アジャイルとウォーターフォールの違い｜発注側の選び方と進め方

アジャイルとウォーターフォールとは、システム開発を進める代表的な2つの手法のことです。システム開発を外部に頼もうとすると、必ず出てくるのが「アジャイルとウォーターフォール、どちらで進めますか」という問いです。言葉は聞いたことがあっても、自社のプロジェクトにどちらが合うのか、発注側としてどう判断すればいいのかは分かりにくいものです。

結論から言えば、両者は「変更をどう扱うか」で分かれます。ウォーターフォールは計画どおりに進めることを重視し、アジャイルは途中の見直しを前提にします。そしてこの違いは、契約形態とも対応します。成果物の完成を約束する請負契約はウォーターフォールと、専門家の稼働そのものに対価を払う準委任契約はアジャイルと相性が良い、というのが基本の考え方です。

本記事では、両者の違いを表で整理したうえで、それぞれが向くプロジェクト、契約形態との対応、発注側でありがちな失敗、両者を組み合わせるハイブリッド、そして最終的な選び方までを、非IT企業の発注担当者がそのまま判断に使える形で解説します。

アジャイルとウォーターフォールは何が違う？（定義と全体像）#

最大の違いは「要件を最初にすべて固めてから作る（ウォーターフォール）か、作りながら優先順位を見直して育てる（アジャイル）か」という進め方の違いです。IPAは「開発対象全体の要件や仕様を確定してから開発を行うウォーターフォール開発とは異なり、アジャイル開発は、そのプロセスの中で、機能の追加・変更や優先順位の変更、先行リリース部分の改善などに柔軟に対応することができる手法です」と説明しています。

ウォーターフォールは工程を順に一度だけ進める#

ウォーターフォールは、要件定義→設計→開発→テスト→リリースと、水が流れ落ちるように工程を一度だけ順に進めます。計画が立てやすい反面、後からの変更に弱いのが特徴です。

アジャイルは短い反復で動くものを育てる#

アジャイルは、短い反復（イテレーション）を繰り返し、動くものを早く出して改善を重ねます。変更を前提にできる反面、発注側の継続的な関与が求められます。

6つの観点で比較する#

主な違いを並べると、次のとおりです。

両者の性格の違いを一目でつかめるよう、進め方の特徴をカードで対比します。

どちらが優れているという話ではなく、プロジェクトの性質によって向き不向きが分かれます。

それぞれどんなプロジェクトに向く？#

要件が固まっていて変更が少ないものはウォーターフォール、要件が動きうる・試しながら育てるものはアジャイルが向きます。

ウォーターフォールが向くプロジェクト#

• 完成形が最初から明確（法対応・既存システムの置き換えなど）
• 仕様変更がほとんど見込まれない
• 予算・納期・スコープを先に確定させたい

アジャイルが向くプロジェクト#

• 新規事業やアプリなど、正解を試しながら探る
• 利用者の反応を見て優先順位を変えたい
• 市場や業務の変化に合わせて継続的に改善したい

モバイルアプリやWebサービスのシステム開発のように、公開後も改善を続ける前提の案件では、アジャイル寄りの進め方が選ばれやすくなります。

自社の案件について「向くプロジェクトの条件」を、2つのカードに整理しました。

まず「要件が固いか、動くか」を見極めると、判断の軸がはっきりします。要件をどこまで固められるかはシステム開発の要件定義の進め方｜失敗しない手順と決めることも参考になります。

契約形態はどう対応する？（請負＝ウォーターフォール／準委任＝アジャイル）#

ウォーターフォールは請負契約、アジャイルは準委任契約が基本的に相性が良いとされます。成果物の完成を約束するか、専門家の稼働に払うかの違いです。

請負契約はウォーターフォールと噛み合う#

請負契約は「あらかじめ特定した成果物の完成」に対価を払う契約です。完成形を先に確定させ、工程を順に進めるウォーターフォールと噛み合います。

準委任契約とIPAのアジャイル開発版モデル契約#

独立行政法人情報処理推進機構（IPA）のアジャイル開発版 情報システム・モデル取引・契約書は、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としています」と明記しています。アジャイルは機能の追加・変更や優先順位の変更が生じることを前提とするため、成果物を先に固定する請負とはなじみにくいからです。

ただし準委任だからといって「お任せ」でよいわけではありません。範囲や進め方の合意は必要です。契約そのものの違いはシステム開発の請負契約と準委任契約の違い｜使い分けと注意点で詳しく解説しています。

発注側でありがちな失敗は？#

最も多いのは「アジャイル＝要件を決めなくていい・丸投げでいい」という誤解です。手法の理解不足が、そのまま失敗につながります。

よくある4つのつまずき#

• アジャイルを理由に要件も優先順位も決めず、ベンダに丸投げする
• ウォーターフォールなのに、途中で仕様変更を繰り返して計画が破綻する
• 発注側が意思決定に関与せず、開発が止まる・迷走する
• 契約形態と進め方がちぐはぐ（アジャイルなのに請負でスコープを固定するなど）

