UIXHERO

調査設計|インタビュー技術

インタビュー調査の目的設定、スコープ定義、計画立案の技法。調査設計がインタビューの成否を決める。

2026年3月22日
更新: 2026年8月27日
4
by Dengen Yosho(DGYS)

調査設計

この技術でできること

  • 「何のためにインタビューするか」を明確な問いに変換できる
  • インタビュー全体のスコープと計画を設計できる
  • 終了後に「で、何がわかったの?」と言われない成果定義ができる

: 「ユーザーの声を聞きたい」ではインタビューは始められない。「ECアプリのカート離脱の原因を、過去3ヶ月以内の購入者5名へのインタビューで特定する」まで落とすのが調査設計


なぜ難しいか

インタビューは「聞けば何かわかる」という誤解が根強い。

準備なしに始めると、聞きたいことが散らかり、分析できないデータが山積みになる。調査設計の本質は「何を明らかにしないか」を決めること。スコープを絞ることで、限られた時間で深い理解に到達できる。


調査設計の進め方

全体フロー

「目的の明確化」→「の設定」→「対象者の定義」→「実施計画の立案」。設計は必ず目的から逆算する。


ステップ1: 目的を明確にする

目的: なぜインタビューが必要かを、1文で説明できる状態にする

やること:

問い
何を知りたいかカート離脱の原因
なぜ知りたいかコンバージョン率改善のため
知った後どうするか改善案を3つ提案する

良い目的:

  • 「ECアプリのカート離脱原因を理解し、改善施策を提案する」

悪い目的:

  • 「ユーザーの声を聞く」(何を知りたいか不明)
  • 「サービスを改善する」(広すぎ)
  • 「検索機能が使いにくいことを確認する」(結論が先にある)

ステップ2: リサーチクエスチョンを設定する

目的: 目的をインタビューで答えられる問いに変換する

→ 詳細はリサーチクエスチョン設計

ここでのポイント:

  • リサーチクエスチョンは3〜5個に絞る
  • 1回のインタビューで答えられる粒度にする
  • 「はい/いいえ」で答えられない問いにする

ステップ3: 対象者を定義する

目的: 誰に聞けばリサーチクエスチョンに答えられるかを決める

→ 詳細はリクルーティング

ここでのポイント:

  • 行動ベースで定義する(「使いたい人」ではなく「使った人」)
  • を1つに絞る
  • 5〜8人を目安にする(同一セグメントで傾向が繰り返されるかを確認するための目安)

ステップ4: 実施計画を立てる

目的: いつ・どこで・どうやってインタビューするかを決める

やること:

項目決めること
形式対面 / リモート / 電話
時間30分 / 45分 / 60分
場所オフィス / ユーザーの自宅 / オンライン
人数5〜8人(1セグメント)
期間1〜2週間(リクルーティング含む)
記録録音 / 録画 / メモ
分析コーディング /
成果物レポート / 施策提案書

テンプレート:

【調査設計書】

■ 目的
[1文で]

■ リサーチクエスチョン
1. [RQ1]
2. [RQ2]
3. [RQ3]

■ 対象者
- 条件: [行動ベースの条件]
- 人数: [X人]
- 除外: [除外条件]

■ 実施計画
- 形式: [対面/リモート]
- 時間: [XX分]
- 期間: [開始日〜終了日]
- ツール: [Zoom/対面]

■ 成果物
- [インサイトレポート/施策提案書]
- 報告日: [日付]

よくある失敗

❌ スコープが広すぎる

全般について聞く」と設計する。

なぜ失敗するか: 何でも聞けるが、何も深く聞けない。分析時に「で、結論は?」となる。

対策:

  • リサーチクエスチョンを3つ以内に絞る
  • 「今回は〇〇だけに集中する」と宣言する
  • 聞かないことリストを作る

❌ 「知った後どうするか」を決めていない

インタビュー結果をどう使うかが決まっていない。

なぜ失敗するか: データは集まるが、施策に変換するプロセスがない。報告書が「面白かったです」で終わる。

対策:

  • 調査設計時に「このインタビューの結果、何を決めるか」を書く
  • 関係者にも「この調査で何が決まるか」を合意する

実践チェックリスト

最低ライン(Must)

理想ライン(Better)


関連技術

前提となる技術

セットで使う技術

次に学ぶ技術


まとめ

  • この技術の本質: 「何を明らかにするか」だけでなく「何を明らかにしないか」を決める技術
  • できるようになること: 終了後に「で、何がわかったの?」と言われない設計ができる
  • 次に学ぶべき技術: リサーチクエスチョン設計(調査設計の核心)

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年8月27日

この記事を書いた人

Dengen Yosho(DGYS)

Dengen Yosho(DGYS)

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

あわせて読みたい

この記事に関連する記事をご紹介します

倫理・同意|インタビュー技術

インタビュー参加者の権利を守るための倫理的配慮と同意取得の技法。

2026年3月22日
6

リサーチクエスチョン設計|インタビュー技術

「聞きたいこと」を構造化し、インタビューで答えられる問いに変換する技法。

2026年3月22日
5

スクリーナー設計|インタビュー技術

インタビュー対象者を確実に選別するスクリーナーの設計技法。条件をYes/Noに変換し、プロ参加者を排除する。

2026年3月22日
5

もっと深く知りたいですか?

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る