MVP Builder

MVP ビルダー

数カ月ではなく、1〜2週間で MVP をリリースしましょう。

基本原則

最もリスクの高い仮説を立証または否定する、最小のものから始めましょう。

MVP は Minimum Viable Product（実用最小限の製品）であり、Minimum Pretty Product（見栄え最小限の製品）ではありません。

MVP 機能マトリックス

すべての機能案を、このマトリックスを使って分類します。

カテゴリー	定義	対応
P0	中核となる価値提案に不可欠	今すぐ構築
P1	重要だが v1.1 まで待てる	検証後にリリース
P2	あるとうれしい機能、ユーザーを喜ばせる機能	v2 以降でリリース
対象外	検証に不要	無期限に延期

例：タスク管理 MVP

P0（第 1 週）：

• タイトルと説明を指定してタスクを作成する
• タスクを完了としてマークする
• タスク一覧を表示する
• 基本的な認証

P1（検証後）：

• 期限、優先度、リマインダー

P2（将来）：

• チームでの共同作業、ファイル添付、モバイルアプリ

対象外：

• ガントチャート、時間追跡、連携機能

5 つの MVP パターン

1. コンシェルジュ MVP

定義： 自動化を構築する前に、サービスを手作業で提供する

使用する場面： 中核となる価値がテクノロジーではなく、サービスの提供にある場合

例：

• 食品配達 → WhatsApp で注文を受け、自分で配達する
• AI コピーライター → 顧客向けのコピーを手作業で作成する
• スケジュール調整ツール → メールで会議を調整する

期間： 1〜3 日 | 検証できること： サービスを求める人がいる

---

2. ウィザード・オブ・オズ MVP

定義： インターフェースは自動化されているように見えるが、裏側では人間が操作する

使用する場面： 自動化の構築にコストや複雑さがかかる場合

例：

• Zapier の初期 → 連携機能を手作業で作成
• AI チャットボット → 人間が回答し、顧客は AI だと思っている

期間： 1 週間 | 検証できること： ユーザーがインターフェースを利用する

---

3. ランディングページ MVP

定義： 製品を説明し、メールアドレスを集める（製品はまだない）

使用する場面： 何かを構築する前に需要を試す場合

例：

• Dropbox → コンセプトを紹介する動画
• Buffer → コードが存在する前にランディングページを公開

期間： 1〜2 日 | 検証できること： ウェイトリストに登録する人がいる

---

4. 単一機能 MVP

定義： 1 つの問題を解決する 1 つの機能

使用する場面： 1 つの機能で価値の 80％を提供できる場合

例：

• Twitter → 140 文字の投稿をするだけ
• Instagram → フィルター付きの写真を共有するだけ
• Stripe → クレジットカード決済を受け付けるだけ

期間： 1〜2 週間 | 検証できること： 中核機能を使う人がいる

---

5. 組み合わせ型 MVP

定義： 独自に構築する代わりに、既存のツールを組み合わせる

使用する場面： 既存のツールを寄せ集めて解決策を作れる場合

例：

• Typeform + Airtable + Zapier + Stripe
• ノーコードツール：Webflow、Bubble、Retool

期間： 2〜5 日 | 検証できること： ワークフローが最初から最後まで機能する

技術スタックの判断ツリー

Is this a web app?
├─ YES
│  ├─ Need real-time?
│  │  ├─ YES → Next.js + Supabase + WebSockets
│  │  └─ NO → Remix + PostgreSQL
│  └─ Simple CRUD? → Supabase + React
└─ NO
   ├─ Mobile app? → React Native + Expo
   ├─ API only? → Express + PostgreSQL
   ├─ Chrome extension? → Vanilla JS + Chrome APIs
   └─ CLI tool? → Node.js or Python

おすすめの MVP スタック：

• フロントエンド： React + Vite または Next.js
• バックエンド： Supabase（Postgres + Auth + Storage）または Express.js
• スタイリング： Tailwind CSS + shadcn/ui
• ホスティング： Vercel/Netlify（フロントエンド）+ Railway/Fly.io（バックエンド）
• 認証： Clerk または Supabase Auth
• 決済： Stripe Checkout

開発を高速化するツール：

• Supabase（10 分でバックエンドを構築）
• Vercel v0（UI の生成）
• Clerk（5 分で認証を設定）
• Stripe Checkout（20 分で決済を設定）

避けるべきアンチパターン

