MVP開発の費用相場。検証する仮説から予算を決めます

見積書が三社から届きました。総額は大きく違いますが、各社が想定する利用者、公開範囲、運用方法も違います。安い会社を選ぶ会議を始めても、同じMVPを比べているとは限りません。

「MVP開発 費用」で調べる経営者へ、僕なら一つの相場表を渡しません。MVPにかける上限は、検証したい仮説が外れても、次の打ち手を試せる金額にします。最初から便利な製品を完成させる予算にはしません。

MVPは、実際の利用者へ価値を届け、続けるか止めるかを判断するための最小版です。社内デモだけの試作品とは、公開時の安全対策や問い合わせ対応に必要な費用が違います。

MVP開発の費用相場は、工数と範囲をそろえて比べます

MVP開発には、案件を問わず使える一つの金額がありません。同じ一画面でも、固定したサンプルを表示する画面と、顧客データを保存して担当者へ通知する画面では、設計、実装、確認の作業量が変わります。

費用は、担当者の工数と単価へ戻して読みます。2026年7月11日に確認したデジタル庁の標準ガイドライン実践ガイドブックは、人件費を工数と単価の掛け算で積算し、20人日を1人月とする方法を示しています。資料内の例では、4人が15日間働く60人日を3人月とし、1人月120万円なら合計360万円と計算しています。

対象は政府情報システムの担当者で、測定単位は人日と人月です。民間のMVP案件を集めた価格調査ではなく、120万円も日本市場の平均単価ではありません。公式資料は相場の根拠ではなく、総額を作業量へ戻す計算方法として使えます。

見積書では、利用者調査、画面設計、実装、テスト、公開準備、初回検証の運用、結果の整理を分けてもらいます。外部サービスの料金、顧客対応に使う社内時間、検証後の修正、終了時のデータ削除も対象内か確認します。

画面を触ってもらう前段階なら、プロトタイプ開発を外注するときの捨て方を先に選べます。実利用者のデータを保存し、継続して提供する段階へ進むときに、MVP開発の予算へ切り替えます。

MVP開発の費用は、仮説と判定日から逆算します

機能一覧の前に、「誰の行動が変われば投資を続けるか」を一文にします。たとえば、電話で受けている予約について、既存顧客が担当者の説明を受けずに申し込みを完了できるかを確かめる、と決めます。予約機能を作るという表現だけでは、確認する行動が見えません。

次に、試す顧客の範囲、案内する方法、記録する数字、判定日を決めます。申し込み開始人数と完了人数、途中で止まった画面、担当者への質問内容を記録すれば、追加開発の場所を選べます。合格人数は一般的な数字から借りず、現在の受付件数と担当者が対応できる件数から経営者が置きます。

英国政府のアジャイルなサービス開発に関する基準は、政府サービスのチームへ、早い段階で実利用者に使ってもらい、利用データから改善する進め方を示しています。費用比較の調査ではなく、開発費や成功率の測定値は載せていません。MVPの予算を利用者から学ぶ段階へ集中させる運用指針として読めます。

予算上限には、判定日までの開発費だけでなく、公開準備、問い合わせ対応、利用記録の確認、修正を一度行う余白、停止時の処理を含めます。仮説が外れた際に全予算を使い切る金額では、学んだ内容を次の案へ移せません。検証後に残す資金を先に分け、残額の範囲でMVPを設計します。

MVP開発で削ってよい部分は、判定を変えない装飾と自動化です

削ってよい部分は、利用者の行動と判定結果を変えない範囲です。ブランド専用の細かなアニメーション、多数の表示テーマ、利用が未確認の検索条件は、検証後へ回せます。運営担当者が少ない間は、管理画面の一括処理を手作業で補える場合もあります。

手作業を使うなら、利用者へ約束する処理時間を守れる件数に限定します。誰がどの表を開き、何分以内に処理し、作業漏れを誰が確認するかを運用手順へ書きます。人が補っている処理を自動化済みの機能として評価してはいけません。

既存の予約サービス、フォーム、オンライン表計算で代替できる業務も残します。MVPから請求書発行を外し、既存の会計サービスで処理しても、予約需要の判定に影響しない場合があります。外部サービスへ移す作業と利用料は無料ではないため、開発費とは別の欄へ置きます。

