調査レポート

意思決定に使えるユーザー調査レポートの書き方

調査目的、参加者、知見、原文の根拠、反証、限界、提案を整理し、判断に使えて後から検証できるインタビューレポートを作ります。

ScribeFlash リサーチチーム2026年10月23日約10分

要点

ユーザー調査レポートは、インタビューごとの要約を並べたものでも、印象的な発言を集めたスライドでもありません。セッションに参加していない人が、何が観察され、どの資料がその解釈を支え、どこでは成り立たず、次に何を判断すべきか理解できる文書です。

私は「根拠のある意思決定記録」と考えるのが分かりやすいと思います。冒頭に対象となる判断と重要な知見を書き、主な主張を原資料につなぎ、最後に提案、未解決の問い、限界を置きます。分析中に作ったラベルをすべて本文へ詰め込む必要はありません。

見た目が整った文書でも、根拠が弱ければ良いレポートにはなりません。十分な知見がない段階で、AI に流暢な文章を作らせて穴を隠さないことが大切です。

このレポートで何を決めるのか

同じインタビューからでも、読者が変わればレポートは変わります。プロダクト担当者はオンボーディングの修正順を決めたいかもしれません。営業責任者は購買時の障壁を知りたいでしょう。

書き始める前に、誰が読み、誰が決めるのか、読後に何を始める・止める・選ぶのか、どの調査課題が直接関係するか、このレポートから外す材料は何かを確認します。

「8件のインタビューをまとめる」は作業説明です。「次四半期に招待フローと権限説明のどちらを先に直すか決める」なら、情報を選ぶ基準になります。

GOV.UK は、設計や優先順位、ロードマップに使える時期に調査結果を共有するよう勧めています。決定後に届く立派な報告書より、単独で理解できる短い資料の方が役立つ場面は多くあります。

実務に使える基本構成

要約では、背景、重要な2〜3個の知見、現在の提案、残るリスクを1ページ以内で説明します。目次ではありません。ここしか読まれなくても判断の論点が伝わる内容にします。

調査目的と課題には、この調査が支える決定と、材料から答えられる問いを書きます。後から目的を「当初案が正しいことの検証」に変えてはいけません。

参加者と方法には、実施時期、件数、募集条件、役割の違い、セッション形式、分析方法を記します。氏名は不要ですが、主張がどの範囲から得られたかは必要です。

主な知見が本文です。各知見に、短い見出し、説明、適用範囲、支持する根拠、必要な反証を置きます。質問順ではなく、意思決定への重要度で並べます。

提案と未解決の問いでは、すぐ実行できること、設計テストが必要な方向、追加調査が必要な問いを分けます。

限界と付録には、サンプルと手法の境界、調査計画、インタビューガイド、詳細な証拠索引を残します。

根拠が許す範囲で知見を書く

よくある失敗は、知見が短すぎることではなく、大きすぎることです。

初回利用の運用担当者6名のうち4名が、同僚を招待する前に権限を確認したとします。次の表現なら範囲が見えます。

今回参加した運用担当者の中では、招待の段階で権限リスクの確認が起きた。複数の参加者が設定を止め、上司や IT 担当者に相談した。

「ユーザーは権限モデルを信用していない」や「招待フローが新規ユーザーの67%を離脱させる」とは書けません。前者は局所的な材料を普遍的な心理へ広げ、後者は小さな定性サンプルを離脱率に見せています。

知見には、何が起きたか、誰にどの条件で起きたか、なぜ判断に関係するか、何までは言えないかを含めます。件数は今回の材料の分布を示しますが、範囲説明の代わりにはなりません。

引用を飾りにせず、原資料へ戻れるようにする

強い引用は会議の印象を支配します。しかし、一人だけの特殊な経験かもしれず、前後を読むと意味が変わることもあります。引用は知見を理解する助けであって、知見そのものではありません。

重要な主張ごとに、匿名の参加者またはセッション、正確な文字起こし、録音の時間位置、校正状態、支持する根拠・反証・研究者メモの区別を残します。

