Home / デザイン思考とは ― 人間中心の問題発見から発想・試作・検証へ

デザイン思考とは ― 人間中心の問題発見から発想・試作・検証へ

デザイン思考（Design Thinking）とは、人々の行動や経験を理解することから問題や機会を発見し、解決策のアイデアを考え、試作と検証を繰り返しながら製品、サービス、業務などを改善・創造するための考え方と方法群です。

デザインという言葉から、製品の外観や美しさを設計する活動を思い浮かべるかもしれません。しかし、デザイン思考の対象は外観に限りません。使いやすい製品の開発、サービスの改善、業務プロセスの見直し、組織や事業の新しい仕組みの構想などにも利用されます。

例えば、ある企業が新しい業務システムを開発するとします。従来の開発では、管理者が必要な機能を定義し、それに沿ってシステムを設計するかもしれません。しかし、実際の利用者を観察すると、管理者が想定していなかった作業や、公式の業務手順には記載されていない例外的な処理が存在する場合があります。

利用者の行動や経験を調べることで、最初に定義された要求とは異なる問題が見つかる可能性があります。

デザイン思考の特徴は、単に利用者の要望を聞いて製品を作ることではありません。利用者自身も明確に意識していない問題や、従来の問題設定では見落とされていた機会を発見し、具体的な解決案を試しながら理解を深めることにあります。

ただし、デザイン思考を実践すれば、必ず独創的な製品や優れた解決策が生まれるわけではありません。観察、解釈、発想、試作、検証にはそれぞれ限界があり、適切な専門知識や技術的な検討も必要です。

デザイン思考は一つの技法なのか

デザイン思考は、ブレインストーミングや特性要因図のような一つの個別技法ではありません。人間中心設計、観察調査、問題構造化、アイデア生成、プロトタイピング、評価などを組み合わせるアプローチです。

デザイナーの問題解決や設計活動についての研究には長い歴史があります。

ハーバート・サイモン（Herbert A. Simon）は『The Sciences of the Artificial』（1969年）で、現在の状態から望ましい状態へ変えるための設計活動を、科学的な研究対象として論じました。

また、リチャード・ブキャナン（Richard Buchanan）は1992年の論文「Wicked Problems in Design Thinking」で、デザインが、問題の定義自体が明確でない複雑な課題に関わることを論じています。

こうした設計研究の流れとは別に、デザインの実務で発展した方法を企業の製品開発やイノベーションに応用する取り組みも広がりました。

IDEOのデイヴィッド・ケリー（David Kelley）やティム・ブラウン（Tim Brown）らは、この考え方を普及させるうえで重要な役割を果たしました。スタンフォード大学のd.school（Hasso Plattner Institute of Design）も、デザイン思考の教育と普及に大きく貢献しています。

ただし、デザイン思考を一人の人物が発明した方法として理解するのは適切ではありません。デザインの実務、設計研究、認知科学、社会調査、経営学など、さまざまな活動や知識が関係しています。

また、デザイン思考には唯一の標準的な手順が存在するわけではありません。代表的なモデルには共通点がありますが、使用する活動の区分や進め方には違いがあります。

デザイン思考の5つの活動

デザイン思考の代表的な説明として、スタンフォード大学d.schoolの5つの活動が知られています。

活動主な目的代表的な作業
Empathize（共感・理解）利用者の経験や状況を理解する観察、インタビュー、利用状況の調査
Define（問題定義）解くべき問題を明確にする調査結果の整理、問題の再定義
Ideate（発想）解決策の可能性を広げるブレインストーミング、類推、アイデアの組み合わせ
Prototype（試作）アイデアを具体的に表現する模型、画面案、業務シナリオ、簡易試作品
Test（検証）利用者の行動や反応から学ぶユーザビリティテスト、試用、観察、比較

これらは、デザイン思考の活動を理解するために便利な分類です。

しかし、実際の活動が必ずこの順序で進むわけではありません。試作品を見せた結果、最初の問題設定が間違っていたと気づくこともあります。新しいアイデアを考えている途中で、追加の利用者調査が必要になることもあります。

