1．概要
本記事ではソフトウェアテストの見積もり方法について記載します。また、基本的な見積もりの考え方は、開発側の見積もりでもテスト側の見積もりでも変わりません。そのため、できる限りどちらでも使えるようにまとめました。
はじめに「見積もりはなぜ難しいのか」、という観点から説明し、見積もりの手法、ドキュメントへのまとめ方までを説明します。
2.見積もりの難しさ
見積もりとは、作業を行うにあたり「どんなタスクがあってどれだけの時間と人数が必要なのかを調査し資料にまとめる作業」のことです。
ただ、見積もりはベテランエンジニアでもよく失敗する大変難しい作業でもあります。
以下資料を参考にすると「94.5% のプロジェクトが深刻な失敗を経験した」とされています。これは、ある意味見積もった結果（予想した結果）とずれが生じで失敗した、とも言い換えることができます。
私のこれまでの経験でも、見積もった結果と実際の結果がずれたことは多く、上記の失敗率と大きな差はないと思っています。
なぜ見積もりに失敗しているのか？
見積もりとは、
「見積もりができる＝今後起きるであろうすべての問題点やタスクを事前に割り出さないといけない」
ということでもあります。例えば以下のようなことも、開発の初期から洗い出しておこなければなりません。
- システムの仕様はいつまでにできるのか？
- 担当者の技術力は？必要な人材は集まるのか？
- 影響範囲は問題なく割り出せているのか？
- どのくらい不具合が出るのか？
- テストのデータは準備できているのか？
つまり、正確な未来予知ができる必要となります。また、正確に未来を読める人など誰もいませんので、正確な見積もりができる人もほとんどいないのです。
上記は「不確実性コーン」と呼ばれる、時間の経過とともに見積の正確度がどのくらい変わるのかを表した図です。
過去の見積もり事例から算出した表で、システムの企画段階では、4倍～0.25倍のずれが起き、プログラミングが完了時には、見積もりのずれは0となります（ものができ上っているので、プログラミング完了時ではこれまでにかかった時間を算出するだけでいい。）
この図から読み取れることは、開発初期にすべてを見積もることは難しく、見積もりの正しさは結果論からでないと判断できない、ということです。
そのため、初期の見積もり結果を深堀しても意味がありません。誰も未来が見通せない＝誰も正確な根拠を言うことができない、となるので以下の理由ばかりとなります。
- お客様がその日に欲しいといったから。
- リリース日から逆算したらそれくらいになるから。
- 早めにリリースした方がいいと思ったから。
- なんとなく。
- 上からの命令です。
「見積もり」と「管理」
上記の理由から見積もりとは、
- 「究極の当てずっぽう」
- 確定しない未来に対して、可能な限り近づけていく作業のこと
- 算出したスケジュールを、さもあっているかのように説明する技術のこと
とも言い換えることができます。そのため、見積もりと必ずセットとなる概念が、管理となります。（見積もっただけで終わりではなく、見積もった結果との差異を正していく作業が必要）
- テストの見積もり →ある程度正確にタスクを割り出す
- テスト管理 →見積もり結果から外れないように、管理する
見積もりを行った際は、見積もりだけでなくその後の作業を管理していることで、正確性の向上やリスクの低下につなげることができます。
3.見積もり方法
テストの見積もり方法は、大きく3つあります。
- ボトムアップ見積もり
- 類推見積もり
- 係数モデル見積もり
ボトムアップ見積もりは、実際にタスクをやってみて工数を出す方法となります。例えば、テスト実施がタスクの場合、以下のように算出します。
- テストケース1000件の工数を出す
- 10件やってみる →1時間かかった
- 1時間＊100 ＝100時間だ！
また、すべてのテストを実施することは難しいので、代表的なものだけ実施することが一般的です。（テスト計画書であれば、実際の計画書をざっくりと書いてみてどのくらいかかるかを算出します。）
つまり、未来がわからないのであれば、実際にやってみて工数を算出する手法となります。そして、それぞれ算出したタスクを積み上げていくことで、総工数を見積もります。
類見積もりは、過去の案件の実績から見積もり結果を算出する手法になります。例えば、A案件の見積もりを算出する場合、
- A案件と類似したA’案件があった
- テスト計画の内容はA'と変わらない
- A'の工数をそのまま利用
こちらは類似する案件や過去の実績を利用するので、開発事例のない新規案件や過去の実績をまとめていない場合、利用できない見積もり方法となります。
係数モデル見積もりとは、様々なモデルを用いて工数を算出する手法です。こちらは算出する方法が難しいので、今回省略します。
- FP法
- COCOMO/COCOMO II
- CoBRA法
見積もりの注意点
どの見積もり方法を用いても重要な点は、バッファ（予備の工数）を持たせておくことです。どの作業中でも必ず例外作業や予期しないことが発生しますので、それに対応できるように予備の工数を確保しておくべきです。例えば、以下のようにして計算します。
- 1日8時間働く場合、6時間に直して計算する
- 全体の工数を1.3倍する（全体の作業にバッファを持たせる）
4.スケジュールの作成
見積もり方法でタスクを洗い出し、それらをスケジュールにまとめます。基本はWBS形式にまとめれば問題ありません。また、その際各メンバーのタスクをかぶらないようにした方がいいです。（最初からマルチタスクにすると、作業に切り替えがうまくいかず、バッファを消費することがあるので）
また、全体のタスクを一覧化することで、抜け漏れの確認を行うことができます。特に抜けやすいタスクに以下があります。
- テスト環境の準備
- テストデータの準備
- 自動テストの動作確認
- 事前のスモークテスト（リリースして動かない、ということもあるので）
見積もった結果をスケジュールにまとめ、最後に説明資料を作成します。この際作成する資料は何がいいかと言いますと、私はテスト計画書がいいと思っています。（開発の場合はプロジェクト計画書など）
見積もりの根拠を説明するには、以下の情報が必要です。
- どこをテストするのか？
- どんなテストを行うのか？
- 何人で行うのか？
- 納品物は何か？
そして、上記の情報をすべて満たすドキュメントがテスト計画書になります。私の中では「テスト計画書＋金額が記載」となったドキュメントを見積書と考えていますので、上記ドキュメントを作成することが、見積もり作業の一旦のゴールとなります。（その後、テスト管理へとつなげる）
5.まとめ
本記事ではテストの見積もりについて記載しました。見積もりは不確実性の高いものであるため、明確な根拠を求めることは難しいことです。そのため、実際にタスクを行ってみる、など行い不確実性を少なくした上で、全体の計画書としてまとめることとなります。