公開: 2026/5/6|更新: 2026/8/11

ヘルスケア・医療テックエンジニア採用ガイド｜規制×技術の人材確保戦略

医療DX・SaMD開発のエンジニア採用難易度と要件定義・選考設計・口説き方の実践手法を解説

ヘルスケア・医療テックのエンジニア採用は、「医療業界経験者」を探すのをやめた時点で成否が決まります。SaMD（プログラム医療機器）や電子カルテの開発経験者は市場に極めて少なく、経験者だけを追うと母集団はほぼゼロになるからです。実際に採用できている企業は、金融・自動車といった隣接規制産業やWeb系から技術力ベースで採り、薬機法・IEC 62304などの規制知識は入社後3〜6ヶ月の研修で習得させる設計を取っています。

TL;DR（この記事の要約）

ヘルスケアエンジニア採用の本質は**「医療経験者を探す」ではなく「技術力のある人材を医療テックに翻訳して招く」**こと
金融業界と同様に規制対応（薬機法・IEC 62304・個人情報保護）が参入障壁となり、経験者の母集団が極めて小さい
採用成功の鍵は「医療ドメイン知識が必須」と決めつけず、技術力ベースで採用し入社後にドメインキャッチアップさせるパスを用意すること
求人票では**「患者の命に直結するプロダクト」という社会的意義と技術的チャレンジの両面**を打ち出す
選考では品質設計の思考プロセス・リスク分析能力・規制への学習意欲の3軸で評価する

1. ヘルスケア・医療テックエンジニア採用市場の現状

医療テックのエンジニア採用が難しい理由は、需要が伸びていないからではなく、供給側の母集団が構造的に小さいからだ。IT人材全体が不足するなかで、さらに規制知識という条件を重ねることで、応募可能な人材が数百人規模まで絞り込まれてしまう。

採用市場の前提となる数値（公的統計）

経済産業省「IT人材需給に関する調査」: 2030年時点で最大約79万人のIT人材不足が生じると試算されている
厚生労働省「一般職業紹介状況」: 「情報処理・通信技術者」の有効求人倍率は例年2倍前後で推移し、全職業平均を大きく上回る
doda「転職求人倍率レポート」: IT・通信エンジニア職の求人倍率は10倍前後で推移し、全職種のなかで最も高い水準にある

つまり、ITエンジニア一般ですら10社が1人を奪い合う市場だ。そこに「医療機器ソフトウェアの開発経験」という条件を重ねれば、候補者が現れないのは当然の結果である。

「エンジニアを募集しているが、医療システムの開発経験者からの応募がゼロ」。この状況は、医療テックスタートアップから大手製薬のDX部門まで共通する悩みだ。

なぜ医療テックエンジニアの採用は難しいのか

難しさの根本には3つの構造的要因がある。

1. 人材プールの絶対的な小ささ

医療機器ソフトウェア（SaMD）やヘルスケアアプリの開発経験を持つエンジニアは、IT業界全体から見れば極めて少数だ。従来の医療機器メーカーでのソフトウェア開発はC/C++が主流で、Web系・クラウド系のモダンな技術スタックとは異なる世界だった。

一方でWeb系エンジニアは「医療は自分には関係ない規制の厳しい世界」と認識しがちで、そもそも応募先として考えない。この認知の壁が母集団を狭めている。

2. 規制・品質管理の壁

医療機器プログラムの開発には薬機法への適合が求められる。IEC 62304（医療機器ソフトウェアライフサイクルプロセス）、IEC 62443（サイバーセキュリティ）、個人情報保護法・次世代医療基盤法など、理解すべき法規制が多い。

この規制知識の習得に時間がかかるため、「即戦力」の定義が他業界より厳しくなる。

3. 外資ヘルステック・製薬との報酬格差

海外のヘルステック企業や外資製薬のデジタル部門は、日本のスタートアップより高い報酬を提示できる。特にAI/ML系のヘルスケアエンジニアは、GAFAM系のヘルスケア事業部からも引き合いがあり、年収競争が激しい。

市場の成長と人材需要の見通し

富士経済の調査によると、国内の医療・ヘルスケアDX関連市場は2025年に約7,800億円、2030年に1兆円を超える見込みだ。特に以下の領域でエンジニア需要が急増している。

