Design Thinking Skill

Prerequisites

• 必須ではない: このスキルはナレッジベースのガイダンススキルのため、特別な前提条件はありません
• 推奨環境: チームワークショップの場合、ホワイトボードや付箋などの可視化ツールがあると効果的

---

Workflow

1. コンテキスト確認: ユーザーの課題・状況を把握する
2. 適切なフェーズ特定: 5フェーズ（共感→定義→発想→試作→検証）のどこにいるかを判断
3. 手法提案: 該当フェーズに適した手法・テンプレートを提案
4. 対話的ガイダンス: 質問に回答しながら、次のステップへ導く
5. イテレーション: 必要に応じて前のフェーズに戻り、反復的に改善

---

Output

このスキルの出力形式: 対話的なガイダンス（Conversational Guidance）

• ファイル生成は行わず、会話を通じて Design Thinking の各フェーズをガイドします
• 必要に応じて、assets/ 内のテンプレートを参照し、ユーザーが自身でドキュメントを作成できるよう支援します
• ワークショップ設計、手法選択、フィードバック解釈などのアドバイスを提供します

---

Overview

Design Thinking（デザイン思考）は、デザイナーの思考プロセスを体系化した問題解決手法です。 「ユーザーにとって本当に価値のあるもの」を生み出すために、共感から始まり、反復的に解決策を磨いていきます。

核心原則:

• Human-Centered（人間中心）: ユーザーの真のニーズから出発する
• Iterative（反復的）: 失敗から学び、素早く改善する
• Bias Toward Action（行動重視）: 考えるより作る、作って学ぶ
• Radical Collaboration（徹底的な協働）: 多様な視点を統合する

┌─────────────────────────────────────────────────────────────────────┐
│                     Design Thinking Process                         │
│                                                                     │
│   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│   │          │   │          │   │          │   │          │   │          │
│   │ EMPATHIZE│──▶│  DEFINE  │──▶│  IDEATE  │──▶│PROTOTYPE │──▶│   TEST   │
│   │   共感   │   │   定義   │   │   発想   │   │   試作   │   │   検証   │
│   │          │   │          │   │          │   │          │   │          │
│   └──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘
│        │                                                           │
│        └───────────────────── 反復 ─────────────────────────────────┘
└─────────────────────────────────────────────────────────────────────┘

---

When to Use This Skill

Ideal Scenarios

1. 新サービス・新製品の企画

   • 「顧客が本当に求めているものは何か」を探索したい
   • 既存の解決策では満足されていない課題がある

2. 顧客体験（CX/UX）の改善

   • カスタマージャーニーを可視化したい
   • タッチポイントごとのペインポイントを特定したい

3. 問題の再定義

   • 「そもそも解くべき問題は何か」を見直したい
   • 表面的な課題ではなく根本原因を探りたい

4. イノベーション創出

   • 既存の枠組みを超えたアイデアが必要
   • 社内でブレインストーミングを活性化したい

5. チーム・組織の変革

   • 部門横断で共通認識を作りたい
   • ユーザー視点の文化を浸透させたい

Example Requests

"新しいモバイルアプリのコンセプトを考えたい"
"顧客インタビューの結果からペルソナを作成して"
"このサービスのカスタマージャーニーマップを作りたい"
"チームでアイデア出しをするワークショップを設計して"
"HMW（How Might We）形式で問題を定義して"
"プロトタイプのテスト計画を立てたい"
"エンパシーマップを作成して顧客理解を深めたい"

---

Phase 1: Empathize（共感）

目的: ユーザーの世界に入り込み、真のニーズを理解する

「ユーザーが言っていること」ではなく「ユーザーが本当に必要としていること」を見つける

1.1 主要な手法

手法	説明	適用場面
インタビュー	1対1で深掘り質問	動機・感情の理解
観察（Shadowing）	行動を見る、真似する	無意識の行動発見
エンパシーマップ	Says/Thinks/Does/Feels整理	インサイト統合
5 Whys	「なぜ」を5回繰り返す	根本原因の特定
Extreme Users	極端なユーザーに注目	隠れたニーズ発見

1.2 インタビューの進め方

準備:

1. 仮説を持ちつつ、白紙で聞く姿勢を保つ
2. オープンエンド質問を用意
3. 「なぜ」「具体的には」を多用

インタビューガイド例:

## ウォームアップ（5分）
- 自己紹介、目的説明
- 「正解はない」ことを伝える

## 背景理解（10分）
- 「普段、〇〇についてどのようにしていますか？」
- 「最近、〇〇で印象に残った出来事は？」

## 深掘り（20分）
- 「そのとき、どう感じましたか？」
- 「なぜそう思ったのですか？」（5 Whys）
- 「理想的にはどうなっていたら良かったですか？」

## クロージング（5分）
- 「他に伝えたいことはありますか？」
- お礼

