ウォーターフォールモデルとは？わかりやすく特徴やメリット、アジャイル開発との違いを解説

ウォーターフォールモデルとはシステム開発の現場でよく利用される開発モデルの1つです。

進捗管理や納期管理、品質管理、手戻りの抑制などができ大変メリットのある開発手法ですが、本質を知らずにウォーターフォールモデルを利用しているプロジェクトを多く見かけます。

近年ではアジャイル型の開発プロセスが注目されていますが、ミニウォーターフォル型の開発プロセスであるため、ウォーターフォルモデルを知らなければアジャイル開発の良さを十分に発揮することはできないでしょう。

ぜひ最後までお読みいただきウォーターフォールモデルについて正しい知識を身に着けてください。

ウォーターフォールモデルとは

ウォーターフォールモデル（Waterfall Model）は開発手順を1歩ずつ確実に進めていく開発モデルのことです。

開発を「工程」に分けて管理し、工程が完了したら開発会社とお客様が各工程の成果物（アウトプット）を確認し、合意の上で完了し次の工程にうつります。

ちなみに、確認することを「レビュー」といい、合意されたら絶対に前の工程に戻らないことが鉄則で、原則として仕様変更が認められません。

仕様が変わってしまうとシステム全体の機能の見直しが必要になってしまい、すべての工程が手戻りしてしまうためです。

また、基本的にシステム開発のスケジュールと予算は手戻りを前提に組まれておらず、仕様変更が入ることはプロジェクトに大きな問題が発生することを意味します。

滝のように落ちながら進め、手戻りのような逆流を起こさない開発手法である点がウォーターフォールモデル開発の特徴です。

ウォーターフォールモデルとV字モデルの違い

V字モデルは、ウォーターフォールモデルの進化版です。

下図のように「実装・単体テスト」を中心に見ると、以下のように見ることができます。

引用：第3回：ウォーターフォールにおけるドキュメント作成ポイント ｜Think IT

上記の図で、左側が要件定義や設計を行う工程で、上流工程と呼ばれ、右側は検証（テスト）を行う工程で、下流工程と呼ばれます。

さらに、上図のように「V字モデル」で表現をすることで設計（上流工程）と検証（下流工程）が左右で対となります。

具体的には次のように対となります。

このように「各工程が対」になることで、同じ粒度で確実に検証ができることから「ウォーターフォールはプロセスで品質を確保できる開発手法」だということが言えます。

プロセスで品質を確保して納品できるため、SIerと呼ばれる請負会社はこの手法を中心に開発しています。

V字モデルでは設計フェーズに対応するテスト（検証）フェーズが用意されていることで、システム全体の品質を保証できるという利点があります。

要件定義で求められた機能は満たされているか、基本設計ではシステム全体が問題なく機能するのか、詳細設計では各種機能が連携できるのか、単体テストでは実装されたプログラムが問題なく動くのか、ということを見ていきます。

前段階の工程は次段階の工程の準備であり、各工程は（基本的に）完璧であることが求められるのです。

ウォーターフォールモデルとアジャイル開発の違い

アジャイル開発というのは、リリースまでの期間を可能な限り短くすることで、ビジネススタートを早めるという目的で考えられたシステム開発手法です。

どのように短くするのかというと、機能を必要最低限に留めるという方法が取られるのが一般的です。

1週間や1ヶ月というスパンで動くシステムを繰り返し提供しつづけることで、この1スパンのことを「反復」と呼びます。

また、アジャイルで1番利用される手法が「スクラム」で、メンバーがシステムの要求仕様とその優先度を共有して、1週間または4週間という期間内でのリリースを目指します。

ミーティングは毎日行われ、メンバー間での密接なコミュニケーションを重視しており、その連携の高さをラグビーのスクラムにちなんで名付けられました。

そのほか、「スパイラル」という手法も存在します。

スパイラルでは短期間でクライアントの要求する機能を何度も提供することが行われます。

まずは作って、次の期間では品質を向上させる。

