ux-research

UX リサーチ

プロダクトデザインに活用できる知見を生み出すために、ユーザーリサーチを計画、実施、分析します。このスキルでは、適切な問いの定義から、意思決定につながる調査結果の提示まで、リサーチプロセスのあらゆる段階で役立つフレームワーク、手法、実践的なガイダンスを提供します。

このスキルを使用する場面

次のような場合に、このスキルを使用します。

• リサーチを計画する場合（手法の選択、範囲の定義、計画書の作成）
• インタビューの台本やディスカッションガイドを作成する場合
• タスクと成功指標を盛り込んだユーザビリティテスト計画を作成する場合
• 参加者を募集し、スクリーナー調査を作成する場合
• 定性データを分析する場合（親和図、テーマ分析）
• リサーチをペルソナ、ジャーニーマップ、機会マップにまとめる場合
• 継続的なディスカバリーの実践（週次インタビュー、OST）を始める場合
• ステークホルダーに調査結果と推奨事項を提示する場合

基本原則

リサーチはリスクを減らすための手段であり、成果物ではありません。常に意思決定に役立てることが目的であり、文書を作ることではありません。リサーチは、人々の好みを尋ねることでも、政治的な道具でも、科学でもありません。適切な問題の解決に役立つ、実践的な探究です。

リサーチの種類

どのような意思決定が関わっているかに応じて、リサーチの種類を選びます。

生成的／探索的

時期： 何を作るかがまだ決まっていない段階です。問題を定義する必要があります。 手法： インタビュー、現場観察、コンテクスチュアル・インクワイアリー、日記調査、文献レビュー 成果： 問題の定義、機会領域、ペルソナ、メンタルモデル

記述的

時期： デザイン上の課題があり、その背景を十分に理解する必要がある段階です。 手法： コンテクスチュアル・インクワイアリー、参与しない観察、ジャーニーマッピング、カードソーティング 成果： 現状マップ、ワークフロー図、メンタルモデル

評価的

時期： 解決策の候補があり、それらをテストする必要がある段階です。 手法： ユーザビリティテスト、ヒューリスティック評価、A/B テスト、クリックテスト、ツリーテスト 成果： 重要度順に分類した課題、タスク完了率、推奨事項

因果的

時期： 解決策が公開され、実際の利用パターンを把握する必要がある段階です。 手法： アナリティクスのレビュー、A/B テスト、ファネル分析、アンケート 成果： コンバージョンデータ、行動パターン、定量的な検証

リサーチのプロセス

1. 問題を定義する

明確な問題の記述から始めます。成果を示す動詞を使って記述します。

• 良い例：「ユーザーがオンボーディングを完了できない要因を特定する」
• 良い例：「新しいチェックアウトフローによって離脱が減るかを評価する」
• 悪い例：「ユーザー体験を理解する」（曖昧すぎます）
• 悪い例：「問題領域を探索する」（測定可能な成果がありません）

リサーチの問いを3～5個作成します。10個を超える場合は、範囲が広すぎます。

2. アプローチを選択する

必要なこと	使用する手法	所要時間
満たされていないニーズを発見する	生成的インタビュー	2-3週間
コンテキストとワークフローを理解する	コンテクスチュアル・インクワイアリー	1-2週間
デザインコンセプトをテストする	ユーザビリティテスト	3-5日
数値で検証する	アンケート＋アナリティクス	1-2週間
専門家による迅速なレビューを行う	ヒューリスティック評価	1-2日
機能に優先順位を付ける	カードソーティング、機能選択	1週間
ナビゲーションのメンタルモデルを理解する	ツリーテスト、カードソーティング	1週間
継続的なパターンを追跡する	継続的なディスカバリー（週次）	継続

手法の詳細な説明については、references/research-methods-catalog.md を参照してください。

3. 計画と準備

短いものであっても、調査には必ず書面で計画を作成します。templates/research-plan-template.md を使用してください。

計画に必須の項目：

• 問題の説明と調査の質問
• 方法論とその根拠
• 参加者の条件と募集方法
• 参加者数（以下の目安を参照）
• スケジュールとロジスティクス
• データの記録・保存方法
• チームの誰が参加するか

参加者数の目安：

• ユーザビリティテスト：各ラウンドで3～5人（5人で問題の約85％を発見できます）
• 探索的インタビュー：ペルソナの各セグメントで5～8人
• カードソーティング：統計的な傾向を把握するには15～20人
• アンケート：定量的に有意な結果を得るには100人以上
• 継続的なディスカバリー：最低でも週に1人

4. 参加者を募集する

募集は最も難しい作業です。前向きに取り組みましょう。質の高い募集が、調査の質を高めます。

適切な参加者：

• ターゲットユーザーと同じ目標や懸念を持っている
• 主要な特徴（年齢、役割、技術への精通度）を備えている
• 自分の考えを明確に説明できる
• 関連技術に、ターゲットユーザーと同程度に精通している

