システムライフサイクル(SDLC)の詳細(その1)

1. はじめに

CSVは、文書化された証拠をもって、システムの信頼性を保証することがそのゴールである。すなわち文書の作成がCSVV活動の中心となるのである。したがって、文書そのものの品質がすなわちシステムの品質に大きく影響することになる。
CSVで作成される文書には、多くの種類がある。各社のSOPの定義によってその数は異なるであろうが、おおよそ1システムあたり25〜50種類の文書を作成する必要性がある。
それぞれの文書には、それぞれの目的があり、その内容は基本的には重複しない。すなわち各文書には「個性」があるのである。
CSV文書は専門文書であるので、誰でもが容易に書き下ろせるものではない。

一般的にCSVを実施するためには、以下のスキルが必要とされる。

1. ITのスキル
2. ユーザ業務に関するスキル
3. 規制要件（バリデーション、ER/ES指針）に関するスキル
4. 品質保証に関するスキル

1人でこれら4つのスキルをあわせ持つことは困難である。
したがって、CSV文書のような専門的で、多種多様な知識を必要とする文書の執筆には、これら4つのスキルを持った人々の共同作業で行われるべきである。いわゆるスキルミックスで執筆するのである。
たとえば、バリデーション計画書をバリデーションマネージャが執筆したとしよう。バリデーションマネージャは（人にもよるが）一般的にはバリデーションの知識を持っているが、その他の3つのスキルに対しては専門ではない。そこで、それらスキルの不足分を、プロジェクトマネージャ（ITのスキル）、ユーザ（ユーザ業務に関するスキル）、QA担当者（品質保証に関するスキル）などが文書のレビュという形でサポートすることになる。
このようにスキルセットを必要に応じて集めることによって、文書の品質を確保するという方法が、CSVでは重要なこととなる。

2. SDLCにおける役割と責任

一般的に、CSVを伴うシステムの導入には、表 3-1　に記載したような役割のチーム構成が必要となる。
それぞれの役割には、それぞれに課された責任があり、これらのスキルミックスにより、システムのバリデーションを実施することになる。

表 3-1　役割と責任

3. 計画フェーズ（Planning Phase）

計画フェーズでは、下記の項目を行う。

1. 業務プロセスとシステム化に対する要求事項の文書化
2. リスクの評価
3. バリデーション計画の策定
4. パッケージの調査と評価
5. ベンダーオーディット

表 4-1　計画フェーズでの成果物

3.1 業務プロセスとシステム化に対する要求事項の文書化（ユーザ要求仕様書）

ユーザは、業務の電子化を検討する場合、コンピュータシステムに対する要求事項をユーザ要求仕様書（以下、URS）として文書化しなければならない。
URSは、システムライフサイクル（以下、SDLC）の計画フェーズの最初に作成する。つまりユーザがURSを作成することにより、SDLCを開始する。（注：筆者の考え方は、URSが先で、バリデーション計画書（VMP）が次としている。ただしGAMP4によると、VMPとURSの作成順序は特定されていない。）
URSは、ユーザが新システムに要求する概要的な機能やサービスの記述を行い、導入するコンピュータシステムがどのような業務上の利益や課題を達成しなければならないのかを定義する。
URSは通常、ユーザ部門の代表者が執筆する。執筆者は、執筆前にシステムから得ることの出来るビジネス上の利益を検討しておかなければならない。また別のユーザまたは共同執筆者によって、業務ニーズが適切に特定されていることを確認する必要がある。また情報システム部門の部員も、ユーザが技術的な要件を適切に記載していることを確認しなければならない。更に、システムのサポートスタッフは、新システム稼動後に、必要となるサービス（サポート要件）が適切に記載されていることを確認すること。

URSには、導入するシステムに対する下記の事項等を記載する。

1. 要求されるシステムの概要
   
2. リプレースするシステム（存在する場合）の概要
   
3. システムを導入することによって発生する業務上の利益や課題
   
4. 実際の業務で必要とする機能（具体的な機能要求）
   
5. 導入するシステムが扱うデータの定義
   
6. 操作環境（例：Clientの環境、ユーザ数、サイト数など）
   
7. サービス（サポート）に関する要求
   
8. 推奨するパッケージ
   
9. 他社事例
   
10. 導入に関する要求事項（初期費用、メンテナンス費用、稼動時期）
    
11. リスクの評価
    

またURSは、下記の要件を満たさなければならない。

1. 候補となるパッケージの調査のための基準となること
   
2. 提案依頼書（RFP）の元になること
   
