MVP・新規事業
スタートアップのMVP開発費用はどう考える？予算に合わせた機能の決め方
「MVPなら安く作れるはず」と考えて見積もりを取ったら、想像より高かった。あるいは、予算はあるけれど、どこまで使ってよいのか判断がつかない。MVPの費用に正解の金額はありませんが、考え方の順番を間違えなければ、限られた資金を検証に効果的に使えます。創業者の目線で、MVPの予算の組み方を整理します。
MVPの予算は「資金計画」から逆算する
MVPの費用を考えるとき、機能の一覧から積み上げると、予算が膨らみがちです。順番を逆にして、次のように考えるのがおすすめです。
- 検証に使える総額を決める：全体の資金計画の中で、MVPの開発と検証にいくらまで使えるか
- 開発以外の費用を差し引く：利用者を集める費用、運営の人件費、検証期間中の運用費など
- 改修の予備費を確保する：検証の結果を受けて手直しする費用を残しておく
- 残りで作れる範囲を決める：その金額で、検証したいことを確かめられる最小の構成を考える
特に見落とされやすいのが3つ目です。MVPは公開して終わりではなく、検証の結果を受けて変えていくものです。最初の開発で予算を使い切ってしまうと、次の一手が打てなくなります。
MVPの費用を左右する要素
| 要素 | 費用が増えやすい例 | 抑えやすい例 |
|---|---|---|
| 利用者の種類 | 利用者・提供者・運営など、複数の立場の画面が必要 | まずは片側の利用者だけに絞る |
| 決済 | サービス内でのオンライン決済、返金、定期課金 | 当面は請求書払いや外部の決済リンクで代用 |
| 外部連携 | カレンダー、SNSログイン、外部APIとの連携 | メールアドレスでのログインと手動の運用から始める |
| 管理画面 | 運営向けの集計・分析・各種設定の画面 | 最低限の一覧と編集に絞る |
| 品質の水準 | 細部まで作り込んだデザインと操作性 | 分かりやすさを優先し、作り込みは検証後に |
この中で、検証したいことに直接関係する要素には予算をかけ、関係しない要素は「抑えやすい例」の方向で考えると、費用を配分しやすくなります。
予算に合わせて機能を絞る3つの方法
1. 運営側の手作業で代用する
マッチング、日程調整、請求など、本来はシステムで自動化したい処理も、利用者が少ないうちは運営側の手作業で回せることがあります。手作業で回している間に、どの処理を自動化すべきかも見えてきます。
2. 既存のサービスを組み合わせる
ビデオ会議、フォーム、メール配信、決済リンクなど、既存のサービスで代用できる部分は無理に作らない方法です。ただし、組み合わせが増えすぎると利用者の体験が分かりにくくなるため、検証したい体験の中心は自分たちで作るのが基本です。
3. 片側から作る
利用者と提供者の両方が必要なサービスでも、最初はどちらか一方の画面だけを作り、もう一方は運営が代行する方法もあります。具体例はマッチングサービスのMVPを作るには？で紹介しています。
機能の絞り込み方の全体像は、MVPとは？最初から大きなシステムを作らない理由と機能の絞り込み方もあわせてご覧ください。
開発費以外にかかる費用
MVPの予算を組むときは、開発費以外の費用も忘れずに見込んでおきましょう。
- サーバー、データベース、ドメインなどの運用費
- メール送信、決済、地図など、外部サービスの利用料
- 利用規約やプライバシーポリシーの整備にかかる費用
- 最初の利用者を集めるための費用
- 検証後の改修・機能追加の費用
「安く作る」と「作り直しになる」のバランス
MVPは検証のためのものなので、最初から完璧を目指す必要はありません。ただし、検証がうまくいった場合にそのまま育てていくのか、作り直す前提なのかで、費用のかけ方は変わります。
| 方針 | 費用のかけ方 | 注意点 |
|---|---|---|
| 作り直す前提 | 検証に必要な最小限に絞り、短期間で作る | 検証後の作り直し費用を別に見込む |
| 育てていく前提 | データの持ち方など、土台の部分は丁寧に作る | 初期費用はやや大きくなるが、その後の拡張がしやすい |
どちらの方針かを最初に開発会社と共有しておくと、見積もりと設計の考え方がそろいます。検証後の判断についてはMVPを作ったあとはどうする？で解説しています。
見積もりを依頼するときに伝えたいこと
MVPの見積もりを依頼するときは、機能の一覧だけでなく、次の情報もあわせて伝えると、予算に合った提案を受けやすくなります。
- 検証したい仮説と、最初の利用者のイメージ
- MVPの開発に使える予算の上限
- 検証を始めたい時期
- 作り直す前提か、育てていく前提か
- 運営側で手作業を担える範囲（人数、時間）
最後の点は意外と重要です。運営側が手作業を多く担えるなら、作る範囲を小さくできます。逆に、運営の人手が少ない場合は、自動化すべき部分が増えます。
資金調達との関係
スタートアップでは、MVPの開発と資金調達の時期が重なることがあります。次の点を意識しておくと、限られた資金を有効に使いやすくなります。
- 検証の結果を説明できる状態にする：利用者の数や反応など、MVPで得られた事実を記録しておく
- 次の開発の見通しを持つ：検証後に何を作るか、その費用の目安を把握しておく
- 成果物の扱いを確認しておく：ソースコードやアカウントを自社で持てる状態にしておく
ソースコードやアカウントの扱いは、事業の資産に関わる点です。詳しくは外注したシステムを自社で持ち続けるためにで解説しています。
予算を使い切らないために
MVPの開発費は、見積もりどおりに収まったとしても、公開後に想定外の対応が必要になることがあります。利用者からの要望、小さな不具合、運営の手作業を減らすための改善などです。検証期間中に対応できる余力を残しておくと、利用者の反応に素早く応えられ、検証の質も上がります。
開発の進め方全体と、依頼先の選び方についてはMVP開発を外注するときの進め方をご覧ください。
予算を伝えていただくと、提案が具体的になります
MVPの見積もりは、機能の一覧より先に「使える予算」と「検証したいこと」を共有いただくほうが、現実的な構成を提案しやすくなります。Tailboneでは、その範囲で作れる最初の版と、後回しにする機能、検証後の改修の考え方まで含めて一緒に整理します。費用は要件によって変わるため、内容を伺ったうえで個別にお見積もりします。
よくあるご質問
MVPの相場はいくらくらいですか？
MVPといっても、画面が数枚の検証用のサービスから、決済や複数の利用者種別を備えたものまで幅が広く、一律の相場を示すのは難しいのが実情です。正確な費用は、検証したい内容と必要な機能によって決まるため、個別の見積もりになります。
予算が少なくても、MVPを作ることはできますか？
範囲を絞れば可能な場合があります。検証に本当に必要な機能だけに絞り、運営側の手作業や既存のサービスで代用できる部分を増やすことで、作る量を減らせます。予算を共有したうえで、その範囲で何を検証できるかを一緒に考えるのが現実的です。
ノーコードで作ったほうが安くなりますか？
検証したい内容がノーコードツールで表現できるなら、初期費用を抑えられることがあります。一方、独自の処理や連携が検証の中心にある場合や、検証後もそのまま育てていきたい場合は、最初から開発会社に依頼したほうが、作り直しの費用を含めて合理的なこともあります。