私が思う見積もりタスクのゴール
必要となる程度をあらかじめ予測して算出し、関係者になぜそうなのか具体的に説明できる状態。未経験のことであっても、なんとなくこれくらいではなく仮説立てて説明ができるかが大事だと思っています。
見積もりに対する心構え
「見積もり」が何のために使える情報か認識すること、ここが見積もり精度の質に関わってくる大事なポイントです。
計画を立てる前の超概算見積もりなのか、実装前の見積もりなのかで、どう「見積もり」を使うかは変わってきますが、下記用途で使用します。
- 今開発する/しないを判断する
- 誰をアサインするか決める
- どれくらいで全体の開発が終了しそうか把握する
- どのようなリスクがあるか把握し対策を立てる
見積もり精度アップのためにやっている3つのこと
- 対象を理解しやすい粒度にブレイクダウンする
- 見積もり変動リスクを洗い出す
- 予実を振り返る
対象を理解しやすい粒度にブレイクダウンする
いち見積もり対象の要素が多くならないようにする。要素が多くなればなるほど「ぬけもれ」や「対象への理解が浅くなる」確率が高くなり、見積もりがブレやすくなるからです。
具体イメージは下記のとおりです。
- 概算見積時は機能レベルまで落とす
- タスク作成時は部品レベルまで落とす
- まずはバックエンド・フロントエンドで分ける
- そこから1〜2日で終わらないタスクはさらに分割
見積もり変動リスクを洗い出す
機能を開発するにあたり、どういう変動リスクがあるか「内的要因」「外的要因」に分けて明確する。
- 内的要因一例
- スキル（例：使用したことがない言語/FWを使用）
- 知識不足（例：対象機能に関係する業務知識が乏しい）
- 経験不足（例：PJ参画したばかりでソースコード理解が浅い）
- 外的要因一例
- 関係者（例：仕様や運用調整に難航し、仕様変更の可能性がある）
変動リスクの工数をプラスし、どれくらいブレ幅がありそうか把握できるようにする。
ここで出した変動リスクは、それらを解消するタスクの作成や準備につながります。
予実を振り返る
やったらやりっぱなしではなく振り返る。
概算見積はブレが多く振り返っても学びが得づらいため、タスク作成時の見積もりを対象にします。
振り返るタイミングはタスクを完了するときで、あまり悩まずにパッと出たことをコメントに書きます。
振り返る内容は、
- 実際にかかった工数と見積もり工数の差分とその差分が生まれた原因
- 思ったより実装に手こずった部分
- 思ったより実装がすんなりいった部分
です。
まとめ
- 生み出す情報が何のために使える情報か認識するの大事
- 見積もり精度を上げるためやっていること
- 対象を理解しやすい粒度にブレイクダウンする
- 見積もり変動リスクを洗い出す
- 予実を振り返る