#20:「体制図」の空白が炎上を招く ── プロジェクト監理者をどこに配置すべきか？（Part 3 実行編：体制論）
お世話になっております。 YMGアドバイザリーの山口です。
投稿のペースを落としました（昨年比）が、皆様のお役に立つべく、今回も「実行論」についてしっかりとお届けいたします。
1.なぜ、「責任者」が二人いてもプロジェクトは迷走するのか？
前回Vol.19では、DXプロジェクトには「進行」を管理するProject Manager（PM）と、「構造の品質」を守るProject Supervisor（監理者）が必要だと述べました。
ここで多くの方が頷きながら、同時にこう思われたはずです。
「うちにはPMがいる。クライアント側にも、ベンダー側にも。責任者は二人いる。なのに、なぜ泥沼化するのか？」
答えは明確です。“責任者が二人いる体制図”は、完璧に見えて、致命的な欠陥を抱えているからです。
一般的なDX体制は、クライアント側PMとベンダー側PMが向き合い、定例会で進捗・課題・スコープを擦り合わせる形で描かれます。
一見すると死角がありません。 しかし、この体制図には「ある席」が抜け落ちています。
それが、設計図の正しさ（構造の品質）だけを守る“監理者の席”です。
この席が空白のままプロジェクトが走り出すと、進捗は進んでいるように見えて、どこかのタイミングで必ず炎上します。
本稿では、この「体制図の空白」をどう埋めるべきか。 監理者を“どこに置くべきか”を、具体的にOrg Chartのロジックとして提示します。
2. 「二項対立」の限界 ─ 利害関係の板挟みになる設計思想
なぜ、クライアント側PMとベンダー側PMが揃っていても、構造品質が守られないのでしょうか。
それは両者のミッションが、最初から異なるからです。
クライアント側PM：社内の要望、現場の不満、部門間の政治、稟議の制約を背負う
ベンダー側PM：工期、コスト、契約スコープ、リソース稼働率を背負う
この二人が向き合う場で、最も強い力学として働くのは何か。
それは「妥協の合理性」です。
現場から「これも欲しい」が出る。
ベンダー側から「それを入れると遅れます」が返る。
結果として合意される言葉は、ほぼ決まっています。
「運用でカバーしましょう」
「次フェーズで対応しましょう」
「いったん最小で対応して、あとで改善しましょう」
この言葉自体が悪いわけではありません。
問題は、それが“構造品質を犠牲にする妥協”であるかどうかを判定する者がいないことです。
クライアント側PMは社内調整の圧力を受ける。
ベンダー側PMは納期・コストの圧力を受ける。
この板挟み構造の中で、「設計の美しさ（構造の正しさ）」は、常に妥協の対象になります。
結果として、Closed-loopは途切れ、データはつながらず、現場は回らない。
そして最後に「結局使われない」という残念な結末を迎えてしまいます。
二項対立の体制図では、設計思想が守れません。 だからこそ 必要なのが、「第三の視点」です。
3. PMOの限界 ── 事務のプロに「審判」は務まらない
ここで、よくある反論に答えておきましょう。
「うちにはPMO（Project Management Office）を設置しているから大丈夫だ」
確かにPMOは、会議が時間通りに始まり、議事録が整備され、課題管理表の空欄が埋まっているという「プロセスの品質」は保証してくれます。
しかし、その空欄に書かれた解決策が、”5年後のシステムをスパゲティ化させないか”という「構造の品質」を判定するには、アーキテクトとしての深い専門知（現場知×構造思考）が必要です。
PMOは、設計図が歪んでいても「期限内に提出された」ことにはOKを出します。
監理者は、たとえ期限内であっても「構造に歪みがある」ならNGを出します。
この役割の違いを認識しないままPMOに監理を委ねることは、経理担当者に建築現場の安全確認をさせるようなものです。
事務のプロに、設計の審判は、残念ながら務まりません。
4. 解決策：監理者の配置論 ─ 「第三の視点」をどこに刺すべきか
結論から言います。 監理者をPMの下に置いてはいけません。
PMの下に監理者を配置すると、監理者は必ず「進捗」の圧力に屈します。
「品質が不安だが、今は止められない」
「本当は設計を見直すべきだが、炎上するので言えない」
こうして監理は形骸化し、監理者は“レビュー担当”に矮小化します。
監理者に必要なのは、独立性です。
監理者は調整役ではなく、審判（レフリー）であるべきだからです。
ここで、推奨する配置パターンを二つ提示します。
推奨パターン1：スポンサー直下のアドバイザリー（独立した品質監査席）
最も強い配置は、監理者を経営層（スポンサー）の直下に置くことです。
体制図としては、次のようなイメージになります。
この配置の狙いは一つです。
監理者が、スケジュールや部門都合に引きずられず、構造品質の観点で経営へ直接進言できる状態を作ること。
「この仕様ではClosed-loopが回りません」
「この“運用でカバー”は、将来コストを爆発させます」
「今止めないと、半年後にもっと大きく炎上します」
こうした“嫌われるが正しい指摘を言える”のは、スポンサー直下の独立席だけです。
推奨パターン2：ビジネスとITの「翻訳」の結節点（ブリッジ＋審判）
二つ目は、監理者をビジネスとITの結節点に置く配置です。
ただし、ここで重要なのは、監理者を「調整役」にしないことです。
監理者の役割は、現場の要求をそのまま通すことでも、IT側の都合で丸めることでもありません。
現場の要求を「構造」に変え、エンジニアの仕様を「業務」に翻訳し、プロトコル変換の品質を担保することです。
体制図としては、以下のように置きます。
この配置は、現場とITがぶつかる“摩擦点”に監理者を置くことで、設計思想を守り抜く構造です。
監理者は「調整役」ではなく「審判」です。
ここを曖昧にすると、監理者は最も疲弊します。
5. 具体的な効能：監理者が体制図にいることで変わる「3つの会議」
1）ステアリング・コミッティ（ステコミ）
ステコミが「遅れの報告会」になっている組織・プロジェクトは少なくありません。
監理者がいると、ステコミはこう変わります。
遅れの議論だけでなく、構造の歪みを経営にエスカレーションできる
「今止めるべきか、進めるべきか」を設計品質の根拠で判断できる
“運用でカバー”の負債を、経営が自覚できる
つまり、ステコミが「進捗会議」から、本来の「意思決定会議」に戻ります。
2）要件定義会議
要件定義の最大の罠は、
現場要望が“仕様”に変換される過程で、構造が壊れること
です。
監理者がいると、次の峻別が可能になります。
現場のワガママ（局所最適） 真に守るべき構造（全体最適）
「それは現場にとって便利ですが、Closed-loopを壊します」
「それは見た目の効率化ですが、判断ロジックが死にます」
この線引きができると、要件定義は“言った者勝ち”から脱却します。
3）ベンダーレビュー
ベンダーからの「できます」は、”製品技術的に可能”、という意味であることが（非常に）多いです。
しかし監理者が問うのは別です。
その実装は運用で、将来にわたって持続可能か？
AM-BOM（As-Maintained BOM）やサービス実績とつながるか？
将来の改修で負債にならないか？
“次フェーズ”が常態化しない設計か？
ここを監理者が厳しくチェックできると、ベンダーレビューは「安心材料の提示」ではなく「構造品質の監査」になります。
6. 結論：体制図を描き直す勇気
DXは、走り出してからは、体制を変えることが極めて難しい。
だからこそ、キックオフの時点で「監理の席」を確保しているかが、勝敗を分けます。
クライアント側PMとベンダー側PMが体制上揃っていても、プロジェクトは迷走しがちです。
なぜなら、その二項対立の体制図には、設計図の正しさを守る席が存在しないからです。
体制図の空白が、炎上を招く。
まずは皆さまのプロジェクト体制図を思い浮かべてください。
そこに、独立した監理者の席はありますか？
YMG Advisoryが提供するのは、この「独立した監理者の席」です。
監理者は、プロジェクトを「前に進める」ことだけを目的としません。
時には「止める」ことが最大の価値になるからです。
”レッドカードを出せる審判がいない試合は、必ず荒れます”
Part 3では、ここで述べた監理視点を具体的なチェックリスト—監理のPlaybookとして公開していきます。
現場DXを「管理」から解放し、「監理」によって成功へ導くために。2026年、実行編を継続します。
次回は、監理者が最初に行う“構造品質監査”の具体手法を解説します。
取り上げてほしいテーマ、ご質問、ご相談などございましたら、お気軽に ymg-info@ymg-advisory.com までご連絡ください。