実践 NEW
デザイン思考でリーダーシップを変革する — 管理職が組織変革を主導する実践フレーム
デザイン思考によるリーダーシップ変革の実践ガイド。管理職が組織変革を主導するために必要な思考転換、ファシリテーションスキル、チーム設計の3軸を、ワークショップ現場の知見から体系化する。
16分で読める
「うちの部下はデザイン思考が理解できていない」。管理職がこう言う時、問題の多くは部下ではなくリーダー側にある。
デザイン思考を組織に導入する失敗パターンの多くは、リーダー自身が「指示する役割」から「問いを立てる役割」へと変わっていないことに起因する。研修やワークショップを「部下にやらせるもの」として位置づけた瞬間、変革の主体がリーダーから切り離される。
本記事では、デザイン思考による組織変革を「管理職個人のリーダーシップ変容」という角度から解説する。理論的な背景に加えて、ワークショップ現場で繰り返し観察されるリーダーの行動変容のパターンを具体的に提示する。
リーダーシップとデザイン思考の根本的な緊張関係
「解を持つリーダー」という呪縛
日本の多くの組織において、管理職に求められてきたのは「問題を解決する人」という役割だ。上位者から課題を与えられ、それを部下に割り振り、プロセスを管理し、成果を出す。このモデルでは、リーダーがあらかじめ「正しい答え」を持っていることが前提になっている。
デザイン思考が前提とする世界はまったく異なる。「解くべき問題そのものが不明確」な領域では、正しい答えをあらかじめ持つことができない。探索し、試し、失敗し、学ぶプロセスこそが価値を生む。このプロセスにおいてリーダーに求められるのは「解を持つこと」ではなく「問いを共に立てること」だ。
この根本的な転換が、管理職にとってデザイン思考を「難しい」と感じさせる核心にある。知識の問題ではなく、アイデンティティの問題だ。
ファシリテーターとしてのリーダー
ワークショップでよく起こるのは、リーダーが部屋の後ろに座り、部下たちの議論を評価するように見ている場面だ。部下がアイデアを出すたびに「それはコストがかかりすぎる」「それは現実的でない」と評価を加える。
この行動が何をするかというと、部屋の心理的安全を一瞬で消去する。人は「評価される」と感じた瞬間に、探索をやめてリスクを回避し始める。 管理職がいる部屋でアイデアが出ない理由の多くは、ここにある。
デザイン思考において、リーダーはファシリテーターだ。プロセスを設計し、場を整え、心理的安全を保ち、発見を促す。解を評価するのではなく、探索を支援する役割への転換が求められる。
実践フレーム：管理職が変革を主導する3つの軸
軸1：思考モードの切り替え——「収束」と「発散」を意図的に管理する
デザイン思考のプロセスには「発散（Divergence）」と「収束（Convergence）」という2つのモードがある。発散は可能性を広げるフェーズ、収束は選択肢を絞り込むフェーズだ。
実際にやってみると、管理職が最も困難を感じるのは「発散を許容すること」だということがわかる。評価や判断をいったん保留して、「荒唐無稽に見えるアイデア」も場に出させることへの抵抗だ。
これは訓練できる。具体的な手法として、「Yes, and…」ルールがある。誰かのアイデアに対して「でも、それは難しい（Yes, but…）」ではなく「なるほど、そしてさらにこうすれば（Yes, and…）」と応答するルールだ。発散フェーズのワークショップで、このルールを明示的に設定するだけで、部屋の発言量は劇的に変わる。
収束の管理も同様に重要だ。 発散で出たアイデアをどの基準で絞り込むか、誰が決めるか、いつ決めるかをリーダーが設計する。判断を長引かせる組織は発散の後で止まり、判断を急ぎすぎる組織は収束で探索の成果を捨てる。
軸2：共感の組織化——リーダー自らフィールドに出る
「顧客中心」「ユーザーインタビューが大事」という言葉を管理職は知っている。しかしリーダー自身がインタビューに参加したことがあるかどうかは、別の話だ。
200回以上のワークショップで繰り返し観察されるのは、リーダーが「インタビューの結果報告」を部下から受ける構図だ。部下が1週間かけて収集した定性データを、30分のプレゼンで要約を聞く。この構造では、現場で生まれる「生の文脈」が管理職に届かない。
d.schoolが強調するのは、共感は報告書を読むことではなく、直接的な接触から生まれるということだ。リーダーがインタビューに同席する、あるいは自らインタビューを行う経験は、「現場感覚のアップデート」だけでなく、部下への強力なシグナルになる。「このリーダーは現場を見ようとしている」というシグナルが、チームの行動を変える。
参加者からの声として多いのは、「リーダーがインタビューに一緒に来てくれた日から、チームの動きが変わった」というものだ。理論を共有するより、行動を共にする方が変化は速い。
軸3：失敗の制度設計——「速く失敗する」文化の構造的担保
デザイン思考では「早期のプロトタイプ」と「失敗からの学習」を重視する。しかしこれは、組織が失敗に対してペナルティを与えない構造になっていなければ、機能しない。
管理職が「失敗を許容する」と言葉で宣言しても、実際の評価制度・昇進基準・KPI設計が「失敗しないこと」を報酬する構造であれば、部下は失敗を隠すか回避する。言葉と制度のギャップがある限り、部下は制度に従う。
実践的なアプローチとして、「学習レビュー（Learning Review）」 という仕組みがある。月次または四半期ごとに「どんな実験をして、何を学んだか」を共有するミーティングだ。ポイントは「成果」ではなく「学び」を評価基準にすることだ。失敗したプロトタイプから3つの洞察を得た人が、成功した通常業務をこなした人と同等に評価される文化設計が必要だ。
リーダーシップ変革の段階モデル
ステージ1：観察者（0〜3ヶ月）
多くの管理職が最初にいるのがこのステージだ。デザイン思考の研修を受け、概念を理解したが、自分の業務への接続が不明確な状態だ。「面白い考え方だが、うちの部署でどう使うかわからない」という言葉が典型だ。
このステージへの処方箋は、小さな実験の設計だ。自分のチームのミーティング1回を「デザイン思考的」に運営してみる。議題に対してまず「ユーザーは誰か」を問う。それだけでいい。成功体験の積み重ねが次のステージへの入り口になる。
ステージ2：実践者（3〜12ヶ月）
デザイン思考のツールを意図的に使い始めるステージだ。ペルソナを作る、ユーザーインタビューを設計する、プロトタイプを低コストで作る。しかしこの段階では「ツールを使うこと」が目的になりがちだ。
実践者ステージのよくある落とし穴は、HMW（How Might We）を埋めることが目的になり、「この問いが本当に正しい問いか」を立ち止まって問わなくなることだ。ツールは手段であり目的ではないという原則を、実践の中で身をもって学ぶのがこのステージの特徴だ。
ステージ3：体現者（12ヶ月以降）
デザイン思考のマインドセットが日常のリーダーシップに統合されたステージだ。明示的に「デザイン思考を使っている」という意識が薄れ、問いを立てること・共感すること・実験することが「リーダーとしての当然の行動」になっている。
このステージのリーダーの特徴は、会議の最初に「今日の会議で解くべき問題は何か」と問うことだ。また、部下の提案に対して「なぜそのアイデアを思いついたか」「ユーザーはどう感じると思うか」と問い返すことだ。「Yes, but…」ではなく「Tell me more…」が口癖になっている。
組織変革を主導するリーダーの具体的行動
週次ミーティングへの導入
最もハードルが低い出発点は、既存のミーティングに1つの問いを追加することだ。週次チームミーティングの冒頭に「今週、ユーザー（顧客・社内ユーザー）から何か発見はありましたか？」という問いを加える。
最初はほぼ沈黙が起きる。「特に何も」という答えが続く。しかし3週間続けると、部下が日常業務の中で「これは来週の発見として言えるか」という視点を持ち始める。問いを設定することで、観察の習慣が生まれる。
「ヘリコプタービュー」の意図的な練習
管理職に特有の課題は、「現場の細部」と「戦略的な全体像」を行き来する能力だ。デザイン思考でいう「共感」は現場への深潜りを要求するが、リーダーには同時に「なぜこの問題を解くことが組織の目標と整合するか」を問う戦略的視点も必要だ。
ある製造業の事業部では、月に一度「ズームイン・ズームアウト」のセッションを設けている。最初の30分は現場からの生の声（ユーザーインタビューの断片、顧客クレームの原文）を読む時間。次の30分は「この声が示唆する戦略的課題は何か」を議論する時間。この2段構えが、現場感覚と戦略視点の乖離を防いでいる。
心理的安全の可視化
Google の Project Aristotle が示したように、チームのパフォーマンスを決める最大の要因は心理的安全性だ。しかし心理的安全は「ある/ない」の二値ではなく、誰が・どのような場面で・どの程度安全を感じているかという分布を持つ。
実践的な手法として、月次チームサーベイに1つの問いを加える方法がある。「先週、何かアイデアを出すのをためらった場面はありましたか？」という問いだ。匿名で回答を集め、結果をチームに共有する。この可視化だけで、チームの心理的安全への意識は変わり始める。リーダーが「心理的安全を大事にしている」という言葉より、「それを測っている」という行動の方が部下に届く。
導入時のよくある失敗と対策
失敗1：リーダーが研修に参加しない
最もよく起こる失敗パターンだ。「デザイン思考研修」を部下に受けさせるが、リーダー自身は業務多忙を理由に参加しない。この構造が生むのは、「部下はデザイン思考の言語を話せるが、リーダーとの対話で使えない」という断絶だ。
対策は単純で、リーダーが最初のセッションに参加することだ。全プログラムを通じる必要はない。しかし「リーダーも同じ体験をしている」という事実が、チームの行動変容を加速させる。
失敗2：成果を急ぎすぎる
「3ヶ月でデザイン思考を組織に定着させる」という目標を設定した結果、ワークショップの回数を増やし、アウトプットの数を管理指標にする。しかしデザイン思考の定着はアウトプットの数ではなく、問いを立てる習慣の定着で計測されるべきだ。
対策として、「行動変容の指標」を設定する。「ユーザーインタビューを実施したチーム数」「プロトタイプを試した施策数」「HMWを使って問いを立て直した会議の数」など、プロセスの変化を追う指標が有効だ。
失敗3：「デザイン思考部門」を作る
デザイン思考の専任チームを作り、「彼らに任せれば変革が起きる」と考える罠だ。専任チームは確かに推進力になるが、他の部門が「デザイン思考はあの人たちの仕事」と捉えた瞬間に、組織全体への浸透が止まる。
対策は、専任チームを「推進者」ではなく「ファシリテーター」として位置づけることだ。各部門のリーダーが主体者であり、専任チームはそれを支援する構造が必要だ。組織全体への導入ガイドはこちらで詳しく解説している。
やってみよう：今週できる3つのアクション
アクション1：「問いのリストアップ」ミーティング（30分）
次のチームミーティングの冒頭30分を「問いのリストアップ」に使う。今チームが取り組んでいるテーマについて、「私たちが当然だと思い込んでいる前提は何か？」「ユーザーは本当に何を求めているのか？」という問いを出し合う。解を出す時間ではなく、問いを広げる時間だ。
アクション2：インタビューへの同席（半日）
今週、顧客や社内ユーザーへのインタビューに1回だけ同席する。部下がインタビューを設計・実施し、リーダーは観察者として参加する。後で「何が一番意外だったか」をチームで5分間共有する。この体験は、報告書を何十枚読むより多くを変える。
アクション3：「学習レビュー」の設計（1時間）
来月から月次の「学習レビュー」を始める。アジェンダはシンプルだ。「今月、試したことは何か」「何を学んだか」「次に試すことは何か」の3問。評価基準を「成果の大きさ」から「学びの深さ」に変える。 このシフトを宣言するだけで、チームのリスクテイク行動は変わり始める。
リーダーシップ変革とデザイン思考の本質的な接続
デザイン思考の核心は「正解のない問題に向き合う方法論」だ。そしてリーダーシップの本質も、今日ますます「正解のない状況を組織として越えていく能力」にある。
管理職がデザイン思考を「部下に教えるもの」として扱う限り、その変革は表層にとどまる。 リーダー自身が「問いを立てること」「共感すること」「実験すること」を日々の行動として体現する時、チームは変わり始める。
チェンジマネジメントとデザイン思考の統合論として、この変革プロセスをより体系的に理解したい方はチェンジマネジメント × デザイン思考 統合導入論も参照してほしい。リーダーシップ不在が招く具体的な失敗パターンについてはデザイン思考の組織導入で失敗する5つのパターンに詳しい。
チームに共感を植え付けるツールとして、エンパシーマップ活用ガイドも合わせて参照されたい。
参考文献
- Kelley, T., & Kelley, D. (2013). Creative Confidence: Unleashing the Creative Potential Within Us All. Crown Business.
- Liedtka, J., & Ogilvie, T. (2011). Designing for Growth: A Design Thinking Tool Kit for Managers. Columbia Business School Publishing.
- Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. Harper Business.
- Edmondson, A. (1999). “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly, 44(2), 350–383.