複数ベンダーのテスト管理術｜重複・抜け漏れを防ぐ責任分界と実践運用

2026 8/09

2026年8月9日 2026年8月9日

機能テストをA社へ任せます。
セキュリティテストはB社という体制もあります。
複数のテスト代行会社を使えば、各社の専門性と人員を活用できます。
一方で、管理設計がない体制では、テストの重複や抜け漏れが起きます。

原因は、各社の技術力だけにあるとは限りません。
契約範囲の「間」と「重なり」を、誰も管理していないことが原因です。
複数ベンダーのテスト管理では、会社間の境界を設計する必要があります。

この記事では、PM向けの管理方法を解説します。
責任分界、重複の排除、情報共有、ハブ役、契約の注意点を扱います。
併用に向く案件かも判断できます。

複数ベンダー体制で起きる3つの問題

複数社を使うときは、まず共通の問題を把握しましょう。
契約を個別に結ぶだけでは、次の3つを防げません。

重複：似たケースを作り、工数と費用が重なる
抜け漏れ：他社が見ると思い込み、境界を誰も確認しない
情報の分断：管理方法が各社で異なり、PMが品質の全体像をつかめない

問題を防ぐ要点は、担当、情報、判断経路の3つを全社でそろえることです。
各社が自分の契約範囲を守っても、境界が空白なら品質は守れません。

テスト代行会社を併用する3つのパターン

管理方法は、複数社を使う目的によって変わります。
自社の体制を、次の3つから選んでください。

パターン	分け方の例	注意する境界
専門領域別	機能、セキュリティ、性能で分ける	複数の専門領域にまたがる観点
フェーズ別	結合、総合、受け入れ、回帰で分ける	前工程から次工程への引き継ぎ
リソース補完	一部のテストケースを追加発注する	既存会社との重複と空白

専門領域別に分ける

テストの種類ごとに、専門会社を使い分ける形です。
機能テストには、業務知識とテスト設計力が求められます。
脆弱性診断や性能テストでは、各領域の知識と経験が必要です。

注意点は、領域をまたぐ観点の担当です。
たとえば、大量データ投入時は、性能とデータ整合性の両方が関わります。
境界にある観点ほど、担当と最終判断者を明記しましょう。

フェーズ別に分ける

開発工程やテスト工程ごとに、担当会社を分ける形です。
開発会社が結合テストまで行い、代行会社が総合テストを担う例があります。
回帰テストだけを、運用保守会社へ任せる場合もあります。

この体制では、フェーズ間の引き継ぎが品質を左右します。
不具合の傾向と、確認が薄い領域を次社へ渡します。

不足するリソースを補う

大型リリースの前だけ、別会社へ一部のケースを発注する形です。
専門領域で分けないため、担当の線引きが曖昧になりやすい体制です。
短期の支援でも、開始前に責任分界を決めてください。

責任分界マトリクスで担当と判断者を決める

最初に作るべき資料は、責任分界マトリクスです。
テストレベルと観点ごとに、実施者と判断者を一覧にします。
キックオフで全社が合意すれば、口頭認識のずれを減らせます。

テストレベル・観点	A社（機能）	B社（セキュリティ）	C社（性能）	自社・PM
結合テスト	対象外	対象外	対象外	担当
機能の総合テスト	担当	対象外	対象外	レビュー
UI・UXの外観確認	担当	対象外	対象外	対象外
脆弱性診断・ペネトレーションテスト	対象外	担当	対象外	結果レビュー
負荷・性能テスト	対象外	対象外	担当	目標値の設定
大量データ投入時の整合性	一部担当	対象外	一部担当	調整・最終判断
リグレッションテスト	担当	対象外	対象外	対象範囲の指定
受け入れテスト（UAT）	対象外	対象外	対象外	担当

表にない観点は、担当者がいないと考えてください。
複数社が関わる観点では、実施範囲を各社の欄に書きます。
調整と最終判断を担う人も、PM側の欄へ明記しましょう。

マトリクスは、作成時点の合意を示す資料です。
仕様や体制が変わるたびに更新し、現在の担当を反映させてください。

