テスト代行の進め方｜依頼から納品までの流れ

「テスト代行を頼んでみたいが、依頼したあと実際にどう進むのか想像がつかない」——そう感じている受託開発のPMは少なくありません。費用や事例の情報はネット上に多くありますが、問い合わせをしてから成果物が手元に届くまでの一連の流れを、工程ごとに具体的に説明した情報は意外と見つかりにくいものです。このテスト代行の進め方が見えないことが、外注に踏み出せない最大の心理的なハードルになっているケースは多いと感じます。

そこで本記事では、依頼から納品までの流れを「問い合わせ → 要件共有 → 見積 → 契約 → テスト設計 → テスト実行 → 報告 → 納品」という8つの工程に分解し、各フェーズで何が起こり、依頼側であるあなたが何を準備し、どこで判断を求められるのかを順を追って解説します。全体像をつかんでおけば、初めての外注でも落ち着いて進められますし、上長への説明や社内調整もスムーズになります。

なお、テスト代行そのものの全体像（サービスの種類・費用・進め方）を先に押さえたい場合は、ソフトウェアテスト代行の全体像をまとめた記事もあわせてご覧ください。本記事は、外注を前提に「依頼後の工程フロー」へ絞って深掘りします。

テスト代行の進め方は大きく8工程に分かれる

依頼から納品までの流れを理解するうえでまず押さえておきたいのは、全体が大きく8つの工程で構成されているという点です。個々の会社で呼び方や区切り方に多少の違いはあっても、骨格はほぼ共通しています。

この記事で扱う8工程は次のとおりです。

• 工程1：問い合わせ・初回ヒアリング
• 工程2：要件共有・対象範囲のすり合わせ
• 工程3：見積・提案の受領
• 工程4：契約・体制の確定
• 工程5：テスト設計（テスト計画・テストケース作成）
• 工程6：テスト実行・不具合報告
• 工程7：結果報告・レビュー
• 工程8：納品・振り返り

前半は「合意形成」、後半は「実作業」

8工程は、性質の違いで前半と後半に分けて捉えると理解しやすくなります。工程1から4までは、何を・どこまで・いくらで・どの体制でやるのかを決める「合意形成のフェーズ」です。ここでの認識のズレが、後工程の手戻りやトラブルの大半を生みます。一方、工程5から8は、実際にテストを設計・実行して品質を可視化する「実作業のフェーズ」です。

依頼側のPMが特に主体的に動く必要があるのは、実は前半の合意形成フェーズです。後半は代行側が主導しますが、その精度は前半でどれだけ正確に情報を渡せたかに大きく左右されます。「テストは丸投げすれば勝手に進むもの」というイメージを持っていると、後半で「想定と違う」というギャップに直面しがちです。前半でしっかり手綱を握り、後半は代行側に任せつつ要所でレビューする、というメリハリが理想的な関わり方です。

各工程で「誰が主導するのか」「依頼側がどんな判断を求められるのか」を整理すると、次のようになります。

工程	主導	依頼側に求められる判断・アクション
1. 問い合わせ・初回ヒアリング	依頼側	課題と依頼形態の方向性を伝える
2. 要件共有・範囲すり合わせ	双方	テスト範囲の確定、全体像の共有
3. 見積・提案の受領	代行側	提案内容の評価、社内合意
4. 契約・体制の確定	双方	契約形態・窓口・運用ルールの決定
5. テスト設計	代行側	テスト計画・テストケースのレビュー
6. テスト実行・不具合報告	代行側	不具合の修正対応、優先度判断
7. 結果報告・レビュー	代行側	リリース可否の判断
8. 納品・振り返り	双方	成果物の受領、改善点の共有

この表を手元に置いておくと、いま自分がどの工程にいて、次に何を判断すべきかが見通せるようになります。

期間の目安とスケジュールの考え方

工程全体にかかる期間は、対象システムの規模やテストの種類によって幅があります。小さな機能追加のテストであれば数日から1〜2週間程度、ある程度の規模のシステム全体を対象にする場合は数週間から数か月に及ぶこともあります。重要なのは、リリース直前に駆け込みで依頼するのではなく、問い合わせから契約までの合意形成に一定の時間がかかることを見込んで、逆算でスケジュールを組むことです。工程の全体像を早い段階で把握しておくと、この逆算がしやすくなります。

