PMOとは？プロジェクト別の役割や導入するポイントを解説

昨今のプロジェクト体制でPMOが登場することは珍しくありません。一方で、発注者（プロジェクトマネージャ等）やプロジェクトリーダー(PL)やメンバの中には、PMOの存在意義や提供価値について疑問を持たれている方も多いと推測します。本稿では、様々な立場の方がPMOについて抱く疑問や偏見を解消し、期待役割や関わり方について適切に理解してもらうことを目的にしています。

PMOの採用を検討している方にとっては採用判断の一助、プロジェクトメンバにとっては適切な関わり方への理解の一助、PMOを担う方々へはキャリア構築への一助、になることを目指しています。

PMOについてよく聞くこと・思われること

本稿の読者の皆さんはプロジェクトに様々な役割で関わっている方がいると思われますが、下記のような声を聞いたり、考えをしたりなどはないでしょうか。

＜PL、メンバとして＞
・PMOって何？
・プロジェクトメンバに偉そうなことばかり言うが、役割が分かりづらい
・正直、PMOってプロジェクトの中で浮いていているし、必要なのか？

（余談）筆者は、数年前までは、PMOの良くない例を多く見てきて（そればかり見てきて、毛嫌いしていたこともあり）PMOの存在意義を否定していた一人です。

＜PMO発注者として＞
・PMOの役割が良く分からない
・期待役割や使い方が分からない
・うまく機能しない

＜PMO当事者として＞
・PMOとしてのキャリアをどう築けばいいのか

本稿ではこのような疑問や意見に対し、PMOの全容をわかりやすく解説していきます。なお、すべて読み切るにはある程度の時間が必要かもしれません。時間がない方や特定の内容を知りたい方は以下の章をお読みいただくことをお勧めいたします。
　・PMOやプロジェクトに馴染みがない方===「プロジェクトマネジメントの起源」
　・PMO設置形態やPMとの役割の違い、PMO種類を知りたい方===「PMOの設置形態」
　・PMO導入の必要性やメリット、デメリット、導入ポイントについて知りたい方===「PMOの必要性」

プロジェクトマネジメントの起源・定義

1950年代、米国防総省が国防、航空宇宙など、大規模プロジェクトを管理するためにマネジメント手法を体系化したのが始まりとされています（PMI日本支部 アニュアル レポート 2021）。

目標達成へ向けて資金や期間などの資源に制約がある中、「関係者が多種多様」「必要な作業が複雑（結果、長期間になりやすい）」な大規模な活動がプロジェクトと呼ばれる起源です。

プロジェクトマネジメントが民間企業に広まってからは、規模の大小、複雑さ度合いに関わらず、（プロジェクト上で守られる必須項目として）“プロジェクトの鉄の三角形”と呼ばれる「スコープ」、「スケジュール」、「コスト」が明確な（有限な）活動全体のことをプロジェクトと呼ぶ、と筆者は理解しています。（かくいう筆者は、プライベートの引越し等、各種イベントを一人プロジェクトと称して、WBSを作ってマネジメントしており、もはや職業病ともいえます）

プロジェクトマネジメント ツール群の起源

