ウォーターフォール vs アジャイル｜発注者がプロジェクト特性で開発手法を選ぶ判断フレーム

「どちらを選ぶか」は手法の優劣ではなく、プロジェクトの特性で決まる

「ウォーターフォールとアジャイル、どちらがよいですか？」という問いを、発注前の検討段階でよく耳にします。しかし、この問い自体に前提の誤りが含まれています。両者に優劣はなく、プロジェクトの特性に合っているかどうかが、唯一の判断軸です。

たとえば、要件が法令や業務規程で固定されている基幹システムの刷新と、ユーザーの反応を見ながら機能を育てていくSaaSプロダクトの開発では、求められる進め方がまったく異なります。前者に「変化への柔軟性」を前提としたアジャイルを当てはめると、スコープが定まらないまま工数だけが膨らむリスクがあります。反対に、後者にウォーターフォールを適用すると、リリース時点ですでに市場ニーズからずれている、という事態も起こりえます。

重要なのは「どちらが正解か」を探すことではなく、自社のプロジェクトにどのような特性があるかを整理したうえで手法を選ぶ、という思考の順序です。この順序を誤ると、手法の選定ではなく手法への依存が始まり、現場の実態と乖離した進め方が定着してしまいます。

本記事では、発注側の意思決定者が開発手法を選ぶための判断材料を、以下の流れで整理します。

• ウォーターフォール開発の工程・特徴・向いているシステムの種類
• アジャイル開発のスプリント構造・特徴・向いているプロジェクトの条件
• 6つの軸による両手法の具体的な比較
• プロジェクト特性から手法を選ぶ4つの問い
• アジャイルが失敗する原因と、発注者側に多い誤解
• 要件定義はウォーターフォール、開発はアジャイルというハイブリッドアプローチの考え方

手法の名称ではなく、プロジェクトの条件から逆算して考える。本記事がその思考の起点になれば幸いです。

ウォーターフォール開発とは — 工程・特徴・向いているシステム

ウォーターフォールモデルは、システム開発をいくつかの工程に分割し、上流から下流へと順番に進める開発手法です。水が上から下へ流れる様子にたとえて「ウォーターフォール」と呼ばれています。各工程の成果物をドキュメントとして確定させてから次工程に進む点が、最大の特徴です。

ウォーターフォールの工程 — 要件定義からリリースまでの流れ

ウォーターフォール開発は、以下の工程を順番に進めます。

1. 要件定義：システムに求める機能・性能・制約を整理し、発注者とベンダーが合意します。この段階で「何を作るか」を文書として確定させます。
2. 基本設計（外部設計）：画面レイアウトやデータの入出力など、利用者から見えるシステムの仕様を設計します。
3. 詳細設計（内部設計）：データベース構造やプログラムのロジックなど、システム内部の実装仕様を定めます。
4. 開発（実装）：設計書をもとにプログラムを作成します。
5. テスト：単体テスト・結合テスト・システムテストの順で、品質を段階的に検証します。
6. リリース・運用：本番環境への展開と、リリース後の保守対応を行います。

各工程は、前工程の成果物が承認されてから開始します。原則として前工程に戻る手順が発生しないよう、上流工程での合意形成を徹底する点がウォーターフォールシステム開発の基本的な考え方です。

ウォーターフォールのメリット — 見積もり精度・品質管理・進捗把握

発注者の立場から見たウォーターフォールのメリットは、主に3点あります。

• コスト・納期の見積もり精度が高い：要件定義の時点でスコープが確定するため、ベンダーは開発規模を定量的に算出できます。予算計上や稟議への対応がしやすく、追加費用が発生するリスクを事前に抑えやすい構造です。
• 品質管理がしやすい：各工程に承認ゲートが設けられるため、問題を早期に発見できます。特に要件定義・設計段階での手戻りを防ぐことで、テスト後に発覚する大規模な欠陥を減らせます。
• 進捗の可視化がしやすい：工程ごとに完了基準が明確なため、「どの工程が何%完了しているか」を把握しやすいです。複数のステークホルダーへの報告が必要な大規模プロジェクトでは、進捗管理の透明性が高まります。

ウォーターフォールが向いているシステムの条件

ウォーターフォールが特に適しているのは、要件が開発開始前に明確に定義できるプロジェクトです。具体的には以下の条件が揃う場合に力を発揮します。

