
薬事を呼ぶ頃には、もう遅い
SaMDの開発現場で、何度か同じ場面を見てきた。
技術はある。
エンジニアもいる。
アイデアも悪くない。
それなのに、前へ進まない。
会議では、
「次は何を作るか」
という話をしている。
ところが、しばらくすると、
「そもそも、これは何として扱うのか」
という話に戻ってくる。
そこで初めて、薬事の話が出てくる。
私は、この瞬間を何度も見てきた。
そして、ここまで来てから薬事を考え始めると、かなり苦しくなる。
「まず作る」の先にあるもの
スタートアップでは、「まず作ってみよう」という判断が必要になることがある。
作ってみなければ分からない。
使ってみなければ分からない。
ユーザーの反応を見ながら変えていく。
ソフトウェア開発では、ごく自然な考え方だと思う。
私自身も、開発の現場では何度もそうしてきた。
ただ、医療に関わるソフトウェアでは、少し事情が違う。
画面を変える。
機能を追加する。
出力を変える。
AIのモデルを更新する。
開発者からすれば、改善かもしれない。
しかし、その変更によって、製品が何をするものなのか、その意味まで変わることがある。
何を表示するのか。
誰に向けて表示するのか。
その情報を、ユーザーがどう判断に使うのか。
こうしたことは、単なる画面や機能の変更では済まない場合がある。
だから、作ってから考えればいいとは限らない。
もちろん、開発を始める段階ですべてを決めておく必要はない。
むしろ、最初から決めきれないことも多い。
ただ、何を作ろうとしているのか。
誰が使うのか。
何のために使うのか。
そこを曖昧にしたまま進むと、あとで戻る距離が長くなる。
知らないことは、質問できない
薬事が難しい理由を、「規制が複雑だから」と説明することはできる。
もちろん、それもある。
でも、私が現場で感じてきた難しさは、もう少し手前にある。
何を知らないのか、分からない。
例えば、
「この機能は医療機器に該当するのか」
と聞くことはできる。
でも、その前に、何を基準に考えればいいのかが分からなければ、その質問すら出てこない。
「この製品の使用目的は何ですか」
と聞かれて、
「医師を支援するためです」
と答える。
間違いではない。
けれど、その答えだけでは、何を支援するのか、どんな情報を提供するのか、その情報をどう使うのかが見えてこない。
話は、そこで止まってしまう。
知らないことは、質問できない。
だから、薬事の問題は、ある日突然発生するわけではない。
まだ問題になっていない段階で、
「これ、どう考えておけばいいんだろう」
と立ち止まれるかどうか。
私は、そこが大きいと思っている。
最後に呼ぶと、動かせなくなる
以前、開発がかなり進んだ段階で、薬事の相談を受けたことがある。
製品は、ほぼ形になっていた。
開発側には、
「ここまで作ったのだから、あとは申請できる形にすればいい」
という感覚があった。
でも、話を聞いていくと、そう簡単ではなかった。
製品の目的。
想定するユーザー。
表示する情報。
その情報を、ユーザーがどう使うのか。
それぞれについて、もう一度考える必要があった。
誰かが間違っていたわけではない。
開発者は、開発を進めていた。
事業側は、ユーザーに価値を届けようとしていた。
薬事側は、その製品をどう説明できるかを考えていた。
みんな、それぞれの仕事をしていた。
ただ、同じ製品について考え始めたタイミングが違っていた。
その時点で変更するとなると、コードだけの話では済まない。
試験も変わる。
文書も変わる。
説明の仕方も変わる。
場合によっては、製品そのものを見直すことになる。
もっと早い段階なら、小さな修正で済んだこともある。
後になるほど、動かさなければならないものが増えていく。
だから私は、薬事担当者を最後に呼ばない、というより、薬事を最後の仕事にしないと考えるようになった。
面倒な質問が、製品をつくる
薬事の話をすると、「開発を遅くするもの」というイメージを持たれることがある。
私自身、若い頃にはそう思っていた。
開発したい。
試したい。
リリースしたい。
そこに、
「この表現はどうですか」
「この変更はどう扱いますか」
「その根拠は何ですか」
と質問が入る。
正直、面倒だと思ったこともある。
でも、長く仕事をしていると、少し見え方が変わってきた。
薬事の人は、ただ開発を止めようとしているわけではない。
「これはどういう製品ですか」
「誰が、何のために使うのですか」
まだ決まっていないことを、問い直しているのかもしれない。
その問いに答えられないまま進んでいたことのほうが、問題だった。
薬事の質問は、製品ができあがった後に答えを整えるためだけにあるのではない。
製品が何であるかを、作る側自身が考えるためにもある。
つまずく前に
SaMDの開発では、技術だけでは決められないことがある。
この機能を入れるのか。
このユーザーを対象にするのか。
この価値を、どんな製品として届けるのか。
開発も、臨床も、品質も、事業も、薬事も関わる。
それぞれが別々に答えを出すのではなく、同じ製品について考えなければならない。
SaMDスタートアップが薬事でつまずく。
その理由を、「規制が難しいから」だけで終わらせたくない。
私が見てきたのは、薬事を後回しにした結果、最後になって苦しくなる会社だった。
もっと早く相談していれば、避けられたこともあったかもしれない。
もっと早く、何を作ろうとしているのかを考えていれば、違う進み方もできたかもしれない。
だから今は、SaMDのプロジェクトが始まると、薬事の開始時期を聞くのではなく、もっと手前で聞く。
「この製品は、誰のためのものですか」
その答えが、まだ決まっていないなら。
そこから一緒に考えればいい。
薬事は、製品ができあがってから呼ぶ仕事ではない。
製品を作り始めるときから、そこにいる。
よろしかったら、こちらもどうぞ。
マガジンの玄関はこちらです
よろしければ、ここから全体の流れをご覧ください。
全体の玄関はこちらです
ほかのテーマやシリーズへの入口を、ここにまとめています。