クラウドプロジェクトのPMOは何をする？｜「何でも屋」にしないために決める5つのこと

「プロジェクトが思うように進まないので、PMOを立てたい」—クラウド移行や基盤更改のプロジェクトが動き出した企業から、そうした相談をいただくことがあります。

PMOという体制を置くこと自体は、いまや一般的になりました。ただ、その役割を決めないまま人だけを置いた結果、会議の設定から資料の修正まであらゆる作業がPMOに集まり、「何でも屋」になっているプロジェクトも少なからず見かけます。

この記事では、クラウド移行・基盤更改プロジェクトにおけるPMOの役割を整理します。PMOという言葉の定義そのものではなく、何を任せ、何を任せないかを最初に決めておくことに絞ります。

この記事でわかること

• PMOが「何でも屋」になってしまう構造的な理由

• クラウド・インフラのプロジェクトでPMOが担う5つの役割

• プロジェクトを始める前に決めておく分担のチェックリスト

※本記事は、クラウド移行や基盤更改などインフラ領域のプロジェクトを想定しています。組織に常設するPMO部門（EPMO）ではなく、個別のプロジェクトに置くPMOを対象としています。

なぜPMOは「何でも屋」になるのか

PMOは、問題が見えてから求められることが多い

「プロジェクトの推進がうまくいかないので、PMOができる人はいませんか」—私たちへの相談も、こうした形で来ることがあります。

本来PMOは、計画の段階から「このプロジェクトをどう管理するか」を設計しておくほうが機能しやすい役割です。一方で実際には、プロジェクトが動き出してから必要性が認識されることも少なくありません。

そしてその時点で期待されているのは、体系として定義された役割ではないことがほとんどです。依頼する側がイメージしているのは、多くの場合「PMとPLの間、PMと顧客の間に入って、プロジェクトを円滑に回してくれる人」という漠然としたものです。この漠然さが、後の何でも屋化の出発点になります。

途中参画のPMOは、まず状況理解から始まる

経緯や背景を知らない状態で途中から参画したPMOが、すぐに調整役として機能するのは難しいものです。それでも役割が決まっていないので、入った人は目の前の困りごとから順に拾っていくことになります。会議の設定、議事録、資料の修正、ベンダーへの催促—気づくと、それらがすべてPMOに集まっています。

これは偶然ではありません。PMOは、担当が決まっていないタスクを引き受けられる唯一のポジションだからです。PMは判断で手一杯、各ベンダーは自社の作業範囲しか見ていない。誰の担当でもない作業は、消えてなくなるのではなく、PMOに流れ込みます。

管理を始めようにも、土台がないことがある

もうひとつ、外からは見えにくい問題があります。

PMOとしてWBS・課題・リスク・進捗の管理を始めようとしても、プロジェクト管理そのものが、まだその段階に到達していないことが少なくないのです。WBSはあるが、最終更新が数週間前で実態と合っていない。課題表はあるが、起票しているのは特定の1人だけ。決めたはずのことが、どこにも残っていない。

この状態で管理手法だけを持ち込んでも、機能しません。

つまり、PMOが何でも屋になるのは担当者の力量の問題ではなく、役割を定義しないまま人を入れた、体制の設計の問題です。そして多くの場合、PMOが最初にやるべきことは管理そのものではなく、管理できる状態を作ることから始まります。

PMOが担う5つの役割

PMOの役割を一言で言えば、情報を集めることではなく、情報を「判断できる状態」にすることです。この視点で見ると、役割は5つに整理できます。

1. 進捗の可視化

WBSを更新することが目的ではありません。遅れている理由を明確にし、判断が必要な状態を見えるようにすることが役割です。

インフラのプロジェクトでは、遅延の原因が「作業が遅い」ではなく「情報が揃っていない」ことが多くあります。既存環境の棚卸しのような前工程の遅れは、後工程のすべてに効いてきます。進捗率だけを追っていると、この構造は見えません。

2. 課題・リスクの管理

課題表を作ることではなく、誰が・いつまでに・何を判断するかを明確にすることが役割です。

インフラのプロジェクトで挙がる課題は、技術課題よりも「所在不明」の課題が多いのが特徴です。用途の分からないサーバ、担当者が退職した業務システム、契約内容を追えない回線。これらは技術では解けません。調べる担当と期限を決めることでしか、前に進みません。

3. 意思決定の支援

PMOが決めるのではなく、PMや責任者が判断できる材料を揃える役割です。

