プロジェクト管理は誰がする？外注開発での役割分担

McKinseyの分析（2012年）では、大規模ITプロジェクトは平均で予算を約45%超過し、スケジュールは約7%遅延、期待していた価値は約56%下回る[1]と報告されている。PMIのPulse of the Professionでも、プロジェクト投資の損失が一桁台では済まない規模で発生する現実が繰り返し示されてきた[2]。外注開発のプロジェクト管理においてこのリスクが増幅するのは珍しくない[3]。発注側と受注側の境界で意思決定が滞ると、仕様の解像度が落ち、優先順位が崩れ、誰もハンドルを握っていない時間が生まれるからだ。

では、プロジェクト管理は発注側と受注側のどちらが担うべきなのか。結論から言えば、単純な二者択一ではない。契約の型が定める責任分界、組織のケイパビリティ（実行能力）、プロダクトのライフサイクル段階という三つの軸を合わせて設計する必要がある。本稿では、外注開発における役割分担をこの三軸で分解し、実務に落とせる形で示していく。

ガバナンスはどこに置くか：失敗の源は境界に宿る

外注の現場で「誰がプロジェクトを管理するのか」が曖昧になると、決定の遅延が連鎖していく。ここで言うガバナンスは、意思決定と統制の仕組みのことだ。要件が揺れるのは仕様の問題だけではない。承認権限の位置が高すぎる場合、意思決定に数営業日単位の待ち時間が生まれ、ベンダー側は作業待ちを避けるために進めやすい作業に流れる。これが優先度の逸脱をもたらし、結果としてリリース価値が薄まる。逆に、過度にベンダー側に裁量を渡すと、短期の生産性は上がるがプロダクト戦略との整合が崩れやすい。

ガバナンスの置き場所を考える際に拠り所となるのは、プロダクト責任とプロジェクト責任の分離である。プロダクト責任は何を作るかを定める使命で、プロダクトビジョン、戦略、ユーザー価値、優先順位の最終判断が含まれる。これは基本的に発注側が持つべき領域だ。一方でプロジェクト責任は、決めたことをどのように納期・予算・品質の制約下で形にするかのオペレーション（実行と統制）であり、進捗管理、リスク管理、ステークホルダー調整が中心になる。この後者は、契約と体制に応じてベンダーに寄せることができる[5]。

重要なのは、どちらかを排他的に選ぶことではなく、プロダクト責任を発注側に明確に固定したうえで、プロジェクト責任を段階ごとに移譲または共同で担う設計にすることだ。意思決定の単一責任点（Single-Threaded Owner：各項目の最終判断者）を項目ごとに明示し、意思決定の最大待ち時間をSLA（Service Level Agreement：サービス水準合意）として合意しておくと、境界での停滞を最小化できる。

境界で発生する3つの遅延：決定、情報、仕様

遅延は決定遅延、情報遅延、仕様遅延の三つに大別できる。決定遅延は承認者が不在または多すぎることが原因で、これは権限委譲とエスカレーションの時限設定で抑制できる（例：二営業日を超えたら自動エスカレーション）。情報遅延は顧客データ、外部API、設計基準といった入力が発注側から出てこないケースで起こるため、提供期限をプロジェクト計画に組み込み、未達時の代替案を事前に定義する（例：テストデータの暫定利用）。仕様遅延は要件のブレに起因し、意思決定の根拠となる仮説とメトリクスをプロダクト側が先に用意することで小さくできる（例：KPIに基づく優先順位の固定）。

契約形態が決める責任分界：請負と準委任の実務

日本の商慣習で多いのは請負と準委任である[4]。請負は成果物の完成責任を受注側が負い、準委任は作業の善管注意義務を負うが成果は約束しない[4]。海外で一般的な用語に置き換えれば、前者は固定価格（Fixed-Price）、後者はタイム・アンド・マテリアル（Time & Materials; 工数従量）に近い[4]。どちらを選ぶかで、プロジェクト管理の担い手は大きく変わる。

固定価格に寄せるほど、受注側はリスクを見込んだ見積もりを行い、変更管理（スコープ変更の統制）を厳格にする。その場合、進捗・課題・リスクの統制は受注側PM（Project Manager）が前面に出ることが合理的だが、仕様の最終決定権は発注側のプロダクト責任者に残さなければ、手堅いが価値の薄い完成を招きやすい。反対にタイム・アンド・マテリアルでは、受注側はキャパシティを柔軟に供給し、プロダクトの意思決定は発注側に重く乗る。ここで発注側がPMとEM（Engineering Manager：技術責任者）の機能を持たないと、速度は出ても方向性が定まらない。