工程1：問い合わせ・初回ヒアリング

最初の工程は問い合わせと初回ヒアリングです。Webフォームやメールで連絡を取り、オンラインまたは対面で初回の打ち合わせを行うのが一般的な流れです。

この段階で代行会社が確認したいこと

初回ヒアリングで代行会社が把握したいのは、おおむね次のような点です。

• どんなシステム・サービスのテストか（業務システム、Webアプリ、スマホアプリなど）
• 現在の開発フェーズと想定リリース時期
• 抱えている課題（テスト工数が足りない、抜け漏れが不安、専任がいない、など）
• 希望する依頼形態（テスト実行だけか、設計から任せたいか）

この段階では細かい仕様を完璧に説明する必要はありません。むしろ「何に困っていて、どうなりたいのか」を率直に伝えることが、適切な提案につながります。たとえば「機能追加のたびに既存機能のデグレ確認が追いつかない」「リリース前の総合テストで毎回スケジュールが逼迫する」といった生々しい困りごとを伝えるほうが、テストの実行だけでよいのか、設計から任せるべきなのか、といった提案の精度が上がります。

逆に、この段階で曖昧にしておくと後で困るのが「ゴールの認識」です。バグをゼロにしたいのか、特定のクリティカルな機能だけ確実に担保したいのか、それともリリース判断の客観的な根拠が欲しいのか——目的によって最適なテストの設計は変わります。初回ヒアリングは、この前提を双方ですり合わせる最初の機会だと捉えてください。

依頼側が準備しておくと話が早いもの

初回ヒアリングをスムーズにするために、手元に簡単な情報を用意しておくと効果的です。システムの概要がわかる資料、画面イメージ、想定している依頼範囲のメモ程度で十分です。依頼前に何をどこまで準備しておくべきかは、テスト代行を依頼する前の準備をまとめた記事で詳しく解説していますので、ヒアリング前にあわせてご確認ください。

工程2：要件共有・対象範囲のすり合わせ

問い合わせの次に来るのが、要件共有と対象範囲のすり合わせです。一連の工程の中でも、成果物の質を最も大きく左右するのがこの工程だと言っても過言ではありません。

「どこまでテストするか」を明確にする

要件共有では、テストの対象範囲（スコープ）を具体的に確定させます。対象とする機能、どのテストレベルを担うか（システムテスト・受入テストなど）、どのテストタイプを実施するか（機能テスト・回帰テスト・互換性テストといった非機能を含む種類）、対応するOSやブラウザ・端末、テストデータの準備方法などを一つずつ決めていきます。代行会社が完成系に対して外部から検証する場合は、システムテストから受入テストの範囲が中心になります。ここが曖昧なまま進むと、「この機能もテストしてくれていると思っていた」という認識のズレが後で表面化します。

スコープを固めるときは、次のような項目をチェックリスト的に確認しておくと抜け漏れが減ります。

• 対象とする機能・画面の範囲（どこからどこまでか）
• 実施するテストの種類と深さ（正常系のみか、異常系・境界値まで踏み込むか）
• 対応する環境（OS・ブラウザ・端末・画面サイズなどの組み合わせ）
• テストデータの用意は誰が行うか（依頼側提供か、代行側作成か）
• テスト環境の準備（検証用サーバーやアカウントの貸与範囲）
• 対象外とする範囲（あえてテストしない部分の明示）

特に見落とされやすいのが「対象外の明示」です。何をやるかだけでなく、何をやらないかを書面で共有しておくと、後になって「やってくれると思っていた」という齟齬を防げます。

情報格差を埋めるフェーズを意図的につくる

テスト代行の進め方で最もつまずきやすいのが、この情報格差への対処です。内製のテストと外部委託のテストには「情報格差」という構造的な違いがあります。社内のエンジニアであれば、開発の経緯や仕様変更の背景、いわゆる裏仕様までを暗黙のうちに共有しています。しかし外部のテスト担当者には、その文脈が自然には伝わりません。

