MVP開発の費用は、なぜ見積もりごとに違うのか

MVP開発の費用を調べると、公開されている金額の幅が大きすぎて、そのまま予算にできません。同じ「MVP開発」という言葉でも、前提が揃っていないためです。

この記事では、金額がばらつく理由と、費用を本当に左右している要素を整理します。結論を先に書くと、費用は単価や工数よりも「何を作ると決めたか」でほぼ決まります。

公開されている費用相場は、なぜここまで幅があるのか

実際に公開されている数字を並べると、次のようになります。

出典	提示されている金額
吉田Web事務所	ノーコードで個人に依頼：10〜50万円／フルスクラッチで開発会社：200〜500万円
Wur株式会社	ノーコード：50〜150万円／スクラッチ：300〜1,000万円

同じ「ノーコード」でも、一方は10万円から、もう一方は50万円からとしています。スクラッチでは上限が500万円と1,000万円で倍の開きがあります。

これはどちらかが間違っているという話ではありません。「MVP」と呼んでいるものの中身が、書き手ごとに違うというだけです。

ログイン機能のない検証用のフォームもMVPと呼べますし、決済と管理画面を備えた実サービスもMVPと呼べます。前者と後者を同じ言葉で括れば、金額が10倍違うのは当然です。

つまり、相場を調べる行為そのものが、あまり意味を持ちません。自社が何を作ろうとしているかを決めない限り、金額は決まらないからです。

MVP開発の費用を決める3つの変数

MVP開発の金額は、次の3つでほぼ決まります。

変数	幅が生まれる理由
作る範囲	検証したい仮説が1つか複数か。機能数が増えるほど、実装だけでなく検証設計とテストも増える
作り方	ノーコード／既存SaaSの組み合わせ／スクラッチ。手法が違えば、同じ画面でも工数が数倍変わる
体制	個人に依頼するか、開発会社に任せるか、自社メンバーと分担するか

このうち**「作る範囲」だけが、発注前に自分で動かせる変数**です。作り方と体制は、範囲が決まって初めて選べます。

ところが実務では、範囲が曖昧なまま見積もりを取り、金額だけを比較する進め方が多く見られます。この順序では、安い見積もりを選んでも結果的に高くつきます。範囲が動けば金額も動くからです。

見積書の内訳を、どこから読むか

MVP開発の見積書は、おおむね次の工程に分かれます。

要件定義 — どの仮説を検証するか、そのために何が必要かを決める
設計 — 画面・データ構造・システム構成を決める
実装 — フロントエンド、バックエンド、インフラを作る
検証 — テストと、リリース後の効果測定の準備
運用 — サーバー、データベース、外部サービスの月額

金額として最も大きいのは実装です。しかし見積もりと実績がずれる原因は、ほぼ要件定義にあります。ここが薄いまま実装に入ると、作りながら仕様が変わり、その分が追加費用として乗ります。

見積書を見るときは、実装の金額より先に、要件定義に十分な期間が取られているかを確認します。ここが数日で終わる前提の見積もりは、後から動く可能性が高いと考えたほうが安全です。

同じ機能でも費用が倍変わる分岐点

画面数や機能数が同じでも、次の要素が入ると工数が大きく変わります。

認証 — メールアドレスとパスワードだけか、SNS連携や二要素認証まで含むか
決済 — 決済代行を使うか、返金・定期課金・請求書発行まで扱うか
管理画面 — 運営側が使う画面を作るか、当面は直接データを触って運用するか
権限管理 — 利用者の役割が1種類か、複数の権限を分けるか
非機能要件 — 同時アクセス数、応答速度、可用性、監査ログの要否

検証段階では、このうちいくつかを「作らない」と決められます。管理画面を作らずに運用でしのぐ、権限は1種類に絞る、といった判断です。

ただし、この判断には条件があります。何を検証したいのかが決まっていないと、どれを落としてよいのか分からないのです。仮説が曖昧なまま機能を削ると、検証そのものが成立しなくなります。

だから多くの現場では、迷った機能を「念のため」残します。そして費用が膨らみます。

「安く作る」より「無駄に作らない」

費用を抑える打ち手として、次のような方法がよく挙げられます。

機能を削る
段階的にリリースする
既存のサービスを組み合わせる
自社の担当範囲を決める

