AI時代のデザイン思考:ボトルネックから増幅装置へ
Blog/
||||||

AI時代のデザイン思考:ボトルネックから増幅装置へ

ある地方病院の朝会で、ベテラン主治医からこう問われました。「デザイン思考はもう時代遅れではないか?」医療技術の現場では、年に何度も耳にする問いです。私たちの答えは、デザイン思考は失敗したのではなく、ただ走るのが遅すぎただけ、というものです。AIはプロトタイプ構築とフィードバック統合を数か月から数日へ圧縮します。本稿では単一専門科パイロットから複数科対応Schema Composerへ転換した内部事例を通じて、AIはデザイン思考の代替ではなく、デザイン思考が二十年待ち続けた道具であることを示します。

ある地方病院の朝会で、ベテラン主治医からこう問われました。「デザイン思考はもう時代遅れではないですか?」

まずは前提として簡単な解説をします。この用語は必ずしも誰もが知っているわけではないからです。デザイン思考とは、1990年代にIDEOおよび周辺のデザインコンサルティング会社によって広められた五段階のループです。empathize(ユーザー理解)、define(問題定義)、ideate(解決策の発散)、prototype(粗くても触れるものを作る)、test(実ユーザーに当てる)の五つから成ります。前提はシンプルです。作り始める前に何の問題を解いているのかを見極め、実ユーザーに粗版を触らせ、その上で問題定義に立ち戻る。当たり前のように聞こえますが、実務上は大半のチームが一周すら最後まで回しきれません

過去十年ほどの間に、この方法論は時代遅れになったという印象が形成されました。よく聞こえてくる文脈はこうです。

  • 2010年代の流行であり、世の中はリーンスタートアップやAIの直接生成へ移った
  • 付箋だらけのワークショップ産業に堕し、後続の実装が伴わない
  • 大企業では儀式化し、一週間スプリントで終わって反復しない
  • LLMが解を直接合成できるなら、empathizeやユーザー調査など不要ではないか

私たちの読みは違います。過去十年、デザイン思考が時代遅れに見えた原因は論理ではなく速度でした。AIはループの足を引っ張ってきた部分、つまりプロトタイプ構築とフィードバック統合を、数か月から数日へ圧縮します。完全なループが、初めてend-to-endで回せるようになったのです。

本稿では、私たちの最近の内部転換、すなわち単一専門科向けの外来補助ツールから、どの専門科でもセルフサービスで使える複数科対応Schema Composerへの転換を取り上げます。この経緯はそのまま、デザイン思考の一周にきれいに対応していました。AIがデザイン思考の代替ではなく、二十年待ち続けた道具であることを示す具体例として用います。


なぜ「時代遅れ」と思われたのか

デザイン思考の中核五段階、empathize、define、ideate、prototype、testは、1990年代にIDEOおよび周辺のデザインコンサルティング会社によって広められました。ティム・ブラウンの2008年『Harvard Business Review』マニフェストが、これを主流の方法論へ押し上げました。

真のボトルネックは論理ではなく、時間でした。

empathizeからtestを経てredefineへ戻る一周を、従来のプロダクトチームが回すには通常三か月から半年かかりました。

  • empathize:5〜15人のユーザーインタビューを設定、文字起こし、パターン抽出
  • define / ideate:関係者全員を多日のワークショップに巻き込み、付箋を山と生み出す
  • prototype:デザイナーが画面モックを作り、エンジニアが動く版を組む
  • test:もう一度ユーザーセッションを回し、フィードバックを集める

各ステップが遅い。一周してユーザーの反応を見た頃には、それを反映する時間も予算も残っていません。

その結果、過去十年で次の三つが起きました。

  • empathizeとdefineが儀式化し、ワークショップ一回で済ませる
  • prototypeとtestはデザイン会社へ外注され、見栄えはするが量産には遠い
  • 方法論全体が「二日スプリント」に押し込まれ、名ばかりのデザイン思考になり、最も意味のある所作、つまり本当に方向転換することを欠いた

2020年代初頭にはコンセンサスが移りました。デザイン思考は「古いやり方」、新しいやり方はリーンスタートアップ、グロースハック、データドリブン・プロダクトだ、と。

「時代遅れ」という評価は業界の世間話だけではありませんでした。レベッカ・アッカーマンの2023年『MIT Technology Review』回顧記事は、その論を集約しました。実装を伴わないアイデア、イノベーション・シアター、コミュニティ専門知識を欠いたエンパシー、というものです。NYUのナターシャ・イスカンダー教授は五年早く2018年の『HBR』記事で、「本質的に保守的」とより鋭く名指ししていました。両者の批判はいずれも、デザイン思考が社会・政策的問題、すなわち学校給食、貧困対策、行政サービスといった、長期にわたる政治的・制度的取り組みを要する領域でつまずいた点を突いています。

