柔軟なウォーターフォールはアジャイルと見分けがつかない

2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイルと全体最適について　～アーキテクチャ設計とウォーターフォールの必要性～』のレポートです。資料は以下。

講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。

資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも（まともなプロジェクトであれば）実質的なオペレーションは似通ったものになるというのです。

確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはどこか、作って試すべきはどこか」という問いが重要になります。

最近の案件でも「アジャイル開発でやりたい」と言われたところで、結局、リリース日や必須機能が決まっていれば、アーキテクチャ設計を入念にやって、確度が上がったら長めなバックログを作って、中期のマイルストーンを決めて、他システムを巻き込むテスト計画を立てて、となってきて「あれ、これウォーターフォールじゃね？」ということがあります。ただ、もちろんのことながら、必要なだけのプロトタイミングやオンサイトやペアプロやオンライン情報共有や自動化や、様々ないわゆるアジャイルなプラクティスはやればいいだけです。

よって、「十分に柔軟なウォーターフォールはアジャイルと見分けがつかない」というか「十分に計画的なアジャイルはウォーターフォールと見分けがつかない」わけです。こうなってくると、たしかに呼び方だけの問題かもしれません。

喩え話的に「COBOLからJavaが主流になった瞬間、もはやCOBOLで作ろうなんて誰も思わないけど、実際にはCOBOL的なJavaはあったし」というのが引き合いに出たのですが、つまり「ソフトウェア開発といえばアジャイルプロセス」というのが「常識」となった瞬間に「ウォーターフォールはアジャイルの亜種」になるのではないか、というのです。言語と開発プロセスを並べるのは簡単ではありませんが、言いたいことは良く分かります。

僕も「アジャイルを目的にした開発は嫌い」ということは言ってきたのですが、世の中の認識が「普通、アジャイルでしょ」となってきているのであれば「ウォーターフォール的な要素も残そうよ」という言い方にしていってもよいかもしれません。とはいえ、エンプラ系の講演で「もう普通はアジャイルですよね？」とかいうとぽかーんとされそうですが...。

なお、資料の方はプロセスとして「ウォータフォールとアジャイル」、アーキテクチャとして「SOAとMSA」と対比させ、現在は後者を主流としながらも、どちらも必要な要素であることをお話させていただきました。どちらも「トップダウンとボトムアップ」の対比として考えることができますよね。

（SOAとMSAの比較も盛り上がりましたが、それはまた別の機会にでも書きます）