「プロジェクトが増えてきたのでPMOを置きたい」「DX推進のために全社を横断するPMOを立ち上げたい」——こうした相談は年々増えています。近年はPMOの役割が、進捗を取りまとめる事務局から、品質を是正する参謀役、さらには全社の投資判断に関わる統括機能へと広がってきました。

一方で、立ち上げたPMOが「報告資料を集めるだけの部署」になってしまい、期待した効果が出ないという声も後を絶ちません。その多くは、PMOを作ること自体が目的化し、「どの権限を持つ、どのレイヤーのPMOにするか」という設計を最初に決めていないことに原因があります。

本記事では、PMOを新設または再構築する立場の方に向けて、PMOの類型とレイヤーの整理から、立ち上げの進め方、体制設計、よくある失敗までを実務目線でまとめます。

そもそもPMOとは何か——「事務局」との違い

PMO（Project Management Office：プロジェクトマネジメントオフィス）とは、組織内のプロジェクトを横断的に支援・統制する常設の機能です。個々のプロジェクトを率いるプロジェクトマネージャー（PM）が「1つのプロジェクトを成功させる」役割であるのに対し、PMOは「複数のプロジェクトが安定して成功する状態を組織として作る」役割を担います。

ここで注意したいのが、PMOと「事務局」は同じではないという点です。会議体の運営や資料の取りまとめといった事務局機能はPMOの活動の一部ではありますが、それだけに留まると、PMOは意思決定に関与しない伝達係になってしまいます。本来のPMOは、集めた情報をもとにリスクを早期に指摘し、標準を整え、経営とプロジェクト現場の間で判断を支えるところに価値があります。

立ち上げの最初の議論で「PMOに何をさせたいのか」を、事務作業のリストではなく「どんな意思決定を助けたいのか」という言葉で定義しておくことが重要です。

PMOの3つの型——支援型・統制型・指揮型

PMOをどう設計するかを考える出発点として、国際的なプロジェクトマネジメントの標準であるPMI（Project Management Institute）が示すPMOの3類型が有用です。これはPMOが持つ**権限（コントロールの強さ）**によって役割を整理したものです。

支援型（Supportive）はテンプレート、ベストプラクティス、研修、教訓などを提供する相談役で、プロジェクトへのコントロールは低い。統制型（Controlling）は支援に加えて、定められた標準・手法・ツールへの準拠を求め、コントロールは中程度。指揮型（Directive）はプロジェクトそのものを引き取り、直接マネジメントする、コントロールの高い型である。

— PMI『A Guide to the Project Management Body of Knowledge (PMBOK Guide)』が示すPMOの類型より要約

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

型権限の強さ主な役割向いている状況
支援型弱いテンプレート・標準・研修の提供、相談対応、知見の蓄積各部門のPMが自律している。まずは緩やかに底上げしたい
統制型中標準への準拠要請、レビュー・監査、進捗と品質のチェックプロジェクトごとの品質のばらつきを是正したい
指揮型強いPMを直接配置し、プロジェクトを主体的に推進難易度の高い重要プロジェクトを確実に完遂させたい

現実には、1つの型に固定する必要はありません。全社的には支援型として標準を配りつつ、経営に直結する重要プロジェクトだけは指揮型として深く関与する、といった組み合わせが一般的です。大切なのは、どのプロジェクトに、どこまで踏み込む権限を持つのかを、立ち上げ時点で経営層と合意しておくことです。権限が曖昧なまま「品質をチェックしろ」とだけ言われても、現場に是正を促す力を持てず、PMOは形骸化します。

なお、PMIの最新の考え方（PMBOK第7版）では、この3類型は絶対的な分類ではなく、組織の状況に応じてPMOの形は多様であってよい、という柔軟な方向へと整理が進んでいます。3類型はあくまで「権限をどう設計するか」を考えるための出発点として使うのがよいでしょう。

PMOが担う3つのレイヤー——プロジェクト・プログラム・コーポレート

権限の強さとあわせて設計すべきなのが、PMOがどの範囲を見るのかというレイヤーです。近年「コーポレートPMO」「全社PMO」という言葉が注目されているのは、PMOの守備範囲が個別プロジェクトから全社へと広がっているためです。

