Ux research

UXリサーチ（ユーザーインタビュー・ユーザビリティテスト）

目的

• 「なぜそのような行動をするのか」をユーザーの言葉と事実で明らかにする
• 思い込みに基づいた設計・実装を防ぐ
• インサイトを要件・設計・企画に接続し、リサーチを行動に変える

定量（[[analytics-kpi]]）は「何が起きているか」を示し、定性は「なぜ起きているか」を示す。両方揃って初めて意思決定ができる。

使うタイミング

• 解くべき課題が本当に存在するかを検証したいとき（企画・アイデア段階）
• プロトタイプや画面設計の問題を実装前に発見したいとき
• リリース直前の最終確認としてタスク達成率を測りたいとき
• 運用中に離脱・不満の原因を深堀りしたいとき

手法の選び方

手法	目的	適したフェーズ	最小サンプル
ユーザーインタビュー	課題・行動・動機の発見	企画前・課題定義	5人
ユーザビリティテスト	操作の詰まり・誤解の発見	プロトタイプ・リリース前	5人
アンケート	量的な傾向・優先度の確認	仮説検証・定量補完	30人〜
フィードバック分析	既存の不満・要望の収集	運用中（常時）	—

5人インタビュー/テストすれば主要な問題の大半が見つかる。完璧なサンプル数より早期の反復を優先する。

ユーザーインタビュー

The Mom Test の原則（誰でも本音を語りやすくする質問設計）

• 意見でなく過去の事実を聞く: 「使いたいですか?」→「最後にその問題が起きたのはいつ?どう対処しましたか?」
• 誘導質問の禁止: 「便利だと思いませんか?」は相手に答えを教えてしまう
• アイデアを売り込まない: 検証したいアイデアを説明し始めると「いいですね」しか返ってこなくなる
• 相手に喋らせる: 自分2割・相手8割。沈黙を埋めない
• 社交辞令を信用しない: 「使います」「買います」は行動・前払い・紹介のある場合のみ本物のシグナルとして扱う

リクルーティング時の注意

• ターゲット条件（職種・利用状況・経験年数等）を事前に明文化する
• 知人・身内への依頼は忖度バイアスが入る。可能な限り第三者を優先する
• 謝礼（Amazonギフト・現金相当）は必ず用意し、謝礼目当て参加者への注意も怠らない

ユーザビリティテスト

進行の基本ルール

• 実タスクを与えて観察する（例:「この画面でプランをアップグレードしてください」）
• 思考発話法を使う: 「考えていることを声に出しながら操作してください」と最初に依頼する
• 司会は助けない・誘導しない。詰まっても沈黙を保つ
• 詰まった箇所・想定外の操作こそが最大の発見

計測する指標

• タスク達成率（成功/失敗/部分成功）
• 詰まった箇所と発言の記録
• 所要時間と操作ステップ数（オプション）

プロトタイプ検証の原則

実装前に紙・Figma・モックで検証する（[[screen-design]]、[[mvp-development]]参照）。作ってから聞くのでは手戻りコストが大きい。

進め方

1. 目的・問いを1文で定義する

   • 「このリサーチで答えたい問いは何か」を書く。曖昧なまま実施しない

2. 手法と対象者条件を決める

   • 上記の手法選択表を参照。ターゲット条件（属性・経験・利用状況）を明文化する

3. インタビューガイド/タスクシナリオを作成する

   • 成果物テンプレートを使ってガイドを準備する
   • インタビュー: オープン質問から始め、具体的な過去事例へ絞り込む
   • ユーザビリティテスト: タスクは「〜を探して〜してください」と行動で指示する

4. リクルーティングと日程調整

   • 最低5人を確保。知人バイアスを避ける
   • セッション時間はインタビュー45〜60分、テスト30〜45分を目安とする

5. セッションの実施と記録

   • 録音・録画（同意を必ず取る）または文字起こし担当を別途用意する
   • 発言の「引用（事実）」と「解釈（意味）」を分けてメモする

6. 結果の構造化

   • 課題を「頻度 × 深刻度」でマッピングする
   • 1人の強い意見は「仮説」として扱い、複数人への確認が取れるまで方針転換しない
   • インサイト→要件（[[requirements-definition]]）・企画（[[idea-generation]]）へ接続する

