「解決策を考える前に、正しい問題を見つけること」——この原則はデザイン思考の文脈で繰り返し語られます。けれど実際に現場でこれを構造として実行できている組織は、想像以上に少ない。

ダブルダイヤモンドは、この原則を「見える形にしたフレームワーク」です。問題空間と解決空間を明確に分離し、それぞれの中で発散と収束のリズムを踏む。この構造を視覚化したことで、英国Design Councilが2004年に発表し2005年に体系化した同モデルは、世界中のデザイナーとビジネスパーソンに使われ続けています。

ダブルダイヤモンドとは——Design Council UKの4フェーズモデル

ダブルダイヤモンドは、英国Design Councilが2004年に発表し、2005年の調査報告書 “A Study of the Design Process” で体系化したデザインプロセスモデルです。Alessi、BSkyB、BT、LEGO、Microsoft、Sony、Starbucks、Virgin Atlantic Airways、Whirlpool、Xerox、Yahoo!——11グローバル企業のデザイン部門を対象とした定性調査を基盤に、優れたデザインプロセスに共通する構造を抽出したものです。

この調査は後に “Eleven Lessons: Managing Design in Eleven Global Brands”（2007年）としても刊行されています。

モデルの名称が示すように、形状は2つのダイヤモンド（菱形）が横に並んだ構造を取ります。左のダイヤモンドが「問題空間」、右のダイヤモンドが「解決空間」です。4つのフェーズはそれぞれのフェーズ頭文字から「4Dモデル」とも呼ばれます。

フェーズ	空間	動き	問い
Discover（発見）	問題空間	発散	何が起きているのか？
Define（定義）	問題空間	収束	本当の問題は何か？
Develop（開発）	解決空間	発散	どんな解決策があるか？
Deliver（提供）	解決空間	収束	何を実装するか？

なぜ「2つのダイヤモンド」なのか——発散と収束の構造

ダブルダイヤモンドが他のフレームワークと一線を画す理由は、「問題を決める前に解決策を考えてはならない」という制約を、構造として明示していることにあります。

ほとんどの問題解決プロセスは、問題が与えられた段階から始まります。「売上が下がっている→どうすれば回復するか」という流れで、解決策の検討にすぐ入ります。しかし実際のプロジェクト現場では、最初に提示される「問題」そのものが誤っていることが珍しくありません。

たとえば「ウェブサイトのコンバージョン率を上げたい」というオーダーで始まったプロジェクトが、ユーザーリサーチの結果「そもそも商品自体のポジショニングが合っていない」という根本的なズレを発見する——これはよくある展開です。第1ダイヤモンドなしに第2ダイヤモンドに入っていたら、間違った問題に対して正しい解決策を作り続けることになります。

「発散→収束」を2回繰り返すリズムも、このフレームワークの核心です。発散とは「多様な情報・視点・アイデアを集める」動き、収束とは「優先順位をつけ、選択する」動きです。問題空間と解決空間のそれぞれで、この2つのリズムを踏むことで、思い込みではなくエビデンスに基づいた問題定義と解決策設計が可能になります。

Phase 1: Discover（発見）——問題空間を広げる

Discoverフェーズは、「自分たちが問題だと思っていることが、本当に問題かを疑うことから始まる」フェーズです。課題を取り巻く状況・ユーザーの行動・文脈を広く探索し、多様な視点と情報を収集します。

このフェーズで最も重要な構えは「知らないことを知る」姿勢——チームが持っている仮説を一時的に脇に置き、フィールドに出て一次情報を集めることです。

インタビュー——表層の言葉の奥へ

半構造化インタビューは、Discoverフェーズの中核的なリサーチ手法です。事前に主要な問いを設定しつつ、会話の流れに応じて深掘りするスタイルで行います。重要なのは、回答を分析しながら聞くのではなく、まず「聞くこと」に徹することです。

「なぜそうしているのですか？」という問いへの最初の答えは、多くの場合社会的に期待される回答です。「なぜ？」を3〜5回繰り返すことで、行動の背後にある本当の動機が現れ始めます。 インタビュー中に「それは予想していなかった」と感じた瞬間こそ、最も価値あるデータです。

観察とシャドーイング——言葉にならない行動を見る

インタビューで語られることと、実際の行動は一致しないことがよくあります。観察（フィールドリサーチ）は、ユーザーが自覚していない行動パターンや環境の影響を見るための手法です。