1.3 エンパシーマップの作成

assets/empathy_map_template.md を使用

┌─────────────────────────────────────────────────┐
│                   [ユーザー名]                    │
├────────────────────┬────────────────────────────┤
│       SAYS         │          THINKS            │
│     （言うこと）    │        （考えること）        │
│                    │                            │
│ • 実際の発言を     │ • 心の中で思っている       │
│   そのまま記録     │   ことを推測              │
│                    │                            │
├────────────────────┼────────────────────────────┤
│       DOES         │          FEELS             │
│     （行動）        │        （感情）            │
│                    │                            │
│ • 観察した行動     │ • 感情・フラストレーション │
│ • 矛盾する行動     │ • 喜び・不安              │
│                    │                            │
├────────────────────┴────────────────────────────┤
│                    PAINS                         │
│             （ペイン・課題）                      │
│ • 障壁、フラストレーション、リスク               │
├─────────────────────────────────────────────────┤
│                    GAINS                         │
│             （ゲイン・欲求）                      │
│ • 望んでいること、成功の定義、目標               │
└─────────────────────────────────────────────────┘

1.4 Output（成果物）

• インタビューメモ
• 観察ノート
• エンパシーマップ
• 気づき・インサイトリスト

詳細: references/empathize_methods.md 参照

---

Phase 2: Define（問題定義）

目的: 共感フェーズの洞察を統合し、解くべき問題を明確にする

「正しい問題」を定義できれば、解決策は半分できたようなもの

2.1 主要な手法

手法	説明	適用場面
ペルソナ	典型的ユーザー像を具体化	チーム共通認識
ジャーニーマップ	体験の時系列可視化	タッチポイント分析
POV文	Point of View声明	問題の焦点化
HMW質問	How Might We...	アイデア発想への橋渡し

2.2 ペルソナの作成

assets/persona_template.md を使用

ペルソナの構成要素:

## 基本情報
- 名前（架空）、年齢、職業、家族構成
- 写真（イメージ）

## 背景・コンテキスト
- 1日の過ごし方
- 使用しているツール・サービス
- 関連する経験・スキル

## ゴール・ニーズ
- 達成したいこと（機能的ゴール）
- なりたい姿（感情的ゴール）
- 社会的な期待（社会的ゴール）

## ペインポイント
- 現状の課題・不満
- 障壁・ブロッカー

## 行動特性
- 意思決定スタイル
- 情報収集方法
- 価値観

## 代表的な発言（Quote）
「〇〇〇〇〇〇〇」

2.3 カスタマージャーニーマップ

assets/customer_journey_map_template.md を使用

ステージ    │ 認知 │ 検討 │ 購入 │ 利用 │ 推奨
───────────┼─────┼─────┼─────┼─────┼─────
行動        │     │     │     │     │
───────────┼─────┼─────┼─────┼─────┼─────
タッチポイント│     │     │     │     │
───────────┼─────┼─────┼─────┼─────┼─────
思考        │     │     │     │     │
───────────┼─────┼─────┼─────┼─────┼─────
感情 😊😐😢 │     │     │     │     │
───────────┼─────┼─────┼─────┼─────┼─────
ペイン      │     │     │     │     │
───────────┼─────┼─────┼─────┼─────┼─────
機会        │     │     │     │     │

2.4 POV文とHMW質問

POV（Point of View）文:

[ユーザー] は [ニーズ] を必要としている。
なぜなら [インサイト] だから。

例:

忙しい共働きの親は、栄養バランスの良い夕食を30分以内に用意する方法を必要としている。
なぜなら、子供の健康を大切にしつつも、自分の時間も確保したいと感じているから。

HMW（How Might We）質問: POVをアイデア発想可能な問いに変換

HMW = "どうすれば〇〇できるだろうか？"

例:
- HMW 調理時間を半分にできるか？
- HMW 子供と一緒に料理を楽しめるか？
- HMW 栄養士のアドバイスを手軽に得られるか？
- HMW 買い物の手間をなくせるか？

HMWのコツ:

• 広すぎず、狭すぎない粒度
• 解決策を示唆しない（手段を含めない）
• 複数のHMWを出して選ぶ

2.5 Output（成果物）

• ペルソナシート
• カスタマージャーニーマップ
• POV文
• HMW質問リスト

詳細: references/define_methods.md 参照

---

Phase 3: Ideate（アイデア発想）

目的: 制約なく大量のアイデアを出し、有望なものを選ぶ

「質より量」→「量から質」

3.1 ブレインストーミングのルール

