そもそも不具合分析とは？
不具合分析とはプロダクトやサービスで発生した問題（不具合、障害、故障など）について、原因の特定や再発防止策の立案実施を行いうためのプロセスを指します。（なので特定や策定を指さない）
一般的な不具合分析のやり方
基本的には問題の情報整理（条件や再現など）から始まり、原因に対して仮説を立てて、その仮説をもとに検証と原因特定を繰り返していき、特定された段階で対策の立案と実行、結果の検証を行います。
下記のほうな手法を使ったりもします。
- 特性要因図（フィッシュボーンダイアグラム）
- 5回のなぜ（5 Whys）
- なぜなぜ分析（Why-Why Analysis）
- FTA（故障の木解析）
- FMEA（故障モード影響解析）
間違った不具合分析
ここまでで不具合分析については何となくイメージがついてきてると思いますが、実施者の知識や考え方で様々な着地をしてしまいます。そこでこういった場合はうまくいかないなどの代表例をいくつか紹介します。
表層的な原因究明で終わる：事象に対しての対策だけとなり、根本原因への対策ができない。
例：「人為的ミス」「確認不足」など、個人の責任に終始し、根本的なシステムやプロセスの問題に目を向けない。
客観的なデータに基づかない推測：経験則や憶測、思い込みで原因を決めつける。「おそらくこれだろう」という安易な結論に飛びつく。
再現性の確認不足：不具合が再現しない、あるいは再現条件を特定しないまま対策を講じる。
責任追及に終始する：問題の解決よりも、誰の責任かを明確にすることに重点が置かれる。
場当たり的な対策：根本原因に対処せず、その場しのぎの対策で終わる。
例：「気を付けるように」といった精神論での対応。
分析プロセスの欠如：明確な手順やツールを用いず、行き当たりばったりで分析を進める。
上記の間違った不具合分析をしてしまった時に起きること
- 再発防止効果が低い: 根本原因が解消されていないため、類似の不具合や同じ原因の不具合が繰り返し発生する。
- 問題の隠蔽化: 表面的な原因にフォーカスすることで、真の問題が隠蔽され、より大きな問題に発展するリスクがある。
- 組織の学習機会の喪失: なぜ不具合が発生したのか、どうすれば防げるのかという知識が蓄積されず、組織として成長できない。
- モチベーションの低下: 責任追及ばかりが行われると、従業員のモチベーションが低下し、問題報告が上がりにくくなる。
- 無駄なコストの発生: 場当たり的な対策は、根本的な解決に至らないため、不具合対応に要する時間やコストが繰り返し発生する。
正しい不具合分析
人自体を原因としない。また、責任追及の場にしない。の二点が守られていれば、基本的に正しい不具合分析といえるのではないかと思います。では何を原因に絞るべきか？というと事象に対して実行しているプロセスやルール、考え方に原因を導き出せるとより建設的で時間のロスなく分析が行えると思います。
まとめ
100％正しい不具合分析はこの世に存在しないと思います。が、過去に様々な人が経験したことなどの知見を踏まえアンチパターンを避けてよりよい分析と対策の検討に時間が使えれば無駄なく有意義な仕事や考え方に変わっていくのではないとかと思います。ここではQA業務の一環として不具合分析について記載しましたが、どの分析に関しても基本は同じではないかと思います。