「品質管理」と聞いて、「ユーザーを満足させること」や「仕様を満たすこと」を思い浮かべるかもしれません。

ソフトウェア工学研究者のロバート・L・グラスは、品質は単一の要素ではないと指摘しています。
品質は様々な属性の集合体なのです。

品質保証は、この多様な属性をバランスよく管理する取り組みです。
その中でも「信頼性」は、ユーザーが安心してシステムを使い続けられるかを左右する重要な特性です。

本記事では、品質を構成する重要な要素の１つ「信頼性」に焦点を当てます。
品質保証で広く使われるソフトウェア信頼度成長モデルの活用方法を、プロジェクトマネージャー向けに解説します。

国際標準規格 ISO/IEC 25010は、品質を以下の8つの属性に分類しています 。

• 機能適合性（Functional suitability）
• 性能効率性（Performance efficiency）
• 互換性（Compatibility）
• 使用性（Usability）
• 信頼性（Reliability）
• セキュリティ（Security）
• 保守性（Maintainability）
• 移植性（Portability）

信頼性（Reliability）が品質保証で重視される理由

この中でも信頼性は、製品やシステムが指定された条件下で安定して動作し続ける能力を指します。
障害の発生頻度や影響の少なさ、速やかな回復能力は製品やシステムにおいて重要な要素です。
製品やシステムにおけるソフトウェアが期待される機能を継続的に提供できることが、信頼性の指標となります。

信頼性を定量化する代表的な指標には、MTTFや欠陥収束率があります 。

製品やシステムの平均故障時間のことです。
「Mean Time To Failure」の頭文字を取ってMTTFです。

予測値であり、必ずしもその時間まで動くことを保証するものではありません。
信頼性試験などの参考値として利用され、以下の式で表されます。

MTTFの計算式

$$\text{MTTF} = \frac{\text{製品・システムの総稼働時間}}{\text{故障数}}$$

計算例

• 製品の稼働時間：1000時間
• 故障数：5回
• MTTF = 1000 ÷ 5 = 200時間

意味
平均して200時間ごとに故障が発生することを示します。

MTTFが長ければ長いほど、製品やシステムの信頼性が高いといえます。

欠陥収束率とは、ソフトウェア開発やテストの過程で発見・修正された欠陥の割合を示す指標です。
ソフトウェア品質管理の分野では、テストやレビューの進捗を定量的に評価するために用いられます。

欠陥収束率は、以下の式で算出されます 。

欠陥収束率の計算式

$$\text{欠陥収束率（％）} = \frac{\text{累積で発見された欠陥数（期間内）}}{\text{推定総欠陥件数（期間終了時の推定総数）}}$$

ポイント
テストで発見された障害数とソフトウェア信頼度成長モデルを用いることで、推定総欠陥件数を予測できます。
これにより、欠陥収束の進み具合を科学的に評価可能です。

ソフトウェア信頼度成長モデルは、テストで発見された障害の累積数を基に分析します。
これにより、潜在障害数を予測する代表的な品質保証手法です。

信頼性評価の代表的な手段として、多くの品質保証の現場で利用されています。

❌ 悪い例：横軸に日付を使用する（ソフトウェア信頼度成長モデルの誤った使い方）

日付を横軸にすると、テストが実施されていない期間も含まれてしまいます。
そのため、障害の発見ペースが不正確になり、信頼性の予測精度が低下します。

✅ 良い例：横軸にテスト時間を使用する（信頼性評価を正しく行うソフトウェア信頼度成長モデルの活用例）

ソフトウェア信頼度成長モデルを正しく活用することが重要です。
誤った使い方をすると、品質保証における信頼性評価の精度に大きく影響します。

私は信頼度成長曲線をSRATSというツールを利用させていただくことが多々あります。

ソフトウェアが正常に機能するために必要な安定性の度合いを確率・統計理論に基づいてソフトウェアの信頼性を評価できます。

• 入力：フォールトデータ
  　- 時間間隔（Time Interval）または累積時間（Cumulative Time）
  　- 障害件数（Number of Failure）
• 出力：ソフトウェア信頼度成長モデル
  　- 現時点で残っている欠陥数（Predictive Residual Faults）
  　- 現時点で欠陥がすべて除去されている確率（Fault-Free Probability）
  　- 次の障害が発見されるまでのテスト時間（Conditional MTTF）

まずはテスト実績からフォールトデータを準備します。

障害件数は、RedmineやJIRAなどの課題管理システムに登録された障害データから作成します 。
報告された事象の数をベースにカウントしてください。

データの入力方法は「時間間隔」または「累積時間」の2種類です。
時間の単位は（人時）や（人日）など、プロジェクトで統一されていれば問題ありません。
重要なのは、継続的に同じ単位で測定することです。

例）時間間隔（Time Intervalの例）

この例では、3人が毎日8時間テストを実施し、1日あたり3件の障害が見つかったケースを示しています。

例）累積時間（Cumulative Timeの例）

累積時間では、2列目が積算値になる点が「時間間隔」との違いです。
時間の単位は（人時）としていますが、（人日）や（人月）でも構いません。

次にモデルを推定します。
フォールトデータのセルを選択して「Estimate」を実行してください。

モデルの推定をすると、推定結果のサマリー（Gamma SRGM、Exponential SRGMなど）が表示されます。

Statusが「Convergence」の場合、データに最も合うパラメータが推定できた状態です。
一方、「MaxIteration」は、パラメータ推定がきちんと行えていない状態を示します。

推定結果のサマリーにある AIC または BIC の小さいモデルがフォールトデータによく適合したモデルです。

適合したモデルを選択後、レポートを出力して信頼性を評価します。
この結果は、ソフトウェア信頼度成長モデルを品質保証手法として運用する際の判断材料になります。

例）ソフトウェア信頼度成長モデル

曲線が水平に近いと信頼度が高いことを意味します。

例）障害予測

• Predictive Residual Faults
  　例では現時点で残っている欠陥が 1.2395個 という意味です。
• Fault-Free Probability
  　現時点で欠陥がすべて除去されている確率が 0.2895 という意味です。
• Conditional MTTF
  　次の障害が発見されるならば 56.40 テスト消化時間後　という意味です。

品質保証担当者は、これらの指標を根拠に追加テストの要否を判断します。

ソフトウェア信頼度成長モデル（SRGM）で障害が収束したか判断する例を示します。

SRGMは右肩上がりの形のためテスト初期段階で多数の障害が潜在していると判断できます。

SRGMの傾きが緩やかになってきた場合、障害は減少しているものの、まだ潜在していると判断できます。

SRGMの傾きが水平に近づけば、新たな障害発見に時間がかかることを意味し、収束したと判断できます。

ソフトウェア信頼度成長モデルは、信頼性評価を数値で裏付ける強力なツールです。
ただし、品質管理のすべてではありません。

ロバート・L・グラスは「品質は属性の塊」と述べています。
ソフトウェア信頼度成長モデルは、品質保証の多様な属性の中で特に「信頼性」を定量化する手法に過ぎません。

品質保証を成功させるには、信頼性だけでなく性能や保守性、セキュリティなども考慮する必要があります。
ソフトウェア信頼度成長モデルを品質保証全体の一部としてプロジェクト全体の品質向上に役立てましょう。