システム開発のPMO支援とは：役割、支援範囲、外部PMOの選び方

PMOとは：PMとの違い

PMO（Project Management Office）とは、プロジェクトを進めるための管理の仕組み（標準、計画、進捗・リスク・品質の監視、報告）を整え、プロジェクトマネージャー（PM）や発注者の意思決定を支える組織・機能です。PMが一つのプロジェクトを率いて目標の達成に責任を持つのに対し、PMOはプロジェクトを横から見て事実を集め、問題を早く見つけて関係者に知らせます。

プロジェクトマネジメントの標準として参照されるのが、PMI（Project Management Institute）の「PMBOKガイド」です。第8版は「The Standard for Project Management」（ANSI/PMI 99-001-2025）を含み、6つの原則と、40のプロセスを含む7つのパフォーマンス領域（ガバナンス、スコープ、スケジュール、ファイナンス、ステークホルダー、リソース、リスク）で構成されています（名称は英語版の目次からの当社訳）。PMIが公開している目次では、付録X2がPMOに充てられ、PMOの価値提案、類型・モデル・構造、成熟度モデルなどを扱っています。

PMOの5つの類型

PMIの調査報告「PMO Frameworks」（2013年11月）は、実務でよく見られるPMOを次の5つの類型に整理しています。

• 部門型PMO：事業部門や部署に、ポートフォリオ管理、ガバナンス、プロジェクト運営の支援などを提供する
• プロジェクト専任型PMO：特定のプロジェクトやプログラムのために一時的に置かれ、データ管理、ガバナンスと報告の調整、事務的な支援を行う
• プロジェクト支援型PMO：組織が定めたプロセスやツールを使い、組織全体のプロジェクト業務を継続的に支援する
• 全社型PMO：最上位のPMOとして、戦略との整合、全社的なガバナンス、ポートフォリオ管理を担う
• センター・オブ・エクセレンス（CoE）：方法論、標準、ツールを整備し、組織の遂行能力を高める

外部PMOが必要になる場面

外部PMOが役立つのは、プロジェクトの規模や難度、関係者の多さに対して発注者側の管理の手が足りないとき、または利害から離れた第三者の目が必要なときです。代表的な場面は次のとおりです。

• 勘定系などの基幹システムの更改・統合のように、障害時の影響が大きく、高い専門性が必要な大規模プロジェクト
• 複数のベンダーが別々に開発し、システム全体の整合や日程の調整を発注者が担うマルチベンダ体制
• 規制対応の期限や制度変更の施行日など、動かせない期限があるプロジェクト
• 長年運用してきたシステムの再構築で、現行の仕様を知る担当者や設計書が失われている場合
• オフショア拠点を含み、言語、時差、組織をまたいで開発する体制
• 進行中のプロジェクトで遅延や品質の問題が見え始め、現状を客観的に評価したい場合

マルチベンダ体制について、IPAの「情報システム・モデル取引・契約書」第二版は、発注者が開発を複数のベンダーに分割発注している場合、ソフトウェア間の機能の整合性、開発スケジュールの調整、ベンダー間の進捗管理と調整は発注者（ユーザ）が責任を負うと定めています（第13条）。そして、複数ベンダーを統制する能力がユーザ側に十分ない場合のリスク軽減策として、全体管理・調整業務を外部に委託することを挙げています。

再構築についてIPAは、長年運用してきたシステムでは業務知識（ドキュメントと有識者）が失われていることが多く、要件定義の前に現行システムを調査する必要があると指摘しています。この調査が不十分なまま着手し、後の開発段階でトラブルに陥った事例が多数報告されているとしています。

PMO支援の範囲：何を任せられるか

PMO支援の範囲は、計画・スコープ、スケジュール、リスク・課題、品質、予算、報告と会議体、レビューの7つに大別できます。最初に、どこまでを外部PMOに任せ、どの判断を発注者に残すかを決めておくことが重要です。

会議体の設計では、IPAのモデル契約が参考になります。第二版は、発注者とベンダーが連絡協議会を定期的に開いて進捗状況、リスクの管理と報告、問題点の協議と解決などを協議し、ベンダーが進捗管理報告を提出して議事録を作成すると定めています（第12条）。PMOは、この会議体の運営を支え、報告の形式をそろえ、決定事項が実行されるまで追跡します。

