LASSIC Media らしくメディア
ソフトウェアテスト外注で体制構築する進め方と実践ポイント
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- ソフトウェアテスト外注で体制構築するには、テスト工程の種類とスコープの明確化が出発点になります
- 外注先には技術スキルだけでなく、テスト自動化対応力とドキュメント品質を評価する視点が欠かせません
- 費用・契約形態・品質指標（KPI）をあらかじめ設計することで、外注後のリスクを抑えた体制を構築できます
目次
ソフトウェアテスト外注による体制構築とは
ソフトウェアテスト外注による体制構築とは、自社では確保が難しいテストエンジニア・QA（品質保証）専門人材を外部パートナーに委託し、テスト工程全体を組織として機能させる取り組みです。単発の「バグ出し」依頼とは異なり、テスト計画・実施・バグ管理・品質報告まで一連の工程を外注先と協働で設計するのが特徴です。
内製とアウトソーシングの役割分担
テスト外注を検討するとき、「すべてを丸投げする」のか「一部の工程だけ委託する」のかを最初に整理することが大切です。多くの現場では、テスト方針の決定・品質目標の設定は自社が担い、テスト設計・実施・バグ報告を外注先が担うという分担が機能しやすいです。
外注先にすべての判断を委ねると、プロダクトへの理解不足から重要なテストケースが抜け落ちるリスクがあります。一方で、自社にテスト専任者がいない場合は、まず外注先のシニアQAエンジニアに方針策定から関与してもらう形も選択肢です。
テスト工程の種類と外注可能な範囲
ソフトウェアテストには複数の工程があり、それぞれ外注適性が異なります。主な工程と特徴を整理します。
| テスト工程 | 主な内容 | 外注適性 | 留意点 |
|---|---|---|---|
| 単体テスト（UT） | 関数・クラス単位の動作確認 | △ 条件付き | コードレビュー権限が必要。 開発チームとの密連携が前提。 |
| 結合テスト（IT） | 複数モジュール間の連携確認 | ○ 適性高 | 仕様書・API定義が整備されている場合に向く。 不明点の即時確認フローが必要。 |
| システムテスト（ST） | 要件に対するシステム全体の動作確認 | ◎ 最も向く | テスト仕様書の品質が外注効果を左右する。 テスト環境の提供が自社側の責任。 |
| 受入テスト（UAT） | ビジネス要件の最終確認 | △ 条件付き | 業務知識が必要。 外注先がビジネス側担当者と直接対話できる体制を整えることが大切です。 |
| 自動化テスト | 回帰テストのスクリプト化・CI/CD組み込み | ○ 適性高 | ツール（Selenium・Appium・Playwright等）の選定は自社主導が望ましい。 スクリプトの保守コストを見込む。 |
IPA「ソフトウェア開発分析データ集2022」*1では、国内ソフトウェアプロジェクトの信頼性（リリース後不具合密度）に関するデータが公表されており、テスト体制の整備状況がプロジェクト品質に直接影響することが読み取れます。
外注先に求めるスキルと選定ポイント
テスト外注先の選定で失敗すると、バグの見落とし・報告書の品質不足・コミュニケーションコストの増大といった問題が生じます。選定時に確認すべき観点を3つに整理します。
テストエンジニアに必要な技術スキル
テスト外注先が備えるべき技術スキルは、対象プロダクトのアーキテクチャによって変わります。Webシステムであればブラウザの動作仕様・REST API・データベース確認の知識が必要です。モバイルアプリ（iOS/Android）であれば、各OSのUIテスト仕様・デバイス固有の挙動への対応力が求められます。
特に確認が必要なのは、テスト設計書を自ら起こせるかどうかです。「渡されたテスト仕様書を実行するだけ」の人材と、「ユーザーストーリーから等価クラス分割・境界値分析でテストケースを設計できる」人材とでは、体制の厚みが大きく異なります。後者のスキルを持つエンジニアの比率を提案段階で確認することをお勧めします。
テスト自動化（Selenium・Appium等）対応力の確認
アジャイル開発・CI/CDを採用しているプロジェクトでは、毎スプリント回帰テストを手動で実施するのは現実的ではありません。自動化テストの対応力は外注先の競争力の中心となっています。
確認すべきツールは、WebテストではSelenium・Playwright・Cypress、モバイルではAppium・XCUITest、APIテストではPostman・REST Assuredが代表的です。さらに、これらをJenkins・GitHub ActionsなどのCI/CDパイプラインに組み込んだ実績があるかを問うことで、対応レベルが明確になります。
自動化スクリプトを外注先が保有したまま契約終了になると、スクリプト資産が失われるリスクがあります。契約時に「スクリプトの著作権・引き渡し」条件を明記しておくことが大切です。
コミュニケーション・ドキュメント力の評価
テスト外注で品質が安定しない原因の多くは、技術力ではなくコミュニケーションにあります。バグレポートの記述が不十分で開発側が再現できない、テスト結果サマリが「合否」だけで詳細が把握できない、といった問題が実務上よく見られます。
選定時にはサンプルのバグレポートや過去のテストサマリ資料の提示を求め、記述の粒度・再現手順の明確さ・優先度分類の妥当性を確認することをお勧めします。また、Jira（課題管理ツール）やSlackへのアクセスをどの程度許可するかも、コミュニケーション設計の一部として事前に定めておく必要があります。
外注で立ち上げるテスト体制の5ステップ
テスト体制を外注で構築するには、単純に「依頼してテストしてもらう」のではなく、双方の役割・責任・品質基準を段階的に積み上げていく設計が必要です。以下の5ステップで進めることで、立ち上げ後の混乱を抑えられます。
ステップ1：テスト方針・スコープ定義（期間の目安：1〜2週間）
外注開始前に、「何を・どこまで・どのレベルでテストするか」を文書化します。テスト対象の機能一覧、優先度付け（重要機能とノンクリティカル機能の分類）、合格基準（バグ密度の許容値など）を自社側で決定します。この段階で方針が曖昧なまま進めると、外注先が独断でテスト範囲を縮小・拡大し、成果物のばらつきが生じます。
ステップ2：外注先の選定とRFP作成（期間の目安：2〜4週間）
RFP（提案依頼書）には、テスト対象システムの概要・使用技術スタック・自動化要否・バグ管理ツール・報告頻度・成果物定義を明記します。複数社に提案を求め、提案書とともにテスト設計のサンプル（対象画面を指定して簡易テストケースを出してもらう）を求めると、実力差が把握しやすいです。
費用のみで選定するとテスト品質が低下するリスクがあります。「検出バグ数への過度な最適化」（バグを多く出すほど評価されると外注先が認識すると、軽微な指摘ばかりが増える問題）を防ぐためにも、費用と品質指標のバランスで評価することが大切です。
ステップ3：テスト計画書・環境整備（期間の目安：1〜2週間）
外注先との合意後、テスト計画書を共同で作成します。計画書には「テスト工程・開始終了日・担当者・テスト種別・ツール・レビュー日程」を含めます。テスト環境（ステージング環境・テストデータ・アクセス権）の準備は自社側が担うケースが一般的です。
テスト環境の整備遅延がプロジェクト全体のボトルネックになることがあります。外注先の作業開始日に間に合うよう、環境準備のタスクを自社スケジュールに組み込んでおく必要があります。
ステップ4：テスト実施・バグ管理（実施フェーズ）
テスト実施中は、バグ管理ツール（Jira・Redmine・GitHubのIssues等）での進捗共有が基本です。週次のステータスミーティングで「実施件数・検出バグ件数・重大度別内訳・未解決件数」を報告してもらう体制を整えます。
バグの修正確認（リグレッションテスト）をどちらが担うかも事前に決めておく必要があります。「外注先が検出→自社開発が修正→再テストも外注先」という流れが一般的ですが、リグレッションテストの範囲を絞らないと工数が膨らみます。修正した機能に影響する隣接機能のみに絞るスモークテスト方針を採用すると効率的です。
ステップ5：品質指標の定義とレビュー（継続的に実施）
テスト完了後も「品質が十分かどうか」を判断するには、事前に決めたKPIとの照合が必要です。主な品質指標については後続の章で詳しく解説します。テスト完了レポートには、KPI達成状況・未解決バグの対応方針・次フェーズへの引き継ぎ事項を含めてもらうよう、契約時に成果物定義として明記することをお勧めします。
費用の市場参考値と契約形態の選び方
テスト外注の費用は、対象システムの規模・テスト種別・自動化の有無・期間によって大きく変動します。以下の数値は市場参考値であり、一次資料に基づく確定値ではありません。実際の費用は複数社への見積もりで確認することをお勧めします。
テスト外注の市場参考費用レンジ
テストエンジニアの単価（準委任ベース）は、経験3〜5年のミドルクラスで月額60〜90万円前後が目安とされています（市場参考値・一次資料非確認）。テストリードや自動化スペシャリストのシニアクラスでは月額90〜120万円以上になるケースもあります。
プロジェクト型（請負）での一括受託の場合、小規模Webアプリのシステムテストで数十万〜数百万円の幅があります。テスト設計も含む場合とテスト実施のみの場合では費用が大きく異なるため、見積もり依頼時に「成果物の範囲」を明確に提示することが重要です。
| 費用タイプ | 市場参考レンジ | 適した状況 |
|---|---|---|
| 準委任（月額単価） | 月額60〜120万円／名（経験・スキルにより変動） | 継続的なテスト体制の維持。 アジャイル開発・スプリント対応。 |
| 請負（一括） | 数十万〜数百万円（規模・工程により変動） | リリース前の集中テスト。 成果物・期間が明確な場合。 |
※上記は市場参考値です。一次資料（公的統計・業界調査）による確定値ではありません。実際の発注前に複数社への見積もり取得を推奨します。
請負・準委任の選び方
テスト外注では契約形態の選択が、品質責任の所在とコスト管理に直結します。
請負は「合格基準を満たしたテスト完了報告書を納品する」という成果物で契約するため、品質責任は外注先が持ちます。ただし、仕様変更・追加テストへの対応が変更契約になりやすく、要件が固まっていないプロジェクトでは管理コストが増えます。
準委任はエンジニアの稼働時間に対して報酬を支払う形態で、仕様変更への柔軟な対応が可能です。ただし、品質の最終責任は発注側（自社）が負う点に注意が必要です。アジャイル開発・スプリント単位のテストには準委任が向いており、リリース前の集中テストには請負が適することが多いです。
品質指標（QA KPI）の設計と管理
テスト外注の成果を可視化するには、事前に品質指標を定義することが欠かせません。「テストが終わった」だけでは品質が十分かどうかを判断できないためです。以下の3つの指標が実務上よく使われます。
バグ検出率・テストカバレッジ・再テスト率
バグ検出率（欠陥密度）は、テストケース1,000件あたりのバグ検出数で表します。過去プロジェクトや業界標準との比較により、「十分にテストできているか」の参考指標になります。ただし、バグ数は多ければよいわけではなく、重大度（Severity）別の内訳が重要です。
テストカバレッジは、定義した要件・テストケースに対してどの割合を実施・合格させたかを示します。機能カバレッジ（要件網羅率）と、自動化テストの場合はコードカバレッジ（C0/C1/C2）の両面で管理することをお勧めします。
再テスト率（フェイルリテスト率）は、修正済みバグの再テストで再発した割合です。再テスト率が高い場合、修正品質に問題があるか、バグレポートの再現手順が不十分であることを示します。この指標を設けることで、外注先のバグレポート品質改善を促す効果も期待できます。
| 品質指標（KPI） | 計測方法 | 活用ポイント |
|---|---|---|
| バグ検出率（欠陥密度） | テストケース1,000件あたりの検出バグ数 | 重大度別内訳（Critical/High/Low）も記録することをお勧めします。 単純な総数ではなく重大バグ率で評価する。 |
| テストカバレッジ | 実施テストケース数÷計画テストケース数 | 機能カバレッジの全件達成を目標ラインとする。 自動化テストはコードカバレッジ（C1以上）も参照する。 |
| 再テスト率 | 修正後再テストで再発したバグ数÷修正済みバグ数 | 10%超で外注先にレポート品質の改善を要請する目安とする（市場参考値）。 |
これらのKPIは外注先が自動的に報告してくれるわけではありません。契約の成果物定義に「週次品質レポート（上記KPI含む）」を明記し、レポートフォーマットをキックオフ時に合意しておくことが大切です。
また、テスト外注体制の改善サイクルを回すには、KPIの数値だけでなく「どのモジュールでバグが集中しているか」「テスト設計の網羅性に偏りがないか」という分析視点が必要です。このような品質分析を含めた体制構築を外注先に期待する場合は、PMO支援・QAコンサルタントのスキルを持つ人材の参加を外注仕様に盛り込む必要があります。
内製でテスト体制の改善を担える人材が不在の場合、外注先の品質報告を評価できる立場の人間（QAマネージャー・プロジェクトマネージャー）を社内に置くか、元請（プライムベンダー）として体制全体を管理するパートナーに一括で委託するかの選択が生じます。
まとめ：テスト外注体制構築の3つの判断軸
本稿では、ソフトウェアテストを外注してQA体制を構築する進め方を、工程定義・外注先選定・費用・品質指標の観点で整理しました。要点を3つに集約すると次の通りです。
第一に、テスト工程の種類と外注可能な範囲を明確にすること。単体テストから受入テストまで工程によって外注適性が異なり、スコープを曖昧にしたまま発注すると品質と費用の両面でリスクが生じます。
第二に、外注先選定では技術スキル・自動化対応力・コミュニケーション力の3軸で評価すること。費用のみでの選定はバグ見落としや報告品質の低下につながる可能性があります。提案段階でサンプル成果物の提示を求めることで、実力を確認できます。
第三に、バグ検出率・テストカバレッジ・再テスト率の3指標をKPIとして契約前に設計すること。外注後の品質判断基準を持つことで、体制の継続改善が可能になります。IPA「ソフトウェア開発分析データ集2022」*1が示すプロジェクト品質データを参照することで、テスト工程への早期投資がリスク低減につながることが確認できます。
よくある質問
ソフトウェアテストをすべて外注することはできますか。
技術的にはすべての工程を外注することは可能ですが、テスト方針・合格基準・品質目標の最終判断は自社が担う必要があります。外注先がプロダクトのビジネス要件を深く理解するには時間がかかるため、特に受入テスト（UAT）は自社の業務担当者が主体となり、外注先はサポート役として参加する形が機能しやすいです。全工程外注を選ぶ場合は、元請として体制全体を管理するQAパートナーを起用することをお勧めします。
テスト自動化の外注はどのタイミングで始めるのが効果的ですか。
テスト自動化は、プロダクトのUI・機能仕様が一定程度固まった後に導入するのが効果的です。仕様変更が頻繁な開発初期にスクリプトを書き始めると、変更のたびにスクリプトのメンテナンスコストが発生します。機能が安定してきたリリース後の回帰テストフェーズから自動化を始め、CI/CDパイプラインに組み込んでいくのが実務上よく採られるアプローチです。外注先の自動化エンジニアを準委任で参画させ、スクリプト資産の所有権を自社に帰属させる契約にしておくことも大切です。
テスト外注先のバグレポート品質を上げるにはどうすればよいですか。
バグレポートの品質は、フォーマットとサンプルをキックオフ時に共有することで大きく改善できます。具体的には「再現環境・再現手順（最小ステップ）・期待動作・実際の動作・証跡（スクリーンショット・ログ）・重大度・優先度」を含むテンプレートを提供してください。最初の1〜2週間は報告されたバグレポートに対してフィードバックを返し、品質水準を揃える期間として設けることをお勧めします。再テスト率を定期的にモニタリングすることで、レポート品質の傾向を把握できます。
テスト外注の契約は請負と準委任のどちらが適していますか。
プロジェクトの性質によって異なります。リリース日が決まっており、テスト対象・合格基準が明確な場合は請負が向いています。成果物の品質責任を外注先に持たせられるためです。一方、アジャイル開発でスプリントごとにテスト範囲が変わる場合や、仕様変更が想定される場合は準委任が適しています。ただし準委任では品質の最終責任が発注側に生じるため、外注先の作業品質を確認できる体制（QAリードを自社側に置く）を整えることが重要です。詳しくは派遣・外注の違いに関する記事もご参照ください。
テスト体制の外注にはどのくらいの期間が必要ですか。
外注先の選定から体制が安定するまで、一般的に2〜3カ月程度を見込む必要があります。内訳は、RFP作成・外注先選定が2〜4週間、テスト計画・環境整備が1〜2週間、テスト実施・品質の安定化に4〜8週間というイメージです（規模・複雑さにより変動。一次資料非確認の参考値）。体制を急いで立ち上げると、外注先とのコミュニケーションルール・バグ管理フローの未整備がボトルネックになりやすいです。リリース日から逆算して余裕を持ったスケジュールを設定することをお勧めします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（独立行政法人情報処理推進機構）「ソフトウェア開発分析データ集2022」（2022年9月公表）
