ソフトウェアの品質について

　そもそもソフトウェアの品質を数値で表すことはできないのですが、前稿：計測の説明で品質を計測する尺度として“テスト項目数”、“欠陥件数”、“欠陥検出率”があることを述べました。これらはソフトウェアの品質を測る便宜的な尺度であって、ソフトウェアの品質を表す尺度ではありません。人の白血球の数は1ミリ立方メートル当り3,000～9,000個が正常値で、あなたは 4,500だから正常ですと、成人検診などで言われますが、血液中の白血球の分布が体中で均一であることを前提に、サンプリングして評価しています。ソフトウェアの場合、欠陥がソフトウェア全体に均一に存在することはありません。むしろ、偏在することの方が多いのです。また、欠陥が多数含まれている場合にはサンプリングという手法は意味がありますが、欠陥数が少なくなっても欠陥が存在しないことを保証しているわけではありません。白血球の場合、白血球が存在しなければ異常ですが、反対に、存在しないことが正常であると仮定すると、ソフトウェアの場合と同様に完全に存在しないことを検証する手段はないでしょう。実際、癌細胞が存在しないことを検証することはできません。ソフトウェアの欠陥であれ、人の癌細胞であれ、“存在しない”ことを検証することは大変難しい問題です。

　ソフトウェアの品質を論じるとき、開発中の欠陥が多数存在する時点では統計的手法が意味を持ちますが、完成に近づくにつれて、欠陥が見つけにくくなった場合、統計的手法では解決できない状況になります。ソフトウェア開発者にとってはちょっとした不注意による欠陥が一つ含まれていても、そのソフトウェアを使用する側からみれば、見逃すことができない大問題になることがあります。
　
　テストデータを使って十分と思われるテストを行い、また、実際のデータを使って多角的にテストして問題がなければ合格とするというのが現状でしょうが、そこまでしておけば大丈夫かと言えば安心感は増しますが、完全とは言えません。一つのテスト項目によるテストはあくまでも一つのケースで動作したということしか意味しません。たまたま正常に見える結果が得られたのかもしれません。そのようなテストをできるだけ網羅的に実施して、完全に近づけることはできるでしょう。しかし、それでもテストだけでは品質を保証することはできません。

　因みに、数学の命題の証明が正しいか否かを保証する一般的手法はありません。難問中の難問を解いたと発表したが、実際は誤っていて、人生を棒に振った数学者が何人もいます。証明が正しいか否かは別の数学者が時間をかけて判定するのです。ソフトウェアで言えば、レビューがこれに当たります。一人のプログラマが書いたプログラムが本当に正しいかどうかを他の複数のプログラマがレビューして正しいと判断しなければ、信頼がおけるプログラムとは言えないでしょう。

　このように、ソフトウェアに欠陥が“存在しない”ことを検証することは難問ですが、この難問を克服するには、既に品質が実証されているモジュールを再利用するのが正当なやり方と言えるでしょう。オブジェクト指向は再利用の考え方を取り入れていますので、この問題の解決手段の一つと言えます。しかし、実証されていないモジュールの再利用は、オブジェクト指向を使用したとしても、難問を克服する手段にはなりません。この難問を克服する最善の手段は複数のプログラマによるレビューと実証の積み重ねにあります。

　大規模なソフトウェアの場合、これだけのことを実施しても、まだ品質を保証することはできません。今後は、上記のレビューや実証済みモジュールを使用することに加え、ソフトウェア・アーキテクチャとして品質の確保をソフトウェアに織り込むことが必要です。

　例えば、ソフトウェアを構成する複数のモジュールやサブシステムは各々が独立性を持ち、コンポーネント間は疎結合（loosely coupled）設計にします。モジュールやサブシステム間の関係を疎結合にすることはプログラマの注意力を集中させ、欠陥の作りこみを減らし、レビューを容易にします。また、大規模システムでは、運用管理システムでシステムの負荷状況などを監視していますが、モジュールやサブシステムなどのコンポーネント・レベルでソフトウェアの動作状況を監視することも必要ではないかと思います。ソフトウェアの内部動作状況を把握する、言わば、神経系を組み込んでおくことが、異常動作を検知する一つの手段になります。私は、このような監視機能を組み込んだソフトウェアを開発したことはありませんが、コンパイラの開発において、フェーズ毎に出力データ（中間言語や各種テーブル）の内容を吐き出すモジュールを組み込み、内容を確かめてから次のフェーズに制御を渡す手法を採ったことがあります。設計通りに動作しているかを確認し、自信を持つことができました。最近のソフトウェアは高性能のマシン環境で動作しますので、監視機能にある程度のマシン資源を使うことは許されるのではないかと思います。

■