PMOとは？定義・PMとの違い・3つの型・立ち上げ手順を実務目線で解説

定義に「成功させる」とは書かれていない

PMO（Project Management Office、プロジェクトマネジメントオフィス）について、PMIの『PMBOKガイド』はこう書いています。プロジェクトに関連するガバナンス・プロセスを標準化し、資源・方法論・ツール・技法の共有を促進する組織構造である、と。第6版から第7版まで、この記述は変わっていません。PMOを論じるときの共通の出発点はここです。

気づきにくいのですが、この一文には入っていない言葉があります。プロジェクトを成功させる、という目的です。PMOが受け持つのは個別案件の成否そのものではなく、その手前にある仕組みです。進め方を揃えること。一度得た知見を、次の案件が使える形で残すこと。この2つがPMOの原型です。

もう1つ、定義は「組織構造」としか言っていません。独立した部署であることは要求していない。専任チームを置く企業もあれば、PMが持ち回りで担う機能として運用している企業もあります。人数や設置形態ではなく、標準化と共有を誰かが引き受けているかどうかが分かれ目です。

第7版では、この考え方が価値提供（バリューデリバリー）の文脈に置き直されました。ガバナンスを働かせ、実践を組織横断で揃え、改善を回す。それによって価値が届く状態を保つのがPMOだ、という説明です。プロセスを守らせる管理部門というより、組織が成果を出し続けるための土台に近い捉え方になっています。

「PMの補佐役」という説明はどこが不正確か

PMOとPM（プロジェクトマネージャー）の関係を補佐役と言い切ってしまうと、PMOに何を頼めるのかが見えなくなります。両者を分けているのは上下関係ではなく、責任を負う対象の範囲です。

PMが背負うのは、担当する1つのプロジェクトの目標達成です。決められたスコープ・納期・予算・品質の中で成果物を出し切る。そのための判断を日々下す。視野は自分の案件の内側にあります。

PMOが背負うのは、組織の中でプロジェクトが成功しやすい状態そのものです。案件をまたいだ人の取り合いを裁く、複数案件に共通するリスクを早めに見つける、経営層への報告の粒度と様式を揃える。どれもPMの職務範囲の外にあり、案件の中に閉じている限り誰も手を出せません。

PMは深さ、PMOは広さ。1つの案件を掘るのがPMで、横に並べて共通の問題を仕組みで潰すのがPMOです。だから、PMOに「手が足りないから資料作成を手伝ってほしい」だけを求めている組織は、PMOという機能をほとんど使っていないことになります。

ただし、小規模な組織ではPMがPMO機能を兼務するのが普通です。この場合、広さの仕事はほぼ確実に後回しになります。目の前の案件には締切があり、標準づくりには締切がないからです。兼務するなら、週に半日でも組織の型を作る時間をカレンダーに固定してしまうほうが現実的です。意識の切り替えだけでは、まず残りません。

支援型・管理型・指令型は優劣ではなく段階

PMBOKガイド第5版から第6版で示された分類が、いまも実務の共通言語として使われています。PMに対してどれだけ強く関与するかで、PMOを3つに分けるものです。

支援型（Supportive）は、テンプレートやベストプラクティスを配り、研修を開き、過去プロジェクトの教訓を集めて共有します。PMの自主性に手を入れないため、統制の度合いは3つの中で最も低い。相談窓口と資料置き場を兼ねた存在だと考えると近いです。

管理型（Controlling）は、そこに遵守の要求が加わります。使うツールを指定する、定めた様式での報告を義務づける、監査やレビューを入れる。支援と強制の中間です。

指令型（Directive）は、PMOがプロジェクトを直接管理し、PMを指名して配下に置きます。結果責任もPMOが取るため、統制は最も強くなります。

どれを選ぶかは、組織のプロジェクトマネジメント成熟度と、経営がPMOに何を期待しているかで決まります。標準が何もない組織にいきなり管理型や指令型を入れると、守らせる中身が固まっていないのに監査だけが先に始まります。現場に残るのは、報告の手間が増えたという記憶だけです。

定石は支援型から始めることです。テンプレートと相談窓口で先に現場の役に立ち、使われた実績を作ってから、遵守を求める範囲を広げて管理型へ動かす。3つは優劣ではなく段階だと見ると、移行の判断がつきやすくなります。

どれを担い、どれを担わないかを先に決める

定義や型の話を実務に落とすと、PMOの仕事は概ね5つの領域に分かれます。

1つ目は標準化です。プロジェクト計画書、WBS、課題管理表、リスク管理表、進捗報告書の様式を揃え、進め方の手順を決めます。様式が揃うと案件をまたいだ比較ができるようになり、横断的な問題の検知がそこで初めて成立します。

2つ目は可視化と報告。各プロジェクトの進捗・課題・リスクを集め、経営層が決められる粒度に加工して届けます。ここでの値打ちは集計そのものではなく、報告ラインを一本にすることです。PMがそれぞれ経営へ直接報告している状態では、粒度も判断基準もばらつき、案件間の優先順位が付けられません。

3つ目はリソース調整です。人員とスキルの配分を案件横断で見て、逼迫の予兆を拾い、配置換えや採用・外部調達の判断材料を出します。個々のPMは自分の案件のために人を囲い込むので、この調整は中立の立場でなければ成り立ちません。

