tl;dr
ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？
空想上の開発手法ウォーターフォールと進化したウォーターフォール
アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。
それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。
もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。
- 一ヶ月で１ウォーターフォールを回す
- 前の手順に戻る手続きが定められている
- 初期フェーズから開発者を巻き込む
- 定期的なレビューに顧客を呼んでいる
あれ？それって、立派なアジャイル開発なのでは？
アジャイルとウォーターフォールの断絶
そういう人たちからしたら、ウォーターフォール=悪だということを前提とした論調を快く思わないのは当然です。だから、彼らは、自分たちの開発をアジャイル開発呼ばわりされることを良しとしません。アジャイルを目の敵としてウォーターフォールに矜持を持って取り組んでいる人たちもいます。そりゃ散々迫害をされてきたのだから当然です。
そういう人達のアジャイル批判には「設計軽視で適当なものづくりをしている奴ら」といった感情が垣間見えます。それも誤解ですが、そういう感情的な対立が起きやすくなってしまっている。そして、彼らには自分たちは初期設計をちゃんとやっているという矜持があり、実際にそうなのでしょう。
実際、アジャイルに開発しようとして、早く出そうとしすぎて品質がおろそかになったり、作り過ぎのビルドトラップに陥る話もよく聞かれるようになりました。それと同時に、設計の重要性が見直され、話題になることも増えてきました。設計ノウハウを持っている人たちから学べるものも多くあるはずです。
アジャイル開発とは価値観
そもそも、アジャイル開発とは価値観であり、特定の開発工程や方法論のことを指しません。その価値観を共有する開発がアジャイルソフトウェア開発であり、方法論は何でも良いのです。
アジャイル宣言及びアジャイル宣言の背後にある原則が全てです。
原則の冒頭は以下の文で始まっています。
顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。
ビジネスとして当たり前のことです。現代のソフトウェア開発は、すべてアジャイル開発を志向すべきです。アジャイルかそうじゃないかという二項対立的な話はナンセンスで、よりアジャイルに進めるためにはどうすればいいかと常に問い続け、改善し続けることが重要です。
開発工程や方法論については何も書かれていません。何ならアジャイル宣言では以下のように謳われています。
プロセスやツールよりも個人と対話を
プロセスやツールも大事ですが、過度にこだわる姿勢はアジャイルとは言えません。
ウォーターフォールは開発手法
アジャイルとウォーターフォールを対比させることのおかしな点は、前項で書いた通りアジャイルは価値観ですが、ウォーターフォールは開発手法(プロセス)であるということです。直交概念であり、比較レイヤが誤っています。
開発手法の話をするのであれば、アジャイル開発の代表的な開発手法であるスクラムと比較をするのであればまだわかります。そして、アジャイルに進められているウォーターフォールの現場もあるし、全然アジャイルに進められていない硬直化したスクラム(もどき)の現場もあります。
「スクラムなんて結局高速ウォーターフォールでしょ？」という意見を聞くこともありますし、あながち間違ってないとも思います。
アジャイルに開発したいという思いは変わらないはず
開発手法をカイゼンしている人たちの間に断絶があるのは悲しいことです。お互い学び合うことはできるはずです。アジャイルという言葉や文化圏に嫌悪感を抱いている人もいるでしょう。でも、お互いの目線は実は変わらないのではないでしょうか。本来的な意味でのアジャイル開発をしたいのです。
だからウォーターフォールを馬鹿にするのはやめましょう。矜持を持ってウォーターフォールに取り組んでいる人たちもいます。それは、良くイメージされるウォーターフォールとは異なるものです。
なにかの概念を説明するために対立概念を作って二項対立的に説明するのは、説明能力に乏しい証拠です。もちろん人間の理解力の問題で、便宜上でも対立概念を作ることで理解が早くなるという現実もあります。その結果として、アジャイルの対立概念としてウォーターフォールという言葉がよく使われる様になり、雑な説明が乱立することになりました。残念なことです。
アジャイル開発とスクラム
余談気味になりますが、ウォーターフォールとアジャイルが比較されがちな別の要因に、アジャイルとスクラムが同一視されがちというのもあるように思います。開発手法のウォーターフォールとスクラムを比較しているが、スクラムのことをアジャイル開発と呼んでしまっている、そういうケースです。
これは、振り返り(レトロスペクティブ)= KPTと時に勘違いされてしまうように、スクラムがそれくらい代表的なアジャイル開発手法になったということでもあるとは思います。
ただ、ここは正しい理解しておくに越したことはないですし、大まかな理解をする分にはそれほど難しくありません。まずは以下の3つを読むことです。
アジャイル宣言やアジャイル宣言の背後にある原則はそれぞれ1分もあれば読み終わるでしょう。スクラムガイドは、それより分量はありますがそれでも17ページしかありません。それぞれ短いですが、何度読んでも発見があり、読み込む価値があります。
スクラムを始めたい場合、これらは基本です。そして、そこさえ抑えられれば後は実践あるのみです。スクラムは経験主義を標榜しているので、まずは始めてみて実践の中で変化していけば良いでしょう。
