実装工数の見積もりの精度を高めるために

最近、長期間にわたる実装が多く、そのときに工数を見積もるの結構大変だったなと思ったのでそのときの振り返りも兼ねて書きます。

そもそも実装段階〜リリースするまでにやらなくはならないことは以下だと思います。

f:id:katsuyukikun:20170325112040p:plain

雑ですね・・笑。。。。まあ、いいか。

まずこのことは押さえておかないといけないなと思いました。

え？と思った方もいると思いますが、結構認識ずれます。

特にシステムに関与していない他のチーム、例えばセールスチームに共有するときなどはどこまでのフローのことを話しているのかというのをまず共有すべきだなと思います。

一旦定義を確定しておこうかなと思います。

個人的には

・見積もり・・・全タスクとその工数を洗い出すこと → 全体感、規模感を算出

・スケジュール・・・そのタスクにかかる時間を算出する

というイメージです。

ここから個人的に良かったなと思った進め方についてです。

見えていない部分はおいといて見えている部分でまずタスク分解する

やることは主に2つ。

・作るべきものをタスクに分解する

・次にタスクの工数を算出する

これができれば良いのですが、全然先が見えなかったりするものもあります。

そのときはこれをざっくりやります。今見えている部分だけでもよいのでやるイメージです。

例えば、Aという機能を実装するときに「Aを完了するには全体としてやることはa、b、cがあるんだけど、bに関してよくわからない部分が多くそれもa次第なんだよなー」となったときはとりあえずaだけは細かくタスク分解していきます。b、cに関してはざっくり今考えられることとしてこれくらいありますくらいでよいかなと思います。そして肌感で工数をふればよいかな程度です。

中間地点もしくは期間で区切って再度、見積もり直す期間をつくる

そして実際に行動に移していくのですがここでポイントがあります。それは見積もりをもう一度見直すタイミングを作ることです。

例であげたとおりb、cに関してざっくりとしか見積もってないので必然的にやることにはなるのですがそのタイミングはaのタスクを消化している途中です。一旦手を止めてでもやるべきだと思っています。

重要なのは「見えているor見える可能性があるならそこまで考えて、タスク分解してから手を動かしましょう」ということです。

仕事である以上、何をどのくらいの期間でやろうと思っているのかというのはすべてのチームへ説明する責任はあるのでそういった意味を含めてもやらないといけません！

ターニングポイントを意識する

あとは最後にスケジュールを作成するときに、スケジュールがどのくらい幅ができそうなのかとその幅のターニングポイントとなる場所を算出しておきましょ。スケジュールの幅というのは最短期間と最長期間との差のことです。そしてそのターニングポイントとはある意味でボトルネックといってもよいかもしれません。タスク分解すると「これらをこの期日までに最低やってないと間に合わなくない？ってことは今週はここまでがmustだよね、ってことはこれが延びた時点で見直したほうがよさそうなよね」という”これが”の部分です。