フリーランスの@linyclarです。
今更ながらリーン・スタートアップを読んで気づいたことがあったので共有します。
MVPとインクリメントを区別する
スタートアップで仮説検証のためにMVP（実用最小限の製品）を構築しているフェーズで
「とにかくコードを書け！ どうせ一月立たずに捨てられるから設計なんて無駄だ！」
のような発言は出てきがちで、なまじ正しいのでタチが悪いといえます。
実際、向かうべき方向を定めることが重要であり、そのためにコードは振り回され設計作業は無駄になります。
正しいのでこの方針で突き進んでしまい、事業が成功した段階で技術的負債に頭を抱えることになります。
Cynefinフレームワークの複雑系プロジェクトの典型的なシナリオでしょう。
この典型的なシナリオに陥る原因は、機能追加の理由が「仮説検証や学習のため」から「ビジネス価値のインクリメントのため」にシフトしているのにやり方を変えないことにあります。
ビジネス価値のインクリメントのために機能追加することが多くなってきたなら、コードが捨てられることがなくなったということであり、設計をするべき時がきたことを意味します。
なので、ビジネスサイドやプロダクトオーナーと一緒に「このストーリーはMVPなのかインクリメントなのか」確認して、MVPなら捨てるかいずれ再実装することになると伝えておいた方がいいでしょう。
複雑系なら顧客に、煩雑系ならプロダクトオーナーにMVPを提供する
複雑系プロジェクトの場合、ビジネスサイドやプロダクトオーナーにも正解はわからないため、MVPを実装して実験と検証を繰り返すしかありません。
煩雑系プロジェクトの場合、ビジネスサイドやプロダクトオーナーあるいは専門家が分析すれば正解はわかります。
言い方を変えると、答え合わせが複雑系プロジェクトではプロジェクトの外で行われるが、煩雑系プロジェクトならプロジェクトの中で完結するともいえます。
もし、煩雑系プロジェクトで頻繁にコードを捨てるようなことをしているなら、実装しないMVPをプロダクトオーナーに提供することでコストを減らせるかもしれません。
例えば、Dropboxはプログラムを作る前にデモ動画を作って見込み顧客が存在するのか確認したそうです。
同じように、画面イメージとか動作イメージ図をプロダクトオーナーに提供し正しい方向か確認するわけです。
作り込む前に方向修正するわけなので、実装コストは最小限になり技術的負債も発生しません。
優秀なプロダクトオーナーがいて適切にバックログリファインメントを行っていれば必要のないことですが、分析が苦手なプロダクトオーナーの場合には有効でしょう。
ただ、「仕様書を書いている！（アジャイルじゃない！）」と追及されるかもしれないので、方向性確認のためだと共有しておいた方が良いかもしれません。