レッスン7：PMOとの連携とエスカレーション設計

このレッスンで学ぶこと

PMOの3つの機能類型（支援型・統制型・指令型）を理解する
PMOが求める報告とプロジェクトリーダーが欲しい支援のズレと、PMOを味方につける5つの手を学ぶ
ステアリングコミッティの設計と、エスカレーションの3レベルを身につける
悪い知らせを早く上げる仕組みの重要性を理解する

前回のレッスンでは、評価権のないメンバーをどう動機づけるかを扱いました。今回は、視点を変えて、プロジェクトを横断的に見るPMOとの関係、そして問題が起きたときにどう上に相談するかというエスカレーションの設計を扱います。中核メッセージの5つ目「PMOは監視者ではなく味方にできる」を、具体的な技術として学ぶレッスンです。

PMOの3つの機能類型

レッスン1で触れた通り、PMO(プロジェクト・マネジメント・オフィス)は、複数のプロジェクトを横断的に支援・統制する社内組織です。PMBOKに由来する一般的な分類として、PMOの機能は次の3つの類型に整理されます。

支援型（Supportive）のPMOは、プロジェクトリーダーに対してテンプレートの提供やノウハウの共有、他プロジェクトの事例紹介といった支援を行います。関与の度合いは比較的軽く、プロジェクトリーダーの自主性を尊重します。

統制型（Controlling）のPMOは、支援に加えて、一定の手法やツールの使用を求め、進捗報告のフォーマットや頻度についてもルールを課します。プロジェクトリーダーの裁量は支援型より狭くなります。

指令型（Directive）のPMOは、プロジェクトの実施そのものを直接管理する強い関与を持ちます。プロジェクトマネジャーがPMOに所属し、PMOの指揮のもとでプロジェクトを実施する形が典型例です。

3つの類型を整理すると、次のようになります。

類型	関与の度合い	プロジェクトリーダーへの主な働きかけ
支援型（Supportive）	軽い	テンプレートの提供・事例紹介
統制型（Controlling）	中程度	手法・報告フォーマットの統一を求める
指令型（Directive）	強い	プロジェクトの実施そのものを指揮する

💡 ポイント どの類型のPMOと関わっているかによって、期待される報告の詳しさや、相談できる範囲が変わります。自社のPMOがどの類型に近いかを早い段階で見極めておくことが、円滑な連携の出発点になります。

PMOが求める報告とプロジェクトリーダーが欲しい支援のズレ

多くのプロジェクトリーダーがPMOとの関係で感じる不満は、「PMOへの報告は手間ばかりかかり、見返りとなる支援が見えない」というものです。一方、PMO側の視点に立つと、複数のプロジェクトを横断的に管理する立場から、定型化された報告を集めることは、リスクの早期発見や全社的な優先順位づけのために欠かせない業務です。

このズレは、双方の目的の違いから生まれます。プロジェクトリーダーは自分のプロジェクトの成功を第一に考えますが、PMOは全社のプロジェクトポートフォリオ全体の健全性を第一に考えます。どちらも間違っているわけではなく、視点の違いが摩擦を生んでいるだけです。

具体的な場面で考えてみます。あるプロジェクトリーダーが、毎週の定型報告を「形式的な作業」と感じ、必要最低限の内容だけを埋めて提出していました。あるとき、プロジェクトの進行に不安を感じてPMOに相談したところ、「〇〇さんの報告はいつも簡潔すぎて、こちらから支援できる材料が少なかったんです」と返されました。プロジェクトリーダーからすれば「忙しい中で最低限は提出していた」という認識でしたが、PMOからすれば「支援したくても、判断材料が足りなかった」というのが実感でした。この行き違いは、報告を単なる義務ではなく、支援を引き出すための情報提供として捉え直すことで解消できます。

📝 補足 このズレを理解せずに「PMOは監視するだけで役に立たない」と決めつけてしまうと、PMOが持つ支援機能を活用する機会を自ら手放すことになります。次の項で扱う「PMOを味方につける5つの手」は、このズレを埋めるための具体的な行動です。

PMOを味方につける5つの手

PMOとの関係を、監視される関係から味方にする関係に変えるために、次の5つの手を紹介します。

1つ目は、求められる報告を先回りして整えることです。フォーマットや頻度に忠実に応じることで、PMOからの信頼を得やすくなります。

2つ目は、PMOが持つ支援機能を積極的に使うことです。テンプレート、過去の類似プロジェクトの事例、専門的な相談窓口など、PMOが提供できるリソースを能動的に求めます。

