「要件が決まらないからアジャイル」は危険｜ウォーターフォールとアジャイルの正しい使い分け

発注側が知っておきたい、開発方式の選び方と現場運用

こんにちは。
Digitectの西川です。

システム開発の進め方を検討するとき、たまに議論になるのが「ウォーターフォールで進めるべきか」「アジャイルで進めるべきか」というテーマです。

ウォーターフォールは古い。
アジャイルの方が柔軟で速い。
いや、アジャイルは管理が難しく、品質が担保しにくい。

このような議論はよくありますが、「どちらが優れているか」という話ではありません。

重要なのは、開発するシステムの性質、関係者の数、契約形態、検収方法、品質管理の難易度に応じて、適切な進め方を選ぶことです。

特に発注側にとって重要なのは、「要件が曖昧だからアジャイルにする」という安易な判断を避けることです。要件を定義できない状態をそのまま開発工程に持ち込むと、アジャイルであってもウォーターフォールであっても、手戻り・追加費用・品質低下のリスクは高まります。

本記事では、ウォーターフォールとアジャイルをどのように使い分け、必要に応じてどう混ぜるべきかを整理します。

---

まず結論：外部ベンダーに開発を依頼する場合は、ウォーターフォールを軸に考えるのが現実的

最初に結論を述べると、企業が外部ベンダーにシステム開発を発注する場合、基本的にはウォーターフォール型を軸に検討するのが現実的です。

ウォーターフォール型をおすすめする理由はシンプルです。
発注側のシステム開発では、多くの場合、以下の要素が求められるからです。

• 何を作るのかを事前に合意する必要がある
• 予算と納期を管理する必要がある
• 契約範囲を明確にする必要がある
• 検収条件を定義する必要がある
• 業務部門、情報システム部門、経営層など複数の関係者が関与する
• リリース後に業務へ与える影響が大きい

このような条件では、「最初に要件を整理し、設計し、実装し、テストし、検収する」というウォーターフォール型の考え方が、発注・管理・品質保証の面で扱いやすくなります。

一方で、ウォーターフォールだけで進めると、利用者のフィードバックを取り込みにくい、実際に画面を見て初めて認識齟齬に気づく、といった問題もあります。

そのため、現実的には「ウォーターフォールをベースにしながら、必要な部分にアジャイル的な進め方を取り入れる」ことが有効です。

---

ウォーターフォールを検討すべきシステム

ウォーターフォールが向いているのは、開発対象や利用目的がある程度明確で、事前に要件を整理できるシステムです。

特に、以下のような場合はウォーターフォールを軸に考えるべきです。

---

1. 利用者や用途が明確なシステム

利用者、利用シーン、業務フローが明確なシステムは、ウォーターフォールと相性が良いです。

例えば、以下のようなシステムです。

• 社内業務システム
• 申請・承認システム
• 販売管理システム
• 請求管理システム
• 顧客管理システム
• 既存業務を置き換えるシステム

これらは、誰が、いつ、何のために使うのかが比較的明確です。

もちろん、細かい仕様は要件定義の中で整理する必要があります。しかし、業務そのものが存在しており、現行運用や帳票、Excel、既存システムなどの参考材料がある場合、要件を定義することは十分可能です。

このようなシステムで「要件がまだ曖昧なのでアジャイルで進めましょう」としてしまうと、単に要件定義を後工程へ先送りしているだけになることがあります。

発注側としては、まず業務・画面・データ・権限・帳票・外部連携などを整理し、開発範囲を明確にすることが重要です。

---

2. 大規模なシステム

開発規模が大きいシステムも、ウォーターフォールを軸にした方が管理しやすくなります。

規模が大きくなるほど、以下のような管理対象が増えます。

• 関係者
• 機能数
• 画面数
• データ項目
• 外部連携
• テスト観点
• 移行対象データ
• 運用設計
• セキュリティ要件
• 非機能要件

これらを曖昧なまま開発に入ると、後からの手戻りが非常に大きくなります。

特に大規模システムでは、ある機能の仕様変更が、別の機能、データベース設計、外部連携、テスト計画に影響することがあります。