金融機関のシステム更改とPMO：金融庁の障害分析から

金融機関のシステム統合・更改では、再委託先を含む管理態勢、流用した仕様の影響調査、有識者によるレビュー、テスト計画の合意、移行とリリースの判定が、PMOのとくに重要な確認対象です。金融庁が公表した障害事例で、これらが原因として挙げられているためです。

金融庁の「金融分野におけるITレジリエンスに関する分析レポート」（2025年6月）によれば、2024年度（2024年4月から2025年3月）に金融機関から報告されたシステム障害は約1,800件で、「ソフトウェア障害」と「管理面・人的要因」による障害が全体の約7割を占めました。

同レポートは、金融機関のシステム統合・更改は障害時の影響が大きく、必要な知識の専門性も高いため「プロジェクト遂行の難度が高い」とし、課題として、再委託先を含むプロジェクト管理態勢の整備、システム仕様書などの開発文書の整備、レビューアとしての有識者の適切な配置によるレビュー体制の整備を挙げています。2024年度にも、勘定系システムの更改で別のプロジェクトのATM仕様を流用した際、仕様差異の理解や影響調査が不足し、一部のATMが起動しない障害が起きています。

同レポートの補論（事例集）には、システム統合・更改に伴って発生した障害として18の事例が掲載されています。次の表は、その一部の原因と対策を、PMOが確認できる項目に置き換えたものです。

同じ事例集では、ある資金清算機関の事例の対策として、CIOの設置による事務局体制の強化などとともに「外部目線によるチェック強化」が挙げられています。

工期・品質・コストの指標：JUASのソフトウェア・メトリクス

PMOが計画や見積りの妥当性を確かめるには、自社の実績に加えて業界の統計と比べるのが有効です。日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」のガイドブック（2025年4月）は、ユーザー企業の回答をもとに、品質・費用・工期の主な指標を示しています。

JUASの分析からは、管理のやり方が結果に表れることも読み取れます。実績工期が標準工期以下だったプロジェクトのユーザー総合テストでの平均欠陥数は20.92で、標準工期を超えたプロジェクト（39.55）の約半分でした。JUASは、工程別の工期を管理しているプロジェクトの方が工期を抑えやすい傾向があるとみています。納期を優先したプロジェクトの74.5%は予定工期までに完了し、他の事項を優先したプロジェクト（61.6%）を上回りました。

品質では、品質目標を示したプロジェクトの換算欠陥率（0.2）は示さなかったプロジェクト（0.23）より低く、要求仕様に大きな変更があったプロジェクトの平均換算欠陥率（0.481）は、変更がなかったプロジェクト（0.192）の2倍以上でした。品質目標を数値で合意し、仕様変更を変更管理の手続きに乗せることは、PMOが最初に整えるべき仕組みです。

オフショア開発を含む体制のPMO

オフショア開発を含む体制では、PMOは、発注者、国内のベンダー、海外の開発拠点の間で、仕様の伝え方、進捗と品質の見える化、変更管理を一本化します。距離、言語、時差、契約の階層が増えるほど、問題が発注者に届くまでに時間がかかるためです。主な作業は次のとおりです。

• 仕様と受入基準を文書で確定し、質問と回答を一つの管理表で扱う
• 進捗を作業時間ではなく、完了した成果物とテスト結果で測る
• 時差を踏まえて定例会の時間を決め、エスカレーションの経路と期限を明文化する
• 再委託を含む体制図、要員のスキル、各工程のレビュー体制を発注者が把握できるようにする
• テスト環境とテストデータの扱い、海外拠点からのアクセス権限など、情報セキュリティの要件が契約と運用の両方で守られているかを確認する

契約面では、IPAのモデル契約第二版が、再委託にユーザの事前承諾を必要とする案と、再委託先の選定を原則としてベンダーの裁量とする案（ユーザは中止を求めることができる）の両方を用意しています（第7条）。海外拠点が再委託先にあたる場合は、どちらの案で契約しているかをPMOが確認し、承諾や報告の手続きを運営に組み込みます。

