テストの工程別外注｜切り分けの判断軸6つ

複数の受託案件を同時に抱え、開発の手が回らないままリリース直前を迎える。エンジニアがテストを兼任し、抜け漏れに気づいたときには時間切れ——。こうした状況で「テストを外に出そう」と考えるのは自然な流れです。

ただ、ここで一気に「全部お願いします」とまとめて出してしまうと、期待した品質も費用対効果も得られないことが少なくありません。カギを握るのは、テストの工程別外注、つまり「どこを出し、どこを残すか」の切り分けです。

テストの工程別外注で成否を分けるのは、工程ごとの向き不向きを見極める判断の型です。本記事では、テスト工程ごとの外注しやすさと、切り分けを決める6つの判断軸を整理します。発注前のPMが、社内や上司への説明にそのまま使える「判断の型」を持ち帰っていただくのがゴールです。

テストの工程別外注が「全工程まとめて」だと失敗する理由

「テストが間に合わない」という悩みは、多くの受託開発の現場で共通しています。専任のQAを置く体制がなく、開発メンバーがテストまで担う運用では、リリース前に負荷が集中しがちです。

そこで外注を検討するのですが、最初の問いを一つ飛ばしてしまうケースがよくあります。それが「そもそもテストを外注すべきか否か」という判断です。この全体判断を整理したうえで、次に来るのが「どの工程を外注するか」です。外注の是非そのものを迷っている段階であれば、まずテストを内製すべきか外注すべきかの判断軸を整理した記事で全体像を確認しておくと、以降の切り分けがぶれません。

丸投げが生む情報格差

全工程をまとめて外部に委ねる「丸投げ」が、最大の失敗要因になります。理由は、外注先には開発の経緯や裏仕様が自然には伝わらないからです。

内製であれば、実装した本人が「この画面は特殊な業務ルールで動く」と暗黙のうちに知っています。ところが外部の担当者は、その背景を共有されない限り、画面の見た目どおりにしかテストできません。

ある業務アプリのテスト代行の現場では、テスト担当者がこう振り返りました。「テスト開始時の理解不足が原因で、本来1回の操作で済む確認作業に、余計な時間を費やしてしまった」。これは特定の現場に限らず、多くの外注案件で共有されている課題です。

内製と違い、外注では開発の経緯・裏仕様・設計思想が自然には伝わらない。この情報格差を放置したまま全工程を渡すと、表面的な動作確認しかできず、肝心の欠陥をすり抜けてしまいます。

「どこを出し、どこを残すか」で品質と費用対効果が決まる

丸投げのもう一つの問題は、費用対効果です。工程によって外注の向き不向きがあるにもかかわらず、一律で出すと、内製したほうが早くて安い工程まで外に出すことになります。

品質は投じた工数だけで決まるわけではありません。IPAが公開するソフトウェア開発分析データ集などの品質・工数データを見ても、どの工程にどれだけ力を入れるかの配分が成果に効くことがうかがえます。テストも同じで、外注する工程を選ぶことが、限られた予算を効かせる第一歩になります。

• 丸投げは情報格差を生み、表面的なテストに終わりやすい
• 工程ごとに外注の向き不向きがある
• 「出す工程」と「残す工程」の切り分けが品質とコストを左右する

テストの工程別外注を考える前に：テスト工程（テストレベル）の4区分をおさらい

切り分けを考えるには、まず「テスト工程（テストレベル）」の全体像を押さえる必要があります。一般的なテストレベルは、単体・結合・システム・受入の4区分で整理できます。

テストの工程別外注とは、この4区分などの工程単位で「出す・残す」を切り分け、必要な工程だけを部分的に外部委託するアプローチのことです。

テストレベル	主な確認対象	一言でいうと
単体テスト	個々のモジュール・関数	部品が単体で正しく動くか
結合テスト	モジュール間の連携	部品同士がつながって動くか
システムテスト	システム全体の振る舞い	要件どおりに全体が動くか
受入テスト（UAT）	業務・利用者の視点	実際の業務で使えるか

この4区分には一本の軸が通っています。上流ほど仕様理解が問われ、下流ほど利用者視点が問われるという軸です。単体テストは実装の内部構造を知っていることが前提になり、受入テストは業務をわかっている人でないと合否を判断できません。

なお、ここで挙げた単体・結合・システム・受入は「テストレベル」であり、後述する探索的テストや回帰テストは実施レベルではなく「テストタイプ（テスト活動）」にあたります。両者は本来別の分類軸ですが、外注適性を考えるうえでは同じ土俵で並べて判断すると便利なため、本記事では区別を明示したうえで併記します。

