実践 NEW
デザイン思考 組織導入 失敗事例5選とその克服策
デザイン思考の組織導入が失敗する具体的な事例5つを分析。「なぜうまくいかなかったのか」の構造を解明し、同じ轍を踏まないための克服策を実践的に解説する。
14分で読める
デザイン思考の組織導入に取り組んだ担当者の多くが、半年後に同じ言葉を口にする。「思ったようには定着しなかった」。
ワークショップは盛り上がった。参加者の満足度も高かった。しかし3ヶ月後、現場は元通りの業務フローに戻っていた。デザイン思考の組織導入における失敗は、偶然の不運ではなく、再現性のあるパターンから生まれる。
200回以上のワークショップ支援と組織変革のフィールドワークを通じて、失敗事例には明確な共通構造があることが分かってきた。本記事では、その5つのパターンを具体的に解剖し、それぞれの克服策を提示する。
なぜ「失敗事例」から学ぶのか
デザイン思考の書籍やセミナーは、成功事例にあふれている。IDEOの革新的なプロジェクト、d.schoolの教育変革、AppleやAirbnbの事例。しかし現場の担当者が直面するのは成功事例ではなく、「なぜ自分たちはうまくいかないのか」という問いだ。
失敗には再現性がある。 業種も規模も異なる組織で、驚くほど似通った失敗が繰り返される。それは構造的な問題が存在することを示す。失敗の構造を知ることは、成功事例を模倣することより、はるかに実践的な知識になる。
参加者からの声として多いのは、「事例を聞いて『うちも同じだ』と気づいた瞬間が一番の学びになった」というものだ。自分の状況に重ねられる失敗事例は、抽象的な成功論より遠く射程が届く。
失敗事例1：「ワークショップ一発で変わる」という前提
何が起きたか
ある製造業の中規模企業で、全社員向けのデザイン思考研修が実施された。3日間の集中ワークショップで、全部門からメンバーが集まり、ユーザーインタビューからプロトタイプまでを体験した。終了後のアンケートは好評で、「これで組織が変わる」という雰囲気が醸成された。
しかし1ヶ月後、現場は何も変わっていなかった。「良い体験だったが、普段の業務に戻ったらどう使えばいいか分からなかった」という声が支配的だった。
失敗の構造
この失敗の本質は、「体験の移転」が設計されていなかったことにある。ワークショップは「特別な場」として設計された。付箋、ファシリテーター、特別な空間。これが「普段の業務とは別のモード」という認識を強化してしまう。
ワークショップで身につくのは「体験の記憶」だ。しかし現場で必要なのは「日常業務に組み込める具体的なルーティン」である。この2つは別物だ。
克服策
ワークショップの翌週に「日常業務への接続ミーティング」を必ず設ける。 アジェンダはシンプルでよい。「今週の仕事のどの場面でデザイン思考を使えるか」を15分議論するだけでいい。
重要なのは、抽象的な「デザイン思考の活用」を語るのではなく、「今週火曜日の顧客訪問でインタビューを試みる」「今月中に一つのアイデアを紙で動くプロトとして作る」という具体的な次のアクションを決めることだ。体験を業務のルーティンに変換する橋渡しが、研修の場ではなくその後の設計にかかっている。
詳細な定着ロードマップはデザイン思考の組織導入完全ガイドを参照してほしい。
失敗事例2：「現場を置き去りにした上意下達」
何が起きたか
ある金融機関で、経営層の号令でデザイン思考の全社導入が決定した。外部コンサルが入り、マネージャー層への集中研修が先行した。研修後、各部門でデザイン思考を「実践する」よう指示が下りた。
現場の反応は冷ややかだった。「また経営から新しい言葉が降ってきた」「自分たちの実際の仕事と何が関係するのか分からない」という空気が漂い始めた。3ヶ月後には、デザイン思考という言葉を使うことへの抵抗感すら生まれていた。
失敗の構造
上意下達の導入は、心理的リアクタンスを引き起こす。人は、選択の自由が外部から制限されると感じた時、その制限に抵抗する傾向がある。「やれと言われたからやる」というスタンスは、主体的な問いの探索を妨げる。
また、管理職層が先行して研修を受け、現場は後から指示を受けるという構造も問題だ。デザイン思考の核心は「現場にいる人が、現場の問題を自分の目で観察すること」にある。 現場を先行させずに導入すると、「現場の問題をマネージャーが代わりに解決してくれるツール」という誤解が生まれる。
克服策
現場の「自発的な問い」から始める設計が有効だ。「デザイン思考を導入する」のではなく、「現場が抱えている特定の問題に対して、デザイン思考の特定の手法を試してみる」という切り口で始める。
実際にやってみると効果が高いのは、「志願制の小さなパイロットチーム」からのスタートだ。全社展開の前に、自発的に手を挙げた3〜5人が一つの実際の業務課題にデザイン思考を適用する。その結果を社内で公開することで、「自分たちもやってみたい」という自発的な動きが生まれやすくなる。
失敗事例3：「成果の可視化に失敗した3年間」
何が起きたか
あるIT企業で、デザイン思考チームが組成された。専任メンバー3名が置かれ、プロジェクトを継続的に推進した。プロセスも改善され、ユーザーインタビューの質も上がっていった。しかし経営層からは「費用対効果が見えない」という評価が続き、3年後にチームは解散となった。
現場では確実に良い変化が起きていた。プロトタイプの質が上がり、ユーザーフィードバックを早期に取得できるようになっていた。しかし経営会議に報告される指標に、それらの変化は一切反映されていなかった。
失敗の構造
デザイン思考は、「探索的なプロセス」と「成果の数値化」の間に本質的な緊張がある。探索のプロセスをKPIで縛ると、探索の質が下がる。しかし成果が可視化されなければ、組織的な支持を得続けることができない。
この失敗の根本は、「デザイン思考チームが評価される指標の設計」を怠ったことだ。チームは良い仕事をしていたが、その価値を組織の言語（数値・事例・ビジネスインパクト）に翻訳する工夫が不足していた。
克服策
「プロセス指標」と「ビジネス指標」を分けて設計する。プロセス指標はインタビュー実施回数・プロトタイプ制作数など。ビジネス指標は、デザイン思考を適用したプロジェクトの製品リリース速度・顧客満足度変化・手戻り削減率など。
特に有効なのは「比較事例の作成」だ。デザイン思考を適用したプロジェクトAと、適用しなかった類似プロジェクトBの比較を社内で共有する。プロセスの良さではなく、ビジネスの結果との相関を語ることで、経営層の言語に変換できる。
失敗事例4：「外部ファシリテーター依存の罠」
何が起きたか
ある消費財メーカーで、外部のデザイン思考専門会社と長期契約を結んだ。月1回のワークショップを継続的に実施し、質の高いファシリテーションを外部から受け続けた。参加者の満足度も高く、アウトプットの質も申し分なかった。
2年後、予算削減で外部契約が打ち切られた。内部でワークショップを開こうとした時、「誰もファシリテーターをできない」という現実が明らかになった。 2年間、外部に頼り続けたことで、内部にケイパビリティが蓄積されていなかった。
失敗の構造
外部専門家への依存は、短期的には品質を確保できる。しかし自分たちでできるようになるための「習得の機会」を外部に委託していることでもある。 完成されたファシリテーションを受け続けることと、自分でできるようになることは、別々の活動だ。
ワークショップでよく起こるのは、参加者が「うまくファシリテートされる体験」に慣れ、自分がファシリテーターとして動く必要性を感じなくなることだ。これは経験の非対称性が作り出す問題だ。
克服策
外部ファシリテーターと契約する際に、「内部移転計画」を最初から設計する。具体的には、6ヶ月後に内部ファシリテーターが副ファシリテーターとして参加、1年後に内部が主導で外部はオブザーバー、1.5年後に完全内製化、という段階的な移転ロードマップを契約時に合意しておく。
外部の役割は「実行者」ではなく「コーチ」であるべきだ。 同じ費用でも、設計の方向性が変わるだけで、組織に残るものが全く異なる。
失敗事例5：「スコープの設定ミスによる燃え尽き」
何が起きたか
ある行政機関で、市民サービスの改善を目的としたデザイン思考プロジェクトが立ち上がった。担当チームは意欲的で、ユーザーインタビュー・観察・プロトタイプと着実にプロセスを進めた。しかし初期のスコープが「市民サービス全体の改善」と設定されていたため、問題の範囲が広大すぎた。
インタビューをするたびに問題が増え、インサイトが膨らみ続けた。「何から手をつければいいのか」という問いに対する答えが見つからないまま、チームのエネルギーが枯渇した。プロジェクトは一度も具体的なアクションに到達しないまま終了した。
失敗の構造
デザイン思考の「共感フェーズ」は、問題の全体像を把握するための発散プロセスだ。しかし発散は必ず「収束」と対になる必要がある。スコープが大きすぎると、収束の判断ができなくなる。「まだインタビューが足りない」「まだ問題が見えていない」という感覚が、収束への移行を妨げる。
この失敗は、デザイン思考の「問題定義フェーズ」の軽視からも生まれる。共感フェーズで集まったインサイトを「どの問いに絞るか」を決める工程が、もっとも難しく、もっとも重要だ。ここをスキップして「全部解決しよう」とすると、必ず燃え尽きる。
克服策
プロジェクト開始前に「スコープの境界線」を明示的に設定する。 「この3ヶ月で取り組む問いは一つだけ」という制約を設けることが有効だ。問いが一つに絞られると、インタビューの目的が明確になり、インサイトの収束判断もしやすくなる。
How Might We（HMW）の使い方に慣れると、問いの絞り込みがしやすくなる。「どうすれば〇〇できるか」という形式の問いを複数作り、チームで優先度投票をする。一つのHMWに絞ってプロトタイプを進めることで、具体的なアクションへの到達速度が上がる。
組織変革とデザイン思考の統合についての詳細はデザイン思考で組織変革を成功させる5ステップ実践ガイドでも論じている。
5つの失敗に共通する構造
5つの失敗事例を並べると、共通する構造が見えてくる。
「理想の姿」と「現在の組織状態」のギャップを過小評価していること。 ワークショップへの期待、上意下達の指示、外部依存、スコープの肥大化。これらはすべて、「デザイン思考がうまく機能するための組織的条件」を整える前に、手法だけを導入しようとする点で共通している。
デザイン思考が組織に根付くには、手法の習得と組織の変革設計が同時に進行する必要がある。 手法を知ることと、組織がその手法を日常的に使える状態になることは、まったく別のプロセスだ。
失敗を克服するための共通アプローチ
5つの失敗を乗り越えるための共通アプローチを整理する。
スモールスタート・クイックウィン設計。 最初の成果を6週間以内に出す設計にする。大きな変革を目指すほど、最初の成果を出すハードルが上がる。小さく始めて、小さな成果を積み重ねることで、組織の信頼と関心を維持する。
「次の行動」の具体化。 ワークショップ・研修・ミーティングのたびに、「次の火曜日に誰が何をするか」を15分で決める習慣をつける。抽象的な理解は、具体的な行動に変換されなければ消える。
失敗の記録と共有。 デザイン思考の「失敗を歓迎する文化」は、プロトタイプの失敗だけでなく、導入プロセス自体の失敗にも適用する。 組織内で「何がうまくいかなかったか」を共有することで、次の試みが改善される。
「失敗を知っている」ことが最大の強みになる
「デザイン思考は自分たちの組織には向かない」と結論づける前に、失敗のパターンと自組織の状況を照らし合わせてほしい。多くの場合、問題は「デザイン思考が機能しない」のではなく、「失敗しやすい設計で始めてしまった」ことにある。
200回以上のワークショップ支援で繰り返し観察されるのは、「一度失敗した組織が、失敗の原因を分析して再挑戦した時に、最も深くデザイン思考を組織に根付かせる」という逆説だ。
失敗は終わりではない。失敗の構造を知ることが、本当のスタートだ。
関連記事
- デザイン思考の組織導入完全ガイド｜失敗パターンと3年ロードマップ — 導入から定着までの全体像
- デザイン思考で組織変革を成功させる5ステップ実践ガイド — 成功パターンとの対比
- デザイン思考が失敗する5つのパターン — 手法自体の限界論との接続