デザイン思考とは｜5つのプロセスと新規事業での使い方

「顧客起点で考えよう」。会議ではそう決まったはずなのに、次の会議に並ぶのは競合の機能一覧、社内にある技術、役員が好みそうな市場規模。肝心の「顧客の困りごと」だけが、資料のどこにも見当たりません。デザイン思考は、この順序を入れ替えるためのアプローチです。

解決策を考える前に、利用者がどこで立ち止まり、何を避け、どんな間に合わせでしのいでいるかを見ます。観察から解くべき課題を一文に絞り、完成品よりずっと粗い試作品を当事者に使ってもらいます。反応が想定と違えば、試作品だけでなく、課題の定義や観察時の前提まで見直します。

見栄えのよい付箋やワークショップは目的ではありません。この記事では、デザイン思考の定義、共感・定義・発想・プロトタイプ・テストの5つのプロセス、そして新規事業の現場で観察を投資判断につなぐ使い方を、仮想の作例つきで解説します。

デザイン思考とは何か

デザイン思考とは、利用者の行動と感情を理解し、解くべき問題を捉え直し、複数の解決案を試しながら学んでいく、人間中心の問題解決アプローチです。製品の外観を整える技法に限定されません。製品やサービスはもちろん、業務フロー、顧客との接点、組織内の仕組みまでが対象になります。

確かめるのは「利用者にとって望ましいか」だけではありません。技術的に提供できるかどうかも、事業として続けられるかどうかも、試作と検証のなかで一緒に確かめます。利用者の経験から問題を探る作業と、成立条件を確かめる作業を分断しないためです。

注意したいのは、「人間中心」が顧客の要望をそのまま採用するという意味ではないことです。人は、言うこととやることが食い違います。そのため、発言だけでなく、実際の手順、ためらい、やり直しまで観察します。新規事業では、顧客も解決策も定まっていない段階でこそ使い、曖昧な構想を「観察できる事実」と「試せる案」に変えていきます。

デザイン思考が向く局面・別の手法を優先する局面

デザイン思考が向くのは、顧客課題か解決案のどちらかが未確定で、当事者の観察と試作テストができる探索の局面です。逆に、問題と要求仕様が固まり、評価軸が性能・品質・コストに絞られた局面では、それぞれの設計・実験・品質管理の手法を優先したほうが早く確実に進みます。

デザイン思考の5つのプロセス

デザイン思考の進行は、共感・定義・発想・プロトタイプ・テストの5つに整理できます。各プロセスの成果物は、きれいな資料ではなく「次の判断に必要な材料」です。進捗は会議を開いた回数ではなく、顧客について何が分かり、どの前提を変えたかで測ります。

1. 共感（Empathize）｜言葉より行動を見る

共感のプロセスでは、利用者が置かれている状況を、その人の視点から理解します。可能なら仕事の流れや利用場面に同席し、何を確認するか、誰に助けを求めるか、どこで手書きのメモに戻るかを記録します。発言と行動は、必ず別の記録として残します。

『The Mom Test』（2013年）の著者 Rob Fitzpatrickが示すのは、自社案への感想ではなく、相手の生活と過去の具体的な行動を聞くという原則です。「欲しいですか」という将来の意向だけで判断せず、「直近でその作業をしたとき、最初から順に教えてください」と尋ねます。共感に必要なのは賛同ではなく、行動の理由を検討できる記録です。

2. 定義（Define）｜社内の悩みを顧客の課題へ変える

定義では、集めた事実から「誰が、どんな状況で、何を必要としているか」を一文にします。「既存製品の売上を伸ばしたい」は自社の課題です。「設備の異常に気づいた夜勤担当者が、熟練者の返答を待たずに初動を選びたい」は利用者の課題です。この一文の違いが、後に出てくる案を大きく変えます。

課題文には、対象者、状況、必要な変化、そして観察で得た理由まで書き込みます。「アプリ」など解決策の名前が入っていたら一度外します。「業務を便利にしたい」のように判断対象を特定できない表現は具体化します。テストで課題の取り違えが分かったら、この一文まで戻ってきます。

3. 発想（Ideate）｜最初の案を正解扱いしない

発想では、課題を解く選択肢を広げます。原則は、最初に思いついた案を正解扱いしないこと。機能追加、アプリ化、AI活用といった定番だけでなく、それ以外の提供方法も候補に戻します。

コツは、発散中の評価と選定を分けることです。選定の段階になってはじめて、課題との一致、試しやすさ、自社が提供する理由、事業成立性を確認します。機能だけでなく、提供手順や支払い方も候補に含めます。BtoBなら、利用者に加えて、運用担当者と購買部門が受け入れられる条件も確認項目に置きます。

