アジャイルとウォーターフォールの使い分け：混在型の実務

「結局、アジャイルとウォーターフォールはどっちが正しいのか？」――PMや管理職の方ほど、こうした問いに何度も向き合ってきたはずです。ですが現場で必要なのは勝敗ではなく、アジャイル ウォーターフォール 使い分けを“案件の中で成立させる設計”です。稟議・監査・契約・予算は計画志向（ウォーターフォール）になりやすい一方、ユーザー価値・UI・業務要件は学習と変化（アジャイル）を前提としているからです。つまり多くのプロジェクトは最初から混在型 開発（ハイブリッド開発、アジャイル×ウォーターフォール）を避けられません。

ここで強調したいのは、アジャイル ウォーターフォール 使い分けは手法の好みではなく、意思決定と説明責任を両立させるための「設計技術」だという点です。これを言語化できるかどうかが、プロジェクトの収束速度を左右します。

本記事では、アジャイルとウォーターフォールの使い分けを理想論ではなく、プロジェクト管理 実務として再現できる形に落とし込みます。判断フレーム、現場で使える代表パターン、境界（固定するもの／変えるもの）の作り方、契約・見積・KPIまで含めた運用の整え方を、手順ベースで解説します。

1. なぜ今「アジャイル vs ウォーターフォール」ではなく「混在型 開発」なのか

まず前提として、現場では「完全アジャイル」も「完全ウォーターフォール」も成立しにくくなっています。SaaSやクラウドの普及で機能提供のスピードは上がり、ユーザーの期待値や変化も早い。一方で、情報セキュリティ、個人情報、監査対応、社内稟議、外部委託など、説明責任と証跡を求める力も強まっています。この二つを同時に満たすため、開発プロジェクト マネジメントは自然と混在型 開発に寄っていきます。

ただし混在型開発は、放っておくと「合意はウォーターフォール、開発はアジャイル、リリースはまたウォーターフォール」という“二重管理”に陥ります。典型例は、上層にはWBSと進捗率で報告しつつ、現場ではスプリントを回しているのに、優先順位と意思決定が追いつかないケースです。結果として、アジャイルの良さ（学習の速さ）が失われ、ウォーターフォールの良さ（見通しと統制）も崩れます。だからこそ、アジャイルとウォーターフォールの使い分けは「運用の結果」ではなく、最初に設計するものとして扱う必要があります。

重要なのは、開発手法 使い分けを工程ではなく「不確実性の分布」で考えることです。要件が揺れる領域（顧客価値、UI、業務フローの詳細）をアジャイルで学習し、揺れてはいけない領域（法令、セキュリティ、運用、基幹連携のIF）をウォーターフォールで固定する。これがプロジェクト管理 実務としての混在型開発の原則です。

2. 判断フレーム：アジャイル ウォーターフォール 使い分けを決める5つの軸

混在型 開発を感覚で始めると、後半で必ず揉めます。そこで、PMや管理職が最初に行うべきは、アジャイル ウォーターフォール 使い分けの判断を共通言語にすることです。おすすめは次の5軸で、案件を“領域に分解して”判断する方法です。ポイントは「プロジェクト全体をアジャイルにする／WFにする」ではなく、領域ごとに最適化することです。

軸①：仕様の確度と変更頻度。仕様の確度が低く、学習の余地が大きい領域はアジャイル側に寄せます。逆に確度が高く、変更の影響が大きい領域はWF側で固定します。例えば「画面UI」「検索条件」「レポート指標」は変化しやすい一方、「データ保持期間」「権限設計」「監査ログ要件」は変化させにくいことが多いです。

軸②：リスクの種類と重大度。セキュリティ事故、個人情報漏洩、運用停止などのリスクは、スプリント内の自由度だけでは守れません。そこで、ウォーターフォール的なゲート（レビュー・承認）を設け、通過条件を明確化します。これは“遅くするためのゲート”ではなく、高速に安全を確認するためのゲートです。

軸③：依存関係の多さ。外部ベンダー、基幹システム、他部署の意思決定、リリース窓など、依存が多い領域は先に設計しないとスプリントが詰みます。逆に依存が少ない領域は、アジャイルで検証→改善を回した方が価値が出ます。開発プロジェクト マネジメントでは、依存が多いところから固めるのが鉄則です。

軸④：契約・調達・予算の縛り。外部委託では、契約形態（請負／準委任）や検収条件が、実質的に開発手法を決めてしまいます。ここを無視して「アジャイルでやります」と言うと、後で変更管理が破綻します。混在型 開発では、成果物の固定度・レビュー点・変更手続きまで含めて、プロジェクト管理 実務として整合を取ります。

軸⑤：組織成熟度（意思決定と品質の基盤）。PO不在、レビュー文化が薄い、テスト自動化がない、意思決定が週1回しかできない……こうした条件下では、理想的なスクラム運用は難しいです。その場合でも混在型 開発は可能です。やるべきは「運用の現実」に合わせて、意思決定の仕組み（合意会、RACI、優先度ルール）と品質の仕組み（完成の定義、非機能チェック）を先に作ることです。

3. 混在型 開発の代表パターン3つ（現場で再現しやすい“型”）

判断軸で領域分割ができたら、次は運用の型に落とします。混在型 開発は自由度が高い分、型がないと必ずブレます。大事なのは名称ではなく、境界の置き方です。アジャイル ウォーターフォール 使い分けの正解は、案件の制約と不確実性の形で変わります。

