ダブルダイヤモンドとは？4つの段階・デザイン思考との違い・実践方法を徹底解説

新しい商品やサービスを企画するとき、すぐに解決策を考え始めてしまい、後から「そもそも解決すべき課題が違っていた」と気づくことがあります。機能を増やしても利用者に使われない、社内では高く評価された案が市場では受け入れられないといった失敗は、解決策の質だけでなく、課題の捉え方に原因がある場合も少なくありません。

ダブルダイヤモンドは、こうした問題を避けるために、課題を広く探索してから焦点を絞り、複数の解決策を考えてから実行案を選ぶ問題解決の枠組みです。発散と収束を二度繰り返す流れが、横に並んだ二つのひし形に見えることから、ダブルダイヤモンドと呼ばれています。

本記事では、ダブルダイヤモンドの意味や4つの段階だけでなく、デザイン思考との違い、利用者調査、課題設定、案の評価、チーム運用、失敗を防ぐ方法まで体系的に解説します。現場で使える記入形式や簡単なコード例も紹介するため、自社の企画、開発、業務改善に応用できます。

1. ダブルダイヤモンドとは

ダブルダイヤモンドとは、問題を正しく理解し、適切な解決策を生み出すために、発散と収束を二回繰り返す問題解決の枠組みです。最初のひし形では「何を解決するべきか」を明確にし、二つ目のひし形では「どのように解決するか」を具体化します。

1.1 発散と収束を二度繰り返す問題解決手法

発散とは、最初から選択肢を限定せず、観察結果、利用者の声、仮説、アイデアなどを幅広く集める活動です。反対に収束とは、集めた情報を比較し、目的や条件に合うものを選び、判断の焦点を明確にする活動を指します。

ダブルダイヤモンドでは、課題を考える場面と解決策を考える場面の両方で発散と収束を行います。最初から一つの答えに飛びつくのではなく、可能性を広げてから絞るため、思い込みによる判断を減らせます。

1.2 二つのひし形が表している意味

一つ目のひし形は、利用者や市場を広く調査し、複数の問題やニーズの候補を発見した後、取り組むべき課題を一つの方向へ整理する流れを表しています。左側では、インタビュー、観察、データ分析などを通じて情報を広く集める「発散」を行い、右側では、得られた情報を分類・分析し、優先して取り組む課題を明確にする「収束」を行います。

二つ目のひし形は、定義された課題に対して多様な解決案を考え、試作や検証を繰り返しながら、最終的に実行する解決策を決定する流れを表しています。最初から一つの案に絞り込むのではなく、複数のアイデアを比較し、利用者からのフィードバックや検証結果を基に改善することが重要です。

ダブルダイヤモンドでは、「正しい課題を見つけるプロセス」と「その課題に対する適切な解決策をつくるプロセス」が明確に分けられています。図の形や四つの段階の名称だけを覚えるのではなく、「課題」と「解決策」をそれぞれ別の対象として発散・収束させる点を理解することが重要です。

1.3 解決策より先に課題を確認する考え方

多くの企画会議では、「どの機能を追加するか」「どの技術を使うか」といった解決策から議論が始まります。しかし、利用者が本当に困っている理由を確認しないまま案を作ると、見当違いの改善を続けることになりかねません。

ダブルダイヤモンドでは、解決策を考える前に、観察や聞き取りを通じて課題の背景を確認します。表面的な要望をそのまま課題と捉えず、その要望が生まれた状況や目的まで掘り下げることで、より本質的な問題を見つけやすくなります。

1.4 商品開発以外にも利用できる理由

ダブルダイヤモンドは、商品やサービスの設計だけに限定された手法ではありません。社内業務の改善、採用活動、教育制度、公共サービス、販売方法、顧客対応など、正解が一つに決まっていない問題に幅広く利用できます。

どの分野でも、関係者の立場によって問題の見え方が異なり、最初から正しい答えが分からない状況があります。情報を広げて整理し、案を広げて検証するダブルダイヤモンドは、このような不確実性の高い課題と相性がよい手法です。

1.5 導入によって期待できる効果

ダブルダイヤモンドを導入すると、チーム内で現在の段階を共有しやすくなります。「今は課題を探索しているのか」「案を評価しているのか」が明確になるため、調査中に結論を急いだり、実行段階で新しい課題を追加したりする混乱を減らせます。

また、判断の根拠を記録しやすくなることも利点です。なぜその課題を選び、なぜその解決策を採用したのかを説明できるため、経営層や関係部署から合意を得る際にも役立ちます。

2. ダブルダイヤモンドが生まれた背景

ダブルダイヤモンドが広く使われるようになった背景には、商品やサービスを取り巻く環境の複雑化があります。利用者の価値観や行動が多様化する中では、過去の成功例や社内の経験だけで正しい課題と解決策を判断することが難しくなっています。

2.1 英国のデザイン分野で整理された枠組み

ダブルダイヤモンドは、デザインプロセスを分かりやすく説明し、組織の中で共有しやすくするために、英国のデザイン分野で整理された枠組みとして知られています。複雑で捉えにくかったデザインの進め方を、「発散」と「収束」が二回繰り返される図として可視化したことで、デザイナーだけでなく、企画担当者、開発者、経営者などもプロセスを理解しやすくなりました。

ダブルダイヤモンドが示される以前から、優れた設計者は、利用者や市場を調査し、情報を整理し、複数の案を試作しながら、より適切な解決策を選ぶ活動を行っていました。ダブルダイヤモンドは、まったく新しい作業方法を突然生み出したものではなく、従来から実践されていた探索、課題定義、試作、検証などの活動を、共通の枠組みとして整理したものです。

この枠組みの価値は、単純な図によってデザイン活動の全体像を共有できる点にあります。各段階で何を行っているのかが明確になるため、現在の進捗状況、次に必要な活動、判断が不足している部分などをチーム全体で確認しやすくなります。

