マルチベンダー開発の調整術｜複数外注先を動かす発注者の運用手順

「A 社からの仕様変更を B 社が把握しておらず、結合テストで全部止まった」「定例会では各社が互いを牽制するだけで何も決まらない」「障害が起きるたびに、なぜか発注者である自分が技術的な仲裁役を求められる」――こうした状況に毎週消耗していないでしょうか。

複数のベンダーに分割発注する「マルチベンダー体制」は、ロックイン回避や得意領域の最大化といった戦略的なメリットがある一方で、運用フェーズに入った瞬間、発注者の現場担当者に重い調整負荷がのしかかります。社内に専任 PM がいない中小・中堅企業では、企画責任者や情シス課長が伝書鳩・板挟み・技術判定者の三役を兼ねざるを得ず、本来の業務時間が失われていきます。

ここで難しいのは、「マルチベンダーとは何か」「PMO を置きましょう」といった概念論ではなく、「明日からの定例会で何を議題にするか」「結合テストでベンダー同士が責任を押し付け合ったときに、自分が技術判定者にならずに済む手順」といった、現場運用の具体的な判断基準が必要だという点です。多くの解説記事は契約段階・体制構築段階に焦点を当てており、運用が始まった後の調整実務までは降りてきません。

本記事では、すでに複数ベンダーに発注済みで運用が始まっている発注者を想定し、調整負荷の構造的な原因を整理したうえで、調整体制の 3 レイヤー設計、依存関係マップの作成、ベンダー横断の課題管理ルール、結合テスト・本番障害時の責任切り分け手順、専任 PM を社内に置けない場合の選択肢、そして月次の改善サイクルまで、明日から持ち帰って使える実務手順を解説します。

マルチベンダー開発で発注者が抱える典型的な調整課題

最初に、なぜマルチベンダー体制で発注者が消耗するのかを構造的に整理します。「自分の運用が悪い」のではなく、体制そのものが調整負荷を発注者に集中させる構造を持っている、という前提を共有することから始めます。

マルチベンダー体制とは何か

マルチベンダー体制とは、システム開発・運用において、複数の外注先（ベンダー）に役割を分割して発注する体制を指します。たとえば「フロントエンド開発を A 社」「バックエンド・API を B 社」「インフラ・運用保守を C 社」「データ連携・ETL を D 社」のように分けるイメージです。

シングルベンダー体制（1 社にすべて任せる）と比較したとき、最大の構造差分は「ベンダー間に上下関係や横断指揮命令系統が存在しない」点にあります。シングルベンダーであれば一次請けが内部の作業分担や課題管理を自社で完結させますが、マルチベンダーでは各社が並列で発注者と契約しているため、ベンダー間の調整は契約上、誰の責任でもありません。この空白を埋める役回りが、自然と発注者に流れ込んできます。

発注者が「伝書鳩」になる 3 つの構造要因

調整負荷が発注者に集中するのには、3 つの構造的な原因があります。

第一に、単一の指揮命令系統が存在しないことです。各ベンダーは自社の契約範囲のみに責任を負い、他社の作業に口出しする立場にありません。「A 社が遅れているので B 社の作業がブロックされている」と把握できても、B 社から A 社に直接催促することはできず、必ず発注者を経由する必要が生まれます。

第二に、ベンダー各社の最適解が衝突することです。A 社は「API を REST で公開したい」、B 社は「GraphQL で受け取りたい」、C 社は「運用負荷を考えると同期処理は避けたい」――各社にとって正しい主張が、組み合わせると相互に矛盾するという状況が常に起こります。発注者は技術的に最適な判断を下せる立場にないことが多く、判断を保留している間に各社の作業が止まります。

第三に、結合点で責任の真空地帯ができることです。A 社の出力を B 社が受け取る設計の場合、エラーが起きたときに「うちは仕様通り送った」「いや受け側のパラメータ解釈が間違っている」という主張の応酬になりがちです。契約書には自社モジュールの責任しか書かれておらず、結合点の責任は誰にも明確に割り当てられていないことが多いのです。

