事例研究 NEW
ヘルスケアテクノロジーのデザイン思考実装 — 患者中心の医療イノベーション
電子カルテ、患者向けアプリ、AI診断支援ツール。ヘルスケアテクノロジーの開発にデザイン思考を実装した企業事例と、医療規制の制約下でプロトタイピングを回すための具体的な設計手法を解説する。
13分で読める
ヘルスケアテクノロジーの開発現場では、奇妙なパラドックスが繰り返される。医師向けの電子カルテシステムに何億円もかけて開発した機能が、現場でほとんど使われない。患者向けの服薬管理アプリが「使いやすい」という高評価を得ながら、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（無償公開ツールキット）
関連記事: ヘルスケア領域のデザイン思考 — 患者体験を再設計する / デザイン思考の共感フェーズ / プロトタイプフェーズの実践