故障モード影響解析（FMEA）とは？

イベントベースの故障モード影響解析

　筆者らが対象としたソフトウエアは大規模かつ長期にわたって保守、拡張されている図形処理用ソフトウエアです。C言語で4,500KLOC、年4回程度のペースのリリースを10年以上続けています。当初、構成要素を機能としようとしましたが、分類が100を超えてしまうことがわかりました。

　そこで、もっと数が少なく抽象的なものを構成要素とする必要を感じ、対象ソフトウエアを大きく（1）図形オブジェクト処理、（2）コマンド（バッチ処理）の2つに分けて考えました。

　（1）図形オブジェクト処理は、リアルタイムにユーザーの操作を受け付けながらユーザーに結果を表示する部分、（2）コマンド（バッチ処理）は、コマンドラインから実行される補助ツール群であり、データ変換等のためにあります。（1）に多数の機能が存在していたため、この部分を機能ではなく、イベントとして抽象化しました。具体的には、（a）ユーザーからの入力にもとづく図形の操作（移動等）、（b）操作の結果から複数の図形どうしの関係を計算、（c）図形の関係にもとづいた処理、（d）表示の4イベントに分割しました。

　構成要素は、対象ソフトウエアの特徴にあわせてうまく選択する必要がありますが、なるべく構成要素の数を減らしつつ、いろいろな部分にあてはまるよう、抽象化することがコツです。

　図3はイベントベースの故障モード影響解析の全体像を示しています。全体として5個の表を使います。上から3つまでは故障モード影響解析自体に必要となる表です。残りの2つは、上3つから得られた故障モード影響解析結果をもとに、これから開発しようとしているソフトウエアに適用する際に必要となる表です。上3つをあらかじめ作成しておけば、ほかの開発でも流用できる場合があります。下2つは、開発するソフトウエアごとに作成しなおさないといけない場合があります。

　1つ目の表へのインプットは、不具合管理表や修正管理表です。また、3つ目が故障モード影響解析の結果になります。一般に故障モード影響解析と呼ばれる技法では、3つ目の表が得られた時点で作業は終了します。ここでは、得られた故障モード影響解析表をもとにこれから開発するソフトウエアにどうやって活用していくかについても紹介します。イメージとしては、過去の不具合管理表をもとに、これら3つの表を作りながら、起こりがちな不具合、起こる場所、優先度を決め、3つ目の表を得ます。3つ目の表の内容を使って、これから開発するソフトウエアでも起こりうる内容か、起こるとするならばどの機能や工程で防げるかを明らかにします。

修正管理表からの故障モード抽出

　故障モードはバグ票、修正管理票から抽出しますが、今回紹介する事例は、総合テストでの修正管理票から抽出しています。総合テストで発見される不具合はそれまでの工程でもみつけにくい総合的、例外的な不具合です。それらを故障モードとして定義し、仕様レビュー、設計レビュー、コードレビュー、テスト設計で活用することで、不具合の早期発見を目指します。

［参考文献］
山科 隆伸, 森崎 修司, 飯田 元, 松本 健一『保守開発型ソフトウェアを対象としたソフトウェアFMEAの実証的評価』「ソフトウェア品質シンポジウム2008 発表報文集, pp.157-164」（発行年：2008）

山科 隆伸, 森崎 修司『大規模ソフトウェアの保守開発を対象とした故障モード影響解析(FMEA)適用の試み, 』「ユニシス技報 No99」（発行年：2009）