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

約5分

プロジェクトの進め方を選びたい方、アジャイルとウォーターフォールの違いを実務目線で理解したい方

アジャイルとウォーターフォールは、厳密には同じ種類の用語ではありません。アジャイルは価値観と原則に基づく開発アプローチの総称で、ウォーターフォールは工程を順に進める予測型ライフサイクルの通称です。このページでは、実務で進め方を選ぶために「変更を前提に短く学ぶか」「合意した段階を計画的に進めるか」という共通の軸で比較します。

比較するときの前提

アジャイルは、短い期間で動くものを作り、利用者や関係者の反応を見ながら改善していく進め方です。Agile Manifesto は、プロセスやツールよりも人と対話、包括的なドキュメントよりも動くソフトウェア、契約交渉よりも顧客との協調、計画への固執よりも変化への対応を重視しています。[1]

ウォーターフォールは、要件定義、設計、実装、テスト、リリースのような工程を段階的に進める予測型の考え方です。要件が比較的安定し、工程ごとの成果物や承認条件を先に定めやすい場合に適合しやすくなります。[5]

なお、ウォーターフォールの起源として頻繁に引用される Royce の1970年の論文は、単純な一方向モデルをそのまま推奨したものではありません。論文は、前工程への反復、試作、テスト計画などのリスク低減策も説明しています。[4] このページでは、現在一般に使われる予測型・段階型の意味で「ウォーターフォール」と呼びます。

比較表

観点	アジャイル	ウォーターフォール
進め方	短い反復で作る	工程を順番に進める
変更対応	変更を前提に調整する	変更は影響範囲を確認して管理する
成果物	動くソフトウェアを早く見せる	要件書、設計書、テスト仕様などを段階ごとに残す
向いている状況	要件が変わる、新規性が高い、利用者反応を見たい	要件が比較的安定し、段階ごとの承認や納品物が重要
リスク	方向性がぶれると反復だけが増える	後半まで問題が見えにくい

アジャイルの基本

アジャイルでは、すべてを最初に決め切るのではなく、小さく作って確認します。たとえば2週間のスプリントで「ログイン画面」「検索機能」「管理画面の一部」のように価値のある単位を実装し、レビューで次の優先順位を決めます。

アジャイルの原則には、早く継続的に価値を届けること、変化する要求を歓迎すること、短い間隔で動くソフトウェアを届けることが含まれます。[2] Scrum はアジャイルを実践する代表的なフレームワークのひとつで、スプリント、プロダクトバックログ、レビュー、レトロスペクティブなどのイベントと成果物を定義します。[3]

graph LR
    A["計画"] --> B["実装"]
    B --> C["レビュー"]
    C --> D["ふりかえり"]
    D --> A

ウォーターフォールの基本

ウォーターフォールでは、工程の完了条件を明確にしてから次へ進みます。たとえば要件定義で「何を作るか」を合意し、設計で「どう作るか」を決め、実装後にテストで品質を確認します。

graph TD
    A["要件定義"] --> B["設計"]
    B --> C["実装"]
    C --> D["テスト"]
    D --> E["リリース"]
    E --> F["保守"]

この進め方は、関係者間で成果物と完了条件を先に合意する開発で説明しやすい一方、後半で要件の誤りが見つかると手戻りが大きくなります。予測型ライフサイクルでもレビューや手戻りはあり、「一度も前工程に戻らない」ことを意味しません。

どちらを選ぶべきか

実務では、完全なアジャイルか完全なウォーターフォールかではなく、組み合わせることが多くあります。

状況	考え方
新規プロダクトで利用者反応を見たい	アジャイルを中心にする
要件が安定し、契約上の成果物と段階承認が明確	ウォーターフォール要素を強める
全体予算は先に決めたいが、機能は探索したい	大枠は段階管理し、実装は反復で進める
AIモデルの品質が事前に読みにくい	評価・実験・改善を短いサイクルに入れる

AIサービス開発での注意点

AIサービスでは、アプリケーションコードだけでなく、プロンプト、モデル、評価データ、ログ分析も変更対象になります。そのため、仕様書だけで品質を固定するのは難しく、実際の入力、失敗例、評価結果を見ながら改善する流れが重要です。

一方で、企業導入ではセキュリティ、権限、データ保護など、継続して満たすべき制約があります。画面やモデルの改善を反復的に進めながら、認証、ログ、データ保護の受け入れ条件を早めに明文化し、各反復で検証する組み合わせが実践的です。

よくある質問

アジャイルでは計画や文書を作らないのですか？

作ります。Agile Manifesto は、計画や文書に価値がないとは述べていません。動くソフトウェアや変化への対応を、相対的により重視すると説明しています。[1]

一つのプロジェクトで両方を使えますか？

使えます。予算、外部契約、全体の承認点は段階的に管理し、各機能の設計・実装・評価は短い反復で進めるなど、対象ごとに適した管理方法を組み合わせます。

まとめ

アジャイルは価値観と原則に基づく開発アプローチ、ウォーターフォールは予測型・段階型ライフサイクルの通称
両者は共通の比較軸に置けるが、完全な対義語や排他的な選択肢ではない
変更と学習が多い領域ではアジャイル、要件と段階承認が安定している領域ではウォーターフォール要素が適合しやすい
AIサービスでは、モデル・データ・評価の変更も開発計画に含める

参考文献

Kent Beck ほか, Manifesto for Agile Software Development, 2001年
Kent Beck ほか, Principles behind the Agile Manifesto, 2001年
Scrum.org, The Scrum Guide, 2020年11月
Winston W. Royce, Managing the Development of Large Software Systems, IEEE WESCON, 1970年
Douglas H. Desaulniers, Robert J. Anderson, Project Management Institute, Matching software development life cycles to the project environment, 2001年11月1日

クイズ

開発手法の基礎

DevOps・MLOps・AIOpsの概要