テスト観点の重複を排除する5つの手順

担当を決めても、ケース単位の重複は残ることがあります。
重複は費用と日程を圧迫するため、次の手順で定期的に確認します。

手順1：開始時に、各社からテスト観点とケースの一覧を集める
手順2：PMが、機能や画面ごとの共通シートへ整理する
手順3：同じ対象に、似た観点のケースがないかを照合する
手順4：専門性、費用、環境への権限から担当を決める
手順5：仕様変更や機能追加のたびに、照合を繰り返す

外したケースは消さず、「対象外」と判断理由を記録します。
この記録により、次の周期で同じ重複を防げます。

共有情報の保管場所と更新者を一元化する

全社で使う情報は、同じ場所に集めます。
全員が同じ版を参照できる状態にします。
情報ごとに、保管場所、更新者、更新時点を決めてください。

情報	一元化の方法	更新時点
過去のバグ履歴	共通の課題管理ツールへ全社の権限を設定	発生・修正のたび
テスト環境情報	権限管理できる文書へ集約	環境構成の変更時
テストデータ	共有ストレージで版を管理	データの更新時
仕様変更情報	変更履歴と全社への通知ルールを用意	変更確定時、または週次定例

環境情報には、URL、認証情報、データの初期化手順を含めます。
テストデータには、マスターデータや境界値データを含めます。
古い情報では、正しい結果を得られません。
再現しない不具合報告や確認漏れにつながります。

一元化では、置き場所と更新責任を1つに決めます。
担当者と更新条件を決めます。
個人の忙しさに左右されない運用にします。

コミュニケーションのハブ役を決める

報告と相談を集めるハブ役も必要です。
選択肢は、PMが担う方法と、特定の1社へ集約する方法です。

観点	PMがハブ	1社へ集約
情報の一貫性	PMが全体を把握しやすい	ハブ役の運用品質に左右される
PMの負荷	高い	低い
意思決定	速い	経由する分、遅れる場合がある
NDA・競合への配慮	不要	必要
向く体制	2〜3社程度	4社以上、または長期案件

PMがハブになる場合

PMが全社の報告と相談を受け、判断する体制です。
情報を集めやすい一方で、社数が増えるほどPMの負荷も増えます。
3社を超えると、進捗確認だけで稼働を圧迫する場合があります。

特定の1社へ集約する場合

実績のある1社が、他社からの報告を一次集約する体制です。
PMの負荷は下がりますが、他社の情報を共有する必要があります。
NDAの範囲と、会社間の競合関係を先に確認してください。

情報の集約役と、最終決定者は分けて明記します。
最終決定をPMに残せば、責任の所在が曖昧になる事態を防げます。

契約とNDAは複数社での共有を前提にする

契約とNDAも、複数社での運用を前提に設計します。
他社の存在と、共有範囲を事前に合意してください。
未合意では、開始後に情報を共有できないおそれがあります。

他社の存在：社名や役割を、どこまで開示できるか
再委託：再委託先にも同じ秘密保持義務が及ぶか
情報共有の範囲：バグ情報やテストデータを、どの会社まで開示できるか
契約終了後の対応：データや認証情報を、どう返却・破棄するか

契約形態により、成果物や責任、報告の粒度が変わります。
準委任と請負のどちらを選ぶべきかという判断軸を確認しましょう。
各社で契約形態が異なる場合は、成果物の定義を開始前にそろえます。

「一部担当」は、作業と成果物に分けて契約へ反映してください。
責任分界マトリクスと契約の内容がずれると、判断時に混乱が生じます。

複数ベンダーが向くケースを見極める

複数社の利用が、すべての案件に適するわけではありません。
専門性や人員の利点と、PMの管理負荷を比べて判断します。

確認項目	複数社が向く状態	1社が向く状態
専門領域	セキュリティや性能などの差が大きい	機能テストが中心
PMの管理工数	責任分界とハブ調整へ時間を割ける	テスト管理へ時間を割けない
システム規模	大規模、または複数システムが連携する	単一システムで完結する
日程	フェーズ間の調整時間を取れる	調整する余裕がない