SaMD（プログラム医療機器）: AIを活用した画像診断支援、治療アプリなど。2014年の薬機法改正で単体プログラムも規制対象に
電子カルテ・医療情報システム: クラウド移行とAPI連携の波でモダンな開発力が必要に
オンライン診療・PHR: コロナ禍を契機に普及が加速。UX設計力のあるエンジニアが不足
創薬DX・バイオインフォマティクス: AI創薬市場が急成長し、ML/データエンジニアの争奪戦に

2. 医療テックエンジニアの職種分類と要件定義

医療テックのエンジニア採用で最初にやるべきことは、職種を4つに分解して要件を書き分けることだ。「ヘルスケアエンジニア」という括りのまま求人票を書くと、必須スキルが足し算になり、市場に存在しない人材像ができあがる。

医療テックの主要4職種

SaMDエンジニア — プログラム医療機器そのものを開発する。薬機法・IEC 62304の適合が前提となり、最も採用難易度が高い
ヘルスケアWebアプリエンジニア — オンライン診療・PHR・予約システムなど非医療機器領域。Web系からの転換が最も現実的
医療AIエンジニア — 画像診断支援や予後予測モデルの開発。ML経験者の争奪戦になりやすい
医療データエンジニア — 電子カルテ連携・匿名加工・DWH構築。データ基盤経験者からの転換が効きやすい

このうち「経験者にこだわるべき」なのは1のSaMDエンジニアだけで、2〜4は他業界からの転換で十分に賄える。

主要な職種と求めるスキル

SaMDエンジニア（プログラム医療機器開発）

必須スキル	あると望ましいスキル
ソフトウェア設計（オブジェクト指向、テスト設計）	IEC 62304の実務経験
Python / C++ / Java のいずれか	薬事申請の経験
バージョン管理・CI/CD	FDA 21 CFR Part 11 の知識
リスク分析（FMEA等）の理解	ISO 14971（リスクマネジメント）

ヘルスケアWebアプリエンジニア

必須スキル	あると望ましいスキル
TypeScript / React / Next.js 等	HL7 FHIR の知識
REST API設計・マイクロサービス	医療情報システムの経験
セキュリティ設計の基礎	3省2ガイドラインの理解
クラウド（AWS / GCP）	HIPAA / GDPRへの対応経験

医療AIエンジニア

必須スキル	あると望ましいスキル
Python / PyTorch or TensorFlow	医用画像処理（DICOM）
ML/DLの設計・学習・評価	臨床研究の基礎知識
データパイプライン設計	薬事戦略の理解
統計学の基礎	論文読解・再現実装

医療データエンジニア

必須スキル	あると望ましいスキル
SQL / Python	医療データ標準（HL7, FHIR, SS-MIX2）
ETL / データパイプライン構築	匿名加工情報の設計
クラウドDWH（BigQuery等）	臨床統計の知識
データガバナンスの理解	次世代医療基盤法の理解

要件定義で陥りがちな失敗

失敗パターン1: 「医療経験必須」で母集団を潰す

最も多い失敗は、すべてのポジションに「医療業界経験3年以上」を必須条件にしてしまうこと。ドメイン知識は入社後6ヶ月で十分キャッチアップ可能なケースが多い。必須にすべきは「規制産業での品質管理マインド」であって、医療業界そのものの経験ではない。

失敗パターン2: 規制知識とコーディング力を同時に求める

IEC 62304に精通しつつモダンなWebアーキテクチャも設計できるエンジニアは、市場にほぼ存在しない。「技術力が高い人材を採用し、規制知識は社内で教育する」か「規制に強い人材を採用し、技術力は段階的に高める」か、どちらの戦略を取るか明確にすべきだ。

失敗パターン3: 「患者の命を預かる」プレッシャーだけを伝える

面接で安全性・リスクばかり強調すると、候補者は「失敗が許されない息苦しい環境」と感じてしまう。挑戦できる技術的面白さと、安全を担保する仕組み（QMS体制・レビュープロセス）の両面を伝えることが重要だ。

3. 医療テックエンジニアに刺さる求人票の書き方

医療テックの求人票は、「社会的意義」「技術的チャレンジ」「キャリア成長」の3軸を同じ分量で書くと応募率が上がる。社会的意義だけを前面に出した求人票は、エンジニアからは「技術的に面白くなさそう」と判断されて読み飛ばされるからだ。

求人票で打ち出すべき3つの軸

軸1: 社会的インパクト

ヘルスケアの最大の魅力は「自分の書いたコードが患者の人生を変える」という直接的なインパクトだ。ただし抽象的な「社会貢献」では響かない。具体的に書く。

