根本原因分析

科学と工学の分野において、根本原因分析（RCA ）は、障害や問題の根本原因を特定するために使用される問題解決の方法です。[ 1 ] ^IT運用、製造、通信、産業プロセス制御、事故分析（航空、^[2] 鉄道輸送、原子力発電所など）、医療（医療診断用）、ヘルスケア産業（疫学用など）などで広く使用されています。根本原因分析は、帰納的（最初に経験的証拠[原因]に基づいて理論[根本]を作成する）および演繹的（経験的データを使用して理論[基礎となる因果メカニズム]をテストする）推論の一種です。

RCA は次の 4 つのステップに分解できます。

• 問題を明確に特定し説明する
• 通常の状況から問題が発生するまでのタイムラインを確立する
• 根本原因と他の原因要因を区別する（例：イベント相関の使用）
• 根本原因と問題の間の因果関係グラフを確立する

RCA は一般に、問題の再発を防ぐために是正措置を講じる修復プロセスへの入力として機能します。このプロセスの名前は、アプリケーション ドメインによって異なります。ISO /IEC 31010によると、RCA には、5 つのなぜ、故障モード影響解析(FMEA)、フォールト ツリー解析、石川ダイアグラム、パレート分析などの手法が含まれる場合があります。

科学と工学において、欠陥を修復し問題を解決する方法は基本的に 2 つあります。

反応型管理とは、問題が発生した後、症状を治療することで迅速に反応することです。このタイプの管理は、反応型システム、^{[3] [4]}自己適応型システム、^[5] 自己組織化システム、複雑適応型システムによって実装されます。ここでの目標は、迅速に対応し、できるだけ早く問題の影響を軽減することです。

一方、プロアクティブ管理は、問題の発生を防ぐことです。この目的には、設計の優れた実践から、すでに発生した問題を詳細に分析し、再発しないように対策を講じることまで、さまざまな手法を使用できます。ここでは、診断の正確さと精度ほどスピードは重要ではありません。問題の影響ではなく、問題の本当の原因に対処することに重点が置かれます。

根本原因分析は、プロアクティブ管理において、問題の根本原因、つまり主要な原因となった要因を特定するためによく使用されます。「根本原因」は単数形で表すのが通例ですが、調査対象の問題の 根本原因は1 つまたは複数の要因で構成される場合があります。

ある要因を除去することで問題の再発を防ぐことができる場合、その要因は問題の「根本原因」とみなされます。逆に、「原因要因」とは、インシデント/イベントの結果に影響を与えるものの、根本原因ではない要因のことです。原因要因を除去すると結果にメリットがもたらされる場合もありますが、再発を確実に防ぐことはできません。

プロアクティブ/リアクティブの全体像を把握するには、ボウタイリスク評価モデルを検討するのが最適です。モデルの中央にはイベントまたは事故があります。左側には、予想される危険と、それらの危険がイベントを引き起こすのを防ぐために設置されている防御ラインがあります。防御ラインとは、運用を管理してイベントを防止するために設置されている規制要件、適用可能な手順、物理的障壁、サイバー障壁です。根本原因分析を使用する優れた方法は、実際のパフォーマンスを適用可能な要件と比較し、パフォーマンスのギャップを特定し、ギャップを埋めて防御を強化することで、それらの防御の有効性をプロアクティブに評価することです。イベントが発生した場合は、モデルの右側、つまり根本原因の特定と損害の軽減に重点が置かれたリアクティブ側になります。

過負荷でヒューズが切れたために停止した機械の調査を想像してください。^[6]調査の結果、ベアリングの潤滑が不十分だったために機械が過負荷になったことが判明しました。調査をさらに進めると、自動潤滑機構のポンプが十分に汲み上げられず、潤滑が不十分だったことが判明しました。ポンプの調査により、シャフトが摩耗していることが判明しました。シャフトが摩耗した理由を調査すると、金属スクラップがポンプに入るのを防ぐ適切なメカニズムがないことがわかりました。これにより、スクラップがポンプに入り、ポンプを損傷することができました。

この問題の明らかな根本原因は、金属スクラップが潤滑システムを汚染する可能性があることです。この問題を解決すれば、一連の出来事が再発するのを防ぐことができます。金属スクラップがシステムに入り込むのを防ぐフィルターがない場合、本当の根本原因は設計上の問題である可能性があります。または、定期的な検査が不足しているためにフィルターが詰まっている場合、本当の根本原因はメンテナンスの問題です。