4. プロトタイプ（Prototype）｜完成させず、問いだけを形にする

プロトタイプは、仮説を「利用者が反応できる形」にした試作品です。紙に描いた画面、クリックできる画面遷移、裏側を担当者が手作業で動かすサービス、会話による再現。どれも立派な候補になります。目的は品質を示すことではなく、答えたい問いを観察できる状態にすることです。

たとえば「この情報の並びで初動を選べるか」だけを確かめたい初回の試作なら、データ連携や認証は範囲から外して構いません。作る前に「何を確かめるか」を一文にし、その問いに答えない要素を削ります。試作品の細部への評価は、今回の仮説の判定とは分けて記録します。

5. テスト（Test）｜感想ではなく使い方を観察する

Nielsen Norman GroupのJakob Nielsenは2001年の論考で、利用者が語る自己申告と実際の行動を分けて扱う必要を指摘しました。テストでも同じです。「どう思いますか」という感想と、具体的な課題を実行してもらったときの行動は、別々に記録します。「設備にこの警告が出ました。普段どおりに対応してください」と依頼し、どこを見て、何を飛ばし、いつ助けを求めたかを残すのです。

進行役は、正しい使い方を教えません。迷った場所と、そのとき発した言葉を分けて記録します。結論を「好評だった」で閉じないことも大切です。続けてよい前提、崩れた前提、次に変える箇所まで残し、仮説の判定文へ落とし込みます。

5つのプロセスは直線ではなく行き来する

5つのプロセスは、共感からテストへ一方向に進む工程表ではありません。テストで課題の取り違えが見つかれば定義へ戻ります。発想の途中で顧客理解が足りないと分かれば共感へ戻ります。順番よりも、得た事実に合わせて戻り先を選ぶことが大切です。

実際の進行では、定義と発想を何度も往復したり、性格の違うプロトタイプを並行して試したりします。プロセス図が横一列に描かれていても、進行まで直線に固定する必要はありません。観察やテストで前提が崩れた時点が、そのまま戻り先になります。

戻る判断を曖昧にしないため、各回の終わりに次の4点を記録しておきます。

1. 観察できた事実
2. 崩れた前提
3. 次に確かめる問い
4. どのプロセスへ戻るか

この記録があると、「進んでいない」のか「誤りを早く見つけた」のかを区別できます。経営会議に報告すべきは完成度ではなく、何が分かり、次の投資判断がどう変わるのかです。

新規事業でのデザイン思考の使い方を作例でたどる

新規事業でのデザイン思考は、顧客課題を探るところから、試作品での初期検証までをつなぐ用途で使います。ここでは製造現場の設備保全を題材にした仮想ケースで、5つのプロセスのつながりを追ってみます。

作例の出発点

ある事業開発チームが「工場向けの保全支援サービス」を検討しているとします。出発時の案は設備データの管理画面。ただし、誰のどの場面を変えるのかは、まだ決まっていません。

共感。 チームは、保全担当者の引き継ぎと異常対応の現場を観察します。夜勤担当者は設備の音や警告を手書きのノートと見比べ、迷うと熟練者へ連絡していました。「記録は足りている」という発言とは裏腹に、必要な記録へたどり着くこと自体の難しさが見えてきます。

定義。 課題文を「設備データを一元管理したい」から、「異常に直面した夜勤担当者が、熟練者の返答前にも安全な初動を選びたい」へ書き換えます。対象が管理業務から、異常直後の判断へ移りました。

発想。 管理画面に加えて、症状から過去事例を探すカード、設備に貼るコード、熟練者へ状況を伝える質問票、初動だけを案内する画面を並べます。アプリ前提を一度外した発想です。

プロトタイプ。 「症状から探すカード」と「熟練者へ送る質問票」を紙で作り、模擬の警告に対応してもらいます。自動連携は作りません。知りたいのは、症状から必要な情報へたどり着けるか、それだけです。

テスト。 利用者は症状カードより先に、設備ごとの過去記録を探しました。そこでカードを設備別に並べ直し、もう一度試します。「利用者が記憶をたどる単位は、症状ではなく設備だ」という事実が残りました。

この仮想ケースで得られたのは、採用された案の数ではなく、投資対象となる問題定義の更新です。利用者の行動を見た結果、解くべき場面は「記録の集約」から「異常直後の初動」へ変わりました。

デザイン思考とリーンスタートアップ・ブレインストーミングの違い

