ソフトウェアテストの外注——種別ごとの線引きと、発注前に決める5つ【2026年版】

2026.09.14|ノウハウ|文: 中元 亨

リリースが2か月後に迫っているのに、テストはエンジニアが交代で見ている。テストに入るとその分だけ開発が止まる。外注できるなら頼みたいが、何をどこまで任せられるのか分からない——開発責任者の方から、こうしたご相談をいただくことがあります。稼働後の不具合が続いていて、開発会社のテストを信じてよいのか分からない、という別方向のご相談も同じくらい多いのが実情です。

先に結論を書きます。テストの外注で結果が変わるのは、外注先の技量ではありません。発注側が「何をもってテスト完了とするか」を決めているかどうかです。テストは網羅する作業ではなく、限られた時間で守る範囲を選ぶ設計だからです。画面の組み合わせを数えれば、ケースは無限に増えます。だから工数は「どこまでやるか」で決まり、その判断は業務を知っている発注側にしかできません。

発注前に決めるのは5つだけです。テスト対象、観点、完了基準、環境、データ。この5つが決まっていれば、どの会社に見積もりを依頼しても比較できますし、成果も測れます。逆にここが空欄のまま発注すると、外注先は自社の標準でテストケースを作ります。その標準があなたの事業リスクと一致している保証はありません。

私はTALENTBASE VIETNAMでCOOを務めています。2018年以降、約100社のご相談を受けてきました。正直に申し上げると、当社はテスト専門の会社ではありません。開発の体制を提供する立場です。ですから、テスト工程だけを切り出して専門会社に委託したほうが合理的な場合には、その旨を率直にお伝えします。一方で、継続的に改修が入るプロダクトでは、開発とQAを同じチームに持つほうが結果的に安く収まることが多いのも事実です。当社のラボ型は最小構成が日本人PM+2〜3人月で月額約80万円から、1名から最短2週間で開始でき、増員は約1週間です。

この記事では、外注を検討するタイミング、テスト種別ごとの外注向き・内製向きの線引き、第三者検証の意味、発注前に決める5つ、費用の考え方、そして外注先の選び方とノウハウの残し方を整理します。読み終えたら、自社のテスト工程を種別ごとに書き出して、外に出すものと社内に残すものを仕分けてみてください。

目次
  1. どのテストを外に出すか
  2. 外注を検討するタイミング
  3. テスト種別ごとの外注向き・内製向き
  4. 第三者検証は、技量ではなく視点の独立性
  5. 発注前に決める5つと、費用の考え方
  6. 対象・観点・完了基準・環境・データ
  7. 費用は何で決まるか
  8. 自動化とAIをどう考えるか
  9. 外注先の選び方と、ノウハウを残す運用
  10. 発注前に確認する6項目
  11. 報告の粒度と、資産として受け取るもの
  12. よくある失敗
  13. よくある質問
  14. Q1. テスト仕様書は自社で用意する必要がありますか
  15. Q2. どのくらいの期間から依頼できますか
  16. Q3. 本番データを渡す必要がありますか
  17. Q4. 海外に委託するとコミュニケーションが不安です
  18. Q5. テストだけを依頼することはできますか
  19. まとめ: 外注の結果を決めるのは技量ではなく完了基準

どのテストを外に出すか——種別ごとの線引きと、第三者検証の意味

外注するテスト種別と内製に残す範囲を仕分ける作業

テストを外注するかどうかの前に、どのテストをという問いに答える必要があります。テストは一枚岩ではなく、種別ごとに性質が違うからです。外注に向くものと、社内に残すべきものがはっきり分かれます。

外注を検討するタイミング

次のどれかに当てはまるなら、検討する価値があります。ひとつ、バグが繰り返し流出している。ふたつ、テストの担当者と開発の担当者が同じ人である。みっつ、重要なリリース(顧客向けの公開、法改正対応)が控えている。よっつ、専任のQAエンジニアが社内にいない。いつつ、リリース頻度が上がってテスト工数が追いつかない。

