CSVの実際

CSVの実施に関する具体的な手順の詳細については、専門書に譲りたい。今ではWeb上で簡単に調べることも出来るはずだ。ここではごく簡単にその概略を紹介しよう。

(1)要件定義
システムを実際に開発するのは、主に外部のICT専門会社ということが多いだろう。依頼者の要望を具現化し、開発担当者がシステム仕様に落とし込む。実際に使うユーザの要望とシステム開発する人の認識がずれていたのでは、目的とするシステムが出来るはずがない。その意味で要件定義の工程は、依頼者と開発者との間に起き得るミスコミュニケーションをなくすためでもある。これは規制要件の如何にかかわらず、本気で取り組まなければならないだろう。一般的には「ユーザ要求仕様書」や「機能仕様書」「設計仕様書」といった文書を作成し、開発者と依頼者とで確認し合意することがここでのゴールとなる。

(2)システム単体の動作確認
要件定義の工程で種々の仕様書が完成すると、次はシステム作りが始まる。ゼロからシステムを開発することもあれば、既に完成しているシステムの一部を依頼者の要望に合わせ、カスタマイズするというケースも多いはずだ。何れにしてもこうして完成したシステムについては、開発した側-ICT会社に開発を委託しているのであれば、そのICT会社-がまずは動作確認することになる。
また、例えばこのシステムがアプリやソフトウェアの類であれば、依頼者側のPC環境、例えばOSやCPUの性能、セキュリティシステムとの相性などが気になるところで、インストール後にも「環境との相性」をテストする必要がある。期待通りの結果となるまで要件定義の変更やシステム仕様の変更等を行い、動作テストを繰り返す。

(3)オペレーション全体としてのテスト
システム単体の動作とは別に、一連のオペレーションとして問題がないかどうかを確認する必要がある。これを実際のスタッフが導入予定のシステムを操作しながら、手順-システム導入後を想定した新しい手順書―に沿って試行してみる。その際、標準的な事案に加え、仮に年に1回も発生しないような事案であっても、“複雑系”は確認しておきたい。

例えば、妊産婦に関する情報を調べる調査システムにおいて、産まれた赤ちゃんが三つ子の場合でも、適切なオペレーションでシステムを動かすことが出来るかどうか。場合によってはシステム仕様を変更するのではなく、入力規則を変更することで解決することもある。

この工程は一般的に「ユーザ受け入れテスト」と呼ばれ、このテストの合格をもってICT会社から晴れてシステムが納品され、対価の支払いへ移ることになる。CSVの要求レベルについては、どういった利用目的で―有り体に言えば、どの規制下で―当該システムを利用するかに大きく影響する。標準的な薬事規制上の要求に則るならば、バリデーション実施の計画書や報告書、その際に生じた不具合の一覧と対応の記録に加え、関連する会議の議事録など、およそ活動の全てを記録として文書作成する必要が生じる。

こうした動作テストの工程は細分化されており、大抵の薬事規制上の要請はDQ(設計時適格性評価)、IQ(据付時適格性評価)、OQ(運転時適格性評価)、PQ(性能適格性評価)等、それぞれの工程におけるテスト計画書と報告書を全て作成することを求めているようだ。

取り扱う人のスキル保証

システム開発をする人の適格性についても、CSVでは問われる。ICT会社に開発を委託した場合、その会社に依頼者側の品質確認担当者が訪問し開発工程を精査する、ベンダー監査、ベンダーオーディットというアプローチが一般的だ。

また、システムを使う側の人のスキルについても、CSVの重要な要素である。特にオペレーションが複雑なシステムである程その要求は大きく、ときには何らかの公的な認定者しか取り扱いを許さない、とすべきシステムもあるだろう。一般的には操作の訓練を一通り受けた者であれば、アクセスして良いということになる。何らかの薬事規制下で扱うシステムであれば、「教育研修計画書」「教育研修記録」等を文書で残したり、わざわざ印刷して手書きのサインや捺印を施し、所定の場所に保管したりといったような仕事が足し算される場合がほとんどである。また、処理操作に関するヘルプ体制についてもしばしば問われる。

さらに、「その人が本当にシステムにアクセスしているのか」も当然、保証要求の対象となる。システムへのアクセス権限については、データの入力や修正をして良い人と、閲覧しか許されない人といったように切り分けることもあるが、アクセス権限の妥当性やパスワードポリシー(何桁以上とか何か月で変更しなければならないとか)等も課題となる。