フレームワーク活用ガイドひとことで言うと#
「ユーザーへの共感」から始めて、問題を定義し、アイデアを出し、プロトタイプを作り、テストするという5つの段階を繰り返すことで、本当にユーザーが求めている解決策を生み出すプロセス。
押さえておきたい用語#
- 共感（Empathize）
- ユーザーの世界に入り込み、本人も気づいていないニーズや感情を理解するフェーズのこと。デザイン思考の出発点であり最重要ステップ。
- HMW（How Might We）
- 「どうすれば〜できるか？」という形式の発散的な問いかけのこと。問題定義をアイデア創出につなげるブリッジとして使う。
- プロトタイプ（Prototype）
- アイデアを最小限の形で素早く形にしたもののこと。紙のスケッチからMVPまでレベルはさまざまだが、完璧を目指さないことが鉄則。
- インサイト（Insight）
- 共感フェーズで発見したユーザーの深層にある欲求や行動パターンのこと。表面的なニーズ（「もっと速いUIが欲しい」）ではなく本質（「待ち時間のストレスをなくしたい」）を指す。
- イテレーション（Iteration）
- プロトタイプ→テスト→改善を繰り返し回すサイクルのこと。1回で正解にたどり着こうとせず、何度も回すことで精度を上げる。
デザイン思考プロセスの全体像#
こんな悩みに効く#
- 良いものを作ったつもりなのに、ユーザーに使ってもらえない
- 技術ドリブンやビジネスドリブンで進めて、ユーザーの本当のニーズを見落としている
- アイデアに自信がなく、大きな投資をする前に検証したい
基本の使い方#
ユーザーの世界に入り込み、本人も気づいていないニーズや感情を理解する。
方法：
- ユーザーインタビュー（5人で十分）
- 行動観察（ユーザーが実際に作業している場面を見る）
- 体験（自分がユーザーの立場を経験する）
重要: 「何が欲しいですか？」ではなく「普段どうしていますか？困っていることは？」と聞く。ユーザーは自分が何を欲しいか正確には言えない。
共感フェーズで得た洞察を統合し、解くべき問題を1文で定義する。
フォーマット： 「[ユーザー] は [ニーズ] を必要としている。なぜなら [インサイト] だから。」
例： 「在宅勤務の親は、集中して仕事ができる30分を必要としている。なぜなら、子どもの世話と仕事の切り替えに毎回15分を失っているから。」
ここで問題を正しく定義できるかが、プロセス全体の成否を決める。
定義した問題に対して、可能な限り多くの解決策を出す。
- ブレインストーミングで量を重視
- 「How Might We（どうすれば〜できるか？）」の問いで発散
- 実現可能性は一旦無視。突飛なアイデア歓迎
出したアイデアを投票やマトリクスで3〜5個に絞る。
選んだアイデアを最小限の形で素早く形にして、ユーザーに見せる。
プロトタイプのレベル：
- 紙: 手書きの画面スケッチ（30分で作れる）
- モック: 簡易的なデジタルモックアップ（1日で作れる）
- MVP: 最小限の機能だけ実装したもの（1〜2週間で作れる）
テストで確認すること：
- ユーザーは直感的に使えるか？
- 定義した問題は本当に解決されているか？
- 想定外の反応はないか？
テスト結果をもとに、共感フェーズに戻って繰り返す。
具体例#
状況: 従業員200名のIT企業。「会議室が足りない」と不満が多いが、実際にはガラ空きの会議室もある。
共感: 社員10人にインタビュー。「予約システムは使っているが、実際に行くと使われていない会議室が多い」「予約だけして来ない人がいる」「急な打ち合わせで空き部屋を探すのが大変」
問題定義: 「急な打ち合わせが必要な社員は、今すぐ使える会議室を知る手段を必要としている。なぜなら、予約システムの情報と実態が乖離しているから。」
アイデア創出（42個のうち上位4つ）:
- 会議室にセンサーをつけて使用状況をリアルタイム表示
- 予約後15分以内にチェックインしないと自動キャンセル
- 会議室を予約不要のフリースペースにする
- Slack botで「今空いてる部屋」を聞けるようにする
プロトタイプ & テスト: 「15分自動キャンセル＋Slack bot」を1フロアで2週間テスト。
結果: 空き部屋の利用率が35%→75%に向上。「会議室が足りない」という不満が82%減少。最初は「もっと良い予約システムを導入しよう」と考えていたが、共感フェーズで「予約と実態のズレ」が本質的な問題だと気づけた。
状況: 全国50店舗のカフェチェーン。モバイルオーダーアプリを導入したが、ダウンロード後の利用率が18%と低迷。
共感: アプリをダウンロードしたが使わなくなった顧客8人にインタビュー。
- 「注文画面が複雑で、レジのほうが早い」（5人）
- 「カスタマイズの選択肢が多すぎてわからない」（4人）
- 「受取時間が不正確で、着いたらまだできていない」（6人）
問題定義: 「忙しい朝にカフェを利用する人は、30秒以内で注文を完了して正確な受取時間を知りたい。なぜなら、レジより遅いなら使う意味がないから。」
アイデア創出:
- ワンタップで前回注文を繰り返す「いつもの」ボタン
- カスタマイズを3段階にシンプル化
- GPSと連動した到着時間予測で受取タイミングを最適化
プロトタイプ（紙プロトタイプ → 3日でモック）: 「いつもの」ボタンをアプリ起動時に最大表示するモックを作成。5人にテスト。
結果: 「いつもの」ボタン実装後、アプリ利用率が18%→42%に改善。注文完了時間は平均48秒→12秒に短縮。技術チームは「AIレコメンド機能」を作ろうとしていたが、ユーザーが本当に求めていたのは「前と同じ」を1タップで完了する体験だった。
状況: 人口8万人の自治体。防災アプリを作ったが、65歳以上のダウンロード率が3%。高齢者にこそ使ってほしいのに届いていない。
共感: 高齢者10名（65〜82歳）を自宅訪問してインタビュー・行動観察。
- 「アプリって何？」（3名）
- 「文字が小さくて読めない」（6名）
- 「子どもに設定してもらったが、通知が多すぎて消した」（4名）
- 「緊急時に電話で教えてくれたほうが安心」（7名）
問題定義: 「スマホに不慣れな高齢者は、緊急時に自分が何をすべきかを分かりやすく知りたい。なぜなら、アプリの操作自体がストレスであり、情報を受け取る手段がそもそも違うから。」
アイデア創出:
- アプリではなく「自動音声電話＋SMS」で避難情報を配信
- 高齢者のスマホに大きなボタン1つ（「今すぐ避難」「大丈夫」）だけのウィジェット
- 町内会の回覧板＋QRコードで情報にアクセス
プロトタイプ: 自動音声電話（「こちらは○○市です。大雨警報が出ました。△△地区の方は□□公民館に避難してください」）+ SMS送信を20世帯でテスト。
結果: テスト対象の85%が「アプリより電話のほうがわかりやすい」と回答。自動音声電話システムを本格導入し、高齢者への情報到達率が3%→78%に劇的改善。「アプリを改善する」のではなく「情報の届け方自体を変える」という問題の再定義が成功の鍵だった。
やりがちな失敗パターン#
- 共感フェーズを飛ばす — 「ユーザーのことはわかっている」と思い込んで、いきなりアイデアを出してしまう。5人でいいからインタビューするだけで、思い込みが壊れる
- プロトタイプを作り込みすぎる — 完璧なものを作ろうとして時間がかかり、テスト回数が減る。30分で作れるレベルの「雑なプロトタイプ」を何回もテストするほうが効果的
- テスト結果を無視して当初のアイデアに固執する — テストで否定的な結果が出ても「ユーザーが理解していないだけ」と言い訳する。テスト結果は謙虚に受け止め、アイデアを修正する
- 問題定義が曖昧なまま先に進む — 「ユーザー体験を良くしたい」のような漠然とした定義では、アイデアも漠然とする。「誰が・何を・なぜ」を具体的に1文で書けるまで問題定義を磨く
まとめ#
デザイン思考プロセスは、ユーザーへの共感を起点に、問題定義→アイデア創出→プロトタイプ→テストを繰り返す創造的問題解決のアプローチ。最も重要なのは、自分の思い込みではなくユーザーの現実から出発すること、そして完璧を目指さず素早く作って素早くテストするサイクルを回すこと。