PMOの役割とは？ミッション・業務内容一覧と自社に必要なPMOの見極め方

「PMOを入れることは決まりかけている。でも、PMOに何をさせればいいのかが自分の言葉で説明できない」——情シスや経営企画でプロジェクトを預かる方が最初につまずくのは、たいていここです。先に結論を言うと、PMOの役割は一言で「PMの補佐として、プロジェクトのボトルネックを見つけて潰しに行くこと」です。業務内容の一覧はあとで整理しますが、一覧表を丸ごと任せることがPMO活用ではありません。僕は受注側のPMとして、また独立後は発注側の立場でもプロジェクトに関わってきました。その両側の経験から、役割の体系、機能別の業務内容、できるPMOとできないPMOの違い、そして自社に必要な役割の見極め方まで、発注側の目線で解説します。

まず土台の整理から。マネジメントという言葉は日本語で「管理」と訳されがちですが、英語のニュアンスはむしろ「なんとかする」に近い。この訳語のズレが、PMOの役割をわかりにくくしている元凶だと僕は思っています。

僕のPMの解釈は、YouTubeのコラボ動画でも話したとおりです。

format_quote

プロジェクトマネージャーは僕の解釈では、プロジェクトのQCDを守ってビジネス価値を作るところの最終責任者。最終責任者であるがゆえに守備範囲みたいなものがなくて、成功させるためにやれることは何でもやるというのが、抽象的ではあるけど本質的な役割だと思っています。

PMが「何でもやる最終責任者」なら、PMOはその補佐です。だからPMOにも、あらかじめ固定された守備範囲はありません。

format_quote

PMOは僕の解釈だとPMの補佐なので、守備範囲があらかじめ決まっているというよりは、本当に遊撃隊みたいに、ここが今ボトルネックになっているからここを解消しに行こう、というのが本来的なPMOかなと思っています。

遊撃隊、つまり決まった持ち場を守る部隊ではなく、戦況を見て手薄になった場所へ駆けつける部隊です。PMOのミッションを一文にするなら「プロジェクトの不確実性を段階的に減らし、成功確率を上げること」。議事録を書くことも進捗表を更新することも、この目的に効いているなら立派な役割ですし、効いていないなら単なる作業です。

発注側にとってこの整理が重要なのは、PMOへの依頼の仕方そのものが変わるからです。「議事録と進捗表をお願いします」と頼めば、議事録係が着任します。「この3か月で意思決定の滞留を解消してほしい」と頼めば、遊撃隊が動き出す。つまりPMOの役割は、PMO側の能力だけでなく、発注側が何をミッションとして渡すかで半分決まる。ここを押さえずに業務内容の一覧だけ眺めても、自社に必要なPMO像は見えてきません。

なお、PMOの教科書的な定義やPMとの責任分界の詳細比較、支援型・管理型といった類型論はそれぞれ別の論点なので、本稿では「発注側がPMOに何をさせるべきか」に絞ります。役割論の前に、そもそもPMOとは何か・何のために置くのかという定義と目的から押さえたい方は、PMOの入門完全ガイド（別記事）を先に読んでいただくと、本稿の解像度が上がるはずです。

守備範囲が固定されないとはいえ、発注側が期待値を設計するには業務内容の地図が要ります。僕の整理では、PMOの仕事は次の6つの機能に集約されます。

大事なのは、この6機能が並列のメニューではないということ。すべては「今のボトルネックはどこか」を特定した上で選ぶ手段です。たとえば品質問題の多くは、テスト工程で発見されても、根っこは上流の合意のズレにあります。開発プロジェクトの7割は上流工程で決まるというのが僕の持論で、問題への事後対処は事前の手当てに比べて3〜5倍のコストがかかる。だからこそできるPMOは進捗の集計係にとどまらず、上流の合意形成やリスクの予兆検知に張りに行くわけです。

