フェイクドアテストとは？｜作る前にボタン1つで需要を確かめる検証手法と、信頼を損なわない設計

新しい機能を作るかどうか、会議で決めきれずに時間だけが過ぎていく。そんな経験はありませんか。

欲しいと言う顧客の声はあるのに、本当に使われるのかは誰にも断言できない状態です。

開発には数週間から数か月かかります。作り終えてから誰も使わないと分かったときの痛みは、チームの規模が小さいほど重くのしかかります。

そこで、作る前に需要を確かめる方法として広く使われてきたのがフェイクドアテストです。本記事では、その仕組みと向き不向き、そして見落とされがちな信頼の問題まで含めて、実務で使える形に整理します。

フェイクドアテストとは何か

まずは言葉の意味から確認しましょう。フェイクドアテストとは、まだ存在しない機能や商品への入口だけを用意し、どれだけの人がその入口に手を伸ばすかを測る検証手法です。

入口とは、たとえば画面上のボタンやメニュー項目、料金表のプラン、あるいは商品のランディングページ（広告や検索から最初に着地するページ）です。押した先には機能がなく、準備中である旨の案内や、関心のある人向けの登録フォームが表示されます。

名前の由来と呼び方

フェイクは偽物、ドアは扉を意味します。壁に扉の絵を描いても、その向こうには部屋がありません。

英語圏ではペインテッドドアテスト（描かれた扉のテスト）とも呼ばれます。ランディングページで市場全体の反応を見る場合はスモークテストと呼ばれることもあり、呼び名は違っても考え方の芯は同じです。

何を確かめるための手法か

フェイクドアテストが答えてくれるのは、その入口を見た人のうち、どれだけが実際に行動したかという一点です。アンケートで欲しいかと聞かれて、はいと答えるのは簡単です。

一方で、忙しい作業の途中にボタンを押す、あるいはメールアドレスを入力するという行動には、小さくても現実のコストがかかります。言葉ではなく行動で関心を測れることが、この手法のいちばんの価値です。

なぜ作る前に試すのか

プロダクト開発では、作る前に確かめる活動をプロダクトディスカバリーと呼びます。全体像はプロダクトディスカバリー入門｜作る前に確かめる進め方で解説しましたが、フェイクドアテストはその中でも特に安く速い道具のひとつです。

言葉と行動のずれ

顧客インタビューやアンケートは、なぜ欲しいのか、どんな場面で困っているのかを深く知るのに向いています。ただ、欲しいかどうかの量を測るには弱い面があります。

人は聞かれると、相手に合わせて前向きに答えがちです。

将来の自分の行動を正確に予測するのも苦手です。だからこそ、言葉で集めた仮説を、行動で確かめる段階が要るのです。

作るコストとの比較

作る前に試す意味は、費用の差を並べると見えやすくなります。以下は数値ではなく、手法ごとの性格を比べたものです。

表のとおり、フェイクドアテストは関心の量を安く測ることに特化しています。使い続けてもらえるかや、価値が本当に届くかまでは分からない点は、最初から割り切っておくべきです。

仮説検証の流れの中での位置づけ

フェイクドアテストは、単独で結論を出す道具ではありません。仮説を立て、小さく試し、学んで次の打ち手を決めるという一連の流れの、序盤に置くのが自然です。

この流れ全体は仮説検証型のプロダクト開発｜思いつきで作らないための型で整理しています。フェイクドアテストで関心が確認できたら、次は手作業の試作や限定公開で、価値が届くかを確かめる段階に進みます。

AIで作るのが速くなった今も意味はあるか

生成AIのコーディング支援が広がり、ちょっとした機能なら数日で形にできるようになりました。それなら、偽の扉など置かずに本物を作って出せばよいのでは、と感じる人もいるでしょう。

確かに、作るコストが下がるほど、フェイクドアテストの出番は減ります。試作を作るのが扉を描くのと同じくらい安いなら、本物を限定公開した方が多くを学べるからです。

それでも、作るコストは書く手間だけではありません。作った機能は保守し続ける必要があり、画面が増えるほど製品は分かりにくくなります。

