根本原因分析 – 原因マップ
概要
Root Cause Analysis – Cause Mappingは、チームが問題を体系的に調査するのに役立つ、構造化された視覚的ツールです。組織の目標への影響から出発し、この手法では各段階で「Why?」と繰り返し問いかけながら、原因を左から右へとたどっていきます。複数の独立した原因が当てはまる箇所ではマップが分岐し、問題がどのように発生したかの全体像を明らかにします。解決策は、それぞれが対処できる特定の原因に直接紐づけられるため、チームは単一の「根本原因」を追いかけるのではなく、最も効果的で経済的な対策を選択できます。
誰が利用できますか
このテンプレートは、インシデント、欠陥、障害、再発する問題を調査するあらゆるチームに役立ちます。安全チームは負傷やニアミスの調査に使用します。オペレーションマネージャーは工程の破綻や生産遅延の分析に活用します。品質エンジニアは欠陥の原因をたどります。プロジェクトマネージャーはスケジュール遅延や予算超過の原因を特定します。IT および DevOps チームはシステム障害やパフォーマンスのインシデントをマップします。人事チームは職場での対立や離職パターンを調査します。部門横断のチームは、視覚的かつ証拠に基づく構造により部門間で共通理解を築けるため、特に有益です。
使用方法
(a) 問題の概要を記入する – 問題が何か、いつ・どこで発生したか、どの組織目標に影響したかを記録してください。
(b) 影響を特定する – どの目標が影響を受けたかを指定してください: 安全、顧客満足度、コスト、スケジュール、または品質。
(c) 原因マップを作成する – 影響から始め、各ノードで "Why?" と問い、左から右へ進めてください。同じ段階で複数の独立した原因がある場合は、マップを分岐させてください。
(d) 証拠を記録する – 各原因を裏付けるログ、記録、写真、聞き取り、またはデータを記録してください。証拠のない原因は推測にすぎません。
(e) 考え得る解決策を特定する – 解決策欄で、各解決策をそれが対処する特定の原因に紐づけてください。所有者、期日、意思決定状況 (承認済み、評価中、却下) を割り当ててください。
(f) 最適な組み合わせを選択する – 再発を確実に防げる、最も安価な解決策の組み合わせを選択します。マップ上のすべての原因を修正する必要はありません。
例について
この例では、倉庫で発生した滑倒による負傷事故を調査します。従業員がシフト交代中の7月14日 14:20に通路4で滑って足首を捻挫し、休業を伴う安全事故となり、45分のダウンタイムが発生しました。
原因マップは、同時に存在していた必要がある2つの独立した原因に分岐します: 摩耗したパイプ継手からの水漏れ（点検スケジュールが設定されていなかった）と、床が濡れていることを示す表示が掲示されていなかった（こぼれが40分間報告されなかった）。証拠には保守記録、清掃当番表、監視カメラのタイムスタンプ、シール検査報告書が含まれます。
3つの対策が特定され、それぞれ異なる原因を対象としています: シールを交換し四半期ごとの配管点検を導入する（施設, 承認済み, 締切 9月5日）；各通路の端に滑り注意の表示を配置する（オペレーション, 承認済み, 締切 8月25日）；および各交代時に15分の巡回点検を実施する（シフトリード, 評価中, 締切 9月1日）。この例は、単一の事象からマップが複数の寄与要因に分岐する様子と、対策がマップ上の異なる箇所を対象としており、単一の根本原因を探すのではないことを示しています。
乾杯!
カワジャ・リズワン
