Introduction
システム開発のなかでも、テスト工程はプロダクトの品質を大きく左右する重要な工程です。テスト工程を適切に計画するためには見積もりの精度を向上させる必要がありますが、開発初期には開発範囲が明確でないことも多く、テスト工数の見積もりは非常に難しいといわれています。しかし、テスト工程の見積もりの精度が低いとプロジェクトの遅延、コストの超過が起こる可能性があり、さらには品質の低下につながることもあります。
では、テスト工程の見積もり精度を上げるためにはどうすればよいのでしょうか?この記事では、ソフトウェアテスト見積もりの目的と重要性、見積もりの算出方法、見積もり精度の高め方などについて解説します。
目次
ソフトウェアテスト見積もりの目的と重要性

どのような業務や業種においても、見積もりをできるだけ正確に算出することは非常に重要です。システム開発のソフトウェアテスト見積もりにおいても同様で、システムテストがどれくらいの金額で、どれくらいの期間をかけて行えるのかをできるだけ正確に見積もる必要があります。
ソフトウェアテストの見積もり作業では、テスト工程に必要なコストや期間、リソースを予測し、これをもとにテスト作業の計画を立てます。テストを行うためにどのようなタスクが必要なのか、それぞれのタスクにどれくらいの工数を割り当てればよいのかを、見積もり作業によって算出します。見積もり結果を用いてテスト作業の計画を立てるため、見積もりが正確であれば信頼度の高いテスト計画を立案できます。
とくに、品質保証(QA)の領域では、テスト工数を正確に算出することで適切なテスト計画のもとで十分なテスト期間とリソースの確保ができ、プロダクトの品質向上にもつながります。
たとえば、テスト工数を少なく見積もってしまうとテスト期間が不足してしまいバグの見逃しが発生するなど、リリース後のトラブル・クレームにつながってしまうことが考えられます。見積もりが正確なら適切な計画とスケジュールのもとでテスト作業を実施でき、品質の伴った開発につながるのです。
このように、ソフトウェアテストの見積もりを行うことはプロジェクト計画に役立つだけでなく、プロダクトの品質向上にもつながる重要な作業であることがわかります。
▽あわせて読みたい▽
>>システム開発とは?工程や手法、依頼時のポイントまでわかりやすく解説
>>システム開発会社の選び方とは?失敗しないための事前準備や依頼の流れ
>>ソフトウェアテストとは?種類や目的、重要な7原則を紹介
>>ソフトウェアテストを効率化するには?テスト設計・テスト実行それぞれの方法を解説
ソフトウェアテストのことならSHIFT
「3分で知るSHIFTのテストサービス」の資料ダウンロードページへ
>>ソフトウェアテスト・第三者検証のページへ
>>導入事例ページへ
>>料金についてページへ
>>お問い合わせページへ
ソフトウェアテストのよくある質問はこちらをご覧ください。
>>ソフトウェアテストのよくある質問にお答えします。目的や種類、作業内容、外注先の選び方などを解説のページへ
関連サービスについて
ソフトウェアテストの見積もりが難しいといわれる理由
ソフトウェアテストを適切に計画するためには見積もりが必要ですが、正確に見積もりを出すことは難しいといわれています。その理由として、開発初期の段階では不確実な要素が多いことがあげられます。
見積もりを行う開発初期の段階では、テスト対象の仕様や開発範囲が不明瞭な場合が多いです。仕様や開発の範囲や難易度などが明確になっていない前提で、正確に見積もりを出すのは困難とわざるを得ません。特に、いままでに対応したことがない新しい分野の開発を行う場合や、開発チームメンバーが大幅に入れ替わっている場合などは注意が必要です。
しかしながら、見積もりを取らなければ開発ははじまりません。不確実な要素だらけのなかから、可能な限り減らしリスクを減らし、どれだけ見積もりの精度を高められるかというのが担当者に求められます。
ソフトウェアテスト見積もりの主な手法と特徴
ソフトウェアテストの見積もりを行う際には、いくつかの見積もり手法のなかからプロジェクトの状況や性質にあったものを選ぶことが大切です。ここでは、主な見積もり手法について、内容とその手法が適している状況を解説します。
類推見積(Analogous Estimation)
類推見積とは、過去の開発案件や類似プロジェクトのデータを参考にして算出する方法です。テスト対象のシステムの性質、機能、技術、チームの構成などが似ている過去の案件がある場合には、そのデータを参考にして見積もりを行います。
まずは過去のプロジェクトの実績、データを洗い出し、分析して今回のプロジェクトとの類似点を探します。たとえば同じような規模の開発、開発メンバーのスキルレベルが同程度、同じプログラミング言語を使うなどです。
類似点がある部分のテスト工数やテスト期間の数値を参考にして、今回のテスト作業を見積もります。過去データと比較して違いがある部分は、補正調整して見積もりを行う必要があります。たとえば、開発担当者が入れ替わって担当者のスキルレベルが下がる場合には、工数を増やすなどの補正が必要です。
この方法は、過去に類似プロジェクトがあれば簡単に見積もりできるという点が大きなメリットです。しかし、過去プロジェクトが今回のプロジェクトと大きく異なる場合には、見積もりの精度が下がってしまいます。いままでにない機能を開発する、新しい技術を採用する、開発メンバーのスキルレベルや経験値が大きく異なるなどの場合には、この手法はほとんど使えないことに注意が必要です。
パラメトリック見積(Parametric Estimation)
パラメトリック見積は、プロジェクトの特性をパラメータで表し、過去のデータに基づいて算出する方法です。
たとえば、「テストケースポイント法」では、テストの複雑さ、機能の数などをパラメータで表し、過去のプロジェクトからパラメータと工数の関係性を割り出して係数化します。このパラメータと係数を今回のプロジェクトに適用して工数を算出します。
この方法のメリットは、客観的なデータをもとに見積もりを算出するため、関係者に説明しやすいという点です。また、この方法で継続的に見積もりデータを蓄積し改善を重ねることで、見積もり精度を高めていくことも可能です。
しかし、この手法は過去のプロジェクトのデータやパラメータなどが必要なため、過去のデータがない場合には使えません。また、過去のデータからパラメータ化や係数化を行う際には、専門的な知識が求められます。
ボトムアップ見積(Bottom-up Estimation)
ボトムアップ見積とは、タスクを細かく分解しそれぞれのタスクの工数を算出したうえで、それらを積み上げていき見積もる方法です。この手法はウォーターフォール開発など、計画段階で工程が明確になっている開発手法に有効です。
まずはテスト作業を、テスト計画、テスト設計、環境準備、テスト実行、再テストなどとタスク分解します。そして、たとえばテスト設計をテスト観点抽出、テストケース作成などと必要に応じてさらに分解します。細分化されたタスクのそれぞれの担当者が工数を算出し、すべてを足してテスト作業全体の見積もりを算出します。
この手法では、具体的にテスト作業を洗い出して個々に見積もりをしたデータをもとにするため、見積もり精度が高いというメリットがあります。また、それぞれのタスクの担当者が工数見積もりを行うことで、当事者意識が高まり担当者が責任を感じてタスクを遂行できるようになるという副次効果も得られます。
一方で、タスクを細かくわけて見積もる必要があるため、見積もりに時間がかかるのがデメリットです。また、ウォーターフォール開発のように作業工程がある程度確定している場合は有効ですが、開発初期に要件が固まりきっていない傾向にあるアジャイル開発などには向いていません。
▽あわせて読みたい▽
>>ウォーターフォールモデルとは?メリット・デメリット・特徴をわかりやすく解説のページへ
>>テスト計画とは?目的や種類・作り方・注意点をわかりやすく解説のページへ
>>テスト設計とは?プロセスと作成方法について解説のページへ
>>テスト実施(実行)ですべきこと~必要な準備と実施手順について紹介~のページへ
>>テスト観点とは?必要性や洗い出すための要素、つくり方を解説のページへ
>>テストケースとは?書き方や満たすべき要件について解説のページへ
>>アジャイル開発とは?概要や進め方、ウォーターフォール型開発との違いやスクラムについて解説のページへ
ソフトウェアテストの見積もりに含めるべき要素・内訳