7. アクションの決定と記録

   • 「何を次のスプリントで対応するか」を明記して終了する

成果物テンプレート

# インタビューガイド: [プロジェクト名]
作成日: YYYY-MM-DD / リサーチの問い: [1文]

## 対象者条件
- 職種/属性: / 経験・利用状況: / 除外条件:

## 導入（5分）
「今日は[テーマ]についてお話を聞かせてください。正解・不正解はありません。
録音してもよろしいでしょうか?」

## 質問リスト（35〜40分）
1. [テーマ]について、普段どんな場面で困りますか?
2. 最近その問題が起きたのはいつですか?どんな状況でしたか?
3. そのとき実際にどう対処しましたか?
4. 他に試したツールや方法は?なぜそれを選びましたか?
5. 理想的にはどうなれば解決しますか?（「使いたいですか?」は聞かない）
深堀り: 「もう少し詳しく」「一番大変だったのは?」「もし使えなくなったら?」

## クロージング（5分）
「最後に伝えておきたいことがあれば教えてください。」

---
# リサーチ結果サマリ: [プロジェクト名]
実施日: YYYY-MM-DD / 参加者: N人

| 課題 | 頻度 | 深刻度 | 代表引用 |
|------|------|--------|--------|
| | N/N人 | 高/中/低 | |

インサイト:
1. [インサイト]: [引用]

次のアクション: [課題] → [対応] (優先度/担当/期限)

チェックリスト

• リサーチの問いを1文で定義した
• 対象者条件を明文化し、知人バイアスを排除した
• 質問はオープン質問・過去の事実ベースで設計した（誘導質問なし）
• セッション記録の同意を取得した
• 発言の「引用」と「解釈」を分けてメモした
• 課題を頻度×深刻度でマッピングした
• 1人の意見で方針を変えていない（複数人確認済み）
• インサイトを要件・企画への接続まで記載した
• 次のアクションを明記して終了した

アンチパターン

• 作り終えてから初めて見せる: 実装コストが発生した後では「作り直し」を判断しにくい。プロトタイプ段階で検証する
• 誘導質問で欲しい回答を集める: 「便利ですよね?」「使いたいと思いませんか?」は調査ではなく説得になる
• 1人の強い意見で全方針を変える: 声の大きいユーザーの意見は仮説として扱い、複数人への確認が取れるまで保留する
• 調査して満足し要件に反映しない: リサーチは意思決定のための手段。アクションが出なければ実施した意味がない
• 社交辞令の「いいですね」を需要と誤認する: 実際の購買・前払い・他者への紹介がないかぎり需要の証拠にならない
• 定性だけで意思決定する: 5人の声だけで「ユーザー全員が同じ課題を持つ」と結論づけない。定量（[[analytics-kpi]]）と組み合わせる

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当タスク
司令塔（メインモデル）	リサーチ設計・問いの定義・各エージェントへの指示・インサイトの解釈・アクション決定
Opus相当	インタビュー記録からのインサイト抽出レビュー・解釈の妥当性検証・課題の優先度判断
Sonnet相当	インタビューガイドのドラフト・録音の文字起こし整理・課題の頻度×深刻度集計
Haiku相当	既存フィードバック（レビュー・問い合わせ・サポートログ）の収集・引用の整理

並列委譲の例:

• 複数セッションの文字起こし整理を複数のSonnet相当エージェントに同時依頼
• App Storeレビュー・サポート問い合わせ・SNS言及の収集を複数のHaiku相当エージェントに同時依頼

関連スキル

• [[orchestration]] — 並列エージェント管理の共通原則
• [[requirements-definition]] — リサーチ結果を要件定義に接続する
• [[idea-generation]] — インサイトから新機能・新サービスのアイデアを発散する
• [[screen-design]] — 発見した課題をUI設計に反映する
• [[mvp-development]] — 検証前の最小プロトタイプ構築
• [[market-research]] — 定性リサーチを市場規模・競合分析と組み合わせる
• [[analytics-kpi]] — 定量データと組み合わせて「なぜ」を明らかにする
• [[accessibility]] — ユーザビリティテスト時に合わせて確認すべき観点