くすりのこと
研究開発
個別業務
ＩＴ
ITと医薬品開発
ソフトウェア
プログラミング
バリデーション
セキュリティ
標準化・用語
広報・教育
団体・組織

ER/ES（厚生労働省）やFDA 21 CFR Part 11（米国）では、該当する業務に使用するコンピュータシステムはCSV（Computerlized Sysytem Validation）が実施されていることが前提になっています。 　CSVは、「システム開発」から「システムの廃棄」にいたるシステムライフサイクルすべてにわたって、医薬品、医療機器にかかわるコンピュータの妥当性を証明することです。 　CSVの達成には「品質保証のプロセス」についての十分な理解が必要です。
Page Index
	情報BOX コンピュタシステムの 品質保証について コンピュータシステムの 信頼性に関するガイドライン CSV指針について GAMP4について CSVに対する準備 参考になるサイト
	（別ページへジャンプ）
	電子記録、電子署名に関する法令 （ER/ES） FDA 21 CFR Part 11
情報BOX ↑　このﾍﾟｰｼﾞの最初へ
	テストの重要性に目覚めたCIOに贈る「9つの教訓」と「5つの質問」　CIO Online、2006年7月2日 　ソフトウェア・プロジェクトにおいて、「テスティング」は非常に重要な工程であるにもかかわらず、なぜか軽視されがちである。多くの企業が、テスティングのための予算や時間、人材を十分に用意しているとは言い難い状況にある。だが、CIOであれば、心の奥ではだれもがそんな現状を憂えているはずだ。そこで本稿では、テストの重要性に目覚めたCIOのために、多くの米国企業への取材から得ることのできた、テスティングの水準を高めるための「9つの教訓」と、CIOがテスティングの問題点を把握するためにテスト責任者に発すべき「5つの質問」を紹介することにしたい。 　 プロセスでつくりこむソフトウェアの製品品質　NTTソフトウェア 　これまで企業ごとに個別に取り組まれてきたソフトウェアの品質保証の取り組みについても、近年、品質保証プロセスの標準化や第三者機関による品質保証能力認証の方向に活発化してきている。ソフトウェア開発における品質保証とは何か。 ISO9001の取得も含め、NTTソフトウェアでの取り組みを例に、そのポイントを紹介する。 　 プログラムの品質と信頼性　ユートラム　2003年 　プログラムの品質の問題を、プログラムミングの技法にとどまらず品質マネージメントシステムにまで広げ考えている 　 阪南大学経営情報学部教授　玉置彰宏HP　「ソフトウェア工学の勧め」より 　・ソフトウェアの品質について 　・高品質のソフトウェアを作る方法 　・ソフトウェアの品質保証 　・ソフトウェアプロセス 　 プロジェクトマネジメントの無償のトレーニングやテンプレートツール　マイクロソフト 　Project 2003 を初めて使う方に参考になる情報や、プロジェクトマネジメントを促進するツールを紹介
コンピュータシステムの品質保証について ↑　このﾍﾟｰｼﾞの最初へ
	品質には、次の３つの保証があります 　（１） 成果物そのものを保証する 　　　　たとえばテストによって要求仕様を満足することを確認することなどがあります。 　　　　目視やダブルプログラミング、二重入力で成果物を確認する方法もこれに入ります。 　（２） 品質プロセスを保証する 　　　　ソフトウェア開発の各プロセスにおいて“不具合”が産み出されない仕組みを構築しそれを保証すること 　　　　です。成果物そのものを保証する行為もプロセスの一部と考えられるのでこれを含む考えもあります。 　（３） 品質システムを保証する 　　　　品質プロセスのマネジメント・システムの質を保証することです。 　　　　品質は作りこむものであるために、時には“不具合”をも作りこむこともあります。 　　　　さらに外部環境の変化により折角構築した品質システムも劣化します。 　　　　そのため、品質システムをいかに計画的に改善できるかが重要になります。 上記のそれぞれについて、複数のの具体的な手法・考え方が提案されていますが、企業が定めた「達成すべき品質目標（最低限のライン）」を実現するために、企業の持つ事業資産（人的、物的）と、上記の3つの保証手段をどのように組み合わせれば良いかということを検討します。 なお、「成果物そのものを保証する」方法のみに頼っているケースが多くの企業で見られますが、これは達成のためのコストが高くなり、改善が反映されないという重大な問題を含んでいます。 また、注意したいのは、アンダースペックも問題ですが、決してオーバースペックにならないことです。企業の実態はそれぞれ異なるものですし、品質のレベルは上へ近づけば近づほどコストがかかる性質があります。 　ポイント 　　　・「品質保証のプロセス」の理解 　　　・企業実態の把握 　　　・「達成すべき品質目標（最低限のライン）」の設定
