企画会議では高評価でした。インタビューでも「欲しい」という声がありました。それでも、数カ月かけて作った製品が使われないことがあります。作る前に確かめた需要が、申込や日程調整、情報提供といった行動へ移っていなかったからです。
プレトタイピングとは、製品を作る前に顧客が選べる場面を仮設し、需要の有無を行動で確かめる手法です。「興味がありますか」と尋ねる代わりに、申込、条件入力、面談予約、社内関係者の同席などを選べる状態にします。
この記事では、プレトタイピングの定義、MVP・プロトタイプ・PoC・テストマーケティングとの違い、代表的な型、6段階の進め方、BtoBで観測する行動、結果の読み方を解説します。
プレトタイピングとは|「作る前に売る」の意味
プレトタイピングは、事業案の主要部分を開発せず、顧客が選択できる場面を再現する方法です。開発投資の前に「そもそも作るべきか」を問い、対象顧客、提案、条件を見直す材料を得ます。
プレトタイピングを提唱したAlberto Savoiaは、『Pretotype It』と『The Right It』で、製品を正しく作る前に、作るべき製品かを確かめる考え方を示しました。pretotypeという語には、prototypeより前に試す意図があります。
「作る前に売る」の焦点は、売上の先取りではありません。顧客に選択を求めることです。申込フォームへの入力、面談枠の確保、利用データの準備には負担があります。手間を伴う行動は、口頭の好意よりも次の判断へつなげやすい材料です。
ただし、無料登録と有償契約、担当者の関心と決裁者の承認は別です。プレトタイピングでは、今回の提案と条件で、対象者が指定した行動へ進んだかまでを確認します。技術成立性、品質、安全性、法令適合性、継続利用は別に確かめます。
プレトタイピングとMVP・プロトタイプ・PoCの違い
どの手法を選ぶかは、完成度ではなく、今回答えたい問いが基準です。需要を問うのか、操作を問うのか、技術や業務の成立条件を問うのかを先に分けてください。
手法 | 中心となる問い | 顧客が触れるもの | 次の判断 |
|---|---|---|---|
プレトタイピング | その提案は選ばれるか | 説明ページ、見本、予約枠、人力提供など | 開発へ進むか、対象・提案を変えるか |
プロトタイプ | 形・画面・操作は理解されるか | 模型、画面遷移、試作品 | 形状や体験をどう直すか |
PoC | 技術・業務・提供体制は成立するか | 限定した実証環境 | 成立条件を満たせるか |
MVP | 最小限の実体で価値が届くか | 利用できる製品・サービス | 利用データから何を学び直すか |
テストマーケティング | 限定条件で実際に売れるか | 販売可能な商品・サービス | 展開条件、価格、販売方法をどう直すか |
MVPは、顧客について学ぶための最小限の製品という考え方です。プレトタイプは、その投資前に提案が選ばれるかを確かめます。クリックできる画面で操作を見るならプロトタイプ、画面の先の申込まで進むかを見るならプレトタイプです。
呼称の範囲は企業や業界で揺れます。社内で名称をそろえるより、「今回は何を答える検証か」を一文にするほうが、手法の取り違えを防げます。
プレトタイピングで需要を確かめる4つの型
ページを作りやすいからフェイクドアを選ぶと、本当に見たい行動とのずれが生じがちです。先に期待行動を決め、その行動が起きる最小限の場面を選びます。
フェイクドア|提案から行動へ進むかを見る
提供前のサービスに説明ページやメニューを用意し、「利用を検討する」「先行案内を受け取る」といった入口を置きます。未提供・検証中であること、取得する情報、次の連絡を明示してください。
見るのは、対象者がどの入口を選び、必要事項をどこまで入力したかです。広告経由と既存顧客への案内は分けて記録します。
ピノキオ|利用場面に置いた反応を見る
動かない模型や見本を、実際に使う場所や業務へ置きます。法人向け報告サービスなら完成見本を用意し、対象者が手に取るか、会議で共有するかを見ます。
「見た目がよい」という感想を需要の証拠にしません。関係者への共有、利用条件の質問、次回打合せの設定を行動として残します。
人力提供型|価値だけを先に届ける
将来はシステムで処理するサービスを、最初は人が提供します。面談記録の整理なら、受領、分類、確認、納品を手作業で行い、成果物が実務で使われるかを確かめます。
処理時間、判断に迷った箇所、顧客への確認回数、例外対応を残します。顧客が受け取った価値と、提供側の負荷は別々に記録します。
限定受付型|条件付きの申込まで進むかを見る
提供時期、対象、利用条件を絞り、相談予約、導入審査、試用申請を受け付けます。日程選択や条件入力まで求め、対象者がどこまで具体的に答えるかを見ます。
「先着」「限定」で反応が変わるなら、その条件を事実どおり示し、通常時の需要と分けて扱います。
プレトタイピングの進め方|仮説から判定まで
説明ページの公開を完了条件にすると、反応がなくても「露出不足」で終わってしまいます。顧客、利用場面、提案、期待行動、反証条件を実施前に記録し、6段階で進めます。
1.崩れたら止まる前提を一つ選ぶ
「需要がある」ではなく、「製造業の新規事業担当者が見本を見た後、実データを使う相談を予約する」という前提です。
2.対象者と接触条件を決める
業種・役職だけでなく、課題の経験、現在の対処、意思決定への関与で定義します。
3.観測する行動と反証条件を書く
「興味を持つ」ではなく、申込開始、条件入力、日程選択などの動詞が対象です。
4.顧客に見せる範囲だけ再現する
判断に必要な説明、見本、条件、入口だけ作ります。裏側が手作業なら、その負荷も記録します。
5.説明とデータの扱いを確かめる
未提供機能を提供中と誤認させません。取得情報、利用目的、保管、削除、連絡方法を確認します。
6.行動ログと理由を分けて残す
「導入したい」は発言、「日程を選んだ」は行動です。誰がどこまで進み、どこで止まったかを記録します。
修正と停止の条件も開始前に分けてください。行動直前で止まった理由が提案の説明不足なら修正できますが、対象者が課題を経験していないなら、対象仮説から見直します。
BtoBのプレトタイピングで観測する行動
BtoBでは、最初に興味を示した担当者だけを見ても導入までの障害は分かりません。利用者、課題責任者、決裁者、法務・情報管理、提供側の行動を分けます。
観測対象 | 行動の例 | まだ証明していないこと |
|---|---|---|
利用者 | 利用場面を説明し、必要なデータ項目を確認する | 予算承認、継続利用 |
課題責任者 | 対象案件を選び、試行の打合せを設定する | 契約、全社展開 |
決裁者 | 費用条件を確認し、社内手続きへ載せる | 実利用、運用定着 |
法務・情報管理 | データ項目と取扱条件を確認する | 事業価値、購入意思 |
提供側 | 手作業で納期と品質を守り、例外を記録する | 自動化後の採算、規模拡大 |
たとえば、面談記録を整理するサービスなら、AI機能の開発前に匿名化した記録と手作業の納品見本を示します。対象者がデータの持ち出し条件を確認し、関係者を含む試行相談を予約したなら、ページを見ただけの反応より確かな次の検証材料になります。
提供可能な範囲、検証中の工程、人が処理する部分、使うデータ、納期を伝えてください。受注できるように装うと、条件を理解した上で進んだ行動かどうか分からなくなります。
プレトタイピングの結果を続行・修正・停止へ分ける
閲覧が1,000件あっても、対象顧客が含まれなければ需要仮説は判定できません。申込があっても、無料資料だけが目的なら有償導入の証拠ではありません。反応数だけでなく、接触、理解、行動、負担、離脱、提供の6段階で読みます。
- 接触:対象条件に合う人へ届いたか
- 理解:提供案と検証中であることが伝わったか
- 行動:事前に決めた行動へ進んだか
- 負担:時間、情報、社内調整、費用条件をどこまで引き受けたか
- 離脱:誰が、どの条件で、なぜ止まったか
- 提供:人力で補った工程に、どの負荷と例外があったか
続行は、すぐ開発するという意味ではありません。提供負荷が不明なら人力提供を続け、決裁者が未確認なら費用と契約条件を提示します。需要行動が見えた後にMVPへ進み、価値の利用と反復を観測します。
修正では、対象顧客、利用場面、提案、条件、入口のどれか一つだけを変えます。同時に変えると、反応が動いた理由を特定できません。
対象者が提案を理解しても負担を伴う行動へ進まず、提案を変える根拠も得られないなら停止します。作らない判断を得ることも、プレトタイピングの成果です。
まとめ|プレトタイピングで作る前に選択を確かめる
プレトタイピングとは、製品開発前に顧客が選べる状況を再現し、需要仮説を発言ではなく行動で確かめる手法です。MVPへ進む前に、そもそも作るべきかを問います。
説明ページ、動かない見本、人力提供、限定受付のどれを使う場合も、手段より先に対象顧客、利用場面、提案、期待行動、反証条件を決めます。BtoBでは、利用者、課題責任者、決裁者、法務・情報管理、提供側の行動を分けてください。
結果は閲覧数や好意的な発言だけで判定しません。対象者へ届いたか、どの負担を引き受けたか、どこで止まったかを追います。需要行動が見えればMVPへ進み、見えなければ対象や提案を修正するか、開発を止めます。
