![見出し画像](https://assets.st-note.com/production/uploads/images/93289777/rectangle_large_type_2_d5a477ee96cfba29ae59c56762e4fe7c.jpeg?width=1200)
タクシーアプリ「GO」のユーザビリティテストを手作りしたら、超大変だったけどめっちゃ楽しかった話をします
これは Mobility Technologies Advent Calendar 2022の23日目の記事です。
本企画は弊社社員の個々の活動による記事であり、会社の公式見解とは異なる場合があります。
自己紹介
Mobility TechnologiesでタクシーアプリGOのユーザーリサーチを担当している井立です。私はプロダクトマネジメント本部アナリシスグループに所属し、マーケットリサーチ、UXリサーチを担当しています。
定量調査・定性調査を組み合わせながら、プロダクト改善や顧客戦略策定の支援をしています。
今年のトライ
今までは、リリースした機能に対してユーザーさんから評価を集めて、示唆を出していく事が主な業務でした。
一方で、リサーチャーとして更に一皮むけるために、サービス検討の初期段階でも貢献したい思いがありました。新しい機能やサービスを検討する際、プロダクト開発に関わるメンバーは「正しい問題の発見・正しい解決の実現」に向き合っていますが、彼らをより強力にサポートするためにいわゆる「ダブルダイヤモンド」の実践を、リサーチャーとして推進してみたいと思ったのです。
なので、この記事では
プロダクト開発の上流工程にも貢献したいと思っているリサーチャー
「正しい問題・正しい解決」に対し確信をもってプロダクト開発をしたいPdMやデザイナー
の方を想定し、ユーザビリティテストを手作りした話をしたいと思います。
※お断り※
ここでは便宜上、関わった案件名を「新機能A」とします。「新機能A」は「タクシーアプリ「GO」にあったら良いな」と思う機能に脳内変換してお読みください。またリサーチ業務の推進プロセスについては私が行ったことをそのまま記載しますが、それ以外はフェイクを入れてますのでご了承ください。
やったこと
introduction
BizDevのメンバーから以下のような相談を受けました。
「新機能A」の検討をしているんですが、一般の方から所感を聞きたいんですよね。できれば「新機能A」で提供したいサービスと近い体験をした事がある人が希望です。
「◯◯の経験を持つ人・使っている人」のような、特定のカテゴリユーザーにアプローチしたいという依頼、よくあります。
そのような場合、調査会社のアンケートパネルや自社のユーザーを対象に「条件に合致する人」をリクルーティングするのが常套手段かと思われます。
ただし、今回の場合「新機能A」の提供内容が当時一般化されていないものだったので、イメージ通りの人にたどり着ける確信が持てませんでした。
そこで実際のタクシー車両を用いて「新機能A」を疑似体験できる環境を用意し、GOのユーザーさんと乗車・ヒアリングする、いわゆる「ユーザビリティーテスト」を実施する事にしました。
![](https://assets.st-note.com/img/1670999248481-EORNc3Wvbz.png?width=1200)
STEP1 社内で仲間を集める
「調査をしたい」と言われたら「目的は?検証ポイントは?」と聞くのがリサーチのお作法ですが、調査で検証したいポイントはBizDev、PdM、デザイナー、エンジニア、それぞれの役割の数だけあるものです。
そこで、「新機能A」にアサイン予定のメンバーに「仕様を詰める前に、一緒にユーザビリティーテストやらない?」と声掛けすることにしました。
また、今回はリサーチャーがオーナーのボトムアッププロジェクトなので、メンバーにもその上司にも「面白そう、時間を割いてでも参加してもいいよ」と思ってもらう必要がありました。
ですので、声掛けタイミングでのポイントとしては、
・プロジェクト(ユーザビリティテスト)を通じて成し遂げたい事と、そのために協力してもらいたい事を明確にする
・プロジェクトのために必要な稼働時間を見積もっておく
ことに留意しました。このような情報提供ができると、彼らやその上司も工数管理がしやすくなりますし、プロジェクトへの参加障壁が下がる気がします。
そんなこんなでメンバーが徐々に増え、最終的に20名ほどが関わるプロジェクトとなりました。
STEP2 調査計画をたてる
調査計画とはすなわち「何を知りたいか」「どうやって調べるか」を整理してアクションプランに落とし込んでいくことです。
そこでSTEP1で集めたメンバーとディスカッションしながら、検証ポイントを整理して、調査計画に落とし込んでいきました。
![](https://assets.st-note.com/img/1669016291098-AOKZOpRXmo.png?width=1200)
この辺については多くの書籍で触れられている所なので詳細の説明は割愛しますが、今回はアンケート調査による事前調査とユーザビリティテスト(行動観察/事後のインタビュー)の二本立てでいくことにしました。
STEP3 ユーザビリティテストの詳細を決める
![](https://assets.st-note.com/img/1670824258161-QfnApehfbj.png?width=1200)
ユーザビリティテストでは上図のように
地点P1→P2におでかけするシチュエーションを作る
協力者と一緒に車両に乗り「新機能A」を体験する。体験と共にしながら、協力者の車内での振る舞いなども観察する。
降車後にインタビュー。「新機能A」の利用に際し「乗車前/乗車中/降車時」の各シーンでの反応や思考・感情をヒアリングする
行動観察とヒアリングを元に、ユーザーニーズやアプリが提供すべき便益などを整理する
こんな流れを目指し、計画を具体化させていきました。
STEP4 スケジュールに落とし込む
やりたい事とテスト日程を決めたら、スケジュールに落とし込みます。
車両の手配や保険の加入、協力者さんとのやりとりなど、事務局的な業務も多く占めておりまさに「段取り八分、仕事(調査)二分」の世界。事務方業務についてはBizDevのメンバーに手厚いサポートを受けながら進めました。(Kさん、その節は本当にお世話になりました)
![](https://assets.st-note.com/img/1670229815340-B27cgaXifU.png?width=1200)
もちろんトラブルが発生
このような一連のテスト計画がトントン拍子で物事が進むわけもなく、いくつかのトラブルに見舞われました。
1つ目のトラブルは、首都高の交通規制・渋滞。
![](https://assets.st-note.com/img/1670229889511-oQ7DPBlYPZ.png)
交通状況は移動に関連する重要な要素ですが、特に突発的な交通規制(交通事故など)は運行計画に大きく影響します。
テストの前日、翌日に通行予定のルートで交通規制が入ったのを知り「このパターンは想定していなかった。。。」と肝を冷やし、急遽対策を立てました。
2つ目は新型コロナウイルス第七波の襲来。
![](https://assets.st-note.com/img/1670230052472-JRaV8qAEPc.png)
プロジェクト組成の時点(2022年4月)では感染者数がある程度落ち着いていましたが、実査日が近づくにつれ第七波もピークに達しました。
そのため当日の感染症対策はどの程度必要か、やむを得ず中止や延期をする場合の基準作りなどについても、頭を悩ませることとなりました。
また、協力者さんと対面してテストを行うため、メンバー一同健康管理には相当の気を使いました。
3つ目は歯の矯正で滑舌が死んだこと。
![](https://assets.st-note.com/img/1670230797535-SqAuwxnkjk.png)
プライベートな事情を急にすみません。
最近歯の矯正を始めたのですが、ユーザビリティテストの直前でパラタルアーチという装置を装着したため、滑舌が急激に悪化しました。
テスト後のインタビューの際、驚くほど全く喋れず「なぜこのタイミングで矯正始めちゃったのかなぁ、私。。。」と後悔することに。
STEP5 いよいよ実査へ
このような数々の困難はありましたが、いざテスト当日。
プロジェクトメンバーが協力者さんと一緒に車に乗り込み、「新機能A」を検証します。
私は主に地点P2に該当するポイントで車両の到着を待ちつつ、ユーザビリティテストが無事に行われているかを遠隔で見守ります(車内の状況は同乗しているメンバーがSlackで実況)。協力者さんが到着したらお出迎えし、プロジェクトメンバー同席のもとインタビューを行いました。
このようにして「行動観察&インタビュー」を繰り返しました。
STEP5 デブリーフィング
ユーザビリティテストとインタビュー後、ユーザーニーズや課題を整理し、プロダクトとして提供すべき価値、実現すべき機能などを整理します。
今後始まる仕様検討の議論に向けて、各メンバーが自分のフィールドで活用できるよう、程よい抽象度にまとめることを心がけました。
![](https://assets.st-note.com/img/1670824387482-i76jblbXkT.png?width=1200)
全体を通しての気づき
今回の取り組みで得た気づきや面白かった箇所を、以下にまとめます。
(1)実際に車両を用意し、特定のシチュエーションを再現することでリアリティが生まれ、「新機能A」に期待されることの解像度を上げることができた。
行動観察をしたプロジェクトメンバーも「新機能A」について疑似体験をしたので、協力者の発言背景や心理、潜在ニーズを発掘しやすいと感じた。
![](https://assets.st-note.com/img/1670232230039-SlWkC9jVkw.png?width=1200)
(2)一次情報は超大事!リサーチャーが膨大な時間をかけて素敵なレポートを書くよりも、プロジェクトに関わるメンバーが実際に一次情報にふれる機会を多く設けるほうが、調査結果の説明力が高いと感じた。
(3)何よりも!様々な職能のメンバーと力を合わせて推進し「実体験をもってニーズを理解する」というプロセスは、発見や気付きが多くあった。準備の大変さが吹き飛ぶほど楽しかった。
まとめ
定量的なリサーチの場合「リサーチャーがメインとなってコツコツと調査・分析をし、その結果を関係者にアウトプットする」という進め方が多いかと思います。
しかし今回のような「正しい問題の発見・正しい解決の実現」に向き合うためのUXリサーチの場合、リサーチャーは
・関連するメンバーが、質の高い一次情報をインプットできる機会創出する
・得られた結果を各メンバーが各自の持ち場で活用できるよう、情報整理をする
・この一連の取組がスムーズに進むよう、全力で舵取りをする
このような振る舞いが良いのかな、と感じました。
最後に告知です。
株式会社Mobility Technologiesでは、採用を強化しています。
「移動で人を幸せに。」に挑戦してくれるメンバーを絶賛募集中です。
PdMやデザイナー、エンジニアなど、モノづくりに関わるメンバーをリサーチャーが強力にサポートしますので、ご興味のあるかたはぜひ採用ページをご覧ください。
明日は、fetaroさんの「TerraformではなくCDKを使っている話」です。