根本原因分析(RCA)とは？

問題の根本原因を特定する方法はいくつかあり、そのプロセスは業種や組織によってさまざまです。ソフトウェアプロジェクトでは、通常、当該の問題に精通したメンバーとRCAマネージャーで構成されるRCA専門チームが分析を行います。こうした活動は「インシデント対応」と呼ばれることもあり、RCAはインシデント事後レビューの一部として行われます。

基本的なフレームワークには以下のステップが含まれます。

• 問題の識別：最初のステップは、問題の種類と症状を明確にすることです(機械の誤動作、プロセスの失敗または欠陥、人的ミスなど)。問題がわかったら、根本原因を調査する間、疑わしい要因を隔離して問題が広がるのを防ぐことが重要です。
• データの収集：問題を識別したら、できるだけ多くのデータを集めます。対象には、インシデントレポート、スクリーンショットやログといった形式での証拠、関係者の証言などがあります。このデータに基づいて、一連のイベント(特に問題の引き金となったイベント)、関係したシステム、問題の発生期間、全体的な影響を調べます。
• 根本原因の究明：RCAチームでブレーンストーミングセッションを実施し、特性要因図やパレート図などの技法を使って根本原因を究明します。RCAマネージャーはミーティングが協力的な雰囲気で行われ、参加者同士が口論にならないよう場を取り仕切ります。
• 解決策の実施：根本原因がわかれば、いくつかの解決策が浮かび上がります。RCAチームは、どの解決策が最適で、いつ実施すべきかを判断します。解決策を実施したら、状況を監視して効果を確認する必要があります。このプロセスは「根本原因是正措置」とも呼ばれます。
• 対策の文書化：発生した問題の再発を防ぐことはRCAの重要なステップです。問題とその解決策を文書に記録して、将来同じ問題が起きたときに参照できるようにすることが大切です。物理的な改善点、プロセスを改善するための推奨事項、予防措置を含めてもよいでしょう。

RCAの3つのステップは、「シックスシグマ」と呼ばれる品質管理アプローチのプロセスに含まれます。

シックスシグマは、ビジネスプロセスの効果と効率を高めるためによく使用され、欠陥の特定、原因の究明、プロセスの改善によって品質のばらつきを最小限に抑え、全体的な一貫性を保つことによって、品質を向上することを目的としています。

シックスシグマでは、改善目標を達成するために、データドリブンの分析手法と体系的なアプローチが用いられます。こうした手法の1つが、既存のビジネスプロセスを改善するための「DMAIC」と呼ばれるフレームワークです。この名前は、フレームワークに含まれる各ステップの頭文字を表します。

• 定義(Define)：問題とプロジェクトの目標を定義します。
• 測定(Measure)：現在のプロセスとそのパフォーマンスをさまざまな角度から詳細に測定します。
• 分析(Analyze)：データを分析して、プロセスのパフォーマンスに影響する要因を洗い出し、問題の根本原因を特定します。
• 改善(Improve)：解決策を考えて試しながら、プロセスを改善します。
• 管理(Control)：プロセスが定着するまで実行状況を管理します。

シックスシグマの分析フェーズでは、プロジェクトの目標を達成するために、ソース分析、プロセス分析、データ分析、リソース分析、コミュニケーション分析の5種類を使用します。そのうちソース分析では、RCAプロセスの3つのステップを使って欠陥を特定します。

• 自由意見ステップ：まずは、プロジェクトチームでブレーンストーミングを行い、特性要因図などの技法を使って、当該の問題について考えられるあらゆる要因を洗い出します。
• 絞り込みステップ：前のステップで洗い出した要因のリストを絞り込みます。
• 結論ステップ：絞り込んだ各要因を検証します。

シックスシグマを取り入れれば、IT運用やソフトウェア開発のプロセスを改善できます。シックスシグマで使用するツールや技法は、システムの障害、高い欠陥率、納期の遅れなど、製品の品質や、システムのパフォーマンス、顧客満足度に影響する問題の要因を特定するために役立ちます。

基本原則に従えば、RCAを効果的に行うことができます。これらの原則の多くは、前述のプロセスステップに反映されています。以下の原則があります。