約100社のご相談を受けてきましたが、2番目のケースが最も多い印象です。人が足りないので、書いた本人が確認する。悪循環の起点はたいていここにあります。

テスト種別ごとの外注向き・内製向き

種別ごとに仕分けると、判断が具体的になります。

テストの種別

外注向きか

理由

単体テスト

内製

実装と一体で、コードを書いた流れの中で行う

結合テスト

場合による

仕様が文書化されていれば外注可能

システムテスト・シナリオテスト

外注向き

手順が決まっていて量がある

リグレッションテスト(回帰)

外注向き

繰り返し実行する定型作業。自動化の対象にもなる

互換性テスト(端末・ブラウザ・OS)

外注向き

機材と環境を持つ会社に任せると速い

性能・負荷テスト

外注向き

専用の知見とツールが要る

セキュリティ診断

外注向き

専門性が高く、第三者が行う意味が大きい

受入テスト(UAT)

内製

業務で使えるかの判断は発注側にしかできない

何を守るかの決定・リスク評価

内製

事業の判断そのもの

テスト種別ごとの外注向き・内製向きの線引きと、第三者検証が視点の独立性である理由

線引きの原則は単純です。手順が決まっていて量がある作業は外に出す。何を守るかを決める判断は社内に残す。この2行で、たいていの案件は仕分けられます。

第三者検証は、技量ではなく視点の独立性

開発会社がテストをしているのに不具合が出る、というご相談をよくいただきます。ここで確認したいのは、開発会社の技量ではなく構造です。作った人が検証すると、作ったときの前提を無意識に共有したまま確認することになります。「この画面はこう使うはず」という前提が、そのまま検証の前提になる。第三者検証の価値は、その前提を共有していない人が見る点にあります。

だから、第三者検証を依頼するときも、既存の開発会社を責める必要はありません。「役割を分けたい」という言い方で十分です。当社が手がけた決済アプリの案件では、週次の保守を前提に体制を組みました。継続的に手が入るプロダクトほど、検証の視点を分ける仕組みが効きます。種別の線引きができたら、次は発注前に決めることに進みます。

発注前に決める5つと、費用の考え方

テストの完了基準と環境を決める担当者

ここが記事の中心です。外注先を探す前に、次の5つを決めてください。決まっていれば見積もりは比較できますし、決まっていなければ各社の前提がばらついて比べられません。

対象・観点・完了基準・環境・データ

決めること

内容

記載例

テスト対象

どの画面・機能・API・端末までを範囲にするか

会員登録から決済完了までの12画面、iOS 3世代、Android 3世代

観点

何を確認するのか(機能・表示・性能・権限・異常系)

権限別の表示制御と、決済失敗時の復帰動作を重点

完了基準

何をもってテスト完了とするか

重要度A・Bの不具合が残存ゼロ、Cは一覧化して合意

環境

どの環境で、いつからいつまで使えるか

検証環境を2面、テスト期間中は他チームの改修を凍結

データ

どんなデータを使うか、本番相当か

マスキング済みの本番相当データ。個人情報は含めない

発注前に決める5つ(対象・観点・完了基準・環境・データ)の記載例と、スポット委託と体制で持つ形の費用構造

このうち最も抜けやすいのが完了基準です。「一通り確認する」では基準になりません。不具合の重要度をA・B・Cに分け、どこまでゼロにするかを書いてください。これがあると、テストの打ち切り判断が感覚ではなく合意になります。

環境とデータも軽視されがちです。検証環境が1面しかなく、テスト中に他チームが改修を入れると、不具合の再現ができません。テスト期間中の凍結は、発注側でしか決められないことのひとつです。

費用は何で決まるか——単位と2つの形

