ソフトウェアの大規模化に伴い、予算やスケジュール、人員を適切に配置し、管理する「ソフトウェア開発手法」が考案されました。特に、PMBOK（Project Management Body of Knowledge）のようなプロジェクトマネジメントの手法がソフトウェア開発にも導入されたことで、その体系化が進みました。
ソフトウェア開発手法にはさまざまな手法がありますが、近年においては「ウォーターフォール開発（ウォーターフォールモデル：waterfall modelとも呼ばれる）」と「アジャイル開発」の2つの開発手法が主に使われています。
ウォーターフォール開発とアジャイル開発にはそれぞれの特徴があり、一概にどちらを採用すれば良いといったものではなく、開発の対象や目的、優先事項、制約などに応じて適切に使い分けることが重要です。
アジャイル開発については、当コラムの「あらためて、アジャイル開発とは｜その概要から進め方、メリット・デメリット、開発手法について」のなかで詳しく紹介していますので、本記事では、ウォーターフォール開発の概要やメリット・デメリットを中心に、アジャイル開発との違いやウォーターフォール開発の向き・不向きについてもわかりやすく解説をしていきたいと思います。
ウォーターフォール開発とは何か？
ソフトウェア開発手法の一つである「ウォーターフォール開発（waterfall development）」は、高級言語によるプログラミング環境が整備された1960年代に考案されました。ソフトウェアのニーズが高まった一方、大規模化によるソフトウェアの品質の低下やエンジニア不足といった課題が生じました。このため、予算やスケジュール、エンジニアを適切に配備するソフトウェア開発手法が検討されました。ウォーターフォール開発も、こうした開発手法の一つとして提唱されました。
ウォーターフォール開発の骨子は、プロジェクトの立ち上げからソフトウェアの開発までの「ソフトウェア開発ライフサイクル（SDLC: Software Development Life Cycle）」を複数の工程に区分し、上流工程から下流工程へと順番に進めていく点にあります。ウォーターフォールとは滝（Waterfall）を意味する英語で、まさに滝のように上流工程から下流工程へ作業が流れていくさまを表しています。
ウォーターフォール開発を構成する6つの工程
ウォーターフォール開発は、次の6つの工程から構成されます。工程数は論者によって異なるものの、基本的な考え方はほぼ変わりません。
なお、ウォーターフォール開発にはより高い品質を実現するための手法として、「V字モデル」「W字モデル」と呼ばれる開発・テストの手法があります。以下で紹介する工程は、基本的にW字モデルを採用した場合の工程になります。
それぞれのモデルについては以下の記事で紹介していますので、宜しければ併せて参照ください。
V字モデルとは｜ウォーターフォール型開発における品質面でのメリット
W字モデルとは：手戻り、抜け漏れを防ぎ、早めのテスト準備が可能に
要件定義（requirement definition）
ユーザーがそのソフトウェアを使って何をしたいのか、どのように使うのかといった情報をもとに、それらを実現するための機能やスペック、その他さまざまな基準や条件などを検討し明確化します。
ここでまとめられた内容は「要件定義書」として文書化されることが一般的です。
なお、要件定義の前工程として、ユーザーの要求を分析する「要求分析（Requirement Analysis）」を行うケースもあります。
成果物例…要件定義書、システム仕様書
基本設計
基本設計（外部設計：External Designとも呼ばれる）では要件定義書やシステム仕様書などの文書に基づき、基本的にユーザー目線からソフトウェアの仕様を設計します。開発を円滑化するために、ソフトウェアをサブシステムに分割していきます。
W字モデルでは、基本設計時に結合テスト仕様書も併せて作成します。
成果物例…基本設計書、外部仕様書、結合テスト仕様書
詳細設計
実装の観点からコード化するための指針を提供するのが、詳細設計（内部設計：Internal Designとも呼ばれる）です。オブジェクトをプログラムの最小単位である「モジュール（module）」に分割し、プログラムの「構造化設計（structured design）」を行います。
W字モデルでは、詳細設計時に単体テスト仕様書も併せて作成します。
成果物例…詳細設計書、インターフェース設計書、データベース設計書、内部仕様書、単体テスト仕様書
コーディング（Coding）
いわゆる実装工程です。詳細設計書に基づいて、プログラマーやエンジニアによってコーディング（プログラミング：Programmingとも呼ばれる）していきます。
成果物例…ソフトウェア
ソフトウェアテスト（Software Testing）
コーディングされたソフトウェアのテストを行います。単体テストや結合テスト、システムテスト、受入テストなど、上流工程で決定された要求や要件、仕様通りにプログラムが動作するかどうかをテスト仕様書に基づいて確認し、ソフトウェアの品質を評価・改善していきます。
成果物例…不具合チケット、テスト結果報告書
運用・保守（System Operation and Maintenance）
ソフトウェアテストが終了しソフトウェアがリリースされた後は、そのソフトウェアの運用・保守を開始します。有形プロダクトと異なり、ソフトウェア開発ライフサイクルは運用開始後も続きます。ソフトウェアの安定稼働やさらなる改善を目指し、基本的にはそのサービスが終了するまでバグの修正やアップデートといった運用・保守を継続的に行います。
ウォーターフォール開発のメリット
ウォーターフォール開発のメリットとして、各工程で満たすべき要件やゴール、作業が文書によって明確に定義されているため、プロジェクトの計画や進捗管理が容易であることが挙げられます。エンジニアは上流の工程で作成された成果物を確認しながら、各工程での作業を進めます。
また、基本的には各工程の成果物を厳格にレビューし、要件が十分に満たされてない場合は次の工程に進むことはできません。
これによって、各工程における成果物に対して一定の品質を担保できることもウォーターフォール開発のメリットの一つです。
またW字モデルにおいては、上流工程で作成された文書をもとにテストの戦略や計画の策定、テスト仕様書の作成が可能なため、実装前であっても最適なテストを準備することが可能こともメリットとして挙げられます。
このような体系化された手法により、ソフトウェア開発プロジェクトの計画や進捗の管理がしやすく、また品質を担保しやすいということがウォーターフォール開発のメリットと言えます。
ウォーターフォール開発のデメリット
ウォーターフォール開発のデメリットとして、何らかの理由により手戻り（rework）が発生してしまった場合にコストや時間を大きくロスしやすいという点が挙げられます。
例えば、結合テストにおいて不具合が検出され、その原因が基本設計書の誤りであった場合、基本設計書をもとに作成された詳細設計書にも誤りが混入している可能性があります。
その結果として、基本設計書の修正に加えて詳細設計書の修正や、単体・結合レベルのプログラムの修正が必要となることもあります。
このように、前工程に戻って作業をやり直すことを手戻りと言いますが、基本的に下流から上流に戻ることを想定していないウォーターフォール開発においては、手戻りが発生した場合の影響が大きくなりやすいというリスクがあります。
特にソフトウェアが大規模になるほど開発やテスト工程が複雑化し、下流工程で見つかる不具合によるスケジュールの遅延や予コストの増加がより深刻化する傾向にあります。そのため、各工程の検証を厳密に行うことが極めて重要です。
こうしたウォーターフォール開発の課題を解決する方法も提案されています。
たとえば、各工程での仕様書やプログラムなどの成果物を厳格にチェックする「ソフトウェアインスペクション」を行うことで、後の工程で不具合が発生するリスクや、その影響の軽減が期待できます。
特に、実装前の設計書の段階で不具合を検出・修正することができれば、その修正コストを大きく抑えることが可能です。もし設計段階で不具合を検出し修正できた場合、下流工程で対応するのに比べ数倍～数十倍のコストメリットがあると言われています。
このようにドキュメントに対するインスペクションによって不具合を早期に検出することは非常にメリットが大きいことから、リスクヘッジとしてインスペクションの実施を検討してみても良いでしょう。インスペクションについて、詳しくは以下の記事を参照ください。
バグの早期検出メリットとその方法｜インスペクションのすすめ
SHIFT ASIAのドキュメントインスペクション
またウォーターフォール開発においては、上流工程で要求や要件を定義した上で設計に進み、原則として前工程に戻らないという性質があることから、開発途中での要求や要件の変更への対応がしにくいということもデメリットの一つとして挙げられます。
したがって、開発プロジェクトの途中でユーザーニーズやトレンド、その他さまざまな環境が変化してしまい、ソフトウェアが完成する頃には前提としていた要求や要件自体が環境にそぐわないものになってしまうということも起こり得ます。
したがって、マーケットやニーズの変化が激しく、開発の途中で要求や要件が変わる可能性が高いソフトウェアの開発においては、基本的にウォーターフォール開発を採用しない方が良いと言えます。
しかしながら、ウォーターフォール開発自体もこうした課題を解決すべく改良されています。
たとえば、システムを分割し反復しながら機能や品質を点検し、段階的に全体を統合していく「反復型開発」や、プロトタイプを設計しユーザー企業からのフィードバックを経たうえで、ソフトウェアを段々とプロダクトに近づけていく「スパイラルモデル（Spiral Model）」といった派生形のソフトウェア開発手法が提案されています。
アジャイル開発がより一般的な開発手法となりつつある昨今において、ウォーターフォール開発というと古い開発手法であると見られることもありますが、ウォーターフォール開発においてもその手法はより洗練され、今もなお進化を続けているのです。
ウォーターフォール開発とアジャイル開発との違い
では、ウォーターフォール開発とアジャイル開発との違いはどこにあるのでしょうか。
アジャイル開発とは、一般的にプロジェクトを「イテレーション（iteration）」という1～4週間程度の短い工期になるように細かく区分し、各イテレーションで要件の定義から計画・設計・開発・テスト・リリースという一連のサイクルを繰り返すことで、最終的なプロダクトのリリースに至る開発手法を指します。
アジャイルソフトウェア開発宣言でも言及されているように、開発プロジェクトの途中においてもユーザーやステークホルダーとのコミュニケーションを通じて要望を取り入れるなど、協調や変化への対応により重きを置くソフトウェア開発手法だと言えます。
＜関連記事＞
あらためて、アジャイル開発とは｜その概要から進め方、メリット・デメリット、開発手法について
アジャイルソフトウェア開発宣言と、その背後にある12の原則を読み解く
アジャイル開発が考案されて以降、ウォーターフォール開発とアジャイル開発のどちらが優れているのかという議論が一部で続けられてきました。しかしどちらの開発手法が絶対的に優れているというわけではなく、それぞれの開発手法の特徴を理解したうえで、適切な開発手法を採用することが重要です。
そこでウォーターフォール開発とアジャイル開発の違いを、アプローチ、柔軟性、要求事項、予算の4点から整理していきましょう。
アプローチ
ウォーターフォール開発では、プロジェクトの最初の段階で要求や要件を定義し、そのプロジェクトにおいて作るものを明確に定義します。そしてリリースまでの計画や成果物、満たすべき基準などを決定します。それぞれの工程で作成された成果物に対しては厳格なレビューが行われ、不十分な場合は次の工程に進むことはできません。
そしてまた、水が上から下にしか流れないように、原則として一度終わった工程には戻ることがありません。
一方、アジャイル開発では、ソフトウェア完成までのプロセスが短期間の「イテレーション」に分割されます。要求や要件の定義から設計、開発、リリースまでを1度だけではなく何度も繰り返します。
要求事項
ウォーターフォール開発の場合、要求事項は要件定義書やシステム仕様書に反映されます。ウォーターフォール開発では、原則として一度定義した要求や要件は変更しませんが、もし開発工程の途中で要求や要件の変更を行なう場合は、工程が進んでいればいるほど手戻りによる工数やコストが大きくなる傾向にあります。
一方アジャイル開発の場合、上で述べたように開発チームは比較的短い期間で設定されたイテレーションを通じて、小さなリリースを何度も繰り返します。最初に決めた要求や要件に向けて一度ですべてを作りきるわけではないため、開発の途中であったとしてもそれらの変更に対応しやすいと言えます。
したがって、要求や要件の変更にともなう手戻りは、ウォーターフォール開発に比べて小さくなる傾向があります。
柔軟性
両者のアプローチの違いは、ソフトウェア開発マネジメントの違いにも現れます。
ウォーターフォール開発の場合、計画時にスケジュールや予算、作業など最終段階までのスケジュールを決定します。そのため開発工程の途中で要求や要件、仕様、スケジュール、体制などを当初計画から変更しにくく、柔軟性という面では弱いと言えるでしょう。
これに対してアジャイル開発の場合、イテレーションごとに要求や要件を取り入れたり見直したりしやすく、たとえば、新しく登場した技術や最新のニーズやトレンドを取り入れるなど、柔軟性の高いソフトウェア開発を行いやすいと言えます。
予算
上述したように、ウォーターフォール開発の場合、最初の段階で全体の工数やスケジュール、予算がある程度固く見積もられます。そのため、よほど予想外のことが起きない限り、全体の費用が当初見積もりから大幅に変化する余地は比較的小さいと言えます。
一方アジャイル開発の場合、全体の工程を細分化し、プロジェクトの途中においてもプロダクトをより良いものにするため柔軟に新たな要素の追加や修正などを行っていきます。
よってはじめに全体の工数を見積もることが難しく、また見積もったとしても状況によって変動しやすいため、スケジュールや予算が可変的と言えます。
ウォーターフォール開発の向き不向き
ウォーターフォール開発が向くケース
ウォーターフォール開発が向くケースとして、金融システムのように開発期間が比較的長く、かつ高い品質が求められる大規模ソフトウェアが挙げられます。また、あらかじめ要求事項が固定されており、原則として変更されないようなソフトウェア開発に向いています。
とはいえ、ウォーターフォール開発だからといって不具合のないソフトウェア開発が可能というわけではありません。実際に、昨今明らかになった金融システムのトラブルは、ウォーターフォール開発で開発したでも不具合が起こりうることを示しています。
しかしながら、各工程において定められた基準をクリアして初めて次の工程に進むというアプローチを取るウォーターフォール開発は、アジャイル開発に比べてより高い品質を担保しやすい開発手法と言えるでしょう。
ウォーターフォール開発が向かないケース
ウォーターフォール開発が向かないケースとして、ターゲットとする市場やニーズの変化が多く、またその辺かがスピーディーな場合や、ユーザーからのフィードバックを取り入れながら開発を進めるような、開発工程の途中での変更が多く発生するソフトウェア開発が挙げられます。
このようなソフトウェアを開発する場合や、特にPoC（Proof of Concept：概念実証）やMVP開発を行う場合は、柔軟性が高く変更に強いアジャイル開発の方が向いていると言えるでしょう。
PoCとは～目的やステップをご紹介～
MVP開発とは｜そのメリットと開発のポイント
SHIFT ASIAのPoC/MVP開発
おわりに
アジャイル開発が主流の開発手法となりつつある近年において、ウォーターフォール開発は時代遅れの開発手法であるとみなされることもありますが、ウォーターフォール開発にも明確な利点があり、またアジャイル開発にもデメリットはあります。
ウォーターフォール開発とアジャイル開発は、どちらが必ずしも優れているというわけではなく、どちらの開発手法を採用すべきかという問いには絶対的な答えは存在しません。
本記事でも紹介したとおり、一般的にはウォーターフォール開発はプロジェクト開始後の変更が少なく、高い品質を担保しやすいという特徴があることから、変化に対する柔軟性を重視しない場合はウォーターフォールの方が適していると言えます。
一方で、開発の途中での変更が見込まれる場合や、ユーザーからのフィードバックを得ながら開発を進めていきたい場合はアジャイル開発の方が適しているでしょう。
それぞれの開発手法にはメリット・デメリットがあり、一長一短の開発手法であるということを理解した上で、開発手法を適切に見極めることが重要です。
私たちSHIFT ASIAでは、お客様が実現したいことに対しての丁寧なヒアリングを通じ、ウォーターフォール開発あるいはアジャイル開発どちらの開発手法がより適しているのかを考慮した上でご提案をいたします。
また、ウォーターフォール開発からアジャイル開発への移行についてもご支援をしております。
詳しくは、こちらまでお気軽にお問い合わせください。
お問い合わせContact
ご不明点やご相談などがありましたら、お気軽にお問い合わせください。
