根本原因分析とは: 手法と実例

ほとんどのチームは、症状の対処に時間を費やしています。根本原因分析(RCA)とは、そうした症状の奥にある、そもそも問題を引き起こした本当の原因を突き止める取り組みです。これにより、問題を一度で解決し、再発を防ぐことができます。

根本原因分析とは何か

根本原因分析とは、問題の目に見える影響に対処するのではなく、その根底にある原因を特定するための構造化された問題解決手法です。基本的な前提はシンプルです。症状だけに対処していれば、同じ問題は再び現れます。しかし発生源を取り除けば、問題は恒久的になくなります。

RCAは単一のツールではありません。それぞれ異なる種類の問題に適したいくつもの手法を背景に持つ一つの規律です。それらに共通しているのは、取り除けば問題の再発を防げるような原因にたどり着くまで、「なぜこれが起きたのか」を繰り返し問い続ける姿勢です。

RCAと通常のトラブルシューティングの違いは、その深さにあります。トラブルシューティングは物事を再び動くようにするものです。RCAは、同じ形で二度と壊れないようにするものです。

主な事実

• 米国品質協会(ASQ)は、品質の低さが米国企業に及ぼすコストは総売上の5〜30%に達すると推定しており、その大部分は根本レベルで解決されないまま放置された不良や不具合に起因するとしています。
• Aberdeen Groupの調査によると、正式な根本原因分析手法を用いる組織は、場当たり的な対応に頼る組織と比べて、再発する問題を最大3倍速く解決できることが分かりました。
• 国際的な品質マネジメント標準であるISO 9001:2015は、組織に対して不適合の原因を特定し、表面的な対応ではなく根本レベルで是正措置を講じることを明確に求めています。

根本原因分析の手法比較

実証された根本原因分析の手法はいくつも存在します。どれを選ぶべきかは、問題の複雑さ、手元にあるデータの量、関わるべき人数によって決まります。

それぞれの手法にはトレードオフがあります。5なぜ分析は速く取り組みやすい一方、複雑な問題では表面的な分析になりがちです。FMEAは徹底していますがリソースを多く必要とします。ビジネスにおけるほとんどの業務上の問題については、まず特性要因図から始め、その後5なぜ分析で深掘りするというやり方で、大半のケースを十分にカバーできます。

根本原因分析のメリット

一貫して実践することで、RCAは組織の問題への向き合い方を変えます。同じインシデントを半年周期で繰り返すのではなく、チームは物事がなぜ壊れるのかについての組織的な知見を蓄積していきます。

その場しのぎではなく恒久的な解決。 最も分かりやすいメリットは、問題が再発しなくなることです。原因に対処すれば、その不具合を生み出す仕組み自体を取り除くことになります。

コスト削減。 手戻り、保証対応、顧客離れ、インシデント対応にはいずれも実際のコストがかかります。根本原因を取り除くことで、こうしたコストを際限なく管理し続けるのではなく、発生源で断ち切ることができます。

部門横断的な学び。 RCAはほぼ必ず、一つの問題が複数の部門にまたがる要因を持っていることを明らかにします。このプロセスは、縦割りのトラブルシューティングでは決して生まれない共通理解を作り出します。

より良いプロセス設計。 繰り返し現れる根本原因は、しばしば業務の構造そのものにある設計上の欠陥を指し示します。優れたRCAプログラムはそうした設計上の問題を浮き彫りにし、DMAICやシックスシグマといった継続的改善の取り組みへとつなげます。

文化の変化。 RCAを定期的に実践するチームは、責任の所在を追及するのではなく「なぜ」を問うことに長けていきます。それは総合的品質管理の文化へ向かう根本的な転換です。

よくある間違いと限界

RCAは強力な手法ですが、うまくいかないケースも少なくありません。以下は最もよく見られる失敗パターンです。

早く切り上げすぎる。 最もよくある間違いは、実際にたどり着く前に根本原因を宣言してしまうことです。「ヒューマンエラー」がそのまま根本原因になることはほとんどありません。それは、研修の不足、手順の不明確さ、ツールの不備といったものの症状です。

寄与要因と根本原因を混同する。 一つの問題には、単一の根本原因がなくても、複数の寄与要因が存在することがあります。それらを区別しないRCAは、問題を完全には解決しない散発的な是正措置につながります。

