複数ベンダー管理表のテンプレート

会社ごとの契約はあるが、境界の責任が書かれていない

連携部分の不具合で、どちらの瑕疵かが決まらない

連携仕様を、各社がそれぞれ持っている

版数がずれ、結合テストで初めて不一致が分かる

契約の形（請負／準委任）が混ざっている

同じ管理の仕方を当てはめ、どちらにも効かない

ベンダー間で直接やり取りしている

発注者が知らないうちに仕様が決まっている

窓口が個人ルートになっている

依頼が変更管理をすり抜ける

1社に依存しすぎている

その社の都合で、プログラム全体の日程が動く

境界の責任者を決める

発注者側に統合責任者を置くか、1社に明記して費用を積む

連携仕様を1つの台帳にする

版数を発注者が確定させる

契約の形ごとに管理を変える

請負は成果物、準委任は工数と作業内容で見る

依頼の経路を一本化する

すべての依頼をCR票か作業指示書に載せる

依存度を把握する

1社が抜けたときの影響を、あらかじめ見積もる

発注者側に統合責任者を置く

連携仕様の台帳を発注者が持ち、結合テストの計画と不具合の切り分けを主導する

社内に技術が分かる人材がいる場合

専任1名は必要。兼務だと機能しない

1社に統合責任を持たせる

主契約者（プライム）を決め、統合の責任と費用を契約に明記する

社内に人材がいない場合

その社への依存が強まる。費用も上がる

ベンダーが負う責任

成果物を完成させる責任

善良な管理者として作業を行う責任

発注者が管理するもの

成果物と検収条件

投入工数と作業内容

進め方への関与

口を出しにくい（指揮命令の問題が出る）

作業内容を指示できる

月次で見る数字

成果物の完成度、検収予定日

投入工数、作業の進み具合

遅れたときの扱い

納期遵守の責任はベンダー

発注者側にも責任がある

変更への対応

CR票で契約変更（金額が動く）

作業指示の変更（工数の範囲内なら金額は動かない）

ベンダー名／略称

A社、B社…

―

担当する構成プロジェクト

C1、C2…

複数にまたがる場合は、すべて書く

契約の形

一括請負／準委任／保守契約

形によって管理方法が変わる

契約金額／期間

金額と、契約の開始・終了

更新時期も書く。更新の直前は交渉力が変わる

窓口（先方／自社）

両側の個人名

個人ルートの依頼を防ぐ

他社との接点

どのベンダーと、何で接するか

連携仕様の台帳へのリンクを書く

統合の責任

誰が持つか（統合責任者／プライム）

空欄にしない。空欄なら、それが最大のリスク

依存度

高・中・低と、その理由

「抜けたら代替に何か月かかるか」で判断する

評価

品質・納期・コミュニケーションを四半期ごとに

次の調達の材料になる

エスカレーション先

先方の上位者と、自社の上位者

現場で解決しないときの経路を先に決めておく

A社

C1 需給管理・料金計算

一括請負

3億1,000万円

高（15年の取引。業務知識が社内にしか無い）

C1内は自社。境界は統合責任者

B社

C2 顧客接点／C4 代理店管理

準委任

月額1,850万円

中（UI開発。代替可能）

統合責任者

C社

C3 スマートメーターデータ基盤

一括請負

2億2,000万円

高（専門領域。国内で扱える会社が3社）

統合責任者

D社

インフラ構築・運用

保守契約

年額4,200万円

中（引き継ぎに6か月）

―

I-01

A社 ⇄ B社

契約情報の参照API

統合責任者

v1.2

2025/2/14

I-02

A社 ⇄ C社

需給実績データの受け渡し（日次）

統合責任者

v1.0

2025/5/9

I-03

B社 ⇄ C社

使用量グラフ表示用の集計データ

統合責任者

v0.9（調整中）

―

I-04

A社 ⇄ D社

バッチ処理の実行基盤とジョブ管理

統合責任者

v1.1

2025/1/20

境界の責任を空欄にしない

統合責任者かプライムのどちらかを、必ず書く

空欄の境界は、必ずもめる

連携仕様は発注者が確定させる

版数と確定日を、台帳で管理する

ベンダー同士で決めさせない

依頼は必ず文書で

CR票か作業指示書を経由する

個人ルートの依頼が、変更管理をすり抜ける

合同の会議体を作る

月1回、全ベンダーが出席する連携会議を開く

境界の問題は、同じ場でないと解けない

四半期ごとに評価する

品質・納期・コミュニケーションの3点

次の調達と、契約更新の材料になる

依存度が高い社には代替策を持つ

ドキュメント化、社内への技術移転、第2の候補

依存度は、手を打たないと下がらない

調達の計画時

境界がどこに生まれるかを先に描き、責任の持ち方を契約に書く

契約交渉

統合の責任と費用を、見積り依頼の条件に含める

月次のベンダー連携会議

連携仕様の台帳を見ながら、調整中の項目を確認する

結合テストの計画

接点ごとに、誰が不具合を切り分けるかを決める

契約更新の時期

四半期評価を持って、条件交渉に臨む

1社が抜けそうなとき

依存度の欄を見て、代替にかかる期間と費用を見積もる

境界の責任が契約に無い

連携部分の不具合で、責任の押し付け合いになる

統合責任者を置くか、プライムに明記して費用を積む

連携仕様を各社が持っている

版数がずれ、結合テストで初めて分かる

発注者側の1つの台帳に集約する

請負と準委任を同じに管理している

どちらにも効かない管理になる

月次報告のフォーマットを、形ごとに分ける

ベンダー同士が直接決めている

発注者が知らない仕様変更が入る

仕様の確定者を、すべて発注者側にする

依存度を評価していない

1社の都合で全体の日程が動く

「抜けたときの代替期間」で依存度を判定する

合同の場が無い

境界の話が、個別のやり取りで滞る

月1回の連携会議を設け、境界の課題だけを扱う

境界の責任

どちらの契約範囲にも入っていない

統合責任者が、4つの接点すべてを持つ

連携仕様

各社が別々に持ち、版数がずれる

1つの台帳で、版数と確定日が管理される

不具合の切り分け

発注者が両社を往復する

統合責任者が主導して切り分ける

契約の管理

請負も準委任も同じ報告書

形ごとにフォーマットを分ける

依存度

把握していない

「業務知識が社内にしか無い」と記述し、文書化を成果物に追加