良い例:

「あなたが開発するAI画像診断支援が、年間X万件の検診で見落としを防ぐ」
「開発した治療アプリが禁煙外来の成功率を高め、保険適用を受けている」

悪い例:

「医療の未来を一緒に創りましょう」（抽象的すぎる）

軸2: 技術的チャレンジ

エンジニアが興味を持つのは、解くべき技術的課題の面白さだ。

「秒間X件の生体データをリアルタイム処理するストリーミング基盤の設計」
「匿名加工と有用性を両立する差分プライバシーの実装」
「マルチモーダルな医療データ（画像・テキスト・数値）を統合するMLパイプライン」

軸3: キャリア成長の道筋

規制産業のエンジニアは市場価値が高い。この事実を率直に伝える。

「SaMD開発経験は国内外で引く手あまた。薬事×ソフトウェアのスキルは希少性が高い」
「入社後の研修でIEC 62304の基礎を習得。1年後には薬事申請をリードできるレベルに」

求人票テンプレート

NGワード・表現

以下の表現は候補者を遠ざけるリスクがある。

NG表現	改善案
「医療業界経験必須」	「規制産業での開発経験歓迎（金融・自動車等でも可）」
「ミスが許されない環境」	「品質設計の仕組みで安全性を担保する環境」
「レガシーシステムの保守」	「既存システムのモダナイズをリードする」
「資格必須（情報処理安全確保支援士等）」	「入社後の資格取得を支援」

4. ヘルスケアエンジニアの母集団形成戦略

母集団形成は、候補者を「医療テック経験の距離」で4層に分け、層ごとに別のメッセージを当てるのが定石だ。全員に同じスカウト文を送ると、経験者には刺さらず未経験者には届かない、という最悪の状態になる。

ターゲット4層の優先順位

第1層：医療テック経験者 — 転換コストはゼロだが母集団も最小。まず取り切る前提で、少数精鋭のスカウトを打つ
第2層：隣接規制業界（金融・自動車・製造） — 品質設計とリスク分析の素地があり、最も費用対効果が高い主戦場
第3層：Web系エンジニア — 技術力は最も高い層。「医療＝堅い」というイメージを壊す発信が前提条件になる
第4層：アカデミア出身者 — 医療情報学・バイオインフォマティクス。研究から産業への移行支援を示せるかが分岐点

採用計画を立てるときは、第2層と第3層に採用工数の7割を配分するのが現実的だ。

ターゲットを4層に分けてアプローチする

第1層: 医療テック経験者（最も採用しやすいが最も少ない）

医療機器メーカーのソフトウェア部門出身
電子カルテベンダー出身
他のヘルステックスタートアップ出身
バイオインフォマティクス経験者

アプローチ先: BizReach、Forkwell、LAPRAS、学会・カンファレンス（各媒体の特徴はエンジニア採用媒体の選び方を参照）

第2層: 隣接規制業界の経験者（コンバートしやすい）

金融系エンジニア（セキュリティ・コンプライアンスの素地あり）
自動車業界のソフトウェアエンジニア（機能安全・ISO 26262経験者）
製造業の品質管理エンジニア（FMEA・V字開発に慣れている）

これらの人材はリスク分析や品質設計の考え方がすでに身についているため、医療特有の規制を学ぶだけで活躍できる。特に金融業界からの転職者についてはフィンテック・金融エンジニア採用ガイドで解説している人材像と重なる部分が多い。

第3層: Web系エンジニア（技術力は高いが規制経験なし）

SaaSスタートアップのバックエンドエンジニア
インフラ / SRE（セキュリティ設計の経験）
データエンジニア / MLエンジニア

この層へのアプローチで重要なのは「医療＝堅い・つまらない」というイメージを壊すこと。技術ブログやカンファレンス登壇で、モダンな技術スタックとスタートアップらしい開発文化を発信する。

第4層: アカデミア出身者

大学の医療情報学研究室
バイオインフォマティクスの博士・修士
情報系で医療AIをテーマにした研究者

研究から産業への移行を支援する姿勢を見せることが重要だ。

チャネル別のアプローチ戦略

ダイレクトスカウト

スカウト文面では「なぜ医療テックなのか」「なぜ今なのか」を明確にする。特に第2層・第3層の候補者には、以下のポイントを含めるべきだ。