d.school自身も、この5段階を固定的な唯一のデザインプロセスとして扱うべきではないと説明しています。

重要なのは、定められた順番で作業を終えることではなく、各活動から得られる知識によって次の判断を改善することです。

1. Empathize ― 利用者の経験を理解する

デザイン思考では、利用者の視点から問題を理解することが重視されます。

例えば、製品の利用者に「どのような機能が必要ですか」と質問すると、既存の製品や経験に基づいた回答が得られるでしょう。

しかし、利用者自身が不便さに慣れてしまい、その問題を明確に認識していない場合があります。また、利用者が希望する機能が、実際の問題を解決する最善の方法とは限りません。

そこで、利用者が実際に何をしているのか、どのような状況で困っているのかを観察します。

例えば、業務システムの利用者が、画面に表示された情報を別の紙へ書き写しているとします。

本人はその作業を当然だと思っているかもしれません。しかし、観察者は、必要な情報を複数の画面で同時に確認できないことが、書き写しを必要としているのではないかと考えられます。

こうした発見は、利用者への質問だけでは得られない場合があります。

共感と観察を混同しない

デザイン思考で使われる「共感（Empathy）」は、利用者の立場や経験を理解しようとする姿勢を表します。

しかし、利用者に感情移入することと、利用者の状況を正確に理解することは同じではありません。

例えば、高齢の利用者が操作に戸惑っている様子を見て、「高齢者はデジタル機器が苦手だから」と判断するのは、観察ではなく解釈です。

実際には、画面の表示がわかりにくい、操作手順が複雑、必要な情報が見つからない、あるいは別の要因が関係している可能性があります。

観察された事実と、その事実を説明する仮説を区別することが重要です。

利用者の言葉をそのまま正解として扱うのではなく、行動、利用状況、関連する制約を調べながら解釈を検討します。

代表的な調査方法

利用者を理解するためには、インタビュー、現場観察、利用状況の記録、日記調査など、さまざまな方法があります。

インタビューでは利用者の考えや経験について詳しく聞くことができます。一方、現場観察では、本人が意識していない習慣や作業上の制約を発見できる可能性があります。

また、カスタマージャーニーマップ（Customer Journey Map）を利用し、利用者が製品やサービスと接する一連の場面を整理することもあります。

例えば、製品購入前の情報収集、問い合わせ、購入、導入、日常利用、トラブル発生時の対応などを時系列に整理し、それぞれの場面で生じる問題を考えます。

ただし、少人数のインタビューや観察で発見した特徴が、すべての利用者に共通するとは限りません。

調査対象者をどのように選んだか、観察されていない利用者層が存在しないか、といった点にも注意が必要です。

2. Define ― 問題を捉え直す

調査によって得られた情報を整理し、どのような問題を解決すべきかを明らかにします。

デザイン思考では、この問題定義の活動が重要です。

例えば、当初の課題が「製品の操作画面を使いやすくすること」だったとします。

しかし、利用者調査の結果、操作そのものよりも、トラブル発生時に必要な情報を見つけられないことが重要な問題だとわかったとします。

この場合、問題の定義を「操作画面を改善する」から、「異常時に必要な情報を迅速に見つけ、適切に判断できるようにする」へ変更することが考えられます。

問題の定義が変われば、検討する解決策も変わります。

操作ボタンを大きくすることだけでなく、必要な情報を状況に応じて提示する仕組みや、作業手順を案内する機能などが候補になります。

How Might Weという問い

デザイン思考では、解決すべき問題を「How Might We …?（どうすれば私たちは……できるだろうか）」という形で表現することがあります。

例えば、次のような問いです。

「どうすれば、設備異常の発生時に、保全担当者が必要な情報を迅速に確認できるようになるだろうか」

この問いは、特定の解決策をあらかじめ指定しないという特徴があります。

「保全担当者用のスマートフォンアプリを開発する」という課題にしてしまえば、アプリ以外の方法が検討対象から外れやすくなります。

一方、「必要な情報を迅速に確認できるようにする」という問いであれば、画面の変更、設備側の表示、作業手順の改善、情報管理の見直しなど、さまざまな可能性を考えられます。

