ダブルダイヤモンドとは何か——なぜ「問題空間」と「解決空間」を分けるのか

ダブルダイヤモンド（Double Diamond）は、「正しい問題を見つけてから、正しい解決策を作る」という設計原理を視覚化したフレームワークです。英国Design Councilが2004年に発表し、世界中のデザイン教育・ビジネス実務で標準的なプロセスモデルとして活用されています。

一文で定義すると、ダブルダイヤモンドとは「問題空間」と「解決空間」を分離し、それぞれで発散と収束を1往復ずつ行う4フェーズのプロセスです。用語の定義だけを素早く確認したい場合は用語辞典のダブルダイヤモンド項目へどうぞ。

この構造がなぜ機能するのかという理論的背景に加えて、実務で起きやすい失敗パターンと業種別の適用例を厚く扱う点が、実践ガイドとの役割分担です。各フェーズの具体的な進め方（インタビュー設計、親和図法の手順、プロトタイピングの手法）まで手順として知りたい場合はダブルダイヤモンド実践ガイドを合わせて読んでください。

「解決策はあるのに、問題が間違っている」という落とし穴

プロダクト開発やサービス改善の現場で、こんな事態が起きていないでしょうか。ユーザーが離脱する原因を「UIの分かりにくさ」だと断定し、画面を全面リニューアルしたのに、離脱率が変わらない。 後から調べてみたら、問題はUIではなく料金体系にあった。

ワークショップでよく起こるのは、課題が十分に探索されないまま解決策の議論に突入するパターンです。「解決策を考えるのは楽しいが、問題を掘り下げるのは地味で退屈」という心理が、チームを誤った方向に導きます。

この「焦り」には構造的な理由がある

実際にやってみると、チームが解決策に飛びつく背景には理由があります。進捗を示さなければならないプレッシャー、上層部への報告、四半期ごとの成果要求。 「まだ問題を探索しています」という報告は、組織内で評価されにくい。

結果として、最初に思いついた仮説をそのまま正式な「問題定義」にしてしまう。この構造的なバイアスに対抗するために、ダブルダイヤモンドは「問題の探索にも十分な時間を使え」と明示的にプロセスに組み込んだのです。

4フェーズという構造：分けることの意味

Design Councilは2004年にこのモデルを発表し、翌2005年の調査報告書「A Study of the Design Process」で、11社のグローバル企業のデザインプロセスを詳細に調査し、成功するプロジェクトに共通するパターンを4つのフェーズ――Discover、Define、Develop、Deliverとして体系化しました。この調査は2007年に「Eleven Lessons: Managing Design in Eleven Global Brands」として刊行されています。

第1ダイヤモンド：正しい問題を見つける

**Discover（発見）では、「問題はすでに分かっている」という前提をいったん脇に置き、課題領域を広く探索します。続くDefine（定義）**で、その情報を「解くべき本質的な問題」1つへ収束させる。ここで作られる問いこそが、第2ダイヤモンドの出発点だ。問題定義の質が最終的なソリューションの質を決定するため、特に唯一の正解が存在しないウィキッド・プロブレムに取り組む場合、この絞り込みを急がないことが後工程全体の質を左右します。

第2ダイヤモンド：正しい解決策を作る

Develop（開発）で解決策の選択肢を多様なアプローチから幅広く発想し、**Deliver（提供）でプロトタイプとユーザーテストを通じて1つの解決策へ絞り込み実装します。重要なのは、第1ダイヤモンドで定めた問いに対してのみこの探索が始まるという順序そのものです。「最初のアイデアがベストであることは、ほぼない」**という前提に立つからこそ、Develop フェーズでの発散が意味を持ちます。

各フェーズで実際に何をするか（インタビュー設計、親和図法（KJ法）の進め方、Crazy 8sなどのプロトタイピング手順）を1つずつ知りたい場合はダブルダイヤモンド実践ガイドにまとめています。構造の理由を押さえたところで、続いて実務のつまずきどころを具体的に見ていく。

実務でよくある5つの失敗パターン

ダブルダイヤモンドの理論を理解していても、実際に運用すると同じ失敗が繰り返されます。特によく見られる5つのパターンを、原因と対策とあわせて挙げます。

