ウォーターフォールはこう使え（その1）

　ウォーターフォール・モデル悪玉論が幅を利かせている。一方でスパイラル・モデルやアジャイル・モデルがもてはやされている、銀の弾丸のごとく。
　曰く、

• この無駄な成果物を作らされているのはウォーターフォールだから
  
• あいまいな仕様と理不尽な要求に振り回されているのはウォーターフォールだから
  
• スケジュール後半になって追い立てられるのはウォーターフォールだから
  
• いつまでたっても品質が向上しないのはウォーターフォールだから
  
• 赤字プロジェクトが垂れ流されているのはウォーターフォールだから
  
• このプロジェクトがデスマってるのはウォーターフォールだから
  

　偉大な（?）グルの尻馬に乗って叩く。まるでウォーターフォールという軛がボクの創造性と可能性をことごとくダメにしていると言わんばかりに。何かに責任転嫁して考えを止めるのは楽だけど、その「何か」が真の原因で無い限り、解決にはならない。

　仕事ができないのは道具が悪いと騒ぐ前に、その道具ちゃんと使ってる? 知らないままコトバだけを振り回すことはとても危険なことは、ＯＯ談義で語り尽くされてるでしょ? 10年前のトドメ文句「オブジェクト指向ですから」は、それなりに効力をもっていた。わたしはよく分かっていなかったから…が、今はそうではない。試行錯誤を繰り返す中で、その両刃の剣に何度も傷ついたから。

　今ではウォーターフォールとスパイラルを併用している。M.Fowler氏のようなスゴいことは言えないけれど、それでも蔓延する誤解というか怨念というか思い込みについて、提案めいたものは出せる。

* * *

ウォーターフォールモデルとは

　はてなの定義によると、ウォーターフォールモデルでは逐次開発モデルであり、フィードバックがないらしい。

　滝が上から下へ流れ落ちる如く、手戻りは認められない。「上流」で決定されることは碑（いしぶみ）と同じ、絶対命令かつ誤りが一切無いことが前提。その一方で、拡大解釈可能かつあいまいに書かれてあることも事実。「下流」に至り顧客の目に見える段階になって要求が具体的になり、しかもそれは碑に書いてある（＝解釈可能）と言い張り、無償で直せ、これは仕様どおりでないと言い放つ…

　この例は、今の状況なのかもしれない。安請合した営業やダメPM、あいまいな仕様や無謀な計画がプロジェクトを破綻させているにすぎない。"ウォーターフォールだから"なのではない。理論武装のヘリクツと、開発方式とは別物。

　これをふまえた上で定義する。ウォーターフォールモデルとは、まずマイルストーンまでの成果物を厳密に決め、次にそこに向かって収束させることを段階的に進めるやりかた。

　成果物とはドキュメントやコードに限らない。他システムの接続確認ができる試験環境だったり、○○業務を行うためのデータセット一式だったり。

* * *

"河下り"よりもむしろ"山登り"

　"ウォーターフォール"という名前に違和感がある。上から下へ、"河下り"のイメージじゃない。現実はむしろ、順番に段階を踏んで上を目指す"山登り"の方が近い。

　ただし、頂上がゴールなのではなく、一つの peak であって、peak から peak をリレー式に縦走する感じ。一人で黙々と登るのではない。皆で登る。それも全員がいっせいに始めるのではなく、チームごとにバラバラ。ある人は途中の peak で下山し、別の人は途中から peak を目指す。また、登山口から登る人もいれば、市販ソフトを使って五合目からの人もいる。

　最初から最後まで縦走する人はいない。リレー式に渡されるバトンというより、むしろ神輿のようなものを担ぎながら次の peak を目指す。途中で合流する人から部品を組み込んで、神輿はだんだん大きくなる。担ぎ手もどんどん増えてくる。

　ポイントは、peak に到着する日を予めコミットしておくところ。つまり、マイルストーン毎に必要な成果物は厳密に提示させるところ。「次でがんばるからいいや」「○○のせいで遅れます」なんてセリフは言わせないところ。

　「○月○日に peak-1 に到達し、次のチームへの引継を行う」のであれば、何が何でも神輿はその日に着いてなければならない。できなければ peak-1 で待っている人のお金と、そこへ向かっているチームのお金がどんどん使われることになる。

　神輿は一つに限らない。むしろ2つ3つあるのが普通。どんな神輿かはプロジェクトの性格による。1回こっきり、失敗が許されないならば、試験環境やテストツールがデカい神輿になるだろう。あるいは、レガシーシステムの更改ならば古い神輿が引っ張り出される。

　その中で、最も遅れてはならない神輿のルート、すなわち一番時間がかかる神輿のルートがクリティカルパス。こいつを見極め、こいつだけはゼッタイに遅れないようにする。計画との Fit/Gap に目を光らせる。この神輿が遅れるということは、プロジェクト全体のケツを割ることになるから。

　仮に「間に合わない」「成果物がそろわない（貧弱ゥ）」な場合は、挽回策とセットで peak-1 に臨む。peak-1 には皆が待っているのだ。PMがマイルストーンと成果物に喧しいのは、自分の責任で他人（他社・他チーム）のお金を会社に使わせることがイヤだから。

* * *

ウォーターフォール・モデルの真髄

　ウォーターフォール・モデルの真髄はこうだ。プロジェクトを構造化し、段階を踏んで要素成果物を構築する。次に、必要な要素成果物を必要なタイミングで持ち寄り、組み上げる。これを複数のルート・複数のチームで行う。だからこそ「マイルストーンの厳守」「成果物の厳守」が求められる。"ウォーターフォール・モデル"を言い換え、「プロジェクト構造化モデル」と呼ぶほうがしっくりする。

　幸か不幸か、「あじゃいる」だの「らっぷ」といったカッコイイ呼び名が付けられず、"ウォーターフォール"という語感から様々な誤解・曲解が生まれては一人歩きしたのが真相だとふんでいる。