MVP開発の費用は、体制(何人が関わるか) × 期間(何週間かけるか)でほぼ決まります。「MVPの相場は○万円」という一般論は、対象範囲・品質条件・規制の前提が違う案件を一つの数字に潰しているため、自社の判断材料にはなりません。
役に立つのは相場ではなく、何にいくらかかるかの分解です。本記事では、見積もりの内訳、費用を左右する要因、予算からの逆算方法を整理します。MVP開発全体の進め方はMVP開発とはを参照してください。
この記事のポイント
- 費用は体制×期間(人月・スプリント単位)で分解して見積もる
- 開発費だけの見積もりは危険。募集・計測・サポート・分析まで含める
- 費用を増やす主要因は、対象範囲・外部連携・品質条件・規制・検証運用の5つ
- PoCコードを流用するか作り直すかで、前提も金額も変わる
- 予算が限られるなら、機能を薄く広げるのではなく検証する仮説を絞る
費用の構造 — 体制 × 期間で分解する
MVP開発の見積もりは、突き詰めると次の式です。
費用 = 体制(人数 × 単価) × 期間 + 開発以外の検証運用費
だから同じ「MVP開発」でも、1〜2人で1週間のノーコード検証と、チームで3ヶ月の実ユーザー検証では、費用は桁で変わります。Wildcardの実績でも、MVPの期間は約1週間〜約3ヶ月まで分布しています(内訳はMVP開発の期間で公開しています)。
見積もりを比較するときは、金額の大小ではなく、まず次を揃えます。
- 何人が、何週間(何スプリント)関わる前提か
- どの範囲(対象・対象外)を作る前提か
- 開発以外の作業(次節)が含まれているか
前提が揃っていない見積もりの比較は、安い方を選ぶ根拠になりません。
見積もりに含めるべき項目 — 開発費だけでは検証まで届かない
MVPは「作って終わり」ではなく、実ユーザーの行動から学んで初めて完了します。次の項目が見積もりに含まれているかを確認します。
| 項目 | 内容 | 抜けたときに起きること |
|---|---|---|
| 設計・実装 | 要件定義支援、UI設計、開発、テスト | (通常は含まれる) |
| 検証対象者の募集 | テストユーザーの確保、案内、利用開始の支援 | 完成したのに使う人がいない |
| データ準備 | 実データの整備、ダミーデータ、権限設定 | 公開直前に数週間の遅延が発生する |
| 計測基盤 | 行動ログ、ダッシュボード、インタビュー設計 | 公開したのに判断材料が取れない |
| 運用・サポート | 問い合わせ対応、障害対応、利用状況の確認 | 初期のつまずきで利用が止まり、誤判定する |
| 結果分析・判断 | データ分析、レポート、継続・変更・撤退の判断支援 | 「作った」だけで意思決定につながらない |
開発費が総額の全てではないこと、そして開発以外の項目こそMVPの成否を分けることが、通常の受託開発との大きな違いです。
費用を増やす5つの要因
期間を左右する要因と同じ軸が、費用も左右します。
| 要因 | 費用が小さい条件 | 費用が大きくなる条件 |
|---|---|---|
| 対象範囲 | 一人の利用者、一つの業務 | 複数部門、多数の権限・例外 |
| 外部連携 | 手入力、単一サービス | 基幹システム、複数API、データ移行 |
| 品質条件 | 招待制、限定データ | 24時間運用、高可用性、大量アクセス |
| 規制・安全 | 一般情報、低リスク | 個人情報、金融・医療、監査要件 |
| 検証運用 | 利用者へ直接連絡できる | 募集・営業・契約調整が必要 |
見積もりが想定より高いときは、値切るのではなく、この表のどの行が金額を押し上げているかを確認します。多くの場合、対象範囲か品質条件を絞ることで、検証の価値を落とさずに費用を下げられます。
PoCコードの流用 — 前提を確認しないと見積もりを誤る
PoCを経てMVPへ進む場合、PoCの検証コードを流用するか、本番用に作り直すかで費用は大きく変わります。
- 流用できる場合 — PoC段階から本番利用を想定した作りにしていた場合。検証から実装への接続が速く、総費用を抑えられる
- 作り直す場合 — スピード最優先の検証コードだった場合。無理に流用すると、修正のたびに障害が増え、かえって高くつく
どちらが正解かは案件次第ですが、見積もり時点でどちらの前提かを明示してもらうことが重要です。「PoC済みだから安くなるはず」という期待と、「作り直し前提」の見積もりがすれ違うと、比較も交渉も成立しません。捨てる部分と育てる部分の分け方はMVPの要件定義で扱っています。
予算から逆算する — 薄く広げず、仮説を絞る
予算が限られる場合の正しい絞り方は、機能を全体的に簡素にすることではなく、検証する仮説を減らすことです。
- 小さな予算 — ノーコード(GPTsや既存ツール)で一つの仮説だけを検証する。Wildcardの実例では、GPTsを使った小規模MVPを約1週間で初期リリースしています
- 中規模の予算 — 一つの業務・一種類のユーザーに絞ったWeb・業務ツール型MVP。実ユーザーが業務で使える品質まで作る
- 実ユーザー検証まで含む予算 — 公開・募集・計測・インタビュー・改善までを一体で計画する。開発費と検証運用費を分けて確保する
AIの活用で「作る費用」の構造自体が変わり、小さな予算でも本物を作れる領域が広がっています。この変化はAIでMVP開発の何が変わったかで詳しく解説しています。
よくある失敗
相場の数字で社内予算を先に固定する
前提の違う相場記事の金額で予算を決めると、対象範囲の議論が「予算に収まるか」の議論にすり替わります。先に仮説と対象範囲を絞り、その検証に必要な体制×期間から積み上げます。
開発費だけで発注し、検証費を残さない
予算のすべてを開発に使うと、公開後の募集・計測・分析ができず、「作ったが何も学べない」状態になります。検証運用の予算を最初から分けて確保します。
機能を減らす代わりに品質を落とす
費用を抑えるために全体の完成度を下げると、「価値がないから使われない」のか「使いにくいから使われない」のか判別できなくなります。削るのは幅(対象範囲)であって、対象範囲内の完成度ではありません。判断基準はMVPの機能はどこまで絞るべきかで解説しています。
よくある質問
MVP開発の費用相場はいくらですか
一律の相場はありません。体制×期間で決まるため、1〜2人×1週間のノーコード検証と、チーム×3ヶ月の実ユーザー検証では桁が変わります。相場を探すより、自社の仮説の検証に必要な体制と期間を見積もる方が早く正確です。
見積もりを安くする一番効果的な方法は何ですか
検証する仮説を一つに絞ることです。仮説が絞られると、機能・データ・連携・品質条件が連動して小さくなり、体制×期間が縮みます。逆に、仮説が曖昧なまま金額だけ下げると、検証に必要な要素が削られます。
複数社の見積もりはどう比較すればよいですか
金額ではなく前提を比較します。体制と期間、対象・対象外、開発以外の検証運用の含否、PoCコードの扱い。前提が揃わない場合は、同じ要件定義書(仮説・判断基準・対象範囲)を渡して再見積もりを依頼します。