スクリーナー調査を作成する（templates/screener-template.md を参照）：

• 対象となる具体的な行動を定義する
• 必要なツールの知識とアクセスレベルを決める
• トピックに関する知識の要件を設定する
• 誰を探しているのかが明白にならないようにする（参加希望者に対策される可能性があります）

募集のヒント：

• ターゲットユーザーを完全に代表する参加者を募集することの重要性は、過大評価されています
• 完全な代表性よりも、早期かつ頻繁にテストすることが重要です
• 初回のラウンドでは、友人や近所の人に頼むことをためらわないでください
• 妥当な謝礼を用意します（1時間あたり50～100ドル）
• 招待文はシンプルにします
• 事前に製品について話さないでください

5. データを収集する

データ管理：

• 一貫した命名規則を使います：Study-ParticipantName-YYYY-MM-DD
• ファイルはすぐに共有ドライブへ移します
• 使い慣れたツールを使います。技術的な問題は調査セッションを台無しにします
• すぐに使えるよう、調査キットを常に準備しておきます

主な収集方法：

インタビュー — ユーザーの視点から世界を見るための最も効果的な方法です。手法の詳細は references/interviewing-guide.md を参照してください。

クイックチェックリスト：

• 目標、属性、アイスブレイク、重点的な質問を含むインタビューガイドを準備する
• 自由回答形式の質問をし、「それについて、もう少し詳しく教えてください」と掘り下げる
• 話すよりも聞くことを重視し、沈黙に慣れる
• 参加者が使う正確な言葉や語彙を記録する
• 録音を止めた後にも注意を払う。新たな気づきは、そのときに得られることがよくあります

ユーザビリティテスト — 代表的なユーザーが、デザインを使ってタスクに取り組む様子を観察します。手順の詳細は references/usability-testing-guide.md を参照してください。

クイックチェックリスト：

• シナリオとペルソナに基づいてタスクを作成する
• デザイナーは進行役を務めてはいけません
• 別の観察担当者を用意してメモを取る
• 早い段階から頻繁にテストする。昼食の直前には決して行わない
• 各ラウンドで3人をテストし、同じ日の昼食時に振り返りを行う

コンテクスチュアル・インクワイアリー — 参加者の実際の環境でインタビューと観察を行います。

クイックチェックリスト：

• 移動時間を見込んで計画する
• 日課を中断せずに、その場に慣れる
• 見学させてもらうのではなく、作業を実際に行ってもらう
• 環境、回避策、ツール、中断など、あらゆることを観察する
• 複数の視点を得るため、複数の調査担当者で行う

6. データを分析する

分析によって、パターンがインサイトへと変わります。参加することで恩恵を受ける人も含め、全員を巻き込みましょう。

定性的分析のプロセス：

1. すべてのメモと録音を注意深く確認します
2. 観察事項を抽出します：行動、感情、アクション、発言の引用
3. 各観察事項を付箋に書きます（情報源の参加者が分かるように記号を付けます）
4. ホワイトボード上でメモをテーマごとに分類します
5. パターンが現れるのを観察し、評価しながら配置を変えます
6. 各グループにインサイトを表す文で名前を付けます
7. インサイトから実行可能な提案を導き出します

分析セッションの構成：

• 調査の目標とプロセスを要約します（何を明らかにしたかったのでしょうか？）
• 参加者と状況を説明します
• データ収集の方法を説明します
• グループで引用や観察事項を抽出します
• テーマごとに分類します（例：「参加者は記憶を補うためにペンと紙に頼っている」）
• 調査結果を要約します：パターン → インサイト → デザインへの示唆
• 共有可能な形式で記録します

アフィニティダイアグラム、機会のマッピング、ペルソナの作成などの詳細な手法については、references/analysis-synthesis.mdを参照してください。

7. 結果を報告する

ペルソナの簡単なスケッチや、ホワイトボード上の付箋の写真は、読まれずに放置される長文の報告書よりもはるかに効果的です。

必ず含める項目：

• 調査の目標と質問
• 手法と参加者の概要
• 主な調査結果（パターンとインサイト）
• 重大度順に並べた提案
• 次のステップの提案

調査結果の重大度スケール：

重大度	定義	対応
Critical	ユーザーがタスクを完了できなくなる	リリース前に必ず修正
High	大きな困難が生じ、ユーザーが離脱する可能性がある	現在のサイクルで修正
Moderate	ある程度の困難が生じるが、ユーザーは回避策を使える	次のサイクルで対応を計画
Low	軽微な不便。見た目や好みに関するもの	バックログに追加

調査結果の発生頻度スケール：

頻度	定義
High	参加者の30％以上が問題を経験
Moderate	参加者の11〜29％が問題を経験
Low	参加者の10％以下が問題を経験

問題の優先度判定（3段階）：

