つぶやき・生活の知恵

原因分析(RCA)が成功する4つの法則

つぶやき・生活の知恵

根本原因分析(RCA)は難しいですよね。

もし、効果的に成功する方法がわかれば、メリットしかないと思いませんか?

ここで学べることは、明日から実践できる効果的な方法です。

まずマインドセットとしてお願いしたいことは、
自分流を一度捨てて、この記事を最後まで読んでみてください。

まず原因分析の目的から知りたい!という方はこちらの記事もおすすめです。


こんな経験をしたことはありませんか?

  • RCAの会議が違う方向に白熱して、少し違う方向性の解決策ができてしまった
  • 再発防止策を実行したが、また同じ事象が発生してしまった
  • 根本原因分析をやってみたが、まとまりのある文書にすることができない
  • 根本原因分析の報告書を、「不十分だ/破綻している/わかりにくい」とダメ出しされた
私の原因分析は、問題点だらけ?

これらの失敗を、もう起こさないための知識を共有します。


この記事が役立つあなたは、きっとこんな人

  • 製造業(食品、機器、自動車、医薬化粧品、伝統工芸、etc.)
  • IT業(SE、プログラミング、プロジェクト推進、etc.)
  • サービス業(レストラン、コンビニ、Uber、etc.)
  • 医療業(事務、看護、医師、技師、etc.)

つまり、全ての人とってこの記事は役に立つと考えています。

この記事を読んで、効果的なたくさんの成功例が生まれて欲しい、そう願っています。

詳しすぎるくらい書いてしまうこともあるかもしれませんが、
各項目の冒頭でも十分な理解が得られるように工夫しますので、どうかご容赦ください。

私の熱量がそのまま文書量に反映されます!

効果的に成功させる4つの「やってほしいこと」

RCAを効果的に成功させる方法のために、
常にやってほしいことは、4つです。これで全部です!

難しいものはありませんし、きちんと解説もつけますよ(๑・̑◡・̑๑)

① 問題を定義して、その問題についてのみ考える

② 推定原因の記述では、対象ひとつに対して、欠陥ひとつを記述する

③ 推定原因のうち、定義した問題につながるものだけを残す

④ ③のうち、推定原因が発生した事実があるものだけを残す

解説

① 問題を定義して、その問題についてのみ考える

原因分析を行う上で非常に重要なことは、
なにが問題か?
を最初に文書化(定義、という)することです。

定義の文書化をどのように行うか、ですが、4W2Hで表現します。

また必ず、対象と欠陥がわかるようにしましょう。

定義した上で、目につくところに設置してください!

これによって、起点(発生した問題)を振り返る手助けになり、
発生した問題と異なる方向にRCAが進んでしまうことを抑止します。

RCAでは、話題が発散しすぎて、発生した問題点と異なることまで言いたくなることがあります。

それはそれで、実は別の問題を予防する良い知識かもしれませんが、
まずは発生した問題に焦点を当てましょう。

「変な方向に進んでいるかもしれない」と思ったときは、
「定義した問題に対する議論からそれていないか?」
と自分や参加者に問いかけてみることです。

4Wとしていますが、文書作成での王道の5Wの「Why」は利用しません。

2Hとは「How」と「How many」で、RCAでは有用な情報になります。

5W1HとはWho(だれが)When(いつ)、Where(どこで)、What(なにを)、Why(なぜ)、How(どのように)を指し示す言葉です。5W1Hを意識し文章を構成することで、伝えたい情報の主旨が明確になり、かつ過不足なく伝えることができます。

https://www.asobou.co.jp/blog/bussiness/5w1h

例えば、
「2022年01月01日に、私がAビル31階の自動扉Aの前に立ったが扉は全く開かなかった」
を4W2Hの要素に分解してみましょう。

ひ、開かない!!

「Who;私」
「When;2022年01月01日」
「Where;Aビル31階」
「What;自動扉A」
「How;開かない」
「How many;全く」
となりますね。

ぜひ「問題を定義して、その問題についてのみ考える」という方法を行なってみてください。

② 推定原因の記述では、対象ひとつに対して、欠陥ひとつを記述する

推定原因とは、定義した問題を引き起こした要因(なぜなぜ分析で出てきた)のことです。

