根本原因分析 – 原因マッピング
概要
根本原因分析 — 原因マッピングは、チームが問題を体系的に調査するのに役立つ、構造化された視覚的なツールです。組織の目標への影響を起点に、各ステップで「なぜ？」と繰り返し問いながら、左から右へ原因をたどっていきます。複数の独立した原因が該当する箇所ではマップが枝分かれし、問題がどのように発生したかの全体像を明らかにします。その後、解決策はそれぞれが対処する特定の原因に直接紐付けられ、チームは単一の「根本原因」を追いかけるのではなく、最も効果的かつ費用対効果の高い対策を選べるようになります。
利用対象
このテンプレートは、インシデント、欠陥、システム障害、または再発する問題を調査するあらゆるチームに役立ちます。安全チームは、けがやヒヤリ・ハットの調査に使用します。オペレーションマネージャーは、プロセスの破綻や生産遅延の分析に活用します。品質エンジニアは、欠陥の原因をたどります。プロジェクトマネージャーは、スケジュールの遅れや予算超過の原因を診断します。IT および DevOps チームは、システム停止やパフォーマンス障害をマップします。人事チームは、職場での対立や離職の傾向を調査します。部門横断のチームは、部門間で共通の理解を築く視覚的かつ証拠に基づく構造から、特に恩恵を受けます。
使用方法
(a) 問題の概要を記入する – 問題の内容、発生した日時と場所、どの組織の目標に影響があったかを記録します。
(b) 影響を特定する – 安全、顧客満足度、コスト、スケジュール、品質のうち、どの目標が損なわれたかを明確にします。
(c) 原因マップを作成する – 影響から出発し、各ノードで「なぜ？」と問いながら左から右へ進めます。同じ段階で複数の独立した原因がある場合は、マップを分岐させます。
(d) 証拠を記録する – 各原因を裏付けるログ、記録、写真、面談、データなどを文書化します。証拠のない原因は推測に過ぎません。
(e) 考えうる解決策を特定する – 解決策欄で、各解決策をそれが対処する特定の原因に紐づけます。所有者、期限、および意思決定ステータス（承認済み、検討中、却下）を割り当てます。
(f) 最適な組み合わせを選ぶ – 再発を確実に防げる、最も費用のかからない解決策の組み合わせを選びます。マップ上のすべての原因を修正する必要はありません。
例について
この例では、倉庫での滑って転倒した負傷事故を調査します。従業員が 7 月 14 日 14:20、シフト交代時に通路 4 で滑って足首を捻挫し、休業を伴う安全事故となり、45 分の稼働停止が発生しました。
原因マップは、同じ段階で同時に存在していた 2 つの独立した原因に分岐します。1 つは摩耗した配管継手からの水漏れ（点検スケジュールが存在しなかった）、もう 1 つは濡れた床の注意表示が掲示されていなかったこと（漏水が 40 分間報告されなかった）です。証拠としては保守ログ、清掃当番表、CCTV のタイムスタンプ、シール検査報告書が含まれます。
3 件の対策が特定され、それぞれ別の原因を対象としています：シールを交換し、四半期ごとの配管点検を導入する（設備チーム、承認済み、期限: 9月5日）；各通路の端に床濡れ注意の標識を常備する（運用チーム、承認済み、期限: 8月25日）；および各シフト交代時に 15 分の床点検を実施する（シフトリーダー、検討中、期限: 9月1日）。この例は、1 つの事象から複数の要因へとマップが分岐する様子と、解決策が一つの根本原因を探すのではなく、マップ上の異なる箇所に対応していることを示しています。
よろしくお願いします。
カワジャ・リズワン