過去のテスト代行案件を振り返ると、この情報格差の影響が明確に表れます。たとえば数十画面規模のWebアプリで、テスト開始時の理解不足が原因で、本来1回の操作で済む確認作業に何度も手戻りが発生したケースがありました。アプリの全体像を把握しきれないまま着手したことで、実行フェーズの序盤で無駄な操作が積み上がったわけです。

この経験から得られた教訓は明快です。一見遠回りに見える「対象システムの全体像を共有する時間」に最初に投資したほうが、結果的にテスト全体の時間は短縮されるということです。具体的には、キックオフで半日ほど画面を一緒に触りながら全体像をすり合わせておくと、実行フェーズに入ってからの質問の往復や手戻りが目に見えて減ります。「急がば回れ」の発想がテスト代行にはそのまま当てはまります。要件共有の工程では、機能一覧を渡して終わりにせず、全体像をすり合わせる時間を意図的に確保することを強くおすすめします。

工程3：見積・提案の受領

要件がすり合った段階で、代行会社から見積と提案を受け取ります。社内の意思決定が本格化するのがこの工程です。

見積に含まれる主な項目

提案書や見積書には、おおむね次のような要素が記載されます。

• テストの対象範囲と実施するテストの種類
• 想定する工数と期間
• 体制（担当人数・役割）
• 成果物の一覧（テスト計画書、テストケース、報告書など）
• 費用と支払い条件

見積を比較するときの着眼点

複数社を比較検討するのはごく自然な進め方ですが、金額の安さだけで判断するのは危険です。同じ「テスト一式」という表現でも、テスト設計まで含むのか実行だけなのか、報告書の粒度はどの程度か、不具合の再テストは費用に含まれるのかなど、中身は会社によって大きく異なります。見積項目の内訳を揃えたうえで比較すると、後の認識違いを防げます。

費用の相場観や見積の内訳をより詳しく知りたい場合は、テスト代行の費用相場を解説した記事で料金体系の考え方を整理していますので、社内説明の材料としてご活用ください。

上長への説明材料を意識する

このフェーズでは、上長や経営層への説明責任が発生することが多いものです。費用対効果を説明するには、単なる金額ではなく「兼任エンジニアの工数をどれだけ本来の開発に戻せるか」「リリース後のバグ対応コストをどれだけ抑えられるか」という観点で整理すると説得力が増します。

具体的な金額の相場は案件規模によって大きく変わるため別記事に譲りますが、稟議に使える費用対効果は、次のような計算フレームで自社の数値を当てはめると組み立てられます。

• 削減できる兼任工数の価値 ＝ 兼任エンジニアがテストに割いている工数（人日／月）× エンジニアの人日単価
• 回避できる障害コスト ＝ 直近で発生した本番障害1件あたりの平均対応工数（調査・修正・クライアント対応・再リリース）× 想定発生件数
• 投資額 ＝ 代行費用の見積額

このうち「兼任工数」と「障害対応コスト」は、社外には存在しない自社固有の数値です。稟議の前に、(1)直近数か月でテストに費やした兼任工数の実績、(2)本番障害1件あたりに要した平均工数、(3)障害発生時のクライアント対応にかかった時間、の3点だけでも社内で集めておくと、「削減・回避できる金額 − 代行費用」という形で投資判断の土台を示せます。金額を一つも出さずに「投資です」と説明するより、自社の数字に当てはめたこの試算が一行でもあるほうが、上長や経営層の納得感は格段に高まります。

加えて、テストの専門家に任せることで抜け漏れが減り、クライアントからの信頼低下を防げるという定性的なメリットも添えておくと、「単なるコスト増」ではなく「品質と開発スピードへの投資」として説明しやすくなります。提案を受け取ったら、その場で即決せず、これらの数値を整理する時間を社内で確保しておくとよいでしょう。

工程4：契約・体制の確定

提案内容に合意したら、契約を締結し、テストを進める体制を確定させます。

契約形態と秘密保持