行動を伴わない分析。 RCAはレポートを生み出しますが、レポート自体は何も解決しません。明確な担当者、期限、検証ステップがなければ、得られた知見は紙の上にとどまったままになります。

確証バイアス。 チームはしばしば最初にもっともらしいと思えた説明に固執し、それ以上探すのをやめてしまいます。特性要因図のような構造化された手法は、絞り込む前に複数の原因カテゴリーを検討することを強制することで、これを防ぐのに役立ちます。

対象範囲の肥大化。 あらゆる悪い結果を一度に説明しようとするRCAは、あいまいな結論を生みがちです。問題定義を絞り込むことで、より鋭い結果が得られます。

根本原因分析の進め方(ステップバイステップ)

ステップ1: 問題を明確に定義する

具体的で測定可能な問題定義を書きましょう。「顧客からの苦情が増えている」では曖昧すぎます。「2026年第1四半期に、顧客からの不良報告率が1.2%から3.8%に上昇し、モバイル決済フローに集中している」であれば調査できる形になります。絞り込まれた問題定義は分析が脱線するのを防ぎ、実際に解決できたかどうかを判断する助けにもなります。

ステップ2: データを収集する

仮説を立てる前に事実を集めましょう。インシデントログ、プロセスデータ、顧客からのフィードバック、タイムスタンプ、そのほか何が、いつ、どこで起きたかを示す証拠がこれに含まれます。このステップを飛ばして原因の特定に飛びつくことが、チームが誤った対象を修正してしまう原因になります。

ステップ3: 考えられる原因を特定する

特性要因図のような構造化された手法を使い、カテゴリー別に考えられるすべての原因を洗い出します。異なる部門の人々を巻き込みましょう。この段階での目標は深さではなく広さです。何かを除外し始める前に、もっともらしい原因をすべて浮かび上がらせることが重要です。

ステップ4: 根本原因を見つける

選んだ手法を適用し、考えられる原因から実際の原因へと掘り下げていきます。5なぜ分析を使う場合は、根本的でありかつ行動可能な原因にたどり着くまで、各段階で「なぜこれが起きるのか」を問い続けます。パレート分析を使う場合は、頻度や影響度のデータを使って、問題の大部分を占める原因を特定します。ステップ2で収集したデータに照らして、導き出した結論を検証しましょう。

ステップ5: 是正措置を実施し検証する

根本原因に直接対処する是正措置を設計します。明確な担当者と期限を割り当てます。そして、問題が実際に発生しなくなったかを測定することで、その対策が本当に機能しているかを検証します。この検証ステップこそ、多くのRCAプロセスが不十分になりがちな部分です。これがなければ、本当の解決とただの偶然の一致を見分けることができません。

ステップ6: 再発防止のために標準化する

対策の効果が検証されたら、その変更を組み込むために関連する手順書、研修資料、システム上の管理策を更新します。このステップこそ、一度きりの対応を恒久的な改善へと変えるものです。また、RCAをPDCA、リーン手法、バリューストリームマッピングといったより広範なフレームワークにつなげるステップでもあります。

根本原因分析の実例

製造業における不良

ある家具メーカーで、完成品の表面の傷が4%増加しました。最終検査を強化する代わりに、彼らはRCAを実施しました。

対策は変更管理のチェックリストでした。傷の発生率は2回の生産サイクル以内に元の水準まで戻りました。

ソフトウェアサービスの障害

あるSaaS企業では、1か月の間に3件の別々のデータベースタイムアウト障害が発生しました。インシデントレビューでは、あるパターンが特定されました。3件すべてが、週末のバッチジョブが実行された後の月曜日の朝に発生していたのです。

そのバッチジョブは大量の一時データを共有テーブルに書き込んでおり、クリーンアップを行っていませんでした。数週間にわたってテーブルが肥大化し、クエリ時間が急上昇していました。根本原因は、バッチジョブにクリーンアップ処理が欠けていたことと、テーブルサイズに関する自動アラートが存在しなかったことの組み合わせでした。両方の問題を修正し、障害は発生しなくなりました。

顧客離れの急増

あるB2Bソフトウェア企業は、契約から90〜180日目の顧客コホートで解約が急増していることに気づきました。アカウントマネージャーたちは価格の問題だと考えていました。しかしRCAは、それとは異なる事実を明らかにしました。

