テスト工数の見積もり方と相場｜計算方法・外注費用・開発比率を発注者向けに解説

テスト工程を軽く見積もると何が起きるか——発注側が陥りやすい落とし穴

システム開発の見積もり段階で、テスト工程の工数が実態より少なく計上されているケースは少なくありません。結果としてリリース直前に工数不足が発覚し、納期遅延や追加費用の発生につながる——こうした事態は、発注側が「テストは開発の後処理」と捉えていると起きやすくなります。

見積もり段階でテストが後回しにされやすい理由

テスト工程が過小評価される背景には、見積もりの構造的な問題があります。多くの場合、プロジェクト初期の見積もりは機能要件の洗い出しと実装工数の算出に集中します。テストは「実装が終わってから考えるもの」と位置づけられ、詳細な工数算出が後回しになりがちです。

発注側も、提示された見積書の内訳を細かく確認せずに承認するケースがほとんどです。「テスト：〇〇人日」と記載されていても、その根拠となるテスト設計・実施・不具合管理の各工程が適切に積み上げられているかどうかを、発注者が判断する機会はほぼありません。

開発会社側も、受注競争の中で総額を抑えるためにテスト工数を圧縮するケースがあります。テストは成果物として可視化しにくく、削減しても短期的には表面化しないため、調整されやすい工程です。

工数不足が発覚するタイミングとその影響

テスト工数の不足が明らかになるのは、多くの場合、開発終盤です。実装がほぼ完了した段階でテストを開始すると、想定以上のバグが検出され、修正と再テストのサイクルが繰り返されます。このタイミングで工数不足が発覚すると、次のような影響が連鎖します。

• リリース遅延：テスト期間を確保するためにリリース日を後ろ倒しにせざるを得なくなり、ビジネス計画全体にずれが生じます。
• バグの流出：期日を優先してテストを打ち切ると、未検出の不具合が本番環境に流出するリスクが高まります。リリース後の障害対応は、テスト段階での修正より数倍のコストがかかるケースがほとんどです。
• 追加費用の発生：当初の契約に含まれていない追加テスト工数が発生し、変更契約や追加見積もりの対応が必要になります。

発注者がテスト工数の見積もりを正しく把握しておくことは、こうしたリスクを事前に回避するための判断材料を持つことにほかなりません。見積書を受け取った段階でテスト工程の妥当性を確認できるかどうかが、プロジェクト全体のコントロールに直結します。

テスト工数の基本構造——何に工数がかかっているのかを整理する

「テスト」という言葉は一見シンプルに聞こえますが、実際には複数のフェーズで構成される複合的な工程です。発注者が工数見積もりを受け取ったとき、テスト関連の項目をひとまとめに捉えてしまうと、内訳の妥当性を判断することが難しくなります。まずはテスト工程がどのような作業から成り立っているかを整理しておくことが、見積もりを正しく読み解くための前提になります。

テスト工程の主要フェーズと各フェーズで発生する作業

テスト工程は、大きく以下の6つのフェーズに分類できます。それぞれのフェーズで独立した工数が発生します。

• テスト計画：テストの目的・範囲・スケジュール・体制を定義する工程です。何をどこまでテストするかを決める判断作業が含まれるため、経験値の高い担当者が関与することが多く、想定より工数がかかるケースがあります。
• テスト設計：テスト観点を整理し、どのような条件・手順で動作を確認するかを設計します。機能の複雑さに比例して工数が増加します。
• テストケース作成：設計をもとに、個別の確認手順を文書化します。テスト工程全体の中でも工数比率が高くなりやすい作業です。
• テスト実施：作成したテストケースに沿って実際に動作確認を行います。手動テストの場合、件数が増えるほど工数は線形に増加します。
• バグ管理・報告：検出した不具合をトラッキングツールに起票し、開発チームへ共有・進捗管理を行います。件数が多い場合は管理工数だけで相当な時間を要します。

これらのフェーズがテスト工数の内訳を構成しており、工程比率としてはテストケース作成と実施で全体の50〜60%を占めることが多い傾向にあります。

見落とされやすい工数項目——バグ修正後の再テストと環境構築

発注者が見積もりを確認する際に見落としやすい工数項目が2つあります。

1つ目は再テスト（リグレッションテスト）です。バグが修正された後、修正箇所だけでなく関連する機能に影響が出ていないかを確認する作業が必要になります。バグの件数が多いほど再テストの工数は膨らみ、当初の計画工数を超えることも少なくありません。

2つ目はテスト環境の構築・維持です。本番環境とは別にテスト専用の環境を用意し、データを整備する作業は、規模によっては数日単位の工数が発生します。この項目が見積もりに含まれていない場合、後から追加費用として計上されるリスクがあります。