ただし、問いを広く設定すればよいというわけでもありません。対象となる利用者、場面、目的が不明確であれば、具体的な検討が難しくなります。

問題の範囲を必要に応じて広げたり狭めたりしながら、何を解決したいのかを明確にします。

3. Ideate ― 解決策の可能性を広げる

問題が明確になったら、考えられる解決策を探索します。

この段階では、最初に思いついた方法だけに限定せず、異なる観点から複数のアイデアを考えることが重要です。

ブレインストーミング、SCAMPER、類推、モルフォロジカル分析などの発想技法を利用できます。

例えば、設備異常時の情報確認を改善する場合、次のような方向を検討できます。

  • 異常の種類に応じて必要な情報を自動表示する。
  • 操作画面から該当する保全手順へ直接移動できるようにする。
  • 設備の状態と過去の故障履歴を関連づける。
  • 音声によって作業手順を確認できるようにする。
  • 保全担当者が利用する情報の種類自体を見直す。

ただし、多くのアイデアを出せば、必ず優れた解決策が得られるわけではありません。

実現可能性、利用者への効果、費用、運用上の制約などを考慮しながら候補を選択します。

発散と収束

デザイン思考では、発散的思考（Divergent Thinking）と収束的思考（Convergent Thinking）の往復が重視されます。

発散では、問題の捉え方や解決策の可能性を広げます。

収束では、それらを比較・整理し、次に検討すべき候補を選びます。

ただし、候補を選ぶ際に、最も印象的なアイデアや多数決で支持されたアイデアを採用すればよいとは限りません。

例えば、技術的に魅力的な案であっても、現場の安全上の制約によって実用化できない場合があります。

反対に、地味な業務手順の変更が、大きな設備投資を伴う案よりも効果的なこともあります。

発想の段階で選択肢を十分に広げることと、選択の段階で適切な根拠を用いることを区別する必要があります。

4. Prototype ― アイデアを具体的にして学ぶ

プロトタイピング（Prototyping）は、アイデアを具体的な形にして、その意味や実現可能性を検討する活動です。

試作品というと、実際に動作する製品を思い浮かべるかもしれません。しかし、デザイン思考では、紙に描いた画面案、簡単な模型、サービス利用のシナリオ、業務の模擬実行などもプロトタイプとして利用できます。

例えば、新しい業務システムの画面を検討する場合、最初からソフトウェアを開発する必要はありません。

紙に画面を描き、利用者へ操作してもらうことで、必要な情報が見つけやすいか、操作の順番が理解できるかを調べられます。

プロトタイピングの価値は、完成品に近いものを早く作ることだけではありません。

実際に試すことで、それまで明確になっていなかった問題を発見できることが重要です。

プロトタイプは仮説を調べるための道具

例えば、「異常発生時に関連情報を一つの画面へ集約すれば、必要な情報を探す時間が短くなる」という仮説を考えたとします。

この場合、試作画面を使って、利用者が必要な情報を見つけるまでの時間や、誤った情報を選択する頻度を調べることができます。

その結果、情報を一つの画面へ集約したために、かえって必要な情報が見つけにくくなることもあるでしょう。

このような結果が得られたら、画面の構成や仮説そのものを見直します。

プロトタイプを作ることは、提案したアイデアが正しいと示すための活動ではありません。

プロトタイプは、利用者や現実の制約について新しい質問をするための道具と考える方が適切です。

5. Test ― 利用者の行動と結果から学ぶ

検証では、プロトタイプを利用者に試してもらい、観察された結果から改善点を考えます。

例えば、新しい操作画面を試してもらう場合、「この画面は使いやすいと思いますか」と尋ねるだけでは不十分かもしれません。

利用者に実際の作業を依頼し、目的を達成できるか、どこで迷うか、どのような誤操作をするかを観察することが重要です。

また、利用者が「使いやすい」と評価したとしても、実際には操作に時間がかかっている場合があります。

利用者の主観的な評価と、実際の行動や測定結果を区別する必要があります。

定性的な検証と定量的な検証

