最低なユーザーリサーチ：リモートのリスクを減らすためのアプローチ
目次
はじめに
この投稿は、ユーザーリサーチを批判することを目的に書いた記事ではないことをご理解ください。自分自身の経験をもとに、ユーザーリサーチの可能性を広げるためのアプローチをご紹介し、リモートでユーザーリサーチを行っている、またはこれから行う人にとってお役に立てればと思っています。
自分は今現在（2020年4月）、フルリモートで仕事をしています。プロダクトマネージャーとして不慣れなところが多く、何が正解かわからないまま進めている状態ではありますが、完璧な正解を求めるのではなく、今のプロダクト開発に価値を届けられるかどうかで判断すべきだと最近は考えるようになりました。
イントロ：ユーザーリサーチとは？
さて、プロジェクトをフルリモートで進めていくにあって頭を悩ませている内のひとつが、ユーザーリサーチを実施するための「環境の構築」です。簡単なイントロとして、ユーザーリサーチには様々な目的があります：
- ユーザーと課題発見のため
- 価値探究と価値評価のため
- 使い勝手を検証するため
それぞれの目的に合わせて、ユーザーインタビューや定量調査、ユーザビリティテスト、A/B テストなどの手法を用いるのがユーザーリサーチです。
（１）では、想定しているユーザーはマーケットに存在するかどうか、そしてそのユーザーは想定していた課題を抱えているのかどうかを探るためにあります。
（２）は（１）の結果を踏まえて、課題を解決するためのアイディアを目に見える形に落とし込み、実際に触ってもらいながらソリューションの方向性を定めるために実施します。
あとは作るだけなのですが、同時にユーザビリティの検証をしながら「使いやすい」ソフトウェアに仕上げなくてはならないため、（３）も必要です。
例えば、新規でプロダクトを開発するシチュエーションにいると仮定しましょう。その場合、フルリモートでユーザーリサーチを実施するときのハードルになり得るのは、（２）と（３）です。なぜなら、実際のモノ（プロトタイプやソフトウェア）を被験者に触ってもらいながら、観察をする必要があるからです。
ペルソナと、解決すべき課題の特定がある程度できた状態で、プロトタイプをしながら（２）に進むことにしましょう。
リモートでユーザーリサーチを行うリスク
理想的なセットアップは、被験者の隣にインタビューワー（インタビューをする人）が座り、被験者がプロトタイプを触っている様子を観察しながら質問やガイドをし、仮説が正しかったのか or 間違っていたのかを検証するためのインサイトを抽出することです。
しかしそれは、「こちら」が用意した環境、例えば端末やネットワークを利用していることが前提にあります。被験者が在宅でリモートによるユーザーインタビューを行うときによく直面する問題は、被験者が持っている端末と自宅のネットワーク環境に左右される「被験者の環境に完全に依存してしまう問題」です。ちなみに、それぞれの物理的な距離はかなり遠い場合は、「では、近くのカフェでやりませんか？」なんてプランBはそもそも通用しません。では、どのようなことが起こるか。
「フルリモートではユーザーインタビューが成り立たない説」
水曜日のダウンタウンです。はい。被験者の方々に事前にご自身の環境について伺ったところ、驚きのニュースが多数寄せられました。
PC 端末が社用のため、申請していないツールが使えない
自宅のネットワークが遅く、テレビ電話の精度が悪い
なるほど。心の中では「まじかよ」状態です。このまま行けば、説が立証されてしまいます。なぜまずいかというと、プロトタイプを開くためにツールが必要なのであれば、そもそも見ることができないからです。ましてや、同業者でない限り自分たちが利用するツールを申請してインストールしているとは思えません。つまり、インタビューで利用するプロトタイプが見れない可能性が高い。
そしてもう一つ。テレビ電話の精度が悪いと、発言が途切れ途切れになってしまうことが多く、向こうもこちらもストレスになり、要約されてしまったりして、諦めてしまうことが考えられます。それでは、ユーザーインタビューの目的が達成されず、形だけのインタビューになってしまいます。
リスクよりも、チャンスを見る
それぞれのリスクを低減するために、以下のようなアプローチを取りました：
- プロトタイプを触ってもらえないリスク：figma のオブザベーションモードを使いながら Zoom のスクリーンシェア
- テレビ電話の精度が悪くインタビューできないリスク：昔ながらの電話をする
自分は最近まで知らなかったのですが、figma の同じプロトタイプ URL を参照している人であれば、画面をミラーリングし、カーソルの動きと画面遷移を把握することができます。その動きに合わせて、電話でインタビューをするという戦術です。これがとてもいい。（figma の observation mode）
むしろ被験者の隣に座って観察しながらインタビューするよりも、画面内の行動や心理状況を的確に把握することができます。余談ですが、この仕掛けについて知っている被験者は数少ない。そのため、「え、自分がやっていることがわかるんですか！？どうして？」と不思議がられることが多く、ちょっと自慢げになっています。
電話は言わずもがな。リモートの場合、これはマイナスではなくプラスに働くことが実は多いです。なぜなら、テレビ電話は正面を向いて話しているため、被験者は躊躇してしまって実は話にくかったりします。顔見知りだったら別ですが。電話の場合は普段から利用しているということもあり、発言も自然に出てきます。つい長電話してしまいましたね、という穏やかな雰囲気で終われるところがまたいい。
最低でなくても、最高は目指さなくてもいい
これを整えることができれば、ある程度（２）で辿り着きたいゴールに到達することができます。最低な環境でのユーザーリサーチですが、最低限のユーザーリサーチは実施することができることがわかりました。
（３）の使い勝手を検証するためのユーザーリサーチをどうするべきかはまだ考えてもいません。でも、シンプルにできることは何か、を念頭に置くことができれば、できるような気がしてきました。シンプルに考えるためには、とりあえずやってみること。上に書いたように、古典的なやり方でも成立はします。時間をかけて理想的な環境を整えるよりかは、プロダクト開発におけるメリットはより大きいかもしれません。
最後に、ユーザーリサーチを計画し、実施する際に意識していることは、良いユーザーリサーチは良い結果が出たから良いというものではないということです。良いユーザーリサーチは、ユーザーが求めていた価値（機能やデザイン）が提供できたかどうかで判断すべきだと考えます。そして、そのアウトプットを周囲に説明するためのコミュニケーションもシンプルであるべきです。デザインの伝え方、ですね。
