MVPは「機能を減らした安い完成品」ではありません。新規事業で最も不確かな仮説を、実際の顧客とのやり取りから確かめるための最小限の手段です。ところが、MVPという言葉だけが先に走ると、要望を少し削ったシステムを作り、公開してから「何を検証するものだったのか」が分からなくなります。開発に着手する前に、確かめる問い、対象顧客、観察する行動、結果によって変えることを決める必要があります。
新規事業のMVPとは
MVPはMinimum Viable Productの略で、日本語では「実用最小限の製品」などと訳されます。重要なのは「小さい製品」ではなく、顧客へ価値を届けながら事業仮説を学べることです。画面が少なくても、確認したい仮説と関係のない機能だけならMVPとは呼びにくいでしょう。反対に、裏側を手作業で運用していても、顧客が価値を体験し、利用や購入の行動を観察できるなら、有効なMVPになり得ます。
NEDO「オープンイノベーション白書 第三版」は、MVPを製品デザインや技術的問題を解決するためではなく、事業仮説を検証する位置づけとして整理し、「構築・計測・学習」のフィードバックを回す考え方を紹介しています。MVPの完成ではなく、学習が一巡するところまでが一つの単位です。
MVP・PoC・プロトタイプ・本番製品の違い
これらの言葉は現場によって使い方が異なります。名前だけで合意せず、「誰に使ってもらうか」「何を確かめるか」「どこまで実運用するか」を説明できる状態にします。
| 名称 | 主な目的 | 主な利用者 | 確認すること |
|---|---|---|---|
| PoC | 技術や方式が成立するか確かめる | 社内担当者、限定した協力者 | 精度、性能、連携、技術的制約 |
| プロトタイプ | 体験や仕様を具体化する | 顧客候補、社内関係者 | 操作、理解、利用場面、要件 |
| MVP | 最小限の価値を届け、事業仮説を学ぶ | 初期顧客 | 利用、継続、支払い、業務への適合 |
| パイロット | 限定した現場で運用可能性を確かめる | 特定企業・拠点・地域 | 運用負荷、定着、サポート、導入条件 |
| 本番製品 | 対象市場へ継続的に価値を提供する | 定めた顧客層 | 品質、拡張性、収益性、継続運用 |
たとえば、画像認識の精度を確かめるだけならPoCで足りるかもしれません。しかし、その精度で現場担当者が業務を変え、会社が費用を払うかは別の仮説です。技術検証と事業検証を分け、両方の結果がそろってから本格開発を判断します。
MVPを作る前に確かめたいこと
「MVPを作って反応を見る」という順番が、いつも正しいわけではありません。顧客の課題が曖昧な段階では、インタビューや既存手段による試験提供の方が、早く安く学べます。
課題が実際に起きているか
顧客候補へ、問題が最後に起きた場面、現在の対処、影響、これまで試した方法を聞きます。「あったら便利」という反応より、すでに時間や費用を使って対処している事実を重く見ます。調査方法は新規事業の市場調査で詳しく解説しています。
コードを書かずに確かめられないか
説明用LP、予約受付、紙の見本、既存ツール、手作業の代行で答えられる問いもあります。顧客が提案に反応するかを知りたいだけなら、複雑なアプリは不要です。一方で、処理速度、操作感、繰り返し利用、既存業務との連携を確かめたいなら、動く仕組みが必要になります。
結果によって何を変えるか
良い結果が出たら本格開発へ進む、弱ければ対象顧客や提供方法を見直す、といった分岐を先に置きます。結果にかかわらず開発を続けるのであれば、そのMVPは意思決定のためではなく、単なる初期版になっている可能性があります。
検証したい仮説からMVPの形を選ぶ
人が裏側を担当するコンシェルジュ型
顧客にはサービスとして提供しつつ、自動化予定の処理を担当者が手作業で行います。価値が伝わるか、どんな入力が必要か、どこで例外が起きるかを学べます。利用が増えると運用負荷が高くなるため、検証期間と対象数を限定します。
LP・先行受付型
価値提案をページで説明し、相談、デモ予約、先行案内への登録などの反応を見ます。需要の入口を確認する方法であり、継続利用や技術成立まで証明するものではありません。未提供の機能をすでに使えるように見せず、現在の提供状況を正しく記載します。
操作できるプロトタイプ型
主要画面をつなぎ、利用者に操作してもらいます。どこで迷うか、業務の順番と合うかを確かめやすい方法です。保存や外部連携が動かない場合は、その範囲を利用者へ説明します。
主要価値だけを実装する機能型
顧客が価値を受け取る中心機能を実装し、限定した利用者へ提供します。本番データを扱うなら、MVPであっても認証、権限、バックアップ、個人情報、法令などを軽視できません。「最小限」は、安全性まで削る意味ではありません。
最も不確かな事業仮説を一つ選ぶ
顧客の何を見れば判断できるか定める
問いに答える最小の提供方法を選択する
対象を限定して実際の利用場面へ出す
行動データと会話を一緒に集める
続行・変更・中止と次の仮説を決める
作る機能をどう絞るか
機能一覧を先に作ると、社内の要望が足し算されます。最初に「顧客がこのMVPを使うことで、どの仕事を終えられるか」を一文にします。その仕事を完了するために必要な入力、処理、出力をつなぎ、途中でなくても困らない機能を後へ回します。
中心体験を一つにする
顧客管理、チャット、請求、分析を薄く広く作るより、最も大きな課題を解く一連の体験を成立させます。たとえば「資料をアップロードし、確認結果を受け取り、修正すべき箇所が分かる」ことが価値なら、管理者向けの細かな集計画面は後でも構いません。
Must・Should・Could・今回は作らないに分ける
| 区分 | 判断 | 質問 |
|---|---|---|
| Must | MVPの問いに答えるため必須 | これがないと顧客は中心価値を受け取れないか |
| Should | 重要だが、代替運用が可能 | 一時的に人や既存ツールで補えないか |
| Could | 利便性を上げる追加要素 | 検証結果を変えるほど重要か |
| 今回は作らない | 仮説が確かになってから判断 | 今作ることで学習が早くなるか |
分類は一度決めて終わりではありません。顧客へ見せた結果、Mustだと思っていた機能が不要になったり、例外対応が中心価値だと分かったりします。変更を失敗扱いせず、MVPから得た学びとして優先順位へ戻します。
MVPでも削ってはいけない品質
見た目や自動化範囲は限定できても、顧客へ損害を与える部分は安易に削れません。扱う情報と利用場面から、最低限守る品質を決めます。
- 認証と、利用者ごとの閲覧・操作権限
- 個人情報や機密情報の取得目的、保存、削除
- データのバックアップと復旧方法
- 誤処理が起きた場合の検知と連絡
- 決済を行う場合の金額・解約・返金条件
- 医療、金融、建築など対象業界の法令・資格・責任範囲
- 外部サービス停止時の代替手順
限られた利用者だけに提供する、機密性の低いダミーデータを使う、危険な操作は人が確認するなど、検証範囲自体を狭める方法もあります。安全性を落として速度を出すのではなく、安全に試せる範囲へ切ります。
捨てるMVPか、育てるMVPかを決める
検証用に短期間だけ使い、学びを得た後に作り直すMVPと、そのまま本番製品へ育てるMVPでは、設計の考え方が違います。前者は変更速度を優先できますが、利用対象とデータを限定します。後者は、認証、データ構造、監視、運用などへ早い段階から配慮が必要です。
「とりあえず作り、うまくいったらそのまま拡張する」は、後で品質問題や開発速度の低下を招きます。開発前に、作り直す可能性、残すデータ、移行方法を話し合ってください。技術的負債そのものが悪いのではなく、何を後回しにしたか分からない状態が問題です。
MVPの費用と期間を左右するもの
MVP開発の費用と期間は、画面数だけでは決まりません。外部サービスとの連携、データ移行、権限、AIの精度検証、決済、監査、対応端末、運用体制によって変わります。見積もりでは「MVP一式」ではなく、検証目的と範囲を分けます。
| 要素 | 負荷が増える例 | 初期の切り方 |
|---|---|---|
| 利用者 | 複数企業、複数権限、不特定多数 | 協力企業や一つの役割へ限定する |
| データ | 機密情報、大容量、既存データ移行 | 対象データを絞り、手動登録も検討する |
| 連携 | 基幹システム、決済、複数API | CSVや管理者操作で一時的に代替する |
| 自動化 | 多数の例外、判断ロジック、AI | 人の確認を挟み、例外を記録する |
| 品質 | 常時稼働、高速処理、厳格な監査 | 利用時間や対象を限定する |
MVPで何を測るか
アクセス数だけでは、中心価値が届いたか分かりません。MVPの問いから、観察する行動を決めます。初回利用、中心機能の完了、再利用、社内共有、問い合わせ、有料継続など、事業フェーズに合う行動を選びます。
数値と一緒に、利用者の会話と操作も記録します。完了率が低い場合、価値がないのか、操作で迷ったのか、必要なデータを用意できなかったのかで次の対策が変わります。KPIの組み立て方は新規事業のKPI設計で詳しく説明しています。
- 届いたか対象顧客が利用開始まで進んだか
- 価値を得たか中心となる作業を完了できたか
- 続けたいか再利用、紹介、支払いなど次の行動があったか
誰に試してもらうかで結果が変わる
MVPは、不特定多数へ広く公開すればよいとは限りません。課題が起きる状況と役割を定め、最初の仮説に合う利用者を選びます。既存顧客は協力を得やすい一方、自社との関係が評価へ影響します。可能であれば、既存の関係がない顧客候補や、これまで別の方法を選んだ人も含めます。
利用開始前には、検証中のサービスであること、使える機能、データの扱い、問い合わせ先、不具合時の対応を説明します。業務へ影響する場合は、いきなり全面的に置き換えず、対象データ、担当者、利用期間を限定します。
感想だけでなく、実際の仕事を観察する
利用後に「どうでしたか」と聞くだけでは、具体的な障害が見えません。可能な範囲で、どこから作業を始め、何を入力し、どこで止まり、結果を誰へ渡したかを確認します。操作に迷った箇所と、価値を感じなかった箇所を分けて記録します。
使わなかった人の理由も残す
利用した人だけを見ると、開始前の障害を見落とします。案内を開かなかった、登録しなかった、初回で止まった人にも、時間、信頼、データ準備、社内承認などの理由を確認します。利用率を上げる機能より、導入方法や提案内容を先に変えるべきだと分かる場合があります。
公開後は「機能追加」より先に原因を分ける
利用が進まないと、機能不足だと考えて追加開発を始めがちです。しかし、対象顧客へ届いていない、価値の説明が伝わっていない、導入手続きが重い、運用担当が決まっていない可能性もあります。
週次レビューでは、何を公開したかではなく、次を確認します。
- 今週はどの仮説を検証したか
- どんな行動と発言が得られたか
- 仮説を支持する証拠と反証は何か
- 次に一つだけ変えるなら何か
- 続ける・変える・止める判断に何が足りないか
経済産業省の新製品・新サービス創出に関する調査報告書でも、最初からプロダクトを作り込むことで、ユーザーのフィードバックを得る期間や回数が限られる課題が示されています。機能の完成度ではなく、限られた資源で何回学べるかを意識します。
MVP開発会社を選ぶときの確認事項
- 開発前に顧客と検証目的を確認するか
- コードを書かない検証方法も提案するか
- 仕様変更が起きる前提で進行方法を説明できるか
- マーケティングと利用データを開発へ戻せるか
- 認証、権限、個人情報など削れない品質を説明するか
- ソースコード、デザイン、クラウド環境、分析データの所有者は誰か
- 検証後に作り直す範囲と、引き継ぐ範囲が明確か
- 結果が弱いとき、追加開発ではなく停止や方針変更を提案できるか
開発実績の多さだけでなく、事業仮説が変わったときの動き方を聞きます。新規事業では、最初の仕様どおりに完成することより、学びに合わせて適切に変えられることが重要です。
MVP開発で起きやすい失敗
完成品を小さくしただけになる
多数の機能を薄く入れても、どの価値が選ばれたか分かりません。中心体験を一つに絞り、端から端まで使えるようにします。
社内デモで検証を終える
社内評価は仕様やリスクを確認するには必要ですが、顧客の購入行動とは異なります。提供できる範囲を限定し、実際の対象顧客へ使ってもらいます。
好意的な声だけで次へ進む
「便利そう」という発言に加え、再利用、社内共有、見積もり、支払いなどの行動を見ます。使わなかった人や途中で止まった人の理由も記録します。
運用を後回しにする
問い合わせ対応、データ修正、障害連絡、顧客サポートを誰が行うか決めずに公開すると、利用者が増える前にチームが疲弊します。手作業部分を含め、担当と上限を決めます。
MVPで作るのは製品だけではなく、次の判断材料
MVP開発は、安く早くシステムを納品する方法ではありません。顧客の課題と事業の成立条件について、実際の利用から学ぶ方法です。開発前に問いを決め、その問いへ答える最小の体験を作り、対象顧客へ届け、結果に応じて方向を変えます。
AINAVIでは、顧客・市場の検証、LPと集客、MVP開発、公開後の分析を分けずに設計します。支援範囲はAINAVIの新規事業支援をご覧ください。最初の検証順序から整理したい場合は、新規事業の最初の3ヶ月でやることも参考になります。