シャドーイングは、許可を得てユーザーの日常行動に同行する手法です。実際にやってみると、「インタビューでは〜と言っていたのに、実際は真逆の行動をしていた」という発見がよく生まれます。この「言葉と行動のギャップ」に、最も価値あるインサイトが隠れています。

デスクリサーチと量的データ

一次リサーチと並行して、既存の調査レポート、競合分析、統計データなども幅広く収集します。フィールドで観察した個別の事例が、量的データの傾向と照合されたときに初めて「インサイト」としての信頼性が上がります。

Phase 2: Define（定義）——問題を絞り込む

Defineフェーズは、Discoverで集めた大量の情報を整理し、「本当に解くべき問題」を1〜2文で定義するフェーズです。発散から収束へ——この転換点はダブルダイヤモンド全体の中で最も意思決定の密度が高い場所です。

親和図法でインサイトを構造化する

インタビュー・観察・デスクリサーチで集まった情報は、まず親和図法（Affinity Diagram）で整理します。付箋1枚に1つの観察事項を書き、類似したものをグルーピングしていくプロセスで、個別の事実が「傾向」や「パターン」へと昇格します。

グルーピングの段階でチームメンバーが「あ、それって私のインタビューでも出てきた」という連鎖反応が起きる——この交差点が「インサイト」の候補です。

POVステートメント——問題定義の形式

Defineフェーズのアウトプットは、POVステートメント（Point of View Statement）と呼ばれる問題定義文です。d.schoolの形式を借りると、「[ユーザー像] は [ニーズ] を必要としている。なぜなら [インサイト] だから」という構造で記述します。

優れたPOVステートメントは、解決策の方向を決めずに問題の本質を示します。「高齢ユーザーは読みやすいフォントを必要としている」は解決策を含んでいます。「高齢ユーザーは情報の信頼性を確かめる手段を必要としている。なぜなら、画面上の情報の真偽を判断する基準を持っていないから」という形が、より良い問題定義です。

“How Might We”——問いに変換する

POVステートメントを、How Might We（HMW）の問いに変換することで、次のDevelopフェーズへの橋渡しができます。「どうすれば〜できるだろうか？」という問いの形式は、問題の記述を可能性の探索へと転換します。

Phase 3: Develop（開発）——解決空間を広げる

Developフェーズは、Defineで絞り込んだ問いに対して、多様な解決策のアイデアを大量に発想するフェーズです。解決空間における「発散」の段階に当たります。

アイディエーションの原則

アイディエーション（発散的思考）のセッションでは、「量を優先する」「判断を保留する」「他者のアイデアに乗る」という基本原則を守ります。最初の20分で出るアイデアは、すでにチーム全員が知っているものです。 本当に新しいアイデアは、それを使い切った後に現れます。

ブレインストーミングの現場

声の大きな参加者のアイデアに引っ張られて、全員が似たような方向に収束してしまう——ブレストセッションでは頻繁に起きます。有効な対策がブレインライティング（各自が付箋にアイデアを書いてから共有する方式）と、Crazy 8s（8分間で8つのアイデアをスケッチする手法）の組み合わせです。

個人でアイデアを出してから共有するプロセスを挟むことで、発声力と発想力の分離が生まれます。実際にやってみると、普段の会議では発言しない参加者が最も鋭いアイデアを出してくることが多いです。

共創ワークショップ——ユーザーを巻き込む

Developフェーズで見落とされがちだが効果が大きい実践が、ユーザー・顧客・エンドユーザーをアイデア発想のプロセスそのものに参加させる共創（Co-creation）です。チーム内のブレストで出たアイデアと、ユーザーと一緒に発想したアイデアでは、実装後の受容性が大きく異なります。

2時間のワークショップに数名のユーザーを招き、HMWを共有した上でアイデア出しを一緒に行う。このプロセスで生まれたアイデアは、「ユーザーが自分でも言語化できていなかったニーズ」に対応することが多いです。

Phase 4: Deliver（提供）——解決策を絞り込み実装へ

Deliverフェーズは、Developで発散したアイデアを絞り込み、プロトタイプで検証しながら実装可能な解決策に仕上げるフェーズです。解決空間の収束段階です。

低忠実度プロトタイプから始める

プロトタイプの目的は「完成品を作ること」ではなく、「アイデアを検証可能な形に外部化すること」です。紙とペンで描いたスケッチ（ペーパープロトタイプ）は、デジタルで作り込んだUIよりも多くの場合有効です。作るコストが低いため、フィードバックを受けても「もう変えたくない」という心理的抵抗が生まれにくいからです。