3. 機能仕様書（FS）を作成するための適切な基準となること
   
4. PQが実施できること（注：GAMPのV-Model参照）
   

URSは、パッケージ調査の前に初版の執筆を完了しておくことが望ましい。何故ならばパッケージ調査は、URSにより要求されている各種の事項と、当該パッケージ候補がどのくらいマッチするかを調査するためのものであるからである。
しかしながら昨今のビジネスの現場では、はじめにパッケージありきでシステムの導入を行うことが多い。逆にパッケージを使用せず、ソフトウェアを一から開発するようなケースは稀となった。
そのような場合は、URSの執筆に先立って、ベンダーからパッケージに関する多くの情報を入手し、またはデモンストレーションを見せてもらうことになる。そのようなベンダーからの情報を得た上で、URSを執筆した方が、効率が良いようである。

3.2 リスクの評価（リスク評価報告書）

URSを分析し、システム化のリスクを事前に分析することによって、バリデーションの必要性、範囲、レベル等を評価する。
ここで注意が必要なのは、「リスク」と「問題点」は異なるということである。
「問題点」とは、現実に対峙している「問題・課題」である。それに対してリスクとは、将来起こり得るかも知れない問題である。
「リスク」は回避するものであり、「問題点」は解決すべきものである。
リスクは例えるならば、「落とし穴」である。「落とし穴」はどこにあるかわからない。したがって「落とし穴」に落ちないかもしれない。しかしながら、落ちるかも知れないという不安を持ったままのプロジェクト遂行は、差し控えるべきである。またもし「落とし穴」に落ちたらどうするかということを事前に検討しておくことが重要である。
火災は起きないに越したことがないが、もし火災が起きた際の避難訓練はきわめて重要であることと同じである。
CSVにおいては、あらゆるリスクをあらかじめ抽出し、検討し、それらリスクをできる限り回避するための方策や、リスクを軽減するための方策、更に万が一リスクが現実となった際に、どう対処するかを事前に定義しておくことが重要である。
リスクがあまりにも大きな場合は、システム化を見送るという決定もありえる。また運用で回避するといった、手順の検討も必要となる。

リスク評価では以下の項目を評価する。

1. 業務重要性に関するリスク
   
2. システムの複雑性に関するリスク
   
3. システムの規模に関するリスク
   
4. 規制要件に関するリスク
   
5. コストに関するリスク
   
6. 安全被害に関するリスク
   

一般にリスク評価は、リスクが現実のものとなった場合のインパクト（Impact）と、そのリスクが現実に起こりえる可能性（Likelihood）の掛け合わさったものとして計られる。それぞれ、高（High）、中（Middle）、低（Low）といった評点をつけ、評価することになる。（表4-2参照）

表 4-2　リスク評価表

3.3 バリデーション計画の策定（バリデーション計画書）

コンピュータシステムの重要性、複雑性、規模に応じて、妥当な程度でCSVを実施しなければならない。
バリデーション計画書（以下、VMP）は、ユーザ要求仕様書及びリスク評価報告書をもとに作成する。
FDAは「General Principles of Software Validation; Final Guidance for Industry and FDA Staff」（2002.1.11）において、以下のように述べている。
「バリデーションの範囲は、ソフトウェアの複雑性と安全リスクに基づくべきで、企業規模やリソースの節約に基づいてはならない。バリデーション活動、タスク、作業項目の選定は、ソフトウェア設計の複雑性と特定に意図した用途をもつソフトウェアの仕様に関連したリスクに比例するものでなければならない。リスクが低い機器に対しては、最低限度のバリデーション活動が実行されればよい。リスクが増加するほど、そのリスクに対応する追加のバリデーション活動が必要となる。バリデーション文書は全てのソフトウェアバリデーション計画と手順が無事に完結したことを示す上で必要となる。」
リスク評価で抽出され、検討されたすべてのリスクについて、それらの回避方法や、万が一の際の対処方法は、VMPにおいて十分に検討されなければならない。
これらリスクの回避方法や対処方法を、事前にQA担当者がレビュし、プロジェクトオーナーが承認することによって、CSVの各タスクが開始される。
VMPの目的は、コンピュータシステムが運用フェーズへ移行するまで、プロジェクトの品質をどのようにして達成、管理、維持するかを定義することである。
バリデーション管理は、プロジェクトの規模に応じて適切に実施しなければならない。また、各業務、技術、規制要求事項を考慮に入れる必要性もある。

VMPには、以下のような当該コンピュータシステム導入プロジェクト全体の品質保証計画を記載する。