IPAも、アジャイル開発の利点を生かすには「十分なスキルとノウハウを有するベンダ企業を選定するだけでは足りず、プロダクトの方向性及び内容を決めるための主体的かつ積極的な関与が必要となり、相応の負担を伴います」としています。関与は「あったほうがよい」ものではなく、負担を織り込んで体制を用意すべきものだ、という位置づけです。どちらの手法でも、発注側の関与を欠くと失敗しやすくなります。つまずきの典型はシステム開発が失敗する理由｜よくある原因と発注側の対策でも整理しています。

ハイブリッドという選択肢は？#

要件が固い部分はウォーターフォール、変わりうる部分はアジャイル、と使い分ける進め方も現実的です。すべてを一方に寄せる必要はありません。

実際のプロジェクトは、すべてが「固い」わけでも「動く」わけでもありません。基幹の帳票や法対応など要件が明確な部分はウォーターフォールで確実に作り、利用者の反応で変わりうる画面や新機能はアジャイルで育てる、という組み合わせが有効な場合があります。大切なのは、どこを固定してどこを可変にするかを、発注側とベンダで事前に合意しておくことです。ここが曖昧だと、契約も進め方もぶれてしまいます。

発注側はどう選べばいい？（判断の3つの軸）#

「要件の固まり具合」「変更・改善の見込み」「発注側の関与体制」の3つで判断します。この3軸がそろって傾く方向が、自社に合う進め方です。

• 要件の固まり具合：最初に固められる→ウォーターフォール寄り／固めきれない→アジャイル寄り
• 変更・改善の見込み：少ない→ウォーターフォール寄り／繰り返す前提→アジャイル寄り
• 発注側の関与体制：要所の判断のみ→ウォーターフォール寄り／継続的に関与できる→アジャイル寄り

迷ったときに立ち返れるよう、選び方の判断軸をカードで整理しました。

3つが「ウォーターフォール寄り」に傾けばウォーターフォール、「アジャイル寄り」に傾けばアジャイル、混在するならハイブリッドを検討します。手法名から入るのではなく、自社の状況から選ぶのが失敗しないコツです。

弊社（株式会社TryWith）の支援#

弊社では、アジャイル・ウォーターフォールのどちらで進めるべきかの見極めから、契約形態の選定、開発の実行までを、開発を担う立場からお手伝いしています。要件がどこまで固まっているか、変更の見込みや自社の関与体制を一緒に整理し、案件に合った進め方と契約（請負／準委任）を設計します。モバイルアプリ・Web・ECなどのシステム開発を要件定義から運用まで一貫して手がけており、スポットCTO的な関与もあわせて提供しているため、「その進め方や見積もりが何を前提にしているか」を、開発側の視点から噛み砕いてご説明することもできます。

「アジャイルとウォーターフォールのどちらで進めるべきか」「今の契約形態が進め方と合っているか」といったご相談に、現状整理からお応えします。

よくある質問（FAQ）#

Q. アジャイルとウォーターフォールの一番の違いは何ですか？

A. 変更への向き合い方です。ウォーターフォールは工程を順に一度だけ進めるため後からの変更に弱く、アジャイルは短い反復を繰り返して優先順位の見直しを前提に進めます。発注側に求められる関与の度合いも変わります。

Q. アジャイルとウォーターフォール、どちらが優れていますか？

A. 優劣ではなく向き不向きです。要件が固く変更が少ないならウォーターフォール、要件が動く・試しながら育てるならアジャイルが向きます。混在するならハイブリッドも選択肢です。

Q. アジャイル開発の契約は請負と準委任のどちらですか？

A. 準委任契約が基本的に相性が良いとされます。IPAのアジャイル開発版 情報システム・モデル取引・契約書も、成果物を約束する請負ではなく、専門家の業務遂行に対価を払う準委任を前提としています。

Q. アジャイルなら要件定義は不要ですか？

A. 不要ではありません。全体像や優先順位は決める必要があり、発注側の主体的な関与も欠かせません。「決めなくていい」という誤解は失敗の典型です。

Q. 非IT企業でもアジャイル開発を発注できますか？

A. できます。ただし継続的な意思決定と関与が前提になるため、体制が取りにくい場合は、ウォーターフォールやハイブリッドも含めて検討すると現実的です。

まとめ#

アジャイルとウォーターフォールの違いは、変更をどう扱うかという進め方の違いに集約されます。要件が固く変更が少ないプロジェクトはウォーターフォール（請負契約）、要件が動き試しながら育てるプロジェクトはアジャイル（準委任契約）が基本の相性です。発注側は「要件の固まり具合」「変更・改善の見込み」「発注側の関与体制」の3軸で選び、混在するならハイブリッドも検討します。どちらを選んでも、発注側の主体的な関与が成否を分けます。

出典：アジャイル開発版 情報システム・モデル取引・契約書｜独立行政法人情報処理推進機構（IPA）（2020年3月31日公開／2025年4月8日最終更新。準委任契約を前提とする旨、およびユーザ企業の「主体的かつ積極的な関与が必要となり、相応の負担を伴います」との記述は同ページ本文）

「どちらで進めるべきか」「契約形態が進め方と合っているか」を整理したい場合は、現状把握からお手伝いします。まずはお問い合わせはこちらからお気軽にご相談ください。