リーンスタートアップ：なぜ作る前にコンセプトを実証するのが良いか

リーンスタートアップでは出来るだけ実装せず、必要最小限のものでコンセプトを実証するのが良いとされる。

スタートアップのシステム開発の場面で考えるとすごく賛成で、これは見事に逆をやってしまった失敗経験に裏打ちされている。

具体的には内部で仕様を決めて、必要最低限など気にせずに必要と内部で判断したものはどんどん実装していっていた。

なぜこれが問題になるかというと、

①コンセプトの実証の必要性、フィードバック受ける必要性がない、というのが社内の、チーム内の風潮になってしまう：

積極的にフィードバック受けるというのはユーザが増えてくればいろいろ楽になってくるんだけど、初期ではわりと手間がかかる（としてもやったほうがいいんだけど）というのもあって、状況として「売れないね」「ユーザ増えないね」ってなったときに、このチームに出てくる発想として

「あ、あの機能がないから売れないのか」

になってしまう（あの機能あれば売れる病）。出発点が売れそうな機能を仮定して、最小限とか気にせずに作るというところから始まっているので、このタイミングでも時間がかかっても新規機能をがっつり実装し、リリースした後、また「売れないね」、になる。

②この頃になると、何か必要で何が不要な機能なのかというのが社内で合意がとれなくなってくる（根拠となるフィードバックがとれないので）

特に、大きなバッチサイズで、1リリースあたりにたくさん機能詰め込んでるんで、ユーザが増えたとしても何に反応しているのかよくわからないまま。

こうなると、唯一の拠り所となるのはチーム内で地位がある人のゴリ押しだけになり、周りのメンバーは冷め始め、チームがギスギスし始める

③仕様先行型でつくってしまっているので、複雑化リスクと機能追加を天秤にかけるとかやってない。リリースが3周くらいしたところで、システムが超複雑化してしまっていて、メンテナンスコストが膨れ上がり、最初は気軽にできていた新規機能追加もままならなくなり、行き詰まる。

というような負のスパイラルをシステマチックに避けられるという意味で、よく考えられたフレームワークだと思う。