マルチベンダー管理｜インターフェース仕様と責任分界

複数のベンダーが分担するときは、各社の成果物だけでなく、接続点の仕様・提供時期・テスト環境・障害対応を管理します。担当範囲の境目が曖昧なままだと、全体の結合確認が遅れるおそれがあります。

発注側PMは、共通仕様と変更の決め方、各社の責任、問題の切り分け手順を合意します。モックを使って前倒しできる確認と、実システムでなければ確かめられない条件を分けて計画します。

本文の演習は学習用のオリジナル事例です。解答例の表現は一例で、公式問題の解答・配点ではありません。

1. 接続点を共通の条件で管理する

OpenAPIやスキーマは仕様を共有・検証する助けになりますが、業務上の意味や運用条件まで自動で合意できるものではありません。変更は影響を評価し、関係者へ同じ版を通知します。

2. スタブで進める範囲と、実接続の確認

API本体が未完成でも、合意した仕様に従うスタブやモックで、画面・送受信・エラー処理の一部を確認できます。正常応答だけでなく、業務例外やタイムアウトの条件も必要に応じて用意します。

実APIの性能、認証連携、実データ、同時実行などは、スタブの結果だけで確認済みとは扱えません。実接続へ切り替える日と、再確認するテストを工程表へ残します。

障害発生時は、時刻や識別子を合わせて送受信ログを突き合わせます。機密情報の扱いとアクセス権も決め、各社が共通の証拠で調査できるようにします。原因の技術判断と、契約上の責任・費用の判断は分けて進めます。

演習1：API遅延時の前倒し確認

条件：R社の在庫APIが2週間遅れる。共通仕様は合意済みで、Q社は画面側の応答処理を先に確認できる。

問い：先行テストのために提供を調整するものを述べよ。（30字以内）

解答例：合意した仕様に準拠するAPIスタブ。（18字）

根拠：API本体を待たずに画面側の処理を確認できます。提供担当・範囲・期限も合意します。

確認ポイント：スタブを使った確認を、実APIとの結合テスト完了と置き換えてはいけません。

演習2：障害の切り分け

条件：結合テストで電文エラーが起き、Q社とR社のどちらの処理が原因か不明である。

問い：共同調査のためのルールを述べよ。（40字以内）

解答例：送受信ログを突合し、共同で調査担当と対応期限を決める。（27字）

根拠：共通仕様とログを根拠に、調査を止めずに原因を絞ります。

確認ポイント：原因が不明な時点でPMが責任を断定すると、証拠に基づく調査を妨げます。

3. 答案の観点

• 仕様の版と業務条件が共通になっているか。

• 提供時期と各社の依存関係を確認したか。

• スタブと実接続の検証範囲を区別したか。

• 障害調査の証拠・担当・期限が明確か。

出典と仕様を確認する

IPA：PMシラバス Ver.7.1

IPA：情報システム・モデル取引・契約書