ただし、図の形や四つの段階を形式的にまねるだけでは、ダブルダイヤモンドを適切に活用したことにはなりません。重要なのは、各段階でどのような情報を集め、何を基準に整理し、どのような根拠で次の段階へ進むのかを理解することです。枠組みを固定された手順として扱うのではなく、設計上の判断を支援する考え方として活用する必要があります。

2.2 市場の複雑化によって必要性が高まった理由

市場が比較的単純な場合は、利用者の要望を聞いて機能を追加するだけでも成果につながることがあります。しかし、競合商品が増え、利用者の選択肢が広がると、表面的な改善だけでは明確な差を作りにくくなります。

現在は、価格、使いやすさ、安心感、環境への配慮、購入後の体験など、複数の要因が意思決定に影響します。ダブルダイヤモンドは、こうした複雑な要因を最初から一つに決めつけず、広く調べてから重点を定めるために有効です。

2.3 組織内部の思い込みを減らす役割

長期間にわたって同じ商品やサービスを扱っている組織では、業界の慣習、過去の成功体験、社内で共有されている知識などが、無意識のうちに当然の前提として扱われやすくなります。専門知識や蓄積された経験は重要ですが、それだけを根拠に判断すると、利用者の実際の行動や市場の変化を見落とす可能性があります。

例えば、組織内では「利用者はこの機能を必要としている」「価格が購入を妨げている」「操作方法は十分に分かりやすい」と考えられていても、実際の利用者が同じように認識しているとは限りません。社内では合理的に見える説明であっても、利用者の状況や行動を確認しなければ、組織内部だけで通用する論理に偏ってしまいます。

ダブルダイヤモンドの探索段階では、利用者観察、インタビュー、アンケート、問い合わせ履歴、アクセスデータ、購買記録、操作ログなど、さまざまな方法を通じて事実を集めます。担当者の予想や意見から調査を始めることはできますが、それらを最初から正しい答えとして扱わず、検証すべき仮説として整理することが重要です。

このように、意見、経験、仮説、観察された事実を分けて扱うことで、議論を個人の立場や発言力だけに依存させず、確認可能な情報に基づいて進められます。ダブルダイヤモンドは、専門家の経験を否定するための枠組みではありません。経験から生まれた考えが、現在の利用者や市場の状況にも当てはまるかを検証するための枠組みです。

また、探索によって社内の想定とは異なる事実が見つかった場合、それを例外として排除するのではなく、なぜ認識の違いが生まれたのかを分析する必要があります。こうした姿勢によって、組織は過去の成功や内部の常識にとらわれず、利用者の現実に基づいて課題を定義し直すことができます。

2.4 部門を越えた共同作業に適している理由

新しい商品やサービスには、企画、営業、開発、広報、顧客対応など、多くの部門が関わります。それぞれが異なる指標や責任を持っているため、同じ議題を扱っていても、重要だと考える点が一致しない場合があります。

ダブルダイヤモンドを共通の進行図として利用すると、部門間の認識をそろえやすくなります。各部門の意見を発散段階で広く取り入れ、収束段階で判断基準を共有することで、一部門だけに偏った決定を防げます。

2.5 不確実な課題に向いている理由

原因と答えが明確な問題では、既存の手順や専門知識を使って素早く解決できます。一方で、「なぜ利用されないのか」「どのような体験が求められているのか」のような問いは、調査を始めるまで原因が分かりません。

ダブルダイヤモンドは、最初から正解を知っていることを前提にしない手法です。仮説を持ちながらも、新しい情報によって課題や案を修正できる構造になっているため、不確実性の高い企画や改善活動に適しています。

3. ダブルダイヤモンドの4つの段階

ダブルダイヤモンドは、探索、定義、展開、提供という4つの段階で構成されます。それぞれの段階には異なる目的があるため、調査、判断、発想、実行を一つの会議で同時に進めないことが重要です。

3.1 探索で利用者と状況を広く調べる

探索段階では、最初に設定した問題を絶対視せず、利用者の行動や周囲の状況を幅広く調査します。聞き取りだけでなく、実際の利用場面、問い合わせ、途中離脱、代替手段などを確認し、本人も言葉にできていない困りごとを探します。

この段階では、早く結論を出すことより、見落としていた可能性を発見することが優先されます。自社に都合のよい情報だけを集めず、当初の仮説に反する事実も残しておくことが、後の課題定義の精度を高めます。

3.2 定義で取り組むべき課題を絞る

定義段階では、探索で得た情報を分類し、繰り返し現れる行動、感情、障害、目的を整理します。そのうえで、誰が、どのような状況で、何を達成できずに困っているのかを、具体的な課題文として表します。

単に「売上が低い」「利用率が悪い」と書くだけでは、解決案の方向が定まりません。結果として現れている数値だけでなく、その数値を生み出している利用者側の障害まで明らかにする必要があります。

3.3 展開で複数の解決案を生み出す

展開段階では、定義した課題に対して、可能な解決案を幅広く考えます。現在の商品を改善する案だけでなく、提供方法を変える案、説明を減らす案、手続きをなくす案、他の手段に置き換える案なども検討します。

最初から実現可能性だけで案を狭めると、既存の延長線上にある案しか出なくなります。発想時には評価を急がず、一定数の案を出した後で、効果、費用、危険性、実行期間などの基準を使って比較します。

3.4 提供で試作と検証を繰り返す

提供段階では、選んだ解決案を試作品や小規模な実施方法に変え、実際の利用者や関係者に試してもらいます。完成品を作る前に反応を確認することで、方向が違っていた場合の損失を小さくできます。

検証では、好意的な感想だけを集めるのではなく、利用者が目的を達成できたかを観察します。操作時間、迷った場所、途中離脱、質問内容などを記録し、必要に応じて展開段階や定義段階へ戻ります。

3.5 各段階を行き来しながら進める