素材は何でも構いません。付箋、段ボール、マスキングテープ、PowerPoint——重要なのは「動く」「触れる」「体験できる」状態にすることです。 サービスのプロトタイプなら、社内のメンバーがロールプレイで「サービス提供者を演じる」ウィザード・オブ・オズ手法も有効です。

ユーザーテストとフィードバックループ

プロトタイプができたら、実際のユーザーに体験してもらい、行動を観察します。 ここでの重要な構えは「仮説の証明」ではなく「想定外の発見」を目指すことです。

テストセッション中に観察すべきは「ユーザーが詰まる場所」と「予期しない使い方をする瞬間」です。上手くいかなかった場面の方が、上手くいった場面より多くを教えてくれます。 フィードバックを受けてプロトタイプを修正し、再びテストする——このイテレーションを素早く回すことがDeliver フェーズの核心です。

実装への接続

Deliverフェーズの終端は「完成」ではなく「実装可能な状態への到達」です。プロトタイプが一定の検証を経たら、開発・調達・組織的意思決定のプロセスへと接続する「ハンドオフ」が必要です。このハンドオフを設計しないと、精度の高いプロトタイプが完成しても実装に至らない「ポートフォリオの肥やし」になります。

Framework for Innovation（2019改訂版）との違い

Design Councilは2019年、オリジナルのダブルダイヤモンドを発展させた“Framework for Innovation”（イノベーションのためのフレームワーク）を発表しました。4フェーズの基本構造は維持しながら、以下の4原則を追加したのが主な変更点です。

原則	内容
Put People First（人間中心）	サービス利用者のニーズ・強み・意欲を起点に設計を始める
Communicate Visually and Inclusively（視覚的・包摂的なコミュニケーション）	問題とアイデアの共通理解をビジュアルで形成する
Collaborate and Co-create（協働と共創）	多様な関係者と協力し、他の実践から学ぶ
Iterate, Iterate, Iterate（反復する）	早期にエラーを発見し、リスクを抑え、アイデアへの確信を積み上げる

2005年版が「何をどの順番でやるか（プロセス）」を示したものだとすると、2019年版は「なぜそのプロセスが機能するか（文化・組織・原則）」まで射程を広げたモデルと言えます。単発プロジェクトだけでなく、組織レベルでデザイン思考を定着させようとする文脈では、2019年版の4原則が強力な補助線になります。

IDEO 5ステップ・Design Sprint・デザイン思考との関係

ダブルダイヤモンドは、しばしばIDEOのデザイン思考5ステップやGoogleのDesign Sprintと混同されます。それぞれの位置づけを整理します。

観点	ダブルダイヤモンド	IDEO 5ステップ	Design Sprint
発祥	Design Council UK（2004/2005）	IDEO / Stanford d.school（2000年代）	Google Ventures（2010年代）
フェーズ/日程	4フェーズ（期間は可変）	5フェーズ（Empathize / Define / Ideate / Prototype / Test）	5日間固定
最大の特徴	問題空間と解決空間の明確な分離	共感（Empathize）を独立フェーズとして強調	時間制約による意思決定の加速
主な活用文脈	サービスデザイン・政策デザイン	プロダクト開発・イノベーション教育	スタートアップ・新機能検証
イテレーション	フェーズ間の往復を許容	5フェーズの反復を前提	1スプリント完結が基本
適した組織規模	中〜大規模、行政・公共系	スタートアップ〜大企業	小〜中規模チーム

3つはそれぞれ独立したフレームワークではなく、互いに補完関係にあります。 ダブルダイヤモンドの第1ダイヤモンド（Discover + Define）は、IDEOの「Empathize + Define」とほぼ対応し、第2ダイヤモンド（Develop + Deliver）は「Ideate + Prototype + Test」に対応します。Design Sprintはダブルダイヤモンドの第2ダイヤモンドを5日間に圧縮したプロセスと見ることもできます。

「どれを使うか」より「なぜその構造が有効か」を理解することで、プロジェクトの性質に応じた使い分けが可能になります。

日本企業での適用

ダブルダイヤモンドの構造は、公開情報の範囲で複数の日本企業・組織での実践が確認できます。

製造業の新規事業開発では、既存製品の改良から「ユーザーの業務フロー全体の最適化」への問題定義の転換が繰り返し報告されています。このパターンは、Discoverフェーズで現場リサーチを丁寧に実施し、「製品の機能」ではなく「ユーザーの仕事の文脈」を理解したことで生まれます。「何を改善するか」より先に「何が本当の問題か」を問うフェーズへの投資が、問題定義のジャンプを可能にします。