課題が顕在化しやすい 4 つのタイミング

これらの構造的負荷は、プロジェクトの全期間で均等に発生するわけではなく、特定のタイミングで集中して顕在化します。

1. 要件確定後の仕様変更: 一度合意した仕様が変更された際、A 社の変更を B・C・D 社にどう周知し、影響範囲を誰が評価するかが曖昧になる
2. 結合テスト: モジュール単体テストでは見えなかった結合点の不整合が一気に表面化し、原因切り分けに発注者が巻き込まれる
3. 本番障害: 障害発生時にどのベンダーが一次対応するか、ログ提出のフォーマットや時間制限が決まっておらず、対応開始が遅れる
4. スコープ追加交渉: 新機能追加時に「これは A 社の追加開発か、B 社の調整か」の切り分けで、各社の見積もり前段階で長期化する

これら 4 つのタイミングを事前に想定し、運用ルールを準備しておくことが、調整負荷を下げる最初のステップになります。

情報システム開発における失敗事例の体系的整理は、財務省財務総合政策研究所の情報システム開発 トラブル事例と対応法（PDF）にもまとまっており、結合点での責任曖昧化はマルチベンダー特有の構造的問題として古くから指摘されています。

調整体制を設計する3つのレイヤー

個別の運用手順に入る前に、調整体制全体を整理する枠組みを共有します。マルチベンダーの調整体制は、役割の異なる 3 つのレイヤーで切り分けて設計することをおすすめします。混在したまま運用すると、すべてが発注者の業務に集中してしまうためです。

ガバナンス層（ステアリングコミッティ）

ガバナンス層は、プロジェクト全体の方向性・予算・スコープ変更・重大課題のエスカレーション判断を担うレイヤーです。会議体としては「ステアリングコミッティ」「経営会議」「プロジェクト統括会議」などの名称で呼ばれます。

• 頻度: 月 1 回（または重大課題発生時の臨時開催）
• 参加者: 発注企業の経営層またはプロジェクトオーナー、各ベンダーの責任者（営業責任者・事業部長クラス）
• 決議事項: 予算追加・スコープ変更・重大なスケジュール変更・契約変更・エスカレーション課題の最終判断
• 議事録: 決議内容を文書化し、参加者全員の合意を取る

ガバナンス層で重要なのは、「日常運用の課題」をここに持ち込まないことです。日常運用は次の運用層で処理し、ガバナンス層には「運用層で解決できない・解決すべきでない」課題のみを上申するルールにします。これを徹底しないと、ガバナンス層が課題報告会になり、本来の意思決定機能が失われます。

運用層（プロジェクト推進会議）

運用層は、日々の進捗確認・課題管理・依存関係調整を担うレイヤーです。会議体としては「週次進捗会議」「プロジェクト推進会議」などの名称になります。

• 頻度: 週 1 回（プロジェクトのフェーズによっては週 2 回）
• 参加者: 発注者側の窓口担当者、各ベンダーの PM・リーダークラス
• 議題: 全体スケジュール進捗・依存関係マップの更新確認・課題チケットレビュー・次週のリスク確認
• 議事録: 決定事項・宿題事項・担当者・期限を明文化

運用層の運営で最も避けるべきは、「各社が順番に進捗報告をするだけの会」になることです。それでは情報共有はできても、ベンダー間の調整は進みません。後述する依存関係マップと課題管理ルールを使い、「他社の作業がブロックしている依存」「他社の判断を待っている課題」を中心に議論するアジェンダ設計が必要です。

技術判定層

技術判定層は、本記事で最も強調したいレイヤーです。「A 社と B 社の主張が技術的に割れたときに、どちらが正しいかを判定する」役割を担います。

ここで重要なのは、この役割を発注者が引き受けてはいけないということです。発注者がこの役割を兼ねると、各社の主張を技術レベルで評価する負担が常時のしかかり、判断を間違えれば責任も負わされます。これが、発注者が消耗する最大の原因です。