契約形態：請負と準委任、PMOの位置づけ

外部PMOの契約は、成果物の完成ではなく専門家としての業務の遂行を対象とするため、準委任契約が基本です。IPAのモデル契約第二版も、マルチベンダ形態でユーザの全体管理・調整業務を外部に委託する場合、その契約形態は準委任契約とすべきだとしています。

IPAの解説によれば、請負ではベンダーが仕事の完成義務を負い、準委任では善管注意義務（善良な管理者の注意をもって業務を処理する義務）を負うものの、完成義務は負いません。モデル契約は工程ごとに次の契約類型を基本としています。

モデル契約は工程ごとに委託料を個別契約で定める多段階契約を採り、前の工程の結果を踏まえて次の工程を見積り直せるようにしています。解説には、請負にすると発注者側に「丸投げ」の意識が強くなる場合があるという指摘もあります。PMOは、契約類型と責任分担が実際の体制や作業と合っているかを確認します。

第二版の検討では、裁判例でベンダーの「プロジェクトマネジメント義務」とユーザの「協力義務」がよく問題になっていることが議論されました。IPAはこれらを条項として加えることは見送り、ユーザとベンダーは双方ともプロジェクトマネジメントを行う必要があり、各フェーズで自らの役割を踏まえることが重要だと整理しています。外部PMOを入れても、発注者のプロジェクトマネジメントの責任はなくなりません。

アジャイル開発については、IPAが2020年3月にアジャイル開発版のモデル契約を公開しています。スクラムを採用し、成果物の完成に対価を払う請負ではなく、業務の遂行に対価を払う準委任契約を前提としています。プロダクトオーナーはユーザ企業が、スクラムマスターはベンダー企業が選任し、契約前チェックリストでは、1チーム（最大で10名程度）で継続的に開発できる規模か、完了基準と品質基準が明確かなどを確認します。

外部PMOの選び方：8つの確認点

外部PMOは、同種のプロジェクトでの経験、発注者の側に立てる独立性、報告の具体性、体制と契約の明確さで選びます。資格は知識の目安ですが、決め手は同種案件での実務経験と、悪い知らせを早く正確に伝える姿勢です。

1. 同種の経験：業界（金融機関など）、システムの種類（基幹系の更改や移行など）、規模、開発手法での実務経験があるか
2. 独立性：開発ベンダーと同じ会社がPMOを担う場合、利害の衝突をどう防ぐか（IPAのモデル契約も、全体管理・調整業務をマルチベンダとは別の事業者が受ける場合と、その一社が受ける場合の両方を想定しています）
3. 報告の具体性：状況報告書の見本で、遅延やリスクが事実と数値で書かれているか
4. 指標：自社の実績やJUASのような業界統計で、計画と見積りの妥当性を説明できるか
5. 体制：担当者の役割と稼働量、交代時の引き継ぎ、オフショアや再委託を含む体制への対応
6. 契約：準委任か成果物型か、業務範囲、報告と会議体、責任の範囲が明確か
7. 情報セキュリティ：機密情報とアクセス管理のルールがあり、ISO/IEC 27001などの認証を取得しているか
8. 資格：PMIのPMPなどの資格を持つ担当者がいるか（資格と試験の情報はPMI日本支部が提供しています）

支援の範囲が決めにくいときは、まず進行中のプロジェクトの現状評価から始め、その結果を見て継続的な支援の範囲を決める方法もあります。

findnのPMO支援

株式会社findn（東京都千代田区）は、プロジェクトマネジメントの領域で、PMO、計画とスコープの定義、スケジュール管理、リスク・品質管理、予算管理、ステークホルダーへの報告を支援しています。あわせて、要件定義から設計、テスト、運用、モダナイゼーション、オフショア開発までのシステム開発と、FISC安全対策基準やCOBITなどのITガバナンスに関するITコンサルティングを提供しています。ISO/IEC 27001:2022の認証を取得しており、代表取締役のサラワナ・プラタープ（CISA）はIT分野で25年以上の経験を持ち、2005年に来日し、国内外の大手証券会社のIT業務に携わってきました。