試作段階では、少人数の利用者を詳しく観察することで、問題の性質を理解できる場合があります。

一方、その問題がどの程度広く発生するか、変更によって性能がどれほど改善するかを調べるには、定量的な測定が必要になることがあります。

例えば、操作時間、作業完了率、エラー件数、問い合わせ件数などを比較できます。

ただし、少人数の利用者による試用結果から、すべての利用者について改善効果があると結論づけることはできません。

利用者の属性、使用環境、タスクの種類なども考慮する必要があります。

検証の結果によっては、アイデアを改善するだけでなく、問題の定義や利用者についての理解を修正することもあります。

ダブルダイヤモンド ― 問題と解決策の両方を探索する

デザイン思考に関連する代表的なモデルとして、英国Design Councilのダブルダイヤモンド（Double Diamond）があります。

これは、問題を理解するための探索と、解決策を考えるための探索を、それぞれ発散と収束の組み合わせとして表現したものです。

段階役割主な活動
Discover（発見）問題の可能性を広く探索する調査、観察、情報収集
Define（定義）取り組むべき問題を明確にする問題の整理、焦点化
Develop（開発）多様な解決策を探索する発想、試作、比較、改善
Deliver（実現）解決策を具体化し、実施する検証、選択、導入、評価

最初のダイヤモンドでは、当初の問題設定をいったん広げ、何を問題とするべきかを考えます。

次に、調査結果に基づいて取り組むべき問題を明確にします。

二つ目のダイヤモンドでは、その問題に対して多様な解決策を考え、試作や検証を通じて候補を絞り込みます。

このモデルは、問題と解決策の両方について、発散と収束の活動が必要であることをわかりやすく表現しています。

しかし、ダブルダイヤモンドも、すべてのプロジェクトが必ず通過する順序を規定するものではありません。

例えば、解決策の試作によって、それまでの問題定義が不適切だったことがわかれば、最初の探索へ戻る必要があります。

また、Design Councilのモデルでは、人間中心、協働、視覚的なコミュニケーション、反復などの原則も重視されています。

デザイン思考の三つの評価視点

IDEOは、デザイン思考において、人々にとっての望ましさ、技術的な実現可能性、事業としての成立可能性を組み合わせて考えることを重視しています。

視点英語検討する問い
人々にとっての望ましさDesirability利用者にとって重要な問題を解決しているか
技術的な実現可能性Feasibility必要な技術や能力によって実現できるか
事業・運用としての成立可能性Viability費用、収益、組織、制度などの条件の下で継続できるか

例えば、利用者が強く望んでいる機能であっても、現在の技術では実現できない可能性があります。

また、技術的に実現できても、運用費用が高すぎれば事業として成立しないかもしれません。

反対に、事業性が高いと見込まれる製品でも、利用者にとって重要な問題を解決できなければ、採用が進まない可能性があります。

デザイン思考は人間中心という特徴を持ちますが、人々の要望だけで製品や事業の成功を判断するものではありません。

また、これらの条件は完全に独立しているわけではありません。技術的な制約によって利用者の行動が変わる場合もあれば、利用方法の変更によって費用や運用条件が変化する場合もあります。

実践例 ― 製造設備の異常対応を改善する

デザイン思考を実務へ応用する例として、製造設備の異常対応を支援するシステムの改善を考えてみましょう。

次の内容は方法の理解を目的とする仮想事例です。

ある工場では、製造設備に異常が発生したとき、保全担当者が原因の調査と復旧作業に長い時間を要するという問題がありました。

当初、管理者は「保全システムの操作画面が使いにくい」と考えていました。

利用者の調査

保全担当者の作業を観察すると、設備の異常発生時には、操作画面だけでなく、紙のマニュアル、過去の故障記録、別の情報システムなどを参照していることがわかりました。

また、経験豊富な担当者は設備の状態をもとに必要な情報を判断できますが、経験の浅い担当者は、どの記録を参照するべきかを判断することが難しいという状況も見えてきました。

この段階では、単に画面が使いにくいという説明では不十分である可能性があります。

問題の再定義

調査結果から、問題を次のように捉え直したとします。