現職のスキルがどう医療テックで活きるか（スキルの翻訳）
医療ドメイン未経験でも活躍している社内メンバーの存在
入社後の学習支援体制

テックカンファレンス・勉強会

医療テック専門のイベントだけでなく、一般的な技術カンファレンス（CloudNative Days、PyCon JP等）に登壇することで第3層にリーチできる。発表テーマは「医療データのリアルタイム処理」「ヘルスケアにおけるMLOps」など、技術的な切り口で設計する。

技術ブログ・OSS活動

以下のようなテーマで情報発信すると、ヘルスケアに関心があるエンジニアの目に留まる。

FHIR実装の技術的ポイント
SaMD開発でCI/CDをどう設計するか
医療AIの精度評価とバイアス対策

リファラル

社内のエンジニアが前職時代の同僚を紹介するリファラル施策は、特にヘルスケア業界で有効だ。なぜなら、第2層・第3層の人材は「知り合いが実際に働いていて楽しそう」というリアルな情報を最も信頼するからだ。

5. 選考設計：技術力と規制マインドの見極め方

医療テックの選考で見るべきは規制知識の有無ではなく、「品質・安全に対する思考のクセ」だ。IEC 62304やFHIRの知識は入社後に習得できるが、リスクを体系的に洗い出す思考習慣は短期間では身につかない。

選考フローの設計

推奨する選考フローは以下の5ステップだ。

カジュアル面談（30分） — 医療テックへの興味を引き出す。この段階で規制の重さを語りすぎない
技術課題（持ち帰り / 1週間） — セキュリティ・監査ログ・データ削除要求を含む設計課題で品質思考を見る
技術面接（60分） — 課題の設計意図を深掘りし、トレードオフの判断根拠を確認する
カルチャーフィット面接（45分） — QA/RAメンバーを同席させ、規制との折り合いの付け方を見る
オファー面談 — 入社後90日の学習計画をセットで提示し、未経験の不安を潰す

技術課題の設計

医療テック特有の技術課題として、以下のようなテーマが有効だ。

例1: API設計課題（バックエンド向け）

「患者の服薬記録を管理するAPIを設計してください。以下の要件を満たすこと：認証・認可の設計、監査ログの記録、データ削除要求への対応」

評価ポイント:

セキュリティ設計の深さ（認証だけでなく監査証跡まで考えられるか）
データの整合性に対する配慮
エラーハンドリングの考え方

例2: リスク分析課題（SaMD向け）

「以下のシンプルな機能仕様に対して、起こりうるリスクを洗い出し、対策を提案してください。[簡単な仕様書を提示]」

評価ポイント:

体系的にリスクを洗い出せるか（FMEAの考え方に近いか）
リスクの重大度と発生頻度を区別できるか
現実的な対策を提案できるか

技術面接での質問例

品質設計の思考を見る質問

「前職で最もクリティカルなバグを修正した経験を教えてください。どう発見し、どう対処し、再発防止にどう取り組みましたか？」
「テストカバレッジ100%でも防げないバグとは何ですか？どう対策しますか？」
「コードレビューで最も重視するポイントは何ですか？」

学習意欲・適応力を見る質問

「未経験のドメインで開発した経験はありますか？どうキャッチアップしましたか？」
「規制やルールに従いながら開発するとき、やりづらさを感じたことはありますか？どう折り合いをつけましたか？」
「医療テックに興味を持った理由を教えてください」

リスク感度を見る質問

「本番環境にデプロイするとき、個人的に必ず確認することは何ですか？」
「セキュリティとユーザビリティがトレードオフになったとき、どう判断しますか？」
「自分のコードにバグがあり、それが患者に影響する可能性がある場合、どう行動しますか？」

評価で注意すべき点

「規制を知っているか」ではなく「規制を学ぶ姿勢があるか」で評価する

IEC 62304やFHIRの知識は入社後に習得できる。面接で見るべきは、新しいルールや制約を前向きに受け入れ、その中で最善を尽くす姿勢だ。

過度に慎重すぎる人材にも注意

医療テックだからといって、リスクを過大評価して何もリリースできないエンジニアは適さない。「許容可能なリスク」を判断し、適切なスピードで開発を進められるバランス感覚が重要だ。

6. オファー・クロージング戦略

医療テック企業が外資ヘルステックや大手製薬のデジタル部門と競合したとき、報酬の絶対額で勝てる場面はほとんどない。勝ち筋は「希少スキルの獲得」「裁量の大きさ」「プロダクトの社会的意義」という非金銭的価値を、候補者のキャリア観に接続して具体的に語ることにある。

