開発プロセスモデル

ウォーターフォールモデルのメリット

　ウォーターフォール・モデルのメリットとしては、次のような点が挙げられます。

・進ちょく管理を行いやすい
　開発全体のプロセスを工程に分割して各工程の成果物を明確に定義するため、成果物の完成度合いを持って作業進ちょくとすることができる。また、各工程が直列に進むため、マイルストーンの設定が明白。さらに、成果物を関係者がレビューすることにより、各工程の進ちょくに関して、開発側とユーザー側の意思統一が可能。なお、後工程においては、この成果物レビューでの結果が、開発側にとっての唯一の武器となる（ユーザー側に「仕様です」というための根拠）。

・全体規模を把握しやすい
　最初の工程から最後の工程まで、システム全体をスコープとして進めるため、要件定義や設計の工程（いわゆる、上流工程）が終わった段階で、システム全体の仕様を決めることができる。逆に言うと「上流工程が終わった段階で、システム全体の仕様が決まっていなければならない」ということなので、現実問題として、その時点で決められる範囲や粒度が問題になることも少なくない。

・PJを構成しやすい
　この業界でよく言われる開発者の役割分担に、SEとかPGとか言う分け方がある。それぞれ「設計をする（できる）人」「実装をする（できる）人」ということだが、すなわち、ウォーターフォール・モデルのPJにおいては、設計工程ではSEを集め、実装工程ではPGを集めれば良い、ということになる。特に大規模PJで、メリットが大きいと言る。

・契約にしやすい
　システム開発では、実装工程をほかの会社が担当するなど、下請け構造が根強い。例えば、設計工程での成果物（設計書や仕様書）通りの実装を下請け会社に依頼することが多い。この場合、双方にとって、瑕疵（かし）判断の明確さや見積もりのしやすさ、という観点でメリットが大きい。ただし実態としては、仕様変更（上流工程に対する変更）の頻発により、下流工程を担当する下請け会社がデスマーチに陥ることも少なくない。

ウォーターフォールモデルの考え方

　さて、これらのメリット（や、この後説明するデメリット）を生み出す根底として、ウォーターフォール・モデルには次のような考え方があります（図2）。

・事前に予見
　開発の早い段階で今後のことを見通し、それに従って開発を進める。見通した内容に対する変更は、基本的に受け付けない。そのため進ちょく管理を行いやすく、全体規模を把握しやすく、また契約にもしやすい、ということになる。

・手続き中心
　成果物を作成する手続きを中心として、誰がやっても同じように進められるようなタスクに分解して管理する。そのため進ちょく管理を行いやすく、PJを構成しやすい、ということになる。開発メンバー側からすれば、PJのルールに従って、歯車のように各工程の作業をこなす、というイメージとなる。

　これらの考え方から、ウォーターフォール・モデルは、「大規模プロジェクトに向いている」「システムの品質を高めるのに有効」などと言われています。

　さて、歴史が古いことや上記のようなメリットもあり、現在では、最も使われている開発プロセスと言って良いウォーターフォール・モデルですが、どこに行ってもいろいろな「悪口」を耳にします。「要件が変わらない訳ない」「どうせ、前工程の責任を後工程が全部かぶるだけ」等々。よく使われているだけあって、それなりの「ダメな点」もいろいろと上がってくるのでしょう。そもそもソフトウエア開発PJの成功率があまり高くない（と言われている）上に、開発プロセスの選択肢がほとんどなく、業界の慣習やウォーターフォール・モデルの運用が原因になっていることも多いのではないでしょうか。