SaMDプロジェクトは、技術では失敗しない。意思決定で失敗する

PMDA相談で、私が一番驚いたこと

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

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

AIの性能。

アルゴリズム。

評価結果。

ソフトウェアの安全性。

そうした技術を説明し、理解してもらう場だと考えていた。

しかし、実際に問われたのは別のことだった。

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

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

「問題が起きたら、誰が責任を持つのですか。」

同じような質問が、何度も繰り返された。

私は、その帰り道でようやく気づいた。

PMDAが見ていたのは、AIではない。

組織の意思決定だった。

プロジェクトには、正しい人しかいない

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

私は、その場にいたことが何度もある。

でも、本当に薬事が止めた案件は、ほとんど記憶にない。

開発には、開発の正しさがある。

「性能を上げたい。」

営業には、営業の正しさがある。

「早く現場へ届けたい。」

品質保証には、品質保証の正しさがある。

「再現できないものは世に出せない。」

薬事には、薬事の正しさがある。

「社会へ出す以上、説明できなければならない。」

誰も間違っていない。

だから難しい。

プロジェクトは、「悪い人」がいて止まるのではない。

正しい人同士が、それぞれ違う景色を見ていることで止まる。

私は、この構図を何度も見てきた。

「正しさ」は、1つではない

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

開発者は言った。

「診断支援です。」

営業は言った。

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

医師は言った。

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

その場には、間違った人はいなかった。

それぞれ、自分の立場から正しいことを言っていた。

でも、その「正しさ」は一致していなかった。

私は、その会議で初めて理解した。

使用目的とは文章ではない。

それぞれが持っている「正しさ」を、1つに統合する作業なのだ。

たった1行が変わるだけで、必要なエビデンスが変わる。

評価計画が変わる。

営業資料が変わる。

投資家への説明も変わる。

使用目的を書いていたのではない。

会社として、何を正しいと定義するのかを書いていたのである。

一番危ない現場は、条文を守る現場だった

少し誤解されるかもしれない。

私が一番ヒヤッとした現場は、規制を軽視する現場ではなかった。

規制だけを見ている現場だった。

「決まりですから。」

その言葉が出た瞬間、私は危険信号だと思うようになった。

規制には理由がある。

事故があり、失敗があり、その積み重ねが条文になっている。

理由を理解せずに条文だけを適用すると、新しい技術には対応できない。

SaMDは、その連続だった。

だから私は、条文を覚えることよりも、「なぜ、その条文が存在するのか」を考える時間の方が大切だと思っている。

「軽微変更」が怖い理由

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

ボタンの位置を少し変えた。

表示色を変えた。

AIモデルを更新した。

それぞれは小さな変更だ。

でも、半年後に振り返ると、製品は最初とは別物になっていることがある。

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

そのとき思った。

怖いのは変更ではない。

誰も変更だと思わなくなることだ。

開発はUIを変える。

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

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

薬事は警告文を見直す。

全員が別々に改善している。

でも、その変化を統合して見ている人がいない。

だからQMSは必要になる。

私は今、QMSを品質の仕組みというより、「組織の記憶」と「意思決定の履歴」を残す仕組みだと考えている。

技術より先に設計するもの

もし今、新しいSaMDプロジェクトを始めるなら、私が最初に設計するのはアーキテクチャではない。

意思決定である。

まず決める。

誰が何を決めるのか。

その判断は、どんな根拠で行うのか。

意見が割れたら、誰が最後に決めるのか。

次に設計する。

必要な情報が、必要な人へ届く仕組み。

そして最後に決める。

いつまでに判断するのか。

判断できなかったら、どうするのか。

リスクは誰が引き受けるのか。

私は、この3つが曖昧なプロジェクトで、うまくいった例をほとんど知らない。

PMDAが見ていたのは、組織だった

PMDA相談を経験するたびに、思うことがある。

あの場は、技術を審査する場ではない。

会社が、自分たちの意思決定を説明できるかを見る場だ。

誰が判断したのか。

なぜ、その判断をしたのか。

同じ状況になったら、次も同じ判断ができるのか。

そこに一本の筋が通っているか。

PMDAが確認していたのは、そのことだった。

そして振り返ると、私が関わったプロジェクトも同じだった。

問題になったのは、AIではない。

アルゴリズムでもない。

仕様書でもない。

「この会社として、何を正しいと考えるのか。」

その合意が曖昧だったとき、プロジェクトは必ず揺れた。

統合思考とは、正解を選ぶことではない

SaMDの仕事を通して、私が一番大きく変わったことがある。

以前は、正しい答えを探していた。

でも今は違う。

開発には、開発の正しさがある。

営業には、営業の正しさがある。

品質保証には、品質保証の正しさがある。

薬事には、薬事の正しさがある。

そのどれかを選ぶことが、意思決定ではない。

異なる正しさを持ったまま、1つの判断へ統合すること。

それが意思決定なのだと思う。

だから私は、SaMDプロジェクトは技術では失敗しないと考えている。

失敗するのは、異なる「正しさ」を統合できなかったときだ。

ソフトウェアは、人が設計する。

そして、人の判断は組織が設計する。

SaMDで本当に設計すべきものは、ソフトウェアだけではない。

意思決定そのものなのである。