いずれも有効です。しかしどれも「何を検証したいかが決まっている」ことが前提になっています。前提が抜けたまま機能を削れば、ただ中途半端なものができるだけです。

つまり費用を左右しているのは、単価交渉でも工数削減でもなく、発注前に検証設計ができているかどうかです。ここに手を入れられれば、費用は構造的に下がります。手を入れられなければ、どこに頼んでも膨らみます。

依頼先による進め方の違い

同じMVP開発でも、依頼先によって費用の決まり方そのものが変わります。

	一般的な受託開発	フリーランス・ノーコード活用	YOLOのプロダクト開発
前提	要件が固まっている	作るものが決まっている	検証したい仮説がある
見積もりの起点	機能一覧から工数を積む	実装する画面数	何を検証すれば判断できるか
要件が曖昧なとき	要件定義を別途発注する	発注側が決める必要がある	仮説の整理から一緒に行う
仕様が変わったとき	追加費用として計上	都度見積もり	検証結果として織り込む前提で設計する
終わったあと	納品して終了	納品して終了	内製化を前提に、進め方ごと引き渡す

一般的な受託開発は、要件が固まっている案件では合理的です。決まったものを正確に作る体制だからです。ノーコードやフリーランスの活用も、作るものが明確なら費用対効果が高い選択肢になります。

問題は、MVP開発の多くがそのどちらでもないことです。「何を作るか」がまだ決まっていない段階で、要件が固まっている前提の見積もりを取る。この不一致が、追加費用と手戻りの発生源になります。

YOLOが要件定義ではなく検証設計から入るのは、この不一致を最初に解消するためです。仮説が1つに定まれば、必要な機能は自動的に絞られます。削る判断ができるようになるので、結果として費用が下がります。

YOLOが検証設計から入れる理由

進め方を掲げるだけなら誰でもできます。実行できるかどうかは体制で決まります。

YOLOは開発会社ではなく、UXデザインとプロダクトマネジメントに専門性を持つProduct Evolution Studioです。メンバーは事業会社で自社プロダクトの開発とグロースを経験しており、発注側の立場で意思決定をしてきた人間が設計に入ります。

これが実務で効くのは、次の場面です。

仮説を1つに絞る場面 — 事業側の都合と技術的な制約の両方が分かるため、落とす判断ができる
仕様が動いた場面 — 検証結果として想定内に扱えるため、追加費用の交渉にならない
引き渡しの場面 — 内製化を前提に、判断の基準ごと渡せる

実際の支援でも、株式会社LabBase様では内製化を意識して社内のPMの方と伴走し、株式会社フォトシンス様では入退室管理システムの新規Webアプリケーション開発とあわせて、新規事業の検証を推進する初期ユーザーの獲得まで担当しました。ほかの事例はプロダクト開発のページに掲載しています。

つくって納めるだけでは、事業の判断材料は増えません。検証が回る状態にすることが目的です。

見積もりを取るときに確認する項目

複数社から見積もりを取るなら、次を揃えて依頼します。揃っていない見積もりは比較できません。

検証したい仮説を、文章で1つに絞って伝えているか
必須機能と、あると望ましい機能を分けて伝えているか
想定するリリース時期を伝えているか
運用費が見積もりに含まれるか、別かを確認したか
要件定義にどれだけの期間を見ているかを確認したか
リリース後の修正が、どこまで含まれるかを確認したか
仕様が変わった場合の追加費用の扱いを確認したか

このうち最初の1つ、検証したい仮説を1つに絞ることが最も重要です。ここが定まると、必要な機能が自然に絞られ、見積もりの幅も小さくなります。

逆にここが決まらないまま複数社に相談しているなら、見積もりを集める前にやるべきことが残っています。

まとめ

公開されている相場は前提が揃っていないため、そのまま予算にはできない
費用を左右しているのは単価や工数ではなく、発注前に作る範囲を決められているか
範囲を決めるには検証設計が要る。ここに手が入らなければ、どこに頼んでも費用は膨らむ

YOLOでは、プロダクト開発の支援を検証設計の段階から行っています。同じ考え方をAIの領域に向けた進め方はAI PoCの進め方に、依頼先の選び方はPoC開発の会社選びにまとめました。デザインだけを切り出して外注する場合の費用の構造は、UXデザインの外注費用で扱っています。