1. Discoverを「情報収集タスク」として消化してしまう: Discoverフェーズを、期日までにインタビュー件数やアンケート回収数をこなす作業だと捉えてしまうケースです。件数は集まっても、チームの問題理解が更新されないまま次工程に進んでしまうため、Defineの収束が最初の思い込みをなぞるだけで終わります。対策は、Discoverの終了条件を「当初の仮説が崩れた回数」で定義することです。

2. Defineで「多数決」が起きる: 収束フェーズで、集まった情報の中から声の大きい人の意見や、経営層が期待していそうな結論を選んでしまうケースです。Defineは本来、集めた事実から論理的に導かれる問いを選ぶ工程ですが、合意形成の場に変質すると、最初から答えが決まっていたのと同じ結果になります。問題定義案を提出する際は、根拠となったデータや発言を必ず添付するルールを設けておく。

3. Developで「実現可能性」を先に評価してしまう: 発散フェーズであるDevelopで、「予算的に無理」「技術的に難しい」という評価を早期に始めてしまうケースです。評価は収束フェーズであるDeliverの役割であり、Developで評価を始めると選択肢の幅が狭まり、最初に思いついた無難な案しか残りません。Develop中は評価コメントそのものを禁止し、アイデア出しの場と評価の場を分けてしまうのが手っ取り早い。

4. Deliverでプロトタイプを作らずに実装へ進む: 納期が迫っていることを理由に、Deliverのプロトタイプ検証を省略していきなり本実装に入るケースです。検証されていない解決策が的外れだった場合、実装後の手戻りコストはプロトタイプ段階で修正するよりもはるかに大きくなります。対策は、どれほど納期が厳しくても「最小限のプロトタイプで1回だけ確認する」工程を死守することだ。

5. フェーズの往復を「計画の失敗」だと捉えてしまう: Developで検討した結果、Defineの問題定義に戻る必要が生じたときに、それを計画通りに進まなかった失敗だと捉えてしまうケースです。ダブルダイヤモンドは本来フェーズを行き来する前提のフレームワークであるため、往復自体は正常な動作だ。対策は、プロジェクト開始時点で「後戻りが起きうる」ことをステークホルダーへ事前共有し、往復を精度向上の工程として位置づけておくことです。

業種別に見る適用例

抽象的な説明だけでは、実務にどう落とし込むかがつかみにくいままです。3つの異なる業種で、4フェーズがどう機能するかを見てみます。ここに登場する企業名・数値は、構造を理解するための仮想シナリオです。

SaaS：解約直前の離脱率改善

Discover（発見）: チームは「UIが分かりにくいから離脱する」という仮説を検証しないまま、リニューアル案の検討に入っていました。ここでDiscoverをやり直すとしたら、まずやるべきはユーザーインタビューと行動ログの突き合わせです。画面遷移ログを見ると、離脱の多くは「料金確認画面」の直前で起きていました。

Define（定義）: 集めた情報を1つの問いに収束させます。「UIの分かりにくさ」ではなく、「料金体系が事前に把握できないことへの不安」。この収束作業こそが第1ダイヤモンドの本体です。

Develop（開発）: 問いが変われば、発想の幅も変わります。料金シミュレーター、段階的な見積り表示、担当者への即時チャット――UIの改修は、数ある選択肢の1つでしかない。

Deliver（提供）: 料金シミュレーターのプロトタイプを作り、一部ユーザーへ試験提供します。効果が確認できた案だけを、本実装に進めます。

行政サービス：申請手続きのオンライン化

Discover: 「申請フォームが複雑だから利用率が低い」という仮説のもと、UI改善だけを検討していました。窓口担当者への聞き取りを行うと、離脱の多くは添付書類の準備段階、つまりフォームを開く前で起きていることが分かりました。

Define: 問いを「フォームの分かりやすさ」から「申請前に何が必要かが事前に分からない不安」へ収束させます。

Develop: 必要書類を事前診断するチェックリスト、窓口での書類代行サービス、オンライン申請前の相談チャットなど、フォーム改修とは別方向の選択肢が広がる。

Deliver: 必要書類の事前診断チェックリストを試験提供し、申請完了率を計測します。