医療テック企業ならではのオファー設計

報酬レンジの目安（2026年時点）

ポジション	年収レンジ
ジュニア（経験1〜3年）	450〜600万円
ミドル（経験3〜7年）	600〜900万円
シニア / テックリード	900〜1,300万円
医療AI/MLスペシャリスト	800〜1,500万円
VPoE / CTO級	1,200〜2,000万円

外資ヘルステックや製薬のデジタル部門と競合する場合、報酬だけでは勝てないことが多い（報酬設計の詳細はエンジニア採用で勝つための報酬設計と年収戦略を参照）。以下の非金銭的要素で差別化する。

差別化ポイント1: プロダクトの社会的意義

「自分のコードが患者の命を救う」という体験は、BtoBのSaaSや広告テックでは得られない。この本質的なやりがいを、実際の患者さんの声や医師からのフィードバックとして伝える。

差別化ポイント2: 希少スキルの獲得

SaMD開発やFHIR実装の経験を持つエンジニアは、国内外で引く手あまただ。「ここで3年働けば、市場でほぼ唯一無二の人材になれる」というキャリア投資の視点を伝える。

差別化ポイント3: 規制産業ならではの安定性

医療は景気変動の影響を受けにくい。スタートアップであっても、医療ニーズそのものがなくなることはない。この安定性は特に30代後半以降の候補者に響く。

差別化ポイント4: 裁量の大きさ

大手製薬のデジタル部門では、意思決定が遅くエンジニアの裁量が限られがちだ。スタートアップなら「アーキテクチャの選定から自分で決められる」「PMDAとの折衝にも直接関われる」という裁量の大きさが魅力になる。

クロージングで伝えるべきメッセージ

内定から承諾までの期間に以下を伝える。

入社後3ヶ月の具体的な計画: 何をどの順番で学ぶか、誰がサポートするか
チームメンバーとの接点: 入社前に現場エンジニアとランチや1on1の機会を作る
意思決定の根拠: なぜその候補者を選んだのか、どんな活躍を期待しているか

7. 入社後の定着：医療テック特有のオンボーディング設計

医療ドメイン未経験者を採用する戦略を取る以上、オンボーディング設計は採用活動の一部として同時に作らなければならない。「入社後に教育する」と求人票に書いておきながら実体がなければ、入社3ヶ月での早期離職に直結する。

オンボーディングの基本設計についてはエンジニアのオンボーディング完全ガイドも合わせて参照してほしい。

最初の90日間のロードマップ

Week 1-2: 環境構築 + 基礎学習

開発環境のセットアップ
薬機法・医療機器プログラムの基礎研修（社内資料 + 外部セミナー）
セキュリティ研修（個人情報取り扱い、3省2ガイドライン）
既存コードベースの概要把握

Week 3-4: ペアプログラミング期間

小さなタスクからペアで取り組む
コードレビューを通じて品質基準を体感する
QA/RA（品質保証/薬事）チームとの顔合わせ

Month 2: 自走開始

中規模のフィーチャー開発を担当
設計レビューに参加し始める
IEC 62304の社内トレーニング（該当する場合）

Month 3: 戦力化

独力でフィーチャーを設計・実装・テスト
コードレビューのレビュアー側に回る
チーム改善提案を歓迎する

定着率を高める施策

ドメイン学習の仕組み化

月1回の「医療ドメイン勉強会」（医師や看護師をゲストに招く）
医療系カンファレンスや学会への参加費支援
薬事関連資格の取得支援（費用負担 + 学習時間の確保）

エンジニアリングの自律性を守る

規制産業では手続きやドキュメントが増えがちだ。しかし「必要最小限のプロセスで最大の品質を担保する」設計を心がけ、エンジニアが本質的な開発に集中できる環境を守る。

CI/CDで自動化できる品質チェックは自動化する
ドキュメントはコードから自動生成する仕組みを整備する
規制対応のテンプレート化・型化を進める

患者・医療従事者の声を届ける

エンジニアのモチベーションを高める最も強力な手段は、自分のプロダクトが実際に使われている現場の声を直接届けることだ。

導入先の医療機関への見学機会
患者さんからのフィードバック共有
臨床試験の結果報告会への参加

8. ヘルスケアエンジニア採用のロードマップ

採用体制構築の段階的アプローチ

