影響解析

影響解析

　図2-1の「影響解析（FMEAシート）」シートは3ステップ目です。1ステップ目で得られた「処理名」列をコピーします。また、2ステップ目で得られた「故障モード」列を「影響解析（FMEAシート）」シートの「故障モード」列にコピーします。この時点で処理別のチェックリストができていると考えるとわかりやすいでしょう。

　おのおのの故障モードが起こった際に、どのような結果となるかを「影響内容」列に記入します。影響内容が場合分けできる場合には、その数だけ記入します。「影響」「発生」「検出」列にはそれぞれ故障モードが起きた場合の影響度合いや、（利用・運用時に故障モードが発生する）発生頻度、検出の難しさを5段階で記入します。

　図2-2の「ランク値表」シートは、5段階を決める際の参考値です。あくまで参考なので、ソフトウエアやプロジェクトの状況に応じて適切なものに変更してください。これら3つの値を掛け算したものが、後述するRPN（Risk Priority Number：リスク優先数）になります。ですので、0は使わず、1～5の間の値を使ってください。

　「RPN」列は「影響」「発生頻度」「検出」列の積です。FMEAシートが完成したら、RPNが大きいものから順番に対策を考えていきます。「原因」列には、故障モードが発生する原因を書きます。

　「対策」列には、故障モードを起こさないための対策を記入します。対策は「注意する」「考慮する」などの抽象的な表現だけではなく、「設計時に漏れがないようチェックリストを用いて調べる」や、「コンパイル時に警告が出力されるようにする」、「テスト項目に必ず加える」など、防止／検出の仕組みを記入してください。

　「工程」欄には、故障モードに記入されたものと類似する不具合が発見できる工程のうちもっとも早い段階を記入します。例えば、詳細設計のミスで混入するものであれば「詳細設計」と記入します。コーディングミスであれば、コーディングになります。

　「原因」列は故障モード発生の原因となる考慮漏れや、チェック方法のミスなどを記入します。前のページで示した可変長部分を持つファイル／電文フォーマットの場合は、「特例的に許している可変長データ構造の考慮忘れ」が原因の記入例になるでしょう。

　「対策」列には、原因を根本的に防ぐ方法や、手順化の定義（強制）により防ぐ方法、テストをはじめとした確認作業により検出できる方法を記入します。先の例ですと、例えば「詳細設計書レビュー、コードレビューに使うチェックリストに『ファイル／電文フォーマットの可変長データ構造への考慮はあるか？』を追加する」と記入します。

　「工程」列には具体的な対策をどの工程で実施するかを記入します。複数の工程が該当する際には、すべて記入します。「詳細設計書レビュー、コードレビューに使うチェックリストに『ファイル/電文フォーマットの可変長データ構造への考慮はあるか？』を追加する」の場合には、「詳細設計」「コーディング」を記入します。

影響解析結果を用いた欠陥予防

　完成した影響解析結果（FMEAシート）をRPN（リスク優先数）の大きな順番にならべ、その順番にチェックしていくと、過去に総合テストでみつかった不具合のうち致命的なものから順に対応していくことができます。すべてのチェックが難しい場合でも、開発期間やコストを勘案しながら、できる範囲での欠陥予防や指摘ができるようになります。

　一般にFMEAシートは、複数のエキスパートが頭を突き合わせて起こり得る故障モードを列挙しながら作ることが推奨されています。

　しかし、現実問題として、特にソフトウエアを対象とした場合、複数のエキスパートが集まる時間の確保や、起こり得る故障モードの列挙は難しいと言えるでしょう。そのため、不具合や処理の抽象化は、やはり対象に対する知識をたくさん持ったベテランが行うのが、現実的だと考えています。また、今回紹介した方法では、過去の総合テストで発見された不具合をもとに作成しています。