Random Failures と Systematic Failures の違い

IEC 61508（機能安全）の中に、Random Failures （ランダム故障）と Systematic Failures （決定論的原因故障）の定義がある。

IEC 61508（機能安全）の定義そのものではなく、総合的にどんなことを意味しているのかいろいろ調べて考えてみた。

そうすると、前回の記事『ソフトウェア品質論の歴史的推移』につながるところがあることに気がついた。

■Random Failures （ランダム故障）

• 構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。
• 故障率を計測することで統計的に品質を管理する。

まず、ランダム故障は故障率が計測できる故障だから統計的に管理できる。だからこそ、統計的品質管理論によって品質を高めることができる。

つぎに Random Failures （ランダム故障）に相対する Systematic Failures/Faults  （決定論的原因故障/障害）はどんなものか見ていただきたい。

■Systematic Failures/Faults  （決定論的原因故障/障害）

• ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
• 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
• 開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。

Systematic Failures/Faults は故障率を予測することが難しい。部品の故障によって発生するのではなく、タイミングや複雑なユーザーオペレーション、まれに発生するイベントなどによって起こる障害である。

となると、部品の故障率を予測して品質を管理する手法が使えない。結果として開発プロセスで抑えるしかないということになる。これがプラグマティズム的品質管理論だと思う。

さらに、ソフトウェアの障害の場合、ユーザーオペレーションに起因する障害（バグ）の場合、障害が発生する手順を繰り返すと確実に障害を再現できる。あるとても複雑な手順を実施しないと発生しないが、その手順を実施すると確実に問題が起こるような場合、その障害の発生確率をどう考えるか。

たぶん、その障害の発生手順を知らない時点では、障害発生手順をやってしまう確率になるが、その障害の発生手順を知ってしまったら、製造業者のソフトウェア改訂責任という観点からすると発生確率は100%と言えるのかもしれない。

ソフトウェアが原因の場合、ソフトウェアを修正することで障害の発生を防止できることから、障害が原因で発生するハザード（潜在危険）の大きさによっては、ソフトウェアアップデートを確実に求められる。発生する状況がまれであるためソフトウェアを改訂しないという選択ができないこともある。

ソフトウェアに起因する障害の特徴でもある Systematic Failures/Faults の防止には、統計的品質管理論は効かず、プロセスアプローチが有効（というよりは他に有効な方法論がなかった）というのが定説だ。

ただ、広島市立大学の大場充先生が言うように商品の価値や顧客満足を重視した品質管理が21世紀のトレンドであるならば、 Systematic Failures/Faults が商品の価値や顧客満足に及ぼす影響度を分析（リスク分析）して、その優先度により、プロセスアプローチのしかたを変えるという方法がクローブアップされるのではないだろうか。