ウォーターフォールモデルとは？メリットやアジャイル開発との比較を徹底解説

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

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

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

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

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

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

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

ちなみに、確認することを「レビュー」といい、合意されたら印鑑を押印し完了となります。

そして、絶対に前の工程に戻らないことが鉄則です。

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

品質を作り込むV字モデル

下図のように「実装・単体テスト」を中心に見ると、

• 左側：要件定義や設計を行う工程で上流工程と呼ばれる
• 右側：検証（テスト）を行う工程で下流工程と呼ばれる

と見ることができます。

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

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

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

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

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

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

後述しますが小回りが聞くため、社内開発に向いています。

設計に対する検証のV字構造で表現し品質を確保できる

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

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

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

原則として仕様変更はなく工程の後戻りはない

ウォーターフォールモデルでは原則として仕様変更が認められません。

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

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

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

ウォーターフォールモデルの特徴は工程の厳格な管理

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

すべての工程に抜け、漏れがないかを徹底的に検証しながら進めていきます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ITゼネコンの構造上、大手がキャリア・待遇ともに有利です。このあたりについては「ITゼネコンとは？下請け構造から見える課題を現場視点で解説！」で詳しく解説していますので合わせてご覧ください。

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

ウォーターフォールは請負開発の契約に適していることも特徴としてあげられます。

納品物や責任範囲、スケジュールが明確にできるためです。

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

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

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

ウォーターフォールモデルの工程をわかりやすく解説

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

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

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

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

工程	説明	成果物	別名
要件定義	システム全体の機能の策定	要件定義書	–
基本設計	基本設計書	基本設計書	外部設計
詳細設計	詳細設計書	詳細設計書	内部設計
実装	プログラミング	プログラムコード	PG、製造、開発
単体テスト	機能単体の性能評価	エビデンス	プログラムテスト
結合テスト	複数機能の連携評価	エビデンス	–
総合テスト	システム全体の性能評価	エビデンス	システムテスト
受入テスト	本番環境へのシステム導入	システム本体	導入テスト

ウォーターフォールモデルはしっかりと作業を進められる開発手法ですが、メリット・デメリットも存在します。

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

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

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

メリットはQCDの管理がしやすい

QCDとは

のことです。

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

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

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

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

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

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

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

工程により分業化をしやすい

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

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

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

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

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

デメリットは仕様変更の弱さと工程による専業化の副作用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ウォーターフォールモデルとアジャイルの比較

ウォーターフォールモデルとアジャイルの違いを比較してみましょう。

アジャイルとは？よく利用されるスクラムを紹介！

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

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

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

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

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

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

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

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

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

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

ウォーターフォールモデルとアジャイルの比較

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

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

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

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

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

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

筆者がSIerからWeb系に転職したときに感じたウォーターフォールとアジャイルの違いを「SIerからWEB系に転職して7年経ったので比較してみた」にまとめています。

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

ウォーターフォールモデルが有利で利用されるケース

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アジャイルが有利で利用されるケース

今度はアジャイルが向いているのは以下のようなケースを見ていきます。

ビジネスの運用に合わせて仕様が常に変わるケース

システムとしての方向性、必要性は定まっているものの、その後の運用は確定しないケースというのがあります。

こういう場合、仕様がその都度変更になる可能性が大きいです。

こういう場合はアジャイルで開発したほうが柔軟に対応できるでしょう。

社内のITエンジニアに開発を依頼するケース

社内エンジニアというのはそこまで人数が揃っているケースは少ないです。

そうなると開発に時間も人数もかけることが難しくなります。

そのため、まずは作ってみて改良を加えていくというアジャイルの進め方は相性が良いのです。

短期間でリリースを求めるケース

とにかく動くシステムを求める場合はまさにアジャイルにうってつけです。

短期間でシステムをリリースできるので、ビジネスチャンスを逃さずにスタートを切ることが可能になります。

あとは、ユーザーの反応を見ながら適宜改良していくことになります。

まとめ

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

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

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

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