ウォーターフォール開発とアジャイル開発
——発注者が知っておくべき違い

「ウォーターフォールとアジャイル、どちらがいいですか？」という質問をよく受けます。ただ、発注者にとって重要なのは「どちらが優れているか」ではなく、「それぞれの進め方で発注者の関わり方がどう変わるか」です。

知らないまま発注すると、「なぜこんなに確認を求められるのか」「なぜ途中で費用が変わるのか」という疑問が解消されないまま開発が進みます。この記事では、2つの開発方式の違いを発注者の視点から整理します。

ウォーターフォール開発は、工程を順番に進める方式です。要件定義→設計→実装→テスト→リリースという流れで、前の工程が完了してから次に進みます。家を設計図通りに建設するイメージです。最初に全体の設計図を確定するため、発注者はプロジェクト全体の像を把握しやすいという特徴があります。

アジャイル開発は、短いサイクル（イテレーション）を繰り返しながら開発を進める方式です。優先度の高い機能から順番に作り、2〜4週間ごとに動くものを確認しながら次に作るものを決めていきます。変化に柔軟に対応できる反面、最終的な全体像はイテレーションを重ねるなかで徐々に明確になっていくため、最初の段階では全体像が見えづらいという側面があります。

ウォーターフォールでは、発注者が最も重要な役割を果たすのは最初の要件定義フェーズです。ここで「何を作るか」を確定させ、以降は開発会社に任せる形になります。承認のタイミングは各工程の完了時です。したがって、実装の工程に入ると、実装が終わるまで承認のタイミングはありません。

アジャイルでは、発注者が開発期間中ずっと関与し続ける必要があります。イテレーションごとに動くものを確認し、「これでよいか」「次は何を作るか」を判断し続けます。要件は開発中に変えることができますが、その分発注者の時間と判断力が必要です。

ウォーターフォールでは、要件定義が完了した後の変更は追加費用・納期延長が発生します。ただし「ウォーターフォールでは変更できない」というのは誤解です。変更管理のプロセスを通じて、要件定義完了後でも変更を受け付けてもらえます。重要なのは「変更が発生した場合、費用・納期への影響をいつ・どう通知するか」を事前にルール化しておくことです。

アジャイルでは、変更を前提とした進め方なので、イテレーションの計画段階であれば比較的柔軟に対応できます。ただし変更が増えると当初の目標から外れていくリスクがあり、スコープ管理が重要になります。

スコープ管理とは、プロジェクト開始前に開発会社と発注者が「プロダクトバックログ（作りたい機能・要件の優先順位付きリスト）」を合意することから始まります。大枠の優先順位と完了条件を合意した上で、イテレーションごとに「今回何を作るか」を確認・調整していく形を指します。「大枠は最初に決め、詳細は変えられる」という理解が正確です。

ウォーターフォールは請負契約で進めるケースが多く、その場合は契約時点で総額が確定します。発注者にとって予算の見通しが立てやすいというメリットがあります。

アジャイルは準委任契約で進めるケースが多く、イテレーションごとに費用が発生する形になります。なお準委任契約には「履行割合型」と「成果完成型」があります。履行割合型は作業量に応じて費用が発生し完成責任はありませんが、成果完成型は成果物の完成が条件になります。どちらの型で契約するかを事前に確認することが重要です。

ウォーターフォールでは、テスト工程が明確に分かれています。「テスト期間中は何をやっているか」が発注者にも把握しやすく、テスト完了のタイミングで品質を確認できます。ただし、テストフェーズまで実際の動作が見えないため、品質の問題が発覚するのが遅くなりやすいという側面があります。

アジャイルでは、各イテレーションの中でテストが行われます。動くものを毎イテレーション確認できるため、品質の問題を早い段階で発見しやすいというメリットがあります。一方で、イテレーションごとのテストが発注者には見えにくく、「きちんとテストされているか」が不透明になりやすいという側面もあります。

どちらの方式でも、発注者として「何をどうテストしているか」を確認することが重要です。特にアジャイルでは、イテレーションのレビューやテストに発注者が積極的に参加することが品質確保の鍵になります。

