内製とテスト代行の役割分担｜責任範囲を決める5ステップ

2026 8/09

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

内製チームとテスト代行会社を併用すると、テストの負荷を分散できます。
専門家の視点も取り入れられます。

一方で、作業だけを分けても体制は機能しません。
「誰が判断するか」まで決めないと、抜けや二重作業が生じます。

役割分担では、作業の担当と判断の責任を分けます。
品質とリリースの最終判断は、内製側に残します。

この記事では、役割分担を決める5ステップを解説します。
工程別の分担例やRACI表も、そのまま検討に使えます。

内製とテスト代行の役割分担は「作業」と「判断」を分ける

最初に分けるべきものは、作業の担当と判断の責任です。
両者を一つにすると、境界にある仕事が宙に浮きます。

テスト代行会社は、合意した範囲を設計して実行できます。
結果の報告や再テストも担当できます。

内製側は、事業や利用者への影響を判断できます。
範囲の承認や優先度は、内製側が決めます。

区分	おもな内容	担当の目安
作業	テストケース作成、実行、結果報告、再テスト	テスト代行会社へ委託できる
専門判断	不具合か仕様かの判定、修正方針の決定	内製QAと開発者
事業判断	残るリスクの受容、リリース可否の決定	内製PM

PMはプロジェクトマネージャーを指します。
QAは品質保証を担う役割です。
以降は「内製PM」と「内製QA」に表記を統一します。

内製か外注かを未定なら、先に判断の基準を整理しましょう。
テストの内製と外注はどちらが得か｜判断の物差しで確認できます。

つまり、外注する範囲が広くても、品質判断まで手放す必要はありません。
この原則が、以降の線引きの土台です。

役割分担を決める5ステップ

役割分担は、5ステップで決めると抜けを防げます。
工程だけでなく、成果物と判断まで順に具体化できるためです。

STEP1｜テストの目的と対象をそろえる

最初に、確かめる品質と対象範囲を合意します。
目的が違えば、同じ機能でも必要なテストが変わります。

対象にする機能、端末、ブラウザー
対象外にする機能と、その理由
性能、使いやすさ、セキュリティなどの品質観点
開始条件、完了条件、中断条件

たとえば、決済機能では正常終了だけでは足りません。
二重送信や通信切断も、対象に含めるか決めます。

目的と対象を1枚にまとめます。
見積もりと結果を、同じ基準で評価できます。

STEP2｜工程と成果物を分ける

次に、工程を成果物の単位まで分けます。
「システムテストを外注する」だけでは、作業の境目が見えないためです。

テスト計画書の作成と承認
テストケースの作成とレビュー
環境とテストデータの準備
テストの実行と証跡の保管
不具合の起票、判定、修正確認
完了報告とリリース判定

各項目に「作る人」と「承認する人」を置きます。
これで、作成済みなのに承認されない事態も防げます。

工程ごとの外注範囲には、6つの判断軸があります。
テストの工程別外注｜切り分けの判断軸6つで確認できます。

STEP3｜RACIで責任者を1人に決める

タスクごとの責任は、RACIで決めます。
RACIとは、4種類の関わり方を整理する枠組みです。

R（実行担当）：手を動かして作業する人
A（承認責任者）：最終判断をして説明責任を負う人
C（相談先）：判断の前に意見を求める人
I（報告先）：決定や結果の共有を受ける人

Aは、1タスクにつき1人にします。
2人を置くと、意見が割れたときに最終判断が止まります。

タスク	内製PM	内製QA	テスト代行会社
テスト計画の承認	A	R	C
テストケースの作成	I	A	R
テスト環境の準備	I	A／R	C
テストの実行	I	A	R
不具合の起票	I	A	R
不具合の優先度決定	C	A／R	C
リリース判定	A	R	I

この表は一例です。
契約や組織に合わせて変えてください。
大切なのは、Aの重複と不在をなくすことです。

STEP4｜受け渡し条件を文書にする

担当間の受け渡し条件は、口頭ではなく文書にします。
境界で起きる待ち時間は、前提の違いから生まれるためです。

受け渡すもの	完了条件の例	受け取る側
仕様書	版番号と変更履歴があり、未決事項が明記されている	テスト代行会社
テスト環境	接続を確認し、必要な権限とデータがそろっている	テスト代行会社
不具合報告	再現手順、期待結果、実際の結果、証跡がある	内製QA
完了報告	実行数、合格数、未実行数、残る不具合がある	内製PM

たとえば、仕様書に未決事項が残る場合は、回答期限と回答者も記します。
受け渡し条件があれば、着手の可否を双方が判断できます。

STEP5｜契約書と運用資料をそろえる

最後に、合意した分担を文書へ反映します。
資料ごとに内容が違うと、問題が起きた際に解釈が割れます。

契約書やSOWに、対象範囲と対象外を記す
RACI表に、担当者名と更新日を記す
連絡ルールに、手段と期限を記す
完了条件に、承認者と必要な証跡を記す

SOWは「作業範囲記述書」です。
委託する作業や成果物を、契約の一部として示します。