契約は管理モデルの指紋である。変更が頻出する探索フェーズは準委任寄りにしてプロダクト側がハンドルを握り、実装フェーズに入ったら一部モジュールを固定価格で切り出して受注側PMの統制を効かせるといったハイブリッドも現実的だ[4]。重要なのは、契約書に管理に関する条項を明文化することだ。具体的には、共同のステアリングコミッティの有無、定例の報告粒度、リスク登録簿の管理責任、変更要求の受付窓口、受け入れ基準と検収の判定権限といった要素を、担当者名と代行条件まで含めて書く。

検収基準と受け入れ責任：品質の最後の砦

検収は請負契約で重く、準委任でもスプリントレビューやUAT（User Acceptance Testing：ユーザー受け入れテスト）の合格条件として機能する[4]。受入基準は曖昧にしない。ユーザーストーリーの完了条件、非機能要件（性能・可用性・セキュリティなど）のSLO（Service Level Objective：目標水準）、互換性の前提、環境差異の扱い、データ移行の整合性判定などを、測定方法とともに定義する。判定の独立性を確保するには、発注側の品質責任者を明示してベンダーPMと対等に置くことが効果的だ。品質ゲートをくぐる権限がベンダー側だけに偏ると、短期の納期は守れても運用で事故が露見する。

PO・PM・EM・ベンダーPM：重なりを設計で解く

外注開発で混線しやすいのが、プロダクトオーナー（PO）、発注側PM、発注側EM、そして受注側PMの関係だ。理想は各役割の目的を明文化し、単一責任点を項目ごとに固定することに尽きる。プロダクトオーナーは価値最大化の責任者であり、ビジョン、ロードマップ、優先順位、受け入れ判断の最終責任を持つ。発注側PMはスコープ、スケジュール、コストのトレードオフを握る交渉役で、リスクの先回りとステークホルダー調整が主戦場だ。発注側EMは技術的意思決定の責任者で、アーキテクチャ、非機能、開発プロセス、リリース運用の整合を担う。受注側PMは提供スコープの実行責任者で、チームの編成、ベロシティの確保、報告と是正の運用を行う[5]。

役割は重なる。たとえば受け入れ判断はPOの責任である一方、品質に関する技術的妥当性はEMが支える。スケジュールの最終調整は発注側PMが責任を持つが、日々の進行は受注側PMが主導する。重なりを健全な緊張として機能させるには、定例の場を意図して分けることが有効だ。プロダクトゴールを扱う場と、プロジェクトの健康状態を扱う場、技術的意思決定を扱う場を分離し、同じ議題が横断するときはステアリングコミッティで紐付ける。

RACIを“文章で”持つ：運用しやすい最小単位

RACIチャート（Responsible/Accountable/Consulted/Informed：実行/最終責任/助言/通知の区分）は便利だが、表が巨大化すると誰も見なくなる。運用しやすい形は、シナリオごとの短い記述で責任の所在を固定することだ。たとえば優先順位変更のシナリオでは、POが意思決定を担い、発注側PMがコストとスケジュール影響を評価して助言し、受注側PMは影響したタスクの再計画を実行し、EMは技術的制約の可否を示す、といった一段落の文章にまとめる。障害対応のシナリオでは、受注側が一次切り分けと暫定対応を即時に行い、その報告を受けた発注側EMが恒久対応方針を決め、POはユーザー影響とアナウンス方針を確定する、といった形だ。表より短い文章のシナリオを積み重ねると、現場は迷わない。

実装に落とす：SLA/SLO、エスカレーション、メトリクス

役割分担を紙に書いただけでは回らない。運用を支えるのは、時間と事実に関する合意だ。まず意思決定のSLAを決める。優先順位変更は二営業日以内、仕様の解釈は一営業日以内、重大障害の是非判断は一時間以内といった具合に、決めないことのコストを可視化して時限を付ける。次にサービスレベル目標を合わせる。可用性、応答時間、デプロイ頻度、リードタイム、変更失敗率といった指標は、プロダクトの性質に応じて現実的な水準を置く[6]。開発の健全性はDORA系メトリクス（DevOps Research and Assessmentによるベンチマーク：デプロイ頻度、変更リードタイム、復旧時間、変更失敗率）が通用する領域が広い[7]。最後に、エスカレーションの経路を一本化する。決定が滞ったら何時間で誰に上げ、どのチャネルを使うのかを一目で分かるようにし、全員が同じ経路図を持つ。

