SaMD・薬機法承認プロセスとPM。開発と薬事、二本のレールを走らせる仕事

「開発は終わったのに、なぜまだリリースできないんですか」。SaMD（Software as a Medical Device、プログラム医療機器）のプロジェクトに初めて関わったPMが、必ずと言っていいほど一度はぶつかる壁です。答えは単純で、開発の完了と、市場に出せる状態は、SaMDにおいては別物だからです。承認審査という、開発チームだけではコントロールできないプロセスが間に挟まります。この記事では、SaMD領域のPMが実際に何をしているのか、そしてどんな経験がここで活きるのかを解説します。

0. 前提：SaMDとは何か、なぜ普通のアプリ開発と違うのか

SaMDとは、診断支援AIや治療用アプリのように、ソフトウェア単体が医療機器として薬機法上の承認・認証の対象になる製品群を指します。一般的なアプリであれば、リリース後にユーザーの反応を見ながら機能を追加・修正していく、いわゆるアジャイルな進め方が主流です。ところがSaMDでは、承認された仕様から逸脱する変更を行う場合、原則として再度の届出や審査対応が必要になります。つまり「リリースしてから直せばいい」という発想が通用しにくい領域だということです。この構造の違いを理解しないままプロジェクトに入ると、開発側の当たり前と薬事側の当たり前が衝突し、プロジェクトが停滞します。

1. PMの実務：2つのガントチャートを同時に見る

SaMD案件のPMは、実質的に2つのガントチャートを同時に運用しています。1つは通常の開発スケジュール、もう1つは薬事申請・審査対応のスケジュールです。この2つは独立して動くのではなく、随所で依存関係を持ちます。例えば、非臨床試験や治験データの提出が必要な場合、そのデータが揃わないと審査を申請できません。逆に、審査側からの照会事項（追加資料の要求）が来ると、開発チームは一時的に別の作業に手を回す必要が出てきます。このスケジュールの二重管理こそが、SaMD領域のPMに固有の専門性です。率直に言えば、これは経験がないと感覚がつかめません。だからこそ、一度この経験を積んだ人材の市場価値は高くなります。

2. 対比：一般的なプロダクト開発のPdMとの違い

SaaSプロダクトのPdM経験者にとって、要件を磨き込みユーザー価値を最大化するという基本姿勢はSaMDでも変わりません。違うのは、磨き込みの過程に「規制上の制約」という変数が常に加わる点です。ある診断支援ソフトウェアの開発では、当初UI/UXチームが提案した直感的な操作フローが、規制上求められる「誤操作防止のための確認ステップ」と衝突し、再設計が必要になった場面がありました。ここで重要だったのは、規制を単なる制約として受け止めるのではなく、「なぜその規制があるのか」という背景（この場合は誤診断のリスク低減）を理解した上で、ユーザー体験と両立する設計を模索する姿勢でした。この視点の持ち方こそ、優れたPdM経験者がSaMD領域で評価される理由です。

3. どんな経歴の人が向いているか

誤解がないように申し上げると、SaMD領域は「規制に詳しい人」だけの市場ではありません。むしろ僕がこれまで支援してきた転職者を見ると、以下のようなタイプが活躍しています。1つ目は、金融機関のシステムなど、他の規制業界でコンプライアンス要件を織り込んだ開発経験を持つ方。2つ目は、ヘルスケア領域のスタートアップでPdMを務め、プロダクトと規制の両立を模索してきた方。3つ目は、臨床工学技士や薬剤師など医療資格を持ちながらIT寄りの業務に関わってきた方です。これらの経歴は一見バラバラに見えますが、共通しているのは「制約の中で最適解を探す」という思考の型です。

4. キャリアの広がり：SaMD経験が開く次の扉

SaMD領域で経験を積むと、その後のキャリアには複数の方向性が見えてきます。同じ企業内でより大規模な製品群の開発責任者になる道、規制対応の知見を活かしてRA（レギュラトリーアフェアーズ）寄りのポジションへシフトする道、あるいはスタートアップの創業メンバーとして規制対応の設計から関わる道などです。以下は目安であり統計値ではありませんが、規制と開発の両方を理解する人材は市場での希少性が高く、転職時の年収交渉においても優位に働くケースを多く見てきました。

5. 「照会事項」への対応がPMの真価が問われる瞬間

SaMD審査の過程では、規制当局から「照会事項」と呼ばれる追加の質問や資料要求が届くことがあります。これに対する回答期限は決して長くなく、開発チームは通常業務と並行して対応する必要に迫られます。ある画像診断支援ソフトウェアの案件では、想定していなかった角度からの照会が来て、社内が一時的に混乱した場面がありました。この時、PMが最初にやったことは「誰が何を、いつまでに用意するか」を即座に整理し、開発チームの通常タスクへの影響を最小化する優先順位付けでした。パニックに陥りやすい局面だからこそ、冷静にタスクを分解し、関係者に安心感を与える振る舞いが評価されます。

6. 「作りながら学ぶ」ではなく「学びながら作る」姿勢の重要性

一般的なプロダクト開発では、まず作ってみて反応を見ながら学ぶという進め方が許容されます。SaMDではこの順序が通用しにくいため、着手前に規制の骨格を学ぶ姿勢が求められます。とはいえ、規制の全てを完璧に理解してから動き出す必要はありません。実務で評価されるのは、分からないことを分からないままにせず、薬事担当者やRA部門に早めに確認を取りにいく姿勢です。僕がこれまで見てきた優れたSaMD領域のPMは、例外なく「早めに聞く」ことを徹底していました。

7. 海外展開を見据えたSaMD案件が増えている理由

近年は日本国内の薬機法対応だけでなく、米国FDAや欧州のMDR（医療機器規則）など、複数の規制当局の要求を同時に満たす形で開発を進めるSaMD案件が増えています。国ごとに承認プロセスや要求資料が異なるため、PMには「どの国の審査を優先して進めるか」というロードマップ設計の視点も求められます。この視点を持つPMはまだ市場に少なく、グローバル展開を狙う企業にとって非常に貴重な人材です。

8. QMS（品質マネジメントシステム）との付き合い方

SaMD開発では、ISO13485等に基づくQMS（品質マネジメントシステム）の運用と足並みを揃える必要があります。開発の各工程で必要な文書化・レビュー記録が定められているため、PMはこのQMSのルールを開発プロセスに違和感なく組み込む工夫が求められます。QMSを「面倒な事務作業」ではなく「後で必ず自分たちを助けてくれる記録」と捉えられるかどうかで、プロジェクトの安定感が変わってきます。

9. スタートアップと大手企業、どちらでSaMD経験を積むべきか

スタートアップでは薬事対応の初期設計から関われる裁量の大きさが魅力です。一方、大手企業では体系化されたQMSやRA部門のもとで型を学べる安心感があります。どちらが優れているという話ではなく、まず型を学びたいか、裁量を持って手探りで進めたいかという志向で選ぶのが妥当です。

（結論）「制約を面白がれるか」が最初の分岐点

SaMD領域のPMに向いているかどうかを見極める最初の分岐点は、規制という制約を「不自由」と捉えるか、「設計の難易度を上げてくれる面白い変数」と捉えるかだと僕は考えています。この記事の下にある適性診断では、あなたの志向がこの領域に合っているかを確認できます。皆さんいかがでしたでしょうか。制約は思考を鍛える砥石です。ではその視点を持って、今日もがんばりましょう。