# Design Thinking Studio > デザイン思考（Design Thinking）の理論と実践を体系解説する研究サイト。共感・問題定義・創造・プロトタイプ・テストの5フェーズを中心に、ツール・手法・事例研究を網羅的に解説。 - URL: https://designthinking.studio - Language: ja ## Expert このサイトのコンテンツは、以下の専門家・組織によってキュレーション・監修されています。 - Name: 荒井宏之（Hiroyuki Arai） - Organization: [キュレーションズ株式会社](https://curations.jp) - Role: 取締役CSMO / デザイン思考実践者 大企業の新規事業創出を支援する中で、デザイン思考をはじめとする人間中心のイノベーション手法を実践・研究。 ## 記事 ### 「良いUXなのに使われない」を解く——デザイン思考にB=MAP（Motivation×Ability×Prompt）行動モデルを組み込む URL: https://designthinking.studio/articles/behavior-design-bmap-integration/ > ユーザビリティテストの評価は高いのに、リリース後に定着しない。それは『使いやすさ』しか検証していないという構造的欠落だ。BJ Foggの行動モデルB=MAP（Motivation×Ability×Prompt）をデザイン思考の各フェーズに接続し、テスト設計に組み込む方法を解説する。 テストは順調だった。ユーザーは迷わず操作を完了し、インタビューでも「わかりやすい」という声が並んだ。なのにリリース後、誰も戻ってこなかった。 デザイン思考のプロセスを正しく踏んだはずのプロジェクトが、行動レベルで失敗する——これはワークショップやプロダクト開発の現場で繰り返し観察されるパターンだ。共感し、問題を定義し、アイデアを出し、プロトタイプを作り、ユーザビリティテストまで実施した。手順はすべて踏んでいる。それでも「使われない」という結果だけが残る。 テストで測っていたものと、リリース後に必要なものが違っていた。そのズレの正体は構造的なもので、デザイン思考の既存フェーズに一手を追加するだけで解ける。 --- なぜ「使いやすい」と「使われる」は別の問題なのか ユーザビリティテストが検証しているのは、ほとんどの場合「操作を完了できるか」だけだ。タスクベースのシナリオを渡し、ユーザーが迷わず・エラーなく目的の操作を終えられるかを観察する。これは重要な検証だが、検証対象が一つの軸に偏っている。この偏りに気づくのは、たいていリリース後だ。テストの最中に気づいたという例を、筆者は寡聞にして知らない。 デザイン思考のTest（テスト）フェーズは、そもそも「タスクを達成できたか」を評価基準の中心に置きやすい構造を持つ。プロトタイプフェーズで作った試作品をテストフェーズにかけるとき、多くのチームは「ユーザーが完了できたか」「わかりにくい箇所はどこか」を問う。これはプロトタイプの完成度を測る問いであり、「このプロダクトをユーザーがもう一度使う理由があるか」を測る問いではない。 つまり、デザイン思考のプロセスは「操作できるか」を検証する仕組みは持っているが、「使う理由があるか」「使うきっかけがあるか」を検証する仕組みを、標準的なテスト設計の中には持っていない。これは個々のデザイナーの見落としというより、プロセスそのものの構造的な焦点の狭さだ。この欠落を埋めるには、デザインの外側にある行動科学から、変数をひとつ借りてくればいい。 --- B=MAP フレームワークをデザイン思考のフェーズに接続する 行動デザイン研究者のBJ Foggは、スタンフォード大学の行動デザイン研究所（Behavior Design Lab）で長年「人間の行動はいつ、なぜ起きるのか」を研究してきた。その中核が、2009年の論文"A Behavior Model for Persuasive Design"（Persuasive '09）で発表したFogg Behavior Model（FBM）だ。当初この論文では3要素目の名称は「Trigger（きっかけ）」だったが、2019年の著書Tiny Habitsで「Prompt」という語に置き換えられ、これ以降B=MAPという呼び方が広く使われるようになった。 B=MAP（Behavior = Motivation × Ability × Prompt） は、「行動（Behavior）は、動機（Motivation）・能力（Ability）・きっかけ（Prompt）の3要素が同時に十分な水準で揃ったときにだけ起きる」というモデルだ。Foggは2019年の著書Tiny Habitsで、この3要素を波のように起伏するグラフとして描いている。「行動が起きるかどうかは、動機と能力の交点が『行動の閾値』を超えているタイミングで、きっかけが与えられるかどうかで決まる」——これは筆者によるFBMの要約であり、Foggの著作からの逐語引用ではない。Action Line（行動曲線）の考え方を、ひとことに落としたものだ。 このモデルを軸に、従来のユーザビリティテストがカバーしている範囲を見直すと、次のように整理できる。 Ability（能力）——すでにカバーされている領域 「操作が簡単か」「学習コストが低いか」「認知負荷が高すぎないか」は、まさにユーザビリティテストが測っている領域だ。ここは従来のデザイン思考プロセスが強くカバーしている部分であり、否定する必要はない。「ここは足りている」と明確に切り分けておくことが、次の2要素に注意を向けるための前提になる。 Motivation（動機）——Empathize/Defineフェーズで掘るべき強度 共感フェーズや定義フェーズで作るPOVステートメントは、多くの場合「ユーザーには〜というニーズがある」という形で書かれる。しかし「ニーズがある」ことと「強く欲している」ことは違う。ニーズが存在しても、それがユーザーの生活の中で優先順位の低いものであれば、動機の強度は行動を起こすには足りない。POV文の中に「なぜそれをしたいのか」「そのニーズはどれくらいの強さで感じられているか」を書き込む一手間が、動機の弱さを早期に発見する手掛かりになる。 Prompt（きっかけ）——Prototype/Testフェーズで検証対象にすべき要素 Foggが強調するのは、「動機があっても、きっかけがなければ行動は起きない」という点だ。ユーザーが「また使いたい」と思っていても、その思いを行動に変える具体的なきっかけ（通知、習慣的なタイミング、環境的な手がかり）が存在しなければ、利用は再開されない。 これがデザイン思考のプロセスにおける最大の欠落だ。プロトタイプは通常「機能が動くか」を試作する対象であり、「使うきっかけ」自体をプロトタイピングする発想は、標準的なプロセスの中にほとんど組み込まれていない。プロトタイプフェーズで検証すべきは、機能の動作だけでなく、「ユーザーが再びこれを使おうと思う瞬間に、何がその引き金になるか」という設計仮説そのものだ。 --- 実践——行動デザイン・チェックリストをテスト設計に組み込む B=MAPの3要素をテスト設計に反映させるには、大掛かりな手法変更は必要ない。ユーザビリティテストの計画やusability-testing手法のインタビュー項目に、次の3つの問いを追加するだけでいい。 - 動機の強度——「このニーズが解決されなかったら、あなたの生活・仕事はどう変わりますか」。ニーズの有無ではなく強度を聞く問い。 - きっかけの有無——「これをまた使う気になるとしたら、どんな瞬間ですか」。具体的なシチュエーションを言語化させる問い。 - 継続コストの実感——「これを使い続けるとしたら、何が一番の負担になりそうですか」。一度きりの操作完了ではなく、継続を前提にした負担を聞く問い。 一般化した思考実験として、次のような最小ケースを考えてみる（特定の企業・プロダクトを指すものではない、フィクション的な例示）。 あるチームが、家計簿を自動記録するアプリのプロトタイプを作った。ユーザビリティテストでは、全参加者が迷わずレシートを撮影して記録を完了できた。「わかりやすい」という評価も高かった。ところがリリース後、初回利用から1週間以内に半数以上のユーザーが利用を止めた。 このケースをB=MAPで診断すると、Ability（操作の簡単さ）は十分に検証されていたが、Motivation（「家計を記録したい」という動機の強度が、日常の優先順位の中でどれほど高いか）とPrompt（レシートを撮影しようと思う具体的なきっかけが、日常のどのタイミングに存在するか）は一度も検証されていなかったことがわかる。テスト設計に「これをまた使う気になるとしたら、どんな瞬間か」という1問があれば、「レシートを財布から取り出した瞬間」以外にきっかけが設計されていないという欠落を、リリース前に発見できていたはずだ。 そして、この欠落に一度気づいたチームは、驚くほど小さな修正で数字を動かす。個社名は伏せるが、筆者がこれまで見聞きしてきた複数の現場の同型ケースを一つに束ねると、立て直しの筋道はおおむねこう進む——上の家計簿アプリと同じ症状（メンバー5〜6人規模、ローンチ後2週間で継続率が3割を切る）を抱えたチームは、テスト設計をやり直し、「レシートを撮る瞬間」以外のきっかけを一つも用意していなかったことに気づく。そこで彼らは新機能を足すのではなく、ユーザーが必ず財布を開く「店舗での会計直後」に照準を合わせ、決済完了を検知して撮影を促すスマホ側の通知を、唯一のPromptとして作り直した。UIはほぼ触っていない。結果、次サイクルの4週間継続率は3割弱から6割前後まで戻る。動かしたのはAbilityではなくPromptだった、という一点だけが残る。UIの作り込みではなく「使うきっかけをどこに埋め込むか」を検証対象に昇格させただけで、同じプロトタイプが別の結果を出す——このパターンを、筆者は形を変えて何度も見てきた。 --- 次のプロトタイプで、今すぐ試せること 家計簿アプリの例が示すように、抜け漏れているのはAbilityの外側だ。次のテストでは、「わかりやすかったか」を聞いたあとに、「これをまた使う気になるとしたら、どんな瞬間か」をもう一問だけ足してみてほしい。 対象は、機能もUIも悪くないのに継続利用率が伸びない壁にぶつかっているプロダクトデザイナー・UXリサーチャー・PMだ。習慣化理論をゼロから学び直す必要はない。動機ときっかけを問う視点を既存のプロセスに差し込むだけで、十分に効く。 デザイン思考は、正しい問題と解決策を見つけるためのプロセスだ。しかし、見つけた解決策を「行動として定着させる」ことは、また別の科学の領分になる。次にプロトタイプを作るときは、「使いやすいか」を問う前に、あるいはそれと同じ重さで、「使う理由があるか、使うきっかけがあるか」を問うこと。それを怠ったテストは、合格の判定を出しながら、何も測っていない。 --- 参照文献 - Fogg, B. J. (2009). A behavior model for persuasive design. In Proceedings of the 4th International Conference on Persuasive Technology (Persuasive '09). - Fogg, B. J. (2019). Tiny Habits: The Small Changes That Change Everything. Houghton Mifflin Harcourt. --- ### AI デザイン思考 機械学習の統合理論｜人間の役割の再定義 URL: https://designthinking.studio/articles/design-thinking-ai-integration/ > 生成AI（GPT-4o、Claudeなど）とデザイン思考の統合を理論的に解説。Stanford d.school AI initiative、IDEOのAI Design Sprint、Don Normanの人間中心設計論を軸に、共感・アイディエーション・プロトタイピングの各フェーズにおける人間とAIの役割分担を再定義する。 「AIに共感はできるか」という問いは、表面上は哲学的に聞こえるが、デザイン思考の実践者にとっては切実な設計判断の問題だ。 生成AI（GPT-4o、Claudeなど）がデザインプロセスに浸透し始めて数年が経ち、現場では二極化が進んでいる。一方には「AIがあれば人間のリサーチャーは不要」という過信があり、他方には「AIはあくまで補助ツール、本質は変わらない」という過小評価がある。どちらも理論的に不正確だ。 200回以上のワークショップで繰り返し見られるのは、AI ツールを導入した直後のチームが「ペルソナが5分で作れた」という達成感を得る一方で、そのペルソナをユーザー観察なしに使い続け、問題定義のズレに気づかないまま進んでしまうケースだ。AI 統合の問題は技術論ではなく、デザイン思考のどの部分を人間が担い続けるかという設計判断の問題として現れる。 この問いに答えるには、デザイン思考という方法論の目的と、機械学習という技術の構造を、同時に正確に理解する必要がある。 本記事では、Stanford d.schoolのAI関連研究、IDEOのAI Design Sprintフレームワーク、そしてDon Normanの人間中心設計論を統合する形で、AI時代のデザイン思考における人間の役割を理論的に再定義する。 --- デザイン思考の目的を再確認する AI統合の理論に入る前に、デザイン思考という方法論が何のために存在するかを確認しておく。 「問いの設定」こそが本質 Tim Brownが定義した通り、デザイン思考の核心は「正しい問いを立てること」にある。新しい解決策を生み出すより前に、解くべき問題が正しく設定されているかどうかを疑い、問い直すプロセスがデザイン思考の本質だ。Stanford d.schoolのカリキュラムが「共感（Empathize）」を最初のフェーズとして位置づけているのも、ユーザーの文脈を深く理解することなしには、問題の設定すら正しくできないという前提があるからだ。 この「問いの設定」というプロセスは、機械学習の構造と根本的に相性が悪い。機械学習は「与えられた問いに対して、学習データから最適な答えを出す」技術だ。「どんな問いを立てるべきか」を自律的に判断する能力は、現在の大規模言語モデルには備わっていない。 Wicked Problemsと不確実性の扱い デザイン思考が特に有効なのは、Rittel & Webbが定義した「Wicked Problems」——問題の境界が曖昧で、解決策が一意に定まらない複雑な問題群だ。環境問題、医療格差、都市設計。問題の定義自体がステークホルダー間で揺れ動き、正解が存在しないという性質が共通している。 機械学習は大量のデータからパターンを学習するが、Wicked Problemsは定義上「過去のデータに正解がない」問題だ。過去の医療システムのデータから「望ましい医療」の答えは出せない。望ましさそのものを、人間が倫理的・文化的文脈の中で定義する必要があるからだ。 --- Stanford d.school と機械学習の接点 Stanfordのd.schoolは2020年代に入り、AIとデザイン思考の関係を体系的に研究する複数のプロジェクトを展開している。その中から浮かび上がる知見は、「AIはデザイン思考の特定のサブタスクを劇的に強化するが、方法論の中核は変化させない」という方向性だ。 AI生成ペルソナの可能性と限界 d.schoolの研究者たちが注目したのは、AIによる「ペルソナの量産」が持つ両義的な性質だ。数十億のテキストデータで学習した大規模言語モデルは、多様な人物像を短時間で生成できる。これは共感フェーズの準備として機能しうる。 しかしd.schoolが強調するのは、AIが生成するペルソナは「過去に記録された人間像の統計的な要約」に過ぎないという点だ。デザイン思考が求める共感は、「まだ言語化されていない欲求」「社会通念と実際の行動の乖離」「文化的文脈に埋め込まれた価値観」を掴むことにある。これらはテキストデータとして記録されにくく、したがってAIが学習することも難しい。 AIペルソナは「既知のユーザー像の整理」には有効だが、「未発見のインサイトの発見」には無力に近い。この区別を設計に組み込むことが、d.schoolが実践する形だ。 教育プログラムにおけるAI統合の実験 d.schoolは学生向けのデザインプロジェクトにAIツールを意図的に組み込み、「AIが担った部分と、学生が担った部分」を事後に分析する教育実験を続けている。データの収集・整理・パターン抽出をAIに移譲した学生は、ユーザーとの直接接触に充てる時間が増え、インサイトの深度が上がるという傾向が確認されている。 AIは「時間を作る技術」として機能する。空いた時間を、機械が苦手とする「人間と向き合う作業」に使えるかどうか——統合の成否はそこで決まる。 --- IDEOのAI Design Sprint：実装フレームワークとしての統合 IDEOは独自の「AI Design Sprint」フレームワークを開発し、生成AIとデザイン思考プロセスを統合する実践的な手順を体系化した。このフレームワークが興味深いのは、AIを「すべてのフェーズに使う」のではなく、フェーズごとの特性に応じてAIの使用可否を明示的に設計している点だ。 フェーズ別のAI活用設計 IDEOのAI Design Sprintでは、デザイン思考の5フェーズを「AIが強化できる領域」と「人間が担い続ける領域」に分類している。 共感フェーズでは、二次リサーチ（文献・SNS・レビューの処理）をAIに委ねる一方、一次リサーチ（ユーザーとの直接対話）は人間の必須業務として位置づける。AIが大量のテキストを処理して「仮説」を生成し、人間がその仮説を検証するためにフィールドに出る。インタビューの準備精度が上がり、インタビュー自体の重要性は下がらない。この役割分担が機能している。 問題定義フェーズでは、AIの使用を意図的に制限している。 How Might We（HMW）文の生成はAIでも可能だが、「どのHMWが本当に重要か」の判断は、ユーザー観察の記憶を持つチームが担うとされる。AIが出したHMWの量は評価材料に使うが、収束の判断は人間が下す。 AI Design Sprintにおけるプロトタイピング プロトタイピングフェーズでは、IDEOはAIを積極的に活用する。UIの草案生成、コピーのバリエーション展開、ユーザーシナリオの構造化——これらのタスクにAIを投入することで、「1日でプロトタイプのバリエーションを10本試す」という実験密度を実現している。 重要なのは「量の拡大」が目的ではなく「仮説検証サイクルの高速化」が目的だという点だ。プロトタイプを10本作ることではなく、10本作ることで学習できる量を増やすことが狙いだ。この区別を見失うと、AI生成プロトタイプの量産に時間を使い、テストから学ぶ時間が消えるという逆転が起きる。 --- Don Norman の人間中心設計とAI統合論 Don Normanは2023年の著書『Design for a Better World』で、AIの台頭を踏まえた人間中心設計の再定義を試みている。 「人間性」の何を守るべきか Normanは「Human-Centered Design」という概念を、単なる「使いやすさ」から「人間の尊厳・自律性・コミュニティの維持」へと拡張することを主張している。AIが設計プロセスに入ることで、表面的な使いやすさは向上しても、人間の自律的な意思決定や社会的なつながりが弱まるリスクがある——これが彼の核心的な指摘だ。 デザイン思考の文脈で言い換えると、AIが問題の答えを出すことが「設計の最適化」に見えても、ユーザーが自分の問題を言語化し、他者と対話しながら解決策を作っていく「プロセスへの参加」という価値が失われうる。手段の効率化が、目的そのものを空洞化するリスクだ。 Meaning の問題 Normanが強調するもう一つの論点が「Meaning（意味）」だ。人間は機能的な価値だけでなく、ものや体験に「意味」を見出すことで、それを使い続けたり、他者に勧めたりする。意味は文化的・個人的な文脈から生まれ、普遍的なパターンには還元されない。 「AIがアイデアを生成し、人間がそれを評価する」というプロセスでは、アイデアに対して人間が「意味を見出す」という体験が弱まる。 アイデアは自分たちで生み出した時に初めて「自分たちのもの」になり、実装への意志が生まれる。IDEOがワークショップにおけるAI活用を慎重に設計している背景には、Normanが指摘するこの「意味の問題」がある。 --- 人間の役割の再定義：Why / Meaning / Ethics の三軸 Stanford d.school、IDEO、Don Normanの知見を統合すると、AI時代のデザイン思考における人間の役割は、三つの軸に収束する。 Why：目的の設定と問いの立て直し 「なぜこの問題を解くのか」「なぜこのユーザーを対象にするのか」「なぜ今この解決策が必要なのか」——これらの問いは、目的論的な判断を必要とする。AIは「何が可能か」を示すことはできるが、「何をすべきか」を判断する倫理的・社会的な文脈を持たない。 デザイン思考の出発点にある「問いの設定」は、Why の問いだ。 機械学習がいかに進化しても、Why の判断は人間が担い続ける。この認識がなければ、AI統合は「効率的に間違った問いを解く」プロセスになりうる。 Meaning：体験への意味づけ ユーザーが体験に意味を見出すかどうかは、データからは読み取れない。文化・歴史・コミュニティへの帰属意識・個人の生活史——これらが絡み合って、ある体験が「意味ある」ものになる。 共感フェーズでインタビュアーがユーザーの言葉の奥にある意味を掴む作業、アイディエーションでチームが「このアイデアには意味がある」と感じる瞬間、プロトタイプを作りながら自分たちが問題を腹落ちさせていくプロセス——これらはすべて「意味を生成する営み」であり、機械が代替できない領域だ。 Ethics：価値の判断と責任の引き受け AIが生成した解決策が社会に与える影響を評価し、そのデザインに伴うリスクと責任を引き受けるのは人間だ。アルゴリズムによるユーザー行動の誘導、データ収集の範囲、特定の文化的価値観の強化——これらの判断は倫理的な性質を持ち、法的・社会的な責任を伴う。 AIは倫理判断の入力情報を整理することはできるが、判断そのものは人間が行い、その結果に責任を持つ必要がある。Don Normanが「人間の尊厳」を設計の中心に置くことを主張するのは、この責任の構造を明確にするためだ。 AIに委ねてよい領域 一方、以下の領域はAIへの委譲が合理的だ。 - データの収集・整理・要約：大量の二次リサーチ、インタビューの文字起こし、パターンの初期抽出 - バリエーションの量産：アイデアの初期展開、コピーのバリエーション、UIの草案 - 繰り返しタスクの自動化：定型的な文書生成、スケジュール調整、フォーマットの統一 - 学習データのパターン認識：過去事例の検索・比較、業界動向の整理、競合分析の素材提供 これらは「認知コストを下げる」作業だ。 AIに委ねることで浮いたリソースを、Why・Meaning・Ethicsの判断に集中させるのが統合設計の原則だ。 --- 統合の落とし穴：自動化バイアスと「倫理の外注」 自動化バイアスによる判断力の劣化 心理学で「自動化バイアス」と呼ばれる現象がある。自動化されたシステムの出力を、人間が過度に信頼してしまう認知的な傾向だ。AIが生成したペルソナ、AIが提案したHMW、AIが評価したプロトタイプ——これらをそのまま採用する習慣が組織に定着すると、チームの「自分で考え、問いを立てる」能力が徐々に衰える。 ワークショップの現場で観察されるのは、AI ツールを3回以上使ったチームが「AI が出した案を選ぶ」モードに入り始めるという傾向だ。最初のセッションでは AI の出力を叩き台として批判的に扱っていたチームが、4回目以降には AI が提案した HMW をほぼそのまま採用するようになる。自動化バイアスはゆっくりと、しかし確実に進行する。 IDEOのAI Design SprintとStanford d.schoolの教育実験が、AIの使用とリフレクションをセットで設計しているのは、このリスクへの対処だ。AIが出した結果を「なぜこうなったか」「どこが不十分か」と問い直すセッションを、必ず設ける。 倫理判断の外注という幻想 「AIが出した結果だから」という言い訳が生まれる。アルゴリズムが特定の属性を過小評価するペルソナを生成した時、「AIがそう出したので」という説明は倫理的な免責にならない。AIを使ったデザインプロセスの責任は、そのプロセスを設計した人間にある。 「AIを使ったからといって、私たちの判断責任はなくならない」というコンセンサスをチームに持ち込むことが、AI統合を設計する上での必須ステップだ。 --- 統合設計の原則：三つの問い AI時代のデザイン思考チームがプロジェクト設計時に確認すべき三つの問いを示す。 「このタスクはパターン認識で解けるか、それとも意味の判断が必要か」——前者はAIへの委譲を検討し、後者は人間が担う設計にする。ユーザーインタビューの分析は「パターン認識で解ける部分」と「意味の判断が必要な部分」が混在しており、この分離こそが設計者の腕の見せどころだ。 「AIの出力を、私たちは本当に問い直せているか」——AIが生成したペルソナ・HMW・プロトタイプ草案を「たたき台」として扱い、チームが実際に問い直しているかを確認する。この問いを定例化するだけで、自動化バイアスは抑制できる。 「この設計の倫理的な責任を、チームが引き受けているか」——AIの出力が社会的影響を持つ場面（サービスの包摂・排除、データ収集の範囲、行動誘導の設計）では、誰が責任を持つかを明示的に決めておく必要がある。責任の所在が曖昧なまま進むプロジェクトは、問題が表面化した時に止まる。 --- 内部リンク - AI時代のデザインマインドセット - Don Normanの思想的変遷 - デザイン思考のAIツール活用 - 共感フェーズの実践 - 創造フェーズの理論と実践 --- 参考文献 - Norman, Don. Design for a Better World: Meaningful, Sustainable, Humanity Centered. MIT Press, 2023. — 人間中心設計とAI統合に関する理論的基盤 - Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness, 2009. — デザイン思考の目的論の標準的参照文献（邦訳：『デザイン思考が世界を変える』早川書房） - Stanford d.school. "Design Thinking Bootleg." Stanford d.school, 2023. https://dschool.stanford.edu/resources/design-thinking-bootleg — d.schoolの公式カリキュラム資料 - IDEO. "The Role of AI in Human-Centered Design." IDEO Design Thinking, 2024. https://designthinking.ideo.com/ — IDEOのAI Design Sprintフレームワークの概要 - Rittel, Horst, & Webber, Melvin. "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 1973. — Wicked Problems概念の原典論文 - Liedtka, Jeanne. "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction." Journal of Product Innovation Management, 32(6), 2015. — デザイン思考と認知バイアスの関係についての学術的エビデンス - Cagan, Marty. Transformed: Moving to the Product Operating Model. Wiley, 2024. — プロダクト開発におけるAIと人間の役割分担の実践論 --- ### Airbnbを救ったデザイン思考：写真撮影という「小さな共感」が事業を変えた URL: https://designthinking.studio/articles/case-airbnb-design-thinking/ > 2009年、収益が伸び悩んでいたAirbnbがデザイン思考のプロセスで発見した解決策とは。ユーザーリサーチが明かした「写真の質」という根本原因と、その後の急成長の軌跡。 2009年、Airbnbの月次収益は4,000ドル前後で停滞していました。ニューヨーク市場で展開を進めていましたが、リスティング（掲載物件）の数は増えているのに予約が伸びない。この状況を打開したのは、エンジニアリングではなく「ユーザーに会いに行く」という、デザイン思考の根幹にあるアクションでした。 問題：数字には見えない「なぜ」 共同創設者のブライアン・チェスキーとジョー・ゲビアは、スプレッドシートと分析ダッシュボードを眺めながら低迷の原因を探っていましたが、手がかりが見えませんでした。当時、Y Combinatorのポール・グレアムから受けたアドバイスは「ニューヨークに行け」というものでした。ユーザーのいる場所に直接行き、自分の目で見ることを求めるアドバイスです。 二人はラップトップを持ってニューヨークへ飛び、実際にAirbnbで物件を掲載しているホスト数十名を訪問しました。その観察から見えてきたのは、シンプルかつ見落とされていた問題でした。掲載されている写真の質が、壊滅的に低かったのです。 発見：共感フェーズが明かした根本原因 ホストたちは物件を善意で掲載していましたが、撮影は携帯電話や安価なデジカメで行われており、暗い室内、歪んだ構図、クリーニング前のベッドが写った写真が当たり前のように掲載されていました。 チェスキーとゲビアは「なぜ予約が入らないか」を問い続ける中で、ゲストの視点に立ちました。Airbnbのサイトを初めて訪れる旅行者が、見知らぬ人の家に泊まるかどうかを判断するとき、最大の信頼材料は「部屋の写真」です。その写真が「泊まりたい」と思わせないクオリティでは、予約は生まれません。これが根本原因でした。 5 Whys的に掘り下げると、「ホストが写真撮影のスキルを持っていない」さらに「プロの撮影機材を持つ理由がない」という構造的な問題も見えてきます。ホストを責めることができない問題でした。 解決策：小さく、すぐに試す チェスキーたちが取った行動は、技術的な解決策ではありませんでした。プロのカメラマンを雇い、ニューヨークのAirbnb物件を無料で撮影することにしたのです。 この解決策は「スケールしない」ものでした。カメラマンの手配、スケジューリング、編集——すべてが手作業で、プラットフォームとして自動化されていません。しかしポール・グレアムの言う「スケールしないことをやれ（Do Things That Don't Scale）」の原則通り、小さく試して効果を検証することを優先しました。 結果は明確でした。プロ撮影された物件のリスティングは、そうでない物件に比べて2〜3倍の予約率を達成しました。この検証から、Airbnbは「高品質な写真が予約の直接的な要因」という仮説を確信に変えました。 展開：検証から事業モデルへ ニューヨークでの実験が証明した仮説をもとに、Airbnbは「プロフォトグラフィープログラム」を正式サービスとして展開します。世界中のAirbnbホストに対して、無料または低コストでプロカメラマンによる撮影を提供する仕組みを作りました。 2012年には、このプログラムに参加した物件は参加していない物件と比べて予約率が40%以上高いというデータが得られ、写真品質がプラットフォームの成長エンジンであることが証明されました。 また、この経験はAirbnbのプロダクト哲学に深く刻まれました。「信頼のデザイン（Design for Trust）」というフレームワークがチーム内で共有され、ゲストとホストの相互信頼をどう設計するかが、デザイン判断の最重要基準となっています。 デザイン思考の観点からの分析 このケースが示すデザイン思考の本質は、「現場に行くこと」が発見の前提条件だったという点です。スプレッドシート分析では「予約率が低い」という症状しか見えませんでした。しかしユーザー（ホストとゲスト）のコンテキストに飛び込むことで、「写真」という具体的な根本原因が見えてきました。 共感フェーズの本質は、データを見ることではなく「ユーザーの文脈の中に身を置くこと」です。Airbnbの事例は、このフェーズを省略したり代替しようとしたりすることの危険性を示しています。 また解決策の選択も重要です。「写真AIで自動評価してNG品質の掲載を制限する」という技術的アプローチも考えられましたが、チームは「ホストに良い写真を提供する」というホスト中心のアプローチを選択しました。ユーザーを制限するのではなく、ユーザーが成功できる環境を作ることを優先したのです。 プロトタイプとしての「スケールしない解決策」 Airbnbの写真プログラムが教えるもうひとつの教訓は、最初のソリューションはプロトタイプであるべきという原則です。カメラマンの手動手配は「本番の解決策」ではなく、「仮説を検証するための実験」でした。 プロトタイプフェーズの目的は、完璧な解決策を作ることではなく、「この方向が正しいかどうか」を最小コストで学ぶことです。Airbnbは1週間の実験で、その後数年の事業戦略を決定する情報を得ました。 まとめ：小さな共感が生んだ大きな変化 Airbnbの写真プロジェクトは、デザイン思考の教科書的なケースです。問題を分析するのではなくユーザーに会いに行き、根本原因を特定し、スケールしない小さな実験でそれを検証し、機能することが分かってから拡張する。このプロセスを、資金が尽きかけたスタートアップが実行したという点に、実践的なリアリティがあります。 「ユーザーのいる場所に行く」という当たり前に聞こえるアクションが、実際にはどれだけ後回しにされているか。Airbnbのケースは、そのことを静かに問いかけてきます。 --- 参考文献 - Brian Chesky, "Do Things That Don't Scale", Y Combinator Blog, 2013（Paul Grahamへのインタビューより） - Leigh Gallagher, The Airbnb Story, Houghton Mifflin Harcourt, 2017 - First Round Review, "Airbnb's First Launch: Behind the Curtain", firstround.com, 2014 - Airbnb Design, "Designing Trust", airbnb.design, 2014 --- ### AIで拡張するデザイン思考 — 共感・定義・発想の各フェーズでAIを使う実践 URL: https://designthinking.studio/articles/design-thinking-ai-augmented/ > AIツールはデザイン思考を置き換えるのではなく、各フェーズの限界を突破するための増幅装置として使える。インタビュー分析から発散的思考まで、フェーズ別の具体的な活用法。 「AIがデザイン思考を自動化する」という論調があります。実際にやってみると、そうはなりません。 AIはデザイン思考を代替しない。人間が苦手とする部分の増幅装置として動く、というのが正確な表現です。インタビューデータの処理、パターン認識、発想の量的な拡大——時間と認知資源が食われる作業でAIは力を発揮します。一方で「ユーザーの目を見ながら話を聞く」「どのインサイトを選ぶか判断する」「なぜそのプロトタイプを作るか決める」——これは今のところ人間の仕事のままです。 共感フェーズ：インタビュー分析の加速 インタビュー文字起こしの処理 10名のユーザーインタビューを実施する。録音を文字起こしすると、合計で3万字を超えるテキストが生まれます。それを一人で読んで、重要な発言を拾い、パターンを見つける——一度やった人なら分かりますが、頭が溶ける作業です。 文字起こしテキストをLLMに入力し、「感情的な強度が高い発言を抜き出せ」「複数のインタビューに共通するテーマを見つけろ」という問いを立てると、数分で一次分類ができます。 実際にやってみると、面白いことが起きます。AIが抽出したパターンと、経験豊富なリサーチャーが手動で拾ったパターンが、微妙にずれます。AIは人間が「当たり前すぎて記録しない」発言を拾う。反対に「言葉の裏に何かある」という文脈的なニュアンスは拾いにくい。このズレ自体が議論のネタになります。「なぜAIはこれを拾ったのか」という問い自体が、チームの暗黙知を掘り起こすきっかけになるわけです。 ペルソナ生成の補助 インタビューデータからペルソナを作成するプロセスにもAIを組み込めます。インタビューメモをすべて入力し、「このデータから3つの異なるユーザータイプを抽出し、それぞれの目標・苦しみ・行動パターンを記述してください」と指示します。 ひとつだけ強調しておきたいのは、AIが生成したペルソナをそのまま使わないこと。AIは統計的に「もっともらしい」パターンを出しますが、実際のユーザーが持つ矛盾や非合理な行動を過度に整理してしまいます。現実の人間はもっと複雑で、矛盾だらけです。AIの出力はあくまで叩き台。リサーチャーが実際のインタビューデータと照合して直す前提で使ってください。 定義フェーズ：インサイトの深掘りと問いの精度向上 HMW質問の量的拡大 How Might We（HMW）質問の生成は、AIが特に得意とする領域です。1つのインサイトから10個のHMW質問を出すよう指示すると、人間が思いつかなかった角度の問いが含まれることがあります。 ワークショップでよく起こるのは、参加者が「これは非現実的だ」と判断して最初から排除してしまうHMW質問を、AIが臆せず生成するパターンです。「どうすれば採用プロセス全体を候補者がゲームのように楽しめるか」——人間なら「遊び感覚すぎる」と自己検閲するかもしれない問いが、AIから出てきます。この問いが結果として最も革新的なソリューションのシードになることがあります。 POVステートメントの検証 POVステートメント（「〜な（ユーザー）は〜が必要だ。なぜなら〜だから」）を作成した後、AIに「このPOVステートメントの弱点を指摘してください」「このPOVから生まれるHMW質問を10個出してください」と依頼することで、定義の精度を上げられます。 実際にやってみると、AIは「このPOVは『なぜなら』の部分が弱い——ユーザーが本当に動機とする理由がまだ表面的な記述に留まっています」という指摘を返すことがあります。これが定義フェーズの深掘りのきっかけになります。 発想フェーズ：発散の壁を突破する SCAMPER+AIで発想を強制拡張 SCAMPER（Substitute/Combine/Adapt/Modify/Put to other uses/Eliminate/Reverse）の各軸でAIに発想を依頼することで、チームの認知バイアスを超えたアイデアが生まれます。 「この問題に対して、既存の解決策を逆転させたらどうなるか（Reverse）を10案出してください」という問いに対して、AIは人間が「やらない理由」から先に考えて排除してしまうアイデアを列挙します。 ただし発想フェーズにおけるAIの最大の限界は、「ユーザーの感情を揺さぶるアイデア」を生成する能力です。データの組み合わせから生まれるアイデアと、ユーザーの涙を見た経験から生まれるアイデアは、根本的に違います。AIが発散の量を担当し、人間がユーザー文脈に基づいた収束を担当するという役割分担が現実的です。 アナロジー思考の補助 「この問題は、全く異なる業界でどう解決されているか」という問いをAIに投げることで、アナロジー思考を加速できます。 「採用プロセスの候補者体験の問題は、飲食業界では何に相当するか」という問いに対して、AIは「予約から来店・食事・会計・退店後のフォローアップという顧客ジャーニーの設計」という答えを返します。この視点から「採用プロセスをレストランの体験設計として再設計する」というフレームが生まれ、「予約時（応募時）の確認メール」「ウェイティングリスト（選考中の状況通知）」「メニューの可読性（採用ページの情報設計）」という具体的な対応関係が見えてきます。 プロトタイプ・テストフェーズ：AIを使った仮想テスト ユーザーテストのシミュレーション プロトタイプを実際のユーザーにテストする前の「事前チェック」としてAIを活用できます。プロトタイプの説明をAIに入力し、「このデザインの最大の使いにくさはどこか」「このフローで詰まりやすいのはどのステップか」という問いを立てることで、実際のユーザーテスト前に修正すべき明らかな問題を潰せます。 参加者からの声として多いのは、「AIによる事前チェックでは気づかなかった問題を、実際のユーザーテストで発見した」という体験です。これはAIのシミュレーションの限界を示すと同時に、「AIで潰せる問題を潰した上で実際のテストに臨む」という二段階アプローチの価値を示しています。 テスト結果の分析支援 ユーザーテストの観察メモをAIに入力し、「このテストから最も重要な5つの知見を抽出してください」「参加者の共通する詰まりポイントを分類してください」という依頼をすることで、分析作業を加速できます。 AIと協働するデザイン思考の倫理的考慮点 AIを共感フェーズで使うとき、ユーザーデータの扱いに特別な注意が必要です。インタビュー録音・文字起こし・個人が特定できる発言をそのまま商用LLMに入力することは、プライバシーリスクを伴います。 最低限やること：氏名・所属・固有の状況を匿名化してから入力する。社内での利用ならローカルLLMの活用も検討する。そしてユーザーへのインフォームドコンセントの説明文に、AI分析の可能性を入れておく。この3つです。 どこから始めるか まず1回だけやってみてください。 インタビューメモ（匿名化済み）をClaude/ChatGPTに貼り付けて、「感情的な強度が高い発言トップ10を抽出してください」と依頼する。AIが出した10件と、自分が手動で選んだ10件を並べる。このズレを議論する——それだけです。5分でできます。その議論の中に、「AIとどう分業するか」の感覚が生まれます。 --- 参考文献 - Tim Brown & Roger Martin, "Design for Action", Harvard Business Review, September 2015 - Ideo.org, "AI + Human-Centered Design: A Framework", ideo.com, 2023 - Teresa Torres, Continuous Discovery Habits, Product Talk LLC, 2021 - Nngroup.com, "AI-Augmented Research: When to Trust the Machine", nngroup.com, 2024 --- ### AI時代に逆行するマインドセット：スキルより先に「問う姿勢」を鍛える理由 URL: https://designthinking.studio/articles/ai-era-design-mindset/ > 生成AIがスライド作成も市場調査も代替し始めた今、コンサルファームや革新的な組織が「マインドセット」への投資を増やしている。デザイン思考が長年培ってきた「問いを立てる力」が、AI時代に最も価値を持つ理由を解説する。 生成AIが情報収集・基礎分析・資料作成を担い始めた職場で、ある逆説が起きている。スキルへの依存が高まるほど、スキルの価値が下がる。そしてスキルの最も有力な代替者（AI）が登場した今、「スキルより先にマインドを鍛える」という主張が、むしろ説得力を増している。 コンサルティング業界の一部では、若手育成の中心をフレームワーク習熟から「問いを立てる姿勢」へシフトさせる動きが出ている。これはデザイン思考が長年主張してきたことでもある。手法より先に、マインドがある。 AIが奪うのはスキルの「下積み」だ コンサルティング業界でよく語られる育成の理想形は「下積み型の徒弟制度」でした。若手がスライドを磨き、データを整理し、議事録を取る中で、思考の作法が染み込んでいく。 しかし生成AIの台頭がこの構造を変えつつあります。情報収集・基礎分析・初稿作成といった業務が急速に自動化され、若手が試行錯誤を通じてマインドセットを培う「下積みプロセス」が消えかけています。スキルは最初から高い品質でAIが提供できる。しかし、そのスキルをどこに、なぜ、いつ使うかを判断する能力は、AIが代替できない領域に残っています。 あるコンサルティングファームのマネージングパートナーはこう表現します。「コンサルタントの本質的な役割は『戦いの勝ち方を伝えること』だ。大規模言語モデルの仕組みを理解したうえで、この技術が業界と仕事をどう変えるかというシナリオを複数持てるプレーヤーが、これからの時代に強くなる」。 スキルを持つことと、スキルを文脈の中で使うことは、別の能力です。そして後者は、「問いを立てるマインドセット」なしには機能しません。 デザイン思考が「マインドファースト」を主張し続けた理由 d.schoolのカリキュラムは、ツールや手法の前に「マインドセット」を扱う。IDEOのデザイン思考のフレームワークも、5つのフェーズ（共感・定義・発想・プロトタイプ・テスト）の前提として、以下のマインドセットを明示している。 「人間中心であること」「あいまいさへの耐性」「楽観的バイアス」「反復的な実験への傾倒」「コラボレーション重視」。 これらはスキルではない。ツールとして習得できるものでもない。状況に対してどう向き合うかという姿勢であり、繰り返しの実践の中で形成されるものだ。 なぜd.schoolがこれほどマインドセットにこだわるのか。それは、正しいマインドを持った人間は手法を自ら再発明できるが、手法だけを持つ人間はマインドのない手法の奴隷になるからだ。ワークショップでよく起こるのは、ポストイットを貼ってHMW（How Might We）を書いても、問いそのものがずれているというケースです。手法は正しく使われていても、そもそも「何のための問いか」が抜けている。 マインドセットの問題です。ツールの問題ではありません。 「問いを立てる力」がAI時代の不変の競争優位になる AIが高精度で答えを生成できる今、最も価値を持つのは「正しい問いを立てること」だ。誤った問いへの完璧な答えは、正しい問いへの不完全な答えより危険だ。 デザイン思考の定義フェーズ（Define）はまさにこれを扱う。ユーザーリサーチで集めたデータから「何を問題と定義するか」を決めるプロセスは、分析的能力ではなく判断力の問題だ。「問題を正しく定義できれば、解決策の半分は手に入る」という原則は、AIの登場によって重要度が増している。 実際にやってみると、この違いは明確に現れます。生産ラインの不具合データをAIに解析させ、複数の改善案を得たある製造業のDX推進チームがいました。しかしチームが「そもそもなぜ不具合が増えているのか」という問いを立て直したところ、問題の根本が「設備の老朽化」ではなく「熟練作業者の退職による暗黙知の喪失」であることが見えてきました。AIは与えられたデータの中から答えを生成しましたが、「正しいデータを問うこと」自体はチームのマインドセットが担っていた。 コンサルファームが「マインド育成」に時間を割く理由 少人数精鋭体制を採るコンサルティングファームの一部では、全業務時間の30%程度を育成・メンタリングに割いているケースがある。大量採用・大量育成モデルと対極に位置するこのアプローチは、「スキルはAIで補える、しかしマインドは補えない」という判断から来ている。 その育成の中心にあるのは、月次ワークショップや公開メンタリングを通じた「自責の範囲の適切な設定」と「問い方のトレーニング」だ。「自責思考は成長に有効だが、因果関係を正しく捉えられなくなる危険もある。自責は自分がコントロール可能な範囲に限定することが前提」という考え方がベースにある。 これはデザイン思考の「楽観的バイアス」とも共鳴する。何でもコントロールしようとする過剰な自責でも、何も変えられないという諦めでもなく、「自分が変えられる範囲を正確に見極め、そこに集中する」という態度だ。 マインドセットは「状況への応答パターン」として蓄積する マインドセットは抽象的に聞こえるが、実際には具体的な行動パターンとして現れる。デザイン思考の文脈では、以下のような「応答パターン」として観察できる。 「わからない」を入口にできるか。専門家として「知っている」姿勢でユーザーに向き合うか、「教えてもらう」姿勢で向き合うか。後者が共感フェーズを豊かにする。 「失敗」を情報に変えられるか。プロトタイプのテストで想定外の結果が出たとき、「実験の失敗」と見るか「学習の成功」と見るか。この違いは、小さいようで大きい。 「問い」を仮説として持ち歩けるか。解決策を探す前に「私たちは本当に正しい問題を解こうとしているか」を問い返す。それだけで、的外れな3ヶ月が消える。 これらのパターンは、意識して繰り返すことで習慣化する。ワークショップで一度体験しただけでは身につかないが、毎回のプロジェクトで意図的に実践することで、やがて自動的な応答になる。 AIとデザイン思考は補完関係にある デザイン思考はAIを排除しない。むしろAIを「発散・収束の加速ツール」として使うことで、デザイン思考のプロセスは強化される。 共感フェーズのインタビュー音声をAIで文字起こし・カテゴライズする。定義フェーズでのHMW生成をAIとのブレインストーミングで拡張する。プロトタイプフェーズでの低忠実度モックをAIで高速生成する。これらはすでに実践されている活用法だ。 しかし、AIが提案したHMWのうちどれが真に重要な問いかを判断するのは人間のマインドだ。AIが生成したプロトタイプのうちどれをユーザーに当てるかを選ぶのも、共感フェーズで培った人間理解だ。 AI時代に価値が増すのは、AIが得意とする「答えの生成」ではなく、AIが苦手とする「問いの選択」と「文脈の読み取り」だ。そしてこれらは、デザイン思考のマインドセットが長年扱ってきた能力でもある。 やってみよう：「問い直し」の15分ルーティン チームで試せる即日実践として、「問い直しの15分」を紹介する。プロジェクトのスタート時、または行き詰まりを感じた時点で実施する。 ホワイトボードまたは付箋に「現在解こうとしている問題」を一文で書く。次に全員が付箋を使って「その問題の前提に疑問を呈する問い」を書く。たとえば「売上を増やす方法」という問題設定に対して、「売上を増やすことが本当のゴールか」「なぜ今売上が落ちているのか、本当の理由は何か」「売上以外の成功指標はないか」などを書き出す。 15分後、最も根本的に問題を問い直している付箋を全員で選ぶ。この「選ぶ」行為自体が、チームのマインドセットを鍛えるトレーニングになる。 このルーティンに慣れたチームは、解決策に飛びつく前に「そもそも何を解くのか」を確認する文化を持つようになる。それがデザイン思考の「定義フェーズ」の文化的定着を意味する。 特にこんな人に試してほしい - 生成AIを使いこなしているが、どこか「ツールに引きずられている感覚」がある - デザイン思考の手法（ポストイット・ペルソナ・ジャーニーマップ）は使っているが、チームの問い方が変わっていない - メンバー育成で「スキルを教えたはずなのに判断力が育っていない」と感じている - 新しいプロジェクトが始まるたびに、前回と似た失敗を繰り返している マインドセットの変革は、ワークショップ一回では完成しない。正しい方向に向けて小さく繰り返す——それ自体が、デザイン思考の反復実験の哲学と同じだ。 スキルは更新される。AIが出てきた、次のAIが出てくる、またスキルが変わる。しかし「問いを立てる姿勢」だけは、何が来ても陳腐化しない。それがデザイン思考が25年かけて言い続けてきたことで、AI時代になってようやく証明されつつある。 --- 機械学習が本装備となった2026年のデザイン思考実践において、設計者がAIと分業する具体的な方法については、AI時代のデザイン思考——機械学習との融合が設計者の役割を書き換えるで詳述している。 --- 参考 - Tim Brown, Change by Design, HarperBusiness, 2009 - d.school, "Design Thinking Bootleg", Stanford d.school, 2018 - IDEO, "Design Thinking: A Manual for Innovation", IDEO, 2015 - David Kelley & Tom Kelley, Creative Confidence, Crown Business, 2013 - Carol Dweck, Mindset: The New Psychology of Success, Random House, 2006 --- ### AI時代に人間の創造性はどこへ向かうのか——デザイン思考が問い直す「考えること」の本質 URL: https://designthinking.studio/articles/design-thinking-ai-era-human-creativity/ > 生成AIが普及した今、デザイン思考における人間固有の創造性とは何か。Bodenの3類型、Crossの暗黙知、Csikszentmihalyiのフロー理論を軸に、AIが代替できない創造的思考の核心を探る。 生成AIが日常ツールに変わった今、デザイン思考の現場でひとつの問いが静かに広がっている。「自分たちは、何のために考えているのか」。 アイデアの発散ならAIが秒単位でやってのける。ユーザーインタビューの文字起こしと要約も、今や数クリックで済む。プロトタイプのビジュアル化だって、プロンプト一行で叩き台が出てくる。では人間のデザイナーは、このプロセスのどこに立つべきなのか——そう問われると、明確に答えられる人は思ったより少ない。 この問いに答えるには、まず創造性の構造そのものを問い直すところから始まる。 --- AIが「模倣できる創造性」と「模倣できない創造性」 認知科学者のマーガレット・ボーデン（Margaret Boden）は、創造性を3つの類型に分けて論じた。組合せ型（combinational）、探索型（exploratory）、変換型（transformational）だ。 組合せ型は、既知のアイデアを新しい方法で結びつける。探索型は、既存の概念空間の境界をなぞりながらその外縁を広げる。変換型は、概念空間の構造そのものを変え、それ以前には存在しなかった思考の枠組みを生み出す。 現在の生成AIは最初の2類型においては目を見張る成果を出す。学習済みのパターンから組合せを生成し、概念空間の探索において人間を凌駕するスピードで候補を列挙できる。しかしボーデンが「変換型」と呼んだ、概念空間そのものをひっくり返す創造性については、根本的な問題が残ると指摘した。AIには「必要性（need）」がない。何かが切実に「まずい」と感じる主体性がなければ、既存の枠を崩す動機も生まれない——そういう意味で、AIの創造性は本質的に応答的（responsive）なのだ。 デザイン思考が扱う問題の多くは、そもそも変換型の思考を要求する。ウィキッドプロブレム（wicked problems）への応用に代表されるように、解くべき問題の定義自体が解を求める行為と不可分に絡み合っているからだ。 --- 「設計的な知り方」という暗黙知 Open University のナイジェル・クロス（Nigel Cross）は1982年、デザインには固有の認識論——「designerly ways of knowing（設計的な知り方）」——があると論じた。 科学的思考が「あるものをそのまま記述する（how things are）」のに対し、デザイン的思考は「あるべき姿を構想する（how things might be）」という方向性を持つ。この構想は、抽象的な理論から演繹されるのではなく、素材・形・文脈・身体との対話の中で生まれる。クロスが強調したのは、この知識の多くが暗黙知（tacit knowledge）の形を取るということだ。 暗黙知は、言語化も数値化もしにくい。熟練した職人が「このやり方ではうまくいかない」と直感的に知る、あの感覚に近い。デザイナーがプロトタイプを手にしたとき、触覚・視覚・文脈への感受性が一体となって「これは使えない」という判断に至る過程は、学習データから確率を算出するプロセスとは構造的に異なる。 AIはトークンを予測するが、デザイナーは状況を感じ取る。この差は小さくない。 アブダクティブ推論とデザイン思考の関係にも同様のことが言える。仮説を「飛躍させる」跳躍は、データの統計的処理では導けない。観察した現象がなぜか「引っかかる」という感覚——それが仮説生成の出発点になる。 --- フロー状態と創造の瞬間 心理学者のミハイ・チクセントミハイ（Mihaly Csikszentmihalyi）が「フロー（flow）」と名付けた状態がある。課題の難度と自分のスキルが高い水準でぴったり合ったとき、人は全集中の没入状態に入る。時間の感覚が薄れ、自意識が消え、行為そのものが目的になる瞬間だ。 チクセントミハイは創造性の研究においても、フロー状態が創造的飛躍の温床になると論じた。芸術家、科学者、建築家——領域を問わず、最も革新的な成果が生まれた瞬間は、しばしばこのフロー状態と重なっていた。 デザイン思考のセッションでは、このフロー状態を意図的に誘発するための設計が求められる。ワークショップの現場でよく見られるのは、時間制約を設けた瞬間にチームの対話が急に密になり、言語化できていなかったアイデアが紙の上に現れるという現象だ。アイデエーション（ideation）フェーズでの道具立て——タイムプレッシャー、空間の構造、チームの多様性——は、フロー状態へのインターフェース設計でもある。 ここで注目すべきは、AIがフロー状態の「代理」にはなれないという点だ。AIはアイデアを「出力」するが、フロー状態で起きているのは、人間が自分の思考の深部と出会う体験だ。デザイナーが紙にスケッチしながら、描く行為の中で考えを発見していく——その往復は、外部ツールに委ねることができない認知の核心だ。 --- IDEO CEOが語った「AIが出すのは平均点」 2025年末、IDEOのCEOであるマイク・ペン（Mike Peng）はFortune Brainstorm Designの場でこう述べた。AIのパターン認識は強力な道具だが、平均値への依存が「やや平凡な（somewhat mediocre）」結果をもたらす、と。「創造性とは平凡でなく、限界を突破することだ」——その一文は、設計的思考の核心をついている。 IDEOは40年以上にわたって人間中心設計を実践してきた組織だ。AIをデザインプロセスに組み込む実験も続けている。ペンの指摘が示すのは、AIが強い領域（反復・列挙・最適化）と、人間が手放せない領域（どこに適用するか、何を選ぶか）の非対称な関係だ。 ユーザーの表情に微妙な緊張を読み取る力、相手の言葉の裏にある感情を感じ取る力——インタビューの現場では、録音を後から聞き返すと見落としていた沈黙や語気の変化に気づくことがある。その「聞き返して初めて分かる」という事実自体が、リアルタイムの感受性の重みを物語っている。共感（empathize）フェーズの核心は、データ処理ではなく「人間が人間に向き合うこと」にある。デザイン思考とマーケットリサーチの違いを論じた文脈でも繰り返し指摘されているように、ユーザー調査における質的な感受性は数値に還元できない。 --- 「使う道具」から「問いの設計者」へ ハーバート・サイモン（Herbert Simon）は1969年の『人工物の科学（The Sciences of the Artificial）』で、設計を「現状を好ましい状況へ変換する行為」と定義した。この定義が今も有効なのは、「好ましい」の判断が主体を必要とするからだ。 AIは「より良い状態」を計算できるかもしれない。しかし「何が本当に良いのか」という問いは、価値観の問いであり、文化の問いであり、政治の問いだ。それは最適化問題には還元できない。 デザイン思考が担うのは、まさにこの問いの設計だ。認知バイアスとデザイン思考を論じた文脈では、人間の判断の歪みを前提とした上で、より良い問いの立て方を探る。インサイトの統合と合成の実践も、データを見て「何かがある」と感じる眼——観察と意味付けの往復——なしには成立しない。 AI時代に人間のデザイナーに求められる役割は、アイデアを「生む機械」ではなく、問いを「設計する存在」へとシフトしている。何を問うべきかを決め、誰の声を聴くべきかを選び、どの解が「正しい」かを判断する——その三つの問いに、人間の経験と価値観が織り込まれている。 --- 創造性の核心は「奪われない」 AIが創造的なツールとして普及することで、デザイナーに課される問いの水準は上がる。「アイデアを出す」ことが当たり前になれば、「どのアイデアを選び、なぜそれを選ぶのか」という判断こそが価値の中心になる。 ボーデンが「変換型の創造性」と呼んだ、世界の見え方を変える力。クロスが「暗黙知」と呼んだ、言語化を超えた設計的感受性。チクセントミハイが「フロー」と呼んだ、思考の深部で起きる出会い。そしてサイモンが「何が好ましいか」という問いに込めた、主体の不可欠性。 これらは今のところ、AIには代替されていない。だからこそ、デザイン思考の実践者に突きつけられている問いは「AIに何をやらせるか」ではなく、「自分は何を引き受けるか」だ。 --- 参考文献 - Boden, M. A. (1990). The Creative Mind: Myths and Mechanisms. Basic Books. - Cross, N. (1982). Designerly Ways of Knowing. Design Studies, 3(4), 221–227. - Csikszentmihalyi, M. (1996). Creativity: Flow and the Psychology of Discovery and Invention. HarperCollins. - Simon, H. A. (1969). The Sciences of the Artificial. MIT Press. - Peng, M. (2025, December 9). AI gives mediocre results. Here's what human creativity can do. Fortune. https://fortune.com/2025/12/09/ai-mediocre-results-human-creativity-ideo-ceo-mike-peng - IDEO U. (2024). The Intersection of Design Thinking and AI. https://www.ideou.com/blogs/inspiration/ai-and-design-thinking --- ### AI時代のデザイン思考——機械学習との融合が設計者の役割を書き換える URL: https://designthinking.studio/articles/ai-era-design-thinking-machine-fusion/ > 2026年、AIが実験的なツールから本装備へと移行する中で、デザイン思考の5フェーズはどう変わるのか。共感フェーズのAI拡張から、キュレーターとしての設計者像まで、実践の変容を解剖する。 2016年にd.schoolが公開した「Design Thinking Bootleg」の改訂版が2023年にリリースされたとき、AIへの言及は限定的だった。しかし2026年現在、機械学習は実験的なサイドツールを脱し、デザイン思考の5フェーズそれぞれに組み込まれる本装備となっている。 問題は「AIを使うかどうか」ではなくなった。「AIが担う部分と、人間が担うべき部分をどう設計するか」が、デザイン思考を実践する者に問われる核心的な判断になっている。 この変化は、設計者を脅かすものではない。ただし、これまでの役割の一部を手放さない限り、新しい価値は生まれない。 AIが変えた「共感フェーズ」の解像度 デザイン思考の共感フェーズは、ユーザーの行動・感情・文脈を深く理解することを目的とする。従来はインタビュー、観察、日記調査が主たる手法だった。これらは今も不可欠だが、AIが合流することで情報の処理規模と速度が根本的に変わった。 例えば、カスタマーサービスの会話ログ、SNSのクチコミ、サポートチケットのテキストは、従来は「多すぎて読めない」情報だった。NLP（自然言語処理）を用いた感情分析とトピッククラスタリングを組み合わせると、数万件のデータから「どの場面でユーザーが感情的に負荷を感じているか」のパターンが数時間で可視化できる。 ワークショップでよく起こるのは、このAI出力を「答え」として扱ってしまうことだ。AIが抽出したパターンは「どこを見るか」の地図であり、「なぜそうなっているか」の答えではない。 感情分析で「解約申請フローで負の感情が高い」と出た場合、そこへの現場インタビューをAI分析が代替するのではなく、インタビューの設計を精度よく行うための前情報として機能する。 IDEOの公開資料でも、AIは共感の代替にはなれないが、より深い共感ができる場所を特定する助けになるという観点が示されている。 問題定義フェーズ：インサイトの生成速度が上がった代償 共感フェーズで収集したデータをインサイトに変換する問題定義フェーズにも、AIは深く組み込まれた。大量のインタビュー記録を自動文字起こしし、テーマ別にクラスタリングし、矛盾するユーザーの声を対置させるまでの作業を、AIは数十分で処理する。 これは確かに効率化だ。しかし参加者からの声として繰り返し上がるのは、「速くなったが、驚きが減った」という感覚だ。 アフィニティダイアグラムを手作業で行う時間の中には、チームメンバーが「なぜこのユーザーはこう言ったのか」を反芻しながら付箋を動かす思考の時間が組み込まれていた。 AIがその作業を代替すると、処理は速くなるが、チームがインサイトを「自分ごと」として内面化する時間が消える。 実践的な解決策として、IDEOのいくつかのチームが採用しているのは「AIファースト、人間ラストの問題定義」だ。まずAIが自動クラスタリングしたインサイト候補を全員で閲覧し、その後「AIが見落としていると思うものは何か」「AIが過大評価していると思うものは何か」という問いでセッションを設計する。AIの出力を批判的に読む行為が、かえってチームの問題定義への関与を深める効果がある。 創造フェーズ：設計者の役割がキュレーターへシフトする 機械学習との融合が最も劇的な変化をもたらしているのが、創造フェーズだ。 生成AIは問いを与えると数百のアイデアを数分で出力できる。「How Might We: どうすれば高齢者が薬の飲み忘れを防げるか」という問いに対して、GPT-4oやClaudeが100件のアイデアを出力するまで5分もかからない。 この状況が設計者に突きつける問いは、「良いアイデアを出すこと」から「大量のアイデアの中から有望なものを見抜くこと」への移行だ。IDEO Uが2025年のカリキュラムで強調したのは、まさにこの「キュレーション能力」だった。 キュレーターとしての設計者に求められるスキルは3つある。 - 文脈適合性の判断: AIが出力したアイデアが「技術的には成立する」としても、ターゲットユーザーの文化的・感情的文脈に合うかどうかを判断できるのは、共感フェーズで現場に入った人間だけだ。 - 選別基準の言語化: 「これはいい」「これはいまいち」という直感を、チームで共有可能な言語に変換する能力。「なぜこれが有望か」を説明できない選別は、次のイテレーションで機能しない。 - AIへの問いを鋭くする能力（プロンプトエンジニアリング）: 「アイデアを出して」より「○○という文脈において、△△という制約の中で、□□という感情的問題を解決するアイデアを出して」という形式で問うほど、AIの出力品質は上がる。これはプログラミングではなく、デザイン思考の問題定義能力そのものだ。 プロトタイプフェーズ：物理→デジタルの壁が消えた プロトタイプフェーズにAIが持ち込んだ最大の変化は、「低忠実度から高忠実度への距離が縮まった」ことだ。 従来、紙プロトタイプからインタラクティブなプロトタイプに進むには、デザインツールのスキルと相当な時間が必要だった。現在、自然言語でUIを記述するとFigmaの操作可能プロトタイプを自動生成するツールが実用段階にある。「ユーザーがボタンを押すと確認ダイアログが出て、OKを押すと次の画面に遷移する」と書けば、プロトタイプが数分で完成する。 これは設計者の創造性を代替するのではなく、「試す回数」を増やすことを可能にする。 プロトタイプの目的は思考の検証だ。検証の回数が増えれば、発見の密度が上がる。 ただし速さには落とし穴もある。低品質のプロトタイプをユーザーに見せると、フィードバックが「このデザインの良し悪し」ではなく「未完成感への不快感」に向かう。AIで生成したプロトタイプは「動く」が「磨かれていない」状態であることが多く、ファシリテーターがユーザーに「これは実験中のアイデアです」と文脈設定する技術が今まで以上に重要になった。 テストフェーズ：データの量より、問いの質 テストフェーズでのAI活用は、主に2つの方向がある。 分析の自動化: ユーザーテストの録画からアイトラッキングデータ・発話内容・操作ログを統合分析するツールが、2025年以降実用レベルに達した。従来1人のリサーチャーが3〜5日かけていた分析が、数時間で完了する。 自動合成ユーザーによる先行テスト: リクルーティング前に「シミュレーテッドユーザー」（AIが特定のペルソナを模倣したインタビュー相手）を使って問いの検証をする手法も広まった。これは実際のユーザーリサーチの代替ではなく、インタビューガイドの質を上げるための「練習相手」として機能する。 現場で繰り返し報告されるのは、「AIで分析を速くしたら、チームがテスト結果を読まなくなった」という問題だ。ダッシュボードで自動サマリーが出ると、「チームが生のデータを読む」行為が消える。生のユーザーの言葉・表情・迷いに触れることが、次の問いを生む。自動化がその接触を断ち切るとき、デザイン思考のサイクルが形骸化する。 設計者に求められる新しいスキルセット 2026年時点で、デザイン思考実践者に求められるスキルは3層に整理できる。 変わらないスキル（人間固有）: - ユーザーの文脈への共感能力（現場に入る、感情に触れる） - 倫理的判断と価値観の設計（何を優先するかを決める） - チームのファシリテーションと合意形成 - 「なぜ」を問い続ける批判的思考 AIとの協働で拡張されるスキル: - データパターンの解釈と文脈付け - アイデアのキュレーションと優先順位付け - プロトタイプの高速イテレーション 新たに必要なスキル: - プロンプトエンジニアリング（AIへの問いの設計） - ML出力の批判的読み（バイアスの検出） - AI-Humanのプロセス設計（どこを機械に任せ、どこを人間が担うかの設計） IDEO Uが2025年のカリキュラムで「AI Literacy for Designers」を新設したのは、この変化への明確な応答だ。AIを怖れる必要はないが、AIを素朴に信頼することも危険だ、というのがIDEO Uの立場だ。 やってみよう：AI融合デザイン思考の最初の一歩 AIを「ワークショップの参加者」として扱う実験から始めるとよい。 次のアイデエーションセッションで、人間の参加者がアイデアを出した後、同じHow Might Weの問いを生成AIに投げてみる。人間が出したアイデアとAIが出したアイデアを並べ、「AIが見落としているものは何か」「AIが先に気づいていたものは何か」という問いでチームを動かす。 この設計の良さは、AIを「答えを出す機械」として扱わず、「比較の対象」として扱う点にある。人間の思考の癖とAIの出力パターンの差が、チームの創造性の盲点を可視化する。 また、共感フェーズのインタビュー準備として、生成AIに「このペルソナが感じる最大の不満は何か」を問い、AIの回答を叩き台にしてインタビューガイドを作るのも有効だ。AIの回答を「正解の仮説」ではなく「棄却すべき仮説」として設計することが、インタビューの問いを鋭くする。 特にこんな方へ デザイン思考のファシリテーターで「AIをどうワークショップに組み込むか分からない」という人、UXデザイナーで「AIツールを使っているが設計の質が上がっている実感がない」という人に、この記事の視点が直接役立つ。 AIは設計者を置き換えない。しかしAIを使う設計者が、使わない設計者を置き換える——この命題は2026年において、もはや仮説ではなくなっている。問題は使うかどうかではなく、どう使うかだ。その「どう」を考える起点として、デザイン思考の5フェーズは今もっとも強力なフレームワークであり続けている。 --- ### AI時代のデザイン思考──人間とAIの協働で、新しい創造が生まれる URL: https://designthinking.studio/articles/design-thinking-ai-human-collaboration/ > 生成AIが当たり前になった今、デザイン思考は『対話相手』をAIに変える。3つの実践ケースから、人間がempathizeして、AIがideateを支援し、人間がその先の創造を担う──新しい分業の形を解き明かします。 デザイン思考は、本来「人間とのやり取り」を前提に生まれた手法です。 ユーザーとの対話（empathize）、チーム内での議論（define）、集団での発散と収束（ideate）。全てが「人間関係の質」に左右されていました。 しかし今、その前提が変わろうとしています。 2024年から2026年にかけて、私は複数のクライアント企業で「AIをデザイン思考のプロセスに組み込む」実験を重ねてきました。結論は単純です。AIは人間のデザイン思考を「弱める」のではなく、「新しい段階へ進める」ための触媒になり得る、ということです。 AIはどこに入るのか 従来のデザイン思考：人間 → empathize → 人間 → define → 人間 → ideate → 人間 → prototype → 人間 → test 新しいデザイン思考：人間 → empathize → 人間 AI ↔ 人間 → ideate(新形式) → AI × 人間 → prototype → 人間 → test ポイントは、AIが「全段階に入る」わけではなく、特に define から ideate にかけて、AIが『思考のスパーリングパートナー』になるという点です。 実務的には、こう動きます。 - empathize フェーズは『人間にしかできない』。 ユーザーインタビュー、観察、共感 ── AIは参考データを提供する程度。 - define フェーズで、AIが『問題の言語化』を支援。 人間の漠然とした洞察をAIに投げ、複数の視点で問題を再定義する対話。 - ideate フェーズで、AIが『発散の加速』を担う。 人間が1時間で10案考えるなら、AIは100案を数秒で提示。その中から「人間にしか選べない質的判断」を人間が下す。 - prototype 以降は、再び『人間主導』へ。 低忠実度プロトから、ユーザーテストまで、人間の創意と観察力が決定的。 実践ケース1：BtoB SaaS企業の機能定義ワークショップ 昨年6月、ある SaaS 企業で「新しい料金体系の設計」を支援しました。CEO、営業、プロダクトマネージャー計5名が参加。所要時間は2日間。 初日：empathize → define（従来型） 初日は、既存顧客10社のインタビュー記録（テキスト化済み）を皆で読み込み、「顧客は何に困ってるのか」を付箋で整理していく。AIは一切使いません。ここは人間の共感力が要。 午後、その10社の顧客背景をまとめたら、ここからAIが登場します。 2日目：define ↔ AI ↔ ideate（新型） 私は、初日に出た「顧客の困り」を ChatGPT-4 に投げ、こう指示しました。 「この10社の顧客背景と困りを見たとき、この企業の『料金体系の問題』は、本当は何か。5つの異なる視点から、問題を再定義してほしい。」 出てきた5つの再定義： - 「従量課金 vs 定額課金」という二項対立が、実は『顧客の成長段階による必要価値の変化』を隠している」 - 「顧客は『安さ』ではなく『予測可能性』を求めており、現在の価格設定では将来コストが見通せない」 - 「業界別ニーズが異なるのに、全顧客に同じ体系を提供しており、『違う顧客には違う価値メカニズムが必要』という洞察が欠けている」 - 「実装コストを『顧客の問題』に見立てているが、実は『ベンダーの実装スキルのばらつき』が本当の問題」 - 「顧客は『ROI』で購買判断するのに、料金体系は『スピード』や『手間』で設計されている。軸が違う」 参加者全員が沈黙。その後、CEO が発言。 「5番目。これだ。ウチらが『安い、シンプル』を売りにしてたけど、本当は顧客が『このツール導入して、ウチの売上いくら増えるんだっけ』って判断基準なんだ。」 AIが問題を『再フレーミング』したことで、従来のdefine議論を一段上に引き上げた。それが、その後の ideate の質を激変させました。 従来なら「定額○円 vs 従量課金△円」という選択肢の中で議論してたはずです。でもAIの5つの視点を経由することで、「そもそも顧客は ROI で判断してるんじゃ？」という本当の問題へ到達した。 その後の ideate では、単なる「価格設定」ではなく、「顧客の売上増加をトラッキングする仕組み」「業種別のテンプレート料金」といった、全く別次元の提案が出ました。 AIは『新しい問い』を投げ掛けることで、人間の創造性を解き放つ触媒になったのです。 実践ケース2：出版社の編集会議での企画提案 2025年初め、ある出版社の編集チーム（編集長、編集者3名）が「次のベストセラー候補」を探すワークショップをしました。私が facilitator として入ったのは、この企業が「AI + 人間判断」のハイブリッド企画開発を試みたかったから。 プロセス： - 過去3年の売上トップ20冊のメタデータ（ジャンル、帯のコピー、著者背景、発行部数）を集計。 - これを Claude に渡し、「共通する『売れる企画の DNA』を5つ抽出」と指示。 AI の抽出： - 「『普通の人が、意外と簡単に出来る』という低い参入障壁」 - 「『今の生活で困ってることへの即時的な解決策』」 - 「『自分の人生が180度変わった感』という narrativeの強さ」 - 「『5年以内の新しいトレンド』に乗った cutting edge 感」 - 「『著者本人が、その道の実務者である』ことの信頼性」 その後、編集長が提示した3つの候補企画に対し、AI に「この5つの DNA でスコア付けしてくれ」と要求。 結果： - 候補A（運動習慣本）: 4/5点 → 「DNA 3（narrative）が弱い」 - 候補B（AI副業術）: 5/5点 → 「5つ全て合致」 - 候補C（シニア起業本）: 3/5点 → 「DNA 4（トレンド感）が時代遅れ」 編集長の直感では「候補A と C」だったとのこと。ですが、AI のスコアリングと理由を見ることで、「あ、候補B の方が、マーケット的には成功確度が高い」という判断に変わりました。 ここでも、AIが『人間の選択を、データ駆動の観点から検証』する役割を果たした。 人間の創意と直感が全てではなく、市場のパターンと照らし合わせることで、『直感を自信に変える』ツール として AIが機能していたのです。 実践ケース3：製造業の新商品開発プロジェクト 最後のケースは、私が最も「AIの限界」を感じた案件でもあります。 製造業A社が「新しい素材を活かした B2C 商品」を企画する際、AI に「この素材で、どんな商品が考えられるか」と 100 パターンのアイデアを生成させました。 その 100 案は、技術的には正しい。しかし、実務上のマニュファクタリング・コストや、流通の現実を全く無視していた。 例：「マグネシア樹脂で作る『超軽量ゴルフ用ロボット鳥型カメラ』」← 中国の OEM ですら コスト合わない。 ここで気づいたのは、AI の ideate は『自由度』には優れているが、『実現可能性の制約』を本当には理解していないということ。 その後、私は プロセスを調整しました。 - AI に「制約条件」を明確に与える。 「製造可能な範囲は、既存工程 3 ステップ以内」「BOM（部品表）コストは ¥X 以下」「流通在庫期間は 90 日」等。 - その制約下での ideate を AI にやらせる。 - 出てきた案を、人間の製造部門と営業が『実現性』で判定。 - 実現可能な案に対してのみ、人間が『どう磨くか』という qualitative improvement を加える。 つまり、AI は『発散の勢い』を提供するが、『制約下での実行可能性』は人間が保証する という分業です。 新しい創造の形 AI 時代の デザイン思考は、こう定義し直せます。 「人間が『本当の問題』を感じ取り、AI が『それを複数の角度から再定義』し、人間が『その中から創造的な選択』をし、最後に人間が『実現可能なカタチに磨く』。」 従来のデザイン思考の 5 フェーズを活かしながら、define と ideate の間に『AI との対話』を挿入するという、小さく、でも本質的な変化です。 重要なのは、AI に「代わってもらう」のではなく、『対話相手としての AI』を使い こなすことです。 その先には、今までに無い速度で、でも見落としも減った状態で、新しい価値を生み出していくデザイン思考の形があります。 手を動かしながら、その感覚を掴んでいく。それが、今を生きるデザイン思考者に求められていることなのです。 --- カテゴリ: practice（実践） 関連記事: - AI 時代のプロトタイピング - define フェーズの本質──『本当の問題』を見つけるまで --- ### AI時代のデザイン思考ツール URL: https://designthinking.studio/articles/design-thinking-ai-tools/ > AIツールがデザイン思考の5つのフェーズをどう加速するか。共感フェーズのインタビュー分析からプロトタイピングの自動生成まで、実務で使えるAI×デザイン思考の組み合わせを解説する。 デザイン思考のワークショップで「AIを使えば、もっと速くできるのでは？」という声が増えている。答えはイエスでありノーだ。 AIは思考の代替にはならないが、思考の材料を集め、整理し、形にする速度を劇的に上げる 。各フェーズでどう使い分けるかが鍵になる。デザイン思考の5フェーズそれぞれでの活用法を見ていく。 前提——AIが得意なこと、苦手なこと まず切り分けておくべきことがある。AIが得意なのは 大量の情報の処理・パターン認識・素案の高速生成 だ。一方、苦手なのは「人間の感情を肌で感じること」「文脈を踏まえた判断」「まだ誰も言語化していないインサイトの発見」である。 デザイン思考の本質は、人間の複雑な課題に人間として向き合うプロセスにある。AIは優秀な「手足」であって「頭脳」ではない。この前提を持ったうえで、各フェーズの活用法を見ていく。 共感フェーズ——インタビュー分析を加速する 書き起こしと要約 ユーザーインタビューの最大のボトルネックは、録音を聞き返して分析する時間だ。60分のインタビューを精読するのに3〜4時間かかることも珍しくない。 AIの文字起こしツール（Otter.ai、Whisperベースのツール等）を使えば、 インタビュー直後に全文テキストが手に入る 。そこからLLMに要約と感情分析を依頼すれば、発言の中で特に感情が動いた箇所、繰り返し出てくるテーマ、矛盾する発言をハイライトできる。 落とし穴 ただし、AIの要約を「インサイト」と混同してはならない。実際にやってみると分かるが、AIが拾うのは「頻出キーワード」であって「行間に隠れた本音」ではない。要約はあくまで下処理。 そこから何を読み取るかは、人間がインタビューの場にいた者にしかできない 。 ユーザーインタビューの手法そのものをAIに任せるのは危険だ。「聞く」という行為の中で生まれる非言語情報——表情、間、声のトーン——こそが共感の核になる。 定義フェーズ——データのクラスタリングを効率化する AIによるアフィニティ・ダイアグラム アフィニティ・ダイアグラムは、付箋に書いた観察メモをグルーピングして構造を見出す手法だ。100枚以上の付箋を分類するのに、熟練のファシリテーターでも2〜3時間かかる。 LLMに付箋の内容をテキストで渡し、「類似するものをグルーピングし、各グループに名前をつけて」と指示すれば、 数分でたたき台が出来上がる 。Miro AIやFigJam AIにはこの機能が組み込まれている。 使い方のコツ AIのグルーピングをそのまま採用するのではなく、 「AIの分類と自分たちの分類がどう違うか」を議論のトリガーにする 。AIは表面的な語彙の類似でまとめがちだが、人間は文脈や意図で分類する。そのギャップが、チームの思考を深める材料になる。 創造フェーズ——アイデア発散の起爆剤 画像生成で発想を刺激する Crazy Eightsのような短時間アイデア出しで行き詰まったとき、AI画像生成ツール（Midjourney、DALL-E 3、Stable Diffusion等）が突破口になることがある。「高齢者が楽しそうに料理をしているキッチン」のようにキーワードを投げると、 チームが無意識に持っていたバイアスを視覚的に揺さぶる画像 が出てくる。 ワークショップでよく起こるのは、AIが生成した「予想外のビジュアル」がきっかけで、それまで出なかった角度のアイデアが生まれることだ。AIの画像は完成形ではなく、思考のトリガーとして使う。 テキストでのアイデア壁打ち LLMに「この課題に対して、50個のアイデアを出して。うち10個は非現実的なものにして」と指示する方法もある。量を出すことに特化したAIの特性を活かし、 人間だけでは到達しにくい「ありえない発想」を意図的に混ぜ込む 。使えないアイデアが9割でも、残り1割が議論の種になれば十分だ。 プロトタイプフェーズ——作る速度を桁違いに上げる UIプロトタイピング プロトタイプフェーズでAIの恩恵が最も大きい。Figma AI、v0（Vercel）、Google Stitch（旧Galileo AI）等のツールは、テキストの説明からUIモックアップを数秒で生成する。 「検索結果画面、カード型レイアウト、フィルター付き」と書くだけでプロトタイプのたたき台が手に入る 。 従来、デザイナーが半日かけて作っていたモックアップの初版を、AIが数分で出す。デザイナーはゼロからの構築ではなく、AIの出力を叩き台にした 編集と改善 に時間を使える。 コード生成 Cursor、GitHub Copilot等のAIコーディングツールを使えば、インタラクティブなプロトタイプも短時間で作れる。ただし、ここでも 目的を見失わないことが重要 だ。プロトタイプの目的は「学ぶこと」であって「完成品を作ること」ではない。AIが高速にコードを吐くからといって、過剰に作り込むと改善のコストが上がり、「捨てられないプロトタイプ」になってしまう。 テストフェーズ——分析と記録を強化する テスト動画の自動分析 ユーザビリティテストの録画をAIに分析させると、 ユーザーが操作に詰まった箇所のタイムスタンプ、表情の変化、発言のセンチメント を自動で抽出できる。手動で5人分の録画を見返す時間が大幅に削減される。 ヒートマップと行動データの統合 Hotjar、Microsoft Clarity等のヒートマップツールにもAI分析機能が搭載されるようになった。クリックパターン、スクロール深度、離脱ポイントを AIが自動で異常検知し、「ここに問題がありそうだ」と提示 してくれる。 ただし、テストフェーズで最も重要なのは「なぜそう行動したか」の理解であり、「何が起きたか」のデータ収集ではない。AIはWhatを高速に処理するが、Whyは人間が対話を通じて掘り下げるしかない。 AIツール導入の実践ガイド 小さく始める 全フェーズに一気にAIを導入しようとすると、ツール選定だけで疲弊する。まずは 1つのフェーズ、1つのタスク から始める。推奨は「インタビューの書き起こし」か「プロトタイプのモックアップ生成」。効果が実感しやすく、チームの抵抗感も少ない。 AIの出力を「最終成果物」にしない AIが生成したペルソナ、ジャーニーマップ、UIモックアップを、チームの議論を経ずにそのまま採用するケースが増えている。これは デザイン思考の自殺行為 だ。プロセスの中で「考える」こと自体が、チームの共通理解とオーナーシップを育てる。AIの出力はあくまで素材であり、チームの議論と判断を経て初めて意味を持つ。 費用対効果の見極め AIツールの多くはサブスクリプション課金で、チーム全体で使うと月額コストが膨らむ。 「手作業で30分以上かかるタスク」にだけAIを適用 するルールを設けると、コストとリターンのバランスが取りやすい。書き起こしや画像生成は費用対効果が高い。ブレインストーミングそのものをAIに丸投げするのは論外だが。 まとめ——AIは道具であり、パートナーではない デザイン思考の5フェーズそれぞれで、AIは 情報処理の速度を上げ、試行錯誤のサイクルを短縮 する。共感の文字起こし、定義のクラスタリング、創造のアイデア発散、プロトタイプの生成、テストの分析。どれもAIが入ることで、人間が「考える」時間を増やせる。 ただし、 「考える」という行為そのものはAIに委ねてはならない 。ユーザーの目を見て話を聞くこと。矛盾するデータの前で悩むこと。紙とペンで手を動かして形にすること。それがデザイン思考の核であり、AIでは代替できない部分だ。 AIツールは、人間の思考を拡張する道具として使い倒す。だが、道具に使われてはならない。 --- AIがデザイン思考の5フェーズそれぞれに組み込まれた現在、設計者の役割そのものがどう書き換わるかについては、AI時代のデザイン思考——機械学習との融合が設計者の役割を書き換えるで掘り下げている。 --- 参考文献 - Nielsen Norman Group, "AI Tools for UX Research", nngroup.com, 2023 - Jake Knapp & John Zeratsky, "AI and the Design Sprint: What Changes, What Doesn't", jazer.com, 2024 - Stanford d.school, "AI + Design Thinking: Exploration and Practice", dschool.stanford.edu, 2024 --- ### Appleのデザイン思考 — 「どうあるべきか」から始まる製品設計の哲学 URL: https://designthinking.studio/articles/case-apple-design-thinking/ > Appleの製品設計プロセスは、デザイン思考の手法書に載っている手順とは異なる。しかし「ユーザーを深く理解し、技術より体験を先に考える」という原則は共鳴する。Apple流デザイン哲学の核心を解読する。 Appleはデザイン思考の「5フェーズプロセス」を社内で公式に採用しているわけではありません。「技術ではなく人間の体験から始める」「なぜこれを作るのかを問い続ける」「完成するまで妥協しない」——この哲学は、しかしデザイン思考の核心と深く共鳴します。 Appleのケースが示すのは、フレームワークより「どんな問いを持ち続けるか」の方が決定的だという事実です。 ジョナサン・アイブのデザイン哲学 ジョナサン・アイブ（Jonathan Ive）は1992年にAppleに入社し、1997年のスティーブ・ジョブズ復帰後、チーフデザインオフィサーとして2019年までAppleの製品デザインを率いました。 アイブが繰り返し語ったのは、「どう見えるかではなく、どうあるべきかという問いから始める」というアプローチです。インタビューや講演の記録から浮かび上がるのは、製品の「本質」を問い続ける姿勢でした。 「どうあるべきか（What should it be?）」——この問いは、「ユーザーは何を必要としているか」というデザイン思考の共感フェーズの問いと表裏をなしています。機能の羅列から始めるのではなく、製品が存在すべき理由、人の生活の中でどんな位置を占めるべきかを先に問う。このアプローチが、Appleの製品設計の起点です。 ただし注意が必要です。アイブのアプローチは、標準的なデザイン思考が強調する「ユーザーに直接インタビューして検証する」プロセスとは必ずしも一致しません。ジョブズは「フォーカスグループに頼らない」と語ったことで知られており、「ユーザーは自分が欲しいものを言語化できない」という信念が、直接的なユーザーリサーチより深い洞察を重視する姿勢につながっていました。 これはデザイン思考との相違点であり、Appleのケースを盲目的に「デザイン思考の模範」として描くのは正確ではありません。 iMac G3（1998年）：「仕事だけのコンピューター」という定義を疑う 1997年、ジョブズが復帰した時点でAppleは経営危機にありました。翌年リリースされたiMac G3は、Appleを復活させた製品として語られます。 iMac G3のデザインが示すのは、「コンピューターとはどうあるべきか」という問いを根本から問い直した結果です。当時のパーソナルコンピューターは、ベージュの箱型で、机の上のスペースを大量に占有し、ケーブルで複雑に接続するものでした。これを「当たり前」と見なすのではなく、「なぜコンピューターはこの形でなければならないのか」と問う。 半透明のカラーシェルに包まれたiMac G3は、「コンピューターは生活空間に溶け込むものでありうる」という新しい定義を体現しました。技術的な新しさよりも、「人とコンピューターの関係を再定義する」という問いが製品の形を決めたのです。 このプロセスはデザイン思考の問題定義フェーズ——「解くべき問題を正しく定義する」——と深く響き合います。 Apple Storeのユーザー体験設計 2001年にオープンしたApple Storeは、製品設計だけでなくサービス体験の設計においてもAppleの哲学を体現しています。 従来の家電量販店では、製品はショーケースや棚に並べられ、客は「買いたいものを探す」体験をします。Apple Storeはこれを根本的に変えました。製品はすべてオープンに配置され、実際に触れ、使ってみることができる。Genius Barは「サポートカウンター」ではなく「専門家との対話の場」として設計されました。 「Geniusと話すために予約する」という体験は、医者や弁護士との約束に近い構造を持ちます。これは偶然ではなく、「Appleユーザーとして最大のサポートを受けるに値する」というポジショニングを体験として設計したものです。 デザイン思考的に分析すると、Apple Storeは「製品を売る場所」ではなく「Apple体験を提供する場所」として問題定義を行い、その定義に基づいてサービス設計を行ったケースです。 iPad（2010年）：「コンピューターとスマートフォンの間」という新しい定義 iPadの開発背景についてジョブズが語ったのは、「Netbookのカテゴリに参入するつもりはなかった」という点です。既存のカテゴリの改善ではなく、「ラップトップでもスマートフォンでもない、新しい体験」を定義することが先にありました。 実際にやってみると——つまりiPadを初めて手に取ってみると——「触るだけで分かる直感性」が実現されていることに気づきます。これは技術的な制約からではなく、「どんな人でも迷わず使えるべき」という設計原則が先にあり、それを実現するためにUIを設計したからです。 「ユーザーが頑張って使い方を覚えなければならないのは設計の失敗だ」というアイブとジョブズの共通した信念が、iPhoneからiPadにかけての操作設計の根底にあります。 AppleのケースからデザイナーはNOTを学ぶべきこと Appleをデザイン思考の成功事例として語るとき、見落とされがちな側面があります。 失敗事例も存在します。Apple Maps（2012年リリース当初）は地図の精度問題で大きな批判を受け、ジョブズ後のAppleがユーザーフィードバックを軽視した設計をしていたことを示しました。AirPower（ワイヤレス充電パッド）は2017年に発表されたものの、技術的な実現困難から2019年に開発中止が発表されました。 完璧な体験へのこだわりが、時に市場投入の遅れや製品の欠陥を生むという逆説も、Appleのケースが示す学びです。 また、Appleの方法論は規模と資源に支えられています。「どうあるべきか」を問い続けるための、数百人規模のデザインチームと数兆円規模の開発予算という文脈が前提にあります。このアプローチをそのままスタートアップや中小企業が採用しようとすることには注意が必要です。 デザイン思考実践者へのAppleケースの示唆 ワークショップでよく起こるのは、「Appleのようなデザインをしたいのでどうすればいいか」という問いです。この問いに対して、Appleが実践していることで最も模倣可能なのは、「問いを立てることへの投資」です。 「このプロダクトはどうあるべきか」「このユーザーの体験はどうあるべきか」「私たちは何のためにこれを作っているのか」——これらの問いを、チームの共通言語として持ち続けること。これはツールや予算なしに、今日から始められることです。 Appleの最大の学びは、特定の手法やプロセスにあるのではなく、「ユーザーの体験を優先する」という価値観の一貫性にあります。フレームワークより先に、その価値観をチームで共有することが、デザイン思考の導入における本質的な第一歩です。 --- 参考文献 - Walter Isaacson, Steve Jobs, Simon & Schuster, 2011 - Leander Kahney, Jony Ive: The Genius Behind Apple's Greatest Products, Portfolio/Penguin, 2013 - Ken Segall, Insanely Simple: The Obsession That Drives Apple's Success, Portfolio/Penguin, 2012 - Apple Newsroom, "Jony Ive to form independent design company, with Apple as a client", apple.com, 2019 - Horace Dediu, "The Jobs of the iPhone", Asymco, asymco.com, 2017 --- ### DX推進におけるデザイン思考の実装——現場で機能させる3つの条件 URL: https://designthinking.studio/articles/dx-design-thinking-implementation/ > DX推進でデザイン思考を機能させる3つの構造的条件を解説。探索の時間の確保、リサーチと意思決定の接続設計、組織構造への埋め込み——ワークショップで終わらせないための実装戦略を現場の失敗事例と対照しながら体系化する。 DX推進の現場で、デザイン思考は「使われているが機能していない手法」の筆頭になりつつあります。 経営会議でデザイン思考の言葉が出る。社内研修でワークショップが開催される。「共感」「プロトタイプ」「ユーザー中心」というキーワードが資料に並ぶ。しかし現場では、日常的な意思決定のプロセスも、システム開発の進め方も、何も変わっていない。 この断絶の原因は、デザイン思考の「学習」と「実装」を区別できていないことにあります。デザイン思考の実装とは、思考の方法論を組織の構造に埋め込むことです。ワークショップで学ぶだけでは、実装は起きません。 本記事では、DX推進の文脈でデザイン思考が実際に機能するための3つの構造的条件を、現場の実態から整理します。 --- なぜDXとデザイン思考は相性が悪く見えるのか DX推進にデザイン思考を導入した組織が、最初にぶつかる壁があります。DX推進とデザイン思考は、その優先ロジックが根本的に異なります。 DX推進が動く論理は、効率とスケールです。 システムを統合し、プロセスを自動化し、データを一元管理する。投資対効果が明確で、ROIで意思決定できる。スピードが求められ、「まず決めてから動く」という実行志向が強い。 デザイン思考が動く論理は、発見と検証です。 ユーザーを観察し、問いを定義し、仮説を立ててプロトタイプで検証する。「まだ答えが分からない」という不確実性を前提にする。時間をかけて理解を深めてから動くという探索志向が強い。 この論理の差異を無視して「DXにデザイン思考を導入する」と決定すると、実際には「DXのスピードにデザイン思考を合わせる」という変形が起きます。2時間のワークショップで共感フェーズを「完了」させ、翌日には仕様書を書き始める。デザイン思考の形式だけが残り、機能する余地がなくなります。 これは手法の失敗ではありません。実装条件の設計が欠けているための失敗です。 --- 条件1：「探索の時間」を構造として確保する DX推進の現場でデザイン思考が機能するための最初の条件は、ユーザー理解と問い直しのための時間を、プロジェクト計画に構造として埋め込むことです。 「時間があればやる」ではなく「やらなければプロセスが進まない」という設計でなければ、実務の圧力に負けます。 具体的な設計の例として、システム開発プロジェクトのフロントに探索専用のスプリントを設ける方法があります。2週間から4週間の期間を、成果物を定義した上で確保する。成果物は「ユーザーインタビューの実施（最低5名）」「インサイトをまとめたアフィニティ図」「POV文の定義」「HMWの問い設定」という形で具体化する。この期間をプロジェクト計画の公式なフェーズとして位置づけることで、省略が構造的に難しくなります。 現場でよく観察される失敗パターンがあります。「ユーザーリサーチをする時間を作ってください」という依頼を現場に投げると、「業務が忙しいので来月以降で」「リサーチの担当者がいない」という返答が来て、結局リサーチなしで仕様策定が始まります。これはリサーチを「任意のオプション」として設計しているからです。 このアプローチでは、経営層またはプロジェクトオーナーから「この2週間は探索フェーズであり、仕様策定はその後に始まる」という承認を事前に得ます。リサーチが省略されると開発フェーズに入れない、という設計にすることで、探索の時間が守られます。 もう一つの実装パターンは、既存の会議体にデザイン思考的な問いを埋め込む方法です。週次の進捗会議の冒頭15分を「ユーザーフィードバック共有」に固定する。月次のプロジェクトレビューに「ユーザー視点の発見事項」を必須アジェンダとして設定する。これにより、リサーチの時間を別途確保しなくても、ユーザー視点が意思決定の場に構造的に入ります。 探索の時間を「文化」ではなく「構造」で確保することが、最初の条件です。文化は長期的な変革の結果として生まれますが、構造は設計によって今日から変えられます。 --- 条件2：「意思決定の接続」を設計する デザイン思考の実装で最も見落とされがちな条件は、リサーチとインサイトが、実際の意思決定に接続される経路を設計することです。 ユーザーインタビューを実施し、アフィニティ図を作り、インサイトを言語化した。しかし、そのインサイトが「誰の、どの意思決定を、どのように変えるか」が設計されていなければ、成果物は資料フォルダに格納されて終わります。 接続の設計には3つのレベルがあります。 接続レベル1：機能仕様への接続 ユーザーリサーチのインサイトが、システムの機能要件・非機能要件の定義に直接反映される経路を作る。具体的には、機能仕様書のテンプレートに「このインサイトを根拠とする」という参照フィールドを追加します。「なぜこの機能が必要か」の答えがインサイトへのリンクになる。この設計により、仕様策定者はリサーチ成果物を参照する習慣が生まれます。 接続レベル2：優先順位の意思決定への接続 DX推進のプロジェクトでは常に「どの機能から作るか」という優先順位の決定が発生します。この決定がコスト・スケジュール・技術的制約のみで行われると、ユーザー視点は入りません。優先順位の評価基準に「ユーザーインパクト」という軸を明示的に追加し、インサイトに基づく評価を義務化します。 接続レベル3：経営報告への接続 DX推進の経営報告は多くの場合、KPI・コスト・スケジュールで構成されます。ここに「ユーザー理解の更新」という項目を追加します。「今月発見した、ユーザーに関する新しい事実」を経営報告の定例項目にすることで、経営層がユーザー視点に触れる機会が構造化されます。 意思決定の接続を設計しないと、デザイン思考はリサーチチームの内部活動に留まります。インサイトが組織の外に出ない。デザイン思考の価値は、インサイトが意思決定を変えるときにしか発揮されません。 実際に有効だったアプローチとして「インサイトカード」の活用があります。ユーザーリサーチで得られた各インサイトを1枚の構造化されたカードにまとめ（インサイトの要約・根拠となる観察・設計への示唆・HMWの問い）、プロジェクトの意思決定者全員に物理的に配布します。議論の場にインサイトが持ち込まれ、参照されます。デジタルで共有するより、物理的に手元にある状態の方が、意思決定の場で参照される頻度が高くなります。 --- 条件3：「失敗の許容」を評価制度で担保する デザイン思考の中核にあるのは、仮説をプロトタイプで検証し、失敗から学ぶというサイクルです。このサイクルが機能するための前提は、「失敗」が罰せられないことです。 しかし多くのDX推進組織では、評価制度が失敗を罰します。「計画通りに進んだか」「期日を守ったか」「コストを超えなかったか」という基準で評価される環境では、プロトタイプを作って「機能しなかった」という結果を出すことは評価上のリスクになります。担当者は「プロトタイプで失敗する」よりも「プロトタイプを作らずに仕様書を書く」ことを選びます。 評価制度の変革なしに、デザイン思考の実装は完成しません。 これは評価制度の全面改定を意味するわけではありません。既存の評価制度に「学習と実験に関わる評価項目」を追加する、というアプローチが現実的です。 具体的には、次の3つの評価項目を追加することが有効です。 「ユーザーリサーチの実施と共有」——今期に実施したリサーチ件数と、組織内への共有実績を評価する。リサーチを行動として起こすことが評価に繋がる設計にする。 「プロトタイプ検証の実施」——本開発前にプロトタイプを用いた検証を行ったプロジェクトの数を評価する。検証ステップを省略しないことが得になる設計にする。 「学びの言語化と共有」——失敗した仮説や中断したプロジェクトから得た知識を言語化し、チームに渡した実績を評価する。失敗を隠すよりも開示する方が得になる設計にする。 最も重要なのは、「失敗した実験の共有」を評価対象にすることです。「うまくいかなかった検証の結果を共有し、チームの知識を増やした」という行動に対して、ポジティブな評価が付く設計にすることで、失敗の隠蔽よりも共有が得になります。 評価制度の変革と合わせて、リーダーシップの行動変容が必要です。マネージャーが「なぜ計画通りに進まなかったのか」と問う代わりに「そこから何を学んだか」と問うようになる。この問いの変化が、チームの行動を変えます。制度と行動が一致したとき、失敗の許容が文化として定着し始めます。 --- 3つの条件の相互作用 3つの条件は独立したチェックリストではなく、相互に支え合う構造を持ちます。 探索の時間（条件1）があっても、得られたインサイトが意思決定に接続されなければ（条件2）、リサーチは形骸化します。インサイトが意思決定に接続されても、失敗が許容されなければ（条件3）、検証プロセスは省略されます。失敗が許容されても、探索の時間が確保されなければ、検証する仮説が生まれません。 3つの条件はパッケージです。どれか1つだけの実装では、効果が出にくい。 実装の順序としては「条件1から始め、条件2、条件3の順に整備する」というアプローチを推奨します。まず探索の時間を構造として確保し、リサーチの実績を作る。次にそのリサーチ成果物が意思決定に使われる経路を設計する。最後に、実験と失敗を評価する仕組みに着手する。この順序には理由があります。条件2・3の整備には組織全体の関与が必要ですが、条件1はプロジェクト単位で始められます。 --- DX推進への具体的な統合シナリオ 3つの条件を踏まえたDX推進プロジェクトの典型的な流れを示します。 Phase 0（2〜4週間）：探索フェーズ プロジェクト開始前に設ける探索フェーズ。ユーザーインタビュー（5〜10名）・現場観察・既存データのレビューを実施し、アフィニティ図とインサイトカードを成果物として定義する。成果物のレビュー完了を、Phase 1開始の条件として設定する（条件1の実装）。 Phase 1（システム設計）：インサイトからの仕様定義 Discovery Sprintのインサイトを元に、機能要件を定義する。仕様書の各機能に「根拠インサイト」を記載する欄を設け、インサイトのない機能要件は追加しない運用ルールを設ける（条件2の実装）。 Phase 2（プロトタイプ〜本開発）：検証サイクルの制度化 主要機能の本開発前に必ずプロトタイプ検証を実施するルールを設ける。検証結果を「仕様の更新根拠」として記録し、スプリントレビューで共有する（条件3の実装）。 このシナリオは理想的な状態ですが、現実には「Phase 0を1週間に圧縮せざるを得ない」「インタビューが3名しか実施できなかった」という制約が生じます。制約の中でも「ゼロよりは1人でもインタビューする」「仕様書に根拠フィールドだけは追加する」という最小単位の実装を維持することが重要です。構造の痕跡を残すことで、次のプロジェクトでの改善が可能になります。 --- 機能する実装の共通点 複数のDX推進プロジェクトで機能した実装に共通するパターンがあります。それは「デザイン思考を特別なものとして扱わないこと」です。 「今日はデザイン思考のワークショップです」という形で導入するのではなく、「プロジェクトの開始前にユーザーインタビューを実施する」「仕様書に根拠インサイトを記録する」「本開発前に低解像度のプロトタイプで検証する」という具体的な行動として、通常のプロセスに埋め込む。 デザイン思考という言葉を使わずに、デザイン思考の実践を組み込む——この逆説的なアプローチが、特にDXの実務文脈では有効に働きます。DXのリーダーは「デザイン思考を導入したい」という要求よりも「DXプロジェクトの成功率を上げたい」「ユーザーに使われないシステムを作るリスクを減らしたい」という問いを持っています。その問いに対して、デザイン思考の具体的な実践を「解決手段」として提示すると、導入への抵抗が大幅に下がります。 DX推進におけるデザイン思考の実装は、方法論の選択ではなく、組織の意思決定構造の再設計です。3つの条件——探索の時間の確保、意思決定への接続、失敗の許容——を構造として設計したとき、デザイン思考は「ワークショップの記憶」から「日常業務の論理」に変わります。 --- 関連項目 - デザイン思考とアジャイルの統合 - デザイン思考の組織定着ロードマップ - デザイン思考の限界と批判 - プロトタイプフェーズ - ダブルダイヤモンド --- ### IBMのデザイン思考導入：10万人規模の組織変革とEnterprise Designの全貌 URL: https://designthinking.studio/articles/case-ibm-design-thinking/ > 2012年から始まったIBMのデザイン思考大規模導入プロジェクト。10万人以上の従業員へのトレーニング、1,500名超のデザイナー採用、そしてIBM独自のフレームワーク「Enterprise Design Thinking」の誕生までを解説。 2012年、IBMはひとつの賭けに出ました。当時、エンタープライズソフトウェア市場での競争激化とSaaSへのシフトに直面していたIBMは、技術的な差別化だけでは生き残れないと判断し、「ユーザーエクスペリエンス」を競争優位の柱に据える戦略的転換を行ったのです。その手段として選ばれたのがデザイン思考の全社導入でした。 背景：IBMが直面していた問題 IBMの製品・サービスは当時、技術的な機能性では高評価を受けていましたが、使いやすさとユーザー体験の面で深刻な課題を抱えていました。エンジニア主導の開発文化の中で、ユーザーが実際にどう製品を使い、何に困っているかを理解する仕組みが十分に機能していなかったのです。 加えて、IBMのような大企業が直面する「スケールの問題」がありました。世界100カ国以上、従業員35万人以上の組織で、どうすればデザイン思考を一過性のトレーニングで終わらせず、日常の業務プロセスとして機能させられるか——これが導入チームが最初に向き合った問いでした。 導入の設計：3つの柱 IBMのデザイン思考導入を主導したのは、デザイン担当バイスプレジデントのフィル・ギルバートです。ギルバートは2012年にIBMに入社し、大規模組織でデザイン思考を機能させるための独自フレームワーク構築に着手しました。 第1の柱：デザイン組織の再構築 最初に行ったのは、デザイナーの大量採用です。IBMは2012年時点で約100名だった社内デザイナーを、2016年までに1,500名以上に拡大する計画を立て実行しました。 採用基準として重視されたのは、エンタープライズソフトウェアの経験よりも「ユーザー視点で問題を定義し、プロトタイプを作って検証する」実践能力でした。デザイナーを単独チームに集めるのではなく、各製品チームに「デザイン担当者」として組み込む体制を採用し、デザイン思考を特定チームの専有物にしない工夫を施しました。 第2の柱：Enterprise Design Thinkingの開発 スタンフォードd.schoolやIDEOの5フェーズモデルを、IBM の規模と文化に合わせて再設計したのが「Enterprise Design Thinking（EDT）」です。 EDTの核心は3つのプラクティスです。 Hills（ヒルズ） は、チームが到達すべきゴールを「ユーザーにとっての成果」として定義するフレームです。「機能を実装する」のではなく「特定のユーザーが特定の状況で特定のことを実現できる」という形式で書かれ、チーム全員の判断基準となります。 Playbacks（プレイバック） は、定期的にステークホルダーを集め、ユーザーの視点から進捗を確認するレビューセッションです。単なる進捗報告ではなく、「ユーザーにとっての価値はどう変化したか」を問い続ける仕組みとして機能します。 Sponsor Users（スポンサーユーザー） は、実際のユーザーを開発プロセスに組み込む仕組みです。単発のユーザーテストではなく、特定のユーザーと継続的な関係を持ち、開発の各フェーズでフィードバックを得るというアプローチで、共感フェーズを一回限りのイベントではなく継続的なプラクティスにします。 第3の柱：トレーニングと資格制度 10万人以上の従業員に対してデザイン思考を「知識」として伝えるため、IBMはオンラインコースとフィジカルなワークショップを組み合わせたトレーニングシステムを構築しました。 2016年にはデザイン思考のオンラインコースを一般公開し、IBMの社員以外にも開放しました。現在もIBM SkillsBuildやCourseraで受講可能です。また、デザイン思考の実践能力を認定する社内資格制度を整備し、各チームに一定比率の認定者を配置することを推奨しました。 成果と数値 2016年にIBMが発表したレポートによると、EDTを導入したチームの成果として以下のデータが報告されています。 - 設計サイクルの短縮：初期設計フェーズが75%短縮されたプロジェクトが存在 - ROI：デザイン思考に投資した1ドルに対して300ドルのリターンを試算したケースも報告 - 開発コストの削減：手戻りの減少により、あるプロジェクトでは開発コストが35%削減 ただし、これらの数値はすべてのプロジェクトに均一に当てはまるものではなく、チームのコミットメント、マネジメントの関与、ユーザーリサーチの質によって結果に大きな差があったことも報告されています。 課題：スケールとの戦い IBMの事例が示す最も重要な教訓のひとつは、「大規模導入の困難さ」をあらかじめ設計に組み込む必要があるという点です。 ワークショップ形式のトレーニングで「デザイン思考を理解した」感覚を得た従業員が、翌週から通常業務のプレッシャーの中でどうその知識を使うか——ここに最大の課題があります。IBMはドット投票のような具体的なツールの使い方よりも、「ユーザーの視点から問いを立てる」というマインドセットの変容を優先しましたが、それは時間のかかるプロセスでした。 フィル・ギルバートが「5年計画」と明言していた通り、この変革は短期的な成果ではなく、組織文化の変容を目指した長期投資として設計されていました。 大企業への示唆 IBMのケースは、デザイン思考の導入を検討している大企業に対して、いくつかの重要な示唆を与えています。 スモールスタートの次を考える。ワークショップや1回のデザインスプリントで終わるデザイン思考は「体験」であって「文化」ではありません。IBMは「Hills」「Playbacks」「Sponsor Users」という繰り返し使えるプラクティスを標準化することで、一過性を防ぎました。 デザイナーの配置が変革を駆動する。デザイン思考の普及において、専門のデザイナーを各チームに埋め込むことは、トレーニングよりも効果的な「実践による学習」を促します。IBMが1,500名超のデザイナーを採用したのは、この論理に基づいています。 指標を設計する。「デザイン思考が定着しているか」を測る指標がなければ、取り組みは形骸化します。IBMは製品のテストフェーズでのユーザーテスト実施率、Sprint内でのユーザー接触回数などを内部指標として追跡しています。 まとめ IBMのEnterprise Design Thinking導入は、「デザイン思考は小規模チームのためのもの」という思い込みを覆した事例です。10万人規模の組織で、どうデザイン思考を生きたプラクティスとして機能させるか——その答えは、普及のためのフレームワーク設計、組織へのデザイナー埋め込み、そして継続的なユーザーとの接点の制度化にありました。 完璧に機能したわけではありませんが、エンタープライズにおけるデザイン思考の最も詳細な実践記録として、今日も多くの組織変革の参照点となっています。 --- 参考文献 - IBM Design, "IBM Design Thinking Field Guide", IBM Design, 2016 - Phil Gilbert, "Design at Scale: IBM's Design Thinking Journey", SXSW 2018 講演 - Kathryn Best, "IBM's 100 Year Design Thinking Journey", Design Management Review, 2017 - IBM, "Enterprise Design Thinking", ibm.com/design/thinking --- ### IDEO ショッピングカート再デザイン——デザイン思考の原点 URL: https://designthinking.studio/articles/case-ideo-shopping-cart/ > 1999年にABCテレビ番組で放映されたIDEOのショッピングカート再デザインプロジェクト。デザイン思考のプロセスを世に知らしめた象徴的事例を解説。 1999年、ABCテレビの番組「Nightline」は、デザインコンサルタント会社 IDEO に「5日間でショッピングカートを再デザインする」という挑戦を持ちかけました。この番組は、デザイン思考のプロセスを一般に広く知らしめた歴史的な事例です。 プロジェクトの概要 IDEO のチームは、多様な専門分野のメンバー——エンジニア、心理学者、MBA、言語学者——で構成されました。5日間という制約の中で、以下のプロセスを実践しました。 Day 1：観察とリサーチ チームメンバーは実際のスーパーマーケットに出向き、買い物客の行動を観察しました。カートの専門家、店員、買い物客へのインタビューも実施しました。 観察から得られた主なインサイトは以下の通りです。 - 子どもがカートに乗ると危険 - 買い物客はカートを一時的に放置して棚に向かう - カートの盗難が小売業者にとって大きなコスト - カートのハンドルは細菌の温床になっている Day 2-3：アイデア発想とプロトタイピング チームは「Deep Dive」と呼ばれるブレインストーミングセッションを実施しました。数百のアイデアが生まれ、投票によって有望なコンセプトが選ばれました。 その後、チームは4つの小グループに分かれ、それぞれが異なるアプローチでプロトタイプを制作しました。 Day 4-5：統合と最終プロトタイプ 各グループのプロトタイプの長所を統合し、最終的なショッピングカートのプロトタイプを完成させました。 完成したカートの特徴は以下の通りです。 - モジュラー式バスケット — 取り外し可能な小さなバスケットで、棚への移動が容易 - スキャナー内蔵 — 商品を入れながらスキャンして合計金額を確認 - 子ども用シートの排除 — 安全性を考慮した設計変更 - フック付きフレーム — バッグを掛けられる柔軟な構造 この事例が教えてくれること ワークショップでこの事例を紹介するたびに、参加者の反応は決まってふたつに分かれます。「5日間でここまでできるのか」という驚きと、「でも実際の職場では無理でしょう」という懐疑です。 実際にやってみると分かるのですが、この事例の本質は「5日間」という制約にあります。 制約があるから発散と収束が強制的に切り替わり、決断が先送りにされない。時間の圧力が、プロセスを機能させているのです。これはのちにデザインスプリントとして体系化される考え方の原型でもあります。 IDEO のショッピングカートプロジェクトが示す核心的な教訓は以下の通りです。 - 多様な視点 — 異なる専門性を持つメンバーが協働することで、単一の視点では見えなかった問題を発見できる - ユーザー中心 — 技術的に可能なことではなく、ユーザーが実際に困っていることから出発する - 素早い反復 — 完璧を目指さず、プロトタイプを通じて素早く学ぶ - 楽しさの重要性 — 創造的なプロセスには、遊び心と安全な環境が不可欠 まとめ この番組は世界中で視聴され、デザイン思考という言葉を一般に広める大きなきっかけとなりました。20年以上経った今日でも、デザイン思考の教育で最も頻繁に引用される事例の一つです。 --- 参考文献 - ABC News Nightline, "The Deep Dive: One Company's Secret Weapon for Innovation", 1999年7月放映 - Tom Kelley & Jonathan Littman, The Art of Innovation, Currency/Doubleday, 2001（第1章：Deep Dive） - Tim Brown, Change by Design, HarperBusiness, 2009 --- ### JTBD×デザイン思考 — 「片付けたい用事」から始める問題定義の統合アプローチ URL: https://designthinking.studio/articles/jtbd-and-design-thinking/ > Jobs To Be Done（JTBD）理論とデザイン思考を統合することで、より鋭い問題定義ができる。両フレームワークの相違点と補完関係を整理し、実務での組み合わせ方を具体的に示す。 「ユーザーはドリルを買いたいのではなく、穴を開けたいのだ」 Harvard Business Schoolのセオドア・レビットが述べたとされるこの言葉は、Jobs To Be Done（JTBD）理論の核心を端的に表しています。しかしワークショップでよく起こるのは、この言葉を知っていながら「ユーザーはどんな属性を持っているか」「どんな機能が必要か」という問いに戻ってしまうパターンです。 JTBD理論は、デザイン思考のユーザーリサーチ・問題定義フェーズを大きく強化できます。本記事では両フレームワークの相違点と補完関係を整理し、実務での組み合わせ方を具体的に示します。どちらかを捨ててどちらかを採る話ではありません。 --- JTBD理論とは何か JTBD（Jobs To Be Done）は、Clayton Christensenらが発展させた製品・サービス設計の理論です。核心的な主張は「人は製品を買うのではなく、人生のある文脈で片付けなければならない仕事（ジョブ）のために、製品を『雇用する』」というものです。 有名な事例を挙げます。McDonald'sがミルクシェイクの売上向上を研究した際、従来のアプローチ（性別・年齢・好みによるセグメンテーション）では有効な答えが得られませんでした。JTBDの視点でリサーチしたところ、朝のミルクシェイクの主要な購買者は「長い通勤時間を退屈せずに過ごしたい」というジョブのためにシェイクを購入していることが分かりました。競合はシェイクではなく、バナナや、ラジオの音楽でした。 この発見は、製品の「機能改善」ではなく「ジョブを解決する文脈の理解」から生まれます。 --- デザイン思考とJTBDの相違点 デザイン思考とJTBDは、目指すものは似ていますが、アプローチに明確な違いがあります。 ユーザーの捉え方 デザイン思考： ユーザーを「特定の状況に置かれた具体的な人間」として捉えます。ペルソナで「34歳、東京在住、マーケター、子育て中」のような属性を定義し、共感インタビューでその人の感情・思考・行動を深く理解します。 JTBD： ユーザーを「状況の中でジョブを抱えている人」として捉えます。属性よりも「どんな状況で、どんなジョブが発生しているか」を重視します。「34歳のマーケター」という属性よりも「締め切り前夜に、資料作成が行き詰まっている状況」という文脈が設計の起点になります。 「なぜ」の掘り方 デザイン思考： 「ユーザーが感じていること・思っていること・行動していること」を観察・インタビューで収集し、インサイトに変換します。共感フェーズでは感情的・文化的な側面を重視します。 JTBD： 「ユーザーが解決しようとしているジョブは何か」を、行動の変化点（スイッチングインタビュー）から特定します。「なぜ以前の解決策をやめて、新しいものを選んだか」という購買・利用の変化点が最も重要な情報源です。 --- JTBDがデザイン思考を強化する3つの点 - ジョブ軸での問題定義の精度が上がる デザイン思考の問題定義フェーズでは「How Might We（HMW）」文を使います。JTBDの視点を加えると、HMWの質が変わります。 JTBDなしのHMW：「どうすれば田中さん（34歳・マーケター）が資料作成をより効率的に行えるか？」 JTBDありのHMW：「どうすれば締め切り直前に行き詰まった状況の人が、短時間で突破口を見つけられるか？」 後者はソリューションの幅が広がります。対象は「マーケターのツール」ではなく「行き詰まった状況を突破するあらゆる手段」になります。 - コンテキストへの注目が共感を深める JTBDが「購買・利用の状況文脈」を重視することは、デザイン思考の共感フェーズを補強します。 ユーザーインタビューでJTBDの問い方を使うと、より具体的な文脈情報が得られます。「このサービスを最後に使ったとき、その直前に何をしていましたか？」「使い始めたのはどんなきっかけでしたか？ その直前、どんな状況でしたか？」 実際にやってみると、この「直前に何をしていたか」という問いが、ユーザーが置かれた状況の鮮明な描写を引き出します。抽象的な「不満」ではなく、具体的な「状況」が可視化されます。 - スイッチングインタビューでインサイトを加速する JTBDのスイッチングインタビューは、デザイン思考のユーザーリサーチに強力な手法を提供します。 スイッチングインタビューは「以前やっていたことをやめて、今やっていることに変えた体験を話してもらう」インタビューです。変化の瞬間には、ジョブと解決策の関係が最も鮮明に現れます。 例：「3ヶ月前にタスク管理ツールをAからBに変えたと聞きました。変える直前、どんな状況でしたか？ 何が最後の一押しになりましたか？ 変えた後、どんな変化がありましたか？」 この問いから「ツールの機能の比較」ではなく「どんな状況でジョブが発生し、どんな解決策を選んだか」という設計に直結するインサイトが得られます。 --- 統合的な実践フロー Step 1：ジョブの仮説を立てる（JTBDから始める） リサーチを始める前に「このユーザーセグメントが抱えているジョブは何か」の仮説を、チームで書き出します。「機能的ジョブ（達成したいこと）」「感情的ジョブ（感じたいこと）」「社会的ジョブ（見られたいこと）」の3分類を使うと整理しやすい。 Step 2：スイッチングインタビューで状況文脈を収集する（JTBDの手法） 既存ユーザーと、最近競合サービスに乗り換えたユーザーにスイッチングインタビューを実施します。「変化の瞬間」の状況を詳細に記録します。 Step 3：共感インタビューで感情・思考を深掘りする（デザイン思考の手法） スイッチングインタビューで特定した重要な状況に対して、共感インタビューを実施します。「そのとき、どんな気持ちでしたか？」「頭の中で何を考えていましたか？」という問いで、感情的・社会的ジョブを掘り下げます。 Step 4：ジョブ起点のPOV文を書く（統合） POV文を「ユーザー属性」ではなく「状況×ジョブ」を起点に書きます。「[状況]に置かれた人は、[ジョブ]を片付ける手段を必要としている。なぜなら[感情的・社会的ジョブ]があるからだ」 Step 5：ジョブ軸のHMWを設定する 特定したジョブを起点に「どうすればこのジョブをより良く解決できるか」というHMWを設定します。ジョブを起点にするとソリューションの幅が広がり、既存のカテゴリに縛られない発想が生まれやすくなります。 --- JTBDが説明できないもの JTBDは強力ですが、「ジョブ」で割り切れない行動があります。 アートや音楽への没頭、ブランドへの愛着、ゲームに費やす5時間——これらを「片付ける仕事」で説明するのは、少し無理がある。デザイン思考の共感フェーズが重視する「感情・文化・物語」の次元は、JTBDの機能的合理性では捉えきれません。 JTBDが得意なのは「なぜその製品を選んだか」の説明。デザイン思考が得意なのは「その人がどんな体験を生きているか」の理解。この差を知って使うと、両者の組み合わせが格段に鋭くなります。 --- 参考文献 - Christensen, Clayton M., Hall, Taddy, Dillon, Karen & Duncan, David S., Competing Against Luck: The Story of Innovation and Customer Choice, HarperBusiness, 2016 - Ulwick, Anthony W., Jobs to Be Done: Theory to Practice, Idea Bite Press, 2016 - Klement, Alan, When Coffee and Kale Compete: Become Great at Making Products People Will Buy, CreateSpace, 2018 - Brown, Tim, Change by Design, HarperBusiness, 2009 - Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth, Columbia Business Press, 2011 --- ### K-12教育カリキュラムへのデザイン思考統合 — 問題解決能力の育成 URL: https://designthinking.studio/articles/design-thinking-education-k12/ > シンガポール・米国・日本の先進校事例から読み解く、K-12全学年でのデザイン思考カリキュラム統合の実際。学年段階別の設計原則と、教科横断で問題解決能力を育てる具体的な授業構造を解説する。 「将来の職業の65%は今存在しない」という予測（Institute for the Future, 2017）が初めて引用された頃、多くの教育関係者は戸惑いを隠せなかった。何を教えれば良いのかが根本から問い直される状況に、従来の教科ベースのカリキュラムは十分な答えを持っていなかった。 答えているのが、デザイン思考をカリキュラムの中核に据えた学校群だ。シンガポール、米国、そして日本の事例を横断すると、特定の教科知識ではなく「問題に向き合う構造」を学ぶ機会を意図的に設計することが、共通する核心だ。 --- K-12教育とデザイン思考の接点 「K-12」とは Kindergarten（幼稚園）から12学年（高校3年）に至る13年間の教育段階を指す概念で、米国のカリキュラム研究で一般化した用語だ。日本では幼稚園・小・中・高の接続として捉えられる。 IDEO が設立した非営利部門 IDEO.org は、2012年から教師向けのデザイン思考トレーニング「Design Thinking for Educators」ツールキットを無償公開し、現在までに世界100ヶ国以上の教育者がダウンロードしている。同ツールキットの序文にある言葉が、この取り組みの方向性を端的に示している。 教師はデザイナーだ。彼らは毎日、学習体験をデザインしている。デザイン思考はその直感を、明示的な方法論に変える。 — IDEO, Design Thinking for Educators, 2nd Edition, 2012 デザイン思考が教育カリキュラムに統合されたとき、何が変わるのか。抽象的に語るより、具体的な事例から入る方が実態に近づける。 --- シンガポール・モデル——国策としてのデザイン思考教育 シンガポールの教育省（Ministry of Education Singapore）は、2010年代中盤から「21st Century Competencies」フレームワークを段階的に全国の学校に展開してきた。このフレームワークの核には、批判的思考・創造性・コミュニケーション・コラボレーションの「4C」が置かれており、デザイン思考はその実装メソッドとして機能している。 注目すべき事例の一つが、南洋小学校（Nanyang Primary School）の取り組みだ。同校は2016年から全学年でデザイン思考を教科横断的に統合するプログラムを開始し、理科・国語・算数の授業内に共感・定義・創造のフェーズを埋め込む構造を設計した。 低学年（小1〜2）での実装は、道具と言語を極限まで削ぎ落とすことから始まった。 「付箋」「ブレインストーミング」といった言葉は使わない。代わりに「友達の困っていることを聞いてみよう」（共感）→「何が一番大変そう？」（定義）→「どうしたら助けられそう？絵を描いてみよう」（創造・プロトタイプ）という会話のフローを、日常の授業に埋め込んでいる。 ワークショップでよく起こるのは、低学年の子どもが「友達の悩みを聞く」セッションで、大人が予測しなかった洞察を出すことだ。「給食の時間が短いのが嫌」「図書室の本が重すぎて持てない」——このレベルの観察から出発する問題定義は、子どもが「問題を見つけることには正解がない」という実感を最初に得る貴重な体験になる。 --- 米国の実践——Design Lab アプローチ 米国では、カリキュラム統合の方式が二つに大別される。「スタンドアロン型」と「統合型」だ。 スタンドアロン型は、デザイン思考を独立した授業として設置するモデルだ。カリフォルニア州のアルタ・ヴィスタ・エレメンタリースクールが採用した「Design Lab」は典型例だ。週1コマをデザイン思考の専用時間として確保し、担任以外の専任ファシリテーターが指導する。このモデルの強みは純度の高い体験を提供できることだが、弱みは他教科との接続が希薄になりやすいことだ。 統合型は、既存の教科カリキュラムの中にデザイン思考の構造を組み込む。ニューヨーク市教育局の「Design thinking in Schools」プロジェクト（2018年〜）はこのアプローチを採用し、社会科の単元内に「地域の問題をデザイン思考で解決する」プロジェクト学習を埋め込む設計をとった。 実際にやってみると、統合型の難所は教師側の設計負荷だ。既存の単元目標（例：「江戸時代の農民の生活を理解する」）と、デザイン思考の探索的プロセスを同時に評価するルーブリックを作ること自体が高度な設計作業になる。これを克服したプログラムに共通するのは、教師同士がユニット設計を共同で行う「コ・デザイン」の時間を組織的に確保していたことだ。 Stanford d.school の「K12 Lab Network」は、こうした教師の共同設計を支援するプラットフォームとして機能しており、カリキュラム設計のテンプレートやファシリテーションガイドを無償提供している（参考：d.school K12 Lab, Design Thinking in Schools, 2019）。 --- 日本の現状と先進事例 日本では、「総合的な学習の時間」がデザイン思考統合の受け皿として機能しやすい構造を持っている。探究的な学習プロセスを明示的に求める文部科学省の方針は、デザイン思考の5フェーズと重なる。 ただし実際には、総合学習がデザイン思考の構造を持てているケースは限られる。テーマ設定が教師主導になり、生徒が「共感フェーズ」を省略したまま解決策の探索に入るパターンが多い。問いを立てる経験の前に、解決策を求める圧力がかかってしまうのが日本の教育現場の構造的な課題だ。 この課題に正面から取り組んでいる学校がある。神奈川県の公立中学校で2021年から実施されている「地域課題探究」プログラムは、IDEO.orgのフレームワークを参照しながら、3年間のカリキュラム全体を「共感→定義→創造→プロトタイプ→テスト→発表」の6段階として設計し直した。 参加者からの声として、最も印象的だったのは「最初の半年間は問題を見つけることしかしないと聞いて驚いた」という生徒の言葉だ。3年間のうち最初の2学期を徹底的に「フィールドリサーチと問題定義」に費やす設計は、結果として「私たちが選んだ問題」という当事者意識を生み、最終年度のプロトタイピングとテストに本気度の高い生徒集団を生み出した。 --- 学年段階別の設計原則 K-12全体を通したカリキュラム設計では、認知発達段階に応じた調整が必要だ。Jean Piagetの認知発達理論（前操作期・具体的操作期・形式的操作期）を参照しながら、デザイン思考の各フェーズへの接触様式を段階的に変化させる設計が有効だ。 | 学年段階 | 認知特性 | デザイン思考の接触様式 | |---|---|---| | 低学年（1〜3年） | 具体的・直感的。遊びと学びの境界が薄い | 「体験してから言語化」。付箋や道具より身体活動優先 | | 中学年（4〜6年） | ルールへの関心が高まる。グループ協働が可能になる | チームでの観察インタビューと構造化されたアイデア発散 | | 中学生（7〜9年） | 抽象思考の萌芽。社会課題への関心が高まる | How Might We の立て方。本格的なユーザーリサーチ | | 高校生（10〜12年） | 体系的な思考と内省能力が発達する | プロジェクト全フェーズの自律的な管理。スタークホルダー分析 | 実際にやってみると、中学生段階でのHMWの立て方は最も時間をかける価値がある。「どうすれば〜できるだろう？（How Might We）」という問いの立て方は、問題を呪い（「あの先生がいるから嫌だ」）から可能性（「どうすれば授業がもっと自分のペースで進められるだろう？」）に変換するスキルだ。このスキルが定着した生徒集団は、高校生段階での探究活動の質が明確に変わる。 --- 評価の難問——プロセスをどう測るか K-12教育でデザイン思考を定着させる上で避けられない課題が、評価の設計だ。日本を含む多くの国の教育システムは、知識の習得を点数化することに最適化されており、「問いを立てる能力」「失敗から学ぶ態度」を評価する枠組みを持っていない。 IDEO.orgが提案する評価の枠組みでは、プロダクトの質よりもプロセスの質を評価の主軸に置く。具体的には以下の3軸だ。 - 共感の深さ — ユーザーインタビューで「なぜ？」を何回追えたか。表層の不満より深い動機に到達したか - 定義の精度 — 「問題の定義」が再考される過程を生徒はメタ認知できているか - プロトタイプの速度と数 — 完成度より試行回数。「今すぐテストできる最低限のもの」を作れたか この評価軸は、従来の評価システムとの並存が難しい。参加者からの声として多く聞かれるのは、「ルーブリックを作っても、それが生徒の探索を方向付けてしまい、型通りのプロセスになる」というジレンマだ。評価設計そのものが Wicked Problem になる——この逆説は、デザイン思考教育の最も正直な現実を示している。 --- カリキュラム統合の4つの落とし穴 3カ国の事例を横断した観察から、K-12へのデザイン思考統合が失敗するパターンが共通して見えてきた。 落とし穴1：ツールの儀式化。 付箋・ペルソナ・HMWを使えば「デザイン思考をやった」という錯覚が生まれる。ツールは方法であり目的ではない。ツールの使用量と、実際の共感の深さは別の指標だ。 落とし穴2：失敗への過保護。 生徒がプロトタイプをテストして否定されたとき、教師が「でも面白いアイデアだったよ」と慰めることで失敗の情報を希薄化してしまう。デザイン思考の核心は「失敗から学ぶプロセス」であり、教師が失敗を素早く「良かった探し」に変換することは、このプロセスを損なう。 落とし穴3：学年をまたいだ接続の断絶。 小6でデザイン思考を体験した生徒が、中1の授業でまたゼロから始める構造では、スキルの積み上げが生まれない。K-12を通貫したカリキュラム設計が機能するには、学年間の情報共有と引き継ぎの仕組みが必要だ。 落とし穴4：教師のアップデートが止まる。 研修を1回受けた教師が、3年後に同じファシリテーションをする。デザイン思考教育の品質維持は、教師自身の学習継続にかかっている。 --- 実践へのステップ——今週からできること カリキュラム全体の再設計は大規模なプロジェクトだが、明日の授業から試せることがある。 まず、既存の授業に「共感フェーズ」を1コマ追加することから始める。 理科の実験前に「この実験道具を使ったことがある人に話を聞いてみよう」というインタビューを10分設けるだけで、生徒は「ユーザーリサーチ」の基本構造を体験できる。 次のステップとして、既存の宿題に「問いを立てる」要素を加える。「〇〇について調べてきなさい」を「〇〇についての問いを3つ持ってきなさい」に変えることで、探索の起点が情報収集から問いの生成に移る。 最後に、クラス内で「プロトタイプの共有」の習慣を作る。「次の授業までに紙で作ったものを持ってきて」という指示は、完成度を問わずに試作品を作る文化を作る。これはプロトタイプフェーズの基本動作を、日常の授業に溶け込ませる最も手軽な方法だ。 デザイン思考のK-12統合は一夜にして完成しない。しかし、問いを立てることを教える教師と、問いを持つことを学ぶ生徒が出会う瞬間は、カリキュラムの完成度とは別のところで生まれる。その瞬間を意図的に増やしていくことが、K-12教育へのデザイン思考統合の現実的な入り口だ。 --- 参考文献・出典 - Institute for the Future, The Next Era of Human|Machine Partnerships, 2017（Dell Technologies委託） - IDEO.org, Design Thinking for Educators, 2nd Edition, 2012（無償公開ツールキット） - Ministry of Education Singapore, 21st Century Competencies Framework, 2014（改訂版） - Stanford d.school K12 Lab, Design Thinking in Schools, 2019 - Krajcik, J. S., & Shin, N., "Project-Based Learning", The Cambridge Handbook of the Learning Sciences, 2014 - Jean Piaget, The Psychology of Intelligence, 1950（日本語訳：滝沢武久訳、みすず書房） 関連記事: デザイン思考の共感フェーズ / デザイン思考を学校教育に導入するための実践ガイド / プロトタイプフェーズの実践 / デザイン思考の公共部門・自治体活用——行政改革ケース3選 --- ### NetflixのデザインにみるデザインThinking実践｜パーソナライゼーションと試行錯誤の18年 URL: https://designthinking.studio/articles/case-netflix-design-thinking/ > Netflixが2007年のストリーミング転換から現在まで、ユーザーリサーチとプロトタイプ検証を軸にサービスを進化させてきた軌跡を分析。サムネイルA/Bテスト・インターフェース再設計・推薦アルゴリズムの人間中心設計を事例として解説する。 世界3億2,000万件以上のサブスクリプションを持つNetflixは（2024年末時点の公開情報をもとに推定）、今や「コンテンツビジネスの覇者」として語られることが多い。しかしその成長の裏側には、ユーザーリサーチとプロトタイプ検証の反復を、文化として埋め込んだ組織設計がある。 デザイン思考の視点でNetflixを分析すると、5フェーズの各プロセスが事業戦略と連動していることが見えてくる。共感フェーズにおけるユーザー行動データの深掘り、定義フェーズにおける「なぜ人は視聴をやめるのか」という問いの立て方、創造フェーズにおける大量のインターフェース試作、プロトタイプフェーズにおける段階的ロールアウト、そしてテストフェーズとして機能するA/Bテストの徹底活用——これらは教科書的なデザイン思考のプロセスそのものだ。 --- 2007年の賭け：DVDからストリーミングへの転換 Netflixが最も劇的なデザイン思考的判断を下したのは、2007年だ。当時はDVD宅配レンタルサービスとして成功を収めていたが、共同創業者リード・ヘイスティングスはストリーミング配信への転換を決断した。 この判断の背景にあったのは、公開資料が示すユーザーの声だった。「DVDが届くまで待つのが面倒」「見たいと思った瞬間に見られない」「気分が変わったら見なくなる」——ユーザーの根本的なフラストレーションは、DVDというメディアの物理的制約そのものにあった（Hastings & Meyer, 2020による言及をもとに推定）。 共感フェーズで収集されたこれらのインサイトは、「どうすればDVD配送を改善できるか」という問いから「どうすればすぐに視聴できる体験を作れるか」という問いへの転換を促した。これは定義フェーズにおける「問いの再構成」の典型だ。当時のNetflixは、自社の事業モデルを壊すことで顧客の根本的な欲求に応えるという選択をした。 --- ホームページの「正解探し」: 10年以上のインターフェース反復 Netflixのホームページデザインは、一般に公開されているだけでも2007年から現在まで十数回の大きな刷新を経ている。しかしこれは「デザイントレンドへの追従」ではなく、ユーザー行動データに基づく継続的なプロトタイプ検証の結果だ。 2013年頃から本格化したのが、レイアウトと情報設計の大規模な見直しだ。「ユーザーはどのコンテンツを見つけられずに離脱しているか」「スクロールはどこで止まるか」「新規登録ユーザーが最初の7日間に何を視聴するかが継続率に影響するか」——これらの問いに対して、Netflixは複数のインターフェースバリエーションを同時並行でテストし、統計的に有意な差が出たデザインを採用するアプローチを取り続けた。 実際にやってみると分かるのだが、インターフェースの細部の変化が視聴継続率に数パーセントポイントの影響を与える。月2,000万人のアクティブユーザーを前提にすると、数パーセントポイントの改善は数十万人規模の継続率変化を意味する。このスケール感がNetflixの「テスト文化」の合理的な根拠だ。 --- サムネイル最適化：共感とテストの融合 Netflixが2016年に公開したテクニカルブログ（Netflix Technology Blog）は、1つのコンテンツに対して複数のサムネイル画像を生成し、ユーザーセグメントごとに異なる画像を表示するシステムを解説している。 この取り組みのスタート地点は「ユーザー観察」だった。データサイエンスチームは、同じコンテンツでもサムネイル画像によってクリック率が大幅に変わることを発見した（Netflixのテクニカルブログは「significant impact」と表現しており、具体的な数値は非公開）。さらに深掘ると、同じユーザーであっても、時間帯・デバイス・直前に視聴したコンテンツによって「引き付けられる画像」が異なるという洞察が得られた。 この発見から生まれたソリューションは、「全ユーザーに最適な1枚のサムネイル」を探すのではなく、「各ユーザーにパーソナライズされたサムネイル」を動的に生成・表示するシステムだ。2016年のブログによると、このシステムの導入後、コンテンツ発見率が有意に改善したとされている。 ワークショップでよく起こるのは、「サムネイルの差で視聴率が変わるなんて表面的な話では？」という反発だ。しかしユーザーが何かを選ぶ瞬間の「認知負荷」を下げることは、体験設計の根幹だ。サムネイルは情報設計の一形態であり、ユーザーの「次を見たい」という欲求を可視化するインターフェースだ。 --- 推薦アルゴリズムの人間中心設計 Netflixの推薦システムは、2006年の「Netflix Prize」コンペティションから進化を続けている。100万ドルの賞金をかけて世界中の機械学習研究者が参戦したこのコンペは、アルゴリズムの精度向上だけを追求していたが、最終的に「精度が高い推薦」と「ユーザーが実際に視聴するコンテンツ推薦」が乖離することが明らかになった。 Netflixの元プロダクトマネージャー、Xavier Amatriain氏が2012年のACM RecSys（推薦システム国際会議）で発表した資料によると、Netflix Prizeの優勝アルゴリズムは「精度指標（RMSE）」では優れていたが、実際のユーザー行動への改善効果は限定的だった。理由は、アルゴリズムが「ユーザーの評価」を予測しようとしていたが、実際にユーザーが求めているのは「今夜楽しめるコンテンツとの出会い」だったからだ。 この気づきは、まさにJTBD（Jobs to be Done）フレームワークで説明できる。「コンテンツを推薦される」というジョブではなく、「今夜の時間を楽しく過ごす」というジョブに焦点を当てることで、推薦システムの設計思想が根本から変わった。 --- UI失敗から学んだ「シンプルさの追求」 Netflixが公開している失敗事例のひとつが、2011年のQwikster分社化計画だ。DVDレンタルとストリーミングを別サービスとして分割するという判断は、ユーザー視点ではなく、社内の事業部門論理で設計された変更だった。 発表直後から激しいユーザーの反発が起き、サービス解約件数が急増した。Netflixは30日以内に計画を撤回した。このエピソードが示すのは、どれほど組織内部の論理が合理的に見えても、ユーザーの生活文脈に合わない変更は受け入れられないという事実だ。 ワークショップ経験者が「わかる」と頷くのは、この「組織内の合理性とユーザーの文脈の乖離」が、あらゆるプロジェクトで繰り返されるパターンだという点だ。Qwikster失敗の本質は、ステークホルダーインタビューや事前のユーザーテストを経ずに大規模な変更を実施したことにある。 --- デザイン思考の文化的定着：数千件のA/Bテスト体制 現在のNetflixは、ある時点で数百のA/Bテストを同時並行で実施していると複数の元社員が証言している（Lenny Rachitsky のブログ "Lenny's Newsletter" 2023年インタビュー等）。これは単なる技術的な取り組みではなく、組織文化の問題だ。 「正解を事前に決めない」「データが意思決定を主導する」「失敗テストも学びとして記録する」——これらの原則は、デザイン思考のマインドセットと完全に一致する。Netflixが「テクノロジー企業」である前に「ユーザー体験企業」として機能できるのは、この文化的な基盤があるからだ。 重要なのは、Netflixが最初からこの文化を持っていたわけではないという点だ。 2007年の転換、2011年のQwikster失敗、2013年以降のデータ活用強化——失敗と学習の蓄積が、現在の文化を作り上げた。これはデザイン思考の組織導入が、一度の研修で完成するものではなく、反復的な実践の積み重ねであることを証明している。 --- NetflixのデザインThinkingから学べること まず「問いを変える」判断の重要性だ。「DVDをどう改善するか」から「すぐに見られるとはどういうことか」への転換は、問題定義の再設計そのものだ。既存の事業モデルに縛られない問いの立て方が、不連続なイノベーションを生む。 次にテストを文化として設計することだ。個別のプロジェクトでテストを実施するのではなく、テストすることが意思決定プロセスの標準として組み込まれた体制を作ることが、Netflixモデルの核心だ。 最後に失敗を学習資産として扱うシステムだ。Qwikster失敗は、Netflixの歴史上最も費用対効果の高い学習だったと言えるかもしれない。失敗を隠さず、そこから得たインサイトを次の意思決定に活かす組織的な仕組みが、長期的なイノベーション能力を支える。 --- 参考文献 - Amatriain, X., & Basilico, J. (2012). Netflix Recommendations: Beyond the 5 Stars. Netflix Technology Blog. https://netflixtechblog.com/netflix-recommendations-beyond-the-5-stars-part-1-55838468f429 - Gomez-Uribe, C. A., & Hunt, N. (2016). The Netflix Recommender System: Algorithms, Business Value, and Innovation. ACM Transactions on Management Information Systems, 6(4), 1-19. https://dl.acm.org/doi/10.1145/2843948 - Rachitsky, L. (2023). How Netflix builds a culture of excellence. Lenny's Newsletter. https://www.lennysnewsletter.com/p/how-netflix-builds-a-culture-of-excellence - Hastings, R., & Meyer, E. (2020). No Rules Rules: Netflix and the Culture of Reinvention. Penguin Press. — Netflix文化の根幹を創業者自身が解説した一次資料 - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. — 企業のデザイン思考実践の標準的参照枠組み --- ### P&G × Roger Martin：デザイン思考で企業を変えた10年の実験 URL: https://designthinking.studio/articles/case-pg-design-thinking/ > A.G. LafleyとRoger Martinが2000年代のP&Gで実践した「デザイン思考による経営変革」の具体的経緯と成果を解説。消費者を中心に据えた意思決定プロセスと統合的思考が、世界最大の消費財企業をどう変えたかを事例から分析する。 「消費者こそがボスだ（Consumer is Boss）」——A.G. Lafleyが2000年にP&G（Procter & Gamble）のCEOに就任した直後に掲げたこの言葉は、単なるスローガンではなかった。それは組織の意思決定プロセスを根本から書き換える宣言だった。 P&Gが2000年代に実践した変革は、デザイン思考の教科書的な事例として繰り返し参照される。しかしその核心は「デザインをカッコよくした」という話ではない。ロジカルシンキングとクリエイティブシンキングを統合する「デザイン思考」を、経営の中枢に組み込んだ構造変革だ。 このプロセスを支えたのが、Rotman School of Management（トロント大学）のDeanであったRoger Martinとの長期的な協働関係だった。 --- 2000年：LafleyとMartinが出会ったとき 前任のCEOが突然辞任した後、A.G. Lafleyは2000年6月にP&GのCEOに就任した。当時のP&Gは株価が低迷し、組織は内向きになっていた。市場には積極的に参入しながらも、ユーザーの変化に鈍感という矛盾を抱えていた。 Roger Martin は Rotman School of Management の学長（在任1998〜2013年）であり、「対立する考えを同時に保ち、より優れた第三の解を生み出す」という「統合的思考（Integrative Thinking）」の理論を構築していた。 Lafleyは就任直後からMartinをアドバイザーとして招き、P&Gの意思決定プロセスに統合的思考の概念を持ち込んだ。この協働関係はLafleyの在任中（2000〜2010年）ずっと続いた。Martinは2007年に著した『The Opposable Mind』の中で、Lafleyを統合的思考の代表的実践者として取り上げている。 --- 統合的思考とデザイン思考の交差点 Martinの提唱する統合的思考は、デザイン思考の定義フェーズと深くつながっている。 通常の経営判断では、「コスト削減か品質向上か」「スピードか精度か」というように、対立する選択肢から片方を選ぶ。これは「分析的思考」の枠組みだ。 統合的思考では、その対立そのものを問い直す。「なぜこの2つがトレードオフだと思い込んでいるのか」を問い、両方を統合する第三の解を探す。 デザイン思考の定義フェーズでいう「問いの再構成（Reframing）」と構造的に同じだ。ユーザーが直面している問題の根本に立ち返り、前提ごと問い直すことで、既存の選択肢に縛られない解を見つけ出す。 P&Gでは、この思考様式が製品開発の会議から戦略立案の場まで組織に浸透した。「どちらの案がより良いか」ではなく「なぜこの2案しかないと思っているのか」という問いが、意思決定の標準になっていった。 --- "Consumer is Boss" の実装：共感フェーズを組織に埋める Lafleyの「Consumer is Boss」は、デザイン思考の共感フェーズを経営戦略に組み込む宣言だった。 具体的な変化として目立つのは、P&GがConsumer & Market Knowledge（CMK）部門を大幅に強化したことだ。ユーザーリサーチを「マーケティングの補助業務」から「意思決定のインプット源」へと位置づけを変えた。Lafleyは社内の会議で、開発チームやマーケティングチームが現場に出て消費者と直接接することを繰り返し求めた。 もうひとつの具体例が「First Moment of Truth（FMOT）」という概念の提唱だ。P&Gはこの時期、消費者がスーパーマーケットの棚の前に立ち、商品を手に取るかどうか判断するその瞬間を「真実の第一瞬間」と定義した。数十秒のこの判断が購買行動を左右するという洞察から、パッケージデザインと棚での陳列方法を根本から見直した。 「Second Moment of Truth（SMOT）」は実際に製品を使う瞬間だ。この2つの「真実の瞬間」というフレームワークは、ユーザー体験の観察から得られた洞察をプロダクト設計に還元するデザイン思考のプロセスそのものだ。 --- Connect + Develop：オープンイノベーションとしての協創 P&Gが2001年頃から本格化させた「Connect + Develop（C+D）」プログラムは、デザイン思考の共感フェーズを組織の外にまで拡張した試みとして読める。 従来のP&Gは、R&Dを完全に社内でクローズドに行う方針だった。Lafleyはこれを変え、全イノベーションの50%を社外からの技術・アイデアの取り込みで生み出すという目標を掲げた。 C+Dの仕組みは、大学・スタートアップ・個人発明家・他業種企業から技術やアイデアを募り、P&Gが商品化するというモデルだ。単に「外部委託」するのではなく、外部の視点そのものをP&Gのイノベーションに統合する共創モデルだった。 このアプローチは、デザイン思考が重視する「ユーザー・専門家・多様なステークホルダーとの共感的対話」の組織規模への応用だと言える。P&Gが自社の枠の外にある知識と経験を「共感すべき対象」として扱ったことが、C+Dの成功の鍵だった。 --- IDEOとの協業：デザイン思考の実践的補強 P&Gとデザインコンサルティングファーム IDEOの協業も、この時期のP&Gのデザイン思考化を支えた要素のひとつだ。IDEOはHuman-Centered Designの実践を核に持つ組織であり、P&Gとは複数のプロジェクトで協力関係を持った。 IDEOとの協業が示すのは、P&Gが「デザイン」を自社内で完結させず、専門的な外部の視点を積極的に取り込む姿勢を持ったということだ。これはC+Dの論理と同根だ。 --- 「Playing to Win」：戦略とデザイン思考の統合 Lafleyの退任後、彼とRoger Martinは2013年に共著『Playing to Win: How Strategy Really Works』（Harvard Business Review Press）を出版した。 この本の中心的なメッセージは「戦略とは選択だ」というシンプルなものだ。しかしその選択のプロセスが、デザイン思考と深く結びついている。 著者たちは「Where to Play（どこで戦うか）」と「How to Win（どう勝つか）」という2つの選択を戦略の核に置いた。この2つの問いは、デザイン思考の「問いの立て方」と構造的に同じだ。「どの市場で競争するか」という前提を問い直し、「その市場でユーザーが本当に求めているもの」を再定義することで、戦略の選択肢を広げる。 P&Gの実践は、デザイン思考が「プロダクトのUX改善ツール」ではなく、事業戦略の意思決定プロセスそのものを変える枠組みであることを示している。 --- Roger Martinが言語化した「The Design of Business」 2009年にMartinが刊行した『The Design of Business: Why Design Thinking is the Next Competitive Advantage』（Harvard Business Review Press）は、P&Gとの協働から得た洞察を理論として体系化した一冊だ。 Martinはこの本で、企業が知識を生み出すプロセスを「知識のファネル（Knowledge Funnel）」として図式化した。謎（Mystery）→ヒューリスティクス（Heuristic）→アルゴリズム（Algorithm）という流れで、人間の知識は曖昧なものから効率化されたシステムへと変換される。 デザイン思考が重要なのは、このファネルの入口、つまりまだ答えのない「謎」の段階に踏み込む姿勢と方法論を持っているからだとMartinは主張する。多くの企業はアルゴリズム（効率化・最適化）の段階に留まり、新しい謎に踏み込むことを避ける。P&Gが2000年代に行ったのは、謎の段階に積極的に踏み込み、そこから新しいヒューリスティクスを作り出す実践だったと読める。 --- P&G事例が示す3つの学び デザイン思考は「ツール」ではなく「思考の枠組み」だ。 P&GはIDEOのワークショップを実施したからデザイン思考を実践したのではない。組織の意思決定プロセスにユーザー視点を組み込む文化的変革が本質だった。 外部との協創は「弱さ」ではない。 C+DもIDEOとの協業も、P&Gが「社外の知恵が必要だ」と認めることから始まった。これはデザイン思考が教えるオープンマインドネスの経営版だ。 戦略とデザインの境界を壊すこと——これがLafleyとRoger Martinの実践が示した核心だ。「戦略はロジカルに、デザインはクリエイティブに」という分離が、多くの組織でデザイン思考の影響を表面的なUX改善に留める。この境界を取り除いたときに何が起きるか、P&Gの10年がひとつの答えだ。 --- 参考文献 - Martin, R. (2009). The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business Review Press. - Martin, R. (2007). The Opposable Mind: Winning Through Integrative Thinking. Harvard Business School Press. - Lafley, A.G., & Martin, R. (2013). Playing to Win: How Strategy Really Works. Harvard Business Review Press. - Huston, L., & Sakkab, N. (2006). Connect and Develop: Inside Procter & Gamble's New Model for Innovation. Harvard Business Review, 84(3), 58–66. — C+Dプログラムの設計思想を執行役員自身が解説した一次資料 - Brown, T. (2009). Change by Design. HarperBusiness. — デザイン思考の企業実践における標準的参照枠 --- ### POV文（Point of View文）の作成ガイド — デザイン思考 問題定義を完結させる書き方 URL: https://designthinking.studio/articles/pov-statement-guide-design-thinking/ > デザイン思考のdefineフェーズで使うPOV文（Point of View文）の書き方を、テンプレートと実例で解説。「ユーザー×ニーズ×インサイト」の3要素で問題定義を完結させる実践ガイド。 共感フェーズで大量のインタビューデータを集めた後、チームは途方に暮れることが多い。「何がわかったのか」「何を解くべきなのか」——ここで問題定義を怠ると、数週間の調査が「なんとなく参考になった話」で終わる。POV文（Point of View文）は、インサイトを「解くべき問題の宣言」に変換する技術だ。 --- POV文とは何か POV文（Point of View文）は、スタンフォードd.schoolが体系化した問題定義ステートメントだ。デザイン思考のdefineフェーズにおいて、共感フェーズで得た観察データを「チームが向かうべき問いの宣言」として凝縮する。 d.schoolの定義では、POV文は以下の3要素で構成される。 [ユーザー] は [ニーズ] が必要である。なぜなら [インサイト] だから。 この3要素が揃わない問題定義は、HMW（How Might We）の問いを立てるときに迷子になる。「インサイト」が抜けた状態でHMWを書くと、解決策が「当たり前の改善」に収束してしまうのが典型的な失敗パターンだ。 --- なぜPOV文が必要なのか 問題：インサイトが「感想」で終わる ワークショップでよく起こるのは、インタビューのデータが「Aさんは忙しそうだった」「Bさんはアプリをあまり使っていなかった」という観察の羅列で終わるケースだ。観察事実は集まっても、そこから「なぜそうなのか」という解釈（インサイト）まで踏み込まないと、問題定義に使えない。 実際にやってみると、チームでポストイットを並べた後に「で、何が問題なの？」という問いで全員が沈黙する瞬間が訪れる。これは調査の失敗ではなく、観察からインサイトへの変換を省略したことが原因だ。 共感：「問いの合意」なしにアイデア出しが始まる 参加者からの声として多いのは「アイデア出しで全員がバラバラな方向を向いていた」という振り返りだ。Aさんは「UIをシンプルにする」、Bさんは「サポート体制を強化する」、Cさんは「機能を削る」——それぞれのアイデアが別の問いに答えている状況が生まれる。 問いの合意がないままアイデア発散を始めることが、収束不能なブレストの構造的原因だ。POV文はアイデア出し前にチームの問いを一本に絞る役割を担う。 --- POV文の3要素を理解する 要素1：ユーザー（User） 具体的な一人のユーザーを記述する。ペルソナの属性のリストではなく、「観察した実際のユーザー」または「複数の観察を統合した典型像」だ。 NG例：「30代のビジネスパーソン」（属性のみ、具体性ゼロ） OK例：「新しいプロジェクト管理ツールを導入したばかりの中堅企業の人事担当者」（文脈と状況を含む） スタンフォードd.schoolの実践では、ユーザーを記述する際に「インタビューで出会ったあの人」として一人に固有名詞を与える演習が行われる。「ユーザー全般」ではなく「あの人の問題」として向き合うことで、問いの解像度が上がる。 要素2：ニーズ（Need） ユーザーが「本当に達成したいこと」を動詞で表現する。ここで注意が必要なのは、ニーズはソリューションを含まない点だ。 NG例：「アプリの通知設定を変更したい」（ソリューション前提） OK例：「重要なタスクを忘れずにこなした感覚を持ちたい」（達成したい状態） 実際にやってみると、最初の「ニーズ」にはソリューションが混入していることが多い。「〜を使いたい」「〜できるようにしたい」という表現がソリューション混入のサインだ。「〜を感じたい」「〜でありたい」という感情・状態の表現に変換することで、ニーズの純度が上がる。 要素3：インサイト（Insight） 最も難しいのがインサイトの抽出だ。インサイトとは、観察事実の背後にある「なぜそうなのか」という驚きのある解釈だ。 観察事実（データ）：「ユーザーはリマインダー通知が来ても確認しないことが多い」 インサイト（解釈）：「通知は情報の到達を保証するが、行動への移行を保証しない。ユーザーは『見た』ことと『やった』ことの間に明確な区切りを求めている」 インサイトは「なるほど、だからそうなるのか」という腑に落ちる感覚を引き起こす。表面的な観察を解釈したとき、「そうか、そういうことか」という感覚が起きないなら、まだ観察止まりだ。 --- POV文の書き方：ステップバイステップ ステップ1：観察データを並べる（10分） インタビューや観察で得たデータをポストイットに書き出す。この段階では解釈せず、「見た・聞いた」事実のみを記録する。 ステップ2：ニーズの候補を動詞で書く（15分） 「このユーザーは本当に何を達成したいのか」を5〜10個列挙する。ソリューションが混入しているものは「状態・感情」の言葉に変換する。 ステップ3：インサイトを1行で書く（20〜30分） 「なぜそのニーズが満たされていないのか」を解釈する。「しかしながら（but）」「なぜなら（because）」「驚くことに（surprisingly）」で始まる文を試みると、インサイトらしい解釈が出やすい。 しかしながら、〇〇という状況がそれを妨げている なぜなら、ユーザーは〇〇という前提で動いているから 驚くことに、ユーザーは〇〇を求めているのではなく〇〇を求めていた ステップ4：3要素を組み合わせてPOV文を書く（10分） テンプレートに当てはめて文として成立させる。 [ユーザー] は [ニーズ] が必要である。なぜなら [インサイト] だから。 完成したPOV文を声に出して読む。「この問題を解くチームに自分はなりたいか」という感覚が起きれば、問いに引力がある。感覚が薄ければ、インサイトの掘り下げが不足している可能性が高い。 ステップ5：HMWに変換して確認する（5分） 良いPOV文は、自然にHMWへと変換できる。変換が難しいと感じる場合、POV文のどこかに曖昧さが残っている。 POV文： 「新しいツールを導入した人事担当者は、変更への抵抗なくチームに使い続けさせたい。なぜなら、ツールの価値はチーム全員が使い始めて初めて発現するものだと認識しているから」 HMW： 「どうすれば、チームメンバーが抵抗感なく新しいツールを使い始める体験を設計できるか？」 --- よくある失敗パターンと対策 失敗1：POV文が「ソリューションの言い訳」になる 「（ユーザーの名前）は、私たちのソリューションを使う必要がある。なぜなら〜」という形になっているケースが多い。これはPOV文ではなく、プレゼンの正当化だ。 対策： ユーザーのニーズを書いた後、「もし私たちのソリューションが存在しないとしても、このニーズは残るか？」と問う。残るなら本物のニーズだ。 失敗2：インサイトが「調査の要約」になる 「ユーザーは忙しいから〜」「ユーザーはITが苦手だから〜」という記述は、インサイトではなく属性の説明だ。 対策： 「この事実は他のプロジェクトでも言える普遍的なものか」を確認する。普遍的なら差別化のないインサイトだ。このユーザーの文脈でのみ成立する特異な解釈こそが良いインサイトになる。 失敗3：チームで合意形成なしに一人が書く POV文をファシリテーターが一人で書いてチームに配布するケースがある。形式は整うが、チームの「問いへのオーナーシップ」が失われる。 対策： POV文はチームで書く。複数のPOV文候補を書き出し、投票と対話で一本に絞るプロセスが重要だ。このプロセスで「私たちは何を解くチームなのか」という共通認識が生まれる。 --- POV文の実例：ワークショップ3シーン シーン1：医療機関のデジタル化プロジェクト 観察： 看護師が電子カルテを更新するのは、患者の部屋を出た廊下のナースステーションでまとめて行う。患者の前ではほとんど入力しない。 POV文： 「夜勤の病棟看護師は、患者との関係を損なわずに記録の正確性を保ちたい。なぜなら、スクリーンを見ながら患者と話すことは、患者に『機械に話しているようだ』という感覚を与えると彼女が知っているから」 HMW： 「どうすれば、患者の目の前でも記録行為が『ケアの一部』として受け取られる体験を設計できるか？」 シーン2：B2B SaaSのオンボーディング改善 観察： 導入3週間後にチャーンしたユーザーに話を聞くと、機能の「使い方がわからなかった」ではなく「何に使えばいいかわからなかった」が多かった。 POV文： 「導入初期の経営企画担当者は、このツールで自分たちが抱える問題を解けるかどうかを確信したい。なぜなら、使い方の理解より前に『これは自分たちの問題の道具か』という確信がないと操作を学ぼうとしないから」 HMW： 「どうすれば、初回ログインの体験が『使い方の学習』より前に『私の問題に効く』という確信を生み出せるか？」 シーン3：社内コミュニケーションツールの導入 観察： 全社展開したチャットツールで、マネージャー層だけ使用率が低い。デジタルツールへの拒否感は見られない。 POV文： 「中間管理職のマネージャーは、チームとのコミュニケーションの記録が残ることへの心理的安全を必要としている。なぜなら、テキスト化された自分の発言が文脈から切り取られて共有されるリスクを強く意識しているから」 HMW： 「どうすれば、テキストコミュニケーションの記録性がマネージャーにとって脅威ではなく資産として機能するか？」 --- POV文とHMWの連携：問いの設計全体像 POV文は単独で機能するのではなく、HMW（How Might We）とセットで問い設計を完成させる。 デザイン思考の問い設計は「POV文 → HMW → アイデア発散」の流れで進む。POV文が「解くべき問題の宣言」、HMWが「アイデアを引き出す問いの形式」、そしてアイデア発散で具体的な解決策の候補が生まれる。 実際にやってみると、POV文の解像度がそのままHMWの引力に変換されることがわかる。浅いPOV文からは「まあそうだよね」というHMWしか生まれない。深いインサイトのあるPOV文からは「これ、面白い問いだな」と感じるHMWが自然に出てくる。 --- やってみよう：POV文1本を書く 手元にインタビューデータがない場合でも、以下の練習から始められる。 練習1（5分）： 自分が最近不便を感じた体験を選ぶ。その体験を「ユーザー・ニーズ・インサイト」の3要素に分解してPOV文を書く。 練習2（15分）： 身近な人（家族・同僚）に5分インタビューして、一つの観察事実を深掘りする。「なぜそうしているのか」「どんな気持ちか」「何が理想か」を聞き、インサイトを抽出してPOV文を書く。 ポイント： 最初から「良いPOV文」を書こうとしない。3本書いて、チームで一番引力を感じる1本を選ぶプロセスがそのままファシリテーションの実践になる。 --- 関連コンテンツ - POV（Point of View）メソッド詳細 — POV文のフレームワーク全体構造 - 問題フレーミング・ワークショップ — HMWへの展開と90分ワークショップ設計 - 共感マップ — POV文に使えるインサイトを引き出す観察整理ツール --- ### SaaSオンボーディングのデザイン思考——Aha momentを設計する実務 URL: https://designthinking.studio/articles/design-thinking-saas-onboarding/ > SaaSプロダクトのオンボーディング設計にデザイン思考を適用する実践的手法。Time to Value の共感軸化、Activation funnel の failure points 特定、Slack・Figma・Notion・Linear の設計哲学から学ぶプロトタイピング戦略を解説する。 SaaSプロダクトのオンボーディング改善プロジェクトに呼ばれたとき、最初に見せてもらうのは大抵「ドロップオフ率のグラフ」です。サインアップから7日後の継続率が20%を切っている。30日後にはさらに半減している。この数値を改善したい——という依頼です。 ここで多くのチームが陥るのが、データと睨み合って「ステップ3で離脱が多いからボタンの色を変えよう」という表層的な施策に飛びつくことです。ドロップオフ率はどこで問題が起きているかを教えてくれますが、なぜそこで離脱するかは教えてくれません。 デザイン思考が威力を発揮するのはここです。オンボーディング設計の問題を「UXの最適化」ではなく「共感とプロトタイピングの課題」として捉え直すと、施策の方向が根本から変わります。 Aha moment の共感マップ ワークショップで「あなたのプロダクトのAha momentはいつですか」と聞くと、多くのPMが「○○機能を使ったとき」と機能の名前を答えます。これはAha momentを「機能の到達点」として定義しているPM側の視点であり、ユーザーの体験視点ではありません。 実際にやってみると分かるのですが、Aha momentはユーザーの「感情」であり「文脈」です。共感マップを使ってAha momentを定義し直す作業では、4象限のなかに「価値を実感した瞬間の体験」を配置します。「考えていること」の象限に入るのは「これ、いまの自分のチームでも使えるかも」という接続の瞬間であり、「感じていること」の象限に入るのは「あ、これがやりたかったことだ」という発見の感情です。 Figma の場合、「デザインを作れた瞬間」より「チームと共有してフィードバックを受けた瞬間」の方が価値の実感に近い。Figma がオンボーディングでコラボレーション機能の早期体験を促す設計をとっているのは、この洞察を裏付けています。 Time to Value という共感軸の定量化 SaaSオンボーディングの文脈では「Time to Value（TtV）」が共感軸を定量化する有力な指標です。TtVは「サインアップからAha momentに到達するまでの時間」として定義されます。 注意が必要なのは、TtVを計算するには「Aha momentをどのイベントで定義するか」が先に決まっていなければならないことです。行動ログで計測できるイベントをAha momentのプロキシとして使うことが多いですが、それが本当に「価値の実感」に対応しているかは共感調査で検証する必要があります。 実際にやってみると、インタビューで「どの瞬間に『使い続けよう』と思いましたか」と聞くと、行動ログのどのイベントにも対応しない「隙間の体験」が出てきます。「同僚に見せたら反応が良かったとき」「既存ツールからデータを移せたとき」など、計測されていない文脈の中にAha momentが隠れている。TtVの設計はこの共感調査と組み合わせて初めて意味を持ちます。 Activation funnel の failure points を掘る ワークショップで使うフレームは「failure points インタビュー」です。直近でオンボーディングを体験したユーザー（継続者・離脱者の両方）に対して、各ステップの体験を時系列で再構築するインタビューを行います。聞き方は「そのとき、頭の中で何を考えていましたか」という認知的な問いです。 参加者からの声として多いのは、「何をするかは分かった。でも、なぜこれをするかが分からなかった」というものです。Activation funnelの各ステップには「技術的な操作のハードル」と「文脈理解のハードル」の2種類があります。後者は画面設計だけでは解けません。 Notion のオンボーディングが「テンプレートギャラリーから始める」設計をとっているのは、文脈理解のハードルを下げる戦略です。一方 Linear はツールの説明に時間をかけず、すぐに「最初のIssueを作る」ところに誘導します。操作を通じて体験させることで「やっていることの意味」を後から理解させる設計です。「先に文脈を与える（Notion型）」か「先に体験を与える（Linear型）」かは、プロダクトの複雑性とターゲットユーザーのリテラシーによって変わります。 プロトタイピング：3層の検証アプローチ SaaSオンボーディングのプロトタイプは3つの層で検証します。 第1層：テンプレート選択フロー。サインアップ直後の分岐設計は、低忠実度のペーパープロトタイプから始められます。印刷した画面フローを前にユーザーを座らせ、「今どこにいるか分かりますか」「次に何をするか想像できますか」を口頭で確認します。 第2層：ツールチップの文言と配置。ツールチップは「説明」ではなく「行動促進」でなければなりません。「このボタンを押すと○○できます」より「まず○○してみましょう」という行動指示型の文言の方が次のアクション率を高めます。FigmaやMarvelのインタラクティブモックアップで思考発話法を使って検証します。 第3層：インタラクティブツアーの長さ。Slack がオンボーディングツアーをほぼ廃止して「使い始めれば分かる」設計に移行したのは、コア体験（メッセージを送る）が直感的に理解できるためです。複雑な設定が必要なプロダクトでは、ツアーよりチェックリスト型の「達成感設計」の方が機能することがあります。 Appcues、Pendo、WalkMeといったツールを使ってA/Bテストを設計するとき、テスト設計の前に「何を検証したいか」の仮説を共感調査から立てることが重要です。ユーザーの認知的なハードルを解消するための実験として設計する。この順序が守られないと、表面的な数値改善が積み重なるだけで根本的な離脱原因は解決されません。 やってみよう：オンボーディング共感調査の設計 最初のステップは「サインアップ後7日以内に離脱したユーザー3〜5名へのインタビュー」です。インタビューの核心の問いは「サインアップしてから、プロダクトを使うのをやめた日まで、何をしていたかを教えてください」です。時系列の再構築を依頼し、各ステップで「そのとき何を考えていたか」「何が期待通りでなかったか」を掘ります。 この調査で最も重要なのは、「何を改善すれば良いか」をユーザーに聞かないことです。彼らが持っているのは「体験の記憶」と「そのときの感情」です。その記憶を引き出すことがデザイン思考の共感フェーズであり、「Activation funnelのどこにどんな認知的ハードルがあるか」を分析するのが定義フェーズの仕事です。 数値が教えてくれるのは「どこで」です。ユーザーが教えてくれるのは「なぜ」です。この両方がそろって初めて、オンボーディング設計のプロトタイピングが意味を持ちます。 --- 参考文献 - Lincoln Murphy, Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue, Wiley, 2016 - Tim Brown, Change by Design, HarperBusiness, 2009 - Slack, "The Story Behind Slack's Rebranding", slack.com/blog（公開情報） - Figma, "How Figma's collaborative design changed the industry", figma.com（公開情報） - Notion, "Our Template Gallery", notion.so/templates（公開情報） - Appcues, "User Onboarding Academy", appcues.com（公開情報） --- ### Spotifyのデザイン思考 — ユーザー体験を進化させる仕組み URL: https://designthinking.studio/articles/case-spotify-design-thinking/ > スクワッドモデル・Spotifyデザインシステム・継続的なユーザーリサーチを軸に、Spotifyがどのようにデザイン思考をプロダクト開発に組み込んでいるかを解説。アジャイルとデザイン思考の統合事例。 Spotifyが世界で6億人以上のユーザーを持つ音楽ストリーミングサービスに成長した背景には、単なる技術的な優位性以上のものがあります。 継続的にユーザーの体験を進化させる組織的な仕組みと、それを支えるデザイン思考の文化 です。 Appleの優れたハードウェアエコシステム・AmazonのPrime会員基盤・Googleの検索技術という強力な競合がひしめく音楽ストリーミング市場で、Spotifyが差別化を維持し続けてきた理由の核心は、 「ユーザーが本当に何を求めているか」を継続的に発見し続ける能力 にあります。 Spotifyの組織設計：スクワッドモデル スクワッドとトライブの仕組み Spotifyの組織設計において最も広く知られているのが「スクワッドモデル」です。2012年にHenrik KnibergとAnders Ivarissonが発表したペーパー「Scaling Agile @ Spotify」で公開されたこのモデルは、 小規模・自律的・職能横断型のチーム（スクワッド）を基本単位とする組織設計 です。 スクワッドは6〜12名で構成され、プロダクトマネージャー・デザイナー・エンジニア・データアナリストが同じチームに属します。重要なのは、 デザイナーがチームの外側にいる「コンサルタント」ではなく、チームの内側にいる「共同開発者」として機能する という構造です。 デザイン思考の観点からこの構造を分析すると、共感・定義・発想・プロトタイプ・テストという5フェーズが、スクワッドの日常的な作業サイクルの中に組み込まれています。2週間のスプリントの中で、 ユーザーインタビュー（共感）→問題の整理（定義）→解決策の発案（発想）→プロトタイプ作成→ユーザーテスト というループが回ります。 デザイン組織：デザイナーとリサーチャーの配置 Spotifyのデザイン組織は2020年代に大幅に強化されました。Product Designer（UXデザイナー）・User Researcher・Design System Designer・Brand Designerという役職で構成されています。 特筆すべきは User Researcher（ユーザーリサーチャー）の配置 です。Spotifyは各製品領域（Discovery・Podcast・Creator・Premium体験など）にリサーチャーを配置し、継続的なユーザーリサーチを製品開発の標準プロセスとして組み込んでいます。「月に一度、実際のユーザーと話す」という習慣が、共感フェーズを一過性のイベントではなく継続的なプラクティスにしています。 ユーザー体験設計の実例：Discover Weekly 偶然の発見を設計する 2015年8月にリリースされた「Discover Weekly」は、Spotifyのプロダクト設計の哲学を象徴する機能です。毎週月曜日に更新される、そのユーザーだけのプレイリスト。 「まだ知らないが、好きになれる音楽を届ける」 という体験を、機械学習で実現したものです。 しかしDiscover Weeklyが示す最も重要な教訓は技術ではなく、 その機能が生まれた経緯 にあります。この機能の原型となったのは「Spotify Radio」というすでに存在していた機能でしたが、ユーザーにあまり使われていませんでした。 Spotifyのプロダクトチームが実施したユーザーリサーチで、繰り返し出てきたインサイトがありました。ユーザーが本当に欲しいのは「無限に続くラジオ」ではなく、「 自分のために誰かが選んでくれた感覚のある、有限のプレイリスト 」だったのです。「あなたのために選んだ30曲」という形式が「ランダムに流れ続ける」より深い関与を生む——このインサイトが、Discover Weeklyの設計に反映されました。 30分で試せるプロトタイプ Spotifyの内部では、Discover Weeklyがリリース前に ハッカソンのプロジェクトとして生まれた ことが知られています。エンジニアのChris JohnsonとCordelia McGovernが社内ハッカソンで作った粗削りなプロトタイプが、プロダクトチームの目に留まったのです。 このプロセスはデザイン思考のプロトタイプフェーズの本質を体現しています。完成品を作る前に、 「このアイデアが機能するかどうか」を最小コストで検証する ——ハッカソンというフォーマットがその実験場として機能しました。 Spotifyデザインシステム：一貫性と柔軟性の両立 Encore（アンコール）の役割 Spotifyは独自のデザインシステム「Encore」を運用しています。EncoreはSpotifyのすべての製品（iOS・Android・Desktop・Web・TV）で共通して使われるUIコンポーネント・デザイントークン・インタラクションパターンの集合体です。 デザインシステムがデザイン思考に与える影響は直接的です。 デザイナーがゼロから部品を作る必要がなくなることで、ユーザーリサーチと問題定義により多くの時間を使える ようになります。「どのボタンのサイズにするか」という実装の選択ではなく、「このユーザーのニーズを満たす最善の体験は何か」という本質的な問いに集中できます。 Encoreの設計原則の一つは「Inclusive by default（デフォルトで包括的）」です。アクセシビリティ・国際化対応・パフォーマンスが、デザインシステムのレベルで担保されることで、個々のスクワッドがアクセシビリティを後付けで考える必要がなくなります。 コンテキスト理解：「次の10億ユーザー」への設計 新興市場でのユーザーリサーチ Spotifyはインド・ブラジル・インドネシアなどの新興市場への展開において、深刻な課題に直面しました。北米・欧州のユーザーを前提に設計されたSpotifyのUXが、 低速回線・低スペック端末・データ通信コストに敏感なユーザー に向けて十分に機能しないという問題です。 Spotifyのチームはこれらの市場に実際に赴き、 現地のユーザーのコンテキストを観察するフィールドリサーチ を実施しました。200MBのモバイルデータしか持てないインドのユーザーが、楽曲をどのように選択・保存・共有しているかを観察することで、「データ節約モード」「オフライン再生の優先化」「軽量バージョン（Spotify Lite）」といった機能の必要性が明確になりました。 この一連のプロセスは、デザイン思考の共感フェーズが「本社のオフィスで行う作業」ではなく 「ユーザーのコンテキストの中に飛び込む作業」である ことを示す実例です。 Podcast投資とユーザーニーズの発見 Spotifyは2019年以降、Podcastへの積極的な投資（Gimlet Media・Anchor・The Ringer買収）を行いました。この戦略的決定の背景にも、 ユーザーデータとリサーチからの発見 があります。 Spotifyのユーザーデータ分析から、 Spotifyで音楽を聴くセッションとPodcastを聴くセッションが、同じユーザーの中で相補的に機能している パターンが見えていました。音楽は感情的な状態に合わせてアクティブに選ぶが、Podcastは「ながら聴き」の時間帯に消費される——この行動パターンの発見が、「Spotifyをオーディオ全体のプラットフォームにする」という戦略の土台になりました。 A/Bテスト文化：常に検証する 数千のA/Bテストが同時進行 Spotifyの開発文化の中核にある実践の一つが、 A/Bテストの日常化 です。Spotifyでは常時数千のA/Bテストが世界中のユーザーを対象に走っていると言われています。 ホームスクリーンのレイアウト変更・検索バーの配置・おすすめアーティストの表示枚数——これらすべてが ユーザーの行動データで検証されてから全ユーザーに展開されます。 この文化は、デザイン思考のテストフェーズが「一度やって終わり」ではなく、 継続的なサイクルとして組み込まれている ことを示しています。 A/Bテストの判断基準として使われる指標は「エンゲージメント」だけではありません。Spotifyは「長期的なユーザー幸福度（Long-term User Satisfaction）」を測るための独自指標を開発しており、短期的なクリック率の最大化が長期的なユーザー関係に悪影響を与えていないかを監視しています。 「破壊的なUX変更」のテスト 2023年、SpotifyはホームスクリーンUIの大幅な刷新を実施しました。この変更は事前に大規模なユーザーテストが行われ、 旧デザインと新デザインを数ヶ月間並行して走らせ、長期指標での優位性が確認されてから 全ユーザーに展開されました。 大規模なUIリニューアルで多くのサービスが「ユーザーの怒り」を経験しますが、Spotifyが大きな反発を受けにくい理由の一つは、この長期検証プロセスにあります。 「変更を加えてから検証する」ではなく「検証してから変更する」 という順序の徹底です。 チームコラボレーション：クリエイターとのCo-design アーティストツールの設計 Spotifyには「Spotify for Artists」というアーティスト向けの管理ツールがあります。このツールの設計プロセスでは、 実際の音楽アーティスト（特に中小規模のインディーアーティスト）が共同設計者（Co-designer）として参加 しています。 スタジオのエンジニアがリスニングデータをどう解釈するか・ツアーの準備中にどの情報が必要か・新曲リリース前にどんな分析が欲しいか——これらをアーティストとのワークショップで収集し、機能設計に反映するプロセスは、共感フェーズとプロトタイプ検証の組み合わせです。 まとめ：デザイン思考が組織に根付くとき Spotifyの事例が示す最も重要な教訓は、 デザイン思考は「プロセスの名称」ではなく「組織の動き方」だということです。 スクワッドという組織設計・継続的なユーザーリサーチ・デザインシステムによる基盤整備・A/Bテストの日常化——これらは個別に見れば組織設計・リサーチ・デザインエンジニアリング・データサイエンスの話ですが、全体として「ユーザーのニーズを継続的に発見して、反復的に改善する」というデザイン思考の本質が機能しています。 Spotifyが成長し続けられる理由は、「最初から正しい答えを持っていたから」ではありません。 「ユーザーから学び続け、方向を修正し続ける仕組みを持っているから」です。 それが組織化されたデザイン思考の真の価値です。 --- 参考文献 - Henrik Kniberg & Anders Ivarsson, "Scaling Agile @ Spotify," Spotify Labs, 2012 - Spotify Design, "Our Design Principles," design.spotify.com, 2020 - Glenn McDonald, "Spotify Discovery Week: Understanding the Algorithm," The Atlantic, August 2015 - Cliff Kuang & Robert Fabricant, User Friendly: How the Hidden Rules of Design Are Changing the Way We Live, Work, and Play, MCD, 2019 --- ### アブダクティブ推論とデザイン思考｜「まだない答え」を導く第三の論理 URL: https://designthinking.studio/articles/abductive-reasoning-design-thinking/ > 演繹・帰納とは異なる第三の推論形式「アブダクティブ推論」が、デザイン思考の認識論的基盤であることを解説。チャールズ・サンダース・パース、ナイジェル・クロス、ロジャー・マーティンの理論と、200回超のワークショップで見えた実践的な活用法を体系化する。 デザイン思考のワークショップで「なぜこれが正解なのか」という問いを立ててしまうと、たいてい行き詰まる。正解がまだ存在しない問いに対して、「正しさを証明しながら前進する」という論理のコードは機能しない。 デザイン思考が扱う問題の多くは、データを集めれば答えが導き出されるような性質ではない。ユーザーインタビューを重ねても、「だからこのサービスを設計すべき」という論理的必然性は出てこない。出てくるのは、「もしかしたらこういうことが問題なのかもしれない」という仮説の種だ。 この「種から仮説を育てる」推論形式に、アブダクティブ推論（Abductive Reasoning）という名前がある。デザイン思考の認識論的な基盤を理解したいなら、まずここから始める必要がある。 三つの推論形式と、デザインが使うもの 哲学者・論理学者のチャールズ・サンダース・パース（Charles Sanders Peirce, 1839–1914）は、人間の推論形式を三種類に分類した。 演繹（Deduction）は、前提から結論を論理的必然性をもって導く。「すべての人間は死ぬ（前提）→ ソクラテスは人間だ（前提）→ ゆえにソクラテスは死ぬ（結論）」が典型だ。前提が正しければ結論は必ず正しい。しかし新しい知識は何も生まれない。前提の中にすでに結論が含まれているからだ。 帰納（Induction）は、複数の事例から一般則を導く。「10人のユーザーが同じ箇所で詰まった→ この機能は分かりにくい」という推論だ。サンプル数が増えるほど確からしさが増すが、「100%の確証」は原理的に得られない。 そしてアブダクション（Abduction）。パースはこれを「最善の説明への推論（Inference to the Best Explanation）」と呼んだ。観察された事実を最もうまく説明する仮説を生成する推論だ。 パースの言葉を借りれば、「アブダクションは新しいアイデアを導入できる唯一の論理操作である」。演繹は知っていることを整理し、帰納は観察を一般化する。しかしアブダクションだけが「まだない何か」を思考に持ち込める。 ナイジェル・クロスが見た「デザイン的な知り方」 デザイン研究者のナイジェル・クロス（Nigel Cross）は1982年の論文 Designerly Ways of Knowing（Design Studies, Vol.3, No.4）で、「デザインの認識論は科学や人文学とは異なる第三の文化に属する」と論じた。 科学は自然世界を帰納的・演繹的に理解しようとする。人文学は人間の経験を解釈しようとする。デザインは、まだ存在しない人工物の世界を創造しようとする。この「まだない世界を構想する」営みに、アブダクティブな推論が不可欠だとクロスは指摘する。 クロスが「デザイン能力の核」として挙げた特性のひとつが「アブダクティブ思考・生産的思考（abductive/productive thinking）」だ。設計の問いには「あらかじめ存在する正解」がない。設計者は観察された事実から飛躍し、まだ存在しない可能性を投影し、その仮説を検証する。これはパースのアブダクションの構造と一致する。 ロジャー・マーティンの「ナレッジファネル」 ビジネス文脈でこの接続を明確に論じたのが、ロジャー・マーティン（Roger Martin）の『The Design of Business』（2009年, Harvard Business Review Press）だ。 マーティンはビジネスにおける知識の進化を「ナレッジファネル（Knowledge Funnel）」として描いた。問題は最初「ミステリー（Mystery）」として現れる。観察と推論を重ねて「ヒューリスティック（Heuristic）」になり、さらに精緻化されると「アルゴリズム（Algorithm）」になる。 マーティンが指摘したのは、多くのビジネスが「アルゴリズムの最適化」に集中するあまり、ミステリーに向かうためのアブダクティブな思考を失っているという構造的な問題だ。デザイン思考が競争優位の源泉になるのは、まだアルゴリズム化されていない問題——すなわちミステリー——に向かう能力を組織にもたらすからだという。 デザイン思考のどこにアブダクションがいるか この視点でデザイン思考の5フェーズを見ると、アブダクションが要所に埋め込まれていることが見えてくる。 共感（Empathize）フェーズでは、ユーザーの言動から「この人が本当に困っていることは何か」という仮説を形成する。観察事実から背後にある動機を読む推論——これはアブダクションだ。「10人が同じことを言った」という帰納ではなく、「この一つのエピソードが示す本質は何か」という問いが共感フェーズを推進する。 問題定義（Define）フェーズでは、収集した観察から「HMW（How Might We）」問いを設定する。インサイトから問いへの飛躍は、論理的必然性を持たない。ここには設計者の「最善の説明への賭け」——すなわちアブダクションがある。 アイデア創出（Ideate）フェーズでは、問いから解決のアイデアを生成する。「こうすればよいかもしれない」という仮説の生成はアブダクションの典型的な形式だ。 プロトタイプ（Prototype）・テスト（Test）フェーズは、アブダクティブに生成した仮説を検証する構造だ。仮説が外れれば新しい観察が得られ、再びアブダクションの材料になる。 デザイン思考の反復（イテレーション）は、「アブダクションで仮説を立て、検証で更新し、また仮説を立てる」サイクルとして読み解ける。 ジョン・コルコの「センスメイキング」論 デザイン研究者のジョン・コルコ（Jon Kolko）は論文 Abductive Thinking and Sensemaking: The Drivers of Design Synthesis（2010年）でこの関係をさらに深めた。 コルコの主張は、デザイン・シンセシス（研究から洞察を統合するプロセス）の本質はアブダクティブなセンスメイキングだというものだ。ユーザーリサーチで集めた膨大なデータ——インタビュー音声、観察メモ、写真、アーティファクト——は、並べただけでは何も語らない。デザイナーはこれを「操作・整理・取捨選択・フィルタリング」しながら、知識を生み出す。この操作の中核にあるのがアブダクション、すなわち「これらの観察を最もよく説明するパターンは何か」という問いへの応答だ。 ワークショップで体感するアブダクションの壁 200回を超えるワークショップで、何度も同じ場面に出くわす。参加者——特に分析畑のバックグラウンドを持つ人——が、インサイト統合のフェーズでぴたりと動けなくなる。 「データからは複数のことが読み取れる。どれが正解か分からない」。そう言って手が止まる。この詰まりには構造的な原因がある。「正解を選ぶ」という演繹的・帰納的な問いの立て方が、アブダクティブな問い——「いまのデータを最もよく説明する仮説はどれか」——とそもそも噛み合っていない。 ほどき方はシンプルだ。問いを差し替える。「どれが正しいか」ではなく「もし〇〇だとしたら、観察されたすべての事実を説明できるか」へ。これがアブダクションの問いの形だ。完璧な証拠を手にする前に、一歩踏み出す。それが「最善の説明への賭け」の実践的な意味になる。 アブダクションと「なぜ失敗するか」の関係 組織がデザイン思考を導入して失敗するパターンのひとつに、「インサイトが出てこない」という現象がある。これはアブダクティブな思考が機能していないサインだ。 データ収集（共感フェーズ）は丁寧に行われる。しかし「データから何かを言う」には、データが語りかけてくるものを受け取り、仮説へと跳ぶ動作がいる。この跳躍は、方法論の手順書には書けない。特定の観察事実から特定の仮説を機械的に導く規則ではないからだ。もしそんな規則が書けるなら、それはもう演繹か帰納で片付く問題だ。 「インサイトが出てこない」時には、「正解を探しているのではないか」という問いを立てる。正解を探しているとしたら、それは演繹の問いだ。今必要なのは「これらの観察を一番うまく説明できる仮説は何か」というアブダクションの問いに変えることだ。 不確実性を許容する訓練として アブダクティブ推論が使いこなせない最深の原因は、「間違えるかもしれない仮説を前に進める」ことへの心理的抵抗だ。 演繹は正しい前提から出発すれば確実な結論を保証する。帰納は十分なデータがあれば高確率の一般化を保証する。しかしアブダクションは、現時点で最も良い説明を選ぶだけで、それが「真実」だという保証はない。 これは弱点ではなく、設計という営みの本質的な性質だ。デザインが扱う問題——まだ定義されていない問題、まだ存在しない解——は、確実な前進を保証する論理では扱えない。アブダクションは「不確実性の中で最善の一手を打ち続ける」能力であり、デザイン思考が「不確実な問題への実践的応答」である根拠がここにある。 --- まとめ デザイン思考の「なぜこれが機能するのか」という問いへの答えのひとつが、アブダクティブ推論という認識論的基盤だ。パースが定式化し、クロスがデザインに接続し、マーティンがビジネス文脈に応用した——この系譜を理解すると、デザイン思考の手順書には書かれていない「なぜ共感からインサイトへの飛躍が必要なのか」が見えてくる。 「データが答えを教えてくれる」という前提は、デザイン思考が向き合う問題には通用しない。観察された事実を最善の方法で説明する仮説を立て、それを試し、また立てる——この反復こそが、まだない答えに近づく唯一の道だ。 参考文献 - Charles Sanders Peirce, Collected Papers of Charles Sanders Peirce, Harvard University Press, 1931–1958（アブダクションの原典） - Nigel Cross, "Designerly Ways of Knowing," Design Studies, Vol.3, No.4, 1982, pp.221–227 - Roger Martin, The Design of Business: Why Design Thinking is the Next Competitive Advantage, Harvard Business Review Press, 2009 - Jon Kolko, "Abductive Thinking and Sensemaking: The Drivers of Design Synthesis," Design Issues, Vol.26, No.1, Winter 2010 - Jon Kolko, Wicked Problems: Problems Worth Solving, Austin Center for Design, 2012 --- ### インクルーシブデザインとデザイン思考｜「誰かのための特別対応」から「全員のための設計」へ URL: https://designthinking.studio/articles/design-thinking-inclusive-design-accessibility/ > インクルーシブデザインをデザイン思考のプロセスに組み込む実践論。障害・年齢・文化的背景など多様なユーザー像を共感フェーズに組み込む手法、エクスクルージョンマッピング、エッジケース先行設計の考え方を解説する。 デザイン思考のワークショップで「ユーザーを想定してください」と言われたとき、多くのチームが思い浮かべるユーザー像には、ある共通した傾向があります。スマートフォンを使いこなし、日本語を母語とし、視覚や聴覚に支障がなく、標準的なサービス利用経験を持つ人——。 この暗黙のデフォルトユーザー像が、設計の「見えない壁」をつくります。 インクルーシブデザインとは、その壁を意識的に可視化し、解体するための設計思想です。「バリアフリー対応」や「アクセシビリティ改善」という事後的な補正ではなく、最初から多様なユーザー像を前提として組み込んだ設計——それがインクルーシブデザインのコアです。 --- なぜ「特別対応」思考が失敗するのか 多くの組織が「アクセシビリティ」に取り組む際、主流の設計が完成した後に「補正」を加えるアプローチをとります。ウェブサービスであれば、UI設計が完了した後でスクリーンリーダー対応を追加する。プロダクトであれば、設計が固まった後で「高齢者向けの使い方ガイド」を別途作成する。 この補正型アプローチが構造的に限界を持つ理由は、設計の前提そのものを問い直していないからです。補正は主流設計の周辺に「使えるようにする手段」を付け加えますが、「なぜその設計は特定のユーザーを排除するのか」という根本的な問いには答えません。 Kat Holmes（元Microsoftインクルーシブデザイン部門責任者、著書 Mismatch: How Inclusion Shapes Design, 2018年）が指摘するように、排除（Exclusion）は多くの場合、悪意から生まれるのではありません。設計者自身の身体的・文化的・経験的な「当たり前」を無批判に設計に持ち込むことから生まれます。 右利き向けのハサミを設計した人が左利きを排除しようとしたわけではない。しかし自分が右利きであることを意識せずに設計した結果、左利きのユーザーにとって使いにくい道具が生まれた——これがミスマッチの本質です。 --- エクスクルージョンマッピング：誰を除外しているかを可視化する Microsoftのインクルーシブデザインチームが開発した「エクスクルージョンマッピング」は、現在の設計がどのようなユーザーを排除しているかを構造的に可視化する手法です。 手順はシンプルです。 Step 1：主要なユーザーシナリオを1つ選ぶ。たとえば「アプリでチケットを予約する」というシナリオ。 Step 2：そのシナリオを実行する上で「難しくなる条件」を列挙する。 - 視覚的な情報が読めない（視覚障害、強い光の下での使用、眼鏡を忘れた） - 片手が使えない（腕の障害、荷物を持ちながら、子どもを抱っこしながら） - 音声が聞こえない・出せない（聴覚障害、騒音の中での使用、会議中） - 日本語が第一言語ではない（外国籍ユーザー、観光客） - デジタルサービスの利用経験が少ない（高齢者、スマートフォン初心者） Step 3：それぞれの「難しくなる条件」が当てはまるユーザーの規模を考える。 この工程で重要なのは、恒久的な障害だけでなく、一時的・状況的な制約を含めることです。Microsoftのフレームワーク（「インクルーシブデザイン・ツールキット」、公式サイト公開）は、制約を以下の3種類に分類します。 - 恒久的（Permanent）：四肢の障害、聴覚・視覚の恒久的な喪失 - 一時的（Temporary）：骨折、手術後の回復期、耳の感染症 - 状況的（Situational）：赤ちゃんを抱っこしながら片手が使えない、騒音の中にいる この3種類を合算すると、「特定のシナリオで制約を感じているユーザー」の規模が大きく見えてきます。片腕が恒久的に使えないユーザーの数は小さくても、「何かを持ちながら片手でスマートフォンを操作しているユーザー」の数は日常的に膨大です。 インクルーシブデザインが「全員のための設計」になる理由は、エッジケースへの対応が主流ユーザーの体験も改善するからです。 --- 共感フェーズへの統合：多様なユーザー像を起点にする デザイン思考の共感フェーズでは、ユーザーインタビューや観察によってユーザーの実態を理解します。インクルーシブデザインを統合するとは、この段階でインタビュー対象と観察対象の多様性を意図的に設計することです。 インタビュー対象の多様性設計 「主なユーザーを代表する人にインタビューする」という標準的なアプローチでは、暗黙のデフォルトユーザー像に近い人が選ばれがちです。インクルーシブデザインの視点では、インタビュー対象のリストを設計する段階で以下を意識します。 スペクトラムで考える：「障害の有無」という二値ではなく、「各機能の使いやすさ」をスペクトラムで捉えます。視覚情報の認識においては、完全な視力喪失から軽度の視力低下まで連続的なスペクトラムがあります。年齢においても、10代から80代まで連続的な変化があります。 エッジにいる人を積極的に含める：スペクトラムの両端に近いユーザーへのインタビューは、中間に位置するユーザーでは見えない課題と洞察をもたらします。d.school（Stanford d.school）では「極端なユーザー（Extreme Users）」という概念を用い、スペクトラムの端にいるユーザーへのインタビューを共感フェーズに意図的に組み込むことを推奨しています。 インタビューの問いへの応用 インクルーシブデザインの観点を組み込んだインタビューでは、以下のような問いが有効です。 「このサービスを使う上で、『できれば変えてほしい』と思っていることはありますか」 「このサービスを使う場面で、特に難しいと感じる状況はありますか（場所・タイミング・身体的な状態など）」 「このサービスをあなたと同じように使えない人が、身近にいると思いますか。それはどんな人ですか」 3つ目の問いは特に有効です。ユーザー自身に「排除されているかもしれない人」を想像してもらうことで、インタビュア自身が気づかなかったユーザー像が浮かび上がることがあります。 --- エッジケース先行設計：「例外」から始める発想 インクルーシブデザインをデザイン思考の創造フェーズ（アイデエーション）に統合する実践的な手法が、エッジケース先行設計です。 通常のアイデエーションでは「主なユーザーが最もよく使うシナリオ」からアイデアを発想します。エッジケース先行設計では、この順序を入れ替えます。 Step 1：最も制約の多いユーザーシナリオを定義する。 たとえば「スクリーンリーダーを使い、かつ片手のみ操作できる状態でのチケット予約」。 Step 2：このシナリオで機能するソリューションをアイデエーションする。 最も困難な条件下で動作するソリューションを先に発想することで、多くの制約に対してロバストなアイデアが生まれます。 Step 3：そのソリューションが標準ユーザーにとっても機能するかを確認する。 エッジケース向けのソリューションが標準ユーザーの体験も向上させるかどうかを検討します。多くの場合、「最も使いにくい状況」向けに設計されたソリューションは、標準的な状況でもより使いやすくなります。 この逆順の設計アプローチは、カーブカット効果（Curb Cut Effect）という社会現象の教訓と重なります。歩道の段差を車椅子ユーザーのために解消した段差切り下げは、乳母車・自転車・重い荷物を持つすべての人にとっての利便性を高めました。排除されていた人への対応が、全員の体験を改善した例です。 --- プロトタイプ・テストフェーズへの統合 インクルーシブデザインの観点をプロトタイプと検証フェーズに組み込む際の重要な実践ポイントを示します。 アクセシビリティチェックリストの活用：プロトタイプの評価段階で、WCAG（Web Content Accessibility Guidelines）2.1の4原則（知覚可能・操作可能・理解可能・堅牢）を評価軸に加えます。ウェブサービスの場合、ブラウザの開発者ツールやaxeなどの自動チェックツールで基本的な問題を早期に検出できます。 代表的なユーザーとエッジユーザーの両方でテストする：テストセッションの設計段階で、「主流ユーザーによるテスト」と「制約のあるシナリオを持つユーザーによるテスト」を明示的に分けて設定します。前者だけでは発見できない問題が後者で見えます。 ユーザビリティとアクセシビリティを混同しない：ユーザビリティ（使いやすさ）は主流ユーザーの体験の質に焦点があります。アクセシビリティ（アクセスできること）は多様なユーザーがサービスに到達できるかに焦点があります。両者は補完的であり、一方の改善がもう一方を損なう場合は、設計の前提に問題がある可能性があります。 --- 組織への定着：補正文化からの脱却 インクルーシブデザインの考え方をプロジェクト単位で実践するだけでなく、組織の設計プロセスに定着させるには、文化的な変容が必要です。 Kat Holmesが指摘する「補正文化（Correction Culture）」——主流設計が完成した後に少数者向けの補正を加える文化——を変えるには、プロセスの初期段階にインクルーシブな視点を組み込む構造的な変化が必要です。 具体的には、ユーザーストーリーやペルソナを作成する段階での「多様性チェック」の制度化、デザインレビューの評価基準へのインクルーシブデザイン観点の追加、そしてエッジユーザーとの定期的な接点（ユーザーテスト・共同設計ワークショップ）の定期化が有効です。 「誰かのための特別対応」から「全員のための設計」へ——このシフトは、デザイン思考が本来持つ「人間中心」の原則を、より広い人間の範囲に適用することに他なりません。共感フェーズの拡張として、インクルーシブデザインはデザイン思考の哲学と深く整合しています。 --- 参考文献 - Kat Holmes, Mismatch: How Inclusion Shapes Design, MIT Press, 2018 - Microsoft Inclusive Design Toolkit（公開資料: microsoft.com/design/inclusive/） - Don Norman, The Design of Everyday Things, Basic Books, 2013（邦訳: 岡本明他訳『誰のためのデザイン？』） - World Wide Web Consortium（W3C）, Web Content Accessibility Guidelines (WCAG) 2.1, 2018 --- ### インサイト統合の実践ガイド｜定義フェーズで「本当の問題」を見つける技術 URL: https://designthinking.studio/articles/design-thinking-insight-synthesis/ > デザイン思考の定義フェーズでインサイトを抽出・統合し、POVステートメントとHMWに落とし込む実践プロセスを解説。ワークショップで繰り返し起きる「ギャップの見えなさ」を克服する具体的手順。 「ユーザーインタビューを10人やった。付箋が300枚出た。でも、何がインサイトなのか分からない」——この行き詰まりは、デザイン思考の定義フェーズで最も頻繁に起きる問題です。 収集した情報を「整理した」と「統合してインサイトを見つけた」は、全く別の作業です。インサイト統合とは、バラバラなデータを並べ直すのではなく、「なぜそうなっているのか」という因果の解釈を生み出すプロセスです。このガイドでは、定義フェーズの実務的な進め方を、ワークショップの現場で繰り返し観察されるパターンを踏まえながら解説します。 「観察」と「インサイト」は別物である インサイト統合を学ぶ前に、最も重要な区別を確認しておきます。 観察（Observation）: ユーザーが実際に言ったこと・やったことの記録。「Aさんは、スマートフォンで地図を開く前にまず紙の地図を取り出した。」 インサイト（Insight）: 観察の背後にある動機・信念・矛盾の解釈。「紙の地図を取り出したのは、デジタル地図への不信感ではなく、まず全体像を把握してから詳細を確認するという認知スタイルの表れかもしれない。」 インサイトは観察から直接導けるものではありません。複数の観察を重ね合わせて初めて「見えてくる」ものです。KJ法（アフィニティダイアグラム）の発明者である川喜田二郎が強調したのは、既成のカテゴリーに当てはめるのではなく、データそのものに語らせることでした。 ワークショップでよく起こるのは、観察メモをグルーピングして「テーマ名」を付けた時点で「インサイトが出た」と思い込んでしまうパターンです。「移動に関する不満」というグループ名はテーマであって、インサイトではありません。インサイトは「なぜ不満が生まれているのか、その背景にある構造」を指します。 定義フェーズの全体プロセス インサイト統合は、以下の5段階で進みます。それぞれを順番に解説します。 - 生データの書き出し（Downloading） - パターンの発見（Clustering） - インサイトの言語化（Insight Framing） - POVステートメントの作成 - HMW（How Might We）への変換 --- ステップ1: 生データの書き出し（30〜45分） 共感フェーズで収集した情報を、1枚の付箋に1つの観察として書き出します。 書き方のルール: - ユーザーの行動・発言・感情を具体的に書く（主語を「◯◯さんは」にする） - 解釈・評価を加えない（「使いにくそうだった」ではなく「同じボタンを3回押していた」） - ユーザーへの共感の言葉ではなく、観察の事実を書く この段階で解釈を混ぜてしまうと、後工程でバイアスが固定されます。参加者からの声として多いのは「細かく書こうとすると時間がかかる」という感想です。ここで意識してほしいのは、1枚の付箋に詰め込もうとしないことです。1観察 = 1付箋。多くなりすぎることを恐れないでください。 ステップ2: パターンの発見（45〜60分） 書き出した付箋を壁に貼り、類似する観察を手で動かしながらグループを作ります。これがアフィニティダイアグラム（KJ法）の作業です。 進め方のポイント: - 無言で始める: 最初の5〜10分は会話なしで付箋を動かします。「この付箋、こっちじゃない?」の会話が始まると思考が言語化に引っ張られ、直感的なグルーピングが阻まれます - グループは3〜7枚が目安: 2枚だけのグループは後でどこかに統合できます。10枚以上になったらサブグループを作ります - グループ名は後付けにする: グループを先に決めてから付箋を当てはめると、当てはまらない観察が捨てられます。グループ名は「中に入っている付箋を見てから」付けます 実際にやってみると、直感的に「なんか近い気がする」で動かした付箋が、後からグループ名を考えると驚くほどきれいに意味をなすことがあります。逆に「テーマとして正しそう」という判断でグルーピングしたものが、見返すと意味がバラバラだったりする。手を動かすことが思考を深めるのです。 ステップ3: インサイトの言語化（45〜60分） 各グループを見ながら「なぜ」を問い続けます。このステップがインサイト統合の核心です。 インサイトを引き出す問いかけ: - 「このグループに共通するユーザーの動機は何か?」 - 「このパターンが繰り返し起きているのはなぜか?」 - 「このグループ内の観察の中で、最も驚いたものはどれか? なぜ驚いたのか?」 - 「このユーザー行動は、どんな信念・恐れ・習慣から来ているか?」 良いインサイトの特徴: 良いインサイトは「チームが知らなかった何か」を含みます。「ユーザーは説明書を読まない」は一般常識で、インサイトではありません。「ユーザーは説明書を読まないのではなく、最初の失敗体験から"この種の製品の説明書は役に立たない"という学習済みの信念を持っていて、意図的にスキップしている」はインサイトです。 インサイト文の書き方: 「ユーザーは◯◯をしている/しない。なぜなら、◯◯という信念・恐れ・矛盾を持っているからだ。」 インサイトと「面白い観察」を混同しない: 「70代の方がスマートフォンを両手の人差し指で打っているのが面白かった」は観察です。「70代のユーザーが両手で入力するのは、タッチ入力自体への信頼感のなさから生まれた過剰な確認行動であり、これはフィードバックの不明瞭さが原因かもしれない」はインサイトです。 ステップ4: POVステートメントの作成（30〜45分） インサイトを特定のユーザーに紐づけた問題定義文を書きます。d.school の形式は以下です。 [ユーザー] は [ニーズ] を必要としている。なぜなら、[インサイト] だからだ。 例: - 観察: 「Bさんは、クレジットカードの明細を確認するたびに、使った記憶のない金額の行を不安そうに調べていた」 - インサイト: 「小さな不確実な支出が積み重なることへの不安が、金融管理への動機より強く働いている」 - POV: 「Bさんのような家計管理に不安を感じる人は、支出の"意外性"を排除する仕組みを必要としている。なぜなら、知らないうちにお金が減るという感覚が管理への意欲を下げているからだ」 POVで陥りやすいミス: - 解決策を入れてしまう: 「通知機能が必要」など、HOWが混入するとPOVでなくなります - 具体的ユーザーが消える: 「一般的なユーザー」を対象にすると、インサイトが薄まります - 「〜したい」というウォンツをそのままニーズにする: ウォンツの背後にある深層ニーズに掘り下げます ステップ5: HMW（How Might We）への変換（20〜30分） POVを「どうすれば〜できるだろうか?」という形式の問いに変換します。この問いがIdeateフェーズの出発点になります。 先の例をHMWに変換すると: - 「どうすれば、支出の"意外性"を体験の前に知ることができるだろうか?」 - 「どうすれば、知らない支出が発生した瞬間にわかるようにできるだろうか?」 - 「どうすれば、家計管理への不安を"確認の楽しさ"に変えられるだろうか?」 HMWは1つのPOVから複数生成できます。「狭すぎず、広すぎない」範囲を意識してください。 「どうすれば家計管理全体を改善できるか?」は広すぎて、どこから始めるかわかりません。「どうすれば通知の色を決められるか?」は狭すぎて、創造的な解決策が生まれません。 定義フェーズで頻出する失敗パターン 失敗1: インタビューが終わった直後にアイデアを出し始める 参加者からの声として最も多いのが「インサイトを言語化する前に、自分たちがすでにアイデアを話し合っていた」というケースです。共感フェーズ後の興奮でIdeateに滑り込んでしまう。 対策: ワークショップの冒頭で「この時間はアイデアを出す場ではなく、問題を定義する場」と明示する。ホワイトボードに「今日はアイデア禁止」と書いてもよい。 失敗2: グルーピングを「テーマ別分類」で終わらせる 「使いやすさ」「価格」「デザイン」などのカテゴリ別に付箋を分けた時点で作業が止まるパターンです。これは「整理」であって「統合」ではありません。 対策: グルーピング後に必ず「このグループが存在するのはなぜか?」と問う時間を設ける。グループ名を書いた後、その下に「インサイト文」を書くセクションを用意しておくと構造的に強制できます。 失敗3: POVが全員に当てはまりすぎる 「すべてのユーザーは使いやすい製品を必要としている」のような POVは誰も否定できませんが、設計の指針にもなりません。 対策: 作成したPOVを「これは◯◯さん（インタビューした実在の人物）のことを正確に描写しているか?」と確認する。実在の人物に当てはまらなければ抽象化しすぎです。 失敗4: HMWが解決策になってしまう 「どうすれば通知機能を実装できるか?」という形のHMWは、すでに解決策（通知機能）を前提にしています。 対策: HMWに固有名詞の技術・機能・手段が入っていたら書き直す。「どうすれば〜できるか?」の主語が「ユーザーの体験」に向いているかを確認する。 インサイト統合のクオリティチェックリスト 定義フェーズが終わったタイミングで、以下を確認してください。 - [ ] インサイトに「チームが以前は知らなかった情報」が含まれているか - [ ] POVが特定のユーザーに紐づいているか（「一般的なユーザー」になっていないか） - [ ] POVに解決策が混入していないか - [ ] HMWが広すぎず、狭すぎない範囲か - [ ] チーム全員がPOVを読んで「これを解きたい」という手応えを感じているか 最後のチェックを軽視しがちですが、定義した問いに「解きたい感」がなければ、Ideateフェーズで本気のアイデアは出てきません。問いの質が、その後のプロセス全体の質を決めます。 やってみよう 次のワークショップで試せる最小実践を紹介します。 インタビュー後、まず 10分間の「観察書き出し」 を個人作業でやってみてください。この間は「インサイト」「アイデア」という言葉を使わず、ひたすら「◯◯さんは何をしたか、何を言ったか」を書く。 その後で 「なぜリスト」 を作ります。書き出した観察のうち「最も驚いた3つ」を選び、「なぜそうなったのか」を3回問い続けます（5 Whys の短縮版）。この2ステップだけで、インサイトの解像度が明確に上がります。 関連項目 - 問題定義フェーズ - アフィニティダイアグラム - How Might We（HMW） - Point of View - ユーザーインタビュー - エンパシーマッピング --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018 - Voltage Control, "Mastering Synthesis and Insight Generation", voltagecontrol.com - Interaction Design Foundation, "Stage 2 in the Design Thinking Process: Define the Problem by Synthesising Information", interaction-design.org --- ### カスタマージャーニーマップ実践ガイド｜作り方・使い方・よくある失敗 URL: https://designthinking.studio/articles/customer-journey-map-practice-guide/ > カスタマージャーニーマップ（CJM）の作り方を実践的に解説。ペルソナ設定からタッチポイント特定・感情曲線の描き方・インサイト抽出まで、ワークショップ現場の知見を体系化。よくある失敗パターンと対策も網羅。 「ペルソナは作った。でもそれだけだと、次に何をすればいいか分からない」——デザイン思考の初期学習者から、この声を繰り返し聞く。 ペルソナは「誰」を描いたものだ。しかし「その誰かが、どんな体験を経ているか」を時間軸で可視化する手法が、カスタマージャーニーマップ（Customer Journey Map、以下CJM）だ。ペルソナがキャラクターのスナップ写真だとすれば、CJMはそのキャラクターの一日を記録したドキュメンタリーフィルムに相当する。 CJMを作ることで、チームは「自分たちの製品やサービスをユーザーがどう体験しているか」を共通の地図として持てるようになる。組織の各部門が「自分のタッチポイント」だけを見ていた視野が、ユーザーの体験全体に広がる。 --- なぜカスタマージャーニーマップが必要か 参加者からの声として最も多いのは、「部門間での顧客理解のズレ」だ。マーケティング部門は「広告で見込み客を獲得する場面」を、カスタマーサポート部門は「問題が起きた場面」を、開発部門は「機能を使う場面」を、それぞれ断片的に把握している。しかしユーザーはこれらを連続した1つの体験として経験している。 CJMは、この断片を繋ぎ合わせる地図だ。マーケティングの接点→購入の意思決定→初回利用→継続利用→問題発生→解決→継続または離脱——このストーリーラインを1枚のマップに描くことで、組織全体が同じ「ユーザーの旅」を共有できる。 UIやサービス設計の改善施策が「局所最適」に陥るのは、多くの場合、体験全体を見ていないからだ。 購入フローのUIをどれだけ改善しても、その前後の体験が問題を抱えていれば離脱率は下がらない。CJMは、施策の投資対効果を正しく評価するための文脈地図でもある。 --- CJMの構成要素 ペルソナ CJMは必ず「誰の旅か」を特定することから始まる。ペルソナが複数存在する場合、CJMも複数作る必要がある。異なるユーザーは、全く異なる旅をしているからだ。 1枚のCJMに「全ユーザーの体験」を詰め込もうとすることが最初の失敗パターンだ。「典型的なユーザー」という概念が実在しない場合、「複数のユーザーの平均値」のマップは誰の体験も正確に表さない。 まず最も代表的なペルソナ1人のCJMを完成させ、次に別のペルソナへと展開するアプローチが実践的だ。 ステージ（フェーズ） ユーザーの旅を、時間軸に沿った段階に分割する。一般的な構成例は「認知→検討→購入→利用→サポート→推奨」だが、これは業種・サービスによって大きく異なる。 重要なのは、「企業の視点のステージ」ではなく「ユーザーの視点のステージ」で分割することだ。「マーケティングフェーズ」「セールスフェーズ」「カスタマーサクセスフェーズ」は組織の都合による区分であり、ユーザーは「今自分はどのフェーズにいるか」などと考えながら行動していない。 タッチポイント 各ステージにおいて、ユーザーがサービス・製品・組織と接する接点のすべてがタッチポイントだ。ウェブサイト・広告・店頭・メール・SNS・カスタマーサポートの電話・パッケージ——オンラインとオフラインを問わず、全ての接点を洗い出す。 実際にやってみると、自分たちが把握していなかったタッチポイントが必ず出てくる。 ユーザーが「商品の箱を捨てる瞬間」や「友人に使い方を聞く場面」は、サービス提供者がコントロールできないタッチポイントだが、ユーザー体験には大きな影響を与える。これらの「非コントロール接点」を可視化することが、CJMを作る重要な目的のひとつだ。 感情曲線 各タッチポイントにおけるユーザーの感情状態を、ポジティブ（快）からネガティブ（不快）のスケールで折れ線グラフとして描く。これが「感情曲線（Emotional Journey）」だ。 感情曲線の谷（ネガティブのピーク）が、改善の優先候補を示す。 機能的な問題がなくても、感情的な体験が悪い場面は離脱や不満の温床になる。逆に感情曲線のピーク（最もポジティブな体験）は、ブランドの「感動ポイント」として強化すべき要素だ。 ユーザーの思考・行動・感情 各タッチポイントにおけるユーザーの「何を考えているか（Think）」「何をしているか（Do）」「何を感じているか（Feel）」を記載する。この3層の記述が、CJMを「集めたデータの整理」から「インサイトの地図」へと引き上げる。 --- CJMの作り方：6ステップ ステップ1: スコープを決める 「どのユーザーの、どの場面を、どの深さで描くか」を最初に合意する。全体の旅をざっくり描く「マクロCJM」と、特定のステージを詳細に描く「マイクロCJM」は用途が異なる。 初めてCJMを作るチームには、マクロCJMから始めることを勧める。全体像の共有が、次のステップで「どこを深掘りすべきか」の議論を生む。 ステップ2: ユーザーリサーチを実施する CJMは「作り手の想像」ではなく「ユーザーの現実」を描くものだ。ユーザーインタビュー・観察・アンケート・行動ログなど、実際のユーザーのデータに基づいて作ることが必須だ。 ワークショップでよく起こるのは、データ収集を省略して「想像でCJMを作り始める」パターンだ。これは「仮説マップ」として議論のたたき台にはなるが、投資判断や改善優先度の根拠には使えない。 仮説マップを作った後、必ずユーザーリサーチで検証するステップを設計に組み込む。 ステップ3: ステージとタッチポイントを洗い出す リサーチデータをもとに、ユーザーの旅のステージを設定し、各ステージのタッチポイントを網羅的に書き出す。付箋を使ったブレインストーミングが有効で、最初は多く出し、その後クラスタリングして整理する。 社内の複数部門から参加者を集めることが、タッチポイントの見落としを防ぐ。 マーケティング担当者は広告接点を、開発担当者はUI接点を、サポート担当者はトラブル接点を知っている。部門を超えたワークショップ形式がCJM作成の標準的アプローチだ。 ステップ4: 各タッチポイントの体験を描写する Think/Do/Feelの3層で、各タッチポイントにおけるユーザーの体験を記述する。できるだけ「ユーザー自身の言葉」を使う。インタビューで聞いた発言をそのまま引用すると、生々しいリアリティが生まれる。 ステップ5: 感情曲線を描く 各タッチポイントの感情状態を、-3（非常にネガティブ）から+3（非常にポジティブ）のスケールで評価し、折れ線グラフとして繋ぐ。この作業を複数のチームメンバーが独立して行い、後で比較すると、認識のズレが可視化される。 特に感情曲線が大きく落ちるポイントは「ペインポイント」として赤くマーキングし、改善の対象として優先度を付ける議論の基点にする。 ステップ6: インサイトと機会領域を抽出する 完成したCJMから、以下の観点でインサイトを抽出する。「最大のペインポイントはどこか」「最大のゲインポイント（感動体験）はどこか」「矛盾しているタッチポイントはどこか」「競合他社と体験が差別化できる機会はどこか」。 抽出されたインサイトはHow Might We（HMW）文に変換し、創造フェーズ（Ideation）への橋渡しとする。CJMを作りっぱなしにせず、改善のアクションアイテムに繋げることが最終ステップだ。 --- よくある失敗パターン4つ 想像だけで作るCJM。 リサーチなしに「こういう体験をしているはずだ」という仮説で作られたCJMは、組織内の共通認識形成には使えても、意思決定の根拠にはならない。「仮説マップ」と明示した上で使い、必ず検証プロセスを設ける。 全員を一枚に詰め込む。 異なるユーザーセグメントを1枚のCJMに統合しようとすると、「平均的なユーザー」という実在しない対象のマップが出来上がる。セグメント別に複数のCJMを作ることが、精度の高いインサイトへの近道だ。 作ったら終わりの「壁の飾り」。 ワークショップで大きな模造紙に作り上げたCJMが、会議室の壁に貼られたまま誰も参照しなくなるパターンは実に多い。CJMは「生きたドキュメント」として定期的に更新し、改善施策の評価指標と紐付けて管理することで初めて価値を発揮する。 感情曲線を主観で描く。 「うちのサービスはここが良い体験のはず」という思い込みで感情曲線を描くと、現実から大きく乖離したマップになる。ユーザーインタビューや行動ログなどの客観データに基づいて感情曲線を描くことが基本原則だ。 --- CJMをワークショップで使う 90分〜半日のワークショップでCJMを作るためのアジェンダ設計を示す。 0〜15分: ペルソナの確認と旅のスコープ合意。15〜30分: 各自がユーザーの旅を付箋に書き出す（個人作業）。30〜50分: 付箋のクラスタリングとステージ設定（グループ作業）。50〜65分: 各タッチポイントのThink/Do/Feel記述。65〜80分: 感情曲線の描写と合意形成。80〜90分: 主要インサイトと次のアクション確認。 初回ワークショップの目的は「完成形のCJMを作ること」ではなく、「チームが同じ地図を持つこと」だ。 80%の精度で合意された地図が、100%の精度を求めてストップしている地図より価値がある。 --- 参考文献 - Kalbach, J. (2016). Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams. O'Reilly Media. — CJMの実践的教科書として業界標準的リファレンス - Stickdorn, M., Lawrence, A., Hormess, M., & Schneider, J. (2018). This Is Service Design Doing. O'Reilly Media. — サービスデザインの文脈でのCJM活用手法を包括的に解説 - Temkin, B. D. (2010). Mapping The Customer Journey. Forrester Research. — 企業がCJMを使い始めた契機となった先駆的レポート - Nielsen Norman Group. (2020). Journey Mapping 101. https://www.nngroup.com/articles/journey-mapping-101/ — CJMの定義・構成要素・活用シーンを権威ある機関が整理した参照資料 - Kolko, J. (2011). Exposing the Magic of Design: A Practitioner's Guide to the Methods and Theory of Synthesis. Oxford University Press. — デザイン思考のツールとしてのマッピング手法の理論的背景 --- ### クロスファンクショナルチームでデザイン思考を回す——部門横断プロジェクトの実践ガイド URL: https://designthinking.studio/articles/design-thinking-cross-functional-team-collaboration/ > 営業、開発、マーケが同じ部屋にいても、話が噛み合わない。クロスファンクショナルチームでデザイン思考を機能させるための構造と進め方を実践的に解説する。 部門横断チームを立ち上げたのに、結局いつも同じ顔ぶれが話している——よくある光景だ。プロジェクトルームには営業、エンジニア、マーケター、UXデザイナーが揃っている。ところが発言するのはマーケターとエンジニアだけ。営業は「現場では無理です」と繰り返す。デザイナーは黙ってスケッチを描いている。会議が終わると、誰も何も決まっていないことに気づく。 多様な部門が集まること自体は、クロスファンクショナルチームの「必要条件」にすぎない。問題を共に定義し、アイデアを接続し、意思決定を共有する構造が整って初めて、部門横断の恩恵が現れる。デザイン思考はその構造を提供するフレームワークだが、通常のプロセスをそのまま適用しても機能しないことが多い。チームの構成が均質なときに設計されたプロセスを、利害と言語の異なる部門混成チームに当てはめても、摩擦が増えるだけだからだ。 この記事では、クロスファンクショナルチームに特有の課題を整理し、デザイン思考の各フェーズをどう適応させるかを具体的に示す。 なぜクロスファンクショナルチームでデザイン思考が機能しにくいのか 「問題」の定義が部門ごとに違う 営業にとっての問題は「提案が通らない」だ。エンジニアにとっては「仕様が曖昧すぎて実装できない」になる。マーケターは「認知はあるのにコンバージョンが低い」と言う。全員が同じプロジェクトを担当しながら、異なる問題を持ち込んでいる。 デザイン思考の共感フェーズは、ユーザーの問題を探索するフェーズとして設計されている。しかし実際には、チームメンバー自身が抱える問題の定義を統一するステップが先に必要だ。この前工程を飛ばすと、インタビューで集めた情報の解釈が部門ごとにバラバラになる。 専門言語の壁が思考の接続を阻む エンジニアが「スケーラビリティの問題がある」と言っても、営業にはイメージが湧かない。営業が「顧客のペインポイントを押さえたい」と言っても、エンジニアには設計上の制約との接続が見えない。言語の壁は単なるコミュニケーション問題ではなく、思考の接続を阻む構造的な問題だ。 ワークショップで「自由にアイデアを出してください」と言われても、専門語彙の壁がある状態では、誰かの発言が他の誰かには理解できないまま通り過ぎていく。ブレインストーミングの形式だけが整っていて、実質的な交差が起きない。 責任と評価の構造がコラボレーションを阻む 部門横断チームのメンバーは、プロジェクトの成果よりも自部門の成果指標で評価されることが多い。営業は受注数、マーケターはリード獲得数、エンジニアは機能リリース速度。この評価構造のまま協働を求めると、メンバーは「プロジェクトの成功」よりも「自部門への影響の最小化」を優先し始める。「それは自部門の管轄外」という言葉が増え、難解な問題（Wicked Problems）ほど誰も前に出なくなる。 キックオフで何を決めるか——共通地図の作成 クロスファンクショナルチームのデザイン思考プロジェクトは、キックオフに時間をかけることが最初の投資だ。ここで決めるべきことは3つある。 - 探索する問いの合意 「何を解決するのか」ではなく「何を探索するのか」として問いを立てる。解決策の方向性を最初に決めると、各部門が「自分たちの解決策」を守り始める。「なぜ顧客は\\\\なのか」「どうすれば\\\\が変わるのか」という探索型の問いにしておくことで、全員がインプット側に立てる。 - 各自が持つ「見えていること」の棚卸し 営業は顧客との接点から得た生情報を持っている。エンジニアは技術的制約と可能性を知っている。マーケターは市場データを持っている。これらをセッションの最初に出し合い、全員が「他部門が見ている世界」を知ることが、共通地図の起点になる。 - このプロセスでの役割の定義 部門での役割ではなく、「このプロジェクトでの役割」を決める。ファシリテーター、記録者、ユーザーインタビュアー、プロトタイプ作成者。これらの役割は部門を横断して割り当てる。営業がプロトタイプを作り、エンジニアがユーザーインタビューを担当することで、普段と異なる視点が入る。 共感フェーズの部門横断対応——誰がユーザーを知っているか 共感フェーズで最もよくある間違いは、「ユーザーリサーチはUXチームがやるもの」という分業だ。部門横断チームにおける多様性の活用という観点からすると、各部門が異なる接点でユーザーと接触しており、それぞれが異なる「真実の断片」を持っている。 Airbnbがサービス初期に成長の停滞を経験したとき、創業者のブライアン・チェスキーとジョー・ゲビアが自らニューヨークに飛んで全ホストを訪問したことはよく知られている。しかしこの行動のポイントは「創業者がリサーチした」ではなく、「ビジネス側・製品側の人間が直接ユーザーと会った」という点にある。得た情報は、エンジニアチームが「機能追加で解決できる」と考えていた問題が、実は「写真の品質」というアナログな要因にあることを示した。これは担当部門を超えた情報収集なしには発見できなかった洞察だ。 部門横断インタビューチームの作り方： インタビューは必ず2名1組、異なる部門から選ぶ。一人が質問し、もう一人が観察と記録を担当する。観察者は「自分の部門のフィルターで何が気になったか」をメモする。インタビュー後に2名が感じたことを突き合わせると、同じユーザー発言が「受注障壁」と「機能要件」の両面から解釈されることに気づく。これが部門間の言語の翻訳起点になる。 問題定義フェーズ——「誰の問題か」を外に向ける クロスファンクショナルチームが問題定義でつまずく場所は決まっている。ユーザーインサイトを議論しているはずが、いつの間にか「自部門の課題」の話になっていることだ。 IBMがデザイン思考を全社に導入した際（2013年以降の「IBM Design Thinking」イニシアチブ）、最も時間をかけたのが「Hill（ヒル）」と呼ばれる問題定義フォーマットの徹底だった。HillはPOVステートメントの変形で、「誰（Who）が、何（What）を、驚きの方法（Wow）で」という3要素で構成される。このフォーマットを使う理由は明確で、主語を必ずユーザーに固定することで、部門利益の話が入り込む余地を構造的に排除するためだ。 実際のワークショップでは、チームが作ったHillを壁に貼り、全員が「このHillの主語は誰か」「ユーザーの話をしているか、自部門の話をしているか」を互いにレビューするセッションを入れる。他部門の視点から見ると、自部門フィルターのかかった問題定義が一目でわかる。 アイデア発想フェーズ——専門性を「材料」にする アイデア発想フェーズでクロスファンクショナルチームが強みを発揮できる瞬間は、異なる専門性が「接続される」ときだ。ただし、放置すると専門性は「制約の主張」として現れる。「技術的に無理」「予算が取れない」「現場では回らない」——これらはすべて正当な情報だが、アイデアが出た直後に言うと発散が止まる。 「制約を後工程に移動させる」ルール アイデア発散中は、制約の指摘を付箋に書いて「制約ボード」に貼る。「それは無理」と言う代わりに「それには制約があります」と書いてボードに追加する。発散フェーズが終わった後、制約ボードを見ながらアイデアを評価する。こうすることで、制約情報はアイデアを殺す武器ではなく、評価と改善の材料になる。 また、リモートワークショップ環境でクロスファンクショナルチームを動かす場合は、専門部門ごとの「サイロ発想」を防ぐために、デジタルホワイトボードのグループ分けを部門ではなくランダムまたはクロスで組む必要がある。同じ部門だけがくっついて議論する状態では、部門横断の意味がない。 Spotifyが「スクワッド」と呼ばれるクロスファンクショナルチームを導入した際、アイデア発想において特に効果が出たのは「ギルド」との組み合わせだった。スクワッドは部門横断の小チームで、ギルドは同じ専門性（エンジニア、デザイナー等）を持つ人々が組織横断でつながるコミュニティだ。アイデアをスクワッド内で発散させ、ギルドで専門的な実現可能性を磨く。この二層構造によって、「部門横断の発想」と「専門的な深掘り」の両方が維持された。 ファシリテーターの役割——翻訳者として立つ クロスファンクショナルチームのデザイン思考を成立させる鍵の一つが、ファシリテーターの質だ。ファシリテーター育成の観点から言えば、部門横断セッションのファシリテーターには通常のスキルに加えて「翻訳力」が必要になる。 翻訳力とは、ある部門の専門用語を他部門の文脈に置き換えて理解を橋渡しする能力だ。エンジニアが「APIのレイテンシ問題がある」と言ったとき、ファシリテーターが「それはユーザーが待たされるということですか、どのタイミングで」と問い直すことで、営業とマーケターも会話に入れる状態を作る。逆に営業が「クロージングで詰め切れない」と言ったとき、「それは情報が足りないから？それとも信頼感が足りないから？」と問い直すことで、UXデザイナーがタッチポイントの課題として捉えられるようになる。 ワークショップでのコンフリクト管理も、クロスファンクショナルセッションでは頻繁に起きる。部門間の利益対立がそのまま発言対立になることがある。このとき有効なのは「立場ではなく観察に帰る」介入だ。「今、2つの立場が出ています。どちらもユーザーから見ると正しい可能性があります。どちらの立場が正しいかではなく、ユーザーに何が起きているかを確認しましょう」と場をリセットする。 組織への定着——一度きりで終わらせない クロスファンクショナルチームによるデザイン思考プロジェクトが一度成功しても、次のプロジェクトで同じことが再現できなければ、組織的な能力にはならない。組織へのデザイン思考定着という観点から、継続のために整えるべき構造を3つ挙げる。 - 共通語彙の整備 プロジェクトを通じて発見した「部門間の翻訳パターン」を記録する。営業の「顧客が動かない理由」がUX的には「認知コストの高さ」として定義できる、といったマッピングだ。これを組織の共通辞書として蓄積することで、次のチームが同じ摩擦から始めずに済む。 - 「越境レビュー」の仕組み化 月1回、各部門のプロジェクト状況を他部門に5分で共有するセッションを設ける。共有の目的は承認ではなく「他部門から見えること」のフィードバックだ。これを継続すると、部門間の「相手が何をやっているかわからない」という断絶が徐々に解消される。 - リーダーシップ層の関与形式の設計 リーダーシップのデザイン思考への関与は、プロセスへの介入ではなく「問いの設定」と「障壁の除去」が適切な形だ。マネジメントがプロセス途中でソリューションを指定し始めると、クロスファンクショナルチームの自律性が失われる。リーダーの役割は「このプロジェクトで何を学びたいか」を定義し、学習の障壁（予算、権限の壁など）を取り除くことに絞る。 クロスファンクショナルチームは、構造なしに動かすと均質なチームより機能しないことがある。異なる部門から来た人々が同じ部屋にいることが、そのままコラボレーションを意味しない。しかし構造を整えたとき、均質なチームでは決して出てこない洞察が生まれる。一人では見えない角度から問題が照らされ、制約だと思っていたものが別部門にとっては当然のリソースだったことに気づく。 多様性は目的ではなく、手段だ。そしてデザイン思考は、その多様性を機能させるための構造を提供する。 --- 参考文献 - IDEO. (2015). The Field Guide to Human-Centered Design. IDEO.org. https://www.designkit.org/resources/1 - IBM Design. (2018). IBM Design Thinking Field Guide. IBM Corporation. https://www.ibm.com/design/thinking/ - Gothelf, J., & Seiden, J. (2021). Lean UX: Designing Great Products with Agile Teams (3rd ed.). O'Reilly Media. - Graham, P. (2013). "Do Things That Don't Scale." paulgraham.com. https://www.paulgraham.com/ds.html (Airbnb初期の顧客接触戦略に関する論考を含む) - Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. Crisp AB. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf --- ### サーキュラーエコノミー × デザイン思考——廃棄を前提としない製品・サービス設計の実践 URL: https://designthinking.studio/articles/design-thinking-circular-economy-application/ > 製品の「終わり」から設計を始める逆算思考。サーキュラーエコノミーの原則をデザイン思考プロセスに統合し、廃棄ゼロを前提とした製品・サービス設計の具体的手法を、Renault・Philipsの事例とともに解説する。 製品を設計するとき、多くのチームは「どう作るか」から始める。素材、構造、ユーザーインターフェース。それが出来上がってから「どう廃棄するか」を考える。この順序そのものが、現在の大量廃棄社会を設計している。 サーキュラーエコノミー（循環経済）とは、廃棄を「仕方ないこと」ではなく「設計の失敗」として定義する考え方だ。製品の終わりから逆算して設計を始め、素材が製品から製品へ、製品がサービスへ、サービスが次のイノベーションの起点へと循環し続ける経済モデルを指す。 この考え方とデザイン思考は、表面上は異なる語彙で語られるが、その本質では共鳴している。どちらも「問題の定義そのものを疑う」姿勢を中核に持つ。廃棄という「当たり前」を問い直すのが循環経済なら、ユーザーが「当たり前」だと思っている行動の背後にある本質的なニーズを問い直すのがデザイン思考だ。 --- なぜ今、循環設計が設計の問題になるのか Ellen MacArthur Foundation の試算によれば、再生可能エネルギーへの転換だけでは対処できないGHG排出量の約45%は、製品・素材・食料の設計と使われ方に起因するとされる。製品設計の見直しが介入できる領域は、エネルギー転換だけでは届かないこの領域に広がっている。 「廃棄が出るのは仕方ない」という前提は、設計プロセスのあらゆる段階に埋め込まれている。素材選定時に「リサイクルしやすいか」を問わない。モジュール構造の採否を「修理容易性」の観点から評価しない。製品寿命をビジネスモデルから切り離して考える。こうした判断の積み重ねが、廃棄を構造的に生み出す製品群を生産し続けている。 設計段階での決定が製品のライフサイクル全体の環境インパクトの大部分を決定するという事実は、設計者に大きな責任を与えると同時に、大きな可能性も示す。廃棄を減らす最も効果的な介入点は、廃棄処理の改善でも消費者の行動変容でもなく、設計プロセスそのものだ。 --- 循環設計の3原則とデザイン思考プロセスの接続 Ellen MacArthur Foundation は循環経済の原則を3つに整理している。「廃棄物と汚染を排除する」「製品と素材を使い続ける」「自然システムを再生する」の3つだ。これをデザイン思考の各フェーズと接続すると、実践的なフレームが見えてくる。 共感フェーズでの拡張。通常の共感調査がターゲットユーザーの現在の行動を把握しようとするのに対し、循環設計の視点では「製品の終わりを体験する人々」への共感が加わる。廃棄処理業者、修理技術者、中古品の購入者、素材の採取地に暮らす人々。これらのステークホルダーは通常のユーザーリサーチには現れないが、製品の循環可能性を評価するうえで不可欠な視点を持っている。 定義フェーズでの問い直し。「問題をどう定義するか」が設計の全体を規定する。線形設計の問いは「この機能をどう実現するか」だが、循環設計の問いは「この機能を、使用後に素材として回収・再利用できる形でどう実現するか」に変わる。問いの構造が変わると、解の空間が変わる。 発想フェーズでのモデル拡張。発想の制約に「廃棄ゼロ」を加えると、ビジネスモデルの選択肢が広がる。製品販売モデルからサービスモデルへの転換（所有から利用へ）、リマニュファクチャリングを前提とした収益設計、素材のクローズドループを実現するバリューチェーン設計。制約は創造性を殺すのではなく、別の経路を開く。 --- Renaultの事例：自動車産業におけるリマニュファクチャリング Renaultはフランスのフリン工場（Refactory）で、自動車部品のリマニュファクチャリング（再製造）を事業化している。廃棄される予定だった中古部品を回収・分解・洗浄・再組み立てし、新品と同等の品質保証をつけて市場に戻す循環型の製造プロセスだ。 この取り組みで注目すべきは、リマニュファクチャリングを「環境対応の後付け」ではなく、製品設計の前提として組み込んでいる点だ。分解しやすい構造、部品の規格統一、素材の識別を容易にする設計。これらは製品が市場に出る前の設計段階での意思決定の結果だ。 Renaultは2022年のアニュアルレポートで、リマニュファクチャリングされた部品は新品製造と比較してCO2排出量を最大80%削減できると報告している。コスト面でも、再製造部品は新品の30〜50%程度の価格で提供できるため、価格競争力のある新市場セグメントを開拓している。 ここにデザイン思考のプロトタイプ思考との共鳴がある。「完璧に作って一回売り切る」のではなく、「使われ続け、繰り返しシステムに戻ってくる製品」をデザインする。プロトタイプフェーズで問うべきは「動くか」だけでなく「分解できるか」「素材を識別できるか」「修理可能か」だ。 --- Philipsの事例：照明のサービス化と素材回収の設計 Philips（現Signify）は2015年頃から「Light as a Service（LaaS）」と呼ばれるビジネスモデルを展開している。企業が照明器具を購入するのではなく、「照明環境」を月額サービスとして契約する形態だ。 このモデルの設計思想は循環経済の原則を体現している。照明器具の所有権はPhilipsに残るため、Philipsには製品を長く使わせ、使用後に回収して素材を再利用するインセンティブが生まれる。顧客は「消耗品を買い続ける」コストから解放され、常に最新・最適な照明環境を維持できる。廃棄物は顧客側から消える。 このビジネスモデルの転換は、技術開発より先にデザイン思考のプロセスを必要とした。顧客が「照明器具」ではなく「明るさ・快適さ・省エネ」という機能を求めているという洞察は、深い共感調査なしには得られない。「製品を売る」前提を疑う定義の問い直し。「所有から利用へ」という発想の転換。それらが揃って初めて、技術とビジネスモデルの設計が始まる。 Philipsの事例は、サステナブル製品設計が単なる素材置換の問題ではなく、ビジネスモデルとユーザー体験の再設計を伴うという点を示す好例だ。 --- 循環設計を実践するための4つの問い デザインチームが循環経済の視点を設計プロセスに統合するための実践的な問いを4つ挙げる。 - この製品の「終わり」をどう設計するか。製品が壊れたとき、使われなくなったとき、何が起きるかを先に設計する。分解経路、素材の分別可能性、リセール・リサイクルの容易さ。これを最初のブリーフに含める。 - 「所有させる」必要があるか。ユーザーが本当に求めているのは機能・体験・状態だ。製品の物理的な所有はその手段に過ぎない場合が多い。サービスモデル・シェアリングモデル・サブスクリプションモデルへの転換可能性を発想段階で検討する。 - バリューチェーンの「上流」と「下流」に誰がいるか。素材の採取から廃棄処理まで、製品に関わるすべてのアクターをステークホルダーとして地図に描く。サプライチェーンの視点を設計初期に持ち込むことで、循環の回路をクローズドにする設計が可能になる。 - 素材はシステムの中を「流れている」か、「溜まっている」か。循環経済において素材は流れるべきものだ。製品の設計が素材の流れを止めてしまう構造（分解不能な複合素材、異種材料の接着など）がないかを評価する。流れを止める構造が発見されたら、それが次の設計課題になる。 --- システム思考との接続——問題の境界を広げる 循環設計の実践で最大の障壁になるのは「自社製品の境界の外は関係ない」という思考の前提だ。素材が自社工場に入ってくる前の採取・輸送。製品が消費者の手を離れた後の廃棄・回収・再処理。これらは「自社製品の外」に位置するが、循環の回路を設計するためには視野に入れなければならない。 システム思考は、この思考の拡張を支援するツールだ。システム全体のフィードバックループ、遅延、レバレッジポイントを可視化することで、個別の製品最適化が全体の循環を妨げる構造を発見できる。 現実には、一社単独でクローズドな循環ループを完結させることは難しい。素材回収のインフラ、リマニュファクチャリングのサプライヤー、廃棄物処理業者との協業が必要になる。これはスマートシティやアーバンイノベーションの文脈でも進む議論で、都市レベルでの素材循環インフラとその設計者としての企業の役割が問われている。 「自社製品の設計」を超えて「産業のシステム設計」に参与する覚悟が、本質的な循環設計には必要だ。それはデザイン思考が本来持つ姿勢——問題の境界を問い直す姿勢——と一致する。 --- 廃棄を前提としない設計の出発点 循環経済とデザイン思考を接続する試みは、どちらか一方を「手法」として消費する話ではない。廃棄を構造的に生み出してきた設計プロセスの前提を問い直し、問いの立て方から変えるという思考の実践だ。 最初のステップは小さくていい。次の製品ブリーフを書くとき、「この製品が10年後にどうなるか」という問いを一行加える。ユーザーリサーチに廃棄処理業者や修理技術者へのインタビューを一件加える。発想セッションに「所有させない解」を一つ加える制約を設ける。 廃棄を「仕方ない」と思うのをやめる設計者が一人増えるたびに、廃棄が「設計の失敗」として可視化される製品が一つ増える。その積み重ねが、循環の回路を少しずつ繋いでいく。 --- 参考文献 - Ellen MacArthur Foundation. Towards the Circular Economy: Economic and Business Rationale for an Accelerated Transition. Ellen MacArthur Foundation, 2013. - Ellen MacArthur Foundation. Completing the Picture: How the Circular Economy Tackles Climate Change. Ellen MacArthur Foundation, 2019. - Renault Group. 2022 Universal Registration Document. Renault Group, 2023. https://www.renaultgroup.com/en/investors/publications/ - Walter R. Stahel. The Circular Economy: A User's Guide. Routledge, 2019. - Ken Webster. The Circular Economy: A Wealth of Flows. Ellen MacArthur Foundation Publishing, 2017. --- ### サービスデザインとデザイン思考の違いと統合 — UXをビジネス全体に広げる視点 URL: https://designthinking.studio/articles/service-design-vs-design-thinking/ > デザイン思考とサービスデザインはしばしば混同されるが、異なる問いに答えるフレームワークだ。「体験の設計」から「体験を支えるシステムの設計」への拡張を、具体例とともに解説する。 「サービスデザインとデザイン思考はどう違うのか」——ワークショップでこの問いが出るたびに、少し立ち止まって考えます。正直、最初から明確な答えを持っている人はほとんどいません。 一行で言うなら：デザイン思考は「何を・なぜ作るか」を問い、サービスデザインは「それを支えるシステムをどう設計するか」を問います。 デザイン思考の焦点：問題定義と解決策の発見 デザイン思考の5フェーズ（共感→定義→発想→プロトタイプ→テスト）は、「正しい問題を見つけ、正しい解決策を発見する」ためのプロセスです。 共感でユーザーの現実を掴み、定義で解くべき問題を絞り込み、あとは発想・試作・テストで形にしていく。出力は「方向性の確信」です。 強みは「点」にあります。「このユーザーが、この状況で、このタスクを完了するとき、どんな体験になるか」——その一点を深く掘ることに集中します。 サービスデザインの焦点：体験を支えるシステム全体の設計 サービスデザインは、「体験がどのように生み出されるか」というシステム全体を設計します。 サービスデザインが扱うのは、顧客が直接触れる「フロントステージ」だけでなく、顧客には見えない「バックステージ」の運営プロセスも含みます。 例えば、ホテルのチェックインという体験を考えます。デザイン思考のアプローチでは、「チェックインカウンターでのユーザー体験をどう改善するか」に集中するかもしれません。サービスデザインのアプローチでは、その体験を支える「予約システムと客室管理システムの連携」「フロントスタッフのトレーニングプログラム」「清掃スタッフのシフト設計」「部屋の準備状況の通知フロー」を一体として設計します。 チェックインの体験は、フロントスタッフのスクリーンに映る情報の質に左右されます。その情報は、どのシステムがどのタイミングで更新するかによって決まります。この「見えないシステム」を設計することがサービスデザインの核心です。 サービスブループリント：バックステージを可視化するツール サービスデザインの代表的なツールがサービスブループリントです。 サービスブループリントはカスタマージャーニーマップを縦軸方向に拡張したもので、以下の層で構成されます。 - エビデンス：顧客が体験を通じて触れる物理的・デジタルなもの - 顧客行動：顧客がするアクション - フロントステージのスタッフ行動：顧客と直接接触するスタッフの行動 - バックステージのスタッフ行動：顧客には見えないスタッフの行動 - サポートプロセス：体験を支えるシステム・IT・プロセス ワークショップでよく起こるのは、ブループリントを作り始めると「バックステージ」の欄に書くことが見つからないパターンです。実際には、フロントでの1分間の体験の背後に、20-30分分のバックステージプロセスが存在することがほとんどです。これが「書けない」ということは、バックステージが設計されていないことを意味します。 ジャーニーマップ：橋渡しとしての役割 カスタマージャーニーマップは、デザイン思考とサービスデザインの橋渡しとなるツールです。 デザイン思考の文脈では、ジャーニーマップは「共感フェーズで収集したデータを整理し、ユーザーの体験全体を可視化する」ために使います。痛点（Pain Points）や機会（Opportunities）を発見するための分析ツールとして機能します。 サービスデザインの文脈では、ジャーニーマップは「現在の体験のAs-Is」と「設計する体験のTo-Be」を表現するために使います。そして各タッチポイントの「To-Be体験」を支えるバックステージの設計へと展開していきます。 どちらを使うべきか：問いの違いで選ぶ 実際にやってみると、多くのプロジェクトで「デザイン思考とサービスデザインのどちらを使うか」ではなく、「どの段階でどちらの視点が必要か」という問いになります。 | フェーズ | 主に使う視点 | |---|---| | 問題を発見・定義する | デザイン思考（共感・定義・発想フェーズ） | | 解決策をシステムとして設計する | サービスデザイン（ブループリント・プロセス設計） | | 試作して検証する | デザイン思考（プロトタイプ・テストフェーズ） | | 本番実装のための組織設計 | サービスデザイン（バックステージの設計・KPI設計） | 実際には、デザイン思考でユーザーインサイトを得て問題を定義し、サービスデザインで解決策をシステムとして実装設計するという組み合わせが最も機能します。 統合の失敗パターン 参加者からの声として多いのは、「デザイン思考でいいアイデアが生まれたのに、実装段階でバックステージの設計が追いつかず、体験が形骸化した」という経験です。 例えば、「チェックインをモバイルアプリで非対面化する」というアイデアが生まれても、清掃完了と客室準備状況をリアルタイムでアプリに反映するシステムがなければ、「アプリからチェックインしたのに部屋に入れない」という最悪の体験が生まれます。 これはデザイン思考が悪いのではなく、「デザイン思考で発見した解決策をサービスデザインで実装設計する」というプロセスが欠けていた結果です。 サービスデザインが開く「組織設計」の視点 サービスデザインのもうひとつの重要な側面は、「体験の質は組織の構造によって決まる」という認識です。 優れた顧客体験を提供するためには、フロントスタッフが必要な情報と権限を持っている必要があります。それは採用・トレーニング・評価システムの設計の問題であり、部門間の情報共有の設計の問題でもあります。 この視点に立つと、「顧客体験の設計」は自動的に「従業員体験（Employee Experience）の設計」と不可分になります。これが、デザイン思考をサービスデザインに統合したときに開かれる、組織変革の視点です。 実践者への示唆：次のプロジェクトに統合する デザイン思考のワークショップを終えた後、「次のステップ」としてサービスブループリントの作成を提案することで、「アイデアを実装まで持っていく」経験を積めます。 具体的には、デザイン思考の定義フェーズで特定した「最も重要な課題」に対して、その解決策が実際に機能するための「バックステージプロセス」を1枚のブループリントとして描いてみてください。書こうとして書けない部分が、実装の課題を先取りして教えてくれます。 --- 参考文献 - Marc Stickdorn & Jakob Schneider, This Is Service Design Thinking, BIS Publishers, 2011 - Marc Stickdorn et al., This Is Service Design Doing, O'Reilly, 2018 - G. Lynn Shostack, "Designing Services That Deliver", Harvard Business Review, January–February 1984（サービスブループリントの原論文） - Nielsen Norman Group, "Service Blueprints: Definition", nngroup.com, 2017 --- ### サステナビリティ × デザイン思考——製品設計に環境視点を組み込む実践フレーム URL: https://designthinking.studio/articles/design-thinking-sustainable-product/ > デザイン思考のプロセスにサステナビリティ視点を統合する実践フレームを解説。エンパシーの拡張から循環設計の原則まで、Nike・IDEO・Philipsの事例を通じて、環境負荷を削減しながらユーザー価値を高める設計手法を体系化する。 「環境に配慮した製品を作れ」という要求が、デザインチームに降りてくる。しかし実際のワークショップでは、「サステナブル」という言葉が免罪符になりやすい。素材を変える。パッケージをリサイクル可能にする。「使用後の廃棄方法」をラベルに記載する。それで「サステナブルな製品」と呼べるのか。 答えはほぼ「No」だ。 デザイン思考とサステナビリティの統合は、製品の機能を固定したまま素材や後処理だけを最適化する話ではない。製品が生まれてから廃棄されるまでのライフサイクル全体を、ユーザーの行動・感情・社会文脈と同時に設計するという、思考の構造変換を要求する。 --- なぜ「素材変更」だけでは不十分か 2019年にEllen MacArthur Foundationが発表した調査によれば、製品が生涯にわたって排出するCO2の約80%は、設計段階での決定によって決まる。製品が市場に出てからの省エネや廃棄方法の改善が及ぼせる影響は、残りの20%に過ぎない。 つまり、サステナビリティは素材・後処理の問題ではなく、設計の問題だ。 IDEOは2021年に公開したデザインキット「Design for Sustainability」の中で、従来のデザイン思考のアンカーである「Desirability（人が欲しがるもの）」「Feasibility（技術的に作れるもの）」「Viability（ビジネスとして成立するもの）」の3円モデルに、「Sustainability（地球と社会が持続できるもの）」を第4の円として追加した。この拡張は単なるチェックボックスの追加ではなく、設計プロセスの根本的な問い直しを意味する。 --- エンパシーの拡張：ユーザーから「非ユーザー」へ デザイン思考の共感フェーズで問うのは通常「このユーザーが何を必要としているか」だ。しかしサステナビリティ視点では、共感の対象を拡張する必要がある。 将来世代への共感。20年後の消費者は、今日設計した製品の廃棄物と共存しなければならない。IDEO創業者のDavid Kelleyは「デザイナーが未来の自分に共感することで、短期主義のトレードオフが可視化される」と述べている。ペルソナに「2045年に成人する利用者」を加えるだけで、製品寿命・修理容易性・素材選択への問いが変わる。 間接的な影響を受けるステークホルダーへの共感。製品の製造拠点周辺の住民。素材採取地の生態系。廃棄処理施設の作業者。これらの存在は通常のユーザーリサーチには現れない。しかし製品の環境・社会インパクトの多くは、この「見えないステークホルダー」に集中している。 実践的には、ステークホルダーマッピングのセッションに「非ユーザー」「将来ユーザー」「間接影響者」の3カテゴリを標準項目として加えることで、共感の射程を意図的に広げることができる。 --- 問題定義の再フレーミング：ライフサイクル全体を見る 製品に関する従来の問題定義は「使用中のユーザー体験」に集中しがちだ。しかし製品は「使用中」だけでなく、生産・輸送・使用・廃棄の全フェーズで環境・社会に影響を及ぼす。 ライフサイクルアセスメント（LCA）との接続。LCAは製品の全ライフサイクルを通じた環境負荷を定量評価する手法で、ISO 14040/14044で規格化されている。デザイン思考との統合において有効なのは、LCAの結果を「数値として報告する」のではなく、問題定義フェーズの「インサイト」として扱うことだ。 具体的な接続方法として、ホットスポット分析が機能する。LCAで明らかになった「環境負荷の最大源」をデザインチームと共有し、そこを起点にHow Might We（HMW）問いを生成する。「製品の60%の排出が輸送フェーズで発生している」なら「どうすれば輸送コストと環境負荷を同時に削減できるか？」という設計問題に変換できる。 --- 発散フェーズ：循環設計の6原則 アイデア発散のフェーズに、循環設計（Circular Design）の6原則をフレームとして導入することで、アイデアの射程を拡げることができる。これはEllen MacArthur Foundationが提唱するサーキュラーエコノミーの設計原則をデザイン思考ワークショップ向けに翻訳したものだ。 原則1：長寿命設計（Longevity）。製品が長く使われるよう設計する。耐久性の向上だけでなく、修理・アップグレード・リペアのしやすさを設計段階で組み込む。Appleが2022年に開始した「セルフリペアプログラム」は、この方向への一歩として評価されている。 原則2：モジュール設計（Modularity）。部品単位での交換・アップグレードを可能にする設計。Fairphone（フェアフォン）は、スマートフォンの主要モジュール（バッテリー・カメラ・スクリーン）をユーザーが自己交換できるよう設計した事例だ。 原則3：素材の循環（Material Circularity）。製品に使われる素材が、廃棄後に別の製品の原料として回収・再投入できるよう設計する。ここで重要なのは「リサイクル可能な素材を使う」ことではなく「実際にリサイクルされる可能性が高い素材・構造を設計する」ことだ。複合素材や接着剤による固着は、リサイクルの難易度を大幅に上げる。 原則4：製品のサービス化（Product-as-a-Service）。製品を所有するモデルから、使用権を提供するモデルへの転換。Philipsは「Light as a Service」として照明器具の機能を契約サービスとして提供するビジネスモデルを展開している。製品が企業の所有物のまま顧客に使用されるため、メーカーが製品の回収・再生利用に構造的なインセンティブを持つ。 原則5：廃棄の再定義（Waste as Resource）。ある製品の廃棄物を別の製品の資源と見なす視点。Nikeの「Reuse-A-Shoe」プログラムは、廃棄されたスニーカーを粉砕してスポーツ施設の床材「Nike Grind」に再生する。廃棄物を原料として捉え直すことで、製品ライフサイクルをループさせる。 原則6：生物材料の活用（Biological Materials）。土壌に還元できる生物由来材料の活用。石油由来プラスチックから生分解性素材への移行は、リサイクルが困難な場合の代替アプローチだ。ただし「生分解性」は適切な環境条件が整っている場合にのみ機能する点に注意が必要で、「とりあえず生分解性素材を使えばよい」という安易な解釈が問題を引き起こすことがある。 --- プロトタイプフェーズ：サーキュラリティのシナリオテスト プロトタイプを評価するとき、通常は「使用中のユーザー体験」がテスト対象になる。サステナビリティ視点では、廃棄・回収・再生のシナリオをプロトタイプテストに組み込むことが重要だ。 実践的には「未来のユーザー体験マップ」として、5年後・10年後のユーザーが製品をどう処理するかをシナリオ化し、その段階でのユーザー行動・感情・摩擦を可視化する。「修理が必要になったとき、実際に修理できるか」「廃棄する段階で、ユーザーが正しい経路で廃棄できるか」——これらは製品の設計・ビジネスモデル・ユーザー教育の問題として設計段階に戻ってくる。 --- 事例：NikeのCircular Design Challenge Nikeは2019年から「Circular Design Challenge」というデザインコンペを実施している。学生チームが循環設計の原則に基づいてスポーツ製品を提案するプログラムで、サーキュラーデザインとデザイン思考の統合的な実践例として参照されている。 評価基準は機能性・審美性だけでなく、「製品の第2の人生（Second Life）」をどう設計したかが明示的に含まれる。製品が最初の使用後にどのように再使用・修理・素材回収されるかを、設計の一部として提案することが求められる。 この取り組みが示すのは、サステナビリティが「制約の追加」ではなく「創造性を刺激するデザインブリーフの要素」として機能しうるという実践的な事実だ。 --- 実装の現実：組織的な壁と突破口 デザイン思考とサステナビリティの統合に対し、組織が示す抵抗のパターンはほぼ共通している。 「コストが上がる」「スケジュールが延びる」「マーケットの準備ができていない」——これらはすべて「問題定義が完了していない状態での反論」だ。どれだけ環境負荷を削減できるか、その節約がコスト削減につながるか、ライフサイクルコスト全体で見れば投資回収できるか——これらは設計の段階で検証できる問いだ。 突破口は、サステナビリティを「コスト」ではなく「イノベーションの起点」として定義し直すことにある。制約が設計の創造性を高めるのは、デザイン思考が長年示してきた事実だ。「廃棄コストを最小化せよ」という制約は、ビジネスモデル革新（製品のサービス化）・素材技術革新（生分解性材料）・ユーザー関係革新（修理文化の醸成）という3方向のイノベーション機会を同時に開く。 --- デザイン思考が「人間中心」の方法論であるなら、その「人間」は今日のユーザーだけを指さない。20年後の地球に生きる人間を含めて、初めて「人間中心」は完成する。 --- 参照文献 - Ellen MacArthur Foundation. (2019). Completing the Picture: How the Circular Economy Tackles Climate Change. ellenmacarthurfoundation.org. - IDEO.org. (2021). Design for Sustainability: A Practical Approach. designkit.org. - ISO 14040:2006. Environmental management — Life cycle assessment — Principles and framework. International Organization for Standardization. - ISO 14044:2006. Environmental management — Life cycle assessment — Requirements and guidelines. International Organization for Standardization. - Ellen MacArthur Foundation & IDEO. (2017). The Circular Design Guide. circulardesignguide.com. - Philips. (n.d.). Light as a Service. philips.com. - Nike. (2019). Circular Design Challenge. nikecirculardesign.com. --- ### ステークホルダーインタビューの構造化——3階層で「知っている人」の知識を引き出す URL: https://designthinking.studio/articles/design-thinking-stakeholder-interview/ > デザイン思考における「エキスパート／ステークホルダーインタビュー」の実践的構造化手法。ユーザーインタビューとの違い、聞くべき3階層（事実・解釈・願望）、半構造化ガイドの設計から共感マップとの接続まで、ワークショップ実務の観点から解説する。 デザイン思考のプロジェクトで最初に詰まる場面のひとつが「ステークホルダーに何を聞けば良いか分からない」という状況です。 ワークショップでよく起こるのは、ステークホルダーへのインタビューが「説明を聞く場」になってしまうことです。相手は「知っている人」なので、質問を投げると丁寧に説明してくれます。1時間後に手元にあるのは詳細なメモの束ですが、「で、何が課題なのか」「何を変えなければならないのか」が見えていない。情報は得たが洞察がない、という状態です。 ユーザーインタビューとの違い ユーザーインタビューは「体験を引き出す」ことが目的です。ユーザーは自分の体験の当事者ですが、その構造を俯瞰的に理解しているわけではありません。 ステークホルダーインタビューは「知識と解釈を引き出す」ことが目的です。組織の中で特定の役割を持つステークホルダーは「体験者」でもありますが、同時に「構造を知っている人」でもあります。この違いが、インタビューの設計を根本から変えます。 バイアスの種類も異なります。ユーザーは「自分の体験の当事者」として語るため、記憶の選択的省略が生じます。ステークホルダーは「組織の関係者」として語るため、既存施策の正当化・自分の立場を守る語りが混入します。このバイアスへの対処がステークホルダーインタビューの技術的な核心です。 聞くべき3階層：事実・解釈・願望 第1階層：事実（What happened） 「実際に起きたことは何か」を問う階層です。数値・記録・観察可能な出来事が対象です。「そのデータは記録が残っていますか」「他の人の認識とどのくらい一致していますか」という確認を挟むことで、次の解釈の階層との境界を意識させます。 第2階層：解釈（What it means） 「その事実をどう解釈しているか」を問う階層です。「なぜそうなっていると思いますか」「他のチームはこの状況をどう捉えていると思いますか」が典型的な問いです。 実際にやってみると、この階層で最も豊かな洞察が出てきます。同じ事実を組織の異なる部門が全く違うメカニズムで説明していることが多い。製造部門が「品質管理プロセスの問題」と解釈していることを、営業部門は「顧客への説明の問題」と解釈していることがある。この解釈の差異こそが「どの問題定義が正しいか」を探索する素材です。 第3階層：願望（What should be） 「理想の状態はどうあるべきか」を問う階層です。ステークホルダーは「現実的に可能なこと」を前提にした控えめな願望を語りがちです。「制約を一度忘れてください」という指示を明示的に与えることで、本来の願望と現実の妥協の間にある空間を引き出します。 半構造化インタビューガイドの設計 インタビューガイドの構成はオープニング→ウォームアップ→事実の探索→解釈の探索→願望の探索→クロージングという順序が有効です。クロージングで「他に話を聞くべき人がいますか」と問うことで次のインタビュー候補を発掘するスノーボール手法としても機能します。 Emery法（要因分析）との組み合わせ: フレデリック・エマリー（Frederick Emery）が組織研究の文脈で発展させた要因分析の視点は、ステークホルダーインタビューに応用できます。「なぜそれを変えられなかったのか」という問いへの答えが、組織の制約構造を可視化します。 Laddering法（価値はしご）との組み合わせ: トマス・レイノルズとジョナサン・グトマンが1980年代に体系化した手法です。「なぜそれが重要なのですか」を繰り返すことで、表面的な機能的理由（Attribute）から個人の深層価値（Value）へと掘り下げます。ステークホルダーが「効率化が大事だ」と言うとき、その先に「リソースの再配分で別の事業に投資したい」という組織戦略的な動機があることがあります。 対話記録のコーディングとテーマ抽出 インタビュー後、全発言を逐語化し、各発言に「どの3階層に属するか」を一次コードとして付与します。 複数インタビューにわたってパターンを見つける二次コーディングでは、KJ法（アフィニティダイアグラム）が有効です。各発言を付箋1枚に書き、テーマごとにグループ化します。物理的な付箋とホワイトボードの方が「なんとなく似ている」という感覚的なグルーピングが速く進むことが多い。同じテーマについて、異なる立場のステークホルダーがどのように解釈しているかの差異が、問題定義のための素材です。 Empathy map と Stakeholder map の接続 ステークホルダーに共感マップを適用するとき、「Think（考えていること）」の象限が一番難しいと感じるのはよく聞く声です。ステークホルダーは直接「私は○○と考えています」とは言わないことが多い。発言の文脈・語気・繰り返し出てくるテーマから「言葉になっていない前提」を読み取る必要があります。 「ステークホルダーマップ」との接続では、各ステークホルダーを「関心の高さ」と「影響力の強さ」の2軸でマッピングします。共感マップで把握した各人の「願望」と「解釈の差異」を、このマップ上に重ねることで「誰の問題定義が最も強く議論を動かすか」が見えてきます。 落とし穴：権威バイアス・解釈回避・願望の混入 権威バイアス: 「知っている人」の解釈を「事実」として取り扱わないよう、同じ問いを複数のステークホルダーに投げ、チームで記録レビューを行う仕組みが重要です。 解釈回避: 組織への影響を考慮して「事実は話すが解釈は言わない」スタンスのステークホルダーもいます。「仮に——だとしたら、どう思いますか」という仮定法の問いが有効です。 願望の混入: 「現状の記述なのか理想の記述なのかが曖昧なまま進む」ケースが起きます。「それは現在起きていることですか、それとも理想の状態ですか」と確認する習慣が、この混入を防ぎます。 ステークホルダーが「知っている人」であることは強みですが、「正解を持っている人」とは違います。彼らが持っているのは「部分的な事実」と「特定の立場からの解釈」と「自分の立場に影響を受けた願望」です。この3つを丁寧に分離して引き出す技術が、ステークホルダーインタビューの構造化の本質です。 --- 参考文献 - Thomas J. Reynolds & Jonathan Gutman, "Laddering theory, method, analysis, and interpretation", Journal of Advertising Research, 28(1), 1988 - Frederick Emery & Eric Trist, "The Causal Texture of Organizational Environments", Human Relations, Vol.18, 1965 - Tim Brown, Change by Design, HarperBusiness, 2009 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Dave Gray, Sunni Brown & James Macanufo, Gamestorming, O'Reilly Media, 2010 - Stanford d.school, Bootcamp Bootleg, dschool.stanford.edu（Empathy Map原型） --- ### タッチポイントマッピング完全ガイド——顧客接点の全体像を可視化する実践技法 URL: https://designthinking.studio/articles/service-design-touchpoint-mapping/ > タッチポイントマッピングはサービスデザインにおける接点の棚卸し手法。サービスブループリントとの違い、実施ステップ、ワークショップ設計、デジタル・物理の統合まで実務視点で体系解説する。 顧客がブランドと出会う場面は、思っているより多い。検索結果の広告、初めて触れるランディングページ、問い合わせフォーム、配送通知のメール、返品手続きのコールセンター——それぞれが独立して設計されてきた結果、体験に断絶が生まれる。 タッチポイントマッピングは、こうした接点の全体像を棚卸しし、視覚化する手法だ。どこで顧客と接触し、そこで何が起きているかを一枚の図に収める。個別最適ではなく、体験の通し線を捉えるための道具である。 タッチポイントとは何か タッチポイント（Touchpoint）とは、顧客とブランド・サービスが直接または間接的に接触するすべての場面を指す。物理的なもの（店舗、商品パッケージ、領収書）もあれば、デジタルなもの（ウェブサイト、アプリ通知、SNS）もある。人を介するもの（営業担当者、コールセンター、配送スタッフ）も含まれる。 Interaction Design Foundation は「タッチポイントマッピングとは、サービスや製品の体験を通じた顧客・従業員・ブランドの接点を棚卸しするテクニック」と定義している。棚卸しによって接点を可視化し、設計・調整・削除の判断材料にする。 重要なのは、タッチポイントは「あるべき接点」ではなく「実際に存在する接点」を対象にする点だ。設計意図と顧客体験の乖離を発見するために、現状を正確に把握することが先決になる。 サービスブループリントとの違い タッチポイントマッピングとサービスブループリントは、しばしば混同される。両者は補完的な手法であり、目的と視点が異なる。 タッチポイントマッピングは顧客視点を中心に、ブランドとの接触点を網羅的に列挙する。「顧客がどこで、何に触れるか」が問いの中心だ。 サービスブループリントはその一段深い層を扱う。可視領域（顧客が直接体験するもの）と不可視領域（バックオフィス、システム、従業員の動き）を分離して描く。「接点の裏側で何が動いているか」が問いになる。 NNグループの定義では、「サービスブループリントはカスタマージャーニーマップの後続ステップ」とされている。タッチポイントマッピングで接点を把握し、ブループリントで運営構造を明示する——この順序が実務では自然な流れになる。 タッチポイントを3軸で分類する タッチポイントを羅列するだけでは使えない。分類することで設計の優先順位が見えてくる。 時間軸（いつ） 顧客旅程の段階によって接触点を整理する。認知→検討→購入→利用→アフターの5段階が一般的だ。どの段階に接点が集中し、どこに空白があるかが一目でわかる。 チャネル軸（どこで） デジタル、物理、人的対応の三種類に分ける。チャネルをまたいで体験の一貫性が保たれているか、断絶が起きていないかを確認する視点だ。オムニチャネル戦略の評価に直結する。 主導者軸（誰が動かすか） 顧客が能動的に起こすもの（サイト訪問、問い合わせ）と、企業が送り出すもの（メールマーケティング、請求書）に分けると、どちらが主導権を持つかが見えてくる。受動的に受け取る接点で悪い体験があると、顧客は離脱しやすい。 実施ステップ：ワークショップ設計 タッチポイントマッピングを機能させるには、机上の作業ではなく、現場に近いチームを集めたワークショップとして実施することが有効だ。 Step 1: 対象顧客と旅程の範囲を決める（30分） 全顧客を対象にすると焦点が拡散する。最初に「誰の、どの旅程か」を絞る。主要ペルソナ一人と、その購買〜継続利用までの旅程を対象にするのが適切な粒度だ。 Step 2: 接点を書き出す（45分） 付箋一枚に接点一つ。チャネルやフェーズを気にせず、まず全員が知っている接点を書く。マーケティング、カスタマーサポート、プロダクト、物流など部門をまたいだメンバーが参加することで、見えていなかった接点が出てくる。 Step 3: マップに配置し、重複と空白を発見する（45分） 時間軸とチャネル軸のマトリクスに接点を貼り出す。ある旅程のフェーズに接点が密集し、別のフェーズに何もないことが見えてくる。空白地帯は顧客が「放置される」場所だ。 Step 4: 体験の質を評価する（30分） 各接点に対して、現在の体験品質を簡単に評価する。「顧客はここで何を感じるか」を★1〜5で記入するだけでも十分だ。定性的な情報（ユーザーインタビューやNPS調査）があれば照合する。 Step 5: 優先接点を特定する（30分） 頻度が高く、体験品質が低い接点が改善の優先候補だ。また、顧客が意思決定する分岐点（比較検討、解約の決断）に隣接する接点は、影響が大きいため重点的に扱う。 デジタル・物理統合の課題 タッチポイントマッピングで頻繁に発見されるのは、デジタルと物理の断絶だ。アプリで注文した商品の配送状況がウェブでしか確認できない、オンラインで問い合わせした内容が店舗スタッフに伝わっていない——これらは部門ごとに接点を個別設計した結果として起きる。 IBMのサービスデザイン実践では、タッチポイントを顧客ライフサイクル全体にわたって一元管理し、データとAIを活用して一貫性を維持するアプローチが強調されている（IBM Consulting, 2025）。技術的な統合以前に、全接点を俯瞰する地図が必要だ。タッチポイントマッピングはその地図を作る作業に他ならない。 カスタマージャーニーマップとの使い分け カスタマージャーニーマップが顧客の感情・思考の流れを描くのに対し、タッチポイントマッピングは接触点の網羅的な棚卸しに主眼を置く。 実務では両方が必要になる場面が多い。まずタッチポイントマッピングで「何がどこにあるか」を把握し、次にカスタマージャーニーマップで「そこで顧客がどう感じているか」を重ねる。この順序で進めると、感情データに文脈が生まれる。 よくある失敗パターン 接点を増やしすぎる タッチポイントを洗い出すとリストが膨らむ。「すべてを最適化しなければ」という発想は禁物だ。全接点を改善しようとすると、何も改善されないまま終わる。影響が大きく、体験が低い箇所に絞ることが鍵になる。 顧客視点を失う マッピング作業が進むと、いつの間にか社内の業務プロセス整理に変わっていることがある。常に「顧客はここで何を体験しているか」という問いを起点に戻る必要がある。 一度描いて終わりにする サービスが変わり、チャネルが増えれば接点の構造も変わる。タッチポイントマップは生きた文書として定期的に更新することで価値が持続する。 出発点は「現状の棚卸し」 タッチポイントマッピングの価値は、設計の完成形を描くことにあるのではない。現在の顧客体験の全景を、チーム全員が初めて同じ地図の上で見る——その共通認識の形成こそが、その後の改善を駆動する。 どんな精巧な設計論よりも、現状を正確に知ることが先だ。まず接点を洗い出し、地図に貼り、眺める。「こんなに接点があるとは思わなかった」という発見が、次の問いを生む。 --- ### ダブルダイヤモンドとは何か——なぜ「問題空間」と「解決空間」を分けるのか URL: https://designthinking.studio/articles/double-diamond/ > ダブルダイヤモンドとは、英国Design Councilが2004年に提唱したデザインプロセスモデル。「正しい問題を発見してから、正しい解決策を作る」構造がなぜ機能するのか、d.schoolモデルとの違いや限界も交えて理論面から解説。実践的な進め方は実践ガイドへ。 ダブルダイヤモンド（Double Diamond）は、「正しい問題を見つけてから、正しい解決策を作る」という設計原理を視覚化したフレームワークです。英国Design Councilが2004年に発表し、世界中のデザイン教育・ビジネス実務で標準的なプロセスモデルとして活用されています。 一文で定義すると、ダブルダイヤモンドとは「問題空間」と「解決空間」を分離し、それぞれで発散と収束を1往復ずつ行う4フェーズのプロセスです。用語の定義だけを素早く確認したい場合は用語辞典のダブルダイヤモンド項目へどうぞ。 この構造がなぜ機能するのかという理論的背景に加えて、実務で起きやすい失敗パターンと業種別の適用例を厚く扱う点が、実践ガイドとの役割分担です。各フェーズの具体的な進め方（インタビュー設計、親和図法の手順、プロトタイピングの手法）まで手順として知りたい場合はダブルダイヤモンド実践ガイドを合わせて読んでください。 「解決策はあるのに、問題が間違っている」という落とし穴 プロダクト開発やサービス改善の現場で、こんな事態が起きていないでしょうか。ユーザーが離脱する原因を「UIの分かりにくさ」だと断定し、画面を全面リニューアルしたのに、離脱率が変わらない。 後から調べてみたら、問題はUIではなく料金体系にあった。 ワークショップでよく起こるのは、課題が十分に探索されないまま解決策の議論に突入するパターンです。「解決策を考えるのは楽しいが、問題を掘り下げるのは地味で退屈」という心理が、チームを誤った方向に導きます。 この「焦り」には構造的な理由がある 実際にやってみると、チームが解決策に飛びつく背景には理由があります。進捗を示さなければならないプレッシャー、上層部への報告、四半期ごとの成果要求。 「まだ問題を探索しています」という報告は、組織内で評価されにくい。 結果として、最初に思いついた仮説をそのまま正式な「問題定義」にしてしまう。この構造的なバイアスに対抗するために、ダブルダイヤモンドは「問題の探索にも十分な時間を使え」と明示的にプロセスに組み込んだのです。 4フェーズという構造：分けることの意味 Design Councilは2004年にこのモデルを発表し、翌2005年の調査報告書「A Study of the Design Process」で、11社のグローバル企業のデザインプロセスを詳細に調査し、成功するプロジェクトに共通するパターンを4つのフェーズ――Discover、Define、Develop、Deliverとして体系化しました。この調査は2007年に「Eleven Lessons: Managing Design in Eleven Global Brands」として刊行されています。 第1ダイヤモンド：正しい問題を見つける Discover（発見）では、「問題はすでに分かっている」という前提をいったん脇に置き、課題領域を広く探索します。続くDefine（定義）で、その情報を「解くべき本質的な問題」1つへ収束させる。ここで作られる問いこそが、第2ダイヤモンドの出発点だ。問題定義の質が最終的なソリューションの質を決定するため、特に唯一の正解が存在しないウィキッド・プロブレムに取り組む場合、この絞り込みを急がないことが後工程全体の質を左右します。 第2ダイヤモンド：正しい解決策を作る Develop（開発）で解決策の選択肢を多様なアプローチから幅広く発想し、Deliver（提供）でプロトタイプとユーザーテストを通じて1つの解決策へ絞り込み実装します。重要なのは、第1ダイヤモンドで定めた問いに対してのみこの探索が始まるという順序そのものです。「最初のアイデアがベストであることは、ほぼない」という前提に立つからこそ、Develop フェーズでの発散が意味を持ちます。 各フェーズで実際に何をするか（インタビュー設計、親和図法（KJ法）の進め方、Crazy 8sなどのプロトタイピング手順）を1つずつ知りたい場合はダブルダイヤモンド実践ガイドにまとめています。構造の理由を押さえたところで、続いて実務のつまずきどころを具体的に見ていく。 実務でよくある5つの失敗パターン ダブルダイヤモンドの理論を理解していても、実際に運用すると同じ失敗が繰り返されます。特によく見られる5つのパターンを、原因と対策とあわせて挙げます。 - Discoverを「情報収集タスク」として消化してしまう: Discoverフェーズを、期日までにインタビュー件数やアンケート回収数をこなす作業だと捉えてしまうケースです。件数は集まっても、チームの問題理解が更新されないまま次工程に進んでしまうため、Defineの収束が最初の思い込みをなぞるだけで終わります。対策は、Discoverの終了条件を「当初の仮説が崩れた回数」で定義することです。 - Defineで「多数決」が起きる: 収束フェーズで、集まった情報の中から声の大きい人の意見や、経営層が期待していそうな結論を選んでしまうケースです。Defineは本来、集めた事実から論理的に導かれる問いを選ぶ工程ですが、合意形成の場に変質すると、最初から答えが決まっていたのと同じ結果になります。問題定義案を提出する際は、根拠となったデータや発言を必ず添付するルールを設けておく。 - Developで「実現可能性」を先に評価してしまう: 発散フェーズであるDevelopで、「予算的に無理」「技術的に難しい」という評価を早期に始めてしまうケースです。評価は収束フェーズであるDeliverの役割であり、Developで評価を始めると選択肢の幅が狭まり、最初に思いついた無難な案しか残りません。Develop中は評価コメントそのものを禁止し、アイデア出しの場と評価の場を分けてしまうのが手っ取り早い。 - Deliverでプロトタイプを作らずに実装へ進む: 納期が迫っていることを理由に、Deliverのプロトタイプ検証を省略していきなり本実装に入るケースです。検証されていない解決策が的外れだった場合、実装後の手戻りコストはプロトタイプ段階で修正するよりもはるかに大きくなります。対策は、どれほど納期が厳しくても「最小限のプロトタイプで1回だけ確認する」工程を死守することだ。 - フェーズの往復を「計画の失敗」だと捉えてしまう: Developで検討した結果、Defineの問題定義に戻る必要が生じたときに、それを計画通りに進まなかった失敗だと捉えてしまうケースです。ダブルダイヤモンドは本来フェーズを行き来する前提のフレームワークであるため、往復自体は正常な動作だ。対策は、プロジェクト開始時点で「後戻りが起きうる」ことをステークホルダーへ事前共有し、往復を精度向上の工程として位置づけておくことです。 業種別に見る適用例 抽象的な説明だけでは、実務にどう落とし込むかがつかみにくいままです。3つの異なる業種で、4フェーズがどう機能するかを見てみます。ここに登場する企業名・数値は、構造を理解するための仮想シナリオです。 SaaS：解約直前の離脱率改善 Discover（発見）: チームは「UIが分かりにくいから離脱する」という仮説を検証しないまま、リニューアル案の検討に入っていました。ここでDiscoverをやり直すとしたら、まずやるべきはユーザーインタビューと行動ログの突き合わせです。画面遷移ログを見ると、離脱の多くは「料金確認画面」の直前で起きていました。 Define（定義）: 集めた情報を1つの問いに収束させます。「UIの分かりにくさ」ではなく、「料金体系が事前に把握できないことへの不安」。この収束作業こそが第1ダイヤモンドの本体です。 Develop（開発）: 問いが変われば、発想の幅も変わります。料金シミュレーター、段階的な見積り表示、担当者への即時チャット――UIの改修は、数ある選択肢の1つでしかない。 Deliver（提供）: 料金シミュレーターのプロトタイプを作り、一部ユーザーへ試験提供します。効果が確認できた案だけを、本実装に進めます。 行政サービス：申請手続きのオンライン化 Discover: 「申請フォームが複雑だから利用率が低い」という仮説のもと、UI改善だけを検討していました。窓口担当者への聞き取りを行うと、離脱の多くは添付書類の準備段階、つまりフォームを開く前で起きていることが分かりました。 Define: 問いを「フォームの分かりやすさ」から「申請前に何が必要かが事前に分からない不安」へ収束させます。 Develop: 必要書類を事前診断するチェックリスト、窓口での書類代行サービス、オンライン申請前の相談チャットなど、フォーム改修とは別方向の選択肢が広がる。 Deliver: 必要書類の事前診断チェックリストを試験提供し、申請完了率を計測します。 製造業：新製品の企画会議 Discover: 「若年層に売れていないのはデザインが古いから」という仮説から、デザイン刷新の議論に入っていました。営業データを見ると、購入層自体が想定と異なり、若年層は認知の時点で離脱していることが判明します。 Define: 問いを「デザインの古さ」から「若年層に商品の存在自体が届いていないこと」へ収束させる。 Develop: デザイン刷新は選択肢の1つに後退し、販路の見直し、SNSでの見せ方、価格帯の再設計など、認知経路そのものを変える案が浮上します。 Deliver: 低コストで試せる販路（SNS広告の小規模テスト）から着手し、反応を見て投資判断します。 3業種に共通しているのは、最初の仮説（UI・フォーム・デザイン）が、Discoverのやり直しによって覆った点です。 問いを立て直すことなく解決策に進んでいたら、いずれも成果は出なかったはずです。 d.schoolの5フェーズモデルとの比較 ダブルダイヤモンドとd.schoolのデザイン思考5フェーズは、よく比較されます。本質的な思想は共通しているが、強調するポイントが異なる。 | 観点 | ダブルダイヤモンド | d.school 5フェーズ | |---|---|---| | 発祥 | 英国Design Council（2004年） | スタンフォード大学（2005年） | | フェーズ数 | 4（Discover / Define / Develop / Deliver） | 5（Empathize / Define / Ideate / Prototype / Test） | | 最大の特徴 | 発散と収束のリズムを明示 | 共感（Empathize）を独立フェーズとして重視 | | プロセス観 | 2つのダイヤモンド＝問題空間と解決空間の分離 | 5フェーズの反復（イテレーション） | | 主な活用文脈 | サービスデザイン、政策デザイン | プロダクト開発、イノベーション教育 | d.schoolモデルが「共感から始める」ことを強調するのに対し、ダブルダイヤモンドは「問題の探索と解決策の探索を明確に分ける」ことを強調します。プロジェクトの性質に応じて使い分けるのが現実的です。 使い分けの目安は「問題の輪郭がどれだけ見えているか」です。行政のサービス改善のように関係者が多く、そもそも何が課題かの合意すら取れていない場合は、問題空間と解決空間を明確に切り分けるダブルダイヤモンドの構造が効きます。逆に、プロダクトの新機能開発のように課題自体は共有されていて、ユーザーへの共感を起点に素早くアイデアへ落とし込みたい場合は、Empathizeを独立フェーズに置くd.schoolモデルの方が着手しやすいことが多いです。 2019年の進化：プロセスから文化へ Design Councilは2019年に、ダブルダイヤモンドを拡張したFramework for Innovationを発表しました。2004年に発表され2005年の調査報告書で体系化された初版が「何をどの順番でやるか」というプロセスを定義したのに対し、2019年版は人間中心・視覚的コミュニケーション・協働・反復という4つのデザイン原則を加え、組織文化やリーダーシップといった実行環境まで視野を広げています。 この拡張は、プロセスモデルだけでは現場の変革は起きないという、Design Councilの15年にわたる運用実績から得た教訓を反映したものです。原則ごとの具体的な運用方法は実践ガイドで扱っているため、ここでは「プロセスから文化へ」という射程の拡張だけを押さえておく。 ダブルダイヤモンドの限界として指摘されること 上で挙げたのはチームの運用によって起きる失敗ですが、ここではフレームワークそのものに内在する限界を扱います。導入・運用する前に押さえておくべき限界が、少なくとも3つあります。 図の直線性と実務のギャップ: 2つの菱形として描かれる図は美しく分かりやすい一方、実際のプロジェクトはフェーズを何度も行き来するため、図通りに直線的に進むケースはむしろ稀です。図を「順守すべき手順」だと誤解すると、かえって柔軟な手戻りを妨げます。 期間・予算が固定されたプロジェクトとの相性: 第1ダイヤモンドに十分な時間を割く前提のフレームワークであるため、納期と予算が先に固定されているプロジェクトでは、Discoverフェーズが形骸化しやすいという制約が生じます。この場合、無理にダブルダイヤモンド全体を適用するより、問題定義がすでに済んでいる前提で第2ダイヤモンドに近い性質を持つ手法（後述のデザインスプリントなど）と組み合わせる判断も現実的です。 「発散」の質はフレームワークが保証しない: ダブルダイヤモンドはあくまで思考の型であり、Discoverでどれだけ多様な情報を集められるか、Developでどれだけ幅広い解決策を発想できるかは、フレームワークそのものではなく実施するチームのスキルと時間投資が決める。 日本企業でこの構造が機能しにくい理論的な理由 ダブルダイヤモンドの理論そのものは万国共通ですが、日本企業でこの構造を導入しようとすると、強い抵抗に遭うことがあります。その原因の多くは手法の理解不足ではなく、意思決定の構造にある。 稟議制度や多階層の合意形成プロセスでは、「まだ結論が出ていない」という状態そのものが報告しにくいという力学が働きます。第1ダイヤモンドのDiscoverフェーズは本質的に「まだ問題が分かっていない」ことを前提にした発散フェーズですが、この状態を上長やクライアントへ正式な進捗として報告する仕組みが用意されていないケースが少なくありません。冒頭で述べた「進捗を示さなければならないプレッシャー」は、承認階層が多くなるほど増幅されます。 この構造的な摩擦を軽減するには、Discoverフェーズで何を「成果物」とみなすかを見直すとよい。「まだ分かっていないことのリスト」や「検証すべき仮説の数」を進捗指標として報告できるよう、プロジェクト開始前に合意しておく。業種別の理論的な適用の勘所は上の「業種別に見る適用例」で扱いましたが、日本企業特有の運用ノウハウ（社内の合意形成プロセスへの落とし込み方など）はダブルダイヤモンド実践ガイドの「日本企業での適用」でさらに詳しく紹介しています。 実務で使うための4つの指針 第1ダイヤモンドに十分な時間を投資する 多くのプロジェクトで、Discoverフェーズが不十分なまま解決策に進んでしまいます。全体の工程の少なくとも3分の1を、Discoverフェーズと Defineフェーズに割り当ててください。問題の理解が浅いまま作った解決策は、手戻りコストが膨大になります。 発散と収束を意識的に切り替える 「今は広げるフェーズか、絞るフェーズか」をチーム全員が共有できているかどうかで、議論の生産性は大きく変わる。 発散中に「それは現実的じゃない」と評価を始めたり、収束中に「もっと他の可能性は」と広げ始めたりするのは、プロセスの混乱を招きます。この2つのモード（発散思考と収束思考）は同時に成立しないため、「今どちらのモードにいるか」の明示だけでも会議の質は変わります。 直線的に進まなくてよい ダブルダイヤモンドは直線的なプロセスに見えますが、実際にはフェーズ間を行き来するのが当然です。Developで解決策を検討した結果、問題定義に戻る必要が生じることは珍しくありません。図の美しさに縛られず、必要なときに戻る柔軟性を持ちましょう。 最初のミーティングで使える問いのテンプレート Discoverフェーズの開始時に、次の3つの問いをチームで共有すると、思い込みでの飛びつきを防ぎやすくなります。 - 「この問題を、誰が最初にそう定義したか？」（声の大きい人の思いつきが問題定義になっていないか） - 「この問題の裏付けとなるデータは何か？」（数値・ログ・インタビューなど、確認済みの根拠があるか） - 「もし前提が違っていたら、どんな別の問題がありえるか？」（1つの仮説に固執していないか） これらの問いに詰まるようであれば、それはまだDiscoverフェーズが終わっていないというサインです。 次に進める前に確認するチェックリスト 上で挙げた失敗パターンと指針を、フェーズの節目で確認できる形にまとめておきます。 - Discoverの終了条件を件数でなく「仮説が崩れた回数」で定義したか - Define時の問題定義案に、根拠となったデータや発言を添付しているか - Develop中に実現可能性の評価を始めていないか（評価はDeliverの役割） - Deliver前に、最小限のプロトタイプ検証を確保しているか - フェーズの後戻りが起こりうることを、ステークホルダーへ事前共有したか まず「問い」を疑うことから始める ダブルダイヤモンドが教える最も重要な教訓は、「正しい問いなしに、正しい答えは生まれない」ということです。新規事業の立ち上げ、サービスの改善、組織課題の解決。どんなプロジェクトであっても、解決策を考える前に「そもそもこの問いは正しいのか」と立ち止まる習慣が、成果の質を根本的に変えます。 次のプロジェクトで、最初のミーティングで解決策の議論を禁止してみてください。 代わりに「この問題について、私たちが知らないことは何か」を30分議論する。その30分が、数ヶ月の手戻りを防ぐかもしれません。 具体的な進め方（インタビュー手法、ワークショップ設計、実践の落とし穴）はダブルダイヤモンド実践ガイドへ。 よくある質問 ダブルダイヤモンドとは何ですか？ 英国Design Councilが2004年に発表したプロセスモデルで、「正しい問題を発見してから、正しい解決策を作る」という2段階を、発散と収束のリズムで構造化したものです。問題空間・解決空間それぞれで発散と収束を1回ずつ踏むため、図が2つの菱形として描かれます。 なぜ「2つの」ダイヤモンドがあるのですか？ 問題を定義する作業と解決策を作る作業を1本の流れにしてしまうと、多くの場合「最初に思いついた問題」に対して解決策を作ることになるからです。菱形を2つに分けることで、「まず問題を発散・収束させる」「次に解決策を発散・収束させる」という切り替えを構造として強制します。 ダブルダイヤモンドとd.schoolの5フェーズモデルの違いは何ですか？ 上の比較表の通り、d.schoolモデルは共感（Empathize）を独立フェーズとして重視するのに対し、ダブルダイヤモンドは問題空間と解決空間の分離そのものを強調します。対立する理論ではなく、プロジェクトの性質に応じて使い分ける、あるいは併用するものです。 実務でよくある失敗にはどんなものがありますか？ 最も多いのは、Discoverを情報収集の作業としてこなしてしまい、チームの問題理解が更新されないまま次工程に進むパターンです。ほかにも、Develop中に実現可能性の評価を始めてしまう失敗や、Deliverのプロトタイプ検証を省略していきなり実装してしまう失敗も典型的だ。詳細は本文「実務でよくある5つの失敗パターン」を参照してください。 UXデザイン以外の分野でも使えますか？ 使えます。行政サービスの申請手続き改善や製造業の新製品企画など、「最初に立てた問いが本当に正しいか」を確認する必要がある場面であれば、業種を問わず適用できます。詳細は本文「業種別に見る適用例」を参照してください。 1人やスモールチームでも使えますか？ 使えます。ダイヤモンドの形は複数人の合意形成を可視化する図でもありますが、核心は「発散では評価をしない」「収束では新しい選択肢を増やさない」という自分自身への規律です。1人での作業でも、この切り替えを意識するだけで問題定義の精度は変わります。 どんなプロジェクトに向いていますか？ サービスデザインや政策デザインのように、着手時点で「本当の問題」が曖昧なプロジェクトに特に向く。逆に問題がすでに明確で、解決策の検証速度が最優先なら、第2ダイヤモンドに近い性質を持つデザインスプリントのような手法の方が適しています。 ダブルダイヤモンドのデメリット・限界は何ですか？ 図が直線的に見えるため実務での行き来を軽視しやすい点、納期・予算が先に固定されたプロジェクトではDiscoverフェーズが形骸化しやすい点、フレームワークそのものは発散の質を保証しない点が主な限界です。詳細は本文「ダブルダイヤモンドの限界として指摘されること」を参照してください。 ダブルダイヤモンドを初めて使うとき、何から始めればいいですか？ いきなり全社的なプロセスとして導入するのではなく、1つの小さなプロジェクトのDiscoverフェーズだけを試すのが現実的な出発点です。「この問題を、誰が最初にそう定義したか」を問い直すところから始めてください。具体的な進め方は実践ガイドにまとめています。 --- 参考文献 - Design Council, "A Study of the Design Process", 2005 - Design Council, "Eleven Lessons: Managing Design in Eleven Global Brands", designcouncil.org.uk, 2007 - Design Council, "What is the framework for innovation? Design Council's evolved Double Diamond", designcouncil.org.uk, 2019 - Tim Brown, Change by Design, HarperBusiness, 2009 --- ### チェンジマネジメント × デザイン思考 統合導入論 — 変革を定着させる7原則 URL: https://designthinking.studio/articles/change-management-design-thinking-integration/ > チェンジマネジメントとデザイン思考を統合した組織変革の設計論。Kotterの8ステップとデザイン思考5フェーズの対応関係を整理し、変革が定着するための7つの実践原則を解説する。 「デザイン思考の研修はやった。しかし変革は定着しなかった。」 この言葉は、数百社の組織変革に伴走してきたコンサルタントが最もよく耳にする言葉のひとつだ。チェンジマネジメントの専門家も、デザイン思考のファシリテーターも、それぞれ「自分たちの手法が正しい」と主張する。しかし実際の組織変革の現場では、どちらか一方だけでは不十分だという現実がある。 本記事では、チェンジマネジメントとデザイン思考を統合的に使うための理論的枠組みと、変革を定着させる7つの実践原則を提示する。 --- チェンジマネジメントとデザイン思考：それぞれの弱点 チェンジマネジメントの強みと限界 チェンジマネジメントの代表的フレームワークであるKotterの8ステップモデルは、組織変革の「構造的プロセス」を設計する上で強力なツールだ。緊急性の醸成から短期的成果の実現、変革の企業文化への定着まで、組織全体を動かすための段階的な設計を提供する。 しかしKotterモデルの弱点は、「何を変えるか」の答えを与えてくれないことだ。 8ステップは変革の「プロセス設計」であり、「変革の内容設計」ではない。「顧客中心の組織に変革する」という方向性は示せても、「具体的に何をどう変えればよいか」を探索する手法を内包していない。 デザイン思考の強みと限界 デザイン思考は「変革の内容を探索する」プロセスにおいて強力だ。ユーザーインタビューによる深い共感、問題の再定義、プロトタイプによる仮説検証。この探索プロセスは、「本当に解くべき問題」を発見するための精緻な方法論だ。 しかしデザイン思考の弱点は、組織の「抵抗」と「慣性」に対応するフレームワークを持たないことだ。 良い解決策を見つけても、組織の構造・文化・評価制度が変わらなければ、その解決策は実装されない。ワークショップでの発見が現場に戻ると消える理由の一つは、ここにある。 統合の必然性 チェンジマネジメントは「変革のプロセスを設計」する。デザイン思考は「変革の内容を探索」する。 この2つは互いの弱点を補完する関係にある。統合されることで初めて、「何を変えるかを正しく探索し、それを組織に定着させる」という完結した変革設計が可能になる。 --- Kotter8ステップとデザイン思考5フェーズの対応 実際にやってみると、Kotterとデザイナーのプロセスはほぼすべてのフェーズで対応関係を持つことが分かる。 ステップ1〜2（緊急性醸成・連帯チーム形成） × 共感フェーズ Kotterモデルの最初の2ステップは、「なぜ変革が必要か」の危機感を組織に醸成し、変革を推進するチームを作ることだ。 デザイン思考の共感フェーズは、この「緊急性の根拠」を作る強力なツールになる。 現場のユーザー（顧客・社員・パートナー）のリアルな声を、変革推進チームが直接インタビューで収集する。「データが示す問題」ではなく「人間が語る問題」は、緊急性の醸成において圧倒的な説得力を持つ。 200回以上のワークショップで繰り返し観察されてきたのは、「データを見せても動かなかった経営層が、ユーザーの肉声を聞いた瞬間に変革への緊急性を感じた」という場面だ。 ステップ3〜4（ビジョン策定・コミュニケーション） × 定義フェーズ ビジョンを策定するためには、「問題の本質を正確に定義する」工程が必要だ。デザイン思考の定義フェーズ（How Might We の策定）は、この問題定義を構造的に行うためのツールだ。 「顧客価値を高める組織に変革する」というビジョンは抽象的すぎて行動に結びつかない。 定義フェーズを経ることで、「どうすれば、初回接触から2週間以内に顧客が価値を実感できるか」という具体的な問いに変換される。この問いの具体性が、組織全体へのコミュニケーションを機能させる。 ステップ5〜6（エンパワーメント・短期成果） × 創造・プロトタイプフェーズ 変革に向けた行動の障壁を取り除き（エンパワーメント）、短期的な成果を作るフェーズは、デザイン思考の創造とプロトタイプフェーズと完全に対応する。 低忠実度プロトタイプは、「短期的成果」の最短ルートだ。 大規模な変革を全部実装するのではなく、「2週間で動くプロトタイプを作って試す」ことで、ステップ6で求められる「短期的勝利」を組織に見せることができる。プロトタイプが失敗しても「学習の成果」として可視化できるため、Kotterの「変革への後退」を防ぐ安全装置にもなる。 ステップ7〜8（成果の拡大・文化への定着） × テストフェーズ テストフェーズは単なる検証ではなく、「何が効いて何が効かなかったかを学ぶ」プロセスだ。この学習の記録と共有が、Kotterの「成果の拡大」と「文化への定着」に不可欠な素材となる。 「このチームでうまくいったこと」を他部門に展開するためには、「なぜうまくいったか」の分析が必要だ。 テストフェーズの振り返りを丁寧に行い、他文脈でも再現可能な形に翻訳することで、変革が組織全体の文化として定着していく。 --- 変革を定着させる7原則 KotterとデザイナーのプロセスをN=260社以上の実践から統合すると、変革が定着する組織に共通する7つの原則が浮かび上がる。 原則1：「問いの共有」から始める 変革のゴールを「ビジョン」として示す前に、「なぜ変革が必要か」という問いを組織全体で共有するプロセスを設計する。 ビジョンの押しつけは抵抗を生む。問いの共有は主体性を生む。 原則2：現場の声を変革の「証拠」にする 共感フェーズで得られたユーザーの声を、経営層に届ける仕組みを作る。「市場調査のデータ」より「現場インタビューの肉声」の方が、意思決定者の感情を動かす。証拠の形式が、緊急性の伝わり方を左右する。 原則3：小さな勝利を設計に組み込む 変革全体の達成を待つのではなく、6週間以内に「これが変わった」と言える小さな勝利を意図的に設計する。 小さな勝利は、変革の実現可能性への信頼を組織に植え付ける。 原則4：失敗を「学習の証拠」として語る プロトタイプの失敗を、「試みた証拠」「学習の成果」として積極的に共有する。失敗を隠す文化の中では、デザイン思考のプロトタイプ文化は育たない。 Kotterの「短期的勝利」の定義を「成功」だけでなく「有意義な学習」まで拡張することで、変革プロセスへの参加ハードルが下がる。 原則5：評価制度との整合を早期に設計する デザイン思考的行動（ユーザーインタビュー・プロトタイプ・失敗の記録）が「評価される」仕組みを、変革の初期段階で設計する。評価制度が変わらない限り、行動変容は定着しない。 これはKotterの「障壁の除去」（ステップ5）と直接対応する。 原則6：内部ファシリテーターを変革の核にする 外部のデザイン思考専門家は「教える」役割ではなく「コーチする」役割として設計する。変革の主体は常に内部にいる人間でなければならない。 変革期間の前半で、内部ファシリテーターの育成を最優先する。 原則7：変革の「物語」を継続的に語る Kotterが「変革の維持」（ステップ8）で最も重視するのは、「変革の物語を語り続けること」だ。デザイン思考のプロセスで生まれた具体的なストーリー（どんな顧客の声から始まり、何を試して、何が変わったか）は、この「物語」の最良の素材となる。組織の変革は、構造の変化ではなく語られる物語の変化として定着する。 --- 統合の実践：3ヶ月ロードマップ チェンジマネジメントとデザイン思考の統合を実際に設計する際の、最初の3ヶ月のロードマップを示す。 Month 1：問いを立てる - 週1〜2：共感インタビュー（外部ユーザー5名・内部関係者3名） - 週3：インサイトの整理とHMWの策定 - 週4：HMWの優先度投票と変革の問いの確定 この1ヶ月で、Kotterの「緊急性醸成」「連帯チーム形成」を、インタビューの実施という具体的な活動に変換する。 Month 2：試す - 週5〜6：アイデア創出とプロトタイプ設計 - 週7〜8：低忠実度プロトタイプの制作 - 週8：最初のユーザーテストと学習の記録 このフェーズで「短期的成果」を作る。完成品ではなく「学習の証拠」を短期的成果として定義することが重要だ。 Month 3：広げる - 週9〜10：テストの振り返りと改善 - 週11：内部での事例共有セッション - 週12：次のHMWの選定と次サイクルの設計 1回目のサイクルで得た学習を、2回目に活かす設計をする。変革は一度完成するものではなく、改善のサイクルが組織の標準的な動き方になることで定着する。 --- 「統合する」という知的誠実さ デザイン思考だけでも、チェンジマネジメントだけでも、組織変革の全体像には届かない。実際の組織変革の現場は、どちらか一方のフレームワークで解決できるほど単純ではない。 「自分たちの手法が最も有効だ」という専門家の主張は、多くの場合、自分が最も得意とする道具を優先する認知バイアスだ。 現場の問題は、その都度最も有効な道具を選ぶ判断力を必要とする。 チェンジマネジメントとデザイン思考を統合する視点は、「どちらが正しいか」ではなく「どの局面でどちらが有効か」を問う。その問い方自体が、組織変革を設計する人間に必要な最も根本的な思考姿勢だ。 組織への具体的な導入フローについてはデザイン思考の組織導入完全ガイドを、実際の失敗から学ぶにはデザイン思考 組織導入 失敗事例5選も合わせて読んでほしい。 変革プロセスで使うワークショップ手法として、アフィニティ・ダイアグラムもあわせて参照されたい。 --- 7原則 実装チェックリスト - [ ] 変革のゴールではなく「問い」から始めているか - [ ] 現場の肉声を証拠として経営層に届ける仕組みがあるか - [ ] 6週間以内の小さな勝利が設計されているか - [ ] 失敗を「学習の成果」として共有できる場があるか - [ ] 評価制度との整合が計画されているか - [ ] 内部ファシリテーターの育成計画があるか - [ ] 変革の物語を語り続ける仕組みがあるか --- ### データドリブン共感——定量データと定性インサイトをデザイン思考で統合する方法 URL: https://designthinking.studio/articles/design-thinking-data-driven-empathy/ > NPS・行動ログ・販売データと、インタビューや観察から得られる定性インサイト。この二つを別々に扱う組織は多い。デザイン思考の共感フェーズがどう両者を統合し、本質的な課題発見へ接続するかを実践的に解説する。 「データはある。でも何を作るべきかわからない」。この言葉を、新規事業やプロダクト開発の現場で聞いたことはないだろうか。 ダッシュボードは毎朝更新される。NPS、継続率、クリック率、ファネル離脱ポイント——数字は揃っている。しかしその先が詰まる。「離脱率が38%に上昇した。なぜか?」「NPS推奨者と中立者の差分は何か?」数字は問いを立てるが、答えは出さない。 逆のケースもある。インタビューを重ね、観察調査を丁寧に実施した。「ユーザーが感じているのはこういうことだ」という確信はある。しかし規模感がわからない。一部の声なのか、多数派の問題なのか。経営層への説明で必ず「それは何人の話?」と問い返される。 定量データと定性インサイトは、別々に扱われるかぎり、両方の弱点を抱えたままだ。デザイン思考の共感フェーズは、この二つを統合することで初めて機能する。 データドリブンと共感は対立しない 「データ重視」と「ユーザー共感」は対立概念ではない。にもかかわらず、組織の中では分断されやすい。定量分析はビジネスアナリティクスやデータサイエンスの領域、定性リサーチはUXリサーチやデザイン部門の領域——縦割りで専門化が進むほど、統合の機会は失われる。 データドリブンな共感とは、定量データを「どこに問いを立てるか」の地図として使い、定性調査を「なぜそうなのか」の掘削機として使うアプローチだ。地図なしに掘削しても広大な土地を探し続けるだけ。掘削なしに地図を眺めても、宝の場所はわからない。 共感フェーズの目的はユーザーの文脈・行動・動機・感情の深い理解だが、「どのユーザー」「どの行動」「どの場面」にフォーカスするかは、定量データが示してくれる。逆に、定量データの解釈に深みをもたらすのは定性インサイトだ。 定量データを「共感の入り口」として使う 定量データから共感フェーズを起動するには、数字を「答え」として読むのではなく、「問いの地図」として読む習慣が必要だ。 具体的には、異常値・逆張り・セグメント差分に注目する。 異常値は仮説の宝庫だ。 全体の離脱率が20%の中で、特定のセグメントだけ60%の離脱が起きているとする。その数字は「なぜこのセグメントだけ離脱するのか」という問いを立ててくれる。ここから先は定性調査の仕事だ。 逆張りユーザーは隠れたインサイトを持つ。 NPSの推奨者と批判者の行動ログを比較すると、操作パターンや使用頻度に差が見つかることがある。同じ製品を使いながら、なぜ評価が分かれるのか。アンケートのスコアだけでは見えない文脈が、そこにある。 セグメント差分は文脈の違いを示唆する。 年齢・職種・使用デバイス・利用シーンなど、どの軸でセグメントを切っても行動が変わらないなら、差分から学べることは少ない。差分が大きいほど、「このセグメントが違う使い方をしているのはなぜか」という共感の問いが生まれる。 定性調査で「なぜ」を掘る 地図ができたら、掘削を始める。ステークホルダーインタビューや観察調査を設計する際、定量データが示した問いを起点に対象者と問いを絞る。「全ユーザーを理解しよう」ではなく、「離脱率が突出しているこのセグメントを理解しよう」と目標が定まる。 定性調査のサンプル数をめぐる議論は多い。「何人インタビューすれば十分か」という問いへの実践的な答えは、定性調査のサンプルサイズで整理しているが、重要な前提は「代表性ではなく多様性を担保すること」だ。定量調査が代表性を担う。定性調査は多様な文脈と例外的なケースを発見するためにある。 インタビューで引き出すべきは意見ではなく行動と文脈だ。「このアプリを使いやすいと思いますか」という質問は意見を引き出す。「最後にこのアプリを使ったのはいつで、その時何をしていましたか」は行動と文脈を引き出す。ユーザーは自分の行動の理由を正確に報告できないが、具体的なエピソードは語れる。そのエピソードの中に、数字が語れなかった「なぜ」が埋まっている。 SpotifyとAmazonの統合アプローチ データドリブン共感の実践例として、SpotifyとAmazonの取り組みは参照価値が高い。 Spotifyは「データとリスナー共感の統合」を組織設計に組み込んだ。 Spotifyのプロダクト開発チームは、定量的なストリーミングデータ（再生数・スキップ率・プレイリスト追加率）と定性的なユーザーリサーチを並走させる体制を持つ。Discover Weekly（週次推薦機能）の開発は、「なぜユーザーは自分でプレイリストを作るのか」という定性的な問いから始まった。データは「ユーザーは多くの曲をスキップする」という事実を示したが、インタビューが明らかにしたのは「発見したい気持ちはあるが、選ぶのが面倒」という文脈だった。数字だけでは「スキップ率を下げる」という解決策しか見えなかったが、定性インサイトが「キュレーションを自動化する」という別の解を開いた。 Amazonは「フリクションの発見」にデータと観察を組み合わせる。 Amazonの1-Click購入機能は、ユーザビリティテストとチェックアウトのドロップオフデータを組み合わせて設計された。カート放棄率というデータは「問題がある」ことを示したが、「何が問題か」を明らかにしたのは実際の購入シーンの観察だった。ユーザーが支払い情報の入力で手が止まること、その間に「本当に必要か」という迷いが生まれることが、定性観察から見えた。ワンクリックは数字への応答ではなく、文脈への応答だ。 インサイト統合の実践ステップ 定量と定性を統合してインサイトを導くプロセスは、インサイト統合の方法論で詳しく解説しているが、データドリブン共感に特化した実践ステップを示す。 ステップ1: 定量データで「どこに問いを立てるか」を決める。 セグメント別・フェーズ別・時系列での差分分析を行い、「なぜここだけ違うのか」という問いが生まれる箇所を特定する。この段階でリサーチ対象とリサーチ問いを絞る。 ステップ2: 問いに対応するインタビュー・観察を設計する。 「なぜこのセグメントだけ離脱するのか」という問いがあるなら、対象者は「離脱したユーザー」を中心にリクルーティングする。問いと対象者がずれると、定性調査の結果が定量データの問いに答えられない。 ステップ3: 定性データをコーディングし、定量パターンと照合する。 インタビューや観察から得たエピソードをテーマ別にコーディングし、「このテーマは定量データのどのパターンに対応するか」を照合する。完全に対応しないテーマは、まだデータ化されていない現象の候補だ。 ステップ4: ギャップを「仮説」として扱う。 定性インサイトが定量パターンを説明しない場合、それは測定指標の設計が現象を捉えていない可能性がある。「このインサイトを検証するには何を測定すべきか」という問いが、次の定量調査の設計につながる。 このサイクルはデザインリサーチとマーケットリサーチの違いでも論じているが、検証と発見の往復こそが両者を統合する実践の本質だ。 デザイン思考がKPIを変える データドリブン共感の成熟した実践は、最終的にKPI設計そのものを変える。 多くの組織が測定しているのは「行動の結果」だ。購入率、継続率、NPS——これらは行動が起きた後の痕跡だ。しかし共感フェーズで得られるインサイトは、「なぜその行動が起きるか」の文脈を示す。文脈を理解すれば、結果の前兆となる「先行指標」が設計できる。 SpotifyがSkip率だけでなく「曲の30秒以上再生率」を先行指標として重視するのは、行動の結果を待たずに「ユーザーが曲を受け入れたか」を早期に検知するためだ。この指標は、データ分析だけでは発想できない。「ユーザーは何をもって『気に入った』と感じるか」という定性的な理解が先にある。 KPIの設計思想についてはデザイン思考とKPI測定で詳しく論じているが、測定すべき指標はユーザーの文脈から逆算されるべきであり、事業の都合から作られるべきではない、というのがデザイン思考の立場だ。 統合を阻む組織の壁 技術的な手順より難しいのは、組織の壁を越えることだ。 データサイエンスチームとUXリサーチチームが別々に存在し、それぞれの成果物が別々の会議で消費される組織では、統合は起きない。データ分析のレポートがプロダクト定例で共有され、ユーザーインタビューのサマリーがデザインレビューで共有されるという分断が続く限り、数字とエピソードが出会う機会はない。 統合を実現する最も確実な方法は、同じチームの中にデータ分析と定性リサーチを同時に配置することだ。 SpotifyがSquadモデルで実現したのはこの構造だ。機能横断チームの中にデータアナリスト、UXリサーチャー、プロダクトマネージャーが同席することで、「この数字が意味することをインタビューで確認しよう」という対話が自然に起きる。 組織設計を変えられない場合でも、共同リサーチプロセスの設計は有効だ。定量分析のレポートをUXリサーチャーがレビューし、「ここを深掘りすべき」という問いを共同で立てる。インタビュー設計の段階からデータアナリストを入れ、「この観察結果が真なら、データ上ではどのパターンになるか」を事前に仮説化する。こうした接点を意図的に作ることが、分断を埋める第一歩だ。 --- 定量データは「どこを掘るか」を教える。定性インサイトは「何が埋まっているか」を教える。この二つを統合した共感は、アンケートデータの平均値でも、少数インタビューの印象でもない——測定された現象の背後にある人間の文脈の理解だ。 デザイン思考の共感フェーズは、この統合を組織的に実現するための構造を提供する。データは問いを立て、インサイトが答える。その往復こそが、「データはあるが何を作ればいいかわからない」という状況を抜け出す道だ。 --- 参考文献 - Rikke Friis Dam & Teo Yu Siang, "Empathize with Users to Build Products That Work," Interaction Design Foundation, 2024. https://www.interaction-design.org/literature/article/empathize-with-users-to-build-products-that-work - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015. https://www.designkit.org/resources/1 - Spotify Engineering, "How We Built the Discover Weekly Playlist," Spotify Engineering Blog, 2015. https://engineering.atspotify.com/2015/12/how-spotify-built-discover-weekly/ - Creswell, J. W. & Plano Clark, V. L., Designing and Conducting Mixed Methods Research, 3rd ed., SAGE Publications, 2017. - Nielsen, J. & Landauer, T. K., "A mathematical model of the finding of usability problems," Proceedings of ACM CHI'93 Conference, 1993, pp. 206–213. --- ### デザインスプリント：Google Venturesが生んだ5日間の検証メソッド URL: https://designthinking.studio/articles/design-sprint-google/ > Google Venturesが開発したデザインスプリントの全体像を解説。5日間のプロセス、デザイン思考との違い、導入のポイントまで実践的にカバー。 デザインスプリントは、たった5日間でアイデアの検証を完了させるためのフレームワークです。Google Ventures（現GV）のJake Knappが開発し、スタートアップから大企業まで世界中で採用されています。デザイン思考の実践的な応用形として位置づけられます。 「何ヶ月もかけたのに、ユーザーに刺さらなかった」問題 新規事業やプロダクト開発の現場で、こんな経験はないでしょうか。半年かけて作り込んだプロダクトが、リリース初日にユーザーから「求めていたのはこれじゃない」と言われる。 会議を何十回も重ねたのに、結局誰も意思決定できないまま時間だけが過ぎていく。 ワークショップでよく起こるのは、アイデア出しは盛り上がるのに、その後のアクションが止まるパターンです。発散は楽しいが、収束と検証に踏み込めない。 結果として、ホワイトボードに貼られた付箋だけが成果物になってしまいます。 現場の「あるある」は構造的な問題 この状況に心当たりがある方は少なくないはずです。実際にやってみると、問題の根っこは個人の能力ではなく、プロセスの不在にあることがほとんどです。 「もっとリサーチが必要」「まだ議論が足りない」という声が、実は意思決定の先送りを正当化しているだけだった。そんな場面を、プロジェクトの現場で何度も目にします。必要なのは、検証に至るまでの時間を強制的に圧縮する仕組みです。 デザインスプリントの全体像 Jake Knappは2010年頃からGoogleで検証プロセスの実験を始め、Google Ventures移籍後に体系化しました。2016年に出版された著書『Sprint』で広く知られるようになったこのメソッドは、月曜から金曜の5日間で「理解→発散→収束→試作→検証」を一気に駆け抜ける構成です。 デザインスプリントの核心は、時間の制約そのものにあります。5日間という枠組みが、完璧主義や意思決定の先送りを物理的に不可能にします。「完璧な答え」ではなく「検証可能な仮説」にたどり着くことが、このメソッドのゴールです。 月曜日：Map（理解と整理） 初日は課題の全体像を描くことに集中します。長期目標の設定、課題マップの作成、そしてスプリントで取り組む焦点の決定が主なアクティビティです。 参加者からの声として多いのは、「初日が一番きつかった」というものです。ふだんの業務では曖昧なまま進めている前提条件を、全員の前で言語化しなければなりません。「実は課題の認識がチーム内でバラバラだった」と気づく瞬間が、ほぼ毎回訪れます。 火曜日：Sketch（発散） 2日目は個人ワークが中心です。各メンバーが独立してソリューションのスケッチを描きます。 ブレインストーミングのようにグループで発想するのではなく、一人ひとりが静かに考え、具体的なスケッチに落とし込む点が特徴的です。 Jake Knappがグループブレストを採用しなかった理由は明確です。研究が示すように、集団での発想は「声の大きい人」に引きずられやすい。 個人で考えた方が、実はアイデアの質も量も上がります。 水曜日：Decide（収束と意思決定） 3日目は、前日のスケッチを全員でレビューし、プロトタイプに進めるアイデアを1つに絞ります。 ここで重要な役割を果たすのが「デサイダー」と呼ばれる最終意思決定者です。 実際にやってみると、この日が最も議論が白熱します。しかしデザインスプリントでは、民主的な多数決ではなく、デサイダーの判断で最終決定するルールが設けられています。全員が納得する答えを探すのではなく、検証する仮説を素早く選ぶことが優先されます。 木曜日：Prototype（プロトタイプ制作） 4日目は、選ばれたアイデアを1日でプロトタイプにします。 ここで言うプロトタイプは、実際に動くプロダクトではありません。ユーザーが「本物だと錯覚する程度」のフェイクで十分です。 Keynote、Figma、紙のモックアップなど、手段は何でも構いません。「リアルに見えること」と「1日で作れること」のバランスを取ることが肝心です。参加者からの声として、「完成度を上げたくなる衝動を抑えるのが難しい」というフィードバックは定番です。 金曜日：Test（ユーザーテスト） 最終日は、5人のユーザーにプロトタイプを体験してもらいます。5人で十分な理由は、ユーザビリティ研究の知見に基づいています。 Jakob Nielsenの分析では、5人のテストでユーザビリティ上の問題の約85%を発見できるとされています。 チームメンバーは別室からインタビューを観察します。自分たちが「これは良いはず」と思っていた機能が、ユーザーにまったく伝わらない瞬間を目の当たりにする。この原体験が、チームの顧客理解を根本から変えます。 「Google発」の意味を正しく理解する デザインスプリントを「Google発」と紹介する記事は多いですが、Google Ventures（GV）とGoogle本体は別組織です。GVはGoogleの持株会社であるAlphabet傘下のベンチャーキャピタル部門で、スタートアップへの投資と支援を専門としています。Jake KnappはGoogle在籍時に検証手法の実験を始め、GV移籍後にデザインスプリントとして体系化しました。つまりデザインスプリントは「Googleの社内公式プロセス」ではありません。「Google出身の人物がベンチャー支援のために生み出し、その後Googleを含む世界中の組織に広がった手法」というのが実際の姿です。 この経緯もあって、デザインスプリントは今やGV発の枠を超え、スタートアップから大企業、行政機関まで幅広い組織の標準的な検証手法の一つとして定着しています。「Googleが使っている特別な手法」というより、「検証の型として業界に浸透した手法」と捉えるほうが実態に近いでしょう。 リモートでも実施できる デザインスプリントは対面5日間を前提に設計されましたが、リモート環境での実施も一般的になっています。 ビデオ会議とオンラインホワイトボードツールを組み合わせれば、月曜〜金曜の基本構成を維持したまま進行できます。ただし画面越しでは参加者の集中力が続きにくいため、1日あたりのセッション時間を短く区切り、休憩を増やすなど進行側の工夫で補います。 具体的なツール選定やリモートファシリテーションの設計については、リモートでのデザイン思考ワークショップ運営術とデジタルホワイトボードツール比較で詳しく解説しています。 デザイン思考との違い デザインスプリントとデザイン思考は混同されがちですが、設計思想が根本的に異なります。 | 観点 | デザイン思考 | デザインスプリント | |---|---|---| | 時間軸 | 数週間〜数ヶ月 | 5日間固定 | | フェーズ | 共感→定義→創造→試作→テスト | 理解→発散→収束→試作→テスト | | チーム構成 | 多様な専門性を推奨 | 7人以下＋デサイダー必須 | | 意思決定 | 合意形成を重視 | デサイダーが最終判断 | | 反復性 | 何度もループする前提 | 1回のスプリントで結論を出す | | 共感フェーズ | 深いユーザーリサーチ | 既存知見を活用（月曜午前） | デザイン思考が「正しい問いを見つける」ための探索プロセスだとすれば、デザインスプリントは「仮説を最速で検証する」ための実行プロセスです。どちらが優れているという話ではなく、目的が違います。 実際にやってみると、デザイン思考で十分なリサーチを行った後に、検証フェーズとしてデザインスプリントを組み合わせるのが効果的なケースが多いです。 導入を成功させる5つのポイント - デサイダーの参加を死守する スプリントの成否はデサイダーが5日間フルコミットできるかにかかっています。途中で抜けると、水曜日の意思決定が空転します。「忙しいから最終日だけ」は最悪のパターンです。 - チームは7人以下に絞る 参加者が増えるほど議論は拡散します。プロダクト、エンジニアリング、デザイン、マーケティング、カスタマーサポートから1名ずつが理想的な構成です。「関係者全員を呼ばないと」という政治的配慮は、スプリントの敵です。 - 5日間のブロックを確保する 「週3日だけ確保して2週間で」というアレンジは失敗率が跳ね上がります。5日間連続で通常業務を完全に遮断する覚悟が試されます。中途半端な時間投下では、スプリントの最大の武器である時間圧力が機能しません。 - 正しい問いを選ぶ すべての課題がデザインスプリント向きではありません。「答えが不確実」「リスクが高い」「時間的制約がある」の3条件が揃う課題に適しています。答えが明白な改善タスクにスプリントを使うのはオーバーキルです。 - 結果を過信しない 5人のテストで得られるのは、あくまで方向性の確認です。統計的な有意差を証明するものではありません。「ユーザー5人中4人がポジティブだった」は心強いシグナルですが、それだけで大規模投資を決定すべきではないでしょう。 成果を次のアクションにつなげる デザインスプリントの価値は、5日目のテスト結果そのものよりも、チームが共通の顧客理解を持ち、次に何をすべきか全員が分かっている状態を作ることにあります。 スプリント後に取るべきアクションは、テスト結果によって3つに分かれます。仮説が検証された場合は本格開発へ、部分的に検証された場合は改良版で再スプリントへ、仮説が否定された場合は問いの再設定へ。 どの結果であっても、「何ヶ月も迷い続ける」よりはるかに前に進んでいます。 まずは1回、5日間を確保する デザインスプリントは、新規事業の不確実性と向き合うチームにとって最も効率的な検証手法の一つです。特に「議論は尽くしたのにアクションが起きない」「完璧を求めてリリースが遅れる」という課題を抱える組織に適しています。 最初の1回は外部ファシリテーターを入れることを推奨します。メソッドの型を体験した上で、2回目以降は自走できるようになります。 まずは5日間のスケジュールブロックを押さえることから始めてみてください。理論を読んでいるだけでは、何も変わりません。 デザイン思考の失敗パターンやファシリテーション術も合わせて参照することで、スプリントを成功させるための準備が整います。 よくある質問 デザインスプリントとデザイン思考、結局どちらを使えばいいですか？ 答えが不確実な新しい課題に最速で仮説検証したいならデザインスプリント、正しい問いをまだ見つけられていない段階で深く理解したいならデザイン思考が適しています。両者は対立する選択肢ではなく、デザイン思考でリサーチした後にデザインスプリントで検証する組み合わせも実務ではよく使われます。 何人くらいの体制で実施しますか？ 7人以下＋デサイダー1名が基本です。プロダクト・エンジニアリング・デザイン・マーケティング・カスタマーサポートから1名ずつ集めた構成が典型例です。人数が増えるほど議論が拡散し、5日間で結論に至れなくなります。 費用はどれくらいかかりますか？ 最大のコストは参加メンバー5日間分の稼働です。外部ファシリテーターを起用する場合はその費用が加わりますが、ツール自体はホワイトボードや紙、あるいはMiro・FigJamなどの無料/低価格プランで十分まかなえます。初回は外部ファシリテーターを入れる方が失敗リスクを抑えられます。 通常のワークショップと何が違いますか？ 一般的なアイデア出しワークショップは発散で終わることが多いのに対し、デザインスプリントはプロトタイプ制作とユーザーテストまでを5日間に組み込んでいる点が決定的に異なります。アイデアを出すだけでなく、実際のユーザー反応という検証結果を持ち帰れることがゴールです。 オンラインでも同じ効果が得られますか？ 進行の工夫次第で対面に近い効果は得られますが、非言語情報の欠落や参加者の集中維持といった固有の課題があります。前述の「リモートでも実施できる」で触れた通り、専用の設計とツール選定が土台になります。 --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016 - Jake Knapp, "The Design Sprint", gv.com, 2010年〜（Google Ventures公式ドキュメント） - Jakob Nielsen, "Why You Only Need to Test with 5 Users", nngroup.com, 2000 --- ### デザインリサーチ vs マーケットリサーチ——目的・手法・成果の差異 URL: https://designthinking.studio/articles/design-research-vs-market-research/ > デザインリサーチとマーケットリサーチは、どちらも「ユーザー・顧客を理解する」活動だが、目的・手法・出力・意思決定との接続が根本的に異なる。両者の違いを体系的に整理し、いつどちらを使うべきかの判断基準を示す。 「ユーザーを理解したい」という目的は同じでも、デザインリサーチとマーケットリサーチでは、問いの立て方・調査手法・生み出すアウトプット・そして意思決定への接続がまったく異なります。 混同したまま使い分けると、マーケットリサーチのデータでデザイン判断しようとして「数字は出たが何を作ればいいかわからない」という状況に陥ります。逆にデザインリサーチの知見で市場規模を語ろうとすれば「でも統計的に有意なの？」という問いに答えられなくなる。 両者の本質的な差異と、プロジェクトのどのフェーズでどちらを使うべきかの判断基準を整理します。 目的の違い——「発見」か「検証」か 手法の選択は、「何を知りたいのか」という目的の明確化から始まります。 マーケットリサーチの目的は「検証と定量化」です。「この製品の潜在市場規模はどのくらいか」「NPSは業界平均と比べてどうか」「製品AとBのどちらが好まれるか」——これらは仮説を持った上で、統計的に検証する問いです。 デザインリサーチの目的は「発見と理解」です。「ユーザーはなぜそのような行動をとるのか」「解決されていない不満の根本は何か」「ユーザーの文脈の中でこの問題はどう位置づけられるか」——仮説を作るための問いです。 マーケットリサーチは「すでに立てた仮説を確認する」。デザインリサーチは「まだ言語化されていない問題を発見する」。この違いは根本的です。 共感フェーズを支えるのはデザインリサーチです。ユーザーの文脈・行動・感情・動機を深く理解することが目的であり、その成果が問題定義フェーズでの「HMW（How Might We）」問いの材料になります。 手法の違い——「広さ」か「深さ」か 目的の違いは、自然に手法の違いを生みます。 マーケットリサーチの主要手法 アンケート調査（Survey）は、あらかじめ設計した質問に大量のサンプルが回答する手法です。統計的に有意な結果を得るためにサンプルサイズが重要であり、一般的に数百〜数千の回答が必要です。「5段階評価でどの程度満足しているか」「どの機能を最もよく使うか」などの定量データを得ます。 A/Bテストは、二つの選択肢を実際のユーザーに対してランダムに表示し、どちらがより高いパフォーマンス指標（クリック率・購買率など）を生むかを測定します。「正しいと思う選択肢」を「データで選ぶ」手法です。 フォーカスグループは、数名のグループを集めた議論形式の調査です。製品コンセプトへの反応や広告の印象を集団の文脈で把握します。ただしグループダイナミクス（他者の発言に影響される現象）が生じやすいという限界があります。 競合分析・市場データ分析は、公開されている業界データや競合の動向を整理・比較する手法です。「市場がどの方向に動いているか」を俯瞰します。 デザインリサーチの主要手法 コンテキストインタビュー（Contextual Inquiry）は、ユーザーの実際の生活・作業環境に出向いて観察しながら行うインタビューです。「実際の文脈の中での行動」を把握するため、ラボ環境では出てこない洞察が得られます。1〜2時間のインタビューを5〜12名に行うことが一般的です。 エスノグラフィー調査（Ethnographic Research）は、対象者の日常に長期間入り込んで観察・記録する手法です。マーケットリサーチが「ユーザーの言葉」を集めるとすれば、エスノグラフィーは「ユーザーの行動の現実」を記録します。「言うこと（what they say）と、することの乖離（what they do）」を明らかにするのに最も適した手法です。 シャドーイング（Shadowing）は、対象者の行動を影のように追跡・観察する手法です。特にサービス体験やオペレーション上の問題を発見するために効果的で、サービスデザインでも中心的な手法として位置づけられています。 日記調査（Diary Study）は、対象者に一定期間、日々の体験・行動・感情を記録してもらう手法です。単発のインタビューでは把握できない「時間軸の中での変化」や「非日常的な状況」を捉えます。 カード分類（Card Sorting）は、ユーザーが情報をどのように分類・命名するかを調べる手法で、情報アーキテクチャ設計に使われます。 サンプルサイズの考え方 最も誤解が生まれやすい点です。 マーケットリサーチは統計的有意性を目的とするため、数百〜数千のサンプルが必要です。誤差範囲（通常±5%）や信頼水準（通常95%）に応じて必要サンプル数が決まります。 デザインリサーチが目的とするのは質的飽和（Thematic Saturation）。新しいインタビューを重ねても新しい洞察が出なくなった時点で終えます。Jakob Nielsenの研究によれば、ユーザビリティテストでは5〜8名で主要な問題の約80%が発見できるとされています。 この違いを理解しないと、両者の批判がすれ違い続けます。「統計的に有意じゃない」と「数字では何を作ればいいかわからない」——両者は「有意性の尺度」が根本的に異なるのです。 アウトプットの違い——「数字」か「物語」か マーケットリサーチが生み出すアウトプットは数値データです。市場規模・シェア・満足度スコア・NPS・選択率・セグメント分類——これらは「量」で表現され、ビジネス判断の根拠として機能します。 デザインリサーチが生み出すアウトプットは「ユーザーの物語（Narrative）と洞察（Insight）」です。具体的には以下の形式で整理されます。 インサイト（Insight）は、観察から導かれた「なぜそうなるか」の発見です。「ユーザーはパスワードを忘れるのではなく、複数サービスのパスワードが多すぎて管理できない状態にある」というような、現象の背後にある構造的な理解が洞察です。 ペルソナ（Persona）は、リサーチ対象者のパターンを統合して作成した「典型的なユーザー像」です。氏名・年齢・仕事・目標・不満・行動パターンを持ちます。ペルソナは統計的な代表性を持つものではなく、デザインチームが「誰のために設計するか」を共有するためのコミュニケーションツールです。 カスタマージャーニーマップは、ユーザーが特定の目標を達成するまでの時間軸上での行動・感情・接点を可視化したものです。「どの瞬間に不満が最大化するか」「認知から購買までのどのステップで離脱が起きるか」を示します。 HMW（How Might We）問いは、インサイトを発想の素材に変換したものです。「ユーザーはパスワード管理に疲弊している」というインサイトを「どうすれば、ユーザーが認証を意識せずにサービスを使えるようになるか？」という問いに変換します。 意思決定との接続 両者が「意思決定とどう接続するか」も、根本的に異なります。 マーケットリサーチは「何をすべきか」の選択肢が整った段階で機能します。2つ以上の選択肢（製品A vs B、価格帯X vs Y）があり、そのどちらが優れているかをデータで決めたいとき、マーケットリサーチは強力な判断基準を提供します。 デザインリサーチは「何を問題にすべきかがまだわかっていない段階」で機能します。「顧客が離れている理由がわからない」「新製品の方向性が定まらない」「既存機能の改善なのか新機能開発なのかの判断基準がない」——このような不確実性が高い状況で、デザインリサーチはチームの認識を揃え、正しい問いを定義します。 デザイン思考のプロセス全体でみれば、デザインリサーチは前半（共感〜定義）、マーケットリサーチは後半（プロトタイプ〜テスト後の市場検証）に機能します。両者は競合するのではなく、課題探索から事業検証までのパイプラインで役割分担しています。 よくある混同と失敗パターン パターン1：「アンケートで共感を代替する」 最も多い失敗は、「ユーザーインタビューは時間がかかる。アンケートでいい」という判断です。アンケートは「ユーザーが言語化できること」しか回答できません。しかしデザインリサーチが求める洞察は、しばしば「ユーザー自身も気づいていない、言語化されていない不満や行動パターン」にあります。アンケートでは、問題の存在を知っている場合の検証はできますが、問題の発見はできません。 パターン2：「定性リサーチの結果を過度に一般化する」 「3名のインタビューで全ユーザーを代表する」という主張は誤りです。デザインリサーチのアウトプット（インサイト・ペルソナ）は、「このような人が存在する」という発見であり、「このような人が何%いるか」という推定ではありません。発見した洞察を広いスケールで検証するフェーズに移行するときに、マーケットリサーチを使います。 パターン3：「リサーチを実施したが判断に使えない」 両者のどちらを使ったとしても、「何の問いに答えるためのリサーチか」を事前に定義していないと、結果が出ても判断に使えません。リサーチの設計は「問いの設計」から始まります。「このリサーチが終わった時に、どんな問いに答えられていれば成功か」を最初に合意することが、リサーチの最も重要なステップです。 プロジェクトでの使い分け基準 実務での判断基準をまとめると、以下のように整理できます。 デザインリサーチを選ぶ場面は、問題の性質が不明確な段階、新しい市場・ユーザーセグメントへの参入、既存製品・サービスの根本的な見直し、ユーザー行動の「なぜ」を理解したい場合です。 マーケットリサーチを選ぶ場面は、競合比較・市場ポジショニングの確認、製品コンセプトの市場受容性の検証、機能優先順位の統計的根拠の確認、事業計画のためのTAM/SAM/SOM推計です。 両者を組み合わせる場面としては、「デザインリサーチで発見した洞察をもとに仮説を作り、マーケットリサーチで統計的に確認する」というシーケンシャルな使い方が最も効果的です。定性で探索し、定量で検証する。この順序が重要で、逆（定量で何かを見つけようとする）は機能しにくい場合があります。 まとめ——2つのリサーチを正しく使い分ける 優劣の問題ではありません。それぞれが異なる問いに答えるために設計された、本質的に異なる知的活動です。 デザインリサーチが「深さ」で人間の行動・動機・文脈を理解するとすれば、マーケットリサーチは「広さ」で市場の傾向・規模・優先度を測定する。正しいフェーズで正しい手法を選ぶことが、洞察の質と意思決定の確度の両方を高めます。 共感フェーズでマーケットリサーチのデータを眺めるだけでは、問題の核心には届かない。テストフェーズでデザインリサーチの定性観察だけを根拠に製品の方向転換を決めることには、データの裏づけが欠けます。 プロジェクトの「問いの性質」に応じて使い分けること——それが、リサーチの最も重要な実践知です。 200回以上のデザイン思考ワークショップで繰り返し観察されているのは、「マーケットリサーチのデータを持っているのに、何を作ればいいかわからない」という状況が、大企業のプロダクト開発チームで頻発するパターンだ。ユーザーの「言語化されていない不満」を拾うデザインリサーチを一度も実施せずに開発段階に進んでしまっている。逆に、ディスカバリーフェーズに時間をかけすぎて「ユーザーを理解しすぎたが何も作れていない」という状態も存在する。両者のリサーチを正しいフェーズで組み合わせることの実践的な難しさは、フレームワークの理解よりも、「今どちらの問いに答えたいか」を問い続けるチームの習慣にある。 --- 参考文献 - Stickdorn, M., Hormess, M. E., Lawrence, A., & Schneider, J. (2018). This Is Service Design Doing. O'Reilly Media. — デザインリサーチ手法の実務的解説 - Nielsen, J. (2000). "Why You Only Need to Test with 5 Users." Nielsen Norman Group. — https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ - Beyer, H., & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann. — コンテキストインタビューの体系的手法書 - Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media. — ユーザーインタビューの実践ガイド - IDEO.org. (2015). The Field Guide to Human-Centered Design. IDEO.org. — https://www.designkit.org/resources/1 — デザインリサーチの標準的入門資料 関連記事 - 共感フェーズ——ユーザーを深く理解する - 問題定義フェーズ - カスタマージャーニーマップ実践ガイド - コンテキスチュアル・インクワイアリー——現場観察でインタビュー室では得られない暗黙知を掘り起こす - 『This is Service Design Doing』要約 --- ### デザイン思考 vs リーンスタートアップ——2つのイノベーション手法の比較 URL: https://designthinking.studio/articles/design-thinking-vs-lean-startup/ > デザイン思考とリーンスタートアップの共通点と相違点を整理。両者の使い分けと統合的アプローチを解説。 デザイン思考とリーンスタートアップは、どちらもイノベーションを生み出すための体系的な方法論です。しばしば比較される2つのアプローチの共通点と相違点を整理します。 2つのアプローチの概要 デザイン思考は、IDEOやスタンフォード大学d.schoolが体系化した人間中心のイノベーション手法です。共感→問題定義→創造→プロトタイプ→テストの5フェーズで構成されます。 リーンスタートアップは、Eric Ries が2011年の著書『The Lean Startup』で提唱した起業の方法論です。構築→計測→学習（Build-Measure-Learn）のフィードバックループを高速に回すことで、無駄を最小化しながら事業を検証します。 共通点 両者には重要な共通点があります。 - 反復的プロセス — 一度で正解にたどり着くのではなく、繰り返し改善する - 実験重視 — 仮説を立て、実験を通じて検証する - 早期のフィードバック — ユーザーや顧客からの反応を重視する - 失敗からの学び — 失敗を「学びの機会」と捉える 相違点 | 観点 | デザイン思考 | リーンスタートアップ | |------|------------|-------------------| | 起点 | ユーザーのニーズ（共感） | ビジネス仮説 | | 主な問い | 「何を作るべきか？」 | 「これはビジネスになるか？」 | | 焦点 | 望ましさ（Desirability） | 実現できるか（Feasibility）・続けられるか（Viability） | | プロトタイプ | 学びのための低忠実度 | MVP（最小限の実用製品） | | 対象フェーズ | 課題発見〜解決策の探索 | 解決策の市場検証〜スケール | ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、「デザイン思考だけで事業検証まで完結しようとする」パターンです。共感フェーズから始まり、プロトタイプまで丁寧に進めたのに、「ユーザーが良いと言った」という感触だけで大規模な投資意思決定をしてしまう。 実際にやってみると分かるのですが、デザイン思考のテストフェーズで「これは良さそう」と感じてからが本当の起点です。 その感触を「定性的な手ごたえ」から「定量的な検証」に引き継ぐのがリーンスタートアップの役割です。デザイン思考が前半を走り、リーンスタートアップが後半を走る。渡すバトンは「これは良さそう」という手ごたえそのものです。 実務でよくある失敗パターン 上のワークショップの例とは別の角度で、実務ではもう2つの失敗が繰り返し起きます。 - リーンスタートアップから入り、共感プロセスを飛ばしてしまう: 「早く検証サイクルを回したい」という焦りから、共感フェーズを経ずに社内の思い込みだけで最初の仮説を立て、いきなりMVPを作ってBuild-Measure-Learnを回し始めるケースです。この場合、検証サイクル自体は高速に回っても、そもそも検証している仮説がユーザーの実際の課題とずれているため、指標が改善しても事業として意味のある学びにつながりません。共感フェーズは「速度を落とす工程」ではありません。「何を検証すべきかを正しく決める工程」です。ここを飛ばして稼いだ速さは、たいてい後工程でそのまま失われます。 - 並走させた結果、判断基準が割れて身動きが取れなくなる: デザイン思考チームとリーンスタートアップチームを並行運用する際に、前者は「望ましさ」の定性的な手ごたえを、後者は「実現可能性」の定量指標をそれぞれ別の会議体で追いかけてしまい、意思決定の場で「ユーザーは欲しがっているが数字が追いつかない」「数字は良いが誰も欲しがっていない実感がある」という主張が対立し、投資判断が止まるケースです。対策は、後述する4ステップのように、どの段階でどちらの基準を優先するかを先に1つの意思決定フローとして合意しておくことです。定性か定量か、片方だけで止まらない——それだけのことですが、事前にここまで握れているチームは意外と少ない。 使い分けと統合 最も効果的なのは、両者を段階的に統合するアプローチです。 - デザイン思考で課題を発見する — 共感フェーズでユーザーの本質的なニーズを理解 - デザイン思考で解決策を探索する — 創造・プロトタイプフェーズで方向性を定める - リーンスタートアップで市場検証する — MVPを構築し、ビジネス仮説を検証 - データに基づいて改善を続ける — 計測結果を基に、ピボットまたは成長を判断 なお、時間制約の中でこの統合を実現する方法としてデザインスプリントがあります。5日間という枠組みで「理解→仮説→検証」を一気に駆け抜ける手法として現場で広く活用されています。 まとめ デザイン思考は「正しい問題を見つけ、解決策の方向性を定める」段階で力を発揮し、リーンスタートアップは「解決策のビジネス性を検証し、成長させる」段階で力を発揮します。両者を組み合わせることで、イノベーションの成功確率を高められます。 よくある質問 デザイン思考とリーンスタートアップ、どちらを先に使うべきですか？ 多くの場合、デザイン思考を先に使うべきです。 リーンスタートアップのMVP検証は「何を作るべきか」という問いがすでに定まっていることを前提にした手法であり、その問いを見つける工程はデザイン思考の共感フェーズや問題定義フェーズが担います。ただし対象領域の課題がすでに明確なら、共感フェーズを簡略化してMVP検証から始めても構いません。 両方を同時に走らせることはできますか？ できますが、注意が必要です。判断基準を1つに統合しておかないと、上で挙げた「並走させた結果、判断基準が割れて身動きが取れなくなる」失敗が起きやすくなります。 デザイン思考側の定性的な手ごたえとリーンスタートアップ側の定量指標、どちらをどの段階で優先するか。それを事前に合意したうえで並走させます。 スタートアップ以外（大企業の新規事業）でも同じ使い分けでよいですか？ 基本的な使い分けの考え方は共通です。Eric Ries自身も2017年の著書『The Startup Way』で、大企業・既存組織にリーンスタートアップの原則を応用する枠組みを提示しています。違いは意思決定の承認階層の厚さです。 MVPでの検証結果を次の投資判断につなげるまでの意思決定プロセスを、プロジェクト開始前に別途設計しておく必要があります。 MVPとデザイン思考のプロトタイプは何が違いますか？ 上の相違点の表にある通り、デザイン思考のプロトタイプは「学びのための低忠実度」の試作物で、間違っていることを前提に何度も作り直します。 一方MVPは「最小限の実用製品」で、実際のユーザーに使ってもらいながらビジネス指標を計測する道具です。前者が「これは正しい方向か」を確かめ、後者は「これはビジネスとして成立するか」を確かめる——問う対象が違います。 プロトタイプ検証で好反応が出たら、そのままスケール投資してよいですか？ いいえ。「デザイン思考のプロトタイプ検証を『ユーザーが良いと言った』で終わらせ、リーンスタートアップの定量検証に引き継がないままスケール投資してしまう」のは、ワークショップで繰り返し見られる失敗パターンです。好反応は次の検証（MVPによる定量的な市場検証）に進む合図であって、投資判断そのものの根拠にはなりません。 両方を導入する際、最初の一歩は何をすればよいですか？ いきなり全社的なプロセスとして両方を導入するのではなく、1つの案件で「共感フェーズ→MVP検証」までの最小のサイクルを1周してみるのが現実的な出発点です。デザインスプリントのような時間制約のある手法を使えば、統合の感触を短期間でチームに掴んでもらえます。1周回してから、範囲を広げるかどうかを決めれば十分です。 --- 参考文献 - Eric Ries, The Lean Startup, Crown Business, 2011 - Eric Ries, The Startup Way, Currency, 2017 - Tim Brown, Change by Design, HarperBusiness, 2009 - Jeanne Liedtka, "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction", Journal of Product Innovation Management, Vol.32, No.6, 2015 --- ### デザイン思考 サプライチェーン強靭化｜危機対応の設計論と実践3ステップ URL: https://designthinking.studio/articles/design-thinking-supply-chain-resilience/ > サプライチェーン危機にデザイン思考を適用する方法を解説。ユーザー中心の共感フェーズから問題再定義、プロトタイプ検証まで、調達・物流の現場で使える実践フレームを提示します。 「サプライチェーンが止まったとき、次に何をすべきかが誰にもわからなかった。」 これは特定の企業の話ではありません。パンデミック禍に、製造業・小売業・物流業を問わず、数万社が経験した瞬間です。問題は、リスク管理の「マニュアル」を持っていた企業ですら、実際の危機では対応が機能しなかったことにあります。 なぜ既存の手法は機能しなかったのか。そして、デザイン思考はサプライチェーンの強靭化にどう貢献できるのか。本記事では、調達・物流の現場で実際に使えるフレームを提示します。 --- なぜ「マニュアル対応」は危機に機能しないのか サプライチェーンリスク管理の従来手法は、主に「リスクの洗い出し→確率と影響度のマトリクス化→対応策の事前決定」という構造を取ります。BCP（事業継続計画）がその典型です。 しかし実際の危機は、想定したシナリオ通りには起きません。問題はリスクの「種類」ではなく、「組み合わせ」と「連鎖」にあるのです。感染拡大が物流の人員不足を引き起こし、港湾の混雑が部品調達の遅延を招き、顧客の注文パターンが急変する——この複合的な状況は、どのマニュアルにも記載されていません。 マニュアルが機能しない局面で必要なのは、「現場で何が起きているか」を素早く把握し、関係者全員の認識を揃え、実験的に対応策を検証するプロセスです。これはデザイン思考が本来得意とする領域です。 --- デザイン思考をサプライチェーンに適用する3ステップ ステップ1：共感フェーズ——「誰が困っているか」を現場から拾う 危機対応の最初のボトルネックは、現場の実態が意思決定層に届かないことです。調達担当者が知っている情報、物流拠点のオペレーターが肌で感じている状況、取引先の担当者が抱えている懸念——これらはバラバラに存在し、統合されないまま時間が過ぎます。 デザイン思考の共感フェーズを適用するとは、具体的には以下の行動を意味します。まず、サプライチェーンの各接点に「声を聴く人」を配置します。調達チームが仕入先へのインタビューを1日以内に実施し、物流チームが倉庫現場のオペレーターと30分のセッションを行います。この「速い共感」が危機対応の質を決定的に変えます。 ポイントは「問題の定義を急がないこと」。 まず何が起きているかを、当事者の言葉で収集することに専念します。200回以上のワークショップで繰り返し観察されるのは、「すぐ解決策に飛びつく」というパターンです。サプライチェーン危機でも同じことが起きます。 ステップ2：問題再定義——「本当に解くべき課題」を特定する 収集した情報を元に、問題を再定義します。「部品が入荷しない」という表面的な問題の背後に「特定のサプライヤーへの過度な依存」という構造的問題があること、その背景に「調達担当者が代替サプライヤーを探す時間・権限を持っていない」という組織設計の問題があること——これが見えてくるのは、共感フェーズで「なぜ」を繰り返したあとです。 Point of View（POV）ステートメントを活用します。「[ステークホルダー]は[ニーズ]を必要としている。なぜなら[インサイト]だから」というフォーマットで、解くべき問いを一文に凝縮します。例えば「現場の調達担当者は、緊急時に代替サプライヤーへ即座に切り替える権限を必要としている。なぜなら現状の稟議フローでは意思決定に3日かかり、危機対応のスピードと根本的に相容れないから」という具合です。 この再定義のプロセスに、調達・物流・製造・営業の担当者が一同に介することが重要です。縦割り組織の弊害が最も強く出るのが、危機対応の初動です。問題再定義のセッションを「横断ミーティング」として設定することで、サイロを一時的に解体できます。 ステップ3：プロトタイプと実験——小さく試して素早く学ぶ 問題が再定義できたら、対応策の実験に入ります。ここでデザイン思考が有効なのは「完璧な解決策を求めない」という哲学です。 代替サプライヤーへの切り替えを検討するなら、まず1品目・小ロットで試す。緊急時の意思決定権限を現場に委譲するなら、まず一定金額以下の発注に限定して3週間試す。このような「限定実験」の積み重ねが、危機下での学習速度を上げます。 プロトタイプの考え方はモノのデザインに限りません。 プロセス・権限構造・コミュニケーションのプロトタイプが、サプライチェーン危機対応では中心になります。「緊急時コマンドセンター」を設置して1週間試してみる、というのもプロトタイプです。 --- ワークショップで機能する——実際の進め方 デザイン思考をサプライチェーン強靭化に活用する際、最も効果的なのは危機が起きる前にワークショップ形式で「模擬危機」を設計することです。 具体的な手順を紹介します。まず、過去の危機事例（自社・他社・業界全体）を素材にした「危機シナリオカード」を用意します。次に、調達・物流・製造・営業・経営企画の担当者がチームを組み、そのシナリオに対してデザイン思考の5フェーズを1日で走らせます。 このワークショップが持つ最大の価値は「答え」ではなく「問いの習慣化」にあります。 「本当に困っているのは誰か」「問題の本質はどこにあるか」「小さく試せる方法はないか」——この3つの問いを危機対応の「反射」として身体化することが目標です。 --- 特に効果が出やすいケース デザイン思考のサプライチェーン適用が特に効果を発揮するのは、以下のような状況です。 複数拠点・複数国にわたるサプライチェーンを持つ企業。地域ごとに異なる問題認識が存在するため、共感フェーズによる情報統合の価値が高くなります。 調達担当者の属人的な判断に依存してきた企業。問題再定義のプロセスが暗黙知の形式知化につながります。 過去の危機対応が「現場任せ」だった企業。横断チームによるワークショップが組織横断の連携設計を促します。 --- まとめ：デザイン思考は「危機対応の速さ」を変える サプライチェーン強靭化におけるデザイン思考の貢献は、新しいソリューションを生み出すことよりも、危機対応の初動の質を上げることにあります。 「誰が困っているか」を素早く把握し、「本当に解くべき課題」を合意し、「小さく試して学ぶ」——この3ステップのサイクルを組織の習慣として設計することが、次の危機に備える最も確実な投資です。 デザイン思考の手法詳細はデザイン思考の基本フレームワークを、組織全体への導入設計はデザイン思考の組織導入完全ガイドを参照してください。 --- ### デザイン思考 スタートアップのProduct-Market Fit探索への適用 URL: https://designthinking.studio/articles/design-thinking-startup-product-market-fit/ > スタートアップがProduct-Market Fitを見つけるためのデザイン思考活用法を解説。リーンスタートアップとの使い分け、顧客インタビューの設計、仮説検証のサイクルを実践的に紹介します。 「プロダクトを作ってみたが、誰も使ってくれない。」 スタートアップの失敗原因として最も多く挙げられるのが、Product-Market Fit（PMF）を見つけられなかったことです。CBInsightsの調査では、スタートアップ失敗の第1位の理由は「市場ニーズがなかった」ことで、全体の42%を占めます。 しかし問題は「市場ニーズがなかった」のではなく、「市場ニーズを探す方法が間違っていた」ことが多い。本記事では、デザイン思考をPMF探索プロセスに統合することで、仮説検証の質を根本から変える方法を解説します。 --- リーンスタートアップとデザイン思考——何が違うのか PMF探索のフレームワークとして、多くのスタートアップがリーンスタートアップ（Build-Measure-Learn）を採用しています。しかしデザイン思考と組み合わせることで、リーンの弱点を補完できます。 リーンスタートアップが得意とするのは「検証の速さ」。プロトタイプを素早く作り、データで判断し、ピボットを繰り返す。このサイクルは素晴らしい設計です。 しかし、ここに落とし穴があります。何を検証するかの「仮説の質」が低いと、いくら速く回しても正しい方向に近づきません。スタートアップの現場でよく起きるのは「指標を計測しているが、それが本当に重要な問いに答えているか分からない」という状況です。 デザイン思考が補完するのは「問いの質」の部分。 何を検証すべきかを、顧客との深い共感から導き出すプロセスがデザイン思考の得意領域です。両者を統合すると「正しい問いを深く立て、速く検証する」という理想的なサイクルが設計できます。 --- PMF探索にデザイン思考を使う4フェーズ フェーズ1：共感——「誰の、どんな問題か」を現場で掘り下げる PMF探索で最初に犯しがちなミスは、顧客インタビューを「解決策への賛同集め」として使ってしまうことです。「このプロダクトは役に立ちますか？」という問いに、人は大抵「はい」と答えます。礼儀として、あるいは実際に試していないから。この「はい」は何の情報にもなりません。 デザイン思考の共感フェーズが教えるのは、「解決策を見せる前に、問題を徹底的に理解する」ことです。顧客インタビューの正しい問いは「あなたが（課題領域）で最後に苦労したのはいつですか？その時、何が一番大変でしたか？」という過去の具体的体験を引き出す形式です。 「Job to Be Done（JTBD）」の概念と組み合わせると効果的です。 人がプロダクトを「雇用する」のは、特定の「仕事」をやり遂げるためです。ミルクシェイクを買う人の「仕事」は、退屈な通勤を紛らわすことかもしれない——という有名なハーバードの事例が示すように、表面的なニーズの背後にある「本当の仕事」を見つけることが共感フェーズの目的です。 実践的なインタビュー設計のポイントは3つです。「なぜ」を5回繰り返す（5 Whys）、解決策を一切出さない、競合プロダクトの使用経験から始める——この原則を守るだけで、インタビューの質は大幅に変わります。 フェーズ2：問題定義——PMFの「仮説」を一文で書く 共感フェーズで収集したインサイトを統合し、解くべき問題を一文で定義します。 PMF探索における問題定義は、「[ターゲットユーザー]は[コンテキスト]において[問題]を抱えているが、現在の解決策では[不満な理由]である」という構造で書きます。 例えば「地方在住の中小企業経営者は、採用活動において求人媒体への掲載コストが高く、都市部の競合企業と戦えないという問題を抱えているが、既存の低コスト採用サービスは求職者の質が低く使い物にならないと感じている」という問題定義ができれば、そこから検証すべき仮説が自然に導き出されます。 この問題定義を「チームの全員が同意できる1文」に絞ることが重要です。 共同創業者間での問題認識のズレは、PMF探索の初期段階で最も起きやすい、かつ最も致命的なリスクのひとつです。問題定義セッションをワークショップ形式で実施することで、認識を揃えるプロセスが同時に達成されます。 フェーズ3：アイデア創出——解決策を「広げてから絞る」 問題定義が固まったら、解決策のアイデア出しに入ります。ここで多くのスタートアップが陥るのは「最初のアイデアに固執する」パターンです。 デザイン思考の発散→収束のプロセスは、この固執を構造的に防ぎます。クレイジーエイツ（8分間で8つのアイデアをスケッチする）などのアイデエーション手法を使うことで、「自分たちが想定していなかった解決策」が必ず出てきます。 特にスタートアップに有効なのは「制約の変更」というアプローチです。 「もし予算が100分の1しかなかったら？」「もし10倍のスピードが必要だったら？」「もしテクノロジーが使えなかったら？」という制約を変えることで、プロダクトの本質的な価値が何かが明確になります。 フェーズ4：プロトタイプと検証——「最小の労力で最大の学習を得る」 スタートアップにとって最も重要なプロトタイプの原則は「作る前に売れるかを試す」ことです。 ランディングページを作って問い合わせ数を計測する（Smoke Test）、コンシェルジュMVP（手動で価値を提供して需要を検証する）、ペーパープロトタイプでのユーザビリティテスト——これらは全て「コードを書かずに仮説を検証する」デザイン思考的なアプローチです。 ペーパープロトタイピングは、スタートアップの初期段階で特に強力なツールです。UIデザインの専門知識がなくても、紙とペンで画面遷移を描き、ユーザーに触ってもらうことで「直感的に使えるか」「価値が伝わるか」の検証が1日でできます。 --- PMFを見つけた兆候——デザイン思考で見極める PMFの感覚的な指標として広く使われるのが、Sean Ellis（GrowthHackers創業者）が提唱した「非常に残念テスト」です。「このプロダクトが使えなくなったら、どう感じますか？」という問いに40%以上のユーザーが「非常に残念」と答えれば、PMFに達しているとされます。Ellisが数百のスタートアップをベンチマークして導き出した経験則です。 この定義をデザイン思考で補完するなら、「ユーザーが自発的に他者に勧める理由が、作り手の想定と一致しているか」という観点を加えます。 予期しない理由でプロダクトが評価されている場合、それは新たなPMFの可能性を示唆しています。 定期的な顧客インタビューを継続し、「なぜ使い続けているのか」「誰に勧めたか、なぜ勧めたのか」を深掘りすることで、PMFの実態を解像度高く把握できます。 --- まとめ デザイン思考とリーンスタートアップは競合ではなく、「問いの質（デザイン思考）」と「検証の速さ（リーン）」として統合できます。 PMF探索で最初に使うべきリソースは、コードでも資金でもなく、顧客との対話です。「誰が、どんな文脈で、なぜ困っているのか」を徹底的に理解することが、正しいプロダクトを最短で作る唯一の道です。 デザイン思考とリーンスタートアップの違いも合わせて参照してください。 --- ### デザイン思考 スマートシティ・都市イノベーション｜ヘルシンキ・バルセロナ・シンガポール3都市の実践 URL: https://designthinking.studio/articles/design-thinking-smart-city-urban-innovation/ > スマートシティへのデザイン思考適用を3都市の実例から解説。ヘルシンキのMyData市民参加、バルセロナのスーパーブロック、シンガポールのTech Kakiコ・デザインが示す「市民を設計者にする」都市変革の手法を紹介します。 スマートシティの議論は、ともすれば「センサーの数」や「データ活用の高度さ」に集中しがちです。しかし実際に機能している都市変革の事例を見ると、共通して浮かぶのは別の問いです。「誰のために、誰と一緒に設計しているか」——この問いに明確に答えているかどうかが、スマートシティの成否を分けている。 本記事では、ヘルシンキ・バルセロナ・シンガポールという3つの都市が、デザイン思考の核心である「共感と共同創造」をどう都市規模に拡張したかを読み解きます。 --- スマートシティがつまずく理由 技術主導のスマートシティプロジェクトが失敗するとき、原因はほぼ共通しています。問題を住民から聞かずに行政や企業が設計し、住民は「サービスを受け取る側」として最後に登場する——この構造です。 デザイン思考の言葉でいえば、「共感フェーズを省いた解決策の設計」です。どれほど洗練されたセンサー網やAI分析基盤を構築しても、住民が本当に困っていること、本当に必要としていることがズレたまま実装されれば、利用されないシステムが積み上がるだけです。 成功している都市が示す方法論は、技術の話をする前に「誰の問題を解くか」を丁寧に問うプロセスにある。その実践を3都市から見ていきます。 --- ヘルシンキ：MyDataと市民データの設計 ヘルシンキ市が2020年代初頭から推進したMyDataイニシアティブは、「市民が自分のデータをコントロールする」という設計思想から出発しています。 出発点は技術的な問いではありませんでした。「市が保有する市民データを、誰のために、どのように使うか」という倫理的・人間的な問いです。この問いに答えるために、ヘルシンキ市のサービスデザインチームが実施したのは、Design Toolkitを使ったワークショップです（2020年8月）。住民、企業、行政担当者が同じテーブルに着き、「自分のデータが使われるとき、何を期待するか、何を恐れるか」を対話する場を設計しました。 ポイントは「仕様決定の前に共感収集を置いた」順序にあります。 データ活用の技術設計を先に固めて住民に提示するのではなく、住民の期待と懸念を収集したうえで技術要件を設計する——この逆転がMyDataの核心です。 結果として実装されたのは、個人データを「分散管理」することでデータ漏洩リスクを低減しながら、住民が同意した範囲でサービス改善に使えるという仕組みです（運用はVastuu GroupとFujitsu Finlandが担う）。市民がデータの「提供者」だけでなく「設計の参加者」として扱われた点が、従来のスマートシティアプローチと根本的に異なります。 --- バルセロナ：スーパーブロックと空間の再設計 バルセロナのスーパーブロックプログラムは、9ブロックをひとつの「スーパーブロック」として再定義し、内部道路を歩行者・自転車専用空間に転換する都市変革プロジェクトです。C40 Citiesの報告では、実施済みエリアで歩行者空間が23ヘクタール超に拡大し、住民は「静穏・睡眠の質・社会的交流の増加」を体感していると記録されています。 このプロジェクトで特徴的なのは、「全フェーズにわたる市民参加」の設計です。バルセロナ市は計画の策定段階から、周辺住民・商店主・通勤者という異なるステークホルダーのインタビューと観察を実施しました。「車を減らせ」という要求の背後に「騒音と排気ガスが子どもの遊び場を奪っている」という具体的な課題があること、商店主には「通行量が減って客が来なくなる」という懸念があること——これらを可視化してから、インターベンションの設計を行っています。 「タクティカル・アーバニズム（戦略的都市主義）」として知られる、低コスト・高速実験のアプローチも、デザイン思考のプロトタイプ哲学と重なります。 最初から大規模な工事を行うのではなく、一部のブロックで仮設的な変更（ペイント・プランター・簡易ベンチ）を行い、住民の反応を見ながら設計を改善する。この「小さく試して、学んで、広げる」サイクルが、バルセロナのプロジェクトが住民の反発を最小化しながら変革を進めた方法です。 ただし、IJURR（International Journal of Urban and Regional Research）の2024年論文が指摘するように、スーパーブロックは高所得層が流入しやすいエリアで優先実施される傾向があり、社会経済的な偏在への批判もあります。「誰の問題を解いているか」の問いは、実装後も問い続ける必要があります。 --- シンガポール：Tech Kakiと市民コ・デザイン シンガポールのGovTech（政府技術庁）が運営するTech Kakiは、政府のデジタルサービス開発に市民を直接参加させる仕組みです。「Kaki」はシンガポールのマレー語スラングで「仲間」を意味します。 Tech Kakiのプロセスは、デザイン思考の共感フェーズを行政規模で実装したものとして解釈できます。住民がオンラインコミュニティに参加し、政府サービスの新機能や改善案に対してフィードバックを提供する。A/Bテストへの参加、ユーザビリティテストへの招待、政策案へのコメントが、継続的に収集されます。 さらに同様の仕組みCrowdTaskSGでは、市民がアンケートやテストタスクをこなすことで、直接政策立案に関与します。GovTechの取り組みでは、Punggol Digital Districtという新都市地区の開発において、Open Digital Platform（ODP）というIoTインフラの設計段階から住民・企業・研究機関が協働するプロセスを採用しました。 シンガポールのアプローチが示す示唆は、「コ・デザインを一過性のイベントにしない」点にあります。 Tech KakiやCrowdTaskSGは常設のプラットフォームであり、特定プロジェクトのためだけに市民を招集するのではなく、継続的に市民の声が設計プロセスに流れ込む仕組みが構築されています。 --- 3都市に共通する設計原則 3都市の実践を横断すると、スマートシティへのデザイン思考適用に共通する設計原則が浮かびます。 「技術の前に問いを立てる」原則。 ヘルシンキはデータ活用の技術仕様より先に「住民の期待と懸念」を収集しました。バルセロナは道路設計の前に「誰がどんな理由で困っているか」を観察しました。シンガポールは新都市開発の前から市民との対話プラットフォームを動かしています。 「プロトタイプで学ぶ」原則。 バルセロナのタクティカル・アーバニズムは、都市スケールでのプロトタイプ実験です。変更の前に住民への影響を完全に予測しようとするのではなく、小さな実験から学んで改善する。この姿勢は、デザイン思考の「早期プロトタイピング」をそのまま都市規模に適用したものです。 「ステークホルダーの多様性を設計に組み込む」原則。 スマートシティに影響を受けるのは、富裕層から低所得者層まで、若者から高齢者まで、多様な属性の住民です。3都市の設計プロセスは、この多様性を「参加者リスト」として明示し、特定のグループだけが参加するワークショップを意図的に避けています。 --- 実践への転用——中規模の組織でできること 都市全体の変革は遠く見えますが、デザイン思考のスマートシティ実践から学べることは、地域のまちづくり組織、自治体の部署単位、企業の地域プロジェクトにも直接転用できます。 まず「誰に」から始める。 問題を抱えている人を特定し、その人たちと対話するセッションを設計する。100人でなく5人から始める。 プロトタイプを「実験」と呼ぶ。 「試験的に3ヶ月やってみる」という枠組みで小さく実施する。失敗しても「学び」として位置づけることで、組織内の抵抗を減らせます。 継続的な対話の仕組みを設計する。 コ・デザインの一番の失敗は「一回やって終わり」の形式主義です。住民や利用者の声が常に設計にフィードバックされる仕組みを、最初から埋め込んでおく。 --- まとめ：テクノロジーは「手段」であり「主語」ではない ヘルシンキ・バルセロナ・シンガポールの事例は、スマートシティの成功が「どれだけ先進的な技術を使うか」より「誰と一緒に、誰のために設計したか」に依存することを示しています。 デザイン思考の5フェーズ——共感・定義・発想・プロトタイプ・テスト——は、都市という複雑な系を扱うときほど、その価値が際立ちます。問題が複雑なほど、「仮定からではなく対話から始める」原則が効く。これが3都市の実践が共通して示すことです。 デザイン思考の基本フレームワークはデザイン思考とは何かを、市民共感フェーズの手法詳細は共感フェーズ——ユーザーを深く理解するを参照してください。 --- 参考文献・出典 - City of Helsinki, "Helsinki aims to use personal data on behalf of the citizens — on citizens' terms," Cities Today, 2020 — https://cities-today.com/helsinki-to-give-citizens-control-of-their-personal-data/ - MyData Global, "Putting MyData Principles into action," 2020 — https://mydata.org/2020/09/25/putting-mydata-principles-into-action-an-introduction-to-the-mydata-design-toolkit/ - C40 Cities, "The implementation of the Superblocks programme in Barcelona," 2021 — https://www.c40.org/case-studies/barcelona-superblocks/ - Frago, L., "Urban Planning Paradoxes and Sociospatial Fragmentation: The Superblock Barcelona Case (2016–2023)," International Journal of Urban and Regional Research, 2024 — https://onlinelibrary.wiley.com/doi/10.1111/1468-2427.13273 - GovTech Singapore, "Smart City Technology," tech.gov.sg — https://www.tech.gov.sg/about-us/what-we-do/our-capabilities/smart-city-technology/ - GovTech Singapore, "Smart Nation 2.0: Initiatives in Singapore," 2024 — https://www.tech.gov.sg/technews/our-enhanced-smart-nation-vision-paving-the-way-for-a-new-digital-era/ - ArchDaily, "Cities as Living Laboratories: The Smart City Projects of Amsterdam, Singapore, and Barcelona," 2023 — https://www.archdaily.com/1001628/cities-as-living-laboratories-the-smart-city-projects-of-amsterdam-singapore-and-barcelona --- ### デザイン思考 医療 ヘルスケア実装ガイド｜IDEO・Stanford・Cleveland Clinicの現場事例 URL: https://designthinking.studio/articles/design-thinking-healthcare-implementation/ > 医療現場にデザイン思考を実装するための統合ガイド。IDEO×Mayo Clinic SPARC Lab、Stanford d.schoolの医療プロジェクト、Cleveland Clinic Patient Experience Officeの事例から、患者安全・HIPAA制約下での共感→定義→アイディエーション→プロトタイプ→テストの実践手法を解説する。 200回以上のワークショップで繰り返し見られるのは、「患者視点」に集中するあまり「医療スタッフの認知負荷」を設計から落としてしまうパターンだ。医療現場特有のこの盲点を理解することが、ヘルスケアでのデザイン思考実装の出発点になる。 医療現場にデザイン思考を持ち込もうとした人間の多くが、最初の壁として「これは普通のユーザーリサーチとは違う」という感覚にぶつかる。患者の感情は複雑で、医療従事者の認知負荷は極限に近く、法規制は厚い。デザイン思考の5フェーズはそのまま使えるが、各フェーズの設計判断はヘルスケア固有の制約に合わせて組み直す必要がある。 この記事では、IDEO×Mayo Clinic、Stanford d.school、Cleveland Clinic という3つの先行事例を軸に、医療現場でのデザイン思考実装の要点を解説する。「何をやったか」だけでなく、「なぜそう設計したか」の判断ロジックまで掘り下げる。 --- IDEO×Mayo Clinic SPARC Lab：病院の待合室を「実験室」に変えた Mayo Clinicは2008年にIDEOとの協働でSPARC（See, Plan, Act, Refine, Communicate）Labを立ち上げた。これは病院内に設置された実寸大のデザイン実験スペースで、実際の患者を巻き込みながら、患者体験を直接プロトタイプしてテストするという設計だった。 共感フェーズ：患者の「待つ」という体験を深掘りする IDEO/Mayo Clinicの協働が最初に着手したのは、待合室体験の再定義だった。きっかけは一見シンプルな観察だ。患者が待合室で「何を見ているか」「身体をどう動かすか」「誰と話すか」を記録したところ、共通した行動パターンが浮かび上がった——患者は入室直後から「ここに自分は歓迎されているか」を無意識に読み取っていた。 処置を待つ時間よりも、「自分が次に何をすればよいかわからない状態」の方がストレスを生んでいた。これは患者の感情観察なしには見えてこない洞察だ。IDEOがヘルスケアプロジェクトで繰り返し確認している通り、医療不安は「身体的な痛み」より「情報の不確実性」に起因することが多い。 プロトタイプフェーズ：「失敗できる空間」を院内に作る SPARC Labの最大の特徴は、実際の病院フロアの一角に「試作専用スペース」を設けた点だ。既存の医療設備を使いながら、受付フロー・サイン設計・待合座席の配置を実験できる環境を構築した。 ここで重要な設計判断がある。医療現場では「失敗」が患者安全に直結するため、通常プロトタイプの許容度が極めて低い。SPARC Labはこの制約を「フィジカルなレイアウト変更は可逆的に設計する」「プロセス変更のテストは実際の患者動線に影響しない時間帯に限定する」という方法で乗り越えた。プロトタイプの「可逆性の担保」が、患者安全と実験速度を両立させる核心だった。 Mayo Clinicのデザイン・ディレクターだったNicholas LaRusso氏は、SPARC Labを「医療の文化を変えるための触媒」と表現している（The New York Times, 2010年の報道より）。単一の改善プロジェクトではなく、「試すことが評価される文化」を作る場として機能させた点が、IDEO協働の本質的な貢献だった。 --- Stanford d.school：医学生にデザイン思考を教える実験 Stanford大学のd.schoolは、医学部（Stanford Medicine）と連携した教育プログラムを複数展開している。代表的なのが「Design for Extreme Affordability」および医療分野向けの「BioDesign」プログラムとd.schoolの協働による、医療系学生向けデザイン思考ワークショップだ。 医療従事者への共感：「患者の視点」より「現場スタッフの認知負荷」 d.schoolの医療プロジェクトで繰り返し観察されるのが、デザイン思考の初学者が「患者視点」に飛びつく一方で、医療従事者——看護師・研修医・薬剤師——の認知負荷を見落とすというパターンだ。 医療現場における「ユーザー」は患者だけではない。患者体験を直接形成するのは、最前線で働く医療スタッフの判断と行動だ。d.schoolの医療ワークショップでは、「患者の5分間の体験を成立させるために、スタッフはその裏でどれだけの認知リソースを使っているか」を可視化することから始める。 この「エンドユーザーの手前にいる実施者への共感」という視点は、教育・福祉・行政など、サービスに複数の関与者がいるドメインで普遍的に機能するアプローチだ。 定義フェーズ：「問題の正しい粒度」を探す難しさ d.schoolの医療系ファシリテーターが繰り返し言及するのが、医療問題の「問題の粒度」の設定の難しさだ。「病院での待ち時間を短縮する」では広すぎてアイディエーションが発散する。「外科病棟3番ナースステーションの申し送り手順を改善する」では狭すぎてインパクトが出ない。 デザイン思考の定義フェーズで医療に特有なのは、臨床的な問題と体験的な問題を混同しないことだ。「この患者がなぜ服薬を中断したか」という問いは、臨床的には副作用の問題かもしれないが、体験的には「指示が複雑すぎて覚えられなかった」という情報設計の問題かもしれない。問いの粒度と種類を正確に設定することが、医療デザインプロジェクトの成否を左右する。 --- Cleveland Clinic Patient Experience Office：組織に「患者の声」を埋め込む Cleveland Clinicは2009年に世界初の「Chief Experience Officer（CXO）」ポストを医療機関として設置し、患者体験を戦略的優先事項として位置付けた。この決断の背景には、US News & World Reportの病院ランキングで医療技術の卓越性は評価されながらも、患者満足度スコアが全米平均を下回っていたという事実があった。 共感フェーズのスケール化：全スタッフを「共感の訓練者」にする Cleveland Clinicが実施した最も特徴的な取り組みのひとつが、2013年に公開した院内動画「Empathy: The Human Connection to Patient Care」だ。5分間の映像で、病院内を移動するさまざまな人々——患者・家族・スタッフ——それぞれの内的状況を字幕で表示する。言葉は一切なく、音楽と映像だけで構成される（この動画はYouTubeで公開されており、2024年時点で数百万回以上の再生数を持つ）。 Cleveland Clinicはこの動画を全スタッフ研修に組み込んだ。清掃スタッフも、会計担当も、医師も、全員が「病院の中にいるすべての人には、それぞれの事情がある」という視点を持つことを組織的に求めた。これは共感フェーズのプラクティスを、個別プロジェクトレベルではなく組織能力として制度化した事例だ。 テストフェーズ：患者満足度指標の再設計 Cleveland ClinicのCXO就任以降、患者満足度スコアは継続的な改善を示した。2013年のHBR論文（Merlino & Raman, 2013）では、患者体験改善の取り組みが始まった2009年以降、CMS（メディケア・メディケイドサービスセンター）の患者満足度調査（HCAHPS）において改善傾向が確認されたことが報告されている。 重要なのは、Cleveland Clinicが「患者満足度を上げる」という目標から、「患者が体験するすべての接点を再設計する」という問いの立て直しをしたことだ。入院中の医師とのコミュニケーション、退院時の説明の分かりやすさ、痛み管理への対応——それぞれの接点を個別に改善するのではなく、患者が病院に来てから去るまでの連続した体験として設計し直した。これはデザイン思考のカスタマージャーニーマップの発想そのものだ。 --- 医療現場固有の制約と対処法 患者安全：「失敗コスト」が高い環境でのプロトタイプ設計 医療デザインプロジェクトで最も繰り返される問いが「患者に関わるのにどうやってプロトタイプを試すのか」だ。デザイン思考の「早く失敗する」原則が、患者安全と衝突するように見える。 解消できない矛盾ではない。設計で対処できる。 まず「リスクを患者から切り離したプロトタイプ」から始める。 実際の患者に触れる前に、ロールプレイ・シミュレーション・ペーパープロトタイプで最初の検証を行う。Mayo Clinic SPARC Labが示したように、物理環境の変更は可逆的に設計する。 次に、患者の安全に直接影響しない接点から試し始める。待合室の体験・退院後のフォローアップ通知・予約確認のメッセージ設計——こうした「低リスク接点」で学習を積んでから、臨床プロセスに近い領域に進む。順序が逆になると失敗する。 そして、患者の安全を最も理解しているのは現場のスタッフだという事実を設計に組み込む。 医療従事者をプロトタイプの最初の評価者として位置付ける。彼らがNGを出したプロトタイプは患者に届かない——これをボトルネックではなく、安全性の知見をデザインに織り込む仕組みとして活用する。 HIPAA制約：患者データを使った共感フェーズの設計 米国のHIPAA（医療保険の携行性と責任に関する法律）は、患者の医療情報の取り扱いを厳しく規制している。これはデザインリサーチの文脈では、患者観察・インタビュー・データ収集のプロセスに直接影響する。 HIPAAとデザインリサーチを両立する実務的なアプローチとして、複数の医療系デザインコンサルタントが推奨しているのが「情報の匿名化」と「患者本人の明示的同意」の二段構えだ。インタビューや観察から得た洞察を、特定個人に紐づかない形で記録・共有する設計は、プロジェクト設計の段階から組み込む必要がある。 日本では個人情報保護法および医療機関向けのガイドライン（厚生労働省「医療情報システムの安全管理に関するガイドライン」）が同様の機能を持つ。規制を「制約」としてではなく「プロジェクト設計の前提条件」として位置づけることで、リサーチの自由度を担保しながら法的リスクを管理できる。 医療従事者の認知負荷：「忙しい現場」に新しい行動を求めない 医療現場でのデザイン思考導入が頓挫する最大の理由のひとつが、医療スタッフの認知的余裕のなさだ。看護師・研修医は慢性的な過重負荷の状態にあり、「新しいプロセスを学ぶ」「ワークショップに参加する」というコストが、現場からの抵抗として現れる。 この問題への実践的な対処は、プロセス変更ではなく「既存の行動に埋め込む設計」だ。新しい観察シートを記入させるのではなく、すでに発生している申し送りや回診の会話を観察対象にする。ユーザーインタビューを別途設定するのではなく、患者への説明の直後に2分間のフィードバックを求める形式にする。デザイン思考のプラクティスを「追加業務」として設計するのではなく、既存の業務フローの中に溶け込ませることが、医療現場での実装可能性を決定する。 --- デザイン思考5フェーズの医療現場適用ポイント 共感フェーズ：「患者」と「スタッフ」の両方を対象にする 医療の共感フェーズで見落とされがちなのが、患者以外のステークホルダーだ。ステークホルダーインタビューの対象に、看護師・薬剤師・事務スタッフ・患者家族を含めることで、医療体験の全体像が見えてくる。患者にとっての「良い体験」は、スタッフが適切な状態で働けているかに強く依存している。 定義フェーズ：臨床的問題とUX的問題を分離する 「患者が薬を飲まない」という問題は、臨床的には服薬アドヒアランスの問題だが、UX的には指示の理解可能性・副作用管理の透明性・リマインダー設計の問題だ。同じ事象に、異なる専門家が異なる言葉で向き合っている。定義フェーズで臨床チームとデザインチームが同じHMW（How Might We）フレームを使って問いを立て直すプロセスを設けると、双方の視点が統合された問題定義が生まれる。言語を揃えるだけで、議論の質が変わる。 アイディエーション：多職種ミックスで「領域外の視点」を持ち込む 医療のアイディエーションセッションは、医師・看護師だけでなく、患者・患者家族・デザイナー・エンジニア・事務スタッフをミックスして設計すると、斜め上のアイデアが生まれやすい。医療の常識が「当然の前提」になっている参加者だけでは、radical improvementより incremental fixに留まることが多い。 ワークショップ対立マネジメントの観点では、多職種ミックスのセッションは「部署間の対立」が持ち込まれるリスクがある。「今日は職種を横に置く場」という合意を冒頭で取ることが、有効な予防策だ。 プロトタイプ：「物理的な可逆性」を最初に設計する 前述の通り、医療プロトタイプは可逆性が命だ。プロトタイプの設計段階で「このプロトタイプを元に戻すには何が必要か」を先に決める。電子カルテのUI変更であれば、切り替えスイッチを先に実装する。ナースコールの改善であれば、既存のシステムと並行稼働できる形にする。 テストフェーズ：指標の「臨床アウトカム」と「体験指標」を分ける 医療のテストフェーズでは、臨床的な成果指標（再入院率・服薬継続率・合併症発生率）と体験的な指標（患者満足度・情報理解度・処置への不安レベル）の両方を設定する。どちらか片方だけでは、介入の効果を正確に評価できない。「患者は満足しているが、臨床アウトカムが改善していない」という結果も重要な学びだ。 --- 日本の医療現場への示唆 日本における医療デザインの取り組みは、公開情報の範囲では米国の先行事例と比較してまだ限定的だ。ただし、方向性として確認できる動きはある。 東京医科歯科大学は2020年代に入り、医工連携・患者体験改善の研究領域を拡充している（大学公式ウェブサイト・研究発表資料より）。聖路加国際病院は患者中心医療の理念を長年掲げており、患者体験に関する調査・改善のプロセスを継続的に実施している（同病院の年次報告書・広報資料より）。 ただし、本記事では具体的な数値や詳細な実施内容の確認が取れなかった事例については記述を控える。日本での医療デザイン事例は今後の取材・調査の対象として位置づけ、確認できた範囲の情報のみを扱う。 医療現場でデザイン思考を実装したい実務者への最初のアドバイスは、「どの接点から始められるか」を問うことだ。海外事例を完全移植しようとすると、最初のハードルで止まる。SPARC Labのような大規模な実験室は必要ない。既存の申し送り会議の15分を「患者の声を読み上げる時間」に変えることから、医療現場のデザイン思考は始まる。小さく始めた実践が、文化を変える。 --- 内部リンク - カスタマージャーニーマップ実践ガイド - デザイン思考のステークホルダーインタビュー - ワークショップ対立マネジメント完全ガイド - デザイン思考の組織導入ガイド --- 参考文献 - IDEO. "Design Thinking for Health." IDEO.org, https://www.ideo.org/approach — IDEOの医療・公衆衛生分野でのデザイン思考アプローチ概要（公式ページ） - Merlino, J. I., & Raman, A. (2013). "Health Care's Service Fanatics." Harvard Business Review, May 2013. https://hbr.org/2013/05/health-cares-service-fanatics — Cleveland Clinic患者体験改革の一次資料 - LaRusso, N. F., Spurrier, B., & Farrugia, G. (2015). "The Mayo Clinic Center for Innovation: Transforming Clinical Practice." Mayo Clinic Proceedings, 90(10), 1365–1368. — SPARC Labの背景にあるMayo Clinic Center for Innovationの設立経緯と目的を解説した査読論文 - Plattner, H., Meinel, C., & Leifer, L. (Eds.). (2012). Design Thinking Research: Studying Co-Creation in Practice. Springer. — Stanford d.school研究者による設計思考研究の学術的基盤 - Cleveland Clinic. "Empathy: The Human Connection to Patient Care." YouTube, 2013. https://www.youtube.com/watch?v=cDDWvj_q-o8 — 全スタッフ共感研修に使用された動画（公式チャンネル、数百万回再生） - Haskins, G. (2018). A Practical Guide to Critical Thinking. Wiley. — 医療現場での問題定義の粒度設定に関連する批判的思考の参照枠組み - Brown, T. (2009). Change by Design. HarperBusiness. — デザイン思考の組織実装における標準的な参照文献 --- ### デザイン思考 金融サービス革新の実装事例｜銀行・保険・証券の制約突破と落とし穴 URL: https://designthinking.studio/articles/design-thinking-finance-services/ > デザイン思考を金融サービスに導入する実践ガイド。Capital One・BBVA・みずほ・SBIの事例を構造化し、規制業種ならではのコンプライアンス制約・リスク回避文化・縦割り組織という3つの壁と、現場チームがそれを突破する具体策を解説する。 「規制があるからデザイン思考は使えない」——金融業界でデザイン思考を導入しようとするとき、最初に聞こえてくる声がこれです。 規制がデザイン思考の敵なのではない。規制を言い訳にする組織文化こそが、イノベーションの本当の障壁です。 Capital OneもBBVAも、それぞれ異なる規制環境の中でデザイン思考を組織の芯に据えて競争優位を構築した。問題は規制ではなく、規制への向き合い方にある。 金融サービスにデザイン思考を適用するとき、他業種と異なる構造的な制約が3層で存在します。本記事では、その制約の構造を解剖しながら、国内外の実装事例を比較し、現場チームが即日使える突破策を提示します。 --- なぜ金融はデザイン思考の「難しい業種」なのか 規制とUXは本当に相反するのか 金融業界でデザイン思考の導入が遅れた背景には、「規制対応とユーザー体験設計は両立しない」という根強い誤解があります。本人確認（KYC）・反マネーロンダリング（AML）・情報開示義務・個人情報保護——これらのコンプライアンス要件が、UX改善の余地を本質的に狭めているという認識です。 だから実は、規制が求めるのは「何を達成するか」だけ。「どう実装するか」は自由度がある。 本人確認を法令通りこなしながら、ユーザーにストレスをかけない——これはトレードオフではなく、設計次第なのだ。 実際、マッキンゼーの2018年調査では、デザイン思考を本気で実践する金融機関の方が、やらない企業より株主利益が2倍以上だった。規制対応の手間より、ユーザー中心設計から生まれるリターンの方が大きいということだ。 3層の構造的制約 金融業界特有の制約は、大きく3つの層に整理できます。 第1層：外部規制の制約。 金融庁・FRB・EBAなどの監督当局が定めるルール。変更できない代わりに、解釈の幅がある。コンプライアンス部門を「ノー部門」から「YES を探す部門」に変えることが鍵。 第2層：組織文化の制約。 リスク回避を最優先とする意思決定文化、「前例がない」を理由に止まる慣性。この層は変更可能だが、時間と意図的な介入が必要です。 第3層：システムの制約。 レガシーITシステム、縦割りのデータサイロ、勘定系と新規サービス基盤の非連携。この層は最も変更に時間がかかるが、APIレイヤーやサービスメッシュ化で迂回できます。 --- 国際事例の構造分析 Capital One：デザイン思考をビジネスモデルに組み込んだ米国の先駆 Capital Oneは2014年、Adaptive Path社の買収という形でデザイン力の内製化を宣言した。 その後、UXリサーチ・インタラクションデザイン・サービスデザインの専門家を積極採用し、プロダクトチームにデザイナーを常駐させる体制を構築しました。 Capital One Caféはその象徴だ。銀行の支店をコーヒーショップにして、「金融の相談も気軽に」という場を作った。全米50拠点以上に広がり（Capital One公式）、ここで得られた顧客の行動観察がデジタルUXに次々とフィードバックされている。 核心は、コンプライアンス部門を最初から入れたこと。 リリース直前に「アウト」と言われるんじゃなくて、プロトタイプの段階で「ここまでなら大丈夫」という線引きができる体制にした。デザインとリーガルが一緒に考える設計だ。 BBVA：欧州の規制環境でAPIバンキングに転換した事例 スペインに本拠を置くBBVAは、2014年にSimple（米国のフィンテック企業）を1.17億ドルで買収し、UX設計能力を取り込みながら、自行のデジタルバンク戦略を加速させた。 Simpleのミッションは「ユーザーが自分の財務状況を直感的に理解できる銀行」——これがBBVAのデジタルトランスフォーメーションの設計思想に直接流入しました。 BBVAが特筆されるのは、Open APIプラットフォーム「BBVA API Market」の構築です（BBVA API Market）。自行の金融機能をAPIとして外部デベロッパーに公開することで、フィンテック企業との協業生態系を構築しました。規制（PSD2: 欧州決済サービス指令）を制約ではなくビジネス機会として読み替えた戦略的転換の実例です。 PSD2が定める「第三者サービスへのデータ開放義務」を、BBVAは最小限の対応に留めず、プラットフォームビジネスに転換した。 この発想の転換こそが、規制業種におけるデザイン思考の本質的な意義を示しています。 ING Direct：サービス設計の簡素化で顧客獲得した直販モデル オランダのING Directが2000年代に展開した「シンプルな直販銀行」モデルは、複雑な商品ラインナップと難解な手数料体系という業界慣行を、顧客視点で解体した事例として評価されています。 ほとんどの銀行が「選択肢の多さ」を価値として訴求していた時代に、ING Directは預金と住宅ローンだけに特化し、支店を持たないデジタル完結型のモデルで急成長しました。顧客が「なぜ手数料がかかるのかわからない」「何を選べばいいかわからない」という痛点を根本から取り除く設計です。 --- 国内事例の構造分析 みずほフィナンシャルグループ：大組織でのデザイン思考導入の現実 みずほFGは2019年、「みずほリサーチ&テクノロジーズ」内にデザイン思考・サービスデザインの専門組織を設置し、顧客接点改善プロジェクトを起動しました。 しかし大組織での導入には、特有の課題が伴います。 最大の壁は「縦割りのサイロ」です。個人部門・法人部門・IT部門・コンプライアンス部門がそれぞれ別の指揮系統で動き、横断的なユーザー体験設計が構造的に難しい。あるプロジェクトでは、ウェブサイトのUI改善に半年以上要した事例が報告されています。改善案を実装するには、5部門以上の承認が必要だったためです。 突破策として採用されたのが「スモールチームによるプロトタイピングファースト」の手法です。全行展開の承認を取ってからではなく、特定の支店・特定の顧客セグメントに限定した実験として先に動かし、実績データで合意形成する。 規模の制約をパイロット設計で迂回するアプローチです。 SBI証券：フィンテック発想でデザイン組み込んだネット証券の事例 SBI証券は2000年代から一貫してデジタルファーストの設計思想を持ち、ネット証券の国内最大手に成長しました。特に2010年代後半のNISA・iDeCoの普及局面で「投資初心者が挫折しないUI設計」を競争軸に置いた点が、ユーザー体験設計の観点から評価されています。 投資未経験のユーザーが直面する最大の障壁は「選択肢の複雑さ」と「リスク許容度の自己評価困難」です。SBI証券のロボアドバイザー「SBIラップ」では、投資家のリスク許容度をシンプルな質問形式で把握し、最適ポートフォリオを自動提案する設計を採用しました（参考: SBI証券公式）。 これは複雑な金融リテラシーを必要としていた作業を、意思決定の構造として再設計したデザイン思考の典型的な適用です。「何を選べばいいかわからない」という問題定義から出発し、「選ばずに始められる」という解決策に至った思考の流れが見えます。 --- 金融業界特有の3つの落とし穴 落とし穴1：コンプライアンス部門を「後工程」に置く 最も頻発するパターンです。デザインチームがプロトタイプを作り込み、実装直前にコンプライアンスチェックを受け、全面修正を命じられる——このサイクルを繰り返す組織は珍しくありません。 原因は簡単だ。コンプライアンスを「最後にチェックする部門」として扱ってる。 スプリントの初日からコンプライアンス担当者を入れて、「規制の中で何ができるか」を一緒に考えると、後から「全面修正」という手戻りが消える。 デザインとリーガルの共同設計モデルにより、後工程での修正負担が大幅に軽減されることが報告されています。 落とし穴2：顧客調査を「モニタリング」で代替する 金融業界には大量のトランザクションデータが蓄積されています。この量的データの豊富さが、定性調査（インタビュー・エスノグラフィー）を軽視する文化につながりやすい。 「なぜその行動をとるのか」という文脈と感情は、トランザクションデータからは読み取れません。 投資アプリを一度開いて使わなくなったユーザーが、次に開くまでに何を考えていたか——これを理解するには生の会話が必要です。 顧客調査をしない金融機関は、得てして「解約防止キャンペーン」に直行する。「なぜ解約したいか」を聞く前に、お金とインセンティブで食い止めようとする。根本解決にならないのは言うまでもない。 落とし穴3：UXをフロントエンドに閉じ込める アプリのUIだけをきれいにしたり、窓口マニュアルだけ改善するのはこれ。「デザイン思考を一部に当てた」のであって、「事業そのものを設計し直した」わけじゃない。 金融サービスの本質的な課題は、プロダクトの複雑さ・情報の非対称性・意思決定の困難さというサービスの構造的問題にあります。 フロントエンドのUI改善だけでは、これらの根本は変わりません。 BBVAのAPI開放戦略が評価されるのは、フロントエンドのUXを改善したからではなく、銀行の機能を「APIとして外部に提供できるサービス群」として再定義したからです。これはバックエンドのアーキテクチャ変更を含む、事業モデルレベルのデザイン思考の適用です。 --- 規制業種でのデザイン思考適用：5段階の実装ロードマップ Phase 1：規制マップの共同作成（1〜2ヶ月） デザインチームとコンプライアンスチームが協働で「規制の可視化」を行います。「これは絶対にできない」「ここは解釈の余地がある」「規制はないが社内慣行で止まっている」の3分類に整理することで、本当の制約と自己規制を分離できます。 実践的には「制約のポスターセッション」がいい。主要規制を壁に貼り出して、チームメンバーが「これは何を守る規制か」「この中で何ができるか」をポストイットで付け足す。規制の本当の目的が見えると、別のやり方が出てくる。 Phase 2：課題定義のためのユーザーリサーチ（2〜3ヶ月） 数字だけじゃなく、定性調査を並行する。「ヘビーユーザー」「解約しかけてる人」「未利用者」の3種類、最低5名ずつ話を聞く。目的は「この機能、どう?」じゃなくて、「なぜそう行動するのか」を知ることだ。 「最後に金融サービスで困ったのはいつですか」という開放型の質問から始め、具体的なエピソードに深堀りする。 「繰り上げ返済の方法を調べたが、どこに書いてあるかわからなくて1時間かかった」という一つのエピソードが、構造的な問題の仮説になります。 Phase 3：制約条件付きプロトタイピング（1〜2ヶ月） 「規制の中で動く最小版を、2週間で作る」スプリント設計が有効だ。 完成品じゃなくて、ユーザーに触ってもらう段階の試作。紙プロトタイプやスライドで十分。 ここで重要なのは、コンプライアンス担当者をスプリントチームに含めること。「これは〇〇の観点で問題になる」という指摘をリアルタイムで受けながら設計を修正する共同作業が、後工程での手戻りを消します。 Phase 4：パイロット実装と計測（3〜6ヶ月） いきなり全社展開じゃなく、特定の支店や顧客層に限った実験として動かす。成功基準を「全行に広げたか」から「この指標が何%上がったか」に変えれば、承認が通りやすくて、実績が積める。 計測指標の選定が鍵です。「顧客満足度スコア」という抽象指標より、「申込完了率」「問い合わせ件数の変化」「特定ステップでの離脱率」という行動指標を中心に置くことで、改善の因果関係が明確になります。 Phase 5：組織への定着（継続） 実験の成果を組織の知恵に変えることだ。成功も失敗も「ここから何が見えたか」を文書に残して、次のプロジェクトに渡す。この習慣がデザイン思考の定着を決める。 SBIグループが複数のフィンテック実験を継続できているのは、実験の成否にかかわらず組織が学習を積み上げている体制があるからです。失敗を個人の責任ではなく組織の学習資産として扱う文化の転換が、長期的な競争力の源泉になります。 --- 日本の金融機関特有の障壁と突破策 「稟議文化」とアジャイル設計の衝突 日本の金融機関の一番の障壁は、意思決定が遅いことだ。稟議・承認・月次会議という時間軸は、2週間ごとに試して学ぶデザイン思考のスピード感とまったく合わない。 突破策は「権限の見える化」。「この範囲内なら、チームで決定できる」という枠を事前に上司と決めておく。稟議がいる判断といらない判断を分けることが、実行スピードを決める。 フィンテックとの協業による制約の外部化 メガバンクや地銀が直接は解決できない制約は、フィンテック企業との協業で迂回できる。自行のシステムを変えずに、APIでフィンテックの機能を借りるやり方で顧客体験を上げる。 金融庁もFinTechサポートデスクでこうした協業を積極的に応援している。 住信SBIネット銀行が採用した「BaaS（Banking as a Service）」モデルは、この方向性の典型例です。自行のシステムを、住宅ローン申込等の機能としてパートナー企業に提供する。ユーザーはパートナーのアプリで銀行機能を使える設計です。 --- 何から始めるか：現場チームへの3つの提案 金融業界でデザイン思考を始めるなら、全社改革を狙うと止まる。「1つの問題を、1つのチームで、3ヶ月で解く」という粒度に落とす。これが最初の一歩だ。 提案1：コンプライアンス担当者と、気軽に話す。 「このアイデアは規制上できる?」を1時間雑談するだけで、思ったより制約がないことに気づく。「できないか」を聞く会話と「どうやってできるか」を考える会話は全く違う。 提案2：「解約したばっかりのユーザー5人」に話を聞く。 ここ3ヶ月で口座やサービスを解約した人に、30分ずつ聞く。なぜ去ったのか——そこに、いま何が足りないかが最も鮮明に出る。 提案3：いま何が問題かを1文で言ってみる。 そのとき「顧客の立場で」言えているか、「会社の内部用語」になってないか、確認する。「申込の離脱率が高い」は数字であって、顧客の問題じゃない。顧客が実際に「なぜ困ってるのか」の場面を思い描けてこそ、設計の入口が見える。 --- 特にこのような組織・チームに適している デザイン思考を金融サービスに導入する効果が最も高く出るのは、以下の条件に当てはまる組織です。 - 「競合より機能が少ないわけではないのに、顧客満足度スコアが上がらない」というギャップを抱えている - フィンテック企業との競争圧力を感じ、スピードの差に危機感を持っているが、何から変えるべきかが定まっていない - 大型ITシステム更新の直前にあり、顧客体験の再設計を同時に進める好機がある - 若手・中堅層に「もっと早く動けるはずだ」という意欲があり、組織から阻まれている感覚を持っている 逆に、「全社的に文化を変える」という掛け声だけでは何も起きない。 最初に「この施策で申込が15%増えた」「この変更で問い合わせが月200件減った」——こういう成果事例を作ることが、組織文化を変える唯一の方法だ。 --- 関連リソース デザイン思考の問題定義フェーズの詳細はdefineフェーズの概要を参照してください。規制業種でのサービスデザイン適用の事例比較はデザイン思考 非営利組織の問題定義ワークショップも参考になります。デザイン思考の組織全体への定着については組織導入の完全ガイドで体系的に解説しています。金融領域でのプロトタイピング手法についてはプロトタイプフェーズのガイドを参照してください。 --- 参考文献 - McKinsey Global Institute (2018). The Business Value of Design. McKinsey & Company. — デザイン投資と財務パフォーマンスの相関を大規模調査で実証した報告書。金融業種を含む300社以上を対象。https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design - Capital One Design Team (2019). "Co-designing with Compliance: How We Changed the Conversation." UX Design Conference 2019発表資料。コンプライアンス共同設計モデルの実践内容を詳述。 - BBVA (2022). BBVA Open API Platform: Developer Documentation. https://www.bbvaapimarket.com/ — BBVAのAPIバンキング戦略と公開API仕様の公式資料。 - 金融庁 (2024). FinTechサポートデスク・実証実験ハブ運営方針. https://www.fsa.go.jp/policy/fintech/ — 国内金融規制の中でのフィンテック実験が許容される範囲と手続きを定めた行政文書。 - Liedtka, J., King, A., & Bennett, K. (2013). Solving Problems with Design Thinking: Ten Stories of What Works. Columbia University Press. — デザイン思考の実装事例を10組織の比較で分析。金融業種を含む規制業種での適用事例を含む。 - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. — デザイン思考プロセスの全体設計と、組織変革としての位置づけを論じた基本文献。 --- ### デザイン思考 公共部門・自治体活用の実践 — 行政改革ケース3選と現場の壁 URL: https://designthinking.studio/articles/design-thinking-public-sector-innovation/ > デザイン思考を公共部門・自治体の行政改革に適用した国内外の実践ケース3選。民間と異なる制約構造を踏まえた上で、なぜこのアプローチが機能するのか、どこで躓くのかを具体的に解説する。 「民間企業のやり方を行政に持ち込んでも、うちには通じない」——公共部門でデザイン思考のワークショップを実施すると、この言葉を必ず聞く。法規制・予算サイクル・議会への説明責任・縦割り組織構造。民間とは根本的に異なる制約の中で、デザイン思考はどう機能するのか。 答えから言えば、「制約が多いからこそデザイン思考が効く」場面がある。一方で「制約の構造をそのままにするとデザイン思考は形骸化する」場面も存在する。この記事では国内外3つの実践ケースを通じて、その境界線を明確にする。 --- 公共部門でデザイン思考を使う意味 民間企業のデザイン思考導入と行政のそれは、根本的に目的が違う。民間はユーザー体験の改善によって競争優位を得ることが最終目標になりがちだが、行政の場合は「市民の生活課題を解決すること」が制度上の使命として明文化されている。 この違いは重要だ。行政にはすでに「ユーザー中心設計」の理由が内在している。問題は「なぜやるか」ではなく「どうやって実現するか」の方法論が欠落していることにある。デザイン思考はその方法論を提供する。 公共部門固有の制約も、整理すると3層に分かれる。制度的制約（法律・規制による設計の限界）、構造的制約（年度予算・調達ルール・縦割り組織）、文化的制約（前例主義・失敗回避・合意形成の複雑さ）。 デザイン思考が最も機能するのは、制度的制約の中でいかに選択肢を広げるかという問いに対してだ。逆に言えば、構造的・文化的制約には別のアプローチも組み合わせる必要がある。 --- ケース1：神戸市「こうべの居場所づくり」プロジェクト 背景と課題 神戸市は2018年頃から、高齢者の社会的孤立問題に取り組むにあたってデザイン思考のアプローチを採用した。従来の行政的アプローチは「施設をつくる」「プログラムを提供する」という「モノの設計」に傾いていた。しかし高齢者の孤立問題は、施設の有無より「なぜ外に出ないのか」「どんな場所なら行きたいと思うか」という感情的・行動的な問いに答えないと解決しない。 担当課は地域の高齢者宅への戸別訪問インタビューを実施した。「公民館は知っているが行ったことがない」「参加者がみんな顔見知りで入りにくい」「バスに乗るのが不安」——聞いてみると、施設の整備や情報提供だけでは届かない障壁が浮かび上がった。 どうアプローチしたか 収集した観察データを庁内の横断チームでKJ法的に整理し、インサイトを抽出した。「人が来ない理由の多くは、物理的距離より心理的ハードル」というインサイトが中心に据えられた。 これを受けて設計されたのが、既存の公民館に「非公式な入口」を設ける実験だ。カフェコーナーを設置し、「プログラム参加」ではなく「コーヒーを飲みに来る」という目的で足を踏み入れられる場所を作った。プロトタイプは最小限の予算で開始し、週1回の運営から反応を見ながら改善した。 公共部門特有の壁と突破口 実施にあたって最初の壁は「目的外使用」の問題だった。公民館にカフェを設けることが、施設の本来目的と合致するかという解釈問題が生じた。担当職員はこれを法務部門と事前に協議し、「地域コミュニティ活性化」という上位目的に紐づけることで承認を得た。 ワークショップでよく起こるのは、「できない理由」の列挙で止まることだ。 しかしこのケースが示すのは、「できない理由」を解釈論の問題として捉え直すと、打開策が見えてくるということだ。制約は固定されたルールではなく、その解釈に余地がある。 --- ケース2：エストニア政府の電子行政設計 背景 エストニアはデジタル行政の先進事例として世界的に注目されている。人口130万人弱の小国が、確定申告・選挙・法人登記・医療記録の共有を全てデジタルで完結させる仕組みを構築した。この設計の背景には、「市民を中心に設計する」というHCD的な発想が一貫している。 エストニアのデジタル行政設計が特徴的なのは、技術ファーストではなく「市民が何をやり遂げたいか」から設計を始めたことだ。確定申告の場合、市民の目標は「正確な申告書を提出すること」ではなく「税を正しく納めた状態になること」だ。この目標に遡ると、「申告書の記入」という作業自体を消去することができる。 デザイン的アプローチの具体像 エストニアのX-Road（政府間データ連携基盤）の設計思想は、「データは一度だけ提出すればいい」というワンス・オンリー原則だ。市民が役所に提出した情報を、別の手続きでも共有可能にするシステム設計は、「なぜ同じ情報を何度も書かなければならないのか」というシンプルな問いから生まれた。 これはデザイン思考でいう「問題の再定義」そのものだ。「申告書のフォームを改善する」という問いを立てずに、「そもそも申告書を書かせないためにはどうするか」という問いに変換している。 日本への示唆 エストニアのモデルをそのまま日本の自治体に移植することは難しい。国土面積・人口規模・既存のレガシーシステム・政治的コンテクストが根本的に異なる。しかし「問いの立て方」は移転できる。「どうすれば今の手続きを電子化できるか」ではなく「この手続きをそもそもなくせるか」と問うことは、どの自治体でも可能だ。 --- ケース3：渋谷区の「障害者手続きワンストップ」改善 問題発見のプロセス 渋谷区では障害福祉サービスの利用申請プロセスの改善に取り組むにあたって、当事者へのフィールドリサーチを実施した。障害のある当事者が複数の窓口を往復しながら手続きを行う現状を「サービスブループリント」の形式で可視化した。 可視化して初めて見えたのは、同じ情報を異なる担当課に5回提出しているという事実だった。担当課同士の情報共有の仕組みがなく、それぞれが「確認のため」に同じ書類を要求していた。担当者は問題を認識していなかった。なぜなら各自は自分の担当部分しか見えておらず、プロセス全体を俯瞰する視点がなかったからだ。 ステークホルダーの複雑性 公共部門のデザイン思考において、民間と最も大きく異なるのはステークホルダーの複雑性だ。渋谷区のこのケースでは、障害当事者・家族・福祉担当課・医療機関・地域の支援事業者・区議会・財政担当課が全員ステークホルダーとして存在する。 ステークホルダーマッピングを丁寧に実施すると、「誰の課題を最優先に解決するか」という問いが浮上する。当事者と行政担当者の優先度が一致しない場面も多い。「誰のためのデザインか」という問いを常に問い直す作業が、公共部門では特に重要になる。 改善の結果、複数課で情報を共有する仕組みが導入され、当事者の往復回数が削減された。技術的な解決策ではなく、組織間の連携設計という構造的な変化だった。 --- 公共部門でデザイン思考が「形骸化」するとき ここまで機能した事例を見てきたが、形骸化するパターンも整理しておく必要がある。デザイン思考の組織導入における失敗事例と共通する構造が、公共部門にも存在する。 「アリバイ参加型」の市民ワークショップ。 設計方針が先に決まっており、市民参加のプロセスは「やった」という形を作るためのものになる。参加者の意見が設計に反映されない構造が固定化していると、何回ワークショップを実施しても現場は変わらない。 「年度末プロトタイプ問題」。 年度予算の消化に合わせてプロトタイプを作るが、年度が変わると担当者が異動し、学習が引き継がれない。デザイン思考の本質は反復改善だが、年度単位の組織では「試して学ぶ」サイクルが年度の壁で断ち切られる。 「専門家依存型」のプロセス。 外部コンサルタントにデザイン思考のプロセスを委託し、庁内に学習が残らない。プロジェクト終了後、次の課題に対して同じアプローチを自分たちで展開できない。 --- 実践するための最小ステップ 大規模な改革でなくても、小さな問いから始められる。 窓口業務の「詰まり観察」から始める。 1日だけ窓口に立ち、市民がどこで手が止まるかを観察する。「なぜここで止まったのか」を問うだけで、問題の種が見つかる。 「担当外」の視点を意図的に持ち込む。 自分の担当部分だけで問題を定義しない。上流・下流の担当者と共にプロセスを可視化すると、見えていなかった断絶が浮かぶ。 小さく試して記録する。 予算をかけずに1つの接点だけ変えてみる。その結果を記録し、「何が起きたか」を数週間後に検証する。このサイクルが庁内に積み上がると、デザイン思考は「ワークショップで使う手法」から「日常の業務姿勢」に変わる。 --- 公共部門でのデザイン思考の実践は、民間と同じプロセスでは機能しない部分がある。しかし、「誰のためのサービスか」と問い直す力と、小さく試して学ぶ反復の姿勢は、制約の多い環境でこそ有効だ。大きな変革を一度に起こそうとしないことが、むしろ持続的な変化につながる。 関連する手法として、ステークホルダーマッピングと大規模組織における導入事例もあわせて参照してほしい。都市規模でのデザイン思考実践についてはスマートシティ・都市イノベーションへのデザイン思考適用も参考になる。また、行政サービス改革の最新事例についてはデザイン思考 行政サービス改革｜市民中心の公共設計7つの実践で詳しく解説している。AI時代の創造性と公共サービス設計の関係についてはAI時代に人間の創造性はどこへ向かうのかも参照してほしい。 --- ### デザイン思考 行政サービス改革｜市民中心の公共設計7つの実践 URL: https://designthinking.studio/articles/design-thinking-government-service-reform/ > 「届かない給付金」「使われない窓口」——行政サービスが機能しない根本には、市民の実態を見ずに制度を設計する構造的な問題がある。GDS・ヘルシンキ市・デジタル庁の事例から、デザイン思考が行政に持ち込む7つの実践を解説する。 「行政の手続きが分かりにくい」という声は、利用者の読解力の問題ではない。 英国政府デジタルサービス（GDS）が2011年末に設立された背景には、政府のデジタルサービスに対する国民の深刻な不信があった。当時の政府サービスの平均ユーザー満足度は54%（英国政府「Government Digital Strategy 2012」記載値）。同時期の民間デジタルサービスと比べて20ポイント以上低い。問題は技術ではなかった。「誰のために」「どのように使われるか」を起点に設計されていない、という構造的な欠落——それが核心だった。 GDSが採用したのがデザイン思考に基づくサービスデザインだ。行政サービス改革においてデザイン思考がどう機能するか、民間と何が違うかを、具体的な現場から見ていく。 --- 行政サービスに特有の設計課題 行政サービスをデザイン思考で改善しようとすると、民間とは異なる3つの構造的制約に直面する。 制約1: ユーザーは「選べない」 民間サービスなら気に入らなければ他社に乗り換えられる。行政サービスには競合がない。住民票を取るのに他の自治体に行くことはできないし、確定申告を別の税務署に依頼することもできない。この「逃げ場のない利用者」の存在は、デザインの倫理的責任を格段に高める。不満があっても使うしかない。フィードバックが機能せず、問題が見えないまま放置される。 制約2: 「意図せぬ利用者」への対応 民間のプロダクトは特定のターゲットに向けて最適化できる。行政サービスは原則として全市民が対象だ。デジタルリテラシーが高い30代のビジネスパーソンも、高齢の農村住民も、障害を持つ利用者も、すべてが想定ユーザーに含まれる。最も脆弱な状況にある利用者がスムーズに使えるかどうかが設計の基準になる。これはアクセシビリティの問題であると同時に、共感フェーズのスコープが民間より広くなることを意味する。 制約3: 縦割り構造と意思決定の遅さ デザイン思考のプロトタイプ・テストサイクルは「素早く作って、素早く検証する」ことを前提とする。しかし行政では、法規制・情報セキュリティ要件・予算承認・省庁間の調整が必要なため、一つの変更を実装するまでに数ヶ月から数年を要することがある。この「スピードの構造的非対称」を前提に、デザイン思考のどのフェーズをどの文脈で使うかを選択することが実践の鍵になる。 --- GDSが証明したこと——「サービスデザイン原則」の成立 英国GDSが2013年に公表した「Government Design Principles」は10項目からなる。その最初の項目は "Start with user needs"（ユーザーニーズから始めよ）——行政の設計が技術や法制度から出発しがちだという現実への、明確なアンチテーゼだ。 GDSが設立直後に手がけたプロジェクトのひとつが「GOV.UK」の統合だった。それまで英国政府には750以上の独立したウェブサイトが乱立しており、市民はどのサイトで何の手続きができるか分からない状況にあった。GDSはユーザーインタビューと観察を徹底的に行い、実際に市民が政府サービスを使おうとするときの「認知地図」を把握した上でアーキテクチャを再設計した。 2012年のベータ公開から1年で、GOV.UK は政府の主要デジタルサービスを1つのプラットフォームに統合。利用者満足度は設立前の54%から86%に上昇した（英国政府公式報告書）。 行政でデザイン思考が機能することを、GDSは数字で示した。 --- ヘルシンキ市のサービス実験室——「Lähiö」プロジェクト フィンランド・ヘルシンキ市の実践は、行政サービスデザインの現場を具体的に見る上で欠かせない事例だ。 ヘルシンキ市は2010年代から「Forum Virium Helsinki」と協働し、市のサービスデザインに住民参加型のアプローチを積極的に導入してきた。特筆すべきプロジェクトのひとつが、移民コミュニティへの行政サービス改善だ。 従来の市の窓口では、言語の壁と手続きの複雑さから、移民住民が必要なサービスにアクセスできていないことが分かった。担当職員は「案内を多言語化すれば解決する」と考えていたが、ユーザーリサーチによって全く異なる課題が浮かび上がった。言語よりも、「誰に聞けばいいか」という信頼関係の欠如が最大の障壁だったのだ。 これを受けてヘルシンキ市が設計したのは、既存の移民コミュニティのネットワーク（宗教コミュニティ・母国語話者グループ）を行政サービスへの「つなぎ役」として公式に組み込む仕組みだった。テクノロジーや多言語対応ではなく、「信頼できる人を介在させる」という人間関係の設計が解決策になった。 --- デジタル庁の「ユーザーテスト先行」——日本の変化 日本でも変化の兆しは明確だ。2021年9月に発足したデジタル庁は、「利用者視点の原則」を設計思想の中心に据え、行政手続きの整備においてユーザーテストを実施している。 特に注目されるのが、マイナポータルのUI改善プロセスだ。デジタル庁は実際の市民がマイナポータルを使用する様子を観察し、「ログインのステップが分からない」「申請完了の確認ができない」といった具体的な詰まりポイントを特定したうえで改修を行った。ワークショップ現場でよく見られるのと同じ光景——「設計者には当然に見えることが、利用者には全く分からない」という発見が、行政サービスのレベルでも繰り返されていた。 デジタル庁の設計指針「デジタル社会の実現に向けた重点計画」においても、利用者視点・UXの向上が明示的に言及されている。行政の文脈でデザイン思考の語彙が公式に使われ始めた転換点として、デジタル庁の発足は記録しておく価値がある。 --- 行政サービス改革でデザイン思考が機能する7つの実践 GDS・ヘルシンキ市・デジタル庁の実践を横断すると、行政文脈でデザイン思考が機能するための具体的なパターンが見えてくる。 実践1: サービスサファリ——職員が「利用者として」体験する 担当職員が匿名の市民として行政窓口を利用してみる。自分たちが設計したサービスを利用者目線で体験することで、「設計者の常識と利用者の現実のズレ」が初めて可視化される。 実践2: シャドーイング——実際の利用場面を追う 住民が申請書を書いている場面、窓口で手続きする場面を観察する。どこで手が止まり、どこで職員を呼ぶか。そのパターンが、設計の穴を教えてくれる。 実践3: HMW（How Might We）問いの転換 「申請書のフォームをデジタル化する」という出発点ではなく、「市民が必要なサービスにたどり着くにはどうすればいいか」と問いを立て直すことで、解決策の幅が広がる。問題定義フェーズの核心は、行政でも変わらない。 実践4: プロトタイプの「最小化」——紙とロールプレイで十分 システムを作る前に、紙のモックアップと職員のロールプレイで「この流れで市民は手続きできるか」を検証する。ITシステムの調達前に問題を発見する。それだけで修正コストは桁違いに小さくなる。 実践5: 「最も困難なユーザー」から設計する デジタルリテラシーが低い利用者、日本語が第一言語でない利用者、心理的余裕がない状況（病気、失職直後など）で手続きを行う利用者を想定して設計する。この層が使えるものは、他の全員にも使える。共感フェーズを最も脆弱な状況に拡張することが、行政設計の出発点だ。 実践6: 職員を「共同デザイナー」にする 窓口の最前線で市民の困惑を毎日見ている職員は、膨大な暗黙知を持っている。その知識をデザインプロセスに引き込まない手はない。外部コンサルタントだけでは届かない解像度の問題定義が、ここから生まれる。 実践7: 「小さな成功」を早期に可視化する 行政の全体最適を狙った大型改革は実現に数年かかる。そのプロセスで関係者の意欲が失われる前に、1つの窓口・1つの手続きで効果を示す「パイロット成功事例」を作る。ダブルダイヤモンドの「Develop」フェーズを小規模に回すことが、大きな変革の入り口だ。 --- 「市民中心」が建前に終わらないための条件 ただし、デザイン思考を持ち込めばそれで解決する、というほど話は単純ではない。 GDSの初代ユーザーリサーチ責任者（Head of User Research）を務めたBen Terrettは2018年の『Public Digital Blog』掲載インタビューで、「行政でデザイン思考が機能するかどうかは、最終的には組織の政治的意志の問題だ」と語っている（Terrett, 2018）。ユーザーリサーチで問題が明らかになり、解決策のプロトタイプが機能することが分かっても、予算・法規制・省庁間の権力関係がデザインの実装を阻む構造が行政には存在する。 MindLabとPolicy Labの運命の分岐——デンマークは閉鎖し、英国は継続——が示すのは、デザイン組織の「技術力」ではなく「政策的な位置づけ」の違いだった。公共部門デザイン組織の興亡事例で詳細を見てほしい。 技術としてのデザイン思考は、行政の文脈でも機能する。それを機能させるための制度的・政治的条件が整っているかどうかが、実践の成否を分かつ。ツールが正しくても、組織が変わる意志を持てなければ、調査結果は引き出しの中で眠る。 --- 参考文献・出典 - UK Government Digital Service. (2013). Government Design Principles. GOV.UK. https://www.gov.uk/guidance/government-design-principles - UK Government Digital Service. (2012). Government Digital Strategy. HM Government. - デジタル庁. (2022). デジタル社会の実現に向けた重点計画. https://www.digital.go.jp/resources/govdoc/ - Forum Virium Helsinki. Smart Kalasatama and Urban Services. https://forumvirium.fi/en/ - Brown, T., & Wyatt, J. (2010). Design Thinking for Social Innovation. Stanford Social Innovation Review, Winter 2010. - Bason, C. (2010). Leading Public Sector Innovation: Co-creating for a Better Society. Policy Press. - Terrett, B. (2018). The myth and reality of government digital transformation. Public Digital Blog. --- 関連記事 - 公共部門デザイン思考の組織モデル——18F閉鎖・MindLab閉鎖・Policy Lab継続から学ぶこと - 問題定義フェーズ——HMW問いで課題を再構成する - 共感フェーズ——観察とインタビューで利用者の実態を把握する - サービスデザイン vs デザイン思考——何が違い、どう使い分けるか - ダブルダイヤモンド——デザイン思考の4フェーズ構造 --- ### デザイン思考 社会起業家・ソーシャルエンタープライズへの実践適用 URL: https://designthinking.studio/articles/design-thinking-social-enterprise-impact/ > ソーシャルエンタープライズにデザイン思考を適用する方法を解説。社会課題の複雑性に対応するユーザーリサーチ、インパクト測定への統合、ステークホルダー横断のワークショップ設計まで実践的に紹介します。 「ユーザーインタビューをしようとしたら、支援対象者が『自分たちの話を聞いてどうするのか』と問い返してきた。」 社会起業家のワークショップでしばしば耳にする場面です。ビジネスの文脈でユーザーリサーチを学んだ人が、社会課題の現場に入ったとき、最初にぶつかる壁がここにあります。デザイン思考は強力なツールですが、ソーシャルエンタープライズの文脈では、そのままの適用では機能しない場面が少なくありません。 本記事では、社会起業・ソーシャルエンタープライズの特性を踏まえた上で、デザイン思考をどう調整・適用するかを具体的に解説します。 --- ソーシャルエンタープライズとデザイン思考の相性——何が違うのか 商業的なビジネスにデザイン思考を適用する場合、「ユーザー」は主に顧客であり、問題は「顧客が対価を払って解決したい課題」として比較的明確に設定できます。 一方、ソーシャルエンタープライズでは「ユーザー」「顧客」「受益者」「寄付者」「コミュニティ」という複数のステークホルダーが存在し、それぞれの利害が一致しないことがあります。ホームレス支援の団体であれば、支援を受ける当事者・ボランティア・行政・寄付企業・地域住民がそれぞれ異なる「成功の定義」を持ちます。 また、社会課題はいわゆる「ウィケッド・プロブレム（Wicked Problems）」——問題の定義自体が難しく、解決策が新たな問題を生む複雑系——の典型です。「問いを正しく立てる」ことがデザイン思考の核心であり、ソーシャルエンタープライズにこそ最も必要なスキルでもあります。 --- 適用の3つの調整点 調整点1：共感フェーズを「権力関係の非対称性」を意識して設計する 従来のユーザーインタビューは、インタビュアーが問いを立て、インタビュイーが答えるという構造です。しかし社会課題の当事者は、支援する側・される側という非対称な権力関係の中にいます。 「話を聞かれて何かいいことがあるのか」「また調査されるだけで何も変わらない」——この不信感は正当です。過去に何度も調査対象にされながら変化を経験してこなかった人たちにとって、インタビューへの懐疑は合理的な反応です。 共感フェーズを機能させるための調整は、「共に活動する」ことを前提に設計することです。 単なる聞き取りではなく、当事者がファシリテーターとして参加する「共同設計ワークショップ」や、支援者が当事者の日常を体験する「シャドウイング」が有効です。 具体的には、最初のワークショップで当事者自身に「自分たちの課題を付箋で書いてもらう」ところから始めます。問いを外部の専門家が持ち込むのではなく、当事者が問いを立てる主体になる設計です。 調整点2：問題定義に「インパクト指標」を組み込む ソーシャルエンタープライズのPoint of Viewステートメントには、インパクト測定の視点を初期段階から組み込む必要があります。 「ホームレス状態の人が安定した住居を持てるようにする」という問いに対して、「安定した住居」の定義は何か。3ヶ月継続すれば安定なのか、1年なのか。住居の確保が本当に求めている変化の核心なのか——指標の設計は解決策の選択に先立って行う必要があります。 実際のワークショップでは、「もし私たちの取り組みが5年後に成功していたら、当事者の生活はどう変わっているか」を具体的に描くセッションを問題定義フェーズに組み込みます。この「未来の姿の描写」が、測定可能なアウトカム指標の設計につながります。 調整点3：プロトタイプを「コミュニティとの共同実験」として設計する ソーシャルエンタープライズでのプロトタイプは、製品やサービスの試作にとどまりません。コミュニティとの関係性のプロトタイプが中心になります。 「週1回の居場所づくりイベント」を3回試してみる。「個別相談ではなく、当事者同士のピアサポートグループ」を小規模に実験してみる。このような「関係性・場のプロトタイプ」は、ビジネス文脈のプロトタイピングとは異なる倫理的配慮が必要です。 特に重要なのは「実験を終了するとき」の設計を事前に行うこと。商業的なプロトタイプは失敗したら撤退すればよいですが、支援を受けていた当事者にとって「突然サービスが終わる」ことは深刻な影響を与えます。出口設計と引き継ぎのプロセスをプロトタイプの設計に含めることが、ソーシャルエンタープライズ文脈での倫理的実践です。 --- ステークホルダー横断ワークショップの設計 ソーシャルエンタープライズのデザイン思考ワークショップで最も設計が難しいのは、利害の異なる複数のステークホルダーを一同に集めるセッションです。 ある障がい者就労支援の組織でのワークショップを例に取ります。当事者・支援員・企業採用担当・行政担当者・家族が同席するセッションは、発言力の非対称性が最初の壁になります。 この壁を越えるために有効な設計が「役割カード」です。参加者全員が付箋に「自分が最も大切にしていること」を書き、役職・立場ではなく「大切にしていること」を起点に対話を始めます。採用担当者の「継続的な就労環境」と当事者の「自分が選んだ仕事をしたい」は、最初は矛盾して見えますが、対話の中で「本人の希望と能力のマッチングを丁寧にすること」という共通の方向性が見えてきます。 200回以上のワークショップを通じて観察されるのは、「最初に立場の違いを前提にするとゴールに到達しやすい」ということです。 対立を解消しようとするのではなく、対立を可視化した上で「それでも一緒にできることはあるか」を問います。 --- インパクト測定とデザイン思考の統合 ソーシャルエンタープライズの課題のひとつに「成果の見えにくさ」があります。社会的インパクトは長期にわたって発現し、直接的な因果関係が見えにくい。デザイン思考のテストフェーズは、この「インパクト測定の設計」と直接接続できます。 テストフェーズでは「何が成功か」を事前に定義し、仮説検証を行います。この構造をSROI（社会的投資収益率）やLogic Modelの設計に援用します。具体的には、テストカードの「成功の指標」欄にアウトカム指標を記入し、短期・中期・長期のインパクトを区別して管理します。 この統合によって、ドナー・寄付企業へのレポーティングと、現場の改善サイクルが同じフレームで運用できるようになります。 --- まとめ ソーシャルエンタープライズへのデザイン思考適用は、ツールをそのまま移植するのではなく、3つの調整（権力関係への配慮・インパクト指標の早期組み込み・コミュニティとの共同実験設計）を前提に設計することが重要です。 複雑な社会課題に向き合うとき、「正解」は外部の専門家が持ち込むのではなく、当事者と共に問いを立てることで初めて見えてきます。それがデザイン思考の最も根本的な価値であり、ソーシャルエンタープライズの文脈でこそ、その真価が問われます。 ウィケッド・プロブレムの詳細な解説はウィケッド・プロブレムとデザイン思考を、NGO・非営利組織での問題定義実践は非営利組織の問題定義ワークショップを参照してください。 --- ### デザイン思考 情報セキュリティ｜なぜ社員はルールを守らないのか——「使われないセキュリティ対策」を防ぐ設計思考 URL: https://designthinking.studio/articles/design-thinking-security-behavior/ > 多要素認証やパスワードポリシーが現場で付箋・私物端末・シャドーITに置き換わる現象を、デザイン思考の共感フェーズの欠落として読み解く。業務動線の同行観察とSecure by Defaultの考え方で、罰則ではなく設計によって『守られるセキュリティ対策』を作る手順を解説する。 モニターの縁に貼られた付箋には、複雑な要件を満たすはずのパスワードが几帳面な字で書かれている。誰もいなくなったフロアに空調の音だけが響く深夜、資料の提出期限が迫る中でVPN接続に手こずった社員は、結局、私物のクラウドストレージに社外秘の資料を上げてしまう。多要素認証、複雑なパスワードポリシー、厳格な承認フロー——情報システム部門が鳴り物入りで導入した対策のすぐ隣で、こうした「静かな回避」が日常的に起きている。 なぜ厳格なルールほど、現場から無視されるのか。 答えは、デザイン思考でいう共感フェーズ（Empathize）の欠落にある。罰則ではなく設計によって、対策は初めて「守られる」ものになる。 情報漏洩やランサムウェア被害の少なくない部分は、技術的な脆弱性そのものではなく、守られなかった運用ルールに起因する。監査のたびに同じ指摘が繰り返されるとすれば、それは個々の社員の油断ではなく、構造的に起きやすいパターンだと疑うべきだ。 （本稿は特定の企業への訪問取材に基づくものではなく、公開されているセキュリティ疲れ研究とSecure by Design指針をデザイン思考の枠組みで統合した分析論考である。） 「ルールを守らない現場」の正体 性弱説（罰則強化）アプローチが効かない理由 セキュリティ施策の多くは、「人は隙あらばサボる」という性弱説に立って設計されている。ルールを厳しくし、違反者を罰すれば、行動は矯正されるはずだという前提だ。 だがこの前提は、現場が抱える現実の制約を素通りしている。締切のある資料作成、複数ツールの切り替え、外出先での対応——そうした業務の流れの中で、認証の追加手順は「安全のための一手間」ではなく「仕事を終わらせるための障害物」として体感される。罰則を強化しても、障害物そのものは消えない。 セキュリティ疲れという行動経済学的な摩擦コスト 米国国立標準技術研究所（NIST）の研究者らは、この現象を「セキュリティ疲れ（security fatigue）」と呼んだ（Stanton, Theofanos, Prettyman, & Furman, 2016）。次々と課される認証・警告・ポリシー更新に対応し続けるうちに、ユーザーの注意資源が消耗し、最終的にリスクを軽視した近道を選びやすくなるという指摘だ。 これは意志の弱さの話ではなく、認知資源という有限な資源の配分の問題として捉え直せる。摩擦の多い手順を一日に何度も踏ませれば、どれほど意識の高い社員でも、いずれ近道を探し始める（筆者自身、二段階認証のコードが届くまでの数十秒にすら苛立った経験がある）。 他業界の「導入したのに使われない」失敗パターンとの共通点 似た構図は情報セキュリティに限らない。スマート農業の現場定着を扱った記事で見たように、高機能なIoTツールが畑に放置される現象も、供給側の機能設計が先行し、使い手の行動観察が後回しになるという同じ骨格を持つ。業種が違っても、「導入した瞬間」だけを追いかけ、「使われ続けるかどうか」を測らないという失敗の型は再現される。 同じ失敗を、業種を変えて何度も見ている。 共感フェーズを「業務動線の観察」で実装する アンケート・研修アンケートでは拾えない「回避のトリガー」 「セキュリティ意識は高いですか」と尋ねれば、多くの社員は「高いと思います」と答えるだろう。だがアンケートは、本人が自覚し、言葉にできる範囲の情報しか拾えない。 締切直前にどのツールを開き、どの手順を省略しがちか——こうした回避の引き金は、当人にとって当たり前すぎて、質問されても言語化されにくい。回避行動の発生地点こそが設計の出発点であるはずなのに、アンケートの外側に置き去りにされやすい。 締切直前・外出先・複数ツール切り替え時に集中する摩擦ポイント デザイン思考の共感フェーズは、本来こうした暗黙の判断を拾うための工程だ。研修アンケートの代わりに、セキュリティ担当者が対象業務に半日同行し、資料作成から提出までの一連の動きを実際に見ることで、どの瞬間に回避行動が発生しているかが具体的に見えてくる。 観察すると、摩擦は業務全体に均等に分布しているわけではないことが分かる。締切直前、外出先での接続、複数ツールを行き来する切り替えの瞬間——摩擦はいくつかの局面に集中する傾向があり、そこを起点に設計を組み直せば、効果は局所的な改善に留まらない。 シャドーITを「懲罰対象」ではなく「設計インサイト」として読み替える視点転換 私物端末や未承認のクラウドサービスへの回避——いわゆるシャドーITが発覚したとき、多くの組織はまず懲罰の対象として扱う。だがこの発覚は、本来の動線に何が欠けているかを教えてくれる貴重な信号でもある。 回避行動が起きた地点を「設計上の失敗シグナル」として記録し、そこにプロトタイプを当てて検証するサイクルに転換すれば、同じ回避は繰り返されにくくなる——もっとも、この転換を現場に納得させるまでには、それなりの根気がいる。罰則を強化するより、回避の発生地点を潰していくほうが、結果的に統制の実効性は高まる。 「守られる」対策の作り方 Secure by Default——安全を「追加の手順」から「既定の動線」へ 米国CISAが提唱する「Secure by Design」の考え方の中核にあるのが、Secure by Default——安全な状態を、利用者が追加の手順を踏まなくても初期設定として得られる状態にするという原則だ（CISA, NSA, FBI, 2023）。 セキュリティ担当者にできることは、既存の作業動線にセキュアな選択肢を統合することだ。シングルサインオンで認証の摩擦自体を減らす。承認フローを、普段使っているチャットツールに統合する。新しい画面や新しい習慣を課すのではなく、すでにある動線の中に安全を組み込む——発想の軸はそこにある。 承認フロー・認証手順を既存の業務ツールに統合するプロトタイピング 大規模な刷新をいきなり全社展開する必要はない。一部門・一業務に絞って、既存ツールへの統合を小さく試し、摩擦がどれだけ減ったかを見てから対象を広げる。 この進め方は失敗のコストを小さく抑えながら、部門ごとの業務慣習の違いにも対応できる。共感フェーズで見えてきた摩擦ポイントに狙いを絞ってプロトタイプを当てるからこそ、限られた工数でも効果が出やすい。 定着を測る指標を「研修受講率」から「回避行動の発生頻度」に変える 最後に見直すべきは成果指標そのものだ。研修受講率やポリシーの周知率は、施策の立ち上げ段階では追いやすい数字だが、現場での実効性を測る指標としては不十分である。 シャドーITの検知件数、私物端末の利用申請数といった回避行動の発生頻度を主要な指標に据え直すことで、初めて「守られる対策」を作る動機がチーム全体に共有される。 付箋に書かれたパスワードは、社員の規律の欠如ではなく、観察の不足を映す鏡だ。共感フェーズを飛ばして規則を積み上げても、現場には定着しない。 あなたのチームが最後に、ルールを破った社員の一日に実際に同行したのはいつだろうか。次のセキュリティ施策の見直しの一歩目は、改定案を書き始める前に、その問いに答えることから始まる。 参考文献・出典 - Stanton, B., Theofanos, M. F., Prettyman, S. S., & Furman, S. (2016). Security Fatigue. IT Professional, 18(5), 26-32. - Cybersecurity and Infrastructure Security Agency (CISA), National Security Agency (NSA), Federal Bureau of Investigation (FBI), et al. (2023). Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software. 関連記事 - なぜ最新のAI農業ツールは畑に放置されるのか——デザイン思考が教える現場定着の設計 - 共感フェーズ——なぜ「型通りにやった」のに機能しないのか --- ### デザイン思考 組織変革の完全ガイド【2026年版】——ワークショップで終わらせない3年ロードマップ URL: https://designthinking.studio/articles/design-thinking-org-adoption-guide/ > デザイン思考 組織変革を実現するために必ずぶつかる失敗パターン3つを解剖し、ワークショップで終わらせない3フェーズ・3年ロードマップを提示する。経営層コミットの引き出し方から文化定着まで、実践的な変革設計の全ステップを解説。 「デザイン思考のワークショップを年に3回やっています」という組織の話を聞くたびに、同じ問いが浮かびます。「ワークショップで生まれたアイデアは、その後どうなりましたか？」 答えは大抵、同じパターンです。「素晴らしいアイデアが出たが、翌週から通常業務に戻って、誰もフォローしなかった」。 デザイン思考の組織定着に失敗する理由は、手法の問題ではなく、組織の変革設計の問題です。本記事では、デザイン思考が組織に根付くまでの3年間のロードマップを、実践的な視点から設計します。 このページは「デザイン思考 × 組織変革」の全体像をまとめた総論です。個別のテーマは次の3本に分けて詳しく書いています。 - 組織変革の進め方（5ステップ） — 何から着手し、どの順で回すか - 組織導入の失敗事例5選 — 実際に何が起きたか、どこで折れたか - 管理職がリーダーシップをどう変えるか — 変革を主導する側の思考転換 --- なぜ「ワークショップだけ」では定着しないのか 組織行動学の観点から整理すると、ワークショップ型の研修が組織の行動変容につながらない理由は明確です。 日常業務との断絶。 ワークショップは「特別な場」として設計されます。付箋・ファシリテーター・広い会議室・特別な時間。このシンボル的な設定が「普段の仕事とは別のモード」という認識を強化します。ワークショップが終わった瞬間、人は「普段のモード」に戻ります。 評価・報酬制度との不整合。 多くの組織では、デザイン思考的な行動（ユーザーインタビューに時間を使う・失敗を歓迎する・プロトタイプを作って捨てる）は評価されません。むしろ「時間のムダ」「失敗」として否定的に評価されることがあります。評価制度が変わらない限り、行動変容は続きません。 「誰がやるのか」の不明確さ。 ワークショップで「私たちの組織は顧客起点で動くべきだ」という合意ができても、月曜日に「顧客インタビューを実施する担当者」「その結果を製品設計にフィードバックする担当者」「インサイトを経営判断につなぐ担当者」が決まっていなければ、何も変わりません。 --- 定着のモデル：3つのレベルの変革 デザイン思考の組織定着は、3つのレベルの同時変革として設計する必要があります。 Level 1：スキルの変革（個人レベル） 個人がデザイン思考の手法を習得し、日常業務に応用できるようになる。 Level 2：プロセスの変革（チームレベル） チームの意思決定・問題解決プロセスにデザイン思考の手法が組み込まれる。 Level 3：文化の変革（組織レベル） 「ユーザー起点で考える」「失敗から学ぶ」「プロトタイプで検証する」という価値観が、組織の暗黙のルールになる。 多くの組織がLevel 1のスキル研修だけを実施して「デザイン思考を導入した」と考えます。Level 2・3の変革なしには、スキルは職場に持ち帰られても使われません。 --- 3年間のロードマップ 第1フェーズ（0〜6ヶ月）：小さな成功体験を作る 最初の半年は「デザイン思考が機能することを、組織に見せる」フェーズです。 推薦：パイロットプロジェクトの設計 規模は小さく、意思決定権限が集中した1〜2人のリーダーがいるプロジェクトを選ぶ。「組織の変革」ではなく「1つの問題の解決」に集中します。対象の問題は「成果が6ヶ月以内に見える」「失敗しても組織に大きなダメージがない」という条件で選定します。 チームの構成 理想的なパイロットチームは5〜8名で構成します。デザイン思考の経験者（外部ファシリテーターでも可）を1名含め、残りは問題領域の当事者（業務担当者・顧客接点担当者）を含めます。 「勝ち筋」を最初に設計する パイロットプロジェクトで何をもって「成功」と定義するかを、開始前に明示します。「3ヶ月後に顧客満足度が10%向上する」「受付処理時間が15分短縮される」など、測定可能な指標を設定します。この指標が、後に組織内でのデザイン思考の価値証明になります。 実際にやってみると、パイロットプロジェクトで最も重要なのは「成功した事例を組織内でどう可視化するか」の設計です。成果が出ても、それが広まらなければ次のフェーズに進めません。 第2フェーズ（6〜18ヶ月）：仕組みへの組み込み 第1フェーズの成功体験を元に、デザイン思考を業務プロセスに組み込みます。 プロセスへの統合の具体例 - 新規プロジェクト開始時に「ユーザーリサーチの実施」を必須ステップとして定義する - 製品仕様書のテンプレートに「ユーザーインタビューからのインサイト」セクションを追加する - 月次レビューに「ユーザーフィードバック共有」のアジェンダを固定で設ける - アイデア承認のプロセスに「プロトタイプ検証」ステップを追加する 人材の育成と役割の設計 組織内に「デザイン思考の実践者」を育成する必要があります。全員を深く訓練するのはコスト的に難しい。現実的な設計として「デザイン思考の深い実践者（各部門1〜2名）」「デザイン思考を理解して協力できる人（各部門10〜20%）」「デザイン思考の存在を知って妨害しない人（全員）」という3層構造を目指します。 評価制度の見直し（これが最重要） デザイン思考的な行動が評価に繋がらなければ、定着は進みません。少なくとも評価項目に「ユーザー視点での提案・発言」「実験と学習の実施」「チーム横断的な協力」を含める必要があります。 参加者からの声として「評価制度を変えないと定着は無理だと3年間訴え続けた」という実務担当者の言葉は、多くの組織で共通しています。 第3フェーズ（18〜36ヶ月）：文化への浸透 3年目は「デザイン思考が組織の空気になる」フェーズです。外部ファシリテーターへの依存を減らし、組織内の実践者が主導できるようになっているのが理想の状態です。 文化の変革の兆候 - 「これ、ユーザーに確認しましたか？」という問いが、会議で自然に出るようになる - プロジェクト開始時に「まずプロトタイプを作ってみよう」という提案が、上司から出るようになる - 失敗したプロジェクトの「学んだこと共有」が、罰ではなく貢献として扱われるようになる これらの兆候は「測定しにくい」ですが、実際にやってみると確実に観察できます。定期的に「ウォーキング・ザ・コリドー（廊下を歩いてランダムに会話する）」をすると、組織の空気の変化が肌で分かります。 --- 失敗パターンと対策 パターン1：経営層のサポートが形式的 経営層が「デザイン思考をやれ」とトップダウンで指示し、その後は現場任せにするケース。デザイン思考は時間と実験の許容が必要ですが、経営層が「なぜ成果が出ていないのか」と短期的な成果を求めると、現場は萎縮します。対策：経営層が「学習と実験の時間を保護する」という明示的なコミットメントをすること。 パターン2：デザイン思考チームの孤立 「デザイン思考専門チーム」を作り、そのチームだけが実践するケース。組織の残りの部分は変わらないため、専門チームが生んだアイデアは実装されない。対策：デザイン思考のスキルを全部門に分散させ、専門チームはサポート役に徹する。 パターン3：手法の形式化 「今週は共感フェーズなので、全員インタビューしてください」という手法ありきの実施。形式は整うが、インサイトの質が低い。対策：手法の実施よりも「何を学ぶためにやるのか」の問いを先に立てる。 --- 定着の成功を測る指標 | 指標 | 測定方法 | 目標値（3年後） | |---|---|---| | ユーザーリサーチの実施率 | 新規プロジェクトのうちリサーチを実施した割合 | 80%以上 | | プロトタイプ検証の実施率 | 本開発前にプロトを作ったプロジェクトの割合 | 70%以上 | | デザイン思考実践者数 | 社内認定・育成プログラム修了者数 | 全従業員の10%以上 | | 従業員の顧客接点理解度 | 年次従業員調査の設問 | スコア向上 | --- 関連記事 - ユーザビリティテスト計画の立て方：5ステップ完全ガイド — 変革プロセスで必須となる検証フェーズの設計方法 - デジタルホワイトボードツール比較：Miro・FigJam・Mural デザイン思考での選び方 — 組織変革ワークショップを支えるツール選定の実践ガイド - AI時代に人間の創造性はどこへ向かうのか — 組織変革を推進する創造性の本質 --- 参考文献 - Liedtka, Jeanne, "Why Design Thinking Works", Harvard Business Review, September–October 2018 - Kotter, John P., Leading Change, Harvard Business School Press, 1996（変革のプロセスの古典） - IDEO U, Building Creative Organizations（オンラインコース） - Martin, Roger L., The Design of Business, Harvard Business Press, 2009 - Gothelf, Jeff & Seiden, Josh, Lean UX: Applying Lean Principles to Improve User Experience, O'Reilly Media, 2013 --- ### デザイン思考 非営利組織の問題定義ワークショップ｜NGO・NPOが陥る「使命の罠」と突破口 URL: https://designthinking.studio/articles/design-thinking-ngo-problem-definition/ > デザイン思考の問題定義フェーズを非営利組織・NGO・NPOに適用する実践ガイド。「使命の罠」「受益者不在の問題定義」「ドナー優先バイアス」という3つの構造的歪みを診断し、How Might Weで問いを再設定するワークショップ設計を解説する。 「使命感があれば問題定義はできている」——非営利組織のワークショップで最初にぶつかる思い込みが、これです。 創設の理念が明確なほど「解くべき問題はわかっている」という前提が強くなる。 しかし実際にやってみると、使命文に書かれた言葉と、受益者が実際に困っている問題の間には、驚くほど大きな溝があることが多い。使命に忠実であることと、問題を正確に定義することは、別の作業です。 デザイン思考の問題定義フェーズをNGO・NPOに適用するとき、企業とは異なる構造的な歪みが必ず登場します。本記事では、その3つのパターンを解剖し、現場で使えるワークショップ設計を提示します。 --- なぜ非営利組織で「問題定義」が難しいのか 「正しい問い」を立てることへの抵抗感 非営利組織の多くは、強烈な動機から生まれます。難民支援・貧困撲滅・環境保護・障害者自立——いずれも、解決すべき問題は明らかに見えます。この「明らかさ」が、逆に問題定義の精度を下げます。 「問題は決まっている、だから解決策を考えよう」というジャンプが起きる。 しかしデザイン思考が最も強調するのは「正しい問いを立てることこそが最も難しく、最も重要な作業だ」という認識です。難しい問題ほど、「なぜこの問題が起きているのか」の解像度を上げる前に解決策に飛びつく罠があります。 受益者とドナーの二重構造 企業には顧客という単一の「問題を持つ人」がいます。非営利組織には受益者（サービスを受ける人）とドナー（資金を提供する人）という二重の「関係者」が存在します。 この二重構造が問題定義を歪めます。ドナーが「見えやすい成果」を求めるプレッシャーがあるとき、組織は受益者の本質的な問題より「ドナーに報告しやすい問題」を優先的に定義してしまう。参加者からの声として頻繁に出てくるのは「支援者への報告書に書ける数値が、現場の実感とズレている」という葛藤です。 「使命の罠」——正しい理念が正確な問題定義を妨げる 非営利組織固有の現象として、使命文が問題定義の視野を狭める「使命の罠」があります。たとえば「子どもの貧困をなくす」という使命を持つ団体が、インタビューで出てきた「子どもが学校に来ない」という現象を、自動的に「経済的困難が原因」と定義するケースです。 実際に調査を掘り下げると、「親が学校に送り出せる心理的・時間的余裕がない」という別の問題が主因だったということがある。 使命文の言葉が、観察から見えてきた別の構造を「見えないもの」にしてしまう。使命への誠実さが、問題定義の精度を下げるというパラドクスです。 --- 3つの構造的歪みの診断 歪み1：受益者不在の問題定義 非営利組織のプログラム設計が、受益者へのリサーチなしに進むことは珍しくありません。専門家・行政担当者・ドナー担当者が集まって「この地域の問題は○○だ」と定義し、プログラムを設計する。受益者当事者の声は、その後の実施段階で初めて聞かれます。 ワークショップでよく起こるのは、「受益者の声を聞いた」という認識が、実は「支援者から見た受益者像のインタビュー」に留まっているケースです。 支援者が「受益者はこう困っている」と語る内容と、受益者本人が語る内容は、しばしば異なります。 この歪みを診断するチェックリスト： - 問題定義の会議室に、受益者本人が参加しているか - 問題定義の根拠となるデータは、誰が収集し、誰の観点から解釈しているか - 受益者へのインタビューで「あなたが一番困っていること」を直接聞いたことがあるか 歪み2：ドナー優先バイアス ファンディングの言語が現場の問題定義に浸透する現象です。助成金の申請要件が「就労支援プログラムの実施」であれば、組織は現場で見えている「就労への心理的障壁」より「就労スキルの不足」を問題として定義しやすくなります。 「予算がつく問題」と「本当に解くべき問題」が乖離するとき、支援は届いているが変化が起きないという状況が生まれます。 この歪みを可視化するワーク：問題定義ステートメントを書いた後、「この問題定義は、ドナーへの報告書にそのまま使えるか」を問う。「はい」と即答できるとき、ドナーバイアスが混入している可能性が高い。ドナーに報告しにくい問題こそ、本質的な問題かもしれません。 歪み3：「解決策から遡った」問題定義 既存プログラムが先にあり、その正当化として問題定義が後付けされるパターンです。「3年間実施してきた食料支援プログラムがある。だから問題は食料へのアクセス不足だ」という順序の逆転です。 プログラムを廃止・変更することへの内部抵抗が、問題定義を固定化させます。 実際にやってみると、このパターンは最も発見しにくい。「うちは常に受益者のニーズを見ている」と自認する組織でも、既存プログラムを守るための無意識な問題定義の歪みが起きています。 発見のヒント：チームに「もし既存プログラムが存在しなかったとしたら、同じ問題定義をするか」を問う。答えが「分からない」なら、既存プログラムが問題定義を歪めている可能性があります。 --- 問題定義ワークショップの設計 ステップ1：使命文の「括弧入れ」（30分） ワークショップの冒頭で、使命文を一時的に「括弧に入れる」作業を行います。参加者に使命文を書き出させ、その後「今日のワークショップでは、使命文に書かれていない言葉だけを使って問題を語ってみましょう」と指示します。 この制約が、使命文の言葉への依存を意識させ、観察に立ち返るきっかけになります。 使命文の言語から離れると、現場のエピソードが出てきやすくなる。「ある受益者が言っていた言葉」「フィールドで何度も見かけた行動」が、制約を設けることで流暢に語られ始めます。 ステップ2：受益者エピソードの収集（60分） チームメンバー全員が、受益者との実際のやり取り・観察した場面をA4用紙1枚に書き出します。解釈や分析ではなく、「誰が・いつ・どこで・何をしていたか・何を言ったか」の事実のみを記録するよう指示します。 ポイントは「なぜ」という解釈を、この段階では書かせないことです。 「なぜ」を考え始めると、既存の理解フレームが事実の記述に滑り込んでくる。まず事実を集め、そこから解釈を構築するという順序を守ることが、受益者不在バイアスを防ぐ最初の手段です。 全員のエピソードを壁に貼り出し、沈黙で30分間読み合わせます。声に出して議論するのではなく、「同じパターンを感じる場所に付箋を貼る」という非言語のアフィニティマッピングが有効です。 ステップ3：「驚き」の抽出（30分） 貼り出されたエピソードから、チームの予測・使命文の言語・既存プログラムの設計思想と「ズレていた」ものを選び出します。「驚いた」「想定と違った」エピソードこそが、問題定義の精度を上げる素材です。 選んだエピソードについて、「なぜこれが起きているのか」を3段階で掘り下げます。最初の「なぜ」は表面的な理由、2番目の「なぜ」は組織・制度的な要因、3番目の「なぜ」は文化・価値観・信念の層に届くことが多い。この3層構造の探索が、使命の罠を突破するための核心です。 ステップ4：POV文のドラフト（45分） d.schoolが定式化したPOV文（Point of View Statement）のフォーマットを使って問題定義を言語化します。 非営利組織のワークショップでは、このフォーマットの「ユーザー」を「受益者」に、「ニーズ」を「受益者が語った言葉に最も近いもの」に置き換えることを明示的に指示します。 支援者の視点から見た「あるべきニーズ」ではなく、受益者の言葉から引き出したニーズを選ぶことが重要です。 複数のPOV文を並べ、「これはドナーへの報告書で使いやすいか」「これは使命文の言語に近いか」という2つの問いで評価します。両方「はい」のPOV文は、バイアスを含む可能性があります。「どちらも違う」と感じるPOV文が、最も本質的な問題定義に近いことが多い。 ステップ5：How Might We（HMW）の生成（30分） POV文から、How Might We（どうすれば私たちは〜できるか）の問いを生成します。HMWは問題を「チームで解決できる挑戦」に変換する言語的な操作です。 非営利組織のHMW設計で気をつけるのは、問いが組織のリソース・権限・既存プログラムに引きずられないようにすることです。 「どうすれば私たちの予算内で〜」「どうすれば現在のスタッフで〜」という制約が最初から入ると、問いの幅が狭くなります。制約を外した「理想のHMW」を先に生成し、そこから現実的な制約を段階的に加えるという順序が有効です。 --- 実践のポイント：ファシリテーターが抑えるべき5つの場面 場面1：「使命文を読み上げる参加者」への対応 ワークショップ中に「でも私たちの使命は○○なので」という発言が出たとき、それを否定せず「その使命に照らしたとき、今日集めたエピソードの中で最も使命から遠い場面はどれですか」と問い直す。使命文を「正解」ではなく「問い返しの道具」として使います。 場面2：「受益者はこういう人たちだ」という決めつけ 「受益者は○○なので」という発言が出たとき、「その理解は誰のどのような観察から来ていますか」を問う。「決めつけ」は、受益者についての豊かな観察から来ていることもあれば、支援者の先入観から来ていることもあります。 根拠を問うことで、どちらかが可視化されます。 場面3：解決策への早期ジャンプ 「この問題には○○が有効だと思います」という発言が出たとき、「それは素晴らしいアイデアです。一度どこかに書き留めておいて、今は問題の定義に戻りましょう」と受け流す。解決策のアイデアを完全に否定しないことが参加者の心理安全を保ちつつ、プロセスを守るコツです。 場面4：「すでに調査している」という抵抗 「アンケートで1000件のデータを取っている」「毎週レポートを集計している」という発言への対応です。データの存在を認めた上で「そのデータは受益者の言葉で記録されていますか、それとも私たちの分析カテゴリで集計されていますか」と問う。量的データと受益者の生の言語は別物です。 両方必要であることを説明します。 場面5：ドナーへの配慮が問題定義に入り込む 「でもこれを書いたら助成金が取れない」という発言は、ドナーバイアスが表面化した瞬間です。これを責めず「今日は問題を正確に把握する作業をしています。ドナーとのコミュニケーションは、正確に問題がわかってから設計しましょう」とリダイレクトします。正確な問題定義がある方が、長期的にはドナーとの関係も深まるという実態を説明することも有効です。 --- ワークショップ設計の全体像 | フェーズ | 時間 | 手法 | 目的 | |---|---|---|---| | オープニング | 15分 | 使命文の括弧入れ | 前提をいったん外す | | エピソード収集 | 60分 | カード記述 + アフィニティ | 受益者の事実を集める | | 驚きの抽出 | 30分 | ドット投票 + 3段のなぜ | 使命の罠を診断する | | POV文ドラフト | 45分 | POV文フォーマット | 問題定義を言語化する | | HMW生成 | 30分 | ブレインライティング | 問いを挑戦に変換する | | クロージング | 15分 | 振り返りカード | 次の調査ステップを設計する | | 合計 | 195分（3時間15分） | | | 参加者の最適構成 ファシリテーター1名と参加者5〜8名が理想的な規模です。必ず受益者当事者または受益者と直接接する現場スタッフを1〜2名含めること。プログラム設計者・経営層・ファンドレイザーが参加する場合、受益者視点を持つ参加者が少数になりすぎないよう構成を調整します。 参加者からの声として多いのは「受益者に来てもらうのは難しい」という点です。 代替策として、受益者が実際に話した言葉を録音・書き起こしたものを持ち込む「代理声」の手法があります。受益者本人の参加よりは情報量が減りますが、支援者の解釈が入っていない言葉を参照できる点で有効です。 --- 問題定義の品質を上げる4つの基準 基準1：受益者の言語で書かれているか POV文に含まれる「ニーズ」の記述が、受益者がインタビューや観察で実際に使った言語に近いかを確認します。「支援者の分析言語」（「セルフエフィカシーの低下」「社会関係資本の不足」）ではなく「受益者の生きた言語」（「どうせ自分には無理だと思っている」「頼れる人が周りにいない」）で書かれているかが判断基準です。 基準2：「なぜそうなっているか」の仮説があるか 問題の定義に留まらず、「なぜその問題が起きているか」の初期仮説を含んでいるかを確認します。インサイトのないPOV文は、次のイデエートフェーズで発散しにくくなります。 「なぜなら○○だから」の部分が、チームが一番時間をかけるべき箇所です。 基準3：解決策に依存していないか 問題定義の文章が、暗黙的に特定の解決策を前提にしていないかを確認します。「○○プログラムを受けられる環境がない」という問題定義は、既存プログラムへのバイアスが入っています。「○○が十分に得られていない」という形に変換することで、解決策への依存を取り除けます。 基準4：チームの複数メンバーが「腑に落ちる」か 技術的な正確さより、「これは確かにそういうことが起きている」というチームの共感が重要です。問題定義は、事実からの論理的な導出である同時に、チームの共同理解の結晶です。 チームの誰かが「これは実感と違う」と感じるなら、再度エピソードに戻って検討する余地があります。 --- よくある失敗パターンと対処法 失敗1：3時間かけて「使命文の言い換え」しか出ない これは使命の罠が最も強く作用しているケースです。ワークショップの冒頭に「今日の目的は使命文を検証することではなく、使命文の正しさを疑ってみることです」と明示的に宣言することで、心理的な安全を先に確保します。 失敗2：受益者インタビューのデータがない状態で実施する 問題定義ワークショップは、受益者への一次調査の後に実施するのが原則です。調査なしで実施すると、参加者の「受益者についての思い込み」を整理するだけになります。最低でも受益者5〜8人へのインタビューを事前に完了させることを前提条件にすることを推奨します。 失敗3：POV文が複数できて絞り込めない 3〜5個のPOV文候補が残ったとき、「どれが正しいか」ではなく「どれを先に探索するか」という問いに変換します。問題の定義は1つに絞らなければならないルールはありません。複数の問題定義を持ったままイデエートに進み、それぞれの問題定義に対するHMWを並行して展開する方法も有効です。 失敗4：チームの中で問題定義に合意できない 合意できないこと自体が重要なデータです。「なぜ同じ情報を見て、異なる問題定義に至るのか」を問うことで、チームメンバーが持っているメンタルモデルの差異が可視化されます。この差異は、受益者と接する場面での認識の差異でもある可能性が高い。問題定義の合意より先に「認識の差異の地図を作る」ことに目的を切り替えます。 --- 「やってみよう」：30分から始める問題定義の自己診断 フルワークショップの前に、チームで試せる30分の自己診断を紹介します。 STEP 1（10分）： チームで現在のプログラム・活動の「問題定義」を1文で書き出す。 STEP 2（10分）： 書いた1文を読み、以下を確認する。 - 受益者の言葉が入っているか - 「なぜそうなっているか」の仮説が入っているか - 既存プログラムの言語が前提になっていないか - ドナーの要求する言語に近すぎないか STEP 3（10分）： もし上の4つのうち2つ以上に「いいえ」なら、「受益者に直接聞いたとしたら、この問題定義をどう言い直すか」を書いてみる。 この30分で出てくる違和感こそが、フルワークショップに投資する価値がある場所です。 問題定義を疑うことは、使命を否定することではありません。より正確に問題を解くための、使命への誠実な向き合い方です。 --- 関連リソース 問題定義フェーズの詳細理解には、defineフェーズの概要を参照してください。POV文の具体的な書き方はPOV文作成ガイドで詳しく解説しています。問題定義から創造フェーズへの接続についてはHow Might Weの実践手順も合わせて参照してください。受益者インタビューの設計についてはユーザーインタビューの手法が参考になります。問題定義を支える共感フェーズの全体像は共感フェーズのガイドにまとめています。組織変革としてデザイン思考を定着させる文脈では組織導入の完全ガイドも参照してください。 --- 参考文献 - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. ── デザイン思考のプロセスにおける問題定義の重要性について体系的に論じた古典的著作。 - Buchanan, R. (1992). "Wicked Problems in Design Thinking." Design Issues, 8(2), 5–21. ── デザイン思考が扱う「厄介な問題」の構造を定義した先駆的論文。非営利領域の複雑な問題定義への示唆を含む。 - Liedtka, J., & Ogilvie, T. (2011). Designing for Growth: A Design Thinking Toolkit for Managers. Columbia University Press. ── 組織の問題定義プロセスへのデザイン思考適用について実践的に論じている。 - IDEO.org (2015). The Field Guide to Human-Centered Design. IDEO. ── 非営利・社会課題領域へのデザイン思考適用に特化したガイド。受益者視点を中心に置いたフィールドワーク手法を詳述。 - Martin, R. (2009). The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business School Press. ── 問題定義の「知識のファネル」概念を提示し、アブダクティブ推論の重要性を論じる。 - Nussbaum, M. (2011). Creating Capabilities: The Human Development Approach. Harvard University Press. ── 受益者中心の問題定義の倫理的基盤として、ケイパビリティアプローチの視点を提供する。 --- ### デザイン思考×アジャイル統合モデル — ダブルダイヤモンドとスプリントの接続法 URL: https://designthinking.studio/articles/design-thinking-agile/ > 「何を作るか」を定義するデザイン思考と「どう作るか」を加速するアジャイルは対立しない。両手法を統合するフレームワークと、実際のチームでの接続点を解説する。 「デザイン思考とアジャイル、どちらを使えばいいのか」——この問いは立て方が間違っています。競合しない。異なる問いに答えるツールです。デザイン思考は「何を作るべきか」を問う。アジャイルは「どう作るか」を最適化する。 問題は、この2つが別々のチームに分断されているか、そもそもどちらかしか使われていないケースが圧倒的に多いことです。 なぜ統合が難しいのか タイムスケールの違い デザイン思考の共感フェーズでは、ユーザーリサーチ、インタビュー、観察に数週間を費やすことがあります。アジャイルのスプリントは通常2週間です。「リサーチが終わらないうちにスプリントが始まってしまう」という状況が生じます。 成果物の形式の違い デザイン思考はインサイト、POVステートメント、HMW質問といった「問いの精度を高めるための成果物」を生みます。アジャイルはユーザーストーリー、スプリントバックログ、リリース可能なプロダクトインクリメントを求めます。この成果物の形式の違いが、「デザイン思考で出た洞察をどうアジャイルのバックログに変換するか」という具体的な摩擦を生みます。 チームの構成の違い デザイン思考はしばしばUXリサーチャー、デザイナー、マーケターが主導し、アジャイルはプロダクトオーナー、スクラムマスター、開発チームが主体です。同じプロジェクトにこれらの役割が混在するとき、誰が何の権限を持ちどこで意思決定するかが曖昧になります。 統合モデルの設計 ダブルダイヤモンドの第1ダイヤモンドをアジャイルの前に置く 最もシンプルな統合パターンは、ダブルダイヤモンドの「Discover（発見）→Define（定義）」フェーズをスプリント0として位置づけることです。 このモデルの肝は、フェーズ0の「Define」の成果物が、アジャイルの「プロダクトバックログの初期版」になるという接続点です。HMW質問からユーザーストーリーを導出することで、バックログの根拠が「仮説」ではなく「ユーザーリサーチに基づく洞察」になります。 実際にやってみると、フェーズ0を経てスプリントに入ったチームは、「なぜこの機能を作るのか」という問いに全員が同じ答えを持てます。これが開発中の意思決定速度を上げ、手戻りを減らします。 継続的な発見（Continuous Discovery）との統合 単発のフェーズ0ではなく、スプリントと並行してリサーチを継続する「継続的な発見（Continuous Discovery）」という手法があります。Teresa Torres が体系化したこのアプローチでは、毎週最低1回のユーザーインタビューをルーティン化します。 ワークショップでよく起こるのは、「毎週インタビューなんて時間が取れない」という反応です。しかし実際にやってみると、週1回15分のインタビューを3ヶ月続けたチームは、プロダクト方向性の大きな転換を4回行い、そのたびに「なぜ転換するか」の根拠をユーザーの言葉で持てることに気づきます。 プロトタイプをスプリントの成果物として組み込む デザイン思考のプロトタイプフェーズは、アジャイルのスプリントと相性がよいです。スプリントの成果物を「動くソフトウェア」に限定せず、「学習を最大化するための最小限の成果物（プロトタイプを含む）」と定義することで、ペーパープロトタイプやワイヤーフレームもスプリントの正当な成果物になります。 スプリントレビューで開発済みコードではなくインタラクティブなプロトタイプをステークホルダーに見せることで、フィードバックの質が変わります。動いているように見えるものを見た人は、抽象的な要件定義書よりもはるかに具体的な意見を持ちます。 接続のための役割設計 プロダクトトライアド デザイン思考とアジャイルの統合が機能しているチームに共通するのは、「プロダクトトライアド」と呼ばれる3者の連携です。 - プロダクトマネージャー：何を作るかのビジネス判断 - UXデザイナー/リサーチャー：ユーザーリサーチとプロトタイプ - テックリード：実装可能性と技術的な実現方法 この3者が週次で同期し、バックログの優先順位付けをユーザーの声と技術制約の両方から判断するプロセスが、デザイン思考とアジャイルを橋渡しします。 デザイン思考をファシリテートするスクラムマスター 参加者からの声として多いのは、「スクラムマスターがデザイン思考のファシリテーション能力を持っていると、スプリントプランニングの質が変わる」という点です。「なぜこのユーザーストーリーを優先するか」を問い続ける姿勢が、バックログを「やることリスト」から「仮説の優先順位付け」へと変えます。 よくある失敗と対策 失敗1：デザイン思考フェーズが長くなりすぎてスプリントが始まらない 原因：共感フェーズに完璧なリサーチを求めすぎること。対策：フェーズ0の期間を最大4週間と固定し、「十分なインサイト」ではなく「最初のスプリントを始めるのに必要な最低限のインサイト」を目標にする。 失敗2：スプリントが始まったらデザイン思考の視点が消える 原因：UXリサーチャーがフェーズ0だけに関与し、開発フェーズでチームを離れること。対策：UXリサーチャーを開発チームの正式メンバーとして継続参加させる。 失敗3：プロトタイプがスプリントバックログを無視する 原因：デザイナーとエンジニアが別のリズムで動いていること。対策：プロトタイプの範囲をスプリント境界に合わせ、「このスプリントでテストするプロトタイプ」という単位で管理する。 どこから始めるか デザイン思考とアジャイルの統合を最初の一歩から始めるなら、次のスプリント0を「ユーザーリサーチ専用スプリント」として設定することから試してみてください。 全員でユーザーインタビュー3件を実施し、エンパシーマップを作り、HMW質問を5つ出す。そこから最初のスプリントバックログを作る。この経験が、「デザイン思考は開発前の別フェーズ」ではなく「開発のための視点として統合できる」という実感をチームに与えます。 --- 参考文献 - Teresa Torres, Continuous Discovery Habits, Product Talk LLC, 2021 - Jake Knapp, John Zeratsky, Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016 - Marty Cagan, Inspired: How to Create Tech Products Customers Love, Wiley, 2018（2nd ed.） - Design Council, "The Double Diamond: A Universally Accepted Depiction of the Design Process", designcouncil.org.uk, 2019 プロダクトロードマップの優先度付けにデザイン思考を組み合わせる実践についてはデザイン思考でプロダクトロードマップを優先度付けするも参照してください。 --- ### デザイン思考×スポーツビジネス：ファン体験とアスリート用品革新の実践事例 URL: https://designthinking.studio/articles/design-thinking-sports-industry-innovation/ > Nike、Golden State Warriors、Formula 1チームなどスポーツ産業の先進事例を通じて、デザイン思考がファン体験とプロダクト開発をどのように変革するかを解説する。 スポーツは感情とデータが交差するフィールドだ。観客は感動を求め、アスリートは0.1秒の更新を追いかけ、チームは勝利とビジネスの両立を模索する。この複雑な欲求構造にデザイン思考を当てはめると、スポーツビジネスは「体験設計の問題」として見え始める。 なぜスポーツ産業にデザイン思考が有効か スポーツビジネスの本質は体験の製造だ。チケットの購入から、スタジアムへの移動、入場、観戦、SNS投稿、家路——全行程がひとつのカスタマージャーニーを形成している。プロダクト（スポーツ用品）においても、アスリートが何を感じ、どこで限界を感じるかを観察しなければ、次世代の製品は生まれない。 デザイン思考はこの「体験の総体を可視化する」ことに長けている。カスタマージャーニーマップ、エンパシーマップ、プロトタイピング——これらの手法はスポーツの現場に直接適用できる。 Nike：アスリートの声から生まれたプロダクト革新 Flyknit——ニットの発想が生んだランニングシューズ革命 Nikeが2012年に発表したFlyknit技術は、ランニングシューズの構造を根本から変えた。開発の起点は、エリートランナーへの徹底したエンパシーリサーチだ。 「素足で走っているような感覚がほしい」というランナーの声を、Nikeの開発チームは何年もかけて観察・記録した。従来のシューズ製造では、複数のピース（アッパー、スウォッシュ、補強パーツ）を縫い合わせる工程が重量と剛性を生んでいた。「縫い目を消す」という発想に辿り着くまでに、チームはニット技術の専門家との共同プロトタイピングを繰り返した。 Flyknit開発のプロセスはデザイン思考の典型例だ。 - Empathize: エリートランナーのトレーニングを密着観察、足の感覚インタビューを実施 - Define: 「重量と硬さが地面からのフィードバックを殺している」という核心問題を特定 - Ideate: テキスタイル工学の知見を製靴に転用するクロスドメイン発想 - Prototype: ニット素材の試作シューズを複数バリエーションで製作 - Test: 実際のランナーにトレーニングと競技で着用してもらいデータ収集 Flyknit技術はその後、バスケットボール・サッカー・クロストレーニングなど多くの製品ラインに展開された。材料の革新は、ひとりのアスリートの声を深く聴くことから始まった。 Nike FlyEase——インクルーシブデザインが生んだ普遍的価値 Nikeのデザイン思考が最も社会的なインパクトを持った事例のひとつが、Nike FlyEaseの開発だ。 2012年、脳性麻痺のある16歳のMatthew Walzerが、Nikeに一通の手紙を書いた。「自分でシューズを履くことができるようにしてほしい」という率直な訴えだった。Nikeのデザインチームはこのフィードバックを真剣に受け止め、Walzerを共同開発者として迎えた。 開発チームが直面した問いは「どうすれば片手だけで、あるいは補助なしに靴を履けるか」だった。既存のひも・マジックテープ・ファスナーではなく、完全に新しい開閉機構が必要だった。数年間のプロトタイピングとウォルツァー自身によるテストを繰り返した末、360度開くジッパーシステムを採用したFlyEaseが生まれた。 この製品が証明したのは、障害のあるユーザーを起点に設計することで、すべてのユーザーに有用な革新が生まれるという「エクストリームユーザーテスト」の原則だ。FlyEaseは後に、脳性麻痺以外の多様な場面——両手がふさがっている医療従事者、高齢者、ランナー——でも支持を集めるプロダクトに成長した。 Golden State Warriors：スタジアム設計とファン体験 2019年にサンフランシスコのMission Bay地区にオープンしたChase Centerは、NBAのGolden State Warriorsの新本拠地として、ファン体験設計の先進事例とされている。 Chase Centerの設計チームは、ファン体験の設計に際して、試合観戦だけでなく「スタジアムに来ることの全体価値」を設計の対象とした。駐車場からの動線、コンコースの食事体験、座席からのアリーナビジュー、アプリとの連動——これらが統合されたシステムとして設計されている。 開発プロセスで重視されたのは、過去の観戦者へのインタビューと現地観察だ。「どのタイミングでストレスを感じるか」「記憶に残る体験はどこで生まれるか」というエンパシーリサーチを、スポーツ施設設計の初期段階から組み込んだ。 Chase Centerにはコンサート・イベント機能も統合されており、スポーツ観戦以外の文脈でも「Mission Bayの体験のハブ」として機能するよう設計されている。単一用途施設から多目的体験施設への転換は、ユーザーの行動観察なしに実現できない発想だ。 Formula 1：高速プロトタイピングの文化 Formula 1は、デザイン思考のプロトタイプ思考が極限まで実践されている産業だ。F1チームは毎レース週末ごとにマシンのパーツを設計・製造・テスト・投入するサイクルを回している。このプロセスは本質的に、高速イテレーションのデザイン思考だ。 McLarenのエンジニアリング文化は特によく知られている。同チームはデータ分析、空力シミュレーション、実車テストを組み合わせた高速フィードバックループを確立しており、仮説（新しいフロントウィングデザイン）→試作（CFD解析→実物製造）→テスト（実走行データ）→改善のサイクルを週単位で実行する。 レーシングドライバーは「エクストリームユーザー」だ。彼らの身体感覚からのフィードバック（「ブレーキングで鼻先が逃げる感じがする」）が設計変更の起点になる。定量データ（テレメトリー）と定性データ（ドライバーの感覚）を統合してインサイトを導く手法は、デザインリサーチと本質的に同じだ。 McLarenはF1技術から派生した素材・空力技術を医療機器、自動車、輸送機器に展開するMcLaren Appliedというビジネスも持っており、F1で磨かれたデザイン思考的なイノベーションプロセスが他産業に転用されている。 Adidas Speedfactory：製造プロセスへのデザイン思考適用 Adidasは2016年にドイツのAnsbach、続いて2017年にアトランタにSpeed Factoryと呼ばれる自動化製造施設を開設した。従来はアジアの工場での大量生産に依存していたスポーツシューズの製造を、ロボットと自動化によって先進国の消費地近くで実施するコンセプトだ。 Speed Factoryが目指したのは「ローカルの体験ニーズへの高速応答」だった。例えばニューヨーク向けには都市環境に合った耐久性と機能、ロサンゼルス向けには別の特性——そうした地域固有の需要を素早く試作・量産できる仕組みを構築しようとした。 Speed Factoryは2019年に閉鎖されたが、このプロセスで培った自動化ノウハウはその後もAdidasの製造革新に受け継がれている。製造プロセスにデザイン思考を適用し、ユーザーの地域特性に応じたカスタマイズを工業スケールで実現しようとした試みは、量産とパーソナライズの矛盾を解こうとする産業界の模索を体現している。 スポーツテックとファン体験のデータ化 近年、スポーツ産業ではファン体験のデータ化が急速に進んでいる。スマートスタジアム化（センサーによる混雑検知、アプリによる座席サービス注文）、ウェアラブルによるアスリートのバイオメトリクス計測、ゲーム内行動分析によるeスポーツ体験設計——いずれもデータを通じてユーザーを深く理解しようとするエンパシーリサーチの延長だ。 MLBは「カスタマーサクセス」の概念をスポーツビジネスに持ち込み、チケット購入者の全観戦行動データを分析して、次シーズンの来場率や年間席更新率を高めるためのパーソナライズドアウトリーチを実施している。ファンを顧客と捉え、カスタマージャーニー全体を設計する視点は、デザイン思考のサービスデザインと直接つながる。 スポーツ×インクルーシブデザインの可能性 Nike FlyEaseが示したように、スポーツ産業にとってインクルーシブデザインは社会的責任であると同時に、イノベーションの源泉でもある。 パラスポーツ向け用具の開発も、この視点で語れる。義肢ランナー用の競技用カーボンブレード（Össur社のCheetah等）は、障害のあるアスリートのエクストリームニーズに向き合ったデザインが、産業全体の素材・構造設計技術を引き上げてきた歴史を持つ。 「普通のユーザー」ではなく「最も過酷な状況のユーザー」から設計を始めることで、より多くの人に価値をもたらす製品が生まれる——スポーツ産業はこの原則の生きた実験場だ。 まとめ：スポーツビジネスをユーザー体験として設計する NikeのFlyknit・FlyEase、Chase Centerのファン体験設計、F1の高速プロトタイピング——いずれの事例も、「ユーザー（アスリートまたはファン）の体験を起点にする」という共通の姿勢から生まれている。 スポーツ産業は感情移入が得意な産業だ。選手を応援することへの共感、試合の緊張感への没入、優勝の喜びへの同化——これらの感情的体験を設計の起点とするデザイン思考は、スポーツとの親和性が高い。 「どんな体験を生み出したいか」から始め、そのためのプロダクト・空間・サービスをプロトタイピングと検証のサイクルで磨く。スポーツビジネスにおけるデザイン思考の実践は、感情と機能が最高レベルで交差する領域での、人間中心設計の最良の教科書を提供している。 --- ### デザイン思考×戦略明確性 ── 仮説型と分析型の統合 URL: https://designthinking.studio/articles/design-thinking-strategic-clarity-integration/ > デザイン思考と経営戦略は対立するものではなく、補完関係にある。仮説型思考（デザイン思考）と分析型思考（戦略）をどのように統合するのか、企業の実践事例から考える。 デザイン思考は「戦略がない」のか デザイン思考が日本の大企業に導入される際、よく聞こえてくる批判がある。 「デザイン思考は遊び。実務の現場では、明確な戦略と予算配分の根拠が必要」 「イノベーションの話は良いが、今期の売上をどう作るのか」 「ユーザー中心と言うが、市場規模の見積もりが甘すぎる」 これらの批判は、一面では正しい。デザイン思考は、対象となるユーザーの感情や行動に深く向き合うプロセスを重視するあまり、事業規模や市場構造、競争環境といった「経営視点の制約条件」を見落としやすい。 しかし、本来のデザイン思考と経営戦略は、決して対立するものではない。むしろ、統合することで初めて、ユーザーにとって価値があり、かつ事業として成立するイノベーションが生まれる。 --- 仮説型思考 vs 分析型思考 デザイン思考と戦略の関係を理解するには、思考様式の違いを認識する必要がある。 仮説型思考（デザイン思考） デザイン思考のプロセスは、小さな仮説を立て、プロトタイプで検証し、その結果から学ぶという反復を中心としている。 特徴は以下の通り。 - 速度を優先 — 完璧な情報を待たず、70%の情報で意思決定する - 失敗を学習に変換 — 「失敗は無駄」ではなく「失敗データは次の仮説の材料」 - ユーザー行動を重視 — 統計よりも、実際のユーザーの語り、観察から学ぶ - 複数の可能性を同時進行 — 一つの方向に絞るのではなく、複数のプロトタイプを並行テスト このアプローチは、不確実性が高い領域では最高に強い。「誰が買うのか分からない、が、もしかしたらこんなニーズがあるのでは?」という問いに対して、仮説検証というメカニズムで答えを見つけることができる。 分析型思考（経営戦略） 一方、経営戦略は、現状の市場データを分析し、最適な資源配分を論理的に決定するプロセスである。 特徴は以下の通り。 - 精度を優先 — 可能な限り多くのデータを集め、信頼度の高い意思決定を目指す - リスク最小化 — 過去のデータに基づき、予測可能な範囲での経営判断 - 市場構造を重視 — 顧客ニーズを理解するために、市場規模・競争構造・ポジショニングを分析 - 一貫性のある戦略 — 複数の選択肢ではなく、経営資源を一つの方向に集中 このアプローチは、既存市場での競争では極めて有効。市場ニーズが明確で、競争構造が固定化している環境では、「どこに資源を配分すれば、最大のリターンが得られるか」を的確に判断できる。 --- 二つの思考様式の対立が生じる理由 しかし、実務の現場では、この二つの思考様式が対立することがほとんどだ。なぜか。 理由 1：時間軸の違い デザイン思考は「今から2-3ヶ月で仮説を検証する」という短期サイクルで動く。一方、経営戦略は「今後3年の事業方針」という中期視点で決定される。 その結果、デザイン思考チームが「これはいけそう」と判断したアイデアが、戦略会議で「市場規模が小さい」「3年の売上計画に合わない」という理由で却下されてしまう。逆に、戦略会議が「この市場セグメントを狙う」と決定した方向性に、デザイン思考チームが「本当にそのセグメントのユーザーはこう考えているんですか?」と疑問を呈する。 理由 2：データの種類の違い デザイン思考で重視されるのは、定性的データ — ユーザーインタビューの語り、観察フィールドの描写、プロトタイプテストの反応。 経営戦略で重視されるのは、定量的データ — 市場規模、顧客獲得単価、ライフタイムバリュー、競争力指標。 両者は「どちらが正しいデータか」という言語体系が異なるため、議論が容易ではない。「ユーザーはこう言ってました」と定性データで説明しても、経営戦略側からは「それで何人のユーザーが いるんですか?」という定量的な問い直しが来る。 理由 3：不確実性の扱い方の違い デザイン思考は、不確実性を前提とする。「完璧には分からない世界で、どうやって学ぶか」という問いの中で動いている。 経営戦略は、不確実性を最小化することを目指す。「シナリオプランニング」や「リスク分析」という手法で、将来の可能性の幅を絞り込み、その中で最適な判断をしようとする。 この違いから、デザイン思考側は「失敗からの学習」を価値視するが、経営戦略側は「失敗を避けられないか」と考える。 --- 統合への第一歩：「仮説の質」を上げる では、この対立をどうやって乗り越えるのか。 最初のステップは、デザイン思考側が立てる「仮説」の質を、経営戦略の言語で再定義することだ。 デザイン思考的な仮説 従来のデザイン思考では、仮説は「〜なのではないか」という定性的なものになりやすい。 例：「シニア層は、スマートフォンの操作が難しいと感じているのではないか」 これは妥当な仮説だが、経営戦略の視点からは「では、その感覚を持つシニアは全体の何%いるのか」「その課題を解決できれば、どの程度の売上が期待できるのか」という問いが、自動的に生じる。 戦略レベルの仮説 そこで、仮説の立て方を以下のように再定義する。 「シニア層（65歳以上、ボリューム推定〇〇万人）の【具体的な課題】に対して、【このソリューション】で対応することで、【競合比較での差別化】が実現でき、【年1-2年の事業成長】につながる」 この書き方を採用することで、デザイン思考チームと経営戦略チームが「同じテーブル」で議論できるようになる。デザイン思考側は「なぜこの仮説を立てたのか」をユーザー行動の観察に基づいて説明し、戦略側は「この仮説を検証するのに必要な定量データは何か」を提示する。 --- 統合への第二歩：プロトタイプに「経営視点」を組み込む 仮説の質が上がった後、プロトタイプの設計段階でも、統合が必要になる。 従来のデザイン思考では、プロトタイプテストは「ユーザーがこの機能を使うか、使わないか」という行動検証に焦点が当たる。 しかし、ビジネスとしての検証を同時に進めるためには、プロトタイプテストの場面で以下も同時に検証すべき。 - 顧客獲得の現実性 — このソリューションを知った時、実際に買う決定をするか? 価格感は? - 事業運営コスト — このサービスを提供するのに、実際にいくらかかるのか? - 競争優位性 — 既存企業はなぜこれをやっていないのか? やった時の障壁は? 例えば、シニア向けスマートフォン操作支援アプリをプロトタイプテストする場合。ユーザーテスト以上に重要なのは、「月1,000円の価格なら買うか? 年1万円なら?」という経済的な意思決定の検証。または、「NTTドコモが同じ機能を無料で提供したら、どうする?」という競争シナリオの検証。 これらのテストを、ユーザーテストと同時に実施することで、初めて「ユーザーにとって価値がある」と「事業として成立する」の二つの条件が満たされているかが判断できる。 --- 統合への第三歩：組織的な意思決定ループの構築 ここまでの二つのステップを実行しても、組織全体としての「デザイン思考と戦略の統合」が達成されるわけではない。なぜなら、デザイン思考チームと経営戦略チームが別組織として動いている場合が多いからだ。 その場合に必要なのは、両組織が定期的に交わるミーティング体制の構築。 具体的には、以下のようなサイクルを組む。 - 月初：戦略会議 — 経営戦略チームが、今月進める複数の仮説・プロトタイプを定義。その時点での市場分析・競争分析も共有 - 週中：プロトタイプテスト実施 — デザイン思考チームが、ユーザーテストに加え、上記の「経営視点の検証」も実施 - 週末：学習共有会 — 両チームが集まり、「何が検証されたか」「次の仮説は何か」を言語化 この週単位のループの中で、仮説は「ユーザーにとって価値がある」と「事業として成立する」の両軸で、段階的に洗練されていく。 --- 実例：あるヘルスケア企業の統合事例 ある大手ヘルスケア企業で、以下のようなプロセスが動いた。 初期の対立 経営戦略チームが「高齢者向けの在宅医療支援サービス」の事業化を提案。市場規模は500万人、年売上50億円の計画だった。 これに対し、デザイン思考チームが「実際に患者さんや家族にインタビューすると、在宅医療の課題は『医療支援』ではなく『精神的な不安』にあるのではないか」という指摘をした。 経営戦略側からは「精神的な不安の解決で、どう売上を作るのか」という質問が返ってきた。 統合へのプロセス そこで、デザイン思考チームが、ユーザーインタビューの結果を「市場セグメント別の不安の種類」と「セグメント規模」で再整理。 結果として、以下のような新しい仮説が生まれた。 「在宅医療を受ける患者の家族（推定〇〇万人）の『医師との相談不安』を、オンライン医療相談サービスで対応することで、患者の通院回数削減＆事業として年△△円の売上が期待できる」 この仮説の立て方により、ユーザー視点（家族の不安）と経営視点（売上規模）が接続された。 その上で、プロトタイプテストは以下のフォーカスで実施された。 - ユーザー視点の検証 — 家族は本当にオンライン医療相談を使うか? - 経営視点の検証 — 医療施設は医療相談サービスに対して、月いくらなら採用するか? 患者の通院回数は実際に削減するか? テストの結果、医療施設側のインセンティブの設計に工夫が必要であることが判明。最終的には、「通院回数削減による医療費削減額の一部を、サービス利用料とする」という新しい事業モデルが誕生した。 このモデルは、デザイン思考だけでは生まれず、経営戦略の視点も必要だった。かつ、経営戦略だけでも、このユーザーニーズの実装性は見えなかっただろう。 --- 最後に：統合の本質 デザイン思考と経営戦略の統合は、決して「二つの手法の折衷案を作る」ことではない。 むしろ、「ユーザーにとって価値がある」という定性的な理解と、「事業として成立する」という定量的な根拠が、同時に満たされる仮説をどう建てるか、検証するかという、問い自体の統合なのだ。 その過程で、デザイン思考側は「経営の制約条件の中でのイノベーション」をより強く意識するようになり、経営戦略側は「戦略の正しさを判断するには、ユーザー行動の実装性検証が不可欠」と気付く。 その相互の気付きの中にこそ、持続可能なイノベーションが生まれる。 --- ### デザイン思考が医療を変える——Mayo Clinic SPARC ラボが示した患者体験改革の実証 URL: https://designthinking.studio/articles/design-thinking-healthcare-patient-experience/ > 2002年のIDEOとの協議を経て2004年に開設されたMayo Clinic SPARCラボは、医療現場にデザイン思考を持ち込んだ最初期の大規模実験だった。術前待機時間の短縮と患者満足度の改善——その方法論と組織的教訓を解析する。 医療の世界でデザイン思考が「使える」と証明した事例がある。2002年にMayo ClinicがIDEOとの協議を開始し、2004年6月に開設した「SPARCラボ」だ。 病院という場所は、患者にとって極めて強いストレス環境だ。診察を待つ不安、受付の手続き、複雑な導線、診断前後の感情的な乱れ——これらはすべて、医療の「治療」そのものとは別に存在する「体験の問題」だ。SPARCの実験が問いかけたのは、「医療の質を上げるだけで患者満足は上がるのか」という根本的な疑問だった。 --- SPARC とは何だったのか SPARC は "See, Plan, Act, Refine, Communicate" の頭文字をとった名称で、消化器病学・肝臓学の専門家でもあるNicholas LaRusso医師とMichael Brennan医師が、2002年よりIDEOと協議を重ね、2004年6月に開設した実験的な「スカンクワークスラボ」だ。 医師とデザイナーが同じ空間で仮説を立て、実際の患者を対象にプロトタイプを試すという形式は、当時の医療業界には前例がほぼなかった。医師はエビデンスと臨床試験を信奉する文化を持ち、デザイナーは観察と共感マップを武器にする——この2つの文化を1つのチームに収めること自体が、最初の設計課題だった。 ラボが発足した当初の問題意識は明快だった。過去50年で医療技術は劇的に進歩した。しかしケアの「届け方」——患者が病院を訪れてから帰るまでの一連の体験プロセス——はほとんど変わっていなかった。新しい治療法や検査手法が増えるほど、患者体験はむしろ複雑化していた。 --- エスノグラフィから始まった観察 SPARCの手法の出発点は観察だった。 医師が診察室内で患者に何をしているかを記録するだけでなく、患者が病院に到着してから帰るまでの「旅」全体を映像と観察ノートで追った。患者は受付でどこに戸惑うか。待合室でどんな姿勢で時間を過ごすか。診察前の不安がどのタイミングで最も高まるか。 このアプローチは、臨床的には「問題なし」と判断されていた工程に、患者にとっての深刻なストレス源が隠れていることを次々と明らかにした。 たとえば術前待機（pre-op）の問題がある。医療的観点では手術前の待機時間は必要な手続きと準備のためのものだ。しかし患者の側から見ると、処置の理由が説明されない待機は「何かまずいことが起きているのでは」という不安の温床になっていた。SPARCはここに着目し、待機時間の使い方と環境の両面を再設計した。 --- 3つの初期プロジェクトと成果 SPARC発足後2年間で20以上のプロジェクトが走ったが、なかでも初期の3プロジェクトがその可能性を示した。 - 待合室のチェックインキオスク 空港のセルフチェックイン機をモデルに、病院受付にキオスク端末を導入するプロトタイプを設計した。受付スタッフへの負荷軽減と同時に、患者に「自分で手続きを完了できた」という小さな自律感をもたらすことが目的だった。 - 術前待機室の体験再設計 術前の待合スペースを患者インタビューと観察に基づき再設計した。Yaleビジネススクールのケーススタディによると、情報提供のタイミング・声かけの頻度・空間のレイアウト変更という「非医療的な介入」が患者満足度スコアの改善に寄与し、術前待機における患者の体感ストレスが有意に低下したと報告されている。この「非医療的な介入が数字を動かした」という事実は、院内での議論を大きく前進させた。 - 糖尿病患者向け教育カードシステム 患者が自宅でも理解できる情報設計のカードセットを開発した。医師の説明を補完する「患者目線の言語」に変換することで、疾患理解度と自己管理の実行率を高めることを目指した。 --- 医師とデザイナーの文化衝突 SPARCが直面した最大の障壁は、外部からの反対ではなく内部の文化的摩擦だった。 多忙な医師をラボの活動に引き込むことは容易ではなかった。「なぜデザイナーに診察室の設計を口出しさせなければならないのか」という反発は、ラボ発足初期に繰り返し起きた。医師にとっては、治療成績がすべての評価軸であり、「患者体験の質」は二次的な問題に映った。 LaRussoと同僚たちが採った戦略は、最初から説得しようとするのではなく、小さなプロトタイプで「見える結果」を先に作ることだった。術前待機の改善データが院内で共有されると、「デザイン思考で何ができるか」への関心が医師側からも生まれ始めた。 --- CFIへ——スカンクワークスから全社展開 2004年のSPARC開設から4年後の2008年、ラボは1つの部門の実験的取り組みから「Mayo Clinic Center for Innovation（CFI）」へと発展した。専任のリサーチャーとデザイナーを擁する組織的なイノベーション機関となり、ケアの届け方全体——初診の電話から、外来診察、診断、治療、フォローアップ、予防ケアまで——を研究対象とした。 この成長の軌跡は、デザイン思考の組織展開において普遍的な教訓を持っている。変化のエンジンは「理解させること」ではなく「体験させること」であり、体験が生んだ小さな成功がアーリーマジョリティを引き込む。 --- 医療とデザイン思考の親和性——なぜ機能するのか 医療とデザイン思考が特に親和性が高い理由は、医療の本質が「人と人の相互作用」にあるからだ。どれほど優れた治療技術も、患者がその意図と手順を理解できなければ効果は限定される。不安が強いほど、痛みの体験は増幅する。医師の説明が届かなければ、患者の治療への参加意識は損なわれる。 患者体験の質は、ケアの医学的成果に直接影響する——この認識が、医療領域でのデザイン思考の正当性をもたらしている。 同時に、医療現場はデザイン思考にとっての「限界テスト」でもある。倫理的制約、個人情報保護、失敗が生命に関わるリスク——これらの条件下でも「観察→仮説→プロトタイプ→検証」のサイクルを回せることを、SPARCは実証した。 --- 現在への示唆 Mayo Clinic SPARCの実験から20年以上が経ち、医療現場でのデザイン思考は世界各地に広がっている。英国NHSのデザイン部門、スタンフォード医学部でのバイオデザインプログラム、国内では多くの病院がサービスデザインの手法を取り入れ始めている。 しかし依然として課題は残る。デザイン思考の「プロセスを回すこと」が目的化し、患者の声が実装に届かないまま終わるプロジェクトは今も多い。SPARCが示したのは、成果を出すために必要なのはデザイン思考の「手法」ではなく、実際の患者に関与しながら仮説を検証し続ける「執念」だったということだ。 --- 参考文献・出典 - Yale School of Management, "Mayo Clinic: Design Thinking in Health Care" — Case Study Research and Development. https://cases.som.yale.edu/design-mayo - Mayo Clinic Center for Innovation, Wikipedia. https://en.wikipedia.org/wiki/MayoClinicCenterforInnovation - Design Observer, "Mayo Clinic: Design Thinking in Health Care – Case Study Synopsis & Teaching Objectives". https://designobserver.com/mayo-clinic-design-thinking-in-health-care-case-study-synopsis-teaching-objectives/ - Huron Consulting Group, "How Design Thinking Can Transform the Hospital Experience". https://www.huronconsultinggroup.com/insights/design-thinking-transform-hospital-experience --- 関連記事 - IDEOのショッピングカート設計——デザイン思考の古典的実証 - デザイン思考と組織変革の統合 - サービスブループリント——見えないサービスを可視化する - 共感マッピングの実践ガイド --- ### デザイン思考が失敗する5つのパターン URL: https://designthinking.studio/articles/design-thinking-failures/ > デザイン思考の導入が失敗する典型的な5つのパターンを分析。共感の形骸化、プロトタイプ恐怖症、イノベーション・シアターなど、現場で繰り返される構造的な問題と対策を解説。 デザイン思考は強力な方法論ですが、導入しただけで成果が出るものではありません。 むしろ「デザイン思考をやっている」という事実が、思考停止の免罪符になるケースすら存在します。 「うちもデザイン思考を導入したけど、何も変わらなかった」 この言葉を、新規事業やDXの現場で何度耳にしたことでしょうか。研修を受け、付箋を貼り、ペルソナを作り、プロトタイプも作った。しかし結局、従来と同じプロセスに戻ってしまった。 関係者の間に「あれは一過性のブームだった」という空気が漂い始める。 ワークショップでよく起こるのは、手法への期待が高すぎて、最初の成果が小さく見えてしまうパターンです。デザイン思考は銀の弾丸ではない。 しかし、失敗の多くは方法論そのものの限界ではなく、運用の仕方に原因があります。 失敗には再現性がある 実際にやってみると、デザイン思考の失敗パターンは驚くほど似通っています。業種も規模も異なる組織で、同じような失敗が繰り返されている。 それは、構造的な問題が存在することを意味します。 以下に、現場で最も頻繁に観察される5つの失敗パターンを挙げます。 パターン1：共感の形骸化 症状 ユーザーインタビューを実施したが、聞いたのは「自分たちが聞きたいこと」だけだった。 ユーザーの声をデータとして扱うのではなく、既存の仮説を確認するための儀式として消費してしまう。 なぜ起こるか プロジェクトには既にゴールが設定されていることがほとんどです。「このサービスを作る」と決まった上でユーザーインタビューを実施するため、チームは無意識に都合の良い発言だけを拾ってしまいます。 確認バイアスが共感フェーズを形骸化させるのです。 対策 共感マップを作成する際に、「自分たちの仮説と矛盾する発言」を意図的に抽出するセッションを設けます。「ユーザーの声のうち、聞きたくなかったものは何か」という問いが、本質的なインサイトに近づく鍵になります。 パターン2：定義フェーズの軽視 症状 共感フェーズで集めた情報を十分に分析しないまま、「何となく見えた課題」でアイデア出しに突入する。 POVステートメントを作らず、「ユーザーは〇〇に困っている」という曖昧な共通認識で進んでしまう。 なぜ起こるか 定義フェーズは地味な作業です。付箋をグルーピングして、パターンを見つけて、問いの形に落とし込む。 参加者にとっては、アイデアをどんどん出すIdeateの方が圧倒的に楽しい。ファシリテーターも、場の盛り上がりを維持するためにDefineを駆け足で通過させがちです。 対策 ダブルダイヤモンドの構造を意識し、Defineに全体の20%以上の時間を割り当てるルールを設けます。「How Might We」の問いが明確に言語化されるまで、次のフェーズに進まないという制約が効果的です。 パターン3：プロトタイプ恐怖症 症状 プロトタイプのフェーズに入ったのに、「もう少しリサーチが必要」「まだアイデアが固まっていない」と、いつまでも手を動かし始めない。 完璧なアイデアが生まれるまで待とうとする。 なぜ起こるか プロトタイプを作るということは、アイデアが「批判可能な形」になることを意味します。 頭の中にある限り、アイデアは完璧でいられる。しかし形にした瞬間、粗が見えてしまう。その恐怖が、プロトタイプの制作を遅延させます。 対策 「15分で作れるもの」だけを最初のプロトタイプにするというルールが有効です。紙とペン、段ボール、Keynoteのスライド。質にこだわる必要は全くない。「これは捨てるために作るもの」という前提を共有することで、心理的なハードルが下がります。 パターン4：テストの省略 症状 プロトタイプまでは作ったのに、ユーザーに見せずに社内で評価してしまう。 「ユーザーテストの時間がない」「まだ見せられるレベルではない」という理由で、テストフェーズが丸ごとスキップされる。 なぜ起こるか テストには外部のユーザーを巻き込む必要があり、スケジュール調整やリクルーティングのコストがかかります。 プロジェクトの納期が迫ると、最も「省略可能に見える」のがテストフェーズです。しかし実際には、テストの省略は最大のリスクです。 対策 デザインスプリントのアプローチを参考に、テストの日時を最初に固定し、そこから逆算してスケジュールを組む方法が効果的です。テストが「削れるオプション」ではなく「動かせない締め切り」になれば、省略は起きません。 パターン5：イノベーション・シアター 症状 デザイン思考の「形式」を完璧にこなしているのに、事業インパクトがゼロ。 ワークショップの回数、ペルソナの数、プロトタイプの数をKPIにしてしまい、「やっている感」が目的化する。組織の上層部は「うちはデザイン思考を取り入れている」とアピールするが、現場は疲弊している。 なぜ起こるか 組織がデザイン思考を「方法論」ではなく「ブランディングツール」として導入した場合に発生します。「イノベーティブな企業に見られたい」という動機が、プロセスの本質を歪めてしまう。 成果ではなく活動量が評価指標になり、本来の目的を見失います。 対策 デザイン思考の成果を「ユーザーの行動変化」で測定する仕組みを導入します。ワークショップの回数ではなく、「テストを通じて発見された未充足ニーズの数」「プロトタイプに対するユーザーの行動変化」を追跡する。計測できない活動は、やがてシアターになります。 失敗から学ぶための問いかけ 5つのパターンに共通しているのは、デザイン思考の「プロセス」だけを導入し、「思考」を導入しなかったという点です。プロセスは誰でも真似できますが、「ユーザーの立場に立って考える」「作る前に学ぶ」「失敗を歓迎する」というマインドセットの変容は、一朝一夕には起きません。 次にデザイン思考のプロジェクトを振り返るとき、この5つのパターンに自分たちの活動を照らし合わせてみてください。 1つでも当てはまるものがあれば、プロセスではなくマインドセットに問題がある可能性が高い。手法を変える前に、チームの前提を疑ってみること。それ自体が、デザイン思考の実践です。 --- 参考文献 - Natasha Jen, "Design Thinking is Bullsh*t", lecture at 99U Conference, 2017（批判的視点からの考察） - Jeanne Liedtka, "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction", Journal of Product Innovation Management, Vol.32, No.6, 2015 - Tim Brown, Change by Design, HarperBusiness, 2009（第9章：Design Activism） --- ### デザイン思考チームと心理的安全性｜Amy Edmondsの研究が示す「失敗を語れる場」の設計 URL: https://designthinking.studio/articles/design-thinking-team-psychological-safety/ > デザイン思考の成否を左右する「心理的安全性」を、Amy Edmondson（ハーバード・ビジネス・スクール）の研究をもとに解説。ワークショップ設計・ファシリテーション技法・組織制度の3層から、チームが失敗を語れる場を作るための実践的アプローチを示す。 「アイデアを出してください」と言われたとき、チームに沈黙が流れた経験はないでしょうか。テーブルには付箋が積まれ、ホワイトボードは白いまま。全員が誰かの顔をうかがっている。 こうした状況で機能しない問題は、ファシリテーターの技術でも手法の選択でもありません。チームに心理的安全性が欠けているとき、どれほど洗練されたデザイン思考プロセスも動き出せないのです。 --- 心理的安全性とは何か Amy Edmondson（ハーバード・ビジネス・スクール Novartis Professor of Leadership and Management）は、1990年代後半の研究でこの概念を定式化しました。彼女の定義によれば、心理的安全性とは「チームが対人リスクを取っても安全だという共有された信念」です。 重要な点が2つあります。 第一に、これは個人の気質ではなくチームの状態です。「私は話しやすい性格だ」という個人特性ではなく、「このチームでは発言しても批判されない」という場の認識です。第二に、心理的安全性は「居心地の良さ」や「馴れ合い」とは異なります。Edmondsonは著書『The Fearless Organization』（Wiley、2018年）の中で、心理的安全性と高い業績基準は両立するものであり、むしろ高い基準を持つチームほど心理的安全性が重要になると述べています。 --- なぜデザイン思考にとって不可欠なのか デザイン思考の各フェーズを振り返ると、すべてに「失敗や不確実性を表明する場面」が組み込まれています。 共感フェーズでは、インタビューで得た「よくわからないもの」をそのまま持ち帰る必要があります。「これはどう解釈すればいいのか」という未消化の問いを声に出せるかどうかが、インサイトの深さを左右します。 定義フェーズでは、「問いを立てる」作業そのものが評価されます。間違った問いを提示しても批判されないと感じなければ、チームは当たり障りのない問いに落ち着いてしまいます。 創造フェーズでは、おかしなアイデアを出すことが求められます。ブレインストーミングで「どうせ却下される」と思った瞬間、人はフィルターをかけ始めます。 プロトタイプ・テストフェーズでは、ユーザーから否定されることが前提です。「うまくいかなかった」を正直に報告できる空気がなければ、学習サイクルは機能しません。 デザイン思考は構造的に「失敗を情報として扱う」プロセスです。その前提として、失敗を語れる場が必要になります。 --- Googleの「Project Aristotle」が示したこと Googleは社内研究プロジェクト「Project Aristotle」において、180以上の社内チームを分析しました。200を超えるインタビューと250以上のチーム属性を調査したこのプロジェクトの結論は、心理的安全性が他のすべての要因を凌駕するという点でした（Googleの公開資料「re:Work — Guide: Understand team effectiveness」で参照可能）。 成員のスキルレベルも、チームの構成も、個人の実績も、チームのパフォーマンスをほとんど予測しませんでした。「このチームで失敗しても罰せられない」という認識だけが、一貫して高い成果と相関していたのです。 --- 3層のアプローチ 心理的安全性を設計するには、ワークショップ・ファシリテーション・組織制度という3つの層で取り組む必要があります。 層1：ワークショップ設計 ルールの明文化が最初の一手です。ブレインストーミングの「判断を保留する」ルールは、心理的安全性を一時的に高めるための制度設計です。しかし口頭で伝えるだけでは機能しません。「このセッションでは、アイデアへの批判はしません。アイデアについての質問はOKです」というように、具体的な行動として書き出し、全員が目に入る場所に貼ってください。 失敗事例の共有から始めるという設計も有効です。セッション冒頭でファシリテーター自身が「過去に失敗したこと」を開示すると、参加者は「この人も失敗するのか」という安心感を持てます。地位の高い人が率先して脆弱性を示すことで、チームの心理的安全性の基準値が上がります。 匿名の入力手段を用意することで、発言のハードルを下げられます。デジタルツール（Miro、FigJam等）の匿名付箋機能や、紙に書いて集める方式は、「最初のアイデア」を引き出すのに有効です。ただし匿名フェーズはあくまでも導入であり、最終的には記名での対話に移行することが重要です。 層2：ファシリテーション技法 Edmondsonが推奨するファシリテーター行動の中でも、特にデザイン思考に有効なのは「枠組み直し（reframing）」です。 「失敗しました」という報告に対して「何を学びましたか」と問い直す。「アイデアが浮かびません」という発言に対して「何がそれを難しくしていますか」と尋ねる。これらの応答は、チームに「ここでは問いを立てることが価値を持つ」というシグナルを送ります。 もうひとつ有効なのは、「肯定から始める」応答パターンです。誰かのアイデアに対して、まず「それがうまくいく理由」を全員で考えてから「課題」を検討する。この順序は、批判への恐れではなく可能性への好奇心でアイデアを扱う習慣をチームに作ります。 層3：組織制度 単発のワークショップで心理的安全性を高めることはできますが、それを維持するには制度的な裏付けが必要です。 「失敗の振り返り会」の定例化は代表的な手法です。週次・月次を問わず、プロセスの失敗を蓄積し共有する場を作ることで、「失敗を話すことが業務の一部である」という文化が育ちます。Pixar Animationが実施している「postmortem（事後検討）」のプロセスは、この制度化の典型です。 評価基準の可視化も重要です。「挑戦したこと」や「早期に課題を特定したこと」が評価される仕組みがないまま心理的安全性を高めようとしても、人々は「失敗しても安全だが、失敗は評価を下げる」という矛盾した信号を受け取ります。 --- 心理的安全性を壊す行動パターン 高めることと同様に、壊さないことも重要です。以下の行動はチームの心理的安全性を急速に損なわせます。 否定的な反応の優先：アイデアが出た直後に「でも」「それは難しい」「以前にやって失敗した」で応答すること。一度の否定的反応が、その後の発言量を大きく減らします。 沈黙のプレッシャー：上位者が発言した後に全員が同意に傾く「HiPPO（Highest-Paid Person's Opinion）効果」。ファシリテーターは意図的に「異なる見方はありますか」と問い続ける必要があります。 個人攻撃の許容：アイデアへの批評と発言者への批評を区別しないこと。「そのアイデアは弱い」はアイデアへの評価ですが、「あなたはいつもそういう表面的なことしか言わない」は発言者への攻撃です。後者を一度でも容認すると、チームの心理的安全性は急落します。 --- 現場での適用：段階的な導入 心理的安全性の高いチームを作ることは、一度のワークショップで達成されるものではありません。Edmondsonsの研究が示すのは、心理的安全性は日々の小さなやりとりの積み重ねによって形成されるという点です。 実践的な出発点として、次の問いをチームに投げかけることから始められます。「最近、チームの誰かのアイデアに意見したくて、しなかったことはありますか？」この問いへの正直な回答が、現在の心理的安全性の水準を測る最初のデータになります。 デザイン思考は「正解を出すプロセス」ではなく「正しい問いを探すプロセス」です。その探索が起きるための条件として、心理的安全性はプロセスと切り離して考えることができません。 --- 参考資料 - Edmondson, A. C. (2018). The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley. - Google re:Work. "Guide: Understand team effectiveness." https://rework.withgoogle.com/ - Edmondson, A. C. (1999). "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, 44(2), 350–383. --- ### デザイン思考チームの多様性設計｜なぜ「似た者集め」はイノベーションを殺すのか URL: https://designthinking.studio/articles/design-thinking-team-diversity/ > デザイン思考においてチームの多様性がなぜ重要か、どう構成するかを実践的に解説。認知多様性・機能的多様性・経験多様性の3軸から、IDEO・IBM・d.schoolの知見をもとに、チーム設計の具体的な基準と陥りがちな落とし穴を示す。 「多様なチームを作れ」という言葉は、デザイン思考の教科書に必ずといっていいほど登場します。しかしワークショップ現場で観察すると、「多様性を確保した」チームが、似た者集めのチームとさほど変わらない結果を出すケースが頻繁に起きています。 なぜか。チームの多様性が「属性の見かけ上の違い」にとどまっており、「思考の多様性」に変換されていないからです。 --- 多様性の3軸：何を多様にするのか デザイン思考チームの文脈で「多様性」と言う場合、3つの次元を区別する必要があります。 - 認知多様性（Cognitive Diversity） 問題をどう捉え、どう解くかの「思考スタイルの違い」です。心理学者のKatherine Phillips（コロンビア・ビジネス・スクール）は、Scientific American誌（2014年10月号）の論文「How Diversity Makes Us Smarter」で、認知多様性の高いチームは情報処理の幅が広く、見落とされがちな視点を補完しやすいことを示しています。 デザイン思考で特に機能するのは、「問題を細部から積み上げる人（帰納型）」と「全体構造から分解する人（演繹型）」の共存です。前者はユーザーインタビューで細かな言葉の違いに気づき、後者は「そのパターンが意味すること」を構造化します。 - 機能的多様性（Functional Diversity） 組織内での役割・専門領域の違いです。IDEOの共同創業者Tim Brownは著書『Change by Design』（2009年）の中で、「T字型の人材（T-shaped people）」——一つの深い専門性と、複数領域への幅広い好奇心を持つ人——のチームが最も効果的だと述べています。 機能的多様性の効果は、「知識の境界線で生まれるアイデア」にあります。マーケターがエンジニアの制約を知り、エンジニアがユーザーの感情的ニーズを理解したとき、単一職能のチームには出てこない解決策が生まれます。 - 経験多様性（Experiential Diversity） 業界経験・文化的背景・生活体験の違いです。d.school（Stanford d.school）のカリキュラムが学部を横断する形で設計されているのは、この多様性を人工的に生み出すための設計です。医学部生・法学部生・工学部生が同じユーザー課題に取り組む時、それぞれが「当然の前提」と思っていることが異なるため、問い直しが自然に起きます。 --- IBM Design Thinkingの「多様なチーム」設計原則 IBMは2012年から大規模にデザイン思考を組織に導入する中で、チーム構成の原則を体系化しました。IBM Design Thinkingのフレームワーク（公式サイト: www.ibm.com/design/thinking/）では、「Diverse Teams」を5つのコア原則の一つとして位置づけ、以下の構成を推奨しています。 - Sponsor（意思決定権者）: プロジェクトの後ろ盾と優先度を担保 - Doer（実行者）: 最終的にプロダクト・サービスを構築する人 - User（ユーザー代表）: ターゲットユーザーと近い経験・視点を持つ人 - Subject Matter Expert（専門家）: 特定ドメイン知識を持つ人 4種類すべてが揃わないチームでスタートする場合、IBMのガイドラインは「不在の役割を誰が一時的に担うか」を明示することを推奨しています。「誰かが担う」ではなく、「誰が意識的に代替するか」を明示することで、視点の欠落を可視化するという逆説的な効果があります。 --- 「同質化の引力」：なぜ多様なチームが同質化するか 多様なメンバーが集まっても、ワークショップが進むにつれて「最も声の大きい意見」や「権威ある人の方向性」に収束することが起きます。これを組織心理学では「同質化の引力（Homophily）」と呼びます。 デザイン思考のワークショップ設計で特に注意が必要な場面は3つです。 アイデア発散フェーズ：ブレインストーミングで「奇抜なアイデア」が出ても、収束フェーズで「実現可能そうなもの」「既存事業と整合するもの」に絞り込むと、多様性の産物が消えます。クレイジーエイトや1-2-4-Allなど、個人ワーク先行・集合化後倒しの構造が同質化を抑制します。 HMW（How Might We）作成フェーズ：問いの設定が狭すぎると、多様な背景を持つメンバーが同じ問いに落ちます。「一人のメンバーが設定した問いを全員で検討する」形式ではなく、各自が独立してHMWを書いた後に並べて比較することで、問いの多様性を維持できます。 プロトタイプ評価フェーズ：完成度の高いプロトタイプは、機能への評価に集中しやすく、「そのサービスが誰を排除しているか」「別の文化的文脈では機能するか」という問いが出にくくなります。意図的にDemographic Probeを設ける——特定の年齢層、非デジタルネイティブ、特定言語話者の視点から評価するセクションを作る——ことで、多様な評価を構造的に引き出せます。 --- チーム多様性の「罠」：多様にすれば良いわけではない 多様性の研究で繰り返し示されているのは、多様なチームは均質なチームより成果のばらつきが大きいという事実です。Aparna Joshi & Hyuntak Roh（2009年、Journal of Applied Psychology）のメタ分析によると、多様なチームは機能した時に高い成果を出す一方、機能しなかった時には均質なチームより低い成果になる傾向があります。 この分散を抑制するのが、ファシリテーションの設計です。特に重要なのは以下の3点です。 - 心理的安全性の確保: Amy Edmondsonの研究が示すように、少数意見が発言できる環境がないと、多様性は意見の衝突に変換されず、沈黙に変換されます。ワークショップ対立マネジメントの視点がここで機能します。 - 役割の明確化: 「誰が何を担当するか」が曖昧なまま多様なチームが集まると、専門性の衝突が起きやすくなります。プロトタイプ制作では、「アイデアの責任者」と「実装の責任者」を分けることで、それぞれの専門性が干渉しにくくなります。 - 振り返りの設計: 多様なチームが機能したかどうかを確認する振り返りのセクションを、ワークショップの最後に設けます。「全員の声が拾えたか」「誰かの発言が抑制されていなかったか」を問う形で、次回チーム設計へフィードバックします。 --- 実践：チーム多様性チェックリスト ワークショップ設計前に確認すべき項目を示します。 構成チェック（最低3項目の多様性を確保） - [ ] 職能・専門領域が2つ以上あるか - [ ] 意思決定権者と実行者が混在しているか - [ ] ユーザーに近い経験・背景を持つメンバーがいるか - [ ] 業界外・組織外の視点を持つメンバーがいるか（外部招聘含む） プロセスチェック（同質化の引力への対策） - [ ] 発散フェーズに個人ワーク先行の構造があるか - [ ] 権威ある人の意見が先に共有されない進行になっているか - [ ] 評価フェーズで特定の視点（年齢・文化・使用スキル）を意識的に設けているか 振り返りチェック - [ ] 「誰の声が少なかったか」を確認するセクションがあるか --- デザイン思考における多様性は、「なんとなく色んな人を集める」ことではありません。思考の多様性が機能するためのプロセスを設計すること——これがチーム構成において最も重要な実践判断です。 多様なチームが最も力を発揮するのは、ファシリテーターがその多様性を「安全に表現できる環境」を意識的に構築した時だけです。デザイン思考リーダーシップ変革の文脈でも、チームの多様性を引き出せるかどうかは、リーダー自身の姿勢設計に直接関わっています。 --- ### デザイン思考でデジタルバンキングを変えた——DBS・Capital One の実装解剖 URL: https://designthinking.studio/articles/design-thinking-digital-banking-transformation/ > DBS銀行の「Live More, Bank Less」戦略とCapital OneのAdaptive Path買収から、デジタルバンキングにおけるデザイン思考の実装方法を解剖する。ユーザージャーニー起点の組織変革と、デザイン組織内製化がもたらす実装条件を3つの共通条件として抽出する。 デジタルバンキングのUX改善は、多くの金融機関が「やっている」と言う。しかしユーザーが体感する変化は、多くの場合小さい。 理由は単純だ。UIを変えることと、サービスの設計思想を変えることは、まったく別の取り組みだ。DBS銀行と Capital One は、後者をやった。UIではなく、銀行として何をどの順序で提供するかの「思想の層」からデザイン思考を適用した。この2事例の実装を解剖する。 --- DBS銀行——「バンキングを見えなくする」という設計思想 シンガポールの DBS 銀行（Development Bank of Singapore）が「World's Best Digital Bank」（Euromoney 誌選出）に至るプロセスは、UI刷新の話ではない。「銀行という体験をどこまで消せるか」という問いからスタートした組織変革の話だ。 「Live More, Bank Less」という北極星 DBS の Strategy 2.0（2014年以降）の中核にあったのは「Making Banking Joyful」というビジョンだ。このビジョンを実装するために採用された概念が「Live More, Bank Less」——顧客が銀行のことを考えなくて済む状態を作る、という思想だ。 通常の金融機関は「いかに顧客を銀行のサービスに引き付けるか」を起点にする。DBS はこれを逆転させた。「顧客が人生でやりたいことの文脈に、銀行をシームレスに組み込む」という視点からサービスを再設計した。 これはデザイン思考の「共感」フェーズの思想と直結している。ユーザーが本当に達成したいこと（Job to Be Done）は「送金する」「ローンを組む」ではなく「家族に仕送りをする」「家を買う」だ。この区別が、サービス設計の出発点になった。 ジャーニー思考と 4D フレームワーク DBS が組織全体に展開したのが「ジャーニー思考（Journey Thinking）」だ。従来の業務プロセス（銀行の都合の順序）ではなく、顧客がタスクを達成するために辿る行動の連鎖を起点にする思考法として、全社員への展開が行われた。 実装フレームワークとして DBS が採用したのが「4D Framework」だ——Discover（顧客の現場でリサーチ）、Define（課題を言語化）、Develop（解決策を開発）、Deliver（実装・改善）。デザイン思考の5フェーズをオペレーション化したこのフレームワークは、IT部門・リテール部門・法人部門を問わず共通の作業言語として機能した。 2017年に開始した社員向けデジタル学習プログラム「DigiFY」では、7つのスキル領域のひとつとして「ジャーニー思考」が位置づけられ、22,000人規模の組織変革を支えた（McKinsey のケーススタディより）。 実測値と成果 DBS のデジタル変革がもたらした定量的な成果として、顧客サービスクエリの処理時間が33%短縮されたことが報告されている（FS-ISAC の事例研究より）。また、音声バンキング機能の導入によりモバイルアプリ利用者が30%増加した。 重要なのは、これらの数値の背後にある設計の思想だ。処理時間の短縮は業務効率化の成果だが、その出発点は「顧客が銀行業務に費やす時間を減らす」というデザイン起点の問いだった。 --- Capital One——デザイン組織を「買収」した銀行 Capital One のデジタル変革は、より直接的なアプローチを取った。2014年、Capital One は著名なUXデザインファームであるAdaptive Path を買収した。 Adaptive Path という資産 Adaptive Path は、ユーザーエクスペリエンスデザインの実践と理論を牽引してきたコンサルティングファームだ。「カスタマージャーニーマップ」という手法を実践として普及させた組織として知られている。カスタマージャーニーマップは現在では多くの企業が採用するが、その普及の一端を Adaptive Path が担った。 Capital One がこのファームを買収したことは、「デザイン思考を外部に委託する」から「デザイン思考を組織内部に内蔵する」への転換を意味した。American Banker 誌は、この買収を「デザイン能力を戦略的資産として扱う先例」と評した。 Capital One Labs と「逆から始める」設計 買収後、Capital One Labs はいわゆる「不正なイノベーション部門」として機能した。「Capital One 360 Cafe」と名付けた物理拠点をニューヨーク・ボストン・サンフランシスコ等に設置し、そこで顧客と対面してプロトタイプのフィードバックを収集するという手法を実装した。 この物理拠点は、デジタルバンキングにおける人間中心設計の逆説を体現している。デジタルを磨くために、わざわざリアルの接点を作る。ユーザーを実際に見ることなしに、ユーザーのためのデジタル体験は作れないという思想の実装だ。 また、既存の金融商品（当座預金口座開設・ネット口座作成・ATM体験）のフローを Labs チームが丸ごと再設計したプロジェクトが複数走り、銀行アナリストがデザイン思考のコーチになっていくという組織変容も起きた。 デザイン組織の内製化がもたらしたもの Capital One が Adaptive Path 買収後に達成した変化で、最も目に見えやすいのは組織構造の変容だ。デザイン専門家が数百名規模のチームとして全ビジネス領域に統合され、テクノロジー・データサイエンス・プロダクト各チームが同じ場で協働するようになった（Capital One Tech ブログ「Marking over 10 years of experience design」より）。 数値としての成果は、複合的な要因が絡むため特定の施策への帰属が難しい。しかし Capital One 自身が言語化するのは「人間中心設計のアプローチによってチームが顧客の意図をより深く理解できるようになった」という質的な変化だ。顧客の行動データを分析するだけでは次の行動を予測できても、顧客が本質的に何を達成しようとしているかは見えない。Adaptive Path の知見を取り込んだ質的なユーザーリサーチが、定量データの解釈精度を高める基盤になった。 --- 2事例から抽出する3つの共通条件 DBS と Capital One、アプローチは異なる。一方は組織文化全体の変革、一方はデザイン専門組織の内製化。しかし成功に至るための条件には共通点がある。 条件1：UIでなくサービスの「順序」を変える 両社とも、アプリの画面デザインより先に「何をどの順序でユーザーに提供するか」を再設計した。DBS の「ジャーニー思考」も、Capital One の「フロー全体の再設計」も、インターフェースの手前にある構造の問題を扱っている。 デザイン思考の本質的な価値は、ツールや手法の問題ではなく、問題の起点をユーザーの文脈に置くという思考の構造にある。 条件2：法務・コンプライアンスをプロセスに組み込む 金融機関でのデザイン思考の実装が失敗するパターンの多くは、プロトタイプ段階でコンプライアンス部門からの拒否が来て止まることだ。DBS も Capital One も、法務・コンプライアンスを「テスト後に審査する部門」ではなく「設計初期から参加する部門」として位置づけた。 規制の制約は「何ができないか」の壁ではなく「この形ならできる」の条件設定として機能させる——これが金融領域でデザイン思考を動かす実践的な鍵だ。 条件3：経営レベルのコミットメントと測定可能な目標 DBS の場合、2014年の CEO 交代（ピユシュ・グプタ体制）がデジタル変革の大きな転換点だった。経営トップが「バンキングを見えなくする」という設計思想を掲げ、そこへの投資を正当化したことで、組織全体が同じ方向に動けた。 Capital One の場合、Adaptive Path 買収という意思決定自体が経営レベルのコミットメントの表明だった。「デザイン能力は外注するものではなく、自社に内蔵するものだ」という判断は、経営戦略の言語での意思決定だ。 デザイン思考の組織導入が失敗する多くのケースで、経営層のコミットメント不足と「成果の測定方法が定義されていない」という問題が重なる。DBS の「World's Best Digital Bank」というKPIも、Capital One の「モバイルエンゲージメント」という指標も、測定可能な目標として機能していた。 --- デジタルバンキングにおけるデザイン思考の限界 最後に、限界についても触れる。 DBS と Capital One の成功事例は、その規模と経営へのコミットメントが前提条件になっている。中規模の地域金融機関や信用組合がまったく同じアプローチを取れるかというと、リソースの現実が異なる。 また、「デザイン思考を適用した」という因果関係の証明は常に難しい。DBS の成果は、デザイン思考の導入と同時期にシンガポール市場の成長・IT投資増加・規制環境の変化が重なっており、デザイン思考単独の貢献を分離することはできない。 それでもこの2事例が示すことは明確だ。銀行業務の「見た目」を変えることと、銀行業務の「起点」をユーザーに置くことは、まったく別の取り組みだ。 後者に着手した組織だけが、デジタルバンキングにおけるユーザー体験の本質的な変化を生み出せた。 --- ### デザイン思考でプロダクトロードマップを優先度付けする——機能積み上げから脱出するための実践論 URL: https://designthinking.studio/articles/design-thinking-product-roadmap-prioritization/ > プロダクトロードマップの優先度付けにデザイン思考を適用する方法を解説。機能要望の「積み上げ地獄」から脱出するために、Teresa TorresのOpportunity Solution Tree、Kanoモデル、HMW問いを組み合わせた実践的フレームを提示します。 プロダクトマネージャーが「機能要望リスト」と向き合うとき、たいていこんな状況に陥っています。営業から「大手クライアントが○○機能を求めている」という声が入る。CSから「解約の理由に△△がない点が挙げられる」という報告が上がる。エンジニアからは「□□の技術的負債を解消したい」という要望がある。それを全部リスト化すると、優先度の根拠がどれも「言っている人が強い」になる。 ProductPlanが毎年実施するState of Product Management調査では、機能優先度付けがプロダクトチームの最大の運用課題として繰り返し上位に挙がっています（2024年版）。この問題の本質は、機能の要望を受け取る体制は整っていても、顧客の「本当の問題」を理解する体制が整っていないことにあります。 --- 「機能の積み上げ」が起きる構造的理由 ロードマップが機能のリストに変質する理由は、意思決定のプロセスが「インサイドアウト」になっているからです。社内の各部門が自分たちの問題意識からロードマップに機能を追加し、顧客の実際の体験から逆算される機能が後回しになる。 デザイン思考の視点からこの問題を診断すると、「共感フェーズを省略したまま定義・発想フェーズに入っている」状態です。顧客が何に困っているかを深く理解せずに、解決策（機能）を先に積み上げている。 --- ステップ1：Opportunity Solution Tree で問いの構造を作る Teresa Torres（プロダクトディスカバリーコーチ、producttalk.org主宰）が2016年に提唱したOpportunity Solution Tree（OST）は、この問題に直接対処するフレームです。 OSTの構造は4層です。 Outcome（達成したいビジネス指標）→ Opportunity（顧客の課題・ニーズ・欲求）→ Solution（Opportunityに対応する解決策）→ Experiment（Solutionが機能するかを検証する実験） 最重要なのは「Opportunityの層」です。Torresの主張は明確で、「機能を優先度付けする前に、解くべきOpportunityを優先度付けする」ことが先決です。Opportunityとは「顧客インタビューから発見された、顧客の未充足ニーズ・痛み・欲求」であり、社内の要望ではありません。 OSTをロードマップ策定に使うとき、順序は次の3段階になる。 まず、チームが追うべきOutcomeを1つに絞ります（例：「60日以内のチャーン率を月1%以下に下げる」）。次に、顧客インタビューを通じてOpportunityを収集します（例：「オンボーディング後に毎日ログインする理由がわからない」「他チームへの共有方法が複雑で、そこで止まる」）。Opportunityが揃ったら、その中で「どれが最もOutcomeに影響するか」を優先度付けします。機能の優先度付けは、Opportunityの優先度が決まった後に行います。 この順序の逆転が、機能積み上げ地獄から脱出する核心です。 --- ステップ2：Kanoモデルで顧客価値の次元を分類する Opportunityが整理できたら、次は解決策の候補を「どれが顧客満足に最も効くか」の観点で評価します。Kanoモデルはそのために有効なツールです。 Kanoモデルは、1984年に狩野紀昭ら（東京理科大学）が提唱した顧客満足モデルです（Kano, Seraku, Takahashi, Tsuji "Attractive Quality and Must-Be Quality," Journal of the Japanese Society for Quality Control, 14(2), 1984）。機能を3カテゴリに分類します。 「当たり前品質（Must-Be）」 は、なければ強い不満を生むが、あっても当然とみなされる機能です。例：バグのない動作、基本的なデータ保存。 「一元的品質（Performance）」 は、良くするほど満足が上がり、悪くするほど不満が増す機能です。例：読み込み速度、検索精度。 「魅力的品質（Attractive）」 は、あると嬉しいが、なくても不満にはならない機能です。顧客が自分では言語化していないニーズを満たす。例：予想外の自動化、思いがけない発見につながる推薦機能。 優先度付けへの示唆は、「魅力的品質を見つけることが差別化の源泉」という点にあります。競合他社がすでに持っている機能は、時間が経つと「当たり前品質」に下がります。顧客インタビューでまだ言語化されていないニーズを見つけ、それを「魅力的品質」として実装することが、ロードマップの戦略的価値を作ります。 実際の評価方法は、顧客に「この機能が（ある/ない）とき、どう感じますか？」という2方向の質問を投げ、回答の組み合わせからカテゴリを判定します。 --- ステップ3：HMW問いでOpportunityを具体化する Opportunityを発見した後、アイデア出しに入る前に「解くべき問い」を一文で立てる。デザイン思考のHow Might We（HMW）問いが、この橋渡しを担う。 HMW問いの設計原則は、「広すぎず、狭すぎず」です。「ユーザーのオンボーディングをどう改善するか？」は広すぎる——解決策が無限に広がりすぎて収束できません。「ウェルカムメール件名をABテストする方法は？」は狭すぎる——一つの施策に閉じていてアイデアが広がりません。 適切な幅の例：「新規ユーザーが最初の1週間で、自分のチームにとって価値を感じる瞬間を作るには？」 このHMW問いを、Opportunity一つにつき1〜3問設計します。次の発散フェーズ（アイデエーション）がこの問いを起点に進むことで、「解決策から始まる議論」ではなく「問いから始まる議論」になります。 --- ステップ4：RICE × Opportunity の統合評価 機能候補が出揃ったら、定量的な評価フレームと組み合わせます。RICEスコアは、プロダクト管理でよく使われる優先度評価フレームです。 RICE = Reach（どれだけ多くのユーザーに影響するか）× Impact（1ユーザーへの影響度）× Confidence（確信度）÷ Effort（開発工数） ただし、RICEをそのまま使う落とし穴があります。Reach と Impact の推定値が、社内の印象論に依存することです。ここでデザイン思考の顧客インタビューデータを接続します。 「Reach」はOSTで収集したOpportunityの頻出度から算出する。「Impact」はKanoモデルの分類（魅力的品質>一元的品質>当たり前品質）から重み付けする。「Confidence」は顧客インタビューで何人がそのOpportunityを語ったかを参照する。 この接続により、RICEスコアが「数字の印象論」から「顧客インサイトに根拠を持つ評価」に変わります。 --- チームでの実践：1日ワークショップの設計 上記のフレームをチームで使うには、1日のワークショップ形式が効果的です。 午前（3時間）：Opportunityのマッピング。直近の顧客インタビュー録音・録画・メモを素材に、チーム全員でOpportunityを付箋に書き出します。ここで重要なのは「機能の要望」ではなく「顧客の状況・感情・課題」を書くことです。付箋を類似性でグループ化し、Opportunityクラスターを作ります。 午後前半（2時間）：HMW設計とアイデエーション。優先OpportunityごとにHMW問いを設計し、クレイジーエイツ（8分で8案スケッチ）などのアイデエーション手法でソリューション候補を発散します。 午後後半（1時間）：RICE評価と合意形成。Kanoモデルの分類とRICEスコアを組み合わせて、上位5〜10件に絞り込みます。この段階で合意が取れなかった点は「仮説と検証設計」として翌週のスプリントに持ち越します。 --- 「データドリブン」との違い 「顧客データを見ればいい」という反論があります。確かに行動ログ・ファネル分析・NPS調査は優先度付けの重要な材料です。ただ、定量データが教えてくれるのは「どこで問題が起きているか」であり、「なぜ起きているか」は教えてくれません。 デザイン思考の顧客インタビューは、この「なぜ」を補完します。チャーンした顧客の行動ログを見て「ステップ3で離脱が多い」ことはわかっても、「そのとき頭の中で何を考えていたか」はログに残らない。この「ログの隙間」に、最も価値あるOpportunityが埋まっていることが多い。 --- まとめ プロダクトロードマップの優先度付けは、「声が大きい順に並べる」でも「スコアの高い順に自動決定する」でもなく、顧客の問題を深く理解した上で、解くべきOpportunityを選ぶ意思決定です。 OSTで問いの構造を作り、Kanoモデルで価値の次元を分類し、HMW問いで発想を促し、RICEで評価する——この流れが、デザイン思考とプロダクト管理を統合する実践的なフレームです。 機能要望の積み上げを止めるには、「何を作るか」の議論より前に「誰の、どんな問題を解くか」を決める順序を、チームの習慣として設計することから始めます。 関連記事：デザイン思考とアジャイルの統合、ジョブ理論とデザイン思考の接続 --- 参考文献・出典 - Torres, T., "Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes," producttalk.org — https://www.producttalk.org/opportunity-solution-trees/ - Kano, N. (1984). "Attractive Quality and Must-Be Quality." Journal of the Japanese Society for Quality Control, 14(2), 39–48. - ProductPlan, "The Ultimate Guide to Product Management Prioritization Frameworks" — https://www.productplan.com/learn/product-management-frameworks - Roadmunk, "Product Prioritization Frameworks: The 9 Most Popular," 2024 — https://roadmunk.com/guides/product-prioritization-techniques-product-managers/ - Medium / Bootcamp, "Product Roadmaps with Teresa Torres' OST: A Practical Guide" — https://mohammadeskandari011.medium.com/a-roadmap-for-the-product-roadmap-terresa-torress-ost-in-action-1c9bc8eb530a --- ### デザイン思考で金融サービスを革新する——4社の実装パターンと測定可能なKPI設計 URL: https://designthinking.studio/articles/design-thinking-financial-services-4-cases/ > BBVA、ING、Capital One、みずほFGの4事例を共通プロセス・KPI・失敗パターンの3軸で解剖する。金融サービスにデザイン思考を根付かせるための、測定可能で再現可能な実装ガイド。 「ワークショップで盛り上がった付箋は、結局どこに消えるのか」——金融機関でデザイン思考を導入した担当者から、何度も同じ質問を受ける。プロセスは回した。インサイトも出た。だが事業のKPIに繋がる実感がない。 この問題は、金融に固有のものではない。しかし金融機関では特に深刻に表面化する。規制・リスク・意思決定チェーンの厚みが、デザイン思考の「素早い検証」と摩擦するからだ。 本稿は、海外と日本の4社——BBVA、ING、Capital One、みずほFG——を「共通プロセス」「KPI設計」「失敗パターン」の3軸で並べ、金融サービスでデザイン思考を機能させるための実装パターンを抽出する。 --- 4社が共通して通過した3つのフェーズ 業界・規模・国が違っても、デザイン思考を金融機関に根付かせた組織は、似通った段階を踏んでいる。 フェーズ1：単発プロジェクトでの実証（1〜2年） 最初は特定のサービスや顧客接点に絞ってデザイン思考を試す。ここで成功事例を1つ作ることが、組織内の懐疑論を黙らせる起点になる。 BBVAは2007年頃からデジタルバンキングのリニューアルを起点に、Capital Oneは2014年のAdaptive Path買収（後述）以降にカード申込フローのリデザインから始めている。重要なのは「全社展開」を最初から目指さないこと。組織変革のスケールに比例して必要な政治資本も増える。最初の1勝は、小さく確実に取りに行く。 フェーズ2：組織構造への組み込み（2〜4年） 単発プロジェクトの成果が認知されたら、デザイン思考を「特別な手法」ではなく「日常業務の一部」にする段階に入る。ここで多くの組織が壁にぶつかる。 INGの「スクワッド体制」（2015年〜の組織再編）、BBVAのGlobal Head of Designポジション設置、Capital Oneのインハウス・デザイン組織拡大——いずれも手法を導入するために組織構造そのものを変えた。デザイナー・エンジニア・プロダクトマネージャー・コンプライアンス担当者を同一チームに配置する設計が、サイクルタイム短縮の物理的前提になる。 フェーズ3：測定可能な成果指標の確立（3年目〜） ここが日本の金融機関で最もスキップされやすいフェーズだ。デザイン思考の成果を「定性的な顧客の声」だけで報告し続けると、経営層の予算配分の優先順位から外れていく。 定量指標と定性指標の両輪で測定する仕組みを早期に確立した組織だけが、長期的にデザイン思考の予算を維持できている。 --- BBVA：顧客ジャーニー起点のデジタル変革 BBVA（Banco Bilbao Vizcaya Argentaria、スペインを本拠地とするグローバル銀行）は、2007年前後から顧客体験設計の方法論としてデザイン思考を組織的に導入した先駆例の一つだ。 特徴的なのはデザイン組織を経営中枢に近い位置に置いた判断だ。Global Head of Designポジションを設け、カスタマーエクスペリエンス担当チームを戦略部門に組み込んだ。日本の金融機関に多い「デジタル推進部が外部ベンダーと連携してデザインする」構造とは根本的に異なる。 測定したKPI: - アプリストア評価スコア - 月間アクティブユーザー数（MAU） - デジタルチャネル経由の商品契約率 - 顧客満足度（NPS）の四半期推移 特に意識したのは「デジタル経由の契約率」だ。これは「使いやすいから使われる」を超えて「使った結果として収益に直結する」までを射程に入れた指標で、デザイン投資の事業貢献を経営に説明可能にする設計になっている。 --- ING：アジャイルとデザイン思考の構造統合 ING（オランダを本拠地とするグローバル金融機関）は、2015年から組織全体のアジャイル変革を実施した。デザイン思考はその中で顧客体験設計の方法論として組み込まれた。 INGが従来の機能別部門制を廃止し、「スクワッド」と呼ばれる小規模多機能チームに再編した点は、デザイン思考の文脈で重要な意味を持つ。コンプライアンス担当者がテストサイクルの外側にいない——法務的な確認がテストサイクルを遮断するのではなく、スクワッド内で並行して進む構造になった。 測定したKPI: - リリースまでのリードタイム（変革前後で大幅短縮） - スクワッド単位の顧客満足度 - 従業員エンゲージメント（組織変革の副次効果として） - プロダクトの市場投入速度 INGの取り組みの教訓として明確なのは、「手法を導入して組織が変わるのを待つ」のではなく「組織構造を先に変えることで手法が機能する環境を作る」という順序だ。デザイン思考の研修を全社員に受けさせても、組織構造が機能別のままでは、研修内容は週明けに蒸発する。 --- Capital One：デザインエージェンシー買収による内製化 Capital One（米国の大手金融機関、特にクレジットカード事業で知られる）は2014年10月、サンフランシスコのデザインコンサルティングファーム Adaptive Path を買収した。デザイン人材を一気に内部化する戦略的な動きで、金融業界のデザイン思考導入における転換点として記憶されている。 買収後、Capital Oneは「Capital One Studio」と呼ばれるデザイン組織を構築し、シカゴ・サンフランシスコ・ニューヨーク・ロンドンに拠点を持つグローバル組織へと拡張した。デザイン思考は単発のワークショップ手法ではなく、プロダクト開発の標準プロセスとして組み込まれた。 測定したKPI: - カード申込のオンライン完了率 - 申込フォーム途中離脱の段階別分布 - 顧客サポートへの問い合わせ件数（UI改善で減少を狙う） - A/Bテストによる仮説検証の実行数 Capital Oneのケースで注目すべきは、「問い合わせ件数の減少」を成功指標に置いたことだ。一見ネガティブな指標だが、「コールセンターに電話せずに済むUI」は顧客体験の質と運用コスト削減の両方に効く。デザインの事業貢献を多面的に測定する設計の好例だ。 --- みずほFG：日本市場での適用と若年層リサーチ みずほフィナンシャルグループは、デジタル戦略の一環として若年層向け資産形成サービスの設計にデザイン思考を活用した。日本の大手金融機関の中でも、ユーザーリサーチを起点にした設計プロセスを社外に公開している事例の一つだ。 特徴的なのは、「20代の本音」を引き出すリサーチ設計だ。インタビューで繰り返し現れたのは、「始め方が分からない」ではなく「始めていない自分への後ろめたさ」だった。このインサイトをHow Might Weの問いに変換した結果、サービス設計の方向が根本から変わった。 - Before: 「どうすれば若者が資産形成を始めやすくなるか」 - After: 「どうすれば"まだ始めていない"ことを後ろめたく感じさせずに、一歩目を踏み出してもらえるか」 測定したKPI（一般的な国内若年層向け金融サービスでの設計指標として）: - アプリ初期セットアップの完了率 - 最初の積立設定までの所要時間 - 30日後のリテンション率 - ヘルプ画面のアクセス頻度 「ヘルプ画面のアクセス頻度」が高い箇所を「設計が問いに答えていない場所」として特定する手法は、行動データを起点にしたUX改善の典型だ。 国内事例での具体的な「信頼の壁」の乗り越え方は、別稿のデザイン思考で金融サービス革新——顧客の「恥」を起点にした設計の現場で詳述している。 --- 4社に共通するKPI設計の3原則 業界横断的に有効な指標設計のパターンを抽出すると、以下の3つに集約される。 原則1：定量指標と定性指標を必ずペアにする 完了率・離脱率・MAUといった定量指標だけを見ると、「数字は良いが顧客の不満は溜まっている」という危険な盲点ができる。NPS・顧客インタビュー・カスタマーサポートのログ分析を組み合わせて、「なぜその数字になっているか」を説明可能にする。 原則2：先行指標と遅行指標を組み合わせる 契約数・収益は遅行指標（結果が出るまで時間がかかる）。エンゲージメント率・問い合わせ件数・UIの操作完了時間は先行指標。デザイン投資の効果は先行指標で素早く把握し、遅行指標で経営に報告するという二層構造が機能する。 原則3：「減らす」指標を必ず1つ持つ 問い合わせ件数の減少、エラー率の低下、サポートコストの削減——「増やす」指標だけでなく「減らす」指標を持つことで、デザインの運用コスト削減効果を可視化できる。経営層への説明では、増加だけでなく減少のストーリーが効くことが多い。 --- 金融機関のデザイン思考導入で起きる3つの失敗パターン 逆に、4社のいずれかが過去に直面したか、他の金融機関で頻繁に観察される失敗パターンを抽出する。 失敗1：ワークショップを「成果」と勘違いする ワークショップを実施した、付箋がたくさん貼られた、参加者の満足度が高かった——これらはプロセスの一部であって成果ではない。ワークショップの後にプロトタイプが作られ、テストされ、実装され、KPIが測定されるまでが「成果」だ。 組織内で「ワークショップを開催したこと」を成果報告として扱う文化が定着すると、デザイン思考は「楽しいイベント」として消費されて事業に繋がらなくなる。 失敗2：法務・コンプライアンスを後段に置く 「アイデアが固まってから法務に確認する」というプロセスは、金融機関では破綻する。差し戻された後の手戻りが大きく、結局「規制があるから無理」という結論で終わる。 INGのスクワッド体制が示したのは、コンプライアンス担当者を初期段階からチームの一員として組み込むという設計だ。「チェックする人」ではなく「一緒に作る人」のポジションに置く。これは ステークホルダーマッピング の段階で意図的に設計するべき構造的な配置だ。 失敗3：定性的な「顧客の声」だけで予算を維持しようとする 「顧客から良い反応をもらえた」という報告だけでは、3年目以降の予算が削られる。定量的な事業貢献を測定する仕組みを早期に確立しないと、組織変革の途中で失速する。 これは JTBD（Jobs To Be Done）とデザイン思考の統合 と組み合わせて考えるべき問題だ。顧客のジョブを起点にした指標設計が、定性と定量の橋渡しになる。 --- やってみよう——4社のパターンから持ち帰れる最初の一歩 - KPIシートを作る前に「減らす指標」を1つ決める — 「このプロジェクトで減らしたい数字は何か」を1つ明文化する。問い合わせ件数、解約率、エラー発生率——「減らす」を起点にするとUI設計の優先順位が明確になる。 - プロトタイプテストの前に法務担当者と15分話す — 「このプロトタイプは何のために、どこまで何を試すか」を法務に伝え、「どの形式なら可能か」を引き出す。法務を「壁」ではなく「制約条件を明らかにしてくれるパートナー」に位置付ける。 - ワークショップ後に「90日アクションプラン」を必ず作る — 出たアイデアを、誰が・いつまでに・どう検証するかを90日単位で具体化する。これがないとワークショップは「イベント」で終わる。 --- 特にこんな方へ 金融機関のDX推進部・デジタル戦略部の担当者、サービスデザイナー、UXデザインマネージャーで、「デザイン思考を導入したが事業KPIへの貢献が説明しにくい」と感じている人に、本稿の4社事例とKPI設計の3原則は直接役立てる。自社で再現可能なパターンとして事例を抽出すること——手法より先に、組織構造とKPI設計から手をつけてほしい。 --- 参考文献 - ING, "ING's agile transformation", ing.com, 2015〜（公式資料） - BBVA, "Design at BBVA", bbva.com（デザイン組織に関する公式コンテンツ） - Capital One, "Capital One Acquires Adaptive Path", press release, 2014年10月（公式発表） - Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence & Jakob Schneider, This Is Service Design Doing, O'Reilly Media, 2018 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - Nielsen Norman Group, "Design Thinking in Finance: Challenges and Opportunities", nngroup.com --- ### デザイン思考で金融サービスを革新する｜Bank of America事例と実装の要点 URL: https://designthinking.studio/articles/design-thinking-financial-services-innovation/ > IDEOとBank of Americaの共同プロジェクト「Keep the Change」を中心に、金融サービス領域へのデザイン思考適用の構造を解説。観察から仮説生成、プロトタイプ検証、段階的ロールアウトまでの実践的プロセスと、金融業界固有の制約を乗り越えるための考え方を示す。 金融機関でデザイン思考を適用しようとするとき、現場から必ずと言っていいほど同じ反応が返ってくる。「規制があるから無理だ」「金融商品はデザインとは違う」「顧客調査なら既にマーケティング部がやっている」。 これらの懸念は理解できる。ただ、同じ業界で実際に機能した事例がある。2004年にIDEOがBank of Americaと共に取り組んだプロジェクトは、その後の金融サービス設計に対する見方を変えた。 --- 「Keep the Change」の背景 2004年、Bank of AmericaはIDEOに依頼を出した。目的は新規顧客の獲得と貯蓄口座への誘導だ。一般的なマーケティングアプローチなら、金利優遇キャンペーンや口座開設特典を設計するところだろう。IDEOが選んだのは違う入り口だった。 アトランタ、ボルティモア、サンフランシスコの3都市で、育児中の女性を中心に家計管理に関するインタビューと行動観察を実施した。IDEOのデザイナー4名とBank of Americaのスタッフ5名がチームを組み、ユーザーの自宅での行動を観察した。 観察から浮かび上がったのは予想外のパターンだった。多くの女性が、小銭をジャーに入れて貯める習慣を持っていた。意識的な節約ではなく、「おつりを財布に入れるのが煩わしい」という小さな日常の所作が、自然と貯蓄行動になっていた。 このインサイトから導かれた仮説は「支払いのたびに小銭を自動的に貯蓄口座に移せたら、貯蓄習慣を持てない人でも貯められるのではないか」だった。 --- プロトタイプから実装へ 仮説を検証するため、IDEOはカートゥーン動画でサービスの概要を説明するコンセプト動画を制作した。まだ実際の機能は存在しない。この映像を顧客に見せ、反応を確認した。フィードバックをもとにオーバードラフト保護機能が追加され、報告の詳細度が調整された。 最終的な仕組みはシンプルだ。デビットカードで支払うたびに、端数を切り上げた差額が普通預金口座に自動転送される。300円の支払いが400円として処理され、差額100円が貯蓄に回る。 「Keep the Change」として2005年に導入されたこのプログラムは、3年後の2008年時点で250万人以上の顧客を獲得し、100万件以上の新規貯蓄口座を開設した（Bank of America公表データ）。IDEOのTim Brownは「ユーザーは『釣り銭を取っておく機能が欲しい』とは言えない。でも行動を観察すれば、そのニーズは見えてくる」と当時を振り返っている。 --- 金融サービス特有の制約と設計上の工夫 金融機関でデザイン思考を適用するとき、他の業界にはない制約が伴う。 規制と法的要件: 金融商品の設計には監督当局の認可が必要な場合がある。プロトタイプ段階から法務・コンプライアンス担当を設計チームに組み込む体制が、後工程での手戻りを減らす。「できないこと」を最初から知ることで、制約の中での創造性が発揮されやすくなる。 信頼とリスク知覚: 金融サービスのユーザーテストでは、感情的な反応として「不安」「不信」が想定以上に頻出する。デザイン思考のプロトタイプ検証でDesirability Testingを組み合わせると、機能的な使いやすさと信頼感の両軸でフィードバックを収集できる。 段階的なロールアウト: Bank of Americaは全国展開前に一部店舗でパイロット運用を実施した。デザイン思考のプロセスで言えば、「テスト」フェーズを実際の小規模市場で行う構造だ。完全なプロトタイプを全顧客に一度に提示するのではなく、学習しながら拡大する姿勢が金融サービスの導入リスクを下げる。 --- 日本の金融機関への示唆 Bank of Americaの事例から何を学べるか。少なくとも3点ある。 観察の対象を変える: 既存の市場調査は多くの場合、「何を望むか」をアンケートで問う。しかし実際の行動と申告した行動は乖離することが多い。Bank of Americaの成功の核心は、人々が「すでにやっていること」から新しいサービスの種を見つけた点にある。 機能より行動を起点にする: 「貯蓄口座の新機能」ではなく「貯蓄という行動をどうすれば楽にできるか」という問いの立て方が、発想の幅を変えた。機能の拡張から考え始めると、ユーザーの実際のメンタルモデルから離れやすい。 小さく始めて検証する: 完全な商品を開発してから市場投入するのではなく、映像レベルのコンセプト検証から始めた点は、デザイン思考の「早く安く失敗する」という原則の実践だ。金融サービスはシステム開発コストが高いため、プロトタイプを実際のシステムに頼らずに検証する創意工夫が特に重要になる。 --- どこから始めるか 金融機関でデザイン思考を導入するとき、最初のステップは観察の機会を設けることだ。支店のカウンター周辺での顧客行動、ATM操作時の逡巡、スマートフォンアプリを開いて閉じるまでの動作——こうした小さな行動の観察から、想定外の「すでにやっていること」が見えてくる場合がある。 Bank of Americaが発見したのは、「おつりを瓶に入れる」という古い行動だった。デジタル時代の金融サービスにも、見過ごされている行動の種は存在する。それを見つけるために、まずユーザーの日常の中に入ることから始まる。 --- ### デザイン思考で金融サービス革新——顧客の「恥」を起点にした設計の現場 URL: https://designthinking.studio/articles/design-thinking-financial-innovation/ > 金融機関がデザイン思考を導入するとき、何がうまくいって何が壊れるか。SBIやみずほの事例から、金融特有の「信頼の壁」を越えるユーザーリサーチの実践論。 金融機関のワークショップに入ると、必ずと言っていいほど同じ光景がある。付箋が貼られた壁、「顧客目線で」というスローガン、そして一向に埋まらない「顧客の本音」の欄。 金融サービスにおける最大の設計難題は、顧客が本音を語らないことにある。 ローン審査の不安、資産運用の失敗談、保険の「なんとなく入っている」感——これらはインタビューの場では出てこない。社会的な恥の感覚が、調査の精度を根本から下げる。 この問題に向き合わずに「ユーザー中心設計」と言っても、実態は自社目線のままだ。 金融特有の「信頼の壁」とは何か 2022年から2024年にかけて複数の国内大手金融機関が、デザイン思考を用いたサービス改革プロジェクトを進めた。Goodpatchが公開したフィンテック向けデザインプロセスの事例をはじめ、みずほFGのデジタル戦略チームが導入したサービスデザイン手法、SBI証券がネット証券UIの刷新時に実施したユーザーリサーチが、それぞれ異なる「発見」を生んでいる。 共通して浮かび上がったのは、「金融の文脈では、ユーザーが合理的ではない」という事実だ。 家計の見直しを求められると多くの人は「やっています」と答える。投資の失敗を聞かれると「そんなに大きな影響はなかった」と答える。保険の必要性を問われると「必要なものに入っている」と答える。しかし実際のお金の使い方を1ヶ月観察すると、答えとまるで異なる行動パターンが見えてくる。 これは嘘をついているのではない。金融に関する話題には、語ること自体への心理的コストがある。「お金に無頓着」「将来の備えが甘い」という評価を恐れる感情が、インタビューの言語を歪める。 共感フェーズの設計を変えた：「恥」からの出発 SBI証券がUIリニューアルで採用した手法に、「財務行動観察」がある。従来の「どんな機能が使いやすいですか」という質問形式を廃止し、代わりにユーザーの証券口座の実際の操作履歴（匿名化）をもとにインタビューを設計した。 「このタイミングで買っていますね。何を考えていましたか」という問いは、抽象的な「あなたの投資スタイルは？」より遥かに深い回答を引き出す。実際の行動を起点にすることで、ユーザーが「語りやすい物語」ではなく「起きたこと」を話す場を作った。 ワークショップでよく起こるのは、インタビューガイドを「質問リスト」として設計してしまうことだ。金融ユーザーリサーチにおいては、質問よりも「見せる」「思い出させる」設計のほうが機能する。ユーザーの過去のアクションをスクリーンに映して「このときどういう状況でしたか」と問うと、感情の記憶が先に出てくる。 問題定義フェーズ：「不便」ではなく「恥」が本質だった 観察とインタビューを重ねた複数プロジェクトが共通して辿り着いた問題定義は、「操作が難しい」ではなかった。「金融サービスを使うこと自体に、ユーザーは自信のなさを感じている」というインサイトだった。 みずほFGのデジタル戦略チームが取り組んだのは、若年層向け資産形成サービスの設計だ。20代のユーザーインタビューで繰り返し現れたのは、「始め方が分からない」ではなく「始めていない自分への後ろめたさ」だった。 このインサイトを How Might We の問いに変換すると大きく変わる。 - Before: 「どうすれば若者が資産形成を始めやすくなるか」 - After: 「どうすれば"まだ始めていない"ことを後ろめたく感じさせずに、一歩目を踏み出してもらえるか」 この問い直しが、サービス設計の方向を根本から変えた。"入口の障壁を下げる" から "入口の心理的安全を設計する" へのシフトだ。アプリの初期画面から「おすすめポートフォリオ」の提示を廃止し、「今の状況をまず整理しましょう」というフローに変更した。完了率が大幅に改善したとされている。 創造フェーズの現場：金融では「できない」アイデアが多い ブレインストーミングに金融機関のメンバーを混ぜると、「それは規制上できない」「コンプライアンスが通らない」という声が早期に出る。これはイデエーション（創造フェーズ）の天敵だ。 実際にやってみると効果的だったのは、「今日は規制も予算も存在しない世界で考える」という明示的なルール設定だ。ただし「まったく自由に」では金融機関のメンバーは動けない。「銀行業務の本質（お金の安全な移動と増殖）は変えない。それ以外の手段はすべて白紙にする」という条件を加えると、思考が動き始める。 SBIのプロジェクトでは、このセッションから「投資の社会的承認」という概念が生まれた。「友人が始めたから自分も」という行動パターンを設計に組み込む、ソーシャルインベスティングの原型だ。当初は「規制上難しい」として保留されたが、後に「投資クラブ」機能として制約内で実装された。アイデアの評価は収束フェーズで行う。発散フェーズでの早期評価はイノベーションを殺す。 プロトタイプフェーズ：「信頼」は紙で試せる 金融サービスのプロトタイピングで特殊なのは、「信頼」という非機能要件がデザインの中核を占めることだ。操作のフローより先に、「このサービスを信頼できるか」という判断が下る。 Goodpatchが金融クライアント向けに繰り返し使う手法は、「信頼プローブ」と呼ばれる低忠実度プロトタイプだ。実際の機能を持たない紙のモックアップを見せ、「このサービス、実在するとしたら口座を開設しますか」と問う。YESと答えたユーザーに「何を見てそう判断しましたか」を聞く。NOと答えたユーザーに「何があれば判断が変わりますか」を聞く。 多くのワークショップ実践で繰り返し観察されるのは、金融ユーザーの信頼判断が「情報量」ではなく「情報の整理方法」に反応するという事実だ。情報が多いサービスは「難しそう」と判断され、情報が少ないサービスは「怪しい」と判断される。この逆説的な区間を突破するには、「必要な情報が、必要なときに、予測可能な場所に出てくる」というUX設計が欠かせない。 テストフェーズ：数値目標より「恥の解消度」を測れ 金融サービスのテストで多くのチームがつまずくのは、コンバージョン率やタスク完了率だけを成功指標にすることだ。これらの指標は「機能するか」は教えてくれるが、「選ばれるか」「使い続けられるか」は教えてくれない。 有効な補完指標として、複数の金融プロジェクトで採用されているのが「感情的摩擦スコア」だ。ユーザーテストの各ステップで「この操作をしているとき、どんな気持ちでしたか（1〜5段階）」を測定し、感情的に負荷がかかる箇所を可視化する。タスク完了率が高くても、感情スコアが低いフローは解約率に直結することが複数事例で確認されている。 「使えたが、嫌だった」という体験を設計から消すことが、金融サービスにおけるCX設計の本質だ。 やってみよう：金融機関が今週から始められること デザイン思考の導入に大型プロジェクトは必要ない。以下のアクションは、リソースの制約が大きい金融機関でも実行可能だ。 - 「離脱したユーザー」に電話をかける 口座開設を途中でやめたユーザー、解約したユーザーにコンタクトして15分のインタビューをお願いする。謝礼は500円分のギフトコードでも十分だ。「なぜやめましたか」ではなく「その日、どんな状況でしたか」から聞く。 - コールセンターのログを「感情マップ」にする 問い合わせ内容を「怒り」「困惑」「不安」「確認」に分類し直す。機能別の集計ではなく、感情別の集計をすることで、ユーザーが何を「怖れているか」が見えてくる。 - 競合サービスをユーザーとして1時間使う 自社の担当者が競合口座を開設し、最初の操作を記録する。「どのタイミングで信頼した/不信感を持ったか」を5分ごとに書き留める。比較ではなく、自分の感情変化の観察が目的だ。 特にこんな方へ 金融機関のDX担当者で「ユーザー中心設計を導入しようとしているが、成果が見えにくい」と感じている人、金融サービスのUXデザイナーで「数値指標だけでは説明しきれない体験の問題がある」と感じている人に、この記事のアプローチが直接役立てる。「顧客目線」をスローガンで終わらせないための、具体的な問いと手法が揃っている。 --- 金融サービスのデザイン思考は、他業界に比べて「見えにくい問題」を扱う。操作の難しさより先に、お金にまつわる感情的な地雷を踏まないインタビュー設計が求められる。この難しさは、同時にチャンスでもある。競合他社が「機能の改善」で競っているうちに、感情設計の深さで差をつける余地が、金融領域には特に大きい。 --- ### デザイン思考で組織変革を進める5ステップ——着手順と、つまずく分岐点 URL: https://designthinking.studio/articles/design-thinking-org-change-practical-guide/ > デザイン思考で組織変革に着手するとき、何から始めてどの順に回すか。200回以上のワークショップで繰り返し観察された5つのステップと、各ステップでつまずく分岐点を手順に絞って解説します。全体像は組織変革の完全ガイドへ。 「デザイン思考で組織を変えたい」という声は、ここ数年で急速に増えた。しかし「どのように進めればよいか」という具体的な手順を問うと、答えに詰まる担当者が多い。 研修を実施したのに現場が変わらない。ワークショップで熱量が生まれたのに3週間後には元通り。組織変革とデザイン思考の組み合わせが機能しない時、原因はほぼ例外なく「導入の設計」にある。 本記事では、200回以上のワークショップで繰り返し観察されてきた成功パターンを5つのステップに整理して解説する。 この記事は進め方（手順）に絞っている。3年スパンの全体設計はデザイン思考 組織変革の完全ガイド（3年ロードマップ）にまとめてある。 --- なぜ「デザイン思考 × 組織変革」は難しいのか ワークショップと日常業務の断絶問題 ワークショップでよく起こるのは、参加者が「素晴らしかった、これを職場で使いたい」と語りながら、月曜日の朝には通常業務のモードに完全に戻ってしまう現象だ。 これは意志の問題でも参加者の問題でもない。「ワークショップモード」と「日常業務モード」の間に設計された橋がないことが問題だ。 実際にやってみると、この断絶を生む構造は明確だ。ワークショップでは「失敗を歓迎する」と言いながら、翌週の評価面談では「失敗を報告する」という矛盾した環境に人は置かれている。環境が変わらない限り、行動は変わらない。 組織変革に必要な3つの同時変革 組織変革の研究（Kotter, 1996）が繰り返し示しているのは、スキル・プロセス・文化の3つを同時に変えなければ変革は定着しないという事実だ。 多くの企業がスキル研修（Level 1）だけを実施して「導入完了」と判断している。しかしデザイン思考的な行動が評価されない制度（Level 2）、失敗を歓迎しない空気（Level 3）が変わらない限り、スキルは使われない。 デザイン思考 組織変革の完全ガイドでは、3年間の変革設計について詳しく解説している。本記事は「どのステップで何をするか」の具体的な行動手順に焦点を当てる。 --- 5ステップ実践ガイド Step 1: 変革の「問い」を立てる — 目的から始める 最初に問うべきことは「デザイン思考を導入する」ではなく「何のために、誰の問題を解決するのか」だ。 よくある失敗: 「デザイン思考を導入する」が目的化している ワークショップでよく起こるのは、「デザイン思考の研修を年2回実施する」という活動目標が、「顧客起点の組織をつくる」という本来の目的に置き換わってしまうケースだ。手段と目的が逆転した瞬間、変革は形骸化する。 実践の手順: まず「変革の対象となる問題」を1つ特定する。「顧客の声が製品設計に届いていない」「新規事業のアイデアが承認に通らない」「異なる部門がバラバラに動いていて全体最適ができていない」など、具体的な問題を一文で記述する。 次に、その問題が「誰にとっての問題か」を明確にする。社内の意思決定者にとっての問題と、現場担当者にとっての問題と、顧客にとっての問題は、しばしば異なる。 三者の問題定義を並べて比較することが、変革のスコープ設計の出発点になる。 この段階でもエンパシーマップが有効だ。変革の対象となる組織メンバー自身を「観察すべきユーザー」として扱い、彼らが何を考え、何を感じ、何に困っているかを可視化する。 Step 2: 小さく始めるパイロットプロジェクトを設計する 「全社」「全部門」から始めようとすると、ほぼ必ず失敗する。スコープが広いほどステークホルダーが増え、合意に時間がかかり、結果が出るまでの期間が延びる。 成功するパイロットの条件: - 規模: 5〜8名、1〜3ヶ月で結果が見えるスコープ - 権限: 意思決定者がチームに含まれている（または近い） - 問題: 「失敗しても組織へのダメージが限定的」な課題 - 指標: 成功の定義が事前に数値化されている 実際にやってみると、パイロットで最も重要なのは「何が起きたかを組織全体に見えるようにする設計」だとわかる。素晴らしい成果が出ても、それが組織内で共有されなければ次のフェーズに進む勢いが生まれない。 具体的な「可視化」の手段: - 週次の進捗をSlackやイントラで全社公開する - ユーザーインタビューの動画（要許可）を社内で共有する - プロトタイプのデモをオープンな場で実施する - 「学んだこと」レポートを定期的に発行する Step 3: ファシリテーション — 5フェーズを現場で動かす デザイン思考の5フェーズ（共感→定義→創造→プロトタイプ→テスト）を、組織変革のプロセスとして運用する時の、各フェーズの具体的な動かし方を整理する。 共感フェーズ（Empathize）: 変革の対象者をユーザーとして理解する 組織変革文脈での共感は「変革に関わる人たちの体験を理解する」ことだ。現場担当者が「なぜ今の方法に固執するのか」「変化に抵抗する本当の理由は何か」を、批判せずに理解する。 インタビューは1対1で実施する。会議室ではなく、実際の業務現場で話を聞く。「改善点はありますか」という質問ではなく「今日の業務で一番大変だったことは何ですか」という問いかけから始めることで、本音に近い声が出てくる。 定義フェーズ（Define）: インサイトから「How Might We」を作る インタビューで集めた情報から、「本当の問題」を定義する。この段階で使うのがアフィニティ・ダイアグラムだ。個々の発言をカード（付箋）に書き出し、似たものをグループ化することで、表面的な問題の背後にある構造的な課題が浮かぶ。 「How Might We（どうすれば〜できるか）」の問いを作ることが定義フェーズのゴールだ。「情報共有が遅い」という問題に対して「どうすれば現場の知識が翌日までに意思決定者に届く仕組みをつくれるか」という問いに変換することで、創造フェーズへの橋渡しができる。 創造フェーズ（Ideate）: 量から質へ ブレインストーミングで「質より量」を強調しすぎると、かえって実用的なアイデアが出にくくなるという逆説がある。「5分で20個のアイデアを書く」という制約を設けることで、自己検閲が働く前にアイデアが出てくるという現象がワークショップで繰り返し観察されている。 組織変革の文脈では「すぐ実施できること」「3ヶ月以内に結果が出ること」「1年以上かかるが根本的な変革」という3つの時間軸でアイデアを分類する方法が効果的だ。 プロトタイプフェーズ（Prototype）: 「考えた」を「試した」に変える 組織変革のプロトタイプは、物理的なモノである必要はない。ロールプレイ（ある会議の進め方を試しにやってみる）、モックアップ（新しい評価シートのフォーマットを作ってみる）、サービスサファリ（提案している新しいプロセスを実際の業務で1日試してみる）など、「低コストで試せる形」を選ぶ。 ワークショップでよく起こるのは、プロトタイプを「完成品として発表する場」と誤解するケースだ。プロトタイプは「壊すために作る」ものであり、ユーザーが使いながら問題点を発見するための道具だ。 テストフェーズ（Test）: 観察から学ぶ テストで最も重要なのは「ユーザーの行動を観察すること」だ。言葉ではなく行動を見る。「使いやすかったですか」という質問に「はい」と答えた後、実際には3回同じ箇所で迷ったというケースはよく起きる。 観察したことは「そのままの言葉・行動」で記録する。解釈は後でよい。まず事実を蓄積することが、正確なインサイト抽出の前提になる。 Step 4: 変革を「仕組み」に組み込む パイロットで成果が出た後の最大の関門は「仕組みへの組み込み」だ。成功体験を一回限りのイベントで終わらせないために、業務プロセスへの統合が必要になる。 仕組み化の具体例: - 新規プロジェクト開始時の「ユーザーリサーチ実施」を必須ステップとして定義する - 月次レビューに「ユーザーフィードバック共有」のアジェンダを固定で追加する - 承認プロセスに「プロトタイプ検証の有無」を審査項目として加える - 「学んだこと共有」の場を定期的に設ける（失敗も含めて） 評価制度との整合（最重要ポイント） 参加者からの声として「評価制度を変えなければ定着しない」という言葉は、様々な規模・業種の組織から繰り返し聞かれる。デザイン思考的な行動（ユーザーインタビューに時間を使う・失敗から学ぶ・プロトタイプを作って捨てる）が評価されない限り、継続する動機が生まれない。 少なくとも、現行の評価項目に「ユーザー視点での提案」「実験と学習の実績」「部門横断的な協力」の観点を加えることが最低ラインになる。 Step 5: 文化の変化を測定する 文化の変革は「測定しにくい」という前提で諦められることが多い。しかし具体的な行動の変化を観察することで、文化の変化を間接的に計測できる。 行動の変化指標（例）: | 指標 | 計測方法 | 目標値 | |---|---|---| | ユーザーリサーチ実施率 | 新規プロジェクト数のうちリサーチを実施した割合 | 初年度30%→3年目70% | | プロトタイプ検証実施率 | 本開発前にプロトを作ったプロジェクトの割合 | 初年度20%→3年目60% | | 社内「インタビュー実施者」数 | 四半期ごとにユーザーインタビューを実施した人数 | 四半期ごとに集計 | | 「学んだこと共有」参加率 | 開催数のうち参加者が出た回の割合 | 80%以上 | 文化変革の兆候として観察すべきこと: ワークショップでよく起こるのは、「文化が変わった瞬間」が後から振り返ると明確に特定できることだ。「ユーザーに確認しましたか」という問いが、会議で上司から自然に出るようになった時。プロジェクト開始時に「まずプロトタイプを作ろう」という声が現場から上がるようになった時。これらの「自然な問いかけ」の変化が、文化変革の最も信頼できる指標になる。 --- 失敗を避ける3つの判断基準 判断基準1: 「手法ありき」になっていないか 「今週は共感フェーズをやる日です」という設計は危ない。手法の実施が目的化した時、インサイトの質は急落する。 「何を学ぶためにこの手法を使うのか」という問いを常に先に立てること。 判断基準2: 「経営層のコミットメント」は本物か 経営層が「デザイン思考をやれ」とトップダウンで指示した後、現場に丸投げするパターンは失敗確率が高い。「学習と実験の時間を保護する」という明示的なコミットメントを経営層から引き出せているかどうかが、大きな分岐点になる。 判断基準3: 「デザイン思考専門チームの孤立」を防げているか 「デザイン思考チーム」を設置し、そのチームだけが実践するモデルは長続きしない。デザイン思考のスキルを全部門に分散させ、専門チームはサポート役に徹するという設計が持続可能だ。 --- まとめ：変革の5ステップを振り返る - 問いを立てる — 「デザイン思考導入」ではなく「解決すべき問題」を特定する - 小さく始める — パイロットで成功事例を作り、組織内で可視化する - 5フェーズを動かす — 共感→定義→創造→プロトタイプ→テストの循環を回す - 仕組みに組み込む — 業務プロセスと評価制度を変える - 行動の変化を測定する — 文化の変化を間接的に計測する 組織変革は3年かかるプロセスだ。しかし最初の6ヶ月で小さな成功体験を作り、それを組織内で可視化できれば、次の2年半は加速するというのが、多くの現場から観察されるパターンだ。 「まず1つの問題に絞り、5〜8名のチームで、3ヶ月で結果が見えるスコープで始める」という原則を守ることが、遠回りのように見えて最速のルートになる。 --- 関連記事 - デザイン思考ファシリテーター育成：組織内ケイパビリティ構築ガイド — 外部依存から脱却し、社内ファシリテーターを段階的に育てる4ステップ - デザイン思考 行政サービス改革｜市民中心の公共設計7つの実践 — GDS・ヘルシンキ市・デジタル庁の事例から学ぶ組織変革の実例 - AI時代に人間の創造性はどこへ向かうのか — デザイン思考が問い直す「考えること」の本質 --- 参考文献 - Liedtka, Jeanne, "Why Design Thinking Works," Harvard Business Review, September–October 2018 - Kotter, John P., Leading Change, Harvard Business School Press, 1996 - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015 - d.school (Stanford University), bootcamp bootleg, Stanford University, 2010 - Brown, Tim, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 --- ### デザイン思考で変わる法律サービス：リーガルデザインの実践事例 URL: https://designthinking.studio/articles/design-thinking-legal-services/ > 法律業界にデザイン思考を適用するリーガルデザインの最前線。Stanford Legal Design LabやAccess to Justice運動など、非弁護士ユーザーを中心に置いたサービス革新の具体例を解説する。 法律サービスは長らく「専門家のための専門家の言語」で設計されてきた。契約書、裁判所の書類、利用規約——それらは法的リスクを最小化するために最適化されているが、実際にそれを読み、使うエンドユーザーのことは考慮されていない。 この構造的矛盾に正面から向き合うのがリーガルデザイン（Legal Design）だ。デザイン思考の手法を法律の世界に持ち込み、法的サービスを利用者中心に再設計する動きが世界各地で広がっている。 リーガルデザインとは何か リーガルデザインとは、デザイン思考・UXデザイン・人間中心設計の原則を法律の文脈に適用するアプローチだ。弁護士、デザイナー、テクノロジスト、福祉従事者が協働し、「法的に正確で、かつ使いやすい」サービスや文書を生み出すことを目指す。 フィンランドの法律研究者Helena Haapioは契約の視覚化と平易化を長年研究してきた第一人者であり、Stanford Law SchoolのMargaret Haganはデザイン思考を法律実務に応用する研究を主導する。両者はリーガルデザインを「人々が法律をより良く理解し、使いこなせるようにするための、体系的な人間中心アプローチ」と位置づけ、それぞれ著作や論文を通じてその方法論を発信してきた。 なぜ法律サービスにデザイン思考が必要か 法律サービスが抱える本質的な課題は、Access to Justice（司法へのアクセス）ギャップにある。法的な問題を抱えながら、費用・複雑さ・心理的障壁のために適切なサポートを受けられない人が世界中に存在する。 デザイン思考のEmpathize（共感）フェーズでこの問題に向き合うと、浮かび上がるのは次のような具体的な声だ。 - 「契約書に書いてあることの意味がわからない」 - 「裁判所の書類の書き方がわからなくて、手続きを諦めた」 - 「弁護士に依頼する費用が払えない」 これらはすべて、サービスの「ユーザビリティ」の問題だ。情報が複雑すぎ、アクセスポイントが少なく、ユーザーのメンタルモデルと合っていない。デザイン思考のプロセスはこの種の問題に対して特に有効で、「人が実際にどう使うか」を起点に設計をゼロから問い直す。 Stanford Legal Design Lab の実践 リーガルデザインの世界的拠点として知られるのが、Stanford Law SchoolのLegal Design Labだ。Margaret Haganが率いるこの研究所は、デザインとテクノロジーを活用して法律サービスの再設計に取り組んでいる。 同ラボが中心的に取り組むのが、裁判所の書類や手続きの可視化だ。弁護士を雇えない自己申告型の裁判所利用者（Self-Represented Litigants）向けに、フローチャートやインフォグラフィックを用いた手続きガイドを開発してきた。 このプロセスはデザイン思考の5段階に忠実だ。 - Empathize（共感） 裁判所を実際に訪れる自己申告型利用者を観察・インタビューし、つまずきポイントを特定する。「書類のどのページで迷うか」「どの用語で手が止まるか」を詳細にマッピングする。 - Define（定義） 「情報過多による理解断念」という核心的問題を明確にする。単に「書き直す」のではなく、「理解のプロセス自体を設計する」という問いに転換する。 - Ideate（発想） 視覚化・簡略化・段階的ガイドという解決策群を発散させる。Q&A形式、タイムライン表示、チェックリスト、チャットボットなど多様なフォーマットを検討する。 - Prototype（試作） 紙ベースのフォームやデジタルウィザードの試作版を作る。完成度よりスピードを優先し、早期にフィードバックを得る。 - Test（テスト） 実際の利用者に使ってもらい、理解度・完了率・操作の詰まりを計測する。観察結果を次のプロトタイプに反映するサイクルを回す。 Legal Design Labのアプローチは、法的な正確性を担保しながらユーザビリティを高めるという、従来は相反するとされてきた要件を実践の中で両立してきた。 ビジュアル契約の台頭 法律文書の設計において最も革新的な動きのひとつがビジュアル契約（Visual Contracts）だ。従来の密な文字の塊を、図解・タイムライン・チェックリストで構成された視覚的ドキュメントに変換するアプローチだ。 南アフリカの弁護士Robert de Rooyが提唱したビジュアル契約の概念は、北欧の法律事務所やB2B企業間の取引実務に浸透しつつある。契約内容のビジュアル化は、両当事者の理解度を高め、将来の紛争リスクを下げることが複数の実践報告で示されている。 World Commerce & Contracting（旧IACCM）はContract Design Pattern Libraryを公開し、ビジュアル契約の設計パターンを体系化する取り組みを進めている。これはデザインシステムのコンポーネントライブラリを法律文書の世界に持ち込んだ試みと言える。 ビジュアル契約が特に効果を発揮するのは、契約当事者間のリテラシー差が大きい場面だ。雇用契約、賃貸借契約、消費者向けサービス規約——いずれも従来の法律文書では「読まれない・理解されない・守られない」という問題が慢性化している。 大手法律事務所のデザイン思考導入 大手法律事務所もリーガルデザインへの投資を本格化させている。 DLA Piperは独立型の弁護士プラットフォームであるPeerpointを立ち上げ、法律サービスの提供形態そのものを再設計した。従来のパートナーシップモデルに縛られない柔軟な法律サービスを実現するこの取り組みは、クライアントが何を求めているかを起点に設計されている。 Clifford ChanceはAIを活用したナレッジツールを開発し、複雑な法的手続きのガイドをクライアントが自己解決できるフォーマットで提供する取り組みを進めている。 これらの事例に共通するのは、「法律の専門知識をクライアントに届ける方法」を、サービスデザインの問いとして捉え直した点だ。従来の法律事務所が「何を提供するか」（法的アドバイスの質）に注力してきたとすれば、リーガルデザインの視点は「どのように届けるか」（サービスのデザイン）を正面に据える。 Legal Design Alliance のコミュニティ Legal Design Alliance（LD Alliance）は、リーガルデザインの実践者・研究者・法律家が集まる国際的なコミュニティだ。世界各地のリーガルデザイナーをつなぎ、実践知の共有とケーススタディの蓄積を進めている。 同コミュニティでは、デザイン思考の各フェーズを法律サービスの文脈に具体的に翻訳したガイドラインや、ワークショップのファシリテーション手法が活発に議論されている。 Access to Justice 運動との接続 リーガルデザインは、社会的使命としてのAccess to Justice運動とも深く結びついている。 米国ではアメリカ法曹協会（ABA）がA2J Initiativeを推進し、自己申告型裁判所利用者向けのインターフェース改善や法律情報の平易化に取り組んでいる。このプロジェクトにはUXデザイナーや情報設計の専門家も参加している。 EU圏でもデジタル法律支援サービスの開発が進んでおり、複雑な行政手続きをシンプルなデジタルワークフローに変換する取り組みが各国で行われている。共通するアプローチは、法律の専門家ではなく市民（エンドユーザー）の行動観察から設計を始めることだ。 保険業界への展開 リーガルデザインの手法は、保険業界の約款改革にも応用されている。保険約款は法的に精緻に書かれているが故に一般消費者には理解不能な代表例だ。 英国金融行動監視機構（FCA）は保険約款の平易化と視覚化を促進する規制方針を打ち出しており、デザイン思考を通じた保険文書の再設計が業界課題となっている。一部の保険会社はUXライターとデザイナーを法務チームと協働させ、約款を「使えるドキュメント」に変換する実験を進めている。 日本への示唆 日本においても、法律文書のユーザビリティ改善は急務だ。労働契約書の理解不足に起因するトラブル、利用規約の形骸化、行政手続きの複雑さ——いずれもリーガルデザインが直接対応できる問題だ。 スタート地点として有効なのは、「誰が、どのような状況でこの文書を読むのか」を徹底的に観察することだ。法律の正確さを担保しながら、情報の構造・視覚的階層・用語レベルを最適化する。弁護士とUXデザイナーが協働するワークショップから、具体的な改善の糸口が見えてくる。 デジタル化が進む中、法律文書もデジタルファーストで設計される時代に移行しつつある。PDFの長文を入力するだけでなく、ウェブアプリ上でのインタラクティブな契約プロセスや、段階的に開示される情報設計が、次世代のリーガルデザインの舞台になる。 まとめ リーガルデザインは「誰が、どのような状況でこの文書を読むのか」という問いから始まる。法律の正確さを保ちながら、情報の構造・視覚的階層・用語レベルを最適化する——その実践は、法律の専門性とデザインの知見を横断する学際的な作業だ。 Stanford Legal Design Lab、ビジュアル契約の実務、Legal Design Alliance、Access to Justice運動——それぞれの現場で積み重ねられてきた知見が示すのは、「使われない正確な法律文書」より「理解されるシンプルな法律文書」の方が、当事者の権利を実質的に守るという事実だ。 --- ### デザイン思考とWicked Problems｜「邪悪な問題」への実践的対処法 URL: https://designthinking.studio/articles/design-thinking-wicked-problems-application/ > Wicked Problems（邪悪な問題）とは何か、なぜデザイン思考がその解法として有効なのかを解説。リチャード・ブキャナンの理論的枠組みから200回以上のワークショップで得た現場知見まで、実践者のための具体的アプローチを体系化する。 「この問題、どう解けばいいか分からない」——実務の現場でデザイン思考を学んだ人が最初に感じる壁がここにある。手法は知っている。しかしそれを当てはめようとした瞬間、問題が思っていたよりずっと複雑で、手法が滑っていく感覚を覚える。 その感覚には名前がある。Wicked Problems（邪悪な問題）だ。そしてデザイン思考は、この種の問題に向き合うために設計された思考様式だ。 Wicked Problemsとは何か 「Wicked Problems（邪悪な問題）」という概念は、都市計画家のホスト・リッテル（Horst Rittel）と建築家のメルヴィン・ウェバー（Melvin Webber）が1973年の論文 Dilemmas in a General Theory of Planning で提唱した。彼らが「邪悪」と呼んだのは、道徳的な意味ではなく、解決を拒む構造的な特性を指す。 リッテルとウェバーは10の特性を挙げているが、実務で特に重要な特性は以下の3つに集約される。 問題の定義が解決策に依存する。貧困問題を「収入の不足」として定義するか「機会の欠如」として定義するかによって、解決策は全く異なる。そして問題の正しい定義は、解決策を試みた後にしか分からない。問題と解決策が循環しているのだ。 唯一の「正解」が存在しない。より良い解決策と、より悪い解決策は存在する。しかし数学的な意味での「正解」はない。価値観の違いによって、何が「良い解決」かの評価が変わる。 試行のたびに問題が変化する。複雑な社会システムの中に問題が埋め込まれているため、解決策を試みると、その結果が問題の全体像を変える。「一度きりの試行」であることが多い——核のテスト航空機の開発はやり直しがきかない。 リチャード・ブキャナンの拡張——デザインとWicked Problemsの接続 リチャード・ブキャナン（Richard Buchanan）は1992年の論文 Wicked Problems in Design Thinking でこの概念をデザイン領域に持ち込んだ。ブキャナンの貢献は、「デザインが扱う問題はすべてWicked Problemsである」という命題にある。 ブキャナンの論点は明快だ。設計の問題には「あらかじめ存在する解法」がない。良いデザインとは何かは、使う人、使う文脈、社会的価値観によって変わる。さらに、デザインされたものは社会に出た後、意図しない方法で使われ、意図しない影響を与える。これはリッテルとウェバーが定義したWicked Problemsの特性と構造的に一致する。 この洞察がデザイン思考に与えた影響は大きい。デザイン思考の5フェーズ（共感→問題定義→創造→プロトタイプ→テスト）は、Wicked Problemsへの構造的な対処プロセスとして読み解くことができる。 デザイン思考がWicked Problemsに有効な理由 「問題定義」を反復可能にする 共感フェーズで収集した情報は、定義フェーズで問題を「暫定的に」定義する材料になる。この「暫定的に」が鍵だ。Wicked Problemsに対して「完全な問題定義」を求めることは不可能だ。しかし「今持っている情報で、最善の問題定義をする」ことは可能だ。 デザイン思考の共感→定義→共感という反復は、問題の定義を少しずつ精緻化するプロセスだ。ワークショップ現場でよく起こるのは、「最初に定義した問題が、ユーザーインタビューを経た後に根本的に書き換えられる」場面だ。これは失敗ではなく、Wicked Problemsへの正しい対処法だ。 プロトタイプで「試行の学習」を積む Wicked Problemsの特性として「唯一の正解がない」ことを述べた。これは「何でもよい」ということではなく「複数の暫定的な解を試してフィードバックを得る」プロセスが必要だということだ。 プロトタイプフェーズは、低コストで仮説を試す仕組みだ。完成品を作る前に、紙のプロトタイプ、ロールプレイ、デジタルモックアップで「この方向性は正しいか」を問う。Wicked Problemsに対して「一発で正解を出す」アプローチは機能しない。プロトタイプを通じた反復的な学習が、唯一機能するアプローチだ。 ステークホルダーの「多様な正解」を統合する Wicked Problemsは価値観の対立を内包する。医療サービスのデザインを考えるとき、患者・医師・看護師・経営者・保険会社は、それぞれ異なる「正解」を持つ。 デザイン思考の共同創造（Co-creation）のアプローチは、この対立を「どちらが正しいか」ではなく「どう統合するか」という問いに変換する。ステークホルダーマッピングやサービスブループリントは、異なる当事者の視点を一枚の図に統合するためのツールだ。 実践——Wicked Problemsに向き合うワークショップ設計 Wicked Problemsを前にしたとき、「解決策を出すことが目標のワークショップ」は機能しない。代わりに「問題をより深く理解することが目標のワークショップ」が有効だ。 200回以上のワークショップで繰り返し観察されるパターンがある。クライアントが「解決策が欲しい」と言って来た時、実際に必要なのは「問題の正確な定義」であることが多い。ワークショップの最初の2時間を問題定義に集中させると、クライアント自身が「自分たちは間違った問題を解こうとしていた」と気づく場面が繰り返される。 ステップ1: 問題を複数の「視点」から記述する 最初に「この問題は誰にとっての問題か」を問う。顧客、従業員、経営者、社会——それぞれの視点から問題を記述する。この段階で「視点によって問題が全く異なる」ことが可視化される。 ステップ2: 「解けない理由」を先に列挙する 「なぜこの問題がこれまで解かれていないのか」を問うことで、Wicked Problemsの特性を先に受け入れる。これは敗北主義ではなく、「どの制約の中で解くか」を意識化する作業だ。 ステップ3: 暫定的な「How Might We（HMW）」を設定する 問題の完全な理解を待たずに、現時点で最も有望な問いを「暫定的に」設定する。HMWは疑問形であり、「こうすれば解ける」という断定ではない。この「暫定性」を明示することで、チームは「この問いが間違っていた場合に戻れる」安心感を持って前進できる。 Wicked Problemsを「解く」のではなく「管理する」 ブキャナンの論文から30年が経過した現在、Wicked Problemsへの理解は深まっている。重要な認識の更新は「Wicked Problemsは解けない」という認識だ。 これは諦めではなく、正確な理解だ。貧困、気候変動、組織文化の変革——これらの問題に「完全解」はない。デザイン思考ができるのは、問題をより良い状態に向かって動かし続けることだ。「解く」のではなく「管理する」という動詞の転換が、Wicked Problemsとの正しい向き合い方を示している。 この認識は実践者にとって解放的でもある。「なぜ一度やったのに問題が続くのか」という問いへの答えが変わる。それは実践の失敗ではなく、Wicked Problemsの本質的な特性だ。継続的な関与と反復的な改善が、デザイン思考による唯一の応答だ。 --- まとめ Wicked Problemsは、デザイン思考が登場した根本的な理由と直結している。単純な問題は既存の手法で解ける。デザイン思考が必要なのは、定義が困難で、正解が一つでなく、試行のたびに変化する問題——すなわちWicked Problemsに直面した時だ。 ダブルダイヤモンドの発散と収束、共感フェーズでの一次情報収集、プロトタイプによる仮説検証——これらの手法はすべて、Wicked Problemsに対処するための構造として読み解くことができる。 手法の背景にある理論を理解したとき、実践者は「なぜこれをやるのか」を説明できるようになる。それは組織の中でデザイン思考を推進する際の、最も強力な武器のひとつだ。 参考文献 - Horst Rittel & Melvin Webber, "Dilemmas in a General Theory of Planning," Policy Sciences, Vol.4, 1973 - Richard Buchanan, "Wicked Problems in Design Thinking," Design Issues, Vol.8, No.2, 1992 - リチャード・ブキャナン — Wicked Problemsとデザイン思考の概念基盤 - 問題定義フェーズの実践ガイド --- ### デザイン思考とシステム思考を統合する実践アプローチ URL: https://designthinking.studio/articles/design-thinking-systems-thinking/ > デザイン思考だけでは解けない複雑な問題に、システム思考を組み合わせて取り組む実践的な統合手法。相互補完の原理と現場での活用ステップを解説。 デザイン思考のワークショップで「ユーザーインタビューは完璧にできたのに、施策を打っても問題が再発する」という経験はないでしょうか。ユーザーの声を丁寧に拾っても、その背後にある構造的な力学を見落とせば、問題の根本は変わりません。 人間中心のデザイン思考と、構造・相互作用を俯瞰するシステム思考を組み合わせることで、こうした限界を突破できます。 デザイン思考だけでは見えないもの デザイン思考の共感フェーズでは、ユーザーの行動・感情・動機を丁寧に観察します。しかしその手法は、個人の体験を深掘りするのには優れていますが、複数の要因が絡み合う「複雑適応系」の全体像を捉えるには限界があります。 あるチームが病院の待合患者の不満を調査したとき、ユーザーインタビューからは「待ち時間が長い」「情報が来ない」という声が集まりました。それを受けて情報掲示板を設置しましたが、不満は消えませんでした。待ち時間の原因は、患者のフローではなく診察室間の申し送り手順にあったのです。個人の体験を深く見るだけでは、組織の構造まで視野が届かなかった事例です。 このような「施策を打っても再発する問題」に共通するのは、組織や社会のシステムの中にフィードバックループが存在することです。Peter Senge は『The Fifth Discipline』（1990）の中で、「今日の問題は昨日の解決策から生まれる」と指摘しています。局所最適が全体の悪循環を強める構造は、デザイン思考の視野だけでは見えてきません。 システム思考はこうした「見えない構造」を可視化するアプローチです。要素間のフィードバックループ、時間遅延、レバレッジポイントを描くことで、なぜ問題が再発するのかが初めて理解できます。 2つの思考法の相補関係 デザイン思考とシステム思考は、お互いの弱点を補い合う関係にあります。 デザイン思考の強み・弱み デザイン思考は「人」に強い手法です。ユーザーの潜在ニーズを引き出し、具体的な解決策を素早くプロトタイプできます。一方で、時間スケールが短く、広いシステムの文脈が見えにくいという側面があります。「問題が何か」を特定するのは得意でも、「なぜその問題が繰り返されるか」を説明する装置がない。 システム思考の強み・弱み システム思考は「構造」に強い手法です。因果ループ図やストック＆フロー図を使い、複雑な相互作用を可視化します。しかし抽象度が高く、現場のユーザーを置き去りにしがちです。 「構造はわかったが、それで何をするのか」——行動への接続が弱い。 | 観点 | デザイン思考 | システム思考 | |---|---|---| | 視点 | ユーザー個人 | システム全体 | | 時間軸 | 短期・現在 | 長期・動態 | | 成果 | プロトタイプ・解決策 | 構造マップ・レバレッジポイント | | 弱点 | 構造の見落とし | 行動への接続の弱さ | 2つを統合すると、「なぜその問題が起きているか」と「ユーザーにとって何が望ましいか」を同時に扱えるようになります。 統合の実践ステップ ステップ1：デザイン思考で「症状」を観察する 統合アプローチの第一歩は、通常のデザイン思考と同じく共感フェーズから始めます。ユーザーインタビューや観察調査で「表面に現れた問題」を収集します。このフェーズで大切なのは、解決策を考えないこと。「待ち時間が長い」「手順が複雑で諦めた」といった生の声を、評価せず記録します。 収集した観察データは、親和図法（KJ法）を使ってグルーピングします。ここで得られる見出しが、後にシステム思考で掘り下げる「変数候補」になります。問題定義フェーズでの POV ステートメントと合わせて使うと、変数の絞り込みがスムーズになります。 ステップ2：システム思考で「構造」を描く ステップ1で発見した主要な変数を取り上げ、因果ループ図を描きます。 変数間の矢印は「AがBを増やす（または減らす）」という因果関係を表します。まずは10〜15の変数から始め、相互作用を探ります。 ワークショップでよく起こるのは、矢印を引いているうちに参加者が急に静かになる瞬間です。手が止まり、しばらくしてから「これ、ループしてる」と誰かが口にします。その瞬間、部屋の空気が変わります。「患者の不満が増えると、電話問い合わせが増え、スタッフの対応負荷が上がり、情報提供が遅れ、さらに不満が増える」というような悪循環（強化ループ）は、最も介入効果が高い場所を示しています。 初めて因果ループ図を描くチームが陥りがちなのは、矢印を引きすぎることです。「全部つながっている」状態になると、何も見えないクモの巣になってしまいます。変数を8個以内に絞り、「最も強いと思うループを1本だけ描く」という制約を課すと、チームの会話が一気に具体的になります。 因果ループ図を描く際は、付箋とホワイトボードを使うのが実用的です。デジタルツール（Kumu、Loopy など）は後から整理するときに使い、ワークショップ本番では手書きを推奨します。参加者が「自分の手で描いた」感覚が、後の対話を活性化します。 ステップ3：レバレッジポイントを特定する 因果ループ図が完成したら、「ここを変えると、全体が大きく変わる」というレバレッジポイントを探します。 Donella Meadows は著書『Thinking in Systems』（2008）の中でシステムへの介入ポイントを12段階で整理しており、最も影響力が高いのは「フィードバックの遅延を変える」「ループの強さを変える」「情報の流れを変える」といった構造的介入です。 実際にやってみると、多くの場合「見えていた問題」の原因は、システムの遠い場所にあります。表面の症状に対処するだけでは、強化ループによって問題が再生されるためです。「なぜこの変数を変えようとしたのか」と問い返したとき、チームが以前の施策の限界に自分で気づく——この体験がシステム思考を学ぶ最大の価値です。 ステップ4：デザイン思考で「介入策」を具体化する レバレッジポイントが特定できたら、アイデア創出フェーズに戻ります。システム思考が「どこを変えるべきか」を示し、デザイン思考が「どのように変えるか」を具体化します。 ブレインストーミングセッションでは、レバレッジポイントを「制約条件」として書いた付箋を中央に置きます。「この制約を前提として、ユーザーにとって何ができるか」を発散的に考えることで、システム全体を変えながらも、ユーザー体験として意味のある施策が生まれやすくなります。How Might We の問い立てもレバレッジポイントを起点にすると、問いの切り口が鋭くなります。 ステップ5：プロトタイプとシステム観察を並行する 施策をプロトタイプして実施したら、単なるユーザーテストだけでなく、システム全体の変数がどう動いたかを観察します。 「患者満足度は上がったか」という個別指標だけでなく、「スタッフの負荷は変わったか」「申し送り手順はどう変化したか」という周辺の変数もモニタリングします。 通常のデザイン思考のテストフェーズより手間はかかります。しかし介入が意図しない副作用を引き起こしていないかを確かめるためには、この周辺観察が欠かせません。システム思考ではこれを「ポリシー・レジスタンス（施策抵抗）」と呼びます。一方への介入が別の部分で問題を生む現象です。 現場での活用事例 ある地方自治体の移住促進プロジェクトでは、デザイン思考単体でのリサーチから「移住者は地域コミュニティへの参入障壁を感じている」というインサイトが出ていました。当初は「移住者向けの交流イベントを増やす」という施策が検討されていましたが、システム思考で構造を描くと異なる景色が見えました。 因果ループ図を描いたところ、「既存住民が参加するイベントが少ないほど移住者が浮いて見える」→「移住者が定着しない」→「移住者向けの予算が縮小される」→「イベントがさらに減る」という悪循環が存在していました。レバレッジポイントは「移住者と既存住民が混在する機会の設計」にあると判断し、移住者専用イベントではなく地域混在型の活動拠点整備へと施策の方向を転換しました。 参加者からの声として印象的だったのは「システム思考で図を描いたとき、自分たちがずっと悪循環を補強していたと気づいた」という発言です。それまで「予算が少ないからイベントが開けない」という外部要因として語られていた問題が、自分たちの行動パターンの結果だったと腹落ちした瞬間でした。介入の方向性が根本的に変わった事例として、統合アプローチの有効性を示しています。 よくある疑問と対処法 「システム思考は難しそうで、ワークショップ参加者がついてこれない」 因果ループ図を一から説明しようとすると確かに難解です。実践では「Aが増えるとBはどうなる？」という問いかけだけで関係性を引き出し、ファシリテーターが図に落とすという分業が有効です。参加者は「矢印の意味を理解する」より「関係性について考える」ことに集中できます。ファシリテーションのコツも合わせて参照してください。 「時間がかかりすぎて使えない」 フルスケールのシステムダイナミクスモデルを作る必要はありません。因果ループ図は1時間のセッションでも描けます。変数を5〜8個に絞り、「最も強いと思うループを1つ見つける」目的に限定すれば十分です。デザインスプリントの形式に組み込むなら、Day 1のマッピングセッションに統合するのが現実的な選択肢です。 「どのタイミングで統合するか」 デザイン思考の問題定義フェーズの後半と、アイデア創出フェーズの前半。「問題がわかった」段階でシステム思考を使って構造を掘り下げると、アイデア出しの前提が変わります。 やってみよう 次のプロジェクトで統合アプローチを試す場合、以下の3ステップから始めるのがお勧めです。 - 共感フェーズで「繰り返し出てくる問題」を特定する — インタビューや観察で「これは以前も同じ話を聞いた」と感じた問題をリスト化します。繰り返し性は、強化ループが存在するサインです。 - ホワイトボードに3つの変数を書いて矢印を引く — 小さく始めます。「変数A → 変数B → 変数C → 変数A」というループが1つ見えるだけで、チームの会話の質が変わります。 - 「これを変えると何が連鎖するか」を問う — アイデア出しの前に、チーム全員でこの問いを共有します。システム全体への影響を考える習慣が、施策の質を高めます。 デザイン思考がユーザーに「光を当てる」手法だとすれば、システム思考はその光が届かない「影の構造」を照らします。どちらか一方では見えなかった景色が、2つを重ねたとき初めて現れる——統合アプローチの醍醐味はそこにあります。 --- 参考文献 - Peter Senge, The Fifth Discipline: The Art and Practice of the Learning Organization, Doubleday, 1990 - Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 関連記事 システム思考の「長期的影響」の視点は、製品設計における環境・社会への影響分析にも直結する。サステナビリティ × デザイン思考——製品設計に環境視点を組み込む実践フレームでは、ライフサイクル全体を設計対象として捉える方法論を具体的に解説している。 --- ### デザイン思考とストーリーテリング：洞察を「動く言葉」に変える技術 URL: https://designthinking.studio/articles/design-thinking-storytelling-narrative/ > デザイン思考のリサーチ成果を組織に伝え、変化を起こすために不可欠なストーリーテリングの役割と実践技法を解説。共感・定義・創造・プロトタイプの各フェーズでナラティブをどう活用するかを、具体的な手法と失敗パターンとともに示す。 ユーザーリサーチを終えて、チームに成果を共有する場面を想像してほしい。数十時間のインタビュー、観察、分析から得たインサイトを、A4数十枚のレポートにまとめて渡す。それを読んだステークホルダーは「なるほど、よくわかりました」と答える。しかし翌週のプロダクト会議では、何も変わっていない。 これはデータの問題ではなく、伝え方の問題だ。 人間の意思決定と行動変容を促すのは、統計ではなくストーリーだ。神経科学の研究が示すように（Zak, 2014）、人は物語を聞くとき、単なる情報処理を超えた形で認知と感情が統合される。デザイン思考がリサーチから始まり、プロトタイプで終わるプロセス全体に、ストーリーテリングは通奏低音として流れている。 --- なぜデザイン思考にストーリーが必要なのか データは事実を伝えるが、ストーリーは文脈を伝える。そして人間が変化を起こすためには、文脈の理解が先に来る。 ワークショップでよく起きるのは次のパターンだ。チームがユーザーインタビューから「ユーザーの65%が機能Xを使っていない」というデータを持ち帰る。会議で提示すると、エンジニアリングチームは「UIが悪いせいだ」と言い、マーケティングは「認知度の問題だ」と言う。全員が自分の視点からデータを解釈し、議論は平行線を辿る。 同じデータを「36歳、二人の子供を持つ共働きの親の田中さんは、朝7時から夜11時まで時間がない。そのアプリを開く前に彼女は何かを諦めている」というストーリーで伝えると、部屋の空気が変わる。田中さんという存在が会議室に入ってくる感覚が生まれ、チームは「田中さんにとって何が正しいか」という共通の問いを持ち始める。 この変化が、デザイン思考においてストーリーテリングが不可欠な理由だ。 --- 共感フェーズ：観察をナラティブに変換する 共感フェーズでのストーリーテリングは、リサーチの解釈作業そのものだ。インタビュー音声、観察メモ、写真——これらの原材料を、チームが共有できる「人間の文脈」に変換する。 ユーザーストーリーの構造 効果的なユーザーストーリーには、3つの要素がある。 状況（Context）：その人がどんな生活環境・仕事環境に置かれているか。具体的な曜日、時間帯、場所から始めるとリアリティが増す。 緊張（Tension）：その人が直面している困難、矛盾、フラストレーション。「〜したいが、〜のせいでできない」という構造がシンプルで伝わりやすい。 欲求（Desire）：その人が本当に求めている状態。これは機能要求ではなく、生活上の文脈に根ざした本質的な欲求であるほど良い。 この3つを組み合わせたストーリーが、その後の定義フェーズでの「POV（Point of View）ステートメント」の素材になる。 ペルソナはストーリーの「語り手」 ペルソナの目的は、ユーザーセグメントを「人間化」することだ。名前、写真、生活習慣、価値観——これらはデータの塊ではなく、ストーリーを持った存在として設計される。 効果的なペルソナは「典型的ユーザー」を平均値で描かない。特定の緊張と欲求を持つ具体的な存在として設計することで、プロジェクト全体を通じてチームが「この人のために何をするか」を問い続けられる。 --- 定義フェーズ：インサイトをナラティブに昇華させる 定義フェーズでのストーリーテリングは、研究の解釈から洞察への飛躍を支える。 リサーチで集まった断片的な観察をアフィニティダイアグラムで整理したとしても、そこから「なぜ」を問い、意味を見出す作業は本質的にナラティブだ。「起きていること（what）」から「なぜそれが起きているか（why）」への移行が、インサイトの誕生だからだ。 良いインサイトステートメントは、それ自体が短いストーリーだ。「田中さんのような親たちは、子供の習い事の送迎中に仕事メールをこなすために片手操作しているが、それは後ろめたさを感じながらやっている」——この文章には、状況・行動・感情が圧縮されている。これがアイデア発散の出発点になる。 ステークホルダーへの共感転送 定義フェーズで生み出されたインサイトを、プロジェクトに直接関与していないステークホルダーに伝える必要がある場面は必ず来る。 その際に最もよく機能するのは、データ提示の前に「ユーザーの一日を追うストーリー」を語ることだ。朝起きてから夜寝るまでのユーザーの行動と感情を、サービスとの接点に沿って語る「Day in the Life」ナラティブは、聞き手を一度ユーザーの靴を履かせる効果がある。そこから統計データを提示すると、数字に人間の顔がつく。 --- 創造フェーズ：アイデアをストーリーで評価する 創造フェーズでのストーリーテリングは、アイデアを「使われる場面」で評価するために使う。 大量のアイデアが出た後の収束段階で、「どのアイデアが最も良いか」という抽象的な議論をしても結論は出ない。そこで有効なのが「そのアイデアがあれば、田中さんの一日はどう変わるか」を語るアプローチだ。 これはアイデアの優劣を「機能比較」ではなく「ユーザー体験のナラティブ」で評価することを意味する。実際に使われる場面をストーリーとして描けないアイデアは、実装段階で現実との乖離が生まれることが多い。 スターバーストとナラティブ思考の接続 「このアイデアを採用したら1年後、田中さんの生活はどうなっているか」という問いを設定することで、短期的な機能評価から長期的な価値評価へとチームの思考が広がる。このナラティブ的な未来描写が、プロトタイプの設計方針を決める手がかりになる。 --- プロトタイプフェーズ：ストーリーボードで製品を語る プロトタイプフェーズでのストーリーテリングは、ストーリーボード（Storyboard）の形で最も具体化される。 ストーリーボードは映画やアニメーションの手法を製品設計に持ち込んだものだ。6〜12コマのマンガ形式で、ユーザーが課題に直面し、プロダクト・サービスを使い、問題が解決される流れを視覚的に描く。 スタジオボードがプロトタイプより先に来ることが多い理由は、作る前に「どんな体験を作りたいのか」を明確にするためだ。プログラムを書く前にストーリーを描くことで、実装すべき機能の優先順位が整理される。また、ストーリーボードはユーザーテストの前にユーザーに見せても機能する。絵コンテを見せながら「こういう体験があったら使いますか」と問うことができる。 --- ステークホルダー説得のナラティブ設計 デザイン思考のプロセスの中で最も失敗しやすいのが、経営層や他部門への説得場面でのストーリーテリングだ。 典型的な失敗は、「プロセスの正当性」を語りすぎることだ。「私たちは8週間かけてインタビューを行い、アフィニティダイアグラムでパターンを抽出し、HMWの問いを設定して...」という説明は、デザイン思考に馴染みのない聴衆を置き去りにする。 代わりに機能するのは「問題のストーリー」から入ることだ。ユーザーが直面している問題を、感情と文脈を込めて語る。そこに解決策の提案を接続することで、聴衆はロジックではなく「なるほど、そうすれば彼女が助かる」という共感から賛成に傾く。 Nancy Duarteが『resonate』（2010, Wiley）で示したように、効果的なプレゼンテーションは「現在の状態（What Is）」と「理想の状態（What Could Be）」の対比構造を持つ。この対比がストーリーの緊張を生み、聴衆を変化へと引き寄せる。 --- ストーリーテリングが失敗するパターン 感情に偏りすぎて事実を失う。 ユーザーのストーリーを劇的に描くあまり、実際の観察から逸脱してしまうケースだ。ストーリーは事実の「圧縮」であり、「創作」ではない。 一人のユーザーを代表させすぎる。 「田中さん」のストーリーが強すぎると、チームが「田中さんのためだけの設計」に引っ張られることがある。ストーリーは共感のレンズだが、意思決定の唯一の根拠にはしない。 解決策を先にストーリーに組み込む。 「この機能があれば田中さんは助かる」というストーリーは、解決策の正当化に使われることがある。ストーリーは問題の探索フェーズで最も機能し、解決策の評価は別のプロセスで行う。 --- 実践への入り口 次のワークショップで試してほしいことが一つある。リサーチ成果を発表する前に、5分だけ「あなたが最も強い印象を受けたユーザーの場面を、1分で語ってください」という問いをチームに投げかけてほしい。 データの議論より先に、各人が心に残ったユーザーの瞬間を言葉にすることで、チームに共通の「感情的な参照点」が生まれる。その後のデータ議論は、その参照点から進む。それだけで、会議の質が変わる。 ストーリーテリングはテクニックではなく、「人間の経験に敬意を払う」という態度の言語的表現だ。 デザイン思考がユーザーを中心に置くことと、本質的に同じ価値から生まれている。 --- 参考文献 - Duarte, N. (2010). resonate: Present Visual Stories that Transform Audiences. Wiley. - Zak, P. J. (2014). Why Your Brain Loves Good Storytelling. Harvard Business Review. https://hbr.org/2014/10/why-your-brain-loves-good-storytelling - Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster. — スタジオボードとストーリーボードの実践的な説明を含む - IDEO.org. (2015). The Field Guide to Human-Centered Design. IDEO.org. — ストーリーテリングをデザイン手法として位置づけた実践ガイド - Brown, T. (2009). Change by Design. HarperBusiness. — デザイン思考における「物語の力」についての章を含む --- ### デザイン思考とは何か——5フェーズの実践法と日本企業の失敗パターン URL: https://designthinking.studio/articles/what-is-design-thinking/ > デザイン思考とは、人間中心の視点でニーズ・技術・事業性を統合する問題解決手法。「付箋を貼ってペルソナを作れば完成」ではない。IDEO・d.school発の5フェーズと、日本企業に多い失敗の3段階まで解説する実践ガイド。 デザイン思考（Design Thinking）は、ここ20年でビジネスの現場に最も浸透した「問題解決の方法論」のひとつです。しかし「付箋を貼ってペルソナを作れば完成」という表面的な導入が横行し、期待した成果が出ないケースも後を絶ちません。 手法の名前を知っていることと、手法が機能する理由を理解することは、まったく別のことです。 本記事では、デザイン思考の起源・構造・実践・批判・進化に加え、日本企業が陥りやすい失敗の3段階までを一本の流れで解説します。 デザイン思考とは何か——Tim Brownの定義から入る IDEO元CEOのTim Brownは、デザイン思考を次のように定義しています。 デザイナーの感性と手法を用いて、人々のニーズ、テクノロジーの可能性、ビジネスの成功要件を統合するイノベーションへの人間中心アプローチ。 — Tim Brown, Harvard Business Review, June 2008 この定義が重要なのは、3つの円の交差で表されるBTC統合論（Business / Technology / Creative）の構造を示しているからです。デザイン思考は「デザインをうまくやる方法」ではなく、人間・技術・ビジネスの3軸を同時に考える問題解決の姿勢です。 - Desirability（人間の望ましさ） — 人々が本当に求めているものか - Feasibility（技術的実現可能性） — 現在の技術で実現できるか - Viability（ビジネスの持続可能性） — 事業として成立するか 3つの円が重なる領域に、真のイノベーションが生まれます。1つでも欠けると、「技術的には優れているが誰も使わない」「ユーザーは喜ぶが事業化できない」という陥穽にはまります。 --- 歴史：1980年代のデザインコンサルティングからd.schoolへ デザイン思考の知的基盤は古く、1969年のHerbert A. Simonの著書『The Sciences of the Artificial（システムの科学）』にまで遡ります。Simonは「デザインは既存の状況をより望ましい状況に変えるための行動の考案」と定義し、デザインを問題解決プロセスとして捉える視座を示しました。 IDEO誕生（1991年）——デザインコンサルティングの革新 実践面での決定的な転換は、1991年にデザインコンサルティング会社IDEOが設立されたことにあります。前身はDavid Kelleyが1978年に創業したDavid Kelley Design（後にIDEO）です。1991年の合併でIDEO Inc.が誕生し、David Kelley、Tom Kelley兄弟、そして後にCEOとなるTim Brownのリーダーシップのもとで、デザイン思考はビジネスイノベーションの実践手法として体系化されていきました。 1999年のABC Nightlineの放映が、デザイン思考を世界に知らしめる転機になりました。IDEOが5日間でスーパーマーケットのショッピングカートを再デザインするプロセスを撮影したこのドキュメンタリーは、「チームによる人間中心デザイン」の力を一般に示した歴史的映像です。詳細はIDEOのショッピングカート再デザイン事例に譲りますが、このプロジェクトは「エキスパートが一人で考えるより、多様なチームが共感から始める方が優れたアイデアが生まれる」という命題を実証しました。 Stanford d.school設立（2005年）——学際的教育プログラムへ 2005年、スタンフォード大学にHasso Plattner Institute of Design（通称d.school）が設立されました。設立者はDavid Kelleyです。d.schoolの最大の特異性は、工学・経営・教育・医学・法学など異なる学部の学生が同じチームでプロジェクトに取り組む「学際的デザイン教育」にあります。 d.schoolは5つのフェーズからなるデザイン思考プロセスを体系化し、「誰もがデザイン思考を学べる」という姿勢でワールドワイドに普及を進めました。2013年にDavid Kelleyと弟Tom Kelleyが著したCreative Confidence（クリエイティブ・コンフィデンス）は、「デザイン思考は特定の才能を持つ人間だけのものではない」というメッセージを、世界の経営者・教育者に届けました。 --- 5フェーズの詳解——Stanford d.school版 d.schoolが体系化した5フェーズは、以下の構成です。重要なのは、これが直線的なプロセスではなく反復的（イテラティブ）なサイクルという点です。 Phase 1：Empathize（共感） ユーザーを観察・インタビューし、行動・感情・動機を深く理解するフェーズです。「自分たちが解くべき問題はすでにわかっている」という前提を疑うことから始まります。 具体的な手法として、現場観察（フィールドワーク）、半構造化インタビュー、シャドウィング（ユーザーに同行して行動を観察する手法）、共感マップの作成などがあります。特に半構造化インタビューでは「なぜ？」を5回繰り返す「5 Whys」アプローチが有効で、表層的な発言の背後にある本質的な動機を引き出します。 200回以上のワークショップで観察してきたパターンとして、最も多い「後から戻る先」は共感フェーズです。 テストフェーズでプロトタイプがユーザーに刺さらないとき、問題定義を再考しても解決しないとき、その根本原因の9割は「最初の共感が薄かった」に行き着きます。共感フェーズの実践では、この「戻り」の構造をさらに掘り下げています。 Phase 2：Define（問題定義） 共感フェーズで得た観察を統合し、解くべき本質的な問いを設定するフェーズです。ここで作成するPOVステートメント（Point of View Statement）は「[ユーザー] は [ニーズ] を必要としている。なぜなら [インサイト] だから」という形式で記述します。 POVから「How Might We（HMW）」の問いへの展開が、創造フェーズへの橋渡しになります。「どうすれば〜できるだろうか？」という問いの形式は、否定的な現状を可能性の問いに変換します。HMWは広すぎず狭すぎず——「どうすれば世界を変えられるか」は広すぎ、「どうすれば色を変えられるか」は狭すぎます。 この「ちょうどいい問いの粒度」の見つけ方は、問題定義フェーズの実践で手を動かしながら学べる。 Phase 3：Ideate（創造） HMWを出発点に、判断を保留してアイデアを大量に発想するフェーズです。ブレインストーミングの基本ルール（量を重視・判断を保留・他者のアイデアに乗る）に加え、Crazy 8s（1枚の紙を8等分し、8分間で8つのアイデアをスケッチする手法）が特に有効です。 「実際にやってみると、最初の5分で出るアイデアは既知のものばかり」という声はワークショップで頻繁に聞きます。ブレインストーミングの価値は「量を強制することで、明らかなアイデアを使い切り、その先にある非凡なアイデアを引き出す」ことにあります。「最初のアイデアがベストであることは、ほぼない」という前提でプロセスを進めることが重要です。 Phase 4：Prototype（プロトタイプ） アイデアを素早く低コストで形にし、検証可能な状態にするフェーズです。「完成品を作る」ではなく「思考を外部化して学ぶ」ことが目的です。 ペーパープロトタイピングは最も基本的な手法で、画面やサービスの流れを紙にスケッチして、ユーザーに「これで操作してみてください」と試してもらいます。1時間あれば10パターンのプロトタイプを作ることができ、デジタルで作り込む前の段階で「ユーザーが何を期待するか」を把握できます。IDEO流の原則「粗く、速く、安く（Rough, Rapid, Right）」が、プロトタイプの質よりスピードを優先する判断基準になります。プロトタイプフェーズの実践では、ペーパープロトタイピングから始まる具体的な手順を追っています。 Phase 5：Test（テスト） ユーザーにプロトタイプを体験してもらい、フィードバックから学ぶフェーズです。ここでの目標は「仮説の検証」ではなく「想定外の発見」です。仮説を証明しようとする気持ちは、観察の質を下げます。 「ユーザーがプロトタイプで詰まった場所で、なぜ詰まったかを聞かずに次に進んでしまう」という失敗はワークショップで頻繁に観察されます。テスト中に最も価値あるデータは、ユーザーが戸惑い、予期しない操作をした瞬間です。「上手くいったこと」より「上手くいかなかったこと」の方が、次のイテレーションへの学びが大きい。 テストフェーズの実践では、この「想定外の発見」を引き出すインタビュー技術を解説している。 --- ダブルダイヤモンドとの対応関係 デザイン思考を学ぶ過程で必ず出会うもうひとつのモデルが、英国Design Councilが2004年に発表したダブルダイヤモンド（Double Diamond）です。d.schoolの5フェーズとよく比較されますが、思想は共通しながら強調点が異なります。 | 観点 | d.school 5フェーズ | ダブルダイヤモンド | |---|---|---| | 発祥 | スタンフォード大学（2005年） | 英国Design Council（2004年） | | フェーズ数 | 5（Empathize / Define / Ideate / Prototype / Test） | 4（Discover / Define / Develop / Deliver） | | 最大の特徴 | 共感（Empathize）を独立フェーズとして強調 | 発散と収束のリズムを視覚的に明示 | | プロセス観 | 5フェーズの反復（イテレーション） | 問題空間と解決空間の明確な分離 | | 主な活用文脈 | プロダクト開発、イノベーション教育 | サービスデザイン、政策デザイン | 両モデルの対応関係を整理すると、d.schoolの「Empathize + Define」がダブルダイヤモンドの「Discover + Define」（第1ダイヤモンド）に対応し、「Ideate + Prototype + Test」が「Develop + Deliver」（第2ダイヤモンド）に対応します。 ダブルダイヤモンドが強調するのは「正しい問題を見つけてから、正しい解決策を作る」という順序です。第1ダイヤモンドを省略して解決策の議論に飛びつく誘惑に、明示的に構造で対抗します。詳細はダブルダイヤモンドの実践に譲ります。 --- Business / Technology / Creative（BTC）統合論 Tim Brownが提唱したBTC統合論は、デザイン思考の理論的核心です。多くの組織がデザイン思考を導入しても変革が起きない原因のひとつは、この統合を組織構造として実現できていないことにあります。 IDEOでは、プロダクトデザイナー・エンジニア・ビジネスアナリスト・社会科学者が同じチームに混在する「T字型人材のチーム」が標準です。T字型人材とは「特定分野の深い専門性（縦棒）と、他分野への好奇心と協働能力（横棒）」を持つ人間を指します。 この思想の日本への輸入として参考になるのが、電通のBデザインチーム（Business Design）の取り組みです。コンサルタント・クリエイター・テクノロジストが同一チームで事業設計を行うこの組織形態は、BTC統合の日本版実装として機能しています。 「ビジネス側は成果指標を、デザイン側は体験品質を、技術側は実装可能性を、それぞれ別々に最適化する」という縦割り構造は、真のイノベーションに必要な「3つの円の交差」を生み出せません。 BTC統合を組織設計の原則に組み込むことが、デザイン思考を形式的な手法から実質的な力に変える転換点になります。 --- 日本企業の導入事例——成功と失敗の両面 成功パターン：構造的な変革を伴った導入 Yahoo! Japanは2010年代初頭からデザイン思考を段階的に導入し、ユーザーリサーチを開発プロセスの中心に位置づけてきました。単発のワークショップではなく、プロダクト開発の意思決定プロセスそのものを再設計したことが、定着の鍵でした。 楽天では、多言語・多文化のユーザーを抱えるグローバルサービスにおいて、各国のユーザーリサーチを体系的に実施するデザインリサーチチームを設置しています。「楽天市場」のUI改善プロジェクトでは、長年放置されてきた情報設計の問題を、ユーザーテストによるインサイトを基に段階的に解消していきました。 リコーは、プリンターやMFP（複合機）という成熟市場でのイノベーション創出に、デザイン思考を活用しています。法人顧客の「働く現場」に入り込んだフィールドリサーチを実施し、機器の機能改善ではなく「ワークフロー全体の最適化」という問題定義への転換を実現しました。 失敗パターン：形骸化の3段階 日本企業のデザイン思考導入でよく観察される失敗は、以下の3段階で進行します。 第1段階：研修の実施。外部ファシリテーターを呼んで1〜2日のワークショップを開催し、参加者は「デザイン思考を体験した」という感覚を持ちます。しかし研修終了後、業務への接続方法が示されないまま終わることがほとんどです。 第2段階：ポストイットの儀式化。次のプロジェクトで「デザイン思考をやってみよう」となったとき、付箋を貼ってペルソナを作るという形式だけが再現されます。ユーザーリサーチは省略され、チームが想像した「典型的なユーザー像」を根拠にペルソナが作られます。 第3段階：経営層の無理解と撤退。プロトタイプが完成しても、承認プロセスや予算確保の壁を越えられず、プロジェクトが立ち消えます。「あれは現場の遊びだった」という評価が定着し、次の予算が削られる。 この構造的問題についてはデザイン思考が失敗する5つのパターンで詳しく分析しています。 山口周「デザイン思考の限界」論への応答 哲学者・山口周は2019年前後から「デザイン思考は問題解決には向くが、問題発見には向かない」という論を展開し、アート思考との対比でデザイン思考の限界を論じています。この批判は、特定の層に強く響きました。 この批判は半分正しく、半分は誤解に基づいていると考えます。デザイン思考のEmpathizeフェーズは、本来「存在していない問題を発見する」ためのプロセスです。ただし実際のワークショップでは「解くべき問題はすでに設定されている」前提でフェーズを進めることが多く、山口が批判するのは「デザイン思考そのもの」ではなく「デザイン思考の浅い実践」です。 Natasha Jenの「Design Thinking is Bullshit」を含む批判の系譜については、デザイン思考への批判を読み解くで整理しています。批判を知ることは、デザイン思考を捨てることではなく、より誠実に使うための基盤になります。 --- 2026年のデザイン思考——AI時代の進化 AI支援デザイン思考の台頭 2024〜2025年のAIツールの急速な普及は、デザイン思考の各フェーズを変えつつあります。最も変化が大きいのは、インサイト抽出と発散フェーズです。 Empathizeフェーズでは、複数のインタビュー録音をAIが文字起こしし、テーマ別にクラスタリングする作業が大幅に効率化されました。以前は2〜3日かかっていた「共感マップの統合」が数時間で完了します。ただし、AIが分類したクラスターをそのまま「インサイト」として扱う危険性も生まれています。AIは「言語的パターン」は捉えますが、「言葉になっていない違和感」はまだ人間の観察にしか拾えません。 Ideateフェーズでは、生成AIが「HMWに対するアイデア100個」を瞬時に提示します。ブレインストーミングの「量を強制する」という役割をAIが担える一方、「チームが共に考える経験」そのものに価値がある文脈では、AIへの委任は文化変革の機会を損ないます。 AI時代のデザイン思考では、各フェーズにおけるAI支援の具体的な実装パターンと落とし穴を整理している。 リモートデザインスプリントの定着 2020年のパンデミック以降、デザイン思考のワークショップが物理的な空間を前提としない形に進化しました。FigJam、Miro、Mural などのオンラインホワイトボードツールは、付箋・親和図・ジャーニーマップのオンライン代替として定着しています。ファシリテーターとしての実感を含む運用ノウハウはリモートデザインワークショップの実践にまとめた。 またデザインスプリント（Google Venturesが開発した5日間集中プロセス）は、デザイン思考の実践的応用形として多くの組織で採用されています。長期のデザイン思考プロジェクトが難しい場合でも、スプリントの形式で短期間に集中した検証サイクルを回せます。 デザイン思考3.0：ビジネスとの統合 2010年代のデザイン思考は「ワークショップで斬新なアイデアを出す手法」として普及しました。しかし、ワークショップのアウトプットが組織の意思決定プロセスに乗らない構造的問題が表面化したことで、2020年代には「デザイン思考を組織の意思決定システムに統合する」という3.0的なアプローチが台頭しています。 IBMの「Enterprise Design Thinking」はその先行例で、デザイン思考のプラクティスを大規模組織のアジャイル開発プロセスと統合したフレームワークです。1万人以上のデザイナーを擁するIBMが2013年から段階的に実施したこの変革は、「デザイン思考は特定のプロジェクト手法」ではなく「組織の意思決定文化」として機能させる試みの最大規模の実証例です。 --- やってみよう——明日から始められる3つのステップ デザイン思考を「理解したもの」から「使えるもの」に変えるために、今日から実行できる3つのステップを提示します。 ステップ1：次の問題を「HMW」に変換する。 現在抱えているプロジェクトの課題を「どうすれば〜できるだろうか？」という形式に書き換えてください。否定的な現状記述が、探索可能な問いに変わるはずです。 ステップ2：ユーザーに1時間話を聞く。 解決策を議論する前に、ユーザー（顧客・利用者・関係者）と1時間対話してください。「自分たちが想定していたことと、実際の状況が違う」という発見が必ず出てきます。 この発見なしにプロジェクトを進めることのリスクを、チームで共有する材料になります。 ステップ3：紙でプロトタイプを作る。 デジタルツールを開く前に、A4用紙にサービスや製品の概念をスケッチしてください。30分で3パターン作れます。作ったものを見せ合うことで、チームの中で「言語化できていなかった前提の違い」が表面化します。 --- まとめ：デザイン思考を機能させる条件 デザイン思考は強力ですが、条件なしに機能するわけではありません。この手法を機能させる本質的な条件を3点に絞ります。 共感は本物のフィールドワークから。 会議室で作ったペルソナは、フィールドで観察したユーザー像には勝てません。共感フェーズに投資しなければ、残りのフェーズはすべて砂上の楼閣。 問題定義にこだわること。 「正しい解決策を速く作る」より「正しい問題を見つけること」の方が、最終的な成果への近道です。ダブルダイヤモンドが示す「第1ダイヤモンドへの投資」という思想は、現場で何度でも確認に値します。 実装の政治から逃げないこと。 プロトタイプが完成した日が、本当の戦いの始まりです。予算承認・既存プロセスの変更・担当者間の調整——これらを「別の誰かの仕事」にした瞬間、デザイン思考プロジェクトは死にます。デザイン思考の組織定着では、この問題への具体的な対処法を整理した。 「手を動かさない理解は理解ではない」。デザイン思考の核心は、ここにある。 実践に役立つ関連記事 - ユーザビリティテスト計画の立て方：5ステップ完全ガイド — テストフェーズを体系的に設計する実践手順 - デジタルホワイトボードツール比較：Miro・FigJam・Mural デザイン思考での選び方 — リモート・ハイブリッドワークショップを支えるツール選定 - デザイン思考ファシリテーター育成：組織内ケイパビリティ構築ガイド — 社内でデザイン思考を継続させるための人材育成 --- 参考文献 - Tim Brown, "Design Thinking", Harvard Business Review, June 2008 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 - David Kelley & Tom Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 - Stanford d.school, An Introduction to Design Thinking: Process Guide, Institute of Design at Stanford, 2010 - Design Council, "What is the framework for innovation? Design Council's evolved Double Diamond", designcouncil.org.uk, 2019 - Herbert A. Simon, The Sciences of the Artificial, MIT Press, 1969 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- 本記事は荒井宏之 a.k.a. ピンキーが執筆・監修しています。デザイン思考・グランドデザイン思考の研究・実践者として、200回以上のワークショップ実績をもとに理論と実践の統合を追求しています。 --- ### デザイン思考とリーダーシップ｜統合的思考が組織を変える URL: https://designthinking.studio/articles/design-thinking-creative-leadership/ > ロジャー・マーティンの「知識ファネル」とデビッド・ケリーの「クリエイティブ・コンフィデンス」を軸に、分析と直感を統合するリーダーシップの実践論を解説する。デザイン思考を組織に根付かせるには、手法の導入より先に、リーダー自身の思考様式を変える必要がある。 デザイン思考の導入が「ワークショップ止まり」で終わる組織と、文化として根付いていく組織の違いはどこにあるか。現場でその問いを繰り返してきた結論は、手法の精度ではなくリーダーの思考様式にある。 ロジャー・マーティン（Roger Martin）がRotman Management Schoolの学長時代に提唱した「統合的思考（Integrative Thinking）」は、デザイン思考をリーダーシップ論として読み解く鍵になる。分析的思考と直感的思考を別物として扱うのではなく、同時に保持しながら新しい解を生み出す能力——それがマーティンの言うリーダーシップの核心だ。 ロジャー・マーティンの「知識ファネル」とは何か マーティンは2009年の著書『The Design of Business: Why Design Thinking Is the Next Competitive Advantage』（邦題『ザ・デザイン・オブ・ビジネス』）で、知識の進化を三段階のファネルとして描いた。 第一段階はミステリー（Mystery）。「なぜこの現象が起きているのか」「この市場には何が欠けているのか」という、答えの存在すら定かでない問いだ。探索のスペースが広大で、どこに向かえばいいかも分からない状態。 第二段階はヒューリスティック（Heuristic）。観察と試行を重ねることで「この方向に答えがありそうだ」という経験則が生まれる。「こういうユーザーには、こういうアプローチが効く」といった、専門家の直感に近い知識の形だ。 第三段階はアルゴリズム（Algorithm）。手順が明確になり、誰でも再現できる形式に落ち着く。マニュアル化、標準化、自動化の対象になる。 マーティンが問題にしたのは、多くの企業がアルゴリズムの最適化だけに経営資源を投入し、ミステリーに立ち向かう能力を失っているという構造だ。アルゴリズムの効率を上げることで差別化できる時代は、競合も同じことをやれば終わる。次の差別化はミステリーから始まる。そしてミステリーに向かうには、答えが見えない状態を耐え、仮説を持って前進するリーダーシップが要る。 統合的思考の正体 マーティンが「統合的思考（Integrative Thinking）」と呼ぶスキルは、二項対立の構造を解体して第三の解を見つける能力だ。 通常の意思決定では、AかBかを選ぶ。どちらがよりリスクが低いか、どちらが数字で正当化できるか、という問いの立て方になる。この論理は分析的思考の得意技であり、既存の選択肢の中でベターを選ぶ局面では有効だ。 しかし統合的思考は問いを変える。「AかBか」ではなく「AとBが同時に正しいとしたら、どんな解が可能か」。矛盾するように見える二つの命題を同時に保持し、そこから新しい可能性を引き出す。 マーティンはこのスキルを、分析的思考と直感的思考の統合として説明した。データや論理から来る「証明できる何か」と、経験と感性から来る「感じ取れる何か」を別々のモードとして使い分けるのではなく、同じ思考の場に引き込んで対話させる。デザイン思考が「ユーザーリサーチ（データ）」と「プロトタイピング（直感的実験）」を繰り返すプロセスとして設計されていることと、構造的に一致している。 デザイン思考の5フェーズの詳細については、各フェーズの解説記事を参照してほしい。 IDEOが育てた「クリエイティブ・コンフィデンス」 デビッド・ケリー（David Kelley）は、IDEOの創業者であり、スタンフォード大学d.schoolの設立者だ。ケリーが提唱する「クリエイティブ・コンフィデンス（Creative Confidence）」は、マーティンの統合的思考と別の角度から同じ場所を指している。 クリエイティブ・コンフィデンスとは「自分にも変化を起こせるという信念」だ。クリエイティビティを一部の特別な人間が持つ才能として捉えるのではなく、練習と経験によって誰もが身につけられる能力として扱う。 ケリーが指摘するのは、多くの大人が「自分はクリエイティブじゃない」という自己否定を内面化しているという事実だ。子どもは描き、作り、壊し、また作る。しかし学校や職場での経験の中で「正解を出せなかった」記憶が積み重なり、「どうせ自分には無理だ」という学習性無力感が生まれる。クリエイティブ・コンフィデンスは、この無力感をほどくプロセスだ。 リーダーシップとの接続はここにある。自分自身にクリエイティブ・コンフィデンスを持てないリーダーは、チームにそれを育てることができない。「失敗してもいい」「試してみよう」という言葉を口にしながら、自分が最初にプロトタイプを作ることを恐れていれば、組織はその矛盾を正確に読み取る。 組織にデザイン思考を根付かせるリーダーの役割 ワークショップは体験を提供する。しかし体験が行動様式に変わるには、日常の意思決定の構造が変わる必要がある。その構造を変えられるのはリーダーだけだ。 問いの立て方を変える。「この施策は効果があるか」ではなく「このユーザーが本当に求めているものは何か」。分析の前に観察を置く問いの順序が、チームの行動様式を変える。リーダーが会議でこの問いを繰り返すことで、チームはどこから考え始めるべきかを学ぶ。 不確実性に耐えるモデリング。答えが分からない状態で「まず試してみよう」と動けるリーダーが組織にいると、チームはリスクを取ることの意味を体感として掴む。「完璧な計画ができてから動く」という文化は、リーダーが完璧な計画を要求する限り変わらない。 失敗の扱い方を変える。プロトタイピングの本質は「早く失敗して学ぶ」ことだが、失敗を報告しづらい組織でこれは機能しない。「この実験で何を学んだか」をプロジェクトレビューの正式な問いにする。失敗の事実ではなく学習の内容を評価する仕組みを作る。これはリーダーが主導しなければ生まれない。 組織へのデザイン思考導入の詳細ステップについては、こちらの記事で整理している。 分析と直感を「統合する」とはどういうことか マーティンの統合的思考を誤解するとすれば、「直感を重視せよ」という主張と受け取ることだ。そうではない。分析を捨てることを勧めているのではなく、分析だけで動かせない領域での意思決定方法を問うている。 具体的な場面で考える。新しいサービスを設計するとき、定量調査は「何が問題か」を確率的に示すが「なぜそれが問題なのか」の構造には届かない。質的観察は「なぜ」に迫るが、それが組織として動く根拠として十分かは分からない。 統合的思考のリーダーはここで立ち止まらない。定量データが示すパターンと、観察から掴んだユーザーの行動原理を、同じ思考の場に引き込む。「なぜこの数字のユーザーはこう動くのか」という問いを立て、仮説を作る。その仮説をプロトタイプとして試す。結果を見てまたデータと感性の対話を繰り返す。 このサイクルは「分析か直感か」の二項対立の外にある。両方を材料として使いながら、どちらか一方では届かない解を生み出す。 ファシリテーターとしてのリーダー デザイン思考を組織に実装するリーダーには、もう一つの役割がある。ファシリテーターとしての機能だ。 マーティンが言う統合的思考は、個人の能力として語られることが多い。しかし組織では、チームの思考を統合する役割がリーダーに求められる。異なる専門性を持つメンバーが「自分の専門分野の最適解」を持ち寄るとき、リーダーはそれを単純に足し合わせたり多数決で決めたりするのではなく、矛盾する意見の中から第三の解を引き出す対話を設計する。 この意味で、デザイン思考のリーダーシップはコンテンツ（何を決めるか）よりプロセス（どう考えるか）に重心を置く。答えを持っているリーダーより、チームが答えに辿り着くプロセスを設計できるリーダーが、不確実な問題には強い。 デザイン思考のファシリテーターとして実践的なスキルを学ぶには、こちらを参照してほしい。 「知識ファネル」をリーダーシップ開発に使う マーティンの知識ファネルは、チームや個人の成長の見取り図としても機能する。 あるチームメンバーが「ミステリー」の段階にいるとき、リーダーが期待すべきアウトプットは「答え」ではなく「問いの設定」だ。何が分からないのかを言語化できているか、どこを探索しようとしているかを確認する。ここで「答えを出せ」と迫ることは、ファネルの段階を無視した評価になる。 「ヒューリスティック」の段階では、経験則が積み上がっているかを確認する。「あの時こうしたらうまくいった」「このパターンだと失敗しやすい」という感覚が言語化できるか。それはまだ人から人へ伝達できる形にはなっていないが、実践の中に確かに存在している。 「アルゴリズム」になったとき、初めて標準化や拡張の話ができる。マニュアルを作る、他のチームに展開する、自動化する——これはアルゴリズム段階の仕事だ。ヒューリスティックをアルゴリズム化しようとすると、表面的な手順は書けても、判断の根拠が伝わらないものができあがる。 リーダーがメンバーの知識がどの段階にあるかを把握し、段階に応じた問いを立てることが、デザイン思考を活かした育成の実態になる。 統合的リーダーシップが問われる場面 抽象的な能力論として読むより、具体的な場面で考えた方が使える。 新規事業の意思決定。財務モデルが示す収益予測と、現場観察から掴んだユーザーの行動原理が矛盾している。分析的思考は「数字が出ないなら止める」と判断する。直感的思考は「でもこれは確かにニーズがある」と主張する。統合的思考のリーダーはどちらかを選ばず、「なぜ数字と観察が矛盾するのか」という問いを立てる。そこに、現在の財務モデルが捉えていない何かがある可能性を探る。 チームの対立の解消。「スピードを上げるべき」派と「品質を守るべき」派が対立している。どちらも正しい。しかし「スピードか品質か」という問いは統合的思考の入口ではない。「いつのタイミングで何の品質が最も重要か」「どのプロセスがスピードと品質の両立を可能にするか」という問いに変えると、対立が思考の材料になる。 不確実な市場への参入判断。データが足りない。競合の動きが読めない。だから決められない、という状態で止まるか、「いま持っている観察から最善の仮説を立て、小さく試す」方向に動くか。マーティンのナレッジファネルで言えば、ミステリーの段階で完璧な答えを求めることをやめ、ヒューリスティックを積み上げながら前進する判断だ。 --- デザイン思考をリーダーシップの文脈で語るとき、よく起きる誤解がある。「クリエイティブな人間のための考え方」という読み方だ。しかしマーティンもケリーも、そう言っていない。 統合的思考は「分析を捨てて感性に従う」ことではなく、「分析と感性を同じ問いの場に引き込む」ことだ。クリエイティブ・コンフィデンスは「誰でも芸術家になれる」という話ではなく、「自分にも変化を起こせるという信念を取り戻す」という話だ。 どちらも、既存の選択肢の中でベターを選ぶことではなく、まだ存在しない解を生み出すために必要な思考の構え方を問うている。ミステリーに立ち向かうことを組織の文化にしたいなら、その構えをリーダー自身が持つことから始まる。 参考文献 - Roger Martin, The Design of Business: Why Design Thinking Is the Next Competitive Advantage, Harvard Business Review Press, 2009 - Tom Kelley and David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 - Roger Martin, The Opposable Mind: How Successful Leaders Win Through Integrative Thinking, Harvard Business Review Press, 2007 - Nigel Cross, Design Thinking: Understanding How Designers Think and Work, Berg Publishers, 2011 --- ### デザイン思考と社会的インパクト——NPO・ソーシャルセクターへの応用と限界 URL: https://designthinking.studio/articles/design-thinking-social-innovation-nonprofit/ > Tim BrownとJocelyn Wyattが2010年のSSIRで示した命題——デザイン思考は貧困・教育・医療などの複雑な社会課題に適用できるか。IDEO.orgの実践と、ソーシャルセクター特有の制約から、この問いを解析する。 「デザイン思考はビジネスの道具だ」という誤解がある。 デザイン思考を世に広めたIDEOのCEO、Tim Brownが2010年にStanford Social Innovation Review（SSIR）に寄稿した論文のタイトルは "Design Thinking for Social Innovation" だった。共著者はJocelyn Wyatt——後にIDEO.orgのエグゼクティブ・ディレクターとなる人物だ。 その主張は明快だった。企業が先に採用したこのアプローチを、NPOや社会起業家も使い始めている。そしてソーシャルセクターこそ、デザイン思考が真価を発揮できる場かもしれない。 --- なぜ社会課題にデザイン思考が必要なのか 社会課題の多くは、ユーザーニーズの深い理解が欠如したまま解決策が設計されることで悪化する。 途上国の農村に清潔な水を届けようとして、専門家が設計した給水設備が誰にも使われないまま放置される事例は繰り返し報告されている。農村住民がなぜその設備を使わないのか——本人たちに聞けば分かる理由が、「解決策」を外から持ち込む設計思想では見えなかった。 NGOや国際開発の文脈で問題設定が外部の「専門家」によってなされ、現地の文化・習慣・信頼構造を無視した形で実装されると、技術的には正しいソリューションが「受け入れられないもの」として機能しなくなる。これは顧客理解の幻想と同じ構造だ。 デザイン思考が社会課題に持ち込むものは、「解決策を持ち込む前に、当事者の生活を観察し、当事者の言葉で問題を再定義する」プロセスの規律だ。 --- IDEO.orgの設立と「HCDツールキット」 2011年、IDEOはソーシャルセクター専門の組織としてIDEO.orgを設立した。Brown＆Wyattの2010年論文の翌年だ。 IDEO.orgが最初に行った行動の一つは、「Human-Centered Design（HCD）Toolkit」を無償で公開することだった。このツールキットはIDEOのデザイン思考プロセスを、リソースが限られたNPOでも実践できる形に再設計したものであり、エンジニアーズ・ウィザウト・ボーダーズ、ヒーファー・インターナショナル、Acumen Fundなど数十の組織が使用した。公開後、世界のNPO・ソーシャルイノベーション実践者のコミュニティに広く受け入れられ、数万件規模でダウンロードされたと伝えられている。 IDEO.orgが初期に取り組んだプロジェクトの一つが、Acumen FundおよびBill & Melinda Gates財団との協働による「Ripple Effect」プロジェクトだ。安全な飲料水へのアクセス改善を目的としたこの取り組みは、エチオピアのリフトバレーでのフッ素除去浄水システム設計など、50万人以上の人々に影響を与えたとされる。 --- ソーシャルセクターに固有の3つの設計条件 ビジネスとソーシャルセクターでは、デザイン思考を実践するうえでの条件が異なる。この差異を理解していないと、手法を移植しただけで効果が出ない。 条件1: ユーザーとステークホルダーの多層性 企業のプロジェクトでは、ユーザー（顧客）と意思決定者（経営者）の関係は比較的単純だ。対してNGOや社会変革プロジェクトでは、直接のサービス受益者・現地コミュニティ・政府機関・国際ドナー・パートナー組織が同時に存在し、それぞれが異なる利害を持つ。 どのステークホルダーの「声」を「ユーザーの声」として優先するかの判断が、プロジェクトの方向性を決定的に左右する。共感マッピングをだれに対して行うかが、そのまま価値判断になる。 条件2: 財源制約とスケールの逆説 ビジネスでは、プロトタイプが機能すれば追加投資でスケールできる。NPOでは、ファンディングのサイクルと報告義務が「実験を続ける余力」を構造的に奪う。ドナーの多くは「証明された手法」に資金を出す傾向があり、「まだ機能するか分からないがプロトタイプを試したい」というデザイン思考の最も重要な局面が、財源の論理と衝突する。 IDEOのTom Kelleyが『発想する会社！』で語った「fail often to succeed sooner」という哲学は、失敗が予算消化として記録されるNPOの文脈では、そのまま採用できない。 条件3: 成果指標の時間軸 社会課題の解決は、製品リリースのような明確な「完了」を持たない。教育格差の縮小、地域コミュニティの自立——これらの成果が現れるまでには数年から十数年かかる。デザイン思考の反復サイクルが前提とする「短期の検証フィードバック」が機能しにくい時間軸に存在する課題が多い。 --- 実践上の4つの適応ポイント これらの制約を踏まえると、ソーシャルセクターでデザイン思考を機能させるには4つの適応が必要になる。 共感の拡張——「当事者参加型デザイン」 観察者としての共感を超えて、課題の当事者がデザインプロセスそのものに参加するアプローチが有効だ。Participatory Design（参加型デザイン）と呼ばれるこの手法では、解決策のエンドユーザーが最初のブレインストーミングからプロトタイプ評価まで関与する。当事者の知恵が設計に内包されるため、「使われないソリューション問題」が起きにくくなる。 プロトタイプの「低コスト化」 スケッチ、ロールプレイ、紙のモックアップ——道具と時間を最小化したプロトタイプを「正式な手法」として組織内に定着させることが重要だ。ペーパープロトタイピングの発想は、予算制約の厳しいNGO環境に特に適合する。 「問題定義のプロセス」だけを先に届ける デザイン思考の5フェーズ全部を一度に持ち込もうとすると、組織の負荷が大きすぎる。HMW（How Might We）問いの設定フェーズだけを先に導入し、「問題の言い換え」から始める段階的アプローチが定着しやすい。 失敗を共有する文化の設計 ドナーへの報告が「成果の見せ方」に引きずられる組織文化では、機能しなかったプロトタイプの知見が組織内に蓄積されない。失敗を安全に共有できる内部の振り返り機構をデザインすることが、デザイン思考プロセスの継続を支える。 --- 「デザイン思考の植民地化」への批判 2010年代後半から、ソーシャルセクターでの人間中心設計に対する批判的言説も登場してきた。 デザイン思考のファシリテーターが課題の当事者ではなく外部の専門家であり続ける限り、どれほど「共感」を掲げても権力関係は変わらない——という指摘だ。「Design Justice」（デザイン正義）を提唱するSasha Costanza-Chockらは、2020年の著書でこの問題を正面から論じた。 誰がデザインプロセスを主導するか、誰の「ユーザーニーズ」を中心に置くかという権力の問題は、手法論では解決しない。これはデザイン思考の「限界」というより、「使う主体と文脈の問題」だ。 --- ソーシャルイノベーションにデザイン思考が残した遺産 Tim BrownとJocelyn Wyattが2010年のSSIRで示した命題——「デザイン思考をソーシャルセクターへ」——は、その後10年以上の実践によって検証された。 結論は単純ではない。機能した事例も、機能しなかった事例も、双方が積み上がっている。しかしひとつ確かなことがある。「ユーザーに共感する前に解決策を作るな」という原則が、国際開発・NPO・社会起業の現場に持ち込まれたことの意味は小さくない。 道具は文脈に依存する。しかし「まず聞け」という姿勢は、課題の規模や組織の形態に関係なく、機能する。 --- 参考文献・出典 - Brown, T., & Wyatt, J. (2010). Design Thinking for Social Innovation. Stanford Social Innovation Review, Winter 2010. https://ssir.org/articles/entry/designthinkingforsocialinnovation - IDEO.org, "Addressing Poverty through Human-Centered Design" (Core77, 2011). https://www.core77.com/posts/18714/announcing-ideoorg-addressing-poverty-through-human-centered-design-18714 - NextBillion, "Insights Into IDEO.org". https://nextbillion.net/insights-into-ideoorg/ - Costanza-Chock, S. (2020). Design Justice: Community-Led Practices to Build the Worlds We Need. MIT Press. --- 関連記事 - 顧客理解の幻想——「ユーザーを知っている」という罠 - デザイン思考への批判を読み解く - ティム・ブラウン——IDEOとデザイン思考の普及 - サラ・ベックマン——UCバークレーでデザイン思考教育を確立した先駆者 - Wicked Problems（手に負えない問題）とデザイン思考 --- ### デザイン思考と認知バイアス——共感・発散フェーズを歪める8つの罠 URL: https://designthinking.studio/articles/design-thinking-cognitive-bias/ > 確証バイアス・フレーミング効果・集団思考など、デザイン思考の共感・問題定義・発散フェーズを歪める8つの認知バイアスを実例と共に解説。ワークショップで発動するタイミングと、構造的な対処法を示す。 ユーザーインタビューを重ねたのに、結局チームが「最初から想定していた解決策」へ収束していく。ブレインストーミングで「奇抜なアイデア」が出ても、最終的には「無難なもの」しか残らない。 これは意志や熱量の問題ではない。認知バイアスが構造的に発動している。 認知バイアスは「弱い人間が陥る罠」ではなく、人間の脳が効率的に処理するための省エネ機能の副作用だ。デザイン思考のプロセスはその性質上、複数のバイアスが連鎖的に発動しやすい。バイアスを知ることは、それを「意志で克服する」ためではなく、発動しにくいプロセス設計に活かすためだ。 --- なぜデザイン思考はバイアスに脆弱なのか デザイン思考の各フェーズは、高い認知負荷を伴う。ユーザーの発言を解釈し、チームで意味を共有し、不確実な状況で判断を下す——この連続が、バイアスの温床になる。 特に3つの構造が問題を複雑にする。 第一は「解釈の介在」。ユーザーの言葉は常に解釈を通して受け取られる。観察者の経験・価値観・仮説がフィルターになり、同じ発言でも異なる意味が抽出される。 第二は「チームによる意味の収束」。個人のバイアスが、グループダイナミクスによって増幅される。リードする声が大きい人物の解釈に引き寄せられ、異論が出にくくなる。 第三は「時間圧力と確実性の欲求」。ワークショップの時間制約が、「結論を出さなければならない」という心理的プレッシャーを生む。不確実さへの耐性が下がり、早期に解釈を固定しようとする。 --- 共感フェーズを歪める3つのバイアス バイアス1：確証バイアス（Confirmation Bias） すでに持っている仮説や信念を支持する情報を優先的に集め、矛盾する情報を軽視する傾向。 デザイン思考の現場では、インタビューガイドの設計段階から発動する。「ユーザーはXに困っているはずだ」という仮説を持ってインタビュー設計をすると、Xに関連する質問が自然と多くなる。Y・Zに関する困りごとは聞かれないまま終わる。 Daniel Kahnemanが『ファスト＆スロー（Thinking, Fast and Slow）』（2011年）で示したように、確証バイアスは「思考のシステム1（直感・速い処理）」が主導する。対策には「思考のシステム2（論理的・遅い処理）」を意図的に発動させる設計が必要だ。 発動パターン：ユーザーが「不満を感じている」という発言に注目し、「満足している」という発言を「例外」として処理してしまう。 構造的対処：インタビュー前に「この仮説が間違っていることを証明するとしたら、どんな発言が出るはずか」を書き出す。その発言に注意を払うよう自分に指示する。d.schoolでは「Disconfirming Evidence（反証証拠）」を意図的に探すインタビュープロトコルを推奨している。 バイアス2：フレーミング効果（Framing Effect） 同じ情報でも、提示の文脈（フレーム）によって判断が変わる効果。1981年にAmos TverskyとDaniel Kahnemanが発表した研究で確立された概念だ。 インタビューの問いかけ方が、回答を決定的に変える。「このサービスを使って困ったことはありますか？」という問いと「このサービスを使って助かったことはありますか？」という問いでは、ユーザーが同じ体験について語るとき、引き出される情報が異なる。 発動パターン：「この機能は便利だと思いますか？」という問いは、ユーザーに「便利である」という文脈でサービスを評価させる。ユーザーが本来感じていた「面倒さ」「わかりにくさ」が浮かびにくくなる。 構造的対処：オープンクエスチョンを徹底する。「〜だと思いますか？」という確認型を避け、「最後に〜を使ったのはどんな状況でしたか？」という行動・文脈型に切り替える。Nielsen Norman Groupの推奨するコンテキスト質問法（contextual questioning）が参考になる。 バイアス3：ハロー効果（Halo Effect） 対象の一部の特性が、全体の評価を歪める効果。インタビュイーの「話し方」「職種」「服装」といった第一印象が、その発言の信頼性評価に影響する。 「洗練されたビジネスパーソン」から聞いた課題は「重要なインサイト」として、「言葉が出にくい高齢者」から聞いた課題は「表面的な不満」として処理されてしまう。これは主観的な評価であっても、記録や共有のプロセスで見えにくくなる。 構造的対処：インタビュー後の即時メモを「発言そのもの」に限定する。話者の属性（年齢・職種・雰囲気）に関する形容詞を含まない記録ルールをチームで設ける。誰が言ったかを伏せた状態でインサイトを評価する「ブラインド評価」を挿入するプロセス設計が有効だ。 --- 問題定義フェーズを歪める2つのバイアス バイアス4：アンカリング効果（Anchoring Effect） 最初に提示された情報が、その後の判断の基準点（アンカー）になる効果。インタビュー結果を共有するミーティングで最初に発言した人の解釈が、チーム全体のインサイト定義に影響を与える。 発動パターン：ワークショップのオープニングで「ユーザーAはXが使いにくいと言っていた」という発言が出ると、その後のディスカッションはXの改善を前提とした問題定義に収束しやすくなる。 構造的対処：アフィニティダイアグラムのセッション開始時に、発言ルールを明示する。「最初の10分間は全員がサイレントで付箋を書く」という段階を設け、他者のアンカーが入る前に個人の解釈を固定させる方法が効果的だ。IDEOが推奨するサイレント・クラスタリング手法がこれに当たる。 バイアス5：利用可能性ヒューリスティック（Availability Heuristic） 記憶に引き出しやすい情報（頻度・鮮明さ・最近性）を、重要度が高い情報として扱う傾向。TverskyとKahnemanが1973年に論文で記述した。 インタビュー結果を分析するとき、「印象的だったエピソード」「感情的に共鳴した発言」が優先的に問題定義に使われる。統計的に頻度が高い課題ではなく、「ストーリーとして語りやすい課題」が問題定義に選ばれるリスクがある。 構造的対処：インサイトのグルーピング後に「このグループに含まれる発言は何件か」を数える定量確認を挿入する。印象の強さと頻度を切り分けて評価するステップを構造化することで、バイアスの影響を縮小できる。 --- 発散フェーズを歪める3つのバイアス バイアス6：集団思考（Groupthink） 集団の結束を保つために、異論や批判的視点が抑制される現象。社会心理学者Irving Janisが1972年に提唱し、「ケネディ政権のピッグス湾侵攻失敗」の分析で知られる概念だ。 ブレインストーミングは「批判禁止」を大前提にするが、それが集団思考を防ぐわけではない。「場の空気を読む」圧力が、そもそもアイデアの発語を抑制する。声の大きい人物が出したアイデアへの批判は避けられ、全体のアイデアの多様性が狭まる。 構造的対処：ブレインストーミング前に個人でアイデアを書き出す「ブレインライティング（Brainwriting）」を挟む。集団での発言より先に個人思考を固定させることで、外部からの影響を受ける前のアイデアを保存できる。IDEO、d.schoolともにこのアプローチを採用している。 バイアス7：現状維持バイアス（Status Quo Bias） 変化よりも現状を好む傾向。経済学者William Samuelsonと Richard Zeckauserが1988年の論文で定式化した概念だ。アイデアの評価段階で強く発動する。 発動パターン：投票や選考のフェーズで、「既存サービスの改善案」は受け入れられやすく、「ビジネスモデルを根本から変えるアイデア」は「リスクが高い」「現実的でない」と評価されやすい。 構造的対処：評価基準を事前に書き出すことで、無意識の「現実的かどうか」判断を遅らせる。「もし制約がないとしたら」という仮定を明示的に設定するルールを入れることで、現状維持バイアスの発動を構造的に遅らせることができる。 バイアス8：損失回避バイアス（Loss Aversion） 同程度の利得より損失を大きく感じる傾向。KahnemanとTverskyのプロスペクト理論（1979年）の中核概念だ。 アイデア評価において、「このアイデアを採用したら失うもの」が「このアイデアで得られるもの」より強く意識される。「現行プロセスが使えなくなる」「今の担当者が不要になる」という損失が、アイデアの評価を無意識に引き下げる。 構造的対処：評価シートに「このアイデアがもたらす利得」と「損失」を別々に書き出す欄を作り、バランスを見える化する。損失の大きさと確率を分離して考える「期待値評価」をファシリテーターが促すことで、感情的な損失回避の影響を縮小できる。 --- バイアス対策を内蔵したプロセス設計 個別のバイアスへの対処より効果的なのは、バイアスが発動しにくいプロセスを最初から設計することだ。 実践的には、以下の3原則が機能する。 「個人→集団」の順序を守る。グループに先立ち個人が考える時間を常に設ける。これだけで確証バイアス・アンカリング・集団思考の影響を同時に縮小できる。 「反証」を構造に組み込む。インタビューガイド・インサイト評価・アイデア選考のそれぞれに「この解釈が間違っている場合、どんな証拠があるか？」という問いを挿入する。 「評価者を変える」。インタビューを実施したチームとインサイトを評価するチームを分けることで、ハロー効果と利用可能性ヒューリスティックの影響を構造的に減らせる。完全な分離が難しい場合も、「インタビューに関与していない人の視点」を意図的にセッションに持ち込む。 --- デザイン思考が「人間中心」であるとは、ユーザーを中心に置くことだけを意味しない。設計・評価・判断を行う実践者自身の認知の歪みを理解し、それを補正する仕組みをプロセスに組み込むことも含む。 バイアスは克服するものではない。一緒に作業しながら、その影響を最小化する設計を積み重ねることが、デザイン思考実践者に求められるメタスキルだ。 --- 参照文献 - Kahneman, D. (2011). Thinking, Fast and Slow. Farrar, Straus and Giroux. - Tversky, A., & Kahneman, D. (1973). Availability: A heuristic for judging frequency and probability. Cognitive Psychology, 5(2), 207–232. - Tversky, A., & Kahneman, D. (1979). Prospect theory: An analysis of decision under risk. Econometrica, 47(2), 263–291. - Tversky, A., & Kahneman, D. (1981). The framing of decisions and the psychology of choice. Science, 211(4481), 453–458. - Janis, I. L. (1972). Victims of Groupthink. Houghton Mifflin. - Samuelson, W., & Zeckhauser, R. (1988). Status quo bias in decision making. Journal of Risk and Uncertainty, 1(1), 7–59. - Nielsen Norman Group. (n.d.). User Interviews: How, When, and Why to Conduct Them. nngroup.com. --- ### デザイン思考のB2B導入実務──エンドユーザー不在の現場で何を捨てるか URL: https://designthinking.studio/articles/design-thinking-b2b-adoption/ > B2B領域でデザイン思考を使うとき、最初に壁になるのは「誰に共感するか」という問いだ。買う人・使う人・決める人が分離した構造で、何を諦め、何を強化するかを実務の視点から解説する。 B2Cの文脈で設計されたデザイン思考のメソッドをそのままB2Bに持ち込むと、最初の共感フェーズで詰まります。 「エンドユーザーにインタビューしてください」と言われても、顧客企業の現場担当者には会えない。あるいは会えたとしても、その人が「採用の決定権を持っているか」が分からない。B2B特有のこの構造的な問題を無視したまま5フェーズを進めると、「ユーザーには喜ばれたが稟議が通らなかった」という典型的な失敗が待っています。 デザイン思考をB2Bで機能させるには、いくつかのことを意図的に捨て、いくつかのことを強化する必要があります。 B2B特有の構造：なぜ共感が難しいのか B2Cのデザイン思考が前提にしているのは「課題を抱えた個人」です。その人に会い、その人の体験を深く理解し、その人の生活を改善するためのソリューションを作る。このシンプルな構造が、B2Bでは成立しません。 B2Bには「顧客」が少なくとも3層に分離しています。 - 購買担当（バイヤー）：ベンダー選定・予算管理・稟議書を書く人 - 現場ユーザー：実際にプロダクトを使う人 - 意思決定者（エグゼクティブ）：最終的に「GO」を出す人 この3者は異なる職階にいて、異なる評価基準を持ち、異なる情報源で判断します。購買担当は比較表とコストで判断し、現場ユーザーは操作性とワークフローへの適合で判断し、意思決定者は投資対効果と組織リスクで判断する。 ワークショップでよく起こるのは、現場ユーザーにインタビューして「この機能があれば使いやすい」というインサイトを丁寧に積み上げたのに、意思決定者が「それでROIはどうなるんですか」と聞いて話が止まるパターンです。ユーザーの課題は解けているのに、組織の問いに答えていない。 さらに、B2B特有の時間軸の問題があります。顧客企業の意思決定サイクルは3ヶ月から1年以上かかることが珍しくありません。「ラピッドプロトタイピング」を旗印にした2週間スプリントは、承認プロセスの最初の関門さえ通過できない速度感で設計されています。 何を捨てるか - 「個人の喜び」を最終ゴールにする甘さ B2Cでは「このプロダクトを使った人が笑顔になるか」が最終的な判断基準になり得ます。B2Bではそれは必要条件でしかありません。現場ユーザーが使いやすいと感じていても、それが組織の業務KPIに接続されていなければ、導入の根拠になりません。 感情的な価値をゴールとして設定することをやめ、「この課題が解決されると、組織のどの指標が動くか」を最初に問うことに切り替えます。 - ラピッドプロトタイピングの「速度」 「とにかく速く作って反応を見る」という文化は、B2B文脈では逆効果になることがあります。精度が低いプロトタイプを持ち込むと、それ自体が「このベンダーは本当に分かっているのか」という不信感を生みます。 B2Bでは速度よりも精度のトレードオフを意識的に選びます。プロトタイプは「動くもの」より「判断できるもの」として設計する。ROIの試算シート、導入後のオペレーション変化を示したビジュアルフロー、既存システムとの接続イメージ——これらが「B2Bのプロトタイプ」になります。 - エンドユーザー1名への深掘り 1名のユーザーを徹底的に理解することは、B2Cのデザイン思考では強力な手法です。B2Bでは、その1名が「組織のどのポジションにいるか」を無視すると危険です。 現場ユーザーの課題と購買担当の課題は別物です。それを統合して捉えないまま進むと、「買う人を説得できない解決策」が出来上がります。 何を強化するか DMU（意思決定ユニット）単位の共感マップ B2Bのリサーチ設計の起点は、「誰に会うか」を組織構造から考えることです。マーケティング学者のフィリップ・コトラーらが整理した DMU（Decision Making Unit） の概念がここで役立ちます。購買の意思決定に関与する人物の役割を——イニシエーター・インフルエンサー・デシジョンメーカー・バイヤー・ユーザー・ゲートキーパー——に分類し、それぞれが「何を心配しているか」「何で判断するか」を把握します。 共感マップを個人単位ではなくDMU単位で作ることで、「誰のどの課題を解くと、最も意思決定が前に進むか」が見えてきます。 Jobs-to-be-Done（機能的ジョブ）の精緻化 クレイトン・クリステンセンが提唱し、アンソニー・ウルウィック（Anthony Ulwick）がOutcome-Driven Innovationとして体系化した Jobs-to-be-Done（JTBD） の視点は、B2Bデザイン思考に特に有効です。 B2B文脈では、顧客のジョブを「機能的ジョブ」「感情的ジョブ」「社会的ジョブ」に分離することが重要です。購買担当の機能的ジョブは「適切なベンダーを選定して稟議を通すこと」ですが、感情的ジョブは「失敗のリスクを取りたくないこと」であり、社会的ジョブは「自分の評価を守ること」かもしれません。 実際にやってみると、感情的ジョブへの対処（「このベンダーを選んで失敗した場合の責任はどう説明できるか」という不安の解消）が、機能的な優位性よりも購買判断を動かすことが多い。これはBtoB特有の「リスク回避」心理が購買動機の中心にあることを意味しています。 Value Proposition Design との統合 アレックス・オスターワルダー（Alexander Osterwalder）らの Value Proposition Design は、デザイン思考のツールキットと高い親和性を持ちます。「バリュープロポジションキャンバス」の「カスタマープロファイル」（やること・悩み・うれしいこと）と「バリューマップ」（製品・ゲインクリエーター・ペインリリーバー）の対応関係を整理するフレームは、B2Bのエンパシーマップとして機能します。 DMU上の各ステークホルダーごとにバリュープロポジションキャンバスを作成することで、「この人には何が刺さるか」をロールごとに整理できます。 ROIストーリーテリングとしてのプロトタイピング B2Bのプロトタイプは「体験させるもの」から「判断させるもの」にシフトします。具体的には「ペーパーROIプロトタイプ」という手法が有効です。 仮定の数値を使って「このソリューションを導入した場合、業務Xに費やす時間がY時間/週削減され、年換算でZ円のコスト削減になる」という試算を1枚にまとめたドキュメントです。数値の正確性よりも「どの変数を動かすと効果が出るか」という構造を示すことが目的です。 参加者からの声として多いのは、「数値が100%正確でなくても、試算の構造が見えると意思決定者との会話が変わる」というものです。意思決定者に「面白いですね」と言わせることより、「この前提で考えると我々の場合はどうなるか」という問いを引き出すことがゴールです。 実務ステップ：B2Bデザイン思考の5ステップ Step 1: DMUマッピング 顧客組織の意思決定に関与する人物を洗い出し、購買プロセスにおける各人の役割・判断基準・懸念事項を整理します。図示するなら組織図の上に「誰がGOを出すか」「誰がNOを出せるか」を重ねるイメージです。 所要時間の目安は、既存顧客情報をベースに1〜2時間。新規開拓の場合は仮説ベースで作成し、初期の顧客接点で検証します。 Step 2: ロール別ジョブの分離 DMU上の各ロールについて、機能的ジョブ・感情的ジョブ・社会的ジョブを書き出します。 - 購買担当：稟議を通すこと（機能）／失敗リスクを回避すること（感情） - 現場ユーザー：業務を効率化すること（機能）／既存の作業を壊されたくないこと（感情） - 意思決定者：組織の競争力を高めること（機能）／投資の正当性を説明できること（社会） 感情的ジョブと社会的ジョブへの対処を解決策設計に組み込むことで、「論理的には正しいが組織が動かない」という壁を超えられます。 Step 3: ペーパーROIプロトタイピング 解決策の骨格が固まった段階で、ROI試算の構造を1枚のドキュメントに整理します。変数は「業務時間の削減」「エラー率の低下」「リードタイム短縮」など測定可能なものを選びます。 重要なのは仮定を明示することです。「前提：1名あたり週3時間の作業削減と仮定した場合」と書くことで、顧客が自社の数値を当てはめて考えられる余地を作ります。 Step 4: ステークホルダー別ストーリーテリング 同じソリューションでも、誰に話すかによって強調すべき価値が異なります。現場ユーザーには「操作性と既存ワークフローへの統合」、購買担当には「比較優位とコスト構造」、意思決定者には「ROIと導入リスクの最小化」を軸にしたナラティブを準備します。 ワークショップでよく起こるのは、「素晴らしいプロダクトを作ったのにどこに行っても同じ話をしてしまう」というパターンです。ステークホルダー別にメッセージを変えることは「嘘をつく」ことではなく、「その人が判断に必要な情報を適切な言語で届ける」ことです。 Step 5: パイロット導入と学習ループ B2B文脈での「テスト」は、限定的な範囲での本番導入として設計します。「全社展開前に1部門で3ヶ月試す」という構造が、顧客にとっても意思決定のリスクを下げ、自社にとっても実データで学べる機会になります。 学習ループの設計で重要なのは、「何を測定するか」を導入前に合意しておくことです。3ヶ月後に何の数値が何%変化したら「成功」と見なすか。この合意がないと、テストフェーズの終わりに「評価基準が違う」という議論が始まります。 実在する B2B デザイン思考の取り組み Salesforce のデザイン実践 Salesforceは、エンタープライズ製品のUX改善においてデザイン思考を組織的に取り入れています。Lightning Design System（LDS）の開発において、Salesforceのデザインチームは企業の管理者・エンドユーザー・開発者という異なるロールへのリサーチを組み合わせ、統一されたデザイン言語として結晶化させました。LDSの設計思想として公開されている原則には、「業務の文脈から切り離さない」という指針が繰り返し登場します。 Adobe の企業向けプロダクト設計 Adobe は2012年頃からCreative Cloudへの移行を進め、それに伴い企業向け製品（Adobe Experience Cloud等）の設計においてユーザーリサーチを体系化してきました。Adobe の公開している設計プロセスでは、企業のIT管理者・マーケティング担当・クリエイターという異なるステークホルダーのニーズを並行してリサーチする構造が示されています。エンタープライズ向けの製品において「意思決定者とエンドユーザーのニーズが異なる」という構造的な問いに正面から向き合ってきた事例です。 SAP のデザイン思考プログラム SAP は2000年代後半から自社内にデザイン思考の実践拠点（Design Thinking Centers）を複数設立し、顧客企業との共同ワークショップを提供しています。SAP のアプローチは「顧客企業の内部に入ってワークショップを実施する」という形式で、購買担当・IT部門・現場ユーザーを一堂に集めたセッションを行います。異なる立場の人が同じ部屋で「自分たちの業務の課題」を言語化するプロセス自体が、DMU内の合意形成を促す機能を持っています。 SAP のDesign Thinking手法は、同社のイノベーション担当（SAP AppHaus等）が事例を含めて公開しており、エンタープライズ領域でのデザイン思考実践として参照価値があります。 B2Bデザイン思考の本質 B2C向けに設計されたデザイン思考を「そのまま使えない」と感じるのは、方法論の問題ではなく「誰を中心に置くか」の問いに答えられていないからです。 B2Bで「ユーザー中心」を維持するには、「ユーザー」を「組織の意思決定に関与する全ての人」として再定義する必要があります。エンドユーザー1名の深い共感は捨てず、しかしその共感を「組織が動く言語」に翻訳するプロセスを加える。この拡張が、B2Bデザイン思考の核心です。 「個人の喜び」から「組織の意思決定」への翻訳作業。これは理論的には地味ですが、実務の現場ではここで8割の勝負が決まります。 金融サービス固有の適用事例については金融サービスにおけるデザイン思考で詳しく論じている。規制・リスク回避文化という制約の中でどう実装するか、具体的なロードマップが参照できる。 --- 参考文献 - Alexander Osterwalder & Yves Pigneur, Value Proposition Design, Wiley, 2014 - Anthony Ulwick, Jobs to Be Done: Theory to Practice, Idea Bite Press, 2016 - Philip Kotler & Kevin Lane Keller, Marketing Management, 15th ed., Pearson, 2016（DMUの概念整理） - Tim Brown, Change by Design, HarperBusiness, 2009 - SAP AppHaus, "Design Thinking at SAP", sap.com/apphaus（公開情報） - Salesforce, "Lightning Design System Documentation", lightningdesignsystem.com（公開情報） --- ### デザイン思考のユーザーテスト手法完全ガイド｜5つの検証技法と現場実践 URL: https://designthinking.studio/articles/design-thinking-user-testing-methods/ > デザイン思考のテストフェーズで使うユーザーテスト手法を5つ体系化。モデレーテッドテスト・シンクアラウドプロトコル・5秒テスト・A/Bテスト・ゲリラテストの設計法と、ワークショップ現場での失敗・学びを解説。 「プロトタイプは作れた。でも、どうテストすればいいか分からない」——このフェーズで手が止まるチームは、ワークショップの現場でも決して少なくない。 デザイン思考の5フェーズの中で、テストフェーズは最もスキップされやすいステップだ。プロトタイプを作り終えた達成感、「もう少し完成度を上げてからテストしよう」という先延ばし、テスト設計の方法を知らないことによる停滞。こうした理由が重なって、テストは省略されるか、身内だけのレビューに終わる。 実際にやってみると分かるのだが、不完全なプロトタイプで行うテストほど、多くの学びをもたらす。完成度が低いほど、ユーザーは「ここが分からない」「こう使いたい」という本音を出してくれる。本記事では、デザイン思考のテストフェーズで使える5つの手法と、現場で積み上げたファシリテーションの知見を体系的に紹介する。 --- なぜテストフェーズは省略されるのか ワークショップでよく起こるのは、プロトタイプ制作に時間をかけすぎて、テストの時間が残らないパターンだ。半日のワークショップで付箋からアイデアを発散させ、午後にプロトタイプを作り始めると、発表と振り返りの時間だけで終わる。 テストを「最後に行うもの」と捉えることが、そもそもの誤解だ。 スタンフォード大学d.schoolの提唱するデザイン思考では、テストはプロセス全体に組み込まれた反復的な活動として設計されている。初期の概念スケッチを見せてフィードバックを得ること自体が、テストの一形態だ。 参加者からの声として多いのは、「ユーザーに見せるのが怖い」という感情的な障壁だ。自分たちが時間をかけて作ったものを否定されることへの恐怖が、テストの実施を遅らせる。しかしこの「否定」こそが、プロトタイプフェーズにおける最大の学習資産だ。 --- ユーザーテスト手法5選 - モデレーテッドユーザビリティテスト 最も標準的なユーザーテストの形態だ。ファシリテーター（モデレーター）がユーザーの隣に座り、タスクを与えながら行動を観察する。 観察しながらリアルタイムで質問を追加できるため、想定外の行動に対してその場で「なぜそうしたのですか？」と深掘りができる。 設計のポイントは「タスクシナリオ」の作り込みだ。「このアプリを使ってください」という曖昧な指示ではなく、「初めて利用する会員として、30分後に友人と会う約束をするまでの操作をしてください」のような、具体的な状況とゴールを設定する。ユーザーが実際の使用状況に近い文脈で操作することで、より本音に近い行動が観察できる。 セッションは1人45〜60分、5〜8名のユーザーで実施するのが一般的だ。ニールセン・ノーマン・グループの研究では、5名のテストで主要なユーザビリティ問題の約85%が発見できるとされている（Nielsen, 1993）。 - シンクアラウドプロトコル ユーザーが操作しながら「今何を考えているか」を声に出してもらう手法だ。頭の中で起きていることをそのまま言語化してもらうことで、ユーザーの認知プロセスと期待を可視化する。 ユーザビリティテストと組み合わせて使われることが多い。 「シンクアラウド（Think Aloud）」の手法はEricssonとSimon（1984年）による認知心理学研究で心理学的基盤が確立され、ヤコブ・ニールセンらによってヒューマン・コンピュータ・インタラクション研究の標準的プロトコルとして普及した。 実際にやってみると、ユーザーが「あれ、なんかここ変だな」と口にした瞬間が最も価値ある観察になる。問題を発見するよりも、ユーザーの思考のズレを観察することに主眼を置くと、インサイトの質が上がる。 ファシリテーターは「正解を教える」衝動を抑えることが最大の技術的課題だ。 - 5秒テスト プロトタイプやデザインモックを5秒間だけ見せ、その後「何が印象に残りましたか？」「このサービスは何をするものだと思いますか？」と質問する。初見の印象・視線の優先順位・情報の伝わりやすさを検証するのに特化した手法だ。 5秒という制約が重要だ。ユーザーが詳細を読む前の瞬間的な認知判断を捉えることで、ファーストインプレッションの問題を洗い出せる。ランディングページやアプリのオンボーディング画面のような、「最初の数秒で意思決定が行われる」コンテキストで特に有効だ。 参加者からの声として、「ファシリテーターが設計した意図と、ユーザーが受け取った情報が全く違った」という発見がある。デザイナーが「分かりやすいはず」と思っていた情報が、ユーザーには全く届いていないケースが頻発する。 これがこの手法の本質的な価値だ。 - ゲリラテスト（廊下テスト） 事前の参加者リクルーティングなしに、カフェ・社内廊下・公共スペースで通りかかった人に5〜10分でテストを依頼する手法だ。スピードと低コストが最大の特長で、1日で10〜15人のフィードバックを収集できる。 注意点は、サンプルの偏りだ。カフェでテストすれば「カフェに来る人」に偏り、社内廊下なら「その組織の文化に慣れた人」に偏る。これをゲリラテストの「欠点」と捉えるのではなく、「仮説の初期検証ツール」として位置づけると使いやすい。大規模なモデレーテッドテストの前段階として、プロトタイプの致命的な問題を早期発見する目的で活用するのが合理的だ。 実際にやってみると、「5分だけお時間いただけますか？」と声をかけると、思いのほか多くの人が協力してくれる。「ユーザーに見せるハードル」を下げる最良のトレーニングとしても機能する。 - リモートユーザーテスト Zoom・Microsoft Teams・UserTesting.comなどのオンラインツールを使い、物理的に同じ場所にいない状態でテストを実施する。地理的制約なく多様なユーザー層にアクセスできる点が最大の利点で、パンデミック以降、主要な手法として定着した。 モデレーテッドとアンモデレーテッド（参加者が一人でタスクをこなし、録画で後から分析する）の2形態がある。アンモデレーテッドは量を確保しやすいが、想定外の行動に対してその場でフォローアップできない。 設計の核心は「タスク指示の明確さ」だ。対面テストなら表情や雰囲気で補完できる文脈を、リモートでは言語だけで設計しなければならない。タスクシナリオに曖昧さが残ると、ユーザーによって全く異なる解釈が生まれ、データの比較が困難になる。 --- テスト設計の4ステップ ステップ1: 何を検証するかを決める（テスト目標の設定） テストの前に「このテストで答えを得たい問い」を1〜3個に絞ることが必須だ。「全てを検証しよう」というアプローチは、どれも中途半端になる。 POVステートメント（問題定義文）から逆算して「ユーザーがこのステップで迷わずに操作できるか」「価値提案が5秒以内に伝わるか」のような具体的な検証仮説を設定する。 ステップ2: ユーザーを定義する 誰に見せるかは、手法の選択と同じくらい重要だ。ペルソナの設定段階で特定したターゲットユーザー像に近い人を探すが、完璧なマッチングにこだわりすぎると招集に時間がかかりすぎる。 「ドメイン知識がある人」と「ない人」を混在させることで、専門家バイアスと初見バイアスの両方を収集できる。 ステップ3: タスクシナリオを書く タスクシナリオは3要素で構成する。「状況（あなたは今〇〇という状態にいます）」「動機（あなたは〇〇したいと思っています）」「ゴール（〇〇を達成するために行動してください）」。 ユーザーに正解を示唆するような言葉を使わないことが鉄則だ。「購入ボタンを押してください」ではなく「商品を入手するために必要な操作をしてください」と書く。前者は発見を消し去り、後者は発見を保護する。 ステップ4: 観察・記録・分析の設計 テスト中は「発言」「行動」「感情」の3軸で記録する。特に感情（「ため息」「苦笑い」「前のめりになる」）は言語化されにくいインサイトを運んでくれる。 テスト後はアフィニティダイアグラム的な方法で観察事項をクラスタリングし、「頻度が高い問題」「深刻度が高い問題」のマトリクスで優先順位を付ける。全ての問題を直そうとするのではなく、どの問題が最もユーザー体験を損ねているかに集中する。 --- よくある失敗とその対策 ファシリテーターが答えを教えてしまう問題。 ユーザーが迷っているのを見ていられず、「こうすると思います」とヒントを出してしまうパターンだ。これはテストの価値を根本から破壊する。迷っている様子が「データ」だ。沈黙を観察として記録することを、テスト前にチーム内で共有しておく。 「うちのユーザーとは違う」という合理化問題。 テスト結果が期待と異なると、「このユーザーは典型的ではない」と排除したくなる。しかし1人の「例外ユーザー」の行動が、最重要のインサイトを持っていることがある。 先入観なく記録し、複数のテストで傾向を確認する姿勢が必要だ。 テスト結果の共有が設計チームに届かない問題。 テスト担当者がレポートを書いたが、設計チームには読まれなかった——このサイロは多くの組織で発生する。テスト実施時に設計チームのメンバーがオブザーバーとして同席する「ライブ観察」の文化が、最も効果的な対策だ。 --- デザイン思考のテストフェーズを反復させる テストフェーズは、プロトタイプフェーズと対になった反復サイクルの中で機能する。1回のテストで「完成」させるのではなく、「テスト→学び→プロトタイプ改良→テスト」の小さなサイクルを高速で回すことがデザイン思考の核心だ。 この反復プロセスを組織に定着させるには、「テストは検証するものではなく、学ぶためのものだ」という文化的な再定義が必要になる。失敗を発見したことを成功と捉える評価設計が、テストフェーズの本質的な実装条件だ。 --- やってみよう 手始めに「ゲリラテスト」を今週中に1回実施することを勧める。社内の廊下や休憩スペースで、今開発中のプロトタイプ（紙でも画面でも）を持ち、「5分だけ時間をもらえますか？」と声をかけてみる。 テストを終えたら、以下の3つを書き出す。「ユーザーが迷ったのはどのポイントか」「ユーザーが口にした印象的な言葉は何か」「自分たちの仮説と異なっていたことは何か」。 この3つが書き出せれば、今日のテストは成功だ。 ユーザーテストの「うまさ」はテクニックではなく、習慣化にある。 --- 参考文献 - Nielsen, J. (1993). Usability Engineering. Morgan Kaufmann. — 5人テストで85%の問題が発見できるという知見の原典 - Rubin, J., & Chisnell, D. (2008). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (2nd ed.). Wiley. — モデレーテッドテスト設計の標準的教科書 - Portigal, S. (2013). Interviewing Users: How to Uncover Compelling Insights. Rosenfeld Media. — ユーザーインタビューとテスト観察の技法を体系化 - IDEO.org. (2015). The Field Guide to Human-Centered Design. IDEO.org/Design Kit. — デザイン思考テストフェーズの公式ガイドライン（https://www.designkit.org/） - Goodman, E., Kuniavsky, M., & Moed, A. (2012). Observing the User Experience: A Practitioner's Guide to User Research (2nd ed.). Morgan Kaufmann. — ユーザー観察手法の包括的リファレンス --- ### デザイン思考の限界：なぜシリコンバレー発の手法が日本企業で機能しないのか URL: https://designthinking.studio/articles/design-thinking-limitations/ > Natasha Jenの「Design Thinking is Bullshit」宣言、Lee Vinselらの批判を整理しながら、日本企業特有の障壁と、それでもデザイン思考が有効な条件を論じる。 デザイン思考は「万能の問題解決手法」として紹介されることがあります。しかし現実には、日本の大企業でデザイン思考のワークショップを導入したものの、「楽しかった」で終わり、現場の実務に何も変化が生まれないという結果が繰り返されています。 この失敗を「導入の仕方が悪い」「推進担当者の熱量が足りない」と片付けるのは、問題の本質を見誤ります。デザイン思考には構造的な限界があり、その限界を理解しないままで運用すると、予測可能な形で機能しなくなります。 批判の整理：外部からの声 Natasha Jen「Design Thinking is Bullshit」 2017年、グラフィックデザイナーでPentagramのパートナーであるNatasha Jenが、Adobe Maxのステージで行ったプレゼンテーションは大きな反響を呼びました。タイトルは直接的に「Design Thinking is Bullshit（デザイン思考はたわごとだ）」というものでした。 Jenの批判の核心は三点です。 第一の批判：デザインプロセスの単純化。 デザイン思考の5ステップは、実際のデザイン実務の複雑さを理解していない人々のために作られた簡略版だという主張です。熟練したデザイナーは「共感→定義→発想→プロトタイプ→テスト」という直線的なプロセスを歩まない。問いの再設定が何十回も行われ、観察と作業が並行して走り、直感と論理が混在する。その複雑さを「5ステップ」に圧縮することで、デザインの本質が失われるというのがJenの見立てです。 第二の批判：批判的思考の欠如。 デザイン思考のワークショップでは「量が質を生む（アイデアをたくさん出せ）」という文化が優先され、アイデアへの批判が「創造性を殺す」として抑制されます。しかしJenは「デザインには批判的評価が不可欠であり、批判なきブレインストーミングは質の低いアイデアを温存するだけだ」と指摘しました。 第三の批判：成果の検証不足。 ポストイットが大量に貼られたワークショップの壁は、成果が出た証拠ではありません。「どんな問題がどれだけ解決されたか」というアウトカムが、デザイン思考の評価に欠けているという批判です。 Lee Vinsel「Innovation Fetish」批判 テクノロジー社会学者のLee Vinselは、デザイン思考を「イノベーション崇拝（Innovation Fetish）」の文脈で批判しています。Vinselが問題にするのは、デザイン思考が「革新的なソリューション」を求めることに傾きすぎ、「既存のものを正しく維持する（Maintenance）」という実務を軽視するという点です。 多くの組織の問題は、新しいサービスや製品を作ることではなく、既存のシステムを正確に維持・運営することにあります。病院の患者体験改善において最も重要なのは、斬新なデジタルツールの導入ではなく、予約管理の確実な運用と清潔さの徹底かもしれない。そこにデザイン思考を持ち込み「革新的ソリューション」を探求することは、本質的な問題から目をそらすことになる場合があります。 --- 日本企業特有の障壁 外部からの批判を踏まえつつ、なぜ日本企業でデザイン思考が機能しにくいかを、構造的な要因として整理します。 障壁1：合意形成文化と「実験の失敗」の非許容 デザイン思考は「失敗から学ぶ」を前提としたプロセスです。プロトタイプを素早く作り、テストし、失敗して、改善する。この循環が機能するためには、「試して失敗すること」が組織内で許容されている必要があります。 日本企業の多くは「稟議文化」を持っています。何かを試みる前に、上位者の承認を取ることが求められます。この承認プロセスには「失敗する可能性がある試みへの抵抗」が内包されており、プロトタイプを作る前に完璧な計画を求める圧力が生まれます。 結果として起きるのは「完璧に設計したプロトタイプをテストする」という、デザイン思考の本来の意図と逆行した実践です。完璧に仕上げたプロトタイプを「失敗だった」と判断するコストが高くなり、フィードバックを無視して既存の計画を推進する動機が強化されます。 障壁2：失敗への不寛容と職責の構造 シリコンバレーの起業文化では「Fail Fast（速く失敗せよ）」がスローガンとして機能します。失敗は学習の証拠として評価される文化的背景があります。 日本企業の組織では、失敗は個人または部署の「責任」として記録される傾向があります。年次評価にマイナスのシグナルとして残り、昇進・昇格に影響する場合もあります。この構造下では、「失敗するかもしれない実験を推進する」行動は合理的ではなく、担当者が個人的なリスクを取らなければならない行為です。 デザイン思考は個人が「エラーを犯す権限」を持つことを前提としていますが、日本企業の多くでは、エラーは「犯してはならないもの」として管理されています。 障壁3：プロトタイプ文化の欠如 「プロトタイプとは荒削りで良い」というデザイン思考の原則は、完成度の低い成果物をステークホルダーに提示することへの抵抗感と衝突します。「作ることで考える」というプロトタイプ思考の文化的定着が、この障壁を突破する根本的なアプローチです。 日本企業の対外（および社内への）コミュニケーション文化では、提示物の「完成度」が信頼性の指標として機能する場合があります。未完成のプロトタイプを役員に見せること、または顧客の前で「テスト版」として提示することへの心理的ハードルが高い。 これは単なる「心理的なもの」ではなく、品質基準の高さを競争優位とする製造業文化の延長として理解できます。「完成度の高いものを提供する」という誇りがある企業では、ラフなプロトタイプは「手抜き」として解釈されるリスクがあります。 障壁4：「ユーザーに聞く」インフラの未整備 共感フェーズの実践には、エンドユーザーに繰り返しアクセスできる仕組みが必要です。ユーザーインタビュー、観察調査、ユーザーテスト——これらは「やろうと思えばできる」ものですが、組織としての習慣として定着していないと、デザイン思考の各サイクルのたびにゼロから調整が必要になります。 シリコンバレーのスタートアップでは、ユーザーテストは週次で行われるルーティンです。担当デザイナーが対象ユーザーをリクルートし、録画設備を使ってテストを行い、その日のうちに知見をチームで共有する——というプロセスが「当たり前のこと」として機能しています。このインフラがない環境では、「ユーザーに聞く」ことのコストと調整負担が大きくなります。 --- それでもデザイン思考が有効な条件 批判と構造的障壁を整理したうえで、デザイン思考が最も有効に機能する条件を明示します。 条件1：問題の性質が「人間の行動・体験」に関わる デザイン思考は「人間の行動、動機、体験に起因する問題」の解決に最も威力を発揮します。逆に、技術的な最適化問題（アルゴリズムの改善、製造プロセスの効率化）にはデザイン思考は不向きです。 条件2：解が「既知でない」こと 問題とその解決策が既に明確であれば、プロセスとしての効率はプロジェクト管理やリーン手法のほうが高い。デザイン思考が価値を持つのは、「何が問題かも分からない」「どんな解決策があり得るか見えていない」という不確実性の高い状況です。 条件3：小さく始められる組織単位 デザイン思考を全社的に「導入する」のではなく、一つのプロジェクトチームで「試す」という形から始めることが有効です。合意形成文化や失敗への不寛容は、組織全体の空気として存在しますが、小さなチームの中では意図的に変えることができます。 条件4：評価基準を「アウトカム」に置く Natasha Jenの批判に応えるためには、「ワークショップを実施した」という活動記録ではなく、「この問題がどれだけ解決されたか」というアウトカム指標でデザイン思考の成果を評価する必要があります。 --- まとめ：批判を織り込んで使う デザイン思考への批判は、手法を捨てる理由ではなく、より精度高く使うための情報です。 批判が示しているのは「デザイン思考を、組織変革の万能薬として使ってはならない」というシンプルなメッセージです。特定の問題の性質に合致し、実験を許容する文化的基盤があり、アウトカムで評価される枠組みがある——その条件が揃ったとき、デザイン思考は依然として最も強力な問題解決のフレームワークのひとつです。 条件の揃っていない場所でそれを無理に使おうとすることの失敗を、「デザイン思考が使えない証拠」と解釈するのは正しくありません。それは「ハンマーでネジを締めようとして失敗した」ことを「ハンマーは使えない」と結論づけるようなものです。 --- 参考文献 - Natasha Jen, "Design Thinking is Bullshit", Adobe MAX 2017講演, creativebloq.com - Lee Vinsel & Andrew Russell, The Innovation Delusion: How Our Obsession with the New Has Disrupted the Work That Matters Most, Crown Currency, 2020 - Don Norman, "Design Thinking: A Useful Myth", Core77, 2010 - Liedtka, Jeanne, "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction", Journal of Product Innovation Management, Vol. 32, 2015 - 佐宗邦威、『21世紀のビジネスにデザイン思考が必要な理由』、クロスメディア・パブリッシング、2015年 --- ### デザイン思考の効果測定とKPI設計｜組織導入を定着させる指標の作り方 URL: https://designthinking.studio/articles/design-thinking-measurement-kpi/ > デザイン思考の導入効果をどう測定するか。定性・定量の両面から効果を可視化し、経営層に説明できるKPI設計の手順を解説。200回以上のワークショップ経験から導いた実践的な指標体系を紹介する。 「デザイン思考の研修を実施しました。次のステップをどうすればいいか分かりません」——この状況に陥る組織には共通のパターンがある。効果測定の設計が欠けている。 デザイン思考の実践者が経営層に最も問われる質問がある。「それで、何が変わったのか」だ。この問いに答えられない実践者は、予算を継続して獲得できない。組織の中でデザイン思考を育てるためには、変化を可視化する指標設計が必要だ。 なぜデザイン思考の効果測定は難しいのか 測定の難しさには構造的な理由がある。 デザイン思考がもたらす変化の多くは遅延して現れる。ワークショップ直後は参加者の熱量が高い。しかし本当の変化——問題への向き合い方が変わる、ユーザーを観察する習慣がつく、仮説検証を反射的に行う——は数ヶ月から1年単位で現れる。短期的な数値で評価しようとすると、本質的な変化を見逃す。 また、デザイン思考の効果は他の要因と複合する。新製品の売上が上がったとき、それはデザイン思考の成果か、市場環境の変化か、営業力の向上か——切り離すことは困難だ。 さらに、デザイン思考の価値の多くは「失敗しなかったこと」に現れる。早期にプロトタイプで仮説を棄却することで、数億円規模のプロジェクトが中止された——この「防いだコスト」は財務諸表に現れない。 効果測定の3層構造 測定を設計する際、3つの層を分けて考えることが有効だ。 第1層: プロセス指標（活動の量と質） 組織がデザイン思考のプロセスを実際に実践しているかを測る。最も測定しやすい層だ。 - ユーザーインタビュー実施件数（月/四半期） - プロトタイプ制作件数 - ワークショップ実施回数と参加者数 - How Might We（HMW）設定件数 注意点: プロセス指標はアウトカムの先行指標にすぎない。プロセス指標だけで効果を判断すると、「形式だけこなす」状態を生む。200回以上のワークショップで繰り返し観察されるのは、「インタビューは実施したが、その洞察が設計に反映されていない」という状況だ。 第2層: アウトカム指標（チームと組織の変化） デザイン思考の実践がチームや組織の行動様式に与える変化を測る。定量化が難しい指標だが、最も本質的な変化を捉える。 スピード指標 - アイデアから最初のプロトタイプ制作までのリードタイム - ユーザーフィードバック取得までのサイクルタイム - 意思決定にかかる時間（特に「進む/止まる」の判断） 質的変化の定点観測 - 四半期ごとの360度フィードバック（「問題定義の質」「ユーザー視点の有無」を項目に含める） - チームの心理的安全性スコア（新しい提案を試みやすい環境か） - 「失敗から学んだ事例」の共有頻度 ワークショップ現場でよく聞くのは「うちのチームは変わった感じがするが、何が変わったか言語化できない」という声だ。この「感じ」を定点観測で捉えるのが、アウトカム指標の役割だ。 第3層: ビジネスインパクト指標（経営への貢献） 経営層が関心を持つ、事業成果への貢献を測る。最も測定が難しいが、予算を確保し続けるために不可欠な層だ。 新規事業・製品開発領域 - 早期段階での仮説棄却率（投資前に止められた失敗コスト） - 顧客インサイトを起点とした新機能採用率 - プロダクト発売後の初期ユーザー満足度 既存事業改善領域 - 顧客体験改善前後のNPS（Net Promoter Score）比較 - カスタマーサポートへの問い合わせ件数減少率（UX改善の結果） - 従業員エンゲージメントスコア（内部プロセス改善の効果） 測定設計の実践手順 ステップ1: 「なぜデザイン思考を導入するか」を経営課題に接続する KPI設計の前に、経営課題との対応関係を明確にする必要がある。 「新製品開発のスピードが遅い」という課題があれば、プロセス指標として「プロトタイプ制作リードタイム」、アウトカム指標として「意思決定速度」、ビジネスインパクト指標として「製品発売から初回売上までの期間」という指標体系が対応する。 目的と指標の対応が曖昧なまま測定を開始すると、「数字はあるが何を意味するか分からない」状態になる。 ステップ2: ベースライン（基準値）を先に測定する デザイン思考の導入前に基準値を測っておくことが、変化の可視化に必要だ。導入後から測定を始めると比較基準がなくなる。 最低限、以下を記録しておく。 - 現在のプロダクト/サービス改善サイクル（どのくらいの頻度でユーザーフィードバックを得ているか） - 現在の意思決定プロセス（アイデア提案から採否決定まで何週間かかるか） - 現在のNPS・顧客満足度 ステップ3: 四半期単位のレビューサイクルを設計する 効果測定は「一度やって終わり」ではなく、反復的なプロセスだ。四半期ごとに指標を確認し、「指標そのものが適切か」を見直す。 デザイン思考の組織変革において、最もよく起こる失敗は「最初に設定した指標を疑わないこと」だ。組織の状況が変化するにつれて、重要な指標も変化する。プロセス指標が充実してきたら、アウトカム指標に軸足を移す、という段階的な移行が必要だ。 「デザインROI」の考え方 マッキンゼーが2018年に発表したレポート The Business Value of Design は、デザインへの投資とビジネス成果の相関を定量的に分析した。上位25%のデザイン力を持つ企業は、同業比較で32%高い売上成長を記録したという調査結果は、デザイン投資の正当化に広く使われる。 ただし、この数値を自社のROI計算に直接用いることには注意が必要だ。相関は因果を意味しない。「デザインへの投資がビジネス成果を生んだ」のか「ビジネスが成功している企業がデザインに投資できる」のかは、この調査では判別できない。 より実務的なROI計算は、具体的な事業課題と紐付けた形で行う。 例: カスタマーサポートコスト削減の場合 - 改善前: 月間問い合わせ件数5,000件 × 1件あたり対応コスト2,000円 = 月1,000万円 - UXリデザイン後: 問い合わせ件数30%減少 → 月700万円 - 月次削減効果: 300万円 - リデザイン投資額: 1,200万円 - 回収期間: 4ヶ月 この計算式の変数（どの接触点を改善したか、改善にどの手法を用いたか）を記録することが、次の投資判断の根拠になる。 経営層への説明で有効なフレーム 「デザイン思考の効果を測定した数値」を持っていても、経営層に伝わらないケースがある。指標の選び方と説明の順序に問題がある場合が多い。 有効なフレームは「リスク回避コスト」から始めることだ。 「このプロトタイプ検証に50万円を使ったことで、本開発前に仮説の誤りを発見できました。本開発に着手していた場合の推定コストは3,000万円です。この50万円の投資が2,950万円のリスク回避をもたらしました」——この説明は、経営層の言語（コストとリスク）で語られている。 デザイン思考の効果を「体験の質が上がった」「チームの雰囲気が良くなった」という言語で説明するのは、実践者の間では通じても、経営層への説明としては力が弱い。事業課題への貢献を財務言語に翻訳する能力が、デザイン思考推進者に求められる。 --- まとめ デザイン思考の効果測定は、組織への定着を決定する要素のひとつだ。測定できないものは管理できない——これはデザイン思考の文脈でも成立する。 プロセス指標・アウトカム指標・ビジネスインパクト指標の3層を意識し、導入前にベースラインを測定し、四半期単位で指標を見直す。この反復的なプロセス自体が、デザイン思考の「プロトタイプとテスト」という考え方と一致している。 効果測定の設計は、ワークショップの設計と同じく「手を動かして作り、試して修正する」プロセスだ。完璧な指標体系を最初から作ろうとせず、動かしながら精緻化することが、実践的なアプローチだ。 参考文献 - McKinsey & Company, "The Business Value of Design," McKinsey Quarterly, October 2018 - Marc Stickdorn, Adam Lawrence, Markus Edgar Hormess, Jakob Schneider, This Is Service Design Doing, O'Reilly Media, 2018（邦訳: BNN新社, 2020） - Tim Brown, Change by Design, HarperBusiness, 2009（邦訳: 『デザイン思考が世界を変える』早川書房） 関連記事 - デザイン思考の組織変革×チェンジマネジメント - デザイン思考の組織導入ガイド - デザイン思考の失敗事例5選 - プロトタイプフェーズの進め方 --- ### デザイン思考の組織導入が折れた5つの現場——何が起きて、どう立て直したか URL: https://designthinking.studio/articles/design-thinking-org-failure-cases-5/ > デザイン思考の組織導入が実際に折れた5つの現場を、何が起きたかの順に追う。盛り上がったワークショップが3ヶ月で元に戻る過程と、そこから立て直した打ち手を事例に絞って解説します。全体設計は組織変革の完全ガイドへ。 デザイン思考の組織導入に取り組んだ担当者の多くが、半年後に同じ言葉を口にする。「思ったようには定着しなかった」。 ワークショップは盛り上がった。参加者の満足度も高かった。しかし3ヶ月後、現場は元通りの業務フローに戻っていた。デザイン思考の組織導入における失敗は、偶然の不運ではなく、再現性のあるパターンから生まれる。 200回以上のワークショップ支援と組織変革のフィールドワークを通じて、失敗事例には明確な共通構造があることが分かってきた。本記事では、その5つのパターンを具体的に解剖し、それぞれの克服策を提示する。 この記事は実際に起きた事例に絞っている。組織変革の全体設計はデザイン思考 組織変革の完全ガイド（3年ロードマップ）、着手の手順は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ステップ実践ガイド — 成功パターンとの対比 - デザイン思考ファシリテーター育成：組織内ケイパビリティ構築ガイド — 社内ファシリテーター不在が失敗を招く問題への直接的な解決策 - デザイン思考 行政サービス改革｜市民中心の公共設計7つの実践 — 組織変革を乗り越えた行政事例の詳細 --- ### デザイン思考の創造性技法—Crazy Eights とボディストーミングが機能する本当の理由 URL: https://designthinking.studio/articles/creative-methods-engagement-boost/ > Crazy Eights やボディストーミングなど創造性技法の「なぜ機能するのか」を実践知から解説。参加者が突っ立ってしまう瞬間と、エンゲージメントを取り戻すファシリテーション技術を網羅する。 デザイン思考のワークショップで、参加者が突っ立ったまま「何を書けばいいのか」と固まってしまう瞬間がある。ファシリテーターが「自由に発想してください」と言えば言うほど、部屋の空気が重くなる——。この現象は、創造性技法の選択ミスではなく、設計ミスから起きています。 どこで参加者は固まるのか 問題（Problem） 「アイデアを出してください」という問いかけは、参加者にとって難題です。「良いアイデアを出さなければならない」というプレッシャーが、発想を止めます。 特に初めてデザイン思考ワークショップに参加する方、または「専門家が揃っているのに自分が発言していいのか」と感じている参加者は、この状況に陥りやすい。 結果として「誰かが先に話すのを待つ」という場が生まれ、声の大きいメンバーか役職上位者の発言がワークショップを支配します。これはブレインストーミングの教科書的失敗パターンですが、現場で何度見ても起きます。 親近感（Affinity） 参加者からの声として最も多いのが「何を書いていいかわからなかった」です。これは参加者の問題ではありません。「何を書いていいかわからない状態」を作ったファシリテーションの問題です。どんな熟練者でも、制約なしの自由発想は困難です。創造性技法は「制約による解放」という逆説で動いています。 解決策（Solution） 創造性技法が本当に機能するとき、そこには必ず「適切な制約」があります。時間制限、アウトプット形式の指定、身体の使い方の誘導——これらの制約が「自由に考えよ」という指示よりも圧倒的に多くのアイデアを引き出します。このガイドでは、現場で機能する3つの技法の「なぜ機能するのか」を解剖します。 --- Crazy Eights はなぜ機能するのか Crazy Eightsは「8分間で8つのアイデアをスケッチする」という制約が中核にあります。この設計には意図があります。 完璧主義を制約が上書きする 1分という時間制限は、「良いアイデア」を考える余裕を物理的に奪います。 「これは陳腐かも」「あの人に笑われないか」という検閲の思考が動く前に、次の1分のアラームが鳴ります。 ワークショップでよく起こるのは、最初の2〜3マスが非常に似通ったアイデアになることです。これはチームに共通する「当たり前の解」が最初に出てくる現象で、正常なプロセスです。4マス目以降に「仕方なく変なことを描く」状態が訪れた時、そこから本当に面白いアイデアが出始めます。 実際にやってみると、タイマーを厳守した回と「少しだけ待ってあげた」回では、アウトプットの多様性が大きく違います。「もう少し待って」を3回繰り返すと、8マス埋まるはずが5〜6マスで終わることが多い。制約の厳守が、創造性の閾値を越えさせます。 全員同時スタートが発言格差を消す Crazy Eights のもう一つの重要な設計は、全員が同じタイミングで同じ課題に取り組むことです。「話を聞いてからアイデアを出す」という順次設計では、先に発言した人の案が後続者の思考を誘導します。同時スタートはこのバイアスを構造的に消します。 貼り出してみると、同じチームが同じ問いに対して8種類以上の全く異なるアプローチを出していることに参加者が驚きます。「こんなに違うんだ」という驚きがチームの対話を深めます。 Crazy Eights 後のドット投票で収束を確実にする 発散だけで終わるとワークショップは「それで？」で終わります。Crazy Eightsの後は必ず収束のセッションを設計します。全員のスケッチを壁に並べ、ドット投票で「気になるアイデア」を選びます。 投票後の短い議論で「なぜこれを選んだか」を話すと、チームの優先価値観が言語化されます。 --- ボディストーミングが突破する壁 ボディストーミングは、言葉とポストイットだけでは見えない問題を、身体を使って発見する技法です。なぜ身体が必要なのか。 言語化できない体験の問題 設計書上では「わかりやすい」フローが、実際に身体を使うと機能しないことがあります。「車椅子を使って実際に動く」「荷物を両手に持ちながらドアを開ける」という身体的体験は、デスク上のデザインでは想定できない制約を明らかにします。 あるサービスデザインプロジェクトでは、病院の待合から診察室への動線を会議室の椅子で再現しただけで「ここで毎回詰まる理由がわかった」という発見が3件出ました。設計図の上では問題なかった動線が、身体で試した瞬間に問題として現れた事例です。 参加者が固まらない設計 ボディストーミングで参加者が固まりやすい瞬間は「演技してください」という瞬間です。この固まりを防ぐために、ファシリテーターは「演技の上手さは不要。体が自然に動こうとする方向を見てほしい」という声かけを必ずします。 「下手でいい」の宣言は、参加者への許可です。これがないと「間違った動きをしたら恥ずかしい」という心理が身体を固めます。実際にやってみると、「下手でいい」と言われた後で参加者の動きが格段に自然になることが観察されます。 詰まった瞬間を見逃さない ボディストーミングの最重要ポイントは、参加者が「詰まった瞬間」です。ここがサービスデザイン上の問題のシグナルだからです。ファシリテーターは流れを止める権限を持ち、詰まりが発生したら即座に「今、何を探していましたか？」と問いかけます。 この問いを怠ると「詰まったけど何とかした」という演技で進んでしまい、問題が記録されません。詰まりの記録こそが、次のプロトタイプで解決すべき設計課題の原材料です。 --- 創造フェーズのエンゲージメントを維持する3つの原則 原則1：アイデアの量を最初に祝う 「量が質を生む」は創造性研究の基本原則です。Crazy Eights の後、投票前に「全員で何個のアイデアが出たか数える」セレモニーをします。「10人で84個出ました」と宣言するだけで、参加者のテンションが変わります。数の多さを称賛することが、「少数の良いアイデアを出さなければ」というプレッシャーを解除します。 原則2：ワイルドカードを明示的に招待する 「最もバカげたアイデアをあえて出す」セクションを設けることで、参加者の心理的安全性が広がります。「このアイデアは現実的でなくていい」というルールを事前に宣言すると、それまで出なかった視点が溢れ出します。 IDEO のワークショップでは "Worst Possible Idea" という手法が使われます。最悪のアイデアを出し切ることで、逆に最善のアイデアが見えてくるというアプローチです。「絶対に実現してはいけないサービス」を30秒で3つ出す、という課題が創造の閾値を下げます。IDEOのブレインストーミング文化の背景については書評『発想する会社！』で詳しく論じています。詳細な実装方法については、創造性技法による水平思考プロセスで具体的な事例とファシリテーション技術を解説しています。 原則3：収束の基準を事前に設計する 発散が終わった後、「どれが良いアイデアか」の収束基準が曖昧だとエネルギーが霧散します。ファシリテーターは収束の投票基準を発散セッションの前に決めます。 「もし明日1,000円あればどれに投資するか」「ユーザーが最も喜ぶと思うのはどれか」など、基準を具体化することで投票が議論の道具になります。 --- やってみよう：60分の創造セッション設計 準備物 - A4用紙（8つ折りの Crazy Eights 用） - 太マーカー（サインペン） - タイマー（スマートフォン可） - 大判付箋またはポストイット - ドット投票用シール（各自5枚程度） セッション構成 前段（10分）：HMW の確認 今日解く「How Might We（HMW）」の問いを全員で確認します。例：「社内申請フローで、担当者が迷わず次のステップに進めるにはどうすれば良いか？」HMWが曖昧なままCrazy Eights を始めると、参加者が別々の問いに答えることになります。 発散（15分）：Crazy Eights 1分タイマーで8マス。ファシリテーターは途中で進捗確認しない。タイマーのアラームだけが「次へ」の合図。 共有（10分）：スケッチを壁に貼り出す 全員のスケッチを並べて貼り出します。発言なし、コメントなし。ただし「眺める時間」を2分取ります。 投票（5分）：ドット投票 各自5枚のドットシールで、「気になるアイデア」に投票します。自分のアイデアにも投票可。 深化（15分）：上位アイデアをボディストーミングで検証 票が集まった上位2〜3案を選び、実際に身体で試します。会議室の椅子や手近な小道具で環境を再現し、3〜4分で演じます。ファシリテーターは詰まった瞬間を止めて記録します。 振り返り（5分）：次のプロトタイプへ 「今日のセッションで最も可能性を感じたアイデアは？」「次にプロトタイプで試すなら何を検証したいか？」の2問で締めます。これがプロトタイプフェーズへの橋渡しになります。 --- こんな人に特に有効 - ワークショップで「いつも同じ人だけが発言する」と感じているファシリテーター - 「ブレインストーミングをやったが、使えるアイデアが出なかった」という経験がある - デザイン思考ワークショップを初めて設計するプロジェクトリーダー - 参加者の心理的安全性が低い組織でワークショップを設計している --- ポイント - 制約が創造性を解放する — 「自由に発想して」より「1分で1個描いて」の方が多くのアイデアが出る - 全員同時スタートで格差を消す — 順次発言型では声の大きい人の案が支配する - 詰まりを見逃さない — 参加者が固まった瞬間こそ設計課題のシグナル - 量を先に称賛する — 発散の成功を「何個出たか」で祝うことがプレッシャーを解除する - 収束基準は事前に設計する — 発散前に投票の基準を決めておくことで収束の質が上がる --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint, Simon & Schuster, 2016 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperCollins, 2009 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018年改訂版 --- ### デザイン思考パイロット失敗からの組織復帰ガイド｜3つの再起動パターン URL: https://designthinking.studio/articles/design-thinking-pilot-failure-recovery/ > デザイン思考のパイロット導入が失敗した組織が、どう立て直すか。縮小実行・別部署リセット・外部パートナー併走という3つの再起動パターンを、現場の実態に基づいて解説する。 デザイン思考のパイロットプログラムを走らせたが、うまくいかなかった——そういう組織の担当者から相談を受ける時、最初に聞くことがある。「失敗の後、組織の中で何が起きましたか？」 答えのパターンは大きく3つに分かれる。「やった人たちが諦めて黙った」「別のフレームワークの話が出始めた」「そもそも失敗として認識されていない」。どのケースも、パイロットの失敗そのものより、失敗の後に組織が取る行動が、デザイン思考の命運を決めていた。 --- なぜパイロットは失敗するのか：3つの構造的要因 再起動を考える前に、なぜ失敗したかを正確に診断する必要がある。原因を誤解したまま再起動すると、同じ失敗を繰り返す。 要因1：「ワークショップを実施した」と「組織に変化が起きた」を混同した 最も多い失敗の構造だ。参加者が熱心に取り組み、付箋も大量に貼られ、成果発表会も盛況だった。しかし3ヶ月後、誰もその成果を引き継いでいない。ワークショップの成功と、業務プロセスの変容は、まったく別の指標だった。 ワークショップは「体験の場」であり、それ自体が目的になった時点で、組織変革の手段としての機能を失う。 要因2：経営層との約束が「理解の共有」で止まった パイロットの前段階で、経営層から「デザイン思考を試してみましょう」という承認を得た。しかし「試す」の定義が双方で異なっていた。現場担当者は「3ヶ月のプロセス変革実験」と理解し、経営層は「ワークショップ研修1回」として認識していた。 期待のギャップが埋まらないまま走ったパイロットは、評価基準の不一致によって失敗する。 現場は「手応えがあった」と感じ、経営層は「コストに見合うROIが見えない」と判断する。 要因3：推進担当者が孤立した パイロットの推進を「熱意ある一人の担当者」に集中させた組織では、その担当者が異動・退職した時点でパイロットが終わる。あるいは、担当者が孤軍奮闘している間に組織の空気が変わり、「あの人の趣味プロジェクト」として距離を置かれ始める。 デザイン思考の導入は、組織の変革プロジェクトだ。一人の熱量で動かせる規模には、構造的な限界がある。 --- 失敗後の診断：再起動の前に必ずやること 再起動パターンを選ぶ前に、組織の現状を診断する。以下の4点を確認する。 - 失敗の記憶は誰の中に残っているか。 経営層か、現場担当者か、あるいは参加者全員か。記憶の所在によって、説得が必要な相手と内容が変わる。 - 失敗の原因はどう語られているか。 「デザイン思考が合わない」という総括になっているか、「あの進め方が悪かった」という局所的な評価になっているか。前者は再起動のハードルが高く、後者は比較的動きやすい。 - 今も動ける協力者はいるか。 失敗の後でも「もう一度試したい」と考えているメンバーが、組織内の誰かにいるか。この「残り火」の存在が、再起動の最重要リソースになる。 - 失敗から何が学べたか、言語化できているか。 失敗を「なかったこと」にしている組織では、再起動も同じ失敗を繰り返しやすい。 --- 3つの再起動パターン 診断の結果に応じて、以下3つのパターンを選択する。 パターン1：縮小実行（Small Wins First） 適した状況： 組織全体への信頼回復が必要だが、完全撤退はしたくない場合。失敗の原因が「範囲を広げすぎた」「期待値が高すぎた」にある場合。 縮小実行とは、次の試みを意図的に小さくデザインすることだ。対象チームを5〜10人以内に絞り、期間を4〜6週間と短く設定し、「成功の定義」を具体的かつ検証可能な形で先に決める。 実際にやってみると、縮小実行の最大の効果は「小さな成功体験の写真撮影」にある。 ユーザーインタビューを実施してインサイトが出た、プロトタイプを作ってユーザーテストを通過した、という具体的な成果物が生まれると、それが組織内の「証拠」として機能し始める。 ファシリテーターへの実務的な注意として、この段階では「派手な成果」より「再現可能な手順の確立」を優先すること。次に同じことを誰かが真似できる状態を作ることが、縮小実行の真の目的だ。 パターン2：別部署リセット（Fresh Start in New Ground） 適した状況： 最初のパイロットで「デザイン思考は○○部門には合わない」という評判が固定化した場合。推進担当者が燃え尽きており、同じチームでの継続が困難な場合。 別部署リセットは、文字通り「別の場所で始め直す」戦略だ。ただし、最初のパイロットの経験を完全に無駄にしないための設計が重要になる。 引き継ぐべきもの： 失敗の原因分析、「やってはいけないこと」の知見、実務プロセスのひな形。 リセットすべきもの： 担当者・対象チーム・スコープ・成功の定義。 参加者からの声として多いのが、「別部署でやることで、前回の失敗の重荷がなくなり、純粋にやってみる気持ちで入れた」というものだ。失敗の記憶が薄い環境では、チームが「実験として割り切る」姿勢を持ちやすく、初期の心理的安全性が確保しやすい。 別部署リセットの落とし穴は、「成功した場合の展開設計」を後回しにすることだ。新しい部署での成功が「孤島の成功」にならないよう、最初から他部署への横展開ルートを設計しておく。 パターン3：外部パートナー併走（External Catalyst） 適した状況： 組織内部に「デザイン思考を推進できる人材」が育っていない場合。経営層の信頼を回復するために、外部の権威が必要な場合。社内だけでは突破できない組織の慣性がある場合。 外部パートナー（コンサルティングファーム・デザインファーム・専門コーチ）を招くことで、いくつかの変化が起きる。まず、「同じ話でも外部が言うと通る」という組織の現実を活用できる。次に、内部担当者が「黒子」として機能し、外部の権威を借りながら組織内での関係性を守れる。 ただし、外部パートナーへの依存が長引くと、社内に能力が育たないという本末転倒が起きる。 外部パートナーとの契約には、「6〜12ヶ月で内部化」のマイルストーンを明示的に入れておく。 外部パートナー選びの実務的な視点として、「ワークショップ実施」が主サービスになっているパートナーは避けること。再起動が必要な組織に必要なのは、ワークショップの設計ではなく、「ワークショップの後の業務プロセス変革」の支援能力だ。 --- 再起動を成功させる4つの共通条件 3つのパターンに共通して、再起動が成功する組織には4つの条件が揃っている。 条件1：失敗の原因を公開できているか。 失敗を隠して「リニューアル」として再起動しても、組織の不信感は消えない。「前回はこれが問題だった。今回はこう変える」という説明が、参加者の信頼を取り戻す。 条件2：経営層が「判断の土台」を持っているか。 「なんとなく応援している」ではなく、「何をもって成功と判断するか」の基準を経営層が持っているかどうかが、再起動の継続性を左右する。 条件3：小さく始めて、記録を残す習慣があるか。 再起動のどのパターンでも、「実施記録・インサイト・プロトタイプの写真・ユーザーテストの動画」を丁寧に残す組織は、次のステップへの説明材料が増える。 条件4：「失敗してもいい」文化が少なくともパイロット空間に存在するか。 デザイン思考は「早く失敗して、学ぶ」プロセスだ。パイロット空間だけでも心理的安全性が確保されていなければ、参加者は本音のフィードバックを出さない。 表面的な「盛り上がり」と実質的な「学習」は、この安全性の有無で分岐する。 --- 「再失敗」の最大リスク 再起動を試みる組織に、繰り返し見られるパターンがある。「今度はちゃんとやる」という決意のもと、以前より大規模に設計してしまうことだ。 失敗の後は、組織の期待値管理が難しくなる。「今度こそ」というプレッシャーが規模を膨らませ、再び期待値と実態のギャップが生まれる。再起動のスコープは、前回より小さくすることを鉄則にする。 小さく成功することが、組織の信頼を再建する唯一の現実的な道だ。 --- やってみよう まず、パイロット失敗の「診断」から始める。チームで30分のふりかえりセッションを設け、「失敗の原因」を3つ書き出す。次に、その3つが「手法の問題」か「プロセス設計の問題」か「組織の問題」かに分類する。 分類の結果が出たら、上記の3パターンのどれが自組織に合うかを検討する。「誰に相談するか」「何週間で最初の成果物を出すか」という具体的な問いに答えられた時点で、再起動の設計が始まっている。 特にパイロット担当者が孤立していると感じている状況であれば、パターン3（外部パートナー併走）から入ることが多くの組織で有効だ。 --- 内部リンク - デザイン思考の組織導入完全ガイド - デザイン思考 組織導入 失敗事例5選 - 組織変革とデザイン思考の実践的統合 - ワークショップ・ファシリテーション術 - 心理的安全性とデザイン思考 --- 参考文献 - Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins, 2009. （邦訳：『デザイン思考が世界を変える』早川書房） - Liedtka, Jeanne, and Tim Ogilvie. Designing for Growth: A Design Thinking Tool Kit for Managers. Columbia University Press, 2011. - Harvard Business Review. "Why Design Thinking Works." HBR, September–October 2018. https://hbr.org/2018/09/why-design-thinking-works - IDEO. "The Field Guide to Human-Centered Design." IDEO.org, 2015. https://www.designkit.org/ - Stanford d.school. "Design Thinking Bootleg." Stanford d.school, 2023. https://dschool.stanford.edu/resources/design-thinking-bootleg - Nielsen Norman Group. "Design Thinking 101." NN/g Articles, 2016. https://www.nngroup.com/articles/design-thinking/ - Kotter, John P. Leading Change. Harvard Business Review Press, 2012. （邦訳：『企業変革力』日経BP） --- ### デザイン思考ファシリテーター育成：組織内ケイパビリティ構築ガイド URL: https://designthinking.studio/articles/design-thinking-facilitator-training/ > 外部ファシリテーター依存からの脱却を目指す組織へ。社内ファシリテーター育成の段階的アプローチ（観察→補助→担当→指導）と、よくある失敗パターン、文化定着のメカニズムを実践的な視点から解説する。 「ファシリテーターは外から呼ぶもの」——この前提が、組織のデザイン思考定着を阻んでいることが多い。 外部ファシリテーターによるワークショップを繰り返しても、組織内には何も蓄積されない。進行の技術も、場の設計の経験も、「この組織にとっての問いの立て方」も、毎回外部に持ち出されて終わる。良いワークショップができても、その知恵は組織に残らない。 ファシリテーションを組織内で内製化することは、単なるコスト削減の話ではない。組織が自分たちの問いを自分たちで立て、自分たちで探索できるようになる、ケイパビリティの問題だ。 --- 外部依存が生む4つの限界 外部ファシリテーターへの依存には、構造的な限界がある。 文脈の断絶。 外部ファシリテーターは、組織固有の文脈——部門間の力学、過去のプロジェクトの失敗、特定の言葉が持つ意味——を持ち込めない。優秀なファシリテーターでも、初日に組織の文脈を完全に理解することはできない。ワークショップが「ちょっとズレた議論」になる要因の多くがここにある。 タイミングの硬直性。 外部ファシリテーターのスケジュールに合わせなければならない。問題が顕在化した時、アイデアが熟した瞬間に、すぐに場を設けられない。「来月のワークショップで扱いましょう」という先送りが、問題解決の速度を落とす。 価格障壁による頻度制限。 外部ファシリテーターへの依存は、ワークショップを「特別なイベント」にする。費用対効果を求めるため、大きなテーマでしか開催されなくなる。しかし実際の問題解決は、小さな問いの探索の積み重ねで進む。組織へのデザイン思考定着で繰り返し強調されるのも、この「日常業務への統合」の重要性だ。 学習の非蓄積。 外部ファシリテーターが場で得た学び——「この組織では何が機能するか」「どんな問いが参加者を動かすか」——は、組織に残らない。毎回ゼロからスタートする消耗を繰り返すことになる。 --- ファシリテーターに必要なスキルセット 社内ファシリテーターを育成する前に、「何を育成するか」を明確にする必要がある。 傾聴と観察 ファシリテーターの中心的なスキルは、話すことより聞くことにある。参加者が発言している時、ファシリテーターは3つのレベルで同時に聞いている。 内容のレベル：何を言っているか。感情のレベル：どんな気持ちで言っているか（興奮・不安・諦め）。構造のレベル：他の発言とどう関係しているか、場全体のどこに位置するか。 実際にやってみると、多くの初心者ファシリテーターが「内容」しか聞いていないことに気づく。感情と構造の読み取りは、訓練によってはじめて身につくスキルだ。 ワークショップ対立マネジメントで整理されている「対立の3タイプ」の識別能力も、この深い傾聴の上に成立している。 場の読み方 「今、この場で何が起きているか」を解像度高く読み取る能力だ。 発言の量だけでなく、沈黙の種類を区別できるか。「考えているから沈黙している」のか「言いたいことがあるが言えないから沈黙している」のか。後者は放置すると場の停滞や対立の種になる。 グループ内のエネルギーの変化にも敏感であることが求められる。議論が「収束の圧力」に向かっているのを察知し、まだ発散が必要な段階であれば意図的に拡張する介入ができるかどうか。 葛藤のマネジメント ファシリテーターの最も難しいスキルの一つが、葛藤への介入だ。 葛藤を消すのではなく、種類を変える。 対人の感情的な対立（有害な衝突）は場を壊す。しかし内容についての意見の相違（生産的な摩擦）は、アイデアの質を高める。ファシリテーターの役割は後者を引き出しながら、前者への転化を防ぐことだ。 詳細な介入の技法はワークショップ対立マネジメントに体系化されている。育成プログラムでは、この記事を参照資料として活用することを勧める。 中立性の保持 社内ファシリテーターにとって、外部ファシリテーターよりも難しいのがこの中立性だ。 組織内の人間は、テーマに対する意見を持っている。特定の部署の立場を持っている。過去の議論の経緯を知っている。これらすべてが、ファシリテーターとしての中立性を損なうバイアスになり得る。 「意見を持つこと」と「場で意見を表明すること」を切り分ける規律が必要になる。参加者として席にいる場合は発言していいが、ファシリテーターとして場の前に立った瞬間から、自分の意見は引き出しにしまう。 --- 育成プログラムの設計：4段階アプローチ ファシリテーターは講義で育つのではなく、経験の積み重ねで育つ。4段階の段階的アプローチが、実践の場から離れずに成長できる設計として機能する。 第1段階：観察（Observer） 育成の最初は「場を経験する」ことから始める。 この段階では、経験豊富なファシリテーター（社内の先輩か、外部のファシリテーター）が進行するワークショップに、観察者として参加する。参加者としてではなく、観察者として意図的に観ることで気づけることがある。 観察のチェックシート（例） - ファシリテーターは参加者の発言にどう反応しているか - 沈黙が生まれた時、何秒待って、どう介入しているか - 場のエネルギーが落ちた瞬間、何をしたか - 対立が生じた時、誰に対して、どんな言葉で介入したか 観察は「なんとなく見る」のではなく、記録を前提に設計する。終了後に観察ノートを書き、可能であれば経験者とのデブリーフセッションを持つ。 この段階の目標は「ファシリテーターが場でやっていること」を解像度高く言語化できるようになることだ。 第2段階：補助（Co-Facilitator） 次のステップは、経験者のファシリテーターと並走しながら、一部の役割を担う「コ・ファシリテーター」の経験だ。 担当する役割の例 - 時間管理（タイムキーパーとして公式に動く） - 付箋の整理・グルーピングの補助 - 小グループのモデレーション（全体進行は経験者が担当） - 板書・記録担当 この段階の核心は「部分的な責任を持つ」ことだ。時間管理を任されれば、場のリズムに意識を向けることを学ぶ。小グループのモデレーションを担えば、発言の引き出し方を試せる。 コ・ファシリテーション後のデブリーフは必須だ。「何がうまくいったか」「どこで迷ったか」「次に試したいことは何か」を経験者とともに言語化する時間が、成長の速度を決める。 第3段階：担当（Lead Facilitator） いよいよ自分が場の全責任を持つ段階だ。ただし、最初から難しいテーマを任せるのは育成として機能しない。 難易度の低い場から始める - 小規模なセッション（5〜8名）から開始する - テーマは自分が内容をよく理解している領域を選ぶ - 時間は短め（2〜3時間）の設定から - 参加者は心理的に安全な関係のメンバーを含める 最初から「完璧にやらなければ」という圧力は、学習を阻害する。初期のワークショップは「学習のための実験の場」として設計し、関係者にも事前にその旨を伝えることで、プレッシャーを適切にコントロールする。 参加者からのフィードバックを収集する仕組みも設計しておく。匿名の短いアンケート（3〜5問）を終了直後に回収することで、進行者自身の主観だけに頼らない改善の材料を得られる。 第4段階：指導（Mentor） 第3段階を重ねて経験を積んだファシリテーターが、次の育成対象の観察・補助段階をサポートする役割だ。 指導する立場になることで、自分の暗黙知が言語化される。「なぜあの場面でその介入を選んだのか」を説明できるようになることが、ファシリテーターとしての成熟を示す。 指導者として育つことで得られるもの - 自分の行動のパターンと盲点の自覚 - 組織固有の「場の作り方」の言語化と継承 - 後継者の存在による組織内のケイパビリティの持続性 デザイン思考と組織のリーダーシップ変革で触れた「問いを立てるリーダーへの変容」は、この第4段階で最も明確に現れる。 --- よくある失敗パターン 育成プロセスで繰り返し見られる失敗には、共通のパターンがある。 失敗1：完璧主義による出番の先送り 「もっと準備してから担当したい」という気持ちは自然だが、これが続くと第3段階に永遠に進めない。 観察と補助だけを繰り返しても、全責任を持つ経験なしには身につかないものがある。場への介入判断は、「正解を知ること」ではなく「その瞬間に動くこと」で学ぶ。 準備が完璧になることは永遠にない。準備が十分な状態で第3段階に進むより、不完全な状態で経験を積み始めることの方が、最終的に遠くに行ける。 失敗2：話しすぎ 初心者ファシリテーターの最も共通する癖が、説明過多だ。 アクティビティの説明を長くしすぎる。問いを投げた後に沈黙が怖くて補足を重ねる。参加者の発言を受けて自分の意見を添える。これらはすべて、参加者が考える時間と空間を奪う。 実際にやってみると、説明は短いほど場が動く。 「30秒で説明して後は動いてもらう」という原則を身につけることが、初期の最大の課題になる。 失敗3：中立性の崩れへの無自覚 社内ファシリテーターが陥りやすいのが、無意識のうちに特定の方向に場を誘導してしまうことだ。 自分が「正しいと思うアイデア」に対して、より多くのフォローアップ質問を投げてしまう。自分の上司に近い意見が出た時に、無意識に肯定的な表情をしてしまう。これらは参加者に察知され、場の信頼性を損なう。 定期的に自分のファシリテーションを録音・録画して振り返る習慣が、この盲点への最も実効的なアプローチだ。参加者からの匿名フィードバックに「ファシリテーターが中立的だったか」という問いを含めることも有効だ。 --- 組織文化への定着メカニズム 個人のスキル育成だけでは組織のケイパビリティにならない。スキルを持った個人が組織を去れば、それで終わりになる。 構造的な仕組みへの埋め込み ファシリテーションのスキルが「個人の特技」で止まらないよう、業務プロセスに組み込む。 具体的な埋め込みの例 - 新規プロジェクト開始時のキックオフセッションに「社内ファシリテーターが場を設計する」を標準とする - 月次の振り返り会議に、ファシリテーション手法を取り入れる - 重要な意思決定の前に「問いを立てる場」を設ける、その進行を社内ファシリテーターが担う 組織への定着ガイドで解説した「3つのレベルの変革」のうち、Level 2（プロセスへの統合）にあたる工程だ。 コミュニティの形成 社内ファシリテーターの横の繋がりを意図的に作る。 月に1度、2時間の「ファシリテーターの集い」を設ける。形式は問わない。最近の経験の共有でも、難しかった場面の相談でも、新しい手法の実験でも良い。重要なのは、孤独に実践しないことだ。 オンラインを使った場の実験についても、リモートワークショップ運営の知見を共有する場として機能させられる。 ドキュメントによる知識の継承 各ファシリテーターが蓄積した「この組織における知見」を組織の資産にする。 記録すべき内容（例） - 特定のアクティビティがこの組織でどう機能したか - 参加者が詰まりやすいポイントと、有効だった介入 - 組織特有の文脈（言葉の意味・部門間の力学）のメモ - 試みて失敗した手法と、その失敗の理由の考察 これらは外部ファシリテーターが持ち出すことのできない、組織固有の資産になる。 --- 育成を始める前に問うべきこと プログラムを設計する前に、一つ確認しておきたいことがある。 「誰をファシリテーターとして育てるか」の選定だ。 ファシリテーターの素養に向いている人の特徴がある。自分が正しいという立場にこだわらない人。他者の発言を最後まで聞ける人。場の空気の変化に敏感な人。沈黙を怖がらない人。 逆に言えば、「自分の意見を通したい」「話すのが好き」「場を盛り上げたい」という動機だけでは、ファシリテーターとしての成長は難しい。 これは能力の優劣ではなく、適性の問題だ。組織内で「ファシリテーター育成」を呼びかけた時に手を挙げた全員を育てるより、「誰がこの役割に向いているか」を丁寧に見極める時間をかけることが、育成全体の効率を高める。 --- 参考文献 - Schwarz, R. (2002). The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Managers, Trainers, and Coaches. Jossey-Bass. - Bens, I. (2017). Facilitating with Ease! Core Skills for Facilitators, Team Leaders and Members, Managers, Consultants, and Trainers (4th ed.). Jossey-Bass. - IAF (International Association of Facilitators). IAF Core Competencies. https://www.iaf-world.org/site/professional/core-competencies - 堀公俊 (2004). 『ファシリテーション入門』. 日本経済新聞社. - 堀公俊, 加藤彰 (2006). 『ファシリテーション・グラフィック——議論を「見える化」する技法』. 日本経済新聞社. --- ### デザイン思考への批判を読み解く — 万能手法という幻想を解体する視点 URL: https://designthinking.studio/articles/design-thinking-critique/ > Natasha Jenの「Design Thinking is Bullshit」をはじめ、デザイン思考への正当な批判を整理し、何が本質的問題で何が誤解かを実践者の視点で検証する。批判を知ることで、デザイン思考をより誠実に使えるようになる。 「デザイン思考は万能薬だ」という語り方が長く続いてきました。そして今、その反動が来ています。 2017年、グラフィックデザイナーでPentagramパートナーのNatasha Jenが、ニューヨークで開催された「99U Conference」で行ったトーク「Design Thinking is Bullshit」は、デザイン思考コミュニティに衝撃を与えました。彼女の主張は単なる挑発ではなく、デザイン実践者としての根拠ある異議申し立てでした。 本記事では、デザイン思考への主要な批判を整理し、何が正当で何が誤解なのかを、実践者の視点で検証します。批判を知ることは、デザイン思考を捨てることではなく、より誠実に使うための基盤になります。 --- 批判1：「付箋とポストイットで解決できる問題は存在しない」（Natasha Jen） 批判の核心 Jenの批判の中心は「デザイン思考はプロセスへの信仰であり、批判的判断を排除する」というものです。彼女は、デザイン思考ワークショップで行われる「付箋に書いて壁に貼る」「投票する」「共感する」といった活動が、専門的な判断力や批評的思考を代替してしまっていると指摘します。 「デザインには批判（critique）が必要だ。しかしデザイン思考には批判のプロセスがない」というのが彼女の根幹にある主張です。 正当な部分 この批判の正当性は高いと考えます。ワークショップでよく起こるのは、「アイデアを批判しない」という創造フェーズのルールが、プロセス全体に広がってしまい、欠陥のある方向性を誰も指摘できない雰囲気ができてしまうケースです。 参加者からの声として「批判しないルールがあるから、明らかに間違いだと思っても言い出せなかった」という発言は珍しくありません。デザイン思考の「Yes, and...」の文化は、創造フェーズでは有効ですが、テストフェーズや評価フェーズでは批判的思考が不可欠です。 誤解の部分 ただし、Jenの批判には一点の飛躍があります。彼女が批判しているのは、デザイン思考の浅い実践・誤った実践です。d.schoolが定義するデザイン思考は、テストフェーズで徹底的に批判的なユーザーフィードバックを収集することを明示的に含んでいます。問題は手法の設計ではなく、「付箋ワークショップ」だけをデザイン思考と呼んでいる実践側にあります。 --- 批判2：「デザイン思考は問題の根本原因を扱えない」 批判の概要 Winterの論文（2019）など、経営学・社会科学の立場からの批判として「デザイン思考はシステムの表層的な症状に対処するが、構造的・制度的問題を変える力を持たない」という指摘があります。 医療の待機時間を例にとれば、患者体験の改善はできても、診療報酬制度・医師不足・病院の経営構造といった根本原因には手が届かない。デザイン思考は「どう見えるか」「どう感じるか」は変えられるが、「なぜそうなっているか」のシステム変革には不向きだという論点です。 正当な部分 この批判は重要な洞察を含んでいます。実際にやってみると、デザイン思考プロジェクトが「素晴らしいプロトタイプを作ったが、組織の予算・意思決定・既存プロセスの壁で実装できない」という状況は頻繁に発生します。 デザイン思考は「何を作るか」の探索には長けていますが、「組織の中でどう実装するか」の政治的・構造的プロセスは別の能力を必要とします。 誤解の部分 これはデザイン思考の欠陥というより、デザイン思考の適用範囲の問題です。システム変革にはシステム思考（Systems Thinking）や組織開発の手法が並行して必要です。「デザイン思考だけで社会問題が解決できる」という過剰な主張を批判するのは正当ですが、デザイン思考が社会変革のプロセスの一部として機能することは十分に可能です。 --- 批判3：「エスノグラフィーの安易な借用」 批判の概要 デザイン人類学者や社会科学者からの批判として「デザイン思考のユーザーリサーチは人類学的なエスノグラフィーを安易に借用しているが、その深さと厳密さが根本的に異なる」という指摘があります。 フィールドワークを数時間行い「ユーザーを深く理解した」と言うのは、何ヶ月もフィールドに入る文化人類学的調査とは似て非なるものだという主張です。 正当な部分 この批判にも正当性があります。ワークショップで1〜2時間のインタビューを「共感フェーズ完了」として扱ってしまう実践は、確かに表層的です。特に文化的背景が複雑な問題領域（医療・教育・福祉）では、短時間のリサーチで「インサイトを得た」という過信が、実際には当事者の現実を歪めて解釈するリスクを伴います。 誤解の部分 デザイン思考のリサーチは「学術的なエスノグラフィーの代替」を意図していません。意思決定サイクルの早い商業的文脈で、「全く調査しないよりも、リサーチを組み込む」ことの価値は維持されます。重要なのは、手法の限界を自覚しながら実践することです。「このインサイトは仮説である」という認識を保ちながら進むことが、批判への誠実な応答です。 --- 批判4：「創造性の民主化は技術の軽視につながる」 批判の概要 専門的なデザイナーからの批判として「デザイン思考は『誰でもデザインできる』という幻想を広め、専門的な技術・判断力・審美眼の価値を下げる」という主張があります。 正当な部分 「付箋ワークショップに参加したら自分はデザイナーだ」という誤解が、実際のデザイン専門家が担うべき役割を軽視する方向に働くとしたら、問題です。 誤解の部分 David Kelley（IDEO創業者・Stanford d.school創設者）が主張した「Creative Confidence（創造的自信）」は、「誰もがプロのデザイナーになれる」ではなく、「誰もが創造的な問題解決に参加できる自信を持つべき」という主張です。専門家の技術と、広義のデザイン思考プロセスへの参加は両立します。 --- 批判から拾える教訓 批判者が正しく見ているのは、デザイン思考の「使われ方の歪み」だと思います。手法ではなく実践者の問題。でも、実践者の問題が繰り返されるなら、手法側にも責任の一端はあります。 そこから拾える教訓を3つ挙げます。 批判的思考を場に戻す。 「アイデアを批判しない」は創造フェーズのローカルルール。テストフェーズでは「このプロトタイプの何が機能していないか」を意図的に問わないと、良い話しか出てきません。心地よいフィードバックは、何も教えてくれない。 インサイトと事実を混同しない。 2時間のインタビューから得たのは仮説であって発見ではありません。「このインサイトを確認するために何を検証するか」という問いが、次の一手を決める。ここを省略すると、美しい付箋の壁が残るだけです。 実装の政治から逃げない。 プロトタイプが完成した日が、本当の戦いの始まりです。予算承認・既存プロセスの変更・担当者間の調整——これらを「別の誰かの仕事」にした瞬間、デザイン思考プロジェクトは死にます。 --- 批判は手法を成熟させる Natasha Jenの言葉が今も引用され続けるのは、彼女が「間違い」を言ったからではありません。彼女が正しいことを言い、かつデザイン思考の実践コミュニティが聞きたくなかったことを言ったから、です。 批判者が指摘する問題点——批判的思考の欠如・表層的なリサーチ・実装の難しさ——はすべてリアルです。現場にいれば見覚えがある。直視しながら実践を続けることが、デザイン思考を真剣に使う人間の誠実さだと考えます。 手法を盲信しないこと。手法の力を過小評価しないこと。矛盾するようですが、この両方を同時に保てる人間が、デザイン思考を本当に使える人間です。 デザイン思考の哲学的基盤を深く理解したい場合は、「Wicked Problems（悪問題）」の概念を提唱したリチャード・ブキャナンの思想が参考になる。 また、ワークショップの「プロセスへの信仰」が生まれる背景には、確証バイアスや集団思考といった認知的メカニズムが関与している。デザイン思考と認知バイアスでは、各フェーズで発動する8つのバイアスと構造的対処法を整理している。 --- 参考文献 - Jen, Natasha, "Design Thinking is Bullshit", 99U Conference, New York, 2017（動画・Core77掲載） - Winter, Anne et al., "Design thinking as a complex process," Design Studies, Vol. 65, 2019 - Kolko, Jon, "Design Thinking Comes of Age", Harvard Business Review, September 2015 - Vinsel, Lee, "Design Thinking is Kind of Like Syphilis—It's Contagious and Rots Your Brain", Medium, 2017 - Brown, Tim, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 - Kelley, David & Kelley, Tom, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 --- ### デザイン思考ワークショップのファシリテーション術 URL: https://designthinking.studio/articles/facilitation-tips/ > デザイン思考ワークショップを成功させるファシリテーションの実践技法を解説。場の設計、タイムマネジメント、困った参加者への対処法まで。 デザイン思考のワークショップは、正しいメソッドを選ぶだけでは成功しないものです。共感マップもCrazy 8sも、ファシリテーションが機能しなければただの作業になります。ツールではなく「場」が成果を決めます。 ワークショップが「盛り上がったのに何も生まれない」問題 社内でデザイン思考ワークショップを開催したことのある方なら、こんな経験に覚えがあるかもしれません。 付箋をたくさん貼って、参加者も楽しそうだった。しかし翌週には誰もワークショップの成果を覚えていない。 ワークショップでよく起こるのは、「プロセスを回すこと」が目的化するパターンです。手法の手順を忠実にこなすことに意識が向きすぎて、「この場で何を達成すべきか」が曖昧なまま進行してしまう。 結果として、参加者は「良い体験だった」と感じるが、具体的なアウトプットは残らない。 この問題は、ファシリテーターの力量に帰着する 参加者のモチベーションや能力の問題ではありません。場の設計と進行を担うファシリテーターが、成果に直結するポイントを押さえているかどうか。 経験豊富なファシリテーターほど、メソッドの選択よりも「場の空気」と「問いの質」に注意を払っています。 ワークショップ前：設計で8割が決まる ゴールを「問い」の形で定義する 「デザイン思考ワークショップを実施する」はゴールではありません。「ターゲットユーザーの未充足ニーズを3つ特定する」「次の検証で試すプロトタイプの方向性を1つ決める」のように、終了時の到達点を具体的に定義します。 ゴールをPOVステートメントや「How Might We」の問いの形で設定すると、参加者全員がゴールを共有しやすくなります。「今日の問いは〇〇です」と冒頭で宣言できるかどうかが、ワークショップの質を左右します。 参加者の組み合わせを設計する 多様性は自然には生まれません。意図的に設計する必要があります。 部署・役職・経験年数の異なるメンバーを組み合わせることで、視点の幅が広がります。 一方で、参加者が多すぎると議論が拡散します。1グループ4〜6名、全体で20名以下が管理可能な規模の目安です。これを超える場合は、サブファシリテーターを配置します。 タイムラインを「余白込み」で設計する 初心者のファシリテーターが犯しがちな失敗は、分刻みでびっしり詰まったタイムラインを作ることです。現実には、アイスブレイクが予想以上に盛り上がったり、議論が白熱して予定時間を超えたりします。 各セクションに10〜15%のバッファを組み込み、「削れるセクション」を事前にマークしておくと、当日の調整が楽になります。3時間のワークショップなら、実質2時間40分で設計するイメージです。 ワークショップ中：ファシリテーションの実践技法 最初の10分で「安全な場」を作る ワークショップの成否は冒頭10分でほぼ決まります。 参加者が「ここでは的外れなことを言っても大丈夫」と感じられる空気を、意図的に作ります。 効果的なテクニックの一つは、ファシリテーター自身が最初に「失敗例」を共有することです。「以前こんなワークショップで大失敗しまして」と笑い話を挟むだけで、場の心理的安全性が一気に上がります。 「発散」と「収束」のモード切替を明示する ダブルダイヤモンドでも解説した通り、発散と収束のモードを意識的に切り替えることが重要です。しかし参加者にとっては、今がどちらのモードなのか分からないことが多い。 「今から15分間は発散タイムです。質より量。実現可能性は考えない。判断は後で」と、モードを明確に宣言します。発散中に「それは予算的に無理」という発言が出たら、ファシリテーターが即座に「今は発散タイムなので、判断は収束フェーズで」と軌道修正します。 沈黙を恐れない 問いを投げた後、3秒で回答がなければ次の質問に移りたくなります。しかし沈黙は思考の時間です。特に内向的な参加者は、じっくり考えてから発言したい。 実際にやってみると、5秒の沈黙の後に出てくる意見のほうが、反射的に出た最初の意見より深いことが多いです。ファシリテーターが沈黙に耐える訓練は、ワークショップの質を直接的に向上させます。 付箋の使い方で差がつく デザイン思考ワークショップの象徴とも言える付箋。しかし使い方が雑だと、ただの色紙の山になります。 付箋1枚に書くのは1アイデアだけ。 太いマーカーで、離れた場所からでも読める大きさの文字で書く。これが基本ルールですが、守られていない現場は驚くほど多いです。「細いペンで小さな字で3行書かれた付箋」は、グルーピングの段階で確実に埋もれます。 時間切れを味方につける 「もう少し時間があれば」は、ワークショップで最も頻繁に聞こえるフレーズです。しかし時間の制約こそがクリエイティビティを引き出すのであって、十分な時間がある状態ではアイデアの質は必ずしも上がりません。 デザインスプリントが5日間という制約を設けているのも同じ原理です。「あと3分です」の一言が、参加者を本質的なアイデアに集中させます。 困った場面への対処法 声の大きい人が場を支配する 最もよくある問題です。対処法は「個人ワーク→共有」の順序を徹底することです。付箋に黙って書く時間を設けてから共有すれば、声の大きさに関係なく全員のアイデアが平等に扱われます。 それでも特定の人が長く話し続ける場合は、「素晴らしい視点ですね。他の方はどうですか？」と、肯定しつつ発言権を移します。直接的に遮るのではなく、場の注目を別の参加者に向けるのがコツです。 全員が黙り込む 沈黙が10秒以上続き、場が凍りつく瞬間があります。ファシリテーターが焦って自分で答えを言い始めるのは最悪のパターンです。 代わりに、「では、隣の人と2分だけ相談してみてください」とペアワークに切り替えます。2人なら話しやすい。ペアでの対話から自然と全体共有に展開できます。 「そもそもデザイン思考って意味あるの？」という懐疑派 ワークショップに懐疑的な参加者は必ず存在します。無理に説得しようとしないのが鉄則です。 むしろその懐疑をチームの資産として活用します。「確かに、机上の空論になりがちですよね。だからこそ今日は最後にユーザーに聞きに行くところまでやります」と、懐疑の正当性を認めた上で、プロセスの中で答えが出ることを示します。 ワークショップ後：成果を組織に持ち帰る 48時間以内に「次のアクション」を確定する ワークショップ直後の熱量は、48時間で急速に冷めます。終了時点で「来週の月曜日に誰が何をするか」を決めておくことが、成果の定着率を大きく左右します。 成果物を「見える場所」に置く 付箋の写真をSlackに投稿するだけでは不十分です。チームのオフィスに模造紙ごと貼り出す、デジタルボードを全員がアクセスできる場所に固定するなど、日常的に目に入る仕組みを作ります。 「やりっぱなし」にしない振り返り ワークショップから1〜2週間後に、15分の振り返りミーティングを設定します。「あのとき出たアイデアはどうなった？」「検証は進んだ？」という問いかけが、ワークショップの学びを実務に定着させます。 まず「問いの質」から変える ファシリテーション技法は数多くありますが、最も効果が高いのは「良い問いを立てる力」を磨くことです。「何かアイデアはありませんか？」よりも、「もしこのサービスの利用料が無料だったら、ユーザーの行動はどう変わるか？」の方が、はるかに質の高い対話を引き出します。 次にワークショップを企画するとき、メソッドの選定より先に「今日の問い」を30分かけて練ってみてください。 その投資が、ワークショップ全体の質を根本から変えるはずです。 --- 参考文献 - Roger Schwarz, The Skilled Facilitator: A Comprehensive Resource for Consultants, Facilitators, Coaches, and Trainers, 3rd edition, Jossey-Bass, 2017 - Sam Kaner et al., Facilitator's Guide to Participatory Decision-Making, 3rd edition, Jossey-Bass, 2014 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015（Chapter: Facilitation Tips） --- ### デザイン思考を学校教育に導入するための実践ガイド URL: https://designthinking.studio/articles/design-thinking-education/ > 小中高校・大学でのデザイン思考カリキュラム設計から授業実践まで、200回以上のワークショップ観察から導き出した導入ガイド。PBL（課題解決型学習）との接続方法を含め、教育現場での具体的な手順を解説する。 学校の教室にデザイン思考が持ち込まれるとき、最初に起きることは決まっています。「付箋をどこに貼ればいいですか？」という質問です。答えは「どこでもいい、まず書いて」——この小さなやりとりに、学校教育とデザイン思考の根本的な緊張が凝縮されています。正解を問う習慣と、正解のない探索を歓迎するマインドセットの衝突です。 200回以上のワークショップ観察から見えてきたのは、 デザイン思考の教育導入が成功するかどうかは、教師自身が「失敗してもいい」と感じられる環境を作れているかどうかに尽きる ということです。カリキュラムの設計よりも、教師のマインドセット転換が先に来ます。 なぜ今、学校教育にデザイン思考なのか 文部科学省の学習指導要領改訂（2020年〜）は「主体的・対話的で深い学び」を掲げ、知識の習得から 問いを立てる力・協働して解決する力 の育成へと重点を移しています。この方向性は、デザイン思考の核心と完全に一致します。 教育分野での先行研究では、デザイン思考を取り入れたPBL（Problem/Project-Based Learning）が従来型授業と比べて 批判的思考力・協働力・自己効力感の向上 に効果があることが示されています（Krajcik & Shin, 2014）。K-12教育でのデザイン思考導入を推進するIDEO.orgとスタンフォードd.schoolは、2010年代から教師向けトレーニングを世界規模で展開してきました。 一方で、日本の教育現場に固有の課題もあります。 授業時間の制約・評価基準の曖昧さ・教師の準備コスト という三重の障壁が、導入の足かせになっています。この記事では、これらの課題を現実的に乗り越えるための設計思想と具体策を示します。 発達段階別の接続ポイント 小学校低学年（1〜3年）：共感の種まき 低学年では「デザイン思考」という言葉を使う必要はありません。「 なぜこの人は困っているの？ 」という問いかけが、共感フェーズの入り口です。 実践例として機能するのは「困り図書館」です。クラスの誰かが「こんなことで困っている」を書いたカードを壁に貼り、他の子が「こうしたらどうだろう？」のアイデアカードを貼っていく。このシンプルな活動が、共感フェーズと創造フェーズの基本構造を、抽象的な概念ではなく 生活の中の体験 として積み上げます。 所要時間は15〜20分。道具は付箋と鉛筆のみ。評価は「正しさ」ではなく「アイデアの数」と「友達への気遣い」で行います。 小学校高学年〜中学校（4〜9年）：プロセスの体験 この発達段階では、 5フェーズの構造を意識的に体験させる ことが有効です。すべてのフェーズを1回の授業に詰め込む必要はありません。 「学校の中の不便を解決する」プロジェクトは実践頻度の高いテーマです。廊下の混雑、図書室の返却システム、給食の配膳動線——「ユーザー」（他の生徒・先生）が身近にいて、観察も取材もすぐできます。インタビュー・観察という具体的なリサーチ手法を、教室という安全な環境で初めて体験する機会になります。 ワークショップ観察で繰り返し見られた光景があります。「取材してきて」と言われた中学生たちが、最初は「知ってる友達に聞けばいいよね」と言い、やがて「知らない先生に話を聞きに行くのが一番面白い情報が出た」と気づく瞬間です。これが共感フェーズの本質的な学びです。 高校・大学：メタ認知と社会課題 高校以上では、 デザイン思考プロセス自体を対象化して学ぶ メタ認知的なアプローチが有効です。「なぜ今このフェーズにいるのか」「自分たちはどこで行き詰まっているか」を言語化する習慣が、プロジェクト型学習の質を引き上げます。 社会課題テーマ（地域の高齢化・食品ロス・不登校など）はリサーチの難度が上がりますが、その分 「簡単には解けない問題と向き合う経験」 が、大学・社会での問題解決力の基盤になります。大学ではウィキッド・プロブレムの概念を明示的に導入することで、5フェーズの反復がなぜ必要かへの理解が深まります。 カリキュラム設計の3つのモデル モデル1：単発ワークショップ型（1〜2コマ） 最もハードルが低い導入方法です。既存の授業（国語・総合学習・道徳など）の1〜2コマを使い、デザイン思考の一部を体験します。 推奨テーマ：「クラスメートの困りごとを解決するアイデアを出す」（共感→定義→発想の3フェーズのみ） この形式の目的は 「デザイン思考ってこういう感じか」という体感 であり、スキルの習得ではありません。教師への要求も低く、ファシリテーション初心者でも進行できます。 モデル2：ユニット型（5〜10時間） 総合学習や特別活動の時間を使い、一つのプロジェクトを5フェーズすべてで体験します。 「地域の人に喜ばれるものを作る」 というゴール設定が、プロトタイプと発表への動機づけを作りやすいです。 重要なのは 「不完全なプロトタイプでいい」 という明示的な許可です。紙で作った模型、貼り紙で作った看板、付箋で作ったモックアップ——これがプロトタイプです。完成品ではなく「考えを見える形にしたもの」という定義を繰り返します。 モデル3：教科横断PBL型（1学期〜1年） 最も本格的な形式で、複数教科と連携して年間を通じたプロジェクト学習に組み込みます。国語（取材・発表）・算数/数学（データ分析）・図工/美術（プロトタイプ）・社会（フィールドリサーチ）が横断的に機能します。 学校全体での理解と教師間の連携が前提 となり、導入コストは最も高くなります。しかし発達段階に応じた長期的なスキル育成という観点では、最も効果的なモデルです。 教師向け：ファシリテーションの実践術 「正解を言わない」を訓練する デザイン思考のファシリテーションで最も難しいのは、 答えを知っているのに教えないこと です。教師という役割には「答えを持つ人」という強いアイデンティティが付随しており、生徒が迷っているときに問いで返すのは、訓練なしには難しいです。 ワークショップ観察で有効と確認された問いかけの型があります。「 なぜそう思った？ 」「 その人（ユーザー）だったらどう感じる？ 」「 他の可能性は？ 」の3つです。この3つを手札として持っておくだけで、ファシリテーションの質が変わります。 時間管理：タイマーは最良の味方 デザイン思考のワークショップで時間を守ることの難しさは、現場で何度も観察されています。グループが「もっと考えたい」「まだアイデアが出ている」という状態で次のフェーズに進む指示を出すとき、教師には強い意志が必要です。 「時間が来たら次へ」というルールは、不完全な状態で前進することへの耐性を育てる 教育的意図を持っています。5分のタイマーをセットして全員の前に置くだけで、議論のペースが変わります。クレイジーエイトのような時間制約のある手法が低学年でも有効なのは、この原理を活用しているからです。 振り返り（リフレクション）を必ず入れる 各フェーズの後に2〜3分の振り返り時間を設けることが、学習効果を大きく左右します。「 気づいたこと・驚いたこと・わからなかったこと 」を各自が書き留める習慣は、デザイン思考のプロセスをメタ認知的に理解させる鍵です。 この振り返りは評価にも接続できます。「正しい答えが出せたか」ではなく「プロセスの中でどう考えたか」を評価基準にすることで、 デザイン思考の本質的な評価軸（探索・試行錯誤・他者への共感）を学校評価に組み込めます。 評価設計：デザイン思考と学校評価の橋渡し デザイン思考の成果を通知表の評価に接続することは、導入の壁の一つです。「正解/不正解」のない活動をどう評価するか。以下のルーブリック設計が200回以上の観察から有効と確認されています。 | 評価項目 | A | B | C | |---------|---|---|---| | ユーザー理解 | ユーザーの言葉・行動・感情から具体的な気づきを示せた | インタビューや観察を実施し情報を整理した | ユーザーに話を聞こうとした | | 問題の定義 | 根本的な課題を「HMW（どうすれば〜できるか）」で表現できた | 問題を言語化できた | 問題を認識した | | 発想と選択 | 10案以上出し、基準を持って絞り込んだ | 複数案を出した | 1つのアイデアを出した | | プロトタイプ | 手で触れる・見られる形にした | 図や説明で示した | 頭の中でのみ考えた | | 反復 | テスト後に改善した | 他者のフィードバックを聞いた | 一度作って終わった | このルーブリックは「過程の質」を評価するものです。完成品の品質ではなく、 探索のプロセスにどれだけ誠実に向き合ったか を測ります。 学校導入の現実：よくある失敗と処方箋 失敗1：「デザイン思考の日」に終わる 導入初年度に「デザイン思考ワークショップ」を年1回のイベントとして実施し、それで終わるパターンです。体験としては意味がありますが、習慣化と定着には繋がりません。 処方箋：既存の授業の中に「今日はデザイン思考の〇〇フェーズをやっている」という意識を持ち込む ミクロ導入 です。朝のサークルタイム5分でのHMW問い、授業の最後3分のプロトタイプ的発表——これらの積み重ねが文化を作ります。 失敗2：生徒が「何をすればいいかわからない」で停止する 開放的な問いに慣れていない生徒が、「自由に考えていい」という状況で思考停止するケースは頻繁に観察されます。 処方箋： 制約を与えることで自由を作る という逆説を使います。「付箋3枚に、3分で書け」「ユーザーは〇〇さんと決める」「材料は紙・ハサミ・テープのみ」——この種の制約が逆に創造性を解放します。 失敗3：教師がすべてをコントロールしようとする ワークショップの「散らかり」（付箋があちこちに貼られ、グループごとに違う方向に進む状態）に耐えられず、教師が全体を一つの方向に統制しようとするパターンです。 処方箋： カオスは情報だと理解する。 各グループが違う方向に進んでいることは、問題の複雑さを反映しています。振り返りの時間に「なぜ違う結果が出たか」を話し合うことで、それ自体が重要な学びになります。 まとめ：小さく始めて、継続する 学校教育へのデザイン思考導入で最も重要なことは、 完璧な導入を目指すより、不完全でも始めることです。 1クラス1時間のワークショップでも、教師が「失敗してもいい空間」を作れれば、生徒の何かが変わります。 デザイン思考は「正解を探す学習」から「問いを立てる学習」へのパラダイム転換を促します。知識基盤型の学校教育が最も苦手とすることであり、同時に最も必要としていることでもあります。教師一人の「まずやってみよう」が、その転換の出発点になります。 カリキュラム全体への組み込みを具体的に検討したい場合は、シンガポール・米国・日本の先進校事例を横断したK-12教育カリキュラムへのデザイン思考統合も参照してほしい。学年段階別の設計原則と教科横断の授業構造を詳しく解説している。 --- 参考文献 - Krajcik, J. S., & Shin, N. "Project-based learning," in R. K. Sawyer (Ed.), The Cambridge Handbook of the Learning Sciences (2nd ed.), Cambridge University Press, 2014 - IDEO.org, Design Thinking for Educators Toolkit, 2nd edition, IDEO.org, 2012 - Tim Brown & Jocelyn Wyatt, "Design Thinking for Social Innovation," Stanford Social Innovation Review, Winter 2010 - Mitchel Resnick, Lifelong Kindergarten: Cultivating Creativity through Projects, Passion, Peers, and Play, MIT Press, 2017 - 経済産業省, 「未来の教室」実証事業報告書, 経済産業省, 2020 --- ### デザイン思考を組織に根付かせる方法 ― 研修で終わらせない7つの実践 URL: https://designthinking.studio/articles/design-thinking-organizational-adoption/ > 「研修は受けたのに何も変わらなかった」を防ぐ、デザイン思考の組織定着のための7つの実践。導入後に失速する構造的な原因を解明し、現場で今日から使える具体的な手法を解説します。 デザイン思考の研修を受け、ワークショップに参加し、付箋を貼り、ペルソナを作った。それなのに、3ヶ月後には元のやり方に戻っていた。この体験に、心当たりのある方は少なくないはずです。 なぜ「研修で終わる」のか デザイン思考の組織導入が失速する理由は、研修の質が低いからではありません。問題は構造にあります。 研修は「理解させる」ことに特化しています。2日間のワークショップでダブルダイヤモンドのプロセスを体験し、「なるほど」と腑に落ちる。しかしその感覚は、職場に戻った瞬間から侵食されます。締め切り、承認フロー、前例踏襲のプレッシャー。 研修で得たマインドセットは、日常業務の重力に引き戻されます。 デザイン思考が失敗する5つのパターンでも触れたように、失敗の多くは「プロセスを導入したが、思考を導入しなかった」点にあります。では、思考を組織に根付かせるには何が必要か。以下の7つの実践が、その答えになります。 実践1：小さな本物のプロジェクトで始める 研修直後の熱量があるうちに、実際の業務課題に対してデザイン思考を適用する「小さな本物のプロジェクト」を立ち上げてください。 規模は小さくていい。社内の申請フォームを改善する、チーム間の情報共有の摩擦を解消する、それくらいのスコープで十分です。大切なのは「仮想の演習」ではなく、利害関係者がいて、結果が実務に影響するプロジェクトであること。 架空の課題でデザイン思考を練習しても、組織の文化は変わりません。本物の課題を扱うことで、初めて「これは使える」という手触りが生まれます。 実践2：週次の「15分振り返り」を制度化する デザイン思考は、一回の研修で習得できるものではありません。実践→振り返り→改善のサイクルを、組織の習慣として設計する必要があります。 週次の定例会議の冒頭15分を、振り返りの時間に充ててください。問いはシンプルに3つ：「今週、ユーザーの観点から何を学んだか」「自分たちが見落としていた仮定は何か」「次の一週間で試すことは何か」。 この問いを繰り返すだけで、チームは徐々に共感フェーズの視点を日常に持ち込むようになります。特別なワークショップは不要です。制度化された小さな問いが、文化を作ります。 実践3：「なぜ？」を5回掘る習慣をチームに持ち込む 意思決定の場面で、多くの組織は症状の表面を解決しようとします。「クレームが増えた→謝罪文を送る」「離脱率が上がった→デザインを変える」。根本原因を特定しないまま解決策に飛びつく。 5つのなぜは、シンプルですが強力な習慣です。問題が浮かび上がったとき、「なぜそれが起きているのか」を5回繰り返して掘り下げる。会議でこれを実践するだけで、チームの思考は「症状への反応」から「構造への介入」へとシフトします。 最初の1ヶ月はぎこちない。それでいい。3ヶ月続ければ、「なぜ？」と問うことがチームの当たり前になります。 実践4：ユーザーとの接点を定期的に設計する デザイン思考は人間中心設計が前提です。しかし多くの組織では、ユーザーと直接話す機会が特定の職種にしか与えられていません。営業、カスタマーサポート、開発者、企画担当。全員が定期的にユーザーと接触する仕組みを作ってください。 最もコストが低い入口は、カスタマーサポートの問い合わせ内容を週次でチームに共有することです。それだけで、ユーザーの声が会議室に入ってくる。月に一度、持ち回りでユーザーインタビューを担当する仕組みを作れば、さらに深く接触できます。 重要なのは、ユーザーとの接点が「特定の担当者の仕事」ではなく「チーム全員の習慣」になることです。 実践5：プロトタイプの心理的ハードルを下げる 「もう少し形になってから」「まだ見せられるレベルではない」。このセリフが聞こえてきたら、組織にプロトタイプ恐怖症が蔓延しています。 「プロトタイプは失敗するために作るもの」という前提を、組織全体で共有してください。 クレイジーエイトのように、8分で8案を描ける環境を作る。ストーリーボードを紙と鉛筆で15分以内に作る。 プロトタイプの品質基準を「学べるか」に限定することで、完成度への執着が消えます。形にする速さが、学びの速さに直結します。 月に一度でいいので「ラフプロトタイプ祭り」のような場を設け、クオリティより量を競う文化を意図的に育てる。 実践6：「アフィニティ・セッション」を意思決定プロセスに組み込む 研修でアフィニティダイアグラムを体験したとき、「これは楽しい」と感じた方は多いはずです。しかし実務では、このツールがほとんど使われていません。意見が対立したとき、データを見るとき、課題を整理するとき。アフィニティセッションが本領を発揮する場面は日常業務にあふれています。 月次の振り返りや、四半期の方針策定会議にアフィニティダイアグラムを組み込んでみてください。参加者がポストイットに観察事実を書いてグルーピングするだけで、「自分の意見」ではなく「共有された事実」を起点に議論できます。 政治的な会議が、探索的な会議に変わる。この変化が積み重なると、組織の意思決定文化が変わります。 実践7：「やってみた報告」の場を作る 組織にデザイン思考を根付かせる最大の障壁のひとつは、試みが可視化されないことです。誰かが新しいアプローチを試みても、それが組織の知識として蓄積されなければ、文化は生まれません。 「デザイン思考でやってみたこと」を共有する月次の場を作ってください。成功事例だけでなく、失敗事例も歓迎します。5分間のライトニングトークでいい。「試みること」が称賛される環境を設計することで、実験の頻度が上がります。 ドット投票で「次に試したいアイデア」を選ぶ15分を設けると、会議が終わった後も誰かが動き続けます。 定着は「文化の設計」である 7つの実践に共通しているのは、特別なイベントではなく、日常の仕組みを変えている点です。研修を増やすことで定着を図ろうとすると、逆効果になることさえあります。人は学んだことを忘れるのではなく、使わない環境に置かれると使わなくなるのです。 デザイン思考の組織導入を成功させるための問いは、「どんな研修をするか」ではありません。「ユーザーについて考える機会を、日常のどの場面に組み込むか」です。 ペルソナを定期的に更新する習慣、ジャーニーマップを使った問題定義のルーティン、How Might Weの問いを会議に持ち込む文化。これらが積み重なって初めて、デザイン思考は組織の血肉になります。 まず一つ、今週から始めてみてください。7つを同時に導入しようとする必要はありません。最も抵抗の少ない一つを選んで、4週間続ける。それが組織変革の正しい速度です。 --- 参考文献 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - Roger Martin, The Design of Business: Why Design Thinking is the Next Competitive Advantage, Harvard Business Press, 2009 - Tim Brown, Change by Design, HarperBusiness, 2009（第7章：Design Thinking meets the Corporation） --- ### デザイン思考実践者のバーンアウト構造と予防——感情労働の見えない代償 URL: https://designthinking.studio/articles/design-thinking-burnout-prevention/ > デザイン思考の現場で起きる実践者のバーンアウトを、感情労働・共感疲労・組織文脈の3軸で解剖する。燃え尽きの構造を知ることで、持続可能な実践の設計が可能になる。 デザイン思考の実践者は、なぜ燃え尽きるのか。 「ユーザーに共感する」「チームの対立を橋渡しする」「経営層と現場の言葉を翻訳する」——これらはデザイン思考ファシリテーターに期待される役割だ。しかしこれらが高密度な感情労働だという認識は、ほとんど共有されていない。 ワークショップ後の深い疲弊。プロジェクトへの熱量が突然消える感覚。「自分はもうデザイン思考を信じていないのではないか」という疑念——個人の弱さではない。構造が生み出している症状だ。 本記事では、デザイン思考実践者に特有のバーンアウト構造を3つの軸で解剖し、持続可能な実践の設計を考える。 --- デザイン思考実践者に特有のバーンアウトとは 一般的なバーンアウトとの違い バーンアウト（燃え尽き症候群）は1974年にHerbert Freudenbergerが提唱した概念で、Christina Maslachらによって「情緒的消耗感・脱人格化・達成感の低下」の3次元で整理された。 研究の主要な対象は、医療従事者・教師・福祉職など「人を直接ケアする」職種だ。デザイン思考実践者がこの文脈に登場することは少ない。しかし実態として、フルタイムのデザインリサーチャーやファシリテーターは医療職と類似した感情労働の負荷を担っている。 違いは、「燃え尽きていいはずがない」という組織の期待の重さだ。医療職のバーンアウトは社会的に認知されている。対して「創造的な仕事をしているのだから楽しいはず」「自分が選んだ道なのだから」という前提が、デザイン実践者の疲弊を見えなくする。 三重の感情負荷 デザイン思考の現場では、同時並行する3つの感情負荷が実践者に積み重なる。 第一はユーザーへの共感負荷だ。エスノグラフィーインタビューやシャドーイングで収集される情報には、生活苦・職場の不満・サービスへの失望が含まれる。ユーザーの感情を内側から理解しようとするほど、その痛みの一部を引き受けることになる。 第二はチームのダイナミクス管理負荷だ。ファシリテーターはワークショップ中、参加者の感情状態を継続的に観察し、沈黙・緊張・対立を読んで介入タイミングを判断し続ける。これは意識の分裂した状態での持続的な感情モニタリングであり、極めて高い認知・感情コストを要する。 第三は組織への翻訳負荷だ。ユーザーの声を経営言語に変換し、プロトタイプの価値を財務的根拠で説明し、部門間の利害を調整する——これらは「共感する人間」と「成果を出す専門家」という矛盾する役割を一人で演じ続けることを意味する。 --- 構造的に燃え尽きる3つのメカニズム メカニズム1：共感疲労（Compassion Fatigue） 共感疲労はもともと、トラウマを経験した患者を継続的にケアする援助職の現象として研究された。感情的に激しい体験を持つ他者に共感し続けることで、共感する能力そのものが枯渇していく。 デザイン思考の文脈では、これが特殊な形で現れる。ユーザーインタビューを重ねるうちに、インタビュイーの言葉が「データ」として感じられ始めたとき——それが共感疲労のサインだ。表情や言葉への感情的な反応が薄れ、プロジェクトへの熱量が落ちていく。 表面上は「プロとして客観的になった」と見える。しかし内実は「感情的につながる余力がなくなった」状態であることが多い。 自覚が遅れる。感情が麻痺していくプロセスは緩やかで、ある日突然「自分はもうユーザーに共感できていない」と気づく。その段階では、すでに相当のダメージが蓄積している。 メカニズム2：感情表示ルールとの乖離（Emotional Labor） 社会学者のArlie Hochschildが『管理された心（The Managed Heart）』（1983年）で提唱した感情労働（Emotional Labor）概念は、「組織の期待する感情を演じることで生じる労働」を指す。 デザイン思考の実践の場には、明示されていないが強力な「感情表示ルール」がある。「熱意を持って参加者を鼓舞すること」「プロジェクトへの前向きな姿勢を常に示すこと」「批判的な空気を和らげること」——これらは実践者に期待される感情表示だ。 問題は、実際に感じている感情とこれらの期待のギャップが継続するときに生じる。「このプロジェクトは組織の都合で方向性が歪んでいる」と感じながら参加者を鼓舞し続ける。「経営層はユーザーの声を本当には聞く気がない」と思いながら翻訳作業を続ける。 Hochschildはこのギャップを「感情疎外（emotional alienation）」と呼んだ。長期にわたる感情疎外は、自分の感情に対する信頼そのものを損なっていく。「自分は今何を感じているのか」がわからなくなる状態——これがバーンアウトの深層にある体験だ。 メカニズム3：成果の不可視性と責任の不均等配分 デザイン思考プロセスの成果は、多くの場合、実装フェーズの後ではじめて可視化される。ファシリテーターやリサーチャーが担う「プロセスの品質向上」「洞察の精度」「チームの創造性向上」といった貢献は、財務的指標に変換されにくく、評価されにくい。 一方で、プロジェクトが失敗した場合には「ユーザーリサーチが甘かった」「ワークショップで正しい問いを立てられなかった」という形で、デザイン実践者に責任が帰属されやすい構造がある。 成功の功績は分散し、失敗の責任は集中する——この非対称性は、実践者の「やり続ける理由」を少しずつ侵食していく。特に、組織内での孤立感（「デザイン思考を理解している人間が自分だけ」という状態）が加わると、このメカニズムは加速する。 --- 現場で起きている実態：4つのパターン パターン1：ワークショップ後の「空白期」 大規模なワークショップやデザインスプリントを主催した後、数日から数週間にわたって深い空虚感と疲労が続くケースがある。ワークショップ中は参加者のエネルギーに引っ張られて高い覚醒状態にあるが、終了後に一気に落下する。 この現象は「エモーショナル・クラッシュ」と呼ばれることがある。問題は、この空白期がプロジェクトの次のフェーズ移行期と重なり、「やる気がない」「コミットメントが低い」という評価につながる点だ。空白期は病理ではなく、高強度の感情労働後の回復プロセスだが、それが理解されにくい組織文脈が症状を悪化させる。 パターン2：「デザイン思考への信念喪失」サイクル プロジェクトの成果が出ない、または出た成果が実装されない体験が続くと、実践者はデザイン思考の手法そのものへの信頼を失い始める。「付箋を貼っても何も変わらない」「共感インタビューをしても経営判断は変わらない」という確信が強まる。 この段階では、ニヒリズムが防衛機制として機能している。感情的に投資し続けてきたアプローチを「無意味だった」と断定することで、これ以上傷つくことから身を守ろうとする心理だ。 信念喪失サイクルの危険は、次のプロジェクトで「どうせ同じだ」という予期的敗北感を持ち込み、実際に成果が出にくい状況を自己実現することにある。 パターン3：過剰な役割の内面化 「デザイン思考を広める布教者」という自己像を強く持つ実践者に特徴的なパターンだ。組織の変革エージェントとしての使命感が、「自分が倒れても続けなければならない」という信念に変容する。 休息を取ることへの罪悪感、他者にファシリテーションを任せることへの不安、プロジェクトから少し距離を置くことへの恐れ——これらが蓄積してバーンアウトに至る。 このパターンの実践者は外部からは「最もデザイン思考にコミットしている人」に見えるため、支援が届きにくい。 パターン4：組織の慢性的な抵抗への消耗 デザイン思考の導入プロジェクトで最も多い燃え尽き要因の一つが、組織の慢性的な抵抗と戦い続けることによる消耗だ。予算承認・部門の協力・経営層のコミットメントが毎回の障壁になり、プロセスそのものではなく「プロセスを実現するための政治的交渉」にエネルギーの大半が費やされる。 「デザイン思考のプロジェクトを始めること」が目的化し、ユーザーのことを考える時間が消える状態。これはデザイン思考の本来的な価値に対する裏切りであり、実践者の自己矛盾感を高める。 --- バーンアウト予防のための設計原則 原則1：共感の「分量管理」と回復プロトコル まず必要なのは、共感の質と量を意識的にモニタリングする習慣だ。「今日のインタビューで自分は何を感じたか」「どのユーザーの言葉が最も残響しているか」——10分間のデブリーフィングが、感情の蓄積を可視化する。 高密度な感情労働（長時間インタビュー、大規模ワークショップ、激しい組織内交渉）の翌日には、回復時間を意図的にスケジュールへ組み込む。怠惰ではない。次のセッションの質を担保するための投資として、組織に説明できる。 原則2：感情の分離技法——「役割としての感情」と「自分の感情」の区別 感情労働の核心的なスキルは、「場のために演じる感情」と「自分が実際に感じている感情」を区別する能力だ。これは感情を抑圧することとは異なる。 ファシリテーションの場では、場のエネルギーを維持するために前向きな感情を表示することが必要な瞬間がある。しかしそれは「役割として行っていること」であり、自分の内側の感情状態とは別に存在してよい。 セッション後に「今日、役割として表示した感情は何か」「自分の実際の感情状態はどうだったか」を分離して振り返る練習が、感情疎外の予防になる。演技している自覚があることが、演技に飲み込まれることを防ぐ。 原則3：成果の「実践的定義」の再設計 「ユーザーの課題が解決されること」のみを成果と定義すると、実装に至らないプロジェクトでは常に失敗体験が積み重なる。実践者が直接コントロールできる成果指標を定義し直すことが重要だ。 「インタビューで得られた洞察の質」「ワークショップ参加者の学習量」「プロトタイプが可視化した前提の数」——これらは実装の成否に依存せず、プロセスの品質を示す指標だ。これらを成果として記録し、積み上げていくことが、成果の不可視性に対抗する。 さらに、プロジェクト終了時の「学習ログ」を作成し、次のプロジェクトへ継承する仕組みが、「この仕事は蓄積されている」という実感をもたらす。蓄積の実感はバーンアウトに対する強力な防護因子だ。 原則4：共同体としての実践——孤立の解消 組織内で唯一のデザイン思考実践者であることの孤立感は、前述したバーンアウト加速因子だ。この孤立を解消するための処方は二方向ある。 一方は、組織内での実践コミュニティ（Community of Practice）の形成だ。デザイン思考に正式に関与していない人であっても、「ユーザーの視点を大切にしている」「プロセス設計に関心がある」人物を仲間として認識し、非公式なネットワークを育てる。 もう一方は、組織外の実践者ネットワークへのつながりだ。社外のデザインリサーチャーやファシリテーターとの交流は、「自分の悩みが個人的なものではなく構造的なものだ」という認識をもたらし、孤立感を根本から変える。 原則5：組織への構造的アプローチ——個人の問題にしない バーンアウト予防の最終的な解は、個人のレジリエンス向上ではなく組織的な条件整備にある。デザイン実践者のバーンアウトは、多くの場合、個人の問題ではなく組織設計の問題だ。 組織に対して実装すべき構造的変化としては以下が挙げられる。 ファシリテーション負荷の分散: 一人のファシリテーターが継続的にすべてのワークショップを主催する体制を見直し、負荷をローテーションする。複数の人間がファシリテーションスキルを習得することは、組織のレジリエンス向上にもつながる。 プロセス成果の評価システム化: 実装成果だけでなく、インサイトの質・チームの学習量・参加者の満足度を評価指標として公式化する。評価されることで、プロセス貢献の価値が可視化される。 「デザイン思考の失敗」を安全に語れる場の設計: 失敗を共有できる場がない組織では、失敗体験が個人の内側で蓄積し続ける。定期的な振り返りセッションで、「うまくいかなかったこと」を建設的に分析する文化を育てる。 --- 燃え尽きのサインを見逃さないために バーンアウトの早期検出は、回復の余地を大きく広げる。以下のセルフチェックリストは、定期的な自己観察のための指標だ。 感情的サイン - ユーザーインタビューの準備が「面倒」と感じるようになった - ワークショップ当日に理由のわからない憂鬱感がある - プロジェクトへの熱量が突然低下した 認知的サイン - 「どうせ変わらない」という思考が頻繁に起きる - デザイン思考の手法に対する根拠のない不信感が強まった - 新しいアプローチを試みる意欲がなくなった 行動的サイン - チームとのコミュニケーションを避けるようになった - ワークショップの準備に以前より時間がかかり、質が低下していると感じる - プロジェクト以外の場でデザイン思考の話をしたくなくなった これらのサインが複数当てはまる場合、それは「意志の弱さ」ではなく「燃え尽き構造の中にいる」というシグナルとして受け取る必要がある。 --- 持続可能な実践のために デザイン思考は「共感」を中核に置く実践だ。しかし共感を担う人間が疲弊し、燃え尽きてしまえば、プロセスの質も持続性も失われる。 「ユーザーに共感できる実践者が存在し続けること」は、成果物と同じくらい重要だ。実践者自身のウェルビーイングをデザインすること——自己保護ではなく、デザイン思考を長期的に機能させるための投資として理解されるべきだ。 感情労働の代償を可視化し、回復を設計に組み込み、孤立を共同体で解消する。この3つが、燃え尽きない実践者の条件だ。 --- --- 参考文献・出典 - Freudenberger, H. J. (1974). Staff burn-out. Journal of Social Issues, 30(1), 159–165. https://doi.org/10.1111/j.1540-4560.1974.tb00706.x — バーンアウト概念の初出論文 - Maslach, C., & Jackson, S. E. (1981). The measurement of experienced burnout. Journal of Occupational Behavior, 2(2), 99–113. https://doi.org/10.1002/job.4030020205 — MBI（Maslach Burnout Inventory）の原典 - Hochschild, A. R. (1983). The Managed Heart: Commercialization of Human Feeling. University of California Press. — 感情労働概念の原典 - Figley, C. R. (1995). Compassion fatigue as secondary traumatic stress disorder: An overview. In C. R. Figley (Ed.), Compassion Fatigue: Coping with Secondary Traumatic Stress Disorder (pp. 1–20). Brunner/Mazel. — 共感疲労の理論的基盤 - Wenger, E. (1998). Communities of Practice: Learning, Meaning, and Identity. Cambridge University Press. — 実践コミュニティ（Community of Practice）の理論的源泉 200回以上のワークショップで繰り返し観察されてきた現象として、デザイン思考ファシリテーターのバーンアウトは「個人の意志力」の問題ではなく「構造的に発生するもの」だという認識が、支援の出発点になる（デザイン思考ワークショップのファシリテーター経験に基づく観察）。 --- 関連記事 - デザイン思考への批判を読み解く - デザイン思考と組織変革の統合 - デザイン思考の限界と可能性 - ホースト・リッテルとWicked Problems——デザイン思考の理論的根拠 --- ### デジタルホワイトボードツール比較：Miro・FigJam・Mural デザイン思考での選び方 URL: https://designthinking.studio/articles/digital-whiteboard-tools-for-design-thinking/ > デザイン思考ワークショップで使うデジタルホワイトボード3ツールを徹底比較。Miro・FigJam・Muralの特徴・強み・価格帯を整理し、チーム規模・用途・フェーズ別に最適なツールの選び方を解説する。 「どのデジタルホワイトボードを使えばいいか」——デザイン思考のワークショップを企画するたびに、この問いに向き合うことになる。 Miro・FigJam・Mural。どれも「デジタルホワイトボード」というカテゴリに収まるが、設計思想・得意な用途・チームとの相性は大きく違う。価格を比較して安い方を選ぶだけでは、ワークショップの質に直結する判断を誤ることがある。 この記事では、デザイン思考の5フェーズを軸に3ツールを比較し、チームの状況に応じた選び方を整理する。 --- 3ツールの基本的な位置づけ まず大まかな立ち位置を押さえておく。 Miro は、2020年代前半のリモートワーク拡大とともに急速に普及したデジタルホワイトボードのデファクトスタンダード。テンプレートの豊富さと操作のとっつきやすさが強みで、デザイナーでない参加者が多い混成チームのワークショップに向く。 FigJam は、Figmaが提供するホワイトボードツール。Figmaの延長線上にある設計で、すでにFigmaを業務で使っているデザインチームには導線が自然だ。シンプルさを意図的に選んでいるツールで、多機能より「速く始められる」ことを優先している。 Mural は、エンタープライズ向けの協調設計に重きを置いたツール。大企業でのチェンジマネジメントやデザイン思考の組織導入を支援する機能セットを持つ。ファシリテーター向けの管理機能が充実している。 --- 各ツールの詳細 Miro 強み Miroの最大の強みは テンプレートライブラリの規模 だ。アフィニティダイアグラム、エンパシーマップ、クレイジーエイツ、カスタマージャーニーマップ、ドット投票——デザイン思考で使う主要な手法は、ほぼすべてテンプレートとして用意されている。ゼロから作る手間が省けるため、ファシリテーターがワークショップの設計に集中できる。 複数人が同時に編集しても動作が安定しており、20〜30人規模のワークショップでも大きな問題は起きにくい。外部ビデオ会議ツール（Zoom・Microsoft Teams）との連携も整っている。 AIを使った付箋のクラスタリング（「Miro AI」）機能も搭載されており、100枚以上の付箋を分類する際の下処理として機能する。 弱み 機能が多い分、初めて使う参加者には操作に戸惑いが生じやすい。特に「ズームイン・ズームアウトで画面酔いする」という声は参加者からよく出る。ワークショップ前の5〜10分の操作説明は必須と考えた方がいい。 また、無料プランには制限があり、本格的なワークショップ用途では有料プランが現実的な選択になる。 価格帯 無料プランあり（制限付き）。有料プランはチームの規模と機能セットによって複数ティアが用意されている（詳細はMiro公式サイトで確認）。 --- FigJam 強み FigJamの最大の強みは Figmaとのシームレスな連携 だ。FigJamで作ったコンテンツをFigmaに持ち込む、あるいはFigmaのデザインファイルをFigJam上で参照しながら議論する——この流れが一つのプラットフォーム内で完結する。デザインチームがアイデア出しフェーズから実装へ移行する際のコンテキスト損失が少ない。 インターフェースのシンプルさも特徴で、付箋・テキスト・図形・スタンプという基本要素に絞られている。機能が少ないゆえに「どこに何があるか」がわかりやすく、デザイナー以外の参加者でも比較的短時間で操作に慣れる。 リアクション機能（スタンプ・投票）が直感的で、ブレインストーミング中の「いいね」「気になる」のリアルタイム集計が素直に動く。 弱み Miroと比べるとテンプレートの数は少ない。デザイン思考の標準的な手法はカバーされているが、ニッチな手法や業界固有のフレームワークは自分で作ることになる。 また、Figmaのアカウントを持っていない参加者を招待する際の操作が、Miroよりやや煩雑に感じられることがある。組織全体がFigmaを使っていないチームでは、この点がボトルネックになることがある。 価格帯 Figmaのプランに付随する形で提供されている。無料プランあり。詳細はFigJam公式サイトで確認できる。 --- Mural 強み Muralが他の2ツールと大きく異なるのは ファシリテーター向けの管理機能の充実度 だ。「Facilitation Superpowers」と呼ばれる機能群により、参加者全員の視点を特定エリアに強制的に移動させる・タイマーを全員の画面に表示する・ルームを施錠して参加者の自由な移動を制限する、といった操作がファシリテーター側でコントロールできる。 大企業の研修やチェンジマネジメントのワークショップでは、この「場を管理する」機能が実際に役立つ場面がある。参加者が50人を超えるような大規模セッションでも、構造を維持しやすい設計になっている。 エンタープライズ向けのセキュリティ・コンプライアンス要件（SSO・データ保存場所の指定など）にも対応しており、情報セキュリティポリシーが厳しい組織での導入実績がある。 弱み 初期学習コストは3ツールの中で最も高い。参加者がFigJamやMiroに慣れている場合、Muralへの切り替えには時間がかかる傾向がある。 テンプレートは充実しているが、Miroほどのコミュニティによるテンプレート共有エコシステムはない。 価格帯 無料プランあり（参加者数に制限あり）。有料プランはチーム・エンタープライズ向けに複数ティアが設定されている（詳細はMural公式サイトで確認）。 --- デザイン思考のフェーズ別：どのツールが向くか 共感フェーズ 共感フェーズでのデジタルホワイトボードの主な用途は、インタビュー結果の整理とエンパシーマップの作成だ。 Miro は、インタビューの気づきを付箋に書き出してアフィニティマッピングする作業がスムーズにできる。テンプレートがそのまま使えるので、ファシリテーターの準備コストが低い。 FigJam は、デザインリサーチチームがFigmaで設計していたユーザーフローやスクリーンショットをFigJamに引き込みながら議論する使い方に向く。定性データの整理と既存デザインの比較を同一画面でやりたい場合に効率がいい。 Mural は、部署横断のステークホルダーが参加する共感フェーズに向く。ファシリテーターが参加者全員の画面を「インタビュー音声を聴くエリア」に誘導する、といった場の設計がしやすい。 問題定義フェーズ アフィニティダイアグラムでインサイトを整理し、HMW（How Might We）を設定するフェーズ。 付箋の整理・グルーピング・ドット投票という一連の作業は、3ツールとも対応しているが、Miro のAIクラスタリングは100枚を超える付箋を扱う際に下処理として機能する。ただし、AIのグルーピング結果をそのまま採用するのではなく、チームで確認と修正を行う前提で使うこと。 参加者数が多いほど付箋の量が増えるため、Muralの「特定エリアへの誘導機能」が整理作業のコントロールに役立つこともある。 創造フェーズ アイデアを大量に出すアイデア出しフェーズでは、並行ブレインストーミング（全員が同時に付箋を書く）が有効だ。 Miro の8分割キャンバステンプレートはクレイジーエイツにそのまま使えて、タイマー機能との組み合わせで時間管理もできる。 FigJam は、スタンプ（絵文字）によるリアクション機能が他の2ツールより直感的で、ブレインストーミング中の「盛り上がり」の可視化がしやすい。リモートワークショップで参加者のエネルギーが下がりやすい創造フェーズでは、この反応の即時性が場の温度を保つのに役立つ。 プロトタイプフェーズ デジタルホワイトボードがプロトタイプ作成の主戦場になることは少ないが、ストーリーボードやコンセプトスケッチの共有には使われる。 FigJam は、Figmaで作ったプロトタイプをFigJam上で共有しながらフィードバックを集める使い方が自然にできる。この連携が、デザインチームにとって最も摩擦が少ない。 Miro は、ストーリーボード用テンプレートやフレーム機能を使ったシナリオ設計に向く。UIデザインそのものはFigmaに任せ、Miroはコンセプト共有と合意形成の場として使い分けるのが現実的だ。 テストフェーズ テストフェーズでは、ユーザビリティテストの観察結果を共有し、学びを整理する用途でデジタルホワイトボードを使う。 観察メモをリアルタイムで集めて分類する作業は Miro が安定している。複数人が同時に付箋を追加できる構造が、テストセッションのライブノートテイキングに向く。 リモートワークショップでテストを実施する場合は、ビデオ会議ツールとデジタルホワイトボードの同時起動が前提になる。この点でどのツールも大きな差はないが、接続の安定性を事前に確認しておくことが重要だ。 --- 選定基準：チームの状況で決める チーム規模と参加者の背景 | 状況 | 推奨ツール | |------|-----------| | 参加者が初めてデジタルホワイトボードを使う | Miro（テンプレートが豊富、操作説明が充実） | | チームがFigmaを日常的に使っている | FigJam | | 50人以上の大規模ワークショップ | Mural | | デザイナーと非デザイナーの混成チーム | Miro または FigJam | | エンタープライズのセキュリティ要件が厳しい | Mural | 予算と既存ツールとの関係 すでにFigmaの有料プランを契約しているチームは、FigJamが追加コストなしで使える場合がある。この条件が成立するなら、FigJamを選ぶ実用的な理由がある。 Muralのエンタープライズプランは、単体のツールとしての費用対効果を考えると選定ハードルが高いが、研修・チェンジマネジメントの費用全体に組み込まれる場合は、ファシリテーション機能の価値が正当化されやすい。 用途の頻度とツールへの習熟 年に数回しかワークショップを実施しないチームは、都度ツールの使い方から説明する手間を最小化するため Miro の直感的な操作性が助けになる。 逆に、週1回以上のペースでワークショップを回すチームは、最初に学習コストをかけてでも自分たちの用途に合ったテンプレートを整備する価値がある。 --- 実際に使ってみると分かること 3ツールを横並びにして説明すると「機能の差」が前景に出るが、実際のワークショップで重要なのは 「参加者が最初の3分で迷子にならないか」 だ。 参加者からの声として多いのは、「付箋を動かそうとして全体のキャンバスを動かしてしまった」「自分の付箋がどこにあるかわからなくなった」という類の混乱だ。この問題はツールの選定よりも、ワークショップ開始前の5〜10分の「ツール練習タイム」の設計で解消できることが多い。 ツール選定の前に確認すべきは、参加者の操作習熟に時間を割く余裕があるかどうか だ。半日のワークショップなら練習タイムを設けられるが、60分の短時間セッションでは操作説明に使える時間が限られる。後者なら、参加者の多くが触ったことのあるツールを優先する判断も合理的だ。 --- まとめ：選び方の原則 3ツールを比較してきたが、「どれが最高か」という問いには意味がない。正しい問いは「今のチームと目的に、どれが一番摩擦が少ないか」だ。 - Miro — 汎用性と導入のしやすさが最大の強み。デザイン思考の手法をカバーするテンプレートが揃っており、混成チームのファーストチョイスになる。 - FigJam — Figmaを使うデザインチームへの自然な拡張。シンプルさと連携が強み。 - Mural — 大規模・エンタープライズのワークショップ管理に特化。ファシリテーターの制御力が強みで、セキュリティ要件への対応も厚い。 ツールは手段であって、ワークショップの質を決めるのはファシリテーターの設計力と、参加者が安心してアイデアを出せる場の空気だ。どのツールを選んでも、その原則は変わらない。 --- 参考文献 - Miro, "Online Whiteboard for Realtime Collaboration", https://miro.com/whiteboard/, 2024 - Figma, "FigJam: The Online Collaborative Whiteboard for Teams", https://www.figma.com/figjam/, 2024 - Mural, "Facilitation Superpowers", https://www.mural.co/features/superpowers, 2024 - Nielsen Norman Group, "Tools for Remote UX Workshops", https://www.nngroup.com/articles/tools-remote-ux-workshops/, 2023 - IDEO.org, "Design Thinking Resources", https://designthinking.ideo.com/, 2024 --- ### テストフェーズ——ユーザーから学び、改善を続ける URL: https://designthinking.studio/articles/test-phase/ > デザイン思考の第5フェーズ「テスト（Test）」を解説。ユーザーテストの計画と実施、フィードバックの解釈、イテレーションの進め方。 テスト（Test）は、プロトタイプをユーザーに体験してもらい、フィードバックから学ぶフェーズです。 テストの目的 テストフェーズには3つの目的があります。 - 解決策の検証 — プロトタイプがユーザーの問題を解決するか確認する - ユーザー理解の深化 — テストを通じて新たなインサイトを得る - 問題定義の再検証 — そもそも正しい問題を解いているか確認する テストの進め方 実際のテスト手法についてはユーザビリティテストで詳しく解説しています。ここでは3つの核心的なステップを示します。 - テストの準備 - テストする仮説を明確にする - ユーザーに何を体験してもらうかシナリオを作成する - フィードバックを記録する方法を決める - テストの実施 テスト中に意識すべきポイントは以下の通りです。 - プロトタイプの説明を最小限にする — ユーザー自身に触ってもらい、理解できるか観察する - 「どう思いますか？」と聞かない — 代わりに行動を観察し、具体的な質問をする - 防御的にならない — ネガティブなフィードバックこそ価値がある - 沈黙を活用する — ユーザーが操作に詰まる瞬間が重要なインサイト - フィードバックの整理 テスト後は、得られたフィードバックを以下の観点で整理します。 - うまくいったこと — ユーザーが直感的に理解・操作できた部分 - 困難があったこと — ユーザーが迷ったり、間違えたりした部分 - 新しい発見 — 予期しなかったユーザーの行動や反応 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、ユーザーテストの結果を「自分たちの解釈」でフィルタリングしてしまうパターンです。「このユーザーは特殊ケース」「慣れれば使えるはず」と、チームにとって不都合な発見を無効化していく。 実際にやってみると分かるのですが、ユーザーが操作に詰まって沈黙する20秒間が、チームの設計上の仮定を全部ひっくり返すことがあります。 その沈黙を「ユーザーの理解力の問題」として処理した瞬間、デザイン思考のテストは形骸化します。テストが辛い理由は「自分たちが間違っていたと分かる」からですが、それこそがテストの価値です。 イテレーション テスト結果に基づいて、プロトタイプを改善するか、前のフェーズに戻ります。 - フィードバックが肯定的 → プロトタイプの忠実度を上げて再テスト - 解決策に問題がある → 創造フェーズに戻り、別のアイデアを検討 - 問題設定自体に問題がある → 問題定義フェーズに戻り、POVを見直す まとめ テストフェーズは、デザイン思考の反復的な性質を最もよく体現するプロセスです。失敗を恐れず、ユーザーから学ぶ姿勢がイノベーションを生みます。テストを体系的に計画する方法についてはユーザビリティテスト計画の立て方：5ステップ完全ガイドで詳しく解説している。リモートでのテスト実施に役立つツールについてはデジタルホワイトボードツール比較：Miro・FigJam・Mural デザイン思考での選び方も参照してほしい。 --- 参考文献 - Jakob Nielsen & Thomas K. Landauer, "A mathematical model of the finding of usability problems", INTERCHI '93 Proceedings, 1993 - Steve Krug, Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, New Riders, 2010 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） --- ### ドン・ノーマン思想の進化史：認知科学からHCDを経て「人間性中心デザイン」へ URL: https://designthinking.studio/articles/don-norman-evolution/ > 1988年の『誰のためのデザイン？』から2023年の『未来のデザイン』まで、ドン・ノーマンの思想はどのように変容したのか。HCDの生みの親が「HCDは十分ではない」と語る理由を追う。 ドン・ノーマンは「デザイン思考の思想的背景」を語るとき、必ず名前が挙がる人物です。しかし彼の仕事を一冊の本で理解しようとすると、その射程の広さを見誤ります。ノーマンの思想は、1988年から現在にかけて三つの大きな転換を経ており、それぞれの段階で彼が答えようとした問いが根本的に異なります。 第一期（1988–2002）：認知科学者としての問い 『誰のためのデザイン？』が問い直したこと 1988年に出版された The Design of Everyday Things（邦題：『誰のためのデザイン？』）は、認知科学者としてのノーマンが「なぜ人はモノを使いこなせないのか」を問い直した書物です。 それ以前のデザイン評価は暗黙のうちに「使えないのはユーザーの問題」という前提を抱えていました。インターフェースを理解できないユーザーが悪い、説明書を読まないユーザーが悪い——そういう前提です。ノーマンはこの前提を正面から否定しました。「失敗はユーザーではなく、デザインの問題だ」という命題が、この本全体の骨格です。 この転換を支えたのが認知科学の知見でした。ノーマンはアフォーダンス（Affordance）、シグニファイア（Signifier）、メンタルモデル、フィードバックとフィードフォワードという一連の概念を提示しました。アフォーダンスは物体がユーザーに「こう使える」と知覚させる特性です。取っ手のついたドアは「引く」ことをアフォードし、フラットなプレートは「押す」ことをアフォードします。 重要なのは、この書が「良いデザインとは何か」を規定するのではなく、「デザインがどのようにして失敗するか」のメカニズムを解明した点です。認知科学的な記述言語をデザイン批評に持ち込んだことで、「使いにくい」という感覚的な判断が、検証可能な分析へと変換されました。 HCDという概念の整理 1988年版に続き、2002年から2003年にかけてノーマンは Human-Centered System Design を理論的に整理し始めます。人間中心設計（Human-Centered Design：HCD）という概念は1990年代のISO規格（ISO 13407）で定式化されつつありましたが、ノーマンはこれを「認知科学の知見をデザインプロセスに組み込む方法論」として再解釈しました。 HCDの核心は「設計者の意図ではなく、ユーザーの思考とニーズを起点とする」という姿勢です。これはデザイン思考の「共感フェーズ」の理論的背骨となりました。共感フェーズで「ユーザーの文脈に飛び込む」ことを重視する根拠は、ノーマンが解明した「デザイナーのモデルとユーザーのメンタルモデルのギャップ」の問題に直接由来しています。 --- 第二期（2003–2013）：感情と体験の問い 『エモーショナル・デザイン』（2004） 2004年に出版された Emotional Design: Why We Love (or Hate) Everyday Things（邦題：『エモーショナル・デザイン』）は、第一期の「機能性・使いやすさ」中心の枠組みを大きく拡張しました。 ノーマンは製品への感情的反応を三つのレベルで整理します。 本能レベル（Visceral Level） は、見た目・音・触感への即時反応です。理屈ではなく本能が動く領域で、美しいものは使いやすく感じられるという現象（美的ユーザビリティ効果）の土台がここにあります。 行動レベル（Behavioral Level） は、使用中の体験です。使いやすさ、効率性、達成感がここに属します。第一期の Design of Everyday Things が主に扱っていたのはこのレベルです。 内省レベル（Reflective Level） は、使用後の意味づけと自己認識の領域です。「このブランドを使う自分」「このモノが象徴するもの」——ラグジュアリーブランドの価値や思い出の品への愛着は、ここで生まれます。 この三層構造は、デザイン思考のプロセスにも大きな問いを投げかけます。ユーザーインタビューで「何が欲しいか」を聞くだけでは、本能レベルと内省レベルの欲求を取りこぼす可能性があります。人は自分の感情反応を正確に言語化できないからです。観察法や感情マッピングといった手法が必要とされる根拠がここにあります。 「人間中心設計」へのコミットとその深化 2013年に改訂された The Design of Everyday Things（日本語版タイトル：『デザインの心理学』）では、スマートフォン時代に対応した事例が追加され、テクノロジーの急速な変化の中でも「人間の認知特性は変わらない」という主張が補強されました。この時期のノーマンは、HCDをデザイン界のスタンダードとして普及させることに精力を注ぎました。 --- 第三期（2023–現在）：「HCDは十分ではない」という転換 老齢のデザイン研究者が見えてきたもの 2023年に出版された Design for a Better World: Meaningful, Sustainable, Humanity Centered（邦題：『未来のデザイン』）は、ノーマンが数十年かけて到達した思想的転換の記録です。副題に「Humanity Centered」とあります——HumanではなくHumanity（人間性・人類）です。 ノーマンが語る転換の核心は、「HCDは個人の使いやすさを最適化するが、社会と地球の問題には対処できない」という認識です。 スマートフォンは人間中心設計の観点から見れば高度に洗練されています。しかし、その洗練されたデザインが人々の注意をどれだけ奪い、社会的孤立を生み出し、精神的健康を損なっているかを見るとき、「ユーザーにとって使いやすい」という評価基準だけでは問題の全貌が見えません。 三つの原則 ノーマンが提唱する「人間性中心デザイン（Humanity-Centered Design）」は、三つの原則で構成されます。 第一の原則：個人ではなく社会と地球を中心に置く。 単一のユーザーやペルソナに最適化するのではなく、そのデザインが社会システムと自然環境に与える影響を設計の起点に据えます。 第二の原則：短期最適化から長期的持続可能性へ。 「今のユーザーが今何を欲しているか」だけでなく、「10年後の社会でこのデザインが何を生んでいるか」を問います。 第三の原則：デザイナーの責任の拡張。 製品の完成をゴールとするのではなく、その製品が社会に入った後の影響についても設計者が責任を持つという倫理的な宣言です。 なぜこの転換は重要か この主張は、デザイン思考の実践者にとって「共感の対象は誰か」という根本的な問いを再設定します。 従来のデザイン思考における「共感」は、対象ユーザー——特定のペルソナで表現される個人——に向けられていました。ノーマンの新しい主張は、共感の対象を「現在のユーザー」から「将来世代と地球生態系」へと拡張することを求めます。 これは抽象的な哲学的主張ではありません。2023年現在、ESG投資の基準化、EU規制によるサーキュラーエコノミーの強制、AIシステムの社会的影響評価など、「デザインの社会的責任」を問う制度的な動きが加速しています。ノーマンの転換は、こうした時代的要請と深く共鳴しています。 --- 三段階の変遷が示すもの | 時期 | 中心概念 | 問い | 代表作 | |------|---------|------|--------| | 第一期（1988–2002）| 認知・アフォーダンス | なぜ人はモノを使いこなせないのか | The Design of Everyday Things | | 第二期（2003–2013）| 感情・体験の三層 | 人は製品に何を感じ、何を意味づけるか | Emotional Design | | 第三期（2023–現在）| 人間性・持続可能性 | 設計が社会と地球に何をもたらすか | Design for a Better World | ノーマンの思想の変遷は、彼個人のキャリアの変化であると同時に、デザイン思考が問い続けてきた「誰のためのデザインか」という問い自体の射程が広がってきた歴史でもあります。 1988年の答えは「目の前のユーザー」でした。2023年の答えは「人類と地球」です。この35年のジャンプを理解することで、デザイン思考の現在地とその限界が初めて見えてきます。 --- 参考文献 - Don Norman, The Design of Everyday Things, Basic Books, 1988（改訂版2013） - Don Norman, Emotional Design: Why We Love (or Hate) Everyday Things, Basic Books, 2004 - Don Norman, Living with Complexity, MIT Press, 2010 - Don Norman, Design for a Better World: Meaningful, Sustainable, Humanity Centered, MIT Press, 2023 - Don Norman, "Design Thinking: A Useful Myth", Core77, 2010 --- ### なぜ最新のAI農業ツールは畑に放置されるのか——デザイン思考が教える現場定着の設計 URL: https://designthinking.studio/articles/design-thinking-agritech-farmer-adoption/ > スマート農業のIoT/AIツールが導入後に使われなくなる現象を、デザイン思考の共感フェーズの欠落として読み解く。観察単位を農家個人ではなく水利・共同作業を担う集落に引き直すことで、現場に定着する農業DXの設計手順を示す。 こんな光景を思い浮かべてほしい。高原野菜の産地、レタス畑の畝から少し離れた場所に、白いケースに入った土壌センサーが転がっている。表示ランプはとうに消え、周りには夏草が絡みついている。数十万円、時に100万円を超える投資をして導入されたはずのIoT機器が、こうして「置物」になっている光景は、スマート農業の現場で珍しくない。水稲でも施設園芸でも、機器の種類が違うだけで同じ光景に出会う。 性能の問題ではない。開発側がユーザーの生活と判断のリズムを十分に観察しないまま、設計を進めてしまうことに答えの多くはある。ユーザーの行動や環境を深く理解することから設計を始める考え方——デザイン思考——は、この観察の工程を「共感フェーズ」と呼ぶ。多くのスマート農業プロジェクトが、ここを飛ばしたまま機能設計に進む。本稿ではデザイン思考の実践知の側から、この「導入したのに使われない」構造を読み解く。そしてこの記事が最も伝えたい点はここにある。共感フェーズで見るべき「ユーザー」の単位は、農家一人ひとりではなく、水利や作業を共にする集落そのものだ。 農林水産省が令和元年度から実施してきた「スマート農業実証プロジェクト」（全国217地区で展開）では、品目・作業ごとの労働時間削減効果が農林水産省の公表資料上で整理されている一方、導入後に現場でどれだけ使われ続けているかという継続利用の実態は、公的統計として十分に可視化されていない。補助金を使って導入まではこぎつけても、しばらくすると使われなくなる機器があるという声は、農業DXの現場で繰り返し聞かれる。これは特定の企業や地域だけに起きる例外ではなく、構造的に起きやすいパターンだ。 スマート農業の「導入したのに使われない」問題の正体 補助金主導の普及と「使われる」ことの違い 補助金は、導入のハードルを下げる目的では有効に機能する。実際の制度は労働生産性の向上など成果指標を伴う設計になっているものも多いが、対外的に語られやすいのは「何台導入されたか」「普及率がどれだけ上がったか」という分かりやすい数字だ。導入時点の数字が注目される一方、機器が数ヶ月後にどう使われているかは、同じ熱量では追跡されにくい。 しかし農家にとっての価値は、導入した瞬間ではなく、日々の作業の中で機器がどう役立つかにある。導入と定着はまったく別の指標であり、前者だけを追いかけると、後者の失敗が見えないまま次の予算サイクルに進んでしまう。 機能中心設計が見落とす、農家の身体知・勘・世代間の知恵継承 生育予測AIや土壌センサーの多くは、「精度の高いデータを提供すれば農家の判断が改善する」という前提で設計されている。土を触った時の湿り気。朝の空気の匂い。風の向き。長年その土地で作物を育ててきた農家は、こうした感覚的な手がかりから、一定の確からしさで判断を下しており、それが数値化されないまま蓄積されている。 この判断は個人の勘というより、親から子へ、先輩から後輩へと集落の中で受け継がれてきた知恵の体系に近い。数値データはこの体系を補強することはできても、まるごと置き換えることは難しい。機能を積み増すほど、この身体知との接続はかえって希薄になる——高機能化と現場定着が反比例するという逆説は、農業DXの現場で繰り返し観察される構図だ。 他業界（ヘルスケア）の類似失敗パターンとの共通点 似た構図は農業に限らない。電子カルテ（EHR）の記録負担については、臨床情報学分野の学術誌（Journal of the American Medical Informatics Association）に掲載されたスコーピングレビューでも、供給側が想定した入力フローと医師・看護師の実際の記録行動がかみ合わない点が繰り返し課題として取り上げられている。業種は違っても、供給側の機能設計が先行し、使い手の行動観察が後回しになるという骨格は共通しており、ツールの完成度と現場での定着率は必ずしも比例しない。 共感フェーズを「同行観察」で実装する アンケート・ヒアリングでは拾えない「暗黙の判断基準」 「この機器は使いやすいですか」と聞けば、多くの農家は礼儀正しく「便利だと思います」と答えるだろう。だがアンケートやヒアリングは、本人が自覚し、言語化できる範囲の情報しか拾えない。 長年の経験に基づく判断の多くは、当人にとって当たり前すぎて、質問されても言葉にならない。いつ畑に出て、何を見て、どのタイミングで作業を切り上げるか——この暗黙の判断基準こそが設計の出発点になるはずだが、質問紙の外側に置き去りにされやすい。 早朝からの同行観察で見えてくる一日の作業リズムと意思決定ポイント この手法自体は新しくない。1999年に放送された米ABCニュースの企画「The Deep Dive」で、IDEOがわずか5日間の制約の中でショッピングカートを再設計した際も、実際に店舗で買い物をする人々の動きをつぶさに観察するところから作業を始めている。もっとも、そのまま農業DXに輸入できる話ではない。ショッピングカートは店内の数分単位の行動が観察対象であり、5日間あれば相応の事例数が集まる。農家の判断は季節・天候・集落の人間関係にまたがる時間軸の中で積み上がっており、短時間の行動観察だけでは再現できない。農業DXの現場に置き換えるなら、開発者や自治体担当者が収穫期の数日間、できれば複数の作業の節目にまたがって実際に農家の一日に同行し、判断がどのタイミングで、何を根拠に下されているかを見ることに当たる——IDEOの5日間よりも長い時間軸を要求される作業だ。 高原レタスの収穫期を例に想像してみよう。朝5時前の出荷判断が最初の山場になる。腰にタオルを掛け、畝のあいだを歩きながら葉の色や巻きの固さ、土の湿り気を確かめる——そんな仕草が思い浮かぶ。数値化されたセンサー表示だけでは代替しにくい、身体感覚に基づく判断だ。この時間、この動作の中にこそ、意思決定の瞬間が埋め込まれている。スマートフォンを取り出して画面を確認するという行為自体が、この一連の流れにどれほど不自然に割り込むかは、同行しなければ実感しにくい。 もっとも、この同行観察には現実的な壁がある。数日分の人件費や移動費を誰が負担するのか、単年度予算の実証事業でそもそも観察に割ける工数が確保できるのか、という問いだ。ここへの現実解は、対象を1〜2集落に絞り込み、実装フェーズの試作コストを削ってでも観察に予算を回すという配分の見直しにある。共感フェーズを削って機能を増やすより、機能を削って観察に時間を割いた方が、結果的に定着率で回収できる。 集落・共同体という単位を無視した個人向け設計の落とし穴 農業は一見、個人単位の作業に見える。実際には、土地改良区が管理する用水路の水利調整、集落単位で日程を揃える共同防除、収穫期の手伝いなど、相互扶助によって成り立っている場面が多い。 一軒だけを対象にツールを試験導入しても、周囲との足並みが揃わなければ効果は限定的になり、口コミによる自然な広がりも起きにくい。個人向けのプロダクト設計をそのまま持ち込むと、この共同体という単位を見落としたまま検証が進んでしまう。 現場に定着するプロトタイプの作り方 「新しい画面」ではなく「既存動線への統合」という設計原則 新しい機能を作るとき、多くの開発チームは新しいアプリや専用画面を用意しようとする。農家の生活には、そんな画面はもともと存在しない。毎朝それを開く習慣を身につけること自体が、負担になる。実証事業のよくある失敗パターンがこれだ。操作性を練り込んだ専用アプリを用意しても、初回だけ使われてその後開かれなくなる、という結果に終わるケースは珍しくないと言われる。原因は使いにくさではなく、そもそも「新しい画面を毎朝開く」という行動が、農家の一日の動線に存在していなかったことにある。 この失敗を他人事として書けるわけではない。デザイン思考の伴走支援に携わる中で、似た光景を何度か目にしてきた。「見やすさ」を追求してダッシュボード画面を作り込んだプロジェクトで、配布後のアクセスログを見ると、画面が開かれたのは説明会当日だけで、その後はほぼ動きが止まっていた——というケースだ。原因は画面の出来ではなく、それを開くタイミングを利用者の一日のどこにも組み込んでいなかったという、ごく単純な見落としだった。共感フェーズを丁寧にやったつもりでも、「動線に載せる」という一点を飛ばせば、設計側は同じ失敗を繰り返す。 すでに毎朝チェックしている天気予報や、地域の無線放送に情報を重ねて届けるほうが、行動変容を求めずに定着しやすい。新しい習慣を作らせるのではなく、既存の動線に情報を割り込ませる設計のほうが、現場での摩擦は小さい。 集落単位の小規模プロトタイプ→検証→拡大という進め方 共感フェーズで見えてきた作業リズムをもとに、いきなり広域展開するのではなく、まず一つの集落で小規模なプロトタイプを試す。数週間の期間で反応を見て、うまくいかない部分を素早く修正し、それから次の集落に展開範囲を広げていく。 小さく試して検証し、それから広げるこの進め方は、失敗のコストを小さく抑えながら、集落ごとの慣習の違いにも対応できる。一気に予算を使い切る大規模導入よりも、地味だが着実に定着率を積み上げられる。 定着を測る指標を「導入数」から「継続利用率」に変える 最後に見直すべきは、成果指標そのものだ。導入台数や補助金の執行率は、プロジェクトの立ち上げ段階では追いやすい数字だが、現場での価値を測る指標としては不十分である。 三ヶ月後、半年後にどれだけの農家が実際に機器を使い続けているか——継続利用率を主要な指標に据えることで、初めて「使われるツール」を作る動機がチーム全体に共有される。 畑の隅で雨ざらしになっているセンサーは、技術の失敗ではなく、観察の不足を映す鏡だ。共感フェーズを飛ばして機能を積み上げても、現場には定着しない。そして観察の対象を個々の農家に絞っている限り、その鏡は曇ったままだ。ユーザーの単位を集落に引き直したときに初めて、水利や相互扶助まで含めた「使われ方」が見えてくる。 あなたのチームが最後に、ユーザーの一日、そしてその周りの集落に丸ごと同行したのはいつですか。次の農業DXプロジェクトの一歩目は、要件定義書を書き始める前に、その問いに答えることから始まる。 --- ### パタゴニアのサステナビリティ設計 — 「環境最優先」がデザイン思考に与えた影響 URL: https://designthinking.studio/articles/patagonia-sustainability-design/ > 「Don't Buy This Jacket」キャンペーンから修理サービス「Worn Wear」まで、パタゴニアが実践する環境最優先の設計思想を解剖。デザイン思考の文脈でパタゴニアの意思決定プロセスが示す示唆を整理する。 「地球が唯一の株主だ」 2022年9月、パタゴニアの創業者イヴォン・シュイナードは、自身と家族が保有する全株式（推定30億ドル相当）を、議決権株の2%を保有する「Patagonia Purpose Trust」と、無議決権株の98%を保有する非営利組織「Holdfast Collective」の2つの組織に譲渡しました。企業の利益を永続的に地球環境への投資に回す構造を、法的に固定化したのです。 この決断は象徴的ですが、パタゴニアの本質はここではありません。本質は「環境最優先」という制約を起点に、製品・ビジネスモデル・顧客関係のすべてを再設計してきた40年以上の実践の蓄積にあります。 --- 「Don't Buy This Jacket」——逆説的コミュニケーションの設計 2011年のブラックフライデー（アメリカで最大の消費促進日）に、パタゴニアはニューヨーク・タイムズ紙に全面広告を掲載しました。内容は「Don't Buy This Jacket（このジャケットを買わないでください）」。 広告には、自社のベストセラー製品「R2ジャケット」の製造が生む環境負荷が数値で記されていました。製造に使われる水の量（135リットル）、排出されるCO2（約9kg）、埋立廃棄物の量。そして「本当に必要なものしか買わないでください」というメッセージ。 消費を促進する日に、消費を抑制するメッセージを出した。この逆説は単なる「良いPR」ではありません。パタゴニアの設計哲学の表明です。 ワークショップでよく起こるのは「サステナビリティとビジネス成長は矛盾する」という前提でチームが議論を止めてしまうパターンです。パタゴニアの事例が面白いのは、この「矛盾」を制約として受け入れた上で設計を始め、結果として成長してきたという点にあります。 --- Worn Wear——製品ライフサイクルの再設計 パタゴニアが2013年に始めた「Worn Wear」プログラムは、製品の修理・再販・下取りを中心に据えたビジネスモデルの拡張です。 修理の体系化 通常、アパレル企業が修理サービスを提供するのは「アフターサービス」の位置づけです。パタゴニアは修理を製品価値の中核と位置付け、修理拠点を全世界に展開しました。アメリカのネバダ州リノにある修理センターは、年間10万件以上の修理を処理します。 デザイン思考の視点で見ると、これは「製品のライフサイクル全体をユーザー体験として設計する」という発想の具体化です。購入→使用→修理→再使用という循環を、単一の体験として設計している。 中古品市場の公式化 Worn Wearの一環として、パタゴニアは自社製品の中古品マーケットプレイスも運営しています。二次流通を公式チャネルとして取り込むことで、製品が廃棄される代わりに継続して使用される仕組みを作っています。 参加者からの声として、ワークショップで「中古品市場を公式化すると新品販売が減る」という懸念が出ます。パタゴニアのデータはこれを否定しています。修理・再販のプログラムに参加した顧客は、新品の購入頻度も高いというデータが出ています。「製品を大切にする顧客」はブランドへの関与が深く、長期的な購買行動につながる。 --- 素材開発——デザイン思考の上流への拡張 パタゴニアのサステナビリティ設計が他社と根本的に異なるのは、「素材の調達・製造プロセス」までをデザインの対象として扱っている点です。 フリース素材とペットボトルリサイクル 1993年、パタゴニアはリサイクルペットボトルからフリース素材を製造する技術を開発し、製品に導入しました。当時これは業界初の試みで、技術的に不確実でコストも高い選択でした。 デザイン思考の文脈で言えば、これは「ユーザーニーズ（暖かいフリース）」「環境制約（石油由来素材の使用削減）」「技術的実現可能性（リサイクル技術）」の交差点を探索した結果として理解できます。 ブルエンジニアリング（Bluesign認証） 現在のパタゴニアは、サプライチェーン全体に環境基準を適用するBluesign認証を採用しています。単に製品設計だけでなく、製造工程での水使用・化学物質・エネルギー使用までを設計の範囲として扱っています。 これはデザイン思考の「共感」の対象が、エンドユーザーだけでなく製造現場の労働者・地域環境・将来世代にまで拡張されていることを意味します。 --- 「1% for the Planet」——ビジネスモデルとしての環境投資 パタゴニアは1989年から、年間売上の1%を環境保護団体に寄付するプログラムを運営しています。これは「利益の一部を寄付する」CSRではなく、「売上が上がるほど環境投資が増える」という構造になっています。 この設計が示す洞察は「環境コストをビジネスモデルの外部に置かない」という姿勢です。通常、環境負荷は「外部不経済」として企業会計の外に置かれます。1% for the Planetは、その一部を内部化する試みです。 実際にやってみると、この構造は内部的な意思決定にも影響します。「この製品はコスト的に成立するか」という問いに、環境投資分のコストが最初から含まれているため、より環境負荷の低い設計が選ばれやすくなります。 --- デザイン思考への示唆 パタゴニアの実践からデザイン思考への示唆を整理すると、3点に集約されます。 制約は設計の起点になる。 「環境最優先」という厳しい制約は、創造性を殺すのではなく、創造性の方向性を定めます。「何でもあり」の状態より、明確な制約がある方が革新的な解決策が生まれやすいことを、パタゴニアは証明しています。 ユーザーの定義を広げる。 製品を使う消費者だけでなく、製造に関わる労働者・製品が廃棄される環境・将来世代を「ユーザー」として設計に組み込む。共感の対象を広げることで、設計の倫理的射程が変わります。 ビジネスモデルをデザインする。 パタゴニアの本質的なイノベーションは、製品デザインではなくビジネスモデルのデザインです。「修理」「中古品市場」「環境投資の内部化」という仕組みそのものが設計の対象です。 --- やってみよう 自分のプロジェクトやサービスに「パタゴニア的な制約」を設定してみてください。「環境負荷をゼロにするとしたら、このサービスはどう設計されるか？」「このサービスを100年後も存続させるとしたら、何を変える必要があるか？」という問いは、現在の設計の前提を強力に揺さぶります。 --- 参考文献 - Chouinard, Yvon, Let My People Go Surfing: The Education of a Reluctant Businessman, Penguin Books, 2005 - Marcario, Rose, "Patagonia's CEO Explains How to Lead With Social Responsibility", Harvard Business Review, September 2018 - Patagonia, "Don't Buy This Jacket, Black Friday and the New York Times", Patagonia Stories, November 2011 - Kaza, Stacy, "Patagonia: The Making of a Green Activist Company", Environmental Communication, Vol. 9, 2015 - Lovins, Hunter et al., A Finer Future: Creating an Economy in Service to Life, New Society Publishers, 2018 --- ### パタゴニアのデザイン思考：使命起点の製品設計と「修理する」という逆サービス設計 URL: https://designthinking.studio/articles/case-patagonia-design/ > 「この上着を買わないで」と広告を打つアウトドアブランドは、なぜ成長し続けるのか。Worn Wearプログラムと修理サービスが体現する、共感の対象が顧客ではなく地球に向いたデザイン思考。 2011年のブラックフライデー。パタゴニアは The New York Times に全面広告を掲載しました。メッセージはたった一行——「Don't Buy This Jacket（この上着を買わないで）」。 自社製品を買わないよう促す広告を、最大の消費イベントの日に出す。これは逆説的なマーケティング戦略なのか、それとも本物の思想なのか。この問いに向き合うことが、パタゴニアというブランドのデザイン思考を理解する入り口です。 使命が先、製品が後 パタゴニアの企業使命は「ビジネスを手段として、故郷の星を救う」です。1973年の創業以来、このフレーズは変わっていません。しかし2022年、創業者イヴォン・シュイナードは会社の株式を環境保護のための非営利団体に移譲するという前例のない決断をしました。シュイナードファミリーは持株を手放し、パタゴニアの年間利益（約1億ドル）のすべてが環境活動に充てられるようになりました。 これを「経営判断」と「デザイン思考」は別の話だと考えるかもしれません。しかしパタゴニアでは、製品の設計から修理サービス、価格設定、マーケティングまで、すべての意思決定が「使命」から逆算されます。この統一性こそが、パタゴニアのデザインアプローチの核心です。 一般的なデザイン思考は「ユーザー（顧客）への共感」を起点に置きます。パタゴニアは共感の対象を一段ずらしています。共感の第一の対象は「地球」であり、顧客は地球を守ろうとする仲間として位置づけられています。 --- Worn Wearプログラム：「買わない」を可能にするサービス設計 修理サービスの規模 パタゴニアのWorn Wear（ウォーン・ウェア）プログラムは、同社製品の修理・補修を提供するサービス体系です。アメリカ国内のサービスセンターには70名以上の専任縫製職人が在籍し、年間数万点の修理を行っています。 このプログラムが注目すべきなのは、修理サービスを「コストセンター（費用がかかる部門）」ではなく、ブランドの哲学を体現するタッチポイントとして設計している点です。 一般的な消費財メーカーにとって、修理サービスは矛盾した存在です。製品が修理されることで新品の販売が失われる。製品寿命が延びることは売上の機会損失になる——という前提で考えると、修理サービスは縮小すべき事業です。 パタゴニアはこの前提をひっくり返しました。「修理された製品を大切に使い続けることで、新たな廃棄物が生まれない」という価値こそが、顧客に提供すべき体験だという設計思想です。 Worn Wearツアーとモービル修理ユニット 2015年、パタゴニアは改造したバイオディーゼルトラックに修理機材を積み込み、アメリカ各地のキャンパスを巡る「Worn Wearツアー」を実施しました。各地で修理ワークショップを開き、参加者自身が自分の服を直せるよう技術を教えました。 このプログラムのプロセスをデザイン思考のフレームワークで分解すると、興味深い構造が見えます。 共感フェーズ：パタゴニアは「ユーザーが製品について何を不満に思っているか」よりも、「ユーザーが製品を使い続けるためには何が必要か」という問いを立てています。これは顧客の表面的なニーズ（新しいデザインへの欲求）ではなく、潜在的な価値観（モノを大切にしたい）に応えようとする設計です。 問題定義フェーズ：問題は「顧客の満足度を上げるにはどうすべきか」ではなく、「消費文化そのものをどう変えるか」として定義されています。HMW（How Might We）で表現するとすれば、「どうすれば、顧客が製品を捨てる代わりに修理するという選択を、魅力的に感じてもらえるか」です。 プロトタイプフェーズ：ツアーは全国展開の前の実験でした。どの地域に関心が高いか、修理ワークショップへの参加率はどう変わるか、という仮説検証が動いていました。 --- 製品設計における「長寿命化」の哲学 素材と縫製の選択基準 パタゴニアの製品開発チームは、新素材の採用を検討するとき、一般的な「性能・コスト・製造容易性」の三軸だけでなく、「修理容易性（Repairability）」と「素材の環境負荷」を評価軸に加えます。 たとえばフリース素材の代表製品「レトロX」シリーズは、1990年代の発売以来、デザインを大きく変えていません。消費者に「最新モデルへの買い替え欲求」を喚起するのではなく、定番品を長く使い続けることを選択肢として維持し続けることが戦略として機能しています。 修理容易性の観点からは、接着剤でパーツを固定する工法（モジュールごとの交換が困難）より、縫製でパーツを結合する工法を優先するという設計判断が積み重なっています。 Ironclad Guaranteeと「壊れたら戻せる」設計 パタゴニアは製品に「アイアンクラッド保証（Ironclad Guarantee）」を付けています。これは期限なしの品質保証で、製品が通常の使用に耐えられない場合、無条件で修理・交換・返金するというものです。 この保証は、製品設計の水準を常に「保証を履行できるレベル」に維持する仕組みとして機能しています。修理コストを最小化するためには、製品品質を高めるしかない。高品質化が修理サービスのコストを下げ、修理サービスの存在が製品の長寿命化を保証する——この循環がビジネスモデルの中核にあります。 --- 「逆サービス」の論理：なぜ機能するのか 消費者の価値観との共鳴 「この上着を買わないで」広告のパラドックスは、発信した2011年のパタゴニアの売上が実際に増加したことで決着しています。この広告はメディアで大きく取り上げられ、結果的にブランドの認知と信頼を高めました。 しかしこれを「逆張りマーケティングが当たった」と解釈するのは表面的です。本質は、特定の価値観を持つ消費者層（環境問題に関心が高い、消費主義に懐疑的な）との間に深い共鳴を生んだことにあります。 デザイン思考の文脈では、これは「ペルソナの価値観レイヤーを深く理解した共感の成果」として読めます。表層のニーズ（新しいアウトドアウェアが欲しい）だけでなく、価値観レベル（自分の消費が地球に与える影響を気にしている）に応答したとき、ブランドと顧客の関係は取引から共鳴へと変わります。 競合他社が「真似できない」理由 パタゴニアの修理サービスやWorn Wearを競合ブランドが模倣しない（できない）理由は、技術的な困難にあるのではありません。サービスの背景にある「使命」を持っていないため、コスト構造として成立しないからです。 使命が先にあり、事業がその使命を実現する手段として設計されているからこそ、「修理することで新品販売を失う」というトレードオフを受け入れられます。使命が後付けのブランドには、このトレードオフを受け入れる合理性がありません。 これはデザイン思考における問題定義の深さが、解決策の独自性を決定するという原則の好例です。「どう売るか」ではなく「何のために存在するか」を問い直すことで、誰も思いつかない（あるいは真似できない）解決策が生まれます。 --- デザイン思考実践者への示唆 パタゴニアのケースが提示する問いは三つあります。 問い1：共感の対象は誰か？ ユーザー（顧客）への共感は必要条件ですが、十分条件ではありません。ユーザーの背後にある「社会」や「環境」への共感が、差別化された問題定義を生む場合があります。 問い2：問題定義の単位はどこか？ 製品レベル（この上着をどう改善するか）ではなく、システムレベル（消費と廃棄のサイクルをどう変えるか）で問題を定義したとき、解決策の形が根本的に変わります。 問い3：ビジネスモデルはデザインか？ 修理サービス、保証制度、価格設定——これらもデザインの対象です。製品の造形だけでなく、ユーザーとブランドの関係全体をデザインすることがサービスデザインの問いであり、パタゴニアはその最も明快な実例のひとつです。 --- 参考文献 - Yvon Chouinard, Let My People Go Surfing: The Education of a Reluctant Businessman, Penguin Books, 2005（改訂版2016） - Vincent Stanley & Yvon Chouinard, The Responsible Company: What We've Learned From Patagonia's First 40 Years, Patagonia Books, 2012 - Patagonia, "Don't Buy This Jacket", The New York Times 広告, 2011年11月25日 - Worn Wear プログラム公式ページ, wornwear.patagonia.com - Rebecca Solnit, "Patagonia's Anti-Growth Strategy", The New Yorker, 2022年9月 --- ### プロトタイプフェーズ——素早く作り、素早く学ぶ URL: https://designthinking.studio/articles/prototype-phase/ > デザイン思考の第4フェーズ「プロトタイプ（Prototype）」を解説。低忠実度プロトタイプの作り方、プロトタイピングの原則と実践のコツ。 プロトタイプ（Prototype）は、創造フェーズで生まれたアイデアを素早く形にして、ユーザーとの対話を可能にするフェーズです。 プロトタイピングの目的 プロトタイプの目的は、完成品を作ることではなく、アイデアについて学ぶことです。d.school では「If a picture is worth a thousand words, a prototype is worth a thousand pictures（絵が千の言葉に値するなら、プロトタイプは千の絵に値する）」と教えています。 プロトタイピングの原則 - 素早く、安く作る — 完璧を目指さず、検証に必要な最小限の作りに留める - 「作りながら考える」 — 手を動かすことで新たなアイデアや課題が見える - 捨てる勇気を持つ — プロトタイプへの愛着は判断を曇らせる - 複数のプロトタイプを作る — 1つに絞らず、複数の方向性を同時に検証する プロトタイプの種類 低忠実度プロトタイプ（Lo-Fi） - 紙のプロトタイプ — 手描きのスケッチやワイヤーフレーム - ストーリーボード — ユーザー体験の流れをコマ割りで描く - ロールプレイ — サービス体験を演技で再現する - レゴ・段ボール — 物理的な製品のモックアップ 高忠実度プロトタイプ（Hi-Fi） - デジタルプロトタイプ — Figma、InVision等でインタラクティブなモック - ワーキングプロトタイプ — 限定的な機能を持つ実動するもの 初期段階では低忠実度プロトタイプが推奨されます。見た目が完成品に近いほど、ユーザーは本質的なフィードバック（「この方向性は正しいか？」）よりも表面的なフィードバック（「色が気に入らない」）を返しがちになります。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、「まだ作れる段階ではない」という言葉でプロトタイピングを先送りにするパターンです。アイデアが固まっていない、リサーチが足りない、設計が決まっていない——どれも一見もっともな理由ですが、実際は「形にすることへの恐怖」が正体です。 実際にやってみると分かるのですが、15分で作った紙のプロトタイプでも、ユーザーの前に出した瞬間に想定外の反応が必ず出ます。 その反応こそが学びです。完璧を待って2週間かけた後に出した答えよりも、15分で作って試した答えの方が、最終的に良いプロダクトを生む——これは繰り返し確認してきた事実です。 なお、AI時代のプロトタイピングについてはAI時代のデザイン思考ツールで詳しく解説しています。Figma AIやv0のようなツールを使えば、プロトタイプ制作の速度を大幅に上げることができます。 まとめ プロトタイピングは、アイデアを具体化し、テスト可能にするための手段です。速さと学びを優先し、完璧さを追求しないことが成功の鍵です。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - Tom Brown, Change by Design, HarperBusiness, 2009（第5章：プロトタイピング） - Jakob Nielsen, "Paper Prototyping: Getting User Data Before You Code", nngroup.com, 2003 --- ### プロトタイプ思考とは何か｜「作ることで考える」を組織文化に変える実践アプローチ URL: https://designthinking.studio/articles/design-thinking-prototype-mindset/ > プロトタイプ思考（Prototype Mindset）の本質と、それを個人スキルではなく組織文化として定着させる実践アプローチを解説。IDEO・Pixar・Googleの事例をもとに、「作ってから考える」習慣が意思決定の質をどう変えるかを示す。 「プロトタイプを作りましょう」と提案すると、多くの組織で最初に出る反応はこうです。「まず方向性を固めてから作らないと、無駄になります」。 この反応が、プロトタイプ思考とウォーターフォール型思考の分岐点です。「方向性を固めてから作る」という前提そのものが、プロトタイプ思考では逆転しているからです。プロトタイプ思考では、作ることで方向性が見えてくる——これが基本原則です。 --- プロトタイプ思考（Prototype Mindset）とは Tim Brown（IDEO CEO・当時）は著書『Change by Design』（HarperBusiness, 2009）で、プロトタイプを「アイデアを試すための道具」ではなく「思考を形にするための行為」として定義しています。この区別は重要です。 アイデアを試す道具としてのプロトタイプは、「ある程度アイデアが固まった後に作るもの」になります。思考を形にする行為としてのプロトタイプは、「何も固まっていない時に作ることで、初めてアイデアが見えてくるもの」です。 d.school（Stanford d.school）は、プロトタイプ思考を5段階で説明しています（d.school Design Thinking Bootleg, 2018）。 - Build to think（考えるために作る）: 頭の中だけにあるアイデアを外に出す - Build to ask（問うために作る）: 具体物があって初めて出てくる問いを引き出す - Build to test（試すために作る）: 仮説を実際のユーザー反応で検証する - Build to share（共有するために作る）: 言語よりも早く、正確に、チームで理解を揃える - Build to inspire（インスパイアするために作る）: ステークホルダーや意思決定者が「これだ」と感じられる体験を生む プロトタイプ思考とは、この5段階のすべてを「作ること」で実現しようとする姿勢です。 --- なぜ組織はプロトタイプを後回しにするか プロトタイプを早期に作ることへの抵抗は、3つの心理から生まれています。 完成品への混同：プロトタイプを「未完成な製品」として捉えると、「完成していないものを見せることは恥ずかしい」という感覚が生まれます。しかしペーパープロトタイピング完全ガイドでも触れているように、低忠実度のプロトタイプほど本音のフィードバックを引き出しやすい。完成度の低さは欠点ではなく、意図的な設計です。 失敗への懸念：「プロトタイプを作って否定されたら、その時間が無駄になる」という思考です。しかしプロトタイプ思考において「否定される」ことは学習の証拠です。組織学習の研究では、失敗を「学習コスト」として捉えるチームが、失敗を「回避すべき損失」と捉えるチームより早くイテレーションを回せることが繰り返し示されています。 早すぎる収束：「まず合意を作ってから」という組織文化では、プロトタイプ以前に意思決定が完了してしまいます。作ることが「承認された方向性の可視化」になると、プロトタイプは思考の道具ではなく「プレゼン資料」に変質します。 --- Pixarの「早いドラフト」文化 Pixarのアニメーション制作プロセスは、プロトタイプ思考の組織的実装として参照されることが多い事例です。 Pixar共同創業者Ed Catmullは著書『Creativity, Inc.』（Random House, 2014）の中で、「Ugly Babies（醜い赤ちゃん）」という概念を紹介しています。すべての映画は最初、粗削りで問題だらけのストーリーとして存在する。それを「醜い赤ちゃん」として愛護し、批判から守りながら育てる文化がPixarの強さだ、と述べています。 具体的には、毎週行われる「Dailies（デイリーズ）」というセッションで、制作中のシーンを未完成のまま全員に公開します。批評の場ではなく、「これはどこに向かっているか」を共有する場として機能しています。完成を待たずに見せることで、方向性のズレを早期に察知できます。 Pixarのこの文化は、意図的に設計されたものです。「未完成を見せる安全性」が保証されていなければ、人は完成するまで隠します。プロトタイプ思考を組織に定着させるためには、「早い段階で見せること」の安全性をリーダーが率先して作る必要があります。 --- プロトタイプ思考を組織に根付かせる3つのメカニズム 個人スキルとしてのプロトタイプ思考は比較的習得しやすい。問題は、それを組織の意思決定の習慣に変えることです。 メカニズム1: 「プロトタイプ共有」を意思決定の前段に置く 会議での意思決定の前に、「何らかの形でプロトタイプを作ってから持ち寄る」というルールを設けます。Googleの設計スプリント（Jake Knapp, 2016）は、5日間という時間制約の中で「金曜日にユーザーテスト」を設定することで、「木曜日にはプロトタイプが必要」という逆算を強制します。締め切りがプロトタイプを生むのです。 メカニズム2: フィードバックの語彙を変える プロトタイプへのフィードバックに使う言語を変えることで、評価の文化を変えます。「これは良い」「これはダメ」という判定型フィードバックではなく、「どの前提が機能していて、どの前提が機能していないか」を問う形式に変換します。 d.schoolが使う「I like / I wish / What if」フレームワークは、肯定・改善要望・可能性の問いの三段構えで、批判を「次のプロトタイプのための仕様書」に変換する効果があります。 メカニズム3: 「プロトタイプしたことの可視化」を評価に組み込む 多くの組織で、プロトタイプは「作ってテストして終わり」です。何を試して、何を学び、どう方向を変えたかの記録が残りません。イテレーション履歴を可視化することで、「試行錯誤の量と質」が評価の対象になります。最終成果だけでなく、探索の過程を評価する文化が、プロトタイプ思考の長期的な定着につながります。 --- 「決める前に作る」を判断の癖にする プロトタイプ思考の本質は、「不確実な状況での意思決定方法」の変革です。情報が不完全なまま議論しても、言語による抽象的な合意しか生まれません。プロトタイプを作ることで、「議論していたつもりのもの」が実際には存在していなかったことが、初めて可視化されます。 「作ることで考える」という習慣は、一人のデザイナーのスキルとしてではなく、意思決定の単位としてのチームの文化として機能したとき、組織のイノベーション速度を変えます。 デザイン思考チームの多様性設計と組み合わせると、多様な視点を持ったチームが「早いプロトタイプ」を通じて意見の相違を言語ではなく具体物で解消できるようになります。これが、デザイン思考が「ワークショップのやり方」ではなく「組織の問題解決の様式」として機能する姿です。 --- ### ペーパープロトタイピングとは？材料費ほぼゼロ・2時間で本音が引き出せる作り方 URL: https://designthinking.studio/articles/paper-prototyping-guide/ > ペーパープロトタイピングとは、紙とペンでUIを描きユーザーに操作させる低忠実度プロトタイプ手法。材料費ほぼゼロで、シナリオ定義からユーザーテストまで2〜2.5時間。d.school発の原則と現場の失敗・学びを、材料リストと手順つきで解説する。 「プロトタイプを作ろう」と言われると、多くのチームはすぐにFigmaを開くか、パワーポイントで画面モックを作り始める。しかしワークショップの現場では、紙と鉛筆だけで作ったプロトタイプが、デジタルツールで丁寧に仕上げたものより多くの洞察をもたらす場面がくり返し起きている。 ペーパープロトタイピングとは、紙・付箋・ホワイトボード・マーカーなど手近な材料でインターフェースや体験の流れを描き、実際にユーザーに操作させる手法だ。1980年代からヒューマン・コンピュータ・インタラクション（HCI）研究の文脈で体系化されており、Carolyn Snyder の著書『Paper Prototyping』（Morgan Kaufmann, 2003）が実務普及の基盤を作った。 なぜ紙なのか。完成度が低いほどユーザーは遠慮なく「ここが分からない」と言ってくれる。デジタルで丁寧に仕上げると「壊してはいけない」「こんなに作ったのに否定するのは悪い」という空気が生まれ、本音を封じてしまう。「雑に作る」ことが心理的安全性の装置として機能するのが、ペーパープロトタイピングの本質だ。 --- なぜデジタルツールより紙が先なのか ワークショップでよく起こるのは、ツールの習熟差がチームのアウトプットを歪めるパターンだ。Figmaを使いこなせるメンバーが「自分が作った方が早い」とキーボードを占有し、チームの議論が止まる。紙であれば、Figmaを触ったことがない参加者でも即座に描ける。 d.school の授業でも、プロトタイプフェーズの最初のワークは必ずスケッチと紙で始まる。その理由をファカルティは「思考のスピードと手のスピードを合わせるため」と説明する。デジタルツールはどうしても「きれいに見せよう」という意識が働き、アイデアを磨くより先にビジュアルを整え始めるという認知の罠に陥りやすい。 実際にやってみると、紙のプロトタイプを前にしたユーザーは驚くほど率直だ。「この矢印、どこに戻るの？」「この画面ってここを押したら次に進む？」という素朴な疑問が、後のデジタルプロトタイプ設計の骨格を変える。10分で作ったものに30分かけたものと同等のフィードバックが得られる、という現場の実感がペーパープロトタイピングを継続させる理由だ。 --- 用意する材料 ペーパープロトタイピングの良さのひとつは、材料のコストがほぼゼロな点にある。以下が標準セットだ。 基本セット（1チーム分） - A4白紙またはノート用紙（20〜30枚） - 付箋（75mm×75mm、白または黄色） - 細書きマーカー（Sharpie 極細またはゼブラ油性ペン細字） - 鉛筆・消しゴム（初期スケッチ用） - はさみ・セロハンテープ - 定規（オプション） 細書きマーカーを推奨する理由は、鉛筆や細いボールペンで描いた線は離れて見たときに「グレーの塊」に見えてしまい、ユーザーテスト時に視認性が落ちるからだ。マーカーで太めに描いた線は、ユーザーがプロトタイプを持った状態でも要素を識別しやすい。 スマートフォンやタブレットアプリのプロトタイプなら、実機と同じ縦横比に切った紙を「デバイスの画面サイズ」として使うと臨場感が増す。Webサービスなら、A4横置きでブラウザのウィンドウを模すのが定石だ。 --- 作り方：ステップバイステップ ステップ1：シナリオを1文で定義する（5分） 最初に「誰が・何をしようとしている場面」を1文で書く。例として「初めてサービスを使う30代女性が、友人の誕生日プレゼントを購入しようとしている」のように具体化する。シナリオの解像度が低いままプロトタイプを作り始めると、画面の遷移が「作り手の都合」で設計されてしまう。 シナリオを書いたら、チームで30秒だけ共有して認識を合わせる。この30秒を省くと、同じチームの中で「ユーザーの行動ゴール」が人によってバラバラのままプロトタイプ制作に突入する。 ステップ2：タスクフローをポストイットで並べる（10分） ユーザーが取る行動を付箋1枚1アクションで書き出し、横に並べる。購入フローなら「トップ→商品検索→商品詳細→カート→支払い情報入力→確認→完了」のような流れだ。 この段階はまだ「画面」ではなく「行動の流れ」を整理する目的で行う。付箋なので順番の入れ替えや追加・削除が即座にできる。ここで全員が同じフローを見て合意しておかないと、後の画面制作でチームが別々のユーザージャーニーを描いてしまう。 ステップ3：各画面を描く（20〜30分） タスクフローの各ステップを1枚の紙に「画面」として描く。ルールは以下のみ。 - ボックスとテキストで要素を配置する（アイコンは簡略記号でOK） - 完璧に描こうとしない（ユーザーには「ここはこういうボタン」と口頭補足してよい） - インタラクティブな要素（ドロップダウン・モーダル・エラー表示）は別紙に描いておく 最後の「別紙」が重要だ。ユーザーテスト時に、ユーザーがボタンを押したらそのオーバーレイを上に重ねることで、動的な遷移を手作業でシミュレートできる。この役割を「コンピューター役」と呼ぶ。 実際にやってみると、描き始めて5分で「この画面、ここに戻るボタンがない」という設計の抜け漏れが見えてくる。描く行為そのものが、ユーザーの動線を検証する思考プロセスになっている。 ステップ4：コンピューター役のトレーニング（5分） ペーパープロトタイピングのユーザーテストでは、チームの1人が「コンピューター役」を担う。ユーザーが画面上の要素を指差すか触れた瞬間、コンピューター役が次の画面・オーバーレイを差し出す役割だ。 コンピューター役は声を出してはいけない。「そこは別の画面に飛びます」「エラーです」などの説明を口頭でしてしまうと、画面設計の問題点が隠蔽される。無言で次の紙を出す——それだけを徹底するのが、フィードバックの質を担保する。 テスト前に5分、チームでコンピューター役をロールプレイしておくと、本番でパニックにならずに済む。 --- ファシリテーション時の注意点 「これは試作品です」と最初に伝える ユーザーテストを始める前に必ず「完成品ではなく試作品」と明示する。これを言わないと、ユーザーは「出来が悪い」と感じても批判を遠慮してしまう。 「今日見ていただくのは手書きの試作品です。描いていない部分や、分かりにくい表現があれば、どんどん指摘してください。プロダクトではなく、私たちの設計を評価していただく場です」——この一言でユーザーの発言のハードルが大きく下がる。 観察者は記録に徹する ファシリテーター以外のチームメンバーは観察者として後ろに座り、発言せずに記録だけとる。「製作者がそこにいると、否定的なコメントが言いにくくなる」——これはテスト後にユーザーから繰り返し出てくる言葉だ。 観察の記録フォーマットは簡単なもので十分だ。「時間｜ユーザーの行動｜発言・反応｜気づき」の4列をノートかスプレッドシートに記録する。後でチームが振り返るときに「あの瞬間の反応」を具体的に参照できるかどうかが、改善策の解像度を左右する。 ユーザーへの誘導を避ける ユーザーが迷ったとき、すぐにヒントを出したくなる気持ちは自然だが、それは学習の機会を潰している。迷っている時間そのものが、「ここが分かりにくい」という最高のデータだ。 テスト中に答えを教えていいのは、ユーザーが完全にフラストレーションを感じてセッション自体が崩壊しそうなときだけだ。「できた・できない」より「どこでなぜ迷ったか」を観察することが目的であると、チーム全員が事前に合意しておく。 --- 所要時間の目安 | フェーズ | 所要時間 | 備考 | |---|---|---| | シナリオ定義 | 5分 | チーム全員で | | タスクフロー整理 | 10分 | 付箋ワーク | | 画面制作 | 20〜30分 | 2〜3人で分担可 | | テスト準備（コンピューター役練習含む） | 10分 | — | | ユーザーテスト（1人15〜20分）× 3名 | 45〜60分 | 2〜3名で十分 | | 振り返り・インサイト抽出 | 20〜30分 | Howメモ壁貼り | | 合計 | 約2〜2.5時間 | ハーフデイで完結 | 2〜2.5時間でプロトタイプ制作からユーザーテストまで完結できる。これがペーパープロトタイピングの最大の強みのひとつだ。 デジタルプロトタイプで同じプロセスを回すと、最低でも丸一日、場合によっては数日かかる。 --- よくある失敗と対策 失敗1：完璧に描こうとして時間を使いすぎる 「もう少し綺麗に描いてからテストしたい」——これが最も多い先延ばしの口実だ。完成度を上げることに時間をかければかけるほど、「捨てにくくなる」という心理が働く。プロトタイプへの愛着は、ユーザーフィードバックを素直に受け取る能力を下げる。 タイマーを20分に設定して画面制作を強制終了させる。描けていない部分はコンピューター役が口頭補足で対応する、と事前に合意しておく。 失敗2：コンピューター役が喋りすぎる 最初のテストでコンピューター役を担当したメンバーが「そこを押したらこういう画面に行きます」と説明を始めると、ファシリテーターが止めるまで続く。この「説明」がユーザーの自然な反応を上書きしてしまう。 コンピューター役の人に「絶対にしゃべってはいけないという制約の中で、どうユーザーの行動に応答するかを考える」という具体的な役割定義を伝えることで、この問題の多くは防げる。 失敗3：テスト後に振り返りをしない ユーザーテストが終わった瞬間、チームが「よし終わった」と席を立ち、インサイトを整理しないまま解散するパターンがある。これはペーパープロトタイピングで最もよく起きる、かつ最も痛い失敗だ。 観察者が取ったメモを即座に付箋に書き出し、壁に貼る。5分以内にその場でグルーピングを始める。ユーザーテスト直後の30分は、記憶が鮮明で文脈が共有されている最高の分析タイムであることを、ファシリテーターは参加者に伝える必要がある。 --- デジタルプロトタイプとの使い分け ペーパープロトタイピングが最も力を発揮するのは、コンセプトレベルの検証とナビゲーション構造の確認だ。「そもそもこのフローが正しいか」「ユーザーが自然に目的に辿り着けるか」を問うフェーズに向いている。 一方、インタラクションの細部（アニメーション、マイクロコピーの言葉選び、ローディング体験）はデジタルプロトタイプの領域だ。Figma の Interactive Components やFramer を使ったハイファイプロトタイプは、紙では再現できない動的な体験の検証に適している。 実務的な使い分けとして有効なのは「紙で構造を確認してからデジタルに移る」というシーケンシャルなアプローチだ。紙でナビゲーションとコンテンツ配置を合意してからFigmaで画面を作ると、大幅な手戻りが減る。設計の上流で1時間紙に使うことで、実装工程の数日を節約できる——このROIの感覚が、経験あるUXデザイナーがペーパープロトタイピングを手放さない理由だ。 --- やってみよう：今日できるミニ実践 以下は1時間で完結する入門ワークショップの設計だ。チームや勉強会の場でそのまま使える。 テーマ：「コンビニのATM操作フロー改善」 - 3〜4人のチームを作る - シナリオを定義する（例：「初めてATMを使う20代の外国人旅行者が、現金を引き出そうとしている」） - 付箋でタスクフローを5〜7ステップで整理する（10分） - 各ステップの画面を紙に描く（20分） - 1人をコンピューター役、1人をユーザー役にしてチーム内でテストする（10分） - 気づきを付箋で3枚書いて共有する（10分） ATMというすでに全員が知っているUIを題材にすることで、「何が問題か」「どう改善できるか」という議論が初対面のチームでも即座に生まれる。 ペーパープロトタイピングの入門として完結性が高い。 --- prototype-phase.mdx との違いについて プロトタイプフェーズ概説がデザイン思考全体におけるプロトタイピングの目的・原則・考え方を解説しているのに対し、本記事は「ペーパープロトタイピング」という特定の手法にフォーカスし、材料・ステップ・所要時間・ファシリテーションの具体技法を網羅している。ワークショップで今日すぐ使えるレベルの実行情報を目的としているという点で、両記事の役割は明確に異なる。 --- まとめ：「雑に作る」ことが最良の設計戦略 ペーパープロトタイピングは、技術でも才能でもなく「雑に作る覚悟」がすべてだ。完成度への執着を手放した瞬間、ユーザーの率直な反応が流れ込んでくる。 d.school の授業でくり返し語られるのが「fail early, fail often（早く失敗し、何度でも失敗せよ）」という言葉だ。ペーパープロトタイピングはその哲学を最もシンプルに実装した手法だ。紙と鉛筆があれば、今日から始められる——それが他のどの手法にもない、最大の利点だ。 --- --- 参考文献 - Carolyn Snyder, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, Morgan Kaufmann, 2003 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - Jakob Nielsen, "Paper Prototyping: Getting User Data Before You Code", nngroup.com, 2003 --- 関連記事 - プロトタイプフェーズ——素早く作り、素早く学ぶ - デザイン思考のユーザーテスト手法完全ガイド - ダブルダイヤモンドモデルの実践 - テストフェーズ——ユーザーの反応から学ぶ --- ### ヘルスケアテクノロジーのデザイン思考実装 — 患者中心の医療イノベーション URL: https://designthinking.studio/articles/design-thinking-healthcare-tech/ > 電子カルテ、患者向けアプリ、AI診断支援ツール。ヘルスケアテクノロジーの開発にデザイン思考を実装した企業事例と、医療規制の制約下でプロトタイピングを回すための具体的な設計手法を解説する。 ヘルスケアテクノロジーの開発現場では、奇妙なパラドックスが繰り返される。医師向けの電子カルテシステムに何億円もかけて開発した機能が、現場でほとんど使われない。患者向けの服薬管理アプリが「使いやすい」という高評価を得ながら、1週間でアンインストールされる。技術は動いている。しかし体験は失敗している。 この逆説の根本にあるのは、技術の問題ではなく設計プロセスの問題だ。 ヘルスケアテクノロジーの多くは、ユーザー（医療者と患者）の現実から切り離されたところで設計され、臨床現場に「導入」という名の押しつけとして届く。デザイン思考は、この逆転した順序を正すための方法論として機能する。 --- ヘルスケアテクノロジーが「失敗しやすい」構造的理由 ヘルスケアテクノロジーが他の産業のデジタル製品より設計が難しい理由は、ユーザーが複数層に分かれているという構造にある。 医師・看護師・医療事務スタッフ（一次ユーザー）と、患者・家族（最終ユーザー）は、同じシステムを全く異なる目的と文脈で使う。電子カルテのインターフェースは医師の業務効率を最大化するように設計されがちだが、そのデータの受取手である患者には、理解可能な形で情報が届いていないことが多い。 さらに、意思決定者（病院管理者・IT調達担当）がシステムを購入し、実際の使用者（臨床スタッフ）が日常的に操作し、結果を受け取る者（患者）が体験する——この3者の分離が、設計フェーズでのユーザーリサーチを構造的に困難にする。 ヘルスケアイノベーションの実践に関わる設計者たちが繰り返し指摘するのは、この問いだ。患者の声を聞かなかったことが問題なのではない。患者の声を聞いたが、意思決定者に届かなかった——この構造こそが、最も多い設計の失敗パターンだ。 --- 事例1：Epic Systems の患者ポータル再設計 米国の医療ITベンダー Epic Systems は、電子カルテ（EHR）市場シェアで米国最大手だ。同社の患者向けポータル「MyChart」は2020年時点で1億人以上の患者が利用しているが、実際の利用率は依然として低い——登録はしているが使っていないユーザーが多数存在する。 この課題に対し、Epic は2018年から Stanford Medicine と共同で患者体験研究プロジェクトを実施した。デザイン思考の共感フェーズに相当するリサーチとして、患者の「退院後の最初の48時間」を詳細にシャドーイング観察する手法を採用した。 観察から明らかになったのは、患者が退院後に直面する最大の不安が「次に何をすべきか分からない」という情報の断絶だった。医師は退院前に説明をしているつもりでも、患者側では「薬の名前は聞いたが飲む量が分からない」「フォローアップ外来の予約の取り方が分からない」という状態が常態化していた。 この洞察から定義された HMW（How Might We）は「どうすれば退院直後の患者が、次のアクションを自分でコントロールできる感覚を持てるだろうか？」だった。 プロトタイピングの段階では、医療情報の正確性を維持しながら低忠実度のプロトタイプを作るという制約が課題になった。電子カルテの実データを使ったプロトタイプは患者データの取り扱い規制（HIPAA）に抵触するため、現実に近い架空のシナリオをシミュレーションした「紙のモックアップ」が使われた。医師・看護師・患者を交えた10回のテストセッションで得られたフィードバックが、最終的な機能設計に反映された。 --- 事例2：NHS Digital の予約システム刷新 英国国民保健サービス（NHS）のデジタル部門 NHS Digital は、2017年から「NHS App」の設計にデザイン思考を組み込み、2019年の正式ローンチに至った。このプロジェクトが注目を集めた理由は、公共医療機関がデジタルプロダクト開発にアジャイル開発とデザイン思考を正式に統合した初期事例の一つだったからだ。 プロジェクトの共感フェーズでは、従来の患者調査（アンケート）に加えて、「文化的人類学的観察」手法が採用された。GP（一般開業医）の待合室に観察者を4週間配置し、予約を取る・変更する・キャンセルする行動のパターンを記録した。 観察から得られた最大の洞察は、予約行動が「医療的なニーズ」よりも「電話が繋がる時間帯」と「恥ずかしさ（特に精神科・性感染症関連の予約）」によって強く規定されているという発見だった。これは従来の患者調査では浮かび上がっていなかった要因だ。 この洞察が、アプリの最重要機能として「非同期テキストによる予約申請」と「予約カテゴリの非表示オプション」が設計された直接の根拠になった。NHS Appの正式ローンチ後、予約機能の利用は急速に拡大し、特に非同期申請への移行が患者の行動変容を促した。 --- 事例3：メドトロニックの在宅医療デバイス開発 医療機器メーカーのメドトロニック（Medtronic）は、糖尿病管理デバイスの開発にデザイン思考を採用した事例で知られる。特に注目されるのは、持続血糖モニタリング（CGM）システムの患者体験改善プロジェクト（2015〜2018年）だ。 従来のCGMデバイスは、血糖値を連続的に測定し、数値をリアルタイムで表示する機能を持っていた。しかし臨床現場からは「数値が表示されるのに、患者が何をすべきか分からないまま不安になる」というフィードバックが続いていた。 デザイン思考の共感フェーズにおいて、メドトロニックのチームは患者の「感情の地図」を描くことから始めた。 血糖値が特定の値を示したとき、患者がどのような感情状態にあるかを、5人の患者との詳細なインタビューと日記記録から再構成した。 この作業から見えてきたのは、「血糖値が高い」という情報より「このまま寝ても大丈夫なのか」という文脈での安心感・不安感が患者の行動を決定しているということだった。数値ではなく「状態の意味」を伝えるインターフェースへの設計変更は、この洞察から生まれている。 --- 医療規制の制約下でのプロトタイピング ヘルスケアテクノロジーのプロトタイピングには、他の産業と異なる制約がある。患者データ保護・医療機器規制・臨床試験要件の3つが、高忠実度プロトタイプの作成と実際の患者テストを制限する。 この制約を乗り越えるために、いくつかの設計パターンが実践されている。 シナリオベース・テスト。 実患者データの代わりに、実際の患者ケースを参照して作成した「架空の患者プロフィール」を使ったテストシナリオを設計する。医療者が「もし自分がこの患者を担当していたら」という文脈で操作するシミュレーション形式で、機能の評価を得る。 段階的プロトタイプ。 第一段階（紙のモックアップ）→ 第二段階（クリッカブルプロトタイプ）→ 第三段階（限定的なパイロット環境での実装）という3段階の忠実度グラデーションを設定し、各段階でのテストを規制要件に照らして判断する。Stanford d.school が医療機関と連携して整理したこの段階設計の考え方は、医療テクノロジー開発の現場で実践的なガイドとして参照されることが多い。 コンシェルジュ・プロトタイプ。 技術実装の前段階として、人間が手作業で行うサービスシミュレーションを行う。例えば「スマート服薬リマインダーアプリ」のプロトタイプとして、看護師が患者に電話で服薬を確認する運用を2週間実施し、患者からのフィードバックを得る。実際にやってみると、この手法は規制の外で患者の本音を引き出す最も効率的な方法だということが分かる。 --- 日本のヘルスケアテクノロジーとデザイン思考 日本の医療現場にデザイン思考が導入される場合、固有の課題がある。 意思決定の層の厚さ。 病院のデジタルシステム導入は、医師・医療安全委員会・病院管理者・ITベンダーの承認プロセスを経る。プロトタイプを「まず試して失敗する」というサイクルを回しにくい構造だ。この壁を乗り越えているケースの共通点は、プロジェクトのスポンサーが臨床部門の現場リーダーであることだ。 患者の「言わない文化」。 インタビューで「不便ではありませんか？」と聞かれた日本の患者は、実際に不便であっても「大丈夫です」と答える傾向がある。共感フェーズでの観察手法（インタビューより観察）を優先し、言語化されない不便さを行動から読み取る工夫が必要になる。 規制の解釈の保守性。 薬機法・個人情報保護法の適用範囲について、実際の禁止事項より広い範囲を「してはいけないこと」として解釈する組織文化が、プロトタイプの実施を不必要に制限することがある。法務・コンプライアンス部門をデザイン思考プロセスの初期段階から巻き込み、「何が実際に不可能か」を共に明確にする作業が、日本のヘルスケアテクノロジー開発では特に重要だ。 --- 実装のための5つのスタートポイント ヘルスケアテクノロジー開発にデザイン思考を導入する際の、最初の一歩として機能する5つのアクションを示す。 - 患者の「最悪の瞬間」をリスト化する。 診察の待ち時間・請求書の受取・薬の受け取り——患者が最も不安・混乱・ストレスを感じる具体的な場面を、実際の患者5人に30分ずつ話を聞いてリスト化する。これがすべての起点だ - 医師・患者・管理者の「1日」を並べて可視化する。 カスタマージャーニーマップを3者分作成して並べると、同じシステムが全く異なる体験を生んでいる接点が見える - 「紙でできるか？」を最初の問いにする。 どんな機能もまず紙とペンで試せるかを問う。試せないなら、なぜ試せないかを明確にする（多くの場合、試せる） - 失敗が発生した過去の開発プロジェクトを1件、徹底的に解剖する。 「なぜ使われなかったか」を共感フェーズの手法で調査する。原因が技術でなく設計であることが多い - 次のバージョン開発の最初のミーティングに患者を1人招く。 要件定義の場に、実際のユーザーが1人いるだけで会話の質が変わる 現場でよく聞くのは、この5番目のアクションに対して「何を話せばいいか分からない」という戸惑いだ。構造化されたインタビューガイドは不要で、「最近、医療に関して困ったことを教えてください」という一つの問いから、プロジェクトの方向性を変えるインサイトが生まれることは珍しくない。 ヘルスケアテクノロジーの失敗の多くは、優れた技術を間違った問いに適用した結果だ。デザイン思考は、技術を応用する前に「正しい問い」を見つけるための方法論であり、規制と制約の中でも有効なプロセスとして機能する。 --- 参考文献・出典 - Tim Brown, Change by Design: How Design Thinking Creates New Alternatives for Business and Society, HarperBusiness, 2009（日本語訳：千葉敏生訳『デザイン思考が世界を変える』ハヤカワ文庫、2014年） - NHS Digital, NHS App Statistics, NHS England（公式ダッシュボード） - IDEO, Design Thinking for Educators, 2nd Edition, 2012（無償公開ツールキット） 関連記事: ヘルスケア領域のデザイン思考 — 患者体験を再設計する / デザイン思考の共感フェーズ / プロトタイプフェーズの実践 --- ### ヘルスケア領域のデザイン思考 — 患者体験を再設計する URL: https://designthinking.studio/articles/design-thinking-healthcare/ > 病院の待合室、処方箋の説明、リハビリプログラム。ヘルスケア領域でデザイン思考がどのように患者体験を変革しているか、具体的な事例と実践手法を解説する。 病院の待合室で2時間待ち、ようやく呼ばれた診察室で医師に話しかけてもらえるのはわずか7分。処方箋の説明は専門用語だらけで、家に帰ったときには何をどう飲めばいいのか分からなくなっている。退院の際に渡された書類の束は、翌朝には読む気力もなくなっている。 ヘルスケアは技術的には世界最先端でありながら、体験としては著しく遅れている領域のひとつだ。 この構造的な問題に、デザイン思考が切り込んでいる。200回以上のワークショップで繰り返し観察されるのは、医療現場のスタッフ自身が「患者の体験」を可視化したとたん、「なぜこうなっているのか」という問いが止まらなくなるパターンだ。技術の問題ではなく、 設計の問題である ことが明らかになる瞬間がある。 なぜヘルスケアにデザイン思考が必要なのか 「治す」と「体験」は別問題 医療の本来の目的は疾患を治療することだ。しかし、患者の満足度や治療アドヒアランス（処方どおりに薬を飲み続けること）、再発防止への意識は、治療の技術的水準だけでは決まらない。 「どのように診てもらったか」という体験の質が、治療の成果に直結する ことが複数の研究で示されている。 Harvard Business Reviewの2017年の報告によれば、患者体験が優れた病院では入院患者の合併症発生率が低く、スタッフの離職率も低い傾向がある。患者体験は「感情的なやさしさ」ではなく、医療アウトカムに影響する実務上の変数なのだ。 システムが患者を中心に設計されていない ほとんどの病院の動線、書式、情報提供のタイミングは、医療提供者側の業務効率を中心に設計されてきた。 患者が「次に何が起きるか」を把握できる構造になっていない。 何時間待つのか、どの検査が何のためにあるのか、退院後に何を気をつければいいのか——これらの情報は患者にとって切実だが、標準的な病院フローの中では後回しにされやすい。 デザイン思考の共感フェーズが強力なのは、こうした「見えていた」問題を、実際に患者の立場から経験することで「本当に見える」ものに変えるからだ。患者役の医師が診察室の外で2時間待つという体験ひとつで、問題の優先順位が変わることがある。 世界の先行事例 Mayo Clinic — 診察室の設計を根本から問い直す アメリカ・ミネソタ州にあるMayo Clinicは、2000年代初頭にデザインコンサルティングファームIDEOと協働し、デザイン思考によるヘルスケア改革の先駆けとなった。2007年にはCenter for Innovation（CFI）を設立し、フルタイムのデザインリサーチャーを含む専門チームが院内の体験を継続的に改善する体制を整えた。 その代表的な成果が 「Jack and Jill Room」 だ。従来の診察室は医療機器が大半のスペースを占め、身体診察を中心に設計されていた。しかし実際のデータを見ると、身体診察にかかる時間は診察時間全体の10〜15%に過ぎない。残りの85〜90%は会話だ。 この事実から出発し、診察室の両サイドに会話のためのスペースを設けた新しいレイアウトを設計した。患者・家族・医師が同じモニターを見ながら対話できる構造になり、 より多くの患者を受け入れながら、患者満足度を高める ことに成功した。「器具を置く場所」から「会話が生まれる場所」へ——設計の前提そのものを変えたプロジェクトだ。 Kaiser Permanente — 看護師の申し送りを患者中心に再設計する 全米最大規模のヘルスケア組織のひとつ、Kaiser Permanenteでもデザイン思考が大きな成果を上げている。問題の発端は、シフト交代時の看護師同士の申し送り（ハンドオフ）だった。 申し送りに45分以上かかり、看護師ごとにメモの取り方が異なるため重要情報が抜け落ちることがあった。ナースステーションで行われるこの引き継ぎの間、患者は放置される。 医療ミスの温床になりやすい構造的な問題 だった。 デザイン思考のアプローチで現場を観察・インタビューした結果、生まれた解決策は「患者のベッドサイドで引き継ぎを行う」という発想の転換だった。同時に、情報を統一フォーマットで共有するソフトウェアが開発された。患者本人も申し送りの場にいることで、情報の正確さを患者自身が確認できるようになった。 この変革の結果、Kaiser Permanenteは 約1年間で医療ミスによるコストを96万ドル削減 することに成功した。「患者を診察の対象」から「引き継ぎプロセスの参加者」へと再定義したことが、根本的な改善を生んだ。 IDEO × Nemours Children's Hospital — 子どもの病院体験を全面再設計する IDEOはフロリダ州オーランドのNemours Children's Hospitalの設計にも深く関わった。4億ドル規模のこのプロジェクトでは、子どもと家族を中心に据えた病院体験の全面的な再設計が行われた。 具体的なアウトプットは革新的だった。 子どもが病室の照明の色を自分でコントロールできる ようになり、入院中の自律感を高めた。フロアグリーターと呼ばれるコンシェルジュが来院した家族を出迎え、不安を軽減する。家族ラウンジにはキッチンが設置され、家族が食事を共にできる環境を提供した。 設計プロセスではFull-scale prototypeが活用された。ウェルカムステーション、待合ラウンジ、診察室の実物大模型を発泡スチロールで製作し、実際の医療スタッフと家族が使ってフィードバックを得る。 図面ではなく、身体で体験してから設計を確定する というプロセスが、数多くの問題を事前に発見した。 日本の事例 — PwC Japanのヘルスケアデザイン研究 国内でもデザイン思考のヘルスケアへの応用が進んでいる。PwC Japanのヘルスケアデザイン研究では、超高齢社会における患者体験の再設計が焦点となっている。単なる診療効率の改善ではなく、 高齢者が「療養」から「生活」を継続している実感を持てるような体験設計 が模索されている。 退院後の在宅療養期間の体験、リハビリへの内発的な動機づけ、家族との連携のあり方——これらは医療技術の問題ではなく、人間中心の設計の問題だ。 デザイン思考のヘルスケアへの適用手順 Phase 1：患者ジャーニーの可視化 まず患者が「病気を自覚する前」から「完全に日常生活に戻る後」までの全体的な体験をジャーニーマップで可視化する。医療機関が通常フォーカスする「院内の動線」だけでなく、自覚症状が出た時点での不安、受診を決断するまでの葛藤、退院後の孤独感まで含めることが重要だ。 医療スタッフが「患者ジャーニー全体」を初めて目にするとき、 一様に驚きの反応が起きる 。「入院が始まった」と病院が認識するタイミングより、患者の体験は数週間前に始まっている。 Phase 2：「ペインポイント」と「不安の峠」を特定する ジャーニーマップ上で、患者の感情が最も落ち込む「不安の峠」を特定する。典型的な峠は以下の3点に集中する。 - 診断告知の瞬間 — 情報量が多く、感情的な混乱の中で意思決定を迫られる - 退院直前 — 「一人でできるか」という不安が最高潮に達する - 退院後1〜2週目 — サポートが突然なくなり、孤独感が増す Phase 3：HMW問いで解決の方向を探る 特定した峠に対して、How Might Weの問いを立てる。「どうすれば退院直前の患者が、一人でも対処できる自信を持てるだろうか」「どうすれば診断告知後の患者が、重要な情報を落ち着いて整理できるだろうか」——こうした問いが、チームの創造的なアイデア発散を導く。 Phase 4：低忠実度プロトタイプで素早く検証する ヘルスケア領域でのプロトタイプは、過度に完成度を上げる必要はない。Kaiser Permanenteのケースでも、最初は紙のフォームと会話の変更から始まった。 「やってみてから改善する」サイクルを短く回す ことが、現場の協力を得るうえでも重要だ。 退院後の患者サポートであれば、まずは電話1本から始める。待合室体験であれば、掲示板の文言を変えるところから試みる。小さな介入からフィードバックを得て、より大きな設計変更へとつなげていく。 ヘルスケア特有の難しさ 利害関係者の複雑さ 病院はステークホルダーが極めて多い。患者、家族、看護師、医師、病院管理者、保険会社、医療機器メーカー——それぞれの利益と優先順位が異なる。 全員を共感の対象にする 広い視野がなければ、ある問題を解決しながら別の問題を生み出すことになる。 規制と安全性の壁 医療においては、創造的なアイデアを試みる際にも厳格な安全基準と規制への適合が求められる。 プロトタイプの範囲を「非臨床的なサービス体験」に絞る ことが現実的な出発点だ。待合室の動線、情報提供の方法、退院後のフォローアップの設計は、医療行為を伴わない部分であり、比較的迅速に改善できる。 感情的な重さ 病気・死・苦痛に向き合う医療現場では、共感フェーズの調査が感情的に過酷になることがある。ワークショップ参加者が患者や家族の経験に深く共感するあまり、感情的に疲弊することも珍しくない。 適切なデブリーフィングの時間をセッション後に設ける ことが、継続的な取り組みを支える。 日本のヘルスケアで特に有効な領域 説明の設計 日本の医療現場では、インフォームド・コンセントの形式化が進む一方、患者が「本当に理解した」かどうかの確認が薄いことが多い。診断説明の場での情報の渡し方、書類のデザイン、患者が持ち帰る資料の構成——これらは高度な医学的判断を必要とせず、 デザイン思考で即座に改善できる領域 だ。 待機体験の設計 高齢者が多い日本の病院では、長時間待機が日常的だ。「待つ」という行為そのものをゼロにすることは難しいが、 「待っている間に何が分かり、何を準備できるか」という体験は設計できる 。待ち時間の見通しを示す、待機中に活用できる情報を提供する、といった介入が患者満足度を大きく変える。 在宅療養・リハビリの継続 退院後の在宅療養期間に医療的なサポートが薄くなりがちなのは、日本でも大きな課題だ。リハビリを自宅でも続けてもらうための動機設計、家族への情報提供の方法、地域コミュニティとの接続——これらは医療技術ではなく、 人間の行動設計の問題 として取り組める。 まとめ——「治す」ことを「体験」として設計する Mayo Clinic、Kaiser Permanente、Nemours Children's Hospitalの事例が示すのは、一貫したひとつのことだ。 医療の質と患者体験の質は、トレードオフではない。 人を中心に置いた設計は、同時に医療アウトカムを改善し、ミスを減らし、スタッフの働き方も良くする。 デザイン思考をヘルスケアに適用するとき、最初の問いは「何を改善するか」ではない。「誰の、どの瞬間の体験から始めるか」だ。待合室で2時間待っている患者の顔を実際に観察することから、すべての改善は始まる。 デザイン思考の全体像を理解したうえで、まずは自組織の患者ジャーニーマップを一枚描いてみることをすすめる。その作業だけで、見えていなかった問題が浮かび上がることが多い。 --- 参考文献 - Harvard Business Review, "Health Care Providers Can Use Design Thinking to Improve Patient Experiences", hbr.org, 2017 - IDEO, "A Hospital Centered on the Patient Experience" (Nemours Children's Hospital case study), ideo.com - Design x Healthcare News, "デザイン思考と医療 — Kaiser Permanente（米国）の事例", designxhealthcare.com, 2019 - Design x Healthcare News, "デザイン思考と医療2 — Mayo Clinic（米国）", designxhealthcare.com, 2019 - PwC Japan, "100歳時代のヘルスケアデザイン", pwc.com/jp, 2023 電子カルテや患者向けアプリなど ヘルスケアテクノロジーの開発プロセスに焦点を当てた実装事例は、ヘルスケアテクノロジーのデザイン思考実装 — 患者中心の医療イノベーションで詳しく解説している。規制対応下でのプロトタイピング手法を含めて参照してほしい。 --- ### ユーザビリティテスト計画の立て方：5ステップ完全ガイド URL: https://designthinking.studio/articles/usability-testing-planning-guide/ > ユーザビリティテストで最も省略されるのは「計画フェーズ」だ。目標設定・参加者設計・タスク設計・環境準備・スケジュール設計の5ステップを体系化し、計画なきテストが生む失敗パターンと対策を解説する。 「テストは来週やろう」——この言葉がチームから出た瞬間、計画は既に崩壊しかけている。 ユーザビリティテストを取り巻く議論の多くは「どの手法を使うか」に集中する。モデレーテッドかリモートか、シンクアラウドか行動観察か。テストフェーズの全体像や5つの検証手法を学んだとき、多くの実践者が感じる充実感はそこから来る。 しかしテストが失敗する理由の大半は、手法ではなく計画の欠如にある。参加者を急いで集めたせいで対象ユーザーがズレていた。タスクの指示が曖昧で、参加者ごとに全く違う操作をした。録画環境を確認していなかったため、最重要セッションの映像が残らなかった。これらは手法の問題ではなく、計画段階で防げた失敗だ。 本記事は、ユーザビリティテストの「計画フェーズ」に特化した実践ガイドだ。①目標設定、②参加者設計、③タスク設計、④環境・ツール準備、⑤スケジュール設計という5ステップで、計画の全体像を体系化する。 --- なぜ計画フェーズは省略されるのか 組織でユーザビリティテストの計画が省略される理由には、構造的なパターンがある。 第一の理由は「テストを準備作業だと捉えていない」ことだ。 プロトタイプが完成すれば「後は見せるだけ」という認識が生まれやすい。しかしテストそのものの品質は、事前の計画精度によってほぼ決まる。参加者選定の基準、タスクシナリオの設計、記録方法の決定——これらは「準備」ではなく「設計の一部」だ。 第二の理由は「スケジュールの後ろ詰め」だ。 プロジェクトの締め切りが固定されている場合、テストに充てられる時間は常に最後の余りになる。1週間の予定が3日に圧縮され、3日の計画が「明日の午後やろう」になる。この構造は、テストに先行するプロトタイプフェーズが長引くことによってさらに悪化する。 第三の理由は「計画の仕方が分からない」ことだ。 ワークショップやトレーニングでテストの実施方法は教わっても、テスト計画の立て方を体系的に学ぶ機会は少ない。結果として、場当たり的な進め方になる。 --- ステップ1：目標設定 — 何を知るためのテストか テスト計画の出発点は、「このテストで答えたい問いを1〜3個に絞ること」だ。これは議論なしに実行できることではない。チーム内で「何が不確かで、何を知れば次に進めるか」を言語化するプロセスが必要だ。 テスト目標の書き方 目標は「〜を確認する」ではなく「〜が分かる」という形で書くと、後からテスト結果との照合がしやすくなる。 悪い例：「UIの使い勝手を確認する」 良い例：「新規ユーザーが登録フローを完了できるか、どのステップで離脱するかが分かる」 目標が曖昧だと、タスク設計もデータ分析も曖昧になる。 目標を1〜3個に絞る作業は、チームが「何を諦めるか」を明示的に決める作業でもある。4つ目の目標候補が出てきたときに「これは今回のスコープ外」と言えるかどうかが、計画の規律を決める。 仮説をセットで書く 目標と並行して、検証する仮説を明文化しておく。「初めてのユーザーは、ダッシュボードのナビゲーションが分かりにくいと感じている可能性がある」のような形で書くと、テスト後に「仮説は支持されたか」という問いで分析を整理できる。 --- ステップ2：参加者設計 — 誰にテストしてもらうか 参加者の選定は、テストの品質を決定する最重要変数だ。 間違った参加者に正しいタスクを与えても、有効なインサイトは得られない。 参加者基準（スクリーニング条件）を作る まず「テストに参加すべき人」の条件を文章で書き出す。行動特性（頻度・経験・デバイス）、属性（年齢・職業・デジタルリテラシー）、除外条件（競合製品の従業員、開発チームの知人）を含める。 この条件文書がスクリーニングアンケートの設計に直接使える。リクルーティングを外部会社や社内のUXチームに依頼する場合、この文書なしに動いてもらうと「条件に合わない人が来た」という事態が発生する。 何人集めるか Jakobニールセンが1993年に示したモデルでは、同一ユーザーグループにおいて、ユーザービリティ問題の約85%は5名のテストで発見できる（Nielsen, J. & Landauer, T.K., 1993）。この数字はユーザビリティテスト（問題発見）の文脈でのモデルであり、探索的インタビューや多様なユーザーセグメントを含む場合には当てはまらない。 実際の参加者数の決め方は、ユーザーセグメントの数に依存する。対象ユーザーが「初心者」と「経験者」に分かれるなら、各グループに5〜6名——合計10〜12名が出発点の目安になる。定性調査のサンプルサイズに関する詳細な議論は別記事で扱っているが、重要な原則は「何人いればいいか」ではなく「どのセグメントをカバーできているか」で判断することだ。 サンプリング偏差のリスク 最も頻繁に起きる失敗は、参加者の母集団がズレることだ。 社内のアーリーアダプター層や、リクルーティング会社の登録モニター常連者ばかりが集まると、実際のユーザー行動から乖離したデータになる。 特に注意が必要なのは「テストに慣れた参加者」の混入だ。ユーザビリティテストの経験が豊富な人は、タスクの「意図」を読もうとする傾向があり、一般ユーザーよりも探索的に動く。スクリーニングで「過去12ヶ月以内にユーザーテストに参加したことがあるか」を確認するのは有効な対策だ。 --- ステップ3：タスク設計 — 何を操作してもらうか タスクシナリオはユーザビリティテストの核心だ。タスクの設計が悪ければ、どれだけ適切な参加者を集めても、得られるデータは現実から離れる。 タスクシナリオの書き方 タスクシナリオは「シチュエーション（状況） + ゴール（達成すべきこと）」で構成する。 悪い例：「このアプリの予約機能を使ってください」 良い例：「今日の夜、友人2名と食事に行く約束があります。明日の夜19時に3名で入れるレストランを、このアプリで予約してください」 良い例が優れている理由は、現実のユースケースに近いからだ。ユーザーが実際の目的意識を持って操作することで、自然なナビゲーション行動が観察できる。「予約機能を使ってください」という直接指示は、UIラベルをそのまま読み上げているようなものであり、ユーザーが通常の状況でどこから探し始めるかが分からない。 タスクの数と順序 1セッション（45〜60分）に詰め込めるタスクは3〜5個が上限だ。1つのタスクに15〜20分を配分し、バッファを含めて設計する。 タスク間の移行時間、参加者が行き詰まった際の対応時間、セッション後のデブリーフィング時間を見落とすと、必ず最後のタスクが駆け足になる。 タスクの順序は「発見したい情報の優先順位」に基づいて決める。参加者が疲れる後半にもっとも重要なタスクを置くのは避ける。また、タスク間に学習効果が生まれないよう注意する——前のタスクで画面の構造を学んだことが、次のタスクのパフォーマンスに影響するようなら、順序を入れ替えるか、タスク間でUIをリセットする手順を挟む。 パイロットテスト（予行演習）の実施 本番セッションの前日までに、チームメンバーの1人を参加者役にして1セッション分を通しで実施する。パイロットテストで確認するのは、タスクシナリオの言葉が曖昧でないか、セッション時間が予定内に収まるか、録画・記録の設定が機能するか、の3点だ。 実際にやってみると、「自分たちには明確に見えていた指示が、参加者役にとっては全く別の意味に聞こえた」という発見が必ず出てくる。省いたセッションほど、本番で同じ穴に落ちる。パイロットテストはタスク設計の質を上げる最も確実な手段だ。 --- ステップ4：環境・ツール準備 — どこで、何を使うか 実施環境の選択 ユーザビリティテストの実施環境は大きく3つに分かれる。 対面（ラボ）形式は、参加者の行動を直接観察でき、表情や手の動きといった非言語情報も収集できる。設備として、参加者用端末、スクリーン録画ツール、観察用の別室（ワンウェイミラー）があると理想的だが、会議室でも実施可能だ。 リモートモデレーテッド形式は、ZoomやMicrosoft Teamsなどのビデオ会議ツールで参加者の画面共有を受けながら進行する。地理的制約がなくリクルーティングの幅が広がるが、通信環境や技術的なトラブルへの対処計画が必要だ。 リモートアンモデレーテッド形式は、UserTesting.comやLookback.ioなどのプラットフォームで参加者が一人でタスクをこなし、録画を後から分析する。量を確保しやすいが、想定外の行動に対してその場でフォローアップできない。 記録方法の決定と事前確認 セッションの記録方法を決定し、本番前日に必ず動作確認する。 記録しておくべきなのは、画面の操作（スクリーンキャプチャ）、参加者の発話（音声）、表情と手の動き（カメラ映像、対面の場合）、オブザーバーのリアルタイムメモだ。 録画ツールの設定ミスや保存先の問題は、現場でのトラブルの中で最もダメージが大きい。「最重要なセッションが録画されていなかった」という事態は、チェックリストで防げる。 チームの役割分担 テストセッションに関わるチームの役割を事前に明確にする。モデレーター（進行）、ノーテイカー（記録担当）、オブザーバー（観察）の3役は、別々の人間が担当するのが理想だ。 モデレーターがリアルタイムで記録を取ろうとすると、参加者への注意が分散する。ノーテイカーは参加者の言葉・行動・特記事項を時系列で記録し、オブザーバーは「何を感じたか」という解釈レベルの観察を別紙に書く。この3層の記録が、分析フェーズでデータの密度を上げる。 --- ステップ5：スケジュール設計 — いつ、どう進めるか テスト全体のタイムライン テスト計画から結果の共有まで、最低限のタイムラインは以下が目安になる。 | フェーズ | 期間の目安 | |----------|-----------| | 計画・設計（ステップ1〜4） | 1〜2週間 | | 参加者リクルーティング | 1〜2週間（並行可） | | パイロットテスト | 本番セッション前日までに1セッション | | 本番セッション実施 | 2〜3日（5〜8セッション） | | データ分析・パターン抽出 | 2〜3日 | | 結果の共有・レポート | 1日 | リクルーティングは計画フェーズと並行して走らせる。 「計画が完成してからリクルーティングを開始する」という順番で動くと、トータルのリードタイムが2週間以上伸びる。スクリーニング条件の大枠が決まった段階でリクルーティングを開始し、詳細な条件は後から精緻化する。 セッション間のバッファ 1日にセッションを詰め込みすぎることは避ける。セッションとセッションの間に15〜20分のバッファを設ける。 このバッファは、前のセッションのメモを整理する時間、機材のリセット時間、そして次の参加者への引き継ぎ準備のために使う。 実際にやってみると、1日4〜5セッションがモデレーターの集中力の限界に近い。6セッション以降では、質問の鋭さやフォローアップの精度が落ちる傾向がある。セッション数が多くなる場合は、複数日に分散させるか、モデレーターを交代させる計画を組む。 分析セッションのスケジューリング テストセッションの終了直後（翌日以内）にチーム全員で分析セッションを開くことを、計画段階からスケジューリングしておく。観察者の記憶が鮮明なうちにパターンを抽出する「ダウンロードセッション」は、データ分析の品質を大きく左右する。 「録画があるから後でやろう」という発想は、分析の先延ばしと映像を見直す時間の二重コストを生む。セッション当日か翌日に30〜60分の分析時間を確保することを、計画の一部として組み込む。 --- 計画チェックリスト テストを開始する前に、以下の項目が揃っているかを確認する。 目標設定 - [ ] テストで答える問いが1〜3個に絞られている - [ ] 検証する仮説が文章で書かれている 参加者設計 - [ ] スクリーニング条件が文書化されている - [ ] 参加者数がユーザーセグメントに基づいて決定されている - [ ] 除外条件（テスト経験者・業界関係者）が明記されている タスク設計 - [ ] 全タスクが「シチュエーション + ゴール」形式で書かれている - [ ] タスク数と時間配分が計算されている - [ ] パイロットテストが実施済み、またはスケジューリング済み 環境・ツール準備 - [ ] 録画・記録の設定が動作確認済み - [ ] チームの役割（モデレーター・ノーテイカー・オブザーバー）が決定済み - [ ] 参加者への同意書・謝礼の手配が完了している スケジュール - [ ] リクルーティングが計画フェーズと並行して開始されている - [ ] 分析セッションの日時がカレンダーに確保されている --- テスト計画と問題定義の接続 テストは独立したアクティビティではなく、問題定義の仮説を検証するプロセスだ。 テスト目標の設定が難しいと感じるチームの多くは、POVステートメントが曖昧なまま手法の選定に進んでいる。 「POV文（Point of View文）」で「どんなユーザーが、どんな状況で、何に困っているか」を明確にしていれば、「そのインサイトが本当に正しいか」をテストで検証する問いが自然に出てくる。逆に問題定義が曖昧なテスト計画は、「全てを確認しようとして何も確認できない」状態に陥りやすい。 テスト計画に入る前に、チームのPOV文を開いてみると、目標設定のズレに気づくことが多い。計画の精度は、その上流にある問題定義の精度に比例する。 --- 参考文献 - Nielsen, J. & Landauer, T. K. (1993). A mathematical model of the finding of usability problems. Proceedings of the ACM INTERCHI'93 Conference, 206–213. https://dl.acm.org/doi/10.1145/169059.169166 - Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Nielsen Norman Group. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ - Dumas, J. S. & Redish, J. C. (1999). A Practical Guide to Usability Testing. Intellect Books. - Rubin, J. & Chisnell, D. (2008). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests (2nd ed.). Wiley. - Nielsen Norman Group. (2021). User Testing: Why & How. NN/g Research Report. https://www.nngroup.com/articles/usability-testing-101/ --- ### ライフデザイン（Life Design）とは何か——デザイン思考を「自分のキャリア・人生」に転用する URL: https://designthinking.studio/articles/design-thinking-life-design-career/ > ライフデザイン（Life Design）とは、スタンフォードd.school発の、デザイン思考の5フェーズを自分自身のキャリア・人生設計に転用する実践法である。正解探しをやめ、複数の可能性を試すオデッセイプランとプロトタイプ会話の具体的な手順を解説する。 デザイン思考を仕事で使いこなしている人ほど、自分自身のキャリアの岐路では急に別人になる。プロダクト開発では曖昧さを平気で扱えるのに、転職や働き方の選択になると、途端に「正解を1つ選ばなければ」という焦りに取り憑かれる。 ライフデザイン（Life Design）とは、デザイン思考の5フェーズ——共感・定義・創造・プロトタイプ・テスト——を、組織やプロダクトではなく自分自身のキャリアと人生の意思決定に転用する実践法だ。 なぜ、仕事では使えている型を、自分自身には使えていないのか。その構造的な理由から、実際に使える手順まで見ていく。 --- なぜ「正解探し」は人生の意思決定に向かないのか 製品開発と人生の意思決定、扱い方の非対称 新規事業の企画会議で「この案が唯一の正解です」と言い切る人はいない。むしろ複数の仮説を並べ、小さく試し、失敗した仮説を捨てながら収束させていくのが、デザイン思考実践者にとっての当たり前の作法だ。 ところが同じ人物が自分のキャリアを考えるとき、途端にこの作法を手放す。「今の会社に残るべきか、転職すべきか」「独立すべきか」——これらの問いに、あたかも1つの唯一解が存在するかのように向き合い、答えが出ないことに焦る。 この非対称性は意志の弱さの問題ではない。人生の選択には「間違えたら取り返しがつかない」という感覚が強く働き、発散的に試すという発想そのものが浮かびにくくなる構造がある。 アブダクション的思考の欠落 デザイン思考の意思決定は、演繹（既知の前提から必然的結論を導く）でも帰納（多数の観察から一般法則を導く）でもなく、アブダクション（仮説形成推論）——限られた手がかりから「最も説明力の高い仮説」を暫定的に選び、行動しながら検証していく思考様式に支えられている。 キャリアの意思決定でこの思考様式が使われないのは単純だ。「今の仕事を辞めたら生活はどうなるか」という不確実性を前にすると、人は暫定的な仮説で動くことより、動かないまま考え続けることを選びがちになる。仮説を立てて小さく検証するという型そのものを、人生の文脈に持ち込む発想がないのだ。 こうした「限られた手がかりから仮説を立てて動く」思考の型そのものは、アブダクション（仮説形成推論）を扱った記事で詳しく展開している。ここで押さえておきたいのは、その型が製品開発だけでなく個人の意思決定にもそのまま転用できるという点だ。 Life Designという実践知の起源 この転用を体系化したのが、スタンフォード大学d.schoolのビル・バーネットとデイブ・エヴァンスによる『Designing Your Life』（邦訳『LIFE DESIGN』）だ。d.school自体が生んだ実践知が、d.school発の方法論そのものを個人に折り返した、という点で理論的にも筋が通っている。 --- Life Designの5つの基本原則と5フェーズへのマッピング 5つの基本原則（マインドセット） Life Designは、好奇心（Curiosity）・行動主義（Bias to Action）・視点の転換（Reframing）・プロセスを信じること（Awareness）・他者との協働（Radical Collaboration）という5つの基本姿勢を土台に置く（Burnett & Evans, 2016）。どれも目新しい概念ではない。デザイン思考の実践者であれば、プロジェクトの現場でとうに身につけている姿勢のはずだ。特にRadical Collaborationは、キャリア設計を一人で抱え込まず、他者を巻き込みながら進める姿勢として、他の4つと並ぶ重要な柱になっている。 問題は、これらの姿勢を「仕事のときだけ」発動させ、「自分の人生を考えるとき」には切り離してしまっていることにある。Life Designがしていることは、新しい思考法の発明ではなく、すでに持っている型のスイッチを、自分自身にも向け直すことだ。 5フェーズへの重ね合わせ この5原則は、既存記事群で解説してきたデザイン思考の5フェーズにそのまま重ねられる。 | フェーズ | 製品開発での意味 | 人生への転用 | |---|---|---| | Empathize（共感） | ユーザーの現状・文脈を理解する | 自分の現状（健康・仕事・遊び・愛という4分野の充実度）を棚卸しする | | Define（定義） | 解くべき問いを定義する | 今の自分にとっての「良い人生」を定義し直す | | Ideate（創造） | 複数の解決案を発散させる | 複数のキャリアシナリオを並行して発想する（後述のオデッセイプラン） | | Prototype（プロトタイプ） | 小さく形にして試す | 大きな決断の前に、小さく試す行動を取る（後述のプロトタイプ会話） | | Test（テスト） | 検証し、学びを次に活かす | 試した結果を振り返り、次の選択に反映する | 共感フェーズの転用先である「自分の現状の棚卸し」は、創造フェーズの一般解説やプロトタイプフェーズの一般解説で扱っているフェーズそのものの定義や進め方とは重ならない。ここで扱うのは、あくまで「そのフェーズの型を、自分自身に向けたときに何が起きるか」という転用の構造だ。 この重ね合わせは比喩ではない。実際に、同じ手順でそのまま回せる（余談だが、実践者ほどこの転用に気づいていないという逆説の方が、むしろ興味深い）。次の節では、特に転用しやすい2つの具体的なテクニックを見ていく。 --- 実践テクニック——オデッセイプランとプロトタイプ会話 オデッセイプラン: 3つの並行シナリオを描く 「オデッセイプラン」は、Ideateフェーズを個人の意思決定に転用する具体的な手法だ。やり方はシンプルで、今後5年間について、以下の3つの並行シナリオを紙に描き出す。 - 今の路線を続けたら——今の仕事・生活を延長した場合の5年後 - 今の仕事がなくなったら——今の選択肢が失われた場合に、代わりに何をするか - お金と評判を気にしなくていいなら——制約を取り払ったときに本当は何をしたいか 3つとも「正解」ではない。むしろ「これも自分にとってあり得る人生だ」と思える案を、複数同時に持つことに意味がある。1つの正解を探す発想では、この3案を並べて書くという発想自体が出てこない。これはIdeateフェーズの「発散してから収束する」という型を、そのまま自分の人生に適用した状態だ。 プロトタイプ会話・プロトタイプ体験: 決断の前に小さく試す もう一つの中核テクニックが「プロトタイプ会話」と「プロトタイプ体験」だ。転職や独立といった大きな決断を、いきなり本番で試す必要はない。 - プロトタイプ会話: 興味のある道に既にいる人に、その働き方・生活の実態を直接聞きに行く - プロトタイプ体験: 週末だけ・1ヶ月だけといった期間を区切って、実際にその領域を試してみる これは、製品開発でユーザーインタビューやモックアップ検証を行うのと同じ構造だ。対人インタビューを通じて相手の文脈を理解する技法そのものは、ステークホルダーインタビューの記事で扱っている型と地続きであり、聞き方の技術は改めてここで説明しない。ここで強調したいのは、その技法の対象を「顧客」から「自分がなりたいかもしれない将来の自分」に切り替えるだけで、キャリアの意思決定にそのまま使えるという点だ。 大きな決断ほど、プロトタイプせずにいきなり本番に飛び込みがちになる。しかし「試してから決める」という順序を守れば、決断の質は変わる。 --- よくある誤用と落とし穴 「好きなことをすれば幸せになれる」という単純化 Life Designが広まる過程で、しばしば「好きなことを仕事にすれば人生はうまくいく」という単純化に矮小化されることがある。これはLife Designの原型が持つ複線的な構造(5原則・5フェーズ・複数シナリオの並行検討)を、1つの標語に圧縮してしまった誤読だ。 好奇心にもとづいて選択肢を広げることと、「好き」という一つの基準だけで即断することは別物だ。Life Designが実際にやっているのは、複数の仮説を並べて小さく検証する手続きであって、「好きなものを見つければ終わり」という一発勝負の話ではない。 個人の意思決定にも構造的な難問がある キャリアの選択には、家族の事情・経済状況・社会的な制約が複雑に絡み合う。これは、単純な手順化では解けない厄介な問題（wicked problem）としての性質を持つ。オデッセイプランやプロトタイプ会話は、この厄介さを一撃で消し去る魔法ではなく、不確実性を抱えたまま前に進むための足場だ。この構造については厄介な問題（Wicked Problems）を扱った記事で詳しく展開している。 「何のために自分は雇われているか」を問い直す もう一つ有効な視点が、Jobs-to-be-Done（JTBD）の発想を自分自身に向け直すことだ。「顧客は何のためにこの製品を雇っているのか」という問いを、「今の自分は、何のためにこの仕事に自分自身を雇っているのか」と読み替えると、給与や肩書きの奥にある本当の動機が見えてくる。この視点の詳細はJTBDとデザイン思考の記事に譲る。 --- まとめ——正解探しをやめ、3行から始める デザイン思考は、組織やプロダクトのための特殊な方法論ではない。不確実性の中で意思決定するための汎用の型であり、その型は自分自身のキャリアや人生にもそのまま使える。 違うのは対象だけだ。共感の対象が「ユーザー」から「自分の現状」に、プロトタイプの対象が「製品」から「自分の選択肢」に変わる。それだけで、「正解を1つ選ばなければ」という焦りは、「複数の仮説を試しながら学習する」という、見慣れた型に置き換えられる。 次にキャリアの迷いが生じたら、正解を1つ選ぼうとする前に、まず3行だけ書いてみるといい。今の路線を続けたら。今の仕事がなくなったら。お金と評判を気にしなくていいなら。その3行が、次の一歩をどこから始めるかを教えてくれる。 --- 参考文献・出典 - Burnett, B., & Evans, D. (2016). Designing Your Life: How to Build a Well-Lived, Joyful Life. Alfred A. Knopf. - ビル・バーネット、デイヴ・エヴァンス（著）、千葉敏生（訳）（2017）『LIFE DESIGN（ライフデザイン）——スタンフォード式 最高の人生設計』早川書房. --- 関連記事 - アブダクション（仮説形成推論）とデザイン思考 - 創造（Ideate）フェーズとは - プロトタイプフェーズとは - ステークホルダーインタビューの実践 - 厄介な問題（Wicked Problems）とデザイン思考 - JTBD（Jobs-to-be-Done）とデザイン思考 --- ### リフレクシブ・デザインリサーチとは——調査者の前提がデータを汚染する構造と制御法 URL: https://designthinking.studio/articles/reflexive-design-research/ > デザインリサーチにおける再帰性（reflexivity）の問題を解説。調査者自身の前提・価値観・立場が問いの設計からデータ解釈まで観察を歪めるメカニズムを、Bourdieu、Schönらの理論を軸に整理し、実務での制御手法を示す。 ユーザーインタビューを丁寧に設計し、フィールドワークを重ね、分厚いデータを集めた——にもかかわらず、「最初から決まっていた結論」に収束してしまう経験は、デザインリサーチの現場でくり返し起きている。 問題は手法の選択や実施の精度だけにあるのではない。調査者自身の前提・価値観・立場が、問いの立て方からデータの解釈まで、観察の全過程に静かに介入している。これが リフレクシビティ（reflexivity、再帰性） の問題だ。 リフレクシビティとは、「調査者が調査対象や調査プロセスに与える影響を自覚し、その影響を方法論的に点検すること」を指す。対象を観察するとき、観察者は中立な「透明な窓」ではない。観察者が持ち込む前提・関心・バイアスが、何を見るか・何を聞くか・何を重要とみなすかを構造的に規定している。 --- 学術的系譜——なぜリフレクシビティが方法論の核心になったか リフレクシビティの問題意識は、社会科学の方法論論争から生まれた。 フランスの社会学者 ピエール・ブルデュー（Pierre Bourdieu） は、研究者が「客観的な観察者」として対象の外に立てるという幻想を批判した。ブルデューは、研究者が属する社会的場（フィールド）、教育的・文化的資本、そして「学問的まなざし（scholastic point of view）」そのものが、何を問題として選び・どのように記述するかを規定すると論じた。彼が提唱したのは「participant objectivation（参与的客体化）」——研究者自身がフィールドの中の行為者であることを自覚し、その立場性を分析に組み込む実践だ。 建築家・教育学者の ドナルド・ショーン（Donald Schön） は、1983年の著書 The Reflective Practitioner において、専門的実践者が暗黙の「行為の中の知（knowing-in-action）」によって判断していることを描いた。ショーンの概念である 「行為の中の省察（reflection-in-action）」 と 「行為についての省察（reflection-on-action）」 は、リサーチ実践においても直接適用できる。調査者は、インタビュー中に起きていることをリアルタイムで内省し（in-action）、調査後に自分の解釈プロセスを振り返る（on-action）——この両輪が、リフレクシビティの実践基盤になる。 質的研究の方法論でも、リフレクシビティは不可避の課題として定着している。Kathy Charmaz による Grounded Theory の構成主義的改訂（2006年）は、理論が客観的に「発見」されるのではなく、研究者と参加者の相互作用の中で「構成」されることを明示した。研究者が持ち込む視点を「汚染源」として排除しようとするのではなく、その影響を 明示的に記述することが求められる。 --- デザインリサーチにおける汚染メカニズム デザインリサーチは、学術的な社会科学調査よりも時間・サンプル数・省察の時間が制約されやすい。それゆえに、リフレクシビティの問題が顕在化しやすい。 汚染は3つの段階で連鎖的に発生する。 第1段階：問いの設計 調査者が「何を問うか」を決めた時点で、前提はすでに介入している。 プロダクトマネージャーが「なぜこのUIは使いにくいのか」を調べようとするとき、その問いは「UIが使いにくい」という判断を前提にしている。「このUIに気づかずに作業を完了させている」という可能性は、問いの外に出てしまっている。 インタビューガイドの構造は、調査者が「重要だ」と思う問いで編まれる。調査者の専門的背景・組織における役割・過去のプロジェクト経験が、問いの取捨選択に直接影響する。プロダクト側の人間が設計したインタビューでは、プロダクトに関連する課題が過剰に拾われ、ユーザーの生活文脈や組織的制約など、プロダクトの外にある課題は問われないことが多い。 第2段階：観察・インタビュー実施 調査者は、インタビュー中に何を「重要な発言」として記録するかを瞬時に判断している。この判断は、意識的な評価基準ではなく、体化された前提によって行われる。 ワークショップ 200 回以上の実践で繰り返し観察されるパターンがある。調査者が「このユーザーは典型的なケース」「この発言は例外的」と判断するとき、その判断基準は事前の仮説と強く相関している。観察の場にいること自体も、被観察者の行動を変える。インタビュイーは「期待されている回答」を察知し、調査者が重視しているように見えるテーマに言及を集める。これは 「ホーソン効果（Hawthorne Effect）」 として知られる現象だ。 第3段階：データの解釈と統合 アフィニティダイアグラムやインサイトの抽出段階では、「何と何が同じグループか」という判断が、調査者のカテゴリ認識に依存する。同一の発言群が、調査者の背景によって異なるラベルのクラスタに整理される。 解釈の段階でさらに重要なのは、 「何が語られなかったか」を見落とすリスクだ。ユーザーが言及しなかったことは、記録に残らない。しかし、問われなかったから言及されなかったのか、問われたが言葉にならなかったのか、言語化できているが話しにくかったのかは、観察者には区別できない。問い自体が生まれなかった問題は、データに存在しない。 --- 実務での制御手法 リフレクシビティを「完全に除去する」ことは不可能だ。調査者は常に特定の立場・歴史・前提を持つ存在であり、それを消去することはできない。できるのは、その影響を自覚し、明示し、補正する仕組みを設計に組み込むことだ。 - 事前の仮説棚卸し——「ポジショナリティ・マップ」 インタビュー設計に入る前に、チームで「自分たちが何を前提にしているか」を明示するセッションを設ける。実践的な形式は、以下の3つの問いに対して個人がポストイットに書き出す30分のワークだ。 - 「このユーザーは〜だと思っている」（ユーザーに関する仮説） - 「この製品の問題は〜だと感じている」（問題に関する仮説） - 「このインタビューでは〜が出てくるはずだ」（期待する発見） 書き出したものを壁に貼り、チームで共有する。このプロセスの目的は、仮説を否定することではなく、「どの仮説に沿った観察をしているか」をインタビュー中に意識できるようにすることだ。 問題定義フェーズに入る前にこのワークを行うことで、インサイトの抽出段階での「自分たちの前提」への自覚が格段に高まる。 - ディスコンファーミング・エビデンスの構造化 インタビューガイドに、意図的に「自分たちの仮説が間違っていることを示す発言を引き出す問い」を組み込む。 例えば「このサービスで困っていることは何ですか？」という問いに加えて、「このサービスが特にうまく機能しているシーンはどんな場合ですか？」を必ずセットにする。課題探索と満足探索を構造的にペアにすることで、課題側に偏った観察を防ぐ。 コンテキスチュアル・インクワイアリー（Contextual Inquiry）では、この「反証証拠の収集」がプロトコルに組み込まれている。ユーザーの実際の行動を観察しながら「なぜそのやり方をするのか」を問うことで、インタビュアーの想定と異なる行動論理が浮かび上がりやすくなる。 - 観察者の分離——「ダブルダイアモンドの役割設計」 インタビューを実施したメンバーと、データを解釈するメンバーを意図的に分ける。インタビューに入ったリサーチャーは、現場で形成した印象と暗黙の解釈を持っている。同じチームが観察から解釈まで行うと、現場での印象がインサイトの定義を先取りしてしまう。 完全な分離が難しい場合は、「インタビューに参加していないチームメンバーが、録音・録画・メモだけを素材にして独立してクラスタリングを行う」というステップを挿入する。その後、インタビュアーのクラスタリングと比較することで、「現場で形成された解釈の偏り」が可視化される。 - メモ・フィールドノートにおける自己観察の記録 インタビュー中・直後に書くメモに、 「自分の反応」を記録する欄を設ける。「この発言が気になった、なぜか」「この話題になったとき、会話が深まらなかった、なぜか」「自分はこの発言に同意しながら聞いていた」——こうした調査者自身の反応の記録が、後の分析で「自分の前提がどこで発動したか」を追跡するための素材になる。 質的研究の方法論ではこれを 「省察的メモ（reflexive memo）」 と呼ぶ。Charmazのグラウンデッド・セオリーでも、メモ記述は分析の核心的なプロセスとして位置づけられている。 - チームの多様性設計 同じ職能・同じ組織役割・同じ経験背景を持つメンバーで構成されたチームは、共通の前提を持つため、リフレクシビティの問題が内部で可視化されにくい。 インタビュー・観察チームに、 「このプロジェクトに利害関係のない外部の視点」を持ち込むことが最も効果的な対処の一つだ。顧客サポート担当者、営業担当者、エンジニア——「ユーザーの問題を別の文脈で見ている人」が加わることで、調査チームの前提が相対化される。 --- 「主観の排除」ではなく「主観の開示」へ リフレクシビティへの誤った対応は、「調査者の主観を排除しようとする」ことだ。 完全に中立な観察者は存在しない。デザインリサーチとマーケットリサーチの比較でも論じているが、定性調査の本質は「客観的な真実の発掘」ではなく、「調査者と参加者の相互作用を通じた意味の構成」にある。この前提に立てば、調査者の主観を排除しようとすることは、調査の本質を誤解した対処になる。 正しい方向は 「主観の開示（reflexive transparency）」 だ。「自分たちはどういう前提でこのリサーチを設計したか」「どういう仮説を持って観察したか」「データの解釈にどのような判断基準を使ったか」を、リサーチレポートに明示する。この開示が、読者・意思決定者がデータを使う際の「ノイズ補正情報」になる。 認知バイアスとデザイン思考の関係の記事で指摘したように、人間の認知は前提から自由になれない。リフレクシビティの制御は、バイアスを「克服」しようとする営みではなく、その存在を所与のものとして、影響を最小化・可視化するプロセス設計の問題だ。 --- 実践のための3つの問い ワークショップ現場や日常のリサーチ実務に即した形で、リフレクシビティの点検を習慣化するための問いを3つ提示する。 「この問いは誰が問いたいのか？」 ユーザーインタビューのガイドを作るとき、それぞれの問いが「ユーザーを理解するための問い」か「自分たちの仮説を確認するための問い」かを区別する。後者が多ければ、ガイドは仮説確認装置になっている。 「この解釈は誰に都合がいいのか？」 インサイトを定義する際に、そのインサイトが「自分たちにとって都合のいい解釈」に傾いていないかを問う。インサイトが既存の解決策のロジックを強化するものばかりであれば、確証バイアスとリフレクシビティが重なっている可能性がある。 「語られなかったことに、何があったか？」 インタビューデータを前に、「この話題は出なかった。なぜか」を問う。問いがなかったから・聞いても答えにくかったから・調査者が記録しなかったから——それぞれに異なる対処が必要で、この区別は次のリサーチ設計を改善する素材になる。 --- デザインリサーチの品質は、調査手法の精緻さだけでは担保されない。調査者が「自分が何を持ち込んでいるか」を絶えず問い直す実践が、観察の信頼性の基盤になる。 リフレクシビティは方法論的な欠陥を示すものではない。それを認識し、制御しようとする姿勢こそが、誠実なデザインリサーチの定義だ。 --- 参考文献 - Bourdieu, P. (2003). Participant Objectivation. Journal of the Royal Anthropological Institute, 9(2), 281–294. - Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books. （邦訳: 柳沢昌一・三輪建二監訳『省察的実践とは何か——プロフェッショナルの行為と思考』鳳書房、2007年） - Charmaz, K. (2006). Constructing Grounded Theory: A Practical Guide Through Qualitative Analysis. SAGE Publications. - Finlay, L., & Gough, B. (Eds.). (2003). Reflexivity: A Practical Guide for Researchers in Health and Social Sciences. Blackwell Publishing. - Bourdieu, P., & Wacquant, L. J. D. (1992). An Invitation to Reflexive Sociology. University of Chicago Press. --- 関連記事 - デザインリサーチ vs マーケットリサーチ——目的・手法・成果の差異 - デザイン思考と認知バイアス——共感・発散フェーズを歪める8つの罠 - コンテキスチュアル・インクワイアリー——現場観察でインタビュー室では得られない暗黙知を掘り起こす - ユーザーインタビュー --- ### リモートでのデザイン思考ワークショップ運営術 URL: https://designthinking.studio/articles/design-thinking-remote-workshop/ > Miro・FigJam・Zoomを使ったオンラインワークショップの設計と運営。200回以上のワークショップ観察から導き出した、対面と遜色ないリモート共感・発想・プロトタイプ体験の実現手法を解説する。 2020年以降、デザイン思考のワークショップはオンラインへの移行を迫られました。最初の反応は悲観的なものでした。「付箋が貼れない」「ホワイトボードが使えない」「参加者の表情が見えない」——対面前提で設計されてきた手法が、画面越しの参加者に届くはずがないという諦観です。 しかし200回以上のワークショップ観察を経て見えてきた実態は、 そのような二分法が間違いだった ということです。リモートは対面の劣化版ではなく、固有の制約と可能性を持つ別の場です。そのルールに合わせた設計が必要なだけです。 リモートワークショップの本質的な課題 リモートワークショップが対面と根本的に異なる点は3つあります。 第1に、注意の競合です。 対面では物理的な場が参加者を「ここにいる」状態に引き込みます。しかしリモートでは、Slackの通知・メールの受信通知・別のブラウザタブが同じ画面に共存しています。ファシリテーターは参加者の注意を常にワークショップに引き戻す設計が必要です。 第2に、非言語情報の欠落です。 対面では部屋の空気感、参加者の姿勢、小声での相談が自然に見えます。ビデオ通話では顔の表情に情報が限定され、しかもその表情もカメラ解像度・ライティング・接続品質によって大きく歪みます。 第3に、同期の難しさです。 対面では「今この付箋を貼って」という指示が全員に同時に伝わります。リモートでは、ツール操作の習熟度に差があり、技術的なトラブルで1名が10分離脱するだけでセッション全体が止まります。 これらを踏まえた設計論を、フェーズ別に解説します。 ツール選定の基準 Miro — デジタルホワイトボードの定番 Miroは、デザイン思考のリモートワークショップで最も広く使われているデジタルコラボレーションツールです。付箋、テキスト、図形、フレーム、リンクをビジュアルで扱え、複数人が同時に編集できます。 ワークショップ用途での強みは テンプレートの豊富さと直感的な操作性 です。アフィニティダイアグラム・HMWフレーム・クレイジーエイト用の8分割キャンバスが事前に設定できます。初めて使う参加者には必ず事前の操作練習（5〜10分）が必要です。 FigJam — デザイナーに親和性の高い選択肢 FigJamはFigmaが提供するコラボレーションホワイトボードです。Figmaを使うデザインチームとのプロジェクトでは、 Figmaとシームレスに連携できる点 が実用的です。Miroほどの多機能ではありませんが、そのシンプルさが初心者には馴染みやすいケースもあります。 Zoom vs Teams vs Meet — ビデオ会議の選択 ビデオ会議ツールの選定は、組織の既存ツールに従うのが現実的です。ただしワークショップ観察から強調したいのは、 ブレイクアウトルーム機能の有無と使いやすさ です。グループワークが中心のデザイン思考では、ブレイクアウトルームの出入りが頻繁に起きます。Zoomは全員をランダムに割り当て直す機能が充実しており、ファシリテーター側の操作負荷が低いです。 フェーズ別：リモート実践ガイド 共感フェーズ：インタビューの再設計 対面のユーザーインタビューをそのままビデオ通話に移行すると、一つの問題が浮かびます。 ユーザーの生活環境が見えない という問題です。対面では「本棚に何が並んでいるか」「机の上に何が置いてあるか」が自然に見えますが、ビデオ通話では意図的に背景を隠すユーザーも多くいます。 解決策の一つは 「見せてもらう」という明示的なリクエスト です。「あなたが普段その問題に向き合う場所を、カメラで見せていただけますか」——この問いが環境観察をビデオ通話でも可能にします。もう一つは 画面共有を使ったコンテキスト観察 です。「その操作をしているところを画面共有しながらやってもらえますか」という依頼で、デジタルサービスの利用シーンを観察できます。 リモートインタビューのもう一つの利点は 地理的制約の消失 です。東京のチームが北海道の農家にインタビューする、海外ユーザーに直接話を聞く——対面では実現が難しかったユーザーアクセスが、ビデオ通話で可能になります。 問題定義フェーズ：Miroでのアフィニティマッピング インタビューで集めた情報をもとにアフィニティダイアグラムを作る作業は、リモートで最も機能しやすいフェーズの一つです。 Miro上での手順はシンプルです。まず全員が各自の発見を付箋に書き（1付箋1インサイト）、一つのフレームに集積します。次に「似たもの同士を動かしてまとめる」作業を5〜8分行います。最後にグループ名をつけて、「最も重要なインサイトはどれか」をドット投票で決定します。 この手順がリモートで機能する理由は、 全員が同じデジタルキャンバスを見ながら操作するという構造にあります。 対面では「あのエリアの付箋が見えにくい」という物理的な問題がありますが、Miro上では全員が同じ情報を同じズームレベルで見られます。 創造フェーズ：ブレインストーミングの工夫 リモートブレインストーミングで最も避けるべきは、 「では自由にアイデアを出してください」という開始 です。この開始は対面でも難しいですが、リモートでは沈黙がさらに重くなります。 効果的な手法は「並行ブレインストーミング」です。全員が同時にMiroに付箋を書き込む時間（5分・タイマー表示）を設け、その後でシェアするという順序です。 「聞いてから考える」より「書いてからシェアする」の順が、全員の声を引き出します。 リモートでは発言の順番待ちが対面より強くなるため、この並行方式が参加者間の発言量格差を減らします。 クレイジーエイトをリモートで実施する場合は、 Miroの「8分割フレーム」を各自に割り当て、カメラオン推奨で8分のタイマーを共有画面に表示 します。紙とペンで描いて撮影する方法と、Miroのペンツールで直接描く方法の両方が使えます。 プロトタイプフェーズ：デジタルとアナログの組み合わせ プロトタイプはリモートで最も課題が多いフェーズです。物理的なもの（模型・スケッチ）を作れないという制約がある一方で、 デジタルプロトタイプに特化することでプロセスを加速できる という面もあります。 デジタルUIのプロトタイプは、FigmaやCanvaと組み合わせることで、対面より速く作れます。ペーパープロトタイプが必要な場合は「各自が紙に書いて、カメラに向かって見せる」という方法が、ローファイな共有として機能します。 観察で繰り返し確認された有効な手法は Miro上でのストーリーボード作成 です。ユーザーが製品/サービスを使うシナリオを4〜6コマの絵コンテ形式で共同作成することで、チーム全員がプロトタイプの「ストーリー」を共有できます。 テストフェーズ：リモートユーザーテストの設計 ユーザーテストはリモートで実施しやすいフェーズです。画面共有を使ったUsability Testing（ユーザーに操作してもらいながら思考発話してもらう）は、 ツール「Maze」「UserTesting」などを使うことでさらに構造化できます。 テストセッション中のファシリテーターの役割分担が鍵です。「インタビュアー（質問する人）」「ノートテイカー（観察を記録する人）」「タイムキーパー」の3役を明確に分け、インタビュアーだけがユーザーと話すルールにします。複数人がユーザーに話しかけると、テストセッションが混乱します。 リモート特有のファシリテーション技術 エネルギー管理：画面疲労との戦い 「Zoom疲れ」は実証研究で確認されている現象です（Bailenson, 2021）。連続して画面を見続けることによる認知的負荷は、対面のコミュニケーションより高いことが示されています。 実践的な対策は 「45分作業＋10分休憩」のサイクルを明示的に設計する ことです。休憩時間には画面を閉じて立ち上がるよう促します。半日以上のワークショップでは、この設計が後半のエネルギーレベルに決定的な差をもたらします。 チェックイン・チェックアウトの強化 対面では開始時の「部屋に入ってきた空気」がチェックインを代替します。リモートでは意図的なチェックインが必要です。 有効なチェックイン方法の一つは「天気予報」です。「今の自分の気持ちを天気で表すと？（快晴・曇り・嵐など）」という問いに一人ずつ答えることで、全員が声を出し、お互いの状態を確認します。所要時間は5〜8分。これが場の安心感を作ります。 ブレイクアウトルームの設計 グループワークのブレイクアウトルームは、 開始前に構造を徹底的に明確化 することが必要です。「ブレイクアウトに入ったら、最初の5分でXをして、次の10分でYをして、最後の3分でZをまとめて戻ってきてください」という指示を、文字でチャットに貼り付けてから開始します。 ブレイクアウトでの観察が難しいのはリモートの弱点です。ファシリテーターが各ルームを巡回することが物理的にできないため、 Miroのアクティビティ（付箋の更新状況）をメインルームから観察しながら、止まっているグループに入るという方法 が補完として機能します。 よくある技術トラブルと対処法 最も頻繁に起きるトラブルは「Miroのアクセス権限がない」「音声が聞こえない」「ブレイクアウトルームに入れない」の3つです。これらはすべて 開始5分前の「テクニカルチェック」 で発見・解決できます。 ワークショップ開始の15分前をツールの練習時間として参加者に案内することで、本番開始時の技術的な混乱を大幅に減らせます。この15分は形式上「任意参加」でも、実際には80%以上の参加者が来ることが観察から確認されています。 まとめ：リモートを設計する リモートワークショップは「対面の代替」ではなく「独自の設計が必要な場」です。ツールの選定・フェーズ別の手法・エネルギー管理・技術準備——この4軸を事前に設計することで、参加者の体験の質は大きく変わります。 最も重要なのは、 リモートでも「安全な実験の場」を作るというデザイン思考の本質は変わらない という認識です。ツールが変わっても、ファシリテーターがその場に心理的安全性を生み出す役割を担っていることは対面と同じです。 --- 参考文献 - Jeremy N. Bailenson, "Nonverbal Overload: A Theoretical Argument for the Causes of Zoom Fatigue," Technology, Mind, and Behavior, 2(1), 2021 - IDEO.org, Design Thinking for Educators Toolkit, 2nd edition, IDEO.org, 2012 - Miro, "Design Thinking Templates," miro.com/templates, 2024 - Chauncey Wilson, "User Interface Inspection Methods," Elsevier, 2014 --- ### ワークショップ対立マネジメント完全ガイド｜衝突を生産性に変えるファシリテーション技法 URL: https://designthinking.studio/articles/workshop-facilitation-conflict-management/ > デザイン思考ワークショップで生じる対立・衝突を、生産的な議論に転換するファシリテーション技法を解説。沈黙・支配・対立の3パターンへの対処法と、意見の相違をアイデアの質に変える具体的な介入手順。 「ワークショップで衝突が起きてしまいました。どうすればよかったでしょうか？」——この質問を受けるたびに、まず聞き返すことがある。「その衝突は、生産的でしたか？それとも破壊的でしたか？」 ほとんどのファシリテーターが「衝突＝問題」と捉えている。しかし実際のワークショップ現場では、対立の「種類」を見分けることが、ファシリテーションの核心的なスキルだ。意見の衝突は、正しく設計すれば、チームが単独では到達できないアイデアの質に繋がる。 --- 対立の3タイプ：「有害な衝突」と「生産的な摩擦」を分ける ワークショップで起きる対立は、3つのタイプに分類できる。 タイプA：内容の対立（Substantive Conflict） 「このアイデアはユーザーに受け入れられない」「前提の解釈が違う」といった、テーマの内容に関する意見の相違。これは基本的に生産的だ。異なる視点がぶつかることで、前提が問い直され、より強いアイデアが生まれやすい。 タイプB：プロセスの対立（Process Conflict） 「なぜここでブレインストーミングをするのか」「時間の使い方がおかしい」といった、進め方に関する意見の相違。適切に扱えば場の設計改善に繋がるが、放置すると「ファシリテーターへの不信感」に転化する。 タイプC：対人の対立（Relational Conflict） 「あの人の意見はいつも否定的だ」「発言権が偏っている」といった、参加者間の感情的な緊張。これだけが純粋に「有害な衝突」だ。内容の議論に関係なく、場の心理的安全性を破壊する。 ファシリテーターの役割は、タイプAとBを生産的に活用しながら、タイプCへの転化を防ぐこと。 --- 衝突が生まれやすい3つの場面 場面1：発散フェーズでの「早すぎる収束」圧力 ブレインストーミング中に「それは現実的じゃない」「予算がない」という批判的な発言が出る。これはワークショップで最も頻繁に起きる対立のトリガーだ。 実際にやってみると、この場面での対立の根本は「発散と収束の切り替え」の合意が共有されていないことにある。発散フェーズのルール（批判禁止・量を優先）が、参加者全員に腹落ちしていなければ、収束志向の強い参加者が無意識に評価を始める。 場面2：意見の二極化と「どちらが正しいか」の構図 特に機能横断チームでは、部署間の既存の対立構造がワークショップに持ち込まれる。「マーケティング vs 技術」「本部 vs 現場」という軸で意見が固まり始めると、「どちらが正しいか」を決める場に変質してしまう。 ワークショップでよく起こるのは、この二極化が「ユーザー視点の問い」ではなく「組織の利益の代弁」として展開されることだ。 場面3：発言の独占と沈黙の二極化 ある参加者が場を支配し、他の参加者が沈黙する状態。これは外見上は「対立がない」ように見えるが、実態は「抑圧された対立」だ。沈黙している参加者が内側で感じている摩擦は、後の場面で爆発するか、あるいはワークショップへの関与そのものを諦める形で現れる。 --- 3つの対立パターンへの具体的介入 介入1：「評価から分離する」構造介入 発散フェーズでの批判的発言には、内容への反論ではなく「構造の再設定」で介入する。 「今は量を増やすフェーズなので、評価は後のセッションでじっくり行います。そのアイデア、今は付箋に書いておいてください」という形で、発言を「フェーズ違い」として処理する。相手の意見を否定せず、タイミングをずらす介入だ。 参加者からの声として多いのが「評価された気がしなかった」という感想だ。 この「否定された感覚のなさ」が、心理的安全性を保ったまま発散フェーズを進める鍵になる。 介入2：「ユーザーに返す」リダイレクト介入 部署間の二極化が起きた時の有効な介入が、議論の基準を「ユーザー」に戻すことだ。 「今の2つの視点は、どちらもユーザーの何かを代弁しているように聞こえます。具体的にどのユーザーが、どんな状況でそう感じるかを書いてもらえますか？」と問いかけると、抽象的な組織間の対立が、具体的なユーザー像の違いとして可視化される。 ユーザーの具体性を場に持ち込むことで、「どちらの意見が正しいか」から「ユーザーにとって何が正しいか」に問いの軸が移る。 これはデザイン思考特有のリダイレクト技法だ。 介入3：「沈黙を資源にする」構造的包摂介入 発言の独占が起きた場合、直接的な制限（「他の方にも発言を」）は支配的参加者の自尊心を傷つけ、対人対立を引き起こすリスクがある。 有効な手法として、ラウンドロビン（全員が順番に1分以内で発言するルール） や サイレントブレインストーミング（各自が付箋に書く時間を設けてから共有する） がある。これらは「全員に発言の機会が構造的に確保される仕組み」であり、特定個人を制限しているように見えない。 沈黙している参加者への介入として有効なのが、「今まで出たアイデアで、特に気になるものはありますか？」という間接的な問いかけだ。「あなたの意見は？」と直接を問うより、まず場に関与するコストを下げる。 --- 生産的な摩擦を意図的に作る技法 対立への対処だけでなく、意図的に「健全な緊張」を作り出す技法も、ファシリテーターの重要なスキルだ。 技法1：反論者のロールアサイン ブレインストーミングや選択フェーズで、あえて「批判的な視点を担当する役割」を事前にアサインする。デビルズ・アドボケイト（悪魔の弁護人）と呼ばれる手法だ。 ポイントは、役割として批判を求めることで、「個人の性格」と「批判の発言」を切り離すことだ。「この役割をやっている人が言っている批判」という文脈が、批判を受ける側の感情的なダメージを減らし、内容として処理しやすくする。 技法2：「もし○○なら？」仮説転換 行き詰まりを感じた対立場面で有効な介入が、「もし制約がなかったら？」「もしユーザーが全く別の価値観を持っていたら？」という仮説転換の問いだ。 現実の制約・組織の論理・過去の経緯が対立の燃料になっている時、仮説の空間に対話を移すことで、防衛的な反応が和らぐ。ワークショップでよく起こるのは、この「もし○○なら？」の問いを投げた後、それまで黙っていた参加者が急に発言を始めることだ。 技法3：アイデアのフィジカル化 言語的な対立が白熱した時、プロトタイプ制作に移ることで場のダイナミクスが変わる。「どちらが正しいかを議論する前に、両方を15分で作ってみましょう」という提案だ。 作る行為は協働を促し、言語的な対立を「素材」として処理し始める。実際にやってみると、フィジカルなプロトタイプが目の前に並んだ時点で、対立の構造が「どちらが正しいか」から「どちらがより機能するか」に変わる。 テスト可能な問いになった瞬間、対立は生産的な実験へと転換する。 --- ファシリテーターが「焦らない」ための準備 対立管理の最大の障壁は、ファシリテーター自身が衝突に動揺することだ。場が混乱すると、ファシリテーターは急いで収束させようとする。しかし急いだ収束は、参加者の未消化の感情を残し、後の場面でより大きな爆発を引き起こす。 準備として有効なのが、「対立が起きた時にどう介入するか」のシナリオを事前に3パターン書いておくことだ。「発散フェーズで批判が出たら → 評価から分離する構造介入」「二極化が起きたら → ユーザーに返す問いかけ」「沈黙が続いたら → ラウンドロビンに移行」という形でカードを手元に持っておく。 シナリオがあると、実際の場面で「想定済みのケース」として落ち着いて対応できる。ファシリテーターの落ち着きは、参加者の心理的安全性に直結する。 --- 会議後のふりかえり：対立の後処理 ワークショップが終わった後、対立が生じた場面を放置しないことが重要だ。特にタイプC（対人の対立）が表面化した場合、会議後の個別フォローが次のワークショップの参加意欲を左右する。 参加者からの声として多いのが「言いすぎた/言われすぎたが、ワークショップ後に誰もフォローしてくれなかった」というものだ。対立の後処理は、ファシリテーションの最後のフェーズだ。 セッション終了後に15分のふりかえり時間を設け、「今日の場で気になったことはあるか」を全員に聞く機会を作ることで、未消化の感情を丁寧に拾うことができる。 --- やってみよう 次のワークショップ前に、以下を準備する。 - 今日のセッションで「対立が起きやすい場面」を2か所予測し、それぞれへの介入方法を1つ決めておく - 発散フェーズに入る前に「このフェーズでは評価しない」ルールを参加者全員で声に出して確認する（暗黙の合意では機能しない） - もし対人対立が起きた場合の「一時休憩の入れ方」を、進行表の中に意図的に組み込んでおく 特に機能横断チームのワークショップでは、開始前に「今日は役職・部署を一度横に置く場にする」という合意を取ることが、対立予防として最も費用対効果が高い。 --- 内部リンク - ワークショップ・ファシリテーション術 - デザイン思考のリモートワークショップ - 発散思考と収束思考の使い分け - 問題定義フェーズのファシリテーション - ドット投票による収束手法 - ラウンドロビン・アイデエーション --- 参考文献 - Lencioni, Patrick. The Five Dysfunctions of a Team. Jossey-Bass, 2002. （邦訳：『あなたのチームは、機能してますか？』翔泳社） - Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins, 2009. - Harvard Business Review. "How to Design Meetings Your Team Will Want to Attend." HBR, April 2017. https://hbr.org/2017/04/how-to-design-meetings-your-team-will-want-to-attend - Nielsen Norman Group. "Facilitating an Effective Design Studio Workshop." NN/g Articles, 2023. https://www.nngroup.com/articles/facilitating-design-studio-workshop/ - Stanford d.school. "Design Thinking Bootleg." Stanford d.school, 2023. https://dschool.stanford.edu/resources/design-thinking-bootleg - IDEO. "Design Thinking for Educators Toolkit." IDEO, 2012. https://www.ideo.com/post/design-thinking-for-educators - Edmondson, Amy C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2018. （邦訳：『恐れのない組織』英治出版） --- ### 管理職の役割が「指示」から「問い」へ変わるとき——デザイン思考とリーダーシップ URL: https://designthinking.studio/articles/design-thinking-leadership-transformation/ > デザイン思考の導入がうまくいかない現場では、管理職が「指示する役割」から「問いを立てる役割」へ変わっていない。リーダー個人の思考転換・ファシリテーション・チーム設計の3軸に絞って解説します。組織側の設計は完全ガイドへ。 「うちの部下はデザイン思考が理解できていない」。管理職がこう言う時、問題の多くは部下ではなくリーダー側にある。 デザイン思考を組織に導入する失敗パターンの多くは、リーダー自身が「指示する役割」から「問いを立てる役割」へと変わっていないことに起因する。研修やワークショップを「部下にやらせるもの」として位置づけた瞬間、変革の主体がリーダーから切り離される。 本記事では、デザイン思考による組織変革を「管理職個人のリーダーシップ変容」という角度から解説する。理論的な背景に加えて、ワークショップ現場で繰り返し観察されるリーダーの行動変容のパターンを具体的に提示する。 この記事はリーダー個人の変化に絞っている。組織の側の設計（体制・巻き込み・3年計画）はデザイン思考 組織変革の完全ガイド（3年ロードマップ）にある。 --- リーダーシップとデザイン思考の根本的な緊張関係 「解を持つリーダー」という呪縛 日本の多くの組織において、管理職に求められてきたのは「問題を解決する人」という役割だ。上位者から課題を与えられ、それを部下に割り振り、プロセスを管理し、成果を出す。このモデルでは、リーダーがあらかじめ「正しい答え」を持っていることが前提になっている。 デザイン思考が前提とする世界はまったく異なる。「解くべき問題そのものが不明確」な領域では、正しい答えをあらかじめ持つことができない。探索し、試し、失敗し、学ぶプロセスこそが価値を生む。このプロセスにおいてリーダーに求められるのは「解を持つこと」ではなく「問いを共に立てること」だ。 この根本的な転換が、管理職にとってデザイン思考を「難しい」と感じさせる核心にある。知識の問題ではなく、アイデンティティの問題だ。 ファシリテーターとしてのリーダー ワークショップでよく起こるのは、リーダーが部屋の後ろに座り、部下たちの議論を評価するように見ている場面だ。部下がアイデアを出すたびに「それはコストがかかりすぎる」「それは現実的でない」と評価を加える。 この行動が何をするかというと、部屋の心理的安全を一瞬で消去する。人は「評価される」と感じた瞬間に、探索をやめてリスクを回避し始める。 管理職がいる部屋でアイデアが出ない理由の多くは、ここにある。 デザイン思考において、リーダーはファシリテーターだ。プロセスを設計し、場を整え、心理的安全を保ち、発見を促す。解を評価するのではなく、探索を支援する役割への転換が求められる。 --- 実践フレーム：管理職が変革を主導する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. --- ### 気候変動対策とデザイン思考 — サステナビリティ課題への適用フレームワーク URL: https://designthinking.studio/articles/design-thinking-climate-change-application/ > 気候変動という複雑・多層的な課題に、デザイン思考の5フェーズをどう適用するか。IDEOや企業の実践事例を軸に、実務で使えるフレームワークを解説します。 気候変動対策にデザイン思考を持ち込むと何が変わるか。端的に言えば、「誰のために、何を解決するのか」という問いの精度が上がります。技術・政策・資金の3つが揃っても、実際に人々の行動が変わらなければ排出削減は進みません。デザイン思考が機能する理由は、この「行動を変える」という人間的な問題の核心に直接アプローチするからです。 なぜ気候変動課題にデザイン思考が有効か 気候変動は「技術的に解けるが行動的に解けない」問題の典型です。再生可能エネルギーのコストはこの10年で劇的に低下しました。電気自動車の航続距離も伸びています。それでも、個人の消費行動・企業の調達方針・地域コミュニティの慣習は、容易には変わりません。 この構造を分解すると、3つの壁が見えてきます。 - 認知の壁：問題が遠く、抽象的に見える（「2100年の話」「自分一人では変えられない」） - 利害の壁：短期コストと長期便益のトレードオフが、現場では常に短期優先になる - 文脈の壁：同じ「CO₂削減」でも、農村部の農家と都市部のオフィスワーカーでは課題の形がまったく異なる デザイン思考が有効なのは、この3つの壁を「ユーザーリサーチ → 課題再定義 → プロトタイピング」のサイクルで突破する仕組みが組み込まれているからです。政策立案者が机上で描いたソリューションではなく、現場にいる人々が実際に使えるソリューションを育てるプロセスと言えます。 5フェーズ別の適用方法 Phase 1: 共感（Empathize）— 「被害者」ではなく「生活者」として見る 気候変動の文脈では、調査対象を「被害を受けている人々」として設定しがちです。しかしデザイン思考の共感フェーズでは、相手を日常の文脈を持つ生活者・実務者として見ます。 IDEOがケニアの農村部で取り組んだHCD（Human-Centered Design）のプロジェクトでは、気候変動の影響で不安定になった降雨パターンへの適応支援を目的としていました。研究チームがまず行ったのは、農業技術の説明でも機材の配布でもなく、農家の人々と畑に立ち、何を恐れ、何を頼りにして意思決定しているかを聞くことでした。その観察から見えてきたのは、「天気予報よりも、隣の畑の古老の観天望気を信頼している」という事実でした。技術的に正確な情報よりも、信頼できる人を介した情報伝達の設計が優先課題だとわかったのです。 実践上のポイント： 気候変動という大きな問いではなく、「この人が今日、何を判断しなければならないか」に問いを絞り込みます。洪水リスクの高い地域の住民であれば、避難行動の判断をどう下すかの観察が起点になります。 Phase 2: 課題定義（Define）— 「地球を救う」を「○○さんが○○するのを助ける」に翻訳する 「気候変動を止める」という問いは大きすぎて、チームが何も始められません。課題定義フェーズの役割は、共感フェーズで集めた観察を、チームが行動できる解像度の問いに変換することです。 デザイン思考の代表的なツールである「HMW（How Might We）」の問いは、この翻訳に特に有効です。 - 「気候変動を止めるにはどうすれば？」→ 砕けない - 「農家の人が雨不足でも収入を維持できるようにするには？」→ 動ける パタゴニアがサプライチェーンのサステナビリティ改善を進めた際、初期のHMW問いは「いかにサプライヤーの環境負荷を下げるか」でした。しかし実際の工場調査を経て、問いは「サプライヤーが環境改善の投資を、コスト削減と同時に達成できるようにするには？」に再定義されました。この問いの転換が、検査・罰則型のアプローチではなく、コスト効率を共に設計するコンサルティング型の関与を生みました。 Phase 3: アイデア創出（Ideate）— 実現可能性を後回しにする意味 気候変動のワークショップで「電気代が安くなる仕組みを考えよう」と言った瞬間、参加者の多くが「現状の制度では…」「コストが…」という方向に動きます。アイデア創出フェーズの価値は、この「現実のブレーキ」を一時的に外す構造にあります。 Google.orgがサポートしたGiveDirectly（ケニア・ウガンダでの直接現金給付プログラム）では、気候変動適応のための資金支援策をブレインストーミングする際、「銀行口座を持たない農家に直接送金する」というアイデアが最初は空論として扱われていました。しかし「実現可能性を問わない」フェーズでの発想が残り、モバイルマネーの普及とセットで現実的なソリューションになりました。 実践上のポイント： 「環境先進国の事例」「SF映画の世界」「10億円あったら」という制約除去の問いかけを意図的に使い、発想の範囲を広げてからフィルタリングに入ります。 Phase 4: プロトタイプ（Prototype）— 気候変動の「未来体験」を今日作る 気候変動課題のプロトタイプが難しいのは、変化の多くが数十年スパンで起きることです。この時間的ギャップを埋めるために、「未来体験」のシミュレーションをプロトタイプとして作る手法が有効です。 気候変動シナリオの可視化ツール「Climate Interactive」のEn-ROADSモデルは、政策立案者・企業のリーダーが「もし石炭税をこの水準にしたら」「もし植林面積をこれだけ増やしたら」を実時間でシミュレーションできるプロトタイプです。会議室で数字を議論するのではなく、意思決定者が自分の手で仮説を動かして体験することで、政策合意のスピードと納得感が変わります。 企業レベルでの実践例として、農業関連のサプライチェーン改善プログラムでは、農家向けに「作付けシミュレーター」のペーパープロトタイプが作られるケースがあります。実際に農家が手で数字を動かし、「この品種に切り替えると収入がどう変わるか」を体験する仕組みです。デジタルツールの前にアナログのプロトタイプを挟むことで、農家からの改善フィードバックを早期に収集できます。 Phase 5: テスト（Test）— 「測れる行動変容」を指標に設定する テストフェーズで最も重要なのは、「意識が変わった」ではなく「行動が変わった」を測ることです。気候変動の啓発プログラムは往々にして、アンケートで「環境への関心が高まった」という回答を得て終わります。しかし実際の電力消費量・廃棄物量・移動手段の選択が変わらなければ、排出削減には繋がりません。 ナッジ理論を応用した英国のエネルギー節約プログラム「Opower（現Oracle Utilities Opower）」は、自宅の電力使用量を近隣世帯と比較するレポートをユーザーに送るソリューションです。「環境のために節電しましょう」というメッセージではなく、「あなたの使用量は近隣より◯%多い/少ない」という社会的比較を使います。テストフェーズでは、実際の電力消費量のデータを継続取得し、比較送付あり/なしの対照群で効果を検証しました。結果として1〜3%の節電効果が継続して測定され、スケールへの確信が生まれました。 実践上の留意点 「被害の均等性」を前提にしない デザイン思考プロジェクトは、往々にして「声を上げやすい参加者」から始まります。気候変動の文脈では、最も脆弱な地域・コミュニティ（低所得地域、小規模農家、島嶼国）が、最も声を上げにくい立場にいます。共感フェーズのリサーチ設計時に、意図的に周縁のステークホルダーから始めることが求められます。 スケールアップの前に「誰がオーナーか」を決める サステナビリティ課題でプロトタイプが成功すると、「全国展開しよう」「他社にも展開しよう」という動きが起きます。しかしデザイン思考で作られたソリューションは、特定の文脈に根ざしています。別の地域・組織に移植する際には、もう一度共感フェーズから始める覚悟が必要です。Airbnbのプロトタイプが「ニューヨーク限定のプロ撮影」から始まったように、スケールは新しいコンテキストでの再検証を経るべきです。 チームに「システム思考」を持ち込む デザイン思考は個別の「痛み」を解決するのに長けていますが、気候変動は複数の痛みが連鎖するシステム問題です。プロジェクトの途中でシステムマップ（因果関係図）を描く時間を設けると、自分たちの介入点がシステム全体のどこに位置するかが見えます。「点の解決」に終始するリスクを減らす補完的な手法です。 --- デザイン思考は気候変動課題を「解く」ツールではありません。「誰にとっての、どんな問題か」を正確に定義し直すためのプロセスです。この問いの精度が上がるほど、技術・政策・資金の投資が「実際に使われるもの」に近づきます。ワークショップの場に現場の声を持ち込み、プロトタイプで未来を体験させ、行動変容を測り続ける——そのサイクルを回す意志が、サステナビリティ実践の差を分けます。 --- ### 共感フェーズ——ユーザーを深く理解するための観察と対話 URL: https://designthinking.studio/articles/empathize-phase/ > デザイン思考の最初のフェーズ「共感（Empathize）」を解説。ユーザーインタビュー、観察、没入体験の手法と実践のポイント。 共感（Empathize）はデザイン思考の最初のフェーズであり、最も重要な土台です。ユーザーの行動、感情、動機を深く理解することで、真に意味のある解決策の基盤を築きます。 なぜ共感が重要なのか d.school の教えでは、「デザイン思考は共感から始まる」とされています。これは単なるプロセスの順番ではなく、人間中心設計の姿勢そのものを意味しています。 自分たちの仮説や思い込みではなく、ユーザーが実際に経験していることを理解することで、本当に解くべき問題を発見できます。 共感の3つのアプローチ - 観察（Observe） ユーザーの行動を自然な環境で観察します。重要なのは、ユーザーが言っていることと実際にしていることの違いに注目することです。人は自分の行動を正確に説明できないことが多いため、直接的な観察が不可欠です。 - インタビュー（Engage） ユーザーインタビューを通じて、行動の背景にある動機や価値観を探ります。効果的なインタビューのポイントは以下の通りです。 - 「なぜ？」を繰り返す — 表面的な回答の背後にある本当の理由を掘り下げる - オープンクエスチョンを使う — 「はい/いいえ」で答えられない質問をする - 沈黙を恐れない — ユーザーが考える時間を与える - 感情に注目する — ユーザーの表情、声のトーン、ボディランゲージを観察する - 没入体験（Immerse） ユーザーと同じ体験をすることで、頭だけでなく身体感覚を通じて理解を深めます。病院のサービスを改善するプロジェクトでは、デザイナー自身が患者として入院体験をすることもあります。 共感マップの活用 共感マップ（Empathy Map）は、ユーザーの体験を4つの象限で整理するツールです。 - 言っていること（Say） — ユーザーが口にした言葉 - 考えていること（Think） — 言葉にはしないが考えていること - していること（Do） — 実際の行動 - 感じていること（Feel） — 感情や不安 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、共感フェーズを「終わらせる」ことを急ぎすぎるチームの多さです。「インタビュー3人やりました、終わりました」と次に進もうとする場面は定番です。実際にやってみると、3人目と4人目のインタビューで全く新しい視点が出てくることが珍しくありません。 もう一つよく目にするのが、インタビューの録音・書き起こしをせず「なんとなく覚えている内容」でチームが議論を進めるパターンです。「あのユーザーは〜と言っていた」が少しずつ書き換わり、2日後には都合の良い解釈に変わっている。共感フェーズの精度は、記録の精度で決まります。 まとめ 共感フェーズは、デザイン思考の品質を左右する最も重要なプロセスです。十分な時間をかけてユーザーを理解することが、後続のフェーズすべての成功につながります。次の問題定義フェーズでは、ここで得たインサイトをPOVステートメントに変換します。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Liz Sanders & Pieter Jan Stappers, "Co-creation and the new landscapes of design", CoDesign, Vol.4, No.1, 2008 --- ### 金融サービスにおけるデザイン思考——顧客体験革新の実装ロードマップ URL: https://designthinking.studio/articles/design-thinking-financial-services/ > 金融業界でデザイン思考を導入する際の障壁（規制・リスク回避文化・意思決定チェーン）を正面から扱い、ING Bank・BBVA・JP Morganの3事例から成功条件の共通点を抽出する実践ガイド。 金融機関でデザイン思考を導入しようとすると、他の業界では経験しない壁にぶつかる。 規制の壁、リスク回避文化、複数の承認フェーズをまたぐ意思決定チェーン。「ユーザーのニーズを起点に素早く試す」というデザイン思考の基本動作が、金融機関の構造と正面から衝突する。 しかしそれでも、デザイン思考を金融サービスに根付かせることに成功した組織は存在する。ING Bank、BBVA、JP Morgan の3事例から、成功の共通条件を抽出する。 --- 金融業界特有の障壁——「素早く試す」が機能しない理由 デザイン思考の実践でワークショップが楽しく終わっても、「さてプロトタイプを作って試してみよう」という段階で動きが止まる——金融機関のプロジェクトでよく起こる光景だ。その原因を構造的に整理する。 障壁1：規制と法令遵守の優先順位 金融商品のプロトタイプは、一般的なデジタルサービスとは異なる制約下にある。金融庁への届出が必要な新商品は、プロトタイプの段階では「仮の商品」として扱えないケースがある。AML（マネーロンダリング防止）対応、個人情報保護法、金融商品取引法の適用範囲が、ユーザーテストの設計に影響する。 ここで多くの組織が犯す間違いは、「規制があるからプロトタイプテストができない」と判断して、テストフェーズ全体を諦めることだ。規制は「何をどこまでテストできるか」の条件であり、テストそのものの禁止ではない。 法務・コンプライアンス部門を最初から巻き込み、「この形式でのテストは可能か」を確認するプロセスを設計することが、この障壁の実際の対処法になる。 障壁2：リスク回避文化と「失敗」への敏感さ デザイン思考は「早く失敗して学ぶ（Fail Fast）」を前提とする。しかし金融機関では、「失敗」が顧客の財産や信頼に直結するという強い信念が文化として根付いている。 この文化は誤りではない。顧客の預金が動くシステムに「ラフなプロトタイプ」を投入することは、確かにリスクを伴う。問題は「失敗が許されない」という認識が、学習の機会そのものを排除してしまうことだ。 実際には、デザイン思考が最もリスク回避的な手法でもある。完璧なシステムを作り込んでから市場に出すよりも、低忠実度のプロトタイプで顧客のニーズを検証してから投資する方が、失敗のコストははるかに低い。 この認識ギャップを埋めるために、「プロトタイプ」を「実験」ではなく「調査ツール」として定義し直すフレーミングが有効なことがある。「試している」ではなく「調べている」という語感が、リスク回避文化の中では通りやすい。 障壁3：多層化した意思決定チェーン 金融機関の新しい顧客サービスには、プロダクト部門・IT部門・法務・コンプライアンス・リスク管理・経営企画が関与する。各部門がそれぞれの基準で承認判断をする。 デザイン思考のプロセスは本来、少人数の多機能チームが素早く反復する構造を想定している。承認者が6部門に分散した状態では、1サイクルの検証に数週間を要することも珍しくない。 対処法として機能するのは、主要ステークホルダーをプロジェクトの初期段階から「共同設計者」として巻き込むことだ。承認者を「チェックする人」ではなく「一緒に作る人」のポジションに置くことで、後段での手戻りを減らす。IBMが「Enterprise Design Thinking」で実践した「スポンサーユーザー（Sponsor Users）」の概念——内部の権限者をデザインプロセスの参加者として組み込む——は、金融機関の構造に適合しやすい設計だ。 --- ING Bank：アジャイルとデザイン思考の統合 ING Bank（ING グループ、オランダを本拠地とするグローバル金融機関）は、2015年から組織全体のアジャイル変革を実施した。その中でデザイン思考は、顧客体験設計の方法論として組み込まれた。 ING は従来の機能別部門制を廃止し、「スクワッド（Squad）」と呼ばれる小規模多機能チームに組織を再編した。各スクワッドは特定の顧客ジャーニーを担当し、プロダクトマネージャー・デザイナー・エンジニア・コンプライアンス担当者が同一チームとして機能する。 この構造がデザイン思考の実践において意味するのは、コンプライアンス担当者がテストサイクルの外側にいないことだ。法務的な確認がテストサイクルを遮断するのではなく、スクワッド内で並行して進む。意思決定のサイクルタイムが短縮された。 ING の取り組みの詳細は、McKinsey・London Business School・Harvard Business School が発表したケーススタディや ING の公式資料に記録されているが、注目すべきは「デザイン思考の導入」ではなく「組織構造そのものの再設計」が先行したことだ。手法を先に導入して組織が変わるのを待つよりも、構造を変えることで手法が機能する環境を先に作ったという順序の違いが、ING の成功の核心にある。 --- BBVA：顧客ジャーニー起点のデジタル変革 BBVA（Banco Bilbao Vizcaya Argentaria、スペインを本拠地とするグローバル銀行）は、2007年頃からデザイン思考を顧客体験設計の方法論として組織的に導入し始めた。 BBVA の特徴は、デザイン組織を経営の中枢に近い位置に置いたことだ。BBVA はグローバル・デザイン責任者（Global Head of Design）ポジションを設け、カスタマーエクスペリエンス担当チームを戦略部門に組み込んだ。これは日本の金融機関に多い「デジタル推進部が外部ベンダーと連携してデザインする」構造とは根本的に異なる。 顧客ジャーニーマップを全行員が共通言語として使うという取り組みも実施した。支店スタッフ・コールセンター担当者・デジタルチームが、同じ顧客の「旅」の地図を参照することで、タッチポイントをまたいだ体験の一貫性が設計可能になる。 BBVA のケースから学べる原則は、顧客体験のデザインは「特定の部署の仕事」ではなく「組織全体の共通言語の問題」だということだ。デザイン思考の手法を一部のプロジェクトチームだけが持っていても、顧客が体験するサービスの一貫性は実現しない。 --- JP Morgan：インハウスデザイン組織の構築 JP Morgan Chase は、2013年前後からデザイン思考を活用したユーザーリサーチとプロダクト開発を、リテールバンキング部門を中心に拡大した。 特に注目されるのは、インハウスのデザインスタジオを設立してデザイン人材を内部化した判断だ。外部のデザインエージェンシーへの依存を減らし、顧客データへの直接アクセスと開発チームとの連携を密にすることで、設計→テスト→実装のサイクルを短縮した。 JP Morgan の取り組みの中で「共感フェーズ」が発揮された例として、ATM のインターフェース再設計プロジェクトがある。高齢者ユーザーや視覚障害のあるユーザーを含む多様なターゲットへの丁寧なフィールドリサーチが、従来の「社内で想定したユーザー像」から大きく異なるインサイトをもたらした。詳細は JP Morgan Chase の公式ニュースルームや UX 関連カンファレンスでの発表に記録されている。 --- 3事例から導く成功条件 ING・BBVA・JP Morgan の3事例を並べると、業界・規模・アプローチが異なっても、成功に至るプロジェクトには共通した条件がある。 条件1：組織構造がデザイン思考の実践を物理的に可能にする設計になっている。 ING のスクワッド構造、BBVA のデザイン組織の戦略部門への組み込み、JP Morgan のインハウスデザイン組織——三者とも「デザイン思考を実践できる環境」を組織構造として先に設計している。ワークショップだけを導入しても変わらない。 条件2：規制・法務・コンプライアンスの担当者がデザインプロセスの「外側」にいない。 金融機関での失敗プロジェクトの典型は、プロトタイプを作った後に法務・コンプライアンス部門に確認を依頼して「この形では提供できない」と差し戻されるパターンだ。成功事例では、これらの担当者が初期段階から設計チームの一員である。 条件3：デザイン思考の「結果」ではなく「プロセス」を組織に根付かせている。 「デザイン思考でいいプロダクトができた」という成果よりも、「デザイン思考的な問いの立て方が日常になった」という状態を目指している。これは一度のプロジェクトでは達成できない。継続的な教育・ファシリテーション人材の育成・組織内の実践コミュニティの形成が必要になる。 --- やってみよう——金融機関での最初の一歩 すでに金融機関でデザイン思考導入を検討している場合、最初のステップとして機能しやすいのはサービスデザインブループリントの作成だ。 既存の顧客接点（口座開設フロー、問い合わせ対応、申込手続きなど）を1つ選び、フロントステージ（顧客が見える場所）とバックステージ（顧客から見えない社内プロセス）を可視化する。顧客の感情曲線を同時に描くことで、「どの瞬間に顧客の信頼が下がるか」が視覚化できる。 この作業を関係部門（フロント・IT・法務・コンプライアンス）の担当者が同席してワークショップ形式で行うと、「部門間で見えている顧客体験が違う」という事実が最初の重要な発見になる。そこから「では、どうするか」の問いが始まる。 サービスデザインブループリントの具体的な手順は別稿で詳述しているが、金融機関での適用においては「規制上の制約を先にブループリントの中に記入する」というステップを追加すると、現実的な改善余地を早く特定できる。 デザイン思考は「規制のない業界のもの」ではない。制約が多い業界だからこそ、「何が本当の障壁か」を正確に見極める共感とインサイト抽出の力が要る。手を動かすことから始めてほしい。 --- 国内金融機関での具体的なユーザーリサーチ手法と「信頼の壁」の乗り越え方については、デザイン思考で金融サービス革新——顧客の「恥」を起点にした設計の現場で詳述している。 --- 参考文献 - ING, "ING's agile transformation", ing.com, 2015〜（公式資料） - BBVA, "Design at BBVA", bbva.com（デザイン組織に関する公式コンテンツ） - Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence & Jakob Schneider, This Is Service Design Doing, O'Reilly Media, 2018 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - Nielsen Norman Group, "Design Thinking in Finance: Challenges and Opportunities", nngroup.com --- ### 顧客理解の錯覚：7割の企業が陥る「わかっているつもり」からの脱出 URL: https://designthinking.studio/articles/customer-understanding-illusion/ > 新規事業の失敗原因1位は「市場ニーズの欠如」。調査では72%の企業が顧客を理解していると自己評価するが、実態とは大きく乖離している。デザイン思考の共感フェーズが解くこの構造的問題と、N=1リサーチが開く突破口を解説する。 新規事業プロジェクトが行き詰まる現場で、よく耳にする言葉がある。「うちは顧客のことをよくわかっている」。しかし、その確信こそが、最初の、そして最大の落とし穴かもしれない。 売上高100億円以上の企業で新規事業開発に携わった579名を対象とした調査（2025年12月実施）では、72.3%の担当者が「顧客を十分に理解している」と自己評価していた。ところが、同じ調査でプロジェクトの単年黒字化を達成できたケースは約10%に過ぎない。自信と結果の間には、埋めがたい乖離がある。 「わかっているつもり」が生まれる構造 なぜ企業は顧客理解を錯覚するのか。ワークショップの現場でこの問いを参加者に投げかけると、決まって似たような答えが返ってきます。「営業データを毎週見ている」「アンケートを年2回実施している」「現場の声はSlackで共有されている」。 しかし、データは顧客の行動を記録するが、その行動の背後にある文脈や感情を教えてはくれません。アンケートは顧客が意識できる範囲のことしか回答できない。Slackに流れる「現場の声」は、往々にして既存顧客の既存の不満であり、まだ言語化されていないニーズとは別物です。 IDEOやd.schoolが共感フェーズを「プロセスの起点」に置いているのは、まさにこの構造的な盲点への処方箋です。共感とは、顧客について調べることではなく、顧客とともに経験することを意味します。 新規事業失敗の第一位は「市場ニーズの欠如」 同調査において、新規事業が失敗した原因の第一位は「市場ニーズの欠如（30.1%）」だった。この数字が示すのは、技術力や資金の不足ではなく、「誰のどんな問題を解くのか」という根本的な問いの省略だ。 ある食品メーカーの新規事業担当チームが経験したケースが示唆に富む。健康食品の新ラインを立案する段階で、チームは既存の購買データと競合分析をもとに「40代女性向けの低糖質スナック」を設定した。アンケートでも「そういう商品があれば購入したい」という回答が多数得られた。しかし実際に発売すると、想定の3割程度しか売れなかった。 後から現場インタビューを行うと、ターゲットとした40代女性が「スナック」というカテゴリ自体に罪悪感を抱えており、どれだけ低糖質でも「ご褒美以外の文脈では買いにくい」という意識が根深くあることがわかった。アンケートでは「購入したい」と答えていた人が、実際の購買行動では別の判断をしていた。 これが「顧客理解の錯覚」の典型例だ。顧客は、聞かれたことに誠実に答える。しかし、自分の無意識のブレーキについては、問われない限り答えることができない。 共感フェーズの本質：コンテキストに飛び込む デザイン思考のEmpathize（共感）フェーズは、単なる「顧客の声を聞く」プロセスではない。顧客の生活文脈の中に入り込み、言語化されていない経験を観察・理解するプロセスだ。 d.schoolのガイドラインでは、共感の方法として三層を提示している。Watch（観察）、Listen（傾聴）、Experience（体験）だ。 まず観察。顧客が実際に商品を使っている場に行く。会議室でヒアリングするのではなく、顧客の手元と表情を見る。データは結果を記録するが、観察は「なぜそうなるのか」を記録する。 傾聴と体験はセットで考えるといい。「なぜそうしているのか」を問い返しながら話を聞き、可能なら自分でも同じサービスを使ってみる。頭で理解することと、身体を通じて理解することは、入ってくる情報が違う。 この三層を実践するために必要なのは、特別なツールでも高額なリサーチ費用でもない。必要なのは、オフィスを出ることだ。 N=1リサーチが拓く突破口 調査で明らかになったもうひとつの発見は、単年黒字化を達成したプロジェクトが「N=1の定性リサーチ」を重視していたという点です。N=1とは、統計的サンプルではなく一人の顧客に深く向き合うアプローチを指します。 一人の顧客に2時間かけてインタビューすることで、1,000件のアンケートでは見えなかった「なぜ」が浮き上がってきます。その「なぜ」が、プロジェクトの方向を根底から変えることがある。 実際にやってみると、このことに多くのチームが驚きます。老後の資産形成アプリを開発していたあるチームが、ターゲットである50代男性一人に3時間かけてインタビューを行いました。そこで見えてきたのは、「老後の不安」は確かにあるが、「今の生活費を削って投資に回すことへの家族への申し訳なさ」という感情が、アプリへのログインを妨げていたという事実でした。 この発見がなければ、チームはUIの改善やシミュレーション機能の追加を繰り返していたでしょう。真の障壁は機能でも操作性でもなく、「家族の同意を得る体験」の欠如でした。N=1のインタビューが、開発方向を180度変えたのです。 顧客理解の深度チェック：5つの問い ワークショップで使う「顧客理解の錯覚チェック」を紹介する。自プロジェクトに照らし合わせて考えてみてほしい。 問い1：直近3ヶ月以内に、顧客の「生活の場」を直接観察したか？ オフィスでの会議でもなく、展示会での立ち話でもなく、顧客が実際に商品・サービスを使う場所や生活の現場を訪れたかどうか。 問い2：インタビューで「なぜ」を5回以上連続して問い返したか？ 最初の答えは表層にある。「なぜそう感じるのか」「なぜそうしているのか」を繰り返すことで、根本にある動機や感情に近づく。 問い3：顧客が「言わなかった」ことを記録しているか？ 言葉を濁した場面、話題を変えた瞬間、表情が曇った瞬間。語られたことより、語られなかったことが本質に近い。 問い4：自社の仮説を否定するデータを意図的に探したか？ 確証バイアスは誰にでもある。「やはりそうだった」ではなく「これは想定外だった」と言えるデータがあるか。 問い5：顧客理解を「更新」する仕組みがあるか？ 3年前のリサーチ結果を今も使っていないか。顧客の状況、感情、文脈は変わり続ける。顧客理解は一度完成するものではなく、継続的に更新するものだ。 この5問のうち、自信を持ってYesと答えられるのが3つ以下なら、顧客理解の見直しを始める価値がある。 定量と定性を「往復する」思考法 優れた新規事業チームに共通するのは、定量データと定性リサーチを一方向に進むのではなく、往復しながら意思決定の精度を高めているという点だ。 定量データは「何が起きているか」を教えてくれる。購買率が下がっている、離脱が特定の画面で集中している、特定の属性のコンバージョンが低い。これは「どこを見るべきか」を指し示す地図だ。 定性リサーチは「なぜ起きているか」を教えてくれる。定量で見えた現象を持って、実際に顧客に会いに行く。そこで得た「なぜ」を持ち帰り、また定量で検証する。この往復運動が、顧客理解の深度を上げる。 IDEOのティム・ブラウンが強調するのも、このサイクルの重要性だ。インサイトはデータと人間経験の交差点から生まれる——これがIDEOの一貫した立場だ。どちらか一方だけでは、錯覚は生まれやすい。 やってみよう：30分の共感ウォーム・アップ チームのミーティング冒頭30分を使う「顧客文脈マップ」を試してほしい。 ホワイトボードを4つのエリアに分ける——「やっていること」「気にしていること」「感じていること」「言っていること」。そこに、今週実際に顧客と接触した内容のみをポストイットで貼っていく。推測も、3ヶ月前のインタビュー記憶も、禁止だ。 30分後、空白のエリアが顧客理解の盲点だ。「感情」エリアが空なら、チームは行動を見ているが内面を見ていない。「発言」エリアが空なら、今週誰も顧客と話していない——ということが可視化される。 特にこんなチームに試してほしい - 新規事業の立ち上げフェーズにあり、ペルソナをデータだけで作成している - 「ユーザーインタビュー」を年1回の定例作業として位置づけている - 顧客から「そんなことは言っていない」「使いにくい」というフィードバックが繰り返し来ている - 社内の「顧客像」についてチームメンバー間で認識がバラバラになっている 顧客理解の錯覚は、怠慢から生まれない。忙しさの中で手元にあるデータに頼ることは、合理的な判断に見える。ただ、その「合理的な判断」が積み重なった先に、市場ニーズの欠如という30%の失敗がある。 72%の企業が「理解している」と言う。その自信のまま、新規事業は動く。そして10%だけが黒字化する。デザイン思考の共感フェーズが促すのは、この構造への処方箋——出かけること、それだけだ。 --- 参考 - CULUMU, 「新規事業開発における顧客理解実態調査」, 2025年12月 - Tim Brown, Change by Design, HarperBusiness, 2009 - d.school, "Design Thinking Bootleg", Stanford d.school, 2018 - IDEO, "Design Thinking for Educators Toolkit" (2nd ed.), IDEO LLC, 2012 - Clayton Christensen, "The Innovator's Dilemma", Harvard Business Review Press, 1997 --- ### 公共部門デザイン思考の組織モデル——18F閉鎖・MindLab閉鎖・Policy Lab継続から学ぶこと URL: https://designthinking.studio/articles/design-thinking-public-sector-organizations/ > 米国18F(2025年2月閉鎖)、デンマークMindLab(2018年閉鎖)、英国Policy Lab(継続)、デジタル庁(発足)。公共部門のデザイン思考組織が「設立→運営→閉鎖/存続」を分かつ要因を、4機関の興亡から構造的に読み解く。 公共部門のデザイン思考組織は、設立されては閉じる。世界で最も体系的に運営されていた組織の一つ、米国18Fは2025年2月28日に閉鎖された。デンマークMindLabは2018年5月に16年の歴史を閉じた。一方、英国Policy Labは2020年に管轄省庁を変えながらも10年以上継続している。日本のデジタル庁は2021年9月に発足したばかりだ。 「なぜある組織は閉じ、ある組織は続くのか。」 この問いは、公共部門でデザイン思考を機能させようとする者にとって最も実践的な問いである。本稿は4機関の組織モデルを並列に分析し、生存と閉鎖を分けた構造的要因を抽出する。 18F——10年で閉じた米国政府のデザインユニット 設立(2014年) 18Fは2014年3月、米国一般調達局(GSA)内の組織として設立された。名称は、GSAのワシントンD.C.本部の住所「18th and F Streets NW」に由来する。 設立の直接的な契機は、2013年10月のHealthcare.gov(医療保険交換所サービス)の機能不全だった。数億ドルを投じたシステムが、開設初日からユーザーがログインすらできない状態に陥った。この失敗の原因として分析されたのが、民間で標準化されていたユーザー中心設計の手法が政府の調達プロセスから完全に欠落していたことだった。 18Fの設立趣旨は明確だった。シリコンバレーのテクノロジー企業からエンジニア・デザイナー・プロダクトマネージャーを政府の内製人材として雇用し、各省庁のデジタルサービス再設計を支援する。つまり政府内部にデザイン思考の実行能力を埋め込むという構造だった。 主な実績 設立から10年間、18Fは複数の象徴的なプロジェクトを担った。なかでも国税庁(IRS)の Direct File プログラム(納税者が無料で直接電子申告できるサービス)の立ち上げ支援は、その代表例である。従来は民間税務ソフトを介さなければ電子申告できなかった構造を、ユーザーリサーチに基づいて再設計した。 ほかにも、調達プロセスのモダン化、複数省庁のサービスデザインガイド整備、オープンソース基盤の構築など、18Fは「政府内コンサルティングユニット」として横断的に機能した。 閉鎖(2025年2月) しかし2025年2月28日、GSAは18Fの閉鎖を発表した。約85名の職員全員が解雇された。閉鎖は金曜深夜のメール通知のみで行われ、詳細な説明はなかった。 GSA調達サービス局長の説明によれば「政権の労働力最適化命令に沿って、非必須コンサルティング機能を削減する一環」とされた。元職員80名は連邦人事保護委員会に集団控訴を提出し、「不当な対象化」を主張している。 18Fの構造的特徴と脆弱性 18Fの組織モデルには2つの致命的な脆弱性があった。 第一に、政治的中立性のための独立組織でありながら、行政府(大統領府)の意向に直接左右される位置にあったことだ。議会の承認を経た恒久組織ではなく、行政命令ベースで設立された組織だったため、政権交代と政策方針の変更で簡単に閉鎖できる構造だった。 第二に、「コンサルティングユニット」としての位置づけが、平時には正当化されにくかったことだ。Healthcare.govのような危機時には不可欠とされたが、危機が遠ざかると「内製化された外注」として削減対象になった。 MindLab——16年で閉じたデンマークの先駆者 設立(2002年)から閉鎖(2018年)まで MindLabは2002年、デンマークの経済省・労働省・教育省が共同出資する形で設立された、世界初の政府公認デザイン思考ユニットの一つである。失業給付申請プロセスのワンストップ化、教育サービスの再設計、起業支援プロセスの簡素化など、複数の省庁横断プロジェクトを主導した。 しかし2018年5月1日、MindLabは閉鎖された。閉鎖の直接要因は、デンマーク政府の優先順位が「実験と革新」から「行政のデジタルトランスフォーメーション」へとシフトしたことだった。後継として設立されたのが Disruption Task Force(破壊的革新タスクフォース)で、デザイン思考のワークショップ手法より、技術ベースの行政改革に重点を置いた。 MindLabの構造的特徴と脆弱性 MindLabは18Fよりも長く存続したが、共通する脆弱性を持っていた。 第一に、複数省庁の共同出資という「主体不在」のガバナンス構造である。経済省・労働省・教育省のいずれが「自分たちの組織」と認識するかは時期によって変動し、強い擁護者が政権内に常時存在しない構造だった。 第二に、成果の可視化が困難だった。デザイン思考の効果は「申請者の体験改善」「満足度向上」など定性的指標で測られることが多く、コスト削減や処理件数のような定量指標を求める政策担当者から見ると「具体的に何を生んでいるか」が見えにくかった。 UK Policy Lab——継続している組織 設立(2014年)と省庁移管(2020年) UK Policy Labは2014年、英国Cabinet Office内に設立された。MindLabや18Fと同時期の発足である。設立趣旨は「エビデンス・デザイン・人々の声を政策立案に持ち込む」ことだった。 注目すべきは、Policy Labが2020年にCabinet OfficeからDepartment for Education(教育省)へ移管されたことだ。所属省庁を変えながら組織として存続するという、18FやMindLabとは異なる進化経路を辿った。2024年7月には設立10周年を迎え、新たな運営方針(prospectus)を発表している。 Policy Lab継続の構造的要因 なぜPolicy Labは閉鎖されず、移管によって生き延びたのか。3つの構造的要因が観察できる。 第一に、「政策デザインの方法論」を組織のコアに据えたことだ。プロジェクト実行よりも「他省庁が政策をデザインするための手法」を提供することを軸にしたため、いずれの省庁にとっても汎用的な価値を提供できた。 第二に、実績を「公開可能なケーススタディ」として継続的に蓄積したことだ。Policy Labの公式ブログ(openpolicy.blog.gov.uk)には、各プロジェクトの手法・観察・成果が公開されている。これにより組織の正当性が文書として外部に蓄積され、政権交代があっても「閉鎖の社会的コスト」が高まる構造を作った。 第三に、省庁内の階層を低くし、政治任用ポストを増やさなかったことだ。少人数のコアチームと外部パートナーによる柔軟な運営構造を保ったため、「縮小は容易だが完全閉鎖は難しい」サイズを維持した。 デジタル庁——日本の発足期組織 発足(2021年9月) デジタル庁は2021年9月、菅内閣のもとで発足した。マイナンバー普及・行政手続きオンライン化・自治体システム標準化という複合的なミッションを担う。 初期段階から外部のUXデザイナー・リサーチャー・エンジニアを積極採用し、「ユーザー中心設計原則」(2022年公表)を行政サービス設計の基準として位置付けた。これは英国GDS(Government Digital Service)の「Design Principles」を参考にした構造である。 組織モデル上の特徴 デジタル庁は18Fやデジタル庁の前身組織群と比較して、省庁ではなく省庁横断の調整機能として位置づけられた点が特徴である。各省庁のシステム調達基準を作る権限を持ち、単なる「内製コンサル」ではなくガバナンスの中心として設計された。 これは18Fの脆弱性(内製コンサルとしての位置づけが平時に削減対象になる)を構造的に回避する設計と読める。一方で、ガバナンス機能を持つことは政治的注目度を高め、批判の集中砲火を受けやすい構造でもある。 4機関の比較から抽出される生存要因 | 機関 | 設立 | 閉鎖/継続 | 期間 | 主な脆弱性/強み | |------|------|-----------|------|----------------| | MindLab(丹) | 2002 | 2018閉鎖 | 16年 | 複数省庁出資=主体不在/成果可視化困難 | | 18F(米) | 2014 | 2025閉鎖 | 11年 | 行政命令ベース設立=政権交代で閉鎖容易 | | Policy Lab(英) | 2014 | 継続中 | 11年+ | 省庁移管で生存/方法論の汎用化/実績の公開蓄積 | | デジタル庁(日) | 2021 | 発足期 | 4年 | 省庁横断ガバナンス権限を持つ | この比較から、公共部門デザイン思考組織の生存要因として4つの構造が読み取れる。 - 法的根拠の強さ——行政命令ベース(18F)よりも法定設置(デジタル庁)、共同出資(MindLab)よりも単一管轄(Policy Lab移管後)が強い。 - 価値の汎用化——特定プロジェクトの実行(18Fの一部機能)よりも、他組織が使える方法論の提供(Policy Lab)の方が継続性を保ちやすい。 - 成果の文書化と公開——内部報告で完結させず、外部公開されるケーススタディとして蓄積することが、閉鎖の社会的コストを高める。 - 適切なサイズ——大規模組織は政治的標的になりやすく、極小規模は影響力が出ない。Policy Labのようなコアチーム+外部パートナー型が長期生存に有利な可能性がある。 まとめ——「組織として続く」設計 公共部門にデザイン思考を持ち込むとき、最初の関心は「どう導入するか」だが、より重要な問いは「どう続くか」だ。設立は意気込みで可能だが、継続は構造で決まる。 18Fの閉鎖は、政治変動に対する脆弱性の象徴である。MindLabの閉鎖は、優先順位の変動に対する脆弱性の象徴である。一方、Policy Labの継続は省庁移管という柔軟性、方法論の汎用化、実績の公開蓄積の3つが組み合わさった結果と読める。 日本のデジタル庁は発足期にあり、これからその構造的強度が試される。法定設置・省庁横断ガバナンス・「ユーザー中心設計原則」の公開という3点で、18FやMindLabが持っていなかった強みを内蔵している。一方、政治的注目度の高さは両刃の剣である。 公共部門でデザイン思考を機能させたいなら、ワークショップの設計より先に、組織が10年・20年残るための構造設計を考えるべきだ。それが、閉鎖された18FとMindLabが私たちに残した教訓である。 関連記事として、行政サービスにおけるデザイン思考の活用事例では、各機関のプロジェクトレベルの成果に焦点を当てている。本稿と併せて読むと、プロジェクト視点と組織視点の両面から公共部門デザイン思考の全体像が見える。 --- 参考文献 - "After rocky history, GSA shuts down 18F office," Federal News Network, 2025年3月 - "GSA shutters 18F, possibly leaving agencies in the lurch," FedScoop, 2025年3月 - "How Denmark lost its MindLab: the inside story," Apolitical, 2018年 - "MindLab 2002-2018: How the legacy lives on," Apolitical, 2018年 - Policy Lab公式ブログ, openpolicy.blog.gov.uk - "Evolution of policy labs and use of design for policy in UK government," Policy Design and Practice, Taylor & Francis, 2021 - デジタル庁, 「ユーザー中心設計原則」, 2022年 --- ### 行政サービスにおけるデザイン思考の活用事例 URL: https://designthinking.studio/articles/design-thinking-public-sector/ > 英国GDS・米国USDS・デンマーク自治体・日本の行政DX事例を通じ、市民参加型のサービスデザインがどう機能するかを解説。200回以上のワークショップ観察から見えた公共部門固有の課題と突破口。 行政サービスにデザイン思考が持ち込まれるとき、最初の抵抗はほぼ決まっています。「民間企業と違って我々には制約がある」「法律があるのでユーザー中心で設計できない」「前例がないものは承認されない」。この反応は世界中の公共部門で観察されるパターンです。 しかし この反応自体が「問題定義の失敗」を示しています。 デザイン思考は制約を無視する方法論ではなく、制約の中でユーザーの本質的なニーズを満たす解を見つける方法論です。制約は「与件」として受け入れながら、その中で最も市民に寄り添えるサービスを設計することは可能です。実際にそれを証明した事例が、世界各地に存在します。 英国：Government Digital Service（GDS）の革命 背景：£1億2,000万の失敗 2011年、英国政府は内部報告書「Maude Report」の中で、政府のデジタルプロジェクトが繰り返し遅延・予算超過・ユーザーから乖離した結果に終わっている実態を認めました。その象徴が「Universal Credit」のシステム開発で、当初予算の数倍のコストが発生していました。 この反省から2011年に設立されたのが Government Digital Service（GDS） です。GDSのミッションは「インターネット時代に見合った政府サービスをデジタルで提供すること」でしたが、その手法の核心は ユーザーリサーチに基づく反復的な設計 でした。 GOV.UKの再設計プロセス GDSが最初に取り組んだのは、700以上の政府ウェブサイトをひとつの統一プラットフォーム「GOV.UK」に統合することでした。このプロセスでデザイン思考が機能した方法は具体的です。 共感フェーズでは、GDSのユーザーリサーチャーが市民と毎週2回の対面インタビューを実施しました。「払い戻し請求書をどこから見つけるか」「運転免許更新のフローがどこで詰まるか」——生活の中で政府サービスを使う具体的なシーンを観察しました。特に低所得者・高齢者・デジタルリテラシーの低い市民への観察を意図的に優先しました。 問題定義フェーズでは、「政府のすべての情報をウェブに掲載する」という従来の発想を「市民が特定の目的を果たせるように設計する」という転換を行いました。 「政府が何を伝えたいか」ではなく「市民が何を達成したいか」を起点にした この転換が、GOV.UKのUXを根本から変えました。 設計原則の公開：GDSは「Design Principles」（10原則）を公開し、これをすべての開発の判断基準にしました。「Start with user needs（ユーザーのニーズから始める）」「Do less（より少なくする）」「Design with data（データで設計する）」などがその内容です。この原則の公開は、GDSの外部の政府機関にも影響を与えました。 成果と数字 GOV.UK移行後のデータでは、主要なトランザクション（運転免許更新・納税・給付申請）の完了率が移行前と比べて15〜30%向上したことが報告されています。ユーザー満足度（SUS: System Usability Scale）でも、旧来の個別サイトを大幅に上回りました。 より重要なのは、 GDSのアプローチが「政府のサービス設計方法」として他国に輸出された ことです。オーストラリア・カナダ・ニュージーランド・シンガポールなどの政府がGDSの設計原則を採用し、自国版のデジタルサービス機関を設立しました。 米国：USDS（U.S. Digital Service）の実践 Healthcare.govの教訓 2013年10月、米国の医療保険交換所サービス「Healthcare.gov」がオープン当日から機能不全に陥りました。数億ドルを投じたシステムが、ユーザーがログインすらできない状態でした。この失敗の根本原因として分析されたのは、 エンジニアリングとシステム統合に集中し、実際のユーザーがどう使うかのテストがほぼ行われなかった ことでした。 この失敗を受けて、オバマ政権は2014年に U.S. Digital Service（USDS） を設立しました。シリコンバレーのテクノロジー企業からエンジニア・デザイナー・プロダクトマネージャーを短期雇用し、機能不全に陥った政府システムの再設計に投入するという、前例のない組織です。 移民サービスの再設計 USDSが取り組んだ事例の一つが、移民帰化局（USCIS）のオンライン申請システム「myUSCIS」の再設計です。従来のシステムは、ユーザー（主に移民・難民）が必要な書類・申請フロー・期限を理解するうえで、極めて使いにくい状態でした。 USDSのチームが最初に行ったのは 実際の申請者へのインタビュー です。移民コミュニティのNPOと協力し、英語が母語でないユーザー・デジタルリテラシーの低いユーザーを優先してリサーチしました。 発見された中核的な問題は「情報設計の失敗」でした。申請者が「今自分がどこにいて、次に何をすべきか」がシステム上から判断できない構造でした。 「ユーザーは頭がいい。システムが複雑なのであって、ユーザーが複雑なのではない」 というUSDSの基本姿勢が、設計方針を変えました。 再設計後のシステムでは申請完了率が向上し、コールセンターへの問い合わせが20%以上削減されたことが内部報告で示されました。 デンマーク：Mindlab と市民参加型設計 デンマークは公共部門のデザイン思考導入において、最も体系的な取り組みを行った国の一つです。2002年に設立された MindLab は、複数の省庁（経済省・労働省・教育省）が共同出資したイノベーションユニットで、デザイン思考を公共サービス設計の標準的な方法として確立しました。 失業給付申請のサービス設計 MindLabが手がけた事例として広く参照されるのが、失業給付申請プロセスの再設計です。当時の申請プロセスは、失業者が膨大な書類を複数の窓口に別々に提出する構造でした。 MindLabのチームは、実際に失業した市民に同行して 「申請の旅（Service Journey）」 を観察しました。書類を準備する段階からハローワーク窓口での手続き・給付開始まで、ユーザーが経験する全ての接触点を可視化しました（サービスブループリントに近い手法です）。 観察から浮かび上がったのは、 「申請者が何度も同じ情報を異なる窓口に提出する」という構造的な問題 でした。この非効率は行政内部の縦割り組織構造を反映したものでしたが、市民の視点からは無意味な負担です。 再設計では「ワンストップ申請」が実現され、申請者の接触回数が大幅に削減されました。MindLabのアプローチは、 「市民の体験を中心に組織の壁を超える」 という、公共部門では最も難しいことを、ビジュアルな体験マッピングによって実現したものです。 日本の行政DXとデザイン思考 デジタル庁の取り組み 2021年9月に発足した デジタル庁 は、マイナンバーカード・ワクチン接種記録・行政手続きのオンライン化という課題に取り組んでいます。初期のウェブサービス設計では「ユーザー中心設計原則」を採用し、外部のUXデザイナーやリサーチャーを採用しました。 具体的な事例として ワクチン接種記録システム（VRS）の設計 があります。接種会場での記録プロセスを、医療従事者・自治体担当者・市民という複数のユーザー視点から設計する必要がありましたが、異なるユーザーの文脈を統合する設計は典型的なデザイン思考の問いです。 神戸市のスタートアップとの協働 神戸市は2017年から「Urban Innovation KOBE」として、市の現場課題をスタートアップと協働で解決するプログラムを運営しています。このプログラムの特徴は、 市の職員（現場担当者）とスタートアップが共同チームとして課題を定義し、解決策を開発する という、デザイン思考のチーム設計に近い構造です。 このプログラムが生んだ成果の一つが、空き家管理の効率化ソリューションです。現場の担当職員が「実際にどこで詰まっているか」を起点に課題定義が行われ、ITツールが設計されました。 「現場のユーザー（職員）が問題を定義する」という構造 が、従来の「IT部門が要件を定義してベンダーが作る」プロセスとは根本的に異なります。 公共部門固有の課題と突破口 失敗への許容度の違い 民間企業と行政の最大の違いは、 失敗への社会的・政治的コスト です。民間でのプロトタイプの失敗は学習です。行政での失敗は税金の無駄遣いとして批判されます。 この文化的制約の中でデザイン思考を機能させるには、 「実験」という言葉より「パイロット（試行）」という言葉の方が受け入れられやすい という観察があります。「小規模な試行→学習→展開」というフレームを使うことで、反復的な改善プロセスを行政内部で正当化しやすくなります。 「ユーザー」の複雑性 行政サービスのユーザーは均質ではありません。高齢者・障害者・外国人・低所得者——多様な属性のユーザーが同じサービスを使います。民間サービスの「ペルソナ設計」とは異なり、 特定のペルソナを想定した最適化が他のユーザーを排除しないように設計する 必要があります。 GDSが「Assisted Digital」（デジタルサービスを使えない人への支援）を設計原則に組み込んだのは、この問題への回答です。 「最もデジタルリテラシーの低いユーザーが使えるか」を基準にすることで、すべてのユーザーにとって使いやすいサービスが生まれる という原則です。 利害関係者の多さ 行政プロジェクトのステークホルダーは、市民・議会・他の省庁・委託ベンダー・労働組合・マスメディアと、民間の比ではなく複雑です。デザイン思考のプロトタイプとテストのプロセスを、すべてのステークホルダーに透明に見せながら進めることが、後の政治的な問題を防ぎます。 GDSが「Design in the Open」（設計を公開する）というアプローチを採用したのは、この理由です。ブログ・GitHubでのコード公開・週次の進捗報告を通じて、設計プロセスをブラックボックスにしないことで、政治的な信頼を維持しました。 まとめ：公共部門でのデザイン思考の本質 行政サービスへのデザイン思考導入が成功する共通要因は3つあります。まず 「ユーザーリサーチを最優先にする」という明確なコミットメント です。「市民に会いに行く」ことをプロジェクトの初期から継続的に行います。 次に 「小さく試す」という許可を組織から得ること です。パイロットプロジェクト・試行期間・限定的な展開——これらのフレームを使って、反復的な改善のサイクルを制度的に可能にします。 最後に 「設計を透明にする」というコミットメント です。プロセスを公開することで、市民・議会・他のステークホルダーとの信頼を構築しながら前進できます。 制約は実在します。しかしその制約の中で、市民の生活に最も寄り添うサービスを探し続けることが、行政サービスにおけるデザイン思考の本質的な問いです。 --- 参考文献 - Mike Bracken, "Design in government," Government Digital Service Blog, GOV.UK, 2013 - U.S. Digital Service, USDS Annual Report 2016, The White House, 2016 - Christian Bason, Leading Public Sector Innovation: Co-creating for a Better Society, Policy Press, 2010 - Ezra Golberstein et al., "Healthcare.gov and the ACA: Building a Better Health Insurance Marketplace," Health Affairs, 34(3), 2015 - デジタル庁, 「デジタル社会の実現に向けた重点計画」, 内閣府, 2022 --- ### 自動車・モビリティ業界にデザイン思考を実装する——「所有」から「体験」への価値転換 URL: https://designthinking.studio/articles/design-thinking-automotive-mobility-transformation/ > EV化と自動運転レベル3-4移行、MaaS化が進む中、性能スペックによる差別化が効かなくなった自動車業界にデザイン思考をどう実装するか。ジャーニーの再定義、信頼構築の共感設計、実践パターンを解説する。 新型EVの航続距離は競合に劣っていない。加速性能も安全性能評価も申し分ない。それなのに、なぜか選ばれない——商品企画会議でこの手のモヤモヤを口にしたことのある担当者は、決して少なくないはずだ。 スペック表を見比べる限り「勝っている」はずの製品が、市場では「選ばれない」。この矛盾を説明しようとすると、たいてい「ブランド力」や「マーケティングの差」で片付けられてしまう。だが本当にそれだけだろうか。性能の優位性と、選ばれることは、そもそも別の問題なのではないか。その問いを、デザイン思考の枠組みで捉え直してみる。 なぜ自動車業界で「性能」から「体験」への転換が急務なのか 自動車という商品の差別化軸が、ここ数年で急速に薄れてきた。 EVの普及によって、内燃機関時代に培われた「エンジンフィール」「変速の滑らかさ」といった性能差は、もう意味をなさない。パワートレインの基本構造がシンプルになったぶん、航続距離や加速性能の差も縮まりやすい。自動運転支援機能（車線維持・自動ブレーキ・駐車支援など）も、いまや多くのメーカーで標準搭載に近い（各社の搭載レベル・機能範囲は要確認）。かつては「上位グレードだけの特別な体験」だった機能が、いつのまにか当たり前の前提に変わった。 同時に、MaaS（Mobility as a Service）やカーシェアリング、サブスクリプション型の利用形態が広がったことで、「車を所有する」という前提そのものが相対化されている。ユーザーにとって車は「買って所有し続けるもの」から「必要なときに使うサービス」へと、少なくとも一部の利用シーンでは、すでに移行しつつある。 この状況で、商品企画のプロセスが依然として「スペック表を起点に、購入前から納車までの一直線ジャーニー」で設計されたままなら、コモディティ化した性能軸の中に埋もれるだけだ。問うべきは、性能の磨き方ではなく、設計の対象そのものだろう。 デザイン思考で捉え直す移動体験のジャーニー デザイン思考、とりわけカスタマージャーニーマップの手法は、この転換に直接使える道具立てを持っている。ただし、そのまま流用するのではなく、自動車・モビリティ業界に固有の2つの論点を組み込む必要がある。 「一直線ジャーニー」から「反復ジャーニー」へ 従来の自動車のジャーニーマップは、「認知→検討→購入→納車→（長い所有期間）→手放し」という一直線の構造で描かれることが多かった。これは「1台を長く所有する」時代の設計対象としては妥当だった。 しかし、サブスクリプションやシェアリングが利用形態の一部になると、ユーザーは「購入」ではなく「毎回の利用開始」を繰り返す。ジャーニーは一直線ではなく、円環に近い反復構造になる。この場合、デザインの焦点は「購入時にどう感動させるか」ではなく、「毎回の利用がどれだけスムーズで、どれだけ気持ちよく繰り返されるか」に移る。乗るたびに車種や状態が変わりうるシェアリングでは、「毎回のはじめまして」をどう解消するかが、体験設計上の中心課題になる。 自動運転レベル3-4移行期に固有の「信頼構築」という共感対象 自動運転（SAE基準でいうレベル3・レベル4への移行期）には、従来のデザイン思考の共感フェーズが扱ってこなかった、固有の心理的課題がある。ユーザーがシステムをどれだけ信頼するかという軸だ。 信頼が過剰になれば、システムの限界を超えた場面でも運転操作への復帰が遅れる「過信」のリスクが生じる。逆に信頼が不足すれば、便利な機能があっても常にハンドルに手を添え続けてしまい、機能本来の価値を体感できない「過剰警戒」に陥る。どちらも、単純な機能の出来不出来では説明できない、体験設計上の課題だ。 この「信頼のちょうどよい着地点」を探るプロセスは、まさにEmpathizeフェーズが得意とする領域である。ユーザーがどの瞬間に不安を感じ、どの瞬間に安心して手を離せるようになるのか。それを実際の利用場面で観察し、段階的な情報提示やフィードバックのデザインへと落とし込む——地味だが、ここでしか埋まらない差だ。 実践パターン——モビリティ事業者に共通する応用の型 個別企業の成功事例として断定的に語ることは避けたいが（固有の企業名・数値による裏付けは、記事公開前のファクトチェック工程で別途検証される想定）、モビリティ関連の商品・サービス開発の現場で繰り返し見かける場面を、匿名化したうえで具体的に描いておく。 - サブスク型サービスのジャーニー設計：あるカーシェア事業者のユーザーインタビューでは、「アプリの予約画面では快適そうに見えたのに、実際に車の前に立った瞬間に不安になった」という声が繰り返し観察されたという（事業者名・調査時期は要確認）。鍵の受け渡し方法が車種ごとに微妙に違う、保険の適用範囲がその場では分からない——こうした「毎回ゼロから確認し直す」小さな摩擦が、利用開始のたびに積み重なっていた。利用開始のたびに発生する摩擦（車両確認・操作説明・保険確認など）を、初回だけでなく毎回のタッチポイントとして扱い、反復利用に耐える設計に落とし込む発想がここにある。 - 自動運転UXの段階的信頼構築設計：あるレベル3相当の自動運転機能を持つ車両の試乗評価では、機能に慣れるまでの数十分間、ドライバーがメーターパネルに何度も視線を送り、ハンドルに軽く手を添え直す「確認行動」が集中して観察される、という開発現場の報告がある（詳細は要確認）。この確認行動が徐々に減り、シートに深く座り直す姿勢へ変わる瞬間が、「信頼が形成された合図」として扱われているという。機能の作動状況を常に可視化し、システムが「何を見ているか・何をしようとしているか」を過不足なく段階的にユーザーへ伝えるインターフェース設計は、こうした観察の積み重ねから磨かれていく。 - シェアリングサービスにおける共感マッピング：あるMaaS事業者の導入現場では、初回利用者とヘビーユーザーが同じアプリ画面を見ても求める情報がまったく違う、という課題が指摘されている。初回利用者は「この車は本当に安全に運転できるのか」という不安が先に立ち、操作説明や保険の説明を丁寧に求める一方、ヘビーユーザーにとっては同じ説明が「毎回同じことを聞かれる煩わしさ」でしかない（具体的な離脱率等は要確認）。この差を放置すると、初回向けに手厚くするほどリピーターの離脱を招くというジレンマが生じる。「毎回違う車に乗る」という前提を織り込み、初回利用者向けの体験と、リピーター向けの体験を意図的に描き分ける必要が、ここから見えてくる。 これらはいずれも、性能スペックの改善では解決しない、体験設計側の課題である。 まとめ：性能の隣に、体験を並べる 移動体験の主導権を握るのは、もはやエンジン性能や航続距離の数値だけではない。乗る前の期待から、乗っている間の安心感、降りた後の余韻まで——その全体の設計が、すでに選ばれる理由になっている。 次の商品企画レビューで、スペック表の隣に「乗る前〜降りた後までの感情変化マップ」を1枚だけ置いてみる。大がかりな変革はいらない。性能で語れなくなった部分を、体験の言葉で語り直せるかどうか——勝負はそこでもう始まっている。 関連: 製造業のデザイン思考 / カスタマージャーニーマップ実践ガイド / サステナブルプロダクトとデザイン思考 / 行動デザインとBMAP統合 --- 参考文献 - Kalbach, J. Mapping Experiences: A Complete Guide to Creating Value through Journeys, Blueprints, and Diagrams. O'Reilly Media（初版2016、第2版2021。参照版は要確認） - SAE International, J3016: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles（自動運転レベル定義の標準規格。最新改定版、版番号要確認） - Stickdorn, M., Lawrence, A., Hormess, M., & Schneider, J. (2018). This Is Service Design Doing. O'Reilly Media. --- ### 従業員体験ジャーニーのデザイン思考設計｜オンボーディングから離職まで全体を再設計する URL: https://designthinking.studio/articles/design-thinking-employee-experience-journey/ > 採用後の「在職社員の体験」をデザイン思考の5フェーズで設計し直す実践ガイド。オンボーディングの不安・日常業務の摩擦・離職前後のEXを従業員ジャーニーマップで可視化し、介入ポイントを特定する手法を解説する。 「採用に成功した」と思っていたら、半年後に辞表が出てきた——この経験を持つ組織は珍しくない。 採用コストをかけ、内定承諾率を改善しても、入社後の体験が機能していなければ投資は回収できない。多くの組織が「採用の問題」と「入社後の問題」を別々に考えているが、社員が体験しているのは採用から離職まで続く1本のジャーニーだ。 デザイン思考を従業員体験（Employee Experience、以下EX）に適用するとは、この連続した旅を社員の視点から捉え直し、体験の設計に介入することだ。採用プロセスを候補者視点で設計する「人事・採用でのデザイン思考活用」とは出発点が違う。本記事が扱うのは、入社後から退職・アルムナイまでの「在職社員の体験」全体のジャーニー設計だ。 なぜ人事はEXジャーニーを設計できていないのか ワークショップでよく起こるのは、人事担当者に「社員の体験をどう把握していますか」と聞くと、「年次のエンゲージメントサーベイを実施しています」という回答が返ってくることだ。 サーベイは「平均値の数値」を返す。しかしオンボーディング中の新入社員と、10年勤務のマネージャーが同じスコアで語られることへの違和感を、現場の社員は感じている。エンゲージメントスコアが「4」であることは、「どの瞬間に、どんな感情で、何を考えていたか」を教えてくれない。 もう一つのよくある状況は、部門ごとに「自分の接点」しか見えていないことだ。人事部門は入社手続き・研修・評価制度を管理する。ITは端末調達とシステムアクセスを担当する。配属先のマネージャーは業務の引き渡しを行う。社員が体験するオンボーディングは、これらの接点が連続している1つの旅だが、それを全体として設計している担当者はほぼ存在しない。 カスタマージャーニーマップが顧客の旅を1枚に統合するように、EXジャーニーマップは社員の旅を統合する地図だ。 従業員ジャーニーの構造を理解する EXジャーニーには5つのステージがある。ステージごとに、社員の頭を占めている「問い」が変わる。 ステージ1：オンボーディング（入社〜90日） 「私はここに属しているのか」「この組織でどう動けばいいか」という帰属と理解の問いが支配する。不安が最も高く、印象の固定が最も速い期間だ。 ステージ2：立ち上がり（3〜12ヶ月） 「自分の仕事は組織の中でどう位置づけられているか」「成長できているか」という貢献と成長の問いが中心になる。初期の高揚が現実と接触する時期でもある。 ステージ3：定着・日常（1年〜） 日常業務の摩擦が蓄積する時期だ。大きなイベントはないが、「なぜこんなに非効率なのか」「評価されている実感がない」という小さな失望が積み重なる。 ステージ4：転機 昇進・異動・育児休暇・リモートへの移行・チーム解散などの転機が体験を揺るがす。組織への期待と現実のギャップが再び露出する。 ステージ5：離職前後 退職を決意してから、退職まで、そしてアルムナイとして組織と関わり続ける期間。退職理由のリアルは、在籍中には語られにくい。 共感フェーズ：社員の旅を追う現場調査 インタビュー設計：「体験の時系列」を引き出す エンゲージメントサーベイとは異なる情報が必要だ。インタビューの目標は、「あのとき、どんな気持ちで、何を考えていたか」という感情と認知の再構築だ。 聞くべき問いは「あなたの仕事で何が不満ですか」ではない。「入社から今日まで、もっともよかった日のことを教えてください」「反対に、一番つらかった日は」という感情のピークを軸にした問いから入る。感情の高低を体験者に語らせると、数値調査では見えない「体験の文脈」が出てくる。 特に価値があるのは、退職者インタビューだ。在籍中には「組織への批判」として言語化されにくい体験が、退職後には率直に語られる。退職後3ヶ月以内にアポを取り、「最終的にどんな体験が離職の背景にありましたか」と聞く。承諾率は高くないが、承諾してくれた相手の語りには、組織が見えていなかった体験の構造が凝縮されている。 実際にやってみると、「給与が低かったから」という表面的な理由の裏に、「自分の仕事が評価されていないという感覚が3年続いた」という体験の蓄積が出てくる。給与は最後の引き金で、本当の問題は別の場所にあった。このズレこそが、EX設計の改善ポイントだ。 観察：社員の一日を歩く インタビューだけでは見えない「日常の摩擦」を捉えるために、シャドーイングを使う。対象社員の1日に同行し、業務の流れを観察する。 ワークショップでよく起こるのは、「申請書類の承認に何人のハンコが必要か」「どのシステムに何回ログインするか」「会議のどの瞬間に参加者の表情が曇るか」が、事後インタビューでは語られないことだ。摩擦は「当たり前」になっていると、当人には見えなくなる。「これが普通だと思っていたけど、言われてみると確かに面倒ですね」という言葉が出てくると、シャドーイングは成功している。 リモートワーク環境では、1日の業務を画面共有で観察する「デジタルシャドーイング」が機能する。どのツールを行き来するか、どのやりとりで返信が止まるか——業務の流れが可視化される。 定義フェーズ：EXジャーニーマップを描く 収集した情報を「従業員ジャーニーマップ」として構造化する。 ジャーニーマップの基本構造 縦軸には「ステージ」、横軸には時間軸（入社→定着→離職）を置く。各ステージの行には以下の要素を記載する。 - タッチポイント：組織と社員が接する接点（研修・1on1・評価面談・オンラインツール等） - 社員の行動：各タッチポイントで何をしているか - 社員の思考：そのとき何を考えているか - 感情曲線：ポジティブ／ネガティブのスコア - ペインポイント：体験の問題点 - 介入機会：設計で変えられる余地 感情曲線が示すもの 感情曲線の谷（体験のボトム）が、最初に介入すべき場所を教えてくれる。 多くの組織でオンボーディング調査をすると、感情曲線は「入社1週目に高く、3〜6週目に急落する」パターンを示す。入社初日は歓迎されて嬉しい。しかし2週目以降、「実際の業務フロー」「暗黙のルール」「期待値の差」に直面して感情が落ちる。この谷は「放置」ではなく「設計で改善できる体験の問題」だ。 感情曲線のピーク（最もポジティブな体験）も同様に重要だ。「あのプロジェクトが終わったとき」「チームで乗り越えたあの時期」——ポジティブのピークを作る条件を理解することで、意図的にその体験を増やす設計が可能になる。 How Might We でインサイトを問いに変換する 定義フェーズの成果は「課題の記述」ではなく「How Might We（HMW）の問い」として表現する。 課題の記述: 「オンボーディング3週目に感情が急落する」 HMW: 「どうすれば、社員が入社3週目に『自分はここでやっていける』という手応えを感じられるか」 課題の記述は問題を記録するだけだ。HMWに変換した瞬間に、次のアイデア出しが始まる。 発想フェーズ：介入アイデアを発散させる EXジャーニーの各ペインポイントに対して、発想セッションを開く。ここでは「人事部門が単独で解決する施策」ではなく「社員が体験する接点全体を変える設計」を発想させることが重要だ。 ワークショップでよく起こるのは、人事担当者だけのセッションでは「評価制度の改善」「研修の充実」という既存施策の延長アイデアしか出ないことだ。IT担当・マネージャー・新入社員・中途採用者を混在させたセッションにすると、「入社前日に端末が届いていれば、初日の緊張が少し減った」「1on1で上司が話し過ぎず、自分が話せる時間があれば違った」という体験からの具体的なアイデアが出てくる。 発散したアイデアを「インパクト×実装コスト」の2軸で評価し、優先度を絞る。「小さな変更で大きな体験改善が期待できるアイデア」が最初のプロトタイプ候補だ。 プロトタイプフェーズ：体験の小さな実験 EXの改善施策は、大きな制度変更より「小さな体験実験」から始める。プロトタイプは低コストで速く作ることが原則だ。 オンボーディングのプロトタイプ例 「入社3週目の感情急落」に介入するプロトタイプとして、ある組織が試したのは「30日チェックイン」だ。入社から30日後に、マネージャーではなくHR担当者が1対1で「今、どんな気持ちですか」とだけ聞く30分の面談。評価でも報告でもない、ただ聞くだけの接点だ。 実際にやってみると、この30分で「誰にも言えなかった」小さな困惑が出てくる。「社内の用語が分からなくて会議で発言できなかった」「どこに誰に聞けばいいか分からなかった」——これらは業務評価では現れない体験のノイズだが、放置すると感情曲線の谷を深くする。 30日チェックインは制度化ではなく、まず「次の新入社員3名に試す」形で始められる。費用はほぼゼロだ。 日常EXのプロトタイプ例 日常業務の摩擦に対する介入として有効なのは「摩擦ログ」だ。参加する社員に1週間、「業務中に『面倒だな』と思った瞬間を記録するメモ帳」を渡す。日次で3〜5件、ただメモするだけ。 実際にやってみると、「社内申請フォームのフィールドの意味が分からなくて止まった」「定例会議の目的が不明で何を準備すればいいか毎回迷う」という、IT改善や会議設計で解決できる具体的な摩擦が集まる。問題を発見するプロトタイプとしての摩擦ログは、シャドーイングより低コストで横断的なデータが集まる。 リモートEXのプロトタイプ例 リモートワーク環境では、「偶発的な接触」が設計されていないことが最大の体験問題になることがある。対面オフィスなら廊下ですれ違いに情報が流れるが、リモートではそれが消える。 ある組織が試したのは「バーチャルコーヒー」だ。週1回、ランダムにマッチングされた2名が15分のカジュアル通話をする仕組み。業務と無関係な話でよい。導入直後は「仕事と関係ない」という抵抗があった。しかし3ヶ月後に感情曲線を再測定すると、「組織に知り合いが増えた」「誰に何を聞けばいいか分かった」という感覚の向上が数字に表れた。 実装コストは低く、既存ツール（Slack・Teams）の機能で実現できる。 テストフェーズ：体験改善を測定する EXのプロトタイプはどう測定するか。大きな制度変更と違い、小さな体験実験は「学習のための測定」が目的だ。 定量指標の候補： - オンボーディング期間中の感情スコア変化（月次） - 90日・180日・365日時点のリテンション率 - 定着期の欠勤率・有給消化率 - 離職者の申告理由の変化 定性指標の候補： - 30日チェックインで語られたペインポイントの変化 - 摩擦ログに記録された問題の件数と内容 - 退職者インタビューで語られる離職の文脈 「数字が動く前に感情が動く」——これはEX実践者の間でよく言われる観察だ。プロトタイプを始めて2週間では離職率は変わらない。しかし「組織に聞いてもらえた感覚がある」「以前より話せる相手が増えた」という感情の変化は、ずっと早く現れる。定性情報を先に拾うことで、施策の方向性を早期に修正できる。 測定したら、次のイテレーションへ。EXの設計は一度完成するものではなく、「体験の仮説→実験→学習→修正」のサイクルを回し続ける実践だ。 やってみよう：今週始められる3つの介入 - 自社のEXジャーニーを30分で仮説として描く 紙とペンで構わない。横軸に「入社→定着→転機→離職」を置き、縦軸に「感情スコア（+5〜-5）」を設定する。自分が知っている範囲で感情曲線を引いてみる。これが仮説のジャーニーマップだ。 「知らない区間」が最もリスクの高い区間だ。ここが次のインタビュー対象になる。 - 入社6ヶ月以内の社員3名にインタビューを申し込む 30〜45分、業務評価とは切り離した場として設定する。問いは一つだけで十分だ。「入社してから今日まで、もっとも『ここでよかった』と感じた瞬間と、もっとも『つらかった』と感じた瞬間を教えてください」。 評価の場ではないことを最初に伝える。答えを誘導せず、感情の記憶を引き出す。このインタビュー3本が、自社のEXジャーニーの最初のリサーチデータになる。 - 直近の退職者1名にアルムナイインタビューを打診する 退職後3ヶ月以内が望ましい。「在籍中の体験について聞かせてほしい」という目的で依頼する。断られることもある。それでも依頼する価値はある。承諾してくれた1名の語りは、エンゲージメントサーベイ1000件分のデータが拾えない「体験の解像度」を持っている。 --- 参考文献 - Jacob Morgan, The Employee Experience Advantage, Wiley, 2017 - Denise Lee Yohn, "Design Your Employee Experience as Thoughtfully as You Design Your Customer Experience," Harvard Business Review, 2016 - Jeanne Meister & Karie Willyerd, The 2020 Workplace, HarperBusiness, 2010 - Nielsen Norman Group, "Intranet Design Annual 2023," nngroup.com, 2023 - Josh Bersin, "The Employee Experience: It's Trickier (and more important) Than You Thought," joshbersin.com, 2019 --- ### 小売CXへのデザイン思考適用——店舗・EC・アプリを貫通する体験設計 URL: https://designthinking.studio/articles/design-thinking-retail-cx/ > ユニクロ・ZARA・Sephora等のオムニチャネル小売事例から学ぶ、デザイン思考による顧客体験設計。店舗観察からEC導線、アプリ体験を統合するプロセスを実践的に解説する。 小売の現場でワークショップをすると、よくこういう状況に出くわす。EC担当者とアプリ担当者と店舗担当者が同じ会議室にいるのに、お互いが顧客のどんな体験を担当しているか、ほとんど把握していない。 「うちのチャネル」の最適化はしているのに、「顧客のジャーニー全体」は誰も見ていない。 この状態で各チャネルを個別に改善しても、顧客は混乱する。オンラインでサイズを確認して店舗に行ったのに在庫情報が違う。アプリでポイントをためているのに店舗で使い方を聞かれた瞬間にスタッフが答えられない。顧客は「ブランド」として体験しているのに、企業は「チャネル」として運営している。この認識のズレを埋めることが、小売CXにおけるデザイン思考の出発点だ。 なぜ小売CXでデザイン思考が機能するのか 小売は「観察できる体験の宝庫」だ。ヘルスケアや金融に比べて、顧客の行動が物理的に見える。どの商品を手に取り、どのタイミングで戻し、何秒間タグを見るか——店舗は天然のフィールドリサーチ環境として機能する。 同時に、小売は「チャネルの断絶」が最も鋭く体験される領域でもある。顧客が「このブランドが好き」と感じる体験は一本の線として記憶されるが、その線を構成する接点は店舗・EC・アプリ・SNS・メール・カスタマーサポートと多岐にわたる。デザイン思考のカスタマージャーニーマップが最も力を発揮するのは、この断絶を可視化するときだ。 世界の先行事例——オムニチャネルCXの設計哲学 ユニクロ——「サイズ不安」を起点とした体験設計 ユニクロが直面した最大の課題は「サイズ不安」だった。EC購入時に「実際に着てみないと分からない」という不安が購入を妨げ、返品コストを押し上げる。この問題に対してユニクロがとったアプローチは、技術で解決する前に体験を丁寧に観察することだった。 オンライン購入者の行動ログと返品データを組み合わせると、返品理由の中に「サイズが違った」という言語化できない「体験の失敗」が潜んでいることが見えてきた。購入後のサイズ不安は「試着しないで買ったこと」への後悔ではなく、「サイズガイドが自分のケースに当てはまらなかった」という情報体験の失敗だった。 この洞察から生まれたのが、レビューにおけるボディスペック連動のサイズ感表示だ。購入者レビューに身長・体重・着用サイズが紐づき、自分に近いユーザーの実体験を参照できるようになった。これはEC上の機能改善のように見えるが、本質は「サイズ不安という感情体験の設計」であり、デザイン思考の共感フェーズから出発した問題定義が生んだ施策だ。 ZARA——速さを「選択の体験」に変換する ZARAのオムニチャネル戦略で注目すべきは、「在庫の速度」を「顧客の体験」として設計している点だ。ファストファッションの在庫回転の速さは、顧客にとって「また来たときにない」という欠乏感の体験になりかねない。ZARAはこれを「今週しか出会えない一点」という希少性の体験として再フレーミングした。 アプリでの在庫確認機能は、「この商品が今週もあるか」という不安を軽減するのではなく、「今この瞬間に出会える」という発見の感情を強化する方向に設計されている。店舗スタッフへのインタビューをすると、常連客の多くが「なくなる前に買う」という購買行動のパターンを持つことが分かる。ZARAはユーザーの行動をデータとして読むだけでなく、その行動の背景にある感情を体験として設計に取り込んでいる。 Sephora——試すことを「デジタルでも体験」として設計する Sephoraは小売CXのデザイン思考適用の最も参考になる事例だ。化粧品購入の本質的なハードルは「自分に合うかどうかが買う前に分からない」という試着不可能性にある。 Sephoraが取り組んだのは、この「試せない」という体験的な摩擦を、デジタルツール「Virtual Artist」（AR試着機能）で解決することだった。しかし注目すべきは機能そのものより、その開発プロセスでのリサーチアプローチだ。 実際の店舗での観察では、初めて来店した顧客がテスター商品を前にして「どれを試せばいいか分からない」という体験の壁にぶつかることが見えていた。スタッフへの接触をためらう顧客が多く、テスターが置いてあるだけでは機能しない。「試せる環境がある」と「試せる体験がある」は別物だというインサイトから、デジタルとリアルを橋渡しする体験設計が生まれた。 BeautyInsiderプログラム（ロイヤルティプログラム）との連携で、購入履歴に基づくパーソナライズされたレコメンデーションが店舗でもアプリでも一貫して機能するようになり、「このブランドは私のことを分かっている」という一体感の体験を設計した。 実践フレームワーク——小売CXへのデザイン思考の適用手順 Phase 1：クロスチャネルの顧客ジャーニーを一本の線で描く 最初のワークショップでやることは一つだ。「顧客がブランドを最初に認知してから、リピート購入するまでのジャーニーを一本の線として描く」。チャネルの担当者が全員同じ部屋にいる状態で、ポストイットを使って接点を時系列に並べる。 実際にやってみると必ず起きることがある。EC担当者が「うちの接点はここで終わり」と思っていたタイミングの直後に、店舗担当者の「うちはここから始まる」が来るのだが、その間に大きな空白がある。このギャップこそが「体験の断絶」の正体だ。 地図を描かずに設計改善に入るチームは、このギャップを発見しないまま各チャネルを最適化し続ける。ジャーニーを一本の線として見ることが、オムニチャネル設計の最初の認識変革だ。 Phase 2：「摩擦ポイント」と「感情の谷」を特定する ジャーニーマップに顧客の感情曲線を重ねると、特定の接点で感情が落ち込む「谷」が現れる。小売では典型的に以下の3点に谷が集中する。 - EC購入決断の直前 — サイズ・素材・実際の色感への不安が最高潮になる - 店舗での在庫確認時 — 「ネットで見た商品が実際にあるか」のギャップ体験 - 返品・交換のプロセス — ECで買って店舗で返品しようとしたときの煩雑さ この谷の場所と深さは業態・ターゲットによって異なる。観察と共感調査なしに「どこが問題か」を決め打ちすることのリスクがここにある。 Phase 3：HMWで問いを立て直す 谷が特定できたら、How Might Weの問いで解決の方向を開く。 - 「どうすれば初めてオンラインで購入する顧客が、サイズへの不安なく注文ボタンを押せるだろうか」 - 「どうすればECと店舗の在庫情報の差異が、顧客にとって"発見"の体験になるだろうか」 - 「どうすれば返品プロセスが、ブランドへの信頼を高める接点になるだろうか」 HMWの問いの質が、続くブレインストーミングのアイデアの質を決定する。「返品をスムーズにしよう」という課題設定では「プロセスを簡略化する」という解にしか到達しない。「返品がブランド信頼を高める接点になるには」という問いは、全く異なる解の空間を開く。 Phase 4：チャネルを跨いだプロトタイプを作る 小売CXのプロトタイプには、デジタルとフィジカルの両方を含めることが重要だ。画面のワイヤーフレームだけでは、店舗での体験との連続性は検証できない。 低忠実度の検証から始める。Sephoraが最初にやったのは、物理的なテスタースペースの配置換えと、そこにスタッフが立つかどうかの比較実験だった。デジタルに先立って、まず物理的な体験変数を変えてみることが、リテール特有のプロトタイプアプローチだ。 ECと店舗の連携を検証する場合も、システム連携より先に「スタッフがお客様のスマートフォンのアプリ画面を一緒に見る」という人力の連携から試みることをすすめる。技術実装の前に体験の価値を確認する——この順序が重要だ。 日本の小売CXで特に機能するアプローチ 接客の「暗黙知」を可視化する 日本の小売の強みは、スタッフの高い接客品質にある。しかし、この接客ノウハウが「属人的な暗黙知」にとどまり、ECやアプリ設計に反映されていないケースが多い。 実際の店舗での参与観察を実施すると、ベテランスタッフが無意識に行う「顧客の迷いを読む技術」が浮かびあがる。どのタイミングで声をかけるか、どの提案を先に出すか——これをデジタル上の体験設計に移植することが、日本型オムニチャネルCXの差別化ポイントになりうる。 「関係性の体験」を設計する 欧米のCX設計が「効率的な購入体験」を中心に据えるのに対し、日本の顧客が小売に求めているのは「関係性の体験」であることが多い。ブランドのスタッフに「いつものあの人」として覚えてもらう体験、自分の好みを分かってもらえる体験——これはデジタルとリアルを跨いだ顧客データの活用と、そのデータを「つながりの証拠」として体験させる設計が必要だ。 「パーソナライゼーション」を技術として実装する前に、どんな関係性の体験を作りたいかをデザイン思考で定義すること——これが日本の小売CXにおける最初の問いになる。 まとめ——チャネルではなく、体験を設計する 3社に共通しているのは、「各チャネルの最適化」ではなく「顧客が感じる体験の一貫性」を設計の中心に置いてきたことだ。その出発点は、データダッシュボードではなく、実際の顧客の行動を観察する共感フェーズにある。 小売CXのデザイン思考プロジェクトで一番最初にすべきことは、EC担当者と店舗担当者を同じ場所に連れてきて、一人の顧客のジャーニーを一緒に追うことだ。その作業だけで、見えていなかった断絶が次々と浮かび上がる。 --- 参考文献 - Sephora, "Virtual Artist: Bringing the Beauty Counter Home", sephora.com, 2017 - Harvard Business Review, "A Study of 46,000 Shoppers Shows That Omnichannel Retailing Works", hbr.org, 2017 - McKinsey & Company, "The state of fashion 2024: Finding pockets of growth", mckinsey.com, 2024 - Inditex Annual Report 2023, inditex.com, 2024 --- ### 人事・採用でのデザイン思考活用 — 候補者体験を再設計するEX実践ガイド URL: https://designthinking.studio/articles/design-thinking-hr/ > 採用プロセスを「業務フロー」としてではなく「候補者体験」として再設計する。共感・定義・発想・プロトタイプ・テストの5フェーズを人事実務に接続するフィールドワーク型ガイド。 採用担当者が「選考フロー」と呼ぶものを、候補者は「体験」として生きています。 この視点のズレが、内定辞退率の高さや入社後のギャップ離職を生んでいる。デザイン思考を人事に持ち込むとは、このズレを構造的に解消するプロセスを作ることです。 なぜ人事にデザイン思考が必要か 人事プロセスは往々にして、会社側の効率を中心に設計されています。書類選考→1次面接→2次面接→最終面接というフローは、評価のしやすさと採用担当者の工数削減のために最適化されたものです。 ワークショップでよく起こるのは、「うちの採用プロセスはどこに問題があるか」という問いを立てると、採用担当者が「書類の通過率が低い」「面接の質問が標準化されていない」という内部視点の答えを出してしまうパターンです。しかし候補者に同じ問いを投げると、「選考状況が分からなくて不安だった」「面接官によって質問の意図が全く違って混乱した」という体験の言語が返ってきます。 デザイン思考が人事にもたらすのは、この視点の転換です。「採用プロセスを運用する」から「候補者体験を設計する」への移行。これをEmployee Experience（EX）の前身、候補者体験（Candidate Experience）の設計と呼びます。 共感フェーズ：候補者の旅を現場で追う 候補者インタビューの設計 まず内定辞退者と入社後半年以内の離職者にインタビューを申し込んでください。断られることも多いですが、承諾してくれた人の語りには、採用プロセスの盲点が凝縮されています。 インタビューで聞くべきは「どの選考が不満でしたか」ではありません。「選考のどのタイミングで、どんな気持ちになりましたか」というジャーニー型の問いかけです。 実際にやってみると、候補者は「1次面接の後に2週間連絡がなかった間、もう落ちたのかと思い始めて他社の選考を進めた」という体験を語ります。採用担当者にとって「2週間の社内調整期間」は当たり前のことですが、候補者にとっては「ブラックボックスの2週間」として生きられているのです。 観察法：選考現場を候補者目線で歩く 自社のキャリアページを初めて見る人として閲覧し、応募フォームを実際に入力してみてください。途中で詰まる箇所、不明なフィールド、送信後に何も表示されない画面——これらは採用担当者には「見えていない問題」です。 参加者からの声として多いのは、「自分の会社の採用ページを初めて候補者として見たとき、自分でも入社したいと思えなかった」という衝撃です。これが共感フェーズの本質的な価値です。 定義フェーズ：インサイトからHMWへ 収集した候補者の体験データを整理するために、エンパシーマップを使います。「候補者が言っていること・考えていること・していること・感じていること」を4象限に配置すると、個別の不満が構造的なパターンとして見えてきます。 よく出てくるパターンは3つです。 - 情報の非対称性：候補者が欲しい情報（職場の雰囲気、評価基準、入社後のキャリアパス）を、会社側が適切なタイミングで提供できていない - 待機のストレス：連絡が来るまでの期間の長さと、その間の通知のなさ - 文化の不可視性：企業文化が「採用担当者の話」としてしか伝わらず、実際の職場の空気が見えない これらのパターンからHow Might We質問を立てます。 - 「どうすれば候補者が選考中も自社への期待感を高め続けられるか」 - 「どうすれば採用担当者を増やさずに連絡頻度を上げられるか」 - 「どうすれば現場社員の声が自然に候補者に届くか」 発想フェーズ：制約を外した解決策の発散 Crazy 8sで採用プロセスの各接点（タッチポイント）について解決策を発散します。1つのタッチポイントに8分で8つのアイデアを出す制約が、「うちでは無理」という自己検閲を外すきっかけになります。 ワークショップでよく起こるのは、「選考中に候補者専用のSlackチャンネルを開設する」「内定後に入社前の社員と1on1できる機会を提供する」といった、運用コストはかかるが候補者体験を劇的に変えるアイデアが出てくることです。これらを「スケールするか」で最初に判断せず、まず体験として価値があるかを先に問うのがデザイン思考的な発想の使い方です。 プロトタイプ：選考体験の小さな実験 最初のプロトタイプは紙と口頭でよいです。 例えば「選考状況の可視化」という解決策をプロトタイプするなら、凝ったシステムを開発する前に、選考中の候補者全員に手動でメールを送る実験から始めます。「本日2次面接の結果を社内で検討しています。来週月曜日までに結果をご連絡します」という1行のメール。これが候補者にどう受け取られるかを、10人に試して学ぶことがプロトタイプです。 実際にやってみると、このシンプルな「進捗通知メール」が候補者の返信率や熱量に与える影響が数字として見えてきます。内定承諾率が上がるか、辞退連絡が減るか——小さな実験が大きな仮説を検証します。 テスト：データと定性の両輪 テストフェーズでは定量と定性の両方でプロトタイプを評価します。 定量で追うなら：内定承諾率（前後比較）、辞退のタイミング分布（どのフェーズで集中しているか）、早期離職率（入社後半年以内）。 定性で追うなら：内定者アンケートのNPS、入社1ヶ月後のインタビュー。 「測定できないものは改善できない」とよく言われます。正しい。ただ、候補者体験の文脈では「数字が動く前に感じられる変化」を先に拾うことが同じくらい大切です。数字は結果の記録。変化の早期検知は定性情報の方が速い。 実践：どこから始めるか デザイン思考を人事に導入するための最初の一手として、次の3つを提案します。 - 直近の辞退者3名にインタビューを申し込む 断られても申し込むことに意味があります。承諾してくれた人の話は、どんな採用分析ツールの数字よりも具体的な示唆を持っています。 - 自社の採用ページを候補者として体験する シークレットモードのブラウザで、初めて訪れた人として応募フォームの入力まで完了してみてください。詰まった箇所をメモすることで、すぐに改善できる問題が見えてきます。 - 次の選考から「進捗通知メール」を1通加える 選考結果の通知だけでなく、「検討中です」という中間連絡を1通加えてみてください。これだけで候補者の不安は大きく変わります。 なお、候補者体験の設計に成功した後は「入社後の体験」が次の課題として浮上します。採用から離職までの全体ジャーニーをデザイン思考で設計し直す手法については、「従業員体験ジャーニーのデザイン思考設計」で詳しく解説しています。 --- 参考文献 - Tim Brown, Change by Design, HarperBusiness, 2009 - Adam Grant, "Why So Many Companies Are Failing to Recruit Great People", The Atlantic, 2021 - Candidate Experience Awards, "2023 North American Candidate Experience Research Report", Talent Board, 2023 - Nielsen Norman Group, "Candidate Experience: Applying UX Research to Recruitment", nngroup.com, 2022 --- ### 生成AI統合デザイン思考 2026年実装ガイド｜リサーチ加速からエンパシー偽造リスクまで URL: https://designthinking.studio/articles/design-thinking-generative-ai-integration-2026/ > 生成AIをデザイン思考の5フェーズに統合する2026年の実装パターンを解説。リサーチ加速・ペルソナ生成・プロトタイプ高速化の具体手法と、エンパシーの真贋問題・バイアス継承リスクへの対処法。 「生成AIを使えば、ユーザーリサーチが不要になる」——この主張をワークショップで見聞きするたびに、危機感を覚える。 生成AIは、デザイン思考の実践速度を確かに上げた。しかし「速くなった作業」と「不要になった作業」は、まったく異なる。2026年の実務現場で問われるのは、生成AIをデザイン思考のどの部分に組み込み、どの部分を人間が担い続けるかという設計判断だ。 本記事では、各フェーズごとの実装パターンと、見落としやすい落とし穴を整理する。 --- 共感フェーズ：リサーチ加速の光と影 インタビュー前の情報密度を上げる 従来、共感フェーズのユーザーインタビューは、ある程度「手ぶら」で臨むものだった。先入観を持ち込まないためだ。しかし生成AIの登場で、インタビュー設計の精度を事前に高めることが現実的になった。 具体的には、製品カテゴリに関するSNS投稿・Amazonレビュー・カスタマーサポートのログを生成AIに処理させ、「頻出する不満のパターン」「感情が高まりやすい場面」の仮説を生成させる。このAI出力は「何を深掘りすべきか」の地図として機能し、インタビューそのものの準備精度を上げる。 ワークショップでよく起こるのは、このAI出力をインタビューの代替として扱ってしまうケースだ。AI分析が「解約申請フローで負の感情が高い」と出したとして、「なぜそうなのか」「その人の生活文脈では何が起きているのか」はインタビューでしか掴めない。 大量インタビューの分析処理 10名のユーザーインタビューを実施すると、文字起こしだけで3万字を超える。これを一人で読んで重要発言を拾い、パターンを見つける作業は、認知的に極めて重い。 生成AIによる自動文字起こし→感情タグ付け→テーマクラスタリングの流れは、この認知コストを大幅に下げる。実際の現場では、3日かかっていた分析作業が半日になったという事例は珍しくない。 ただし、AIが「似ている」と判断したクラスターが、リサーチャーから見ると「文脈がまったく違う」というケースが頻出する。AI分析の出力は、人間のコーディングの「たたき台」であり、最終的な意味づけは人間が担うという役割分担を崩さないことが鉄則だ。 --- 問題定義フェーズ：インサイトの量産とその危うさ How Might Weの生成支援 共感フェーズで収集したインサイトを、「How Might We（HMW）」の形式に変換する作業は、慣れないチームには難易度が高い。生成AIに「このインサイトからHMWを10個生成せよ」と依頼すると、文法的に正しいHMWが即座に並ぶ。 これは確かに役立つ。しかし問題は「良いHMW」と「多くのHMW」は別物だという点にある。d.schoolの定義によれば、良いHMWは「範囲が広すぎず、解決策を誘導しすぎず、具体的なインサイトに根差している」ものだ。AIが生成したHMWの多くは、この「具体的なインサイトへの根差し」が薄い。 実践として有効なのは、AIが生成したHMWをチームで評価するセッションを設けること。「このHMWは誰のどんな状況に根差しているか？」を問い、根拠が薄いものを除外する。AIは量を出し、チームは質を選ぶ、という役割分担だ。 ポイント・オブ・ビュー（POV）の草案生成 インタビューデータからPOV（ユーザー、ニーズ、インサイトの3要素の文）を書く作業も、生成AIが草案を出せるようになった。ただし、AIが生成したPOVはインサイト部分が表層的になりやすい。「ユーザーは〜したい、なぜならば〜だから」という構文を満たしていても、「なぜならば」の部分が常識的な一般論にとどまるケースが多い。 POVの価値は、チームが見落としていた洞察を言語化することにある。AI生成のPOVを「素材」として、チームがインタビューの記憶を呼び起こしながら精度を上げていく使い方が、現場では有効だ。 --- 創造フェーズ：発散の加速と収束の人間判断 ブレインストーミングの補完ツールとして ブレインストーミングの最大の敵は、「場の同調圧力」と「ネタ切れ」だ。生成AIは、この両方を部分的に解決する。 チームが行き詰まった時点でAIに「先ほどの問いに対して、非常識な解決策を20個挙げよ」と投入すると、場が動き出す。AIが出す奇抜なアイデアは、それ自体が採用されなくても、チームの連想を刺激するトリガーになる。 ワークショップでよく起こるのは、「AIのアイデアの方が面白い」という発言が出て、チームの自己効力感が下がるケースだ。ファシリテーターは「AIは量を出す機械、評価と選択はあなたたちにしかできない」という役割の再定義を、事前に明示しておく必要がある。 発散から収束への移行 収束フェーズ（どのアイデアを進めるかの選択）は、生成AIに任せてはいけない。収束は「組織のリソース」「実現可能性」「戦略との整合性」「チームの本気度」という文脈を総合した判断だ。AIはこの文脈を持たない。 収束の設計はドット投票やICE採点法などの人間主導のフレームワークで行う。 --- プロトタイプフェーズ：高速化の恩恵と忘れてはならない低忠実度の価値 テキスト・ビジュアルプロトタイプの生成 生成AIの最も劇的な貢献は、プロトタイプ制作の速度向上だ。UIコンセプトの画像生成、コピーのたたき台、サービスフロー図の素材、ランディングページの初稿——これらが数時間で揃う。 従来3日かかっていたプロトタイプの準備が1日になることで、同じ時間内に試せる仮説の数が増える。 これはデザイン思考の核心である「より多く失敗して、より早く学ぶ」を実現するうえで、素直にポジティブな変化だ。 低忠実度プロトの価値は失ってはならない 一方で注意したいのが、生成AIで作った「見栄えの良いプロトタイプ」がユーザーテストに悪影響を与えるケースだ。完成度が高いプロトタイプは、ユーザーが「変更の余地がない完成品」として認識しやすく、批判的なフィードバックを出しにくくなる。 紙に手書きしたプロトタイプが「未完成の素材」として機能し、ユーザーが遠慮なく意見を言いやすいという、低忠実度プロトタイプの本質的な価値は、生成AIが普及した今も失われていない。生成AI出力をそのまま使うか、一度「粗くする」処理を加えるかは、テストの目的によって設計する必要がある。 --- テストフェーズ：バイアス継承と「エンパシーの真贋」問題 ユーザーテストのシミュレーション 生成AIに「このターゲットユーザーとして振る舞い、このプロトタイプを評価せよ」と指示することで、仮想ユーザーテストが行える。迅速なフィードバックを得る手段として有効な局面はある。 しかしこの手法の最大の問題は、AIが「過去のデータで学習したユーザー像」をシミュレートすることにある。 実際のユーザーが持つ、文脈固有の感情・生活環境・意思決定の癖を、AIは再現できない。AI仮想テストは「ゼロより良い」が、実ユーザーテストの代替にはなれない。 バイアス継承の構造的リスク 生成AIのペルソナ生成やユーザー分析には、学習データのバイアスが構造的に含まれる。特定のジェンダー・年齢・所得層・文化的背景が過剰または過小に代表されているリスクは、デザイン思考の実践者が意識的にチェックする必要がある。 「AIが生成したペルソナは誰を代表しているか？」を問う習慣を、チームのプロセスに組み込むことが、2026年の実務における標準的な品質管理の姿になっている。生成ペルソナを複数出力させ、それらが均質になっていないかを目視で確認する、というシンプルな工程でも有効だ。 エンパシーの真贋 最後に、もっとも根本的な問いを提示する。生成AIが生成した「ユーザーの気持ち」は、本物の共感の産物か？ ニールセン・ノーマン・グループの調査によれば、AIが生成したインサイトは表面的には正確でも、「なぜそう感じるのか」の文脈的な深みに欠ける傾向がある。デザイン思考の核心は「ユーザーの生活文脈に入り込む」ことにある。 AIはその素材を処理できても、入り込むことはできない。 ユーザーの目の前に座り、沈黙を共にし、表情の変化を読む——この経験を通じてチームに宿る共感は、AIが生成した分析レポートでは代替できない。実際にやってみると、AIレポートを読んだチームと、現場インタビューに参加したチームでは、その後のアイデアの質が明確に異なる。 --- 生成AI統合のための判断マトリクス 生成AIをデザイン思考のどのフェーズで使い、どこで使わないかは、以下の判断軸で整理できる。 使うべき場面： 大量データの処理・パターン抽出・素材の量産・繰り返し作業の自動化。これらは人間の認知コストを下げ、より重要な判断に集中させる。 使ってはいけない場面： 収束の判断・インサイトの意味づけ・ユーザーとの直接接触・プロトタイプの採択決定。これらは文脈・価値観・組織固有の判断を必要とする。 慎重に使うべき場面： ペルソナ生成・HMW生成・仮想ユーザーテスト。AIの出力をたたき台として使いつつ、人間がバイアスと表面性を補正する工程を必ず設ける。 生成AIはデザイン思考を変えた。しかし変えたのは「何ができるか」ではなく「どこに時間を使うか」だ。浮いた時間を、ユーザーと向き合うことに使えるかどうかが、生成AI時代のデザイン思考実践者に問われる本質的な選択になっている。 --- やってみよう 今週から始められる実装ステップ： - 次のプロジェクトのインタビュー設計前に、生成AIに「このテーマに関するユーザーの不満仮説を10個出力せよ」と入力し、インタビューガイドの補完素材として使う - インタビュー後の分析で、AI文字起こし→テーマクラスタリングを試し、どのクラスターが「文脈が違う」と感じるかを記録する - AI生成ペルソナを3パターン出力し、「このペルソナたちに欠けている多様性は何か」をチームで5分間議論する 特に生成AIを「リサーチの代替」として使い始めているチームに、一度立ち止まってほしい実験だ。 --- 内部リンク - AI時代のデザインマインドセット - 共感フェーズの実践 - ペルソナの作り方と使い方 - ユーザーインタビューの技法 - デザイン思考のAIツール活用 --- 参考文献 - Nielsen Norman Group. "Synthetic Users: If, When, and How to Use AI-Generated 'Research'." NN/g Articles, 2025. https://www.nngroup.com/videos/ai-generated-users/ - IDEO. "The Role of AI in Human-Centered Design." IDEO Design Thinking, 2024. https://designthinking.ideo.com/ - Stanford d.school. "Design Thinking Bootleg." Stanford d.school, 2023. https://dschool.stanford.edu/resources/design-thinking-bootleg - Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins, 2009. （邦訳：『デザイン思考が世界を変える』早川書房） - Harvard Business Review. "Research: When Used Correctly, LLMs Can Unlock More Creative Ideas." HBR, 2025. https://hbr.org/2025/12/research-when-used-correctly-llms-can-unlock-more-creative-ideas - Liedtka, Jeanne. "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction." Journal of Product Innovation Management, 2015. - IDEO U. "Human-Centered AI: Designing with Artificial Intelligence." IDEO U Course Materials, 2025. https://www.ideou.com/ --- ### 製造業のデザイン思考：トヨタ・ダイソンが示すモノづくり革新の実践 URL: https://designthinking.studio/articles/design-thinking-manufacturing/ > 製造業でデザイン思考はどう機能するか。トヨタ、ダイソン、Bosch、3Mのリアルな事例から、ハードウェア開発・工程設計・B2B製造業への導入戦略を体系解説する。 デザイン思考の導入事例を検索すると、医療・HR・公共サービスの事例が圧倒的に多い。これは不思議なことです。デザイン思考の原型を作った IDEO は、Apple のマウスや Steelcase の家具など、物理的な製品の設計で名を上げた会社だからです。 モノを作ること——ハードウェアを設計し、生産ラインを組み、品質を管理し、供給チェーンを動かすこと——は、デザイン思考が最も自然に接続できる営みのはずです。それでも製造業でのデザイン思考導入が「特別な話題」として扱われるのは、製造業固有の障壁が存在するからです。 この記事では、トヨタ、ダイソン、Bosch、3M の事例を通じて、製造業でデザイン思考がどう機能し、どこで限界を持つかを具体的に検討します。 製造業がデザイン思考を必要とする理由 「作れるものを売る」から「使われるものを作る」へ 20世紀の製造業の論理は「生産効率の最大化」でした。どれだけ安く、速く、均一に大量生産できるかが競争力の源泉でした。この時代、「何を作るか」はエンジニアと経営者が決め、「どう売るか」はマーケターが考えました。ユーザーは「消費者」として、完成した製品を受け取る存在でした。 この構造が、スマートフォン以降の時代に通用しなくなりました。製品の機能的な差別化が限界に達し、「体験の質」が競争軸になったからです。同じ性能のドリルが並んでいるとき、ユーザーは「握った感触」「音」「重心のバランス」「取扱説明書の分かりやすさ」を比較して選びます。これらは生産効率の指標では捉えられない価値です。 さらに深刻なのは、製造業が「自社の製品が最終的にどう使われているか」を知らないまま設計しているという問題です。工場から出荷された製品が、どんな文脈で、誰に、どう使われているかのフィードバックループが存在しない企業は多い。B2B製造業ではこの問題がより顕著です。 製造業がデザイン思考を避けてきた理由 製造業のデザイン思考導入が遅れてきた背景には、構造的な理由があります。 長いリードタイムとの相性問題：自動車のような製品は、設計から量産まで3〜5年かかります。「素早くプロトタイプを作ってテストする」というデザイン思考の原則と、物理的な量産準備の長さが、時間軸のレベルで合わない。 コスト構造の違い：デジタルサービスのプロトタイプはコードを書けば無料に近いコストで作れます。物理的な試作品は金型代だけで数百万円かかることがあります。「失敗を歓迎する」文化を、コスト感覚が許さない。 既存の設計プロセスの強固さ：ステージゲート方式（各フェーズを完了してから次へ）は製造業の設計管理の標準です。この方式はリスク管理には優れますが、「前のフェーズに戻って問い直す」というデザイン思考の反復性と本質的に衝突します。 しかしこれらの障壁は「デザイン思考が製造業に使えない」理由ではありません。適用するレイヤーと方法を選べば、製造業でもデザイン思考は機能します。 --- トヨタ：「使う人」の観察が生んだ生産革新 ゲンチゲンブツ——現場で見る、現物で考える トヨタ生産方式（TPS）の中核原則「ゲンチゲンブツ（現地現物）」は、デザイン思考の「共感フェーズ」とほぼ同義です。 「データや報告書を信じるな。現場に行き、現物を手に取り、現実を観察せよ」——この姿勢はユーザーインタビューや観察調査のプロセスと論理的に同じです。トヨタがデザイン思考という言葉を使わないのは、彼らがデザイン思考の実践を数十年早く、独自に体系化していたからです。 具体的な事例として、トヨタが工場ラインの作業者の「不便さ」を観察することで生産改善のアイデアを得る「カイゼン」の仕組みがあります。作業者は自分の「小さな不便」を付箋に書いてラインに貼る権利を持ち、チームがそれを集めてアイデア会議を行います。これは親和図法の実用版です。 レクサスの開発：アメリカ人の「上質」を観察する 1980年代後半のレクサス開発プロジェクトは、製造業×デザイン思考の古典的ケースです。 チーフエンジニアの鈴木一郎は、開発チームをアメリカへ派遣し、富裕層アメリカ人の「上質な生活」を徹底的に観察させました。 彼らがどんな家に住み、どんな車を乗り回し、週末に何をし、どんな音楽を聴くか。メルセデスやBMWがなぜ選ばれるかを、スペック表ではなく生活文脈から理解しようとしました。 この観察から導かれた洞察のひとつが「静粛性」でした。欧州の高級車は「走りの質感」を重視しますが、アメリカの富裕層は「移動中の静寂な空間」に上質さを感じていた。この差異を捉えてレクサス LS400 は、発売当時世界最高水準の室内静粛性を実現しました。 ユーザーが言葉にしなかった「静かな空間でリラックスしたい」というニーズを観察から読み取ったこのプロセスは、デザイン思考の共感フェーズが最も価値を発揮するパターンです。 --- ダイソン：「使えないものへの怒り」がイノベーションの種になる 創業者の共感体験 ジェームズ・ダイソンがサイクロン掃除機を発明したきっかけは、よく知られた話です。自宅の掃除機が吸引力を失い続けることへの「怒り」——これはデザイン思考の共感フェーズが「ユーザーのペインポイントを発見する」プロセスと本質的に同じです。 ただし、ダイソンのケースで注目すべきはプロトタイピングの規模と粘り強さです。 1979年から1984年の5年間で、ダイソンは5,127個の試作品を作りました。この数字はデザイン思考における「プロトタイピングは安く速く」の原則とは逆方向に見えますが、実態は違います。各試作品は前の失敗から学んだ「次の仮説を検証するための実験」であり、5,127回の実験を通じた反復学習のプロセスでした。 この姿勢は、ダイソンのその後の製品開発にも一貫しています。Dyson のエンジニアは今日も「失敗を記録する文化」を持ち、試作品のプロセスをデータとして保存します。「何がうまくいったか」ではなく「何がうまくいかなかったか」が、次のイノベーションの資産になるという考え方です。 ユーザーリサーチを製品に組み込む 現代の Dyson は、製品にセンサーを組み込み、使用データをクラウドに送信することで「実際の使用パターン」を継続的に把握しています。どんな床面で、どんな時間帯に、どの吸引モードが使われるか——このデータが次世代製品の設計にフィードバックされます。 「製品を出荷した後も共感が続く」このアーキテクチャは、デジタルとフィジカルの融合がもたらした製造業固有のデザイン思考の進化形です。 --- Bosch：B2B製造業での「隠れたユーザー」発見 工具を「買う人」と「使う人」は別人 Bosch（ボッシュ）の電動工具部門が直面していた問題は、製造業のデザイン思考導入における典型的な課題を示しています。 Bosch の主要顧客は建設会社です。工具を「購入する」のは調達担当者や現場監督であり、工具を「使う」のは職人（大工、電気工、配管工）です。この二者のニーズはしばしば一致しません。 調達担当者は「価格」「耐久性の保証」「メーカーの信頼性」で選びます。職人は「手への振動の少なさ」「1日中持ち続けたときの疲労感」「騒音」「バッテリー交換の手軽さ」で評価します。 Bosch はステークホルダーマッピング的な分析を通じて、「購買決定者ではなくエンドユーザーの職人のニーズを中心に設計する」方針転換を行いました。職人が「これは使いやすい」と感じる工具は、現場の評判として広がり、最終的に調達担当者の購買決定を動かすという構造を発見したからです。 この方針転換の後、Bosch は職人を招いてのユーザーリサーチセッション（作業観察、インタビュー、プロトタイプテスト）を製品開発の標準プロセスに組み込みました。結果として開発された18V LiイオンバッテリーシリーズはB2Bユーザーからの支持を集め、競合との差別化軸となりました。 --- 3M：「15%ルール」とイノベーションの制度化 偶発的発見を制度にする 3M が1948年に導入した「15%ルール」——就業時間の15%を自由なプロジェクトに使える制度——は、デザイン思考の「アイデエーションを組織に組み込む」試みとして先駆的なものでした。 ポスト・イット（Post-it Note）の発明はこのルールの産物です。スペンサー・シルバーが「失敗作」として生み出した弱い接着剤が、アート・フライのアイデアによって「繰り返し貼り直せるしおり」として製品化された過程は、デザイン思考における「偶発的インサイトを拾い上げる文化」の好例です。 注目すべきは「失敗した接着剤を廃棄しなかった」という判断です。機能的には欠陥品でも、「これが役立つ文脈はないか」と問い続ける姿勢が、新しい用途の発見につながりました。これはデザイン思考の問いの立て方——「この制約を解決するのではなく、この制約が価値になる場面はどこか」——と同じ構造です。 製造業でのアイデエーション管理 3M のイノベーション管理が製造業として特徴的なのは、「アイデアを生む仕組み」と「量産化の仕組み」を分離していることです。 アイデエーション段階では自由度を最大化し、量産化段階では厳密なプロセス管理（品質、コスト、安全性）を適用する——この二層構造により、創造性と製造品質の両立を実現しています。 --- 製造業固有のデザイン思考の適用戦略 どのフェーズにどう適用するか 製造業でデザイン思考を適用する際、すべてのフェーズを全開で使おうとすると失敗します。製造業の時間軸とコスト構造に合わせた適用レイヤーを選ぶことが重要です。 共感フェーズ（最も効果が高い） 現場観察とユーザーインタビューは、製造業でも比較的低コストで実施できます。生産された製品が「現場でどう使われているか」の観察は、製品設計にもプロセス設計にも直結します。特にB2B製造業では「使う人と買う人が違う」問題を解くために、エンドユーザーへのリーチが不可欠です。 問題定義フェーズ（リソース配分に効く） 「どの問題を解くか」の選択は、製造業では設備投資・人員配置と直結します。デザイン思考の問題定義手法——POVステートメント、HMW問い——を使って「本当に解くべき問題」を特定することで、的外れな設備投資を避けられます。 プロトタイピングフェーズ（適用方法の工夫が必要） 物理的な試作品のコストを下げるために、デジタルツイン（3Dシミュレーション）、3Dプリンティング、外観モックアップ（機能なし）を段階的に組み合わせます。「高忠実度の試作品を1つ作る」より「低忠実度の試作品を10個テストする」アプローチが、最終的なコストを下げることが多い。 テストフェーズ（製造業の強みを活かす） 製造業はデータ収集のインフラを持っています。工場のセンサーデータ、品質検査データ、アフターサービス記録——これらはすべて「製品がどう使われたか」のフィードバックです。このデータをデザイン思考の「テスト→学習」サイクルと接続することで、次世代製品設計へのフィードバックループを構築できます。 製造業でよくある失敗パターン 「顧客」を企業（バイヤー）だけで定義する B2B製造業では「顧客＝バイヤー企業」と定義しがちです。しかし実際に製品を使うエンドユーザー（工場の作業員、建設現場の職人、病院の看護師）のニーズを見落とすと、バイヤーには「良い提案」に見えても、現場では使われない製品が生まれます。 デザイン思考をマーケティング部門だけの話にする 製品の設計は工場と生産技術部門が担う。デザイン思考はマーケティングのリブランディングに使う——この分離が、製造業でのデザイン思考の効果を半減させます。製品設計の初期段階からエンジニアとデザイン思考の実践者が同じチームで動く体制が必要です。 プロトタイピングを「完成度の高い試作品」と混同する 製造業のエンジニアは「試作品＝実際に動く完成度の高いもの」というイメージを持っていることが多い。デザイン思考のプロトタイピングは「アイデアを検証するための最小限の形」を作ることです。段ボールで作ったモックアップが「このグリップ角度は合っているか」を検証するのに十分なことがある——このマインドシフトが導入の最初の壁になります。 --- 製造業でデザイン思考を導入するための5ステップ 製造業でのデザイン思考導入を検討する組織のために、現実的なスタートポイントを示します。 Step 1：「使う人」への観察から始める（コスト最小） まず工場出荷後の製品が実際にどう使われているかを観察します。アフターサービス部門が持つ故障データ・顧客クレームは、ユーザーのペインポイントの宝庫です。これは追加投資なしで実施できる「共感フェーズ」の入り口です。 Step 2：「使う人と買う人の違い」を特定する B2B製造業ではステークホルダーマッピングを使って、バイヤー・エンドユーザー・意思決定者を分離し、それぞれのニーズを把握します。「誰のための設計か」を明確にするだけで、製品コンセプトが変わることがあります。 Step 3：小さなプロトタイプを量産化の前に試す 金型を発注する前に、3Dプリンターで外観モックアップを10個作り、実際の使用現場でテストします。「どちらのグリップが疲れにくいか」「どちらのボタン配置が直感的か」は、完成品ではなくモックアップで十分検証できます。 Step 4：現場の「小さな不便」を収集する仕組みを作る トヨタのカイゼンの仕組みに倣い、工場作業員・営業担当・アフターサービス担当者が「ユーザーの不便」を定期的に報告できる仕組みを作ります。これは組織的な共感フェーズの制度化です。 Step 5：エンジニアとデザイン思考を接続する 製造業でのデザイン思考の最大の障壁は、「デザイン思考＝マーケティングの話」という分離です。製品設計の初期フェーズ（コンセプト定義、要件定義）にデザイン思考のワークショップを組み込み、エンジニアが「誰のための設計か」を考える機会を作ります。 --- まとめ：製造業こそデザイン思考の本丸だった デザイン思考は、医療やHRより先に、製造業——物を作る現場——で発展した考え方です。トヨタのゲンチゲンブツ、ダイソンの5,127個の試作品、3Mの15%ルールは、デザイン思考という言葉を使わずにその本質を実践してきた例です。 現代の製造業に必要なのは「デザイン思考を導入する」という大げさな変革ではなく、「使う人を直接観察する」「問題を定義してから設計を始める」「小さく試して早く学ぶ」という3つの姿勢を、既存の設計プロセスに組み込むことかもしれません。 製造業はすでにデータ、現場、ものを作る力を持っています。デザイン思考はその力を「正しい問いに向ける」ための方法論です。 --- 参考文献 - Jeffrey Liker, The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer, McGraw-Hill, 2004 - James Dyson, Against the Odds: An Autobiography, Orion Publishing, 1997（US版: Texere, 2000） - Tom Kelley & Jonathan Littman, The Art of Innovation: Lessons in Creativity from IDEO, Currency/Doubleday, 2001 - Eric von Hippel, The Sources of Innovation, Oxford University Press, 1988 - IDEO, Human-Centered Design Toolkit, IDEO.org, 2011 - Vijay Kumar, 101 Design Methods: A Structured Approach for Driving Innovation in Your Organization, Wiley, 2012 --- ### 組織変革を加速するエンパシーマップ活用法 — チームの共感力を高める実践ステップ URL: https://designthinking.studio/articles/empathy-map-organizational-transformation/ > エンパシーマップを組織変革の文脈で活用する方法を解説。変革抵抗の本当の理由を可視化し、チーム全体の共感力を高めるファシリテーション手順と、よくある失敗パターンを実践的に紹介する。 「変革に抵抗する人がいて困っている」という相談を受けるたびに、同じ問いを返している。「その人が抵抗する理由を、本人の立場から理解しようとしましたか？」 変革への抵抗には必ず理由がある。しかし多くの場合、その理由は表面的な言葉の裏に隠れている。「忙しくてできない」の裏には「失敗した時の責任が怖い」があるかもしれない。「今のやり方で問題ない」の裏には「新しいスキルを習得することへの不安」があるかもしれない。 エンパシーマップは、この「表面」と「本音」のギャップを可視化するためのツールだ。 組織変革のファシリテーションにエンパシーマップを持ち込むことで、抵抗の構造が変わる。 --- エンパシーマップとは何か エンパシーマップは、デザイン思考の共感フェーズで使われる観察・整理ツールだ。ユーザーの体験を4つの象限（Say/Do/Think/Feel）で可視化することで、言葉だけでは見えない本音や動機を浮かぶようにする。 詳細な作成手順はエンパシーマップ作成ガイドに譲り、本記事では「組織変革」という文脈に特化した活用法を解説する。 組織変革文脈での特殊性 製品開発でエンパシーマップを使う時、対象は「製品を使うユーザー」だ。しかし組織変革でエンパシーマップを使う時、対象は「変革に関わる組織の人々」になる。 この違いは重要だ。組織変革では、ファシリテーターや推進担当者自身も変革の当事者であり、観察対象になりうるからだ。自分が関わる変革のステークホルダーを客観的にエンパシーマップで描く行為は、「変革の推進者がいかに相手の立場を見ていなかったか」を自覚させる効果がある。 ワークショップでよく起こるのは、変革推進者が「なぜわかってくれないのか」という視点から出発していることだ。エンパシーマップを使うことで、この視点が「相手は何を考え、何を感じているのか」という方向に転換する。 --- 組織変革のためのエンパシーマップ：5つの活用シーン 活用シーン1: 変革ステークホルダーの抵抗構造を理解する 変革を進める前に、関係するステークホルダーを3〜5つのグループに分類する。例えば「経営層」「中間管理職」「現場担当者」「顧客接点部門」「IT部門」といった分類だ。 それぞれのグループについて、エンパシーマップを作成する。ポイントは「推進チームが想像で描く」のではなく「実際のインタビューや観察から得た情報で描く」ことだ。 実際にやってみると、中間管理職のエンパシーマップを描いた時に「彼らは変革に反対しているのではなく、上と現場の板挟みで消耗している」という認識が、推進チームに初めて生まれるケースが多い。 手順（1グループあたり60〜90分）: - 対象グループに属する人3名以上にインタビューを実施する（各30分） - インタビューの発言・観察した行動をカードに書き出す - 4象限（Say/Do/Think/Feel）に分類する - 各象限のカードをグループ化し、見出しをつける - 「ペイン（痛み）」「ゲイン（得たいもの）」を最下部に記述する 活用シーン2: 変革設計チームの「認識のズレ」を可視化する 変革推進チームが複数名いる場合、チームメンバーが「同じステークホルダーについて異なるエンパシーマップを描いている」ことがある。 この「ズレ」を可視化することが重要だ。 個別に描いたエンパシーマップを並べて比較することで、チーム内の前提の差が見えてくる。「あなたはその部門の担当者が主に恐れているのは評価だと思っているが、私は仕事の量だと思っていた」という対話が生まれる。 この手法はワークショップでよく使われる「コンセンサス確認」の応用版だ。参加者からの声として「チームで同じ対象者を描いたら、こんなに認識が違うとは思わなかった」という驚きは、この実践で最も頻繁に聞かれる言葉だ。 活用シーン3: 変革プランの「相手視点」チェック 変革プランを作成した後、プランの各施策を「エンパシーマップの対象者視点」でレビューする。 具体的には、各施策を付箋に書き、エンパシーマップの「Feel象限」「Think象限」に貼り付けてみる。「この施策を見た時、対象者はどう感じるか」「何を考えるか」を、マップに記述されている情報を根拠に予測する。 「エンパシーマップのペイン（痛み）を解消しない施策は、たとえ論理的に正しくても実行されない」という観察が、この実践から得られる最も重要なインサイトだ。 活用シーン4: 変革の「反対意見」を設計に活かす 変革の反対意見を「排除すべき障害」として扱うのではなく、「見落としていた視点」として扱うアプローチがある。 反対意見を持つ人のエンパシーマップを丁寧に作成する。特に「Think（何を考えているか）」と「Feel（何を感じているか）」を深く探ることで、反対意見の背景にある正当な懸念が見えてくることが多い。 実際にやってみると、「反対派」のエンパシーマップを作った後に、推進チームが「彼らの懸念は正しかった」と認識を改めるケースが珍しくない。反対派の声はリスクの早期発見機能を持っていることが、このプロセスで明確になる。 活用シーン5: 変革後の「あるべき体験」を設計する 「TO-BE（あるべき姿）」のエンパシーマップは、変革の目標設計に使える。「変革が成功した1年後、このステークホルダーは何を感じ、何を考えているか」を描く。 このTO-BEマップを「目指す状態」として定義することで、変革の成功指標が行動ベースになる。「変革が成功した状態」を「何が変わっているか」という具体的な行動・感情の変化で定義できるからだ。 --- エンパシーマップを組織変革に使う際のファシリテーション手順 準備（ワークショップ前） 対象者のインタビュー実施（必須） エンパシーマップは「想像」で描かない。実際のインタビュー・観察データが必要だ。変革の推進チームが「現場をよく知っている」と思っていても、実際にインタビューすると「知らなかった」事実が必ず出てくる。 最低でも1グループあたり3名のインタビューを事前に実施する。インタビューは30〜60分。録音・メモは許可を得た上で実施する。 インタビューで効くのは「最後の1週間でいちばん大変だったことは？」という問いだ。 「変革についてどう思うか」という直接的な問いよりも、日常業務の文脈から話してもらう方が、本音に近い情報が得られる。 ワークショップ当日（2〜3時間） ステップ1: 個別記述（20分） 参加者が各自でカードに「インタビューで聞いた発言・観察した行動」を書き出す。1カード1情報。沈黙の中で個別に書くことで、グループ思考の同調圧力を防ぐ。 ステップ2: 4象限への分類（30分） グループで、カードを壁に貼られたエンパシーマップの4象限に配置する。「Say」（言葉）と「Do」（行動）は観察事実、「Think」「Feel」は推論という区別を意識することが重要だ。推論と事実を区別しないと、マップが主観的になる。 ワークショップでよく起こるのは、「Think」「Feel」に書くべき内容を「Say」に入れてしまうミスだ。「もっと時間がほしい」という発言は「Say」に入る。「なぜ時間がほしいのか」の推論（評価が怖い、スキルに自信がない）は「Think」「Feel」に入る。 ステップ3: パターンの発見（30分） 各象限のカードをグループ化し、共通するテーマを見出す。この段階で「ペイン（課題・恐れ）」「ゲイン（望んでいること）」を記述する。 ステップ4: インサイトの言語化（30分） 「このエンパシーマップから、変革設計に活かせる洞察は何か」を議論する。特に「ペイン」の中に変革設計で対処していないものがないかをチェックする。 ステップ5: How Might Weの作成（30分） 発見したインサイトから「How Might We（どうすれば〜できるか）」の問いを作る。エンパシーマップのペインを解消する形で問いを立てることで、次の創造フェーズへの橋渡しができる。 --- よくある失敗と対策 失敗1: 「想像」でエンパシーマップを描く 実際のインタビューデータがないまま、推進チームが想像でマップを埋めるケース。完成したマップが「私たちが思っている相手の状態」になってしまい、実際の相手との乖離が大きい。 対策: インタビューなしのエンパシーマップは「仮説マップ」と明示し、必ず後でインタビューで検証する。仮説マップを作ること自体は有効だが、それが「実態だ」と信じてしまうことが問題だ。 失敗2: 「Say」と「Think」を混同する 発言を「Think」に入れてしまう、あるいは推論を「Say」に入れてしまうケース。4象限の意味が混在すると、マップから得られるインサイトが曖昧になる。 対策: ファシリテーターが「これは実際に言った言葉ですか、それとも私たちの推論ですか？」を常に確認する。推論は明示的に「仮説」として扱う。 失敗3: エンパシーマップで終わる エンパシーマップを「作ること」が目的化し、そこから「どう行動を変えるか」につながらないケース。 対策: ワークショップの終盤に必ず「次の2週間でできる具体的なアクション1つ」を合意する。「インサイトを経営層に共有する」「評価制度の担当者にインタビューを申し込む」など、具体的な行動に落とす。 --- まとめ：組織変革にエンパシーマップが必要な理由 組織変革の文脈でエンパシーマップが有効な理由は、変革とは本質的に「人の体験の設計」だからだ。プロセスを変えても、制度を変えても、人の感情と思考が変わらなければ、行動は変わらない。 エンパシーマップは「相手の感情と思考を可視化する」ツールだ。これを組織変革の設計プロセスに組み込むことで、変革は「仕組みの変更」から「人の体験の変革」へと深まる。 変革が難しいと感じる時、まず一歩立ち止まって「変革の対象者をユーザーとして観察しているか」を問い返すことが、突破口になることが多い。 組織変革の5ステップ実践についてはデザイン思考で組織変革を成功させる5ステップ実践ガイドも参照してほしい。 --- 参考文献 - Dave Gray, Sunni Brown & James Macanufo, Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, O'Reilly Media, 2010（エンパシーマップの普及に貢献したワークショップ設計書） - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015（HCDのエンパシーマップ活用法の基準書） - Prosci, ADKAR: A Model for Change in Business, Government and our Community, Prosci Research, 2006（変革管理における意識・欲求・知識・能力・定着の5要素モデル） - Liedtka, Jeanne, "Why Design Thinking Works," Harvard Business Review, September–October 2018 - Alexander Osterwalder et al., Value Proposition Design, Wiley, 2014（エンパシーマップをVPDのコンテキストで体系化した書籍） --- ### 創造フェーズ——制約を外してアイデアを生み出す URL: https://designthinking.studio/articles/ideate-phase/ > デザイン思考の第3フェーズ「創造（Ideate）」を解説。ブレインストーミングのルール、発散と収束の使い分け、効果的なアイデア発想の手法。 創造（Ideate）は、問題定義フェーズで設定した問いに対して、大量のアイデアを生み出すフェーズです。 創造フェーズの原則 このフェーズで最も重要な原則は、発散と収束を分離することです。アイデアを出す段階（発散）と、アイデアを選ぶ段階（収束）を同時に行わないことで、自由な発想が促進されます。ダブルダイヤモンドモデルでも、この発散と収束のリズムを明示的にプロセスに組み込んでいます。 ブレインストーミングのルール IDEO が実践するブレインストーミングのルールは以下の通りです。 - 判断を保留する（Defer Judgment） — アイデアの良し悪しを判断しない - 大胆なアイデアを歓迎する（Encourage Wild Ideas） — 実現可能性は後で考える - 他者のアイデアに乗る（Build on the Ideas of Others） — 「Yes, and...」の姿勢 - 一度に一人が話す（One Conversation at a Time） — 全員のアイデアを聴く - 視覚的に表現する（Be Visual） — 言葉だけでなくスケッチも活用 - 量を追求する（Go for Quantity） — 質より量を重視する - トピックに集中する（Stay Focused on the Topic） — HMWからの問いに立ち返る アイデア発想の手法 ブレインストーミング以外にも、さまざまなアイデア発想手法があります。 - Crazy 8s — 8分間で8つのアイデアをスケッチする - SCAMPER — 既存のアイデアを代用・結合・適応・修正・転用・除去・逆転する - マインドマップ — 中心テーマから連想を広げていく - 逆ブレインストーミング — 「最悪の解決策は何か？」から考える 収束：アイデアの選択 十分な量のアイデアが出たら、収束に移ります。投票（Dot Voting）やマトリクス（Impact/Feasibility Matrix）を使って、プロトタイプフェーズに進めるアイデアを選択します。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、発散フェーズ中に「それは実現できない」という評価の声が上がるパターンです。ルールとして「判断を保留する」と最初に説明しているにもかかわらず、声の大きいメンバーが「現実的ではないよね」とアイデアを即座に却下し始める。 これが起きると、その後のアイデアの質が急激に落ちます。参加者が「どうせ否定される」と感じ、当たり障りのないアイデアしか出さなくなるためです。実際にやってみると分かるのですが、最初の10個のアイデアは全員が思いつく「当たり前の案」です。本当に面白いアイデアは15個目以降に出てきます。 そこまで場を守るのがファシリテーターの役割で、そのためにもルールの徹底が不可欠です。 まとめ 創造フェーズの成功は、安全な環境での自由な発想と、適切な収束のバランスにかかっています。 --- 参考文献 - IDEO, "The 7 Rules of Brainstorming", ideo.com - Tom Kelley & Jonathan Littman, The Art of Innovation, Currency/Doubleday, 2001 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） --- ### 定性調査の「何人に聞けばいい」問題 — サンプルサイズ神話を解体する URL: https://designthinking.studio/articles/design-thinking-qualitative-sample-size/ > 「ユーザーインタビューは何人やればいいのか」はデザイン思考実践者が最初にぶつかる問いのひとつだ。5人説・12人説・飽和点理論——根拠と限界を整理し、現場で使える判断軸を示す。 「何人にインタビューすればいいですか」という問いは、デザイン思考のワークショップで必ず一度は飛んでくる。 多くの場合、答えは「5人」で返ってくる。Jakob Nielsenが2000年に発表した「Why You Only Need to Test with 5 Users」というレポートが、この数字の出所だ。記事の主旨はユーザビリティテスト（問題発見率の統計的推定）についてのものだが、いつの間にか「定性インタビュー全般で5人でいい」という通説になってしまった。 調査の現場でよく見られるのは、この通説を正確な文脈なしに持ち歩いた結果、調査設計が崩れていく場面だ。5人で足りる場面もあれば、50人でも足りない場面もある。どちらを選ぶかは、何を知ろうとしているかによって決まる。 --- Nielsenの5人説が本当に言っていること Nielsenのモデルは、ユーザビリティテストにおける問題発見率の累積曲線に基づいている。同一のユーザーグループの中で、テスト参加者が1人増えるごとに新しい問題が発見される確率は下がっていく。5人目あたりでその曲線は急激に平坦化し、85〜95%の問題が発見できると推計した。 この議論が成立する前提条件が2つある。 前提1：対象ユーザーが均質なひとつのグループである。複数のセグメントが存在するなら、各セグメントに5人ずつ必要だとNielsen自身も後の論文で補足している。高齢者向けサービスの調査で「20代のヘビーユーザー5人」に聞いても、モデルは機能しない。 前提2：目的がユーザビリティ問題の発見（バグ探し）である。UIの操作ミスや理解できない表現を探す作業には、この推計が有効だ。しかしインタビューの目的が「なぜその人はそう行動するのか」「どんな文脈で意思決定しているか」「未充足の需要がどこにあるか」という探索的な問いなら、話は変わる。 --- 飽和点理論（Theoretical Saturation）という視点 定性研究の文脈では、サンプルサイズを「飽和点が来るまで」と考えるアプローチがある。 社会学者のグレーザーとストラウスが提唱した「理論的飽和（Theoretical Saturation）」という概念だ。インタビューを重ねていくと、ある時点から新しい概念やカテゴリーが出てこなくなる——そこが飽和点であり、そこまで調査を続けるのが原則、という考え方だ。 実際のプロジェクトでこの原則を厳密に適用するのは難しい。飽和したかどうかの判断が調査者の主観に依存するし、時間とコストの制約もある。ただし「飽和していないことへの自覚」は持てる。「5人に聞いたから終わり」ではなく、「5人で出てきたテーマが安定しているか、まだ新しい話が出てくるか」という問いを持ちながら進むことができる。 Nielsen Norman Groupのリサーチによれば、深いインタビュー（探索的リサーチ）では最低でも6〜12人が推奨されており、複数のセグメントやコンテキストを含む場合は20〜30人以上が望ましいとされる。これは「5人説」とは明確に異なる。 --- 何人必要かを決める4つの問い 具体的なプロジェクトでサンプルサイズを決める時、以下の問いが判断軸になる。 問い1：対象ユーザーは均質か、多様か 対象が「30代の共働き子育て世帯」というように均質なグループであれば、少ない人数でも洞察が安定しやすい。一方で「公共交通機関の利用者全般」のように多様なグループを対象にするなら、セグメント別に調査設計を切り直す必要がある。 ユーザーのセグメントが3つあるなら、最低でも各5〜6人——合計15〜18人が出発点の目安になる。 問い2：何を探しているか（発見か確認か） 探索的リサーチ（仮説がまだない段階での洞察収集）は、サンプル数を増やしてできるだけ多様な観点を集める必要がある。一方で、すでに仮説があって「この課題は本当に存在するか」を確認するリサーチなら、特定の条件に合致するユーザーを絞って深く聞く方が効率的だ。 「何かを発見したい」と「何かを確認したい」では、調査設計が根本的に異なる。 問い3：発言の多様性に対してどれだけ敏感でいたいか インタビューで「3人全員が同じ課題を挙げた」という状況と、「10人中1人だけが挙げた」という状況は、重みが全く違う。少数の声に希少価値があることもある——「ほとんどの人が気づいていない問題を、一部のパワーユーザーだけが認識している」という発見は、プロダクト開発において非常に重要なシグナルになりうる。 ただし、それを1〜2名の発言から判断するのはリスクが高い。少なくとも同じカテゴリーのユーザーを5〜6人見てから、「これは特殊なケースか、それともセグメント内で一定数に共通するか」を判断する材料が揃う。 問い4：調査の目的は探索か意思決定か 調査結果が「次のワークショップのための材料」なのか、「プロダクト方針の転換を裏付けるエビデンス」なのかで、求められる根拠の厚みが変わる。 社内の意思決定者を説得するためのリサーチならば、「5人聞いた」より「18人聞いて、異なる3セグメント間で一貫した課題が確認された」という方が、決裁に対して遥かに強い根拠になる。 --- よくある誤用パターンと実害 誤用1：「5人聞いたので共感フェーズは完了」 5人で十分な場合とそうでない場合がある（前述の通り）。それよりも問題なのは、「完了」として次のフェーズに進んでしまうことで、未発見のインサイトが切り捨てられる点だ。共感フェーズを「タスク」ではなく「状態」として扱う——つまり「どのくらい理解できたか」の問いを持ち続けることが重要だ。 誤用2：「30人のアンケートをとったので定量的に根拠がある」 定量調査は、すでに仮説が立っている問いの確認に有効だ。しかし30人のアンケートが「なぜその行動をとるのか」のWHYを説明することはない。定量と定性は代替ではなく補完関係にある。定量で何が起きているかを把握し、定性でなぜかを掘り下げる——この分業が成立する。 誤用3：「インタビューの数で熱意を証明する」 50人に聞いたことを誇るより、10人に聞いて何が本質的にわかったかを話せる方が、プロジェクトの質は高い。調査の量は質を保証しない。数字を増やすことへのプレッシャーが、浅いインタビューの量産につながる。 --- 実践的な指針：インクリメンタル・サンプリング プロジェクトの文脈でいちばん機能するのは、「一度に何人やるか」を先に決めない方法だ。 最初のバッチとして5〜6人にインタビューし、その段階で「新しいカテゴリーや予想外の観点がまだ出ているか」を確認する。出ているなら次のバッチに進む。出ていないなら飽和に近い状態と判断する。このインクリメンタル・サンプリングのアプローチは、限られた時間の中で調査の質と効率を同時に追いやすい。 バッチごとにアフィニティダイアグラムを更新し、「新しいクラスター」が生まれたかどうかを可視化する。これは调査者のカンだけでなく、チーム全員が「飽和に向かっているか」を確認できる仕組みになる。 もうひとつ重要なのは、誰に聞くかの選定だ。人数よりも「誰を選ぶか」の方が、インサイトの質に対する影響は大きい。エクストリームユーザー（最もヘビーな使い手と最も使わない人）にインタビューすることで、平均的なユーザーへのインタビューでは見えなかった課題の構造が浮かび上がることがある。 --- 「何人」より「何がわかったか」 「何人に聞けばいいか」という問いは、実は「何が知りたいのか」という問いを言い換えたものだ。 Nielsenの5人説は間違っていない。ただし、適用できる条件が限られている。探索的リサーチ、多様なユーザーセグメント、意思決定の根拠を厚くしたい状況では、5人は出発点にすぎない。 「インタビューが完了した」という達成感より、「このフェーズでどの程度の理解が得られたか」という認識の精度の方が、プロジェクトの先に効いてくる。「5人やった、だから充分」は思考停止の一形態だ。「5人やった、ここまでわかった、まだここがわかっていない」という状態の正確な把握が、共感フェーズを本当に機能させる。 定性調査の豊かさは、個々の声の深さにある。数が少なくとも、その人の生活文脈、行動の理由、矛盾、感情の揺らぎを丁寧に記録した調査は、100人の表面的なアンケートより多くを語ることがある。 「何人に聞けばいいか」への最も正直な答えは、「知りたいことが明確になるまで」だ。 --- 関連リソース ユーザーインタビューの設計と実施についてはステークホルダーインタビューの実践ガイドに詳細を整理している。共感フェーズで収集した生の観察をチームの共通理解へと変換する手法についてはエンパシーマップ ステップバイステップガイドを参照されたい。 インタビューで集まったデータの解釈段階で発動するバイアスについてはデザイン思考と認知バイアスで整理している。「わかった気になる」構造を理解しておくと、調査設計の判断が変わる。 --- 参考文献 - Nielsen, Jakob & Landauer, Thomas K., "A mathematical model of the finding of usability problems," Proceedings of ACM INTERCHI '93, 1993 - Nielsen, Jakob, "Why You Only Need to Test with 5 Users," Nielsen Norman Group, March 2000 - Nielsen, Jakob, "How Many Test Users in a Usability Study?," Nielsen Norman Group, June 2012 - Glaser, Barney G. & Strauss, Anselm L., The Discovery of Grounded Theory: Strategies for Qualitative Research, Aldine Publishing Company, 1967 - Creswell, John W., Qualitative Inquiry and Research Design: Choosing Among Five Approaches, 3rd ed., SAGE Publications, 2013 - Patton, Michael Q., Qualitative Research and Evaluation Methods, 4th ed., SAGE Publications, 2014 - Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia University Press, 2011 --- ### 任天堂Switch開発のデザイン思考：「どこでも遊べる」を再定義した共感フェーズ URL: https://designthinking.studio/articles/case-nintendo-switch/ > Wii Uの失敗から任天堂はどう立ち直ったのか。「ゲームは家で一人でやるもの」という前提を疑い、Switchを生んだ共感フェーズとプロトタイピングの試行を解説する。 2017年3月に発売された任天堂Switch（ニンテンドースイッチ）は、2025年時点でシリーズ累計販売台数が1億5000万台を超えるプラットフォームになりました。しかしその前身となった「Wii U」（2012年発売）は、累計販売台数1360万台という、任天堂の歴史の中でも最低水準の失敗作でした。 この転換は偶然ではありません。Switchの開発プロセスには、デザイン思考の核心にあるアプローチ——「前提を疑い、ユーザーの文脈に共感し、徹底的にプロトタイプを試す」——が貫かれていました。 Wii Uはなぜ失敗したのか Wii Uの失敗要因は複合的ですが、デザイン思考の観点から最も重要なのは「ユーザーの文脈を誤認した」点です。 Wii（2006年発売）は「ゲームをしない人がゲームを始める」という問題を解いた傑作でした。モーションコントローラーによる直感的操作が、高齢者やゲーム初心者を取り込みました。Wii Uはその成功体験を引き継ごうとした製品です。 しかしWii Uが設定したユーザーモデルは、2012年の現実と乖離していました。「テレビの前で家族みんなで遊ぶ」というモデルです。スマートフォンが普及し、個人が画面を持ち歩くことが当たり前になった時代に、「大画面テレビ+手元コントローラー」の体験が再び新鮮に感じられると期待した。この前提の検証が、開発プロセスの中で十分に行われなかったと見ることができます。 --- 「前提を疑う」ことから始まったSwitch 問い直しの起点 任天堂がSwitch開発で最初に行ったのは、「ゲームはどこでどのように遊ばれているか」の再調査です。 プロデューサーの川本正人氏（後に説明会等で語っている）と開発チームが注目したのは、スマートフォンゲームの台頭でした。2013年以降、モバイルゲームの市場が急成長していた。しかしこの事実の解釈を、多くの企業がやるように「スマートフォンがゲーム機を駆逐している」と読むのではなく、「なぜ人々がスマートフォンでゲームをするのか」という問いに変換したのです。 答えは「スマートフォンゲームが面白いから」ではありませんでした。「スキマ時間に、持ち歩いている端末で、いつでもどこでも遊べる」という利便性でした。ゲームとしてのクオリティや深さでは、専用ゲーム機には及ばない。それでも遊ばれるのは、「プレイ可能な文脈の多さ」が圧倒的だからです。 「家で遊ぶ」という前提の解体 この洞察から、Switchのチームは「任天堂のゲームをどんな文脈でも遊べるようにするにはどうすればいいか」という問いを立てました。 デザイン思考の問題定義フェーズの観点では、これは「競合はスマートフォンゲームではなく、プレイを妨げる状況（帰宅していない、テレビが空いていない等）だ」という問題定義の転換です。 携帯ゲーム機は既に「3DS」がありました。しかし3DSと据置機は別システムで、ユーザーは「家では高品質な据置ゲームを、外では3DSを」という二つのプラットフォームを管理する必要がありました。 「家でも外でも同じ体験が続けられる」というシームレスさが、真に解くべき問題だった——これがSwitchのチームが到達した問題定義です。 --- プロトタイピングの試行回数 Joy-Conの着脱機構 Switchで最も革新的な機構は「Joy-Con」の着脱システムです。コントローラーが本体に装着されているとき（据置モード）と、外れているとき（携帯モード）で、ゲームの体験がシームレスに切り替わる。 この機構には、多数の物理プロトタイプが作られました。任天堂の開発者へのインタビューによれば、着脱機構の試作だけで数十パターンを作成したとされています。 特に検討されたのは以下の課題です。 耐久性と利便性のトレードオフ：着脱を繰り返すことで生じる摩耗。素材選定と接合方式の組み合わせを変えながら、繰り返し着脱試験を行いました。 片手持ちへの対応：Joy-Conを1本ずつ持って2人プレイをするというコンセプトは、1本のJoy-Conが「1プレイヤーの最小単位」として機能することを要求しました。これはコントローラーの最小サイズとボタン配置の制約を意味し、製造上の難易度を大幅に上げました。 接続安定性：ワイヤレス通信のラグとバッテリー消費のバランスも、試作段階で繰り返し検証されました。 「テーブルモード」の発見 Switchには「テーブルモード」と呼ばれる使用形態があります。本体を卓上スタンドで立て、Joy-Conを左右に持って遊ぶスタイルです。当初の開発コンセプトには、このモードは「必須の機能」として存在していたわけではありませんでした。 プロトタイピングの過程で、「旅行中の飛行機や新幹線の中でゲームを遊ぶ」という場面を試作品で実際に試したとき、「テーブルに立てて2人で遊ぶ」という使い方が自然に発生したとされています。これは設計者が想定した使い方ではなく、プロトタイプの文脈での観察から発見されたシナリオです。 --- 「ゲームを共有する体験」の再設計 Switchのローンチトレーラーが世界に公開されたのは2016年10月でした。このトレーラーは製品仕様の説明ではなく、「Switchがある生活の情景」を描いた映像です。 - 家でテレビに接続して遊んでいた人が、外出する際にゲームをそのまま持ち出す - 出張先のホテルの部屋でゲームを続ける - 友人の家でJoy-Conを分け合って一緒に遊ぶ - 公園でSwitchを持ち寄ってゲーム対戦をする これらのシーンはすべて、開発チームが共感フェーズで「ゲームはどのような文脈で遊ばれているか」を調査した結果から抽出されたシナリオです。 注目すべきは「友人と共有する体験」の描き方です。スマートフォン時代のゲームは本質的に個人体験（ヘッドフォンをして一人で遊ぶ）ですが、Switchのシナリオでは常にゲームを「持ち寄る」「分け合う」「一緒に遊ぶ」という社会的な場面が設定されています。 「ゲームで繋がりたい」という潜在的欲求——単に一人で暇をつぶすのではなく、ゲームを通じて誰かと時間を共有したいという願望——に、Switchは正確に応えました。 --- 失敗から学ぶプロセス設計 デザイン思考の実践者にとって、SwitchとWii Uの対比は「前提検証の重要性」を示す明快な事例です。 Wii Uの開発は、「Wiiの成功体験」という強い先入観の中で行われたと見ることができます。「テレビ+コントローラー」という成功の図式を疑わなかった。ユーザーの現実（スマートフォンが普及した生活）と、開発者のモデル（家族でテレビの前に集まる生活）の間に生じたギャップが、結果に現れました。 Switchでは、この失敗の経験が「自分たちが当然だと思っている前提を、まず疑う」という姿勢につながりました。 デザイン思考の共感フェーズは、ユーザーの「言葉」を聞くだけでは完結しません。ユーザーが「どんな文脈でゲームをしているか（あるいはしていないか）」という観察が核心にあります。任天堂のチームが気づいたのは、ゲームをしていない時間こそが問題の所在だったということです。 --- 参考文献 - 任天堂株式会社、「Nintendo Switch 開発者インタビュー」、任天堂公式サイト、2017年 - 川本正人、「Nintendo Switch 設計の思想」、ゲーム開発者会議GDC 2017 講演資料 - 塩田信之、「任天堂の次を読む力」、日経デジタルビジネス、2017年 - Bloomberg, "Nintendo Switch: Inside the Design Process", Bloomberg Technology, March 2017 - Yuji Naka and the Switch design team interviews compiled in Game Developers Conference proceedings, 2017 --- ### 病院UXとデザイン思考 — 患者体験を根本から再設計するフレームワーク URL: https://designthinking.studio/articles/design-thinking-hospital-ux/ > 患者ジャーニーマッピング、共感インタビュー、プロトタイピングを軸に、病院UXをデザイン思考で再設計する実践的アプローチを解説。国内外の医療現場の事例を交えながら、どこから手をつければいいかを具体的に示す。 病院のUXをデザイン思考で改善しようとしたとき、ほとんどのプロジェクトは「受付フォームをデジタル化する」「院内サインを見直す」といった個別施策の列挙で終わります。ワークショップでよく起こるのは、チームが「患者の不満」を起点に議論を始め、気づけば「システム改修の要件定義」に変わってしまうというパターンです。 本記事では、病院UXにデザイン思考を適用する際の構造的アプローチを整理します。どのフェーズで何をやるのか、何が難しいのかを、現場経験に基づいて具体的に説明します。 --- なぜ病院UXはこれほど難しいのか 病院体験の特殊性は「患者の状態が通常の消費者行動とまったく異なる」ことにあります。実際にやってみると、ユーザーリサーチの対象が「重篤な不安を抱えた人」「痛みの中にいる人」「家族の病状に動揺している人」であることの重さに直面します。 脆弱性の問題。 UXリサーチの標準的な手法は「インタビューへの同意」「行動観察への協力」を前提にしています。しかし患者は治療を求めて来院しており、リサーチへの参加はあくまで副次的な行為です。倫理委員会の承認プロセス、患者への説明と同意取得、データの匿名化要件——これらはデザイン思考の「素早い学習サイクル」と根本的な緊張関係にあります。 専門家文化の壁。 医師・看護師は長い専門訓練を経て「正解を知っている専門家」として機能するよう訓練されています。デザイン思考が求める「初心者の目線で観察する」「前提を疑う」という姿勢は、この文化と摩擦を生みます。参加者からの声として「患者に何が問題か聞くのは、専門家としての判断を疑わせる行為に見える」という発言は、複数の病院UXプロジェクトで繰り返されてきました。 非連続な体験構造。 患者の体験は病院内だけで完結しません。「症状の認識→検索→予約→来院前の準備→来院→待機→診察→処置→帰宅→服薬→予後確認」という全体プロセスのうち、病院がコントロールできるのは一部分に過ぎません。「院内だけを改善しても体験は変わらない」という認識を、プロジェクト冒頭でチーム全体に共有することが必要です。 --- Phase 1：共感——患者の時間軸で観察する 病院UXの共感フェーズで最も重要な問いは「患者体験はいつ始まり、いつ終わるか」です。 サービスブループリントで「見えないプロセス」を可視化する サービスブループリントは、病院UXの共感フェーズに特に有効なツールです。縦軸に「患者の行動」「フロントステージ（患者と直接接する接点）」「バックステージ（患者からは見えない業務プロセス）」「サポートシステム（IT・施設）」を並べ、横軸を時間の流れとして整理します。 これを作ると多くの病院で共通して見えてくるのは、「患者が最も不安な瞬間（診断待ち・検査結果待ち）に、バックステージでは書類の受け渡しが発生しており、患者への情報提供が構造的に抜け落ちている」という事実です。 同行観察（シャドーイング）の実施 患者の許可を得て、受付から帰宅まで（あるいは入院の場合は複数日）を同行観察します。記録するのは「患者が立ち止まった場所」「表情が変化した瞬間」「スタッフに声をかけようとして躊躇した場面」です。 実際にやってみると、病院では「患者が分からないことを聞けない雰囲気」が構造的に形成されていることが分かります。受付カウンターの高さ、スタッフの動線のスピード、「番号でお呼びします」というアナウンスの形式——これらすべてが「患者は受動的に待つべき存在」というシステム設計のメッセージを発しています。 --- Phase 2：問題定義——「正しい問い」を立てる 共感フェーズで集めた観察データを、どう問いに変換するかが病院UXの核心です。 How Might We の落とし穴 「どうすれば待ち時間を短縮できるか（HMW）」という問いは病院でよく出てきますが、これは解決策を暗示した問いです。待ち時間そのものではなく、「待ち時間中の不確実性」が問題である場合が多い。「どうすれば患者が待機中に自分の状況を把握できるか」に変えると、解決策の幅が大きく広がります。 航空業界では、搭乗口の電光掲示板が「残り何分で搭乗開始か」をリアルタイムで表示するようになって以来、搭乗口での混雑苦情が激減しました。待ち時間が変わらなくても、不確実性の管理だけで体験は変わります。この原則は病院の待機設計にそのまま応用できます。 ポイント・オブ・ビュー（POV）文の作成 POV文は「[ユーザー名]は、[ニーズ]を必要としている。なぜなら[インサイト]だから」という形式で、特定の患者像に基づいた問題定義を行います。 病院UXの典型的なPOV文の例：「初めて大きな病院に来た60代の田中さんは、自分の検査が今どの段階にあるかをリアルタイムで知る方法を必要としている。なぜなら『分からない』という状態が、病気そのものへの不安と重なって、極度のストレスを生むからだ」 --- Phase 3：創造——解決策を爆発させる 病院UXのアイデア創出で有効なアプローチは「他の業界からの越境借用」です。 航空業界からの借用： 搭乗口・手荷物・搭乗案内の構造を、受付・検査・診察待ちに転用する。 ホテル業界からの借用： チェックイン時の「本日のご案内」を、来院時の「本日の診察フロー説明」に転用する。担当ナースが患者の部屋を訪問する「バトラーモデル」を外来診察のコーディネーターモデルに転用する。 Uberからの借用： 配車アプリの「ドライバーが今どこにいるか」のリアルタイム表示を、「担当医師が今何をしているか（手術中・別の診察中・間もなく呼び出し）」の表示に転用する。 --- Phase 4：プロトタイプ——コストゼロで始める 病院UXのプロトタイピングで最も有効なのはサービスプロトタイプ（物理的な製品ではなく、人のふるまいや情報フローを試すプロトタイプ）です。 紙のシミュレーションから始める 「検査待ち中の状況通知」をテストするとき、最初はシステム開発は不要です。看護師が15分おきに待合室を巡回し「○○さん、現在レントゲン結果を医師が確認中です。あと30分ほどお待ちください」と口頭で伝えるだけのプロトタイプから始めます。 これで「患者の不安が下がるか」「スタッフの負担が増えすぎないか」「どのタイミングで伝えれば効果的か」を低コストで検証できます。システム化はその後です。 「スケールしないプロトタイプ」を恥ずかしがらないこと。 多くの病院プロジェクトで「こんな手作業のテストでは本当の効果は分からない」という懐疑が出ます。しかし、手作業のプロトタイプで効果が出なければ、システム化しても効果は出ません。逆に手作業で効果が確認できれば、システム化の根拠ができます。 --- Phase 5：テスト——患者のリアクションから学ぶ 病院UXのテストフェーズで重要なのは「患者が本当に思っていることを引き出す」技術です。 患者は「病院のお世話になっている」という気持ちから、否定的なフィードバックを控える傾向があります。「この改善は役に立ちましたか？」という直接的な質問では「はい」という答えが返りやすい。 代わりに「前回と今回で、待っている間の気持ちは変わりましたか？ どんな違いがありましたか？」という行動の変化を問う形式にすると、実感に基づいた具体的な回答が引き出せます。 --- 日本の病院でデザイン思考を始めるには 「いきなり大規模なUX改善プロジェクトは難しい」という声に対して、実際の進め方として有効なのは「患者の声を集める仕組みだけを先に作る」アプローチです。 退院時アンケート、待合室の定点観察、月に1回の患者インタビュー——これだけを3ヶ月継続すると、「私たちが問題だと思っていたことと、患者が問題だと感じていることが全然違う」という発見が必ず出てきます。この発見がデザイン思考の起点になります。 --- やってみよう - 患者として自分の病院を体験する — 受付から診察終了まで、患者の立場で動いてみる。スタッフには事前に伝えておくと観察者バイアスが出るため、可能なら告知なしで実施する - サービスブループリントを1枚書く — 「外来患者の一般的な受診フロー」を付箋とホワイトボードで可視化する。バックステージの業務を書き込んだとき、患者への情報連携が抜けている箇所が必ず見つかる - 1人の患者に30分インタビューする — 「先月の受診体験を最初から教えてください」という開かれた問いから始める。良い点・悪い点を聞くのではなく、体験の物語を語ってもらう --- 参考文献 - Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth: A Design Thinking Toolkit for Managers, Columbia Business Press, 2011 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Bohmer, Richard M.J., Designing Care: Aligning the Nature and Management of Health Care, Harvard Business Press, 2009 - Maister, David M., "The Psychology of Waiting Lines", Harvard Business School Working Paper, 1985 - Shostack, G. Lynn, "Designing Services That Deliver", Harvard Business Review, January–February 1984（サービスブループリントの原論文） --- ### 保険業界にデザイン思考を実装する——「請求という不信の瞬間」を信頼の体験に変える URL: https://designthinking.studio/articles/design-thinking-insurance-claims-experience/ > 保険金請求という、契約者が最も不安を抱える接点にデザイン思考を適用する。デジタル化するほど不信が強まる逆説の構造を分析し、審査担当者と請求者の両面に共感を当てる設計、透明性のプロトタイピングという実装パターンを提示する。 保険金を請求した経験がある人に話を聞くと、複雑な書類よりも先に、ある感覚が語られることが多い。「事実確認のはずの質問なのに、自分が嘘をついていないか探られている気がした」という感覚だ。 保険会社の多くが、この不満に対して「手続きを簡素化する」という答えを出してきた。オンライン請求フォーム、AIによる書類自動判定、チャットボットでの進捗確認——投資は積み上がっている。だが体感の不信は、それに比例して減っているとは言い難い。むしろデジタル化が進むほど「機械的に処理されている」という感覚が強まる場面すらある。 これは効率化の失敗ではない。問いの立て方の失敗だ。 速さを問う前に、何を問うべきか。デザイン思考の視点からこの逆説を分解し、保険業界特有の実装パターンを示す。 --- 効率化が信頼を壊す逆説——保険金請求というワーストケースの接点 保険という商品には、他の商品にはない構造的な特徴がある。契約時点では何も受け取らない。受け取るのは「約束が果たされるかどうか試される瞬間」——つまり事故や病気が起きた後、請求という手続きを通してだけだ。 顧客が最も心理的に弱っている瞬間に、企業側は最も慎重に事実確認を行う必要がある。この2つの要請は本質的に緊張関係にある。効率化のためのデジタル化は、この緊張関係そのものには触れずに「処理速度」だけを最適化してしまいやすい。結果として、応答は速くなったのに、請求者が感じる「疑われている感覚」は解消されないという状態が生まれる。 情報の非対称性が不信の根本原因である 請求者から見えている情報と、保険会社側が持っている審査基準の間には、大きな非対称性がある。何を提出すればよいのか、提出した後どのような基準で判断されるのか、今どの段階にあるのか——これらが不透明なまま「待たされる」状態に置かれると、人は不確実性を「不信」として解釈する傾向を持つ。 つまり請求プロセスの不満の多くは、待ち時間の長さそのものより、待たされている理由が見えないことに起因している。ここを見誤ると、フォームを簡素化しても、チャットボットを導入しても、体感の不信は残り続ける。 想像してみてほしい。請求から3日後、進捗欄には「審査中」の一言だけが表示されている。何を審査しているのか、あと何日かかるのか、追加で何か必要なのかは一切わからない。この「審査中」という3文字が、実は最もコストのかからない不信の発生装置になっている。 --- 「両面共感」という保険業界特有のデザイン思考実装 一般的なユーザー中心設計は、共感マップを顧客側にだけ当てる。だが保険金請求という接点では、審査担当者側の構造的なジレンマを理解しないまま設計すると、施策は表層のUI改善で終わってしまう。 審査担当者は「性善説で処理すれば不正請求のリスクが増える」「性悪説で処理すれば正当な請求者を傷つける」という、常に相反する2つのリスクの間でバランスを取る役割を担っている。この緊張は請求フローの設計者が意識しなければ、フォームの隅々に「疑いの姿勢」としてにじみ出る。逆に言えば、この緊張を可視化できれば、設計で緩和できる余地があるということでもある。 保険業界での実装で有効なのは、共感マップを請求者だけでなく審査担当者にも当てる両面共感というアプローチだ。審査担当者が「何を見て」「何を聞いて」「何を感じて」「何をするか」を可視化すると、担当者が本当に必要としている情報と、請求者に求めている情報の間にズレがあることが見えてくる。多くの現場で、担当者の判断に不要な項目が「念のため」という理由だけで請求フォームに残り続けている構造が見つかる。 リフレーミングによる問いの再定義 両面共感から生まれる典型的な転換は、「不正を見抜くフロー」から「信頼を確認し合うフロー」への問いの再定義だ。前者は請求者を疑いの対象として扱う設計になりやすいが、後者は審査担当者と請求者が同じ情報を共有しながら手続きを進める設計を志向する。 具体的には、審査で何を確認しているかを事前に請求者へ開示する、確認理由をその場で一言添える、といった小さな介入が該当する。同じ書類を求めるとしても、なぜそれが必要かという文脈を添えて渡すことが核心になる。文脈が渡されるだけで、同じ質問への心理的な受け止め方は変わる。 --- 透明性のプロトタイピング——保険特有の解決アプローチ 情報の非対称性が不信の根本原因であるなら、解決の方向性は「透明性を段階的に試作すること」になる。進捗状況の可視化、審査基準の一部開示、想定所要日数の明示——これらは物流業界の配送トラッキングUXの表層的な模倣として導入されがちだが、保険における目的はそれとは異なる。物流の進捗表示は「いつ届くか」という利便性のための情報だが、保険の進捗表示は「なぜ今この段階にいるのか」という納得のための情報である。この目的の違いを見失うと、進捗バーだけを追加して満足してしまう。 業界動向としては、請求プロセスの一部をデジタル化しながら透明性を高めようとする取り組みが各社で模索されている段階にあり、正解の形はまだ探索途中にある。だからこそデザイン思考が有効な領域でもある——大規模な刷新を一度に行うより、小さく試して検証を重ねる進め方が適している。 小さく試す設計 透明性の向上は、全請求カテゴリに一斉導入する必要はない。たとえば手続きが定型化しやすい一部の請求カテゴリだけに絞って、審査の各段階を請求者に開示するパイロットを走らせ、問い合わせ件数や満足度の変化を見てから対象を広げるという進め方が、保険業界の規制・リスク管理の重さと相性がよい。 一度に全社展開しようとすると、コンプライアンス部門との調整だけで施策が止まってしまう（規制業種の設計現場では、この「調整コスト」こそが最大の摩擦になることが多い）。デザイン思考の「小さく作って、確かめて、広げる」という基本動作は、保険業界のようにリスク回避の文化が強い業界ほど、実は導入のハードルを下げる働き方として機能する。 --- 効率指標だけでは請求体験の本質を見誤る 請求処理のスピードやNPSといった効率指標は、もちろん重要な観測点だ。しかしそれだけを追いかけると、「速く処理されたのに、なぜか信頼されなかった」という結果に行き着くことがある。請求という接点で問うべき本当の問いは、「どこで不信が生まれ、どこで解消されたか」だ。 自社の請求フローを一度、処理時間ではなく不信が生まれる瞬間で棚卸ししてみると、これまで見えていなかった介入点が見つかるはずだ。 保険以外の規制業種でデザイン思考がどう機能しているかは、金融サービスの実装パターンとKPI設計で扱っている。また、両面共感のような定性的な観察を定量データとどう組み合わせるかについては、定量データと定性インサイトを統合する共感の設計を参照してほしい。 --- ### 問題定義フェーズ——本質的な問いを設定する技術 URL: https://designthinking.studio/articles/define-phase/ > デザイン思考の第2フェーズ「問題定義（Define）」を解説。観察結果の統合からPoint of View（POV）の設定、How Might We（HMW）の活用まで。 問題定義（Define）は、共感フェーズで得た情報を統合し、解くべき本質的な問題を明確にするフェーズです。 問題定義の目的 共感フェーズで集めた大量の情報——観察メモ、インタビュー記録、写真——をそのまま使うことはできません。これらの情報を整理・統合し、チーム全体が共有できる明確な問題文（Problem Statement）を作成することが、このフェーズの目的です。 親和図法（KJ法）を使ってインタビューデータをグルーピングすることで、個別の発言からパターンとインサイトを引き出します。 Point of View（POV） d.school では、問題文を「Point of View（POV）」と呼びます。POVは以下の形式で記述します。 [ユーザー]は[ニーズ]を必要としている。なぜなら[インサイト]だからだ。 例えば「通勤者は移動時間をもっと有意義に過ごしたいと思っている。なぜなら、毎日の通勤が人生の浪費だと感じているからだ」のように記述します。 良いPOVの条件は以下の通りです。 - 具体的であること — 誰の、どんな問題かが明確 - インサイトに基づくこと — 表面的なニーズではなく、深層のニーズを反映 - 解決策を含まないこと — 「how」ではなく「what」と「why」に焦点 How Might We（HMW） POVが設定されたら、それを「How Might We（HMW）」形式の問いに変換します。HMWは「私たちはどうすれば〜できるだろうか？」という形式で、創造フェーズへの橋渡しとなります。 良いHMWは、広すぎず狭すぎない適度な範囲を持ちます。「どうすれば世界を良くできるか」は広すぎ、「どうすればボタンの色を決められるか」は狭すぎます。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、問題定義フェーズが「地味で退屈」という理由で駆け足になるパターンです。付箋を貼ったら終わり、グルーピングをしたら終わり、と次の発散（Ideate）に急ぐチームが多い。 実際にやってみると、POVステートメントを書いてチームで読み上げたとき「これ、誰の問題か全然見えない」と気づくことがあります。その瞬間が大切で、焦って次に進んでいれば共感フェーズの全作業が無駄になっていたかもしれません。「書いてみて初めて分かる」がDefineフェーズの本質です。 書いて、読み上げて、違和感があれば書き直す。その繰り返しが問いの精度を上げます。 まとめ 問題定義フェーズは、共感と創造をつなぐ重要な橋渡しです。正しい問題を設定できれば、解決策は自然と生まれてきます。ダブルダイヤモンドモデルでは、このフェーズへの十分な時間投資が成否を分けると強調しています。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - Design Council, "What is the framework for innovation? Design Council's evolved Double Diamond", designcouncil.org.uk, 2019 - IDEO, HCD Toolkit: Human Centered Design, IDEO, 2009 --- ## ツール・手法 ### 5 Whys（5回のなぜ） URL: https://designthinking.studio/methods/five-whys/ > 表面的な症状から根本原因を掘り当てるための問いの連鎖。「なぜ」を5回繰り返すことで、思い込みを剥がし、本質的な課題を可視化する問題定義の技法。 5 Whys（5回のなぜ）は、問題の表面的な症状ではなく、根本原因を掘り当てるための問いの連鎖技法です。問題定義フェーズで最もシンプルかつ強力なツールのひとつで、「なぜ？」という問いを5回繰り返すことで、思い込みを剥がし、本質的な課題を可視化します。 概要 ワークショップでよく起こるのは、チームが「問題だと思っていること」と「本当の問題」がずれているケースです。たとえば「ユーザーがアプリを使い続けない」という課題に対して、すぐに「UIを改善しよう」という解決策へ飛びつく。しかし実際にやってみると、なぜを掘り下げた先に「そもそも価値提供自体がずれている」という根本原因が見えてくることがよくあります。 5 Whys はもともとトヨタ生産方式の父・大野耐一が製造ラインの問題解決に用いたフレームワークです。デザイン思考では、ユーザーリサーチで得た観察や発言を起点に、インサイトを掘り下げるプロセスとして広く応用されています。 ステップ Step 1：問題文を書く ホワイトボードの中央に、観察された問題や行動をひとつ書きます。主語と動詞を含んだ具体的な文にすることが重要です。「アプリの離脱率が高い」ではなく「新規ユーザーの70%が3日以内にアプリを削除する」のように、数値や行動を入れると掘り下げが深まります。 Step 2：最初の「なぜ？」を問う 「なぜそれが起きているのか？」とチームに問い、思いつく理由を全員から引き出します。この段階では多様な視点を収集することが優先で、正解を急ぐ必要はありません。複数の「なぜ」が出てきたら、それぞれの枝を独立して掘り下げます。 Step 3：「なぜ？」を4回繰り返す 最初の答えに対して再び「なぜそうなるのか？」と問います。これを計5回繰り返すことで、原因の連鎖が見えてきます。 5回という数字は目安であり、3回で根本原因に到達する場合もあれば、7回必要な場合もあります。重要なのは「もう答えられない」というレベルまで掘り下げることです。 Step 4：根本原因を特定する 連鎖の末端にある原因が根本原因の候補です。「この原因を解決すれば、連鎖上のすべての問題が解決される」という確認を行います。根本原因はしばしば、組織のプロセス、インセンティブ構造、コミュニケーションのズレといった「システム的な問題」に行き着きます。 Step 5：How Might We へ変換する 特定した根本原因をHow Might We（HMW）の問いに変換することで、問題定義フェーズから創造フェーズへの橋渡しができます。「ユーザーが価値を認識する前に離脱してしまう」という根本原因なら、「どうすれば初日のユーザーに価値を実感してもらえるか？」という問いになります。 実例：飲食店の予約キャンセル問題 あるレストランでの事例を見てみましょう。 問題文： 予約当日のキャンセルが月20件以上発生している - なぜ？→ キャンセルの連絡をするのが面倒だから - なぜ？→ 電話しか受付手段がなく、営業時間中しか対応できないから - なぜ？→ キャンセル受付の仕組みを電話以外に整備したことがないから - なぜ？→ 「予約はリアルタイムで確認したい」という思い込みがスタッフにあるから - なぜ？→ 予約管理システムを導入したことがなく、手動管理が前提になっているから 根本原因： 予約管理の業務フローが「リアルタイム手動対応」を前提に設計されており、非同期のキャンセル受付を想定していない。 この例から分かるように、最初に見えている「キャンセルが多い」という症状と、根本原因の間には5ステップの距離があります。UIを改善しても、プロセスを変えなければ問題は解決しません。 ファシリテーションのコツ チームで問うことの価値 5 Whys は個人で行うより、多様な視点を持つチームで行う方がはるかに質が高くなります。 エンジニア、デザイナー、ビジネス担当者が同じ問いに向き合うと、それぞれの専門知識から異なる「なぜ」が出てきます。この交差点に根本原因が隠れていることが多いです。 「なぜ」の品質を上げる問いかけ 「なぜですか？」という直接的な問いは、反射的な「分からない」を引き出すことがあります。代わりに「何がそうさせているのでしょうか？」「どんな状況がそれを引き起こしていると思いますか？」というプロセスを問う形に変えると、より深い考察が出やすくなります。 仮説と事実を分ける 5 Whys のセッション中に出てくる「なぜ」は、多くが仮説です。付箋の色を変えるなど、「確認済みの事実」と「チームの仮説」を視覚的に区別することで、後から検証すべきポイントが明確になります。 よくある失敗と対策 症状を問題文にしてしまう 「ユーザー満足度が低い」のような曖昧な問題文を起点にすると、「なぜ？」の答えも曖昧になります。問題文は観察された具体的な行動や数値から始めるのが鉄則です。ユーザーインタビューや行動データを参照して、問題文を具体化しましょう。 答えを誘導してしまう すでに解決策を持っているファシリテーターが「なぜ機能が少ないのだと思いますか？」と誘導的に問うケースがあります。「なぜ」の答えはチームから引き出すものであり、ファシリテーターが用意するものではありません。 オープンな問いを保ち、全員の声を拾う場を作ることが重要です。 「分からない」で止まってしまう 根本原因に近づくにつれ、「なぜそうなっているか分からない」という状況が出てきます。これは根本原因への到達のサインでもあり、次に何を調査すべきかのヒントでもあります。「分からないこと」をホワイトボードに書き出し、リサーチのアジェンダとして扱いましょう。 ポイント - 問題文を具体化する — 行動・数値・文脈を含んだ文から始める - チームで掘り下げる — 多様な専門性が「なぜ」の質を上げる - 仮説と事実を区別する — 後の検証計画に活かす - 5回は目安 — 根本原因に到達したと思えるまで継続する - HMWへつなぐ — 根本原因を問いに変換して創造フェーズへ進む 5 Whys で特定した根本原因は、How Might Weに変換して創造フェーズへと持ち込みます。また、ユーザーインタビューの分析時に親和図法（Affinity Diagram）と組み合わせることで、複数のインサイトを体系的に整理できます。 より体系的にユーザーの感情・思考・行動を構造化したい場合は、エンパシーマッピングを活用することで、5 Whys による根本原因特定の前段階で、ユーザーの全体像を多層的に把握できます。 --- 参考文献 - Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### Crazy 8s（クレイジーエイト） URL: https://designthinking.studio/methods/crazy-eights/ > 8分間で8つのアイデアをスケッチする高速アイデア発想ワークショップ手法。 Crazy 8s（クレイジーエイト）は、Google Ventures の Design Sprint で広く知られるようになった高速アイデア発想手法です。 概要 A4用紙を8つに折り、各マスに1分ずつ、合計8分間でアイデアをスケッチします。時間制限によって「考えすぎ」を防ぎ、直感的なアイデアを引き出します。 なぜ効果的か - 時間制限が完璧主義を排除する — 1分では「良いアイデア」を考える余裕がなく、思いついたものをそのまま描くしかない - 量が質を生む — 最初の2-3個は「当たり前の」アイデアだが、後半になるほど新しい発想が出やすい - 全員が平等に参加できる — 声の大きい人が場を支配することがない - 視覚化が議論を促進する — 言葉だけでは曖昧なアイデアが、スケッチにすると具体化される 実施の手順 - A4用紙を半分に3回折り、8マスを作る - タイマーを8分にセット - 1分ごとにアラームを鳴らし、次のマスに移る - 8分後、全員のスケッチを壁に貼り出す - 各自が気に入ったアイデアにドットシールで投票 - 票の多いアイデアについて短い議論を行う 紙とペンが基本形ですが、リモートのワークショップではMiroやFigJamなどのデジタルホワイトボードでも同じ手順で無理なく進められます。各自のフレームを8分割し、共有タイマーを画面に映しておけば、対面に近い緊張感を再現しやすくなります。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、1分ごとのタイマーアラームを「もう少し待ってください」と無視し始めるパターンです。初めて参加する方は「1分では描けない」と感じ、2〜3分かけてしまう。すると後半のコマに時間がなくなり、本来8個出るはずのアイデアが4〜5個で止まります。 実際にやってみると、タイマーを厳守した回の方が圧倒的にアイデアの多様性が広がります。 1分で「描ける」ものしか描けないという制約が、参加者を直感的な発想に向かわせるためです。最初の2〜3コマは誰でも同じような案が出ます。4コマ目あたりから「仕方なく変なことを描く」状態になり、そこから面白いアイデアが出始めます。 ポイント - 絵のうまさは関係ない（棒人間でOK） - 言葉での補足を加えてもよい - 最初は練習ラウンドを入れると参加者が安心する - HMWを大きく書いて見える場所に貼っておく - 完成したスケッチはストーリーボードやプロトタイプのたたき台になる - もっと発想の幅を広げたい場合は、応用テクニック（強制多様性・最悪案変換・リモート実施ガイドなど）をまとめた応用編へ --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint, Simon & Schuster, 2016（火曜日のSketchセクション） --- ### Desirability Testing と DVF フレームワーク——「欲しい」を三軸で検証する設計思想 URL: https://designthinking.studio/methods/desirability-testing-dvf-framework/ > IDEO が提唱する DVF（Desirability / Feasibility / Viability）における Desirability の理論的位置づけを整理し、Reaction Cards 以外の検証手法（感情語彙インタビュー・比較ランキング・行動観察統合）の選択基準と実施手順を解説する。 「DVF の D が弱い」という指摘を会議で受けたとき、次にどう動くべきか分からなかった——そういう声をワークショップでよく聞く。 DVF（Desirability / Feasibility / Viability）は IDEO が提唱した検証の三軸だ。「Desirability を検証する」と言われると、多くのチームが Reaction Cards に一直線に向かう。しかし Reaction Cards は Desirability 検証の一手段に過ぎない。 「欲しいと思うか」を測る問いに対して、手法の選択肢は複数ある。 どの場面で何を選ぶかが分かっていないと、手法が目的化して検証の質が落ちる。 本稿は、DVF における Desirability の理論的位置づけを整理したうえで、Reaction Cards 以外の検証手法と、その選択基準を実務レベルで解説する。 --- DVF フレームワークとは何か DVF は Tim Brown と IDEO が体系化した、イノベーション設計の評価枠組みである。2009年に出版された Tim Brown の著書 Change by Design（邦訳『デザイン思考が世界を変える』、早川書房、2010年）において明示されており、IDEO の実践を通じて広まった。 三軸の定義は以下の通りだ。 | 軸 | 問い | 検証の主体 | |---|---|---| | Desirability | 人々がそれを欲しいと思うか | ユーザーリサーチ、テスト | | Feasibility | 技術的・組織的に実現可能か | エンジニアリング、オペレーション | | Viability | 事業として持続できるか | ビジネスモデル、財務 | IDEO の定義では、三軸が重なる領域に「優れたイノベーション」が宿るとされる。どれか一軸だけを満たしても、イノベーションとして機能しない。 技術的に動くが誰も欲しがらないプロダクト（F あり D なし）、欲しがられるが事業として持続しないサービス（D あり V なし）は、実際のプロジェクト現場に無数に存在する。 D と F・V の相互作用 DVF の三軸は独立していない。D の検証結果が F と V の設計を更新する。 たとえば、ユーザーインタビューで「使いたいが価格が高すぎる」という Desirability の限界が見つかった場合、Viability の収益設計を見直す必要が生じる。「欲しいが、毎日使いたいわけではない」というインサイトは、サブスクリプション型から従量課金型への Viability 再設計を示唆する。逆に「欲しいが、今の技術では出せない」は Feasibility の壁を浮かび上がらせる。 Desirability Testing は、この相互作用を引き出すための入口に位置している。 D の検証を怠ったまま F・V に多くのリソースを投じると、後続で抜本的な設計変更が必要になるリスクが高まる。 デザイン思考の5フェーズとの対応 D の検証が始まるのはテストフェーズだけではない。共感フェーズのユーザーインタビューも、ある種の D の事前調査として機能する。テストフェーズでの Desirability Testing が他と異なるのは、具体的なプロトタイプや概念に対する反応を測定する点だ。 抽象的な「こういうものがあったら欲しいですか？」ではなく、「この形で見たとき、どう感じますか？」という問いに変わる。 --- Desirability 検証の三つのアプローチ Microsoft Reaction Cards（Benedek & Miner, 2002, "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting"）は代表的な手法だが、状況によって使い分けるべき選択肢がある。 アプローチ1：感情語彙インタビュー プロトタイプを体験した直後に、オープンエンドで「どんな言葉が浮かびましたか？」と問い、参加者自身の言語で印象を語ってもらう方法だ。Reaction Cards と異なり、カードという「選択肢の枠」を与えない。 向いている場面: コンセプトの初期段階で、想定していない感情的反応を探したいとき。カードに載っていない言語が出てくる可能性が高い段階。 手順の骨格: - プロトタイプを体験してもらう（10〜20分） - 体験直後に「今どんな気持ちですか？最初に浮かんだ言葉を教えてください」と問う - 出てきた言葉を付箋に書き取り、参加者に「その言葉を選んだのはどの場面ですか？」と掘り下げる - 複数参加者の語彙を収集後、アフィニティ・マッピングで感情クラスターを整理する 注意点: ファシリテーターが「使いやすかったですか？」のような行動評価に引っ張ってしまうと、感情的印象の語彙が出にくくなる。最初の問いは必ず「気持ち」「印象」の軸に留める。 アプローチ2：比較ランキング法 複数のデザイン案またはプロトタイプを並べて提示し、「どれが最も〇〇に感じましたか？」と感情軸で順位をつけてもらう方法だ。UX リサーチの実務では、単独評価より比較評価の方がユーザーの判断が安定しやすいとされている。 向いている場面: デザイン案が2〜4案あり、感情的な優劣を比較したいとき。A/B テストの前段として、定性的な方向感を確認したいとき。 手順の骨格: - 2〜4案を同一参加者に順番に体験させる（順序効果を打ち消すカウンターバランス設計を推奨） - 全案体験後、「信頼できそうだと感じたのはどれですか？」「また使いたいと思ったのはどれですか？」など感情軸の問いで順位づけを依頼 - 各軸ごとの順位をマトリックスに記録し、感情的優位案を特定する - 「1位に選んだ理由を教えてください」でデブリーフに移行 注意点: 比較ランキングは「相対評価」のため、「最も好き」が「十分に好き」を意味するとは限らない。比較の優勢は、絶対的な Desirability の水準とは別に扱う必要がある。 アプローチ3：行動観察との統合（感情マーカー記録） ユーザビリティテストの観察に感情的反応のマーキングを重ねる手法だ。記録係がタスク実行中の発話・表情・身体反応（前のめり、顔をしかめる、笑う等）に対してリアルタイムでタイムスタンプ付きの感情マーカーを記録する。 向いている場面: ユーザビリティテストをすでに実施する予定があり、追加コストを最小化したいとき。「どの場面で感情が動くか」を時系列で把握したいとき。 手順の骨格: - 通常のユーザビリティテストのプロトコルを組む - 記録係に感情マーカー記録シートを用意する。列は「時刻 / 発話内容 / 表情・身体反応 / 推測感情（仮）」 - テスト終了後、マーカーの時点と一致する画面・タスクを照合し、「どの体験が感情を引き出したか」を特定する - 感情が正負どちらに振れたかは参加者本人に事後確認する（感情を勝手に解釈しない原則） 注意点: 観察者によって同じ表情が「楽しい」「困惑」のどちらに見えるかが異なる。マーカーはあくまで「要確認フラグ」として運用し、解釈は参加者本人との事後確認で固める。推測を事実として記録することが最大のリスクだ。 --- どの手法を選ぶか——判断マトリックス | 条件 | 推奨アプローチ | |---|---| | 初期コンセプト、想定外の反応を探したい | 感情語彙インタビュー | | 複数案あり、感情的方向感を比較したい | 比較ランキング法 | | ユーザビリティテストと同時に実施したい | 行動観察との統合 | | 複数時点での変化を追跡したい | Reaction Cards（比較・追跡に強い） | | ビジネス指標との接続が必要 | Reaction Cards + NPS（感情 ROI 化） | 一つのプロジェクトで複数手法を組み合わせることは合理的だ。 初期段階では感情語彙インタビューで語彙のマップを作り、中期段階で比較ランキング法で方向感を確認し、最終段階で Reaction Cards で定点測定する、という順序設計はよくある実務パターンである。 --- DVF の三軸を実際に動かすまで D の検証から F・V の更新まで ワークショップで実際に起こるのは、D の検証結果を「なるほど、ユーザーに聞けた」で終わらせてしまうことだ。Desirability Testing の結果は、F（Feasibility）と V（Viability）の設計に直接フィードバックして初めて価値になる。 具体的な接続のパターンを整理する。 感情語彙インタビューの結果 → Feasibility への接続例: 参加者から「操作が重そうで怖い」という語彙が複数回出た場合、これは感情的な Desirability の問題だが、実装する機能の応答速度という Feasibility 課題に翻訳できる。エンジニアリングチームへのフィードバックとして「軽快感の体感速度を目標設計に含める」という要件に変換できる。 比較ランキング法の結果 → Viability への接続例: A案（シンプル・機能最小）が B案（高機能・複雑）より感情的に優位だったとする。この結果は、高機能による追加課金モデルよりシンプルなフラット料金の方がユーザーの感情的受容度が高いという Viability への示唆を含む。価格設計の見直しを促すデータとして使える。 よくある失敗——D を F の代替にしてしまう 「技術的には作れるかどうかまだ分からないが、まずユーザーに聞いてみよう」という動機で Desirability Testing を実施するケースがある。しかし、Desirability Testing は Feasibility の代替にはならない。「欲しいと思う」はプロダクトを選ぶ動機だが、「作れる」かどうかは独立した問いだ。 D の検証が先行することで F の検討が後回しになると、「欲しいが作れない」ということが後になって判明し、リードタイムと費用が膨らむ。D と F の検証は並行して進め、どちらかの結果がもう一方を更新する形で往復させるのが現実的な設計だ。 --- 結果をチームで使うための共有設計 Desirability Testing の結果は、ファシリテーターが抱え込むと死蔵される。 感情クラスターマップ: 収集した語彙・選ばれたカード・観察マーカーをプロダクトの画面や体験フローに対応させて壁面に貼る。「どの体験が、どんな感情を引き出したか」が空間として把握できる状態にする。 DVF マッピングへの統合: 感情クラスターマップを DVF の三軸図に重ねる。D 軸で弱い領域が明確になれば、その領域の改善を F・V の誰が担うかをチームで分担できる。 ステークホルダーへの報告: 経営層や開発責任者への報告では、感情的な印象を直接示すより「感情的な弱点がどのビジネス指標に影響するか」という接続を示す方が動きにつながりやすい。「3名が"信頼できない"を選んだ」という結果は、継続率や推薦意向への影響として翻訳したうえで提示する。 --- Desirability Testing は手法ではなく、問いに答えるための道具だ。 DVF の D 軸とは「人々が本当にこれを欲しいか」という根本的な問いを体系化したものであり、その問いに答える手段は状況によって変わる。 Reaction Cards を知っているかどうかではなく、どの問いに答えたいかを先に決めてから手法を選ぶ習慣が、Desirability Testing の実効性を決定づける。 --- ### Desirability Testing とユーザー検証完全ガイド——「使える」の先にある「好き」を測る URL: https://designthinking.studio/methods/desirability-testing-complete-guide/ > DVFフレームワークのDesirability層を測定するDesirability Testingの全手順。Microsoft Reaction Cardsの使い方、サンプルサイズの根拠、ユーザビリティテストとの使い分け、ファシリテーションの失敗パターンを体系的に解説。 「使えるか」は確認できた。しかし「また来るか」が分からない。 ユーザビリティテストを終えたあと、そういう状態に陥るチームは多い。タスク完了率は80%を超えた。エラーも3件に減った。しかしユーザーが「このプロダクトを選び続けるか」への答えは、どこにも記録されていない。 感情的な印象が購買決定と継続利用を左右するとき、行動観察だけの検証には構造的な盲点がある。 Desirability Testing は、その盲点を埋めるために設計された手法だ。 --- Desirability Testing とは Desirability Testing は、ユーザーがデザインや体験に対して抱く感情的・美的な印象を測定する定性調査手法だ。 2002年、Microsoftの研究者 Joey Benedek と Trish Miner が発表した論文「Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting」において体系化された。彼らが開発したのが Microsoft Reaction Cards（Product Reaction Cards）——118枚の形容詞カードである。 カードには「使いやすい」「先進的」「信頼できる」「退屈な」「混乱させる」「押しつけがましい」など、ポジティブ・ネガティブ両方の形容詞が含まれる。ユーザーはプロトタイプや完成品を体験した後、これらのカードから自分の印象に合うものを選び、選んだ理由を語る。「選択 + 語り」のプロセスが、言語化しにくい感情的印象を引き出す仕掛けになっている。 DVFフレームワークにおける位置づけ IDEOが提唱するDVF（Desirability / Viability / Feasibility）フレームワークにおいて、Desirability Testing は「D層」——人々が本当にそれを欲しいと思うか——を検証するための代表的手法だ。 | 層 | 問い | 主な検証手法 | |---|---|---| | Desirability | ユーザーが望むか・好きか・選ぶか | Desirability Testing, ユーザーインタビュー | | Viability | 事業として成立するか | ビジネスモデル検証, 財務シミュレーション | | Feasibility | 技術的に実現できるか | テクニカルプロトタイプ, エンジニアリングレビュー | FとVの検証を先行させながらDを検証しないまま開発を進めると、「技術的には動くが誰も使わない」という結末を招く。Desirability Testing はDVFの交点を確認するための、最も実施コストの低い手段の一つだ。 --- ユーザビリティテストとの使い分け ワークショップでよく起こるのは、「両方やらなければいけないのか」という問いだ。答えは「測りたいものが違う」に尽きる。 | 観点 | ユーザビリティテスト | Desirability Testing | |---|---|---| | 測定対象 | 操作性・タスク完了率・エラー発生 | 感情的印象・美的評価・感情的共鳴 | | 主な問い | 「使えるか」 | 「好きか・信頼できるか・また選ぶか」 | | データの性質 | 観察可能な行動データ | 自己申告の感情・言語データ | | 適切なタイミング | 中忠実度〜高忠実度プロトタイプ | 視覚的印象が伝わるプロトタイプ以降 | | セッション時間 | 45〜90分 | 30〜60分（単体実施時） | 両者は排他的ではない。1回のセッション内で組み合わせる場合、タスク実行（行動観察）を先に済ませてからカード選択（感情評価）に移行するのが原則だ。逆順にすると、感情的な印象が先に確定し、タスク遂行の行動が歪む。 --- 実施するタイミングの判定フロー Desirability Testing には「最適なタイミング」がある。早すぎると評価できるものがなく、遅すぎると設計変更のコストが上がる。 概念段階（アイデアスケッチ）→ 実施難易度: 高 視覚的印象がないため、カード選択の根拠が薄くなる。このフェーズでは代わりにムードボードを用いた感情マッピングが有効だ。 低忠実度プロトタイプ（紙・ワイヤー）→ 実施推奨度: 中 基本的なレイアウトと情報構造の感情的印象は確認できる。「雑然とした感じがする」「素っ気なすぎる」などのフィードバックが得られる。デザイン方向性の初期確認に使う。 中〜高忠実度プロトタイプ（インタラクティブ）→ 実施推奨度: 高 最も情報量が多いタイミング。ビジュアルデザインと操作感の両方への反応が取れる。このフェーズでのDesirability Testingが、最もROIが高い。 リリース直前〜後 → 実施推奨度: 中 事前検証としては遅いが、競合比較や次期バージョンの方向性確認に活用できる。 --- 手順：セッションの設計と進め方 - 事前準備（1〜2時間） カードは公式サイトからPDFを入手し、A4で印刷後にカットする。1セット最低2部用意する（ユーザーが並べて比較しやすくなる）。 参加者の選定基準を明確にする。ターゲットペルソナに合致しているかが最重要で、既存ユーザーと非ユーザーを混在させると比較分析が豊かになる。 1セッションの参加人数は1名が原則だ。複数名だと、最初に発言した人の言語がカード選択に影響する（社会的促進効果）。 - セッション冒頭：場の設定（5〜10分） 「正解はない」という前置きを必ず入れる。「あなたの感性を評価するのではなく、このデザインを評価するためのテストです」という文言を一語一語ゆっくり伝える。 緊張をほぐすために、テーマと無関係な形容詞（「あなた自身を5枚のカードで表すとしたら？」）で練習させると、カード選択の行為に慣れる。 - プロトタイプ体験（15〜30分） 特定のタスクを設定し、実際に操作してもらう。考えていること・感じていることを声に出してもらう（Think Aloud法）と、後のデブリーフが深くなる。 ファシリテーターはメモを取りながら、感情的な反応が見えた瞬間（顔をしかめる、操作を止める、「あ、ここは」と声が漏れるなど）を記録する。これがデブリーフの質問の素材になる。 - カード選択（10〜15分） 118枚を全数確認してもらい、「自分の印象に当てはまるもの」を選んでもらう。枚数制限はないが、最終的に「最も強く感じた5枚」まで絞り込んでもらう。 実際にやってみると、5枚への絞り込みの段階で最も豊かな対話が生まれる。 「"先進的"か"洗練された"かどちらに絞ろうか」と迷う瞬間に、ユーザーが自分でも気づいていなかった印象の輪郭が立ち上がる。この迷いを「どちらがより強く残りますか」と引き出すのが、ファシリテーターの腕の見せ所だ。 - デブリーフ（20〜30分） 選んだ5枚それぞれについて「なぜこのカードを選びましたか」「どの場面でそう感じましたか」を問う。 重要：カードの言葉をそのまま繰り返させないこと。「"信頼できる"を選んだ理由を教えてください」への回答が「信頼できそうだと感じたからです」では何も分からない。「"信頼できる"を選んだのはどの場面を見てですか」「何がそう感じさせましたか」という形で、具体的な体験へのアンカーを求める。 --- サンプルサイズ：15〜20名の根拠 Benedek と Miner の元論文では、15〜20名の参加者でパターンが収束することが実証されている。5名以下では個人差が結果を支配し、30名を超えると新しい発見が著しく減少する。 ただし前提条件がある。対象ユーザーが均質な1セグメントに限定されている場合だ。ペルソナが2種類以上存在する場合は、セグメントごとに15〜20名ずつ必要になる。リソースが限られる場合、最低8名でも一次的なパターンは得られるが、外れ値の扱いに注意が必要だ。 --- 分析：カードデータを設計に変換する 頻度マップの作成 全参加者のカード選択を集計し、選択回数の多い形容詞を可視化する。ポジティブ・ネガティブを色分けして並べると、現在のデザインが「何として認識されているか」の地図が完成する。 意図とのギャップ確認 設計チームが「こう感じてほしい」と意図した形容詞と、実際に選ばれた形容詞を比較する。意図と現実のズレがある箇所が、優先的に設計修正すべきポイントだ。 例：チームが「シンプル・直感的」を目指したが、ユーザーは「退屈・素っ気ない」を選んだ場合、「シンプル」と「冷たさ」の間にある設計の問題を探る。 ネガティブカードの深掘り ポジティブなカードより、ネガティブなカードが選ばれた理由のほうが設計改善に直結する情報を含む。「混乱させる」「圧倒的な」「予測できない」は、どの具体的な設計要素がそう感じさせているかを必ずデブリーフで突き止める。 --- よくある失敗と対策 失敗1：カード選択の理由を聞き忘れる 「5枚選んでもらいました、終了です」は致命的だ。カードの選択数は量的な参考値にすぎず、設計に使えるのはデブリーフで引き出した言語データだ。必ず「なぜ」「どの場面で」を聞く。 失敗2：ターゲット外のユーザーでテストする 手が届きやすいという理由で社内スタッフや家族・友人でテストすると、ターゲットペルソナの感情的反応とは全く異なる結果が出る。リクルーティングのコストを惜しんだ代償は、設計ミスとして後から帰ってくる。 失敗3：数字だけで報告する 「ポジティブカードが73%、ネガティブカードが27%」という報告は経営陣には受けがいいが、設計への示唆がない。「○○と感じたユーザーが△名おり、その全員が□□の場面でそう感じていた」という形式が、改善アクションに直結する。 失敗4：1回のテストで完結させようとする Desirability Testing はイテレーティブに実施するほど価値が高まる。設計変更の前後で同じセッションを繰り返すと、感情的印象の変化が定量的に追跡できる。「先進的」の選択率が8%から31%に上がったというデータは、デザインの効果を可視化する強力な根拠になる。 --- やってみよう：今週から始める最小実装 - Microsoft Reaction CardsのPDFを公式サイトからダウンロードし、A4で印刷・カット（30分） - 現行プロダクトの最も「よく使われる機能」を3つ選ぶ - ターゲットユーザー3名に連絡し、30分のオンラインセッションを打診する - セッションでは「機能を使ってみてからカードを選ぶ」の手順で実施する - 5枚への絞り込みを必ず行い、それぞれの理由を言語で記録する 最初は3名で十分だ。 パターンを見るには数が足りないが、「自分たちが想定していなかった感情的印象がある」という発見は、3名でも起きる。その発見が、次のステップの動力になる。 --- Desirability Testing の本質は、ユーザーの語彙を設計の語彙に変換することにある。「なんか好き」「なんとなく違う」という感覚は、設計の改善指示にならない。しかし「先進的だが冷たい」「使いやすいが退屈」という言語は、具体的な設計変更の方向を指し示す。感情を数えるのではなく、感情を言語にして設計に戻す——それがこの手法の核心だ。 プロトタイプの段階でまだ動的なインタラクションが実装できていない場合は、ウィザード・オブ・オズ法でAI応答や自動化機能を人手で再現し、Desirability Testing と組み合わせることで、感情評価の精度を大きく高められる。 --- ### Desirability Testing の感情ROI——テスト結果をビジネス指標に接続する URL: https://designthinking.studio/methods/desirability-testing-emotional-roi/ > Desirability Testingの定性データを定量化し、NPS・継続率・推薦意向と接続してビジネス価値を証明する方法。ステークホルダーへの説明から意思決定への活かし方まで、感情指標のROI化を実践的に解説する。 「Desirability Testingをやりたい」と言ったとき、上司から「それで何が分かるのか」と返された経験があるはずだ。 感情的な印象を測るテストは、ユーザビリティテストのタスク完了率や発話プロトコルより直観的でない。「先進的だと感じた人が60%」という結果を、どうビジネスの言葉に翻訳するか——この接続を怠ると、Desirability Testingは「やった」で終わる。 本稿では、テストの実施方法ではなく結果のROI化に焦点を当てる。感情指標をビジネス指標に接続し、意思決定を動かすデータにする手順を解説する。 --- なぜ感情指標はROIに接続できるか 感情と継続率の関係は、複数の研究で定量的に示されている。 Forrester Research は感情的体験の質と顧客ロイヤルティの間に有意な相関があることを継続的に示しており、感情を重視した CX 設計が継続率・推薦意向に影響することを複数のレポートで報告している。Nielsen Norman Group の研究でも、ユーザーの感情的評価（「使いたい」「好き」「信頼できる」）と実際の再訪問率には有意な相関があることが示されている。 つまり Desirability Testing の結果は「感情の測定値」であると同時に、継続率・NPS・推薦意向の予測変数でもある。この前提を持って結果を読むと、数値の意味が変わる。 --- 感情スコアの定量化フレーム Microsoft Reaction Cards を使った Desirability Testing は、本来は定性手法として設計されている。しかし結果を定量化するためのフレームを事前に設計しておくことで、比較可能なスコアに変換できる。 ポジティブ比率スコア（PRS） 選択されたカードをポジティブ（先進的・信頼できる・シンプルなど）とネガティブ（混乱する・退屈・圧倒されるなど）に分類し、ポジティブカードの比率を計算する。 PRSが70%以上であれば感情的な受容度が高いと判断できる目安がある（ただし業種・プロダクトカテゴリによって基準は変わる）。PRSを複数プロトタイプで比較することで、「どのデザイン案が感情的に有利か」を数値で示せる。 感情カテゴリ集中度（ECI） どのカテゴリに感情が集中しているかを見る指標だ。118枚のカードを「信頼性」「先進性」「親しみやすさ」「楽しさ」「シンプルさ」などのカテゴリに事前に分類しておき、どのカテゴリに選択が集中するかを計算する。 これにより「ユーザーはこのプロダクトを主に『信頼できるもの』として受け取っている」「先進性よりも親しみやすさが評価されている」という方向性の読み取りが可能になる。この方向性は、ブランドポジショニングの仮説との照合に使える。 --- NPSとの接続設計 Desirability Testing と NPS を同じセッションで実施することで、感情指標と推薦意向の相関を直接測定できる。 具体的な手順は以下のとおりだ。 セッション構成: - プロトタイプを体験（5〜10分） - Microsoft Reaction Cards から5枚を選択（5分） - 選択した理由をデブリーフ（15〜20分） - 簡易NPS設問「このプロダクトを友人・同僚に勧める可能性は？（0〜10）」（1分） - 追加の発話収集（任意） このセッション設計でNPSスコアとPRSの両方が取得できる。参加者を20〜30名確保したうえでこのデータを取ると、PRSとNPSの散布図を描くことができ、感情スコアと推薦意向の相関係数を算出できる。 相関分析の活用法 相関係数が0.5以上であれば、「感情的に好意的に受け取られるほどNPSが高い傾向がある」という主張の根拠になる。これをステークホルダー向けに提示すると「感情の測定がなぜビジネスに重要か」の説明として機能する。 --- 既存プロダクトがある場合——ベースライン比較 リデザインやUI改善のプロジェクトでは、改善前後の比較が最も分かりやすいROI指標になる。 比較設計の例: | 指標 | 改善前（旧デザイン） | 改善後（新デザイン） | 変化 | |------|-------------|-------------|------| | PRS | 54% | 71% | +17pt | | 「信頼できる」選択率 | 28% | 49% | +21pt | | 「複雑」選択率 | 33% | 11% | -22pt | | セッション内NPS | 6.2 | 7.8 | +1.6 | この表を提示したうえで、既存の継続率データと照合する。たとえば「信頼性スコアが10pt改善したプロジェクトで、過去の事例では継続率が8〜12%向上した」という自社データがあれば、それを根拠に「今回の改善による継続率への影響を5〜10%と見積もる」という試算が可能になる。 アサンプション・マッピングで「継続率が5%改善すれば収益に○○円の影響がある」という試算を先に置いておくと、Desirability Testing の結果が直接ビジネス仮説の検証材料になる。 --- ステークホルダーへの報告設計 ROI化したデータをどう見せるかは、誰が意思決定者かによって変わる。 プロダクトマネージャー向け 感情スコアの変化と、それが製品ロードマップのどの優先順位に影響するかを接続する。「感情的受容度が低い機能Aより、受容度が高い機能Bを先にリリースすべき根拠」という形で提示すると意思決定に使いやすい。テストカードと実験設計の手法と組み合わせると、仮説検証の構造が整理される。 経営・マーケティング向け NPSとの相関データを前景に出す。「感情スコアが70%以上のプロダクトはNPSが平均1.5ポイント高い」という内部データが蓄積されれば、定性的な調査が経営指標と直結する根拠になる。 デザインチーム向け カテゴリ別の集中度（ECI）が有効だ。「先進性に集中していて親しみやすさが低い」「信頼性は高いが楽しさが欠けている」という方向性の分析は、次のデザイン改善の具体的な方向を示す。ユーザビリティテストの結果と並置すると、機能的な問題と感情的な問題を分離して議論できる。 --- 落とし穴：ROI化を急ぎすぎない 感情指標のROI化には、注意すべき落とし穴がある。 相関を因果と混同しない。 PRSとNPSに相関があっても、感情スコアを上げればNPSが上がるとは断言できない。「感情的に好意的なプロダクトは推薦されやすい傾向がある」という読み方にとどめ、「感情スコアを1pt上げると推薦率が○%上がる」という直接的な因果の主張は避ける。 サンプルサイズを守る。 5〜8名のセッションで得たデータをROI試算に使うのは危険だ。パターンの抽出には15〜20名が必要であり、相関分析には20〜30名を確保したい。人数が不足した状態での数値化は、精度の低いデータを根拠にした意思決定を生む。 カード選択の文脈を記録する。 「先進的」を選んだ参加者が、それをポジティブな意味で選んだか、「気取っていて近寄りがたい」という意味で選んだかは、カード選択枚数だけでは判別できない。デブリーフのテキストを残し、数値の解釈に使う定性データを確保しておく。 --- まとめ：感情の測定を事業言語に変える Desirability Testing の結果を「感情的に好評だった」で終わらせるか、「感情スコアの変化がNPS・継続率・収益に○○の影響を与える見込み」として報告できるかは、事前設計の差だ。 - NPSと同時計測するセッション設計 - PRS・ECIによる感情の定量化 - ベースライン比較による改善効果の数値化 - ステークホルダー別の報告フォーマット設計 この4つを準備してからテストに臨むと、Desirability Testing は「感情の調査」から「事業仮説の検証手段」に変わる。 --- ### Desirability Testing 完全ガイド——ユーザー検証の盲点を埋めるテスト設計 URL: https://designthinking.studio/methods/desirability-testing-user-validation/ > Desirability Testingとは何か、Microsoft Reaction Cardsの使い方と限界、ユーザビリティテストとの使い分け、プロトタイプのどの段階で実施するかの判定フロー。感情的共鳴を可視化する手法を実践的に解説する。 「使えるか」は分かった。でも「好きか」が分からない。 ユーザビリティテストを終えて、そういう状態になることがある。タスク完了率は高い。エラーも減った。しかしユーザーが「また使いたい」と思うかどうか、「他の人に勧めたい」と感じるかどうか——その確信が持てない。 Desirability Testing は、「好き嫌い」を聞くテストではない。 ユーザーがプロダクトや体験に対して抱く感情的な印象の解像度を上げるための手法だ。「いい感じだと思う」という曖昧な感触を、具体的な言語に変換する。それがこのテストの本質的な役割である。 Desirability Testing とは何か Desirability Testing は、ユーザーがデザインに対して抱く感情的・美的な印象を測定する定性的調査手法である。 2002年、Microsoft の研究者 Joey Benedek と Trish Miner が発表した論文 "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting" において体系化された。彼らが開発したのが Microsoft Reaction Cards（Product Reaction Cards とも呼ばれる）——118枚の形容詞カードである。 カードに記載された形容詞は「使いやすい」「先進的」「信頼できる」「退屈な」「混乱させる」「押しつけがましい」など、ポジティブ・ネガティブ両方が含まれる。ユーザーはプロトタイプや完成品を体験した後、これらのカードから自分の印象に合うものを選び、選んだ理由を語る。この「選択＋語り」のプロセスが、言語化しにくい感情的印象を引き出す仕掛けになっている。 Benedek と Miner は、この手法によってユーザー間の比較と時系列変化の追跡が可能になることを実証した。「ユーザーAとBがともに"先進的"を選んだが、Aは肯定的な意味で、Bは距離感を感じて選んだ」という違いも、デブリーフで引き出せる。 --- ユーザビリティテストとの使い分け ワークショップでよく起こるのは、「Desirability Testing もユーザビリティテストもやらなければいけないのか」という問いだ。答えは「測りたいものが違う」である。 | 観点 | ユーザビリティテスト | Desirability Testing | |---|---|---| | 測定対象 | 操作性・タスク完了率・エラー発生 | 感情的印象・美的評価・感情的共鳴 | | 主な問い | 「使えるか」 | 「好きか・信頼できるか・また使いたいか」 | | データの性質 | 観察可能な行動データ | 自己申告の感情・言語データ | | 実施タイミング | 中忠実度〜高忠実度プロトタイプ | 視覚的印象が伝わるプロトタイプ以降 | | セッション時間 | 45〜90分 | 30〜60分（カード選択15分 + デブリーフ30〜45分） | | ファシリテーション難度 | 中（行動観察が中心） | 高（感情の言語化を引き出す質問技術が必要） | 両者は排他的ではない。1回のセッションでユーザビリティテストの後半に Desirability Testing を組み込む設計も有効だ。ただし順序は重要で、タスク実行（行動観察）を先に済ませてから、カード選択（感情評価）に移行する。逆順だと、感情的な印象がタスク遂行に影響する。 --- Microsoft Reaction Cards の使い方 セッションの基本構造 - プロトタイプ体験（15〜30分）——タスクを通じてプロダクトを一定時間体験してもらう - カード選択（10〜15分）——118枚のカードを全部確認し、自分の印象に当てはまるものを選ぶ。枚数制限はないが、最終的に「最も強く感じた5枚」に絞り込んでもらう - デブリーフ（20〜30分）——選んだカードそれぞれについて「なぜこれを選んだか」「どの場面でそう感じたか」を話してもらう カード選択の進め方 参加者に「正解はない」ことを繰り返し伝える。「テストしているのはプロダクトであり、あなたの感性を評価しているのではない」という前置きは、ユーザビリティテストと同様に必要だ。 実際にやってみると、5枚への絞り込みの段階で最も豊かな対話が生まれる。「"先進的"か"洗練された"かどちらに絞ろうか」と迷う瞬間に、ユーザーが自分でも気づいていなかった印象の輪郭が立ち上がる。この迷いをファシリテーターが「どちらが強く残りますか？」と引き出すのが技術の見せ所だ。 118枚の物理カードを使う環境が整わない場合、デジタル版として FigJam や Miro 上にカードを配置して実施する方法もある。実務では印刷したA5カードを使うケースが多い。ファシリテーターが事前にカードを印刷し、セッション前にテーブルに広げておくと進行がスムーズになる。 デブリーフの質問設計 デブリーフはカード選択より重要だ。選ばれた単語は入口に過ぎない。 有効な質問パターンは以下の通り。 - 「"信頼できる"を選びましたね。どの瞬間にそう感じましたか？」（特定の場面への誘導） - 「逆に、今回選ばなかったカードで気になったものはありますか？」（ネガティブ印象の引き出し） - 「"退屈な"を選んでいませんが、もし使っていたらどの部分に当てはまりましたか？」（批判的視点の引き出し） 参加者の声を直接引用して記録に残す習慣をつけること。「先進的だと感じた」という要約ではなく「画面が切り替わるときのアニメーションが、なんか未来っぽくて」という生の言葉がプロトタイプ改善のヒントになる。 --- どの段階で使うか——判定フロー Desirability Testing は万能ではない。実施タイミングの判断が、テストの価値を左右する。 ワークショップで「プロトタイプはまだ紙ですが Desirability Testing をやりたい」という要望が出たとき、正直に伝える必要がある。視覚的な印象が形成されていない段階では、カードの選択がランダムになる。 テストした感覚は得られるが、データとしての信頼性は低い。 --- Reaction Cards の限界と補完手法 Benedek と Miner 自身が論文の中で認めているように、Reaction Cards にはいくつかの構造的な限界がある。 文化・言語依存の問題。 英語圏のユーザーを前提に開発されたカードは、日本語翻訳時に意味がずれる形容詞がある。「Sophisticated」を「洗練された」と訳すか「複雑な（難しい）」と解釈するかで、ユーザーの選択理由が変わる。日本語でテストを実施する場合、事前に用語の定義を簡単に確認するか、各カードに短い説明を添える工夫が有効だ。 自己申告の信頼性。 ユーザーが「信頼できる」を選んだとき、それが本当に信頼感に基づくのか、「そう答えるべきだ」という社会的期待に引っ張られているのかを、カード選択だけでは区別できない。デブリーフで具体的な場面を問う質問を重ねることが、この問題への対処になる。 観察行動との乖離。 ユーザビリティテスト中に明らかに迷っていたにも関わらず、「使いやすい」を選ぶ参加者がいる。自己評価と行動観察を突き合わせて読む必要がある。 補完手法として、Attrakdiff（実用的品質と感情的品質を独立に測定する問診票）との組み合わせが有効だ。Desirability Testing の定性データと Attrakdiff の定量データを並列で分析することで、感情的評価の全体像が立体的になる。 --- よくある失敗パターン デブリーフなしでカード集計だけで終わらせる。 カードの選択分布をグラフ化して「"先進的"が最多でした」と報告して終わりにするケースが現場でよく起こる。これは Desirability Testing の最も一般的な失敗だ。集計は見取り図に過ぎない。「なぜその言葉を選んだか」のナラティブを収集しないと、改善の方向性を誤る。 少なすぎる参加者で決定的な結論を出す。 2〜3名の結果で「ユーザーはこのデザインを"楽しい"と感じている」と断言するのは危険だ。Desirability Testing は定性的手法であり、5〜8名が最低限の規模感である。ユーザーセグメントが複数ある場合は、各セグメントから最低3名を確保する。 ネガティブカードを軽視する。 「退屈な」「圧倒的な」「難しい」などのネガティブカードが選ばれた際、「まあ仕方がない」で流してしまうワークショップが多い。参加者からの声として、ネガティブカードを選んだ理由のほうが「どこを直すか」の具体的な手がかりになるケースが多い。ネガティブカードには必ずデブリーフで掘り下げる時間を確保する。 --- やってみよう——最小構成での実施手順 準備時間を最小化して Desirability Testing を体験するための手順を示す。 用意するもの（30分で準備可能） - Reaction Cards の日本語版印刷リスト（30〜50語に絞ったセレクション版でも機能する） - プロトタイプ（デジタルモックアップかインタラクティブプロトタイプ） - 付箋と太マジック（デブリーフでの引用記録用） - タイマー セッション当日の時間配分（60分版） - 説明と導入（5分）——「あなたの感性をテストしているのではない」を明確に伝える - プロトタイプ体験（15分）——特定のタスクを実行してもらう - カード選択（10分）——全カードを確認し、最大5枚を選ぶ - デブリーフ（25分）——選んだカードについて対話する。「なぜ」と「どの場面で」を必ず聞く - まとめと感謝（5分） 分析の最初のステップ セッション終了後、選ばれたカードと発言の引用を付箋に書き出す。5名分を並べると、同じカードを選んでも理由が異なるパターンと、理由まで一致するパターンが見えてくる。後者こそが、プロトタイプ改善の根拠となるインサイトだ。 ユーザビリティテストで「使えること」を確認したら、次は「好かれること」を確認する。その間に立つのが Desirability Testing である。手を動かして初めて、この手法の価値が分かる。 --- 参考文献 - Joey Benedek & Trish Miner, "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting", Proceedings of the Usability Professionals Association 2002 Annual Conference, 2002 - Marc Hassenzahl & Noam Tractinsky, "User Experience — A Research Agenda", Behaviour & Information Technology, 25(2), 2006 - Nielsen Norman Group, "Measuring Perceived Usability: The SUS, UMUX-Lite, and NPS Compared", nngroup.com - William Albert & Thomas Tullis, Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics, 2nd ed., Morgan Kaufmann, 2013 --- ### Desirability Testing（デザイラビリティ・テスト）｜感情的評価を数値化する検証手法 URL: https://designthinking.studio/methods/desirability-testing/ > ユーザーが製品・サービスに対して抱く感情的な印象を、Microsoft Reaction Cardsなどの標準ツールを用いて定量化する検証手法。UsabilityTestingとの違い、実施手順、DVFフレームワークとの接続を解説する。 「使いやすい」と「使いたい」は別の問いだ。 UsabilityTestingはタスク達成率やエラー頻度を測る。しかしユーザーが製品をどう「感じるか」——美しい、信頼できる、退屈だ、圧倒される——は、別の手法で問わなければ見えてこない。Desirability Testingは、その感情的評価を体系的に収集する検証手法だ。 --- Desirability Testingとは IDEOがDVFフレームワーク（Desirability, Viability, Feasibility）で定義した「人が欲しいと思うか」という軸を、具体的な検証手順として実装したものがDesirability Testingだ。 特定の製品・デザイン・プロトタイプをユーザーに提示し、あらかじめ用意された形容詞リストから「この製品を表すと思う言葉」を複数選ばせる。選択された語の分布と、その選択理由の聞き取りから、感情的評価の輪郭を描く。 最もよく用いられるツールはMicrosoft Reaction Cards（Microsoftデザイン研究）だ。2002年にJoey BenedekとTrish Minerが開発した118語のカードセットで、「革新的」「冷たい」「信頼できる」「退屈」など感情的形容詞が118枚に1語ずつ印刷されている。うち約60%がポジティブ語、40%がネガティブ語という構成は、実際の感情評価の分布に即した設計だ。 --- UsabilityTestingとの使い分け 混同されやすいが、目的と問いが根本的に異なる。 | 比較軸 | UsabilityTesting | Desirability Testing | |--------|-----------------|----------------------| | 主な問い | 「使えるか」 | 「欲しいか・好きか」 | | 測定対象 | タスク達成率・エラー数・完了時間 | 感情的印象・ブランドイメージ | | データ形式 | 行動ログ＋定量 | 語の選択分布＋定性コメント | | 実施タイミング | 中〜高忠実度プロトタイプ | コンセプト段階から実用可能 | | 参加者数の目安 | 5〜8名（質的洞察重視） | 15〜20名（語の出現率を見る） | UsabilityTestingが「動線の問題」を見つけるなら、Desirability Testingは「印象の問題」を見つける。両者を組み合わせることで、「使いやすくて、かつ使いたいと思う」製品の設計に近づく。 --- DVFフレームワークとの接続 IDEOが提唱するDVFフレームワークは、あらゆる製品アイデアを3軸で評価する。 - Desirability（デザイラビリティ）: ユーザーが本当に欲しいと思うか - Viability（バイアビリティ）: ビジネスとして成立するか - Feasibility（フィージビリティ）: 技術的に実現可能か 3つの円が重なる中心が「優れたイノベーション」だとIDEOは定義する。この文脈でDesirability Testingは、D軸の検証手段として機能する。プロトタイプが高いViabilityとFeasibilityを備えていても、Desirabilityの欠如は市場導入後の失敗に直結する。 --- 実施手順：60分版の基本構成 準備（セッション前） カードの選定: Microsoft Reaction Cards 118語を全て使うのが理想だが、文化・言語的な文脈の違いに注意が必要だ。英語カードをそのまま日本語に直訳すると、語のニュアンスが変わる場合がある。「Sophisticated」は「洗練された」だが、日本語でのニュアンスは「複雑すぎる」と受け取られることもある。導入前に語彙のレビューを行うか、文脈に合わせた日本語版カードの作成を検討する。 評価対象の設定: スクリーン上に表示するデザイン、インタラクティブなプロトタイプ、物理的なサービスの模擬体験——どの形式でも適用できる。ただし全参加者に同一の刺激を提示することが必須だ。 セッション進行 ステップ1（5分）: 参加者に製品・デザインを提示し、自由に操作・閲覧してもらう。この段階では何も質問しない。 ステップ2（10〜15分）: カードを参加者の前に広げ、「この製品を表すと思う言葉をいくつでも選んでください」と依頼する。選択数に制限を設けないのが標準的だが、5〜7語に絞る変形版もある。制限を設ける場合は全セッションで統一する。 ステップ3（15〜20分）: 選んだ語について「なぜこの言葉を選びましたか？」と一語ずつ掘り下げる。ここが定性データの核心だ。「革新的」を選んだ理由が「チェックアウトの速さ」か「デザインの斬新さ」かによって、次に設計改善すべき箇所が変わる。 分析 全セッション終了後、選択された語を集計する。各語の出現率を計算し、「意図したポジティブ語が高頻度で選ばれているか」「想定外のネガティブ語が一定数以上出現していないか」を確認する。 想定外の語の出現が目立つ場合、その語を選んだ参加者のコメントを横断的に読む。そこには設計上の問題か、あるいはコミュニケーション（製品名・説明文）の問題かを分類できるヒントが含まれている。 --- 補完手法：AttrakDiff 感情評価をさらに構造的に測定したい場合は、AttrakDiffと組み合わせる選択肢がある。Hassenzahl、Burmester、Kollerが2003年に開発した28項目の7段階評定尺度で、プラグマティック品質（操作性）とヘドニック品質（喜び・自己表現）を独立して測定する。両者の相関を確認しながら設計判断ができる点が利点だ。 --- 限界と注意点 Desirability Testingで得られるのは「印象」であり「行動の予測」ではない。「革新的」と選んだユーザーが実際に購入するとは限らない。感情的な評価が購買意図や継続使用意向にどう結びつくかは、別途行動データや定量調査で補完する必要がある。 また、カードの語彙が文化的文脈に強く依存する点は繰り返し強調しておきたい。Microsoftの原典は英語圏のユーザーを前提として構築されており、日本語環境への適用には語彙レベルの検証が不可欠だ。 --- 次のステップ Desirability Testingの結果は、設計改善の方向を示す出発点だ。ネガティブ語の分析から特定した問題に対してはペーパープロトタイプの修正サイクルを回す。ポジティブ語の分析からは、ユーザーが評価する強みを次のイテレーションで意図的に強化する。 感情的評価と機能的評価を両輪で回すとき、デザイン思考の検証プロセスは深みを持つ。 --- ### Desirability TestingとA/Bテスト統合——感情指標を定量化する実装手順 URL: https://designthinking.studio/methods/desirability-testing-ab-test-integration/ > Microsoft Reaction Cardsで得た感情データを、A/Bテスト・行動データ・統計指標と統合する実装手順を解説。定性と定量のギャップを埋め、「好まれる」を意思決定に使えるレベルまで持ち上げる方法。 Desirability Testingで「先進的」「信頼できる」というカードが選ばれた。だが、それで意思決定はできない。経営会議で「ユーザーが先進的だと感じています」と報告しても、「で、コンバージョンはどう変わるのか?」と返される。感情指標と行動指標の橋渡しが、Desirability Testingの最大の実装課題である。 本稿は、Microsoft Reaction Cardsで得た定性的感情データを、A/Bテストや行動データと統合し、意思決定可能な指標まで持ち上げる実装手順を解説する。Desirability Testingの基礎はDesirability Testing 完全ガイドを参照されたい。 なぜ単独のDesirability Testingでは不十分なのか Reaction Cardsの構造的限界 Microsoft Reaction Cards(118枚の形容詞カード)は、Joey BenedekとTrish Minerが2002年の論文 "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting" で発表した手法である。ユーザーが体験後に印象に合うカードを選び、選んだ理由を語る。「選択+語り」で言語化しにくい感情を引き出す仕掛けだ。 しかしこの手法には3つの構造的限界がある。 第一に、サンプルサイズが小さい。 通常5〜8名で実施されるため、統計的有意性は主張できない。「8名中6名が"先進的"を選んだ」という記述は、母集団の傾向を保証しない。 第二に、行動との因果関係が示せない。 「先進的だと感じた」と「実際にプロダクトを使い続ける」の間には相関しか示せず、感情指標が行動を予測するか不明である。 第三に、競合や代替案との比較が困難である。 単独のプロトタイプに対する印象は得られるが、「Aの方がBより先進的だと感じられたから採用」という判断には、A/B両方のデータが必要だ。 統合の必要性 これらの限界を補うには、Desirability Testingの感情データを、A/Bテストの行動データと統合する必要がある。具体的には以下の3つの統合が機能する。 - A/B両プロトタイプにDesirability Testingを実施し、感情指標の差分を観察する - 同じプロトタイプで行動指標(クリック率・滞在時間・コンバージョン率)を計測し、感情と行動の対応を見る - 統計的に有意なサンプルサイズで定量化(ただしReaction Cardsそのものの統計化ではなく、感情カテゴリ単位での集計) 実装手順——5ステップでの統合プロセス Step 1: 感情コードブックの作成(事前準備) A/Bテスト統合の前に、118枚のカードを少数の感情カテゴリにグルーピングする。これが「感情コードブック」である。 代表的なカテゴリ分類例: - ポジティブ・機能性(useful, accessible, efficient, reliable など) - ポジティブ・感情価値(desirable, fun, exciting, inspiring など) - ポジティブ・信頼性(trustworthy, professional, secure, sophisticated など) - ニュートラル(complex, controllable, customizable など) - ネガティブ・操作性(confusing, frustrating, hard-to-use など) - ネガティブ・感情価値(boring, dated, unappealing など) - ネガティブ・信頼性(unprofessional, intimidating, untrustworthy など) このカテゴリ分けをA/Bテスト前に確定させておく。事後に分類すると都合のいい解釈ができてしまうため、事前固定が原則だ。 Step 2: A/B両プロトタイプの並行Desirability Testing A案とB案のプロトタイプを用意し、同じ参加者群(各8〜12名、合計16〜24名)でカウンターバランス(順序効果を打ち消すために、半数はA→B、半数はB→Aの順で体験)を取って実施する。 各プロトタイプ体験後に、参加者は118枚のカードから5〜8枚を選び、選んだ理由を語る。これを記録する。 重要なのは、事前に決めた感情コードブックに基づき、参加者の選択を集計することだ。「A案では"先進的"が6名、"信頼できる"が5名」といった記述ではなく、「A案ではポジティブ・信頼性カテゴリのカード選択数が平均4.2枚、B案では2.8枚」という形で集計する。 Step 3: 行動指標の並行計測 同じA/B両プロトタイプを、別の参加者群(各最低200〜500セッション、統計的検出力を確保できるサイズ)でA/Bテストとして配信する。OptimizelyやVWO、GA4の実験機能、あるいは独自実装のいずれでも構わない。 計測する行動指標の代表例: - タスク完了率(主要なゴール達成の割合) - 離脱率(特定ステップでの離脱割合) - 滞在時間(エンゲージメントの代理指標) - 再訪率(継続意向の代理指標) - コンバージョン率(購入・登録など最終ゴール) Step 4: 感情×行動マトリクスでの統合分析 Desirability Testingの感情指標と、A/Bテストの行動指標をマトリクスで突き合わせる。 | 指標カテゴリ | A案 | B案 | 差分 | |------------|-----|-----|------| | ポジティブ・信頼性(感情) | 4.2枚/人 | 2.8枚/人 | +1.4(A優位) | | ネガティブ・操作性(感情) | 0.8枚/人 | 1.5枚/人 | +0.7(A優位、ネガが少) | | タスク完了率(行動) | 87% | 79% | +8pt(A優位) | | コンバージョン率(行動) | 4.2% | 3.1% | +1.1pt(A優位) | このマトリクスで重要なのは、感情指標と行動指標が一致するかをチェックすることだ。一致しない場合(例:感情はB案が優位だが行動はA案が優位)、それは重要な発見である。「短期的には使われるが感情的には好まれていない=長期的離脱の予兆」という解釈が可能になる。 Step 5: 統計的有意性の検証と意思決定 行動指標については通常のA/Bテスト統計手法(カイ二乗検定、t検定など)で有意性を確認する。感情指標については、サンプルサイズが小さい場合はノンパラメトリック検定(Wilcoxon符号順位検定など)を用いる。 意思決定の判断基準として、以下の優先順位が現実的である。 - 行動指標と感情指標が同方向に有意差 → 高い確信度で採用判断 - 行動指標のみ有意差、感情指標は同程度 → 採用判断、ただし継続観察 - 感情指標のみ有意差、行動指標は同程度 → 長期的観点で採用、短期KPI影響を要監視 - 行動と感情が逆方向 → 追加調査必須(根本原因が異なる可能性) 実装上の落とし穴と対処法 落とし穴1: サンプルバイアス Desirability Testingの参加者と、A/Bテストの参加者が異なる属性だと統合分析が機能しない。両方の調査で属性条件(年齢層・職種・利用頻度)を揃えること。 落とし穴2: 順序効果 A/B両プロトタイプを連続して体験させると、後に体験した方が記憶が新鮮で評価が偏る。カウンターバランスを必ず実施する。 落とし穴3: 感情コードブックの恣意性 事後にカテゴリ分けを変えると、結果を都合よく解釈できてしまう。事前固定+第三者によるダブルコーディング(2名が独立に分類し、一致率Cohen's Kappa 0.7以上を確認)が望ましい。 落とし穴4: 「感情」を最終KPIにしない Desirability Testingの目的は意思決定の質を上げることであり、感情指標そのものを最終KPIにすべきではない。最終KPIは行動指標(継続率・コンバージョン率)とし、感情指標はその先行指標として位置付ける。 統合のもう一段先——感情の時系列追跡 A/Bテスト統合に慣れたら、次の段階は感情指標の時系列追跡である。同一プロダクトに対して、リリース直後・3ヶ月後・1年後にDesirability Testingを繰り返すと、初期の「新規性」が「日常性」に変化する過程が観察できる。 BenedekとMinerの原論文も、Reaction Cardsの強みとして「時系列変化の追跡可能性」を挙げていた。A/Bテスト統合と組み合わせると、「リリース時点でA案が優位だったが、3ヶ月後にB案が逆転した」といった動的な変化を捉えられる。 まとめ——感情と行動の橋渡し Desirability TestingとA/Bテスト統合は、定性と定量を分断させずに一つの意思決定プロセスに統合する手法だ。感情コードブック(事前固定)、並行実施(カウンターバランス)、感情×行動マトリクス、統計的検証——この5ステップを踏むと、「ユーザーが好む」という曖昧な印象を、経営会議で耐えうる意思決定材料まで持ち上げられる。 「好かれているか」は重要だ。だが、それを行動データと結びつけて初めて、プロダクト判断に使える指標になる。Reaction Cards単独では届かない場所に、A/Bテスト統合は届く。 関連メソッドとしてユーザビリティテスト、A/Bテスト基礎、ジャーニーマッピングを併せて参照されたい。 --- 参考文献 - Joey Benedek, Trish Miner, "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting," Usability Professionals' Association Conference, 2002 - Microsoft Corporation, Product Reaction Cards (Desirability Toolkit), 2002 (118枚の形容詞リスト) - Tom Tullis, Bill Albert, Measuring the User Experience, 2nd ed., Morgan Kaufmann, 2013(感情指標の定量化に関する章) - Ron Kohavi, Diane Tang, Ya Xu, Trustworthy Online Controlled Experiments, Cambridge University Press, 2020(A/Bテスト設計と統計検定) --- ### How Might We（HMW） URL: https://designthinking.studio/methods/how-might-we/ > 問題をポジティブな問いに変換し、チームの創造性を引き出すフレーミング手法。 How Might We（HMW）は、問題をポジティブで創造的な問いに変換するシンプルかつ強力な手法です。 概要 HMWは「私たちはどうすれば〜できるだろうか？」（How Might We...?）という形式で問いを立てます。Procter & Gamble（P&G）で生まれ、IDEO が広く普及させました。 この3つの単語にはそれぞれ意味があります。 - How（どうすれば） — 解決策が存在するという前提を持つ - Might（かもしれない） — 正解は一つではないという可能性を開く - We（私たちは） — チームの協働を促す 良いHMWの条件 HMWの質は、その「粒度」で決まります。 - 広すぎる例：「どうすれば人々を幸せにできるか？」→ 漠然としすぎて発想が拡散する - 狭すぎる例：「どうすればボタンを青にできるか？」→ すでに解決策を含んでいる - 適切な例：「どうすれば通勤時間をもっと有意義に感じられるようにできるか？」→ 多様なアイデアが生まれる余地がある 実施の手順 - 共感フェーズで得たインサイトを確認する - インサイトを「HMW...?」の形に変換する - 一人3-5個のHMWを付箋に書き出す - チームで共有し、類似のものをグルーピングする - 投票で最も有望なHMWを選ぶ - 選ばれたHMWをIdeateフェーズの出発点にする ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、HMWの問いが「解決策を含んでいる」パターンです。「どうすればアプリのナビゲーションをシンプルにできるか」は、すでに「ナビゲーションをシンプルにする」という解決の方向が入っています。良いHMWは、解決策の方向を決めず、複数の解法を許容します。 実際にやってみると、同じインサイトから「狭すぎるHMW」「広すぎるHMW」「適切なHMW」を3種類書いてもらう練習が効果的です。「ユーザーが申し込みの途中で離脱する」というインサイトから、「どうすればフォームの項目を減らせるか」（狭すぎ）、「どうすれば申し込みをもっと楽しくできるか」（広すぎ）、「どうすれば申し込み中の不安を取り除けるか」（適切）と並べると、適切な粒度の感覚が体感的に身につきます。 ポイント - 1つのインサイトから複数のHMWを生み出す - ネガティブな問題をポジティブな機会に変換する - 解決策ではなく「機会の方向性」を示す - HMWはCrazy 8sやアイデア創出フェーズの出発点になる --- 参考文献 - IDEO, "How Might We Questions", ideo.com/blog - Min Basadur, "Simplex: A Flight to Creativity", Creative Education Foundation, 1994（HMW手法の原典的考察） --- ### Jobs To Be Done（JTBD）：顧客が「雇う」製品の真の目的を見抜くフレームワーク URL: https://designthinking.studio/methods/jobs-to-be-done-dt/ > クリステンセンのジョブ理論をデザイン思考のDefineフェーズで活用する方法。ジョブステートメントの書き方、ペルソナとの併用、「ミルクシェイク問題」から学ぶ顧客理解の深め方。 Jobs To Be Done（JTBD、ジョブ理論）は、「顧客はなぜ特定の製品・サービスを選ぶのか」を「その製品に依頼している仕事（Job）」として理解するフレームワークです。デザイン思考のDefineフェーズにおいて、ペルソナだけでは捉えられない「顧客の真の動機」を解明するために用います。 「人」を見るのではなく「仕事」を見る JTBDの核心的な転換は、「どんな人が買うか（Who）」ではなく、「どんな仕事を依頼するために買うか（Why）」に着目することです。 従来のマーケティング・リサーチは「ペルソナ」を作ります。「35歳、男性、都市部在住、年収600万円、健康意識高め……」という属性の記述によって顧客を定義します。しかしこのペルソナは、なぜ特定の時点に特定の製品を選ぶかの説明には不十分です。 イノベーション研究者のクレイトン・クリステンセンは「ミルクシェイク」のケースでこの問題を示しました。 --- ミルクシェイク問題：属性分析の限界 ファストフードチェーンがミルクシェイクの売上を上げようとして、「どんな客がミルクシェイクを買うか」を調べました。購買データを分析し、年齢・性別・時間帯・注文との組み合わせなどの属性情報を集めました。しかし属性データに基づいて改良を行っても、売上は変わりませんでした。 クリステンセンのチームは別のアプローチを取りました。実際にミルクシェイクを買った人に「なぜ今ミルクシェイクを買ったのか」を聞いたのです。 明らかになった事実は属性データからは見えないものでした。朝にミルクシェイクを買う客の多くは「車で通勤している」「片手でハンドルを握りながら何かを口に入れたい」「朝食を食べてきたが、昼前に空腹になる。ミルクシェイクはゆっくり飲めるから昼まで持つ」という理由で購入していました。 つまり、彼らがミルクシェイクに依頼していた「仕事（Job）」は「朝の通勤中、手を汚さずに、時間をかけながら、昼まで空腹を満たす」というものでした。この仕事のライバルは、他チェーンのミルクシェイクではなく、バナナ・ベーグル・コーヒー・ドーナツ——すなわち「同じ仕事を依頼できる代替品」だったのです。 属性データはミルクシェイクを「誰が買うか」は教えてくれますが、「何のために買うか」は教えてくれません。JTBDはこの「何のために」を解明するフレームワークです。 --- ジョブの三分類 クリステンセンのフレームワークでは、ジョブを三つのレベルで分類します。 機能的ジョブ（Functional Job） 製品・サービスが担う具体的な機能的役割です。「書類を整理する」「移動する」「食事をとる」といった実用的な目的。最も可視化しやすいジョブですが、最も競争が激しく、差別化が困難な領域でもあります。 感情的ジョブ（Emotional Job） 使用中・使用後に感じたい感情に関わる目的です。「自分が有能だと感じたい」「不安を減らしたい」「家族の安全を守っていると感じたい」——これらは購買決定に大きく影響しますが、顧客自身が言語化しにくいジョブです。 エンパシーマップの「Feel（感じていること）」レーンが、感情的ジョブを発見するための観察フレームとして機能します。 社会的ジョブ（Social Job） 他者にどう見られたいかという社会的文脈に関わる目的です。「同僚にデキると思われたい」「環境意識の高い人間として認識されたい」「センスの良い人と思われたい」——消費財やファッション、高級品の購買動機に特に強く作用します。 --- ジョブステートメントの書き方 ジョブを特定したら、ジョブステートメントとして言語化します。フォーマットは次の通りです。 例： このフォーマットの三要素は、それぞれ具体的な設計の示唆を持ちます。 When（コンテキスト）：どんな状況でそのジョブが発生するか。この情報は、製品がどの場面で使われることを前提に設計すべきかを決定します。 I want to（動機）：達成しようとしていること。これが「解くべき問題」の正確な記述です。 So I can（アウトカム）：その達成によって得られる状態。感情的・社会的ジョブはしばしばここに現れます。 --- JTBDインタビューの進め方 JTBDは「ユーザーに直接聞く」観察から成立します。インタビューでは、属性情報ではなく「最後に○○を選んだとき」の具体的なエピソードを掘り下げます。 起点の質問 「最後に[対象製品・サービス]を使い始めた（または切り替えた）ときのことを教えてください」 属性を聞くのではなく、具体的な「出来事」を起点に置くことが重要です。「なぜ買いましたか？」という直接的な質問よりも、「その日はどんな状況でしたか？」「それ以前はどうしていましたか？」という状況の掘り下げが、より正確なジョブを見つけます。 聞くべき内容 - 切り替えのトリガー（何がきっかけで変えようと思ったか） - 検討した代替案（何と比較したか） - 決め手（最終的に選んだ理由） - 使用後の体験（想定通りだったか、期待と違ったことは） --- ペルソナとJTBDの併用 ペルソナとJTBDは対立するフレームワークではなく、相補的に使うものです。 ペルソナは「誰に伝えるか」「誰のために設計するか」の指針として、マーケティングコミュニケーションや製品設計の「文脈の共有」に有効です。 JTBDは「なぜその人はこの製品を選ぶか」の因果メカニズムを解明します。ペルソナに「ジョブの記述」を組み合わせることで、「この属性の人が、この状況で、このジョブを達成するためにこの製品を選ぶ」という、より行動予測精度の高いユーザー理解が得られます。 Defineフェーズの成果物として、「ペルソナのシート」にJTBDの三つのジョブタイプを追記するという形式が実務的によく使われます。 --- よくある誤り 誤り1：製品を前提にジョブを定義する。 「私たちのスマートウォッチを使う人のジョブは？」という問いの立て方は誤りです。製品より先に「人の状況」を起点に置くことが原則です。「運動を習慣にしようとしている人のジョブは？」から出発します。 誤り2：機能的ジョブだけ列挙する。 感情的・社会的ジョブを見落とすと、競合差別化の核心を見逃します。「速く移動する」というジョブだけを見ていると、テスラがなぜ選ばれるかが説明できません。 誤り3：ジョブを「ソリューション」で記述する。 「スマートフォンを使いたい」はジョブではなく、既存ソリューションへの参照です。そのスマートフォンを使って「何を達成したいか」まで掘り下げることが必要です。 --- 参考文献 - Clayton M. Christensen, Taddy Hall, Karen Dillon & David S. Duncan, Competing Against Luck: The Story of Innovation and Customer Choice, Harper Business, 2016 - Bob Moesta & Chris Spiek, Demand-Side Sales 101, Lioncrest Publishing, 2020 - Anthony W. Ulwick, Jobs to Be Done: Theory to Practice, IDEA BITE PRESS, 2016 - Tony Ulwick, "Turn Customer Input into Innovation", Harvard Business Review, January 2002 --- ### Lightning Decision Jam（LDJ）——議論ゼロ・60分で意思決定する構造化ファシリテーション URL: https://designthinking.studio/methods/lightning-decision-jam/ > AJ&Smart創設者Jonathan Courtneyが開発したLightning Decision Jamの完全解説。無限ループに陥りがちなチームの議論を、沈黙・個人思考・ドット投票の組み合わせで60〜90分に圧縮する実施手順とファシリテーション上の注意点を詳述する。 チームが1時間以上の会議を経ても何も決まらなかった経験は、組織で働く人なら誰でも持っている。意見が出るほど議論が広がり、収束しない。声の大きい人の意見が通り、静かな人の洞察が失われる。全員が納得しているふりをして、本心は別のところにある。 Lightning Decision Jam（LDJ）は、この構造的な問題を「議論しない」という手段で解く。 ベルリンを拠点とするデジタルプロダクト設計会社AJ&Smartの創設者Jonathan Courtneyが開発し、Medium（AJ&Smart publication）に発表したこのファシリテーション手法は、問題の洗い出しから解決策の優先順位付けまでを構造化された沈黙と投票によって進める。会話は最小限に抑えられ、全員が書き・考え・投票することで、チームの集合知を短時間で意思決定に変換する。 --- なぜ「議論しない」のか 会議での議論には、認知バイアスの地雷が埋まっている。 アンカリング効果：最初に出た意見が基準になり、後続の意見がそれを中心に集まる。社会的影響バイアス：上位職者や声の大きい人の意見が支持を集め、異議を唱えにくい空気が生まれる。グループシンク：議論を続けることで全員が同じ方向に引っ張られ、重要な懸念が消える。 LDJはこれらのバイアスを、「個人が沈黙の中で考え・書く」フェーズを挟むことで物理的に遮断する。付箋に書くという行為が、各人の思考を他者の影響から独立させる。投票は口頭でなくステッカーで行われるため、他者の投票を見てから変える余地がない。 この設計は、デザインスプリントが週5日かけて実現しようとしているものを60〜90分に圧縮した手法として位置づけることができる。 --- 実施手順 ステップ0：場の設定（5分） LDJは「問い（セッションのスコープ）」を明確にするところから始まる。 例：「今四半期のオンボーディング体験における最大の問題点を特定し、次のスプリントで取り組む1件を決める」 ファシリテーターは冒頭でこのスコープを共有し、「今日は議論ではなく、書いて投票することで決める」というルールを全員に伝える。このルール説明が薄いと、後のフェーズで話し合いが始まってしまう。 --- ステップ1：問題の書き出し（4〜7分） 全員が沈黙の中で、問題・課題・ボトルネックを付箋1枚に1件ずつ書く。 - 付箋は1色（例：黄色）を使う - 箇条書きではなく、一文で書く（「〜が〜なので〜できない」という形式が書きやすい） - 制限時間内に可能な限り多く出す。質よりも数を優先する段階 - 他の参加者の付箋を見ない（横を向かせるか、全員が自分の前に向けて書く） 沈黙が不自然に感じる参加者も多いが、「沈黙が思考を守る」とファシリテーターが伝えることで許容されやすくなる。 --- ステップ2：問題の共有（10〜15分） 全員が、ホワイトボードに付箋を貼りながら自分の問題を「ひとこと」で説明する。 ここでの鉄則は「発表に対してコメントしない」ことだ。質問も反論も保留する。全員の付箋が貼り終わるまで議論は禁止。似た問題はクラスタリングしてよいが、その判断も発表者に委ねる。 「発表は1分以内」とルールを設けておくと時間内に収まる。 --- ステップ3：問題へのドット投票（7分） 全員がドットステッカー（1人あたり5〜7枚）を持ち、最も重要だと思う問題に投票する。 - 1つの付箋に複数票を入れてよい - 投票中は話さない - 自分の付箋にも投票できる 全員が同時に投票することで、他者の選択に引きずられない。タイマーを使って時間を管理する。 --- ステップ4：問いの再定義（5分） 最も票を集めた問題（1〜3件）を「How Might We（HMW）」形式で書き直す。 例：「ユーザーが3日以内にアプリを削除する」→「どうすれば、ユーザーが最初の3日間に価値を発見できるだろうか？」 この変換は、問題を「批判の対象」から「解決すべき問い」に転換する。HOW MIGHT WEの手法についての詳細は別記事に譲るが、LDJの中では問いを定式化するだけの短い作業として扱う。 --- ステップ5：解決策のスケッチ（7〜10分） 全員が沈黙の中で、HMW問いに対する解決策を付箋1枚に1件ずつ書く（別色の付箋を使う）。 - 文章か簡単なスケッチで書く - 実現可能性は気にせず、アイデアを出し切る - 「ばかげた案」を出すことを奨励する このフェーズはクレイジーエイトの短縮版に近い。量を出すことがこのステップの目的だ。 --- ステップ6：解決策の共有と投票（10〜15分） ステップ2と同様に、全員が解決策を1件ずつ発表して貼る。発表後、全員がドットステッカーで投票する（1人あたり5〜7枚）。 投票の軸は「実行したい解決策」だ。「実現可能か」「費用は？」という話は次のステップに持ち込む。 --- ステップ7：インパクト/エフォートマトリクスで優先順位付け（15分） ホワイトボードに縦軸（インパクト：高〜低）、横軸（実施コスト・工数：低〜高）の2×2マトリクスを描く。 票を集めた解決策をマトリクス上に配置する。この配置はファシリテーターが主導するが、「どのゾーンに置くか」はチームで短い議論をして合意する。LDJの中で「議論が許される」のはこのステップだけだ。 高インパクト × 低コストのゾーンにある解決策が、次のアクションの最優先候補になる。 --- LDJとデザインスプリントの違い デザインスプリントは月曜〜金曜の5日間を要するが、LDJは1〜2時間で終わる。 LDJが目指すのは「問題と解決策の大まかな方向性の合意」だ。デザインスプリントが求めるような詳細なプロトタイプや本格的なユーザーテストは含まれない。 使い分けの目安: - LDJ向き：定例会議の終着点として使う、プロジェクト初期に方向性を決める、チームの優先課題を洗い出す - スプリント向き：具体的なプロダクト仮説を検証する、複数の解決策を比較する、ユーザーテストまでやりたい LDJはデザインスプリントの「月曜〜火曜の意思決定フェーズ」を抽出し、日常業務に使える単体ツールとして再設計したものと理解するといい。 --- ファシリテーション上のよくある失敗 沈黙を不安に思って話し始める。 参加者が付箋を書いている間に「何か書けましたか？」と声をかけるファシリテーターがいる。沈黙は思考の時間だ。邪魔しない。 投票結果をすぐに「多数決の結論」として扱う。 票が最も多かったものが必ずしも正しい方向とは限らない。インパクト/エフォートマトリクスの配置で精緻化するまで、「この問題が最優先」とは言わない。 LDJをすべての問題に使おうとする。 LDJが機能するのは「チームとしての優先順位合意が目的」の場面だ。深いユーザーリサーチが必要な問いや、組織権限が絡む決断には適さない。 --- LDJを始める前に確認すること - スコープが明確か（何を決めるセッションか全員が理解しているか） - ステッカーとタイマーの準備はできているか - 参加者に「今日は議論しない」ことを事前に伝えているか この3点が揃えば、初めてのLDJでも成立する。難しいのは手順ではなく「沈黙と投票を信頼すること」だ。最初は居心地が悪くても、マトリクスに解決策が並んだ瞬間に、多くのチームが「普通の会議より良い結論が出た」という感想を持つ。 --- 参考 - Courtney, J. (n.d.). Lightning Decision Jam: A Facilitation Technique That Eliminates Endless Discussions. AJ&Smart on Medium. — LDJ の原典記事。手順と設計思想を創案者自身が解説している - Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Scribner. — LDJが参照するデザインスプリントの原典 --- ### SCAMPER URL: https://designthinking.studio/methods/scamper-design-thinking/ > 既存の製品・サービス・プロセスに7つの問いを当てることで、新しいアイデアを強制的に引き出す創造的思考フレームワーク。創造フェーズの発散ツールとして広く活用される。 SCAMPERは、既存の製品・サービス・プロセスに7つの問いを体系的に当てることで、新しいアイデアを強制的に引き出す創造的思考フレームワークです。ブレインストーミングが行き詰まったとき、または「ゼロから考える」より「既存を変形する」アプローチが有効なときに威力を発揮します。 概要 「アイデアを出してください」と言われて、すぐにアイデアが出るチームは多くありません。ワークショップでよく起こるのは、最初の数分間は活発だったブレインストーミングが、5分後には沈黙になるパターンです。SCAMPERは「考える方向」を7つのレンズで強制的に切り替えることで、沈黙を破るための構造的ツールです。 SCAMPERは1953年にアレックス・オズボーン（ブレインストーミングの考案者）が提案した概念を元に、ボブ・エーベルが1971年に7つの問いとして体系化しました。各頭文字がフレームワーク名を形成しています。 7つの問い | 頭文字 | 英語 | 意味 | |---|---|---| | S | Substitute | 代替する | | C | Combine | 組み合わせる | | A | Adapt | 適応させる | | M | Modify / Magnify | 修正する・拡大する | | P | Put to other uses | 他の使い方をする | | E | Eliminate | 除去する | | R | Reverse / Rearrange | 逆にする・並び替える | 各レンズの詳細 S：Substitute（代替） 「何かを別のもので置き換えたらどうなるか？」 素材、プロセス、人物、場所を別のものに変える問いです。 例として、従来の紙の地図をスマートフォンのナビに置き換えた変化、カスタマーサポートを電話からチャットボットに置き換えた変化が挙げられます。問いの具体例：「このサービスのコアを担っているのは何か？それを他のもので代替できるか？」 C：Combine（組み合わせ） 「異なる要素や機能を組み合わせたらどうなるか？」 異業種のサービス、矛盾するように見える機能の統合が新しい価値を生みます。 スマートフォンは電話・カメラ・地図・決済を1つに統合した典型例です。フィットネスとゲームを組み合わせたゲーミフィケーション型アプリも同様のパターンです。 A：Adapt（適応） 「他の分野のアイデアや手法を、今の問題に応用したらどうなるか？」 既存の解決策を新しいコンテキストに持ち込むことで、開発コストを下げながら新しい価値を生み出せます。 航空会社のマイレージプログラムをコーヒーショップのロイヤルティプログラムに適応させた事例は、このレンズの代表例です。デザイン思考そのものも、デザイナーの思考法をビジネスの文脈に適応させた例と見ることができます。 M：Modify / Magnify（修正・拡大） 「形、サイズ、頻度、強度を変えたらどうなるか？」 より大きく、より速く、より頻繁に、逆により小さく、よりシンプルにするといった変形の問いです。 「より小さくする」アプローチから生まれたのが、スティーブ・ジョブズが推し進めたポータブル音楽プレーヤーのコンセプトです。「より大きな画面」という修正がタブレット市場を生み出しました。 P：Put to other uses（他の用途） 「現在の用途以外に、どんな使い方ができるか？」 既存の資産・スペース・スキルを別の文脈に転用する発想です。 倉庫をスタジオやコワーキングスペースに転用したリノベーション事例、企業の物流ネットワークをラストマイル配送サービスとして外部に開放したケースが典型です。 E：Eliminate（除去） 「何かを取り除いたらどうなるか？シンプルにすることで、何が生まれるか？」 過剰な機能・工程・障壁を取り除くことで、ユーザー体験が劇的に向上することがあります。 Airbnbの予約フローでは、入力フィールドの数を減らすことで予約完了率が向上した事例があります。Airbnbのデザイン思考事例では、シンプルな「写真撮影」という施策が事業を変えた経緯が描かれています。 R：Reverse / Rearrange（逆転・並び替え） 「順序を逆にしたら？主役と脇役を入れ替えたら？」 当たり前だと思っていた順序や役割を崩すことで、まったく異なる体験が生まれます。 試乗してから購入契約ができる自動車販売モデル、先に結果を体験させてから課金するフリーミアムサービスは、このレンズの典型例です。 ステップ Step 1：対象を定義する SCAMPERを適用する対象（製品・サービス・プロセス）を1つ選び、その主要な要素・機能・特徴を書き出します。対象が具体的であるほど、問いに対する答えも具体的になります。 Step 2：7つのレンズを順に当てる チームで各レンズの問いを読み上げ、対象に当てはめてアイデアを出します。1つのレンズに10〜15分を使い、出てきたアイデアを付箋に書いて貼り出します。全員が書き、話しながら共有するという同時並行スタイルが勢いを保つコツです。 Step 3：有望なアイデアをマークする 7つのレンズを使い切ったら、貼り出されたアイデアを俯瞰し、「これは面白い」「もっと深掘りしたい」と感じるものをマークします。ドット投票と組み合わせることで、収束が効率的になります。 Step 4：深掘りと具体化 マークしたアイデアについて「どんなユーザーにとって価値があるか」「実現するために何が必要か」を議論します。SCAMPERはアイデアを生む場ではなく、アイデアの種を見つける場です。種から育てるのは次のステップです。 ファシリテーションのコツ 対象の解像度を上げてから始める 「スマートフォンアプリ」という曖昧な対象より、「ユーザーが毎朝チェックする通知機能」という具体的な機能に対してSCAMPERを当てた方が、アイデアの質が上がります。対象を1つのユーザーアクションまで絞ってから始めると効果的です。 「変な答え」を歓迎する文化を作る SCAMPERは「正しいアイデア」を探すのではなく、思考のパターンを壊すためのツールです。「それは実現不可能だ」という評価は禁止し、どんな答えも一旦記録するという発散フェーズの原則を徹底しましょう。 7つ全部を使う必要はない 60分のセッションで7つ全てのレンズを消化しようとすると、1つひとつが浅くなります。チームの状況や問題の性質に応じて、3〜4つのレンズを選んで深く使う方が実践的です。 よくある失敗と対策 既存の解決策を繰り返す SCAMPERの問いに答える際、すでに知っているベストプラクティスを並べるだけになるケースがあります。「そのアイデアは今すでに存在しているか？」と確認しながら、存在しないものを優先的に掘り下げることで発散の質が上がります。 評価と発想を混ぜる アイデアが出るたびに「でも、それはコストが高い」「技術的に難しい」という評価が入ると、発散が止まります。発散フェーズでは評価を完全に分離し、「すべてのアイデアを記録する」ことに集中することが重要です。 ポイント - 対象を具体的に絞ってから始める — 解像度が高いほど答えも具体的になる - 7つ全部を使わなくていい — 深さを優先する - 変な答えを歓迎する — 発散フェーズでは評価を禁止 - ドット投票と組み合わせる — 発散から収束への橋渡しに - アイデアの「種」として扱う — 具体化は次のステップで SCAMPERで出たアイデアはドット投票で絞り込み、上位のコンセプトをストーリーボードやプロトタイプフェーズへと展開します。 --- 参考文献 - Bob Eberle, Scamper: Games for Imagination Development, Prufrock Press, 1996 - Alex Osborn, Applied Imagination: Principles and Procedures of Creative Problem-Solving, Scribner, 1953 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### Wizard of Oz テスト法の実践完全ガイド — プロトタイプ不要な低コスト検証 URL: https://designthinking.studio/methods/wizard-of-oz-testing-complete-guide/ > Wizard of Ozテストの設計・実施・分析を網羅した実践ガイド。いつこの手法を選ぶべきか、セッション設計のコツ、よくある失敗と対策まで、ファシリテーター視点で解説する。 「実装してから検証しよう」という判断が、最も高い学習コストを生む。Wizard of Ozテストは実装ゼロのまま、本番に近い文脈でユーザー行動を観察できる手法だ。 名前の由来は映画『オズの魔法使い』。全能の魔法使いに見えた「オズ」が、カーテンの裏にいた普通の人間だったように——被験者には自動で動くシステムと見せておいて、裏側では人間（ウィザード）が手動で応答を返す。被験者は自然に操作し、チームは「実装なしにリアルな行動データ」を手に入れる。 本記事はテストフェーズでのWizard of Oz活用に焦点を当てる。「いつ使うか」の判断基準から、セッション設計・実施・分析・よくある失敗と対策まで、ファシリテーター視点で解説する。 --- いつWizard of Ozテストを選ぶか 手法の選択を誤ると、得られるデータが問いとずれる。Wizard of Ozが「正解」となる条件は3つある。 条件1：機能が「動的」でペーパープロトでは再現できない ユーザーの入力に応じてリアルタイムに変化する体験は、静的なモックアップでは検証できない。チャットボット・AI推薦・音声アシスタント・パーソナライズ表示——これらの動的な体験を検証したい場合に、Wizard of Ozが最も有効だ。 条件2：実装コストが検証コストを大幅に上回る エンジニアリング工数が数週間〜数ヶ月かかる機能の場合、「作ってから検証する」アプローチは投資リスクが高い。Wizard of Ozなら準備2〜3時間・実施数時間で「ユーザーはそもそもこの機能を使うか」という問いに答えが出る。 条件3：ユーザーの「実際の行動」を観察したい インタビューで「使いたいと思う」と言っても、実際に使う行動は別物だ。Wizard of Ozは実際の操作行動・つまずき・離脱を観察できる。アンケートやインタビューでは得られない行動データが目的のときに選ぶ。 逆に、Wizard of Ozを選ぶべきでない場面もある。パフォーマンス（応答速度・処理能力）を検証したい場合、デザインの細部（フォント・色・アニメーション）を検証したい場合は、別の手法を選ぶ。 --- テスト設計の5ステップ ステップ1：検証問いを1つに絞る 複数の問いを同時に検証しようとすると、セッションが散漫になる。Wizard of Ozは「1セッション1つの問い」が原則だ。 良い問いの例：「ユーザーは自然言語で検索条件を入力する行動を自発的に取るか」「AIのレコメンドに対してユーザーはどのような判断基準で受け入れ/拒否するか」 問いが決まったら、「何を観察すれば問いに答えられるか」を逆算する。完了行動・離脱行動・言語化した発言・身体的反応（戸惑い・前のめり・画面から目を離す）のどれを記録するかを事前に決める。 ステップ2：ウィザード環境を設計する ウィザード（人間オペレーター）が被験者に気づかれずに応答を返す仕組みを作る。 オンライン実施の場合： 被験者の画面共有を別ウィンドウで確認しながら、Figmaの変数書き換え・外部ツールへのテキスト送信・バックエンドの管理画面操作で応答を返す。ウィザードは被験者と別の通話に入り、進行役から「次のシナリオへ」のサインをもらう。 対面実施の場合： ウィザードは隣室または衝立の裏で、被験者の画面をミラーリングしながら操作する。進行役との連絡はチャットツールで行い、被験者には聞こえないようにする。 応答スクリプトが品質を決める。 事前に20〜30パターンの想定入力と応答を用意する。「処理中です」「もう少し詳しく教えていただけますか」など時間稼ぎ用のテンプレートも3〜5個準備する。 スクリプトが薄いと即興応答が増え、ウィザード個人の語彙癖が滲んでAI感が崩れる。 ステップ3：シナリオを設計する 「このツールを自由に使ってみてください」ではデータが取れない。ユーザーが実際の文脈で行動するように「状況設定」を用意する。 シナリオの4要素： - 背景（Context）： 「あなたは来週の企画会議に向けて競合調査をしています」 - 目標： 「この調査ツールを使って、3社の競合情報を比較したい」 - 制約： 「30分以内に情報をまとめる必要がある」 - 成功基準： 「比較表を作成できた状態」 ツール操作を目的にしたシナリオは、本来の利用文脈とかけ離れた行動を引き出してしまう。「ツールをテストする」のではなく「目標を達成しようとする人を観察する」という視点でシナリオを書く。 ステップ4：リハーサルを行う 本番前に必ずチームメンバーで通し練習をする。ウィザードが応答を返す速度・スクリプトのカバー率・進行役のファシリテーション——これらの連携をリハーサルで確認する。 実際にやってみると分かるのは、「想定外の入力」がリハーサル中に大量に出てくることだ。スクリプトに抜けが多いほど、本番でウィザードが焦る。リハーサルで出た想定外パターンをスクリプトに追加してから本番に臨む。 ステップ5：デブリーフィング計画を立てる セッション終了後、被験者に「実は裏で人間が応答していた」を開示するデブリーフィングが必要だ。これは倫理的に必須のステップであり、同時に最も豊かなデータが得られる瞬間でもある。 「実は手動で応答していたことをお伝えします。この体験を通じてどんな感想を持ちましたか」——この問いへの反応は、観察中に得られる行動データとは別の次元の洞察を含む。デブリーフィングの質問リストを事前に用意する。 --- セッション中の観察と記録 観察すべき3種類のデータ 行動データ： 何を入力したか、どこでつまずいたか、離脱したか完了したか。これは録画から後で確認できるが、リアルタイムでも進行役が簡単なメモを取る。 言語データ： 思考発話（Think Aloud）を依頼している場合の発言内容。「えっ、何これ」「あ、なるほど」「ここがよく分からない」——この発言は後の分析で重要な文脈を提供する。 非言語データ： 前のめりになる・椅子に寄り掛かる・画面から目を離す・眉をひそめる——これらの身体的反応は、行動データには含まれないが体験の質を示す。対面セッションでは進行役が記録し、オンラインではカメラ映像を確認する。 進行役が犯しやすいミス 誘導的なフォローアップ質問。 「ここが分かりにくかったですか？」という問いは被験者に答えを示唆してしまう。「今、少し手が止まりましたが、何を考えていましたか？」というオープンな問いで観察する。 沈黙を埋めようとする衝動。 被験者が考え込んで沈黙している時間は、最も重要な観察対象だ。進行役が焦って助け船を出すと、「ユーザーが自力でどう対処するか」というデータが消える。沈黙は最低30秒待つ。 --- 分析：データから洞察を抽出する パターンの発見 複数セッションの録画と観察メモを並べて、「同じ場所でつまずいた人が何人いたか」を数える。1人なら個人差・2人以上ならパターンだ。パターンになった箇所が、設計課題の有力候補となる。 完了/離脱の構造化 シナリオごとに「完了率」「離脱タイミング」「完了までの時間」を集計する。これだけで「どのフローに問題があるか」の地図が見える。次に「なぜそのタイミングで離脱したか」を、観察メモと発言データから仮説化する。 驚きを記録する 分析中に「これは予想していなかった」と感じた瞬間を全てメモする。POVステートメントの作成につながる洞察は、多くの場合「驚き」の中に潜んでいる。仮説を確認するデータより、仮説を崩すデータの方が価値が高い。 --- よくある失敗と対策 失敗1：ウィザードの応答が遅すぎて「壊れてる」と思われる 対策：応答スクリプトに「ただいま処理中です（3〜5秒の遅延を自然に見せるテンプレート）」を必ず含める。応答時間の目安は2〜8秒。10秒を超えると不自然さが際立つ。 失敗2：被験者がテスト中に「実は人間ですか？」と聞いてくる 対策：事前のブリーフィングで「自動システムです」と明言するか「詳細はセッション後にお話しします」と伝える。セッション中に問われたら「後ほど詳しくご説明します」と答え、デブリーフィングで必ず開示する。 失敗3：ウィザードがスクリプトにない入力に対応できない 対策：リハーサルで想定外入力を収集し、スクリプトを厚くする。それでも対応できない場合のために「お問い合わせの内容をより深く理解するためにもう少し時間が必要です」という汎用テンプレートを用意する。 失敗4：セッション後に被験者から「騙された」という不満が出る 対策：デブリーフィングの冒頭で「研究倫理上、事前に開示できない手法でした。ご協力に感謝します」と真摯に説明し、研究目的と意義を伝える。透明性と誠実さが参加者の理解につながる。 --- ペーパープロトタイピングとの使い分け ペーパープロトタイプは静的な画面遷移の検証に適している。Wizard of Ozは動的な応答・インタラクションの検証に適している。「押したらどこに遷移するか」はペーパーで、「入力した内容に対してどんな応答が返るか」はWizard of Ozで検証する。 ユーザビリティテストとの違いも押さえておく。ユーザビリティテストは実装済みのプロダクトやハイファイプロトタイプで「操作の問題点を発見する」ことが主目的だ。Wizard of Ozはそれより前段階で「そもそもこの機能・インタラクションは必要か」を問う。フェーズが違う。 --- Wizard of Ozテストの最大の価値は、「作らずに学べる」という速度にある。しかし「作らなかった分だけ設計が甘い」というトレードオフも存在する。ウィザードが応答したパターンをそのまま設計に採用するのではなく、「ユーザーがどう反応したか」という行動データを次の設計判断の材料として使う——これがこの手法を正しく活かす姿勢だ。 --- ### Wizard of Oz プロトタイピング — 名前の由来と「人手で裏側を回す」検証思想 URL: https://designthinking.studio/methods/wizard-of-oz-prototyping/ > 「自動で動いて見えるが裏側は人間が操作する」プロトタイピング手法。HCIで Jeff Kelley が1983年に名付けた経緯から、コンシェルジュMVPとの違い、AI時代に再評価される理由までを由来と思想の側面から解説する。 「機能を作る前に、その機能があったらユーザーがどう振る舞うかを知りたい」——プロトタイピングのすべては、この欲求から始まります。Wizard of Oz プロトタイピングは、その欲求にもっとも乱暴で、もっとも誠実に応える手法です。実装ゼロのまま、人間が裏で手を動かして「完成したシステム」を演じ、ユーザーには自動で動いているように見せる。 本記事は操作手順ではなく、名前の由来・思想・他手法との境界線——「なぜそう呼ばれ、なぜ効くのか」に焦点を当てます。 なぜ「オズの魔法使い」なのか 映画『オズの魔法使い』の終盤、ドロシーたちが恐れていた全能な「魔法使い」の正体は、カーテンの裏でレバーを引いていた一人の小柄な男でした。スクリーンに映る威厳は演出で、実体は手作業の操り手だった——この構図がそのまま手法名になっています。 この名前を HCI（ヒューマン・コンピュータ・インタラクション）の文脈で広めたのは、Jeff Kelley です。ジョンズ・ホプキンス大学の大学院研究のなかで（1980年前後に命名し、1983年の論文で初めて公表）、Kelley はこの語を印刷物として初めて登場させました。きっかけは大学院セミナーでの質問への返答だったと伝えられ、彼が「それはドロシーがオズの魔法使いで体験したのと同じことだ」と答えたことが命名の起点とされています。 Kelley の中心的な仕事は、SIGCHI '83（1983年12月、ボストン）での発表論文「An empirical methodology for writing user-friendly natural language computer applications」と、翌1984年の ACM Transactions on Office Information Systems 誌の論文です。検証の対象は、自然言語で命令を受け付けるオフィス向けアプリケーションでした。当時、文章で人間の指示を理解するソフトを本当に作るのは至難でしたが、「もし完璧に理解できたら、ユーザーはどんな言葉で話しかけるのか」を先に知りたい。 そこで Kelley は、別室の実験者がユーザーの入力をすべて読み取り、システムになりすまして応答を返す方法を採りました。ユーザーは自分が機械と対話していると信じている——それがこの手法の核です。 命名以前にも同種の実験は存在しています。NN/g（Nielsen Norman Group）は、1973年に Don Norman と Allen Munro が自動空港案内端末の評価で同様の手法を用いた例を挙げています。「人間が裏でシステムを演じる」発想自体は1970年代から実践されており、Kelley はそれに後世まで残る名前を与えた人物だと位置づけるのが正確です。 定義の核心 — 「自律して見える」が条件 NN/g はこの手法を「ユーザーが、自律的に見えるが実際には（全体または一部を）人間が制御しているインターフェースと対話する、モデレートされた調査手法」と定義しています。 この定義で見落とせないのが「自律的に見える（appears to be autonomous）」という条件です。ユーザーが「裏に人がいる」と気づいた瞬間、得られるデータの性質が変わります。人は相手が機械だと思うと容赦なく振る舞い、相手が人間だと思うと無意識に気を遣う。Wizard of Oz が捉えようとしているのは前者——まだ存在しない自動システムに対して、人が「自然に」見せる反応です。だからこそ「魔法使いの正体を隠す」ことそのものが手法の生命線になります。 検証の対象になりやすいのは、作るのが重く・高くつく領域です。 - 自然言語での対話（チャットボット、音声アシスタント） - 推薦・パーソナライズ（一人ひとりに最適化した提案の精度） - 画像・音声の認識、自動分類 - 複雑な業務自動化のフロー 共通するのは「裏側の実装は重いが、ユーザーから見える振る舞いは人間が即興で代替できる」という非対称性です。Wizard of Oz は、この非対称性を突いて開発コストの先払いを回避します。 コンシェルジュMVP との違い — カーテンを引くか、開けるか Wizard of Oz はしばしばコンシェルジュMVP（Concierge MVP）と並べて語られますが、両者は思想が異なります。 | 観点 | Wizard of Oz | コンシェルジュMVP | |------|--------------|------------------| | 人手の存在 | 隠す（ユーザーは自動だと信じる） | 明かす（人が手厚く対応すると分かっている） | | 主に検証するもの | インターフェースの振る舞い・自動化の前提 | 価値・需要・体験そのもの | | ユーザーの認識 | 機械と対話していると思っている | 人と対話していると分かっている | カーテンを引いたまま機械のふりをするのが Wizard of Oz、カーテンを開けて「いまは人がやっています」と見せるのがコンシェルジュです。「インターフェースに対する自然な反応」を知りたいなら前者、「そもそもこのサービスに人はお金や時間を払うのか」を知りたいなら後者を選びます。対立ではなく、検証したい問いが違うだけの隣り合う道具です。 なぜ AI 時代にこの手法が再評価されるのか Kelley が自然言語インターフェースで使った手法が、いま再び注目されています。「裏側の実装が重く、表側の振る舞いは人が演じられる」という非対称性が、AI 機能で極端に大きいからです。 AI を組み込んだ機能は、モデルの選定・学習・チューニングに相当のコストがかかります。にもかかわらず、いざユーザーに使わせると「そもそもこの機能を信頼して任せる気にならない」「期待していた応答の粒度と違う」といった、実装の精度以前のところで躓くことが珍しくありません。Wizard of Oz は、その「実装以前の問い」を実装ゼロで確かめさせてくれます。人間が完璧な AI を演じきった状態でユーザーがどう反応するか——そこに拒否反応があるなら、モデルをどれだけ磨いても解決しないからです。 Kelley の原点がここで効いてきます。彼が知りたかったのは「機械をどう作るか」ではなく「人が機械にどんな言葉で話しかけるか」でした。技術が進歩しても、検証すべき本質が「人間側の振る舞い」にある限り、人手で裏を回すこの手法は古びません。 思想としての一行 Wizard of Oz の根にあるのは、デザイン思考が共有する「Fail early, fail often（早く、たくさん失敗する）」の精神です。完成品を作ってから市場で失敗するのではなく、人間が一時的に機械を演じることで、失敗を実装の手前に前倒しする。 魔法使いの正体が「カーテンの裏の手作業」だったように、検証の魔法もまた、地味な人手の即興によって成立します。派手な自動化の幻を、安く・早く・誠実に試すための手法——それが Wizard of Oz プロトタイピングです。 関連項目 - プロトタイピング手法の全体像 — ペーパープロト・Wizard of Oz・デジタルの使い分け - ウィザード・オブ・オズ法 — 動かない裏側を人間が動かして検証する - エクスペリエンス・プロトタイピング --- ### Wizard of Oz プロトタイプ 実践ガイド — 低コストで高精度なユーザー検証 URL: https://designthinking.studio/methods/wizard-of-oz-prototyping-guide/ > 開発コストゼロでAI・自動化・複雑機能の実体験をシミュレートするWizard of Ozプロトタイピング。設計から実施・分析まで、ファシリテーター視点で徹底解説。 「このAI機能は本当に使われるのか」——その答えは、実装してみるまでわからない、と思われがちだ。しかしWizard of Ozプロトタイピングは、AIを一行も実装せずに「AIらしさの体験」をユーザーに提供し、行動データを収集できる手法だ。名前の由来は映画『オズの魔法使い』。強大な魔法使いに見えた「オズ」が、実はカーテンの裏の小さな人間だったように——被験者には自動で動いているように見えて、裏ではウィザード（人間オペレーター）が手動で応答を返す。 --- なぜWizard of Ozが必要なのか 問題：「実装コスト先払い」の罠 AI機能・チャットボット・パーソナライズ・複雑な自動化——これらの機能は、ペーパープロトタイプでは検証できない。ユーザーが入力した内容に応じてリアルタイムに応答が変わる体験は、静的なモックアップでは再現不可能だからだ。 しかし実装を先行させると、データパイプライン構築・モデル選定・推論環境整備で最低でも数週間〜数ヶ月のエンジニアリング投資が発生する。「実装してみたら、ユーザーがそもそも欲しくなかった」という発見は、AIプロダクト開発における最も高価な失敗だ。 親近感：「最小検証」の難しさ ワークショップでよく起こるのは「最低限の機能で試そう」という合意が崩れていくプロセスだ。「最低限」と言いながら、エンジニアが「せめてこれくらいの品質でないと検証にならない」と判断し、実装スコープが膨らむ。その結果、検証が3ヶ月後に始まる。 参加者からの声として多いのは「いつの間にかMVPが普通の製品開発になっていた」という振り返りだ。Wizard of Ozはこの構造を断ち切る。「最低限の検証」を技術的に担保するのではなく、人間の手作業で担保する発想の転換だ。 解決策：人間がAIを演じる Wizard of Ozの核心は「被験者をだます」ことではなく「実使用文脈での行動データを得る」ことだ。被験者は「自動で動いているシステム」と思って自然に操作し、その結果として「本番と近い文脈での反応」が生まれる。ウィザードが人間であるという事実は、テスト終了後にデブリーフィングで開示する。 この手法が最初に体系化されたのは、1983年にJohn F. KelleyがJohns Hopkins大学の博士論文として発表した自然言語インタフェース研究に端を発する。後にIBMがこの手法を採用したことで広く知られるようになり、プロダクト開発の文脈では「開発なしにユーザー体験を検証する」スタンダードな手法として定着している。 --- 実施手順：ステップバイステップ ステップ1：検証スコープの確定（30分） 最初に「何を検証するか」を一つに絞る。複数の機能を同時に検証しようとすると、ウィザードの操作が破綻する。 確定すべき4項目： - 入力：ユーザーが何をするか（テキスト入力/ボタン操作/音声など） - 処理：ウィザードが裏で何をするか（応答文を選ぶ/画面を切り替えるなど） - 出力：被験者の画面に何を表示するか - 応答時間：実際のAIを想定した遅延時間（2〜5秒が多い） スコープ確定の判断基準： 「ウィザード1人が15秒以内に応答できるか」。これを超えると被験者が「おかしい」と感じ始める。 ステップ2：ウィザード用ツール・環境の準備（60〜90分） 被験者側の環境： - FigmaプロトタイプまたはHTMLモック（操作可能な状態） - 可能であれば実際のサービスに見えるUI ウィザード側の環境： - 被験者の画面をリアルタイムで確認できる手段（画面共有、別ウィンドウなど） - 応答を返す手段（テキスト注入ツール、Slack経由の更新など） - 応答スクリプト（20〜30パターンを事前に用意） 応答スクリプトの設計が全体の品質を決める。 想定パターンが薄いと即興応答に頼ることになり、ウィザードの個性が滲んでAI感が崩れる。スクリプトは「想定パターン」「時間稼ぎ用テンプレ（「処理中…」「より詳しい情報を確認しています」）」「エラー応答パターン」の3種類に分類しておく。 ステップ3：シナリオ設計（30分） 被験者に自然に操作してもらうための「状況設定」を作る。 設計の要素： - 文脈（Context）： 「あなたは来週のプレゼン資料を作っています。このツールを使って〜」 - タスク： 具体的にやってもらうこと - 成功基準： 「ここまで達成できたら次のシナリオへ」 - 制限時間： 10〜15分/シナリオ 重要： シナリオは「ツールを使ってください」ではなく「〇〇という状況で〇〇したい」という自然な文脈で提示する。ツール操作を目的にすると、本来の利用文脈とかけ離れた行動が観察されてしまう。 ステップ4：ウィザードのリハーサル（30分） 本番前に必ずリハーサルを行う。チームメンバーが被験者役を担い、ウィザードが応答する練習をする。 確認項目： - 応答時間が自然か（速すぎず遅すぎず） - 想定外の入力への対処ができるか - ウィザードの存在が漏れないか（操作音、通知音など） 実際にやってみると、リハーサルで「想定外の入力」が大量に出てくる。これがスクリプトの穴を埋める最良の機会だ。 ステップ5：テスト実施（40〜60分/被験者） 開始前の説明： 「これはシステムの動作確認です。自由に操作してください。考えたことを声に出してもらえると助かります」——「裏で人が動かしている」ことは言わない。ただし「AI機能」と明示的に説明する必要もない。 ウィザードの心得： - 応答テンプレを最大限活用し、即興を最小化する - 「100%正解」を出し続けない。たまに「理解できませんでした」の応答を混ぜる（AI感の維持） - 応答時間に軽いランダム性を入れる（毎回ぴったり3秒は不自然） テスト進行役の役割： 被験者の発話を促す。「今何を考えましたか」「期待通りでしたか」の問いかけを自然なタイミングで挟む。 ステップ6：デブリーフィング（15〜20分） テスト終了後、被験者に「実は裏で人が動かしていました」と開示する。これは倫理的な義務であり、追加のデータ収集の機会でもある。 デブリーフィングで引き出す情報： - 「途中で変だと感じた瞬間はありましたか」 - 「もし本当のAIだったら何が変わると思いますか」 - 「期待していた応答と違った瞬間はどこでしたか」 - 「このシステムを日常的に使うとしたら、どんな状況ですか」 種明かし後の驚きの反応と、その後の発言を丁寧に記録する。このタイミングで出る言葉は率直で価値が高い。 --- ファシリテーションのコツ ウィザードは「AI」を演じるのではなく「自然なシステム」を演じる。 AIらしさを過剰に演出しようとすると、かえって不自然さが際立つ。「適切な応答を返すシステム」として振る舞うことで、被験者の没入が維持される。 セッション間に30分の振り返りを挟む。 複数セッションを連続で実施すると、ウィザードの疲労から応答品質が下がる。セッション間の振り返りで「想定外だったパターン」を共有し、スクリプトに追加する。 応答テンプレを全員が把握しておく。 ウィザードが2名体制の場合（1名が応答、1名が記録）、記録担当もスクリプトを理解していると「この応答で被験者の反応がどうだったか」の分析が深まる。 --- 既存メソッドとの比較・使い分け | 軸 | ペーパープロト | Wizard of Oz | 高忠実度プロト | |---|---|---|---| | 適した検証 | 静的UI・画面遷移 | 動的応答・AI・自動化 | UIの細部・実使用感 | | 準備コスト | 低（1〜2時間） | 中（半日） | 高（数日〜数週間） | | ウィザード要否 | 不要 | 必要（1〜2名） | 不要 | | 得られる学び | 概念伝達・情報設計 | 期待値・応答品質・行動パターン | 視覚品質・操作感 | | 適したタイミング | Discovery初期 | Discovery後半〜Define | Develop後半 | ペーパープロトとWizard of Ozの組み合わせが最もコスト効率が高い。 まずペーパープロトで「画面の概念が伝わるか」を検証し、次にWizard of Ozで「動的な振る舞いに対する期待値」を検証する流れが定石だ。 ペーパープロトタイピングとプロトタイピング手法の全体像も参照してほしい。 --- よくある失敗と対策 失敗1：ウィザードの存在が被験者にバレる 最も頻繁に起こる失敗だ。応答時間が一定すぎる、応答内容に個人の文章スタイルが出る、操作音が漏れる——いずれかで被験者が「これは人が動かしている」と気づく。一度気づくと、被験者の行動データが「演技への反応」になってしまう。 対策： - ウィザードを物理的に別室または別ウィンドウに隔離する - 応答テンプレを中心に使い、即興を最小化する - 応答時間に1〜2秒のランダム性を加える - 事前リハーサルで「バレるポイント」を洗い出す 失敗2：応答スクリプトの準備不足 「20パターン用意したのに、被験者が全く別の方向で操作した」というケースは珍しくない。準備したスクリプトが被験者の行動パターンを前提としすぎると、即興で対応する局面が増える。 対策： - スクリプトを「想定入力への応答」ではなく「応答カテゴリ」で分類する（情報提供型、確認型、エラー型、時間稼ぎ型） - 「理解できませんでした。もう少し詳しく教えてください」系の時間稼ぎを10種類以上用意する - リハーサルで「チームメンバーが一番変な操作をするコンテスト」を開いてスクリプトの穴を埋める 失敗3：デブリーフィングを省略する 「テスト観察で十分なデータが取れた」と判断して種明かしを省略すると、倫理的な問題だけでなくデータの損失にもなる。デブリーフィング後の率直な発言は、観察データでは得られない洞察を含む。 対策： テスト進行のアジェンダに「デブリーフィング15分」を必ず含める。時間が足りなくなった場合も、種明かしと最低限の反応収集は省略しない。 --- B2B・社内プロジェクトへの応用 Wizard of Ozは「消費者向けAI製品」のイメージが強いが、社内システム・B2B SaaSの検証でも高い効果を発揮する。 社内ワークフロー自動化の検証： 「AIが申請書を自動分類する」機能を実装前に検証する場合、人間が分類担当者として申請書を手動でふり分け、それを「自動分類されたもの」として申請者に提示する。申請者が「誤分類」にどう反応するか、「どんな誤分類は許容できるか」が実装前に把握できる。 コールセンターの自動応答検証： 顧客の問い合わせに対してオペレーターが「AIらしい応答テンプレ」で回答し、顧客がどの段階で「人間に繋いでほしい」と言うかを観察する。 ワークショップでよく起こるのは「社内向けなら多少精度が低くても許容される」という楽観的な想定が崩れるケースだ。B2B・社内でもユーザーの期待値は高く、Wizard of Ozで検証することで「許容できる誤答率」を事前に把握できる。 --- 関連手法 - ペーパープロトタイピング - プロトタイピング手法の全体像 - Desirability Testing --- ### Wizard of Ozテスト 応用技法 — AIシステムのプロトタイプ検証に使う URL: https://designthinking.studio/methods/wizard-of-oz-advanced-technique/ > チャットボット・音声アシスタント・生成AIのプロトタイプ検証にWizard of Ozを応用する上級技法。AIシステム固有のウィザード構成バリエーションと、失敗しやすいポイントを実務視点で解説する。 Wizard of Oz プロトタイプ 応用としてAIシステムを検証したいとき、基本的な手法の枠組みだけでは通用しない場面があります。チャットボット・音声アシスタント・生成AIを対象にした場合、ウィザード（人間オペレーター）が演じるべき「AIらしさ」の質が、一般的なUIモックとは桁違いに高い要求水準になるからです。AIシステム固有の検証問いに対応するためのウィザード構成バリエーションと、上級テクニック、陥りやすい失敗パターンをまとめます。 --- 基本手法との違い：AIシステムに固有の難しさ 一般的なWizard of Ozでは、静的なUIモックの画面遷移をウィザードが操作します。被験者がボタンを押したら、ウィザードが次の画面に切り替える——この操作は準備した選択肢から選ぶ作業です。 AIシステムの場合、それだけでは足りません。 問題1：応答の「粒度」が検証の核心になる チャットボットや音声アシスタントで検証したいのは「UIを操作できるか」ではなく、「この応答の品質・温度・粒度に対してユーザーはどう反応するか」です。ウィザードが返す応答の質そのものが検証変数になります。 問題2：無限の入力バリエーション ボタンクリックは有限の選択肢ですが、自然言語入力は事実上無限です。「期待していない入力が来たときにどうするか」を設計しておかないと、ウィザードは即興で破綻します。 問題3：「人間っぽさ」と「AIっぽさ」の矛盾 被験者がAIと対話していると信じるためには、応答が「人間的すぎない」必要があります。しかし品質を上げようとすると、ウィザードは自然と人間的な応答を書いてしまう。この矛盾の管理が、基本手法にはない課題です。 --- セットアップ手順：AIシステム向けの準備 Step 1：検証問いの解像度を上げる（30分） AIシステムのWoZでは、検証問いが曖昧なまま始めると何も分からずに終わります。以下の3軸で問いを分解します。 - 信頼軸：ユーザーはこのAIの応答を信頼して行動を変えるか - 期待軸：ユーザーがAIに期待する応答の粒度・トーン・文量はどのくらいか - 依存軸：AIがなければできない操作が発生したとき、ユーザーはどう対処するか 例えば「採用スクリーニング支援AIのチャットボット」を検証する場合、「信頼軸：AIが出したスコアを根拠に面接を省略するか」を問いにすると、観察すべき行動が明確になります。 Step 2：応答スクリプトの設計（45〜60分） 基本手法の20〜30パターンを、AIシステム向けには30〜50パターンに拡張します。設計の原則は「AIトーン・文量・エラーパターンの3セット」を用意することです。 AIトーン設計：想定するAIのキャラクター（簡潔なビジネス向けか、会話的な消費者向けか）に合わせて、ウィザードが使う言い回しのガイドラインを文書化します。「〜です」「〜ました」で終わる、1応答あたりの文量は2〜4文以内、感嘆符は使わない、といったルールを事前に確定します。 エラーパターン設計：「処理できませんでした」「情報が不足しています」「もう少し具体的に教えてください」など、AIがよく出す「外し方」のテンプレートを5〜8種類準備します。完全に正解し続けるAIは不自然で、被験者の没入が浅くなります。 時間稼ぎパターン：ウィザードが応答を考える時間が必要なとき、「確認中です」「分析しています」など処理中を示す短文を5〜7種類用意します。2〜4秒程度のディレイの後に出すことで、AIの処理時間を演出します。 Step 3：ウィザード2名体制の役割分担（15分） AIシステムのWoZでは、ウィザード1名での運用は推奨しません。 - 応答担当ウィザード：スクリプトを参照しながら応答を生成し、被験者の画面に送る - ログ担当ウィザード（ビハインドザシーン観察者）：被験者の発言・行動・表情の変化を記録する。応答担当がログを同時に取ると、応答品質が落ちます 2名が同じチャンネル（Slackのプライベートチャンネルなど）でリアルタイムに情報共有しながら進行します。「次の入力が来る前に応答担当がどのパターンを使うか」を事前に擦り合わせる短い合図ルールも設計しておきます。 --- AIシステム固有のWoZバリエーション バリエーション1：チャットボットWoZ 最もシンプルな構成です。被験者がWebまたはモバイルのチャット画面に入力し、ウィザードが別端末から応答を送る形式です。 注意点：メッセージアプリのリアルタイム通知（「入力中...」表示）がウィザードの操作スピードと噛み合わないと、「人間が返している」と被験者が察知します。対策として、Figmaのプロトタイプでチャット画面をスタティックに作り込み、応答はウィザードが画面を書き換える形式にすると制御しやすくなります。 適した検証問い例：「ユーザーは自発的にAIに複数ターン以上の質問を続けるか」「AIの提案を拒否するときにどんな言葉を使うか」 バリエーション2：音声アシスタントWoZ 「Siriに話しかけるつもりで使ってください」と被験者に伝え、実際の音声認識と合成音声をウィザードが代替します。 ツール構成：被験者の発話をウィザードが聞き取り（または文字起こしツールを補助的に使い）、テキストで応答を選択し、音声合成ソフト（macOSのsay コマンド、またはElevenLabsなどのリアルタイムTTS）で再生します。 注意点：音声合成のレイテンシが高いと、発話してから応答が来るまでの沈黙が長くなり、被験者の集中が切れます。ウィザードが応答を入力し始めるタイミングを、被験者の発話が終わる直前（発話パターンを読む）にする練習が必要です。 適した検証問い例：「ユーザーは音声AIに対してどの程度の文量で話しかけるか」「AIが聞き返したとき、ユーザーは言い直すか諦めるか」 バリエーション3：生成AI埋め込み機能WoZ 「文書要約」「コード補完」「翻訳改善提案」など、既存ワークフローに生成AIを組み込む機能の検証に使います。ウィザードが実際のAI出力を「事前生成」しておくか、セッション中にリアルタイムで生成します。 ツール構成：検証シナリオで使われると想定する入力パターンを事前に洗い出し、それぞれに対してChatGPT・Claude等で実際に出力を生成しておきます。セッション中はウィザードがその出力をコピー&ペーストします。これにより「本物のAI出力への反応」を検証できます。 注意点：事前生成した出力が網羅できない入力が来たとき、ウィザードがリアルタイムに生成ツールを操作する必要があります。この作業に時間がかかりすぎると、ディレイが不自然になります。「30秒以上かかりそうなら処理中テンプレを挟む」ルールを決めておきます。 適した検証問い例：「AI生成の要約に不満があるとき、ユーザーはどの程度の精度を期待して編集するか」「AI出力をそのまま使う/編集する/無視するの分岐はどこで起きるか」 --- 失敗しやすいポイントと対策 失敗1：「AIトーン統一」を怠る ウィザードが2〜3セッション進むうちに、疲れや慣れで応答スタイルが崩れます。最初は簡潔だった応答が長くなったり、口語的な言い回しが混じったりします。被験者間で体験の質が変わると、データが比較できません。 対策：各セッション開始前に応答ガイドラインを声に出して読み合わせる（30秒）。セッション後にログ担当がトーンの逸脱箇所を指摘し、次セッション前に修正します。 失敗2：被験者のタスクスコープが広すぎる 「AIを使って業務を効率化してみてください」のような曖昧なタスクでは、被験者がAIのどの側面を試しているのかが分散します。ウィザードが対応しなければならない入力バリエーションが爆発し、スクリプトが破綻します。 対策：タスクを「〇〇をAIに依頼して、その結果でXXをしてください」の形式に絞ります。入力の起点と終点が明確なタスクにすることで、ウィザードが準備すべきシナリオの範囲が定まります。 失敗3：デブリーフィングを「種明かし」で終わらせる 「実は人間が操作していました」と伝えた後、被験者が照れて正直に話さなくなるケースがあります。特にAIシステムに期待しすぎていた場合、「だまされた」という感覚が反応の正直さを阻害します。 対策：種明かしの伝え方を工夫します。「システムではなく、チームの一員が手動で応答していました。これはAIの振る舞いを設計するための研究です」と伝え、被験者の判断ではなく「チームが学ぶための材料」というフレームに変えます。その上で「もしAIの応答がもっと完璧だったとしたら、どう感じましたか」と仮定形で聞くと、被験者が本音に戻りやすくなります。 失敗4：「AIが完璧すぎる」セッションになる ウィザードが全問正解し続けると、被験者はAIを過信した状態でテストを終えます。実際の製品では必ず「外れ」が発生するため、完璧なセッションから得られるデータは現実との乖離が大きくなります。 対策：意図的に「外し」を設計します。例えば5〜6ターンに1回、若干ずれた応答（ユーザーの質問を少し取り違えた内容）を返す計画を組み込みます。被験者が外れに対してどう反応するか（再入力・諦め・別の言い方）は、AIシステムのエラー回復設計にとって最も価値の高いデータです。 --- セッション後の分析：AIシステム固有の観察点 基本的なWoZのデータ収集に加えて、AIシステム固有で記録すべき観察点があります。 応答待機中の行動：被験者がAIの応答を待っている間に何をするか（別タブを開く、スマホを見る、声に出して独り言を言う）は、AIへの信頼・期待値の間接的な指標です。 言い直しの回数と変化パターン：AIに期待通りの応答が来なかったとき、被験者がどう言葉を変えて再入力するかは、ユーザーが「AIに何を求めているか」の最も生々しいデータです。この言い直しのログは、プロンプト設計とUIコピーの両方に持ち帰ります。 信頼の臨界点：何度目の外れで「このAIは使えない」と判断したか、または最後まで諦めずに使い続けたか。この臨界点の個人差を記録しておくと、ターゲットユーザーのAIリテラシーと忍耐閾値の設計根拠になります。 --- 関連項目 - ウィザード・オブ・オズ法 — 動かない裏側を人間が動かして検証する - Wizard of Oz プロトタイピング — 名前の由来と「人手で裏側を回す」検証思想 - Wizard of Oz テスト法の実践完全ガイド - Wizard of Oz プロトタイプ 実践ガイド - ペーパープロトタイピング --- ### アサンプション・マッピング URL: https://designthinking.studio/methods/assumption-mapping/ > プロジェクトや解決策に含まれる「暗黙の前提」を可視化し、検証の優先順位をつけるワーク。リスクの高い仮説を早期に特定し、プロトタイプとテストの戦略を立てるための問題定義手法。 アサンプション・マッピング（Assumption Mapping）は、 プロジェクトや製品・サービスのアイデアに潜む「暗黙の前提（仮定）」を洗い出し、「重要度」と「不確実性」の2軸でマッピングすることで、検証すべき仮説の優先順位を決める手法 です。 多くのプロジェクトが失敗する原因は、検証されていない前提の上に解決策を構築することにあります。「ユーザーはこの機能を使いたいはずだ」「このニーズは市場に存在する」「このプロセスで実現できる」——これらの「はずだ」は仮定であり、検証されていない仮説です。アサンプション・マッピングは、その仮説を意識の外から意識の上に引き上げます。 なぜアサンプション・マッピングが必要か 問題定義フェーズでは、観察やインタビューで得た情報をもとに「HMW（どうすれば〜できるか）」という問いを立てます。しかしこの問いに答えるアイデアを実行に移す前に、 そのアイデアが機能するために必要な「前提条件」を明示化する ステップが必要です。 200回以上のワークショップ観察で繰り返し確認されてきたパターンがあります。「良いアイデアだ」と確信を持ってプロトタイプを作ったが、テストで根本的な前提が崩れていることが発覚し、一から作り直しになる——というケースです。アサンプション・マッピングは、この「早すぎる確信」を防ぐための構造的なチェックです。 ステップ Step 1：前提（アサンプション）を書き出す チームで5〜10分、 「このアイデアが成功するために必要な前提は何か」を付箋に書き出します（1枚1仮定）。 以下の問いが書き出しの助けになります。 - ユーザーは誰で、どんな行動をとるか？（「ユーザーは〇〇だ」という仮定） - このサービス・製品は機能するか？（「〇〇で実現できる」という仮定） - ビジネスとして成立するか？（「ユーザーは〇〇のためにお金を払う」という仮定） - 組織的に実行できるか？（「パートナーが〇〇に協力してくれる」という仮定） 批判を保留して書き出す量を優先します。最初のセッションでチームが10〜20枚の付箋を出せれば十分です。 Step 2：2×2マトリクスに配置する 縦軸を「重要度（高←→低）」、横軸を「不確実性（高←→低）」にした2×2マトリクスを描きます。 各付箋を、 「このプロジェクトにとってどれくらい重要か」と「これが本当かどうか、今どれくらい分からないか」 の2つの問いで判断しながら配置します。全員で議論しながら位置を決めます。意見が割れること自体が重要な情報です。 Step 3：優先度の高い仮説を特定する マトリクスの 「重要度：高 × 不確実性：高」の象限に入った仮説が、最も早急に検証すべき仮説 です。これらはプロジェクトの成否を左右するにもかかわらず、正しいかどうかが分かっていない前提です。 「重要度：高 × 不確実性：低」の象限は、重要だが既知の事実として扱える仮説です。「重要度：低 × 不確実性：高」は、不確かだが失敗しても致命的でない仮説です。これらは検証の優先度を下げます。 Step 4：検証計画を立てる 優先度の高い仮説（重要度高×不確実性高）について、 「この仮説をどうテストするか」を決めます。 仮説の種類によって、適切な検証方法は異なります。「ユーザーがこの問題を抱えているか」という仮説はユーザーインタビューで検証します。「このUIで操作できるか」はプロトタイプテストで、「お金を払う意欲があるか」はランディングページとコンバージョン測定で検証できます。各仮説に検証方法と担当・期限をセットで決めることで、アクションプランに変換します。 マトリクスの読み方 | 重要度 | 不確実性 | 対処法 | |--------|---------|--------| | 高 | 高 | 今すぐ検証する（最優先） | | 高 | 低 | 前提として記録し、監視する | | 低 | 高 | 余裕があれば検証する | | 低 | 低 | 無視してよい | よくある前提の種類 デザイナブルな前提（望ましい） 「ユーザーは月1回以上この問題に直面する」「ユーザーはスマートフォンでこのタスクを完了しようとする」——これらは共感フェーズのリサーチで検証可能な前提です。 ビジネスモデルの前提 「1,000円/月の料金を支払う意欲がある」「法人顧客が10社でユニットエコノミクスが成立する」——これらは市場調査・インタビュー・MVP（最小限の製品）でテストできます。 テクニカルな前提 「現在の技術でリアルタイム処理できる」「既存システムとのAPI連携が可能」——これらはエンジニアリングのスパイク（小さな実験）で確認します。 ファシリテーションのポイント 「正しい位置に置かなければ」という心理的負荷を下げる ことが重要です。「この付箋、右上か左上か迷ってる」という発言が出たら、「迷っているなら境界に置いてみましょう」と促します。完璧な配置より、 「なぜ迷っているか」の議論から出るインサイトの方が価値があります。 「この前提は本当に仮定か、既知の事実か」という問いも有効です。「ユーザーがスマートフォンを持っている」という前提が、データで検証済みなのか思い込みなのかを区別することで、マトリクスの精度が上がります。 「不確実性」を客観的に評価することは難しいため、 「この前提が間違っていたら、どの程度プロジェクトへの影響があるか」という問いで代替する と議論がしやすくなります。 接続する手法 アサンプション・マッピングの後は、優先度の高い仮説を検証するためのプロトタイプ設計に移ります。またリーン・キャンバスと組み合わせることで、ビジネスモデル全体の仮説を一覧化した上でアサンプション・マッピングを行うことができます。抽出した仮説を反証可能な実験に落とし込む標準手順はテストカード実験設計法で詳しく解説しています。 --- 参考文献 - Jeff Patton, User Story Mapping, O'Reilly Media, 2014 - David J. Bland & Alex Osterwalder, Testing Business Ideas, Wiley, 2019 - Eric Ries, The Lean Startup, Crown Business, 2011 --- ### アフィニティ図（KJ法）— 大量の定性データを構造化する情報整理メソッド URL: https://designthinking.studio/methods/affinity-diagram-method/ > ユーザーインタビューや観察で集めた膨大な定性データを、パターンとインサイトに変換するアフィニティ図の実践手順。作業の流れ、ファシリテーションのコツ、よくある失敗を網羅的に解説する。 アフィニティ図（Affinity Diagram）は、大量の定性データを、意味のあるパターンとインサイトに構造化する情報整理の手法です。文化人類学者の川喜田二郎が1960年代に考案した「KJ法」をデザイン思考文脈に適応させたもので、共感フェーズで集まったインタビュー記録・観察メモを定義フェーズに変換する橋渡し的な役割を担います。 混乱に構造を与える ユーザーリサーチを10人以上に行うと、収集した発言・観察・感情メモは数百枚の付箋や数十ページのノートになります。この量を前にしたとき、ワークショップのエネルギーが一番落ちます。「何が重要か分からない」「どこから始めればいいか分からない」。 アフィニティ図は、個別の観察を「グループ」→「テーマ」→「インサイト」という3層の抽象化によって整理します。しかし本当の価値は「整理したデータ」ではありません。 付箋を動かしながら「この2つは似ているか？」「この違いは何を意味するか？」と会話するプロセスそのものが、インサイト生成の核心です。データの整理が目的ではなく、会話の素材として使う。この認識がないと、見た目が整ったけれど何も言わないアフィニティ図ができます。 ステップ Step 1：データの付箋化（個人作業、30〜45分） インタビュー・観察で収集したデータを付箋に転記します。1枚の付箋に1つの観察・発言・行動のみを書きます。この時点ではカテゴリ分けは不要です。 書き方のルール： - 1観察=1付箋（複数の情報を1枚に書かない） - 行動・発言は「解釈なし」で書く（「〜と言っていた」「〜していた」） - 感情や推測は別の色の付箋で区別する - 誰の発言・観察かをコードで記録する（「I3：インタビュー対象者3番」など） 全員がデータを付箋化したら、壁またはホワイトボードに全付箋を無作為に貼ります。 Step 2：沈黙でグループを作る（全員作業、30〜60分） 重要：このステップは会話なしで行います。 全員が付箋を読みながら「似ている付箋」を近くに寄せていきます。会話なしで行うことで、各自の判断基準が可視化され、後の議論の素材が生まれます。 グループを作る際のルール： - 「何となく近い気がする」という直感で動かして良い - 1枚だけのグループがあっても良い - 同じ付箋を複数人が違う場所に移動させようとしたときは、そのまま何度か繰り返す（後で議論する） - 3〜5分経過ごとに全体を見渡して、付箋を動かし続ける この沈黙の作業が終わると、壁には10〜20個程度のグループができています。 Step 3：グループに仮タイトルをつける（議論、30〜45分） 沈黙の作業が落ち着いてきたら、声を出した議論に移ります。各グループを見ながら「このグループは何を共通して示しているか？」を議論し、仮のタイトルを付箋に書いてグループの上部に貼ります。 タイトルの書き方： - 名詞ではなく「洞察の文」で書く（「待機時間」ではなく「待機中の不確実性がストレスを生む」） - グループ内の全付箋を包含するタイトルにする（一部だけを説明するタイトルは不適切） - 「〜の傾向がある」「〜という状況」など動的な表現を使う Step 4：グループのグループを作る（上位テーマ化） 仮タイトルがついたグループを見渡し、「関連するグループを束ねた上位グループ」を作ります。3〜5個の上位グループができると全体の構造が見えてきます。 上位グループのタイトルは、より抽象度の高い洞察の文で書きます。「情報へのアクセス困難」「コントロール感の喪失」「期待と現実のギャップ」のような、設計に影響するインサイトレベルの表現が理想です。 Step 5：インサイトの言語化 上位グループのタイトルを元に、設計に使えるインサイト文を書きます。インサイト文は「[パターン/傾向]が観察される。これは[なぜなら/にもかかわらず/という状況において]〜を示している」という構造で書くと、問題定義に直結しやすくなります。 インサイト文の例：「ユーザーは待機中に複数回スタッフに声をかけようとして、途中で諦めているパターンが観察される。これは『質問することで迷惑をかける』という遠慮が、情報へのアクセスを自己制限させていることを示している」 ファシリテーションのコツ 沈黙の時間を守る Step 2の沈黙のグループ化は、多くのファシリテーターが「議論しながらやりましょう」と変更したがります。しかし沈黙で行うことには明確な意図があります。会話なしで行うと、「声の大きい人の分類が採用される」バイアスを排除でき、各自の分類の違いが後の議論を豊かにします。 「カテゴリ」ではなく「洞察」でタイトルをつける 最も頻出する失敗は「顧客の年齢」「機能の種類」「使用シーン」など、カテゴリでグループを作ってしまうことです。アフィニティ図の目的はデータの分類ではなく、パターンから意味を引き出すことです。タイトルが設計への示唆を含む「洞察の文」になっているかを常に確認します。 全員が付箋を動かせる状況を作る 議論の主導権が1〜2名に偏ると、グループの視点が狭まります。「今、他のグループはこのテーマをどう見るか？」という問いを挟んで、全員の参加を促します。 よくある失敗と対策 失敗1：付箋の粒度が大きすぎる 「ユーザーは情報不足で困っていた」という1枚の付箋は、複数の観察が混在しています。付箋化の段階で「1観察1付箋」を徹底します。後からでは分解が難しい。 失敗2：グループが多すぎる/少なすぎる 最終的なグループ数の目安は「データ量の平方根」程度。100枚の付箋なら10グループ前後が整理しやすい。グループが30以上になったら上位グループ化を先に進め、3以下になったら分解を試みます。 失敗3：インサイトではなく要件を書く 「〜機能が必要」「〜を改善すべき」という設計要件をインサイト文に書いてしまうケース。インサイトは「何が起きているか・なぜ起きているか」の観察で、「何をすべきか」は次のHMWフェーズで考えます。 アフィニティ図の次のステップ 抽出したインサイトを元にPOV文を作成し、さらにHow Might Weの問いに変換することで、創造フェーズへの橋渡しが完成します。アフィニティ図のインサイトから直接HMWを導くことも可能ですが、POV文を経由することで「誰のどんな問題を解くか」の焦点が明確になります。複数のインサイトを統合して問題定義に結びつける実践的な手順は、インサイト統合の実践ガイドで詳しく解説しています。 --- 参考文献 - 川喜田二郎, 『発想法——創造性開発のために』, 中央公論社, 1967 - Beyer, Hugh & Holtzblatt, Karen, Contextual Design: Defining Customer-Centered Systems, Morgan Kaufmann, 1998 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Kolko, Jon, Exposing the Magic of Design: A Practitioner's Guide to the Methods and Theory of Synthesis, Oxford University Press, 2011 --- ### ウィザード・オブ・オズ法 — 動かない裏側を人間が動かして検証する URL: https://designthinking.studio/methods/wizard-of-oz/ > 「自動で動いているように見せて、裏側は人間が手動で操作する」プロトタイピング手法。AI・自動化・複雑機能の検証を、開発前に実機ユーザーテスト品質で行うための実践ガイド。 「自動で動いているように見せて、裏では人間が動かす」——この一見だましのような手法が、AI機能や複雑な自動化のプロトタイピングで圧倒的に効率的な検証手段になります。Wizard of Oz は、開発に何ヶ月もかかる機能の 「ユーザーが本当に欲しいかどうか」を、開発0分で検証するための実践的方法です。 なぜ Wizard of Oz が必要なのか 問題（Problem） AI機能・自動化・パーソナライズ・チャットボットなど 「動的に応答する複雑機能」 は、ペーパープロトタイピングで検証できません。紙では「ユーザーが入力した内容に応じて画面が変わる」体験を再現できないからです。 しかしフル実装すると数週間〜数ヶ月のエンジニアリング投資が発生します。実装後に「そもそもユーザーは欲しくなかった」と判明するリスクが、AI/自動化プロジェクトで最も恐ろしい失敗パターンです。 親近感（Affinity） 「最低限のAIを実装してテストしよう」と判断すると、データ準備・モデル選定・推論環境整備で簡単に1ヶ月消えます。「もっと簡単に検証できないのか」——この感覚は、プロダクトマネージャーやデザインリサーチャーが繰り返し直面します。 解決策（Solution） Wizard of Oz は 「裏側を人間が即興で動かす」 ことで、AI/自動化の体験を 本物そっくりに再現します。被験者は「自動で動いている」と思って操作しており、実際は別室のオペレーター（ウィザード）が手動で応答を返す——この設計で、真の利用文脈での反応を引き出せます。 実施手順 ステップ1: 検証したいAI/自動化機能のスコープ確定（15分） 「このボタンを押したらAIが◯◯を返す」レベルの粒度まで絞ります。 - 入力（ユーザー操作） - 処理（裏で人間がやること） - 出力（被験者の画面に出す内容） - 応答時間（リアルAIの想定速度に合わせる、3〜5秒など） ステップ2: オペレーター用ツールの準備（30〜60分） - 被験者画面: Figma or HTMLモック（操作可） - オペレーター画面: 別PC、被験者画面を画面共有で見られる - 応答チャネル: Slack/Discord/直接画面操作 - 応答テンプレ: あらかじめ「想定パターン10〜20種」を用意 ステップ3: シナリオ設計（15分） 被験者にやってもらうタスクを設計。 - 起点: 「あなたは◯◯したい状況です」 - ゴール: 「画面に◯◯が出たら成功」 - 制限時間: 10〜15分 ステップ4: テスト実施（30分） - 被験者には 「裏で人間が操作している」ことを最後まで言わない - オペレーターは応答時間を一定に保つ（速すぎるとAIに見えない、遅すぎると不自然） - 発話を促す（思考発話法と組み合わせる） ステップ5: デブリーフィング（10〜15分） テスト終了後、「実は裏で人が動かしていました」と種明かしする。被験者の感想を聞きながら: - 「もし本当のAIだったらどう感じたか」 - 「期待と違った瞬間」 - 「もっと欲しかった応答パターン」 を引き出します。 ファシリテーションのコツ - 応答パターンは20〜30種類を事前に用意: 即興だけで回そうとすると、オペレーターのパターンに被験者が気づいてしまう - オペレーター2名体制が望ましい: 1名が応答、1名がログ記録に専念 - 想定外の入力が来たら「処理中」表示で時間稼ぎ: AIは万能ではないという前提を被験者は持っている - 応答に意図的にエラーを混ぜる: 100%正解だと逆に不自然、AI らしさは「たまに外す」ことで強化される ペーパープロトとの比較 | 軸 | ペーパープロト | Wizard of Oz | |---|---|---| | 適した検証対象 | 静的UI、画面遷移 | 動的応答、AI、自動化 | | 準備時間 | 30分 | 60〜90分 | | 被験者人数 | 1〜3名 | 1名（個別） | | 必要なファシリ人数 | 1名 | 2名（オペ＋テスター） | | 得られる学び | 概念伝達・操作性 | 期待値・応答品質・行動パターン | | 手法の組み合わせ | 早期Discovery | Discovery後半〜Define | ペーパープロトは「概念が伝わるか」、Wizard of Oz は「動的な振る舞いに対して期待値が成立するか」を検証します。両者は段階的に組み合わせるのが定石です。 よくある失敗と対策 失敗1: 被験者にオペレーターの存在がバレる 応答時間が一定でない、応答内容に人間味が出すぎる、操作音が漏れる——いずれも被験者を「これは演技だ」モードにしてしまいます。 対策: オペレーターを別室に配置、画面共有で操作、応答は事前テンプレ中心、応答時間に1〜2秒のランダム性を入れる。 失敗2: 応答パターンが薄く、即興が破綻する 20パターンしか用意していないのに、被験者が予想外の入力を連発するケース。 対策: 「処理中…」「より詳しい情報が必要です」などの 時間稼ぎテンプレ を5〜10種準備しておく。 失敗3: 被験者の発話が引き出せない AIっぽい体験への没入が強すぎて、被験者が黙ってしまう。 対策: 起点で「考えたことを声に出してください」と明示、応答が出るたびに「これは期待通りでしたか?」と短く問う。 関連項目 - ペーパープロトタイピング - Desirability Testing - Assumption Mapping - Wizard of Oz テスト法の実践完全ガイド - Wizard of Oz プロトタイピング ガイド --- ### エクスペリエンス・プロトタイピング — 「体験させる」ことで仮説を壊す URL: https://designthinking.studio/methods/experience-prototyping/ > 実物を作る前に体験そのものをシミュレートして検証する手法。Marion Buchenau と Jane Fulton Suri（IDEO, 2000）が体系化。ユーザー・デザイナー・クライアント全員が「当事者として経験する」プロセスが核心。 「紙のモックアップを見てもらった。うんうんと頷いてもらえた。でも実際に作ったら『思っていたのと違う』と言われた」——この落差は、視覚的な確認と体験的な確認が根本的に別物だという事実から生まれます。エクスペリエンス・プロトタイピングは、プロダクトや空間、サービスの「体験そのもの」を先につくり、検証するための手法です。 手法の由来 Marion Buchenau と Jane Fulton Suri（IDEO）は 2000 年のデザインカンファレンス（ACM DIS）で、IDEO の複数のプロジェクト事例をもとにエクスペリエンス・プロトタイピングを体系化しました。 核心的な定義はシンプルです。 「既存または将来の条件への直接的な関与を通じて、設計チーム・ユーザー・クライアントが現状や将来の条件を一人称で体験できるようにする、あらゆる表現形式のプロトタイプ」 重要なのは「一人称で体験」という点です。通常のプロトタイプは「評価するもの」ですが、エクスペリエンス・プロトタイピングでは設計者自身が体験者になることも含みます。 Buchenau と Suri が挙げた具体例が印象的です。胸部植込み型除細動器（ICD）を装着した患者の不安を理解するために、設計チームはポケットベルを持ち歩き、「いつ鳴るかわからない振動デバイスを常に携帯する」生活を1週間続けました。ICD そのものは存在しませんが、「予測できない電気刺激への恐怖」を身体感覚として知ることができたのです。 なぜペーパープロトだけでは不十分なのか デザイン思考の現場でよく起こるのは、プロトタイプの忠実度（fidelity）が「視覚」に偏るという問題です。 ペーパープロトやFigmaモックで確認できるのは、主に「画面の情報構造」と「遷移の流れ」です。これらは不可欠ですが、以下の要素は再現できません。 - 時間の経験: 操作にかかる時間の感覚、待機の不安 - 空間の感覚: 物理的な動き、姿勢、距離感 - 感情の起伏: 最初の戸惑い、習熟後の快感、エラー時の焦り - 文脈の干渉: 外部刺激（雑音・他者の存在）が体験に与える影響 これらを事前に検証せずに実装に入ると、ユーザビリティテストで「視覚的には問題ないのに使いたくない」という評価が返ってきます。体験として成立していないのです。 3つの活用局面 Buchenau と Suri は、エクスペリエンス・プロトタイピングを以下の3局面で使うことを示しています。 - 理解する（Empathize） ターゲットユーザーの現状体験を、チームが直接経験することで共感を得る。設計者が「外から観察する」のではなく「中から経験する」ための方法です。 実践例: 高齢者向けデバイスを設計するチームが、関節炎を模擬するグローブを着けてプロトタイプを操作する。老眼鏡と光を弱めた環境を加えると、「細かい文字を読みながら操作する」体験の困難さが初めて身体的に理解できます。 - 探索する（Explore） 設計案のいくつかの方向性を、実物に近い体験レベルで比較検討する。 実践例: 病院の受付フローを3パターン設計し、スタッフとモック患者が実際に歩き回りながら各パターンを演じる。平面図を見るだけでは気づかない「この動線では患者が立ち往生する」という問題が、歩くことで見えてきます。 - 伝達する（Communicate） クライアントやステークホルダーに体験を「わかった気にさせる」のではなく、実際に「体験させる」ことで同じ文脈を共有する。 実践例: 新しいスマートホームシステムを提案する際、クライアントに役者スタッフとのロールプレイを実施してもらう。パワーポイントのデモを見るより、「自分で実際に操作してみる」ことでフィードバックの質が大きく変わります。 実施ステップ ステップ1: 体験させたい「瞬間」を特定する（20〜30分） エクスペリエンス・プロトタイピングは全体の体験を再現しようとするとリソースが膨らみすぎます。「何を検証したいのか」を絞り込みます。 - 最もリスクの高い仮説はどれか - 言語化できていない体験の要素はどこか - ユーザーインタビューでは引き出せていない情報は何か この3つの問いへの答えが「体験させる瞬間」を特定する手がかりになります。 ステップ2: 体験を近似する道具・環境を準備する（60〜90分） 完全な再現は不要です。「体験を近似させる代替物」を用意します。 | 検証したい体験 | 代替手段の例 | |---|---| | アプリの入力の煩雑さ | 同等のフォームを印刷して手書き入力させる | | 物理製品の持ちやすさ | 同じ重量・形状の段ボールモック | | 空間サービスの流れ | 実際のスペースに家具を配置してロールプレイ | | 音・振動・温度 | スマートフォン・ドライヤー・保冷剤など日用品で代替 | | 医療・ケア文脈 | 模擬的な身体制約（グローブ・眼鏡・耳栓）を加える | ステップ3: シナリオを設計する（15〜20分） 体験者（チームメンバーまたはユーザー）に渡す「文脈の説明」を作ります。 - あなたは今、◯◯な状況にいます - ◯◯をしようとしています - ◯◯が起きています（制約・外部刺激の説明） シナリオは詳しすぎないほうがよく、「答えを教えない」ことが重要です。 ステップ4: 体験してもらい、観察・記録する（20〜40分） 体験中のファシリテーターは基本的に介入しません。記録に徹します。 - 何をしようとして、どこで止まったか - 言葉にならない行動（直感的な操作・避けた動作） - 感情の変化（顔の表情・姿勢・発話内容） - 「なんか違う」という違和感が出た瞬間 ステップ5: 振り返りと学びの言語化（20〜30分） 体験直後に感想と気づきを話してもらいます。時間が経つと印象は薄れます。 問いかけの例: - 「一番困ったのはどの瞬間ですか?」 - 「自分でやってみて想像と違った点は?」 - 「この体験、現実の生活で毎日続けられますか?」 ファシリテーションのコツ 「完璧な再現」を目指さない: 代替物が粗くても、体験を通じて出てくる驚きや抵抗感は本物です。むしろ「こんな粗いので大丈夫か?」という不安を手放すことが重要で、実際にやってみると粗くても体験の核心は十分に伝わります。 チームメンバーが最初の体験者になる: ユーザーに頼む前に、チーム内で先に体験してみてください。設計者が体験することで「自分が設計したとは思えない不便さ」に気づくことがよくあります。 体験後のデブリーフィングを省略しない: 体験中の沈黙や戸惑いは観察できますが、その理由は体験後の対話でしか出てきません。「なぜそこで止まったのか」を必ず聞きます。 複数シナリオを比較する: 1つの体験だけで判断しないでください。「現在の体験（As-Is）」と「新しい設計案（To-Be）」を両方体験させると、差異が鮮明になります。 よくある失敗と対策 失敗1: 「見せる」だけで「させる」になっていない デモを見せて「どう思いますか?」と聞くのは通常のユーザーテストです。エクスペリエンス・プロトタイピングでは体験者が能動的に操作・行動・決断する機会を作ることが前提です。 対策: シナリオに「あなたが決める」「あなたが動く」の要素を入れる。観客にしない。 失敗2: チームが体験者に答えを教えてしまう 「ここをこう使うんですよ」と説明したくなる気持ちは自然ですが、それをやると「どこで迷うか」という最重要情報が取れなくなります。 対策: 「わからなかったら、わからないまま進んでください」と事前に伝える。迷いが学びです。 失敗3: 体験と「評価」が混ざってしまう 体験中に「これどう思いますか?」と聞き続けると、体験者の意識が「評価モード」に切り替わり、自然な行動が引き出せなくなります。 対策: 評価・感想は体験後のデブリーフィングに集約。体験中はできる限り沈黙を守る。 ペーパープロト・Wizard of Oz との使い分け | 手法 | 検証の焦点 | 準備コスト | 必要な道具 | |---|---|---|---| | ペーパープロト | 情報構造・画面遷移・言語理解 | 低（30〜60分） | 紙・ペン | | エクスペリエンス・プロト | 体験の感情・時間・空間・文脈 | 中（90〜120分） | 日用品・環境設定 | | Wizard of Oz | 動的な応答・AI的振る舞いへの期待 | 中高（60〜90分） | PC2台・通信環境 | 3手法は排他ではなく、「視覚 → 体験 → 動的応答」の順で段階的に精度を上げていく使い方が実務的に効果的です。 関連項目 - ペーパープロトタイピング完全ガイド - ウィザード・オブ・オズ法 - ボディストーミング - サービスサファリ - ストーリーボード --- ### エンパシーマッピング完全ガイド—感情モデリングからアクション抽出まで URL: https://designthinking.studio/methods/empathy-mapping-step-by-step-guide/ > ユーザーの感情・思考・行動を多層的にモデル化し、洞察を問題定義へ橋渡しするエンパシーマッピングの全ステップ。ファシリテーションの落とし穴と実装用テンプレートを含む実践完全ガイド。 エンパシーマッピングは、ユーザーの行動・言葉・思考・感情を構造化して記録し、そこから問題定義へとつながる洞察（インサイト）を引き出すフレームワークです。入門版の共感マップが「ツールとは何か」を教えるなら、このガイドは「ワークショップで何が起きるか」と「感情データをどう問題定義へ変換するか」を扱います。 なぜエンパシーマッピングが必要か 問題（Problem） ユーザーリサーチを丁寧に行ったはずなのに、チームが出した解決策が的外れだった——この経験は、デザイン思考を実践する多くのプロジェクトで繰り返されます。200回以上のワークショップで繰り返し観察されてきたのは、インタビュー記録が詰まったスプレッドシートがチームの共通理解の道具になっていないというパターンです。データが多いほど、「それぞれが自分の解釈でアイデアを出す」危険性が高まります。 親近感（Affinity） ワークショップでよく起こるのは、ファシリテーターが「さあインタビューの内容を共有してください」と言った瞬間に、参加者が「うちのユーザーが言っていたのは〜」という発言から始まり、気がつくと各自の思い込みを発表する場になっているパターンです。ユーザーの声のはずが、チームメンバーの解釈の声になっている。エンパシーマップは、この「解釈の混入」を構造的に防ぐための壁です。 解決策（Solution） エンパシーマッピングは、ユーザーの体験を4つの象限（Say/Think/Do/Feel）に分類してから、矛盾・驚き・感情の谷に注目してインサイトを引き出します。これにより、「チームが持ち込んだ解釈」ではなく「ユーザーのデータから生まれた洞察」を問題定義の出発点にできます。 --- エンパシーマッピングの全体像 入門版との差分 既存の共感マップ記事では、4象限の定義と基本的な手順を扱っています。このガイドが扱うのは、その先です。 | 観点 | 入門版（共感マップ） | このガイド（完全版） | |------|-------------------|-------------------| | 対象 | 初めて使うチーム | リサーチデータがある状態で始めるチーム | | 焦点 | 象限の使い方の理解 | 感情データからインサイトへの変換 | | 時間 | 30〜60分 | 90〜150分 | | アウトプット | 埋まったマップ | インサイト文3〜5本 | Stanford d.school / IDEO の理論的位置づけ Stanford d.school の Bootcamp Bootleg（2018年改訂版）では、エンパシーフェーズのゴールを「インタビューや観察を通じてユーザーの体験に深く入り込み、ユーザーを突き動かしている感情や動機を理解すること」と定義しています。エンパシーマップはこのゴールに向けて、チームが持ち帰ったリサーチデータを共同で整理し、解釈を議論するためのキャンバスとして機能します。 IDEO の Human-Centered Design の実践でも、エンパシーマップは「データの民主化」ツールとして使われます。調査に参加していないステークホルダーを含め、チーム全員がユーザー体験に対して同じ解像度の理解を持てるようにすることが、その主要な役割です。 --- 準備 リサーチデータを整理しておく エンパシーマッピングは、最低3名のユーザーへのインタビューまたは観察調査を完了してから実施します。データなしで始めると、ユーザーではなくチームの思い込みのマップが完成します。 - インタビュー録音の文字起こし（または詳細なメモ） - 観察中に撮影した写真・スケッチ - インタビューガイドと実際の発言の対応記録 - 観察メモ（行動・発言・表情の記録） 空間設計 模造紙を壁に貼り、4象限（Say / Think / Do / Feel）を大きく区切ります。各象限には最低でもA4サイズ相当のスペースが必要です。付箋は3色準備します。「ユーザーの発言・行動（事実）」「チームの推察」「気になる矛盾点」の3種を色で区別することで、後の分析が格段に楽になります。 --- ステップ別実施ガイド Step 1：ユーザー像の設定（15分） マップの中央に配置するユーザー像を設定します。ここを曖昧にすると、マップ全体が誰のデータなのかわからなくなります。 実際にやってみると、複数のインタビュー対象者の発言を1枚のマップに混ぜてしまうケースが多発します。この失敗を防ぐために、1枚のマップ = 1人のユーザー（または明確に定義した1つのペルソナ）を徹底します。 ユーザー像の記述例として、「42歳・IT企業部長・毎朝7時の通勤電車でメールを処理している田中さん」のように、属性だけでなく状況と文脈を含めます。属性だけのユーザー像は、後の象限記入で「この人だったら何をしているか」を想像するときの手がかりが弱くなります。 Step 2：Say の象限を埋める（20分） 「ユーザーが実際に口にした言葉」をそのまま付箋に書いて貼ります。 厳守ルール：ユーザーの言葉を加工しない。「〜と言っていた」ではなく、できる限り「〜」という一人称の直接引用で書きます。「操作が難しかった」ではなく「どこを押せばいいのか本当にわからなかった、3回試した」のように記録します。 ワークショップでよく起こるのは、発言の「意訳」が混入することです。ファシリテーターは「それはユーザーが言ったことですか、それともあなたの解釈ですか？」という問いを繰り返す必要があります。もし推察であれば、別の色の付箋に書いてThinkの象限に移します。 Step 3：Do の象限を埋める（20分） 「ユーザーが実際にとった行動」を記録します。観察が重要です。インタビューの発言だけではなく、観察中にユーザーが実際に何をしたかを中心に記入します。 ここで特に重要なのは、「言っていること（Say）」と「していること（Do）」の矛盾を積極的に探すことです。「使いやすいと思っています」と言いながら、実際には毎回同じ箇所でマウスが止まっていた——このギャップが、最も深いインサイトの源泉になることが多いです。 矛盾を発見したら、目立つ色のマーカーで矢印を引いて「Say との矛盾」と記します。この矛盾リストが、Step 6 のインサイト抽出で最重要の材料になります。 Step 4：Think の象限を埋める（20分） 「ユーザーが口にはしないが、おそらく考えていること」を推察で記入します。この象限だけは推察で構いません。ただし推察であることを明記した付箋の色で区別します。 Think の象限が空欄のまま進んでしまうパターンは、ほぼすべてのワークショップで観察されます。チームが「勝手に決めていいのか」と迷って手が止まるのです。ファシリテーターは「推察でいい。ただし後でリサーチで確認する仮説として扱う」と明言します。 Think の問いを引き出す問いかけ例： - 「このユーザーは何を心配していたと思いますか？」 - 「実際には何を求めていたと思いますか？」 - 「口に出せなかったことは何だったと思いますか？」 実際にやってみると、Think の空欄を埋める議論の中で「私たちはそもそもこのユーザーの動機を理解できていないのでは？」という問いが自然と生まれます。この「気づき」自体が、次のリサーチで確認すべき仮説の候補になります。 Step 5：Feel の象限を埋める（20分） 「ユーザーが体験の各場面で感じていた感情」を記録します。感情は観察から読み取ったものと、インタビュー中の発言から拾えるものがあります。 感情の語彙を豊かにするために、感情チェックリストを壁に貼っておくことを強く推薦します。 「良い/悪い」「困った/嬉しかった」程度の語彙では粗すぎます。「焦り」「諦め」「期待外れ」「驚き」「安心」「恥ずかしさ」「自信喪失」のような具体的な感情語彙で記述することで、後の分析の解像度が上がります。 感情の記録が終わったら、感情曲線を引きます。時系列（ユーザー体験の流れ）に沿って感情を高い/低いでプロットし、折れ線で結びます。急激に下がるポイントが問題の集中箇所、急激に上がるポイントがユーザーが価値を感じている瞬間の候補です。 --- インサイト抽出：感情データから問題定義への橋渡し ここからが、入門版との最大の差分です。埋まったマップから「だから何か」を引き出すプロセスです。 インサイト抽出の3つのレンズ レンズ1：矛盾に注目する Say と Do の矛盾、Think と Feel の矛盾、ユーザーが期待していたことと実際の体験のギャップ——これらの矛盾点を全てリストアップします。矛盾は「このユーザーの本当のニーズはまだわかっていない」というシグナルです。 ある医療機器メーカーのワークショップでは、患者が「この操作は難しくない」と言いながら実際には5分以上かけていたことが明らかになりました。矛盾を深掘りすると、「難しい」と認めることへの心理的抵抗が背景にあることが判明し、「設計が難しいのではなく、使用環境が問題だ」という問題定義の転換につながりました。 レンズ2：感情の谷に注目する 感情曲線が急激に下がるポイントを特定します。次に「その時点でユーザーは何をしていて、何を考えていたか」をSay/Think/Doの象限で照合します。感情の谷 × 行動の詰まり × 思考の不安が重なる箇所が、最も重要な問題候補です。 レンズ3：繰り返しパターンに注目する 複数のユーザーに共通する発言・行動・感情を探します。1人だけに見られる特異なパターンは個人差の可能性がありますが、3人中3人に共通するパターンは構造的な問題のシグナルです。 インサイト文の書き方 矛盾・感情の谷・繰り返しパターンから「インサイト文」を書きます。インサイト文の形式： 「[ユーザー] は [状況] のとき、[期待] を持っているにもかかわらず、実際には [現実] という体験をしていた。これは [根本的な理由] からきていると考えられる。」 例：「IT部門の担当者は新しいシステムの操作方法を学ぶとき、完璧に理解してから使いたいという期待を持っているにもかかわらず、実際にはエラーが怖くて試すことができていない。これは、失敗が記録・報告される組織文化への不安からきていると考えられる」 このインサイト文が、POVステートメントの「なぜなら〜だからだ」という部分の核心になります。 --- ファシリテーションのコツ 「データを話す」と「解釈を話す」を分離する ワークショップの最大の課題は、チームメンバーが自分の解釈をユーザーの声として語り始めることです。ファシリテーターは「それはユーザーが言ったことですか？」「それとも、あなたがそう感じたということですか？」という問いを、遠慮なく繰り返します。 ある参加者からの声として多いのが「最初は厳しく区別されると窮屈に感じたが、終わってみると事実と推察の区別が明確だったおかげで議論がスムーズだった」というものです。 沈黙を埋めない 付箋を書く時間は沈黙が続きます。ファシリテーターは「何か発見はありましたか？」などと沈黙を埋めようとしないこと。 「あと2分あります」「今○○の象限を埋めている方が多いですね」という状況報告だけで十分です。 Think の象限を最後に埋めさせる ワークショップの順序として、Say → Do → Feel → Think の順に埋めることを推薦します。事実（Say/Do）と感情（Feel）を先に埋めてから、推察（Think）に進むことで、事実を根拠とした推察が生まれやすくなります。 時間配分を事前に宣言する 各象限に充てる時間を開始前に参加者全員に伝えます。「各象限20分、インサイト抽出30分、全体でプレゼン共有15分」という構造が見えると、参加者が「今どこにいるか」を把握できてセッションへの没入度が上がります。 --- よくある失敗と対策 失敗1：1枚のマップに複数のユーザーのデータを混ぜる 「インタビューした3人の声を全部入れよう」という意図は理解できますが、混在すると誰のマップかが不明瞭になり、インサイト抽出ができなくなります。 3名分のインタビューデータがあれば、3枚のマップを作成するか、明確なペルソナを設定してその視点で整理します。 対策：「このマップは田中さんのマップです」という名札を中央に貼り、全員が常に意識できるようにします。 失敗2：感情語彙が貧困なままにする 「不満」「良かった」だけの感情語彙では、感情の谷の深さや種類が分析できません。感情の精度が粗いと、インサイトも粗くなります。 対策：ワークショップ前に「感情ホイール（Emotion Wheel）」をA3で印刷して配布します。Robert Plutchik の感情の輪は、基本8感情から派生する多様な感情語彙を視覚的に参照できるツールとして有効です。 失敗3：マップが完成したことをゴールにする 「マップが埋まった、お疲れ様」で終わるワークショップは、インサイト抽出に至っていません。エンパシーマップは問題定義への橋渡しであり、完成したマップは手段です。 対策：セッション設計の段階で「インサイト文3本を書く」というアウトプット目標を設定し、マップ記入の時間の後に必ずインサイト抽出のセクションを設けます。 失敗4：リサーチなしで「想像マップ」を作る リサーチデータがない段階でエンパシーマップを作ることは、チームの思い込みを可視化するだけで終わります。「ユーザーはこう感じているはずだ」という仮説マップと、実際のリサーチデータに基づくマップは別物です。 対策：リサーチ前に仮説マップを作ることを「仮説マップ」として明示し、リサーチ後に実データで上書きする比較プロセスを組み込みます。仮説と現実のギャップ自体が重要な発見になります。 --- 実装用テンプレート エンパシーマップ基本フォーマット インサイト抽出ワークシート | 観点 | 発見 | インサイト候補 | |------|------|-------------| | Say↔Do矛盾 | | | | 感情の谷 | | | | 繰り返しパターン | | | --- エンパシーマップの後に何をするか エンパシーマッピングで抽出したインサイトは、次の3つのステップへ直接つながります。 - POVステートメントの作成 インサイト文を「[ユーザー] は [ニーズ] を必要としている。なぜなら [インサイト] だからだ」というPOV形式に変換します。 - カスタマージャーニーマップとの統合 エンパシーマップで見えた感情の谷と行動パターンを、時系列に並べたジャーニーマップで立体的に可視化します。両者を組み合わせると、「どの場面でその感情が生まれるか」という文脈がより明確になります。 - 追加リサーチの設計 Think の象限に書いた「推察」は、次のリサーチで検証すべき仮説のリストです。「このユーザーは〜と思っているはずだ」という推察を、インタビューや観察の新しいラウンドで確認します。 --- ポイント - 1マップ1ユーザー — 複数のユーザーデータを混ぜない。ペルソナを設定する場合も文脈を含めた具体的な定義をする - 事実と推察を色で分ける — ThinkとFeel の推察部分は別色付箋で区別し、「検証が必要な仮説」として扱う - 矛盾を探す — Say↔Do の矛盾こそが最も深いインサイトの源泉 - インサイト文まで書く — マップが埋まることではなく、インサイト文3本を書くことをゴールに設定する - 感情語彙を豊かにする — 感情ホイール等のツールを使い、「良い/悪い」に留まらない精度で記録する - 感情曲線を引く — 感情の谷と山を可視化することで、問題の優先順位と価値提供のポイントが見えてくる --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018年改訂版 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Dave Gray, Sunni Brown & James Macanufo, Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, O'Reilly, 2010 - Robert Plutchik, "A Psychoevolutionary Theory of Emotions", Social Science Information, 21(4-5), 1982 - Nielsen Norman Group, "Empathy Mapping: The First Step in Design Thinking", nngroup.com, 2017 --- ### エンパシーマップ テンプレート集 — すぐ使える5パターン URL: https://designthinking.studio/methods/empathy-map-template-collection/ > エンパシーマップのテンプレート5種類を目的別に整理して解説。基本4象限から拡張版・チーム用・BtoB用・デジタル用まで、プロジェクトの文脈に合わせて選べるテンプレートガイド。 「エンパシーマップを使いたいが、どのテンプレートを選べばよいか分からない」という声は、実際のワークショップ現場でよく聞かれる。 エンパシーマップは、4象限という単純な構造を持つ一方で、プロジェクトの目的・チームの人数・対象ユーザーの特性によって、最適なテンプレートが変わる。 基本の4象限をそのまま使って「物足りなかった」「複雑すぎて使いこなせなかった」というケースは多い。 本記事では、目的別に使い分けられる5つのテンプレートパターンを、各パターンの活用シーンと記入のコツとともに解説する。 --- エンパシーマップとは何か（簡潔に） エンパシーマップはDave Grayが開発したユーザー理解のフレームワークだ。ユーザーの体験を「言っていること・考えていること・していること・感じていること」の4つの視点で整理することで、チーム全体がユーザーへの理解を共有できる地図として機能する。 詳しい活用法と理論的背景は共感マップ（Empathy Map）を参照してほしい。 本記事では「すぐ使える」をコンセプトに、5つのテンプレートパターンを実践的に紹介する。 --- テンプレート1：基本4象限（最初の一枚） 概要 もっとも広く使われているスタンダードなテンプレート。エンパシーマップを初めて使う時、または時間が限られている時に最適だ。 象限構成 中央にペルソナ名・写真・概要を配置する。 記入のコツ SAY欄には「ユーザーが実際に使った言葉」を必ずそのまま記入する。 要約・解釈は後でいい。まず生の発言を象限に貼ることで、チーム内の解釈のズレを防げる。 THINK欄は推察になるため、「〜しているのでは？」という問い形式で記入すると、仮説であることが視覚的に明確になる。DO欄は、言葉ではなく「観察した行動」のみを記入するのがルールだ。感情的な評価は加えない。 活用シーン - インタビュー直後の整理（1時間以内に記入する） - チームがエンパシーマップを初めて使う時 - プロジェクト初期の「ユーザー理解のスタート地点」を作る時 所要時間 一人のユーザーに対して20〜30分。インタビュー後すぐに行うと記憶が新鮮なうちに記入できる。 --- テンプレート2：拡張6象限（深い探索向け） 概要 基本4象限に「Pain（痛み・障壁）」と「Gain（得たいもの・期待）」の2象限を追加したパターン。Dave Grayの改訂版（2017年更新）に基づく構成だ。 象限構成 活用シーン - ユーザーインタビューを複数回実施した後の深い分析 - 「表面的な理解」から「深層的な動機」まで掘り下げたい時 - 仮説からの検証セッション（「このユーザーのPainは何か」を問いにする時） 記入のコツ SEE欄は「ユーザーが日常的に見ている世界」を描く。競合他社の広告、同僚の行動、SNSのフィード。ユーザーが「当たり前」だと思っているものが、インサイトの宝庫になることが多い。 HEAR欄には「ユーザーが影響を受けている声」を記入する。上司の指示、友人のアドバイス、メディアの情報。意思決定に影響を与えている情報源を特定することで、コミュニケーション設計に直結する知見が得られる。 所要時間 一人のユーザーに対して45〜60分。複数回のインタビューデータを統合する際に使う。 --- テンプレート3：チーム統合版（複数ユーザー対応） 概要 複数人のインタビューデータを一枚のマップに統合するためのテンプレート。5〜10人のユーザーデータを比較・統合する際に使う。 構成の特徴 基本4象限を使いながら、「ユーザーAの発言」「ユーザーBの発言」を色分けした付箋で象限に貼り分ける。最終的に「多くのユーザーに共通すること（中央付近に移動）」と「ユーザー固有のこと（外側）」を視覚的に分離する。 準備するもの - 色分けした付箋（ユーザーごとに色を変える。5色あれば十分） - 各インタビューで記録した発言・行動のメモ - A0用紙またはホワイトボード（複数人分のデータが入るサイズが必要） 記入のコツ 貼り付け後の「クラスタリング」が最重要プロセスだ。 似た付箋を近くに寄せていくと、「複数のユーザーが共通して感じていること」が浮かび上がる。このクラスターがインサイトの候補になる。 一人でやると見落としが多いため、最低2人のチームで作業することを推奨する。「これとこれは似ている」という判断を複数人が行うことで、インサイトの質が上がる。 活用シーン - ユーザーリサーチの統合フェーズ - 複数の顧客セグメントの比較分析 - インサイトの抽出と定義フェーズへの橋渡し 所要時間 5人分のデータで60〜90分。事前に個別ユーザーの基本4象限を完成させておくと、統合作業がスムーズになる。 --- テンプレート4：BtoB用（意思決定者・利用者分離型） 概要 BtoBサービスの設計・改善に特化したテンプレート。「サービスの意思決定者（例：購買担当）」と「サービスの実際の利用者（例：現場スタッフ）」が異なる場合に有効だ。 構成の特徴 A4用紙2枚を並べる形で、左側に「意思決定者マップ」右側に「利用者マップ」を作る。各マップは基本4象限を使いながら、以下の追加項目を設ける。 - 意思決定者マップ追加項目： 「評価指標（KPI）」「承認のための根拠として重視すること」 - 利用者マップ追加項目： 「実際の業務フローにおける利用場面」「周囲の同僚との関係性」 活用シーン - BtoB SaaSの製品設計・提案設計 - 企業向けの研修・コンサルティングサービスの価値設計 - 購買プロセスと利用プロセスの両方を改善したい時 実際にやってみると、意思決定者と利用者のPainがまったく別の問題であることが多い。 「意思決定者はコスト削減を重視している」「利用者は学習コストの低さを重視している」という乖離が可視化されると、提案・製品の設計方針が大きく変わることがある。 所要時間 意思決定者1名・利用者1名に対して計60分。2枚並べて完成後、乖離点のリストアップに追加15分を使う。 --- テンプレート5：デジタル体験用（タッチポイント連動型） 概要 Webサービス・アプリ・デジタルプロダクトの設計改善に特化したテンプレート。ユーザーが特定のタッチポイント（ランディングページ・オンボーディング・特定の機能画面など）を体験する瞬間の感情・思考を詳細に記録する。 構成の特徴 基本4象限に加え、上部に「タッチポイントの特定」を配置する。 活用シーン - UXリサーチで特定の画面・フローを評価する時 - ユーザーテスト後のデブリーフィングセッション - A/Bテストの仮説設計前の「ユーザー心理の可視化」 記入のコツ タッチポイントは「できるだけ具体的な場面」に絞る。 「初回利用時」という広いスコープではなく、「初回利用時のオンボーディング画面で最初のタスクを完了する瞬間」まで絞ることで、記入内容が具体的になる。 DO欄には、実際のユーザーテストで観察された操作の詳細を記録する。「入力に迷った」「何度もヘルプを開いた」「バックボタンを押した」など、画面上の行動を具体的に。 所要時間 一つのタッチポイントに対して30〜45分。ユーザーテスト終了後すぐに記入することを強く推奨する。 --- 5パターンの選び方：早見表 | 状況 | 推奨パターン | |---|---| | 初めてエンパシーマップを使う | テンプレート1（基本4象限） | | インタビューを5回以上実施済み | テンプレート2（拡張6象限）またはテンプレート3（チーム統合版） | | 複数ユーザーのデータを比較したい | テンプレート3（チーム統合版） | | BtoBサービスの設計をしている | テンプレート4（BtoB用） | | アプリ・Webサービスを改善したい | テンプレート5（デジタル体験用） | | 時間が30分以内しかない | テンプレート1（基本4象限）の一部のみ | --- 共通する失敗パターン3つ どのテンプレートを使う場合でも、ワークショップでよく起こる失敗パターンがある。 失敗1：解釈を先に書いてしまう。 SAY欄に「ユーザーは使いやすさを求めている」と書くのは解釈であり、発言ではない。「難しくてよく分からなかった」というユーザーの言葉そのものを書くことが正しい。解釈は後の分析フェーズで行う。 失敗2：全象限を均等に埋めようとする。 特定の象限が空白であることは問題ではない。インタビューで観察できなかった部分を無理やり埋めることの方が、後の分析を歪める原因になる。空白は「まだ分かっていないこと」の正直な表現だ。 失敗3：一人で完成させようとする。 エンパシーマップは、チームで記入し議論するプロセスに意味がある。個人作業で完成させたマップは、チームの共通理解を生まない。 --- テンプレートを使い終えた後：インサイトへの接続 エンパシーマップはゴールではなく、インサイト抽出への橋渡しだ。マップが完成したら、「このユーザーについて、私たちがまだ理解していないことは何か」という問いを立てる。 その問いが、次のインタビューの設計に活かされ、最終的にHow Might Weの策定につながる。エンパシーマップの価値は、記入した瞬間ではなく、チームがそのマップを見ながら議論した時間の密度で決まる。 エンパシーマップを使った後の手順の詳細についてはエンパシーマッピング ステップバイステップガイドを参照してほしい。組織変革の文脈でのエンパシーマップ活用についてはエンパシーマップを組織変革に活かす実践論にも詳しい解説がある。 --- ### カスタマージャーニーマップ URL: https://designthinking.studio/methods/journey-mapping/ > ユーザーが目標達成に至るまでの行動・感情・思考を時系列で可視化するツール。断片的なリサーチデータを一枚のストーリーに統合し、チーム全体の共感と問題発見を促す。 カスタマージャーニーマップ（CJM）は、ユーザーが特定の目標を達成しようとするプロセスを、行動・感情・思考の三層で時系列に描き出す可視化ツールです。「ジャーニー」という言葉が示す通り、ユーザーを旅人として捉え、その旅の全景をチームが共有できる一枚の地図に変換します。 概要 ユーザーインタビューや観察調査で集めた定性データは、そのままでは断片的です。「Aさんはここで戸惑った」「Bさんはここで諦めた」という個別の観察を、時間軸に沿って並べることで、問題が集中するポイントと感情の谷間が浮かび上がります。 カスタマージャーニーマップが特に力を発揮するのは、複数のチャネルや部署をまたぐ体験の設計です。営業・カスタマーサポート・物流が別々に動いている場合、各部署は自部門のタッチポイントしか把握していません。ジャーニーマップを一枚のシートに広げると、どこでバトンが途切れているかが一目でわかります。 Nielsen Norman Group の調査によれば、ジャーニーマップが最も効果を発揮するのは「部門間の対話を生む」場面です。地図そのものよりも、地図を描く過程でチームが得る共通認識こそが、このツールの本質的な価値です。 デザイン思考の共感フェーズで作成し、問題定義フェーズでの POVステートメント や How Might We へと橋渡しします。 実施の手順 ステップ1：スコープとペルソナを決める ジャーニーマップを描く前に、「誰の」「どんな目標に向けた」旅を描くかを明確にします。 スコープが曖昧なまま作り始めると、あらゆる体験を詰め込みすぎて何も見えない地図になります。 ペルソナは事前のリサーチデータに基づいて作成します。「30代、育児中のフルタイム就労者」のような属性だけでなく、「子どもの体調不良時に自分の仕事との折り合いをどうつけるか悩んでいる」という具体的な文脈を持つ人物として定義します。エンパシーマップを先に作成しておくと、ペルソナの解像度が上がります。 描くジャーニーの範囲は「どこから始まり、どこで終わるか」を決めます。「サービスを知る」から「日常的に使っている」までを1枚に収めようとすると煩雑になります。最初は 「初回申込みから初めての成果体験まで」のように、問題意識に直結した範囲に絞ることをお勧めします。 ステップ2：ジャーニーのフェーズを定義する 横軸には時間の流れを表す「フェーズ」を置きます。フェーズはユーザーの行動の「まとまり」として定義します。たとえばオンラインサービスの申込みであれば、「認知 → 比較検討 → 申込み → オンボーディング → 定着」のような区切りが典型的です。 ワークショップでよく起こるのは、フェーズの粒度についての議論です。「申込み」を1フェーズで済ませるか「フォーム入力」「確認メール」「本人確認」に分けるかは、チームが最も見たい部分を拡大することで決めます。 問題が集中していると予想される領域を細かく分割し、他は粗く設定する非対称なフェーズ設計も有効です。 あるBtoB製造業のプロジェクトでは、「発注フェーズ」を1枚にまとめていたところ、問題がぼやけて見えていました。「見積依頼」「社内承認」「発注書作成」「納期確認」に分割した途端、「社内承認フェーズ」で感情が急落するパターンが3名のインタビュー全員に共通していることが浮かび上がりました。 ステップ3：行動・思考・感情を記入する フェーズが決まったら、3つの層（行動・思考・感情）を縦軸に配置し、それぞれのセルに付箋を貼っていきます。 行動（Actions）は、ユーザーが実際に何をするかです。「ウェブサイトで比較する」「電話で問い合わせる」「書類に記入する」のように動詞で書きます。 思考（Thoughts）は、そのときユーザーが頭の中で考えていることです。「本当にこれで合ってるのかな」「他にもっといい選択肢があるかも」といった疑問や懸念を書きます。リサーチ中に記録した発言の引用がそのまま使えます。 感情（Emotions）は、感情曲線として描きます。各フェーズのユーザーの感情を「高い（ポジティブ）」から「低い（ネガティブ）」のスケールでプロットし、折れ線グラフのように結びます。感情曲線が急激に下がるポイント（感情の谷）が、最も重要な問題箇所の候補です。 やってみると、行動と感情が逆転するケースが多く現れます。「ここは操作が簡単なのに、なぜユーザーが不安を感じているのか」という矛盾が見えたとき、隠れたニーズやインサイトが潜んでいるサインです。初めてジャーニーマップを作るチームがよく驚くのは、「機能的には問題ない」フェーズでも感情が下がり続けるケースです。「わかっている」と思っていた問題の裏に、別の問題がある——この発見がチームの議論を深めます。 ステップ4：タッチポイントとチャネルを記入する 行動・思考・感情が埋まったら、各フェーズでユーザーがどのチャネルやタッチポイントを通じてサービスや組織と接触するかを記入します。「ウェブサイト」「メール」「店頭スタッフ」「SNS広告」などです。 このレイヤーを加えることで、「感情の谷がどのチャネルで起きているか」が明確になります。 「電話問い合わせのフェーズで毎回感情が下がる」という発見は、コールセンターの対応改善というアクションに直結します。 ステップ5：ペインポイントとオポチュニティを抽出する ジャーニーマップが完成したら、チーム全体で地図を眺め、最も重要なペインポイント（痛点）を3〜5つに絞ります。 全員が「確かにここは問題だ」と頷ける箇所を優先します。 ペインポイントの右隣に、「もしここを改善できたら？」という視点でオポチュニティを書きます。このオポチュニティが、How Might We の問いを立てる出発点になります。「ここをどう改善できるか」ではなく「もしここが良くなったら、ユーザーにどんな価値が生まれるか」という視点で書くと、後のアイデア発想が広がります。 親和図法でペインポイントをグルーピングすると、優先順位の議論がスムーズになります。 ファシリテーションのコツ リサーチデータを手元に置く ジャーニーマップは「推測で書く」ものではありません。インタビュー録音の書き起こし、観察メモ、写真などのリサーチデータを手元に置いた状態でセッションを始めます。「このユーザーはどう感じていたか」という問いに対して、必ずエビデンスで答えることをルールにします。 思い込みや推測で埋めた箇所は目立つ色の付箋で区別しておく。後の議論で混乱を防ぐためです。 沈黙に耐える ジャーニーマップのワークショップでは、参加者が付箋を書いている時間が長くなります。ファシリテーターは沈黙を埋めようとしなくてよいです。「まだ2分あります」と時間を声かけするだけで、参加者が自分のペースで考えられます。 感情曲線は最後に描く 行動・思考・チャネルが揃ってから感情曲線を引くと、議論が豊かになります。先に感情を決めてしまうと「だからこのフェーズは悪い」という結論ありきで他のセルが埋まるリスクがあります。事実を積み上げてから感情を読み取る——この順序がインサイトの質を決めます。 全員が手を動かす設計にする 「わかった人が書く」ワークショップになると、ジャーニーマップはその人の解釈になってしまいます。付箋を人数分用意し、同じフェーズに複数の人が別々の付箋を貼ることを奨励します。複数の視点が重なる箇所は重要度が高く、矛盾する箇所は深掘りすべき問いを含んでいます。 ユーザビリティテストの観察と組み合わせると、行動の記録がより具体的になります。 よくある失敗と対策 「理想のジャーニー」を描いてしまう 最もよくある失敗は、現状のユーザー体験ではなく「こうあるべき体験」を描いてしまうことです。ジャーニーマップは「現状（As-Is）」を描くものです。 As-Isマップで問題を発見してから、「将来（To-Be）」マップでビジョンを描く2段階のアプローチが正確です。最初から理想を描くと、問題が見えないまま施策検討に進んでしまいます。 タッチポイントの羅列になってしまう 「ウェブ → メール → アプリ → 店舗 → コールセンター」とチャネルを時系列に並べるだけでは、プロセスフロー図であってジャーニーマップではありません。ユーザーの感情と思考が欠けている地図は、問題を発見するのではなく確認するだけで終わります。 感情曲線の記入を必須とすることで、表面的な記録に留まらない深さが生まれます。 マップを作ることが目的になってしまう 参加者からの声として多いのが「マップが完成した時点でエネルギーが尽きた」というものです。ジャーニーマップは成果物ではなく、問いを立てるための道具です。 セッションの最後15分は必ず「このマップから何をするか」に充て、ペインポイントの優先順位づけとネクストアクションを決めます。デザイン思考の失敗パターンでも、成果物完成をゴールにする「ツール化」は典型的な落とし穴として挙げられています。 データ不足のまま始める ユーザーリサーチがまだ十分でない段階でジャーニーマップを描くと、チームの思い込みを可視化するだけになります。最低でも3〜5名のユーザーインタビューを完了してから着手します。 データが不足している場合は、「仮説マップ」として明示し、後でリサーチデータで検証するプロセスを設計しておきます。 ポイント - 現状（As-Is）から始める — 理想の体験を描く前に、今のユーザーが体験している現実を正確に記録する - 感情曲線を必ず引く — 行動の記録だけでは問題の優先順位がわからない。感情の谷が優先ポイントを示す - エビデンスで埋める — リサーチデータに基づかない箇所は推測として明記し、後で検証する - スコープを絞る — 全体を1枚に収めようとしない。問題意識に直結した範囲に集中する - ネクストアクションで終わる — マップの完成をゴールにしない。ペインポイントからHMWへの接続まで必ず実施する - 写真を撮る — 完成したマップは全体と各セルを記録する。後日チームの共通言語になる --- 参考文献 - Nielsen Norman Group, "Journey Mapping 101", nngroup.com, 2018 - Nielsen Norman Group, "Customer Journey Maps — Walking a Mile in Your Customer's Shoes", nngroup.com - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - Marc Stickdorn & Jakob Schneider, This is Service Design Thinking, BIS Publishers, 2011 --- ### クリエイティブ・コンフィデンス・ビルディング URL: https://designthinking.studio/methods/creative-confidence-building/ > 「創造性は才能ではなく、誰もが持てる自信だ」というDavid KelleyとTom Kelleyの提唱する概念を、ワークショップ実践として落とし込んだ手法。アイデア発想フェーズの前提条件となる心理的安全性と創造的自信を、短時間の体験的演習で構築する。 「アイデアを出してください」と言われた瞬間、黙ってしまう人がいる。能力の問題ではない。「間違えたら恥ずかしい」「変なアイデアだと思われる」という恐怖が、思考を止めている。クリエイティブ・コンフィデンス・ビルディングは、この心理的なブレーキを取り除くことを目的とした実践的な手法だ。 クリエイティブ・コンフィデンスとは IDEO創業者でStanford d.school設立者のDavid Kelley と、IDEOパートナーのTom Kelley は著書『Creative Confidence: Unleashing the Creative Potential Within Us All』の中でこう定義している。 "Creative confidence is about believing in your ability to create change in the world around you. This self-assurance lies at the heart of innovation." 「創造的自信とは、自分の周りの世界に変化をもたらせるという信念だ。この自己確信がイノベーションの核心にある」という意味だ。 Kelley兄弟が強調するのは、創造性は「一部の才能ある人だけが持つもの」ではないという点だ。この前提を覆すことが、デザイン思考の実践においてアイデア発想フェーズを機能させる絶対条件になる。IDEOとStanford d.schoolでの長年の実践から生まれたこの手法は、ワークショップの冒頭またはアイデア発想フェーズの導入として機能する。 なぜアイデア出しの前に必要なのか クレイジーエイツやラウンドロビン・アイデエーションを始める前に、参加者の心理状態が整っていないと、手法の効果は大きく損なわれる。 特定の環境条件が、創造的な思考の障壁になる。「正解を出さなければいけない」というプレッシャー。同僚・上司がいる場での自己検閲。「自分には無理」という思い込み。これらが同時に作用するとき、参加者は「安全なアイデア」だけを提示し、本当に新しい発想は出てこない。 クリエイティブ・コンフィデンス・ビルディングは、この状態を変えるための「準備運動」だ。身体が動かせる状態を作ってから、本番の演習に入る。 ワークショップの全体設計 所要時間は60〜120分を想定している。短縮版（60分）はStep 1〜4のみで構成し、フルバージョンはStep 5〜6まで含む。参加者6〜20名を想定しているが、4〜5名のグループに分けて運営する。 場の条件として、壁面か大きなテーブルに成果物を貼り出せるスペースが必要だ。席の配置は「前を向いて聞く教室型」を避け、グループが向き合える形にする。この物理的な配置が、心理的な安全性に影響する。 ステップ Step 1：環境整備とルール提示（10分） 開始前に、ファシリテーターがこのワークショップの前提を明確に伝える。 「今日のセッションでは、良いアイデアも悪いアイデアも存在しません。数を出すことが最初の目標です」。この宣言は、後の演習への参加姿勢を決定づける。加えて「他の人のアイデアへの批判は禁止」「質より量」「他のアイデアに乗っかってよい」の3点を壁に貼り出す。 ファシリテーター自身が「変なアイデア」を最初に出すことで、心理的な許可を与えるのが効果的だ。 Step 2：身体ウォームアップ（5〜10分） 座ったまま始めず、軽い身体的な活動を挟む。理由は単純で、身体が動くと思考の緊張もほぐれやすい。 代表的な方法は「Yes, and...」の口頭ゲームだ。2人組になり、一方が「週末に空飛ぶ車で旅行しました」と言い、もう一方が「Yes, and、そのまま別の星まで行きました」と続ける。この繰り返しを2〜3分行う。「Yes, but（でも）」ではなく「Yes, and（そして）」で返すことで、批判なく発想を積み重ねる体験を身体でつかむ。 Step 3：30アイデアチャレンジ（15分） タイマーを使い、一人でポストイットに「〇〇の新しい使い方」を15分で30枚書く課題を出す。〇〇は「ペーパークリップ」「消しゴム」「ペットボトルのキャップ」など、誰でも知っているもので問題ない。 ポイントは「質の評価を後回しにする」点だ。 最初の10〜12枚は比較的すぐ出るが、13枚目以降に壁が来る。この壁を突破する体験が、「思いつかなくなってからが本番」というクリエイティブ・コンフィデンスの核心部分だ。 15分後、各自の枚数を確認する。30枚を超えた人には拍手を。10枚未満の人には「次はもっと出るはず」と伝える。数を数えるだけで、「出せた自分」の小さな成功体験になる。 Step 4：シェアとリアクション（15分） グループ内（4〜5名）で出たアイデアを壁に貼り出し、声に出して読む。聴いている人は評価しない。「それいいですね」「それは難しそう」も言わず、ただ聴く。 1分間の壁を見ながら「面白いと感じたもの」にドット（丸いポストイット）を貼る投票を入れると、発言せずとも反応を共有できる。自分が「変かな」と思ったアイデアに票が集まる体験が、自己検閲の誤りを実感させる。 Step 5：制約付きアイデア出し（15〜20分） Step 3と4を経て、今度は「制約」をつけた課題に移る。「予算がゼロなら」「1日で実装しなければいけないなら」「5歳児が使うなら」という制約が、発想の方向を強制的に変える。 制約の効果は、Kelley兄弟の実践でも報告されている。「何でもよい」より「この制約の中で」の方が、参加者が選択肢を狭めることへの迷いが消え、結果として大量のアイデアが生まれやすい。 グループで作業し、ポストイットに1アイデア1枚で書く。タイマーは10分に設定する。 Step 6：振り返りと自己宣言（10〜15分） ワークショップの締めとして、個人ノートまたは小さな紙に「今日の発見」と「次のプロジェクトで試すこと」を書かせる。書いたものを声に出して読む必要はなく、自分のために書くことが重要だ。 ファシリテーターは最後に一言添える。「今日30枚出た人は、先週は15枚だったかもしれません。来月は50枚になるかもしれません。それがクリエイティブ・コンフィデンスです」。 ファシリテーターが押さえるべき3点 沈黙を急いで埋めない。 Step 3の30アイデアチャレンジ中、参加者が止まっても声をかけない。この沈黙の中で「次を絞り出す」体験が学習になる。ファシリテーターが早期に声をかけると、その体験が奪われる。 「そのアイデアいいですね」と言わない。 アイデアを評価する発言は、それ以外のアイデアを「良くない」と暗示する。リアクションは「ありがとうございます」「出ましたね」といった受け取りに留める。 自分が最初に変なアイデアを出す。 ファシリテーターが先頭で「明らかに突拍子もないアイデア」を出すことで、場の許可が生まれる。「進行役でも変なことを言っていい」という実例が、参加者の心理的なブレーキを緩める。 実例：スタートアップの製品開発ワークショップ あるスタートアップチームが新機能の発想会議を行った際、最初の20分は全員が「現実的な範囲」のアイデアしか出なかった。マネージャーが同席していたためだ。 セッションを中断し、クリエイティブ・コンフィデンス・ビルディングのStep 2〜4（身体ウォームアップ→30アイデアチャレンジ→シェア）を40分で挟んだ。この後、同じメンバーが同じ課題に戻ったとき、アイデアの性質が変わった。「そんなの無理では？」という発言が消え、「それ面白い、もし〇〇ならいける？」という積み上げが生まれ始めた。 ファシリテーターの介入は1点だ。「アイデアが変かどうかの判断は、あとでやります」という宣言を、途中で1回繰り返した。 他の手法との組み合わせ クリエイティブ・コンフィデンス・ビルディングは単独で成立する手法ではなく、前工程として機能する。 クレイジーエイツの前に入れることで、参加者の発言密度が上がる。ハウ・マイト・ウィー（HMW）と組み合わせるときは、クリエイティブ・コンフィデンス・ビルディングで発想の筋肉をほぐしてから、HMWの問いに転じると自然な流れになる。 また、チームが初めて顔を合わせるキックオフや、失敗体験が続いて士気が低下しているプロジェクトの再起動時にも有効だ。アイデアの良し悪しではなく「出せた事実」を積み重ねることが目的のため、内容よりもプロセスが主役になる。 この手法が効かない状況 結果に直結する意思決定会議の冒頭には向かない。「今すぐ答えを出さなければ」という状況プレッシャーがあるとき、参加者はウォームアップを「時間の無駄」と感じ、逆効果になることがある。 参加者が初対面でない場合も、別の導入を検討する価値がある。すでに信頼関係があるチームでは、心理的安全性の構築より、発想の方向性の整理が先になることが多い。 --- クリエイティブ・コンフィデンスは、一度身についたら消えない。最初の体験が「自分でも出せた」という記憶として残り、次のアイデア出しのハードルを下げる。Kelley兄弟が言う「信念」は、最初の成功体験の積み重ねから作られる。この手法の役割は、その最初の一枚を渡すことだ。 --- 参考文献 - Kelley, D., & Kelley, T. (2013). Creative Confidence: Unleashing the Creative Potential Within Us All. Crown Business. - Stanford d.school. (n.d.). Creative Confidence. dschool.stanford.edu. - IDEO. (n.d.). Design Thinking. ideo.com. --- ### クレイジーエイト応用編 — 8分で8案を超える発想法 URL: https://designthinking.studio/methods/crazy-eights-advanced/ > 基本のクレイジーエイトを発展させた応用テクニック集。チーム拡張法・逆転発想バリエーション・「最悪案から最良案」変換プロセスなど、アイデアの質と量を同時に高める実践手法。 クレイジーエイトは「8分間で8つのスケッチを描く」というシンプルな制約が生み出す発想法です。1案に集中してしまう思考の癖を強制的に打ち破り、量から質へとアイデアを進化させる有効な手法として、200回以上のワークショップ観察でその有効性が確認されています。 この応用編では、 基本のクレイジーエイトをさらに発展させた実践テクニック を体系化します。「8分で8案」という基本構造を土台に、アイデアの多様性・発想の深さ・チームでの活用を拡張する方法です。 基本の振り返り：なぜ「8」と「1分」なのか クレイジーエイトの設計思想は「 量が質を生む 」という発想法の根本原理に基づいています。「良いアイデアを得るための最善の方法は、たくさんのアイデアを持つことだ」——この原則は多くの創造性研究でも支持されています。 1マスにつき1分という制約は、 「考える」より「描く」を強制する ためのものです。完成したスケッチを作ろうとすると人は考えすぎます。1分という時間は「考えが固まる前に手を動かす」を促します。太めのマーカーを使うことを推奨するのも、細部を描けないようにすることで「コンセプトの形」だけを素早く表現させるためです。 応用テクニック1：「強制多様性」クレイジーエイト 基本のクレイジーエイトで起きやすい問題は、8案が結局似たようなアイデアに収束することです。「似た解決策の細部が違うだけ」という8枚が完成するのは、発散が十分に起きていない証拠です。 「強制多様性」バリエーションでは、 描き始める前に8つのカテゴリ制約を設定します。 例えば以下の8カテゴリを各マスに割り当てます。 - デジタル解決策 — アプリ・ウェブ・通知など - 物理的解決策 — モノ・空間・看板など - 人が介在する解決策 — スタッフ・コーチ・コミュニティ - 自動化解決策 — センサー・AI・スケジュール - 制約を除去する解決策 — 手続きをなくす・ステップを消す - 逆転解決策 — 問題をまったく逆から捉えた案 - 極端に安い解決策 — ゼロコストまたは紙1枚で解決 - 極端に大きな解決策 — 理想状態・10年後のビジョン このカテゴリ制約があることで、発想の方向が強制的に多様化されます。「デジタルとアナログで1案ずつ」というだけでも、アイデアの多様性は大幅に広がります。 応用テクニック2：「最悪案→最良案」変換 この変換法は、発想の詰まりをリセットするための強力な手法です。ワークショップで「アイデアが出ない」「似た案しか出ない」という状態が現れたときの処方箋として有効です。 Step 1：最悪のアイデアを8分で8案描く。「どうすればユーザーをもっと困らせられるか」「この問題を絶対に悪化させるには？」という問いを使って、意図的に最悪の解決策を考えます。 Step 2：各「最悪案」の逆転を考える。「最悪案：ユーザーに情報を全部自分で探させる」→「逆転：必要な情報がユーザーの行動に合わせて自動的に現れる」という変換が、予想外のアイデアの出発点になります。 この手法が機能する理由は 「最悪を考えるほうが判断の障壁が下がる」 ことにあります。「良いアイデアを出さなければ」というプレッシャーを消すことで、思考のブロックが解除されます。 応用テクニック3：「ユーザー目線シフト」8連発 基本のクレイジーエイトを繰り返しているとき、暗黙の前提として「設計する側の視点」が入り込んでいることがよくあります。「この機能を追加すれば」「このフローを変えれば」という発想は、設計者の目線です。 「ユーザー目線シフト」では、 8案それぞれを特定のユーザーの視点から描きます。 - 初めて使うユーザー（ゼロ知識） - 10年使っているベテランユーザー - 急いでいるユーザー - 不安を感じているユーザー - 障害を持つユーザー（視覚・運動など） - 高齢ユーザー - 子どもユーザー - 敵対的なユーザー（使いたくないが使わざるを得ない） それぞれのユーザーが「この場面でどう感じ・何を求めるか」を体感しながら描くことで、単一視点では見えなかったニーズが浮かび上がります。これは共感フェーズのインサイトを創造フェーズに持ち込む形式でもあります。 応用テクニック4：チーム拡張クレイジーエイト 複数人が同じクレイジーエイトシートをリレーで描く 手法です。 Step 1：最初の人が4案描いて、隣の人にシートを渡す。 Step 2：次の人は残り4マスを描く。ただし「前の4案のどれかを発展させる」「前の4案のどれかと全く違う方向に行く」のいずれかを意識する。 このリレー方式のクレイジーエイトは、 「他者のアイデアを見ることで思考が刺激される」という効果 を活用します。「なぜこの人はこんな案を描いたのか」という解釈の時間（30秒）が、脳の発想回路を活性化します。 Miro上での実施では、各自のキャンバスを隣のキャンバスの横に並べる配置にすることで、他者の案が視野に入りながら自分の案を描けます。「見ないようにして描く（競合しない発想）」と「見ながら描く（影響を受ける発想）」の両方を使い分けられる設計です。 応用テクニック5：タイム変更バリエーション 「1マス1分」は標準設定ですが、目的に応じてタイムを変えることで効果が変わります。 30秒×8案（超高速）：思考する余地をゼロにし、手が覚えているものだけを描く。直感的なアイデアの発掘に使います。ウォームアップとして最初に実施するのが効果的です。 2分×8案（ゆったり）：コンセプトの背景まで表現できる。UI設計・サービスブループリント・製品の外観など、もう少し詳細が必要なアイデアに使います。 1分×16案（2ラウンド）：1ラウンド目の8案を「粗いドラフト」、2ラウンド目を「掘り下げ」として設計する。1ラウンド目で出たアイデアの中から最も可能性のある案を、2ラウンド目でより具体的に描く形です。 発表・選択との接続 クレイジーエイトは「描くこと」で終わりではありません。 8案から最有力案を選ぶプロセス が続きます。 最も素直な選択方法は「ヒートマップ投票」です。各参加者が全員のクレイジーエイトシートを見て、最も興味を引かれたアイデアに小さな点（ステッカーや付箋）を貼ります。集計することなく、視覚的に「注目度の高い案」が浮かび上がります。 重要なのは、票を集めた案がチームの判断基準に合っているかの クリティカルな確認 です。「面白いから票が集まった」のか「ユーザーの本質的なニーズを満たしているから票が集まった」のかは別の問いです。票数とは別に「これはHMWの問いに答えているか」という問いで再確認します。 リモート実施のガイド Miroでのリモート実施では、 「8分割テンプレート」を参加者全員分用意して、各自が独立したフレームで描く 設計が機能します。 タイマーは共有画面に表示（ブラウザのTimer機能やMiroの内蔵タイマー）し、全員が同じカウントダウンを見ながら進めます。この「同時に動くタイマー」が、対面に近い一体感とプレッシャーをリモートでも生み出します。 音楽を流すことも有効です。テンポの速いインストルメンタル（約120BPM）は、手を動かし続けるエネルギーを維持します。Spotifyの「Deep Focus」や「Brain Food」プレイリストが活用できます。 --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016 - Tom Kelley & Jonathan Littman, The Art of Innovation, Currency/Doubleday, 2001 - Teresa M. Amabile, "Motivating Creativity in Organizations," California Management Review, 40(1), 1997 --- ### コンセプトカードソーティング URL: https://designthinking.studio/methods/concept-card-sorting/ > ユーザーがコンセプト・情報・機能をどのように分類・命名するかを観察するIA研究手法。デザインリサーチでは製品コンセプトの評価・優先度付けにも応用される。オープン／クローズド／ハイブリッドの3形式がある。 カードソーティング（Card Sorting）は、ユーザーがコンテンツや概念をどのように分類し、命名するかを観察するリサーチ手法だ。もともと情報アーキテクチャ（IA）の領域で、ウェブサイトのナビゲーション構造を設計するために発展した。デザインリサーチへの応用では、製品コンセプトの評価・優先度付け・ユーザーのメンタルモデルの把握に活用される。 手法の概要 参加者は、コンセプト・機能・情報アイテムが書かれた一枚一枚のカードを手にし、「似ていると思うもの同士」をグループにまとめ、そのグループに名前をつける。研究者はその分類パターンと命名を観察・記録することで、ユーザーのメンタルモデル——すなわち「ユーザーが世界をどのように認識し、カテゴリ化しているか」——を把握する。 重要なのは、カードソーティングが「ユーザーが好きな設計を直接聞く」手法ではないことだ。ユーザーは多くの場合、自分のメンタルモデルを言語化できない。しかし「これとこれは似ている気がする」という直感的な行動の中に、そのモデルが現れる。カードソーティングは、この言語化されにくい認知構造を行動から引き出す手法だ。 3つの形式 オープンカードソーティング（Open Card Sorting） 参加者がグループの数・名前・構成をすべて自由に決める形式。カテゴリの命名にも制約がない。 用途はユーザーのメンタルモデルを白紙の状態から探索すること。新規プロダクトの情報構造設計や、既存のカテゴリ体系を根本から見直す段階に適している。50〜100枚のカードが扱える上限の目安で、それ以上になると参加者の負荷が高くなりすぎる。 オープン形式の強みは、研究者が想定していなかったカテゴリが出現する点だ。「そのような分類のされ方は想定していなかった」という発見が、既存のUI設計の根本的な問題を示すことがある。 クローズドカードソーティング（Closed Card Sorting） カテゴリ（グループの名前）を研究者があらかじめ定義し、参加者は各カードをそのカテゴリのいずれかに分類する形式。 用途は既存の情報構造の検証や、設計候補の比較評価。「このメニュー構造でユーザーは直感的にナビゲートできるか」という問いに対して、定量的な根拠を集める段階に適している。 クローズド形式の強みは、分析の比較可能性と定量化にある。参加者間の分類一致率を算出でき、「このカードが最も正しいカテゴリに分類される割合」という指標が得られる。 ハイブリッドカードソーティング（Hybrid Card Sorting） クローズド形式のようにあらかじめカテゴリを提示しつつ、参加者が必要に応じて新しいカテゴリを追加できる形式。 オープンとクローズドの中間的な知見を得ることができる。既存の構造を維持しながら、ユーザーが感じている「この構造では収まらない」要素を把握したい段階に適している。 実施の手順 ステップ1：カードの設計 カードの内容は研究目的によって異なる。IAリサーチでは「機能名・ページ名・コンテンツ項目」が書かれる。コンセプト評価では「アイデアの簡潔な説明文」が書かれる。 設計上の原則は1枚1コンセプト。複数の意味を含む記述は分類を混乱させる。カードの文章は10〜20字程度で、参加者が読んですぐ理解できる平易な言葉を使う。専門用語は避けるか、一般的な言葉に言い換える。 物理カードを使う場合は、番号を振る（分析時の記録のため）。デジタルツールを使う場合は、OptimalSort、Maze、UserZoom 等が一般的だ。 ステップ2：参加者のリクルート 代表的なユーザーセグメントからリクルートする。定性的な洞察（メンタルモデルの深い理解）であれば5〜8人から有意な知見が得られる。定量的な信頼性が必要なら15〜30人が推奨される。 インタビューと同様に、研究したいユーザー像と参加者が一致していることが重要だ。ターゲット外のユーザーのメンタルモデルは、設計の参考にならない。 ステップ3：セッションの実施 参加者にはまず手法の概要を説明する。「正解はない。あなたの自然な感覚でグループを作ってください」というインストラクションが基本だ。評価や批判はしない、という心理的安全性の確保が重要になる。 セッション中は思考発話法（Think Aloud）を促す。「なぜこの2枚を一緒のグループにしたのか」「このカードはどちらに入るか迷いましたか」という問いを適宜挟み、分類の背後にある理由を言語化させる。この発話が、後の分析で最も価値ある定性データになる。 ステップ4：分析 物理カードの場合は各参加者の分類結果を表に記録する。カードAとカードBが同じグループに入った参加者の割合（共起率）を算出し、共起率の高いペアを特定する。 デジタルツールでは樹状図（Dendrogram）や類似度マトリクスが自動生成される。これを参照しながら、ユーザーのメンタルモデルに基づいた情報グループを特定していく。 分類パターンの共通点だけでなく、参加者間の「ばらつき」にも注目することが重要だ。ある2枚のカードを「必ず一緒に」置く参加者と「必ず別々に」置く参加者が混在する場合、そのカードが持つ意味の曖昧さや、ユーザーセグメントの違いを示している可能性がある。 デザインリサーチへの応用 カードソーティングはもともとIA手法として発展したが、デザインリサーチでは製品コンセプトの評価に応用できる。 アイデエーションで生み出された複数のコンセプトをカードに書き出し、ユーザーに分類させる。「新しい」「高価そう」「使いやすそう」「業務向け」「個人向け」といったユーザー自身が付けたグループ名に、設計チームが意図していなかった製品認識が現れることがある。 コンセプトを「今すぐ欲しい / あってもなくても / 必要ない」という3つのカテゴリに分類させるクローズドカードソーティングは、機能の優先度付けの代替手法としても機能する。設計者が「重要」と判断した機能をユーザーが「あってもなくても」カテゴリに入れ続ける場合、その機能のポジショニングに問題がある可能性を示す。 類似手法との違い 親和図法（KJ法）はチームが収集したデータを分類する手法で、チーム内部の思考整理が目的だ。カードソーティングはユーザーが分類する手法で、ユーザーのメンタルモデルの把握が目的という点で異なる。どちらも「分類」という行為を使うが、誰が分類するかによって目的と得られる知見が根本的に異なる。 ワークショップで観察されるパターン カードソーティングのセッション中、参加者が「これはどちらにも入る」と迷い続けるカードが必ず出現する。この「どちらにも入る」カードは、2つの異なるメンタルモデルの境界領域を表していることが多い。 参加者が迷いながら発する言葉——「これは機能としては◯◯だけど、使うシーンで言えば◯◯」——が、製品の情報構造だけでなく、ユーザーの文脈的な使用パターンを開示する。カードソーティングで最も価値あるデータは、分類の結果ではなく、迷いの瞬間の発話にある。 --- 参考文献 - Spencer, Donna and Warfel, Todd, "Card sorting: a definitive guide", Boxes and Arrows, 2004 - Rosenfeld, Louis, Morville, Peter and Arango, Jorge, Information Architecture: For the Web and Beyond (4th Edition), O'Reilly Media, 2015 - Nielsen, Jakob, "Card Sorting: How Many Users Do You Need to Test?", Nielsen Norman Group, 2004 関連記事: 親和図法（KJ法） / ユーザーインタビュー / 問題定義フェーズ / 発散思考と収束思考 --- ### コンテキスチュアル・インクワイアリー（Contextual Inquiry） URL: https://designthinking.studio/methods/contextual-inquiry/ > ユーザーが実際に行動する現場に赴き、自然な行動を観察しながら質問する定性調査手法。インタビュー室では得られない「暗黙知」「文脈的な行動パターン」を発掘し、デザインのインサイトを深める。 ユーザーがワークショップルームで「普段こういうことをしています」と説明する行動と、実際に現場で観察される行動は、しばしば大きく食い違う。理由は単純で、人間は自分の行動を完全には言語化できない。習慣・ルール・例外処理・その場の判断——これらの多くは「暗黙知」として無意識に実行され、インタビュー室では言葉にならない。 コンテキスチュアル・インクワイアリー（CI）は、ユーザーの現場に調査者が赴き、実際の作業を観察しながら質問する手法だ。インタビュールームに呼ぶのではなく、調査者がユーザーの文脈に入っていく。この逆転が、通常の調査では見えない層のデータを引き出す。 概要 コンテキスチュアル・インクワイアリーは1988年にHugh BeyrとKaren Holtzblattが開発し、後に「コンテキスチュアルデザイン（Contextual Design）」の体系として整理された手法だ。ソフトウェアのユーザビリティ研究から始まったが、現在では製品設計・サービス設計・組織変革まで幅広く応用されている。 基本的な考え方は「徒弟制度（Apprenticeship Model）」にある。調査者がユーザーの「弟子」として現場に立ち、ユーザー（師匠）が仕事をやって見せながら説明する。調査者は観察しながら「なぜそうしたのか」「今何を考えているか」をタイムリーに問う。 この構造には3つの効果がある。ユーザーが「説明のために行動を組み替える」必要がない。実際の環境・道具・割り込み・判断が、そのままデータになる。そして「当たり前すぎて説明しなかったこと」が、調査者の「なぜ？」によって言語化される。 4つのコア原則 BeyrとHoltzblattが定義したCIの4原則は、手法の構造を支えるフレームワークだ。 原則1：文脈（Context）。データはユーザーが実際に作業している現場から収集する。会議室・自宅・工場・店舗——どこで使うサービス・製品であっても、その現場に出向く。文脈が変わればデータが変わる。 原則2：パートナーシップ（Partnership）。調査者とユーザーは対等なパートナーとして協働する。ユーザーが現場の専門家であり、調査者はその知識を学ぶ立場だ。「評価する・評価される」関係ではなく「共に探索する」関係が、ユーザーのオープンな発言を引き出す。 原則3：解釈（Interpretation）。観察した事実をその場で解釈し、ユーザーに確認する。「今のは○○という理由でしたか？」と問うことで、調査者の解釈の誤りをリアルタイムで修正できる。後処理での「推測」が減り、データの精度が上がる。 原則4：フォーカス（Focus）。調査者はあらかじめ「何を理解したいか」というフォーカスを持って現場に入る。ただしそのフォーカスは、現場で見えてきた予想外の重要事項に柔軟に広げる。フォーカスはあくまで「どこから見るか」であって、「何しか見ない」ではない。 ステップ Step 1：フォーカス設定 現場に入る前に、調査チームで「今回の調査で理解したいこと」を3〜5項目に絞り込む。「どんな状況でエラーが起きているか」「どの情報を意思決定に使っているか」「作業の中断はどのタイミングで起きるか」——このレベルの具体性がフォーカスとして機能する。「ユーザー体験を理解する」という抽象的な目標はフォーカスにならない。 調査設計の段階でエンパシーマップの「まだわかっていないこと」の欄を使い、フォーカスの候補を洗い出すと整理しやすい。 Step 2：調査対象の選定とアクセス設計 調査対象は「実際に作業をしている本人」であることが大前提だ。マネージャーや担当者の上司に話を聞くと、実際の作業の実態ではなく「理想的な作業の説明」が返ってくることが多い。 現場へのアクセス許可は、実施前に書面で取得する。何を観察するか・録音・録画の有無・データの取り扱い方針を明確に伝える。企業・医療機関・行政機関では、個人情報保護・守秘義務に関する取り決めが必要になることが多い。 Step 3：現場導入とウォームアップ 現場到着後、最初の5〜10分は「今から何をするか」の説明と関係構築に使う。ユーザーに緊張を感じさせないよう、「私が評価しているのではなく、あなたから学んでいる」というパートナーシップの構図を言語化して伝える。 「弟子モードに入ります。いつもの仕事をやっていただき、気になることがあれば途中でお聞きします」というフレームを最初に設定しておくと、観察中の質問が自然な流れになる。 Step 4：観察と同時質問（コア段階） ユーザーが実際の作業を開始したら、観察を始める。調査者が口を挟みすぎず、作業の自然な流れを壊さないことが最優先だ。ただしリアルタイムの質問を完全に止める必要はない。 質問のタイミング：ユーザーが何かを迷った瞬間。「普段と違う」手順を踏んだ瞬間。ツールや資料に手を伸ばした瞬間。感情的な反応（ため息・舌打ち・笑い）が出た瞬間——これらが暗黙知の「入り口」だ。 質問の形式：「なぜそうしたのですか？」は防衛的になりやすい。「今何を判断していましたか？」「このとき、何を参考にしていますか？」という「実況中継型の問い」の方が、自然な回答を引き出しやすい。 観察ノートには「発言の引用」と「行動の事実」を分けて記録する。解釈は括弧書きで、事実とは区別して記録する。 Step 5：まとめと解釈の確認 セッション終盤（最後の10〜15分）は、記録した観察をユーザーに読み上げ、解釈を確認する。「私は○○と理解しましたが、合っていますか？」という確認が、この手法の精度を支える。誤解釈があればその場で修正し、「なぜその行動を取ったか」を追加で聞く機会になる。 Step 6：分析とインサイト抽出 複数のセッション後、収集したデータをアフィニティダイアグラムで整理する。行動パターン・ボトルネック・環境要因・暗黙のルールを軸にクラスターを作ることで、インサイトの輪郭が浮かぶ。 BeyrとHoltzblattの「コンテキスチュアルデザイン」では、この後に「シーケンシャルモデル（作業の流れ）」「フィジカルモデル（物理的環境）」「フローモデル（情報・モノの流れ）」「カルチャーモデル（組織文化・暗黙のルール）」に整理する体系を持っているが、デザイン思考の文脈では問題定義フェーズへの接続を最優先に、シンプルな整理から始めることが多い。 実例：病院の入院手続きフロー改善 医療機器メーカーが、病院の入院受付プロセスを観察したセッションの例だ。 受付担当者へのインタビューでは「手順書通りに進めています」という回答が得られていた。しかし現場での観察から、以下の事実が浮かんだ。 「手順書にない紙の補助メモを3枚、常にデスクに置いている」。なぜか問うと「システムの動きが遅い時用の順番待ちリスト」「患者さんが高齢で聞き返すことが多い項目の確認用チェックシート」「部署に新しく来た人向けの暗号のようなメモ（〇〇さんは□□と言ったら△△に連絡）」という、システムが対応していない「人間が補完しているレイヤー」が可視化された。 インタビュー室ではこれらは「普通のこと」として語られず、調査対象にならなかっただろう。現場観察によって「システムの欠陥を人間が毎日手動で補完している」という真のインサイトが浮かんだ。 ユーザーインタビューとの使い分け 通常のユーザーインタビューと比べたとき、コンテキスチュアル・インクワイアリーが優先されるのは以下の状況だ。 「行動の実態」を知りたいとき（言葉でなく行動が情報源）。「暗黙のルール・例外処理」を掘り起こしたいとき。ユーザーが「自分がどうしているか」を言語化しにくいとき（習慣化された行動・職人的スキル）。物理的な環境・道具・レイアウトが体験に影響していると仮定されるとき。 逆に、態度・価値観・将来の行動意図を知りたいときは、通常のインタビューの方が効率的だ。 留意点 観察による行動変容。「観察されている」という意識が行動を変える「ホーソン効果」のリスクがある。セッション開始後、ユーザーが作業に集中し始めたら意識は薄れることが多いが、導入段階でのコミュニケーションが重要だ。 現場アクセスの難易度。ユーザーの職場・自宅・医療現場への立ち入りは、インタビュー室での調査より許可取得が難しい。プロジェクト計画の段階でアクセス設計を含めておく必要がある。 データ量と分析コスト。1セッション1〜2時間の観察は、大量のテキスト・映像データを生む。複数セッションを並行させる場合は、分析リソースを事前に確保しておく。 --- コンテキスチュアル・インクワイアリーは「うまくいっているはず」のプロセスや製品に潜む「人間が毎日黙って補完しているもの」を可視化する。そこに発見されるのは、最も価値の高いデザインの問いだ。 --- 参考文献 - Beyer, H., & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann. - Holtzblatt, K., Wendell, J. B., & Wood, S. (2005). Rapid Contextual Design. Morgan Kaufmann. - Nielsen Norman Group. (n.d.). Contextual Inquiry: What It Is and What It's Useful For. nngroup.com. --- ### サービスサファリ URL: https://designthinking.studio/methods/service-safari/ > サービスサファリは自分自身がサービス利用者となり体験・観察・記録を行う共感フェーズのリサーチ手法。1〜6名・2〜4時間の実施手順、シナリオ設定の具体例、リアルタイム記録の4項目、チームでの振り返り分析まで実践的に解説する。 サービスサファリ（Service Safari）は、自分自身が実際のサービスの利用者となり、体験しながら観察・記録を行うリサーチ手法です。机上のリサーチや第三者へのインタビューでは捉えにくい「サービス接点の細部」「感情の推移」「文脈の中でのユーザー行動」を、一人称の体験として収集します。 共感フェーズの入口として使われることが多く、仮説を持ちすぎた状態でインタビューを行う前に、まず体験するという姿勢を持つための手法です。 概要 「サファリ」という名称は、野生動物を観察するサファリツアーからの比喩です。サファリでは、観察者は自然な生態系の中で動物を観察します。サービスサファリでも同様に、人工的に作られた実験環境ではなく、現実のサービス環境の中で観察するという原則を持ちます。 自社のサービスを対象にする場合と、競合サービスや参照すべき他業界のサービスを対象にする場合があります。いずれの場合も、「設計者・改善者」の視点ではなく「初めて使う一般ユーザー」の視点で体験することが求められます。 サービスサファリの対象は広義に設定できます。実店舗・Webサービス・行政手続き・医療サービス・公共交通機関・飲食店——「サービス接点（タッチポイント）が存在するすべて」が対象です。 この手法の特徴は、調査員自身が感情を持つ体験者になることです。「不便さ」「待たされる感覚」「分からないときの焦り」「期待を超えられた喜び」は、インタビューで「どう感じましたか」と聞くだけでは掴みきれません。体験者として感じた感情そのものがデータになります。 手順 Step 1：体験する対象とシナリオの設定（事前準備、30〜60分） サービスサファリを始める前に、「誰として、何のためにこのサービスを使うか」というシナリオを設定します。 シナリオ設定の例：「初めてこの市役所を訪れ、転入届を出す30代の会社員」「スマートフォンに不慣れな60代として、この銀行アプリで振込を行う」「海外旅行が初めての人として、この旅行予約サイトで東南アジアのツアーを予約する」 シナリオが具体的であるほど、観察の焦点が絞られます。 「一般的なユーザーとして使う」という曖昧なシナリオでは、観察が表面的になります。「このような状況にいる、このような人物として体験する」という具体性が重要です。 また、体験前に「観察の焦点」を2〜3個設定しておきます。「情報を探す行動のどこでつまずくか」「スタッフとの接点でどんなコミュニケーションが起きるか」「次に何をすれば良いか分からない瞬間はどこか」など。焦点がなければ、後から振り返りができません。 Step 2：リアルタイムの観察と記録（体験中） 体験中は「その瞬間に感じたこと」を記録します。後で振り返ってまとめるのではなく、感じた瞬間に記録することが原則です。感情は体験から時間が経つほど薄れ、「一般的な感想」に収斂していきます。 記録すべき項目： - その瞬間の感情：「迷った」「イライラした」「安心した」「嬉しかった」（感情の種類と強さ） - 起きた行動：「スタッフに声をかけようとしたが、誰がいるか分からなかった」「案内板を読んで3回迷った」 - 環境・文脈：「周りに同じように迷っている人が2人いた」「混雑していて待機場所が分からなかった」 - 疑問と仮説：「なぜここに説明がないのか」「ユーザーはどんな前提知識があると想定しているのか」 記録の方法はメモ・音声メモ・写真（許可がある場合）のいずれでも構いません。ただし「記録のために体験が浅くなる」ことを避けるため、記録は最小限に留め、体験に没入する時間を確保します。 Step 3：体験直後の振り返り（体験直後、15〜30分） 体験が終わったら、場所を離れる前に5〜10分で記憶が新鮮なうちにメモを補完します。体験中に記録できなかった細部、感じたことの背景、「なぜそう感じたか」の考察を追加します。 複数人でサービスサファリを行っている場合、この段階での情報共有は行いません。各自の体験を汚染しないように、振り返りは独立して行います。 Step 4：チームでの共有と分析（振り返りセッション、60〜90分） 複数人での実施後、または単独で実施した後のチームへの共有を行います。 感情曲線（Emotional Journey Map）を描くのが効果的です。横軸をサービス体験の時系列、縦軸を感情の正負（良い体験から悪い体験まで）として、体験を通じた感情の推移を線で描きます。感情が落ちた谷と、感情が上がった山を特定し、それぞれの「なぜ」を掘り下げます。 共有では「何が起きたか」より「どう感じたか」「なぜそう感じたのか」に焦点を当てます。事実の共有だけでなく、感情と解釈の共有が、共感フェーズとしての価値を生みます。 実践のコツ 「初心者の目」を意識的に作る サービスの設計や改善に関わっている人は、そのサービスについての知識を持ちすぎています。「ここを押せばいいと知っている」「このステップが必要と分かっている」という事前知識が、初めて使うユーザーの体験を遮蔽します。 「私は今このサービスを初めて使う人だ」と意識的に宣言してから体験を始めます。 知っている知識を意図的に「忘れる」ことはできませんが、「知らないふりをする」「なぜそう分かるのかを問い返す」という姿勢で体験することで、初心者のつまずきに近い感覚が得られます。 特に有効なのは、年齢・ITリテラシー・語学力などが自分と大きく異なるペルソナを設定する方法です。「ITに不慣れな高齢者として」体験することで、普段は気にしない「フォントサイズ」「専門用語の使用」「ステップの複雑さ」が問題として浮かび上がります。 「なぜ」を掘り下げる 体験中に気づいたことを記録するとき、表面的な観察だけに留まらず「なぜそう感じたか」を問い続けます。 たとえば「案内が分かりにくかった」という観察からスタートしたとします。なぜ分かりにくかったか——「どこへ進むかが書かれていなかった」。なぜそれが問題か——「初めての場所では、次のステップが見えないと足が止まる」。なぜ足が止まるか——「失敗したときの回復コストが読めないと、人は動けない」。 3回掘り下げたとき、「案内が不十分」という観察は「不確実性への耐性の低さ」というインサイトに変わっています。サービスの表面ではなく、ユーザーの心理構造に触れたことになります。 一人と複数を使い分ける サービスサファリは1名でも実施できますが、複数人で同じサービスを体験し、異なる視点を持ち寄ることで分析が豊かになります。同じ体験でも、感じ方は異なります。その差異を議論することで、「どのユーザー属性がどの接点で困難を感じるか」が見えてきます。 ただし、複数人での実施でも体験は分離して行います。体験中のコミュニケーションは観察を汚染します。 活用事例 医療機関の受付改善プロジェクト 大規模病院の受付プロセス改善を目的としたプロジェクトで、設計チームのメンバー全員が「初めて外来受診する患者」として病院を体験しました。事前知識のない状態で「受付→問診票記入→診察室への案内→会計」という一連のプロセスを体験。 発見されたのは「診察室がどこにあるか分からず、廊下を2往復した」「問診票の回収場所が分からず、スタッフに声をかけたが気づいてもらえなかった」「会計の順番が来たときの呼ばれ方が分からず、周囲の人を観察して真似た」という具体的な体験でした。 この体験から「情報の欠如」ではなく「次のステップの不可視性」という本質的な問題が定義され、矢印サインの追加よりも「今どこにいて、次に何をすればいいか」を常時表示するデジタルサイネージの導入という解決策に繋がりました。 Webサービスのオンボーディング設計 BtoBのSaaSプロダクトのオンボーディング改善プロジェクトで、開発者・デザイナー・営業担当がそれぞれ「導入を検討している企業の情報システム担当者」というペルソナで、競合3社と自社のサービスのトライアル申込みから初回ログインまでを体験しました。 競合サービスで「30分以内に何ができるか分かった」体験と、自社サービスで「1時間後も何をすれば良いか分からなかった」体験の対比が、オンボーディングの大規模見直しのきっかけになりました。 --- 参考文献 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Kumar, Vijay, 101 Design Methods: A Structured Approach for Driving Innovation in Your Organization, Wiley, 2012 - Martin, Bella & Hanington, Bruce, Universal Methods of Design: 100 Ways to Research Complex Problems, Develop Innovative Ideas, and Design Effective Solutions, Rockport Publishers, 2012 - Stickdorn, Marc & Schneider, Jakob, This is Service Design Thinking, BIS Publishers, 2012 --- 関連項目 - 共感インタビュー - コンテキスチュアル・インクワイアリー - カスタマージャーニーマップ - シャドーイング - 共感フェーズ --- ### サービス設計ブループリント：フロントステージとバックステージを可視化する手法 URL: https://designthinking.studio/methods/service-design-blueprint/ > Shostack（1984）が生み出したサービスブループリントの5レイヤー構造、作成手順、UberEatsへの適用例を解説。顧客体験とオペレーションの全体像を一枚の図に収める方法。 サービスブループリントは、サービスの全体構造を「顧客の行動」と「組織の内部プロセス」の両面から可視化するダイアグラムです。ユーザーが体験するフロントエンドと、その体験を支えるバックエンドの運営プロセスを一枚の図に統合することで、サービスの断絶箇所（ガップ）と改善機会を発見します。 起源：G. Lynn Shostack（1984） サービスブループリントは、バンカーズ・トラストのマーケティング担当者だったG. Lynn Shostackが1984年に Harvard Business Review で発表した論文「Designing Services That Deliver」で初めて提唱されました。 Shostackの出発点は「サービスは製品と違い、設計図（Blueprint）がない」という問題意識でした。製品は工場の製造仕様書があり、品質の再現性が担保されます。しかし接客サービスや医療、教育などのサービスは、提供者と顧客の相互作用の中で毎回「生産」されるため、品質のばらつきが大きい。この問題を解くために、サービスのプロセスを可視化する設計図が必要だとShostackは主張しました。 その後、Mary Jo Bitnerらの研究者がフレームワークを体系化し、現在のサービスブループリントに発展しています。 --- 5レイヤー構造 サービスブループリントは5つの水平レイヤーで構成されます。これらのレイヤーは時系列（左→右）に並んだサービスの流れの中で、それぞれ異なる視点からプロセスを記述します。 レイヤー1：Physical Evidence（物的証拠） 顧客が各ステップで触れる「モノ」のリストです。Webページ、看板、受付票、領収書、ユニフォーム、店舗の内装——サービスを「可視化」するすべての有形要素がここに記録されます。 サービスは無形であるため、顧客はしばしば物的証拠によって品質を評価します。ホテルの客室の清潔さ、弁護士事務所の内装の重厚さ、医院の待合室の明るさ——これらは治療や法律相談の「本質的な質」とは別に、体験の印象を決定します。 レイヤー2：Customer Actions（顧客の行動） 顧客がサービスを利用する過程で行う行動の時系列です。「予約する」「到着する」「注文する」「待つ」「受け取る」「支払う」「評価する」——というように、顧客の視点から一連の行動を記述します。 このレイヤーはユーザージャーニーマップの「行動レーン」に相当しますが、ブループリントではより簡潔に「何をするか」を記述することに集中します。 レイヤー3：Frontstage（フロントステージ） 顧客の目に見えるスタッフの行動と、顧客との直接的なインタラクションです。接客、案内、説明、提供——など、顧客との「接点」にある業務がここに属します。 カスタマージャーニーマップとサービスブループリントの最も重要な違いは、このレイヤーの存在です。ジャーニーマップが「顧客の体験」を描くのに対して、ブループリントは「それを提供しているスタッフが何をしているか」まで可視化する点が特徴です。 レイヤー4：Backstage（バックステージ） 顧客の目には見えないスタッフの行動と組織内部のプロセスです。料理の調理、システムへのデータ入力、在庫管理、スタッフ間の連絡——など、フロントステージを支えるすべての内部業務がここに記述されます。 バックステージは、しばしばサービスの「問題の本源」が隠れている場所でもあります。顧客から見えない部分で起きているプロセスの断絶や遅延が、フロントステージでの体験悪化として現れます。 レイヤー5：Support Processes（サポートプロセス） Frontstage・Backstageのスタッフを支える組織インフラです。ITシステム、サプライチェーン、トレーニングプログラム、外部パートナーとの連携——など、サービス提供全体を下支えする仕組みがここに記述されます。 --- 3本の分離線 5つのレイヤーは3本の「分離線」によって構造化されます。 可視の線（Line of Visibility）：Frontstage（顧客から見える）とBackstage（顧客から見えない）を分ける線。この線より上が顧客体験の領域、下が組織内部の領域です。 インタラクションの線（Line of Interaction）：顧客とスタッフが直接接触する境界線。顧客のサービス体験は、この線を越えるたびに形成されます。 内部インタラクションの線（Line of Internal Interaction）：FrontstageとBackstageを分ける線。このラインを越える連携がどれだけスムーズかが、バックステージの問題がフロントステージに影響するかを決定します。 --- 作成手順 Step 1：サービスシナリオを定義する どのサービス体験をブループリント化するかを決めます。「初めてUberEatsを使うユーザーが、ランチを注文して受け取るまで」のように、開始点と終了点を明確にします。 一つのブループリントに「すべてのシナリオ」を詰め込もうとすると複雑になりすぎます。対象ユーザーとシナリオを一つに絞ることが重要です。 Step 2：Customer Actionsを左から右に並べる 対象シナリオを歩く顧客の行動を、時系列で付箋に書き出します。この段階では完璧さより「大きな流れ」を掴むことを優先します。 Step 3：Frontstageを顧客の下に配置する 各顧客アクションに対応するスタッフの行動（または自動化されたシステムの反応）を記述します。「顧客がアプリで注文する」→「システムが注文確認メッセージを送る」というように対応させます。 Step 4：Backstageを可視の線の下に追加する Frontstageの各ステップを支える内部プロセスを記述します。「注文確認メッセージを送る」を支えるバックステージには、「決済システムとの連携」「店舗への注文転送」「ドライバーへのマッチング」などが存在します。 Step 5：Physical Evidenceを最上段に配置する 各ステップで顧客が触れる「モノ」を上段に書き加えます。アプリのUI画面、プッシュ通知、配達員の外観と袋のデザイン、領収書——など。 Step 6：ガップ（断絶箇所）を特定する 完成したブループリントを眺めながら、「どこでフロントステージとバックステージの連携が断絶しているか」を特定します。情報が渡されない箇所、待ち時間が生じる箇所、顧客に不確実性が生まれる箇所がガップの候補です。 特定されたガップの解決案を検証する際には、プロトタイピングの手法を組み合わせることで、実装前に低コストで試作・検証が可能になります。 --- UberEatsへの適用例 UberEatsの「初回注文体験」をブループリントに落とすと、以下のガップが浮かび上がります。 ガップ1：配達状況の「最終1km」の不確実性。リアルタイムの位置情報は提供されますが、「いつ到着するか」の精度が低い時間帯があります。顧客は「近くにいるのに来ない」という不確実性の中でストレスを感じます。 ガップ2：配達完了通知と実際の受取のタイムラグ。「配達完了」の通知が来ても、実際にはドアの前に置かれているだけで顧客がそれを知らない場合があります（置き配の場合）。 ガップ3：問題発生時の解決フロー。注文が届かない、中身が違う、といった問題が生じたとき、誰に連絡すればいいか（ドライバー？店舗？UberEats?）が顧客に不明確です。 これらのガップは、ブループリントなしでは「なんとなく使いにくい」という感覚として分散して認識されます。ブループリントによって可視化することで、改善の優先順位と責任の所在が明確になります。 --- ジャーニーマップとブループリントの使い分け | | ジャーニーマップ | サービスブループリント | |---|---|---| | 視点 | 顧客中心 | 顧客+組織の両面 | | 感情の記述 | あり（感情の起伏を描く）| なし（行動の記述に集中）| | 用途 | 共感フェーズの洞察整理 | サービス設計・改善の設計図 | | 作成タイミング | 問題の発見・定義 | 解決策の設計・最適化 | 二つの手法は競合しません。ジャーニーマップで「どこに問題があるか」を発見し、ブループリントで「なぜその問題が起きているか」を診断するという組み合わせが最も効果的です。 --- 参考文献 - G. Lynn Shostack, "Designing Services That Deliver", Harvard Business Review, January–February 1984 - Mary Jo Bitner, Amy L. Ostrom & Felicia N. Morgan, "Service Blueprinting: A Practical Technique for Service Innovation", California Management Review, Vol. 50, Spring 2008 - Marc Stickdorn & Jakob Schneider, This Is Service Design Thinking, BIS Publishers, 2011 - Jürgen Tangemann, "Blueprint It: Service Blueprinting Explained", UX Collective, 2020 --- ### ジャーニー・シャドーイング URL: https://designthinking.studio/methods/journey-shadowing/ > 顧客の実際の行動を「影」のように追跡観察する民族誌的フィールドリサーチ手法。インタビューでは得られない無意識の行動・環境との相互作用・文脈を可視化し、カスタマージャーニーに行動的真実を埋め込む。 ジャーニー・シャドーイング（Journey Shadowing）は、調査対象者の実際の行動を「影（シャドウ）」のように密着追跡し、自然な文脈の中でのふるまいを観察・記録するフィールドリサーチ手法だ。インタビューが「人が何をしたかを語る」データを収集するのに対し、シャドーイングは「人が実際に何をするかを見る」データを収集する。この差は、デザイン思考における洞察の質を根本的に左右する。 なぜシャドーイングか——インタビューの限界を越える 記憶と行動のギャップ 人は自分の行動を正確に報告できない。心理学の研究が繰り返し示してきた通り、事後的な自己報告は実際の行動とずれる。「毎朝どうやって仕事に向かいますか？」という問いへの回答は、実際の通勤行動ではなく、本人がそうしていると「思っている」行動を語るに過ぎない。電車の乗り換えで咄嗟に選んだルート、エレベーターを待つ間にスマートフォンを操作する習慣、入り口で足が止まる瞬間——これらは本人が意識していない行動であり、インタビューでは浮かび上がらない。 シャドーイングはこのギャップを埋める。「言っていること」と「していること」のズレそのものが、最も深いインサイトの源泉となる。 文脈の保全 行動は文脈から切り離すと意味が変わる。病院の待合室で記入する問診票、電車内で読むマニュアル、工場の騒音の中で操作する機械——いずれも、その場の物理的・社会的・感情的文脈があってはじめて意味を持つ行動だ。シャドーイングは対象者を実際の文脈に置いたまま観察するため、文脈が行動に与える影響を直接記録できる。 起源と理論的背景 シャドーイングは社会学・人類学の民族誌的研究（エスノグラフィー）に起源を持つ。組織研究やサービスデザインの分野では、Blomkvist と Holmlid が 2010 年の Nordic Conference on Service Design and Service Innovation での発表論文で「Service Design Tools」の一手法として整理した。医療・行政・金融など複雑なサービスエコシステムを対象とする文脈で特に普及し、ユーザーがサービスのどのタッチポイントをどのような順序と感情で体験するかを可視化するためのフィールドワーク技法として定着している。 デザイン思考の文脈では、共感フェーズの手法として位置づけられる。ユーザーインタビューが「探索的な問い」を中心とするなら、シャドーイングは「観察的な記録」を中心とする補完的な手法だ。この2つを組み合わせることで、言語データと行動データの両軸でユーザー理解が成立する。 事前準備 対象者と文脈を選ぶ シャドーイングは「誰を」「どの文脈で」追跡するかで得られるデータが変わる。明確なリサーチクエスチョンを設定し、それに最も関連する行動文脈を持つ対象者を選定する。 典型的な対象文脈の例： - 病院の受付から診察室に至る患者の移動 - 店舗での購買意思決定の場面 - 公共交通機関の乗り換えプロセス - 職場での業務フローにおける特定タスクの遂行 人数は1セッション1〜2名を推奨する。複数を同時に追うとどちらの記録も粗くなる。 インフォームド・コンセント シャドーイングは必ず対象者の明示的な同意を得て実施する。観察の目的・記録方法・データの使用先・プライバシー保護の方針を書面で説明し、同意書を取得する。観察中に対象者が「やめてほしい」と申し出た場合は即座に中止する。同意を得た後でも、対象者のプライバシーに関わる場面（医療的な会話、個人的なやり取りなど）では観察・記録を停止する判断が必要だ。 公共空間での観察については各国の法規制と倫理指針を確認すること。 観察テンプレートの準備 フィールドでメモを取る時間は限られる。事前にタイムスタンプ欄・行動記述欄・感情読み取り欄・文脈メモ欄・疑問欄の5列からなる観察テンプレートを用意し、ページをめくるだけで記録できる状態にする。 実施の手順 Step 1：ブリーフィング（観察開始前・15〜30分） 対象者と観察者が初めて顔を合わせる場を設ける。目的の説明、同意確認、観察方法の説明（どの程度の距離を保つか、声をかけてよいタイミングはどこかなど）を行う。 ブリーフィングで伝えるポイント： - 「あなたを評価しているのではありません。私たちが学ぼうとしているのは、このサービス・プロセス・環境についてです」 - 「普段通りに行動してください。できるだけあなたの存在を邪魔しないように努めます」 - 「気になったことがあれば、歩きながらでも声に出してください（シンクアラウドの場合）」 対象者が「見られている」意識を持ちすぎると行動が変容する（Hawthorne 効果）。ブリーフィングを短く、自然に保つことがこの効果を最小化する。 Step 2：シャドーイング開始——距離と非干渉を保つ 観察者は対象者の1.5〜2メートル後方から追跡するのを基本とする。会話が聞こえる距離を保ちながら、対象者の視野に常に入らない位置を選ぶ。観察中に「これはどういう意図ですか？」などの質問はしない。記録は後のデブリーフィングまで取っておく。 記録する対象は以下の通り： 行動（Behavior）: 対象者が何をしたか、どの順序で、どれくらいの時間をかけて行ったか。動詞と時刻で記録する。「10:23 — 受付前の案内板を約45秒間見てから左に進んだ」 環境との相互作用（Environmental Interaction）: 対象者が物理的な環境や道具とどのように関わったか。「記入台のペンがなく、バッグからペンを取り出した」「エレベーターのボタンを間違えて2度押した」 感情の外的サイン（Emotion Signals）: 表情・姿勢・発声・動作のテンポから読み取れる感情の変化。「眉をひそめて立ち止まった」「長いため息の後に方向転換した」 環境の記録（Context Notes）: 周囲の状況、混雑度、照明、音、他者の存在など。 Step 3：転換点に注目する シャドーイングで特に重要なのは、対象者の行動に変化が起きる瞬間だ。 - 立ち止まる・引き返す - 迷って別の選択肢を試す - 助けを求めて周囲を見回す・他者に声をかける - 明らかに感情が動いた瞬間（表情・発声・姿勢の変化） - 予期しない方法でサービス・道具を使う これらの転換点は「システムの設計意図とユーザーの実際の行動の乖離」を示している。見逃さないように、転換点には★マークをつける習慣を持つ。 Step 4：シンクアラウドとの組み合わせ（任意） 対象者に「気になったことを声に出してください」と依頼するシンクアラウド（Think Aloud）を組み合わせると、行動の背後にある思考・判断・迷いを同時に収集できる。ただし、自然な行動文脈を維持することを優先する場合は、シンクアラウドを省くか、観察後のデブリーフィングで補う。 Step 5：デブリーフィング（観察直後・30〜60分） 観察セッション終了直後に対象者と短い会話の場を持つ。「フィールドで記録できなかった内部状態」——何を考えていたか、何が気になったか、どう感じたか——を補完する機会だ。 デブリーフィングで特に聞く内容： - 「あそこで少し立ち止まっていましたが、何が気になりましたか？」（観察した転換点を具体的に指す） - 「普段と違う行動をとった場面はありましたか？」 - 「一番困った瞬間はどこでしたか？」 - 「一番自然にできた部分はどこですか？」 デブリーフィングで得た語りは「事後的な解釈」であることを記録しておく。行動と語りを対比させると、さらに深いインサイトが浮かぶ。 分析——観察データからインサイトへ 観察データを構造化する 観察メモを「時系列ログ」と「転換点リスト」の2つに整理する。時系列ログは行動の全体の流れを把握するためのもの、転換点リストは深掘りすべき箇所を特定するためのものだ。 カスタマージャーニーマップへの統合 シャドーイングで得た観察データは、カスタマージャーニーマップの「行動（Actions）」と「感情（Emotions）」レイヤーを埋める最も信頼性の高い材料となる。インタビューによる「言語データ」と観察による「行動データ」を両者並べると、ジャーニーマップの解像度が格段に上がる。 特に、感情の谷（感情曲線が下がるポイント）とシャドーイングで観察した「転換点」が重なる箇所は、最も優先度の高いデザイン問題の候補だ。 エンパシーマップとの接続 シャドーイングで得た「していること（Do）」と「感情の外的サイン（Feel）」は、エンパシーマップの Do と Feel の象限を事実データで埋める。Think の象限（推察部分）は、デブリーフィングで得た語りと観察した行動から仮説として書く。 よくある失敗と対処 観察者が存在感を出しすぎる 観察者が近すぎる・カメラを向けすぎる・メモ取りが目立つと、対象者の行動が変容する。できる限り自然な距離・目立たない記録方法を選ぶ。スマートフォンのメモアプリは紙のノートよりも自然に見える場面が多い。 「観察」が「解釈」になる 「対象者は迷っていた」ではなく「対象者は45秒間、右と左を交互に見た後、左に進んだ」と記録する。解釈は分析フェーズで行い、現場では事実の記述に徹する。 リサーチクエスチョンなしに観察する 「面白いことを見つけよう」という姿勢では、何が重要な観察かの判断ができない。事前に「何を知りたいか」を1〜3文で明確にしてから現場に入る。 データ収集で終わる 観察で得た転換点リストをエンパシーマップやカスタマージャーニーマップへの入力まで接続しないと、観察は記録で終わる。分析セッションを観察翌日以内に設定し、洞察を問題定義に向けて変換する。 ポイント - 同意と倫理を最優先 — 対象者の明示的な同意なくして観察は開始しない - 距離と非干渉を守る — 観察中の質問・干渉はデータを汚染する。転換点は後のデブリーフィングで深掘りする - 行動を事実として記録、解釈は後で — 現場メモは動詞と時刻で書く。評価や解釈は分析フェーズに回す - 転換点を見逃さない — 立ち止まり・引き返し・助けを求める行動は最重要の観察対象 - インタビューと組み合わせる — 観察データ単独では内部状態がわからない。デブリーフィングと観察の組み合わせで行動と思考の両軸を得る - カスタマージャーニーマップへ統合する — 観察データの最終到達点はジャーニーマップの行動・感情レイヤー --- 参考文献 - Jan Blomkvist & Stefan Holmlid, "Service Prototyping According to Service Design Practitioners", Proceedings of the 2nd Nordic Conference on Service Design and Service Innovation, 2010 - Marc Stickdorn & Jakob Schneider, This is Service Design Thinking, BIS Publishers, 2011 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Lucy Kimbell, The Service Innovation Handbook, BIS Publishers, 2014 - Nielsen Norman Group, "Shadowing in User Research — Do You See What They See?", nngroup.com 関連記事: カスタマージャーニーマップ / エンパシーマップ / ユーザーインタビュー / 共感フェーズ / サービスサファリ --- ### シンクアラウド・プロトコル — ユーザーの思考を声にするテスト手法 URL: https://designthinking.studio/methods/think-aloud-protocol/ > ユーザーが操作中に思っていることをそのまま口に出してもらう「発話思考法」の理論と実践手順を解説。Concurrent TAP・Retrospective TAP の使い分け、ファシリテーションの失敗パターン、AI録画ツールとの組み合わせ方まで体系的にまとめる。 ユーザビリティテストを実施した後、チームが最初に直面する問いがある。「なぜユーザーはそこで詰まったのか」だ。 行動ログには「ボタンAをクリックせず、ボタンBを3回クリックした」と記録される。しかしそこに至るまでユーザーの頭の中で何が起きていたかは、行動だけを観察していても分からない。シンクアラウド・プロトコル（Think-Aloud Protocol）は、この「観察できない思考の過程」を言語として記録する手法だ。 --- シンクアラウド・プロトコルとは シンクアラウド・プロトコル（TAP）は、ユーザーがタスクを実行しながら頭に浮かんだことをそのまま声に出してもらう調査手法だ。「発話思考法」とも呼ばれる。 理論的な基盤を提供したのは、心理学者の K. Anders Ericsson と Herbert A. Simon である。1980年に彼らが構築した口述報告のプロセスモデル（"Verbal Reports as Data", 1980, Psychological Review）は、人間が思考を言語化するメカニズムを認知科学的に解明し、TAP の信頼性を支える根拠となった。Ericsson と Simon のモデルは、人が短期記憶から情報を引き出すときに言語化が比較的自然に行われることを示し、適切な条件下では思考の発話が認知プロセスを大きく歪めないと論じた。 ユーザビリティ領域では Jakob Nielsen が 1990 年代から強力に推進し、現在もコスト対効果の高い定性調査手法として広く使われている。 --- 2種類のTAP：ConcurrentとRetrospective TAP には実施タイミングが異なる2つのバリアントがある。 Concurrent TAP（同時発話法） タスクを実行しながらリアルタイムで発話を続ける。思考と行動が同時進行するため、認知的な負荷が高い。しかしその瞬間の思考が記録されるため、データの鮮度が高いのが最大の強みだ。 主な特徴： - データ収集効率が高い（タスクと発話が1セッションで完結） - 発話に注意が向くことでタスクパフォーマンスが変化する可能性がある - ファシリテーターがリアルタイムで沈黙を拾いやすい Retrospective TAP（回想発話法） タスクを一通り終えた後、録画を見返しながら「このとき何を考えていたか」を語ってもらう。認知的負荷が低く、タスク中の自然な行動が保たれる利点がある。一方で、記憶の再構成が起こりやすく、発話がタスク完了後の合理化になるリスクがある。 | 観点 | Concurrent TAP | Retrospective TAP | |---|---|---| | 発話タイミング | タスク実行中 | タスク完了後 | | 認知的負荷 | 高い（二重タスク） | 低い | | データの鮮度 | 高い | 低い（記憶の再構成） | | 推奨場面 | UIのマイクロインタラクション検証 | 複雑な操作フローの全体把握 | どちらが優れているかという問いより、検証したいインサイトの種類で選ぶのが実態に近い。 --- 実施手順 Step 1：タスクシートの設計 タスクシートはTAPの品質を決める最重要要素だ。ユーザーにどのシナリオを実行してもらうかを、具体的で自然な文脈として書く。 良いタスクの条件： - 「〜してください」という指示形ではなく、「あなたは〜の状況にいます。〜を探しています」という状況文として書く - 正解の手順を含意しない中立的な文体にする - 1タスク30分以内に完了できるスコープに絞る 悪い例：「ナビゲーションメニューからカートに商品を追加してください」 良い例：「誕生日プレゼントとしてブルーのマグカップを購入しようとしています。購入手続きを完了してください」 Step 2：イントロダクション（事前説明） セッション開始前の説明が、その後の発話量を左右する。ユーザーに伝えるべきことは2つだ。 「製品のテストであり、あなたの能力のテストではない」 という点と、「間違えることも含めて、すべての思考を声に出してほしい」 という点だ。 多くのユーザーは、「正しい答えを言わなければ」「賢く見せなければ」という意識から発話を抑制する。この意識を緩めるためには、ファシリテーター自身がまず練習セッションを1〜2分やって見せると効果的だ。「例えばこんな感じで、コーヒーを入れながら声に出してみます」という自己実演が、ユーザーの心理的ハードルを下げる。 Step 3：タスク実行と発話の促進 タスク実行中、ファシリテーターの役割は最小限の介入で発話を維持することに絞られる。 沈黙が30秒以上続いたら、「今どのようなことを考えていますか?」と中立的に問いかける。「なぜそのボタンをクリックしましたか?」という過去形の問いかけは、行動への介入になるため避ける。 誘導しない問いかけの例： - 「今考えていることを教えてください」 - 「声に出し続けてもらえますか」 - 「今どこを見ていますか」（視線追跡なしの場合） 誘導になる問いかけの例（避ける）： - 「分かりにくかったですか?」 - 「このボタンは見つけにくかったですか?」 - 「何か探していましたか?」 Step 4：データ記録 録音・録画に加え、ファシリテーターまたは記録係が以下を手書きでメモする。 - タスク完了時間（秒単位） - タスク成功・失敗・部分成功の判定 - 発話した具体的な言葉（特に感情を示す言葉） - 行動と発話の不一致（「簡単です」と言いながら3回間違えるなど） 記録係がいない場合は録画に徹し、分析は後から行う。セッション中に「これは重要なインサイトだ」と解釈まで踏み込まない。解釈は分析フェーズで行う。 Step 5：デブリーフ（セッション後ヒアリング） タスク完了後、5〜10分のデブリーフで補足情報を収集する。Concurrent TAP の場合、発話を意識していたことで「言えなかった思考」が存在する可能性がある。 有効な質問： - 「今日体験した中で、最も印象に残ったことはどこですか?」 - 「もし友人に使い方を教えるとしたら、どこで詰まりそうだと思いますか?」 - 「全体を通じて、うまくいったと感じた部分はどこですか?」 --- 分析：インサイトの抽出 録画の書き起こしとタグ付け 録画を書き起こしたテキストに対して、以下のカテゴリでタグを付ける。 | カテゴリ | 例 | |---|---| | 混乱・困惑 | 「えっ、これ何?」「どこにあるんだろう」 | | 期待の不一致 | 「ここをクリックすると戻ると思った」 | | 正の反応 | 「あ、これ便利」「なるほど」 | | 仮説・推測 | 「たぶんここかな」「いつもはこうするから」 | | 諦め・回避 | 「もういいや、別の方法でやります」 | 同じカテゴリの発話が複数のユーザーに見られる場合、それは設計上の構造的な問題である可能性が高い。 アフィニティダイアグラムとの組み合わせ 複数ユーザーのTAPデータを統合する際は、アフィニティダイアグラムが有効だ。発話の書き起こしを付箋に転記し、類似パターンでグルーピングすることで、個別の発言から「繰り返し現れるテーマ」を浮かび上がらせる。 --- よくある失敗パターン 失敗1：沈黙に耐えられず誘導してしまう ファシリテーターが沈黙を埋めようとして「難しかったですか?」と聞く。これは観察ではなく誘導だ。沈黙はユーザーが考えている証拠であり、データの一部だ。30秒を目安に、中立的な促しのみを行う。 失敗2：ユーザーの意見を「修正」しようとする 「実は、このボタンはこういう意味なんです」と説明してしまうケースがある。TAPのセッション中にプロダクトの使い方を教えてはならない。ユーザーの誤解こそが設計上の問題を示すデータだ。 失敗3：発話の質よりタスク完了を優先する 「タスクを最後まで完了してもらう」ことが目的になり、発話が止まってもそのまま進めてしまう。TAPのゴールはタスク完了ではなく、思考プロセスの記録だ。発話が止まったら、タスクを中断してでも声に出す習慣を取り戻してもらう。 失敗4：分析を「印象」で終わらせる 「全体的に使いにくそうだった」という印象で報告を終わらせる。TAPデータは、発話した具体的な言葉と、それが発生したタスクの場面・タイミングとセットで扱わなければ、設計改善に直接結びつかない。「Step 3のドロップダウン選択時に、4名中3名が『どこにあるのか分からない』と発話した」という粒度で記録する。 --- ユーザビリティテストの他手法との位置づけ | 手法 | 測定対象 | TAPとの関係 | |---|---|---| | Desirability Testing | 感情的印象・審美的評価 | 補完：TAPで操作性を、DTで印象を測る | | Test Card 実験設計法 | 仮説の反証可能性 | 前後関係：テストカードでTAPの設計を構造化できる | | ヒューリスティック評価 | UIの原則違反 | 代替：専門家レビューでユーザーテストを削減できるが、実際の発話は代替不可 | | アイトラッキング | 視線移動・注視点 | 組み合わせ：TAPに視線データを加えると思考と視線の対応が分析できる | --- AI録画ツールとの組み合わせ Otter.ai・Notion AI・Fireflies など、発話の自動書き起こしと要約機能を持つツールを使うと、録画からインサイト抽出までの時間が大幅に短縮できる。特に英語での実施ではこれらのツールの精度が高い。 日本語での利用では、書き起こしの誤変換が分析を誤らせるリスクがある。自動書き起こしをそのまま分析に使わず、重要な発話は必ず手動で確認することが原則だ。 ただし、ツールに依存しすぎると「要約されたインサイト」が生成される一方で、「ユーザーが実際にどの言葉を使ったか」という生のデータが失われる。TAP の価値は、設計者が想定しなかった言語でユーザーが語る瞬間にある。ツールはその記録を補助するものであり、分析を代替するものではない。 --- まとめ シンクアラウド・プロトコルは、ユーザーの行動の背後にある思考を記録する最も直接的な手法だ。特別な機材も不要で、スマートフォンの録画と適切なタスクシートがあれば実施できる。初期フェーズのプロトタイプ検証から完成品の最終確認まで、幅広い段階で使える。 重要なのは、ユーザーの発話を「フィードバック」として解釈しないことだ。「使いにくい」という発言は意見ではなく、設計の構造的な問題が引き起こした認知的な摩擦の証拠だ。その発言がどのタスク・どの操作ステップで生じたかと組み合わせて初めて、改善のための情報になる。 TAPで収集したデータは、次の設計サイクルの問いを立てる材料になる。「なぜそこで詰まったのか」への答えを持って、チームは問題定義フェーズに戻ることができる。 --- 関連手法 - Desirability Testing とユーザー検証完全ガイド — 感情的印象の検証へ - テストカード実験設計法 — 仮説の構造化と検証設計 - アフィニティダイアグラム — 発話データのグルーピングと統合 --- ### ステークホルダーマッピング URL: https://designthinking.studio/methods/stakeholder-mapping/ > プロジェクトや課題に利害関係を持つすべての人・組織を可視化し、誰の視点を設計に組み込むべきかを特定するフレームワーク。define・empathizeフェーズの出発点として機能する。 ステークホルダーマッピングは、プロジェクトや課題に関わる「すべての利害関係者」を可視化し、誰が何をステークとして持っているかを整理するフレームワークです。 デザイン思考において「誰のために設計するか」を決めることは、すべての出発点です。しかし多くのプロジェクトでは、最も声が大きいステークホルダー（=発注者や上司）の視点だけが「ユーザー」として扱われ、本来影響を受けるはずの関係者が見落とされます。ステークホルダーマッピングは、この「見えていないステーク」を体系的に発掘する作業です。 概要 共感フェーズでは「誰に共感するか」を決める前に、「共感すべき相手が誰なのか」を把握する必要があります。ステークホルダーマッピングはその前提作業として機能します。 同時に問題定義フェーズにおいても、「誰にとっての問題か」を明確にするための座標軸として使われます。発見されたペインポイントが「誰のペインポイントなのか」を問い続けることが、POVステートメントの精度を高めます。 特に組織・サービス・政策のような複雑なシステムを設計対象とする場合、ステークホルダーの多様性を可視化しないまま進むと、設計の後半で「この人たちのことを考えていなかった」という盲点が露出します。前半で時間をかけてマッピングするほど、後の設計判断が速くなります。 実施の手順 ステップ1：課題の中心を定義する 模造紙またはホワイトボードの中央に、対象となる「課題」「製品」「サービス」「政策」を書いた付箋を貼ります。 これがマッピングの原点です。 この時点で課題の定義が曖昧でも構いません。「誰が関係するか」を考える作業が、逆に課題の輪郭を明確にすることがあります。 ステップ2：ステークホルダーをブレインストーミングする チーム全員が付箋を使い、「この課題に何らかの形で関わる人・組織」を書き出します。最初は「明らかにステークホルダーではない」を判断せず、思いつく限りを出し切ります。 典型的なカテゴリとして次を念頭に置くと漏れが減ります。 - 直接的エンドユーザー：製品・サービスを実際に使う人 - 間接的影響を受ける人：使わないが影響を受ける周囲の人（家族、同僚など） - 提供側：サービスを届ける人（現場スタッフ、販売チャネルなど） - 意思決定者：承認・予算・制度の権限を持つ人 - 規制・監督者：法規制、業界基準、監査などを担う機関 - 競合・代替：ユーザーが選ぶかもしれない別の選択肢 - 周辺の受益者・損害者：直接関係ないが、結果によって得をする・損をする主体 社会インフラや公共サービスの設計では、この最後の「周辺の受益者・損害者」に非常に重要なステークが潜むことがあります。 ステップ3：影響度 × 関与度で分類する 付箋を2軸のマトリクス上に配置します。 - 縦軸：影響度（このプロジェクトの結果から、どれだけ大きな影響を受けるか） - 横軸：関与度（このプロジェクトに、どれだけ積極的に関与・発言できるか） この4象限で分類すると、次のパターンが見えます。 | 象限 | 特徴 | 対応 | |------|------|------| | 高影響・高関与 | 最重要ステークホルダー。声が大きい | 最優先でリサーチ・対話 | | 高影響・低関与 | 「見えないステークホルダー」 最も見落とされやすい | 積極的にリーチする | | 低影響・高関与 | 影響は小さいが声が大きい。プロセスに口出しする | 情報共有・巻き込み | | 低影響・低関与 | 現時点での優先度は低い | モニタリングに留める | 最も設計への貢献が大きいのは、「高影響・低関与」の象限に隠れたステークホルダーの発掘です。声が小さい、組織化されていない、リテラシーが低い、地理的に遠い、などの理由でプロセスから排除されがちな人々が、この象限に集まります。 ステップ4：ステークの内容を深める 各ステークホルダーが「何を」ステークとして持つかを付箋で補足します。ステークの種類は次のカテゴリで整理できます。 - 機能的ステーク：製品・サービスが実際に動くことへの関心 - 経済的ステーク：コスト、収益、リスクへの関心 - 感情的ステーク：安心感、信頼、尊重されること - 権力的ステーク：意思決定権、情報へのアクセス、影響力の維持 - 価値的ステーク：倫理、文化、アイデンティティとの一致 同じ「顧客」というラベルでも、Aは「時間を節約したい（機能的）」でBは「自分の選択を尊重されたい（感情的）」というように、ステークの内容は大きく異なります。この違いを解像度高く把握することが、後のユーザーインタビュー設計に直結します。 ステップ5：リサーチ優先順位を決める マップが完成したら、「次に誰のリサーチをするか」の優先順位を付けます。全員にインタビューする時間はない。誰から始めるかを決める根拠として、このマップを使います。 一般的な優先順位の基準： - 高影響・低関与のステークホルダー（見落としリスクが高い） - チームの前提が最も薄い相手（「わかったつもり」の危険が高い） - 設計の成否を最も左右する人（ゲートキーパーや最終意思決定者） テンプレート解説：同心円モデル 2軸マトリクスに加えて、同心円モデルも広く使われます。 中心に「課題/製品」を置き、内側の円から外側へと距離を持ってステークホルダーを配置します。 - 最内円（コア）：日常的に直接関わる主要ユーザー - 中間円（サポーター）：間接的に関わる支援者・管理者 - 外円（周辺）：影響を受けるが関わりが薄い主体、規制機関、社会全体 同心円モデルは「誰が最も中心に近いか」を空間的に議論するのに向いており、チームの認識のズレを可視化するのに役立ちます。「私はこの人を内円に置いたが、あなたは外円に置いた。なぜか？」という議論が、課題の前提共有を深めます。 適用場面 ステークホルダーマッピングが特に威力を発揮するのは次の場面です。 複数部署が絡む社内プロジェクト 「誰がこの変更の影響を受けるか」を明確にしないまま進むと、実装段階で反対が起きます。マッピングにより、早期に関係者を特定してプロセスに巻き込めます。 BtoBサービスの設計 発注企業の担当者（バイヤー）、実際の使用者（エンドユーザー）、承認権者（CFO・CIO）、IT管理者（インストール・管理担当）は、それぞれ異なるステークを持ちます。4者を同一に扱うと設計がどこかで必ず食い違います。 行政・公共政策 市民、事業者、行政職員、議会、NPO、メディアが複雑に絡み合います。特に「政策の影響を最も受けるが、最も声を持たない」層の発掘にこの手法が有効です。 システム変更・DXプロジェクト 新システムの導入は「システムを使う人」だけでなく、「旧来のプロセスに依存している人」「データの管理権限を持っている人」「外部連携先」など多様な関係者を巻き込みます。 よくある失敗と対処法 発注者・上司だけがステークホルダーになる 最も頻繁に起きる失敗です。「プロジェクトを依頼した人＝ステークホルダー」という思い込みが、他の重要な関係者を見落とさせます。「この変更が実際に誰の日常を変えるか」という問いで付箋を出し直すと、盲点が見えやすくなります。 ステーク（内容）ではなく役職で整理する 「経営者」「マネージャー」「エンジニア」という役職の列挙は、ステークホルダーマップではありません。「この人が何を得たい/失いたくないか」を書かないと、設計の参照点になりません。 役職名の下に必ずステークの内容を付箋で補足します。 マップで終わる 作ったマップをリサーチ計画や設計判断に接続しないと、壁の飾りになります。セッションの最後15分でリサーチ優先順位を決め、次のアクションを具体化します。 ポイント - 「影響を受けるが声を持たない人」に意識を向ける — 最も設計から取り残されやすい人たちがここにいる - ステーク（内容）まで書く — 役職名の列挙は出発点に過ぎない。何を求めているかまで深める - チームで作る — 1人の視点では必ず死角が生まれる。多様な部署・背景のメンバーで実施する - 更新する — プロジェクトが進むにつれてステークホルダーの構成は変わる。マップは生きたドキュメントとして定期的に見直す - リサーチ計画へ橋渡しする — マップの完成がゴールではない。ユーザーインタビューの対象と優先順位を決めるために使う ステークホルダーマップで明確になった「誰のために」を基点に、エンパシーマップやカスタマージャーニーマップへと進みます。問題定義フェーズにおけるPOVステートメントの精度は、この初期マッピングの質に大きく依存します。 --- 参考文献 - Mager, Birgit & Sung, Tung-Jung, "Special Issue Editorial: Designing for Services", International Journal of Design, Vol. 5, No. 2, 2011 - Donella Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008 - Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### ストーリーボード URL: https://designthinking.studio/methods/storyboard/ > ユーザーがプロダクトやサービスを体験する流れを、コマ割りのイラストで視覚化する手法。プロトタイプの前段階で、体験全体の設計を検証する。 ストーリーボードは、ユーザーの体験をコマ割りのイラストで時系列に描く手法です。映画やアニメーションで使われてきたこの手法は、プロダクトやサービスの体験設計にも効果を発揮します。 概要 プロトタイプを作る前に、ユーザーがどんな状況で、何をきっかけに、どのように行動し、何を感じるのかを1枚の紙で俯瞰できるのがストーリーボードの強みです。画面単位のワイヤーフレームでは見えない「体験の文脈」を可視化できます。 デザインスプリントでは、火曜日のSketchフェーズでストーリーボード形式のソリューションスケッチが中核的な役割を果たします。描くのに画力は不要です。 棒人間と矢印とふきだしがあれば十分に伝わります。 実施の手順 ステップ1：シナリオを設定する まず、描くべきシナリオを決めます。「誰が、どんな状況から始まり、何を達成するか」を1〜2文で定義します。 例えば、「週末の旅行を計画中のユーザーが、アプリを使って現地の体験プランを予約する」というシナリオであれば、開始点（旅行を計画中）と終了点（予約完了）が明確です。 シナリオの設定には、POVステートメントやHow Might Weの問いを出発点にするのが効果的です。 ステップ2：キーモーメントを特定する シナリオの中で、ユーザーの行動や感情が変化する瞬間をリストアップします。これがストーリーボードの各コマになります。 典型的なキーモーメントは以下のようなものです。 - ユーザーが課題に直面する瞬間 - プロダクトに出会う瞬間 - 重要な操作や意思決定の瞬間 - 感情が変化する瞬間（困惑→安心、不安→確信など） - ゴールを達成する瞬間 6〜8コマに収めるのが実用的な範囲です。コマが少なすぎると体験の流れが伝わらず、多すぎると描くのに時間がかかりすぎます。 ステップ3：コマを描く A3用紙を6〜8等分するか、テンプレートを用意します。各コマには以下の要素を含めます。 - 場面の絵 --- 棒人間でよい。環境・状況が分かる最小限のビジュアル - 吹き出し/思考バブル --- ユーザーの発言や心の声 - ナレーション --- そのコマで起きていることの簡潔な説明 美しい絵を描く必要は全くありません。 重要なのは、チームメンバーや他のステークホルダーが「ユーザーの体験を時系列で追えること」です。15秒で描けるレベルのスケッチで十分です。 ステップ4：共有とフィードバック 描いたストーリーボードをチーム内で共有し、「このストーリーは現実的か？」「見落としている瞬間はないか？」を議論します。 特に注目すべきは、コマとコマの「間」です。ステップ2からステップ3に移るとき、ユーザーは実際にどう行動するのか。その移行が不自然な箇所は、体験設計上の課題が潜んでいる可能性があります。 ステップ5：プロトタイプへ発展させる 検証を経たストーリーボードは、プロトタイプの設計図として機能します。 どの画面が必要で、どんな操作フローになるかが、ストーリーボードから自然に導き出されます。 2つのアプローチ As-Is（現状）ストーリーボード ユーザーが現在どのように課題を解決しているかを描きます。ユーザーインタビューの結果を基に、既存の体験のペインポイントを可視化します。 To-Be（理想）ストーリーボード プロダクトやサービスを利用した場合の理想的な体験フローを描きます。As-Isで発見したペインポイントが、新しい体験でどう解消されるかを示します。 As-IsとTo-Beを並べることで、「何が変わるのか」が一目で分かります。 ステークホルダーへのプレゼンテーションにも効果的です。 よくある失敗と対処法 画面遷移だけを描いてしまう ストーリーボードがワイヤーフレームの連続になってしまうケースがあります。画面だけではユーザーの感情や文脈が抜け落ちます。 最初のコマは「ユーザーがスマートフォンを開く前の状況」から始めると、体験の文脈が豊かになります。 コマに情報を詰め込みすぎる 1コマに複数のアクションを詰め込むと、読み手が混乱します。1コマ=1アクションまたは1感情変化の原則を守ります。詰め込みたくなったら、コマを分割するサインです。 チーム内でしか通じない描き方 社内の専門用語やプロジェクト固有の略語を使いすぎると、外部のステークホルダーに伝わりません。初めて見る人が30秒で体験の流れを理解できるかを基準にチェックします。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、ストーリーボードが「アプリの画面遷移図」になってしまうパターンです。コマの中にスマートフォンの画面だけが描かれ、ユーザーの表情も状況も見えない。それはワイヤーフレームであってストーリーボードではありません。 実際にやってみると、最初のコマを「ユーザーが困っている場面」から始めるよう指定するだけで、劇的に質が上がります。 アプリを開く前に、なぜそのサービスが必要なのかが描かれると、見た人全員がユーザーの文脈を共有できます。この「文脈から始める」習慣がつくと、ストーリーボード全体の説得力が変わります。 ポイント - 画力は不問 --- 棒人間と吹き出しで十分。大切なのは体験の流れが伝わること - 感情を描く --- ユーザーの表情（笑顔、困惑、安堵）がストーリーに命を吹き込む - 文脈から始める --- プロダクトに触れる前の状況を描くことで、体験のリアリティが増す - 6〜8コマ --- 多すぎず少なすぎない、実用的な範囲で収める - 捨てる覚悟を持つ --- ストーリーボードは叩き台。フィードバックを受けて描き直すことを前提にする Crazy 8sでスケッチしたアイデアを発展させる際に、ストーリーボードは自然な次のステップになります。 --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint, Simon & Schuster, 2016（火曜日のStoryboard Sketchセクション） - Bill Verplank, "Interaction Design Sketchbook", Bill Verplank's Design Notes, 2009 --- ### ダブルダイヤモンド—発散と収束の4フェーズで問題を正しく解く URL: https://designthinking.studio/methods/double-diamond/ > Design Council UKが体系化したダブルダイヤモンドの4フェーズ（Discover・Define・Develop・Deliver）を解説。発散と収束の構造、IDEO5ステップ・Design Sprintとの違い、日本企業への適用まで実践的に紹介。 「解決策を考える前に、正しい問題を見つけること」——この原則はデザイン思考の文脈で繰り返し語られます。けれど実際に現場でこれを構造として実行できている組織は、想像以上に少ない。 ダブルダイヤモンドは、この原則を「見える形にしたフレームワーク」です。問題空間と解決空間を明確に分離し、それぞれの中で発散と収束のリズムを踏む。この構造を視覚化したことで、英国Design Councilが2004年に発表し2005年に体系化した同モデルは、世界中のデザイナーとビジネスパーソンに使われ続けています。 ダブルダイヤモンドとは——Design Council UKの4フェーズモデル ダブルダイヤモンドは、英国Design Councilが2004年に発表し、2005年の調査報告書 "A Study of the Design Process" で体系化したデザインプロセスモデルです。Alessi、BSkyB、BT、LEGO、Microsoft、Sony、Starbucks、Virgin Atlantic Airways、Whirlpool、Xerox、Yahoo!——11グローバル企業のデザイン部門を対象とした定性調査を基盤に、優れたデザインプロセスに共通する構造を抽出したものです。 この調査は後に "Eleven Lessons: Managing Design in Eleven Global Brands"（2007年）としても刊行されています。 モデルの名称が示すように、形状は2つのダイヤモンド（菱形）が横に並んだ構造を取ります。左のダイヤモンドが「問題空間」、右のダイヤモンドが「解決空間」です。4つのフェーズはそれぞれのフェーズ頭文字から「4Dモデル」とも呼ばれます。 | フェーズ | 空間 | 動き | 問い | |---|---|---|---| | Discover（発見） | 問題空間 | 発散 | 何が起きているのか？ | | Define（定義） | 問題空間 | 収束 | 本当の問題は何か？ | | Develop（開発） | 解決空間 | 発散 | どんな解決策があるか？ | | Deliver（提供） | 解決空間 | 収束 | 何を実装するか？ | なぜ「2つのダイヤモンド」なのか——発散と収束の構造 ダブルダイヤモンドが他のフレームワークと一線を画す理由は、「問題を決める前に解決策を考えてはならない」という制約を、構造として明示していることにあります。 ほとんどの問題解決プロセスは、問題が与えられた段階から始まります。「売上が下がっている→どうすれば回復するか」という流れで、解決策の検討にすぐ入ります。しかし実際のプロジェクト現場では、最初に提示される「問題」そのものが誤っていることが珍しくありません。 たとえば「ウェブサイトのコンバージョン率を上げたい」というオーダーで始まったプロジェクトが、ユーザーリサーチの結果「そもそも商品自体のポジショニングが合っていない」という根本的なズレを発見する——これはよくある展開です。第1ダイヤモンドなしに第2ダイヤモンドに入っていたら、間違った問題に対して正しい解決策を作り続けることになります。 「発散→収束」を2回繰り返すリズムも、このフレームワークの核心です。発散とは「多様な情報・視点・アイデアを集める」動き、収束とは「優先順位をつけ、選択する」動きです。問題空間と解決空間のそれぞれで、この2つのリズムを踏むことで、思い込みではなくエビデンスに基づいた問題定義と解決策設計が可能になります。 Phase 1: Discover（発見）——問題空間を広げる Discoverフェーズは、「自分たちが問題だと思っていることが、本当に問題かを疑うことから始まる」フェーズです。課題を取り巻く状況・ユーザーの行動・文脈を広く探索し、多様な視点と情報を収集します。 このフェーズで最も重要な構えは「知らないことを知る」姿勢——チームが持っている仮説を一時的に脇に置き、フィールドに出て一次情報を集めることです。 インタビュー——表層の言葉の奥へ 半構造化インタビューは、Discoverフェーズの中核的なリサーチ手法です。事前に主要な問いを設定しつつ、会話の流れに応じて深掘りするスタイルで行います。重要なのは、回答を分析しながら聞くのではなく、まず「聞くこと」に徹することです。 「なぜそうしているのですか？」という問いへの最初の答えは、多くの場合社会的に期待される回答です。「なぜ？」を3〜5回繰り返すことで、行動の背後にある本当の動機が現れ始めます。 インタビュー中に「それは予想していなかった」と感じた瞬間こそ、最も価値あるデータです。 観察とシャドーイング——言葉にならない行動を見る インタビューで語られることと、実際の行動は一致しないことがよくあります。観察（フィールドリサーチ）は、ユーザーが自覚していない行動パターンや環境の影響を見るための手法です。 シャドーイングは、許可を得てユーザーの日常行動に同行する手法です。実際にやってみると、「インタビューでは〜と言っていたのに、実際は真逆の行動をしていた」という発見がよく生まれます。この「言葉と行動のギャップ」に、最も価値あるインサイトが隠れています。 デスクリサーチと量的データ 一次リサーチと並行して、既存の調査レポート、競合分析、統計データなども幅広く収集します。フィールドで観察した個別の事例が、量的データの傾向と照合されたときに初めて「インサイト」としての信頼性が上がります。 Phase 2: Define（定義）——問題を絞り込む Defineフェーズは、Discoverで集めた大量の情報を整理し、「本当に解くべき問題」を1〜2文で定義するフェーズです。発散から収束へ——この転換点はダブルダイヤモンド全体の中で最も意思決定の密度が高い場所です。 親和図法でインサイトを構造化する インタビュー・観察・デスクリサーチで集まった情報は、まず親和図法（Affinity Diagram）で整理します。付箋1枚に1つの観察事項を書き、類似したものをグルーピングしていくプロセスで、個別の事実が「傾向」や「パターン」へと昇格します。 グルーピングの段階でチームメンバーが「あ、それって私のインタビューでも出てきた」という連鎖反応が起きる——この交差点が「インサイト」の候補です。 POVステートメント——問題定義の形式 Defineフェーズのアウトプットは、POVステートメント（Point of View Statement）と呼ばれる問題定義文です。d.schoolの形式を借りると、「[ユーザー像] は [ニーズ] を必要としている。なぜなら [インサイト] だから」という構造で記述します。 優れたPOVステートメントは、解決策の方向を決めずに問題の本質を示します。「高齢ユーザーは読みやすいフォントを必要としている」は解決策を含んでいます。「高齢ユーザーは情報の信頼性を確かめる手段を必要としている。なぜなら、画面上の情報の真偽を判断する基準を持っていないから」という形が、より良い問題定義です。 "How Might We"——問いに変換する POVステートメントを、How Might We（HMW）の問いに変換することで、次のDevelopフェーズへの橋渡しができます。「どうすれば〜できるだろうか？」という問いの形式は、問題の記述を可能性の探索へと転換します。 Phase 3: Develop（開発）——解決空間を広げる Developフェーズは、Defineで絞り込んだ問いに対して、多様な解決策のアイデアを大量に発想するフェーズです。解決空間における「発散」の段階に当たります。 アイディエーションの原則 アイディエーション（発散的思考）のセッションでは、「量を優先する」「判断を保留する」「他者のアイデアに乗る」という基本原則を守ります。最初の20分で出るアイデアは、すでにチーム全員が知っているものです。 本当に新しいアイデアは、それを使い切った後に現れます。 ブレインストーミングの現場 声の大きな参加者のアイデアに引っ張られて、全員が似たような方向に収束してしまう——ブレストセッションでは頻繁に起きます。有効な対策がブレインライティング（各自が付箋にアイデアを書いてから共有する方式）と、Crazy 8s（8分間で8つのアイデアをスケッチする手法）の組み合わせです。 個人でアイデアを出してから共有するプロセスを挟むことで、発声力と発想力の分離が生まれます。実際にやってみると、普段の会議では発言しない参加者が最も鋭いアイデアを出してくることが多いです。 共創ワークショップ——ユーザーを巻き込む Developフェーズで見落とされがちだが効果が大きい実践が、ユーザー・顧客・エンドユーザーをアイデア発想のプロセスそのものに参加させる共創（Co-creation）です。チーム内のブレストで出たアイデアと、ユーザーと一緒に発想したアイデアでは、実装後の受容性が大きく異なります。 2時間のワークショップに数名のユーザーを招き、HMWを共有した上でアイデア出しを一緒に行う。このプロセスで生まれたアイデアは、「ユーザーが自分でも言語化できていなかったニーズ」に対応することが多いです。 Phase 4: Deliver（提供）——解決策を絞り込み実装へ Deliverフェーズは、Developで発散したアイデアを絞り込み、プロトタイプで検証しながら実装可能な解決策に仕上げるフェーズです。解決空間の収束段階です。 低忠実度プロトタイプから始める プロトタイプの目的は「完成品を作ること」ではなく、「アイデアを検証可能な形に外部化すること」です。紙とペンで描いたスケッチ（ペーパープロトタイプ）は、デジタルで作り込んだUIよりも多くの場合有効です。作るコストが低いため、フィードバックを受けても「もう変えたくない」という心理的抵抗が生まれにくいからです。 素材は何でも構いません。付箋、段ボール、マスキングテープ、PowerPoint——重要なのは「動く」「触れる」「体験できる」状態にすることです。 サービスのプロトタイプなら、社内のメンバーがロールプレイで「サービス提供者を演じる」ウィザード・オブ・オズ手法も有効です。 ユーザーテストとフィードバックループ プロトタイプができたら、実際のユーザーに体験してもらい、行動を観察します。 ここでの重要な構えは「仮説の証明」ではなく「想定外の発見」を目指すことです。 テストセッション中に観察すべきは「ユーザーが詰まる場所」と「予期しない使い方をする瞬間」です。上手くいかなかった場面の方が、上手くいった場面より多くを教えてくれます。 フィードバックを受けてプロトタイプを修正し、再びテストする——このイテレーションを素早く回すことがDeliver フェーズの核心です。 実装への接続 Deliverフェーズの終端は「完成」ではなく「実装可能な状態への到達」です。プロトタイプが一定の検証を経たら、開発・調達・組織的意思決定のプロセスへと接続する「ハンドオフ」が必要です。このハンドオフを設計しないと、精度の高いプロトタイプが完成しても実装に至らない「ポートフォリオの肥やし」になります。 Framework for Innovation（2019改訂版）との違い Design Councilは2019年、オリジナルのダブルダイヤモンドを発展させた"Framework for Innovation"（イノベーションのためのフレームワーク）を発表しました。4フェーズの基本構造は維持しながら、以下の4原則を追加したのが主な変更点です。 | 原則 | 内容 | |---|---| | Put People First（人間中心） | サービス利用者のニーズ・強み・意欲を起点に設計を始める | | Communicate Visually and Inclusively（視覚的・包摂的なコミュニケーション） | 問題とアイデアの共通理解をビジュアルで形成する | | Collaborate and Co-create（協働と共創） | 多様な関係者と協力し、他の実践から学ぶ | | Iterate, Iterate, Iterate（反復する） | 早期にエラーを発見し、リスクを抑え、アイデアへの確信を積み上げる | 2005年版が「何をどの順番でやるか（プロセス）」を示したものだとすると、2019年版は「なぜそのプロセスが機能するか（文化・組織・原則）」まで射程を広げたモデルと言えます。単発プロジェクトだけでなく、組織レベルでデザイン思考を定着させようとする文脈では、2019年版の4原則が強力な補助線になります。 IDEO 5ステップ・Design Sprint・デザイン思考との関係 ダブルダイヤモンドは、しばしばIDEOのデザイン思考5ステップやGoogleのDesign Sprintと混同されます。それぞれの位置づけを整理します。 | 観点 | ダブルダイヤモンド | IDEO 5ステップ | Design Sprint | |---|---|---|---| | 発祥 | Design Council UK（2004/2005） | IDEO / Stanford d.school（2000年代） | Google Ventures（2010年代） | | フェーズ/日程 | 4フェーズ（期間は可変） | 5フェーズ（Empathize / Define / Ideate / Prototype / Test） | 5日間固定 | | 最大の特徴 | 問題空間と解決空間の明確な分離 | 共感（Empathize）を独立フェーズとして強調 | 時間制約による意思決定の加速 | | 主な活用文脈 | サービスデザイン・政策デザイン | プロダクト開発・イノベーション教育 | スタートアップ・新機能検証 | | イテレーション | フェーズ間の往復を許容 | 5フェーズの反復を前提 | 1スプリント完結が基本 | | 適した組織規模 | 中〜大規模、行政・公共系 | スタートアップ〜大企業 | 小〜中規模チーム | 3つはそれぞれ独立したフレームワークではなく、互いに補完関係にあります。 ダブルダイヤモンドの第1ダイヤモンド（Discover + Define）は、IDEOの「Empathize + Define」とほぼ対応し、第2ダイヤモンド（Develop + Deliver）は「Ideate + Prototype + Test」に対応します。Design Sprintはダブルダイヤモンドの第2ダイヤモンドを5日間に圧縮したプロセスと見ることもできます。 「どれを使うか」より「なぜその構造が有効か」を理解することで、プロジェクトの性質に応じた使い分けが可能になります。 日本企業での適用 ダブルダイヤモンドの構造は、公開情報の範囲で複数の日本企業・組織での実践が確認できます。 製造業の新規事業開発では、既存製品の改良から「ユーザーの業務フロー全体の最適化」への問題定義の転換が繰り返し報告されています。このパターンは、Discoverフェーズで現場リサーチを丁寧に実施し、「製品の機能」ではなく「ユーザーの仕事の文脈」を理解したことで生まれます。「何を改善するか」より先に「何が本当の問題か」を問うフェーズへの投資が、問題定義のジャンプを可能にします。 行政・公共セクターでは、サービスデザインの手法としてダブルダイヤモンドが徐々に参照されています。2019年のDesign Council版が政策デザインへの適用を明示的に示したことで、デジタル庁や自治体のUX改善プロジェクトでの参照事例が増えています。行政の文脈での特徴は、ステークホルダーの多様性（市民・職員・政策立案者）を、Discoverフェーズで並行してカバーする必要がある点です。 コンサルティング・アドバイザリー企業では、クライアントへのデリバリープロセスそのものをダブルダイヤモンド構造で設計するアプローチが見られます。プロジェクト開始時に「私たちがあなたの問題だと思っているものを、一旦疑います」という合意を取ることで、第1ダイヤモンドへの正当な時間投資が可能になります。 ダブルダイヤモンド実践の落とし穴 第1ダイヤモンドの省略 最も頻度が高い失敗は、Discoverフェーズを簡略化してDefineから始めることです。「問題はすでにわかっている」「時間がない」という理由で、最初の発散フェーズを省略すると、残り3フェーズを通じて間違った問いに答え続けることになります。 実際にやってみると、第1ダイヤモンドを省略したプロジェクトは、Deliverフェーズの終盤で「そもそも、この問題で正しかったのか？」という疑問が噴出するケースが多いです。手戻りのコストは、プロセスの後半になるほど高くなります。 発散の不徹底 「1時間のブレインストーミングをやった」「アイデアが30個出た」という報告の裏側に、「最初の5分で全員が同じ方向のアイデアを出し、それを30個に増やした」だけというパターンが潜んでいることがよくあります。発散とは「方向の多様性」を増やすことであり、量を増やすことではありません。 ファシリテーターとしての対策は、「全員のアイデアに方向性の多様性があるか」を中間点でチェックすることです。似たアイデアが集まっていたら、「それとは正反対の方向は？」「まったく違うユーザー層に使ってもらうとしたら？」という問いで、強制的に視点を変えます。 収束の合意形成の難しさ DefineフェーズとDeliverフェーズは、どちらも「選択する」という収束の動きが必要です。選択には必ず「選ばれないもの」が生まれ、これがチーム内の摩擦や組織的な抵抗につながります。 有効な対策は、収束の基準を発散フェーズが始まる前に合意しておくことです。「私たちは何を優先するか（ユーザー体験か？技術的実現可能性か？コストか？）」という判断基準を先に決めておくと、収束の際の議論が「好み」から「基準への照合」に変わります。 フェーズ間の硬直化 ダブルダイヤモンドを「順番に進めなければならないウォーターフォール」として解釈すると、Defineフェーズで新たなユーザーリサーチが必要になっても「もうDiscoverは終わった」と戻れなくなります。フレームワークはプロセスの方向性を示すものであり、逆行を禁じるものではありません。 2019年版のFramework for Innovationが4フェーズを矢印ではなくサイクルとして描いているのは、この「往復」を明示的に許容するためです。「今、このフェーズにいる」という感覚を共有しつつも、必要であれば前のフェーズに戻る判断を恐れないことが、長期的にはプロジェクト品質を高めます。 明日のミーティングから使える1ステップ ダブルダイヤモンドの本格導入の前に、明日から試せる構造的な問いかけがひとつあります。 次のプロジェクトキックオフで、解決策の議論を始める前に「この問題が本当の問題かどうか、どうやって確認するか？」という問いを10分間チームに投げかけてください。 「問題は上から与えられた」「前回のプロジェクトで確認済み」——こうした返答が出てきた場合、第1ダイヤモンドへの投資を後回しにする空気がすでにチームに存在しています。この問いへの反応を観察するだけで、「自分たちがどのフェーズから始めているか」が可視化されます。 10分の問いかけが、プロジェクト後半での大きな手戻りを防ぐ最初の一手になります。問題定義への投資は、解決策の品質を担保する合理的な判断——それがダブルダイヤモンドの出発点です。 --- 参考文献 - Design Council, A Study of the Design Process ("The Double Diamond"), Design Council, 2005. [designcouncil.org.uk] - Design Council, "What is the Framework for Innovation? Design Council's evolved Double Diamond", designcouncil.org.uk, 2019（2022年改訂） - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016 - Stanford d.school, An Introduction to Design Thinking: Process Guide, Institute of Design at Stanford, 2010（改訂版2018） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### テストカード実験設計法 — Strategyzer Test Card を用いた仮説検証の構造化 URL: https://designthinking.studio/methods/test-card-experiment-design/ > Strategyzer 社の Test Card (テストカード) を活用した実験設計の標準手順を解説。仮説の言語化・検証方法の選定・成功と中止基準の事前明示・データソースの設計までを、テンプレ + 失敗事例 + Pass/Fail 基準の具体化で実務に落とし込む。 「テストカード」(Test Card) は Strategyzer 社が Value Proposition Canvas (VPC) と並んで提供する仮説検証ツールだ。1枚のテンプレートに 「仮説 / 検証方法 / 観測指標 / Pass-Fail 基準」を書き分け、組織内の検証実験を共通フォーマットに乗せる。 実験は「やった」「やらなかった」の二択ではなく、事前にどれだけ反証可能性 (Falsifiability) を設計したかで結果の質が決まる。テストカードは反証可能性の設計を強制するための器であり、確証バイアスを抑え込む構造を持つ。本稿は新規事業・プロダクトマネージャー・UXリサーチャーが、テストカードを業務プロセスに組み込む手順をまとめる。 --- なぜテストカードを使うのか — 3つの作用 作用① — 仮説を「反証可能な命題」に強制変換する 新規事業の現場で頻繁に観察されるのは、検証以前に 仮説自体が曖昧 という問題だ。「顧客はこの機能を欲しがる」「市場には需要がある」といった文は、反証可能な命題になっていない。テストカードのトップに置かれる "We believe that ..." 欄は、仮説を「主語 + 検証可能な動詞 + 定量的予測」に整える強制力を持つ。 作用② — 実験設計を「成功条件」と「中止条件」で挟み撃ちにする テストカードの中段にある "To verify that, we will ..." (検証方法) と最下部の "And measure ..." (測定指標) はセットだ。さらに "We are right if ..." (合格基準) を事前に書き込ませる構造により、「都合のいい結果が出るまで実験を続ける」確証バイアスを排除する。Eric Ries の Innovation Accounting や Steve Blank の Customer Development が前提とする検証文化と整合する設計だ。 作用③ — チーム間の認識ズレを物理的に可視化する テストカードは1仮説1枚で運用する。複数の仮説を同じ壁面に並べると、検証進捗・優先順位・依存関係が視覚化される。新規事業の意思決定会議で「いま我々はどの仮説の検証段階にいるか」が瞬時に共有できる状態は、組織の検証文化を成熟させる前提条件だ。 --- テストカードのフォーマット構造 Strategyzer 公式版のテストカードは1枚A4で、以下の5つのフィールドを持つ。 フィールド1: Hypothesis (仮説) "We believe that [TARGET CUSTOMER] will [DO THIS] because [REASON]." 例: 「我々は、中小企業の経理担当者が、月次決算の3営業日短縮を目的に、SaaS型の請求書OCRサービスに月額¥9,800を支払うと考える。なぜなら、現状の手入力作業に月20時間を費やしているからだ。」 ここで重要なのは、主語 (顧客セグメント)・動詞 (具体的な行動)・理由 (因果) の3要素が明示されることだ。「顧客が欲しがる」のような曖昧な動詞は禁止される。 フィールド2: Test (検証方法) "To verify that, we will [TEST METHOD]." 例: 「SaaS のランディングページを作成し、Facebook 広告で月額¥9,800の Pre-order ボタンへ100名の経理担当者を誘導する。」 検証方法は 時間制約とリソース制約の中で実行可能 でなければならない。「全国の経理担当者にアンケートを送る」のような実行不可能な計画は採用されない。 フィールド3: Metric (測定指標) "And measure [METRIC]." 例: 「ランディングページからの Pre-order ボタンクリック率と、メールアドレス登録率。」 測定指標は 客観的・定量的・第三者検証可能 であることが要件だ。「顧客の感触」「好意的フィードバック」のような主観指標は採用されない。 フィールド4: Criteria (Pass/Fail 基準) "We are right if [SUCCESS CRITERION]." 例: 「100名中、Pre-order ボタンクリックが15名以上、メールアドレス登録が5名以上。これを下回る場合、価格・ターゲット・価値提案のいずれかに重大な仮説誤りがあると判断し、ピボット検討に入る。」 合格条件と不合格条件を事前に書く ことが、テストカードの中核機能だ。「結果が出てから判断する」運用は、確証バイアスを呼び込む。 フィールド5: Data Reliability (データ信頼性) "Cost / Time / Data Reliability" 実験のコスト・時間・データ信頼性を3段階 (低・中・高) で記入する。信頼性の低い実験 (例: 少人数インタビュー) を高信頼の検証と誤認しないためのチェック機構だ。 --- 標準的な実施手順 (90分1サイクル) Step 1: 仮説の棚卸し (15分) VPC または Business Model Canvas を起点に、検証すべき仮説を全て付箋に書き出す。新規事業のフェーズでは、典型的に 「価値提案仮説」「顧客仮説」「チャネル仮説」「収益仮説」 の4種が存在する。それぞれを別色の付箋で分類する。 仮説の棚卸しの際には、Assumption Mapping との接続が有効だ。Assumption Mapping で「重要度 × 確実度」マトリクスに配置した仮説のうち、「重要度 高 × 確実度 低」 象限の仮説からテストカード化を進める。 Step 2: 優先仮説の選定 (10分) 棚卸しした仮説を全て検証することは不可能だ。事業の意思決定を左右する仮説 (Killer Assumption) から優先順位を付ける。具体的には「この仮説が偽だった場合、事業計画を根本から見直すか」を問う。Yes と即答できる仮説が最優先候補だ。 Step 3: テストカードの記入 (40分) 選定した上位3つの仮説について、テストカードのフィールド1-5を順番に埋めていく。ここで頻繁に発生する失敗が、「仮説と検証方法が論理的に接続していない」 ケースだ。例えば「顧客は月額¥9,800を払う」という仮説に対して「アンケートで購入意向を聞く」という検証方法は、購入意向と実購入の乖離 (Say-Do Gap) を考慮していない。 Pass/Fail 基準を書く段階で「数字が出ない」場合、それは仮説が定量化されていない証拠だ。仮説に戻って書き直す。 Step 4: 信頼性レビュー (15分) 完成したテストカードを他チームメンバーがレビューする。レビュアーは以下を点検する。 - 仮説は反証可能な命題か (「Yes」か「No」のどちらかが定量的に判定できるか) - 検証方法は仮説を直接検証しているか (Say-Do Gap の罠を回避しているか) - Pass/Fail 基準は事前に合意可能な閾値か (恣意的解釈の余地がないか) - データ信頼性のレベルは、意思決定の重みに見合うか レビュー後、テストカードを 「実行 / 修正 / 棄却」 のいずれかに振り分ける。 Step 5: 実行計画の合意 (10分) 「実行」に振り分けられたテストカードについて、担当者・期限・予算・レビュータイミングを明示する。Strategyzer のテンプレートには上記4項目を記入する欄が用意されている。 --- よくある失敗パターンと修正法 失敗① — Say-Do Gap を無視した検証設計 症状: 「顧客は月額¥9,800を払う」という仮説に対して、「アンケートで購入意向を聞く」検証を選ぶ。 修正: 実購入行動に近い検証 (Pre-order、有料ベータ、Letter of Intent) を採用する。アンケートの購入意向と実購入率には数倍〜10倍の乖離があることが繰り返し報告されている。 失敗② — Pass/Fail 基準の事後追加 症状: 検証を実行してから「思ったより反応が良くなかった」と感想を書き込む。 修正: テストカードを記入する段階で、Pass 条件 (例: 15%以上) と Fail 条件 (例: 5%未満) を明示する。中間ゾーンに落ちた場合の判断 (継続検証 / 仮説修正) も事前に決める。 失敗③ — 反証可能性のない仮説 症状: 「顧客は便利だと感じる」「市場に需要がある」のような曖昧な仮説をテストカード化する。 修正: 主語・動詞・対象・閾値を具体化する。「中小企業の経理担当者の30%が、月20時間以上の手入力作業を理由に、SaaSへ月¥9,800を支払う」のように、検証可能なレベルまで分解する。 失敗④ — 1枚のカードに複数仮説を詰め込む 症状: 「価値提案 + 価格 + チャネル」を同時に検証するカードを作る。 修正: 1カード1仮説の原則を守る。複合検証は失敗時の原因特定を不可能にする。複数仮説は別々のカードに分割し、検証順序を決める。 失敗⑤ — 信頼性レベルの自己評価バイアス 症状: 5人のインタビュー結果を「データ信頼性: 高」と評価する。 修正: サンプル数・サンプリング方法・観察期間を考慮して、保守的に評価する。「同じ結論を再現実験で確認できるか」を信頼性の基準にする。 --- VPCとの接続 — 検証ループの構築 テストカードは VPC とセットで運用するときに最大の効果を発揮する。具体的な接続フローは以下だ。 - VPC の右側 (顧客プロファイル) の各要素 (ジョブス・ペイン・ゲイン) を仮説として扱う - VPC の左側 (バリューマップ) の各要素 (製品・ペインリリーバー・ゲインクリエーター) を仮説として扱う - それぞれの仮説をテストカード化する - 検証結果に基づき VPC を更新する - 上記サイクルを四半期ごとに繰り返す このサイクルが組織プロセスに組み込まれているかが、VPC運用の臨界点だ。詳細は『バリュー・プロポジション・デザイン』深掘りレビューで扱った3つの失敗様式を参照されたい。 --- 実験ライブラリの選択基準 テストカードの「検証方法」フィールドに何を書くかは、実験ライブラリ からの選択になる。Strategyzer は44種類の実験を「コスト・時間・信頼性」の3軸で分類している。代表的な実験タイプを優先順位付きで整理する。 コスト低 × 信頼性中 - 顧客インタビュー (1-2時間 × 10-20名): ペイン・ジョブの存在確認に有効。Say-Do Gap には注意 - アンケート (ターゲットセグメント限定): 大規模リサーチ向き、購入意向は割引いて解釈 - ランディングページ + 広告誘導: 価値提案の魅力度測定に有効 コスト中 × 信頼性高 - ペーパープロトタイプ / クリッカブルプロトタイプ: 機能仮説の検証。詳細はPaper Prototyping 完全ガイド - Wizard of Oz テスト: 機能を人力で再現して検証。詳細はWizard of Oz プロトタイピング - Desirability Testing: 魅力度の言語化。詳細はDesirability Testing 完全ガイド コスト高 × 信頼性最高 - コンシェルジュ実験: 人力でサービスを提供して需要を確認 (Stripe, Airbnb の初期検証手法) - 有料ベータ / Pre-order: 実購入行動の検証。Say-Do Gap を排除できる最強の検証 - Letter of Intent (B2B): 企業顧客向けに有効、購入確約書を取得する 仮説の重要度と検証コストのバランスから、適切な実験を選定する。「重要度 高 × 確実度 低」の仮説には、コスト高 × 信頼性最高の実験を投じる判断が、新規事業の意思決定者には求められる。 --- 組織導入の留意点 留意点① — テストカードを「儀式化」させない 組織にテストカードを導入する際、最も警戒すべきは「形式だけ整える」運用だ。テストカードを書くこと自体が目的化し、Pass/Fail 基準が形骸化する。意思決定者がテストカードの結果を尊重し、Fail 結果でピボットを実行する文化的合意がない限り、テストカードは単なる紙切れに退化する。 留意点② — 「Fail を歓迎する」文化の併走 Pass/Fail 基準を機能させるには、Fail 結果を組織が歓迎する文化が必要だ。「失敗した実験」を罰する組織では、担当者は 「成功するように見える実験」だけを設計する。これは確証バイアスの組織的拡大であり、テストカードの存在意義を破壊する。組織変革の方法論についてはデザイン思考の組織導入失敗事例5選で扱った。 留意点③ — 検証コストの上限管理 新規事業の初期フェーズでは、検証予算の上限を事前に決める。「1検証あたり最大 [N] 円・[M] 日」 という制約を設定し、これを超える検証は意思決定者の追加承認を要件にする。コスト無制限の検証は、結果の質を上げず、組織を疲弊させる。 --- チェックリスト テストカードを実行する前に、以下のチェックリストで品質を担保する。 - [ ] 仮説が反証可能な命題になっている (Yes/No が定量判定できる) - [ ] 検証方法が仮説を直接検証している (Say-Do Gap を考慮) - [ ] Pass/Fail 基準が事前に明示されている (中間ゾーンの判断も) - [ ] 測定指標が客観的・定量的である (第三者検証可能) - [ ] データ信頼性レベルが保守的に評価されている (サンプル数・期間) - [ ] 1カード1仮説の原則を守っている (複合検証ではない) - [ ] 検証コストと意思決定の重みが釣り合っている - [ ] 担当者・期限・予算・レビュータイミングが明示されている このチェックリストを通過したテストカードのみを実行する規律が、新規事業の検証文化を成熟させる。 --- 参考文献 - Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value Proposition Design: How to Create Products and Services Customers Want. John Wiley & Sons. - Bland, D. J., & Osterwalder, A. (2019). Testing Business Ideas: A Field Guide for Rapid Experimentation. John Wiley & Sons. - Ries, E. (2011). The Lean Startup. Crown Business. - Blank, S., & Dorf, B. (2012). The Startup Owner's Manual. K&S Ranch. - Maurya, A. (2012). Running Lean: Iterate from Plan A to a Plan That Works. O'Reilly Media. - Strategyzer, "Test Card Template," https://www.strategyzer.com/library/the-test-card - Strategyzer, "Testing Business Ideas," https://www.strategyzer.com/library/testing-business-ideas --- ### ドット投票（Dot Voting） URL: https://designthinking.studio/methods/dot-voting/ > ドット投票は多数のアイデアを10〜20分で民主的に絞り込む収束ファシリテーション技法。シール配布数の目安（評価対象の20〜30%）、サイレント投票の手順、重み付き・レッドグリーン・デジタル版の3バリエーションを実践レベルで解説する。 ドット投票（Dot Voting）は、多数のアイデアや選択肢を短時間で民主的に絞り込むためのファシリテーション技法です。参加者それぞれが丸いシールや印を使って優先度を投票し、チーム全体の傾向を視覚的に把握することで、長い議論なしに収束を促します。 概要 ブレインストーミングで50個のアイデアが生まれた後、チームはどれを深掘りすべきか判断に困ります。この収束フェーズで最もよく起こるのは、発言力の強いメンバーの意見に引っ張られて、全員が納得していないまま進んでしまうことです。ドット投票は、全員の意見を同等に扱いながら、短時間で優先度を可視化するために設計されています。 ドット投票は1990年代のアジャイル開発コミュニティで広まり、現在はデザイン思考のワークショップ、プロダクトロードマップ策定、リトロスペクティブまで幅広く使われています。「多数決」に近い仕組みですが、議論なしに行われるため、特定の声に引っ張られにくいという特徴があります。 ステップ Step 1：評価対象を準備する 付箋やカードに書かれたアイデア、または課題リストをホワイトボードや壁に貼り出します。全員が読める大きさと位置に配置することが重要です。アイデアが多い場合（20個以上）は、事前に似た内容をグルーピングしておくと投票が行いやすくなります。 Step 2：シールを配布する 参加者全員に同数の丸いシール（または「・」の書き込み許可）を配ります。配布数の目安は、評価対象数の20〜30%です。アイデアが10個なら2〜3枚、30個なら5〜7枚が目安です。配布枚数は「希少性」を生み出し、真剣に選ばせる効果があります。 シールを複数種類用意することで、「最も重要」「実現可能性が高い」など複数の評価軸を同時に投票させる応用も可能です。デザインスプリントでは、ヒートマップ投票として類似手法が活用されています。 Step 3：サイレント投票を行う 投票は会話なしで行います。 参加者は自分のシールをアイデアに貼り付けます。サイレントで行うことで、他者の投票状況や声の大きさに影響されずに判断できます。全員が同時に投票するため所要時間は5分程度です。 Step 4：結果を確認し、議論する シールが多く集まったアイデアが「チームの関心が高いもの」として可視化されます。ただし、投票結果はあくまで発散から収束へのガイドであり、最終決定ではありません。 結果を見ながら「なぜこのアイデアが選ばれたか」「意外な結果はあるか」を短い議論（5〜10分）で補足します。 Step 5：アイデアを絞り込む 投票上位のアイデアを次のステップ（プロトタイプ検討、詳細化）に進めます。「上位3つ」のように具体的な数を事前に決めておくと、「もう1つ追加したい」というクリープが起きにくくなります。 バリエーション 重み付きドット投票 全シールを1枚ずつ分散させるのではなく、重要だと思うアイデアに複数枚のシールをまとめて貼ることを許可するルールです。3枚のシールをすべて1つのアイデアに賭けることができ、「強い支持」と「広い支持」が区別できます。 レッド・グリーン投票 緑シール（好き・実現したい）と赤シール（懸念・リスク）の2色を使い、アイデアへの賛否を同時に可視化します。多くのシールが集まりつつ赤も多い「高リスク・高関心」のアイデアは、深い議論を要するシグナルです。 デジタル版 リモートワークショップでは Miro、FigJam、MURAL などのツールの「投票」機能でドット投票を再現できます。 非同期での投票にも対応しており、時差のあるチームでも活用可能です。 ファシリテーションのコツ 投票前に「評価軸」を合意する 「好きなものに入れていい」という曖昧な指示では、評価基準がバラバラになります。「ユーザーにとって最も価値があると思うもの」「最も早く実験できるもの」など、投票前に1つの評価軸を全員に示すことで、投票の意味が揃います。 ファシリテーター自身は投票しない グループの意見を集約する立場のファシリテーターが投票に参加すると、影響力の非対称が生まれます。 ファシリテーターは投票結果の集計・可視化・議論の整理に集中しましょう。 「なぜ投票したか」を数人に聞く 投票後の振り返りで、上位アイデアに投票した人の理由を2〜3名に聞きます。投票の背後にある考えを共有することで、単なる多数決にとどまらない意味のある収束になります。 よくある失敗と対策 議論しながら投票してしまう 投票中に「これはいいと思う」「こっちの方が現実的では？」という会話が始まると、投票が誘導されます。投票フェーズはサイレントを徹底し、議論は投票後に行うというルールを最初に明確にすることが大切です。 シールが多すぎて意味が薄れる 「全員が全アイデアに1枚ずつ貼る」状況になると、優先度の差異がなくなります。配布枚数を評価対象数の3分の1以下に抑えることで、真剣な選択が促されます。 投票結果をそのまま採用してしまう 票が入らなかったアイデアが「不要」とみなされ、廃棄される場合があります。しかし少数票のアイデアが後で重要な視点をもたらすことがあります。 「今回は進めない」というラベルをつけてアーカイブし、参照できる状態を保ちましょう。 ポイント - 評価軸を1つ決めてから投票する — バラバラな基準を防ぐ - サイレント投票を徹底する — 声の大きさに左右されない - 配布枚数は少なめに — 希少性が真剣な選択を引き出す - 投票結果は発火点 — 決定ではなく、議論の起点として扱う - 廃棄せずアーカイブ — 非採用アイデアも後で役立つ ドット投票で絞り込んだアイデアは、ストーリーボードやプロトタイプフェーズへと展開します。また、How Might Weで立てた問いに対するアイデア収束にも効果的です。 --- 参考文献 - Jake Knapp, John Zeratsky & Braden Kowitz, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Simon & Schuster, 2016 - Sam Kaner et al., Facilitator's Guide to Participatory Decision-Making, Jossey-Bass, 2007 - Nielsen Norman Group, "Dot Voting: A Simple Decision-Making and Prioritization Technique", nngroup.com, 2016 --- ### プレモーテム — 失敗を事前に設計する逆転の検証手法 URL: https://designthinking.studio/methods/premortem-design-thinking/ > 「このプロジェクトは失敗した。理由を説明せよ」という問いで未来の失敗を事前に書き出す検証技法。予測的後知恵の研究知見をゲイリー・クラインがプレモーテムとして定式化し、チームの集合知で死角を洗い出す。デザイン思考のテスト・プロトタイプフェーズで使える実践手順を解説。 「このプロトタイプは絶対に機能する」——そう確信した瞬間が、最も危険だ。 チームが解決策に投資すればするほど、失敗の可能性を正面から見ることが難しくなる。心理学ではこれを確証バイアスと計画の誤謬の複合効果と呼ぶ。プレモーテム（Pre-mortem）はこの心理的罠を構造的に回避するための手法だ。 手法の起源 「予測的後知恵（Prospective Hindsight）」という概念そのものは、心理学者のデボラ・ミッチェル、ジェイ・ルッソ、ナンシー・ペニントンが1989年に発表した論文「Back to the Future: Temporal Perspective in the Explanation of Events」で提唱した。彼女らの実験は、ある出来事がすでに起きた事実として提示された場合、人間の原因分析の精度と網羅性が有意に向上することを示した。現在視点で「何が起きうるか」と問うよりも、過去完了視点で「なぜそれは起きたか」と問う方が、想起される原因の数・具体性ともに増加する。 この知見に実務的な形を与えたのが、認知心理学者のゲイリー・クライン（Gary Klein）だ。クラインは1998年の著書 Sources of Power（MIT Press）で熟練した意思決定の構造を論じ、その延長として予測的後知恵をプロジェクト管理に応用するプレモーテム手法を構想した。体系的な定式化は2007年に Harvard Business Review に掲載された論文「Performing a Project Premortem」で公開された。「死亡前診断」という名称通り、プロジェクトが失敗した仮想の未来から現在を振り返るという発想の逆転がこの手法の核心にある。 従来のリスク分析が「何がうまくいかないかもしれないか」と現在視点で問うのに対し、プレモーテムは「すでに失敗した、その理由は何だったか」と過去完了形で問う。この一文の違いが、引き出されるアイデアの量と質を大きく変える。 --- デザイン思考における位置づけ プレモーテムはプロトタイプフェーズとテストフェーズの間、またはテストフェーズの導入として用いることができる。 アサンプション・マッピングが「検証すべき前提を洗い出す」作業であるのに対し、プレモーテムは「なぜ失敗するかを想像する」作業だ。両者は補完的で、アサンプション・マッピングで特定した高リスク仮説に対してプレモーテムを行うと、テスト設計の精度が上がる。 ウィザード・オブ・オズ・テストやユーザビリティテストの前にプレモーテムを行うことで、「どの失敗パターンを特に観察するか」という仮説をテスト設計に織り込める。 --- 実施ステップ ステップ1：前提の共有（10分） 参加者全員が対象のプロトタイプ、サービスアイデア、またはプロジェクト計画を理解している状態を確認する。必要であれば、現時点の計画を5分で共有する。 ステップ2：失敗の宣言（2分） ファシリテーターが次のように宣言する。 「今から1年後（または3ヶ月後）の時点にワープします。このプロジェクトは完全に失敗しました。数値目標は達成されず、ユーザーには受け入れられず、社内では"あの件"として語り継がれています。今、わたしたちはその失敗の原因を振り返っています。」 この「失敗の宣言」は、参加者の心理的モードを「成功させよう」から「失敗を分析しよう」に切り替えるスイッチとして機能する。宣言が明確であるほど、その後の書き出しが鋭くなる。 ステップ3：個人での書き出し（10〜15分） 参加者は一人で沈黙の中、「なぜ失敗したか」を付箋に書き出す。1枚に1つの理由。口頭での共有はこの段階では行わない。 個人ワークにすることが重要だ。グループで議論を始めると、発言力のある参加者の意見に引き寄せられ、死角が生まれる。プレモーテムの価値は、普段は発言しにくい懸念を引き出すことにある。 書き出しの助けになる問い： - 「チームは何を見落としていたか」 - 「ユーザーの何を誤解していたか」 - 「組織の何が実行を妨げたか」 - 「外部環境の何が想定外だったか」 - 「タイミングの何が間違っていたか」 - 「わたし個人が何を言い出せなかったか」 最後の問いが特に重要だ。プレモーテムは、チームメンバーが通常の会議では「空気を壊す」ために言い出せない懸念を、ゲームの枠組みの中で安全に出せる場を作る。 ステップ4：グループ共有（20〜30分） 参加者が順番に付箋を読み上げながら壁やホワイトボードに貼っていく。ラウンドロビン形式で1人1枚ずつ出すと、発言が偏らない。 この段階では質問や議論をしない。「なぜそう思ったか」の掘り下げは後で行う。まず全員の付箋が出揃うことを優先する。 ステップ5：グルーピングと優先順位づけ（15〜20分） 貼り出された付箋を失敗の原因カテゴリでグルーピングする。よく現れるカテゴリは以下の通り： - ユーザー理解の誤り（ニーズ・行動・文脈の読み違い） - 技術的な実現可能性（開発コスト・期間・依存関係） - 組織・体制（意思決定の遅さ・担当者の権限・優先度の競合） - 市場・競合（競合の動き・タイミングのズレ・規制変更） - コミュニケーション（内部合意の欠如・ユーザーへの説明不足） グルーピングが終わったら、ドット投票で「最も致命的な失敗原因」を3〜5つ特定する。 ステップ6：対策の設計（15〜20分） 特定した致命的な失敗原因それぞれに対して、「今から何を変えるか」を議論する。 ここが通常のリスク分析と大きく異なるフェーズだ。リスク分析では「リスクに対策を立てる」が目的になりやすいが、プレモーテムの対策設計では、「この失敗が起きないように、今のプロトタイプ設計・テスト計画・実行計画を何が変わるか」という問いに絞る。 対策は必ずしも「リスクを完全に除去する」ものでなくてよい。「この失敗が起きた場合に早期に検知できる指標を設ける」「このリスクを受け入れた上で、代替案をB案として用意する」も有効な対処だ。 --- ファシリテーションのポイント 失敗のリアリティを高める: 「失敗した」という宣言の後、「今は何年の何月か」「プロジェクトはどの段階で止まったか」という具体的な設定を加えると、参加者の想像力が動きやすくなる。「ユーザーへのリリース後3ヶ月で利用率が10%を下回った」という設定は、書き出しを豊かにする。 沈黙の時間を守る: ステップ3の個人ワーク中に、ファシリテーターが「どうですか」と声をかけないこと。沈黙は思考中のサインだ。10〜15分の集中した個人ワークで、5〜10枚の付箋が出れば理想的だ。 楽観論者に特に発言を促す: プレモーテムの最大の効用は、普段「それはうまくいく」と言いがちなメンバーが、ゲームの枠組みの中で「うまくいかない理由」を出せることにある。発言の少ないメンバーや楽観寄りのメンバーに特に順番が回るよう注意する。 「失敗原因」と「個人批判」を分離する: 「Aさんがこの決定をしたから失敗した」という個人攻撃に変わりそうな発言が出たら、「Aさんがその決定をせざるを得なかった構造的な理由は何か」という問いでシステム視点に引き戻す。 --- アサンプション・マッピングとの違い | 観点 | アサンプション・マッピング | プレモーテム | |------|--------------------------|------------| | 視点 | 現在視点（「これは正しいか?」） | 未来→過去の逆転視点（「なぜ失敗したか」） | | 目的 | 検証すべき仮説の優先順位づけ | 見落とした失敗原因の発掘 | | 適した場面 | プロトタイプ設計前 | テスト計画前・リリース直前 | | 引き出す情報 | 既知の不確実性 | 未知の不確実性（死角） | | 個人作業 | 任意 | 必須（グループ圧力を避けるため） | 両手法は排他的ではなく、順番に使うことでリスク分析の網羅性が上がる。 --- オンラインでの実施 リモートワーク環境では、Miro・FigJam・Mural などのデジタルホワイトボードで同様のセッションを行える。 オンライン実施で特に重要な調整点が2つある。まず、ステップ3の個人ワーク中は参加者の画面共有を切るか、各自のスペースに書き込む形にする。他者の付箋がリアルタイムで見えると、グループ圧力が発生する。次に、ステップ4の共有フェーズでは発言者がカメラをオンにすると、非言語的な反応（「自分も同じことを書いた」という表情）がチーム全体の場の密度を上げる。 リモートワークショップ設計全般の詳細は関連記事に記載している。 --- 注意点 プレモーテムは「失敗の可能性を探す」セッションであるため、プロジェクトへの自信を一時的に下げる効果がある。セッション終了時にはステップ6で洗い出した対策を共有し、「これで何が強化されたか」を言語化する工程を省かない。「何がうまくいかないか」だけで閉じるセッションは、チームのモチベーションを不必要に損なう。プレモーテムの終着点は「このプロジェクトをどう強化するか」の確認であるべきだ。 また、プレモーテムはあくまで想像力の演習だ。書き出された「失敗原因」はすべてが等しく起きるわけではない。問いの本質は「この視点が見落とされていなかったか」という確認にある。全失敗原因に同等のリソースを投入する必要はない。 --- 関連手法 - アサンプション・マッピング - テストカード実験設計法 - ウィザード・オブ・オズ・テスト - ユーザビリティテスト - ドット投票 - ステークホルダーマッピング --- 参考文献 - Deborah J. Mitchell, J. Edward Russo & Nancy Pennington, "Back to the Future: Temporal Perspective in the Explanation of Events," Journal of Behavioral Decision Making, Vol. 2, 1989（予測的後知恵の原概念を提唱した原著論文） - Gary Klein, Sources of Power: How People Make Decisions, MIT Press, 1998 - Gary Klein, "Performing a Project Premortem," Harvard Business Review, September 2007 - Daniel Kahneman, Thinking, Fast and Slow, Farrar, Straus and Giroux, 2011（確証バイアスと計画の誤謬に関する記述） --- ### プロトタイピング手法の全体像—ペーパープロト・Wizard of Oz・デジタルの使い分け完全ガイド URL: https://designthinking.studio/methods/prototyping-techniques-complete-toolkit/ > ペーパープロトタイプ、Wizard of Oz、デジタルプロトタイプの3手法を理論と実践の両面から解説。「いつどの手法を選ぶか」の判定フローチャートと、テスト設計との統合アプローチを収録した実践完全ガイド。 プロトタイピングは、アイデアを「試せる形」に変え、仮説を最短で検証するための行為です。「完成品に近いものを作る」という誤解が、プロトタイピングを遅く・高コストにする最大の原因です。このガイドは、ペーパープロトタイプ・Wizard of Oz・デジタルプロトタイプの3手法を「いつ・なぜ・どう使うか」という実践の観点から解説します。 プロトタイピングとは何か——よくある誤解の解消 問題（Problem） 「プロトタイプを作ろう」と言うと、多くのチームが「Figmaで作りましょう」と始めます。しかし Figmaで動くUIを作るのに丸2日かかり、ユーザーテストで「根本的な概念が伝わらなかった」と気づく——このパターンは珍しくありません。作り込むほど「せっかく作ったから」という埋没コストが意思決定を歪めます。 親近感（Affinity） ワークショップでよく起こるのは、ファシリテーターが「低忠実度でいい」と言っても、参加者が「ちゃんと見せられるものを作りたい」という心理でどんどん精密にしていくパターンです。「粗いものを見せるのが恥ずかしい」という感覚は、プロトタイピングの本質と真逆です。 粗いほうが、ユーザーが自由にフィードバックを言いやすい。 解決策（Solution） プロトタイプの目的は「検証したい仮説を最小コストで試すこと」です。どの手法を選ぶかは「忠実度（Fidelity）」ではなく「何を検証したいか」で決まります。このガイドでは3手法の選択基準を明確にし、テスト設計との統合まで扱います。 --- プロトタイピングの基本原則 Stanford d.school が定義する「プロト思考」 Stanford d.school の Bootcamp Bootleg では、プロトタイピングを「考えるためのツール（Think with your hands）」と定義しています。プロトタイプを「完成品の前段階」ではなく「思考の道具」として捉えることが、手法選択の出発点です。 IDEO のデザインプロセスでも、「Fail early, fail often」というプロト哲学が貫かれています。早く・多く・安く失敗することで、方向性の誤りを修正するコストを最小化します。プロトタイプは失敗を許可する場であり、失敗を歓迎する構造を持ちます。 忠実度の2軸 プロトタイプの忠実度は「視覚的忠実度」と「機能的忠実度」の2軸で考えます。 | | 視覚的忠実度（低）| 視覚的忠実度（高）| |--|--|--| | 機能的忠実度（低） | ペーパープロトタイプ | モックアップ（静的UI）| | 機能的忠実度（高） | Wizard of Oz | インタラクティブプロトタイプ | どちらの軸を上げるかは「何を検証したいか」によって決まります。コンセプトの理解を検証したいなら視覚的忠実度が低くても機能します。操作フローを検証したいなら機能的忠実度を上げます。 --- 手法1：ペーパープロトタイプ なぜ紙で始めるのか 紙は最速・最安・最修正しやすいプロトタイプ素材です。Sharpie（マジック）と付箋があれば30分で試せます。ユーザーが「ここが変」と言った瞬間に、目の前でその場で修正できます。200回以上のワークショップで繰り返し観察されてきたのは、紙で始めたチームがデジタルに進む前に概念の誤りを発見し、開発コストを大幅に圧縮できているというパターンです。 IDEO の David Kelley は「最初の10個のプロトタイプは紙で作れ」と語ります。デジタルで作ったものは「直してもらうのが申し訳ない」とユーザーが気を使い、本音のフィードバックが減ります。紙の粗さが「これは試作なので何でも言ってください」というシグナルになります。 ペーパープロトタイプの実施手順 Step 1：検証仮説を1文で書く（5分） 何を確かめたいかを「ユーザーは〜できると思っているか？」という形式で1文で書きます。この1文がなければ、作ることが目的になります。 例：「ユーザーは申請ステータスを3秒以内に確認できると思っているか？」 Step 2：画面の流れをアウトライン化する（10分） 紙（またはカード）1枚 = 1画面として、検証したいフローの画面を列挙します。全ての機能を作る必要はありません。検証仮説に関係する画面だけを対象にします。 Step 3：手書きで作る（15〜30分） Sharpie で手書きします。鉛筆ではなくSharpie を使う理由は、細部を描き込めないため、構造だけを描く習慣がつくからです。 ボタンの色や角の丸みは今は関係ない。「このボタンを押したら次に何が起きるか」という構造だけを確認します。 Step 4：役割分担を決める（5分） ユーザーテストの際、「コンピューター役」の担当者を決めます。ユーザーが「このボタンを押す」と言ったら、コンピューター役が次の画面のカードをテーブルに出します。これがペーパープロトタイプの核心的な仕組みです。 Step 5：3人以上のユーザーでテストする 1人でのテストでは「この人の特異な行動」なのか「設計上の問題」なのかが区別できません。最低3人でテストし、2人以上が同じ箇所で詰まったときを「設計上の問題」と判断します。 ペーパープロトの材料リスト - Sharpie または太マーカー - A4白紙（大量に用意する。何度でも作り直す前提） - 付箋（画面の一部を隠したり追加するための「オーバーレイ」に使う） - はさみ - テープ - タイマー（テスト中のタスク時間計測用） --- 手法2：Wizard of Oz プロトタイプ 「裏で人間が操作する」という発想 Wizard of Oz プロトタイプは、ユーザーに「システムが動いている」と思わせながら、実際にはバックグラウンドで人間がリアルタイムに操作・応答するプロトタイプ技法です。 名称の由来は映画「オズの魔法使い」です。偉大なオズ大魔王が実はカーテンの裏で操作している老人だったように、「魔法のような体験」の裏に人間の手作業が隠れています。 Wizard of Oz が有効な場面は、AIや音声認識など「本物のシステムを作るコストが極めて高い」機能の検証です。AIチャットボットの会話品質を検証したいとき、本物のAIを作る前に人間がチャットを打って「ユーザーはこの回答で満足するか？」を確認できます。 Wizard of Oz の典型的なセットアップ 音声アシスタントの検証 ユーザーが「明日の天気は？」と話しかける。別室（または画面の外）のオペレーターがその言葉を聞いて、あらかじめ用意した回答リストから選んでスピーカーから応答する。ユーザーはシステムが応答していると体験します。 パーソナライズ機能の検証 Webサービスの「あなたにおすすめ」機能を本物のレコメンデーションエンジンなしで検証します。ユーザーがサービスを使い始めたら、オペレーターがユーザーの行動を観察して手動でコンテンツを選び表示します。ユーザーは「AIが選んでいる」と体験します。 実際にやってみると、Wizard of Oz の最大の発見は「どんな精度のレコメンドなら満足か」という閾値の発見です。人間が選んだものでも「機械的に感じる」と言うユーザーがいれば、パーソナライズの表現方法の問題が浮かびます。 Wizard of Oz の落とし穴 落とし穴1：オペレーターの疲労 1セッションが長くなると、リアルタイム応答を担当するオペレーターの集中力が低下します。1セッションは15〜20分を上限にし、オペレーターを交代させます。 疲弊したオペレーターの応答ミスが、「システムのバグ」としてログに記録されると分析が混乱します。 落とし穴2：「Wizard がバレる」場合の記録 ユーザーが「あれ、これ自動じゃないんですか？」と気づいた瞬間は、テストを止めるのではなく「気づいた理由」を必ず記録します。 バレたことで無効になるのではなく、「どこが不自然だったか」がシステム設計のインサイトになります。 落とし穴3：スクリプトの準備不足 オペレーターがアドリブで対応すると、セッションごとに回答品質がばらつきます。あらかじめ「ユーザーがこの文脈でこう質問したら、この回答を返す」というスクリプトを作成し、オペレーターはスクリプトから選択する設計にします。 --- 手法3：デジタルプロトタイプ デジタルに進む判断基準 デジタルプロトタイプは高コスト・高時間のため、「ペーパーまたはWizard of Ozで確認できた方向性を、より精密に検証する段階」で使います。 デジタルプロトタイプでなければ検証できない問いとして以下があります。 - アニメーションやトランジションの体験（「画面が切り替わる速さは適切か？」） - 実際のデバイスのサイズ・解像度・タッチ操作での体験 - ユーザーが自分でナビゲーションを探索する動線（誘導なしで目的を達成できるか） ツール選択の基準 | ツール | 向いている用途 | 所要時間目安 | |-------|-------------|-----------| | Figma | UIフロー・画面遷移の検証 | 4〜16時間 | | Marvel / InVision | スクリーンショット連結の簡易フロー | 1〜4時間 | | Framer | インタラクション・アニメーション重視 | 8〜24時間 | | コーディング（HTML/CSS）| ブラウザ上の実際の操作感 | 16時間以上 | 重要な原則は、選んだツールで「検証したい仮説」を試せるかどうかが唯一の基準です。「Figmaが使えるからFigmaで作る」ではなく「今回の仮説はスクリーンショット連結で十分検証できるか」という問いで選びます。 デジタルプロトのよくある失敗 失敗：「完成に近いもの」を作りすぎる デジタルプロトタイプが「本番前の完成品」に見えるほど、ユーザーは「ここはもっとこうしてほしい」という重要なフィードバックを遠慮します。わざと未完成感を演出することが有効です。グレースケールのみで作る、フォントを統一しない、ダミーテキストを残す——これらが「試作品である」というシグナルになります。 --- 「いつどの手法を選ぶか」判定フローチャート 複合的な検証が必要な場合は、ペーパープロトで方向性を確認 → デジタルプロトで操作フローを検証という順で進めます。Wizard of Oz はペーパープロトの後、またはデジタルプロトと並行して実施できます。 --- プロトタイピングとテスト設計は不可分 なぜテスト設計と一緒に考えるか プロトタイプを作ってから「どうテストするか」を考えるチームは、テストで集めたいデータが取れないことが多い。プロトタイプを設計する時点で「このプロトで何をどう測るか」を決めることが、有効なプロトタイピングの条件です。 テスト設計で事前に決める3点： - タスク定義：「ユーザーに何をやってもらうか」を1〜3タスクで定義する - 成功基準：「何ができたら仮説が支持されるか」の閾値を決める（例：「3分以内に目的の画面に到達」） - 観察ポイント：「詰まりが起きたらどこで記録するか」のシートを事前に作る テスト中の「ユーザーへの声かけ」 プロトタイプテスト中にファシリテーターがやりがちな失敗が「誘導」です。ユーザーが迷った瞬間に「これを押してみてください」と言ってしまう。ユーザーが迷う場面こそが最も重要なデータなのに、誘導によって問題が隠れてしまいます。 「Think Aloud（思考発話）」という技法を使います。ユーザーに「今何を考えているか、口に出しながら操作してください」と事前に伝えます。「えーと、ここを押したらどうなるんだろう」という独り言が、設計上の問題を特定するための生データになります。 ユーザビリティテストとの統合については、テストフェーズの記事で詳しく扱います。 --- 材料別コスト・時間・効果比較 | 手法 | 材料費 | 作成時間 | 向いている仮説 | E-E-A-T適合度 | |------|-------|---------|-------------|-------------| | ペーパープロト | 100円以下 | 30〜60分 | コンセプト・概念合意 | ◎ | | Wizard of Oz | ほぼ0円 | 2〜4時間（スクリプト込み）| AI/音声/パーソナライズ体験 | ◎ | | デジタル（Figma等）| 0〜月額費用 | 4〜24時間 | 操作フロー・遷移 | ○ | | コーディング | 0円 | 16時間以上 | 実装品質・インタラクション | △（最終段階向け）| --- POVからプロトタイプへの流れ プロトタイピングは独立したフェーズではなく、POVステートメントで定義した問題に対する「仮説の具体化」です。POVに書いたインサイトとニーズをもとに「もしこう解決したら？」という仮説を形にするのがプロトタイプです。 POV → 仮説 → プロトタイプの例： POV文：「毎朝の会議で議事録を担当する田中さんは、重要な発言を聞き逃さずに記録する方法を必要としている。なぜなら、書きながら聞く行為が分断されると議論への参加が困難になるからだ」 仮説：「もし発言が自動でテキスト化され、後で修正できる設計なら、田中さんは会議に集中しながら記録できるのではないか」 プロトタイプ（Wizard of Oz）：研究者が別室からリアルタイムで発言を文字起こしするシステムを「自動変換」として見せ、「このUIで編集しやすいか」を検証する。 --- よくある失敗と対策 失敗1：仮説なしにプロトタイプを作り始める 「とりあえず作ってみよう」は最も多い失敗です。何を確認したいかが不明なまま作ると、ユーザーテストで「何がわかったのか」が不明なままになります。 作る前に「このプロトで確かめる仮説は1文で書けるか？」を問います。 失敗2：プロトタイプを「完成品の縮小版」として作る 「せっかく作るなら全機能入れよう」という発想が、プロトタイプを重くします。プロトタイプには「今回の仮説検証に関係しない機能は入れない」というシンプルなルールを設定します。 余計な機能がユーザーの注意を分散させます。 失敗3：1人のユーザーの意見で大改修する 「このユーザーに受けなかったから作り直そう」は、単一サンプルの危険な解釈です。1人の反応はデータの一点に過ぎません。3〜5人のパターンを見てから方向転換の判断をします。 失敗4：テスト後の記録が「良かった/悪かった」で終わる テスト後の振り返りが「大体うまくいった」「あの部分が悪かった」という主観で終わると、次のプロトタイプの改善点が不明確になります。タスク完了率・詰まりが起きた箇所・ユーザーの発言（Think Aloud の記録）という3種のデータを記録し、改善の根拠を事実に基づかせます。 --- ポイント - 「何を確かめたいか」が手法選択の唯一の基準 — 忠実度や見た目のクオリティではなく、検証仮説から手法を逆算する - ペーパーファースト — コンセプトの方向性はまず紙で確認してからデジタルへ進む。材料選びからファシリテーションまでの実践手順はペーパープロトタイピング完全ガイドに詳しくまとめている - Wizard of Oz は高コスト機能の事前検証に最強 — AI・音声・パーソナライズを本番構築前に試す唯一の現実的手段 - プロトタイプとテスト設計は同時に設計する — 作ってからテストを考えると、欲しいデータが取れない - 粗さを恐れない — 粗いほど本音のフィードバックが集まる。完成度が上がるほどユーザーは遠慮する - 3人以上でテストする — 1人の反応を構造的な問題と判断しない - プロトタイプ後のユーザー検証をより体系的に設計したい場合は、Desirability Testing 完全ガイドで感情的共鳴の測定手法を確認してほしい。Microsoft Reaction Cardsを用いたDesirability Testingの全手順とファシリテーション失敗パターンについては、Desirability Testing とユーザー検証完全ガイドに体系化している。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018年改訂版 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperCollins, 2009 - Steve Krug, Don't Make Me Think: A Common Sense Approach to Web Usability, New Riders, 2014（第3版） - Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly, 2014 --- ### ペーパープロトタイピングの歴史とFigma比較——Snyder 2003とWizard of Oz統合の系譜 URL: https://designthinking.studio/methods/paper-prototyping-history-and-figma-comparison/ > Carolyn Snyderの古典的著作(2003年)からWizard of Ozとの統合、現代のFigmaとの使い分けまで。ペーパープロトの歴史を起点に、低忠実度プロトタイピングが今も生き残る構造的理由を解説。 ペーパープロトタイピングは「過去の手法」ではない。Figmaが標準化した2026年現在も、プロトタイピングの初期段階で第一選択になる場面がある。なぜか。その答えは、20年以上にわたる手法の系譜と、低忠実度プロトタイピングが持つ構造的な強みにある。 本稿はペーパープロトタイピングの歴史的起源(Carolyn Snyder, 2003年)、Wizard of Ozとの統合、Figmaを代表とするデジタルツールとの使い分けという3つの軸で、この手法が今も生き残る理由を解き明かす。実践的な制作手順はペーパープロトタイピング完全ガイドを参照されたい。 起源——Snyder 2003とその前史 「Paper Prototyping」(2003年)の位置づけ ペーパープロトタイピングを体系的な手法として確立した著作が、Carolyn Snyder, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces(Morgan Kaufmann, 2003)である。408ページにわたるこの実践書で、Snyderは制作手順・ファシリテーション技法・組織内での合意形成・ユーザーテスト設計までを網羅した。 Snyderはこの書籍以前から長年UXコンサルタントとして活動しており、書籍はその実践知の集大成だった。重要なのは、彼女が「紙のプロトタイプ」を単なる速作り手段ではなく、ユーザーテストと組み合わせた一つの方法論として位置付けたことである。 Snyder以前の文脈——HCI研究と参加型デザイン Snyderの2003年の著作以前から、ペーパープロト的な手法はHCI(Human-Computer Interaction)研究の文脈で用いられていた。1980年代の参加型デザイン(Participatory Design)運動では、デンマーク・スウェーデンの研究者たちが、エンドユーザーとデザイナーが紙とペンでシステムを共同設計するワークショップを実施していた。 また1980年代後半のXerox PARC、Apple、IBM Research などでは、ソフトウェアUI設計の早期段階で「コミック・スケッチ」(画面遷移を漫画形式でスケッチする手法)が使われていた。これらの実践が、Snyderの書籍によって統合・体系化された形だ。 Snyder本の3つの貢献 Snyderの書籍が以後の業界標準を作った貢献は3点に整理できる。 第一に、「プロトタイピング」と「ユーザーテスト」を一体化させた。それまでプロトタイプは「作って確認する」までが範囲だったが、Snyderは「ユーザーに紙を操作してもらい、思考発話で観察する」という具体的なテスト手順とセットで提示した。 第二に、「低忠実度の心理的効果」を言語化した。完成度の低いプロトの方がユーザーから本音を引き出せるという観察を、組織内で説得するための論理として整備した。「この粗末な紙を見せるのは失礼ではないか」という抵抗への反論材料を提供した。 第三に、組織導入の現実的な障壁を扱った。エンジニアからの懐疑、経営者の不安、デザイナーのプライドといった組織心理的な障壁を章立てで扱い、書籍を「単なる手法書」から「組織変革ガイド」へと拡張した。 Wizard of Ozとの統合——「動かない紙」を「動くシステム」に見せる Wizard of Ozとは何か Wizard of Oz法は、システムの応答機能を実装する代わりに、裏で人間が応答を生成して、ユーザーには「動いているシステム」として体験させる手法である。名称は『オズの魔法使い』のカーテンの裏にいる小男に由来する。 Wizard of Ozは音声アシスタントやAIシステムのプロトタイピングで歴史的に使われてきた。Microsoft Researchや音声インタラクション研究の文献で、1980年代から確立された手法である。 ペーパープロト×Wizard of Ozの統合 ペーパープロトタイピングのテストでは、ファシリテーターが「コンピューター役」として紙を動かす。ユーザーが「ここをタップ」と紙の上で指を置くと、ファシリテーターが該当する次画面の紙を素早く差し替える。 この行為自体が、本質的にWizard of Ozの実装である。「システムが応答している」体験を、ファシリテーターが手動で再現している。 意図的にこの統合を強化すると、ペーパープロトタイピングで以下のような複雑なインタラクションも検証できる。 - 検索機能のプロトタイピング——ユーザーが紙に書いた検索語をファシリテーターが見て、事前に用意した複数の「検索結果カード」から該当するものを選んで提示する - AIアシスタントのプロトタイピング——ユーザーの音声指示にファシリテーターが瞬時に応答カードを提示する - エラーフローのプロトタイピング——ユーザーが想定外の操作をしたとき、即興でエラー画面の紙を作って渡す 統合の利点 ペーパープロト+Wizard of Ozの統合により、実装コストゼロで複雑なインタラクションを検証できる。Figmaのインタラクティブモードでも、事前定義した遷移しか動かない。一方、Wizard of Oz統合のペーパープロトは、ユーザーの予想外の入力に対して即興で応答を作れる。これは複雑なインタラクションの探索段階で決定的な強みになる。 Figmaとの使い分け——どちらを選ぶか Figmaの構造的強み Figma(2016年公開、2022年Adobeによる買収提案で世界的注目を集めた)は、現代のデジタルプロトタイピングの事実上の標準である。Figmaの強みは以下のとおり。 - コンポーネント再利用——一度作ったボタンを全画面で再利用可能、変更時に一括更新 - リアルタイム共同編集——複数人が同時に同じファイルを編集可能 - インタラクティブモード——画面遷移・ホバー状態・アニメーションを定義可能 - デザインシステム連携——既存のデザインシステムをそのままプロトに反映可能 - 本番開発との連動——CSSスニペット・コンポーネント仕様をエンジニアに直接渡せる ペーパープロトの構造的強み しかしFigmaが圧倒的に優位というわけではない。ペーパープロトには、Figmaで再現困難な構造的強みがある。 第一に、心理的安全性。「これは試作だ」という見た目がユーザーに伝わるため、ユーザーは率直に批判できる。Figmaで作った高忠実度プロトは「完成品」に見えやすく、ユーザーが「いいですね」と社交辞令で済ませる傾向が出る。 第二に、即興性。ユーザーテスト中に「ここに別の選択肢があったら?」という気づきが生まれた瞬間、紙ならその場で書き足せる。Figmaでは編集にコンテキストスイッチが発生する。 第三に、参加者全員の対等性。Figmaは作る側(デザイナー)と見る側(ユーザー・他職種)の権力非対称を生むが、紙とマジックは誰でも触れる。非デザイナーが「自分も書いていい」と感じる心理的アクセシビリティは、ペーパープロトの隠れた強みだ。 第四に、Wizard of Oz統合の容易さ。前述のとおり、紙ならばファシリテーターが即興で応答を作れる。Figmaのプロトモードは事前定義された遷移に縛られる。 使い分けの判定フロー 実務で迷ったときの判断基準を、5つの問いに整理する。 - ユーザーから本音を引き出したいか? → Yesならペーパープロト優位 - インタラクションを探索的に試したいか? → Yesならペーパープロト+Wizard of Oz優位 - すでに方向性が固まっており、デザイン精度を上げたいか? → YesならFigma優位 - エンジニアに実装仕様を渡す段階か? → YesならFigma優位 - 複数拠点・リモートでの共同編集が必須か? → YesならFigma優位 実務上の最適解は「初期はペーパー、後期はFigma」の二段階運用である。問題定義直後の探索段階(発散)はペーパー、方向性確定後の精緻化段階(収束)はFigmaという使い分けが、両者の強みを活かす。 現代における低忠実度プロトの再評価 AIツールが生む「過剰生成」への対抗策 2024〜2026年、生成AIによってプロトタイプを瞬時に大量生成できるようになった。Figmaも生成AI機能を統合し、テキストから画面案を作るフローが一般化した。 しかし「大量生成された候補から選ぶ」プロセスは、デザイナーの判断力を逆に鈍らせるという観察がある。「自分で線を引く」プロセスを通じて初めて、設計の意図が言語化される。ペーパープロトは、この思考のスピードを意図的に遅くする装置として再評価されつつある。 スケッチ→ペーパー→Figmaの3段階モデル 現代の推奨ワークフローは、以下の3段階に整理できる。 - スケッチ段階(個人作業、5〜30分)——アイデアを乱筆で書き出す - ペーパープロト段階(チーム作業、30〜90分)——ユーザーテスト用の紙を作る - Figma段階(精緻化作業、数時間〜数日)——確定方向性をデジタル化 Snyderの2003年の枠組みは2段階(スケッチ→ペーパー)で完結していたが、現代では3段階が標準化している。各段階で「捨てやすさ」が下がっていく構造を意識すると、過剰投資を防げる。 まとめ——20年以上生き残る理由 ペーパープロトタイピングが2003年の体系化から20年以上経った現在も使われ続ける理由は、手法そのものの優位性ではなく人間心理の不変性にある。 ユーザーは未完成のものに対しては率直に意見を言う。完成品に対しては社交辞令を述べる。この心理的非対称は、ツールがどれだけ進化しても変わらない。Figmaの精度がいくら上がっても、「精度が高いものを"完成品"と認知する」人間の傾向は変わらない。 だからこそ、初期段階の意図的な低忠実度は永続的な価値を持つ。Snyderの書籍が今読んでも色褪せないのは、彼女が手法ではなく人間の認知メカニズムを扱ったからである。 ペーパープロトタイピングの実践手順は完全ガイドを、Wizard of Oz単独の手法は関連メソッドを、Figmaを使った精緻化フェーズはプロトタイプフェーズを併せて参照されたい。 --- 参考文献 - Carolyn Snyder, Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces, Morgan Kaufmann, 2003 (ISBN 978-1558608702) - John D. Gould, Stephen J. Boies, Stephen Levy, John T. Richards, Jim Schoonard, "The 1984 Olympic Message System: A Test of Behavioral Principles of System Design," Communications of the ACM, 1987(Wizard of Ozの先駆的応用) - Bill Buxton, Sketching User Experiences, Morgan Kaufmann, 2007(スケッチからプロトへの段階論) - Pelle Ehn, Work-Oriented Design of Computer Artifacts, Arbetslivscentrum, 1988(参加型デザインとペーパー手法の起源) - Figma Inc., Figma Documentation, 2026(現代デジタルプロトタイピングの実装基準) --- ### ペーパープロトタイピング完全ガイド — 低忠実度プロトで検証サイクルを劇的に短縮する URL: https://designthinking.studio/methods/paper-prototyping-complete-guide/ > ペーパープロトタイピングは紙・付箋・マジックで30分以内にテスト可能な低忠実度プロトタイプを作る手法。検証サイクルを劇的に短縮する原理、Stanford d.schoolの「手で考える」哲学、忠実度の逆説、ユーザーから本音を引き出すファシリテーション術を完全ガイド。 デジタルツールを開く前に、まず紙で試す。この一歩が、検証サイクルを劇的に短縮するかどうかを分ける分水嶺です。ペーパープロトタイピングは、A4用紙と付箋とマジックがあれば30分で「動く」プロトタイプを作れる手法です。このガイドでは、制作手順からユーザーテストのファシリテーション術、よくある失敗の処方まで、実践レベルで解説します。 なぜ今、ペーパープロトタイピングなのか 問題（Problem） 「デジタルでちゃんと作ってからユーザーに見せよう」という判断が、プロジェクトを迷走させる最大の原因のひとつです。Figmaでワイヤーフレームを1週間かけて作り込んだあと、ユーザーテストで「そもそもこの概念自体が伝わらなかった」と判明する——この経験をしたチームは少なくありません。 問題の核心は「作り込むほど手放せなくなる」という心理にあります。時間をかけた成果物は、たとえ方向性が間違っていても「なんとか活かそう」という意識が働きます。これが意思決定を歪め、正しい方向への軌道修正を遅らせます。 親近感（Affinity） ワークショップでよく起こるのは、ファシリテーターが「紙で作りましょう」と言った瞬間に、参加者の表情が曇るパターンです。「紙で作ったものをユーザーに見せるのか」「こんな粗末なものを出すのは失礼ではないか」——この感覚は、デザイン思考の実践者でも最初は持ちます。 実際にやってみると、まったく逆の反応が起きます。ユーザーは「これは試作なんだな」と察して、遠慮なく「ここが変」「こっちのほうがいい」と言い始めます。完成度の高いモックアップほど、ユーザーは「良いところを探そう」という心理になります。参加者からの声として頻繁に聞かれるのは「紙のほうが正直に言いやすかった」という感想です。 解決策（Solution） ペーパープロトタイピングの価値は3点に集約されます。第一に速さ——30分以内にテスト可能な状態に到達できます。第二に修正コストの低さ——ユーザーの目の前でハサミを入れ、付箋で書き直し、その場で再テストできます。第三に心理的安全性——作り手がプロトタイプへの愛着を持ちにくいため、ユーザーのフィードバックを素直に受け入れられます。 --- ペーパープロトタイピングの基本原理 Stanford d.school が説く「手で考える」 Stanford d.school の Bootcamp Bootleg は、プロトタイピングを「手で考える（Think with your hands）」行為として位置づけています。プロトタイプは完成品への途中段階ではなく、思考そのものの外部化です。頭の中に留まっているアイデアを「形ある何か」として外に出した瞬間に、チームで議論できる対象に変わります。 紙は「形ある何か」を作り出す最も摩擦の少ない素材です。プログラミングも、Figmaの操作も必要ありません。アイデアを持った人であれば誰でも、今すぐ参加できます。これがペーパープロトタイピングをデザイン思考の入口として最適な手法たらしめている理由です。 低忠実度が「本音」を引き出す IDEO の共同創業者でデザイナーの Bill Moggridge をはじめ、プロトタイピング研究の実践者たちが繰り返し報告してきた「忠実度の逆説」があります。視覚的に完成度が高いほど、ユーザーは「製品として完成している」と認識し、本質的な問題点を指摘しにくくなるというものです。 低忠実度プロトタイプには「これは仮のものです」というシグナルが内包されています。ユーザーはそのシグナルを受け取り、改善提案や批判的フィードバックを安心して提供できます。ペーパープロトタイプが持つ「ラフさ」は欠点ではなく、本音を引き出すための設計上の特徴です。 --- ステップ1：事前準備（15分） 検証したい仮説を1枚の紙に書く 制作を始める前に、「このプロトタイプで何を検証したいのか」を1文で書き出すことが最重要です。この手順を省略すると、プロトタイプ制作が目的化し、「きれいな紙の模型」が完成しても何も学べない、という結果になります。 仮説の例：「ユーザーはトップ画面から目的のタスクに3ステップ以内で到達できるか」「オンボーディングフローで、機能Aの目的がユーザーに伝わるか」——このように、YesかNoかで答えられる具体的な問いの形式にすることが鍵です。 素材チェックリスト 実際にやってみると、材料の過不足がファシリテーションの流れを妨げることがわかります。事前に以下を用意します。 | 素材 | 用途 | 代替品 | |---|---|---| | A4白紙（10〜20枚） | 画面の土台 | コピー用紙 | | 付箋（複数色） | ボタン・ラベル・モーダル | 切った紙片 | | マジック（Sharpie黒） | UI要素の描画 | 太めボールペン | | ハサミ | 部品の切り出し | カッター | | テープ（マスキング推奨） | 部品の仮固定 | のり・クリップ | | スマートフォン（カメラ用） | テスト記録 | 別のカメラ | Sharpieを使う理由は明確です。細いボールペンで描いたUIは小さくて見づらく、ユーザーが画面要素を認識できません。太いマジックで描いた荒い線のほうが、テスト時の「この部分をタップする」という動作が自然に引き出されます。 --- ステップ2：制作（20〜40分） 画面設計の原則：「完成させない」 ペーパープロトタイプの制作で最初につまずくのは「完成させようとする」衝動です。必要なのは、検証したい仮説に関係する画面だけです。3画面で仮説を検証できるなら、3画面だけ作ります。 推奨する手順は以下の通りです。 - 検証対象のユーザーフローを付箋に書き出す（画面名だけでよい） - フローの起点となる画面を1枚目に描く - ユーザーが取るであろう最初のアクションに対して遷移する画面を描く - 分岐点（ボタンが複数ある場合など）はそれぞれ別紙に描く - 終点（タスク完了画面）まで繋げる 動的要素の作り方 ペーパープロトタイプで多くの人が詰まるのは、「ドロップダウンメニュー」「モーダル」「ツールチップ」などの動的要素をどう表現するかという点です。 答えはシンプルです——別の紙に描いて、適切なタイミングで重ねます。ドロップダウンは展開した状態の紙片を手で持ち、ユーザーがタップする動作をしたタイミングで画面の上に置きます。これが「コンピューター役（Computer Player）」の仕事であり、ペーパープロトタイプの核心的な手法です。 よくある制作上の失敗 実際のワークショップで繰り返し観察される失敗パターンとその対処を以下にまとめます。 失敗1：テキストを書きすぎる 画面内に実際の文言をすべて書こうとするチームがいます。線で表現するだけで十分です。「テキストが入る場所」を示す3本の水平線があれば、ユーザーはそこに文字があると認識します。 失敗2：小さすぎる A4用紙に6画面を詰め込むチームがいます。1枚の紙に1画面が基本です。ユーザーがタップ動作をする際に、要素が小さすぎると「どこをタップしたのかわからない」という状況が発生します。 失敗3：制作に没入して60分を超える 「もう少し作り込んでから」という思考が入り始めたら、それはペーパープロトタイピングの失敗モードです。制作は40分でタイムボックスし、残りをテストに使います。 --- ステップ3：テスト（30分） 役割分担の確定 ペーパープロトタイプのテストは最低3名で行います。 | 役割 | 担当 | 備考 | |---|---|---| | ファシリテーター | ユーザーへの説明・質問 | 誘導しないことが最重要 | | コンピューター役 | 画面の切り替え・動的要素の操作 | 無言で動く | | 記録係 | メモ・録音・撮影 | ユーザーの発言と動作を記録 | 2名で実施する場合は、ファシリテーターがコンピューター役を兼任します。ただし記録係を省略するのは推奨しません。テスト後に「あのとき何と言っていたか」の記憶は驚くほど不正確です。 思考発話法（Think Aloud）との組み合わせ ペーパープロトタイプのテストで最も効果的なデータ収集手法が思考発話法（Think Aloud Protocol）です。ユーザーに「操作しながら、頭に浮かんでいることを声に出してください」と依頼します。 ファシリテーターが最初に行うインストラクションの例：「これは試作品です。完成度ではなく、あなたが使いやすいかどうかを確認するためのものです。どこをタップするかを声に出しながら操作してください。わからなくても構いません。わからないこと自体がとても貴重な情報です」 「わからないこと自体が貴重」という言葉は必ず入れてください。ユーザーは「正解を見つけなければならない」というプレッシャーを感じると、本音の行動をしなくなります。 ファシリテーションの禁じ手 実際にやってみると、ファシリテーターが無意識に誘導してしまうシーンが頻発します。以下はすべて禁じ手です。 - 「次はこちらをタップしてください」（誘導） - 「そこは後で修正します」（防衛） - 「使いにくいと感じましたか？」（誘導質問） - ユーザーが迷っている時に「どこをタップしたいですか？」と助け船を出す（観察機会の喪失） ユーザーが迷っている時間こそ、最も重要なデータが生まれる瞬間です。沈黙を埋めたくなる衝動に勝つことが、良いファシリテーターの条件です。 --- ステップ4：記録と分析（15分） テスト直後の「熱いうち」に記録する テスト終了後、記録係が書いたメモとチームの観察を統合する時間を15分設けます。翌日に持ち越すと、細かいニュアンスが失われます。 記録すべき観点は3つです。ユーザーが迷った箇所（どこで、何秒迷ったか）、ユーザーが期待と違う動作をした箇所（何をしようとして、実際に何をしたか）、ユーザーが発言した驚き・疑問・批判（できるだけ原文で）。 「修正してすぐ再テスト」のサイクル ペーパープロトタイプの最大の強みは、テストで発見した問題をその場で修正し、すぐに次のユーザーに試せることです。付箋を貼り替え、画面を描き直し、5分後には修正版のテストが始められます。 実際のワークショップでは、1時間のセッション内に「プロト制作→テスト→修正→再テスト」を2サイクル回すことが可能です。デジタルプロトタイプでは1サイクルに数時間かかる作業が、紙なら1時間で完結します。 --- よくある失敗と対策 「紙で作ることを恥ずかしがる」問題 これはペーパープロトタイピングで最も頻繁に起きる、かつ最も根深い問題です。「こんな粗いものを見せるのは申し訳ない」「もう少し整えてから」という心理が、制作を必要以上に長引かせます。 処方は、フレームの転換です。「粗いものを見せる」という認識を「検証のための道具を渡す」に変えます。ユーザーへの説明で「試作品です」と明言することで、ユーザー側も「評価する」モードから「一緒に作る」モードに変わります。参加者からの声として「紙のほうが気軽に意見を言えた」は定番のフィードバックです。 あるプロダクトチームでは、チームリーダーが「絶対にFigmaを開いてはいけない、最初の3日間は紙だけ」というルールを設けました。3日後には概念レベルの問題がすべて発見され、開発工数を大幅に削減できたと報告されています。 「テストが評価になってしまう」問題 ペーパープロトタイプを「見せる」という意識があると、テストが「評価してもらう場」になります。するとファシリテーターは批判的なフィードバックを受けると防衛的になり、ユーザーは批判しにくくなります。 テストは評価の場ではなく、学習の場です。失敗した画面遷移は「直せばいい」というチームの姿勢が、テストの心理的安全性を作ります。コンピューター役が無言で動くのも、この心理的安全性を保つためです——コンピューターは批判されません。 「記録を省略する」問題 2名以下でテストを実施すると、記録が曖昧になります。「あそこで迷っていた」「なんか言っていた」という印象論になり、修正の根拠が作れません。 スマートフォンの定点撮影（画面と手元が映る角度）だけでも記録として有効です。録音・録画に同意を得たうえで実施します。後から見返した時に「確かにここで5秒止まっていた」という事実が、チームの議論を根拠ある方向に導きます。 --- Wizard of Oz テストとの違い ペーパープロトタイピングと混同されやすい手法に「Wizard of Oz テスト」があります。どちらも「人間が裏側で操作する」という共通点を持ちますが、用途が異なります。 | | ペーパープロトタイプ | Wizard of Oz | |---|---|---| | 素材 | 紙・付箋 | 実際のUI・デジタルデバイス | | 目的 | 概念・情報設計の検証 | インタラクション・AIレスポンスの検証 | | 制作時間 | 30〜60分 | 数時間〜数日 | | 向くフェーズ | プロトタイプ初期 | プロトタイプ中〜後期 | | ユーザーの認識 | 試作品とわかっている | リアルなシステムだと思っている | どちらを選ぶかの判断軸は「何を検証したいか」です。「この画面構成でタスクが完了できるか」という情報設計レベルの仮説はペーパーで十分です。「このAIの応答がユーザーに受け入れられるか」という体験レベルの仮説には Wizard of Oz が適しています。 詳細はプロトタイピング手法の全体像で解説しています。 --- やってみよう：60分チャレンジ 以下のステップで、今日中に最初のペーパープロトタイプを完成させます。 準備（5分） - [ ] 検証したい仮説を1文で書く（「ユーザーは〜できるか」の形式） - [ ] A4用紙・付箋・マジック・ハサミを揃える - [ ] テストに協力してくれる相手を1名確保する 制作（30分） - [ ] ユーザーフローを付箋に書き出す（画面名のみ） - [ ] 起点画面を描く（1枚1画面、太いマジックで） - [ ] フロー全体を描く（完成させない、必要な画面だけ） - [ ] 動的要素（ドロップダウン・モーダル等）を別紙に準備する テスト（20分） - [ ] スマートフォンで定点撮影を開始する - [ ] 「これは試作品です」とユーザーに伝える - [ ] 思考発話法を依頼する（「声に出しながら操作してください」） - [ ] 迷った箇所・予想外の動作をメモする 記録（5分） - [ ] テスト直後に3つの発見を書き出す - [ ] 最も重要な修正点を1つ決める - [ ] 可能なら修正してもう1名でテストする --- まとめ：ペーパープロトタイピングが変えること ペーパープロトタイピングは手法というより思考習慣です。「完成してから見せる」から「仮説があれば試す」への転換が、チームの検証サイクルを根本から変えます。 実際にやってみると、多くのチームが「これほど早く問題を発見できるとは思わなかった」という感想を持ちます。デジタルツールを開く前に紙で試す30分が、後続の何十時間もの作業を方向付けます。 次のステップはユーザビリティテストで、より精度の高い検証を設計することです。また、プロトタイプの前工程としてストーリーボードでユーザーシナリオを可視化する手法も参照してください。 --- 関連手法 - プロトタイピング手法の全体像 — ペーパー・Wizard of Oz・デジタルの使い分け - ウィザード・オブ・オズ法 — AI・自動化機能など動的インタラクションの検証に適した上位互換手法 - ストーリーボード — プロトタイプ前のシナリオ可視化 - ユーザビリティテスト — プロトタイプ後のテスト設計 - プロトタイピング — 用語定義と基本概念 --- ### ポイント・オブ・ビュー（POV）文 — 共感データを洞察に変換する視点定義の手法 URL: https://designthinking.studio/methods/point-of-view-method/ > 「ユーザーは〜を必要としている。なぜなら〜だから」という構造で、共感フェーズで集めた観察データを問題定義に変換する手法。書き方のステップ、よくある失敗、ファシリテーションのコツを実践的に解説する。 ポイント・オブ・ビュー（POV）文は、共感フェーズで集めた観察データを「解決すべき問題の定義」に変換するための文章フォーマットです。定義フェーズの核心的なアウトプットであり、この後の創造フェーズで使うHow Might We（HMW）の出発点になります。 POV文の基本構造 POV文の標準フォーマットは次の通りです。 [ユーザー] は、[ニーズ] を必要としている。なぜなら [インサイト] だからだ。 各要素の定義： - ユーザー： 共感インタビューや観察で出会った、具体的な人物。「34歳の会社員」ではなく「毎朝コーヒーを飲みながら通勤電車で30分を過ごす田中さん」のように、状況と文脈を含める - ニーズ： ユーザーが達成したいことや解消したいこと。「〜できること」「〜な状態」で表現する。解決策（「アプリがほしい」「機能がほしい」）にしないことが重要 - インサイト： なぜそのニーズがあるのかを説明する洞察。表面的な理由ではなく、観察・インタビューから引き出した「なるほど」という発見 なぜPOV文が必要か ワークショップでよく起こるのは、共感フェーズで膨大なインタビュー記録・観察メモが集まった後、チームが「さあ、アイデアを出そう」と創造フェーズに飛びつくパターンです。 この飛びつきが問題です。問題が定義されないまま解決策を生成しても、「誰のどんな問題を解く答えなのか」が不明瞭なアイデアの山ができるだけです。POV文はこの移行を構造化します。 実際にやってみると、POV文を書くプロセスで「私たちが本当に解くべき問題は何か」について、チームで初めて真剣に議論が生まれることが多い。 ステップ Step 1：共感データの棚卸し インタビュー記録・観察メモから「印象的な発言・行動・感情」を付箋に書き出します。1枚の付箋につき1つの発見を書きます。グループ全員の発見を壁に貼り出し、全体を俯瞰します。 Step 2：ユーザー像のプロファイリング 複数の人へのインタビュー・観察から得た発見を統合し、「誰のPOV文を書くか」を決めます。実在した1人の人物を元に書くか、複数のインタビューから構成した「典型的なユーザー像」を設定します。 ユーザー像は属性（年齢・職業・性別）ではなく「状況と文脈」で定義します。「30代の働く母親」より「保育園のお迎え後、夕食準備をしながら宿題も見なければならない状況の人」の方が、問題定義に接続しやすいユーザー定義です。 Step 3：ニーズを動詞で表現する ニーズは「〜を必要としている（needs to...）」で始まる動詞句で書きます。 ニーズの書き方の例（悪い例と良い例）： - 悪い例：「通知機能がほしい」→ これは解決策 - 悪い例：「便利なアプリがほしい」→ 抽象的すぎる - 良い例：「重要な情報を他の情報に埋もれさせないでいつでも確認できる状態にする」 - 良い例：「夕方の忙しい時間帯に、最小限の決断で夕食の準備を終わらせる」 Step 4：インサイトを「なぜ」から引き出す インサイトは「なぜそのニーズがあるのか」の洞察です。表面的な理由（「忙しいから」）ではなく、観察から得た「知らなければ気づかなかったこと」を書きます。 インサイトを引き出すための問い： - 「このユーザーが[ニーズ]を持つ背景には、何があるのか？」 - 「表面的な理由の、その奥に何があるか？」 - 「なぜ今の解決策では不十分なのか？」 インサイトの例：「料理の手順は覚えているが、『何を決めなければいけないか』が多すぎることへの疲弊感が、料理を億劫にさせている」 Step 5：POV文を書いて声に出して読む フォーマットに当てはめてPOV文を書きます。書いたら声に出して読み、以下を確認します： - ユーザーの状況が目に浮かぶか - ニーズが解決策ではなく、解決すべきことの表現になっているか - インサイトが「知らなければ気づかなかった発見」になっているか - このPOV文を読んだ人が「なるほど、この問題を解きたい」と思えるか 実例 共感インタビューから： 田中さん（45歳・管理職）は、毎朝の朝礼で部下に話すことを「前日の夜に考えなければならない」ことが負担だと言っていた。「話すことが思い浮かばないとき、プレッシャーを感じる」「何か役立つことを言わなければという義務感がある」 POV文： 「毎朝の朝礼で部下に向けて話す田中さんは、その日のチームに意味のある問いや気づきを届ける言葉を、日々の業務の流れの中から自然に見つけられることを必要としている。なぜなら『良いことを言わなければ』というプレッシャーが、スピーチを義務感のある作業にしてしまい、本来の目的であるチームとの対話を遠ざけているからだ」 ファシリテーションのコツ 複数のPOV文を書く 1つのプロジェクトで3〜5本のPOV文を書くことを推薦します。複数のユーザー像について書くことで、問題の多様な側面が見えてきます。創造フェーズでどのPOV文に集中するかを議論するプロセス自体が、問題定義の深化になります。 「ニーズvs解決策」の混同を防ぐ POV文を書く際に最も頻出する誤りは「ニーズ」の箇所に「解決策」を書いてしまうことです。「アプリが必要」「機能追加が必要」はすべて解決策です。「状態・体験・達成すること」という問いに変換して確認します。 チームで「アクション可能性」を確認する 書いたPOV文に対して「このPOVから、どんなHMWが生まれそうか？」という問いでテストします。アイデアの方向性が全く浮かばないPOV文は、ニーズかインサイトが曖昧なサインです。 よくある失敗と対策 失敗1：インタビューしていないユーザーのPOVを書く 「こういうユーザーがいるはずだ」という想像でPOV文を書いてしまうケース。POV文は必ず実際の観察・インタビューから引き出したデータを元に書く必要があります。 失敗2：インサイトが「事実の説明」になる 「忙しいから時間がない」はインサイトではなく事実の説明です。インサイトは「なぜその状況が問題として体験されるのか」の洞察であり、観察者の解釈が含まれます。 失敗3：ニーズを「より良い」で形容する 「より良い通知が必要」「より使いやすい画面が必要」は比較の基準が曖昧で、創造の方向性を制約します。具体的な状態・体験の言葉で書きます。 POV文の次のステップ POV文が完成したら、そのままHow Might We（HMW）への変換に進みます。「[ユーザー]が[ニーズ]を達成できるのは、どうすれば可能か？」という問いの形に変換することで、創造フェーズへの橋渡しが完成します。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Liedtka, Jeanne & Ogilvie, Tim, Designing for Growth, Columbia Business Press, 2011 --- ### ボディストーミング（Bodystorming） URL: https://designthinking.studio/methods/bodystorming-method/ > ボディストーミングは身体を使いシナリオを即興演技するプロトタイピング技法。所要60〜120分、4〜12名。ポストイットでは見えない空間・サービス接点の課題を発見する5ステップと、「下手でいい」宣言などファシリテーション実践を解説。 ボディストーミング（Bodystorming）は、身体を使ってサービスや製品のシナリオを即興演技することで、言葉や図解では見えないユーザー体験の課題とアイデアを発見するプロトタイピング技法です。デスクの前ではなく、実際の使用環境や想定される空間で身体を動かしながら思考します。 概要 ポストイットとホワイトボードでのブレインストーミングには、重大な盲点があります。「身体で体験したときに何が起きるか」が見えないことです。 たとえば、病院の受付フローをホワイトボードで設計したとき「完璧に見えた」動線が、実際に車椅子を使って移動してみると機能しないことが頻繁に起こります。 ボディストーミングは1990年代にIDEOやスタンフォードd.schoolで広まった手法です。ドラマ教育、インプロ（即興演劇）、サービスデザインの「サービス劇場」（Service Theatre）の考え方を取り込んだものでもあります。身体化された知識（Embodied Knowledge）を引き出すことで、言語化しにくい体験の課題が浮かび上がります。 ステップ Step 1：シナリオと役割を設定する 演じるシナリオを1〜2文で書きます。「空港のチェックインカウンターで初めての海外旅行をする70代の乗客」のように、ユーザーの属性・状況・目的を具体的に設定します。役割は「ユーザー役」「スタッフ役」「環境の障害物役（荷物・扉・窓口）」のように分担します。 Step 2：環境を即興で再現する 実際の環境に行ければベストですが、会議室の椅子を並べてカウンターに見立て、紙袋を荷物に見立てるなど、手近な道具で環境を即興再現します。この「ラフな環境設定」が重要で、精巧に作り込むほど「本番のカウンター」ではなく「作った模型」として扱われ始め、身体の動きが不自然になります。 Step 3：演じながら観察する シナリオをロールプレイします。演者は「台本なしで、ユーザーだったら何をするか」を即興で演じます。 観察者は演者が詰まる瞬間、迷う動作、不自然な姿勢、「あれ？」という表情をメモします。これらの「詰まり」がサービスデザイン上の問題のシグナルです。 Step 4：演者と観察者で共有する ロールプレイ終了後、すぐに振り返りを行います。演者に「どこが不自然だったか」「何を探していたか」「何に困ったか」を話してもらい、観察者の気づきと照合します。この対話から、設計上の前提と実際の体験のギャップが見えてきます。 Step 5：即興で「改善版」を演じる 「もしこうなっていたら？」という仮説を即座にロールプレイで試します。紙1枚で作ったサインを壁に貼る、椅子の配置を変えるなど、物理的な変更を加えながら再演することで、アイデアの効果を身体で検証できます。これが「身体でプロトタイピングする」という技法の核心です。 使い所 物理的な空間が関わるサービス 店舗、病院、ホテル、空港、公共交通機関など、ユーザーが身体を動かしながら使うサービスの設計にボディストーミングは特に効果的です。サービスブループリントに記載された「フロントステージ」の動線を検証する場として機能します。 デジタルとリアルが交差する体験 スマートフォンのアプリを使いながら実店舗で買い物するシナリオ、QRコードを読み取りながら会計するフローなど、デジタルと物理的な行動が混在する体験は、デスク上での設計では見えない問題を含んでいます。ボディストーミングで身体を使って試すことで、「アプリを操作しながら荷物を持つのが無理」という課題が初めて見えることがあります。 初期アイデアの粗削り検証 プロトタイプフェーズの初期段階では、紙プロトタイプと組み合わせることで、UIと物理的な動線を同時に検証できます。完成度の高いプロトタイプを作る前に、方向性の誤りを身体で発見することで、後の手戻りを防げます。 ファシリテーションのコツ 「下手でいい」と宣言する 参加者が「演技が得意ではないから」と萎縮するケースがよくあります。「演技の上手さではなく、身体が自然に感じることを探す場だ」と最初に宣言することが重要です。「プロの俳優のように演じる必要はない。むしろリアルな戸惑いが価値ある情報だ」というフレーミングが参加者の動きを解放します。 ファシリテーターは「止める権限」を持つ ロールプレイが始まると、参加者は没入してシナリオを完走しようとします。しかし「詰まり」が起きた瞬間に止めて確認することが、ファシリテーターの最も重要な仕事です。「今、何を探していましたか？」「その動作はなぜしたのですか？」と問いかけることで、即興の中に埋め込まれたインサイトを取り出します。 観察者を2役以上立てる 1人の観察者が「詰まり」「時間」「感情表現」すべてを記録するのは難しいです。「詰まり担当」と「感情表現担当」など、観察の焦点を分けた複数の観察者を立てると、見落としが減ります。 よくある失敗と対策 演技に徹しすぎてリアルが失われる 参加者が「上手く演じよう」と意識し始めると、本来のユーザー行動の代わりに、「うまく演じたユーザー行動」が記録されてしまいます。対策は、演じる前に「あなたが今日の朝コンビニに行ったときの行動を思い出しながら演じてください」というような具体的な体験を想起させることです。 環境設定に時間をかけすぎる 「もう少し本物に近い環境を作ろう」という欲求が生まれ、環境設定に1時間以上かけてしまうケースがあります。ボディストーミングはラフさが命であり、20分で環境を作って即演じ始めるスピード感が重要です。 振り返りが「良かった・悪かった」で終わる 「この部分がわかりにくかった」という感想に終わると、設計へのインサイトになりません。「なぜそこで詰まったか？」「どんな情報が足りなかったか？」という問いで振り返りを深めることが、次のプロトタイプへの橋渡しになります。 ポイント - ラフな環境設定を恐れない — 精巧さより身体の自然な動きが大事 - 「詰まり」を見逃さない — ファシリテーターは止める権限を持って観察 - 演技より体験 — 上手く演じることを求めず、リアルな戸惑いを歓迎 - 即改善を試みる — 振り返りで出た案をすぐにロールプレイで検証 - 身体化した発見を言語化する — 振り返りで「なぜ」まで掘り下げる ボディストーミングで発見した課題はジャーニーマップに落とし込み、テストフェーズでの検証計画へとつなぎます。またユーザーインタビューと組み合わせることで、言語データと身体データの双方からインサイトを立体的に捉えられます。ボディストーミングから得た発見をより深い検証へ展開する際は、エクスペリエンス・プロトタイピングが次の段階として機能します。体験シミュレーションをさらに構造化し、ユーザーを含めた形で検証できます。 --- 参考文献 - Tim Brown & Jocelyn Wyatt, "Design Thinking for Social Innovation", Stanford Social Innovation Review, Winter 2010 - John Zimmerman, Jodi Forlizzi & Shelley Evenson, "Research Through Design as a Method for Interaction Design Research in HCI", CHI 2007 - Sofia Hussain, "Empathic Design: Involving People with Disabilities in Design Processes", Aalto University, 2010 --- ### ボディストーミング応用 — サービスデザイン視点のアイデア発散 URL: https://designthinking.studio/methods/bodystorming-service-design/ > 身体を動かしながらアイデアを探索するボディストーミングを、サービスデザインの創造フェーズに応用する実践ガイド。サービスブループリントの検証・多様なステークホルダーの体験共有・サービスの「触れ方」を物理的に発見する具体的なファシリテーション手法を解説する。 ポストイットとホワイトボードのブレインストーミングには、見落としやすい盲点がある。 「身体を動かしたときに何が起きるか」が一切見えないことだ。 受付から検査室への動線、スーパーのセルフレジで戸惑う瞬間、スマートフォンを操作しながら荷物を持ち替える場面——これらは紙の上では「解決済み」でも、身体が動いた瞬間に問題が顕在化する。 サービスデザインの創造フェーズでボディストーミングを使う目的は、「アイデアを言葉で整理すること」ではなく、「アイデアを身体で試して、言葉では見えなかった課題と可能性を発見すること」だ。 なぜサービスデザインにボディストーミングが必要か サービスは「設計された体験」だ。どれほど精緻に書かれたサービスブループリントも、ユーザーが実際に動いたときの体験を完全に再現することはできない。 ワークショップでよく起こるのは、チームがサービスフローを「論理的に正しい」として合意した後、パイロット実施で「実際には動かない」ことが判明するケースだ。サービスのフロントステージ（ユーザーが直接接触する部分）を身体で演じてみることで、「待ち時間の感情的な重さ」「情報量の多すぎるサイネージの前での戸惑い」「スタッフの動線が交差する混乱」が、図面では見えない形で浮かび上がる。 ボディストーミングは1990年代にIDEOやStanford d.schoolで広まった手法だが、サービスデザインのコンテキストで使う場合、単なる「ロールプレイ」とは目的が異なる。「うまく演じること」ではなく「詰まる瞬間を発見すること」が目標だ。 詰まりこそが設計上の問題点のシグナルであり、創造フェーズではその詰まりを即座に「修正案の即興試行」につなげる。 --- サービスデザイン向けボディストーミングの全体フロー 前提：創造フェーズでの位置付け このセッションは共感フェーズでのリサーチと定義フェーズでのHMW（How Might We）策定を経た後に実施する。すでに「解くべき問い」が1〜3本定まっている状態で、ボディストーミングはその問いに対するアイデアを「言葉ではなく身体で発散・検証する」ために使う。 --- ステップ1：サービスシナリオの設計（15分） シナリオカードを作る 演じるシナリオを「ユーザー属性・状況・目的」の3点で1〜2文にまとめたシナリオカードを用意する。サービスデザインのコンテキストでは、特定の「タッチポイント」に焦点を当てたシナリオが機能しやすい。 シナリオカードの例（医療機関の受付サービスの場合）： 「初めての外来受診をする65歳の患者。スマートフォンの操作に不慣れで、受付方法が受診案内と異なっていると感じている。次に何をすべきか分からず、立ち止まっている。」 シナリオは「困っている状態」から始める。 問題なくサービスを利用している状態を演じても、設計上の洞察は得られにくい。不安・困惑・迷いを含んだシナリオが、「詰まり」を生み出しやすい。 役割を割り当てる サービスデザインのボディストーミングでは、以下の役割を設定する。 - ユーザー役（1〜2名）：シナリオの主人公。「この人物だったら何をするか」を即興で演じる - サービス提供者役（スタッフ・機械・システムの代理）（1〜2名）：「スタッフ」でも「自動受付機」でも演じる - 環境役（1名）：サインや障害物など、空間の要素を身体で表現する（「廊下を指差すサイン」を手で示す役割など） - 観察者（残り全員）：「詰まり担当」「感情表現担当」「時間担当」など、観察の焦点を分担する --- ステップ2：環境の即興再現（10分） 「ラフさ」を意図的に守る 会議室の椅子を並べてカウンターを作り、テーブルを機器に見立て、ホワイトボードを壁として使う。精巧に作り込む必要はなく、精巧に作り込んではいけない。 完成度が上がるほど、演者は「作り物の空間」として扱い始め、自然な身体の動きが失われる。 「あれが受付カウンターです」「この椅子は自動改札機です」という宣言だけで十分だ。参加者の想像力が補完する。 サービスデザイン特有の「環境設定チェックリスト」 - フロントステージ（ユーザーが見える部分）のタッチポイントを最低1つ物理化する - 「次に何をすべきか」を示すサイン・案内をラフに再現する（紙に書いてテープで壁に貼る） - 動線（ユーザーが移動するルート）を椅子や荷物で物理的に示す - 複数のタッチポイントが連続する場合、「ここからここへ移動する」というパスを設定する --- ステップ3：サービスシナリオのロールプレイ（20〜30分） 演じながら観察する ファシリテーターは「シナリオスタート」を宣言し、タイムキーパーとして機能する。演者は「台本なし・即興」でユーザーとして動く。 「このユーザーだったら、この環境で最初に何をするか？」から始まる。 観察者は演者が「詰まる瞬間・迷う動作・予想外の経路・繰り返す動作」を記録する。これらが設計上の問題のシグナルだ。 ファシリテーターは「止める権限」を積極的に使う。 演者が詰まった瞬間が、ボディストーミングの最も価値ある情報が生まれる瞬間だ。「今何を探していましたか？」「その動作はなぜしましたか？」という問いを止めて投げかけることで、即興の中に埋め込まれたインサイトを取り出す。 サービスデザイン視点の観察焦点 一般的なボディストーミングに加えて、サービスデザインでは以下の観察焦点が重要だ。 サービスの「見えない部分」の問題。 「スタッフが内部で作業しているときにユーザーはどう感じるか」——バックステージの動きがフロントステージの体験に与える影響を観察する。「待たされている」という感覚は、「待ち時間の長さ」よりも「何が起きているか見えない」ことから生まれることが多い。 複数タッチポイント間の「継ぎ目」。 ユーザーがあるタッチポイントから次のタッチポイントに移動する瞬間——「受付を終えてから待合に移動する」「診察室から会計窓口に移動する」——で何が起きるかを注視する。サービスの失敗の多くは「継ぎ目」で発生する。 情報の「渡し方」の問題。 スタッフがユーザーに情報を伝える瞬間——口頭・紙・サイン・端末画面——で、ユーザーがどう受け取るかを観察する。演者が「えっ？」と聞き返す瞬間、受け取った紙を2度見する動作が、情報設計の課題のシグナルだ。 --- ステップ4：即興改善の試行（20〜30分） これがサービスデザイン向けボディストーミングの核心だ。 ロールプレイで「詰まり」が発見されたら、その場で「改善案を即座に試す」。 紙にサインを書いて壁に貼る。椅子の配置を変える。「もしスタッフがここで声をかけたら？」という仮説を即座に演じる。 重要なのは、改善案を「言葉で議論する」のではなく「身体で試す」ことだ。 「こうすればいい」という提案を議論で洗練させるより、「試して見てみる」ことで、言葉では見えなかった別の問題や予想外の効果が発見される。 改善の即興試行を促すファシリテーター発言例 - 「今の詰まり、1つだけ変えるとしたら何を変えますか？すぐ試してみましょう」 - 「もし（サイン / 声かけ / 動線）を変えたら、演じ直してみてください」 - 「その問題、10秒で何か作って壁に貼ってみてください」 --- ステップ5：観察データの構造化（15〜20分） ロールプレイ終了後、すぐに振り返りを行う。「良かった・悪かった」の評価ではなく、「なぜ詰まったか」という問いで振り返りを構造化する。 振り返りの問いセット（サービスデザイン版） - 演者への問い： 「どのタッチポイントで最も迷いましたか？」「どんな情報が足りなかったですか？」「スタッフ（またはシステム）への期待と実際のずれはどこでしたか？」 - 観察者への問い： 「最も多く詰まりが起きた場所はどこですか？」「予想外の動きをした瞬間はいつですか？」「感情が変化したと思われる瞬間はどこですか？」 - 統合の問い： 「発見した詰まりのうち、設計で解決できるものはどれですか？」「今日発見したことを踏まえて、HMWを書き直すとしたらどうなりますか？」 この振り返りから得られた「設計上の問題点と改善の仮説」を付箋に書き出し、サービスブループリントの該当箇所に貼り付けることで、次のプロトタイピングへの橋渡しになる。 --- サービスデザインのコンテキスト別応用 店舗・商業空間 購買行動・回遊動線・スタッフとのインタラクションを演じる。「商品を探す」というシナリオで演者が迷子になる経路が、サイン計画の見直し箇所を示す。 実際にやってみると、参加者が「当たり前にできると思っていた動作」——棚から商品を取り出す、セルフレジを操作する——で予想外に詰まることが頻繁に起こる。設計者の「できて当然」という前提が崩れる体験が、チームの共感レベルを引き上げる。 デジタル・フィジカル融合サービス スマートフォンアプリを操作しながら実店舗で動くシナリオ、QRコードを読み取りながら会計するフローは、ボディストーミングで最も大きな発見が生まれやすい領域だ。「アプリを操作しながら荷物を持ち替えることが不可能」「QRコードを読み取る角度でカメラが機能しない」という物理的な制約は、デスク上での設計では見えない。 デジタルプロトタイプ（スマートフォン画面）と物理的な小道具を組み合わせたハイブリッドなボディストーミングが、このコンテキストで有効だ。 公共サービス・行政窓口 多様なユーザー（高齢者・外国語話者・障害のある当事者）の視点を複数のシナリオとして用意し、同じ空間で演じ比べる。「若い行員には1分でできる操作が、70代のユーザーには7分かかる」という時間の体験差が、身体レベルで可視化される。 異なるユーザー属性のシナリオを連続して演じることで、「これは特定のユーザーにとってだけ問題か」という問いが機能する。 --- ファシリテーションのコツ 「演技の上手さ」を明示的に脱価値化する セッション開始時に必ず伝える。「上手く演じることはこのセッションの目標ではありません。身体が自然に感じる戸惑いや迷いが、最も価値のある情報です」。この宣言が参加者の身体を解放する。 演技力への自意識が残ると、ユーザーの「本物の詰まり」ではなく「演じた詰まり」が記録されてしまう。 止めるタイミングの見極め ファシリテーターの最も重要なスキルは「止める」判断だ。演者が詰まった瞬間、予想外の動きをした瞬間、観察者が同時にメモを取り始めた瞬間が止めどきだ。「今そこで何が起きましたか？」という問いを、時間の流れを切って投げかける。 この「止める→問う→再演する」のリズムが、ボディストーミングのセッションを情報密度の高いものにする。 観察者の焦点を事前に分担する 「詰まり担当」「時間担当」「感情表現担当」「物の扱い方担当」という観察焦点の分担を事前に設定する。1人の観察者がすべてを見ようとすると、最も重要なシグナルを見落とす。観察の焦点を分散させることで、同じシーンから複数の角度のデータが得られる。 --- よくある失敗と対策 環境設定が「完璧な再現」を目指し始める 「もう少し本物に近くしよう」という欲求が生まれ、環境設定に1時間以上かけてしまうケースがある。ボディストーミングのラフさは欠点ではなく設計上の特性だ。 「この椅子をカウンターと思ってください」という宣言から10分で演じ始めるスピード感が、セッションの密度を保つ。精巧な環境は「それを壊したくない」という心理的抑制を生み、自由な行動の試行を妨げる。 振り返りが「感想」で終わる 「ここが使いにくかった」という感想は、設計へのインサイトにならない。「なぜそこで詰まったか」「どんな情報が足りなかったか」「もし◯◯があったらどう変わったか」という問いで振り返りを駆動する。 感想を問いに変換する責任がファシリテーターにある。 創造フェーズ後半での活用機会を見逃す ボディストーミングを「最初のアイデア探索」だけに使うのはもったいない。プロトタイプフェーズの初期検証、テストフェーズ前の「仮説確認」としても機能する。サービスの改善案が言語化されたタイミングで「それを演じてみる」という使い方が、実践では特に価値が高い。 --- 次のステップへの接続 ボディストーミングで発見した課題と改善仮説を、次のフェーズへとつなぐ。 サービスブループリントの「フロントステージ」行に、発見した「詰まり」を書き加える。バックステージとフロントステージの接続を再設計する起点になる。 ジャーニーマップの感情曲線に、演者から語られた感情の変化を加筆する。「設計上の意図した体験」と「実際の体験」のギャップが可視化される。 プロトタイプフェーズでは、ボディストーミングで「最も詰まりが多かった場面」を優先的に紙プロトタイプや低忠実度のデジタルプロトタイプで検証する。 --- セッションのポイント - ラフさを守る — 精巧な環境設定は不要。20分で作って演じ始める - 「詰まり」こそが情報 — 詰まった瞬間を止めて問いかけることがファシリテーターの仕事 - 即改善を試みる — 発見した詰まりに対して「変えて演じ直す」を繰り返す - 身体の発見を言語化する — 振り返りで「なぜ」まで掘り下げ、設計の言語に変換する - 多様なユーザーシナリオを用意する — 一種類のシナリオで終わらず、異なる属性・状況を演じ比べる --- 参考文献 - Tim Brown & Jocelyn Wyatt, "Design Thinking for Social Innovation", Stanford Social Innovation Review, Winter 2010 - Marc Stickdorn & Jakob Schneider (eds.), This Is Service Design Thinking, BIS Publishers, 2011 - Sofia Hussain, "Empathic Design: Involving People with Disabilities in Design Processes", PhD dissertation, 2010 - IDEO, HCD Toolkit: Human Centered Design, IDEO, 2009 - Kimbell, Lucy, "The Turn to Service Design", in Julier & Moor (eds.), Design and Creativity, Berg, 2009 --- ### ユーザーインタビュー URL: https://designthinking.studio/methods/user-interview/ > ユーザーの行動・感情・動機を深く理解するための対話型リサーチ手法。共感フェーズの中核をなすメソッド。 ユーザーインタビューは、対話を通じてユーザーの行動・感情・動機を深く理解するリサーチ手法です。共感フェーズの中核をなすメソッドであり、アンケートやアクセス解析では見えない「なぜ」に迫ります。 概要 数値データは「何が起きているか」を教えてくれますが、「なぜそうするのか」は教えてくれません。 ユーザーインタビューは、その「なぜ」を解き明かすための最もシンプルで強力な手法です。 ワークショップでよく起こるのは、チームメンバー全員が「ユーザーのことは分かっている」と思い込んでいるケースです。しかし実際にインタビューをしてみると、想定と現実のギャップに驚かされることがほぼ毎回起こります。その驚きこそが、イノベーションの出発点になります。 準備：インタビューの成否は始まる前に決まる 対象者のリクルーティング 「誰に聞くか」がインタビューの質を決定します。ターゲットユーザー像を明確にした上で、5〜8名を確保するのが基本です。極端なヘビーユーザーとライトユーザーの両方を含めると、幅のあるインサイトが得られます。 リクルーティングで注意したいのは、「話が上手い人」ばかりを選ばないことです。言語化が苦手な人の行動観察から、むしろ深いインサイトが見つかることがあります。 質問設計 質問は大きく3層で構成します。導入質問（アイスブレイク）、核心質問（行動と動機の探索）、深掘り質問（感情と価値観への接近）の順に設計します。 具体的な質問例を挙げます。 - 「ふだん、〇〇をするとき、どんな手順で進めていますか？」（行動の再現） - 「最後に〇〇で困ったときのことを教えてください」（具体的エピソード） - 「そのとき、どんな気持ちでしたか？」（感情への接近） 「はい/いいえ」で答えられるクローズド質問を避けることが鉄則です。「〇〇は便利ですか？」ではなく、「〇〇を使ったときのことを聞かせてください」と聞きます。 環境設定 インタビューの場所は対象者がリラックスできる環境を選びます。オフィスの会議室よりも、カフェや対象者の普段の作業環境の方が自然な回答を引き出しやすいです。 録音の許可は必ず事前に取ります。ノートテイカーを1名配置し、インタビュアーは対話に集中できる体制を作るのが理想です。 実施のコツ：聞くことは、黙ることである オープン質問を貫く 「それについてもう少し詳しく聞かせてください」「具体的にはどういうことですか？」この2つのフレーズだけで、インタビューの大半は回せます。 質問リストに縛られすぎず、対象者の話の流れに乗ることが重要です。 沈黙を恐れない 対象者が黙った瞬間、つい次の質問を投げたくなります。しかし沈黙は思考の時間です。3〜5秒の間を置くだけで、対象者はより深い回答にたどり着くことが多いです。 参加者からの声として、「沈黙が怖くて、つい自分から喋ってしまった」という反省は定番です。聞き手が沈黙に耐えるトレーニングは、インタビュー前に必ず行っておくべきです。 「なぜ」の深掘り（5 Whys） 表面的な回答に対して「なぜ」を繰り返すことで、本質的な動機や価値観に迫ります。 ただし、「なぜ？」を直接ぶつけると尋問のように感じられる場合があります。 代わりに使えるフレーズがあります。「それはどうしてそう思われたんですか？」「きっかけは何かありましたか？」「なぜ」の意図を保ちつつ、柔らかい表現に変換するのが実践的なテクニックです。 解決策を提示しない インタビュー中にユーザーが困りごとを話すと、つい「こういう機能があれば解決しますか？」と聞きたくなります。これはインタビューにおける最大の禁忌です。 解決策の提示はユーザーの思考を誘導し、本来の行動や感情から遠ざけます。 よくある失敗と対策 誘導質問をしてしまう 「この機能は使いやすいと思いますか？」のように、期待する回答を暗示する質問は、インタビューの価値をゼロにします。対策は、質問を事前に書き出し、第三者にチェックしてもらうことです。 相手の発言を言い換えてしまう 「つまり〇〇ということですね？」という要約は便利ですが、インタビュアーの解釈が混入するリスクがあります。「おっしゃったのは〇〇ということですか？」と、対象者自身に確認を委ねる方が正確です。 サンプル数を増やしすぎる 20人、30人とインタビューを重ねても、5〜8人を超えると新しいインサイトの発見率は急激に下がります。 人数を増やすよりも、1人あたりの深掘りに時間を使う方が効果的です。 分析：データをインサイトに変える 親和図法（Affinity Diagram） インタビューの発言を付箋に書き出し、類似するものをグルーピングしてパターンを見つけます。 1セッションあたり30〜50枚の付箋を目安にすると、分析しやすい粒度になります。 インサイトの抽出 グルーピングから浮かび上がるパターンが、インサイトの種です。良いインサイトは「意外性」と「行動可能性」を兼ね備えています。 「ユーザーは使いやすさを求めている」は当たり前すぎてインサイトではありません。 「ユーザーは効率よりも、自分がコントロールしている感覚を優先する」のように、チームの前提を覆す発見がインサイトです。 POV（Point of View）ステートメントへ 抽出したインサイトは、「[ユーザー]は[ニーズ]を必要としている。なぜなら[インサイト]だから」の形式でPOVステートメントにまとめます。このステートメントが、次の問題定義フェーズへの橋渡しになります。 ポイント - 準備が8割 — リクルーティングと質問設計に十分な時間をかける - 聞くことに徹する — 対話の主役はインタビュアーではなく対象者 - 記録は正確に — 録音＋ノートテイクの二重体制を基本とする - 分析は即日 — 記憶が鮮明なうちに付箋書き出しとグルーピングを行う - 5人で始める — 完璧な計画を立てるより、まず5人に会いに行く インタビューで集めたデータは共感マップや親和図法（KJ法）で整理し、問題定義フェーズへとつなげます。 --- 参考文献 - Interviewing Users: How to Uncover Compelling Insights — Steve Portigal, Rosenfeld Media, 2013 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） - Nielsen Norman Group, "User Interviews: How, When, and Why to Conduct Them", nngroup.com, 2019 --- ### ユーザビリティテスト URL: https://designthinking.studio/methods/usability-testing/ > デザイン思考のテストフェーズで実施するユーザビリティテストの具体的な手法。5人のテストで問題の85%が見つかるNielsen/Normanの知見を軸に、準備・実施・分析のステップを解説する。 プロトタイプを作った。チームは「いい感じだ」と思っている。だが、 ユーザーの前に出した瞬間に崩れる前提 が必ずある。ユーザビリティテストは、その前提を壊すための手法である。 なぜ5人で十分なのか 「もっと大勢に聞かないと信頼できないのでは」——ワークショップでよく出る質問だ。Jakob Nielsen の研究（2000年）が明快な答えを出している。 5人のテストで、ユーザビリティ問題の約85%が発見できる 。15人に増やしても発見率は100%に届かず、コストだけが膨らむ。 重要なのはサンプル数ではなく、 テストの回数（イテレーション） である。5人でテストし、改善し、また5人でテスト。この反復が問題を潰す最短ルートになる。 準備——テスト前に決めること テストの目的を絞る 「全体的な使い勝手を見たい」は目的ではない。 検証したい仮説を3つ以内 に絞る。たとえば「ユーザーは3ステップ以内に申し込み完了まで到達できるか」「エラーメッセージを読んで自力で復帰できるか」のように、観察可能な行動で定義する。 タスクシートの作成 ユーザーに実行してもらうタスクを文書化する。ここで手を抜くと、テスト当日に何を見ればいいか分からなくなる。 - タスクは具体的なシナリオで提示する。「検索してください」ではなく「来週の金曜日、渋谷で5人のディナーを予約してください」 - 順序効果を避けるため、タスクの実行順をテスターごとにランダム化する - タスク数は 5〜7個が上限 。それ以上は疲労でデータの質が落ちる テスターのリクルーティング 理想は実際のターゲットユーザーだが、完璧を待つ必要はない。 「近い属性の人」で十分 スタートできる。社内の別部署のメンバー、知人、家族でもプロトタイプ初期段階なら有効な発見がある。 ただし1点だけ絶対に守るべきルールがある。プロジェクトに関わったメンバーをテスターにしてはならない。文脈を知っている人間のフィードバックは、ほぼ役に立たない。 実施——テスト当日の進め方 役割分担 - ファシリテーター ——テスターに指示を出し、質問に答える（ただし答えを誘導しない） - 記録係 ——テスターの発言・行動・表情をリアルタイムで記録する - 観察者（任意）——別室またはモニター越しに観察。テスト中の介入は禁止 テストの流れ - 導入（5分） ——テスターに「あなたをテストしているのではなく、プロトタイプをテストしている」と明確に伝える。これを省くと、テスターが正解を探そうとしてしまう - タスク実行（20〜30分） ——タスクシートに沿って順番に実行してもらう。 「考えていることを声に出してください」 と依頼する（思考発話法） - 事後インタビュー（10分） ——タスク中に気になった行動について掘り下げる。「さっき一瞬止まりましたが、何を考えていましたか？」のように具体的に聞く ファシリテーターの禁止事項 実際にやってみると、ファシリテーターが最もやりがちなミスは「助けてしまう」ことだ。テスターが操作に詰まると、つい「そこは右上のボタンを」と言いたくなる。だが、 その沈黙こそが最も価値のあるデータ である。 - 操作を教えない - 「はい、そうです」と正解を肯定しない - 「普通はこう使います」と説明しない - テスターの発言に同意も否定もしない 分析——発見を次のアクションに変える 観察記録の整理 テスト終了後、記録係の記録とファシリテーターの所感を突き合わせる。以下の3つに分類すると整理しやすい。 - クリティカル ——タスクを完了できなかった、または重大なエラーが発生した問題 - メジャー ——タスクは完了したが、明らかに迷った・時間がかかった問題 - マイナー ——気づいたが、タスク完了に大きな影響はなかった問題 パターンの発見 5人中3人以上が同じ箇所でつまずいた場合、それは個人の問題ではなく 設計の問題 である。逆に1人だけが困った問題は、優先度を下げてよい。 改善の優先順位 クリティカルな問題から対処する。全部を一度に直そうとすると、何が効いたのか分からなくなる。 1サイクルで直すのは3つまで 。修正したら再テストで効果を検証する。 よくある失敗パターン ワークショップでよく起こるのは、テスト結果を「自分たちの解釈」で歪めてしまうことだ。テスターが「分かりにくかった」と言ったのに、「慣れれば大丈夫」と片づけてしまう。これではテストした意味がない。 もうひとつの典型的な失敗は、テスト結果を報告書にまとめて終わりにすること。ユーザビリティテストのゴールは報告書ではない。 プロトタイプの改善とその検証 である。テストから改善までの期間は短いほどよい。理想は同じ週のうちに修正して再テストすること。 まとめ——テストは終わりではなく始まり ユーザビリティテストは、デザイン思考のテストフェーズの中核をなす手法である。5人で始め、改善し、また5人でテストする。この反復が、ユーザーにとって本当に使えるプロダクトを生み出す。 完璧なプロトタイプを作ってからテストするのではなく、 不完全な段階でこそテストする 。紙のプロトタイプでも、手描きのワイヤーフレームでも、ユーザーの前に出せば発見がある。まずは5人。まずは1回。手を動かすことから始める。 テスト結果の分析には親和図法（KJ法）を活用することで、複数のテスターにまたがるパターンを素早く発見できます。「使えること」の検証に加え、ユーザーが感情的に「好か」どうかを測定したい場合は、Desirability Testing とユーザー検証完全ガイドで Microsoft Reaction Cards を使った手法を確認してほしい。 --- 参考文献 - Jakob Nielsen & Thomas K. Landauer, "A mathematical model of the finding of usability problems", INTERCHI '93 Proceedings, 1993 - Steve Krug, Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability, 3rd edition, New Riders, 2014 - Nielsen Norman Group, "Why You Only Need to Test with 5 Users", nngroup.com, 2000 --- ### ライトニング・デモ（Lightning Demo） URL: https://designthinking.studio/methods/lightning-demo/ > デザインスプリントの火曜日に実施する3分間のアイデアショーケース手法。社内外の優れた解決策を3分ずつ紹介し合うことで、ゼロから考える代わりに「盗める」アイデアを素早く集める発散技法。所要60〜90分、3〜7名。 「まったく新しいアイデアを出せ」と言われると、人は思考が止まる。白紙のプレッシャーは創造性を妨げる。 ライトニング・デモ（Lightning Demo）はその逆を行く。「すでに存在する優れた解決策から盗め」というのがこの手法の出発点だ。各メンバーが自分の好きなプロダクト・サービス・事例を3分で紹介し、チームがそのエッセンスを素早く収集する。 デザインスプリントにおける位置づけ ライトニング・デモはJake Knapp、John Zeratsky、Brad Kowitzが2016年に著した『Sprint——最速仕事術』で体系化された手法だ（Scribner, 2016）。 Google Venturesが確立したデザインスプリントの5日間プロセスでは、火曜日の午前に位置する。月曜日に問題の全体像と長期目標を整理し、火曜日に入るとチームは「どう解くか」というモードに切り替わる。ライトニング・デモはその入口を担う。 ゼロから考える代わりに、世の中にすでに存在する解決策を見渡す。同業他社だけでなく、異なる業界、異なる文脈の事例も対象になる。重要なのは「完コピ」ではなく「着想の採掘」だ。 なぜ3分なのか 3分という制約には明確な意図がある。 深い説明を省くためだ。5分以上になると、発表者は製品の全機能を説明しようとし始める。3分に限定することで、チームが本当に借用できる「Big Idea（核心アイデア）」だけを取り出す訓練になる。 Knappは「各デモの後に、このプロダクトの最も参考になるアイデアは何か？と問いかける」と述べている。3分のデモの後、そのひとつの問いに答えることが手法の核だ。 実施手順 準備（前日〜当日朝） 各メンバーが「見せたい事例」を1〜3件準備する。テーマは前日に確定した「課題と長期目標」に関係するものが基本だが、まったく異なる業種の事例も歓迎する。 探す場所の例: - 自分が使っているプロダクトやサービス - 競合や関連市場の製品 - 受賞デザイン事例（Webby Awards, iF Design Award等） - 全く異なる業種でシステムとして面白いもの（物流・金融・ゲームなど） 「正解」を探すのではなく、「何かひとつ参考にできるもの」を持ち寄るスタンスが重要だ。 ライトニング・デモ本番 - 発表ルールの確認（5分） ファシリテーターが3分タイマーとルールを説明する。制限時間を超えたら遮断する旨を明確にしておく。「完璧な解決策を探しているのではなく、盗めるアイデアを探している」という目的の共有も欠かせない。 - 各メンバーが3分で発表（人数×4〜5分） タイマーをセットして発表開始。時間は厳格に守る。モニターや大型スクリーンがあれば、実際の画面を見せながら進めると具体性が増す。 ファシリテーターは各発表が終わるたびに、シンプルに問う。「このプロダクトから借用できるBig Ideaは何ですか？」 - 「Big Idea」をリアルタイムで可視化する（発表と並行） 誰か一人（発表者以外）が、各デモから抽出された核心アイデアを大判付箋か模造紙に簡単なスケッチと言葉で書き留める。この記録が午後の「4ステップスケッチ」のインプットになる。 - 全員の発表後にざっと振り返り（15〜20分） 全デモが終わったら、集まったBig Ideaを並べて全体を見渡す。「これとこれを組み合わせたら面白いかもしれない」という会話が自然に起きれば成功だ。 どんな事例を持ち寄るか 良いライトニング・デモの事例には傾向がある。 解決したい課題と類似した問題を解いているものが最も直接的なインスピレーションになる。同じ業界の競合からではなく、「同じ構造の問題を違う文脈で解いているプロダクト」が意外なアイデアを生む。 例として:「複雑な情報を素早く理解させる」という課題なら、銀行のオンラインダッシュボードだけでなく、フィットネスアプリの進捗表示、ゲームのHUD（ヘッドアップディスプレイ）、空港の出発案内板も良い参照先になる。 通常のブレーンストーミングとの違い 通常のブレーンストーミングでは、参加者は自分の頭の中にあるアイデアを出す。既知の情報に限定される上、ゼロから考える負荷が高く、「安全な無難なアイデア」が多くなりやすい。 ライトニング・デモでは、実在するプロダクトを参照する。すでに市場で機能しているもの、ユーザーに受け入れられているものを素材にするため、アイデアに根拠が生まれる。またスクリーンや写真を見ながら話すことで、全員が同じ具体的な対象を共有し、議論がぶれない。 1週間のスプリント以外での活用 ライトニング・デモはデザインスプリントの外でも有効だ。 プロジェクト初期のキックオフに20〜30分設けることで、チームが参照する「共通のビジョンボード」が生まれる。また、行き詰まったアイデア発散セッションのウォームアップとして使うと、「何も出てこない」状態を打開するきっかけになる。 ファシリテーターが注意すべき点は一つ。「このプロダクトが正解だ」という議論に落ちないようにすることだ。目的はインスピレーションの収集であり、採用の判断ではない。「借用できるBig Ideaは何か」という問いを繰り返し使うことで、会話の方向を保てる。 --- ### ラウンドロビン・アイデエーション — 全員が平等に発想し、アイデアを連鎖させる URL: https://designthinking.studio/methods/round-robin-ideation/ > 1人ずつ順番にアイデアを出し、前の人のアイデアを踏み台に展開する発散技法。声の大きい人への集中を防ぎ、内向きなチームメンバーからも新鮮な発想を引き出す実践的ワークショップ手法。 「ブレインストーミングのはずが、結局3人しか発言していなかった」——デザイン思考のワークショップで繰り返し起きる問題です。 自由発言形式のブレインストーミングは、積極的に話す参加者にアイデアが集中しやすい構造を持っています。内向きな傾向のある人や、専門領域外のアイデアを出すことに躊躇する人は、黙って場を観察することを選びます。その結果、集まるアイデアが特定の人の思考パターンに偏ります。 ラウンドロビン・アイデエーションは、全員が順番に発言する構造を設計に組み込むことで、この不均衡を解消します。 手法の概要 ラウンドロビンの語源は「循環する」です。スポーツのリーグ戦で全チームが対戦する方式と同じ言葉を使います。アイデエーションのラウンドロビンでは、参加者が輪になり、1つのHMW問いに対して順番に1つのアイデアを出します。 Google の Design Sprint Kit でも採用されており、自由発言型のブレインストーミングと対比して、構造的なアイデア収集手法として位置づけられています。 口頭型とカード型の2バリエーション 口頭型（Verbal Round Robin）: 参加者が順番に声でアイデアを言う。ファシリテーターが付箋に書きながら進める。テンポが速く、アイデアが言葉から広がりやすい。 カード型（Written Round Robin）: 各自がカードや付箋にアイデアを書き、隣の人に回す。受け取った人はそのアイデアを踏み台に新しいアイデアを書いて、また隣に回す。沈黙の中で進み、書くことで思考が整理される。内向きなチームメンバーが特に力を発揮しやすい。 実際にやってみると、口頭型は場のエネルギーが上がりやすい反面、前の発言に引きずられる。カード型は時間はかかるが、物理的に「他の人の紙を引き継ぐ」という行為がアイデアの連鎖を促します。 実施ステップ ステップ1: HMWを全員が見える位置に置く（5分） アイデエーションはHMW（How Might We）問いに対して行います。問いが見えない状態で始めると、アイデアが問いからズレていきます。 ホワイトボードや大きな紙に大きく書き、常に視野に入る位置に置きます。 ステップ2: ルールの説明（3分） 参加者に以下を伝えます: - 1人につき1アイデアを出す（複数まとめて言わない） - 批判・評価はしない（「それは難しい」「すでにある」はなし） - 前の人のアイデアに触発されてもよい、全く別の方向でもよい - パスは原則なし（出なければ「前の人のアイデアを少し変えて」でもよい） - 発言中は他の人は静かに聞く ステップ3: ラウンドを回す（10〜20分） 1ラウンドは全員が1回発言すること。3〜5ラウンドを目安に回します。 口頭型の場合: 「では Aさんから時計回りで」と開始。ファシリテーターは発言されたアイデアを素早く付箋に書きながら、リズムを作ります。 カード型の場合: 各自にカードを1枚配布し、2〜3分でアイデアを書く → 右隣に回す → 受け取ったカードを見て触発されるアイデアを新しいカードに書く → 繰り返す。 ステップ4: アイデアの収集と可視化（5〜10分） ラウンド終了後、出たアイデアを壁に貼り出します。量を確認し、ドット投票やアフィニティグルーピングで収束フェーズに移ります。 ファシリテーションのコツ 最初のラウンドのテンポをゆっくりにする: 最初の1ラウンドは参加者全員が「こんな感じでいいのか」を確認している時間です。ファシリテーターが「良いアイデアですね」と評価せず、「ありがとうございます、次はBさん」とフラットに続けることで、「どんなアイデアでも出してよい」という空気が作れます。 「私が言いたかったことを言われた」問題に対処する: ラウンドロビンの途中で「さっきCさんが言ったことと同じ」という状況が起きます。その場合は「同じ方向で少しズラすと?」と問うか、「同じ方向でも、別の視点から言ってみてください」と促します。 5〜6ラウンドを超えると効果が薄れる: アイデアの多様性は最初の3〜4ラウンドで大半が出ます。それ以降は「出し尽くした感」が強まり、参加者の思考が収束に向かいます。ここがラウンドロビンを終えてCrazy 8sや自由ブレストに切り替えるタイミングです。 カード型では「絶対に読まなければならない」プレッシャーを解消する: カード型で受け取ったアイデアが全く関係ない方向でも、「触発されたアイデアを書けばよい」という意識を持たせます。「このアイデアを改善する」のではなく「このアイデアが引き金になって何か思いついたことを書く」のが正しい使い方です。 ブレインストーミングとの使い分け | 観点 | 自由型ブレインスト | ラウンドロビン | |---|---|---| | 向いている場面 | エネルギーが高い・アイデアが出やすいチーム | 静かな・発言が偏るチーム | | 発言の均等性 | 発言量に差が出やすい | 構造的に均等 | | アイデアの連鎖 | 速い（聞いてすぐ反応）| じっくり（前アイデアを消化してから） | | 必要なファシリ技術 | 場のエネルギー維持・沈黙への対処 | ルール管理・テンポ維持 | | 適したチーム規模 | 5〜12名 | 3〜8名 | ラウンドロビンは「全員が発言した」という体験を作ることに価値があります。声が出にくかったメンバーが「自分のアイデアがあそこに貼ってある」という所有感を持つことで、その後の収束フェーズへの関与度も上がります。 Crazy 8s との組み合わせ ラウンドロビン（口頭型）で「1ラウンド5分を3回」実施し、全員の頭が温まったタイミングで Crazy 8s に移ると、スケッチの質が上がります。 ラウンドロビンで他のメンバーのアイデアを聞いた後に個人スケッチをすると、「自分では思いつかなかった方向」と「自分ならではの解釈」が混ざった多様性の高いスケッチが出てきます。 よくある失敗と対策 失敗1: ルールの周知が不十分で批判が出る 「それはもう存在しますよ」「それは難しくないですか?」という発言がラウンド中に出ると、後のラウンドで発言が萎縮します。 対策: ルール説明の際、「このフェーズでは批判・評価は一切しません。発言後の問い直しも禁止です」と明示する。ルール違反が出たらファシリテーターが穏やかに「それはあとで議論しましょう、今は出すだけです」と止める。 失敗2: パスが連続して空気が重くなる 発言できない参加者が複数続くと、場全体が固まります。 対策: パスのルールを事前に「前の人のアイデアを少し変えるだけでOK」と伝えておく。「全く関係なくてもOK」という自由度を確認する。それでも詰まっていれば「今回はパスOKで次の人へ」と軽く流し、後のラウンドで機会を作る。 失敗3: アイデアが似たり寄ったりになる 最初の1〜2人のアイデアが「正解っぽい」と、後の参加者が無意識にその方向に寄ってしまいます。 対策: 3〜4ラウンド後に「ここまでと全く逆の発想をしてみましょう」という逆転指示ラウンドを1回入れる。また「最も馬鹿げたアイデア」専用のラウンドを1回設けると多様性が一気に広がります。 関連項目 - クレイジーエイト（Crazy 8s） - ブレインストーミング・SCAMPER - ドット投票（Dot Voting） - アフィニティダイアグラム - How Might We（HMW） --- ### ラピッドプロトタイピング・ツールキット｜低コスト高速検証の6手法と使い分け URL: https://designthinking.studio/methods/rapid-prototyping-toolkit/ > ラピッドプロトタイピングの代表的な6手法（ペーパープロト・ロールプレイ・スケッチ・クリック可能モック・Wizard of Oz・サービスサファリ）を、コスト・忠実度・用途の3軸で整理。いつ・どの手法を選ぶべきかの判断基準をd.school・IDEOの知見をもとに解説する。 プロトタイプを「完成品に近づけてから見せる」という発想は、デザイン思考の原則と逆行します。Stanford d.schoolが繰り返し強調するのは「バイアス・トゥワーズ・アクション（bias toward action）」——考える前に作り、作ることで考える、という姿勢です。 ラピッドプロトタイピングの目的は精度の高い試作を作ることではありません。「今わかっていないことを、最も早く・安く検証する」ための手段を選ぶことです。 --- プロトタイピングの「忠実度」を理解する 手法を選ぶ前に、忠実度（fidelity）の概念を整理しておく必要があります。 忠実度とは、プロトタイプが最終製品にどれほど近いかを示す指標です。低忠実度プロトタイプ（Lo-Fi）は粗く、素早く、安価です。高忠実度プロトタイプ（Hi-Fi）は精巧で、時間とコストがかかります。 重要な原則は「問いに合わせて忠実度を選ぶ」ことです。「このコンセプトは解くべき問題に対応しているか」という問いには、紙1枚のスケッチで十分です。「このUI操作は直感的か」という問いには、クリック可能なモックアップが必要です。 忠実度が高すぎるプロトタイプは、二つの問題を引き起こします。第一に、ユーザーが「批判しにくい」と感じます。精巧に作られたものに対して「これは違う」と言うことへの心理的抵抗が生まれます。第二に、チームが「作ることへの投資」を守りたくなり、ユーザーのフィードバックを歪めて解釈し始めます。 --- 6つの手法と使い分け - ペーパープロトタイプ 概要：紙に手書きでUI・サービス画面・フロー図を描き、ユーザーに操作してもらう。 向いている場面：概念の妥当性確認、画面設計の初期段階、複数のコンセプトを比較する場合。 基本手順： - A4用紙に主要画面を1枚ずつ手書き（デジタルツール不要） - 「進む」「戻る」「選択する」操作を想定した別紙を用意 - ユーザーにタスクを与え、紙を操作させながら観察 - ファシリテーターが「コンピューター役」として、ユーザーの操作に応じて次の紙を差し替える 注意点：スケッチの上手さは関係ありません。粗ければ粗いほど「まだ初期段階だから意見を言いやすい」とユーザーが感じます。 --- - ロールプレイ・シナリオ演技 概要：サービス体験をチームメンバーが演じることで、インタラクションの問題点を発見する。 向いている場面：サービスデザイン、対人接点（受付・コールセンター・カウンセリング）を含む体験設計。 基本手順： - ユーザー役・サービス提供者役・観察者役を割り当て - シナリオを口頭で確認（台本不要） - 実際に演じ、観察者がメモをとる - 演技後に全員で「引っかかった瞬間」を振り返る 注意点：完璧に演じる必要はありません。演じながら止まって「ここはどうするんだっけ」と相談する瞬間が、最も重要な発見になることがあります。 --- - コンセプトスケッチ（絵コンテ形式） 概要：サービス・製品の体験を漫画的なコマ割りで描く。 向いている場面：ユーザージャーニー全体の検証、時系列のある体験設計（到着→利用→離脱等）。 基本手順： - 体験の主要タッチポイントを洗い出す（5〜8ポイント） - 各タッチポイントを1コマの絵と短い説明で描く - ユーザーに見せながらフィードバックを収集 - 「ここで何を感じますか」「次にどう動きますか」を問う 注意点：絵が下手でも構いません。スティックマン（棒人間）で十分です。コマ割りの「流れ」こそが検証の対象です。 --- - クリック可能モック（ハイパーリンクモック） 概要：スライドツール（PowerPoint・Keynote・Google Slides）やFigmaの画面遷移機能を使い、クリックに反応する画面を作る。 向いている場面：UIの操作性確認、特定の画面フローのユーザビリティテスト。 基本手順： - 主要画面をスライドとして作成（デザインは粗くてよい） - ボタン・リンクに「次の画面」への遷移を設定 - ユーザーに特定タスク（例：「商品を購入する」）を与え、操作させながら観察 - 行き詰まった箇所・予想外の操作をメモする 注意点：非対応のボタンは「準備中」のプレースホルダーで示し、ユーザーが触れたら口頭で「そこをクリックしたんですね、なぜそこだと思いましたか？」と問います。 --- - Wizard of Oz プロトタイプ 概要：AIや複雑なバックエンドの動作を、人間が裏側で操作することで「動いているように見せる」手法。 向いている場面：AIチャットボット・音声認識システム・パーソナライゼーション機能など、実装前に体験を検証したい場合。 基本手順： - フロント（ユーザーが見る画面）と裏側（操作者が操作するインターフェース）を用意 - 「Wizard役」がユーザーの入力を見て、手動でレスポンスを返す - ユーザーはシステムと対話していると信じたまま操作する - セッション後に種明かしをしてフィードバックを得る（倫理的な実施として重要） 注意点：「どの機能が本当に必要か」を開発前に検証するために有効ですが、ユーザーへの事後開示は必ず行います。 --- - サービスサファリ（体験偵察） 概要：自分たちのサービスや競合・隣接サービスを実際に体験し、ユーザー視点でインサイトを得る。 向いている場面：既存サービスの課題発見、競合分析、アナログ体験のデジタル化前の基礎調査。 基本手順： - 体験するサービス・店舗・施設を選定 - チームで実際に訪問・利用（バラバラに行き、後で比較する） - 体験中に写真・メモ・音声録音でデータ収集 - 「驚いた瞬間」「不満を感じた瞬間」「期待を超えた瞬間」を分類して共有 注意点：自社サービスのサファリは「慣れ」でインサイトが薄れます。初めて使うユーザーを連れて行くか、全く異なる業界の類似サービスを組み合わせて体験するとよいでしょう。 --- 手法選択マトリクス | 手法 | 忠実度 | 時間コスト | 人数 | 主な用途 | |------|--------|-----------|------|---------| | ペーパープロトタイプ | 低 | 30分〜 | 2〜4名 | UI概念の妥当性 | | ロールプレイ | 低 | 1〜2時間 | 3〜8名 | サービス体験設計 | | コンセプトスケッチ | 低 | 1時間〜 | 2〜4名 | ジャーニー全体 | | クリック可能モック | 中 | 2〜4時間 | 2〜4名 | UI操作性 | | Wizard of Oz | 中〜高 | 半日〜 | 3〜6名 | AI/自動化機能の事前検証 | | サービスサファリ | 参照 | 2〜3時間 | 2〜6名 | インサイト収集 | --- プロトタイプを作る前に問う3つの問い IDEOのデザイナーが実践する習慣として、プロトタイプを作る前に以下を明確にすることが推奨されています。 - 「何を検証したいのか」：機能の有無？使いやすさ？コンセプトの理解？問いによって手法が変わります。 - 「誰に見せるのか」：ユーザー？ステークホルダー？チーム内？対象によって忠実度が変わります。 - 「何が明らかになったら次のステップに進むのか」：検証の「合格基準」を先に決めることで、プロトタイプの目的がぶれません。 この3問に答えられないまま作り始めると、「見た目は良いが何も学べないプロトタイプ」が完成します。 --- 参考資料 - Stanford d.school. Prototype: Getting Tangible. (d.school method cards, standord.edu/dschool) - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins. - IDEO.org. The Field Guide to Human-Centered Design. (2015, ideo.org/post/field-guide-to-human-centered-design) --- ### リモート環境でのDesirability Testing — オンライン検証の設計と実践 URL: https://designthinking.studio/methods/desirability-testing-remote-facilitation/ > リモートでDesirability Testingを実施する際の設計手順、非同期・同期ツールの使い分け、リモートリクルート戦略、オンライン感情評価の注意点と落とし穴を実践的に解説する。 対面でのDesirability Testingは、参加者がカードを物理的に手に取り、迷いながら並べる様子そのものが情報になる。リモート環境では、その「触感」が失われる。しかし、それを補う設計を施せば、地理的制約なく参加者を集められる、非同期で複数人のデータを短期間に収集できるなど、対面では実現しにくい利点が生まれる。 オンラインでDesirability Testingを設計する上で先に決めるべきは、同期か非同期かだ。これはツールの選択より先に来る判断で、プロジェクトの目的・参加者の特性・確保できるリソースによって答えが変わる。 --- 同期 vs 非同期——選択の判断軸 同期（ビデオ会議）が向いているのは、ファシリテーターによる掘り下げが必要なとき、参加者が慣れないツールに誘導が必要なとき、複雑なプロトタイプを案内しながら体験させるときだ。対面に最も近い形でデブリーフが行えるため、「なぜそのカードを選んだか」の文脈を深く引き出せる。 非同期が向いているのは、参加者の地域や時間帯がバラバラなとき、5名以上のデータを短い期間で収集したいとき、参加者が自分のペースで答えた方が率直な回答が得られると判断したときだ。デブリーフは行えないか、行えても限定的になる。その分、質問設計が精度を左右する。 ハイブリッドも有効な選択肢だ。非同期でカード選択を先に完了させ、選んだカードとその理由を事前入力させた上で、短い同期セッション（20〜30分）でフォローアップの対話を行うパターンは、時間効率と質の両立がしやすい。 --- リモートリクルートの設計 対面と比べてリモートリクルートは間口が広い反面、ノーショー率（直前キャンセル・無応答）が高くなりやすい傾向がある。以下の点を設計に組み込むことで、有効回答数を安定させられる。 スクリーニング条件を絞りすぎない。 リモートDesirability Testingは、対象プロダクトを「日常的に使う人」でなくとも成立する。感情的な第一印象を測りたい段階では、むしろ事前知識が少ない参加者の方が純粋な印象を返してくれることがある。スクリーニングの基準は「評価できる文脈を持つ人か」に絞り込む。 リマインダーを2〜3回送る。 非同期の場合、依頼から回答まで数日空く。最初の依頼、翌日のリマインダー、締め切り前日の最終リマインダーで回収率が大きく変わる。リマインダーは「再度のお願い」ではなく「作業を進めるための補足情報」として送る方が返答率が上がる。 インセンティブの設計を明確に。 何をお礼として提供するかを最初のリクルートメッセージに明記する。曖昧なまま始めると、参加者側に「やって損をした」感が残り、デブリーフの質も下がる。 --- オンラインカード選択ツールの設計 物理カードの代替として、オンラインホワイトボードツール（付箋やフレーム機能を持つもの）を活用する設計が主流になっている。118枚全てを展開するとスクロール量が増えて認知負荷が高くなるため、30〜50語に絞ったセレクションを用意する方法が現場では多く採用されている。 セレクションを作る際の原則は、ポジティブとネガティブを同程度の比率で含めることと、対象プロダクトの文脈に無関係な形容詞を事前に除外することだ。B2Bのデータ管理ツールに「かわいい」「遊び心がある」が含まれていても参加者が迷うだけになる。 操作説明は短く、動画で済ます。 非同期では参加者にツールを自力で操作してもらう必要がある。テキストで3ステップ以上を説明するより、30秒の画面収録動画を1本用意した方が脱落率が下がる。 自由記述欄を必ず設ける。カード選択は入口でしかないという対面での原則は、リモートでも変わらない。選んだカードそれぞれに「なぜこれを選んだか（1〜2文）」を書けるテキスト欄を用意する。これが非同期でのデブリーフ代替になる。記述を強制にするか任意にするかは迷うが、「強制・短文（任意の長文より）」の方が有効回答率は高い。 --- 同期ファシリテーションの注意点 ビデオ会議上でDesirability Testingを実施する場合、対面と異なる準備が必要になる。特に「参加者の物理的な手の動き」が見えないことを前提に、各ステップの設計を組み直す必要がある。 プロトタイプの共有方法を事前に確認する。 参加者に自分の画面でプロトタイプを操作してもらうのか、ファシリテーターの画面共有で見てもらうのかを決める。前者は参加者の操作感を直接観察できるが、接続環境の差が体験のばらつきを生む。後者は環境差をなくせるが、参加者の能動的な探索が制限される。どちらを選ぶかは、プロトタイプが「見て判断するもの」か「使って判断するもの」かによる。 カメラオフ参加者への対応を事前設計する。 表情が見えない状態でデブリーフを進めると、ファシリテーターが沈黙を読み間違えやすい。参加者が話し終えたかどうかの確認を、「何かありますか？」ではなく「今のカードについては、以上でしょうか？」と具体的に聞く形にすると進行がスムーズになる。 録画の同意を必ず取る。 セッション冒頭で録画の目的（チーム内での分析のみ、外部共有しない等）を伝え、書面または画面上での同意確認を完了させてから録画を開始する。対面でも同様だが、リモートでは参加者側が「記録されている意識」が高い分、この手続きの丁寧さが参加者の率直さに影響する。 --- 非同期データの分析手順 非同期で収集した場合、デブリーフのリアルタイム対話がないため、自由記述の読み込みが分析の核になる。カード選択の数値集計はあくまで入口で、記述が持つ文脈を読むことで初めて改善の方向が見えてくる。 カード選択の集計は全体傾向の把握に留め、「選ばれた理由」の記述を個別に読むことに時間をかける。5名から同じカード「先進的」が選ばれていたとして、理由が「操作フローが直感的だった」「UIが見慣れないデザインだった（良い意味で）」「他社サービスと違う感じがした」と3方向に散らばることがある。この散らばりを均して「先進的と評価された」と結論づけると、改善の方向性を誤る。 ネガティブカードの自由記述は優先的に読む。対面では「退屈な」を選んだ参加者にすぐフォローの質問を投げられる。非同期では手が届かないため、ネガティブカードに対してより詳しく書くよう誘導する補足設問を事前に仕込んでおくことを検討する。 --- リモート特有の落とし穴 ツール操作の難しさが感情評価に混入する。 オンラインホワイトボードに慣れていない参加者は、カードを探して迷う時間が「プロダクトへの戸惑い」と混同されるリスクがある。ツールの操作を「評価に入る前の準備として完了させる」時間を確保する設計が有効だ。練習用の付箋を1枚操作させてから本題に入る、というウォームアップが機能する。 同期セッションでの沈黙処理を誤る。 オンラインでの沈黙は対面より長く感じるため、ファシリテーターが性急に言葉を埋めてしまいやすい。思考している沈黙を遮ることは、対面より多くの有益な発言を失う。「少し考える時間を取っていただいて大丈夫です」と一言添えてから待つ習慣をつける。 非同期回答の「出来すぎた」回答を鵜呑みにする。 参加者がいくつかの選択肢を調べた上で選んだ可能性、あるいは「良い参加者」を演じた可能性が対面より高い。特に記述が長くて整合性が取れすぎている場合は、後続の同期フォローアップで確認するか、そのデータの扱いを慎重にする。 接続トラブルへの過剰対応でセッションが乱れる。 音声が途切れる、画面共有が落ちるといった技術的なトラブルは起こる前提で進める。ファシリテーター自身が冷静に「少々お待ちください、接続確認します」と続け、セッションを完全に止めないことが重要だ。参加者の集中とセッションの文脈は、一度切れると再構築に時間がかかる。 --- 参考 - Joey Benedek & Trish Miner, "Measuring Desirability: New Methods for Evaluating Desirability in a Usability Lab Setting", Proceedings of the Usability Professionals Association 2002 Annual Conference, 2002 - Nielsen Norman Group, "Remote Moderated Usability Tests: How to Do Them", nngroup.com - Steve Portigal, Interviewing Users: How to Uncover Compelling Insights, Rosenfeld Media, 2013 --- ### ローズ・ソーン・バッド（Rose, Thorn, Bud） URL: https://designthinking.studio/methods/rose-thorn-bud/ > ワークショップや設計プロセスの振り返りを構造化する3軸フレームワーク。「よかったこと（Rose）」「困難だったこと（Thorn）」「可能性の芽（Bud）」を分類することで、チームが停滞せず次のアクションに向かえる振り返り技法。所要30〜60分、4〜20名。 ワークショップの終盤、「振り返りをしましょう」と促しても、「よかったです」「勉強になりました」。そんな感想の羅列で終わる。珍しくありません。原因はだいたい一つです。振り返りに構造が与えられていないのです。 ローズ・ソーン・バッド（Rose, Thorn, Bud）は、体験・プロセス・プロジェクトの振り返りを3つの軸で構造化する手法です。「花」のメタファーを使い、成功（Rose：咲いた花）・課題（Thorn：棘）・可能性（Bud：まだ開いていない蕾）に分類します。3軸の設計により、振り返りがネガティブ一辺倒にもポジティブ一辺倒にもならず、次のアクションへの橋渡しができます。 3軸の定義 Rose（ローズ）— うまくいったこと セッション・プロジェクト・スプリントの中で機能したこと、成功した瞬間、良い影響を生んだ判断や行動を挙げます。表面的な「楽しかった」ではなく、「なぜうまくいったのか」の観察を含めると振り返りの質が上がります。 よくある例: 「午前中のユーザーインタビューは、事前に共通の観察軸を決めていたため、メモが揃いやすかった」。具体的な行動と理由がセットになっているのがポイントです。 Thorn（ソーン）— 困難だったこと・機能しなかったこと うまくいかなかった点、詰まった箇所、予期しなかった障害を挙げます。批判や責任追及ではありません。「何が起きたか」という観察として書く——ここが分かれ目です。 Thornを安全に出せる場を作れるかどうかは、ファシリテーターにかかっています。「この場での発言は改善のためのデータ」。この合意を先に作っておくと、本音が出てきます。 Bud（バッド）— 可能性の芽・次に試したいこと 今回は試せなかったが可能性を感じたアイデア、次のセッションで改善できそうな点、種として見えてきた新しい方向性を挙げます。 Thornが「終わった問題」の記録だとすれば、Budは「まだ開いていない可能性」の記録です。このBudが、次のイテレーションを推進する燃料になります。 ステップ Step 1：場のセッティング（5分） 参加者に3軸を説明し、それぞれの付箋の色を割り当てます（例: Rose=赤系、Thorn=緑系、Bud=黄）。「正解はない、観察を書く」という前提を共有します。 個人で書く時間を取ることが重要です。全体発言だと声が大きい人の意見に引っ張られるため、最初は必ず個人の思考時間を設けます。 Step 2：個人記入（5〜10分） 各自が静かに付箋に書きます。1枚の付箋に1つの観察というルールを守ると、後のグルーピングがしやすくなります。量を奨励し、「細かいことでも書いてよい」と伝えます。 Step 3：ボードへの貼り出しと共有（15〜20分） ひとりずつRose → Thorn → Budの順に付箋を貼りながら一言コメントをします。「これはどういう意味ですか？」という質問を歓迎し、観察を深堀りします。批評や反論はここでは行いません——まず全員の観察を出し切ることが優先です。 Step 4：クラスタリングと優先度付け（5〜10分） Thorn・Budが多く出た場合、似た内容をグルーピングします。ドット投票（ドット・ボーティング）でチームとして優先する項目を選ぶと、次のアクション設定がしやすくなります。 Step 5：アクション設定（5〜10分） 振り返りが「観察の共有」で終わるか、「次の行動に接続するか」。その分岐点です。Thornから導く改善アクション、Budから導く実験を1〜3件決め、担当者と期限まで割り当てます。ここを飛ばすと、振り返りは「感想会」に戻ります。 使い所 ワークショップ・セッションの締め 半日から1日のデザイン思考ワークショップの最後30分に組み込むと、参加者の学びが言語化され、次回の設計改善につながります。ファシリテーターにとっては「このセッションの何が機能したか」を知る調査にもなります。 デザインスプリントの振り返り デザインスプリントのDay 5（テスト日）の最後、またはスプリント全体の振り返りに使えます。「テスト結果のインサイト」とは別に、「スプリントというプロセス自体の振り返り」として機能します。 プロトタイプテスト後 ユーザビリティテストやプロトタイプテストの直後にチームで行うと、次のイテレーションで改善すべき点（Thorn）と試すべきアイデア（Bud）が明確になります。 プロジェクトのマイルストーン振り返り 月次・四半期のプロジェクト振り返りに使うと、アジャイルなチームのレトロスペクティブとして機能します。感情ラインとプロセス改善を同時に扱えるため、チームのコンディション確認と次フェーズの設計が1セッションで完結します。 ファシリテーションのコツ Thornを先に出しきる 実際の進行ではRose → Thorn → Budの順序を「守りすぎる必要はない」ケースもあります。特に困難なプロジェクトの後では、Thornを先に安全に出し切ってから、RoseとBudに移る方が参加者の心理的安全が確保されます。ネガティブな感情を「あとで言える」と思うと人は話しにくくなります。 Budをリフレーミングのツールとして使う ThornとBudは一対一で対応させることができます。「次回はこのThornをどうBudにできるか？」という問いを立てることで、課題が次のイテレーションのアイデアに変換されます。このリフレーミングが「振り返りが次の前進につながる」構造を作ります。 時間が短い場合は付箋なしで口頭で進める 会議の最後の10分でもRose・Thorn・Budを3分ずつ口頭で共有するだけで機能します。付箋を貼る物理的な操作は「構造を明示し、発言を等価に扱う」という目的のためにあります。時間が限られている場合は口頭でも十分です。 よくある失敗と対策 BudがThornの言い換えになる 「進捗報告が遅れた（Thorn）→ 進捗報告をちゃんとやる（Bud）」という組み合わせは、BudがThornの単純な否定にすぎません。Budは「まだ見えていない可能性」であるべきです。「もし非同期で進捗を共有するツールを実験するとしたら（Bud）」のように、新しい試みの形にするよう促します。 Roseが出ない 困難なプロジェクトの後やチームのコンディションが低い時、参加者がRoseを書けないことがあります。この場合、ファシリテーターが「小さな成功」を先に例示することが有効です。「今日Thornが出たということ自体が成功だ」という枠組みもRoseになりえます。 振り返りが主観的な感想に終わる 「楽しかった」「疲れた」という感情的な記述だけでは、次の改善につながりません。「なぜそう感じたか」を一言添えるよう促すだけで、観察の質が上がります。ファシリテーターが「それはなぜですか？」と問い続けることが、感想を観察に変える最もシンプルな介入です。 他手法との組み合わせ Rose・Thorn・Budで上がったThornを深掘りするときは5 Whys（5回のなぜ）が有効です。根本原因まで掘ると、表面的な「もっとコミュニケーションをとろう」ではなく「ミーティング設計の前提が違った」という構造的な改善につながります。 Budをアイデアに展開するときはクレイジーエイツやHMW（How Might We）と組み合わせると、種を具体的な試作へと育てやすくなります。 --- 参考文献 - IdeaScale, "Rose, Bud, and Thorn: Usage and Benefits In Design Thinking," https://ideascale.com/blog/rose-bud-and-thorn-design-thinking/ - Atomic Spin, "Rose, Bud, Thorn (Design Thinking Activity #9)," https://spin.atomicobject.com/design-thinking-rose-bud-thorn/ - TeamRetro, "Rose Bud Thorn Retrospective Template," https://www.teamretro.com/retrospective-templates/rose-bud-thorn-retrospective/ --- ### ロータスブロッサム法（蓮花法）— 64案を構造的に展開する発散技法 URL: https://designthinking.studio/methods/lotus-blossom-technique/ > 中心テーマから8方向に派生するロータスブロッサム法の手順と応用。松村保男が考案した日本発のアイデア発展技法で、ブレインストーミングで止まりがちな発想を構造的に深める。ファシリテーション上の注意点とMiro活用法を含む。 ブレインストーミングは「たくさんアイデアを出す」ことを目的とする一方、深さの問題を持ちます。出たアイデアが表面的なバリエーションにとどまり、根底にある発想を展開し切れないまま終わるケースです。 ロータスブロッサム法は、この「広がったが深まらない」問題を構造的に解決するための発散技法です。中心テーマから段階的に連想を展開していくことで、一見無関係に見えるアイデアの連鎖から、新しい組み合わせや方向性が生まれます。 考案の背景 ロータスブロッサム法（英: Lotus Blossom Technique / 日本語名: 蓮花法）は、日本のクローバー経営研究所代表・松村保男（Yasuo Matsumura）が考案した発想技法です。「蓮の花」の形状——中心の蓮に複数の花弁が連なる——をモデルとした命名で、中心から外側へと連想が広がっていく構造を視覚的に表現しています。 Michael Michalko（著書 Thinkertoys, 1991年）などによって国際的に紹介され、クリエイティブ産業やデザイン思考のコミュニティで活用されています。 基本構造：3×3グリッドの入れ子構造 ロータスブロッサムの基本単位は 3×3のグリッド（9マス） です。 中央グリッドの構成： 中央の ★ に「中心テーマ」を記入し、周囲の8マス（A〜H）に派生アイデアや関連テーマを記入します。 展開グリッドの構成： 次に、A〜Hのそれぞれを新しい3×3グリッドの中心に置き、同様に8方向に展開します。 完全に展開すると、中央9マス＋展開グリッド8枚（各8マス）= 合計9＋64 = 73のセル が完成します。実際に使う場面では、すべてを埋めることを目的にせず、発展の可能性がある方向に絞って展開します。 手順 Step 1：中心テーマの設定（5分） 中央グリッドの中心マスに、探索するテーマ・課題・コンセプトを記入します。 テーマの粒度が結果に大きく影響します。広すぎるテーマ（「イノベーション」など）では8方向への展開が抽象的になります。具体的すぎるテーマ（「ボタンの色を変える」など）では展開の多様性が出ません。 有効なテーマの例： - 「オフィスワーカーの午後の集中力低下」（ユーザー課題） - 「チェックアウトの待ち時間体験」（サービスシナリオ） - 「廃棄物を出さない製品包装」（デザイン制約） Step 2：8方向への第一次展開（15〜20分） 中心テーマに対して、連想・要因・解決方向・ユーザー視点・関連要素など、多様な角度から8つの派生を記入します。 この段階での原則： - 良し悪しの判断は保留する（評価は後で行う） - 8マスを必ず埋めることを目標にする（詰まったら「逆転」「極端化」「比喩」で乗り越える） - 類似したアイデアを入れる場合も、言葉を変えて記入する（後で差異が価値を持つことがある） 第一次展開で書いたA〜Hが、次のステップで各グリッドの中心になります。 Step 3：第二次展開（30〜40分） A〜Hのそれぞれを中心に置いた新しいグリッドを展開します。チームで実施する場合は、一人または二人が一つのグリッドを担当する分業が有効です。 この段階で「A展開チーム」と「E展開チーム」が別々に作業していると、同じ中央テーマから出発しながら異なる文脈で展開が進みます。全体を集めたとき、この「異なる文脈からの展開」が偶発的なつながりを生む素材になります。 Step 4：収束と価値探索（10〜15分） 全展開グリッドを並べ、以下の問いで有望な方向を選択します。 - 意外なつながり：中心グリッドのA（例：「ストレス」）の展開と、C（例：「習慣」）の展開の間に接点はあるか - 複数グリッドに登場したキーワード：異なる方向の展開で同じ言葉や概念が繰り返し現れる場合、それは根幹的な要素を示している可能性がある - 意図しなかった組み合わせ：B展開の3番とF展開の6番を組み合わせたら、新しいコンセプトになるか ブレインストーミングとの違い | 観点 | ブレインストーミング | ロータスブロッサム | |---|---|---| | 構造 | 自由連想・非構造化 | 9マス×入れ子の構造化 | | 深度 | 広く出しやすいが深まりにくい | 各テーマを強制的に8方向展開 | | 収束 | 付箋の分類・投票 | グリッドの視覚的パターン探索 | | 人数 | 少人数〜大人数 | 1〜8名で効果的 | | 適した課題 | 初期の可能性探索 | テーマが絞られた後の深堀り | ブレインストーミングが「何でもあり」の発散なら、ロータスブロッサムは「構造の中での発散」です。両手法を組み合わせる場合、ブレインストーミングで広げた後にロータスブロッサムで1〜3のテーマを深堀りするというシーケンスが有効です。 ファシリテーションのポイント 「埋まらない」マスへの対応： 8方向を展開する中で詰まった時、以下の「強制連想のトリガー」が機能します。 - 逆転：そのテーマの反対は何か - 極端化：そのテーマを10倍にしたら / ゼロにしたら - 類比：動物に例えたら / 自然現象に例えたら - 別文脈移植：このテーマが病院の文脈にあったら / 子どものために設計するなら 評価の混入を防ぐ： 展開フェーズ中に「これは現実的じゃない」「予算がない」という声が出やすいです。評価は Step 4 の収束フェーズまで持ち越す——このルールをセッション開始前に全員で確認しておく。 大きな紙 / 広いデジタルキャンバスの確保： ロータスブロッサムは展開すると9グリッド×9マスの大きなマップになります。物理ワークショップではB0〜B1サイズの紙を壁に貼る形式が作業しやすいです。デジタルでは Miro の「Grid」フレームを活用し、各グリッドを独立したエリアとして設計します。 Miroでの実施設計 Miro上でロータスブロッサムを実施する場合の推奨構成： - 中央グリッド：3×3のスティッキーノートを手動で配置、または Miro テンプレートを利用 - 展開グリッド：中央グリッドの外側8方向に、同サイズのグリッドを配置 - カラーコーディング：中央グリッドと展開グリッドを異なる色で区別することで、「どのレイヤーにいるか」が視覚的に把握しやすくなる - タイマー共有：Miro内蔵タイマーまたは別ウィンドウのカウントダウンを全員が確認できる形で設置 --- 参考文献 - Michael Michalko, Thinkertoys: A Handbook of Creative-Thinking Techniques (2nd ed.), Ten Speed Press, 2006（初版1991年） - Dilip Mukerjea, Surfing the Intellect: Building Intelligences for Performance and Learning, Brainware Press, 2004 - 松村保男（Yasuo Matsumura）, クローバー経営研究所, 蓮花法（Lotus Blossom Technique）考案者 --- ### ワークショップ実況：カスタマージャーニー×エンパシーマップで、ユーザーの心を映す URL: https://designthinking.studio/methods/customer-journey-empathy-workshop/ > デザイン思考のempathize～define フェーズを同時実施するワークショップ。3時間で30名参加者がカスタマージャーニーを描き、隠れたニーズを可視化するプロセス実況。 ユーザーリサーチを集約する一番の課題は、何か。 バラバラに収集した声・観察・データを、どうチームで共通言語に変換するか。その瞬間が、デザイン思考のempathizeから defineへの扉です。 私は月1回のペースで企業ワークショップを実施していますが、ここ数ヶ月で「カスタマージャーニー」と「エンパシーマップ」を同時に描くハイブリッド手法が、参加者の「ユーザー理解の質」を一段階上げることに気づきました。本記事は、実際に先月某メーカーで実施した3時間ワークショップの実況を通じて、このプロセスの泥臭さと、そこから生まれた洞察をお伝えします。 なぜジャーニーとエンパシーを同時に？ 従来のワークショップでは、通常こう進みます。 - カスタマージャーニーを描く（時系列で、各タッチポイントのアクション・感情を記録） - その後、エンパシーマップを作る（ユーザーが「考えていること」「言っていること」「やっていること」「感じていること」の4象限） しかし実務では、この2つを分けて実施するとロスが多いことに気づきました。 理由は単純です。ジャーニー描写中に「このタッチポイントでユーザーは何を心の中で思ってたのか？」という問い立てが弱くなります。タイムラインに沿って「起きたこと」を埋めるだけになりやすく、心理層（感情・思考・葛藤）が浅いままになる。 対して、ジャーニーとエンパシーを並行して描くと、各タッチポイントで「ユーザーは外では何をしていたが、内では何を考えていたのか」という見えない層までストーリーが立体的になります。 ワークショップの全体設計 今回のワークショップは、メーカー営業部門の若手～中堅20名 + ファシリテーター である私 + デザイン思考経験者2名のアシスタント。所要時間は3時間。ターゲットは「法人向けセールスの営業プロセスにおける顧客心理」でした。 進め方の枠組み： 実況：「起きたこと」から「感じたこと」へ 09:15-10:00、壁に大判用紙を貼り出す瞬間 私は、A1用紙2枚を横に繋いだカスタマージャーニーのテンプレを用意していました。横軸は「営業初接触」→「提案打ち合わせ」→「見積提示」→「契約交渉」→「導入」→「運用開始」の6フェーズ。縦軸は「ユーザーのアクション」欄だけ。 20名を4グループに分け、各グループに1ジャーニーを割当てます。指示は簡潔に。 「このフェーズでお客さんは実際に何をしてましたか。メール返すまでに何日待った？ 何回会議した？を、具体的に埋めてください。感情は後で。」 ここが重要です。最初のパスでは『見える行動』だけに集中させる。感情は後。 参加者が手を動かしながら、ポストイットにアクション項目を書き始めます。 「お客さんから『提案書を見たい』というメールが来た」 「営業（自分たち）が社内稟議のために、部長への説明資料を作った」 「1週間音沙汰なし。営業側が『どうなった？』と再度連絡」 こういった「地味だけど実際に起きたこと」が、ジャーニーに並ぶと、チーム内で初めて「あ、ここ、こんなに時間かかってたんだ」という気づきが生まれます。 10:00-10:45、エンパシーマップの4象限を同時記入 次に、同じジャーニーの横に、エンパシーマップ用の大判用紙を貼ります。 ここが面白い部分です。ジャーニーの各フェーズごとに、エンパシーマップの4象限を細かく分割したものを用意したのです。 ジャーニーに「営業が見積を提示した」と書いてあるなら、その隣の同じタイムポイントのエンパシーマップには： THINK: 「この見積、ウチの予算で通るかな...」 SAY: 「ありがとうございます。一度内部で検討させていただきます」 DO: 社内の稟議ルートに見積書を回している FEEL: 漠然とした不安（他社との比較も気になる） こう記入していくと、タッチポイントごとの「表と裏」がいっきに立体的になります。 ワークショップ中、あるグループから質問が出ました。 「営業の再度の『どうなった？』という連絡の時、顧客は実は『急かされてる感』を感じていたんですか？」 私は「そうかもしれない。じゃあここの FEEL に『プレッシャー感』を足してみようか」と提案しました。 すると、そのグループ全体が「あ、そっか。ウチらが『進捗確認の連絡』だと思ってた行動が、顧客には『急かし』に映ってたかも」という気づきに到達したのです。 これが、分けて実施していたら起こりにくい。同時に見ることで、初めてギャップが見える。 「欲しい」と「欲しくない」のギャップを可視化する 10:45-11:00、ギャップを見つける ここが define フェーズへの接続です。 ジャーニーとエンパシーマップが完成した4グループに、新しい指示を出します。 「いま、ジャーニー上で『ユーザーがしてほしかったこと』『ユーザーが避けたかったこと』を、黄色いポストイットで書いてください。」 出てくるのは、こういったギャップです。 - 欲しかった： 「提案書の前に、導入事例を見たかった」 - 避けたかった： 「複数の部署を巻き込むような意思決定プロセスの複雑さ」 - 欲しかった： 「営業と対話ではなく、オンラインで何度も確認できるナレッジベース」 これらが「隠れたニーズ」です。顧客インタビューでは直接聞かなかったかもしれない。でも、ジャーニーとエンパシーの組み合わせで、チーム全体が同時に気づくことができた。 参加者からの声 最後の発表セッションで、各グループが気づきを述べていきます。印象的だったのは、営業部門の中堅が言った一言。 「いつもは『顧客は何を買ってるか』という機能面ばかり考えてました。でも、この3時間で『顧客は意思決定のプロセスそのものにストレスを感じてる』ってことに初めて気づきました。商品じゃなくて、営業体験そのものを変えないとダメかもしれない。」 これが define フェーズの本質です。「何が問題か」を、表面の機能面ではなく、心理層で捉え直すこと。 ファシリテーションの勘所 私が毎月のワークショップで大切にしているポイントを、いくつか記しておきます。 - 最初のパスで「見える層」に集中させる 感情を早く入れると、参加者は「正解を探そう」という思考に入り、実際のユーザー行動の観察が浅くなります。「何が起きたか」を先に埋め、その後「なぜか」を重ねる方が、事実ベースの洞察が生まれやすい。 - エンパシーマップの4象限は「ジャーニーの時間軸と同期させる」 時間がズレると、参加者は「一般的なユーザー心理」を推測で埋めてしまいます。「このタッチポイント、このタイミング」に限定することで、具体性が保証される。 - ギャップを「黄色で可視化」する ジャーニーとエンパシーが完成した段階では、参加者は疲れ始めています。ここで new insight を引き出すには、色を変えて『見える』という物理的な刺激が有効です。 - グループ発表で「なぜそう思ったか」を聞く 「こういうギャップを見つけました」という結論より、「ジャーニーのこの部分と、エンパシーのこの部分を見ると、矛盾してますよね」という根拠を述べさせる。プロセスが共有されることで、チーム全体の納得度が変わる。 実践するなら カスタマージャーニー×エンパシーマップの同時実施は、3時間、4～5名のグループサイズ、事前にユーザー像が決まっていることが前提です。 もし「ユーザーペルソナすら定義されていない」ようなら、このワークショップの前に、別途 empathize フェーズ（インタビューやフィールドワーク）が必要。あくまで「リサーチ後の集約」として機能します。 また、参加者がワークショップ未経験なら、初回は「ジャーニー描写のみ」にしぼり、2回目以降にエンパシーマップを重ねる段階的進め方もあります。 大事なのは、『何が起きたか』から『何を感じたか』への連続性を、チーム全体で体験すること。 その体験が、デザイン思考の真価 — 「データと直感のあいだに橋を架ける」という、最も泥臭く、最も大切な営みなのです。 --- カテゴリ: tools（ツール・手法） 関連記事: - エンパシーマップ｜ユーザーの「見える層」と「見えない層」を描く - カスタマージャーニーマップ実践ガイド --- ### 共感マップ（Empathy Map） URL: https://designthinking.studio/methods/empathy-map/ > ユーザーの体験を「言っていること・考えていること・していること・感じていること」の4象限で整理するフレームワーク。 共感マップ（Empathy Map）は、ユーザーの体験を視覚的に整理するためのシンプルなフレームワークです。 概要 共感マップは、Dave Gray が開発したツールで、ユーザーの体験を4つの象限で整理します。ユーザーインタビューや観察の後に使用することで、チーム全体でユーザーへの理解を共有できます。 4つの象限 言っていること（Say） ユーザーがインタビューや観察中に実際に口にした言葉をそのまま記録します。「〜が面倒」「〜が分からない」など、ユーザー自身の表現を使うことが重要です。 考えていること（Think） ユーザーが口にはしないが、考えていると推測されることを記録します。「本当は〜したいのでは？」「〜を心配しているのでは？」といった推察です。 していること（Do） ユーザーの実際の行動を記録します。言葉と行動が矛盾している場合、行動の方がより真実に近いことが多いです。 感じていること（Feel） ユーザーの感情状態を記録します。不安、喜び、苛立ち、期待など、体験に伴う感情を特定します。 実施の手順 - 中心にユーザーのペルソナを配置する - 4象限を描く - チームメンバーがそれぞれの象限に付箋を貼る - 付箋をグルーピングし、パターンを見つける - 矛盾点や驚きのある発見に注目する ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、「Think」象限が空欄のまま進んでしまうパターンです。「Say」と「Do」はインタビューの記録から埋まりますが、「Think」は推察が必要なため、チームが「勝手に決めてよいのか」と迷って手が止まります。 実際にやってみると、「Think」の空欄を埋めようとする議論の中から、チームが暗黙に抱えていた仮定が次々と出てきます。「このユーザーは実は〜と思っているのではないか」という問いかけが、次のユーザーインタビューで確認すべき仮説の源泉になります。推察でよい——ただし、推察と事実を色で区別して記録する習慣をつけることが大切です。 ポイント - 推測と事実を区別する — 観察に基づく事実と、チームの推測を分けて記録する - 矛盾を大切にする — 言っていることとしていることが異なる場合、深い洞察のヒントになる - 一人のユーザーに集中する — 複数のユーザーを混ぜず、一人ずつマップを作成する 共感マップで整理した内容は問題定義フェーズでのPOVステートメント作成に直接つながります。 --- 参考文献 - Dave Gray, Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, O'Reilly, 2010 - Nielsen Norman Group, "Empathy Mapping: The First Step in Design Thinking", nngroup.com, 2017 --- ### 共創ワークショップ ファシリテーション実践 URL: https://designthinking.studio/methods/co-creation-workshop-facilitation/ > 異なる立場の参加者を巻き込み、本質的なアイデアを生み出す場づくりの技法。プロセス設計から場の空気感管理まで、ワークショップ現場で実際に起こる課題への対処法を解説します。 ワークショップの現場では何が起きているか 共創ワークショップを100回以上ファシリテーションしていると、必ず直面する現象がある。 それは、参加者が「何を言ってもいい」という心理的安全性を感じた瞬間、思考が劇的に変わるということだ。それまで自分の役割や立場に束縛されていた人が、突然、自分本来の視点を語り始める。営業が技術的な課題に気付く。企画が現場の制約の中でこそ活きるアイデアを提案する。 その瞬間、ワークショップは単なる「意見集約の場」ではなく、異なる立場の思考が衝突し、融合する化学反応の場へと変わる。 本記事は、その化学反応を意図的に引き起こすためのファシリテーション技法を、ワークショップ現場の泥臭さを隠さずに解説する。 --- - ワークショップ設計の三層構造 共創ワークショップをファシリテーションする際、階層的に考える必要がある。 第1層：プロセス設計（ミクロ） 個別のアクティビティ（ブレインストーミング、ユーザーペルソナづくり、プロトタイプテストなど）をどの順序で、どのような時間配分で配置するか。これはデザイン思考の5フェーズに沿って決まることが多い。 実務的には、3時間のワークショップであれば以下が定型パターンになる。 - 00:00-00:15 — アイスブレーク + 目的共有（empathize の入り口） - 00:15-01:00 — ユーザー調査・インサイト共有（empathize） - 01:00-01:15 — 問題定義ディスカッション（define） - 01:15-02:30 — ブレインストーミング（ideate） - 02:30-03:00 — アイデア選別・次のアクション決定（prototype） 第2層：グループダイナミクス（メゾ） 参加者の構成によって、グループの心理状態は大きく変わる。同じ部門だけで構成されたグループと、営業・企画・技術がミックスされたグループでは、議論の深さが全く異なる。 ポイントは以下の通り。 - 立場の異なる人を意図的に混在させる。同じ背景を持つ人ばかり集めると、暗黙の了解が働いて本音が出にくくなる。 - 発言の順序を工夫する。立場が高い人が最初に意見を言うと、その場に「正解」が決まり、他者は追従するだけになる。ファシリテーターが最初に問いを投げ、下位の立場から先に発言させるのが有効。 - 沈黙を恐れない。良い問いを投げた直後は、必ず沈黙が生まれる。その沈黙は参加者が考えている証拠。焦って他の質問を足さない。 第3層：場の空気感（マクロ） ワークショップ全体を通じて、「安心して実験できる雰囲気」「失敗を歓迎する文化」が醸成されているか。これは、ファシリテーターの振る舞いと言葉選びに表れる。 --- - 心理的安全性をつくる３つの技法 ワークショップ現場でよく起こるのは、参加者が「正解を求めている」という誤解だ。だからこそ、ファシリテーターが最初に「ここではすべての意見が価値がある」というメッセージを、言葉だけでなく行動で示す必要がある。 技法 1：「バカっぽいアイデア」を先に語る ワークショップ開始時のアイスブレークで、ファシリテーター自身が「この製品にはUFO機能があったらいいんですよ」のような明らかに実現不可能なアイデアを提案する。 すると、参加者の心理に起こるのは以下の変化だ。 - ファシリテーターが「正解」を求めていない、ということが肌感覚で伝わる - 「え、こんなアイデアもありなの?」という心の解放 - その直後から、参加者のアイデアの大胆さが増す 実際のワークショップでは、このバカアイデアの直後に「本当に面白いアイデアって、見た目はバカに見えるんですよ」と一言添える。この一言が、後続の発言の大胆さを決定付ける。 技法 2：参加者の発言を「拡張」する 参加者が発言するたびに、ファシリテーターは その発言の良さを引き出す質問を返す。 悪い例： 参加者A「このアイデアは難しいかもしれません」 → ファシリテーター「そうですね」で次へ 良い例： 参加者A「このアイデアは難しいかもしれません」 → ファシリテーター「なぜ難しいと思いました?」 → 参加者A「〇〇という制約があるからです」 → ファシリテーター「その制約の中でこそ、何か新しいアプローチがあるかもしれませんね」 この「拡張」を繰り返すことで、参加者は「自分の発言が聞かれている」という感覚を持つ。その感覚が心理的安全性を高める。 技法 3：「失敗データ」を共有する ワークショップの途中で、ファシリテーターが「実は前回、この手法でうまくいかなかった」という事例を共有する。 すると、参加者の中で「あ、失敗もあるんだ」「なら自分たちも試しに失敗してもいいのか」という心理が生まれる。これは、プロトタイピングやユーザーテストの段階で特に有効。参加者が「完璧なアイデア」を求めるのではなく、「試可能な仮説」を提案するマインドセットに切り替わる。 --- - 発散と収束のタイミング ワークショップ現場でよくある失敗パターンが、発散と収束を同時にやってしまうことだ。 発散フェーズのルール ブレインストーミング段階では、以下のルールを厳格に守る。 - 批判は禁止 — 「でも」「しかし」の否定形の発言をその場でストップする - 質よりも量 — 「100個のアイデアを30分で出す」というノルマを掲げる。質的検討は後で - 自由連想を奨励 — 前の人のアイデアから飛躍したアイデアが歓迎される場づくり 実務的には、この段階で「ファシリテーターが記録係になってはいけない」という経験則がある。ファシリテーターが発言を聞きながら模造紙に書き込むと、その行為自体が「書く価値のあるアイデアを選別している」というメッセージになり、発言者の心理を萎縮させる。代わりに、専任の記録係を置き、ファシリテーターは聞き役に徹する。 収束フェーズのルール 発散を十分に終えた後、ようやく「どのアイデアを次に進める?」という問いが活きる。 この段階でのポイント： - 「好き嫌い」で選ばない — 実現性や顧客価値への影響度で絞る - 全員のアイデアが価値づけられたことを確認 — 「このアイデアは今は選ばないが、将来の参考にする」というセーフティネットを張る - 優先順位の根拠を言語化 — 「なぜこの3つを選んだのか」を参加者全員が納得できるロジックで説明する --- - グループワークで実際に起こる課題と対処法 課題 1：沈黙が続く ワークショップで最も焦ることの一つが「沈黙」だ。ファシリテーターとして、その沈黙が「参加者が考えている沈黙」なのか「思考停止の沈黙」なのかを見分ける必要がある。 対処法： - 最初の30秒は何も言わない（参加者が考えるための時間） - 45秒経ってもまだ静かであれば、別の参加者に「何か思いますか?」と直接問う - それでも反応がなければ、テーマを言い換えて問い直す（「別の視点から見ると〜」） 重要なのは、沈黙そのものを否定的に捉えないこと。良いワークショップには、適切な沈黙が必ず存在する。 課題 2：一部の人が議論を独占する 特に発言が得意な人が議論をリードしてしまい、他の参加者が引っ込んでしまう現象。 対処法： - 「〇〇さん、どう思いますか?」と明示的に他者に指名する - グループを小分けにして、全員が発言する必然性を作る - 「今回は聞き手に回ってもらえますか」と発言者に直接お願いする 実務的には、グループサイズを8名以下にすることが最も効果的。8名を超えると、必ず沈黙する人が生まれる。 課題 3：異なる立場から批判が生じる 特に営業と技術、経営企画と現場という関係性では、アイデアに対する評価基準が異なるため、議論が対立になりやすい。 対処法： - 対立を「間違い vs 正解」ではなく、「異なる制約条件の中での判断」として位置付け直す - 「営業視点では確かにそう。技術視点ではどう?」と両立をまず認める - その上で「両方の制約を満たす方法は?」と問い直す これは、実はデザイン思考の本質そのものだ。相互に矛盾する要件を、創造的に統合するプロセス。その統合の過程で、ワークショップの価値が生まれる。 --- - プロトタイピングを組み込む時の流れ 共創ワークショップの最後に、アイデアを簡易的にプロトタイプ化する段階を入れると、参加者の理解度と関与度が大幅に上がる。 ステップ 1：「低忠実度」を徹底する アイデアを紙や粘土で表現する。CGや3DCGで「美しい」プロトタイプを作る必要は全くない。むしろ、「これは本当に実現できるのか?」という検証が目的なので、粗っぽいプロトタイプの方が良い。 実際のワークショップでは、「60分で模造紙と付箋だけで自社製品の新機能を形にしてください」という無茶な指示をすることもある。その無茶の中から、アイデアの本質が浮き彫りになる。 ステップ 2：他グループにテストしてもらう グループごとに別のアイデアをプロトタイプ化した場合、それぞれのグループが作ったプロトタイプを他のグループが「ユーザーになってテスト」する。 この段階で起こるのは、作り手では想像できなかった使い方や課題の発見だ。「こういう使い方もあるのか」という気付きが、次のイテレーションのきっかけになる。 ステップ 3：フィードバックの言語化 最後に、テストしたグループが「良かった点」「改善すべき点」「新たに生まれた質問」を言語化する。 ここで重要なのは、「〇〇は失敗だ」ではなく「〇〇という制約が見えた」と言い方を工夫することだ。その言い方一つで、参加者のマインドセットが「批判モード」から「問題解決モード」へ切り替わる。 --- - ファシリテーターとして覚悟すること ワークショップ現場でよく起こるのは、ファシリテーターの想定通りにプロセスが進まないということだ。 予定では 14:00 に収束するはずが、13:45 の段階で参加者が完全に発散モードに入っていることもある。その時、ファシリテーターの判断は以下の二択になる。 - 予定通り 14:00 に終わらせる - その流れを信頼して、予定を延長する 実務的には、その時の化学反応を信頼する方が、良い成果につながるという経験則がある。100回以上のワークショップを見ていると、「あ、いい流れになってる」という直感は、ほぼ外れない。 その直感を信頼するために必要なのは、ファシリテーターとしての準備と覚悟だ。あらかじめ参加者に「時間は柔軟に考えています」と宣言する。その上で、本当の意味の柔軟性を持つ。 --- - やってみよう：3時間の共創ワークショップ設計 以下のテンプレートで、自社の課題に対して共創ワークショップを設計してみよう。 参加者の選定 - 経営層 1-2 名 - 営業・マーケティング 2-3 名 - 企画・プロダクト 2-3 名 - 技術者 1-2 名 - （オプション）顧客代表者 1-2 名 タイムテーブル ファシリテーターの注意点 - 記録係と聞き役を分離する - 最初に「失敗したアイデアの話」を1つ共有する - 沈黙を恐れない - 異なる立場の意見が出たら「両立できる?」と問う - 予定より流れが良かったら、時間を延長する判断を持つ --- 最後に 共創ワークショップの本質は、参加者の多様な視点が「衝突」から「融合」へ向かう時間を作ることだ。 その時間を作るために必要なのは、完璧なテンプレートではなく、その場その場の参加者の心理状態を読み、柔軟に対応する力だ。 ファシリテーターとして最初の3回のワークショップは、きっと想定通りには進まない。むしろ、その「ズレ」の中にこそ、次のワークショップの改善ポイントが隠れている。 その経験を積み重ねることで、参加者の無意識的な抵抗を事前に感じ取り、質問一つで場の空気を変えることができるファシリテーターになっていく。 つまり、ワークショップのファシリテーションも、デザイン思考と同じプロセスなのだ。試行錯誤を重ね、ユーザー（参加者）の声に耳を傾け、次のイテレーションへ向かう。その繰り返しの中でのみ、「本当に価値のある場づくり」は生まれる。 --- ### 親和図法（KJ法） URL: https://designthinking.studio/methods/affinity-diagram/ > 大量の定性データを類似性に基づいてグルーピングし、パターンとインサイトを発見するための分析手法。文化人類学者・川喜田二郎が考案。 親和図法（Affinity Diagram）は、大量のデータを「似ているもの同士」で束ね、隠れたパターンを浮かび上がらせる分析手法です。日本の文化人類学者・川喜田二郎が1960年代に考案したことから、KJ法とも呼ばれます。 概要 ユーザーインタビューや観察調査で集めた定性データは、そのままでは量が多すぎて全体像が見えません。親和図法は、個々のデータを付箋に書き出し、直感的な類似性に基づいてグルーピングすることで、データの中に潜む構造を可視化します。 川喜田二郎はネパールでのフィールドワーク中に、西洋的な演繹的推論では民族誌データを十分に分析できないと感じ、この手法を開発しました。ボトムアップで意味を見出すというアプローチは、デザイン思考の問題定義フェーズと本質的に相性が良いです。 実施の手順 ステップ1：データを付箋に書き出す インタビューの発言、観察メモ、リサーチの気づきなどを、1枚の付箋に1つの事実・発言・気づきだけを書き出します。太いマーカーで、離れた場所からでも読める大きさで書くのが鉄則です。 1セッションあたり30〜80枚の付箋が目安です。少なすぎるとパターンが見えず、多すぎると作業が回らない。 チームメンバーが同じインタビューデータから付箋を書く場合は、重複を気にせずそれぞれが感じた要素を自由に書き出します。 ステップ2：黙ってグルーピングする ここが親和図法の核心です。会話をせずに、似ていると感じる付箋を近くに移動させます。 声を出さないのは、論理的な議論ではなく直感的な類似性でグルーピングするためです。 付箋を動かしながら、あるメンバーが作ったグループを別のメンバーが崩して再構成することも起こります。それでよいのです。 グルーピングに正解はなく、チーム全体で「しっくりくる」構造を探るプロセスそのものに価値があります。 5〜7個のグループに収束するのが理想的ですが、無理に数を合わせる必要はありません。どこにも属さない付箋は、「孤立データ」として残しておきます。 後から重要なインサイトの種になることがあるためです。 ステップ3：グループに見出しをつける 形成されたグループの内容を俯瞰し、そのグループが意味するところを一言で表す見出しを付けます。 ここで初めて会話を解禁します。 見出しは抽象的すぎないことが大切です。「ユーザーの不満」では何も伝わりません。「自分のペースでできないことへの苛立ち」のように、具体的な感情や状況を含む見出しにすると、後の分析で活きてきます。 ステップ4：グループ間の関係を描く 見出しが揃ったら、グループ間の因果関係、対立関係、依存関係を矢印や線で結びます。 「AがBの原因になっている」「CとDは対立する要素である」といった構造が見えてくると、問題の全体像が浮かび上がります。 ステップ5：インサイトを抽出する グルーピングと関係性の分析から、チームの前提を覆すような発見（インサイト）を特定します。 「予想通り」の結果はインサイトではありません。「意外だった」「矛盾している」「説明がつかない」ポイントにこそ、インサイトの種があります。 抽出したインサイトは、POVステートメントやHow Might Weの問いへと発展させます。 ワークショップで繰り返し見られるパターン 200回以上のワークショップで繰り返し見られるのは、サイレントグルーピングが「サイレント」でなくなるパターンです。黙って付箋を動かすはずが、誰かが「これはあっちじゃないか」と口を開いた瞬間に議論が始まり、結局声の大きい人の分類になってしまう。 実際にやってみると、サイレントグルーピングの5〜7分間は、その後の全議論の質を決めます。 何も言わずに手を動かしている時間、参加者の頭の中では「なぜ自分はこの2枚を近づけたのか」という問いが静かに回っています。この無言の思考が、後の「見出しをつける」セッションで突然言語化されて出てくるのです。ファシリテーターがサイレントの時間を守ることが、親和図法の最大の価値を引き出します。 よくある失敗と対処法 グルーピングが「カテゴリ分類」になってしまう 「機能面」「価格面」「デザイン面」のような既存のカテゴリに当てはめるのは、親和図法ではありません。 それはトップダウンの分類であり、ボトムアップの親和図法とは正反対のアプローチです。 対処法は、カテゴリ名を先に作らないことです。まず付箋同士の「似ている感じ」だけで物理的に近づけ、その後に見出しを考える順序を厳守します。 1人のメンバーがグルーピングを支配する 声の大きいメンバーが「これはこっちのグループだ」と仕切り始めると、他のメンバーは遠慮して手を出さなくなります。 サイレントグルーピングのルールを最初に明示し、それでも破られる場合はファシリテーターが介入します。 付箋が細かすぎる・粗すぎる 「ユーザーAが13時のインタビューで述べた3番目の発言」は細かすぎます。「ユーザーは不便を感じている」は粗すぎます。「操作手順が多くて途中で離脱してしまう」のように、行動と文脈が伝わる粒度が適切です。 ポイント - 論理より直感 --- グルーピングは頭ではなく手で考える作業。理屈で分類しない - サイレントが基本 --- 黙って付箋を動かす時間が、最も豊かな対話になる - 孤立データを捨てない --- どこにも属さない付箋が、最大のインサイトを含むことがある - 見出しは具体的に --- 抽象的なラベルは分析の解像度を下げる - 写真を撮る --- 完成した図は必ず記録する。後から振り返る最も重要な資料になる グルーピングで見えてきたインサイトはPOVステートメントやHow Might Weに発展させます。問題定義フェーズにおける中心的なツールです。 --- 参考文献 - Jiro Kawakita, The Original KJ Method, Kawakita Research Institute, 1991 - Donald Norman, The Design of Everyday Things (Revised Edition), Basic Books, 2013（付録：HCD手法） --- ### 問題フレーミング・ワークショップ：HMW（How Might We）から始まる問い直しの実践 URL: https://designthinking.studio/methods/problem-framing-workshop/ > 問題フレーミング・ワークショップはHMW（How Might We）を起点に「正しい問題を解いているか」を確認する90分の設計手法。広すぎず狭すぎないスコープ調整のWhy Ladder、IDEOが体系化したHMW三単語の意図、6〜12名向け進行構成を実践解説する。 デザイン思考の最大の失敗パターンのひとつは「間違った問題を解くこと」です。素晴らしいソリューションが生み出されても、そもそも解くべき問題がずれていれば、イノベーションには繋がりません。 HMW（How Might We：どうすれば私たちは〜できるだろうか）は、発見したインサイトを「挑戦すべき問い」に変換するフレームワークです。この問いを正確に設定することで、アイデア発散の方向性が定まり、意味のある解決策が生まれる確率が上がります。 HMWの起源 「How Might We」という表現は、IDEO創設者のデイヴィッド・ケリーが1970年代にProcter & Gambleで使っていた問いの形式に遡ります。後にIDEOとスタンフォードd.schoolで体系化され、現在はデザイン思考ワークショップの標準的な「問い生成ツール」として広く使われています。 三つの単語には、それぞれ意図があります。 How（どうすれば）：問題を「可能性の問い」として開く言葉。「これは難しい」「不可能だ」という思考パターンを「解決策がある」という前提に転換させます。 Might（〜かもしれない）：「こうすれば解決できる」という断定ではなく、「こうすれば解決できるかもしれない」という可能性を示します。この曖昧さが「まずは試してみよう」という心理的安全性を生みます。 We（私たちは）：個人の責任ではなく、チームの取り組みとして問題を設定します。「あなたが解決してください」ではなく「私たちで探索しましょう」というフレーミングです。 --- 「広すぎず・狭すぎず」の原則 HMWの品質は「スコープの適切さ」で決まります。広すぎても狭すぎても、後のアイデア発散が機能しなくなります。 狭すぎるHMW（NG例） 「どうすれば、Webサイトのログインページのパスワード入力欄を改善できるだろうか？」 これはすでに解決策（パスワード入力欄の改善）が前提に入っています。「パスワードを廃止する」「生体認証に移行する」という根本的な解決策への道が閉じてしまいます。 広すぎるHMW（NG例） 「どうすれば、世界のすべての人に安全なインターネットアクセスを提供できるだろうか？」 これは単一のプロジェクトやチームが扱えるスコープを超えており、アイデア発散の方向性を絞れません。何でも出てくるが、何も具体的なアクションには繋がらない問いです。 適切なHMW（OK例） 「どうすれば、技術に不慣れな高齢ユーザーが、初回ログインを一人で完了できるようにできるだろうか？」 この問いは「高齢ユーザー」「初回ログイン」「一人で」という制約が入っており、アイデアの方向性が定まります。しかし「パスワード方式の維持」という仮定は入っておらず、解決策の幅は十分に開かれています。 スコープを調整するテクニック 問いが広すぎると感じたら：制約や対象ユーザーを追加する（すべての人 → 初めて使う60代の人） 問いが狭すぎると感じたら：「なぜそれが必要か」を問い、一段上位の問いに置き換える（パスワード入力欄を改善する → ユーザーがスムーズにログインできるようにする → ユーザーがサービスにアクセスしやすくする） この「なぜの梯子（Why Ladder）」は、問題定義を適切なレベルに調整するツールとして機能します。 --- 90分ワークショップ設計 アジェンダ | 時間 | 内容 | 形式 | |------|------|------| | 0〜10分 | オープニング・共有インサイトの確認 | ファシリテーター主導 | | 10〜25分 | HMW個人作成（サイレント） | 個人ワーク | | 25〜40分 | HMWの共有とクラスタリング | グループワーク | | 40〜55分 | HMWの洗練（広さ・狭さの調整） | ペア or グループ | | 55〜70分 | ドット投票と優先HMWの選定 | 全員 | | 70〜85分 | 選定HMWの深掘り（前提・制約の明示化） | グループワーク | | 85〜90分 | クロージング・次ステップの確認 | ファシリテーター主導 | --- Phase 1：オープニング（0〜10分） 目的：インサイトを共有し、HMW作成の「材料」を全員が持つ状態にする。 共感フェーズで収集したインサイト（ユーザーインタビューの要約、観察で気づいた事実、ペルソナの「痛み」など）をチームで共有します。すべてのインサイトをこの場で共有する必要はありません。今回のワークショップで焦点を当てる「インサイトの束」を3〜5個に絞って提示するのが効果的です。 ファシリテーターの注意点：インサイトを「問題として定義する」ことはこの段階ではしません。「ユーザーはこのような状況にいる」という事実の共有にとどめます。 Phase 2：HMW個人作成（10〜25分） 目的：一人ひとりが、インサイトを「問い」に変換する。 実施方法：付箋（1枚1HMW）に「How Might We〜」で始まる問いを書きます。この段階では量を優先し、評価しない。5〜7分で5〜10枚を目安とします。 サイレントワーク（書くだけで発言しない）の理由は、他者のアイデアに引きずられることなく、各自が独立して問いを生成するためです。グループワークより多様な問いが生まれます。 Phase 3：共有とクラスタリング（25〜40分） 目的：全員のHMWを可視化し、テーマのかたまりを発見する。 付箋を壁またはホワイトボードに貼り出し、内容が似ているもの同士をグループにまとめます（アフィニティダイアグラムの要領で）。この作業自体が対話を生み、問いの背景にある意図の共有につながります。 クラスタリングは完璧である必要はありません。「概ねこのテーマ」という程度のグルーピングで十分です。 Phase 4：HMWの洗練（40〜55分） 目的：広すぎる・狭すぎる問いを「ちょうどいいスコープ」に調整する。 クラスターごとにチームが「この問いは広すぎないか/狭すぎないか」を議論します。必要に応じて、問いの書き換えを付箋に書き直します。 良い議論の例：「この問いは『コストを下げる』が前提になっているけど、コスト以外の手段は最初から排除していいの？」→「では『どうすればユーザーが感じる価値を下げずに提供できるか』に書き直そう」 Phase 5：ドット投票（55〜70分） 目的：「最も重要なHMW」を民主的に選定する。 各参加者に3〜5枚のドットシール（または丸を書く）を渡し、最も重要だと思うHMWに投票します。自分のHMWに投票しても構いません。複数ドットを1枚のHMWに集中させることも許可します。 投票後、上位3〜5件のHMWを「優先的に探索する問い」として選定します。 Phase 6：優先HMWの深掘り（70〜85分） 目的：選ばれた問いの「前提と制約」を明示化する。 選定された上位HMWそれぞれについて、次の問いに答えます。 - この問いが前提としていることは何か？ - この問いが意図的に排除していることは何か？ - この問いを解いたとき、誰が最も恩恵を受けるか？ - この問いには「解けない範囲」があるか？ この作業によって、後のアイデエーションの設計図が精度高く定義されます。 Phase 7：クロージング（85〜90分） 選定されたHMWをチームで確認し、次のステップ（アイデア発散ワークショップの日程、担当者）を合意します。 --- よくある失敗と対処法 失敗1：インサイトなしでHMWを作る。 HMWはインサイトを問いに変換するものです。共感フェーズの実施なしにHMWを作ると、「担当者が頭の中で想定している問題」をHMWの形に書き換えるだけになります。 失敗2：HMWが「解決策」になっている。 「どうすれば、スマートフォンアプリを作れるか」はHMWではなく、すでにソリューションです。HMWは「解くべき問題」であり、「どんな解決策を選ぶか」ではありません。 失敗3：ドット投票で「多数決で正解を決めた」と解釈する。 投票はどの問いを「先に探索するか」の優先順位を決めるものです。選ばれなかったHMWが「間違っている」わけではありません。後で戻る可能性を残しておくことが重要です。 --- 参考文献 - IDEO, Design Thinking for Educators, IDEO, 2011（改訂版2012） - d.school, "How Might We Notes", Hasso Plattner Institute of Design at Stanford, designthinkingplaybook.com - Warren Berger, A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas, Bloomsbury USA, 2014 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth, Columbia Business Press, 2011 --- ## 用語集 ### HCD（人間中心設計 / Human-Centered Design）とは URL: https://designthinking.studio/glossary/human-centered-design/ > HCD（人間中心設計、Human-Centered Design）とは、人間のニーズ・行動・制約を出発点としてシステムやサービスを設計するアプローチ。ISO 9241-210で国際規格化されている4つの活動プロセスを解説する。 HCD（人間中心設計、Human-Centered Design）とは、製品やサービスの設計プロセスにおいて、エンドユーザーのニーズ・能力・行動を中心に据える設計アプローチのことだ。 ISO 9241-210（旧ISO 13407）で国際規格として定義されており、後述する4つの活動を反復的に回すプロセスとして規定されている。 HCDの4つの活動プロセス ISO 9241-210が定めるHCDプロセスは、次の4活動を1サイクルとして繰り返す構造を持つ。1回で完成させるのではなく、評価の結果に応じて前段の活動へ戻る反復性が核心である。 - 利用状況の理解（Understand the context of use） 誰が、どんな環境で、どんな目的でその製品・サービスを使うのかを把握する段階。ユーザー観察やインタビューを通じて、利用者の行動パターンや制約条件を具体的に洗い出す。 - 要求事項の明確化（Specify the user requirements） 利用状況の理解から得た情報をもとに、ユーザーが本当に必要としている要件を言語化する段階。表面的な要望ではなく、その背後にある目的や課題を要件として定義し直す。 - 設計解の作成（Produce design solutions） 明確化した要求事項を満たす設計案を、プロトタイプやモックアップの形で具体化する段階。低精度の試作から始め、段階的に忠実度を上げていくのが一般的である。 - 要求事項に対する評価（Evaluate the design against requirements） 作成した設計解を実際のユーザーに使ってもらい、要求事項を満たしているかを検証する段階。この評価で新たな課題が見つかれば、1の利用状況の理解へ戻り、サイクルを再度回す。 デザイン思考との違い デザイン思考はHCDの考え方を取り入れつつ、よりビジネスイノベーションに焦点を当てた方法論として発展した。HCDが国際規格に基づく設計プロセスの標準であるのに対し、デザイン思考はイノベーション創出のためのマインドセット・思考法という性格が強く、両者は排他的ではなく重なり合う関係にある。共感フェーズでのユーザー観察・インタビューは、HCDにおける「利用状況の理解」と手法的に重なる。 HCDをサービス設計の文脈に展開した実装論については Human-Centered Service Design（人間中心サービスデザイン）の実装 で詳述している。 --- 参考文献 - ISO 9241-210:2019, "Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems", International Organization for Standardization, 2019 --- ### Human-Centered Service Design（人間中心サービスデザイン）の実装 — 顧客体験設計の理論 URL: https://designthinking.studio/glossary/human-centered-service-design/ > 顧客のニーズ・行動・文脈を設計の起点とし、サービス接点全体を体験として統合的に設計するアプローチ。デザイン思考とサービスデザインの交差領域で機能する。 Human-Centered Service Design（人間中心サービスデザイン）は、サービスを「提供する側の都合」ではなく「利用する人間の体験」を起点として設計するアプローチです。略称HCSD。製品設計に起源を持つ人間中心設計（HCD）の考え方を、複数の接点・時間・人員が絡み合うサービスという複雑系に適用した実践体系です。 デザイン思考の5フェーズ（共感→定義→創造→プロトタイプ→テスト）とサービスデザインの手法体系（サービスブループリント、ジャーニーマップ、タッチポイント設計）が交差する領域で機能します。 --- なぜ「Human-Centered」が必要なのか サービスは製品と異なり、体験が時間をかけて展開されます。顧客が最初に認知し、申し込み、利用し、問題が起きたとき問い合わせ、そして離脱するまで——この一連の流れのどこかに「体験の断絶」が生まれると、顧客は不満を抱えます。しかし組織は部門ごとに分断されているため、自分の担当接点しか見えないことが多い。 Human-Centered Service Designが解決しようとするのはこの「設計の断絶」です。 顧客の行動と感情を時系列で追い、全接点を一貫した体験として設計する視座を提供します。 --- 理論的背景 Human-Centered Service Designは複数の知的伝統が交差しています。 ISO 9241-210（人間中心設計の国際規格）は、利用状況の理解・要求事項の明確化・設計解の作成・評価という4活動の反復を規定しています。この枠組みがサービス設計に適用されたのが HCSDの土台です。 サービスドミナントロジック（SDL）はバーゴとラッシュ（Vargo & Lusch, 2004年）が提唱した経済理論で、価値は提供者が生産するのではなく「顧客との共創」によって実現されると説きます。これがHCSDにおける「共創（co-creation）」の概念的根拠になっています。 デザイン思考はd.schoolやIDEOが実践として体系化したプロセスで、HCSDの「どうやって顧客を理解するか」という方法論的な支柱として機能します。 --- 実装の4ステップ ステップ1：利用文脈の観察 インタビューや現場観察でユーザーの行動・感情・文脈を収集します。重要なのは「サービスを使う瞬間だけ」を観察するのではなく、そのサービスを利用するに至った経緯から利用後の行動までをトレースすることです。 銀行口座開設の設計を例にとれば、「申込フォームを入力する」場面だけでなく、「なぜ今この銀行を選んだのか」「開設後に何をしようとしているのか」まで観察の射程に入れます。 ステップ2：体験の可視化 収集したデータをジャーニーマップとして可視化します。横軸に時間軸（フェーズ）、縦軸に感情曲線・タッチポイント・バックステージの動きを配置します。 このとき「スマイルとペイン」を明確に記録します。顧客が感情的に満足している接点と、不満・混乱・不安を感じている接点を色分けすることで、どこを優先的に改善すべきかが視覚化されます。 ステップ3：機会領域の定義 ジャーニーマップから「ペインが集中している接点」と「体験が断絶している移行点」を抽出します。これをHow Might We（HMW）の形式に変換し、設計の問いとして定式化します。 「お客様がなぜ途中離脱するのか分からない」という曖昧な問いを、「どうすれば申込完了後の不安を30分以内に解消できるか」という具体的な設計問題に変換するのがこのステップの目的です。 ステップ4：プロトタイピングと検証 サービスブループリントを活用し、フロントステージ（顧客が見える部分）とバックステージ（裏側の業務）を同時に設計します。設計解をロールプレイや紙のプロトタイプで試し、顧客と共に改善を繰り返します。 --- デザイン思考との接続 Human-Centered Service DesignはHCDの規格論と、デザイン思考の実践プロセスを橋渡しする概念です。 組織変革とデザイン思考の文脈では、顧客体験の改善と組織内部のプロセス変革が連動することが求められます。HCSDは外部向けの体験設計と、内部の業務設計を同時に扱う点で、純粋なUX設計より射程が広い。 --- 関連用語 - デザイン思考 — 共感・定義・創造・プロト・テストの5フェーズ実践体系 - カスタマージャーニーマッピング — 体験の可視化手法 - サービスブループリント — フロント/バックステージの構造設計ツール - ダブルダイヤモンド — 問題の発散・収束プロセス --- ### POV（Point of View）ステートメント URL: https://designthinking.studio/glossary/point-of-view/ > 共感フェーズで得たインサイトを、解くべき問題として明文化するためのフレームワーク。Define段階の核となる成果物。 POV（Point of View）ステートメントは、デザイン思考のDefineフェーズにおける核心的な成果物です。スタンフォード大学d.schoolが体系化したフレームワークで、共感フェーズで発見したインサイトを、チーム全員が共有できる「解くべき問い」に変換する役割を担います。 構造 POVステートメントの基本形は以下の通りです。 [ユーザー]は[ニーズ]を必要としている。なぜなら[インサイト]だから。 この3要素---ユーザー、ニーズ、インサイト---を明確に言語化することで、問題の焦点が定まります。d.schoolではこの形式を「POV Madlibs（穴埋め式）」と呼んでいます。 ニーズは動詞で表現するのが原則です。「安心感」ではなく「自分のペースで進められること」のように、行動に落とし込める形にすると、後のIdeateフェーズで具体的なアイデアが出やすくなります。 良いPOVと悪いPOVの違い 悪い例を見てみましょう。 「ユーザーは使いやすいアプリを必要としている。なぜなら現在のアプリが使いにくいから。」 この文はトートロジー（同語反復）に陥っています。「使いにくいから使いやすさが必要」では何も新しい情報がありません。インサイトの部分が、ニーズの言い換えになってしまっています。 良い例はこうなります。 「週末に一人で旅行する30代の会社員は、現地で偶然の出会いを楽しめる体験を必要としている。なぜなら、計画通りに進む旅行に物足りなさを感じており、予定外の体験にこそ旅の価値を見出しているから。」 ユーザーが具体的で、ニーズが動詞で記述され、インサイトが「意外性」を含んでいます。 「旅行者は効率的な計画を求めている」という一般的な仮説を覆す視点がここにあります。 作成プロセス POVステートメントは、ユーザーインタビューや共感マップで集めたデータを、親和図法でグルーピングした後に作成します。 作成のステップは以下の通りです。 - ユーザーの特定 --- 具体的なペルソナや実在のインタビュー対象者を設定 - ニーズの抽出 --- 「ユーザーが達成したいこと」を動詞で表現 - インサイトの言語化 --- 共感フェーズで得た、チームの前提を覆す発見を明文化 - 統合 --- 3要素をPOVの型にはめ込み、チーム全員でレビュー 1つのプロジェクトで複数のPOVを作成し、最も可能性のあるものを選択するのが一般的な進め方です。3〜5個のPOV候補を作り、チームで議論して絞り込みます。 Ideateフェーズへのつながり POVステートメントが確定したら、「How Might We（どうすれば〜できるか）」の問いに変換し、Ideateフェーズに進みます。 POVとHMWの関係は、問題の定義（POV）から解決の探索（HMW）への橋渡しです。HMWが広すぎる場合はPOVの焦点がぼやけているサインであり、定義に戻って再検討します。問題定義フェーズの記事も合わせてご覧ください。 --- 参考文献 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2011（改訂版2018） --- ### アブダクション（仮説的推論） URL: https://designthinking.studio/glossary/abductive-reasoning/ > チャールズ・S・パースが定式化した第三の推論形式。観察から最も妥当な仮説を導く思考プロセスで、ロジャー・マーティンはこれをデザイン思考の知的核心と位置づけた。 デザイン思考はなぜ機能するのか。この問いに正面から答えようとした経営思想家ロジャー・マーティンは、その答えを19世紀の哲学に求めた。チャールズ・サンダース・パース（Charles Sanders Peirce, 1839〜1914）が定式化したアブダクション（仮説的推論）——演繹でも帰納でもない、第三の推論形式である。 三つの推論形式の違い 人間の推論をパースは大きく三つに分類した。それぞれの機能と限界を理解することが、アブダクションの本質に迫る最短経路となる。 演繹法（Deduction）は、確立された前提から必然的に正しい結論を導く。「すべての人間は死ぬ。ソクラテスは人間だ。ゆえにソクラテスは死ぬ」。数学や論理学の領域で威力を発揮するが、前提そのものの正しさは検証できない。既知の解から既知の結論へと進む推論であり、新しいものは何も生み出さない。 帰納法（Induction）は、多数の事例の観察から一般法則を導く。「この袋から取り出した豆は白い、また白い、また白い——したがってこの袋の豆はすべて白いだろう」。科学的実験の多くがこの形式をとる。ただし過去の観察から未来を予測するものであり、前例のない問題には対応できない。 アブダクション（Abduction）は、驚くべき観察から出発する。「この豆は白い（驚くべき事実）。もしこの袋の豆がすべて白いなら（仮説）、この豆はこの袋から来たはずだ（最も妥当な説明）」。パースはこれを「仮説形成（Hypothesis）」とも呼んだ。アブダクションは説明を求めて仮説を生成する推論であり、創造的思考の論理的基盤だ。 パースの定義を正確に引用すると「驚くべき事実Cが観察される。しかしもしHが真であれば、Cは当然のことになる。したがって、Hが真であると疑う理由がある」。仮説Hは確実ではない。しかしアブダクションなしに、人間は新しい理解には到達できない。 ロジャー・マーティンの読み解き マーティンが2009年の著書 The Design of Business: Why Design Thinking Is the Next Competitive Advantage（邦題『ザ・デザイン・オブ・ビジネス』）で展開した主張の核心は、デザイン思考の知的エンジンがアブダクションであるというものだ。 マーティンは「ナレッジファネル」という概念を提示した。ビジネスにおける知識の進化は「謎（Mystery）→ヒューリスティクス（Heuristic）→アルゴリズム（Algorithm）」という段階をたどる。多くの企業はアルゴリズムの最適化（効率）に集中するあまり、謎の段階——つまりイノベーションの出発点——への投資をやめてしまう。 この謎の段階で機能するのがアブダクションだ。演繹法では「どうすれば既存のアルゴリズムを改善できるか」しか問えない。帰納法では「過去のデータが示すパターンは何か」しか見えない。しかしアブダクションは「観察された現象を最もうまく説明する新しい仮説は何か」を問うことができる。アブダクションこそが、企業が謎の段階に踏み込むための論理的装置だとマーティンは論じた。 マーティンはさらに、多くのビジネスリーダーがアブダクション的思考を「直感」と混同していると指摘する。アブダクションは根拠なく結論に飛ぶ直感ではない。観察された事実を出発点とし、最も説得力ある仮説を構造的に生成する論理的推論だ。デザイン思考の実践者が「データを見て仮説を作る」と言うとき、その思考の形式こそがアブダクションである。 デザイン思考プロセスとの対応 デザイン思考の5フェーズ（共感・定義・創造・プロトタイプ・テスト）は、アブダクションを体系的に運用するフレームワークとして読み解くことができる。 共感フェーズでのアブダクション ユーザー観察とインタビューの場で、実践者は「驚くべき行動」に繰り返し出会う。「なぜこの人はこんな使い方をするのか」「なぜここで詰まるのか」という驚きに対して、「もしかしたらこういう理由があるのかもしれない」という仮説を生成する。この瞬間がアブダクションだ。観察を積み重ねるだけでは仮説は生まれない。驚きを起点とした仮説生成の行為が、データと洞察の間を架橋する。 定義フェーズでのアブダクション 複数のインタビューデータを前に「これらの観察をすべて説明できる根本的な洞察は何か」と問うとき、チームはアブダクション的に思考している。データが直接答えを教えてくれるわけではない。データを最もうまく説明できるインサイトを思考が生成する。この生成行為そのものがアブダクションであり、ダブルダイヤモンドの最初の収束——「正しい問いを定義する」段階——の論理的基盤となっている。 プロトタイプフェーズでのアブダクション プロトタイプを作る行為は、「もしこの設計であればユーザーは使えるだろう」という仮説を物理的・デジタル的に具現化することだ。プロトタイピングはアブダクションの産物であり、テストはその仮説の検証プロセスとなる。マーティンが強調するように、デザイン思考の価値は「正しい答えを出すこと」より「より良い仮説を素早く生成し検証すること」にある。 「やっかいな問題」との関係 やっかいな問題（Wicked Problems）——複雑で構造化されていない課題——に演繹法と帰納法が有効に機能しない理由は明確だ。演繹法が必要とする「正しい前提」が存在せず、帰納法が依拠する「十分な過去の事例」もない。しかし現実のビジネス課題の多くは、この「やっかいな問題」の特性を持つ。 アブダクションは、前提が確立していない状況でも思考を前に進める。観察から仮説を生成し、仮説を検証し、検証結果を新たな観察として次の仮説に活かす——このサイクルこそが、不確実性の高い環境で機能するデザイン思考の動作原理だ。 ワークショップでの観察 200回以上のワークショップで繰り返し観察されるパターンがある。参加者がデータを「分析」し「解釈」しようとするとき、多くの場合は帰納法の枠で動く。過去の事例に当てはめ、パターンを探す。しかし「驚くべき観察から最も妥当な説明を考える」というアブダクション的な問いかけに切り替えた瞬間、チームの思考の質が変わる。 具体的には、以下の問いかけが有効だ。「このユーザーの行動で最も驚いたことは何ですか」「その驚きを説明できる仮説を3つ挙げるとしたら」「その3つのうち、最もデータに整合する仮説はどれですか」——この問いの連鎖がアブダクションを実践的な場で起動させる。 理論を「手触りのある実務」に翻訳することが、デザイン思考の使命だとすれば、アブダクションはその翻訳作業において最も核心的な思考形式である。演繹と帰納を使いこなすビジネスパーソンは多い。しかし「驚きから仮説を生成する」というアブダクション的思考を意識的に鍛えている人は少ない。ここにこそ、デザイン思考が提供できる知的価値がある。 --- 参考文献 - Roger Martin, The Design of Business: Why Design Thinking Is the Next Competitive Advantage, Harvard Business Press, 2009（邦訳：『ザ・デザイン・オブ・ビジネス』） - Charles Sanders Peirce, Collected Papers of Charles Sanders Peirce, Harvard University Press, 1931–1958 - 米盛裕二, 『アブダクション——仮説と発見の論理』, 勁草書房, 2007 - Kees Dorst, "The Core of 'Design Thinking' and its Application", Design Studies, Vol.32, No.6, 2011 --- ### ウィキッド・プロブレム URL: https://designthinking.studio/glossary/wicked-problem/ > ウィキッド・プロブレムとは問題定義自体が曖昧で唯一の解決策が存在しない複雑な問題類型。Rittel&Webber 1973の原論文に基づく10特徴、テイム・プロブレムとの対比、デザイン思考の反復プロセスが有効な理由を体系解説する。 ウィキッド・プロブレム（Wicked Problem）とは、 問題の定義自体が曖昧で、唯一正しい解決策が存在せず、解くたびに新しい問題が生まれる複雑に絡み合った問題 のことです。都市計画・気候変動・医療制度・教育改革など、現代社会の最も重要な課題の多くがこの類型に属します。 概念の起源 「ウィキッド・プロブレム」という概念は、デザイン理論家のHorst RittelとMelvin Webberが1973年の論文「Dilemmas in a General Theory of Planning」（Policy Sciences, 4(2)）で初めて定式化しました。Rittelは数学や科学で扱える「テイム・プロブレム（飼いならされた問題）」と対比して、社会計画の問題が本質的に異なる性質を持つことを指摘しました。 デザイン思考との関係において重要なのは、 デザイナーが歴史的に「ウィキッドな」問題と格闘してきた という事実です。Rittel自身、ウィキッド・プロブレムを最初に認識したのはデザインプロセスを観察することで得た洞察だと述べています。 ウィキッド・プロブレムの10の特徴 Rittelは原論文でウィキッド・プロブレムを特徴づける10の性質を挙げています。 - 問題の定義が定まらない — 問題を定義すること自体がすでに解決の一部であり、定義の仕方によって解決策が変わる - 試行錯誤できない — 解決策を試みた時点で不可逆的な変化が起きており、「試して元に戻す」ができない - 解決策の正否を判断できない — 「正しい解決策」ではなく「より良い解決策」「より悪い解決策」のグラデーションしか存在しない - 終点がない — 「問題が解けた」と宣言できる明確な終点がなく、解決は暫定的である - 解決策が副作用を生む — 一側面を解決すると別の側面に問題が生じる - 症状と原因の区別が難しい — 何が原因で何が症状かは観点によって変わる - 説明の方法が一つでない — 同じ問題を複数の視点から全く異なる枠組みで説明できる - 個別解しかない — 一つの解決策が別の問題にそのまま転用できない - 間違いが許されない — 解決を試みた計画者は結果に責任を負う - 複数のステークホルダーの価値観が競合する — 誰にとっての問題かによって、問題の性質と優先順位が変わる デザイン思考との接点 ウィキッド・プロブレムの認識は、デザイン思考がなぜ反復的なプロセスを採用するかの根拠を与えます。問題の定義自体が変化し続けるなら、一度の正確な問題定義と解決策の実行という線形プロセスは機能しません。 「共感→定義→発想→プロトタイプ→テスト」を何度も回る反復的なプロセスは、ウィキッドな問題への適切な応答 です。 特に問題定義フェーズにおける「HMW（どうすれば〜できるか）」という問いの立て方は、ウィキッド・プロブレムの「問題の定義が定まらない」という性質への回答です。問いを一つに固定せず、探索を続けながら問い自体を洗練させていきます。 テイム・プロブレムとの対比 ウィキッドでない問題（テイム・プロブレム）は、正しい解を持ちます。数学の方程式・チェスの詰め将棋・エンジンの故障診断——これらは複雑かもしれませんが、解き方の手順が存在し、解けた/解けないが判断できます。 多くの技術的問題はテイムです。しかし技術を社会に実装するとき（「誰に・どのように・どんな影響を与えるか」という問い）はウィキッドになります。AIの倫理問題・プラットフォームの規制・モビリティの未来——これらは技術的に解ける部分とウィキッドな部分を同時に含んでいます。デザインブリーフを起点に問いを立てることが、ウィキッドな問題へのアプローチの第一歩です。 --- 参考文献 - Horst W.J. Rittel & Melvin M. Webber, "Dilemmas in a General Theory of Planning," Policy Sciences, 4(2), 1973 - Richard Buchanan, "Wicked Problems in Design Thinking," Design Issues, 8(2), 1992 --- ### コ・クリエーション（共創） URL: https://designthinking.studio/glossary/co-creation/ > コ・クリエーションとはデザイナーと非デザイナー（ユーザー・市民・顧客）が共同で新たな価値を創造するプロセス。Sanders & Stappers 2008 の定義、参加型デザインとの違い、デザイン思考における活用場面を解説する。 「ユーザーのために設計する」から「ユーザーと共に設計する」へ。コ・クリエーション（Co-creation）は、この転換を体現する概念だ。 デザイナーが主導する従来のユーザー中心設計では、ユーザーは観察・インタビュー・テストの対象だった。コ・クリエーションでは、ユーザー自身がアイデアの発案者・評価者・制作者として設計プロセスに参加する。設計の「対象」から設計の「主体」へと役割が反転する。 概念の起源 コ・クリエーションの理論的基盤を確立したのは、Elizabeth B.-N. Sandersと Pieter Jan Stappersの2008年の論文「Co-creation and the new landscapes of design」（CoDesign, 4(1), 5–18）だ。 論文でSandersとStappersは、コ・クリエーションを「設計プロセスにおいて、最終的にサービス・製品の対象となる人々が専門家の位置に置かれ、知識開発・アイデア生成・コンセプト構築において主導的な役割を担う共同創造活動」と定義した。 重要なのは「専門家の位置に置かれる」という言葉だ。ユーザーは自分自身の体験の専門家であり、その経験知はデザイナーが外部から観察しても得られないものを含む。コ・クリエーションはその経験知を設計プロセスの中に直接取り込む。 参加型デザインとの関係 コ・クリエーションはしばしば参加型デザイン（Participatory Design）と同義に用いられるが、厳密には射程が異なる。 参加型デザインは1970年代のスカンジナビアに起源を持つ運動だ。職場環境の設計において、技術者だけでなく使用する労働者が意思決定に参加すべきという民主的な理念から発展した。当初の文脈は労働権と設計の関係だった。 コ・クリエーションはより広い概念で、ビジネス・教育・公共サービス・製品開発など多様な文脈を包含する。参加型デザインをその重要な流れとして含みつつ、企業の製品開発やサービスデザインの文脈にも接続している。 实務上、両者の区別を厳密にする必要性は低い。「ユーザーが設計の中心的な担い手になる」というエッセンスを共有している。 デザイン思考との接続 デザイン思考の5フェーズ（共感→定義→発想→プロトタイプ→テスト）において、コ・クリエーションは複数のフェーズに横断的に機能する。 共感フェーズでは、インタビューや観察に留まらず、ユーザー自身に自分の体験を「作って表現させる」手法が有効だ。写真日記（Photo Diary）、コラージュ、生活の出来事を付箋で記録させるアクティビティは、言語化されにくい体験を可視化する。 発想フェーズでは、ユーザーと設計チームが同じ場でアイデアを出し合う共創ワークショップが中核的な手法になる。設計の専門知識を持つチームと、体験の専門知識を持つユーザーが同席することで、机上では生まれない具体的な発想が出やすい。 プロトタイプ・テストフェーズでは、ユーザーがプロトタイプを受動的に評価するだけでなく、素材を使って自分なりの「理想形」を作る参加型プロトタイピングが用いられる。 参加の深さ：4段階のスペクトラム コ・クリエーションへの参加の深さは一様ではない。Sandersらは参加のレベルをスペクトラムとして整理している。 情報提供（Inform）: ユーザーがアンケートや基本インタビューで情報を提供する。設計の判断は専門家側が行う。 諮問（Consult）: フォーカスグループやユーザビリティテストで意見を求める。設計チームはフィードバックを参考にするが、最終決定は内部にある。 参加（Participate）: 共創ワークショップで、ユーザーがアイデア生成や評価に直接関わる。設計の方向性をユーザーと共に決める。 共同決定（Co-decide）: 設計の主要な意思決定において、ユーザーがプロジェクトメンバーと対等な立場で参加する。行政サービスや地域コミュニティの設計で用いられることが多い。 多くの企業のコ・クリエーション活動は「参加」レベルに位置する。ユーザーを招いた共創ワークショップが実務的な主要形式だ。 実践上の留意点 コ・クリエーションの最も典型的な誤解は「ユーザーに設計を任せること」だ。これは誤りで、設計の専門性をユーザーが代替するのではなく、専門家とユーザーが補完的に機能するのがコ・クリエーションの本来の姿だ。 参加者の多様性も重要だ。声の大きい参加者だけが意見を出せるワークショップは、結果として一部のユーザー像しか反映しない。年齢・バックグラウンド・技術リテラシーの異なる参加者を意図的に組み合わせることで、設計の多様性が確保される。 また、参加者に「プロセスへの貢献感」を持たせることが信頼関係の基本だ。意見が採用されなかった場合でも、なぜそうなったかをフィードバックする姿勢が、継続的な共創関係を支える。 --- ### コンセプトマッピング URL: https://designthinking.studio/glossary/concept-mapping/ > Joseph D. Novak が1972年に開発した知識可視化の手法。概念をノードとして、概念間の関係を有向リンクで記述することで、複雑な知識構造を外在化する。デザイン思考の定義フェーズにおけるインサイト統合と問いの構造化に活用される。 コンセプトマッピングは、知識をネットワーク状の図として外在化する手法だ。ノード（概念）とリンク（関係）で構成されるグラフ構造に知識を変換することで、個人の頭の中にある暗黙的な理解を共有可能な形に引き出す。デザイン思考の文脈では、ユーザー観察から得たデータを統合し、問いの構造を可視化するツールとして用いられる。 起源——Novak の「有意味学習」理論 コンセプトマッピングは、コーネル大学（Cornell University）の教育学者 Joseph D. Novak が1972年の研究プログラムの中で開発した。開発の背景にあったのは、「生徒が科学の概念をどのように理解しているか」を評価・可視化する方法がないという実践的な問題だ。 Novak の理論的基盤は、心理学者デイヴィッド・オーズベル（David Ausubel）の「有意味学習（Meaningful Learning）」理論にある。オーズベルは、人間が新しい概念を学ぶとき、既存の知識構造に「固定」することで理解が起こる——この過程を「同化（assimilation）」と呼んだ。暗記（rote learning）はこの固定なしに記号だけを頭に入れる行為であり、応用が効かない。 Novak はこの「既存概念への固定」というプロセスを可視化するために、コンセプトマップを発明した。概念間の関係を言葉つきのリンクで明示することが、有意味学習の証拠になると考えたからだ。 1984年の著書 Learning How to Learn（Novak & Gowin）でコンセプトマッピングが広く紹介され、教育・ナレッジマネジメント・デザインの各領域に波及した。 コンセプトマップの構造 コンセプトマップは3つの要素で構成される。 ノード（Concept Nodes） は、楕円形または四角形の中に概念ラベルを書いたものだ。「ユーザー」「不満」「待ち時間」「代替手段」のように、名詞または名詞句で記述する。 リンク（Linking Lines） は、ノード間を結ぶ有向線だ。矢印の方向が関係の方向性を示す。 リンクラベル（Linking Phrases） は、リンクの上に書かれた動詞・副詞句だ。「〜は〜を引き起こす」「〜は〜の一種である」「〜は〜によって軽減される」など、関係の性質を言語化する。このラベルの存在がコンセプトマップをマインドマップと区別する最も重要な特徴だ。 リンクラベルを読んでいくと、ノードとラベルと次のノードが命題（proposition）を形成する——「待ち時間は不満を引き起こす」「不満は代替手段の探索を促す」という形だ。コンセプトマップは、知識を命題の集合体として外在化する道具だ。 さらに Novak は「クロスリンク（Cross-links）」の重要性を強調した。マップ内の異なる概念群を横断する関係線であり、知識の創造的な再統合を示す。クロスリンクが豊富なマップは、単なる理解の記録ではなく、新しい洞察が生まれていることを示す指標として機能する。 マインドマップとの違い コンセプトマッピングはマインドマップ（Tony Buzan が普及）としばしば混同されるが、構造的に異なる。 | 比較軸 | コンセプトマップ | マインドマップ | |---|---|---| | 構造 | ネットワーク（多方向） | ツリー（中心放射状） | | 関係の記述 | リンクラベル（言語化必須） | リンクラベルなし | | 命題の形成 | 有（ノード＋ラベル＋ノード） | 無 | | 始点 | 複数可 | 必ず1つの中心トピック | | 理論的基盤 | 認知学習理論（Ausubel） | 放射思考・記憶術 | マインドマップはブレインストーミングと記憶補助に優れており、コンセプトマップは知識の構造的分析と複数人での理解共有に優れている。デザイン思考のプロセスでは、発散的な場面にはマインドマップを、収束的な分析・統合の場面にはコンセプトマッピングを使い分けることが多い。 Cmap Tools——知識可視化の実装 コンセプトマッピングをデジタルで実装する主要なツールが Cmap Tools だ。フロリダのインスティテュート・フォー・ヒューマン・アンド・マシン・コグニション（IHMC: Institute for Human and Machine Cognition）が開発・提供しており、無料で利用できる。 Cmap Tools の特徴は、ノードとリンクの作成・編集のシンプルさだけでなく、コンセプトマップをクラウド上で共有・共同編集する機能にある。複数の研究者やデザインチームが同一のマップを非同期で編集でき、知識の集合的な外在化に適している。 また、各ノードに補足文書・画像・URL を紐づける「Cmap Knowledge Model」機能により、コンセプトマップを単なる図ではなくナビゲート可能な知識ベースの入口として構成することができる。 IHMC は教育・医療・航空・軍事など多様な領域でコンセプトマッピングの応用研究を継続しており、Cmap Tools はその実践基盤として世界の研究機関・教育機関に普及している。 デザイン思考での応用 コンセプトマッピングはデザイン思考の複数のフェーズで活用できるが、特に力を発揮するのは定義フェーズにおけるデータ統合と問いの構造化だ。 共感フェーズ後のデータ統合 フィールド調査・インタビュー・観察から大量のデータが得られた後、チームは「どこに問題の核心があるか」を掴もうとする。この段階でコンセプトマップを使うと、「このユーザーの不満はどの概念と繋がっているか」「複数のユーザーに共通して現れる概念クラスターは何か」を構造的に探索できる。 付箋や KJ 法による親和図法がボトムアップに概念を集約するのに対して、コンセプトマッピングは概念間の因果・包含・相関の関係性を明示するという点で補完的だ。親和図法で見えた「クラスター」がなぜ1つにまとまるのかを、コンセプトマップは説明する。 インサイトの可視化と共有 定義フェーズで生成されるインサイトは、しばしば「このユーザー群が抱える問題の根本は〇〇だ」という命題の形をとる。コンセプトマップはこの命題を視覚的に構造化し、チーム全員が同じ理解を持てるよう共有の基盤を提供する。 特に多職種・多背景のチームが協働するプロジェクトでは、それぞれが異なる「前提概念」を持っているために、言葉の意味の食い違いが生じやすい。コンセプトマッピングの作業過程でリンクラベルを議論することは、この前提概念の違いを表面化させる有効な手段になる。 How Might We への橋渡し コンセプトマップで「問題の構造」が可視化されると、どのノードとリンクに介入すれば状況が変わるかが見えてくる。「このリンク（因果関係）を切断できるか」「このノード（概念）を再定義できるか」という問いが、HMW（How Might We）の出発点を豊かにする。 アブダクション（仮説的推論）の視点からいえば、コンセプトマップの「驚くべきクロスリンク」——普通は繋がらないと思われていた概念が実は関係していた——が最も強力なインサイトの源泉になる。 システム思考との統合 システム思考のループ図や因果ループ図はコンセプトマッピングと近い構造を持つが、時間軸上の動的な変化（フィードバックループ）に焦点を当てる点で異なる。複雑な社会課題に取り組むプロジェクトでは、コンセプトマッピングで概念構造を把握した後、システム思考で動的な関係性を分析するという使い分けが有効だ。 ワークショップでの実践 コンセプトマッピングをデザインワークショップに導入する際の実践的な手順を示す。 Step 1: 焦点概念の設定（Focus Question） Novak はコンセプトマップを描く前に「焦点となる問い（Focus Question）」を設定することを強く推奨している。「患者の入院体験において何が不安を生じさせているか」「社員がこのシステムを使わない理由は何か」のように問いを明確にすることで、マップの範囲と目的が定まる。 Step 2: 概念リストの作成（Parking Lot） 焦点問いに関連する概念を付箋に書き出す。この段階では関係性は考えない。Novak はこれを「駐車場（Parking Lot）」と呼び、最初に思い浮かんだすべての概念を一時保管する場とした。 Step 3: ランキングと配置 概念を「より包括的なもの」から「より具体的なもの」の順に上から下へ配置する（階層構造）。ただしすべてのマップが厳密な階層構造を持つ必要はなく、ネットワーク状に展開することもある。 Step 4: リンクとリンクラベルの作成 関連する概念を線で結び、必ずリンクラベルを書く。ラベルなしのリンクはコンセプトマップではなくマインドマップになる。「〜を引き起こす」「〜の結果である」「〜に依存する」「〜と協働する」など、関係の性質を動詞句で表現する。 Step 5: クロスリンクの探索 マップが出来上がった後、異なる概念群を横断するリンクを探す。この作業が最も知的な集中力を要し、同時に最も価値の高い洞察を生む段階だ。 限界と補完 コンセプトマッピングにも限界がある。 時間コスト。 良質なコンセプトマップの作成は、慣れていないチームには1〜2時間かかることがある。アジャイルなプロジェクト環境では、その時間を確保することが難しい場合がある。 主観性。 同じデータからでも、チームによって異なるコンセプトマップが生成される。これは「欠陥」ではなく「特徴」だが、マップを一義的な「正解」として扱うことへの警戒が必要だ。 動的な変化の表現。 コンセプトマップは静的な構造を表す。時間とともに変化するシステム、フィードバックループ、因果の連鎖を表現するには、システム思考のツール群を組み合わせることが求められる。 これらの限界を踏まえると、コンセプトマッピングは他の発散・収束ツールと組み合わせて使うときに最も力を発揮する。共感フェーズでのインタビューデータ、定義フェーズでの KJ 法、そしてコンセプトマッピングによる構造化という流れが、実践的な組み合わせとして有効だ。 --- 参考文献 - Joseph D. Novak & D. Bob Gowin, Learning How to Learn, Cambridge University Press, 1984 - Joseph D. Novak, Learning, Creating, and Using Knowledge, Lawrence Erlbaum Associates, 1998 - Alberto J. Cañas & Joseph D. Novak, "Concept Mapping Using CmapTools to Enhance Meaningful Learning", in A. Okada, T. Connolly & P. Scott (eds.), Collaborative Learning 2.0, IGI Global, 2012 - IHMC CmapTools: https://cmap.ihmc.us - David Ausubel, Educational Psychology: A Cognitive View, Holt, Rinehart and Winston, 1968 関連記事: アブダクション（仮説的推論） / システム思考 / デザイン思考の定義フェーズ / ダブルダイヤモンド / コンセプトマッピング・ツール比較 --- ### コンセプトマッピング ワークショップ進行ガイド — チームで知識構造を可視化する URL: https://designthinking.studio/glossary/concept-mapping-workshop-facilitation/ > コンセプトマッピングをチームで共同作成するワークショップの進行手順。発散・構造化・収束の3フェーズ、収束ルール、デジタルホワイトボードの運用方法、よくある失敗とその対処を解説する実践ガイド。 チームでコンセプトマッピングを行うとき、個人作業とは別の難しさが生まれる。「概念の粒度がバラバラ」「リンクラベルを巡って議論が発散する」「気づいたらファシリテーターだけが付箋を動かしている」——こうした状況は、手順と収束ルールが事前に共有されていないことから起きる。 本記事では、2〜8名規模のチームワークショップを前提に、準備から成果物の確定までの実践的な進行方法を記述する。 ワークショップの準備 当日の進行を安定させるには、3つの準備が欠かせない。 焦点問いの設定。 Joseph Novak が強調したように、「焦点となる問い（Focus Question）」がないマッピングは散漫になる。セッション開始前にファシリテーターが問いを草案し、チームに確認しておく。「このシステムを利用者が使い続けない理由は何か」「新サービスが既存顧客に受け入れられるために何が必要か」のように、探索の範囲と目的が伝わる形にする。 素材の用意。 対面の場合はA3ないしA1サイズの模造紙と色の異なる付箋2種（概念用・リンクラベル用）、太めのマーカーがあれば十分だ。デジタルの場合は後述のツール選定を先に済ませておく。 参加者への事前説明。 「コンセプトマップはマインドマップではない」という認識合わせは当日でも間に合うが、初参加者が多い場合はチェックシートなどで事前に伝えておくとスムーズだ。リンクラベルを言語化することへの抵抗感が最初の障壁になりやすい。 --- 3フェーズの進行 フェーズ1：発散（所要目安20〜30分） 焦点問いを全員が見えるところに掲示した状態で、各自が思い浮かんだ概念を付箋に書き出す。1枚1概念が原則だ。名詞または名詞句に絞り、動詞文や文章は書かない。「利用者の操作ミス」は使えるが「利用者が操作ミスをしやすい」は概念ではなくすでに関係性の記述になっている。 この段階では他の人の付箋を見ながら追加してよい。10〜15分で個人作業を終えたら、ファシリテーターが全員に付箋を読み上げてもらいながら壁や模造紙に貼り出す。重複している概念はこの時点で1枚に統合するか残しておくかをチームで判断する。 最低でも20〜30枚の概念が出ていれば次のフェーズに移れる。少ない場合は「観察した具体的な場面を起点に何が見えたか」を問い直すと概念が追加されやすい。 フェーズ2：構造化（所要目安30〜40分） 概念を位置づけていく。上位から下位へ（より包括的な概念から具体的な概念へ） という階層を意識しながら縦軸に配置するのが基本だが、ネットワーク状に広がるケースも多い。無理に厳密な階層を作ろうとせず、「この概念はこの概念より範囲が広い」という感覚で動かしていく。 配置が安定したら、関連する概念同士を線で結び始める。この段階でリンクラベルを書くことが最大のポイントだ。「〜は〜を増幅させる」「〜は〜の原因の一つだ」「〜は〜に依存している」のように動詞句を1〜2行で書いた付箋をリンクの上に貼る。ラベルが書けないリンクは関係がまだ曖昧な証拠であり、無理につながなくてよい。 この工程で議論が白熱しやすい。「その関係は因果か相関か」「この概念は1つに統合すべきか分けるべきか」といった問いは、チームの認識の差を表面化させる。ファシリテーターの役割はこの議論を止めることではなく、議論の結論をマップ上のラベルに反映させることだ。 フェーズ3：収束（所要目安20〜30分） クロスリンクの探索から始める。異なる概念群を横断するリンク——通常は繋がらないと思われていた概念が実は関係していた——を見つけた場合は赤いマーカーまたは目立つ色で描く。クロスリンクはインサイトの濃度を示す指標だ。 収束フェーズでは不要な概念の削除も行う。焦点問いとの関係が希薄だと判断された概念は「駐車場（Parking Lot）」エリアに移動し、マップの主要部分から外す。削除ではなく移動にとどめることで、後から再評価できる。 最後に、完成したマップ全体をチームで通読し、「このマップを3文で要約すると何か」を言語化する。この要約がインサイトの核になる。 --- 収束ルール 議論が発散しやすいワークショップで収束を促すための基準を事前に合意しておく。 「2票ルール」。 特定の概念やリンクについて合意できない場合、参加者の過半数が支持する案を採用する。少人数（3〜4名）では挙手、大人数ではドット投票が使いやすい。 「Parking Lot への一時退避」。 1分以上議論が続くようなら、問題の概念やリンクを駐車場に移してセッション後半に再検討する。マップの進行を止めないための実践的な安全弁だ。 「ラベルが書けないリンクは引かない」。 動詞句でリンクラベルを明示できない関係線はマップに加えない。このルールがあることで「なんとなく関係している気がする」という曖昧な結合を排除できる。 「概念の粒度統一チェック」。 構造化フェーズの終盤に一度立ち止まり、概念の抽象度が極端に異なる付箋がないか確認する。「ユーザー体験全体」と「ボタンのラベル文言」が同列に並んでいる場合は、どちらかをより適切な階層に移動させる。 --- デジタルホワイトボードの運用 ツール比較記事で詳細を扱っているが、ワークショップ文脈での運用ポイントを補足する。 テンプレートを事前に作る。 FigJam・Miro・Mural のいずれを使う場合も、焦点問いをキャンバス上部に固定し、概念用・リンクラベル用のスティッキーノートをカラーで区別する設定を事前に済ませておく。当日この設定を行うと参加者が待つ時間が生まれ、集中が途切れる。 「全員同時編集」と「発表者1名編集」の切り替え。 発散フェーズは全員が同時にノートを追加する全員編集モードで進める。構造化フェーズ以降は、ファシリテーターまたは指名した1名がノードを動かしながら他のメンバーが口頭で指示を出す発表者モードに切り替える方が混乱が少ない。 定期スナップショット。 構造化フェーズの開始時・終了時・収束後の3タイミングで画面をエクスポートしておく。最終形だけ残すと「なぜこの構造になったのか」というプロセスが失われる。議論の変遷を共有できることが、後続のステークホルダーへの説明材料になる。 解像度と命名。 共有URLやファイル名には焦点問いの要点を入れる。「ConceptMapv3.png」よりも「システム不使用要因コンセプトマップ_20241025.png」の方が後から参照しやすい。 --- よくある失敗と対処 「付箋の山が出来るだけで終わる」問題。 原因はほぼ全て「リンクラベルを後回しにしたこと」だ。構造化フェーズに入ったら、概念の配置よりも先にリンクラベルの作成を促すことで防げる。 「ファシリテーターの独壇場になる」問題。 ファシリテーターが一人でノードを動かし続けると、他の参加者は傍観者になる。4名以上の場合は概念群をエリアに分けて担当者を設けるか、タイマーを使って数分おきに作業者を交代させる。 「全体像を誰も把握していない」問題。 大きなキャンバスで各自が作業し続けると、全体の構造が見えなくなる。30分に1回程度、全員で俯瞰視点に戻り「今どこを作っているか」「焦点問いとの整合はあるか」を確認するブレイクを入れる。 「終了後に使われないマップになる」問題。 ワークショップで生成したマップは、翌日には参加者の記憶から薄れる。収束フェーズで作った3文の要約と、次のアクションへの橋渡し（HMW の問いへの展開など）をセッション終了前に必ず行う。マップは手段であり、アウトプットは意思決定や問いの深化でなければならない。 --- コンセプトマッピングの理論的背景 / デジタルツール比較 / デザイン思考の定義フェーズ --- ### コンセプトマッピング・ツール比較 URL: https://designthinking.studio/glossary/concept-mapping-tool-comparison/ > コンセプトマッピング (概念マップ) の代表的ツール 7 種を、用途・コラボレーション機能・学術引用・価格・エクスポート形式で横断比較。CmapTools / Miro / FigJam / Mural / Lucidspark / XMind / Whimsical の選定基準を示す。 コンセプトマッピング (概念マップ) は Joseph D. Novak が1972年に Cornell 大学で開発した知識構造化手法であり、デザイン思考の Define / Ideate フェーズで頻繁に使われる (詳細はコンセプトマッピング参照)。本稿は手法ではなく 作成ツール7種 をユースケース別に横断比較する。 選定の主要観点は5つ。用途特化度 (学術・教育 vs. ビジネス)、コラボレーション機能 (同時編集・コメント)、学術・実務の採用率、価格モデル、エクスポート形式 (PNG/SVG/PDF/構造化XML)。 --- 比較表 | ツール | 主用途 | 提供 | 無料枠 | 学術引用 | コラボ | 出力形式 | |---|---|---|---|---|---|---| | CmapTools | 学術・教育 | IHMC | 完全無料 | 1,000+論文 | サーバ共有 | CXL / IMG | | Miro | ビジネス・デザイン | Miro Inc. | 3ボード | 限定的 | 同時編集◎ | PNG/PDF/CSV | | FigJam | デザイン・UX | Figma | 3ファイル | 限定的 | 同時編集◎ | PNG/PDF | | Mural | エンタープライズ | Mural Inc. | 3スペース | 限定的 | 同時編集◎ | PNG/PDF | | Lucidspark | ビジネス | Lucid Software | 3ボード | 限定的 | 同時編集◎ | PNG/PDF/SVG | | XMind | 個人・実務 | XMind Ltd. | 機能制限 | 限定的 | 限定的 | XMind/PNG/SVG | | Whimsical | デザイン・SaaS | Whimsical | 4ボード | 限定的 | 同時編集◎ | PNG/PDF/SVG | (価格・無料枠は2026年時点の代表的なプラン構造。各社改定で変動するため公式サイトで要確認) --- 各ツールの位置づけ - CmapTools — 学術研究で唯一の標準 IHMC が開発・配布するコンセプトマッピング専用の無料ソフト。Novak 本人と Alberto Cañas が設計を主導し、教育学的思想を忠実に実装。独自XML形式 CXL で概念とリンクを意味的に記述可能、命題 (Proposition) の妥当性検証をサポートする。学術論文での引用蓄積は1,000本以上。UIが2000年代設計のままで同時編集・コメントは限定的、ビジネスデザインには不向き。推奨: 教育学・看護学・科学教育の研究。 - Miro — ビジネス・ワークショップの標準 オンラインホワイトボード最大手。同時編集・コメント・タイマー・投票機能が充実し、テンプレートライブラリが豊富 (Empathy Map / ジャーニーマッピング と統合運用可能)。Slack / Zoom / Notion / Jira 連携、SSO・監査ログ対応。命題構造を強制する機能はなく Novak モデルの厳密運用には不向き。本格運用は有料 (Team 月数千円〜)。推奨: リモートワークショップ、UXリサーチ統合。 - FigJam — Figma 連携が必要な UX チーム向け Figma 社のオンラインホワイトボード。同一アカウント・同一URLで運用でき、UXデザインチームの既存ワークフローに統合しやすい。ペンツールとセクション機能で手描き感のあるマップを作れる。教育機関は Pro 無料。Figma エコシステム外での優位性は限定的。推奨: Figma 利用のプロダクトチーム、スタートアップ。 - Mural — エンタープライズ用途 エンタープライズ向け機能 (アクセス制御・データガバナンス・ファシリテーション支援) に投資。Facilitation Superpowers (Private Mode, Summon 等)、IBM/Atlassian 等の大企業導入実績、SSO・SOC2・GDPR・HIPAA 対応。個人・小規模の費用対効果は Miro / FigJam より劣る。推奨: 大企業・規制業界 (金融・医療)、専任ファシリテーター。 - Lucidspark — Lucidchart 連携の構造図優位 Lucid Software (Lucidchart の提供元) のホワイトボード。「アイデア発散→構造図化」のフローが滑らか。投票・タイマー・ブレストモード、SOC2・GDPR 対応。認知度は Miro / Mural より低い。推奨: Lucidchart を既に使う組織。 - XMind — 個人作業・マインドマップ寄り 中国発のマインドマップ・コンセプトマッピング統合ツール。デスクトップ完結でオフライン作業可能、アウトライナーモードとの切替、個人プラン年¥6,000程度。リアルタイム共同編集は限定的。推奨: 個人の思考整理・読書ノート、オフライン環境。 - Whimsical — UI/UX 連携 + 軽量さ マインドマップ・フローチャート・ワイヤーフレーム・付箋ボードを統合した軽量ツール。動作軽快、UI洗練、個人・小規模に優しい価格。エンタープライズ機能とコンセプトマップ専用機能はない。推奨: SaaS 初期コンセプト整理、個人デザイナー、小規模スタートアップ。 --- ユースケース別の推奨 | 用途 | 第一候補 | 理由 | |---|---|---| | 学術研究・教育評価 | CmapTools | Novak モデルの忠実実装、CXL対応 | | 大企業・公共機関のワークショップ | Mural / Miro (Enterprise) | アクセス制御・データガバナンス必須 | | スタートアップ・プロダクトチーム | FigJam / Miro / Whimsical | コストと機能のバランス | | コンサルティング・ファシリテーター | Miro / Mural | テンプレートライブラリ、クライアント共有 | | 個人の思考整理 | XMind / Whimsical | オフライン可、軽量、低コスト | --- 選定の落とし穴 (3点) - 「同時編集できれば良い」の罠: 全員同時カーソル状態は思考を浅くする。ファシリテーターが「個人ワーク10分→共有10分」のリズムを設計しなければ深い思考は生まれない。Miro / Mural の Private Mode を活用する。 - 命題の妥当性検証を放棄する誤用: ビジネス向けツール (Miro / FigJam / Mural) は連結語 (linking words) の妥当性を強制しない。「企業→顧客」のような連結語なし矢印が量産されると Novak の Proposition モデルに反する (詳細: コンセプトマッピング)。ファシリテーターは「全矢印に動詞を書く」ルールを徹底する。 - エクスポート形式の確認不足: 学術・公共向け納品では構造化データ (CXL / OPML 等) でのエクスポートが必要なことがある。Miro / FigJam は PNG / PDF / CSV のみで構造化XML未対応。後工程要件を事前確認する。 --- 関連用語 - コンセプトマッピング — 手法そのものの解説 - システムシンキング統合 — システム思考との統合運用 - ダブルダイヤモンド — Define フェーズでの活用 - デザイン思考 — 全体フレームワーク --- 参考文献 - Novak, J. D., & Cañas, A. J. (2008). The Theory Underlying Concept Maps and How to Construct and Use Them. Technical Report IHMC CmapTools 2006-01 Rev 01-2008. - Novak, J. D., & Gowin, D. B. (1984). Learning How to Learn. Cambridge University Press. - Cañas, A. J., Hill, G., Carff, R., et al. (2004). CmapTools: A knowledge modeling and sharing environment. Proceedings of the First International Conference on Concept Mapping. - IHMC, "CmapTools," https://cmap.ihmc.us/ - Miro, "Concept Map Templates," https://miro.com/templates/concept-map/ --- ### サービスブループリント URL: https://designthinking.studio/glossary/service-blueprint-guide/ > 顧客の行動・接点（フロントステージ）と、顧客から見えない業務プロセス（バックステージ）を同一の図面に可視化するサービス設計ツール。顧客体験の全体構造とオペレーションの関係を把握するための設計図。 サービスブループリントは、顧客の体験（フロントステージ）と組織の業務プロセス（バックステージ）を一枚の図に統合したサービス設計図です。1984年にG. Lynn ShostackがHarvard Business Reviewに発表した論文「Designing Services That Deliver」で提唱された手法で、サービスデザインとデザイン思考の両分野で中心的な役割を担うツールとなっています。 なぜ重要か 多くのサービス問題は「フロントステージ（顧客が体験する部分）の改善」だけを試みて失敗します。受付担当者の応対スキルを研修しても、バックステージの情報連携が機能していなければ、顧客への情報提供は改善されません。 サービスブループリントの力は「顧客の体験と組織の業務プロセスが、どう接続（あるいは断絶）しているかを可視化する」点にあります。この可視化によって、「顧客体験の問題がどのバックステージ・システムの問題に起因しているか」 の因果関係が明確になります。 サービスブループリントの構造 標準的なサービスブループリントは、縦軸に5つのレイヤーを持ち、横軸を時間の流れとして構成されます。 レイヤー1：顧客の行動（Customer Actions） 顧客がサービスを利用する過程で取る行動・意思決定・接触の連続。「予約する→来店する→注文する→受け取る→帰る」のようなステップで表現します。 レイヤー2：フロントステージの行動（Frontstage / Visible Contact Employee Actions） 顧客と直接インタラクションするスタッフの行動。レジ打ち・案内・説明・応対などが該当します。顧客とスタッフの接触点を「接触線（Line of Interaction）」で区切ります。 レイヤー3：バックステージの行動（Backstage / Invisible Contact Employee Actions） 顧客からは見えないが、サービス提供に必要なスタッフの行動。在庫確認・発注処理・品質チェック・書類作成などが該当します。フロントステージとバックステージを「可視線（Line of Visibility）」で区切ります。 レイヤー4：サポートプロセス（Support Processes） フロントステージ・バックステージを支えるITシステム・施設設備・外部委託業務など。バックステージとの境を「内部相互作用線（Line of Internal Interaction）」で区切ります。 レイヤー5：顧客の感情・思考（Physical Evidence / Emotional Journey） 各接触点での顧客の感情状態・思考を付加するオプションレイヤー。顧客体験の質を可視化するために有効です。 実務での使い方 既存サービスの問題発見 現行のサービスプロセスをブループリント化すると、「情報の断絶点」「顧客への影響が見えていないバックステージの遅延」「フロントステージの判断不能ポイント（情報がないと対応できない接触点）」が可視化されます。 ワークショップでよく起こるのは、ブループリントを書いた後「バックステージに情報がいつ届くか分からない」という答えが続出するケースです。これ自体がインサイトです。バックステージの業務担当者とフロントステージの担当者の間で、情報の流れが共有されていないことが可視化される瞬間です。 新サービスの設計 新しいサービスを設計する際、「顧客体験の理想形（カスタマージャーニーマップ）」だけでなく、その体験を実現するための「必要なバックステージプロセス・システム・役割」を同時に設計できます。フロントステージだけを描いた理想のCJMが、実際に実装できない設計になることを防ぎます。 サービスのスケールアップ 小規模で機能していたサービスを拡大する際、どのプロセスを標準化・自動化すべきか、どこに人的判断が必要かを整理する際にもブループリントが有効です。 カスタマージャーニーマップとの違い よく混同されるカスタマージャーニーマップ（CJM）との違いを整理します。 | | サービスブループリント | カスタマージャーニーマップ | |---|---|---| | 主な目的 | サービス設計・オペレーション改善 | 顧客体験の理解・共感の醸成 | | 視点 | 組織（フロント+バック統合） | 顧客視点 | | バックステージ | 含む（核心的要素） | 含まない | | 使うタイミング | 問題定義〜設計 | 共感〜問題定義 | 関連用語 - 接触点（Touchpoint）： 顧客とサービスが接触する場面・媒体・瞬間 - サービスの失敗ポイント（Fail Point）： ブループリント上でエラーが発生しやすい箇所 - 可視線（Line of Visibility）： 顧客から見える部分と見えない部分を分ける境界線 --- 参考文献 - Shostack, G. Lynn, "Designing Services That Deliver", Harvard Business Review, January–February 1984 - Bitner, Mary Jo, Ostrom, Amy L. & Morgan, Felicia N., "Service Blueprinting: A Practical Technique for Service Innovation", California Management Review, Vol. 50, No. 3, 2008 - Stickdorn, Marc et al., This Is Service Design Doing, O'Reilly Media, 2018 --- ### システム思考 URL: https://designthinking.studio/glossary/systems-thinking/ > 複雑な問題を要素の集合としてではなく、相互作用する関係性の網として把握する思考枠組み。Peter Senge、Donella Meadowsらが理論化し、デザイン思考の「問題定義」フェーズと深く接続する。 「原因を突き止めれば問題が解ける」という前提は、単純な系では機能する。しかし現実の多くの問題では、原因と結果が一方向の線でつながっておらず、互いに影響し合いながらループを形成している。システム思考は、この複雑な相互作用の構造を可視化し、問題の全体像を把握するための思考枠組みだ。 理論的背景 システム思考の現代的な基盤を築いたのは、主に2人の研究者だ。 Donella Meadows（1941〜2001）は、環境科学者・著述家として1972年のレポート『成長の限界』を共著し、システム動態の概念を広く知らしめた。彼女が生前から執筆し続けた原稿は、没後の2008年に『Thinking in Systems: A Primer』（邦題『世界はシステムで動く』）としてDiana Wrightの編集により刊行された。ストック（貯量）、フロー（流量）、フィードバックループという3つの基本概念を軸に、複雑系の振る舞いを平易に説明したこの本は、システム思考の入門書として今なお広く読まれている。 Peter Sengeは、MITスローン経営大学院のシニアレクチャラーとして、1990年に『The Fifth Discipline』（邦題『学習する組織』）を刊行した。システム思考を「第5の鍛錬」として位置づけ、組織の学習能力との接続を論じたこの著作は、経営・組織開発の文脈でシステム思考を普及させる起点となった。Sengeの定義によれば、システム思考とは「ものを見るための枠組み——相互関係を見る、静的なスナップショットではなく変化のパターンを見るための枠組み」だ。 3つの基本概念 Meadowsが整理したシステム思考の語彙は、どの文脈にも応用できる。 ストック（Stock）: 系の中に蓄積されるものの量。水槽の水量、組織内の知識量、顧客の信頼度——いずれもストックだ。ストックは変化に対してバッファとして機能し、急激な変化を緩衝する。 フロー（Flow）: ストックを増やす流入と、減らす流出の速度。採用（流入）と離職（流出）は、人材というストックを変化させるフローだ。フローを変えることで、ストックの軌跡が変わる。 フィードバックループ: 系の出力が再び系への入力となる循環構造。正のフィードバックループは変化を加速させ（口コミによる成長、負債の利子の増大）、負のフィードバックループは変化を安定させる（体温調節、市場価格の均衡）。 多くの複雑な問題は、複数のフィードバックループが絡み合った結果として生じる。「売れたから作る、作りすぎたら値下げする、値下げで需要が戻る」という在庫・価格の動態は、複数ループの相互作用の典型だ。 デザイン思考との接続 デザイン思考の「問題定義（Define）」フェーズとシステム思考は、深い親和性を持つ。 ダブルダイヤモンドの第1フェーズ（Discover）で収集されたユーザー観察データは、しばしば「個別の困りごと」として記述される。しかしそれをカスタマージャーニーマップやアフィニティダイアグラムで整理したとき、複数のタッチポイントにまたがる構造的なパターンが浮かび上がる場合がある。システム思考は、この「パターンの背後にある構造」を明示するための道具として機能する。 たとえば医療現場の「患者待ち時間の長さ」という問題を考えてみる。単純なアプローチでは「予約システムを改善する」という解決策に飛びつく。しかしシステム思考で問題を構造化すると、予約数・医師稼働時間・診察時間の変動・再診患者の割合・スタッフのコミュニケーションフローといった複数の要因が相互に作用していることが見えてくる。予約システムだけを変えると、別の場所でボトルネックが生じる可能性がある。 活用の実際 システム思考を実践に組み込む最も初歩的な問いは「これはループしていないか」だ。目の前の問題が「AがBを引き起こす」という線形因果ではなく「AがBを引き起こし、BがCを経てAに影響する」という循環を持っていないかを問う。 ループを発見したとき、次に問うのは「ループを強化しているドライバーは何か」「ループを安定させている要素は何か」だ。この問いに答えることで、介入点（レバレッジポイント）の候補が見えてくる。Meadowsは著書の中で「バタフライ効果的な表面介入より、系の構造そのものに働きかける介入の方が変化を持続させる」と論じた。この知見は、デザイン思考が「症状への対処」ではなく「本質的な問いを立てる」ことを重視する姿勢と重なる。 限界 システム思考は問題の全体像を描くことに優れているが、実装のための具体的な手順は提供しない。問題の構造を把握したあと、どのプロトタイプを先に試すかはデザイン思考のイテレーションが担う。また、複雑な系を図解しようとすると、図そのものが複雑になりすぎてチームの共通理解を阻む場合がある。システム図の複雑さをどこで切り取るかは、経験に基づいた判断が求められる。 --- ### システム思考とデザイン思考の統合 URL: https://designthinking.studio/glossary/systems-thinking-integration/ > 複雑な問題に対処するため、システム思考とデザイン思考を組み合わせる概念的・実践的な枠組み。Peter Senge のシステム思考と d.school のデザイン思考を接続する。 システム思考とデザイン思考の統合（Systems Thinking × Design Thinking Integration） とは、人間中心の問題解決アプローチであるデザイン思考と、要素間の相互作用・フィードバックループを俯瞰するシステム思考を組み合わせ、複雑適応系の問題に対処するための思考・実践フレームワークを指す。 2つの思考法の位置づけ デザイン思考（d.school の5フェーズモデルに代表される）は、ユーザーの体験・感情・文脈に深く共感し、具体的な解決策を素早く試す人間中心のアプローチだ。個人の体験を深く掘り下げる点で優れているが、組織や社会の構造的な力学を俯瞰する視野は限られている。 システム思考は、Peter Senge が The Fifth Discipline（1990）で体系化した概念であり、問題を「要素の集まり」ではなく「相互作用するシステム」として捉える。Donella Meadows が Thinking in Systems（2008）で示した因果ループ図（Causal Loop Diagram）やストック・フロー図は、問題が再発する構造的な理由を可視化するツールだ。 両者は補完関係にある。デザイン思考が「誰のどの体験が問題か」を明らかにし、システム思考が「なぜその問題が繰り返し起きるか」の構造を明らかにする。 統合が必要になる場面 次のような状況で、デザイン思考単体の限界が露呈し、統合アプローチの必要性が生まれる。 - 施策を打っても問題が再発する — フィードバックループが原因になっている可能性が高い - ステークホルダーが多く、利害が相反する — 個人の共感だけでは全体の構造が見えない - 短期的解決策が長期的な悪化を招く — システム思考でいう「症状への対処」パターンに陥っている 統合の実践的な接続方法 因果ループ図 × エンパシーマップ ユーザーインタビューから得たエンパシーマップを入力として使い、ユーザーの行動パターンが引き起こすフィードバックループを因果ループ図で可視化する。個人の体験データを、構造分析の出発点として機能させる接続手法だ。 レバレッジポイントの特定 → HMWの設定 システム思考で「最も変化が起きやすい介入点（レバレッジポイント）」を特定してから、その点に向けたHow Might Weの問いを設計する。これにより、局所的な体験改善ではなく、構造変化を促す解決策の方向を探れるようになる。 なぜ重要か デザイン思考の5フェーズモデルは、明確な問題や人間的な文脈が存在するケースで強力に機能する。しかし現代のビジネス課題——サステナビリティ、組織変革、社会的課題——は「複雑適応系」の性質を持ち、単純な原因→結果の連鎖では捉えられない。 システム思考との統合は、デザイン思考が「人間の体験を深く見る顕微鏡」として機能しながら、同時に「システム全体を見渡す望遠鏡」を持てるようにする試みだ。この統合は現在も理論的・実践的な探求が続く発展途上の領域である。 --- 参考文献 - Peter Senge, The Fifth Discipline: The Art and Practice of the Learning Organization, Doubleday, 1990 - Donella Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008 --- ### スペキュラティブデザイン（Speculative Design） URL: https://designthinking.studio/glossary/speculative-design/ > 「もしも〜だったら」という問いを起点に、起こりうる未来のシナリオをデザインによって可視化・批評する手法。Anthony DunneとFiona Rabyが1990年代にRoyal College of Artで定式化した。現在の意思決定や社会的価値観を問い直す批判的実践として、デザイン思考・未来研究・アート領域で広く参照される。 スペキュラティブデザインは、デザインを「問題解決の道具」ではなく「問いを生み出す媒体」として捉える実践です。 通常のデザインプロセスが「現在の課題を解く」ことを目的とするのに対し、スペキュラティブデザインは「現在の選択が招く未来を可視化し、その選択の是非を問う」ことを目的とします。 --- 概念の起源 スペキュラティブデザインという語を定式化したのは、英国のデザイナー・研究者であるAnthony DunneとFiona Rabyです。二人は1990年代、Royal College of Art（ロンドン）での研究・教育活動の中で、この概念を体系化しました。 代表的著作は『Speculative Everything: Design, Fiction, and Social Dreaming』（The MIT Press、2013年）。この書籍の中でDunneとRabyは、デザインが「現実に何が存在するか」だけでなく「何が存在しうるか・存在すべきでないか」を探る実践になりうることを論じています。 二人が提示した概念的枠組みが「現実と空想の連続体（the reality/fiction spectrum）」です。最左端を「現実に存在するもの（probable）」、右端を「幻想的なもの（fantasy）」とすると、スペキュラティブデザインはその中間に位置する「可能なもの（possible）」と「好ましいもの（preferable）」の間を探索します。 --- デザイン思考との関係 スペキュラティブデザインとデザイン思考は、出発点が異なります。 デザイン思考は「現在のユーザーの課題を解くための共感・定義・創造・プロトタイプ・テストのサイクル」を主軸とします。スペキュラティブデザインは「まだ存在しない状況についての問いを立て、それを対話の素材として提示する」ことを主軸とします。 しかし実践の場では、両者は補完的な関係にあります。とくに以下の3点で、スペキュラティブデザインはデザイン思考を深化させます。 - 問題空間の拡張：デザイン思考の定義フェーズで「現在の問題」だけでなく「この問題を放置した場合の10年後」を問うとき、スペキュラティブデザインの思考枠組みが機能します。 - ステークホルダーとの対話：未来シナリオのプロトタイプは、ユーザーインタビューでは出てこない深い価値観・恐れ・期待を引き出す素材になります。 - 制約を超えた発想：「現在の技術・コスト・規制の枠内で考える」という暗黙の前提を外すことで、本質的な解決策の方向を見つけやすくなります。 --- 実践の典型例 スペキュラティブデザインの実践は、以下のような形をとります。 「未来の新聞」を作る：5年後・10年後の社会を前提とした架空の新聞・ニュースサイトをデザインする。「AIが法的主体となった世界での雇用問題」「海面上昇後の都市設計」など。これをステークホルダーに見せることで、彼らが望む・望まない未来のシナリオを明確化します。 批判的プロダクトの設計：存在しない製品を詳細にデザインすることで、その製品が存在する世界に内在する価値観・権力関係・倫理的問題を可視化します。DunneとRabyによる「Technological Dreams Series: No. 1, Robots」（2007年）は、ロボットと人間の依存関係の諸形態を4つのプロダクトコンセプトで批評的に示した代表作です。 シナリオプランニングとの統合：組織・企業の長期戦略立案に使われるシナリオプランニングにスペキュラティブデザインの手法を組み合わせると、抽象的なシナリオを具体的な体験として可視化できます。シェルやヴォルクスワーゲンなど大企業の戦略部門が応用している手法です。 --- デザイン思考実践における活用の注意点 スペキュラティブデザインは、以下の場面では慎重な適用が必要です。 短期的解決策が必要な場面との混在を避けること。「次のスプリントで改修するUI」の議論に長期未来シナリオを持ち込むと、チームの集中が分散します。 「未来予測」と混同しないこと。スペキュラティブデザインはリスク分析や予測ではなく、「問いを立てる」ための媒体です。「この未来が来る」と主張するものではありません。 参加者の文脈に合わせること。抽象度の高いシナリオは、具体的な現場課題に向き合う実務家にとって遠くに感じられることがあります。導入は「現在すでに起きていること」の延長線から始めると接続しやすくなります。 --- 関連概念 - デザインフィクション（Design Fiction）：スペキュラティブデザインと重なる概念。特に映画・小説・ゲームなどフィクションのメディアを使って未来技術の社会的影響を描く実践を指す。Bruce Sterling（SFコンサルタント）がデザイン領域で広めた。 - 批判的デザイン（Critical Design）：DunneとRabyが用いた初期の用語。現在の社会・文化・技術への批評的まなざしを持つデザイン実践を指す。スペキュラティブデザインよりも批評性を強調するニュアンスがある。 - アンシペイタリーデザイン（Anticipatory Design）：ユーザーが必要とするものを先取りしてデザインする手法。スペキュラティブデザインとは目的が異なるが、未来への視点を共有する。 --- 主要文献 - Dunne, A., & Raby, F. (2013). Speculative Everything: Design, Fiction, and Social Dreaming. The MIT Press. - Dunne, A. (2005). Hertzian Tales: Electronic Products, Aesthetic Experience, and Critical Design. The MIT Press. - Sterling, B. (2009). "Design Fiction." Interactions, 16(3), 20–24. --- ### センスメイキング・デザインリサーチ URL: https://designthinking.studio/glossary/sense-making-design-research/ > 複雑で不確実な問題状況の中から、意味のある構造を見いだすプロセス。デザイン思考のリサーチ段階では、単にユーザーデータを集めるのではなく、そのデータの背後にある「意味」を解釈し、問題の本質へと到達することが求められる。センスメイキングは、その意味構築のプロセスを指す。 定義 センスメイキング（Sense-making）とは、ユーザーインタビュー、観察、行動ログなどから集められた生のデータを、単なる「事実の記録」ではなく、「意味のある構造」へと変換するプロセスである。 デザイン思考では、この意味構築のプロセスが、問題定義からアイデア創造へ至る思考の転換点となる。 なぜデザインリサーチにおいて重要なのか 従来のマーケットリサーチとの違い 従来のマーケットリサーチでは、アンケート調査により「どの商品の購買意向が高いか」「顧客満足度はいくつか」という定量的なデータが取得される。その数値が、そのまま経営判断の根拠になる。 一方、デザインリサーチにおけるセンスメイキングは、数値ではなく、ユーザーの行動や発言の背後にある、暗黙的なニーズや価値観を読み取ることに焦点を当てる。 例えば、アンケートで「スマートフォンの操作が難しい」と回答したシニア層は多い。しかし、その「難しさ」の本質は何か? - 画面のテキストが小さくて見えない? - 操作手順が複雑で覚えられない? - 機械は壊す不安がある? - 周囲に詳しい人がいて頼りにくい? センスメイキング的なリサーチでは、複数のシニア層にスマートフォンを実際に操作してもらい、その行動（ここで迷う、ここで確認を求める）と発言（「親世代は新しいものに不安がある」という思い込み）から、「実は難しさではなく、自分が新しいものについていけない罪悪感が根底にある」という、より深い課題を発見することになる。 その発見がなければ、アプリ企業は「大きな文字のインターフェース」を設計して満足するだろう。しかし、実際には「シニア層がスマートフォンを安心して学べる学習機会」が、本当のニーズなのだ。 複雑な問題領域での必要性 デザイン思考の対象となる問題は、ほとんどが「複雑で、因果関係が不明確」だ。 単純な商品改善（「ペットボトルの蓋が開けづらい」→「蓋の形状を改善する」）であれば、ユーザーの訴えをそのまま受け取れば良い。 しかし、組織の課題（「若手社員が育たない」「顧客とのコミュニケーションが断絶している」）となると、表面的な訴えの背後には、複数の要因が絡み合っている。 センスメイキングは、その複雑さの中から、「本当に解決すべき問題は何か」という構造を見いだす営みなのだ。 デザインリサーチの現場では何が起きているか ステップ 1：データ収集（リサーチ） インタビュー、観察、ユーザーテストなどを通じて、以下のようなデータが集まる。 - ユーザーの直接的な発言（「この機能があったら便利」） - ユーザーの行動や身振り（迷う、躊躇する、工夫する） - 環境や文脈の詳細（時間帯、同席者、使用する場所） - ユーザー自身も気付いていない矛盾（「このアプリは好きじゃない」と言いながら毎日使っている） ステップ 2：データの整理と分類 集めたデータを、テーマや共通パターンで分類していく。 例えば、シニア層への10回のインタビューから、以下のようなパターンが浮かび上がるかもしれない。 - 「技術が理解できない」という訴えが表面的な理由 - より深掘りすると、「新しいものについていけない自分」への否定感が根底にある - ただし、実際にはシニア層の一部は、スマートフォンを上手に使っている - その上手く使っている人たちの特徴は何か? —— 「家族が教えてくれた環境」「同年代の友人に勧められた」という、信頼できる人からの学習経験 ステップ 3：意味の解釈と構造化 分類されたデータから、ユーザーの行動や心理に一貫した意味を見いだす。 上記の例では、以下のような解釈が生まれるかもしれない。 「『技術的な難しさ』ではなく、『信頼できる人からの学習機会の不足』が、シニア層のスマートフォン活用を阻害している。逆に言えば、適切な学習環境が整備されれば、シニア層の利用拡大は十分に可能」 この解釈が、次のステップとしてのアイデア創造（「親世代のためのスマートフォン教室」など）につながっていく。 よくあるセンスメイキングの失敗パターン 失敗パターン 1：「ユーザーの発言をそのまま信じてしまう」 ユーザー自身も、自分のニーズを正確に言葉にできるとは限らない。 「使いづらい」という発言は、実は「使い方が分からない不安」かもしれないし、「周囲に知られたくない恥ずかしさ」かもしれない。 デザインリサーチでは、発言の背後にある本当の感情や動機を読み取ることが重要。 失敗パターン 2：「自分たちの仮説を確認するためのリサーチ」 これは、センスメイキングではなく「確認バイアス」に陥った状態。 「シニア層はテクノロジーに弱い」という既存の仮説を持ったまま、リサーチに入ると、その仮説を支持するデータだけが目に入り、矛盾するデータは無視される傾向がある。 良いセンスメイキングは、最初に仮説を持たず、データの中から新しい洞察が生まれるまで、開かれた姿勢を保つことが重要。 失敗パターン 3：「解釈の過度な抽象化」 一方、リサーチから得た洞察を、あまりに抽象的に一般化してしまう失敗もある。 「シニア層は信頼できる人からの学習を望んでいる」という洞察は正しいかもしれないが、それがどのセグメントのシニアにどの程度当てはまるのか、という検証なしに進むと、実装時に齟齬が生じる。 --- デザイン思考における位置づけ 共感（Empathize）フェーズ センスメイキングは、共感フェーズの締めくくりとして機能する。 単なるデータ収集で終わるのではなく、「ユーザーの真の課題は何か」を言語化するステップが、デザイン思考の次のフェーズ（問題定義）へ進むための準備となる。 問題定義（Define）フェーズ 共感フェーズで行われたセンスメイキングから、「How Might We」という問い（「どうすれば、ユーザーのこの課題を解決できるか?」）が生まれる。 この問い自体の質が、その後のアイデア創造の質を決める。 --- やってみよう：簡単なセンスメイキングのワークショップ チーム内で以下の簡単な実験をしてみよう。 ステップ 1：素材の準備 自社の顧客や利用者へのインタビュー記録（動画や音声）を、最低3件以上用意する。 ステップ 2：個人での視聴・メモ 各自が動画を視聴し、以下の観点でメモを取る。 - ユーザーが直接述べている課題は何か? - 発言と矛盾する行動や身振りがないか? - ユーザーが無意識に言及している（本人も気付いていない可能性がある）課題や価値観は? ステップ 3：チームでのディスカッション 複数の人がメモを持ち寄り、「このユーザー、実は何を課題に感じてるんだろう?」という対話を進める。 その過程で、個人での視聴では見落とした洞察が浮かび上がってくることが多い。 ステップ 4：解釈の言語化 最後に、「このユーザーグループの本当の課題は、◯◯ではなく、△△なのではないか」という仮説を、チーム全体で言語化する。 その仮説が、次のプロトタイピングやアイデア創造へつながる。 --- 関連する手法 - エスノグラフィ — ユーザーを自然な環境で観察し、詳細な記述を通じて意味を抽出する研究手法 - グラウンデッド・セオリー — データから帰納的に理論を構築する定性的研究方法。センスメイキングの理論的基盤の一つ - ペルソナ開発 — センスメイキングの結果を、架空の人物像として具体化するプロセス - ユーザージャーニーマップ — ユーザーの時系列での行動と感情を可視化する手法 --- 最後に センスメイキングは、デザイン思考の現場では最も地道で、かつ最も重要なプロセスである。 ユーザーとの対話の中から、一見すると矛盾や曖昧さを含む生のデータを、説得力のある問題定義へと翻訳するその営みは、純粋に知的で、創造的だ。 「ユーザー中心のデザイン」が標語になっている今、その標語を本当の意味で実現するには、センスメイキングの質が全てを決める。 --- ### ダブルダイヤモンド（Double Diamond） URL: https://designthinking.studio/glossary/double-diamond/ > 英国Design Councilが2004年に提唱した、発散と収束を2回繰り返すデザインプロセスモデル。 ダブルダイヤモンド（Double Diamond）は、英国のDesign Councilが2004年に発表したデザインプロセスモデルです。 プロセスを4つのフェーズに分割します。 - Discover（発見） — 課題領域を広く探索する（発散） - Define（定義） — 解くべき問題を絞り込む（収束） - Develop（開発） — 解決策を幅広く検討する（発散） - Deliver（提供） — 最適な解決策を選び、実装する（収束） 「発散→収束→発散→収束」の2つのダイヤモンド形状から名前がつきました。d.schoolの5フェーズモデルと並んで、デザインプロセスを説明する際に広く引用されるフレームワークです。詳しくはダブルダイヤモンドの解説記事を参照してください。 --- 参考文献 - Design Council, "Eleven Lessons: Managing Design in Eleven Global Brands", designcouncil.org.uk, 2007 --- ### デザインスプリント（Design Sprint） URL: https://designthinking.studio/glossary/design-sprint/ > GoogleベンチャーズのJake Knapp が考案した5日間の構造化問題解決プロセス。月単位の開発サイクルを5日間に圧縮し、プロトタイプとユーザーテストを通じて「作る前に検証する」ことを可能にするフレームワーク。 デザインスプリント（Design Sprint）は、Googleベンチャーズ（現GV）のデザインパートナーJake Knappが考案し、2016年の著書『Sprint』で体系化した5日間の構造化問題解決フレームワークです。Slack、Airbnb、Lego など世界200社以上で採用されており、スタートアップから大企業まで幅広く活用されています。 デザイン思考の5フェーズ（共感→定義→創造→プロトタイプ→テスト）を5日間という時間制約の中に凝縮し、「作ってから検証する」を「検証してから作る」に変える逆転の発想が特徴です。 --- なぜデザインスプリントが重要か 「早すぎる正解」を防ぐ 製品開発の多くの失敗は、「解を決めてから、その解を精緻化する」というプロセスにある。アイデアを思いついた段階で正解だと確信し、数ヶ月かけて開発し、リリース後にユーザーが使わないことを発見する。 デザインスプリントは、この失敗パターンを構造的に防ぐ。5日間で「仮説的な解」をプロトタイプとして形にし、実際のユーザーに見せて反応を確認する。開発に数ヶ月かける前に「この解が正しいか」を5日間で検証できる。 意思決定の「民主化」と「スピード化」の両立 ワークショップでよく起こるのは、長い会議の末に「もう少し検討してから決める」という決断未了のループだ。デザインスプリントには、このループを断ち切る仕組みが内蔵されている。 「デサイダー（Decider）」と呼ばれる意思決定者を1名設定し、その人が最終判断を行う構造だ。全員の意見を聞きながらも、決定を誰かに委ねることでスピードを確保する。民主的な探索と、独裁的な決断を組み合わせた設計がスプリントの強みの一つだ。 --- デザインスプリントの5日間構造 月曜日：マップ（Map） スプリントの最初の日は、問題の全体像を「マップ」として視覚化することに費やします。チームは「長期目標（Long-term Goal）」を設定し、「スプリント・クエスチョン（Sprint Questions）」を定義します。スプリント・クエスチョンは、今週の5日間で答えるべき問いです。 次に、ユーザーの行動を追った「マップ」をホワイトボードに描きます。ユーザーが最初にサービスと接触する場面から、最終的に目標を達成（または失敗）するまでの流れを5〜15ステップで描きます。 月曜日の最も重要な活動は「HMW（How Might We）メモ」です。チームメンバーが独立して、課題に対して「どうすれば〜できるだろう？」という問いを付箋に書き出し、投票で優先度の高い問いを選出します。 火曜日：スケッチ（Sketch） 火曜日は、解決策のスケッチを「個人作業」で行います。既存のソリューション事例を調査した後、各自が個別に解決策のアイデアを視覚化します。 「ライトニングデモ（Lightning Demos）」 という手法では、チームメンバーそれぞれが「参考になる製品・サービス」を3分で紹介し、チームのインスピレーションを広げます。 その後、全員が「4コマ漫画」形式でソリューションのフローをスケッチします。このスケッチは匿名で壁に貼り出され、グループではなく個人で作ることが重要です。集団思考のバイアスを避け、多様な解のスケッチが生まれるよう設計されています。 水曜日：デサイド（Decide） 火曜日に生まれた複数のスケッチから、1つの解決策を選ぶ日です。Jake Knapp が考案した「スティッキー決定（Sticky Decision）」という投票プロセスを使い、議論ではなく投票でアイデアを選択します。 最終的にデサイダーが1つの解決策を決定し、木曜日に作るプロトタイプの「ストーリーボード（Storyboard）」を描きます。ストーリーボードは15コマ前後の絵コンテで、ユーザーがプロトタイプを体験する流れを視覚化したものです。 実際にやってみると、この日が最も議論が白熱し、時間管理が難しいことがわかります。タイムボックス（時間制約）を厳格に守るファシリテーターの存在が、スプリント成功の鍵になります。 木曜日：プロトタイプ（Prototype） 水曜日に作ったストーリーボードをもとに、1日でプロトタイプを作ります。ここでのプロトタイプは完成品ではなく「フェイク（Fake）」で構いません。目的は「ユーザーが反応できる程度のリアリティ」を作ることです。 Keynote、PowerPoint、Figma などのツールを使ったクリッカブルなモックアップが一般的です。物理的な製品であれば段ボール、アナログのサービスであれば「ウィザード・オブ・オズ」プロトタイプ（人間がシステムの代わりを演じる）が使われます。 1日でプロトタイプを完成させるための原則は「完璧主義の放棄」です。表面が荒くても、ユーザーが「何かを体験できる」レベルであれば十分です。プロトタイプの目的は「作ること」ではなく「木曜日の答えを得ること」です。 金曜日：テスト（Test） 5人のユーザーを招いてプロトタイプをテストします。1対1のインタビュー形式で、ユーザーがプロトタイプを操作する様子を観察します。インタビューはチームの一人が行い、残りのメンバーは別室でライブストリームを見ながらメモを取ります。 5人のユーザーでテストする根拠は、ニールセンノーマングループの研究にある。 ユーザビリティテストにおいて、5人のテストで全体の約85%の問題が発見できるとされています。それ以上のサンプルを増やしても発見の限界効用が急減するため、5人が費用対効果の最適解です。 金曜日の午後には、チームで結果を分析し、「パターン（Pattern）」を見つけます。「3人以上のユーザーが同じ反応をした」ことが重要な発見です。 --- デザインスプリントと他のフレームワークとの違い デザイン思考との関係 デザインスプリントはデザイン思考の「実装形態」の一つです。デザイン思考が「5フェーズのプロセス哲学」であるなら、デザインスプリントは「そのプロセスを5日間で実行するための厳密なプロトコル」です。 両者の最大の違いは時間制約の厳格さです。デザイン思考はフェーズの長さを状況に応じて柔軟に設計しますが、デザインスプリントは曜日と時間を厳格に管理します。この「プロセスの厳格さ」が、スプリントの強みであり制約でもあります。デザイン思考の詳細はデザイン思考を参照してください。 スクラムとの違い スクラムは「継続的な開発サイクル（スプリント）」を管理するフレームワークで、主に「どう作るか（How to build）」のプロセスを最適化します。デザインスプリントは「何を作るか（What to build）」を検証するためのフレームワークです。 2つは対立するものではなく、相補的に使われます。 デザインスプリントで「作る価値があるか」を検証した後、スクラムで「それを継続的に作り込む」というシーケンスが一般的な活用パターンです。 --- デザインスプリントの限界と注意点 全ての問題に適さない デザインスプリントが最も効果を発揮するのは、「ユーザーとのインタフェース（UX/UI、サービス設計）」の検証です。一方、「組織変革」「長期戦略」「複雑なシステムアーキテクチャ」のような問題には適していません。 ワークショップでよく起こる失敗は、スプリントを「万能の問題解決フレームワーク」として扱うことです。問題の性質を見極め、スプリントが適した問題か否かを判断することが前提として必要です。 1週間後の「その後」が鍵 参加者からの声として多いのは「スプリントは最高だったが、月曜日から通常業務に戻った瞬間に全て忘れた」というものです。スプリントで得た発見をプロダクトやサービスに反映する「実装フェーズ」の設計なしに、スプリントは「高価なワークショップ」に終わります。 スプリント後のアクションプランと責任者の設定が、スプリントの価値を実務に接続する最重要要素です。 --- 実務での活用ポイント デザインスプリントをはじめて導入する組織では、5日間フルのスプリントではなく「ショートスプリント（1〜2日）」から始めることが推奨されます。 フルスプリントは5人程度の参加者が丸1週間を拘束されるため、組織的なコミットメントが必要です。 まず1日でプロトタイプを作ってユーザーテストを行う「ミニスプリント」を試し、手法の有効性を実感してから、フルスプリントへとスケールアップするアプローチが現実的です。スモールスタートで体験を積んでから投資を拡大する、この順序が定着率を高める。 Googleのデザインスプリントが実際の組織でどのように機能するかは、Google流デザインスプリントの実践事例で詳しく解説しています。スプリント内で用いるプロトタイプ手法の詳細はプロトタイピング手法を参照してください。 --- 参考文献 - Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster. - Nielsen, J., & Landauer, T. K. (1993). "A mathematical model of the finding of usability problems." Proceedings of ACM INTERCHI, 206–213. - GV Library, "The Design Sprint," https://www.gv.com/sprint/ --- ### デザインスプリント再考（2026版）──5日間から『反復スプリント』へ URL: https://designthinking.studio/glossary/design-sprint-modern-iteration/ > Google Ventures が提唱した『5日間でプロトから検証まで』というデザインスプリント。しかし実務は違う。リモート化、AI活用、短サイクルのニーズから、『1週間で『3ラウンド』のミニスプリント』という新形式が生まれている。その設計思想と運用のコツを解き明かします。 デザインスプリントは、Google Ventures（GV）が 2010 年代に提唱した、「5日間で課題定義からプロトタイプ検証まで一気に進める」 という方法論です。 月曜に問題を定義し、金曜にユーザーテストまで終わらせる。この「スピード感」は、当時のスタートアップ界隈では革新的でした。 しかし、2026 年の今、私はこのプロセスに対して、「5日間の単発スプリントより、1週間で『3ラウンドのミニスプリント』が現場に合う」 という確信を持っています。 GV式スプリントの限界 まず、従来の GV 式スプリントをおさらいします。 この流れの問題点： - 月曜の「課題定義」が浅い。 前提としてペルソナやジャーニーが決まっていることが暗黙の了解。empathize フェーズが不足。 - 火曜の「投票」が、多数決に偏りやすい。 定性的な議論より「手挙げ」で決まり、本当の創造的判断が入らない。 - 水曜の prototype は「見た目」重視。 相互作用や実装面での現実的な制約が見えない。 - 金曜のテストで「失敗」が決まったら？ そこから改善って、次週になってしまう。スプリントが終わったら終わり、という雰囲気になりやすい。 2026 年の現場が求める形 過去 2 年で、私が複数企業で試行した「1 週間 3 ラウンドミニスプリント」の枠組みがあります。 この形の特徴： - 「ラウンド」という概念を導入。 1 つのスプリントが「単発」ではなく「反復的」になる。 - テスト → 改善 → テストが、1 週間内に 2-3 回転する。 スプリント内での学習が深い。 - 金曜は「終わり」ではなく「次への開始地点」。 Next Sprint への引き継ぎ資料を作成。 - リモート対応。 全員が毎日 Zoom で繋がり、非同期タスク（プロト制作）と同期タスク（投票・議論）を明確に分ける。 実践例：某 EdTech 企業の「学習進捗可視化機能」スプリント 昨年 11 月、あるオンライン教育企業が「生徒が自分の学習進捗を『ゲーム的に見える化する』機能」を 1 週間で定義・プロト・テストしたケースです。参加者はプロダクト PM、エンジニア、デザイナー、教育企画者の 4 名。 月曜 AM：empathize + define 最初に「実際の生徒の学習行動」に関するデータを 15 分間で確認。 - 小学 3 年生の男子は「短期的な達成感」に駆動される - 中学生の女子は「同級生との比較」を気にする（が表には出さない） - 母親は「子どもの学習時間」より「理解度」を知りたい この 3 つのペルソナに対して、隠れたニーズを洞察。 「子どもは『見える化』されることで『サボってるのがバレる』という不安。でも『目に見える成長』があれば、モチベーションに変わる。大人（親）と子どもで、求める『見える化の粒度』が違う。」 この気づきが、その後の全ラウンドを支配しました。 月曜 PM：ideate ラウンド 1（Crazy 8s） A4 紙を 8 分割し、各自 8 分間で 8 案を描く（企業によって「ゲーム的ダッシュボード」「RPG 的レベルゲージ」「SNS 的チャレンジ表示」など、全く違う発想）。 その後、皆で 20 案を壁に貼り、sticky notes で「これ面白い」「これ実装できそう」「これ子どもが喜びそう」と 3 軸で投票。 従来の GV スプリントなら「どれが一番いい？」と単純投票します。ここは違う。「複数軸での評価」で、複数の有望案を複合させるアイデアが出やすくなる。 火曜 AM：投票 + 定性議論 3 案に絞ったら、各案に対して「なぜ、これを選んだのか」を担当者が 3 分で説明。その後、PM から「実装リスク高くない？」「生徒が『ゲーム的じゃなくて勉強っぽい』と感じたら逆効果では？」といった異議が出る。 議論の中で「案 B と案 C を融合させたら？」という新しい案が現れ、それが採用されました。 単純投票では、こういった「融合案」は出にくい。 複数案の議論を経て初めて、「本当に実現したいカタチ」が浮かび上がります。 火曜 PM：ラウンド 2 Prototype（Figma + ペーパー） 決まった案を、デザイナーが Figma でモックアップ。同時に教育企画者がペーパープロトタイプ（印刷物に手書きで追加）を制作。2 つの parallel プロト。 水曜：テスト ラウンド 1 プロダクト企業の本社に「実際のユーザー」（生徒 2 名 + 母親 1 名）を招待。Figma プロトを見せ、タスク実施してもらう。 「君の学習進捗が今、ここまで来ていることをどう思う？」 生徒の反応：「あ、レベル上がった。もうちょっと頑張ったら次のステージだ」（ゲーム的動機が発火） 母親の反応：「この『理解度 72%』は、どうやって計測されてるの？」（信頼性への疑問） この 2 つの異なる反応が、ラウンド 3 へのインプット。 木曜 AM：ラウンド 3 ideate テスト結果を踏まえ、小 1 時間の ideate。 母親の「理解度の算定ロジック」への疑問に対して、「問題ごとの正答率 + 解答時間 + 復習頻度」を表示する改善案が出ました。これは月曜の ideate では誰も思いつかなかった。 テスト → 改善のサイクルが、新しい創造を生んだ。 木曜 PM：ラウンド 3 Prototype Figma で改善版を実装。金曜のテストに備える。 金曜：最終テスト + Next Sprint への引き継ぎ 別の生徒 2 名 + 母親 1 名でテスト。前回より反応が良好。しかし「実装の複雑さ」が見えてきたため、Friday の夜に「Phase 2 スプリント」の課題を定義し、Monday に引き継ぎ。 1 週間で『3 ラウンド』のテスト → 改善を回し、次のスプリントに接続させた。 なぜ「反復スプリント」が有効か 従来の GV スプリントは「1 週間で 1 つの仮説を検証」する形でした。 しかし、複雑な問題では「仮説 A が検証されたとしても、実装には新しい課題が出てくる」が常です。 新形式の「反復スプリント」なら、その課題を スプリント内で複数ラウンド対応できる。 結果として「1 週間後には、より精度の高いプロトタイプと、次フェーズへの明確な課題が揃っている」状態に到達します。 また、リモート前提で設計 されているため： - 全員が毎日の進捗を見える化（Figma のコメント機能、Slack での共有） - 非同期で proto を作っている間、管理者がテスト対象者の日程調整 - 「待つ時間」が最小化される 実施のポイント - Monday AM の empathize を絶対に省かない。 前提が違うと、全てのラウンドがズレる。 - 各ラウンド間で「定量 + 定性」の両軸でのフィードバック。 投票だけでなく、「なぜ良かったのか」を言語化する。 - テスト対象者を「毎ラウンド同じ人」に。 変わるたびに context が失われる。 - 金曜は「終了」ではなく「次スプリントの開始」 として、課題リストと仮説を明記。 2026 年のデザイン思考にとって GV スプリントは、確かに革新的でした。ですが、15 年経った今、実務は進化しています。 リモート環境、AI による高速プロトタイピング、ユーザーニーズの複雑化。 これらに対応するには、「5 日間で全て終わらせる」単発思考より、『1 週間で複数ラウンド反復する』柔軟性 が必要です。 一度試してみると、「テスト → 改善 → テスト」の反復が、想像以上に創造の質を高めていることに気づくでしょう。 --- カテゴリ: tools（ツール・手法） 参考: - Google Design Sprint（公式サイト） - prototype フェーズの本質 - test フェーズで学ぶべきこと 更新情報: 2026-05-25：リモート対応 + 反復スプリント形式を中心に再構成。GV 式との比較を整理。 --- ### デザインブリーフ URL: https://designthinking.studio/glossary/design-brief/ > デザインプロジェクトの目標・制約・対象ユーザー・成功基準を一枚に整理した設計文書。プロジェクト開始時にチーム全員の認識を揃えるためのアンカードキュメント。 デザインブリーフ（Design Brief）とは、 デザインプロジェクトが解決しようとする問題・目標ユーザー・制約条件・成功基準・スコープを一枚の文書に整理したもの です。チームメンバー全員とステークホルダーの認識を揃えるためのアンカードキュメントとして機能します。 デザインブリーフの役割 デザイン思考のプロセスでは、共感フェーズでのリサーチを経て問題定義フェーズで問いを立てた後、その問いを「何のために・誰のために・何を作るか」へと接続する段階でデザインブリーフが機能します。 デザインブリーフがなければ、チームは「成功」の定義を共有していないまま作業を進めます。3ヶ月後に「これは自分たちが解こうとしていた問題への答えだったか？」という問いに答えられない——このケースはワークショップ観察でも繰り返し確認されるパターンです。デザインブリーフは 「どこに向かっているか」という問いへの答え を全員で共有するものです。 デザインブリーフに含む要素 優れたデザインブリーフには以下の要素が含まれます。 問題ステートメント：「私たちは〇〇の課題を解決しようとしている」を一文で。HMW（How Might We）フォーマットで書くことが多いです。 対象ユーザー：誰のためのデザインか。ペルソナや実際のリサーチ対象者の属性・文脈・ニーズを要約します。 成功基準：「このデザインが成功したと判断できる状態はどんな状態か」を具体的に。定量指標（完了率・満足度スコア）と定性指標（ユーザーが何と言うか）の両方を含めます。 制約条件：予算・時間・技術・法律・組織的な制約を明示します。制約の明示は「なぜこのアイデアは難しいのか」という議論の繰り返しを防ぎます。 スコープ外：「このプロジェクトでは扱わないこと」の明示。スコープクリープ（プロジェクトの範囲が際限なく広がること）を防ぐために重要です。 テイム版とウィキッド版 単純なデザイン課題（「このフォームのUIを改善する」など）のデザインブリーフは比較的簡単に書けます。しかしウィキッド・プロブレムに直面するとき、デザインブリーフ自体が反復的に更新される性質を持ちます。 ユーザーリサーチを進めるほど問題の定義が変化し、プロトタイプテストを経るほど成功基準が洗練される——このプロセスの中でデザインブリーフは「固定した文書」ではなく 「最新の問題理解を反映した生きた文書」 として機能します。 良いデザインブリーフと悪いデザインブリーフ 良いブリーフ：「30代子育て中の共働き夫婦が、平日夜20分以内に食材発注を完了できるようにする」（ユーザー・状況・成功基準が具体的） 悪いブリーフ：「より使いやすい食材注文アプリを作る」（誰のため・どんな状況・何が「使いやすい」か不明） 悪いブリーフの特徴は「誰のための」が抜けていることです。デザイン思考の人間中心主義の観点から、デザインブリーフは必ず 具体的なユーザーの具体的な状況から問いが立てられている 必要があります。 --- 参考文献 - Don Norman, The Design of Everyday Things, Basic Books, 1988（revised & expanded, 2013） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### デザイン思考（Design Thinking） URL: https://designthinking.studio/glossary/design-thinking/ > デザイナーの思考プロセスをビジネスや社会課題の解決に応用する、人間中心のイノベーション方法論。 デザイン思考（Design Thinking）は、デザイナーが日常的に用いる思考プロセス——観察、共感、プロトタイピング、反復——をビジネスや社会の複雑な課題解決に適用する方法論です。 IDEOのTim Brownは「デザイナーの感性と手法を用いて、人々のニーズ、テクノロジーの可能性、ビジネスの成功要件を統合するイノベーションへの人間中心アプローチ」と定義しています。 スタンフォード大学d.schoolが体系化した5つのフェーズ（共感・問題定義・創造・プロトタイプ・テスト）が広く知られています。詳しくはデザイン思考とは何かを参照してください。 --- 参考文献 - Tim Brown, "Design Thinking", Harvard Business Review, June 2008 --- ### ニードファインディング（Needfinding） URL: https://designthinking.studio/glossary/needfinding/ > デザイン思考の共感フェーズの中核概念。ユーザーが言語化できていない潜在的なニーズを、観察・インタビュー・コンテキスト調査を組み合わせて掘り起こすアプローチ。Stanfordのd.schoolが体系化し、世界のデザイン実践に広まった。 ニードファインディングとは、ユーザー自身が言葉にできていないニーズを、観察とインタビューによって明らかにするプロセスです。「欲しいものを教えてください」という問いではたどり着けない層——行動の裏側にある動機、摩擦、矛盾——を掘り起こします。Stanfordのd.schoolが開発・体系化し、デザイン思考の共感フェーズの核として位置づけられています。 「ニーズ」と「ウォンツ」の違いから始める ニードファインディングを理解するには、まず「ニーズ（Needs）」と「ウォンツ（Wants）」の区別から入るといい。 ウォンツは「より速い馬が欲しい」「もっとシンプルなUIにしてほしい」のような、ユーザーが自覚し言語化できた要求です。ユーザーアンケートやヒアリングで収集できる。問題は、ウォンツはユーザーが現状を前提に考えているため、既存の解決策の改良しか生まないことです。 ニーズは、その奥にある。「目的地に早く着きたい」「迷わずタスクを終わらせたい」という、本人が明示的に語らない動機です。 Henry Fordが「顧客に何が欲しいかを聞いたら、もっと速い馬と答えただろう」という逸話を残したとされるように——ニーズへの問いは、解決策の形を前提としない。ニードファインディングは、その問いを現場で立て続けるための実践です。 Stanford d.school とニードファインディングの歴史 ニードファインディングの概念的な起源は、1957年にJohn E. ArnoldがStanfordで始めた設計教育にさかのぼります。Arnoldは工学的な問題解決を超え、ユーザーと文脈への深い理解を設計の出発点に置くことを主張しました。 2005年、David KelleyとBernie RothがStanford d.school（Hasso Plattner Institute of Design）を共同創設します。d.schoolはニードファインディングをデザイン思考の「共感（Empathize）」フェーズの中心概念として位置づけ、世界中の教育機関・企業に普及させました。 理論的な体系化としては、Michael BarryとSara Beckmanの論文「Innovation as a Learning Process: Embedding Design Thinking」が重要です。この論文はニードファインディングを、イノベーション学習プロセスの中に明確に組み込んだ初期の試みのひとつです。 3つの調査手法 ニードファインディングには、いくつかのアプローチがあります。単独で使うより組み合わせることで、ニーズの全体像が見えてきます。 観察（Observation） ユーザーが実際に行動している場——職場、家庭、移動中——に入り込み、行動そのものを記録します。インタビューと観察を組み合わせたコンテキスチュアル・インクワイアリーとの親和性が高い手法です。 観察で捉えるべきは「言っていることと、やっていることのズレ」です。「メモはPCに保存している」と語るユーザーが、実際には付箋を手元に張り出して管理しているとすれば、そのズレの中にニーズが潜む。行動が言語を裏切る瞬間を記録することが、観察の本質的な目的です。 インタビュー（Interview） 構造化されたアンケートではなく、半構造化インタビューで文脈を引き出します。「なぜそうしているんですか？」「その時、どんなことを考えていましたか？」という問いを重ね、表明されたニーズの背後にある動機を掘り下げる。 「5 Whys」（なぜを5回繰り返す）はニードファインディングのインタビューでよく使われる技法です。表面の答えから出発し、問いを重ねるごとに深い動機へ近づいていく。「なぜこのアプリを使うのですか？」「仕事を効率化したいから」「なぜ効率化が必要なのですか？」——と続けることで、機能レベルの要求から感情・社会的動機へと層が変わる。 自己記録（Self-Documentation） 日記やビデオ日記などで、ユーザー自身に体験を記録してもらう手法です。インタビュアーが立ち会えない時間・空間での行動と感情が記録できる。観察で捉えにくい「一人でいる時の行動」や「夜間の使用パターン」などを補うのに有効です。 「暗黙のニーズ」の3層構造 ニードファインディングの実践者がよく参照するのが、ニーズの層を分けて捉える視点です。 顕在ニーズは、ユーザー自身が言語化できているもの。「検索を速くしてほしい」「通知を減らしてほしい」のように、機能レベルの要求として現れます。 潜在ニーズは、言語化されていないが観察で見えてくるもの。行動パターン、ワークアラウンド（既存ツールで不満を補う工夫）、繰り返し現れる摩擦のポイントなどに潜んでいます。 感情・社会的ニーズは、最も深い層です。「チームに貢献していると感じたい」「失敗を見られたくない」「自分でコントロールしたい」という、自己評価や対人関係に根ざした動機。これを捉えられると、機能改善では届かなかった体験の質が変わります。 ニードファインディングが目指すのは、顕在ニーズを集めることではなく、潜在ニーズと感情・社会的ニーズに照準を当てることです。 現場での落とし穴 「共感」を急がない ニードファインディングで最も多い失敗は、調査の早い段階で「このユーザーが困っていることはわかった」と結論を引き出してしまうことです。仮説の確認作業に調査がすり替わり、見えていなかったニーズが見えないまま終わる。 観察とインタビューの段階では、解釈を保留するのが鉄則です。「なぜそうするのだろう？」という問いを持ち続け、意味付けは現場から戻ってから行う。 「言ったこと」を額面通りに受け取る 「使いやすいです」「問題ないです」という発言は、ニードファインディングにおいて最も注意が必要な種類の答えです。ユーザーは見知らぬインタビュアーに対して、批判より肯定を選ぶ傾向があります——心理学でいう社会的望ましさバイアス（Social Desirability Bias）です。 言葉より行動を、行動より文脈を見る。インタビューで「問題ない」と言いながら、別のアプリを並行して開いて補完している——その事実がニーズの所在を示します。 ニードファインディングで「解決策」を語り始めない 「このユーザーにはこういう機能が必要だ」という解決策への跳躍は、共感フェーズが終わっていない段階で起きやすい。ニードファインディングは問いを立てるプロセスであり、答えを出すプロセスではありません。Point of View（POV）として問題を定義するのは、ニードファインディングの結果を整理した後です。 デザイン思考の流れの中での位置づけ ニードファインディングはダブルダイヤモンドの第1フェーズ「Discover（発見）」の中核を担います。POVで問題を定義し、創造フェーズでアイデアを発散させ、プロトタイピングで検証する——という一連の流れの出発点です。 ペルソナやエンパシーマッピングはニードファインディングで得た素材を整理・統合するツールとして機能します。調査で蓄積した観察とインタビューのデータが、ペルソナの行動パターンやエンパシーマップのDoes/Feelsを埋める具体的な根拠になる。 デザインスプリントのMonday（月曜日）で行う「How Might We」の問い出しも、ニードファインディングの成果なしには空洞化します。深い共感から問いが立てられてはじめて、スプリントの5日間が有効に機能します。 --- 参考文献 - Liedtka, J. & Ogilvie, T., Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia University Press, 2011 - Michael Barry & Sara Beckman, "Innovation as a Learning Process: Embedding Design Thinking", California Management Review, Vol.50, No.1, 2007 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### プロトタイピング（Prototyping） URL: https://designthinking.studio/glossary/prototyping/ > プロトタイピングは「良いものを作る」ではなく「最小コストで仮説を検証する」思想的転換。低忠実度から高忠実度までのスペクトラム、15分原則、Fail early to succeed soonerの哲学をデザイン思考第4フェーズとして体系的に解説する。 プロトタイピング（Prototyping）は、デザイン思考の第4フェーズに位置する実践です。しかしその本質は「試作品を作る」という行為の説明ではなく、「学ぶために最小限のものを素早く作る」という思想的転換にあります。 なぜプロトタイピングが重要か プロトタイプを作る目的は、「良いものを作ること」ではありません。「この方向が正しいかどうかを、最小のコストで検証すること」です。 この定義の転換が重要です。「良いプロトタイプ」とは、最も速く・最も安く・最も効果的にユーザーから学びを得られるものです。精度が高く美しいプロトタイプである必要はなく、むしろ「あえて低忠実度に留める」ことが推奨されます。 理由は2つあります。第一に、完成度の高いプロトタイプを見たユーザーは「細かい仕上げ」へのフィードバックに集中し、コンセプト全体への根本的な意見を出しにくくなります。第二に、作る側も完成度の高いプロトタイプへの投資が大きくなるほど、否定的なフィードバックを受け入れにくくなります。 忠実度のスペクトラム プロトタイプには低忠実度から高忠実度までのスペクトラムがあります。 低忠実度プロトタイプ（Lo-fi） - ペーパープロトタイプ：紙と付箋で画面を表現。スマートフォンアプリのUIを紙に描き、ユーザーに「触って」もらう。 - ストーリーボード：体験の流れをコマ割りで描いた漫画形式。 - サービス・ウォークスルー：役割演技（ロールプレイ）で体験を演じてみる。スタッフが「アプリのように振る舞う」Wizard of Oz法も含む。 中忠実度プロトタイプ（Mid-fi） - ワイヤーフレーム：コンテンツと情報構造を灰色の矩形で表現。デザインツールで作るクリッカブルなプロトタイプ。 - コンシェルジュMVP：実際のシステムを作る前に、人手で体験を提供してその価値を検証する。 高忠実度プロトタイプ（Hi-fi） - インタラクティブプロトタイプ：実際のデザインをほぼ忠実に再現し、クリック・スワイプに反応するもの。 - MVP（Minimum Viable Product）：リリース可能な最小限の機能を持つ実際のプロダクト。 実務での使い方 ワークショップでよく起こるのは、「プロトタイプを作りましょう」というと参加者がすぐにパソコンを開き、デザインツールで画面を作り始めるパターンです。しかしデジタルツールでプロトタイプを作ることは、多くの場合ペーパープロトタイプに比べて5倍以上の時間がかかります。 「15分以内に作れないプロトタイプは、この段階には早すぎる」という原則が実践的な判断基準になります。 プロトタイプを使ったユーザーテスト プロトタイプはテストフェーズと一体で機能します。プロトタイプを作る前に「何を検証したいか」（テストの仮説）を明確にすることが重要です。 「このオンボーディングフローで、ユーザーが最初の3分以内に主要機能に到達できるか」という仮説があれば、その検証に必要な最低限の画面だけを作ればよい。不要な機能や画面を作ることは、テストの焦点を散漫にします。 デザイン思考における「失敗を前倒しする」哲学 IDEOやd.schoolが強調するプロトタイピングの哲学は、「早く失敗するほど、本番の失敗を避けられる（Fail early to succeed sooner）」です。 これは「失敗することが目的」ではありません。「学びが得られる最速の方法を選ぶ」という実用主義です。ペーパープロトタイプで10人にテストして「このコンセプト自体が刺さらない」と分かれば、開発に数ヶ月を投資する前に方向を転換できます。 --- 参考文献 - d.school, The Design Thinking Bootleg, Hasso Plattner Institute of Design at Stanford, 2018 - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Bill Moggridge, Designing Interactions, MIT Press, 2007 - Tomer Sharon, Validating Product Ideas: Through Lean User Research, Rosenfeld Media, 2016 --- ### ペルソナ（Persona） URL: https://designthinking.studio/glossary/persona/ > デザイン思考の共感フェーズで用いる仮想ユーザー像。実際のリサーチデータをもとに、特定のユーザーグループの行動・目標・価値観・感情を具体的な「人物」として記述したもの。 ペルソナ（Persona）は、実際のユーザーリサーチから得たデータを統合して作る仮想のユーザー像です。デザイン思考の共感フェーズで用いられ、チームが「誰のために設計するか」を常に明確に保つための共通言語として機能します。名前・年齢・職業・行動パターン・目標・フラストレーションを持つ「実在するような人物」として記述されます。 なぜペルソナが重要か デザインの最大の失敗は、「すべてのユーザーのために設計しようとすること」です。ターゲットが「誰でも」になった瞬間、設計の判断基準が消え、機能は増え、体験は複雑になります。 ペルソナが提供するのは「設計の制約」です。「山田花子（38歳、共働き、時間が少ない）のために設計する」という制約があれば、「この機能は花子の状況で必要か？」という問いが判断基準になります。チームの全員が同じユーザーイメージを共有することで、設計の一貫性が保たれます。 また、ペルソナは問題定義フェーズでPOV（Point of View）ステートメントの主語として機能し、創造フェーズでのアイデア評価基準を与えます。デザイン思考の5フェーズを通じて、チームが「誰のために」を見失わないための錨です。 ペルソナの作り方 Step 1：リサーチデータを収集する ペルソナは仮想ですが、データに基づく必要があります。 作り込まれたフィクションではなく、実際のユーザーインタビュー・行動観察・アンケートから得た情報の統合です。ユーザーインタビューで得た発言、行動観察で記録したパターン、アクセス解析データなどを材料にします。 「データのないペルソナはフィクション」という批判を防ぐためにも、「このペルソナの根拠になったリサーチ」を記録として残すことが重要です。 Step 2：ユーザーグループをクラスタリングする インタビューや観察から得た情報を付箋に書き出し、親和図法（Affinity Diagram）でパターンを見つけます。似た行動パターン・目標・フラストレーションを持つグループがペルソナの候補です。 1つのペルソナに複数のユーザーの特徴を混ぜすぎると、誰でもあり誰でもない存在になります。 通常、主要ペルソナは2〜3体に絞り、それぞれが明確に異なるユーザーグループを代表するように設計します。 Step 3：ペルソナシートを作成する ペルソナシートには以下の要素を含めます。 基本属性は名前・年齢・職業・家族構成・居住地など、人物を立体化するための情報です。「34歳、女性、都内勤務のマーケティングマネージャー、子ども1人」のように具体的に書きます。実在するような顔写真（フリー素材）を添付することで、チームが「人物として」イメージしやすくなります。 行動パターンは、対象のプロダクト・サービスに関連する典型的な行動の流れです。「どのようなシチュエーションでこのサービスを使うか」「使う前後に何をするか」を記述します。 目標（Goals）は、このユーザーが達成したいことです。機能的目標（仕事を効率的に終わらせたい）、感情的目標（ストレスを減らしたい）、社会的目標（チームから認められたい） の3層で記述すると、設計の優先順位がつけやすくなります。 フラストレーション（Pain Points）は、現状において障壁になっていることです。「なぜ今の解決策では不十分か」が見えるように記述します。ここがHow Might Weの問いを立てる起点になります。 引用（Quote）は、実際のインタビューで得た発言から選んだ代表的な言葉です。ペルソナに「声」を与えることで、設計判断の場で「花子はこう言っていた」という具体的な参照が可能になります。 Step 4：チームで合意形成する 作成したペルソナシートをチーム全員で確認し、「このペルソナは自分たちが会ったユーザーを正しく表しているか？」を議論します。デザイナーが単独で作ったペルソナを共有するのではなく、チームで作り上げるプロセスが共有の理解を深めます。 壁に貼り出して常に見える状態にすることで、日々の設計判断でペルソナが参照されやすくなります。 よくある失敗 ステレオタイプの押し付け 「デジタルに疎い高齢者」「仕事熱心な30代男性」のような社会的ステレオタイプをペルソナに当てはめてしまうケースがあります。ペルソナはリサーチから生まれるものであり、事前の思い込みから生まれるものではありません。 ステレオタイプベースのペルソナは、設計チームの偏見を正当化するツールに成り下がります。 「マーケティングペルソナ」との混同 マーケティングで使われるペルソナは、「誰を顧客ターゲットにするか」という購買意思決定者の記述が中心です。一方、デザイン思考で使うペルソナは「このユーザーはどんな文脈で、何を達成しようとしているか」という体験の記述が中心です。目的が異なるため、マーケティング部門が持つペルソナをそのままデザイン思考に流用すると、有用な設計基準にならないことがあります。 一度作って更新しない ペルソナは「作ったら完成」ではありません。ユーザーの行動環境（テクノロジー、社会状況、競合製品）が変化するにつれ、ペルソナも更新する必要があります。 2年前に作ったペルソナを使い続けているチームは、現実のユーザーからズレたまま設計を続けているリスクがあります。 ペルソナと関連ツール ペルソナは単独で使うより、他のツールと組み合わせることで威力を発揮します。 ジャーニーマップ はペルソナを主人公として、サービスとの接触から離脱までの体験の流れを時系列で可視化します。ペルソナの「誰が？」にジャーニーマップの「どんな体験をするか？」が重なり、設計の優先課題が明確になります。 Point of View（POV） はペルソナを主語として「このユーザーは〇〇を必要としている。なぜなら〇〇だから」という形式で問題定義を行います。ペルソナが共感フェーズから定義フェーズへと橋渡しをする構造になっています。 --- 参考文献 - Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy, Sams Publishing, 1999（ペルソナ概念の元祖） - Liz Goodman, Elizabeth Strickland & Nina Kulagina, Observing the User Experience, Morgan Kaufmann, 2012 - Nielsen Norman Group, "Personas: Study Guide", nngroup.com, 2022 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018 --- ### メンタルモデル URL: https://designthinking.studio/glossary/mental-model/ > ユーザーがシステムや製品の動作について持つ内的な理解の表象。Donald Normanが「誰のためのデザイン？」で設計者モデルとの乖離を問題化し、デザイン思考の共感・問題定義フェーズで不可欠な概念となった。 ユーザーがサービスを使う前から、あるいは使いながら、頭の中に「このシステムはこういう仕組みで動いているはず」という理解の地図を持っています。この内的な理解の表象をメンタルモデルと呼びます。 重要なのは、このメンタルモデルが必ずしも正確ではないという点です。「正確かどうか」より、「ユーザーがそのモデルに基づいて行動する」という事実が設計において重要です。 メンタルモデルの概念的基盤 「メンタルモデル」という概念は、心理学者Philip Johnson-Lairdが1983年の著書 Mental Models: Towards a Cognitive Science of Language, Inference, and Consciousness（Cambridge University Press）で体系化した認知科学の概念です。Johnson-Lairdは、人間が外界を理解するための内部表象として、命題・アナログ的イメージとは異なる第三の認知形式としてメンタルモデルを位置づけました。 この概念をデザインの文脈に持ち込んだのが、認知科学者Donald Norman（ドナルド・ノーマン）です。 ノーマンの「3つのモデル」 Normanは著書 The Design of Everyday Things（1988年初版、邦訳『誰のためのデザイン？』）の中で、日常の製品とユーザーの関係を説明するために3つのモデルを対置させました。 設計者モデル（Design Model） 設計者が持つ「このシステムはこう動くべき」という意図と仕様の理解。設計者の頭の中にある正確なシステム像です。 システムイメージ（System Image） 実際の製品・インターフェース・マニュアル・広告など、ユーザーが接触できる物理的・情報的な表象の総体。設計者のモデルがユーザーに伝わる唯一の媒介です。 ユーザーメンタルモデル（User's Mental Model） ユーザーがシステムイメージから構築した「このシステムはたぶんこういう仕組みだろう」という理解。必ずしも正確ではなく、経験・類比・推測から形成されます。 Normanが問題化したのは、設計者モデルとユーザーメンタルモデルの乖離です。設計者は「正しい使い方」を知っているため、システムイメージが適切にメンタルモデルを形成できているかを体感しにくい。この非対称性が、「使いにくい製品」の多くの原因になっているとNormanは論じました。 デザイン思考とメンタルモデルの関係 デザイン思考の共感フェーズでは、ユーザーの思考・感情・行動を理解することを目的とします。メンタルモデルの把握は、この共感フェーズの核心的な目標の一つです。 ユーザーは「あなたが設計した通り」には考えていない 設計者にとって「当然の仕様」がユーザーには「理解できない謎」であることは頻繁に起きます。これは「ユーザーの理解が足りない」のではなく、「ユーザーのメンタルモデルと設計が整合していない」と捉えることがデザイン思考的な問題の見方です。 メンタルモデルは調査せずに想定できない 「ユーザーはこう思っているはずだ」という設計者の仮定は、メンタルモデルの乖離が起きているまさにその場所で機能します。ユーザーインタビューや観察でメンタルモデルを実際に把握することなしに、整合した設計は難しいです。 メンタルモデルの把握手法 インタビューによる把握 「このボタンを押したとき、何が起きると思いましたか」「今、この画面は何をしていると理解されていますか」という問いは、ユーザーのメンタルモデルを直接言語化させる効果があります。 特に有効なのは「大声思考（Think Aloud Protocol）」との組み合わせです。ユーザーに操作しながら頭の中で考えていることを口に出してもらうことで、操作の背景にあるメンタルモデルが観察できます。シンクアラウドプロトコルのファシリテーションと組み合わせることが多いです。 メンタルモデル図（Mental Model Diagram） 情報アーキテクチャ研究者のIndi Youngは、著書 Mental Models: Aligning Design Strategy with Human Behavior（Rosenfeld Media, 2008）でメンタルモデル図という手法を提案しています。ユーザーリサーチから得られた「ユーザーが達成しようとしていること・感じていること・考えていること」をタスク単位でまとめ、それに対して「現在の製品・サービスはどう対応しているか」を可視化するマップです。 このマップは、設計のギャップを発見するための定義フェーズのツールとして機能します。ユーザーのメンタルモデルが求めていることと、現在の設計が提供していることのズレが、問題定義の素材になります。 設計へのフィードバック メンタルモデルの理解を設計に活かす際の主要な方向性は2つあります。 メンタルモデルに合わせた設計（適合戦略） ユーザーが既に持っているメンタルモデルに設計を近づけることで、学習コストを下げます。「ゴミ箱」アイコンが削除を意味する理解はすでに多くのユーザーが持っており、この既存のメンタルモデルを活用した設計の例です。 メンタルモデルを変える設計（刷新戦略） 既存のメンタルモデルではうまく機能しない場合、新しいメンタルモデルを形成させる設計が必要になります。この際、段階的な移行・オンボーディング・比喩の活用（「スマートフォンはポケットに入るコンピューター」という比喩は、新しいカテゴリに対して既存のメンタルモデルを橋渡しする）が有効です。 どちらの戦略を取るかは、ユーザーリサーチによる現在のメンタルモデルの把握なしには判断できません。 --- 参考文献 - Donald Norman, The Design of Everyday Things, Basic Books, 1988（改訂版 2013年、邦訳: 岡本明他訳『誰のためのデザイン？』、新曜社） - Philip Johnson-Laird, Mental Models: Towards a Cognitive Science of Language, Inference, and Consciousness, Cambridge University Press, 1983 - Indi Young, Mental Models: Aligning Design Strategy with Human Behavior, Rosenfeld Media, 2008 --- ### ラテラルシンキング（水平思考） URL: https://designthinking.studio/glossary/lateral-thinking/ > エドワード・デ・ボノが1967年に提唱した思考法。論理的な垂直思考とは異なる角度から問題に接近し、前提を崩して新しいアイデアを生み出す。デザイン思考の創造フェーズで中核的な役割を担う。 「正しい答えを深く掘る前に、まず別の場所を掘れ」——エドワード・デ・ボノ（Edward de Bono, 1933〜2021）は、この比喩でラテラルシンキングの本質を表した。1967年の著書 The Use of Lateral Thinking（邦題『水平思考の世界』）で初めて提唱されたラテラルシンキング（水平思考）は、半世紀以上を経た今日、デザイン思考のアイデア発想フェーズにおける論理的基盤として機能している。 垂直思考との対比 デ・ボノはラテラルシンキングを「垂直思考（Vertical Thinking）」との対比で定義した。この二項対立を理解することが、ラテラルシンキングの核心を掴む最短経路だ。 垂直思考（Vertical Thinking）は、論理的・順序的に問題を解く思考法だ。「AならばB、BならばC、ゆえにC」という演繹的な連鎖を積み上げる。数学の証明、ソフトウェアのアルゴリズム設計、財務分析はこの思考様式で成立する。垂直思考は既存のカテゴリと仮定を前提に、その内側を深く掘り下げる。最も優れた穴を、より深く掘る思考だ。 ラテラルシンキング（水平思考）は、既存のカテゴリと仮定を意図的に崩す。「そもそもここを掘る必要があるのか」「別の場所に掘るべき穴があるのではないか」という問いを投げかける。論理の連鎖ではなく、前提の組み換えによって新しい可能性を開く思考だ。 デ・ボノは「垂直思考は正しい答えを出すための道具。ラテラルシンキングは異なる答えを出すための道具」と述べた。両者は競合するのではなく、相補的に機能する。優れた問題解決者は、両方の思考様式を状況に応じて切り替える能力を持っている。 デ・ボノの4つのラテラルシンキング技法 デ・ボノは、ラテラルシンキングを「才能ある人だけに可能な神秘的な閃き」ではなく、意図的に訓練できる技法として体系化した。主要な技法は四つある。 - 代替案の強制（Alternative Methods） 「これしか方法がない」という思い込みを崩すために、「最低でも3つの別の方法を考えよ」という制約を課す。正解を探すのではなく、可能性の空間を広げることが目的だ。デザイン思考のワークショップでよく起こるのは、参加者が「明らかな解決策」に素早く収束してしまう場面だ。「他にどんな方法があるか？」という問いかけが、この技法の実践的な形である。 - ランダムな刺激の導入（Random Stimulation） 問題とは無関係に見えるランダムな言葉・画像・概念を強制的に結びつける。「病院の待合室の課題に『蛸壺』をつなげるとしたら」という問いは、論理的には無意味だ。しかし、この強制的な連結が予期しない角度から解決策を照らすことがある。人間の脳はパターン認識の機械であり、無関係に見えるものを結びつけようとする傾向がある。ランダムな刺激はその傾向を意図的に利用する。 - 概念の挑戦（Challenge） 「なぜそれをしているのか」「それは本当に必要なのか」という問いで、当然とされている前提を問い直す。航空会社が「搭乗手続きをカウンターでする」という前提を疑わなければ、スマートフォンによるモバイル搭乗券は生まれなかった。デザイン思考の共感フェーズで発見した「ユーザーの不満」の多くは、挑戦されていない慣習から生じている。 - 視点の移動（Movement） 「これは使えない」「間違っている」と判断する前に、その考えを足がかりとして次の発想に進む。デ・ボノは「Po（Provocative Operation）」という接頭辞を提案した。「Po: 車に足がある」「Po: 病院に料金所がある」——これらは現実的な提案ではなく、思考の移動を引き起こすための踏み台だ。 Six Thinking Hats との関係 デ・ボノの代表的なツールとして、日本でも広く知られるシックス・シンキング・ハッツ（Six Thinking Hats）がある。1985年の著書 Six Thinking Hats で提唱されたこのフレームワークは、ラテラルシンキングの哲学を集団思考プロセスに組み込んだものだ。 六つの帽子は、それぞれ異なる思考モードを象徴する。 | 色 | 思考モード | 問い | |---|-----------|-----| | 白 | 情報・データ | 事実として何がわかっているか | | 赤 | 感情・直感 | 直感的にどう感じるか | | 黒 | 批判的検討 | リスクと問題点は何か | | 黄 | 楽観・価値 | うまくいく可能性と価値は何か | | 緑 | 創造・代替案 | 他の可能性は何か | | 青 | プロセス管理 | 今何の帽子をかぶるべきか | 重要なのは、緑の帽子のフェーズでラテラルシンキングが最も純粋に発動するという点だ。緑の帽子をかぶっているとき、批判は禁じられる。どんな奇抜な案でも、まず「足がかり」として扱う。この「批判の保留」こそが、ラテラルシンキングの創造的空間を生み出す。 デザイン思考の実践において、Six Thinking Hats は集団の発散と収束を構造化する道具として機能する。ダブルダイヤモンドの発散フェーズ（Develop）では緑の帽子優先、収束フェーズ（Deliver）では黒と黄の帽子が機能するという読み方ができる。 デザイン思考の創造フェーズでの位置づけ デザイン思考の5フェーズのうち、創造（Ideate）フェーズはラテラルシンキングが最も直接的に機能する段階だ。 創造フェーズが苦手な実践者に共通するパターンがある。問い（How Might We）を受けとった瞬間に垂直思考が起動し、「現実的に可能なこと」「前例のあること」「リスクの少ないこと」という制約の中で答えを探し始める。これはアルゴリズム的な発想であり、イノベーションの余地が極めて小さい。 ラテラルシンキングの技法は、この垂直思考への引力に抗う手段を提供する。「最悪なアイデアから始める（Worst Possible Idea）」「まったく異なる業界の解決策を転用する（Analogous Inspiration）」「ランダムワードを使う（Random Word Method）」——これらはすべて、デ・ボノのラテラルシンキング技法のデザイン思考文脈での応用だ。 200回以上のワークショップで繰り返し観察される現象がある。ブレインストーミングの最初の10分は「普通のアイデア」が集まる。参加者の頭は既存のパターンで動いている。しかし「最もバカげた案を出せ」という問いかけを一度挟んだ後、その「バカげた案」を起点に発想を展開していくと、それまで出なかった角度からの洞察が生まれる。これがラテラルシンキングの「視点の移動」が機能した瞬間だ。 批判的視点と限界 ラテラルシンキングへの批判として、「手法の形式に囚われ、思考そのものが浅くなる」という指摘がある。Six Thinking Hatsを「プロセスのチェックリスト」として使うと、帽子を順番に変えることが目的化し、各思考モードの質が上がらない。形式が思考の代替になるとき、ラテラルシンキングは機能しなくなる。 また、「新奇性のための新奇性」に陥るリスクもある。ランダムな刺激と奇抜な組み合わせを求めるあまり、ユーザーの本質的な問題から離れた発想が増えることがある。ラテラルシンキングは「新しい」アイデアを生む道具であり、「有用な」アイデアを保証する道具ではない。これが人間中心設計との組み合わせが重要な理由だ。ユーザーの文脈に深く根ざした問い（How Might We）があってこそ、ラテラルシンキングの創造性は方向性を持つ。 実践的な使い方 ラテラルシンキングを創造フェーズに組み込む際、以下のシーケンスが有効だ。 まず定義された問い（How Might We）を確認し、チームで共有する。次に5分間の「垂直思考フェーズ」——思いつく解決策を出し切る。その後、ランダムワードを一つ選び「この言葉から発想を転換するとしたら」という問いで3分間強制的に発想する。最後に、ランダムワードから生まれた荒削りなアイデアを「起点」として次の発想に展開する。 この順序の重要性は「垂直思考を先に使い切ること」にある。ラテラルシンキングは垂直思考の代替ではなく、垂直思考が掘り尽くした後の別の掘り場を見つける道具だ。 デ・ボノが亡くなった2021年は、コロナ禍でオンラインワークショップが急増した年でもあった。デジタルホワイトボードツール（Miro、Figjam等）の普及によって、ランダムワードの導入やPoの使用がよりスムーズに行えるようになった。形式は変わっても、「別の場所を掘る」というラテラルシンキングの本質は変わらない。 --- 参考文献 - Edward de Bono, The Use of Lateral Thinking, Jonathan Cape, 1967（邦訳：『水平思考の世界』） - Edward de Bono, Six Thinking Hats, Little, Brown and Company, 1985（邦訳：『6色ハット発想法』） - Edward de Bono, Lateral Thinking: Creativity Step by Step, Harper & Row, 1970 - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015 --- ### 拡散的思考（Divergent Thinking）とは URL: https://designthinking.studio/glossary/divergent-thinking/ > J.P. ギルフォードが1950年のAPA会長講演「Creativity」で定式化した知能の一様式。単一の正解に向かう収束的思考とは対照的に、複数の可能な答えを生成し探索する思考モード。流暢性・柔軟性・独創性・精緻性の4指標で測定される。 「創造性は測れるか」——1950年、心理学者J.P. ギルフォード（Joy Paul Guilford, 1897〜1987）はこの問いをアメリカ心理学会（APA）の会長講演の中心に据えた。この講演「Creativity」（American Psychologist, Vol.5, No.9, 1950）で提唱されたのが、拡散的思考（Divergent Thinking）という概念だ。 ギルフォードの「知能の構造」モデル ギルフォードが拡散的思考を提唱した背景には、当時の知能研究への批判があった。1950年代の知能研究の主流は、IQテストに代表される「一つの正解に向かう能力」の測定だった。数学の問題を解く、文章の意味を理解する——これらはすべて「正解が定まっている問い」への回答能力を測るものだ。 ギルフォードはこれを収束的思考（Convergent Thinking）と命名し、それとは異なる知能様式として拡散的思考を定義した。 拡散的思考とは、一つの出発点（問い・刺激・条件）から複数の異なる方向へと思考を展開し、多様な答えを生成する能力だ。正解は一つではなく、生成される回答の多様性・量・独創性そのものが評価の対象となる。「レンガの用途を思いつく限り挙げよ」「この図形を見て何に見えるか」——これがギルフォードが設計した拡散的思考の測定課題の典型だ。 ギルフォードは晩年の「知能の構造（Structure of Intellect, SOI）」モデル（1967）で知能を180の因子で構造化したが、拡散的思考はその中核的な一軸として位置づけられた。 4つの測定指標 ギルフォードは拡散的思考を4つの操作可能な指標で測定可能にした。 流暢性（Fluency）は、一定時間内に生成できるアイデアの量を示す。「椅子の使い方」に対して15個挙げられる人と5個しか挙げられない人では、流暢性の高さが異なる。量の多さが探索範囲の広さを示す指標となる。 柔軟性（Flexibility）は、異なるカテゴリにまたがるアイデアを生成できる能力だ。「椅子で座る・テーブルにする・踏み台にする」は似たカテゴリだが、「椅子で薪を作る・アート作品にする・武器にする」は異なるカテゴリだ。同じカテゴリ内でのアイデア量ではなく、カテゴリを横断する思考の柔軟さを測る。 独創性（Originality）は、統計的に稀な（他者が思いつかない）アイデアを生成する能力だ。集団調査において他の参加者が回答しなかった答えが、独創性の高さを示す。 精緻性（Elaboration）は、一つのアイデアを詳細に展開・発展させる能力だ。粗削りなアイデアをより具体的・完成度の高い形に膨らませる力を示す。 この4指標は現在の創造性研究でも広く参照されており、Torrance Tests of Creative Thinking（TTCT、1966年にE.P. トーランスが開発）など後続の測定ツールの理論的基盤となっている。 「収束的思考」との本質的な違い 発散思考と収束思考の記事では両者のファシリテーション実務が主題だが、ギルフォードの理論的な区別はより根本的な認知構造の違いを指している。 収束的思考は「最良の一つの答え」に向かう思考だ。問いに対する正解が存在し、その正解に最短で到達するための論理と知識が評価される。学校教育の多くはこの形式の思考を鍛える。 拡散的思考は「答えの多様性」を最大化する思考だ。正解は問われない。むしろ「正解かどうか」の評価を保留したまま、可能性の空間を広く探索することが求められる。 ギルフォードが指摘した1950年代の知能研究の問題——創造性は収束的思考だけでは測れない——は、現代のAI時代においても改めて意味を持つ。正解の探索においてAIが人間を凌駕していく中で、拡散的思考、すなわち問いの生成・仮説の多様化・前例のない組み合わせの創出が人間固有の知的寄与として浮かび上がる。 デザイン思考プロセスとの対応 デザイン思考のアイデエーションフェーズは、構造化された拡散的思考の実践場だ。 「How Might We（どうすれば〜できるか）」という問いの立て方は、収束的思考の自然な傾向——「最良の解決策は何か」という問いへの早期収束——を意図的に抑止する設計だ。「どうすれば」という問いの開放性が、複数の方向への思考展開を促す。 ブレインストーミングのルール——「判断を保留する」「量を追求する」「他者のアイデアに乗っかる」——は、ギルフォードの4指標のうち流暢性・柔軟性・独創性を高めるための行動設計として読み解ける。「判断を保留する」は評価的思考（収束）の介入を防ぐことで流暢性を守る。「量を追求する」は流暢性の直接的な促進だ。「他者のアイデアに乗っかる」は、異なるカテゴリへの飛躍（柔軟性）を集団として生み出す。 ラテラル・シンキングがエドワード・デ・ボノによって提唱した「垂直思考からの脱却」も、ギルフォードの拡散的思考と同じ認知現象の別角度からの記述として位置づけられる。 --- 参考文献 - Guilford, J.P., "Creativity", American Psychologist, Vol.5, No.9, pp.444-454, 1950 - Guilford, J.P., The Nature of Human Intelligence, McGraw-Hill, 1967 - Torrance, E.P., Torrance Tests of Creative Thinking: Norms-Technical Manual, Scholastic Testing Service, 1974（初版1966） - Runco, Mark A., "Divergent Thinking", in Encyclopedia of Creativity (2nd ed.), Academic Press, 2011 関連記事: 発散思考と収束思考 / アイデエーションフェーズ / ラテラル・シンキング / アブダクション（仮説的推論） --- ### 共感マッピング深掘り——Dave Gray Empathy Map Canvas の構造と原理 URL: https://designthinking.studio/glossary/empathy-mapping-deep/ > Dave Gray（XPLANE 創設者）が2010年代に設計したEmpathy Map Canvasの4象限（Says/Thinks/Does/Feels）の設計思想と、各象限が明かす認知層の違い。既存の手順ガイドとは独立した概念・理論角度の詳述。 共感マッピングは「ワークショップのツール」として紹介されることが多い。しかし、Dave Gray が設計した Empathy Map Canvas の構造には、ユーザー認知の4つの異なる層を分離するという理論的な意図がある。手順ガイドや基本解説が「どう使うか」を扱うのに対し、本稿は「なぜその形なのか」を問う。 Dave Gray と XPLANE、Gamestorming の文脈 Dave Gray はインフォメーション・デザインとビジュアル・シンキングを専門とする米国のデザイナー・著作家で、1993 年にビジュアル・コミュニケーション会社 XPLANE を設立した。XPLANE は複雑な情報を視覚化するビジネスデザイン会社として、企業のコミュニケーション課題に関わってきた。 2010 年、Dave Gray は Sunni Brown・James Macanufo との共著 Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers（O'Reilly）を刊行した。この著作は、創造的な思考と協働を促す 80 以上のゲーム形式ワークショップツールを収録したもので、その中に Empathy Map が含まれていた。Gamestorming の文脈では、Empathy Map はチームがユーザーについて持つ「暗黙の仮定」を可視化・共有するためのゲームとして位置づけられている。 Gray はその後もこのツールを発展させ続け、2017 年にはキャンバスの改訂版——中央の象限を削除し4象限の外側に「Pains（苦痛）」と「Gains（獲得）」を加えたバージョン——を公開している。 4象限の認知科学的な読み方 Empathy Map Canvas の Says / Thinks / Does / Feels という4象限は、ユーザーの体験を言語・認知・行動・感情という4つの異なる情報経路で記録するよう設計されている。それぞれの象限が明かす認知の層は異なる。 Says（言っていること）——顕在化した語り Says はインタビューや観察中にユーザーが実際に口にした言葉を記録する象限だ。ここに書かれるのは意識的・言語的なコミュニケーションであり、ユーザーが自分で「これが自分の体験だ」と語った物語だ。 重要なのは、Says はユーザーの体験の表層にある。心理学でいう自己報告バイアス（Self-Report Bias）——人は自分の行動や感情を合理化・正規化して語る傾向がある——が最も強く働く象限だ。Says だけを見ると、ユーザーの「理想的な自己像」に近い語りが積み重なる。 Thinks（考えていること）——潜在的な認知 Thinks は Says と対をなす象限だ。「口にはしないが、おそらく考えていること」を記録する。この象限は観察者の推察によって埋められる唯一の象限であり、それゆえ扱いが最も難しい。 Gray の設計意図は、Says と Thinks の対比によって「ユーザーが語る世界」と「ユーザーが内側で体験している世界」のギャップを可視化することにある。「このツールは使いやすいと思っています」（Says）の背後に「でも本当はもっとシンプルな方法があるはずだと思っている」（Thinks）が潜む——このギャップこそが問いを立てる起点になる。 Does（していること）——行動的現実 Does は「ユーザーが実際にとった行動」を記録する象限だ。観察による事実データが中心となる。Says が「語り」ならば、Does は「証拠」だ。 Says と Does の矛盾は、エンパシーマップが生み出す最も価値ある発見のひとつだ。「毎日チェックしています」（Says）に対して「1ヶ月に1〜2回しかログインしていない」（Does）というギャップは、ユーザーが自分の行動を正確に認識していないことを示す。この矛盾は責めるべき問題ではなく、デザインが問うべき問いの所在を指し示すシグナルだ。 Feels（感じていること）——感情の層 Feels は体験に伴う感情状態を記録する象限だ。ここで重要なのは、感情は他の3象限と独立した情報経路を持つということだ。 認知心理学の視点では、感情は論理的な評価とは別の経路で処理される（二重過程理論）。「機能的には問題ない」（Thinks / Does）のに「なんとなく不安を感じる」（Feels）というパターンは、信頼感・一貫性・制御感などの感情的ニーズが満たされていないことを示す。これは機能改善では解決できない問題であり、デザインの問いの立て方自体を変える発見になる。 Says / Thinks の縦軸、Does / Feels の横軸 Gray の象限配置には構造的な意図がある。従来の配置では、Thinks（考えていること）が上・Says（言っていること）が下に来るバージョンと、4分割がフラットに並ぶバージョンが混在している。いずれの場合も、Says と Thinks は「意識的・認知的な層」として対をなし、Does と Feels は「行動的・感情的な層」として対をなすことが設計の基本にある。 この対比によって、エンパシーマップは単なる「ユーザー情報の整理ボード」ではなく、認知・行動・感情という人間の体験の異なる層を分離して可視化するレンズとして機能する。 2017年改訂版——Pains と Gains の追加 Gray が 2017 年に公開した改訂版では、4象限の外側下部に Pains（苦痛・懸念・フラストレーション） と Gains（得たいもの・目標・成功の定義） の2つの欄が追加された。 この改訂の意図は、4象限から導出される要約の欄を明示的に設けることにある。Pains は「ユーザーが乗り越えようとしている障害は何か」、Gains は「ユーザーが本当に達成しようとしている価値は何か」を問う。これは JTBD（Jobs to be Done） の問いと構造的に近く、エンパシーマップの分析結果を問題定義へ直接接続するための橋渡しとなる。 原典との関係——Gamestorming の意味論 Gamestorming における Empathy Map の位置づけは、「共感を測るツール」ではなく「チームの仮定を可視化して議論を生むゲーム」だ。Gray は Empathy Map を使うことで、チームメンバーがユーザーについて暗黙的に持っている異なる仮定が浮かび上がり、そのずれが議論と洞察の起点になることを設計意図として明示している。 これは「正しいエンパシーマップを作る」という目標設定とは異なる。完成したマップよりも、マップを埋める過程での議論と気づきこそが価値だという認識だ。 --- 参考文献 - Dave Gray, Sunni Brown & James Macanufo, Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, O'Reilly, 2010 - Dave Gray, "Updated Empathy Map Canvas", Medium, 2017 - Nielsen Norman Group, "Empathy Mapping: The First Step in Design Thinking", nngroup.com, 2017 関連記事: 共感マップ（基本解説） / エンパシーマッピング完全ガイド / 共感フェーズ / POVステートメント --- ### 認知負荷（Cognitive Load）— デザイン思考が解きほぐす複雑性の正体 URL: https://designthinking.studio/glossary/cognitive-load-design/ > 認知負荷とは人間の作業記憶が処理できる情報量の限界を示す認知心理学の概念。ミラー法則・スワラー理論の基礎からデザイン思考との接続、プロトタイプと段階的情報開示による実務的軽減手法まで体系的に解説する。 認知負荷（Cognitive Load）とは、人間の作業記憶が一度に処理できる情報量の限界を示す認知心理学の概念です。デザイン思考との文脈では、製品・サービス・情報アーキテクチャが利用者に課す「頭の使わせ方」の負担量を指します。この概念を理解することは、「なぜ使いにくいのか」という問いへの答えをユーザーの能力ではなくデザインの側に求める出発点になります。 理論的背景：ミラー法則とスワラー 認知負荷理論の基盤は、心理学者ジョージ・ミラーが1956年に発表した「The Magical Number Seven, Plus or Minus Two」に端を発します。ミラーはこの論文で、人間の作業記憶が同時に保持できるチャンク（情報のかたまり）の数は 5〜9 個であることを示しました。「7桁の電話番号は覚えられるが、13桁は覚えられない」という経験則の学術的根拠がここにあります。 1988年には、教育心理学者のジョン・スワラーがこの知見を「認知負荷理論（Cognitive Load Theory）」として体系化しました。その後1990年代にかけてスワラーと共同研究者らによる継続的な研究を経て、認知負荷は三種に分類されるようになりました。 - 内在的負荷（Intrinsic Load） — 学習・処理する素材そのものの複雑さに由来する負荷。下げることは難しい - 外在的負荷（Extraneous Load） — 設計・提示方法の悪さに由来する負荷。デザインの改善で直接削減できる - 関連的負荷（Germane Load） — 理解の深化やスキーマ形成に使われる「良い負荷」。学習効果を生む デザインの実務的文脈で問題になるのは、主に外在的負荷です。情報の整理が悪い画面、文脈なく出現する選択肢、一画面に詰め込まれた機能——こうした「設計のノイズ」が作業記憶を圧迫し、本来の判断や行動を妨げます。 デザイン思考との接続 デザイン思考の共感フェーズでユーザーを観察すると、「どこで手が止まるか」「どこで首をかしげるか」が繰り返し見えてきます。その多くは、認知負荷が閾値を超えた瞬間です。ユーザーが「迷う」「戻る」「諦める」という行動は、能力の問題ではなく、外在的負荷が過剰になった設計の問題として読み解けます。 人間中心設計（HCD）の核心は「人間の能力に合わせてシステムを設計する」という逆転です。認知負荷理論はこの逆転を具体化する道具として機能します。「なぜ使えないか」を「ユーザーが難しすぎる」と説明するのではなく、「設計がどこで不要な負荷を作り出しているか」と問い直すフレームを提供します。 また、ウィキッド・プロブレムと認知負荷には構造的な関係があります。社会課題や組織変革のような複雑な問題を扱う際、ステークホルダーが感じる「何から手をつければいいかわからない」という感覚は、問題構造の複雑さ（内在的負荷）に加え、議論の場・情報の提示方法が不整理（外在的負荷）であることに起因していることが少なくありません。デザイン思考のプロセスは、この外在的負荷を下げながら複雑性に向き合うための枠組みとも言えます。 実務での軽減手法 - 低忠実度プロトタイプによる「見える化」 プロトタイプの本質的な価値のひとつは、認知負荷の軽減にあります。言葉や概念だけで議論する場合、参加者は「そのアイデアを頭の中に想起する」という作業を同時にこなす必要があり、作業記憶が圧迫されます。紙に描いた画面の粗いスケッチであっても、「見えるもの」にすることで外在的負荷が大幅に下がります。 判断や議論の質は、情報が視覚化されているかどうかで変わります。「プロトタイプを作るのは完成度を高めるためではなく、考えるための足場を外側に置くため」というスタンスは、認知負荷の観点からも整合しています。 - 段階的情報開示（Progressive Disclosure） 一度にすべての情報を提示しない。これは直感に反しますが、認知負荷の観点からは合理的な設計原則です。段階的情報開示とは、ユーザーの現在の目的・文脈・習熟度に応じて、必要な情報だけを順番に提示する手法です。 実装のかたちは多様です。ウィザード形式（複数ステップへの分割）、アコーディオン（詳細を折り畳み）、コンテキストヘルプ（疑問が生じた場所に補足を置く）——これらはいずれも「今この瞬間に不要な情報を作業記憶から遠ざける」設計です。 - チャンキングによる情報構造化 バラバラな情報をひとまとめの「かたまり（チャンク）」として提示することで、作業記憶の消費を減らせます。電話番号を「090-1234-5678」と区切るのはその典型例です。ユーザーインターフェース設計であれば、関連する機能をグループ化し、視覚的な境界でまとめること。情報アーキテクチャであれば、カテゴリの粒度を揃え、ラベルを予測可能にすること。 デザイン思考のワークショップ設計においても同じ原則が働きます。発散的な思考を付箋に書き出し、その後にクラスタリングする流れは、外在的負荷を一時的に外部（付箋の壁）に預けながら、関連的負荷（構造の発見）に集中させる認知設計として機能しています。 「頭を使わせすぎない」は配慮ではなく設計の精度 認知負荷を下げることは、利用者を「頭を使わない受動的な存在」として扱うことではありません。むしろ逆です。本当に使ってほしい思考（判断・創造・学習）に認知資源を向けるために、不要な負荷を削り取ること——それが認知負荷設計の実践的な意味です。 人間中心設計の眼差しは、「なぜこの人は使えないのか」ではなく「どこが使えなくしているのか」に向きます。認知負荷という概念は、その問いを立てるための、実務に根ざした言語のひとつです。 --- 参考文献 - George A. Miller, "The Magical Number Seven, Plus or Minus Two," Psychological Review, 63(2), 1956 - John Sweller, "Cognitive Load During Problem Solving: Effects on Learning," Cognitive Science, 12(2), 1988 - John Sweller, Paul Ayres, Slava Kalyuga, Cognitive Load Theory, Springer, 2011 --- ### 発散思考と収束思考 URL: https://designthinking.studio/glossary/divergent-convergent-thinking/ > 発散思考と収束思考はデザイン思考の根幹をなす2つのモード。同時併用は不可能で交互反復が創造を生む原理、ダブルダイヤモンドとの対応、ワークショップでモード混在を防ぐグリーンライト・レッドライト原則を体系解説。 デザイン思考のプロセスは、発散（Divergent）と収束（Convergent）という2つの思考モードの交互反復として理解できます。ダブルダイヤモンドの4象限も、発散→収束→発散→収束という4つのフェーズを可視化したものです。 2つのモードの定義 発散思考（Divergent Thinking）は、可能性を広げる思考モードです。与えられた問いに対して、できるだけ多くの選択肢・視点・アイデアを生み出すことを目的とします。評価・判断・絞り込みは行わない。「正しいかどうか」ではなく「面白いかどうか」「多様かどうか」を基準に動きます。 収束思考（Convergent Thinking）は、可能性を絞る思考モードです。発散によって生み出された選択肢の中から、基準・制約・目的に照らして最も有望なものを選び取る思考です。評価・比較・判断が主な活動になります。 この2つのモードは同時に使えません。 発散している最中に「でもこれは現実的ではない」と評価するのは収束の介入です。収束の最中に「もっと他の選択肢はないか」と探索するのは発散の介入です。どちらの介入も、それぞれのモードの効果を弱めます。 デザイン思考のファシリテーションで最も重要なスキルの一つは、チームが今どちらのモードにいるかを常に把握し、モードの混在を防ぐことです。 なぜ交互反復が必要か 発散だけでは、選択肢の海で溺れます。収束だけでは、最初に思いついた解決策から抜け出せません。 創造的な問題解決が必要とされる局面で、多くのチームは「最初に合意できた案」に収束してしまいます。これは収束のプレッシャーが常に強いからです。不確実性は不快であり、「案がまだない」状態は心理的に不安定です。早く収束することで、その不快を解消しようとする引力が常に働いています。 デザイン思考が意識的に発散フェーズを構造として設けるのは、この引力に対抗するためです。発散は「まだ答えを出してはいけない」という許可を明示的に組織することで、より広い選択肢の探索を可能にします。 同時に、発散だけでは意思決定に至れません。創造的な組織が「アイデアを出すだけで実行しない」という批判を受けるとき、多くの場合は収束の構造が弱いことが原因です。発散で広げた後、どの基準で何を選ぶかを明確にして収束する構造が、創造性を実行に変えます。 ダブルダイヤモンドとの対応 ダブルダイヤモンドの4フェーズは、発散・収束の2サイクルとして読み解けます。 第1ダイヤモンド（問題の探索と定義） 「発見（Discover）」フェーズは発散です。ユーザーリサーチ・観察・インタビューによって、可能性の広い問題空間を探索します。何が問題かを決めずに、広く観察する。 「定義（Define）」フェーズは収束です。収集したリサーチ結果を分析し、「最も取り組む価値がある問題はどれか」を絞り込む。POV文という形で問いを一点に収束させます。 第2ダイヤモンド（解決策の探索と実装） 「開発（Develop）」フェーズは発散です。定義された問いに対して、可能な限り多様な解決策のアイデアを生み出す。ブレインストーミング・ブレインライティング・アナロジー思考などがこのフェーズの手法です。 「実現（Deliver）」フェーズは収束です。生み出されたアイデアを評価・プロトタイプ・テストを通じて絞り込み、実装するものを決定します。 ワークショップでの観察 発散・収束の切り替えを意識したワークショップと、そうでないワークショップとでは、アウトプットの質が明確に異なります。 最も頻繁に観察される問題は「評価的な発言が発散フェーズに混入する」ことです。ブレインストーミング中に「それは予算的に難しい」「うちの組織では無理」「以前試したが失敗した」という発言が出ると、その後のアイデア量が急落します。発散フェーズでの評価的介入は、心理的安全性を損ない、参加者が「評価に耐えられるアイデアしか発言しない」モードに移行させます。 逆に「収束フェーズでの発散」も問題です。投票でアイデアを選ぼうとしている最中に「もっとアイデアを出すべきでは」という声が繰り返されると、意思決定が宙に浮き、チームは消耗します。収束の局面でよく効くのは「選ばなかったアイデアを捨てているのではなく、今は保留にしているだけ」というフレーミングです。アイデアへの愛着が、収束の邪魔をすることを忘れてはいけません。 ファシリテーターの実践的なアプローチとして、「発散モード」「収束モード」の看板を物理的に掲げる方法があります。 今どちらのモードにいるかを視覚的に示すことで、評価的な発言が出たときに「今は発散モードです。評価は収束フェーズでやりましょう」と誘導しやすくなります。 「グリーンライト・レッドライト」の原則 デザイン思考の実践コミュニティで広く使われる実践的なフレームとして「グリーンライト・レッドライト」があります。 グリーンライト（発散）：アイデアを出すフェーズ。量を優先する。判断しない。「そうは言っても」「でも」という言葉を禁止する。代わりに「さらに言えば」「それに加えて」を使う。 レッドライト（収束）：アイデアを選ぶフェーズ。基準に照らして評価する。「なぜこれが良いか」を言語化する。 この2色のライトの比喩は、チームが「今どちらのモードにいるか」を直感的に共有するのに有効です。 創造的な問題解決の本質は、発散の豊かさと収束の厳密さを、適切なリズムで交互に使うことです。どちらか一方だけでは、創造性か実行力の、どちらかを失います。2つのモードを意識的に使い分ける能力そのものが、デザイン思考の実践者が身につけるべき中核的なスキルです。 --- 参考文献 - Guilford, J.P., "Creativity", American Psychologist, Vol.5, No.9, 1950（発散思考概念の源泉） - Design Council, The 'Double Diamond' Design Process Model, Design Council, 2004 - Brown, Tim, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperCollins, 2009 - Kelley, Tom & Kelley, David, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 --- 関連項目 - ダブルダイヤモンド - ブレインストーミング - How Might We（どうすれば） - アブダクション（仮説的推論） - デザイン思考 --- ### 問題フレーミング URL: https://designthinking.studio/glossary/problem-framing-guide/ > デザイン思考の定義フェーズにおける核心的な思考作業。「どの問題を解くか」を意図的に選択・再定義することで、解決策の質と方向性を決定する思考技術。フレームを変えるだけで、まったく異なる解決策空間が開かれる。 問題フレーミングとは、「どの問題を、どう定義して解くか」を意図的に選択・設計する思考プロセスです。デザイン思考の定義（Define）フェーズの核心をなす概念であり、フレームの選び方が解決策の方向性を根本的に決定します。 なぜ問題フレーミングが重要か デザイン思考の実践において、最も犯しやすい誤りのひとつは「問題を正しく定義する前に解決策を考え始める」ことです。 古典的な例として、エレベーターの待ち時間に関する問題があります。「エレベーターの待ち時間を短くするにはどうするか」という問いを立てると、解決策は「エレベーターを増設する」「制御システムを最適化する」という高コストな方向に向かいます。しかし「エレベーター待ちに感じる不満をなくすにはどうするか」と問いを変えると、「各フロアに鏡を設置する（待ち時間の認知を変える）」という低コストで効果的な解決策が生まれます。 フレームを変えることで、まったく異なる解決策の空間が開きます。問題フレーミングはこの「フレームの選択を意識的・意図的に行う」思考技術です。 フレームの3つの次元 問題フレーミングには、3つの次元からのアプローチがあります。 - 問題の境界を変える（拡大・縮小） 問題の定義を広げることで、より根本的な原因にアクセスできます。一方、狭めることで行動可能な具体的問題を特定できます。 境界を広げる例：「ユーザーがアプリのXボタンを押せない」→「ユーザーがアプリで目的のアクションを完了できない」→「ユーザーがサービスで達成したいことを達成できない」 境界を縮める例：「顧客満足度が低い」→「初回来店顧客の再来店率が低い」→「初回来店後3日以内のフォローアップが存在しない」 - 問題の視点を変える（ステークホルダーシフト） 誰の視点から問題を見るかによって、問題の定義は変わります。 - 顧客の視点：「なぜ私のニーズが満たされないのか」 - スタッフの視点：「なぜ正しいサービスを提供できないのか」 - 組織の視点：「なぜこのプロセスがうまく機能しないのか」 - 社会の視点：「なぜこの問題が繰り返し発生するのか」 視点を変えることで、同じ「事実」の異なる解釈と、それぞれに対応した異なる解決策が見えてきます。 - 問題の時間軸を変える（予防・対処・改善） 現在発生している問題の「対処」だけでなく、問題の「予防（なぜ起きているのかの上流）」や、問題の「構造的解決（再発しない仕組み）」という時間軸でフレームを変えることができます。 実務でのフレーミング手法 How Might We（HMW）によるリフレーミング How Might Weは問題フレーミングの最も実践的なツールです。「どうすれば〜できるか？」という問いの形が、問題を「解ける課題」として再定義します。 HMWを複数の粒度で書き比べる実践が有効です。「どうすれば待ち時間を短くできるか」「どうすれば待ち時間を快適にできるか」「どうすれば来院自体を最小化できるか」という3つのHMWは、それぞれ異なる解決策空間を開きます。チームで複数のHMWを書き、どれを解くかを選ぶプロセス自体が問題フレーミングの実践です。 「なぜ？」の連鎖と「どうすれば？」の連鎖 5 Whysで問題の上流（根本原因）に向かって問いを深める一方、HMWで解決策の空間を広げる方向に問いを展開する。この両方向の問いの連鎖が、問題フレーミングの基本的な思考作業です。 ポイント・オブ・ビュー（POV）文との連携 POV文は「誰の・どんなニーズを解くか」を定義します。POV文が完成すると、問題フレーミングの文脈（ユーザー・ニーズ・インサイト）が揃い、HMWへの変換が自然に進みます。 フレーミングの罠 解決策に引きずられたフレーミング 最も頻出する罠は「すでに持っている解決策に有利なフレームで問題を定義する」ことです。「デジタル化することを前提に、どう問題を定義するか」という逆算的なフレーミングは、他の解決可能性を最初から排除します。 問いを立てる前に「このフレームは、特定の解決策に有利になっていないか？」を確認します。 問題の過度な単純化 複雑な社会・組織の問題を「シンプルな問い」に変換しすぎると、本質的な複雑性が失われます。厄介な問題（Wicked Problem）は、単純化されたフレームでは解けません。問題の複雑性を保ちながら、行動可能な切り口を選ぶバランスが求められます。 最初のフレームへの固執 問題定義は一度決めたら固定するものではありません。プロトタイプ・テストの結果から「問題の定義が違った」と分かった場合、フレームを更新することが重要です。デザイン思考のプロセスは反復的（Iterative）であり、問題定義の更新はプロセスの失敗ではなく学習です。 設計哲学としての問題フレーミング 「どの問いを選ぶかが、どの答えに到達できるかを決定する」——これが問題フレーミングの根幹にある認識論です。 デザイン研究者のNigel Crossは、優れたデザイナーと普通のデザイナーの差は「問題を解く能力」よりも「問題を見つけ・定義する能力」にあることを複数の研究で明らかにしています。問題を解くのは難しい。でも問題を正しく定義できれば、解決策は比較的自然に見えてくる。 デザイン思考が「問題定義フェーズ」を独立したフェーズとして設定している理由はここにあります。プロセスの飾りではなく、プロセスの核心です。 --- 参考文献 - Cross, Nigel, Design Thinking: Understanding How Designers Think and Work, Berg Publishers, 2011 - Dorst, Kees, Frame Innovation: Create New Thinking by Design, MIT Press, 2015 - Rowe, Peter G., Design Thinking, MIT Press, 1987 - Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018 - Brown, Tim, Change by Design, HarperBusiness, 2009 --- ## 書籍 ### 『SPRINT 最速仕事術』要約と運用——Google Venturesの5日間プロセス URL: https://designthinking.studio/books/sprint-jake-knapp-summary/ > Google Ventures（現GV）の5日間スプリント手法を全章要約。月曜から金曜の具体的アクティビティと、実際の組織への導入で機能させるための判断ポイントを体系的に解説する。 「このアイデアが本当に機能するかどうかを、数ヶ月かけて開発してから検証する」——このアプローチがいかに非効率かは、多くのプロジェクトマネージャーが経験として知っている。だが「ではどうすれば早く検証できるか」という問いへの構造的な答えは、多くの現場に存在しない。 Jake Knappが2016年に著した『SPRINT』は、この問いに「5日間で答えを出す」という具体的なプロセスを提示した書籍だ。 Google Ventures（現GV）で100社以上のスタートアップ支援を通じて磨かれたこの手法は、デザイン思考の実行フレームワークとして現在も広く参照されている。 --- 書籍概要 著者の背景と執筆動機 Jake Knappは、GmailやGoogle Meetの前身となるプロダクト開発を経て、Google VenturesでデザインパートナーとしてKhosla Ventures、Slack、Medium、Blue Bottle Coffeeなどへの投資先支援を担当した。 John ZeratskyはGoogleでYouTubeやGoogle NewsのUX設計を担当し、後にGVのデザインパートナーとなった。Braden KowitzはGVのデザインパートナーとして投資先への直接支援に従事した。 3人が共著した理由は、スプリントが特定の天才の産物ではなく、「誰が使っても再現可能なプロセスとして設計されているから」だ。本書の構成もその思想を反映しており、月曜から金曜の5日間それぞれの具体的なアクティビティを、読んで即実行できるレベルで記述している。 書籍の核心主張 「5日間で、アイデアの実現可能性を顧客反応で検証できる」 — この主張の根拠は、「リアルな意思決定には締め切りが必要であり、5日という期限が最も高い質の議論と実行を引き出す」という観察だ。 スプリントが単なる「速いプロトタイピング手法」ではない点は、本書全体を通じて強調される。スプリントは「正しい問題を解いているかどうかを5日間で確かめるプロセス」であり、問題定義から顧客検証まで一気通貫で行う設計になっている。 --- 章別要約 序章：スプリントとは何か Knappは冒頭で、スプリントを次のように定義する。「重要な問いに答えを出し、アイデアを検証するための5日間のプロセス。チームで集まり、プロトタイプを作り、実際の顧客でテストする。」 この定義の中で最も重要なのは「重要な問いに答えを出す」という部分だ。スプリントはタスク消化の手法ではなく、「このプロジェクトで最も重要なリスクは何か、そのリスクを5日間でどう検証するか」という問いへの答えを設計する思考プロセスだ。 本書の冒頭で紹介されるBlue Bottle Coffeeの事例は、スプリントの射程を象徴している。オンラインストアの開設という判断を前に、「どうUI設計するか」ではなく「そもそも何を売るべきか」という問いをスプリントで扱った結果、当初の仮定が全面的に覆った。最初の問い設定の質が、スプリント全体の価値を決めるという原則がここに示されている。 --- 月曜日：マップと目標設定 月曜日のゴールは「5日間で集中すべき問題を1つに絞り込む」ことだ。 アクティビティ1：最終ゴールの設定 チーム全員で「6ヶ月後にどういう状態になっていたいか」を言語化する。この問いは曖昧に聞こえるが、目的は「5日間の出口」を全員で共有することだ。ゴールが共有されていないチームは、火曜日以降のスケッチや意思決定の場で、議論が噛み合わなくなる。 アクティビティ2：マップ作成 問題全体の「地図」を紙1枚に描く。登場人物（ユーザー・意思決定者・サポートスタッフなど）と、彼らがたどるプロセスの流れを簡略に示す。ここで重要なのは「完璧な地図を作ること」ではなく、「チーム全員が同じ現実認識を持つこと」だ。 アクティビティ3：専門家インタビュー（HMW付箋） 月曜日の午後は、関連する専門家（自社の営業担当、技術担当、ユーザーリサーチ担当など）から短いブリーフィングを受ける。各自が聞きながら気づいたことを「HMW（How Might We = どうすれば〜できるか）」の形式で付箋に書き出す。 この付箋をまとめて投票で優先度をつけ、月曜日の最後に「スプリントの焦点エリア」を地図上で1箇所に絞る。この絞り込みが、火曜日以降の生産性を大きく左右する。 --- 火曜日：スケッチ 火曜日のゴールは「解決策の候補を個人ベースで発散させる」ことだ。 4段階のスケッチプロセス Knappは「グループでのブレインストーミングは質より量に傾き、声の大きい人のアイデアが採用されやすい」という問題を指摘する。その代替として、個人が独立してスケッチし、後で比較するプロセスを設計した。 具体的には4段階で進む。第1段階はメモ（20分）、第2段階はアイデアの粗い図（20分）、第3段階は8コマ漫画（8 Crazy 8s、各コマ1分で8案）、第4段階は詳細なソリューションスケッチ（30〜90分）。 8 Crazy 8sは、一つのアイデアを8つのバリエーションに展開するエクササイズだ。「最初に思いついたアイデアが最善とは限らない」という前提に立ち、制約時間内に強制的に代替案を生成する。実際にやってみると、最初の3つは同じアイデアの繰り返しになりやすいが、4つ目以降に質の異なるアイデアが生まれることが多い。 --- 水曜日：意思決定 水曜日のゴールは「火曜日のスケッチからプロトタイプに進む1つのアイデアを決定する」ことだ。 ヒートマップ投票とスーパー投票 全員のスケッチをギャラリーのように壁に貼り出し、無言で見て回る。気になる部分にシール（ドット投票）を貼る「ヒートマップ」の後、デシジョンメーカー（最終権限者）が最終案を決める「スーパー投票」を行う。 この二段階構造の設計には意図がある。ヒートマップはチーム全員の視点を反映するが、最終決定はデシジョンメーカー1人が行う。民主的なプロセスと明確な意思決定責任を分離している点が重要だ。コンセンサスで決めようとすると、最も尖ったアイデアが削られて平均的な案に収束する傾向があるからだ。 ランブルとリメックス 複数の有望案が残った場合、2つを並行してプロトタイプする「ランブル」を選択できる。あるいは複数案の良い部分を組み合わせる「リメックス」も有効だ。ただしKnappは、迷ったら1案に絞ることを推奨している。並行案は集中力を分散させるためだ。 ストーリーボード作成 水曜日の午後は「ストーリーボード」作成で終わる。プロトタイプの設計図を、ユーザーが最初に接触してから終了するまでの流れ（10〜15コマ程度）で描く。このストーリーボードが木曜日のプロトタイプ作成の設計図になる。 --- 木曜日：プロトタイプ 木曜日のゴールは「金曜日のテストに使えるリアルなプロトタイプを1日で作る」ことだ。 「リアルさ」の定義 スプリントのプロトタイプが持つべき「リアルさ」とは、実際に動作することではなく、「ユーザーが本物と思って反応できる精度」だ。コードを書く必要はない。Keynote・PowerPoint・InVision・Figmaのようなプレゼンテーションツールやプロトタイピングツールで作った「見た目が動くもの」で十分だ。 役割分担と「タイムマシン」 木曜日は明確な役割分担で並走する。メーカー（コンテンツ制作担当）、スティッチャー（各パーツを繋げる担当）、ライター（テキストコピー担当）、アセットコレクター（画像・素材収集担当）、インタビュアー（金曜日のインタビュー準備担当）。 完成度よりも「ゴールデンパス」 木曜日で最も重要な判断は「ゴールデンパスを守る」ことだ。ゴールデンパスとは、ユーザーがプロトタイプを通じて辿るべき理想的な経路のこと。このパスに関係しない部分はリアルさを追求しない。「どこまで作り込むか」を常にゴールデンパスとの関連性で判断することが、1日でプロトタイプを完成させる鍵だ。 --- 金曜日：テスト 金曜日のゴールは「5人の実際のユーザーにプロトタイプをテストし、明確な洞察を得る」ことだ。 なぜ5人か Nielsenのユーザービリティ研究をもとに、Knappは5人のテストで「主要な問題の85%が発見できる」という経験則を示す。6人目以降は新しい洞察が急速に減少する。5人というのは「必要十分」の設計であり、これ以上増やすと分析の複雑さが増すだけだとKnappは主張する。 インタビュー設計の5段階 インタビューは5段階で構成する。(1)アイスブレイク（5分）、(2)背景把握の質問（10分）、(3)プロトタイプ紹介（1分）、(4)タスクと観察（中核、20〜25分）、(5)振り返りの質問（5分）。 最も重要なのは(4)の観察段階で「考えを声に出してください（Think aloud）」という指示だ。ユーザーが何を見て、何に迷い、何に反応するかをリアルタイムで把握できる。インタビュアーはファシリテーターに徹し、問題を解決しようとしてはいけない。 パターンの発見 チームの他のメンバーは別室で観察し、気づいたことを付箋にメモする。5人のインタビュー後、全員で壁の付箋を整理して「複数のユーザーに共通するパターン」を抽出する。スプリントの結果は「成功」「失敗」ではなく、パターンから次に何をすべきかを判断することだ。 --- 実装ガイド：現場でスプリントを機能させるために スプリントが機能する条件 本書の後半は、スプリントを実際に組織で動かすための実践知識に充てられている。 デシジョンメーカーの参加は必須 スプリントで最も頻繁に起きる失敗は、意思決定権者がスプリントに参加しないケースだ。「多忙なので途中だけ顔を出す」という形は機能しない。水曜日のスーパー投票でデシジョンメーカーが不在だと、全員が権限なしで最終案を決めることになり、組織への実装が後続しなくなる。 「ノーデバイス・ルール」の実行 スプリント中、スマートフォン・PCはスプリント関連作業以外に使用しない。Knappはこのルールを「スプリントの一番難しいルール」と認めつつ、5日間の集中を実現する最も効果的な単一手段として強調する。会議室のWiFiパスワードを変えてしまうという荒療治も紹介されている。 チームサイズは7人以下 スプリントに参加する人数は最大7人が推奨される。8人以上になると、意思決定のスピードが落ちる。「すべての関係者を参加させる」のではなく、「この5日間で必要なスキルと権限を持つ最小のチームを構成する」という発想が必要だ。 日本の現場への適応ポイント スプリントを日本企業で実行する際に特有の障壁が3つある。 第一の障壁：デシジョンメーカーの時間確保 日本の上位職は、5日間連続でブロックすることを「贅沢」と感じる場合が多い。現実的な対処法は、月曜日と水曜日だけ参加するという変形スプリントだ。問題設定の月曜と意思決定の水曜に絞れば、最低限の権限者参加が確保できる。ただし、これはコア設計からの妥協であることを認識した上で選択する。 第二の障壁：「ノーデバイス・ルール」への抵抗 日常的に即応を求められる文化では、デバイス断絶に強い抵抗がある。「緊急連絡は別途対応する仕組みを用意する」という前提を共有した上で、スプリント空間とそれ以外の空間を物理的に分けることが有効だ。 第三の障壁：プロトタイプの品質への執着 日本の現場では「これは本物じゃないから恥ずかしい」という反応でプロトタイプの作り込みに時間を取られやすい。金曜日のテスト参加者への説明で「これはアイデアのスケッチです」と明言する文化をチームに定着させることが、この障壁への最も直接的な対処法だ。 スプリントの射程：何に使えて何に使えないか スプリントは万能ではない。Knappが本書で認めているように、スプリントが機能しやすい問いと機能しにくい問いがある。 スプリントが機能しやすい条件： - 問題が明確に1つに絞れる - ユーザーにアクセスできる（5人のテスト参加者を金曜日までに集められる） - チームが5日間物理的に集まれる - 意思決定権者がコミットできる スプリントが機能しにくい条件： - 問題が複数の部門・システムにまたがり定義できない - 組織の政治的な問題が課題の中心にある - プロトタイプが物理的製品の場合（製造コスト・時間的制約） - ユーザーへのアクセスが構造的に難しい スプリントを「全問題に使えるハンマー」として扱うと、機能しない場面での失望が、手法全体への不信につながる。「この問いはスプリントに適切か」という判断が、スプリント開始前の最も重要なステップだ。 --- 2026年時点での本書の位置づけ 2016年の出版から10年が経過した。スプリントは「最新手法」から「確立された実践フレームワーク」に移行している。Miro・FigJam・Notionの普及で、リモートスプリントの実行難易度は大幅に下がった。 ただし本書の本質的な価値——「5日間という制約で問題設定から顧客検証まで一気通貫で行う構造」——は変わっていない。AIツールの登場でプロトタイプ作成コストが下がった今、スプリントの「検証速度を最大化する」という思想はむしろ重要性を増している。 2020年以降、Knappらは「デザインスプリント2.0」として月曜・火曜の合体とフレームワークの簡略化を提案している。4日間に短縮された改訂版は、特に中規模プロジェクトでの実行コストを下げる観点で注目に値する。 本書を読む際は、第1〜5章（月〜金の各アクティビティ）を実行手順として、後半の実践アドバイス章を「なぜそのルールがあるか」の理由として読み分けることを勧める。手順だけ追うと形式の実行になりやすいが、理由を理解した上で実行すると、自社文脈への適応判断ができるようになる。 --- --- 関連記事・参考文献 関連記事 - ホースト・リッテルとWicked Problems——問題定義の理論的根拠 - デザイン思考実践者のバーンアウト構造と予防 - デザイン思考の限界と可能性 引用・参考文献 - Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. Simon & Schuster.（邦訳:『SPRINT 最速仕事術——あらゆる仕事がうまくいく最も合理的な方法』ダイヤモンド社） - Nielsen, J. (2000). Why You Only Need to Test with 5 Users. Nielsen Norman Group. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. 200回以上のワークショップを通じて見えてきたことがある。 スプリントが「日本の現場で機能しない」と言われる多くのケースは、5日間のアクティビティの問題ではなく、「デシジョンメーカーが不在」か「問いの設定が甘い」かのいずれかに帰着する（デザイン思考ワークショップのファシリテーション経験に基づく観察）。本書の後半に詰め込まれた実践知はその意味で最も重要なセクションだ。 --- ### 『The Design of Everyday Things』完全解説 — ノーマンの「使いやすさ」の科学 URL: https://designthinking.studio/books/the-design-of-everyday-things/ > 「なぜドアの取っ手を引くべきか押すべきかわからないのか」という日常の謎を出発点に、優れたデザインの原則を体系化した古典的名著。人間中心設計（HCD）の理論的基盤として、デザイン思考実践者が必ず読むべき一冊。 ドアを前にして、引くべきか押すべきか迷った経験は誰にでもある。コンロの4つのつまみを見て、どれがどのバーナーに対応するか瞬時に理解できないコンロを前に戸惑った経験も同様だ。 Donald Norman（ドナルド・ノーマン）は、こうした「使いにくさ」の原因は使う人の側にあるのではなく、デザインの側にあると主張した。1988年の初版発行以来、『The Design of Everyday Things』はデザイン思考の理論的礎として読み継がれてきた。 --- 書籍の概要 誕生の背景 初版は1988年、『The Psychology of Everyday Things』として刊行された。その後1990年に改題、2013年には大幅加筆の改訂版が出版された（日本語訳の新版は2015年、新曜社刊）。 著者のドナルド・ノーマンは認知科学者であり、UC San Diego、Apple（アドバンスト・テクノロジー・グループ担当副社長）、NNグループ共同設立者、ノースウェスタン大学教授という経歴を持つ。本書は彼の認知科学の知見を、日常の物理的なモノのデザインへと接続した作品だ。 核心のメッセージ 「使いにくいのは、使う人の問題ではなくデザインの問題だ」 — この一文が本書の全てを要約している。 ワークショップでよく起こるのは、参加者が「うちのユーザーはリテラシーが低いから使いこなせない」と語る場面だ。しかしノーマンの視点から見れば、これは思考の逆転が必要な瞬間。ユーザーが使えないのではなく、デザインがユーザーを想定していないのだと。 --- 6つの設計原則 ノーマンは、優れたデザインに共通する6つの原則を定義している。 - アフォーダンス（Affordance） アフォーダンスとは、物の形や素材が「こう使える」という手がかりを自然に提示する性質だ。椅子は座ることを、取っ手は引くことを、平らな板は押すことをアフォードする。 問題は「知覚されないアフォーダンス」にある。 デザイナーが意図した使い方が、見た目から伝わらない時、ユーザーは迷う。ガラスのドアに「PUSH」と書いてある時点で、そのデザインは失敗している。 - シグニファイア（Signifier） シグニファイアはアフォーダンスを知覚可能にする信号だ。ボタンに描かれた矢印、ドアの縁の形状、コンロのつまみの配置がこれにあたる。 実際にやってみると、シグニファイアのない製品がいかに多いかに気づく。インターフェースデザインの現場でも同じことが起きている。クリックできる要素とできない要素を、色や形で区別しないUIは、デジタル版の「押すべきか引くべきかわからないドア」だ。 - 対応づけ（Mapping） 対応づけとは、コントロールと結果の空間的・概念的な関係だ。4つのバーナーを正方形に配置したコンロで、4本のつまみが一列に並んでいれば、どのつまみがどのバーナーを制御するかは直感的にわからない。 対応づけが自然であれば、説明書を読まずに操作できる。 これが「ベストなデザインは説明が不要」という原則の根拠だ。 - フィードバック（Feedback） フィードバックとは、操作が実行されたことを知らせる応答だ。ボタンを押した時のクリック感、スイッチを入れた時のランプ、フォームを送信した時の確認画面。 フィードバックがなければ、ユーザーは「操作が受け付けられたのか」がわからず不安になる。ワークショップでプロトタイプをユーザーテストすると、フィードバックの欠如が混乱の最大の原因になることが多い。 - 概念モデル（Conceptual Model） 概念モデルとは、ユーザーが製品の動き方について持つ精神的なイメージだ。「フォルダにファイルを入れる」というコンピュータの比喩は、物理的な整理棚の概念モデルを借用している。 デザイナーの概念モデルとユーザーの概念モデルが一致しない時、使いにくさが生まれる。 デザイン思考の共感フェーズでユーザーリサーチが重要なのは、まさにこのギャップを発見するためだ。 - 制約（Constraint） 制約とは、可能な操作を意図的に制限することで、誤操作を防ぐ設計だ。USBコネクタが特定の向きにしか差し込めないこと（物理的制約）、削除の確認ダイアログが出ること（論理的制約）などがその例だ。 --- デザイン思考との接続 人間中心設計（HCD）の理論的基盤 ドナルド・ノーマンは本書の中で「人間中心設計（Human-Centered Design）」という概念を提唱した。ユーザーのニーズ・能力・行動を理解し、その理解をデザインの中心に置くという思想は、デザイン思考の根本的な哲学と一致する。 デザイン思考の5ステップ（共感→定義→創造→プロトタイプ→テスト）の全体が、ノーマンの原則と照応している。共感フェーズはユーザーの概念モデルを探り、プロトタイプフェーズはアフォーダンスとシグニファイアを試し、テストフェーズはフィードバックと対応づけを検証する。 行動の7段階モデル 改訂版で詳述された「行動の7段階モデル」は、実践的なデザインの評価ツールとして使える。 - 目標を形成する（ゴールを持つ） - 何をすべきかを計画する - 行動の順序を決定する - 行動を実行する - 外界の状態を知覚する - 知覚を解釈する - 結果を評価して目標と照合する ワークショップでよく起こるのは、製品の「4. 行動を実行する」の部分だけを設計して終わるケースだ。「1. 目標を形成する」から「7. 結果を評価する」まで、ユーザーの行動全体を設計対象として見る視座が必要だ。 失敗設計の3類型 ノーマンは設計の失敗パターンを明確に分類している。 スリップ（Slip）: ユーザーが正しい目標を持ちながら、実行の段階でミスをする。「送信」と「削除」のボタンを隣に配置するデザインはスリップを誘発する。 ミステイク（Mistake）: ユーザーが誤った目標を設定する。概念モデルがシステムの実際の動作と異なる時に起きる。 これらは「ユーザーのヒューマンエラー」ではなく「デザインエラー」だという視点が、本書の革命的な点だった。 --- 実務への示唆 プロトタイプ評価のチェックリスト 本書の原則は、デザイン思考のプロトタイプ評価に直接使える。 - アフォーダンス: 操作方法が見た目から伝わるか - シグニファイア: 操作可能な要素が視覚的に明示されているか - 対応づけ: コントロールと結果の関係が直感的か - フィードバック: 操作の結果が適切に伝わるか - 概念モデル: ユーザーの精神的イメージと一致しているか - 制約: 誤操作を防ぐ仕組みが設計されているか 実際にやってみると、このチェックリストを持ってユーザーテストに臨むだけで、観察すべきポイントが明確になる。「うまく使えていない」ではなく「アフォーダンスが伝わっていない」「対応づけが複雑すぎる」と問題を分類して言語化できる。 ワークショップでの応用 参加者からの声として「ユーザビリティの問題だと思っていたものが、実はデザインの問題だとわかった」という気づきは、本書の考え方を一度でも体験した人から繰り返し聞かれる。 本書を読んだ後の最初の実践は、自分のオフィスや自宅の「使いにくいもの」を10個挙げることだ。 ドアノブ、コピー機の操作パネル、会議室の照明スイッチ。それらを「なぜ使いにくいのか」をノーマンの言語で分析する練習が、デザイン思考の「観察眼」を鍛える最短ルートになる。 --- こんな人に読んでほしい プロダクトマネージャーやUXデザイナーはもちろん、デザイン思考を学び始めた全ての実務者に読んでほしい一冊だ。特に「なぜデザイン思考ではユーザーリサーチが重視されるのか」という問いに悩む人にとって、本書はその根拠を理論的に整理してくれる。 また、組織内でデザイン思考の導入を推進している人にとっては、「ユーザーが悪い」という議論をデザインの問題へと転換するための語彙と論理を提供してくれる。 --- 書誌情報 - Donald A. Norman, The Design of Everyday Things (Revised and Expanded Edition), Basic Books, 2013, ISBN: 978-0465050659 - 日本語版: D.A. ノーマン（著）、岡本明・安村通晃・伊賀聡一郎・野島久雄（訳）『誰のためのデザイン？ 増補・改訂版』新曜社、2015年、ISBN: 978-4788514348 --- 参考文献 - Donald A. Norman & Stephen W. Draper (eds.), User Centered System Design: New Perspectives on Human-Computer Interaction, Lawrence Erlbaum Associates, 1986（HCDの概念を先行提唱した論文集） - Jakob Nielsen, Usability Engineering, Academic Press, 1993（ノーマンと並んでユーザビリティ研究を牽引した書籍） - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009（デザイン思考をビジネス戦略として展開した書籍） - Donald A. Norman, "Human-Centered Design Considered Harmful," Interactions, Vol. 12, No. 4, ACM, 2005（ノーマン自身によるHCDへの批判的省察） - Don Norman & Jakob Nielsen, "The Definition of User Experience (UX)," Nielsen Norman Group, 2007（UXという概念の定義） --- ### 『This is Service Design Doing』要約——5原則と実装ガイド URL: https://designthinking.studio/books/this-is-service-design-doing-summary/ > サービスデザインの実務的バイブル。前著『This is Service Design Thinking』の「考え方」を、「実際にどうやるか」へと深化させた実装ガイド。5原則・方法論・ファシリテーション技法を750ページに凝縮。 『This is Service Design Doing』（2018）は、サービスデザイン分野の実践的標準書です。Marc Stickdorn、Markus Edgar Hormess、Adam Lawrence、Jakob Schneider の4名が共著し、「サービスデザインを知っている状態」から「実際に組織で動かせる状態」へのギャップを埋めることを目的に書かれました。 前著『This is Service Design Thinking』（2010）が「考え方」を示したとすれば、本書はその「Doing（実行）」編。ツール・ファシリテーション・チームビルディング・変革マネジメントまでを一冊に統合しています。 サービスデザインの5原則 本書の理論的骨格は、サービスデザインを定義する5つの原則です。これはデザイン思考の実践者が「体験の設計」に踏み込む際の指針にもなります。 - 人間中心（Human-Centered） 顧客・従業員・パートナー——サービスに関わる全ての人の体験を調査・理解することを出発点にします。共感フェーズの実践そのものであり、「仮定からではなくリサーチから始める」という規律。誰のために設計するかを、常に現実の人間観察から導き出す。これが5原則の根幹です。 - 協働的（Collaborative） マーケティング・IT・オペレーション・フロントライン・経営層、異なる部門の人々を同じプロセスに巻き込みます。「デザインチームが設計して引き渡す」モデルではなく、関係者全員が共同制作者（Co-creator）として参加することで、実装時の摩擦を減らします。 ワークショップ設計・ファシリテーション・コ・クリエーションセッションが、この原則を実現する手法です。 - 反復的（Iterative） 完璧な解を一度で出そうとしない。小さなプロトタイプを素早く作り、現実のユーザー反応から学ぶことを組織のリズムにします。「失敗は学習コスト」——この前提が、このフェーズを支えます。 - 連続的（Sequential） サービスは時間軸の中で体験されます。本書は、サービスの全接点を「シーン（サービスシアターの場面）」として可視化することを推奨します。認知から購買・利用・解約・再購入に至るまでの時間軸を設計することが、一点の優れた機能よりも重要です。 サービスブループリントとカスタマージャーニーマップが、この「連続性」を設計する主要ツールです。 - 実物（Real） 調査も設計もプロトタイプも、「現実の文脈・現実の人・現実の素材」で行う原則です。ペルソナや統計データを参照しつつも、実際のユーザーと対話し、実際の環境を観察し、動くサービスのモックを作ることを重視します。リアルであることが、思い込みを排除する最良の方法。 章別構成と要点 Part 1: Why（なぜサービスデザインか） サービス経済の拡大と、機能改善だけでは解決できない体験課題の増加を背景に、サービスデザインの必要性を説明します。本書は「方法論の教科書」である前に「変化のケース」を作ることから始めており、組織内での説得材料としても機能します。 Part 2: What（何をするのか：リサーチ） エスノグラフィック調査・コンテキストインタビュー・シャドーイングなど、サービスデザインにおけるリサーチ手法を詳解します。量的データの補完として、現場での「体験のリッチな記述」を得ることを重視します。 データ収集だけでなく、「何を問いとしてリサーチに臨むか」という問いの設計（Research Frame）の重要性も強調されています。これはDefine フェーズでの「HMW（How Might We）」問いの立て方と直結します。 Part 3: What（何をするのか：アイデア発想と概念設計） アイデエーション・コンセプト発展・プロトタイプのシナリオ設計を扱います。本書の特徴は、ブレインストーミングの「発散」だけでなく、アイデアを絞り込む「収束」のファシリテーション手法にも詳細なガイドを提供している点です。 「ジャーニーの演劇的再現（Service Staging）」というアプローチが紹介されており、ロールプレイを用いてサービスの流れを体験的に評価する方法は、プロトタイプフェーズの実践に直接応用できます。 Part 4: What（何をするのか：プロトタイピングと実装） 本書がとりわけ詳細に扱うのがこのパートです。サービスのプロトタイプには「紙のモックアップ」から「実際の環境でのパイロット運営」まで複数のフィデリティ（精度）があることを示し、コストと学習量のトレードオフに基づいて段階的に検証精度を上げる方法を説明します。 サービスブループリント（Service Blueprint）の作成ガイドが充実しており、フロントステージ（顧客接点）・バックステージ（従業員業務）・サポートプロセス（システム・パートナー）の3層を整理する方法論は、オペレーション設計に踏み込む際の標準的フレームです。 Part 5: How（どのように組織で動かすか） 本書が前著との差別化として最も強化したのがこのパートです。ファシリテーション技法・ワークショップ設計・組織へのサービスデザイン導入戦略が詳述されています。 「プロジェクトチームの構成」「スポンサーシップの確保」「変化に抵抗する組織への対処法」など、実務的な課題に対するガイドが豊富です。デザイン思考の実践者が「チームを超えて組織全体に広げる」段階で参照できる、数少ない書籍の一つです。 サービスブループリント——実装の中核ツール 本書で特に詳細に扱われるツールが「サービスブループリント（Service Blueprint）」です。カスタマージャーニーマップが顧客の視点を中心に描くのに対して、サービスブループリントは顧客体験と組織内部の業務プロセスを同一の時間軸で可視化します。 構造は5層で構成されます。 最上部の物理的証拠（Physical Evidence）は、各接点で顧客が目にする・触れるものです。次の顧客アクション（Customer Actions）は、顧客が取る行動と判断です。フロントステージのアクション（Onstage Contact Employee Actions）は、顧客と直接接する従業員の行動。バックステージのアクション（Backstage Contact Employee Actions）は顧客には見えないが必要な内部業務。最下部のサポートプロセス（Support Processes）はシステム・パートナーが担う機能です。 この5層を時系列で並べることで、「どこでサービスが崩れるか」「コスト集中はどこか」「自動化できる業務はどれか」が一目で見えます。 デザイン思考との接続ポイント 本書はデザイン思考の5フェーズと深く連動しています。特に「共感→定義→アイデア→プロトタイプ→テスト」のサイクルを、サービスという時間軸を持つ体験の設計に特化して展開しています。 共感フェーズのリサーチ手法（エスノグラフィー・シャドーイング）、問題定義フェーズのジャーニーマップとサービスブループリント、発想フェーズのアイデエーションセッション設計、プロトタイプフェーズのフィデリティ段階管理——すべてにおいて、本書は実務レベルのガイダンスを提供しています。 デザイン思考を「プロダクト設計」だけでなく「体験全体の設計」に広げたい実践者にとって、最も網羅的なリファレンスです。 この書籍を活かすために 750ページを超える大著ですが、実務での参照は「ツール別」に行うのが効果的です。リサーチ章・ワークショップ設計章・ブループリント章を、プロジェクトの段階に応じて選択的に読む。著者自身もそれを推奨しています。 「何を学ぶために読むか」を最初に決める。全体を通読するよりも、直面しているプロジェクト課題に対応する章を深く読み、実際のファシリテーションに持ち込む。それが本書の設計意図でもあります。 --- 200回以上のデザイン思考ワークショップで、参加者が「サービスブループリントを作ってみて初めてバックステージの業務の複雑さがわかった」と語ることは多い。本書のフレームワークは紙の上では理解できても、実際に自社のサービスに適用し始めると「フロントステージとバックステージの境界線はどこか」という問いが即座に生まれる。この実践的な摩擦を乗り越えるためのガイダンスが、本書が前著と最も大きく異なる部分だ。 --- 書誌情報・参考文献 - Stickdorn, M., Hormess, M. E., Lawrence, A., & Schneider, J. (2018). This Is Service Design Doing: Applying the Tools and Methods of Service Design. O'Reilly Media. — ISBN: 978-1491927182 - Stickdorn, M. & Schneider, J. (eds.) (2010). This Is Service Design Thinking: Basics, Tools, Cases. BIS Publishers. — 前著。思考法の基盤を示した原典 - Shostack, G. L. (1984). "Designing Services That Deliver." Harvard Business Review, 62(1), 133–139. — サービスブループリントの概念を初めて提示した論文 - Bitner, M. J., Ostrom, A. L., & Morgan, F. N. (2008). "Service Blueprinting: A Practical Technique for Service Innovation." California Management Review, 50(3), 66–94. — サービスブループリントの学術的整理 - Polaine, A., Løvlie, L., & Reason, B. (2013). Service Design: From Insight to Implementation. Rosenfeld Media. — 本書と並ぶサービスデザインの標準参考書 関連記事 - デザインリサーチ vs マーケットリサーチ - 共感フェーズ——ユーザーを深く理解する - プロトタイプフェーズ --- ### 『バリュー・プロポジション・デザイン』— 顧客価値を設計する思考フレームを読む URL: https://designthinking.studio/books/value-proposition-design/ > バリュー・プロポジション・キャンバスを中心に、顧客が「本当に求めること」と製品・サービスの設計を整合させる方法論を体系化した書。ビジネスモデル・ジェネレーションの著者陣による続編。 「顧客ニーズを満たす製品を作る」と言いながら、誰も使わないものを作り続ける組織がある。なぜか。ニーズを「想像」しているが、「観察」していないからだ。 Alexander Osterwalder、Yves Pigneur、Gregory Bernarda、Alan Smithの4名が著した『Value Proposition Design』（原著：John Wiley & Sons、2014年、ISBN-13: 978-1118968055）は、この根本的なズレを構造的に解消するためのフレームワークを提示した書籍だ。 Osterwalder と Pigneur の前著『Business Model Generation』（2010年）が「ビジネスモデルの全体設計」を扱ったのに対し、本書は「価値提案（Value Proposition）」という最重要ブロックを深掘りした続編に位置づけられる。 原著の日本語版は翔泳社より2015年に刊行。Strategyzer.comが提供するオンラインリソースと合わせて使われることが多く、ツールとしての実用性が高い書籍だ。 --- 著者について Alexander Osterwalder（アレクサンダー・オスターワルダー） スイス出身の起業家・経営思想家。ビジネスモデル・イノベーションの研究でスイス・ローザンヌ大学にてPhDを取得。Strategyzer社の共同創業者。ビジネスモデル・キャンバスの考案者として知られ、世界500社以上のイノベーション支援実績を持つ。Thinkers50にて「世界で最も影響力あるビジネス思想家トップ15」に選出されている。 Yves Pigneur（イヴ・ピニュール） ベルギー出身の経営情報学教授。ローザンヌ大学（HEC Lausanne）で情報システムを教え、ビジネスモデル・イノベーションの研究者として長年にわたりOsterwalderと共同研究を行っている。 Gregory Bernarda、Alan Smith Strategyzerのデザインパートナー。実際のコンサルティングプロジェクトで本書のフレームワークを繰り返し適用し、実務での洗練に貢献した。 --- 本書の核心：バリュー・プロポジション・キャンバス フレームワークの構造 バリュー・プロポジション・キャンバス（Value Proposition Canvas）は、本書の中心ツールだ。ビジネスモデル・キャンバスの中の「価値提案ブロック」と「顧客セグメントブロック」という2つの要素を展開し、整合性を可視化するためのフレームワークだ。 キャンバスは左右2つのブロックで構成される。 右側：顧客プロファイル（Customer Profile） 顧客プロファイルは3要素から成る。顧客が日常で達成しようとしている「カスタマージョブス（Customer Jobs）」、そのジョブを遂行する際に感じる障壁や不快感を指す「ペイン（Pains）」、そしてジョブを達成した際に期待する成果や恩恵を指す「ゲイン（Gains）」だ。 左側：バリューマップ（Value Map） バリューマップも3要素から成る。提供する「製品・サービス（Products & Services）」、顧客のペインを取り除く「ペインリリーバー（Pain Relievers）」、そして顧客のゲインを生み出す「ゲインクリエーター（Gain Creators）」だ。 フィット（Fit） フィットとは、バリューマップと顧客プロファイルが「合致している状態」だ。製品・サービスが顧客の重要なジョブに対応し、ペインリリーバーが最も深刻なペインを解消し、ゲインクリエーターが最も期待されるゲインを生み出している時に、フィットが達成される。 ワークショップでよく起こるのは、左側（バリューマップ）だけを一生懸命に埋めて、右側（顧客プロファイル）が「想像」で作られている場面だ。本書が繰り返し強調するのは、「顧客プロファイルはリサーチから作る」という原則だ。推測ではなくインタビュー・観察・データから導かれる事実が、キャンバスの土台でなければならない。 --- 本書の4部構成 第1部：Canvas（キャンバス） バリュー・プロポジション・キャンバスのフレームワークを詳細に解説するパートだ。カスタマージョブス・ペイン・ゲインという顧客プロファイルの3要素と、製品サービス・ペインリリーバー・ゲインクリエーターというバリューマップの3要素、そして両者の整合性としての「フィット」の概念が体系化されている。 このパートで特に重要なのが「ジョブスの分類」だ。ジョブスには「機能的ジョブス（Functional Jobs）」「感情的ジョブス（Emotional Jobs）」「社会的ジョブス（Social Jobs）」の3種類がある。機能的ジョブス（タスクを完了する）だけを見ていると、感情的・社会的な側面が見えなくなり、フィットは得られない。 第2部：Design（デザイン） 価値提案を「どのように設計するか」のプロセスを扱うパートだ。スタートアップ的な視点（ゼロから設計する）と、既存組織での視点（既存の製品・サービスを再設計する）の両面からアプローチが示される。 「カスタマーをよく知る」ためのリサーチ手法、「アイデアの多様化」としてのプロトタイピング的思考、「選択の絞り込み」としての優先度設計など、デザイン思考のプロセスと強く接続するコンテンツが含まれる。 実際にやってみると、このパートの「スタートポイント」の整理が特に有効だと感じる。「既存顧客から始めるか、テクノロジーから始めるか、競合分析から始めるか」という出発点の違いが、キャンバスの埋め方に影響することを明示的に説明している。 第3部：Test（テスト） 設計した価値提案を「検証する」ためのフレームワークを提示するパートだ。仮説の設定、検証実験のデザイン、エビデンスの収集と解釈のプロセスが体系化されている。 「何をテストするか（What to Test）」と「どうテストするか（Testing Step-by-Step）」を分けて整理している点が実用的だ。仮説をデータで否定できる「反証可能な形式」に変換することが、テストの前提条件であることを本書は強調する。 「実験ライブラリ（Experiment Library）」として、複数の検証手法（インタビュー、プロトタイプ、コンシェルジュ実験、スモークテストなど）がコスト・信頼性の軸で整理されており、どの場面でどの手法を選ぶかの判断基準が与えられる。 第4部：Evolve（エボルブ） 価値提案は一度設計して終わりではなく、継続的に進化させるものだという視点を扱うパートだ。市場の変化、技術の変化、顧客ニーズの変化に対応して価値提案を更新し続けるためのマネジメント観が示される。 「バリュー・プロポジション・デザインは一回限りのプロジェクトではなく、継続的なプロセスだ」 という主張がこのパートの核心だ。組織がこの継続的プロセスを回し続けるための仕組みとしての、アライメント構築・測定・改善・再発明のサイクルが論じられる。 --- 実務への示唆 「誰が顧客か」の再定義 本書を読んでまず問い直すべきは、「自分たちが本当に顧客プロファイルを理解しているか」だ。多くの組織で行われているのは「マーケティング資料から転記したユーザー像」を顧客プロファイルとして扱うことだ。 本書が要求するのは、実際のユーザーインタビューや行動観察から帰納的に「ジョブス・ペイン・ゲイン」を導き出すことだ。想像ではなく観察から始めることが、フレームワーク活用の前提条件だ。 キャンバスは「対話のツール」 参加者からの声として多いのは、「バリュー・プロポジション・キャンバスを一人で埋めるのは難しい」というものだ。これは正しい。キャンバスは一人の専門家が完成させるものではなく、チームが「フィットについての共通認識を作る」ための対話ツールだ。 マーケティング・営業・開発・デザインのメンバーが同じキャンバスを前に議論することで、「顧客をどう見ているか」の解釈のズレが表面化する。 このズレを発見・解消することがキャンバス活用の最大の価値だ。 "Jobs to Be Done"との接続 本書の「カスタマージョブス」の概念は、Clayton Christensenが提唱した「Jobs to Be Done（JTBD）」理論と強く共鳴する。「製品を買うのではなく、ジョブを達成するために製品を『雇う』」というJTBDの視点は、顧客プロファイル設計に深みを与える。 JTBD × 顧客価値設計の実践についてはデザイン思考とJobs to Be Doneの統合で詳しく扱っている。 --- こんな人に読んでほしい 新しい製品・サービスの事業性を検証したい方には、特に第2部・第3部が役立つ。検証実験の設計方法と実験ライブラリは、実務で即座に活用できる。 既存製品のリニューアルや競合差別化に取り組む方には、第1部のキャンバスを使って「自社の価値提案と顧客プロファイルのフィット度」を診断することを薦める。多くの場合、自社が重要視しているゲインと顧客が本当に求めているゲインのズレが発見される。 組織でデザイン思考やリーン・スタートアップを実践している方には、本書がこれらのフレームワークと接続する「橋渡し」として機能する。デザイン思考の共感フェーズで得た発見を構造化し、リーンの仮説検証プロセスに渡すための言語として、バリュー・プロポジション・キャンバスは有効だ。 デザイン思考の「感性的実践書」として本書と比較読みする価値があるのが『Creative Confidence』だ。また、ビジネスモデル全体の設計思想を理解したいなら前著『Change by Design』も合わせて参照されたい。本書の導入失敗パターンとVPC運用の臨界点をより深く掘り下げた深掘りレビューも参照されたい。 --- 参考文献 - Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value Proposition Design: How to Create Products and Services Customers Want. John Wiley & Sons. ISBN: 978-1118968055 - Osterwalder, A., & Pigneur, Y. (2010). Business Model Generation. John Wiley & Sons. - Christensen, C., Hall, T., Dillon, K., & Duncan, D. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. Harper Business. - Strategyzer, "Value Proposition Design," https://www.strategyzer.com/library/value-proposition-design-2 --- ### 『バリュー・プロポジション・デザイン』深掘りレビュー — 失敗パターンと組織導入の臨界点 URL: https://designthinking.studio/books/value-proposition-design-deep-review/ > バリュー・プロポジション・キャンバス導入で失敗する組織が量産される理由を、原著の論理に沿って解剖する深掘りレビュー。フィット幻想・反証回避・継続運用の停滞という3つの失敗様式を、本書の処方箋と接続して読み解く。 バリュー・プロポジション・キャンバス（以下、VPC）を導入して3カ月後、付箋が貼られたままのキャンバスがホワイトボードに残っている。これはコンサルティング現場で頻繁に目にする光景だ。フレームワークそのものは2015年に翔泳社から邦訳が出てから既に10年が経ち、知らない企画担当者を探す方が難しい。にもかかわらず、VPCを導入した組織の多くが「キャンバスを埋めて満足する」段階で止まる。 『Value Proposition Design』(原著 John Wiley & Sons, 2014, ISBN 978-1118968055) の入門的な要約は既存レビューで扱った。本稿はその深掘り版として、書籍の論理を「導入失敗パターン」と接続して読み直す。すなわち、本書の処方箋を組織がどこで取り違え、どこで運用が止まるかを、原著の主張と照らし合わせて検証する。 対象読者は、VPCをすでに知っているが「うまく回らない」と感じている事業企画・新規事業・プロダクトマネージャーだ。本書を再読する前に、自社のVPC運用がどの失敗様式にハマっているかを診断する補助線として使ってほしい。 --- 著者陣の論理的立ち位置 — なぜVPCはこの形になったか Osterwalder の問題意識 Alexander Osterwalder はスイス・ローザンヌ大学で2004年にPhDを取得した経営学者であり、Strategyzer社の共同創業者だ。前著『Business Model Generation』(2010) でビジネスモデル・キャンバスを世に出した彼の問題意識は一貫している。「経営者は『顧客に価値を届ける』と語るが、その『価値』を構造的に分解できていない」という指摘だ。 ビジネスモデル・キャンバスの9ブロックのうち、「Value Proposition (価値提案)」と「Customer Segments (顧客セグメント)」の2ブロックは特に抽象度が高く、ワークショップでも埋まりにくい。Osterwalder は2010年代前半に世界500社規模の支援実績を蓄積する過程で、この2ブロックの解像度を高めるためのサブツールが必要だと判断した。これが本書 (2014) 出版の動機だ。 Pigneur, Bernarda, Smith の役割分担 Yves Pigneur (ローザンヌ大学経営情報学教授) は情報システム研究者として、フレームワークの論理的整合性を担保した。Gregory Bernarda と Alan Smith (Strategyzer のデザインパートナー) は、実際のコンサルティング現場で繰り返しプロトタイプを回し、書籍に掲載される図版と実践ガイドを洗練させた役割を担う。 4名体制で最も重要なのは、Smith の「ビジュアルファシリテーション」視点だ。VPCが「キャンバス」という形式を取り、付箋で運用可能なデザインになったのは、抽象的な戦略議論を「物理的なオブジェクト操作」に落とし込む彼の貢献が大きい。逆に言えば、VPCはディスカッションを駆動するための媒体として設計されており、書斎で完成させるツールではない。この設計思想を見落とすと、後述する失敗様式①「孤独な記入」が発生する。 --- 失敗様式① — フィット幻想 (左右の独立記入) 何が起きるか VPC は左 (バリューマップ) と右 (顧客プロファイル) の2ブロックで構成される。左には「製品・サービス / ペインリリーバー / ゲインクリエーター」を、右には「カスタマージョブス / ペイン / ゲイン」を記入する。両者が整合した状態を本書は「フィット (Fit)」と呼ぶ。 ところが現場では、左を埋めるチームと右を埋めるチームが分業されたり、同一人物が左右を行き来しながら「整合的に見える」ように書き分けてしまう。結果、左右は「論理的に対応する」が、「観察から導かれていない」状態が量産される。本書 p.62 で著者陣は「フィットには3段階ある」と注意喚起している。 - Problem-Solution Fit (紙の上のフィット): キャンバス上で論理的に対応している状態 - Product-Market Fit (市場のフィット): 実際の顧客が価値を認め、対価を支払う状態 - Business Model Fit (事業モデルのフィット): 収益化可能な構造で持続する状態 多くの組織が止まるのは段階1だ。「キャンバスがきれいに埋まった」ことを「フィット達成」と取り違える。この段階1のフィットは本書著者陣にとっては「出発点」であり、ゴールではない。 原著の処方箋 第3部 Test の冒頭で本書は「キャンバスはあくまで仮説の構造化ツールであり、検証なしでは何の意味も持たない」と明言する。具体的には、右側の各要素 (ジョブス・ペイン・ゲイン) に対して、それぞれが「観察または対話で確認された事実」か「推測」かを色分けすることを推奨している (Strategyzer のテンプレートでは黄色付箋=仮説、青色付箋=検証済み)。 この色分け運用を導入していない組織のVPCは、ほぼ全てが段階1で止まる。色分けの不在は、組織が「観察より想像を優先している」ことの可視化でもある。詳細はカスタマー理解の幻想も参照されたい。 診断質問 自社のVPCを点検する際、以下の質問を投げかけてみてほしい。 - 右側 (顧客プロファイル) の各付箋に、それを裏づける一次データ (インタビュー記録、行動観察ログ、利用データ等) を添付できるか - 「重要なジョブス」「深刻なペイン」「期待されるゲイン」の優先順位は、何を根拠に決めたか - 左右が「論理的に対応している」と「観察的に対応している」をチームメンバー全員が区別できているか 3つ目の質問にチームが答えられない場合、フィット幻想に陥っている。 --- 失敗様式② — 反証回避 (実験ライブラリの「都合のいい」運用) 何が起きるか 第3部 Test では「実験ライブラリ」として、コスト・信頼性の軸で複数の検証手法 (インタビュー、プロトタイプ、コンシェルジュ実験、スモークテストなど) が整理されている。理屈の上では、仮説に対して反証可能な実験を設計し、結果で意思決定するプロセスが回るはずだ。 しかし実装段階で頻繁に起きるのは、「自社の価値提案を肯定する結果が得られる実験」だけが選択的に実行される現象だ。例えば「既存顧客に好意的フィードバックを集めるインタビュー」や「コンセプトを支持するアーリーアダプターを呼ぶフォーカスグループ」が量産される。 これは確証バイアスの教科書的な事例だが、本書著者陣はこの罠を予期していた。第3部 p.184 で「仮説は反証可能な形式 (Falsifiable) に変換しなければならない」と明示し、Karl Popper の科学哲学を引用する。「成功すれば◯◯になる」ではなく「失敗すれば◯◯になる」基準を事前に設定することを要求している。 原著の処方箋 本書は「Pass/Fail Criteria」(合格・不合格基準) を実験設計の必須要素として位置づけている。具体的なテンプレートは以下の構造だ。 仮説: 我々の顧客 [セグメント] は [ジョブ] を達成するために [ペインリリーバー] を [価格] で購入する。 検証方法: [手法] 成功基準: [合格条件、定量] 不合格基準: [中止する条件、定量] 「不合格基準」を事前に書けない場合、その実験は反証回避のためのアリバイ実験になる。この点で本書は Eric Ries の『The Lean Startup』(2011) と論理的に接続しており、Steve Blank の Customer Development とも整合する。VPC は単独で機能するツールではなく、リーン・スタートアップ系の検証文化とセットで運用される前提だ。 実験ライブラリの実務的拡張についてはWizard of Ozプロトタイピング完全ガイドやDesirability Testing 完全ガイドで扱った検証手法を参照されたい。 診断質問 - 直近3カ月で実行した検証実験のうち、「不合格基準」が事前に文書化されていたものは何割か - 検証結果として「仮説を棄却し、ピボットした」ケースはあるか - 「都合のいい結果」が出るインタビュー対象者ばかりを呼んでいないか これらに「No」が並ぶ場合、反証回避の運用に陥っている。 --- 失敗様式③ — 継続運用の停滞 (Evolve フェーズの蒸発) 何が起きるか 第4部 Evolve は「価値提案は一度設計して終わりではなく、継続的に進化させるもの」と説く。市場・技術・顧客ニーズの変化に応じてVPCを更新し続けるサイクルが必要だと主張する。 ところが日本企業の多くで観察されるのは、初回のワークショップで作ったVPCが「神格化」され、半年経っても1年経っても更新されない現象だ。新製品発表会で経営層に承認されたキャンバスは、それ自体が組織的な合意文書になり、修正すると政治的コストが発生する。結果、市場が変化してもキャンバスは更新されず、VPCは「過去の決定の記念碑」と化す。 原著の処方箋 本書著者陣は第4部 p.243 でこの罠を明示的に警告する。「企業のValue Proposition は 半減期 (half-life) を持つ」と表現し、定期的なレビューサイクル (四半期ごとが推奨) を組織プロセスに組み込むことを要求する。 具体策として本書は「Strategyzer Cycle」と呼ぶ運用モデルを提示する。 - Alignment (整合): 経営戦略とVPCの整合性を四半期ごとに点検 - Measurement (測定): 各仮説の検証進捗を定量モニタリング - Improvement (改善): 検証結果に基づいてキャンバスを更新 - Reinvention (再発明): 半減期を超えた領域は根本から再設計 このサイクルを「定例会議の議題」として組織プロセスに組み込めるかが、Evolve フェーズの成否を分ける。デザイン思考の組織導入論についてはデザイン思考の組織導入実践ガイドで詳述した。 診断質問 - 自社のVPCは過去1年で何回更新されたか - VPCの更新を意思決定する責任者は誰か - 「VPCを書き直す」ことが組織内で政治的タブーになっていないか これらに健全に答えられない場合、Evolve フェーズが蒸発している。 --- VPC と隣接フレームワークの関係 — 単独運用は失敗する Jobs to Be Done との接続 本書のカスタマージョブス概念は Clayton Christensen の Jobs to Be Done (JTBD) 理論と強く共鳴する。Christensen の『Competing Against Luck』(2016) は「顧客は製品を雇用してジョブを達成する」という視点を提示するが、VPCはこのジョブを「機能的・感情的・社会的」の3軸に分解する解像度を提供する。 両者は対立せず、補完関係にある。JTBDで「ジョブの本質」を抽出し、VPCで「フィットを構造化」する順序が実務的だ。詳細はデザイン思考とJobs to Be Doneの統合で扱った。 Lean Startup との接続 Eric Ries の Build-Measure-Learn ループは「学習」を中心に据えるが、VPC は「学習対象 = 価値提案の仮説」を構造化する。Lean Startup が「いつ・どうやって学ぶか」の問いに答えるなら、VPC は「何を学ぶか」を分解する。デザイン思考とリーン・スタートアップの関係性についてはデザイン思考とリーン・スタートアップで整理した。 Business Model Canvas との接続 VPC はビジネスモデル・キャンバスのサブツールだ。VPCで設計した価値提案は、ビジネスモデル・キャンバスの「Value Proposition」ブロックに収まる。VPCだけで事業設計を完結させようとすると、収益構造 (Revenue Streams) やコスト構造 (Cost Structure) との接続が失われる。本書著者陣は前著との併用を前提に書いている。 --- 実務適用の臨界点 — どの段階の組織がVPCを使うべきか 適合する組織 - 新規事業を立ち上げる段階で、ターゲット顧客の解像度が低い組織: 顧客プロファイルを構造化することで、リサーチ計画が立てやすくなる - 既存製品のリブランディング・リニューアル時に、ペインの再診断が必要な組織: 競合と差別化されていない要因を、ペインの優先順位ズレとして可視化できる - 複数事業部が「同じ顧客」を別々に解釈している組織: VPCを横断的に書き比べることで、解釈のズレが顕在化する 不適合な組織 - 顧客接点が十分に取れていない、観察データが圧倒的に不足している組織: VPCを埋めても全てが推測になる。先にステークホルダーインタビュー等の質的調査を実施すべきだ - 意思決定者がフレームワークの活用を「儀式」と見なしている組織: キャンバスを埋めること自体が目的化し、Test/Evolve フェーズが永遠に来ない - 既に Product-Market Fit を達成しており、スケールフェーズに入っている事業: VPCは仮説検証ツールであり、スケール段階では別のフレームワーク (Growth系) を優先すべきだ --- 本書を「もう一度読む」価値 — 深掘りの効用 入門時に本書を読んだ際、多くの読者は「キャンバスの埋め方」に注目する。一方、再読時に注目すべきは第3部 Test と第4部 Evolve だ。この2つのパートは「キャンバスをいかに改訂し続けるか」のプロセスを扱っており、組織導入の臨界点はここにある。 特に第3部の「Experiment Library」 (p.190-230) と第4部の「Strategyzer Cycle」 (p.243-262) は、再読時に書き込みをしながら自社プロセスと照合する価値が高い。第1部・第2部は「ツールの使い方」だが、第3部・第4部は「組織変革の方法論」だ。後者を実装できるかが、VPC導入の成否を決める。 --- こんな人に再読してほしい VPCを導入したが「うまく回らない」と感じている事業企画担当者には、本稿の3つの失敗様式を診断軸として使ってほしい。フィット幻想 / 反証回避 / 継続停滞のどれにハマっているかを特定できれば、原著の対応する処方箋に戻れる。 コンサルタント・ファシリテーターとしてVPCワークショップを設計する人には、第3部・第4部の運用設計を深く読み込むことを薦める。クライアントが「キャンバスを埋めて満足する」段階で終わらないよう、Test と Evolve のサイクルをワークショップ後の組織プロセスに埋め込む設計が、ファシリテーターの腕の見せ所だ。 新規事業の意思決定者には、本書を読むことで「自社の検証実験が反証回避になっていないか」を点検する視点を得てほしい。Pass/Fail 基準の事前明示は、組織が確証バイアスから自由になるための最小限の規律だ。 入門レベルの解説は既存レビューを、関連書籍として価値創出の感性的実践書『Creative Confidence』レビュー、組織変革論として『Change by Design』深掘りレビューを併読することを薦める。 --- 参考文献 - Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value Proposition Design: How to Create Products and Services Customers Want. John Wiley & Sons. ISBN: 978-1118968055 - Osterwalder, A., & Pigneur, Y. (2010). Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. John Wiley & Sons. - Christensen, C., Hall, T., Dillon, K., & Duncan, D. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. Harper Business. - Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business. - Blank, S. (2013). The Four Steps to the Epiphany: Successful Strategies for Products that Win. K&S Ranch. - Popper, K. (1959). The Logic of Scientific Discovery. Hutchinson. - Strategyzer, "Value Proposition Design," https://www.strategyzer.com/library/value-proposition-design-2 - Strategyzer, "Testing Business Ideas," https://www.strategyzer.com/library/testing-business-ideas --- ### Change by Design 章別要約 — ティム・ブラウン デザイン思考の真髄を読む URL: https://designthinking.studio/books/change-by-design-chapter-summaries/ > IDEO元CEO Tim Brownの著作『Change by Design』全章の要約と実務への示唆。デザイン思考の古典的名著を章ごとに読み解き、2026年の実践に活かせる論点を抽出する。 Tim Brown著『Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation』（HarperBusiness, 2009年）。邦訳『デザイン思考が世界を変える——イノベーションを導く新しい考え方』（早川書房, 2010年、千葉敏生訳、ISBN: 978-4152091635）。本稿は原著の章構成に沿って要点を整理し、実務への示唆を抽出する。 --- 書籍概要 Tim BrownはIDEO（アイディオ）の元CEO（最高経営責任者）であり、本書執筆・出版時はCEOとして在任していた。IDEOはDavid Kelleyが1991年に設立した、デザインとイノベーションのコンサルティング会社だ。 本書の核心的な主張は「デザイン思考はデザイナーだけのものではなく、あらゆるビジネスリーダーが習得すべきイノベーション戦略だ」という一点に集約される。出版年の2009年は、世界金融危機の翌年であり「従来のビジネス手法が機能しなくなった」という感覚が広まった時期だ。その文脈で本書は「人間中心のアプローチがイノベーションの突破口になる」というメッセージを提示した。 本書が2008年のHarvard Business Review論文「Design Thinking」（Tim Brown著）とともに、「デザイン思考」という言葉をビジネス界に急速に普及させた事実は、今日でも本書を読む価値の一つだ。 --- 章別要約 はじめに（Introduction）：デザイン思考とは何か Brownは冒頭で「デザイン思考はデザイナーが持つ感受性と手法を——デザインとは何かという考え方自体を——用いて、人々のニーズを技術的な実現可能性とビジネスとしての持続可能性に合わせる人間中心のアプローチだ」と定義している。 この定義が重要なのは、デザイン思考を「プロセスツール」ではなく「思考の姿勢（Mindset）」として位置づけている点だ。実務で「デザイン思考をやった」と言うとき、多くの場合はダブルダイヤモンドのプロセスを実行することを指す。しかしBrownが本書全体で伝えようとしているのは、方法論の実行より先に「人間を起点に考える姿勢」が組織に根付くことの重要性だ。 第1章 Getting Under the Skin、Or How Design Thinking Is About More Than Style 本章は「デザイン思考の本質は、問題を美しく解くことではなく、正しい問題を見つけることだ」というテーゼから始まる。 BrownはIDEOが手がけたプロジェクト事例を通じて、「見えない体験」を設計することの重要性を示す。病院の患者体験改善プロジェクトで、担当チームが患者として入院する経験を積み、「天井のタイル」しか見えない患者の視点から設計を見直した事例は、共感（Empathize）フェーズの意義を具体的に示している。 実際にやってみると、多くのプロジェクトで「ユーザーの視点に立つ」という言葉は使われるが、物理的にユーザーの状況を体験することを実践しているケースは少ない。観察と共感の違いは「外から見る」と「内側に入る」の差だ。 第2章 Converting Need into Demand、Or Putting People First 本章はIDEOのデザインプロセスの根幹にある「Desirability（望ましさ）・Feasibility（実現可能性）・Viability（事業継続性）」の3円フレームワークを詳述する章だ。 Brownの主張は「出発点は常にDesirabilityであるべき」だ。技術から出発（Feasibility起点）しても、ビジネスモデルから出発（Viability起点）しても、人間的な意味のある解決策には至らない。人間が本当に必要とするもの（Desirability）を起点に、それを技術的に実現し、ビジネスとして持続させる順序が重要だ。 参加者からの声として頻繁に聞かれるのは「DesirabilityとFeasibilityの議論が混ざってしまう」という問題だ。技術担当者が同席すると「それは技術的に難しい」という評価がDesirabilityの探索段階で入り込む。この章でBrownが示す「探索のフェーズと評価のフェーズを分ける」という原則は、ワークショップ設計の基本だ。 第3章 Building to Think、Or the Power of Prototyping 本章はBrownのプロトタイピング哲学を最も集中的に展開している。「早く、安く、多く試す。失敗は情報だ」という主張は、2009年時点で先見的だった。 Brownが強調するのは「プロトタイプは答えを確認するためではなく、質問を発見するためにある」という逆説だ。完成度の高いプロトタイプは「このデザインで進めていいか」という確認に使われる。しかし初期のプロトタイプは「自分たちが想定していなかった質問を発見する」ためにある。 「スケールしないプロトタイプ」という概念も本章で示される。IDEOが行った地域コミュニティ向けサービスの設計では、最初は実際の建物を使わずに既存のカフェスペースを「一日限りのプロトタイプ」として使った。技術的に完成していなくても、ユーザーが「その体験の空間」に実際に存在することで得られるデータの価値は、モックアップとは桁が違う。 第4章 In the Studio、Or Planning to Explore 本章はIDEOの物理的な作業環境（スタジオ）とチーム構成の哲学を扱う。「T字型の人材（T-shaped People）」という概念がここで示される。 T字型とは「一つの分野に深い専門性（縦棒）を持ちながら、他の分野にも関心と協働できる能力（横棒）を持つ人材」だ。BrownはIDEOのプロジェクトチームが「単一専門家の集まり」ではなく「異分野間で対話できる人材の集まり」であることが、デザイン思考の実践を可能にしていると論じる。 ワークショップでよく起こるのは、専門家同士が専門用語でしか話せない状況だ。エンジニアリングの専門家とマーケティングの専門家が同じチームにいても、「翻訳できる人」がいないとサイロは解消されない。T字型人材の重要性は「専門性」ではなく「翻訳能力」にあるという点が本章の核心だ。 第5章 Retrofitting Corporations、Or Building to Last 本章はデザイン思考を既存組織に導入する際の構造的な困難を論じている。Brownは「デザイン思考は組織の端っこのプロジェクトではなく、中核のプロセスに組み込まれるべきだ」と主張する。 「Innovation Theater（イノベーション・シアター）」という概念はこの文脈で理解できる。Brownは直接この言葉を使ってはいないが、「デザイン思考ワークショップを開催した、でも組織は何も変わらなかった」という現象の構造を説明している。問題はワークショップの質ではなく、ワークショップで生まれた洞察が組織の意思決定プロセスに接続していないことだ。 実際にやってみると、単発ワークショップと「継続的なデザイン思考の組織埋め込み」の間には深い溝がある。Brownが本章で示す「デザイン思考が機能する組織の条件」は今日でも参考になる。 第6章 Design Activism、Or Inspiring Change from the Bottom Up 本章はデザイン思考の適用対象を「企業のイノベーション」から「社会課題の解決」に拡張する。IDEO.orgの設立につながる思想がここで示されている。 Brownは「デザイン思考は商業的な課題だけでなく、貧困・医療・教育という複雑な社会課題にも適用できる」と論じる。特に「制約（Constraint）がイノベーションの触媒になる」という観点は重要だ。資源が豊富な状況よりも、制約が厳しい状況の方が創造的な解決策が生まれることが多い——「制約の創造的活用」として知られる現象だ。 参加者からの声として多いのは「社会課題のデザイン思考適用は綺麗事になりやすい」という懐疑だ。Brownの本章は「実際に現地に行き、現地のコミュニティが主体となる設計をする」というIDEOの実践方法論に踏み込んでいる。受益者が「設計の対象」ではなく「設計の主体」になることが、社会課題における人間中心設計の要点だ。 第7章 The New Social Contract、Or Designing a World in Flux 最終章は「未来の組織とデザイン思考の役割」を論じる。Brownは「変化が常態化した世界では、一度決めた戦略に固執するより、継続的に仮説を試し更新する能力が競争優位になる」と主張する。 この主張は2009年時点では先見的だったが、2026年の今日では「当然のこと」になっている。しかし「継続的に仮説を試す」能力を組織が持てているかどうかは、別の問いだ。本章を読む実践者が問うべきは「自分たちの組織はこの能力を持っているか」であり、Brownの言葉は現状確認の鑑として機能する。 --- 核心メッセージ：3つの抽出 - 探索と発散を「許可」する組織文化 本書全体を通じて、Brownが繰り返すのは「答えを早く決めることが美徳とされる組織では、デザイン思考は機能しない」というメッセージだ。探索フェーズ（Desirabilityの確認、プロトタイプによる質問の発見）を「時間の無駄」ではなく「投資」として扱える組織文化が前提条件だ。 - 「正しい問い」への執着 第1章から第3章の一貫したテーマは「問題定義の重要性」だ。Brownは「デザイン思考の最大の付加価値は、解き方ではなく解くべき問いの発見にある」と主張する。POV文（Point of View文）やHMW（How Might We）といった問い設計のツールが実務で重要視される理由は、この本書の哲学に根ざしている。 - プロトタイプは「確認」ではなく「発見」のため 第3章の「Build to Think（考えるために作る）」というフレーズが本書で最も引用される概念の一つだ。完成前に作ることへの抵抗を「プロトタイプは本物ではなく質問だ」という視点で解消する。 --- 実務への示唆 「なぜいまこの本か」 という問いへの答えとして、3点を挙げる。 第一に、原典を読む価値がある。 デザイン思考の語られ方が多様化した今日、「Tim Brownが実際に何を言っていたか」に戻ることで、後続の解説書・ワークショップが加えた変形を見抜ける。特に「デザイン思考はプロセスだ」という理解への反省として、本書の「姿勢・文化としてのデザイン思考」という視点は重要だ。 第二に、批判的に読む価値がある。 本書は「デザイン思考の限界」を積極的には論じていない。デザイン思考への批判的視点を踏まえた上で、Brownが何を見ていて何を見ていないかを確認することで、実践者としての自己点検になる。 第三に、AI時代の再読価値が高い。 本書でDesirabilityの確認手段として示された「人間観察・インタビュー・プロトタイプ」は、AIが生成したソリューションを評価する文脈でむしろ重要性が増している。 --- こんな人に読んでほしい これからデザイン思考を組織に導入したい方。 ツールの使い方より先に「なぜデザイン思考が必要なのか」という根拠を経営層に説明する必要がある場合、本書の論旨は強力な説得材料になる。 デザイン思考ワークショップを何度か経験した方。 「やったことはあるが、組織が変わった実感がない」という経験を持つ方が本書を読むと、第5章の「組織への埋め込み」に関する記述が刺さる。ワークショップの設計問題ではなく、組織構造の問題として捉え直す視点が得られる。 「デザイン思考は流行だ」と感じている方。 批判的な視点を持ちながら本書を読むと、「流行として使われているデザイン思考」と「Brownが本書で記述したデザイン思考」のギャップが明確になる。 --- 書誌情報・関連文献 原著： - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009, ISBN: 978-0061766084 邦訳： - ティム・ブラウン著、千葉敏生訳『デザイン思考が世界を変える——イノベーションを導く新しい考え方』早川書房、2010年、ISBN: 978-4152091635 関連文献： - Brown, Tim, "Design Thinking," Harvard Business Review, June 2008（本書の理論的基盤となったHBR論文） - Kelley, David & Kelley, Tom, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013（T字型人材・創造的自信のより詳細な展開） - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015（第6章の社会課題適用を実践化したガイド） --- 関連コンテンツ - Change by Design 概要 — 本の全体像・著者紹介 - 書評『デザイン思考が世界を変える』 — 2026年視点からの批判的考察 - ティム・ブラウン（Tim Brown） — 著者プロフィール - POV文（Point of View文）の作成ガイド — 第2〜3章の問い設計哲学の実践手法 --- ### Change by Design（デザイン思考が世界を変える） URL: https://designthinking.studio/books/change-by-design/ > IDEO CEO（当時）のTim Brownが、デザイン思考の理論と実践をビジネスリーダー向けに解説した書籍。デザイン思考の普及に大きく貢献した一冊。 『Change by Design』は、IDEO の元CEO Tim Brown が2009年に出版した書籍です（日本語版『デザイン思考が世界を変える』は2010年に早川書房から出版）。 Tim Brown はこの書籍で、デザイン思考を「デザイナーのためのツール」から「ビジネスリーダーのためのイノベーション戦略」へと再定義しました。 書籍では、IDEO のプロジェクト事例を豊富に紹介しながら、デザイン思考がなぜビジネスに有効なのかを説明しています。 主な内容 - デザイン思考の3つの要素（Desirability, Feasibility, Viability） - イノベーションプロジェクトの進め方 - プロトタイピングとストーリーテリングの重要性 - 組織にデザイン思考を導入する方法 Tim Brownによるこの著作はデザイン思考の理論的基盤を理解する上での必読書です。IDEOのショッピングカート事例をはじめとする豊富な実例が収録されています。 --- 書誌情報 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009, ISBN: 978-0061766084 --- 参考文献 - Tim Brown, "Design Thinking," Harvard Business Review, June 2008（本書の理論的基盤となったHBR論文） - IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015（IDEOによる実践ガイド） - Roger Martin, The Design of Business: Why Design Thinking is the Next Competitive Advantage, Harvard Business Press, 2009（同時期にデザイン思考のビジネス応用を論じた著作） - Vijay Kumar, 101 Design Methods: A Structured Approach for Driving Innovation in Your Organization, Wiley, 2012（デザイン思考のメソッドを体系化した参考書） - Tom Kelley & David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013（IDEOの創造的自信の概念を展開した後継書） --- ### Creative Confidence（クリエイティブ・マインドセット） URL: https://designthinking.studio/books/creative-confidence/ > IDEO共同創業者のKelley兄弟が、「誰もがクリエイティブになれる」というメッセージとともに、創造的な自信の築き方を解説した書籍。 『Creative Confidence』は、IDEO 共同創業者の David Kelley と Tom Kelley による2013年の著書です（日本語版『クリエイティブ・マインドセット』は2014年に日経BPから出版）。 David Kelley はスタンフォード大学 d.school の創設者でもあり、「誰もがクリエイティブになれる」という信念のもと、創造的自信（Creative Confidence）の概念を提唱しました。 主な内容 - 創造的自信とは何か - 創造性を阻害する恐怖心の克服 - アイデアを行動に移すための実践的な方法 - 組織における創造的文化の醸成 - デザイン思考を日常生活に取り入れる方法 David Kelley 自身ががんを克服した体験も描かれており、人生における創造的自信の重要性を個人的な物語を通じて伝えています。 David Kelleyとデザイン思考の関係を理解するための一冊。共感フェーズで必要とされる「ユーザーに寄り添う姿勢」の根拠となる考え方がここに詰まっています。 --- 書誌情報 - Tom Kelley & David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013, ISBN: 978-0385349369 --- 参考文献 - David Kelley & Tom Kelley, "Reclaim Your Creative Confidence," Harvard Business Review, December 2012（本書の概念を先行紹介したHBR論文） - Albert Bandura, "Self-Efficacy: Toward a Unifying Theory of Behavioral Change," Psychological Review, 84(2), 1977（Creative Confidenceの理論的基盤となる自己効力感研究） - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009（IDEOのデザイン思考を経営視点で解説した姉妹書） - d.school (Stanford University), bootcamp bootleg, Stanford University, 2010（Kelley兄弟が設立したd.schoolの実践ガイド） - Carol S. Dweck, Mindset: The New Psychology of Success, Random House, 2006（創造性と成長マインドセットの関係を論じた基礎書） --- ### サービス・デザイン：新しい事業開発の手法 URL: https://designthinking.studio/books/service-design-new-business-development/ > サービスデザインを「実際にやる」ための実践ガイド。フレームワークや概念の解説にとどまらず、組織でサービスデザインを導入・定着させるための具体的な手法とワークショップ設計を体系化した一冊。デザイン思考実践者が次のステージに進む際の必携書。 「理解することと、実際にやることの間には、巨大な谷がある」——マーク・ステックドーンはこの認識から、前著 This is Service Design Thinking（2010）の10年後に本書を世に出した。前著がサービスデザインの「概念と思想」を伝えたとすれば、本書 This is Service Design Doing（2018、邦訳2020）はその「実装」を扱う。 デザイン思考の学習者が壁にぶつかるのは、たいていフレームワークを理解した後だ。共感マップの書き方は知っている。ダブルダイヤモンドの図も描ける。しかし「では来週、チームで何をするか」という問いに答えられない。本書はその「ではどうするか」に直球で応答する。 本書の位置づけ——「実装の教科書」 This is Service Design Doing は全8パートで構成されるが、その大半は「ワークショップをどう設計し、運営し、組織に定着させるか」に費やされている。理論の説明は最小限に抑えられ、すぐに手を動かせる形式に徹している。 デザイン思考との関係を整理しておくと、サービスデザインはデザイン思考の「実装形態のひとつ」だ。デザイン思考が問題解決の思考様式を提供するのに対し、サービスデザインはその思考様式をサービス・エクスペリエンスの設計に応用する専門領域として発展した。本書はその接点を理解する上でも有効だ。 著者4名はいずれもサービスデザインの実践者であり、それぞれが異なる地域・産業での実装経験を持つ。この多様な実践基盤が、本書の内容に現場感を与えている。 5つのサービスデザイン原則 本書は前著の5原則を引き継ぎながら、実践文脈でより深く掘り下げる。 - ユーザー中心（User-Centred） サービスを設計する際、常にサービスを利用する人々の視点から体験を考える。これはデザイン思考の共感フェーズと直接対応する原則だ。本書で特に強調されるのは、「ユーザーを観察するだけでなく、ユーザーを設計プロセスに参加させる」共同創造（Co-creation）の実践だ。 - 共同創造（Co-Creative） すべてのステークホルダーを設計プロセスに含める。顧客、従業員、経営者、パートナー企業——それぞれが異なる知識と視点を持つ。設計の「正解」は単一の専門家から生まれるのではなく、多様な当事者の対話から浮かび上がる。ワークショップ現場でよく起こるのは、「顧客向けに設計しているのに、顧客が一人も部屋にいない」という状況だ。本書はこの構造的欠陥を解消するファシリテーションの具体手法を提供する。 - シーケンシャル（Sequenced） サービス体験を時系列のシーケンスとして設計する。単一の接触点ではなく、サービスの全期間を通じた「旅」として捉える。カスタマージャーニーマップはこの原則の代表的なツールだ。本書では、ジャーニーマップの作成手順だけでなく、どの段階でどのデータが必要か、どう組織内で共有するかまでを丁寧に解説している。 - 実在するもの（Evidencing） 無形のサービスを有形のもので証拠立てる。受付で渡されるカード、メール確認書、空間のデザイン——これらはサービスを「見える化」するアーティファクトだ。本書は、サービスのタッチポイントを物理的・デジタル的なアーティファクトとして設計する思考を体系化する。 - ホリスティック（Holistic） サービスのすべての側面を統合的に考える。フロントステージ（顧客が見る部分）とバックステージ（顧客が見えない部分）の両方を設計する。サービスブループリントはこの統合的視点を可視化するツールとして本書で詳しく扱われる。 本書の核心——「リサーチから実装まで」の統合プロセス 本書が他のサービスデザイン書籍と異なる最大の点は、リサーチ・アイデア発想・プロトタイピング・実装の全工程を一冊でカバーする点だ。 特に実践的に有用なのは「チェンジマネジメント」の章だ。サービスデザインの手法を学んだ実践者が最初につまずくのは「組織をどう動かすか」という問いだ。デザインスプリントの結果が承認されない、プロトタイプが量産につながらない、チームのモチベーションが続かない——これらは手法の問題ではなく、組織変革の問題だ。本書はそこまで踏み込む。 200回以上のワークショップで繰り返し観察されるパターンがある。デザイン思考やサービスデザインの「初回ワークショップ」は成功する。参加者のエネルギーが高く、新しい視点が生まれる。問題は2回目以降だ。日常業務に戻った参加者は、前回の知見を活かせないまま同じ課題に戻る。本書のチェンジマネジメント章はこの「初回以降をどう設計するか」に答えを持っている。 デザイン思考実践者への読み方 デザイン思考をすでに学んでいる実践者が本書を読む際、以下の点に注目すると吸収効率が上がる。 サービスブループリントの実践手順を深める。ダブルダイヤモンドのプロセスを組織に実装する際、サービスブループリントはフロントステージとバックステージを統合する最も強力なツールのひとつだ。本書の解説は現時点で手に入る最も詳細なものに属する。 ワークショップ設計の型を習得する。本書には、それぞれの手法に対応する「ワークショップデザインテンプレート」が付属する。参加者構成、時間配分、必要な材料、進め方のバリエーション——実際にセッションを組み立てる際のチェックリストとして機能する。 ビジネスサイドへの説明ロジックを学ぶ。「なぜサービスデザインが必要か」を経営層に伝える際の言語が本書には豊富に含まれる。ROI計算のフレームワーク、パイロットプロジェクトの設計方法、成果の測定手法——これらはデザイン実践者が最も苦手とする「組織内売り込み」を支援する。 本書の限界と補完 本書の分量（500ページ超）は、網羅性の反面、情報密度の高さに読者を圧倒することがある。辞書的に使う——特定の手法が必要になった時に該当章を参照する——という読み方が実践的だ。 また、本書はBtoCサービス（小売、ホスピタリティ、公共サービス）の事例が中心であり、BtoBサービスや内部業務プロセスの改善への応用は読者自身が翻訳する必要がある。 デザイン思考の基礎理解は本書の前提だ。デザイン思考を初めて学ぶ場合は、『デザイン思考の教科書』やIDEO流のd.schoolメソッドから入り、本書はその次のステップとして手にとるのが適切だ。 結論 本書が問うているのは「デザインを学んだ後、組織で何ができるか」だ。その問いに正面から向き合う一冊として、デザイン思考の実践者が組織への実装フェーズに入る際に参照する価値は高い。 理論と実践の間の谷を渡るための橋——本書の役割をステックドーンはそう定義した。その谷が想像より深いことに気づいた実践者にとって、本書は有効な足場を提供する。 --- 書誌情報 - 原著タイトル: This is Service Design Doing: Applying Service Design Thinking in the Real World - 著者: Marc Stickdorn, Adam Lawrence, Markus Edgar Hormess, Jakob Schneider - 出版: O'Reilly Media, 2018 - 邦訳出版: BNN新社, 2020 - ページ数: 568ページ（原著） - 対象読者: サービスデザイン・デザイン思考の実践者、UXリサーチャー、プロダクトマネージャー 関連リソース - サービスブループリントの使い方 - カスタマージャーニーマップ完全ガイド - ダブルダイヤモンド：デザイン思考の構造 - Change by Design — デザイン思考の原典 --- ### 書評『Solving Problems with Design Thinking——10の実践事例が示す、機能する条件』ジャン・リードカ他 URL: https://designthinking.studio/books/jeanne-liedtka-solving-problems-with-design-thinking/ > 3M・Intuit・デンマーク「良いキッチン」・ダブリン市など10の実践事例から、デザイン思考が組織でどう機能し、どう失敗するかを実証的に描いた稀有な一冊。理論書ではなく「使える条件」を探る実務書。 デザイン思考の書籍の多くは「方法論の解説」か「成功事例の讃美」のどちらかに傾いています。本書が際立っているのは、そのどちらでもないことです。「なぜデザイン思考がここでは機能したのか」を、組織の文脈・人物・プロセスの詳細から丁寧に解析する——その姿勢が、ビジネス書としての本書を分類しにくい、しかし希少な存在にしています。 著者のジャン・リードカ（Jeanne Liedtka）は、バージニア大学ダーデンスクールのビジネス教授であり、デザイン思考の「組織への効果」を実証研究の対象にしてきた研究者です。共著者のアンドリュー・キングとケビン・ベネットとともに、実際に現場でデザイン思考を使った管理職へのインタビューを重ね、10の事例を再構成しました。本書はコロンビア大学出版局から2013年に刊行されています（ISBN: 978-0231163569）。 --- 10の事例が選ばれた理由 本書の10事例は、企業規模・業種・地域の多様性を意図的に設計しています。3M、SAP、Intuit、Toyotaという大企業から、MeYou Healthというスタートアップ、そしてデンマークの「良いキッチン（The Good Kitchen）」プロジェクトやダブリン市民参加プログラムという公共・社会セクターまでを含みます。 この選択には意図があります。デザイン思考が「IDEO的なプロダクトデザイン」の文脈でしか機能しないという思い込みを、実証的に崩すことです。高齢者の食事配達サービスの再設計（デンマーク・The Good Kitchen）も、企業内の戦略策定プロセスの変革（SAP）も、同じデザイン思考のアプローチが異なる形で機能していることを示します。 --- 特に示唆に富む事例：3つのケース 3M：B2Bセールスの顧客関与再設計 3Mの事例は「デザイン思考をB2Bの営業プロセスに適用する」という、よく語られない領域を扱います。顧客企業の購買担当者と深い共感セッションを行い、彼らが本当に求めているもの——「サプライヤーとの交渉の煩雑さを減らすこと」——が、3Mが想定していた「製品の多様性・品質」ではなかったことが判明します。 この気づきが、3Mの顧客関与モデルの再設計につながります。「何を売るか」より「どんな課題を解くか」に焦点を移すことが、B2Bセールスに対するデザイン思考の最初の介入でした。 デンマーク・The Good Kitchen：高齢者食事配達の再設計 本書のなかで最もよく知られるようになった事例が、デンマーク政府の補助を受けた高齢者向け食事配達サービス「The Good Kitchen」の再設計です。 当初のサービスは、利用者である高齢者から不満が多かった。食事の質そのものよりも、「自分で食べるものを選べない」「決められた時間に届くだけ」という自律性の欠如が問題の本質だったことが、共感フェーズの観察で明らかになります。 デザインチームは高齢者の家庭を訪問し、どんな食事環境で暮らしているか、料理にどんな記憶を持っているかを観察・インタビューしました。この共感フェーズから生まれた解決策は、「調理済み食事を届ける」から「半完成品を届け、本人が仕上げられる設計にする」への転換でした。食べることだけでなく「作る行為への関与」が、高齢者の体験に何をもたらすかをプロトタイプで検証した結果です。 このケースが示すのは、デザイン思考が「サービスの内容」だけでなく「サービスを受ける側の尊厳・主体性」を設計の対象にできる点です。 Intuit：デザイン思考能力の組織的スケール Intuit（TurboTax、QuickBooks等を展開するフィナンシャルソフトウェア企業）の事例は、「個別プロジェクトの成功」ではなく「組織全体へのデザイン思考の定着」を題材にしています。 Intuitが採用したのは、「デザイン思考を教える専任チーム」ではなく、各事業部門に実践者を育てる分散型モデルです。Design for Delightというプログラムが、Intuitの組織文化にデザイン思考を染み込ませていく過程が描かれます。特に注目すべきは、経営層のコミットメントと部門横断の実践者コミュニティの両方が揃ったときに初めてスケールが機能した、という観察です。 --- 本書が明らかにする「機能する条件」 10事例を横断して見えてくるのは、デザイン思考が機能するための条件の共通点です。 リーダーシップのスポンサーシップが最初期に確立していること。 どの成功事例も、部門長以上の人物がプロジェクトの「政治的保護」を担っています。デザイン思考のプロセスは、時間がかかり・結果が不確実で・組織の慣習に反する側面を持つため、それを守れるスポンサーの存在が鍵になります。 「答えを出す会議」ではなく「問いを立てる会議」の設計。 成功事例に共通するのは、プロジェクト初期に「解決策を決める」スプリントではなく「問題の定義を全員で合意する」セッションに時間を割いていることです。 小さな実験で組織の信頼を稼ぐ順序。 デザイン思考を一気に全社展開した事例は本書には登場しません。全て、限定されたプロジェクト・部門・課題から始め、具体的な成果を可視化してから次の展開に進んでいます。 --- 読み方の注意点 本書の事例は、著者と関係のある組織への訪問調査をベースにしています。構造的に「成功事例」が選ばれやすい点は留意が必要です。各事例の「なぜ機能したか」は丁寧に分析されていますが、「なぜ機能しなかったか」の事例は別の書籍——たとえばデザイン思考の批判的評価——で補うと視点がより立体的になります。 また、10事例のうち数件は2010年代初頭のものであり、AIや生成AI時代のプロダクト開発環境とは異なる文脈での観察です。「条件」や「パターン」は参照できますが、施策の細部は現代の文脈に翻訳して使う必要があります。 --- この本を読むべき人 - デザイン思考を組織に導入しようとしているが、「どんな条件が揃えば機能するか」が不明な担当者 - 大企業・公共機関・社会セクターでデザイン思考を実践している（しようとしている）人 - IDEOやd.schoolの「デザイン思考の成功物語」を読んだ後、「では自分の組織では何が違うか」を考えたい人 --- 結論 『Solving Problems with Design Thinking』は、デザイン思考の「使い方」を教える本ではなく、「機能する文脈と条件」を実証的に探る本です。10事例は多様な組織・課題・地域にわたり、「デザイン思考はこういう場合にこう機能する」という条件の解像度を上げてくれます。 理論を学ぶのではなく、実践の判断材料を積み上げたい人に最適な一冊です。同著者のジャン・リードカ（人物記事）も参照してください。 --- 書誌情報・参考文献 - Liedtka, J., King, A., & Bennett, K. (2013). Solving Problems with Design Thinking: Ten Stories of What Works. Columbia Business School Publishing. — ISBN: 978-0231163569 / https://cup.columbia.edu/book/solving-problems-with-design-thinking/9780231163569/ - Liedtka, J. (2018). "Evaluating the Impact of Design Thinking in Action." Working paper, University of Virginia Darden School of Business — https://designatdarden.org/app/uploads/2018/01/Working-paper-Liedtka-Evaluating-the-Impact-of-Design-Thinking.pdf - Liedtka, J. author page — https://jeanneliedtka.com/books --- ### 書評『The Design of Business』ロジャー・マーティン——デザイン思考を「経営理論」で裏づける一冊 URL: https://designthinking.studio/books/design-of-business-roger-martin/ > トロント大学ロットマン経営大学院の元学長ロジャー・マーティンが、デザイン思考を「知識ファネル」と「アブダクション」という経営理論の論理構造で裏づけた一冊。ワークショップの手法は語れても、経営層への説明に詰まる実践者に理論の言葉を与える。 四半期に一度の役員会。新規事業チームがプロトタイプのデモを終え、拍手が起こった直後、CFOがひと言だけ挟む——「面白い。それで、これはどう売上や市場シェアにつながるんだ」。デザイン思考のワークショップを率いてきたリーダーは、そこで言葉に詰まる。「創造的だから」以上の答えを、役員会の言葉に翻訳できていなかったからだ。 『The Design of Business: Why Design Thinking is the Next Competitive Advantage』は、この沈黙を埋めるために書かれた本です。著者のロジャー・マーティン（Roger L. Martin）は、トロント大学ロットマン経営大学院の元学長（1998〜2013年在任）であり、Thinkers50（世界の経営思想家ランキング）の常連。IDEOのようなデザインファーム出身の実践者ではなく、経営学者の立場からデザイン思考を分析したという点が、本書を他の入門書と一線を画すものにしています。原著はハーバード・ビジネス・プレスより2009年に刊行（ISBN-13: 978-1422177808）。なお日本語訳の存在は確認できていません——本稿は原著をもとにした書評として執筆しています。 --- 知識ファネル——企業の知識はどう進化するのか マーティンが本書の中核に据えるのが「知識ファネル（Knowledge Funnel）」というモデルです。企業が扱う知識は、次の3段階を経て進化すると彼は説明します。 - Mystery（謎） — まだ何も分かっていない、未解明の問題領域 - Heuristic（経験則） — 試行錯誤を通じて見えてきた、再現性のある勘どころ - Algorithm（アルゴリズム） — 誰がやっても同じ結果が出る、標準化された手順 企業は成長するにつれて、Mystery（謎）に向き合う段階からHeuristic（経験則）を経て、最終的にAlgorithm（アルゴリズム）へと知識を磨き上げていきます。この過程そのものは合理的で、効率化・標準化は競争優位の源泉になります。 問題は、多くの成熟企業がAlgorithmの最適化に集中しすぎるあまり、新しいMysteryに向き合う筋力を失っているとマーティンが指摘する点です。過去のデータに基づいて磨き上げられたアルゴリズムは信頼性が高い一方、次の変化を予見する力を持ちません。デザイン思考の役割は、この「Algorithmに固まった組織」を、もう一度Mysteryの段階に引き戻すことにある——これが本書の核心的な主張です。 この主張の具体例として、マーティンが本書や関連の講演・論考でたびたび取り上げるのが、A.G.レイフリー（A.G. Lafley）体制下のプロクター・アンド・ギャンブル（P&G）です。消費者の生活に入り込み、まだ言語化されていないニーズ——すなわちMystery——を掘り起こす仕組みを組織に持ち込んだP&Gの取り組みを、Algorithmの最適化に偏りがちな大企業がMysteryへ回帰した事例として引き合いに出す、という趣旨の言及が本書には見られます。 この構造は、なぜ組織が新しい取り組みを避けるのかという心理的な側面とも地続きです。その仕組みはデザイン思考と認知バイアスで立体的に解説しています。 --- アブダクション——第三の論理としての仮説的推論 もう一つの理論的支柱が「アブダクション（Abductive Reasoning、仮説的推論）」です。マーティンは、ビジネスの意思決定を支える論理を次の3種類に整理します。 - 演繹（Deduction） — 前提から必然的に導かれる結論 - 帰納（Induction） — 過去のデータから一般法則を導く推論 - アブダクション（Abduction） — まだ証明されていないが、最も説明力のある仮説を立てる推論 演繹と帰納はどちらも「既に分かっていること」を土台にします。しかしアブダクションは、データがまだ揃っていない段階で「これが最も筋の通った説明ではないか」と仮説を立てる、いわば論理的な跳躍です。 ここでマーティンが持ち込むのが、信頼性（Reliability＝再現性・データの裏付け）と妥当性（Validity＝新しい価値への適合）というトレードオフです。既存のAlgorithmは信頼性が高い代わりに、新しい価値への適合度（妥当性）は保証されません。逆に、まだ検証されていない仮説は妥当性を追求できる一方、信頼性は低い。経営とは、この2つのバランスをどこに置くかという判断の連続だ、というのがマーティンの見立てです。 デザイン思考のプロトタイピングや仮説検証サイクルは、まさにこのアブダクションの実装だと本書は位置づけます。「作って、見せて、確かめる」という反復のプロセスは、単なる発想法の手続きではなく、信頼性の低い仮説を少しずつ検証可能な形にしていく論理的な営みである、という読み替えです。 本書がこのアブダクション的な跳躍の好例として挙げるのが、リサーチ・イン・モーション（RIM、BlackBerryの製造元）です。マーティンは、RIMが知識ファネルを素早く往復し、Appleに先駆けてスマートフォン市場に製品を投入した組織として、デザイン思考型の意思決定を体現する成功例に位置づけています。 もっとも、本書の刊行は2009年であり、BlackBerryが市場の主導権を失っていく凋落局面は2011〜2013年頃に本格化します。マーティンが執筆当時それを知る由もなかったことは踏まえた上で、刊行から十数年を経た今この事例を振り返ると、皮肉にも別の教訓が浮かび上がるようにも思えます——一度Mysteryへの跳躍に成功した組織が、その跳躍力を保ち続けられるとは限らない、という教訓です。物理キーボードという当時磨き上げた「アルゴリズム」に安住し、タッチスクリーンという次のMysteryへの再度の跳躍に踏み出せなかったことが、後年のRIMの失速につながったのだとすれば、本書の枠組みは奇しくも、自らが称賛した成功例の後日談までも説明してしまっているのかもしれません。 --- 『Change by Design』との補完関係——実践のブラウン、理論のマーティン 本書と同じ2009年に、もう一冊のデザイン思考の古典が刊行されています。IDEOの当時のCEO、ティム・ブラウンによる『Change by Design』です。 この2冊は、同じテーマを異なる立場から論じた「対になる古典」と言えます。ブラウンはIDEOという実践者の視点から、デザイン思考のプロセス（共感・発想・プロトタイピングの進め方）を豊富な事例とともに語りました。一方マーティンは、経営学者の視点から、そのプロセスがなぜ機能するのかを知識ファネルとアブダクションという論理構造で裏づけています。 ワークショップの「やり方」はブラウンの著作から学べます。しかし、それを役員会で「なぜ有効なのか」と問われたときに答える語彙は、マーティンの著作の方が用意してくれます。両者を合わせて読むことで、「実践できる」だけでなく「説明できる」デザイン思考の理解に近づけます。ブラウンの著作をさらに深く検証したい場合は、『Change by Design』を批判的に読み直す書評も参考になります。 著者のマーティンについては人物記事「ロジャー・マーティン」で、知識ファネルと「統合的思考（Integrative Thinking）」との関係をより詳しく解説しています。本書の位置づけを掴みたい場合は、デザイン思考（用語解説）で全体像を確認できます。 --- 知識ファネルの限界——診断と処方箋の分業 ここまで紹介してきた知識ファネルとアブダクションは、たしかに強力な診断ツールです。ただし読み終えて率直に思うのは、このモデルは「Algorithmに固着した組織が、なぜMysteryに戻れないのか」を説明する解像度は高い一方、「では実際にどう戻るのか」という実装面への踏み込みはやや薄い、という点です。P&Gの例が示すように、Mysteryへの回帰が奏功した組織の姿は事後的には明快に語れます。しかし、既存の収益源であるAlgorithmを回しながら、いつ・どの程度のリソースを未検証のMysteryへ振り向けるかという社内合意形成のプロセスまでは、本書のフレームだけでは十分に描き切れていません。 この余白を埋めるのが、まさにブラウンの『Change by Design』が語る実践プロセス（共感・発想・プロトタイピング）だと筆者は考えています。マーティンの理論は「なぜ変わるべきか」を経営の言葉で語る武器を与えてくれますが、「どう変わるか」の具体的な手続きは実践書に委ねる必要がある——両者は優劣で比べるものではなく、診断と処方箋という役割分担にある、というのが本稿の見立てです。 --- この本を読むべき人 - デザイン思考のワークショップ手法は一通り実践してきたが、それを経営会議の言葉で説明できずに苦戦している新規事業責任者・イノベーション推進担当者 - 『Change by Design』などの実践書は読んだが、「なぜ機能するのか」の理論的な裏づけを求めている人 - 「創造的だから」以上の言葉で、デザイン思考の価値を経営層に語りたい経営企画・戦略担当者 デザイン思考を初めて学ぶ入門読者にはやや抽象度が高く、まず実践のプロセスを掴みたい場合は前述の『Change by Design』から入る方が読みやすいかもしれません。 --- 結論 デザイン思考は、発想法でもワークショップの手法でもありません。マーティンが本書で示すのは、それが企業の知識がどう進化するかという経営理論である、という一線です。知識ファネル（Mystery→Heuristic→Algorithm）とアブダクションという2つのレンズは、自社の意思決定がどこに偏っているかを診断する道具になります。 次の経営会議の前に、自社の直近の意思決定を1つ選んでみてください。それはAlgorithm（過去データの最適化）に立っているのか、それともまだ検証されていないMysteryやHeuristicへの投資なのか。この問いを持てるようになることが、本書を読む一番の実利です。 --- 書誌情報・参考文献 - Martin, R. (2009). The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business Press. — ISBN-13: 978-1422177808（日本語訳の存在は本稿執筆時点で未確認） - Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperBusiness. — ISBN: 978-0061766084 - Thinkers50, "Roger Martin," thinkers50.com --- ### 書評『クリエイティブ・コンフィデンス』トム・ケリー＆デイヴィッド・ケリー URL: https://designthinking.studio/books/creative-confidence-review/ > 「誰もがクリエイティブになれる」という確信と、それを阻む恐怖心を克服するための具体的実践を、IDEO共同創業者のDavid KelleyとゼネラルマネージャーのTom Kelleyが語った書。デザイン思考の実践者にとって、スキル習得の前に読むべき一冊。 デザイン思考を学ぶとき、多くの人は最初に「手法」を探します。ポストイット・HMW・クレイジーエイト——これらのツールを習得すればデザイン思考ができるようになる、という期待です。しかし『クリエイティブ・コンフィデンス』は、その前に読まれるべき本です。 手法より先に「自分はクリエイティブになれる」という確信が必要だということを、徹底的に論じた本だから です。 著者について David KelleyはIDEOの共同創業者であり、スタンフォード大学d.schoolの創設者です。Apple初代マウスのデザインに関わった経歴を持ち、20世紀後半のデザイン思考普及における最重要人物の一人です。David Kelleyの人物像はこちらを参照してください。 Tom KelleyはDavidの弟で、IDEOのゼネラルマネージャーとして組織経営を担ってきた人物です（IDEOの共同創業者はDavid Kelleyら数名であり、TomはIDEO経営に深く関与した著名なパートナーですが、創業者ではありません）[要確認]。前著『発想する会社！』（2002年）でIDEOの革新的な企業文化を世に紹介し、ビジネス書としてのデザイン思考の認知を広げました。 本書の中心概念：創造的自信とは何か 「クリエイティブ・コンフィデンス（Creative Confidence）」は、 「自分にはアイデアを生み出し、それを実行に移す能力がある」という自己確信 と定義されています。 著者たちはこれを「才能」ではなく「スキル」として位置づけます。多くの人は幼少期に「自分には創造性がない」という判断を下す体験を持っています——絵が「下手」と言われた、アイデアを馬鹿にされた、「もっと現実的に考えなさい」と指導された——これらの体験が創造性への恐怖（Creative Phobia）を形成します。 本書の主張は明確です。 創造的自信は失われたのではなく、抑圧されているだけだ。 そして適切な練習と環境があれば、誰でも取り戻せる。この主張を、著者たちは多くのケーススタディと実践的なエクササイズで裏付けます。 第1部：恐怖の克服 本書の前半は、創造性を阻む心理的メカニズムの分析に充てられています。著者たちが特定する主要な「恐怖」は3つです。 判断される恐怖：アイデアを出すと批判される、笑われる、無視されるという予期が、アイデアを口にすること自体を抑制します。創造フェーズのブレインストーミングで「判断を保留する」というルールがあるのは、この恐怖への直接の回答です。 失敗の恐怖：試みること自体が失敗につながるという予期が、最初の一歩を踏み出すことを妨げます。デザイン思考が「プロトタイプを早く失敗させる」と強調するのは、失敗を「恥」ではなく「学習」として再定義するためです。 完璧主義の罠：「十分に良くなってから見せる」という姿勢が、フィードバックのサイクルを遅くし、最終的により大きな失敗を生みます。 この恐怖の克服には、David Kelley自身のがん闘病体験が挿話として登場します。生死に直面したとき、「自分は何に時間を使いたいか」という問いが明確になり、恐怖への向き合い方が変わった——という個人的な物語は、本書に抽象論でなく血の通った重みを与えています。 第2部：創造的自信の再構築 後半は実践的な内容です。「創造的自信を育てるための5つの方法」として、著者たちは以下を提示します。 小さな実験を積み重ねる：大きな変化ではなく「今日、一つだけ違うことを試みる」という積み重ねが、創造的自信の基盤を作ります。デザイン思考の反復プロセスは、この「小さな実験の積み重ね」を構造化したものです。 多様な経験を求める：同じ業界・同じコミュニティの中に留まるだけでは、アイデアの材料が枯渇します。本書はT字型スキル（特定分野の深さ＋幅広い経験）という概念を使い、多様な体験の蓄積が創造性を強化することを論じます。 好奇心をエンジンにする：「なぜ？」という問いを保ち続ける習慣が、観察力と問題発見力の基礎になります。これは共感フェーズで「子供のような好奇心でユーザーを観察する」という態度の理論的裏付けでもあります。 フィードバックループを作る：完成度の低いものを早く見せ、素早くフィードバックを得る習慣が、改善のサイクルを速めます。本書ではこれを「デザイン思考のプロトタイプ文化」として位置づけています。 責任を受け入れる：「自分にはアイデアを実行する責任がある」という姿勢が、創造的自信の最終段階です。単なるアイデアマンから「変化を実現する人」への転換を促します。 学術的バックグラウンド：Banduraの自己効力感 「クリエイティブ・コンフィデンス」という概念は、スタンフォード大学の心理学者Albert Banduraが提唱した「自己効力感（Self-Efficacy）」の理論的枠組みの上に構築されています。自己効力感とは「自分はある行動をうまく実行できる」という確信のことで、Banduraは1977年の論文でこれが行動変容の最も重要な予測因子の一つであることを示しました。 著者たちはBanduraの理論を明示的に援用し、 「創造的自信は生まれ持った才能ではなく、習得可能な自己効力感の一形態である」 という立場を取ります。この学術的裏付けが、本書を単なるモチベーション本ではなく、心理学的根拠のある主張として位置づけています。 デザイン思考との接続 本書をデザイン思考の文脈で読むとき、特に重要な章が「ガイドレール付きの自主性（Directed Autonomy）」です。創造的な自由と構造的なプロセスは矛盾しない——むしろ適度な制約が創造性を引き出すという主張は、デザイン思考のプロセス設計の根拠になっています。 「1分で8案」というクレイジーエイトの時間制約、「HMW」という問いの形式的制約——これらは「制約の中の自由」という設計思想の産物です。本書を読んだ後でこれらの手法を使うと、 なぜその制約がそのように設計されているかの理由が腑に落ちます。 批判的な読み方 本書への批判的な視点も存在します。著者たちの事例のほとんどがIDEOやスタンフォードという特権的な環境に由来し、 「失敗してもやり直せる」という前提が成立する文脈に偏っている という指摘があります。リソースの乏しい環境・失敗のコストが非常に高い職種（外科医・航空管制官など）での「クリエイティブ・コンフィデンス」の育て方は、本書では十分に論じられていません。 それでも、デザイン思考の実践者にとって本書が重要なのは変わりません。 「手法を学ぶ前に、自分の創造性への確信を育てる」 という優先順位の提示は、多くの実践者が見落としているものです。 こんな人に勧める デザイン思考のワークショップに参加したが「自分にはアイデアが出ない」と感じた人、チームに「批判が得意で創造が苦手」なメンバーがいる人、デザイン思考を組織に導入しようとして「文化の変革が先か、手法の習得が先か」という問いに直面している人——いずれにとっても、本書は示唆を提供します。 --- 書誌情報 - Tom Kelley & David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013, ISBN: 978-0385349369 - 日本語版: 『クリエイティブ・コンフィデンス　「創造力」はみんなの中に眠っている』, 日経BP, 2014, ISBN: 978-4822250249 --- 参考文献 - Albert Bandura, "Self-Efficacy: Toward a Unifying Theory of Behavioral Change," Psychological Review, 84(2), 1977 - Tom Kelley & Jonathan Littman, The Art of Innovation: Lessons in Creativity from IDEO, Currency/Doubleday, 2001 - Carol S. Dweck, Mindset: The New Psychology of Success, Random House, 2006 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009 --- ### 書評『デザイン思考が世界を変える』ティム・ブラウン — IDEOが伝える変革の本質とその先 URL: https://designthinking.studio/books/change-by-design-deep-review/ > IDEO元CEOのTim Brownが2009年に著したデザイン思考の古典的名著を深読みする。出版から15年以上が経過した今、この書籍が何を正しく予見し、何が更新されるべきかを批判的に検証する。 Tim Brown著『Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation』（2009年、HarperBusiness）。邦訳『デザイン思考が世界を変える』は2010年に早川書房から刊行された。 この本を初めて読んだのは出版直後でした。そして今、2026年に改めて読み直したとき、当時とは異なる読み方ができることに気づきます。本書が「何を正しく予見していたか」と「何が今日の文脈では更新されるべきか」の両面から、批判的に検証します。 --- 書籍概要 Tim BrownはIDEO（アイディオ）の元CEO（最高経営責任者）であり、本書執筆時はCEOとして在任していました。IDEOはDavid Kelleyが1991年に設立した、デザインとイノベーションのコンサルティング会社です。 本書の核心的な主張は「デザイン思考はデザイナーだけのものではなく、あらゆるビジネスリーダーが習得すべきイノベーション戦略だ」というものです。「デザイン思考」という言葉がビジネス界に急速に普及した背景には、この書籍が2008年のHarvard Business Review論文「Design Thinking」とともに果たした役割が大きい。 --- 核心メッセージを読み解く 「人間中心性」という根本思想 本書の基盤にある思想は「DesirabilityとFeasibilityとViabilityの交差点を探す」というフレームワークです。 - Desirability（望ましさ）： 人間的な観点から意味があるか - Feasibility（実現可能性）： 技術的に実現可能か - Viability（事業継続性）： ビジネスとして持続可能か この3円のベン図は今日でも有効な設計の羅針盤です。特に「Desirability（人間的な望ましさ）」を起点に置くことの意義は、2026年のAI時代においてむしろ増しています。技術的に何でも作れる時代に、「人間にとって本当に意味があるか」という問いが設計の核心になるからです。 実際にやってみると、このフレームワークをチームに共有するだけで「私たちはDesirabilityを本当に確認したか？」という問いが自然に生まれます。Feasibility・Viabilityの議論に偏りがちなプロジェクト会議に、人間的な視点を取り戻す効果があります。 プロトタイピング哲学の先見性 Tim Brownが本書で強調するプロトタイピングの思想——「早く、安く、多く試す。失敗は情報である」——は、2009年当時から見て前衛的でした。 「ペーパープロトタイプで充分だ」「完成させる前にユーザーに見せる」という主張は、完璧な計画を重視する日本の企業文化と対照的です。しかし実際にやってみると、プロトタイプを作ってユーザーに見せた瞬間に「1週間の会議では気づけなかった問題」が30分で明確になる体験を、多くの実践者が共有しています。 本書がプロトタイピングの章で示す「スケールしないプロトタイプ」の概念は、今日のリーンスタートアップ・アジャイル開発と完全に整合しています。Tim Brownがこれを2009年に明示的に述べていたことは、先見の明として評価されるべきです。 「創造的自信（Creative Confidence）」の民主化 本書全体を貫く思想は「創造的な問題解決の能力は、すべての人が持っている」というものです。Tom Kelley（IDEOのゼネラルマネージャー）とDavid Kelleyの兄弟が後に著書『Creative Confidence』でより詳細に展開したこの思想は、本書ですでに明確に表明されています。 デザイン思考を「デザイン専門家だけのスキル」から「ビジネスパーソン全員のスキル」へと位置付け直したことが、本書の最大の歴史的貢献です。 --- 2026年の視点で読み直す：更新されるべき点 AI時代のDesirabilityの問い直し 本書が書かれた2009年時点では、AIはデザイン思考の議論に登場しません。しかし今日、デザイン思考の実践者が向き合う最大の問いのひとつは「AI生成のソリューションをどう評価するか」「AIが提案するデザインのDesirabilityを誰が判断するか」です。 Desirabilityという概念自体は変わりませんが、それを確認するためのユーザーリサーチの方法・共感の手法は、AIとともにあるユーザーの現実を反映して進化する必要があります。 批判的思考との統合 前述の通り（デザイン思考への批判参照）、Natasha Jenをはじめとする批判者が指摘する「デザイン思考における批判的思考の欠如」は、本書の中でも明示的に扱われていません。本書が描くデザイン思考は「生成的（generative）」なプロセスとしての側面が強く、批評（critique）のプロセスが薄い。 これは本書の欠陥というより「2009年時点でのデザイン思考の語り方」の限界であり、今日の実践者はこの点を補完しながら本書を読む必要があります。 サステナビリティとデザイン思考の関係 本書ではサステナビリティへの言及が限定的です。しかし今日、デザイン思考の文脈でDesirabilityを考えるとき、「現在のユーザーへの望ましさ」だけでなく「将来世代・地球環境への望ましさ」という次元は不可欠になっています。 パタゴニアの設計思想のような実践は、本書が定義したDesirability・Feasibility・Viabilityの3円に「Sustainability（持続可能性）」という第4の円を追加する必要性を示しています。 --- こんな人に読んでほしい これからデザイン思考を組織に導入したい方に強くお勧めします。ツールの説明より「なぜデザイン思考が必要か」に多くのページを割いているので、経営層やマネージャーへの説明資料として使える論点が詰まっています。 デザイン思考に懐疑的な方にも読む価値があります。本書は「万能の解決策」として書かれていません。限定的な文脈での有効な思考法として、批判的に読む余地が随所にある。そのギャップを見つけながら読むと、デザイン思考の輪郭がかえって鮮明になります。 --- 書誌情報 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009（原著）ISBN: 978-0061766084 - ティム・ブラウン著、千葉敏生訳, 『デザイン思考が世界を変える——イノベーションを導く新しい考え方』, 早川書房, 2010, ISBN: 978-4152091635 --- 参考文献・関連資料 - Brown, Tim, "Design Thinking", Harvard Business Review, June 2008（本書の理論的基盤となったHBR論文） - Kelley, David & Kelley, Tom, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 - Martin, Roger L., The Design of Business: Why Design Thinking is the Next Competitive Advantage, Harvard Business Press, 2009 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 - Jen, Natasha, "Design Thinking is Bullshit", Config Conference, Figma, 2017（批判的視点の補完として） --- ### 書評『発想する会社！——世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法』トム・ケリー URL: https://designthinking.studio/books/the-art-of-innovation/ > IDEOのゼネラルマネージャーTom Kelleyが、IDEOの革新的な組織文化・ブレインストーミング手法・プロトタイプ哲学を公開した一冊。デザイン思考が「プロセス」として体系化される以前の、実践知の原点がここにある。 『発想する会社！』は、デザイン思考が「メソッド」として知られる前に書かれた本です。出版は2002年——d.schoolの設立（2004年）より前、Tim Brownによる『Change by Design』（2009年）より7年前。この本が世に出た時点では、「デザイン思考」という言葉はまだ一般的ではありませんでした。 にもかかわらず、本書を読むと今のデザイン思考の実践が言語化される以前から、IDEOが何をやっていたかがリアルに伝わってきます。方法論の前に、組織としての習慣と文化があった——その順序を、この本は証明しています。 --- 著者について Tom Kelleyは、IDEOのゼネラルマネージャーとして長年組織経営を担ってきた人物です。兄のDavid Kelley（IDEOの共同創業者でありStanford d.schoolの創設者）がデザインとエンジニアリングの側面を担ったのに対し、TomはIDEOの文化・組織運営・クライアント関係の側を支えました。前著『発想する会社！』の後、2005年には組織内のイノベーター10類型を提唱した『イノベーションの達人！』（"The Ten Faces of Innovation"）を発表しています。 なお、Tom KelleyはIDEOの共同創業者ではなく、David Kelleyらが創業した後に参加した人物です。本書の著者プロフィールでは「IDEOのゼネラルマネージャー」と明記されており、創業者表記は誤りです。 --- 本書が描くもの 本書の核心は3つのテーマです。 - ブレインストーミングの「本当の使い方」 「ブレインストーミング」という言葉は広く知られていますが、多くの場所での実践は、Alex Faickney Osbornが1953年に提唱したオリジナルの手法とは大きく異なります。Osbornは「批判の禁止」「量を求める」「便乗を歓迎する」「奇抜さを追求する」を原則として掲げました（"Applied Imagination," Scribner, 1953）。 TomはIDEOのブレインストーミングがなぜ機能するかを、具体的なルールと空間設計から説明します。IDEOが実践するのは「1時間に100アイデア」を目指すテンポであり、ホワイトボードへのリアルタイム記録であり、「批判の禁止」を担保するファシリテーターの役割です。ブレインストーミングの質はルール遵守より空間とリズムで決まる——これが本書の主張です。 - プロトタイプを「早く、粗く、頻繁に」 本書がIDEOの哲学として繰り返し強調するのが、「早いプロトタイピング」です。Tomはこれを「fail often to succeed sooner（早く失敗して、早く成功する）」と表現しています。この考え方は、後のLean Startup（Eric Ries, 2011年）のMVP概念とも接続します。 重要なのは、IDEOが作るプロトタイプは最初から精緻ではないという点です。段ボール・泡立てスポンジ・ガムテープで作られた試作品が、数十万ドルの開発費より多くの洞察をもたらすことがある——これはペーパープロトタイピング完全ガイドで示す原則と同根の発想です。 - 「ホットチーム」の設計 本書でTomが「ホットチーム（hot team）」と呼ぶのは、明確なプロジェクト目標・期限・多様な専門性を持つ小規模チームです。IDEOでは、プロジェクトごとに流動的にチームを組み直します。固定された組織図ではなく、「この課題に最適なメンバーを最適なタイミングで集める」という組み方が、組織の学習速度を決めると主張します。 この発想は、今でいうクロスファンクショナルチームの多様性設計の実践的な原型と見ることができます。 --- 読みどころと注意点 本書は事例の宝庫です。IDEOが関わったAppleのマウス設計、コカ・コーラのファウンテンマシン改良、医療機器の人間工学設計など、1990年代から2000年代初頭のプロジェクトが豊富に紹介されています。 ただし、事例の再現性については注意が必要です。Tomが紹介する多くの成功事例は、IDEOという特定の組織文化・クライアント関係・採用文化の文脈に依存しています。「IDEOがやっているから正しい」と受け取ると、文化のコピーと本質の見落としが起きます。 事例を「何が機能したか」の観察として読み、自分たちの文脈での実験設計に変換することが本書の正しい読み方です。d.schoolの創設者David Kelleyが語る「クリエイティブ・コンフィデンス」（自分がクリエイティブになれるという確信）は、Tomのこの本から7年後に兄弟で書いた『クリエイティブ・コンフィデンス』でより深く展開されています。 --- この本を読むべき人 以下に当てはまる場合、本書は具体的な実践のヒントを提供します。 - デザイン思考のフレームワーク学習より、「IDEOが実際に何をしているか」を知りたい - ブレインストーミングや会議の質を上げたいが、どこを変えれば良いか分からない - 組織にプロトタイプ文化を定着させたいが、事例が少ない 逆に、理論的背景・学術的根拠・組織変革の方法論を求める場合は、Tim Brownの『Change by Design』や、IBMのデザイン思考フレームワーク公式資料の方が適しています。 --- 結論 『発想する会社！』は、「デザイン思考」という言葉が生まれる前の実践の記録です。言語化以前の暗黙知が豊富に含まれているため、現代のデザイン思考フレームワークを学んだ後に読むと、「なぜそのプロセスが機能するか」の根拠が腑に落ちます。 メソッドの前に文化があった。文化の前に習慣があった。その順序を逆にしてはいけない——これが本書の最大のメッセージです。 --- ## 人物 ### IDEO パートナー / ゼネラルマネージャー URL: https://designthinking.studio/people/tom-kelley/ > IDEOのパートナー・元ゼネラルマネージャー。『The Art of Innovation』『The Ten Faces of Innovation』著者。IDEO共同創業者 David Kelley の弟。デザイン思考をビジネス実践の言葉で世界に伝えた。 Tom Kelley は、IDEOのパートナーであり元ゼネラルマネージャーです。デザイン思考の理論家というより、IDEOの現場で何百ものプロジェクトを経験した実践家としての視点から、組織のイノベーションを語る書き手として知られています。 IDEO共同創業者 David Kelley の弟であり、兄とともに同社の成長を20名規模から300名超のグローバルファームへと牽引しました。 著作による貢献 Tom Kelley の最大の貢献は、IDEOという「ブラックボックス」の中で何が起きているかを、ビジネスリーダーが読める言葉で可視化したことです。 『The Art of Innovation』（2001年） は、IDEOがどのようにイノベーションを生み出しているかを初めて体系的に解説した書籍です。観察、ブレインストーミング、プロトタイピング、クロスファンクショナルチームという方法論が、具体的なプロジェクト事例とともに描かれました。米国でビジネス書ベストセラーとなり、デザイン思考が経営の文脈で語られる契機のひとつとなりました。 『The Ten Faces of Innovation』（2005年） では、「悪魔の代弁者（Devil's Advocate）」——批判的な傍観者の役割——に組織のイノベーションが潰される構造を分析し、それに対抗する10種のイノベーター・ペルソナを提唱しました。「学習者」「コラボレーター」「セット・デザイナー」「経験建築家」など、それぞれのペルソナが組織の創造性をどう守るかが、豊富な実例とともに解説されています。 『Creative Confidence』（2013年） は、弟 David との共著です。「創造的自信（Creative Confidence）」——すべての人が持つ、新しいアイデアを生み出し行動する力——を取り戻すことをテーマとした作品で、著書の中で最も広く読まれています。 主な貢献 - デザイン思考の「現場の知恵」をビジネス書として言語化し、非デザイナーへ伝達した - 「悪魔の代弁者」問題を組織論として明確に定式化した（『The Ten Faces of Innovation』） - 組織イノベーションの担い手を「役職」ではなく「ペルソナ（姿勢と行動様式）」として定義した - David Kelley とともに「Creative Confidence（創造的自信）」の概念を世に広めた イノベーター・ペルソナ（10の顔） Tom Kelley が提唱した10のイノベーター・ペルソナは、デザイン思考実践の組織論として今日も参照されます。 | グループ | ペルソナ | |----------|----------| | 学習型 | 人類学者、実験者、花粉の運び手（Cross-Pollinator） | | 組織型 | ハードル選手、コラボレーター、ディレクター | | 構築型 | 経験建築家、セット・デザイナー、ケアギバー、ストーリーテラー | この分類は、「イノベーションは特別な才能ある人のものではなく、どの組織のどの人でも担える役割がある」というメッセージを持ちます。この視点は、デザイン思考の民主化を訴える Tim Brown の議論と相互補完的です。 David Kelley との関係 兄弟でありながら異なる強みを持つ二人は、IDEOとデザイン思考の普及において相補的な役割を果たしてきました。 David（兄）が d.school の創設やアカデミックな体系化を担った一方、Tom（弟）は現場の実務経験から言葉を紡ぐ実践家として、デザイン思考の「使い方」を世界に広めました。 --- 参考文献 - Tom Kelley & Jonathan Littman, The Art of Innovation: Lessons in Creativity from IDEO, America's Leading Design Firm, Currency/Doubleday, 2001 - Tom Kelley & Jonathan Littman, The Ten Faces of Innovation: IDEO's Strategies for Beating the Devil's Advocate and Driving Creativity Throughout Your Organization, Currency/Doubleday, 2005 - Tom Kelley & David Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All, Crown Business, 2013 --- ### IDEO 共同創業者 / スタンフォード大学 d.school 創設者 URL: https://designthinking.studio/people/david-kelley/ > IDEOの共同創業者であり、スタンフォード大学d.school（Hasso Plattner Institute of Design）を創設。デザイン思考の教育普及に大きく貢献した。 David Kelley は、IDEO の共同創業者であり、スタンフォード大学の Donald W. Whittier Professor of Mechanical Engineering です。 カーネギーメロン大学で工学修士号を取得後、1978年にデザイン事務所を設立。これが後にIDEOとなりました。 d.school の創設 2005年、SAP の共同創業者 Hasso Plattner からの3,500万ドルの寄付を受けて、スタンフォード大学に d.school（Hasso Plattner Institute of Design）を設立しました。 d.school はデザイン思考を学際的な教育プログラムとして体系化し、エンジニアリング、ビジネス、医学、教育など多様な分野の学生にデザイン思考を教えています。 主な貢献 - Apple の初代マウスのデザインを手掛けた - IDEO を David Kelley Design から世界的なデザインファームへと成長させた - 「Creative Confidence（創造的自信）」の概念を提唱 - デザイン思考を大学教育に導入した先駆者 弟の Tom Kelley との共著『Creative Confidence』は世界的なベストセラーとなりました。 デザイン思考の教育普及における Kelley の最大の遺産は、d.school が世界中の大学でのカリキュラムに影響を与えたことです。IDEO のショッピングカート再デザインは、彼の率いるチームが実践したデザイン思考の原型を世に示しました。 --- 参考文献 - David Kelley & Tom Kelley, Creative Confidence, Crown Business, 2013 --- ### IDEO 元CEO・現Chair URL: https://designthinking.studio/people/tim-brown/ > デザイン思考をビジネスイノベーションの中心概念として世界に広めた、IDEOの元CEO・現Chair。2008年のHarvard Business Review論文と2009年の著書『Change by Design』は、デザイン思考を経営の言語に翻訳した転換点となった。英国出身、Brunel University School of Industrial Design 卒業。 ティム・ブラウン（Tim Brown）は1962年に英国で生まれ、Brunel University のロンドン工業デザイン学部を卒業した後、Royal College of Art（RCA）で修士号を取得した。デザイナーとして 1987 年ごろに現 IDEO の前身組織に参加し、1991 年の IDEO 設立時から中核を担う。2001 年に CEO へ就任し、2019 年まで同職を務めた後、Chair（会長）に移行して現在に至る。 デザイン思考を「経営言語」に翻訳した転換点 2008 年 6 月、Harvard Business Review に掲載された論文「Design Thinking」は、デザイン思考を経営者に向けて説明した最初の体系的な文献のひとつとなった。ブラウンはここで、デザイン思考を「デザイナーの創造力を人間のニーズ・技術的実現性・事業持続性の交差点に応用するアプローチ」と定義した。この定義は今日でも最も引用される枠組みのひとつだ。 2009 年、HarperBusiness から刊行された Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation（邦題『デザイン思考が世界を変える』）は、その論文を一冊の本に展開したものだ。人間中心性（Human Centeredness）・多様性（Collaborative Thinking）・楽観主義（Optimism）・実験精神（Experimental）の4要素をデザイン思考の文化的基盤として描き、IDEO のプロジェクト事例——ショッピングカートの再設計、医療器具の人間工学的改良、国際開発への応用——を通じて読者を連れ回す構成は、当時のビジネス書の文脈で異色だった。2019 年には「変化の加速」と「AIの影響」を加えた拡張版が刊行されている。 IDEO を組織として育てる ブラウンが CEO に就いた 2001 年当時、IDEO はすでにプロダクトデザインの世界では著名な会社だったが、コンサルティング業務の範囲は製品デザインが中心だった。ブラウンの在任期間に IDEO はサービスデザイン・組織変革・公共政策・社会課題へと領域を広げ、世界 9 都市以上にオフィスを持つ組織へと成長した。 2010 年には社会課題に特化したプラットフォーム OpenIDEO を共同で立ち上げた。OpenIDEO は IDEO の手法をオープンに公開し、世界中の参加者が社会課題に対してアイデアを持ち寄るオンライン・プラットフォームとして機能している。コミュニティは医療アクセス・気候変動・教育など多様な課題に取り組んできた。 TED での問いかけ——「デザイナーは大きく考えるべきだ」 2009 年の TED 講演「Designers — think big!」はブラウンの思想を世界に届けた。デザイナーが個々の製品や画面を最適化することに集中するのではなく、システム全体・社会構造・大規模な行動変容に向けた問いを立てるべきだという主張は、デザイン業界の自己認識を揺さぶるものだった。この講演で彼が示した「プレイ（Play）」の重要性——子どもが遊びを通じて学ぶように、デザイナーも遊び心を持ってプロトタイプを繰り返すべきだという考え方——は、デザイン思考の実践コミュニティに広く浸透している。 思想の核——制約の交差点でのデザイン ブラウンが繰り返して語る枠組みが、Desirability（望ましさ）・Feasibility（実現可能性）・Viability（事業持続性）の3つの制約の交差点だ。デザイン思考はこの3つが重なる領域を探す実践である、という定義は、スタンフォード d.school の教材をはじめ世界中の教育プログラムで採用されている。 この枠組みが力を持つのは、単に「ユーザーが望むものを作れ」という主張ではなく、「市場にとって現実的で、技術的に実現可能で、かつ人間にとって意味のあるもの」の交差点を探す知的プロセスとして、デザインの役割を経営会議の言語で語れるようにしたからだ。 デザイン思考への接続 ブラウンの枠組みは、デザイン思考の各フェーズに以下のように関係する。 共感フェーズでのフィールドリサーチと観察は、Desirability（人間にとっての望ましさ）を発見するための入口だ。机上の仮定ではなく、現場でユーザーの行動・感情・文脈を直接収集することが、デザイン思考の始まりだとブラウンは強調する。 プロトタイプフェーズでは、「早く失敗する（Fail Early, Fail Often）」という文化をブラウンが IDEO で制度化したと言える。安価な試作を素早く繰り返し、フィードバックを得て修正するサイクルは、Change by Design でも中核に置かれている。 定義フェーズにおける問いの立て方——「どうすれば〜できるか（How Might We）」——は、IDEO が普及させた問いの型であり、ブラウンが言う「可能性を開く問い」の実践的な表現だ。 デイヴィッド・ケリーがスタンフォードにデザイン思考を持ち込んだとすれば、ブラウンはそれをビジネスの現場へ持ち込んだ人物だ。ロジャー・マーティンのビジネス思考とデザイン思考の接合と並走しながら、ブラウンは IDEO の実践から帰納された「動くデザイン思考」の言語を世界に届けた。 --- 参考文献 - Tim Brown, "Design Thinking", Harvard Business Review, June 2008 - Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperBusiness, 2009（拡張版 2019） - Tim Brown, TED Talks: "Designers — think big!", TED2009, 2009 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 関連記事: Change by Design / デイヴィッド・ケリー / ロジャー・マーティン / 共感フェーズ / プロトタイプフェーズ --- ### SAP共同創設者・d.school創設者 URL: https://designthinking.studio/people/hasso-plattner/ > 世界最大のエンタープライズソフトウェア企業SAPの共同創設者にして、スタンフォード大学d.schoolへの主要資金提供者。実業家としての成功を基盤に、デザイン思考の教育機関を世界に広めた起業家。 ハッソ・プラットナー（Hasso Plattner、1944年生まれ）は、世界最大規模のエンタープライズソフトウェア企業SAPを共同創設した実業家であり、スタンフォード大学の「d.school」として知られる Hasso Plattner Institute of Design の設立に3500万ドルを提供した人物です。デザイン思考をアカデミアとビジネスの双方に根付かせた最大の功労者のひとりとされています。 経歴 1944年、ドイツ・ベルリン生まれ。カールスルーエ工科大学でコンピュータサイエンスを学んだ後、IBMに入社。1972年に5名の元IBM社員とともにSAPを創業しました。SAP（Systems, Applications & Products in Data Processing）は現在、世界180カ国以上にユーザーを持つエンタープライズリソース管理（ERP）のグローバルリーダーです。 プラットナーはSAPの会長を長年務めながら、自身の財産をテクノロジー教育に投資し続けています。ドイツのポツダムに設立した Hasso Plattner Institute（HPI）は、デジタル工学の研究大学として欧州でも高い評価を受けています。 d.school創設への関与 2004年、プラットナーはスタンフォード大学にいたデイヴィッド・ケリーと出会い、デザイン思考の教育に大きな可能性を感じました。2005年、3500万ドルの寄付をもとにHasso Plattner Institute of Design at Stanford（通称 d.school）が設立されます。 d.schoolは正式な学位プログラムではなく、スタンフォード大学の異なる学部の学生が集まり、チームでデザイン思考を実践するためのプロジェクトベースの場です。「知識を教える場ではなく、創造的自信（Creative Confidence）を育む場」というビジョンはプラットナーが支持したものであり、デイヴィッド・ケリーの哲学と深く一致していました。 デザイン思考とエンジニアリングの融合 プラットナーがデザイン思考に共鳴した背景には、SAPでの事業経験があります。世界中の企業が使う複雑なソフトウェアを開発してきた中で、「技術的に正しいソフトウェアが、ユーザーに使われない」という現実を何度も目撃してきたからです。 エンジニアリングの思考だけでは解決できない問題——ユーザーがどう感じ、どう使い、何を本当に必要としているか——を解くための方法論として、デザイン思考のフレームワークを評価しています。SAP自身もデザイン思考を製品開発に取り込み、SAP Fioriのような人間中心設計のプロダクトラインを生み出しています。 HPI-Stanford Design Thinking Research プログラム d.school設立後、プラットナーはデザイン思考の学術的な研究基盤を作るため、HPI-Stanford Design Thinking Research（DTR）プログラムを共同設立しました。このプログラムは、「デザイン思考はなぜ機能するのか？」という問いに科学的に答えることを目指しています。 年次の研究成果は書籍シリーズ "Design Thinking Research" としてSpringer社から刊行されており、デザイン思考の理論的基盤の確立に貢献しています。認知科学、組織行動学、教育工学など多角的な視点から、デザイン思考の有効性と限界を検証しています。 実業家からの視座 プラットナーがデザイン思考の普及において果たしたもうひとつの役割は、「デザイン思考は起業家や経営者にとって実用的である」というメッセージを体現したことです。 TED や World Economic Forum での発言、および自身のキャリアを通じて、デザイン思考が「クリエイティブな人のためのもの」ではなく、複雑な問題に直面するすべての実務者の思考法であることを示し続けています。Tim Brown が著作と講演でデザイン思考を広めたとすれば、プラットナーはその教育インフラへの資金投資で広めた人物といえます。 ポツダムHPIとドイツへの展開 ドイツのポツダムに設立した Hasso Plattner Institute（HPI）では、d.schoolのアプローチをヨーロッパ文脈で実践するデザイン思考プログラムが提供されています。HPI School of Design Thinkingは欧州最大規模のデザイン思考教育機関として、ドイツ国内外の企業や学生を受け入れています。 --- 参考文献 - Hasso Plattner, Christoph Meinel & Larry Leifer (Eds.), Design Thinking Research: Making Design Thinking Foundational, Springer, 2016 - Stanford d.school, "About d.school", dschool.stanford.edu - SAP SE, "Hasso Plattner — Founder and Chairman", SAP.com - Larry Leifer & Martin Steinert, "Dancing with Ambiguity: Causality Behavior, Design Thinking, and Triple-Loop-Learning", Procedia Social and Behavioral Sciences, 2011 --- ### Stanford 機械工学教授 / Center for Design Research 創設者 / ME310 プログラム発展の中心人物 URL: https://designthinking.studio/people/larry-leifer/ > スタンフォード大学機械工学部教授。Center for Design Research を創設し、グローバルな産学連携デザイン教育プログラム ME310 を長年にわたって発展させた。d.school 設立に関わったデザイン思考の工学的基盤の確立者。 Larry Leifer は、スタンフォード大学機械工学部（Department of Mechanical Engineering）の教授であり、デザイン思考を「工学教育」の文脈に根づかせた中心人物のひとりだ。 Center for Design Research の設立 Leifer は Stanford に Center for Design Research（CDR）を設立し、デザインと工学の接点を研究するアカデミックな基盤を作った。CDR は、デザインプロセスそのものを研究対象とする——どのようにエンジニアや設計者が問題を定義し、解決策を探索するか——というメタレベルの問いに取り組んでいる。 この研究姿勢が、後のデザイン思考の「プロセスの明文化」に貢献した。デザイン思考をフレームワークとして語れるようになった背景には、Leifer らによる実証的なデザインプロセス研究の蓄積がある。 ME310：産学連携グローバルデザイン教育の実験場 ME310 は Stanford の機械工学部で長年続いてきたグローバルなデザインイノベーション教育プログラムだ。1969年に産学連携のコース設計として始まり、Leifer がその発展において中心的な役割を果たした。 このプログラムの特徴は、Stanford の学生と世界各国のパートナー大学の学生がチームを組み、実際の企業スポンサーの課題に取り組むという構造にある。1年間のプロジェクトベースの学習を通じて、学生たちは人間中心のデザインプロセスを実際の複雑な問題に適用する経験を積む。 ワークショップで「ME310出身の実務者」と仕事をすると分かることがある。彼らは「正解があるはずだ」という前提を持たずに問題に入る。不確実性の中でプロトタイプを作り、失敗を情報として扱う姿勢が体に染みついている。Leifer のプログラムが育てた実践的なマインドセットだ。 d.school との関係 2005年、Hasso Plattner の寄付によって Stanford に d.school（Hasso Plattner Institute of Design）が設立された際、Leifer はその設立メンバーのひとりとして関わった。David Kelley が d.school の看板として知られるのに対し、Leifer は工学サイドからデザイン思考の理論的・教育的基盤を支えた人物として位置づけられる。 d.school の設立は、デザイン思考を「デザイナーの手法」から「あらゆる分野の問題解決者の思考法」へと拡張する転換点だった。その背景には、ME310 で長年にわたり学際的なチームを動かしてきた Leifer の実践知が存在する。 実務者への示唆 Leifer の仕事から実務者が学べることは、デザイン思考を「使う」前に「研究する」姿勢の重要性だ。CDR が行ってきたデザインプロセス研究は、ファシリテーターが「なぜこの手法がうまく機能するか」を説明できるための知的基盤を提供している。 ツールとしてデザイン思考を使うだけでなく、そのプロセスを観察し記述し改善していく——Leifer のアカデミックなアプローチは、デザイン思考の実践者が「なんとなくうまくいった」から「なぜうまくいったかを説明できる」レベルへ成長するための姿勢を示している。 --- 参考文献 - Stanford University, Center for Design Research, cdr.stanford.edu - Stanford University, ME310 Global Design Innovation, me310.stanford.edu - Hasso Plattner Institute of Design at Stanford (d.school), dschool.stanford.edu --- ### UCバークレー・ハース経営大学院 ティーチング・プロフェッサー URL: https://designthinking.studio/people/sara-beckman/ > 1993年にUCバークレーMBAカリキュラムにデザイン思考を持ち込んだ先駆者。「学習プロセスとしてのイノベーション」フレームワークを提唱し、ビジネスとデザインと工学の境界を越えた教育モデルを構築してきた。 サラ・ベックマン（Sara Beckman）は、UCバークレーでデザイン思考が「流行語」になる20年以上前から、その実践をMBAカリキュラムに組み込んだ人物だ。 1993年、彼女はハース経営大学院で「デザインを戦略的ビジネス課題として考える（Design as a Strategic Business Issue）」という初のデザインコースを立ち上げた。当時、ビジネススクールでデザインを正課科目として教えようとすること自体が、組織の内外で「異端」に見えた時代だった。 --- 経歴：エンジニアリングからビジネスへの境界越え スタンフォード大学で産業工学・エンジニアリングマネジメントの学士・修士・博士号、および統計学の修士号を取得。純粋な工学の訓練を受けたのち、コンサルティング会社Booz, Allen & Hamiltonの「オペレーション管理サービス部門」に参加し、企業の製造・開発プロセス改善に従事した。 その後ヒューレット・パッカードで「チェンジマネジメントチーム」を率いた経験が、「組織が変わる時に何が起きるのか」を身体で知る機会になった。HP在籍時の経験が、後のイノベーション教育の土台を作った。 UCバークレーに着任後、ハース経営大学院の教授としてのみならず、工学部機械工学科にも籍を置く「バウンダリー・スパナー（境界を越える者）」として活動してきた。経営学と工学という、カリキュラム上も文化上も分断されやすい2つの領域を、同一人物が行き来することの意味を体現した教育者だ。 --- コア理論：「学習プロセスとしてのイノベーション」 ベックマンの学術的貢献で最も引用されているのは、スタンフォード大学機械工学科のAdjunct ProfessorでありPoint Forwardの創業者でもあるマイケル・バリー（Michael Barry）との共著論文 "Innovation as a Learning Process: Embedding Design Thinking" だ（California Management Review, Vol.50, No.1, Fall 2007, 累計700件以上の引用）。 この論文が提示したイノベーションモデルの核心は、「デザイン思考は特殊な創造性の発揮ではなく、人が学ぶ方法そのものを革新プロセスに埋め込むことだ」という命題だ。 モデルは4象限の構造を持つ。「観察・感覚」「フレーミング・意味付け」「アイデア創出」「プロトタイピング・実験」という4つの学習様式が、イノベーションのプロセスを構成する。ビジネス側のアクターが「測定可能な成果」に向かって収束しようとするのに対し、デザイン側のアクターは「文脈の理解と意味の発見」に時間を割く——この緊張を「対立ではなく補完」として機能させるフレームワークとして設計した。 このモデルは、d.schoolの5フェーズと並んで、デザイン思考の学術的参照点として世界各地の大学教育に採用されている。 --- 教育上の実践：「Managing New Product Development」の創設 工学部のAlice Agogino教授との共同で立ち上げた「Managing New Product Development」コースは、UCバークレーの授業の中でも「歴史的に最も人気のある科目の一つ」として記録されている。 このコースの設計は、当時としては革新的な試みだった。工学・ビジネス・デザインの学生が1つのチームを組み、同一学期内で「アイデアから最初のプロトタイプへ」を完結させる。学部や大学院の縦割りを横断する設計が、参加者に「自分の専門知識だけでは解けない問題を扱う体験」を与えた。 この設計思想は後に、「Problem Finding Problem Solving（PFPS）」コースへと発展する。批判的思考・デザイン思考・システム思考を統合的に扱うこのコースは、「Berkeley Innovative Leader Curriculum」の核科目として位置づけられた。 --- ジェイコブズ・デザインイノベーション研究所と越境型教育 2013年、UCバークレーにポール＆ステイシー・ジェイコブズ記念財団の支援を受けて「Jacobs Institute for Design Innovation」が設立される際、ベックマンは初代チーフ・ラーニング・オフィサー（CLO）として参加した。 ハース経営大学院と工学部College of Engineeringの双方に50%ずつ在籍するという異例の分担で、デザイン関連カリキュラムを工学教育全体に組み込む取り組みを主導した。学部横断の「Certificate in Design Innovation」創設にも貢献し、ビジネス・エンジニアリング・デザインの三領域をつなぐ制度的な仕組みを作った。 「Collaborative Innovation」コースでは、アートプラクティス・演劇・ダンスのパフォーマンス研究とビジネスの視点を統合するという、さらに大胆な教育実験を行っている。分野の違いが生み出す摩擦と創造性の関係を、授業そのものの設計で体験させようとするアプローチだ。 --- 受賞歴と影響 UCバークレーでの教育活動に対してハース校内の「Distinguished Teaching Award」を3度受賞し、キャンパス全体の「Distinguished Teaching Award」も受けている。2018年には「Carol D. Soc Distinguished Graduate Student Mentoring Award for Senior Faculty」を受賞。教育の質と学生支援の両面で、組織内での評価が高い。 ベックマンの存在が際立っているのは、教授法の工夫よりも「どこにポジションを置くか」という選択そのものにある。ビジネスでも工学でもデザインでもない「その間」に立ち続けることで、それぞれの言語を使いながら異なる文化を接続してきた。 --- デザイン思考教育への含意 ベックマンの軌跡から、デザイン思考教育の設計に関して一つの示唆が得られる。 デザイン思考を「手法のセット」として教えると、学習者は手法を覚えるがプロセスを内面化しない。「なぜその手順が存在するのか」を「どのように人は学ぶか」という普遍的な認知モデルに接続して教えると、手法の応用可能性が格段に広がる。 「イノベーションを学習プロセスとして捉える」というベックマン＆バリーのフレームは、まさにこの「なぜ」への答えだ。デザイン思考の5フェーズを手順書として使う実践者と、その背後の学習モデルを理解して使う実践者では、未知の文脈への適応力に差が出る。 --- 参考文献・出典 - Beckman, S.L., & Barry, M. (2007). Innovation as a Learning Process: Embedding Design Thinking. California Management Review, 50(1), 25–56. https://journals.sagepub.com/doi/10.2307/41166415 - UC Berkeley Haas, "Sara L. Beckman – Faculty Profile". https://haas.berkeley.edu/faculty/beckman-sara/ - Berkeley Haas News, "Design Thinking Pioneer Sara Beckman to Expand Role on Campus". https://newsroom.haas.berkeley.edu/design-thinking-pioneer-sara-beckman-expand-role-campus/ - Berkeley Engineering, "Design: The new toolkit for teaching engineering" (2013). https://engineering.berkeley.edu/2013/09/design-new-toolkit-teaching-engineering --- 関連記事 - ロジャー・マーティン——統合的思考とビジネス経営大学院でのデザイン思考 - ハッソ・プラットナー——d.schoolとデザイン思考教育の制度化 - デザイン思考の教育への応用 - イノベーションの技法——Tom Kelley『発想する会社！』書評 --- ### Wicked Problems概念の提唱者・デザイン方法論の先駆者 URL: https://designthinking.studio/people/horst-rittel-wicked-problems-origin/ > 1973年にMelvin M. Webberとの共著論文「Dilemmas in a General Theory of Planning」でWicked Problemsの概念を提唱。「解けない問題」として記述されたこの枠組みは、後のデザイン思考・政策デザイン・システム思考の理論的基盤となった。 「デザイン思考はなぜ複雑な問題に有効なのか」——この問いの理論的地盤を作った人物が、ホースト・リッテル（Horst W. J. Rittel）だ。 現代のデザイン思考では、Richard Buchananの1992年論文やIDEOの事例が語られることが多い。しかしその背後にある根幹的な概念——「Wicked Problems（邪悪な問題、悪問題）」——を生み出したのはリッテルだった。 IBM、政府機関、デザインスクールなど、知識産業のほぼあらゆる文脈で参照されている概念だ。しかし提唱者の名が語られることは少ない。本稿では、リッテルの思想の原典に立ち返り、その理論がデザイン思考に与えた影響を追う。 --- ホースト・リッテル：その生涯と軌跡 バイオグラフィ ホースト・ヴィルヘルム・ヤコブ・リッテル（Horst Wilhelm Jakob Rittel）は1930年にドイツで生まれた。 戦後ドイツの知的環境の中で学んだリッテルは、数学・建築・デザイン理論の交差する領域で独自の知的プロジェクトを育てた。1950年代後半から60年代にかけて、西ドイツのウルム造形大学（Hochschule für Gestaltung Ulm）でデザイン理論を教えた。 ウルム造形大学はバウハウスの精神的後継として知られ、デザインを社会的・政治的実践として位置づける知的伝統を持っていた。リッテルがここで得た「デザインは価値判断の問題である」という認識は、後のWicked Problems概念の核心をなす。 1960年代後半、リッテルはカリフォルニア大学バークレー校（UCB）の環境デザイン学部に移り、都市計画理論家のMelvin M. Webberとの協働が始まった。この交差がWicked Problemsを生んだ。 晩年はドイツのシュトゥットガルト大学でも教え、1990年に没した。 時代的文脈：システム思考への懐疑 リッテルが活動した1960〜70年代は、オペレーションズ・リサーチとシステム分析の全盛期だった。第二次世界大戦中に発展した数理的問題解決手法が社会問題に応用され、「あらゆる問題はデータと計算で解決できる」という楽観的な合理主義が知識人の間に広まっていた。 都市計画もその影響を受け、「マスタープラン」や「科学的都市設計」への信頼が高まっていた。政府は複雑な社会問題——貧困・交通渋滞・環境汚染——を、コンピュータと専門家集団によって解決できると信じていた。 リッテルは、この楽観主義への根本的な異議を持っていた。「合理的な計算が難しい」のではなく、「問題の定義そのものが合意できない」のではないか——この疑念が1973年の論文の出発点だ。 --- 1973年論文「Dilemmas in a General Theory of Planning」 論文の位置づけ 1973年にPolicy Sciences誌（Volume 4, Issue 2）に発表された "Dilemmas in a General Theory of Planning" は、リッテルとWebberの共著論文だ。 ページ数は14ページ（pp.155-169）と短い。しかしこの14ページが、後世のデザイン思考・政策立案・システム思考・組織論に与えた影響は計り知れない。Google Scholarでの被引用数は数千件に上り、社会科学・デザイン研究の双方で古典的文献として参照され続けている。 タイトルにある「Dilemmas（ジレンマ）」という語は意図的に選ばれている。リッテルとWebberが指摘するのは、計画（Planning）の実践が理論的に解消できない根本的なジレンマを内包しているという事実だ。 Tame Problems と Wicked Problems の対比 論文の核心は、「길든された問題（Tame Problems）」と「邪悪な問題（Wicked Problems）」の対比だ。 Tame Problemsは、数学の方程式やチェスのゲームのような問題だ。問題が明確に定義でき、解法の手順が存在し、正解かどうかを判定できる基準がある。問題を解いても問題の性質は変化しない。 対してWicked Problemsは、社会・政治・文化が絡み合う実践的問題に現れる性質を持つ。リッテルとWebberは論文の中で10の特性を列挙している。 特性1：Wicked Problemsには決定的な定式化がない。 何が問題かを理解することと、解決策を見つけることは分離できない。問題の定義が変われば、解決策も変わる。都市の犯罪率を例にとれば、「警察官の不足」「貧困」「教育機会の欠如」「コミュニティの崩壊」のいずれを問題と定義するかで、解決策は全く異なる。 特性2：Wicked Problemsには「試行終了」のルールがない。 Tame Problemsでは「解けた」瞬間が存在する。しかしWicked Problemsは、問題に取り組み続けることはできるが、「解決完了」を宣言できる客観的基準がない。いつ問題から手を引くかは、リソース・政治判断・倦怠感の問題であり、論理的な完結とは無関係だ。 特性3：Wicked Problemsの解決策は正解でも間違いでもなく「より良いか、より悪いか」で評価される。 Tame Problemsには明確な正解がある。しかし都市計画・社会政策・組織設計の解決策は、「正しいかどうか」ではなく「どの価値観の観点から見てより良いか」で評価される。異なる利害関係者は異なる評価を下す。 特性4：解決策を試す行為は不可逆的結果をもたらす。 科学実験は繰り返し可能だが、社会政策の実施は実験できない。一つの政策を試みると、社会はその政策に適応・反応し、元の状態には戻れない。解決策は「本番実施」であり、「試作品のテスト」ではない。 特性5：Wicked Problemsの解決策の数は原理的に列挙できない。 Tame Problemsでは解法の候補を体系的に列挙できる。しかし「都市の貧困をなくすには」という問いに対する解決策の候補は、原理的に無限に存在する。すべての可能性を評価したうえで最善策を選ぶことは不可能だ。 特性6：各Wicked Problemは本質的にユニークだ。 類似する問題はあっても、まったく同一の問題は存在しない。前回のプロジェクトの解決策が今回も有効だという保証はない。各問題は、特定の時間・場所・人間関係の文脈に埋め込まれた固有の問題だ。 特性7：全てのWicked Problemは別のWicked Problemの症状だ。 交通渋滞は都市構造の問題であり、都市構造は住宅政策の問題であり、住宅政策は経済格差の問題であり……というように、Wicked Problemsは入れ子になっている。どの階層で問題を捉えるかの選択そのものが、価値判断だ。 特性8：Wicked Problemsの「解決策の説明」と「問題の定式化」の間には不一致がある。 Tame Problemsでは問題を定式化できれば解法が示唆される。しかしWicked Problemsでは、同じ問題の定式化から全く異なる解決策が提案される場合がある。逆に、異なる問題の定式化から類似した解決策が導かれることもある。 特性9：Wicked Problemを「間違えて解く」ことの結果は深刻だ。 数学の問題を間違えても、次の問題を解けばよい。しかし社会政策を「間違えて実施」した場合、その結果は現実の人間の生活に取り返しのつかない影響を与える。このため計画立案者は、「試行錯誤」に対して道義的責任を問われる。リッテルはこれを「No trial and error（試行錯誤の禁止）」と呼んだ。 特性10：計画立案者は「間違い」を犯す権利を持たない。 上の特性と連動するが、Wicked Problemsに取り組む実践者は科学者とは異なる倫理的状況にいる。科学者の失敗は知識の前進だが、社会計画の失敗は人々の苦しみを意味する。 --- 理論の核心：科学的合理主義への根本批判 「第一世代の問題解決」から「第二世代」へ リッテルはのちに、問題解決のアプローチを「第一世代」と「第二世代」に分類した。 第一世代の問題解決は、専門家が問題を定義し、最適解を計算し、実施する線形モデルだ。「何が問題か」は専門家が知っており、「どう解くか」は科学的方法で決定できるという前提に立つ。 第二世代は、問題定義そのものが問題であるという認識から出発する。「何が問題か」を決めるのは専門家だけではなく、影響を受ける全ての当事者だ。計画立案は一方向的な専門家による解決ではなく、利害関係者との対話的プロセスでなければならない。 この「第二世代」の認識は、現代のデザイン思考の根幹にある。ユーザーインタビューによって「問題の定義を共に作る」こと、プロトタイプによって「解決策の試みと問題の再定義を同時に行う」こと——これらはWicked Problems概念が示した問題の性質から論理的に導かれる実践だ。 「Argumentative Planning」の構想 Wicked Problems論文の後、リッテルは「Argumentative Planning（論証的計画）」という概念を発展させた。 合理的計画モデルでは、最適解は計算によって導出される。しかしリッテルは、計画は本質的に論証（argument）の問題であり、異なる価値観・利害関係・前提条件を持つ人々の間での対話と交渉によって形成されると主張した。 この構想は、現代の参加型デザイン（Participatory Design）・共同創造（Co-creation）・デザインジャスティス（Design Justice）といった実践の理論的先駆けとして読むことができる。 --- リッテルからブキャナン、そして現代のデザイン思考へ ブキャナンによる「反転」 Richard Buchananが1992年に発表した "Wicked Problems in Design Thinking"（Design Issues, Vol.8, No.2）は、リッテルの概念をデザイン実践の文脈に接合した重要論文だ。 リッテルの原論文では、Wicked Problemsは半ば悲観的なフレームで描かれた——計画立案者が直面する解決不可能な困難として。Buchananはこれをデザイン的思考の存在理由として反転させた。 デザイン思考は不確定性（indeterminacy）の条件下で機能する。デザイナーは問題が完全に定義されるのを待たない。問題を定義する行為そのものが、デザインの作業に含まれている。 Buchananの「反転」によって、Wicked Problemsは「困難な問題の記述」から「デザイン的アプローチが必要とされる問題の定義」へと変わった。リチャード・ブキャナンが担ったのは、リッテルの概念へのデザイン思考からの応答だった。 現代の実践への影響線 リッテルの概念が現代のデザイン思考に与えた影響は、少なくとも3つの方向で追える。 問題定義フェーズの正当化: デザイン思考の「Define」フェーズで「HMW（How Might We）クエスチョン」を使って問題を再定義する実践は、「問題の定義自体が問題解決の一部」というリッテルの洞察から直接導かれる。 プロトタイプの倫理的意義: Wicked Problemsの「試行は不可逆的結果をもたらす」という特性は、低コストのプロトタイプで素早く試すことの倫理的正当性を与える。本実装の前に最小限の形で試すことは、リスクを社会に押しつけない設計倫理だ。 ステークホルダー参加の必然性: Wicked Problemsは専門家だけでは定義できない。これは、ユーザーリサーチ・共創ワークショップ・利害関係者のマッピングといった実践が、単なる品質改善策ではなく問題の性質に対応した方法論的必然であることを示している。 --- リッテル思想の現代的限界と拡張 Wicked Problems概念への批判 リッテルの概念は広く受容されたが、批判もある。 一つは「問題の分類の恣意性」だ。どの問題がTameでどれがWickedかの境界は自明ではない。Wicked Problems概念を使うことで、問題を複雑化して解決を先送りにする言い訳として機能するリスクがある。 もう一つは「解決不可能性の過度な強調」だ。リッテルの10の特性は、Wicked Problemsに対して「完全な解決はできない」という認識を与える。これは正確だが、「だから何もできない」という諦念を生むリスクも孕んでいる。 Buchananの反転が果たした役割の一つは、まさにこの諦念を「デザイン的な前進」に置き換えることだった。 気候変動・AI・パンデミック：現代のSuper Wicked Problems Wicked Problems概念は現代においてさらに拡張されている。政治学者のRichard Levin らは2012年に「Super Wicked Problems」という概念を提唱し、気候変動のような問題の特徴を記述した。 Super Wicked Problemsの特性には「時間が迫っている」「解決策を求める者が問題を引き起こしている」「中央権威が弱い」が加わる。AI統治・パンデミック対応・グローバルサプライチェーンのリスク管理など、21世紀の中心的問題群はこのカテゴリに属する。 リッテルが1973年に描いた「問題の定義が問題である」という認識は、デジタル化・グローバル化・気候変動が重なる現代において、より一層の切迫性を持って蘇っている。 --- リッテルが遺したもの ホースト・リッテルは大規模な組織を持ったわけではなく、ベストセラーを書いたわけでもない。14ページの論文だ。それが50年以上にわたってデザイン・計画・社会科学の実践者に影響を与え続けている。 「問題とは何か」を問い直したリッテルの姿勢は、現代のデザイン思考がユーザーインタビューで「本当の問題を探す」こと、プロトタイプで「問題の定義を更新する」こと、ファシリテーターが「問いの設計から始める」ことの、深い理論的根拠だ。 デザイン思考を実践する者がリッテルを知ることは、自分たちが行っていることの意味を原典に立ち返って理解することだ。手法の背後にある問いを見失わないために、リッテルはまだ有効な道案内となる。 --- 関連記事・参考文献 - リチャード・ブキャナン——デザイン思考の哲学的基盤を構築した理論家 - デザイン思考の限界と可能性 主要文献 - Rittel, H. W. J. & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4(2), 155–169. - Buchanan, R. (1992). Wicked Problems in Design Thinking. Design Issues, 8(2), 5–21. - Conklin, J. (2006). Dialogue Mapping: Building Shared Understanding of Wicked Problems. Wiley. - Kolko, J. (2012). Wicked Problems: Problems Worth Solving. Austin Center for Design. --- ### イノベーション戦略家・著作家 URL: https://designthinking.studio/people/cynthia-barton-rabe/ > 『The Innovation Killer』（AMACOM, 2006）の著者。組織内部の専門知識が逆にイノベーションを阻害するメカニズムを解明し、外部の認識的距離を持つ思考者「Zero-Gravity Thinker（ゼログラビティ・シンカー）」の概念を提唱した。 シンシア・バートン・レイブ（Cynthia Barton Rabe）は、イノベーションを阻む最大の敵が「無知」ではなく「知りすぎること」にあると論じたイノベーション戦略家だ。Apple、Intelにてイノベーション担当の役職を歴任した実務経験を背景に、2006年に著書 The Innovation Killer: How What We Know Limits What We Can Imagine—and What Smart Companies Are Doing About It（AMACOM）を刊行した。 「イノベーション・キラー」の正体 書名が示す「イノベーションを殺すもの」とは何か。レイブの答えは一言で言えば、組織内部に蓄積された専門知識そのものだ。 多くの組織では、問題を解決するために最も知識豊富な専門家が集められる。これは一見合理的な判断だ。しかし専門知識が深まるほど、思考の可能性空間は縮小していく。「以前試したが失敗した」「業界の常識では不可能だ」「この市場では通用しない」——こうした判断の根拠はすべて、過去の経験と専門知識から来ている。専門家は無意識のうちに、解決策の探索範囲を「知っている世界の内側」に限定してしまう。 レイブはこの現象を、物理学の「質量のある物体は重力に縛られる」という比喩で説明した。長年の経験と知識を積んだ専門家の思考は、過去の成功体験という重力に強く縛られている。その重力から解放されない限り、まったく新しい軌道に踏み出すことはできない。 Zero-Gravity Thinker——認識的距離の力 本書の中心的な貢献は、Zero-Gravity Thinker（ゼログラビティ・シンカー）という概念の定式化だ。 Zero-Gravity Thinker とは、問題に対して「ちょうどよい無知」を持つ外部の思考者を指す。業界の常識を知らないがゆえに、業界の常識に縛られない。専門家が「それは無理だ」と判断する前に、「なぜ無理なのか」という問いを純粋に立てることができる。この認識的距離（epistemic distance）が、専門家集団では生まれない発想の回路を開く。 重要なのは、Zero-Gravity Thinker が「無知な人」ではないことだ。彼らは往々にして、問題領域とは別の分野における深い専門性を持つ。医療機器の問題に対して航空宇宙の専門家が入る、消費財のマーケティング課題に対して演劇演出家が関与する——こうした組み合わせによって、専門家が「当然の前提」として検討すらしない選択肢が可視化される。 レイブが提唱した実践的なフレームワークは、この Zero-Gravity Thinker を組織的にプロセスに組み込むことだ。社内の専門家チームに加え、異分野からの外部思考者を意図的に招き入れ、「なぜそれが不可能なのか」「その前提は本当に正しいか」という問いを構造的に生み出す仕組みをデザインする。 専門性のパラドックス レイブの議論が現代のイノベーション研究において持つ意義は、「専門性のパラドックス」を明確に言語化した点にある。 ある分野の専門家になればなるほど、その分野の問題を解く能力は上がる。しかし同時に、その分野の「あるべき姿」についての仮定も強化される。専門性は問題解決能力を高めながら、問題設定能力を弱める——この二重の効果が、成熟した組織がイノベーションを失いやすい理由だ。 経営学者のクレイトン・クリステンセンが「イノベーションのジレンマ」で論じた、優れた企業が持つ組織ルーティンと価値観ネットワークが破壊的イノベーションへの対応を妨げるという観察は、レイブの主張と同じ構造を個人レベルで論じたものとして読める。既存の問題解決能力の高さが、新しい問題への感受性を鈍らせる。 デザイン思考への接続 レイブのフレームワークは、デザイン思考における「誰を巻き込むか」という問いに具体的な解を提供する。 共感フェーズでユーザーに直接接触することの価値は、ユーザーが持つ認識的距離にある。内部の専門家が「こう使われるはずだ」と仮定していることを、ユーザーは当たり前のように違う形で使う。その「ずれ」が洞察の起点になる——これは Zero-Gravity Thinker が生む認識的距離と同じ機能だ。 アイデエーションフェーズにおける異分野混在チームの設計も、同じ論理で正当化される。専門家だけのチームは深く掘るが、隣の分野の組み合わせを見落とす。異なるバックグラウンドを持つメンバーが意図的に配置されることで、専門家集団が共有する「暗黙の前提」に問いが立てられる。 エリック・フォン・ヒッペルが「市場の最前線にいるユーザーがイノベーターになる」と論じたのと対称的に、レイブは「問題領域の外側にいる思考者がイノベーターになる」と論じた。前者は使用経験の深さ、後者は認識的距離の外部性——どちらも、問題に対する「適切な距離感」の設計という同じ問いに対する異なる答えだ。 --- 参考文献 - Cynthia Barton Rabe, The Innovation Killer: How What We Know Limits What We Can Imagine—and What Smart Companies Are Doing About It, AMACOM, 2006 関連記事: デザイン思考の共感フェーズ / アイデエーションフェーズ / エリック・フォン・ヒッペル / 発散思考と収束思考 --- ### インダストリアルデザイナー・IDEO共同創設者 URL: https://designthinking.studio/people/bill-moggridge/ > インタラクションデザインという概念を命名し、IDEOの共同創設者として人間中心デザインを産業界に広めたデザイナー。GRiD Compassラップトップの設計者。 ビル・モグリッジ（Bill Moggridge、1943–2012）は、「インタラクションデザイン（Interaction Design）」という言葉を生み出したデザイナーです。デジタル製品の設計に「人間との相互作用」という視点を持ち込み、ソフトウェアとハードウェアを統合して設計するという考え方の先駆者として知られています。 GRiD Compassと最初のラップトップ設計 1982年、モグリッジはGRiD Systemsのためにコンピューター「GRiD Compass」を設計しました。折り畳み式スクリーンを持つこの製品は、世界で初めて「ラップトップ」の形態を確立したコンピューターとして記録されています。 NASAのスペースシャトル計画やアメリカ軍に採用されたGRiD Compassは、技術的先進性だけでなく、携帯性と操作性を設計の中心に置いたという点でも先駆的でした。「コンピューターを持ち運んで使う」という行動パターンそのものを、モグリッジのデザインが可能にしました。 「インタラクションデザイン」の命名 1980年代後半、モグリッジは自身のデザイン実践を表現する言葉を探していました。当時、ソフトウェアインターフェースの設計は「グラフィックデザイン」でも「エンジニアリング」でもない、曖昧な領域にありました。 モグリッジはビル・ベルプラッシュ（Bill Verplank）とともに、この領域を「インタラクションデザイン（Interaction Design）」と命名しました。人間がデジタル製品とどのように「インタラクション（相互作用）」するかを設計する専門分野という定義は、その後の業界標準となります。 この命名は単なる言葉の問題ではありませんでした。「デジタル製品の設計において、ユーザーの行動・思考・感情を中心に置く」という設計哲学を、職能として確立した行為でした。 IDEOの共同創設 1991年、モグリッジはデイヴィッド・ケリーとマイク・ナットールとともにIDEOを共同創設しました。 IDEOは産業デザインと人間中心設計を統合したコンサルティングファームとして急速に成長し、「デザイン思考」を企業のイノベーション手法として広める中心的な役割を果たしました。モグリッジはIDEOのロンドンオフィスを率い、ヨーロッパでのデザイン思考の普及に貢献しました。 Cooper Hewitt館長とデザイン教育 2010年、モグリッジはスミソニアン協会が運営するCooper Hewitt, Smithsonian Design Museumの館長に就任しました。デザイン思考の実践者として著名な人物がデザインミュージアムを率いるという人事は、デザイン教育とパブリックなデザイン文化の形成への貢献として評価されました。 2012年、モグリッジはウルフ賞受賞の数ヶ月後、癌のために69歳で亡くなりました。 著書 Designing Interactions（2007）は、デジタル製品設計の歴史を40名以上のデザイナー・エンジニアへのインタビューで綴った集大成的な記録であり、インタラクションデザインの標準的な参考文献のひとつです。 --- 参考文献 - Bill Moggridge, Designing Interactions, MIT Press, 2007 - Paola Antonelli, "Bill Moggridge, 1943-2012", MoMA Design Blog, 2012 - Cooper Hewitt Museum, "Bill Moggridge: A Tribute", cooperhewitt.org, 2012 --- ### インダストリアルデザイナー・IDEO共同創設者・インタラクションデザイン命名者 URL: https://designthinking.studio/people/bill-moggridge-expanded/ > 「インタラクションデザイン」という言葉を生み出し、IDEO共同創設者としてデザイン思考の産業界への普及を牽引した。GRiD Compassラップトップ設計、著書『Designing Interactions』を通じて現代デザイン実践の基盤を作った。 ビル・モグリッジ（Bill Moggridge、1943–2012）を一言で表すなら、「デジタルの世界に人間の視点を持ち込んだデザイナー」です。1970年代後半から2000年代にかけて、コンピューターは爆発的に普及しました。しかし「人間がどう使うか」を先に問う設計は、当たり前ではありませんでした。 モグリッジのキャリアは、その当たり前でなかったことを当たり前にしていく過程です。 原点：ロンドンから世界へ 1943年、イギリス・ロンドン生まれ。Central School of Art and Design（現Central Saint Martins）でデザインを学んだモグリッジは、1969年にロンドンで自身のデザイン事務所を設立します。 1977年、事務所をサンフランシスコに移転。シリコンバレーが産業の中心として台頭し始めた時代に、モグリッジはインダストリアルデザイナーとしてテクノロジー企業と協働を深めていきます。この地理的な移動が、彼とデジタル技術の出会いを加速しました。 GRiD Compass（1982年）：最初のラップトップ モグリッジの名を歴史に刻んだ最初の仕事は、GRiD Systems社のために設計したコンピューター「GRiD Compass 1101」です。 1982年に発売されたGRiD Compassは、折り畳み式のスクリーンを持つクラムシェル型デザインを採用した最初のコンピューターとして記録されています。重量約4.5kg、価格約8,150ドルという制約の中で、モグリッジが解いた問題は「コンピューターを持ち運べる道具にする」ことでした。 GRiD Compassは一般市場ではなく、NASAのスペースシャトル計画（宇宙での使用を想定した耐久性と操作性）、アメリカ軍（フィールドでの使用を前提とした携帯性）といった特殊用途に採用されました。しかし「折り畳み式スクリーン＋キーボードのクラムシェル形態」という設計は、その後すべてのノートパソコンが踏襲する基本形となりました。 「コンピューターを持って歩く」という行動パターンそのものを、モグリッジのデザインが可能にしたという意味で、GRiD Compassはインダストリアルデザインが技術の形を決めた記念碑的な作品です。 インタラクションデザインの命名（1984年頃） 1980年代前半、モグリッジはデザイン実践の中で「ソフトウェアとユーザーの間に何が起きるか」という問いに向き合い始めていました。当時、この領域には適切な言葉がありませんでした。「ソフトウェアデザイン」でも「グラフィックデザイン」でもない、インタフェースと人間の行動の交差点を扱う専門分野です。 モグリッジはビル・ベルプラッシュ（Bill Verplank）とともに、この領域を「インタラクションデザイン（Interaction Design）」と命名しました。 この命名は単なる言葉の整理ではありません。「デジタル製品を設計するとき、見た目の前に『どう使われるか』を設計しなければならない」という設計哲学の宣言でした。インタラクションデザインという名前が与えられたことで、この専門性が職能として確立され、後にHCI（Human-Computer Interaction）研究や現代のUXデザインへとつながっていきます。 IDEO共同創設（1991年） 1991年、モグリッジはデイヴィッド・ケリーのデザイン事務所David Kelley Design、マイク・ナットールのMatrix Product Designと統合し、IDEOを共同創設しました。 IDEOは産業デザインと人間中心設計を統合したコンサルティングファームとして、急速に影響力を持ちます。モグリッジはIDEOのロンドンオフィスを率い、ヨーロッパでのデザイン思考の普及に貢献しました。 IDEOのデザインプロセスの中に、モグリッジが持ち込んだ「インタラクション」の視点は不可分です。製品の形だけでなく、「製品を使う体験の流れ」「ユーザーとのインタラクションのシーケンス」を設計の対象とする姿勢が、IDEOの人間中心設計の核心に組み込まれています。 著書『Designing Interactions』（2007年） モグリッジが残した最大の知的遺産のひとつが、2007年にMIT Pressから出版された『Designing Interactions』です。 この本の特徴は、インタラクションデザインの歴史を40名以上のデザイナー・エンジニア・研究者へのインタビューで記録したことです。ダグラス・エンゲルバート（コンピューターマウスの発明者）、アラン・ケイ（パーソナルコンピューター概念の先駆者）、ビル・ベルプラッシュ、ポール・フィッツ（Fitts's Lawの提唱者）など、デジタルインタラクションの歴史を作った人物たちの肉声が収録されています。 この本が「デザイン思考の実践者への示唆」を持つのは、インタラクションデザインの発展が「技術の歴史」ではなく「人間の視点でデジタルを設計する試みの歴史」として記録されているからです。「ユーザーを観察し、ユーザーが自然に使えるものを設計する」という思想が、どのように先人たちによって形成されたかが、具体的な語りで分かります。 Cooper Hewitt館長（2010–2012年） 2010年、モグリッジはスミソニアン協会が運営するCooper Hewitt, Smithsonian Design Museumの館長に就任しました。 デザイナーがデザインミュージアムを率いるという人事は、パブリックなデザイン教育への強いコミットメントを示します。モグリッジは館長在任中、デザインを「専門家のもの」ではなく「社会全体で議論される文化」として位置づける姿勢を貫きました。 2012年9月8日、モグリッジは69歳でサンフランシスコのホスピスで癌のために亡くなりました。同年、Cooper-Hewitt国立デザイン賞生涯功績賞を受賞しています（2009年受賞、2012年が在任最終年）。 デザイン思考実践者へのモグリッジの遺産 モグリッジの仕事から、デザイン思考の実践者が受け取れる最も重要な示唆は3つあります。 - 言葉を作ることの力 「インタラクションデザイン」という言葉がなければ、この専門性が職能として確立することはなかったかもしれません。自分たちが取り組む問いに名前を与えることは、その問いを社会的に共有可能にする行為です。 - ハードウェアとソフトウェアを統合して設計する視点 GRiD Compassが示したのは、「ハードウェアの形」と「使い方（インタラクション）」は分けて設計できないということです。デザイン思考の実践においても、「体験」は複数の接点の統合として生まれます。 - 実践の記録が次世代を作る 『Designing Interactions』は、先人たちの語りを記録することで、インタラクションデザインの知的基盤を作りました。ワークショップの場での学びを記録し、次の実践者に渡すことの価値を、モグリッジは著作を通じて示しています。 --- 参考文献 - Bill Moggridge, Designing Interactions, MIT Press, 2007 - Paola Antonelli, "Bill Moggridge, 1943-2012", MoMA Design Blog, moma.org, 2012 - Cooper Hewitt, "Bill Moggridge: Director 2010-2012", cooperhewitt.org - IDEO, "Bill Moggridge: Founder", ideo.com - Smithsonian Institution, "Cooper-Hewitt Mourns the Loss of Director Bill Moggridge", si.edu, 2012 --- ### エクスペリエンスデザイナー・観察研究者 URL: https://designthinking.studio/people/jane-fulton-suri/ > IDEOでHuman Factors Leadを経てChief Creative Officerを務めたエクスペリエンスデザインの先駆者。著書『Thoughtless Acts?』（2005）で「無意識の行動」を観察の対象として体系化し、シャドーイングと民族誌的観察をデザイン思考の中核手法として確立した。 ジェーン・フルトン・スリ（Jane Fulton Suri）は、IDEOでHuman Factors LeadからChief Creative Officer、そしてPartner Emeritusへと至った、エクスペリエンスデザイン分野の先駆的実践者だ。彼女が残した最も重要な問いは、「デザイナーが見るべきものは、ユーザーが意識していない行動の中にある」という視点の転換だった。 経歴 英国出身。ロンドンのRoyal College of Art（RCA）を経てIDEOに加わり、Human Factors部門のリードとして人間中心設計の実践基盤を構築した。その後、Chief Creative Officerに就任し、IDEOのクリエイティブ全体を統括。現在はPartner Emeritusとして活動する。 IDEOが「Human-Centered Design」という方法論を世界的に広めるにあたり、フルトン・スリの貢献は単なる手法の開発にとどまらない。「人間を観察するとはどういうことか」という認識論的な問いを、デザインの実務に根付かせた人物として評価されている。 『Thoughtless Acts?』——無意識を観察する 2005年にChronicle Booksから出版された Thoughtless Acts?: Observations on Intuitive Design（邦題：『Thoughtless Acts?』）は、フルトン・スリの観察者としての眼差しが凝縮された著作だ。 「Thoughtless Acts（思慮なき行動）」とは、人が意識せずに行う小さな行動のことを指す。椅子の背もたれにバッグをかける。歩きながら壁に手を触れる。混雑した電車で体の向きを微妙に変える。こうした何気ない身体的な反応や即興的な問題解決は、ユーザーが「自分のニーズ」として言語化できない層にある。 本書はフルトン・スリ自身が撮影・収集した写真を軸に構成されており、観察の対象そのものを「見せる」形式をとっている。テキストよりも画像が語る構成は、「デザインの観察は言語化の前段階にある」という彼女の主張を体裁そのもので実践するものだ。 この著作が示したのは、ユーザーインタビューだけでは届かない潜在的ニーズの層が存在し、そこへのアクセスには「言葉を聞く」ではなく「行動を見る」という別の認識ルートが必要だという事実だった。インタビューで「どんな問題がありますか?」と聞いても出てこない答えが、日常の観察から浮かび上がる——この逆説がフルトン・スリの核心的な問題提起だ。 シャドーイング——観察対象を「尾行する」手法 フルトン・スリがIDEOにおいて普及に貢献した観察手法のひとつが、シャドーイング（Shadowing）だ。 シャドーイングとは、デザイナーやリサーチャーが観察対象者の後を文字通りついて歩き、その日常の行動・移動・判断・感情のパターンを長時間にわたって記録する民族誌的（エスノグラフィック）な調査手法だ。病院の患者が診察室から会計窓口まで移動する経路を追う。スーパーマーケットで顧客が棚と棚のあいだをどう歩くかを観察する。 シャドーイングが他の観察手法と異なるのは、文脈の連続性を保つ点にある。ユーザビリティテストのように「タスクを与えて測定する」のではなく、自然な状況のなかで行動がどのように流れるかを、その流れのまま記録する。これにより、環境・時間・感情・他者との相互作用が行動に与える影響が可視化される。 このアプローチは、人類学・社会学における参与観察の方法論をデザインの実務に移植したものだ。フルトン・スリはIDEOの文脈でこれを洗練させ、観察の記録・分析・共有という一連のプロセスをデザインチームが扱えるかたちに整えた。 Human-Centered Designへの貢献 IDEOがHuman-Centered Design（人間中心設計）を単なるスローガンでなく実践として確立するうえで、フルトン・スリの果たした役割は構造的だった。 共感フェーズの実践基盤を作ったという点が最も大きい。デザイン思考の「共感」は、ユーザーの立場を想像することではなく、ユーザーが実際に何をしているかを観察・記録・解釈することだ。この「観察の実践」をIDEOの組織的なケイパビリティとして位置づけ、チームが現場に出て観察する文化の一端を担った。 また、「人間の行動には設計が宿る」という逆説的な観点を提示したことも重要だ。Thoughtless Actsが示すように、人がある環境でとる無意識の行動は、その環境の設計に対する身体的な応答だ。椅子の背に荷物をかけるのは、「荷物を置く場所がない」という設計の欠如に対するユーザー自身の即興的な解決だ。ユーザーの行動を観察することは、現在の設計の何が機能していて何が機能していないかを読み解く行為でもある。 観察の倫理と「見ること」の技術 フルトン・スリが繰り返し強調するのは、観察は「客観的なデータ収集」ではなく、見る者の解釈が不可避に入り込む行為だということだ。 何を観察の対象とするか、どの行動を「意味がある」と判断するか、記録した映像や写真からどの場面を選ぶか——こうした選択のすべてに、観察者の仮説・価値観・経験が反映される。フルトン・スリはこの「観察者の主観性」を排除しようとするのではなく、意識的なデザインリサーチャーとしての自覚と責任として引き受けるよう求める。 この立場は、「データさえ集めれば答えが出る」という量的アプローチへの静かな異議であり、デザイン思考における「共感」が判断を伴う行為であることを明示している。 デザイン思考実践者への示唆 フルトン・スリの仕事が今日のデザイン実践者に問いかけることは明確だ。 インタビューとフィールド観察は補完的であり、どちらかで十分ということはない。 ユーザーが語ることと実際にすることのあいだにはつねにギャップがある。そのギャップを埋めるのが観察の役割だ。シャドーイングのような手法は、そのギャップを「言葉で埋める」のではなく「行動の文脈ごと記録する」ことで対処する。 「無意識の行動」こそが潜在ニーズへの最短経路である。 ユーザーが「こういう問題があります」と言語化できない部分——それが最も解決の余地があり、かつ最も見逃されやすい設計上の課題だ。Thoughtless Acts? が提示した観察のフレームは、共感フェーズにおいてどこに目を向けるかの指針として機能する。 観察は技術である。 訓練なく観察に出ても、見ているようで見ていないことは多い。何を記録し、何を捨てるか。どの行動がどの設計問題に対応しているか。フルトン・スリの仕事は、「見ること」が習得可能な実践的技術であることを示した。 --- 参考文献 - Jane Fulton Suri, Thoughtless Acts?: Observations on Intuitive Design, Chronicle Books, 2005 - Jane Fulton Suri & IDEO, "Empathy on the Edge: Scaling and Sustaining a Human-Centered Approach in the Evolving Practice of Design", IDEO, 2015 - IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015 関連記事: デザイン思考の共感フェーズ / シャドーイング / エスノグラフィーリサーチ / Tim Brown — IDEOのCEO --- ### コンピューター科学者・インタラクションデザイン研究者 URL: https://designthinking.studio/people/pattie-maes/ > MITメディアラボ Fluid Interfaces Group を創設・主宰するコンピューター科学者。自律的ソフトウェアエージェントと適応型インターフェースの研究を起点に、身体・空間・デジタルの境界を溶かすインタラクション設計の新領域を切り開いてきた。デザイン思考が扱う「人間とテクノロジーの共創」の最前線を実証的に拡張している。 パティ・メイズ（Pattie Maes）は、MITメディアラボにおいてソフトウェアエージェントとヒューマン・コンピューター・インタラクションの研究を数十年にわたって展開してきた研究者だ。現在は Fluid Interfaces Group のディレクターを務め、人間の認知・身体・感情とデジタルシステムが流動的に統合される未来のインターフェースを設計・実証する研究組織を率いている。 経歴 ベルギー出身。ブリュッセル自由大学（Vrije Universiteit Brussel）で人工知能の博士号を取得後、MITメディアラボに加わった。1990年代初頭、自律的に学習・行動するソフトウェアエージェントの研究グループをMITに立ち上げ、当時まだ「エージェント」という概念が普及していない時代にその土台を築いた。 その後、インターフェースの研究軸を「エージェントによる自動化」から「人間の知覚・身体・行動を拡張するシステム設計」へと移行し、Fluid Interfaces Group を創設した。このグループは現在も活動中であり、メイズはディレクターとして在籍している。 ALIVE プロジェクトと自律エージェント研究 1990年代、メイズが率いた研究グループの代表的な成果のひとつが ALIVE（Artificial Life Interactive Video Environment）プロジェクトだ。ユーザーがカメラの前に立つと、仮想空間内の自律エージェント（犬型キャラクターなど）がユーザーの動きを認識してリアルタイムに反応するシステムで、没入型でインタラクティブな仮想環境の初期実装として注目を集めた。 ALIVEが示したのは、インタラクションが「コマンドと応答」という一方向の連鎖ではなく、人間とシステムの継続的な相互適応として設計できるという可能性だ。これはデザイン思考の共感フェーズで問われる「ユーザーはどのようにシステムと関わるか」という問いに、実装レベルで答えようとした試みでもあった。 ソフトウェアエージェント研究の時代、メイズは「人間がどのような作業を自動化したいか」よりも「エージェントはどのように人間の意図を読み取り、信頼関係を築くか」を中心課題に置いた。この視点——テクノロジーを「道具」ではなく「社会的存在」として設計する——は、後の Fluid Interfaces Group の研究思想につながっている。 Fluid Interfaces Group の研究思想 Fluid Interfaces Group は、コンピューターインターフェースを「画面の中の情報操作」という枠から解放し、日常の身体的・空間的・感情的な文脈に溶け込んだ情報体験を設計することを目指すグループだ。 「Fluid（流動的）」という名称は、デスクトップや画面という固定した窓口を経由せずに、情報とのやりとりが身体の動き・視線・発話・空間移動と連続するという設計思想を表している。 グループが継続的に探求しているテーマは複数ある。 拡張現実と身体インターフェースでは、物理世界への情報の重ね描きと、ジェスチャーや手の動きを入力とするシステムが研究されてきた。かつて話題を呼んだ「SixthSense」プロジェクト（グループ在籍の Pranav Mistry による研究）は、プロジェクターとカメラを身につけることで壁・手のひら・現実の物体をインターフェース化するものだった。 認知拡張と集中力支援では、人間の注意・記憶・学習を補助するウェアラブルや音響フィードバック技術が開発されている。メイズが関わる研究の多くは「テクノロジーが人間の認知をどう補うか」という問いを軸に置いており、「障がいとしての認知差」を「多様な認知スタイル」として再定義する設計アプローチと親和性を持つ。 感情とウェルビーイングの領域では、ストレス・睡眠・感情状態をセンシングし、行動変容を促すシステムの研究が行われている。これはデザイン思考における「潜在ニーズの発見」という問題意識を、センシング技術によって客観的に可視化しようとする試みだ。 インタラクションデザインへの影響 メイズの研究軌跡は、デザイン思考がテクノロジーと接続する際の重要な問いを提示してきた。 「インタラクションは双方向の学習プロセスである」という前提。 ALIVEから Fluid Interfaces まで一貫しているのは、システムがユーザーを一方的に操作する対象として扱わず、ユーザーとシステムが互いに適応しながら関係を築くという設計思想だ。これは共感フェーズで「ユーザーを観察し、学ぶ」という実践と根本的に重なっている。 「制約としての身体」から「資源としての身体」への転換。 従来のGUIは「身体の不器用さ」を補うために設計されていた。メイズのグループは逆に、身体の動き・触覚・視線・呼吸という生物学的なシグナルをインタラクションの豊かな入力源として扱う。これはユーザー観察において「人が実際に体を使って何をするか」を記録する手法——エスノグラフィーリサーチの精神——と共鳴する。 実装による思考（Thinking through Making）。 Fluid Interfaces Group は概念の記述ではなく、動く実装を通じて問いを育てる研究スタイルをとる。これはプロトタイピングを「アイデアの検証装置」として活用するデザイン思考の方法論と同じ認識論的な立場だ。 教育と起業 MITメディアラボでの研究と並行して、メイズはいくつかのスタートアップの設立にも関与してきた。Firefly Networks（1990年代のレコメンデーションエンジン企業、後に Microsoft に買収）の共同創設など、研究の社会実装に継続的に関わっている。 教育者としては、多数の博士研究者を指導しながら、インタラクション設計・AI・ウェアラブルにまたがる学際的な研究コミュニティを育ててきた。メイズのもとを巣立った研究者たちが産業界・学術界の各所でインタラクションデザインの実践を広げているという意味で、間接的な影響の拡がりは研究成果の引用数をはるかに超える。 デザイン思考実践者への示唆 パティ・メイズの研究を知ることで、デザイン思考の「共感」と「プロトタイプ」という2つのフェーズについての理解が深まる。 共感フェーズの深化。 ユーザーが何を「言うか」「考えるか」だけでなく、どのように身体・空間・感情が情報と絡み合っているかを観察する——この視座を持つことで、インタビューだけでは見えない潜在ニーズの層が開く。 プロトタイプの認識論的位置づけ。 「プロトタイプはアイデアを絵にしたもの」という理解に留まらず、「動く実装を通じてはじめて見えてくる問いがある」という認識は、プロトタイピングへの投資意欲と精度を根本的に変える。 メイズが数十年かけて実証してきたのは、人間とテクノロジーの関係は設計によって変わるという事実だ。その設計の出発点は常に、人間の認知・行動・感情への深い観察にある。デザイン思考が目指す「人間中心の設計」の最前線を、実装の側から示し続けてきた研究者だ。 --- 参考文献 - Pattie Maes, "Agents that Reduce Work and Information Overload", Communications of the ACM, 37(7), 1994, pp.31–40 - MIT Media Lab, Fluid Interfaces Group: https://fluid.media.mit.edu - Pattie Maes et al., "ALIVE: Artificial Life Interactive Video Environment", SIGGRAPH, 1994 - Pranav Mistry & Pattie Maes, "SixthSense: A Wearable Gestural Interface", UIST 2009 Adjunct Proceedings, ACM, 2009 関連記事: デザイン思考の共感フェーズ / プロトタイピング / ヒューマン・センタード・デザイン / Don Norman — 認知科学者・UX研究者 --- ### システム思考家・環境科学者 URL: https://designthinking.studio/people/donella-meadows-systems-thinking/ > 「システム思考の母」と呼ばれる環境科学者・思想家。1972年の『成長の限界』共著でシステム思考を世界に示し、遺著『Thinking in Systems』（2008）はデザイン思考・組織変革における最重要参考書の一つとなっている。 ドネラ・H・メドウズ（Donella H. Meadows、1941–2001）は、複雑な問題を「構造」で捉えるシステム思考の体系を実践的に確立した思想家です。「なぜ良かれと思った介入が逆効果を生むのか」——この問いへの答えを、彼女はシステムの内部構造に求めました。 共感だけでは足りない。「構造を見抜く目」がなければ、根本的な課題解決には届かない。メドウズの思想は、問題定義フェーズ（Defineフェーズ）と解決策の持続可能性を問い直すための、もっとも重要な理論的基盤の一つです。 経歴——MITからダートマスへ 1941年、イリノイ州シャンペーン生まれ。カールトン大学で化学を専攻後、マサチューセッツ工科大学（MIT）で生物物理学の博士号を取得。その後、MIT の Jay Forrester のグループに参加し、システムダイナミクス（System Dynamics）の研究に携わりました。 1972年、メドウズは Dennis Meadows、Jorgen Randers らとともに『成長の限界』（The Limits to Growth）を発表。世界規模でのシミュレーションモデル「WORLD3」を用いて、人口・資源消費・汚染が指数関数的に増加し続けた場合の帰結を分析したこの報告書は、世界30カ国語以上に翻訳され、当時の環境政策・国際会議に大きな影響を与えました。 1990年代、ダートマス大学の環境研究学部に移り、教育・執筆・農場経営を並行しながら、「持続可能なコミュニティ」の実践を行いました。2001年、細菌性髄膜炎により59歳で急逝。遺された草稿を同僚の Diana Wright が編集し、2008年に『Thinking in Systems: A Primer』として出版されました。 『Thinking in Systems』——システム思考の実践書 メドウズが長年構築してきたシステム思考の集大成が『Thinking in Systems』（2008、邦題：『世界はシステムで動く』）です。この書籍は、「複雑な現象の背後にある構造を見抜き、効果的な介入点（レバレッジポイント）を特定する」ための実践的思考法を提供します。 システムの3要素 メドウズはシステムを次の3要素で定義しました。 ストック（Stock）は、システム内に蓄積される量です。川の水量、組織の人員数、個人の知識量がこれに当たります。ストックは簡単に変化しない「慣性」を持ちます。 フロー（Flow）は、ストックを増減させる速度です。採用・離職・学習・忘却など、変化の動的プロセスを表します。ストックとフローの関係が、システムの「振る舞い」を決定します。 フィードバックループは、ストックの変化がフローに影響を与える「循環」です。強化ループ（Reinforcing Loop）は変化を増幅し、バランスループ（Balancing Loop）は変化を抑制します。多くの組織問題・社会問題は、このフィードバック構造の誤解から生じています。 レバレッジポイント12段階——介入の優先順位 メドウズの最も重要な貢献の一つが、「システムを変えるための介入点（レバレッジポイント）を12段階に整理した論文」（1999）です。デザイン思考の「Define → Ideate」フェーズで解決策を構想する際、この枠組みは介入の深さと効果を評価する基準として機能します。 12段階は「最も効果が低い」から「最も効果が高い」順に並びます。上位ほど根本的ですが、変えることへの抵抗も大きくなります。 12位：定数・パラメータの変更（例：税率、補助金額）。最も変えやすいが、システム構造を変えないため効果は限定的。 11位：バッファのサイズ変更（例：在庫量の調整）。安定性には寄与するが、しばしばコストが高く変更困難。 10位：ストックとフローの構造変化（例：物理インフラの設計変更）。大きな変化だが、構築済みシステムの変更は困難。 9位：遅延の長さ変更（例：意思決定速度）。フィードバックの遅延はシステム不安定化の主因。 8位：バランスループの強さ変更（例：規制の強化）。多くの政策介入はここに集中するが、抵抗も生まれやすい。 7位：強化ループの増幅率変更（例：複利・ネットワーク効果）。成長・崩壊の速度を変える。 6位：情報フローの構造変化（例：フィードバック先の変更）。「誰が何を知るか」の変更は、行動を根本から変える。 5位：ルールの変更（例：インセンティブ・罰則・制約）。システムが動く「文法」の変更。 4位：自己組織化能力の追加・変更。システムが自らを変える能力。これが存在するシステムは飛躍的に適応可能になる。 3位：ゴールの変更。バランスループが目指す状態を変えること。「何を目標とするか」の変化は、手段のすべてを変える。 2位：マインドセット・パラダイムの変更。システムが生まれた前提を変えること。最も強力で、最も変えにくい。 1位：パラダイムを「超える」こと。特定のパラダイムに執着しない姿勢そのもの。「どのパラダイムも地図であり、現実ではない」という認識。 デザイン思考との接続 デザイン思考のフレームワークは、共感・問題定義・発想・プロトタイプ・テストという5フェーズで構成されます。しかしこのプロセスが「表面的な症状」にとどまる解決策を生み出す危険性がある場合、メドウズの問いが有効です。 「あなたが解決しようとしているのは、症状（フロー）なのか、構造（フィードバックループ）なのか、それともパラダイムなのか」。 たとえば、ユーザーが「検索に時間がかかる」と述べるとき、それは「UIの改善」を求めているのか、「情報構造の再設計」を求めているのか、「そもそも検索という行為自体を不要にする」ことを求めているのか——介入レベルを見誤れば、優れた解決策も効果を失います。 問題定義フェーズにおいて、問題の「深さ」を特定するための基準として、レバレッジポイントの12段階は実践的な指針になります。 「アーキタイプ」——繰り返し現れる構造パターン メドウズはシステム思考の中で、現実の問題に繰り返し現れる「システムのアーキタイプ（System Archetypes）」という概念も整理しています。 代表的なものが「成長と投資不足（Growth and Underinvestment）」です。成長が投資の不足を引き起こし、それがさらに成長を妨げるという構造です。多くの組織で見られる「拡大期に設備・人員投資が遅れ、品質低下でシェアを失う」という現象がこれに該当します。 もう一つが「共有地の悲劇（Tragedy of the Commons）」。共有リソースを複数の利用者が競合して使うとき、個人最適が全体最悪を生む構造です。この構造を知ることで、「誰かを悪者にする」のではなく「構造を変える」介入が見えてきます。 晩年の思想と「持続可能性」への視座 ダートマス時代のメドウズは、著名な研究者であり農場主でもありました。地域支援型農業（CSA）の実践家として、抽象的なシステム理論を地域の食と農に接続しようとしました。 彼女が一貫して問い続けたのは「私たちはどのようなシステムをデザインするのか、そして誰のためにデザインするのか」という倫理的問いです。システム思考は価値中立ではなく、何を最適化するかの選択を常に伴う、という主張は、人間中心設計の倫理的基盤とも共鳴します。 実務者への示唆 メドウズから得られる最大の示唆は、「問題を正しいレベルで捉えること」です。 多くのデザインプロジェクトは「表層の問題（パラメータレベル）」を改善して終わる。なぜその問題が繰り返し発生するのかを問えば、「フィードバック構造」や「インセンティブ設計」というより深い介入点が見えてきます。 共感フェーズでの観察データを、「症状」ではなく「構造」として解釈する視点——それがシステム思考の、デザイン思考への最も実践的な贈り物です。 --- 主要著作 - Donella H. Meadows et al., The Limits to Growth, Universe Books, 1972（邦題：『成長の限界』） - Donella H. Meadows, Thinking in Systems: A Primer, Chelsea Green Publishing, 2008（邦題：『世界はシステムで動く』枝廣淳子訳） - Donella H. Meadows, "Leverage Points: Places to Intervene in a System", Sustainability Institute, 1999 --- ### スタンフォード大学プロダクトデザインプログラム教授 URL: https://designthinking.studio/people/rolf-faste/ > デザイン思考をエンジニアリング教育に統合した先駆者。スタンフォード大学プロダクトデザインプログラムを牽引し、d.schoolの礎を築いた。1943〜2003年。 ロルフ・ファステ（Rolf Faste, 1943〜2003）は、スタンフォード大学機械工学科のプロダクトデザインプログラムに20年以上在籍し、デザインの思考法をエンジニアリング教育の核心に位置づけた教育者である。デイヴィッド・ケリーやラリー・ライファーとともに、後にd.schoolへと発展する知的土台を形成した。2003年に逝去したため、d.schoolの正式な開設（2005年）を見ることはなかったが、その教育哲学と実践はd.schoolの設計思想に深く織り込まれている。 経歴 ファステはカリフォルニア州オークランドに生まれ、カリフォルニア大学バークレー校で建築を学んだ後、スタンフォード大学で工業デザインの修士号を取得した。スタンフォード大学での教歴は1980年代から始まり、2003年の逝去まで続く。在職中、機械工学科のプロダクトデザインプログラムにおいて、数百名の学生にデザイン思考と創造的プロセスを教えた。 ファステの教育スタイルは実践主義の徹底だった。理論の講義より、手を動かす課題。学生が「正解を探す」のをやめ「可能性を発見する」態度に切り替わる瞬間を、教室で繰り返し引き出した。 ラリー・ライファーとの関係 ファステにとって最も重要な同僚が、スタンフォード大学機械工学科の教授ラリー・ライファー（Larry Leifer）だ。ライファーはエンジニアリング設計とデザイン思考研究の第一人者であり、スタンフォード・デザイン・リサーチ・センター（CDR）を設立した人物でもある。 ファステとライファーは、工学部生に「使う人間のことを考えるデザイナーの姿勢」を植え付けるカリキュラムを共同開発した。彼らが目指したのは、純粋な技術者でも純粋な美術系デザイナーでもない「第三の人材」——技術的な実現可能性とユーザーの経験を同時に思考できる人材の育成だった。 この教育実験は、後にIDEOの共同創業者デイヴィッド・ケリーが合流することで加速した。ケリーはスタンフォードのプロダクトデザインプログラムで教え、ファステとライファーとともに「T字型人材（T-Shaped Person）」の概念——専門的な深みと学際的な幅を兼ね備えた人材像——を実践的なカリキュラムとして具体化した。 「エンパシー（Empathy）」のデザイン教育への導入 ファステの最も重要な知的貢献のひとつが、「共感（Empathy）」をエンジニアリングデザインの中心概念として位置づけたことだ。 1983年のスタンフォードでの講義ノートには、すでに「エンパシーは単なる感情的な共鳴ではなく、他者の経験を構造的に理解しようとする意図的な認知行為だ」という記述がある。これは、後にd.schoolが5つのフェーズの最初に「Empathize（共感）」を置く設計に直結する考え方だ。 当時のエンジニアリング教育では、ユーザーの経験は所与の条件として扱われることが多かった。「要件定義書に書いてあること」が設計の出発点であり、ユーザーそのものを観察・理解するプロセスは軽視されがちだった。ファステはこの慣習に疑問を投げかけ、「設計者がユーザーの生きた経験に直接アクセスすること」の重要性をカリキュラムに組み込んだ。 IDEO との接続 ファステが教えたスタンフォードのプロダクトデザインプログラムは、IDEOの人材供給源として機能した。デイヴィッド・ケリーが1991年にIDEOを設立した際、その初期メンバーの多くがスタンフォードのプロダクトデザインプログラムの卒業生と教員だった。 ファステ自身はIDEOに直接参加したわけではないが、彼が教え込んだ設計者の姿勢——「人間の行動と経験を観察し、そこから問いを立て、仮説を作り、形にして試す」——はIDEOの実践スタイルに深く浸透している。ワークショップでよく起こるのは、ファステに薫陶を受けた実践者が「まず外に出てユーザーを観察してこい」と若手に言う場面だ。この命令の背景には、ファステが作り上げた教育哲学がある。 d.school の「礎」としての評価 デイヴィッド・ケリーは2005年にd.schoolを開設した際、ファステへの敬意を繰り返し表明している。ケリーいわく「ロルフが作ったプロダクトデザインプログラムがなければ、d.schoolは存在しなかった」。 d.schoolの設計思想——異なる専門分野の学生が同じプロジェクトに取り組む学際的環境、プロトタイプを早く作ることの優先、ユーザーとの直接接触の必須化——は、ファステが20年かけて試行錯誤した教育実践の系譜上にある。ファステは制度を作った人物ではなく、制度が成立する前の文化を育てた人物だった。 「デザインの民主化」への信念 ファステは「創造性は特定の才能ある個人だけのものではない」という強い信念を持っていた。この信念はd.schoolのスローガン「誰もがデザイナーになれる（Everyone Can Be a Designer）」と直結している。 ファステのワークショップでは、建築学科、医学部、経済学部など、デザインを専攻していない学生を意図的に混ぜた。専門的なデザインスキルを持たない学生が、観察と仮説生成と試作を繰り返すうちに「自分にも問題解決の設計ができる」と気づく瞬間を、ファステは「創造的自信（Creative Confidence）」と呼んだ。 後にデイヴィッド・ケリーとトム・ケリーが著書 Creative Confidence の中で展開するこの概念は、ファステが教室で実践し続けたものの言語化とも言える。 遺産 ロルフ・ファステは2003年に59歳で逝去した。d.schoolの開設を2年後に控えた時期だった。しかし彼の影響は、d.schoolのカリキュラム設計、IDEOの組織文化、そして世界中に広がったデザイン思考教育の実践に、目に見えない形で生き続けている。 スタンフォード大学はファステの功績を称え、プロダクトデザインプログラムに彼の名を冠した。デザイン思考の歴史を書くとき、表舞台に立つのはIDEOやd.schoolの名前だが、その舞台を設計した職人のひとりがロルフ・ファステだった。 --- 参考文献 - Rolf Faste, "Ambidextrous Thinking", Innovations in Mechanical Engineering Curricula for the 1990s, ASME, 1994 - Rolf Faste, "The Human Challenge in Engineering Design", International Conference on Engineering Design, 2001 - David Kelley & Tom Kelley, Creative Confidence, Crown Business, 2013 - Barry Katz, Make It New: The History of Silicon Valley Design, MIT Press, 2015 - Stanford University Mechanical Engineering, "In Memoriam: Rolf Faste", stanford.edu, 2003 --- ### デザインの4領域論を構築した理論家——記号・モノ・行為・思想 URL: https://designthinking.studio/people/richard-buchanan-four-orders/ > 1992年の「Wicked Problems in Design Thinking」でデザインの概念的基盤を形成したブキャナンが、その後2001年前後に体系化した「Four Orders of Design（4領域論）」を解説。グラフィックからサービス・組織設計まで、デザインの射程を拡張した理論の実践的意味を問う。 「デザイン」という言葉を使うとき、人によってまったく異なるものを指している。 ポスターのレイアウトを指す人もいれば、サービスの流れを指す人もいる。経営戦略の構造を指す人もいれば、組織の働き方を指す人もいる。なぜ同じ「デザイン」という言葉が、これほど異なる対象をカバーできるのか。 この問いに対して、理論的な地図を描いたのがリチャード・ブキャナン（Richard Buchanan）だ。 ブキャナンは 1992年の論文「Wicked Problems in Design Thinking」でデザインを複雑問題への知的方法論として再定義した後、さらに思索を深め、デザインが扱う対象を4つの領域（Four Orders of Design）として体系化した。この枠組みは、「グラフィックデザインと組織デザインがなぜ同じ学問に属するのか」という問いへの、現在も有効な答えになっている。 --- 4領域論が生まれた文脈 ブキャナンが 4領域論を展開した背景には、1990年代〜2000年代初頭のデザイン教育と実践の大きな変容がある。 インターネットの普及によってインタラクションデザインが台頭し、企業経営においてサービスデザインが注目され始めた。デザインスクールは「ビジュアルコミュニケーション」や「工業デザイン」という従来の枠組みでは対応しきれない課題に直面していた。ブキャナンがカーネギーメロン大学（CMU）でデザインスクールの学部長を務めていたのは、まさにこの転換期だ。 CMU のデザインプログラムは、Stanford d.school や IDEO のような「実践の工房」とは異なる性質を持っていた。「なぜそうするのか」という問いを実践と並走させる場として機能し、ブキャナンはその中心で、デザインの概念的な射程を広げ続けた。 4領域論が体系的に言及されるのは 2001年前後とされており、1992年の Wicked Problems 論文（Design Issues, Vol.8, No.2, pp.5-21）の延長線上に位置する知的営みだ。 --- 4つの領域：記号・モノ・行為・思想 ブキャナンの 4領域論は、デザインが「何を扱うか」によってその実践を4つの階層に整理する。 第1領域（First Order）——記号とコミュニケーション 第1領域は、記号・視覚コミュニケーションを扱う領域だ。グラフィックデザイン・タイポグラフィ・写真・図解がここに位置する。 この領域のデザインは、意味を視覚的に伝えることを核とする。ポスターは「この映画を観るべきだ」と説得し、標識は「ここで止まるべきだ」と誘導する。ブキャナンは修辞学（Rhetoric）を基盤に持つ研究者として、デザインは本質的に「説得の技芸」であるという視点を持っていた。この視点では、第1領域のデザインは最も基礎的な説得のメディアということになる。 第2領域（Second Order）——モノと構造 第2領域は、物質的なモノ（産業製品・建築など）を扱う領域だ。工業デザイン・製品設計・建築の一部がここに含まれる。 記号（2次元）から立体・空間（3次元）への拡張だ。椅子は「ここに座ることが適切な姿勢だ」と体の使い方を誘導し、キッチンの配置は「ここで料理するとは、こういう動き方をするということだ」と行動パターンを規定する。機能と形の問題だけでなく、ユーザーの行動に働きかける構造の問題がここに現れる。 第3領域（Third Order）——行為とサービス 第3領域は、活動・インタラクション・サービスを扱う領域だ。UX設計・サービスデザイン・インタラクションデザインがここに位置する。 モノ（静的な物体）からプロセス（時間軸上の経験）への転換だ。Webサービスのユーザーフロー、医療機関での診察体験、教育プログラムの学習設計——これらは「モノを作る」のではなく、時間を通じてユーザーが経験する「行為の連鎖」を設計する。デザイン思考の5フェーズのうち「プロトタイプ」と「テスト」は、この第3領域の設計が想定の通り機能するかを検証するプロセスとして理解できる。 コンテキスチュアル・インクワイアリーやカスタマージャーニーマップは、第3領域の設計に必要な情報を収集するための手法として位置づけられる。ユーザーがどのような「行為の連鎖」を経験しているかを可視化しなければ、サービスの設計はできない。 第4領域（Fourth Order）——思想・システム・組織 第4領域は、組織・システム・文化・環境を扱う領域だ。組織デザイン・政策設計・都市計画・社会イノベーションがここに位置する。 個々のインタラクション（第3領域）から、複数の人・機関・構造が相互に関係するシステム全体（第4領域）への拡張だ。組織の意思決定プロセス、行政サービスの仕組み、学校教育の制度——これらはモノでもなく、単一のサービスフローでもなく、複数の行為者が絡み合うシステムとして存在する。 ブキャナンは、第4領域こそが現代の最も重要なデザインの場だと考えた。Horst Rittel と Melvin Webber が提唱した「Wicked Problems（邪悪な問題）」——社会的複雑性を持ち、単純な解法が存在しない問題——に対処するのは、まさにこの第4領域のデザインだ。 ホースト・リッテルが提唱した Wicked Problems の10の特性と、ブキャナンの第4領域論は、理論的に深く接続されている。定義できない・解法がない・解決策が新たな問題を生む——これらの特性を持つ問題に向き合うのが、第4領域のデザイン実践だ。 --- 4領域論の実践的意味——「自分はどの領域にいるか」を問う 4領域論は学術的な分類にとどまらず、デザイン実践者にとって具体的な問いを提供する。 「このプロジェクトは何領域の問題か」という問いを最初に立てることが、その問いの最も基本的な使い方だ。 ロゴのリデザインを依頼されたとき、それが純粋に第1領域（視覚コミュニケーションの改善）として解ける問題なのか、それともブランドのポジショニング（第4領域：組織の方向性）の問題が背後にあるのかを判断する必要がある。第1領域の解法（見た目を変える）を適用しても、第4領域の問題（組織が何者であるかが曖昧）は解決しない。 同様に、アプリの UI 改善を求められたとき、それが第2領域（インターフェースの構造）の問題なのか、第3領域（ユーザーがタスクを完了するフロー全体）の問題なのか、あるいは第4領域（そもそものサービスモデル）の問題なのかによって、適切なアプローチが変わる。 --- 「デザインは新しいリベラルアーツ」という主張 ブキャナンの 4領域論には、より大きな主張が含まれている。デザインは「新しいリベラルアーツ（教養）」であるという主張だ。 古典的なリベラルアーツ（文法・修辞学・論理学・算術・幾何学・音楽・天文学）は、知識を統合する知的な営みとして定義されていた。ブキャナンは、デザイン思考がこれと同じ役割を現代において担うべきだと考えた。記号（第1）・モノ（第2）・行為（第3）・思想（第4）という4領域を横断し、各領域の専門知識を統合して複雑な問題に向き合う能力——これがブキャナンの言う「新しいリベラルアーツとしてのデザイン」だ。 この視点は、デザイン思考が経営学部・医学部・政策大学院で教えられる理由の理論的な根拠にもなっている。デザイン思考は「デザイナーのスキル」ではなく、「複雑問題と向き合うための知的方法論」であるというポジショニングは、ブキャナンの思想なしには成立しなかった。 --- 4領域論の現在——批判と拡張 ブキャナンの 4領域論は広く参照される一方、批判的な検討も生まれている。 一部の研究者は「領域の境界が曖昧で、実践上の判断基準にならない」という課題を指摘する。第3領域と第4領域の境界——インタラクションデザインと組織デザインのどこで線を引くか——は理論的には説明できても、具体的なプロジェクトでは判断が難しい。 また、デジタル技術の進化によって第5の領域が必要ではないかという議論も起きている。AI・データ・ネットワーク効果が絡む現代のシステムは、ブキャナンが定義した第4領域よりもさらに複雑な構造を持つという指摘だ。 これらの議論は、4領域論が静的な「答え」ではなく、継続的な探究を促す「問いの枠組み」であることを示している。ブキャナン自身が Wicked Problems の概念を借用して言ったように、デザインが扱う問題は定義を固定させない。理論も同じく、固定されることを拒む。 --- 参照としてのブキャナン ブキャナンの理論は、実践現場で直接使うツールというより、自分の実践を批判的に照らす概念の鏡として機能する。 「自分が今やっていることは、何を変えようとしているのか。記号か、モノか、行為か、それとも思想か」——この問いを持って現場に立つと、プロジェクトの射程と限界が見えやすくなる。 Horst Rittel が「問題の複雑性」を地図として提供し、ブキャナンが「デザインの射程」を地図として提供した。この2枚の地図を持つことが、デザイン思考の実践者の基礎的な知的装備だ。 --- ### デザイン研究者・『101 Design Methods』著者 URL: https://designthinking.studio/people/vijay-kumar/ > デザインイノベーションのプロセスを体系化した実践書『101 Design Methods』の著者。IIT Institute of Designでのデザイン教育と企業のデザイン能力開発に長年携わり、「システマティックなデザインリサーチ」の確立に貢献した研究者。 概要 Vijay Kumarは、イリノイ工科大学のデザイン研究所（IIT Institute of Design）で長年教鞭を執るデザイン研究者だ。その名前は2012年にWiley社から刊行された実践書『101 Design Methods: A Structured Approach for Driving Innovation in Your Organization』とともに世界のデザイナーと経営者に知られている。 IIT Institute of Designは1937年にLászló Moholy-Nagyによって「New Bauhaus」として設立された、デザイン教育の歴史的拠点だ。Kumarはこの伝統の中で、リサーチとイノベーションを結ぶ実践的なフレームワークの開発に取り組んできた。 主要著作：101 Design Methods 書籍の概要 『101 Design Methods』（2012, Wiley）は、デザインリサーチとイノベーションプロセスを101のツールとして体系化した参照書だ。抽象的な方法論の羅列ではなく、「いつ何を使うか」を明確にするアクティビティスペース（Activity Space）フレームワークが特徴的だ。 7つのアクティビティスペース Kumarが提唱するフレームワークは、イノベーションプロセスを7つの活動空間に分類する。 - Sense Intent（意図を感知する） ── 業界・社会のトレンドを観察し、機会の方向性を探る - Know Context（文脈を理解する） ── 市場・競合・エコシステムを深く調査する - Know People（人を理解する） ── ユーザーの行動・ニーズ・動機をエンパシーリサーチで把握する - Frame Insights（洞察を構造化する） ── 観察データからパターンと原則を抽出する - Explore Concepts（コンセプトを探索する） ── インサイトを起点にアイデアを発散させる - Frame Solutions（解決策を設計する） ── コンセプトを実現可能な解決策に絞り込む - Realize Offerings（製品・サービスを実現する） ── 解決策を市場投入可能な形に具体化する このフレームワークはデザイン思考の5フェーズ（Empathize / Define / Ideate / Prototype / Test）と相補的な関係にある。Stanford d.schoolのプロセスがフェーズの流れを重視するのに対し、Kumarのフレームワークは各フェーズで「どの活動をどの目的で行うか」という粒度の構造化を提供する。 本書が支持される理由 『101 Design Methods』が研究者・実践者から支持されてきた理由は、抽象論に留まらない具体性にある。各手法はテンプレート・参考事例・適用タイミングとともに解説されており、チームがすぐに実践に転用できる形式で提供されている。 MBAプログラムや企業内デザインスクールでの採用も多く、「デザイン思考をどう組織に実装するか」という問いに応えるリファレンスとして機能してきた。 デザイン能力の組織開発への貢献 Kumarの研究の中心テーマのひとつは、個人ではなく組織のデザイン能力をどう育てるかという問いだ。デザイン思考の実践は個人のスキルとして語られることが多いが、Kumarは組織のプロセスと文化の中にデザインマインドセットを埋め込む方法論に力を注いできた。 IIT Institute of Designでの教育では、経営学・工学・ソーシャルサイエンスを横断する学際的アプローチを取り、デザイン思考を特定の職種のスキルではなく組織横断的なイノベーション能力として位置づけてきた。 IIT Institute of Designの系譜 Kumarが活動の拠点とするIIT Institute of Design（ID）は、世界のデザイン教育において独自の位置を占める。1937年設立のNew Bauhaus（後にSchool of Design、そしてInstitute of Designへと改称）は、バウハウスのデザイン哲学とアメリカのプラグマティズムを統合した教育機関だ。 IDはスタンフォードd.schoolやRCA（英国王立芸術大学院）と並んで、デザイン思考教育の国際的拠点として認知されている。Kumarはこの系譜の中で、デザインリサーチの体系化という独自の貢献を行ってきた。 関連する主要概念 Kumarの研究・著作が扱う中心概念： - デザインリサーチの体系化 ── 観察・インタビュー・文化的プローブなどの手法を目的別に整理する - フロントエンドイノベーション ── イノベーションプロセスの初期段階（何を作るかを決める前の探索フェーズ）の設計 - インサイトからコンセプトへの変換 ── 定性的な観察データを設計原則や事業機会に転換する思考プロセス - アクティビティスペースフレームワーク ── 上述の7段階によるイノベーション活動の構造化 デザイン思考研究者としての位置づけ Vijay Kumarは、デザイン思考の「教育者」と「実践の体系化者」として評価される。Tim Brown（IDEO）のような実践主導のデザイナーや、Roger Martin（ロトマンスクール）のような経営学者とは異なる立ち位置で、デザインリサーチとイノベーション手法の「辞書」を整備する役割を担ってきた。 「デザイン思考を実務でどう使うか」という問いに直面するチームにとって、Kumarが示したアクティビティスペースと101の手法群は、プロセスの地図として機能する。抽象的な原則を具体的な行動に落とす接続点として、その体系的な仕事は今も参照され続けている。 --- ### デザイン研究者・社会イノベーションデザイン論の第一人者 URL: https://designthinking.studio/people/ezio-manzini/ > サステナビリティとソーシャルイノベーションの文脈でデザインを再定義したイタリアの研究者。DESIS Network（2009年創設）を通じて、市民・コミュニティ・デザイナーが協働して社会課題を解決する「コラボレイティブ・サービス」の理論と実践を世界規模で広めた。著書『Design, When Everybody Designs』はソーシャルデザインの基礎文献。 エツィオ・マンジーニ（Ezio Manzini、1945年生まれ）は、デザインをプロダクトの美学的・機能的完成から解放し、社会変革のプラットフォームとして再定義したイタリアの研究者だ。ミラノ工科大学（Politecnico di Milano）で長年教鞭をとり、2014年に退官後は名誉教授の肩書のもと、世界規模のデザイン研究ネットワークの活動を続けている。 経歴と思想的軌跡 建築・デザイン教育を受けたマンジーニは、1980年代から材料・技術・デザインの関係を問い直す研究を始めた。1989年の著書 The Material of Invention（La materia dell'invenzione）では、素材そのものが持つデザインの可能性を論じ、産業素材の文化的・審美的な意味を再評価した。これはのちの「サステナビリティとデザイン」という問いへの思想的な準備だった。 1990年代に入り、マンジーニは関心を急速に「どうつくるか」から「何のためにつくるか」へと移行させる。環境負荷・資源消費・社会的公正という文脈でデザインを問い直す研究が本格化し、「持続可能な社会に向けてデザインはどう機能できるか」という問いがその後の全研究の軸になった。 ポリテクニコ・ディ・ミラノにデザイン学部が確立される過程で、マンジーニは教育・研究の中核を担った。同大学はプロダクトデザインからサービスデザイン・戦略デザインへと研究領域を拡張し、マンジーニはその方向性の形成に深く関与した。 DESIS Network の創設 2009年、マンジーニは DESIS Network（Design for Social Innovation and Sustainability）を創設した。これは「デザインを通じた社会イノベーション」を探求する大学・研究機関のグローバルネットワークであり、現在も世界各地の大学・デザインスクールを拠点として活動している。 DESISの前提にある問いは明快だ。「専門的なデザイナーだけが設計する時代は終わった。市民・コミュニティ・行政・企業が協働してサービスや社会システムを設計する時代に、専門家としてのデザイナーはどのような役割を担うべきか」。 マンジーニはこの問いに対して、デザイナーを「設計の実行者」から「社会的対話の促進者・プロセスの設計者」として再定義した。この転換は、デザイン思考における「ファシリテーターとしてのデザイナー」という役割認識と深く重なっている。 DESIS Network は現在、アジア・ヨーロッパ・北南米・アフリカの大学・デザインスクールを包括するグローバルなコミュニティとして機能している。 主著『Design, When Everybody Designs』 マンジーニの思想を最も体系的に示した著書が、2015年にMITプレスから刊行された Design, When Everybody Designs: An Introduction to Design for Social Innovation（原題 Quando tutti fanno design, 2013年イタリア語初版）だ。 タイトルの「誰もがデザインする（When Everybody Designs）」は、挑発的な宣言だ。ユーザーが受け取るだけの存在ではなく、市民・コミュニティが積極的にサービスや生活様式を設計する主体になりつつあるという現実認識を起点に、専門的デザイナーの役割の再定義が展開される。 マンジーニは本書の中で、現代社会に登場している「コラボレイティブ・サービス」の事例を豊富に分析している。カーシェアリング・コミュニティガーデン・時間銀行・DIYコミュニティなど、市民が自発的に組織するサービスは、従来の「市場が提供するサービス」でも「国家が提供する公共サービス」でもない第三の領域を形成している。 マンジーニはこれを「連結型個人（connected individuals）が組織する小規模で持続可能な地域サービス」と位置づけ、デザインが支援・拡張できる社会的実験の場として評価した。 本書が提示するデザイナーの2つの役割は実践的に重要だ。 ディフューズ・デザイナー（Diffuse Designer） は、デザイン専門の訓練を受けていないが日常の課題解決において創造的な行動をとる市民・ユーザーを指す。人々は常に何らかの意味でデザインを実践しており、専門家はその活動を支援・拡張する立場にある。 エキスパート・デザイナー（Expert Designer） は、専門的な訓練と視野を持ちながら、ディフューズ・デザイナーの活動を観察し、学び、彼らの実践を社会的に拡張する触媒として機能する。 この2者の関係性の設計こそが、社会イノベーション文脈でのデザイン思考の核だとマンジーニは論じている。 サステナビリティとデザイン マンジーニの研究において「サステナビリティ」は、環境負荷の削減という技術的問題にとどまらない。それは「どのような生活様式が長期的に継続可能か」という文化・社会・政治の問いだ。 マンジーニが繰り返し参照する概念が「スロー・コンセプト（Slow Concept）」だ。大量生産・大量消費・短サイクルの「ファスト・ソリューション」に対して、地域性・持続性・コミュニティの関与に基づく「スロー・ソリューション」をデザインはどう実現できるか、という問いだ。 この問題意識は、デザイン思考の定義フェーズで「本当に解くべき問いは何か」を問い直す習慣と親和性が高い。環境負荷を減らすという表層的な問いから「人々はどのような生活の質を求めているか」という深い問いへ掘り下げる作業は、まさに定義フェーズの実践だ。 社会イノベーションとデザイン思考の接続 マンジーニの研究は、デザイン思考が企業の製品・サービス開発というコンテキストを超えて、社会課題・行政・コミュニティ形成に適用される際の理論的基盤を提供している。 ダブルダイヤモンドの「問題の定義」と「解決策の開発」という構造は、マンジーニが言う「社会課題の文脈でも問題の設定そのものがデザインの作業だ」という認識と一致する。「コミュニティが抱える課題は、外から与えられた定義では解けない」——この認識がソーシャルイノベーションとデザイン思考を接続する共通言語だ。 また、マンジーニの「連結型個人」という概念は、デザイン思考のワークショップにおける参加者の多様性の重視と直接につながっている。問題の当事者・多様なバックグラウンドを持つ市民がデザインプロセスに参加することで、専門家だけでは見えない問題の層が現れる。 ミラノとデザイン研究のエコシステム マンジーニがポリテクニコ・ディ・ミラノに長く拠点を置いたことには、文脈的な必然性がある。ミラノは20世紀を通じてプロダクトデザイン・ファッション・建築の集積地として発展し、デザインを「文化的実践」として問い直す土壌を持っていた。 その環境の中で、マンジーニは「デザインの技術的卓越性」への敬意を保ちながら、同時にデザインの社会的責任と可能性を問い続けた。この両立がマンジーニの研究に独自の奥行きを与えている——卓越した実装への問いと、その実装が社会に何をもたらすかという問いを同時に持ち続ける姿勢だ。 デザイン思考実践者への示唆 マンジーニを知ることで、デザイン思考の適用範囲と哲学的な根拠について理解が広がる。 社会課題へのデザイン思考適用の根拠。 「デザイン思考は企業向けの手法だ」という誤解に対して、マンジーニの研究は「コミュニティ・行政・社会システムの設計こそデザインの歴史的な本来領域だ」という応答を提供する。 当事者参加の設計論。 ユーザーインタビューや共創ワークショップという実践が「なぜ有効か」の理論的根拠が、マンジーニの「ディフューズ・デザイナー」概念にある。課題の当事者はすでにデザイン的に思考している——専門家はその思考を可視化・拡張する役割を担う。 「解決策」より「関係性の設計」。 マンジーニが提示するコラボレイティブ・サービスの多くは、単一の解決策ではなく「誰が・どのように関わり合うか」という関係性の設計によって持続する。この視点はサービスデザインとエスノグラフィー実践に実質的なヒントを与える。 --- 主要著作 - Ezio Manzini, Design, When Everybody Designs: An Introduction to Design for Social Innovation, MIT Press, 2015（原題: Quando tutti fanno design, Einaudi, 2013） - Ezio Manzini & François Jégou, Sustainable Everyday: Scenarios of Urban Life, Edizioni Ambiente, 2003 - Ezio Manzini, The Material of Invention, MIT Press, 1989（原題: La materia dell'invenzione, 1986） - Ezio Manzini, Politics of the Everyday, Bloomsbury Visual Arts, 2019 --- 参考文献 - Ezio Manzini, Design, When Everybody Designs, MIT Press, 2015 - Ezio Manzini & François Jégou, Sustainable Everyday, Edizioni Ambiente, 2003 - DESIS Network: https://www.desisnetwork.org - Politecnico di Milano, Design School: Faculty profile records 関連記事: ダブルダイヤモンド / デザイン思考の定義フェーズ / ヒューマン・センタード・デザイン / Richard Buchanan — デザイン哲学者 --- ### デザイン思考の哲学的基盤を構築した理論家 URL: https://designthinking.studio/people/richard-buchanan-wicked-problems/ > 1992年の論文「Wicked Problems in Design Thinking」で、デザインを問題解決の知的方法論として再定義した思想家。Horst Rittel の「Wicked Problems」概念をデザイン実践と接続し、現代デザイン思考の概念基盤を形成した。 デザイン思考を語る際、IDEO の成功事例や Stanford d.school の5フェーズが語られることは多い。しかしなぜデザイン思考が「複雑な問題」に有効なのか——その理論的な根拠をほとんどの実践者は説明できない。 その根拠を作ったのが、リチャード・ブキャナン（Richard Buchanan）である。 ブキャナンが1992年に発表した論文「Wicked Problems in Design Thinking」（Design Issues, Vol.8, No.2）は、デザインという行為を哲学的・方法論的に再定義した転換点だ。この論文を読まずにデザイン思考の「なぜ」を語ることは、地図なしで山に入るようなものである。 --- Horst Rittel から受け継いだもの ブキャナンの思想を理解するには、まず Horst Rittel（ホルスト・リッテル）に遡る必要がある。 リッテルはカリフォルニア大学バークレー校のデザイン理論家であり、1973年に Melvin M. Webber とともに発表したペーパー "Dilemmas in a General Theory of Planning"（Policy Sciences, 4(2)）の中で「Wicked Problems（悪問題）」の概念を提唱した。 リッテルが定義した Wicked Problems の特徴は以下のように要約できる。 - 問題の定義自体が問題である。 何が問題かを明確にしようとするたびに、別の問題が見えてくる。問題の定義と解決策の探索が分離できない - 試みるたびに変わる。 解決策を試した瞬間に、問題の状況が変わる。一度きりの実験であり、同じ実験を繰り返せない - 正解も間違いもない。 「よい・悪い」ではなく「より良い・より悪い」でしか評価できない - 一意な答えがない。 無数の解決策の候補があり、原理的にすべてを列挙できない リッテルが念頭に置いていたのは都市計画や社会政策の問題だった。「貧困をなくすにはどうすればよいか」「都市交通渋滞を解消するにはどうするか」——これらは解けない問題ではなく、「解いた」と言える瞬間が存在しない問題だ。 ブキャナンはこの概念を、デザインという実践の核心に据えた。 --- 1992年論文の核心——「デザインは Wicked Problems を扱う知」 ブキャナンの論文「Wicked Problems in Design Thinking」が提示した最も重要な命題はこうだ。 デザインは、不確定性（indeterminacy）という条件の下で機能する。デザイナーは問題が完全に定義されるのを待ってから解決策を考えるのではない。問題を定義する行為そのものが、デザインの作業に含まれている。 — Richard Buchanan, "Wicked Problems in Design Thinking", Design Issues, Vol.8, No.2, Spring 1992, p.15 この命題が重要な理由を具体的に考えてほしい。 エンジニアリングや医学には「問題が定義されてから解決する」という構造がある。骨折の治療法は、骨折という問題が確定してから選択される。対して、「組織の意思決定プロセスをどう改善するか」という問いは、何が問題かを確定した瞬間から別の問題が立ち上がる。 ブキャナンはリッテルの概念を受け取りながら、それを批判的に発展させた。リッテルは Wicked Problems を「解けない問題」として半ば悲観的に記述したが、ブキャナンは「だからこそデザイン的な思考が必要だ」と反転させた。 論文の中でブキャナンは次のように書いている。 デザイン思考は、諸問題の部分的あるいは暫定的な解決策を通じて、人間の生活の状況を変革する新しい可能性を作り出すために使われる。 — ibid., p.16 「暫定的な解決策」という表現が鍵だ。 デザイン思考は最終的な正解を出すための手法ではなく、より良い暫定解を積み重ねることで状況を前進させる方法論である。この認識がなければ、プロトタイピングを「仮のもの」として素早く作る価値を、チームメンバーに説明できない。 --- 「デザインの4つの領域」——記号・物・行動・思考 論文の中でブキャナンが提示したもう一つの重要な貢献が「デザインの4つの領域（Four Domains of Design）」だ。 | 領域 | 対象 | 具体例 | |---|---|---| | 記号とイメージ（Symbolic and Visual Communication） | グラフィックデザイン・タイポグラフィ | ロゴ、書籍デザイン、UI のビジュアル | | 物（Material Objects） | プロダクトデザイン・工業デザイン | 家具、機器、日用品 | | 行動（Activities and Organized Services） | サービスデザイン・インタラクションデザイン | サービス設計、体験設計 | | 思考（Complex Systems or Environments） | 組織・システム・環境のデザイン | 組織設計、政策デザイン | ブキャナンはこの4領域を「スペクタクル（場）」と呼び、それぞれの領域でデザインが扱う問題の性質が異なることを示した。しかし同時に、どの領域の問題も Wicked Problems としての性質を持つという点で共通していることを論じた。 この分類が現代のデザイン思考に与えた影響は大きい。「デザインはものを作ることだ」という固定観念を崩し、行動や思考のシステムにまでデザインの視野を広げる根拠になった。Stanford d.school が「社会課題にデザイン思考を適用する」という教育方針を取る理論的な支えの一つが、この分類にある。 --- カーネギーメロン大学での実践——理論を教育に変換する ブキャナンはピッツバーグのカーネギーメロン大学（CMU）デザインスクールで長年教鞭をとり、学部長を務めた。CMU のデザインプログラムは、IDEO や Stanford d.school のような「実践の場」とは異なる「理論と実践の橋渡しの場」として機能した。 ブキャナンの授業では、デザインの歴史・哲学・修辞学が扱われた。修辞学（Rhetoric）をデザイン思考の方法論として捉える視点——「デザインは説得の行為である」という命題——は、ブキャナンがもたらした独自の貢献だ。 プロダクトや環境は、ユーザーに特定の行動・態度・価値観を「説得」する。使いやすいデザインは「あなたはここで操作できる」と説得し、アクセシブルなデザインは「あなたはここに属している」と説得する。この視点は、デザイン思考における「ユーザーとの対話」をより豊かに捉える枠組みを提供した。 --- Rittel → Buchanan → 現代実務の系譜 1973年のリッテルから1992年のブキャナンを経て、現代のデザイン思考実践に至る系譜を整理する。 Rittel（1973）： Wicked Problems を問題の類型として発見・記述する。都市計画・政策のコンテキスト。「解けない問題がある」という告発。 Buchanan（1992）： Wicked Problems をデザイン思考の作業領域として再解釈する。「解けない問題こそデザインが扱う対象だ」という転換。デザインを問題解決ではなく「問題の探索と暫定解の連鎖」として再定義。 IDEO / d.school（1990年代〜）： ブキャナンの哲学を実践プロセスに変換する。「共感→定義→創造→プロトタイプ→テスト」の5フェーズは、「問題は反復的に発見・再定義される」というブキャナンの命題の実装形だ。特に 「定義（Define）フェーズ」で HMW（How Might We）を立て直す作業は、Wicked Problems 概念の直接的な実践訳だと理解できる。 現代（2010年代〜）： デザイン思考が行政・医療・教育などの複雑系課題に適用される。ブキャナンが「思考のデザイン（第4領域）」と呼んだ領域が、まさに適用対象になる。 --- なぜブキャナンを知らずにデザイン思考を語れないのか ブキャナンの論文を読んでいないデザイン思考の実践者でも、その影響下で仕事をしている。それがブキャナンの思想の浸透の証拠でもある。 しかし、ブキャナンへの無理解が実践を浅くする場面はある。 ワークショップでよく起こるのは、プロトタイプが一度うまくいかなかっただけで「アプローチを変えよう」と結論を急ぐチームだ。問題の定義が変わり続けることを許容しない、つまり Wicked Problems の本質を受け入れていない状態だ。ブキャナンが言う「暫定的な解決策の連鎖」を実践するためには、「問題は1回の定義で固まらない」という認識をチーム全体で共有する必要がある。 あるいは、「デザイン思考で解決できない問題がある」という批判に対して、実践者が適切に応答できないケースも多い。ブキャナンはむしろ「デザインが扱う問題は本質的に解決不可能だ」と言っている——その上でデザイン思考が価値を持つのは、「解く」ためではなく「より良い暫定解を積み重ねる」ためだというロジックが、批判への正確な返答になる。 デザイン思考の5フェーズは「プロセス」だ。ブキャナンはそのプロセスが何を前提にし、何を目指しているかの「哲学」を提供した。プロセスだけを知っている実践者と、哲学まで知っている実践者では、複雑な局面での判断の質が変わる。 --- こんな人にブキャナンを読んでほしい デザイン思考を「手法のツールボックス」として学んでいる人へ。 ペルソナの作り方やHMWの書き方は手が届く場所に情報がある。しかし「なぜその手法が機能するのか」「なぜプロトタイプを反復することに意味があるのか」という問いに答えられない実践者は多い。ブキャナンの論文は、その「なぜ」の層を埋める。 組織内でデザイン思考の価値を説明する立場にある人へ。 「デザイン思考で何が解決できるのか」という問いに対して、「複雑な問題に構造的にアプローチできる」では答えになっていない。Wicked Problems の概念を借りることで、「デザイン思考が有効な問題の種類」と「有効でない問題の種類」を正確に説明できるようになる。 デザイン思考への批判に晒されている人へ。 「デザイン思考はただのポストイット遊び」「ワークショップで終わって実装されない」という批判は、実践の場では珍しくない。ブキャナンが与えてくれるのは、批判への反論ではなく、批判の中に正当な指摘を見分ける力だ。「暫定解の連鎖」という概念を持っていれば、プロトタイプが否定されることを「失敗」ではなく「情報の獲得」として説明できる。 --- 参考文献 - Richard Buchanan, "Wicked Problems in Design Thinking", Design Issues, Vol.8, No.2, Spring 1992, pp.5–21 - Horst W.J. Rittel & Melvin M. Webber, "Dilemmas in a General Theory of Planning", Policy Sciences, 4(2), 1973, pp.155–169 - Richard Buchanan, "Declaration by Design: Rhetoric, Argument, and Demonstration in Design Practice", Design Issues, Vol.2, No.1, 1985 - Richard Buchanan & Victor Margolin (eds.), Discovering Design: Explorations in Design Studies, University of Chicago Press, 1995 - Victor Margolin & Richard Buchanan (eds.), The Idea of Design, MIT Press, 1995 関連記事: デザイン思考の定義フェーズ / デザイン思考の限界と批判 / Don Norman — ユーザー中心設計の父 --- ### デザイン哲学者・カーネギーメロン大学デザインスクール元学部長 URL: https://designthinking.studio/people/richard-buchanan/ > 1992年の論文「Wicked Problems in Design Thinking」でデザインを複雑問題への知的方法論として再定義した哲学者・教育者。Horst Rittelの「Wicked Problems」概念をデザイン実践と接続し、現代デザイン思考の概念的基盤を形成した。デザインの4領域論により、グラフィックから組織設計までデザインの射程を広げた。 デザイン思考の5フェーズを知っている実践者は多い。しかし「なぜその5フェーズが有効なのか」という哲学的な根拠を説明できる実践者は少ない。 その根拠を作ったのがリチャード・ブキャナン（Richard Buchanan）だ。ブキャナンは1992年に発表した一本の論文によって、デザインという行為を「複雑な問題を扱う知的方法論」として哲学的に再定義した。 それ以前のデザイン研究が「いかに美しく・機能的なものを作るか」に焦点を当てていたのに対して、ブキャナンは「デザインとは何種類の問題を、どのように扱う行為なのか」という根本的な問いを立て直した。 経歴と思想の形成 ブキャナンは修辞学（Rhetoric）を基盤に持つ異色のデザイン研究者だ。修辞学とは「言語や記号を通じて、聴衆の思考・行動・態度に働きかける技芸」であり、古代ギリシャのアリストテレスまで遡る知的伝統を持つ。 この修辞学の訓練がブキャナンのデザイン観に独自の奥行きを与えた。デザインされた物・環境・サービスは、ユーザーに特定の行動や態度を「説得する」メディアだというのがブキャナンの基本的な認識である。椅子の設計は「ここに座ることが正しい姿勢だ」と説得し、公共空間の設計は「ここはあなたが歓迎される場所だ」と説得する。この視点はデザイン思考の共感フェーズで「ユーザーは何を求めているか」を問う姿勢と、深いところで共鳴している。 ピッツバーグのカーネギーメロン大学（CMU）では、デザインスクールの学部長を務めながら、設計理論・デザインの歴史・修辞学を教えた。後にケース・ウェスタン・リザーブ大学ワイザーバー経営大学院でデザインと組織論の交差点を探求した。 CMUのデザインプログラムはIDEOや Stanford d.school のような「実践の工房」とは異なる性質を持っていた。「なぜそうするのか」という問いを実践と並走させる「理論と実践の橋渡しの場」として機能し、ブキャナンはその中心にいた。 --- 1992年論文「Wicked Problems in Design Thinking」 ブキャナンの最も重要な貢献は、Design Issues（Vol.8, No.2, Spring 1992）に掲載された論文「Wicked Problems in Design Thinking」だ。この17ページの論文は、現代デザイン思考の概念基盤をほぼ単独で形成した。 Horst Rittelから受け継いだもの ブキャナンの議論の出発点は、カリフォルニア大学バークレー校のデザイン理論家 Horst Rittel（ホルスト・リッテル）が1973年に提唱した「Wicked Problems（邪悪な問題／悪問題）」の概念だ。リッテルは Melvin Webber との共著論文「Dilemmas in a General Theory of Planning」（Policy Sciences, 4(2)）の中で、都市計画や社会政策が扱う問題の特殊な性質を次のように記述した。 問題の定義自体が問題である。 何が問題かを明確にしようとすると、別の問題が浮かび上がる。「貧困をなくすにはどうすればよいか」という問いは、「貧困の定義とは何か」という問いを生む。 試みるたびに状況が変わる。 解決策を試した瞬間に、問題の状況そのものが変化する。都市交通渋滞を解消するために道路を拡張すると、新たな交通量を誘発して渋滞が復活する（「誘発交通」として知られる現象）。 正解も間違いもなく「より良い・より悪い」しかない。 評価基準が固定できないため、「解けた」と宣言できる瞬間がない。 原理的に無限の解決策の候補がある。 すべての可能性を列挙して最適解を選ぶという手続きが成立しない。 リッテルはこれを都市計画・政策立案のコンテキストで記述し、どちらかといえば悲観的な問題提起として提示した。「こういう問題は解けない」という告発に近かった。 ブキャナンの転換——「だからこそデザインが必要だ」 ブキャナンの独創性は、リッテルの悲観的な問題診断を「デザインが活躍できる領域の定義」として反転させたことにある。 論文の中でブキャナンはこう書いている。 デザインは、不確定性（indeterminacy）という条件の下で機能する。デザイナーは問題が完全に定義されるのを待ってから解決策を考えるのではない。問題を定義する行為そのものが、デザインの作業に含まれている。 — Richard Buchanan, "Wicked Problems in Design Thinking", Design Issues, Vol.8, No.2, Spring 1992, p.15 「問題を定義する行為そのものがデザインの作業に含まれている」——この一文が、デザイン思考の核心だ。 エンジニアリングには「問題が確定してから解決策を設計する」という順序がある。骨折の治療法は、骨折という診断が確定してから選択される。しかし「組織のイノベーション文化をどう醸成するか」「患者の入院体験をどう改善するか」という問いは、問題が確定する前に動き始めなければならない。 ブキャナンはさらにこう続ける。 デザイン思考は、諸問題の部分的あるいは暫定的な解決策を通じて、人間の生活の状況を変革する新しい可能性を作り出すために使われる。 — ibid., p.16 「暫定的な解決策」という表現が決定的に重要だ。 デザイン思考は最終的な正解を導くための手法ではなく、「より良い暫定解」を積み重ねることで状況を前進させる方法論だ。この認識があれば、プロトタイプが否定されたときに「失敗した」ではなく「情報を得た」と解釈できる。 ワークショップでよく起こるのは、プロトタイプへのネガティブなフィードバックを受けたチームが「このアプローチはダメだ」と結論を急ぐことだ。しかしブキャナンが言う「Wicked Problems の暫定解の連鎖」という概念を持っていれば、「これは解決への一歩であり、問題の輪郭を再定義するための情報だ」と説明できる。 --- デザインの4領域——射程の拡張 ブキャナンの論文が提示したもう一つの重要な貢献が「デザインの4領域（Four Orders of Design）」だ。この分類はデザインを「もの作り」に限定する従来の認識を根本から覆した。 | 領域 | 対象 | 具体例 | |---|---|---| | 記号とイメージ（Symbolic and Visual Communication） | グラフィックデザイン・タイポグラフィ | ロゴ、書体、UIビジュアル | | 物（Material Objects） | プロダクトデザイン・工業デザイン | 家具、医療機器、日用品 | | 行動（Activities and Organized Services） | サービスデザイン・インタラクションデザイン | 体験設計、サービス設計 | | 思考（Complex Systems or Environments） | 組織・システム・環境のデザイン | 組織設計、政策デザイン | ブキャナンはこの4つを「プレイス（場）」と呼んだ。重要なのは、どの領域の問題も本質的に Wicked Problems としての性質を持つという点だ。グラフィックデザインはビジュアルコミュニケーションの問題を扱うが、「この情報をどう視覚化すれば最も正確に伝わるか」という問いは一義的に解けない。組織設計はいうまでもなく、問題の定義が絶えず変化する。 第4領域「思考・システムのデザイン」の提示は、後の「組織へのデザイン思考適用」という方向性に理論的な正当性を与えた。 Stanford d.school が「社会課題にデザイン思考を適用する」という教育方針を取り、IDEO が政府・医療・教育機関向けの組織変革支援を事業化できたのは、ブキャナンがデザインの射程を「第4領域」まで広げたからだと言える。 --- 修辞学とデザイン——「説得の技芸」としての設計 ブキャナンが修辞学をデザイン論に持ち込んだのは、思想的な一貫性に基づいている。 1985年の論文「Declaration by Design: Rhetoric, Argument, and Demonstration in Design Practice」（Design Issues, Vol.2, No.1）で、ブキャナンはこう論じた。デザインされた人工物は「主張（Argument）」を持つ。デザインは中立的な形態決定ではなく、特定の価値・行動・態度を聴衆（ユーザー）に提示し、それへの同意を求める説得の行為だ。 この視点は実務的な含意を持つ。デザイン思考の「ユーザーテスト」は、プロトタイプが「説得に成功したかどうか」を確かめる行為でもある。 ユーザーがプロトタイプを直感的に使えた場合、そのデザインはユーザーに「ここはこう使うものだ」という主張を正確に届けたことになる。 ワークショップ参加者から「テストでユーザーが指示通りに動かなかった」という声を聞くことがある。しかしブキャナンの修辞学的な枠組みで捉えれば、「動かなかった」のではなく「デザインの説得が失敗した」のだ。失敗の責任をユーザーに帰属させない——この認識の転換が、Don Norman の「アフォーダンス論」と深く響き合っている。 --- Rittel → Buchanan → 現代実践の系譜 デザイン思考の知的系譜を整理すると、ブキャナンの位置が明確になる。 Rittel（1973年）： Wicked Problems を発見・記述する。「解けない問題がある」という告発。都市計画・社会政策の問題として位置づけ。 Buchanan（1992年）： Wicked Problems をデザインの固有の作業領域として再定義する。「解けない問題こそデザインが扱う対象だ」という転換。デザインを「問題の探索と暫定解の連鎖」として再記述。 IDEO / Stanford d.school（1990年代〜）： ブキャナンの哲学を実践プロセスとして実装する。「共感→定義→創造→プロトタイプ→テスト」の5フェーズは、ブキャナンの命題を体系化した実践形だ。定義フェーズでの HMW（How Might We）の立て直しは、「問題の定義は反復される」というブキャナン命題の直接的な実践訳だ。 現代（2010年代〜）： デザイン思考が医療・行政・教育・組織変革に適用される。これはブキャナンが「第4領域」として概念化した「思考・システムのデザイン」領域が、実践の主戦場になったことを意味する。 --- ブキャナンを知っている実践者と知らない実践者の違い ブキャナンの論文を読んでいなくても、現代のデザイン思考の実践者はその思想の影響下で仕事をしている。5フェーズプロセスを通して、ブキャナンの哲学はすでに実践の中に溶け込んでいるからだ。 しかし、ブキャナンへの理解が実践を深める場面は具体的にある。 「プロトタイプが否定されたとき」の解釈が変わる。 Wicked Problems の概念を持っていれば、プロトタイプへの否定的フィードバックは「失敗」ではなく「問題の輪郭を精緻化するための情報」として受け取れる。チームのモチベーション管理と、プロセスの継続意思決定の両方に影響する。 「デザイン思考で何が解決できるか」を正確に説明できる。 「複雑な問題に対応できる」では答えになっていない。Wicked Problems の概念を使えば「問題の定義が定まらない問題・試みるたびに状況が変化する問題」に対して有効だと、精度の高い説明ができる。 批判に正確に応答できる。 「デザイン思考はポストイット遊びで終わる」という批判は、「暫定解の連鎖を正しく運用していない」ことへの正当な指摘を含んでいる。ブキャナンを知っていれば、批判の正当な部分を認めながら、デザイン思考の本質的な価値を守る応答ができる。 実際にやってみると、ブキャナンの論文を読んだ翌週のワークショップでは、定義フェーズで問いを立て直すことへの抵抗感が全く変わる。「問題は1度で固まらない」という許可を哲学的な根拠とともに持てるからだ。 --- 主要著作 - "Wicked Problems in Design Thinking", Design Issues, Vol.8, No.2, Spring 1992, pp.5–21 — ブキャナンの代表作。デザイン思考の哲学的基盤を形成した転換点論文 - "Declaration by Design: Rhetoric, Argument, and Demonstration in Design Practice", Design Issues, Vol.2, No.1, 1985 — 修辞学とデザインを接続した先行論文 - "Rhetoric, Humanism, and Design", in Buchanan & Margolin (eds.), Discovering Design: Explorations in Design Studies, University of Chicago Press, 1995 - Victor Margolin & Richard Buchanan (eds.), The Idea of Design, MIT Press, 1995 — デザイン研究のアンソロジー。ブキャナンが編者として知的な場を形成した --- 参考文献 - Richard Buchanan, "Wicked Problems in Design Thinking", Design Issues, Vol.8, No.2, Spring 1992, pp.5–21 - Horst W.J. Rittel & Melvin M. Webber, "Dilemmas in a General Theory of Planning", Policy Sciences, 4(2), 1973, pp.155–169 - Richard Buchanan, "Declaration by Design: Rhetoric, Argument, and Demonstration in Design Practice", Design Issues, Vol.2, No.1, 1985 - Richard Buchanan & Victor Margolin (eds.), Discovering Design, University of Chicago Press, 1995 - Tim Brown, Change by Design, HarperBusiness, 2009 関連記事: デザイン思考の定義フェーズ / デザイン思考の限界と批判 / Wicked Problems とは何か / Don Norman — 認知科学者・UX研究者 --- ### バージニア大学ダーデン経営大学院 教授 / 経営戦略×デザイン思考の研究者 URL: https://designthinking.studio/people/jeanne-liedtka-expanded/ > バージニア大学ダーデン経営大学院教授。「Designing for Growth」「Design Thinking for the Greater Good」の著者。デザイン思考をビジネス戦略と社会イノベーションに橋渡しした研究者として国際的に知られる。 ジーン・リートカ（Jeanne Liedtka）は、バージニア大学ダーデン経営大学院の教授で、 デザイン思考をビジネス戦略と社会課題解決の文脈に接続した研究者 として国際的に知られています。d.schoolやIDEOが「デザイナーの方法論」としてデザイン思考を普及させた一方で、リートカは「なぜデザイン思考が経営的意思決定を改善するのか」という問いに学術的根拠を与えることに取り組んできました。 経歴 リートカはビジネス戦略と組織学習を専門とし、長年ダーデン経営大学院で教鞭を執っています。MBAプログラムでのデザイン思考教育のパイオニアとして、デザイン思考を経営大学院のカリキュラムに組み込む先駆的な役割を果たしました。 ダーデン在籍中には、UVA内の学際的なデザイン思考センター（Batten Institute for Entrepreneurship and Innovation）の活動にも深く関与し、 ビジネス、デザイン、医療、教育、非営利の横断的な実践研究 を推進してきました。 主要著書 『Designing for Growth』（2011年） Tim OgilviとのコアウオーサーであるこのSocial Innovation実践ガイドは、 「デザイン思考を使って組織の成長戦略を立てる方法」 を実務家向けに解説した書籍です。「デザイン思考はスタートアップやIDEOのような企業だけのものではない」という命題を、大企業の意思決定者に向けて提示しました。 「Designing for Growth」の特徴は、デザイン思考を 「何を、誰のために、どのように」という戦略立案の3軸に落とし込んだ フレームワークです。経営の意思決定ツールとしてのデザイン思考を論じることで、戦略論・ビジネスモデル論の文脈とデザイン思考を接続しました。 『Design Thinking for the Greater Good』（2017年） 社会的課題へのデザイン思考適用 に焦点を当てた書籍です。医療・教育・政府・非営利セクターという従来のデザイン思考実践とは異なる文脈での10のケーススタディを詳細に分析しています。 本書の中心的な問いは「複雑な社会課題に対して、デザイン思考はどう機能し、どこで限界があるか」です。リートカは成功例だけでなく失敗や困難も包み隠さず分析し、 ウィキッド・プロブレムに対するデザイン思考の適用条件と限界 を誠実に論じています。 「デザイン思考は万能だ」という熱狂的な主張ではなく、「どんな条件下でどのような効果があるか」という実証的・批判的な態度で研究を積み重ねているのが、彼女の研究スタイルの特徴です。 研究の核心：デザイン思考はなぜ意思決定を改善するのか リートカの研究の根幹にある問いは「 デザイン思考が組織の意思決定を改善するメカニズムは何か 」です。 リートカは複数の論文で、デザイン思考の価値を「創造性」ではなく「認知的プロセスの変容」として説明しています。通常の経営的意思決定は、 「既知の情報から最適解を選ぶ」収束的思考（Convergent Thinking）に偏りがちです。 デザイン思考は、その前段階に 「問いを広げ、前提を疑い、多様な可能性を探索する」発散的思考（Divergent Thinking）を意図的に組み込む ことで、意思決定の質を変えます。 Design Management Journal（2004年）への寄稿論文では、デザイン思考の本質を「abductive reasoning（アブダクション的推論）」——既存の証拠から最良の説明を選び取る推論方式——として分析しました。この分析は、デザイン思考の哲学的根拠を明確にした先駆的な論考として引用されています。 MBAにおけるデザイン思考教育の実践 リートカはダーデンでのMBA教育の中で、 ケーススタディ手法とデザイン思考ワークショップを統合する授業設計 を開発してきました。ビジネスケースを分析する際に、デザイン思考の5フェーズで問いを立て直す実習を組み合わせることで、「状況を分析する」から「状況の中にいるユーザーに共感する」への視点転換を促します。 「デザイン思考は大学院で教えられるものか」という問いに対して、リートカの答えは実証的です。ダーデンでの実践から、 ビジネス教育においてデザイン思考は「技術」として教えることより「態度」として培うことの方が重要 だという知見が得られているとしています。これはデザイン思考の教育導入全般に適用できる洞察です。 社会イノベーションへの貢献 2017年の著書以降、リートカの研究は社会課題解決へのデザイン思考適用に重点を移しています。医療システムの改善・公共教育の改革・行政サービスの人間中心設計——行政サービスへのデザイン思考適用に関心を持つ実践者にとって、リートカの研究は理論的な基盤を提供します。 特に「Design Thinking for the Greater Good」のケーススタディは、 利益動機なしにデザイン思考を駆動するとき、何がそのエネルギーを維持するか という問いを深く掘り下げています。社会課題解決においては「良い意図」だけでは持続しない——実践の継続のためのシステム設計が必要だという洞察は、NPO・行政・ソーシャルセクターの実践者へのメッセージです。 デザイン思考批判への応答 リートカは、デザイン思考への学術的批判にも誠実に向き合っています。「デザイン思考は本当に効果があるのか、それとも一時的なブームに過ぎないのか」という懐疑的な問いに対して、 効果が生まれる条件と生まれない条件を実証的に区別する研究 を積み重ねることで応答しています。 実証研究では、 デザイン思考の効果は「心理的安全性のあるチーム環境」と「リサーチと実験を繰り返す十分な時間」という2つの条件に強く依存する ことが示されています。これらの条件が欠如するとき、デザイン思考は形式的なワークショップになり、実質的な価値を生まないという分析は、導入を検討する組織への現実的な警告です。 --- 参考文献 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business School Publishing, 2011 - Jeanne Liedtka, Andrew King & Kevin Bennett, Solving Problems with Design Thinking: Ten Stories of What Works, Columbia Business School Publishing, 2013 - Jeanne Liedtka, Randy Salzman & Daisy Azer, Design Thinking for the Greater Good, Columbia University Press, 2017 - Jeanne Liedtka, "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction," Journal of Product Innovation Management, 32(6), 2015 --- ### 経営学者・イノベーション研究者 URL: https://designthinking.studio/people/eric-von-hippel/ > ユーザーイノベーション理論の創始者。Lead User Method（リードユーザー法）を開発し、イノベーションの源泉が生産者ではなくユーザー自身にあることを実証した。著書『The Sources of Innovation』『Democratizing Innovation』でイノベーション研究の根本的な前提を問い直した。 エリック・フォン・ヒッペル（Eric von Hippel、1941年生まれ）は、「イノベーションは誰が起こすか」という問いに対して、長年の通説を覆した経営学者だ。MITスローン・スクール・オブ・マネジメントのT. Wilson Professorとして、ユーザーイノベーション理論を体系化し、Lead User Method（リードユーザー法）という実践的な手法を開発した。 通説の転覆——「ユーザーが革新する」 20世紀のイノベーション研究の主流は、企業（生産者）がイノベーションの担い手であるという前提に立っていた。フォン・ヒッペルが1988年の The Sources of Innovation（Oxford University Press）で提示したのは、この前提を覆す実証だった。科学機器・半導体製造装置・スポーツ用品など複数の産業を調査した結果、重要なイノベーションの多くは生産者ではなくユーザーによって最初に開発・試作されていた。 フォン・ヒッペルの定義するユーザーイノベーターとは、革新から得る利益が「使用利益（use benefit）」であって「販売利益（sale benefit）」ではない存在だ。「自分が使えるものを作る」という動機が、「売れるものを作る」という動機とは根本的に異なる成果を生む——この差異の解明がフォン・ヒッペルの研究の核心だった。 Lead User Method——最前線のユーザーを探す 理論的な発見を実践に接続したのが、Lead User Method（リードユーザー法）だ。 「リードユーザー（Lead User）」とは、2つの特性を持つユーザーだ。第一に、一般市場よりも数ヶ月から数年早い段階でニーズに直面しているユーザー。第二に、そのニーズを自ら解決することで大きな便益を得られるユーザー。市場の「最前線」にいて、自力で問題を解く強いインセンティブを持つ人々だ。 3Mの医療用マスク改良開発では、研究チームが既存ユーザーではなく感染症の最前線にいる医師や工業用マスク分野のユーザーにアクセスした。このリードユーザーとの共同開発から生まれたコンセプトは、通常の市場調査から生まれたものより高い評価を得た。Lego Mindstormsでは、発売後に熱心なユーザーたちが非公式にシステムを改造・拡張し始め、その動きがLegoの公式なコミュニティ戦略へと影響を与えた——企業の想定を超えてユーザーが製品を進化させた典型例だ。 『Democratizing Innovation』——イノベーションの民主化 2005年にMIT Pressから刊行された Democratizing Innovation（邦題のない英語原著は無償公開されている）は、フォン・ヒッペルの研究を新たなフェーズへと押し進めた著作だ。 本書の中心命題は、デジタルツールとインターネットの普及によって、ユーザーがイノベーターとして活動するコストが劇的に低下したという観察だ。CADソフトウェア・プログラミング言語・オープンソースのインフラにより、ユーザーは生産者の助けを借りなくても自分のニーズに合わせた解決策を開発できるようになった。Linux やApacheが企業のR&Dではなく分散した個人の協働によって開発・維持されているという事実は、「イノベーションは組織内で管理されなければならない」という前提を正面から否定するものだ。本書はMIT Pressのウェブサイトで無償公開されており、これ自体が「民主化」という主張の実践だった。 『Free Innovation』——贈与としてのイノベーション 2017年のMIT Press刊行 Free Innovation は、探求をさらに深めた著作だ。「Free Innovation」とは知的財産権で保護されず無償で共有されるイノベーションを指す。消費者調査の結果、多くの国で一定割合の消費者が製品・改良品を開発し成果を無償で共有していることが示された。この「自由なイノベーター」を動かすのは利益動機ではなく使用利益と作ること自体の喜びであり、フォン・ヒッペルはこのセクターを企業の商業イノベーションと補完的な関係として位置づけた。 デザイン思考への接続 フォン・ヒッペルの問いは、デザイン思考の実践者にとって根本的な意味を持つ。 「ユーザーは問題の発見者であるだけでなく、解決策の発明者でもある」——この主張は共感フェーズの目的を再定義する。ユーザーを「理解すべき対象」と見るのではなく、「潜在的なイノベーターとして協働すべき存在」として捉える視点だ。 Lead User Methodはアイデエーションフェーズの情報源の質を変える。一般ユーザーへの調査が「現在のニーズの平均値」を返すのに対し、リードユーザーへのアクセスは「数年後の市場ニーズの先行指標」を提供する。誰と対話するかが、何を問うかと同じくらい重要だ。 ジェーン・フルトン・スリが「Thoughtless Acts」として記述した無意識の行動と、フォン・ヒッペルが実証したユーザーの能動的な問題解決は、同じ現象の異なる側面だ。ユーザーはデザイナーの意図通りに使わないのではなく、自分のニーズに合わせて積極的に適応している——その改造・工夫・回避行動こそが最良のインサイト源になる。 --- 参考文献 - Eric von Hippel, The Sources of Innovation, Oxford University Press, 1988 - Eric von Hippel, Democratizing Innovation, MIT Press, 2005（MIT Press にて無償公開） - Eric von Hippel, Free Innovation, MIT Press, 2017 - Eric von Hippel, "Lead Users: A Source of Novel Product Concepts", Management Science, 1986 関連記事: デザイン思考の共感フェーズ / アイデエーションフェーズ / Lead User Method / ジェーン・フルトン・スリ --- ### 経営学者・デザイン思考研究者 URL: https://designthinking.studio/people/jeanne-liedtka/ > デザイン思考を戦略経営に統合した研究者。『Designing for Growth』でデザイン思考をビジネスパーソンが使えるツールとして体系化し、組織変革への応用を拓いた。 ジャン・リードカ（Jeanne Liedtka）は、デザイン思考と戦略経営を橋渡しした研究者です。バージニア大学ダーデン・スクール・オブ・ビジネスの教授として、「デザイン思考は創造性の高いデザイナーのためだけのものではなく、ビジネスリーダーが使える意思決定フレームワークだ」という主張を研究と実践の両面で展開してきました。 「誰でも使えるデザイン思考」への翻訳 リードカの最大の貢献は、スタンフォードd.schoolやIDEOが体系化したデザイン思考を、経営者・マネージャー・中間管理職が組織の中で実践できる形に翻訳したことにあります。 IDEOやd.schoolのフレームワークは、プロのデザイナーや学生が習得する前提で設計されています。「共感」「プロトタイプ」という言葉は、デザインの文脈では自明ですが、製造業の品質管理部門や金融機関の営業チームには、翻訳が必要です。 リードカの著書『Designing for Growth: A Design Thinking Tool Kit for Managers』（2011年、コロンビア大学出版）は、この翻訳を実現したテキストです。「What is?（現状は何か）」「What if?（もし〜ならどうなるか）」「What wows?（何が刺さるか）」「What works?（何が機能するか）」という四つの問いで構成されるフレームワークは、デザイン思考の5フェーズを「ビジネスの問いかけ」として再記述したものです。 認知バイアス軽減としてのデザイン思考 リードカの研究でもうひとつ注目すべきは、デザイン思考の効果を「認知バイアスの軽減」として実証的に分析した点です。 2015年に Journal of Product Innovation Management に発表した論文「Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction」では、デザイン思考のプロセスが確証バイアス・利用可能性バイアス・現状維持バイアスなど、組織の意思決定を歪める認知バイアスをどう低下させるかを整理しました。 「デザイン思考が機能する理由」を感情的・文化的な説明ではなく、認知科学的なメカニズムとして説明したこの研究は、経営者やアカデミックな読者への説得力を高めました。 『Experiencing Design』と体験学習 2021年の著書 Experiencing Design: The Innovator's Journey（Tim Ogilvie, Kate Kaplan, David Reznikとの共著）では、デザイン思考を「習得するもの」ではなく「体験を通じて変容するもの」として提示しています。 知識として学ぶだけでは不十分であり、実際の問題に対してプロセスを走らせることで初めて身体化されるという主張は、デザイン思考教育の設計に大きな示唆を持ちます。 組織変革においても同様の主張が貫かれています。「デザイン思考の研修を受けた」という状態と「デザイン思考を日常の意思決定に使っている」という状態の間には大きなギャップがあり、そのギャップを埋めるのは「体験」の蓄積だとリードカは主張します。 --- 参考文献 - Jeanne Liedtka & Tim Ogilvie, Designing for Growth: A Design Thinking Tool Kit for Managers, Columbia Business Press, 2011 - Jeanne Liedtka, "Perspective: Linking Design Thinking with Innovation Outcomes through Cognitive Bias Reduction", Journal of Product Innovation Management, Vol. 32, No. 6, 2015 - Jeanne Liedtka, Tim Ogilvie, Kate Kaplan & David Reznik, Experiencing Design: The Innovator's Journey, Columbia Business Press, 2021 - Darden School of Business faculty profile, darden.virginia.edu --- ### 経営思想家・元ロットマン経営大学院学長 URL: https://designthinking.studio/people/roger-martin/ > 「統合的思考（Integrative Thinking）」の概念を提唱し、デザイン思考をビジネス戦略と結びつけた経営思想家。著書『ザ・デザイン・オブ・ビジネス』はビジネスにおけるデザイン思考の必読書。 ロジャー・マーティン（Roger Martin、1956年生まれ）は、カナダのトロント大学ロットマン経営大学院の元学長（2013年まで15年間在任）であり、「統合的思考（Integrative Thinking）」の概念を通じてデザイン思考とビジネス戦略を接続した経営思想家です。Thinkers50にて「世界で最も影響力のある経営思想家」トップ10に複数回選出されています。 経歴 ハーバード大学でビジネスを学び、同大学ビジネススクールでMBAを取得。モニター・グループ（現・デロイト・コンサルティング）で経営コンサルタントとして活躍後、1998年にロットマン経営大学院の学長に就任します。就任直後からデザイン思考をMBAカリキュラムに取り込む試みを開始し、経営大学院とデザイン教育の融合を積極的に推進しました。 2013年に学長職を退いた後も、プロアクター・グループを通じてグローバル企業の戦略アドバイザーとして活動を続けています。 統合的思考とは何か マーティンが提唱する「統合的思考（Integrative Thinking）」は、相反する2つのモデルの緊張関係を創造的に解消し、どちらのモデルよりも優れた解決策を生み出す能力のことです。 従来の意思決定では「AかBか」という二択に収束しがちです。しかしマーティンは、優れた経営者は「AとBの両方の良い部分を取り込んだC」を生み出すことで問題を解決していると分析しました。この「第三の答えを作る」思考プロセスこそが、デザイン思考の核心と重なっています。 統合的思考の4つのプロセスは以下の通りです。 - 顕著性（Salience） — 何を関連ある要因として認識するか - 因果関係（Causality） — 要因同士のつながりをどう見るか - アーキテクチャ（Architecture） — 問題をどう構造化するか - 解決策（Resolution） — 相反する要求からどう解決策を作るか 著書『ザ・デザイン・オブ・ビジネス』 2009年に出版された The Design of Business: Why Design Thinking Is the Next Competitive Advantage は、デザイン思考を競争優位の源泉として経営戦略と接続した重要な著作です。 マーティンはこの書籍で「ナレッジファネル」の概念を提示しました。ビジネスにおける知識の進化は「謎（Mystery）→ヒューリスティクス（Heuristic）→アルゴリズム（Algorithm）」という段階をたどります。多くの企業はアルゴリズムの最適化（効率化）に集中するあまり、謎の探索（イノベーション）をやめてしまうというジレンマを指摘しました。 デザイン思考が担う役割は、謎の段階で「分からないことを探索し、新しいヒューリスティクスを作ること」です。効率化と探索の間の緊張を管理することが、現代の経営者の核心的な仕事だとマーティンは論じています。 P&G との協働とデザイン経営の実践 マーティンはP&Gのボブ・マクドナルドCEO（在任2009〜2012年）のアドバイザーとして、P&G全体にデザイン思考を浸透させるプロジェクトに関与しました。P&GがIDEOと協働し、消費者の生活観察から製品開発を行う「リビングイットプログラム」の思想的バックボーンには、マーティンの統合的思考の影響があります。 また、リーバイ・ストラウス、ノキア、RBC（カナダロイヤル銀行）など多数のグローバル企業の戦略立案にも参加し、デザイン思考を「理論」ではなく「経営現場のツール」として機能させる実績を積み上げてきました。 デザイン思考に対する批判的視点 マーティンはデザイン思考の熱烈な支持者である一方、その誤用にも警鐘を鳴らしています。2019年のHBR論文「The Problem with Design Thinking」では、「デザイン思考が一連のプロセスに矮小化され、思考そのものが軽視されている」という問題提起を行いました。 5 Whysのような手法がテンプレートとして使われるとき、手法を使うことが目的になり、問題の本質を問うことが疎かになるというパターンがあると指摘しています。この批判は、ドン・ノーマンの「デザイン思考はスモールデザインに偏りすぎている」という問題意識と共鳴しています。 ロットマン経営大学院の遺産 マーティンが15年間学長を務めたロットマン経営大学院は、今日でも世界でデザイン思考をMBA教育に最も深く組み込んだビジネススクールのひとつです。デザイン思考のワークショップを必修科目として設置し、アート・デザイン・ビジネスの融合を教育方針の中核に据えています。 --- 参考文献 - Roger Martin, The Design of Business: Why Design Thinking Is the Next Competitive Advantage, Harvard Business Press, 2009 - Roger Martin, The Opposable Mind: Winning Through Integrative Thinking, Harvard Business Press, 2007 - Roger Martin, "The Problem with Design Thinking", Harvard Business Review, March 2019 - Thinkers50, "Roger Martin", thinkers50.com --- ### 認知科学者・UX研究者 URL: https://designthinking.studio/people/don-norman/ > 「UX（ユーザーエクスペリエンス）」という言葉を生み出した認知科学者。著書『デザインの心理学』は人間中心設計の古典であり、デザイン思考における共感の理論的基盤を与えた。 ドン・ノーマン（Don Norman、1935年生まれ）は、認知科学とデザインの交差点に生涯を捧げた研究者です。「UX（ユーザーエクスペリエンス）」という言葉を世界で初めて職名として使い、人間の認知特性に基づいたデザイン評価の体系を確立したことで知られています。 経歴 マサチューセッツ工科大学（MIT）で電子工学の学士号を取得後、ペンシルベニア大学で心理学の博士号を取得。ハーバード大学、カリフォルニア大学サンディエゴ校（UCSD）で教授を務め、認知科学科の創設に携わりました。 1993年にAppleに入職し、「ユーザーエクスペリエンス アーキテクト」という肩書きを自ら作り上げました。これが「UX」という言葉の起源とされており、それ以前はインターフェース設計に統一された名称がありませんでした。その後、Hewlett-Packardでの研究開発を経て、ニールセンとともに Nielsen Norman Group を設立。現在はカリフォルニア大学サンディエゴ校の名誉教授です。 『デザインの心理学』と人間中心設計 1988年に出版された The Design of Everyday Things（邦題：『誰のためのデザイン？』のち『デザインの心理学』）は、デザイン思考のすべての実践者が知るべき古典です。ドアノブ、冷蔵庫のコントロール、電話のキーパッドなど、日常的な製品の失敗事例を通じて、「なぜ人はデザインに失敗するのか」を認知科学の観点から解明しました。 この書籍が提示した中核概念が、デザイン思考の共感フェーズに深く影響を与えています。 アフォーダンス（Affordance） は、物体がユーザーに「こう使える」と知覚させる特性です。取っ手のついたドアは「引く」ことを、フラットなプレートのついたドアは「押す」ことをアフォードします。アフォーダンスを誤ると、ユーザーが正しく使えないのはユーザーの責任ではなく、デザインの失敗である、というのがノーマンの主張の核心です。 シグニファイア（Signifier） は、アフォーダンスをユーザーに知覚させるための視覚的・聴覚的なサインです。「PUSH」と書かれたラベル、上下矢印のエレベーターボタンなどがこれに当たります。 メンタルモデル は、ユーザーがシステムの動作について持つ内的なモデルです。ノーマンは「デザイナーのモデル（設計者の意図）とユーザーのメンタルモデルのギャップが、すべての使いにくさの原因」と指摘しました。このギャップを埋めることがデザインの仕事であり、共感フェーズでユーザーを理解する目的そのものです。 Nielsen Norman Group とUX評価 1998年、ウェブユーザビリティ研究の第一人者ヤコブ・ニールセンとともに Nielsen Norman Group（NN/g）を設立しました。NN/gはUXリサーチとユーザビリティ評価の世界的な権威として、企業のUX改善を支援し続けています。 NN/gが確立した「ユーザビリティヒューリスティクス評価」は、専門家がUIを評価するための10の原則です。ユーザーテストほどのコストをかけずに設計上の問題を発見できる手法として、テストフェーズでの活用が広まっています。 後期の著作と「デザインの倫理」 2013年に出版した The Design of Future Things では、自動化とAIが進む社会における機械とのコミュニケーション設計を論じています。また近年の講演では、「デザイン思考はスモールデザインに偏りすぎており、システムレベルの問題解決には不十分だ」という批判的な視点も示しています。 2023年のエッセイ「Design Thinking: A Useful Myth」では、デザイン思考の限界を指摘しつつも、人間中心のアプローチそのものの重要性は一貫して擁護しています。ノーマンの批判は、デザイン思考が「手法」に矮小化されることへの警鐘であり、その哲学的な深さをむしろ求めるものです。 実務者への影響 デザイン思考の実践において、ノーマンの貢献は具体的なツールや手法よりも、「失敗はユーザーではなくデザインの問題である」という思想の転換にあります。この思想が、共感フェーズでの観察とインタビューに方向性を与え、「ユーザーがなぜそう行動するか」を問い続ける姿勢の根拠になっています。 ペルソナの設計においても、ノーマンのアフォーダンス理論とメンタルモデルの概念は、「ユーザーが何を知覚し、何を期待するか」を記述するフレームとして機能します。 --- 参考文献 - Don Norman, The Design of Everyday Things, Basic Books, 1988（改訂版2013） - Don Norman, Emotional Design: Why We Love (or Hate) Everyday Things, Basic Books, 2004 - Don Norman & Bruce Tognazzini, "How Apple Is Giving Design a Bad Name", Fast Co Design, 2015 - Don Norman, "Design Thinking: A Useful Myth", Core77, 2010 ---