メトリクスは数値だけでなく語られるべき物語でもある。ベロシティが上がっていても、価値のある機能が出荷されていなければ意味はない。そこで、ビジネス成果の代理指標をプロダクト側が提供することが重要になる。たとえば、アクティブユーザーの増減、オンボーディング時間の短縮、チャーン抑制、問い合わせ件数の減少など、プロダクトのゴールに直結する指標を月次のレビューで語る。その上で、プロジェクトの健康状態として、期限遵守率、クリティカルパスの消化状況、リスクの検知と対処のリードタイムを報告する。こうして価値と実行の二枚看板で運転する体制が整う。

ケースで学ぶ配置：スモール、刷新、多ベンダー

小規模な新規プロダクトでは、POが発注側でフルタイムに近いコミットを行い、受注側はEM兼テックリードとPMが小さく強いチームを組む。バックログの受け入れ判断をPOが迅速に下し、仕様の解釈のSLAを短く設定すれば、探索と実装を高速に回せる。レガシー刷新（モダナイゼーション）のように非機能要件が支配的な領域では、発注側EMを最前線に出し、アーキテクチャ決定の単一責任点をEMに寄せる。受注側PMは移行計画や段階的リリースのカットオーバーを強くドライブし、POはユーザー影響の緩和策と機能フリーズの窓口に集中する。多ベンダー体制では、発注側PMO（Project Management Office）を置き、共通の定義とインテグレーション規約を先に整える。各ベンダーPMは自チームを最適化しがちなので、統合テストと環境の責任を単独のチームに持たせることで、境界の摩擦を抑えられる。

いずれのケースでも、共通して効くのは、意思決定の粒度を小さくして早く回すことと、領域ごとの単一責任点を固定することだ。肩書きではなく、シナリオに沿った責任の割り当てを文書化し、時限付きの判断とメトリクスで運用を支える。こうした地味な仕込みが、外注という境界に横たわるリスクを静かに減らしていく。

まとめ：境界の設計が速度と価値を両立させる

外注開発で「誰がプロジェクトを管理するのか」は、契約、組織、工程の三つを束ねる設計課題だ。プロダクト責任は発注側に固定し、プロジェクト責任は契約と段階に応じて移譲や共同に振る。RACIは巨大な表ではなく、シナリオごとの短い文章で現場に落とす。SLAとSLOで時間と品質の合意を結び、エスカレーション経路とメトリクスで運転を安定させる。これらを実行に移せば、ベンダーの実行力と事業側の意思決定力が噛み合い、価値と速度の双方を取りにいける。

明日からの一歩として、まずは現在進行中の案件で決定が滞りがちな場面を書き出し、各場面の単一責任点と判断のSLAを文にして合意してみてほしい。誰がどの場面でハンドルを握るのかが明確になれば、チームは迷わない。次のスプリントレビューで、あなたのプロジェクトはどの境界を一つ縮められるだろうか。

参考文献

Bloch M, Blumberg S, Laartz J. Delivering large-scale IT projects on time, on budget, and on value. McKinsey Digital, 2012. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
PMI. Pulse of the Profession 2013: The High Cost of Low Performance. https://www.pmi.org/learning/library/2022/07/01/21/01/en-2013-pulse-high-cost-low-performance-13511
日本プロジェクトマネジメント学会誌特集「アウトソーシング」SPM研究第4巻第2号. J-STAGE. https://www.jstage.jst.go.jp/browse/spmj/4/2/_contents/-char/ja
IPA（情報処理推進機構）. 情報システム・モデル取引・契約書（第二版）. https://www.ipa.go.jp/ikc/reports/contract-model.html
Project Manager Roles in IT Outsourcing. ResearchGate. https://www.researchgate.net/publication/276094930_Project_Manager_Roles_in_IT_Outsourcing
Betsy Beyer et al. Site Reliability Engineering: Service Level Objectives. Google SRE Book. https://sre.google/sre-book/service-level-objectives/
Forsgren N, Humble J, Kim G. Accelerate: The Science of Lean Software and DevOps. IT Revolution, 2018. https://itrevolution.com/product/accelerate/