QA外注（テスト外注）の進め方完全ガイド｜費用相場・会社の選び方・失敗しないポイントを解説

リリース前夜に重大なバグが発覚し、ローンチが延期になった経験はありませんか。あるいは本番環境で顧客からバグ報告が相次ぎ、対応に追われた経験をお持ちの方もいるかもしれません。

「開発会社は信頼しているが、自社でのテストだけで本当に大丈夫か」という不安は、システムを外注している事業会社の担当者なら多くの方が感じている課題です。品質保証を開発会社任せにすることのリスクは、開発が進むにつれてじわじわと大きくなっていきます。

その課題を解決する手段のひとつが、QA専門会社への外注（第三者検証）です。しかし、「費用がどのくらいかかるか」「稟議書にどう書けばいいか」「どこに頼めばいいか」「何を準備すればいいか」といった具体的な疑問が先に立って、なかなか一歩踏み出せない方も多いのではないでしょうか。

本記事では、QA外注の基本から、検討すべきタイミングの判断基準、費用相場、外注先の選び方、発注側の準備物、進め方のステップ、よくある失敗パターンまでを一気通貫で解説します。ソフトウェアテストの基礎知識についてはソフトウェアテストとは？種類・手法・プロセスを分かりやすく解説もあわせてご覧ください。

QA外注とは？なぜ第三者検証が必要なのか

QA外注（第三者検証）とは何か

QA外注とは、ソフトウェアの品質保証（Quality Assurance）を開発プロジェクトとは独立したQA専門会社に依頼することです。「第三者検証」とも呼ばれます。

通常の開発プロジェクトでは、開発会社がリリース前にテストを実施します。しかしこの場合、テストを行うのは開発に関わったエンジニアであることが多く、自分たちの書いたコードに対して客観的な視点を保つことは難しいという問題があります。

QA外注では、開発に関与していない第三者の専門家が客観的な視点でソフトウェアをテストします。これにより、開発チームでは見落としがちなバグや品質問題を検出できます。

開発会社内テストとの違い

観点	開発会社内テスト	QA外注（第三者検証）
客観性	開発者自身がテストするため主観が入りやすい	第三者が検証するため客観性が高い
専門性	テストは開発の「おまけ」になりがち	テスト専業のため品質管理の専門知識が高い
属人化リスク	担当者退職でテスト品質が低下する	組織的なテスト体制で安定した品質
コスト	開発費に含まれる場合が多い	追加コストが発生する
独立性	開発側が「品質OK」と判断したいバイアスが生じやすい	品質判断に利害関係がない

SCROLL→

第三者検証がリリース品質に与える効果

第三者検証の導入により、リリース後のバグ発生件数が削減されるという実績が多くのQA専門会社から報告されています。開発チームが「正しく動くはず」という前提で見落としやすいエッジケースや、ユーザー目線での操作ミスが発生しやすい箇所を、専門家が体系的に発見します。

特に以下のような品質問題は、第三者検証で発見されやすい傾向があります。

• ユーザーが想定外の操作をした場合の異常系処理
• 異なるブラウザ・デバイス・OS環境での動作差異
• 負荷がかかった状態でのパフォーマンス劣化
• セキュリティ上の脆弱性

QA外注を検討すべき5つのタイミング（判断基準）

QA外注を「やった方がいい」とは分かっていても、いつ・どのような状況で導入を判断すればよいか迷う方は多いです。以下の5つの判断基準を参考にしてください。

バグが繰り返す・顧客クレームが続く

本番リリース後に同じような種類のバグが繰り返し発生している場合、テスト工程に構造的な問題がある可能性があります。開発会社のテストでは見落としやすいパターンが存在することを示しており、第三者の視点を入れるサインです。

テスト担当と開発担当が同一人物

「開発したエンジニアが自分でテストする」という体制は、コスト効率は良いものの品質面でのリスクがあります。人は自分のコードの誤りに気づきにくく、「動くはず」という思い込みでテストが甘くなりがちです。開発者とテスト担当者を分離できていない場合は、外部のQA専門家の導入を検討しましょう。

重要なリリース（顧客向け公開・法改正対応）の前

事業に直接影響するリリースや、法令対応など後戻りできない変更の場合は特に第三者検証の価値が高まります。リリース後に問題が発覚した場合のコスト（対応工数・顧客への謝罪・売上損失）と、QA外注のコストを比較して判断しましょう。