行政・公共セクターでは、サービスデザインの手法としてダブルダイヤモンドが徐々に参照されています。2019年のDesign Council版が政策デザインへの適用を明示的に示したことで、デジタル庁や自治体のUX改善プロジェクトでの参照事例が増えています。行政の文脈での特徴は、ステークホルダーの多様性（市民・職員・政策立案者）を、Discoverフェーズで並行してカバーする必要がある点です。

コンサルティング・アドバイザリー企業では、クライアントへのデリバリープロセスそのものをダブルダイヤモンド構造で設計するアプローチが見られます。プロジェクト開始時に「私たちがあなたの問題だと思っているものを、一旦疑います」という合意を取ることで、第1ダイヤモンドへの正当な時間投資が可能になります。

ダブルダイヤモンド実践の落とし穴

第1ダイヤモンドの省略

最も頻度が高い失敗は、Discoverフェーズを簡略化してDefineから始めることです。「問題はすでにわかっている」「時間がない」という理由で、最初の発散フェーズを省略すると、残り3フェーズを通じて間違った問いに答え続けることになります。

実際にやってみると、第1ダイヤモンドを省略したプロジェクトは、Deliverフェーズの終盤で「そもそも、この問題で正しかったのか？」という疑問が噴出するケースが多いです。手戻りのコストは、プロセスの後半になるほど高くなります。

発散の不徹底

「1時間のブレインストーミングをやった」「アイデアが30個出た」という報告の裏側に、「最初の5分で全員が同じ方向のアイデアを出し、それを30個に増やした」だけというパターンが潜んでいることがよくあります。発散とは「方向の多様性」を増やすことであり、量を増やすことではありません。

ファシリテーターとしての対策は、「全員のアイデアに方向性の多様性があるか」を中間点でチェックすることです。似たアイデアが集まっていたら、「それとは正反対の方向は？」「まったく違うユーザー層に使ってもらうとしたら？」という問いで、強制的に視点を変えます。

収束の合意形成の難しさ

DefineフェーズとDeliverフェーズは、どちらも「選択する」という収束の動きが必要です。選択には必ず「選ばれないもの」が生まれ、これがチーム内の摩擦や組織的な抵抗につながります。

有効な対策は、収束の基準を発散フェーズが始まる前に合意しておくことです。「私たちは何を優先するか（ユーザー体験か？技術的実現可能性か？コストか？）」という判断基準を先に決めておくと、収束の際の議論が「好み」から「基準への照合」に変わります。

フェーズ間の硬直化

ダブルダイヤモンドを「順番に進めなければならないウォーターフォール」として解釈すると、Defineフェーズで新たなユーザーリサーチが必要になっても「もうDiscoverは終わった」と戻れなくなります。フレームワークはプロセスの方向性を示すものであり、逆行を禁じるものではありません。

2019年版のFramework for Innovationが4フェーズを矢印ではなくサイクルとして描いているのは、この「往復」を明示的に許容するためです。「今、このフェーズにいる」という感覚を共有しつつも、必要であれば前のフェーズに戻る判断を恐れないことが、長期的にはプロジェクト品質を高めます。

明日のミーティングから使える1ステップ

ダブルダイヤモンドの本格導入の前に、明日から試せる構造的な問いかけがひとつあります。

次のプロジェクトキックオフで、解決策の議論を始める前に「この問題が本当の問題かどうか、どうやって確認するか？」という問いを10分間チームに投げかけてください。

「問題は上から与えられた」「前回のプロジェクトで確認済み」——こうした返答が出てきた場合、第1ダイヤモンドへの投資を後回しにする空気がすでにチームに存在しています。この問いへの反応を観察するだけで、「自分たちがどのフェーズから始めているか」が可視化されます。

10分の問いかけが、プロジェクト後半での大きな手戻りを防ぐ最初の一手になります。問題定義への投資は、解決策の品質を担保する合理的な判断——それがダブルダイヤモンドの出発点です。

参考文献

Design Council, A Study of the Design Process (“The Double Diamond”), Design Council, 2005. [designcouncil.org.uk]
Design Council, “What is the Framework for Innovation? Design Council’s evolved Double Diamond”, designcouncil.org.uk, 2019（2022年改訂）
Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009
Jake Knapp, John Zeratsky & Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016
Stanford d.school, An Introduction to Design Thinking: Process Guide, Institute of Design at Stanford, 2010（改訂版2018）
IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015