システムやアプリなどのプロダクトの開発において「ウォーターフォール型はもう時代遅れだ」といわれることがあります。

滝の流れ（ウォーターフォール）のように上から下へと一方通行で開発を進めるウォーターフォール型開発は、作業を後戻りさせることができないため、臨機応変な対応ができるアジャイル開発より劣ると考えられるようになりました。

しかし、大規模プロダクトの開発では依然としてウォーターフォール型が使われています。

この記事では、ウォーターフォール型開発がどのようなものであるかを解説したうえで、これに向いているプロダクトと向いていないプロダクトを紹介します。さらにメリットとデメリットも解説するので、ぜひ参考にしてみてください。

ウォーターフォール型開発とは

プロダクト開発は、要件定義→基本設計→詳細設計→コーディング→テストの順に進みますが、この順番どおりに進めるのがウォーターフォール型開発です。

かつてはこれが当たり前でしたが、アジャイル開発が登場したことでウォーターフォール型開発の欠点が強調されるようになりました。

「要件定義→基本設計→詳細設計→コーディング→テストの順に進む」とは、要件定義が終わらなければ基本設計に進まず、基本設計が終わらなければ詳細設計に進まない、という意味です。

それぞれの工程は、開発責任者と開発メンバーとクライアントが合意できたときに終了して次の工程に進みます。

ウォーターフォール型開発には V 字モデルがよく採用されます。

開発工程のコーディングが終了すると次はテストに入るわけですが、テストは単体テスト→統合テスト→総合テスト→受け入れテストと進みます。

そして受け入れテストは要件定義のチェックであり、結合テストと総合テストは基本設計のチェックであり、単体テストは詳細設計のチェックとなっています。

この関係が上記のイラストのように V 字になっているのでそのように呼ばれています。

ウォーターフォール型開発の将来性

ウォーターフォール型開発は消滅したわけではありませんが、それでも「時代遅れ」「将来性がない」といわれてしまうのはなぜでしょうか。

昔のシステムやアプリはできることが少なく、性能も高くありませんでした。

機能が少なく性能が低いシステムやアプリの開発はとてもシンプルなので、要件定義→基本設計→詳細設計→コーディング→テストの順に進めていても納期内に完成させることができます。

したがって、ウォーターフォール型開発でも支障がありませんでした。

しかし現代のシステムやアプリは機能がたくさん搭載され、しかも高性能です。そうなると初期の定義や設計を開発途中（コーディング途中）で変更する機会も増えてきます。

ところがウォーターフォール型開発は、途中で基本設計に戻ったり要件定義に戻ったりすることがとても大変です。それでは、目まぐるしく変化する市場の要望に対応することができません。

それで柔軟に開発を進めていくことができるアジャイル開発が誕生し、こちらが主流になっていったのです。

アジャイル開発については後ほど解説します。

ウォーターフォール型開発が向いているケース

時代遅れと揶揄されてもウォーターフォール型開発が残っているのは、今でもこれでしかつくることができないプロダクトがあるからです。

例えば、品質最優先でつくらなければならないシステムは、ウォーターフォール型開発に向いています。

ウォーターフォール型開発なら、開発責任者、開発メンバー、クライアントが各工程の進捗状況と完成度を慎重に確認しながらシステムをつくり込んでいくことができます。

この 3 者が納得して OK を出した工程は間違いのない状態になっているはずです。ウォーターフォール型開発なら妥協のないつくり込みが可能です。

そして大規模システムを構築するときもウォーターフォール型開発が採用されます。

例えばインフラを制御するための大規模システムの場合、要件定義や基本設計を確定しておかないと先に進めなくなります。

そして一度確定した要件定義や基本設計は、よほどのことがない限り変更、修正、追加、削除をしません。

工程を後戻りすることがほとんどないので、ウォーターフォール型開発のデメリットが出にくいのです。

仕様変更が起きないのであれば、ウォーターフォール型開発のほうが作業の流れがシンプルなのでこれを採用するメリットが大きくなります。

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

ウォーターフォール型開発の特徴は、アジャイル開発と比べるとより明らかになるでしょう。

ウォーターフォール型開発の特徴 アジャイル開発の特徴
要件定義が定まっているプロダクトに向いている 要件定義があまり定まっていないプロダクトに向いている
方向性が途中で変わらないプロダクトに向いている 方向性が途中で変わる可能性があるプロダクトに向いている
クライアントが開発に携わらないプロダクトに向いている クライアントが開発に携わるプロダクトに向いている
品質最優先、大規模、シンプルなプロダクトに向いている 納期優先、小中規模、複雑、多機能なプロダクトに向いている

アジャイル開発でも「要件定義→基本設計→詳細設計→コーディング→テスト」の順に開発を進めるのは同じなのですが、こちらではプロダクトに搭載される複数の機能のうち、 1 つの機能を「要件定義→基本設計→詳細設計→コーディング→テスト」でつくってしまいます。