小さなWebサービスであれば、変更しながら作ることも可能です。しかし、基幹業務や複数部門が利用するシステムでは、変更の影響範囲が大きく、都度方針を変えながら進めることは簡単ではありません。

そのため、大規模なシステムでは、最初に全体構造を設計し、工程ごとに成果物を確認しながら進めるウォーターフォール型が適しています。

---

3. 複数のシステムが絡み合う複雑なシステム

外部システムや既存システムとの連携が多い場合も、ウォーターフォールを重視すべきです。

例えば、以下のようなケースです。

• 販売管理システムと会計システムを連携する
• ECサイトと在庫管理システムを連携する
• 顧客管理システムとポイント管理システムを連携する
• 外部API、決済サービス、DWH、BIツールなどと接続する
• 既存システムから新システムへデータ移行する

このようなシステムでは、自社だけで仕様を決められない領域が多くなります。

連携先システムの仕様、データ形式、API制約、処理タイミング、エラー時の扱い、責任分界点などを明確にしなければなりません。

ここを曖昧にしたまま開発すると、「自システムは正しく動いているが、連携先との整合性が取れない」「データ移行後に業務が止まる」「障害時にどちらの責任か判断できない」といった問題が発生します。

複数システムが絡む開発では、自由度よりも、整合性・影響範囲管理・責任分界点の明確化が重要です。

そのため、ウォーターフォール型で全体設計を固めた上で、段階的に開発・テストを進める方が安全です。

---

アジャイルを検討すべきシステム

一方で、アジャイルが有効な場面もあります。

アジャイルが向いているのは、「何を作るべきか」よりも、「ユーザーに受け入れられるか」「どの方向に伸ばすべきか」の不確実性が高いシステムです。

典型的には、以下のようなケースです。

• 新規サービス
• 新規プロダクト
• 顧客向けアプリ
• ユーザー行動を見ながら改善するWebサービス
• 社内の新しい業務改善ツール
• PoCや実証実験

このようなシステムでは、最初から完璧な要件を定義することが難しい場合があります。

なぜなら、正解が社内に存在していないからです。

業務システムであれば、現行業務や既存帳票をもとに要件を整理できます。しかし、新規サービスの場合、ユーザーが本当に使うか、どの機能に価値を感じるか、どの導線で離脱するかは、実際に出してみなければ分からないことがあります。

この場合は、最初から大きな仕様書を作って一括開発するよりも、小さく作り、早く出し、反応を見て改善する方が合理的です。

つまり、アジャイルは「要件定義から逃げるための手法」ではなく、「市場やユーザーの反応を学習するための手法」です。

ここを誤解してはいけません。

---

「要件が決められないからアジャイル」は危険

発注側が特に注意すべきなのは、「要件が決められないのでアジャイルで進めたい」という考え方です。

これは一見、柔軟で合理的に見えます。しかし実際には、開発方式の問題ではなく、発注側の意思決定や業務整理が未完了であるケースが多くあります。

例えば、以下のような状態です。

• 業務フローが整理されていない
• 誰が使うのか決まっていない
• 必須機能と任意機能の区別がない
• 現行業務の課題が言語化されていない
• 承認者や意思決定者が曖昧
• 予算とスコープの優先順位が決まっていない
• 検収条件を定義できていない

この状態でアジャイルを選択しても、開発がうまくいくわけではありません。

むしろ、スプリントのたびに方針が変わり、作っては戻し、作っては修正し、最終的に何が完成条件なのか分からなくなる危険があります。

アジャイルは、無計画に進めてもよいという意味ではありません。

アジャイルであっても、プロダクトの目的、優先順位、意思決定者、予算上限、リリース判断、品質基準は必要です。

これらがないまま開発を始めると、柔軟性ではなく、単なる混乱になります。

---

動くものを見たいなら、まずAIでプロトタイプを作ればよい

発注側からよく出る要望に、「仕様書だけではイメージが湧かない」「まず動くものを見たい」というものがあります。

これは自然な要望です。