• RCAの主な目的は、問題の根本的な原因を特定することにより、適切な是正措置を判断、実行し、問題を解消することです。根本原因の解決は、問題の再発を防ぐことにもつながります。
• RCAで重視するのは、問題の症状に対処することよりも、問題の根本原因を解消することですが、症状をまったく無視してよいわけではありません。問題が短期的に大きく緩和できるのであれば、症状にも対処すべきです。
• インシデント調査はRCAの重要なプロセスであり、正確な結果を得るには、体系的なアプローチと適切な手順を確立する必要があります。
• 通常は、1つの問題に対して複数の根本原因があります。
• 問題の根本原因を正しく理解するには、分析技法によってイベントのタイムラインや順序を調査し、識別した問題、根本原因、関連する要因の関係を明らかにする必要があります。
• RCAで重要なのは、問題が発生した状況、理由、主な原因を明らかにすることであり、犯人捜しではありません。RCAは誰かに責任を問うことが目的ではないと事前に周知すれば、参加者はミスを隠さず積極的に協力してくれるはずです。
• 根本原因に関する結論は、個人の意見や、勘、憶測に頼るのではなく、事実に基づく証拠によって裏付ける必要があります。
• 真の根本原因には複数の解決策があることがあります。
• 複数の解決策が考えられるときは、できるだけ効率的かつ低いコストで再発を防止できるものを選びます。

RCAは、根本原因を特定するだけでなく、効果的な是正措置を見つけるために十分な、事実に基づく判断材料を提供する、問題解決のための包括的なアプローチです。

特性要因図は、ある特性とその要因の関係を示す図で、問題を引き起こしたさまざまな要因を可視化して根本原因を探るために使用できます。1960年代に東京大学の石川馨教授が考案したこのモデルは、「イシカワダイヤグラム」とも呼ばれ、QC 7つ道具の1つに数えられます。

また、魚の骨を横から見たような形状から「フィッシュボーン図」と呼ばれることもあり、右側の頭に該当する部分は発生した問題を示し、背骨から突き出た大骨は要因のカテゴリーを示します。さらに大骨から突き出た小骨は、そのカテゴリーに含まれる原因や要因を示します。

特性要因図は4つの手順で作成します。

1. 魚の頭の部分に、RCAの対象となる問題を書き出します。
2. 問題に関係すると思われる要因またはそのカテゴリーを洗い出します。通常は4～6個ほど挙げますが、もっと多くてもかまいません。トヨタ社は分類体系として、人(Man)、機械(Machine)、材料(Material)、方法(Method)、測定(Measurement)、環境(MilieuまたはEnvironment)の6つの要素を基準とする「6M(または5M1E)」を提案しています。この分類基準は、要因を考える足掛かりとして多くの問題に適用できます。
3. ブレーンストーミングを実施して、問題を引き起こしたと考えられる原因を洗い出し、適切なカテゴリーの小骨として加えます。
4. 最初に対処すべき原因を決め、実行可能で成功確率が高い解決策を1～3個ほど選定します。

効果的な特性要因図を作成するには、以下のベストプラクティスに従います。

• 解決策ではなく原因を見つけることに重点を置く：RCAの最終目標は問題の解決なので、ブレーンストーミングでは原因よりも解決策に注意が向きがちです。その場合は、進行役が軌道修正しましょう。たとえば、「サポートスタッフを増やす」は解決策であり、「サポートチームの人員不足」が原因です。
• 分類の正確さにこだわりすぎない：原因を正しいカテゴリーに分類することも大切ですが、あまりこだわりすぎるとブレーンストーミングのペースが乱れ、アイデアをリズムよく出せなくなります。進行役は、原因の分類よりも提案の方が重要であることを強調しましょう。原因によっては複数のカテゴリーに該当することもあります。また、原因の数が1つのカテゴリーに偏ることもよくあります。その場合は、そのカテゴリーをいくつかのサブカテゴリーに分けるのも良い方法です。
• アイデアが尽きるまで考える：特性要因図で挙げるべき原因の数に決まりはありません。意見が出尽くしたときが、特性要因図を完成とみなしてRCAの解決策考案ステップに進むことを検討するタイミングです。

RCAに使用できるツールには、特性要因図のほかにもさまざまなものがあります。ツールによって使用するメリットが異なるため、状況に合わせて使い分けます。主なツールをいくつかご紹介します。

なぜなぜ分析：RCAでよく使われるのが、なぜなぜ分析です。その名のとおり、好奇心の強い子供のように疑問の答えに対して「なぜ」を繰り返し、根本原因にたどり着くまで問題を掘り下げていく手法です。問題の根本原因にたどり着くには一般的に5回の「なぜ」を繰り返すのが良いとされますが、問題に応じてそれより多くても少なくてもかまいません。このツールは、根本原因が1つだけの問題に適しています。

なぜなぜ分析を行うときは、以下の手順に従います。

1. 解決したい問題を書き出します。
2. その問題が「なぜ」起きたのかを考え、答えを問題の下に書きます。
3. それが根本原因でない場合は、さらに「なぜ」を繰り返し、答えを下に追加します。
4. 問題の根本原因が見つかったと参加者全員が同意するまで3の手順を繰り返します。

パレート図：パレート図は、折れ線グラフと棒グラフを組み合わせた図で、問題の原因が複数あるときに、特に重要な要因を特定するために役立ちます。要因を値の降順に棒グラフで表し、それらの値を左から右に累積した結果を棒グラフで表します。品質管理では、欠陥の最も一般的な原因や、最も起きやすい欠陥の種類を特定するためによく使われます。