これをグルグルと回すことで最終的な完成系に近づけていきます。

一言にアジャイル開発といってもさまざまな手法が存在し、その定義も人によって少しずつ異なりますが、ウォーターフォールモデルと決定的に違うのは「ローンチ（リリース）が早い」という点でしょう。

ただし、アジャイルは非常に属人的な開発手法のため、品質確保も属人的になりがちです。

以下の表はウォーターフォールモデルとアジャイル開発を比較したものです。

アジャイル開発は計画を重視していないので、仕様変更にも柔軟に対応できるというのがよく分かると思います。

また、成果物に関してもウォーターフォールモデルが膨大な仕様書、設計書を作成するのに対して、アジャイル開発は実装コードのみというのも特徴的です。

項目	ウォーターフォールモデル	アジャイル開発
計画性・進捗管理	高（数ヶ月以上の計画）	低（1週間〜2週間）
品質	プロセスで確保	属人的に確保
価格	比較不可	比較不可
仕様変更	不可能	可能
リリース頻度	3ヶ月〜1年	毎日〜2週間
成果物	設計書、プログラム、マニュアル	プログラム

こうしてみるとウォーターフォールモデルのほうがアジャイル開発よりも劣っているような印象を持たれるかも知れませんが、そういうことではありません。

ウォーターフォールモデルのほうが有利なケースというのも存在します。

筆者がSIerからWeb系に転職したときに感じたウォーターフォールとアジャイル開発の違いをこちらの記事にまとめています。

もっとリアルな形で知りたい方は合わせてご覧ください。

続けて、ウォーターフォールモデルの特徴を見ていきましょう。

ウォーターフォールモデルの特徴

ウォーターフォールモデルの特徴は「工程の厳格な管理」といえるでしょう。

大人数で開発を進める大規模プロジェクトにおけるすべての工程に、抜け漏れがないかを徹底的に検証しながら進めていきます。

何度も要件に漏れがないかクライアントからヒアリングを行い、要件を満たすための基本設計を行い、基本設計を元に詳細設計を行っていくので、前段階の工程が完璧でないと次の工程に進めないようになっています。

そのため、各工程では厳格なスケジュール管理、品質管理が求められるのです。

工程ごとに仕様を確定することで着実な推進が可能

ウォーターフォールモデルでは、工程ごとに仕様が「確定」していきます。

そのため、仕様を確定する際にはクライアントとの「合意」のもと、次の工程にプロジェクトを進めていきます。

不用意な仕様変更によるトラブルを避けるためにクライアントからは承認印をもらいながら進めていくのが一般的です。

こうして進められるウォーターフォールモデルにおいて、仕様変更は原則禁止となっており、仕様変更を行う際にはスケジュールの見直しや予算の変更が行われることもあります。

プロジェクトがデスマーチに突入するきっかけの1つにこの仕様変更があります。

エンジニアには「仕様変更」が発生しないように細心の注意を払って進めることが求められます。

工程ごとにプロジェクトメンバーのアサインで大規模開発に対応

システム開発では工程ごとに求められるプロジェクトメンバーの人数が変わってきます。

そのため、工程ごとにメンバーをアサインし、柔軟に対応することで大規模開発が可能となります。

たとえば、要件定義や基本設計といった工程ではそこまでの人数は必要ありません。

一番マンパワーが必要になるのは実装フェーズからであり、ここから一気にプロジェクトメンバーの数が膨れ上がっていくのが通常です。

実装フェーズで200人必要だからといって要件定義から200人のリソースをアサインしてしまうと、あっという間に予算を圧迫してしまいますが、必要なときに必要なリソースを確保することで効率的な開発が可能になるのです。

IT業界のSIerランキング上位ではITゼネコンというピラミッド構造が依然として根強いですが、これはウォーターフォールモデルによってシステム開発をしていることが起因です。

実装フェーズで大量のプログラマーをアサインする必要があるため、徐々に下請け、孫請けに関係会社が広がっていくためです。

