エンジニア全般
新しくソフトウェアを開発したい場合や、既存のソフトウェアを修正・更新したい場合は、「プロジェクト」と呼ばれる一連の活動や作業の計画を立てる必要があります。
ソフトウェアを開発するためのプロジェクトを結成したとしても、肝心のソフトウェアをどうやって開発するのかが決まっていなければ、プロジェクトを結成した意味がなくなってしまいます。
今回は、ソフトウェアを開発するための手法のひとつであるウォーターフォールモデルの、特徴、開発の流れ、メリット・デメリットに加え、アジャイル開発との違いや適しているプロジェクトについても、順番に解説を行います。
食品商社営業からシステムエンジニアへと転職後、バックエンドエンジニア（Java, PHP）として尽力。開発リーダーを含む上流工程〜下流工程に携わる。IT関連記事から芸能・法律など幅広ジャンルにて執筆。
ウォーターフォール開発モデルとは？特徴4選
ウォーターフォールモデルとは、開発の各工程が終了したら次の工程に進み、原則として前の工程には戻らない開発手法です。
「ウォーターフォール（Waterfall）」とは日本語で滝のことを意味します。
滝は上から下に水が流れ、下に流れてしまった水は上には戻りません。
滝と同じように、次の工程に進んだら前の工程には戻らないという開発の流れのため、ウォーターフォールモデルと呼ばれています。
段階的な進行
ウォーターフォールモデルでは、段階的に開発を行います。
以下の6つの工程に分かれており、各工程は必ず前の工程が終了した後に開始します。
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
進捗は一方向のみ
ウォーターフォール開発モデルでは、各工程の作業が終了し、次の工程の作業が開始された場合は、原則として前の工程の作業に戻ることはありません。
現在の進捗や目的が明確になり計画を立てやすいですが、一度終えた工程に戻るには大きなコストが掛かります。
工程ごとにドキュメントを作成
要件定義では要件定義書、
基本設計では基本設計書、
詳細設計では詳細設計書、
・・・というように、各工程の作業ごとにドキュメントを作成します。
すべての工程でドキュメントが作成され記録されるため、品質の高いシステムを組み上げることが可能です。
ソフトウェア開発の関係者とのやり取りは初期の段階のみ
ウォーターフォールモデルでは、各工程の作業が終了したら次の工程の作業を開始するという特徴があるため、
ソフトウェア開発を依頼してきた人など、関係者とのやり取りは初期の段階のみとなります。
要件定義の段階でしか関係者とやり取りをしないため、完成したソフトウェアに対して修正・変更を加えたい場合は、
再度ソフトウェア修正・変更のプロジェクトを結成する必要があります。
ウォーターフォールモデルのメリット
ここからは、ウォーターフォールモデルを採用することのメリットを解説します。
進捗管理の容易さ
ウォーターフォールモデルは、以下の6つの工程に分かれており、前の工程が終了したら次の工程に進みます。
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
工程がはっきりと区別され、順々に進むため進捗管理がしやすくなっています。
また、どの工程をいつまでに終わらせるのか計画を立てて実際の進捗と比べることで、進捗が進んでいるのか遅れているのか分かりやすくなっています。
例えば進捗が進んでいる場合は、ソフトウェアが完成する予定日を前倒しにすることも可能です。
逆に進捗が遅れているならば、予定日の延期や実装する予定の機能を削るなど、事前に対策を取ることができます。
品質担保がしやすい
前の工程が終わったら次の工程に進むという原則によって、その工程で求められている品質まで開発が進んだら、ドキュメントを作成し、次の工程に進む・・・といったようにプロジェクトの流れが明確になります。
そのため、ウォーターフォールモデルでは品質の担保がしやすくなっています。
工程ごとにドキュメントを作成し、前工程で何があったかが明確であるため、後から見直した際やトラブルがおきた際にも必ず前工程のドキュメントを参照することができます。
効率的なリソース配分
ソフトウェアを開発したい場合、「いつまでに」「どれくらい」が完成の予定日を決める非常に重要な要素となります。
ウォーターフォールモデルを採用した場合は、開発工程が決まっていますので、ある程度完成予定日から逆算し、計画を立てることができます。
どの工程にどれくらい時間をかけられるのかがわかりやすいため、リソース配分を効率的に計画できます。
関係者とコミュニケーションが取り易い
ウォーターフォールモデルでは、関係者とのやり取りは主に初期段階で行われます。
また、各工程の作業が終了した時、作成したドキュメントを関係者に確認してもらい、フィードバックを受け取ります。
工程の作業が終了するごとに関係者と連絡を取るため、関係者の視点でも進捗が分かりやすいことが特徴です。
ウォーターフォールモデルのデメリット
続いては、ウォーターフォールモデルのデメリットを解説します。
柔軟性が低く、仕様変更が難しい
ウォーターフォールモデルは、要件定義の工程でのみ関係者とやり取りを行い、ソフトウェアに実装する機能を決定します。
そのため、要件定義の工程が終了した後、「やっぱりこの機能が欲しい」「あの機能はいらない」と要望があったとしても対応できません。
要件定義の工程で決まった機能でソフトウェアが開発されるため、後から機能の追加・削除ができないのです。
もし機能の追加・削除を行いたい場合は、新たにプロジェクトを結成して機能の追加・削除を行います。
リリースまでの時間が長い
ウォーターフォールモデルでは、全工程が終了して初めてソフトウェアがリリースされます。
そのため、どのようなソフトウェアになったのか、関係者は開発の最終工程までわかりません。
最悪、想定とは全く違うソフトウェアが出来上がる可能性もあります。
リスクとコストが大きい
ウォーターフォールモデルは、開発工程が厳密に決まっており、順番に沿って開発します。
開発が始まってからリリースするまでの時間が長いこともあり、後戻りには多大なコストがかかります。
また、要件定義や基本設計など、開発の初期の工程でミスや間違いがあった場合、それ以降の工程すべてに影響を及ぼします。
ソフトウェアが完成してからミスや間違いに気が付いても、修正するには莫大なコストと時間がかかります。
ミスや間違いに対するリスクが大きく、開発コストが大きくなってしまうのが特徴です。
ウォーターフォールモデルとアジャイル開発の違いを比較
| 項目 | ウォーターフォール | アジャイル開発 |
| 開発工程の違い | 連続した段階を経て一方向に進む。各段階が完了してから次の段階が始まる。 | 反復的でインクリメンタルなアプローチを採用し、短いサイクルで設計からテストまでを繰り返す。 |
| チーム構成と役割 | 各段階ごとに異なる専門家が担当。要件定義者は後の開発段階には関与しないことが多い。 | 小規模なチームが全工程を通じて協力し、柔軟に役割を交換。全員が設計、コーディング、テストに関与可能。 |
| プロジェクト管理 | プロジェクトの初期に全体の計画を立て、変更が難しい。計画通りに進行することが前提。 | 開癲中に新しい要望や変更があれば計画を柔軟に調整。プロジェクトの進捗に応じて方針を変えることが可能。 |
| 受注者との関係 | 初期の要件定義で受注者とのやり取りを行い、その後は進捗報告のみ。ソフトウェアはテスト終了後に受け渡し。 | 開発の各ステージで受注者と密接に連携し、フィードバックを受けながら進める。頻繁にデモやレビューを行う。 |
ウォーターフォールモデルはアジャイル開発とどのような違いがあるのでしょうか？
- 開発工程の違い
- チーム構造と役割
- プロジェクト管理
- 受注者との関係
の4つについて、それぞれ解説します。
開発工程の違い
ウォーターフォールモデルでは、要件定義～保守・運用の各工程を一切後戻りなしに順々に開発します。
アジャイル開発では、設計～テストを短いスパンで繰り返し、何度も顧客からフィードバックを受け、要望がある度に追加変更を繰り返すという方法で開発を進めます。
チーム構成と役割
ウォーターフォールモデルでは、要件定義、基本設計、詳細設計、コーディング、テスト、と各工程ごとに別の人が担当します。
そのため、専門職の分業が一般的です。
例えば、要件定義を行った人は、基本設計やコーディングなど、次の工程に作業が移った場合には開発に参加しないことが多いです。
アジャイル開発では、設計、コーディング、テスト、それぞれの専門職が1つのチームを構成します。
要望がある度に、チーム全員で開発を行い、柔軟に担当を変更しながら開発を行います。
設計担当がコーディングやテストに参加することもあります。
プロジェクト管理
ウォーターフォールモデルでは、初期段階にプロジェクト全体の計画を立て、その計画通りに開発を進めるため、初めに立てた計画通りにすべての物事が進行します。
一方で、アジャイル開発では新しい要望があれば計画を柔軟に変更し、ソフトウェアに変更を加えながら開発を進めます。
受注者との関係
ウォーターフォールモデルでは、最初期の段階で受注者を始めとする関係者と密接にやり取りを行い、その時点で要望を明確な要件として定義します。
それ以降は、開発の進捗状況の報告は行われますが、実際に開発されたソフトウェアを確認できるのはすべての工程が終了した後となります。
そのため、ほとんどの期間において顧客が確認するのは作成されたドキュメントや進捗状況の報告のみであり、フィードバックは実際にソフトウェアがリリースされるまで行いません。
一方でアジャイル開発では、一つの機能を実装するごとに関係者とやり取りを行い、ソフトウェアを渡してフィードバックを受けます。
こまめに関係者とやり取りを行うので、関係者の要望通りのソフトウェアを開発することができます。
ウォーターフォールモデルの開発工程
ここからは、ウォーターフォールモデルの開発工程についてひとつずつ解説します。
要件定義
要件定義では、「どのような機能のソフトウェアを開発したいのか」を定義し、ドキュメントにまとめます。
そして、その定義された要件がまとめられたドキュメントを要件定義書といいます。
要件定義書には、以下の3つを意識して記載します。
- 何ができるのか
- 何ができないのか
- どのような環境で動くのか
要件定義については下記の記事でも詳しく扱っていますので、ぜひ合わせてご参照ください。
基本設計
基本設計では、「ソフトウェア全体をどのような構造にするのか」を設計し、ドキュメントにまとめます。
ソフトウェアの構造がまとめられたドキュメントをアーキテクチャ設計書といいます。
アーキテクチャとは構造という意味で、アーキテクチャ設計書とはまさに開発全体の構造を決める設計書となります。（基本設計自体のことをアーキテクチャ設計という場合もあります。）
アーキテクチャ設計書には主に2つの要素を中心に記載します。
- ソフトウェア全体の構造
- 画面遷移
基本設計については下記の記事でも詳しく扱っていますので、ぜひ合わせてご参照ください。
詳細設計
詳細設計では、「ソフトウェアに実装したい機能の中身」と設計し、ドキュメントにまとめます。
機能ごとの中身についてまとめられたドキュメントを詳細設計書といいます。
詳細設計書には、主に以下の2点を中心に記載します。
- 機能の処理の流れ
- エラーが起きた場合の処理
コーディング
詳細設計が完了したあとは、詳細設計書に沿って実際のコーディングを行います。
すべての設計は詳細設計の段階で終わっているので、ドキュメントに書かれている内容をそのままプログラミングに落とし込みます。
そのため、詳細設計がしっかり行われているほどコーディングが楽になり、人的ミスやシステムバグが減ります。
テスト
コーディングを行って完成したソフトウェアが、作成したドキュメントに書かれている通りに動くかどうか確認します。
テストは単体テスト、統合テスト、システムテストの3種類のテストを行います。
- 単体テスト
- 機能ごとに正しく動作するか
- 例えばロボット開発で言えば、「手」や「腕」がそれぞれ正常に動くことの確認を行います。
- 統合テスト
- 機能と機能の繋がりの確認
- 例えばロボット開発で言えば、手と腕をひとつに合わせて、「片腕」として動くことの確認を行います。
- システムテスト
- ソフトウェア全体の確認
- 例えばロボット開発で言えば、両手両足、頭、胴体、などロボット全体が動くことの確認を行います。
保守・運用
どれだけ念入りにテストを行ったとしても、ソフトウェアが完成し、実際に使用している最中に不具合やバグが発見されてしまうことも少なくありません。
そのためテスト後にリリースが開始されたあとは、保守・運用を行います。
また、このような機能を追加してほしい、という要望が生まれることも多いです。
そのような場合は保守運用の一環として、ソフトウェアに対して修正や機能追加も行います。
ソフトウェア完成後もこういったサポートを行っていくことは非常に重要となります。
ウォーターフォールモデルにおいて修正や機能追加を行いたい場合、修正・機能追加用の新規プロジェクトを結成することが普通です。
ウォーターフォールモデルに向いているプロジェクト
ここからは、どのようなプロジェクトでウォーターフォールモデルを採用すればいいのか、解説します。
大規模プロジェクト
大規模なプロジェクトでは、初期段階で計画の骨子が固まっており、開発中は当初予定通りに進行していくことが理想です。
そのため、工程ごとに段階的に進行していくウォーターフォールモデルの利点を活かしやすく、大規模であればあるほどウォーターフォールモデルを採用することで進捗管理がやりやすくなります。
【具体例】
・航空機の設計と製造 – 変更が困難で、詳細な計画と段階的な進行が必要なため。
・政府のITシステム開発 – 事前に全ての要件を明確に定義する必要があり、段階ごとの承認が求められるため。
・医療機器の開発 – 厳格な規制と品質管理が求められ、工程の各段階をしっかりと管理する必要があるため。
要件が明確なプロジェクト
ウォーターフォールモデルは、プロジェクトの初期段階で要件を詳細に定義することを前提としています。
開発が開始した時点で要件が固まりきっており、予定外の変更が起こりにくいプロジェクトならば、ウォーターフォールモデルの採用が検討できるでしょう。
【具体例】
・会計ソフトの開発 – 初めから必要な機能や要件がはっきりしているため。
・eコマースサイトの構築 – 事前に全ての機能と要件が詳細に定義されている場合。
・企業内の人事管理システム – 必要な要件が明確で変更の余地が少ないプロジェクト。
命やお金に関わる重要プロジェクト
ウォーターフォールモデルでは、各工程で品質管理が行われ、工程ごとの品質が担保しやすいです。
そのためウォーターフォールモデルは、例えば人命に関わる医療機器の開発や、大金が動く金融システムなど、品質が重要となるプロジェクトに適しています。
【具体例】
・医療機器の開発 – 高度な安全性と正確性が求められるため、厳密なプロセス管理が必要。
・金融システムの構築 – 金融取引を扱うシステムは高い信頼性とセキュリティが必要。
・航空機の制御システム – 変更が困難で、安全性が最優先されるため、各段階を慎重に進める必要。
まとめ：ウォーターフォールは時代遅れ？
ウォーターフォールモデルとは、以下の6段階の工程を順番に行い、次の工程に進んだら前の工程には戻らない開発手法です。
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
全体の計画が立てやすく、各工程でドキュメントが作成されるため、全体の品質やスケジュールが重要となるプロジェクトには適しています。
しかし、要件の変更が予想されるプロジェクトや顧客の要望を重要視するプロジェクトにはあまり適していません。
現在のシステム開発では、求めているソフトウェアをスピード開発し、顧客の要望に合わせ柔軟に追加修正を行うことが多くなりました。
そのためウォーターフォールの融通の効かなさ、柔軟性の低さが目立つようになっています。
株式会社Jiteraでは、AIの力を使って顧客のニーズに合わせたシステムを、高品質短納期で開発しています。
もしソフトウェアの開発を検討している企業様、ぜひ株式会社Jiteraへ問い合わせください。
企業様のお悩みに合わせ最適なソフトウェア開発を提供いたします。