製造業：新製品の企画会議

Discover: 「若年層に売れていないのはデザインが古いから」という仮説から、デザイン刷新の議論に入っていました。営業データを見ると、購入層自体が想定と異なり、若年層は認知の時点で離脱していることが判明します。

Define: 問いを「デザインの古さ」から「若年層に商品の存在自体が届いていないこと」へ収束させる。

Develop: デザイン刷新は選択肢の1つに後退し、販路の見直し、SNSでの見せ方、価格帯の再設計など、認知経路そのものを変える案が浮上します。

Deliver: 低コストで試せる販路（SNS広告の小規模テスト）から着手し、反応を見て投資判断します。

3業種に共通しているのは、最初の仮説（UI・フォーム・デザイン）が、Discoverのやり直しによって覆った点です。 問いを立て直すことなく解決策に進んでいたら、いずれも成果は出なかったはずです。

d.schoolの5フェーズモデルとの比較

ダブルダイヤモンドとd.schoolのデザイン思考5フェーズは、よく比較されます。本質的な思想は共通しているが、強調するポイントが異なる。

観点	ダブルダイヤモンド	d.school 5フェーズ
発祥	英国Design Council（2004年）	スタンフォード大学（2005年）
フェーズ数	4（Discover / Define / Develop / Deliver）	5（Empathize / Define / Ideate / Prototype / Test）
最大の特徴	発散と収束のリズムを明示	共感（Empathize）を独立フェーズとして重視
プロセス観	2つのダイヤモンド＝問題空間と解決空間の分離	5フェーズの反復（イテレーション）
主な活用文脈	サービスデザイン、政策デザイン	プロダクト開発、イノベーション教育

d.schoolモデルが「共感から始める」ことを強調するのに対し、ダブルダイヤモンドは「問題の探索と解決策の探索を明確に分ける」ことを強調します。プロジェクトの性質に応じて使い分けるのが現実的です。

使い分けの目安は「問題の輪郭がどれだけ見えているか」です。行政のサービス改善のように関係者が多く、そもそも何が課題かの合意すら取れていない場合は、問題空間と解決空間を明確に切り分けるダブルダイヤモンドの構造が効きます。逆に、プロダクトの新機能開発のように課題自体は共有されていて、ユーザーへの共感を起点に素早くアイデアへ落とし込みたい場合は、Empathizeを独立フェーズに置くd.schoolモデルの方が着手しやすいことが多いです。

2019年の進化：プロセスから文化へ

Design Councilは2019年に、ダブルダイヤモンドを拡張したFramework for Innovationを発表しました。2004年に発表され2005年の調査報告書で体系化された初版が「何をどの順番でやるか」というプロセスを定義したのに対し、2019年版は人間中心・視覚的コミュニケーション・協働・反復という4つのデザイン原則を加え、組織文化やリーダーシップといった実行環境まで視野を広げています。

この拡張は、プロセスモデルだけでは現場の変革は起きないという、Design Councilの15年にわたる運用実績から得た教訓を反映したものです。原則ごとの具体的な運用方法は実践ガイドで扱っているため、ここでは「プロセスから文化へ」という射程の拡張だけを押さえておく。

ダブルダイヤモンドの限界として指摘されること

上で挙げたのはチームの運用によって起きる失敗ですが、ここではフレームワークそのものに内在する限界を扱います。導入・運用する前に押さえておくべき限界が、少なくとも3つあります。

図の直線性と実務のギャップ: 2つの菱形として描かれる図は美しく分かりやすい一方、実際のプロジェクトはフェーズを何度も行き来するため、図通りに直線的に進むケースはむしろ稀です。図を「順守すべき手順」だと誤解すると、かえって柔軟な手戻りを妨げます。

期間・予算が固定されたプロジェクトとの相性: 第1ダイヤモンドに十分な時間を割く前提のフレームワークであるため、納期と予算が先に固定されているプロジェクトでは、Discoverフェーズが形骸化しやすいという制約が生じます。この場合、無理にダブルダイヤモンド全体を適用するより、問題定義がすでに済んでいる前提で第2ダイヤモンドに近い性質を持つ手法（後述のデザインスプリントなど）と組み合わせる判断も現実的です。

