下っ端が工数見積する際に気にしてること
概要
下っ端ながらpmチックなことを少々やっているので、工数見積もりに関して意識していること、参考にしていることなどを記載する。
経緯
元より管理とか開発体制とかに興味あった。
なのでスクラム研修とか受けてたら、管理側が不足していたこともあり縁あって管理的なことをさせてもらってる。
自分への備忘録も兼ねて現在時点で気にしていること、参考にしていることをまとめる。
気にしていること
数値が出る様にして可視化される様な状態になっていること
見積もり及び進捗が可視化、定量化されていて、どの関係者にも明確に提示できる様にしておく。
プロジェクト管理ツールを使う際は、完了状態を可視化、定量化してくれるツールなどを有効利用しながらチーム内でも認識を合わせてカバーし合える状態を作成する。
どうしても明確な指標がなければ再現性に欠け、主観が入ってしまうので意識している。
(それでもまだまだできていないが)
過去の結果をもとに見積もりを立てること
過去のデータを用いることで見積もりの超過を抑えることができるらしい。
見積もりする際は企業特有の組織状態・影響を考慮する必要があるが、その詳細まで把握することは難しく、間違いも生じやすい。
だが、過去の定量的なデータを用いれば詳細を知る、知らないに限らず、全ての要因を加味した調整ができる様になるからである。
過去のデータ、すなわち「文書化された事実」の使用と、コストやスケジュールの超過には、負の相関がある。つまり、過去のデータを使用して見積もられたプロジェクトは、コストやスケジュールの超過が少ない（LedererandPrasad1992）。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (Japanese Edition) (p.161)
また、次のプロジェクトは前のプロジェクトと同じ様に進むという単純な前提を使用することで、主観や根拠の無い楽観主義を回避できる。
過去のデータを、生産性を予測するための土台にしよう。投資信託会社の情報公開と違って、自組織の過去の実績は、将来の実績の最も良い指標になる。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (Japanese Edition) (p.164)
最良、最悪、最有力を出してから想定工数を出す
このケースも上述の本からのエピソードだが、ある開発者に一点見積もりで見積もりをしてもらった後に、
今度は最良ケースと最悪ケースの２点見積もりを行ってもらう。
その結果一点見積もりは最良ケースとかなり近い結果となっており、さらには最良ケース、最悪ケースの両方で一点見積もりの際の工数より大きい値になっている機能もある結果が出た。
このエピソードから言えることは、基本的に最良ベースで見積もりを行ってしまうので、一点見積もりを行った後で最良、最悪の二点で見積もりを行うことで主観的な楽観見積もりを防ぐことができる。
最良ケースと最悪ケースの見積りを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (Japanese Edition) (p.188)
そしてこの二点に有識者の見積もりである最有力ケースも加えて、PERT(Program Evaluation and Review Technique)の公式を用いることで、定量的かつ不必要に大きい見積もりを行うことも防げる。
期待ケース = [最良ケース + (4 * 最有力ケース) + 最悪ケース] / 6
計画の最後にバッファをまとめること
基本的にバッファを各タスクに持たせるとそのバッファを全て消費しながら進めていってしまう。
そこでバッファを各タスクではなく、クリティカルチェーンの最後に集約させることで、本当に必要な時に使用する。
何よりこの状況を作成することによりバッファ消費率を可視化することができる。
求められている計画ではなかった際はメリットデメリットを認識した上で微調整・交渉
にもある通り、見積もりがミスるのは以下と書かれており、
これらの要素を考慮した見積もり結果がビジネスもしくは顧客に削ぐわなかった場合、修正する場合は他を優先度を下げて行うのがまず考えることだが、それも許されなかった場合は見積もりバランスが崩れるので、崩れた計画で納めるためのメリット・デメリットを認識してもらった上での微調整をする。
(テストカバレッジ率、リリース機能の減少など... この交渉がうまくできているかは別として)
(1番が多いイメージ、双方の言い分がわかるので精度は大まかであることを念押しし続ける)
- 要求が完全に決定される前に、正式な見積りが求められる。
- 過去の実績データがなく見積りのキャリブレーション（較正）ができない場合が多い。
- 新しい要求が加えられても、見積りは変更されない。
- 主要なソフトウェア開発プロジェクトにおいて、見積りツールが使われるわけではない。
- 保守的な見積りは封じられ、挑戦的な見積りに置きかえられる。
LM. Liard & M.C. Brenman, “Software Measurement and Estimation: A
Practical Approach”, John Wiley & Sons, Inc., 2006- 期間と工数に関して、「望み」と「見積り」が混同されている場合
- 期待に基づいた計画がなされる場合
- 見積りに関して根拠をきちんと説明できない場合
- 要求が曖昧な場合、要求が変化し、増加していく場合
- 成果物の品質が悪い（顧客の満足が得られない）ことが判明した場合
ズレた際は優先度での機能削減検討と実際の進行に基づく再見積もり
どうしても計画がずれた際は、まずは満たすべき機能の中で優先度の低いものがあるかどうか、バッファ消費だけでもカバーしきれなかった際は機能のカットを検討、提案する。
その上で、再見積もりする際は当初の見積りではなく、実際の進行に基づく再見積もりを行うことで見積もりのズレを少しでも減らす。
デッドラインを達成できなくて再見積りするときは、プロジェクトの進行計画ではなく、実際の進行に基づいて、新しい見積りを作成しよう。
スティーブ マコネル. ソフトウェア見積り 人月の暗黙知を解き明かす (Japanese Edition) (p.296)
結論
書いていながらできていない時も多々あるから定期的に戻って意識し直したい。
まあここら辺は楽しみながら進んでいきたい。知らんけど。
参考文献
Discussion