1. はじめに
筆者が経験する、多くの間違ったCSVの理解を参考に、5つに質問をしてみたい。それぞれ「YES」か「NO」で答えていただきたい
- バリデーションとは、システムの受入れ試験のことである。
- バリデーションの目的は、品質保証である。
- 市販のパッケージは、バリデーションが不要である。
- パッケージのバリデーションは、自社開発に比べて簡単である。
- バグのあるシステムは使用してはならない。
1．バリデーションはシステムの受入れ試験ではない
「Computer System Validation」（コンピュータシステムのバリデーション）であり、テストのことと同義であ った。 今でも、バリデーションはシステムの受入れ試験（テスト）のことで あると考えている人も多いと思われる。
しかしながら、現在では「Computerized System Validation」（コンピュータ化されたシステムのバリデーション）が主流となっている。つまり、コンピュータ化された業務プロセスのバリデーションが求められているのである。
FDAのほとんどのガイドラインには「Computerized System」とあることに注意していただきたい。
この業務プロセスの一部をコンピュータ化する際の導入プロジェクト は通常、
計画→要求→設計→製造→テスト→運用
というステップを踏むことが一般的である。このステップを一般にSoftware Development Life Cycle（SDLC）と呼ぶ。このライフサイクル全体がCSVの対象範囲 となる。SDLCに関しては別の章で解説する。
2．バリデーションの目的は品質保証である
品質とは何か、また品質保証とは何かに関しては、説明が難しい。 詳しくは章を改めて解説を行うが、ここでは簡単にふれておく。
まず品質とは、顧客の望む基準、顧客側の条件のことである。品質は通常、名詞で表現される。
製薬業界における顧客とは、患者、医師、医療機関や規制当局などがあげられる。
特に新薬の申請に関しての顧客は、規制当局である。申請資料の品質は当然、規制当局の期待に沿うもので無ければならない。
申請資料で扱うデータは、薬剤の「安全性」「有効性」「品質」に関するものであり、人の健康に幅広く関係するもので最高の品質と完全性がなければならない。
では品質保証は何かというと、品質にいわゆる「お墨付き」を与えることである。第三者が見て、確かに要求される品質が達成できている という文書化された証拠を元に、保証を行うのである。 バリデーションの目的はまさに、品質保証であるといえる。
筆者がコンサルテーションを経験した大手外資製薬会社ではバリデーション計画書のことを、Project Quality Plan（プロジェクト品質計画書）と呼んでいる例がある。
3．市販のパッケージのバリデーション
筆者は長年にわたり、臨床試験管理システムや臨床データ管理システ ム等のアプリケーションシステムを開発、サポートしてきた経験を持つ。その際にある製薬企業の情報システム部員から「パッケージシステムをカスタマイズしないで導入するのだから、バリデーションは 不要ではないか」という指摘を受けたことがある。つまり彼は、バリデーションとはコンピュータシステムの導入テストあるいはソフトウェアの不具合（バグ）の発見のことであると考えているのである。これは言うまでもなく間違いである。
前述したとおり、FDAは単にコンピュータシステムにバグや不具合の ないことを要求しているのではない。紙ベースのオペレーションがコンピュータ化された際に、申請に関係するデータの品質および品質保証が、劣化しないという保証を求めているのである。
システムの「業務への適合性」についての最終的な責任は製薬企業にあるのである。
FDAが1999年5月に発行した「Guidance for Industry Computerized System Used in Clinical Trials」にはこう記載されている。
市販のソフトウェアの場合、バリデーションの大半がそのソフトを書いた会社で実施済みであるべきである。臨床試験依頼者またはCROは、ベンダーによるこの設計レベルのバリデーション文書（バリデーション文書の原文でもベンダーオーディットの文書でもよい）を保有すべきで、自身で機能テスト（テストデータを使用するなどして）も実施しておくこと。既知のソフトウェアの制限事項、問題点、欠陥修正暦を調査しておくこと。
- 市販で購入でき、
- 一般的な使用目的のために広く使えるよう設計され、
- 無修正で
- データの直接入力に使用されていないデータベースやスプレッドシートのソフトウェアという特別な場合、臨床試験依頼者やCROはデザインレベルのバリデーションの記録を持っていなかもしれない。しかしながら、臨床試験依頼者やCROは自ら機能テストを（テストデータセットなどを使用して）実施し、既知の制限事項や、問題点や、欠陥修正履歴を調査しておくべきである。
つまり市販のパッケージといえども、製薬会社側においてもテストを実施する必要性がある。
4．パッケージは自社開発よりCSVが容易である
パッケージを導入する際に、間違ってはならないことは、そのパッケージのバグの発見や修正を、自社のリソース（人、時間、金）を使って行うべきではないということである。
パッケージ自体のバリデーション（品質保証）は、その製造元のベンダーによって実施されるべきである。
したがって、製薬企業におけるパッケージのCSVは、その多くをカスタマイズ部分（コンフィグレーションを含む）に対して行うことにな る。つまり、パッケージをそのまま使用するファンクションに関して は、CSVは軽減できることとなる。 詳しくは、章を改めて解説することとする。
5．バグのあるシステム
市販のパッケージを購入すると「Known Problem」つまり判明している不具合が記載された、リリースノートが添付されている場合がある。 これらは、次のバージョンでフィックスされるか、パッチによって解 決されることが多い。
ソフトウェアにとって、バグ（不具合）はつきものである。そのすべ てを取り除くことは困難を極める。
いわゆる2000年問題は、当時かなりの関心を集めた。しかしながら、2000年問題を正確に理解し、対応方法を適切に検討したといえる企業 はそう多くは無いのではないかと考える。
2000年問題は、西暦の下2桁が99から00に移行することによって、多 くの不具合が生じると懸念された。そこで、それらの不具合を2000年 になるまでに何とか修正しようと考えた人々も多かったのである。
しかしながら、考えてみていただきたい。たとえば地中に埋め込んである、水道管やガス管などのメータに組み込まれているマイクロチップ全部の修理など、短期間でどだいできっこない。それらは時間をかけて交換時に対応することになる。
もし飛行機の計器が、2000年1月1日0時0分に誤作動することが予想されるのであれば、その時間に飛行機を飛ばさないことが最も重要である。これが2000年問題の対処方法である。つまりあらかじめ想定されるリスクを洗い出し、適切な回避策を検討することが大切なことである。
CSVも同様のことが言える。あらかじめ分かっている不具合に関して、運用で回避するなどの適切な対応方法を検討する必要がある。もちろん、バグのある機能は使用してはならない。これがCSVの大切な目的のひとつである。 しかしながら、そのソフトウェア自体を使用できないというわけではないのである。
このような捕らえ方を理解すると、CSVは単なるソフトウェアの受入れテストやバグつぶしのことではなく「業務への適合性の証明」である とする、CSVの目的の意義が理解いただけるものと考える。
