【翻訳】検証なんかやめてユーザーと共創しよう(Teresa Torres, Producttalk, 2018)

www.producttalk.org

あるところに二人の勤勉な労働者、サリーとパムがいました。サリーはプロダクトマネージャー、パムはユーザーエクスペリエンスデザイナーで、彼らは新しいモバイルアプリに取り組んでいます。

そして、顧客インタビューを行い、MVPを定義し、現在は初期設計に取り組んでいます。

MVPには近い将来のビジョンのほんの一部しか含まれませんが、パムはそのビジョンのデザインに2週間を費やしたいと考えています。また、MVPを作り始める前に、短期的なデザインについてフィードバックを得たいと考えています。

サリーは、できるだけ早くMVPを完成させたいと考えており、パムに、まずそのデザインに集中してほしいと考えています。

こんな時、どうすればいいのでしょうか?

パムが全体的なユーザーエクスペリエンスについて心配するのは正しいことです。私たちは皆、機能を寄せ集めたようなプロダクトにイライラした経験がありますよね。

しかし、サリーもまた正しいのです。彼らは、MVPをできるだけ早く世に送り出すことに集中すべきです。特に、作業の大部分がMVPに影響を与えない場合は、デザインに2週間もかかるのは長すぎると感じます。

重要な仮定のせいで、時間を節約しているつもりが、実は無駄にしている

このような対立を解決するためには、ここで重要な仮定を明らかにする必要があります。

パムは、短期的なビジョンはほぼ正しいと仮定しています。彼女は、MVPの設計が短期ビジョンの設計と首尾一貫していることを確認したいのです。彼女は、AがB、C、Dとどのように適合するかを知らずに、Aを設計したいわけではありません。

このアプローチは、A、B、C、Dが構築すべき正確なものであると確信している場合に有効です。B、C、Dを考慮せずにAだけを設計してしまうと、Bに到達したときにAを設計し直す必要があり、Cに到達したときにAとBを設計し直す必要が出てきますから、非常に非効率です。

しかし、もし私たちの近い将来のビジョンとMVPがほとんど間違っていると仮定すると、パムのアプローチは私たちの時間を節約することはできません。それどころか、私たちは2週間のデザイン作業をすることになり、おそらく無駄になってしまうでしょう。

意思決定の研究では、間違っていることを覚悟しなければならないとされていますが、実際にはなかなかそうもいきません。エゴが邪魔をするのです。自分が正しいように感じ、まるでそうであるかのように進めてしまうのです。

しかし、チームがプロダクトを計測し、プロダクト変更の影響を正直に追跡すると、自分たちが正しいと思っていても、間違っていることの方が多いことがわかります。

Aを間違うか、少なくともAの一部を間違えると仮定し、Bに到達したらBを正しくするために何度か反復する必要がある、などと仮定すれば、短期のビジョンを設計するために2週間を先行させることはもはや意味をなさないのです。

もし、「自分たちが間違っている可能性がある」と仮定すれば、「MVPをできるだけ早く出す」というサリーの主張のほうがより理にかなっているのです。

非効率なイテレーションの価値とは

最初のビジョンが正しいと思い込まないこと:イテレーションは、前のイテレーションを元にするためだけに使用する

最初のビジョンが正しいと決めつけないでください。これまでの繰り返しの上に、さらに繰り返しを重ねましょう。 しかし、同時にパムの心配を無視することもできません。私たちは、ユーザーエクスペリエンス全体に気を配る必要があります。そのためにもイテレーションを行いましょう。

もし私たちの近い将来のビジョンにA、B、C、Dがあるとしたら、おそらくAをMVPに選んだのは、私たちが提供しようとする価値の中心にあるからでしょう。もしAが期待通りに動かなかったら、B、C、Dが危険にさらされることになります。

つまり、B、C、Dは無視して、Aを正しく作ることに専念すればいいのです。サリーは、MVPをできるだけ早く出すことに集中するのが正しいのです。

しかし、Aを完成させた後、Bに取り掛かったとして、この時、Bをできるだけ早くリリースすることが目標ではありません。これが、玉石混交のデザインにつながるのです。