• 法令・規制への対応が必須で、仕様変更の余地が少ないシステム（例：会計システム、人事給与システム）
• 基幹業務の刷新など、業務プロセスが既に安定しており、要件が現行踏襲を中心としているケース
• 官公庁や大企業向けのシステムなど、仕様書・設計書の提出が契約上義務付けられているプロジェクト
• 複数ベンダーが関わるシステム連携案件で、インターフェース仕様を早期に確定させる必要があるケース

一方、要件が曖昧な段階でも開発をスタートしなければならない場合や、リリース後に仕様変更が頻繁に見込まれる場合は、ウォーターフォールの構造がかえって制約になることもあります。この点については、後続のセクションで詳しく整理します。

アジャイル開発とは — スプリント・特徴・向いているプロジェクト

アジャイル開発は、短いサイクルで開発と検証を繰り返しながらシステムを積み上げていく開発手法です。ウォーターフォールが「全工程を順番に完了させる」構造であるのに対し、アジャイルは「動くものを早期に作り、フィードバックをもとに改善し続ける」構造を取ります。

アジャイルの進め方 — スプリントで積み上げる開発サイクル

アジャイル開発の基本単位が「スプリント」です。1〜4週間程度の短い期間を1スプリントとし、計画・開発・テスト・レビューを一巡させます。これを繰り返すことで、機能を少しずつ積み上げていきます。

代表的なフレームワークが「スクラム」です。スクラムでは、開発する機能の優先順位リスト（プロダクトバックログ）をもとにスプリントごとの作業範囲を決め、各スプリントの終わりに発注者を含むステークホルダーへ成果物をデモします。このデモが、要件の認識ずれを早期に発見する機会になります。

アジャイルのメリット — 変化への対応力と早期の価値提供

アジャイルの最大の特性は、要件が途中で変わることを前提とした設計にあります。スプリントのたびに優先順位を見直せるため、市場環境の変化や社内方針の転換にも対応しやすい構造です。また、開発の早い段階から動くシステムを確認できるため、「完成してから使い勝手の問題に気づく」リスクを抑えられます。

アジャイルが向いているプロジェクトの条件

アジャイル開発が力を発揮するのは、次のような条件を持つプロジェクトです。

• 要件が開発開始時点で固まっていない：ユーザーの反応を見ながら仕様を決めていく新規プロダクト開発など
• 市場や事業環境の変化スピードが速い：競合動向や規制変更に応じて機能追加・変更が生じやすいサービス
• 早期リリースによる事業効果を優先したい：全機能の完成を待たず、コア機能だけを先行リリースして検証したいケース
• 発注者側が開発に継続的に関与できる：スプリントレビューへの参加や優先順位決定を担える担当者がいること

一方で、発注者側のリソースや意思決定体制が整っていない場合、アジャイルは期待どおりに機能しないケースも少なくありません。手法の特性と自社の体制を照らし合わせることが、選定の前提になります。次節では、ウォーターフォールとアジャイルを6つの軸で具体的に比較します。

ウォーターフォール vs アジャイル — 6つの軸で比較する

両手法の違いを正確に理解するには、抽象的な説明よりも、発注者が実際に判断を迫られる場面に沿った軸で比較するのが効果的です。ここでは「要件の確定度・変更頻度・納期・予算管理・チーム体制・発注者の関与度」の6軸を基準に整理します。

比較表 — 6つの軸で見るウォーターフォールとアジャイルの違い

以下の表は、発注者が自社プロジェクトの条件と照合しやすいよう、各軸の典型的な傾向をまとめたものです。

各軸にこうした差が生まれる背景は、それぞれ以下の理由によります。

