アジャイルとウォーターフォールの使い分け｜要件確定度×変化必要性の2軸で手法を選ぶ

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

アジャイルとウォーターフォールの使い分けで迷う根本原因は、「どちらが優れているか」という発想で選ぼうとすることにあります。 結論から言えば、手法の優劣ではなく**「要件の確定度」と「変化への対応必要性」の2軸**でプロジェクトの性質を判断し、それに合った手法を選ぶことが正解です。たとえば要件が曖昧で市場の反応を見ながら進める新規Webサービスにはアジャイルが向き、仕様が確定している法定システム刷新にはウォーターフォールが向きます。本記事では、2軸マトリクスによる判断フレームワーク・ハイブリッド型の選択肢・失敗しない選び方のチェックリストを1本に整理します。

前提：2つの手法の核心的な違いを30秒で再確認

使い分けの前に、両手法の「根本的な違い」を押さえておきます。詳細はアジャイル開発とは？ウォーターフォールとの違いを徹底解説で解説していますが、核心だけ再確認します。

観点	ウォーターフォール	アジャイル
進め方	要件定義→設計→実装→テスト→リリースを順に完結	短いスプリント（2〜4週間）を繰り返して段階的に完成
計画の立て方	最初にすべてを決める（フロントローディング）	大枠のみ決め、詳細はスプリントごとに決める
変更への対応	後戻りが難しくコスト大	スプリント単位で方向修正できる
完成物の見え方	リリース時に初めて全体が見える	スプリントごとに動くものが出る
向く不確実性	低い（要件が固まっている）	高い（要件が揺れる・変化が速い）

Asanaは「ウォーターフォールは計画通りに進めることに強く、アジャイルは変化に対応することに強い」と整理しています。この一文が使い分けの本質を突いています。

---

使い分けの核心：2軸マトリクス

手法の選択は、プロジェクトを2つの軸で評価することから始まります。

• 横軸（X軸）：要件の確定度（高い＝仕様が明確・変わりにくい ↔ 低い＝仕様が曖昧・変わりやすい）
• 縦軸（Y軸）：変化への対応必要性（高い＝市場・ユーザーフィードバックが速く影響する ↔ 低い＝外部変化の影響が少ない）

この2軸で4象限のマトリクスを作ると、手法の選択が機械的に判断できます。

	変化への対応必要性：低	変化への対応必要性：高
要件の確定度：高	🟦 ウォーターフォール最適	🟨 ハイブリッド（WF計画＋AG実行）
要件の確定度：低	🟨 段階型ウォーターフォール	🟩 アジャイル最適

🟦 象限①：ウォーターフォール最適（要件確定×変化少）

代表例： 基幹システム刷新、法定対応システム、インフラ移行、公共システム開発

要件が固まっており、完成後も大きく変わらないプロジェクトです。計画通りに予算・期間・品質を管理することが最大の価値になります。ウォーターフォールが持つ「全体計画の可視性」「マイルストーン管理」「QCの徹底」が活きる場面です。

SINTブログは「要件の確定度が高く、仕様変更がないシステムであれば、ウォーターフォール開発が有効」と整理しています。

🟩 象限④：アジャイル最適（要件不確定×変化多）

代表例： 新規Webサービス・スマホアプリ、スタートアップのMVP開発、AI/ML機能の組み込み、UX改善プロジェクト

要件が曖昧で、ユーザーや市場のフィードバックを取り込みながら方向を決めていくプロジェクトです。スプリントごとに動くものを出し、そのフィードバックで次の優先順位を決めるスクラムが特に有効です。

Goodpatch Blogは「要件が変わる可能性が高い場合、アジャイルであればユーザーの反応や市場の変化に応じて最適な形にブラッシュアップできる」と解説しています。

🟨 象限②：ハイブリッド（要件確定×変化多）

代表例： ECサイトのリニューアル（基本機能は確定、UXは改善しながら）、既存サービスへの新機能追加

基本的な仕様は決まっているが、市場投入後にユーザーの反応を見て機能を磨いていく必要があるプロジェクトです。上流はウォーターフォール（要件定義・基本設計）、下流はアジャイル（詳細設計・実装・テスト） という組み合わせが有効です。

🟨 象限③：段階型ウォーターフォール（要件不確定×変化少）

代表例： 研究開発プロジェクト、技術実証（PoC）後の本格開発

要件は曖昧だが、外部環境の変化は少ないプロジェクトです。まずPoC（概念実証）でアジャイル的に探索し、仕様が固まった段階でウォーターフォールに切り替えるアプローチが有効です。

---

プロジェクト特性チェックリスト（7項目）

マトリクスと合わせて、以下の7項目でプロジェクトを採点してください。

#	チェック項目	ウォーターフォール寄り	アジャイル寄り
1	要件の明確さ	全体要件が文書化できる	「使ってみないとわからない」部分が多い
2	仕様変更の頻度	承認後は変更しない前提	スプリントごとに優先順位が変わりうる
3	ステークホルダー	少数で意思決定が速い	多数・分散しており合意に時間がかかる
4	チームの経験	ウォーターフォールの実績あり	アジャイル・スクラムの経験あり
5	リリース形態	一括リリースでよい	段階的・継続的リリースが望ましい
6	コンプライアンス	厳格な文書・承認管理が必要	ドキュメントより動くものを優先できる
7	規模・予算	大規模・固定予算	中小規模・段階的な投資判断が可能

判断の目安： ウォーターフォール寄りが5項目以上→ウォーターフォール、アジャイル寄りが5項目以上→アジャイル、それ以外→ハイブリッドを検討。