見積もりの単位には、人日単価で積む形と、テストケース件数で積む形があります。前者は作業量の見通しが立ちやすく、後者は成果物の量が明確です。どちらでも構いませんが、同じ単位で各社にそろえてもらってください。単位が違うと比較になりません。

体制の形にも2つあります。ひとつはテスト工程だけを切り出してスポットで委託する形。大型リリース前の集中的な検証や、互換性テストのような一時的な作業に向きます。もうひとつは、開発チームの中にQA担当を含めて持つ形です。継続的に改修が入るプロダクトなら、こちらのほうが結果的に安く収まることが多い。毎回のリリースで立ち上げ直す手間がなくなるからです。

当社が提供しているのは後者の形です。ラボ型(準委任)で、最小構成は日本人PM+2〜3人月の月額約80万円から。単価は実務3年で1,500USD、5年で2,000USD、ブリッジSEで3,000USD(1USD=150円換算が目安)と公開しています。テスト担当を1名加えたいといった調整も、増員は約1週間で対応できます。逆に、単発の互換性テストのように量と期間が限定される作業なら、専門会社にスポットで頼むほうが合理的です。

自動化とAIをどう考えるか

自動化は万能ではありません。初期の実装費用がかかり、画面が変わるたびにメンテナンスが発生します。変更の多い画面をいきなり自動化すると、テストコードの保守が新たな負担になります。向いているのは、リグレッションテストのように毎回同じ手順を繰り返す領域です。

2026年時点では、テストケースの作成や観点の洗い出しに生成AIを使う場面も増えました。当社もAIを活用した開発体制を組んでいます。ただし、何を守るかの優先順位はAIが決められません。削るべきは量ではなく、リスクの低い領域のケースです。

外注先の選び方と、ノウハウを残す運用

開発とQAを同じ体制で持つTALENTBASE VIETNAMのチーム

5つが決まったら、相手を選びます。ここでも判断材料は絞れます。実績の数を競う必要はなく、自社の状況に必要な条件だけ確認すれば十分です。

発注前に確認する6項目

確認項目

何を見るか

実績と資格

同じ業界・同じ技術スタックの経験。JSTQBなどの資格保有者の有無

アサインされる人

会社の実績ではなく、担当者の経験年数と担当範囲

テスト設計を任せられるか

ケースの作成から依頼するのか、実行だけ依頼するのか

報告の粒度と頻度

日次か週次か。不具合の起票ルールと重要度の定義

費用の透明性

追加費用が発生する条件。再テストは範囲内か

環境とデータの取り扱い

個人情報を含むデータの扱い、作業場所、機器の管理

私は人材業界の出身で、体制を組む側の視点を持っています。会社の実績より、実際に入る人の経験を確認してください。これはテストに限らず、外注全般に言えることです。

報告の粒度と、資産として受け取るもの

報告書を「不具合が何件出たか」で読んでいる場合は、読み方を変えてください。見るべきは、どの観点でどこを見たかです。件数はテストケースの粒度で簡単に変わります。100件の細かいケースより、重要な導線を押さえた20件のほうが価値が高いことは普通にあります。

報告で確認したいのは、実施したケース数と消化率、観点ごとのカバー状況、未実施の範囲とその理由、不具合の重要度別の内訳、そして残存する既知の不具合の一覧です。この5点が揃っていれば、リリースの判断ができます。

ノウハウを残す方法は明確です。テスト仕様書とテストケースを自社の資産として受け取ってください。契約に成果物として明記すれば済みます。当社も、ドキュメントを納品物に含める運用を標準にしています。次に別の会社へ依頼するときも、同じケースを渡せば立ち上がりが速くなります。

よくある失敗

4つ挙げます。ひとつ、完了基準を決めずに始めること。打ち切りの判断が感覚になります。ふたつ、検証環境が確保できず、テスト期間が後ろ倒しになること。みっつ、報告が件数だけで、何が守られたか分からないこと。よっつ、テストケースを受け取らず、毎回ゼロから作り直すこと。

