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 が商品の価値や顧客満足に及ぼす影響度を分析（リスク分析）して、その優先度により、プロセスアプローチのしかたを変えるという方法がクローブアップされるのではないだろうか。

ソフトウェア品質論の歴史的推移

日科技連主催のソフトウェア品質シンポジウム2010（SQiPシンポジウム2010）で広島市立大学の大場充先生が、ソフトウェア品質論の歴史を解説するセッションがあった。

非常に興味深い内容だったのでここに概要を紹介したいと思う。

■品質という概の推移（概要）

• 「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
• 「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
• 今後の品質概念
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

■品質という概念の推移１

• 現在のソフトウェア品質論はプラグマティズム的品質論を元にした理論が主流であるプラグラマティズ的品質論とは米国企業に1980年頃から浸透しはじめた、古典的な経験主義に基づく統計的品質管理へのアンチテーゼとして提案された
• 興味の焦点は、品質管理の対象としての製品（プロダクト）ではなく、それを生み出しているプロセスにある。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。
• プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

■品質という概念の推移２

• プラグラマティズ的品質論とは「工程の最終段階でのテストによって欠陥を除去し、その情報に基づいてプロセスの状態を知る」というフィードバック方式から、「プロセスの状況を的確に把握し、その情報に基づいて生産されるプロダクトの品質を適切に管理する」フィードフォアワード方式に転換したと言える。
• 1980年代フェーガンが提案したソフトウェアインスペクション法は、古典的なテストに基づく品質管理と新しいプロセスの実態に基づいて品質を保証しようとする葛藤がにじみ出ている。
• その後、ミルズのクリーンルームプロセスの提案に統合されるしかし、結果的に品質保証を底辺で支える新技術の開発が遅れたため、このプラグマティズムに基づく方法は十分な成果を達成できなかった。

■品質という概念の推移３

• 1990年代センジ（プラグマティズム的組織論者）はプロセスの改善という組織の学習プロセスを管理することで、組織の目的に適合した成果を、効果的に達成できることを主張した。
• そのような組織目標を品質改善とすれば「プロセス改善によって品質向上を成し遂げる」という品質論になる。
• 「要求プロセス」「開発プロセス」「検証プロセス」「品質保証プロセス」「販売プロセス」「保守プロセス」などをそれぞれ独立したプロセスとしてとらえ個別に改善することが従来の考え方であった。
• これに対して、それら全てを統合したビジネスプロセスを見ることで全体最適を図ることが重視され、その成果が注目されるようになった。
• この思想の影響を受けたものの代表にハンフリーによって発表されたソフトウェア開発プロセスの成熟度評価モデルがある。

■品質という概念の推移４

• 「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問
• 仮に市場で最も受け入れられている製品の品質が良い品質とする前提が正しければ、プラグマティズム的品質論に根ざしたプロセス評価を受けた組織がソフトウェアは広く利用され、売れるソフトウェアである。
• Microsoft の製品はどうか？
• プラグマティズム的品質論は、現実を反映させて、個々の理論の不備を修正しながら時間とともに発展し続けている。その意味でプラグマティズム的品質論の枠組みは強固であると言える。

■品質という概念の推移５

• 観念論的品質論
• 1960年代のZero Defect運動は、生産現場における不良撲滅運動であり「不良率の低減が製品品質の向上に直結する」という考え方に基づき「不良をなくすことが、究極的な品質の実現である」とする。これは、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 1980年代後半から普及したシックスシグマ運動は ZD運動と同じ精神を引き継いでいるものの、プログラマティズム的解釈が根底にある。
• 観念的品質論では、まず普遍的で純粋な品質概念の存在を前提とする。マッコールの提案をユーザの視点から整理し、分類したのが ISO/IEC9126である。

■品質という概念の推移６

• 日本的品質管理の概念
• 「当たり前品質」と「魅力的な品質」の相対概念である。
• この概念は一見すると経験主義的な品質論に根ざしているように見えるが、本質的には経験を抽象化して獲得された高度に先験的で観念論的な概念である。

■品質論はどこに向かっているか？

• 1990年代から普及したCS運動
• CS (Customer Satisfaction)運動では、顧客（ユーザ）の製品やサービスに対する満足度ことが、効用であり、品質の根源であるとする。
• この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
• 「民主主義的原理に基づく品質論」
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
• 「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
• 開発者視点で重要なのは、そのような評価の結果を開発に結びつけることである。
• そこで重要な役割を果たすのが開発プロセスである。
• 「プロセスは良い品質のソフトウェアを開発するための手段である」
• 品質論においてプロセスは、目的ではあり得ない。
• プラグマティズムの立場から言えば、プロセスのみが、開発者が唯一管理できる対象であり、だからこそ最重要課題である。
• しかし、目的論的な立場から言えば、あくまでも手段である。

【感想】

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。

これは、試行錯誤で作り上げたソフトウェアを叩いて不具合を減らしていくという手法のことを言っているように見える。成熟度の低い組織が真っ先に考えつくのが一度作ってしまったソフトウェアの不良をいかにして取り除くかという観点だ。それだけでは無理と言ってもなかなか聞き入れてもらえない。

「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

この品質論が主流であることは納得できるし、結局、プロセスで品質を確保しようという活動をしているのも事実だ。

「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問

しかし、このことは常に開発現場の経験主義者から突き付けられる。昔は、網羅性の高いシステムテストでバグは潰し切れたし、ユーザーが行うであろうオペレーションのあらゆるパターンを再現できるベテラン技術者がいた。しかし、今ではすべてのオペレーションのパターンなど再現できるはずがない。システムテストでソースコードのテストカバレッジを100%にすることなどできるはずもないのだ。

だから、プロセスで不具合を作り込まない努力、プロセスにゲートをかけることで品質を確保することが必要になってきている。

「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である

今後の品質概念

「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。

評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。

同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

経験主義者を黙らせ、開発プロセスを管理することの重要性を訴えるには、「当たり前品質」や「魅力的な品質」といった日本的品質管理の概念や顧客満足を高めるために必要なプロセス、アクティビティ、タスクが何かという訴えかけが重要になる。

あなたの組織では「不良をなくすことが、究極的な品質の実現である」という古典的な品質論で考えが止まっていないだろうか？

品質に対する考え方は時代とともに変化しているのだ。