---

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

実務では「純粋なウォーターフォール」か「純粋なアジャイル」かより、ハイブリッド型が多数派です。代表的な3パターンを整理します。

パターン1：フェーズ分割型（最も一般的）

要件定義・基本設計（WF） → 詳細設計・実装・テスト（AG） → リリース（WF品質管理）

上流の計画性とリスク管理はウォーターフォールで担保し、実装フェーズのスピードと柔軟性はアジャイルで確保します。DSKクラウドはこのパターンを「最も取り入れやすいハイブリッド形態」と説明しています。

パターン2：PoC先行型

PoC（AG：2〜4スプリント） → 仕様確定 → 本開発（WF）

新技術や新規事業で「そもそも作れるか・使われるか」が不明な段階でPoC（概念実証）をアジャイルで回し、実現可能性と要件が固まった段階でウォーターフォールに移行します。

パターン3：コアWF＋拡張AG型

コア機能（WF：仕様固定） ＋ 付加機能（AG：スプリント開発）を並走

基幹となる機能はウォーターフォールで堅牢に作り、付加価値機能やUI改善はスプリントで柔軟に進めます。プロダクト成熟期のサービス改善に多いパターンです。

---

よくある使い分けの失敗5選

❌ 失敗1：「アジャイルはなんでも解決する」と思い込む

アジャイルは万能ではありません。要件が固まっているプロジェクトにアジャイルを適用すると、毎スプリントで同じ議論が繰り返され、かえって効率が下がります。手法はプロジェクトの性質に合わせる道具であり、トレンドで選ぶものではありません。

❌ 失敗2：「ウォーターフォールは古い」と捨てる

複雑な要件が文書化された大規模刷新や、法令対応システムにアジャイルを無理に適用すると、スプリントごとに要件の解釈が変わり、後続工程への依存関係が管理できなくなります。ウォーターフォールはいまも有効な手法です。

❌ 失敗3：チームのスキルと合っていない手法を選ぶ

スクラムの経験がないチームにスクラムを強制しても、スプリントプランニングやレトロスペクティブが形骸化します。チームの習熟度と手法の複雑さを一致させることが先決です。

❌ 失敗4：ハイブリッドの「切り替えルール」を決めない

「上流はWF、下流はAG」と決めても、「どのタイミングで切り替えるか」「ベースラインはどこか」を明確にしないと、双方の担当者が「どちらのルールで動けばいいか」わからなくなります。切り替えの基準（例：基本設計承認後にスプリント開始）を明文化してください。

❌ 失敗5：顧客・スポンサーの期待値と手法が噛み合わない

「詳細な計画書と固定納期で動きたい発注者」にアジャイルを提案しても摩擦が生まれます。手法の選択にはステークホルダーの期待値と契約形態も考慮が必要です。アジャイルは準委任契約、ウォーターフォールは請負契約と親和性が高い傾向があります。

---

メリット・デメリット（ProsCons）

---

よくある質問（FAQ）

Q1. アジャイルとウォーターフォール、どちらが主流ですか？

プロジェクトの性質によります。ソフトウェア開発・スタートアップ領域ではアジャイルが主流になりつつありますが、基幹システム・インフラ・公共システムではウォーターフォールが引き続き多数派です。実務ではDSKクラウドが指摘するようにハイブリッドが増えており、どちらかに二分できない案件の方が多くなっています。

Q2. 途中で手法を切り替えることはできますか？

できますが、リスクが伴います。特にウォーターフォールからアジャイルへの途中切り替えは、既存の計画書・承認フローとの整合性を取るコストが発生します。切り替えるなら**フェーズの区切り（例：基本設計承認後）**がタイミングとして妥当です。

Q3. スクラムとウォーターフォールを同じプロジェクトで使えますか？

使えます。「ハイブリッドのパターン1：フェーズ分割型」がその典型例です。ただしスクラムガイド2020は純粋なスクラムの定義を持つため、ハイブリッドの場合は「スクラム風のアジャイル開発」として運用することになります。

Q4. アジャイルはドキュメントを書かなくていいのですか？

書かなくていいわけではありません。アジャイルソフトウェア開発宣言の「包括的なドキュメントより動くソフトウェアを重視する」は「ドキュメントが不要」という意味ではなく「動くものを最優先にする」という優先順位の話です。スペックには最低限必要な文書を残すことが推奨されています。

Q5. PMP®試験ではどちらが重視されますか？

PMP®試験のドメインはPeople／Process／Business Environmentの3つで、アジャイル・ハイブリッド・予測型（ウォーターフォール）の3つのアプローチが横断的に出題されます。特定の手法を「正解」とするのではなく、プロジェクトの状況に応じて最適な手法を選択・適応させる能力が問われます。

---

まとめ：使い分けの判断フレームワーク

アジャイルとウォーターフォールの使い分けは「どちらが良いか」ではなく、プロジェクトの2軸（要件の確定度×変化への対応必要性）でマトリクスに当てはめて判断することが基本です。

• 要件確定×変化少 → ウォーターフォール
• 要件不確定×変化多 → アジャイル
• それ以外 → ハイブリッドを3パターンから選ぶ

チェックリスト7項目でスコアをつけ、手法の候補を絞ったうえで、チームの経験・ステークホルダーの期待値・契約形態まで踏まえて最終判断してください。

手法を選んだ後は、スクラムガイドやベロシティの測定（アジャイル選択時）、あるいはWBS分解（ウォーターフォール選択時）など、選んだ手法の実践に進んでください。