ウォーターフォールとアジャイルの違い比較表｜開発手法の選び方診断

ウォーターフォールは工程を順番に1回ずつ進める開発手法、アジャイルは短い期間の反復を重ねて動くものを少しずつ増やす開発手法です。 どちらが優れているかではなく、要件の固まり具合と変更の多さに合うほうを選びます。

この記事では、2つの手法とハイブリッド（組み合わせ）を18項目で比べる表、10問の診断チェックリスト、合計点から手法を決める判定、ハイブリッドの3つの組み方を載せています。診断の判定は Python で全通りを数えて確かめ、表計算用の数式も計算結果を確認しました。扱うのは「手法を選ぶ段階の判断」までで、スクラムの進め方の詳細には踏み込みません。

確認環境：Ubuntu 24.04、Python 3.11.15（判定の検算）、LibreOffice Calc 24.2.7（数式の計算結果）、@mermaid-js/mermaid-cli 11.14.0 と Chromium 141（Mermaid 図の描画）。確認日は 2026-10-06 です。

この記事の結論

• 要件が固まっていて変更が少ないなら、ウォーターフォール。
• 作りながら確かめたいなら、アジャイル。
• 要件と基盤は先に固めて、機能は反復するなら、ハイブリッド。
• 迷ったら10問の診断で合計点を出します。0〜6点はウォーターフォール、7〜13点はハイブリッド、14〜20点はアジャイルです。

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

18項目の比較表（ウォーターフォール・ハイブリッド・アジャイル）

ハイブリッドを含めた3列で、18項目を比べます。 手法を選ぶ打ち合わせでは、この表を上から読み、自分たちの条件に近い列に印を付けていくと話が進みます。

資料に貼るときは、次の Markdown をコピーしてください。

| No | 比べる点 | ウォーターフォール | ハイブリッド | アジャイル |
|---:|---|---|---|---|
| 1 | 進め方 | 工程を順番に1回ずつ進める | 一部を順番に、一部を反復で進める | 短い期間の反復を重ねる |
| 2 | 計画の立て方 | 最初に全体を詳しく計画する | 全体は大枠、反復部分は直前に詳しく | 全体は大枠、直近の反復だけ詳しく |
| 3 | 要件を決める時期 | 開発の前にすべて決める | 骨格は前に決め、細部は反復の中で決める | 優先順位の高いものから順に決める |
| 4 | 要件変更の扱い | 変更管理の手続きで採否を決める | 固定部分は手続き、反復部分は次の反復で取り込む | 次の反復の計画で取り込む |
| 5 | 納期の見通し | 立てやすい（工程ごとに積み上げる） | 節目の日付は固定しやすい | 期間は固定しやすいが、範囲は動く |
| 6 | 費用の見通し | 立てやすい（範囲が固定） | 固定部分は立てやすく、反復部分は期間で見積もる | 期間と人数で決まる。範囲あたりの費用は動く |
| 7 | 範囲（スコープ） | 固定する | 必須の範囲を固定し、残りを調整する | 優先順位で調整する |
| 8 | 動くものを見られる時期 | 終盤（テスト工程以降） | 反復に入ってから定期的に | 最初の反復の終わりから定期的に |
| 9 | 成果物の単位 | 工程ごとの文書と、最後に完成したシステム | 上流の文書と、反復ごとの動く機能 | 反復ごとの動く機能 |
| 10 | テストの時期 | 実装のあとにまとめて行う | 反復ごとのテストと、最後の全体テスト | 反復のたびに行う |
| 11 | 文書の量 | 多い（工程ごとに承認する文書） | 上流は多め、反復部分は必要な分 | 必要な分に絞る |
| 12 | 体制と役割 | 工程ごとに担当を分けやすい | 固定部分は工程別、反復部分は少人数のチーム | 少人数で役割を兼ねるチーム |
| 13 | 利用者・発注側の関わり | 要件定義と受入テストに集中する | 上流と、反復ごとの確認会 | 反復のたびに確認する |
| 14 | 進み具合の測り方 | 工程の完了と、予定に対する消化の割合 | 節目の達成と、反復ごとの完成数 | 反復ごとに完成した機能の量 |
| 15 | リスクが見える時期 | 結合テスト以降に集まりやすい | 反復部分は早く、固定部分は節目ごと | 反復のたびに少しずつ見える |
| 16 | リリースの回数 | 原則1回（または少数の段階） | 数回に分ける | 小さく何度も出せる |
| 17 | 向く規模 | 大人数・複数チームでも進めやすい | 中〜大規模 | 少人数のチーム（複数チームは工夫が要る） |
| 18 | 向く題材 | 要件が固まっていて変更が少ないもの | 骨格は決まっているが、機能の細部を試したいもの | 作りながら確かめたいもの |

