テストの見積もり手法完全ガイド！

ソフトウェア開発におけるテストは、製品の品質を左右する重要なプロセスです。

しかしテスト工数の見積もりは不確実性が高く、プロジェクトの計画段階でつまずく大きな要因の一つです。

不正確な見積もりはプロジェクトの遅延やコスト超過、さらには品質低下に直結するリスクを伴います。

今回はテスト見積もりの難しさと課題を紐解きながら、主要な見積もり手法である「類推見積」「ボトムアップ見積」「パラメトリック見積」の3つを、具体的な計算例を交えてわかりやすく解説します。

これらの手法を使い分け、見積もり精度を高めるためのポイントや、実際の現場で起こりがちなトラブルとその対処法までを網羅的にご紹介します。

▼テスト計画・テスト設計についてはこちら▼

テスト見積もりとは何か

見積もりとは、プロジェクトの目標を達成するために必要なコスト、期間、リソースを予測するプロセスです。

ソフトウェア開発における見積もりは、プロジェクトの計画段階で不可欠な要素であり、特にQA（品質保証）の領域では、テスト工数の算出が重要になります。

正確な見積もりを行うことで、プロジェクトの成功確率が高まり、計画的なリソース配分やスケジュールの策定が可能になります。

また、見積もりは単なる数値の算出だけでなく、プロジェクトの不確実性を評価し、リスクを管理するための重要な手段でもあります。

見積もりを適切に行うことで、以下の役割が果たされます。

これらの役割を理解し、プロジェクトの特性に応じた適切な見積もり手法を適用することが、テスト工数算出の精度を高める鍵となるのです。

ソフトウェアテストにおける見積もりの位置づけ

まず、プロジェクトの初期段階でテストの範囲、期間、リソースを予測し、計画を立てることで、テスト活動が円滑に進む土台を築きます。

開発プロジェクトが進行する中で、テスト見積もりは一度きりではなく、要件の変更や進捗状況に応じて繰り返し見直しを行う必要があります。

このように見直しを行うことで、プロジェクトの状況に合わせた柔軟な対応が可能となり、手戻りや予期せぬコスト増加を防ぐことができます。

さらに、テスト見積もりはただ単に「何日かかるか」を算出するだけでなく、テストの品質と密接に関わっています。

なぜなら、見積もりが不正確だと、テスト期間が不足してテストの網羅性が低下したり、リグレッションテストが十分に実施できずに不具合を見逃すリスクが生じるからです。

逆に、適切な見積もりによって十分なテスト期間とリソースが確保できれば、テスト観点の洗い出しやテストケースの作成に時間をかけられるため、結果として製品の品質向上につながります。

加えて、上長や営業、顧客といったステークホルダーに対して、見積もりの根拠を明確に説明できることが特に重要です。

テスト工数を算出する際には、どのような前提条件で、どのようなテスト範囲を設定し、どの程度の不確実性を考慮に入れているのかを言語化しておくことで、関係者との合意形成がスムーズになり、後々のトラブルを防ぐことができます。

そして、これは見積もりの正当性を確保するだけでなく、テストチームの専門性をアピールする機会にもなるのです。

テスト見積もりの目的と重要性

プロジェクト計画・予算管理との関係

まず、テスト見積もりを行うことで、テストフェーズに必要な時間と人員、そして費用が明確になります。

これにより、プロジェクトマネージャーは、全体スケジュールの中でテスト期間を適切に確保し、予算内でリソースを配分することが可能になります。

正確なテスト見積もりは、プロジェクト計画の信頼性を高める基盤となります。

たとえば、テスト工数を過小に見積もってしまうと、テスト期間が不足し、テスト観点の検討やテストケース作成が不十分になる可能性があります。

その結果、手戻りや追加のテスト工数が発生し、プロジェクト全体のスケジュール遅延やコスト超過を招きかねません。

このような事態を避けるためにも、過去の類似案件の実績データを参考にしたり、テストの対象範囲や複雑性を考慮して、根拠に基づいた見積もりを立てることが不可欠です。

特に受託開発においては、テスト見積もりの精度が顧客との信頼関係に直結します。

顧客に提示する見積もりの根拠が不明確だと、交渉の過程で値引きを求められたり、無理な短納期を要求されたりするリスクが高まります。

