【第7回】CSVからCSAへ　データインテグリティも踏まえたFDAの新ガイダンス動向

（今回以降の記事では、本ドラフトガイダンスで新たに導入された、簡略化されたテストの取り扱いを中心に紹介する）

テスト記録の要件
まず、「第V章 コンピューター・ソフトウェア・アシュアランスのリスク・フレームワーク」-「D. 適切な記録の確立」のセクションで、ソフトウェア保証の記録が含むべきものとして以下が列挙されている。

• ソフトウェアのフィーチャー、機能、またはオペレーションの使用目的
• ソフトウェアのフィーチャー、機能、またはオペレーションのリスクの決定
• 以下を含む、実施された保証活動の文書化:
    － 保証活動に基づいて実施されたテストの説明
    － 発見された問題 (例: 逸脱、故障) および処分
    － 結果の許容可能性を宣言する結論的言明
    － テスト/アセスメントの日付と、テスト/アセスメントを実施した者の氏名
    － 必要に応じて、確立されたレビューと承認
  　　 (たとえば、必要に応じて、署名権限を持つ個人の署名と日付)

これらは、全く異論のないところであろう。
注目すべきは、バリデーション作業のドキュメント作成負担軽減を目指す本ドラフトガイダンスの意図を反映して、以下の一文が示されている点である。（下線は筆者）

「保証活動の文書化には、特定されたリスクに対してソフトウェアのフィーチャー、機能、またはオペレーションが意図したとおりに機能することを示すために必要以上の確証を含める必要はない。」

それに続く同セクションの「表１－ 保証活動と記録の例」に示された記録の例のうち、従来からのCSVのIQ/OQ/PQ実施時のテストに相当する「スクリプトテスト［頑健な］」と新たに導入された「非スクリプトテスト［アドホック］」のそれぞれについて、文書化の必要な項目を比較するために、以下に抜き出した。

両者を比較すると、アドホックなテストにおいてはそもそも詳しいテスト計画が無いため＜テスト計画＞に関する文書化が大幅に削減されるのは当然であるが、＜記録＞として残されるべき項目が、頑健なスクリプトテストに比べて大きくは減らないことがわかる。
この表１に続いて「監視目的で管理されたシステムに保存された不適合データを収集してグラフ化する目的で製造業者がスプレッドシートを開発したシナリオにおける保証の記録の例」が示されており、「この例では、製造業者は、不適合製品が出荷されないようにする追加のプロセス管理と検査を確立している。この場合、スプレッドシートが意図したとおりに実行されなくても、安全性が損なわれることが予見できる品質問題にはならないため、スプレッドシートが高いプロセスリスクをもたらすことはない。」とある。従って、この例は全くMES/LIMS/CDS等に対する参考にはならない。逆に「このような使用目的のものでも、こんなにたくさんの記録が必要なの？」と感じられる。
一方、表１の記載を従来のIQ/OQ/PQの観点から見直したとき、従来の方法論において重要な存在であったトレーサビリティ・マトリクスに関する記載が皆無であることに気が付く。そのことに代表されるように、本ドラフトガイダンスの記載は従来のGAMP流のVモデルとの関係性・継続性を全くといってよいほど考慮していないように、筆者には思われた。