経験は、求人票には載らない

Zoomの画面の向こうで、人事担当者が少し黙った。

カーソルだけが、小さく点滅していた。

「ソフトウェア開発と薬事の両方が分かる人は、かなり少ないです」

そのあと、採用市場の話になった。

大きな会社の名前が出た。

条件の話が出た。

スタートアップという言葉のあとに、短い間があった。

探して見つかるなら、もう誰かが採っている。

そんな話に聞こえた。

「では、開発チームの中から抜擢して、薬事を担ってもらうのはどうでしょう」

誰かが言った。

私は、すぐには返事をしなかった。

正解とは言い切れない。

でも、その場では、ほかの道があまり見えなかった。

SaMDのプロフェッショナルを育てたい。

その言葉は、これまで何度も聞いてきた。

私も、そう思っていた。

ただ、育つ前に人が動いていく。

ようやく任せられるようになった人が異動する。

仕事のおもしろさが分かり始めたころに退職する。

新しい人が入る。

また最初から話す。

製品のこと。

規制のこと。

過去に悩んだ判断のこと。

そして、なぜそうしたのかという理由。

人はいる。

ただ、経験が積み上がらない。

私の物差しでは、足りなかった

私は、最初から薬事をやりたかったわけではない。

役に立つソフトウェアを作りたかった。

それだけだった。

ハードウェア寄りの開発も経験してきた。

仕様を固める。

変更を減らす。

一度決めたものを守る。

そうやって品質を考えていた。

ソフトウェアは違った。

リリースしてからも終わらない。

直す。

変える。

見直す。

使われ方を見ながら、また手を入れる。

ある変更管理の会議で、私は言った。

「これくらいなら、軽微な変更ですよね」

会議室が静かになった。

資料をめくる音だけが残った。

その沈黙で、何かを見落としていると分かった。

影響範囲。

リスク。

承認されている内容。

ユーザーへの影響。

臨床現場での使われ方。

私が見ていたのは、コードの差分だった。

そこにいた人たちは、その先を見ていた。

私の経験が間違っていたわけではない。

ただ、測るものが違っていた。

その物差しを作り直すのに、思っていたより時間がかかった。

「なぜ、やり直したんですか」

若手メンバーに聞かれたことがある。

「なぜ、このタイミングでリスク評価をやり直したんですか」

私は、すぐには答えられなかった。

手順書にそう書いてあったからではない。

誰かに言われたからでもない。

「ここは危ない」

自分の中では、そう感じていた。

前にも似た変更で議論になった。

小さく見えた修正が、使われ方に影響した。

あとから説明しようとして、記録が足りずに困った。

そういう経験が、いくつも重なっていた。

それがいつの間にか、自分の判断になっていた。

でも、感覚のままでは、人には渡せない。

そこで私は、判断した理由や規制対応の経緯を資料にまとめた。

これなら、次の人の役に立つと思った。

数か月後。

別の会議で、その話が出た。

「それ、どこかにありますか」

画面共有で、共有フォルダを開いた。

フォルダの中に、またフォルダがあった。

日付の古いファイルが並んでいる。

作ったはずの資料が、なかなか出てこない。

ようやく見つかったとき、誰かが言った。

「あ、ここにあったんですね」

そのとき、少し考えた。

残しただけでは、残らない。

経験は、次の人の判断に変わって初めて残る

人が辞める。

異動する。

新しい人が入る。

それ自体は、止められない。

問題は、その人が持っていた判断の経験まで、一緒に出ていってしまうことだ。

なぜ、この変更を慎重に見たのか。

なぜ、あのときは見送ったのか。

なぜ、ここだけは確認を増やしたのか。

結果なら、記録に残せる。

でも、「なぜ、そう考えたのか」は、意識して残さなければ消えてしまう。

だから私は、正式な決定だけでなく、そのときの迷いも残すようになった。

「ここは少し気になる」

「今回は見送る」

「次の変更では確認する」

そんな短い言葉でもいい。

あとから誰かが読んで、

「なるほど。だから、ここを見ていたのか」

と分かればいい。

その人が、そこから自分で考えればいい。

経験をそのまま渡すことはできない。

でも、考え始める場所なら渡せる。

開発したい人のままでいい

「開発者に薬事も全部覚えてもらおう」

という話ではない。

ほとんどの人は、ソフトウェアを作りたくて会社に来ている。

コードを書きたい人がいる。

AIをやりたい人がいる。

プロダクトをよくしたい人がいる。

その人たちに、

「薬事も分かってください」

「QMSも理解してください」

と仕事を足していけば、人材が育つわけではない。

むしろ、開発する時間を奪ってしまうかもしれない。

だから、開発の仕事の中で触れてもらう。

薬事の人と仕様を見る。

品質の人と変更の影響を考える。

臨床の人に、なぜそこが気になるのかを聞く。

そして、自分の言葉で考えてみる。

最初から正しい必要はない。

間違えたら、また話せばいい。

その繰り返しの中で、

「前はここを見落とした」

「今回は、ここまで確認しておこう」

という自分の物差しができていく。

私も、最初から分かっていたわけではない。

開発で迷った。

薬事で止まった。

品質の視点から見直した。

臨床の人に聞いた。

会議で間違えた。

あとから記録を読み返した。

その繰り返しだった。

人に教えられるようになるまでには、自分自身が何度も教えられる必要があった。

人は動く。それでも

だから、SaMD人材を探すとき、

「開発も薬事も分かる人はいないか」

と外に探し続けるだけでは、足りないのだと思う。

開発しながら考える。

薬事と話しながら考える。

臨床の言葉を聞いて、もう一度考える。

そして、その判断の理由を残す。

人は動く。

部署も変わる。

会社を去る人もいる。

それでも、

「なぜ、そう判断したのか」

が残っていれば、次の人はそこから始められる。

その人がまた1つ判断する。

その判断が、また次の人へ渡っていく。

あの会議で、私はすぐに返事ができなかった。

開発チームから人を抜擢すれば、それで解決するのか。

今でも、それだけで十分だとは思っていない。

人を採ることはできる。

けれど、経験までは採れない。

SaMD人材を育てるというのは、もしかすると、人を育てることだけではない。

その人が考えたことを、次の人が考え始められる場所をつくることなのだと思う。

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

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

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

全体の玄関はこちらです

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