インフラのプロジェクトでは、切替の時期、停止できる時間、移行方式、ロールバックの可否など、業務への影響と技術的な制約の間で判断が必要になる場面が多くあります。取り得る選択肢、それぞれの影響範囲、うまくいかなかった場合の戻し方—これらをセットで示せるかどうかで、判断の速度が変わります。

4. 関係者間の調整

顧客・ベンダー・開発・インフラの間で生じる認識のずれを整理します。

インフラのプロジェクトでは、ベンダーが複数に分かれることが珍しくありません。ネットワーク、回線、アプリケーション、ライセンスの販社。プロジェクトが止まるのは、多くの場合それぞれの担当領域の中ではなく、責任分界の隙間です。誰の担当でもない作業を見つけ、どこかに寄せる。これがPMOの重要な仕事になります。

5. 運営ルールと記録の管理

「ルールを決めること」と「残す仕組みを作ること」は別の仕事なので、分けて考えます。

運営ルールにあたるのは、会議体、変更管理、レビュー手順、エスカレーションの基準。記録にあたるのは、構成情報、手順書、決定事項です。

インフラのプロジェクトでは、構成情報と手順書が最終的な納品物になります。プロジェクトの成果を運用へ引き渡せるかどうかは、記録のルールを最初に決めたかどうかでほぼ決まります。

PMO機能と事務局機能を分ける

ここまで読んで、「では会議設定や議事録はPMOの仕事ではないのか」と思われたかもしれません。

そうではありません。庶務が不要なのではなく、役割を分けて考えるべきだということです。PMOがそれらを担うこと自体はあります。ただし、それが活動の中心になった時点で、本来の管理・分析・推進に使う時間がなくなります。

作業ごとに整理すると、次のようになります。

この表を貫いているのは、PMOが引き取るのは整合と分析であって、入力作業ではないという原則です。進捗の入力は各担当が、課題の起票は気づいた人が行い、PMOはそれらを突き合わせて全体の整合を見る。ここが逆になると、PMOは常に手が塞がった状態になります。

そのうえで、分担を決めたら事務局機能の工数を別に見積もることをおすすめします。ここを曖昧にすると、結局はPMOが吸収することになります。

うまく回っていないときに出る症状

役割の設計がうまくいっていないプロジェクトには、共通した症状が出ます。当てはまるものがあれば、分担を見直す時期かもしれません。

課題表は毎週更新されているのに、決まったことが増えない

課題に「誰が判断するか」が書かれていないケースです。判断者と判断期限の欄を足すところから始めます。判断者や期限を書けない場合は、まだ課題として整理しきれておらず、いったん調査タスクに分解したほうがよいこともあります。

進捗会議が報告会になっている

資料が実績報告だけで構成され、判断してほしい事項が載っていない状態です。アジェンダの先頭に「今日決めること」を置くだけでも、会議の性質が変わります。

PMOが一番忙しいのに、プロジェクトが前に進まない

庶務がPMOに集中している、典型的な状態です。前章の表を使って、作業を仕分け直します。

切替の直前に、想定外の作業が噴出する

ベンダー間の責任の隙間が放置されていた結果です。責任分界を作業単位で棚卸しします。会社単位で分けているだけでは、隙間は見えません。

始める前に決めておくこと

PMOを置くと決めたら、動き出す前に次の6点を決めておきます。

• [ ] PMOが管理する対象（スコープ／進捗／課題・リスク／品質／コストのどれを見るか）

• [ ] PMとPMOの分担（どこまでPMOが材料を作り、どこからPMが決めるか）

• [ ] 事務局機能の置き場所（PMOに含めるなら、その工数を別に見積もる）

• [ ] エスカレーションの先と基準（何が起きたら、誰に上げるか）

• [ ] ベンダー間の責任分界（会社単位ではなく、作業単位で）

• [ ] 記録のルール（構成情報・手順書・決定事項を、どこに、誰が残すか）

外部の支援会社にPMOを依頼する場合も同じです。何を任せるかは、依頼する側と支援する側で、開始前にすり合わせておく必要があります。支援する側も、曖昧な依頼をそのまま引き受けるのではなく、管理する対象・責任の範囲・事務局機能の有無を確認することが欠かせません。ここが曖昧なまま人を入れると、依頼した側も引き受けた側も、期待していたものと違う結果になります。

まとめ

PMOの価値は、会議を増やすことでも、管理表を増やすことでもありません。プロジェクトの状態を見えるようにし、判断を早くし、止まりそうなところを前に進めることです。

そしてそれは、走り始めてからの頑張りで決まるものではなく、始める前に役割を決めたかどうかでほぼ決まります。PMOを立てることを検討しているなら、人を探す前に、何を任せるかを決めるところから始めてみてください。