メリットと気を付ける点

アジャイルソフトウェア開発宣言は、動くソフトウェアと変化への対応に価値を置くと述べています。一方で、計画や文書の価値を認めたうえで「より価値を置く」ものを示している点も読み取れます。文書を作らないという意味ではありません。

開発手法の選び方診断（10問・各0〜2点）

10問に0・1・2点で答え、合計点で手法を決めます。 点が高いほど、反復しながら進める手法に向いています。

設問6の「2〜4週間」と設問7の「10人以下」は、スクラムガイド2020の記述（スプリントは1か月以内の決まった長さ、スクラムチームは通常10人以下）に合わせた目安です。そのほかの区切りの数字は例なので、組織に合わせて読み替えてください。

判定表

加えて、次の2つの補助ルールを使います。

表計算に貼れる診断シート

次のタブ区切りを、表計算ソフトのセルA1に貼り付けます。F列（点数）のF2〜F11に0・1・2を入力すると、F12に合計、F13に判定、F14に答えの割れが表示されます。

No  設問  0点  1点  2点  点数
1   要件はどこまで決まっているか  文書で確定している   大枠は決まり細部はこれから   作りながら決めたい   
2   開発中の変更はどのくらい見込まれるか  ほぼ無い    月に数件    毎週のようにある    
3   納期と範囲は動かせるか どちらも固定  納期は固定で範囲は調整できる  どちらも調整できる   
4   費用はどう決めるか   総額を先に確定する   上限を決めて段階ごとに確定する 期間ごとに決める    
5   利用者はどのくらい確認に参加できるか  節目のレビューだけ   月に1〜2回  毎週参加できる 
6   動くものをいつ見たいか 完成時でよい  途中で1〜2回 2〜4週間ごと 
7   チームの人数とまとまり 30人以上または複数拠点    10〜30人  10人以下でまとまっている   
8   文書と承認はどこまで求められるか    工程ごとに承認文書が必須    主要な文書だけ 必要な分でよい 
9   リリースは何回に分けられるか  一括で1回   数回に分ける  小さく何度も出せる   
10  技術や方式の見通し   経験のある方式 一部に新しい要素がある 試さないと分からない  
    合計              =SUM(F2:F11)
    判定              =IF(AND(F12>=14,F4=0,F9=0),"ハイブリッド",IF(F12<=6,"ウォーターフォール",IF(F12<=13,"ハイブリッド","アジャイル")))
    答えの割れ               =IF(AND(COUNTIF(F2:F11,0)>=3,COUNTIF(F2:F11,2)>=3),"割れている","そろっている")

この数式を入れたファイルを LibreOffice Calc 24.2 で開き、点数に「2, 2, 0, 0, 2, 2, 1, 0, 1, 0」を入れたところ、F12は 10、F13は ハイブリッド、F14は 割れている と計算されました。使っている関数は SUM・IF・AND・COUNTIF の4つです。

判定を Python で検算する

同じ判定を Python で書き、5つの回答例と、すべての答え方（3の10乗＝59,049通り）で確かめます。

from itertools import product
from collections import Counter

