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

投稿日: 2026/10/14

ウォーターフォールは、最初にすべてを決めて順番に進める開発手法です。予算や納期の見通しを立てやすい一方で、要件が後から変わると手戻りや追加費用が大きくなります。アジャイルは、短い区切りで作って直すことを繰り返す開発手法です。変化に強い反面、総額が見えにくく、発注者側にも継続的な関与が求められます。

どちらが優れているかではなく、要件の明確さ、社内の判断体制、予算の出し方の3点から、自社に合う手法を選ぶのが基本です。実務では、前半を小さく試し、範囲が固まってから本開発を発注するという「段階で分ける」進め方も現実的です。この記事では、両手法のメリット・デメリットと起きやすい問題を整理したうえで、発注前にベンダーへ確認すべき質問と、注意したい危険信号もまとめています。

ウォーターフォール・アジャイルとは

ウォーターフォール

ウォーターフォールは、開発の工程を上から順番に一度ずつ進める手法です。水が滝(waterfall)を上から下へ流れ落ち、逆流しない様子が名前の由来です。

一般的な流れは次のとおりです。

要件定義:作るシステムの機能や仕様をすべて決める
設計:画面、データ、システム構成などを設計書にまとめる
開発:設計書どおりにプログラムを作る
テスト:仕様どおりに動くかを確認する
リリース:本番環境で使い始める

各工程の成果物を確認してから次の工程に進むため、計画や進捗を管理しやすいのが特徴です。一方で、前の工程に戻ることは想定されていません。

アジャイル

アジャイルは、短い期間で「作る→見せる→直す」を繰り返しながら、少しずつシステムを完成させていく手法です。「アジャイル(agile)」は英語で「素早い」「機敏な」という意味です。

代表的な進め方である「スクラム」では、次のサイクルを繰り返します。

計画:今回の区切りで作る機能を、優先度の高いものから選ぶ
開発:1〜4週間程度の区切り(スプリント)で、選んだ機能を作る
確認:動くものを発注者に見せ、意見をもらう
改善:意見をもとに、次に作るものや優先順位を見直す

最初からすべてを決めず、動くものを見ながら方向を修正できるのが特徴です。その分、発注者も開発期間中ずっと判断に関わる必要があります。

それぞれのメリット・デメリット

ウォーターフォールのメリット

予算と納期の見通しを立てやすい:最初に範囲を決めるため、総額とスケジュールを確定しやすく、社内稟議や予算確保と相性がよい
進捗を管理しやすい:工程ごとに完了の基準があり、今どこまで進んでいるかが明確
ドキュメントが残る:要件定義書や設計書が揃うため、保守や担当者の引き継ぎがしやすい
発注者の負担が少ない:要件定義と受け入れテストに集中すればよく、開発中の関与は少なくて済む
完成の基準が明確:仕様書と照らし合わせて、完成したかどうかを判断できる

ウォーターフォールのデメリット

途中で要件を変えると、手戻りや追加費用が大きくなる
問題が見つかるのが終盤のテスト工程になりやすい
発注者が動くものを見られるのは、開発の最後
ベンダーへの丸投げになりやすく、社内に知識が残りにくい

アジャイルのメリット

早い段階で動くものを確認できる:1〜4週間ごとに成果物を見られるため、「思っていたのと違う」を早く発見できる
変化に対応しやすい:市場や業務の変化に合わせて、優先順位や作る機能を見直せる
必要な機能から使い始められる:優先度の高い機能から順にリリースできるため、早く効果を出しやすい
不要な機能を作らずに済む:使いながら判断するため、結局使われない機能への投資を減らせる
発注者とチームの認識がずれにくい:定期的に成果を確認するため、ずれが小さいうちに修正できる

アジャイルのデメリット

総額と完成時期を最初に確定しにくい
発注者側にも、継続的に判断する担当者と時間が必要
準委任契約が一般的で、成果物の完成が保証されない
進め方によっては、全体設計やドキュメントが不足しやすい