「発散」の質はフレームワークが保証しない: ダブルダイヤモンドはあくまで思考の型であり、Discoverでどれだけ多様な情報を集められるか、Developでどれだけ幅広い解決策を発想できるかは、フレームワークそのものではなく実施するチームのスキルと時間投資が決める。

日本企業でこの構造が機能しにくい理論的な理由

ダブルダイヤモンドの理論そのものは万国共通ですが、日本企業でこの構造を導入しようとすると、強い抵抗に遭うことがあります。その原因の多くは手法の理解不足ではなく、意思決定の構造にある。

稟議制度や多階層の合意形成プロセスでは、「まだ結論が出ていない」という状態そのものが報告しにくいという力学が働きます。第1ダイヤモンドのDiscoverフェーズは本質的に「まだ問題が分かっていない」ことを前提にした発散フェーズですが、この状態を上長やクライアントへ正式な進捗として報告する仕組みが用意されていないケースが少なくありません。冒頭で述べた「進捗を示さなければならないプレッシャー」は、承認階層が多くなるほど増幅されます。

この構造的な摩擦を軽減するには、Discoverフェーズで何を「成果物」とみなすかを見直すとよい。「まだ分かっていないことのリスト」や「検証すべき仮説の数」を進捗指標として報告できるよう、プロジェクト開始前に合意しておく。業種別の理論的な適用の勘所は上の「業種別に見る適用例」で扱いましたが、日本企業特有の運用ノウハウ（社内の合意形成プロセスへの落とし込み方など）はダブルダイヤモンド実践ガイドの「日本企業での適用」でさらに詳しく紹介しています。

実務で使うための4つの指針

第1ダイヤモンドに十分な時間を投資する

多くのプロジェクトで、Discoverフェーズが不十分なまま解決策に進んでしまいます。全体の工程の少なくとも3分の1を、Discoverフェーズと Defineフェーズに割り当ててください。問題の理解が浅いまま作った解決策は、手戻りコストが膨大になります。

発散と収束を意識的に切り替える

「今は広げるフェーズか、絞るフェーズか」をチーム全員が共有できているかどうかで、議論の生産性は大きく変わる。 発散中に「それは現実的じゃない」と評価を始めたり、収束中に「もっと他の可能性は」と広げ始めたりするのは、プロセスの混乱を招きます。この2つのモード（発散思考と収束思考）は同時に成立しないため、「今どちらのモードにいるか」の明示だけでも会議の質は変わります。

直線的に進まなくてよい

ダブルダイヤモンドは直線的なプロセスに見えますが、実際にはフェーズ間を行き来するのが当然です。Developで解決策を検討した結果、問題定義に戻る必要が生じることは珍しくありません。図の美しさに縛られず、必要なときに戻る柔軟性を持ちましょう。

最初のミーティングで使える問いのテンプレート

Discoverフェーズの開始時に、次の3つの問いをチームで共有すると、思い込みでの飛びつきを防ぎやすくなります。

• 「この問題を、誰が最初にそう定義したか？」（声の大きい人の思いつきが問題定義になっていないか）
• 「この問題の裏付けとなるデータは何か？」（数値・ログ・インタビューなど、確認済みの根拠があるか）
• 「もし前提が違っていたら、どんな別の問題がありえるか？」（1つの仮説に固執していないか）

これらの問いに詰まるようであれば、それはまだDiscoverフェーズが終わっていないというサインです。

次に進める前に確認するチェックリスト

上で挙げた失敗パターンと指針を、フェーズの節目で確認できる形にまとめておきます。

• Discoverの終了条件を件数でなく「仮説が崩れた回数」で定義したか
• Define時の問題定義案に、根拠となったデータや発言を添付しているか
• Develop中に実現可能性の評価を始めていないか（評価はDeliverの役割）
• Deliver前に、最小限のプロトタイプ検証を確保しているか
• フェーズの後戻りが起こりうることを、ステークホルダーへ事前共有したか

まず「問い」を疑うことから始める

