概要
QAとしてソフトウェア開発の品質保証を経験する中で、「見積もり」についての考え方をまとめた。
なお、基本的な説明がない限りは、日本のWeb業界（アジャイル開発）に対する品質管理を想定した記述とする。
Web業界に関わらず、見積もりについて様々な意見やご指摘等を頂けたら嬉しい。
見積もりとは？
見積もりについての代表的な指標といえば、PMBOKの見積もり種別が一般的かと思うが、
- 超概算見積もり：−50%、+100%
- 概算見積もり ：−25%、+50%
- 確定見積もり ：−5%、+10%
※計画の立ちあ上がりから各見積もりが作成され、右側の数値は実績との予実差に対する許容範囲となる。
ソフトウェア開発における「見積もり」においては、PMBOKの見積もり種別を少しカスタマイズした、下記の種別が適していると考えている。
- 超概算見積もり：−50%、+100%
- 概算見積もり ：−30%、+50%
- 詳細見積もり ：−10% 、+20%
カスタマイズを行なった理由は、
- 5%の計算が面倒
- ソフトウェア開発では他業界より見積もりからの変動が大きいため
- 20%以内の増加なら平均２時間程度の残業、少人数の追加アサインでリカバリ可能な範囲のため
により、見積もり精度の範囲を調整している。
また、ソフトウェア開発においては確定見積もりとはあまり聞かず、詳細見積もりが最終的な見積もりとして作成されているケースが多いため名称も詳細見積もりと変更している。
見積もりの目的
なぜ見積もりが必要なのか？なんのために見積もりを行うのか？
見積もりを作成する理由や、作成した見積もりをどのように活用するのかについても筆者の考えを共有する。
-
スケジュール、予算の計画立案のため
一般的な目的であり、あまり認識がずれる部分ではないので割愛する。 -
進捗状況の確認のため
現時点の実績から開発完了までの見込みが、見積もり予実差の許容内に収まっているかを確認することが進捗状況を判断する１つの指標となる。
大切なことは、見積もりの予実差内に収めようとするのではなく、見積もりの計画から大きな差異を発生させている原因を明確にすることだ。その原因が解決できるのであれば良いが、解決が見込めない場合は早期に再見積もりや再計画を検討する必要がある。 -
振り返りの指標
一案件の検証が完了した時点で、見積もりを一つの基準として振り返りを行うことができる。
この場合に、見積もりの予実差の許容内に収まったらOKで、収まっていないければNGとして分析を行ってもあまり意味がない。（個人の見積もり精度の向上に対しては意味はあるが、、、）
振り返りで必要な分析とは、
【予実差が許容外の場合】
- 余日差が発生した原因や問題は何か？
- 見積もり時点でなぜ考慮ができなかったのか？
- 問題をなぜ防げなかったのか？（どうすれば防げていたか？）
- 問題の検知タイミングが適切だったか？
- 検知したタイミングで適切な対応がされていたか？
【予実差が許容内の場合】
- 計画通りに進めるために、不適切な対応を行っていなかったか？
- 期間や費用に過度なバッファがなかったか？
- より改善するための余地はないか？
の観点で、プロジェクトが適切に運用されていたかを分析する。
各見積もりについて
各見積もりについても筆者の考えをまとめた。
超概算見積もり
企画の立ち上げ段階で頭出しとして受けた情報から、リーダーや担当者が過去の検証実績や案件の知見から大まかに見積もりを行う。基本的には超概算見積もり文書として作成することはなく、案件管理のガントチャートやアサイン管理表などに暫定工数として計画値として記載を行うケースが多い。
概算見積もり
要件定義書やPRDなどのドキュメントから見積もりを行い、テスト計画書としてドキュメントも作成する。この段階である程度の検証観点や検証スコープの大枠を企画／開発側と調整を行う。
概算見積もりでは検証対象の機能や画面などで分類し、更に工数規模で複数のグループに分けることで、工数規模ごとの工数見積もりを出せばグループに含まれる機能や画面の数との掛け算で工数を算出することができる。
概算見積もりの時点で細かい検証内容に落とし込んでから見積もりを行なっても、開発方法や仕様変更などによって再見積もりが必要となり工数がかかってしまうが、ロジックによる計算で概算見積もりを算出する方法であれば、計算するグループの数や係数を変更するだけですぐに再見積もりが可能となる。
設計期間と検証期間のそれぞれで実現可能なスケジュール、アサイン状況かを見積もりから判断する。検証期間に余裕がない場合は、開発スケジュールの遅延が致命的となるため、開発スケジュールをどの程度の頻度で把握する必要があるかも事前に調整しておくとスケジュールの調整が行いやすくなる。
詳細見積もり
検証観点や検証スコープが明確となり、テスト設計が可能な段階になったら詳細見積もりを行い、詳細見積もり文書としてドキュメントを作成する。
詳細見積もりでは検証観点を洗い出し、観点ごとに実施方法を考慮して検証工数の見積もりを行う。同じ観点でも機能や画面ごとに検証工数は変わってくるため、概算見積もりのグループ分けなども参考に各検証観点の工数は調整する必要がある。
詳細見積もりの工数をベースに、設計、検証実施の進捗状況を確認していくことになるため、検証スケジュールの区切りで余日差の工数感が把握しやすいように、ある程度機能や検証観点等で項目書を分けて見積もり工数をまとめるなど、設計や実行の進め方を考慮した見積もりの仕方が重要となる。
まとめ
見積もりは作成したら完了ではなく、開発状況に合わせてスケジュールの調整やアサインの調整などを、開発フェーズの見積もり段階に合わせて調整を行い、余日差が見積もりの許容範囲を超える場合は再見積もりや時フェーズでの見積もりを調整する必要がある。
精度の高い見積もりを心がける事は必要だが、重要な事は開発進捗や状況に合わせて適切なタイミングでスケジュールやアサインを調整することと、最終的には詳細見積もりの余日差−10%〜＋20%の対応に柔軟に対応できる体制を整える事だ。