ウォーターフォール

要点

  • ウォーターフォールとは、要件定義→設計→実装→テスト→リリースの工程を、順番に一度だけ進める開発手法です。
  • 前の工程を完了させてから次の工程に進むため、計画が立てやすく進捗も把握しやすいのが特徴です。
  • 一方で、後工程になってからの仕様変更には弱く、手戻りのコストが大きくなりやすいという弱点もあります。

ウォーターフォールとは

ウォーターフォールは、システム開発の工程を「要件定義」「設計」「実装」「テスト」「リリース」のように区切り、上流の工程から下流の工程へ、一方向に順番に進めていく開発手法です。

水が高いところから低いところへ一度流れ落ちたら逆流しないように、原則として前の工程には戻らずに進めることから「ウォーターフォール(滝)」と呼ばれています。

工程の流れ

各工程は次のように、前工程の成果物(決まったこと)を土台にして進みます。

要件定義
設計
実装
テスト
リリース

「要件定義がすべて固まってから設計に入る」「設計がすべて固まってから実装に入る」というように、各工程の完了を区切りとして次に進むのが基本ルールです。

ぽち先生のヒント建築工事に似ています。基礎工事が終わっていない状態で壁を建てることはできませんし、壁ができていないのに屋根はつけられません。ウォーターフォールも同じように、前工程が完了していることが次工程を始める前提になります。

メリット:計画が立てやすい

最初にすべての要件や仕様を決めてから作業に入るため、開発全体に必要な期間や人員を早い段階で見積もることができます。

各工程の完了時点で「何ができているべきか」がはっきりしているので、進捗状況の管理や、関係者への報告もしやすくなります。大規模なプロジェクトほど、この計画のしやすさが重要になります。

デメリット:後工程での変更に弱い

ウォーターフォールは、前の工程に戻らないことを前提に進めるため、実装やテストの段階になってから「要件を変えたい」という要望が出ると、設計から見直しになり、大きな手戻りが発生します。

上流での変更影響範囲が狭く、比較的対応しやすい
下流での変更すでに完了した工程の作業をやり直す必要があり、コストが大きい

ぽち先生のヒント建物が完成間近になってから「部屋の配置を変えたい」と言われても、壁を壊して基礎からやり直すのは大変です。ウォーターフォールでの後工程の仕様変更も、これと同じくらい大きな負担になりがちです。

どんなプロジェクトに向いているか

ウォーターフォールは、作るものの要件があらかじめはっきりしていて、開発の途中で大きく変わる可能性が低いプロジェクトに向いています。

また、金融システムや公共インフラなど、品質・安全性の基準が厳しく、後戻りのコストや影響が非常に大きいシステムでも、計画を重視できるウォーターフォールが選ばれることが多くあります。

V字モデルとの関係

ウォーターフォールを図で表す際、単純に工程を縦に並べるだけでなく、「V字モデル」としてテスト工程との対応関係を示すこともよくあります。

📋 要件定義 ↔ 受入テスト
✏️ 基本設計 ↔ 結合テスト
🔧 詳細設計 ↔ 単体テスト

各設計工程で決めた内容を、対応するテスト工程で確認するという対応関係を意識しておくと、「何をどのテストで確認すべきか」が整理しやすくなります。

まとめ

ウォーターフォールは、要件定義から設計・実装・テスト・リリースまでの工程を、順番に後戻りせず進める開発手法です。計画の立てやすさが大きな強みですが、後工程での仕様変更に弱いという弱点もあわせて理解しておきましょう。

関連トピック:

🏠 トップに戻る