analyzing-user-feedback

ユーザーフィードバックの分析

対象範囲

対象

• 複数のチャネル（サポート、営業、リサーチ、レビュー、アンケート、利用状況のシグナル）からのフィードバックを集約し、正規化する
• 生のフィードバックを、根拠を伴うテーマと実行可能な提案にまとめる
• 摩擦や、ユーザーが製品を使わない理由を特定する（単なる妥当性の確認にとどめない）
• 繰り返し実施できるフィードバックループ（頻度、担当者、引き継ぎ）を作る

利用する場面

• 「ユーザーフィードバックをテーマとアクションにまとめてください」
• 「サポートチケット／機能リクエストを分析して、主要な課題を特定してください」
• 「過去の に関する のカスタマーボイスレポートを作成してください」
• 「解約理由／キャンセルに関するフィードバックを要約してください」
• 「アンケートの自由回答を分類し、インサイトと提案にまとめてください」

利用しない場面

• まず新しいフィードバックを収集する必要がある場合（conducting-user-interviews／designing-surveys を使用してください）
• バックログの優先順位付けを主な成果物とする場合（prioritizing-roadmap を使用してください）
• 選定したソリューションの PRD／仕様書が必要な場合（writing-prds／writing-specs-designs を使用してください）
• 個別のチケットに返信するだけの場合（統合分析ではなく、サポートのワークフローです）

入力

最低限必要な情報

• 分析対象の製品領域／ワークフロー（または「製品全体」）
• 対象期間と想定件数（例：「過去90日間」、「約2,000件のチケット」）
• 利用可能なフィードバックソース（チケット、インタビュー、営業メモ、レビュー、アンケート、コミュニティ、ログ）
• この分析を役立てる意思決定（ロードマップのテーマ、ローンチ準備状況、オンボーディングの改善、メッセージング、品質）
• 重要なセグメント（ICP、ペルソナ、プランの階層、ライフサイクルの段階）
• 制約：プライバシー／PII のルール、社内限定か共有可能か、期限／作業時間の上限

情報不足時の対応

• references/INTAKE.md から最大5つの質問をします。
• データへのアクセスが限られている場合は、小規模で代表性のあるサンプルを使って進め、信頼度や制約を明記します。
• 秘密情報は求めません。フィードバックに PII が含まれる場合は、個人情報を伏せた抜粋または集計済みの項目のみを依頼します。

成果物

Markdown 形式のユーザーフィードバック分析パックを作成します（チャット内、または依頼があればファイルとして作成します）。

1. コンテキストの概要（対象範囲、意思決定、対象期間、セグメント、制約）
2. ソース一覧とサンプリング計画（対象／対象外とその理由）
3. 分類体系とコードブック（タグ、定義、コーディングルール）
4. 正規化されたフィードバック表（タグ付けされた項目。利用可能な場合はリンク／IDを記載。PII は含めない）
5. テーマと根拠のレポート（主要なテーマ、代表的な引用、頻度／深刻度、信頼度）
6. 提案（アクション、担当者／期間の目安〔判明している場合〕、期待される効果、今後の調査課題）
7. フィードバックループ計画（頻度、関係者、エンジニアリングの参加方法、インサイトの保存方法）
8. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md

ワークフロー（8ステップ）

1) インテークと意思決定の整理

• 入力： ユーザーの状況。references/INTAKE.md。
• アクション： 意思決定、対象範囲、対象期間、対象者、制約を確認します。「何をもって成功とするか」を定義します。
• 成果物： コンテキストの概要。
• 確認事項： 関係者が「この分析によって、どのような意思決定が変わるのか？」に答えられること。

2) ソースを一覧化し、サンプリング計画を定義する

• 入力： ソースの一覧とアクセス上の制約。
• アクション： ソース一覧を作成し、対象／対象外を決定して、サンプル抽出方法（ランダム、層化、件数上位のカテゴリ）を選びます。
• 成果物： ソース一覧とサンプリング計画。
• 確認事項： サンプリング計画が、件数の多いセグメントとリスクの高いセグメントを網羅していること（そうでない場合は、その理由を明示すること）。