ダブルダイヤモンドは、4段階を一度だけ直線的に通過する仕組みではありません。試作品の検証によって課題の理解が誤っていたと分かれば、定義や探索に戻り、情報を追加して考え直す必要があります。

戻ることは失敗ではなく、早い時点で誤りを発見できたという成果です。ただし、理由なく何度も戻ると進行が止まるため、「どの事実によって前の段階へ戻るのか」という条件を決めておくと運用しやすくなります。

JavaScriptによる進行段階の管理例

const 段階一覧 = ["探索", "定義", "展開", "提供"];

function 次の段階を取得する(現在の段階) {
 const 現在位置 = 段階一覧.indexOf(現在の段階);

 if (現在位置 === -1) {
   throw new Error("登録されていない段階です。");
 }

 if (現在位置 === 段階一覧.length - 1) {
   return "検証結果を確認し、必要に応じて前の段階へ戻ります。";
 }

 return 段階一覧[現在位置 + 1];
}

console.log(次の段階を取得する("定義"));
// 出力：展開
 

この例では、現在の段階を入力すると次に進む段階を取得できます。実際の業務では、担当者、開始日、終了条件、成果物、承認者などの情報を加えることで、進行管理の仕組みに発展させられます。

ただし、コードによって段階を自動的に進めるだけでは不十分です。各段階の終了条件を満たしているかを人が確認し、必要な情報が不足している場合は、次へ進まず調査や検証を追加する必要があります。

4. ダブルダイヤモンドとデザイン思考の違い

ダブルダイヤモンドとデザイン思考は、利用者を理解し、試作と検証を繰り返す点で共通しています。一方、両者は完全に同じものではなく、主に枠組みの見せ方、段階の区切り方、活用目的に違いがあります。

4.1 両者に共通する利用者中心の姿勢

ダブルダイヤモンドもデザイン思考も、企業側の都合だけで答えを決めず、利用者の行動や感情を起点に考えます。本人の発言だけでなく、実際の行動を観察し、言葉と行動の違いから潜在的な課題を探ります。

また、最初から完成品を作るのではなく、簡単な試作品で仮説を確かめる点も共通しています。計画の正しさを会議だけで判断せず、現実の反応から学習する姿勢が中心にあります。

4.2 段階の表現方法に見られる違い

ダブルダイヤモンドは、探索、定義、展開、提供の4段階と、二回の発散・収束によって全体を示します。課題を定める活動と解決策を作る活動が、二つのひし形として明確に区別されています。

デザイン思考は、共感、問題定義、発想、試作、検証などの段階で説明されることが一般的です。人の理解から試作品の評価までを、より細かな行動単位で説明しやすい特徴があります。

4.3 比較表で分かる主な違い

両者は競合する手法ではなく、目的に応じて組み合わせられます。ダブルダイヤモンドを全体の進行図として使い、各段階の具体的な行動にデザイン思考の技法を取り入れる方法も効果的です。

表から分かるように、ダブルダイヤモンドは活動全体を整理する地図として利用しやすく、デザイン思考は利用者理解や試作を実行する方法として利用しやすい傾向があります。組織の状況に応じて、どちらか一方に限定する必要はありません。

4.4 どちらを選ぶべきか判断する基準

複数の部署が関わり、企画全体の段階や判断時点を共有したい場合は、ダブルダイヤモンドが適しています。発散しているのか収束しているのかを示せるため、会議の目的や成果物を整理しやすくなります。

利用者への共感、発想会議、試作品の作成方法など、具体的な実践技法を深く学びたい場合は、デザイン思考の考え方が役立ちます。実務では、全体をダブルダイヤモンドで管理し、必要な場面でデザイン思考の技法を使う方法が現実的です。

4.5 他の改善手法と組み合わせる方法

ダブルダイヤモンドは、継続的改善、仮説検証、業務分析などの手法とも組み合わせられます。たとえば、探索と定義で利用者の課題を明確にし、提供後は数値を測定しながら継続的に改善する流れを作れます。

重要なのは、複数の手法を名前だけ導入し、作業を増やしすぎないことです。各手法が何を解決するためのものかを整理し、自社の不足部分を補う形で使い分ける必要があります。

5. 探索段階の進め方

探索段階の目的は、最初に与えられた問題を確認することではなく、利用者や現場の実態から本当に検討すべき問題領域を見つけることです。調査対象や方法を限定しすぎず、異なる立場から情報を集めます。

5.1 調査目的と仮説を事前に整理する

調査を始める前に、何を明らかにしたいのか、現在どのような仮説を持っているのかを文章で整理します。目的が曖昧なまま聞き取りを行うと、大量の情報を集めても判断に使えない可能性があります。

ただし、仮説は答えとして扱うのではなく、確認すべき仮の見方として扱います。仮説に一致する発言だけを探さず、反対の事実や想定外の行動も積極的に記録することが重要です。

5.2 利用者への聞き取りを行う

聞き取りでは、理想や一般論よりも、最近実際に経験した出来事を質問します。「普段どうしていますか」だけでなく、「最後に利用したとき、最初に何をしましたか」と聞くことで、具体的な行動を確認できます。

また、回答を誘導する質問は避ける必要があります。「この機能があれば便利ですか」では肯定的な回答が増えやすいため、「その場面では何に困りましたか」「どのように対処しましたか」と尋ねます。

5.3 実際の行動を観察する

利用者は、自分の行動をすべて正確に説明できるとは限りません。習慣として無意識に行っている操作や、本人が問題だと認識していない不便は、聞き取りだけでは見つけにくいものです。

実際の利用場面を観察すると、説明と行動の違い、迷い、やり直し、周囲の人への質問などを確認できます。観察者の解釈だけを記録せず、何が起きたかという事実と、その理由に関する仮説を分けて残します。

5.4 問い合わせや行動記録を分析する

