概要

デザイン思考は「共感・定義・概念化・試作・テスト」という5段階の型によって、ユーザーの文脈から出発し、不確実な課題を突破する人間中心の問題解決手法である。

• 各フェーズは「発散（可能性を広げる）」と「収束（絞り込む）」の思考モードを意図的に切り替える構造になっている
• 直線的なプロセスではなく、テスト結果によって前のフェーズへ戻る非線形・反復型のアプローチが本質
• ユーザーの表層的な要望ではなく、潜在的なニーズとインサイトを起点に解決策を導くことで、イノベーションを生み出す

フレームワーク全体像

5つのフェーズは独立したステップではなく、相互に行き来する反復サイクルとして機能する。

スタンフォード大学 d.school が提唱したこのフレームワークは、各段階で思考のモードを切り替えながら、ユーザーの文脈から出発して解決策へと収束していく。

フェーズと思考モードの対応

非線形フロー（典型的な戻りパターン）

[共感] ──→ [定義] ──→ [概念化] ──→ [試作] ──→ [テスト]
   ↑                     ↑                          │
   └─────── 課題の再設定が必要な場合 ───────────────┘
                          └────── アイデア再検討が必要な場合 ──┘

💡 ポイント: テストで「解くべき課題が間違っていた」と気づいた場合、定義や共感フェーズまで戻ることが正しい判断。「手戻り」ではなく「学習の証拠」として捉える。

1. 共感（Empathize）：ユーザーの世界を追体験する

客観的なデータ分析を超え、ユーザーが抱く感情・痛み・喜び、そして無意識の行動の背後にある動機を深く理解する。

デザイン思考の起点はユーザーへの共感にある。アンケートや数値データだけでは見えない「なぜそう行動するのか」という動機と文脈を、直接観察・対話を通じて明らかにするフェーズ。

主な調査手法

よくある失敗パターン

• ❌ 「ユーザーは〜だろう」と仮定だけで進め、実際の調査をスキップする
• ❌ インタビューで誘導尋問になり、自分たちが聞きたい答えを引き出してしまう

💡 ポイント: 「なぜ？」を最低3回繰り返す。表層の発言ではなく、その行動を生み出している感情や文脈にたどり着くことがゴール。

2. 定義（Define）：真の課題を特定し、問いを立てる

共感フェーズで得た膨大な断片情報を整理・統合し、解決すべき核心的な「インサイト」を抽出して課題を再定義する。

正しい解決策を作る前に、「正しい問いを解いているか」を問うフェーズ。表層的な要望（Want）の裏にある本質的な欠乏（Need）を特定し、チーム全体の方向性を揃える。

インサイト掘り下げの構造

ユーザーの発言（Want）
  └→「ドリルが欲しい」
        ↓ なぜ？
ニーズ（Need）
  └→「壁に穴を開けたい」
        ↓ なぜ？
インサイト（Insight）
  └→「棚を設置して、快適で整理された部屋で生活したい」

主な手法と成果物

よくある失敗パターン

• ❌ 最初に思いついた問い設定のまま進め、定義フェーズを軽視する
• ❌ 組織の都合や技術的制約から逆算した課題定義になってしまう

💡 ポイント: HMWステートメントは「狭すぎず、広すぎず」が重要。「どうすれば全員が満足できる交通機関を作れるか」は広すぎ、「どうすれば座席数を増やせるか」は狭すぎる。

3. 概念化（Ideate）：思考の枠を外してアイデアを量産する

定義された課題（問い）に対し、実現可能性や論理的な制約を一度取り払い、多角的かつ大量の解決策を考案する。

「質より量」を追求するフェーズ。突飛なアイデアや一見不可能な案が、画期的なイノベーションの呼び水となる。批判を禁止し、他人のアイデアに乗っかる（Yes, and...）姿勢がチームの創造性を最大化させる。

主な発想手法

ブレインストーミングの基本ルール

✅ 批判・評価を禁止する
✅ 突飛なアイデアを歓迎する
✅ 他人のアイデアに乗っかる（Yes, and...）
✅ 量を優先する（質は後で選ぶ）
✅ 一度に一人が話す

よくある失敗パターン

• ❌ 「どうせ実現できない」という自己検閲が働き、アイデアが凡庸な範囲に収まる
• ❌ 声の大きいメンバーの方向性に全員が引っ張られ、多様性が失われる

💡 ポイント: アイデアの選別（収束）は必ず「発散の後」に行う。同じセッション内で発散と収束を混在させると、創造性が著しく低下する。

4. 試作（Prototype）：素早く安価に形にする

アイデアを抽象的な概念のままにせず、手触りのある具体的な「検証可能なツール」へと落とし込む。

目的はプロダクトの完成ではなく、検証を通じた「学習」にある。失敗のコストを最小化するため、いかに「粗く・速く」作れるかが重要。作り込みすぎると、フィードバックを受け入れる心理的障壁が高まるため注意が必要。

忠実度（Fidelity）と用途の使い分け

ラピッド・プロトタイピングの原則

作る目的を1つに絞る
  └→「このプロトタイプで何を検証したいか」を先に定義

最小限の要素だけ作る
  └→ 検証に不要な部分は省略・スキップしてよい

捨てる前提で作る
  └→「壊されるため」に存在するのがプロトタイプ

よくある失敗パターン

• ❌ 「もう少し作り込んでから見せよう」と完成度にこだわり、フィードバックが遅れる
• ❌ 何を検証したいかを決めないまま作り始め、テスト時に学びが得られない

💡 ポイント: プロトタイプの目的は「正しさの証明」ではなく「間違いの早期発見」。粗いプロトタイプへの批判的なフィードバックこそが、最も価値ある資産。

5. テスト（Test）：フィードバックから学びを回収する

プロトタイプを実際のユーザーに使ってもらい、その反応や行動から仮説の誤りや改善のヒントを抽出する。

テストは「自分のアイデアが正しいことを証明する場」ではなく「ユーザーから学ぶ場」である。否定的なフィードバックこそが、次の改善に向けた資産となる。

フィードバックの収集と整理

フィードバック・グリッドの構造

┌──────────────────┬──────────────────┐
│  ✅ 良かった点   │  🔧 改善すべき点  │
│  （続けるべき）  │  （変えるべき）   │
├──────────────────┼──────────────────┤
│  ❓ 疑問・驚き  │  💡 新しいアイデア │
│  （深掘りすべき）│  （追加検討すべき）│
└──────────────────┴──────────────────┘

テスト結果に応じた次アクションの判断

よくある失敗パターン

• ❌ 「うまくいってほしい」という気持ちから、ネガティブなフィードバックを過小評価する
• ❌ テスト参加者に操作方法を説明・誘導しすぎ、実際の使用状況と乖離した結果になる

💡 ポイント: テストでは「なぜそうしたのか」をユーザーに聞き続ける。観察された行動の背後にある動機こそが、共感フェーズへと還流する最も価値ある情報。

参考リンク

• Stanford d.school — Design Thinking Bootcamp Bootleg
• IDEO Design Thinking
• Nielsen Norman Group — Design Thinking 101
• Interaction Design Foundation — Design Thinking