顧客インタビューの調査計画を書く方法

要点

顧客インタビューの調査計画は、長い企画書である必要はありません。調査がどの意思決定に使われるのか、すでに何が分かっているのか、何がまだ不明なのか、誰にどの方法で会うのか、データをどう扱い、いつ分析するのか。この七つがチームに伝われば、計画として機能します。

よくある失敗は、最初から質問を大量に並べることです。先に意思決定を書き、不確実な点を調査課題に変え、その後でインタビューガイドを作る方が、現場で迷いません。

この記事では、SaaS チームが「次の四半期に新規ユーザーの初期設定を作り直すべきか」を判断するケースを使います。小規模チームの一部が設定を完了していませんが、どこで止まり、なぜ止まり、その後どうしたかはまだ分かっていません。

質問一覧ではなく、意思決定から始める

計画の冒頭には、誰が、いつ、何を決めるために調査を使うのかを書きます。

「新規ユーザー体験を理解する」だけでは広すぎます。たとえば、次のように範囲を絞ります。

次回の四半期ロードマップ会議までに、プロダクト責任者が初期設定全体を再設計するか、摩擦の大きい一部だけを直すか判断する。本調査では、小規模チームが設定を終えないときに何が起きるかを把握し、追加検証すべき箇所を特定する。

この文は、数回のインタビューで解決策を証明すると約束していません。実際の判断と調査を結び付けているだけです。判断自体が曖昧なら、依頼者に「調査後に変わり得る選択肢は何か」「結果はいつ必要か」「調査をしない場合は何を根拠に決めるか」を聞いてみてください。

既存のエビデンスと、本当に分からないことを分ける

インタビューは何にでも使える手法ではありません。ファネルデータ、問い合わせ、営業メモ、過去のユーザビリティテスト、解約理由などを先に確認します。

データから「38% の新規アカウントが特定の手順まで進んでいない」と分かっても、利用者が何をしようとしていたか、何の情報が足りなかったか、誰の協力が必要だったかまでは説明できません。そこがインタビューで補える部分です。

計画には「分かっていること」「まだ確認できないこと」「使えるエビデンス」の三列を作ると整理しやすくなります。インタビューは経験や状況の理解に向きますが、因果関係や市場全体での発生率を単独で証明するものではありません。この限界も計画に残します。

不明点を調査課題に変える

調査課題はチームが読む文です。参加者にそのまま尋ねる質問ではありません。今回なら、次のように書けます。

• 小規模チームは最初の設定で何を終えようとしていたか。
• どの場面で追加情報、他者の協力、回避策が必要になったか。
• 完了した人と途中で止めた人では、手順や完了判断がどう違ったか。
• 設定を中断した後、本来の仕事をどう進めたか。

「招待手順が複雑だから離脱したのか」は仮説を埋め込んでいます。「招待時にどんな判断をし、何が継続や中断に影響したか」とすれば、予想に反する材料も拾えます。

重複をまとめ、重要度を付けます。一つのラウンドなら、中心となる課題を3〜5個に絞る方が扱いやすいでしょう。会話で使う問いへの落とし込みは、顧客インタビューの質問設計ガイドで詳しく説明しています。

参加者の条件とラウンドを決める

「ユーザー数名」では募集条件になりません。関連する経験、役割、利用状況、その経験がいつ起きたか、どの差をカバーするかを書きます。

今回なら、過去60日以内に設定を試した小規模チームの利用者を対象にし、完了者と中断者、意思決定をするアカウント責任者と作業を任されたメンバーを含めます。大企業の管理者は、調達や権限設定の事情が別の調査テーマになり得るため、今回は除外できます。

人数に万能な答えはありません。GOV.UK のサービスマニュアルは、質的調査の一ラウンドで4〜8名を一般的な範囲として紹介し、得られた内容に応じて次のラウンドを計画するよう勧めています。これは統計的代表性や「必ず飽和する人数」を意味しません。

最初は6件、2件ごとに短く振り返り、重要な役割が欠けている場合や新しい材料で解釈が変わり続ける場合に追加する、と書けば実行しやすくなります。

問いに合う手法を選ぶ

最近の経験や判断、そのときの制約を知りたいならインタビューが合います。新しい画面を操作できるか知りたいなら、実際に使ってもらい観察します。行動の発生率を推定したいなら、分析データや適切に設計した調査が必要です。

組み合わせても構いません。最近の設定経験を時系列で話してもらい、同意を得たうえで、残っている画面や資料を見せてもらう方法です。計画には名称を並べるより、選んだ理由を書きます。

最近の設定経験を扱う45分の半構造化インタビューを実施する。ワークスペースが残っており本人が同意した場合は、短い操作説明も依頼する。経験と判断を理解するために使い、発生率の推定には使わない。

録音前に、同意とデータ管理を計画する

