ソフトウェア製品の認証は可能か？

先日，某所から「ソフトウェアの認証を行うとしたら，何を試験すればいいのか」という質問を受けた。まず，医療機器に搭載するソフトウェアや，そのものが医療機器となるソフトウェアのケースを説明し，その後，一般的なソフトウェアだったらどうなるのかと考えてみた。それが，この図だ。

規制対象となっている医療機器の場合，薬事申請する際にその医療機器の種類によって，基礎安全，基本機能，基本性能について申告をし，それらが規格を満たしていることの証明を提出しなければならない。それに加えて，リスク分析とその評価結果，リスクコントロール手段とそれを実施してエビデンス，ソフトウェアライフサイクルに関する要求，ユーザビリティに関する要求などを満たしていることを示し，最終的に妥当性の確認を行う。

ここで改めて，なぜソフトウェアを認証したいのかについて考えてみよう。そう聞かれるとおそらく，「ソフトウェアの品質を可視化したいから」とか「ユーザーが安心して使える指標にしたいから」という答えが返ってくるのではないかと思う。

で，ソフトウェアの品質って何だろうと思う。ISO/IEC 9126 のソフトウェアの品質特性を持ち出して，これらだという人がいるかもしれないが，それは違うだろう。
これらの特性は作る側の尺度であって，ソフトウェアを使う側の価値と相対しているとは思えない。

• 機能性（functionality）
• 信頼性（reliability）
• 使用性（usability）
• 効率性（efficiency）
• 保守性（maintainability）
• 移植性（portability）

ユーザーが知りたいのは，ソフトウェア（製品）の価値ではないか。製品の価値には2種類あって，顕在的な価値と潜在的な価値がある。顕在的な価値は，最初の図で言えば，基本機能や基本性能，ユーザビリティなどがそれに当たる。潜在的な価値は，（商品としての）安全性や信頼性だ。顕在的な価値は，製品のカタログやWEBサイトの説明にたいだい書いてある。潜在的な価値は，その通りに動くのか，また，不具合なく動き続けるのかがポイントとなる。ユーザーはソフトウェア（製品）の価値が高いか低いかを知りたいのだろう。ソフトウェア品質とソフトウェア（製品）の価値には相関があるようでいて，実はそうではないという側面もある。ソフトウェア品質はソフトウェア（製品）の価値の1つの側面でしかなく，しかも，ソフトウェアの価値を間接的にしか見ていないように思う。

ソフトウェア品質論の歴的推移を説明するときに毎度この図を使わせてもらっている。

そもそも，昔はソフトウェアについても不具合はゼロにしようという目標で品質論が語られてきたが，今ではそれは無理ということが分かってきたので，ソフトウェアの開発プロセスを管理することで，間接的にソフトウェアの品質を高めることが主流となってきた。

それでも，特に日本では価値や顧客満足を評価指標としてソフトウェアの品質が評価されることもあった。それが「当たり前品質」や「魅力的な品質」といった評価指標だ。

そもそも，ソフトウェア起因の障害は Systematic Failures/Faults （決定論的原因故障/障害）と呼ばれ，ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率率の予測が難しい故障/障害，出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

とてもやっかいな障害だ。そして，Systematic Failures/Faults （決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去するしかないというのが，一般的な考え方らしい。

だから，ソフトウェアの理想的なプロセスを定義して，その通りのソフトウェアが開発されたかどうか，また，ソフトウェアの開発組織が定義したプロセスに対して，どれくらい成熟しているかを図ることが主流となっている。ソフトウェアの場合，ドメイン知識を持たない者が客観的に評価しようと思ったら，結局のところ開発プロセスが定義どおりに行われているかどうかを見るしかなかったのだろう。

しかし，ソフトウェア製品の評価の図をもう一度見て欲しい。ライフサイクルプロセスの評価はソフトウェア製品の評価の一部でしかない。しかも，間接的な評価指標だ。

基本機能や基本性能を評価せずして，ライフサイクルプロセスの評価だけを行って，ソフトウェア製品の価値が計れるはずがない。ソフトウェアが意図する機能や性能をテストせず，開発プロセスだけを評価して，ソフトウェア製品の価値が計れるはずがない。ソフトウェア開発プロセスの完成度，成熟度が高いということは，相対的に「ソフトウェア品質が高いだろう」と予想できるといっているに過ぎない。実際に，そのソフトウェアの性能が高い，機能が期待通りかとうかを直接証明している訳ではない。それらを証明するためには，そのドメイン，その製品に特化したテストとテストのエビデンスが必要となる。「テスト計画を立てること」「テストを実施すること」「テストカバレッジが高いこと」は間接的な評価であって，「何のテストをしたのか」「設定した評価指標は正しいのか」「テストケースの境界値は合っているか」といった機能や性能の直接的な評価ではない。

前者がソフトウェアの開発プロセスの適合を検査するときの間接的な品質検査であり，後者がソフトウェアの直接的な品質検査だ。ソフトウェアの価値を知るためには，どちらも必要でどちらもやった方がいいが，より重要なのは直接的な検査だと思う。

電気的な安全性や機械的な評価などとは異なり，ソフトウェアを評価するのは難しい，こうなっていれば安全とか，こうなっていれば価値が高いと断定できるような，評価指標がない。だからといって，何の評価指標もないとユーザーがそのソフトウェアを選んでいいのかわからないという問題がある。しかし，生死に関わるようなソフトウェアでなければ，問題が発覚したら，アップデートするという解決策がある。

クリティカルなソフトウェア製品をライフサイクルの評価でユーザーにアピールするケースがあるが，それだけでは本当に本質を示していないと思う。基本機能や基本性能，どのようなテストを行ったのかなど，顕在的な価値や潜在的な価値を推し量るための材料はいろいろあるはずだ。賢いユーザーはそういった指標によって，ソフトウェア製品を評価するのだと思う。

ちなみに，ソフトウェアの評価に，基本機能や基本性能のテストを含めてしまうと，ドメイン知識がない認証機関はその指標が本当に正しいのかどうか判断がつかない場合がある。特にソフトウェアの場合は，難しいだろう。

だから，第三者認証を商売にしたい者は，ソフトウェアの基本機能や基本性能のテストをやりたがらないし，そこを評価したくないのだ。ソフトウェアの開発プロセスの認証なら，ドメイン知識がなくてもできるので，そればかりやりたがる。

ソフトウェアの認証は基本，自分で評価基準を決めて，自己認証し，その内容に嘘がないかどうかだけを見るようにすればいいのだ。誰かにお墨付きをもらうと考えること自体に無理があると思う。

ソフトウェア（製品）については，ドメイン知識があるものしか評価できない側面が多いと思った方がよい。だから，第三者がソフトウェア（製品）を評価する際には，その製品の開発者がどのようなテスト計画やバリデーション計画を立てているのか，その戦略やコンセプトはどのようなものか，テストケースは適切か，エビデンスに虚偽はないかといった点を見る必要がある。それは標準的なソフトウェア開発プロセスに従って開発を行っているかどうかという視点とはちょっと違う。

ソフトウェア（製品）の評価者はそのソフトウェア（製品）は価値が高いのか低いのかという視点を持って評価する必要がある。商品の価値は「意図する使用=Intended Use」を理解しないと分からない。

そして，ソフトウェア（製品）の開発者は，ソフトウェア（製品）の真の価値を評価できるのは第三者認証機関ではなく，自分達だということを認識すべきだろう。

第三者認証機関が評価できるのはあくまでもソフトウェア（製品）の価値の一面でしかなく，全体を見渡して評価できるのは，ドメイン知識を持った自分達だということだ。