契約形態は、成果物の完成を約束する請負契約と、作業時間や人員を提供する準委任契約に大別されます。テスト代行では、業務の性質に応じてどちらか、あるいは組み合わせが選ばれます。どちらが適しているかは、成果物の定義がどこまで明確かによって変わります。テスト範囲と成果物が明確に固まっているなら請負が向きますが、仕様が流動的で柔軟にテストを進めたい場合は準委任のほうが扱いやすい、というのが一つの目安です。自社のプロジェクトがどちらの性質に近いかを意識して、提案内容と照らし合わせるとよいでしょう。

また、システムの仕様やデータを外部に共有するため、秘密保持契約（NDA）の締結はほぼ必須です。個人情報や本番に近いデータを扱う場合は、テストデータの取り扱いルールや作業環境のセキュリティ要件も、この段階で明文化しておくと安心です。

窓口とコミュニケーション手段を決める

体制確定では、双方の窓口担当者を明確にし、不具合の報告方法や進捗共有の頻度、使用するツール（課題管理ツールやチャットなど）を取り決めます。窓口が曖昧なまま始めると、質問の往復に時間がかかり、テストのスピードが落ちます。誰がどの判断をするのかを最初に決めておくことが、後半工程の円滑さに直結します。

具体的には、次のような運用ルールを着手前に固めておくと、実行フェーズで迷いがなくなります。

• 不具合報告の起票先と記載フォーマット（再現手順・重要度区分など）
• 仕様に関する質問の連絡先と回答までの目安時間
• 進捗共有のタイミング（日次・週次・マイルストーンごとなど）
• 仕様判断が必要なときの意思決定者は誰か

特に「仕様に関する質問への回答速度」は、テストの進行スピードを大きく左右します。テスト担当者は実行中に必ず疑問にぶつかりますが、その回答が滞ると手が止まり、工数が膨らみます。依頼側として、質問に素早く答えられる体制を社内に用意しておくことも、円滑な進行の鍵になります。

工程5：テスト設計（テスト計画・テストケース作成）

契約と体制が固まると、いよいよ実作業のフェーズに入ります。最初のステップがテスト設計です。

テスト計画とテストケースの作成

テスト設計では、まずテストの方針・スコープ・スケジュール・体制・合否基準などをまとめたテスト計画を立て、続いて具体的なテストケース（テスト項目）を作成します。テストドキュメントの種類としては、テスト計画書・テストケース仕様書・不具合レポートといった文書体系が知られています（かつてのIEEE 829は、現在は後継のISO/IEC/IEEE 29119として体系化されています）。重要なのは、どの文書を作るかは案件の規模やリスクに応じて取捨選択し、作ると決めた文書は一定のフォーマットに沿って整えるという考え方です。この前提で文書を揃えておくと、抜け漏れの少ない設計につながります。テスト技法の体系については、JSTQB（日本ソフトウェアテスト技術者資格認定委員会）が公開する認定資格のシラバスも参考になります。

優先順位付けまでがテスト設計

テストケースを列挙して終わりにしないことが重要です。リー・コープランド氏『はじめて学ぶソフトウェアのテスト技法』でも、限られた時間の中では何をどこまでテストするかの判断が不可欠であることが強調されています。テスト項目を、重要度・リスク・確認のしやすさといった観点で優先順位付けするところまでが、本来のテスト設計です。

私たちの現場の振り返りでも、「作業時間の割り振りが難しかった」という課題は、突き詰めると優先順位付けが不十分だったことの裏返しでした。限られた時間の中ですべてのケースを同じ密度でテストすることは現実的ではありません。だからこそ、どこに時間を割くかの判断が品質を左右します。依頼側としては、どの機能がビジネス上クリティカルか、どこで過去にバグが出やすかったといった情報を共有することで、代行側の優先順位付けの精度を高められます。「この決済まわりは絶対に落とせない」「この管理画面は社内利用なので多少緩くてよい」といったビジネス上の温度感は、依頼側にしか分からない貴重な情報です。

依頼側のレビューが品質を決める

