メインコンテンツへスキップ
カテゴリ: 方法
タイプ: 問題解決テクニック
起源: 品質管理運動、1950年代、米国
別名: RCA、ルートコーズアナリシス、原因分析
先に答えると — 根本原因分析（RCA）は、問題や出来事の根本的な理由を特定するための体系的なアプローチです。即座の症状を修正するのではなく、RCAはより深く掘り下げて、対処すれば再発を防ぐことができる根本原因を見つけます。第二次世界大戦後の製造業の品質管理原則から発展したRCAは、医療、ソフトウェアエンジニアリング、航空、業界全体のインシデント管理において不可欠なものとなっています。

​
根本原因分析とは

根本原因分析（Root Cause Analysis）は、問題の根本的な原因を特定するために使用されるテクニックのファミリーを指す総称です。核心原則は驚くほどシンプルです。何かがうまくいかないとき、目に見える問題を修正するだけでなく、なぜそれが最初に起こったのかを見つけ出し、それを修正するのです。 症状と原因の区別は基本的です。症状は観察されるものです。バグ、失敗、苦情です。根本原因は、症状が存在する根本的な理由です。症状を治療すると一時的な緩和が得られます。根本原因を治療すると恒久的な解決策が得られます。この区別は明白に聞こえますが、実際には、組織は日常的に症状の治療にリソースを費やし、根本的な病気は放置され続けています。 RCAは通常、構造化されたプロセスに従います。問題を定義し、データを収集し、可能な原因を特定し、根本原因を決定し、是正措置を実施します。原因を特定する方法はさまざまです。「5つのなぜ」や特性要因図などの特定のフレームワークを使用するものもあれば、より洗練された統計的またはシステム思考アプローチを使用するものもあります。
「根本原因を排除しなければ、問題は再発する。それだけのことです。」— トヨタ生産方式の原則
RCAの価値は問題解決を超えて広がります。厳格な根本原因分析を実践する組織は、故障モードに関する組織的知識を構築し、時間の経過とともに回復力が高まります。適切に行われる各RCAは、システムがどのように故障し、どのように故障を防ぐかについての理解の蓄積に追加されます。

​
根本原因分析の3層の理解

  • 入門: 問題に直面したとき、何が起こったか（症状）と、なぜ起こったか（原因）を区別してください。「5つのなぜ」テクニックを使用して、実際に対処できる原因を見つけるまで一度に1レベルずつ掘り下げてください。
  • 実践: 特性要因図を使用して問題空間をマッピングし、複数の潜在的な原因を特定してから、データと実験を使用して、どの原因が最も重要かを絞り込んでください。
  • 上級: システム思考を適用して、再発する問題パターンを生み出すフィードバックループと二次効果を特定してください。複数の相互作用する故障を持つ複雑なシステムには、フォールトツリー分析などのテクニックを使用してください。

​
起源

根本原因分析は、第二次世界大戦後の米国の品質管理運動から生まれました。W・エドワーズ・デミングとジョセフ・ジュランの仕事の影響を受けて、日本の製造業者は品質を改善するために欠陥を体系的に分析し始めました。このアプローチは1950年代と1960年代に成熟し、トヨタ生産方式として知られるようになりました。 「根本原因分析」という用語自体は、1990年代に広く使用されるようになりました。特に、いくつかの著名な事故に続いて原子力産業と航空産業が採用した後です。1979年のスリーマイル島事故と1986年のチャレンジャー号爆発事故の両方が、高リスク産業における体系的な根本原因分析の重視につながりました。 ソフトウェア開発では、RCAは2000年代にDevOpsとサイト信頼性エンジニアリングの台頭とともに注目されました。GoogleのSREブックとNetflixのカオスエンジニアリングの実践は、インシデントの管理とシステムの信頼性の改善のためのコア実践としてRCAを形式化しました。

​
核心要点

1

症状と原因を分離する

観察されるもの（症状）は、修正が必要なもの（原因）ではありません。RCAの最初のステップは、原因と混同せずに問題を明確に定義することです。
2

異なる文脈に複数のテクニック

単一のRCA方法がすべての状況に有効なわけではありません。5つのなぜは線形因果連鎖に有効です。特性要因図は複雑な多要素問題に有効です。フォールトツリー分析は重大な故障モードを持つシステムに有効です。
3

