締め切りと見積もり誤差
MVPの解説の図を見て、個人的には発表会や成果報告会のような動かせないデッドラインが存在するケースによく当てはまるように感じた。
締め切りに一番右の形になるつもりで開発してて、開発にかかる時間が予定よりちょっと多くかかった場合
- 下はまあまあ
- 上は酷い タスクの実装コストを事前に正確に見積もることはできないので、揺らぎを見越して早めに「発表会で発表できる形」にする必要がある。 #見積もり #不確実性
この図の、下のフローの方がステップ数が多いことには意味がある。 総工数を考えると下の方が余計なものを作ってる時間がある分、効率が悪い。 それでも、一見効率的な上の開発プロセスより非効率な下のプロセスの方が良い、この逆説が面白いポイント。
例えば1ステップに10日掛かる見積りだとする。発表会は40日後にあるとする。
- 上のプランは「1ステップ10日を4ステップすると完成して100点になる。それまでは0点」
- 下のプランは「1ステップ10日を5ステップで100点になる。それまでは20点ずつ上がる」 下のプランの方が工数が20%多い。つまり開発が非効率。
見積りが正確なら
- 上のプランは成果報告会で完璧な100点のデモをできる。
- 下のプランでは間に合わなくて80点のデモになる。
しかし、現実には見積もりは正確ではない。仮に見積もりが1ステップにつきプラスマイナス1日ずれるとしよう。
- 上のプランでは50%の確率で完成が間に合わず0点になるので、0点と100点の平均で50点。
- 下のプランは50%の確率でステップ4が間に合わなくて60点と80点の平均で70点。 下のプランの方が非効率であるにもかかわらず、下のプランの方が発表会での評価は平均的に高い。
この「締め切りと見積もり誤差」の話とは独立に「『顧客はこういうものが欲しいに違いない』は仮説なので、なるべく早く『顧客に見せられる形』(MVP)を作って、実際に顧客に見せて、顧客ニーズの存在を検証する必要がある」という考え方もあって、それがいわゆるリーンの思想だね。