user-research-synthesis

ユーザー調査の統合

使用するタイミング

創業者または PM が未加工の定性調査データを提供し、それを構造化されたインサイトにまとめる必要がある場合に有効にします。これには、顧客インタビューの書き起こし、アンケートの自由回答、サポートチケットのログ、NPS の自由回答、営業通話のメモ、アプリストアのレビュー、コミュニティフォーラムの投稿が含まれます。「これらのインタビューを要約して」「顧客は何と言っていますか」「このフィードバックをまとめて」「これらの顧客との会話の分析を手伝って」といったフレーズがトリガーになります。

必要なコンテキスト

• startup-context から： プロダクトの段階、現在の顧客セグメント、検証中の既知の仮説、既存のペルソナ（ある場合）。
• ユーザーから： 未加工のデータソース（書き起こし、メモ、録音）、調査対象の質問、参加者の背景情報、検証または否定したい特定の仮説。

ワークフロー

1. 書き起こし全体を読む -- 要約する前に、書き起こしまたはデータソース全体に目を通します。すべての資料を確認するまで、要約を始めないでください。これにより、新近性バイアスを防ぎ、見落としをなくします。
2. メタデータを記録する -- インタビューの日付、参加者、参加者の背景、会話のコンテキストを記録します。
3. 現在の解決策を特定する -- 参加者が現在使用している解決策と、それぞれの満足度を記録します。これにより、ユーザーの視点から競争環境が明らかになります。
4. 問題と課題を抽出する -- 参加者が言及した問題をすべて、本人の言葉で記録します。症状と根本原因を分けます。
5. Jobs to Be Done の枠組みを適用する -- 主な調査結果ごとに、JTBD として表現します：「[状況] のとき、[動機] したい。そうすれば [期待する成果] を得られるからです。」これにより、機能から成果へと焦点を移せます。
6. 予想外の発見に印を付ける -- 既存の前提に疑問を投げかける、驚くようなインサイト、矛盾、調査結果を記録します。こうした発見は、最も戦略的な価値を持つことがよくあります。
7. フォローアップのアクションを定義する -- 調査結果に基づいて、誰が何をすべきかを明確にした具体的な次のステップを列挙します。
8. 確信度を評価する -- データ量と情報源間の一貫性に基づき、各インサイトの確信度を高・中・低で評価します。

出力形式

インタビューの要約（書き起こしごと）

個々の書き起こしまたはデータソースごとに、以下を記載します。

• メタデータ： 日付、参加者の名前・役割、参加者の背景
• 現在の解決策： 現在利用しているものと満足度
• 気に入っている点： 現在のプロダクトまたはワークフローに対する肯定的な反応
• 特定された問題： 参加者自身の言葉による課題と直接引用
• 主な発見： 前提に疑問を投げかける予想外の発見やインサイト
• フォローアップのアクション： 担当者の候補を添えた具体的な次のステップ

インタビュー横断の統合（複数の情報源がある場合）

Jobs to Be Done マップ

ジョブステートメント	頻度	セグメント	確信度
[状況] のとき、[動機] したい。そうすれば [成果] を得られるからです。	情報源 X 件中 N 件	セグメント名	高／中／低

実行可能なインサイト

「[調査結果] が分かりました。これは [示唆] を意味するため、[推奨事項] を実施すべきです。」の形式で、インサイトを番号付きリストにします。

未解決の質問

データで明らかにならなかったことと、推奨する次の調査ステップ。

フレームワークとベストプラクティス

