■eCompliance News ■□■□■□■□ 2004.06.03発 ■□■
http://www.eCompliance.co.jp
↑ BookmarkはこのURLで!! リンクはフリーです。お気軽に!!

□----------------------------------- by eCompliance -----
　　　　　　　　　　　　　　　　　 http://www.eCompliance.co.jp

■　Headline =================================================

・CSV実践講座　第２回　【CSVの概要 その１】
・一言アドバイス【PQの目的】

**************************************************************
◆配信中止・配信先変更は、support@eCompliance.co.jpまでお知ら せください。
バックナンバーの閲覧は、以下のＨＰからお願いします。
http://www.eCompliance.co.jp/merumaga
**************************************************************

■□==========================================================
◆CSV実践講座　第2回　【CSVの概要 その１】
==============================================================
1. そもそも何故CSVが必要か
現在CSVを担当している人々や、これからCSVを実施しようとする人た ちにとって、一番大切なことは、なぜCSVが重要であり、必要なのかを 理解することである。
CSVの重要性について、規制当局の視点、経営者の視点、システムのユ ーザの視点から解説をしてみたい。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
1.1 規制当局の懸念とは
規制当局（主にFDA）の懸念は「Principle: Data quality and quality assurance should not decrease when a computerized system replaces a paper operation.」（原則：データの品質および品質保証 は、紙ベースのオペレーションがコンピュータ化された際に劣化しては ならない）ということである。
規制当局にしてみれば、製薬会社がコンピュータシステムを利用しよう がしまいが、そんなことはお構いなしである。ましてや、どこの何とい うソフトウェアを利用しているかなんかは、ほとんど関心が無いのであ る。
よく「うちの会社は、どこもが使っている○○というソフトウェアを利 用しているから、大丈夫だ。」といったような意見を聞く。FDAにとって は「So what ?」である。
FDAの関心ごとは、上記の原則にあるように、当局へ提出されるデータの 品質や品質保証が、紙ベースのオペレーションがコンピュータ化された 際に劣化していないかどうかということである。いいかえれば「システ ムの業務への適合性の保証」を求めているのである。
つまり、このことがFDAなどの規制当局のCSVへの期待である。
この「システムの業務への適合性の保証」というフレーズは、本書にお いて後ほど何度か出てくるので、ぜひ念頭においていただきたい。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
1.2　経営者の関心とは
コンピュータシステムの導入は、当然のことながら投資である。
企業の経営者にとって、いわゆるROI（Return on Investment）が関心 ごととなる。たとえば「投資に見合った業務品質とデータ品質が得ら れるのか」といったことなどである。
また、紙での記録同様「重要なデータが保護されているか」という ことには特に気を払わなければならない。さらに、コンピュータにお ける最大のリスクとして「何らかの災害の際に、復旧が可能である か」ということである。
当然のことながら「社内の監査や、当局の査察に合格することがで きるのか」ということも一般に高い関心ごとである。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
1.3　ユーザの視点とは
コンピュータシステムを利用するユーザにとって「安心して業務が 遂行できるか」ということが最大の関心ごとであると思われる。
せっかく作成した申請資料が消えてしまっては困るし、研究会などの 前日にシステムが停止されては大変である。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
1.4　CSVの必要性
上述したように、規制当局の視点、経営者の視点、システムのユーザ の視点それぞれにおいて、コンピュータシステムへの各種の懸念を払 拭することが大切である。
このようなことから、CSVが必要になってくるのである。
ともすると、当局の査察に備えるためにCSVを実施しようとする企業が あるが、これでは本末転倒である。
CSVの必要性は、業務をコンピュータ化することによって何らかの問題 が発生しないかという懸念を払拭することにある。例えば、 １．電子データは信頼できるものであるか ２．コンピュータ化された業務がきちんと管理できているか ということも関心事としてあげられる。
==============================================================
2. CSVの目的
CSVの必要性は理解していただけたと思うが、次にCSVの目的について
考えてみたい。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.1　5つの質問
筆者が経験する、多くの間違ったCSVの理解を参考に、5つに質問をし てみたい。それぞれ「YES」か「NO」で答えていただきたい。
　 1. バリデーションとは、システムの受入れ試験のことである。
　 2. バリデーションの目的は、品質保証である。
　 3. 市販のパッケージは、バリデーションが不要である。
　 4. パッケージのバリデーションは、自社開発に比べて簡単である。
　 5. バグのあるシステムは使用してはならない。
いかがであろうか。本セクションでは、上記の質問に対する解答を行 いながら、CSVの目的を明らかにしてみたい。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.2 バリデーションはシステムの受入れ試験ではない
かつてのバリデーションは「Computer System Validation」（コンピ ュータシステムのバリデーション）であり、テストのことと同義であ った。
今でも、バリデーションはシステムの受入れ試験（テスト）のことで あると考えている人も多いと思われる。
しかしながら、現在では「Computerized System Validation」（コン ピュータ化されたシステムのバリデーション）が主流となっている。 つまり、コンピュータ化された業務プロセスのバリデーションが求め られているのである。
FDAのほとんどのガイドラインには「Computerized System」とあるこ とに注意していただきたい。
この業務プロセスの一部をコンピュータ化する際の導入プロジェクト は通常、計画→要求→設計→製造→テスト→運用というステップを踏 むことが一般的である。このステップを一般にSoftware Development Life Cycle（SDLC）と呼ぶ。このライフサイクル全体がCSVの対象範囲 となる。SDLCに関しては別の章で解説する。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.3　バリデーションの目的は品質保証である
品質とは何か、また品質保証とは何かに関しては、説明が難しい。
詳しくは章を改めて解説を行うが、ここでは簡単にふれておく。
まず品質とは、顧客の望む基準、顧客側の条件のことである。品質は 通常、名詞で表現される。
製薬業界における顧客とは、患者、医師、医療機関や規制当局などが あげられる。
特に新薬の申請に関しての顧客は、規制当局である。申請資料の品質 は当然、規制当局の期待に沿うもので無ければならない。
申請資料で扱うデータは、薬剤の「安全性」「有効性」「品質」に関 するものであり、人の健康に幅広く関係するもので最高の品質と完全 性がなければならない。
では品質保証は何かというと、品質にいわゆる「お墨付き」を与える ことである。第三者が見て、確かに要求される品質が達成できている という文書化された証拠を元に、保証を行うのである。
バリデーションの目的はまさに、品質保証であるといえる。
筆者がコンサルテーションを経験した大手外資製薬会社ではバリデー ション計画書のことを、Project Quality Plan（プロジェクト品質計 画書）と呼んでいる例がある。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.4　市販のパッケージのバリデーション
筆者は長年にわたり、臨床試験管理システムや臨床データ管理システ ム等のアプリケーションシステムを開発、サポートしてきた経験を持 つ。その際にある製薬企業の情報システム部員から「パッケージシ ステムをカスタマイズしないで導入するのだから、バリデーションは 不要ではないか」という指摘を受けたことがある。つまり彼は、バリ デーションとはコンピュータシステムの導入テストあるいはソフトウ ェアの不具合（バグ）の発見のことであると考えているのである。こ れは言うまでもなく間違いである。
前述したとおり、FDAは単にコンピュータシステムにバグや不具合の ないことを要求しているのではない。紙ベースのオペレーションがコ ンピュータ化された際に、申請に関係するデータの品質および品質保 証が、劣化しないという保証を求めているのである。
システムの「業務への適合性」についての最終的な責任は製薬企業に あるのである。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.5　パッケージは自社開発よりCSVが容易である
パッケージを導入する際に、間違ってはならないことは、そのパッケ ージのバグの発見や修正を、自社のリソース（人、時間、金）を使っ て行うべきではないということである。
パッケージ自体のバリデーション（品質保証）は、その製造元のベン ダーによって実施されるべきである。
したがって、製薬企業におけるパッケージのCSVは、その多くをカス タマイズ部分（コンフィグレーションを含む）に対して行うことにな る。つまり、パッケージをそのまま使用するファンクションに関して は、CSVは軽減できることとなる。
詳しくは、章を改めて解説することとする。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
2.6　バグのあるシステム
市販のパッケージを購入すると「Known Problem」つまり判明している 不具合が記載された、リリースノートが添付されている場合がある。
これらは、次のバージョンでフィックスされるか、パッチによって解 決されることが多い。
ソフトウェアにとって、バグ（不具合）はつきものである。そのすべ てを取り除くことは困難を極める。
いわゆる2000年問題は、当時かなりの関心を集めた。しかしながら、 2000年問題を正確に理解し、対応方法を適切に検討したといえる企業 はそう多くは無いのではないかと考える。
2000年問題は、西暦の下2桁が99から00に移行することによって、多 くの不具合が生じると懸念された。そこで、それらの不具合を2000年 になるまでに何とか修正しようと考えた人々も多かったのである。
しかしながら、考えてみていただきたい。たとえば地中に埋め込んで ある、水道管やガス管などのメータに組み込まれているマイクロチッ プ全部の修理など、短期間でどだいできっこない。それらは時間をか けて交換時に対応することになる。
もし飛行機の計器が、2000年1月1日0時0分に誤作動することが予想さ れるのであれば、その時間に飛行機を飛ばさないことが最も重要であ る。これが2000年問題の対処方法である。つまりあらかじめ想定され るリスクを洗い出し、適切な回避策を検討することが大切なことであ る。
CSVも同様のことが言える。あらかじめ分かっている不具合に関して、 運用で回避するなどの適切な対応方法を検討する必要がある。もちろ ん、バグのある機能は使用してはならない。これがCSVの大切な目的 のひとつである。
しかしながら、そのソフトウェア自体を使用できないというわけでは ないのである。
このような捕らえ方を理解すると、CSVは単なるソフトウェアの受入れ テストやバグつぶしのことではなく「業務への適合性の証明」である とする、CSVの目的の意義が理解いただけるものと考える。