❌ 「念のため」の機能を構築する → 3 人以上のユーザーから要望があったら構築する ❌ リリース前にデザインを完璧にする → まずは機能するものをリリースする。見栄えが悪くても問題ありません ❌ アーキテクチャを過剰に設計する → MVP ならモノリスで問題ありません ❌ 独自の認証を構築する → Clerk、Auth0、または Supabase Auth を使う ❌ 最初に管理パネルを構築する → データベースの GUI（Retool/Supabase）を使う ❌ Web より先にモバイルアプリを作る → 常に Web を先に作る ❌ 100 万人のユーザー向けにスケールさせる → 10 人向けに構築し、必要になったらスケールさせる

MVP の品質基準

必須 ✅

• コア機能が最初から最後まで動作する
• 基本的な認証（ログイン／サインアップ）
• クラッシュせずにデプロイできる
• モバイル対応（見た目の美しさは不要です）
• 基本的なエラー処理

省略可能 ⏸️

• 完璧な UI／UX
• メール通知
• 高度な機能
• 分析ダッシュボード
• エラーモニタリング（検証後に追加）
• テスト（プロダクトマーケットフィット達成後に追加）

開発プロセス

第 1 週：コア機能の開発

1～2 日目：設計＋セットアップ

• 3 つの画面をスケッチする（紙／Figma）
• リポジトリ＋データベースをセットアップする（テーブルは最大 3～5 個）
• インフラをデプロイする

3～4 日目：開発

• 認証（ライブラリを使い、自分で開発しない）
• コア機能（ユーザーフローは 1 つのみ）
• 基本的な UI（コンポーネントライブラリを使う）

5 日目：仕上げ＋デプロイ

• 重大なバグを修正する
• 本番環境にデプロイする
• 友人 5 人に共有してフィードバックをもらう

第 2 週：検証

1～2 日目：反復

• 第 1 週のフィードバックで見つかった問題を修正する
• 不足している重要な機能を 1～2 個追加する

3～4 日目：ユーザー獲得

• ソーシャルメディアで共有する
• 関連コミュニティに投稿する
• 20 人に個別にメールする

5 日目：分析と判断

• 10 人以上がサインアップしましたか？
• 3 人以上が 3 回以上利用しましたか？
• 1～2 人がお金を払う意思を示しましたか？

判断ポイント：

• ✅ 上記がすべて「はい」→ P1 機能を開発する
• ❌ いいえ → 方向転換するか、プロジェクトを終了する

ローンチチェックリスト

ローンチ前（1 時間）：

• コアユーザーフローが最初から最後まで動作する
• サインアップ＋ログインが動作する
• HTTPS でデプロイされている
• プライバシーポリシー＋利用規約（ジェネレーターを使う）

ローンチ当日：

• スクリーンショット付きで Twitter／LinkedIn に投稿する
• 関連コミュニティ 3～5 か所で共有する
• 20 人に個別にメールする

ローンチ後の第 1 週：

• すべてのフィードバックに返信する
• 重大なバグを 24 時間以内に修正する
• 初期ユーザー 3～5 人にユーザーインタビューを行う

成功指標

MVP の検証基準：

• 初週に10 人以上がサインアップ
• 3 人以上が 3 回以上利用
• 1～2 人がお金を払う意思を示す

これらを達成した場合： 見込みがありそうです。P1 機能を開発してください。

達成できなかった場合： 方向転換するか、次に進んでください。誰も求めていないものに何か月も投資しないでください。

実際の MVP の事例

最小限の形から成功した例：

• Airbnb： アパートの写真＋PayPal のリンク
• Stripe： カード情報を収集するだけのフォーム
• Dropbox： 製品を作る前にデモ動画を公開
• Uber： サンフランシスコ限定の iPhone アプリ
• Facebook： ハーバード大学の学生限定、基本的なプロフィール

どれも、皆さんが想像するよりずっと小さく始まりました。

関連リソース

関連スキル：

• product-strategist - プロダクトマーケットフィットの検証用
• frontend-builder - UI の開発用
• api-designer - バックエンド API の設計用
• deployment-advisor - デプロイに関する判断用
• go-to-market-planner - ローンチ戦略用

関連パターン：

• META/DECISION-FRAMEWORK.md - プラットフォーム選定の判断ツリー

関連プレイブック：

• PLAYBOOKS/build-mvp.md - MVP を構築する手順（作成後）

クイックリファレンス

経験豊富なユーザー向け：

• 最もリスクの高い仮説を特定する
• MVP パターンを選ぶ（コンシェルジュ／ウィザード／ランディングページ／単一機能／段階的構築）
• 機能を分類する（P0／P1／P2／対象外）
• P0 のみを開発する（最大 1～2 週間）
• 見た目は粗くても機能するものをリリースする
• 10 人以上のユーザーで検証する
• P1 を開発するか、方向転換するかを決める