しかし、テスト範囲や前提条件、不確実性などを言語化して説明できれば、顧客も納得しやすくなり、初期の段階で合意形成が進めやすくなるのです。

品質確保とリスク管理の観点

テスト見積もりが適切に行われれば、テスト観点の洗い出しやテストケースの作成に十分な時間を確保できるため、テストの網羅性が向上し、結果として潜在的な欠陥を早期に発見・修正する確率が高まります。

逆に、見積もりが不正確でテスト期間が不足すると、十分なテストを実施できず、品質の低下を招くリスクが生じます。

特に、リグレッションテストの実施が不十分な場合、既存機能への影響が見過ごされ、予期せぬ不具合が発生する可能性が高まります。

このようなリスクを回避するためには、テスト工数を算出する際に、改修の影響範囲やシステムの結合度、リグレッションテストの範囲など、テスト量を増幅させる要因を事前に洗い出して考慮することが重要です。

また、テスト見積もりはリスク管理の観点からも重要です。

不確実性の高い要因（仕様変更の可能性、未経験の技術要素など）を事前に特定し、それらに対応するためのバッファ（予備の期間や工数）を計画に織り込むことで、予期せぬ事態が発生した場合でも、計画通りにテストを進められる可能性が高まります。

例えば、三点見積もり（PERT）のような手法を活用すれば、楽観値、悲観値、最頻値を考慮して不確実性を数値化し、より現実的なテスト期間を算出することができます。

これにより、ステークホルダーに対して、リスクを考慮した妥当な見積もりであることを明確に説明できるようになります。

テスト見積もりの難しさと課題

なぜ見積もりに失敗するのか

テスト見積もりが失敗する主な原因は、さまざまな不確実性を考慮できていないことにあります。

テストの対象範囲は開発初期段階では不明瞭なことが多く、仕様変更や要件の追加が頻繁に発生します。

また、見積もり担当者の経験や主観に頼ることで、楽観的な予測や過度なリスク軽視に陥ることもあります。

たとえば、過去の類似プロジェクトの経験則から安易に工数を見積もってしまうと、今回のプロジェクト特有の技術的な難易度や、未知の依存関係といった要因を見落とす可能性があります。

これにより、想定以上の手戻りや、テストケースの追加発生に繋がり、結果として見積もりの精度が大きく狂ってしまうことになります。

さらに、営業や顧客からの強いプレッシャーによって、現実的な工数よりも短い期間でテストを完了させると約束してしまうことも、失敗の一因です。

これらの要因は、単に見積もり値がずれるだけでなく、プロジェクト全体の信頼性や品質低下を招くリスクもはらんでいます。

「見積もり」と「進捗管理」の関係

テストの見積もりは、単に工数を算出するだけでなく、その後のプロジェクトの進捗管理と密接に関係しています。

見積もりが不正確だと、計画段階で設定されたマイルストーンやスケジュールが現実と乖離し、結果としてプロジェクトの進行に大きな支障をきたします。

正確な見積もりは、テスト活動の開始から完了までの明確なロードマップを提供し、プロジェクトメンバー全員が共通の目標を持って作業を進めるための基盤となります。

たとえば、テストケースの作成、実行、不具合の報告・修正、再テストといった各工程にどれだけの工数がかかるかを事前に見積もることで、計画通りに進んでいるか、遅延が発生していないかを定期的にチェックできるようになります。

これにより、遅延の兆候を早期に捉え、人員の増強やスケジュールの見直しといった対策を迅速に講じることが可能となります。

見積もりは一度きりの作業ではなく、プロジェクトの進捗に応じて見直し、常に現実的な計画を維持するための重要なツールです。

見積もり精度を阻害する要因

テスト見積もりの精度を阻害する要因は多岐にわたります。

まず、要件定義が曖昧であることや、仕様が頻繁に変更されることが挙げられます。

テストの範囲や深さが明確でないと、どれだけの工数が必要かを正確に予測するのは困難です。

次に、技術的な不確実性です。

新しい技術やツールを使用する場合、未知の問題や学習コストが発生する可能性があり、これを事前に見積もりに含めることは容易ではありません。

また、チームメンバーのスキルや経験のばらつきも大きな要因です。

