ウォーターフォールモデルとは
システム開発は上流工程と呼ばれる「要件定義」「設計」と下流工程と呼ばれる「開発」「テスト」の工程に分けられます。
- 要件定義：お客様の要求を聞き、システム化するための仕様を決める工程
- 設計：要件定義で決まった仕様を、設計書におこす工程
- 開発：設計書を見ながら、プログラミングで実際に物を作る工程
- テスト：開発で作られた物が、設計書通りに作られているか確認する工程
ウォーターフォールモデルとは上流から下流に水が流れ落ちるように行う開発手法のことを言います。具体的には「要件定義」→「設計」→「開発」→「テスト」の工程を順番に行っていく手法です。最も古典的な開発モデルの一つで現代でも広く普及しており、ウォーターフォールモデルの開発手法を採用している現場はよくあります。
スポンサーリンク
ウォーターフォールモデルで開発を行う場合は、要件定義の段階でお客様の要求がすべて明確になっている必要があります。なぜならウォーターフォールモデルは「前の工程には戻らない」というのが前提の開発手法だからです。とはいえ何らかの問題や状況変更により前の工程をやり直すことがあります。これを"手戻り"といいます。
ウォーターフォールモデルのメリット
ウォーターフォールモデルのメリットは、全体的な計画を立てやすいのが最大のメリットです。
要件定義の段階で、お客様の要求がすべて明確になっているため、やるべき事が明確であり全体のスケジュールが立てやすくなります。
またスケジュールが明確なため、プロジェクトに必要な人員管理もしやすく、PM（プロジェクトマネージャ）にとっては非常に管理がしやすい開発手法です。
また仕様が明確になっているため、設計工程では設計書が書きやすいというメリットもあります。設計担当者は設計工程の中で、明確になっている仕様を設計書におこすだけです。設計書レビューがしっかりされている現場であれば、設計書の質も高くなります。
ウォーターフォールモデルのデメリット
ウォーターフォールモデルのデメリットは手戻りの負担が大きいことが挙げられます。ウォーターフォールモデルは基本"手戻り"は想定していない開発手法です。工程が下流になるにつれて手戻りの負担が大きくなります。
またウォーターフォールモデルは、テスト工程にならないとお客様が発注したシステムに触ることが出来ません。そのため、いざ触ってみて要求と違ったり、要求通りだが仕様を変えたいと思った時、前者であれば開発側のミスなので、開発側が手戻りをすることとなりますが、後者の場合は、変更注文を発注しないといけない可能性があります。
スポンサーリンク
手戻りは開発規模が大きければ大きいほど、手戻りに時間がかかります。テスト工程やリリース後に大きな認識齟齬が見つかった場合、開発側には大きな負担となる危険性があるのです。
まとめ
本記事ではウォーターフォールモデルの説明とウォーターフォールモデルのメリット・デメリットを紹介しました。
ウォーターフォールモデルはスケジュール管理がしやすいメリットがありますが、いざ動かしてみて「この仕様は想定していたものと違う」なんて話になると、開発側には大きな負担になる危険性がある開発手法でもあります。
最近では、ウォーターフォールモデルのデメリットである"手戻り"の負担を軽くしたアジャイル型開発のような新しい開発手法も登場しています。
[その他 開発手法]