テスト見積もりを最適化する方法|品質とコストを両立するポイント
占いでは『3日で終わる』って出たよ!
必要なのは根拠あるデータ。今回は『テスト見積もりを最適化する方法』を解説するよ
テスト見積もりとは?目的と算出の基本的な考え方
テスト見積もりとは、ソフトウェアテストの目的を達成するために必要な作業工数、期間、費用、設備などのリソースを事前に予測・算出するプロセスです。テストの対象や範囲、必要な作業を整理し、プロジェクトの予算やスケジュール、体制を検討する際に用いられます。
テスト見積もりの2つの目的
テスト計画では、テスト活動に必要なリソースやスケジュールを適切に確保するため、事前に工数や期間などを見積もることが重要です。
テスト見積もりには、主に以下の2つの目的があります。
- ステークホルダーとの合意形成:
必要なテスト範囲や工数、費用を明確にし、社内の予算承認やクライアントとの契約に向けた合意を形成する。 - 品質とリソースの適切な管理:
限られた納期や予算の中で、どの品質リスクにどこまで対応するかを検討し、必要な人員や設備、期間を確保する。
精度の高い見積もりは、必要なリソースを適切に確保し、計画どおりにテストを進めるための重要な要素となります。
見積もりの対象範囲:人件費・機材・ツール・テスト環境
テスト見積もりでは「人時」「人日」「人月」といった作業工数が注目されがちですが、実際には人件費以外の費用やテスト環境の準備も考慮する必要があります。
テストに必要なリソースには、テスト環境やツールなども含まれるため、見積もりでは以下の要素を整理しておくことが重要です。
| 人件費(作業工数) | テスト計画、設計、実行、管理などに関わる要員の稼働時間 |
| ハードウェア費用 | 検証に必要なPC、スマートフォンなどの実機、周辺機器の購入・レンタル費用 |
| ソフトウェア・ツール費用 | テスト自動化ツール、テスト管理ツール、負荷テストツールなどのライセンス費用 |
| テスト環境の構築・運用費用 | クラウドサーバーや検証用ネットワークなどの構築・利用にかかる費用 |
これらの考慮が不足すると、テスト開始直前に実機や環境が不足したり、想定外の費用が発生したりする可能性があります。そのため、環境や機材、ツールまで含めて、必要な要素を漏れなく見積もることが重要です。
開発全体におけるテスト工程の位置づけ
IPA(情報処理推進機構)の統計では、新規開発における工数比率の中央値は、結合テスト20.1%、総合テスト11.9%で、両工程の中央値を単純に合計すると32.0%を占めます。
テスト工数はシステムの規模や機能数、品質要求、テスト範囲などによって変動するため、プロジェクトの条件に応じた見積もりが重要です。
「テスト見積もり」についてはこちらもご覧ください。
テスト見積もりが予算・納期超過につながる主な原因
テスト工数が予定を超過する背景には、テスト実行そのものだけでなく、環境準備や関連作業の見落とし、工数に影響する要因の把握不足があります。
テスト実行以外の関連作業・環境構築の見落とし
見積もりのズレを招く典型的な例が、テストケースの画面操作など、テスト実行にかかる時間だけを見積もるケースです。
実際のテストプロセスでは、テスト実行の前後にもさまざまな作業が発生します。

特に、テスト環境やデータの準備には想定以上の工数が発生する場合があります。例えば、外部APIとの接続調整や権限設定など、事前に把握しにくい作業もあるため、テスト実行以外の工程も含めて見積もることが重要です。
前提条件と工数に影響する要因の見落とし
テスト工数は、システムの規模だけで決まるものではありません。製品や開発プロセス、人員、テスト結果などの条件によっても変動します。主な要因は以下のとおりです。

