フレームワーク活用ガイドひとことで言うと#
「発散→収束」のプロセスを2回繰り返すことで、正しい課題を見つけ（1つ目のダイヤモンド）、正しい解決策を生み出す（2つ目のダイヤモンド）デザインプロセスモデル。多くの失敗は「間違った課題に対して正しい解決策を作る」ことから生まれる。ダブルダイヤモンドはそれを防ぐ。
押さえておきたい用語#
- 発散（Diverge）
- 判断をせずに選択肢や情報を広く集めるフェーズ。「それは無理」「予算がない」などのフィルターを一切かけず、可能性を最大化する。
- 収束（Converge）
- 集めた情報やアイデアを評価・選別して絞り込むフェーズ。基準を明確にし、勇気を持って捨てることが求められる。
- HMW（How Might We）
- 「どうすれば○○できるだろうか？」という課題を問いの形で言語化する手法。問題の枠組みを解決可能な形に変換する。
- プロトタイプ
- 解決策のアイデアを低コストで素早く形にした試作品。ペーパースケッチからクリッカブルモックまでレベルは様々。テストのために使う。
ダブルダイヤモンドの全体像#
こんな悩みに効く#
- いきなりソリューションに飛びついてしまい、そもそもの課題設定が甘い
- アイデアはたくさん出るが、どれを選べばいいかわからない
- デザインプロジェクトの全体像をチームで共有したい
基本の使い方#
最初のダイヤモンドの前半。先入観を捨てて、課題を広く探索するフェーズ。
やること:
- ユーザーインタビュー（最低5人）
- 行動観察（ユーザーの実際の行動を見る）
- デスクリサーチ（市場調査、競合分析）
- ステークホルダーへのヒアリング
ここでは判断しない。「これは重要だ」「これは違う」というフィルターをかけず、情報を幅広く集める。予想外の発見こそが、このフェーズの最大の価値。
例: 「ECサイトの売上が下がっている」→ いきなり「UI改善」に飛びつかず、ユーザーの購買行動、カスタマーサポートへの問い合わせ内容、競合の動向、市場トレンドを幅広くリサーチする。
最初のダイヤモンドの後半。集めた情報を整理し、解くべき課題を1つに絞る。
やること:
- 親和図法で情報をグルーピング
- 「How Might We（どうすれば〇〇できるだろうか？）」形式で課題を言語化
- ユーザーペルソナやジャーニーマップの作成
- チームで「これが本当の課題だ」と合意する
例: リサーチの結果、「UIが悪い」のではなく「初回購入後のフォローがなく、リピート購入につながっていない」が本質的な課題だと判明。→ HMW: 「どうすれば、初回購入者がリピーターになる体験を作れるだろうか？」
ここが最も重要なフェーズ。課題の定義が間違っていると、どんなに優れた解決策も無意味になる。
2つ目のダイヤモンドの前半。定義した課題に対して、解決策を量産するフェーズ。
やること:
- ブレインストーミング（批判なし、量を重視）
- クレイジーエイト（8分で8つのアイデアをスケッチ）
- 他業界の事例からの着想
- 技術的に可能なアプローチの洗い出し
ここでも判断しない。「予算的に無理」「技術的に厳しい」というブレーキは一旦外す。制約は次のフェーズで考える。
例: 「リピート購入を促す」ためのアイデアを30個出す。ポイント制、定期購入、購入後のパーソナライズドメール、コミュニティ機能……
2つ目のダイヤモンドの後半。最適な解決策を選び、プロトタイプを作ってテストする。
やること:
- アイデアの評価と選定（実現可能性 × 効果で絞る）
- プロトタイプの作成（低忠実度→高忠実度）
- ユーザーテストでフィードバックを得る
- 改善してリリースする
例: 30個のアイデアから「購入3日後にパーソナライズドメール + 関連商品レコメンド」を選定。メールのモックを作成し、過去の購入者10人に「このメールが届いたらどう思うか」をテスト。
テスト結果によっては、前のフェーズに戻ることもある。ダブルダイヤモンドは一方通行ではない。
具体例#
従業員800人の中堅IT企業。「会議室が予約しにくい」という不満が社員アンケートで上位に。
第1ダイヤモンド（正しい課題を見つける）
発見（発散）: 社員15人にインタビュー + 会議室の利用状況データを分析 + 他社の事例調査。わかったこと:
- 予約されているのに空室の会議室が30%ある（ゴースト予約）
- 少人数なのに大会議室を予約する人が多い
- 「念のため1時間押さえる」が常態化している
定義（収束）: 本質的な課題は「予約UIが悪い」ではなく、「予約したまま使わない / 必要以上に押さえる行動パターン」だった。→ HMW: 「どうすれば、会議室が必要な人が必要なだけ使える状態を作れるか？」
第2ダイヤモンド（正しい解決策を作る）
展開（発散）: 自動キャンセル機能、チェックイン制、利用率の可視化、適正サイズの自動提案、予約時間の上限設定……20個のアイデア。
実現（収束）: 「開始5分以内にチェックインしなければ自動キャンセル」+「利用率ダッシュボード公開」を選定。2週間でプロトタイプを作り、1フロアでテスト導入。結果、ゴースト予約が70%減少。全社展開へ。
最初に「予約UIを改善」に飛びついていたら、根本的な課題は解決しなかった。
全国120店舗のカフェチェーン。モバイルオーダーアプリの利用率が15%と低迷し、店舗レジの行列が解消しない。
第1ダイヤモンド
発見（発散）: 顧客20人にインタビュー + 店頭観察3店舗 + アプリログ分析。
- アプリDL済みユーザーの40%が一度も注文していない
- カスタマイズ（ミルク変更、サイズ、トッピング）の操作で58%が離脱
- 「結局レジで聞かれるからアプリの意味がない」という声が複数
定義（収束）: HMW: 「どうすれば、レジより早くて確実にカスタマイズ注文ができる体験を作れるか？」
第2ダイヤモンド
展開（発散）: カスタマイズUIの再設計、お気に入り注文のワンタップ再注文、QRコード読み取りで前回注文を再現、音声注文、写真でメニュー選択……18個のアイデア。
実現（収束）: 「お気に入りワンタップ再注文」+「カスタマイズを3ステップに統一」を選定。ペーパープロトで10人にテスト後、5店舗でA/Bテスト。
結果（2ヶ月後）:
- モバイルオーダー利用率: 15% → 38%
- 注文完了までの平均時間: 3分12秒 → 47秒
- ピーク時のレジ待ち時間: 平均8分 → 平均3分
「カスタマイズの複雑さ」が真の課題。UIの色やレイアウトを変えても解決しない問題だった。
預金残高1.2兆円、顧客数18万人の地方信用金庫。オンラインバンキングの登録率は35%あるが、月間ログイン率が12%と極端に低い。
第1ダイヤモンド
発見（発散）: 顧客10人（60〜75歳中心）に自宅訪問インタビュー + 窓口職員8人にヒアリング + ログデータ分析。
- 登録はしたが「使い方がわからず放置」が大半
- パスワードを忘れて再設定→また忘れるの繰り返し
- 「振込を間違えたら取り消せないのが怖い」
定義（収束）: HMW: 「どうすれば、ITに不慣れな顧客が安心してオンラインバンキングを日常的に使えるようになるか？」
第2ダイヤモンド
展開（発散）: 生体認証ログイン、振込の確認画面強化、窓口での操作サポート、家族が代理操作できる機能、操作練習モード……15個。
実現（収束）: 「指紋ログイン + 振込前の電話確認オプション + 窓口での初回操作体験会」を選定。3支店でパイロット実施。
結果（3ヶ月後）:
- 月間ログイン率: 12% → 34%
- 60歳以上のアクティブ率: 5% → 22%
- 窓口来店数: 月平均820件 → 620件（24%削減）
- 顧客満足度調査: 「便利になった」回答率72%
「UIを若者向けに洗練させる」ではなく「不安を取り除く」が正解だった。課題を正しく定義した効果。
やりがちな失敗パターン#
- 発散フェーズで早々に判断してしまう — 「それは無理」「予算がない」と言った瞬間に発散が止まる。発散と収束は明確に分けて、発散中は批判禁止のルールを徹底する
- 第1ダイヤモンドを飛ばす — 「課題はもうわかっている」と思い込んでいきなり解決策を考え始める。これが最大の失敗パターン。課題の発見にこそ時間を使う
- 収束フェーズで「全部やろう」とする — 絞り込めずに中途半端な施策が乱立する。収束フェーズでは勇気を持って捨てることが重要
- テストなしでリリースする — 第2ダイヤモンドの収束で選んだ解決策をプロトタイプでテストせずに本実装に進む。「正しいと思った解決策」が実際に機能するかはテストするまでわからない
まとめ#
ダブルダイヤモンドは「正しい課題を見つけること」と「正しい解決策を作ること」の2段階を、それぞれ「発散→収束」で進めるデザインプロセス。最大のメッセージは「いきなり解決策に飛びつくな」ということ。課題を広く探り、絞り込んでから、初めて解決策を考える。このプロセスを意識するだけで、「作ったのに使われない」という悲劇を大幅に減らせる。