皆さん、こんにちは！ QAエンジニアのいかぽっぽです。
お客様や上司から、このテスト、ざっくりどのくらいかかりそう？と聞かれて困った経験はないでしょうか？
ざっくりとは言っても、それなりになぜこのくらいかかりそうなのか？の説明は必要です。本記事では、基本的なソフトウェアテストの見積の考え方や手法についてご紹介したいと思います。
テスト見積の経験がまだあまりない方や、より精度の高い見積を作成したい方にぜひお読みいただければと思います。
見積とは？
そもそも見積とは？のおさらいになりますが、
目分量や心づもりではかっておおよその見当をつける。目算する。 工事や製品などの、原価・日数・経費などを前もって計算して出す。
「デジタル大辞泉」より
と定義されています。
基本的な考え方や手法はソフトウェア開発と同様ですが、テストの見積においては、主にテスト工程全体や各テスト工程ごとの作業期間、スケジュール、規模感、必要なリソース、コストなどを対象としてアウトプットすることが一般的です。
品質のゴールやテストスコープ、テストタイプ、テスト環境、使用するツールなどの様々な条件によって、算出結果は大きく変動します。
テスト見積の目的
テスト見積の目的は、予算取りのため、プロジェクト計画のため、テストを遅延なく推進するため、など様々あります。また、お客様やプロジェクト管理者だけでなく、見積に基づいて作業を行うQAエンジニアにとっても非常に重要なものです。
目的次第で、用いる手法や算出単位も変わります。
テスト見積の主な手法と特徴
テスト見積でよく用いる手法として、大きくは3つの分類があります。
他にも手法は様々ありますが、ここでは私のこれまでの経験上、多様なテスト見積のシーンに適用できるより汎用性の高いものに絞ってご紹介します。
その1： 類推見積
過去の類似したプロジェクトなどの実績や情報をベースにして、類推して見積もる方法です。具体的な手法としてKKD法やデルファイ法などがあります。（各手法の詳細説明については割愛させていただきます。ご興味のある方は、ぜひ検索してみてください！）
メリットとしては、プロジェクト開始前、もしくは初期（要件定義が完了していない状態）でもある程度根拠のある見積を作成することができること。また、他の手法と比べ、時間をかけずに手早く算出することができます。そのため、プロジェクト全体の予算取りや各テスト工程の概算見積の際によく使われます。
一方、デメリットとしては、プロジェクト特有の条件が反映されづらい点、精度のブレが大きめなことなどが挙げられます。
巷でよく耳にする「エイヤで出す」というのは、だいたいはこの類推見積のパターンが多いです。
その2： ボトムアップ見積
各成果物やタスク単位での工数を算出し、それらを積み上げて見積もる方法です。プロジェクト開発ではお馴染みのWBS（Work Breakdown Structure）はこのボトムアップ見積の代表格と言えます。
メリットとしては、成果物やタスク単位で細分化、可視化するため、納得度の高い見積を作成することができる点です。スケジュールやコストの予実管理にそのまま使えることも大きな特徴です。
デメリットとしては、プロジェクト初期での適用が難しいこと。ドキュメントや画面数など一定の基準となる単位をインプットとして用いるため、少なくとも要件定義レベルまでは完了している必要があります。また、他の手法と比べ、見積作成に手間と時間がかかるケースが多いです。
その3： パラメトリック見積
係数モデルなどを用いて、パラメーターを設定して見積もる方法です。主な手法としては、FP法やCOCOMO法、CoBRA法などがあり、国内外問わず利用実績の多い標準的な手法であるため、係数の信頼度が高く納得性を得られやすいことが最大のメリットです。
しかし、これらを厳格に適用するためには、見積のインプット情報収集や係数設定にそれなりの経験、スキルが必要であるため、現実的にはパラメトリック見積の考え方を活かしてアレンジした見積を行うケースが多いかと思います。（この後、具体例にて説明します。）
各手法を用いた具体例
各手法を用いた見積算出のイメージについて、簡単な具体例で説明したいと思います。
その1： 類推見積での算出イメージ
例）過去実績のあるA案件をベースに、類似案件（A´案件）のテスト工数を類推見積で算出する場合
A案件の実績データ テスト対象：100画面 に対して、 テスト設計：n人日、テスト実施：m人日
A´案件のテスト対象が300画面（＝A案件の3倍のボリューム）だった場合、テスト設計とテスト実施の工数合わせて、
（n人日＋m人日）× 3 人日
として見積もります。
その2： ボトムアップ見積での算出イメージ
例）テスト設計の工数をボトムアップ見積で算出する場合
テスト設計の各タスクを洗い出し、それぞれの工数を積み上げます。
1画面のテスト設計につき、18h ― 仕様把握：2h ― テスト観点の抽出：4h ― テスト項目作成：8h ― レビュー：2h ― レビューコメントの反映：2h
テスト対象は全部で10画面あるとすると、テスト設計のtotal工数は、
18h × 10画面 ＝22.5 人日
となります。
この場合、1画面分のテスト設計を実際にサンプルとしてやってみた実績値を適用すると、より精度の高い見積を算出することができるでしょう。（実際のプロジェクトでは、なかなかそんなことをしている余裕はないのが現実ではありますが・・・）
その3： パラメトリック見積での算出イメージ
例）作成するテストケースのボリュームをパラメトリック見積で算出する場合
対象の機能ごとに規模感をカテゴリー分けして、重み付けを行います。
規模感：大きめの機能 →200（ケース）を設定 規模感：普通の機能 →100（ケース）を設定 規模感：小さめの機能 → 50（ケース）を設定
規模感：大きめの機能が10、規模感：普通の機能が50、規模感：小さめの機能が30あるとすると、
（10機能 × 200）＋（50機能 × 100）＋（30機能 × 50）＝ 8,500ケース
となります。
上記の例では、FP法の考え方を使った係数設定（重み付け）を行っています。この重み付けは、規模感や複雑度などある程度定量的な情報を見積結果に反映することができるため、これらのインプット情報がある場合はぜひ積極的に取り入れてみてください。
より精度の高い見積を目指すためのポイント
ここまで、大きく3つの分類に分けてご紹介しましたが、それぞれメリットとデメリットがあるので、手法を組み合わせて使うことも効果的です。
見積を作成したら、以下3つのポイントに着目してチェックすることをおススメします。
見積対象や条件の洗い出しに漏れがないか
成果物やタスクなど、見積の対象、条件の洗い出しに漏れがないかの確認を行います。
よくあるのは、お客様側で対応してもらえると思って見積には含めていなかったタスク（例えば、テストデータ投入など）が実は自分たちで対応しなければならなかったことが後から発覚し、追加工数が発生する、という残念なしくじり事例です。
見積を依頼した側と見積を作成した側の認識のズレをなくすためにも、抜け漏れ確認は重要なチェックポイントと言えるでしょう。
見積根拠が明確になっているか
お客様や上司が見積を確認する際に、納得性がある見積になっているでしょうか？
算出結果の数字のみを記載するのではなく、前回のX倍のボリュームと仮定、など前提となる考え方を記載しておくと、見積作成のロジックを読み取ることができるようになります。（前提自体が誤っていた場合は、そこから軌道修正ができるようにもなります。）
なぜXX人月必要なのか？、その内訳まで説明できるように根拠を明確にしておくことが重要です。
見積のPDCAサイクル化を図り、予実を照らし合わせて振り返ることが大切
見積を作成したらおしまいではなく、予実について振り返り、ギャップの原因を分析することも大切です。過去実績として「使える」見積にしておくことで、次回の案件時、より精度の高い見積を作成することができます。
見積作成→実行→予実振り返り/ギャップ分析→見積修正/データ化のように、PDCAサイクル化することで、見積の精度向上を図りましょう。
おわりに
繰り返しになりますが、テスト見積においては、漏れなく、根拠を明確に、そして予実の振り返りを行うことが大切です。
ぜひ実践してみていただけると幸いです。
最後までお読みいただき、ありがとうございました！