（つづく）
★次回は「CSVの概要 その２」です。

■□==========================================================
★一言アドバイス
【ＰＱの目的】
私が経験してきたCSVで最も大きな関心はPQに対する誤解です。
あるベンダーのコンサルタントが「PQはPerformance Qualification の略で、コンピュータのパフォーマンスをテストします。」といった 人がいました。
とんでもない誤解ですね。
では、皆様はOQとPQの違いを説明できるでしょうか?
OQは主にシステムのテストを行い、PQはシステムのユーザ業務への適 合性をテストします。
もっと平たく言うと、OQではバグを発見し、修理（または回避）しま す。PQでは、原則OQによってバグが取り除かれた後に、業務が遂行出 来るかどうかをテストします。
よく、PQでバグを見つけることに張り切っている人を見ますが、間違 いです。もしPQ中にバグを見つけたら、OQに差し戻すことが正解です。
また多くのPQ Logでは「異常なし」と記載しているケースを見かけま すが、これも勘違いです。OQをちゃんとやっている限り「異常」は無 いはずですから。
PQでは、異常の無いシステムが更に業務使用に耐えるかどうかを検証 します。いわゆる業務上でのリスク評価（業務の穴の発見）を行いま す。したがってPQは業務を知っているユーザが行うのが適切です。
よく「仕様は満たしているが使えないシステム」を見かけますが、CSV をきっちりとやっていれば、そんな事態は防げるはずです。
詳しくは、CSV講座で解説します。