これを、根本原因が見つからない調査と比較してみましょう。ヒューズ、ベアリング、または潤滑ポンプを交換すれば、おそらく機械はしばらくは再び稼働できるようになります。しかし、根本原因が解決されるまで、問題が再発するリスクがあります。

上記には費用便益分析は含まれていません。1台以上の機械を交換するコストが、ヒューズを交換するまでのダウンタイムのコストを超えているでしょうか？このような状況は、治療が病気よりも悪いと言われることがあります。^{[7] [8]}

費用便益分析がない場合に得られる結論の無関係な例として、人口減少によって得られると主張されているいくつかの利点のトレードオフを考えてみましょう。短期的には年金/退職金制度の納税者が減りますが、人口増加を止めるには、より多くの学校を建設するための費用を賄うために税金を上げる必要があります。これは、治療が病気よりも悪いという問題を説明するのに役立ちます。^[9]

機械を操作する人員について考える場合、考慮すべきコストは財務だけではありません。最終的な目標はダウンタイムを防ぐことですが、それ以上に壊滅的な傷害を防ぐことです。予防は積極的に取り組むことから始まります。

根本原因分析のさまざまな流派や各アプリケーション ドメインの詳細によってアプローチは異なりますが、RCA は一般的に同じ 4 つの手順に従います。