テストレベルの定義そのものは、ソフトウェアテスト技術者資格を運営するJSTQBの公開情報でも標準的な枠組みとして整理されています。用語の共通認識を持っておくと、外注先との会話もスムーズになります。各テストレベルの詳しい実施手順や技法には本記事では踏み込みませんので、「どのレベルを外注に回すか」の判断に絞って読み進めてください。

テスト工程・種類別の外注しやすさマッピング

4区分を押さえたところで、いよいよ外注しやすさの整理に入ります。結論から言うと、工程・種類ごとに外注適性は明確に分かれます。

単体テストは開発側に残すのが基本

単体テストは、実装のコードや内部構造と密接に結びついています。どのモジュールが何を返すべきかを判断するには、実装者と同じレベルの知識が要ります。

そのため単体テストは開発側に残すのが基本です。外部に切り出すと、実装知識のやり取りに手間がかかり、かえってコストと責任分界が曖昧になります。開発者がテストを兼任すること自体の限界については、開発者のテスト兼任が限界を迎える見極め方をまとめた記事で別途整理していますが、単体テストに限れば「兼任でも開発側で持つ」のが原則です。

結合・システムテストは外注向き

一方、結合テストとシステムテストは外注に向いています。仕様書や画面をもとに「要件どおりに動くか」を確認する作業が中心で、定型化しやすいためです。

むしろ、実装者ではない独立した視点が入ることで、開発チームが見落としがちな挙動に気づけるという利点もあります。第三者の目が品質に効く典型的な工程です。

探索的・回帰テストも外注向き（レベルではなくタイプ）

システムを幅広く触りながら欠陥を探す探索的テストや、変更のたびに繰り返す回帰テストも、外注と相性が良い領域です。これらはテストレベルではなくテストタイプにあたりますが、外注適性を見るうえでは工程と並べて判断できます。

とくに回帰テストは繰り返し性が高く、同じ手順を安定して回す代行と噛み合います。外注の観点では「繰り返す作業を外に出して社内リソースを空ける」という発想が有効です。

受入（UAT）は自社主導、外注は支援まで

受入テストは、実際の業務や利用者の視点で「使えるか」を判断する工程です。合否の基準は業務側にあり、外部だけでは判断しきれません。

UATは顧客・自社が主導し、外注はあくまで支援までにとどめるのが原則です。ここは「何を頼めて、何を頼めないか」を線引きしておくと迷いません。

• 支援として外注できること：テスト項目（シナリオ）の作成補助、テストデータの準備、環境構築、実行の代行、結果の記録・報告
• 外部化してはいけないこと：受入の合否判断、業務としての妥当性判断、リリース可否の最終決定

つまり、手を動かす部分は支援を受けつつ、「業務として使えるかを判断する責任」は自社・顧客が握り続けるのが要点です。UATを自社主導で進める段取りは受入テスト(UAT)を自社主導で進める要点をまとめた記事で詳しく扱っています。

以上を一覧にすると、次のように整理できます（探索的・回帰はレベルではなくタイプですが、外注適性の観点で併記します）。

テスト工程・種類	分類	外注適性	主な理由
単体テスト	レベル	△	実装知識と密結合。切り出すと分界が曖昧に
結合テスト	レベル	◎	仕様ベースで定型化しやすく独立視点が効く
システムテスト	レベル	◎	要件との突合が中心で第三者検証に向く
探索的テスト	タイプ	○	幅広い操作で欠陥を発見、独立視点が有効
回帰テスト	タイプ	◎	繰り返し性が高く代行と相性が良い
受入テスト（UAT）	レベル	支援のみ	業務判断は自社主導、外部は支援まで

テストの工程別外注の切り分けを決める6つの判断軸

レベル別マッピングは出発点です。実際には案件ごとに事情が異なるため、より細かい判断軸で微調整します。ここで使うのが6つの軸です。

内製寄りに引く2つの軸

まず、テストを社内に残す方向へ引く力です。

• ドメイン知識依存度：業務や仕様の深い理解が必要なほど、外部への引き継ぎコストが跳ね上がります。専門性が高い領域は内製寄りです。
• 機密性・セキュリティ：扱うデータや環境の機密度が高いほど、外部への開示が難しく、内製で持つ判断に傾きます。

外注適性を左右する2つの軸

次に、外注のしやすさを決める力です。