画面遷移、入力項目、検索条件、一覧表示、操作感などは、文章や表だけでは伝わりにくいことがあります。実際に画面を見ることで、利用者や業務部門から具体的な意見が出やすくなるのも事実です。

ただし、「動くものを見たい」という理由だけで、いきなりアジャイル開発にする必要はありません。

現在は、AIを活用すれば、画面モックや簡易的なプロトタイプを以前よりも短時間で作成できます。

例えば、以下のようなものは比較的早く作れます。

• 画面イメージ
• 入力フォーム
• 一覧画面
• 詳細画面
• 簡単な画面遷移
• サンプルデータを使った操作デモ
• 業務フローに沿った簡易プロトタイプ

これらは本番システムそのものではありません。品質、セキュリティ、拡張性、保守性を担保した完成品とは別物です。

しかし、要件定義のたたき台としては非常に有効です。

つまり、発注側が「動くものを見ながら要件を詰めたい」のであれば、最初からアジャイル開発にするのではなく、要件定義工程の中でAIを活用したプロトタイプを作る方法があります。

この進め方であれば、ウォーターフォールの管理しやすさを維持しながら、アジャイル的な確認・改善のメリットも取り入れられます。

---

ウォーターフォールとアジャイルの“正しい混ぜ方”

実務では、ウォーターフォールとアジャイルを完全に分けて考える必要はありません。

重要なのは、「どの工程に、どの考え方を取り入れるか」です。

代表的な混ぜ方は、以下の3つです。

---

混ぜ方1：全体はウォーターフォール、画面・操作感は短い反復サイクルで詰める

最も現実的で、多くの発注側におすすめしやすい進め方です。

全体の進め方はウォーターフォールをベースにします。

全体の工程、契約範囲、成果物、検収条件はウォーターフォール型で管理します。一方で、画面や操作感、入力項目、一覧表示、業務部門との認識合わせについては、プロトタイプを使いながら短いサイクルで確認・修正を繰り返します。

ここで重要なのは、プロトタイプを一度作って終わりにしないことです。画面を見せ、フィードバックを受け、修正し、再度確認する。この反復的な進め方を要件定義工程の中に組み込むことで、ウォーターフォールの管理しやすさと、アジャイル的なフィードバックの取り込みやすさを両立できます。

---

混ぜ方2：MVPで仮説検証し、本開発はウォーターフォールで進める

新規サービスや新規事業に近いシステムでは、最初から大規模に作り込むのではなく、まずMVPで仮説検証を行う進め方が有効です。

MVPとは、Minimum Viable Productの略で、ユーザーに価値を届けられる最小限のプロダクトを指します。

この進め方では、最初から詳細な仕様をすべて固めるのではなく、まず「ユーザーは本当にこの機能を使うのか」「この導線で価値が伝わるのか」「どの機能を優先すべきか」といった仮説を、小さなプロダクトで検証します。

MVPフェーズでは、アジャイル的に短いサイクルで作り、ユーザーの反応を確認し、必要に応じて改善や方向転換を行います。

例えば、以下のようなケースに向いています。

• 新規サービスの市場性を検証したい
• ユーザーが本当に使うか確認したい
• 機能の優先順位を実データで判断したい
• 最初から大規模投資するリスクを抑えたい

一方で、MVPで作ったものを、そのまま本番システムとして拡張し続けることには注意が必要です。

MVPは、あくまで価値検証を目的としたものです。短期間で検証することを重視するため、設計品質、セキュリティ、拡張性、保守性、運用性が本番システムとして十分でない場合があります。

そのため、MVPでユーザー価値や方向性を確認した後は、その学びをもとに、改めて本開発の要件定義・設計・品質管理を行うべきです。

つまり、この混ぜ方は、MVPフェーズではアジャイル的に仮説検証を行い、本開発フェーズではウォーターフォール型で品質・スコープ・納期・検収条件を管理する進め方です。

「小さく試してから、計画的に作り込む」ことで、新規サービスの不確実性を下げながら、本番システムとして必要な品質も確保しやすくなります。

---

混ぜ方3：初回リリースはウォーターフォール、その後の改善はアジャイルで進める

