従来のウォーターフォール型開発は、もう無理がきているのではないでしょうか。要件定義、基本設計、詳細設計、プログラミング、テスト、本番稼動という流れの各フェーズにおいて成果物として「ドキュメント」を残し、次工程は、そのドキュメントを元に進められるというのは、「ドキュメントが正しいことが前提」です。しかしながら、現実には１００％正しいドキュメントは皆無であり、この結果、やり直し、作り直し、泥沼の人海戦術、赤字・失敗プロジェクトが多発しています。
であれば、もうウォーターフォール型開発は止めましょう。では、どうするのか？ 早期に、ドキュメントの代わりに動くものを作ればいいんです。（これを仮に実行ファースト型開発と名付けましょう。テストファーストではありません） 動くものを触ってテストできれば、ドキュメントのレビューなんかより、よっぽど効率的ですし品質も高いものができます。エンドユーザさんから見ても実感をもってテストできるため、「こんなはずじゃなかった！」ということが激減します。
ソフトウェア業界も、この点には気が付いているはずです。では何故未だにウォーターフォール型開発を続けているのでしょうか？ それには、すぐに変えることが出来ない事情があるんです。ウォーターフォール型開発なら、各フェーズで納品、請求することも出来ますよね。ところが、本来お客様にとってメリットのある実行ファースト型開発では、それがしづらいんです。もしするとしたら、機能単位とかサブシステム単位とかで、どこまで出来たら何千万円とかの契約にしないとなりません。これも実際には難しいです。また、協力会社（実際には下請けイメージが強い）に開発を依頼することも難しくなります。なにぶん、きちんとした設計書が無いのですから。
実行ファースト型開発はスパイラル型開発となるため、「作って見せて直してテスト」を繰り返すことになります。このため、なかなか収拾がつかなくなると心配する人がいます。しかしウォーターフォール型開発の最後で大幅変更を要求されるより、よっぽど良いのではないでしょうか？
実行ファースト型開発の具体的手法を策定中です。希望される方（但し法人に限るため社名を明記）にはドラフト版を差し上げますのでコメントorトラックバック下さい。
つづく