顧客対応の履歴、検索語、離脱場所、返品理由、作業時間など、既に組織内にある情報も探索に活用できます。個別の意見だけでなく、繰り返し発生している問題の規模や傾向を確認できるからです。

数値だけでは理由が分からないため、定量的な記録と聞き取りを組み合わせます。たとえば、特定画面で離脱が多い事実を確認した後、その場面を利用者に操作してもらい、迷った理由を調べます。

5.5 利害関係者の視点を集める

利用者だけでなく、販売担当者、顧客対応担当者、運用担当者、管理者などからも情報を集めます。同じ問題でも、立場によって原因や影響の見え方が異なるためです。

ただし、社内関係者の意見を利用者の事実と同じものとして扱わないよう注意します。「利用者はこう考えているはず」という推測と、実際の調査で確認された行動を分けることで、判断の偏りを防げます。

6. 定義段階の進め方

定義段階では、探索で得た大量の情報を整理し、取り組む価値のある課題を明確にします。情報を減らす作業ではありますが、都合のよい意見だけを残すのではなく、一貫した判断基準で重要度を評価する必要があります。

6.1 調査結果を事実と解釈に分ける

調査結果を整理するときは、実際に確認できた事実と、調査者が考えた理由を分けて記録します。「利用者が三回戻る操作をした」は事実ですが、「画面が分かりにくいから戻った」は解釈です。

事実と解釈を混ぜると、仮説が確定情報として扱われる危険があります。複数の事実から同じ解釈が導けるかを確認し、必要であれば追加の聞き取りや観察を行います。

6.2 情報を類似性によって分類する

聞き取りの発言、観察結果、問い合わせ内容などを小さな単位に分け、意味が近いものをまとめます。最初から既存部署や商品機能の分類に当てはめず、情報そのものの共通点から整理することが大切です。

分類を進めると、「登録方法」ではなく「失敗への不安」、「操作時間」ではなく「中断される環境」など、表面とは異なる共通要因が見つかる場合があります。この共通要因が、本質的な課題を考える手がかりになります。

6.3 利用者像を具体的にする

すべての利用者を一つの平均的な人物として扱うと、特徴のない解決策になりやすくなります。行動、目的、利用頻度、知識、置かれている環境などから、重要な利用者群を分けて考えます。

利用者像を作る目的は、架空の人物設定を増やすことではありません。誰のどの課題を優先するかをチームで共有し、判断が抽象的にならないようにすることです。

6.4 課題文を明確に作成する

課題文には、対象となる人、状況、達成したい目的、妨げになっている障害を含めます。たとえば、「初めて利用する人が、失敗への不安によって申し込みを完了できない」と表現すると、検討対象が具体的になります。

一方、「申し込み画面を改善する」という書き方は、既に解決方法を決めてしまっています。定義段階では、特定の画面や機能に限定せず、複数の解決方法を考えられる課題文にする必要があります。

6.5 優先する課題を選定する

複数の課題候補が見つかった場合は、利用者への影響、発生頻度、事業への影響、緊急性、解決可能性などを基準に比較します。発言の強さや会議参加者の役職だけで優先順位を決めないことが重要です。

判断基準を事前に合意しておくと、なぜその課題を選んだのか説明しやすくなります。また、今回選ばなかった課題も記録しておけば、将来の企画や改善活動で再利用できます。

7. 展開段階の進め方

展開段階では、定義した課題に対する解決策を幅広く考えます。この段階で重要なのは、最初に出た現実的な案をすぐ採用するのではなく、異なる方向性の案を十分に生み出して比較することです。

7.1 発想前に課題と条件を共有する

発想会議を始める前に、対象となる利用者、課題文、調査で確認された事実、避けるべき条件を参加者全員で確認します。前提が共有されていないと、それぞれが異なる問題を解決する案を出してしまいます。

条件を共有することは必要ですが、実現方法を細かく限定しすぎてはいけません。法令、予算、期限などの重要条件と、単なる社内慣習を区別することで、発想の余地を残せます。

7.2 個人で考えてから全員で共有する

最初から全員で話し始めると、発言力の強い人の案に議論が引っ張られることがあります。最初に各自が短時間で案を書き出し、その後に全員で共有すると、多様な視点を確保しやすくなります。

共有時には、案をすぐ評価せず、似た考えを組み合わせたり、異なる案から新しい方向を作ったりします。案を出した人ではなく、案の内容に注目する進行が必要です。

7.3 制約を変えて案を広げる

通常の条件だけで考えると、既存サービスの小さな改善案に偏りやすくなります。「予算が十分にある場合」「人の作業を増やせない場合」「説明を一切読まない場合」など、異なる制約を設定すると発想を広げられます。

極端な条件から生まれた案を、そのまま実施する必要はありません。現実離れした案の一部を取り出し、現在の条件でも実行できる形へ変換することで、新しい解決策につながります。

7.4 解決策を組み合わせる

一つの課題に対して、一つの機能だけで完全に解決できるとは限りません。案を分類し、利用前、利用中、利用後などの時間軸に沿って組み合わせると、体験全体を改善する案を作れます。

ただし、案を増やしすぎると複雑になり、検証が難しくなります。最初の試作では、課題解決に最も影響する要素を中心にし、追加要素は後の検証結果を見ながら判断します。

7.5 判断基準を使って案を絞る

発想後は、利用者への効果、実現可能性、費用、期間、危険性、事業との整合性などを使って案を比較します。単純な多数決だけで決めると、分かりやすく無難な案が選ばれやすくなります。

評価基準ごとに点数を付ける場合も、数字を絶対的な結果として扱ってはいけません。点数の違いが生まれた理由を話し合い、前提や情報不足を明らかにするための材料として使います。

Pythonによる解決案の簡易評価例

解決案一覧 = [
   {"名称": "案A", "効果": 5, "実現性": 3, "費用適合": 4},
   {"名称": "案B", "効果": 4, "実現性": 5, "費用適合": 5},
   {"名称": "案C", "効果": 5, "実現性": 2, "費用適合": 2},
]

