公式スキル · プロダクト
ユーザーインタビューのまとめ
インタビューのメモを、参加者数つきのテーマ、発言、ジョブ（Jobs to Be Done）、インサイトと仮説の区別、確信度つきの提案にまとめる。
Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。
使う場面
- ユーザーインタビューやディスカバリーの通話を3件以上終え、パターンを知りたいとき
- プロダクトの判断の前に、チームから「何がわかったか」を聞かれたとき
AI に渡すもの
- 参加者ごとのインタビューの書き起こしかメモ
- リサーチクエスチョン
- 参加者のセグメント（任意）
できあがるもの
主な発見、人数と発言つきのテーマ、ジョブ（Jobs to Be Done）、インサイトの表、確信度つきの提案をまとめたリサーチ結果。
手順
- 観察をひとつずつ抜き出す 観察ひとつ ＝ 参加者ひとりについての事実ひとつ。したこと、感じたこと、言ったこと、使ったもの。それぞれに参加者と、行動（「した」）、意見（「言った」）、要望（「ほしい」）のどれかをつける。いちばん強い兆候は過去の行動で、いちばん弱いのは要望。
- テーマにまとめる NN/g が説明する親和図法に沿う。まず中身でまとめ、名前はあとでつける。クラスターの数を決めつけない。両方に当てはまる観察は2つのクラスターに入れてよい。同じ根っこのニーズや困りごとを語っている観察をまとめる。テーマの名前は、話題（「モバイル」）ではなく、ユーザーの側から見た言い切りにする（「経営者は毎日スマホで入金を確認している」）。
- テーマごとに参加者を数える 「8人中5人」と書く。このスキルの決まりとして、テーマには2人以上が必要。ひとりだけの観察は「注視したいこと」に置く。ひとつのセグメントからしか出ていないテーマは、そう書く。
- 発言を選ぶ テーマごとに、そのままの発言を1〜2つ、参加者のラベルつきで引用する。言葉どおりに引用する。メモが言い換えなら「（要約）」と書く。
- ジョブを書く ジョブとは、ある状況で人が進めようとしている前進のこと（Christensen Institute）。データに表れていれば、機能面、社会面、感情面も含める。上位のテーマについて「[状況]のとき、[動機]したい。そうすれば[結果]できる」と書く。機能の要望ではなく、観察した行動をもとにする。
- インサイトと仮説を分ける インサイトは、2人以上の参加者の行動で裏づけられたもの。インタビュー前からチームが信じていて、データで確かめられていないものは仮説のまま残す。反対の証拠は隠さずに並べる。
- 確信度つきで提案する 提案はどれもテーマにひもづけ、ユーザーから担当者を聞いていれば名前を書き、このスキルの既定の尺度で確信度をつける。高（参加者の半数以上の行動）、中（複数の参加者、ただし多くは「した」ではなく「言った」）、低（参加者が少ないか、ひとつのセグメントだけ）。確信度を上げるには何を調べればよいかを書き添える。
SKILL.md の全文
AI が読むファイルそのものです。 ダウンロード
---
name: user-interview-synthesis
description: 複数のユーザーインタビューの書き起こしやメモを、ひとつずつの観察、参加者数つきの親和図のテーマ、裏づけの発言、ジョブ（Jobs to Be Done）、仮説と区別したインサイト、確信度つきの提案にまとめる。顧客インタビューのメモ、リサーチの通話の書き起こし、ディスカバリーの通話を渡されて、ユーザーが何を言っていたか、テーマ、パターン、インサイト、リサーチ結果のまとめを頼まれたときに使う。
---
# ユーザーインタビューのまとめ
まとめが役に立つのは、何人がそう言ったのか、本人の言葉で何と言ったのか、チームがどこまで確信してよいのかが読み手に見えるときだ。数えるのは言及の回数ではなく人数。ユーザーが実際にしたことと、すると言ったことを分ける。声の大きいひとりのインタビューを、テーマにしない。
## 使う場面
- ユーザーインタビュー、ディスカバリーの通話、ユーザビリティテストを3件以上終えたあと。
- チームに「何がわかったか」を聞かれたときや、判断の前に結果のまとめが必要なとき。
- インタビュー1件には使わない（call-summary-crm-notes か meeting-minutes を使う）。大量の問い合わせやアンケートの自由記述には使わない（feedback-themes を使う）。
## 用意するもの
- 参加者ごとの書き起こしかメモと、参加者のラベル（P1、P2 か仮名）。
- インタビューで答えを出したかった問い（リサーチクエスチョン）。なければ一度だけ聞き、それでもなければ推測して「[仮定: リサーチクエスチョン]」と書く。
- 任意: 参加者ごとのセグメント（役職、会社の規模、プラン）。テーマをセグメント別に分けられる。
## 手順
1. **観察をひとつずつ抜き出す。** 観察ひとつ ＝ 参加者ひとりについての事実ひとつ。したこと、感じたこと、言ったこと、使ったもの。それぞれに参加者と、行動（「した」）、意見（「言った」）、要望（「ほしい」）のどれかをつける。いちばん強い兆候は過去の行動で、いちばん弱いのは要望。
2. **テーマにまとめる。** NN/g が説明する親和図法に沿う。まず中身でまとめ、名前はあとでつける。クラスターの数を決めつけない。両方に当てはまる観察は2つのクラスターに入れてよい。同じ根っこのニーズや困りごとを語っている観察をまとめる。テーマの名前は、話題（「モバイル」）ではなく、ユーザーの側から見た言い切りにする（「経営者は毎日スマホで入金を確認している」）。
3. **テーマごとに参加者を数える。** 「8人中5人」と書く。このスキルの決まりとして、テーマには2人以上が必要。ひとりだけの観察は「注視したいこと」に置く。ひとつのセグメントからしか出ていないテーマは、そう書く。
4. **発言を選ぶ。** テーマごとに、そのままの発言を1〜2つ、参加者のラベルつきで引用する。言葉どおりに引用する。メモが言い換えなら「（要約）」と書く。
5. **ジョブを書く。** ジョブとは、ある状況で人が進めようとしている前進のこと（Christensen Institute）。データに表れていれば、機能面、社会面、感情面も含める。上位のテーマについて「[状況]のとき、[動機]したい。そうすれば[結果]できる」と書く。機能の要望ではなく、観察した行動をもとにする。
6. **インサイトと仮説を分ける。** インサイトは、2人以上の参加者の行動で裏づけられたもの。インタビュー前からチームが信じていて、データで確かめられていないものは仮説のまま残す。反対の証拠は隠さずに並べる。
7. **確信度つきで提案する。** 提案はどれもテーマにひもづけ、ユーザーから担当者を聞いていれば名前を書き、このスキルの既定の尺度で確信度をつける。高（参加者の半数以上の行動）、中（複数の参加者、ただし多くは「した」ではなく「言った」）、低（参加者が少ないか、ひとつのセグメントだけ）。確信度を上げるには何を調べればよいかを書き添える。
## 出力の形式
```markdown
# インタビューのまとめ: [リサーチクエスチョン]
**参加者:** [n]人（[セグメント]） · **期間:** [日付の範囲] · **インタビュアー:** [名前]
## 主な発見
1. [テーマの言い切り] — [n人中x人]
2. [テーマの言い切り] — [n人中x人]
3. [テーマの言い切り] — [n人中x人]
## テーマ
### [テーマの言い切り] — [参加者n人中x人]
- **根拠:** [観察。した / 言った / ほしい と参加者のラベルつき]
- **発言:** 「[発言]」 — [P#]
- **セグメント:** [すべて、またはどれか]
## ジョブ（Jobs to Be Done）
- [状況]のとき、[動機]したい。そうすれば[結果]できる。（[テーマ]）
## インサイトと仮説
| 内容 | 位置づけ | 根拠 |
|---|---|---|
| [内容] | インサイト / 仮説 / 反証あり | [参加者と種類] |
## 提案
| 提案 | もとにしたもの | 確信度 | 確信度を上げるには |
|---|---|---|---|
| [アクション] | [テーマ] | 高 / 中 / 低 | [次のリサーチ] |
## 注視したいこと
- [ひとりだけの観察] — [P#]
```
## 例
**入力（要約したメモ、請求書の催促についてのインタビュー4件）:**
> P1（制作会社の経営者）: 毎週金曜、スプレッドシートを見ながら支払いの遅れている請求書を催促している。「嫌な役回りをするのが本当に嫌」
> P2（フリーランス）: 催促はメールではなく、スマホから LINE で送る。自動のリマインドがほしい。
> P3（制作会社の経営者）: 催促は経理担当に任せている。月末まで、誰の支払いが遅れているか知らなかった。
> P4（フリーランス）: 同じ催促メールをコピーして貼りつけている。「失礼に聞こえないように、毎回やわらかく書き直している」
**出力:**
```markdown
# インタビューのまとめ: 小規模なサービス業は、支払いの遅れた請求書をどう催促しているか
**参加者:** 4人（制作会社の経営者2人、フリーランス2人） · **期間:** [日付] · **インタビュアー:** [名前]
## 主な発見
1. 催促は人間関係の面で気まずい — 4人中2人
2. 催促は手作業で、まとめて繰り返している — 4人中3人
## テーマ
### 催促は人間関係の面で気まずい — 4人中2人
- **根拠:** P1 した: 毎週催促している。言った: 「嫌な役回り」が嫌。P4 した: 毎回言い方を書き直している。
- **発言:** 「嫌な役回りをするのが本当に嫌」 — P1、「失礼に聞こえないように、毎回やわらかく書き直している」 — P4
- **セグメント:** 両方
### 催促は手作業で、繰り返している — 4人中3人
- **根拠:** P1 した: 毎週金曜にスプレッドシート。P2 した: スマホから LINE。P4 した: 同じメールをコピーして貼りつけ。
- **発言:** 「毎回やわらかく書き直している」 — P4
- **セグメント:** 両方
## ジョブ（Jobs to Be Done）
- 取引先の支払いが遅れたとき、自分で書かなくても丁寧な言い方で催促を送りたい。そうすれば関係を損なわずに入金してもらえる。（テーマ1、2）
## インサイトと仮説
| 内容 | 位置づけ | 根拠 |
|---|---|---|
| 催促は繰り返しの手作業 | インサイト | P1、P2、P4（した） |
| ユーザーは自動のリマインドをほしがっている | 仮説 | P2 のみ（ほしい） |
| 催促の手段はメールが正しい | 反証あり | P2 は LINE を使っている |
## 提案
| 提案 | もとにしたもの | 確信度 | 確信度を上げるには |
|---|---|---|---|
| 丁寧な催促文のテンプレートを用意して試す | テーマ1、2 | 中 | あと4件インタビューし、ユーザーがテンプレートを書き直すかを見る |
| メールの機能を増やす前に、LINE での催促を検討する | テーマ2（P2 は LINE） | 低 | フリーランス5人に、前回どの手段で催促したかを聞く |
## 注視したいこと
- 月末まで、誰の支払いが遅れているかをその場で見る手段がない — P3
```
## 送る前のチェック
- [ ] どのテーマにも「参加者n人中x人」があり、2人以上いる。
- [ ] どの発言もそのままの言葉で参加者のラベルがついているか、「（要約）」と書いてある。
- [ ] どの観察にも、した、言った、ほしい のどれかがついている。
- [ ] どの提案にも、もとにしたテーマと確信度が書いてある。
- [ ] 書き起こしやメモにないことは書いていない。参加者や数字を作っていない。
- [ ] 反対の証拠を落とさずに示している。
## よくある失敗
- 人数ではなく言及の回数を数える。ひとりが「エクスポート」と9回言っても、n人中1人。
- 機能の要望をニーズとして扱う。その要望を口にしたとき、本人が何をしようとしていたかを聞く。
- テーマを話題で書く（「料金」）。テーマは、外れる可能性のある言い切りにする。
チームで使う
AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む
変更履歴
- v1.0.1 · · Example: the single-participant finding is dropped from Top findings (it stays under Worth watching), each recommendation names a theme, and the awkwardness theme no longer claims people delay follow-ups, which no participant said.
- v1.0.0 · · First release.
出典
出典は英語のページです。
- Affinity Diagramming for Sorting UX Findings and Ideas - NN/G (2026-11-04に確認)
- Jobs to Be Done Theory (Christensen Institute) (2026-11-04に確認)