ソフトウェアテストの見積もりに含める必要がある要素について解説します。
工数項目
工数を見積もる際には、対象となる作業の範囲を正確に把握する必要があります。そのため、「テスト計画、テスト設計、テスト実行、不具合報告、レビュー、管理」のようにテスト工程のタスクを分解し、実際に行う作業内容を細かく把握します。
テストのボリュームも工数見積もりに影響するため、テスト対象となるシステムの機能の数や複雑さなどの情報も把握することが重要です。
工程や機能などを洗い出すことで、工数をより正確に見積もることができます。
付随費用
テスト作業に付随する費用についても見積もりを行います。たとえば環境構築費、ツールライセンス料、リソース教育コストなどに関しても漏れなく見積もることで、できるだけ正確なコストを算出できます。
条件・前提
開発期間、開発範囲、担当体制などの開発条件、前提についても考慮に入れる必要があります。
開発範囲が明確になっていないと正確な見積もりができません。どの機能まで対応するのか、顧客のニーズをどこまで取り入れるのかなど、開発範囲を確定させることが重要です。
また担当者の人数、スキルレベル、経験値なども見積もりの重要な要素です。過去に同様のテスト経験がある経験者が多いテストチームと経験者が少ないテストチームでは、必要な工数が大きく変わってきます。このように担当体制も考慮して、より正確な見積もりを行う必要があります。
精度の高いソフトウェアテスト見積もりを行うためのコツ
ここでは、精度の高いソフトウェアテストの見積もりを行うために気をつけたいコツについて解説します。
スコープを明確にする
見積もり時にもっとも重要になるのがスコープ(開発範囲)です。テスト対象となるシステムの範囲はどれくらいなのかを明確にしないと、正しい見積もりができません。開発範囲が曖昧なまま見積もりを進めてしまうと、後から開発範囲が広がった場合に作業量が見積もり量を大幅に超え、計画どおりに作業を進められなくなってしまうでしょう。
そのため、要件定義書などの仕様書で開発スコープを把握し、テスト範囲を明確にしておくことが重要です。また、新機能のテスト範囲だけでなく、新機能追加に伴う既存機能への影響のテスト(リグレッションテスト)の範囲も明確にする必要があります。
テスト範囲が把握できたら、テストデータの準備、テスト環境の準備などの工数見積もりも必要です。また、テストの結果不具合が出た場合の不具合報告、修正フローなどの作業についても明確にし、見積もっておきましょう。
▽あわせて読みたい▽
>>要求仕様書とは?要件定義書やRFPとの違いから書き方、構成まで解説のページへ
>>リグレッションテスト(回帰テスト)とは?目的や自動化のメリットを解説のページへ
過去データを活用する
見積もりの精度を上げるためには、過去データや客観的なデータを活用するのが効果的です。
必要となる期間と工数を関係者や上長に説明するためには、「なぜその数字になったのか」という明確な根拠が必要です。その際に、過去に類似のプロジェクトがあってこの工数だった、タスクを積み重ねていくとこの工数が必要だ、などの客観的なデータをもとにすれば、見積もりに説得力が加わり、また正確性向上も期待できます。
チームでレビューを行う
見積もりをチーム内でレビューすることも重要です。一人で見積もりを進めると、「その人が想定できる範囲での見積もり」になってしまい、後から想定外のタスクが必要になったり、追加工数が発生してしまったりして計画が狂ってしまうリスクを抱えます。
見積もりの根拠となるタスクや成果物などを正しく洗い出しているか、漏れがないかなどを複数人でレビューすることで、見積もりの精度を高められるでしょう。
また、開発中に適宜プロダクトの品質をレビューして見極めることも重要です。場合によっては、品質評価を行った上で事前の見積もり内容と照らし合わせ、必要に応じて再見積もりを行うことも考慮すべきでしょう。
PDCAで予実を管理する
上記でご説明したとおり、見積もりを行う際には過去のデータが非常に重要になります。過去の見積もりデータの精度が高ければ、そのデータを参考にした見積もりの精度も上がります。
そのため、見積もりを作成したらそれで終わりではなく、プロジェクトが完了した後に見積もりと実際の進捗状況を照らし合わせて振り返ることが重要です。見積もりと実際の作業に乖離した点はなかったか、あった場合にはどれくらい乖離していたのか、どこが間違っていたのかなどを詳しく検証しましょう。そして、次のプロジェクトで見積もりを行う際に、振り返った内容を反映することで、より精度の高い見積もりができるようになります。
見積もりの作成、プロジェクト遂行、予実の振り返りと分析、見積もりの修正とPDCAサイクルを回し、見積もり精度を向上させていくことが重要です。
起こりがちなトラブルを想定しておく
プロジェクトの遂行において、すべてが予定通りに進むとは限りません。そのため、見積もりの時点で起こりがちなトラブルを想定しておくことも重要です。
ありがちなトラブルとして、開発範囲が変更になりテストが増える、チームメンバーが離脱するなどが考えられます。このような起こりやすいトラブルを想定し、予備の工数、バッファを設けておくことでプロジェクトを円滑に進められるでしょう。
まとめ
この記事では、ソフトウェアテスト見積もりの目的と重要性、見積もりの算出方法、見積もり精度の高め方などについて解説しました。
見積もりの精度を上げることはシステム開発を円滑に進めるために非常に重要な作業です。特に、ソフトウェアテストの見積もりの精度が低いとテスト計画に悪影響を及ぼし、ソフトウェアの品質低下につながる恐れもあります。そのため、この記事でご紹介した見積もりに関する情報を参考にしていただき、見積もり精度を上げる対策を講じてみてください。
品質・精度を徹底的に追求する、SHIFTのソフトウェアテスト。まずは一度お見積りを
システム開発におけるソフトウェアテストの品質向上にお悩みの場合には、SHIFTのソフトウェアテスト・第三者検証をご活用ください。
SHIFTのソフトウェアテスト・第三者検証では、テストプロセスを徹底的に分解、標準化し、ソフトウェアテストを「ITサービス」として確立しています。SHIFT独自の緻密で網羅性の高いテスト手法により、お客様の製品・サービスに安定した高い品質をお届けします。
過去多数のクライアント事例と豊富なノウハウから、お客様のご状況に合わせた見積もりをお出しいたします。まずはお気軽にご相談ください。
監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――


