フレームワーク活用ガイドひとことで言うと#
実際にはまだ開発していない機能のボタンやリンクだけをプロダクトに配置し、ユーザーがクリックするかどうかで需要を実測する検証手法。クリックした人には「現在開発中です」と表示し、開発前に「作ったら使われるか」のデータを手に入れる。
押さえておきたい用語#
- フェイクドア（Fake Door）
- まだ実装されていない機能の入口だけを設置したUI要素。ボタン・リンク・メニュー項目など、ユーザーが操作できる形で配置する。
- クリック率（CTR）
- フェイクドアが表示された回数に対するクリック数の割合。需要の強さを示す定量指標として使う。
- ウェイティングリスト
- フェイクドアをクリックしたユーザーに表示する「開発中です。通知を受け取りますか？」の画面。メール登録率が需要の深さの指標になる。
- スモークテスト
- フェイクドアテストとほぼ同義で使われることが多い。実際のサービスがない段階でLP（ランディングページ）を公開して反応を見る手法を指す場合もある。
フェイクドアテストの全体像#
実践ステップ#
ここが難しい——ユーザーの信頼を損なうリスク#
フェイクドアテストの最大の懸念は「期待させておいて裏切る」ことでユーザーの不信感を招く可能性だ。特にBtoBプロダクトでは「なぜ動かないボタンを置くのか」とクレームになることがある。
対策は透明性と価値提供のバランスを取ること。「開発中」メッセージにはお詫びと感謝を明記し、通知登録者には機能の進捗を実際にフォローアップする。また、テスト期間は必要最小限に抑え、長期間フェイクドアを放置しない。
実践例#
BtoB SaaS企業が「レポートのPDFエクスポート」機能の需要を検証した。ダッシュボード画面に「PDFエクスポート」ボタンを追加し、クリックすると「現在開発中です。リリース時にお知らせしますか？」と表示。
2週間でインプレッション4,200、クリック380（CTR 9.0%）、通知登録142件（登録率37%）。事前の成功基準CTR 5%を大幅に超え、開発GOとなった。通知登録者へのインタビューでは「毎月の報告資料に使いたい」という具体的なユースケースが判明し、そのまま要件定義に反映された。
ECアプリが「ウィッシュリストの共有機能」を検討していた。商品詳細ページに「ウィッシュリストを友達にシェア」ボタンを設置してフェイクドアテストを実施。
2週間でインプレッション12,000、クリック180（CTR 1.5%）、通知登録22件（登録率12%）。事前の成功基準CTR 3%を下回り、No-Go判断となった。クリックしたユーザーへのインタビューでは「誕生日プレゼントのヒント用」という特定の文脈に限られており、汎用的な需要がないことが確認された。この結果、3スプリント分の開発工数を別機能に振り向けることができた。
まとめ#
フェイクドアテストは「ユーザーの行動で需要を測る」という原則に忠実な検証手法だ。アンケートの「使いたい」という回答と、実際のクリック行動には大きな乖離がある。未実装のボタン1つで、開発前に需要の有無と強さを数値で把握できる。テスト期間は短く、コストはほぼゼロ。「作ったけど使われない」を防ぐための最もコスト効率の高い手法の一つだ。