• 仕様変更の頻度：仕様が頻繁に変わる工程は、引き継ぎのやり直しが増え、外注効率が落ちます。安定している工程ほど外注向きです。
• 繰り返し性：同じテストを繰り返す度合いです。回帰テストのように繰り返し性が高い作業は、代行や自動化と相性が良く、外注の効果が出やすい領域です。

発注設計の可否を決める2つの軸

最後に、そもそも発注として成立するかを見る軸です。

• 責任分界点の引きやすさ：「どこまでが外注先の責任か」を明確に線引きできる工程ほど、発注が設計しやすくなります。
• コスト対効果：外注費用に見合う成果が出るかです。内製したほうが早くて安い工程を無理に外に出しても、効果は薄くなります。

6軸の向きを一覧にすると次のとおりです。

判断軸	高いと…	向き
ドメイン知識依存度	引き継ぎコスト増	内製寄り
機密性・セキュリティ	外部開示が困難	内製寄り
仕様変更の頻度	引き継ぎやり直し増	内製寄り
繰り返し性	代行・自動化と好相性	外注寄り
責任分界点の引きやすさ	発注設計が容易	外注寄り
コスト対効果	外注効果が明確	外注寄り

6軸のうち内製寄りの力が強く働く工程は残し、外注寄りが優勢な工程を出す——これが切り分けの基本動作です。

6軸を使った当てはめ例

たとえば、ある基幹業務アプリの改修案件を考えます。業務ロジックが複雑でドメイン知識依存度が高く、機密データも扱う一方、画面数が多く回帰テストの繰り返し性が高い、という状況です。

この場合、業務判断が絡む受入と、実装に密結合する単体は社内に残します。一方で、画面を横断的に確認する結合・システム・回帰テストは、繰り返し性と定型化のしやすさから外注に回す、という切り分けが見えてきます。品質と費用対効果のバランスをとる判断は、公的な工数・品質データも一つの後ろ盾になります。

6軸を1つずつ当てはめると、切り分けの根拠がさらに明確になります。

判断軸	この案件での状況	示す方向
ドメイン知識依存度	業務ロジックが複雑で高い	単体・受入は内製
機密性・セキュリティ	機密データを扱う	環境分離できる範囲のみ外注
仕様変更の頻度	改修は多いが画面仕様は安定	安定した画面は外注可
繰り返し性	画面数が多く回帰が重い	回帰は外注が有効
責任分界点の引きやすさ	画面単位で範囲を切りやすい	結合・システムは外注設計しやすい
コスト対効果	兼任負荷が高く効果が出やすい	繰り返し工程の外注が効く

6軸を案件の実情に照らして1つずつ当てはめると、「なぜこの工程を出すのか」を一言で説明できます。軸ごとの向きが割れる工程は、無理に外注せず内製に寄せておくと安全です。判断に迷ったら、内製寄りの軸が2つ以上強く効いている工程は残す、と決めておくと運用がぶれません。

部分委託の設計 — スモールスタート・責任分界点・引き継ぎ

切り分けが決まったら、次は「部分委託をどう設計するか」です。ここを詰めないと、せっかくの切り分けが機能しません。

まずは1工程からスモールスタートする

6軸で切り分けた結果を、いきなり全部まとめて外注に回す必要はありません。むしろ、最初から複数工程を同時に切り出すと、引き継ぎも責任分界も一度に増え、かえって立ち上がりが重くなります。

最初は繰り返し性が高く効果の出やすい1工程からスポットで小さく始めるのが現実的です。回帰テストやシステムテストの一部など、成果と範囲を見きわめやすいところから着手し、運用が回ってから対象を広げていきます。

• 繰り返し性が高い工程（回帰テストなど）を最初の1本に選ぶ
• 範囲を1リリース分・1機能分などに区切ってスポット委託する
• 引き継ぎ・報告・不具合の受け渡し方を小さな範囲で試す
• 手応えを確認してから、対象工程を段階的に広げる

この進め方なら、社内の運用負荷を抑えつつ、外注先との連携パターンを低リスクで確立できます。

責任分界点は「成果物と判定基準」で定義する

外注でもめる原因の多くは、責任の境界が曖昧なことにあります。「テストしてもらったはずのバグが漏れていた」というトラブルは、たいてい範囲の認識がずれています。

責任分界点は「どの成果物を、どの判定基準で合格とするか」で定義します。たとえば「結合テストのテスト項目書に沿って全項目を実施し、不具合報告書として提出する。合否判定は発注側が行う」といった具合に、成果物と判定の主体を書き分けます。

