工数見積のテクニックについていろいろ知見がたまったのでまとめておく。
工数見積の難しさ
工数見積は難しいが、それはそもそも着手前に正確に工数を見積もる事が不可能だから。 「不確実性のコーン」の話の通り、未知の問題を前もって考慮することなどできない。
とはいえ「どれくらいでできるのか」の目安がないとビジネスが行えないので工数見積は必要になってくる。
なので、下記テクニックを使って見積もりの制度を上げる
期間バッファを設ける
見積もり時点で考慮していない問題が発生した場合にそなえて予備期間を設けておく。
機能バッファを設ける
「絶対に必要な機能」と「できれば必要な機能」に分類し、想定外の問題により時間が足りなくなった時に「できれば必要な機能」の実装作業をカットする。
いつでもリリースできる状態を保つ
「納期が来てリリースしようと思ったらデプロイ環境が整っていない事に気がついた」などの状況が起こらないように、実装作業に取り掛かってまず最初にリリースできる状態にまでもっていく。
この時機能はダミーでよいが「動作している状態」にする。
以後は必要な機能を追加していく形で実装作業を進めるが、常に「動作している状態」をキープする。
こうしておくと仮に急に納期が短くなったときにも、単に今進めている追加機能が乗らないというだけでリリースには問題が起こらない。
計測する
実際にどれくらいの規模の機能をどれくらいの工数で完成させたのかを計測しておく。
計測結果を次の見積もりに活かすことで次第に制度が上がっていく。
とはいってもこれらのテクニックが使えない場合
様々な理由で自分の思う工数で進められない状況はある。
無理とも思える工数見積もりを上から提示される場合もあると思うが、
基本的にはそれに従うべきだと思う。
と思うのには、上には上の意図があるから。
単に自分の信用が足りないのかもしれないし、
工数プレッシャーによって開発速度をあげようとしているのかもしれない。
ただしこの時、それが自分の思う達成可能工数ではない場合、
「達成できるように努力はするが、達成を約束できるものではない」
という事を正しく確実に伝えておく事が大切だと思う。