なお、当社はテスト専門の会社ではありません。単発の検証であれば専門会社のほうが適していると判断した場合は、その旨を率直にお伝えします。直近のテスト報告書は、観点で読めましたか。

よくある質問

テスト外注に関する質問に答える担当者

テストの外注について、実務でよく届く質問に答えます。いずれも初めてテスト工程を外に出す企業から繰り返し聞かれる内容です。

Q1. テスト仕様書は自社で用意する必要がありますか

テスト設計から依頼することもできます。ただし、何を重点的に守るかの観点は発注側が示してください。業務のリスクを知っているのは発注側だからです。

Q2. どのくらいの期間から依頼できますか

スポットの検証なら数日から対応する会社もあります。当社のラボ型は1名から、面談を経て最短2週間で開始でき、増員は約1週間です。1か月単位でのリプレイスメントにも対応しています。

Q3. 本番データを渡す必要がありますか

個人情報を含むデータは、マスキングするか、テストデータを生成して渡してください。渡さずに済む設計にしておくほうが、契約も運用も簡単になります。

Q4. 海外に委託するとコミュニケーションが不安です

当社はベトナムとの時差が2時間で、日本人PMがフロントに立ちます。報告様式と会議の頻度を日本語で設計できるため、書面でのやり取りが中心になります。

Q5. テストだけを依頼することはできますか

可能ですが、継続的に改修が入るプロダクトでは開発とQAを同じ体制で持つほうが安く収まることが多いです。状況を伺ったうえで、テスト専門会社のほうが適していればその旨もお伝えします。判断の材料をまず一緒に。

まとめ: 外注の結果を決めるのは技量ではなく完了基準——発注前に5つを決める

テストの外注で結果が変わるのは、外注先の技量ではありません。発注側が「何をもってテスト完了とするか」を決めているかどうかです。テストは網羅する作業ではなく、限られた時間で守る範囲を選ぶ設計だからです。線引きの原則は単純で、手順が決まっていて量がある作業は外に出し、何を守るかを決める判断は社内に残します。システムテスト、リグレッションテスト、互換性テスト、性能テスト、セキュリティ診断は外注に向きます。単体テストと受入テスト、そしてリスクの評価は社内に残してください。

発注前に決めるのは5つです。テスト対象(画面・機能・端末の範囲)、観点(機能・表示・性能・権限・異常系のどこを重点にするか)、完了基準(重要度A・Bの不具合が残存ゼロなど)、環境(検証環境の面数と、テスト期間中の改修凍結)、データ(マスキング済みか、本番相当か)。この5つが決まっていれば、どの会社に見積もりを依頼しても比較できます。見積もりの単位は人日か件数かのどちらかにそろえてもらってください。

開発会社がテストしているのに不具合が出るという相談は、技量ではなく構造の問題です。作った人が検証すると、作ったときの前提を共有したまま確認することになります。第三者検証の価値は、その前提を持たない人が見ることにあります。外注先の選定では、会社の実績よりアサインされる人の経験を確認し、報告は件数ではなく観点で読んでください。テスト仕様書とケースは成果物として受け取れば、次の会社に渡せる資産になります。契約形態の選び方はラボ型開発とSESの違い、見積もりの読み方はシステム開発の見積もりの内訳もあわせてご覧ください。当社のラボ型は最小構成が日本人PM+2〜3人月で月額約80万円から、1名・最短2週間で開始でき、増員は約1週間です。現在の体制と要件をお聞かせいただければ、テスト体制の組み方を含めてお答えします。テスト専門会社のほうが適していると判断した場合は、その旨も率直にお伝えします。

無料相談する 記事一覧へ戻る

まずは無料相談から

現在の体制と要件をお聞かせください。同等品質でどこまで下げられるか、概算見積もりでお答えします。

資料ダウンロード 無料相談する