技術判定層の設計には、おおまかに 3 つのパターンがあります。

中小・中堅発注者では ③ が成立しないことが多く、② のフルスペック契約も予算的に難しい場合、後述するように外部 PM 人材を時間契約で部分的に活用する選択肢が現実的です。

複数ベンダーの作業依存を可視化する依存関係マップの作り方

調整体制が整ったら、次に必要なのが「どの作業がどの作業を待っているのか」を可視化する依存関係マップです。これがないと、「A 社の対応待ちです」「B 社から仕様が来ません」という個別報告が並列に上がってきて、発注者が頭の中で組み合わせて整理する負担が発生します。

依存関係マップに記載する 6 つの項目

依存関係マップは、エクセルまたはスプレッドシートで十分です。専用ツールは不要で、各ベンダーが閲覧・更新できる形式であれば構いません。記載すべき最小限の項目は以下の 6 つです。

ここでのコツは、「自社（自ベンダー）に閉じる作業」は記載対象外にすることです。記載すべきは「他社の作業に依存している、または他社の作業をブロックしている可能性がある作業」のみに絞ります。すべての作業を載せると更新負荷が爆発し、誰も更新しなくなります。

週次定例会での更新運用

依存関係マップは、運用層の週次定例会の冒頭 10 分で必ずレビューします。発注者が画面共有しながら一覧を提示し、「先週から状態が変わっていない作業」「期限超過の作業」「ブロック中の作業」の 3 つを順に確認します。

更新は会議直前ではなく、会議の前日 17 時までに各ベンダーが自社担当行を更新するルールにします。会議中に更新を始めると時間を浪費するため、会議は「更新済みの内容に基づいて議論する場」と位置付けます。

依存ブロックが発生したときのエスカレーション基準

「ブロック中」状態が発生した場合の対応ルールも事前に決めておきます。発注者が毎回判断していると、その都度の負担が大きいためです。おすすめする基準は以下の通りです。

• 24 時間ルール: 軽微な情報待ち（仕様確認・パラメータ確認）は、ブロック発生から 24 時間以内に発注者経由で関係ベンダーに転送する。同日中の回答を目安に設定
• 48 時間ルール: 設計判断・技術判定が必要な依存は、ブロック発生から 48 時間以内に技術判定層（リードベンダーまたは外部 PM）に持ち込み、判定会議を設定
• 5 営業日ルール: 解決の見通しが立たない依存は、5 営業日以内にガバナンス層（ステアリングコミッティ）にエスカレーション候補として上申

時間制限を機械的に運用することで、「いつ動くべきか」を発注者が毎回判断する負担がなくなります。

ベンダー横断の課題管理ルールを統一する

複数ベンダーがそれぞれ Jira / Backlog / Redmine / Notion / Excel を使っている、というのはマルチベンダー現場ではむしろ標準です。これを「全社で一つのツールに統一する」のは契約・運用慣習・追加コストの観点から現実的ではありません。

そこで現実解として、ツールは統一せず、発注者に上申する課題チケットのフォーマットだけを統一するアプローチを取ります。各社は自社内では好きなツールで運用し、発注者経由で他社に影響する課題のみ、統一フォーマットに転記してエスカレーションするルールです。

統一すべき 10 項目

統一フォーマットに含める項目は、以下の 10 項目を目安にします。

このフォーマットを発注者側で 1 枚のスプレッドシート（または共有ドキュメント）に集約し、毎週レビューします。

優先度の定義を 4 段階で統一

優先度は、各社が独自に判断するとバラバラになるため、判定基準と対応 SLA（サービスレベル合意）を発注者側で定義して共有します。

「緊急」と「高」を乱発するベンダーが出てきがちなので、月次でレビューし、過剰な優先度設定があれば運用層会議で個別調整します。

週次レビュー会議の運用テンプレート

週次定例会の中で、課題管理レビューに割く時間配分の目安は以下です。

