開発フロー設計

「何を作るべきか」を実際にUIに触れて考えれば良い。

チーム/顧客との間のアプリイメージを効率的にすり合わせられる。

従来のウォーターフォールモデルにおいては動くアプリ、画面の完成が要件定義より（最悪一年）遅れていた。 不完全であっても動くものをさっさと作ることで、作るべきでないものを作っている場合、早く気が付ける。

ソース編集中にシンタックスエラーに気が付くことができる。

古い言語や開発環境においてはビルドするまでエラーに気が付けないことが多々あり、 作るべきソースコードが長い場合などは最悪１週間以上発見が遅れることがある。 致命的な設計ミスなどにも気が付くことが出来ず開発効率と品質低下の要因となる可能性がある。

ソース変更時に自動で差分コンパイルを行い、アプリを再起動＆ブラウザからアクセスし確認できる。

現在のソースがどの様なアプリに対応しているか即座にフィードバックされる。

挙動にエラー/想定外がある場合早期に発見することができる。

例：ExcelでERDを作成しそれとは別にDDLやスキーマファイルを記載するといったケースが考えられるが、 仮にこれに変更を加える場合同期するための編集コストを要してしまう。

コードであるスキーマやDDLを管理の基本とし、チーム内もしくは顧客向けの説明資料として図が必要なのであれば、 都度自動で生成されるようにしておけばよい。

他のチームメンバーを待たなければ開発が行えない状況にしないことで、即時のフィードバックを得ることができる。

モックやドライバを用いて最低限の確認やテストを行うことは可能だが、 「何を作るべきか」のフィードバックとしては不十分になりやすく、 またいずれにも跨った変更にコミュニケーションコストが生じる。