#24:PMに、全部任せるな
─ 経営層が見落とす「監理機能」の空白
お世話になっております。YMGアドバイザリーの山口です。
今回は、少し直接的な話をします。
特に、DXプロジェクトをスポンサーとして支える経営層の方々に、届いてほしい内容です。
ただし、これはPMの能力や努力を批判する話ではありません。
PMという役割に、そもそも担い切れない期待を載せている。その体制設計の問題です。
提案書に書かれたPMと、期待されるPMは同じではない
どのプロジェクトの提案書にも、PM（プロジェクトマネージャー）の役割が記載されています。
進捗管理、課題解決、品質管理、ステークホルダーとのコミュニケーション。整然とした文言が並びます。
しかし、ここでいう品質管理とは、多くの場合、成果物が定められた基準を満たしているか、要件やテストが計画通り完了しているかを管理することです。
そのシステムが、現場業務、データ、経営判断までを正しく接続し、将来にわたって持続可能な構造になっているかを監理することとは、同じではありません。
私が複数のDXプロジェクトを、クライアント側とベンダー側の双方から見てきた中で、強く感じることがあります。
提案書に書かれたPMの役割と、経営層やプロジェクトメンバーが暗黙に期待する役割は、しばしば大きくずれています。
この期待のずれは、クライアント側だけに生じるものではありません。
プロジェクトメンバーも、自分の担当領域を越えて影響する問題を見つけたとき、
「これはPMがクライアントと確認し、全体として判断してほしい」
と考えます。
しかし、PMがすべての実務領域を理解し、部門横断の判断まで担えるとは限りません。課題の登録、担当者の設定、解決期限やステータスの管理はできても、その課題が業務、データ、システム全体に与える構造的な影響まで判断することは、別の専門性と役割を必要とします。
その結果、メンバーは「PMが判断してくれる」と考え、PMは「各領域の責任者が解決すべき問題」と考える。
その間にある課題が、誰にも引き取られないまま残ります。
そして、こうした役割認識のずれを明確にしないままプロジェクトが走り始めることが、プロジェクト崩壊の最も上流にある起点です。
ベンダーが言えないこと、クライアントが聞かないこと
ベンダー側のPMが主として担うのは、契約で合意されたスコープの中で、プロジェクトを前へ進めることです。
定義された成果物を、定められた品質と期限で納品する。課題を整理し、関係者を調整し、プロジェクトを止めない。
これは決して小さな仕事ではありません。
しかし、クライアント側がPMに抱く、
「何かあれば、全体を見て解決してくれるはずだ」
という期待とは、根本的に異なる場合があります。
では、なぜこのギャップが放置されるのでしょうか。
ベンダー側には、商取引上の制約があります。
受注前の提案フェーズで、
「私たちのPMは、御社の業務構造や意思決定の不備まで含めて、すべてを解決する役割ではありません」
と明確に言える営業担当者は、現実には多くありません。
受注を優先すれば、クライアントの期待を完全には否定せず、曖昧なまま受け止めることになります。
これは、必ずしもベンダーの不誠実さではありません。商取引の中で生じる、構造的な問題です。
一方、クライアント側にも別の事情があります。
PMに何を期待するのかを、明確に言語化したことがない。
「総責任者として、全体を見てくれるはずだ」
という感覚はあっても、その「全体」に何が含まれるのかを契約や体制図の言葉に落としていない。
あるいは、どう定義すればよいのか分からない。
そもそも、その必要性さえ理解がない。
結果として、双方が異なる”理想の”PM像を持ったまま、契約が締結され、プロジェクトが走り始めます。
明確にすると、双方にとって都合が悪い。だから曖昧なまま残される。
その曖昧さが、後になって大きな歪みになります。
「総責任者」という言葉の罠
経営層が、
「PMに全部任せている」
と言うとき、その「全部」の中身を問い返してみると、驚くほど曖昧なことがあります。
「総責任者」という言葉が、この曖昧さを生む装置になっています。
「総」という文字がついた瞬間に、誰も責任の範囲を問わなくなる。
総責任者なのだから、全体がカバーされているはずだ。PMがプロジェクト全体を分かっているはずだ。
そう信じて疑わない状態が生まれます。
しかし、ベンダー側のPMは「契約スコープ内の進行管理」を担っている。
クライアント側は「構造的な問題も含めて、全体を見てくれる」と期待している。
この乖離は、誰の議事録にも残りません。
進捗会議では「順調です」という報告が続きます。
課題管理表の消化率も上がっていきます。
しかし、業務、データ、システム、現場運用の間にある構造的な歪みは、誰も見ていない。
PMは、それを独立して監査する役割として置かれているわけではありません。
クライアント側にも、その構造を横断的に見る担当者がいない。
そして経営層は、週次レポートのGreenに安堵している ー これが実態です。
監理機能という「空白」に、誰も気づかない
Vol.21でお伝えした「構造監査」の話を、ここで改めて経営層の言葉に翻訳します。
進捗を管理するPMと、構造品質を監理する人は、根本的に異なる役割です。
PMはプロジェクトの内側で、
「納期、予算、スコープを守りながら前へ進める」
責任を担います。
一方、監理者は進捗ラインから一定の独立性を持ち、
「そもそも正しい方向へ進んでいるか」
「現場業務とシステムは整合しているか」
「この構造で、導入後も運用が回り続けるか」
を問い続けます。
PMは、前へ進める役割です。
監理者は、必要であれば立ち止まらせる役割です。
同じ人が両方を担えば、進捗を守る責任と、構造上の問題を理由に停止を提言する責任との間に、強い役割葛藤が生じます。
これは、施工を進める現場監督に、独立した設計監理まで兼ねさせるようなものです。
しかし、多くのDXプロジェクトでは、この監理機能が体制図上で明示されていません。
監理者の席がない。役割も、権限も、報告先も定義されていない。
PMへの「総責任者」という過剰な期待が、その空白を覆い隠しているからです。
誰も意図的に監理を外しているわけではありません。
それでも結果として、構造を監理する目が存在しない状態で、プロジェクトが走り続けます。
DX推進責任者・PMOの皆さんに、一つだけ問いたいこと
あなたは今、
「PMが全部やってくれるはずだ」
という上司の期待と、PMが実際に担える役割の間で、静かに、しかし激しく消耗していないでしょうか。
課題を上げれば、
「PMに任せているのではないか」
と言われる。
PMに相談すれば、
「それは契約スコープ外です」
と返ってくる。
その間にある空白を、あなたが一人で埋めていないでしょうか？
その空白の名前は、監理機能の不在です。
そして、その不在を解消するために必要なのは、あなたがさらに努力することではありません。
経営層の認識を更新することです。
「PMに全部任せる」という発想を、
「PMとは別に、構造品質を見る監理機能を置く」
という発想へ変える。
Vol.23でお伝えした三つのステップを使うなら、例えば次のように伝えることができます。
現在の体制では、進捗を守る責任と、構造品質を監査する責任が、同じ役割に集中しています。
今の段階で監理機能を補うコストと、UAT直前に構造的な問題が見つかった場合の修正コストには、大きな差があります。
このまま進める場合、私たちはリリース直前に対処困難な問題を引き受ける可能性があります。今のうちに、一緒に体制を見直せないでしょうか。
主語はYouではなく、Weです。
「経営が間違っている」「PMが見ていない」
と告発するのではなく、
「私たちの体制に、見えていない領域がある」
と伝える。
共同作業への招待として、体制の見直しを提案します。
監理の不在は、後から推進責任者の責任になる
最も厄介なのは、監理機能を必要としている経営層ほど、その不在に気づきにくいことです。
「PMがプロジェクト全体を分かっているはずだ」
そう信じて疑わないまま、プロジェクトは進んでいきます。
しかし、PMが主として見ているのは、契約されたスコープ、進捗、課題、成果物です。
業務、データ、システム、現場運用の間に生じている構造的な歪みまで、PM一人が必ず把握しているわけではありません。
そして問題が表面化したとき、推進責任者は、経営層からこう問われます。
「なぜ最初から、監理者という役割が必要だと言わなかったのか」
しかし、Vol.22で述べた通り、計画の前提や体制の不備を早期に指摘することが、組織の中で不利益につながる場合があります。
問題を指摘すれば、
「計画を止める人」
「プロジェクトを複雑にする人」
「余計なコストを増やす人」
と見られる。
一方で、黙って進めれば、炎上後に、
「なぜもっと早く言わなかったのか」
と問われる。
その間に置かれた推進責任者が沈黙するのは、必ずしも能力や勇気の不足ではありません。
組織の中で、合理的な選択をしているだけなのです。
だから必要なのは、推進責任者に勇気を求めることではありません。
経営層が、
「PMにも見えないものがある」
と理解し、監理機能の必要性を早い段階で受け止めることです。
監理者を置くかどうかを、炎上後に現場へ問い返すのではない。
プロジェクト開始時に、経営が判断する。
それが、本来あるべき責任の置き方です。
炎上してから、
「なぜ最初から言わなかったのか」
と問う前に、経営層自身が確認すべきことがあります。
進捗を報告する席とは別に、構造の歪みを伝える席が、本当に用意されているか。
YMGアドバイザリーでは、プロジェクト初期の体制設計段階から、監理機能をどこに、どの権限で組み込むかについてご相談を承っています。
また、すでに進行中のプロジェクトに対しても、現在の体制に構造品質を確認する機能が存在するか、第三者の視点から整理します。
「PMはいる。しかし、本当に全体を見られているのだろうか」
「進捗はGreenだが、なぜか不安が消えない」
「うちのプロジェクトは大丈夫か」
そんな直感をお持ちの方は、ymg-info@ymg-advisory.comまでご連絡ください。
次回Vol.25では、このシリーズ全体を貫いてきた問い──
「なぜ日本企業のDXプロジェクトは、誰も手を抜いていないのに、同じ失敗を繰り返すのか」
を総括します。