東芝は、FMEA(故障モード影響解析)をソフトウエア開発に試験的に適用した事例について、2011年7月14~15日に開催された「第41回 信頼性・保全性シンポジウム(主催:日科技連)」において発表した。過去のプロジェクト(社会インフラ向けシステム)の一部モジュールに対して、設計資料などを基にソフトウエアFMEAを実施した結果、当該プロジェクトのシステム・テストで検出された不具合や出荷後不具合など合計5件の不具合をソフトウエアFMEAによって検出することができた。実装工程より前の上流段階で不具合を発見できる効果がある。今後、実開発への適用を検討する。

 ソフトウエアFMEAとは、ソフトウエアの不具合の原因として考えられる要素を「故障モード」ととらえ、ハードウエアのFMEAと同様に各故障モードによる上位システムへの影響を分析するアプローチである。個別の故障によるシステム全体への影響を分析するため、ボトムアップ的な分析アプローチといわれる。

 ソフトウエアFMEA自体は以前から提唱されているが、論理的な構築物であるソフトウエアの場合、その不具合の要因は複雑かつ多様である。このためハードウエアFMEAと比べて故障モードを整理・抽出しにくいほか、適用コストが高くなるため、あまり普及はしていない。今回、東芝はこの課題に対し、「観点リスト」というアプローチを提案し、ソフトウエアの故障モードを設計者が抽出しやすくした。

「検討不足」が一番やっかい

 ソフトウエア開発の各工程における不具合の混入要因として、東芝は三つを挙げた。(1)間違い、(2)誤解、(3)検討不足、である。間違いとは、要求定義や設計、実装などソフトウエア開発の各工程で詳細化を行う際、その詳細化の変換に誤りが混入すること。誤解とは、前の工程で得られた成果物を、次の工程の技術者が参照する際、誤って解釈すること。検討不足とは、各成果物において明示的に表現されていない事象があり、それが検討不足であることである。

 これら三つのうち、間違いや誤解についてはテストや静的解析などでも検出できるが、検討不足についてはレビューに頼る側面が強く、「発見が難しく、検出アプローチの強化が求められる」(登壇した同社 ソフトウェア技術センター プロセス・品質技術開発担当の夏目珠規子氏)。

 不具合情報を設計にフィードバックするアプローチとしては、FMEA以外にも過去トラブル集の利用、チェックリストの利用などがあるが、いずれも再発防止的な側面が強く、FMEAのように探索的に発想を広げ影響を分析する要素は薄い。

機能×観点で故障モードを抽出

 ソフトウエアFMEAでは前述したように不具合の要因が多様なため…