見積もりが高いとき、選択肢は2つだけではない

開発会社から見積もりが届いて、想定していた予算を超えていた。自己資金300万円のうち開発に充てられるのは200万円のつもりだったのに、270万円と提示された。こういう場面で、多くの人は無意識に「機能を削るか、予算を増やすか」の2択で考えてしまいます。

しかし実際には、その前に確認すべきことがあります。相見積もりを取ったのか、内訳のどこが高いのかを分解したのか、そもそもその見積もりの前提となる仕様が正確に伝わっていたのか。2択に飛びつく前に、この記事では「削るべきケース」と「増やすべきケース」をそれぞれ整理します。

まず確認すること。差額はどこから来ているか

機能を削るか予算を増やすかを決める前に、見積書の内訳を見て「なぜ高いのか」を特定してください。理由によって取るべき対応が変わります。

  • 機能数が多い → 削る余地がある
  • 1機能あたりの単価が想定より高い → 相見積もりで比較する余地がある
  • 決済・地図・メール送信などの外部連携が積み重なっている → その連携が本当に初期リリースに必要かを見直す余地がある
  • バッファ（予備工数）が大きい → 交渉で調整できる余地がある

同じ要望を伝えても開発会社によって見積もりが大きく違うことがあります。1社だけの見積もりで「高い」と判断する前に、条件をそろえた相見積もりを取ることをおすすめします。

機能を削るべきケース

以下に当てはまる場合は、予算を増やすより先に機能を削る方向で検討してください。

1. 削っても検証したい仮説が壊れない場合

MVPの目的は「本当に欲しい人がいるか」を確かめることです。差額の原因になっている機能が、その検証に直接関わらない付随機能であれば、迷わず削るべきです。

2. 「あったら便利」レベルの機能が含まれている場合

見積もりが膨らむ典型的な原因は、必須ではない機能が最初から盛り込まれていることです。「削れない機能」と「後回しにできる機能」を仕分ける考え方に沿って棚卸しすると、実は削れる部分が見つかることが多いです。

3. 資金の余力が少ない場合

自己資金300万円のうち、開発だけでなく公開後の運用費や集客費も確保する必要があります。開発に予算を寄せすぎると、公開後にすぐ資金が尽きるリスクがあります。予算をどう配分すべきかを踏まえたうえで、開発側の上限を守る判断は合理的です。

予算を増やすべきケース

逆に、以下に当てはまる場合は機能を削らず予算を増やす方向を検討してください。

1. 削ると検証したい仮説そのものが壊れる場合

例えば「専門家に個別相談できる」ことが提供価値の核であるサービスで、その機能を削ってしまうと、何を検証しているのか分からなくなります。核となる機能を削って予算を合わせるのは、本末転倒です。

2. 差額が「後から必ず発生する費用」の先送りにすぎない場合

見積書に載っていない、後から発生しやすい費用の項目があります。今削っても、公開後すぐに同じ機能が必要になり、結局追加費用がかかるだけというケースでは、削るのではなく最初から予算に組み込むほうが合理的です。

3. 資金と時間、両方に余力がある場合

自己資金に余裕があり、かつ検証を急ぐ理由が薄い場合は、無理に機能を削って中途半端な検証をするより、必要な機能を揃えて公開したほうが、結果的に「本当に欲しい人がいるか」を正確に判断できます。

判断に迷ったときの目安

状況優先すべき対応
検証したい仮説に関係ない機能で差額が出ている削る
検証の核となる機能で差額が出ている増やす（または相見積もりを取り直す）
差額の理由が説明できないまず内訳を分解してもらう
運用費・集客費まで開発費に食われそうになっている削る

見積もりが想定より高かったときに機能を削るか予算を増やすかを判断するツリー。差額の原因ごとに対応を分岐させる。

削るか増やすかを決める前に、そもそもその機能が「削れない機能」なのか「後回しにできる機能」なのかを仕分ける視点を持つと、判断がぶれにくくなります。また、機能を削る場合は開発会社との交渉の進め方によって、印象を悪くせずに調整できる場合もあります。

詳細はコラムへ

この記事では判断の分かれ目を示しましたが、実際に見積もりの内訳をどう読むか、相見積もりの取り方、機能の仕分け方といった具体的な手順は、それぞれ専門のコラムで詳しく扱っています。

自分のケースがどちらに近いか分からない場合は、無理に一人で決めず、開発会社に「この機能を削った場合、検証したいことは変わらず確かめられますか」と率直に聞いてみることも、有効な判断材料になります。