SaMDプロジェクトで、最後に問われるのは意思決定だった

PMDA相談へ行く前、私は少し勘違いをしていた。

あの場は、自分たちの技術を説明する場所だと思っていた。

AIの性能。

アルゴリズム。

評価結果。

ソフトウェアの安全性。

そうしたものを説明して、理解してもらう。

それが中心だと思っていた。

でも、実際に問われたのは、少し違うところだった。

「その判断は、誰がしましたか」

「変更は、誰が承認しますか」

「問題が起きた場合、どのように対応しますか」

帰り道、私はその質問を何度も思い返していた。

技術の説明だけでは、足りない。

製品を作ることと、その製品について組織として判断することは、別の仕事なのかもしれない。

1行を決めるまで

以前、使用目的を決める会議に参加した。

開発者が言った。

「診断支援です」

営業は言った。

「でも、お客様には診断に役立つと言いたい」

医師は言った。

「現場では、判断材料として使います」

誰かが間違っているわけではなかった。

でも、このままでは、1つの製品について3つの違う説明ができてしまう。

そのとき、使用目的というものを少し違って見るようになった。

使用目的は、文章を1行書けば終わるものではない。

その1行の後ろには、誰が使うのか、何のために使うのか、どこまでを製品の役割とするのか、どこからを人が判断するのか、という決定がある。

1行が変われば、評価も変わる。

説明も変わる。

必要な記録も変わる。

だから、使用目的を書いているのではない。

会社として、何をしようとしているのかを決めているのだと思う。

誰もが正しくても、決まらない

SaMDの現場では、「薬事が止めた」という言葉を聞くことがある。

でも、少し違うように思うことがあった。

開発は、性能を上げたい。

営業は、早く現場へ届けたい。

品質保証は、再現できないものは出せないと考える。

薬事は、社会へ出す以上、説明できなければならないと考える。

それぞれに理由がある。

問題は、誰が正しいかではない。

その意見を受けて、会社として何を決めるのか。

そこが曖昧なままでは、会議を重ねても前へ進まない。

意見が割れたとき、誰が判断するのか。

判断に必要な情報は、その人に届いているのか。

何を根拠に決めるのか。

そして、その判断を誰が引き受けるのか。

技術の設計と同じように、意思決定にも設計が必要なのだと思う。

「決まりですから」で終わらせない

私が仕事をしていて、一番怖いと思ったのは、規制を軽視する現場ではなかった。

むしろ、

「決まりですから」

という言葉だけで話が終わってしまう現場だった。

規制には理由がある。

過去の事故や問題。

そこから得られた経験。

それらが、今の要求につながっている。

だから、守る必要がある。

でも、条文だけを見ていると、「なぜ、これが必要なのか」が見えなくなることがある。

私は要求を見るとき、

「これは、何を守ろうとしているのだろう」

と考えるようになった。

その問いがなければ、守ることそのものが目的になってしまう。

規制の要求を理解することと、製品について判断すること。

この2つは、切り離せない。

変更を、全体として見る

現場では、「軽微な変更です」という言葉を聞くことがある。

ボタンの位置を変える。

表示を変える。

画面の文言を変える。

AIモデルを更新する。

1つずつなら、小さな変更に見える。

私も、そんなプロジェクトを経験した。

開発はUIを変える。

営業は説明資料を変える。

品質保証は手順を変える。

薬事は表示や警告文を確認する。

それぞれの変更には、それぞれの理由がある。

問題は、変更そのものではなかった。

その変更を、誰かが全体として見ているかどうかだった。

誰もが自分の担当範囲では正しく動いている。

それでも、全体を見る人がいなければ、製品は少しずつ変わっていく。

その経験から、QMSを見る目も変わった。

QMSは、品質を守る仕組みだけではない。

組織が何を決めたのか。

なぜ、そう決めたのか。

その判断を、あとからたどれるようにする仕組みでもある。

技術を、医療へつなぐ

PMDA相談を経験して、私自身の見方も変わった。

以前は、技術をきちんと説明できればいいと思っていた。

今は、それだけでは足りないと思っている。

なぜ、この使用目的なのか。

なぜ、この評価方法なのか。

なぜ、このリスクをこう考えたのか。

誰が、どんな根拠で判断したのか。

そして、その判断を組織として説明できるのか。

帰り道で考えていたのは、AIの性能のことではなかった。

「この会社は、どうやって判断しているのだろう」

ということだった。

SaMDでは、技術そのものが問題になることもある。

でも、技術が十分にあっても、組織として判断できなければ前へ進めない。

全員が同じ景色を見る必要はない。

開発には開発の景色がある。

薬事には薬事の景色がある。

品質には品質の景色がある。

臨床には臨床の景色がある。

違う景色を持ったまま、「では、この製品をどうするのか」を決める。

そのために、話す。

記録する。

必要なら、立ち止まる。

そして、決める。

人が作った技術を、人が判断して、医療へつないでいく。

その判断を、誰が、どう支えるのか。

そこまで設計できて、ようやくプロジェクトは前へ進む。

よろしかったら、こちらもどうぞ。

マガジンの玄関はこちらです

よろしければ、ここから全体の流れをご覧ください。

全体の玄関はこちらです

ほかのテーマやシリーズへの入口を、ここにまとめています。