• 0〜10 分: 依存関係マップ更新確認
• 10〜25 分: 緊急・高優先度チケットのレビュー（全件）
• 25〜35 分: 中優先度チケットのうち期限超過・ブロック中のもののみ
• 35〜45 分: 来週のリスク・スコープ追加要望の確認
• 45〜60 分: 個別フリーディスカッション

低優先度チケットはこの場では扱わず、月次レビューに回します。週次の時間を 1 時間に収めるためには、低優先度を切り捨てる勇気が必要です。

ベンダーとのコミュニケーション設計をより掘り下げて理解したい場合は、PMO 体制設計の体系的な整理を提供しているNTTデータ経営研究所のPMOの体制を5つの視点から考えるも参考になります。

結合テスト・本番障害で責任が曖昧になったときの切り分け手順

ここからが本記事の核心です。マルチベンダー体制で最も発注者が消耗するのが、結合テスト時・本番障害時の責任切り分けです。「うちは仕様通り動いた」「いや受け側のパラメータ解釈が違う」という主張の応酬を、発注者が技術的に裁こうとした瞬間、長時間の調査・判断責任・各社からの不満を背負い込むことになります。

これを避けるための 4 ステップ + 事前合意 1 つを解説します。

ステップ 1: 事実情報を全ベンダーから同フォーマットで集める

責任切り分けで最初にやるべきは、主張（解釈）と事実（ログ・タイムスタンプ・データ）を分離することです。各ベンダーには「あなたの解釈・原因仮説は不要、まず事実情報のみを以下のフォーマットで提出してほしい」と依頼します。

集めるべき事実情報は最低限以下の通りです。

• 発生日時（タイムスタンプ・タイムゾーン明記）
• 自社モジュールの該当処理ログ（前後 5 分間のフル抜粋）
• 入力リクエストの全文（HTTP リクエスト・パラメータ・ヘッダ）
• 自社モジュールの出力レスポンスの全文
• 該当時刻のシステム負荷状況（CPU・メモリ・接続数）

この段階では「誰が悪いか」の議論は禁止し、事実情報の収集に専念させます。発注者は事実を集約し、時系列で並べた一覧を作成します。

ステップ 2: ベンダー間の直接対話の場を発注者がセッティングする

事実情報が揃ったら、関係ベンダーの技術担当者を集めた直接対話の場を発注者が設定します。ここで重要なのは、発注者は議論を仲裁・判断するのではなく、議論の場を提供し、合意形成のファシリテーションのみを行う点です。

会議の進め方は以下のシンプルなアジェンダで進めます。

1. 発注者が時系列で事実情報を共有（5 分）
2. 各ベンダーが自社モジュールの動作状況を説明（各 5〜10 分）
3. ベンダー間で原因仮説を出し合い、追加検証が必要な項目をリストアップ（20 分）
4. 追加検証の担当・期限を決める（5 分）

発注者が技術的判断を求められた場合は、「現時点では判断材料が不足しているため、ベンダー間で追加検証してほしい」と引き取らず、ベンダーに返します。これが「自分が技術判定者にならない」ための最重要ルールです。

ステップ 3: 一次切り分け結果を文書化し全社で合意を取る

ベンダー間対話で一次切り分けの仮説が出たら、発注者が議事録として文書化し、全社の合意を取ります。「合意を取る」ことが極めて重要で、口頭の同意だけでは後日「あれは仮説で合意ではない」と覆されるリスクがあります。

議事録には以下を含めます。

• 切り分け結果（どのモジュールのどの処理が原因と推定されるか）
• 推定根拠（どの事実情報を根拠としたか）
• 修正対応の担当ベンダー・期限
• 再発防止策の検討担当・期限
• 反対意見があるベンダー名（あれば）

全社からの「合意」または「異議あり」の返答を 48 時間以内に求め、48 時間以内に異議が出なければ合意成立とみなします。

ステップ 4: 解決しない場合の独立第三者検証