開発チームに専任QAエンジニアがいない

品質保証の専門家がチーム内にいない場合、テストの深度や網羅性に限界があります。特にパフォーマンステストやセキュリティテストなど専門知識が必要な領域は、外部の専門家への委託が現実的です。

リリース頻度が上がりテスト工数が追いつかない

アジャイル開発でリリース頻度が上がると、テスト工数の確保が難しくなります。テストを省略したリリースを繰り返すと品質リスクが蓄積されます。継続的なQA外注やテスト自動化の導入が有効です。

外注できるテストの種類と費用相場

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

テスト種別	概要	外注向き	内製向き
機能テスト	仕様通りに動作するかの確認	◎ 体系的な仕様書があれば外注効果大	開発者が把握しているロジックのみ
回帰テスト	変更によって既存機能が壊れていないかの確認	◎ テストケース数が多く外注で効率化できる	変更箇所が少ない場合
結合テスト	複数のモジュールを組み合わせた動作確認	○ 複雑なシステムでは第三者視点が有効	比較的シンプルなシステム
システムテスト	システム全体を通した動作確認	◎ 本番相当環境でのテストを外部に任せられる	内部ロジックへの深い理解が必要な場合
受入テスト	実際のユーザー要件を満たすかの確認	○ ユーザー視点での検証に強い	クライアントが直接実施する場合
パフォーマンステスト	負荷・応答時間の計測と改善	◎ 専門ツール・ノウハウが必要	簡単な負荷確認のみ
セキュリティテスト	脆弱性・セキュリティホールの検出	◎ 専門知識が必須。内製困難	ほぼ外注推奨

SCROLL→

QA外注の費用相場

QA外注の費用は依頼する規模・内容・外注先によって大きく異なります。以下は一般的な費用の目安です。

人月単価（QA専門会社・国内エンジニア）

外注先の種類	人月単価の目安
国内QA専門会社（SHIFT、バルテス等）	80万円〜120万円／人月
フリーランスQAエンジニア	40万円〜60万円／人月
オフショア（東南アジア等）	15万円〜40万円／人月

SCROLL→

テストケース単価（ケース作成・実行）

テストケースの作成・実行を件数単価で依頼する場合、1ケースあたり数百円〜数千円が相場です。小規模なシステムで簡単な機能テストのみの場合は数十万円程度から依頼できるケースもありますが、大規模システムや複数の専門テストを組み合わせる場合は数百万円以上になることもあります。

費用を左右する主な要因

• テスト対象の規模: 機能数・画面数が多いほど費用が上がる
• テスト期間: 短期集中か長期継続かによって費用構造が変わる
• ドキュメントの整備度: テスト仕様書や要件定義書が整備されているほどテスト会社の準備工数が減り、コストが下がる傾向がある
• テスト種別の組み合わせ: セキュリティテストやパフォーマンステストを追加すると費用が増加する

QA外注会社の選び方：7つのチェックポイント

初めてQA外注先を選ぶ際に確認すべき7つのポイントを解説します。

チェックポイント1: 実績と専門資格（JSTQBなど）

テスト専門会社かどうかの見極めに、JSTQB（Japan Software Testing Qualifications Board）認定資格の保有者数が参考になります。JSTQBはソフトウェアテスト技術者の国内資格で、Foundation Level・Advanced Levelなどのグレードがあります。資格保有者が多い会社ほど、体系的なテスト知識を持つエンジニアが揃っていると判断できます。

また、自社の業種・業界（金融、医療、EC等）や技術スタック（React、Java等）に近いプロジェクト実績があるかも確認しましょう。

チェックポイント2: 自社業界・技術スタックへの知見

汎用的なテストしかできない会社に依頼すると、業界特有の要件や技術的なエッジケースを見落とすリスクがあります。事前ヒアリングや提案内容から「自社のビジネス・技術への理解度」を確認してください。

チェックポイント3: テスト体制の厚さとアサイン人材のスキル

一人でテストを担当するのか、テストマネージャー・テストリード・テストオペレーターなど役割分担された体制で行うのかで品質は大きく変わります。特に大規模案件では、体制の厚さが重要です。

チェックポイント4: コミュニケーション・報告体制

