ウォーターフォール開発とは?アジャイルとの違いと使い分け
公開日:
最終更新日:
ウォーターフォール開発とは、要件定義、設計、実装、テストなどの工程を順に進める開発の方式です。前の工程で整理した成果を次へ渡し、段階ごとに確認や合意を行います。対象範囲や依存関係を整理しやすい一方、後の工程で大きな変更が分かると、前の成果へ戻る影響が広がります。
IBMの開発モデルの比較も参考にできます。ここでは、どちらが優れているかを一律に決めず、仕事の条件から使い分けを考えます。
一般的な工程の流れ
工程 | 主に整理すること | 次へ進む前の確認例 |
|---|---|---|
要件定義 | 目的、必要な機能、制約 | 利用者の期待と対象範囲が合っているか |
設計 | 実現方法、データ、画面、連携 | 依存先と品質条件を満たせるか |
実装 | 動作する処理や画面 | 設計との差と影響が把握できるか |
テスト | 要件や品質条件への適合 | 問題の扱いと残る制約が明確か |
移行・運用 | 本番切り替えと継続対応 | 戻し方、監視、問い合わせ先があるか |
工程名や区切りは組織ごとに異なります。表をそのまま標準とせず、誰が何を確認し、どの情報を次へ渡すかを決めます。
アジャイルとの違い
観点 | ウォーターフォール型の考え方 | アジャイル型の考え方 |
|---|---|---|
主な進め方 | 工程ごとの成果と合意を積み重ねる | 小さな成果と反応から調整する |
範囲の扱い | 早期に明確にし、変更を管理する | 優先順位と実績から見直す |
フィードバック | 工程の節目を中心に設計する | 短い周期で得るよう設計する |
計画 | 全体工程と依存関係を重視する | 目標を共有し、近い仕事を具体化する |
実際の運用には幅があります。ウォーターフォールでも試作や早期確認はできますし、アジャイルでも全体の期限、予算、依存関係を考えます。詳しい考え方はアジャイル開発とは?メリット・デメリットと代表的な手法を解説を参照してください。
向いている条件を具体例で考える
仕様が安定したデータ移行で、移行日、入力形式、接続先が明確なら、工程と検証条件を先に整理する方法が候補になります。変換仕様、件数照合、切り戻し手順などを段階的に確認できます。ただし、データ品質が不明なら早い調査が必要です。
一方、新しい申し込み体験で、利用者がどこに迷うかまだ分からないなら、試作品を小さく作って反応を得る方法が候補になります。最初に全画面を確定すると、後で利用者の理解とずれていたことが分かるかもしれません。
これらは説明用の架空例です。同じ業界でも、仕事の不確実性によって適した進め方は変わります。
変更が起きたときに確認すること
- 変更の目的と、変えない場合の影響を確認します。
- 要件、設計、データ、テスト、運用のどこへ影響するかを調べます。
- 費用、期間、品質、外部依存への影響を整理します。
- 承認する人と、更新する成果物を決めます。
- 実施後に必要な再確認を計画します。
この考え方はアジャイルでも必要です。変更に対応できることと、影響を確認せずに引き受けることは別です。逆に、計画を守るためだけに必要な変更を隠すことも避けます。
併用するときは境界の情報をそろえる
全体の移行日は工程で管理し、利用者向けの一部をスクラムとは?スクラム開発の進め方・役割・イベントを図解のスクラムで改善する運用も考えられます。その場合は、外部へ約束した範囲と、チームが周期ごとに調整できる範囲を区別します。
境界でそろえる情報 | 確認する内容 |
|---|---|
成果の条件 | 何を完成と見なすか |
引き渡し | どの状態で、誰へ、いつ渡すか |
依存関係 | 相手の変更が自分たちへどう影響するか |
変更判断 | 誰が何を承認し、どこに記録するか |
仕事の状態と待ちを可視化したい場合は、既存のカンバンボード解説も参考になります。手法名だけで境界の問題が解消するわけではありません。
選び方をチームで共有する
要件の安定性、反応を得られる速さ、完成した成果を小さく渡せるか、外部の確認条件を見て決めます。選択した理由と見直す条件を残すと、状況が変わっても議論しやすくなります。
施策の進行と費用・承認を一緒に確認する際は、Xtrategyのプロジェクト管理で扱う情報も合わせ、開発の進め方と事業側の判断をつないでください。