4つ目は品質の担保。節目でのレビューやゲート審査を置き、計画の妥当性と成果物の水準を確かめます。管理型・指令型に寄るほど、この比重が増します。

5つ目は人材育成とナレッジ蓄積です。研修、PMへのメンタリング、終了時の振り返りと教訓の蓄積。成果が出るまでに時間がかかるため真っ先に後回しにされますが、標準を組織に根づかせ、次のPMを育てるという点では中長期で最も効きます。

5つすべてを初日から抱える必要はありません。むしろ、どれを担い、どれを担わないかを最初に書き出すほうが効きます。

事務局をPMOと呼んでしまうと、何が起きるか

日本の現場でPMOと呼ばれている役割の実態が、プロジェクト事務局であることは珍しくありません。会議体の設定、議事録の作成、資料の取りまとめ、各所への連絡。運営事務の担い手です。

事務そのものは要る仕事で、誰かが引き受けなければプロジェクトは回りません。困るのは、それだけをPMOと呼ぶことです。事務局には、標準を定める権限も、進め方に踏み込む権限も通常ありません。権限のない役割に横断的な問題の解決を期待しても、構造上できないままです。

この混同は、評価の面でも効いてきます。議事録の速さでPMOを測っていると、標準化やリスクの早期検知は測られないまま残り、やがてコスト部門としてしか見られなくなります。

対処は単純です。立ち上げの時点で、PMOに与える権限を文書にする。どこまでなら現場に是正を求められるのか、どの判断は経営に上げるのか。ここを空白にしたまま人だけ置くと、便利な雑務担当として定着し、時間の大半が調整と資料作成に消えます。

組織図を描く前に踏む5つの段取り

PMOを立ち上げるときの順序は、おおむね次の5段階です。

第1に、目的と評価指標を経営層と合意します。「プロジェクト管理を良くする」では何も決まらないので、解こうとしている問題を具体的に言い当ててください。納期遅延が常態化しているのか。案件ごとに品質のばらつきが大きいのか。経営が全体像を見られていないのか。問題が違えば、必要な機能も型も変わります。そのうえで、何をもってPMOが機能していると判断するのかを決めておきます。

第2に、現状を棚卸しします。いまどんなプロジェクトが動き、それぞれどう管理されているのかを見に行く。すでにうまく回っているやり方があれば、それを標準の下敷きにするのが最短です。現場の実態を見ずに外部の型を持ち込むと、まず定着しません。

第3に、最小限の標準を入れます。手をつけるなら進捗・課題・リスクの3点に絞る。帳票を一気に増やすと現場の負荷だけが跳ね上がり、PMOへの反発を招きます。課題管理表とWBSの2点からでも始められます。

第4に、権限と役割を明文化します。前節のとおり、ここが曖昧だとPMOは事務局に吸収されます。合わせて、経営層が公式にPMOの位置づけを表明すること。現場の協力を得られるかどうかは、この一手でかなり変わります。

第5に、定着支援と改善を回します。標準は配って終わりではありません。使われているかを見て、使われていないなら理由を聞き、様式そのものを直す。PMOが守らせるだけの存在になった瞬間から、標準は形だけのものになります。

立ち上げたPMOが機能しなくなる5つの経路

第1は、目的が曖昧なまま立ち上げること。PMO導入の失敗としてもっとも多く挙げられるパターンです。目的が定まらないまま組織だけができ、運用が形だけになり、それでも存続してしまう。回避策は、立ち上げ前に「どの問題を解くのか」「解けたかをどう測るのか」を1枚にまとめ、経営層と合意しておくことです。

第2は、現場の負担だけが増えること。報告様式が増え、会議が増え、しかし現場にとっての見返りが見えない。こうなるとPMやメンバーの協力は得られなくなります。回避策は、標準を1つ入れるたびに現場から手間を1つ引き取ることです。報告様式を課すなら、集計と経営向けの加工はPMO側が引き受ける。

第3は、標準化そのものが目的にすり替わること。ツールやテンプレートを入れること自体が仕事になり、実情に合わない標準を押し付けて非効率を生みます。回避策は、適用範囲に例外を認めることです。全案件に同じ様式を強制せず、規模や重要度で適用レベルを分けます。

第4は、何でも引き受けて自滅すること。役割を定義できていないPMOは、手当たり次第に依頼を受けて潰れます。回避策は、担わない仕事を先に決めること。「PMOはこれをやらない」を明示しておけば、断る判断を毎回の交渉にせずに済みます。

第5は、経営のコミットメントがないこと。PMOは現場に変更を求める役割なので、経営が位置づけを支持していなければ、ただのお願い係になります。回避策は、立ち上げ時に経営層からミッションと権限を正式に表明してもらうことです。

最初の一手は、課題管理表とWBSの2点

実際の一歩に落とすなら、順序は目的の言語化、現状の棚卸し、最小限の標準の導入です。組織図を描くのも要員を確保するのも、その後で構いません。

最初に入れる標準は絞ってください。課題管理表とWBSの2点から始め、それが実際に使われるようになってから範囲を広げる。PMOの信用は、制度設計の立派さではなく、現場がこれがあると助かると感じた実績の積み上げでできています。

当サイトの資料室では、実務でそのまま使えるWBSテンプレートを配布しています。分解の考え方については、WBSの作り方を解説した記事も合わせて参照してください。