品質と愛情はよく似ている、ソフトウェアの「当たり前品質」は時代とともに変わる：変わる「ソフトウェア品質」再考（1）

「ソフトウェア品質」は時代とともに変化している。本連載では、「品質」というものをもっと分かりやすく理解してもらうために、あらためて「品質」について再考していく。初回は「当たり前品質」の歴史、今後について。

[加藤大受，日本ナレッジ]

　ITの世界の人々に「ソフトウェア品質」の話をすると、ちょっといやな顔をされることが多くあります。品質について質問すると、「品質が重要なことは分かっている」「品質を確保するためにしっかりとレビューやテストをしている」などの返答をもらうことも多いです。筆者は以前メーカーで、製品開発を行っている設計部門に勤めていたので、品質というと「品質保証部門の人からあれこれと指摘される」イメージが付きまとうのは理解できます。自分の書いたプログラムの品質を指摘されると、ちょっと気分を害してしまうことも理解できます。

　本稿では、こういった「品質を確保する、品質を上げるための話」ではなく、「品質」というものをもっと分かりやすく理解してもらうことについてお話しします。

品質をどうやって伝えますか？

　15年以上前に海外のカンファレンスで、品質を分かりやすく伝えることに関する講演がありました。その後援者の人は次のように品質について伝えていました。

　「品質と愛情はよく似ている。どんなに分かりやすく説明しても相手に確実に伝えることはとても難しい」

　確かに、品質も愛情も人によって感じ方が違うものであり、その感じたイメージを相手に伝えることはとても難しいと思います。どちらも相手に伝えなければいけない重要な内容です。

　品質を分かりやすく説明しようとする試みは以前から行われており、ソフトウェア品質をモデル化するというのは最近始まったものではありません。1973年のTRWのレポートで、Barry W. Boehm氏が提案した品質特性を体系化した品質モデルに始まり、1977年にJames A. McCall氏と同僚によって提案されたソフトウェアのライフサイクルのステージを区分ごとにファクター、クライテリア、メトリクスの3階構造でモデル化したものなどがあります。これらは、これから説明する国際規格の基礎となっています。1970年代前半というと、ちょうどリレーショナルデータベースが登場し、Oracleが最初の製品をリリースしたころです。

　このように、ソフトウェア品質を一定の基準で分類してモデル化する方法は、ソフトウェアの歴史とともに歩んでおり、できる限り分かりやすくソフトウェア品質を客観的に表現する方法が研究されています。

参考文献

• James A. McCall, Mike T.Matsumoto, "Software Quality Metrics Enhancements Vol.1"（PDF）（原文コピー）

「当たり前品質」は時代とともに変わる