【応用スキル】トラブル対策の手順(3)【②発生原因推定】 | ものづくりエンジニアのたまり場ブログ・・・【mono-B-LOGue】

【応用スキル】トラブル対策の手順(3)【②発生原因推定】

今回のテーマはこれです。

【問題発生時の処置フロー】
①現状確認
②発生原因推定
③対策案策定
④対策実施
⑤対策実施結果フォロー
⑥再発防止対策策定


「②発生原因推定」

問題が発生するパターンというのはいくつかあります。

(a) 確認漏れや単純ミス、手抜き
(b) システムや機械の誤動作
(c) 情報伝達不足
(d) 普段と違うことをした

まず、「①現状確認」にて時系列的に並べた関連事象を眺めながら、おかしなところがないかチェックします。

(a)は通常のフローで出てくるはずのアウトプットがなかったり、参照しているはずのデータがないとか、違っているなど、比較的見つかりやすいパターンです。

(b)は異常が発生したことが明らかならば原因推定は楽になりますが、そうでない場合かなり面倒です。バグ取りになるような状況になることもあるでしょう。

(c)は実際に動いた側の人にとっては正しいこと。指示した側からすると間違ったこと、という図式です。コミュニケーションの欠落です。

(d)は実は、一番はじめに疑うべき項目です。ちょっとしたことで普段と違うことをしがちでニュースの重大性に気付かずにスルーしやすいのもこのパターンの難しい所です。

もちろん、上にあげた4つだけでなく、「そんなことが?」と疑ってしまうような事象が原因の場合もありますし、原因が複数にまたがっていることもあります。

このとき、トラブル状況を確認した際に集めたデータを眺めながら、推定原因となる事象が再度が発生した場合トラブルが再現するか、推定原因とトラブル状況に矛盾かないか、根気よくトラブル発生原因の推定を行います。
「トラブルの原因となる何かが必ずそこにある」というスタンスです。

①で現状の確認を行ったときに集めたデータが信頼性の高いものであればあるほど、一見矛盾があるように見えることも無視せず、全てのデータの辻褄があう状況を探すことが重要です。
重要なポイントを見逃しているからこそ、正しいはずのデータに矛盾があるように見えるということがあります。
そこにトラブル発生原因が埋れている可能性が高いのです。


【まとめ】
トラブル発生原因推定においては、トラブル状況とそれに繋がるデータの矛盾を解消するような状況を探すことで、真の原因に近づくことができる

次は「③対策案策定」です。

ranking ブログランキング・にほんブログ村へ