工数見積もりの限界

• 初期コンセプト（≒要求定義フェーズ）での見積もりは、実際にかかる工数に対して4倍〜0.25倍のブレが存在する。（不確実性コーン）

• 1ヶ月と見積もったものが4ヶ月かかるかもしれないし、1週間で終わるかもしれないということ。

  • 意味のある見積もりか？

  • この段階で精度を高めることはできない。

• 一度決めたリリース期日厳守なのであれば開発としてはバッファを積むしかない。

• しかし、そうしたいわけではないはず。

• 正確さを求めるなら設計フェーズでの見積もりを出す必要がある。

リスクの存在

• 全てを予測、計画することは不可能である。

• プロダクトは作って動かしてみて初めてわかることもある。

• 作っていく過程でわかることがある。

• 要求が不足していたり、考慮漏れがあったり、パフォーマンスが思ったように出なかったりする。

リリース予測の立て方

• 見積もったストーリーポイント（相対見積もり）に対してベロシティ（過去実績）を使って予測する

• ただし、わかるのは似たような機能開発の場合のみ

  • プラモデルの車を組み立てるのと、実際に車を組み立てるのでは違う

何のために見積もるのか？

• コスト感を知り、優先順序付けに用いたい

• ロードマップを引きたい

• リリース日に合わせてプレスリリースなどのアクションを取りたい

ロードマップ

• ロードマップとは何か？

• リリース期日か？

• リリース期日で引きたいなら、全ての案件に対して設計まで終わらせる必要がある。

  • でなければ何の意味もなさないロードマップが出来上がるだけである。

• ロードマップで本当に欲しいのは何か？

  • ロードマップに機能を書くべからず

• 本当に成し遂げたいことはリリースではなく、その先のアウトカムなり売上のはず。

• 機能はそれらを実現するためのHOWに過ぎない。

• HOWを固定してはいけない。

  • 機能をリリースしたがアウトカム、売上は得られなかったとしてそれで良いのか？

  • HOWを固定するということはHOWが実現されればそれでOKということである。