重み = {
   "効果": 0.5,
   "実現性": 0.3,
   "費用適合": 0.2
}

for 解決案 in 解決案一覧:
   解決案["総合点"] = sum(
       解決案[評価項目] * 割合
       for 評価項目, 割合 in 重み.items()
   )

評価結果 = sorted(
   解決案一覧,
   key=lambda 項目: 項目["総合点"],
   reverse=True
)

for 順位, 解決案 in enumerate(評価結果, start=1):
   print(f"{順位}位：{解決案['名称']}、総合点：{解決案['総合点']:.1f}")
 

このコードでは、効果、実現性、費用との適合度に異なる重みを設定し、解決案の総合点を計算しています。重みは事業の目的や企画の段階によって変える必要があります。

数値評価は議論を補助する道具であり、最終判断を自動化するものではありません。法的な危険性、利用者への不利益、組織の方針など、単純な点数にしにくい条件も別途確認します。

8. 提供段階の進め方

提供段階では、選んだ案を試作品に変え、実際の利用状況に近い環境で検証します。完成度を高めてから見せるのではなく、重要な仮説を確かめられる最小限の形を早く作ることが大切です。

8.1 検証したい仮説を一つずつ明確にする

試作品を作る前に、何を確かめたいのかを具体的に書きます。「使いやすいか」では曖昧すぎるため、「初めての利用者が説明を受けずに申し込みを完了できるか」のように表現します。

一つの試作品で多くの仮説を同時に検証すると、失敗の原因が分からなくなります。優先度の高い仮説から順番に確かめ、結果を反映しながら試作品を更新します。

8.2 目的に合わせて試作品の精度を決める

初期段階では、紙に描いた画面、文章だけの説明、手作業による模擬サービスでも検証できます。見た目を作り込むより、利用者が内容を理解できるか、目的を達成できるかを確認することが優先されます。

一方、操作速度や細かな視認性を検証する場合は、実際に近い動作を持つ試作品が必要です。検証目的に対して必要以上の精度で作ると、時間と費用が増えるだけでなく、作った案を捨てにくくなります。

8.3 利用者に課題を実行してもらう

検証では、機能を説明して感想を聞くだけでなく、具体的な目的を伝えて操作してもらいます。たとえば、「この商品を来週受け取れるように申し込んでください」と依頼し、行動を観察します。

進行役は、利用者が迷ったときにすぐ答えを教えないよう注意します。どこで迷い、何を探し、どの言葉を誤解したかが、改善に必要な重要情報になるからです。

8.4 行動と発言を記録する

検証中は、完了できたかどうかだけでなく、所要時間、間違い、戻る操作、視線、質問、表情などを記録します。利用者が「簡単だった」と答えても、実際には何度も迷っている場合があります。

観察結果は、評価者の印象だけでまとめず、可能な限り具体的な行動として残します。複数人で観察する場合は、記録形式をそろえることで結果を比較しやすくなります。

8.5 結果に基づいて次の行動を決める

検証後は、成功、修正、再検討、中止などの判断を行います。好意的な意見があったという理由だけで進めず、事前に設定した仮説と成功条件に照らして評価します。

課題定義自体が誤っている可能性が見つかった場合は、展開段階で案を増やすだけでは解決しません。探索や定義へ戻り、利用者の状況や課題文を見直す必要があります。

9. 課題設定の精度を高める方法

ダブルダイヤモンドの成果は、定義段階でどのような課題を設定するかによって大きく変わります。優れた解決策を考えても、対象となる課題がずれていれば、利用者や事業に十分な価値を生み出せません。

9.1 症状と原因を区別する

売上の低下、途中離脱、問い合わせの増加は、問題の結果として現れている症状です。これらをそのまま課題として設定すると、割引、画面変更、人員増加など、短期的な対応だけに議論が偏ることがあります。

症状が発生する前に、利用者がどのような状況に置かれ、何を判断し、どこで行動を止めたのかを調べます。原因を一つに決めつけず、複数の可能性を比較することが重要です。

9.2 なぜを繰り返して背景を掘り下げる

表面的な問題に対して「なぜ起きたのか」を繰り返し考えると、背景にある仕組みや条件を見つけやすくなります。ただし、会議室の推測だけで回答を作ると、都合のよい物語になる危険があります。

それぞれの「なぜ」に対して、調査で確認された事実があるかを確認します。根拠がない部分は仮説として記録し、追加調査で検証することで、課題設定の信頼性を高められます。

9.3 対象者と利用場面を限定する

「すべての利用者が使いやすいサービスを作る」という課題は、対象が広すぎて具体的な判断ができません。初心者、頻繁に利用する人、管理者など、行動や目的が異なる集団を分けて考えます。

対象を限定することは、他の利用者を無視することではありません。最初に最も重要な集団の課題を解決し、その後に対象を広げることで、焦点のある改善を進められます。

9.4 解決策を含まない課題文にする

「新しい案内画面が必要だ」という表現には、既に画面を作るという解決策が含まれています。この状態では、案内方法を変える、手順そのものを減らす、人による支援を追加するといった別の可能性が検討されません。

課題文は、「利用者が必要な条件を理解できず、安心して選択できない」のように、利用者の目的と障害を中心に書きます。複数の解決方向を考えられる余地を残すことが重要です。

9.5 成功した状態を具体的に示す

課題を設定するときは、解決後にどのような状態を目指すのかも定めます。「満足度を高める」だけでは測定が難しいため、完了率、所要時間、問い合わせ件数、再利用率などの指標に変換します。

ただし、数値目標だけに集中すると、利用者の不安や理解度などが見落とされる場合があります。行動指標と感情・認識に関する指標を組み合わせ、複数の視点から成功を確認します。

10. 利用者調査と情報整理の実践方法

