システム開発の現場では、よくこんな議論が起こります。
「今回はアジャイルで進めるべきか」
「いや、ウォーターフォールでしっかり固めるべきではないか」
たしかに、開発手法の選択は重要です。ウォーターフォールには、最初に要件を定義し、見積もりを行い、契約範囲を明確にしたうえで進める安心感があります。一方、アジャイルには、作りながら学び、実際に使ってみた反応を取り込みながら改善できる柔軟性があります。
ただ、実際のプロジェクトを見ていると、単純に「どちらが優れているか」という話ではありません。
むしろ重要なのは、プロジェクトの不確実性をどう扱うか。そして、発注側と開発側のどちらか一方に無理を押し付けない進め方をどう設計するかです。
ウォーターフォールは、契約範囲が明確なぶん変更に弱い
ウォーターフォール型の開発では、一般的に請負契約になることが多くあります。
最初に要件を固め、見積もりを出し、納品物と金額を決める。そのうえで、開発側は契約した範囲のものを完成させる責任を負います。
もちろん、実際の責任範囲や変更時の扱いは、契約書や個別の合意内容によって変わります。ここでは、システム開発の現場でよく見られる一般的な整理として捉えてください。
この形は、要件が明確な場合には非常に分かりやすいです。
何を作るのか。いくらで作るのか。いつまでに納品するのか。これらが明確になるため、発注側にとっても予算を組みやすく、開発側にとっても責任範囲を定義しやすい。
しかし、問題は「作っている途中で分かること」が必ずあるという点です。
- やっぱりこの機能も必要だった
- この画面はもっとこうしたい
- 実際に触ってみたら、業務に合わなかった
- 逆に、この機能はいらないかもしれない
ウォーターフォール型の請負契約では、途中で差し込まれた仕様は、基本的には追加要件になります。つまり、別途見積もりと、別途費用の整理が必要です。
これは本来、とても健全な考え方です。契約外の作業を追加するなら、追加費用が発生する。これは当然です。
一方で、逆の問題もあります。作りながら「この機能は不要だった」と分かったとしても、契約上はすでに見積もられた範囲に含まれています。そのため、「作らないなら、そのぶんコストを下げてほしい」と言われても、開発側としては簡単には対応できません。
なぜなら、そこにはすでに設計、調整、体制確保、スケジュール確保などのコストが含まれているからです。
ウォーターフォールは、契約範囲が明確であるがゆえに、途中変更に対して硬くなりやすい。これは良し悪しではなく、構造上の特徴です。
「予算内で何とかして」は、現場にしわ寄せを生む
開発現場では、よくこういうことが起こります。
追加要件であることは分かっている。本来なら別途見積もりが必要であることも分かっている。しかし、発注側としては予算を増やせない。結果として、「何とか今の範囲内で対応できませんか」という話になる。
もちろん、プロジェクトを成功させたい気持ちは分かります。発注側にも事情があります。予算もあります。社内説明もあります。
しかし、それを無理に実装側へ押し込むと、最終的には開発チームにしわ寄せがいきます。
- 残業で吸収する
- 品質を削る
- テストを削る
- ドキュメントを削る
- レビューを省く
こうなると、誰も幸せになりません。
発注側は「思った品質ではない」と感じる。開発側は「契約以上のことをやらされた」と感じる。現場は疲弊する。関係性も悪くなる。
プロジェクトは、契約書だけで進むものではありません。関係者同士の信頼で進みます。
だからこそ、追加要件を曖昧に押し込むのではなく、必要なものは必要なものとして扱う。そのうえで、優先順位をつける。やるものと、やらないものを決める。この姿勢が必要です。
アジャイルでも「いつでも追加できる」わけではない
では、アジャイルならこの問題は解決するのでしょうか。
答えは、半分はイエスで、半分はノーです。
アジャイルは、変化に対応しやすい開発手法です。実際に作りながら、ユーザーの反応を見て、次に何を作るべきかを考えられる。その意味では、不確実性の高いプロジェクトに向いています。
しかし、ここで誤解してはいけないことがあります。
アジャイルは、いつでも好きなだけ追加要望を言える仕組みではないということです。
アジャイルでは、要望を受け付けることはできます。しかし、そのすべてを無条件に実装するわけではありません。
重要なのは、優先順位です。
何が最も重要なのか。何が最も価値を生むのか。何を先に作るべきか。何を後回しにするべきか。場合によっては、何を作らないと決めるべきか。
アジャイルでは、この取捨選択が基本になります。
「これも欲しい」「あれも欲しい」「ついでにこれも」という要望をすべて受け入れていたら、結局はウォーターフォールと同じように、場合によってはそれ以上に、実装側へしわ寄せがいきます。
アジャイルとは、無制限に要望を受け入れることではありません。限られた時間とコストの中で、最も価値の高いものから順番に作るための考え方です。
手法が違っても、守るべき原則は同じ
ここで大切なのは、アジャイルかウォーターフォールかに関係なく、プロジェクトには共通して守るべき原則があるということです。
それは、曖昧な要望を、そのまま実装側に押し付けないことです。
不明確な目的、不明確な業務、不明確なデータ、不明確な優先順位を渡されて、「いい感じに作ってください」と言われても、良いものは作れません。仮に作れたとしても、それは開発者の努力や無理によって成り立っているだけです。再現性のあるプロジェクト運営とは言えません。
本当に良いプロジェクトを進めるためには、発注側も開発側も、それぞれが責任を持つ必要があります。
発注側は、目的、業務、判断基準、優先順位を明確にする。
開発側は、実現可能性、技術的リスク、工数、品質を正直に伝える。
双方で、何をやるかだけでなく、何をやらないかも決める。
この原則は、アジャイルでもウォーターフォールでも変わりません。
それでも「作って使ってみないと分からない」
ただし、ここで忘れてはいけない現実があります。
それは、作って使ってみないと分からないことが必ずあるということです。
どれだけ丁寧に要件定義をしても、実際に触ってみると違和感が出ます。どれだけ業務ヒアリングをしても、画面を見た瞬間に新しい要望が出ます。どれだけ資料で説明しても、動くものを見て初めて理解できることがあります。
人は、頭の中だけで完成形を正確に想像することはできません。特に、AI活用や業務改革のようなテーマではなおさらです。
実際に触ってみる。業務に当てはめてみる。自分たちのデータで試してみる。そこで初めて、「本当に必要なもの」と「思っていたけれど不要だったもの」が見えてきます。
だからこそ、すべてを最初に決め切るウォーターフォールだけでは難しい。一方で、何でも柔軟に受け入れるアジャイルでも危ない。
必要なのは、その中間にある現実的な設計です。
要件定義は準委任でアジャイルに。確定部分は請負で小さく区切る
私が現実的だと感じるのは、要件定義や検証フェーズは準委任契約でアジャイル的に進め、確定した範囲だけを再見積もりして請負契約にするというハイブリッド型です。
まず、最初のフェーズでは、いきなり請負で全体を固めすぎない。
この段階では、業務理解、課題整理、要件整理、データ確認、PoC（概念実証）、優先順位付け、実現可能性の検証を行います。
ここは不確実性が高い領域です。作ってみないと分からない。触ってみないと判断できない。関係者の認識も揃っていない。
そのため、この段階を請負契約で固めるのは相性がよくありません。むしろ準委任契約で、一定期間、専門家が伴走しながら整理、検証する形の方が自然です。
そのうえで、要件が見えてきた部分、仕様が確定した部分、実装範囲が明確になった部分について、改めて見積もりを行う。そして、その範囲だけを請負契約にする。
さらに、その請負範囲も大きく一括にしすぎず、小さく区切ります。
- フェーズ1: データ取得、連携部分
- フェーズ2: 管理画面
- フェーズ3: ユーザー向け機能
- フェーズ4: 分析、レポート機能
こうすることで、発注側にとっては予算管理がしやすくなります。開発側にとっても、責任範囲が明確になります。そして、途中で分かったことを次のフェーズに反映しやすくなります。
「全部アジャイル」でも「全部請負」でもない
現実のプロジェクトでは、「全部アジャイルでやりましょう」も、「最初に全部決めて請負でやりましょう」も、どちらも難しいことがあります。
特に、業務改革、AI活用、新規サービス開発のように不確実性が高いテーマでは、最初からすべてを正確に見積もることは困難です。
一方で、発注側からすると、いつまでも準委任で進み続けるのは不安です。予算が読めない。成果物が見えにくい。どこまで費用がかかるのか分からない。
だからこそ、ハイブリッドが必要になります。
不確実な部分は、準委任で一緒に探索する。確定した部分は、請負で責任範囲を明確にする。ただし、請負範囲は大きくしすぎず、フェーズごとに細かく区切る。
この進め方であれば、アジャイルの柔軟性と、ウォーターフォールや請負の明確さを両立しやすくなります。
良いプロジェクトに必要なのは、手法ではなく合意形成である
最終的に大切なのは、開発手法の名前ではありません。
アジャイルか。ウォーターフォールか。準委任か。請負か。もちろん、これらは重要です。
しかし、それ以上に重要なのは、関係者が次のことに合意しているかどうかです。
- 何がまだ分かっていないのか
- どこまでを探索フェーズとするのか
- どの時点で仕様確定とみなすのか
- 追加要件はどう扱うのか
- 不要になった機能はどう扱うのか
- 優先順位は誰がどう決めるのか
- 開発側に無理なしわ寄せをしないために、どう調整するのか
ここが曖昧なままでは、どんな手法を選んでもうまくいきません。
逆に、ここが合意できていれば、アジャイルでもウォーターフォールでも、あるいはそのハイブリッドでも、プロジェクトは健全に進みやすくなります。
まとめ: 作って学ぶ。ただし、無責任に変更しない
これからの開発プロジェクトでは、最初からすべてを決め切ることはますます難しくなっていくと思います。
AI活用も、業務改革も、新規システムも、実際に作って使ってみないと分からないことが多いからです。
だから、作って学ぶ姿勢は必要です。アジャイル的に、試しながら進めることは重要です。
しかし同時に、変更や追加を無制限に実装側へ押し込んではいけません。
追加要件にはコストがかかる。優先順位を決める必要がある。やらないことを決める必要がある。開発側にしわ寄せをしてはいけない。
個人的には、これからの現実的な進め方としては、要件定義、検証フェーズは準委任でアジャイルに進める。仕様が確定した部分は、再見積もりして請負にする。ただし、請負範囲は小さく区切り、学びを次のフェーズに反映できるようにする。
このようなハイブリッド型が、もっとも実務に合っているのではないかと思います。
アジャイルか、ウォーターフォールか。
その二択ではなく、不確実なものは一緒に探索し、確定したものは責任を持って作る。
これが、これからのプロジェクトに必要な考え方なのではないでしょうか。