• 要件定義の段階で「作るもの・作らないもの」を書面で確定する
• 各工程の完了基準と承認ルールを事前に決める
• 「詳細は後で」という先送りをしない
• 変更が発生した場合の費用・納期への影響通知ルールを契約段階で合意しておく
• 製造フェーズ以降も進捗確認の仕組みを意図的に持つ

• イテレーションごとのレビューに必ず参加する
• 「動けばOK」ではなく「業務に合っているか」を確認する
• 変更の優先順位を自分たちで判断し続ける
• 準委任契約の型（履行割合型か成果完成型か）を事前に確認した上で発注する
• スコープが際限なく拡大しないよう、追加要望の優先順位を管理する

ウォーターフォール開発では、要件定義・設計フェーズでは発注者も打ち合わせに参加する機会が多くあります。しかし製造フェーズに入ると、開発会社の内部作業が中心になり、発注者の関与が自然と減っていきます。

この「見えなくなる」タイミングこそが危険です。開発会社側には「まだ挽回できる」「報告するほどではない」という心理が積み重なり、問題の報告が遅れやすくなります。この両者の姿勢が重なったとき、進捗のブラックボックス化が一気に進みます。

ブラックボックス化が進むと、遅延を早期に検知できず納期直前に発覚する、問題が雪だるま式に膨らむ、完成物と発注者のイメージのズレが拡大するといったことが起きます。

だからこそ、ウォーターフォールで発注する場合は「進捗確認の仕組みを意図的に作る」ことが重要です。

• 週次で完了タスク・残タスク・懸念事項を数値で報告してもらう
• 「オンスケです」という報告を鵜呑みにしない
• 問題が発覚したときの報告・対応ルールを契約段階で決めておく

アジャイルは「要件が変わっても大丈夫」な開発方式なので、最初から仕様を細かく決めなくてよいと思われがちです。しかし「変更に対応できる」ことと「何も決めなくてよい」はまったく別の話です。

最初のイテレーションで作るものが決まっていなければ、開発は始まりません。アジャイルでも「今このイテレーションで何を作るか」は明確に決める必要があります。アジャイルが柔軟なのは「後から変えられる」という意味であって、「今決めなくてよい」という意味ではありません。

変更を前提とした進め方のため、「ついでにこれも」「やっぱりあれも」という要望が積み重なりやすくなります。イテレーションごとに「今回何を作るか」の優先順位を発注者自身が判断し、スコープをコントロールし続ける必要があります。

アジャイル開発は準委任契約で進めるケースが多く、履行割合型の場合は完成責任がありません。準委任契約の型（履行割合型か成果完成型か）を事前に確認した上で発注することが重要です。

ウォーターフォールとアジャイルにはそれぞれ落とし穴があることを踏まえ、実際のプロジェクトでは両者のいいとこ取りをする「ハイブリッド開発」が採用されるケースも増えています。

たとえば、要件定義・基本設計のフェーズはウォーターフォールで全体像をしっかり固め、実装フェーズはアジャイルのイテレーションで柔軟に進めるという組み合わせが代表的です。前半で「何を作るか」の認識をそろえた上で、後半は動くものを確認しながら精度を高めていく進め方です。

発注者として重要なのは、「どちらの方式か」よりも「なぜその進め方を提案しているのか」を開発会社に確認することです。ハイブリッドを含め、プロジェクトの特性に合った進め方を選んでいるかどうかが、開発会社を見極めるポイントにもなります。

発注者側で決めるというよりも、開発会社が提案する方式を理解した上で「なぜその方式なのか」を確認することが重要です。

ウォーターフォールが向いているのは、要件が最初から明確で変更が少ないシステムです。業務基幹系・会計系など、仕様が法律や規定で決まっているケースが典型です。アジャイルが向いているのは、何を作るかを探りながら進める必要があるシステムです。新しいサービスのMVP（最小限の製品）や、ユーザーの反応を見ながら改善していくプロダクトが典型です。

どちらでも「発注者が関与しないプロジェクトは失敗しやすい」という点は共通しています。

発注の失敗を防ぐために最も重要なのは、開発方式への理解と、発注者自身が「関与し続ける」という姿勢です。どちらの方式を選んでも、発注者が適切に関与することがプロジェクト成功の鍵になります。