バリデーション報告書の書き方


<連載 全12回> CSV実践講座(第8回)

CSV実践について研究するページです。

*万が一文中に解釈の間違い等がありましても、当社では責任をとりかねます。
 本文書の改訂は予告なく行われることがあります。

バリデーション報告書の書き方

1. はじめに

バリデーション報告書(以下、VR)は、CSVにおける最も重要な文書のひとつである。
VRでは、バリデーション計画書(以下、VMP)で計画し、プロジェクト期間中に実施したバリデーション活動を要約することになるが、単に作業をサマリーするだけでは、品質保証を目的としたバリデーションの報告書にはなり得ない。
また、筆者がコンサルテーションを行う中で、VMPとVRがほぼ同じ内容になっているケースを多く見かける。おそらくVMPの内容をVRにCopy & Pasteをした上で、「〜をする」を「〜をした」に変更しているのであろう。「計画」と「結果」が一致するというのは、実に奇妙なことである。
VRを執筆する際に重要なのは、「計画」からの逸脱を記載することである。つまり、計画通り実施できた作業に関しては詳細に記載する必要がなく、むしろ計画通り実施できなかったことを「正当化できる理由」と共に記載するべきである。これがシステムの信頼性保証の考え方である。

2. バリデーション報告書とは

VRの目的は、VMPによって要求され実施したバリデーション活動を要約し、プロジェクトのフェーズとその活動が管理されていることを示すことである。またプロジェクト期間中の障害や変更の要約と、VMPからの逸脱および正当化できる理由を記載する。

VRには、以下を記載すること。

  1. 作成した成果物と日付
  2. プロジェクト期間中に発生した障害の要約と対処方法
  3. プロジェクト期間中に実施した変更(Change Control)
  4. バリデーション計画書からの逸脱事項と、それを正当化できる理由(Justification)
  5. プロジェクトのフェーズとその活動が管理されており、再現可能であること(トレーサビリティの保証)
  6. 要求されたシステムの信頼性が確保でき、コンピュータシステムが受入れ可能であり、利用開始できる根拠
  7. 実稼動(プロダクション)フェーズへ進む際の制限等
2.1 障害の対応方法

ソフトウェアにとって、バグ(不具合)はつきものである。そのすべてを取り除くことは困難を極める。
プロジェクトの終了時期や経済的な理由などから、必ずしも発見されたすべてのバグの修正が可能で、さらにその修正が確かであるかどうかを再検証できるとは限らない。
バグのある機能は使用してはならないので、運用で回避することとなる。
この場合は、当該障害をどう運用で回避し、システムを利用する上で問題とはならない旨を記載しておく必要がある。
VRにはこれら不具合への対処として、システムを利用する上での制限事項を記載しておかなければならない。

2.2 変更および逸脱の対応方法

変更とは何らかの理由(障害の発生など)により、意図的にVMP等の計画を変更することである。これに対して、逸脱とは、結果的に計画を守れなかった事項を指す。
変更は事前に変更管理プロセス(Change Control)によって管理しなければならない。VRではプロジェクト期間中に行った変更をサマリーすることになる。

逸脱は変更管理プロセスを経ないで、結果的にVMPを守れなかった事項を指す。信頼性保証上、逸脱は問題となるため、VRではその内容とインパクトを十分に検証し、正当化できる理由(Justification)を記述すること。
この正当化できる理由をQA担当者などの利害関係のない第三者がレビュし、同意を得た上で、プロジェクトの責任者が承認することとなる。
正当化できる理由等が適切に記述できない場合や、QA担当者の同意を得られない場合は、システムを利用開始できないか、利用を制限されることがある。

3. バリデーション報告書の内容

VRには、下記の内容を含めなければならない。

  1. 目的
  2. 範囲
    バリデーション計画書からの適用範囲の縮小や拡大も記述すること。
  3. 用語の定義
  4. プロジェクトフェーズと実施作業の結果の要約
    4-1 フェーズと実施作業の結果
           バリデーション計画書に記載したフェーズと実施作業の結果を記述する。
    4-2 バリデーション計画書からの逸脱
           品質受諾条件からの逸脱を含め、要求された実施作業を実施している間に発生した
           バリデーション計画書からのあらゆる逸脱を記述する。
  5. 成果物
    バリデーション計画書で要求された成果物の一覧表を記載する。
    バリデーション計画書で要求されているが作成しなかったか、完成していない成果物については、その理由の根拠を示す合理的な説明を記述しなければならない。
    バリデーション計画書で特定されていない追加文書がある場合も記載すること。
  6. 障害と変更の要約
    バリデーション計画書によって要求された作業を実施している間に発生した、重要な障害や変更の要約を記述すること。
    特に主要な障害に関しては、解決するために取られた調査や是正措置などを記述しておくこと。
    より情報を詳細に特定する必要がある場合は、障害ログ等を参照先として記載すること。
  7. 使用の制限と制約
    システムの本稼動におけるあらゆる制約または制限を記述すること。
  8. 結論 プロジェクトを通して導かれた結論を記載する。
4. バリデーション報告書における結論

VRにおいて、以下の2点を結論として言い切れたならば、プロジェクト期間中におけるバリデーション活動は終了する。

  1. 当該システムが、事前に策定された品質受諾条件を満たすと判断できる。
  2. バリデーション活動は文書化されており、再現が可能であると判断できる。

これら2つの事項はどちらも信頼性保証上欠かせないものであるからである。

5. バリデーション報告書以降の品質計画文書

VR承認をもって、プロジェクト期間中のバリデーション活動は終了することとなる。
しかしながら重要なことは、利用フェーズ以降もバリデーション状態を維持しなければならないということである。
そこで当該システムをサービス組織へ引き渡す際に、本稼動でバリデーション状態を維持するのに必要なサポート品質計画書を作成することとなる。

6. おわりに

作成したVRは、QA担当者のレビュを受け、コンピュータシステムが利用開始できる根拠について同意を取っておく必要がある。
QA担当者のレビュでは、文書化された証拠(つまりCSVの成果物)をもとに、再現性を検討する。
すなわち再度同じ作業を行った場合、同じ結果が得られるかということである。再現性がなければ、信頼性の保証は行えない。なぜならば、信頼性保証は偶然性を排除し、何度行っても同じ結果が得られることを保証することだからである。
次回は「サービスレベルアグリーメント」の書き方について解説する。

参考