feedback-synthesis

フィードバックの統合

使用するタイミング

創業者やプロダクトリードが、サポートチケット、NPS 調査、ユーザーインタビュー、アプリストアのレビュー、ソーシャルメディア、営業電話のメモ、機能リクエストのログ、スプレッドシート、CSV など、複数のソースからの顧客フィードバックを把握する必要がある場合に有効にします。「顧客フィードバックを分析して」「ユーザーから最も多く寄せられている要望は何？」「機能リクエストに優先順位を付けて」「このバックログをトリアージして」「サポートチケットにはどんなテーマが見られる？」といったプロンプトが該当します。

必要なコンテキスト

• startup-context から： プロダクトの種類、顧客セグメント、現在のプロダクトロードマップの優先事項、会社の成長段階、戦略目標、プロダクトの目的。
• ユーザーから： 生のフィードバックデータ（またはそのデータへのアクセス）、分析対象のソース、対象期間、優先順位付けの指針となるプロダクト目標や望ましい成果、この分析によって判断する内容。

ワークフロー

1. 目標を理解する -- 優先順位付けの指針となるプロダクトの目的と望ましい成果を確認します。戦略的な視点のないフィードバック分析は、シグナルではなくノイズを生みます。
2. 収集して正規化する -- すべてのソースからフィードバックを集めます。データが構造化形式（CSV、スプレッドシート）にある場合は、サマリーテーブルを作成します。各フィードバックを、ソース、日付、顧客セグメント、逐語的な引用、センチメントを含む1行として記録します。
3. テーマに分類する -- 関連するリクエストやフィードバックをまとめます。各テーマに名前を付けます。表面的な機能リクエストではなく、根底にある機会（問題）の特定に重点を置きます。
4. 戦略との整合性を評価する -- 各テーマが、提示されたプロダクト目標や会社の戦略とどの程度整合しているかを評価します。
5. Opportunity Score でスコアを付ける -- Opportunity Score フレームワーク（Dan Olsen）を使用します。Opportunity Score = 重要度 x（1 - 満足度）、0～1 の範囲に正規化します。これにより、最も重要でありながら、現在十分に対応できていない問題を優先できます。
6. 上位の機会に優先順位を付ける -- インパクト（顧客価値と影響を受けるユーザーの幅）、工数（必要な開発・デザインのリソース）、リスク（技術面および市場面の不確実性）、戦略との整合性（プロダクトビジョンとの適合度）に基づき、上位3つのテーマを選びます。
7. 上位項目を深掘りする -- 上位の機会ごとに、根拠、検討に値する代替ソリューション、リスクの高い仮説、最小限の工数でそれらの仮説を検証する方法を記録します。
8. 調査結果を提示する -- まずエグゼクティブサマリー、次に裏付けとなるデータ、最後に推奨アクションを示す構成で、体系的に統合した内容を提示します。

出力形式

統合レポートのテンプレート

# Customer Feedback Synthesis -- [Period]

## Executive Summary
3-5 key findings. Lead with the most surprising or actionable insight.

## Product Goal Alignment
The stated product objective and how feedback themes map to it.

## Theme Map
| Theme | Frequency | Segments Affected | Opportunity Score | Strategic Alignment | Priority |
|-------|-----------|-------------------|-------------------|---------------------|----------|
| [Theme] | [Count] | [Segments] | [Score] | [High/Med/Low] | [H/M/L] |

## Top 3 Opportunities (Deep Dives)
### Opportunity 1: [Theme Name]
- **Rationale:** Customer needs and strategic alignment
- **Representative quotes:** Direct user language
- **Alternative solutions:** Other ways to address this need
- **High-risk assumptions:** What must be true
- **Cheapest test:** How to validate with minimal effort

## Quick Wins
Actions that address frequent feedback with low implementation effort.

## Not Prioritized (and Why)
Themes explicitly deprioritized with reasoning.

## Appendix: Raw Data Summary
Breakdown by source, segment, and time period.

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

機能ではなく機会に注目する

顧客にソリューションを設計させてはいけません。機能ではなく、機会（問題）に優先順位を付けます。ユーザーが「ガントチャートが欲しい」と言った場合、根底にある機会は「プロジェクトのスケジュールを可視化して、関係者に進捗を伝えたい」である可能性があります。リクエストの裏にあるジョブ・トゥ・ビー・ダンを常に掘り下げます。

Opportunity Score（Dan Olsen）

各テーマをスコア化します。Opportunity Score = 重要度 x（1 - 満足度）、0～1 の範囲に正規化します。これにより、重要でありながら十分に対応できていない問題が明らかになります。重要度が高く満足度も高い領域は、すでに十分な対応ができているため、重要度が高く満足度が低いギャップより優先すべきではありません。

シグナルとノイズの判断基準