経験の浅いメンバーが多ければ、想定以上の時間が必要になる可能性がありますし、ベテランに依存しすぎると、そのメンバーに負荷が集中し、プロジェクト全体の遅延に繋がるリスクがあります。

さらに過去のプロジェクトのデータが不足している、あるいはデータがあっても整理されていない場合、客観的な根拠に基づいた見積もりができず主観に頼らざるを得ない状況に陥りがちです。

これらの要因を事前に特定しリスクとして見積もりに織り込むことが、より精度の高いテスト計画を策定するためには不可欠となります。

テスト見積もりの主な手法

類推見積（過去データや類似案件から推測）

類推見積もりは、過去に実施した類似のプロジェクトやタスクのデータをもとに、今回のテスト工数を推測する手法です。

この手法は、テスト対象のシステムや機能、技術要素、チーム構成などが過去の案件と似ている場合に特に有効です。

具体的な手順としては、まず過去のプロジェクトの工数データや実績を収集・分析し、今回のプロジェクトと類似している点を洗い出します。

その上で、類似プロジェクトのテスト工数や期間を参考にして、今回の見積もりを作成します。

この手法の最大の利点は、スピーディーに見積もりが作成できる点です。

特にプロジェクトの初期段階や、詳細な情報が不足している概算見積もりの段階で重宝されます。

しかし、過去のデータがない場合や、今回のプロジェクトと過去のプロジェクトとの間に大きな違いがある場合、見積もりの精度は低下します。

たとえば、新しい技術が導入されていたり、チームメンバーのスキルレベルが異なったりする場合、単純な類推だけでは現実との乖離が生じる可能性があります。

そのため、類推見積もりを用いる際は、類似性の度合いを慎重に評価し、その違いを補正する形で調整を加えることが不可欠です。

具体的な算出例

例えば、過去に開発したECサイトの機能追加プロジェクト（A案件）を参考に、今回のECサイトの機能改修プロジェクト（B案件）のテスト工数を見積もる場合を考えます。

まず、過去のA案件のテスト工数を特定します。

この案件では、テスト設計に3人日、テスト実行に5人日かかったとします。

次に、A案件とB案件の類似性や差異を分析します。

B案件は、A案件よりも機能の規模が1.5倍に拡大し、複雑な決済機能が追加されています。

また、A案件では3名のテスターが担当しましたが、今回は5名のチームで実施する予定です。

これらの違いを考慮して、B案件のテスト工数を類推します。

仮に単純に規模が1.5倍になることを考慮して、テスト設計を3人日×1.5＝4.5人日、テスト実行を5人日×1.5＝7.5人日と見積もります。

さらに、決済機能の複雑さを考慮して、テスト設計に1人日、テスト実行に2人日のバッファを加える、といった調整を行います。

これにより、テスト設計は5.5人日、テスト実行は9.5人日となり、合計で15人日という概算の見積もりを算出できます。

このように、類推見積もりでは、過去の実績をベースに、今回のプロジェクトの特性に合わせて補正を加えていくことが重要です。

ボトムアップ見積（作業分解による積み上げ）

ボトムアップ見積もりは、テスト作業をできる限り細かく分解し、それぞれのタスクにかかる工数を個別に算出し、それらを積み上げて全体の工数を見積もる手法です。

この手法は、ウォーターフォール開発のように、要件や仕様が比較的明確なプロジェクトに適しています。

具体的な手順としては、まずテスト計画、テスト設計、テスト実行、不具合報告、再テストといった主要なフェーズに分けます。

次に、それぞれのフェーズをさらに細分化し、テストケースの作成、テスト環境の構築、テストデータの準備など、具体的なタスクレベルまで分解します。

そして、それぞれのタスクにかかる時間や工数をチームメンバーが個別に算出し、最後にすべてを合計して最終的な見積もりを作成します。

この手法は、テストの作業内容を詳細に洗い出すため、見積もりの根拠が明確になり、高い精度を期待できます。

また、各タスクの担当者が工数を見積もることで、当事者意識が高まり、責任感を持ってプロジェクトに取り組めるというメリットもあります。

一方で、詳細な作業分解には多くの時間と労力がかかるため、見積もり自体に時間がかかってしまう点がデメリットです。

