はじめに
- 非エンジニア職の新人が初めて管理を任された時の日報で「見積もりが!!」と言っていた
- ので、エンジニアとして見積もりをするときにどんなことに気をつけているかをまとめてみた
そもそも見積もりが必要な理由
計画を建てたいから
- いつまでに終わるのか、どの程度まで進むのかによってその後の進め方や他の人のタスクが変わる
- つまり見積もりが甘いと他の人に迷惑がかかる
先に不安要素を潰したいから
- 目標に対して見積もりが無理っぽいとわかった時点対処できる
- 不安要素は発見が早ければ早いほど取れる施策が増える
- つまり出来るだけ早い段階で見積もりが欲しい
正確に見積もるには
タスクを分解する
- 粒度を細かくしたほうが見積もりは簡単
タスク難易度・量を見積もる
- 難しい作業は時間がかかるし、量が多ければ当たり前
- これらを無視して作業ごとに固定にして考えると上手く見積もれない
- 時間の前にタスクの量や難易度を定量化してしまう
- ex.
- タスク量B = 1.5h
- 難易度A = 係数2.0
- 難易度A × タスク量B = 3.0h
- ex.
見積もりに対するKPTをする
- 見積もりを記録する
- 実際にかかった時間を記録する
- ズレがあれば何故かを考える
- 早かった時も遅かった時も原因が何か考える
- 「見積もりが甘い」で終わりがちだけど「何故見積もりが甘くなったのか」まで考えてみるといいかも
- 辛いので毎回はやらなくてもいいと思います
- 日報でやるといいと思います
バッファを設ける
- 必ずイレギュラーは発生するのでバッファを設ける
- 決め打ちでとりあえず1.2倍にしとくとかしてもいい
そもそも正確に見積もろうと思わない
- 見積もり時間に幅を持たせる
- 最良時間
- 超スムーズに進んだ場合の時間
- 最有力時間
- 大抵こうなるだろうなって時間
- 最悪時間
- 問題だらけで辛かった場合の時間
- 「確度何%でこの期日」みたいな言い方が出来るようになる
見積もり直す
- 途中までやって辛かったら見積もり直す
- 細かい粒度のタスクでやるとKPTの意味がなくなるので、大きい粒度でやろう
作業担当者が見積もる
- 一番詳細が見えているのは作業担当者
- 詳細を知らずに見積もると少なく見積もりがち
- 担当者が出してきた見積もりに対してレビューをしながら一緒に目標設定 = 見積もりをしよう