ダブルダイヤモンドでは、利用者の発言を集めるだけでなく、行動や状況を含めて理解することが重要です。調査手法は目的に応じて選び、得られた情報をチームが扱える形へ整理します。

10.1 聞き取り対象者を適切に選ぶ

調査対象者は、年齢や性別だけでなく、利用経験、利用頻度、目的、失敗経験などを基準に選びます。平均的な利用者だけを集めると、重要な問題が見えにくくなる場合があります。

利用をやめた人、競合商品を選んだ人、途中で申し込みを中断した人も重要な対象です。現在の利用者だけでは、選ばれなかった理由や離脱の原因を十分に理解できません。

10.2 質問項目を作成する

質問項目は、導入、具体的な経験、困難、代替行動、判断理由、理想状態などの順番で構成します。最初から核心的な質問をすると緊張しやすいため、答えやすい事実確認から始めます。

質問表を読み上げるだけではなく、回答に応じて追加質問を行います。「大変だった」という発言があれば、何が、いつ、どの程度大変だったのかを具体化します。

10.3 行動の流れを可視化する

利用者が目的を達成するまでの行動を、時間の順番に並べて整理します。各場面での行動、接点、感情、疑問、障害を書き出すと、個別機能だけでは見えない体験全体の問題を発見できます。

たとえば、購入画面に問題がなくても、購入前の情報収集で不安が解消されていなければ離脱が発生します。前後の行動まで含めて確認することで、改善すべき位置を正しく判断できます。

10.4 発言を意味のまとまりに分ける

長い聞き取り記録は、そのままでは比較が難しいため、一つの意味ごとに短く分けます。「時間がない」「失敗したくない」「家族に確認したい」など、判断や行動に影響する内容を抽出します。

抽出した情報には、対象者、利用場面、元の発言、観察事実などを付けます。文脈を失った短い言葉だけが独立すると、調査者の都合に合わせて解釈される危険があるためです。

10.5 情報管理と個人情報に配慮する

聞き取りや行動観察では、氏名、連絡先、利用履歴、健康状態など、個人を特定できる情報を扱う場合があります。調査目的、利用範囲、保管方法、削除時期を事前に明確にし、必要な同意を得ます。

共有資料には、分析に不要な個人情報を載せないことが原則です。録音や映像を利用する場合も、閲覧権限を限定し、目的が終了した後の削除方法を決めておきます。

HTMLによる調査記録形式の例

<section class="調査記録">
 <h4>利用者調査記録</h4>

 <dl>
   <dt>対象者の特徴</dt>
   <dd>初回利用者、事前知識が少ない</dd>

   <dt>利用場面</dt>
   <dd>移動中にスマートフォンから申し込み</dd>

   <dt>確認された行動</dt>
   <dd>料金条件を探すため、同じ画面を三回移動した</dd>

   <dt>本人の発言</dt>
   <dd>追加料金が発生しないか不安だった</dd>

   <dt>考えられる課題</dt>
   <dd>申し込み前に総額と条件を理解できない</dd>
 </dl>
</section>
 

この形式では、対象者、状況、行動、発言、解釈を分けて保存できます。特に「確認された行動」と「考えられる課題」を別項目にすることで、事実と分析結果の混同を防げます。

複数の調査記録を同じ形式で保存すれば、後から共通点を検索しやすくなります。実務では、調査日、担当者、同意状況、関連資料への参照情報なども追加すると管理しやすくなります。

11. 発散と収束を効果的に行う技法

ダブルダイヤモンドを形だけ導入しても、発散段階で案が広がらず、収束段階で根拠のない多数決を行えば十分な成果は得られません。発散と収束では考え方を切り替え、それぞれに適した進行方法を使う必要があります。

11.1 発散中は評価を遅らせる

発散中に「費用が高い」「以前失敗した」と評価を始めると、参加者は安全な案しか出さなくなります。最初は案の数と方向性を増やすことに集中し、評価は後の時間に分けます。

ただし、違法な案や利用者に重大な不利益を与える案まで無条件に推奨するわけではありません。発想を広げる時間と、倫理・安全・実現性を確認する時間を明確に分けることが重要です。

11.2 異なる視点から問いを作る

同じ課題でも、利用者、運用担当者、管理者、初心者、専門家などの立場から見ると、異なる解決案が生まれます。立場を変えて問いを作ることで、特定部署の視点だけに偏ることを防げます。

また、「追加するには」だけでなく、「なくすには」「自動化せずに解決するには」「利用前に防ぐには」など、動詞を変える方法も有効です。問いの形を変えると、発想の方向も変わります。

11.3 案を可視化して共有する

口頭だけで案を共有すると、説明が長い人の案が目立ち、短く説明された案が見落とされることがあります。すべての案を同じ大きさの紙や画面上に書き出し、一覧で見られる状態にします。

可視化すると、似た案の統合、重複、空白領域を確認しやすくなります。案を出した人の名前より、解決する課題や仕組みに注目して分類することが大切です。

11.4 収束の判断基準を先に決める

案を見た後で評価基準を決めると、気に入った案を選ぶために基準を変更する危険があります。利用者への効果、事業との整合性、実現可能性などを、評価前に合意しておきます。

基準には優先順位を付けます。すべての項目を同じ重さで評価すると、平均的で特徴の弱い案が選ばれる場合があるため、今回の目的で最も重要な条件を明確にします。

11.5 少数意見を記録する

収束によって一つの方向を選ぶ場合でも、反対意見や少数意見を消してはいけません。後の検証で問題が起きたとき、どのような危険が事前に指摘されていたかを確認できるからです。

採用しなかった案や懸念点を記録しておくと、判断の透明性が高まります。また、条件が変わった場合に、過去の案を再評価して利用できます。

12. チームでダブルダイヤモンドを運用する方法

