PMOは「なんでも屋」？
プロジェクトの成功にはいろいろな秘訣がありますが、中でも私は次の三つが重要だと考えています。第一に、熱意あるPMと、そのPMと思いを一つにしたメンバーから成るプロジェクトチームを作ることです。第二に、PMがぶれることなく適切な意思決定を行うことです。そして第三に、PMを補佐するPMO（Project Management Office）が適切に機能することです。
PMOは、PMのプロジェクト管理や意思決定を補佐する存在です。優秀なPMがいるだけでプロジェクトがうまくいく場合もありますが、一定規模以上のプロジェクトになると、PMの目が直接届かない範囲が必ず出てきます。そのため、大規模なプロジェクトになればなるほど、PMOは重要な役割を担うことになります。
では、PMOを配置すれば、プロジェクトがうまくいくのでしょうか？PMOの配置自体は一般化しており、一定規模のプロジェクトを立ち上げる際のToDoリストに「PMOの選定・配置」を記載する企業も多く見られます。それ自体は間違っていませんが、PMOを「なんでも屋」や「お守り」のように捉え、とりあえずPMOを置けばうまくフォローしてくれるだろうと、PMOに対して役割をあいまいにしたまま、過大な期待を抱いてしまっているということはないでしょうか？
この問題は、プロジェクト側のみの都合で生じているわけではありません。PMOを社内のIT部門に依頼したり、外部企業に委託したりするケースが多いですが、そうしたPMOサービス提供側にも原因がある場合があります。PMOサービス提供側としても、一言「PMO」と言っておけば、相手に内容や必要性を大まかに理解してもらえることが多いため、詳細かつ具体的、すなわち解像度の高い説明を避けがちです。
このように、「PMO」という言葉が曖昧な定義のまま広く使われてしまっており、「バズワード化」しつつあるのではないかと危惧しています。
PMOのバズワード化の弊害
特に「どうせ同じPMOだから」と支援範囲や深さの違いを考慮せずに、価格だけでPMO委託先を決定してしまい、後から間違いに気づいてPMO委託先を交代させるというケースでは、対応負荷がさらに高くなります。こうなると、プロジェクトの成功のために配置したPMOが、逆にプロジェクトの足を引っ張る事態になりかねません。
こうした弊害を防ぐためには、PMOに対する解像度を上げて、その内容を関係者で共有しておく必要があります。
PMOの解像度を上げよう
ここで改めて、バズワード化しているPMOというものを分解してみましょう。
「支援対象の組織」、「プロジェクトの単位」、「工程」、「担う役割」の4つの軸で、PMOがプロジェクトの成功に貢献するために実施すべき支援の内容を分解します。
支援対象の組織
①事業部門・システムユーザーを支援する場合
事業部門は事業をいかに拡大・改革するか、顧客や社会にどういう価値を提供するかを目的にプロジェクトに参画します。PMOは、ITの視点を持ちつつ、事業や業務にまで踏み込む必要があります。
＜タスク例＞
- 事業部門の要望・要件および優先度の取りまとめ、部門間の調整
- 業務要件のシステム要件への翻訳、システム部門への共有・連携、業務要件の仮説出し・評価
- 意思決定するために必要な情報整理、事業部門責任者への報告 など
②DX・IT部門を支援する場合
DX・IT部門は、デジタル・ITの専門家集団として、さまざまな制約やリスクを考慮しつつ、業務やシステムのQCDを維持することを目的にプロジェクトに参画します。PMOは、ITやプロジェクト管理の専門家として支援する必要があります。
＜タスク例＞
- システム開発ベンダーの進捗管理および成果物の品質管理
- プロジェクトの課題管理・対応方針検討
- 事業部門とDX・IT部門間のコミュニケーション支援 など
どちらの部門を支援するかによって、PMOの役割は異なります。事業部門・システムユーザーを支援するPMOがシステム開発ベンダーの進捗管理も担っているプロジェクトや、DX・IT部門を支援するPMOが業務要件の仮説出しや事業部門間の調整も担っているプロジェクトは、注意が必要です。
プロジェクトの単位
①単体プロジェクトの場合
単体プロジェクトのPMOは、QCDを守りつつ最大の成果を上げるための支援を行うことが求められます。したがって、必要に応じて詳細な情報を収集し、PMの意思決定を支援します。
＜タスク例＞
- プロジェクト各種状況（進捗、品質、課題、リスクなど）の把握・評価
- 課題・リスクを検知した際の原因調査および対策検討・実行 など
②複数プロジェクト横断の場合
一般的に、複数プロジェクトをまとめたものは「プログラム」と呼ばれるため、複数プロジェクト横断のPMOはPgMO（Program Management Office）と呼ばれます。PgMOは、個々のプロジェクトの状況・事情を踏まえた上で、全体最適の視点に立って支援することが求められます。管理対象が広く、難易度が高いため、高いバランス感覚、コミュニケーション力、経験が必要になります。
＜タスク例＞
- 各プロジェクトの関係性を把握した上での、プログラムのマスタースケジュール管理・調整
- プロジェクト横断での課題管理・影響調査
- プロジェクト横断での設計の整合・調整 など
単体プロジェクトのPMOが別プロジェクトとの横断課題コントロールも実施している場合や、複数プロジェクト横断PgMOが各プロジェクトの細かい管理も実施している場合は、注意が必要です。
工程
①要件定義前
要件定義の前に、プロジェクトを通して解決したい課題や達成したいゴール、システム化方針・要求事項などを明確にすることが重要です。これらを明確にしないまま要件定義以降の工程に入ってしまうと、想定した成果物が得られず、手戻りが発生してしまうおそれがあります。NRIではシステム化構想およびシステム化計画という工程を設け、それらを明確にすることを推奨しています。これらの工程でのPMの支援者は、通常PMOと呼ばれませんが、構想・計画の実施経験や、プロジェクトの対象業務とシステムへの知識が必要となります。
＜タスク例＞
- 現状業務・システム課題の整理・分析
- 新業務・システム方針・要求の検討
- 開発ベンダー候補リストの作成、選定観点案の作成 など
②要件定義以降
要件定義以降は、要件定義・設計・開発・テストなど、開発ベンダー主導で進める工程に入ります。開発ベンダーの活動と、ユーザー側の活動が並行して進行するため、管理対象も増え、検討内容も細かくなります。PMの支援者に求められるものも、要件定義前よりも深く・細かくなります。
＜タスク例＞
- システム開発ベンダーおよびユーザーのタスク進捗管理
- システム開発ベンダーの成果物の確認（例：新システム方針・要求を満たしているか等）
- バグの発生状況・原因分析および再発防止策の検討
- データ移行方針・業務移行方針の検討 など
プロジェクトがどの工程にあるかを意識せず、PMの支援者を一律に「PMO」と呼び、必要以上のタスクを担うことにしているプロジェクトは注意が必要です。
担う役割
①管理支援
管理支援はいわゆる「狭義のPMO」が行うものであり、プロジェクトのモニタリングや管理にフォーカスした支援です。客観的にプロジェクトの状況を評価し、よりよい方向に誘導します。
＜タスク例＞
- 進捗管理・課題管理など、PMBOK（Project Management Body Of Knowledge）管理対象の最新状況収集・評価
- 検知した遅延・課題・リスクへの対策検討、対策実行促進
- 管理対象プロジェクトの状況報告 など
②推進支援
推進支援は管理ではなく、中身の検討・実行そのものに対する支援です。プロジェクトリーダーやメンバーと一体となって主体的にプロジェクトを前に進めます。
＜タスク例＞
- プロジェクト状況を先読みしたタスク設計、課題抽出
- タスク実施・課題への対策仮説作成
- 所在があいまいなタスクのポテンヒットキャッチ、関係者調整
PMOの定義や役割が曖昧になり、バズワード化しつつある最も大きな原因がここにあります。進捗などの管理支援を担当しているPMOが、課題解決などの中身の検討・推進支援まで担っているプロジェクトは、注意が必要です。
これまで述べてきたように、PMOと言っても多くの種類があるのが実態です。様々な軸で解像度を上げて、プロジェクトからのPMOへの期待・認識を明確にしておかなければ、期待・認識と体制・スキルが一致しないため、PMOがボトルネックとなって、プロジェクトの進行が遅れるように見えてしまいます。
続いて、実際のプロジェクト例を用いて、それぞれのプロジェクトにおけるPMOの役割をもう少し具体的に説明します。
実際のプロジェクトでPMOに求める役割
ここでは、過去にNRIが支援した事例の中から、3種類のプロジェクトをご紹介します。
事例1：PMOの役割がDX・IT部門支援から事業部門支援に広がったプロジェクト
- プロジェクトの概要
インフラ基盤の老朽化対応を目的とした、DX・IT部門が企画・推進するプロジェクトです。 - プロジェクトの特性
システムの仕様自体は変更しないため、業務部門に影響を与えないようにDX・IT部門中心でプロジェクトを進めなければなりませんでした。また、製品保守期限が迫っているために対応は必須であり、スケジュールを厳守する必要がありました。
図1 事例1におけるプロジェクト体制図（例）
- PMOへの当初の期待
本プロジェクトでは、プロジェクトのモニタリング・管理（狭義のPMOの役割）が期待されていました。
＜具体的なタスク＞
・ 新たに採用するインフラ基盤による変更点の確認、業務部門への影響の調査
・ タスク・スケジュール管理、進捗可視化
・ 遅延発生時のリカバリー対策案検討、後続影響調査、関係先との情報連携
・ 開発ベンダーからの報告内容の妥当性確認、追加情報提供依頼 など - 追加されたPMOへの期待
プロジェクトが進むにつれて、本番切替時の業務影響をユーザーに事前に伝え、運用方法の合意形成を図る必要がでてきましたが、プロジェクト側にそれを実行するリソースがありませんでした。そこで、元々モニタリング・管理を担当していたPMOに、追加で業務移行の計画作成や調整支援を依頼したことで、予定通りに本番切替を行うことができました。
事例2：2種類の「PMO」が必要になったプロジェクト
- プロジェクトの概要
新しい顧客層やニーズに対応する新Webサービスの立ち上げを目的とした、事業部門が企画・推進するプロジェクトです。 - プロジェクトの特性
顧客向けのWebサービスのため、必要な機能や仕様は顧客ニーズに基づいて検討、決定しなければなりません。
一度決めた仕様でも、競合サービスの提供機能や顧客ニーズの動向などによって、要件の変更・追加が発生することがあるため、その都度、柔軟に対応することが求められていました。
また、リリース日が近づくとプレスリリースで事前告知されるため、終盤はスケジュールの厳守も求められていました。
図2 事例2におけるプロジェクト体制図（例）
- 当初のPMOへの期待
本プロジェクトでは、ビジネスとシステムの両面での実現性を高めるために、プロジェクトの企画段階から外部にコンサルティングを委託していました。システム化構想・計画という要件定義前の工程を経て、中身の検討経緯を深く理解したコンサルタントに、要件定義後にもそのままユーザー課題の検討支援を依頼しました。
＜具体的なタスク＞
・ ユーザーインタビューを通じたビジネス方針検討支援
・ ビジネス方針を踏まえた業務要求・システム要求の検討支援
・ 開発ベンダー選定支援
・ 要件定義後のユーザー課題検討支援 - 追加されたPMOへの期待
プロジェクトを進める中で、既存サービスにおける顧客の利用傾向の変化に対応するため、要件の変更・追加が頻発しました。PMとPLだけでは十分に管理できなくなったため、開発ベンダーとのコミュニケーションに問題が生じ始めました。そこで、ユーザー課題検討のコンサルタントとは別に、管理支援を行うためのPMOを新たに体制に組み入れました。そうすることで、システム要求の実施優先順の見直し、リリース日に影響が出ないような要件の入れ替え調整などをスムーズに進めることが可能になり、Webサービスを無事にリリースすることができました。
事例3：規模の異なる「PMO」の追加が必要になったプロジェクト
- プロジェクトの概要
バックオフィス業務基幹システムの刷新を目的とした、事業部門とIT部門の両方が企画・推進するプロジェクトです。 - プロジェクトの特性
バックオフィス業務基幹システムには、財務会計、管理会計、受発注管理などの複数の業務領域が含まれていました。
そのため、業務領域単位での段階的なリリースを計画し、まずはA領域のプロジェクトチームが組成されました。管理支援を行うPMOと、ユーザー課題検討支援のチームがそれぞれ配置されました。
図3 事例3におけるプロジェクト体制図（例）
- 当初のPMOへの期待
A領域の初期リリースを予定通り行うための、管理とユーザー支援両面での活躍が期待されていました。
＜具体的なタスク＞
・ A領域でのスケジュール管理、進捗可視化、リスク対策
・ A領域でのユーザー課題検討
・ A領域での開発ベンダーの成果物レビュー - 追加されたPMOへの期待
PMOの支援の効果もあり、A領域の初期リリースは無事に終わりました。その後、A領域の追加開発を行いながら、B領域、C領域の開発を行う必要が出てきました。複数領域の開発プロジェクトが並行して進行するため、領域ごとの検討内容や進行速度にズレや矛盾が無いか（整合性）、領域間で見落とされている課題が無いか（網羅性）などの確認が必要でしたが、そのリソースが不足することは明らかでした。
そこで、領域ごとのPMOに加えて、領域横断のプログラムを管理するPgMOを追加で組成し、複数業務領域の状況可視化と課題検討を行う役割を与えました。それにより、領域同士の整合性・検討網羅性を確保しながら、2回目以降のリリース・移行を無事迎え、基幹システムの刷新を完遂することができました。
まとめ
本記事では、実際のプロジェクト事例を用いて、それぞれのプロジェクトにおけるPMOに対する期待と、それが変化する実態について説明しました。
便利な言葉として使われがちなPMOという言葉も、支援対象の部門、対象とするシステム・業務の特性、プロジェクト規模や工程によって、実際に期待される役割や範囲は異なります。
期待や役割に対する誤解や認識ずれを防ぐために、PMOという言葉で安易に一括りにするのではなく、プロジェクトの特性に合わせて期待するタスクやアウトプットを具体的に定義することが望ましいです。特に、期待するタスクや役割が管理ではない場合は、PMOと呼ばず、プロジェクト内で適切な名称（ユーザー課題検討支援、プロジェクト推進支援など）を用いることをお薦めします。
そうすることで、適切な役割とスキルを持った体制をプロジェクト内に配置しやすくなるとともに、プロジェクト内での見落としや手戻りが少なくなり、PMがプロジェクトをより成功に導きやすくなるでしょう。
NRIでは、様々なプロジェクトの管理・推進支援の実績があり、プロジェクトの特性・状況に合わせてご支援内容をカスタマイズし、ご提案させていただいております。プロジェクトの推進に関してお悩みがありましたら、ぜひご相談ください。
プロフィール
-
宮澤 夢実のポートレート 宮澤 夢実
産業ITコンサルティング二部
製造業企業の情報システム部門を経て、2019年に野村総合研究所に入社。現在は各種プロジェクトの推進・伴走、システムのグランドデザイン、システム化構想・計画などのコンサルティング業務に従事。
-
森崎 慶太のポートレート 森崎 慶太
産業ITコンサルティング二部
2009年に野村総合研究所に入社。事業変革・業務改革を伴うシステム化構想・計画、実行段階におけるユーザ支援・PMO支援など多数のプロジェクト実績を有する。不動産・運輸業界を中心としたコンサルティンググループのグループマネージャー。
※組織名、職名は現在と異なる場合があります。