※予めお断りしておきますが、かなりネタエントリです
昔はそんな言葉じゃなかったけど、みんなどうやって作ればいいかわからなかった結果、アジャイル手法しかとりようがなかった。どうやって作るかが何となくわかりかけてきた時、ソフトウェア開発はシステム開発というビジネスになって、歪んだんだと思う。
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。
メソッド屋のブログ
「ソフトウェア」。ウォーターフォールってソフトウェア開発の手法なんだろうか。もちろんそうだ。でも、WFはソフトウェア開発の手法からいつの間にか工程ごとの契約管理の仕組みに変わってしまった。システム開発は巨額の投資だ。投資には確実な成果が必要で、確実な成果のためには確実な契約が必要だ。これは真実ではないんだけど、そう信じている人は多い。そこで一番しっくり来るのがWF型開発だ。何度も言うようだけど、これは開発手法ではない。もっと言うと、これが開発手法としてきっちりクリアされているのであれば僕たちは今より幾分幸せだ。実際の問題として、要件の出し漏れを前工程の検討漏れと言い張る人たちのせいで開発手法として成立していない。表面上WF型で開発しようが実際の現場としては単にやり方の不味いアジャイルになっていることも多い。全ては契約の問題だったりするのだ。そしてその契約は正しく履行されない。じゃあ何のために契約があるのってそりゃお金をやり取りするためだ。残念ながらそういうこと。
ということで、実際にはウォーターフォールとアジャイルというのは相反する2つの状態を指すのではなく、実はそれぞれ独立した思想である、とすら感じる。つまり、ウォーターフォールってのは巨大なシステム要件を実現するための「金」をひねり出すために必要とする手法にすぎない。結果としてウォーターフォールっぽいシステム開発を行っているようになるが、真のウォーターフォールは要件が完璧に可視化出来るレベルの小規模メンテ案件以外では実現不可能であるという評価は正しい。
もう一つ重要なこと。アジャイル開発であろうが、クソ要件とクソエンジニアで出来るのはクソシステムであるという現実に変化はない。逆に言うと、ウォーターフォールで工程を適切に巻き戻すことが許されるなら（それをウォーターフォールというかどうかはさておき）それはアジャイルである。
そもそもシステムが巨大であればあるほど、どんなに繰り返しのプロセスを踏んだところで完成間近に最初期に考慮漏れしていたたったひとつの問題からシステム全体が崩壊することだってあるのだ。アジャイルとて人の子。完璧ではない。
エンタープライズシステムの開発には正解なんて無い。失敗を繰り返したところで辿り着くのは失敗の海であり、必要なのはアプリケーションアーキテクチャをよく理解したエンジニアと、正しい業務要件である。業務要件 is GODであり、非機能要件は大地だ。ツールは人間の英知の結晶であり、大地に神のタネを撒けば自動でシステムが生長するべきだ。
それでも現実の問題として、システムは神ならぬ人の手により作られる。作りながらわかる間違いなど瑣末な問題にすぎない。ウォーターフォールが役に立つのは、そのシステムの実現が如何に困難なものなのかという事実を可視化することなのだ。