┌─────────────────────────────────────────────────────────┐
│              ブレインストーミング 7つのルール             │
├─────────────────────────────────────────────────────────┤
│ 1. 判断を保留する（Defer Judgment）                      │
│ 2. 大胆なアイデアを歓迎（Encourage Wild Ideas）          │
│ 3. 他人のアイデアに乗っかる（Build on Others' Ideas）     │
│ 4. 一度に一人が話す（One Conversation at a Time）        │
│ 5. 視覚化する（Be Visual）                              │
│ 6. 量を追求する（Go for Quantity）                      │
│ 7. トピックに集中する（Stay Focused on Topic）           │
└─────────────────────────────────────────────────────────┘

3.2 主要な発想手法

手法	時間	説明
Crazy 8s	8分	8つのアイデアを8分で描く
SCAMPER	30分	7つの視点で変形
ブレインライティング	15分	付箋に書いて回す
逆転発想	15分	「最悪にするには？」から逆転
アナロジー	20分	他業界の成功例を転用

3.3 Crazy 8s

┌────────┬────────┬────────┬────────┐
│   1    │   2    │   3    │   4    │
│  1分   │  1分   │  1分   │  1分   │
├────────┼────────┼────────┼────────┤
│   5    │   6    │   7    │   8    │
│  1分   │  1分   │  1分   │  1分   │
└────────┴────────┴────────┴────────┘

手順:
1. A4紙を8つに折る
2. タイマー8分セット
3. 1分ごとに1アイデアをスケッチ
4. 考えすぎない、手を動かす

3.4 SCAMPER

既存のアイデアを7つの視点で変形:

文字	視点	質問例
S	Substitute（代用）	何を他のもので置き換えられるか？
C	Combine（結合）	何と何を組み合わせられるか？
A	Adapt（適応）	他の用途に適応できるか？
M	Modify（修正）	形、色、意味を変えたらどうなる？
P	Put to other uses（転用）	他の目的に使えるか？
E	Eliminate（削除）	何を取り除けるか？シンプルにできるか？
R	Reverse/Rearrange（逆転/再配置）	順序や役割を逆にしたら？

3.5 アイデアの選定

ドット投票（Dot Voting）:

1. 全アイデアを壁に貼る
2. 各自3〜5個のドットシールを持つ
3. 良いと思うアイデアにシールを貼る
4. 票の多いものを選出

2x2マトリクス:

          高インパクト
               │
    ┌──────────┼──────────┐
    │  やるべき │ 要検討   │
低コスト────────┼──────────高コスト
    │  クイック │ 後回し   │
    │  ウィン  │          │
    └──────────┼──────────┘
               │
          低インパクト

3.6 Output（成果物）

• アイデアリスト（付箋、スケッチ）
• 選定されたアイデア（Top 3-5）
• アイデアの簡易説明

詳細: references/ideate_methods.md 参照

---

Phase 4: Prototype（プロトタイプ）

目的: アイデアを素早く形にして、学びを得る

「完璧を目指すな、学びを目指せ」

4.1 プロトタイプの種類

種類	忠実度	用途	時間
ペーパープロト	低	初期コンセプト検証	30分〜2時間
ストーリーボード	低	体験フロー確認	1〜2時間
ワイヤーフレーム	中	UI構造確認	2〜4時間
モックアップ	中〜高	ビジュアル確認	4〜8時間
クリッカブルプロト	高	インタラクション確認	1〜3日

4.2 プロトタイプの原則

┌─────────────────────────────────────────────────────────┐
│              プロトタイプ 4つの原則                      │
├─────────────────────────────────────────────────────────┤
│ 1. 早く作る（Quick & Dirty）                            │
│    → 完璧より、素早く作って検証                         │
│                                                         │
│ 2. 捨てる覚悟（Disposable）                             │
│    → プロトタイプに固執しない                           │
│                                                         │
│ 3. 1つの問いに答える（One Question）                    │
│    → 「これで何を学びたいか」を明確に                   │
│                                                         │
│ 4. ユーザーに見せる前提（For Testing）                  │
│    → 内部確認用ではなく、ユーザーテスト用               │
└─────────────────────────────────────────────────────────┘

4.3 ストーリーボード

体験の流れを漫画形式で描く:

┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│  Scene  │  │  Scene  │  │  Scene  │  │  Scene  │
│    1    │→│    2    │→│    3    │→│    4    │
│         │  │         │  │         │  │         │
│[スケッチ]│  │[スケッチ]│  │[スケッチ]│  │[スケッチ]│
├─────────┤  ├─────────┤  ├─────────┤  ├─────────┤
│ 説明文  │  │ 説明文  │  │ 説明文  │  │ 説明文  │
└─────────┘  └─────────┘  └─────────┘  └─────────┘

4.4 ペーパープロトタイピング

必要なもの:

• 紙（A4またはスマホサイズにカット）
• ペン、マーカー
• 付箋
• ハサミ

手順:

1. 主要画面を描く
2. ボタン、入力欄を付箋で作る（差し替え可能に）
3. 遷移を矢印で示す
4. ユーザーに操作してもらう

