フレームワーク活用ガイドひとことで言うと#
作る前に「そもそも人は欲しがるのか？」を最小コストで検証する手法。プロトタイプ（試作品）よりもさらに手前の段階で、フェイクや簡易的な仕掛けを使って需要の有無をデータで確かめる。Google出身のAlberto Savoia（アルベルト・サヴォイア）が提唱した。
押さえておきたい用語#
- Pretotype（プレトタイプ）
- 製品を実際に作らず、需要があるかを検証するための疑似体験や仕掛けのこと。「Pre（前の）+ Prototype（試作品）」を組み合わせた造語。
- XYZ仮説
- 「X%の人がYの状況でZをする」という形式で需要仮説を定量化する書き方。曖昧な「ニーズがある」を具体的な数値目標に変換する手法。
- スキン・イン・ザ・ゲーム（Skin in the Game）
- ユーザーが時間・お金・個人情報など何らかのコストを払う行為を指す。「いいね」や「興味ある」ではなく、実際に身銭を切る行動こそが需要の証拠になるという考え方。
- YODA（Your Own Data）
- 自分自身のデータ。他社の成功事例や市場レポートではなく、自分のターゲットから直接集めた一次データで判断すべきという原則。
プレトタイピングの全体像#
こんな悩みに効く#
- 新しいアイデアに自信があるが、本当に需要があるのか確信が持てない
- プロトタイプを作る時間もお金もないのに、上司から「データで示せ」と言われている
- 過去に「完成させてからローンチ → 誰にも使われなかった」を経験した
基本の使い方#
「いいアイデアだと思う」を定量的な仮説に変換する。
- X: ターゲット層のうち何%が反応するか（例: 20%）
- Y: どんな状況・文脈で（例: ランチタイムにオフィス近くで）
- Z: どんな行動をとるか（例: 予約ボタンを押す）
悪い仮説: 「このアプリはニーズがある」 良い仮説: 「オフィスワーカーの**15%**がランチ前に弁当予約ボタンを押す」
ポイントは、行動で書くこと。「欲しいと思う」「興味を示す」ではなく「クリックする」「メールアドレスを登録する」「お金を払う」。
アイデアに合った検証手法を選ぶ。代表的な手法は以下のとおり。
| 手法 | やり方 | 向いている場面 |
|---|---|---|
| フェイクドア | 存在しない機能のボタンやLPを作り、クリック率を計測 | Web・アプリ系の新機能 |
| メカニカルターク | 裏側を人力でまかないつつ、表面上は完成品のように見せる | 自動化サービスの需要検証 |
| ピノキオ | 機能しないモックアップを作り、反応を観察 | 物理プロダクト |
| ワンナイトスタンド | 一夜限りの限定イベントとして実施 | 飲食・体験型サービス |
| インフィルトレーター | 既存のプラットフォームに載せてテスト | マーケットプレイス型 |
コストは数千円〜数万円に抑える。作り込みすぎたら、それはもうプロトタイプ。
設計したプレトタイプを実際に展開し、行動データ（YODA）を集める。
集めるべきは「スキン・イン・ザ・ゲーム」のあるデータ。
| 強いシグナル（信頼できる） | 弱いシグナル（あてにならない） |
|---|---|
| お金を払った | 「買いたい」と言った |
| メールアドレスを登録した | 「便利そう」と言った |
| 予約した・注文した | SNSで「いいね」した |
| 友人に紹介した | アンケートで「使いたい」に丸をつけた |
実験期間は1〜2週間が目安。短すぎるとデータ不足、長すぎると時間の無駄になる。
XYZ仮説で設定した基準値と実データを比較し、次のアクションを決める。
- 基準を超えた → Go: プロトタイプ開発に進む
- 基準に届かない → ピボットか撤退: 仮説を修正して再実験するか、アイデアを捨てる
- 判断がつかない → 実験を改善して再実行: サンプルサイズが足りない、検証方法が甘い可能性
ここで大事なのは、感情ではなくデータで決めること。「せっかく考えたのに…」という気持ちは横に置く。
具体例#
東京・世田谷で個人経営のパン屋を営むオーナーが「グルテンフリーのパンを出したい」と考えた。ただし、米粉の仕入れコストは小麦粉の3倍。売れなければ赤字になる。
XYZ仮説: 「来店客の**10%**が、グルテンフリーパンの価格（1個480円）を見ても注文する」
プレトタイプ（フェイクドア方式）: 店頭のメニューボードに「グルテンフリー食パン 480円」を追加。注文が入ったら「すみません、今日は売り切れです。入荷したらLINEで通知しますか？」とLINE登録を促す。
結果: 2週間で来店客約400人のうち52人（13%）が注文を試み、うち38人がLINE登録した。仮説の10%を超えたため、米粉の仕入れと試作に着手。LINE登録者に先行販売したところ、初週で74個を販売した。
従業員120名のプロジェクト管理SaaS企業で、PMが「AIによるタスク自動振り分け機能」を提案。開発には4人月かかる見込み。CTOは「需要がわからないものに4人月は出せない」と回答。
XYZ仮説: 「既存ユーザーの**5%**が、AI自動振り分け機能のベータ版に申し込む」
プレトタイプ（フェイクドア方式）: ダッシュボードに「AIタスク振り分け（β）」ボタンを追加。クリックすると「現在開発中です。ベータテスターに登録しますか？」というフォームが表示される。
結果: 3週間でDAU 2,800人中312人（11.1%）がボタンをクリック。ベータ登録は189人（6.7%）。仮説の5%を超えたため、まず2人月で簡易版を開発する方針に切り替えた。フルスペック版を作らなかったことで、2人月分のリソースを別機能に回せた。
群馬県の温泉旅館（客室18室）の若女将が、平日稼働率32%を改善するためにワーケーションプランを検討。ただしWi-Fi増強とコワーキングスペース設置に350万円の投資が必要になる。
XYZ仮説: 「都内IT企業の担当者の**8%**が、1泊2日ワーケーション体験プランに申し込む」
プレトタイプ（ワンナイトスタンド方式）: Wi-Fi増強の代わりにポケットWi-Fiを5台レンタル（月額1.5万円）。宴会場の一角にテーブルと電源タップを並べた仮設コワーキングスペースを設置。Peatixで「温泉ワーケーション体験会 1泊2食付き9,800円」を限定10名で募集。
結果: SNSでの告知リーチ約600人に対し、申込23人（3.8%）。定員の2倍以上が集まったため追加開催を実施。参加者アンケートでは「月1で来たい」が78%、「会社の福利厚生として提案したい」が65%。若女将はまず350万円のうちWi-Fi増強の80万円だけを先行投資し、コワーキングスペースは仮設のまま3か月間のデータを集めることにした。
やりがちな失敗パターン#
- プレトタイプなのに作り込みすぎる — 検証に3か月かけたら本末転倒。プレトタイプは数日〜2週間で結果が出るものにする。完璧な仕掛けは必要ない
- 口先のフィードバックを信じる — 「欲しい！」「使いたい！」という声は当てにならない。メールアドレス登録、事前注文、クリックなど行動データだけを根拠にする
- 基準値を決めずに実験を始める — 「反応が良かったら進める」では、何をもって良いとするかが曖昧になり、結局感覚で判断してしまう。XYZ仮説で数値目標を先に決める
まとめ#
プレトタイピングは、製品を作る前に「そもそも需要はあるのか」を最小コストで検証する手法。XYZ仮説で基準値を定め、フェイクドアやワンナイトスタンドといった手法で行動データを集め、データに基づいてGo/No-Goを判断する。「作ったのに誰も使わなかった」という最大の失敗を防ぐために、プロトタイプよりも手前のこのステップを踏むことが、結果的に時間とコストの節約になる。