ステップ 3 で合意が取れない、または切り分け結果が技術的に判定不能な場合は、独立第三者による検証を依頼します。これは追加コストが発生するため、ガバナンス層（ステアリングコミッティ）にエスカレーションして判断を仰ぎます。

第三者検証の発注先候補は以下です。

• 開発に関与していない別の技術コンサル会社
• 該当技術領域に特化したフリーランスの技術アドバイザー
• クラウド・データベースなど該当基盤のベンダー公式サポート（該当する場合）

費用感は、調査内容にもよりますが、簡易な切り分けで数十万円、詳細な原因究明で 100〜300 万円程度が一般的です。これを「ベンダー間で押し付け合って 1 ヶ月失う」コストと比較し、ガバナンス層で判断します。

責任分担マトリクス（RACI）の事前合意

ステップ 1〜4 の手順は障害発生「後」の対応ですが、これを円滑に回すためには、障害発生「前」に責任分担マトリクス（RACI）を全社合意しておくことが理想です。

RACI とは、各タスクについて以下の 4 つの役割を割り当てる手法です。

• R (Responsible): 実作業を担当する者
• A (Accountable): 最終責任を負う者（1 タスクに 1 人のみ）
• C (Consulted): 助言・情報提供を求められる者
• I (Informed): 結果を通知される者

「ユーザー認証 API の障害一次対応」のように粒度を揃え、各社の役割を 1 枚の表に整理しておきます。障害発生時に「この表を見れば一次対応は B 社」と即座に判断でき、対応開始までの時間を短縮できます。

詳細な切り分け手順や RACI 設計に踏み込んだ事例は、SI 業界の現場知見をまとめたマルチベンダ体制による大規模サイト開発プロジェクトを成功に導くポイント（WEBSAS）も参考になります。

専任 PM・PMO を社内に持てない場合の選択肢

ここまで紹介した手順を発注者ひとりで回すのは、現実的には負荷が大きすぎます。中小・中堅企業で社内に専任 PM・PMO を抱えられない場合、外部リソースを部分活用する選択肢を検討する価値があります。3 つのパターンを比較します。

リードベンダーに PMO 機能を委ねる

最もシンプルなのは、契約済みのベンダーのうち最も影響範囲が広い 1 社（多くの場合バックエンド・基盤を担当する社）に PMO 機能を有償で追加委託する方法です。

メリット:

• 技術理解が深く、即座に立ち上がる
• 追加契約手続きが軽い（既存契約の追加範囲として扱える）
• コストは月額数十万円〜100 万円程度に収まることが多い

リスク:

• 利益相反: PMO を担うベンダー自身が他社との結合点を持つ場合、自社に有利な判定をするインセンティブがある
• 他ベンダーの心理的反発: 「同じ立場の業者に統制されたくない」という心理が生まれやすい

利益相反リスクを抑えるためには、技術判定が割れた際に「PMO ベンダー自身が当事者の場合は判定権限を発注者に返す」というルールを契約書に明記しておきます。

外部 PM 人材（フリーランス・複業）を活用する

近年現実的な選択肢として広がっているのが、フリーランス PM・複業 PM を時間契約で部分活用する方法です。週 2〜3 日稼働、月 40〜80 時間程度で契約するイメージです。

メリット:

• 利益相反なし（特定ベンダーと利害関係を持たない）
• コストが PMO 専門会社より低い（月 40〜80 万円程度のレンジが多い）
• 必要なフェーズ（結合テスト期間など）に限定して稼働させられる

リスク:

• 人選が重要（マルチベンダー経験・該当技術領域経験の確認が必須）
• 契約形態が業務委託になるため、指揮命令関係の整理が必要（業務委託で適法な指揮命令の範囲とは何かも併せて参照すると安全です）

選定の観点としては、過去のマルチベンダー PM 経験（できれば 3 プロジェクト以上）・該当業界知識・コミュニケーションスタイル（中立性）の 3 点を必ず面談で確認します。

