【第1回】ソフトウェアのバリデーションとは ― 本質を考えるためのヒント

【抄録】
　一般に、完璧なソフトウェアをつくることはできず、テストも不完全であることが知られているが、それでもソフトウェアは活用しなければならない。この状況に対処するため、バリデーションを通じて合理的な自信を得る。その際、規制当局の視点と規制対象企業の経営陣の視点を持つとよい。なお、後者の視点にはリスクベースアプローチが役に立つ。
　バリデーションに関する規制要求が漠然としているのは技術選択の自由と表裏一体であり、規制対象企業はどのようなテストをどれくらいやるのか、自らが採用した技術の性質を考慮して自ら考えるべきだ。

はじめに
　近年、コンピュータ化システムバリデーション（CSV）においてもクリティカルシンキングの重要性が指摘されている。これは、一部でみられる本質的でない形式主義のCSV実務に対する反省からあげられているものだろう。では、バリデーションの本質とは何であろうか。本稿では、ソフトウェアのバリデーションに焦点をおいて、その本質を探る手がかりを提供することを試みたい。

　まず、本編に入る前に簡単に筆者の自己紹介をしたい。筆者は2007年からコンサルタントとしてIT業界に身を置いており、CSVには2009年から携わっている。当時は既にGAMP 5が発行されており、この分野では「新参者」に分類されるだろう。新参者なりの新規性を強いてあげるとすれば、単一の規制対応に閉じない multi-regulated な環境への対応に強みを持つことかもしれない。

　今日の製薬企業は様々な規制要件やセキュリティ要件への対応が求められている。ひとつの情報システムを導入するにあたっても、US-SOX対応とGMP対応を同時に求められたり、個人情報保護法対応とGCP対応を同時に求められたりすることは珍しくない。厳しいセキュリティ要件もデフォルトになっている。このような状況に対し、筆者は、情報セキュリティマネジメント、ソフトウェア品質マネジメント、ITサービスマネジメント、ソフトウェア開発ライフサイクル（SDLC）などを基盤として、情報システムに関連する諸規制を統合的に取り扱う IT GRC（Governance, Risk, and Compliance）を実践している。その実践の過程で様々な国際規格やITベストプラクティスに触れる機会が得られ、また、自ら国家規格の原案作成に参加する機会も得られた。

　CSVコンサルタントとしてはまだまだ未熟かもしれないが、変わり種としてご笑覧いただければ幸いである。

1.    完璧なソフトウェアはつくれない
「完璧なソフトウェアをつくることは不可能であるということは広く受け入れられている。」

　この一文を見てみなさんはどのように思うだろうか。実は、これはソフトウェアテストの国際規格であるISO/IEC/IEEE 29119で述べられていることである¹ 。これを「不都合な事実」と捉える方もいるかもしれないが、国際規格の策定過程や性質を踏まえれば世界中の専門家のコンセンサスと解釈してよいだろう。なお、この規格は2008年に出版されたGAMP 5 First Editionの参考文献であるANSI/IEEE 829-1998とANSI/IEEE1008-1987の後継規格にあたる。

　上の一文には続きがあり、ISO/IEC/IEEE 29119は、ソフトウェアが不完全であるからこそ、ソフトウェアをリリースする前に十分なテストを実施すべきであるとしている² 。しかし、私たちはテストの実施に当たって次の試練に直面することになる。

「プログラムテストはバグの存在を明らかにするには非常に効果的な方法だが、その不存在を明らかにするには絶望的に不十分である。」

　これはコンピュータ科学者であるエドガー・ダイクストラの有名な言葉で、「ダイクストラの箴言（しんげん）」として知られる³ 。確かに、バグがないことを証明するのは悪魔の証明であるから、テストによってそれを証明することはできないだろう。