6機能の中で、発注側が過小評価しがちなものを2つ挙げておきます。1つは意思決定の支援。経営が見ているのは事業への影響で、現場が報告するのはタスクの進捗です。この粒度のギャップを翻訳しないまま報告を上げると、経営は「で、どうすればいいの」となり、判断が滞留します。もう1つは標準化・横断管理。プロジェクトマネジメントを属人的な職人芸のままにせず、管理の型を組織に残すことで、優秀な個人がいなくても一定水準の運営ができるようになる。外部PMOを入れる価値の少なくない部分は、この「型が残ること」にあります。

ちなみに、各機能をさらにタスクレベルに分解した実務チェックリストは、それだけで一本の記事になる粒度なのでここでは割愛します。日次・週次で何をするかまで落とし込んだPMOの具体的なタスク一覧とチェックリスト（別記事）を別途まとめているので、実務粒度で確認したい方はそちらをどうぞ。

役割の話をすると必ず出てくるのが「うちに来ているPMO、何をしているのかわからない」という発注側の不満です。僕はPMOを「アクティブPMO」と「パッシブPMO」に呼び分けています。ゴールが何かを理解して、そこに向かって能動的に動けるのがアクティブPMO。言われた作業を回すだけなのがパッシブPMOです。

動画の中でも盛り上がったのが「できないPMO」の具体例でした。日程調整だけをする人、リマインドを送るだけの人、会議でアジェンダのタイトルを読み上げるだけの人。極めつけは、PMに「進捗どうですか」と聞いて「終わってません」と言われ、それをそのまま客先にエスカレーションして現場が怒られる、というパターンです。

format_quote

そういう人のことを僕は「土管」って呼んでいるんですけど、ただ中を通っていくだけ。APIにインプットをコールしたら、インプットしたものがそのままレスポンスとして返ってくる。じゃあそのAPI、意味あるの？っていう。

情報を右から左に流すだけなら、そこに人が介在する価値はありません。パッシブPMOが現場で叩かれる理由も整理するとシンプルで、本来的なPMOの仕事をしていないのにPMOという肩書で入っていて、しかも単価が高いから。同じ仕事でも「アドミニストレーター」という職種名で入っていれば、誰も腹を立てないはずなんです。事務局機能そのものは必要な仕事なのだから。こうしたパッシブなPMOが現場でどう見られ、なぜ「いらない」とまで言われてしまうのかは、PMO不要論・嫌われるPMOの実態を掘り下げた記事（別記事）で詳しく整理しています。

では、できるPMOは何が違うのか。僕は条件を2つ挙げています。1つは圧倒的な思考力。この人に自分の時間を使えば自分の仕事が楽になる、プロジェクト全体が前に進む、と周囲に思わせられること。もう1つはチャーム、つまり愛嬌や寄り添い力です。気難しいチームリーダーから遅延の理由やリカバリの見込みを聞き出せるのは、詰める力ではなく関係構築の力。どちらか片方は必須で、両方あれば最強だと思っています。加えて、マネジメント対象への理解も欠かせません。SAPのプロジェクトならSAP、そうでなくても業務やシステム構成を最低限キャッチアップしておく。わからないなりに過去の議事録を予習してくる人と、わからないまま一般論を語る人の差は、現場が一瞬で見抜きます。

そして僕が一番強調したいのは、この違いがスキルの差だけではないということです。

format_quote

僕が従業員にいつも言っているのは、まずアクティブPMOになろうね、ということ。思考力とか経験とかスキルは最初は追いつかないかもしれないけど、アクティブPMOであろうとするかどうかはスタンスの問題なんで。

発注側にとってこれは朗報です。スキルは面談で見極めにくいけれど、スタンスは質問すれば透けて見えるからです。両者の違いを観点別に並べておきます。

この回はSAPコンサルタントの方とのコラボで、発注現場のリアルな不満も含めてかなり率直に話しています。動画で詳しく知りたい方は、以下もあわせてご覧ください。

「PMOの本当の役割とは？できるPMOとできないPMOの違い【プロジェクトマネジメントの教室】」

ここからが発注側の実務です。PMOの役割は一覧表から選ぶものではなく、自社のボトルネックから逆算するもの。発注前にこの順番で確認すれば外さない、という4ステップに整理します。

