はじめに
プロジェクトに関わる役割として、PO（プロジェクトオーナー）・PM（プロジェクトマネージャー）・PMO（Project Management Office）という3つの言葉を耳にする機会が増えました。それぞれの違いが曖昧なまま、現場で何となく使われているケースも少なくありません。それぞれが持つ権限・責任の違いと、実務でどう使い分けるべきかを整理します。
PO・PM・PMOの権限と責任の違い
まず、3つの役割がそれぞれ何に責任を持つのかを整理します。
PO（プロジェクトオーナー）
プロジェクトに対して最終的な意思決定権限と責任を持つ、経営層・事業部門側の役割です。プロジェクトへの投資判断（予算の承認）、スコープの最終決定、重大なトレードオフが発生した際の最終判断がPOの責任範囲です。プロジェクトが生み出すべきビジネス価値に対して説明責任を負う立場であり、プロジェクトの「目的」側・意思決定の最上位を司る役割と言えます。
PM（プロジェクトマネージャー）
「どう進めるか」「いつまでにどう届けるか」に責任を持ちます。スケジュール管理、予算の執行管理、体制構築、リスク対応はPMの責任範囲です。POが承認したスコープ・予算の枠内で、決められた期限の中でどう実現するかを担う、プロジェクトの「実行」側を司る役割です。
PMO（Project Management Office）
個別プロジェクトの意思決定権限は基本的に持ちません。複数プロジェクトを横断して、進め方の標準化、進捗の可視化、リスクの早期発見を支援する役割です。PMOとPM、発注側が目指すべきキャリアはどちらかでも触れたとおり、PMOは「管制塔」としての機能を担います。
どのタイミングでPOに相談すべきか
PMが実務で迷いやすいのが、「どこまでは自分で判断してよく、どこからはPOに相談すべきか」という線引きです。目安は、その判断が「実行方法の調整」なのか「予算・スコープ・重大リスクに関わる判断」なのかです。
例えば、あるタスクの担当者を変更する、作業の順番を入れ替えるといった判断は、承認された予算・スケジュールの範囲内であればPMの裁量で進めて問題ありません。一方、リスクが顕在化して当初予定していたスコープの一部を削らざるを得ない、追加予算が必要になる、納期そのものを見直す必要がある、といった判断は、投資判断そのものに関わる意思決定であり、PMが独断で進めるべきではなく、必ずPOに相談し承認を得るべき領域です。この線引きを曖昧にしたまま進めると、後になって「そんな判断は承認していない」というトラブルに発展しやすくなります。
PMOはどこまでやるべきか
PMOの役割範囲も、現場で誤解されやすいポイントです。PMOは個別プロジェクトの内容判断（スコープや予算の決定）には踏み込むべきではなく、そこはあくまでPOとPMの責任範囲です。PMOが踏み込みすぎると、現場の意思決定が二重構造になり、かえって混乱を招きます。
一方で、PMOの実務上の価値として見落とされがちなのが、「名もなきタスク」「宙に浮いているタスク」を拾い上げる役割です。プロジェクトが複数並行して走っていると、どの担当者の責任範囲にも明確に属さないタスク（部門をまたぐ調整、複数プロジェクトに影響する共通課題など）が必ず発生します。こうしたタスクは、個別のPMからは「自分のプロジェクトの範囲外」と見なされがちで、誰も拾わないまま放置されやすいのが実態です。
PMOがこうした宙に浮いたタスクを定期的に拾い上げ、自ら対応するか、適切な担当者に割り振る——この動きができているかどうかが、PMOが本当に機能しているかどうかの分かれ目になります。進捗会議の仕組みを整えるだけでなく、こうした「隙間」を見つけて埋める実務的な動きこそ、PMOの存在価値が最も発揮される場面です。
まとめ
POは「投資判断・最終意思決定」、PMは「実行・進行管理」に責任を持ち、PMOはそれを横断的に支援する役割です。PMは実行方法の調整と投資判断を混同せず、予算・スコープ・重大リスクに関わる判断は必ずPOに相談すべきです。PMOは個別プロジェクトの意思決定には踏み込まず、標準化と可視化に加えて、誰の担当でもない宙に浮いたタスクを拾い上げる動きを徹底することが、実務で機能するPMOの条件になります。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント