根本原因分析
根本原因分析（root cause analysis）とは、何かがうまくいかなかった理由を、答えが動かなくなるまで問い続ける方法です。根を直せば、その上にある症状も一緒に消えます。症状を直しても、問題はまた戻ってきます。品質管理、ITのインシデント対応、患者安全、航空のいずれの分野でも、障害の後に根本原因分析が求められます。手法の違いは主に誰が推論するかにあります。
手法
なぜなぜ分析（5 whys）障害について「なぜ」と問い、その答えについてまた問う、これを5回繰り返します。一人か小さなチームで行います。速くて安上がりで、原因の連鎖を一本見つけます — 問う人がすでに疑っている連鎖です。一つの仕組みによる一つのインシデントには向いていますが、原因が相互に作用する場合には弱い手法です。
特性要因図（フィッシュボーン図、Ishikawa）原因をカテゴリー — 人、プロセス、設備、材料、環境 — に分け、背骨から出る骨として描きます。ファシリテーターがグループの提案をもとに書き込みます。深さより幅の手法です：候補を並べはしますが、どの原因がどの原因に影響するかについては何も言いません。
故障の木解析（FTA）障害から AND/OR ゲートを通って基本事象へと下りていく、トップダウンの論理ツリーです。構成要素とその故障モードが分かっている工学システムでは厳密です。分析者が作ります。社会の世界にはめったにないデータを必要とします。
パレート分析インシデントをカテゴリー別に数え、その大部分を占めるカテゴリーを直します。痛みがどこにあるかは分かりますが、何がそれを引き起こしているかは分かりません — 原因を見つける手法ではなく、優先度を振り分けるための道具です。
構造化民主的対話問題とともに暮らす人々が候補となる原因を書き、明確にし、それから — ペアを一つずつ、75%の基準で — 各原因が他の各原因に大きく影響するかどうかを判断します。答えはアルゴリズム（解釈構造モデリング、ISM）によって影響のマップにまとめられ、マップの最下部にある原因が根です。50年の実践と、数百件の記録された対話があります。このサイトで実行しているのがこの手法です。
グループが分析者に勝るとき
決め手となる問いは一つです。その原因を、ルームの中の誰かが知っているか？機械が故障したのなら、ログを持ったエンジニアのほうが、15人が投票するよりも早く理由を見つけます。配送が遅れる、患者が待たされる、学校が教員を失っている、町が信頼を失っているといった場合、原因は関わる人々の間に散らばっています — 夜勤は一つを知り、配車係は別の一つを、顧客は三つ目を知っています — そして、そのすべてを把握している分析者はいません。そうなると、手法は全員から原因を集め、全員につながりを判断させなければなりません。さもなければ、分析者がすでに信じていたことしか見つかりません。
研究から得られた二つの知見が、普通のグループ討議でもこれができない理由を説明します。原因どうしのつながりを検討する前に重要度で原因を順位づけるよう求められた人々は、順位を誤ります — 誤った優先順位効果です。そしてグループに意見を求めると、意見があまりに広く散らばって、どれも過半数を得られません — スプレッドシンク（思考の拡散）です。構造化された対話は、この二つを踏まえて作られています：つながりを判断するまでは順位をつけず、つながりは一つずつ特別多数で判断します。
良い根本原因分析が生み出すもの
- リストではなくマップ：どの原因がどの原因に影響するか、根は最下部に。
- 各つながりと、その背後にある合意。読み手は何が決着し、何が決着しなかったかを確かめられます。
- 意見の相違は、平均して消すのではなく記録に残します。
- 対策は、最も目立つ症状ではなく、根に照らして判断します。
七つの段階のテンプレート · 実際の数字を使った具体例 · このサイトがいくつものグループでこれを実行する方法