例えば開発チームを 2 つのグループにわけます。そしてグループ A に機能 A をつくらせ、グループ B に機能 B をつくらせます。

続いてグループ A が機能 C をつくり、グループ B が機能 D をつくり、最終的に機能 A 、 B 、 C 、 D を統合して 1 つのシステムにします。これがアジャイル開発です。

＜アジャイル開発の概念図＞

機能A 要件定義→ 基本設計→ 詳細設計→ コーディング→ テスト
機能B 要件定義→ 基本設計→ 詳細設計→ コーディング→ テスト
機能C 要件定義→ 基本設計→ 詳細設計→ コーディング→ テスト
機能D 要件定義→ 基本設計→ 詳細設計→ コーディング→ テスト

一方のウォーターフォール型開発は、機能 A 、 B 、 C 、 D すべての要件定義が終わったら機能 A 、 B 、 C 、 D すべての設計に移り、その次に機能 A 、 B 、 C 、 D すべてのコーディングに入る、という進め方をします。

＜ウォーターフォール型開発の概念図＞

要件定義→ 基本設計→ 詳細設計→ コーディング→ テスト
機能A、B、C、D 機能A、B、C、D 機能A、B、C、D 機能A、B、C、D 機能A、B、C、D

アジャイル開発なら、もしクライアントが機能 A について要件定義からやり直したいと要求しても、 B 、 C 、 D の開発を継続させることができます。

また、クライアントから機能 E を追加して欲しいといわれても、新たな開発ラインを設置すればよいだけです。

しかしウォーターフォール型開発ではそうはいきません。

機能 A の要件定義が固まらないと、すでに要件定義が決定している B 、 C 、 D も基本設計に進めません。

▼アジャイル開発についての詳細はこちら

「アジャイル開発」の内部リンクへ誘導

ウォーターフォール型開発のメリット

それではもう一度ウォーターフォール型開発に着目していきます。この開発手法のメリットとデメリットをみていきましょう。

先にメリットを紹介します。

全体のスケジュール・予算を把握しやすい

ウォーターフォール型開発では、一度決めた要件定義を開発途中で動かすことがないので、スケジュール管理や予算管理がしやすくなります。

システム開発を発注するクライアントが明確に「こういったシステムが欲しい。機能はこれしか要らない」というビジョンを持っていれば、ウォーターフォール型開発のほうが早く完成するかもしれません。

その代わり、クライアントには一度決めた要件定義を変更しないことと、機能の追加も機能の削除も求めないことを開発チームに約束する必要があります。もちろん例外規定を設けることはできますが、原則変更できないことになります。

クライアントにもメリットがあります。ウォーターフォール型開発なら、「想定していたより開発コストがかかってきたので予算を増額しなければならない」といった事態が起きにくくなります。望んだものが望んだとおりに望んだ金額で出来上がってくるイメージです。

さらにいえば、スケジュールや予算が固定されている場合は、そもそも要件定義を変更することができないので、それならばウォーターフォール型開発で開発したほうがよい、と判断することができます。

行政機関のシステムの場合、スケジュールも予算も、そしてシステムの概要も、議会や役人が最初に決めてしまうので、ウォーターフォール型が向いている場合が多いです。

品質を担保しやすい

品質最優先のプロダクトでウォーターフォール型開発が採用されるのは、品質を担保しやすいからです。

ウォーターフォール型開発では工程の後戻りができないため、 1 つの工程を完了させる前に不具合やバグや要件漏れがないか徹底的にチェックします。これはつくり込みの徹底にもつながり、品質が高くなります。

最近のシステムやアプリのなかには、利用を開始したあとに多少の不具合が出ることを許容しているものもあります。実証実験やβ版は、 100 ％完璧でなくてもとりあえず世の中に出してしまい、使い勝手を調べたり不具合を洗い出したりして煮詰めていく手法です。

しかし重要インフラの制御に使うシステムは、実証実験やβ版で試すことはできません。利用開始時から 100 ％のパフォーマンスを発揮できるプロダクトにするには、いまだにウォーターフォール型開発のほうがアドバンテージがあります。

ウォーターフォール型開発のデメリット

ウォーターフォール型開発のデメリットを考えてみます。

開発途中の仕様変更が難しい

開発途中で仕様変更や要件定義変更ができないことは、ウォーターフォール型開発の最大のデメリットといってよく、そのために「時代遅れ」のレッテルが張られてしまいました。

もしウォーターフォール型で開発しているときに「どうしても」仕様変更しなければならなくなったら、全体を後戻りさせなければならなくなり、そのコストは莫大なものになります。そして納期は大幅に遅れるでしょう。

