マルチベンダー体制におけるインターフェース調整と責任分界

DXや大規模基幹刷新プロジェクトでは、フロントWeb、基幹ERP、クラウドインフラ、データ分析基盤などを異なる専門ベンダーに分割発注する「マルチベンダー体制」が主流となっています。

しかし、マルチベンダー開発で最も多発するのが「結合テストでのインターフェース不整合」と、不具合発生時の「ベンダー同士の責任の押し付け合い（エアポケット）」です。発注元PMが複数ベンダー間の連携を主導し、手戻りを極小化するためのマネジメント技術を解説します。

1. マルチベンダー開発で頻発する3大トラブル

2. 責任分界とインターフェース統制の4大ツール

1. 【RACIマトリクスによる責任分界】：各タスク（IF仕様策定、結合環境構築、スタブ提供、テスト実行、ログ解析）について、実行責任者（R）、説明責任者（A）、相談先（C）、報告先（I）を定義する。

2. 【インターフェース仕様書（ICD）の厳格管理】：OpenAPIやスキーマ定義ファイルを唯一の正解（SSOT）とし、変更管理プロセス外での口頭・個別修正を厳禁とする。

3. 【スタブ/モックによる疎結合開発】：結合テストを待たず、相手方システムを模倣するモックサーバー（スタブ）を早期提供させ、単体レベルで電文疎通を完了させる。

4. 【合同トリアージ会議の設置】：結合テスト期間中、全ベンダーの代表者が毎日同席する会議をPM主催で開催し、障害ログをその場で切り分けて担当ベンダーを即決する。

3. 【実戦記述演習 問1】スタブ提供遅延によるテスト阻害の回避

【シナリオ背景】アパレル企業P社のオムニチャネル刷新において、ECフロント開発をベンダーQ社、在庫引当API開発を基幹保守ベンダーR社が担当している。計画では、結合テスト工程の第1週からQ社がR社の開発したAPIに接続して結合テストを実施する予定であった。しかし、第1週直前になってR社より「基幹DBのスキーマ改修に難航しており、APIの提供が2週間遅れる」との申し入れがあった。Q社は「APIが提供されなければ結合テストに着手できず、待機費用が発生する上に納期に間に合わない」と主張した。

設問1：R社のAPI完成遅延によるQ社のテスト停滞を最小限に抑えるために、PMがR社に対して直ちに作成・提供を指示すべきものを30字以内で答えよ。

【模範解答】

仕様書に準拠したモックAPI（スタブ）環境。（23字）

解説と採点基準（配点：10点）

• 出題意図：本番ロジックの完成を待たずに、固定レスポンスを返すモック/スタブを先行提供させることで、クライアント側のテストを前倒し進行させる判断力を問う。

• 加点キーワード：『モック（スタブ/シミュレータ）』（6点）、『API環境（レスポンス生成環境）』（4点）。

• 減点対象：「APIの仕様書」（仕様書は既にある前提であり、動くテスト対象を提供する必要があるため不適切）。

4. 【実戦記述演習 問2】ベンダー間における障害切り分けルールの確立

設問2：結合テスト中に電文エラーが発生した際、Q社とR社の責任の押し付け合いを防ぎ、迅速に原因を特定するためにPMが定めておくべき運用ルールを35字以内で述べよ。

【模範解答】

送受信電文ログを保存・突合し、合同トリアージで原因を判定するルール。（34字）

解説と採点基準（配点：10点）

• 出題意図：客観的エビデンス（送受信ログ）の保全と、第三者的な合同トリアージ体制によって責任転嫁を排除するプロトコルを問う。

• 加点キーワード：『送受信電文ログの保存・突合/検証』（5点）、『合同トリアージ（合同判定会議）の実施』（5点）。

• 減点対象：「PMがすべてのバグを一人で調査する」（現実的な運用ルールとして成立しないため減点）。

5. まとめ：マルチベンダー統制チェックリスト

• □ インターフェース仕様書は機械検証可能なフォーマット（JSON Schema, OpenAPI等）で管理されているか？

• □ 結合テスト開始前に、各ベンダーがモックを用いた疎通テストを完了させているか？

• □ 障害発生時のエスカレーションフローと、PM裁定ルールの合意が取れているか？