テスト工数の内訳を正確に把握することが、見積もりの適切な評価につながります。

テスト工数の計算方法——代表的な3つのアプローチ

テスト工数の見積もりには、主に3つの計算方法が使われています。それぞれ算出に必要な情報・精度・適した場面が異なるため、受け取った見積書がどの方式に基づいているかを把握しておくと、内容の妥当性を判断しやすくなります。

テストケース数ベースの計算式と使い方

最も直感的に理解しやすい方法が、テストケース数を起点にした計算です。算出式は以下のとおりです。

テスト工数 ＝ テストケース数 × 1件あたりの実施時間

たとえば、テストケースが500件あり、1件あたりの実施時間が15分（0.25時間）であれば、実施工数は125時間になります。これにテスト設計・環境構築・不具合対応の工数を加算して、総工数を算出します。

この方式は、要件定義や基本設計がある程度固まっており、テスト対象の機能一覧が明確な段階で有効です。ただし、1件あたりの実施時間は機能の複雑さや担当者のスキルによって変動するため、過去の実績データを参照しながら設定することが精度を高める上で重要になります。

開発工数比率ベースの考え方——比率の目安と根拠

テストケースの洗い出しが難しい早期フェーズでよく使われるのが、開発全体工数に一定の比率を掛ける方法です。

テスト工数 ＝ 開発全体工数 × テスト比率

比率の目安は、システムの品質要件や規模によって異なりますが、一般的には開発全体の20〜40%程度がテスト工数として計上されるケースが多くなっています。品質基準が高い金融系・医療系システムでは、40%を超える場合もあります。

この方式は見積もりをスピーディーに出せる反面、比率の根拠が曖昧なまま提示されるケースも少なくありません。見積書を受け取った際は「比率をどのような根拠で設定しているか」を確認することが望ましいです。

3つの計算方法の比較——精度・適用場面・注意点

機能点数（FP：Function Point）ベースは、システムの機能規模を定量化した上でテスト工数を算出する方法です。精度は高い一方、FP計測自体に専門知識と工数が必要なため、大規模開発や複数ベンダーが関与する案件で採用されることが多くなっています。

以下に3つの方法を比較します。

• テストケース数ベース：精度は中〜高。要件定義完了後の詳細見積もりに適している。テストケースの質と実績データの有無が精度を左右する。
• 開発工数比率ベース：精度は低〜中。企画・提案フェーズの概算見積もりに適している。比率の根拠が示されているかを必ず確認する。
• 機能点数（FP）ベース：精度は高。大規模・複数ベンダー案件に適している。FP計測コストがかかるため、小規模案件には向かない。

発注者の立場からは、見積書の段階でどの方式が使われているかを確認し、フェーズに対して方式が適切かどうかを判断することが、工数の過不足を見抜く第一歩になります。

開発全体に占めるテスト工程の比率——業界標準と判断基準

テスト工程比率の業界標準データ

一般的に、テスト工程は開発全体の工数のうち25〜35%程度を占めるとされています。IPA（独立行政法人情報処理推進機構）が公表している「ソフトウェア開発データ白書」でも、テスト工程（単体テスト・結合テスト・システムテストの合算）が開発工数の3割前後を占めるプロジェクトが多いことが示されています。

ただしこの数値はあくまで目安です。システムの種別や開発規模、求められる品質水準によって、実際の比率は大きく変わります。

比率が高くなるケース・低くなるケース——システム特性と品質要件による違い

テスト工程の比率が高くなりやすいケースには、次のような特徴があります。

• 金融・医療・製造の基幹系など、障害時の影響が大きい業務系システム（40%超になることもある）
• 組込み系・制御系システムで、ハードウェアとの連携検証が必要な場合
• 既存システムとの連携箇所が多く、結合テストの範囲が広い場合

一方、比率が低くなりやすいケースとしては、以下が挙げられます。

• プロトタイプや内部ツールなど、品質要件が相対的に緩いWebサービス
• テスト自動化が整備されており、手動工数が圧縮されているプロジェクト
• スコープが小さく、単体テストのみで完結する小規模改修

見積書でテスト比率が極端に低い場合に確認すべきこと

受け取った見積書でテスト工程の比率が15%を下回る場合は、内訳の確認を推奨します。理由として多いのは、テスト設計・テスト計画の工数が「設計工程」に含まれていて見えなくなっているケースや、ユーザー受入テスト（UAT）の工数が別途想定されているケースです。

確認すべき具体的なポイントは以下の3点です。

1. テスト種別（単体・結合・システム・受入）ごとの工数が明示されているか
2. テスト設計・テストケース作成の工数が含まれているか
3. 不具合発生時の修正・再テスト工数がバッファとして確保されているか