「設備異常時に、担当者が設備の状態と過去の対応履歴を対応づけ、必要な情報を迅速に確認できない」

この問題定義からは、画面の操作性改善だけでなく、異常の種類に応じた情報提示や、故障履歴の検索方法の改善などが候補になります。

解決策の発想

次に、複数の案を考えます。

例えば、アラーム番号から関連資料を表示する方法、設備の状態に応じて過去の故障事例を提示する方法、作業手順の確認を支援する方法などが考えられます。

ここでは、最初から一つの案へ絞り込まず、異なる仕組みを比較します。

プロトタイプによる検討

画面の簡単な試作品を作り、保全担当者に異常対応の模擬作業を行ってもらいます。

その結果、必要な情報が見つけやすくなったとしても、表示内容が多すぎると重要な警報を見落とす可能性があるとわかるかもしれません。

また、特定の情報を自動提示する機能が、経験豊富な担当者には不要で、経験の浅い担当者には有用な場合もあるでしょう。

このような発見に基づいて、情報提示の方法や対象となる利用者を再検討します。

定量的な評価

改善案について、作業に必要な情報を見つけるまでの時間、誤った資料を参照する頻度、模擬作業の完了率などを測定できます。

さらに、従来の画面と新しい画面を比較し、改善効果を調べることもできます。

ただし、安全に関わる設備であれば、模擬環境での試験だけで実運用への導入を決めるべきではありません。異常な条件下での誤操作や情報の欠落などについて、十分な技術的検討が必要です。

この事例では、利用者の観察によって問題を捉え直し、試作によって仮説を検討し、定量的な分析によって改善効果を評価しています。

問題構造化とデザイン思考の関係

デザイン思考は、問題構造化と密接な関係があります。

両者とも、最初に与えられた問題をそのまま解くのではなく、問題の定義を見直すことを重視します。

ただし、焦点には違いがあります。

問題構造化では、問題の構成要素、関係者の視点、目的、制約、因果関係などを整理することが中心となります。

一方、デザイン思考では、利用者の経験や行動を理解し、そこから問題を再定義し、具体的な解決策を試作して学ぶことが重視されます。

デザイン思考は、問題構造化を含みながら、解決策の発想と実現へ進むアプローチと考えることもできます。

しかし、すべての問題構造化がデザイン思考へ含まれるわけではありません。

例えば、設備の信頼性や複雑な生産計画の問題では、利用者へのインタビューよりも、物理的な制約条件や数理モデルの分析が中心になる場合があります。

また、政策や組織の問題では、利用者という一つの立場だけではなく、複数の関係者の利害や価値観を検討する必要があります。

問題の性質に応じて、問題構造化とデザイン思考を使い分けたり、組み合わせたりすることが適切です。

デザイン思考と定性・定量の統合

デザイン思考は、インタビューや観察などの定性的な調査と結びつけて説明されることが多い方法です。

しかし、定量的な分析と対立するものではありません。

例えば、顧客の利用状況を詳しく観察することで、新しい問題を発見できます。その問題がどの程度広く発生しているかを知るには、利用ログやアンケートなどを使って定量的に調べることができます。

また、利用者調査で得られた仮説をもとに複数の画面を試作し、操作時間やエラー率を比較することもできます。

さらに、実験計画法（DOE）を利用して、画面の構成要素や情報提示方法が利用者の行動へどのような影響を与えるかを調べることも考えられます。

ただし、定量的に測定した結果が改善したとしても、利用者にとって本当に望ましい結果が得られたとは限りません。

例えば、作業時間が短くなった一方で、重要な確認作業が省略されていれば、安全性が低下している可能性があります。

一つの指標だけで評価するのではなく、利用者の目的や実際の利用状況を考慮することが必要です。

デザイン思考においても、定性的な理解から定量的な検証へ進むだけでなく、測定結果に基づいて問題の捉え方を修正することが重要です。

デザイン思考と創造的思考の関係

デザイン思考では、利用者の問題を発見する活動と、解決策を考える活動が結びついています。

しかし、デザイン思考そのものが、特別な発想原理を提供しているわけではありません。

