CSV（Computerized System Validation）を実施する際に作成される文書のことを成果物（Deliverable）と呼ぶ。
2008年に発行されたGAMP 5によると成果物の種類は約60種類にものぼる。
CSV成果物には大別して「計画書」「仕様書」「報告書」「スクリプト」「ログ」といった種類がある。
計画書には、誰がいつ何をするかを明確にする。すなわちCSV実施組織および役割と責任である。またスケジュールを明らかにする。間違ってはならないことは、計画書にはテクニカルな事項は記載しないということである。テクニカルな事項は仕様書 （Specification）に記載すること。
多くのプロジェクトにおいて、計画の通り進捗しないケースがあるが、その最大の理由はもともとの計画が不適切であることが多い。
スケジュールはFeasibleかつReasonableでなければならない。
一方で報告書は計画書の写しであってはならない。そもそも計画の通りすべてのアクティビティが計画通り実施できたなどということはあり得ない。
報告書で大切なことは、計画書の通り実施ができす変更したり、逸脱した事項を記載することにある。
特に逸脱事項は品質保証上問題があるため、正当化できる理由（Justification）を記載してなけばならない。
仕様書はテクニカルな文書である。例えば、ユーザ要求仕様書、機能仕様書、設計仕様書、詳細仕様書（画面仕様書、帳票仕様書、データベース仕様書、プログラム仕様書）等である。
成果物毎の作成留意事項
仕様書は、システム毎に1冊づつ作成すること。例えば2010年度にEDMS（ドキュメント管理システム）の導入プロジェクトを実施したとしよう。その後2013年に機能追加のプロジェクトを実施し、2015年には一部の機能の変更と追加を実施したとする。
多くの場合、例えば、2010年度のプロジェクトでユーザ要求仕様書を作成し、2013年度には追加分のユーザ要求仕様書を作成し、2015年度には変更・追加分のユーザ要求仕様書を作成するといったことをしていないだろうか。
このように差分のみをユーザ要求仕様書としてプロジェクト毎に作成したのでは、当該システムに対する最新のユーザ要件が一瞥できず、したがって当該システムがバリデートできているかどうかが不明になってしまう。
本来は、2010年度にユーザ要求仕様書のVer1.0を作成し、2013年度にはそれを改訂したVer2.0を作成し、2015年度にはさらにVer3.0を作成しなければならない。
機能仕様書や設計仕様書も同様である。差分の機能仕様書や設計仕様書を作成してはならない。
最新の当該システムの機能がどうなっているかを一瞥して分かるようにしておかなければならないのである。
一方で、計画書や報告書といったマネジメント文書は、プロジェクト毎に作成しなければならない。
2010年度のバリデーション計画書やバリデーション報告書は、当該プロジェクトの中で完結し、2013年度のプロジェクトでは、バリデーション計画書やバリデーション報告書は当該プロジェクトのみの成果物としてVer1.0として新規に作成するのである。
けっして過去のバリデーション計画書やバリデーション報告書を改訂してはならない。
成果物の保存方法
計画書、報告書、仕様書等は、最新バージョンのみをバインダーに綴じておかなければならない。
それに対して、テストスクリプトやテストログは全てのバージョンをバインダーに綴じておかなければならない。
なぜならば、最新のテストログのみを綴じておくとすべてのテストが合格しているからである。
規制当局のレビュでは、成功したテストを調査したいのではなく、エラーになったテストを参照し、解決された経緯を調査したいためである。
Comment