• 要件の確定度：ウォーターフォールは設計書を起点に工程が連鎖するため、上流での要件漏れが後工程に影響します。アジャイルは動くソフトウェアを見ながら要件を育てる設計思想のため、曖昧さを前提にしています。
• 変更頻度：ウォーターフォールでの仕様変更は設計書の修正から始まり、下流工程の手戻りを伴うため、変更コストが高くなりがちです。アジャイルはイテレーション（反復）の中に変更を取り込む仕組みを持っています。
• 納期：ウォーターフォールは工程の終端に一括リリースを置くため日程が明確です。アジャイルは機能単位でリリースを重ねるため、「いつ全機能が揃うか」は状況によって変わります。
• 予算管理：ウォーターフォールは一括請負契約と相性がよく、総額管理が容易です。アジャイルはタイム＆マテリアル（実作業時間に応じた精算）契約が多く、予算に上限を設けないと超過リスクが生じます。
• チーム体制：ウォーターフォールは要件定義・設計・開発・テストを別チームが担うことも珍しくありません。アジャイルは同一チームが一貫して関与するため、コミュニケーションロスが少ない反面、特定メンバーへの依存が生まれやすい面もあります。
• 発注者の関与度：ウォーターフォールは要件確定と最終検収が主な接点となります。アジャイルは2〜4週間ごとのスプリントレビューに担当者が参加し、優先度を都度判断する必要があります。

発注者にとって最も影響が大きい違い — 要件変更コストと関与頻度

6つの軸の中で、発注者の実務に直結するのは「変更頻度（変更コスト）」と「発注者の関与度」の2点です。

ウォーターフォールで仕様変更が発生すると、設計書の修正・再レビュー・コードの書き直しが連鎖的に発生します。開発の後半に差し掛かるほど変更コストは指数関数的に増大するため、「決まったものを正確に作る」ことへの前提が崩れると、スケジュールと予算の両面で大きなリスクになります。

一方、アジャイルでは変更自体は吸収しやすい構造ですが、発注者が毎スプリントの優先度判断に参加しないと、開発の方向性がずれていきます。「任せておけば完成する」という感覚で臨むと、意図とは異なる機能が積み上がるケースが少なくありません。発注者側にも一定の工数と意思決定の速さが求められる点は、手法選定の前に把握しておく必要があります。

どちらを選ぶか — プロジェクト特性で判断する4つの問い

開発手法の選定は、スキルや好みではなくプロジェクトの特性で決まります。以下の4つの問いに順番に答えることで、ウォーターフォール・アジャイル・ハイブリッドのいずれが適切かを絞り込むことができます。

問い1：要件定義の時点で仕様をほぼ確定できるか

法定帳票の出力仕様や既存システムの移行要件など、業務ルールが明文化されていて変更余地がほとんどないケースでは、ウォーターフォールが機能しやすいです。一方、「どんな機能が必要かは使いながら確かめたい」という状態であれば、仕様を固めてから着手するウォーターフォールは向いていません。

• 仕様を確定できる → ウォーターフォールを候補に残す
• 仕様が流動的 → アジャイルまたはハイブリッドへ進む

問い2：リリース後の継続的な改善が事業上の前提になっているか

カスタマーポータルや社内業務アプリのように、ユーザーの反応を見ながら機能を育てていくことが事業計画に組み込まれている場合は、アジャイルの反復開発と親和性が高いです。一方、一度リリースして数年は安定稼働させるだけのシステムであれば、継続的なスプリントを維持するコストが無駄になることも少なくありません。

• 継続改善が前提 → アジャイルを候補に残す
• 安定稼働が主目的 → ウォーターフォールを候補に残す

問い3：発注者側がスプリントレビューに週次で関与できるか

アジャイルでは、2週間ごとのスプリントレビューで発注者がフィードバックを出すことが前提になります。情報システム担当者が1〜2名しかおらず、他業務と並行して週次の判断を継続的に出すことが難しい体制では、アジャイルはうまく機能しないケースがほとんどです。

• 週次関与できる体制がある → アジャイルを継続検討
• 関与リソースが限られる → ウォーターフォールまたはハイブリッドへ切り替える

問い4：法令・監査・他システムとの厳密な連携が求められるか

金融・医療・公共領域のシステムでは、法令対応の仕様書や監査証跡が求められることがあります。また、基幹システムとのAPI連携仕様が相手側の都合で固定されているケースでは、途中で仕様を変えられるアジャイルの柔軟性がかえって管理コストを高めることがあります。

• 法令・監査・厳密な連携仕様がある → ウォーターフォールまたはハイブリッド（要件定義はウォーターフォール）
• 制約が少ない → アジャイルも選択肢に残る

判断まとめ — 4つの問いから導く手法の選び方

4つの問いへの回答を組み合わせると、以下のように手法が絞り込まれます。