1. 識別と説明:効果的な問題ステートメントとイベントの説明 (たとえば、障害など) は役立ち、適切な根本原因分析を確実に実行するために通常必要です。問題ステートメントは RCA の北極星であり、チームが調査対象に集中できるようにし、道に迷うことを防ぎます。
2. 情報の収集、整理、分析:ほとんどの RCA は、事実調査セッションから始まり、目撃者の証言、イベントの時系列、イベント発生時に進行していた進展に対する適用可能な要件など、入手可能な情報を収集します。この情報を使用して、イベントのシーケンスまたはイベントのタイムラインを確立し、イベントを防止すべき防御策 (管理要件、物理的障壁、サイバー障壁など) を特定できます。また、使用可能なデータベース (是正措置プログラムや安全プログラム データベースなど) を照会して分析し、パレート図、プロセス マップ、フォールト ツリーなどのデータ分析ツールや、パフォーマンス ギャップに関する洞察を提供するその他のツールも使用する必要があります。Lean Six Sigma のデータ分析ツール、統計分析ツール、階層的クラスタリングやデータ マイニングソリューション (グラフ理論ベースのデータ マイニングなど) など、あらゆる数のデータ分析ツールを活用できます。もう 1 つは、ケース ベース推論ツールを使用して、調査中の状況をケース ライブラリに保存されている過去の状況と比較することであり、変更分析、比較タイムライン分析、タスク分析を含めることができます。
3. 防御の分析:イベントや事故を防ぐはずだった防御を特定した後、RCA 以外の調査も含め、すべてのケースで防御の分析 (従来はバリア分析と呼ばれていました) を実施することを強くお勧めします。1 つの方法は、チャートまたは仮想ホワイトボードに防御をリストすることです。次に、各防御について、その防御の有効性の証拠として収集された情報とデータを確認します。私たちが実際に探しているのは、管理要件が満たされなかった、または物理的またはサイバー障壁が回避された、パフォーマンスの欠陥またはギャップです。これらの初期のパフォーマンスのギャップは、より根深い原因の症状にすぎません。これらの症状のあるパフォーマンスのギャップを使用して、以下に概説する一連の調査質問を作成し、因果分析を使用して症状を発生点 (つまり、根本原因) まで追跡します。
4. 焦点を絞った、偏りのない調査質問の作成:入手可能な情報を収集し、それをタイムラインやその他のデータとともにチャートに整理し、入手可能なデータを分析し、防御策の分析を行った後、それらの洞察を使用して優れた質問を作成します。これらの質問は、因果関係の分析のための調査になります。質問は偏りのないものでなければなりません。また、RCA チームの偏りが調査を汚すことがないように、質問は特定の防御策、またはデータ分析 (例:パレート図、プロセス マップ、フォールト ツリー、管理図) やパフォーマンス ギャップに関する洞察を提供するその他のツールからの特定の洞察に結び付けられている必要があります。好奇心を刺激する質問、"確証バイアス" を反映する質問 (つまり、RCA チームが原因と考える答えを導くような質問をする)、または調査を支援する人が調査を中止して撤退する原因となるような非難的な性質の質問は避けてください。
5. 因果分析:収集した事実の証拠、適用可能な要件、および利用可能なデータの分析から、一連の堅牢な調査質問を作成したら、それらの質問を組織の専門家に提出できます。これで因果分析のプロセスが始まります。影響を受ける組織に質問したら、その回答を使用して、フォローアップのソクラテス式の質問を行います。ソクラテス式の質問により、組織が回答を使い果たすか、最後の原因要因が組織の制御を超えるまで、調査は次のより深い原因要因へと進みます。効果的な因果分析を行うには、ファシリテーション スキル、コミュニケーション スキル、ソクラテス式の質問など、多くのスキルが必要です。適切に実施すると、RCA は最も根深い根本原因まで到達します。注意:石川法やフィッシュボーン ダイアグラム、および5 つのなぜの方法は、根本原因分析を行うには厳密さが足りません。フィッシュボーン分析は 1940 年代、5 つのなぜ分析は 1930 年代に考案されたもので、さらに高度な手法が存在します。今世紀 (2000 年以降) に開発された手法を探してください。これらの手法は、現代の社会技術的な作業環境の新しい動向に対応している可能性が高いからです。
6. RCA の結果の図表化: RCA 調査の結果を図表化する最良の方法は、最初から最終図表の作成を開始することです。このプロセスは、仮想ホワイト ボードの登場により、はるかに簡単になりました。単一の仮想ホワイト ボードで、タイムライン、防御ライン、データ分析、調査質問ライン、因果分析、根本原因、是正措置計画を表示できます。
7. 再発防止のための是正措置:管理の観点から見ると、根本原因、寄与要因、および「原因の範囲」に対処するための包括的な是正措置計画がなければ、RCA の取り組みは完了しません。是正措置計画は問題の所有者が作成する必要があり、RCA チームの参加は必須ではありませんが、チームは問題の所有者にとって優れたガイダンス ソースとなります。原因の範囲のレビューは、根本原因と寄与要因が人間、機器、または施設に与えた損害または影響の範囲を判断するために実施されます。原因の範囲のレビューは、ほとんどの組織にとっての弱点であり、RCA と是正措置計画が再発を防止できない主な理由です。また、組織に管理要件とトレーニングを追加するだけの是正措置計画を回避するように注意する必要があります。これを回避するには、再発を防止する可能性がはるかに高い効果的な是正措置を開発するためのガイドラインとして、ハザード コントロールの階層と Lean ミス防止を使用します。
8. 有効性レビュー:是正措置計画の実施後、所定の期間が経過すると、是正措置の有効性を評価するための有効性レビューが予定されます。これには、是正措置の実施前と実施後に監視される一連のメトリックまたは指標を指定する必要があります。これにより、その影響を測定できます。望ましい結果が得られない場合 (ほとんどの場合、イベントまたは問題の規模または頻度が大幅に減少します)、RCA は効果的でなかったため、再度開始する必要があります。

根本原因分析を効果的に行うには、体系的に実行する必要があります。このプロセスにより、他の重要な詳細を見逃す可能性がなくなります。通常はチームの努力が必要であり、関係者全員が同じ結論に達するのが理想的です。たとえば、航空機事故の分析では、調査の結論と特定された根本原因は、文書化された証拠によって裏付けられる必要があります。^[10]

RCA の目標は、問題の根本原因を特定し、問題の再発や悪化を防ぐことです。次のステップは、RCA 中に特定された根本原因に対処するための長期的な是正措置を開始し、問題が再発しないようにすることです。ただし、問題の修正は正式には RCA の一部ではありません。これらは、IT および電気通信における障害管理、エンジニアリングにおける修復、航空における修復、生態学における環境修復、医学における治療など として知られる問題解決プロセスの異なるステップです。

根本原因分析は、多くのアプリケーション ドメインで使用されています。RCA は、米国連邦規則集の多くのタイトルで具体的に言及されています。例:

