バリデーションという言葉に対して、理解が不十分であったり、全く間違っている場合があるので注意したい。
まず気を付けなければならないことは、製薬業界とIT業界では、「バリデーション」の定義が異なるということである。
IT業界では、一般にバリデーションは、ソフトウェアのテストのことを指す。
製薬業界では、バリデーションは、当該コンピュータ化システムが、ユーザ要件を満たしていることを検証することを指す。日本語では「妥当性の確認」という。
つまり、製薬業界では、ソフトウェアのテストを行っただけでは、バリデーションを実施したことにはならない。
「GCP運用通知」の記録の保存等 第26条第1項に係る事項に以下の要件が記載されている。
１）電子データ処理システムが、完全性、正確性、信頼性及び意図された性能についての治験依頼者の要件を満たしていることを保証し、文書化すること（すなわちバリデーションされること。）。
ここでも明らかのように、ユーザの要件を満たしていることを検証することをバリデーションと定義している。
品質の良いソフトウェアとは
品質の良いシステム（ソフトウェア）とは、当該コンピュータ化システムが、ユーザの要件を完全に満たすものである。
不具合（バグ）がないことのみではない。
カテゴリ分類とは
パッケージの標準機能がそのままユーザ要件を満たしている場合、GAMPではカテゴリ3と呼ぶ。
例えば、分析機器、構造設備などである。
パッケージの標準機能を構成設定（コンフィギュレーション）して、ユーザ要件に適合させる方法を、GAMPではカテゴリ4と呼ぶ。
例えば、ドキュメント管理システムなどである。
パッケージの標準機能をカスタマイズして、ユーザ要件に適合させる方法を、GAMPではカテゴリ5と呼ぶ。
いずれのカテゴリも、その目的は、ユーザ要件にシステムを適合させることであることに注意すること。
筆者はよくあるシステムがどのカテゴリに相当するかといった質問を受けることがある。
これは、本末転倒である。
カテゴリ分類は手段の一環であり、目的は当該ソフトウェアをユーザ要件に適合させることである。
カテゴリを決定することが目的ではない。
URSとPQ
PQを実施するうえで重要なことは、当該システムのバグを発見することが目的ではないということである。
PQの目的は、当該システムがURSを満たしたかどうかを検証することである。
OQと同じテストを繰り返していても、この目的は達成できない。
PQは、URSを参照し、十分なビジネスシナリオを作成した上で計画しなければならない。
Comment