発売前のユーザーリサーチのほとんどは茶番であり、最悪なのは双方とも自分のセリフを分かっているということです。「こういうものがあったら使いますか」と尋ねると、電話の向こうの人——親切心があり、何のリスクも背負わず、存在しない製品を頭の中で想像しているだけの人——は「はい」と答えます。それを検証結果として記録してしまう。しかしそれは検証ではありません。仮定の話に対して見知らぬ人が礼儀正しく振る舞っているだけです。
以前は私もこうしたインタビューを欠かさず行っていました。あらゆるプロダクト戦略の本がそう勧めているからです。コードを一行書く前に50人のユーザーに話を聞け。ペインポイントを見つけろ。ソリューションの前に問題を検証しろ。規律正しく聞こえますし、ホワイトボードに書くと見栄えもします。しかし、10回のディスカバリーコールから実際に得られるのは、10人が「あなたが聞きたいだろうこと」を、通話が始まってから初めて考えたような問題についての曖昧な記憶を通して語っているだけです。誰も意図的に嘘をついているわけではありません。ただ、まだその情報を持っていないだけです——なぜならその情報は、実物ができるまで存在しないからです。
インタビューでは得られないもの
作る前に本当に知る必要があるのは態度ではなく行動です。その人が二度目にアプリを開くか、お金を払うか、3番目の画面で詰まってやめてしまうか。これらのどれも会話には表れません。セッションリプレイ、離脱率のグラフ、サポートチケットに現れます。ユーザーはオンボーディングが「わかりやすい」と心から言いながら、40秒で離脱することがあります。自己申告と実際の行動は、まったく別のものを測る別の計測器だからです。
経済性の面からも、以前はインタビュー先行の順序が強制されていました。実物を作るのに8週間と3人のエンジニアが必要なら、出荷後に間違いに気づく余裕はありません——だからこそ、リスクを安価な会話に前倒しし、それが高くつく失敗を捕まえてくれることを願うわけです。この取引は、構築がボトルネックだった時代には理にかなっていました。しかし今は違います。実際に動作するプロトタイプ——本物の認証、本物のデータベース、実際にクリックして操作できるUI——は、適切なツール（私のものも含む）があれば、今や午後の数時間で作れるものになりました。最初のバージョンのコストがそこまで下がると、インタビューはもはや安価なリスク低減策ではなく、高くつくステップになってしまいます。週末で済む構築を避けるために、何週間もの日程調整コストを払っていることになるのです。
私が代わりにやっていること
アイデアの最小限の実物版を作り、その問題を実際に抱えている3〜5人に見せて、質問するのではなく観察します。「どう思いましたか」ではなく、「カーソルがどこでためらったか」「クリックしても何も起きなかったのはどこか」「製品がまったく対応していないのに試みたことは何か」を見るのです。この最後のものが最も価値があります。促されずに試みた行動は、仮定のインタビューで語られたどんな言葉よりも真実の信号です。なぜなら、それは表明された選好ではなく、実際に現れた選好だからです。
これは従来のリサーチのファネルを逆転させます。何が変わるのかを明確にしておく価値があります：
| インタビュー先行 | 構築先行 | |
|---|---|---|
| 何を測定しているか | 表明された意図（「たぶん使うと思います」） | 実際に現れた行動（今週3回開いたか、開かなかったか） |
| 間違っていた場合のコスト | 1サイクルあたりは低いが、何十回ものインタビューを重ねる中で何ヶ月も間違い続ける可能性がある | 1回の構築サイクルで済み、その後はデータが素早く修正してくれる |
| 最適な質問 | 「今のやり方で、何が面倒だと感じますか？」 | 「直近でここでXをしようとしたときのことを見せてください」 |
| 何を見つけるのに向いているか | そもそも問題が存在するかどうか | その問題に対するあなたの具体的な解決策が機能するかどうか |
| 失敗パターン | 誰もが礼儀正しく、誰も本音を言わないので、自信満々に間違ったものを作ってしまう | 信頼を得る前に未完成なものをリリースしてしまい、悪い第一印象を与える |
この2つの行が互いを打ち消し合っているわけではないことに注目してほしい——それぞれ異なる問いに答えているのだ。インタビューは、問題が本当に存在することを確認するにはそれなりに有効だ。しかし、あなたの具体的な解決策が正しいかどうかを教えてくれる点では弱い。なぜなら、あなたの具体的な解決策はまだ誰の目にも触れていない状態で、正直に反応しようがないからだ。これは「ユーザーと話せ」というアドバイスの多くが見落としている区別だ——それは通常、問題発見にとっては良いアドバイスで、ソリューション検証にとっては悪いアドバイスなのに、人はその両方に同じように適用してしまう。
私の知る創業者は、美容室向けのスケジューリングツールについて14件のインタビューを行った。13人がダブルブッキングの問題は本当に痛いと答えた。彼女はそれを作った。しかし導入は伸び悩んだ。結局のところ、美容室のオーナーたちは抽象的にはダブルブッキングを嫌っていたが、すでに手放したくない場当たり的な個人的回避策を確立していたのだ——これは誰も口にしなかったことだった。なぜなら、代替案を見せて実際に断られる場面を目にしない限り、誰も自分の対処法をわざわざ説明しようとは思わないからだ。
批判派が正しい部分
これはどんな場合にも当てはまるわけではなく、そう言い切ってしまえば話を盛りすぎだろう。もし構築が本当に元に戻すのが高くつく場合——ハードウェア、規制のある医療ワークフロー、変更のたびにコンプライアンス審査がついて回るようなもの——であれば、インタビュー先行の計算は再び逆転する。なぜなら、構築先行を安上がりにしているコストの非対称性がそこでは成り立たないからだ。午後のうちに捨てられるプロトタイプと、金型を作り込んだデバイスとはまったく別物だ。
リサーチが本領を発揮するもう一つの場面は、長い営業サイクルを伴うエンタープライズ営業だ。買い手が調達委員会で、営業サイクルが4か月もあるなら、「とにかくリリースして様子を見る」だけで契約にたどり着くことはできない——構築前に、そもそもそのプロダクトがセキュリティ審査を通過するかどうかを知っておく必要がある。6か月後に破談になる案件は、どんなインタビューよりもはるかにコストが高くつくからだ。そして、純粋な問題発見——将来のプロダクトを想像してもらうのではなく、相手が実際に仕事をしている場に同席すること——を早い段階で低コストに行うことは、本当に見過ごされがちで、本当に有用だ。私は人と話すこと自体に反対しているわけではない。礼儀正しい仮定の会話を証拠として扱うことに反対しているのだ。同じ相手の目の前に10分間、粗削りでも本物の構築物を置けば、真実を教えてくれるというのに。