ITゼネコンの構造上、大手がキャリア・待遇ともに有利です。このあたりについては以下の記事で詳しく解説していますので合わせてご覧ください。

参考：ITゼネコンとは？下請け構造から見える課題を現場視点で解説！｜IT業界の歩き方

SIerなどの請負開発ではプロセス・納品物が明確になるウォーターフォールモデルを利用

ウォーターフォールは納品物や責任範囲、スケジュールが明確にできるため、請負開発の契約に適していることも特徴としてあげられます。

その他にも複数の会社と連携する場合でも同様の理由でウォーターフォールモデルが好まれます。

たとえば、会員機能はA社、ショップ機能はB社という割り振りになる場合です。

ウォーターフォールモデルは工程ごとにやることがはっきりしているので、責任範囲がわかりやすいというのも特徴といえます。

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

ウォーターフォールモデルではメリットとデメリットが存在します。

まずはメリットとして、以下の5つの点があります。

それぞれ見ていきましょう。

QCDの管理がしやすい

QCDとは

のことです。

つまり、狙った場所に狙った期間で着地しやすいということですね。

期間・コストの計画を立てやすく請負契約に合う

各フェーズを確実に終わらせていくため、期間やコストの計算が立ちやすいのはウォーターフォールモデル最大の特徴といえます。

「いつ終わるか分からない」では計画の立てようもありませんが、やること、必要なことが明確になっているので外部発注しやすいのです。

工程により進捗管理がしやすい

工程ごとに進んでいくため、現在、どこの誰が何をしているのかがはっきりしています。

そのため進捗管理が容易で、問題があればその場で潰しながら進むことが可能です。

工程により分業化ができる

工程ごとにやることが決まっているので、業務に適したリソースを配置することが可能です。

適材適所で分業できるので、リソースを無駄なく活用できます。

分業化により人員投下がしやすく大規模開発に合う

必要なときに必要な人員を等価することができるので、大規模開発にも対応することができます。

要件定義は5人、基本設計は10人、詳細設計は20人、開発は100人という進め方もでき、柔軟なプロジェクト進行が可能になります。

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

逆にウォーターフォールモデルのデメリットとしては以下の点があります。

ひとつずつ解説します。

仕様変更の弱さと工程による専業化の副作用

ウォーターフォールモデルの最大の敵は「仕様変更」であることは間違いありません。

各工程を「確定」しながら前に進むウォーターフォールモデルでは、仕様変更を行うことはすべて、あるいは一部の前提条件が覆ることを意味します。

また、専業化によって何かの理由で欠員が出た場合に、担当業務を誰かが補いきれない可能性も出てきます。

病欠で突然休んだ人が重要な機能の担当者である場合などは非常に困ることになってしまうでしょう。

Webサービスなど仕様が変わるプロジェクトには合わない

WebサービスというのはABテストを繰り返しながら、ユーザーの反応によって機能を追加したり、変更したりすることが多いです。

そのため、ウォーターフォールモデルを採用するとプロジェクトが破綻する可能性があります。

現在ではWebサービスの場合ではアジャイル開発のほうが主流といえるでしょう。

実装工程など人員が大量に必要な工程は多重請負構造になりがち

設計段階では数人で進めていたプロジェクトが実装工程では数百人になる、というようなプロジェクトもあります。

こういう場合、大量の人員が導入されますが、下請けA社だけで賄えないから孫受け、ひ孫受けといったアサインが行われるケースもあります。

多重請負構造によりスキルが上がらず仕事も楽しくない

多重請負構造になると、下流に行けば行くほど業務が限定的になります。

あるモジュールの開発だけを任される、テスト要員として黙々とテストケースを消化していくなど、あまり面白くもなく、スキルアップにもならない業務に携わる人が増えてしまいます。

年収も低い状態のままとなります。

クリエイティブな作業はなく工数のためだけの「IT土方」的な要素が強くなり、良い労働環境とは言えないでしょう。

リリースまでに時間がかかる

製品としてリリースされるまでに時間がかかるのもデメリットです。

