user-research-synthesis について
プロダクト、デザイン、リサーチチーム向けのユーザーリサーチ統合スキルです。インタビュー、アンケート、ユーザビリティ調査をテーマや課題、提案に整理し、根拠と不確実性を明示します。
主な機能
- 01調査概要とテーマの構造化
- 02課題、要望、ワークフローの分析
- 03セグメント、競合、優先度の整理
- 04根拠、矛盾、調査ギャップの確認
活用シーン
- 01インタビューから参加者横断のテーマを抽出
- 02アンケート結果から課題やニーズを特定
- 03調査根拠に基づくプロダクト提案
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mohitagw15856/ pm-claude-skills --skill user-research-synthesisインストール後、Claude Code で/user-research-synthesisを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/theme-validity.mdworked-example.mdtemplates/synthesis-report.md詳細
ユーザー調査の統合スキル
このスキルでは、構造化された手法に沿ってユーザー調査データを分析し、実行可能なインサイトへと変換します。
必要な入力
与えられた情報をもとに進めてください。以下のいずれかが欠けていても、完全な出力を作成してください。不足部分は妥当な仮定で補い、(仮定、要確認) と記して、最後に仮定の一覧を示してください。調査の中心的なテーマ自体が欠けている場合(書く内容がない場合)に限り、最初に質問してください。
- 調査データ(インタビューの記録、メモ、アンケート結果、要約の箇条書きなど)
- 調査手法(インタビュー、アンケート、ユーザビリティテストなど)
- 参加者数とそのプロフィール(役割、状況)
- 調査の質問(この調査で明らかにしようとしたこと)
Brain からの読み込み/Brain への書き込み
professional-brain(brain/)が存在する場合は、質問する前に参照してください。
- 最初に読む:
hypotheses/(この調査で検証または反証できる仮説)とcontext.md(ユーザーについて)を開きます。 - 完了後に書き込む: 関連する各仮説のステータスを更新し、長期的に有用なインサイトを
knowledge/users.mdに追加し、生のメモはsource/に保管します。インタビューから導いた主張には[interview]のタグを付け、決して[data]にすり替えないでください。
統合フレームワーク
1. データ収集の概要
- 調査の種類:インタビュー、アンケート、ユーザビリティテストなど
- 参加者のプロフィール:デモグラフィック、セグメント、サンプル数
- 調査の質問:明らかにしようとしたこと
- 調査方法:データの収集方法
2. 主要なテーマの特定
次の構成で調査結果をテーマごとに整理します。
テーマ名
- 説明:このテーマが表す内容
- 該当者数:このテーマに言及した参加者数(例:「12人中8人」)
- 裏付けとなる発言:代表的な引用を2~3件
- 示唆:このテーマが製品にとって意味すること
調査ごとに、主要なテーマを4~8件挙げることを目指します。
3. ペインポイントの分析
特定したペインポイントごとに、以下を記載します。
- ペインポイント:明確な説明
- 深刻度:高/中/低(影響度と頻度に基づく)
- 現在の回避策:ユーザーが現状どのように対処しているか
- 根拠:調査で得られた具体例
4. 機能リクエスト
リクエストを分類します。
- 必須:ユーザーの成功を妨げている重要なニーズ
- 価値が高い:体験を大幅に向上させるもの
- あるとよい:段階的な改善
リクエストごとに、以下を記載します。
- リクエスト:ユーザーが求めたもの
- 頻度:どのくらい挙がったか
- ユーザーの発言:代表的な例
- 根底にあるニーズ:ユーザーがそれを求める理由(表面的な要望より深く掘り下げる)
5. ユーザーワークフローに関するインサイト
実際に観察されたワークフローを記録します。
- 現状:ユーザーが現在どのようにタスクを達成しているか
- ペインポイント:どこで苦労しているか
- 理想の状態:ユーザーが実現したいこと
- 機会:価値を提供できる領域
6. セグメンテーションに関するインサイト
調査から異なるユーザーセグメントが明らかになった場合は、以下を記載します。
- セグメント名:特徴を表す名称
- 特性:このセグメントを定義する要素
- 固有のニーズ:ニーズがどのように異なるか
- 規模/重要度:優先順位付けにおける相対的な重み
7. 競合に関するインサイト
ユーザーが競合製品や代替手段に言及した場合は、以下を記載します。
- 競合製品/代替手段:ユーザーが利用しているもの
- 利用する理由:優れている点
- 不足している点:対応できていないこと
- 乗り換えの障壁:完全には乗り換えない理由
8. 推奨事項
インサイトに基づき、推奨事項に優先順位を付けます。
優先度:高
- 根拠を添えた推奨事項
- 期待される影響
優先度:中
- 根拠を添えた推奨事項
- 期待される影響
優先度:低/今後の検討事項
- 根拠を添えた推奨事項
- 期待される影響
9. 未解決の質問
特定された調査の不足事項:
- まだ理解が必要なこと
- 推奨する追加調査
- 検証が必要な不確実性
分析ガイドライン
インタビューを統合する際:
- 複数の参加者に共通するパターンを探します
- ユーザーの発言と行動の両方に注目します
- 感情的な反応に注意を払います
- 機能リクエストだけでなく、達成すべきジョブを特定します
引用を分析する際:
- 「引用符」で原文どおりの引用を使用します
- 引用には出典を付記します:[参加者 ID、役割、コンテキスト]
- 例外的な意見ではなく、パターンを示す引用を選びます
- 肯定的なフィードバックと否定的なフィードバックの両方を含めます
テーマを特定する際:
- 汎用的なラベルではなく、内容を表す名前を付けます
- 各テーマの根拠を示します
- 可能な場合は定量化します(「ユーザー 10 人中 7 人が……」)
- テーマをビジネス目標に結び付けます
詳細資料
このスキルには、利用可能な場合に使用できるサポートファイルが含まれています。
references/theme-validity.md— テーマが本物といえるのはどんなときか?統合の妥当性に関するルール。出力を作成する際に適用してください。ここには、上記の手法の概要で簡略化されている判断基準や調整方法が記載されています。templates/synthesis-report.md— 品質チェック項目が組み込まれた、記入式の成果物テンプレート。生成を依頼するのではなく、自分で文書を作成したいユーザーに提供してください。
評価基準(0~40)
このスキルの出力は、引き渡す前に採点してください。32 点以上が納品可能な品質です。
| 評価項目 | 0 | 5 | 10 |
|---|---|---|---|
| 根拠の厳密さ | 主張に根拠がなく、参加者数や引用がない。引用に出典がなく、または出現率が曖昧(「多くのユーザー」) | ほとんどのテーマは定量化されているが、一部の引用に出典がない、または出現率が曖昧 | すべてのテーマでデータに基づく出現率(「12 人中 8 人」)を示し、パターンを示す出典付きの引用を 2~3 件含める |
| 統合の深さ | 個々のコメントの羅列を、調査結果らしく見せている | 参加者をまたぐ実際のテーマはあるが、1~2 件の個人のエピソードをテーマとして扱っている | 参加者をまたぐ真のパターンが 4~8 件ある。例外的な意見は例外として示し、表明された意見だけでなく、発言と行動の食い違いも捉えている |
| 意思決定との関連性 | 含意がない観察結果に終始し、データを見て回るだけ | 含意はあるが、「オンボーディングを改善する」のように一般的で、優先度や期待される効果が示されていない | 各テーマが影響するプロダクト上の意思決定を明示し、根拠、期待される効果、労力に基づいて推奨事項に優先順位を付けている |
| 矛盾と不足に関する誠実さ | 都合のよい内容だけを示し、矛盾や不確実性が見えない | 相反するデータには触れているが、掘り下げていない。解釈と観察結果が曖昧に混在している | 矛盾する調査結果を明らかにし、解決に向けた手順を示している。観察結果と解釈を明確に分け、未解決の質問には担当者を明記したフォローアップを設定している |
品質チェック
- テーマが個々の回答ではなく、複数の参加者に共通するパターンを特定している
- インサイトが単なる観察にとどまらず、具体的なプロダクト上の意思決定に結び付いている
- それぞれの主張に裏付けとなる根拠(引用、人数、事例)が含まれている
- 観察結果と解釈が明確に分けられている
- 調査結果が列挙されるだけでなく、影響度に基づいて優先順位が付けられている
よくある失敗パターン
- 個々のコメントをすべて列挙しないでください。統合では、参加者をまたぐパターンを特定する必要があります
- データによる裏付けなしに、解釈を飛躍させないでください
- 根本的な問題を理解する前に機能リクエストに注目しないでください。まず、達成すべきジョブを特定してください
- 相反するデータを無視しないでください。矛盾する調査結果は明らかにして記録する必要があります
- 出現率を定量化せずに結果を示さないでください。それぞれの見解を持つ参加者の人数を明記してください
テーマの例
**Theme: Information Overload During Onboarding**
**Description**: Users consistently expressed feeling overwhelmed by the amount of information presented during initial setup, leading to incomplete onboarding and delayed time-to-value.
**Prevalence**: 9 out of 12 participants mentioned this issue unprompted
**Supporting Quotes**:
- "I just wanted to get started, but it felt like I needed to read a manual first" [P3, Marketing Manager]
- "By the third screen of instructions, I started clicking 'Next' without reading" [P7, Sales Rep]
- "I wish there was a 'quick start' option for people like me who just want to try it" [P11, Product Designer]
**Implication**: Our current onboarding flow prioritizes completeness over engagement. We should consider a progressive disclosure approach where users can start using the product quickly and learn advanced features contextually.
**Recommended Action**:
- Design a "Quick Start" path that gets users to first value in <3 minutes
- Move advanced configuration to contextual help within the app
- Test with 5-10 new users before full rollout
- Expected impact: +20-30% activation rate improvement
テンプレートの出力構成
調査結果を統合する際は、次の構成を使用してください。
# User Research Synthesis: [Research Topic]
## Research Overview
- **Date**: [Date range]
- **Methodology**: [Interview/Survey/Testing]
- **Participants**: [Number] [User types]
- **Research Questions**:
1. [Question 1]
2. [Question 2]
3. [Question 3]
## Executive Summary
[2-3 sentence overview of key findings and implications]
## Key Themes
### Theme 1: [Theme Name]
[Full theme documentation as shown in example above]
### Theme 2: [Theme Name]
[Full theme documentation]
[Continue with 4-8 themes]
## Pain Points Summary
| Pain Point | Severity | Frequency | Current Workaround |
|------------|----------|-----------|-------------------|
| [Pain 1] | High | 10/12 users | [How they cope] |
| [Pain 2] | Medium | 7/12 users | [How they cope] |
## Feature Requests
### Must-Have
1. **[Request]** - Mentioned by [X] participants
- Quote: "[Representative quote]"
- Underlying need: [Why they want this]
### High Value
[Similar structure]
### Nice-to-Have
[Similar structure]
## Recommendations
### High Priority (0-3 months)
1. **[Recommendation]**
- Supporting evidence: [Data from research]
- Expected impact: [What will improve]
- Effort estimate: [Rough sizing]
### Medium Priority (3-6 months)
[Similar structure]
### Future Consideration (6+ months)
[Similar structure]
## Open Questions
1. [Question requiring more research]
2. [Uncertainty to validate]
3. [Follow-up study needed]
## Appendix
- Interview guide used
- Full participant demographics
- Raw notes/transcripts (link)
トリガーフレーズの例
- 「これらのインタビュー記録を統合してください。」
- 「アンケート結果を分析してください。」
- 「このユーザーフィードバックからテーマを見つけてください。」
- 「このユーザー調査を要約してください。」