概要
後輩に「どうやって工数見積もってますか？」と尋ねられて回答したことがあって、自分用にまとめた。
今から対応する場合
自分がやることを洗い出す
仕事を依頼されたら、設計書を読んで理解するところから、実装して動確してプルリクエストするまでに自分がやることを全部洗い出す。
他人が動作確認・レビューする時間は含まない。レビューを待っている時間も含まない。
洗い出す粒度
人による、仕事によるだろうけど、最近は「Controller作成」「FormType作成」くらいの単位。 今関わっている仕事では、ソースレビューをしあう習慣がない(仕様を満たすかどうかのチェックはある)のでレビュー後の修正はほぼ見積もってない・・・。
社会人1年目の案件では、プルリクエスト後にしっかりレビューし合う習慣があり、コードの書き方や自分のミスで指摘される頻度が多いだろうと予想できたので、
工数見積もり→実装方針を決める→実装→リファクタリング→動作確認→プルリクエスト→レビュー後の修正→プルリクエスト2回目
くらいの粒度だった。実装の部分はもう少し細かくしてたかも。
各タスクの工数を見積もる
やることを洗い出したら、各項目ごとに何時間くらいかかりそうか数字として出していく。この合計が見積もった工数になる。
入ったばかりの案件とか、初めて工数見積もるときは予想より多かったり少なかったりするけど、それでOK。
徐々に精度をあげていくこと、予定工数より大幅に工数がかかりそうなことが分かったときにすぐに上長や周りに伝えることが重要...だと思う。
見積もったらN倍することで割り込みタスクを許容する
設計やお客とのやり取りがメインであるAさんは「自分が最初に見積もった工数を3～5倍にしてそれを予定工数としている」と言っていた。客とのやり取りとか、他の人からの質問とか、割り込みのタスクが多いからそれでちょうどいいみたい。
私もそれを見習って初めは3倍くらいにして計算していたけど、基本的に毎日調査と実装をしていて割り込みタスクが少ないので今は3～5倍にすることはあまりない。
未知のタスク(使ったことのないライブラリを導入するとき等)は3～5倍にすることが多い。
工数を記録して見積もりの精度を上げる
私の場合、スプレッドシートに「見積もった工数」「実際にかかった工数」を毎回記録している。
最近人に見せるために作っていないのでめちゃくちゃだけど、こういう感じ・・・。こうやってスプレッドシートで管理し始めた頃は、上長に共有して進捗管理していたのでもう少し丁寧にする必要があった。
A～G列にやることを書き出し、かかる工数を入力し、それを合計する。実装時に自分が忘れそうなこと、懸念していることを備考にメモしたりする。
実際にかかった工数は、H列以降に直接数字を入力したり、E列の値を使って算出する。ここらへんは本当に適当。マメなひとに怒られそう。
ステータス欄を埋めないまま実装完了していることが多いので、不要かもしれない。でも金曜の夜とかにどこまで進んだか記録しておくと、月曜にどこまでやったっけ？何やってたっけ？ってなりにくくなっている・・・かも。
記録しておくと、次回以降それを参考に見積もることができる。
例
・注文明細PDF出力機能は50hかかった。見積書PDF出力機能は注文明細PDF出力機能を流用できるから、注文明細のときよりかなり工数減らして8hくらい
・注文履歴ページは、お気に入りリストページと同じレイアウトだから流用できる。閲覧履歴ページを実装したことがあるけど少し処理が違うから16hくらい
まだ対応しない場合
「全体であとどれくらいかかりそうか？」とスケジュール把握したいとき、着手するのはまだまだ先の仕事でも、かかる工数を見積もる必要がある。
その場合は、やることの洗い出しはせずに、わりとざっくり見積もっている。
半日、1日弱、1日、3日、etc...
着手開始するときに、改めてやることを洗い出して見積もり直す。
それまでにこなした仕事で実装方針がすぐ決められるようになっていたり、ライブラリの使い方の調査が済んでいたりするので、最初に見積もっていた工数よりぐっと減らせることがあるから。
逆に、最初に想定していたよりも予定工数が増えることもある。そういうときは早めに周囲に伝える必要がある。