Phase 1（0〜3ヶ月）: 基盤整備

エンジニア採用ブランディングの構築（技術ブログ開始）
既存メンバーのリファラル協力の仕組み化
求人票の最適化（医療未経験者も応募しやすく）
ダイレクトスカウト開始（BizReach, Forkwell, LAPRAS）

Phase 2（3〜6ヶ月）: 母集団の拡大

テックカンファレンスへの登壇・スポンサー
隣接業界（金融・自動車・製造）へのアプローチ強化
カジュアル面談の質向上
採用KPIの計測開始

Phase 3（6〜12ヶ月）: 採用力の確立

医療テック × 技術のポジショニング確立
リファラル採用の比率向上
入社者の成功事例の可視化・発信
オンボーディングの仕組み改善

採用を成功させるための体制

QA/RA（品質保証・薬事）チームとの連携: 面接プロセスにQAメンバーを組み込み、品質マインドの評価を担当してもらう
医師・医療従事者との協働体制の可視化: 採用面談で医師やドメインエキスパートと話す機会を設ける
経営陣のコミット: 技術リーダーの採用には経営陣が直接クロージングに関与する

FAQ（よくある質問）

Q. 医療業界未経験のWebエンジニアでも本当に活躍できますか？

多くの医療テックスタートアップで、Web系出身のエンジニアが活躍している。重要なのは「学習意欲」と「品質に対する高い意識」だ。入社後3〜6ヶ月のオンボーディングで必要なドメイン知識は十分にキャッチアップできる。むしろWeb系出身のモダンな開発スキルは、レガシーが多い医療業界では強みになる。

Q. SaMD開発のエンジニアは、年収相場がどのくらいですか？

2026年時点で、SaMD開発経験のあるミドルクラスのエンジニアは700〜1,000万円が相場だ。IEC 62304に精通し薬事申請まで経験がある人材は1,200万円以上になることもある。ただし「SaMD経験者」と限定すると母集団が極めて小さいため、「品質管理 × ソフトウェア開発」のスキルセットで採用し、SaMD固有の知識は入社後に教育するアプローチが現実的だ。

Q. 薬機法の規制対応は、エンジニアが直接担当するものですか？

基本的には、薬事（RA: Regulatory Affairs）の専門家が規制戦略を立て、品質保証（QA）がプロセスを管理する。エンジニアに求められるのは「なぜそのルールがあるのか」を理解し、設計・実装レベルで品質を作り込むことだ。規制書類の作成そのものをエンジニアに押し付けるのは組織設計の問題であり、適切な分業が必要。

Q. ヘルスケアスタートアップで、大手製薬のデジタル部門とどう差別化すればよいですか？

大手製薬のデジタル部門は報酬が高い反面、意思決定が遅く裁量が限られる傾向がある。スタートアップの差別化ポイントは「アーキテクチャから自分で選べる裁量」「プロダクトの成長を目に見えて感じられるスピード感」「医師・患者との距離の近さ」だ。特に「自分が開発したものが直接患者さんに届く」という実感は、大手では得にくい。

Q. 医療データの取り扱いで、エンジニアが最低限知っておくべき法律は？

まず個人情報保護法における「要配慮個人情報」としての医療データの扱い、次に医療情報の安全管理に関する3省2ガイドライン、そして次世代医療基盤法（匿名加工医療情報に関する法律）の3つが基本だ。SaMD開発に携わる場合は薬機法の基礎知識も必要になるが、これらは入社後の研修で十分学べる内容だ。

Q. リモートワークと医療テック開発は両立できますか？

多くの医療テック企業がリモートまたはハイブリッドの勤務形態を導入している。ソフトウェア開発はリモートで十分可能だ。ただし、医療機器のハードウェア連携テストや、医療機関での現場検証が必要な場合は出社・出張が発生する。採用時に勤務形態を明確にし、「基本リモート、月X回の現場検証時は出社」のように具体的に伝えることが重要。

Q. 小さなヘルスケアスタートアップが、最初にどの職種を採用すべきですか？

プロダクトの段階による。SaMDとして薬事申請を目指すなら、まず「ソフトウェア品質に責任を持てるシニアエンジニア」が最優先。次に薬事・QAの専門家を採用し、規制対応の基盤を作る。一般的なヘルスケアアプリ（非医療機器）なら、通常のWeb系スタートアップと同様にフルスタック寄りのエンジニアから始めて問題ない。