この技術でできること
- 分析テーマを 具体的な施策提案 につなげられる
- 「だから何？」に答える アクショナブルなインサイト を言語化できる
- データと施策の間に 論理的な根拠のチェーン を作れる
例 : 「ログイン体験に摩擦がある」というテーマだけでは施策は生まれない。「ユーザーはパスワードを覚えていないのではなく、入力する行為自体がストレスだから、生体認証に切り替えることで離脱を防げる」まで言語化して初めてインサイトになる
なぜ難しいか
分析テーマと施策の間には 「だから何？」のギャップ がある。
テーマが見つかると「分析が終わった」と感じてしまう。しかしテーマは「問題の発見」であり、「問題の理解」ではない。 なぜその問題が起きているか ** 、 何が変われば解決するか**まで踏み込まないと、施策は的外れになる。この「もう一段深く考える」が最も難しい。
分析プロセス
全体フロー
「テーマの確認」→「インサイトの言語化」→「施策への変換」→「優先度の判断」。テーマは出発点であり、ゴールではない。
ステップ1: テーマを確認する
目的 : 親和図法で得たテーマの内容と根拠を再確認する
やること :
各テーマについて以下を整理する。
| 項目 | 確認すること |
|---|---|
| 頻度 | 何人中何人が言っているか |
| 強度 | どれくらい強く言っているか（繰り返し・感情の強さ） |
| 代表発話 | テーマを最も端的に表す引用 |
| 例外 | このテーマに当てはまらない人はいるか |
具体例 :
テーマ: ログイン体験の摩擦
頻度: 5/5人
強度: 高（全員が複数回言及）
代表発話: 「毎回パスワード入力が面倒で、結局アプリを開かなくなった」
例外: なし
ステップ2: インサイトを言語化する
目的 : テーマの背後にある「なぜ」と「それがどう影響するか」を明確にする
やること :
インサイトの構造は3層。
テーマ（何が起きているか）
↓
原因（なぜ起きているか）
↓
影響（それがどう影響するか）
インサイトの書き方フォーマット :
[ユーザーは] ○○という行動/状況にある。
[なぜなら] △△だから。
[その結果] □□が起きている。
[つまり] ◇◇ということがわかった。
具体例 :
【テーマ: ログイン体験の摩擦】
ユーザーはログイン画面で離脱している。
なぜなら、パスワードを覚えていないのではなく、
入力する行為自体が日常利用の文脈ではストレスだから。
その結果、アプリを開く習慣が途切れ、利用頻度が低下している。
つまり、認証の簡略化は「便利さ」の問題ではなく
「習慣化」の問題として対処する必要がある。
良いインサイトの特徴 :
- 驚きがある : 「そうだったのか」と思わせる
- 行動につながる : 「だから○○しよう」が見える
- データに根拠がある : 発話・行動で裏付けられている
- 1テーマ1インサイト : 複数のテーマを混ぜない
ステップ3: 施策に変換する
目的 : インサイトを具体的なアクションに変換する
やること :
インサイトから「何を変えれば、どう改善するか」を導出する。
| インサイト | 施策案 | 期待効果 |
|---|---|---|
| 認証行為自体がストレス | 生体認証の導入 | ログイン離脱の減少 |
| 習慣化が途切れている | ログイン不要のフィード表示 | アプリ起動頻度の回復 |
| 送料の不透明さが離脱原因 | 商品ページに送料を表示 | カート離脱の減少 |
施策の質を上げる問い :
- 「この施策はインサイトのどの部分に対応しているか？」
- 「この施策で本当に原因が解消されるか？」
- 「この施策はデータのない仮説ではないか？」
ステップ4: 優先度を判断する
目的 : 限られたリソースで最大の効果を得る
やること :
| 軸 | 高い | 低い |
|---|---|---|
| インパクト | 多くのユーザーに影響 | 限定的 |
| 確信度 | 複数のデータで裏付け | 単一の発話のみ |
| 実現性 | すぐ着手できる | 大規模な開発が必要 |
優先度マトリクス :
高インパクト
↑
┌────────┼────────┐
│ すぐやる │ 計画する│
高確信度────┼────────低確信度
│ 小改善 │ 保留 │
└────────┼────────┘
↓
低インパクト
出力例 :
【インサイトレポート】
1. ログイン体験の摩擦（優先度: 高）
インサイト: 認証行為自体がストレス → 習慣化の断絶
施策: 生体認証導入
根拠: 5/5人が言及、離脱ログとも一致
2. コスト可視性の不足（優先度: 中）
インサイト: 送料が不明 → カート追加後に離脱
施策: 商品ページに送料表示
根拠: 3/5人、EC業界のデータとも整合
よくある失敗
❌ テーマをそのまま報告する
「ログイン体験に問題がある」で終わる。「だから何？」に答えていない。
なぜ失敗するか : テーマ発見で「分析完了」と感じてしまう。分析は発見ではなく、理解がゴール。
対策 :
- テーマごとに「なぜなら」「その結果」「つまり」を書く
- 「この報告を読んだ人は、次に何をすればいいかわかるか？」と自問する
❌ データにないインサイトを書く
「おそらく○○だろう」で施策を提案する。データの根拠がない。
なぜ失敗するか : テーマから施策へ飛躍する時に、自分の仮説を混ぜてしまう。
対策 :
- インサイトの根拠欄に、必ず代表発話を引用する
- 「この発話がなかったら、このインサイトは成立するか？」と確認
- 仮説と発見を明確に区別して書く
❌ 施策を1つに絞れない
「生体認証も、パスワードレスも、ソーシャルログインも」と全部提案する。
なぜ失敗するか : インサイトの粒度が粗い。本質だけを取り出せていない。
対策 :
- 「根本原因は何か」に集中する
- 施策は「原因の解消」を基準に選ぶ
- まず1つ提案し、代替案は補足として示す
実践チェックリスト
最低ライン（Must）
理想ライン（Better）
応用テクニック
インサイトステートメント
いつ使うか : インサイトをチームや関係者に共有する時、1文で伝えたい時
インサイトを定型フォーマットで1文にまとめる。
フォーマット :
「[ユーザー]は[行動/状況]している。なぜなら[原因]だから。[影響/示唆]。」
例 :
「週1回以上利用するユーザーは、ログイン画面で離脱している。なぜなら、パスワード入力行為自体が日常利用の文脈ではストレスだから。認証の簡略化は利便性ではなく習慣化の施策として位置づけるべき。」
崩れるパターン : 1文に複数のインサイトを詰め込むと焦点がぼける。1ステートメント＝1インサイトを徹底する。
How Might We（HMW）変換
いつ使うか : インサイトからアイデア発想に移行する時
インサイトを「どうすれば〇〇できるか？」の問いに変換する。
インサイト : 認証行為がストレスで習慣が途切れる
HMW :
- 「どうすれば、認証なしで安全にアプリを使えるか？」
- 「どうすれば、ログインを意識させずにアプリを開けるか？」
- 「どうすれば、認証自体を楽しい体験にできるか？」
崩れるパターン : HMWが広すぎると（「どうすればユーザーを幸せにできるか？」）アイデアが散らかる。インサイトの原因に対応する粒度にする。また、HMWは発散用であり、そのまま実装案にするものではない。
関連技術
前提となる技術
セットで使う技術
- バイアス制御 — インサイト導出時のバイアス管理
次に学ぶ技術
- ペルソナ接続 — インサイトをペルソナに統合する
まとめ
- この技術の本質 : テーマを「発見」で終わらせず、「理解」→「施策」まで変換する技術
- できるようになること : データに根拠のあるアクショナブルな提案ができる
- 次に学ぶべき技術 : ペルソナ接続（インサイトをユーザー像に統合する）