この技術でできること
- ビジネス課題を インタビューで答えられる問い に変換できる
- 「何を聞くか」が明確になり、 質問設計 がスムーズになる
- インタビュー終了後に 「答えが出たか」を判断 できる
例 : 「売上が落ちている」はビジネス課題であってリサーチクエスチョンではない。「過去3ヶ月で購入をやめたユーザーは、どの段階で・なぜ離脱しているか」がリサーチクエスチョン
なぜ難しいか
ビジネス課題とインタビュー質問の間に 翻訳が必要 。
「コンバージョン率を上げたい」をそのまま聞いても答えは出ない。ビジネスの言葉をユーザーの言葉に変換し、インタビューで回答可能な粒度にする。この翻訳を飛ばすと、「聞いたけどわからなかった」になる。
設計プロセス
全体フロー
「ビジネス課題の整理」→「リサーチクエスチョンへの変換」→「質問の優先順位づけ」→「インタビュー質問への展開」。ビジネスの言葉をユーザーの言葉に翻訳する。
ステップ1: ビジネス課題を整理する
目的 : 関係者が知りたいことを洗い出す
やること :
- 関係者に「この調査で何がわかれば嬉しいか」を聞く
- 仮説を洗い出す
- 既に知っていること・まだ知らないことを分ける
例 :
ビジネス課題: カート離脱率が高い
既知:
- カート追加後の離脱率が40%
- 送料表示のタイミングが遅い
未知:
- ユーザーがどの段階で離脱を決めているか
- 離脱の本当の理由（送料以外にも原因がありそう）
- 他のECでの行動パターン
ステップ2: リサーチクエスチョンに変換する
目的 : ビジネス課題を、インタビューで答えられる問いに変換する
変換ルール :
- ❌ 「はい/いいえ」で答えられる問い → ✅ 「なぜ」「どのように」で始まる問い
- ❌ ビジネスの言葉 → ✅ ユーザーの言葉
- ❌ 複数のテーマを1つに → ✅ 1問1テーマ
変換例 :
| ビジネス課題 | 悪いRQ | 良いRQ |
|---|---|---|
| 離脱率を下げたい | 離脱率は下がるか？ | ユーザーはどの段階で購入をやめる判断をしているか？ |
| 検索を改善したい | 検索は使いにくいか？ | ユーザーは商品を見つけるためにどんな行動をしているか？ |
| リピート率を上げたい | リピートする理由は？ | 再購入したユーザーは、何がきっかけでアプリを再度開いたか？ |
良いリサーチクエスチョンの特徴 :
- インタビューで答えられる（観察・行動・体験を聞ける）
- 具体的（対象・範囲が明確）
- オープン（「はい/いいえ」で終わらない）
- 1問1テーマ
ステップ3: 優先順位をつける
目的 : 限られた時間で聞くべき順番を決める
やること :
- リサーチクエスチョンを3〜5個に絞る
- Must / Nice to have に分ける
- 1回のインタビューで全部聞ける量か確認する
目安 : 60分のインタビューで、深く答えられるRQは3個程度
ステップ4: インタビュー質問に展開する
目的 : RQを、ユーザーに直接聞ける質問に変換する
注意 : RQはそのまま聞く質問ではない。
| リサーチクエスチョン | インタビュー質問 |
|---|---|
| どの段階で離脱しているか | 「最後にカートに入れたけど買わなかった時のことを教えてください」 |
| 何がきっかけで再度開いたか | 「最近このアプリを開いた時、何がきっかけでしたか？」 |
→ 質問の作り方の詳細は質問設計
よくある失敗
❌ RQが広すぎる
「ユーザーはこのサービスについてどう思っているか？」
なぜ失敗するか : 何でも聞けるが何も深く聞けない。分析時に統合できない。
対策 :
- 対象・範囲・行動を限定する
- 「どう思っているか」→「何をしているか」に変換する
❌ RQに答えが含まれている
「ユーザーは送料の高さで離脱しているのではないか？」
なぜ失敗するか : これはRQではなく仮説。このまま聞くと確証バイアスに陥る。
対策 :
- 仮説を外した問いに変換する
- 「どの段階で・なぜ離脱しているか」にする
実践チェックリスト
最低ライン（Must）
理想ライン（Better）
関連技術
前提となる技術
- 調査設計 — RQ設計の前段階
セットで使う技術
次に学ぶ技術
- リクルーティング — 設計の次は対象者選定
まとめ
- この技術の本質 : ビジネス課題を、インタビューで答えられる問いに「翻訳」する技術
- できるようになること : インタビュー終了後に「何がわかったか」を明確に報告できる
- 次に学ぶべき技術 : リクルーティング（RQに答えてくれる人を見つける）
目的別のおすすめ :