MVPの構築
コア仮説を素早く安くテストするMVPを構築する。何を含め、何を切るかの判断フレームワーク。
少なく作り、多く学ぶ
起業する時の本能は印象的なものを作ること。その本能と戦え。MVPの目的は感動させることではない。学ぶことだ。
🔄 Quick Recall: 前のレッスンで競合ランドスケープをマッピングし、市場規模を算出し、ポジショニングステートメントを作成した。何を作るかはわかった。問題は：仮説をテストするために必要な最小限のバージョンは何か？
MVPマインドセット
MVPはフルプロダクトの粗悪版ではない。焦点を絞った実験だ。
MVPとは：
- 最もリスクの高い仮説をテストするために構築できる最小限のもの
- ローンチプロダクトではなく学習ツール
- 実際の顧客が使えるまたはインタラクトできるもの
- 数日〜数週間で作る。数ヶ月ではない
MVPではないもの：
- 最終プロダクトのバージョン1.0
- 実際のユーザーがいないプルーフオブコンセプト
- 友人にだけ見せるプロトタイプ
- 構築に4〜6週間以上かかるもの
コア仮説の特定
すべてのスタートアップには他のすべてを決定する1つの仮説がある。見つける：
スタートアップアイデア：[説明]
コア仮説を特定してください：
1. これが機能するために顧客の行動について何が正しい必要があるか？
2. 支払い意欲について何が正しい必要があるか？
3. 提供能力について何が正しい必要があるか？
4. 上記のうち、間違っていたら他のすべてが無意味になるのはどれか？
5. 最小の労力でこの仮説をどうテストできるか？
コア仮説の例：
| スタートアップタイプ | コア仮説 |
|---|---|
| 食事宅配 | 人は自分で作らない健康的な食事にプレミアムを払う |
| AI文章作成ツール | ライターはAIに初稿を任せることを信頼する |
| 家庭教師マーケットプレイス | 保護者は口コミではなくアプリで家庭教師を予約する |
| B2B分析ツール | 企業はより良いインサイトのために分析ツールを乗り換える |
MVPはこの1つをテストする。他は今はまだ関係ない。
Quick Check: なぜ最もリクエストの多い機能ではなく、最もリスクの高い仮説をテストすべきか？
MVPのタイプ
すべてのMVPがソフトウェア開発を必要とするわけではない：
| MVPタイプ | 内容 | 最適な用途 | 例 |
|---|---|---|---|
| コンシェルジュ | サービスを手動で提供 | サービス系ビジネス | アプリを作る前にミールプランを手動でキュレーション |
| オズの魔法使い | 自動化に見えるが裏は人間 | テック系プロダクト | 裏で手動返信するチャットボット |
| ランディングページ | プロダクトを説明し登録を測定 | あらゆるプロダクト | 「ウェイトリスト参加」ページ |
| プリセル | 作る前に販売 | 明確な成果物があるプロダクト | クラウドファンディングや予約注文 |
| 単一機能 | コア機能1つだけ構築 | ソフトウェア | 1つのことを卓越して行うアプリ |
| 説明動画 | コンセプトを動画でデモ | 複雑なプロダクト | Dropboxはデモ動画でローンチした |
コア仮説をテストできるリストの中で最も安いオプションから始める。 ランディングページでテストできるなら、アプリは作らない。
ノーコードとAIで構築する
MVPの構築に開発者である必要はない：
ノーコードプラットフォーム：
- Bubble： コードなしのWebアプリケーション
- Webflow： プロフェッショナルなWebサイトとランディングページ
- Airtable： データベースとシンプルなワークフロー
- Zapier/Make： ツール連携とワークフロー自動化
- Typeform/Tally： インタラクティブなフォーム
AIによるビルディング：
- AIでランディングページのコピーを生成
- AIでプロダクト説明とオンボーディングフローを作成
- AIでヘルプドキュメントを作成
- AIで価格実験のための財務モデルを構築
コンシェルジュのショートカット： 何かを自動化する前に、手動でやる。「AIがメールを整理する」というコンセプトなら、まず10人の顧客のメールを手動で整理する。手作業でやることでアルゴリズムを構築するより無限に多く学べる。
機能の判断フレームワーク
含めることを検討するすべての機能について聞く：
- コア仮説をテストするか？ Noならカット。
- この機能なしでプロダクトを使えるか？ Yesならカット。
- 重要な学びが得られるか？ Noならカット。
- 後から追加できるか？ Yesなら今はカット。
冷酷なルール： MVPを一文で説明できるなら、スコープはおそらく適切。段落が必要なら、もっと切る。
AIによる機能スコーピング：
スタートアップ：[説明]
コア仮説：[最もリスクの高い仮説]
MVPに以下の機能を検討中：
[検討中の全機能リスト]
各機能について回答してください：
1. コア仮説を直接テストするか？
2. プロダクトが機能するために必須か？
3. 初期の学習後に追加できるか？
[コア仮説]が正しいかテストするために必要な絶対最小限の機能セットを推奨してください。
MVP成功の測定
ローンチ前に成功基準を定義する：
定量指標：
- サインアップコンバージョン率（訪問者→登録ユーザー）
- アクティベーション率（登録ユーザー→コアアクション完了）
- リテンション（2週目に戻ってくるユーザー）
- 売上（該当する場合、小額でも）
定性シグナル：
- ユーザーが他人にプロダクトを説明する（口コミ）
- ユーザーが機能を要望する（より多くを求めるほど気にしている）
- 欠けている機能のワークアラウンドを見つける（高いモチベーション）
- 感情的な反応（「こういうのを探していた」）
具体的な閾値を設定： 「ベータユーザーの20%が2週目に戻ってきたら前進。5%未満ならピボット。」
Key Takeaways
- MVPは最もリスクの高い仮説を最小限の時間とお金の投資でテストする
- すべてのMVPにコードは不要——コンシェルジュ、ランディングページ、プリセルモデルがソフトウェアなしでニーズをテストする
- すべての機能候補にコア仮説をテストするかを問う。Noならカット
- ローンチ前に成功指標と具体的な閾値を定義し、判断をエビデンスベースにする
- MVPを一文で説明できれば適切なスコープ。段落が必要ならもっと切る
Up Next: 次のレッスンでは「ピッチデッキの作成」——検証済みアイデア、市場調査、MVP結果を投資家とパートナーの注目を集めるピッチデッキに変換する。
理解度チェック
まず上のクイズを完了してください
レッスン完了！