「新しいアイデアを思いついたけれど、本当に当たるかどうか…」と悩むことはありませんか？
仮説検証のプロセスで、実際にモックやユーザーインタビューを行う前に、アイデアの優先順位を決めかねたり、どこまで作り込めばいいのか悩んだりするPdMの方は多いと思います。
しかし、いざプロトタイプを作ろうとすると、意外に手間もコストもかかってしまい、「まだ検証も終わっていないのに、すでに疲弊してしまった…」という声も少なくありません。
そこで注目したいのが、「プレトタイピング(Pretotyping)」。
プレトタイピングは、最小限の労力で仮説を速攻で試し、無駄な開発を省くための手法。
この記事では、プレトタイプ検証の具体的な進め方と事例、手法カタログから始め方までを深堀りして解説します。
プロトタイプより手前のPretotyping
プレトタイピング(Pretotyping)とは、「最小限の準備」でアイデアの実現可能性を検証する手法。
これはGoogleの元チーフ・イノベーション・エンジニアであるアルベルト・サボイア氏が提唱した考え方で、「作りたいものの“影”を素早く実在化させ、ユーザーの反応を見て仮説の正否を判断する」点に特徴があります。
ユーザーが本当に望んでいる要素にフォーカスできるため、実際に開発を始める前に“危険な仮説”を潰せるのが魅力です。
従来のプロトタイプはある程度のUIやUXを実装した上でユーザーに見せることが多いですが、プレトタイプはさらに前段階の「“影絵”のような粗いアウトラインの検証」でOKです。
たとえば、実際にはほとんど機能が動いていないモックでも、“クリックしても反応がないボタン”だけを置いてみるなど、とにかく「ユーザーに行動させる導線」を作るのがポイントです。
その行動を取るか取らないかの定量・定性データから、「本当にそこにニーズがあるか？」を早期に判断します。
Pretotypingを導入するメリットとして、サボイア氏が示すPretotyping Manifesto（簡略版）は次のようにまとめられています：
- 1. ユーザーが求めるものを先に学ぶ
- 2. なるべくコードを書かずに検証する
- 3. 計測可能な行動指標を定義し、判断に活かす
- 4. 急いで壊して、急いで作り直す
この4つを忠実に守ることで、無駄なコストと時間を劇的に削減し、本当に必要な製品・機能に集中するスタンスが築けるわけです。
ちなみに、アイデアの粒度を整理する際には「ユーザーインタビュー前に“筋の良い仮説”を設定する」アプローチも併用すると、より検証効率が高まります。
Fake Door / Concierge / One-Night-Stand
プレトタイピングにはいくつかの定番手法があります。ここでは代表的な3つを紹介します。
- Fake Door
「クリックしても未実装」 のリンクやボタンを設置し、ユーザーが本当にクリックするかを測定する方式です。
例としては、ECサイトで新機能の「プレオーダー」ボタンだけ先に配置し、どれだけのユーザーが押すかで需要を測るなど。 - Concierge
「人力で裏を支える」 ことで、ユーザー視点ではあたかも完成品のように見える形を作ります。
たとえば、チャットボット機能があるように見せて、実際はチームメンバーが手作業で回答する。動的にAIを組み込む前に、ユーザーがどの程度求めるかを計測できます。 - One-Night-Stand
「1日だけ（あるいは短期）機能を“試作”してみる」 手法。
すぐに実装できる最小限の仕組みでサービスを擬似的に公開し、ユーザーの反応を計測します。SNS上のテストマーケティングや、ランディングページのみを公開するなどが典型例。
これらの手法はいずれも、大掛かりなアプリ開発やフロント実装に入る前にユーザー行動データを集めるのに有効です。
しかも、失敗した場合でも深刻なロスになりにくい点が最大のメリット。
大事なのは、「どの行動指標（KPI）を測定するか」を事前に明確にしておくことです。クリック数なのか、フォーム入力率なのか、CTAからの離脱率なのか。
具体的なKPIを決めておけば、Fake DoorやConciergeなどの運用をしてみるだけで、次に進むかどうかの判断材料が手に入ります。
ケース：モバイル新機能の需要測定
ここからは、もう少し具体的なケースを想定してみましょう。たとえばBtoCモバイルアプリで新しいチャット機能を企画しているとします。
実際に開発する前に、アプリ内のトップ画面に「New Chat」ボタンを配置し、Fake Doorとしてどれだけクリックされるかを測定するのです。
定量検証ステップは以下のとおり：
- テスト期間を1週間に設定
正式ユーザーや一部のテストユーザーに対して、Fake Door付きのテストバージョンを配布する。 - 3%のクリック率を目標閾値として設定
例：「全ユーザーの3%が『New Chat』をクリックすれば、最低限の関心ありとみなす」など。
数値は過去の機能導入時のクリック率実績をもとに定めることが多いです。 - 3%を上回った場合は次ステップへ
プロトタイピング（部分的に機能を実装）や、さらに詳しいユーザーインタビューを実施して掘り下げる。 - 3%未達ならアイデア修正かピボット
「なぜクリックされなかったか？」を調査し、アイデアの方向性を再点検。UIの問題なのか、ニーズ自体が薄かったのかを見直す。
このような「Next Step判断フロー」を先に決めておけば、結果を見てから悩む時間を減らし、次のアクションを素早く実行できます。
また、数字の結果とあわせてユーザーインタビューを行うことで、「なぜクリックしたか」「なぜクリックしなかったか」の背景を定性情報として補完できます。
さらに詳しいインタビューの設計については、ユーザーインタビューの目的・設計・やり方・分析まで完全ガイドを参照してください。
今日から実践できるアクション
ここでは、プレトタイピングをすぐに取り入れるための具体的な行動プランをまとめます。
- 検証したいアイデアを1つ選定する
チーム内で「本当に開発するか迷っている機能」をピックアップする。 - Fake Doorを設定する
LPやアプリ画面など、ユーザーが最初に触れる部分に「エントリーボタン」だけ配置してみる。できるだけ簡易に実装する。 - 判定基準を決める
クリック率やコンバージョン率など、1〜2個の定量指標を決めて「基準値」を設定する。「〇%を超えたら次フェーズへ」など。 - ユーザーの反応データを即座に収集する
Google Analytics等のトラッキングを仕込んでおき、数日〜1週間でデータを集める。 - 結果をもとにインタビューを行う
「押した/押さなかった」理由を深掘りするために、少数でもいいので実際のユーザーにヒアリングを実施する。
Q&A
- Q1. プレトタイピングとプロトタイプの違いは何ですか？
- A1. プロトタイプは機能やUIの一部を実際に作り込み、ユーザーに近い使用感でテストするステップです。
一方、プレトタイピングは「本格的に実装する前の“さらに前段階”」でアイデアが本当に必要とされるかを調べる手法です。実装コストを抑え、ユーザー行動を軽くテストする点が最大の違いです。 - Q2. プレトタイピングをする際にコードは必須ですか？
- A2. 必須ではありません。Fake Doorなど最小限のリンクボタン程度で済むことも多いです。Concierge手法の場合は人力で裏側を回すため、コードを書かずに検証が可能です。
- Q3. プレトタイピングはBtoBのプロダクトでも使えますか？
- A3. もちろん使えます。むしろ大掛かりなシステム構築になることが多いBtoBこそ、プレトタイピングで「導入意欲」や「担当者の権限」を事前に確認するのが有効です。Fake Doorの代わりに、営業資料の1スライドに“新機能予定”の提案を入れ、顧客が興味を示すかどうかを測るなど応用が可能です。
- Q4. プレトタイプ結果が良かったのに、いざ開発したら不発に終わりました…どうしてでしょう？
- A4. プレトタイピングはあくまで「ユーザーが食いつきそうか」を測る初期指標です。
開発後の不発要因としては、UI/UXの使いにくさや、オンボーディング設計の不備などが考えられます。
そのため、プレトタイプで需要があると分かった後も、継続的にプロトタイプやユーザーインタビューで改善していくプロセスが欠かせません。
参考情報
下記に本記事で触れた書籍・論文・参考リンクをまとめます。
「プレトタイプ」や「無駄ゼロの開発手法」をさらに深めたい方は是非ご覧ください。
- Alberto Savoia (2019), Pretotype It, 3rd Edition
- Eric Ries (2011), The Lean Startup, Crown Business
- Ash Maurya (2012), Running Lean, O’Reilly Media
┗ 記事で要約：【要約】『Running Lean』で顧客開発を加速させる - PM x LLM STUDIO：GPTs Builderでプロトタイプをすることで、仮説検証を高速にする
- PM x LLM STUDIO：PMにとって「心理的安全性」は高速実験を可能にする土台、という話
コメント