Webサービスや業務システムでは、初回リリースまではウォーターフォール型で確実に作り、その後の改善をアジャイル的に回す進め方も有効です。

例えば、保険の申し込みサイトを開発する場合を考えてみます。

初回リリース時点では、利用者が申し込みを完了できること、入力内容が正しく保存されること、審査や契約管理などの後続業務と整合すること、セキュリティや個人情報保護の観点で問題がないことなどを、事前にきちんと設計・検証する必要があります。

このような初回リリースでは、要件定義、設計、開発、テスト、リリース判定を段階的に進めるウォーターフォール型の考え方が適しています。

特に、以下のような内容は、初回リリース前にしっかり整理しておくべきです。

• 申し込みフロー
• 入力項目・必須項目
• 画面遷移
• 入力チェック
• データ保存
• 外部システム連携
• メール通知
• 管理画面
• 権限管理
• セキュリティ
• テスト観点
• 検収条件

これらが曖昧なままリリースすると、申し込みが正しく完了しない、後続業務でデータが使えない、個人情報の扱いに問題が出る、障害時の責任範囲が不明確になる、といった重大なリスクにつながります。

一方で、初回リリース時点ですべてを完璧に決め切る必要はありません。

実際にリリースしてみると、ユーザーの行動や問い合わせ、業務部門からのフィードバックを通じて、改善すべき点が見えてきます。

例えば、以下のような改善です。

• 入力フォームの分かりにくさを改善する
• 離脱が多い画面の導線を見直す
• 説明文や注意書きを変更する
• 申込完了率を上げるために画面構成を調整する
• 管理画面の検索条件を追加する
• 通知メールの文面を改善する
• よくある問い合わせをもとにFAQを追加する
• 業務部門の運用に合わせて一覧項目を見直す

このような改善は、初回開発時にすべて正解を出すことが難しい領域です。

そのため、リリース後は、利用状況や現場の声をもとに、優先順位を付けながら短いサイクルで改善していく方が合理的です。

つまり、この混ぜ方は、初回リリースまではウォーターフォールで安定性・整合性・品質を確保し、リリース後はアジャイル的に改善を重ねていく進め方です。

「最初から完璧を目指して過剰に作り込む」のではなく、「初回リリースに必要な品質は確保し、その後の改善余地を残して運用しながら育てる」という考え方が重要です。

---

契約と検収を曖昧にしない

ウォーターフォールとアジャイルを混ぜる際に、最も注意すべきなのが契約と検収です。

開発方式の議論は、現場の進め方だけでなく、契約上の責任範囲にも直結します。

特に発注側は、以下を明確にしておく必要があります。

• どこまでが契約範囲か
• どの成果物を納品対象とするか
• 何をもって検収完了とするか
• 仕様変更はどのように扱うか
• 追加費用が発生する条件は何か
• プロトタイプは納品物なのか、検討用資料なのか
• MVPは本番利用前提なのか、検証用なのか
• リリース後の改善は保守範囲か、追加開発か

ここを曖昧にすると、後から認識齟齬が発生します。

発注側は「少し直すだけ」と考えていても、開発側から見ると設計変更やテストやデータ移行に影響する場合があります。

逆に、開発側が「これは追加対応です」と判断しても、発注側から見ると「当然含まれていると思っていた」ということもあります。

このようなトラブルを防ぐためには、開発方式だけでなく、契約・検収・変更管理をセットで設計する必要があります。

---

現場運用では「意思決定者」と「変更管理」を明確にする

開発方式を決めても、現場運用が曖昧だとプロジェクトはうまく進みません。

特に重要なのは、意思決定者を明確にすることです。

システム開発では、細かい仕様判断が頻繁に発生します。

• この項目は必須か任意か
• このエラー時は処理を止めるのか、警告にするのか
• 一覧画面にはどの項目を表示するのか
• 承認フローは例外を認めるのか
• データの修正権限を誰に与えるのか

これらは、開発会社だけでは決められません。

発注側の業務責任者やシステム責任者が判断する必要があります。

また、仕様変更の扱いも重要です。

変更を完全に禁止する必要はありません。しかし、変更が発生した場合には、以下を確認すべきです。

