約7分で読めます
UserFirst
「このまま進めていいのかな」を、チームで検討できる問いに変えるー『ユーザーに寄りそわNight!』Vol.03レポート
こんにちは。KINTOテクノロジーズ（KTC）で、ユーザーファースト推進活動の運営に関わっているるかーびーです。
KTCでは「ユーザーファースト」を会社の重点方針のひとつに掲げており、社内勉強会「ユーザーに寄りそわNight!」の開催もその取り組みのひとつです。Vol.02のレポートに続き、今回はVol.03の内容をお伝えします。
テーマは「クイックなリサーチ」。サービスに感じた「このまま進めていいのかな」という違和感を、すぐに改善案にせず、手元にある情報から一度確かめてみる進め方です。
サービスの企画や改善に関わっていると、「この動線で、必要な情報までたどり着けるのだろうか」「説明の途中で迷う人がいるのではないか」と感じる場面があります。
こうした違和感は改善を考えるきっかけになりますが、その時点では本当に問題が起きているのか、ユーザーにどんな影響があるのかまではわかりません。
生煮えのままチームに改善案をあげたとして、関係者の立場によって持っている情報や前提が異なるため、提案に至った背景から理解を取り付ける必要があります。一定の共感は得られるとしても、関係者が多いほど時間がかかるものです。
Vol.03で取り上げたのは、この違和感と改善案のあいだに、「確かめる」を一段はさむ実践でした。
第3回の寄りそわNightでは、デジタル戦略部の上田貴弘さんに登壇していただきました。オンライン相談やVoC（Voice of Customer：お客様の声）の分析、ユーザビリティテストなどを通じて、ユーザーの声や行動を捉える業務に取り組んでいます。当日は、オンライン相談やVoCから見えてきた仮説を、新入社員とのユーザビリティテストで確かめた事例が紹介されました。
新入社員に実際のサービスを使ってもらう
今回の事例の出発点は、オンライン相談やVoCを見る中で生まれた「サービスの利用途中に、いくつかのつまずきが起きているのではないか」という仮説でした。
ただ、相談や問い合わせからわかるのは、ユーザーが言葉にした困りごとが中心です。実際の画面上のどこで手が止まり、何が理解しにくかったのかまではつかめません。
そこで登壇者の上田さんが紹介したのが、新入社員に協力してもらうユーザビリティテストでした。
入社したばかりのメンバーは、業務やサービスに関する前提知識がまだ少なく、社内では当たり前になっている言葉や流れにも、初めてサービスに触れる人に近い反応を示します。社内メンバーなので確認したい内容を共有しやすく、短い準備で実施できる。実践のしやすさも、この方法が選ばれた理由の一つでした。
もちろん、新入社員がそのまま実際のお客様を代表するわけではありません。
今回は、サービスのどこにつまずきがありそうかをまず確かめるための検証です。
テストでは、実際に画面を操作してもらいながら、利用中の発話や迷い、説明を読んだあとの反応を観察していきます。説明を何度も読み返す、次に進まずに考え込む、前の画面に戻って情報を探す。
操作の様子を追うことで、どの場面で立ち止まったのか、どの説明が伝わりにくかったのか、判断するために何の情報が足りなかったのかが具体的になっていきます。
設計上は、説明を読めばそのまま次の画面へ進める想定でも、実際には同じ箇所を何度も読み返している。反対に、作る側が課題だと考えていた箇所では、ほとんど迷いが起きていない。登壇を通して繰り返し語られていたのは、この「想定」と「実際に起きていること」を分けて見ることの大切さでした。
紹介された例のひとつが、本人確認書類の画像アップロードです。最新のスマートフォンで撮ったきれいな写真が容量の上限を超え、エラーになる。設計した時点では問題のなかった仕様でも、ユーザーの利用環境が変わることで、思わぬところにつまずきが生まれます。実際の利用を見て初めてわかるつまずきは、こうした単純なところにも潜んでいます。
エラーに遭遇した人は、そのあと撮り直して先へ進めているのか。それとも、そこで利用をやめてしまっているのか。実際の行動が見えると、次に確かめたいことが具体的になります。こうして、ひとりの違和感が、チームで確かめられる問いに変わっていきます。
オンライン相談やVoCから感じていた違和感に実際の行動が重なったことで、「使いにくそう」という感覚だけでは見えていなかった部分が確認できた。そんな事例でした。
提案の前に、同じ景色を見る
確かめた結果を、チームでどう使うのか。この話題で登壇のキーワードになっていたのが「同じ景色を見る」という言葉です。
ここでいう「同じ景色」とは、全員が同じ意見になることではありません。改善案を挟んで向かい合うのではなく、ユーザーの行動や声を真ん中に置いて、隣に並んで見る。ユーザーに何が起きていたのか。どの情報から、課題かもしれないと考えたのか。何が変われば、困りごとが解消されたと言えそうなのか。立場や役割が違っていても、まずユーザーを共通の起点にして考える、という意味です。
改善案だけが先に出てくると、受け取る側は、何を解決しようとしているのか、なぜ今扱う必要があるのかを、まず確認しなければなりません。ユーザーの行動や発言、問い合わせ、ログが先に共有されていれば、改善案への賛否を決める前に、「何が起きていそうか」から話し始められます。
直したい箇所のリストは、開発の現場ではいつも長くなりがちです。
「一部の環境で画像のアップロードがエラーになることがある」という一行の報告と、目の前でユーザーが何度も写真を撮り直し、手を止めてしまう様子とでは、同じ事実でも受け取る重みが違います。
実際の行動を関係者が一緒に見ることで、ユーザーへの影響を起点に、何から手をつけるかを話せるようになります。
最初に置いた仮説が、正しいとは限りません。確かめてみると、想定とは別の場所で迷っていたり、課題だと思っていたことが実際にはそれほど影響していなかったりもします。
それでも、見ていた事実と仮説が共有されていれば、想定と違う結果が出たときに、次に何を確認するかを考えやすくなります。
事実は、提案を通すためだけの材料ではなく、チームで次の判断を下すための材料にもなります。
今回の事例を貫いていたのは、この考え方だったように思います。
参加者から寄せられた質問
イベント後のアンケートや質問フォームには、今回の内容を実践する際に迷いそうな点について、具体的な質問が寄せられました。たとえば、次のような内容です。
-
「売上を伸ばす」のような大きな目的から、どの粒度まで課題を小さくして調査を設計するのか
-
アンケートで集めた声を、設問の意図や対象者を踏まえてどう読み取るのか
-
集めた事実を、聞き手が判断できる量にどう整理するのか
また、「ユーザー中心の視点でサービス開発を進めるには、何から始めるとよいのか」「プロジェクト名など、普段使う言葉をユーザー起点に変えることにも意味があるのか」といった質問もありました。
内容を理解して終わるのではなく、自分の業務で試すとしたらどこで迷うのか。その段階まで踏み込んだ質問が多かったことが印象に残っています。ここで挙がった論点は、次回以降のテーマを考える際の材料にしていく予定です。
まず、手元にあるものを見てみる
ユーザーファーストの実践というと、大がかりな調査や専門的なリサーチから始めるもののように感じるかもしれません。
今回の事例の起点は、オンライン相談やVoCなど、すでに手元にあった情報でした。そこから気になったことを、新入社員とのユーザビリティテストで確かめる。日々の業務で生まれる「このままでいいのかな」という違和感も、事実とセットにすると、チームで検討できる問いになります。
私自身、気になることがあると、つい解決策まで一気に考えてしまいます。今回の話を聞きながら、答えを出す前に、まず何が起きているのかを一度見てみることを忘れないようにしたいと思いました。
次に何かが気になったとき、まずは手元のログや問い合わせをひとつ確認してみる。今回のレポートが、そんな一歩につながればうれしいです。