デザイン思考、リーンスタートアップ、ブレインストーミングは、同じ場面を置き換え合う選択肢ではありません。利用者の経験から問題と解決案を探るのがデザイン思考です。事業仮説を検証して学ぶ進め方がリーンスタートアップで、案を広げる技法がブレインストーミングです。守備範囲がそれぞれ違います。

エリック・リースが原著『The Lean Startup』（2011年）で示したBuild-Measure-Learnは、構築したものを計測し、得た学びを次の判断へ返す循環です。一方、アレックス・F・オズボーンが『Applied Imagination』（1953年）で体系化したブレインストーミングは、判断を後回しにして案を発散させる技法です。

実務では、デザイン思考の共感と定義で問いを絞り、発想の場面でブレインストーミングを使い、試作後の結果をリーンスタートアップの事業仮説へ返す、という接続がかみ合います。名称で選ぶのではなく、次に答えたい問いで使う範囲を決めます。

デザイン思考を形骸化させやすい6つの運用

デザイン思考が形骸化する主因は、利用者について得た学びではなく、「手順を実施した事実」を進捗として扱ってしまうことです。5つのプロセスの進捗は、開催回数や付箋の枚数ではなく、利用者の行動を見て課題定義と次の投資判断がどう変わったかで測ります。定義を変えなかった回も、どの観察事実を根拠に残したのかを記録しておきます。そのうえで、現場で繰り返し起きるつまずきが次の6つです。

共感をアンケートだけで終える。 選択式の回答だけで課題を確定しません。仕事の順序と、例外が起きた場面を、対話や観察で追加確認します。発言と実際の動きは分けて記録します。

経営課題を顧客課題として置く。 「自社技術の用途を増やす」は経営テーマです。課題文には対象者、利用場面、必要な変化、観察した事実を書き、自社の目的とは分けます。

最初から作るものが決まっている。 課題文に「アプリ」など解決策の名詞が入っていないかを確認します。入っていれば一度外し、対面支援や運用変更まで含めて候補を出し直します。

プロトタイプを完成品に近づけすぎる。 確かめる問いを一つに絞り、その問いに必要な要素だけを試作品に入れます。細部への評価は、仮説の判定と分けて記録します。

テストで案を売り込む。 説明への反応と、試作品を使った行動は別物です。課題だけを渡したときの操作と、説明が必要だった箇所を残します。

イベント後の担当者が決まっていない。 ワークショップの翌日に顧客へ会う人、継続・変更・停止を決める人、記録を保管する人。この3つは開催前に決めておきます。

社内で始める前に決めること

社内でデザイン思考を始めるなら、研修資料をそろえる前に、対象とする利用場面、会える当事者、次の判断者を決めます。テーマを広く置いたまま人だけを集めても、観察も試作も始まりません。試す相手と今回の問いを、開催前に指定しておきます。

開始前に、次の項目を一枚にまとめます。

• 探索する利用場面：誰が、いつ、何をしている場面か
• 現在分かっている事実と推測：観察済みの事実と、社内の仮定を分ける
• 会う当事者：利用者、購入判断者、導入後の運用担当者を混同しない
• 今回答える問い：課題の存在、解決案の理解、利用行動などから一つ選ぶ
• 終了後の判断者：継続、定義変更、停止を誰が決めるか

BtoBの場合は、利用者、購入判断者、情報システム部門、購買部門、導入後の管理者を分けて確認します。共感の対象を一人のペルソナに閉じず、導入に関わる役割ごとに、受け入れられる条件と追加で発生する作業を記録します。

最初の一巡は、全社制度に広げるより、一つの利用場面と一つの問いに絞ります。終わったら、得た事実、崩れた前提、次に戻るプロセスを残します。その記録が次回の開始点になります。開催の形式と検証の判定方法も、この記録から切り離さずに設計します。

まとめ

デザイン思考は、共感・定義・発想・プロトタイプ・テストの5つを行き来しながら、利用者の経験から解くべき課題と解決案を磨いていくアプローチです。5つを順番に実施したかどうかではなく、観察によって課題定義と次の投資判断がどう変わったかを記録します。

共感では発言だけでなく行動を見ます。定義では社内の事情と顧客の課題を分けます。発想では最初の案を正解扱いせず、プロトタイプは問いに答える最小限にとどめ、テストでは説明より利用者の行動を観察します。結果が想定と違えば、定義や共感まで戻ります。

評価すべきは試作品の見栄えではありません。デザイン思考の価値は、大きな開発投資の前に、解く問題の取り違えを見つけられるかどうかにあります。