このとき、私たちが目指すのは、AとBをうまく連動させることです。つまり、Aの設計を変更しなければならないかもしれないのです。

これを非効率に感じるかもしれませんが、非効率になるのは、当初の目論見がすべてをうまくいった場合だけです。そんなことはめったにないですよね。

どれだけ細部であったとしても間違いがあった場合には、この方法の方が速いのです。

信じられませんか?それでは例を見てみましょう。

AのMVPをリリースした後、彼らは学んだことに基づいてイテレーションを進め、AはもはやBを必要とせず、代わりにEを必要とし、さらにCの動作に必要な方法を変更するものに変容したとします。

ここでパムはさらに2週間かけて、Bのデザインを削り、Eを追加し、学んだことを反映させるためにCのイテレーションに入ります。

今度はAとEを発表した後、Eが全く正しくなく、さらにCに影響を与えることを知りました。パムは1週間かけて、A、E、Cのイテレーションに入ります。

この状態がどのように続くか想像がつくでしょう。パムは、新しいことがわかるたびに、すべてをデザインし直さなければならないのです。

もし、パムがAだけを設計した場合、Bを追加したときにAを設計し直さなければならないリスクがあります。Aを機能させるための選択肢を検討しながら、ユーザーがAに何を求めているのかについて多くのことを学んできたため、Bと連動させるためにAを修正する際に、豊富な知識を活用することができるのです。

前のシナリオでは、パムはA、B、C、Dを一緒に再設計していますが、A、B、C、Dについてまだ何も学んでいないので、彼女のデザインはせいぜい推測に過ぎません。

パムは、A、B、C、Dをうまく組み合わせるために、まだ何度も繰り返さなければなりませんが、各イテレーションは前の反省を踏まえて行われます。その結果、デザインサイクルが短縮され、全体のデザインも速くなります。

これは直感に反しています。その理由を見てみましょう。

ほとんどのチームが検証マインドセットを採用している

パムのように、私たちは自分たちのアイデアを検証するために顧客とのやりとりを利用する傾向があります。私たちは、ソリューションを設計するのは自分たちの仕事であり、顧客はそのソリューションが自分たちのために機能するかどうかを確認するのが仕事だと考えています。

そのため、設計が完了するまで、顧客からのフィードバックを待つ傾向があります。私たちは、自分たちの設計が正しいかどうか、顧客に検証してもらうことを期待しているのです。

この検証の考え方には、いくつかの問題があります。

まず、フィードバックを得るのが遅すぎることです。多くのプロダクトチームは、エンジニアの納品サイクルの直前に設計を行います。彼らが検証しているものは、来週のスプリントで使用する必要があります。もしそれが顧客にとってうまくいかなかった場合、チームはそれを修正する時間がありません。仮にうまくいったとしても、顧客は常に改善案を持っているもので、それを統合する時間はほとんどありません。

顧客との共創ではなく、自分たちだけで作ったアイデアを検証する場合、顧客からのフィードバックを得るのが遅すぎて、それをプロダクトに統合することができないのです。

次に、コミットメントのエスカレーションと確証バイアスのために、時間があったとしても、顧客のフィードバックに対してアクションを行う可能性が非常に低くなっています。

復習になりますが、コミットメントのエスカレーションとは、あるアイデアに時間とエネルギーを費やせば費やすほど、そのアイデアにコミットするようになる認知バイアスのことです。例えば、A、B、C、Dをデザインするためにすべての作業を行えば、そのデザインにコミットするようになります。顧客の声を聞き、それを取り入れることに全力を注いでいる人でも、これには苦労することでしょう。

確証バイアス(確証を得られる証拠の方が、確証を得られない証拠よりも2倍聞きやすいというバイアス)のおかげで、私たちのアイデアが意図したとおりに機能していないという顧客からのフィードバックのほとんどを見逃すことになるのです。

そのため、顧客にインタビューしたり、ユーザビリティテストを行ったりしても、いざリリースしてみると、意図したようなインパクトが得られなかったということがよくあるのです。

