FMEAシートの活用事例

不具合管理表からの処理の抽出

　前回は、故障モード影響解析（FMEA）について解説しました。今回は、事例を紹介しながら、具体的な解説をしていきます。

　まずは、図1-1を見てください。この「修正管理表からの抽出・抽象化」シートは、前回紹介した「故障モード影響解析の全体フロー」の1ステップ目の表です。

　最上部の項目は、このシートの管理項目です。それ以降に故障モードを列挙していきます。また、1つの故障モードを1行として記入します。具体的に言えば、修正管理表に記録されている不具合修正の記録1件が1行に対応します。

　1件の記録から「修正管理表から抜粋」に該当する「コマンド・オブジェクト名」列、「不具合現象」列、「原因」列を記入します。今回紹介する事例では、ソフトウエアの構成要素を「コマンド・オブジェクト名」としました。別の構成要素とする際には、「コマンド・オブジェクト名」列の名称を変更します。その際に、後半3つの表にも変更が必要になりますので注意してください。

　「修正管理表から抜粋」の部分を抽象化して、「不具合を抽象化」部分の「処理内容」列と「処理名」列を記入します。「修正管理表から抜粋」の部分の複数行が「不具合を抽象化」の1行に対応する場合もあります。「処理内容」列には不具合の説明を抽象化しつつ書きます。「処理名」列には処理内容を端的に表した名称を記入します。「処理名」は「処理内容」の述部に着目すると決めやすいでしょう。

　例えば、あるデータフォーマットでファイルを保存する場合に、特例的に可変長を許している部分があるとして、その考慮ができていなかったせいで不具合になってしまったとします。「処理内容」列には「ファイルフォーマットの多くは固定長にしているが、～の場合には特例的に可変長を許しており、その読み込み処理を指す」と記入します。「処理名」は「ファイルフォーマットの可変長処理」とします。「処理名」を適切な抽象度にすることで、類似の不具合を未然に防ぐことができるようになります。ただし、あまりにも抽象的にしすぎると、その情報をもとにチェックする人が理解できなくなるので、その点を念頭において作成するとよいでしょう。

抽出した処理をもとにした故障モード列挙

　図1-2の「処理を中心とした故障モード」シートは、2ステップ目の表です。1ステップ目で得られた処理名を「処理名」列にコピーします。もし統合しても不具合の発見に支障が出ないようであれば、2つ以上の処理名を1つに統合してください。例えば、先ほどのファイルフォーマット例の可変長部分がネットワークでの通信（電文）においてもまったく同様のことが言えるならば、処理名を「ファイルフォーマットの可変長処理」から「ファイルフォーマットおよび電文フォーマット（通信フォーマット）の可変長処理」に変更／統合します。

　「着目点」列には、「処理名」列に記入した処理において「どこが不具合の原因になりやすいか」といった考慮すべき項目を記入します。「故障モード」には、処理名において起こる具体的な不具合を書きます。先の可変長ファイルフォーマットの例ですと処理名が「ファイルフォーマットおよび電文フォーマット（通信フォーマット）の可変長処理」なので、故障モードには「～の場合、ファイルフォーマットおよび電文フォーマットに可変長が含まれるが、ファイル読み込み機能、受信機能においてその考慮がない」というような記述になります。

　「具体例」列には実際に発見された不具合を記入します。例えば、「～の場合に、可変長として記入された～のデータが誤って、別のデータとして処理されてしまう」というような内容です。

　1、2ステップ目を実行する際には、エキスパートや対象ソフトウエアに詳しい方の意見をとりいれるようにすると、より適切な故障モードが得られます。