20040823号

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

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

・【いよいよ来週開催!!】CSVセミナーのお知らせ
・CSV実践講座 第八回 【SDLCの概要 その5】
・一言アドバイス【リスクベースアプローチ】

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

■□====セミナーのお知らせ====================================

GAMPではわからない実際のCSVドキュメンテーション!!
【セミナー資料はCD-ROMで配布】

日時:平成16年8月31(火)10:00〜16:30
会場:[東京・五反田] ゆうぽうと
内容:
1.CSV概要
    ・CSVの目的とゴール
    ・規制当局の懸念とは
    ・SDLC(Software Development Life Cycle)概要
    ・IQ,OQ,PQの考え方
    ・作成すべきドキュメント
2.CSVドキュメンテーションの実例
    ・バリデーション計画書の作成方法と実例
    ・ユーザ要求仕様書の作成方法と実例
    ・機能仕様書の作成方法と実例
    ・設計仕様書の作成方法と実例
    ・IQ、OQ、PQ文書の作成方法と実例
    ・バリデーション報告書の作成方法と実例
    ・その他ドキュメント作成における留意点
3.CSV SOPの実例と作成上の注意点
    ・作成すべきCSV SOPの種類
    ・CSV SOPの実例

割引特典つき申込書はこちら↓
http://www.ecompliance.co.jp/seminar/408122.pdf

■□==========================================================
◆CSV実践講座 第八回 【SDLCの概要 その5】
==============================================================
5.6.1 コンピュータシステム導入
コンピュータシステム(クライアント及びサーバー)を導入し、正式
なテスト環境を設定する。
設計仕様書(DS)に従って、準備されたプラットフォームが正確に稼
働し、その要求を満たすことを検証するテストをIQ(Installation
Qualification)と呼ぶ。IQでは、作成されたIQスクリプトをもとに、
ハードウェアの設置、OSやデータベース等のインストレーション、ソ
フトウェアの導入を行い、その結果をIQ報告書(インストレーション
結果報告書)として作成する。

IQ計画書の目的は、指定された環境でのコンピュータシステムのイン
ストール手順を記載することである。記載する事柄は、インストール
過程、実施作業の証拠文書(ログ)の作成、及び成果の確認である。
ハードウェアのIQ計画書は、コンピュータシステムが完全な形で購入
された場合でない時、あるいはコンピュータシステムの組立や修正が
必要とされる場合に必要に応じて十分なレベルで記載すること。

IQスクリプトの目的は、実行するインストレーション手順を指定し、
IQログを作成できるようにすることである。

IQログの目的は、IQスクリプトが実行されたことの証拠書類として実
施記録を作成することである。
IQログはIQスクリプトを実施することによって作成される。
IQログは承認されたIQスクリプトのコピーを使用し、実施結果を記録
し、注釈をつけ、すべてのテスト結果を添付または参照し、IQスクリ
プトを正確に実施したことの証拠書類を揃えること。
IQログはその後IQ報告書にて要約すること。

IQ報告書の目的は、インストールの成功と障害の概要、インストール
された設定項目の概要、及び例外記録とその分析を記載することであ
る。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.6.2 包括的なテストの特定と全ての正式なテストの実施
機能仕様書(FS)に従って、要求された機能が実現されていることを
検証するテストをOQ(Operation Qualification)と呼ぶ。このOQテス
トのことをシステムテストと呼ぶ場合がある。
全ての機能をもれなくテストすることは実際上不可能に近い。そこで
筆者は、ファンクショナル・リスク・アセスメント(FRA:URS⇔FS間
のTraceability Matrixを用いて、各機能および業務のリスクを評価
したマトリックス メルマガ20040629号を参照)においてHigh Risk
とされた機能に関するOQを優先的に実施することを勧めている。
Middle RiskおよびLow Riskとされた機能に関するOQ実施は任意として
もかまわない。このことはFDAが指導しているリスクベースアプローチ
という考え方にも合っている。

OQ計画書の目的は、システムの特定の各機能において実施しなくては
ならないテストを定義することである。
OQ計画書では各機能及び当該の各機能において実施するOQケースの一
覧表を作成すること。
OQ計画書は承認されたテスト計画書に従って作成すること。

OQスクリプトの目的は、システムで実行するOQテスト手順を指定し、
OQログを作成できるようにすることである。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.6.3 テスト結果の記録とレビュ(OQログ、OQ報告書)
OQログの目的は、OQスクリプトが実行されたことの証拠書類として実
施記録を作成することである。
OQログはOQスクリプトを実施することによって作成される。
OQログは承認されたOQスクリプトのコピーを使用し、実施結果を記録
し、注釈をつけ、すべてのテスト結果を添付または参照し、OQスクリ
プトを正確に実施したことの証拠書類を揃えること。
OQログはその後OQ報告書にて要約すること。

OQ報告書の目的は、機能テストの成功と障害の概要、及び例外記録と
その分析を記載することである。またOQ計画書からの逸脱を要約する
こと。
OQで発生した不具合は、別途障害記録として記録し、変更管理計画書
に従って、変更管理を実施すること。さらに変更は変更記録として記
録すること。