1. バリデーションに携わる組織、人員構成
   
2. 期間
   
3. バリデーション管理の実施程度
   
4. 必要な成果物類等の定義
   
5. 除外する成果物の種類
   
6. トレーサビリティマトリックスの対象となるもの
   
7. リスクの回避方法
   

VMPに記載する品質管理計画は、あらゆるプロジェクト作業が当該組織の情報化戦略、コンピュータと技術的な構成、ユーザのサポート要求に沿っていることを保証しなければならない。
以下に、バリデーション計画書における事例を元に、2つの「システム信頼性保証の考え方」を解説しよう。

1) SOPからの変更
プロジェクトの性質や規模によっては、自社のCSVガイドラインやSOPの通りに計画（例えば作成すべき文書の種類など）できない場合がある。このような場合に、絶対にやってはいけないのは、SOPの改訂である。しばしばSOPに違反したくないという心理から、SOPを改訂しようとする向きがある。SOPは標準業務手順書であり、「標準」とは、大多数の事象が相当するというものであう。すなわち一部の例外はあって然りなのである。すべてをカバーするならば、「標準」ではない。
プロジェクトにおけるCSV活動が、SOP（標準）どおりに計画できない際には、その「正当化できる理由」をVMPに記載し、「SOPからの変更」を事前にQA担当者がレビュし、プロジェクトオーナーが承認するという手続きを取るのが正しい。これが「システム信頼性保証の考え方」である。「標準」が常に変わるようであれば、信頼性の保証はできないのである。

2) VMPの承認と改訂
プロジェクトが長期にわたる場合や、規模の大きなプロジェクトの場合、その初期に全期間の詳細な計画書を作成することは困難である。そこでVMPは、プロジェクトの早い段階では直近の2フェーズまでの重要な詳細事項を記載し、その後のフェーズに関しては、概要を記載するに留めることができるというSOPの定義をしておくと便利である。
あまりにもVMPの完成度にこだわり、承認されないままプロジェクトを遂行したり、プロジェクトの終盤で完成させ、結果的にバリデーション報告書と内容的に一致してしまうことは避けなければならない。
筆者は、各社でCSV文書のレビュ依頼を受けることが多々ある。その際にしばしば経験したのが「バリデーション計画書」と「バリデーション報告書」がほぼ同じ内容になっているということだ。つまり、Copy & Pasteをして「〜をする」を「〜をした」に変更しているのだろう。
「計画」と「結果」が一致するというのは、実に奇妙である。
「バリデーション報告書」を執筆する際に重要なのは、「計画」からの逸脱を記載することである。つまり、計画通り実施できた事項に関してはあまり記載の必要がなく、むしろ計画通り実施できなかったことを「正当化できる理由」と共に記載するのである。
CSV中に発見された障害や、計画からの変更・逸脱とそれらによるインパクト（リスク）を十分評価し、たとえ障害や変更・逸脱があったとしても利用開始してもかまわないという正当化できる理由（または回避すべき事項）を文書化するのが「システム信頼性保証の考え方」なのである。

3.4 パッケージの調査と評価（パッケージ調査計画書、パッケージ調査報告書）

パッケージ調査は、URSを満たすために市販のパッケージが必要になる場合に実施する。
パッケージ調査計画書（以下、PAP）では、URSを満足するようなパッケージを適切に調査し選択するためのアプローチを定義する。
パッケージ調査は、URSおよびリスク評価報告書を参考にして行い、その結果はパッケージの選択や他の措置（例えば自社開発）を講ずる際の判断基準となる。
パッケージ調査では、パッケージコンフィギュレーションやカスタマイズ、新規開発作業の必要性、程度の概要について明らかにする。
パッケージ調査報告書（以下、PAR）は、パッケージ調査後に作成する。内容は主な調査結果を記載し、パッケージを採用するか又は他の措置を取るかの結果とその理由を記述する。
PAP及びPARは、以下の場合、作成しなくてもよい。

1. パッケージ調査の概要をURSに記載している。
2. 導入予定コンピュータシステムの業務重要性、複雑性、規模等を考慮して、当該文書の作成が必要ない旨をVMP等に記載している。

3.5 ベンダーオーディット（ベンダーオーディット報告書）