一度公開した機能を取り下げるのは、作るよりもずっと気を遣う作業です。だからこそ、AIで作れる時代でも、作るかどうかの判断材料を安く集める価値は残ります。

代表的な3つのやり方

一口にフェイクドアテストと言っても、扉を置く場所によって性格が変わります。よく使われる型を3つ見ていきましょう。

製品内のボタンやメニュー

すでに使われている製品の中に、新機能への入口を置く型です。たとえばレポート画面に、CSVで書き出すというボタンを一つ足すようなやり方です。

いま製品を使っている人の、実際の作業の流れの中で関心を測れるのが強みです。その反面、既存ユーザーにしか届かないので、新しい市場の需要を測るには向きません。

料金表に新プランを置く

料金ページに、まだ提供していない上位プランやアドオンを並べる型です。押すと、提供開始のお知らせを受け取る登録フォームが開きます。

この型の価値は、機能への関心だけでなく、お金を払う意思にどこまで近いかを探れる点にあります。価格そのものの受け止められ方を調べたいなら、PSM分析（ヴァン・ウェステンドルプ法）のような価格アンケートの手法と組み合わせると、言葉と行動の両面から見られます。

ランディングページで市場に問う

まだ製品がない段階で、製品があるかのような説明ページを作り、広告や投稿で人を集める型です。インディーハッカーやAIソロプレナーが、新しい事業アイデアを試すときによく使われます。

ボタンを押した先で準備中であることを伝え、メールアドレスを残してもらいます。製品を一行も書かずに、市場の反応を見られるのが最大の利点です。

ただし、集客の仕方で結果が大きく変わる点には注意が必要です。広告の文言や配信先を変えれば、同じページでも反応率は簡単に上下します。

設計と測り方の手順

フェイクドアテストは手軽なぶん、思いつきで始めて結果を都合よく読んでしまいがちです。ここでは、判断に使える結果を得るための手順を見ていきます。

合格ラインを先に決める

いちばん大事なのは、テストを始める前に、どの数字なら作ると決めるかを書いておくことです。結果を見てから基準を決めると、期待していた機能ほど甘く判定してしまいます。

合格ラインに業界共通の正解はありません。製品の性格や、作るのにかかる費用から逆算して、チームで合意した値を使います。

何を分母と分子にするか

指標は、扉を見た人を分母、押した人を分子にするのが基本です。画面を開いた人全員を分母にすると、扉が目に入らなかった人まで含まれ、反応率が不当に低く出ます。

さらに一段深い行動として、押した先でメールアドレスを残した人の割合も記録しておきましょう。好奇心で押しただけの人と、本当に待っている人を区別できます。

以下は、手順を一枚にまとめた計画書の例です。数値はすべて説明用の仮定です。

仮説      : 週次レポートを使う人の一部は、自動でSlackに送る機能を求めている
扉        : 週次レポート画面の右上に「Slackに自動送信」ボタンを置く
対象      : 週次レポートを開いた既存ユーザーのみ（新規登録者は除く）
期間      : 2週間（開始前に固定し、途中で延長しない）
指標1     : ボタンが表示された人のうち、押した人の割合
指標2     : 押した人のうち、通知登録まで進んだ人の割合
合格ライン: 指標1が8%以上、かつ指標2が30%以上なら開発に進む（仮定）
押した後  : 準備中であることを正直に伝え、通知登録と一言アンケートを出す

数字の読み方を例で確かめる

この計画で、週次レポートの画面でボタンが表示された人が1,200人、押した人が60人だったとします。反応率は5%で、仮定した合格ラインの8%には届きません。

ここで、合格ラインを下げて作ろうとするのは避けるべきです。代わりに、扉の位置が目立たなかったのか、そもそも需要が小さいのかを分けて考えます。

もう一つ大切なのが、人数が少ないうちは判断しないことです。

数十人の段階の反応率は、数人の偶然で大きく揺れます。必要な人数の考え方はA/Bテストのサンプルサイズ設計｜検定力とMDEをどう決めるかと同じなので、あわせて確認しておくと安心です。

計測の仕込み

計測で必要なのは、扉が表示されたことと、扉が押されたことの2つのイベントを記録することです。押した人の割合は、表示と押下を並べたファネルとして見ると読みやすくなります。

