不具合を分析しすぎてチームに悪影響を与えたかもしれない

担当サービスの品質を担保するというのが仕事の1つなので、不具合の分析などを行うことはよくある。
ここでいう分析とは以下のことを指してる

不具合がいつからいつまで発生していたか
なぜ発生したか
どのような対応をおこなったのか
ユーザにどのような案内をしたのか
(ソーシャルゲームなので)どのようなお詫び(アイテム補填)をしたのか
どうやったら再発しないようにするか

この辺の分析はある程度の経験やスキルが必要だと思っている。ユーザへの案内などは

自分が草案を出して、企画職やCSがそれに補完する
- 例：過去の事例に照らし合わせるとか、ルール上問題ないか
企画職やCSが草案を出して自分が補完する
- 例：長文で書くよりも箇条書きにしようとか、時系列で書くとか

という感じでやっているので、まぁ得意不得意を補完してていいかなーとは思える。

今回のメインは「なぜ不具合が発生したか」というところ。
基本全員日々の作業に追われているし、嫌な過去は見たくないものなのであまり調べたがらない。
~~みんな不都合な過去をなかったことにしたいからソシャゲやってる会社はダメだと叩かれる~~
が、ある程度エンジニア(特にSIer)をやっていると「なぜを3回繰り返せ」というありがたい教えを聞かされるはずだ。自分は新卒2年目で叩きこまれた。
Web業界にきてだいぶ年数が経つが、若い時に叩きこまれたことは習慣(悪いものは呪いという)のようになるので癖で調べてしまう。

分析する上で色々話をきかせてもらった結果、チームが必要以上に不具合に敏感になりすぎてる気がする。
敏感になりすぎている人と鈍感なままな人がいるというのが正確な表現

もちろん不具合はないほうがいい。不具合を起こして誰も幸せにならないからだ。
みんな可能なかぎりゼロにすることを心がけてる。作ってる人みんなで触ってみてる場も儲けてるし、QAテストも時間かけてる。
ユーザへの影響がほとんどないものはさっさと直せばいいし、そこをいちいち分析しても大した答えは出てこないと思う。
変に敏感になり過ぎててなんか硬直してる(動きが遅い)組織になってきてる気がする。

この辺はみんなどういうマネジメントしてるんだろうか