私たちはこの批判の系譜と争うつもりはありません。妥当な指摘です。本稿はもっと狭い問いに答えます。なぜデザイン思考は、プロダクト開発の現場で動かなくなったのか。


AIが実際に変えたこと

AIが議題に登場した当初、最も声高だった物語はこうでした。「もうユーザー調査は不要、LLMに直接解を合成させればよい」。この物語はデザイン思考と真っ向からぶつかります。だからこそ「時代遅れか」と問われるのです。

プロダクトチームの内側で見えてくるのは、むしろ正反対です。

LLMはempathizeを加速しません。加速するのはプロトタイプ構築とフィードバック処理です。

段階AI以前AI以後
仕様書作成1〜2週間(複数回の関係者レビュー)1〜2日(複数AIレビューを並走)
UIモック1週間(デザイナー+ツール)半日(LLM+Figmaプラグイン)
動くプロトタイプ2〜4週間(フロント+バックエンド実装)3〜5日(mocked API+AI生成のUIロジック)
フィードバック統合1週間(手作業のクラスタリング)半日(LLMによるテーマ抽出とクラスタリング)
規制/法務文書ドラフト2〜4週間(弁護士+社内レビュー)3〜5日(AIがドラフトし弁護士が確認)

合算すると、かつて12〜16週間(あるいはそれ以上)かかった一周のデザイン思考ループが、いまや2〜3週間(あるいはそれ以下)で回ります。

補足として、IDEO自身も進路はこの方向だと認めています。2024年以降、彼らはオンライン講座Bring AI to the Design Thinking Processを提供しており、五段階それぞれにAI加速をどう適用するかを教えています。これは上の表とほぼ一対一で対応します。後ほどこのシグナルに戻ります。

ボトルネックは移動しました。かつて遅かった「ユーザーが実際に触れるものを作る」は速くなりました。いま遅いのは「何を作るかを決める」です。

言い換えれば、empathize / defineの相対的な重要度は下がっていません。むしろ上がっています。


本当のシフト

LLMは増幅装置です。問題の枠組みを誤れば、誰も欲しがらないものを前代未聞の効率で生み出します。正しく枠組めば、正しい方向を十倍に増幅します。

つまりデザイン思考の最も古典的な所作、「まず『なぜ』を問う」は、AI時代でも依然として有効であるどころか、ガードレールそのものです。

かつてempathizeが遅かった頃、チームはそこを飛ばす誘惑に駆られました。今はprototypeが速いので、empathizeを飛ばす危険性は減るどころか増しています。間違った道を、誰も気づかぬまま猛スピードで突っ走るからです。

私たちの社内ルールはシンプルです。仕様サインオフがなければ作業に入らない。AIが速くなるほど、サインオフ工程の重要性は増します。私たちはあらゆる仕様に対して三つのAIレビュアー(Codex、Gemini、ChatGPT)を並走させます。これらは契約違反、IDOR、PHI漏れ、互換性問題といった、伝統的なデザイン思考ワークショップでは決して扱われない論点を拾います。AI時代において、こうした懸念は「ユーザーは何を欲しがるか」と並んでempathize / defineの一部に組み込まれるべきで、後付けではいけません。

「仕様ファースト」は反デザイン思考ではありません。AI時代向けに更新されたデザイン思考です。


事例:SOAP.S溢れから複数科対応Composerへ

経緯は市場調査やフォーカスグループから始まったのではありません。あるベテラン医師との対話から始まりました。彼は、自院チームが見ている現象を語りました。患者copilotツールが受診前に主訴を入力できる仕様だが、LLMが生成した文章がSOAPの主観セクションを毎回溢れさせる。臨床推論に充てるはずだった医師の時間が、AIが書いた文章の整理に使われてしまっている、と。

最初の反射は「圧縮レイヤーを足せばよい」でした。患者の入力を医師が使える形に縮める、という発想です。

チームはそれをしませんでした。問題に腰を据えて向き合うと、足りないのは圧縮層ではなく、価値の流れ全体を組み替える必要があると見えてきました。そこでチームはデザイン思考の五段階に沿って歩き直しました。対話から方向転換の意思決定まで、およそ二週間。AI以前なら同じ作業に半年から九か月かかったはずです。

Empathize

チームには整形外科の現役執刀医を兼ねる創業者がいます。彼の視点から、最も古典的なデザイン思考の問いはこうでした。

