デザインシンキング入門:ユーザー視点で課題を解決する方法

アイキャッチ画像
INDEX目次

デザインシンキングとは、ユーザーの課題から出発して解決策を導く人間中心の思考法です。コンサルタント実務の経験をもとに、5ステップの進め方とロジカルシンキングとの使い分けを具体例付きで解説します。

技術的には完璧なシステムなのに、現場で使われない。

SIer時代、何度もこの場面に遭遇しました。要件定義書の通りに作った。テストも全件通った。でもリリース後、現場のスタッフは旧システムを使い続ける。なぜか。答えはシンプルでした。使う人の気持ちを誰も聞いていなかったのです。

デザインシンキングとは、「ユーザーの課題」から出発して解決策を導く、人間中心の問題解決アプローチです。技術ありきでも、戦略ありきでもなく、「使う人は何に困っているのか」を起点にする。この視点を持てるかどうかで、提案の質は根本から変わります。

この記事では、デザインシンキングの基本的な考え方、5ステップの進め方、そしてロジカルシンキングとの使い分けまで、具体例を交えて解説します。

デザインシンキングとは何か

デザインシンキングとは、ユーザーへの共感を出発点に、試作と検証を繰り返しながら課題を解決する思考法です。

英語では Design Thinking。もともとはプロダクトデザインの現場で使われていた手法ですが、IDEOやスタンフォード大学d.schoolの研究を通じて、ビジネスの課題解決全般に応用されるようになりました。

従来のビジネスにおける問題解決は、多くの場合「技術起点」か「戦略起点」で進められます。「この技術を使えば何ができるか」「市場データからどんな戦略が導けるか」。どちらも論理的には正しいのですが、一つだけ抜け落ちがちな視点がある。「使う人は本当にそれを求めているのか?」という問いです。

デザインシンキングは、この問いを最上流に置きます。まずユーザーの行動や感情を観察し、課題を深く理解する。その上で解決策を考え、小さく試して検証する。完璧な計画を作ってから動くのではなく、「作りながら考える」プロセスです。

図解1: デザインシンキングの5ステップ ― 共感問題定義創造プロトタイプテストの循環プロセス

なぜビジネスで注目されているのか

「技術的に正しい」だけでは不十分な時代

SIer時代、私が経験した「使われないシステム」の問題は、技術力の不足ではなく、ユーザー理解の不足が原因でした。

あるプロジェクトで、紙の伝票を電子化するシステムを構築しました。機能としては完璧。でも現場のスタッフは、伝票を手書きするのと同じ項目を画面で入力しなければならなかった。「これなら紙のほうが早い」と言われ、使われなくなったのです。

もしあの時、現場スタッフの業務を観察し、「実際に何に時間がかかっているのか」を理解してからシステムを設計していたら、結果は違ったはずです。技術起点ではなく、ユーザー起点で考える。これがデザインシンキングの本質です。

ケース面接・就活でも差がつく

ケース面接で「新しいサービスを考えてください」と問われたとき、いきなり機能やスペックを語り始める人と、「まずターゲットユーザーの困りごとを整理させてください」と切り出す人では、面接官の印象はまるで違います。

後者は、「ユーザー視点で問題を定義できる人だ」と伝わる。論理的に正しい提案を作る力に加えて、「誰のために解決するのか」を意識できる人は、入社後もチームで信頼される存在になります。

デザインシンキングの5ステップ

デザインシンキングは、5つのステップで構成されます。ただし、一方通行のプロセスではなく、ステップ間を行き来する循環型のアプローチです。

ステップ1: 共感(Empathize)

最初のステップは、ユーザーの立場に立って観察し、理解することです。アンケートやインタビューだけでなく、実際にユーザーの行動を観察する。言葉にならない不満や、本人も気づいていない課題を見つけるのがこのステップの目的です。

「お客様の声を聞く」と言うと簡単に聞こえますが、ここで重要なのは「自分の仮説を一旦脇に置く」ことです。先入観を持ったまま観察すると、自分の仮説を裏付ける情報しか目に入らなくなる。ゼロベース思考と通じる部分です。

ステップ2: 問題定義(Define)

観察から得た情報を整理し、「真に解くべき課題」を定義します。ユーザーが口にする「こうしてほしい」は、必ずしも本当の課題ではありません。

たとえば「もっと速いシステムがほしい」という要望の裏には、「入力項目が多すぎて時間がかかる」という本質的な課題が隠れていることがあります。表面的な要望ではなく、その奥にある真の課題を言語化する。これがイシュードリブンとの接点でもあります。

ステップ3: 創造(Ideate)

定義した課題に対して、できるだけ多くのアイデアを出します。ここでは質より量を重視します。「それは無理だ」「予算がない」といった制約は一旦外して、自由に発想する。

ブレインストーミングのルールに似ていますが、デザインシンキングでは「ユーザーの課題を解決する」という軸がぶれない点が特徴です。発散したアイデアの中から、ユーザーにとって最もインパクトのあるものを選びます。

ステップ4: プロトタイプ(Prototype)