特に、要件が固まっていないアジャイル開発のようなプロジェクトでは、この手法は適用が難しい場合があります。

具体的な算出例

新しく開発する顧客管理システムの機能テストを見積もる場合を例に、具体的なステップを説明します。

①テスト作業の分解: テスト計画、テストケース設計、テスト環境構築、テストデータ作成、テスト実行、不具合報告、再テストという主要なフェーズに分けます。

②タスクの細分化と工数見積もり: 各フェーズをさらに細分化し、それぞれのタスクにかかる工数を見積もります。

③合計工数の算出: 各タスクの工数を合計します。テストケース設計に20人時、テスト実行に40人時、環境構築に8人時、不具合報告や再テストに10人時を割り当てると、合計で78人時（9.75人日）となります。

パラメトリック見積（統計モデルや数式による算出）

パラメトリック見積もりは、プロジェクトの特性を表すパラメータと過去の実績データに基づいた数式を用いて、工数を機械的に算出する手法です。

この手法は客観的なデータに基づいて見積もりができるため、類推見積もりよりも高い精度と再現性を期待できます。

代表的な手法に「テストケースポイント法」があります。

この手法では、まずテスト対象の複雑さや機能の数などをパラメータとして数値化します。次に、過去のプロジェクトにおける、これらのパラメータと工数の関係性を分析し、係数として抽出します。

そして、今回のプロジェクトのパラメータにその係数を適用することで、テスト工数を算出します。

パラメトリック見積もりの最大の利点は、見積もりの根拠が数式やデータに基づいているため客観性が高く、関係者に対して論理的に説明できる点です。

また過去のデータを継続的に蓄積・改善していくことで、見積もりの精度を年々高めていくことができます。

しかし、この手法を適用するには、過去のプロジェクトの工数やパラメータに関する詳細なデータが十分に蓄積されている必要があります。

またプロジェクトの特性を適切にパラメータ化するための専門知識も求められます。

過去の実績データがない、あるいは今回のプロジェクトが過去に例のない新しいタイプである場合は、この手法の適用は難しいでしょう。

具体的な算出例

ここでは、テストケースポイント法を例に、テスト工数を見積もる手順を解説します。

①パラメータの洗い出し: まず、テスト対象の機能の複雑さを表すパラメータを定義します。例えば、「入力項目の数」「出力項目の数」「計算処理の複雑さ」などです。

②パラメータの数値化: 定義したパラメータを、事前に定めた基準に基づいて点数化します。

③テストケースポイント（TCP）の算出: 各機能の点数を合計して、テストケースポイントを算出します。この例では、10 + 15 + 20 = 45TCPとなります。

④生産性係数の適用: 過去のプロジェクト実績から算出した生産性係数（例：1TCPあたりのテスト工数＝2人時）を適用します。

⑤最終工数の算出: 合計TCPに生産性係数を乗じて、最終的な工数を算出します。45TCP × 2人時/TCP = 90人時（11.25人日）。

精度の高い見積もりを行うためのポイント

対象範囲や条件の網羅性確認

精度の高いテスト見積もりを行うためには、まずテストの対象範囲と前提条件を漏れなく確認することが不可欠です。

見積もりは、テスト対象のシステムや機能、テスト環境、利用するツール、担当するチームメンバーの構成など、多くの要素に影響されます。

これらの情報が曖昧なまま見積もりを進めると、後から想定外の作業が発生し、見積もりの精度が大きく狂ってしまいます。

具体的には、要件定義書や仕様書を丁寧に読み込み、テストすべき機能や範囲を明確に定義します。

また、新機能だけでなく、既存機能への影響範囲（リグレッションテストの範囲）や、テストデータを準備する工数、テスト環境の構築・維持にかかる工数も考慮に入れる必要があります。

さらに、テストの前提条件として、テストの完了基準や、不具合の報告・修正フローなど、プロジェクトの進め方に関するルールも明確にしておくことが重要です。

これらの情報を網羅的に洗い出し、関係者間で認識を合わせることで、後から発生する手戻りを減らし、見積もりの精度を高めることができます。

根拠やデータの明確化

見積もりの精度を高めるためには、勘や経験に頼るだけでなく、客観的な根拠やデータに基づいて算出することが重要です。