• なぜ変更が必要なのか
• 影響する機能はどこか
• 追加工数はどの程度か
• 納期に影響するか
• テスト範囲は増えるか
• 契約範囲内か、追加費用か
• 優先度は高いか
• 代替案はあるか

アジャイル的に柔軟に進める場合でも、変更を無制限に受け入れるという意味ではありません。

柔軟性を持たせるほど、変更管理のルールはむしろ重要になります。

---

判断基準：どちらを選ぶべきか

開発方式を選ぶ際は、以下のように考えると整理しやすくなります。

観点	ウォーターフォールが向くケース	アジャイルが向くケース
利用者	明確	変わる
業務フロー	既に存在する／定義できる	これから検証する
要件	既に存在する／定義できる	仮説検証が必要
システム規模	中～大規模	小さく始められる
契約・検収	明確にしたい	継続的な改善を前提とする
品質管理	事前設計が重要	リリース後の改善を重視
目的	業務を確実に支える	ユーザーの反応を見て育てる

発注側の実務では、「どちらが正しいか」ではなく、「どの不確実性を、どの工程で潰すか」が重要です。

業務や連携仕様の不確実性が高いなら、要件定義で整理すべきです。
ユーザー価値の不確実性が高いなら、MVPやアジャイル的な検証が有効です。
画面イメージの不確実性が高いなら、AIプロトタイプを使って早期に確認すべきです。

不確実性の種類を見誤ると、開発方式の選定も誤ります。

---

まとめ：開発方式は、リスク管理で決める

ウォーターフォールとアジャイルは、どちらか一方が常に正しいわけではありません。

発注側にとって重要なのは、開発方式を思想で選ぶのではなく、プロジェクトのリスクに応じて選ぶことです。

利用者や用途が明確で、業務やシステム連携が複雑な場合は、ウォーターフォールを軸に進めるべきです。

一方で、リリースしてユーザーの反応を見ながら方向性を決める必要があるシステムでは、アジャイルやMVP開発が有効です。

ただし、「要件が決められないからアジャイルにする」という考え方は危険です。

要件が曖昧な場合は、まず業務を整理し、必要であればAIを活用してプロトタイプを作り、関係者間で認識を合わせるべきです。

開発方式の選定で重要なのは、次の3点です。

• 固めるべき部分は、最初に固める
• 試すべき部分は、小さく試す
• 変更が起きる部分は、変更管理のルールを決める

ウォーターフォールとアジャイルを正しく混ぜるとは、単に工程名を組み合わせることではありません。

契約、検収、品質管理、意思決定、変更管理まで含めて、プロジェクト全体の進め方を設計することです。

---

開発方式の選定に不安がある場合はご相談ください

システム開発では、最初の進め方を誤ると、後工程で大きな手戻りや追加費用が発生しやすくなります。

特に、以下のようなお悩みがある場合は、開発方式の整理から始めることをおすすめします。

• ウォーターフォールとアジャイルのどちらで進めるべきか分からない
• 要件定義をどこまで行うべきか判断できない
• 動くプロトタイプを見ながら要件を整理したい
• 契約や検収の条件をどう設計すべきか不安がある
• 開発会社に依頼する前に、発注内容を整理したい

筆者である私はスクラムマスターの資格を保有しており、アジャイル開発の考え方や進め方を体系的に理解しています。一方で、大手SIerにおいて、大規模・高品質が求められるシステム開発プロジェクトで、ウォーターフォール型の要件定義、設計、開発、テスト、品質管理にも実務として携わってきました。

そのため、単に「アジャイルがよい」「ウォーターフォールがよい」といった方法論ありきではなく、プロジェクトの目的、規模、複雑性、契約形態、関係者の意思決定体制を踏まえた上で、現実的な進め方をご提案できます。

特に、要件が固まりきっていない段階では、いきなり開発方式を決めるのではなく、まずは業務・目的・制約条件を整理し、「最初に固めるべき部分」と「試しながら決めるべき部分」を切り分けることが重要です。

まずは現在の構想や課題感をもとに、どのような進め方が適しているかを整理するところからご支援可能です。