mcpField
D
discover-interview-synthesis

discover-interview-synthesis

github.com/product-on-purposeデザイン・UI769776 回インストール4 日前に更新
リポジトリ

discover-interview-synthesis について

インタビューのメモ、文字起こし、録音を、根拠に基づくテーマ、インサイト、提案へまとめるリサーチスキルです。参加者の背景、引用の出典、調査の限界も記録します。

主な機能

  1. 01参加者のプロフィール整理
  2. 02反復するテーマの特定
  3. 03出典付きの逐語引用
  4. 04インサイトと提案の統合
  5. 05調査の限界と偏りの記録

活用シーン

  1. 01完了したインタビュー調査の統合
  2. 02顧客開発や営業フィードバックの整理
  3. 03関係者向け調査結果の要約
  4. 04アイデア創出前のユーザー調査整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill discover-interview-synthesis

インストール後、Claude Code で/discover-interview-synthesisを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

HISTORY.md
evals/
trigger-fixtures.json
evals/output-scenarios/
onboarding-interviews.md
references/
EXAMPLE.md
TEMPLATE.md

詳細

インタビューの統合

インタビューの統合では、生のユーザーリサーチデータを、プロダクトの意思決定に役立つ構造化されたインサイトへと変換します。参加者の発言を単に列挙するのではなく、優れた統合では、会話全体に見られるパターンを特定し、観察結果を根底にあるユーザーニーズに結びつけ、調査結果を実行可能な提案へと落とし込みます。

使用するタイミング

  • ユーザーインタビューを一巡実施した後(通常は参加者が5人以上)
  • 顧客発見のための通話や、営業からのフィードバックセッションの後
  • 観察結果をまとめるためのユーザビリティテストセッションの後
  • ステークホルダーが調査結果の要約を必要としているとき
  • チームがユーザーの実態を踏まえてアイデア創出セッションを行う前

使用しないタイミング

  • 参加者向けに社内会議を1件要約する場合 → foundation-meeting-recap を使用します
  • 複数の会議にわたる時間の経過に伴うパターンが必要な場合 → foundation-meeting-synthesize を使用します
  • データがインタビューではなくアンケート回答である場合 → measure-survey-analysis を使用します
  • 調査結果を統合済みで、問題の枠組みを定める準備ができている場合 → define-problem-statement を使用します
  • 統合した調査結果を、段階やタッチポイントに沿った顧客のジャーニーに当てはめたい場合 → discover-journey-map を使用します

手順

インタビューの調査結果を統合するよう依頼された場合は、以下の手順に従います。

  1. 生データを集める インタビューのメモ、書き起こし、録音をすべて集めます。意味のあるパターンを特定できるよう、少なくとも3人の参加者のデータがあることを確認します。調査の目的と使用した手法を記録します。

  2. 参加者プロフィールを作成する 各参加者について、役割、セグメント、在籍期間、特筆すべき特徴など、関連する背景情報を記録します。これにより、読者が調査結果の代表性を判断しやすくなります。

  3. 繰り返し現れるテーマを特定する すべてのメモに目を通し、トピックごとに観察結果をタグ付けします。複数の参加者(理想的には3人以上)に共通するテーマを探します。頻繁に言及されたトピックと、一度だけ出たコメントを区別します。

  4. 意味のある引用を抜き出す インサイトを力強く示す、テーマごとの逐語的な引用を3~5件記録します。優れた引用は具体的で、感情が表れているか、特に明瞭に表現されています。引用には必ず参加者IDを付けます。

  5. インサイトへと統合する テーマをインサイトの記述へと変換します。インサイトは観察(「ユーザーはXと言及した」)にとどまらず、解釈(「ユーザーにはZが理由でYが必要」)を示します。聞き取った内容を、それが重要な理由に結びつけます。

  6. 提案をまとめる インサイトに基づいて、優先順位を付けたアクションを提案します。各提案は、特定のインサイトに直接結びつけます。エビデンスの強さに基づいて確信度を記載します。

  7. 制約事項を記録する 分からなかったこと、サンプルの偏り、追加調査が必要な領域を明らかにします。制約事項を率直に示すことで、信頼性が高まります。

プロジェクトメモリの取り決め

.claude/pm-skills.local.md が存在する場合にのみ有効です。ファイルがない場合は、このセクションを完全に無視し、 上記の説明どおりに動作します。

  • 読み取り: phase と active_initiative を読み取り、取り組み中のイニシアチブを踏まえて調査結果をまとめます。ユーザーにイニシアチブを再度説明するよう求める必要はありません。
  • 書き込み: ペルソナと調査結果を interpretation アーティファクトとして書き込み、後続のスキルが再度貼り付けなくても参照できるようにします。
  • 進め方: memory_auto_append: true が設定されていない限り、書き込み前に追記内容を提示し、確認を待ちます。設定されている場合は追記し、書き込んだ内容を表示します。
  • 書き込みの規律: 書き込む直前にファイルを再読み込みします。提案の作成に使ったコピーから書き込んではいけません。その間に内容が変更されていた場合は、現在の状態に自分の項目を統合し、上書きするのではなく再度提案します。自分の項目だけを追加し、それ以外のすべてのフィールドとセクションはバイト単位で同一のまま維持します。実行時にこれを強制する仕組みはなく、ファイルは Git の対象外であるため、ファイル全体を書き込むと、他のセッションの作業を復元不能な形で失うおそれがあります。

これは、このコホートが実証するループにおける書き込み側です。このスキルが記録した内容を、後から deliver-prd が読み取ります。

出力形式

references/TEMPLATE.md のテンプレートを使用して、出力を構成してください。完全な統合では、テンプレートのすべてのセクションを埋めます:調査の概要、主要なテーマ、注目すべき引用、インサイト、推奨事項、付録。

品質チェックリスト

最終版を作成する前に、次の項目を確認してください。

  • テーマは3人以上の参加者の証拠によって裏付けられている
  • 引用は逐語的で、参加者IDが記載されている
  • インサイトでは「何が」だけでなく「なぜ」を説明している
  • 推奨事項は具体的で、実行可能である
  • 参加者の身元が保護されている(個人を特定できる情報を含めていない)
  • 制約とバイアスが認識されている

例

完成例は references/EXAMPLE.md を参照してください。

コメント