完成したテスト計画やテストケースは、依頼側がレビューする工程を必ず設けましょう。ここで「この観点が抜けている」「この機能は対象外でよい」といったフィードバックを返すことで、実行フェーズに入ってからの手戻りを大幅に減らせます。一連の工程の中で、依頼側が品質に最も影響を与えられるチェックポイントがこのレビューです。

工程6：テスト実行・不具合報告

テスト設計が固まったら、合意したテストケースに沿ってテストを実行していきます。

実行中の報告サイクル

テスト実行中は、検出した不具合を随時報告してもらうのが一般的です。報告には、再現手順、期待される結果と実際の結果、発生環境、重要度（致命的・重大・軽微などの区分）といった情報が含まれます。これらが整理されていると、開発側での修正がスムーズに進みます。

実行フェーズでは、日次や定例での進捗共有を設定しておくと、消化したテストケース数や検出した不具合の傾向をリアルタイムに把握できます。問題の兆候を早期につかめれば、リリース判断の前倒しや追加対応の検討にも余裕が生まれます。たとえば、序盤から重要度の高い不具合が想定以上に出ている場合は、開発側の修正リソースを早めに確保したり、リリース時期そのものを見直したりといった判断を前倒しできます。報告が最後にまとめて来るのではなく、進行中に小刻みに共有される体制であれば、PMとしての打ち手の選択肢が広がります。

不具合の修正と再テスト

報告された不具合を開発側で修正したあとは、修正が正しく反映されているかを確認する再テストを行います。そして、修正によって他の箇所に影響が出ていないかを確かめる回帰テストは、原則として実施するものと考えてください。「念のため時々やる」任意の作業ではなく、修正が入れば影響範囲の確認はセットで必要になります。デグレ（既存機能の劣化）を防ぎたいなら、ここは省略できない工程です。

そのうえで実務上の論点になるのが、回帰テストをどこまでの範囲で行うか（全体を回すのか、影響範囲の差分だけに絞るのか）です。この範囲の取り決めと、再テスト・回帰テストが見積に含まれているかは、工程3の段階で必ず確認しておきたいポイントです。修正と再テストのキャッチボールを何回まで想定するかもあわせてすり合わせておくと、スケジュールと費用の見通しが立てやすくなります。

工程7：結果報告・レビュー

テスト実行が一区切りすると、結果をまとめた報告を受け取ります。テスト代行の進め方の終盤で、品質の状態を可視化する重要な工程です。

報告書に含まれる主な内容

テスト報告書には、おおむね次のような情報が整理されます。

• 実施したテストの範囲と消化状況（消化率）
• 検出した不具合の件数と重要度別の内訳
• 未修正・未解決として残っている課題
• 品質に関する所見やリスクの評価

これらの情報は、リリースの可否を判断するための材料になりますし、クライアントや社内への品質報告の根拠としても活用できます。受託開発では、クライアントに対して「どこまで品質を確認したか」を客観的に示せること自体が大きな価値になります。第三者の視点でテストを行った報告書は、社内のエンジニアによる自己申告よりも説得力を持ち、納品時の信頼関係づくりにも寄与します。

報告を受け取ったら、数値をただ眺めるのではなく、「残っている未解決の課題はリリースを止めるほどのものか」「検出された不具合の傾向から、まだ潜んでいそうなリスクはないか」といった観点で読み解くことが大切です。報告書のレビューには、代行会社の担当者に同席してもらい、気になる点を直接質問できる場を設けると理解が深まります。

「いつテストを終えるか」をどう判断するか

報告を受け取ったPMが直面するのが、「これでテストを終えてよいのか」という判断です。前掲『はじめて学ぶソフトウェアのテスト技法』では、テストの終了を判定する単一の絶対的な基準は存在しないとされ、複数の基準を組み合わせて判断すべきだと説かれています。具体的には、テストカバレッジの目標達成、検出される不具合の発生率が一定のしきい値以下に低下したこと、追加でテストを続けるコストが見込まれる損害を上回ること、そしてプロジェクトチームとしての合意といった観点です。

代行会社からの報告は、これらの判断材料を提供してくれるものです。「いいから出荷しろ」という勢いだけで決めるのではなく、報告書の数値と所見をもとに、根拠を持って終了判断を下せる状態をつくることが、後悔しないリリースにつながります。