• 外注先が担う工程の範囲を明示する
• 提出される成果物（テスト項目書・実施結果・不具合報告）を定義する
• 合否判定を誰が行うかを決める
• 未着手・未確認の扱いを取り決めておく

引き継ぎ情報の設計

丸投げの失敗要因が情報格差だったことを思い出してください。部分委託でも、この格差を埋める段取りが要ります。

外注先に全体像や裏仕様を渡すフェーズを、意図的にスケジュールへ組み込むことが肝心です。キックオフで全体像を共有し、実際に画面を一緒に触りながら業務の流れを説明する時間を確保します。ある現場の振り返りでも、「最初に全体像を理解する時間を設けることが、結果的に作業時間の短縮につながる」という声が挙がっています。急がば回れで、理解フェーズへの投資が全体の効率を押し上げます。

渡すべき情報は、あらかじめリスト化しておくと漏れを防げます。最低限、次の項目は初期段階で共有しておきましょう。

• システムの全体像：何のためのシステムで、誰がどう使うのか
• 裏仕様・業務ルール：画面からは読み取れない特殊な条件分岐や制約
• 過去の不具合傾向：これまでどこで欠陥が出やすかったか
• 優先度の高い確認ポイント：業務上、絶対に落とせない箇所
• テスト環境と権限：どのアカウントで、どこまで操作してよいか

引き継ぎは一度きりの資料送付ではなく、対話しながら全体像を渡す時間として設計します。資料を投げて終わりにすると、丸投げと同じ情報格差が部分委託の中で再現してしまいます。

準委任と請負のどちらで出すか

部分委託では、契約形態も設計要素です。成果物と合否基準を明確に固定できるなら請負、探索的に進めて柔軟に範囲を調整したいなら準委任、といった向き不向きがあります。詳しくは準委任と請負のどちらで外注するかを整理した記事で判断軸を解説しています。

費用対効果を上司に説明する — 試算の観点

工程別外注は、上司やクライアントに「なぜ外注費をかけるのか」を問われる場面がつきものです。ここで効くのが、費用対効果を筋道立てて説明する型です。厳密な金額を出す前でも、次の観点で「効いている理由」を示せます。

外注費そのものではなく、外注で空いた社内リソースが生む価値と、後工程で減るコストで語ると説得力が増します。

費用対効果を語る4つの観点

外注の価値は、支払う費用だけを見ると割高に映りがちです。しかし実際には、外に出したことで社内に生まれる時間や、避けられる後工程のコストまで含めて初めて全体像が見えてきます。次の4つの観点で棚卸しすると、説明の骨格ができます。

• 兼任エンジニアの工数を別作業に振り向けられる価値：テストを外に出した分、エンジニアが本来の開発・設計に時間を戻せる。空いた工数を何に充てられるかを示す
• リリース後のバグ対応コストの削減：第三者検証で欠陥を早く見つけられれば、本番障害・問い合わせ対応・緊急修正といった後工程のコストを抑えられる
• 繰り返し工程の平準化：回帰テストのように毎リリース発生する作業を外に出すと、社内の繁閑の波をならせる
• 属人化リスクの低減：手順が外部と共有されることで、特定メンバーへの依存を下げられる

この4点は、いずれも「外注費という支出」に対する「見えにくい便益」です。数字にしにくいものほど、あらかじめ言語化しておくと稟議の場で強い材料になります。

「減る費用・生まれる時間」で試算を組み立てる

観点が揃ったら、次はそれを試算の形に落とします。ポイントは、外注費を「コスト」ではなく「投資」として並べ、対になる効果を横に置くことです。たとえば次のような整理ができます。

試算項目	外注しない場合	工程別外注する場合
テスト実施の担い手	兼任エンジニアが実施	外注先が結合・回帰を担当
エンジニアの空き工数	ほぼ生まれない	開発・設計に再配分できる
リリース後の障害対応	見落とし由来の障害が残りやすい	第三者検証で事前に削減
繁忙期の負荷	特定メンバーに集中	繰り返し工程を外に逃がせる

試算は「どの費用が減り、どの時間が生まれるか」を対で並べると、上司にもクライアントにも伝わります。具体的な金額は案件ごとに異なるため、まずはこの観点で構造を整理します。そのうえで自社の実績値（エンジニアの単価、過去の障害対応工数など）を当てはめれば、捏造に頼らず現実的な試算に落とし込めます。

数字が揃わない段階でも、「外注しなければこの工数は兼任エンジニアが背負い続ける」という事実を示すだけで、判断材料としては十分に機能します。

