『根本原因分析』（2014年）は、直感や責任追及ではなく、経験的証拠と構造化された手法を用いて品質問題を体系的に調査する方法を解説した一冊です。根本原因分析の理論的基盤を紹介した上で、製造業やサービス業の現場における不具合や故障の根本原因を特定するために、Plan-Do-Check-Act（PDCA）サイクルとさまざまな品質ツールを組み合わせて適用する方法を示しています。
本書から得られるもの――頑固な問題をより速く、より安く、そして永続的な結果で解決する実践的な根本原因ツールを学ぶ
問題が都合の良いタイミングで起こることはめったにありません。製品が顧客先で故障し、サービスが停止し、苦情が机の上に届き、突然全員が「早く直せ」というプレッシャーにさらされます。慌てていると、最も疑わしい対象を責め、症状をつぎはぎして先へ進みたくなるものです。問題は、同じ問題が少し姿を変えて再発することが多いということです。そして、繰り返すたびに、前回よりも多くのコストと時間と信頼を失っていきます。
根本原因分析は、これとは異なる対応方法を提供します。「誰のせいか？」ではなく、「システムの何がこの結果を可能にしたのか？」と問いかけるのです。すべての説明は、守るべきストーリーではなく、検証すべき仮説として扱われます。
シンプルなツールと構造化された思考によって、複雑な失敗でさえ理解し対処することができます。本要約では、証拠に基づく根本原因分析が実際にどのように機能するのか、基本的および高度な調査ツールがそれをどう支えるのか、偶然の一致ではなく真の原因へとデータがどう導いてくれるのか、そしてこれらすべてを顧客苦情・是正処置・日常業務における持続的改善にどう結びつけるのかを学びます。まずは基礎から始めましょう。すべての説明を、事実と一致することで初めてその地位を得る仮説として扱うことです。
根本原因分析は、証拠と明確な仮説によって推進されて初めて機能する
何かがうまくいかなかったとき、もっともらしく聞こえる最初の説明に飛びつきたくなるものです。根本原因分析では出発点が異なります。すべての説明は仮説として扱われます。つまり、失敗がなぜ起きたのかについての具体的な推測であり、事実との照合を生き延びなければならないものです。良い仮説とは、すでに知られていることと整合し、前提を最小限に抑え、確認可能な明確な予測を立てるものです。たとえば、荷積みドアの近くに保管された鋼管は、湿った外気にさらされるため、より頻繁に錆びるのではないか、と疑うかもしれません。
そのような記述は、すでにこの手法が必要とする構造を備えています。保管場所という要因を特定し、もしそれが正しければ何を観察すべきかを示唆しているからです。倉庫の中央よりもドアの近くの鋼管のほうが錆びている、という観察結果です。このアプローチでは、仮説が最終的に「証明」されることは決してありません。仮説は反証されるか、あるいはテストで反証されなかった後も暫定的に支持され続けるかのいずれかです。時間の経過とともに、より良い仮説とは、反証の試みを繰り返し生き延びたものです。このプロセスが無作為な試行錯誤にならないように、基礎となる科学的手法は実践的なステップに分解されます。
欠陥や状態の観察から暫定的な仮説を形成します。その仮説から、もしそれが正しければどのような具体的な結果が見られるはずかを導き出し、正式な実験であれ、既存の部品や記録の構造化された確認であれ、その結果を探す方法を設計します。その比較の結果は、次に学んだことを反映した新しい仮説へと直接つながります。多くの組織では、この論理的な往復がPlan-Do-Check-Act、すなわちPDCAサイクルによって組織化されています。Planは、問題を定義し、テストする価値のある仮説を選ぶことを意味します。Doはテストそのもので、実験室での試行から生産現場でのオンラインテストまで含みます。
Checkは、仮説が予測したことと実際に起きたことの比較です。Actはループを閉じます。より徹底したテストで結果を確認するか、仮説を棄却して新しいサイクルを開始するかを決定します。PDCAの各ターンは仮説を研ぎ澄まし、可能性を狭めていくため、調査は失敗を本当に可能にした条件へと一歩ずつ近づいていきます。次のセクションでは、これらのサイクルが依存する証拠を収集・整理するのに役立つ具体的なグラフィカルツールを見ていきます。
シンプルな品質ツールが散らばったデータを実践的な証拠に変える
日常的な多くの失敗を調査するのに、高度な統計は必要ありません。いくつかのシンプルで広く使われている図表だけで、雑然とした経験を明確で実践的な証拠に変えることができます。出発点として最適なのが特性要因図、別名フィッシュボーン図です。望ましくない結果を一方の側に書き、そこから人、方法、材料、機械、測定、環境といった大まかなカテゴリーへと枝分かれさせます。
各カテゴリーの下に、具体的な可能性のある要因を記録します。不明確な作業指示書、摩耗した工具、温度変動などです。これにより、後で実際のデータと照合できる仮説のマップが作成されます。口論の材料ではなく、検証の対象となる仮説の地図です。実際に何が起きているのかを把握するには、チェックシートがデータ収集に規律をもたらします。作業が行われるその場で、ラインから部品が出てくるたびに欠陥の種類を集計するなどの使い方をします。その集計結果はラン図にプロットすれば時間の経過に伴う変化やパターンを見つけられますし、ヒストグラムで測定値の分布を見れば、特定のサプライヤーや機械だけが他と大きく異なる挙動をしていることが明らかになります。パレート図は、問題を頻度や影響度でランク付けしてどこから着手すべきかを判断するのに役立ちます。少数の原因が結果の大部分を生み出すという長年観察されてきた傾向を利用しつつ、まれではあるが深刻な問題を最優先として扱う余地も残しています。散布図は、温度と不良率のような変数をペアにして、それらが連動して動くかどうかを確認します。
ただし、強い関連性があっても、それだけでは因果関係を証明したことにはならないことを忘れないでください。最後に、フローチャートはプロセスにおける実際のステップと判断の順序を最初から最後まで並べ、どこで欠陥が入り込みうるのか、どこにより詳細な分析が必要なのかをはるかに見えやすくします。これらの実践的なツールを踏まえて、次のセクションでは、単一の作業場でデータを図表化するだけでなく、より大規模で部門横断的な調査を調整するための計画・管理手法に移ります。
マネジメントツールが複雑な根本原因調査を調整されたものにする
図表によって問題の所在が明らかになった後、別の課題が現れます。問題を解決するために必要な人、意思決定、フォローアップ作業を調整する必要があります。問題が複数の部門にまたがる場合や顧客が関わる場合、根本原因分析はデータだけでなく構造も必要なプロジェクトになります。マネジメント・計画ツールは、実験や測定がバックグラウンドで続く間、チームがアイデアを整理し、アクションを追跡し、優先順位について合意するための共通の方法を提供することで、このニーズに応えます。
マトリックス図は良い出発点です。サプライヤー、機械、シフトなどの要因を、特性やタスクと単純な行と列で比較します。調査では、テスト結果や仮説を収集できます。また、各タスクを担当者と期日に結びつけるアクションリストとしても機能します。時間はアローダイアグラム（活動ネットワーク図）によって扱われます。これは各タスクをボックスとして示し、実行すべき順序でつなぎ、それぞれに見積もり期間を割り当てる簡略化されたチャートです。これによりクリティカルパス――調査にかかる時間を決定するタスクの連鎖――が見えるようになり、チームは重要な活動を時間通りに開始し、封じ込め、実験、顧客報告の遅れを回避できます。
複数の是正処置や改善プロジェクトが注目を競う場合は、優先順位マトリックスが、有効性、コスト、実施時間などの重み付けされた基準に対して代替案をスコアリングします。連関図は、要因間に矢印を描き、どれが真のドライバーでどれが主に結果であるかを強調することで、複雑な状況を解きほぐすのに役立ちます。最後に、系統図は、広範な問題を管理可能な枝に分解し、各可能な原因を具体的なタスクに結びつけ、提案された変更がどのように組み合わさるかを明らかにするのに役立ちます。他のマネジメントツールと併用することで、複雑な調査を見える化し、調整された状態に保ちながら、実験と測定を進めることができます。次のセクションでは、問題の記述をより鮮明にし、異なる証拠の糸をつなぐ、より専門的な分析ツールを見ていきます。
専門的ツールが根本原因の探索を研ぎ澄ます
基本的な図表とマネジメントツールがその役割を果たす頃には、多くの問題はすでに絞り込まれているか、解決されています。残るのは、問題がどこにあるかおおよそわかっていても、何がそれを引き起こしているのか正確にはわからない、頑固なケースです。最初のステップとしてよく使われるのが5回のなぜ分析で、その出来事がなぜ起きたのかを、それを許した条件に到達するまで問い続けます。ヒューズが飛んで機械が停止したと想像してください。
しかし、単にヒューズを交換するだけでは不十分です。問いを繰り返すことで、潤滑不足、ポンプシャフトの摩耗、そして最後に金属くずがシステムに入り込むのを許したストレーナーの欠落が明らかになるかもしれません。その最後の点こそが、対処すべき究極の原因です。イズ・イズノット分析は、問題が発生する場所と、発生する可能性があるのに発生していない場所を比較することで、さらに絞り込みます。機械、シフト、サプライヤー、製品バリアントを対比することで、テストする価値のある違いを強調し、偶然の一致をふるい落とします。クロスアセンブリ（部品交換試験）は、より実験的なルートをとります。良品と不良品のアセンブリ間で部品を交換し、欠陥が特定のコンポーネントに追随するのか、それともシステムの残りの部分にとどまるのかを確認します。
これは、完全な機能テストが高価か時間がかかる場合に特に有用です。状況が複雑な場合は、特定の証拠の系統を追うことが重要です。各観察事項を一本の糸として扱い、それが可能性のある原因を支持するのか、矛盾するのか、それとも無関係である可能性が高いのかを問います。設計やシステムの疑問に対しては、状況を可視化して視野を広げることができます。パラメータ図は、入力、望ましい機能、エラー状態、制御可能な設定をマッピングします。また、ユーザー行動や環境条件など、異なるタイプのノイズも示します。
バウンダリ図は、システムの限界とインターフェースを示し、あるアセンブリの見かけ上の問題――たとえば開かないスライドカバー――が、実際にはその境界の外側にある別のコンポーネントによって引き起こされている可能性を明らかにします。これらのツールを組み合わせて使うことで、調査はより鋭い仮説と、より的を絞ったテストへと導かれます。次に、これらの仮説を生み出すパターンを生データから探し出す方法として、探索的データ分析を見ていきましょう。
探索的データ分析が生の数値を有用な手がかりに変える
プロセス、検査、実験から測定値を収集し始めると、次の疑問はこれらの数値が何を伝えようとしているのかです。探索的データ分析（EDA）は、正式な統計検定の前にデータを直接見ることです。シンプルな表示を使って、問題を説明するかもしれないパターン、異常値、グループ化を見つけます。根本原因の作業では、EDAは、現在の仮説をデータが支持するのか挑戦するのかを問うことで、これまでのツールの上に構築されます。
たとえば、モーター組立ラインで、欠陥タイプのパレート図を見れば、ほとんどの失敗が1つの作業場から発生していることがわかり、どこにチェックを集中すべきかがわかります。携帯電話の生産では、ピン寸法の基本的なヒストグラムが1つではなく2つの明確なピークを示すことがあります。これは、2つの金型からの部品が混ざっており、そのうちの1つが異なる挙動をしていることを示唆しています。どちらの場合も、数値を可視化することで、次の問いと次のデータ収集のラウンドが導かれます。これを支えるために、EDAは机の上でも現場でも簡単に使える軽量なツールを使用します。幹葉図は、元の値をすべて残したまま手で分布をスケッチできます。箱ひげ図は、データの中心を要約し、機械や条件間の違いを強調し、さらなるチェックのために外れ値を際立たせます。
多変量図はさらに一歩進んで、出力が時間、位置、サイクルにわたって、複数の要因にまたがってどのように変化するかを示します。これは、機械、作業者、材料、環境がすべて同時に結果に影響を与えている可能性があり、実験を計画する前に迅速な全体像が欲しい場合に特に役立ちます。データのパターンに説明を提案させるという基本的な考え方は新しいものではありません。1854年のロンドンでのコレラ流行の際、ジョン・スノーは死亡者と水道供給業者を地図にプロットしました。そして地図上の例外を検証して自分の説明を洗練させました。EDAという用語が存在するずっと前に、効果的にEDAを使っていたのです。最後のセクションでは、実際の顧客苦情が届いたときにこの考え方をどう適用するか、そして調査を具体的な是正処置にどう変えるかを見ていきます。
効果的な根本原因分析は、顧客苦情・調査・持続的改善を結びつける
あなたが分析していた欠陥が突然、顧客のラインで発生したらどうなるでしょうか。その瞬間、根本原因の作業はもはや抽象的なものではなくなります。顧客を保護し、失敗を調査し、再発を防ぐための明確な方法が必要です。まず状況を安定させることから始めます。問題にどう対処するかを決定し、部門横断的なチームを招集し、疑わしい部品がこれ以上流出しないように封じ込めが必要かどうかを判断します。
封じ込めとは、倉庫の在庫を隔離したり、顧客先の在庫を確認したりすることを意味するかもしれません。深刻なケースでは、リコールの計画を意味することもあります。先ほどのPlan-Do-Check-Actサイクルを覚えていますか？ここでは、それを使って即時の行動を選択し、その効果を確認し、より良い情報が入ってくるにつれて対応を迅速に調整します。すべてを調整された状態に保つために、多くの企業は8D報告書に依存しています。これは、最初の苦情から最終的な予防ステップまで、問題の構造化された記録です。
チームのメンバーを文書化し、顧客が気にする言葉で問題を説明し、一時的な対策を記録し、その後、故障部品をどのように調べたか、どの説明を除外したかを含め、根本原因分析を要約します。原因を確認したら、計画した是正処置、それらが機能することを示す試行、問題の再発を防ぐべき作業指示書や管理計画の変更を記述します。8Dを締めくくることで、組織と顧客の両方が追跡できる単一の記録が残ります。では、これは実際にどうまとまるのでしょうか。品質エンジニアが1年分の顧客データをレビューし、錆が全苦情の半分以上を占めていることを確認したとします。これが解決すべき最重要の問題になります。適切な根本原因ツール――パレート図、層別、的を絞った実験、構造化された原因分析――を使って、「小さなチューブがより頻繁に錆びるようだ」という漠然とした手がかりから、非常に具体的な条件へと徐々に絞り込んでいきます。それは、開いた荷積みドアの近くに保管されたバンドルが湿気を吸収して腐食するというものです。
保管場所とドアの保護に関する簡単な変更によって、錆に関する苦情は劇的に減少しました。それと同じくらい重要なのは、仮説、テスト、最終結論を文書化し、標準やリスク分析を更新し、そのケースを教訓システムに追加したことです。不可解な欠陥に直面する次のチームは、ゼロから始めるのではなく、その成果の上に構築できます。これこそが根本原因分析の真の成果です。失敗を修正しながら、同時に、問題を理解し、時間とともにより容易に解決していく組織を着実に築いていくことです。
まとめ
マシュー・A・バルサロウ著『根本原因分析』の要点は、体系的で証拠に基づく根本原因分析によって、同じ火事と何度も戦うのをやめ、代わりにそれを未然に防ぎ始めることができるということです。すべての説明を検証可能な仮説として扱い、シンプルな視覚的ツールで事実を整理し、必要なときだけより高度な手法を適用することで、勘や責任追及から、明確で共有された理解へと移行できます。図表、ダイアグラム、探索的データ分析は、問題が実際にどこにあるのかを見るのに役立ち、構造化されたチームワークと顧客中心のフォローアップが、その理解を持続的な是正処置と、よりスマートな標準へと変えていきます。
時間が経つにつれて、解決された各問題は成長する経験の蓄積の一部となり、あなたとあなたの組織は、より高い自信とスピードと創造性を持って将来の失敗に対処できるようになります。