• Jobs to Be Done（JTBD）。 すべての調査結果を、顧客が求める機能ではなく、顧客が達成しようとしているジョブとして捉えます。顧客は、自分の生活を前進させるために製品を選びます。
• 要約する前に読む。 要約を書く前に、必ずトランスクリプト全体を確認します。一部しか読まないと、偏った統合につながります。
• 専門用語より平易な言葉を使う。 技術に詳しくない関係者を含め、チームの誰もが理解できる要約を書きます。チーム内で一貫して使われている場合を除き、プロダクトマネジメントの専門用語は避けます。
• 直接引用を残す。 最も強力なデータポイントは、参加者の感情、具体性、言葉遣いを捉えた逐語的な引用です。「先週の火曜日、レポートを作り直すのに3時間かかりました」は、「レポート作成が大変です」よりも有用です。
• 満足している点と問題点を分ける。 ユーザーが現在のソリューションのどこを気に入っているかと、何に不満を感じているかを明確に記録します。強みを把握しておくことで、それを誤って損なわずに済みます。
• 現在のソリューションから競合が見えてくる。 参加者が現在使っているもの（スプレッドシート、手作業のプロセス、回避策を含む）を記録すると、直接的な製品競合よりも広い、実際の競争環境が見えてきます。
• 頻度と重要度は別です。 10人中2人が挙げた課題でも、その2人が理想的な顧客プロファイルに当てはまるなら、8人が挙げた課題より重大な場合があります。
• バイアスへの認識。 リクルートのバイアス（インタビューしていないのは誰か）、誘導質問のバイアス（インタビューの台本を確認する）、生存者バイアス（現在のユーザーと離脱したユーザーの違い）を記録します。
• 必要最小限のサンプル。 定性調査では、通常、セグメントごとに5〜8件のインタビューを行うとテーマの飽和に達します。サンプル数がこのしきい値を下回る場合は、その旨を明記します。
• トライアンギュレーション。 複数の種類のデータを照合します。インタビュー、サポートチケット、アンケートデータで裏付けられたインサイトは、単一の情報源に基づくものより確かなものです。
• 継続的なディスカバリー。 インタビューの統合を一度限りのプロジェクトではなく、継続的な取り組みとして捉えます。毎週定期的にインタビューを行うことで、時間とともに顧客への深い理解が積み重なります。

関連スキル

• prd-writing -- 調査結果の統合をPRDの「背景」と「市場セグメント」のセクションに直接つなげます。
• competitive-analysis -- 顧客インサイトと競合データを組み合わせ、競合が十分に応えられていないジョブを特定します。
• feedback-synthesis -- インタビューのトランスクリプトに加え、チケットやNPSなどの構造化されたフィードバックデータがある場合に連携します。

例

例1：単一インタビューの要約

ユーザー： 「物流マネージャーとのディスカバリーインタビューのトランスクリプトです。要約してください。」

良い出力例：

メタデータ： 2026年3月10日 | Sarah Chen、MidCo（従業員150人）の物流マネージャー

現在のソリューション： Excelのスプレッドシートとメールのやり取りを組み合わせて、出荷を調整しています。満足度：3/10。「機能はしていますが、すべての情報を同期させておくのに、週に5時間ほど取られています。」

特定された問題：

• 出荷状況の信頼できる唯一の情報源がない（4回言及）
• ドライバーの空き状況をリアルタイムで確認できず、電話に頼っている
• 経営陣への報告には、毎週金曜日に手作業でデータをまとめる必要がある

主な発見： Sarahのチームは、リアルタイムの更新を共有するための回避策として、非公式のSlackチャンネルを作っています。これは調査計画では想定していなかったことで、ダッシュボード機能よりもメッセージング連携の優先度が高い可能性を示しています。

例 2：複数インタビューの統合

ユーザー：「B2B スケジューリングツールについて、顧客インタビューを 8 件終えたところです。こちらが書き起こしです。主な学びは何ですか？」

良い出力例：

JTBD #1（8 件中 7 件、確信度：高）：「3 つ以上のタイムゾーンにまたがって会議を調整するとき、全員の空き時間を 1 つの画面で確認したい。そうすれば、メールを 6 往復もやり取りせずに時間枠を予約できるからです。」

**インサイト：**複数のタイムゾーンにまたがるスケジュール調整こそが主なジョブであり、広く捉えたカレンダー管理ではないことがわかりました。つまり、「スマートカレンダー」ではなく「グローバルチームの調整」を前面に押し出すべきです。次のスプリントでは、タイムゾーンのオーバーレイ機能を優先すべきです。

**未解決の疑問：**参加者 8 人の中に、チームに属さない単独ユーザーはいませんでした。チームを持たない個人にとっても、このプロダクトに価値があるのかは、まだわかっていません。