← 記事一覧 正しいものを作る

MVP（最小実用製品）：少なく作り、速く学ぶ

FabricLoopチーム  ·  2026年5月  ·  9分で読めます

「MVP」という言葉は、あまりにも頻繁かつ曖昧に使われてきたため、その意味がほぼ失われています。創業者たちはこの言葉を、洗練されたv1ローンチ、荒削りなプロトタイプ、ランディングページ、そしてその間にある何もかもを表すために使います。壊れたものを出荷する言い訳として使う人もいれば、永遠に作り続ける理由として使う人もいます（「まだバイアブルじゃない」と）。

本来の定義——エリック・リースの『リーン・スタートアップ』に基づく——は明確です。MVPとは、最小限の努力で顧客について最大量の検証済み学習を得られる製品のバージョンです。それは学習ツールであり、製品ローンチではありません。

最も重要な言葉：バイアブル（実用的）

「ミニマム」は難しくありません。創業者は本能的に機能を削ろうとします。難しいのは「バイアブル」です。バイアブルな製品とは、誰かが実際に使用して正直なフィードバックを提供するのに十分な価値を提供するもの——理想的には、お金を払うほどのものです。

誰も使わないMVPは何も教えてくれません。メールアドレス入力フォームがあるランディングページは、コンセプトへの関心を示しているだけで、あなたの解決策が実際に問題を解決するかどうかではありません。最初の1分でクラッシュする壊れたプロトタイプは、バイアブルなしのミニマムです。

よくある間違い 自分がイメージしたものの最小バージョンを作ること。特定のユーザーにコアバリューを届ける最小バージョンではなく。この2つは同じではありません。前者は恣意的で、後者は規律あるものです。

MVPは仮説テストである

MVPについて考える最善の方法は、明確に述べられた仮説を持つ実験として考えることです。何かを作る前に、次のことを書き留めてください：

あらゆるMVPの仮説構造
前提
「[顧客セグメント]は[理由]により[アウトカム]を望んでいると考える。」
テスト
「[最小限のもの]を作り、[期間]内に[特定の行動]をするかどうかテストする。」
シグナル
「[測定可能なアウトカム]であれば真、[その反対]であれば偽とする。」

「偽」の条件を明確に述べられないなら、仮説をテストしているのではなく、製品を作っているだけです。MVPが機能するのは、「ノー」がどのように見えるかを事前にコミットした場合のみです。

「反証可能な仮説のないMVPは、ただの低品質な製品です。それは同じことではありません。」

MVPスペクトラム：フェイクから機能的まで

MVPは完全に手動から完全に自動まで、スペクトラム上に存在します。スペクトラムのどこに位置すべきかは、何を学ぼうとしているか、テストにどれだけ投資するかによって異なります。

MVPフィデリティ・スペクトラム
コンシェルジュ型 価値を手動で提供する。ソフトウェアなし。自動化する前にアウトカムが重要かどうかを学ぶ。
オズの魔法使い型 ユーザーには動作中のインターフェースを見せ、裏側で手動で処理する。インフラなしで需要をテストする。
プロトタイプ型 クリッカブルなモックアップまたは基本的な機能バージョン。完全な信頼性ではなく、使いやすさとフローをテストする。
機能的MVP型 コア機能のみを持つデプロイ可能な製品。実際の使用、リテンション、支払い意欲をテストする。

多くの創業者は「機能的MVP」に直接飛びつきます。最も正当に感じられるからです。しかし、コンシェルジュ型MVP——10人の顧客にサービスを手動で提供すること——は、6ヶ月の開発よりも2週間で多くのことを教えてくれることがよくあります。目標は学習であり、製品ではありません。

MVPに含めるものと含めないもの

スコープの決定は、ほとんどのMVPが失敗するところです。何を含めるかのフレームワークを示します：

MVPに含める
  • コアバリューを提供する単一のアクション
  • そのアクションを発見可能にする十分なUX
  • 支払いまたはコミットメントを受け取る方法
  • 最小限の信頼シグナル（プライバシー、基本的なセキュリティ）
  • フィードバックを提供する経路
MVPから削除する
  • 稀なシナリオのエッジケースとエラーハンドリング
  • 設定、プリファレンス、カスタマイズ
  • 高度なレポートやアナリティクスダッシュボード
  • インテグレーション（バリュープロップのコアでない限り）
  • スケール用オンボーディング——最初のユーザーには直接電話する

テスト：追加を検討しているすべての機能について、「これはどのような学習を可能にするか？」と問いかけてください。答えが「なし——ただ良くなるだけ」なら、削除してください。コアが機能していることを検証した後で、あとから作りましょう。

MVPとベータ版の違い

これらは同じものではなく、混同すると問題が生じます。MVPは仮説を検証するための実験です。ベータ版は、一般公開前のテスト用にリリースする、意図した製品の初期バージョンです。

MVPは実験後に完全に捨てられることがあります。ベータ版は通常、出荷するものの基盤です。MVPは努力あたりの学習を最大化するよう設計されています。ベータ版はほぼ完成した製品のバグを見つけるよう設計されています。

1行もコードを書く前にMVPを持つことができます。ほぼ完成した製品なしにベータ版を持つことはできません。

MVPが機能したかどうかを知る方法

仮説に戻ってください。MVPが「機能した」のは、人々が良いことを言ったからではなく、予測した特定の行動をしたからです。称賛は検証ではありません。コミットメント——時間、お金、繰り返しの使用——が検証です。

MVPが仮説を検証した3つのシグナル：

機能しなかった3つのシグナル：

「これにお金を払いますか？」テスト フィードバックが本物かどうか不明な場合、直接聞いてください：「これに月額X円払いますか？」そして話すのをやめてください。その後の沈黙が、初期段階のプロダクト検証における最も示唆に富むデータポイントです。
FabricLoopがMVPプロセスをサポートする方法 MVPフェーズでは、ユーザーインタビュー、セッションメモ、アンケート回答、チームの議論など、大量のフィードバックが生成されます。FabricLoopは仮説、テスト結果、分析を1つのスレッドにまとめ、チームが何を学んだか、なぜその判断をしたかを、何ヶ月後でも確認できるようにします。

この記事から持ち帰る10のこと

  1. MVPは特定の仮説をテストするための学習ツールであり、低品質な製品ローンチではありません。
  2. 「ミニマム」は難しくありません——「バイアブル」が難しいのです。誰も使わないものは何も教えてくれません。
  3. 作る前に仮説を書いてください：前提、テスト方法、そして「ノー」がどのように見えるか。
  4. コンシェルジュ型MVP（完全に手動での提供）は、6ヶ月の開発よりも2週間で多くのことを教えてくれることがよくあります。
  5. オズの魔法使い型MVPは動作するUIを見せますが、手動で処理します——インフラなしで需要をテストします。
  6. コアバリューを提供しコミットメントを得るものだけを含め、他はすべて削除してください。
  7. MVPは実験後に完全に廃棄される可能性があります——それは問題なく、想定内のことです。
  8. 称賛は検証ではありません；再来訪と支払いが検証です。
  9. ユーザーが理解する前になぜ有用かを説明しなければならなかったなら、バリュープロポジションの見直しが必要です。
  10. 「これに月額X円払いますか？」——そして沈黙——が初期プロダクト検証で最も示唆に富む質問です。