参加者の発言と研究者の解釈を「ユーザーの声」として混ぜないでください。NN/g の AI 調査ツール評価でも、会話や時刻、原資料への参照がない生成結果は検証しにくいと指摘されています。

反証をレポートに残す

4人が同じ場所で止まると、きれいな物語ができます。止まらなかった2人の方が、問題の発生条件を教えてくれるかもしれません。

4名は招待前に権限を確認した。止まらなかった2名は、事前に管理者から権限一覧を受け取っていた。現時点では、操作だけでなく情報不足が摩擦に関係している可能性がある。

この書き方なら、全面的な再設計の前に、権限説明を早く提示するテストができます。主流のテーマと合わないケース、欠けている役割、中断したセッションも知見の境界に影響します。

知見と提案を分ける

「参加者が権限説明を見つけられなかった」は知見です。「説明を招待ボタンの上に移す」は解決案です。関連はありますが、同じ主張ではありません。

分けておけば、チームは問題に同意しつつ、より良い案を考えられます。設計テストが失敗しても、元の調査まで否定されません。

提案には担当者、期待する変化、確認方法を付けます。「案内を改善する」では検証できません。「2種類の配置を次回5件のタスクテストで比較し、助けを求めず招待相手を判断できるか観察する」なら進められます。

限界とプライバシーを小さな注記にしない

参加者がアクティブ利用者に偏っていないか、重要な役割が欠けていないか、自記式の説明だけに頼っていないか、翻訳でニュアンスが失われていないかを書きます。この調査で答えられない発生率や因果関係も明示します。

共有前にはプライバシーを再確認します。GOV.UK は、可能な限り個人を特定できない抜粋を使い、氏名、連絡先、直接識別子を除くよう勧めています。十分に匿名化できない資料は、参加者に事前説明した必要な相手だけに共有します。

名前を「参加者A」に変えるだけでは足りない場合があります。珍しい職種、会社規模、地域、特徴的な経験の組み合わせでも人は特定されます。

ScribeFlash でレポートを作成する

分析で提案された知見を開き、本文、支持する根拠、反証、引用を確認してから承認または却下します。
信頼できる知見を少なくとも一つ確認したら、レポートで生成します。未確認の知見から編集用の草稿は作れますが、草稿は出力できません。
調査目的、方法、参加者概要、知見、根拠、限界、提案、付録を読み、今回の読者に合わせて直します。
章のタイトルと本文を編集し、追加、複製、並べ替え、非表示、削除を行います。非表示の章は出力されません。
引用を開き、知見、参加者、インタビュー、原文、時間位置を確認します。元資料の変更で無効になった引用を解決します。
品質チェックで、知見、支持する根拠、反証、有効・無効な引用の件数を確認します。重大な引用エラーが残る間は完成扱いにしません。
確認後に準備完了へ変更し、TXT、CSV、DOCX、PDF のいずれかで出力します。
後から文字起こしや証拠、知見が変わった場合は、新しいレポート版を作って再確認します。

画面操作は調査レポート作成ガイド、上流の確認は知見レビューガイドを参照してください。

共有前の5分チェック

要約に対象となる意思決定が書かれているか。
各知見の人と状況の範囲が明確か。
引用からセッション、文字起こし、時刻へ戻れるか。
知見の範囲を変える反証が残っているか。
提案が知見と分かれ、検証可能な次の行動になっているか。
限界が具体的で、プライバシー処理が同意内容に沿っているか。
非表示の章、古い版、無効な引用が最終出力から除かれているか。

送付後は話し合いの場を設けます。意思決定者が証拠をどう理解し、何を実行し、どこを疑っているかを聞いてください。納品物はファイルだけではありません。同じ根拠を見ながら、チームが判断できる状態までが調査の共有です。

参考資料

確認済みの知見から編集可能なレポートを作成

支持する根拠、反証、引用を確認してから、チームが使えるレポートに整えます。

調査プロジェクトを作成

サンプルレポートを見る調査テンプレートを選ぶ

ユーザー調査レポートインタビューレポート調査結果定性調査

ScribeFlash ブログ