プロジェクトという概念が出てきた前後に、プロジェクトマネジメント・ツール群(WBS*1、ガントチャート、PERT/CPM*2手法等）の多くが開発されています。その後EVMS*3が登場するなど発展し続けています。

*1 WBS：Work Breakdown Structure
プロジェクトゴール達成へ向けて、プロジェクトの必要な工程や作業を構成立てて分解したもの、ガントチャートや進捗管理表に応用展開される。
*2 PERT/CPM：Program Evaluation and Review Technique/ Critical Path Method
プロジェクトの完遂までに必要なタスクを分析する手法。PERTは戦略コンサルティング会社“ブーズ・アレン・ハミルトン社”が開発、CPMと合わせてクリティカルパスの導出やマネジメントで利用される
*3 EVMS：Earned Value Management
金額予算と日程予定の観点からプロジェクトの遂行状況を定量的に評価し、コスト効率と進捗率を把握するためのプロジェクト管理手法

PMOとは？

Project Management Office（プロジェクトマネジメント・オフィス）の略称で「ピーエムオー」と呼びます。

プロジェクトマネジメントを円滑に進めるための組織であり、一般的には以下のような役割が求められます。

（準備）プロジェクトマネジメントの標準化
（展開）プロジェクト内へのマネジメント標準の周知・展開
（人材開発）プロジェクトメンバへマネジメント研修の実施
（実践）プロジェクト状況チェック、問題・課題取り纏め、原因・真因追求、対応策案検討
（報告・相談）PMへの適時適切な報告・相談
（調整）プロジェクト内外とのリソース（人員、スケジュール、機材等）の各種調整
（修正）マネジメント標準の見直し

PMOの設置形態

組織によって設置形態は様々で、以下のようなものがあります。

１.社内プロジェクトメンバをPM補佐としてPMOに任命
２.外部要員をPMOとして採用
本稿を読まれる方々の大半は、上記いずれかのケースを想定されると思います。
体制図上ではPMとプロジェクト内の各チームの間にPMOが設置されます。状況に応じて、プロジェクト内各チームに派遣され円滑なチーム運営の実施・定着化を支援します。

３.社内のPMO専門組織からプロジェクトへPM補佐としてPMOを派遣
プロジェクトマネジメントの専門知識、経験とも豊富な人材からなるPMO専門組織を設置し、各プロジェクトへPMOを派遣します。こちらも、プロジェクト体制上は、１・２と同様の配置になります。

４.プロジェクトへPM（プロジェクト・マネージャー）を派遣する専門組織
特にIT業界では聞きなれないですが、１～３とは異なり、「プロジェクトへPM（プロジェクト・マネージャー）を派遣」するための専門組織としてPMOを設置する企業もあります。

例）日揮ホールディングス社

私の勤務先である日揮は、PMOという名前の組織はない。プロジェクト本部という組織があり、それとは別にエンジニアリング本部という機能別組織（電機・機械・化学・建築・制御・シビル等の設計者集団）がある。プロマネはプロジェクト本部に属して、各案件（プロジェクト）ごとに機能別組織の横串を通すマネジメントを行なう。つまり、典型的なマトリクス型組織である

PMOが最も必要とされる場所 :タイム・コンサルタントの日誌から

（余談）上記ブログ筆者（佐藤知一氏）は、長らくプラントエンジニアリング企業の日揮に勤められ、プロジェクト計画やプロジェクトマネジメントに関する書籍の執筆、PMに関する諸団体での講演など、日本国内のプロジェクトマネジメントに貢献されている方です。

PgMOとの違い

最近では、プログラム・マネジメント・オフィス（Program Management Office：PgMO）という言葉を目にした方もいらっしゃると思います。PMOとPgMOの違いは、対象と活動目的について以下のように異なります。

詳しく知りたい方は、記事「PgMOとは？PMOとの違いからその役割・案件を説明してみた」をご覧ください。

	PMO	PgMO
対象	目標が１つのプロジェクト（群） ※同一目標のグループ会社や他拠点への展開プロジェクト含む	個々の目標が異なる多種多様のプロジェクト群
活動 目的	プロジェクトマネジメントの円滑な運営	企業が掲げる目標・課題への達成
活動 内容	「PMOとは？」参照	・共通使命(ミッション)の定義付け ・共通使命(ミッション)達成に必要なプロジェクトの検討・組成 ・複数プロジェクトの統括マネジメント

なお、以降の記事は、ITプロジェクトで一般的なプロジェクト組織（１・２）におけるPMOを対象としています。

PMとPMOの役割の違い

「PMOとは？」で少し触れましたが、PMとPMOでは明確に役割が異なります。PMの役割は、「プロジェクト目標を達成すること」です。一方、PMOの役割は「プロジェクトマネジメントを円滑に運営すること」にあり、関係者等含めてその違いは以下の通りです。

	PM	PMO
役割	プロジェクト目標の達成	プロジェクトマネジメントの円滑な運営
関係者	・プロジェクト・オーナー（PO） （多くは経営マネジメント層） 以降は、PMOとの役割分掌次第 ・プロジェクト各チームリーダー（メンバ） ・プロジェクトに関連する他プロジェクト ・プロジェクトに関連する各種部署	・プロジェクト・マネージャー（PM） ・プロジェクト各チームリーダー（メンバ） ・プロジェクトに関連する他プロジェクト ・プロジェクトに関連する各種部署
報告先	PO	PM
活動 内容	・PMOの一連の機能（PMOを設置しない場合） ・プロジェクトの鉄の三角形へ納めるための各種判断・指示 ・プロジェクト・オーナーへのプロジェクト概況報告 ・プロジェクト・オーナーへのプロジェクト計画変更交渉（プロジェクトの鉄の三角形を見直しが必要な場合）	・プロジェクトマネジメントの標準化・見直し ・プロジェクト内へのマネジメント標準の周知・展開 ・プロジェクトメンバへマネジメント研修の実施・定着化 ・プロジェクト状況収集 ・プロジェクト状況分析（問題・課題定義、原因・真因追求） ・プロジェクト問題・課題への対応策案定義 ・プロジェクト運営の安定化 ・PMへの適時適切な情報報告・相談 ・プロジェクトリソース管理（要員勤怠、作業進捗、チーム間での要員・スケジュール調整等）

PMBOKは、IT業界のためだけにあらず

ごく稀に「PMBOK＝IT業界のプロジェクトマネジメント」と理解しているお客様やプロジェクト関係者（コンサルファーム等）とお会いすることがあります。が、PMBOKはプロジェクトに関する全般のガイドラインです。詳しく知りたい方は、第7版についてまとめたこちらの記事をお読みください。

実はいろいろあるPMOの種類

PMOの種類について、一般社団法人 日本PMO協会での定義を照らし合わせながらご紹介します。

１.事務局タイプ（日本PMO協会での定義：「PMOアドミニストレータ（PMO事務）」相当）

• 会議開催準備や議事録作成、発生した課題や進捗の確認が主な活動
• ルーティーンワークが圧倒的に多く、難易度は低め

本稿の冒頭に示したように「PMOって何？」「プロジェクトメンバに偉そうなことばかり言うが、役割が分かりづらい」「正直、PMOってプロジェクトの中で浮いていているし、必要なのか？」のようにとらえる方々の大半は、このタイプのPMOを目にする機会が多いためと筆者は推測しています。

 ２.支援タイプ（日本PMO協会での定義：「PMOアドミニストレータ（PMO事務）、（一部）PMOエキスパート」相当）

• ステコミに向けた資料作成や各工程の計画書作成、ベンダの進捗・品質・リスク管理といったPM業務を支援
• 進捗・品質・リスク管理はプロジェクトが定めたルールに従い、形式的に運用
• 要件定義や基本設計工程に多い印象で、経験値のあるPMOメンバだと資料の流用など効率化を図れるので難易度は中程度

３.課題解決タイプ（日本PMO協会での定義：「PMOエキスパート」相当）

• ２の支援タイプの上級版
• プロジェクト上の課題が起きた場合、整理や会議の場でのエスカレーションだけでなく、ユーザやベンダの中に入って解決の方針を策定し、課題が解決するまでトレースする

４.リスク検知タイプ（日本PMO協会での定義：「PMOマネジャー」相当）

• ３の課題解決タイプのスゴ腕版
• あたかも企業参謀さながらPM参謀として、PMへ迅速な共有・提案を通してPMの意思決定を支援
• プロジェクトリスクが可能な限り顕在化させないように、未然防止案の検討のうえ、PMへ報告・提言
• リスクが問題として顕在化した際には、問題の発生原因・真因を突き止め、対応策案を検討のうえ、PMへ報告・提言

PMOのあんなこと、こんなこと（ほんのちょっと、つぶやき）

炎上プロジェクトでは火消し役でPMOが投入されることがあります。投入されたPMO（達）は、（自分たちは責められない安全地帯という蚊帳の外から）ドヤ顔で問題・課題や原因を指摘し、上から目線でPLやメンバたちに接することを目にすることがありますが、これは褒められた行為ではありません。
PMOと各チームのリーダーやメンバは単に役割が違うだけであり、関係性に上も下もありません。PMOが全うすべくは、「プロジェクトマネジメントの円滑な運営」ですが、左記の態度では「プロジェクト崩壊」を招くのは明らかです。
このようなPMOを見つけた際には、勇気をもってPM（ないしはそのうえ上に）エスカレーションしましょう。
プロジェクトに寄り添うPMOであってほしいものです。

PMOの必要性

プロジェクトマネジメント機能は多岐にわたり、プロジェクトが大規模（プロジェクト内チーム数、メンバ数等）かつ複雑（多様な関係者、複数システムの連携等）になればなるほど、プロジェクトマネジメント機能は複雑化し作業量は多くなり、結果として難易度が高くなる傾向にあります。このような状況下でPMが一人でプロジェクトマネジメント機能全てを実践するのは現実的ではありません。

企業活動を円滑に実施するために組織の拡大とともに業務機能を分割して組織が細分化されるように、プロジェクトも目標達成へ向けて意思決定機能を除くPM機能の一部または全部をPM以外のメンバへ移譲することが考えられます。その期待役割を担うのがPMOです。

PMO導入のメリット・デメリット

【PMO導入メリット】

プロジェクトマネジメント業務の一部をPMOに委譲することで、PM、PLやメンバそれぞれにメリットが生じます。

＜プロジェクト全体にとって＞　▶▶▶　プロジェクト管理品質の向上
進捗やリスク・問題・課題など各種プロジェクト状況報告のルールや報告フォーマットの標準化、周知・展開・定着化などをPMOが受け持つことで、プロジェクト管理品質の向上を期待できます。

＜PMにとって＞　▶▶▶　重要なプロジェクトマネジメント業務への注力
プロジェクトでの意思決定やPO等の重要ステークホルダーとの調整といった難易度が高く重要なプロジェクトマネジメント業務へ注力できます。また、リスクの検知、問題発見のサイクルが早まり迅速に必要な対応を講ずることが可能になります。

＜PLやメンバにとって＞　▶▶▶　担当タスクへの注力
PLやメンバはプロジェクト状況報告をルーティン化できるため、各チームの担当タスクに注力できます。

【PMO導入デメリット】

一方で、デメリットが生じることもあります。

＜プロジェクト全体にとって＞　▶▶▶　PMとPL、メンバとの距離拡大
PMOの立ち位置に依りますが、プロジェクト体制上、PMOはPMとPL、メンバの間に入るケースが多いです。PMとPL、メンバの間には距離ができ、双方のコミュニケーション不全が発生するリスクがあります。
また、PMOがPMの意志や指示の意図を歪曲して解釈し、間違った方向・内容でPLやメンバに伝達・指示するリスクもあります。

＜プロジェクト全体にとって＞　▶▶▶　一時的な管理工数の増大
PMOから展開されるプロジェクト状況報告のルールやフォーマットが、プロジェクト各チームのやり方（各PLのそれぞれの意向）にそぐわない場合、プロジェクト報告が安定化するまでは一時的に管理工数の増大が多かれ少なかれ発生します。

PMOのPMの意向やプロジェクト方針の理解度、PMOの力量や思考・行動のクセによるところが大きいですが、以下のようなリスクもあります。

＜プロジェクト全体にとって＞　▶▶▶　恒常的な管理工数の増加、プロジェクト機能不全＞
PMOが、プロジェクト規模やメンバ構成（知識・スキル）などの実態を把握せぬまま、”あれもこれもとことん管理する”といった、必要以上のプロジェクトマネジメントの実施に陥るリスクがあります。その場合、管理の種類・量が膨大になり、管理工数が増加を招く危険性があります。（PMBOKを絶対的な存在のように扱い、全ての管理を徹底的に行おうとするPMOに見られます）

PMO導入ポイント

PMO導入のポイント

PMが優秀で、プロジェクトに時間を割くことが出来る場合は１の事務局タイプで十分ですし、基幹システムの大規模リプレイスで失敗したら“ヤバイ！”場合は、４のリスク検知タイプのPMOを設置すべきです。また、１～４の全てのPMOをバランスよく揃えるというのもありえます。

つまり、プロジェクトの性質によってPMOの必要性、必要とするPMO機能は異なります。PMO導入には、PMを含めたプロジェクトメンバや開発ベンダのスキル、予算、プロジェクトの重要性から判断しますが、目安として、以下のことをPM一人で対応が困難な場合は、PMO導入検討をおススメします。

• プロジェクト規模（チーム数、メンバ数）
• プロジェクト管理対象*の数やプロセス数、関連性（複雑化否か）

*プロジェクト活動の各種計画、スコープ管理、スケジュール管理、リスク・問題・課題管理、コスト管理、品詞管理など

外部要員としてPMOを選定する際のポイント

外部要員でPMOを調達する際には以下のことをポイントに選定されることをおススメします。（なお、PMO機能が高度になればなるほど高額になる傾向）

• 提供されるPMO機能は、期待役割に沿ったものか
• 予算感に合うか
• 企業やプロジェクト情況を理解したうえでサービス提供できるか

プロジェクトへPMOを投入する際のポイント

PMO導入デメリットを引き起こさず、円滑にプロジェクト運営ができるよう、以下のポイントを実践することをおススメします。

• プロジェクト全体へのPMO投入理由や期待役割について事前説明
• 定期的な機能評価（直接チェック、メンバからのヒアリング）

優秀なPMOを見つけるには／PMO案件で活躍するには

PMO人材をお探しの企業様、および、PMO案件をお探しのフリーランスでご活躍されている向けに、弊社特設サイトを設置しています。現役コンサルタントがプロジェクトの内容やご希望など、PMOに関する様々なご相談をお伺いしております。ご興味を持っていただいた企業様、フリーランスの方のご登録をお待ちしております。

ご登録は簡単１分・お気軽にご相談ください。
◆PMO人材をお探しの企業様 ▷▷▷ PMO案件.jp for BIZ
◆PMO案件で活躍をご希望のフリーコンサルタントの方 ▷▷▷PMO案件.jp

[v057]