ダブルダイヤモンドは、一人でも思考整理に使えますが、複数の専門性を持つ人が協力すると効果を発揮しやすくなります。その一方で、役割や判断方法が曖昧だと、会議が増えるだけで進まない状態になる可能性があります。

12.1 責任者と進行役を分ける

責任者は、最終的な目的、予算、優先順位、実行判断に責任を持ちます。進行役は、発言機会の偏りを防ぎ、現在の段階と会議目的を守りながら議論を進めます。

両方の役割を一人が担当することもできますが、責任者の意見に参加者が合わせすぎる危険があります。重要な企画では、議論を中立的に支援する進行役を置くと効果的です。

12.2 各段階の成果物を決める

探索では調査記録、定義では課題文、展開では解決案一覧、提供では検証結果など、各段階で何を残すかを決めます。成果物が曖昧だと、議論しただけで次へ進み、判断根拠が残りません。

成果物は、美しい資料を作ること自体が目的ではありません。次の段階で判断するために必要な情報が含まれているかを確認し、不要な装飾や重複作業を減らします。

12.3 会議ごとの目的を一つに絞る

調査結果の共有、課題の選定、発想、実現性評価を一つの会議で行うと、参加者が思考を切り替えにくくなります。会議ごとに発散か収束かを明確にし、終了時の状態を決めます。

招待文や会議資料にも、「今日は案を決めない」「今日は三つの課題候補に絞る」などと記載します。目的が明確であれば、必要な参加者や準備物も判断しやすくなります。

12.4 意思決定者を明確にする

全員の完全な同意を待つと、期限内に判断できないことがあります。意見を広く集める段階と、最終的に決定する人を分け、誰がどの基準で判断するかを事前に共有します。

意思決定者は、個人的な好みだけで決めるのではなく、調査結果と合意済みの基準を使う必要があります。判断理由を記録し、後から検証できる状態にします。

12.5 部門間の言葉の違いを調整する

同じ言葉でも、営業、開発、経営、顧客対応で意味が異なる場合があります。「利用者」「顧客」「完了」「品質」など、重要語の定義がずれていると議論がかみ合いません。

企画の初期に用語と対象範囲を確認し、共通の言葉を作ります。専門用語を完全に禁止するのではなく、他部門にも理解できる説明を添えることが重要です。

13. ダブルダイヤモンドで起こりやすい失敗と改善策

ダブルダイヤモンドは分かりやすい図ですが、図に沿って作業名を並べるだけでは成果につながりません。各段階の目的を理解しないまま導入すると、形式的な会議や資料作成が増える可能性があります。

13.1 最初から答えを決めて調査する

経営層や企画担当者が採用したい案を既に決めており、その案を正当化するためだけに調査を行うケースがあります。この状態では、反対の事実が無視され、探索が確認作業になってしまいます。

改善するには、調査前に仮説だけでなく「どの結果が出たら案を見直すか」を決めます。判断を変える条件を明確にすることで、調査を形式的な承認作業にしにくくなります。

13.2 調査対象が身近な人に偏る

社内の人や既存の熱心な利用者だけに聞くと、商品知識が高く、組織に好意的な回答に偏る場合があります。その結果、初心者や離脱した人が抱える問題を見落とします。

対象条件を事前に定め、利用経験や行動の異なる人を含めます。採用が難しい場合は、顧客対応履歴や離脱データなど、別の情報源も組み合わせます。

13.3 発散段階で実現性を気にしすぎる

案を出すたびに費用や技術的な難しさを指摘すると、参加者は既存の仕組みを少し変更する案しか出さなくなります。発散と評価を同時に行うことが原因です。

時間を分け、発散中は案の方向を広げ、収束時に実現性を評価します。技術担当者も、否定するだけでなく「どの条件なら実現できるか」を示す役割を持つと建設的です。

13.4 試作品を完成品のように作り込む

検証前から見た目や内部処理を作り込むと、変更費用が高くなり、問題が見つかっても案を捨てにくくなります。また、細部への感想が増え、重要な仮説の検証がぼやけます。

試作品は、確認したい仮説を検証できる最低限の形にします。初期は紙や静止画を使い、方向性が確認された後で動作や見た目の精度を高めます。

13.5 検証結果を成功か失敗だけで判断する

検証で目標を達成できなかった場合、案全体を失敗として捨てることがあります。しかし、どの部分が機能し、どの仮説が誤っていたかを分析しなければ、次の案に学びを生かせません。

検証結果を、支持された仮説、否定された仮説、判断できなかった仮説、新しく見つかった課題に分けて整理します。失敗を結論ではなく、次の判断に使える情報へ変換することが重要です。

14. 業界別のダブルダイヤモンド活用例

ダブルダイヤモンドは、利用者の課題を理解して解決策を検証する構造を持つため、さまざまな業界で利用できます。分野によって調査対象や成果物は変わりますが、発散と収束の原則は共通しています。

14.1 電子商取引サイトでの活用例

電子商取引サイトでは、購入率が低いという数値だけを見て、割引や画面変更を行いがちです。探索段階で検索、比較、配送確認、支払い、購入後までの行動を調べると、価格以外の障害が見つかる場合があります。

定義した課題に応じて、情報の表示順、比較方法、配送条件の説明、購入手続きなど複数の案を考えます。試作品を使って利用者に購入課題を実行してもらい、完了率や迷いを測定します。

14.2 医療・介護サービスでの活用例

医療や介護では、利用者本人だけでなく、家族、医療従事者、介護職員、管理者など多くの関係者が存在します。それぞれの負担や目的が異なるため、一つの立場だけで課題を定義すると、別の場所に負担が移る可能性があります。

探索では、予約、受診、説明、服薬、継続支援などの流れを確認します。安全性と個人情報を重視しながら小規模な検証を行い、利用者の理解度と現場の運用可能性を同時に評価します。

14.3 教育分野での活用例