これは、インタビューやユーザビリティテストを省略すべきということではなく、自分のバイアスを回避するために、これらの活動をよりうまく行う必要があるということです。

また、これは検証マインドセットを捨てて、共創マインドセットを採用する必要があることも意味しています。

なぜ顧客との共創が正解なのか

検証マインドセットは、テクノロジーに関しては自分たちが一番よく知っているという信念から生まれたものです。そして、それは正しいのです。しかし、顧客が自分たちのニーズについて一番よく知っているのは、顧客自身なのです。

技術的な専門知識に関しては、私たちが一番よく知っていますが、自分自身のニーズに関しては、顧客が一番よく知っているのです。

さて、皆さんの中には、スティーブ・ジョブズが「顧客は自分の欲しいものを知らない」「最初のiPhoneを求めるなんて誰も知らない」と主張したことを思い浮かべる人もいるかもしれません。そこで、この違いをはっきりさせておきましょう。

顧客はテクノロジーで何ができるかを知りません。彼らは、iPhoneが可能であることを知らなかったから、iPhoneを求めることはなかったでしょう。しかし、彼らは、留守電を確認するのが嫌なこと、番号を使ったメールがとてつもなく面倒なこと、画面が小さくてかけたい相手を探すのが大変なことを知っていました。

Appleは、自分たちの技術を駆使して、これらの問題を解決し、さらに多くの問題を解決して、最初のiPhoneを開発しました。しかし、それが重要な問題であることを知らなければ、実現することはできなかったでしょう。

成功するプロダクトとは、顧客の真のニーズに対応した技術的な専門知識の結果です。顧客との共創により、顧客が求めるものを確実に作り上げることができるのです。

では、共創とはどのようなものなのでしょうか?

ソリューションの共創の力を解き放つ

私たちは「プロダクト的な意思決定」をしているため、毎週顧客とエンゲージする必要があります。多くのチームがこのことに頭を悩ませています。彼らは、毎週顧客と関わるには、設計を迅速に行うことができないと主張します。しかし、これは検証マインドセットが忍び込んでいるのです。

毎週、生産準備の整ったデザインを仕上げることはできませんが、先週の仕事をイテレーションすることはできますし、そうすべきです。検証のマインドセットを捨てて、共創のマインドセットを採用すれば、まだデザインをイテレーションしている最中の厄介なタイミングに、顧客からフィードバックを得ることができるのです。

最終的に満足のいくデザインができたときに、「このデザインで大丈夫ですか」と顧客に尋ねるのではなく、3つか4つのデザイン案を見せればいいのです。そして、「この選択肢はどうでしょうか?」と問いかけるのです。

この微妙な変化により、先に挙げた2つの問題が解決され、さらに2つの利点があります。

まず、デザインプロセスの早い段階で、顧客からフィードバックを得られるようになりました。スケッチやワイヤーフレームを反復することは、プロダクト化されたデザインを反復するよりもはるかに簡単です。そのため、顧客からフィードバックをいただいた場合、それを統合する可能性が非常に高くなります。

また、1つのアイデアにかける時間が短いため、コミットメントのエスカレーションや確証バイアスが起こりにくくなります。また、「アリかナシか」という判断ではなく、「比較対照」という判断で検討しているので、確証バイアスの防止にもつながります。

2つの問題の解決に加えて、2つの付加的な利点も得られます。

まず1つ目のメリットは、洗練されていないデザイン、特に複数の選択肢を共有することで、顧客が率直なフィードバックをくれる可能性が高くなることです。私たちがまだデザインしている最中であることがわかり、顧客も私たちの気持ちを害する心配が少なくなるからです。

そして、もうひとつのメリットは、私たちが考えもしなかったような新しい選択肢へとジャンプできる可能性が高くなることです。さて、デザイナーによっては、これが 「委員会方式」とでも言うべきデザインにつながるのではと危惧する人もいるかもしれません。顧客の選択肢を使わなければならないわけではありません。しかし、顧客が提案する選択肢から、顧客のニーズについて多くを学ぶことができるのです。