ブレインストーミング、類推、SCAMPER、TRIZなど、異なる発想技法を組み合わせて利用できます。

例えば、利用者の作業を観察することで、「従来は人間が判断していたことを機械が支援できないか」という問いが生まれるかもしれません。

そこから、別の産業で利用されている自動判定技術や、異なる原理に基づく情報提示方法を探索することが考えられます。

この場合、利用者調査は問題を発見するきっかけになりますが、新しい技術的な解決策を考えるには、技術知識や異分野探索が必要になります。

逆に、新しい技術が先に発見され、その技術を利用することによって従来は想定されていなかった製品やサービスが実現する場合もあります。

技術から新しい用途を考える活動が、常に利用者調査から始まるとは限りません。

デザイン思考は、人間中心の問題発見に優れた特徴を持ちますが、イノベーションの唯一の出発点ではありません。

デザイン思考の限界と批判

デザイン思考は、製品やサービスの開発などで幅広く利用されてきました。しかし、その有効性や適用範囲については、研究上の議論もあります。

例えば、ルーシー・キンベル（Lucy Kimbell）は2011年の論文「Rethinking Design Thinking」で、デザイン思考を普遍的な方法として説明する際に、実際のデザイナーの多様な実践や社会的な文脈が十分に考慮されていないことを批判しています。

また、研究によってデザイン思考の定義や実施内容が異なるため、何が成果を生んだのかを比較・評価することも容易ではありません。

デザイン思考を実務へ適用する際には、特に次のような限界を考慮する必要があります。

共感だけでは正しい理解を保証しない

利用者の経験に共感することは重要ですが、共感によって観察や解釈が正しくなるわけではありません。

利用者の発言や行動について、思い込みによる解釈が入り込む可能性があります。

したがって、観察された事実と解釈を区別し、必要に応じて追加調査を行う必要があります。

利用者の要望が適切な解決策とは限らない

利用者は、自分が経験している問題について重要な情報を提供できます。

しかし、その問題を解決するための技術的な方法について、必ずしも専門知識を持っているわけではありません。

例えば、利用者が「ボタンを増やしてほしい」と希望しても、操作手順全体を見直した方が適切かもしれません。

利用者の要望を尊重することと、それをそのまま設計要件へ変換することは異なります。

少人数の調査では全体を代表しない

少人数のインタビューやユーザビリティテストは、具体的な問題の発見に役立つ場合があります。

しかし、そこで観察された特徴が、すべての利用者に共通するとは限りません。

利用頻度、熟練度、使用環境、文化的な背景などが異なれば、問題も変化する可能性があります。

調査結果を一般化する場合には、適切な標本設計や追加の定量調査などが必要になります。

短時間のワークショップで問題を解決できるとは限らない

デザイン思考は、短時間のワークショップとして実施されることがあります。

しかし、限られた時間で観察、問題定義、発想、試作、検証を一通り体験したとしても、現実の問題について十分な知識が得られたとは限りません。

作業の順番を守ることと、適切な調査や判断を行うことは別です。

形式的なワークショップによって、実際には検討が不十分な問題やアイデアが、完成した結論のように扱われる危険もあります。

技術的・経済的な成立可能性は別途検討する

利用者に望まれるアイデアであっても、技術的に実現できるとは限りません。

また、実現できても、費用、法規制、安全性、保守、組織の能力などの制約によって導入できない場合があります。

特に、製造、医療、交通、社会インフラなどでは、利用者の評価だけで導入を判断することはできません。

専門的な技術検証や安全評価が必要です。

利用者の利益と社会全体の利益は一致するとは限らない

デザイン思考では「人間中心」という表現が使われますが、誰を中心に考えるのかという問題があります。

例えば、あるサービスの直接の利用者にとって便利な仕組みが、そこで働く従業員の負担を増やす可能性があります。

また、特定の顧客にとって魅力的なサービスが、環境や地域社会に負担を与える場合もあります。

利用者だけでなく、影響を受ける関係者や、より広い社会的な条件を考慮する必要があります。

デザイン思考の有効性をどう評価するか