レイヤー見る対象主な問い主な報告先
プロジェクトPMO単一の大規模プロジェクトこの1件をどう完遂するかプロジェクトオーナー
プログラムPMO関連する複数プロジェクトの束施策群として狙った成果を出せているか事業・部門責任者
コーポレートPMO全社のプロジェクト・投資全体限られた資源をどの施策に配分すべきか経営層・CIO
  • プロジェクトPMOは、基幹システム刷新のような単一の大型案件に張り付き、進捗・課題・リスクを管理します。もっとも現場に近いレイヤーです。
  • プログラムPMOは、たとえば「DX推進」という旗のもとに走る複数の施策を束ね、施策間の依存関係や優先順位を調整します。個々のプロジェクトが成功しても、全体として狙った変化が起きなければ意味がない、という視点を持ちます。
  • コーポレートPMOは、全社のプロジェクト群と投資を俯瞰し、「どの施策に人と予算を割くか」「何をやめるか」という配分の判断を経営に対して支援します。ここまで来ると、PMOはIT投資管理やポートフォリオマネジメントと地続きになります。

自社がどのレイヤーのPMOを必要としているのかは、抱えている課題によって変わります。「特定の重要案件が火を噴いている」ならプロジェクトPMO、「DXの施策が乱立して優先順位がつかない」ならコーポレートPMO、というように、課題からレイヤーを逆算するのが立ち上げの出発点になります。

PMO立ち上げの進め方——5つのステップ

PMOの立ち上げは、組織を作ってから役割を考えるのではなく、解きたい課題から逆算して設計します。おおむね次の順序で進めます。

ステップ1：解きたい課題と目的を定義する

「なぜPMOが必要なのか」を、抽象的なスローガンではなく具体的な困りごとで言語化します。「重要プロジェクトの遅延が続いている」「投資判断の根拠が揃わない」「プロジェクト品質が担当者次第でばらつく」——課題が違えば、必要な型もレイヤーも変わります。ここが曖昧なままだと、後のすべてがぶれます。

ステップ2：型とレイヤーを決め、権限を経営と合意する

課題に照らして、支援型・統制型・指揮型のどれで、どのレイヤーを見るのかを決めます。そのうえで、PMOがどこまで踏み込めるのか——標準への準拠を「求める」のか「強制できる」のか、プロジェクトの中止や見直しを「提言する」のか「判断に関与する」のか——を経営層と明文化して合意します。この権限の裏づけがPMO成否の分かれ目です。

ステップ3：担う機能を絞って決める

PMOが担いうる機能は多岐にわたります。最初から欲張らず、課題に直結する機能に絞ります。

機能領域具体例
標準・方法論プロジェクト管理の手順・テンプレート・成果物の型を整備
モニタリング進捗・課題・リスクの可視化、早期警戒
品質・レビュー節目でのレビュー、第三者としての点検
資源・ポートフォリオ要員配置の調整、投資の優先順位づけの支援
人材育成PMの育成、ナレッジの蓄積と共有

立ち上げ初期は「モニタリングと標準整備」から始め、信頼を得てから品質レビューやポートフォリオ支援へ広げる、という段階的な拡張が現実的です。

ステップ4：体制と役割分担を決める

PMOに必要な人材を確保し、PMやプロジェクトオーナーとの役割分担を定義します。ここを曖昧にすると「PMOとPMのどちらが決めるのか」で現場が混乱します。RACI（誰が実行し、誰が説明責任を負い、誰に相談し、誰に報告するか）で整理しておくと、越境や押し付け合いを防げます。

活動プロジェクトオーナーPMPMO
プロジェクトの進捗管理ARC
リスクの早期検知・エスカレーションIRC／R
管理標準・テンプレートの整備ICR
節目レビューの実施ACR
投資・優先順位の判断ACC

（R：実行、A：説明責任、C：相談、I：報告）

ステップ5：小さく始めて成果を示し、広げる

最初から全社の全プロジェクトを対象にすると、負荷ばかりが増えて価値が見えにくくなります。まずは対象を絞ったパイロットで、リスクの早期発見や意思決定の迅速化といった目に見える成果を出し、その実績を武器に対象範囲と権限を段階的に広げていきます。

よくある失敗と回避策

PMOの立ち上げでつまずくパターンは、ある程度共通しています。

よくある失敗何が起きるか回避策
権限が曖昧なまま発足是正を促せず、報告を集めるだけの部署になるステップ2で権限を経営と明文化して合意する
事務局化資料の取りまとめに追われ、リスク指摘や判断支援に手が回らない「どんな意思決定を助けるか」で役割を定義する
監視役と受け取られる現場が実態を隠し、報告が形骸化する支援と統制のバランスを取り、まず現場の負担を減らす価値を提供する
機能の詰め込みすぎ立ち上げ初期に負荷が集中し、どれも中途半端になる課題直結の機能に絞り、段階的に拡張する
経営との接続不足集めた情報が意思決定に使われず、PMOの存在意義が薄れる報告先とレイヤーを合わせ、経営の問いに答える形で情報を届ける