3つ目は、早めに相談することです。問題が深刻化してから相談するのではなく、兆候の段階で相談することで、PMOを問題解決の味方として巻き込めます。具体的には、まだ致命的な影響が出ていない段階で、「現時点では大きな問題ではありませんが、外部ベンダーの納期に遅れの兆候があります。念のため情報共有させてください」とPMOに伝えます。深刻化してから「実は数週間前から遅れの兆候がありました」と報告するのでは、PMOが打てる手も限られてしまいます。

4つ目は、PMOの立場を理解した言葉で伝えることです。「このプロジェクトが成功すること」だけでなく、「この状況が全社のポートフォリオにどう影響するか」という視点を添えて伝えると、PMOにとって判断しやすい情報になります。具体的には、「このベンダーの遅延は、当プロジェクトだけでなく、同じベンダーを使っている別のプロジェクトにも影響する可能性があります」と伝えると、PMOにとっては全社的な対応を検討する材料になり、単なる一プロジェクトの困りごとよりも優先度高く扱ってもらいやすくなります。

5つ目は、別のプロジェクトリーダーとの情報交換にPMOを活用することです。PMOは複数のプロジェクトを横断して見ているため、似た課題を抱える別のプロジェクトリーダーを紹介してもらえることがあります。

⚠️ 注意 PMOとの関係づくりは、一方的にPMOの要求に従うことを意味しません。統制型・指令型のPMOであっても、過度な報告負担や、プロジェクトの実態にそぐわないルールについては、率直に相談し、調整を求めることも健全な関係の一部です。

ステアリングコミッティの設計

レッスン1で触れたステアリングコミッティは、プロジェクトの重要な意思決定を行う会議体です。プロジェクトリーダーは、この会議体を自ら設計する立場に立つことが多く、設計の質がプロジェクトの意思決定速度を大きく左右します。

構成は、スポンサー、関係部門の責任者、必要に応じてPMOの担当者を含めます。頻度は、プロジェクトの重要な区切り（主要なマイルストーンの前後）に合わせて設定するのが基本で、月1回程度が目安になることが多いですが、プロジェクトの規模や緊急度によって調整します。議題は、進捗報告に時間を割きすぎず、意思決定が必要な事項に重点を置いて設計します。

実際の議題構成の例を示すと、次のようになります。

時間配分	議題
5分	前回からの進捗サマリー（要点のみ）
20分	意思決定が必要な事項（予算追加の承認、スコープ変更の可否など）
10分	リスク・懸念事項の共有
5分	次回までのアクションの確認

このように、進捗報告に多くの時間を割かず、意思決定と懸念共有に時間を厚く配分することで、ステアリングコミッティが「報告を聞くだけの場」ではなく「決める場」として機能します。

📖 もっと詳しく 会議そのものの進行技術（発言を引き出す、対立を整理する、時間配分を設計するなど）は、会議運営や合意形成を専門に扱う別の実践的な教材で詳しく学べます。本レッスンでは、ステアリングコミッティという会議体の構成・頻度・議題設計という骨格に絞って扱っています。

エスカレーションの3レベル

問題が起きたとき、誰に、どの段階で相談するかを整理しておくことが、プロジェクトを止めないために欠かせません。エスカレーションを3つのレベルに分けて設計します。

flowchart TD
  Issue[問題の発生]
  L1[レベル1<br/>PL自身の判断で対応]
  L2[レベル2<br/>PMOへの相談]
  L3[レベル3<br/>スポンサー・ステアリングコミッティへの報告]

  Issue --> L1
  L1 -->|自力での解決が困難| L2
  L2 -->|全社的な調整・意思決定が必要| L3

図1：問題の深刻度に応じて、対応のレベルを段階的に引き上げます。すべての問題をいきなりスポンサーに上げるのではなく、レベルを見極めて相談先を選ぶことが重要です。

レベル1は、プロジェクトリーダー自身の裁量で対応できる問題です。憲章で委譲された権限の範囲内で解決できる問題が該当します。

レベル2は、PMOへの相談が有効な問題です。別のプロジェクトの知見や、全社的な調整力が必要な問題が該当します。

レベル3は、スポンサーやステアリングコミッティへの報告が必要な問題です。プロジェクトの目標達成そのものに関わる重大な問題、あるいは部門間の対立が自力での解決を超える場合が該当します。

判断基準としては、影響範囲の広さ（自分のプロジェクト内で収まるか、他部門やほかのプロジェクトに及ぶか）、緊急度（放置すると被害が拡大するか）、自分の権限で解決できるかどうかの3点を目安にします。

実際の報告文は、レベルに応じて次のように書き分けます。

レベル2(PMOへの相談)の例:「現在、外部ベンダーの作業に遅延の兆候があります。まだプロジェクト全体への影響は限定的ですが、類似の事例があれば教えていただけないでしょうか」

レベル3(スポンサーへの報告)の例:「外部ベンダーの遅延により、来月のマイルストーンの達成が難しい見込みです。対応案として、スコープの一部先送りを検討しており、ご判断をいただきたく存じます」

レベル2では情報収集と早期の相談に重点を置き、レベル3では意思決定を仰ぐ形に重点を置いていることがわかります。伝える相手によって、求めるものが「知見」なのか「判断」なのかを意識して文面を変えることが、エスカレーションを機能させる鍵になります。

陥りやすい失敗パターンは、レベルを飛び越えてしまうことです。小さな懸念の段階でいきなりスポンサーに報告すると、「まだ相談するほどの話ではないのに」と受け止められ、次第に相談そのものを重く扱われなくなります。逆に、深刻な問題をレベル1のまま抱え込み続けると、対応が手遅れになります。レベルに応じた相談相手を意識することが、双方にとって適切な情報の流れを保ちます。

悪い知らせを早く上げる仕組み

エスカレーションの設計において、最も重要な心構えは「悪い知らせほど早く上げる」ことです。プロジェクトが計画通りに進んでいないという事実は、多くのプロジェクトリーダーにとって伝えづらいものです。しかし、悪い知らせを抱え込み、状況が悪化してから報告すると、対応できる選択肢が狭まり、関係者からの信頼も損なわれます。

早く上げる仕組みを作るには、定例の報告の場に「懸念事項」の項目を必ず設け、些細な兆候でも共有する習慣をつけることが有効です。また、報告を「失敗の告白」ではなく「早期対応のための情報共有」として位置づけ直すことで、心理的なハードルを下げられます。

🔰 初学者の方へ 「まだ様子を見てから報告しよう」という判断は、多くの場合、事態を悪化させます。不確実な情報であっても、「現時点でこういう兆候がある」という形で早めに共有し、状況が変わり次第、続報を伝えるという進め方の方が、関係者からの信頼を保てます。

講師の現場メモ

事業横断プロジェクトのPLを務めていたころ、私はPMOを「進捗を細かくチェックしてくる監視役」だと感じていました。定型フォーマットへの入力を毎週求められ、正直なところ、負担に感じることもありました。

その後、全社PMO室のマネジャーとして、今度は複数のプロジェクトを横断的に見る側に立ちました。そこで気づいたのは、PMOに寄せられる報告が、実は全社のリソース配分やリスク管理の判断材料として、経営層への説明にそのまま使われているという事実でした。私がかつて「面倒な報告」だと感じていたものは、PMO側から見れば、複数のプロジェクトの健全性を横並びで比較するための、貴重な情報源だったのです。

PMO室マネジャー時代、あるプロジェクトリーダーが印象に残っています。彼女は毎週の報告を誰よりも丁寧に整え、懸念事項の欄には小さな兆候でも書き込んでいました。あるとき、彼女のプロジェクトで、外部ベンダーの遅延という懸念が報告に上がってきました。まだ致命的な影響が出る前の段階でした。私たちPMOは、同時期に別のプロジェクトでも似た懸念が上がっていたことに気づき、全社的にベンダーとの調整を主導しました。彼女のプロジェクトは、結果として大きな遅延を避けられました。

この経験から私が学んだのは、PMOにとって最も価値のある情報は、成功の報告ではなく、早い段階での懸念の共有だということです。プロジェクトリーダーの立場からは、PMOへの報告は義務のように感じられるかもしれません。しかし、丁寧な報告を積み重ねるプロジェクトリーダーは、いざというときにPMOから最も手厚く支援される存在になります。監視されているという感覚を、味方を増やす機会だと捉え直すことができれば、PMOとの関係は大きく変わります。

まとめ

このレッスンでは、以下のことを学びました。

PMOには支援型・統制型・指令型の3つの機能類型があり、期待される報告の詳しさや相談できる範囲が異なる
プロジェクトリーダーとPMOの間には、視点の違いから生まれる報告と支援のズレがあるが、5つの手でこのズレを埋め、味方につけられる
ステアリングコミッティは構成・頻度・議題を意図的に設計することで、意思決定の速度を高められる
エスカレーションはレベル1(自己判断)・レベル2(PMOへの相談)・レベル3(スポンサーへの報告)の3段階で設計する
悪い知らせほど早く上げる仕組みを持つことが、プロジェクトを止めないための重要な心構えである

次のレッスンでは、いよいよプロジェクトの最終段階、終結マネジメントとプロジェクトリーダー自身のキャリアについて扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。