guide root cause analysis steps
このチュートリアルでは、根本原因分析とは何か、およびフィッシュボーン分析や5つのなぜなぜ分析などのさまざまな根本原因分析手法について説明します。
RCA（根本原因分析） は、ソフトウェアプロジェクトチームの問題の根本原因を見つけるための構造化された効果的なプロセスです。体系的に実行すると、チームレベルだけでなく、組織全体で、成果物とプロセスのパフォーマンスと品質を向上させることができます。
このチュートリアルは、チームまたは組織の根本原因分析プロセスを定義および合理化するのに役立ちます。
このチュートリアルは、デリバリーマネージャー、スクラムマスター、プロジェクトマネージャー、品質マネージャー、開発チーム、テストチーム、情報管理チーム、品質チーム、サポートチームなどが根本原因分析の基本を理解し、そのテンプレートと例を提供することを目的としています。 。
学習内容：
根本原因分析とは何ですか？
RCA（根本原因分析） は、欠陥を分析してその原因を特定するメカニズムです。私たちはブレインストーミングを行い、欠陥を読み、掘り下げて、欠陥が「 テストミス '、' 開発ミス 」または「 要件または設計が欠落している 」。
RCAが正確に行われると、それ以降のリリースまたはフェーズでの欠陥を防ぐのに役立ちます。見つかった場合、欠陥は デザインミス 、設計図書を確認し、適切な措置を講じることができます。同様に、欠陥が原因であることが判明した場合 テストミス 、テストケースまたはメトリックを確認し、それに応じて更新できます。
RCAは、欠陥のテストだけに限定されるべきではありません。生産上の欠陥についてもRCAを行うことができます。 RCAの決定に基づいて、私たちは テストベッド そして、それらのプロダクションチケットを回帰テストケースとして含めます。これにより、欠陥または同様の種類の欠陥が繰り返されないことが保証されます。
根本原因分析プロセス
RCAは、顧客サイトから報告された欠陥だけでなく、UAT欠陥、単体テストの欠陥、ビジネスおよび運用プロセスレベルの問題、日常生活の問題などにも使用されます。したがって、RCAは次のような複数の業界で使用されます。ソフトウェアセクター、製造業、健康、銀行セクターなど。
根本原因分析の実施は、患者を治療する医師の仕事に似ています。医者は最初に症状を理解します。それから彼は病気の根本的な原因を分析するために臨床検査を参照します。
病気の根本的な原因がまだ不明な場合、医師はさらに理解するためにスキャンテストを参照します。彼は、患者の病気の根本原因に絞り込むまで、診断と研究を続けます。同じ論理が、あらゆる業界で実行される根本原因分析に適用されます。
したがって、RCAは、特定の一連の手順と関連ツールに従うことにより、症状を治療するのではなく、根本原因を見つけることを目的としています。欠陥分析、トラブルシューティング、およびその他の問題解決方法とは異なり、これらの方法は特定の問題の解決策を見つけようとしますが、RCAは根本的な原因を見つけようとします。
名前の由来根本原因分析：
(画像 ソース )
葉、幹、根は木の最も重要な部分です。地上にある葉(症状)と幹(問題)は見えますが、地下にある根(原因)は見えず、根が深くなり、予想以上に広がる可能性があります。したがって、問題の根底を掘り下げるプロセスは、根本原因分析と呼ばれます。
根本原因分析の利点
以下にリストされているのは、いくつかの利点です。
- 今後、同じ問題が再発しないようにしてください。
- 最終的には、時間の経過とともに報告される欠陥の数を減らします。
- 開発コストを削減し、時間を節約します。
- ソフトウェア開発プロセスを改善し、市場への迅速な提供を支援します。
- 顧客満足度を向上させます。
- 生産性を高めます。
- システムの隠れた問題を見つけます。
- 継続的な改善を支援します。
根本原因の種類
＃1）人間の原因： 人為的なエラー。
例：
- 熟練していない。
- 指示に正しく従わなかった。
- 不要な操作を行った。
＃2）組織的な原因： 人々が適切ではなかった決定を下すために使用するプロセス。
例：
- チームリードからチームメンバーに漠然とした指示が出された。
- タスクのために間違った人を選ぶ。
- 品質を評価するための監視ツールが整っていません。
＃3）物理的な原因： 物理的なアイテムが何らかの方法で失敗しました。
例：
- コンピュータは再起動し続けます。
- サーバーが起動していません。
- システム内の奇妙なまたは大きなノイズ。
根本原因分析を行う手順
効果的な根本原因分析には、構造化された論理的なアプローチが必要です。したがって、一連の手順に従う必要があります。
＃1）RCAチームを形成する
すべてのチームには専用の 根本原因分析マネージャー(RCAマネージャー) サポートチームから詳細を収集し、RCAのキックオフプロセスを開始します。彼は、述べられた問題に応じて、RCA会議に出席する必要があるリソースを調整および割り当てます。
会議に参加するチームには、問題に最も精通している各チーム(要件、設計、テスト、文書化、品質、サポート、および保守)の担当者が必要です。チームには、欠陥に直接関係している人もいる必要があります。 例えば、 お客様に即座に修正を加えたサポートエンジニア。
会議に参加する前に、問題の詳細をチームと共有して、チームが初期分析を行い、準備ができるようにします。チームメンバーは、欠陥に関連する情報も収集します。インシデントレポートに応じて、各チームは、それぞれのフェーズでこのシナリオの問題点を追跡します。準備することで、今後の議論の効率が高まります。
＃2）問題を定義する
インシデントレポート、問題の証拠（スクリーンショット、ログ、レポートなど）などの問題の詳細を収集し、以下の質問をして問題を調査/分析します。
- 何が問題ですか？
- 問題を引き起こした一連のイベントは何ですか？
- どのようなシステムが関係していましたか？
- 問題はどのくらい存在しましたか？
- 問題の影響は何ですか？
- 誰が関与し、誰にインタビューすべきかを決定しますか？
「SMART」ルールを使用して問題を定義します。
- S PECIFIC
- M EASURABLE
- に CTION指向
- R エレバント
- T NAME-BOUND
＃3）根本原因を特定する
実施する ブレーンストーミング 原因を特定するために形成されたRCAチーム内のセッション。使用 フィッシュボーン図 または 5なぜなぜ分析 根本原因に到達するための方法またはその両方。
RCAマネージャーは、会議をモデレートし、ブレーンストーミングセッションのルールを設定する必要があります。 たとえば、ルールは次のようになります。
- 他人を批判したり非難したりすることは許されるべきではありません。
- 他人の考えを判断しないでください。悪いアイデアはありません。彼らはワイルドなアイデアを奨励します。
- 他の人のアイデアに基づいて構築します。他の人のアイデアに基づいて、それをより良くする方法を考えてください。
- 各参加者に意見を共有するための時間を与えます。
- 独創的な思考を奨励します。
- 集中してください。
すべてのアイデアを記録する必要があります。 RCAマネージャーは、会議の議事録とRCAテンプレートの更新を記録するメンバーを割り当てる必要があります。
＃4）根本原因修正措置（RCCA）を実装する
修正アクションには、真の根本原因を特定することによってソリューションを修正することが含まれます。これを容易にするために、修正を実装する必要があるすべてのバージョンと、配信日を決定できる配信マネージャーが存在する必要があります。
RCCAは、この根本原因が将来再び発生しないように実装する必要があります。サポートチームによる修正は、問題が報告されたお客様のサイトに対して一時的なものになります。この修正が進行中のバージョンにマージされるときは、適切な影響分析を実行して、既存の機能が壊れていないことを確認してください。
修正を検証し、実装されたソリューションを監視して、ソリューションが有効かどうかを確認する手順を示します。
＃5）根本原因予防措置（RCPA）を実装する
チームは、このような同様の問題を将来どのように防ぐことができるかについての計画を立てる必要があります。 例えば、 取扱説明書の更新、スキルセットの改善、チーム評価チェックリストの更新など。予防措置の適切な文書に従い、チームが講じられた予防措置を順守しているかどうかを監視します。
こちらをご参照ください 研究論文 「ソフトウェアプロセス品質改善のための欠陥分析と防止」について ソフトウェア工学とアプリケーションの国際ジャーナル 各ソフトウェアフェーズで報告された欠陥の種類を把握し、それらの予防措置を提案します。
RCAから得られた情報は、 故障モードおよび影響分析（FMEA ）ソリューションが失敗する可能性のあるポイントを特定します。
実装する パレート分析 RCA中に特定された原因、たとえば半年ごとまたは四半期ごとに、欠陥の原因となっている主な原因を特定し、それらの予防措置に焦点を当てるのに役立ちます。
根本原因分析手法
＃1）フィッシュボーン分析
フィッシュボーン図は、特定された問題の考えられる原因を特定するための視覚的な根本原因分析ツールであるため、原因と結果の図とも呼ばれます。これにより、症状を解決するのではなく、問題の真の根本原因を突き止めることができます。
によって作成されたため、石川図とも呼ばれます Dr.Kaoru Ishikawa (日本の品質管理統計学者)。ヘリンボーン図またはフィシカワ図とも呼ばれます。
フィッシュボーン分析は、の分析フェーズで使用されます シックスシグマのDMAIC 問題解決のためのアプローチ。それはの1つです 品質管理の7つの基本的なツール 。
フィッシュボーン図を作成する手順：
フィッシュボーン図は、魚の頭を形成する問題があり、魚の背骨と骨を形成する原因となる魚の骨格に似ています。
以下の手順に従って、フィッシュボーン図を作成します。
- 書きます 問題 で 魚の頭 。
- を特定します 原因のカテゴリー と書く 各ボーンの終わり (原因カテゴリ1、原因カテゴリ2……原因カテゴリN)
- を特定します 主な原因 各カテゴリの下で、それを主な原因1、主な原因2、主な原因Nとしてマークします。
- 原因をに拡張します 二次、三次、およびその他のレベル 該当します。
フィッシュボーン図がソフトウェアの欠陥にどのように適用されるかの例（以下を参照）。
フィッシュボーン図を作成するために利用できる無料および有料のツールがたくさんあります。このチュートリアルのフィッシュボーン図は、「 創造的に」 オンラインツール 。 フィッシュボーンテンプレートとツールの詳細については、次のチュートリアルで説明します。
＃2）5つのなぜなぜ分析
5なぜなぜテクニックが開発されたのか Sakichi Toyoda トヨタの製造業で使用されました。この手法は、各回答に理由の質問で回答する一連の質問を指します。それは、子供が大人にどのように質問するかに関係している可能性があります。大人の答えに基づいて、満足するまで「なぜ」の質問を何度も繰り返します。
5問題の根本原因にドリルダウンするために、テクニックがスタンドアロンで、またはフィッシュボーン分析の一部として使用される理由。ステップ数は5に制限されていません。問題の診断が到着するまで、5ステップより少なくても多くてもかまいません。 5なぜなぜ分析は、根本原因に到達するための比較的単純な手法であり、より迅速な方法です。症状を除外して根本原因に到達するための迅速な診断を容易にします。
テクニックの成功は、人の知識に依存します。同じWhy質問に対して異なる回答が存在する可能性があります。したがって、会議で正しい方向と焦点を選択することが重要です。
5つのなぜなぜ分析図を作成する手順
問題を定義することにより、ブレインストーミングの議論を開始します。次に、その後の理由とその回答を続けます。
5つのなぜなぜ分析がソフトウェアの欠陥にどのように適用されるかの例：
5Createlyオンラインソフトウェアを使用してテンプレートと画像を描画する理由。
欠陥の原因となる要因
欠陥の発生を引き起こす多くの要因があります。
- 要件が不明確/欠落/不正確
- 間違ったデザイン
- 誤ったコーディング
- 不十分なテスト
- 環境問題（ハードウェア、ソフトウェア、または構成）
RCAプロセスを実行するときは、これらの要素を常に念頭に置く必要があります。
RCAが開始し、欠陥に関するブレインストーミングを進めます。 RCAをしているときに私たちが自問する唯一の質問は「なぜ？」です。そして何？'ライフサイクルの各フェーズを掘り下げて、欠陥が続く場所を追跡できます。
「なぜ？」から始めましょう。質問、（リストは制限されていません）。 SDLCの外相から始めて、内相に向かって進むことができます。
テクニカルサポート面接の質問と回答pdf
- 「なぜ」欠陥は、 健全性テスト 生産中？
- 「なぜ」テスト中に欠陥が検出されなかったのですか？
- テストケースのレビュー中に欠陥が検出されなかった「理由」は？
- 「なぜ」欠陥は捕らえられなかった ユニットテスト ？
- 「なぜ」欠陥は「デザインレビュー」中に発見されなかったのですか？
- 「なぜ」欠陥が要件フェーズ中に検出されなかったのですか？
この質問への答えは、欠陥が存在する正確なフェーズを示します。フェーズと理由を特定したら、「何」の部分があります。
「将来これを回避するために何をしますか？
この「何」の質問に対する答えは、実装されて処理された場合、同じ欠陥または同じ種類の欠陥が再び発生するのを防ぎます。欠陥または欠陥の理由が繰り返されないように、特定されたプロセスを改善するための適切な措置を講じてください。
RCAの結果に基づいて、どのフェーズに問題領域があるかを判断できます。
例えば、 欠陥のRCAのほとんどが原因であると判断した場合 要件ミス 、その後、より多くのレビューまたはウォークスルーセッションを導入することにより、要件の収集/理解フェーズを改善できます。
同様に、ほとんどの欠陥が原因であることがわかった場合 テストミス 、テストプロセスを改善する必要があります。次のような指標を導入できます 要件トレーサビリティメトリック 、テストカバレッジメトリクス、またはレビュープロセスまたはテストの効率を向上させると思われるその他のステップをチェックし続けることができます。
結論
欠陥を座って分析し、製品とプロセスの改善に貢献することは、チーム全体の責任です。
このチュートリアルでは、RCAの基本的な理解、効率的なRCAを実行するために従うべき手順、およびフィッシュボーン分析や5つのなぜなぜ分析などのさまざまなツールを使用する方法について説明します。今後のチュートリアルでは、さまざまなRCAテンプレート、例、およびその実装方法の使用例について説明します。