「外来の一回一回で、私は患者の漠然とした訴えを、SOAP.Sの中身にどうやって翻訳しているのか?」

答えは「全部書き留める」ではありません。「四つのフィールドと、その背後の推論に圧縮する」です。患側、重症度、外傷性か変性か、罹病期間。この四つが埋まれば、鑑別診断の仮説ツリーは自ずと立ち上がります。

別の言い方をすれば、医師が書くSOAP.Sは患者の語りの逐語録ではありません。医師がその語りを構造的に解釈した結果です。SOAP.Sの溢れは、患者が書きすぎるからではなく、AIの出力をそのままカルテに流し込み、医師が見直す前に圧縮しないツール設計に原因があります。

(「AIがドラフトし、医師が確定する」という設計則の深掘りは、iRehab Doctor AI:Draft-Only原則で別途書いています。AIによる翻訳と医師による確認は、二つの行為であって決して一つに統合してはいけません。)

Define

私たちは問題を再定義しました。

「患者が診察室に入る前の二分間に、過去二週間分の患者入力(VAS推移、創部写真、運動ログ、PROMスコア)を、医師が五秒で読める専門科特化のサマリへ圧縮する」

キーワードは「圧縮」と「五秒で読める」です。従来の「逐語録をEMRへ流し込む」発想を残したままなら、AIの精度をいくら上げてもSOAP.Sの溢れは止まりません。

このdefine工程は、意図的にスコープを絞り込みました。整形外科のみ、このスライスのみ、それ以外には触れない。

Ideate

これまでの解はどれも、行動が診察室の中で起きる前提でした。医師が座り、患者が向かいに居て、EMRが開いた状態で、聴きながら入力する、という構図です。

私たちのideateの肝は、この翻訳工程を診察室の外に丸ごと移すことでした。患者は受診とは別の時点(自宅で、スマホ越しに、過去二週間にわたって)に入力します。AIは受診の二分前に圧縮します。医師は入室前の五秒で読みます。

これはツールのアップグレードではなく、ワークフローの移設です。(Briefに供給される患者側の入力フローは、別記事30秒の毎日チェックインで扱った仕組みです。一日30秒でも、二週間積み上げれば、診察前サマリの素材になります。)

Prototype

数日の仕様書作成、複数AIレビュー、プロトタイプ実装を経て、iRehab Brief Wave 1をリリースしました。整形外科限定です。

これは以前なら4〜8週間、しばしばそれ以上かかった作業です。AIは仕様書の作成、UIモック、バックエンドAPIの足場、データモデルレビュー、規制文書ドラフトを丸ごと圧縮しました。

Test

Briefが院内パイロットに入ると、想定外のことが二つ起きました。

第一に、ある拠点で物理的なロールアウトが止められました。コードの問題ではありません。院の規定で、QRコード入りのポスターはすべて広報部の承認を要し、外科部長は「また一人、医者がFacebookページを布教しに来た」と捉えたのです。コードレビューがカバーする範囲と、院内ガバナンスがカバーする範囲は、まったく別の世界だと判明しました。日本の病院文化でも、診療部、医療安全、広報、感染対策、IT、法務、それぞれの稟議を通さねばならず、「コードが動く」は「現場で使える」を意味しません。

第二に、FBの反応が予想を超えて熱く返ってきました。精神科、神経内科、ウロギネ、産科の医師たちから直接メッセージが届き、皆が同じ問いを投げかけました。「うちの専門科向けにも作れますか?」

二系統のフィードバックは一つのメッセージに収束しました。当初定義した問題は、もっと大きな問題の一スライスに過ぎなかった。

Redefine

どの専門科にも翻訳器が必要ですが、各科が翻訳先とする四つのフィールドはまったく異なります。

  • 精神科は睡眠、気分の変動、服薬遵守
  • ウロギネは排尿日誌、骨盤底筋運動の遂行度
  • 神経内科は症状の変動、副作用、発作頻度
  • 産科は妊娠関連の訴え、胎動、妊娠週数別のアラート

アーキテクチャは同じ。スキーマは四種類どころか各科ごとにまったく違う。

整形外科版Briefを押し続けていれば、おそらく整形外科の少数ユーザーへ滑らかにロールアウトできていたでしょう。同時に、本当の洞察を見逃していました。このツールの価値は「整形外科医の時間を節約する」ではない。「あらゆる専門医が、自分専用の翻訳ルールを数分で定義できる」ことです。

私たちは整形外科Briefのロールアウトを停止しました。新しい仕様を起こしました。複数科対応のSchema Composerであり、専門医本人が自分の四フィールドを定義し、attestationに署名し、自分のspecialty packをリリースできるものです。

