「MVPって“最小のプロダクト”じゃないの？」——よく聞かれます。私の答えは少し違っていて、MVPとは“最小の学習コストで最大の不確実性を崩す仕組み”です。特にBtoBtoCでは、利用者（C）・供給側/パートナー（B）・社内オペレーション（B）の三層の現実が絡むため、ふつうのLPテストだけでは学習が偏りがち。この記事は、未経験〜ジュニアPdM向けに、三層同時に学ぶMVP検証設計を現場目線でまとめた完全ガイドです（企業名や具体数値は非公開）。
1. まず“何を学ぶか”を1行で決める（学習焦点）
MVPの目的を、以下のように1行で言語化します。長いとブレます。
- 需要の真実：ユーザーはお金/時間/データのいずれかを差し出すほど価値を感じるか？
- 供給の成立：供給側（店舗・事業者・在庫など）は、負担＜便益で参加するか？
- 業務の現実：社内の手作業や例外処理を含め、回るか？（SLA/コスト/法務）
この3つのうちどれを最初に崩すかを決め、他は“観察”に留めます。全部やるとMVPになりません。
2. 三層MVPキャンバス：BtoBtoCに効く設計メモ
私はスプリント頭に三層MVPキャンバスを書きます。1枚で十分です。
【学習ターゲット】需要 / 供給 / 業務（いずれか1つを主）
【仮説】例：「初回の“お任せ提案”でCは即決する」「供給側は予約枠の空き埋めが主目的」
【対象】C：直近登録ユーザー / B：稼働中の小規模パートナー3社 / 内部：CS 1名＋Ops 1名
【最小介入】例：提案は人力（Concierge）・裏はスプレッドシートで在庫割当
【成功条件（2つまで）】例：初回成約率 ≥ X%、手作業工数 ≤ Y分/件
【中止条件（Gate）】例：クレーム>0 or 手作業>Y×2 で一旦停止して設計を戻す
3. 検証メニュー：学習コストに対して“濃い”順
- Fake Door（需要）：機能ボタン/プラン比較を置き、クリック/フォーム完了で意思を測る。
- Concierge（価値）：裏側は人力で価値体験を最短提供。品質は高く、仕組みは暫定。
- Wizard of Oz（可用性）：自動に見えるが中は手動。UX維持しつつ実装コストを寝かす。
- 供給サイドPOC：パートナー1社で在庫/規約/清算の現実を詰める。契約は覚書レベル。
- オペレーション・ドライラン：CS/営業/法務と“1件流す”。例外/責任分界を議事録化。
重要なのは同時多発でやらないこと。一つの学習ターゲットに集中し、他は観察データだけ取る。
4. 会話でわかる“濃い学習”の取り方
私：「最初の申込み、どこで迷いました？」
ユーザー：「選択肢が多すぎて、『これで合ってる？』って不安で…」
私：「もし“1クリック提案”があれば、押しました？」
ユーザー：「多分。まず1つ見たいです」
この3往復で「提案は1つで良い/説明より即提示」という濃い学習が取れます。MVPは、情報の濃さ/速さで勝ちます。詳しい聞き方は関連記事へ：ジュニアPdMが身につけたい「ユーザーインタビュー」の基本と実践。
5. 2週間スプリントの“検証設計テンプレ”
Day1 ：キャンバス合意（学習ターゲット/仮説/成功・中止条件）
Day2-3：UIモック/LP/GAイベント準備（Fake Door or Concierge台本）
Day4 ：内部ドライラン（CS/法務/Opsで1件流す）
Day5-7：本番テスト（10〜30件の接点を目安に）
Day8 ：定性ふりかえり（発言×時刻×画面の抜粋を整理）
Day9-10：KPIレビュー（Aha率/申込→完了/手作業工数/TTV）
Day11 ：意思決定（Pivot/Persevere/Kill）
Day12-14：AB改（勝ち案を微修正して次スプリントへ）
6. 指標設計：MVPは“先行指標×コスト”で見る
売上は遅行。MVP段階では、以下の先行指標＋学習コストで評価します。
- Aha到達率：価値に触れた割合（例：提案閲覧→保存／初回タスク完了）。
- TTV：最初の価値までの時間（分）。オンボーディングと一体で見る。
- 供給側の負担：対応ステップ数/件。現場の“ため息”は赤信号。
- Ops工数：手作業分/件。Wizard of Ozの“限界”を早く可視化。
KPIの置き方は詳しくこちら：PdMが成果を出すKPI設計と運用の実践ガイド。
7. 優先順位付け：リスクを崩す順にやる
MVPの並べ替えは“工数×学習価値”の掛け算。私は、重大リスク→可動化→スケール性の順で崩します。迷ったら、こちらのフレームが使えます：優先順位判断フレームワーク完全解説。
8. よくある失敗と回避策（BtoBtoC版）
- 失敗：Cだけ見てBが詰む → 回避：B側の「原価/規約/清算」を最初に1社で検証。
- 失敗：法務が最後に登場 → 回避：Day1のドライランに同席してもらう。
- 失敗：LPクリック＝需要と誤認 → 回避：実支払い/行動の変化を一次指標に置く。
- 失敗：オペレーションが“気合い” → 回避：手作業のSLAを数値で置き、Gateで止める。
9. そのまま使えるドキュメント雛形
■実験チケット
- 学習ターゲット：需要/供給/業務
- 仮説（1行）：
- 対象（人数・属性）：
- 介入：Fake Door / Concierge / WoZ / POC
- 成功条件（2つまで）：
- 中止条件（Gate）：
- 計測：Aha / TTV / 工数 / 例外件数
- ふりかえり日時 / 関係者：
■Concierge台本（電話/チャット）
- オープニング（30秒）：「今日は実際にやったことだけ伺います」
- 提案提示（1案）→ 了承なら予約へ / 迷いなら再提示
- クロージング（60秒）：次回の自走手順を1枚で案内
10. 物語：B側の“ため息”が消えた日
立ち上げ期、Cの体験ばかり磨いてBが悲鳴、という時期がありました。そこでスプリントの焦点を供給の現実に切り替え、覚書レベルのPOC・清算の暫定運用・在庫割当の手動化に限定。毎夕方15分のふりかえりで例外を全部“見える化”したところ、1週間で「どこを自動化すればいいか」が明確に。UIの派手さはないけれど、ビジネスとして回る輪郭が見え、以降の実装は驚くほど滑らかになりました。
11. 関連記事（内部リンク）
12. 有料note＆特典テンプレ
MVPキャンバス／Concierge台本／計測イベント定義のテンプレは、有料noteで配布しています。購入者特典として以下PDFも利用できます。
- PdMスキルテンプレート集（PDF）
- キャリア戦略シート（PDF）
13. まとめ：MVPは“最小の実験装置”
BtoBtoCのMVPは、需要・供給・業務の三層を一度に完成させない設計がコツ。学習ターゲットを1つに絞り、Fake Door → Concierge/WoZ → POCで段階的に濃い学習を取り、先行指標（Aha/TTV/工数）で意思決定する。次のスプリントでは、中止条件（Gate）を先に書き、実験の止め時から決めて始めましょう。
コメント