■□====編集後記==============================================
◆当社事務所の近所にある蒲田の某ファミリーレストランに行ってき ました。いわゆる「ファミコン言葉」（ファミレス・コンビニ言葉） が頻発していました。
1.「ご注文は以上でよろしかったでしょうか？」
2.「スープのほうになります。」
3.「10,000円からお預かりします。」
等ですね。
1.は何で過去形で話すのでしょうか?　一説によると外資ファミレスが 英語のマニュアルを直訳したのが原因ということですが、定かではな いようです。
2.は理解に苦しみます。何で"ほう"なのか、また待っていたら勝手に スープに「なる」のか...
3.は、私からお金を預かったわけで、1万円札から預かったわけではな いですよね。
私たちコンサルタントは、人様の前で話すことが仕事ですので、正確 な日本語を使えるように日々勉強しなければと思う今日この頃です。

■□==========================================================
【 重要事項 】
★本メルマガに記載の現行の著作権は(有)イーコンプライアンスにあり 　 ます。
★本メルマガの全部または一部を引用する際には、事前にご連絡をお願 　 いします。
----*----*----*----*----*----*----*----*----*----*----*----*--
　 ■□■□　ご意見・ご質問の寄稿をお待ちしています　■□■□
----*----*----*----*----*----*----*----*----*----*----*----*--
●質問大募集!!
★教えてＣＳＶ！
★Part11はどうなるの？

■投稿先■
　 support@eCompliance.co.jp

※投稿の際には、住所、氏名、年齢、職業、電話番号、メールアドレ ス、ペンネームをお忘れなくお書き添えください。なお、この情報は 弊社が厳重に管理し、一切公開することはありません。

■□==========================================================
発行：有限会社イーコンプライアンス
住所：〒105-0044 東京都大田区仲六郷4-3-16
電話：050-3047-3410
●編集長 N Kihara

E-mail support@eCompliance.co.jp
Presentation URL http://www.eCompliance.co.jp/
===============================================================