ウォーターフォールモデルを利用するメリットとデメリット

ソフトウェア設計・構築の手法にも、プロトタイプモデルやスパイラルモデルなど、さまざまな手法がありますが、その中でも最も利用されているのはウォーターフォールモデルでしょう。

当たり前のように使用されているウォーターフォールモデルですが、決して万能な手法ではなく、メリットとデメリットが存在します。今回はウォーターフォールモデルを利用することのメリットとデメリットについてご説明していきたいと思います。

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

開発の全容がプロジェクト開始の早い時点で分かる

ウォーターフォールモデルでは「要件定義→設計→プログラミング→テスト」といったように、システム開発のふわっとした部分（上流）から工程を進めていきます。そして下流の工程に入るにしたがって、徐々にシステムの形が形成されていき、最終的にはテストでシステムの品質を保証します。

各工程を完了させてから次工程に進むのが鉄則であり、原則として前の工程にまで遡って作業を行うことはありません。プログラミング工程に入ってから、機能追加が発生することは理論上ありえないのです。

つまり要件定義を終わらせた時点で、システムの全容を掴むことができるのです。そしてベテランエンジニアにもなれば、システム要件を固めていく中で、設計やプログラミングなど、それ以降のフェーズにかかる工数についても見積もることができるため、開発スケジュール全体の計画を立てることが容易で、当初の計画通りに開発を進めることができるのです。

予算やSEの手配がしやすい

ウォーターフォールモデルでは当初の計画があり、その計画通りにプロジェクトを遂行することができるため、開発にかかる費用や、開発にかけるSE・PGの人数も予測することが容易です。

SEも自社SEで充足できなければ、パートナー企業から集めてこなければなりませんので、そうそうすぐに適任者が見つかるわけでもありません。だから早い段階で必要となる人手の予想がつけば、SEやPGの手配もつけやすくなります。

まさしく計画的にプロジェクトを遂行するという意味では、ウォーターフォールモデルはうってつけの開発手法と言ってよいでしょう。

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

手戻り作業が発生すると、大幅な工数増となる

ウォーターフォールモデルも完全無欠というわけではありません。先ほどは計画通りに進めば、予算も人員の手配も容易と申しましたが、問題は”計画通りに進まなかったとき“です。計画通りに進まなかったときこそ、ウォーターフォールモデル最大の弱みが現れます。

上流工程→下流工程へと開発を進めていく中で、原則工程を遡ることは禁止なのですが、どうしても遡らざるを得ない場合が出てきます。例えばプログラミングをしていく中で、処理ロジックに矛盾が生まれるようなプログラム仕様であることに気付き、詳細設計工程まで遡って訂正したり、総合テストで処理結果を確認したところ、お客様の要件を満たすことのできないようなアウトプットとなってしまったため、基本設計工程まで遡って修正を加えるなど。

工程戻りは当初の計画からは「想定外」の出来事です。手戻り作業が発生する事態になれば、予算も人手も、当初の計画よりも増大してしまうのです。

下流工程になればなるほど手戻りが深刻になる

そして下流工程になればなるほど、手戻り作業にかかる工数は増大します。「プログラミング工程→詳細設計」という手戻りよりも、「総合テスト→要件定義」という手戻りの方が、一層深刻です。

遡る工程が多ければ多いほど、遡った時点まで巻き戻して工程を進めなければならず、より多くの予算や人手を必要とします。

できるだけ工程戻りを発生させないようにするためには、コミュニケーション力高く要件定義に臨み、緻密に設計工程を遂行できる、能力の高いSEが担当することが求められます。

 

おわりに

ウォーターフォールモデルはシステム開発の理想の形かもしれませんが、それを上手に機能させるには、能力の高いPMやSEがプロジェクトに従事してこそです。プロジェクト遂行能力の低いPMが担当することになれば、逆にウォーターフォールモデルは諸刃の剣となって、メンバーを疲弊させるだけになるかもしれません。

また近年ではウォーターフォールモデルに取って代わって、アジャイル開発というタイプの手法も話題になっております。詳しくは「ウォーターフォールモデルは衰退しアジャイル開発が主流になる日が来るのか」をご参照ください。