こうした要因を事前に整理し、「どの程度の品質水準を求めるか」「どのOS・ブラウザをサポート対象とするか」などの前提条件を明確にすることが、見積もりの精度を高めるポイントとなります。
テスト工数の算出方法と見積もりの根拠
社内の上長やクライアントから「なぜこの工数が必要なのか」と問われた際、工数の内訳と算出根拠を具体的に説明できることが求められます。
テスト見積もりの2つのアプローチ
テスト見積もりには、大きくメトリクスベースと専門家ベースの2つのアプローチがあります。
- メトリクスベース:
過去のプロジェクト実績やテスト工数の比率などのデータを基に工数を算出する方法 - 専門家ベース:
テストに必要なタスクを分解し、担当者や専門家の経験・知見を基に工数を算出する方法。三点見積もりやプランニングポーカーなどが該当します
実務では、過去の実績とタスクごとの積算を組み合わせることで、見積もりの妥当性を確認できます。
主な見積もり手法と使い分け
JSTQBシラバス(CTFL)では、テスト工数の見積もり技法としてメトリクスベースと専門家ベースの2つのアプローチに分類し、代表的な4つの技法を説明しています。
プロジェクトの進行状況や利用できる情報に応じて、適切に選択・併用することが重要です。
| 見積もり技法 | アプローチ分類 | 算出の仕組み | 主な適用状況 |
| 比率に基づく見積もり | メトリクスベース | 過去実績や業界標準の比率から算出 | 仕様が未確定な段階で、予算や工数を概算する場合 |
| 外挿 | メトリクスベース | 測定データから将来の工数を推計 | テスト実績を基に、残りの工数を見積もる場合 |
| ワイドバンドデルファイ | 専門家ベース | 複数の専門家が見積もり、議論を通じて合意する | 新規案件など、過去実績だけでは判断しにくい場合 |
| 三点見積もり | 専門家ベース | 楽観値・最頻値・悲観値から加重平均を算出 | 不確実な要素が多く、工数の幅を考慮したい場合 |
特に、初期段階では比率に基づく見積もりや外挿、仕様が明確になった段階では専門家ベースの手法を用いるなど、状況に応じて使い分けることがポイントです。
リスクベースドテストで品質とコストを両立するポイント
限られた予算や納期の中で品質を確保するには、すべてのテストケースを一律に検証するのではなく、障害発生時の影響や発生の可能性に応じて、テストの範囲や深度を調整することが重要です。その代表的なアプローチが「リスクベースドテスト」です。
品質コスト(CoQ)から考えるリソース配分
品質コスト(Cost of Quality:CoQ)は、品質確保にかかるコストと、品質不良によって発生するコストを捉える考え方です。テストや検査など、品質を評価する活動にかかるコストは「評価コスト」に分類されます。
評価コストを抑えすぎると、不具合の修正や再リリース、顧客対応などのコストが増加する可能性があります。そのため、テスト工数を一律に削減せず、リスクの高い領域に重点的に配分することが重要です。
影響度と発生の可能性に応じた検証深度の調整
JSTQBでは、リスクの「可能性」と「影響」からリスクレベルを識別し、その分析結果をテストの範囲や優先順位などに反映する考え方が示されています。
実務では、機能ごとにリスクを評価し、高リスクの領域ほどテスト技法や確認範囲を充実させます。

このようにリスクに応じて検証の深度や工数を調整することで、重要な領域にリソースを重点配分できます。
テスト戦略についてはこちらもご覧ください。
テスト自動化による中長期的な工数削減
アジャイル開発や継続的デリバリーでは、リリースのたびに回帰テストを繰り返すため、手動テストの工数が積み重なりやすくなります。こうした反復的なテストの工数を中長期的に削減する手段の一つが、テスト自動化です。
自動化と手動テストの使い分け
テスト自動化では、すべてを自動化するのではなく、繰り返し実行するテストを中心に対象を選ぶことが重要です。自動化には構築・保守の工数も必要なため、対象によっては手動テストのほうが効率的な場合もあります。
自動化に適した領域
- リリースごとに繰り返すスモークテストや回帰テスト
- API連携の疎通・データ検証
- 大量のデータパターンを用いる検証
手動テストに適した領域
- UIデザインや仕様が頻繁に変更される機能
- 実行頻度の低い新規機能
- 操作性やアクセシビリティを確認するユーザビリティ検証
特に、仕様が安定していて繰り返し実行するテストから自動化することが、工数削減につながります。
また、導入時は初期構築や保守のコストと削減できる手動テストの工数を比較し、対象範囲や導入時期を検討することも重要です。
テスト見積もりを最適化する3つのポイント
テスト見積もりを適切に行うには、工数の算出だけでなく、リスクに応じたリソース配分やテスト自動化も重要です。主なポイントを以下に整理します。

まとめ
テスト見積もりでは、必要な作業やリソースを適切に整理したうえで、リスクやテストの特性に応じてリソースを配分することが重要です。プロジェクトの条件に合わせてテスト計画を最適化することで、品質とコストの両立につなげられます。
自社のテスト工数や進め方に課題を感じている場合は、専門家への相談も有効です。
株式会社GENZでは、テスト計画・設計から実行、テスト自動化まで、プロジェクトの課題に応じたテスト支援を行っています。
テスト工数の見積もりやリソース配分、テストの効率化にお悩みの方は、お気軽にお問い合わせください。
この記事を書いた人