def judge(answers):
    """answers: 設問1〜10 の点数（各 0, 1, 2）のリスト"""
    assert len(answers) == 10 and all(a in (0, 1, 2) for a in answers)
    total = sum(answers)
    if total <= 6:
        result = "ウォーターフォール"
    elif total <= 13:
        result = "ハイブリッド"
    else:
        result = "アジャイル"
    # 補正：範囲と納期が固定（設問3が0点）で、工程ごとの承認文書も必須（設問8が0点）なら
    # 合計が高くてもハイブリッドにとどめる
    if result == "アジャイル" and answers[2] == 0 and answers[7] == 0:
        result = "ハイブリッド"
    zeros, twos = answers.count(0), answers.count(2)
    mixed = zeros >= 3 and twos >= 3   # 0点と2点が両方多い＝設問ごとに答えが割れている
    return total, result, mixed

samples = {
    "例1 備品予約システムの入れ替え": [0, 0, 0, 0, 1, 0, 1, 0, 0, 0],
    "例2 社内ポータルの新機能":       [2, 2, 1, 2, 2, 2, 2, 2, 2, 1],
    "例3 勤怠入力の刷新":             [1, 1, 1, 1, 1, 1, 1, 1, 1, 1],
    "例4 基盤は固定で画面は試したい": [2, 2, 0, 0, 2, 2, 1, 0, 1, 0],
    "例5 点は高いが範囲と承認が固定": [2, 2, 0, 2, 2, 2, 2, 0, 2, 2],
}
for name, ans in samples.items():
    total, result, mixed = judge(ans)
    print(f"{name}: 合計{total:>2}点 → {result}" + ("（答えが割れている）" if mixed else ""))

# 全 3^10 通りを数えて、しきい値の偏りを確かめる
count, mixed_in_hybrid, corrected = Counter(), 0, 0
for ans in product((0, 1, 2), repeat=10):
    total, result, mixed = judge(list(ans))
    count[result] += 1
    if result == "ハイブリッド" and mixed:
        mixed_in_hybrid += 1
    if total >= 14 and result == "ハイブリッド":
        corrected += 1
n = 3 ** 10
print(f"全{n}通り")
for k in ("ウォーターフォール", "ハイブリッド", "アジャイル"):
    print(f"  {k}: {count[k]}通り（{count[k] / n:.1%}）")
print(f"  ハイブリッドのうち答えが割れている: {mixed_in_hybrid}通り")
print(f"  補正でハイブリッドになった: {corrected}通り")

実行結果です。

例1 備品予約システムの入れ替え: 合計 2点 → ウォーターフォール
例2 社内ポータルの新機能: 合計18点 → アジャイル
例3 勤怠入力の刷新: 合計10点 → ハイブリッド
例4 基盤は固定で画面は試したい: 合計10点 → ハイブリッド（答えが割れている）
例5 点は高いが範囲と承認が固定: 合計16点 → ハイブリッド
全59049通り
  ウォーターフォール: 5193通り（8.8%）
  ハイブリッド: 48708通り（82.5%）
  アジャイル: 5148通り（8.7%）
  ハイブリッドのうち答えが割れている: 25670通り
  補正でハイブリッドになった: 45通り

5つの回答例は、表計算の数式でも同じ合計・判定・答えの割れになることを確認しました。

回答例の読み方

例3と例4はどちらも10点ですが、合う組み方が違います。 合計点だけでなく「答えの割れ」も見るのは、この違いを拾うためです。

ハイブリッドの3パターン

ハイブリッドは「どこを固定し、どこを反復するか」の切り方で3つに分けられます。下のガント図は、架空の備品予約システムを 2026-11-02 に始めた場合の例です（土日を除いて計算）。

パターンA：上流だけ固定して、機能は反復する

gantt
    title パターンA：上流だけ固定して、機能は反復する
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 先に固める
    要件定義           :a1, 2026-11-02, 15d
    基本設計（全体）   :a2, after a1, 15d
    section 反復で作る
    反復1（予約の登録） :b1, after a2, 10d
    反復2（一覧と検索） :b2, after b1, 10d
    反復3（通知と集計） :b3, after b2, 10d
    section 最後にまとめて確かめる
    システムテスト     :c1, after b3, 10d
    受入テスト         :c2, after c1, 5d
    リリース           :milestone, after c2, 0d

