はじめに
私は、未経験から入社して2ヶ月のエンジニアです。
今回は、そんな初心者エンジニアが研修課題を進めていくに当たって学んだ、工数見積もりについてお伝えしていきます。
経緯
この記事は、私の失敗談に基づきます。
私は研修課題のスケジュール管理にガントチャートを用いていたのですが、具体的工程やそれぞれの難易度など何も分からない私は、「このタスクはこんくらいかかるかな〜」と 完全に感覚で、無根拠に 工数見積もりを行っていました。
そのため遅延が発生し、更にその際のリスケジュールまで感覚で行ったために更なる遅延が発生し...というループに陥ってしまい、見兼ねた上司に見積もり方法を教わることで、やっと無理のないスケジュールを組むことができました。
以下では、その方法と効果、参考として調べた他の見積もり方法を記しています。私のような初心者エンジニアの糧になれば幸いです。
問題点
そもそも、なぜ遅延を繰り返してしまったのでしょうか。
1. 各タスクが大きすぎた
起票していたタスクの粒度が大きすぎました。
どのようなことをやっていくのか、が見えていないと見積もることはできません。
粒度が大きすぎると詳細な工程が見えて来ないため、精度の高い見積もりを実現できませんでした。
2. 工数を感覚で測っていた
「多分このくらい」で工数を決めていました。
経験者ならこれでカバーできる割合も多いでしょうが、ほぼ全ての工程が未経験である私の感覚が、あてになるはずもありません。
3. スケジュールに余裕がなかった
1日の稼働時間と工数を、完全に等しく設定していました。
実際には思うようにいかないのが常であり、アクシデントの想定が不足していました。
見積もり方法
以上の問題点を解消する方法です。
a. タスクの細分化
「1. 各タスクが大きすぎた」に対するアクションです。
タスクの粒度を細かくしていきます。それぞれのタスクの実装過程を追っていき、ある程度の単位で書き出していきます。上司からは、2時間で終わるタスクに分割するのがよいと言われました。
ただ、この時点で分割を行っても、依然として感覚に依存しているだけです。過程を追うのは想像でしかありません。以下の②の工程を踏むまでは、あくまで仮分割として行います。
b. 着手してかかった時間 / 完了率
「2. 工数を感覚で測っていた」に対するアクションです。
いよいよ、感覚ではなく論理に基づいて見積もりをする段階です。
仮分割した各タスクを、少し齧ってみます。最後まで見通しが立った段階で止め、それまでにかかった時間 / そのタスクの完了率を計算すれば、全体の工数が分かります（30分で全体の2/5が終わったなら、30 / (2/5) = 75分かかる）。
このとき、仮分割した1タスクが実は2時間で終わらないものだったと分かったなら、更に細分化する必要があります。
着手することにより、見積もりの段階で実装の方針が立つので、開発前に全体像を把握できることもメリットです。
c. バッファを設けて起票
「3. スケジュールに余裕がなかった」に対するアクションです。
工数見積もりが終了したら起票しますが、この際、稼働時間と工数を完全に対応させるのは望ましくないです。見積もりはあくまで見積もりであり、全てのタスクがその通りに終わるわけではありません。そのため、稼働時間に対して少なめのタスクを充てるべきです。
私は上司から、（mtgなどを除いて）1日6.5h稼働として、2-3タスク（= 4~6h分）を充てるよう助言を受けました。
効果
先述の通り見積もりはあくまで見積もりであり、その通りに事が進むわけではありません。それでは、見積もりを行う効果はどこにあるのでしょうか。
報告・管理のしやすさ
1タスク2時間と決まっているので、見積もりに対するその日の進捗を報告しやすくなりました。報告を受ける側からしても、管理しやすいのではないかと思います。
私はまだ社内のテクニカルディレクターとコミュニケーションを取る機会はないですが、そういった方々や、営業、ひいては顧客への報告にも役立つことでしょう。
不安の解消
個人的には、この点が最も大きかったです。
入社初のタスクということもあり、「これ、いつ終わるんだろう」と毎日不安な気持ちで退社していました。見積もり後は、終わりが明確に見えたことで現状の到達割合が可視化され、毎日の進捗に実感を持つことができました。
その他の見積もりの方法
今回行ったのはボトムアップ見積もり法と言うようです。
他にも見積もりの方法があるのではと気になったので、調べてみました。
類推法
- 過去の類似プロジェクトの工数を参照して、現在のプロジェクトに応用する
- ただし、機能要件や性能が異なる部分は経験や勘頼りになってしまう
3点見積もり法
- 楽観値・最可能値・悲観値の3点から見積もる
- 楽観値 / 悲観値：円滑に進んだ / 進まなかった場合の工数
- 最可能値：実際に必要とされる現実的な工数
-
(楽観値 + 4×最頻値 + 悲観値) / 6で計算する
おわりに
正しい見積もりの方法が分かったとはいえ、経験や知識不足から、精度がまだ追いついていない状態です。
今後繰り返す中で徐々に精度を向上させ、自分は安心して開発を進められる、かつ上司などの管理者は私の進捗を正確に把握できるような、見積もりを目指します。
最後まで読んでいただきありがとうございました。
参考