一方で、仮説に直結する場面は削れません。通知を受け取った後の再訪が利用継続を左右するなら、通知を外した版では継続利用を判定できません。削る基準は実装の難しさではなく、判定に必要な利用場面かどうかです。

作らない範囲を会議で決める方法は、経営者向けの要件定義の進め方でも説明しています。MVPでは対象外にした理由と、追加を再検討する数字まで同じ記録へ残します。

MVP開発で費用を削れない部分は、顧客データと停止手順です

小さく公開するMVPでも、顧客データを預かる責任は小さくなりません。利用者ごとのアクセス範囲、管理者アカウント、秘密情報の保管、操作記録、問い合わせ窓口は、扱う情報と業務上の危険に合わせて設計します。「利用者が少ない」という理由だけで管理者キーを共有してはいけません。

保存するデータは、検証に必要な項目へ絞ります。不要な個人情報を集めなければ、入力画面だけでなく、閲覧権限、訂正、削除、引き継ぎの作業も減らせます。個人情報や決済を扱う場合は、表示する規約や社内手順を担当者と確認し、公開前に必要に応じて法律の専門家へ相談します。

障害時に手作業へ戻せる業務なら、戻し方を公開前に試します。予約データを復元できないなら、バックアップと復元確認が必要です。通知が止まった際は、異常を知る人、顧客へ連絡する人、受付を止める人を決めます。

検証終了時の停止手順も見積もりへ入れます。利用者への案内、データの返却や削除、外部サービスの解約、アカウントの無効化、ソースコードと設定資料の保管を誰が行うかを決めます。続けない判断にも作業と費用がかかります。

公開後の費用も初期見積もりへ足します。MVPでも、公開日を支払いの終点にせず、判定日までに発生する固定費と利用量で変わる費用を分けます。

MVP開発の見積もりは、同じ判定条件で依頼します

候補会社へは、機能一覧だけでなく、仮説、対象利用者、案内方法、判定日、記録する数字、予算上限を同じ一枚で渡します。見積書には、作る画面、外部接続、発注側が用意するデータ、修正回数、公開作業、運用支援、対象外を対応させます。

「一式」の総額だけでは、削る作業を選べません。機能単位と作業単位の工数、担当者の単価、前提が変わった際の計算方法を出してもらいます。安い見積書でテストや公開後の監視が対象外なら、同じ完成条件にはなっていません。

未確認の業務が多い段階では、調査と実装を分けます。現場担当者への聞き取り、実データの項目確認、画面試作までを先に頼み、判明した条件からMVP本体を見積もります。分からない作業を固定額の中へ隠すより、調査で答える問いと成果物を決めたほうが予算を管理できます。

発注側にも作業があります。利用者を集める人、サンプルデータを用意する人、質問へ回答する期限、追加費用を承認する人が決まらなければ、開発会社の担当者が空きを待つ時間も費用になります。見積もりの比較では、社内の担当時間も同じ表へ置きます。

明日の予算会議では、四つの資料を開きます

最初に、直近の問い合わせ記録、申込表、利用中のサービス画面を開いてください。利用者が困っている場面を一つ選び、現在の件数、完了までの手作業、途中で止まる場所を書きます。推測だけで新しい機能一覧を作り始めません。

次に、仮説票へ対象者、変えたい行動、記録する分子と分母、判定日を書きます。範囲票には、MVPへ入れる利用場面、既存サービスへ残す業務、手作業で補う処理、公開前に確認する安全対策を置きます。

最後に、見積比較表へ、調査から判定日までの工数と単価、外部サービス料、社内担当者の時間、停止時の費用を並べます。検証後に残す資金を除いた金額を予算上限にし、追加依頼を承認する人も書きます。

実利用者、判定する数字、終了日が空欄なら、MVP本体の発注を止めます。三項目が埋まり、安全に公開して停止できる作業まで見積書に入ったら、最小範囲で着手できます。次の会議で決める金額は、欲しい機能を全部作る予算ではなく、一つの仮説に答えて次の投資を選ぶための上限です。