大規模な案件では数年かけて開発するシステムもあります。

企画からシステムが形になるまでに数年も要してしまうと、企画していたときとは別の要件が発生してしまい、仕様変更が入ってしまう、または、そのまま出来上がっても世の中の流れから外れたシステムができてしまう、といったリスクもあります。

この弱点を克服するために、まずはリリースしようと考えられたのが前述した「アジャイル開発」です。

ウォーターフォールモデルの工程

ウォーターフォールモデルの工程を簡単に図で表現してみました。

大まかな流れで確認してみると、大枠の設計（要件定義）から少しずつブレイクダウンして基本設計を作り上げ、設計書を元に実装、そして設計書通りに実装できているのかをテストしていくという流れになります。

各フェーズには成果物が発生し、それをクライアントに承認をもらいながら進めていきます。

会社によって各フェーズの呼び方が異なることがありますが、どちらで言っても通じるので心配はいりません。

工程	説明	成果物	別名
要件定義	要求やニーズを明確化し、プロジェクトの目標や範囲を定義する	要件定義書	–
基本設計	要件定義に基づいてシステムのアーキテクチャや機能の基本的な仕組みを設計する	基本設計書	外部設計
詳細設計	基本設計を基に実装のための具体的な使用を策定する	詳細設計書	内部設計
実装	システムのコーディングやプログラミングを行い、機能を実現する	プログラムコード	PG、製造、開発
単体テスト	機能単体の性能をテストし、評価する	単体テスト結果報告書	プログラムテスト
結合テスト	複数機能の連携テストし、評価する	結合テスト結果報告書	–
総合テスト	システム全体の機能や性能を総合的にテストし、評価する	総合テスト結果報告書	システムテスト
受入テスト	実際に利用する環境でシステムが正常に稼働するかテストし、評価する	受入テスト結果報告書	導入テスト

ウォーターフォールモデルが活用されるケース

システム開発においてはどの開発手法が適しているのかを見極めないといけません。

ウォーターフォールモデルが有利になるケースを見ていきましょう。

システム開発に詳しい担当者がいない状態で発注するケース

IT黎明期というのはシステムに関する知識を持つ担当者というのが各企業にかならず存在するわけではありませんでした。

企業は「なんとなくこんなシステムが欲しい」ということをSIerに依頼し、SIerも担当者から頑張って要求を引き出す、ということが当たり前のように行われていたのです。

さらに、これから開発していくものに対して、クライアントとSIer両者の合意を得てから進まないと後から問題になりやすいということも挙げられます。

そのため、確実にステップを踏んでいくという開発手法が好まれるようになりました。

品質は絶対に譲れないケース

たとえば、銀行で動いているシステム、証券取引所で動いているシステム、携帯キャリアの通信システムなど、絶対に障害が発生してはいけないシステムというものが存在します。

これらは計算ミスや通信障害などが起きればお客様に大損害を及ぼしかねないものです。

そのため、徹底的にテストを行い、障害発生率をかぎりなく0％に近づけることが求められます。

ウォーターフォールモデルであれば、こういった要求にも耐えられる高品質なシステムを提供しやすいのです。

大規模プロジェクトのケース

あまりにも巨大なシステムを数人～数十人のメンバーで開発するのでは何年あっても足りません。

そういうときにはウォーターフォールモデルが有利です。

工程ごとに人員をアサインできるので、1番マンパワーが必要なタイミングで大量にリソースを導入し一気に開発を進めることができます。

まとめ

ウォーターフォールモデルというのは確かに日本のシステム開発を支えてきた手法で、現在でも多くのプロジェクトで採用されています。

業界のゼネコン構造や顧客の仕様変更などで苛烈な労働環境を生み出してきた一要因でもありますが、その手法が完全に間違っているわけでもありません。

また、昨今ではクラウド化によってシステム開発もある程度のスピード感を求められるようになってきています。

技術の進化に伴い、ウォーターフォールモデルも少しずつその姿を変えていくのではないでしょうか。