パターンA：上流ウォーターフォール＋下流アジャイル。目的、スコープの大枠、非機能、外部IF、移行方針などを先に固め、機能はスプリントで実装・検証します。向いているのは、ステークホルダーが多い社内システムや、監査要件がある案件です。注意点は、上流で機能まで固めすぎると学習が死ぬこと。上流で固めるのは「変えてはいけない前提」に限定し、変える余地を残します。

パターンB：基盤ウォーターフォール＋機能アジャイル。アーキテクチャ、権限、データモデルの境界、セキュリティ・運用設計はウォーターフォール寄りで設計し、機能はアジャイルで価値検証します。向いているのは、将来拡張を見据えたプロダクトや、複数チームが並走する案件です。注意点は、基盤側の設計が遅れると機能側が止まること。基盤設計は完璧より、「最初の安全な境界」を優先し、スプリントで更新できる範囲を明記します。

パターンC：探索アジャイル→収束ウォーターフォール。最初にPoCやスパイクで仮説検証し、要件確度が上がった段階で固定開発に切り替えます。向いているのは、未知の技術要素がある、ユーザーの反応を見て仕様を決めたい、しかし本番移行や監査が重いケースです。注意点は、探索フェーズで「何が決まったか」を残さないと、後半で再議論が起きること。探索の成果は意思決定ログと要求仕様の差分としてまとめ、収束フェーズの入力にします。

4. 運用設計の核心：境界・ゲート・品質保証を“二重管理”にしない

混在型 開発の最大の敵は管理が二重になることです。経営報告用の計画、現場用のスプリント、監査用の証跡、ベンダー用の契約成果物……これらが別々に増殖すると、プロジェクト管理 実務は一気に崩れます。そこで、最初にやるべきは境界を文書で切ることです。境界が曖昧なまま進むほど、アジャイル ウォーターフォール 使い分けが個人技になり、属人化します。

（1）固定するもの／変えるものを層で分ける。おすすめは「目的（Why）」「制約（Must）」「解決策（How）」の3層です。目的は簡単に変えない。制約（法務、セキュリティ、運用）は合意して固定する。解決策（画面、機能仕様、業務フローの詳細）は学習しながら変える。この層別ができると、揉め事が合意形成の手順に変わります。

（2）ゲートは「止める」ためではなく「通す」ために設計する。ゲートは重くしすぎるとアジャイルが死にますが、無いと事故が起きます。そこで、ゲートの通過条件をチェックリスト化し、スプリントに組み込みます。例として、セキュリティは脅威モデリングの実施と対応方針、運用は監視項目とアラート設計、データは移行手順とリハーサル計画、などです。これらを「いつ誰が承認するか」まで決めると、混在型 開発でもスピードと統制が両立します。

（3）品質保証は二層構造にする。ウォーターフォール側では非機能（性能・可用性・保守性）と運用、セキュリティの合格ラインを定義し、アジャイル側では機能品質を完成の定義（DoD）と自動テストで積み上げます。こうすると「最後にまとめてテストして爆発」ではなく、スプリントごとに品質を育てる運用になります。

5. 契約・見積・KPI・体制まで“混在型”に合わせて整える（PM/管理職の勝ち筋）

混在型 開発の設計ができても、契約・見積・KPIがウォーターフォール前提のままだと、実務では失敗します。特に外部委託では「成果物固定」と「変更前提」が衝突しやすく、アジャイル ウォーターフォール 使い分けが一気に難しくなります。ここはPM 実務として先に整える領域です。

契約の整え方。請負でも準委任でも、混在型開発では「レビュー点」「検収の単位」「変更要求の手続き」を明確にします。成果物を固定しすぎるのではなく、アウトカム（何ができるようになるか）を上位に置き、仕様詳細はスプリントで決める範囲として合意します。さらに、非機能・運用・セキュリティの保証範囲を合意文書に落とすと、後半の炎上を避けられます。

見積の整え方。不確実性は予備費で包むより、「検証コスト」として見せる方が意思決定が速くなります。例えば「スパイク2週間で技術的実現性を確認」「PoCでユーザー導線を検証し、要求を確定」といった形で、探索フェーズの成果物（意思決定ログ、学び、決定事項）を明示します。これにより、開発手法 使い分けが説明できる計画になります。

KPIと体制。進捗率だけでは混在型 開発の価値は測れません。リードタイム、欠陥流出、顧客価値（利用率・業務時間削減）など、成果につながる指標を置きます。またPO不在の組織でも回すために、意思決定者（代替PO）を置き、優先度のルールを決めます。RACIで責任を明確にし、週次の合意会を設けるだけでも、運用は格段に安定します。

補足：社内の標準プロセスとして定着させるには、各プロジェクトの冒頭で「アジャイル ウォーターフォール 使い分けの方針」を1枚にまとめるのが効果的です。混在型 開発の境界・ゲート・責任者を図解すると、説明が一気に楽になります。

まとめ：アジャイルとウォーターフォールの使い分けを“混在型の実務”として成功させる

混在型 開発を成功させる鍵は、「混ぜる」のではなく境界を設計することです。アジャイル ウォーターフォール 使い分けは工程論ではなく、不確実性と制約をどう分け、誰がどこで合意し、どのゲートで安全を確認するかというプロジェクト管理 実務そのものです。固定すべきもの（非機能・運用・セキュリティ・IF）を先に固め、学習すべきもの（機能・UX）を短いサイクルで育てる。これだけで、アジャイル×ウォーターフォールは“二重管理”ではなく“両立”に変わります。

もし今、アジャイルとウォーターフォールの使い分けで迷いがあるなら、まずは「固定するもの／変えるもの／ゲート」を文章で定義してみてください。それが混在型開発の最初の一歩です。