故障モード影響解析シートの事例

　次に、先ほど紹介した故障モード影響解析シートをもとに、これから開発しようとしているソフトウエアに適用する方法を紹介します。

　故障モードを抽出したソフトウエアとこれから開発しようとしているソフトウエアは類似のものである場合や、バージョンアップや機能拡張をする前と後の関係にある場合には、特に効果が大きくなります。

　まず、図3-1の「修正管理表からの処理の抽出・抽象化」は、図1-2のシートに具体例を記入したものです。ここでは冒頭に紹介した4,500KLOCの図形処理アプリケーションの総合テスト時に記録された修正管理表から4件の修正を例にしています。

　図形IDなどは実際の名称を匿名化したものです。1行目は図形オブジェクトに関する不具合で、図形ID「1001」と図形ID「1002」が重なったときの考慮ができていなかったものです。これをもとにほかの同じような不具合を防げるよう抽象化し、「処理内容」を「図形ID 1001の表示領域を求める」とし、さらにほかの図形IDにもあてはまるかどうかを勘案し、「処理名」として「図形ID1000～2999の作成範囲を求める」としました。同様に、2、3、4行目も抽象化をしています。

　次のステップは、図3-2の「処理を中心とした故障モード」シートです。「処理名」列のセルがいくつか結合しています。このようになるべく多くの処理名に共通するよう抽象化を進めます。また、「具体例」列は「修正管理表からの抽出・抽象化」シートの「不具合現象」をもとに記入します。最後の2行（「故障モード」列A1.2.4、A1.2.5）には具体例がありません。これは「処理名」において発生しうる類似の不具合（修正管理表には記入されていないものの起き得る可能性が高いもの）を記入しています。

　「影響解析（FMEAシート）」は「処理を中心とした故障モード」の「処理名」列と「故障モード」列を写し、「影響内容」列に不具合の結果がどのような結果を引き起こすかを記述したものです。「処理を中心とした故障モード」シートと故障モードの順番がいれかわっているのは、後述するRPNの大きな順に並び替えているためです。また、図はRPNの値が上位3つのものを示しています。例えばA.1.2.4の故障モードはRPN値が80でもっとも大きいので先頭になっています。

　RPNは「影響」列、「発生頻度」列、「検出」列の3つの積です。「影響」列は「影響内容」列の内容をもとに、各故障モードが引き起こす結果の深刻度合いを5段階評価で記入しています。

　評価は図2-2の「ランク値」シートにもとづいて決めています（図2-1）。例えば1行目の故障モードは、結果が著しく不正であり、回避策がなく、対応（ソフトウエアの変更、確認）に10日以上必要と推測されたので、「5」が記入されています。また、発生頻度は通常のユーザー利用シーンにおいて1ヶ月に2回以上発生すると推測されたので「発生頻度」列に「4」が記入されています。また、この故障モードを検出する難しさは、システムテストまでに必ず発見される（システムテストのテストケースで検出可能）と推測されたので、「4」が記入されています。

　「対策」列には、故障モードをどうすれば防げるかを具体的に記述したものです。「工程」列には対策をいつ行えるかを記入します。

現場への適用

　ご覧いただいたように故障モード影響解析には特に大がかりな仕組みは必要ありません。前提は、過去に起こった不具合の記録が残っている（あるいは明確に記憶している人がいる）ことと、これから開発するソフトウエアにも類似の不具合が起こり得る、という点です。派生開発、保守開発の多い昨今のソフトウエア開発をかんがみれば、あてはまるものが多いのではないでしょうか。

　ソフトウエアにFMEAを適用しようとする試みは過去にもいろいろなされています（参考文献参照）。また、保守開発型ソフトウエアを対象としたソフトウエアFMEAの実証的評価（http://se.aist-nara.ac.jp/html/review/softwarefmea.html）も参考になるでしょう。

［参考文献］

河野哲也, “ソフトウエア開発におけるFMEA適用に関する考察”, ソフトウエアテストシンポジウム東京予稿集, p. 127~130 (2009)