クリティカル・システムに使う市販ソフトウェアの検証方法(2) ―― 誰が，何をもって市販ソフトウェアが信頼できることを証明するのか

　CSVでは，対象とするソフトウェアのカテゴリごとに，確認するべき事柄を定義しています（表1）．OSやミドルウェア，データベースなどの基盤ソフトウェア（カテゴリ1）や市販ソフトウェア（カテゴリ3）など，買ってきてそのまま使う（または，設定を少々変更する程度の）ソフトウェア製品であっても，妥当性確認の計画や報告，運用時の点検などは，ソフトウェア製品を使う側である製造業者が行わなければいけません．

表1　CSVのカテゴリ分類（GAMP5による）

●「安全の証明」には保証が伴う

　品質を評価することと安全を証明することは，似ているようで異なります．最大の相違点は「安全の証明」には保証が伴うということです．安全の向こう側には，重要度の差はあるものの必ず軽減するべきリスクが存在します．リスクが具現化することを防いでいるからこそ安全が確保されるのであって，安全を表明するためにはリスクが受容できるまでに軽減できていることを示す根拠が必要です．

　図1で第三者認証機関が発行するISO 26262の適合証明は，対象製品を開発した組織がISO 26262の要求を満たしていることを証明しているのであり，ユーザに対して対象製品そのものの安全性を保証しているわけではありません．

　なお，医療機器の場合，電気的安全性については独立した試験機関が規格（IEC 60601-1）に基づいて，対象製品そのものを試験し，検査結果の証明書を発行します．検査機関自身もISO 17025（試験所および校正機関の能力に関する一般要求事項）の認証を受けていれば，その試験データを広く規制当局が求める認証に使うことができます．

　ソフトウェアの品質は，電気的安全性の試験で「何ボルト±10％以内に入っていれば合格」といったように，一般化された検査基準を確立することが困難です．だからこそ，前回述べたように，ソフトウェアの開発プロセスがソフトウェア品質論の中心になっているわけです．

　しかし，「ソフトウェア開発プロセスが要求通りにできているから，そのプロセスを使って作った製品は安全である」と言い切れるでしょうか？ ソフトウェア・プロジェクトのプロセス管理能力が高いと，そのプロジェクトがアウトプットするソフトウェア製品の品質が高いという相関はあるかもしれませんが，このことは対象製品の安全を保証しているわけではない，ということを忘れてはいけません．

　第三者認証のすべてが保証を伴わないかと言えば，そんなことはありません．例えば，日本では国（厚生労働省）が医薬品に対して許認可を与えていますが，認可した医薬品に重大な問題が起これば，国もその責任の一端を担います．実際，薬害エイズ訴訟，B型肝炎訴訟，C型肝炎訴訟では国が責任の一部を認め，被害者に賠償を行っています．第三者認証には保証というエンド・ユーザに対する責任を負う場合と，要求への適合を確認するだけでエンド・ユーザに対する責任を負わない場合があることを認識することが重要です．

　クリティカル・ソフトウェアを開発する組織は，第三者による規格適合証明を「安全のお墨付き」と考えてはいけません．対象となるソフトウェアが見えにくいから，評価が難しいから，という理由で，対象製品そのものの検証から目をそらしていては，安全の証明に近づくことはできないのです．安全を確保するためには，安全の反対側にある具体的なリスクを想定することが必要であり，それらのリスクを具現化させないリスク・コントロール手段の設計と検証，妥当性確認を行わなければ，安全の証明にはならないのです．

　安全の証明には必ず責任が伴います．安全に対して責任を持つ者は，どのような根拠で安全を証明するのか説明できるようにしておく必要があります．国際規格の適合証明を根拠の一つに使うのであれば，それが対象製品を使うユーザの安全にどのように寄与しているのか説明できるようにしておく必要があります．適合証明を過大に評価していると，実質的な製品安全からかえって遠ざかる危険さえあります．このことを，クリティカル・ソフトウェアの開発組織は認識しなければいけません．