ダブルダイヤモンドが教える最も重要な教訓は、「正しい問いなしに、正しい答えは生まれない」ということです。新規事業の立ち上げ、サービスの改善、組織課題の解決。どんなプロジェクトであっても、解決策を考える前に「そもそもこの問いは正しいのか」と立ち止まる習慣が、成果の質を根本的に変えます。

次のプロジェクトで、最初のミーティングで解決策の議論を禁止してみてください。 代わりに「この問題について、私たちが知らないことは何か」を30分議論する。その30分が、数ヶ月の手戻りを防ぐかもしれません。

具体的な進め方（インタビュー手法、ワークショップ設計、実践の落とし穴）はダブルダイヤモンド実践ガイドへ。

よくある質問

ダブルダイヤモンドとは何ですか？

英国Design Councilが2004年に発表したプロセスモデルで、「正しい問題を発見してから、正しい解決策を作る」という2段階を、発散と収束のリズムで構造化したものです。問題空間・解決空間それぞれで発散と収束を1回ずつ踏むため、図が2つの菱形として描かれます。

なぜ「2つの」ダイヤモンドがあるのですか？

問題を定義する作業と解決策を作る作業を1本の流れにしてしまうと、多くの場合「最初に思いついた問題」に対して解決策を作ることになるからです。菱形を2つに分けることで、「まず問題を発散・収束させる」「次に解決策を発散・収束させる」という切り替えを構造として強制します。

ダブルダイヤモンドとd.schoolの5フェーズモデルの違いは何ですか？

上の比較表の通り、d.schoolモデルは共感（Empathize）を独立フェーズとして重視するのに対し、ダブルダイヤモンドは問題空間と解決空間の分離そのものを強調します。対立する理論ではなく、プロジェクトの性質に応じて使い分ける、あるいは併用するものです。

実務でよくある失敗にはどんなものがありますか？

最も多いのは、Discoverを情報収集の作業としてこなしてしまい、チームの問題理解が更新されないまま次工程に進むパターンです。ほかにも、Develop中に実現可能性の評価を始めてしまう失敗や、Deliverのプロトタイプ検証を省略していきなり実装してしまう失敗も典型的だ。詳細は本文「実務でよくある5つの失敗パターン」を参照してください。

UXデザイン以外の分野でも使えますか？

使えます。行政サービスの申請手続き改善や製造業の新製品企画など、「最初に立てた問いが本当に正しいか」を確認する必要がある場面であれば、業種を問わず適用できます。詳細は本文「業種別に見る適用例」を参照してください。

1人やスモールチームでも使えますか？

使えます。ダイヤモンドの形は複数人の合意形成を可視化する図でもありますが、核心は「発散では評価をしない」「収束では新しい選択肢を増やさない」という自分自身への規律です。1人での作業でも、この切り替えを意識するだけで問題定義の精度は変わります。

どんなプロジェクトに向いていますか？

サービスデザインや政策デザインのように、着手時点で「本当の問題」が曖昧なプロジェクトに特に向く。逆に問題がすでに明確で、解決策の検証速度が最優先なら、第2ダイヤモンドに近い性質を持つデザインスプリントのような手法の方が適しています。

ダブルダイヤモンドのデメリット・限界は何ですか？

図が直線的に見えるため実務での行き来を軽視しやすい点、納期・予算が先に固定されたプロジェクトではDiscoverフェーズが形骸化しやすい点、フレームワークそのものは発散の質を保証しない点が主な限界です。詳細は本文「ダブルダイヤモンドの限界として指摘されること」を参照してください。

ダブルダイヤモンドを初めて使うとき、何から始めればいいですか？

いきなり全社的なプロセスとして導入するのではなく、1つの小さなプロジェクトのDiscoverフェーズだけを試すのが現実的な出発点です。「この問題を、誰が最初にそう定義したか」を問い直すところから始めてください。具体的な進め方は実践ガイドにまとめています。

---

参考文献

• Design Council, “A Study of the Design Process”, 2005
• Design Council, “Eleven Lessons: Managing Design in Eleven Global Brands”, designcouncil.org.uk, 2007
• Design Council, “What is the framework for innovation? Design Council’s evolved Double Diamond”, designcouncil.org.uk, 2019
• Tim Brown, Change by Design, HarperBusiness, 2009