デザイン思考（Tim Brown, HBR 2008）

高校生向けのやさしい解説

エジソンは電球を発明しただけでなく、発電や送電のしくみまで丸ごと作って初めて電球を「役に立つもの」にしました。デザイン思考とは、こんなふうに「人が本当に何を欲しがっているか」を直接よく観察し、技術的にできること・商売として成り立つことと結びつけて、試作（プロトタイプ）と作り直しをくり返しながら答えに近づいていく考え方です。デザイナーだけのものではなく、サービスや会社の戦略づくりにも使える「進め方」として紹介した記事です。

概要

Tim Brown (IDEO CEO) による本記事は、デザイン思考 (design thinking) を「デザイナーの感性と方法を用いて、人々のニーズと技術的に実現可能なものとを結び、それを顧客価値や市場機会へと変換する規律 (discipline)」と定義する。エジソンの「市場全体を構想する」発明スタイルを源流に位置づけ、デザイン思考を製品設計に閉じず、サービス・プロセス・戦略にまで適用範囲を拡げる人間中心のイノベーション・アプローチとして提示する。直接観察によるニーズの深い理解、発散と収束を往復する反復、早期のプロトタイピングを核とし、「インスピレーション／アイデア化／実装」という重なり合う空間を行き来する非線形のプロセスとして描く。

主要概念

人間中心 (human-centered) のイノベーション

“innovation is powered by a thorough understanding, through direct observation, of what people want and need in their lives”

イノベーションは抽象的な分析ではなく、人々の生活の直接観察から得られるニーズの理解によって駆動される。デザイン思考はこの観察を方法論の中心に据える。

3つの空間（線形でないプロセス）

デザイン思考は「インスピレーション (inspiration)・アイデア化 (ideation)・実装 (implementation)」という重なり合う空間を反復的に往復する。明確に区切られた段階ではなく、行き来する非線形のプロセスである。

プロトタイピングと試行錯誤

エジソンの「99%の発汗」を引きつつ、仮説の検証ではなく反復のたびに新しいことを学ぶための早期プロトタイピングを重視する。失敗を早く重ねることが学習を加速する。

ニーズ・実現可能性・存続可能性の交差

人々の望み（desirability）・技術的実現可能性（feasibility）・事業としての存続可能性（viability）が交わる点に解を求める。

創造（creation-space）との関連

「観察 → 発散 → プロトタイプ → 収束」を反復するデザイン思考のプロセスは、創造を一回的なひらめきではなく、場の中での試行・撹乱・選択の循環として捉える見方と重なる。発散と収束の往復は、創造モデルの波（多様性の生成）と束（収斂・固定化）の局面の交替に対応づけて読むことができる。ただし本記事はビジネス文脈の実務方法論であり、創造の存在論的記述ではない点に留意する。

書誌情報

• 著者: Tim Brown（IDEO）
• 年: 2008
• 出典: Harvard Business Review, June 2008（Reprint R0806E）
• access_status: raw-confirmed
• 全文: readings.design (PDF)

ソース参照（GitHub・検証用）

• cs 原典ファイル: knowledge/raw/D22_brown_2008_design-thinking.pdf（manifest_id: D22-S06）
• cs 精読ノート: knowledge/source-notes/D22/D22-S06_brown-2008.md
• この wiki ページ（pd）: wiki/sources/D22_brown_2008_design-thinking.md
• 参照先（原典 DOI / オープンアクセス）: 下記「書誌情報」を参照

出典メモ

• 本ページは cs ローカル raw PDF（knowledge/raw/D22_brown_2008_design-thinking.pdf）を pdftotext で抽出した本文を一次入力として生成した。
• 関連: pd wiki の概念ページ「デザイン思考（PD）」は PD 独自の3視点で design thinking を再整理しており、本記事（Brown 原典）はその一次文献にあたる。
• 生成: 2026-06-14, Claude Opus 4.8（pd#111 Step 3b バッチ2）。cs 側 source-note 生成後に wiki-cross-check.mjs で矛盾検査を再実行する。