最近、物忘れが激しくなってきて、具体的なことを思い出すのに時間がかかる（笑）
なので、具体的なことをメモっておく。
前提の考え方
規模によって、正確性が大きく変わる
規模が大きくなれば、正確に見積もるというのは、困難。
ただ、適当過ぎるのもダメ。
なので、考え過ぎず、考えなさすぎず、がポイント。
注意点
- 見積もる機能とフェーズに漏れが無いか？
要するに、工数が大きく変わる要素に漏れが無いか？ - バッファは、機能ごと、フェーズごとにバッファを盛らず、最後にバッファを考える
何故かと言うと、WBSを引く際に楽になります。
基本、実工数で線を引いて、バッファをXX人日分、載せる等調整がし易くなります。 - 工数の理由を大切に。
見積は、個人の主観になりがちなので、必ず第三者に見て貰う必要があります。
その際に理由を説明できるようにしておくのが大切です。
後は、お客さんにも説明しますので。 - 見積り前提を忘れずに。見積りしていない機能は、やらないが当たり前と思いますがら、明確にこの機能はやりませんと。書くことが大切。何故なら、お客さんも、忘れていて、あ！ってなり、再見積もりとかも発生するので（笑）
やる事
規模が大きい（数十の画面、バッチ、APIとかがある）場合
なんちゃって、FP法になりますが、
- 見積もる機能の洗い出し
- 見積もるフェーズの洗い出し
- 機能ごとに、難易度（簡単、普通、難しい）を決める。
- 決める際には、簡単な理由、難しい理由をメモっておく。
- 一通り難易度を決めたら、最初と最後で、難易度の先入観が変わってる可能性があるため、一通り再度見直す。
- 「簡単には割り振った機能」を見て、「簡単は、何人日」、「普通は、何人日」、「難しいは、何人日」と決めて、工数を弾いていきます。
- バッファで諸々調整します。
で、最後に、見積レビューをして他者の意見を貰って、調整という感じですかね。
規模が小さい（1個か、2個のバッチ、画面、APIとかの改修）場合
- 要件定義、基本設計、実装、単体、結合、システムテストで、細かに見積もる。
- バッファで諸々調整します。
で、最後に、見積レビューをして他者の意見を貰って、調整という感じですかね。
現場によりますが
上記で出して、過去の類似工数があればそれと比較し、バッファを調整します。
過去との比較で注意すること
メンバーによって、大きく工数が変わります。
なので、その当時のメンバーがどうだったのか？を改めて思い起こしつつ、比較する必要があります。
駄文
意外と記事を書いてみると、詰まります。
あれ？これどうしてたっけ？とか。
言語化することは、本当に大切ですね。