散布図：散布図は、「分布図」とも呼ばれ、2つの変数からなる1組のデータポイントと回帰分析によって、変数間の関係を示します。特性要因図やなぜなぜ分析で見つかった複数の潜在的原因の関係を図にして、どの原因が問題に大きな影響を与えているかを調べるためによく使われます。

散布図を作成するときは、独立変数(潜在的原因)と従属変数(問題)をデータ項目にします。次に、プロセスを監視して、散布図の基になる測定データを収集します。データが揃ったら、独立変数をx軸に、従属変数をy軸にプロットします。プロットが明確な直線または曲線のパターンを描いた場合は、その原因と問題の間に正の相関関係があることを示します。明確なパターンがない場合は、その原因と問題の間には相関関係がないことを示します。

RCAのベストプラクティスをいくつかご紹介します。

• 憶測を捨てる：RCAで正しい結果を得るには、証拠に基づいて判断する必要があります。参加者全員が憶測を捨て、データや事実的な証拠のみに基づいて仮説を裏付けることが重要です。
• データを幅広く収集する：1つの問題に複数の原因や要因があることがあり、根本原因が1つであってもそれがイベントの複雑な連鎖を引き起こす場合もあります。そのため、問題の真の原因を見つけるには、できるだけ多くの要因をできるだけ長い期間にわたって測定することが重要です。
• RCAチームに多様なメンバーを入れる：幅広い観点から問題にアプローチして、さまざまな解決策が出せるよう、RCAチームは、異なる役割を担当する多様なメンバーで構成します。
• チームを小規模に保つ：ブレーンストーミングセッションは、参加者が10人くらいのときが最も生産性が高いと言われます。それより少ないと、出されるアイデアの数やバラエティが限られ、多いと、議論が円滑に進まず、「声が大きい人」の意見に引きずられがちです。
• 細部まで掘り下げる：新しい証拠が見つかるたびに、分析の粒度を細かくして調査を行います。タマネギの皮をむくように1層ずつ事実を明らかにして問題の根本原因に近づけば、より適切な解決策にたどり着きます。
• 参加者が安心して出席できるようにする：多くの問題は最終的に人的ミスが原因です。RCAは誰かに責任を負わせたり罰を与えたりすることが目的ではないと事前に周知し、できればミーティングのたびに、直すべきは人ではなく問題であることを伝えます。

RCAが完了したら、最後のステップは予防措置を実行することです。そのためにはまず、更新する必要のある文書、変更する必要のあるプロセス、新たな研修または再研修が必要な従業員などを特定します。修正事項の多くは、RCAに基づいて判断できます。目標は常に、予防措置を講じて、解決した問題の再発を防ぐことです。

RCAは基本的に、問題を解決するための手法であるため、まずは問題があることを認識する必要があります。開発やIT運用については、問題を認識するための手段がすでにいくつかあります。

• オブザーバビリティ：アプリケーションパフォーマンス監視ツールを使えば、アプリケーションの動作を常に把握し、メトリクスを収集して、処理速度の低下など、コードのパフォーマンスに関する問題が発生したときにアラートを生成できます。ログも問題の発見に役立ちます。ログでは、問題がインフラにあるのかコードにあるのかといった点を判断するのが難しいこともありますが、その場合はRCAを実行することで要因を詳しく調べることができます。
• 顧客の不満：アプリケーションやサービスのエクスペリエンスについて顧客が不満を訴えている場合は、問題が発生している可能性があります。こうした不満は、バグや処理速度の低下など、パフォーマンスの問題を発見するための第一歩になることが多く、RCAを始めるきっかけにもなります。
• リアルユーザー監視(RUM)：リアルユーザー監視では、顧客が不満や苦情を訴える前に問題を検出して修正できます。

これらの手段を導入すれば、インフラの問題が発生したときにアラートを生成し、RCAを体系的に実行するために必要なデータを収集できます。また、これらの手段で高い効果を得るには、ネットワークをリアルタイムで可視化し、必要なデータを収集して、実用的なインサイトを提供するツールが必要です。こうした監視ツールやオブザーバビリティツールでは、インフラで生成されるさまざまなデバイスログやレポートに記録されたイベントが、機械学習によって分析され、相関付けられます。そこから得られるインサイトをRCAに使用すれば、より効果的な解決策をよりすばやく見つけることができます。

RCAは、インフラで問題が起きた原因、さらにはインフラが円滑に機能するための条件を明らかにするために欠かせないプロセスです。効果的なRCAプロセスを確立するには時間と労力がかかりますが、それを乗り越えれば、適切かつ永続的に問題を解決し、インフラのパフォーマンスを最大限に引き出せる環境を構築できます。