要件定義と基本設計で全体の骨格（機能の一覧、データの持ち方、画面の共通ルール）を決め、機能は10営業日の反復で作ります。反復に入る前に「反復の中で変えてよいこと」と「変えるなら手続きが要ること」を分けておくのがこのパターンの要点です。

パターンB：工程は順番のまま、工程の中で反復する

gantt
    title パターンB：工程は順番のまま、工程の中で反復する
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 要件定義
    要件定義               :a1, 2026-11-02, 15d
    section 設計
    基本設計               :a2, after a1, 15d
    詳細設計               :a3, after a2, 10d
    section 実装と単体テスト（2週間ごとに見せる）
    反復1 実装と単体テスト :b1, after a3, 10d
    確認会1                :milestone, after b1, 0d
    反復2 実装と単体テスト :b2, after b1, 10d
    確認会2                :milestone, after b2, 0d
    反復3 実装と単体テスト :b3, after b2, 10d
    確認会3                :milestone, after b3, 0d
    section テスト
    結合テスト             :c1, after b3, 10d
    システムテスト         :c2, after c1, 10d
    受入テスト             :c3, after c2, 5d

工程の順番と承認はウォーターフォールのままにし、実装と単体テストの工程だけを10営業日ごとに区切って、区切りごとに確認会で動くものを見せます。確認会で出た意見は、詳細設計の範囲で直せるものは次の区切りで取り込み、基本設計に及ぶものは変更管理の手続きに回します。

パターンC：領域で分けて並行に進める

gantt
    title パターンC：領域で分けて並行に進める
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 共通
    要件定義（全体の範囲）   :a1, 2026-11-02, 10d
    section 基盤とデータ移行（順番に進める）
    基盤の設計               :w1, after a1, 10d
    基盤の構築               :w2, after w1, 15d
    データ移行の設計と試行   :w3, after w2, 15d
    section 画面と機能（反復で進める）
    反復1                    :g1, after a1, 10d
    反復2                    :g2, after g1, 10d
    反復3                    :g3, after g2, 10d
    反復4                    :g4, after g3, 10d
    section 合流
    結合テスト               :c1, after g4, 10d
    システムテストと受入テスト :c2, after c1, 10d

基盤とデータ移行は順番に、画面と機能は反復で、同じ期間に並行して進めます。2つの流れが合流する結合テストの開始日を先に決め、そこから逆算して両方の計画を立てます。 領域の境目になるインターフェース（画面から呼ぶ処理の入出力など）は、共通の要件定義の中で先に決めておきます。

3パターンの期間（この例での計算）

ガント図の日数を Python で足し、土日を除いて最終日を求めた結果です。

日数は説明用に置いた架空の値です。パターンの優劣ではなく、Bは詳細設計と結合テストを独立した工程として持つぶん長く、Cは並行に進めるぶん短くなるという構造の違いを示しています。

判定からパターンを選ぶ流れ

flowchart TD
    S["診断シートに10問答える"] --> T{"合計点は？"}
    T -- "0〜6点" --> WF["ウォーターフォール"]
    T -- "7〜13点" --> HB["ハイブリッド"]
    T -- "14〜20点" --> AG["アジャイル"]
    HB --> Q1{"0点と2点の設問が<br>どちらも3問以上？"}
    Q1 -- "はい" --> Q2{"点の差は領域の差？"}
    Q1 -- "いいえ" --> Q3{"画面や使い勝手を<br>早く見せたい？"}
    Q2 -- "はい（基盤と画面など）" --> PC["パターンC：領域で分ける"]
    Q2 -- "いいえ（時期の差）" --> PA["パターンA：上流だけ固定"]
    Q3 -- "はい" --> PA
    Q3 -- "いいえ" --> PB["パターンB：工程内で反復"]

スクラム・カンバン・スパイラル・プロトタイピングとの位置づけ

「ウォーターフォールかアジャイルか」を調べると、ほかの名前も出てきます。それぞれ決めている対象が違うので、同じ列に並べて二者択一にするものではありません。

