MVP開発とは｜新規事業を小さく始める発注の仕方
MVP開発の進め方と費用の考え方を新規事業の発注者向けに解説。MVPとPoCの違い、検証したい仮説から最小限の機能を決める方法、MVPから本開発へ移るときの判断を紹介します。
新規事業のシステムを、最初から完成形で作る必要はありません。MVP開発は、事業の仮説を確かめるために必要な最小限の製品を作り、小さく始める方法です。この記事では、新規事業の担当者に向けて、MVPとPoCの違い、検証したい仮説から最小限の機能を決める方法、費用と期間の目安、MVPから本開発へ移るときの判断を解説します。
MVP開発とは：PoCとの違い
MVP（Minimum Viable Product）は、実際の顧客に使ってもらい、事業の仮説を確かめるための最小限の製品です。PoC（Proof of Concept、概念実証）は、技術的に実現できるかを確かめる試作です。似た言葉と並べると、違いは次のとおりです。
PoCは「作れるか」、MVPは「売れるか・使われるか」を確かめるものです。技術的な不安が小さい案件なら、PoCを飛ばしてMVPから始めることもあります。
検証したい仮説から最小機能を決める方法
MVPの機能は「作りたい機能」から決めるのではなく、「確かめたい仮説」から逆算します。
1. 仮説を書き出す
まず、事業が成り立つための前提を書き出します。
- 課題の仮説：誰が、どんな場面で、何に困っているか
- 解決策の仮説：その困りごとを、この方法で解決できるか
- 支払いの仮説：解決にいくら払ってもらえるか
2. 一番危ない仮説を選ぶ
外れたら事業そのものが成り立たない仮説を優先します。多くの場合、「顧客は本当にお金を払うか」が最も危ない仮説です。
3. 検証に必要な最小の流れを決める
選んだ仮説を確かめるために、顧客が通る最小の流れを決めます。たとえば「登録→体験→有料化→利用」が成立すれば、支払いの仮説を確かめられます。この流れに必要ない機能は作りません。
4. 合格の基準を先に決める
「登録から1か月で有料化する人がどれだけいれば次に進むか」のように、次の投資に進む基準を数字で決めます。基準がないと、結果を都合よく解釈してしまいます。
5. 作らない機能の一覧を作る
管理画面の作り込み、細かな設定機能、多言語対応などは、MVPでは手作業や既存ツールで代替できることが多くあります。「今回は作らない」と決めた機能も一覧にして、関係者と合意しておきます。
作り方別の費用と期間の目安
MVPの費用と期間は、機能の量と作り方で大きく変わります。以下は、ある受託開発会社が商談や提案書で示している期間の目安です。業界全体の相場ではなく、一つの受託開発会社の例として参考にしてください。
作り方による違いも大きくなります。ノーコードやローコード（プログラムをほとんど書かずに作るツール）は早く安く作れる反面、検索対策や複雑な処理に弱い面があります。AIを使ってコードを生成する開発は、従来型のフルスクラッチより初期費用と期間を抑えやすくなっています。ある受託開発会社が同じ要件で方式を比べた例では、従来型のフルスクラッチはAIを使った開発の2倍以上の初期費用、約2.5〜3倍の期間と試算しました。
費用全体の考え方はシステム開発の費用相場、期間は開発期間の目安で詳しく解説しています。
MVPから本開発へ移るときの判断
MVPを公開したら、事前に決めた基準で結果を評価し、次の3つから選びます。
- 進む：基準を満たした。本開発で機能を広げ、利用者を増やす
- 修正する：一部の仮説が外れた。対象顧客や機能を変えてもう一度検証する
- やめる：最も危ない仮説が外れた。投資を止め、学びを次の事業に生かす
本開発に進むときは、次の点も確認します。
- MVPの仕組みをそのまま拡張できるか、作り直しが必要か
- 利用者が増えたときのサーバー費用や運用体制
- 決済や外部サービスとの連携など、後回しにした重い機能の着手時期
MVPでよくある失敗
- 機能を足し続けて、公開が何か月も遅れる。「最小限」の範囲が守られていない
- 合格の基準を決めずに公開し、結果を見ても次に進むか判断できない
- 社内の知人だけに使ってもらい、実際の顧客の反応を確かめていない
- 無料で提供したため、お金を払ってもらえるかが分からないまま終わる
- MVPのつもりで作った仕組みが、利用者が増えた段階で作り直しになる
どれも、開発を始める前に「何を確かめるか」と「どこまで作るか」を文書で決めておけば防げます。開発会社に相談するときも、機能の一覧より先に、確かめたい仮説と合格の基準を伝えると、提案の質が上がります。
MVPは変更が前提です。契約の形や進め方は、変更を受け入れやすいものを選びます（ウォーターフォールとアジャイル、請負と準委任）。
受託開発の現場から
ある受託開発会社が、新規事業の案件で実際に提案している進め方を紹介します。
- PMF（製品が市場に受け入れられた状態）に向けて、「課題が明確か」「解決策を設計できているか」「製品で実現できるか」の順に仮説を確かめます。MVPを決める手前までの仮説を、発注者と一緒に整理するところから始めます。
- PoC、MVP、拡張の段階ごとに、「何を検証するか」「次に進む基準」「この段階では検証できないこと」「範囲・期間・費用」を1枚の表にまとめています。PoCの環境はMVPに流用する前提で作り、作り直しを避けます。
- MVPの検証項目には、数値の目標を置きます。たとえばAIの認識の成功率を90%、95%、99%のどこに置くかを決めてから進めます。また、無料の既存アプリでは支払い意思を測れないため、有償のオプションを用意して課金意思を確かめる段階を設けた提案もあります。
- 一方で、PoCを実装レベルまで踏み込むと構築とほとんど同じになる案件では、PoCを外しました。代わりに、要件定義と調査（画面のモックとアンケート）にとどめると判断した例もあります。「PoCを必ずやる」ではなく、確かめたいことに合わせて段階を選んでいます。
まとめ
- PoCは「作れるか」、MVPは「使われるか・お金を払ってもらえるか」を確かめる
- MVPの機能は、作りたい機能ではなく、最も危ない仮説から逆算して決める
- 次に進む基準を数字で先に決め、作らない機能も一覧にして合意する
- 費用と期間は作り方で大きく変わる。段階ごとに分けて見積もる
- MVPの結果で「進む・修正する・やめる」を判断する
どの仮説から確かめるべきか整理できていない段階でも、FastProposal の無料AI相談で事業のアイデアを入力すれば、最小限の機能と費用の目安を数分で整理できます。開発会社への相談の前にお試しください。