選んだアイデアを、最小限の形で具現化します。完璧な製品を作る必要はありません。紙の模型、画面のスケッチ、簡単なデモ。「伝わる最小限のもの」を素早く作ることがポイントです。

私がコンサルティングの現場で実践しているのは、PowerPointで画面イメージを作り、クライアントに「こんな使い方をイメージしています」と見せる方法です。言葉だけで説明するよりも、ユーザーの反応が格段に具体的になります。

ステップ5: テスト(Test)

プロトタイプをユーザーに見せて、フィードバックをもらいます。ここで得た反応をもとに、問題定義に戻ったり、アイデアを修正したりする。このサイクルを繰り返すことで、解決策の精度が上がっていきます。

重要なのは、テストの結果を受け入れる姿勢です。自分が考えた解決策が否定されても、それは失敗ではない。「この方向ではユーザーの課題は解決しない」という貴重な情報を得たということです。

図解2: ロジカルシンキング vs デザインシンキング ― 正しく組み立てる力とユーザー視点で課題を発見する力の使い分け

コンサルティングとデザインシンキングの融合

ロジカルシンキングとの使い分け

「ロジカルシンキングとデザインシンキングは、どちらを使えばいいのか?」とよく聞かれます。答えは「どちらも使う」です。

ロジカルシンキングは「正しく組み立てる力」。論理的に分解し、構造化し、説得力のある提案にまとめる。一方、デザインシンキングは「正しい問いを見つける力」。ユーザーの行動を観察し、本当に解くべき課題を発見する。

コンサルティングファームに戻って実感したのは、この2つは車の両輪だということです。ユーザー視点で課題を見つけても、それを論理的に構造化して伝えなければ経営者には伝わらない。逆に、論理的に完璧な提案書でも、ユーザーの実態に基づいていなければ、実行段階で「現場で使えない」と言われる。

落とし穴: 「共感」が「迎合」になる

デザインシンキングでよくある失敗は、「共感」が「ユーザーの言いなり」になってしまうことです。ユーザーが「こうしてほしい」と言ったことをそのまま実装するのは、共感ではありません。

ユーザーの要望の裏にある真の課題を見つけ、ユーザー自身も気づいていなかった解決策を提示する。これが、デザインシンキングにおける本当の「共感」です。

落とし穴: プロトタイプを作り込みすぎる

もう一つの落とし穴は、プロトタイプを完璧に作り込もうとしてしまうことです。プロトタイプの目的は「学ぶこと」であり、「見せること」ではありません。30%の完成度でいいから早く見せてフィードバックをもらう。この速度感が、デザインシンキングの生命線です。

図解3: デザインシンキングの2つの落とし穴 ― 共感と迎合の違い、プロトタイプの目的

関連する思考法・フレームワーク

デザインシンキングを学んだら、以下の思考法もあわせて押さえておくと相乗効果があります。

ゼロベース思考

デザインシンキングの「共感」ステップでは、既存の思い込みを外してユーザーを理解します。ゼロベース思考と組み合わせると、より本質的な課題発見につながります。

関連記事: ゼロベース思考:前提を疑い、本質から考え直す技術

イシュードリブン

デザインシンキングの「問題定義」とイシュードリブンの「論点設定」は、「何を解くか」を見極める点で共通しています。

関連記事: イシュードリブン(論点思考)

ロジカルシンキング

デザインシンキングで発見した課題を、ロジカルシンキングで構造化して伝える。この組み合わせが実務では最も効果的です。

関連記事: ロジカルシンキングとは?コンサルタントが実践する論理的思考の基本

問題解決プロセス

デザインシンキングは問題解決プロセスの中で、特に「課題発見」のフェーズに強みを持つ思考法です。

関連記事: 問題解決プロセスの全体像

まとめ

デザインシンキングは、「ユーザーのことを考えましょう」という精神論ではありません。共感し、定義し、創造し、試し、検証する。この具体的なプロセスを通じて、技術起点や戦略起点では見つからない課題と解決策を発見する方法論です。

ロジカルシンキングで鍛えた「正しく組み立てる力」に、デザインシンキングの「正しい課題を見つける力」を加える。この両方を使いこなせる人は、提案が「論理的に正しい」だけでなく「現場で実際に機能する」ものになります。

明日から一つだけ試してみてください。何か新しい企画や提案を考えるとき、「この製品・サービスを使う人は、実際にどんな場面で、何に困っているのか?」と5分だけ想像してみる。その5分が、提案の質を変えてくれるはずです。


著者: Sam(柴山 治)

YOHACK株式会社 代表 | コンサルタント | エンジニア | 映像クリエイター | 著者・監修者

SIerでシステムを作り、ファームで戦略・業務・ITの提案を行い、

事業会社で「提案を受ける側」を経験し、

ファームに戻って経営の意思決定に関わり、そして創業しました。

DXのバリューチェーンを発注側・受注側の両方から見てきた経験が、

私のコンサルティングの土台になっています。

ワシントン大学フォスタービジネススクールMBA修了。

著書『日本型デジタル戦略』(クロスメディア・パブリッシング)等。

▼ YOHACK公式サイト

https://www.yohack.io

▼ ご相談・お問い合わせ

https://www.yohack.io/contact