診断との対応でいえば、設問1・10の点が高い（要件や技術が見えていない）のに他の設問が低い場合は、ウォーターフォールの要件定義にプロトタイピングを組み込む形が合います。設問2・9の点が高く期間で区切りにくい保守作業は、カンバンが合います。

手法を選ぶときの判断基準（条件→選ぶもの）

確かめて分かったこと

• 全59,049通りのうち、ハイブリッドと判定されるのは48,708通り（82.5%）でした。ウォーターフォール（8.8%）とアジャイル（8.7%）はほぼ同じ割合です。答えが設問ごとに少しでもばらつくと合計は中央に寄るため、両端の判定は「ほとんどの設問で同じ向きの答えがそろったとき」にだけ出ます。
• ハイブリッドのうち半分以上（25,670通り）は「答えが割れている」状態でした。合計点が同じでも中身が違うことが多く、合計点だけでパターンを決めると合わない組み方を選びやすくなります。
• 補正ルールが効くのは45通りだけでした。まれな組み合わせですが、範囲・納期・承認がすべて固定の状態で反復だけを選ぶと、後から上流の手続きとぶつかるため、ルールとして残しています。
• 診断シートの数式は、Python の判定と5つの回答例すべてで同じ結果になりました。入れ子の IF は外側から順に評価されるので、補正の条件を最初に書く必要があります。
• Mermaid のガント図は、土日を除く指定を書くと「10d」が10営業日として描かれました。暦の日数で数えるとずれるので、期間を営業日で考えるときはこの指定を入れておきます。

つまずきやすい点と整え方

よくある質問

Q. ウォーターフォールとアジャイルの違いは何ですか？ A. 工程を順番に1回ずつ進めるか、短い反復を重ねるかの違いです。ウォーターフォールは要件を先にすべて決めるので納期と費用の見通しを立てやすく、アジャイルは優先順位の高いものから作るので変更を取り込みやすくなります。

Q. ウォーターフォールとアジャイルはどちらが向いていますか？ A. 要件が固まっていて変更が少ないならウォーターフォール、作りながら確かめたいならアジャイルが向いています。判断しにくいときは、この記事の10問の診断で合計点を出すと、条件を1つずつ確認できます。

Q. ハイブリッド開発とは何ですか？ A. ウォーターフォールとアジャイルを、工程や領域で使い分ける進め方です。上流だけ固定する、工程の中で反復する、領域で分ける、の3つの組み方があります。

Q. アジャイルとスクラムの違いは何ですか？ A. アジャイルは考え方の総称で、スクラムはそれを進めるための枠組みの1つです。手法を選ぶ段階ではまずウォーターフォール・ハイブリッド・アジャイルのどれにするかを決め、そのあとでスクラムなどの具体的な進め方を選びます。

Q. 診断の点数が境目（6点と7点、13点と14点）のときはどうすればよいですか？ A. 境目のときは、設問3（納期と範囲）と設問8（文書と承認）の答えを優先して決めます。この2問が0点なら固定の多い側、2点なら反復の多い側を選ぶと、後から手続きとぶつかりにくくなります。

まとめ

• 要件が固まっていて変更が少ないならウォーターフォール、作りながら確かめたいならアジャイル、要件と基盤は先に固めて機能は反復するならハイブリッドです。
• 違いは計画・要件変更・納期と費用の見通し・成果物・テスト時期・文書量・体制など18項目で比べられます。
• 10問・各0〜2点の診断で、0〜6点はウォーターフォール、7〜13点はハイブリッド、14〜20点はアジャイルと判定します。
• 合計点が同じでも中身は違います。0点と2点がどちらも3問以上なら「答えが割れている」と見て、領域で分けることを検討します。
• ハイブリッドは上流だけ固定・工程内で反復・領域で分けるの3パターンから選びます。
• スクラム・カンバン・プロトタイピングは、手法を選んだあとに決める進め方や手段です。

参考

• アジャイルソフトウェア開発宣言（日本語版）https://agilemanifesto.org/iso/ja/manifesto.html
• The Scrum Guide（2020年11月版。スプリントの長さとスクラムチームの人数を確認）https://scrumguides.org/scrum-guide.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。