1. タイトル 10 - エネルギー >>> 10CFR パート 50、付録 B、基準 XVI、「是正措置」(NQA-1 でも採用)
   • 「故障、不具合、欠陥、材料や設備の欠陥、不適合など、品質に悪影響を及ぼす状態が速やかに特定され、是正されることを保証するための措置を確立しなければならない。」
   • 品質に重大な悪影響を与える状況が発生した場合、その措置により状況の原因が特定され、再発を防止するための是正措置が講じられることを保証するものとする。」
2. タイトル 14 - 航空宇宙 >>> 14 CFR 第 III 章、サブチャプター C、パート 437、サブパート C、§437.73 異常の記録、報告、および是正措置の実施。
   1. 許可者は、安全上重要なシステム、サブシステム、プロセス、施設、またはサポート機器に影響を与える各異常を記録する必要があります。
   2. 許可者は、各異常のすべての根本原因を特定し、各異常に対するすべての是正措置を実施する必要があります。
3. タイトル 21 - 食品および医薬品 >>> 21 CFR サブパート J: 21CFR820.100(a) – 是正/予防措置: (A) 各製造業者は是正措置および予防措置を実施するための手順を確立し、維持する必要があります。手順には、次の要件が含まれます。
   1. 製品、プロセス、品質システムに関連する不適合の原因を調査する。
   2. 不適合製品およびその他の品質問題の修正および再発防止に必要な措置を特定する。
   3. 是正措置および予防措置が効果的であり、完成したデバイスに悪影響を及ぼさないことを確認するために、是正措置および予防措置を検証または検証する。
4. タイトル 42 - 公衆衛生 >>> 42 CFR PART 488、調査、認証、および施行手順 > サブパート E - 長期ケア施設の調査と認証
   1. §488.61 臓器移植プログラムの承認および再承認に関する特別手順。
   2. ...患者死亡および移植失敗の根本原因分析（プログラムによって患者死亡および移植失敗の原因または寄与要因として特定された要因を含む）。

上記の例は、製造業で RCA がどのように使用されるかを示しています。RCA は、化学薬品の生産制御 (品質管理) など、工業プロセス制御でも日常的に使用されています。

RCA はエンジニアリングやメンテナンスにおける障害解析にも使用されます。

根本原因分析は、深刻な問題の根本原因を検出するために IT および通信業界で頻繁に使用されます。たとえば、ITILサービス管理フレームワークでは、インシデント管理の目標は障害のある IT サービスをできるだけ早く再開すること (リアクティブ管理) ですが、問題管理は、根本原因に対処することで繰り返し発生する問題を完全に解決すること (プロアクティブ管理) を目的とします。

もう一つの例は、コンピュータセキュリティインシデント管理プロセスであり、根本原因分析はセキュリティ侵害の調査によく使用されます。^[11]

RCA は、ビジネス アクティビティ監視や複合イベント処理と組み合わせて使用​​され、ビジネス プロセスの障害を分析するために使用されます。

IT 業界での使用は、安全性が重要な業界での使用と常に比較できるわけではありません。通常、IT 業界での RCA の使用は、既存のフォールト ツリーやその他の設計仕様によってサポートされていないためです。代わりに、デバッグ、イベント ベースの検出、監視システム (サービスが個別にモデル化されている) の組み合わせが通常、分析をサポートします。すべての予想されるシナリオに対するシミュレーションやさまざまな詳細なランブックなどのトレーニングおよびサポート ツールは存在せず、代わりに「価値がある」と見なされた問題に基づいて事後に作成されます。その結果、分析は監視/観察インターフェイスを持つものに限定されることが多く、入力と出力の検証に重点を置いた実際の計画/確認された機能には限定されません。そのため、IT 業界では「根本原因はない」という言い回しが一般的になりました。

健康と安全の分野では、RCAは医学（診断）や疫学（感染症の原因の特定など）で日常的に使用されており、因果推論法ではプロセスの複雑さを理解するために臨床的専門知識と統計的専門知識の両方が必要になることが多い。^[12]

RCAは、環境科学（例：環境災害の分析）、事故分析（航空・鉄道業界）、労働安全衛生の分野で使用されています。^{[13]医療機器、 [14]}医薬品、^[15]食品、^[16]栄養補助食品^[17]の製造においては、根本原因分析が規制上の要件となっています。

RCA は、変更管理、リスク管理、システム分析にも使用されます。

