製薬業界の経験をスキルシートで伝える書き方｜領域・基準・検証の文書の示し方

製薬業界の経験をスキルシートで伝えるには、領域（研究・治験・安全性・製造品質・営業）、対象の基準（GxP）、システムの種類とパッケージか独自か、検証で作った文書、関わった部門の5つをそろえて書きます。「製薬会社向けシステム開発」とだけ書くと、読み手は何を任せられるかを判断できません。

一方で、製薬の経験には、開発中の医薬品や治験の情報、患者の情報など、書いてはいけないものが多く含まれます。この記事では、伝わる書き方と、書かない線の引き方をあわせて紹介します。スキルシートの全体の構成や基本の型はスキルシートの書き方の記事をご覧ください。

製薬の案件で読み手が知りたいこと

製薬の案件の担当者がスキルシートで確かめたいのは、主に次の3つです。

1. 同じ領域の経験があるか：治験の案件なら治験、製造の案件なら製造の経験か
2. 基準の対象のシステムで働いたことがあるか：検証や変更の手続きに慣れているか
3. 検証の文書をどこまで自分で作れるか：要求仕様書から報告書まで、どの文書を担当したか

製薬の案件では、システムの技術そのものより、決められた手続きの中で作業できるかが重く見られることがあります。技術の経験に加えて、手続きの経験が読み取れる書き方にすると、評価されやすくなります。

プロジェクト欄に足したい5つの項目

一般的なスキルシートのプロジェクト欄（期間・概要・役割・技術）に、次の5つを足します。

基準の対象かどうかを書き分ける

同じ製薬会社のシステムでも、GxPの対象になるものと、ならないものがあります。対象のシステムで働いた経験は、検証や変更の手続きに慣れていることの裏づけになります。分かる範囲で「GCPの対象」「GMPの対象」のように書き、対象外のシステムならそのように書いておくと、読み手が誤解しません。

検証の文書は名前で書く

厚生労働省の「医薬品・医薬部外品製造販売業者等におけるコンピュータ化システム適正管理ガイドライン」では、開発、検証、運用管理、廃棄の段階ごとに、要求仕様書、DQ・IQ・OQ・PQの計画書と報告書、バリデーションの報告書などが示されています。「バリデーションを担当」とまとめるより、どの文書を作成し、どの文書をレビューしたかを名前で書くほうが、担当の範囲が伝わります。

ガイドラインではソフトウェアをカテゴリに分ける考え方もとられています。パッケージをそのまま使ったのか、設定したのか、独自に作ったのかを書いておくと、どの程度の検証を経験したかが読み手に伝わります。

記入例（架空）

期間：（例）約1年半。うち自分の参画は要件定義から本番稼働後3か月まで
概要：（例）国内の製薬会社における治験のデータ収集システム（EDC）の導入
領域・基準：治験。GCPの対象のシステム
システムの種類：業界向けパッケージの設定と、社内の他システムとのデータ連携の開発
役割：検証の担当リーダー。メンバー2名
検証で作った文書：要求仕様書の取りまとめ、OQの計画書・報告書の作成、要求とテストのトレーサビリティの表の作成
関わった部門：データマネジメント部門と要求を詰め、品質保証部門のレビューを経て承認を得た
技術：（例）SQL、Python（データ連携）、テスト管理ツール

これは項目の埋め方を示すための架空の例です。実際の経験に置き換えて書いてください。

「主な担当」には判断を書く

製薬の案件では、文書を作るだけでなく、何を確かめる対象にするかの判断が問われます。

変更や不具合への対応を書くのも効果的です。本番稼働後に変更が入ったとき、影響の評価をどう行い、どこまで再テストしたかは、実際に関わった人でないと書けません。

保守・運用の経験も、手続きの経験として書けます。変更の申請から承認、テスト、記録までを何件ほど担当したか、逸脱の報告や定期的な点検に関わったかを書いておくと、稼働中のシステムを任せられるかが伝わります。

スキル一覧の書き方

スキル一覧には、技術の欄とは別に、業務と手続きの欄を設けます。

• 業務の領域：治験のデータ収集、副作用の情報の管理、製造の記録、資材の管理など、経験した業務
• 基準と手続き：GCP・GMP・GVPなどの対象のシステムでの作業経験、変更管理や逸脱の手続きの経験
• 検証の文書：作成した経験のある文書の名前
• 製品：使ったパッケージの名前（取引先が特定されないかぎり）
• 語学：英語の文書の読み書き、海外の拠点との会議の経験

テストや検証の経験の書き方はQAエンジニアのスキルシートの記事、CRMの製品の経験はSalesforceのスキルシートの記事、取りまとめの経験はPMOのスキルシートの記事も参考になります。

書かないことの線を引く

製薬の経験で特に注意したいのは、開発中の医薬品と治験の情報、患者の情報です。一般的なスキルシートで避ける社名や案件名に加えて、次のような情報は書きません。

開発中の品目や治験の計画は、公表される前の情報であることが多く、取引先が特に厳しく管理しています。公表されている情報かどうか判断がつかないときは、書かないほうを選びます。

患者の情報には特に注意が必要です。個人情報保護法は、病歴などを含む個人情報を「要配慮個人情報」と定め、取扱いに特に配慮を要するものとしています。治験や副作用の情報には、こうした情報が含まれることがあります。画面の写しやテストのデータをスキルシートや面談の資料に使うことは避けてください。

組み合わせで特定されないようにする

領域、疾患、規模、時期を組み合わせると、社名を書かなくても会社や品目が特定されることがあります。たとえば、ある疾患の治験を国内で行っている会社が限られる場合、疾患の名前を書くだけで分かってしまいます。提出前に、組み合わせたときに特定されないかを読み返します。ぼかし方の型はスキルシートと守秘義務の記事、契約上の秘密の範囲は秘密保持契約の記事で整理しています。

面談で口頭で伝えるときのコツ

面談では、シートに書いた内容を、手続きの流れにそって話せるようにしておきます。

• どの基準の対象で、なぜそうだったか：システムの用途と、記録の扱い
• 文書の流れ：誰が作り、誰がレビューし、誰が承認したか
• 変更が入ったときの動き：影響の評価から再テスト、記録までの流れ

面談でよく聞かれる質問の傾向は面談でよく聞かれる質問の記事で紹介しています。

よくある質問

開発品の名前を書かないと、経験の価値が伝わらないのではないですか？

読み手が知りたいのは、品目の名前より、どの領域で、どの基準の対象のシステムを、どこまで担当したかです。「治験のデータ収集」「GCPの対象」「OQの計画書と報告書を作成」と書けば、品目の名前がなくても、任せられる範囲は十分に伝わります。

GxPの対象かどうか分からないシステムを担当していました。どう書けばよいですか？

確かめられない場合は、基準の名前を書かず、「治験の部門で使う社内システム」のように用途で書きます。対象かどうかを推測で書くと、面談で深く聞かれたときに説明がずれることがあります。手順書に沿った変更の手続きを経験していれば、その事実を書いておくと手続きへの慣れが伝わります。

英語の文書を読んだ経験は書くべきですか？

製薬の案件では、海外の本社が作った文書や、海外の拠点との会議に関わることがあるため、書いておく価値があります。「英語の要求仕様書を読んで日本の要件と比べた」「英語で検証の文書を作成した」のように、何をしたかを具体的に書くと、程度が伝わります。