【この記事のポイント】 要件定義前に発注額を固定すると、発注者とベンダーで利害が対立しプロジェクトが破綻するリスクがあります。発注額の完全固定を避け、要件変動を見越した予算・スケジュール管理を行うことが重要です。
なぜ要件定義前に発注額が固定された案件が生まれるのか？
そこには、発注者とベンダー双方の切実な事情が重なる背景があります。
発注者側: 部署で決められた予算枠の上限を超えられない
ベンダー側: 当期目標の達成や関係構築のため、赤字覚悟で受注してしまう
このように互いの思惑が一致することで「事前の金額固定」が発生しますが、実はこれこそが後の大きなトラブルの引き金となります。
では、なぜこのような「事前の金額固定」がまかり通ってしまうのでしょうか。双方の事情をもう少し詳しく紐解いてみましょう。
たとえば事業者側（発注者）の現実として、割り当てられた外注予算があらかじめ決まっているため、その枠内で対応してくれるベンダーに頼るしかないという切実な事情があります。 一方でベンダー側も、今年度の売上目標をクリアしたい、あるいは今後の関係性構築を優位に進めたいという思惑から、要件定義すら終わっていない段階であるにもかかわらず、営業が「とにもかくにも〇〇円でやります」と赤字覚悟の安請け合いをしてしまうのです。
発注額の事前固定が「成立する業態」と「成立しない業態」の違いとは？
商売として成立するかどうかは、提供するサービスが「高度にパッケージ化されているか」によって大きく分かれます。
フルオーダーメイドに近い受託制作で金額を固定すると何が起きるのか、具体的な例を交えて解説します。
「とにもかくにも〇〇円でやります」といってしまう案件でも商売として成立するのは、高度なパッケージングが行われているサービスです。
どんなクライアントでも、基本的に提供するサービスに変化がない場合はあまり問題にならないでしょう。デジタル系のプロジェクトに関していえば、たとえばツールベンダーが該当します。
しかし、サービスのパッケージングが行われていないサービス、たとえば受託開発や受託制作の現場ではそうはいきません。
クライアントの業種や状態によって、要件や対応コストが大きく異なるサービスにおいては、予算が固定されていることは大きな障害になりえます。
例えていえば、どんなシーンで誰が使うかもわからない服をフルオーダーメイドで作るのに、予算が完全に決まっているようなものです。
会社に来ていくジャケット一枚を作るのであれば数万円で事足りるかもしれませんが、人生一度の晴れ舞台で、シャツも革靴もベルトも腕時計もオーダーメイドで、といったオーダーになればとても数万円ではまかないきれません。
要件定義前の発注額固定はどこでプロジェクト破綻を引き起こすのか？
主に、プロジェクトの核となる「要件定義フェーズ（工程）」です。 物理的な実態が見えにくいデジタル開発では要件が膨張しやすいため、金額を固定したまま進めるとこの工程で大きなギャップが生じて破綻することになります。
要件定義フェーズで生じる主なリスクは、以下の2点です。
見積もりの乖離: 要件未定のまま金額を決めると、後から数千万円単位のギャップが生じるリスクがある
要件の変動性: 制作中に要件が膨らみやすく、最も重要な工程で暗雲が立ち込める
なぜ、このような深刻な落とし穴が生まれてしまうのでしょうか。その背景を詳しく見ていきましょう。
サイトリニューアルやアプリ開発のような大規模な制作・開発では、予算ありきのコンペ形式で競合提案にかけることが多く、プロジェクトが始まる前から予算が決まっているケースがほとんどです。
そのため、ろくに要件定義すら終わっていない提案時点で、ベンダー側は「〇〇円でやります」「普通に見積もれば数千万オーバーですが、値引きで対応します」と伝えがちですが、これこそが落とし穴です。そもそも、要件定義が終わっていない状態での見積もりはあてになりません。多少の誤差は値引きで吸収できると思っていても、最終的に値引き額が数千万円レベルに膨れ上がってしまうこともあり得るからです。
また、デジタル開発は、模型をもとに家を建てるようにはいきません。建築に比べて物理的な実態をイメージしにくいため、要件が後からいくらでも変動・膨張しやすい特徴があります。
こうした背景があるからこそ、要件定義はプロジェクトの成否を左右する最重要工程であり、「発注金額の固定」がその要件定義における大きな障害となってしまうのです。
発注額の固定が要件定義フェーズで大きなトラブルになる理由とは？
金額が固定されることで、発注者とベンダーの間で「真逆のインセンティブ（心理的なベクトル）」が生まれてしまうのが最大の原因です。
発注者側: 「定額なら、要望をできるだけたくさん詰め込みたい」
ベンダー側: 「赤字やプロジェクトの事故を防ぐために、要件を極力削り込みたい」
この両者の利害対立が、具体的にどのような交渉の停滞を招くのか、それぞれのリアルな本音をシミュレーションしてみましょう。
1. 発注者側の心理
このベンダーは多少値引きをしてでも仕事がほしいらしい。それどころか、予算上限が決まっていてもRFP（提案依頼書）の内容をやりきると言っている。ということは、RFPを拡大解釈して要件を増やしていっても追加請求はされないはずだ。それなら、できるだけ要望を盛り込んだほうが得だな。ちょうど別部署からも追加オーダーが来ているし、営業さんには悪いけれど一緒に対応してもらおう。
わかりやすくするために、ダイレクトに損得を考えた本音として描きましたが、実際これに近い心理が働くのはごく自然なことです。
2. ベンダー側の心理
営業が、予算上限が完全に固定された案件を取ってきてしまった。利益は度外視するにしても、クライアントに迷惑をかけるプロジェクトの事故だけは絶対に防がなければならない。しかし、まだ要件は曖昧なところが多い。デジタル系のプロジェクトは要件が変動・膨張するもの。事故を防ぐには、合意する要件を絞りに絞るしかない。予算上限が決まっている以上、後からの膨張を見越して、要件定義フェーズではかなりバッファ（ゆとり）を見込んだ合意や、競合提案時の内容を削るハードな交渉が必要になるぞ……
ベンダー側でプロデューサーやプロジェクトマネージャーを経験した方であれば、深く首肯していただけるのではないでしょうか。
利害の対立がもたらす悲劇
このように、予算が完全に固定され増減の余地がない状況では、発注者側は「要件を増やして曖昧にしておきたい」、ベンダー側は「事故を防ぐために要件を減らして早急に白黒つけたい」という、完全に真逆のベクトルで引っ張り合うことになります。
結果として要件定義はなかなか合意に至らず、プロジェクトの進行は停滞します。もし、プロジェクト全体の請負契約をすでに結んでしまっていた場合、ベンダー側は引くに引けないため、交渉はさらに硬直化して深刻な衝突に発展します。 そして、この膠着状態で最も困るのは、要件定義が揉めて進行が遅れている間に、競合他社にリードを許してしまう発注者側なのです。
発注額固定によるプロジェクトの失敗（悲劇）を防ぐにはどうすればよいか？
この悲劇を防ぐには、お互いがデジタル開発特有の「不確実性」を正しく認識し、対立関係ではなく「同じ目的を持つパートナー」として歩み寄ることが不可欠です。
発注者側: 予算の完全固定をやめ、要件変動に備えたコントロール枠（バッファ）を持つ
ベンダー側: 「何でも安くやります」という安請け合いをやめ、リスクを見据えた現実的な提案・見積もりを出す
具体的に、双方がどのようにアプローチを変えるべきか詳しく見ていきましょう。
1. 発注者側ができること：予算の「完全固定」をやめる
まず発注側は、予算の上限を設けるのは良いとしても、一切の増減を認めない「完全な固定」をやめるべきです。 本来的には、要件や発注内容が増えれば、それに応じて発注金額も増やすのが健全です。もし予算上限の関係で追加費用が出せない場合は、「要件追加を諦める」か「他の不要な機能の発注をとりやめる」といったスコープの柔軟なコントロール（枠のやりくり）を行いましょう。
デジタル開発はその曖昧性・不確実性ゆえに、要件の変動は避けられません。最初から予算もスケジュールもギリギリに設計されているプロジェクトは、途中で必ず破綻します。
2. ベンダー側ができること：現実的な提案をし「安請け合い」をしない
ベンダー側は、まず受注欲しさに「〇〇円で何でもやります」という仕事の取り方をやめるべきです。金額が固定された不確実なプロジェクトは、要件定義で揉める原因になり、最終的にクライアントに不利益をもたらします。
真にクライアントのためを思うのであれば、提示された予算に対して無理のない実現可能なプランを熟考し、デジタル案件の不確実性（要件変動による追加請求の可能性）を事前に丁寧に説明した上で、現実的な見積もりを提示しましょう。そして、予算やスケジュールをコントロールしながらやりきる関係性を築くべきです。
「要件が増えているのに、クオリティも、コストも、納期（デリバリー）も一切変えずにうまくいくプロジェクト」など存在しないのです。
ベンダーを下請けととらえず、同じ目的をもつパートナーと捉え、双方にとって良いプロジェクトになるよう、精度の高い提案を引き出すRFPテンプレートをご用意しました。埋めるだけで高品質の提案依頼書が完成します。ぜひご活用ください。