工程8：納品・振り返り

最後の工程が、成果物の納品と振り返りです。

納品される成果物

契約で取り決めた成果物が納品されます。一般的には、テスト計画書、テストケース一覧、テスト結果（消化状況）、不具合報告書、テスト総括報告書などです。これらは単なる納品物ではなく、社内に蓄積される品質資産になります。次回以降のテストや、同種案件の見積の精度向上にも役立つため、整理して保管しておくことをおすすめします。

特にテストケース一覧は、繰り返し実施する回帰テストの土台として再利用できます。一度作り込んだテストケースがあれば、次のリリースでは差分だけを追加すればよく、ゼロから設計し直す必要がなくなります。納品物を「使い捨て」にせず資産として運用していくことが、テスト体制を継続的に強化していくうえでの近道です。納品時には、成果物の格納場所やフォーマットについても確認し、社内で誰でも参照できる状態にしておくとよいでしょう。

振り返りで次につなげる

一連のテストが完了したら、代行会社と簡単な振り返りを行うと効果的です。うまくいった点、認識がズレた点、次回改善したい点を共有しておくと、二回目以降の依頼では立ち上がりが格段に速くなります。実際、私たちの現場でも、一度全体像を把握した経験があれば次のプロジェクトはよりスムーズに進められるという声が上がっています。テスト代行は、回を重ねるほど依頼側と代行側の連携が洗練され、コストパフォーマンスが高まっていく取り組みでもあります。

公的な品質指標も判断の補助線になる

社内での品質基準づくりや、テスト工数の妥当性を検討する際には、独立行政法人情報処理推進機構（IPA）が公開しているソフトウェア開発分析データ集のような公的な統計も参考になります。自社の数値を客観的な指標と照らし合わせることで、報告内容の評価や次回計画の精度を高められます。

依頼前に必ず確認しておきたいチェックリスト

各工程に散らばった判断ポイントのうち、初めての外注で失敗を防ぐために契約前に潰しておきたい項目を、一覧にまとめておきます。月曜からそのまま確認に使える単位で整理しました。

• テスト範囲（対象機能・テストレベル・テストタイプ）と、あえてテストしない対象外範囲を書面で確定したか
• 担うテストレベルがシステムテスト〜受入のどこか、認識が双方で揃っているか
• 見積の内訳（設計まで含むか・報告書の粒度・再テストと回帰テストの費用）を社間で同じ条件に揃えて比較したか
• 回帰テストの対象範囲（全体か差分か）を見積段階で握ったか
• 契約形態（請負／準委任）が自社の仕様の固まり具合に合っているか、NDAとデータ取り扱いルールを明文化したか
• 窓口担当・不具合報告フォーマット・仕様質問の回答目安時間・意思決定者を着手前に決めたか
• 兼任工数と本番障害の対応コストという自社固有の数値を集め、費用対効果の試算を用意したか

このチェックリストを依頼前にひととおり確認しておくと、合意形成フェーズでつまずく要因の大半を事前に取り除けます。

まとめ：全体像を知れば、テスト代行は怖くない

ここまで、テスト代行の進め方を問い合わせから納品までの8工程に分けて解説してきました。改めて流れを振り返ると、前半の問い合わせ・要件共有・見積・契約という合意形成フェーズで認識をきちんと揃えておくことが、後半のテスト設計・実行・報告・納品の質を決めることがおわかりいただけたかと思います。

特に重要なのは、外部委託ならではの情報格差を埋める意識です。対象システムの全体像を共有する時間に最初に投資し、テストケースのレビューに依頼側が主体的に関わることで、成果物の精度は大きく変わります。依頼から納品までの全体像を事前に把握しておけば、初めての外注でも落ち着いて判断でき、社内やクライアントへの説明にも自信を持って臨めるはずです。

テスト体制の見直しや外部委託の活用を検討されている方は、まずは現状の課題を整理したうえで、テスト代行サービスへの相談窓口からお気軽にお問い合わせください。貴社の状況に合わせた進め方を一緒に整理いたします。