テスト代行会社の乗り換え判断｜失敗を防ぐ引き継ぎと契約の完全ガイド

2026 8/09

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

テスト代行会社への不満が続いても、すぐに乗り換えるのは危険です。
準備が足りないまま切り替えると、仕様の理解不足からテスト漏れが起こりえます。

一方で、品質低下を放置すれば、本番障害や調査工数の増加につながります。
大切なのは、感覚ではなく事実と将来のリスクから判断することです。

この記事では、乗り換えの判断基準から移行後の品質管理までを解説します。
PMやQA責任者が使えるように、確認事項を実行順に整理しました。

テスト代行会社を乗り換えるべき5つのサイン

乗り換えは「不満の強さ」ではなく、品質や対応の変化から判断します。
直近の案件やリリースを比べると、一時的なミスと継続する問題を分けられます。

バグ検出率の低下：同じ規模や種類の開発でも、テスト中の検出件数が減っている
報告品質の低下：再現手順や影響範囲がなく、形式的な報告が続いている
担当者の頻繁な交代：交代のたびに、仕様を最初から説明している
対応の遅れ：見積もりや質問への回答が、当日から1〜2週間へ延びている
指摘漏れの正当化：「仕様書になかった」などの説明が、本番障害のたびに出る

1回のミスだけで、乗り換えを決める必要はありません。
繁忙期などによる、一時的な品質低下の可能性があるためです。
直近3〜6カ月の推移と、複数のサインが重なっているかを確認しましょう。

深刻度に応じて対応を分ける

サインが出たら、影響する範囲と繰り返す可能性を整理します。
次の表を使うと、改善要求と乗り換え準備のどちらを優先するか決めやすくなります。

サイン	影響範囲	推奨する対応
担当者の交代が1回だけ	引き継ぎ期間に限られる	改善を求めて経過を見る
バグ検出率が2四半期続けて低下	品質全体に広がる	原因を聞き、乗り換え準備も始める
報告書の形骸化が常態化	意思決定の精度が下がる	是正を求め、改善しなければ乗り換える
テスト漏れによる本番障害	顧客や売上に影響する	すぐに乗り換えを検討する

判断時には、問題を放置した半年後の状態を考えてください。
改善できる問題か、ベンダーの体制に原因がある問題かを見極められます。

外部委託そのものが合わない場合は、乗り換えだけでは解決しません。
テスト代行のデメリットと内製化との使い分けも確認し、委託を続けるか検討しましょう。

乗り換えに適した時期と避けるべき時期

テスト対象が安定し、引き継ぎの時間を取れる時期に切り替えましょう。
契約更新月だけでなく、開発とリリースの予定も合わせて判断します。

時期	判断	理由
機能追加が一段落した節目	適している	対象が安定し、仕様を学ぶ負担を抑えやすい
契約更新月	適している	契約と実務の区切りを付けやすい
大型リリースの前後1カ月	避ける	仕様の理解不足によるテスト漏れが起きやすい
年末年始や大型連休の前後	避ける	両社の人員が減り、連絡が滞りやすい
繁忙期の最中	避ける	引き継ぎや並行稼働の工数を確保しにくい

契約更新月とリリース直前が重なる場合は、更新月だけを優先しないでください。
引き継ぎを1〜2カ月早めるか、契約を延長してリリース後に切り替えます。
契約とプロジェクトの両方に区切りを付けられる日程が理想です。

移行計画では並行稼働の要否を決める

並行稼働は、追加コストと品質リスクを比べて決めます。
実施すれば二重の費用がかかるものの、切り替え直後の検出漏れを見つけやすくなります。

事業への影響とテスト対象の複雑さが高いほど、並行稼働が必要です。
決済や個人情報を扱う基幹機能では、1〜2回のリリースで並行稼働を検討します。
影響が限られる社内ツールなどでは、一括で切り替えられる場合があります。

並行稼働で決める4項目

終了条件：「1回のリリース」など、期間や完了条件を決める
役割分担：新旧の会社が担当する機能を分ける
結果の比較：同じ機能の結果を比べ、バグ検出の精度を確かめる
費用の上限：追加で使える予算を社内で決める