• 1人の顧客の意見だけではパターンとは言えません。 あるテーマをシグナルとして扱う前に、独立した3件以上の言及を求めます。例外：その1人が大口顧客で、解約リスクとして挙げている場合。
• 直近の意見への偏りを確認します。 最近、特定の問題について大量のフィードバックが寄せられると、継続的な問題が見えにくくなることがあります。必ず前の期間と比較します。
• 声の大きさは重要度と同じではありません。 パワーユーザーや声の大きい顧客は、フィードバックを不均衡に多く寄せる傾向があります。単純な件数ではなく、セグメントの規模と収益への貢献度で重み付けします。
• 称賛もデータです。 ユーザーが気に入っている点も記録します。自社の強みを把握しておけば、リデザインの際に誤って損なうことを防げます。

仮説の検証

最優先の機会ごとに、最もリスクの高い仮説を特定し、可能な限り低コストで検証する方法を設計します。プロトタイプ、アンケート、またはウィザード・オブ・オズ実験で検証できる仮説を確かめるために、完全なソリューションを構築してはいけません。

情報源ごとのガイダンス

情報源	強み	注意点
サポートチケット	シグナルが強く、具体的な問題がわかる	バグに偏り、満足しているユーザーを見落としやすい
NPS／アンケート	幅広く網羅でき、定量化できる	回答率が低いと結果に偏りが生じる
機能リクエストボード	整理されており、投票数を確認できる	パワーユーザーの投票が優勢になりやすい
営業電話のメモ	売上に近く、見込み顧客の視点がわかる	見込み顧客が、実際には使わない機能をリクエストすることがある
アプリストアのレビュー	公開されており、競合との比較を含む	否定的な内容に偏り、漠然とした不満が多い
ソーシャルメディア	率直で、リアルタイム	ノイズが多く、セグメント分けが難しい

よくある間違いを避ける

• 既存の仮説を支持する都合のよい引用だけを選ぶ。相反するフィードバックも含め、全体の分布を示します。
• 頻度と重要度を混同する。ユーザーが我慢している高頻度の不便より、解約につながる低頻度の問題のほうが重要です。
• 推奨事項を示さずにデータだけを提示する。アクション項目のないテーママップは、統合分析ではなくレポートです。必ず次に何をすべきかを最後に示します。
• 声を上げない多数派を無視する。苦情を言わないユーザーは、満足している場合も、関与していない場合もあります。セグメント分析によって両者を見分けられます。

関連スキル

• user-research-synthesis -- フィードバック分析で、インタビューやユーザビリティテストなど、個別のユーザー調査が必要なギャップが見つかった場合に連携します。
• churn-analysis -- フィードバックのテーマが解約パターンと相関し、より深いリテンション分析が必要な場合に連携します。
• prd-writing -- 統合分析から明確な機会が見つかり、PRDに落とし込む必要がある場合に連携します。

例

例 1：機能リクエストの優先順位付け

ユーザー：「機能リクエストボードには150件あります。次の四半期に何を開発すべきか、一緒に考えてください。」

良い出力の抜粋：

エグゼクティブサマリー： 150件のリクエストは9つのテーマに分類できます。最大の機会は、最もリクエスト数の多い機能（SSO、34票）ではなく、ニーズが最も満たされていない「共有ドキュメントでのリアルタイム共同作業」です（機会スコア：0.82）。SSOのスコアは低く（0.45）、既存の回避策でほとんどのユーザーのニーズを十分に満たせているためです。

機会 1：リアルタイム共同作業

• 根拠： 4つのセグメントで22件のリクエストがあります。ARR 85Kドル相当のエンタープライズ案件3件で、導入拡大の障壁として挙げられています。現在の満足度：2/10。
• 代替ソリューション： (a) 完全なリアルタイム編集、(b) 軽量なコメント機能とプレゼンスインジケーター、(c) 通知機能付きの非同期レビューワークフロー
• リスクの高い仮説： ユーザーが求めているのは、他のユーザーによる変更を把握することだけではなく、同時編集である
• 最も低コストな検証方法： プレゼンスインジケーターのみ（ドキュメントを閲覧している人を表示）を追加し、共同作業に関するチケットが減るかを測定する

例 2：複数の情報源を統合

ユーザー：「先月分のサポートチケットが200件、NPSの回答が50件、顧客インタビューのメモが10件あります。顧客はどんなことを伝えていますか？」

良い出力の抜粋：

テーマ 1：大規模なデータセットでCSVエクスポートが機能しない（機会スコア：0.91）

• サポートチケット47件、NPSの推奨者ではない回答8件、インタビュー3件。ユーザーは1万行の上限に達すると、エクスポートを手作業で分割して回避しています。
• 戦略との整合性： 高い -- データエクスポートは「オープンプラットフォーム」という当社のポジショニングの中核です。
• 最も低コストな検証方法： 不要です。明らかなバグ／制限事項なので、直接修正します。
• すぐできる改善： CSVエクスポートの上限を10万行に引き上げます（エンジニアリングの見積もり：2日）。