若手エンジニアが学んだ工数見積もり方法

ディップ Advent Calendar 2019の20日目です。

はじめに

こんにちは、ディップ株式会社に2018年新卒で入社し、求人系サービスの開発や社内向けツールの開発を行なっている@taku-0728です。
今回は私が先輩から教わった工数見積もり方法について書きたいと思います。
知っている人からすれば当たり前だろと思われるかもしれませんが、同じように工数見積もりについて悩んでいる方の参考になればと思います。
よろしくお願いいたします。

背景

まずはじめに言っておきますが私は「工数見積もりが大の苦手」です。基本的に考えるより先に行動したいタイプなので、「いつくらいにできそう？」と聞かれても「やってみないとわかんないじゃん」と思うタイプの人間です。（もちろん答えるときは◯日くらいですとちゃんと答えますが。）
そのため、自分でスケジュールを引く際には内容を軽く把握して ある程度感覚でスケジュールを引いていました。

問題点

「感覚でスケジュールを引く」ことは知識と実務経験が豊富なベテランエンジニアであれば問題ないと思います。しかし、経験も知識も未知数な若手エンジニアにとっては相当難しいと思います。最初に引いたスケジュールから思うようにいかなかったにも関わらずギリギリまでなんとかしようとして報告が遅くなり、結果的に先輩や上司を困らせた経験がある方はいるのではないでしょうか？(私はその一人です。)
「先輩や上司への報告がギリギリのためスケジュールの遅延を早い段階で検知できず、適切な対応を取れない」ことが一番の問題点であると思います。

なぜ思うように進まないのか

最初に自分で「これくらいかかるだろう」と考えたのになぜ思った通りに進まないのでしょうか？
原因はいくつかあると思いますが「そもそも見積もる粒度が大きすぎる」というのが1つ考えられると思います。
たとえばあるタスクについて設計からテストまでの工数を出して欲しいと言われた際、

• 設計：◯人日
• コーディング：◯人日
• テスト：◯人日

のように各工程ごとでしか見積もりを行わないことはあると思います。
このような見積もりだと

• 担当したタスクが想定より難しかった
• 緊急度の高いタスクによって必要な工数が確保できなかった

など、よくある問題がそのままスケジュールの遅延に繋がりがちです。
その遅延をすぐ報告せずギリギリまでなんとかしようとして上司・先輩にアラートをあげるタイミングが遅くなってしまうのではないでしょうか。
例えばコーディングに3人日かかると見積もります。はじめの1日で予想以上に詰まり初日で全体の20%しか進んでなかった場合、すでに10%程度遅れているにも関わらず「あと2日あるからなんとかなるか」と考えてしまいがちです。（夏休みの宿題でありがちなやつですね）ただ、そうなると遅延を取り返そうと残りの2日間でものすごく残業したり、最悪の場合ギリギリになって「やっぱり無理でした」と報告することになってしまいます。

解決策

どうすればスケジュールの遅延を早い段階で検知し、適切な対応が取れるのでしょうか？
当たり前ではありますが、「タスクをより細分化して工数を見積もる」ことを教わりました。

細分化って？

とはいえ細分化と言われても何を持って分割すればいいのかわからないと思います。
自分が教わった定義は「1つのタスクが3時間以下になるまで細分化」することです。
例えばコーディングに3人日かかるさっきの例で考えます。

• コーディング：24時間(8時間×3人日)
  • タスクA：10時間
    • タスクA-1：3時間
    • タスクA-2：2時間
    • タスクA-3：2時間
    • タスクA-4：3時間
  • タスクB：8時間
    • タスクB-1：3時間
    • タスクB-2：3時間
    • タスクB-3：2時間
  • タスクC：6時間
    • タスクC-1：3時間
    • タスクC-2：3時間

コーディングという1つの大タスクが3つの中タスク、9つの小タスクにそれぞれ細分化されました。
これによってもしタスクA-1に詰まって5時間かかってしまった場合、タスクA自体が2時間遅れていること、それによってタスクB、タスクCの開始時間も遅れる可能性があることに気づけます。自分の見積もりより遅れそうだなと思ったタイミングで先輩や上司に報告、相談することで周りも遅延を早い段階で把握でき、適切な対応を取れるのではないかと思います。

結果

タスクの見積もり方法を工夫してみて約1ヶ月経ちましたが、当初想定していなかった効果もいくつかありました。

自分の見積もりに自信がもてる

今まで感覚値で見積もっていたものを細分化して見積もることによって自信が持てるようになりました。
マネージャーたちに「このスケジュールで大丈夫？」と聞かれた時に「各タスクにこれくらいの時間がかかりそうです。その結果全体としては◯日くらいかかります。」と根拠を持った説明ができるようになりました。

バッファが考えやすい

実工数に対してバッファをどれくらい持つべきか悩んでいましたが、今は1日4~6時間で見積もるようにしています。実際の業務時間は1日8時間ですが、毎日8時間全てを自分のタスクに使えるわけではないので1日あたり4~6時間を工数として見積もり、残りの時間はバッファとして考えるようにしています。

これから

工数見積もりについて書かせてもらいましたが、正直言って「見積もり上の工数と実際にかかった工数が全く同じになる」ことは不可能だと思っています。しかしながら見積もりと実績値の差を限りなく減らすことはできると思うので、各タスクが終了した後に見積もりと実際の工数を比べてなぜ差があったのかを振り返り、次の見積もりに活かすというサイクルを意識しています。このサイクルを繰り返すことで見積もりと実績値の差を限りなく減らすことができるようになると考えています。
また、今自分のチームの他の若手メンバーにも同じ方法で工数を出してもらっています。
他のメンバーの意見も取り入れながらやり方は都度変えていくつもりです。

まとめ

若手エンジニアが先輩から教わった工数見積もり方法について話をさせていただきました。
あくまでも一例であり、もっといい方法はたくさんあると思うので、参考程度にとらえていただければと思います。
意見や不明点等あれば気軽にコメントしていただければと思います。
最後までお付き合いいただきありがとうございました。