第39章

言い訳としてのリサーチ

すでに信じていることを、調査で裏づけようとする

ユーザーが何を求めているかを知るために調査する、と自分に言い聞かせる。いつもそうとは限らない。ときには、調査が始まる前に答えは出ている。調査の役目は、会議で誰も異議を唱えないほど、その答えに重みを持たせることだ。事前の選定質問で、都合の悪い回答者が除かれる。インタビューの質問は、望む発見へ傾く。分析では、筋の通る話になるまでデータをまとめ直す。誰も嘘をつく必要はない。欲しかった答えを支えるものが十分集まったところで、探すのをやめるだけだ。

よくあるバイアスだ。まともな意図を持つ、まともなチームにも現れる。

確証バイアスは、物語を守る

この仕組みには名前がある。動機づけられた推論だ。Yale Law Schoolで、賢い人が事実に関して誤った結論に至る仕組みを研究した心理学者 Dan Kahan は、平易な言葉で定義している。

情報の評価を、正確さとは別の何らかの目標に合わせる傾向。
— Dan Kahan（英語からの翻訳）

デザインで、正確さ以外の目標となるのは、たいてい、すでにつくったプロダクトや、チームがすでに決めた方向性だ。結論が先に来る。調査はそのあとを追い、何かが結論を裏づけるまで続く。

Raymond Nickerson が1998年に発表した、数十の分野にわたる確証バイアスの広範なレビューは、問題が愚かさや不誠実さではないことを示している。脳は早い段階で情報をふるい分ける。持っている信念を支える証拠は、速く受け入れられる。脅かす証拠には、より厳しく、より長く疑いが向けられる。Peter DittoとDavid Lopezによるある実験では、好ましくない医学的検査結果を評価する参加者は、好ましい結果を受け取った参加者よりも、受け入れる前に多くの証拠を求めた。データは変わっていない。信じようとする姿勢が変わった。この非対称さは、自動的であって、意図的ではない。

調査のプロセスをゆがめるのに、特定の結果を望んでいる必要はない。調べているものを大切に思っているだけでいい。

偏った調査は、どう見えるか

不正には見えない。一つずつ行われる、もっともな選択に見える。

「この製品分野に関心がある」ユーザーを募集する。つまり、自分たちのようなプロダクトに、すでに興味を持つ人だ。既存の解決策の困りごとを聞く質問を書く。自分たちのプロダクトは、その困りごとを解決するからだ。市場全体ではなく、想定した顧客を代表する参加者と、ユーザビリティテストをする。振り返りでは、方向性を裏づける発言を三つ記録し、矛盾する二つは「例外」に分類する。どの判断も、専門的に聞こえる。どれも中立ではない。

Dan LovalloとDaniel Kahneman による、プロジェクト計画における経営者の楽観を扱ったHBRの分析は、組織内でも同じパターンを示している。リーダーは調査を依頼するが、問いの枠組みは「実行すべきか」ではなく、「どう実行するか」だ。調査は、つくるに値するかの確認ではなく、実現を支えるものになる。

Google+が、その例だ

Googleは、社内調査をもとに、2011年6月、Google+ を公開した。ユーザーは、オンラインでのコンテンツ共有を、もっと自分で管理したがっていた。その部分は本当だった。だがGoogle+は、そのニーズに対し、Circlesを中心にした新しいソーシャルネットワークで応え、Facebookと直接競った。調査が裏づけたのは、問題だった。新しいGoogleのソーシャルネットワークを、使い始めるほど人々が強く求めていることを、証明したわけではない。

結果としてできたのは、紙の上では本当の発見に対応しながら、肝心の行動を読み違えたプロダクトだった。人々が求めていたのは、よりよいプライバシー設定だけではない。Facebookを離れ、二つ目の人間関係のネットワークをゼロから築き、新しい仕組みを覚える理由も必要だった。ComScoreの推計では、2012年1月、Google+ユーザーの平均利用時間は月約3.3分だった。Facebookのユーザーは、平均7時間を超えていた。Google+の一般消費者向けサービスは、2019年4月に終了した。

調査を信じる前に、これを問う

簡単な確認方法がある。調査を始める前に、どんな結果ならプロジェクトを中止するか、方向を変えるかを書いておく。具体的に。「重大なユーザビリティの問題」では、言い逃れできるほど曖昧だ。もっと具体的にする。「助けなしで主要なタスクを完了できるユーザーが60％未満なら、流れを考え直す」。あるいは、「ユーザーがこの問題を、自分の生活で重要なものと捉えていなければ、やめる」。

その一文を書けないなら、調査はおそらく、決定を試すためではなく、記録して裏づけるためにある。

これが重要なのは、何が自分の誤りを示すかを書き出すと、調査は本当は何のためかを、厳しく見つめざるをえないからだ。ほとんどのチームがこの手順を飛ばすのは、不誠実だからではない。誰も、その問いを声に出さないからだ。何が出たら進路を変えるのかを決めないまま、実行を前提に調査が設計される。そこで、言い訳がつくられる。

言い訳としての調査は、時間とお金を無駄にするだけではない。悪い判断を、修正から守る。疑問を持っていた人は、調査結果のスライドを見て黙る。確信のなかった関係者は、データの前で押し切られる。3週間前に本当の問題に気づいたデザイナーは、それを口にするきっかけを得られない。調査がすでに答えを出したからだ。その場が本当はただ正当化の材料を求めているときに、調査がそう使われるのを、私は見てきた。言い訳は案を守り、その案を修正できたかもしれない会話を狭める。

よい調査は、居心地が悪くなるものだ。まだ知らなかったことを見つけるはずのものだ。調査で一度も驚かないなら、別の形でプロジェクトに奉仕している。調査は、ときには計画を揺さぶるべきだ。それも仕事の一部だ。