テスト期間中に「バグを発見したらどのように報告するか」「進捗はどのタイミングで共有されるか」を事前に確認しましょう。バグ管理ツール（Jira、Redmine等）の使用有無や、日本語対応の可否も重要な確認ポイントです。

チェックポイント5: 費用の透明性と追加費用の発生有無

見積もり段階で「追加テストケースが発生した場合の費用」「仕様変更時の対応」など想定外コストの発生条件を明確にしておきましょう。後から追加費用が発生してトラブルになるケースも少なくありません。

チェックポイント6: アフターサポートと不具合対応の範囲

テスト完了後に発見した不具合の修正対応範囲（再テストの対応有無等）や、テスト成果物（テスト仕様書・バグレポート）の納品形式を確認しましょう。

チェックポイント7: 発注側の準備負担（テスト仕様書提供の要否）

テスト仕様書を自社で準備する必要があるか、会社が作成を代行するかは費用と工数に直結します。ドキュメントが整備されていない場合でも対応できるか、対応する場合の費用はいくらかを確認してください。

発注側が準備すべきもの（テスト仕様書・環境・スケジュール）

QA外注を成功させるには、発注側の準備が重要です。事前準備が不十分だとテスト会社の作業効率が下がり、品質・コスト・スケジュールのすべてに悪影響が出ます。

必須ドキュメント一覧

ドキュメント	内容	整備状況ごとの対応
要件定義書 / 仕様書	どのような機能があり、どう動くべきかの仕様	必須。なければテスト会社への依頼が難しい
テスト仕様書	どの機能をどのようにテストするかの設計	自社で作成 or テスト会社に作成依頼（追加費用）
画面設計書 / UI仕様	各画面の設計意図・遷移フロー	あれば品質が上がる
バグ管理ルール	バグ報告・優先度判断・修正フローの取り決め	キックオフ前に合意する

SCROLL→

ドキュメントが整備されていない場合は、テスト会社が仕様をヒアリングしながらテスト設計するケースもありますが、その分コストと期間が増えます。

テスト環境の準備

テスト専用の環境（ステージング環境）をテスト期間中に用意しましょう。本番環境でのテストはデータ損失・サービス停止のリスクがあるため避けてください。

必要な準備:

• テスト環境のURL・アカウント・権限
• テストデータの用意（個人情報を含まないダミーデータ）
• 外部APIやサードパーティサービスのスタブ・モック（必要に応じて）

スケジュール設計（テスト期間の確保）

テスト期間を開発スケジュールの後半に詰め込むと、テストが不十分なままリリースを迫られるリスクが生じます。開発計画の段階からテスト期間（通常は開発工数の20〜30%が目安）を確保してください。

ドキュメントが不十分な場合の対応

「仕様書がない」「古い仕様書しかない」という状況でも、テスト会社によっては対応可能です。ただし仕様の確認・整理の工数が増えるため、費用と期間が割増になることを理解した上で依頼しましょう。また、テスト会社の仕様理解の正確性を確認するためのコミュニケーションコストも増加します。

QA外注の進め方：契約から納品まで5ステップ

ステップ1: テスト要件の整理

まず「何をテストしたいか」を明確にします。

• テスト対象の機能範囲（どの機能をテストするか）
• テスト種別の選定（機能テスト・回帰テスト・パフォーマンステスト等）
• 合否基準（どの条件を満たせばリリースOKとするか）
• テスト期間と予算の上限

この段階でテスト対象を絞り込むほど、見積もりが具体的になり費用の見通しが立てやすくなります。

ステップ2: 外注先の選定と見積もり取得

複数のQA専門会社に見積もりを依頼し、比較します。1社のみに依頼すると価格相場が分からないため、最低でも2〜3社から取得しましょう。

見積もり依頼時に共有する情報:

• システムの概要（業種・規模・主要機能）
• テスト要件（テスト種別・範囲・合否基準）
• ドキュメントの整備状況
• 希望スケジュール

ステップ3: 契約・キックオフ

外注先が決まったら、以下を契約前に合意しておきましょう。

• テスト範囲と成果物（バグレポート・テスト結果報告書等）の定義
• バグ発見時の報告フォーマット・優先度基準
• 仕様不明点の確認フロー
• 追加費用の発生条件

ステップ4: テスト実行期間の管理

