  |
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
から始まった何年ぶり何度目かのウォーターフォール (vs アジャイル) 論争だが，この記事もその反論記事・支援記事も含めて，「ウォーターフォールを採用する（せざるを得ない）理由」について書いてあるものはあっても，「ウォーターフォールのメリット」について書かれた記事が見当たらないのには驚く。
http://simplearchitect.hatenablog.com/entry/2016/06/20/080807
まずこの記事。「メリットはない」って言ってるんだから，書いてないのは当然なのかもしれないが，アジャイルのメリット＝なぜアジャイルがいいのか，についても書かれていない。これではFUDといわれてもしかたない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
「日本でアジャイルが流行らない理由」≒日本でウォーターフォールが採用される（消極的な）理由は書いてあるが，ウォーターフォールのメリットについては書かれていない。
http://ledsun.hatenablog.com/entry/2016/06/21/102501
タイトルから期待して読んだが，「ウォーターフォールの課題と言われてるものは，実は解決されてるよ」という記述が大半を占める。
最後の一節は「アジャイルの問題」として，「変化に人間がついていけない」点が挙げられていて，その裏返しでウォーターフォールがいいよ，ってことを言いたいのかもしれない。しかし，アジャイルは「変化に機敏に対処する」ことが眼目であって，何でもかんでも変化させなければいけない，というものではないので，指摘自体が的外れに見える。
http://arclamp.hatenablog.com/entry/2016/06/23/172941
冒頭，
とあって，メリットを語ってくれるかな，と期待させるが，結局「スコープが確定しているならウォーターフォールでいい」，という消極的な採用理由が述べられるだけで，メリット＝積極的な採用理由は述べられていないように見える。
それを語る前に，まずウォーターフォールを定義しておく。現在日本でウォーターフォールとして認識されているプロセスは，国防総省式の「戻りの線」なしのものである。即ち，確定した要件なり仕様なり（以下まとめて「スコープ」と呼ぶ）は変更しない。「ウォーターフォール」という名前自体が，この一方向性に由来している。従って，ウォーターフォールの定義としては，「（フェーズゲートを超える際に）確定したスコープは変更しないプロセス」で良いだろう。
この定義に沿わないプロセスは，「偽ウォーターフォール」であり，以下に述べるウォーターフォールのメリットを受けることはできない。メリットを享受できないだけでなく，この種の「偽ウォーターフォール」は（「偽アジャイル」同様）大きな害悪を撒き散らす。
さて，「確定した要件・仕様は変更しない」ことのメリットは何か。パッと思いつくのは「手戻りがない」ということである。確かにこれはメリットと言えるかもしれないが，手戻りがなくてうれしいのは主に作業者である。これでは弱い。もう一歩踏み込んで「手戻りがない」と発注者／受注者含め何がうれしいのか。
答は
である。
すごく当たり前のことなのだが，これが書かれている記事が見当たらない。
そしてウォーターフォールのメリットはこれだけで，それ以外にはメリットと言えるものはおそらく存在しない。
ここで，前節で登場した三つの要素「スコープ」「コスト」「納期」に注目してみる。
よく見るとこれらは，いわゆる「QCD」に対応している。ちなみにここでいう Quality (品質) は「バグがない」等の「問題の不在」だけを指すのではなく，本来の意味での「品質」，即ち利用者の役に立つか，使いやすいか，ということまで含むものである。スクラム（アジャイル）を知る人であれば，「トレードオフ・スライダー」の「品質」に相当するものだと理解してもらえればよい。
そうすると，前節のウォーターフォールのメリットは，以下のように言い換えることが可能である。
「ウォーターフォールのメリットは＜品質を固定することで＞コストと納期がぶれるリスクを小さくできる点にある」
これで問題が明らかになった。要するにウォーターフォールは，コストと納期のために品質を二の次にするプロセスなのである。
その結果，これまでどんなことが起きてきたか。
開発の途中で，要件や仕様に問題が見つかったとしても，あくまでウォーターフォールの定義に殉じると，出来上がるのは「使いにくい」「使われない」システムである。
「事業会社をIT会社に転生させることが、これからのSIerのミッション」 ( http://gothedistance.hatenadiary.jp/entry/2016/06/20/153941 ) に，その実例らしきものがでてくる。
これを行った瞬間から，ウォーターフォールはその（ほぼ）唯一のメリットを失い，混沌が始まる。
最も多いパターンは，発注者側が（もはやスコープ＝品質を固定するという前提が失われているにも関わらず）納期とコストの確定というメリットの享受を譲らず，プロジェクトがデスマーチ化する，というものであろう。あるいは，コストは譲るが納期は譲らない，というパターンの方が多いかもしれないが，いずれにせよデスマーチ化につながりやすいことは間違いない。
そしてこの副作用として何が起きたかというと，受注者側がそれを見越して納期とコストにバッファを積むようになった。当然それは見積もりの不透明感につながり，発注者側に受注者が「ボッて」いるのではないかという不信感を植えつけることになった。要するにお互い不幸になったのだ。
スコープの変更の必要が生じたら，どちらに転んでもいい結果は得られない。となると，ウォーターフォールがうまくいくのは，「スコープが明白で，変更の可能性が全くない」開発案件に限られる。統計をとったわけではないので，そのような案件がどの程度あるかはわからないが，直感的には「ほとんどない」のではないかと思う。なぜなら，そこまでスコープが明白であれば，今はパッケージやSaaSのようなレディメイドのものを導入する方が安いし早いしリスクも小さいからだ。
もう一つの可能性としては，スコープが変更不要になるまで，とにかく事前の準備と調査を徹底的に行う，というパターンもありうる。しかし，これは「準備と調査」の過程で事実上いろいろ試作することになる（そうしないと変更のリスクが消せない）ので，もはや作業プロセスの大半が実はウォーターフォールではない，ということになるだろう。
ではアジャイルのプロセスを導入すれば，これらの問題はすべて解決するか，というとそういう話ではない。ウォーターフォールにメリットが（ほとんど）ないことと，アジャイルが有効であることとは，独立な議論である。
そもそも「アジャイル」というのは考え方であってプロセスではない。だから，考え方を理解せずにプロセスだけ導入すると「偽アジャイル」になって，害悪を撒き散らすことが多い。
アジャイルの考え方は，主に以下の2点でウォーターフォールと大きく異なる。
1. スコープの変化がありうることを前提としている
2. スコープ＝品質＝役に立つこと（＝使えないものを作らないこと）が最優先であり，そのためにコストや納期が変化を（ある程度）受け入れる
この考え方こそアジャイルの本質であって，CI/CDやDevOpsなどは，変化にすばやく対応するための道具にすぎない。もっといい道具があればそれを使えば良いし，CI/CDがなくても変化に迅速に対応できるのなら使わなくてもいい。
また「スコープに変化がありうること」は必ずしも「スコープをできるだけ確定する」こととは矛盾しない。リスクを下げるために，スコープはできるだけ確定する努力をする，というのはアジャイルでも変わらない。変えるべき時は変える，という点が違うだけだ。なんでも後で決めればいい／変えてもいい，というのは「偽アジャイル」であって，害悪でしかない。
もちろんこれがあれば何もかもが解決する，という類のものでもない。上述の2点があるだけで（少なくとも今のたいていの開発案件において）ウォーターフォールよりマシになりうるとは思われるが，別の問題（例：納期やコストの変化をどう扱うかという問題）も，同時に導入されてしまう。特に日本では請負契約によるソフトウェア開発が一般的であり，これが「納期やコストの変化」と絶望的に相性が悪い。
もっとも，今の「ウォーターフォール」によるソフトウェア開発が，請負契約の成立条件である「契約時にスコープを確定（し，変更しない）」を厳密に守っているわけでもない以上，これだけを理由にアジャイルを否定するのはどうかとも思う。
契約については，IPA等でも取り組みがあるようだが，いずれにせよ契約を行うのは発注者と受注者であり，受注者側だけでどうこうできる問題でもないので，発注者側の意識の変化を期待するしかないかもしれない。