4.5 Output（成果物）

• プロトタイプ（物理 or デジタル）
• プロトタイプ説明書
• テストで検証したい問い

詳細: references/prototype_methods.md 参照

---

Phase 5: Test（テスト・検証）

目的: プロトタイプをユーザーに試してもらい、学びを得る

「あなたの解決策を売り込むな、学びを得ろ」

5.1 テストの心構え

DO（すべきこと）:
✓ 観察する、聞く
✓ 「なぜそうしましたか？」と質問
✓ 沈黙を恐れない
✓ メモを取る
✓ ユーザーの行動と発言の矛盾に注目

DON'T（避けること）:
✗ 解決策を説明しすぎる
✗ ユーザーを誘導する
✗ 防御的になる
✗ 「それは仕様です」と言う

5.2 テストセッションの流れ

## 1. 準備（テスト前）
- テスト目的・問いを明確化
- 参加者リクルート（3〜5人）
- シナリオ・タスクを用意
- 記録係を決める

## 2. 導入（5分）
- 目的説明「プロトタイプのテストであり、あなたのテストではない」
- 思考発話法の説明「思ったことを声に出してください」
- 質問を歓迎することを伝える

## 3. タスク実行（15-30分）
- タスクを読み上げる
- 観察・メモ
- 「今何を考えていますか？」と適宜質問

## 4. 振り返り（10分）
- 全体的な感想
- 良かった点、困った点
- 改善アイデア

## 5. 分析（テスト後）
- フィードバックを整理
- パターンを見つける
- 次のイテレーションを計画

5.3 フィードバックキャプチャグリッド

┌─────────────────────┬─────────────────────┐
│      良かった点     │       改善点        │
│        (+)         │        (-)          │
│                    │                     │
│ • ...              │ • ...               │
│ • ...              │ • ...               │
│                    │                     │
├─────────────────────┼─────────────────────┤
│       質問         │      アイデア       │
│        (?)         │        (!)          │
│                    │                     │
│ • ...              │ • ...               │
│ • ...              │ • ...               │
│                    │                     │
└─────────────────────┴─────────────────────┘

5.4 学びの統合

テスト結果から次のアクションを決定:

結果	アクション
核心的な問題発見	Phase 2（Define）に戻る
アイデアの方向性が違う	Phase 3（Ideate）に戻る
細部の改善が必要	Phase 4（Prototype）を改良
概ね良好	次のフェーズ（実装）へ

5.5 Output（成果物）

• テスト結果レポート
• フィードバックキャプチャグリッド
• 学びと次のアクション

詳細: references/test_methods.md 参照

---

Quick Reference

フェーズ別所要時間（目安）

Phase	最小	標準	深掘り
Empathize	2時間	1日	1週間
Define	1時間	半日	2日
Ideate	1時間	半日	1日
Prototype	2時間	1日	3日
Test	2時間	1日	1週間
合計	8時間	4日	3週間

各フェーズの主要成果物

Phase	主要成果物
Empathize	エンパシーマップ、インタビューメモ
Define	ペルソナ、ジャーニーマップ、HMW
Ideate	アイデアリスト、選定アイデア
Prototype	プロトタイプ
Test	テストレポート、学び

---

Best Practices

DO（推奨）

• ✓ ユーザーに会う（机上で考えない）
• ✓ 反復する（一発で正解を目指さない）
• ✓ 可視化する（言葉より絵）
• ✓ 多様なメンバーで実施
• ✓ 失敗を歓迎する
• ✓ 時間を区切る（タイムボックス）

DON'T（非推奨）

• ✗ 最初から正解を決めつける
• ✗ 自分の仮説を確認するだけのインタビュー
• ✗ 完璧なプロトタイプを作ろうとする
• ✗ フィードバックを無視する
• ✗ 1人で進める

---

Resources

References（理論・手法ガイド）

• references/design_thinking_overview.md - Design Thinkingの概要と原則
• references/empathize_methods.md - 共感フェーズの詳細手法
• references/define_methods.md - 問題定義の詳細手法
• references/ideate_methods.md - アイデア発想の詳細手法
• references/prototype_methods.md - プロトタイプの詳細手法
• references/test_methods.md - テスト・検証の詳細手法

Assets（テンプレート）

• assets/empathy_map_template.md - エンパシーマップ
• assets/persona_template.md - ペルソナシート
• assets/customer_journey_map_template.md - カスタマージャーニーマップ
• assets/problem_statement_template.md - POV/HMW問題定義
• assets/ideation_canvas_template.md - アイデア出しキャンバス
• assets/prototype_test_plan_template.md - プロトタイプテスト計画

---

参考文献

• Stanford d.school: Design Thinking Bootcamp Bootleg
• IDEO: Human-Centered Design Toolkit
• Tim Brown: Change by Design
• Jake Knapp: Sprint