テスト期間中は発注側も積極的に関与することが重要です。「丸投げ」にすると品質が下がりやすいです。

発注側がすべきこと:

• 定期的な進捗確認（週次ミーティング等）
• バグ報告への迅速な回答・優先度判断
• 仕様に関する質問への対応
• テスト範囲外の問題が見つかった場合の判断

ステップ5: 成果物の受入と納品

テスト完了後、成果物（バグレポート・テスト結果報告書）を確認して受入を行います。

確認すべき内容:

• テスト範囲の網羅性（当初合意したテスト対象が実施されているか）
• バグ報告の内容（再現手順・深刻度・スクリーンショット等）
• 合否判定の根拠

未解決のバグがある場合の対応フロー（修正→再テストの範囲）も事前に合意しておくとスムーズです。

よくある失敗パターンと防止策

QA外注でよくある失敗と、事前に防ぐための対策を紹介します。

丸投げによる品質未向上

失敗パターン: テスト会社に全部任せきりにして、仕様の質問への対応が遅れたり、バグ報告の優先度判断を放置したりすると、テストが形式的になります。

防止策: 週次ミーティングと担当窓口の設置。バグ報告への24時間以内の回答を社内ルール化しましょう。発注側が積極的に関与することで、テスト会社も本来の力を発揮できます。

スケジュール圧縮によるテスト期間の短縮

失敗パターン: 開発が遅延した分だけテスト期間が圧縮され、「形式的なテストだけしてリリース」という事態になる。

防止策: テスト開始日は開発スケジュールの変動に連動させない。「最低○営業日のテスト期間は確保する」という原則を開発計画段階から合意しておきましょう。

ドキュメント不足によるテスト漏れ

失敗パターン: 仕様書がない・古いドキュメントしかない状態でテストを依頼すると、テスト会社が「なんとなく動いていれば合格」という曖昧なテストをしてしまう。

防止策: テスト開始前にテスト対象の仕様を文書化または口頭説明でテスト会社に共有する。テスト会社が仕様を正確に理解しているかを確認するレビューを設けましょう。

受入基準の未設定

失敗パターン: 「どの状態でリリースOKとするか」の基準が不明確なまま進めると、軽微なバグが残っているのにリリースしてしまったり、逆に完璧を求めてリリースが止まったりする。

防止策: 「残存バグが○件以下かつ深刻度High以上がゼロ」という受入基準を契約前に定義しておきましょう。

QA外注でコストを抑えるコツ

QA外注は品質への投資ですが、コストを適切にコントロールする工夫も重要です。

リスクベーステストで優先付けする

すべての機能を均等にテストするのではなく、障害発生時の影響が大きい機能・変更頻度が高い機能・ユーザーが最も使う機能を重点的にテストします。重要度の低い機能のテストは内製にする、または後回しにすることでコストを削減できます。

ドキュメントを事前に整備する

テスト仕様書・要件定義書を整備しておくほど、テスト会社の準備工数が減りコストが下がります。ドキュメント作成への投資が外注費用の削減につながります。

テスト自動化と組み合わせる

継続的にリリースを行うプロジェクトでは、回帰テストの自動化と手動テストの組み合わせが有効です。自動化できる部分は内製のテスト自動化に任せ、探索的テストや専門テスト（セキュリティ・パフォーマンス）を外注するという使い分けでコスト効率を高めましょう。

スポット依頼と継続契約を使い分ける

大規模リリース前の一時的な強化にはスポット依頼、定常的な品質管理には月次契約の継続利用が向いています。自社のリリース頻度・開発体制に合わせて使い分けましょう。

QA外注は「開発会社を信頼していないから外注する」のではなく、「客観的な視点を追加することで品質をさらに高める」という前向きな投資です。本記事で解説した費用相場・判断基準・進め方のポイントを活用して、自社での導入を検討してみてください。

品質管理の全体的な考え方については品質管理とは？ソフトウェア開発における重要性と手法を解説もご参照ください。

秋霜堂株式会社について

秋霜堂は、Web開発・AI活用・業務システム開発を手がけるシステム開発会社です。要件定義から設計・開発・運用まで一貫してご支援しています。

システム開発のご相談や、自社課題に合った技術的アプローチについてお悩みの方は、お気軽にお問い合わせください。