特定の問題の特異性を詳しく調べなくても、いくつかの一般的な条件により、RCA は一見したよりも困難になる可能性があります。

まず、実際にはすべてを監視し、すべての監視データを長期間保存することは一般的に不可能であるため、重要な情報が欠落していることがよくあります。

第二に、データと証拠を収集し、それらをイベントのタイムラインに沿って分類して最終的な問題に結びつけることは、簡単ではありません。たとえば、通信業界では、分散監視システムは通常、1 日に 100 万から 10 億のイベントを管理します。このような無関係なイベントの山からいくつかの関連イベントを見つけることは、干し草の山から針を探すようなものです。

3 番目に、特定の問題には複数の根本原因がある場合があり、この多重性により因果関係のグラフを確立することが非常に困難になる可能性があります。

4 番目に、因果グラフには多くのレベルがあることが多く、根本原因分析は調査者の目に「根本」であるレベルで終了します。上記の産業プロセス制御の例をもう一度見てみると、より詳細な調査により、工場のメンテナンス手順には 2 年ごとの潤滑サブシステムの定期検査が含まれていたのに対し、現在の潤滑サブシステム ベンダーの製品では 6 か月の期間が指定されていたことが明らかになります。ベンダーを切り替えたのは、経営陣がコストを節約したいと考え、変更がメンテナンス手順に与える影響についてエンジニアリング スタッフに相談しなかったためである可能性があります。したがって、上記の「根本原因」によって、引用された再発は防げたかもしれませんが、他のマシンに影響を与えるその他の (おそらくより深刻な) 障害は防げなかったでしょう。

• Abubakar, Aisha、Bagheri Zadeh, Pooneh、Janicke, Helge、Howley, Richard (2016)。「個人情報盗難の調査における予備ツールとしての根本原因分析 (RCA)」。2016 年サイバー セキュリティおよびデジタル サービスの保護に関する国際会議 (サイバー セキュリティ) 議事録。
• Babaoglu, O.; Jelasity, M.; Montresor, A.; Fetzer, C.; Leonardi, S.; van Moorsel, A.; van Steen, M. 編 (2005)。複雑な情報システムにおけるセルフスター特性; 概念的および実践的基礎。LNCS。第 3460 巻。Springer。
• IATA (2016 年 4 月 8 日)。「民間航空当局および航空管制サービス プロバイダー向けの根本原因分析」。国際航空運送協会。2016 年 4 月 8 日時点のオリジナルからアーカイブ。2017年11 月 17 日に取得。効果的な根本原因分析を実施するための重要な手順、根本原因の特定に使用するツール、効果的な是正措置計画の作成方法。
• Lewerentz, Claus; Lindner, Thomas, 編 (1995)。反応システムの形式的開発; ケーススタディ生産セル。LNCS。第 891 巻。Springer。
• Manna, Zohar; Pnueli, Amir (1995)。反応システムの時間的検証：安全性。Springer。ISBN 978-0387944593。
• 大野耐一（1988年）『トヨタ生産方式：大規模生産を超えて』オレゴン州ポートランド：プロダクティビティ・プレス、17頁。ISBN 0-915299-14-3。
• OSHA、EPA。「ファクトシート：事故調査における根本原因分析の重要性」（PDF）。労働安全衛生局。 2019年3月22日閲覧。
• Sofema (2017 年 11 月 17 日)。「安全管理担当者と事業エリア所有者のための根本原因分析」。Sofema Aviation Services。2017年 11 月 17 日のオリジナルからアーカイブ。2017年11 月 17 日に取得。効果的な根本原因分析 (RCA) を実行するためのベスト プラクティス手法と行動を特定します。
• Wilson, Paul F.; Dell, Larry D.; Anderson, Gaylord F. (1993)。根本原因分析: 総合的品質管理のためのツール。ミルウォーキー、ウィスコンシン: ASQ Quality Press。ISBN 0-87389-163-5。

• 問題解決マップ (PSMap) RCA ソフトウェア
• BlueDragon 統合問題解決システム (IPS)
• 「根本原因分析と監視ツール: 完璧な組み合わせ」Irene Carrasco 著
• 「アポロ根本原因分析」
• 「原因マッピングによる視覚的な説明」
• 「ソロジック根本原因分析法」
• 「根本原因分析の基礎」
• 「DOE 根本原因分析文書」