とくに多いのが、1つ目の「権限の曖昧さ」と2つ目の「事務局化」です。この2つはセットで起きます。権限がないから判断に関与できず、結果として事務作業に押し込まれる——この悪循環を避けるために、立ち上げ時の権限合意にもっとも時間をかけるべきです。

自社に合うPMOをどう選ぶか

ここまでの整理をふまえ、自社に合うPMOの型とレイヤーを選ぶための判断の目安をまとめます。

  • プロジェクトの品質が担当者次第でばらついている → 統制型 × プロジェクト／プログラムPMO。標準を整え、レビューで底上げする。
  • 各部門のPMは自律しているが、知見が共有されていない → 支援型 × プログラムPMO。テンプレートと教訓の共有から始める。
  • 経営に直結する難プロジェクトを確実に完遂させたい → 指揮型 × プロジェクトPMO。PMを直接配置して深く関与する。
  • DX施策が乱立し、投資の優先順位がつかない → 支援・統制のハイブリッド × コーポレートPMO。全社のポートフォリオを俯瞰して配分を支援する。

現実の組織では、これらを組み合わせて運用します。「全社には支援型のコーポレートPMOを置き、重要案件だけは指揮型で入る」といった設計が典型です。重要なのは、型もレイヤーも固定的な正解があるわけではなく、自社の課題と成熟度に応じて選び、育てていくものだということです。

立ち上げたPMOは、一度作って終わりではありません。組織のプロジェクトマネジメントが成熟するにつれ、支援型から統制型へ、プロジェクト単位からコーポレートへと、担う役割は変化していきます。定期的に「いまのPMOは、いまの課題に合っているか」を問い直すことが、形骸化を防ぐ最良の方法です。

FAQ

Q. PMOは専任でなければいけませんか。 立ち上げ初期は兼任から始める組織も多くあります。ただし、リスクの早期指摘や標準整備には一定の工数が必要です。兼任だと目の前のプロジェクト業務が優先され、横断的な活動が後回しになりがちなため、成果が見えてきた段階で専任化を検討するのが現実的です。

Q. PMOとPMは何が違うのですか。 PMは「担当する1つのプロジェクトを成功させる」役割で、そのプロジェクトの遂行に責任を持ちます。PMOは「複数のプロジェクトが安定して成功する状態を組織として作る」役割で、標準の整備・横断的なモニタリング・経営への判断支援などを担います。両者は対立するものではなく、PMOがPMを支え、時に統制する関係です。

Q. 小さな組織でもPMOは必要ですか。 プロジェクト数が少ないうちは、専任のPMO組織を作るより、まず支援型の機能（テンプレートや振り返りの仕組み）を軽く整えるところから始めるのが適しています。プロジェクトが増え、品質のばらつきや優先順位づけに困り始めたら、レイヤーと型を決めて正式に立ち上げるとよいでしょう。

Q. コーポレートPMOと従来のPMOはどう違いますか。 従来のPMOが個別プロジェクトやプログラムの遂行を支援するのに対し、コーポレートPMO（全社PMO）は全社のプロジェクト群と投資全体を俯瞰し、「どの施策に資源を配分するか」という経営レベルの判断を支援します。守備範囲と報告先が経営層に近づく点が大きな違いです。

まとめ

PMOの立ち上げで最初に決めるべきは、組織の箱ではなく「どの権限を持つ、どのレイヤーのPMOにするか」という設計です。

  • PMOは事務局ではなく、意思決定を支える機能として定義する
  • 権限は支援型・統制型・指揮型の3類型で、範囲はプロジェクト・プログラム・コーポレートの3レイヤーで整理する
  • 課題からレイヤーと型を逆算し、権限を経営と明文化して合意する
  • 機能を絞って小さく始め、成果を示しながら段階的に広げる
  • 型もレイヤーも固定ではなく、組織の成熟に応じて育てていく

PMOは、正しく設計すればプロジェクトの成功率と投資対効果を組織的に引き上げる強力な仕組みになります。反対に、権限も目的も曖昧なまま立ち上げると、報告を集めるだけの部署になりかねません。自社の課題を起点に、どのPMOが必要なのかを見極めるところから始めてください。

参考資料