これらが見積書に明示されていない場合、テスト工程が過小評価されている可能性があります。後工程でのコスト増や納期遅延につながりやすいため、発注前に書面での確認を求めることが望ましいです。

テスト外注の費用相場——単価・工数・総額の目安

テスト工程の外注を検討する際、まず把握しておきたいのが費用の目安です。見積もりを依頼する前に相場感を持っておくと、提示された金額の妥当性を判断しやすくなります。

テストエンジニアの人工単価の目安

国内のテストエンジニアを外注する場合、人工（にんく）単価の相場はスキルレベルによって異なります。テスト実施を担うメンバークラスであれば、1人日あたり4万〜6万円程度が一般的な目安です。テスト設計やテストリード業務を担うシニアクラスになると、1人日あたり7万〜10万円前後になるケースが少なくありません。

国内オフショア（地方拠点）や海外オフショアを活用する場合は、メンバークラスで1人日あたり1.5万〜3万円程度まで費用を抑えられるケースがあります。ただし、コミュニケーションコストや品質管理の工数が別途発生するため、単純な単価比較だけでは総コストを見誤りやすい点に注意が必要です。

テストケース単価・テスト実施のみの費用感

テストケースの単価ベースで契約する形式もあります。テストケース1件あたり500〜1,500円程度が国内の相場感です。仕様の複雑さや確認環境の数によって変動します。

月額契約型（ラボ型）でテストチームをアサインする場合は、エンジニア1名あたり月額50万〜80万円前後が一般的な水準です。継続的なリリースサイクルに対応したい場合や、回帰テストを定常業務として委託したい場合に向いています。

費用を左右する主な条件と発注前に確認すべき項目

テスト外注の費用は、以下の条件によって大きく変わります。見積もりを複数社から取得する際は、条件をそろえた上で依頼しないと比較が困難になります。

• テスト設計込みか、テスト実施のみか：テスト設計（テストケースの作成）は実施工数と同程度かそれ以上の工数がかかることもあります。設計を含めるかどうかで総額が大きく変わります。
• 自動化の有無：自動テストのスクリプト作成は初期費用がかかりますが、回帰テストを繰り返す場合は中長期的なコスト削減につながります。手動テストのみなのか、自動化ツールの導入・運用まで含むのかを明確にする必要があります。
• 報告書・エビデンスの形式：簡易的なバグ票のみで完結するのか、スクリーンショット付きのエビデンスや品質レポートまで求めるのかによって、成果物作成の工数が変わります。
• テスト環境の準備責任：テスト環境の構築・維持を発注側が行うのか、受注側に含めるのかによっても費用が変動します。

見積もり取得時には、上記の条件を発注側から明示した上で依頼することが重要です。条件が曖昧なまま比較すると、安く見えた提案が実際には別途費用が発生する構造になっていることがあります。

テスト自動化は工数削減になるか——導入判断の考え方

テスト自動化はランニングコストを下げる手段として注目されていますが、導入すれば必ず工数が減るわけではありません。初期構築・スクリプト保守・実行環境の整備にも相応の工数と費用がかかるため、プロジェクトの性質によっては費用対効果が出にくいケースも少なくありません。発注者として自動化の提案を受けたときは、「自動化が本当に有効な状況かどうか」を判断する軸を持っておくことが重要です。

テスト自動化の費用対効果が出るケース・出ないケース

自動化が効果を発揮しやすいのは、同じテストを繰り返し実行する必要がある場面です。具体的には以下のようなシナリオが該当します。

• 回帰テストが多い長期運用プロダクト：機能追加のたびに既存機能の動作確認が必要なシステムでは、自動化によって反復コストを大幅に削減できます。
• 大規模案件でテストケース数が多い：手動では数百〜数千件のテストに膨大な工数がかかるため、自動化の初期投資を早期に回収しやすくなります。
• リリース頻度が高いアジャイル開発：短いサイクルで継続的にテストを回す必要がある場合、自動化は実行速度と品質の両面で貢献します。

一方、費用対効果が出にくいケースも存在します。仕様変更が頻繁に発生するフェーズでは、テストスクリプト自体の修正工数が積み上がりやすく、手動テストより総コストが高くなることがあります。また、短期プロジェクトや要件が固まっていない初期フェーズも同様です。自動化の構築コストを回収できる実行回数に達する前にプロジェクトが終了してしまうケースが多くなります。

自動化ツール導入時の工数と費用の考え方

テスト自動化の外注コストを見積もる際は、初期費用とランニング費用を分けて把握することが重要です。初期フェーズでは、ツール選定・環境構築・テストスクリプトの作成に数十〜数百時間規模の工数が発生します。その後も、仕様変更のたびにスクリプトの保守対応が必要になるため、自動化を導入したからといってテスト工数がゼロになるわけではありません。