音声、映像、共有画面、文字起こしには、個人情報や企業の機密情報が含まれる可能性があります。初回セッション直前まで扱いを決めずにいるのは危険です。

参加者に何を伝えるか、どの記録に同意が必要か、誰が原資料を見られるか、文字起こしや調査ツールに提供するか、報告時にどう匿名化するか、保存期間、撤回と削除の流れを計画に記します。将来役立つかもしれないという理由だけで、不要な情報を集めないようにします。

法的・組織的な要件は、地域、業界、契約、データの種類によって変わります。この記事は法的助言ではありません。機微な個人情報、未成年者、医療情報、規制対象データを扱う場合は、組織のプライバシーまたは法務担当者に確認してください。

ScribeFlash では、メディアとプロジェクトデータの保存期間を選べます。ただし、この設定だけで同意、アクセス管理、法令対応が完了するわけではありません。

最初のインタビュー前に分析時間を確保する

最終インタビューまで日程を埋め、レポート作成の時間を忘れる計画は珍しくありません。重要箇所の確認、エビデンスの整理、参加者間の比較、反例の検討、知見の記述とレビューには時間がかかります。

GOV.UK は分析時間を明示的に確保し、目安として調査2時間につき少なくとも分析1時間を挙げています。複雑な調査ではさらに必要です。2件ごとに短いデブリーフを入れ、終了後に連続した統合分析の時間を守る方が現実的です。

担当者と成果物も決めます。文字起こしを確認する人、引用をエビデンスとして整理する人、知見をレビューする人、レポートを受け取る意思決定者と日付を明記します。反対の材料も消さずに残してください。違いは役割や利用環境の差を示しているかもしれません。顧客インタビュー分析ガイドでは、その後の作業を詳しく扱っています。

そのまま書き換えられる調査計画

背景と意思決定
（日付）までに（具体的な判断）を行う。今回の調査を始める根拠は（データ、フィードバック、事業上の変化）である。

既存のエビデンスと不明点
すでに（情報源と範囲）が分かっている。判断に影響する（不確実な点）を理解する必要がある。本ラウンドでは（因果、発生率、範囲外の問題）を扱わない。

調査課題
優先順位を付けた3〜5個を記す。望ましい解決策が有効だと前提しない。

参加者
（期間）内に関連経験があり、（役割、利用状態、重要な差）を含む。（条件と理由）は除外する。（件数）から始め、（時点）で追加の要否を確認する。

手法、同意、データ管理
（手法）を一回（時間）で行う。記録方法、処理者、アクセス、匿名化、保存期間、撤回、削除を記し、高リスクのデータは専門担当者に確認する。

分析と共有
（件数）ごとに振り返り、（担当者）がエビデンスを整理する。（日付）までに統合し、（成果物）を（意思決定者）へ共有する。

リスクと限界
募集の偏り、欠けている役割、日程、自記式回答への依存と、その軽減策を記す。

ScribeFlash で調査プロジェクトを作成する

計画が合意できたら、後の分析に使う項目を ScribeFlash に移します。ローカルへのインストールは不要です。Web 版にログインして進めます。

1. Projects を開き、New project を選びます。
2. 「2026 Q4 小規模チーム初期設定調査」のように識別できる名前を付けます。
3. 必要なら顧客名や会社名を入力します。社内調査では空欄でも構いません。
4. 目的欄に、意思決定と範囲を書きます。インタビューガイド全体を貼り付ける欄ではありません。
5. 予定インタビュー数を入力します。計画用の値であり、統計的代表性を示すものではありません。
6. 調査課題を一つずつ追加します。重複をまとめ、中心となる3〜5個を残します。プロジェクト作成には少なくとも一つ必要です。
7. 元の言語と出力言語を選びます。多言語調査では、原文と翻訳のどちらを引用するか、重要な表現を誰が確認するかも決めます。
8. 参加者への説明と組織方針に合うメディア・プロジェクトデータ保存期間を選びます。
9. 製品名、人名、略語、専門用語が繰り返される場合は、既存の用語集を選びます。
10. プロジェクトを作成します。各セッション後に音声または動画をアップロードし、非同期の文字起こし完了後、知見に関わる箇所を確認します。詳しい操作は調査プロジェクト作成ガイドを参照してください。

プロジェクトの項目が調査判断を代行するわけではありません。目的、課題、文字起こし、エビデンス、知見を同じ流れに保つための土台です。

参考資料

• GOV.UK Service Manual: Plan a round of user research
• GOV.UK Service Manual: Plan user research for your service
• GOV.UK Service Manual: Capturing research questions
• Department for Education: Writing a user research plan
• Nielsen Norman Group: Project Management for User Research: The Plan
• GOV.UK Service Manual: Getting informed consent for user research
• GOV.UK Service Manual: Managing user research data and participant privacy