• 問い1〜4がすべて「確定・安定・困難・あり」→ ウォーターフォールが適切です
• 問い1〜3が「流動的・継続改善・関与できる」、問い4が「制約少」→ アジャイルが適切です
• 問い1が「ある程度確定」、問い2〜3が「改善前提・関与可能」、問い4が「制約あり」→ 要件定義フェーズをウォーターフォールで固めてから開発をアジャイルで進めるハイブリッドアプローチを検討する価値があります

開発手法の選び方で重要なのは、どちらが「優れているか」ではなく、自社の体制と案件の性質にどちらが「合っているか」です。この4つの問いは、その判断を発注者側の言葉で整理するための起点になります。

アジャイルが失敗する原因 — 発注者側の誤解と準備不足

アジャイル開発を選んだにもかかわらず、期待した成果が出なかったというケースは少なくありません。その原因の多くは、技術的な問題ではなく、発注者側の関与の仕方や事前準備の設計ミスにあります。アジャイルの失敗原因を正しく理解しておくことが、手法選定と発注設計の精度を高める前提となります。

失敗パターン1：発注者がスプリントに関与せず、ベンダーに丸投げになる

アジャイル開発では、スプリントと呼ばれる短い開発サイクルごとに、発注者側が優先順位の判断や成果物の確認を行う必要があります。この役割を担うのが「プロダクトオーナー」です。しかし発注者側にプロダクトオーナーが実質的に不在で、確認作業をベンダーに委ねてしまうケースが多く見られます。

この状態が続くと、開発の方向性が発注者の業務実態から乖離していきます。スプリントレビューは形式的なものになり、後から「思っていたものと違う」という認識のズレが表面化します。アジャイルは発注者の継続的な意思決定を前提とした手法であり、丸投げとは構造的に相性が悪いことを理解しておく必要があります。

失敗パターン2：「後で変えられる」という前提で要件整理を省略する

アジャイルには仕様変更への柔軟性があります。しかしこれは「最初から要件を何も決めなくていい」という意味ではありません。「後で変えればいい」という考えのもと、初期の要件整理や業務フローの確認を省いてしまうと、スプリントを重ねるたびに手戻りが発生し、開発コストと期間が膨らんでいきます。

アジャイルで柔軟に変更できるのは、ある程度の方向性と優先順位が合意されている前提があってこそです。目的や解決すべき業務課題が曖昧なまま開発を始めることは、変更を繰り返す口実になりやすく、プロジェクト全体の収束を難しくします。

失敗パターン3：予算の上限が見えないまま開発が継続する

アジャイル開発は、スプリントを積み重ねる構造上、費用が積み上がっていきます。スコープを柔軟に変更できる反面、最終的な総費用が見えにくくなる性質があります。予算管理の設計をあいまいにしたまま開発を進めると、気づいたときには当初の予算を大幅に超えていたという事態になりかねません。

発注者側には、スプリントの単価設定・想定するスプリント数・変更が生じた際の費用精算ルールを、契約段階で明確にしておく責任があります。「アジャイルだから都度調整できる」という前提で予算管理を後回しにすることは、アジャイルの失敗原因として特に頻度の高いパターンです。

失敗を防ぐために発注前に確認すべきこと

上記の失敗パターンに共通するのは、アジャイルに必要な「発注者側の能動的な関与」が設計されていない点です。発注前に以下の3点を確認しておくことで、構造的なリスクを減らすことができます。

• プロダクトオーナーを誰が担うか：社内で意思決定できる担当者をスプリントに継続的に関与させられるか確認する
• 要件の初期整理にどこまで時間をかけるか：目的・対象ユーザー・優先度の高い機能群を発注前にある程度言語化しておく
• 予算の上限と精算ルールを契約に明記するか：スプリント単価・想定期間・変更時の費用負担ルールをベンダーと合意しておく

アジャイル開発の注意点は、手法そのものの複雑さよりも、発注者側の準備と関与の設計にあります。この認識を持ったうえでベンダー選定に臨むことが、プロジェクトの成否を分ける重要な前提となります。

ハイブリッドアプローチという選択肢 — 要件定義はウォーターフォール、開発はアジャイル

