データ収集は正義？(2) ソフトウェア開発編(2)-信頼性

前節：ソフトウェア開発編(1)-生産性　次節：ソフトウェア開発編(3)-信頼性

前節ではソフトウェア開発での生産性のデータ収集について記載してきましたが、今回は信頼性データについてとソフトウェア開発全般でのデータ収集について書いていきます。

信頼性データ

(1) 信頼性とは

ソフトウェア開発における信頼性とはなんでしょうか。辞書的には「対象を信じられる度合い」のことです。

これをソフトウェア開発に当てはめると、ソフトウェア開発を信じられる度合い、つまり「期待したソフトウェアを正しく作っているかということを信じられるかの度合い」になります。

もっと簡単に言えば、一般的に言われている「バグの密度」が一番近い感覚になります。

ソフトウェア開発における信頼性の対象としては以下に大別されます。

(a) ソフトウェア製品・サービス
ソフトウェア開発が完了し、製品やサービスをユーザにリリース・サービスインした後で出てくるバグが対象になります。
これを「プロダクト信頼性」と呼びます。

(b) ソフトウェア開発
ソフトウェア開発中に出てくるバグが対象になります。ただしこのバグは製品・サービスのバグを減少させることにもなり、一方的に悪いとは限りません。
これを「プロジェクト信頼性」と呼びます。

(2) （参考）品質との関係、SQuaREとの関係

品質とは「品物の性質」のことですが、ISO9000やPMBOK、TQCなどで定義されているのは「品物の性質が要求を満たす程度」となっています。

一方、ソフトウェア開発では、SQuaRE (Systems and software quality requirements and evaluation、JIS 25010：2013 (ISO/IEC 25010:2011)で品質特性が定義されています。

SQuaREでは、以下の品質が定義されています。
製品品質 ：ソフトウェア開発時における一般的な品質
利用時の品質 ：ユーザ視点での品質、顧客満足度の一視点
データ品質 ：製品で使用するデータに関する品質

この中の製品品質の品質特性を以下に示します。その主特性として、機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性が定義されています。

SQuaRE 製品品質

この主特性の中に信頼性がありますが、これは成熟性や可用性、障害許容性、回復性の副特性を持つ特性であり、最初に示した信頼性の辞書的な意味の「対象を信じられる度合い」、ソフトウェア開発の「期待したソフトウェアを正しく作っているかということを信じられるかの度合い」とは異なることに注意してください。
・・・たぶんSQuaREでいう信頼性は意味を狭めて、ディスっています。

最初に「信頼性をバグの密度」というような感覚であると言いましたが、これをSQuaREに当てはめると、製品品質の機能適合性が一番近いものになります。機能適合性の副特性である機能完全性と機能正確性、機能適切性がこれに近くなります。

ということでここでの結論「信頼性とは品質の中の機能適合性であり、バグ密度を計測対象にする」以上です。
・・・反論は受け付けていません（こちらが負けますから）。

(3) （参考）バグとは

バグとはなんでしょうか。ここでいうバグ（虫）とはスミソニアン博物館に展示されている「リレー式コンピュータに挟まった蛾」のことで、この蛾がコンピュータに不具合を起こし、この蛾が世界最初のバグとなりました。

そして蛾を取り除いた（デバッグ）ところ、正しく動作するようになり、デバッグをコンピュータの不具合を修正する意味になりました。

つまり、バグとはコンピュータの不具合という現象のことであり、また不具合の原因であるという二つの意味を持っています。

ここでバグのことを不具合という言葉を使いましたが、この言葉以外にも多くの類似の言葉が各業界で別々に使われています。これを現象と原因に分けて見ていきます。

(a) 現象系：不具合、障害、故障、インシデント、アクシデント
(b) 原因系：欠陥、瑕疵（かし）、フォールト

上記の言葉で現象か原因を区別するように使うようにしてください。またバグは両方の意味で使われることが多く、文脈をみて、現象か原因かを区別することが重要です。

・・・ここではバグと言う言葉を使っていきますので、注意しながら読んでください。

（予告）信頼性データの続き

今回で信頼性のデータ収集とその正義を書く予定でしたが、前振りが長くなってしまいましたので、本文は次回で紹介するようにします。お楽しみに。