制約から逆算するしかない
ある自治体から相談が来た。
「食 × ジオパークを軸にしたコンパクト型のお試しツアーを、夏に実施したい。予算はツアー本体で 60 万円、日々のサポート費用で 200 万円。受け入れは最大 10 名まで。入札は 5 月中旬までに完了したい」
…これを読むと、Web プロダクトで MVP を逆算するときと同じ筋道で考えられる、と思った。
予算、時期、人数、テーマの 2 軸 ―― 制約はかなり明確に渡されている。あとはこれを 「何の仮説を、どこまで検証するためのプロト」 として組み直すか、だ。
このメディアの toushogata-kanban や kikakugai-yasai-kakouhin と同じ「一枚絵プロト」型で、設計の中身を書いておきたい。
まず、検証したい仮説を 1 行で書く
地域のお試しツアーは、たいてい「来てもらえば気に入ってくれるはず」という暗黙の前提で動いている。
けれど、PdM の視点で MVP を作るとき、最初にやるべきは 検証したい仮説を 1 行で書く ことだ。
このツアーの場合、僕がいま置いている仮説はこうだ。
「食 × ジオパーク」という 2 軸の体験を 1 泊 2 日で受け取った人のうち、一定割合が、ツアー後 30 日以内に何らかの次アクション（再訪 / 関係構築 / 移住相談）を取る
これを検証するための最小単位を、予算と人数の制約に当てはめていく。
制約を非機能要件として整理する
ヒアリングで出た制約を、プロトの設計条件として並べ直す。
| 項目 | 値 | プロト設計への影響 |
|---|---|---|
| ツアー本体予算 | 60 万円 | 1 回あたりの実施規模を縛る |
| 日々サポート予算 | 200 万円 | ツアー以外の伴走に使える |
| 最大人数 | 10 名 | 1 グループあたり 3〜5 名 × 2 回が現実的 |
| 実施時期 | 夏 | 入札完了 5 月中旬、準備期間 2 ヶ月弱 |
| テーマ | 食 × ジオパーク | 2 軸ある = どちらかを主、どちらかを副に置く |
ここで重要なのは、「最大 10 名」を 1 回で消費しないこと。MVP の原則からすれば、1 回目の学びを 2 回目に反映するために、回数を 2 回以上に分ける方が良い。
MVP 一枚絵
以下が、僕がいま頭の中で持っている一枚絵だ。
┌──────────────────────────────────────────────────┐
│ お試しツアー MVP v1 │
├──────────────────────────────────────────────────┤
│ │
│ 【検証したい仮説】 │
│ 食 × ジオパークの 1 泊 2 日体験を受け取った人の │
│ うち、X% が 30 日以内に次アクションを取る │
│ │
│ 【最小単位】 │
│ 1 グループ: 3〜5 名 / 1 泊 2 日 / 食を主・ジオを副 │
│ │
│ 【回数】 │
│ 夏に 2 回 (1 回目で学び、2 回目で改善) │
│ │
│ 【主要 KPI】 │
│ ① ツアー完了率 │
│ ② ツアー後 7 日 NPS │
│ ③ ツアー後 30 日次アクション率 ← 主要指標 │
│ │
│ 【非機能要件】 │
│ 予算 60 万 / 最大 10 名 / 夏実施 / 入札 5 月中旬 │
│ │
└──────────────────────────────────────────────────┘
各セクションを掘る
検証したい仮説
「食 × ジオパーク」と書かれているとき、これは複合仮説だ。分解するとこうなる。
- 仮説 A: 食を軸にした体験は、参加者の次アクションを引き出す
- 仮説 B: ジオパークを軸にした体験は、参加者の次アクションを引き出す
- 仮説 C: 食 × ジオパーク の "二軸の組み合わせ" 自体が、単軸より強い
MVP では、まず仮説 A と B を検証するべきだ。仮説 C は、A と B が成立したあとで初めて意味を持つ。
なので、設計上は 「食を主、ジオパークを副」 or 「ジオパークを主、食を副」のどちらかに振る。両方主は、MVP には重すぎる。
最小単位
1 グループ 3〜5 名。これは PdM 的に言えば「同じバッチで定性データを取れる最小単位」だ。
少なすぎると個別事情に流される。多すぎると 1 人 1 人の声が拾えない。3〜5 名は、ツアー後の振り返りインタビューを全員にやれる人数でもある。
回数
夏に 2 回。
1 回目は「仮説 A or B どちらかを試す」回。2 回目は「1 回目の学びを反映して、もう一度同じ仮説を試す」回 or 「もう一方の仮説を試す」回。
ここで重要なのは、1 回目と 2 回目のあいだに振り返りの時間を取る ことだ。Web プロダクトで言うと、A/B テストを 2 週間で 1 回しかしないのと、毎週リリースして毎週学ぶのと、後者の方が圧倒的に学習が速い。
主要 KPI
3 つ並べたが、本当に意思決定に使う指標は ③ ツアー後 30 日次アクション率 だ。
参加者の満足度（NPS）は嬉しい指標だけれど、満足したのに何もしない参加者は、ツアーの成功とは呼びにくい。逆に「ツアーは普通だったけど、その後、再訪して移住相談まで進んだ」人がいれば、それはツアーが起点として機能した、ということになる。
ツアー後の "次アクション" を、参加者ひとりずつにヒアリングする ―― ここを設計に組み込む。
このツアーが "プロト" であるために必要なこと
地域のツアーは "1 回やって終わり" になりがちだ。それを避けるためには、最初から MVP として扱う宣言が要る。
具体的には、
- 検証したい仮説を、自治体側と事前に合意する
- KPI を「集客数」ではなく「ツアー後の次アクション率」に置く
- 2 回実施で学びを反映するサイクルを契約条件に入れる
- ツアー後 30 日の伴走を、日々サポート 200 万円の中から確保する
このうち、特に重要なのは 「ツアー後 30 日の伴走」を予算化する こと。
ここを切ると、ツアーは "イベント" に戻る。残すと、ツアーは "プロト" になる。
ツアー後 30 日で起きてほしいこと
参加者の 30 日後の状態を、こう設計しておく。
| 段階 | 起きてほしいこと | 運営側のアクション |
|---|---|---|
| Day 0 | ツアー完了 | 当日終わりに 1 on 1 振り返り |
| Day 1〜3 | 余韻のなかで連絡 | 個別フォローメール / LINE |
| Day 7 | 次の動きの種を共有 | 「次にやってみたいこと」を聞く |
| Day 14 | 何か 1 つ試す | 試したことの共有を促す |
| Day 30 | 次のアクションを取る | 再訪・関係構築・相談の入り口 |
これは 前の記事 で書いた SaaS のオンボーディング設計と完全に同じ構造になる。違うのは、対象が "サインアップしたユーザー" ではなく "ツアー参加者" だという点だけだ。
開いている問い
このプロトを 1 度回した後で、
- 仮説 A と B のどちらが効くか
- 1 グループの最適人数
- 1 泊 2 日 vs 2 泊 3 日 のどちらが効くか
- ツアー後 30 日の伴走でどこに効くか
…が見えてくるはずだ。これを次の年度の入札に反映できれば、自治体側にとってもこのツアーは "資産" になる。
逆に、これを 1 度きりで終わらせると、来年もまた "60 万円で何ができるか" をゼロから議論することになる。
「ツアーを資産にできるか、毎年消費し続けるか」 ―― この分かれ目は、ツアーの内容ではなく、ツアー後 30 日の設計にある。
これが、いまの僕の仮説だ。