営業、カスタマーサクセス、プロダクトを横断した特性要因図のセッションにより、このコホートの顧客は、プラットフォームの中核的な価値を引き出すための統合ステップを一貫して完了できていないことが特定されました。根本原因は、この統合が多くの購買担当者が持っていない技術的知識を必要とするものであったにもかかわらず、オンボーディングの流れが技術に詳しくない担当者向けの案内を用意していなかったことでした。オンボーディングを構造的に見直したことで、そのコホートの解約率は翌四半期に34%減少しました。

ベストプラクティス

明確な問題定義から始める。 あいまいな問題は、あいまいな原因しか生み出しません。具体性こそが、有用なRCAの基盤です。

問題と症状を区別する。 「なぜ」を問い始める前に、正しい対象について問うていることを確認しましょう。症状はしばしば問題そのものであるかのように装います。

現場に近い人を巻き込む。 実際に業務を行っている人々こそが、どこにひび割れがあるかを知っています。経営層だけで進めるRCAは、実態を見失いがちです。

根本原因を一つで止めない。 現実の問題の多くは、原因が一つではありません。最初の根本原因を見つけた後は、対処すべき寄与要因が他にもないかを問いましょう。

検証を妥協しない。 検証されていない是正措置は単なる仮説にすぎません。検証ステップを標準のRCAテンプレートに組み込みましょう。

RCAをより広範な改善の仕組みにつなげる。 プロセスの再設計や継続的改善プログラムにつながらない単発のRCAの知見は、棚上げされがちです。得られた知見をDMAICサイクルや業務レビューの周期に組み込みましょう。

繰り返すインシデントを追跡する。 同じ根本原因が異なるインシデントで複数回現れる場合、それは構造的な問題のシグナルです。時間をかけて知見を蓄積し、パターンを探しましょう。

よくある質問

RCAと5なぜ分析の違いは何ですか?

RCAは、問題の根底にある原因を見つけるための広範な規律です。5なぜ分析は、RCAの中で使われる具体的な手法の一つです。根本原因分析はさまざまなツールを使って実施できます。5なぜ分析は最も取り組みやすい手法ですが、複雑な問題には必ずしも適しているとは限りません。

どのRCA手法を使うべきですか?

単純な業務上の問題には5なぜ分析から始めましょう。複数の部門が関わる場合や原因が明白でない場合は、特性要因図を使います。複数の考えられる原因の中から優先順位をつける必要がある場合は、パレート分析を使います。安全に関わる重大な問題や影響の大きい品質の不具合には、FMEAや8D問題解決にエスカレーションしましょう。

一つの問題にはいくつの根本原因がありえますか?

複数あることが一般的です。実務上、重大な問題のほとんどは、単一ではなく複数の寄与する根本原因を持っています。一つのRCAが、主要な原因と2〜3の寄与要因を明らかにすることもあり、対策を定着させるにはそのすべてに対処する必要があります。

RCAとトラブルシューティングはどう違いますか?

トラブルシューティングは、できるだけ早く通常の運用状態を回復させるものです。RCAは、そもそもなぜ通常の運用が失敗したのかを突き止めるものです。多くの場合両方を行いますが、順序があります。まずトラブルシューティングで出血を止め、その後RCAを実施して再発を防ぎます。

RCAは従業員の離職といった技術的でない問題にも有効ですか?

はい。RCAは製造業やエンジニアリングだけでなく、人事、顧客体験、財務、オペレーションでも活用されています。手法は同じです。離職率の高さという問題を特性要因図で調べると、オンボーディング、マネジメントの慣行、報酬体系に根本原因が見つかることがあります。この規律は、恒久的に解決したい繰り返しの問題を抱えているあらゆる場面に応用できます。

---

再発する問題とは、実際には一度も解決されたことのない問題です。RCAは、その隙間を埋める取り組みであり、これを標準的な業務リズムに組み込んだチームは、火消しに費やす時間がはるかに少なくなり、改善に費やす時間がはるかに多くなります。どの手法を使うかよりも、検証され標準化された対策までやり遂げる規律の方がずっと重要です。

関連記事

• 5なぜ分析: 手法の使い方
• 特性要因図: 根本原因分析のための視覚化ツール
• パレート分析: 問題の優先順位付けのための80/20の法則
• DMAIC: シックスシグマの問題解決フレームワーク
• PDCAとは: Plan-Do-Check-Actを解説