コンピュータシステムの信頼性に関するガイドライン ↑　このﾍﾟｰｼﾞの最初へ
	情報システムの信頼性向上に関する評価指標（試行版）　経済産業省、2007年4月13日 　「情報システムの信頼性向上に関するガイドライン」を受けて、当該ガイドラインの遵守度合いを測る評価指標の検討を行ってきました。この度、本検討結果を踏まえ、「情報システムの信頼性向上に関する評価指標（試行版）」を策定いたしましたのでその内容を公表いたします。 　 情報システムの信頼性向上に関するガイドライン　経済産業省、2006年6月15日 　情報システム障害の社会的影響が日々、深刻化してきていることを受け、「情報システムの信頼性向上に関するガイドライン」の検討を行ってきました。この度、案に対するパブリックコメントの結果を踏まえ、同ガイドラインを策定いたしましたのでその内容を公表いたします。 　 工業標準化法に係る「電磁的方法による保存をする場合に確保するよう努めなければならない基準　厚生労働省、農林水産省、経済産業省、国土交通省省、2005年3月30日 　　 情報セキュリティポリシー・サンプル0.92a版　NPO日本セキュリティネットワーク協会 　ＪＮＳＡのポリシーＷＧ（ワーキンググループ）ではポリシー・サンプル（０．９２版） を作成し、ソフトバンク パブリッシングの月刊誌である「N+I NETWORK Guide」の２００２年６月号から翌１月号までの全８回の連載記事を執筆し、ポリシー・サンプル解説書にしました。 　　 システム監査基準、システム管理基準　経済産業省、2004年10月8日 　情報技術の浸透や技術革新の影響により、企業経営におけるＩＴ投資の目的が、単なる現場の合理化から経営そのものの革新へと大きく変化しつつある中、経済産業省においては、国際的な最新動向も踏まえつつ、昭和６０年に策定した「システム監査基準」を改訂し、新たな「システム管理基準」及び「システム監査基準」を策定しました。