このredefineの判断こそが、デザイン思考第五段階の本当の成果物です。「プロトタイプは動いた」ではなく「最初の問題定義の枠が小さすぎた」。


二つのAI増幅器

この二週間を振り返ると、AIは特定の二か所で作業を加速しました。

第一の増幅器:spec → prototypeまでの時間。

サインオフに耐える仕様書を書き、動くプロトタイプを作り、社内レビューを回す、これらは以前なら4〜8週間かかりました。私たちは7〜10日に圧縮しています。LLMが仕様の下書きを作り、三つのAIレビュアーが並走し、人間のアーキテクトが調停します。プロトタイプはmocked APIとAI生成のUIスタブから始まり、エンジニアが業務ロジックを埋めていきます。

第二の増幅器:feedback → redefineまでの時間。

「パイロット稼働」から「方向転換すべき」へたどり着くには、かつて3〜6か月の利用データ、複数回のインタビュー、統合作業を要しました。私たちのループは現在こうです。FBが一週間、DMが三日、社内議論が一日。外部シグナルから「最初の枠は部分問題だった」と捉え直す新仕様まで、五日です。

二つの増幅器を合わせると、デザイン思考の一周(思考、仕様、プロトタイプ、フィードバック、再定義)は、6〜9か月から約2週間に圧縮されます。これはデザイン思考が置き換えられたのではありません。デザイン思考が初めてend-to-endで回ったのです。


デザイン思考の本質

デザイン思考はワークショップではありません。付箋でも、エンパシーマップでもありません。

その核心は二つの「意志」です。

  • 自分の最初の答えが間違っていたと認める意志。
  • 速く試し、正しい答えを見つける意志。

過去十年、この二つはどちらも貫きにくいものでした。第一の意志はサンクコストに塞がれました(「三か月かけた仕様を、間違いだと認められるか?」)。第二の意志は時間に塞がれました(「もう一周回すのに半年」)。

AIが第二の問題を変えました。速い反復がついに安くなりました。それが第一の意志を、初めて意味あるものに変えます。間違いを認めることが、即座に別の手を試せることを意味するようになったからです。

だからこそ私たちのチームは、仕様ファースト、なぜを問うこと、「これでどんな扉が開いたか?」を社内規律として扱います。AIは単なる道具です。その上に乗る方法論こそが本体であり、その方法論には名前があります。それがデザイン思考です。


私たちは独りではない

一チームの事例だけでは、ただの逸話に聞こえるかもしれません。方法論の本家は、もっと直接的なシグナルを発しています。

2024年以降、IDEOはオンライン講座Bring AI to the Design Thinking Processを、その名のとおり率直なタイトルで提供しています。カリキュラムは五段階それぞれにおけるAI加速を教えます。

  • Inspiration / Research:AIで創造的インプットを拡張する
  • Synthesis:「調査と統合を加速し、洞察に早く到達する」
  • Brainstorming:より速く発散し、より多くの選択肢を探る
  • Prototyping:構想を素早く形にする
  • Responsible use:AIの限界と倫理を理解する

本稿で先ほど示した加速表に重ねれば、五段階はほぼ一対一で並びます。

デザイン思考を世に広めた当事者たちは、AIをライバル扱いしていません。彼らは自らコミュニティを次世代版へ手引きしているのです。第五段階に注目してください。responsible use、すなわち「AIが速くなるほど、まず『なぜ』を問うことがガードレールになる」という、私たち自身の主張と響き合っています。

デザイン思考は時代遅れではありません。創設者たち自身が、それをAIに手作業で繋ぎ込んでいるのです。


おわりに

ベテラン主治医の問いに戻りましょう。「デザイン思考はもう時代遅れではないか?」

私たちの答えは「いいえ」です。過去十年、時代遅れに見えたのは反復ループが長すぎたからです。AIは敵ではありません。AIこそが、デザイン思考が二十年待ち続けた道具です。

iRehab Briefが単一専門科パイロットから複数科対応Composerへ転じた二週間は、私たちのチームが、デザイン思考が実際にend-to-endで回るのを初めて目にした瞬間でした。これが最後にはならないと考えています。


さらに読む

De Novoブログから

  • iRehab Doctor AI:Draft-Only原則 — Briefの設計則を扱う姉妹篇。AIが翻訳し、医師が確定する。この二行為を一つに統合してはいけない。
  • 30秒の毎日チェックイン — Briefに供給される患者側入力フロー。一日30秒、二週間の積み上げが診察前サマリの素材になる。
  • Recovery Loop — iRehabの諸機能が動く土台となる、より広い臨床方法論。