ウォーターフォール型開発が近年の新規事業開発にあってないと思う理由

・ウォーターフォール型がフレームワークベースの開発に合っていない
　①ウォーターフォール型は大規模開発には向いてる(仕様を前もって決めておけば全体が都度協調しなくてもOKなので)んだが、フレームワークの恩恵のおかげで少人数チームでもアプリケーション開発ができるようになったので、少なくともチームが小さいうちはこのメリットは受け取れない。
　②フレームワークベースの開発の特徴として、フレームワークが想定しているものは作りやすい反面、想定外のものは非常に作りにくいし、変更もしにくくなる。
　作るべきものがフレームワークによって想定されているかどうかを考えずに仕様を決めてしまうのは論外で、さらにこのことを考慮に入れて仕様を設計したとしても、作っているうちに、これってこのやり方だとやりやすいよねとかやりにくいよねとかが出てくるので、ウォーターフォールで遡ることが不可能だと、そういうタイミングでの改善の芽が摘まれてしまう。なので、その程度の仕様のブレを許容するような設計指針だとこれもクリアできる。これがユーザーストーリーみたいな抽象的な設計を採用する理由になる。

・ウォーターフォール型が新規事業開発（スタートアップチーム）に合っていない
　①スタートアップでは常にいいプログラマーを雇えるわけではないので未熟なプログラマーを前提として考えないとだめなんだけど、ウォーターフォールの後戻りのない仕様設計って使うフレームワークとかに精通している前提なので、プログラマーのプロジェクト中のレベルアップによる仕様とか作りとかの改善効果をうまく取り込めないウォーターフォールは合ってない。
　②スタートアップのように少人数で開発運用をしていくことを考えると、技術的負債を日々解消していかないと続かなくなってしまうんだけど、バッチサイズが大きいので日々の改善が効かなくなりがち。

書いてて思ったけど、ウォーターフォール型をやり玉に上げて（アンチパターンで）考えをまとめたかったんだけど、そもそもアンチウォーターフォールが理想的なものになるわけではないので、この書き方だと限界がある。
つまりアンチウォーターフォールは書けるんだけど、新規事業ベストプラクティスに辿り着けるわけではないので、前提を置かない新規事業ベストプラクティスも後日別途書くことにする。