MVP の見積が「500 万か 6,000 万か」で迷子になる理由
「まずは小さく作って市場の反応を見たい」——スタートアップの創業者や社内新規事業の担当者から、こうしたご相談を受けることが増えています。いわゆる MVP (Minimum Viable Product) 開発です。ところが、いざ複数社に見積を依頼すると「500 万円」「2,000 万円」「6,000 万円」と桁ひとつ違う数字が並び、「そもそも MVP っていくらが妥当なのか」という前段で止まってしまう方が少なくありません。
MVP の見積が振れやすいのは、「MVP」という言葉自体に共通の定義がないためです。同じ言葉で、A 社は「1 機能・1 画面の検証用プロトタイプ」を想定し、B 社は「本番運用に耐える初期リリース版」を想定していれば、金額は当然変わります。この記事では、発注側のスタートアップ・新規事業担当者向けに、MVP の見積レンジ・スコープの絞り方・削っていい要素と削ってはいけない要素・PMF 後の追加開発の予算計画まで、実務で使える形で整理します。
FIXITMVP って頼んだのに、A 社 500 万で B 社 6,000 万って、何が違うんですか？
Tsukasa結論から言うと、MVP という言葉の指す範囲が会社ごとにまったく違うのが原因です。
FIXITTsukasaA 社は 1 機能・1 画面のプロト、B 社は本番運用に耐える初期版を想定していたりします。
FIXITTsukasa判断の軸は仮説の絞り込みです。今回の MVP で何を学びたいかを 1 つに絞ってください。
1. MVP の定義と「MVP と言いつつフル機能」問題
MVP とはもともと「仮説を検証するために必要な最小限のプロダクト」を指す言葉です。エリック・リース著『リーン・スタートアップ』が広めた概念で、目的は「作ること」ではなく「学ぶこと」にあります。
本来の MVP の姿
- ターゲットユーザーが 1 セグメントに絞られている
- 検証したい仮説が 1 つに決まっている (例: 「この価格でも売れるか」)
- その仮説を検証するために必要な機能だけが載っている
- リリース後、指標を測って学びを得る前提で作られている
よくある「MVP と言いつつフル機能」パターン
一方で、発注現場で頻発するのが次のパターンです。
- 会員登録 / ログイン / マイページ / 管理画面 / 通知 / 課金 / レポート機能まで全部乗せた「初期リリース版」を「MVP」と呼んでいる
- 「ユーザーを 1 万人集めるつもりなので、そのスケールに耐える設計で」と要件に書かれている
- 「将来の BtoB も BtoC も両方対応できる作りにしてほしい」と依頼している
このタイプの案件は、実質的には中規模 SaaS の初期版であり、MVP の金額感 (数百万円) で作れる範囲を大きく超えます。見積を取る前に「これは検証のための MVP なのか、事業の初期プロダクトなのか」を発注側で言語化しておくことが、金額のブレを抑える第一歩です。
2. MVP 開発の見積レンジと規模別の目安
MVP の見積は、検証したい仮説の粒度と、想定するユーザー数で大きく変わります。ここでは実務で目にすることの多い 3 レベルに分けて整理します。数字はあくまで目安で、単価水準や会社構造による差はあります。基本的な工数と単価の考え方については システム開発の見積相場 をあわせてご確認ください。
| MVP のタイプ | 想定内容 | 費用レンジ | 期間 |
|---|---|---|---|
| 検証特化型 MVP | ランディングページ + 申込フォーム、ノーコード活用 | 100〜300 万円 | 1〜2 か月 |
| 初期プロダクト型 MVP | 1〜2 個の主要機能に絞った Web サービス / アプリ | 300〜1,000 万円 | 2〜4 か月 |
| 事業ローンチ型 MVP | 有料課金・複数ロール・運用機能を含む初期版 | 1,000〜2,000 万円 | 4〜6 か月 |
検証特化型 (100〜300 万円)
「そもそもこの課題に対価を払う人がいるか」を確かめるフェーズです。ランディングページと申込フォームだけ、あるいはノーコードツール (Bubble・Adalo・Glide など) でプロトタイプを組む選択肢が有力です。この帯では、フルスクラッチのシステム開発を発注するより、フリーランスや小規模チームの活用が費用対効果で優位に立ちやすい傾向があります。
初期プロダクト型 (300〜1,000 万円)
コア機能を 1〜2 つに絞り、実際にユーザーが継続利用できる Web サービスやアプリを作るフェーズです。日本のスタートアップの MVP 発注でもっとも多いレンジで、Web サービスなら 500 万円前後、iOS / Android 両対応のアプリなら 800 万円前後が現実的な下限になります。
事業ローンチ型 (1,000〜2,000 万円)
BtoB の SaaS や、課金・審査・多段階ワークフローを含むサービスでは、この帯からのスタートになります。ここに近づくと、もはや「MVP」というより「初期リリース版」と呼ぶべき規模で、要件定義から本番運用まで一通り作り込むためです。
3. スコープの絞り方: コア価値 / ノイズ機能 / 将来機能
MVP の見積を適正化する最大のレバーは、機能を絞り込むことです。値引き交渉で下げられる幅は 5〜10% ですが、スコープを絞れば 30〜70% 下がります。ここでは、機能を 3 つに分類するフレームを紹介します。
(1) コア価値: これがないと MVP が成立しない機能
「このプロダクトが解こうとしている課題」を解決する中核機能です。例えば飲食店予約サービスなら「店舗一覧の閲覧」「日時指定の予約送信」「店舗側での予約受信」の 3 点。これを削るとサービス自体が成立しないので、絶対に残します。
(2) ノイズ機能: あると便利だが、なくても検証できる機能
- 洗練されたオンボーディング画面
- プッシュ通知 (メール通知で代替可能)
- 高度な検索・絞り込み
- SNS シェア機能
- 多言語対応
これらは、初期 100〜500 ユーザーの検証フェーズでは省いても意思決定に影響しない機能です。MVP からは思い切って外し、必要性がデータで確認できたときに追加します。
(3) 将来機能: スケールしてから作ればいい機能
- 管理者権限の細分化 (ロール 5 種類など)
- 詳細なレポート・分析ダッシュボード
- 外部システム連携 (会計・CRM・SFA)
- API 公開・Webhook
これらは「将来必要になるかもしれない」で載せると、それだけで数百万円が積み上がります。「今の仮説を検証するのに必要か」と自問し、No なら次フェーズへ回します。
発注前にこの 3 分類で機能を仕分けたうえで見積を依頼すると、見積書の粒度と金額の妥当性が一気に判断しやすくなります。事前準備のチェックリストは 発注前に整理すべきこと にまとめています。
4. MVP で削っていい要素・削ってはいけない要素
「削れるものはすべて削る」のが MVP の原則ですが、削るとあとで致命傷になる要素も存在します。ここは発注前に必ず整理しておきたい観点です。
削っていい要素
- 装飾的なアニメーション・独自のブランド UI
- 管理画面の UI リッチさ (初期はエンジニアが直接 DB 操作でも運用可)
- 詳細なユーザー分析機能 (GA やログ集計ツールで代替)
- 対応ブラウザ・端末の網羅性 (PC Chrome 優先などに絞る)
削ってはいけない要素
認証・アカウント管理
ユーザー ID が後から統合できない設計にすると、リリース後のリカバリが極めて難しくなります。パスワードのハッシュ化、リセットフロー、なりすまし対策の最低ラインは必ず入れます。
課金・決済まわり
有料サービスの場合、決済の入り口を後から差し込むと、既存ユーザーとの契約整合が崩れやすいです。Stripe・PAY.JP などの決済 SaaS を使い、金額計算・領収書発行・失敗時のリトライを最低限組み込んでおきます。
法対応・規約まわり
特定商取引法、資金決済法、個人情報保護法、景品表示法など、業種によっては初期版から必須になる論点があります。「MVP だから利用規約は後で」で公開すると、後から差し替えるコストがユーザー影響込みで膨らみます。
セキュリティの最低ライン
ログインの総当たり対策、SQL インジェクション対策、HTTPS 化、シークレット管理は工数としては軽いのに、抜けているとサービス継続そのものが危うくなります。
運用に必要なログ・監視
エラーログが取れていない MVP は、リリース後に「何が起きているか分からない」状態になり、次の意思決定ができません。Sentry や Datadog の導入は必ず含めておきます。
注意
「MVP だからここは省いていい」の判断でもっとも危険なのが、認証・課金・法対応・セキュリティ最低ライン・監視の 5 項目です。実装工数としては数十万円で済むのに、抜けたまま公開するとユーザー影響込みでリカバリコストが跳ね上がります。「MVP に載せる機能を削る」と「土台の非機能を削る」は別軸の判断です。
5. MVP 後の PMF 検証と追加開発の予算計画
MVP は「作って終わり」ではなく、「作ってから学ぶための道具」です。したがって、予算計画も 1 回の開発費だけでなく、リリース後 3〜6 か月の追加開発コストとセットで組む必要があります。
想定すべき 3 つのフェーズ
MVP を発注するときは、リリース時点で完成する版だけでなく、その後の道筋も見ておきます。1 つ目が MVP 開発期で、1〜4 か月かけて初期版を作ります。2 つ目が検証・改修期で、リリース後の 3〜6 か月でユーザー反応を見ながら機能追加や改修を回します。3 つ目が PMF 後スケール期で、PMF が見えた 6 か月目以降にユーザー増と機能拡張に耐える設計へ再投資するフェーズです。
追加開発の予算目安
検証・改修期の追加開発費は、MVP 本体の 30〜60% を追加で見ておくのが安全です。500 万円で MVP を作ったなら、続く半年で 150〜300 万円の追加投資が発生する想定です。実際の内訳は「バグ修正」「ユーザーから寄せられた機能追加」「UI 改善」「軽微な非機能改善」に分かれます。
継続的に少しずつリリースする形になるため、契約形態はアジャイル的な進め方に寄せると相性が良く、月ごとに使う工数を柔軟に調整できます。詳しくは アジャイル開発の見積 を参照してください。
PMF 前にやってはいけない投資
- リファクタリングを目的とした大規模書き直し
- 大手企業を意識した過剰なセキュリティ認証取得
- 想定ユーザー数の 10 倍を前提としたインフラ設計
これらは PMF が見えてから投資するべき項目です。PMF 前に手を出すと、方向転換のたびに投資が無駄になります。
6. MVP 発注時に見積で確認する項目
MVP は「小さく作って早く学ぶ」ためのものですが、次の一手を打つ土台にもなります。発注時の見積書には、金額だけでなく次の項目を明記してもらうと安心です。
拡張性の前提
- 想定同時アクセスユーザー数と、その前提での構成
- 主要機能を 1 つ追加した場合の概算工数の目安
- データ量が 10 倍になった場合の再設計の要否
コードの引継ぎ性
- ソースコードの成果物範囲 (バックエンド / フロント / インフラ設定)
- README やセットアップ手順の納品有無
- 主要ロジックのコメント・ドキュメント整備方針
- 別の開発会社に引き継ぐ場合の想定工数
権利関係
- ソースコードの著作権帰属 (発注側 / 受注側 / 共有)
- 使用するオープンソースライブラリのライセンス
- デザインデータ (Figma 等) の権利帰属
- 使用する SaaS・API のアカウント名義
権利関係は、次の会社に引き継ぐときや、資金調達時のデューデリジェンスで必ず確認される項目です。MVP の段階で曖昧にしておくと、後から遡って合意し直すコストが発生します。詳しい交渉の進め方は 見積交渉術 で扱っています。
まとめ
MVP の見積は、検証特化型 (100〜300 万円) / 初期プロダクト型 (300〜1,000 万円) / 事業ローンチ型 (1,000〜2,000 万円) の 3 層で捉えると、桁ズレの見積を並べて評価する物差しになります。金額を下げるレバーは値引き交渉ではなくスコープ絞り込みで、「コア価値 / ノイズ機能 / 将来機能」の 3 分類で機能を仕分けるだけで、見積は 30〜70% 下がります。ただし、認証・課金・法対応・セキュリティ最低ライン・ログと監視の 5 項目は、削るとサービス継続そのものが危うくなるため、MVP でも土台として組み込みます。予算計画は 1 回の開発費で完結させず、リリース後 3〜6 か月の検証・改修期に MVP 本体の 30〜60% を追加で確保しておくのが現実的です。
AI 駆動開発のクリエイティブスタジオである FIXIT では、スタートアップや社内新規事業の担当者と一緒に、仮説の言語化から機能の仕分け、見積レンジの提示までを伴走するかたちで相談を受けています。「今の企画で、MVP をいくらでどこまで作れるのか」を相談したい方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。