ウォーターフォールは通用しない

従来のウォーターフォールモデルによる開発工程はもはや通用しません。設計が終わる前にコーディングははじまっているし、コーディングが終わる前にテストははじまっているのです。

ウォーターフォールモデルによる開発は、多くの企業で当たり前のように行われています。「だって管理が楽だしぃ」、というのがその原因でしょう（たぶん）。開発工程をいくつかのステージに分けて、ひとつずつ着実にこなしていこうというわけですから、単純でわかりやすいのは確かです。

例えば「計画」「設計」「実装」という３つのステージを考えてみましょう（やや大ざっぱですが）。まず計画を行い、計画が完成したら設計を行い、設計が完成したら実装を行います。各ステージで問題が発生したら、ひとつ前の段階に戻ってやり直します（フィードバック）。

管理者好みの、非常に単純な原理ですね。

実際のところ、この方法が通用するのはプロジェクトの規模が十分小さな場合に限られます。フィードバックにはコストがかかることは明らかですが、これは規模が大きくなるほど高くつくのです（私の直感ですが、フィードバックのコストは規模の２乗に比例するように見えます）。大きなプロジェクトで完全に先のことを見通してフィードバックの必要ない計画を練るなんて神業ができるはずありませんから、大規模プロジェクトにウォーターフォールモデルを導入すると、次のどちらかの結果に落ち着きます：

• フィードバック作業によって開発期間が倍増し、開発費用も倍増する。開発メンバーは疲労し、終わりの見えない仕事に飽きた優秀な人材は転職を試みる。たとえどんなに素晴らしいシステムに仕上がったとしても、完成する頃にはニーズがなくなっている。当然の結果として、顧客の信用を失う。
• フィードバックの必要性を無視し、未完成のまま出荷される。開発チームの混乱状態がソースコードに反映されているので、メンテナンスは困難である。バグは永久になくならない。また、メンテナンスのための専属スタッフ（＝貧乏くじを引かされる人物）が必要になる。

ウォーターフォールモデルは間違っているのでしょうか？いいえ、そうではありません。ウォーターフォールモデルの「使い方」が間違っているだけなのです。設計しなければ実装はできないし、実装が完了しなければテストはできません（当然！）。問題なのは、開発規模と人間の限界との関係です。

大きすぎるプロジェクトは、より小さな部分に分割しましょう。システムはオブジェクトの集合体であるという考え方によれば、この発想は極めて自然です。分割された結果（＝サブシステム）がまだ大きすぎるなら、さらに分割しましょう。そして各部分は最終的に、１人の人間が理解可能な十分小さなオブジェクトとなります。このオブジェクトそれぞれにウォーターフォールモデルを適用します。

規模の小さなウォーターフォールモデルでのフィードバックには、無視できるほど小さなコストしかかかりません。ほとんどの場合、フィードバック作業は担当者の頭の中だけでごく自然に行われるでしょう。プロジェクト全体の工程を後戻りさせる必要はなく、隣接するサブシステムとの関係だけ考慮にいれれば良いのです。気の滅入るような会議を開く必要もありません。そのかわりに、関係者のところに行って、ちょっとしたインタビューをすれば済んでしまうでしょう。

この方法によって、プロジェクトは小さなウォーターフォールの集合体になります。落差の小さな滝(=waterfall)が寄り集まって大きな滝になる感じです。プロジェクト全体の工程は、次のような（驚くべき！）状態になります：

• 設計を開始してまもなく、どこかで実装が開始される。
• 実装を開始してまもなく、どこかで単体試験が開始される。
• すべての実装が終わる寸前まで、どこかで設計が続いている。
• すべての単体試験が終わる寸前まで、どこかで実装が続いている。

もしあなたが管理者なら、開発工程の終盤にさしかかっても設計が完了していないという状態は「恐怖」でしょう。順調に進んでいるのか、それとも本当に遅れているのかを見極めなければならない責任がプレッシャーとなるでしょう。しかし、重圧に負けて開発工程全体にウォーターフォールモデルを適用するようなことがあってはなりません。

それに、管理者が闘わなければならない恐怖はこれだけではありません。この恐ろしい話については、また次回。