3) 最初の通読（オープンコーディング）

• 入力： 抽出したフィードバック項目。
• アクション： 項目を手作業で読み、注釈を付けて、何が「問題」なのか、なぜユーザーが困ったり離脱したりするのかを明らかにします。分類を作る前に、生のメモを記録します。
• 成果物： 初期コード／メモとテーマ候補の一覧。
• 確認事項： メモに、機能のアイデアだけでなく、利用しない理由と摩擦が記録されていること。

4) 分類体系とコードブックを作成する

• 入力: 初期コード、製品のコンテキスト。
• 作業: タグ付けスキーマ（トピック、ライフサイクルの段階、重大度、ユーザーセグメント、根本原因、感情）を定義します。タグの定義とルールを明確に記述します。
• 成果物: 分類体系とコードブック。
• 確認事項: 2 人がコードブックを使って同じ項目に同様のタグを付けられること。

5) フィードバックテーブルを正規化してタグ付けする

• 入力: 生の項目、分類体系／コードブック。
• 作業: 正規化されたテーブルを作成し、各項目にタグを付け、証拠となるフィールド（情報源、日付、セグメント、原文の抜粋、リンク／ID）を記録します。
• 成果物: 正規化されたフィードバックテーブル（タグ付け済み）。
• 確認事項: PII が含まれていないこと。すべての行に、少なくとも 1 つの主要テーマタグと、重大度／影響を示すシグナルがあること。

6) テーマを統合し、慎重に定量化する

• 入力: タグ付け済みのテーブル。
• 作業: 上位テーマを要約し、セグメント／情報源ごとの頻度を定量化し、重大度と「発生する理由」を特定して、不明点やバイアスを明示します。
• 成果物: 信頼度レベル付きのテーマと証拠のレポート。
• 確認事項: 各テーマに代表的な証拠（引用／例）が含まれ、純粋な推測に基づいていないこと。

7) アクションと学習計画に落とし込む

• 入力: テーマのレポート、制約条件。
• 作業: テーマをアクション（バグ修正、UX の改善、コミュニケーション、製品への投資判断）と未解決の質問（次に何を調査するか）に変換します。各アクションを証拠と期待される影響に結び付けます。
• 成果物: 推奨事項と学習計画。
• 確認事項: 推奨事項が次のスプリント／四半期に実行できるほど具体的であること（判明している場合は、担当者と期間が明確であること）。

8) 共有し、フィードバックループと品質ゲートを確立する

• 入力: ドラフト一式。
• 作業: 共有形式（ドキュメントとレビュー）を提案します。実施頻度、担当者、保存場所（インサイトの保管場所）を定義します。references/CHECKLISTS.md を実施し、references/RUBRIC.md に基づいて採点します。リスク／未解決の質問／次のステップを追加します。
• 成果物: 最終版ユーザーフィードバック分析パック。
• 確認事項: パックがそのまま共有できること。制約が明示されていること。フォローアップのアクションが予定されていること。

品質ゲート（必須）

• references/CHECKLISTS.md と references/RUBRIC.md を使用します。
• 必ず含める項目: リスク、未解決の質問、次のステップ。

例

例 1（サポートチケット）: 「直近 60 日間のオンボーディング関連チケットを分析してください。ユーザーフィードバック分析パックと、推奨修正事項の上位 10 件を出力してください。」 期待される内容: 情報源の一覧とサンプリング、分類体系、タグ付け済みのテーブル、引用付きのテーマ、優先順位を付けたアクション。

例 2（アンケートとレビュー）: 「新しい価格改定について、アンケートの自由回答とアプリストアのレビューを統合してください。最大の摩擦点と、その原因は何ですか？」 期待される内容: 情報源／セグメント別のテーマ、重大度を示すシグナル、推奨事項（メッセージング／UX の変更を含む）。

境界の例: 「すべてのフィードバックを読んで、次に何を作るべきか教えてください。」 応答: スコープ／期間／判断事項とサンプルデータセットの提示を求めます。それが得られない場合は、サンプリング計画と、制約を明示した最小限の初回統合結果を提示します。