はじめに
システム開発は業界ごとに求められるルールや文化が大きく異なるものです。特に製薬業界は、生命に関わる医薬品の品質や安全性を保証するため、システムの開発にも厳格な基準が存在します。私自身、製薬業界のシステムの開発で経験を重ねてきましたが、その過程で他業界からSEが参画される際、最初に直面する”壁”にはある程度共通するものがあると感じています。それは以下の3つです。
- トレーサビリティ
- データインテグリティ
- リスクベースアプローチ
この記事では、これらがなぜ”壁”となるのか、そしてどのように対処すべきかについて、私なりの考察をお伝えします。
「はじめて製薬業界のシステム開発」に臨む皆様の一助となれば幸いです。
トレーサビリティ：どの行動も「記録」と「追跡」が基本
システム開発におけるトレーサビリティとは、要求仕様から設計、テストに至るまで、すべての活動がどのように紐づいているかを追跡できるようにする活動を指します。製薬業界のシステム開発では、活動の正しさや抜け漏れがないことを客観的に証明する必要があるため、非常に重要視されます。
なぜ壁となるか
「自分の作業は自分が分かっているから大丈夫」という前提で記録を残しがちであるためです。しかしそのような記録は他の人には理解できないことが多く、後々大きな問題になる場合があります。
対処法
- 自分だけの独自用語や表現を使っていないか？
- 自分以外の誰かが見ても内容が理解できるか？
- 記録を伝える相手（管理者や監査担当者など）を具体的にイメージしているか？
など、「他の人が後から追跡し、同じ成果を得られるか？」を意識して記録するとよいでしょう。常に意識することで記録の質が向上し、トレーサビリティは自然と確保されていきます。
２．データインテグリティ：「信頼できるデータ」のための原則
データインテグリティは、「データの完全性」とも訳され、「すべてのデータがライフサイクルを通して完全で正確に記録されていること」を意味します。この概念はシステム開発に限らず、あらゆる活動に求められる基本的な要件です。データインテグリティの欠如に起因する事件が近年多発したことから、その重要性がさらに高まっています。
データインテグリティを確保するための要件には、ALCOA原則というものがあります。これは各要件の頭文字をとったもので、それぞれ以下を意味しています(後半のCCEAは、ALCOA原則の拡張版であるALCOA＋(プラス)の要件)。
- A：Attribute（帰属性） – 誰がデータを記録・修正したか特定できる
- L：Legible（判読性） – データが読みやすい状態で保存されている
- C：Contemporaneous（同時性） – データは遅滞なく記録される
- O：Original（原本性） – 最初に生成されたデータが記録されている
- A：Accurate（正確性） – データは事実に基づき正確に記録されている
- C：Complete（完全性） – 事象を再現できる記録がある
- C：Consistent（一貫性） – 記録は一貫していて矛盾がない
- E：Endurering（不朽性） – 保存期間に渡ってデータが利用できる形で保管されている
- A：Available（可用性） – 必要なときにデータが使用できる
なぜ壁となるか
各要件自体は決して特別なものではありませんが、すべての活動で一貫して意識することが難しく、抜け漏れが生じやすいためです。特に、設計やプログラミングでこの原則を意識できていないと、後に発見が困難な問題の原因となる可能性があります。
対処法
データインテグリティはすべての活動で求められる要件のため、面倒でも常にチェックを続けることが結局は習熟への近道です。設計や開発などを行う際には、ALCOA原則の要件を満たしているかを意識的に確認する習慣をつけましょう。ALCOA原則を意識した開発プロセスが整備されているプロジェクトでは、その手順を忠実に守りながら、各プロセスの意味や背景を一つひとつ理解していくことも重要です。
また、規制やガイドラインには、データインテグリティの要件を満たすために必要な取り組みが記されています。その内容を少しずつでも着実に理解し、実践していくことが大切です。
３．リスクベースアプローチ：曖昧なリスク判断を減らす仕組み
リスクベースアプローチとは、リスクマネジメントの手法を用いてリスクを特定し、リスクの大きさに応じて適切な対応を行う活動です。開発するシステムによっては、リスクが患者の命に関わる可能性もあるため、非常に重要な活動となります。
なぜ壁となるか
リスクの大きさ(発生頻度、発生時の影響)をSEとしての経験のみに頼って調査・評価することで、優先順位の設定や対応を誤る可能性があるためです。特に、規制や安全性に関する課題が存在していても、技術的には問題がないリスクを見逃してしまいがちです。
対処法
リスクは技術面以外にも潜んでいるため、評価を経験や直感だけに頼らないことが重要です。プロジェクト内で手順や基準が共有されている場合は、それを積極的に活用しながら一つずつ慣れていきましょう。見落としがないかを有識者と積極的に協議することも効果的です。
また、すぐに全てを理解するのは難しいかもしれませんが、規制やガイドラインについて少しずつでも理解を深めていくことも重要です。技術面以外で何をリスクとして考えればよいかを知る手がかりになるでしょう。
まとめ：意識的に考える習慣が習熟への鍵
「トレーサビリティ」「リスクベースアプローチ」「データインテグリティ」という3つの要素は、製薬業界のシステム開発で特に重要視されるものの、品質確保の観点では本来どの開発でも必要とされる基本的な考え方であり、特別なものではありません。これまでSEとして経験則に基づいて行ってきた活動を、改めて意識的かつ体系的なプロセスとして捉え直すことで、自然と製薬業界特有の基準やルールにも適応できるようになるはずです。
少しでも「参考になった」と思っていただけたなら、幸いです。
主な参考文献
- 医薬品・医薬部外品製造販売業者等における コンピュータ化システム適正管理ガイドライン入門 第4版,蛭田 修,株式会社じほう,2020年
- データインテグリティ対応の大前提! Q&Aで学ぶCSV入門,荻原 健一,株式会社じほう,2019年
- 適切な査察対応が見えてくる! Q&Aで学ぶデータインテグリティ,荻原 健一,株式会社じほう,2017年
- ICH-Q9 品質リスクマネジメント（R1）（ステップ5）,独立行政法人 医薬品医療機器総合機構,2023年