どちらの手法にも明確な強みがあり、デメリットの多くは「手法とプロジェクトが合っていない」ときに表面化します。ここからは、それぞれで実際に起きやすい問題を詳しく見ていきます。

ウォーターフォールで起きやすい問題

ウォーターフォールの問題の多くは、「最初にすべてを決める」という前提から生まれます。

1. 要件を最初に決めきれない

多くの発注者は、実際に画面を触るまで本当に必要な機能がわかりません。要件定義書に合意しても、完成品を見て「思っていたのと違う」となるのはよくあることです。

2. 問題が見つかるのが終盤になる

テストは最後の工程です。そのため、設計のミスや認識のずれが見つかるのはリリース直前になります。その時点での手戻り(前の工程に戻ってやり直すこと)は、費用も時間も大きくなります。

3. 仕様変更がそのまま追加費用と遅延になる

ウォーターフォールは、請負契約(完成した成果物に対して代金を払う契約)と組み合わせるのが一般的です。要件定義後の変更は原則として追加見積もりになるため、業務や市場の変化に合わせにくくなります。

4. 「書類は揃っているのに動くものがない」

進捗は設計書の完成度で報告されることが多く、発注者が動くソフトウェアを見るのは最後になります。「進捗90%」のまま何か月も止まるプロジェクトは珍しくありません。

5. ベンダーへの丸投げになりやすい

要件定義が終わると、受け入れテストまで発注者の出番はほとんどありません。日本ではこの構造が、SIer(システム開発を一括で請け負う会社)にすべてを任せる慣習と結びついてきました。その結果、社内に知識が残らない原因にもなっています。

ウォーターフォールが合うケース

法令や既存システムの仕様で、要件が明確に決まっている(制度対応、機能が同じシステムの置き換えなど)
予算と納期を最初に固定する必要がある(社内稟議、補助金申請など)
発注者側が開発期間中、頻繁には関与できない

アジャイルで起きやすい問題

アジャイルはウォーターフォールの弱点を補う手法ですが、万能ではありません。発注者側の準備がないまま始めると、別の形で問題が起きます。

1. 総額と完成時期が見えにくい

アジャイルは作る範囲を最初に固定しません。そのため「総額いくらで、いつ完成するか」を確約しにくく、社内稟議や年度予算の仕組みとは相性がよくありません。

2. 発注者側の負担が大きい

アジャイルでは、発注者側からプロダクトオーナー(何をどの順番で作るかを決める責任者)を出すのが基本です。毎週の確認や優先順位の判断に時間を割けないと、開発チームは待ち状態になります。

3. 契約形態とのミスマッチ

アジャイルは、準委任契約(作業の遂行に対して代金を払い、成果物の完成義務を負わない契約)と組み合わせるのが一般的です。IPA(情報処理推進機構)が公開しているアジャイル開発版のモデル契約も、準委任契約を前提にしています。

つまり、期待した成果が出なくても費用は発生します。逆に、請負契約のままアジャイルで進めると、変更のたびに「契約範囲内かどうか」で揉める原因になります。

4. 「アジャイル」が計画不足の言い訳になる

「アジャイルなので設計書はありません」「全体の計画は走りながら決めます」という説明には注意が必要です。スプリントを回しているだけで、全体像やゴールが誰にも見えていないケースがあります。

5. 技術的負債が溜まりやすい

新機能の追加を優先し続けると、技術的負債が溜まります。技術的負債とは、後回しにした設計やテストの問題が、将来の改修コストを押し上げるものです。開発のスピードが徐々に落ち、「最初は速かったのに」という状態になります。

6. 名前だけのアジャイル

要件はすべて最初に決め、それを2週間ごとに分割しただけ、という進め方もあります。これは、ウォーターフォールの硬さとアジャイルの不透明さという両方の弱点を抱えた状態です。

アジャイルが合うケース

新規事業や新サービスで、使ってみないと正解がわからない
発注者側に、継続して判断できる担当者がいる
予算を段階的に出し、成果を見て継続・中止を判断できる