実施前に検証する

複数の潜在的な根本原因を特定してから、データまたは実験を使用して、実際に問題を駆動している原因を検証してください。検証されていない原因の修正を実施するとリソースの無駄になります。
4

システム的なパターンを探す

個々の問題は多くの場合、共通の根本原因を共有しています。時間の経過とともにRCAの発見を追跡すると、一度修正すれば複数の問題タイプを同時に排除できるシステム的な問題が明らかになります。

​
応用場面

ソフトウェアインシデント管理

本番インシデント後、正式なRCAは技術的な故障だけでなく、それを許容したプロセス、モニタリング、設計のギャップも特定します。

医療患者の安全

有害事象が発生したとき、RCAはコミュニケーションプロトコル、ワークフロー設計、人員配置などのシステム的要因を特定し、個人の過失に帰しません。

製造業の品質管理

欠陥が発見されたとき、RCAはそれらを引き起こしたプロセスのばらつきと機器の問題を追跡し、ターゲットを絞ったプロセス改善を可能にします。

プロジェクトの振り返り

プロジェクトの失敗や成功の後、RCAのような分析は結果に影響を与えたシステム的要因を特定し、組織的学習を可能にします。

​
事例

医療において、医療改善研究所は1999年の画期的な報告書「To Err Is Human」の後、RCAを中核的な患者安全実践として推進しました。文書化されたケースの一つでは、患者が誤った部位の手術を受けた病院が関与していました。表面的な分析は個々の外科医を責めるでしょう。RCAは代わりにシステム的な原因を特定しました。混乱した手術部位マーキングプロトコル、手術室の時間的プレッシャー、上級外科師への質問を妨げる文化です。 病院はシステム的な変更を実施しました。普遍的な手術部位マーキングプロトコル、切開前の「タイムアウト」による口頭確認の要求、懸念がある場合にどのチームメンバーでも手術を停止できる「レッドフラグ」ポリシーです。実施後、誤った部位の手術はほぼゼロに減少しました。個人がより注意深くなったからではなく、システムがエラーを実質的に不可能にしたからです。 テクノロジーでは、Etsyが2013年の2時間続いたサイト停止後にRCAを実施しました。彼らの分析は、引き金がデプロイされたコード変更であった一方で、根本原因は不十分なカナリアテストと不明確なロールバック手順であることを明らかにしました。彼らは自動カナリア分析と簡素化されたロールバックプロセスを実装し、将来のインシデントが長時間の停止を引き起こす可能性を低くしました。

​
境界と失敗モード

適切なRCAには専用の時間、場合によっては外部の専門知識が必要です。「次に進む」プレッシャーの下にある組織は、再発を防ぐために必要な深さをスキップすることがよくあります。
データ検証なしに、RCAチームは実際のものではなく、最も明白または政治的に都合の良い原因に収束することがよくあります。常に証拠で検証してください。
システム的な修正は多くの場合、プロセスの変更、新しいツール、またはトレーニングを必要とします。コストは単一のインシデントに対して不均衡に思える可能性があり、累積的な影響を理解せずに正当化するのが難しくなります。

​
よくある誤解

RCAは成功にも同様に適用されます。何かがうまくいった理由を理解すると、システムとプロセスで維持し拡大すべきことが明らかになります。
5つのなぜは単純な因果連鎖に有効ですが、複雑な多要素問題には失敗します。特性要因図は複雑な問題をマッピングするのに役立ちますが、追加の検証が必要です。問題に適したツールを使用してください。
RCAは是正措置に続く場合にのみ価値があります。修正を実施せずに根本原因を特定することは、学術的な演習であり、問題解決ではありません。

​
関連概念

5つのなぜ

5つのなぜ は、最も一般的に使用されるRCAテクニックの一つであり、反復的な質問を使用して根本原因まで掘り下げます。

特性要因図

特性要因図 は、潜在的な原因をカテゴリ別に視覚化するもう一つのRCAテクニックです。

第一原理思考

第一原理思考 は、根本的な真実への分解を奨励することで、RCAの哲学的基盤を提供します。

​
一言で言うと

症状を治療して緩和し、根本原因を治療して治す。根本的な原因を見つけるために時間を投資すれば、修正は持続します。