ユーザーリサーチ

ユーザーリサーチとは、実際のユーザーの行動・思考・感情・目標を理解するための体系的な調査活動である。優れたプロダクトは「作り手が正しいと思うもの」ではなく「ユーザーが実際に必要としているもの」から生まれるという原則に基づき、設計の前提をデータと観察によって検証する。リサーチを行わずに設計を進めることは、仮説を事実として扱うことと等しく、大きな手戻りリスクを抱える。

調査手法は定性調査と定量調査に大別される。定性調査（インタビュー・エスノグラフィ・コンテキスチュアルインクワイアリー）は「なぜそう行動するのか」という深い洞察を得るのに適しており、少数のユーザーから豊かな意味を引き出す。ユーザビリティテストは実際にプロダクトを操作してもらう観察形式の調査で、設計の問題を低コストで早期発見できる。一方、定量調査（アンケート・A/Bテスト・アナリティクス）は「何が・どれくらい」起きているかを統計的に把握するのに適しており、仮説の広域検証や優先度判断に役立つ。

ペルソナは特定のユーザータイプを象徴する架空の人物像であり、チーム内で「誰のために設計するか」を共通認識として保つためのツールである。ジョブ理論（Jobs To Be Done: JTBD）はユーザーがプロダクトを「雇う」理由を「〇〇をするためのジョブ」として定式化し、機能への注目ではなく目的への注目を促す。エンジニアがリサーチ活動に参加することで、技術的制約をリサーチ設計に反映できるとともに、ユーザーの言葉を直接聞く経験が設計判断の質を高める。

コードレビューで着目するポイント

機能の設計根拠（なぜこの仕様か）がリサーチの知見に基づいて説明可能か
ユーザーストーリーや要件がペルソナやJTBDと紐づいているか
A/Bテストの実装において計測指標とサンプルサイズの計算が事前に定義されているか
行動データ収集（アナリティクス）がユーザー同意・プライバシーポリシーに準拠しているか
ユーザビリティテストのフィードバックが Issue・バックログとして管理されているか
数値目標（コンバージョン率・タスク達成率）がリサーチ知見から設定されているか
仮説ドリブンの開発フローが整備されており、リサーチ結果が次のスプリントに反映されているか

典型的なアンチパターン

ペルソナの形骸化: 作成したペルソナが設計の実際の意思決定で参照されず、壁の飾りになるパターン。ペルソナが意思決定の基準として機能するためには、チーム全員が内面化し、「〇〇さんなら？」という問いかけが自然に行われる文化が必要。

確証バイアスによるリサーチ: 結果が既に決まっている仮説を確認するためだけにリサーチを行い、反証するデータを無視するパターン。リサーチは「仮説を否定できるか」という姿勢で設計すべき。

定量データの過信: アナリティクスのクリック数や直帰率は「何が起きているか」を示すが「なぜ起きているか」は示さない。定量データ単独での設計判断は因果関係を取り違えるリスクがある。

参考リソース

“Interviewing Users” Steve Portigal（Rosenfeld Media）
“When Coffee and Kale Compete” Alan Klement（Jobs To Be Done の実践書）
Nielsen Norman Group（https://www.nngroup.com/articles/）
Maze（ユーザーテストプラットフォーム: https://maze.co/）
“Continuous Discovery Habits” Teresa Torres（Product Talk）