第44回不具合対応ブログ（不具合発生時の知見集約）

第8回不具合対応ブログで初動対応について記したが，ここでは知見集約についての手順，注意点について取り上げる．

• 相談するかしないか

これまで経験した全く同じ小さな不具合であると判断される場合は従来通りの手順で進める．しかし，同じではないが同類の不具合であると考えられる場合は注意が必要である．このケースで同じとして進めていった場合，原因が異なる場合があるので時間と経費のロスが生じる．つまり，ベテラン経験者以外はどんな些細な不具合でも周囲に相談すべきという結論になる．ベテラン技術者とは社内の資格や，過去の不具合解決件数の多さで判断すればよい．このどんな些細な不具合でも相談できるかどうかは社内風土によるので，コミュニケーションを良くとることを教育で徹底する．

しかし，大きな不具合や未経験の不具合の場合は自職場だけでなく，他職場も巻き込んだ体制を早期に作って社内のベテラン技術者に相談して進める．これは以前のブログでも取り上げている．

• 意見集約の手順

第14回不具合対応ブログで不具合発生原因を特定するため要因特性図を作成することを紹介した．ここではDRBFMについて紹介する．トヨタ自動車が開発して広く使われている手法であるが，関係者が集まってエクセルのフォーマットを埋めていって次のアクションを決定する．以下に注意点とフォーマットの一例を添付する．フォーマットはマイクロソフトのCopilotで入手可能である．

🎯 DRBFMフォーマット作成のポイント（重要）

DRBFMは「変更点に集中」することが最重要

FMEAのように網羅するのではなく、変更点から波及する問題を深掘りする

「議論（DR）」と「実験（GF）」のセットで成立する

過去の不具合履歴を必ず参照する

リスク評価は簡易でよい（High / Medium / Low）