• Tier 1： 重大度が高く、発生頻度も高い → 直ちに対応。製品の成功に対するリスクが高い
• Tier 2： 重大度が中程度で発生頻度が低い、または重大度が低く発生頻度が中程度
• Tier 3： 重大度が低く、発生頻度も低い → リスクが低いため、バックログに追加

報告書の構成には、templates/findings-report-template.mdを使用してください。

継続的なディスカバリー

継続的なディスカバリーを実践するチーム（推奨）にとって、調査は一つのフェーズではなく、毎週の習慣です。

継続的なディスカバリーのサイクル：

• 製品を開発するチームが、毎週顧客と接点を持ちます
• 望ましい成果の実現を目指して、小規模な調査活動を行います
• 日々の製品に関する意思決定に、継続的な顧客の意見を取り入れます

プロダクトトリオ（プロダクトマネージャー＋デザイナー＋エンジニア）は、次のことを行います：

• ストーリー形式のインタビューを毎週実施します（意見ではなく、実際の過去の行動について尋ねます）
• 成果 → 機会 → 解決策 → 仮説検証を対応付けた機会・解決策ツリーを維持します
• 機会ごとに15〜20個の解決策のアイデアを生み出します（量が質を高めます）
• 小規模で迅速な実験を通じて、毎週10〜20個の仮説を検証します
• テストを実施する前に成功基準を定めます

フレームワークの全容については、references/continuous-discovery.mdを参照してください。

よくある避けるべき間違い

• 誘導的な質問：「」：「これはより簡単だと思いませんか？」→「この体験をどのように説明しますか？」
• **確証バイアス：**仮説を本当に検証するのではなく、仮説を裏付ける証拠を探すこと
• **テストが遅すぎる：**調査結果を活用する時間がない、リリース直前にテストすること
• **行動を観察せず、意見を尋ねる：**人は自分の行動を正確に予測できません
• **記録しすぎて、行動が足りない：**誰も読まない50ページのレポートと、変化を促すホワイトボードの写真
• **スクリーナーを省略する：**代表的な参加者ではなく、都合のつく人を誰でも募集すること
• **進行役がデザイナーである：**自分が作ったものがうまくいかない様子を、客観的に観察することはできません
• **分析中に解決しようとする：**パターンが明らかになる前に、解決策へ飛びつきたい衝動を抑えます
• ユーザーの要望に基づいて機能を追加する：「」：「Xができたらいいのに」――さらに掘り下げて聞きます。多くの場合、すでにXのための情報源があります

クイックリファレンス

問題文の形式： [動詞：特定する／評価する／判断する] + [何を] + [誰のために] + [どのような状況で] **インタビュー質問の形式：**自由回答形式で、行動に焦点を当て、過去形にします（「最後に〜したときのことを教えてください……」） **ユーザビリティタスクの形式：**シナリオに基づき、目標を中心にします（「[目標]を達成したいとします。どのようにするか見せてください。」） **スクリーナーの形式：**基準を明かさずに対象者を絞り込む、行動に関する質問 **分析の成果物：**パターン → インサイト → 推奨事項 → 重大度

リソース

このスキルには以下が含まれます。

• references/research-methods-catalog.md：種類別にまとめた、20種類以上の調査手法の詳細ガイド
• references/interviewing-guide.md：準備から振り返りまで、インタビュー手法を網羅したガイド
• references/usability-testing-guide.md：評価基準、トリアージ、SUS（採点式、グレード／パーセンタイルの解釈、下位尺度を含む全10問の尺度）、および代替質問票（UMUX-Lite、SEQ、NASA-TLX）を含む、テストプロセス全体のガイド
• references/analysis-synthesis.md：親和図法、テーマ分析、ペルソナ作成、機会のマッピング
• references/continuous-discovery.md：週次の進め方、Opportunity Solution Tree、仮説の検証
• references/workshop-methods.md：チームのファシリテーション手法――問題の枠組み設定（HMW、Problem Tree、Abstraction Laddering、Rose/Thorn/Bud）、アイデア創出（Thumbnail Sketching、Creative Matrix、Round Robin、Alternative Worlds）、優先順位付け（Importance/Difficulty Matrix、Bull's-Eye、Dot Voting、What's on Your Radar）、モデリング（Storyboarding、Concept Poster、Cover Story Mock-Up）。半日のワークショップ用テンプレートと、ファシリテーションのアンチパターンも含みます。
• templates/research-plan-template.md：記入式の調査計画
• templates/interview-guide-template.md：インタビュー台本のテンプレート
• templates/usability-test-plan-template.md：タスクと指標を含むテスト計画
• templates/screener-template.md：参加者スクリーナー調査票
• templates/findings-report-template.md：調査結果レポート
• examples/method-selection-scenarios.md：「状況Xでは手法Yを使う」という判断ガイド
• examples/interview-to-insights.md：生のインタビューデータから実用的なインサイトを導き出すまでの手順