MonaLensのようにボタンのクリックをファネルの一段として扱えるツールなら、扉を押した人がその後どこへ移動したかまで追えます。押したあとすぐに製品を離れた人が多ければ、案内の文言が体験を損ねている可能性を疑えます。

信頼を損なわないための注意点

フェイクドアテストには、避けて通れない弱点があります。ユーザーに、存在しないものを見せているという事実です。

失望は確実に生まれる

ボタンを押した人は、その機能を使いたかった人です。押した先で何もないと分かれば、程度の差はあれ必ずがっかりします。

一度なら笑って許してくれる人も、何度も同じ目に遭えば、この製品の表示は信用できないと感じ始めます。製品内の扉は、同じ人に何度も見せないよう、対象と頻度を絞るのが鉄則です。

押した後の画面で誠実さを示す

失望を最小限にする鍵は、押した後の画面にあります。次の要素を入れておくと、体験は大きく変わります。

• 機能がまだ準備中であることを、ごまかさずに伝える
• なぜ聞いているのか、つまり本当に必要か確かめてから作りたいという理由を添える
• 提供開始を知らせる登録や、一言の意見を送れる欄を用意する
• 元の作業にすぐ戻れる導線を置く

この画面は、謝るためだけの場所ではありません。押してくれた人は、最も関心の高い協力者候補です。

理由や使い方を一言でも聞ければ、その後の設計に生きる情報が手に入ります。

やってはいけないケース

どんな場面でも使ってよい手法ではありません。代表的な避けるべき場面を表にまとめます。

特に、申込やお金のやり取りが完了したように見せる設計は避けてください。関心を測ることと、相手をだますことの境界を、チームで事前に言葉にしておくことが大切です。

押した人への約束を守る

通知登録をしてもらった以上、その人たちには結果を伝える責任があります。作ることになれば提供開始を知らせ、作らないと決めたなら、その判断も短く伝えましょう。

この最後の連絡を省くと、テストは単なる釣りになってしまいます。逆に、きちんと伝えれば、意見を聞いてくれる製品だという印象を残せます。

結果をどう次につなげるか

テストが終わったら、結果は大きく3つに分かれます。それぞれの場合に、次に何をすべきかを考えておきましょう。

合格ラインを超えた場合

関心があることは分かりましたが、使い続けてもらえるかはまだ分かりません。ここで一気に完成版を作るのではなく、最小限の版を限定公開し、実際の利用を見るのが堅実です。

公開後は、押した人のうち何割が使い始め、何割が使い続けたかを追いましょう。作った機能の定着を測る考え方は、機能の定着率（アダプション）｜作った機能が使われない状態を測って直すで詳しく解説しています。

合格ラインに届かなかった場合

需要が小さいと判断して、開発の候補から外すのが基本です。これは失敗ではなく、数か月分の開発を使わずに済んだという成果です。

ただし、扉が目立たない場所にあった、文言が分かりにくかったなど、テストの設計に問題があった可能性も確かめます。設計を直して再テストするのは一度までにとどめ、結論を先延ばしにする言い訳にしないことが肝心です。

判断がつかない場合

反応率が合格ラインの近くで揺れていたり、人数が足りなかったりする場合もあります。期間を少し延ばしたくなりますが、延長するなら最初に決めた期間で一度区切り、改めて計画を立て直しましょう。

関心はあるのに登録まで進む人が少ない、という結果も考えられます。その場合は、押した人に直接話を聞くと、何が足りないのかが見えてくることがよくあります。

まとめ

フェイクドアテストは、まだ存在しない機能への入口だけを置き、どれだけの人が手を伸ばすかで需要を確かめる手法です。言葉ではなく行動で関心を測れ、作る前に安く速く結論に近づけるのが最大の価値です。

一方で、分かるのは関心の量までで、使い続けてもらえるかは別の検証が必要です。

合格ラインを先に決め、押した人に誠実に向き合い、結果を約束どおり伝える。この3つを守れば、ユーザーの信頼を損なわずに、作るべきものを見極める強力な道具になります。

次に新しい機能の議論で迷ったら、まずは扉を一つ描いてみることから始めてみてはいかがでしょうか。