20040621号
■eCompliance News ■□■□■□■□ 2004.06.21発 ■□■
http://www.eCompliance.co.jp
↑ BookmarkはこのURLで!! リンクはフリーです。お気軽に!!
□----------------------------------- by eCompliance -----
http://www.eCompliance.co.jp
■ Headline =================================================
・CSV実践講座 第四回 【SDLCの概要 その１】
・一言アドバイス【品質管理（QC）とは】
**************************************************************
◆配信中止・配信先変更は、support@eCompliance.co.jpまでお知ら
せください。
バックナンバーの閲覧は、以下のＨＰからお願いします。
http://www.eCompliance.co.jp/merumaga
**************************************************************
■□==========================================================
◆CSV実践講座 第四回 【SDLCの概要 その１】
==============================================================
5.SDLC(Software Development Life Cycle)概要
5.1 SDLC(Software Development Life Cycle)とは
FDAは、ソフトウェア・アプリケーションの開発とバリデーションに
対してライフサイクル・アプローチを実施することを求めている。
このライフサイクルは、一般にSDLC(Software Development Life
Cycle)と呼ばれるMethodology（方法論）である。SDLCの"S"は
Softwareをあてるのが一般的であり、Systemではない。何故ならば、
開発を行うのはSystemではなくSoftwareだからである。
ライフサイクルの例として、計画(Planning)→要求(Requirement)→
設計(Design)→製造(Build)→テスト(Test)→移行(Deployment)→利用
(Use)→廃棄(Retire)といったフェーズがあげられる。
SDLCは通常Water Fall Modelと呼ばれ、水が滝を流れるように後戻り
は原則として出来ない。
多くの製薬企業の情報システム部門には、いわゆる「開発標準」とい
う規約文書が存在している。多くの場合開発標準は、ソフトウェア開
発のライフサイクルに基づいて記述されている。しかしながらCSVの
観点で全ライフサイクルが網羅的に記載されているかどうかは疑問が
残る。FDAでは、査察官自体がこのSDLCのメソドロジーに基づいて教
育を受けている。今後の査察においては、このSDLCに則ったドキュメ
ントの整備と整合性がチェックされるものと思われる。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
SDLCにおける活動は、手順書定め実施しなければならない。CSV活動
の証拠として、またどのような選択や決定をしたかを伝えるために、
SDLC活動の適切な記録を、各フェーズについて保持しなければならな
い。原則として記録は、技術面、管理面、そして品質面からのレビュ
と承認を受けなければならない。これらの記録をどの程度詳細にする
かは、当該システムの複雑さや、どの程度の正確な機能の確証が必要
かによって違ってくる。作成された文書は、SOPで定義する役割の者
がレビュや承認を行わなければならない。レビュおよび承認は、署名
の形式をとるのが普通である。
一般的に、SDLCおよび各フェーズにおけるドキュメンテーションは、
下記のようなものが考えられる。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.2 プランニング (Planning)
本フェーズでは、下記の事項を行う。
1) 業務プロセスとシステム化に対する要求事項の文書化
2) バリデーションの必要性の評価
3) バリデーション計画の策定
4) ベンダーオーディットおよびパッケージ調査
5.2.1 業務プロセスとシステム化に対する要求事項の文書化
ユーザが「User Requirements Specification」（ユーザ要求仕様書、
URS）を作成することにより、SDLCが開始される。
URSには、導入するシステムに対するユーザの要求事項を記載し、実
際の業務で必要とする機能や、データ、操作環境を定義づける。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.2.2 バリデーションの必要性の評価（リスク評価）
URSにもとづき、リスク評価を行う。リスク評価にはCompliance
Assessment（規制要件調査）を含め、ユーザの要求するシステムは
Safety（安全性）Efficacy（有効性）Quality（品質）に直接的また
は間接的に影響するかを判定しなければならない。つまりGXPデータ
を扱うシステムであるか否かを判定する。これにより、導入するコン
ピュータシステムが規制の範囲内に入るか否かを決定する。またシス
テムの重要性、複雑性、規模の評価を行う。特に重要性の評価の中で
は、システムが動作しなかった場合や、不具合が起きた場合などのリ
スクを評価する。例えば、システムが1日停止した場合や不具合があっ
た場合、災害によりシステムがクラッシュした場合などの業務に対す
るインパクトを評価する。この評価結果にもとづいて、CSVの程度が
決定される。
筆者はリスク評価は、QAUが実施することが望ましいと考えている。
〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜∞〜
5.2.3 バリデーション計画の策定（バリデーションマスタープラン）
リスク評価によって、規制要件対応と決定したコンピュータシステム
は、バリデートしなければならない。すなわちバリデーションマネー
ジャが必要に応じて指名され、バリデーションマスタープラン（VMP）
を作成することになる。
VMPにはバリデーションに携わる組織、人員構成、期間、必要な文書
類等の定義をはじめ、当該システム導入プロジェクト全体の品質保証
計画を明らかにしなければならない。
バリデーション計画は、リスク評価で評価されたシステムの重要性、
複雑性、規模に応じて妥当とされる程度で策定しなければならない。
VMPはバリデーションの根幹をなす文書であるため、QAUによる事前の
レビュを受けておくことが望ましいと考えられる。事後にQAによる指
摘があった場合、品質保証が出来ないことになるからである。
VMPにおいてプロジェクト期間全体を通して、計画を詳細に記載する
ことは困難である。従って初期の段階では、直近の2フェーズ程度を
詳細に記述し、プロジェクトの進捗に従って逐次加筆していくことに
なる。この場合でもVMPは承認を行い、変更管理計画に従って変更を
管理しなければならない。
（つづく）
★次回は、「SDLCの概要 その２」です。
■□==========================================================
★一言アドバイス
【品質管理（QC）とは】
品質管理とは、顧客の要求を満足させる品質をもった製品を作り出し、
顧客に提供する機能をいいます。日本ではこのQCのことをQuality
Checkと勘違いされているように感じることがしばしばあります。これ
は間違いで、Quality Controlが正しいことはご承知の通りです。日本
の多くの製薬企業においては、データの入力に際して、ダブルエント
リーを用い、また読みあわせを数回行うなどして入力のミス等を修正
しています。しかしながらこの作業はあくまでもCheckであり、QCでい
うところのControlではありません。CheckとControlの違いは明らかで
す。Controlとは、ＳＯＰなどの標準(書）にそって業務プロセスが管
理運営されており、それらを逸脱していると正常に戻す機能のことを
言います。新薬申請後の書面調査においても同様にCheckが行われて
いますが、プロセスに関する品質（管理）はレビュされていないよう
です。これは日本と米国での考え方の大きな違いであるといえます。
ちなみに、ManageとControlは邦訳するとどちらも「管理」となります
が、その違いはこうです。Manageは野球の監督に例えられ、Controlは
投手に例えることが出来ます。つまりManageとは、全体を指揮、統制
（例えば敬遠を指示）する役割であり、Controlとは指示されたとおり
に業務を遂行する（例えばストライクを投げる）ことです。
このことから分かるように、QC担当者の役割は、業務プロセスがＳＯ
Ｐから逸脱した（またはしそうな）場合において、それを指摘し、正
しいプロセスへと誘導することです。決してデータの入力ミスを見つ
けてあげることではありません。一般にデータの入力ミスを入力に責
任を持つ部門ではなく、他の部門（この場合はＱＣ部門）が修正して
いるとすると、プロセス中のデータの品質は向上しにくくなります。
原則は、データソース側がデータの品質に責任を持つことです。
次回は、品質保証（QA）について述べます。
■□====編集後記==============================================
◆先週は南の島へ行ってたものですから、メルマガはお休みしてしま
いました。すみません。
その間にも、配布希望のメールを多く頂き、大変お待たせしました。
今週は、仕事に戻るためにリハビリをしなければなりません。
台風が来ているようですが、皆様お気をつけくださいね。
【 重要事項 】
★本メルマガに記載の原稿の著作権は(有)イーコンプライアンスにあり
ます。
★本メルマガの全部または一部を引用する際には、事前にご連絡をお願
いします。
----*----*----*----*----*----*----*----*----*----*----*----*--
■□■□ ご意見・ご質問の寄稿をお待ちしています ■□■□
----*----*----*----*----*----*----*----*----*----*----*----*--
●質問大募集!!
★教えてＣＳＶ！
★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/
===============================================================