市販のパッケージを導入する場合などのように、当該プロジェクトに、外部ベンダーを利用する際は、事前にベンダーを評価する必要がある。
前回も紹介したが、FDAが1999年5月に発行した「Computerized Systems used in Clinical Trials」には、こう記載されている。
「市販のソフトウェアの場合、バリデーションの大半がそのソフトウェアを作成した会社で実施済みであるべきである。製薬企業は、ベンダーによるこの設計レベルのバリデーション文書（バリデーション文書の原文でもベンダーオーディットの文書でもよい）を保有すべきで、自身で機能テスト（テストデータを使用するなどして）も実施しておくこと。既知のソフトウェアの制限事項、問題点、障害対応記録を調査しておくこと。」
ベンダーオーディットは、VMPで事前に計画した内容に従って実施しなければならない。VMPには、ベンダーオーディットに関する以下の項目を文書化しておかなければならない。

1. オーディットプロセスを管理すること
   
2. ベンダーオーディットを実施しない場合には、その根拠
   
3. ベンダーオーディット責任者・担当者の決定
   
4. ベンダーオーディットの方法（訪問、書簡、他社からの情報提供）
   
5. ベンダーオーディットチェックリストにもとづいて実施すること
   
6. ベンダーオーディット告書を作成すること
   

ベンダーオーディットでは、下記の項目などを調査する。

1) 品質保証システム（QMS）
当該ベンダーが自社の要求する品質標準に合致した品質でソフトウェアの開発を行うことができるかどうかを調査する。
つまり自社が要求する品質保証基準を満たさないベンダーの場合は、発注できないか又は品質基準の差を自社で保証する必要性が発生する。
具体的には当該ベンダーの品質保証に関する規定書や手順書の有無、QA部門などの品質保証体制、開発過程の作成ドキュメント等を調査すること。

2) 開発標準
開発標準とは、SDLCにおける作成すべき文書の種類と承認プロセスを指す。ソフトウェアの開発が適切に規定された手順によって実施され、テストされ、それらの記録が適切に保存されていることをベンダーに確認しなければならない。

3) 開発担当者のスキル（業務、規制要件、バリデーション等）
スキル調査は、当該ベンダーがユーザ要求を満たし、ソフトウェアをGXP基準等規制要件に精通した専門家が開発し、業務に適応したコンピュータシステムを提供できる能力を有するかどうかを調べる。これは品質保証の一部である。

4) 経済状況
経済状況が悪いベンダーの場合は将来におけるサポートに不安が残り、万が一の場合、導入したコンピュータシステムのサポートが打ち切られる危険性等がある。

ベンダーオーディットは下記のタイミングで行う。

1. ベンダーとの契約前
   
2. 設計フェーズ（必要に応じて）
   
3. 運用フェーズ（必要に応じて）
   

ベンダーオーディットの実施又は非実施にあたっては、過去のベンダーオーディット報告書及びその他のベンダーオーディット関連情報（例えばベンダーからの回答書、製品情報、会社情報、ホームページ、他社からの情報等）を参考にすることができる。

ベンダーオーディットを省略できる条件としては、下記のものが考えられる。

1. 当該ベンダーが自社内の情報システム部門である場合
   
2. 過去1年間にオーディットを実施していた場合
   
3. OS、Database、汎用ソフトウェア（Excel、Word、SAS）等を製造しているメーカー
   
4. URSに基づくリスクの評価において、リスクが低いとされたソフトウェアを製造しているメーカー
   
5. VMPで、理由とともにベンダーオーディットを省略する旨記載されており、承認を得ている場合
   
6. 当該ソフトウェアのバージョンアップに伴うプロジェクト（CSV活動）である場合
   

ベンダーオーディットの結果は、ベンダーオーディット報告書（以下、VAR）として文書化する。
VARには、オーディットの概要、推奨する是正処置、全体的な推薦事項等を記載する。またオーディット中に調査した資料など、参照すべき必要文書を一覧する。
VARは、当該ベンダーの詳細な情報を含むなど、機密文書として、取り扱いに注意する必要がある。

4. おわりに

紙面の都合から、今回は計画フェーズについての解説のみとなった。しかしながら、システムの信頼性保証の考え方で最も重要なのは、計画フェーズなのである。
何度も述べてきたとおり、信頼性保証は、偶然性を排除しなければならない。つまり再現性がなければならないのである。緻密な計画に基づいて、計画の通り実行し、予定したスペックの結果を導き出すというのがその根本的な考え方なのである。
次回は、要求フェーズ以降について解説を行う。

参考

• 「Guidance for Industry; Computerized Systems used in Clinical Trials」FDA　1999.5
• 「General Principles of Software Validation; Final Guidance for Industry and FDA Staff」FDA　2002.1.1