ステップ1：プロジェクトの「詰まり」を言語化する。 進捗が見えないのか、会議で何も決まらないのか、品質が不安なのか、部門間の調整が止まっているのか。先ほどの機能一覧に照らして、どこが詰まっているかを発注側自身の言葉で書き出します。ここが曖昧なまま「とりあえずPMOを」と発注すると、高い確率で議事録係が着任します。

ステップ2：それは遊撃機能か、事務局機能かを判定する。 資料作成や日程調整といった事務局機能だけが必要なら、PMOの単価を払う必要はありません。アドミニストレーターや事務局要員として調達したほうが、コストも期待値も適正になります。判断や調整が絡む詰まりであれば、そこで初めてアクティブPMOの出番です。

ステップ3：任せる業務と、求める判断を発注前に言語化する。 「何をやってもらうか」だけでなく「どんな場面で意見や判断材料を求めるか」まで決めておく。具体的には、任せる業務範囲、判断や提言を求める場面、レポートライン、そして3か月後に何がどうなっていれば成功とみなすか。この4点が書き出せていれば、期待値のすり合わせは大きく外しません。PMOが機能しない原因は、PMO側の能力だけでなく、受け入れ側の期待値設計の不在にもあります。ここは発注側の設計責任だと僕は考えています。

ステップ4：面談でスタンスと対象理解を確認する。 経歴書のプロジェクト数は当てになりません。代わりに、こんな質問をぶつけてみてください。

• 「着任後の最初の2週間で、何をしますか」——ボトルネックの特定から入る人か、フォーマット整備から入る人か
• 「私たちのプロジェクトの資料を渡したら、まず何を読みますか」——マネジメント対象を理解しに行く姿勢があるか
• 「進捗遅延を検知したら、経営への報告前に何をしますか」——土管か、遊撃隊か

答えの正しさより、質問への向き合い方にスタンスが出ます。「ご要望に応じて何でもやります」としか返ってこないなら、それはパッシブPMOのサインです。

この4ステップで必要な役割が定まったら、次は誰に担わせるかの検討です。社内人材で賄うか外部の力を借りるかを含め、外部PMO支援サービスの内容と選び方（別記事）も選択肢の整理に役立ててください。

• PMOの役割は「PMの補佐」であり、ミッションは不確実性を減らしてプロジェクトの成功確率を上げること。固定された守備範囲はない
• 業務内容は進捗・課題管理、会議体運営、品質・リスク管理、標準化・横断管理、意思決定支援、ステークホルダー調整の6機能に整理できる
• できるPMOとできないPMOの差は、ゴールに向かって能動的に動くスタンスの有無。情報を流すだけの「土管」に高い単価を払ってはいけない
• 事務局機能だけが必要なら、PMOではなくアドミニストレーターとして調達したほうが期待値もコストも適正になる
• 発注前に「詰まりの言語化」と「求める判断の言語化」をしておくことが、PMOを機能させる発注側の設計責任

PMOという言葉が曖昧なのは、市場の定義が揺れているからで、あなたの理解不足のせいではありません。だからこそ、自社の詰まりを自分の言葉で語れるようにしておくこと。それがそのまま、良いPMOを引き当てる確率を上げる最短の準備になります。

---

PMOに「何をさせるべきか」から一緒に設計しませんか

「PMOを入れたいが、遊撃機能と事務局機能のどちらが必要か判断がつかない」「今入っているPMOが議事録係になっていて、立て直したい」「面談で候補者のスタンスを見極める自信がない」——そんな段階のご相談こそ歓迎です。

僕たちは受注側・発注側の両方でプロジェクトに関わってきた経験をもとに、契約前の役割設計や期待値の言語化からお手伝いしています。話を伺った結果、PMOではなく事務局要員で足りる、あるいは他社の支援形態のほうが適している、と判断すればその旨も正直にお伝えします。

まずは現状の詰まりを整理するところからで構いません。無料相談からお気軽にご連絡ください。PMO支援サービスの詳細はサービス紹介ページにもまとめています。