デザイン思考が有効だったかを評価するとき、アイデアの数やワークショップ参加者の満足度だけを指標にするのは不十分です。

例えば、次のような成果を区別して評価する必要があります。

評価対象考えられる評価方法
問題理解の改善従来認識されていなかった問題や制約が明らかになったか
解決策の質利用者の重要な問題に対応しているか
利用しやすさ作業完了率、操作時間、エラー率など
技術的な実現可能性試験、試作、設計検証
事業的な成果導入率、継続利用、費用、収益など
組織的な効果部門間の理解、判断の改善、開発の進行状況

これらの成果は互いに関係しますが、同じものではありません。

例えば、利用者の問題理解が深まっても、その結果として製品の売上が増えるとは限りません。

また、売上が増加したとしても、それがデザイン思考による効果なのか、他の市場条件や販売施策による効果なのかは区別する必要があります。

デザイン思考の有効性を論じる研究も進んでいますが、方法の定義や成果の測定方法が異なるため、すべての状況について一律の効果を主張することには慎重であるべきです。

AI時代のデザイン思考

LLMなどのAIは、デザイン思考のさまざまな活動を支援できます。

例えば、インタビュー記録や自由記述の回答から、問題に関係する概念や特徴を抽出できます。

調査情報を分類し、カスタマージャーニーマップや問題構造の原案を作成することも考えられます。

また、異なる問題定義を比較したり、複数の解決策を提案したり、試作画面の作成を支援したりすることもできます。

しかし、AIによってデザイン思考の作業が自動化されることと、利用者の問題を正しく理解できることは別です。

例えば、実際の利用者を観察せず、LLMに「典型的な顧客の困りごと」を生成させた場合、一般的にはもっともらしい問題が挙げられるでしょう。

しかし、それらが特定の製品や利用者に実際に存在するかは確認されていません。

同様に、AIが生成したペルソナ（Persona）は、実際の調査結果に基づいていなければ、想像上の人物像にすぎません。

ペルソナは利用者の特徴を整理するための表現方法ですが、人物像を具体的に描いたこと自体が、その特徴の妥当性を証明するわけではありません。

AIをデザイン思考へ利用する場合には、観察された事実、調査から得られた解釈、AIが提案した仮説、実際の検証結果を区別することが重要です。

また、AIの提案によって探索の範囲が既存の典型的な解決策へ偏る可能性にも注意が必要です。

AIが生成した候補を参考にしながらも、それだけに依存せず、利用者の観察や独自の技術探索を続けることが望まれます。

ThinkNaviでの位置づけ

ThinkNaviでは、デザイン思考を、利用者の経験を理解することから問題を捉え直し、解決策の発想と検証へ進むための総合的なアプローチとして位置づけます。

関連する個別手法には、ブレインストーミング、KJ法、類推、SCAMPER、問題構造化、概念マップ、意思決定マトリクス、実験計画法などがあります。

例えば、利用者調査で得られた情報をKJ法で整理し、問題の捉え方を比較することができます。

問題を定義した後には、ブレインストーミングや類推によって解決策の候補を考えられます。

複数の候補を比較する場合には意思決定マトリクスなどを利用し、試作や実験によって解決策の効果を調べることもできます。

ThinkNavi Freeでは、調査結果の整理、問題定義、アイデアの比較、評価項目の設定などを支援するワークシートやツールが考えられます。

LLMを利用する場合には、観察記録からの特徴抽出、異なる問題定義の提案、解決策の生成、仮説と検証結果の対応づけなどが開発候補になります。

これらは今後の機能開発の方向性であり、現在すべてが提供されていることを意味しません。

デザイン思考について理解する際に重要なのは、5つの活動を正しい順番で実行することではありません。

人間中心という理念を掲げるだけで、新しい知識や解決策が得られるわけでもありません。

利用者を観察することによって問題の捉え方を変え、解決策を具体的に試すことによって新しい事実を発見し、その結果に基づいて問題と解決策の両方を修正する。デザイン思考の実際的な価値は、この柔軟な探究のあり方にあります。

関連ページ

参考文献・関連資料