仕様書からは生まれなかった ― 医療機器監視システム『MEGTAR』と歩んだ、問いをデザインする5年間
- MICHIHIKO MIKAMI
- 23 時間前
- 読了時間: 5分
先日、亀田医療大学大学院の大滝理事長の演習で「デザインプロセスにおけるAIの活用」というテーマで講義を行う機会をいただきました。
テーマは、医療機器監視システム「MEGTAR」がどのように生まれたのか。その開発プロセスを、デザイン思考のダブルダイヤモンドモデルを用いて振り返るというものでした。
講義を終え、学生や大滝理事長との対話を振り返る中で、私自身も改めて気づかされたことがあります。
それは、
私はMEGTARという製品をデザインしたかったのではない。
医療システムが生まれるプロセスそのものをデザインしたかったのではないか。
そんな思いです。
医療システムは「要求仕様書」から始まる
私は17年以上、医療情報システムの開発や導入に携わってきました。
経験上、医療機関へのシステム導入はほぼ決まった流れで進みます。
現場から要望を集める
要求仕様書を作成する
入札を行う
落札したベンダーが開発・導入する
この流れには理由があります。
公平性を保ち、コストを抑え、限られた予算の中で最適なシステムを導入するためです。
決して間違った仕組みではありません。
しかし、このプロセスには一つだけ大きな疑問がありました。
要求仕様書は、本当に「解くべき課題」を表現できているのだろうか。
「現場の要望」を聞けば良いわけではない
かつて医療情報システム開発では、「現場の要望をできるだけ仕様書へ反映する」ことが重視された時代がありました。
ところが、その結果として生まれたのは、機能が膨大に盛り込まれた巨大な要求仕様書です。
「あれも欲しい」「これも必要だ」という現場の声はどれも正しく、どれも重要でした。
しかし、それらをすべて盛り込んだ結果、開発費は膨らみ、応札できるベンダーが現れず、プロジェクト自体が成立しないという事例も少なからず発生しました。
その反省から、現在では医療コンサルタントの役割は「コスト削減」が中心となり、既存システムを比較し、できるだけ安く、確実に導入することが重視されるようになりました。
これは合理的な変化です。
しかし、その一方で、新しい価値を生み出す余地は小さくなりました。
つまり医療業界は、「現場の要望を全部かなえる」ことにも、「既存システムを最適に調達する」ことにも、それぞれ限界を経験してきたのです。
MEGTARは仕様書から生まれた製品ではない
MEGTARは、このどちらとも違う方法で生まれました。
2021年、コロナ禍の中で国立大牟田病院の医師や臨床工学技士、看護師の皆さんと対話を重ねることから始まりました。最初から「医療機器監視システムを作ろう」と決めていたわけではありません。
「呼吸ケアで本当に困っていることは何なのか。」
そこから対話が始まりました。
そして見えてきたのは、
防護服を着ると人工呼吸器のアラームが聞こえない。
という切実な現場の声でした。
開発を進める中で、通信規格がメーカーごとに異なり、セキュリティや接続の壁から直接データを出力させることが極めて困難であるという壁にぶつかりました。そこで直接データを取得する方式を断念し、発想を転換。『直接つながらないなら、カメラで画面をそのまま見ればいい。』という現在の非接触型のコンセプトが生まれました。
さらにOCRの認識率100％を目指していた時期もありました。
しかし現場から返ってきた言葉は、
「判断するのは人間です。完璧な数値より、前後の状況が分かる方が臨床では役立ちます。」
というものでした。
この一言で、私たちの設計思想は大きく変わりました。
AIが判断するシステムではなく、人が判断するための材料を提供するシステム。
これがMEGTARの原点です。
デザインしたのは「問い」だった
振り返ると、私たちは何度も問いを立て直してきました。
呼吸器を遠隔監視したいのか。
マルチベンダー環境を解決したいのか。
OCRの精度を上げたいのか。
アラームを通知したいのか。
どれも違いました。最後に残った問いは、
看護師は、なぜアラーム対応で迷うのか。
でした。
この問いに向き合った結果、「医療機器のドライブレコーダー」というコンセプトにたどり着きました。
アラームという「点」ではなく、前後の映像や波形、数値推移という「線」で状況を捉える。その文脈を示すことで、人間が判断できるようにする。
この発想は、最初の仕様書には書かれていませんでした。現場との対話を繰り返したからこそ見えてきた価値です。
本当にデザインすべきもの
今回の演習では、「従来の仕様書に基づく調達では、現場との試行錯誤が難しい」という話題でも議論になりました。
私は、入札制度や調達制度そのものを否定したいわけではありません。それらは公平性や説明責任を支える大切な仕組みです。
しかし、その前段階にある
「何を作るべきかを見つけるプロセス」
は、もっとデザインできるのではないでしょうか。
観察し、
対話し、
試作し、
失敗し、
また作る。
その繰り返しを経て初めて、本当に解くべき課題が見えてきます。
デザイン思考とは、ユーザーの要望をそのまま形にすることではなく、本当に解くべき問いを見つけるためのプロセスなのだと思います。
プロダクトよりも、プロセスを
AIはますます進化し、仕様書を書き、プログラムを生成し、システムを開発する能力を高めています。
だからこそ、人間に残される価値は「何を作るか」を考えることです。
私はMEGTARという製品を通して、現場と開発者が対話を続けながら、新しい価値を見つけていくプロセスそのものを実践してきました。
そして今も、そのプロセスは終わっていません。ソフトウェアは完成した瞬間に終わるものではなく、現場との対話を通じて育ち続けるものだからです。
医療DXは、新しい技術を導入することと結びつけて語られることも多いですが、それは本質ではありません。
現場と共に問いを立て、共に試し、共に学び続ける。
つまり、継続的な共創環境を作ること。そのプロセスをデザインすることこそが、本当のイノベーションで、医療DXにつながるのではないか。
亀田医療大学での講義を終えた今、私は改めてそう感じています。
私はこれからも共創を続けていきます。
コメント