外部 PM 人材を活用する企業が増えている背景には、フリーランス・複業のエンジニアや PM が増加し、必要なフェーズだけ柔軟に稼働してもらえる労働市場が整ってきたことがあります。発注プラットフォームを通じた人材活用については、発注者向けのお役立ち資料を後述のリソースから参照してください。

PMO 専門会社の活用

大規模プロジェクト（プロジェクト総額 数億円以上）の場合は、PMO 専門会社へのフル委託も選択肢になります。

メリット:

• 体制が組織化されている（複数人体制・ノウハウの蓄積）
• ガバナンス層への報告品質が高い

リスク:

• コストが大きい（月額数百万円〜）
• 契約手続き・選定プロセスが長期化する（2〜3 ヶ月かかることも）
• フィット感の問題: 大規模 PJ 前提のサービスを中規模 PJ に当てはめると過剰品質になる

選択の目安としては、プロジェクト総額 3 億円未満であれば外部 PM 人材、3〜10 億円であれば外部 PM 人材または小規模 PMO 会社、10 億円以上であれば PMO 専門会社、という棲み分けがおおまかな目安です（プロジェクトの複雑度によって増減します）。

マルチベンダー運用を継続改善する月次レビューの観点

最後に、マルチベンダー運用の継続改善について触れます。一度設計した運用ルールは、プロジェクトの進行や体制変更とともに必ず劣化していきます。月次でレビューする仕組みを組み込むことで、調整負荷の再増加を未然に防げます。

月次で計測すべき 5 つの定量指標

レビュー会議では、以下 5 つの定量指標を毎月計測し、トレンドを追います。

特に指標 4・5 は、「発注者の調整負荷」を直接表す指標です。指標 4 が増加し、指標 5 が減少していれば、ベンダーが自律的に調整できるようになってきたサインと判断できます。

ベンダーアンケートで定性面を補足する観点

定量指標だけでは見えない問題もあるため、四半期ごとに各ベンダーへ簡易アンケートを実施します。設問例は以下です。

• 他ベンダーとのコミュニケーションコストは適切か（5 段階評価）
• 依存関係マップは更新しやすいか（5 段階評価）
• 課題管理フォーマットは適切な粒度か（5 段階評価）
• 改善してほしい運用ルールがあれば自由記述

匿名で回収することで、率直なフィードバックを引き出せます。

半年に 1 回の体制見直しチェックリスト

半年に 1 回は、体制そのものの見直しを行います。チェック項目は以下を目安にします。

• ステアリングコミッティの参加者は今の意思決定に合っているか
• 運用層会議の頻度は今のフェーズに合っているか（過剰・不足）
• 技術判定層の体制（リードベンダー / 外部 PM / 第三者検証）は機能しているか
• 依存関係マップの記載項目・粒度は今のプロジェクトに合っているか
• 課題優先度の判定基準は実態と合っているか
• 外部 PM 人材の稼働時間・契約形態は適正か

体制見直しの結果は、ガバナンス層に上申し、必要に応じて契約変更・運用ルール改訂を進めます。

マルチベンダー体制の調整は、「ベンダー各社の善意」や「発注者の頑張り」に依存する限り、構造的に発注者が消耗する仕組みになっています。本記事で紹介した 3 レイヤーの体制設計、依存関係マップ、課題管理ルール、責任切り分け 4 ステップ、外部 PM 活用の選択肢、月次改善サイクルは、いずれも「発注者ひとりに負荷を集中させない」ための仕組みです。

すべてを一度に導入する必要はありません。まずは依存関係マップと課題管理フォーマットの統一から始め、結合テスト前に責任分担マトリクス（RACI）を全社合意し、消耗感が続くようであれば外部 PM 人材の部分活用を検討する、という段階的な導入をおすすめします。

外部人材を活用した発注者側の体制づくりや、フリーランス PM・複業 PM の選定・契約実務について、より具体的な情報を求める場合は、発注者向けのお役立ち資料も参考にしてください。