ウォーターフォール型開発では、クライアントが開発途中のプロダクトを確認してからいろいろなアイデアを盛り込みたいと思ってもそれはできません。

もしクライアントが開発途中で柔軟な対応を求める場合は、アジャイル開発の一種であるスクラム開発という手法がおすすめです。

こちらの記事で詳しく解説しているので参考にしてみてください

▼「スクラム開発」の内部リンクへ誘導

成果物の完成に時間がかかる

ウォーターフォール型開発では、各工程において成果物をクライアントに提出することになります。各工程の成果物は報告書の形になることが多いので、開発チームは事務処理が増えます。

そしてクライアントは、 1 つの工程の完了を了承してしまうと後戻りできないので、その報告書をしっかり読み込む必要があります。そして要件定義どおりに進んでいるかどうか確認します。

こうした作業が 1 つの工程が終わるごとに発生するので、ウォーターフォール型開発は完成までに時間がかかります。

ウォーターフォール型開発の手順

ウォーターフォール型開発は次のような手順で進めます。

  1. 要件定義
  2. 基本設計
  3. 詳細設計
  4. コーディング（実装）
  5. 単体テスト
  6. 結合テスト
  7. 総合テスト
  8. 受け入れテスト

それぞれの工程で何をするのか解説します。

要件定義

ここでいう要件とは、システムやアプリなどのプロダクトに盛り込む要件のことです。

要件定義が重要になるのは、クライアントがプロダクトについて詳しくないことが多いからです。クライアントがプロダクトに精通していれば、例えば「この業務を自動化するならこのようなシステムが必要になる」ということがわかるので、要件はすぐに定義できます。

しかし多くのクライアントは「自動化したい業務」は把握していても、「どのようなシステム」を使えばよいのかや、そのシステムに「どのような機能」を搭載しなければならないかはよくわかっていません。

開発チームの責任者はクライアントにヒアリングをしてニーズを引き出し、そのためにどのようなプロダクトや機能が必要なのか説明し、それをつくる承諾を得なければなりません。

クライアントにヒアリングをしたら、開発責任者は要件定義書をつくり「この機能を盛り込んだこのシステムをつくればこの作業を自動化できる」といったことをクライアントに示します。

ここで齟齬が生じると後工程で混乱することになるので、要件定義はウォーターフォール型開発で最も重要な作業といえるかもしれません。

基本設計

基本設計は、要件定義の内容を満たすプロダクトをどのようにつくっていくかを決める工程です。

つくる機能、使用するソフトウェアやハードウェアを決めていきます。

基本設計の内容も基本設計書という書面にして、開発チームとクライアントで共有します。

詳細設計

プロダクトに搭載する機能が多岐に渡ったり、高度なものだったり、複雑なものだったりすると、基本設計だけでは開発メンバーがつくれない場合があるため、そのときは詳細設計をつくります。

その後、開発メンバーは詳細設計を元にコーディングしたりプログラミングをします。

開発（コーディング）

詳細設計が固まればコーディングに移ります。これを実装と呼ぶことがあります。

実装が終わると、プロダクトが動き始めます。

単体テスト

単体テストはプロダクトのなかの 1 つの機能をチェックする工程です。

例えば 10 個の機能がプロダクトに搭載されていたら、単体テストを 10 回行うことになります。

結合テスト

単体テストで不具合を潰すことができたら、すべての機能を結合したテストを行います。

機能 A だけを動かしたときや機能 B だけを動かしたときはエラーが出なくても、機能 A と機能 B を連携させて動かすとエラーが出ることがあります。

そのようなエラーをこの結合テストでなくしていきます。

総合テスト

総合テストは、結合テストより大規模なテストになります。

例えばシステムでは、少ないデータの処理では不具合が出ないものの、大量のデータを処理するとエラーが出ることがあります。総合テストでその不具合をなくしていきます。

受け入れテスト

受け入れテストでは、実際にクライアントの担当者にプロダクトを扱ってもらいます。

またこのテストで使うデータは、クライアントが実際のビジネスで使っている「本物」です。

受け入れテストで不具合が出なければ、そのまま納品となり、プロダクト開発は完了します。

まとめ

ウォーターフォール型開発が時代遅れとみなされるのは、やむをえないところがあります。システムもアプリもものすごいスピードで開発され、世に出され、そして陳腐化していきます。

そのためプロダクト開発ではスピードが求められるようになり、ウォーターフォール型開発ではそのニーズに応えることができません。

若いプログラマーやエンジニアのなかには、ウォーターフォール型開発をしたことがない人もいるでしょう。新興のシステム会社のなかにも、ウォーターフォール型開発案件を手がけたことがないところがあるかもしれません。

しかしウォーターフォール型開発は今でも存在し、これでしかつくることができないプロダクトをつくっています。

そのためウォーターフォール型開発に携わった経験は、逆に強みになるかもしれません。