5つの結果を一式で保管すれば、契約上の範囲と日々の運用をそろえられます。

テストレベル別の役割分担例

工程別の分担は、必要な知識と判断権限で決めます。
すべてを一律に内製か外注へ寄せる必要はありません。

テストレベル	主担当の目安	内製側に残す役割	テスト代行会社の役割
単体テスト	内製	実装とテストコードの保守	自動化の仕組みづくりを支援
結合テスト	内製と外注	仕様提供、原因の切り分け	テストケース作成、実行
システムテスト	外注中心	業務知識の提供、結果の承認	利用者目線での設計、実行
受入テスト	内製	業務上の合否と受入判断	実行、証跡作成を支援

単体テストは内製を基本にする

単体テストは、内製の開発者が担う形を基本にします。
コードの構造を知る人ほど、異常な分岐を見つけやすいためです。

外部の支援は、自動テストの基盤づくりに向きます。
実装とテストコードの保守責任は、内製側に残します。

結合テストは知識と実行を分ける

結合テストは、内製と外注の協業に向きます。
内製は内部仕様を説明し、外注は組み合わせの観点を広げられます。

たとえば、画面とAPIのデータ不一致が出たとします。
外注が証跡を取り、内製の開発者が原因を切り分けます。

このように、発見と原因調査を分ければ、専門性を生かしやすくなります。

システムテストは外注範囲を広げやすい

システムテストは、テスト代行会社を主担当にしやすい工程です。
第三者の視点で、業務の流れ全体を確認できるためです。

内製側は、業務説明と質問への回答を担います。
結果を受け入れる基準も、開始前に承認します。

受入テストの合否は内製側が決める

受入テストの合否は、内製側が決めます。
受入は「業務で使えるか」という事業上の判断だからです。

テスト代行会社には、操作や証跡の作成を依頼できます。
残る不具合を受け入れる判断は、内製PMが行います。

情報共有は「誰が・いつ・どこへ・何を」で決める

役割分担には、情報共有のルールも必要です。
担当者が決まっても、必要な情報が届かなければ動けないためです。

情報	共有する人	期限	共有先と内容
仕様変更	変更を決めた内製担当	決定した当日	課題管理ツールへ理由と影響範囲を記す
環境変更	環境を変える担当	作業の前日まで	共有チャネルへ停止時間と変更内容を記す
既知の不具合	不具合を見つけた担当	判明した当日	不具合一覧へ再現条件と回避策を記す
作業の遅れ	遅れを把握した担当	予定との差が出た時点	内製PMへ影響と回復案を伝える

期限は案件に合わせて変えてかまいません。
「分かり次第」などの表現は避けます。

情報の正本は1か所に決めます。
チャットは通知に使います。
決定事項は、課題管理ツールへ残します。

情報の種類ごとに4点を決めれば、古い仕様でテストする事故を防げます。

品質の最終責任は内製側が持つ

テストを委託しても、最終責任は内製側に残ります。
事業上の損失を受け入れる権限は、発注側にあるためです。

テスト代行会社は、契約した範囲の実行品質に責任を持ちます。
内製側は範囲を承認し、リリースを判断します。

論点	テスト代行会社	内製側
合意したテストの実施	実行して証跡を出す	結果を確認する
テスト範囲の妥当性	不足を助言する	承認する
不具合の事業影響	事実を報告する	評価する
残るリスクの受容	判断材料を出す	決定する
リリース可否	結果を報告する	最終決定する

たとえば、契約外の端末で不具合が出ても、代行会社だけの責任とは言えません。
対象外を承認した内製側にも、判断の責任があります。

契約範囲と最終責任を分けておけば、問題の原因を事実にもとづいて振り返れます。

役割分担が崩れる5つの失敗例

失敗は、作業よりも境界の判断で起きます。
次の5例を確認すると、自社の分担表の穴を見つけやすくなります。

作業が宙に浮く：双方が相手の担当だと考え、着手されない
仕様変更が届かない：テスト代行会社が旧版の仕様書でテストする
不具合判定が止まる：仕様か不具合かを決める人がいない
優先度がずれる：利用者への影響が報告に含まれていない
リリースが決まらない：承認責任者が2人以上いる

例として、テストケースだけを外注したとします。
レビュー担当がなければ、実行前の承認で作業が止まります。

RACIと受け渡し条件を照合すれば、5つの失敗を開始前に減らせます。

体制を見直すタイミングと手順

役割分担は、節目と異常の発生時に見直します。
開発が進むと、必要な知識や作業量が変わるためです。

タイミング	確認すること
結合テストへ移る前	実装上のリスクがテストケースへ反映されたか
仕様を変更したとき	対象範囲、RACI、旧テストケースを更新したか
不具合件数が想定から外れたとき	観点、環境、報告ルールに問題がないか
予定より1営業日以上遅れたとき	未着手の作業や承認待ちがないか
リリース判定の前	未実行と残る不具合の責任者が明確か

「件数が増えたら」では、見直す時期が人により変わります。
過去案件をもとに、件数や遅延日数で条件を決めます。