この技術でできること
- 大量の発話データを意味のあるカテゴリに分類できる
- 「なんとなく」ではなくデータに基づいたパターンを発見できる
- 分析結果を根拠と共に報告できる
例: 5人のインタビューでも数十ページの発話録が生まれる。コーディングなしでは「印象に残った話」しか報告できない
なぜ難しいか
コーディングは「感想を書く」ことではない。データに基づいて分類し、根拠を示す作業である。
多くの分析で起きる問題は、コードが曖昧・分類が主観的・結論が先にある、の3つ。
分析プロセス
全体フロー
「データ準備」→「オープンコーディング」→「アクシャルコーディング」→「パターン抽出」。発話にラベルをつけ、関係を整理し、頻度と例外を分析する。
ステップ1: データ準備
目的: 分析可能な形式でデータを整える
やること:
インタビューの録音を文字に起こす。
| 方法 | 精度 | コスト |
|---|---|---|
| AI文字起こし（Otter, Notta等） | 中〜高 | 低 |
| 外部委託 | 高 | 中〜高 |
| 自分で起こす | 高 | 高（時間） |
逐語録でなくてOKな理由:
- コーディングに必要なのは「意味」であり、一言一句の再現ではない
- ただし、印象的な発話はそのまま残す（報告時の引用に使う）
非言語情報の残し方:
- 笑い、沈黙、ためらい、声のトーン変化を【 】でメモする
- 例: 「使いやすいです【3秒沈黙】…まあ、慣れれば」
- 非言語が入ると、発話の「本音度」がわかる
話者表記の粒度:
- I: インタビュアー、U: ユーザー（基本形）
- 複数ユーザーの場合: U1, U2, U3 で区別
- タイムスタンプは5分刻みで十分（例: [05:00]）
ステップ2: オープンコーディング
目的: 発話に意味のあるラベル（コード）をつける
やること: コード = 発話の意味を短いラベルで表現したもの
手順:
- 発話を1文〜数文ずつ読む
- 「この発話は何を言っているか」を短い言葉で表現
- 同じ意味の発話には同じコードをつける
例:
| 発話 | コード |
|---|---|
| 「毎回パスワードを入力するのが面倒で」 | 認証の手間 |
| 「ログイン画面で止まっちゃうことが多い」 | 認証の手間 |
| 「指紋認証があれば楽なんだけど」 | 認証の改善要望 |
| 「買おうと思ったけど、送料が高くて」 | 送料による離脱 |
コードの粒度:
- 細かすぎ: 「パスワード入力」「ログイン画面」（統合できない）
- 粗すぎ: 「不満」（何の不満かわからない）
- ちょうどいい: 「認証の手間」（具体的かつ統合可能）
ステップ3: アクシャルコーディング
似たコード同士をまとめて、上位の意味のまとまりを作る工程。オープンコーディングが「ラベルを貼る」作業なら、アクシャルコーディングは「棚に整理する」作業。
目的: コード同士の関係を整理し、上位カテゴリを作る
やること: オープンコーディングで出たコードを、上位カテゴリにまとめる。
例:
【上位カテゴリ: ログイン体験】
├── 認証の手間
├── 認証の改善要望
└── パスワード忘れ
【上位カテゴリ: 購入障壁】
├── 送料による離脱
├── 決済手段の不足
└── 在庫切れ
関係性の種類:
- 包含関係: AはBに含まれる
- 因果関係: AがBを引き起こす
- 対立関係: AとBは矛盾する
ステップ4: パターンの抽出
目的: 頻度・強度・例外からインサイトを得る
やること:
| コード | 出現人数 | 出現回数 |
|---|---|---|
| 認証の手間 | 5/5人 | 12回 |
| 送料による離脱 | 3/5人 | 5回 |
| 在庫切れ | 1/5人 | 2回 |
分析の視点:
- 頻度: 多くの人が言っている = 共通の課題
- 強度: 繰り返し言っている = 深刻な課題
- 例外: 1人だけ違う = 特殊なセグメントか、見落としか
コーディングツール
| ツール | 特徴 | 料金 |
|---|---|---|
| スプレッドシート | シンプル、共有しやすい | 無料 |
| Notion | 柔軟、タグ機能 | 無料〜 |
| Dovetail | 定性分析特化 | 有料 |
| ATLAS.ti | 学術研究向け | 有料 |
| 付箋（Miro等） | 親和図法と組み合わせ | 無料〜 |
おすすめ:
- 5人以下: スプレッドシートで十分
- 6人以上: Dovetailや専用ツールを検討
よくある失敗
❌ 結論が先にある
「ユーザーはこれを求めているはず」という仮説に合う発話だけをコーディングする。
なぜ失敗するか: 確証バイアス。聞きたい答えだけを拾ってしまう。
対策:
- 仮説に反する発話も必ずコーディングする
- 「仮説に反するコード」というカテゴリを作る
- 他の人にコーディング結果をレビューしてもらう
❌ コードが曖昧
「不満」「良い」「悪い」のような抽象的なコードをつける。
なぜ失敗するか: 何に対する不満かがわからず、施策につながらない。
対策:
- コードは「何について」「どう感じたか」をセットにする
- 「不満」→「認証の手間への不満」
❌ 分析者が1人だけ
自分だけでコーディングすると、主観が入る。
なぜ失敗するか: 同じ発話でも、人によって解釈が異なる。
対策:
- 2人以上でコーディングし、一致率を確認する
- 一致しないコードは議論して決める
- 最低でも、他の人に結果を見せてフィードバックをもらう
実践チェックリスト
最低ライン（Must）
理想ライン（Better）
出力例
コードブック
【カテゴリ: ログイン体験】
コード: 認証の手間
定義: ログイン時のパスワード入力・認証プロセスへの負担感
例: 「毎回パスワードを入力するのが面倒」「ログインで止まる」
コード: 認証の改善要望
定義: 認証プロセスの簡略化を求める発言
例: 「指紋認証があれば」「覚えなくていい方法がいい」
分析サマリー
【主要な発見】
1. 認証の手間（5/5人）
- ほぼ全員がログイン体験に不満
- 特にパスワード入力が障壁
- 指紋・顔認証への期待が高い
2. 送料による離脱（3/5人）
- カート追加後に離脱するパターン
- 送料無料ラインが不明確
関連技術
前提となる技術
セットで使う技術
- 親和図法 — コードをグルーピングする
次に学ぶ技術
- インサイト抽出 — コードから施策へ
まとめ
- この技術の本質: 「感想」ではなく、データに基づいてパターンを発見する技術
- できるようになること: インタビュー結果を「根拠と共に」報告できる
- 次に学ぶべき技術: 親和図法（コードをグルーピングする）
次に学ぶ技術: 親和図法
