はじめに
おはようございます、BIチームの齊藤です。
この記事はGunosy Advent Calendar 2020の22日目の記事です。昨日の記事は板谷さんによるFitbitのカスタムレポートを作成してLINEに通知する でした。
背景
プロダクト開発では、「このプロダクト / 施策によってユーザーが〇〇という課題が解決されるのではないか？」「この改修を入れればユーザー体験は良くなるのでは？」などの仮説を持って開発を行うことが一般的です。しかし、ある課題に対する施策やアプローチの候補というものは大量に存在します。これらの中から
「う〜〜〜んこれが最高！これしかありえない！！！はい実装即リリース！！！！！」
と施策を選び取ることは常人には不可能です。そこで、単一または複数の施策に対して効果検証を行い、施策の効果を判断します。
弊社ではA/Bテストによる検証を行うことが多いです。A/Bテストは無作為化比較実験であるためバイアスのない正確な検証が期待できますが、一方で
そもそもテストを開始できるようにする時点で開発コストがかかる
適切なサンプルサイズを満たすために時間がかかる
施策の候補が多数ある場合テストが複雑になる
などの課題があります。
これらの課題を避けるために、実装前のより早い段階、プロダクト開発の用語で言うとプロトタイプの段階での検証を行うという方法がとれます。プロトタイプでの検証方法として代表的なのがユーザーテストです。少数のサンプルでの調査となるため精度は期待できませんが、施策の方向性の手早い確認として機能します。
本記事では実際にユーザーインタビューおよびユーザーテストを行った際に注意した点を紹介していきます。
ユーザーインタビューとユーザーテスト
ユーザーテストとは、簡潔に説明すると「何人かのユーザーを対象に、プロトタイプを触ってもらってプロトタイプの良し悪しを判定する」作業になります。ユーザーを対象にヒアリングをする、という内容からユーザーインタビューという呼称で呼ばれることもあります（少なくとも社内ではありました）が、個人的にはテストとインタビューは意識的に区別した方が良いと感じました。この2つはそれぞれ
ユーザーインタビュー
- 仮説の段階で対象としたユーザーの現在の状態をヒアリングする
ユーザーテスト
- ある程度形にしたプロトタイプを用いて、事前に設計したテストをユーザーに行ってもらい評価する
という別々の目的があります。
ユーザーインタビュー
施策やプロダクトの前提となる仮説は「〇〇な人々は××という課題を持っていて、△△によって解決できる」といった形式になることが多いですが、インタビューでは前半の対象とするユーザーの属性についての調査を行います。
インタビューおよびテストでは仮説段階で対象とする属性を持つユーザーを集めます。例えば若年層向けの婚活サイトを作る場合は20~30代の未婚の人々を集め、トレーディングカードに特化したECサイトを作る場合は現在カードゲームをプレイしているユーザーを集めます。これらのユーザーについて、
普段の行動などは事前に考えていた通りか？
仮説通りの課題を持っているのか？
現在その問題をどう解決しているか or 放置しているのか？
など、現時点でどのような行動をしているかのヒアリングを行います。この段階でそもそも仮説の課題なんて感じていない、現行の他社製品で十分解決できており乗り換える見込みが低い、といった結果が得られた場合仮説を練り直すことができます。開発コストが無駄にならないのでこれはこれで前向きに捉えられますね。
注意点として、あくまで「現時点でどういう行動を取っているか」を聞くべきであり、「ユーザーが何がしたいか」を聞くべきではありません。
ユーザーテスト
ユーザーテストでは、プロトタイプをユーザーに操作してもらうことでプロトタイプの評価を行います。例えばECサイトであればトップページから商品を選んで購入確定画面まで進んでもらう、乗り換えアプリであれば最寄りから目的地までのルートを検索してもらう、といった製品の主目的となるようなタスクを設定します。タスクを通じて、どのパターンのデザインであれば購入したい商品を見つけられるか、あるいはどのパターンだと見つけられないか、などの課題点を発見します。
タスクの設計で注意すべき点は多々ありますが、今回は特に「前提条件や内容についてユーザー側に裁量を持たせない（=実行する内容は極力全ユーザーで同じにする）」という点を意識しました。例えば「あなたが最近気になっている製品を、普段他のECサイトを使っている時と同じような感じで探して購入を検討してください」というタスクを設定した場合、人によって思い浮かべる製品やサイトが異なるためユーザー間でタスクにズレが生じることになります。ユーザー間で前提条件を統一するために、仮の状況（コンテキスト）を追加してタスクにシナリオを設定します。ECサイトの例だと「あなたは犬を飼っていて、安いドッグフードを探しています。このサイトを使ってドッグフードを選んで購入確定するところまで進めてください。」という感じです。
また、タスクの実施中にも注意すべき点がいくつかあります。一つはタスクの実行中にはユーザーに思ったことを口に出しながら進めてもらうことです（思考発話法）。 これによりユーザーの認知プロセスを把握することができ、タスクの失敗の原因や悪印象を感じた理由などを分析することができます。
もう一つ、インタビュアーがタスク中に心がけるべき点として「黙っていること」があります。えっ黙ってていいんすか？と思われるかもしれませんが、タスク中はあくまでユーザーの行動を誘導することなく、タスクの実行を見守ることに徹しなければなりません。どうしても沈黙に耐えきれない場合やユーザーに質問をされた場合には、ユーザーがしていることを口に出す（下の方見てますね〜、端っこのリスト見てますね〜など）、質問をオウム返しにする、という方法があります。
テスト結果を分析する際にも、観察していて感じたことではなく事実としてのユーザー行動を書き出す、あくまでユーザーの視点から問題を記述するなどのポイントがあります。現在進行形で勉強中です*1*2
おわりに
ユーザーテストは専門の方々に外注するという選択肢もありますが、当然専門的な知識が求められる仕事なのでそれなりのお値段がします。社内でノウハウを貯めて自社で行えるようになりたいですね。あわよくばテストの実施をお願いされてお金が貰えるようになりたいです。
明日は石田さんによるスプリント振り返りについての記事です！
*1:樽本 徹也(2012). アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング― オーム社
*2:Marty Cagan(2019). INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 日本能率協会マネジメントセンター