ちなみに筆者はOQは、必ずしも製薬会社側で実施する必要はないと考
えている。また実機で実施する必要性もないものと思っている。
なぜならば、機能のテストはH/WやOSの環境が同じであれば、どこで
テストしても同じ結果が得られると思われるからである。
従って、OQはベンダーに外注しても良いものと考えられる。
ただし、他のシステムや特殊な装置などを実際に接続しなければなら
ない場合は、実機で行わざるを得ない。この場合も実施自体はベンダ
ーに委託しても良い。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.6.4 運用環境の安定性の保証
ユーザ要求仕様書(URS)に対して、要求された要件が実現され、稼
働できることを検証するテストをPQ(Performance Qualification)
と呼ぶ。しばしばこのPQはその名前から、コンピュータやネットワー
クのパフォーマンス試験のことと誤解されることがあるが、そうでは
ない。ユーザの業務プロセスが、コンピュータ化により要求に応じて
滞ることなく実現できるか(パフォームするか)を検証するのがPQの
目的である。従って、PQはユーザが実施することになる。このPQテス
トのことをユーザ・アクセプタンス・テスト(UAT)と呼ぶ場合がある。

PQはシステムがユーザ要求仕様書を満たし、ユーザに受け入れられ、
本来の目的に合っているかどうかを判断するために実機のシステム上
で実施すること。

PQ計画書は、システムがユーザが要求した本来の目的に合っているか
どうかまた要求した性能が発揮できるかどうかを検証できるようなテ
ストを定義する。

PQシナリオは、システムで実施されるPQテストのパターンを記載する。
これはシステム化後に実際にシステムを利用して実施される業務プロ
セスの何通りかのワークフローである。

筆者は、OQと同様、FRAにおいてHigh Riskとされた業務に関するPQを
優先的に実施することを勧めている。Middle RiskおよびLow Riskと
された業務に関するPQ実施は任意としてもかまわない。従って、PQシ
ナリオにおいてできる限りHigh Riskな業務を包含するようなワーク
フローを指定するとPQ実施の効率が高くなる。

PQスクリプトは、システムで実施されるPQテストをシナリオに沿って、
その実施ステップを指定する。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.6.5 コンプライアンスリスクの重要なプロセスの評価
PQスクリプトの実施により、PQログを作成すること。
PQスクリプトは複数回繰り返される場合があり、よって、一つのPQス
クリプトから複数のPQログが作成されることもある。
PQログの目的は、PQテストを実施したという文書化した証拠を提示す
ることである。
PQログは承認されたPQスクリプトのコピーを使用し、実施結果を記録
し、注釈をつけ、すべてのテスト結果を添付または参照し、PQスクリ
プトを正確に実施したことの証拠書類を揃えること。
PQログはその後PQ報告書にて要約すること。
PQ実施に関して大切なことは、OQはシステムをテストすることである
のに対し、PQはシステムを利用した業務をテストすることである。
従って、PQは決してシステムのバグの発見を目的とするものではない。
もしPQ実施中にバグを発見した場合には、即座にPQを中止し、OQを再
実施すること。このことを理解しないと、OQとPQに違いがなくなって
しまう。
PQでは、OQによりバグが取り除かれたシステムを利用して、業務が実
際に滞りなく遂行できるかどうかをテストすることに意義がある。
筆者がよく経験するのは、PQログをレビュしていると「問題なし」と
記載している場合が多々ある。これは当たり前であり、OQを適切に実
施しておれば問題はないはずである。PQをユーザが実施する意義は、
システムを業務で実際に使用した際に、何らかの落とし穴がないかど
うかを検証できることにある。IT部門の担当者では実際の業務を想定
しその落とし穴を見つけることは一般的に難しい。

PQ報告書の目的は、実行されたPQ実施を要約し、PQ計画書からの逸脱
を記述することである。
PQ報告書では、実稼動後のコンピュータ化された業務プロセスのリス
ク(業務上の落とし穴)を特定し、リスク軽減のための施策を検討す
ること。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
(つづく)

★次回は、「SDLCの概要 その6」です。

■□==========================================================
★一言アドバイス
【リスクベースアプローチ】
FDAは、cGMPにおいて、リスクベースアプローチを推奨しています。
これは、全ての電子システムやその機能を満遍なくバリデーションや
Part11の対応範囲とするのではなく、重要度の高いものから順次対応
することです。
FDAが査察を実施する際に、限られた日にちでは昨今のIT時代におい
ては、全てを調査することなど土台無理といえます。
そこで、より重要度(リスク)の高いシステムの、より重要度の高い
機能から調査するという方針が出されたわけです。
このことはバリデーションを行う製薬会社側でも同様のことが言えま
す。
FDAにとってみれば、バリデーション作業を1から順番に対応して、ハ
イリスクの機能を後回しにされるよりも、例え全てではなくともより
ハイリスクなものを至急対応している方が好ましいということです。
したがって、バリデーションやPart11対応を行う際には、まずリスク
調査を十分に行ってから開始することが望まれます。

■□====編集後記==============================================
◆仕事がら、東京と大阪を行ったりきたりしています。その際に一番
戸惑うことは、エスカレータでの立ち位置です。
ご存知と思いますが、東京では左側に立ち、大阪では右側です。
聞くところによると、大阪で1970年に万国博覧会が開催され、日本で
始めて歩く歩道が設置されました。
万博では世界中の人々が集まってくるわけですから、開催委員会が世
界中の立ち位置を調査したそうです。
その結果、圧倒的に右側に立つことが多かったそうなんです。
つまり大阪の方が”グローバルスタンダード”なんですね。
のりこ

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

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

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

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

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