特に、上長や顧客に説明する際には、なぜその工数になったのかを明確に言語化できることが求められます。

見積もりの根拠を明確にするためには、以下のポイントを意識すると良いでしょう。

見積もり時によくあるトラブルと対処法

スコープ変更への対応

テスト見積もり後によく発生するトラブルの一つが、テストスコープの変更です。

開発途中の仕様変更や、顧客からの追加要件によって、当初の見積もり工数が現実と合わなくなることがあります。

このような事態を避けるためには、見積もりの際に「変更管理プロセス」を明確にしておくことが重要です。

まず見積もりの前提条件として、テストスコープが固定されていることを明記し、変更が発生した場合はその影響を再評価して再度見積もりを行う旨を関係者間で合意しておく必要があります。

変更が発生した際には、まず変更内容がテストにどのような影響を与えるかを分析します。

例えば追加される機能の規模や複雑さ、既存機能への影響度などを評価し、それに応じて必要なテストケースの追加や、既存テストケースの見直し工数を再算出します。

そして再見積もりの結果を速やかに顧客や関係者に提示し、スケジュールの調整や追加費用の発生について協議します。

これにより、予期せぬスコープ変更にも落ち着いて対応でき、過度な残業や品質低下を防ぐことができます。

リソース不足や進捗遅延の対応

見積もり通りにプロジェクトが進まない原因として、リソース不足や予期せぬ進捗遅延が挙げられます。

例えば、プロジェクトの途中でチームメンバーが離脱したり、想定以上の不具合が発生して修正に時間がかかったりすることがあります。

このようなトラブルに対応するためには、見積もり段階でリスクを織り込んでおくことと、進捗を定期的に管理することが重要です。

まず、見積もりには不確実性を考慮したバッファ（予備工数）を含めておきましょう。

三点見積もり（PERT）のような手法を活用することで、リスクを数値化し、現実的な工数の幅を持たせることが可能です。

また進捗管理においては、毎日または毎週チームメンバーから進捗状況を報告してもらい、計画との乖離がないかをチェックします。

遅延の兆候が見られた場合はその原因を早期に特定し、他のメンバーの協力を仰いだり、テストの優先順位を見直したりといった対策を講じます。

さらに、進捗の遅れが深刻な場合は、関係者と相談し、スコープの削減やスケジュールの延長を検討することも必要です。

関係者間の認識齟齬の解消

テストの見積もりは、開発者、営業、顧客など、多くの関係者が関わるため、認識の齟齬が発生しやすいものです。

例えば「テスト」という言葉の定義が人によって異なったり、「品質」の基準が曖昧だったりすると、後々大きなトラブルに発展する可能性があります。

このような認識齟齬を解消するためには、見積もりの段階で「見積もり根拠の言語化」と「レビュープロセスの確立」が不可欠です。

見積もり根拠の言語化とは、単に工数を提示するだけでなく、「なぜこの工数になったのか」を明確に説明できる状態にすることです。

例えばテスト範囲やテスト観点を明記したドキュメントを作成し、見積もりに含まれる作業（テストケース作成、テスト実行など）と含まれない作業（不具合修正、環境構築など）を明確に定義しておきます。

また見積もり書を完成させる前に、関係者全員でレビューを行い、内容に合意を得るプロセスを確立することも重要です。

これにより、見積もりに対する共通理解を醸成でき、後から「こんなはずじゃなかった」というトラブルを防ぐことができます。

まとめ

今回はテスト見積もりの難しさ、主要な見積もり手法、そして見積もり精度を高めるためのポイントやトラブルへの対処法について解説しました。

テスト見積もりは、プロジェクトの計画、予算管理、品質確保、リスク管理に不可欠なプロセスです。

プロジェクトの特性に応じて、類推、ボトムアップ、パラメトリックといった手法を適切に使い分けることが重要です。

また、見積もりの前提条件や根拠を明確に言語化し、関係者間で認識を合わせることで、後々のトラブルを防ぎ、信頼性の高い計画を立てることができます。

この記事で得た知識を活かし、見積もりの精度を向上させ、計画通りに高品質な成果物を生み出せるテストチームの構築を目指してください！

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事の監修

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。

記事制作：川上サトシ