マルチベンダー体制が遅くなる本当の理由｜窓口と責任分界

「フロントはA社、APIはB社、インフラはC社。それぞれが得意だから速いはず。」——紙の上では合理的だ。現場では、結合試験の週に全員が止まることが多い。

マルチベンダーが遅くなる主因は、各社の技術力不足だけではない。統合のオーナーと責任分界が空いていることだ。得意分野の足し算は、インターフェースの引き算を自動ではやってくれない。

遅延の正体は、窓口乱立と「そこは御社では」の空白地帯だ。

典型失敗

1. 窓口乱立: 発注側の担当が機能ごとに分かれ、優先順位が矛盾する
2. 環境差: 各社のローカル／ステージングが微妙に違い、結合で初めて壊れる
3. 責務の押し付け合い: 障害の一次切り分けが誰の契約にもない
4. 結合が最後: 縦割り納品を集め、終盤に一気に繋ぐ
5. 契約が個別最適: 変更手数料は各社に発生し、横断変更が進まない

深掘り事例：結合試験で3社が止まった

匿名化した一例。EC系の刷新。A社（フロント）、B社（受注API）、C社（基盤）。個別のデモはいずれも「完了」。結合の2週間前から、認証トークンの寿命、エラーコード、リトライ方針が一致しないことが発覚した。

誰の契約に「横断IFのオーナー」もない。協議に3週間、改修に4週間。事業側のキャンペーン日程は消え、各社への追加費用が発生した。分岐点は発注時だ。主幹を1社にするか、社内に統合PMを置きIF文書の承認者を一人にできていれば、結合は「発見の場」ではなく「確認の場」になった。

得意な会社を並べることと、一つのシステムとして出すことは別の設計だ。

構造的原因

• 調達がカテゴリ別に最適化され、統合コストが見積もりに入らない
• 「得意だから速い」仮説が検証されないまま契約が走る
• 問題が起きるまでオーナー不在が可視化されない

回避の判断軸

マルチベンダーを続ける	寄せる／主幹を置く
社内に統合PMがおり、IF承認の権限がある	横断変更が多く、窓口が発注側で割れている
主幹ベンダーが結合と障害一次の責任を契約で持つ	「各社対等」で誰も結合を引き受けない
環境とIFが早期に一本化されている	結合を終盤の一発にしている

次に確認すること

1. 統合のオーナー（社名と人名）は一人か
2. IF文書の承認者は誰か
3. 障害一次の切り分けはどの契約か
4. 結合のマイルストーンは前半にあるか
5. 横断変更の費用負担ルールはあるか

まとめ

マルチベンダーが遅いのは、しばしば各社が悪いからではない。統合と責任分界を設計せず、得意分野だけを調達したからだ。主幹か社内PMかを先に決め、IFと障害の空白を契約から消す。並べる前に、繋ぐ役を置く。

---

体制設計・ベンダー選定の相談は、お問い合わせフォーム からどうぞ。