PMOとは、Project Management Office（プロジェクトマネジメントオフィス）の略で、プロジェクトを進めるための管理を支える組織・機能です。計画や進捗をそろえ、部門間の課題を整理し、責任者が必要な判断をできる状態をつくります。社内の部署として置かれる場合も、外部のコンサルティング会社が支援する場合もあります。
PM（プロジェクトマネージャー）が一つの案件を率いる役割であるのに対し、PMOはその運営を支えたり、複数案件に共通する管理の仕組みを整えたりします。ただし「PMOには決定権がない」とは限りません。どこまで管理し、何を決めるかは、組織が与えた権限によって変わります。
たとえば、システムの切替日が迫っているのに、営業部は新しい受注手順を決められず、開発会社は仕様確定を待っている。個々の担当者は働いていても、仕事のつなぎ目で全体が止まることがあります。PMOの仕事内容は、こうした場面で誰のどの判断が必要かを具体化すると理解しやすくなります。
PMOとは、プロジェクトの管理を支える組織・機能
PMOを一つの職種名だけで捉えると、会社による違いが分からなくなります。最初に「支援する対象」と「与えられた権限」を分けると、会議運営から全社の案件管理まで、同じ名称で呼ばれる理由が見えてきます。
一つの案件を支えるPMOと、組織横断のPMOがある
日本PMO協会は、PMOをプロジェクトマネジメントを横断的に支援する部門や仕組みと説明し、管理方法の標準化、教育、各種調整などを役割に挙げています。単に人員を追加するだけでなく、複数の人が同じ前提で仕事を進められるようにする機能です。
大きな一案件の中にPMOを置くこともできます。たとえば基幹システムの刷新で、会計、販売、在庫の各チームに別々の責任者がいる場合です。それぞれの計画が個別には成立していても、データ連携や総合テストの時期が合わなければ全体は進みません。こうした接続を管理する役割が必要になります。
一方、部門や全社のPMOでは、案件をまたぐ人員の重複、管理方法のばらつき、経営への報告形式などが対象になります。複数のプロジェクトが同じ専門家を必要とするなら、個々のPMが自分の案件だけで日程を決めても解決しません。組織として優先順位を判断する材料をそろえる必要があります。
PMOという名前だけでは権限を判断できない
プロジェクトマネジメントの専門団体PMI（Project Management Institute）に掲載された論文「PMO evolution」は、支援中心の型、ルールへの準拠を求める型、プロジェクトを直接管理する型を区別しています。また、設置範囲も個別案件、部門、全社に分けています。支援対象が広いことと、指揮権限が強いことは別の軸です。
そのため、体制図でPMOがPMの横に描かれていても、予算変更まで承認できるとは言えません。逆に、PMOの責任者に一定の案件判断が委譲されているなら、助言だけを行う組織とも言えません。役割を確かめるには、名称ではなく「誰が提案し、誰が決め、誰が実行するか」を確認します。
本記事の具体例では、PMOが状況整理と調整を行い、PMや事業責任者が与えられた権限内で判断する体制を使います。これは理解のための一例であり、すべての会社の指揮命令系統を示すものではありません。
次の図は、PMOが現場の進捗・課題を整理してPMの判断を支え、決まった方針を現場の実行へ戻す、支援型の一例です。PMOが直接指揮する体制など、別の形もあります。
PM・PMO・現場チームの違いを、意思決定で整理する
PMOを導入しても、商品やサービスの目的を決める人、現場の作業を実行する人が不要になるわけではありません。分業の効果が出るのは、責任を薄めずに、判断と実行をつなげたときです。
PMは案件を率い、PMOは管理の仕組みと判断材料を整える
以下は、発注企業がシステム刷新を進める架空の体制例です。比較表の権限はこの例に限り、実際の責任分担は会社の規程や案件の合意に合わせて決めます。
| 役割 | この例で担うこと | 仕様変更が起きた場合 |
|---|---|---|
| 事業責任者 | 事業目的・投資・重要な方針を判断 | 予算枠や開始時期の大幅な変更を承認 |
| PM | 案件全体の計画と実行を率いる | 対応案を選び、必要な承認を求める |
| PMO | 情報を整理し、管理と部門間調整を支援 | 費用・納期・他チームへの影響を集約 |
| 業務・開発チーム | 要件の具体化、設計、開発、検証を実行 | 作業量や実現方法を調査・見積もり |
たとえば現場から新機能の要望が出たとき、PMOができるのは、要望の理由、必要な作業、開始日に与える影響、決定期限を一つにまとめることです。これによって「便利そうだから追加する」という話を、「何を優先し、何を後にするか」という判断に変えられます。
ただし、現場の見積もりを確認せずにPMOだけで工数を決めると、資料上の計画と実際の仕事が離れてしまいます。担当チームが技術的な前提を説明し、PMが全体計画と照合し、必要なら事業責任者へ上げる。PMOは、その流れが途中で止まらないよう支援します。
責任の空白をなくすには、決める内容を具体化する
「課題はPMOが管理する」という記載だけでは、問題は解決しません。管理表を更新する担当者と、課題を解消する担当者は異なる場合があります。たとえばデータ移行の不具合をPMOが記録しても、修正方法を考えるのは技術担当、移行を実施してよいかを判断するのは所定の責任者です。
この分担を曖昧にすると、現場はPMOの指示を待ち、PMOは現場の回答を待つ状態になります。実務上は、課題ごとに担当者、必要な決定、判断者、期限を置くと、どこで止まっているかが分かります。担当者を置いただけで安心せず、その人に必要な情報と権限があるかも確認します。
コンサルティング会社が入る場合も、この整理は変わりません。外部の専門家が分析を行うことと、顧客企業が経営上の選択を引き受けることは別です。コンサル全体の役割と顧客との関係は、基礎記事でも説明しています。
PMOの仕事内容は、記録を判断と行動へつなぐこと
進捗表、課題表、議事録はPMOの仕事で目にしやすい成果物です。大切なのは、その書類を使ってどの迷いや滞りを減らすのかです。以下の業務例は、編集部が仕事の流れを説明するために整理したものです。
計画をそろえ、遅れの影響を確かめる
計画を立てる段階では、担当者ごとの作業を並べるだけでなく、前後関係と完了条件をそろえます。営業部の「準備完了」が説明会の実施を意味し、システム部の「準備完了」がテスト終了を意味しているなら、同じ完了という言葉でも中身が違います。
架空の販売システム刷新で考えます。開発会社は画面の実装を終えましたが、営業部が例外的な値引きの承認手順を決めていません。この状態で「開発は完了」とだけ報告すると、利用者が業務を試すテストの開始条件を満たしているように見えます。PMOは、何が終わり、何が未決かを分けて全体計画に反映します。
進捗を確認する際も、「予定より三日遅れている」という数字だけでは重要度が分かりません。その作業を待つ後工程は何か、余裕日数はあるか、他の作業を先に進められるかを担当者と確かめます。単なる督促ではなく、遅れが事業上の期限に届く前に選択肢を用意する仕事です。
ここでは担当者の報告を疑うことが目的ではありません。「完成」の定義や確認日を共有し、異なる報告を同じ基準で扱えるようにすることが目的です。現場に説明できない集計方法を使うと、数字を合わせる作業だけが増えてしまいます。
課題とリスクを分け、対応する人を決める
すでに発生している問題と、今後発生する可能性があることは、扱いを分けると整理しやすくなります。テスト用のデータが届いていないなら現在の課題です。繁忙期に営業担当者の確認時間が取れなくなりそうなら、先回りして考えるリスクです。
同じ架空例で、店舗ごとに商品コードの使い方が違うことが分かったとします。課題表に「データ不整合」と書くだけでは、誰も動けません。どの店舗のどの情報が違い、移行作業の何に影響し、業務部門と開発会社のどちらが何を決める必要があるかに分解します。
PMOは、課題の件数を減らすことだけを目標にしない方がよいでしょう。重要な問題を小さく見せたり、未解決のまま終了扱いにしたりすれば、数字は改善しても危険は残ります。対応の完了を確認する証拠と、影響を受ける相手の認識まで確かめる必要があります。
リスクについては、起きたら考えるのではなく、兆候と対応の開始条件を決めます。営業担当者がテストに参加できない可能性があるなら、代替担当を置くのか、日程を分けるのか、責任者へいつ判断を求めるのかを事前に整理します。未来を当てる仕事ではなく、対応を選べる時間を確保する仕事です。
会議を、報告の場と決める場に分ける
全員が同じ会議に出ていても、目的が「情報共有」なのか「決定」なのかが混ざると、重要事項が持ち帰りになります。PMOは、参加者と議題をそろえ、何を決める会議なのかを事前に示します。担当者では決められない事項を、担当者だけの会議で何度も議論することは避けたいところです。
議事録も、発言の再現だけでは次の行動につながりません。決まったこと、決まらなかったこと、残った選択肢、追加で必要な情報、次の判断日を分けます。特に「検討する」は、検討する人と期限がなければ状態を表すだけの言葉になってしまいます。
部門同士の対立があるとき、PMOが一方の意見を消して報告を整えるのは問題です。営業部が操作性を重視し、システム部が保守性を重視しているなら、双方の条件を残して判断者に渡します。合意していないことを、資料の表現だけで合意済みに見せない姿勢が重要です。
システム刷新の架空例で、PMOの動きを追う
ここからは、複数店舗を持つ小売企業が販売システムを刷新する架空例です。実在企業の案件や成果を示すものではありません。PMOが入る前後で、情報の集め方と判断の進め方がどう変わるかを考えます。
開始前に、目的と完了条件を合わせる
この会社の事業目的を「店舗ごとの在庫を把握し、欠品時の他店取り寄せをしやすくすること」とします。画面を予定日に公開することだけが目標になると、現場が在庫を更新しないまま、システム導入だけが完了するかもしれません。
PMOはPMと相談し、システムの完成、店舗の運用準備、データの確認を別の項目として計画に置きます。店舗責任者には新しい入力手順を確認してもらい、開発会社にはその手順を試せる環境を用意してもらいます。誰かの作業が終わったことと、利用開始できることを分けるためです。
同時に、開始日を変えられない理由も確かめます。契約上の期限なのか、旧システムの保守期限なのか、社内の希望なのかで、遅れへの対応が変わります。「絶対に延期できない」という言葉を前提にする前に、条件と判断者を明らかにします。
途中の変更を、費用・時間・目的に戻して判断する
開発中に、店舗から「スマートフォンでも在庫を更新したい」という要望が出たとします。便利な機能ですが、最初の計画には含まれていません。PMOがその場で採否を決めるのではなく、利用場面、開発とテストの追加作業、既存機能への影響を整理します。
選択肢は追加するか断るかの二つだけではありません。初回は既存端末を使い、次の段階でスマートフォン対応を行う案もあります。PMOは各案について、誰の負担がいつ発生するかを見えるようにし、PMが推奨案と理由をまとめられるよう支援します。
事業責任者が段階導入を選んだら、その決定を開発計画だけでなく店舗向けの説明にも反映します。会議では延期に合意したのに、店舗は初日から使えると思っている、というずれを残さないためです。決定を記録するだけでなく、関係者の作業に落とすところまでが一連の管理です。
切替後まで追い、次の案件に残す
システムが動き始めた後は、問い合わせの窓口、未解決事項の引継ぎ、旧手順の停止を確認します。プロジェクトチームが解散した後に残る仕事を、通常業務の担当者が引き受けられるようにするためです。引継ぎ先が決まっていない課題を、稼働開始だけを理由に閉じないようにします。
振り返りでは「連携不足だった」で終わらせず、どの決定がどの時点で必要だったかを残します。今回なら、店舗の例外業務をテスト直前に集めたことが手戻りの原因だったのかもしれません。次回は計画段階で例外業務の確認日を設ける、といった運営方法の変更につなげます。
このように、PMOの仕事は文書を増やすことだけではありません。現場で起きた出来事を、全体計画の修正、判断、実行、次回の改善へつなぎます。コンサルタントの調査や分析が実行支援とどう結び付くかは、仕事内容の記事でも紹介しています。
実際の支援事例では、どの問題に対応しているか
架空例と実案件を混同しないため、ここでは公開資料で確認できた範囲を限定して紹介します。支援会社が掲載する顧客インタビューと、発注者自身が残した実施資料では、確かめられる内容も異なります。
トヨタコネクティッド：関係者の認識をそろえる支援
マネジメントソリューションズ（MSOL）が公開する事例では、顧客のトヨタコネクティッドの担当者が、プロジェクト運営についてメンバー間に認識のずれがあったと説明しています。支援内容として紹介されているのは、プロジェクト計画書を基にした状況の可視化や、役割の明確化、タスクの整理です。
担当者は、状況を言葉や図で明確にし、タスク管理ツールも使ったことで、プロジェクトが進みやすくなったと述べています。これは支援会社のサイトに掲載された顧客担当者の説明です。独立した効果検証ではなく、削減工数や投資回収率をこの資料だけで計算することはできません。
編集部がこの事例から重視するのは、「各人が努力していること」と「全体として同じ理解で動けること」は別だという点です。担当者を増やすだけで解決するのか、役割や作業のつながりを整理する必要があるのかを見分けると、PMOに期待する仕事が具体的になります。
国立病院機構：発注者が求めたPMO支援の範囲
顧客側の資料として、国立病院機構が公開している、2016年3月付の診療情報データベース構築の標準作業手順書があります。2015年度の構築事業を基にした資料で、PMO支援の調達についても記録しています。
記載された業務には、全体計画、実施体制や連絡方法の整備、進捗管理、関係する業者との会議、報告作成の支援があります。さらに、電子カルテなどに関する知識や、システム調達・工程管理の知見を持つ事業者の選定が望ましいとしています。
この資料から分かるのは、発注者がPMOに求めた仕事の中身です。会議日程を調整するだけでなく、対象業務を理解したうえで、複数の調達や導入作業をつなぐことが求められています。過去の医療情報基盤の事例であり、現在の全業界の標準契約や、特定コンサル会社の実績として扱うものではありません。
PMOを提供する企業は、何を事業にしているのか
PMOは顧客企業の内部機能にもなりますが、外部に任せる部分はサービスとして事業化されています。提供会社を分析するときは、現場で担う役割に加えて、何が売上を生み、その仕事を提供し続けるために何が必要かを考えます。
MSOL：人材による実行支援と、ソフトウェアの展開
マネジメントソリューションズ（MSOL）は、公式サイトでPMOサービスを主事業と位置付けています。2025年12月期の決算短信では、主軸のPM事業について、PMOコンサルタント数、稼働率、平均単価を重要な管理指標に挙げています。
この指標の組合せから、編集部は、人材を確保するだけでなく、その人材が案件で稼働し、担う仕事に対して対価を得ることが事業運営上の重要点だと整理します。一人の専門家が同時に使える時間には限りがあるため、案件獲得と人材育成・配置を合わせて考える必要があります。ただし、三つの指標だけで同社の連結売上を正確に再現することはできません。
同じ短信では、プロジェクト管理ソフトウェア「PROEVER」の展開と、労働集約型からAI主導型への事業変革を目指す方針も示しています。これは会社の戦略説明であり、すでに人材依存が解消されたことを意味しません。現場に人が入る支援と、ソフトウェアを提供する事業では、顧客が購入するものや拡大の仕方が異なります。
発注側からは、支援人数の多さだけでは価値を判断できません。月次報告の作成を任せるのか、複数部門の計画を立て直すのかで、必要な経験と作業量は違います。提供会社の収益指標と、顧客案件での成果指標を混同せず、依頼する仕事ごとに確かめることが大切です。
費用を考える際も、人数だけを比べると依頼内容の違いを見落とします。説明用の架空例として、二名が三か月支援するなら投入量は六人月です。しかし、その六人月で計画の立て直しと社内への引継ぎまで行う提案と、決まった資料の更新だけを行う提案では、同じ仕事を買うことにはなりません。人月は一人が一か月働く量を表す単位であり、成果の大きさを表す単位ではありません。
また、外部費用を減らしても、顧客側の担当者が情報収集や資料修正に多くの時間を使うなら、全体の負担は減らない可能性があります。見積もりを確かめるときは、外部に任せる作業と社内に残る作業を並べ、成果物を誰が受け取り、どの状態なら支援を終えられるかまで比較します。ここでの人数・期間は説明用であり、実在企業の見積もりや料金相場ではありません。
アビーム：経営統合の専門支援にPMOを組み込む
アビームコンサルティングは、経営統合支援のサービスで、PMO・チェンジマネジメント、戦略、組織・人、業務プロセス、システムという五つの領域を示し、統合計画から実行までを支援すると説明しています。ここでのPMIは企業買収後などの経営統合を指し、プロジェクトマネジメントの団体名であるPMIとは別の意味です。
この提供範囲から、PMOが単独の管理サービスとしてだけでなく、専門的な変革支援の一部として組み込まれることが分かります。たとえば経営統合なら、人事制度の変更、業務の統一、システム統合を別々に進めるだけでは、互いの前提がずれる可能性があります。
後半の例は編集部の説明ですが、PMOが専門チーム間の仕事をつなぐ必要性を表しています。人事制度の専門家の代わりに制度を設計するのではなく、制度変更が給与システムや社員への説明に与える影響を全体の計画に結び付ける、といった役割です。
なお、ここで参照したサービスページだけでは、PMO部分の料金や売上構成までは分かりません。MSOLとの単価比較や、どちらが優れているかという順位付けはできません。比べるべきなのは、同じPMOという名称でも、何の専門業務と組み合わせて提供されているかです。
PMOが機能しない原因と、導入前に決めること
PMOを置けばプロジェクトが成功するわけではありません。PMI掲載の論文でも、役割への期待のずれや、手続きが過剰になる問題が指摘されています。以下では、そうした論点を踏まえ、編集部が導入時の確認方法を整理します。
報告の負担が、判断の改善を上回っていないか
毎週の資料を増やしても、それを使う人や決める内容が定まっていなければ、現場には入力作業だけが残ります。進捗を細かく把握したいという理由で項目を増やす前に、どの情報があれば誰が何を決められるのかを確認します。
たとえば日次で全作業の進捗率を集めるより、今週中に判断しないと後工程が止まる事項を短くまとめる方が役立つ場面があります。逆に、切替直前のように小さな変化が大きな影響を生む時期には、確認頻度を高める意味があります。管理の細かさを案件の局面に合わせて変える考え方です。
すでに開発チームが使っている管理ツールと同じ内容を、別の表へ手作業で転記していないかも確認します。目的に合う情報を既存の仕組みから取り出せるなら、報告のためだけの二重入力は減らせます。様式を統一することそのものではなく、判断できる状態を保つことを目標にします。
小さな案件で、関係者が直接話せて判断もすぐできるなら、独立したPMO組織を増やす前に、既存のPMとチームで必要な機能を担えるか検討できます。逆に、同じ規模でも関係部署が多く、承認が何段階にも分かれるなら、調整の負担は大きくなります。人数や予算だけで必要性を決めず、実際にどこで仕事が止まるかを確認する方が、過剰な管理を避けやすくなります。
専門知識、権限、情報へのアクセスがそろっているか
PMOに「全体を管理してほしい」と頼んでも、必要な会議に参加できず、計画書も見られなければ状況を把握できません。担当者へ問い合わせる窓口、情報の共有範囲、経営層へ判断を求める経路を開始前に決めます。機密情報は必要な範囲に限って共有し、管理のしやすさを理由に無制限に集めないようにします。
また、PMO担当者があらゆる専門分野を知っているとは限りません。専門家の説明を整理する能力と、技術や業務を自ら判断できる能力は別です。技術的な論点が多い案件なら、誰に専門判断を求めるかを体制に組み込みます。分からない内容をもっともらしい進捗表に置き換えないことも、管理の品質です。
外部支援を頼むときは、支援範囲、成果物、会議への参加、顧客側の役割、期間、引継ぎを具体化します。「PMO一名」という人数だけの依頼では、事務作業を期待する人と、組織改革を期待する人の間にずれが生まれます。必要な仕事を先に決め、その仕事に合う体制を選ぶ順序が有効です。
PMOの成果は、意思決定と実行の変化で確かめる
プロジェクトが成功したという結果だけで、PMOの貢献を切り分けるのは難しいものです。担当者の能力、案件の難しさ、顧客の方針変更なども結果に影響するためです。PMOが担った仕事に対応する変化を確かめる必要があります。
成果指標を、依頼した仕事と対応させる
PMI掲載のPintoの論文は、プロジェクト全体の成果とPMOの成果を分け、提供するサービスごとに指標を設ける考え方を示しています。編集部としても、PMOを一律の件数目標で評価するより、解決したい問題に合う指標を選ぶことを勧めます。
たとえば判断の遅れが問題なら、必要な情報がそろってから決定されるまでの日数を追います。部門間の依存関係が見えていないなら、後工程に影響する課題をどの時点で発見できたかを確認します。報告負担の軽減を依頼したなら、現場とPMの資料作成時間がどう変わったかを見ます。
ただし、数字だけで評価すると行動がゆがむことがあります。決定日数を短くするために検討不足のまま結論を出せば、後からやり直しが増えます。課題の発見件数が増えても、実態が悪化したとは限らず、以前見えていなかった問題が可視化された可能性があります。指標の変化と、その理由を合わせて確かめます。
支援が終わった後に、何が残るかを確認する
外部のPMOが支援している間だけ管理が回る状態では、契約が終わると元に戻るかもしれません。計画の更新方法、課題の判断経路、使う資料の意味を社内担当者が説明できるかを、終了前に確認します。単にファイルを渡すことと、運営を引き継げることは違います。
引継ぎの確認には、次回の定例会議を社内担当者が主導し、外部担当者が不足点を補う形も考えられます。そこで重要課題の見落としや、判断者への連絡漏れが起きるなら、手順書だけでは足りなかった部分が分かります。これは編集部が提案する確認方法で、すべての契約に共通する義務ではありません。
PMOを理解するときの要点は、何人配置するかより、どの管理上の問題を解決する機能なのかを確かめることです。対象範囲、判断権限、現場との分担、成果の確かめ方が具体的なら、PMOという名称の違いに振り回されず、その仕事と提供企業の価値を判断しやすくなります。
