ウォーターフォールはこう使え（まとめ）

　この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。

　…というわけで、ここでは総括＋補足して締める。

* * *

　ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1）

1. プロジェクトを構造化し、段階を踏んで要素成果物を構築する
   
2. 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる
   
3. 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる
   

　プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープンになり、ベースが明らかになるのでそこへの変更が「変更」として管理できる。（その2）

　クリティカルパスによく乗っかりがちな「仕様の確定」は、日付を決めることで現実的なものにする。契約前はペラペラだろうし、プロジェクト終盤では遅すぎる。だから、契約直後になんとしてでも形にする。そのためには、プロジェクト序盤で、「仕様が明確化されていない」事実を顧客自身の口から言ってもらう。（その3）、（その4）

　責任問題となったとき、最終的にプログラマを「守って」くれるのはドキュメント。プロジェクトが傾いたとき、その建て直しの土台となるのがドキュメント。ソースから自動生成できるが、全部読んで理解することを顧客に求めるのは無謀というもの。ドキュメントとは契約書だと意識すること。（その5）

* * *

　変更、特に仕様の変更について。ウォーターフォール・モデルで「変更」は別ライン、すなわち未来日の peak で受け渡しを約束する別チームが対処する。

　そのためには、リソースを新たに割り当てなければならない。これを嫌がるPMは現在のチームでその作業をさせようとする（←これが間違い）。その結果、現行チームの能率が大幅に低下し、クリティカル・パス上の神輿のスピードが落ちる→未来日の peak に間に合わなくなる… という悪循環がある。

　一方、きちんとリソースを割り当て、別チームが出発できれば、これほど理想的に働く方法はないといえる。なぜなら、未来日の peak で現行チーム・別チームが合流するようコミットできるからだ。ウォーターフォールでマイルストーンの「日付」にやかましいのは、その日をプロジェクト全体として保証するため。「次」はもうないのだ。

* * *

　ウォーターフォールとスパイラルの役割分担について。プロジェクト全体を俯瞰し、マスタースケジュールを粛々と実行するのはウォーターフォール、個々の「すべきこと」を割り当てられたチーム内で実行するのはスパイラルが適している。

　つまり、マイルストーン＋成果物のマネジメントはウォーターフォールで、「方式」や「業務」で、peak とチームが割り当てられた中ではスパイラルで回すほうが良い結果を出している。契約のコミットが求められ、後戻りができないものはウォーターフォール、ある程度分解された目標をクリアするにはスパイラルが良い（と経験的に知った）。特に「方式」のネットワークやデータベースアクセス、部品の開発にはスパイラルが最適。

* * *

　わたしはウォーターフォール信者ではなく、アンチ・アジャイルというわけでもない。ウォーターフォール・モデルでのプロジェクト経験が多かったというだけ。良いウォーターフォール悪いウォーターフォールの双方ともに、沢山の knowledge を積んできている。だから、危機に陥ったときどうすればよいか適切に判断できるし、そもそも酷い目に遭わないようにするには何を準備しておくべきなのかも身をもって知っている。

　フシギなことが一つある。スパイラルであれアジャイルであれ、RUPでもいい。世に問われてから随分と時間が経っているが、knowledge は積まれているだろうか? 偉大なるグルの著作物のことではない。ありゃ"教科書"だ。そうではなく、実践において結果を積んでいるだろうか? 単なる「プログラミング＋アルファ」のレベルを超えて、プロジェクト全体を任せられるものとして育っているのだろうか?

　プロジェクト全体を任せた事例があるなら、紹介してほしい。断っておくが、「実験的なプロジェクト」や「どっかの研究室が主催したやつ」ではない。また、一度きりではなく、繰り返し（＝spiral）実践で培った事例だ。10年以上前、まだ「オブジェクト指向」が手垢にまみれてないときから、ずっと探してきたが、いまだに見当たらない。

* * *

　また稿を改め、ウォーターフォールならでの事例を紹介してみたい。あるいはもっと体系的に書き直すべきかも。いずれにせよ、次回からは「スゴ本」の紹介に戻るとしよう。