原因の一つとしてあり得る、というものですね。

先程の例を利用すると、要因の一つとして
「自動扉Aのセンサーが、反応していなかった」
が出てくるかもしれません。

このように記述することで、次に紹介する③や④の活動が、
漏れなく、正確に、ロジカルに行えるようになります。

逆にいうと、このルールを守らなければ、
分析に漏れを引き起こし、不正確で、まとまりのない原因分析になります。

重要なことは、
対象ひとつ「扉A」と、欠陥ひとつ「手でひらかなかった」
のセットであるということです。

対象ひとつと欠陥ひとつのセットで!


NG例としては、
「扉や扉のセンサーを手で遮ったり、動かそうとしなかった」
のように、対象複数と欠陥複数のセットにしてしまうことです。

複数の推定原因がある場合は、必ず対象ひとつに対して欠陥ひとつに分解してください。

「自動扉を手で動かそうとしなかった」
「自動扉のセンサーを手で遮らなかった」 と記述しましょう♪

③ 推定原因のうち、定義した問題につながるものだけを残す

RCAでは、推定原因が複数出てきます。

その中で、何が重要な原因をふるい分けする必要があります。
③はふるいわけ作業の1つです。

「自動扉Aのセンサーが、反応していなかった」
だから
「2022年01月01日に、私がAビル31階の自動扉Aの前に立ったが扉は全く開かなかった」
というように、だから、でつながりがっているものは、残すべきです。

つながっていないもの、とは何か?それは「推定原因の飛躍」です。

例えば、
「自動扉を開けるための立ち位置の表示がなかった」
だから、
「2022年01月01日に、私がAビル31階の自動扉Aの前に立ったが扉は全く開かなかった」
などです。

だから、の部分につなぎとなる別の要素ないと、定義した問題につながらないのです。

上の例では、立ち位置の表示がもしなくても、立ち位置にいれば扉は開きます。

つなぎとして、
「センサーが反応していない」
「センサーが反応する立ち位置にいない」
という2つの段階を経ないと、この推定原因を論ずるには時期尚早なのです。

この2つの段階(つなぎ)が事実発生していれば、
初めて「自動扉を開けるための立ち位置の表示がなかった」を論ずる価値が発生します。

飛躍しないように、1歩ずつ

これを守らないと、本当は発生していない原因を分析に挿入してしまうことになり、
今回起きた事象を正確に理解できなくなります。

原因分析に飛躍がないか?振り返りながら進めていきましょう♪

④ ③のうち、推定原因が発生した事実があるものだけを残す

推定原因が発生した事実を、必ず確認するようにしましょう。

もし発生した事実があれば、それは間違いなく「その時に起きていた」ことです。

よく陥りがちなのが、「推定原因」を検証しないで
(つまり事実発生していたかを評価しないままで)、
次のなぜ、を考えてしまうことです。

これでは、「その時に起きたことを理解する原因分析」になっていません。

例えば推定原因を検証しないまま、
↓「センサーが反応していない」
↓「センサーが反応する立ち位置にいなかった」 ※
↓「センサーが反応する立ち位置がわからなかった」
↓「センサーが反応する立ち位置を示す表示がなかった」
と、それらしい原因分析ができてしまいます。

ここで※のポイントで、発生した事実を確認してみて、
「センサーが反応する立ち位置にいなかった(防犯カメラから確認すると、反応する立ち位置にいた)」
となると、この原因分析は破綻します。

また深掘りしていた原因分析の時間も無駄だった、ということになります。

発生した事実を検証することは、
無駄な時間の節約と、効果的な原因分析の助けになります
よ♪

まとめ

  • 要件を定義する
  • 対象ひとつに欠陥ひとつ
  • 定義した問題とつながるか
  • 発生した事実があるか

以上のことを守りながら、原因分析をやると、
やるたびに目に見えて良い内容に変わっていきます。

初めから全てがうまくはいかないかもしれませんが、
ひとつづつでもチャレンジしてみてください(● ˃̶͈̀ロ˂̶͈́)੭ꠥ⁾⁾

いかがでしたか?拙い文章だったかもしれません。
できれば図を増やしたり、文書を見直すことで、より良い記事に育てたいと考えています。

ではまた!

コメント

タイトルとURLをコピーしました