同じ機能を両社がテストすれば、新しい会社の実力を早い段階で確認できます。
結果に差がなければ、予定より早く並行稼働を終える判断もできます。
差が大きい場合は、担当範囲やテスト観点をすぐに見直せます。

引き継ぎ資料は4分野に分けて整備する

品質の空白を短くするには、担当者の経験を文書に移す必要があります。
テストケースだけでなく、既知の課題や過去の障害も引き継ぎましょう。

テスト資産：仕様書、ケース、データ、自動テストと実行環境
既知のバグや課題：未修正の不具合、許容した挙動、対応を保留した項目
環境情報：検証環境、アカウント、外部連携、CI/CDの設定
過去のノウハウ：障害の原因、注意する機能、開発チームとの連携方法

資産	引き継ぐ内容	提供形式の例
テスト仕様書	機能別の観点、期待結果、実行手順	表計算ファイルや管理ツールの出力
テストケースとデータ	実行済みケース、アカウント、データセット	移行用CSVや環境情報シート
既知のバグ	未修正の不具合、再現条件、対応方針	課題管理ツールの出力と補足資料
ノウハウと障害履歴	障害原因、注意する機能、連携ルール	議事録とナレッジ文書

抜けやすい情報は、担当者の頭にある経験則です。
たとえば、同じ原因で障害が3回起きた機能は、新しい会社にも知らせる必要があります。
契約終了が近づくと、旧担当者が別の案件へ移る場合もあります。
聞き取りは、乗り換えを検討した段階で始めましょう。

テスト資産は、日ごろから自社でも保管して更新してください。
旧会社のツールだけで管理すると、権限や出力形式の問題で移せないおそれがあります。

契約終了前に確認する4つの論点

旧会社への通知前に、契約書と運用のずれを確認します。
法務や契約担当と相談し、権利やデータの扱いを書面で残しましょう。

論点	確認する内容	注意点
秘密保持	終了後の期間、対象、担当者が異動した場合の扱い	担当者の理解と契約書が食い違う
データの返却・破棄	方法、期限、証明書の要否	口頭確認だけで記録が残らない
著作権・利用権	成果物の帰属、独自ツールの利用範囲	渡せない資産を新会社へ提供する
未払い・精算	最終請求、未消化工数、並行稼働の費用	費用の認識が両社でずれる

秘密保持の期間と対象を確認する

契約終了後も秘密保持が続くか、契約書で確認します。
通知書には、条項が続く期間と対象を記載し、双方の認識を合わせましょう。

データの返却・破棄を記録に残す

本番相当のデータや検証環境の情報は、返却または破棄の方法を決めます。
口頭確認ではなく、破棄証明書や完了報告書の提出を求めます。
アクセス権限は、契約終了日に失効させる運用が必要です。

テスト資産を新会社へ渡せるか確認する

仕様書や自動テストの著作権が、どちらにあるか確認してください。
成果物を自社へ移す契約でも、旧会社の独自資産が含まれる場合があります。
その部分は利用できる範囲を確かめてから、新会社へ渡します。

契約終了の直前ではなく、乗り換えの検討時に契約書を確認しましょう。
選定時に決めるべき条項は、テスト代行で失敗しない選び方でも確認できます。

乗り換え後の品質低下を抑える4つの対策

資料をそろえても、新会社がプロダクトの特徴をつかむには時間がかかります。
初回から重要な機能をすべて任せず、検出漏れを見つける仕組みを用意します。

段階的な移管：影響が小さい機能から始め、重要な機能へ広げる
結果の再確認：社内QAや旧会社が、新会社のテスト結果を確かめる
週次の振り返り：進み具合と課題を共有し、認識のずれを直す
KPIの設定：旧会社の実績と比べられる指標を、開始時から測る

立ち上げ時のリスク	主な原因	対策
重要機能のバグを見落とす	仕様の理解が足りない	影響の小さい機能から段階的に移す
報告内容が合わない	運用ルールが旧会社と違う	初回リリース前に報告形式を合わせる
環境でテストを実行できない	環境や権限の引き継ぎ漏れ	並行稼働中に環境を使って確かめる
質問への回答が遅れる	開発チームとの関係ができていない	週次で課題と担当者を確認する