教育では、学習者が理解できない原因を、努力不足や教材の難しさだけで説明してしまうことがあります。探索によって、学習環境、利用時間、前提知識、質問への心理的抵抗などを調べると、異なる課題が見つかります。

解決策として、教材変更だけでなく、学習順序、振り返り方法、支援のタイミング、仲間との協力などを検討できます。小規模な授業や教材試験で、理解度と継続行動の変化を確認します。

14.4 社内業務改善での活用例

社内業務では、作業時間を減らすために新しい仕組みを導入しても、入力項目や確認作業が増え、現場の負担が高まることがあります。現在の手順だけでなく、なぜその確認が必要なのかまで探索することが重要です。

定義段階では、不要な作業、重複入力、承認待ち、情報不足などを区別します。解決策も、仕組みの導入だけに限定せず、規則の変更、役割の整理、作業自体の廃止を含めて検討します。

14.5 公共サービスでの活用例

公共サービスは、年齢、言語、身体状況、情報環境が異なる多様な人に利用されます。平均的な利用者だけを想定すると、必要な人ほど手続きを完了できない問題が起きる可能性があります。

探索では、窓口、紙、電話、ウェブサイトなど複数の利用経路を調べます。公平性、利用しやすさ、運用費用、法的条件を確認しながら、異なる利用者群に対して検証を行います。

15. ダブルダイヤモンドの導入手順と成果測定

ダブルダイヤモンドを組織へ導入するときは、最初から大規模な制度を作るより、小さな課題で試しながら調整する方法が適しています。目的、期間、役割、成果物、判断基準を明確にし、学びを次の企画へ残します。

15.1 小規模な課題から試す

最初の導入では、期間が短く、対象者へ接触しやすく、検証結果を確認できる課題を選びます。経営全体の変革のような大きすぎるテーマでは、範囲が広がり、方法自体の効果を評価しにくくなります。

小規模な課題で進め方を経験すると、自社に必要な会議時間、調査人数、成果物の量が分かります。その結果を使って、より大きな企画に適した運用方法を作れます。

15.2 期間と区切りを設定する

探索を続ければ情報は増えますが、期限がなければいつまでも定義へ進めません。各段階に期間を設定し、期限時点で得られた情報から次の判断を行います。

ただし、予定どおり進むこと自体を最優先にしてはいけません。重大な情報不足や危険性が見つかった場合は、理由を記録したうえで期間や範囲を見直します。

15.3 段階ごとの終了条件を決める

探索は「十分に調査したと感じたら終了」ではなく、主要な利用者群への調査が完了し、繰り返し現れる課題が確認できた状態など、具体的な終了条件を設定します。

定義、展開、提供にも同様の条件を設けます。条件が明確であれば、責任者の感覚だけで進行が変わることを防ぎ、チームが次に必要な作業を判断できます。

15.4 成果を複数の指標で測定する

導入成果は、売上や費用だけでなく、課題発見までの時間、手戻りの減少、試作回数、利用者の完了率、関係部署の合意形成などから測定できます。短期的な結果と長期的な結果を分けることも必要です。

たとえば、初期の調査費用が増えても、開発後の大規模な修正が減れば、全体として効率が高まっている可能性があります。部分的な費用だけでなく、企画から提供後までの総負担を確認します。

15.5 学びを組織に蓄積する

企画が終了したら、採用した案だけでなく、調査結果、採用しなかった課題、否定された仮説、検証で得た知見も保存します。結果だけを残すと、別のチームが同じ調査や失敗を繰り返す可能性があります。

記録は検索可能な形にし、対象者、課題領域、調査時期、判断理由などを付けます。ただし、古い調査結果が現在も有効とは限らないため、取得時期と利用条件も明記します。

導入状況を管理するデータ例

const 企画情報 = {
 企画名: "申し込み体験の改善",
 現在段階: "提供",
 課題文: "初回利用者が料金条件を理解できず、申し込みを中断する",
 成功条件: {
   完了率: 0.85,
   平均所要時間_秒: 180,
   問い合わせ削減率: 0.2
 },
 検証結果: {
   完了率: 0.82,
   平均所要時間_秒: 165,
   問い合わせ削減率: 0.24
 }
};

function 条件を評価する(成功条件, 検証結果) {
 return {
   完了率達成: 検証結果.完了率 >= 成功条件.完了率,
   時間達成:
     検証結果.平均所要時間_秒 <= 成功条件.平均所要時間_秒,
   問い合わせ削減達成:
     検証結果.問い合わせ削減率 >= 成功条件.問い合わせ削減率
 };
}

console.log(
 条件を評価する(
   企画情報.成功条件,
   企画情報.検証結果
 )
);
 

このコードでは、事前に設定した成功条件と実際の検証結果を比較しています。例では所要時間と問い合わせ削減率は条件を満たしていますが、完了率は目標に届いていないことが分かります。

一つの指標が未達だからといって、企画全体を即座に中止する必要はありません。どの利用者群が完了できなかったのか、どの場面で離脱したのかを確認し、修正後に再検証します。

おわりに

ダブルダイヤモンドとは、課題の探索と定義、解決策の展開と提供を通じて、発散と収束を二回繰り返す問題解決の枠組みです。単に二つのひし形を描く手法ではなく、解決策を考える前に正しい課題を見つけ、実行前に複数の可能性を検証する考え方に価値があります。

実践では、探索中に結論を急がないこと、事実と解釈を分けること、解決策を含まない課題文を作ること、完成前に試作品で検証することが重要です。また、発散と収束を同じ時間に行わず、各段階の目的、成果物、終了条件をチームで共有する必要があります。

最初から大規模な導入を目指すのではなく、範囲の小さい改善課題で一連の流れを試すと、組織に合った運用方法を見つけやすくなります。調査や検証で得られた学びを蓄積し、次の企画へ反映することで、利用者にとって価値があり、事業としても持続可能な解決策を生み出せるようになります。