ウォーターフォールとアジャイルは二択ではありません。エンタープライズ開発の現場では、両者を組み合わせたハイブリッドモデルが多く採用されています。「要件定義・基本設計はウォーターフォールで固め、実装フェーズをアジャイルで回す」という構造がその典型です。発注者にとっては、リスク管理と柔軟性を同時に確保できる現実的な選択肢といえます。

ハイブリッドモデルが有効な場面

ハイブリッドモデルが機能しやすいのは、次のような条件が重なるプロジェクトです。

• 全体スコープは確定しているが、画面設計や機能の優先順位は変わりうる：業務フローは固まっているものの、ユーザーの使い勝手は試しながら改善したいケース
• 予算・納期の上限が決まっている：完全アジャイルでは予算の着地点が読みにくいため、フェーズ前半をウォーターフォールで見積もり根拠を作る
• 社内承認プロセスが必要：要件定義書・基本設計書といった成果物が意思決定層への説明責任を果たす文書として機能する

CLANEが手がける案件でも、基幹業務に隣接するWebアプリや社内向けダッシュボードの開発においてこの構造を採用するケースが増えています。要件定義フェーズで業務要件と非機能要件を文書化したうえで、実装はスプリント単位で進めることで、手戻りの少ない開発と段階的な品質検証を両立しています。

ハイブリッドを選ぶ際にベンダーに確認すべき体制・契約の論点

ハイブリッドモデルは、設計が適切でないと「ウォーターフォールの硬直性とアジャイルの不確実性を両方抱える」という最悪の結果になりかねません。ベンダーに対して以下の点を事前に確認することをお勧めします。

• 契約形態の切り替え：要件定義フェーズは請負契約、実装フェーズは準委任契約とするケースが多いです。フェーズごとの契約構造を明確にするよう求めてください。
• 要件変更の吸収ルール：スプリント中に発生した仕様変更をどう扱うか。バックログに積み直すのか、追加費用が発生するのかを確認します。
• 発注者側の関与頻度：アジャイルフェーズでは、スプリントレビューへの参加やプロダクトオーナー役の担当者設置が必要になります。社内リソースの確保が前提となります。

開発手法の選定は、ベンダーの得意な進め方に合わせるのではなく、自社プロジェクトの特性から逆算することが重要です。ハイブリッドモデルはその柔軟な選択肢の一つとして、検討の俎上に載せる価値があります。

まとめ — 発注者が手法選定で押さえるべき3つの視点

ウォーターフォールとアジャイルのどちらを選ぶかは、手法の優劣で決まるものではありません。記事全体を通じて伝えてきたポイントを、発注者として次のアクションに進むための視点として3点に整理します。

視点1：手法の優劣ではなく、プロジェクト特性で選ぶ

「アジャイルのほうが現代的」「ウォーターフォールは古い」という印象で手法を選ぶのは、判断の誤りにつながりやすいです。要件が固まっており、規制対応や他システムとの連携が多い業務システムであれば、ウォーターフォールのほうが予算・納期・品質の管理がしやすい場面も多くあります。一方、ユーザーの反応を見ながら機能を磨いていくサービス開発には、アジャイルが適しています。「何を作るか」がどの程度明確かという問いから、手法選定を始めてください。

視点2：アジャイルは、発注者側の関与コストが高い

アジャイル開発は、発注者が週次・隔週単位で意思決定に関わることを前提としています。仕様の確認、優先順位の判断、フィードバックの提供——これらを継続的に担える体制が社内になければ、スプリントが形骸化し、開発が迷走するリスクがあります。アジャイルを選ぶ前に、「誰がプロダクトオーナーの役割を担えるか」を社内で確認することが不可欠です。

視点3：ハイブリッドが現実解になるケースは少なくない

要件定義フェーズはウォーターフォールで丁寧に固め、開発フェーズはアジャイルで反復しながら進めるハイブリッドアプローチは、多くのBtoB開発プロジェクトで現実的な選択肢となっています。どちらか一方に絞り込もうとするよりも、フェーズごとに適した進め方を組み合わせるという発想を持っておくと、ベンダーとの相談もスムーズに進みます。

手法選定に正解はありませんが、プロジェクトの性質・社内体制・要件の確定度という3つの軸を整理しておくことで、ベンダーとの初回打ち合わせの質が大きく変わります。まずは「要件はどの程度固まっているか」「開発中に変更が生じる可能性はどのくらいか」を社内で棚卸しするところから始めてみてください。