作業の工数を見積もるときの3つのポイント
自分は今年で3年目のエンジニアになるが、未だに作業工数の見積もりは難しく思う。
今までいくつかのプロジェクトにアサインされてきた。その中で、自分はPGとしてコーディングをしたり、
SEとして設計書作成をしていたが、共通しているのはそのタスクには期限があるということ。
そしてその期限をもって、プロジェクトの全タスクはスケジューリングされている。
タスクには期限を設ける必要があるため、そのタスクについていくつか考えなければならないことがあるだろう。
「そのタスクの成果物は？」
「そのタスクの完了にはどのくらい時間がかかるの？」
「そのタスクはいつ終わる？」
将来の結果を予測するのは難しい。だが見積もりは重要だ。
なぜならいつ終わるのか分からなければ、次のタスクをいつ振ればいいのか決めようがないから。
つい先日、プロジェクト内のPMに見積もりについていい事を聞けたので、ここでまとめてみる。 見積もりのポイントは次の3つ
- タスクは細かく分割する
- 工数はフィボナッチ数列を使って見積もる
- 工数が分かるタスクで相対的に測る
1つずつ章ごとに分けてまとめてみる
タスクは細かく分割する
タスクの見積もりは難しい。それが大きなタスクであればなおさらだ。 タスクは細かく分けるほど正確な工数を見積もれるのだから、タスクを分けるのは重要なことだ。
個人的にはタスクは最大でも3日で終わるような規模にするべきだと考えている。
でないと自分の今持っているタスクを十分に見える化することができない。
例えば「実装」というタスクを振られたとして、その作業をどのように分けるべきか。
実装といってもコーディングして終わり、ではないだろう。コーディングが終わったら動作確認をしたり、
バグがあればまたコーディングに戻り、動作確認が終わればリポジトリにコミットして次はソースレビュー。
レビューで指摘を受けてまたコードを修正、動作確認、…という流れになるはず。
なのでタスクを分割すると以下のような感じ。
- コーディング
- ソースチェック
- 動作確認
- リポジトリにコミット
- ソースレビュー
- レビュー指摘箇所の修正
- 修正後の動作確認
- 修正後のソースコミット
- 修正後のソースレビュー
このように作業に分割すれば見積もりはしやすくなるだろう。
また、ソースレビューは自分の作業だけでは完結せず、レビューが行われるまでは待ちの状態になる。
その点も考慮してスケジュールを組まないと余裕を持って期限内に終わらない可能性が出てしまう。
タスクが十分に分割されていれば、正確に見積もりができ予定通りに作業を完了させられるように
なるのではないだろうか。
工数はフィボナッチ数列を使って見積もる
フィボナッチ数列とは1,1,2,3,5,〜と続く数列で、ある値はその前とその前の前の数を足し合わせた値になる。 フィボナッチ数列に登場する値を使うと相手に工数が伝わりやすくなるとのこと。 例えば
1人日：すぐに終わりそう
3人日：そこそこ時間かかるね
5人日：結構かかるな〜
8人日：え！かかりすぎじゃない！？
13人日：何かがおかしい
ポイントとしては5人日以上かかる想定であれば、そのタスクの見積もりは妥当ではないということ。
前の章でも述べたが、タスクは小さく区切るべきであり5人日かかるタスクというのはそもそもタスクの分割が
不十分である。従ってそのようなタスクがあれば、またタスクを分ける作業に戻るべきだろう。
また、1人日、3人日、5人日というような見積もりだけだとかなりざっくりしているが、さくっと相手に
作業時間を伝えることができる。
自分は見積もりに結構時間を使ってしまうタイプなので、この方法を活用して楽出来ればなーとか考えてます。
工数が分かるタスクで相対的に測る
あるタスクの作業量を伝える時、単純に何人日かかると言っても伝わりにくい場合は、
すでにある実績と比較して伝えるとわかりやすいらしい。
例えば、
「以前こういう作業にこれぐらい時間がかかり、今回の作業は誰々さんが実施するので〜倍の何時間かかります」
というような感じ。
この方法なら割と簡単に時間をかけずに工数を見積もれる気がしますね。
自分は実績をものさしにして見積もりをするということはしなかったですが、今後は実績はちゃんと計測して 将来の見積もりに役立てるようにしたいなー。
まとめ
ポイントとしては以下の通り。
1.細かくタスクを分ける
2.フィボナッチ数列でざっくり見積もる
3.タスクは他の作業と比べて相対的に測る
今回はPMとの飲み会でいい話が聞けたので、まとめてみた。
これらのポイントを抑えれば見積もりもきっと上手くなると思うので、これからはちょっと意識してみます。
