クリティカル・システムに使う市販ソフトウェアの検証方法(1) ―― ソフトウェア品質論の推移とシステムの安全性確保の考え方

●ソフトウェアに関連するリスク

　ソフトウェアはよく「中身がどうなっているのか見えない」と言われます．従って，ソフトウェアの構造や品質を可視化する取り組みや研究が長年続けられていました．ソフトウェア・システムの中身が見えにくいからといって安全や信頼に対する対応を放置していたら，ソフトウェアはブラックボックスのままであり，重大な事故を起こすリスクを排除することができません．重大なリスクとは，医療機器で言えば，患者さんに重傷を負わせるような巨大なエネルギーを出力してしまうリスク，自動車で言えば，ブレーキをかけたいときにブレーキ制御が効かない，エアバックが動作しない，といったリスクです．

　では，このようなソフトウェアに起因するリスクが具現化し障害に至らないようにするためには，何をすればよいのでしょうか．各産業はどんな取り組みを行ってきたのでしょうか．それを理解するためには，ソフトウェア品質論の歴史的背景を知る必要があります．

●統計重視からプロセス重視，顧客満足重視へ

　ソフトウェア品質論の歴史的推移を図3に示します^（2*）．1960年代以前から現在に至るまで，見えないソフトウェアの品質を確保する考え方として常に主導的な役割を果たしてきたのが，統計的品質管理論です．統計的品質管理論は，ソフトウェアのみならず，ハードウェアも含めた品質管理の基礎となっています．

図3　ソフトウェア品質論の歴史的推移
広島市立大学 教授 大場 充氏の講演「ソフトウェア品質って何だ～民主主義原理に基づくソフトウェア品質論入門～」を参考に作成した^（2*）．

　1960年代にはソフトウェアの品質管理としてZD運動（Zero Defect運動；欠陥をゼロにする運動）が行われていましたが，ソフトウェアで欠陥（すなわちバグ）をゼロにすることは不可能であることが次第に明らかになり，ソフトウェアの世界ではZD運動は衰退していきました．その後，台頭してきたのが，プラグマティズム品質論，すなわちソフトウェアの開発プロセスに着目してソフトウェア品質を高める考え方です．プロセス重視の品質論，プロセス改善の組織論，組織の成熟度モデルの研究は1990年代から欧米を中心に盛んに行われるようになり，現在でもソフトウェア品質に対する絶対的な地位を築いています．

　ソフトウェア開発プロセス重視の品質論が時間の経過とともに，詳細かつ強固に補強されていく一方で，ソフトウェアの開発現場では小さいプロセスを機敏に適用するアジャイル開発を支持するプロジェクトも増えてきています．プロセス重視の品質論の基本は，ウォータ・フォールやV字のプロセス・モデルを想定し，各工程においてインプットとアウトプットをきっちり確認しながら進めていくという考え方です．一方，下流工程であっても大量の変更が発生する現実に直面しているソフトウェア開発プロジェクトの中には，プロセス管理がソフトウェアの品質向上に貢献するという考え方に異を唱え，アジャイル開発の方が結果的に品質が高まる，と主張する者もいます．

　プロセス管理重視のソフトウェア品質論が台頭してきた一方で，日本では「当たり前品質」，「魅力的な品質」といった，商品の価値に焦点を当てた考え方があります．また，顧客満足を高める活動，いわゆるCS（Customer Satisfaction）運動がソフトウェアの品質向上に貢献する，という視点も追加されつつあります．

　このように，現代のソフトウェア品質論は「統計的品質管理論」，「ソフトウェア開発プロセス管理」，「商品の価値・顧客満足重視」という三つの大きな考え方が共存していると考えられます．

●求められる安全要求に応える，という発想

　要求される安全レベルの指標として，IEC 61508（機能安全規格）ではSIL（Safety Integrity Level：安全度水準）が，ISO 26262（自動車の機能安全規格）ではASIL（Automotive Safety Integrity Level：自動車安全度水準）が定義されています．また，医療機器のプロセス規格であるIEC 62304（医療機器ソフトウェア ― ソフトウェア・ライフサイクル・プロセス）では，ソフトウェア安全クラスが定義されています．

　これらの指標はそれぞれ，ソフトウェアを搭載したシステムに対して，どれくらいのレベルの安全が要求されるのかをクラス分類し，そのクラスによってクリティカルなソフトウェア・システムに対する要求を変えようとしています．当然のことながら，安全度水準やソフトウェア安全クラスが高いと判定された場合の要求は，クラスが低いときよりも広く深くなります．IEC 62304において，ソフトウェア安全クラスがA, B, Cのうち一番高いCであった場合，要求されるプロセスとプロセス中に実施するアクティビティやタスクの種類が最も多くなります．

　この考え方は，図3（ソフトウェア品質論の歴史的推移）に照らし合わせると，「ソフトウェア開発プロセス管理」と「商品の価値・顧客満足重視」の融合ととらえることができるでしょう．

　安全度水準やソフトウェア安全クラスといった視点は，損なわれるとユーザが危害を被る「当たり前品質」の度合いと見ることができます．損なうと顧客満足を著しく低減させる商品の価値を安全度水準やソフトウェア安全クラスで格付けし，その度合いに応じて，適用するプロセス，アクティビティ，タスクの割り当てを変えていることから，ソフトウェア品質論の「ソフトウェア開発プロセス管理」と「商品の価値・顧客満足重視」を融合させていると考えることができます．この考え方は，2000年代のソフトウェア品質論の主流となるかもしれません．

参考・引用*文献
（1）U.S. Food and Drug Administration；General Principles of Software Validation, Version 1.1, dated June 9, 1997.　※なお，2002年1月に本ガイダンスの最終版が策定されている．この最終版は，米国FDAのWebサイトで参照できる．
（2*）大場 充；ソフトウェア品質って何だ～民主主義原理に基づくソフトウェア品質論入門～，ソフトウェア品質シンポジウム2010（SQiP2010）【http://www.juse.or.jp/software/200/】 企画セッション4-3 論文，2010年9月．

さかい・よしお