デジタル庁の調達改革の検討資料でも、要件や技術に不確実性がある案件はアジャイル、不確実性がない案件はウォーターフォールが適すると整理されています。

どちらを選ぶべきか:3つの質問で判断する

観点	ウォーターフォール	アジャイル
向いている要件	明確で、途中で変わらない	不確実で、使いながら変わる
費用の決まり方	最初に総額を確定	体制×期間で月ごとに発生
主な契約形態	請負契約	準委任契約
発注者の関与	要件定義と受け入れテストに集中	開発期間中ずっと継続
問題が見つかる時期	終盤(テスト工程)	早い(1〜4週間ごと)
典型的な失敗	完成したのに使われない	費用が膨らみ、終わらない

手法を選ぶ前に、社内で次の3つに答えてみてください。

要件をいま文章で書き切れるか:書き切れるならウォーターフォール寄り、「使ってみないとわからない」ならアジャイル寄りです。
社内に毎週判断できる人がいるか:いなければ、アジャイルは機能しにくくなります。
予算は一括で固定か、段階的に出せるか:一括固定が必須なら、少なくとも契約はウォーターフォール型の考え方が必要です。

現実的な選択肢:段階で分ける

実務では、どちらか一方に決めきらない進め方もよく使われます。

前半をアジャイル、後半をウォーターフォール:PoC(小さく試して実現できるかを確かめる検証)やプロトタイプを準委任で短く回し、範囲が固まった部分を請負で発注する。
段階契約:要件定義・設計・開発を別々の契約にし、各段階の終わりに続けるかどうかを判断する。
アジャイルに上限を設ける:「3か月・月額いくら」のように期間と予算の上限を決め、その時点で何ができているかを評価する。

発注前にベンダーへ確認したい質問

ベンダーの実力は、手法の名前ではわかりません。「その手法でどう進め、問題が起きたらどうなるか」を具体的に答えられるかどうかで判断します。

ウォーターフォールの提案を受けたとき

要件定義後の仕様変更は、どの範囲まで見積もりに含まれていますか?
開発の途中で、動く画面を確認できるタイミングはありますか?
テスト工程で重大な問題が見つかった場合、費用はどちらが負担しますか?

アジャイルの提案を受けたとき

1スプリントの期間と体制、月額費用はいくらですか?
最初の3か月で、何が使える状態になる見込みですか?
当社側のプロダクトオーナーには、週に何時間程度の関与が必要ですか?
優先順位はどう決め、「作らないもの」はどう決めますか?
テストの自動化やコードレビューは、どのように行いますか?

どちらの手法でも確認すること

途中で中止・縮小する場合の条件は何ですか?
ソースコード、設計資料、クラウドのアカウントは誰の所有になりますか?
担当者が交代・退職した場合の引き継ぎ方法は?

注意したい危険信号

「アジャイルなので見積もりは出せません」とだけ言い、月額や期間の目安も示さない
ウォーターフォールなのに、途中で成果物を確認する場が一度もない
見積もりの内訳が「一式」ばかりで、何にいくらかかるのかわからない
なぜその手法を選んだのかを、自社の状況に合わせて説明できない

まとめ

ウォーターフォールとアジャイルには、それぞれ明確な強みと弱みがあります。

ウォーターフォールは、見通しの立てやすさが強みです。一方で、「完成したのに使われない」リスクがあります。
アジャイルは、変化への強さが強みです。一方で、「費用が膨らんで終わらない」リスクがあります。

どちらを選んでも、発注者が途中で何も判断しなければ、失敗のリスクは残ります。

手法を選ぶときは、次の3点を社内で確認してください。

要件をいま書き切れるか
毎週判断できる人がいるか
予算を段階的に出せるか

迷う場合は、前半を小さく試してから本開発を発注するなど、途中で判断できるタイミングを契約に組み込むことが大切です。

「どちらの提案が自社に合っているのか」「この見積もりは妥当なのか」と迷ったら、お手元の見積もり・提案書をもとに、発注者の立場で確認ポイントをお伝えします。無料セカンドオピニオンを申し込む

← ブログ一覧に戻る