用語比較
アジャイルとウォーターフォールの違い（変更の受け入れ方で見分ける）
ウォーターフォールは、すべてのフェーズを順番に進め、前のフェーズの結果に次のフェーズが依存する開発手法です。アジャイルは、フェーズを複数の短い開発サイクルに配置し、小さな変更を繰り返し届ける開発手法です。
違いが最もはっきり出るのは、変更の扱いです。AWSの解説によれば、ウォーターフォールはフェーズが完了したとみなされたあとに変更する余地がほとんどなく、アジャイルは変更に迅速に対応できるよう要件や計画を継続的に評価します。
G検定では、AIプロジェクトの進め方で、アジャイルとウォーターフォールの名前が開発手法として挙がります。このページは、2つの名前が選択肢に並んで迷う人向けです。
CRISP-DMなどのプロセス標準との違いは別のページで扱い、ここでは2つの開発手法の比較に絞ります。
この記事の根拠と出典
各セクションの見出しの下に、公式資料で確認した内容か編集部の整理かをラベルで示しています。 試験日・料金・申込条件・試験方式は変わることがあるため、申込前に公式サイトで確認してください。G検定の一次情報確認日: 2026-10-02。
結論
ウォーターフォール
フェーズを順番に進め、各フェーズの終わりに具体的な成果を出す。完了後の変更の余地は小さい。
アジャイル
複数の開発サイクルを短く回し、小さな変更を漸進的に届ける。要求の変更を後期でも歓迎する。
違いを表で確認
| 比較軸 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | ウォーターフォール：全フェーズを順番に並べ、前のフェーズの結果に依存する | アジャイル：フェーズを複数の開発サイクルに配置し、各サイクルで小さな変更を提供する |
| 変更への対応 | ウォーターフォール：フェーズ完了後に変更する余地がほとんどない | アジャイル：要求の変更を開発の後期でも歓迎し、要件・計画・結果を継続的に評価する |
| 向いているプロジェクト | ウォーターフォール：要件を事前に正確に定義できる小規模なプロジェクト | アジャイル：複雑なプロジェクトでも、問題を早い段階で特定して対処しやすい |
| メリット | ウォーターフォール：プロジェクト管理に規律を与え、各フェーズの終わりに具体的な成果が出る | アジャイル：問題を早い段階で特定して対処でき、関係者のフィードバックを得やすい |
| デメリット | ウォーターフォール：変更がソフトウェアの配信時間・コスト・品質に影響しうる | アジャイル：フィードバックに頼りすぎると、スコープが過度に変わったり途中で頓挫したりしうる |
G検定の学習に使う書籍（Amazon）
試験範囲を通して読むときの1冊です。読んだ章は、このサイトの章別問題で確かめられます。
どこで迷っているかを切り分ける
どちらが新しい、どちらが優れていると考えて選ぶ人
優劣ではなく、向き不向きで選びます。要件を最初に確定できるならウォーターフォール、変更を前提に進めるならアジャイルです。
選択肢の文章から、どちらの手法か見分けたい人
「順番」「完了後の変更が難しい」が出ればウォーターフォール、「反復」「短い間隔」「変更を歓迎」が出ればアジャイルです。
ウォーターフォールの特徴を「古い」の一言で済ませている人
AWSの解説は、各フェーズの終わりに具体的な成果が出て、プロジェクト管理に規律を与える点を、メリットとして挙げています。
具体例で使い分ける
例 1
要件を最初に確定でき、後から変えない場合
仕様が固まっており、設計から試験まで順に進めて、完了したフェーズには戻らない開発を問う場面です。
- 全フェーズを順番に進め、前のフェーズの結果に次が依存します。
- AWSの解説は、要件を事前に正確に定義できる小規模なプロジェクトに最適としています。
結論: 順番に進め、完了後は変更しない開発は、ウォーターフォールです。
例 2
2〜3週間ごとに動くものを出し、要望を取り入れる場合
短い間隔で動くソフトウェアをリリースし、顧客の要望を見て次の内容を調整する開発を問う場面です。
- アジャイル宣言の原則は、動くソフトウェアを2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースすると定めています。
- 要求の変更は、たとえ開発の後期であっても歓迎します。
結論: 短い間隔で届けて変更を歓迎する開発は、アジャイルです。
例 3
動くものを進捗の尺度にする場合
文書の完成率ではなく、実際に動くものの有無で進み具合を測る考え方を問う場面です。
- アジャイル宣言の原則は、動くソフトウェアこそが進捗の最も重要な尺度だとしています。
結論: 動くソフトウェアを進捗の尺度にするのは、アジャイルの原則です。
問題文から答えを選ぶ手順
- 1
変更の扱いを確認する
完了後の変更を想定しないならウォーターフォール、変更を後期でも歓迎するならアジャイルです。
- 2
進め方を確認する
全フェーズを一度だけ順番に進めるならウォーターフォール、短い開発サイクルを繰り返すならアジャイルです。
- 3
成果物の出し方を確認する
各フェーズの終わりに成果を出すのがウォーターフォール、小さな変更を漸進的に届けるのがアジャイルです。
- 4
プロジェクトの性質で最終確認する
要件が事前に確定できる小規模な開発はウォーターフォールが最適とされます。関係者のフィードバックを得ながら進めたいなら、アジャイルの特徴と合います。
試験での見分け方
- 1全フェーズを順番に進め、完了後の変更が難しいのが、ウォーターフォール。
- 2短い開発サイクルを繰り返し、変更を歓迎するのが、アジャイル。
- 3要件を事前に正確に定義できる小規模な開発は、ウォーターフォールが最適とされる。
- 4動くソフトウェアを進捗の尺度とするのは、アジャイルの原則。
誤答しやすい選択肢
アジャイルは計画を立てない手法だと考える
修正: AWSの解説は、アジャイルが要件・計画・結果を継続的に評価すると説明しています。計画をなくすのではなく、繰り返し見直します。
ウォーターフォールは必ず劣っていると考える
修正: 要件を事前に正確に定義できる小規模なプロジェクトには最適とされます。向き不向きで判断します。
アジャイルなら顧客の要望をすべて取り込めばよいと考える
修正: AWSの解説は、フィードバックに頼りすぎるとスコープが過度に変わりうることを、デメリットに挙げています。
確認問題
Q1すべてのフェーズを順番に並べ、前のフェーズの結果に次のフェーズが依存する開発手法はどちらですか？
答え: ウォーターフォール
AWSの解説は、設計が滝のように、あるフェーズから次のフェーズに流れるイメージで説明しています。
Q2要求の変更を、たとえ開発の後期であっても歓迎する開発手法はどちらですか？
答え: アジャイル
アジャイル宣言の背後にある原則に、要求の変更を後期でも歓迎することが挙げられています。
Q3アジャイル宣言の原則で、進捗の最も重要な尺度とされているものは何ですか？
答え: 動くソフトウェア
文書や計画ではなく、動くソフトウェアそのものを進捗の尺度とします。
到達チェック
- ウォーターフォールとアジャイルの進め方の違いを言える
- 変更への対応の違いを言える
- それぞれが向いているプロジェクトを言える
- アジャイル宣言の原則を1つ以上言える
関連ページで確認する
同じ資格で次に知りたいこと
- エコーチェンバーとフィルターバブルの違い
エコーチェンバーとフィルターバブルの違いを、起きる場所、原因、本人の気づきやすさ、G検定での見分け方と確認問題まで、総務省の情報通信白書に沿って解説します。
- ImageNetとILSVRCの違い（データセットとコンペティション）
ImageNet（画像データセット）とILSVRC（画像認識のコンペティション）の違いを、AlexNetが15.3%の誤り率で優勝した2012年の結果とあわせて解説。G検定の大項目2で問われる区別と確認問題つきです。
- 請負契約と準委任契約の違い（AI開発の契約でG検定に出る見分け方）
請負契約と準委任契約の違い（約束する内容、完成義務、AI開発の各段階で準委任型が親和的とされる理由、G検定での見分け方と確認問題）。根拠は民法と経済産業省の契約ガイドライン。
よくある質問
Qアジャイルとウォーターフォールの最大の違いは何ですか？
変更の扱いです。ウォーターフォールはフェーズ完了後に変更する余地がほとんどなく、アジャイルは短い開発サイクルを繰り返して変更に迅速に対応します。
Q要件が最初に決まっている開発に向くのはどちらですか？
AWSの解説によれば、要件を事前に正確に定義できる小規模なプロジェクトには、ウォーターフォールが最適とされています。
Qアジャイルの欠点は何ですか？
AWSの解説は、顧客からのフィードバックに過度に依存すると、スコープが過度に変更されたり、プロジェクトが途中で頓挫したりする可能性を挙げています。
Qアジャイル宣言とは何ですか？
アジャイルな開発の考え方を示した宣言で、その背後にある原則に、価値のあるソフトウェアを早く継続的に提供することや、要求の変更を後期でも歓迎することが含まれます。
次に見る比較
- G検定・DS検定・統計検定2級で重なる用語10語の比較
同じ名前の用語の定義と収録章を、資格ごとに並べます。
- ベイズの定理と条件付き確率の違い（統計検定2級の式と計算例）
求める確率の向きの違いと、陽性になる確率の計算例を確かめます。
- 紛らわしい用語ペア早見表
混同しやすい用語の違いと判定の手掛かりを、資格別の一覧で確かめます。
執筆: ミナト編集部（運営者情報を見る）