発注者として確認しておきたいのは、「何回テストを実行すれば初期投資を回収できるか」という損益分岐点の試算です。たとえば手動テストで1回あたり100時間かかるテストスイートがある場合、自動化の初期構築に200時間かかるなら、3回以上の実行で回収できる計算になります。この試算を外注先に依頼し、根拠を持って判断することが、テスト工数の見積もりにおける発注者の重要な役割です。

発注者が見積書を受け取ったときのチェックポイント

ベンダーから見積書を受け取った際、テスト工程の妥当性を発注者が自ら判断するのは容易ではありません。しかし、いくつかの観点を押さえておくだけで、見積もりの妥当性や抜け漏れのリスクをある程度見極めることができます。CLANEが開発支援の現場で実際に確認している観点を整理します。

見積書のテスト工程で確認すべき5つの観点

以下の5点が明記されているかどうかを、見積書を受け取った段階で必ず確認してください。

1. テスト対象の範囲が明示されているか
   どの機能・画面・APIを対象とするのかが具体的に記載されている必要があります。「全機能をテストする」という記述だけでは、後から対象外を主張されるリスクがあります。
2. テスト種別ごとに工数が分かれているか
   単体テスト・結合テスト・システムテスト・受入テストは、それぞれ目的も作業内容も異なります。テスト工数の見積もりとして、種別ごとに工数が分解されていることが適切な見積もりの条件です。
3. バグ管理・再テストの工数が含まれているか
   バグが検出された後の修正確認（再テスト）は、テスト全体の工数に対して10〜20%程度を占めることも少なくありません。この工数が計上されていない見積もりは、後から追加費用が発生する可能性があります。
4. テスト環境の構築・維持コストが別途計上されているか
   テスト専用のサーバーやデータベース、モックの整備には相応のコストがかかります。開発環境と兼用する場合でも、その前提が明記されているかを確認してください。
5. テスト完了の定義が明記されているか
   「テストが終わった」とはどの状態を指すのかが曖昧なままだと、品質水準の認識ズレが生じます。合格基準（バグ件数・重大度など）が書かれているかを確認することが重要です。

「テスト一式」でまとめられた見積もりが危険な理由

見積書のテスト工程欄に「テスト一式：○人日」とだけ記載されているケースがあります。この表記は、種別・対象範囲・再テスト工数のいずれも不明瞭なまま金額だけが提示されている状態です。

このような見積もりでは、テスト工程チェックの観点から見ると、何が含まれて何が含まれていないかを発注者が判断できません。結果として、テスト中にスコープ外を主張される、あるいは品質基準の合意がないまま「完了」とされるリスクが高まります。

CLANEが支援する案件では、テスト工程を種別・対象・完了条件の3軸で整理することを基本としています。見積書を受け取った際にこれらの記載がない場合は、ベンダーに内訳の提示を求めることが、後のトラブル回避につながります。

まとめ——テスト工数の見積もりで発注者が押さえておくべきポイント

テスト工程の工数・費用を適切に見積もるには、いくつかの判断軸を持っておくことが重要です。ここまでの内容を発注者視点で整理します。

工数・費用の目安として押さえておく数値

• テスト工程は開発全体工数の20〜30%が業界標準。安全性・品質要件が高いシステムでは40%を超えるケースもあります
• 外注時の人工単価は5万〜10万円／人日が一般的な相場で、テスト設計・実行・管理の役割ごとに単価が異なります
• 総額は規模・期間・テスト種別によって大きく変動するため、単価だけで比較すると判断を誤りやすくなります

見積書を受け取ったときの確認ポイント

見積書には、テストケース数・工程ごとの工数内訳・不具合対応の再テスト範囲が明記されているかを確認してください。これらが不明瞭な場合、後工程で追加費用が発生するリスクがあります。また、環境構築・テストデータ準備の工数が含まれているかどうかも見落とされやすい点です。

外注判断と自動化導入の考え方

外注が有効なのは、社内にテスト設計の専門知識がない場合や、リリース期限が短く人員を集中投下する必要がある場合です。一方、自動化は繰り返し実行頻度が高いテストに対して効果を発揮しますが、初期構築コストが発生するため、単発プロジェクトへの導入は費用対効果が合わないケースが少なくありません。

次のアクションに向けて

ベンダーへの確認・見積もり依頼・社内合意形成を進める際は、テスト範囲の定義・品質基準・不具合発生時の対応フローをあらかじめ整理しておくと、認識のズレを防ぎやすくなります。テスト工数の見積もりは、開発プロジェクト全体のリスク管理と直結しています。発注前の段階でこれらの観点を持つことが、後工程のトラブル抑制につながります。