CSV指針について ↑　このﾍﾟｰｼﾞの最初へ
	内外のCSV指針
	コンピュータ使用医薬品等製造所適性管理ガイドライン　経済産業省、1992年 　医薬品など製造所において利用されるコンピュータを対象として、開発および運用管理の２つの段階に分け、遵守すべき事項をそれぞれ定めています。 　 　　平成17年3月30日 通知（薬食監麻発第０３３０００１号）の施行に伴い廃止されました。 Guide To Inspection of Computerized Systems in Drug Processing　FDA、1983年 　FDA査察官向けのガイドライン。コンピュータを利用する製薬工場を査察官が査察する際に、そのフレームワークを提供することを目的としています。 　 PMA Computerized Systems Validation　米国製薬工業協会、1990年 　PMA発行のCSVのガイドライン。 　 General Principles of Software Validation; Final Guidance for Industry and FDA Staff　FDA、2002年1月 　医療機器の設計、開発、製造に使用されるソフトウエアのバリデーションの原則を記述しています。 　 Guidance for Industry / Computerized Systems used in Clinical Investigations　FDA、2007年5月 　臨床試験向けのCSVガイドライン。治験におけるコンピュータの使用使用に関し、臨床試験データとして維持管理、あるいはFDAに提出求められるデータを使用するコンピュータに関するガイドラインとして提供されています。 　 GAMP4（Good Automated Manufacturing Practice Version 4）　ISPE(日本語呼称：国際製薬技術協会） 　GAMP4はコンピュータやプロセス制御システム等の適格性評価やバリデーション技術を実践する実用的な規範ガイドとして、FDAをはじめ世界中の規制当局やヘルスケア産業において広く使われています。 　　GAMP FORUM 　　WHAT'S NEW IN GAMP4 　　ISPE - Japan
GAMP4について ↑　このﾍﾟｰｼﾞの最初へ
	CSVのガイドとしては、国際的に広がりつつある「GAMP4」が良く利用されますが、GAMPはもともと自動化システム向けのものとして考えられたものであるため、業務系システムに適用するには、言葉の定義などしっくりしない点が見受けられられます。品質プロセスを理解しながら柔軟な対応をすることも必要になってきます。
	ソフトウェアカテゴリー、ハードウェアカテゴリー 　GAMP４はソフトウェアとハードウェアをそれぞれ以下のカテゴリーに分類しています。 　カテゴリーの数字が大きいほど、バリデーションの要求が高度になっています。 　　ソフトウェアカテゴリー 　　　・Category1　　Operating Systems 　　　・Category2　　Firmware 　　　・Category3　　Standard Sofoware Pakages 　　　・Category4　　Configurable Softawre Pakages 　　　・Category5　　Custum Software 　　ハードウェアカテゴリー 　　　・Category１　　Standard Hardware Components 　　　・Category2　　Custum Built Haerdware Components 　 ライフサイクルアクティビティとドキュメンテーション GAMP４はソフトウェアライフサイクル（ソフトウェアの企画から廃棄まで）におけるアクティビティ（作業）とドキュメンテーションを以下のように定めています。 　 １．管理 　　　・Project Document Management 　　　・Project Change Control 　　　・Project Traceablity Matrix 　　　・Project Configuration Management 　　　・Design Review and Continued Risk 　　　 　　　　　　　　　　　　　　　　　Asesessment 　 ４．適格性試験（品質保証） 　　　・Installations Qualifications(IQ) 　　　・Operational Qualifications(OQ) 　　　・Process Qualifications(PQ)☆ 　　　・Validation Report(VR) ２．計画☆ 　　　・Validation Plan(VP) 　　　・Vendor Prelimirary Assessment 　　　・Risk Assessment + Clitical Parameters 　　　・User Requirements Specifications(URS) 　　　・Specifications Approval 　　　・Supplier Detained Assessment ５．運用・保守☆ 　　　・Change Control 　　　・Service Level Agreement(SLA) 　　　・Periodic Review 　　　・Performance Monitoring 　　　・System Security 　　　・Record Retention 　　　・Backup And Recovery 　　　・Business Continuity Planning 　 ３．設計・制作・テスト 　　　・省略 ６．廃棄☆ 　　　・Retirement 　　　　　　　　　　　　　☆　User Responsibility 　 ワンポイントアドバイス by BPPonline 　 （１）管理・計画 　導入プロジェクト初期においては、バリデーション計画書を作成します。バリデーションに必要な組織や期間、必要な文書の定義などを行い、プロジェクトとしての品質保証計画を作成します。また、プロジェクトの途中で変更が生じた場合の手続きを文書化（Change Control Plan）する必要があります。 　要求の取りまとめ段階では、URS（User Requirement Specification）を作成します。URSには、多くの場合に機能レベルでのリスク管理をおこなうFRA（Functional Risk Assessment）を含めます。 　製品選定ではURSに基づいて RFP（Request for Proposal）を作成します。導入するシステム（とくにパッケージ部分）の規制対応について調査する責務は発注側にあるため、ソフトウェア・ベンダーはユーザーの査察を受けることがあります。 （２）設計・制作・テスト 　製品選定後、設計をおこなってDesign Specificationsを作成します。同時に、URSを実現するための仕様として、FS（Functional Specifications（ソフトウェア））およびTS（Technical specifications（ハードウェア））が作成されます。 システムの導入にあたり、テスト仕様書を作成してテストをおこない、テストの結果報告書を作成します。 （３）適格性試験（品質保証） 　この段階では、品質保証のためのテストをおこないます。TSに対してはIQ（InstallationQualification、FSに対してはOQ（Operation Qualification）、URSに対してはPQ（Performance Qualification）を実施します。 （４）運用・保守 　システムの運用にあたっては、SOPとして標準とする業務プロセスを文書化しておく必要があります。SOPに基づいて、導入されたシステムに関する教育をおこなう必要があります。教育に関する文書としては、トレーニング・プラン、カリキュラム、教育記録などがあります。 （５）システム移行 　システムの移行にあたっては、とくにデータの正確な移行を保証する必要があります。データ移行にあたっては、旧システムに蓄えられた監査証跡も含めて作業をする必要があります。また、データ移行に使用するプログラムについても、バリデーションを実施します。移行作業の実施に際しては、移行作業の手順書およびデータ移行結果報告書を作成します。