私が思う見積もりタスクのゴール

必要となる程度をあらかじめ予測して算出し、関係者になぜそうなのか具体的に説明できる状態。未経験のことであっても、なんとなくこれくらいではなく仮説立てて説明ができるかが大事だと思っています。

見積もりに対する心構え

「見積もり」が何のために使える情報か認識すること、ここが見積もり精度の質に関わってくる大事なポイントです。
計画を立てる前の超概算見積もりなのか、実装前の見積もりなのかで、どう「見積もり」を使うかは変わってきますが、下記用途で使用します。

いち見積もり対象の要素が多くならないようにする。要素が多くなればなるほど「ぬけもれ」や「対象への理解が浅くなる」確率が高くなり、見積もりがブレやすくなるからです。

具体イメージは下記のとおりです。

機能を開発するにあたり、どういう変動リスクがあるか「内的要因」「外的要因」に分けて明確する。

内的要因一例
- スキル（例：使用したことがない言語/FWを使用）
- 知識不足（例：対象機能に関係する業務知識が乏しい）
- 経験不足（例：PJ参画したばかりでソースコード理解が浅い）
外的要因一例
- 関係者（例：仕様や運用調整に難航し、仕様変更の可能性がある）

変動リスクの工数をプラスし、どれくらいブレ幅がありそうか把握できるようにする。
ここで出した変動リスクは、それらを解消するタスクの作成や準備につながります。

やったらやりっぱなしではなく振り返る。

概算見積はブレが多く振り返っても学びが得づらいため、タスク作成時の見積もりを対象にします。

振り返るタイミングはタスクを完了するときで、あまり悩まずにパッと出たことをコメントに書きます。

振り返る内容は、