テストの工程別外注でよくある失敗3つと回避策

現場で繰り返し起きる失敗を3つ挙げます。いずれも「切り分け」と「情報設計」の甘さから生じます。

失敗	なぜ起きる	回避策
全工程まる投げ	情報格差が埋まらず、表面的テストに終わる	出す工程を絞り、全体像を渡すフェーズを設ける
単体テストまで外注	実装知識と密結合し、コスト過多・分界が曖昧に	単体は開発側に残し、結合以降を外注する
UATを丸投げ	業務・利用者視点の判断を外部化できず受入責任が宙に浮く	UATは自社主導、外注は支援業務までに限定する

補足すると、それぞれ次のような症状として表れます。

• 全工程まる投げ：報告されるバグが浅く、リリース後に業務上の重大な欠陥が噴出する
• 単体テスト外注：仕様確認のやり取りが増え、想定より工数も費用も膨らむ
• UAT丸投げ：本番で「そもそも業務で使えない」と発覚し、誰の責任か曖昧になる

いずれの症状も、外注の初期段階では見えにくいのが厄介なところです。テスト報告書の見た目は整っていても、確認の深さが浅ければ、問題はリリース後に一気に表面化します。だからこそ、着手前の切り分けと情報設計が効いてきます。

3つの失敗はすべて、「残すべき工程を出した」か「情報を渡さずに出した」かのどちらかに帰着します。裏を返せば、切り分けと引き継ぎ設計さえ押さえれば、大半は避けられます。発注前のチェックとして、次の3点を自問しておくと安全です。

• この工程は、内製寄りの軸（ドメイン知識・機密性・仕様変更頻度）が強く効いていないか
• 外注先に渡すべき全体像・裏仕様を、対話で伝える時間を確保したか
• 合否判定の主体と成果物を、契約・仕様の段階で明文化したか

まとめ：テストの工程別外注は「レベル×6軸」で切り分ける

テストの工程別外注は、勢いで全部を出すものではありません。判断には型があります。

1. レベル・種類で当たりをつける：単体は残す、結合・システム・回帰は外注向き、UATは自社主導で支援のみ
2. 6軸で微調整する：ドメイン知識依存度・機密性・仕様変更頻度・繰り返し性・責任分界・コスト対効果で内製寄りか外注寄りかを判断
3. 小さく始めて部分委託を設計する：まず1工程からスポットで着手し、責任分界点を成果物と判定基準で定義し、情報格差を埋めるフェーズを組み込む

この型に沿えば、「なぜこの工程は残し、この工程は出すのか」を上司やクライアントに筋道立てて説明できます。費用対効果の説明が求められる場面でも、判断の根拠を示せるはずです。

発注準備の具体的な進め方は、依頼から納品までの流れをまとめた記事で段取りを確認できます。

よくある質問

Q. 外注しやすいテスト工程はどれですか。 結合テスト・システムテスト・回帰テストが外注に向きます。仕様や画面をもとに定型的に確認でき、独立した第三者の視点が品質に効くためです。とくに回帰テストは繰り返し性が高く、代行と相性が良い領域です。逆に単体テストは実装知識と密結合するため、開発側に残すのが基本です。

Q. 受入テスト（UAT）は外注できますか。 テスト項目の作成補助・データ準備・実行代行といった支援は外注できますが、受入の合否判断や業務としての妥当性判断は外部化できません。UATは自社・顧客が主導し、外注は支援までにとどめるのが原則です。手を動かす部分を任せても、リリース可否の最終判断は自社で握り続けます。

Q. 工程別外注は何から始めればよいですか。 繰り返し性が高く効果の出やすい1工程から、スポットで小さく始めるのがおすすめです。回帰テストやシステムテストの一部を1リリース分などに区切って委託し、引き継ぎと報告の型を確立してから対象を段階的に広げると、社内負荷を抑えつつ低リスクで進められます。

Q. 単体テストはどんな場合でも外注できませんか。 原則は開発側に残すのが基本です。単体テストは実装のコードや内部構造と密結合しており、外部に切り出すと実装知識のやり取りにかえって手間がかかるためです。ただし、テストコードの整備方針や自動化基盤の構築を専門会社に相談する、といった形の支援はあり得ます。実行そのものを丸ごと外に出すより、開発チームが単体テストを回しやすくする支援を受ける、と考えると現実的です。

どの工程から外注すべきか切り分けに迷う場合は、テスト体制の現状をふまえてご相談ください。現状の体制と課題を整理したうえで、無理のない切り分けを一緒に考えられます。