ソフトウエア開発における根本原因分析（RCA）の重要性：不具合対応からプロセス改善へ
こんにちは。スーパーソフトウエア東京オフィス技術部の加藤です。
ソフトウエア開発プロジェクトにおいて、不具合対応は避けられないものです。特に、リリース前のシステム試験やリリース後に見つかる重篤な不具合は、プロジェクトの進捗に大きな影響を与えます。
不具合対応発生時の初期対応
不具合が検出された場合、以下の工程で迅速に対応する必要があります。
場合によっては、インシデント報告書を作成する必要があります。
不具合の事象の確認
不具合の再現性確認
不具合の発生条件の特定
不具合を起こしているコードの特定
回避策の検討
コード修正または暫定対応
修正後のテスト
テスト工程への適用または顧客へのリリース
根本原因分析（RCA）の重要性
しかし、不具合対応だけでは根本的な解決にはなりません。組織としては、問題がなぜ発生したのか、防げなかったのかを分析し、根本的なソフトウエア開発のプロセスや組織の体制について改善を進める必要があります。これが「根本原因分析（RCA）」です。
ウォーターフォール開発における根本原因分析（RCA）の例
ここでは、ウォーターフォール開発において、システム試験で重篤な問題が見つかったケースを例に、原因を追求する一例を説明します。
問題点の明確化：発生した事象や影響範囲などを事実に基づいて把握します。
情報の収集：関連するデータ、設計書などの情報、関係者からのヒアリングを行い情報を収集します。
時系列での把握：問題が発生するまでのタイムラインでの情報収集と整理を行います。
問題発生工程の特定：問題が発生した工程を特定します（ここではシステム試験）。
問題流入工程の探索：問題が流入した工程を探索します。
問題箇所の特定：問題となっている事象が、どの工程に間違い（欠陥）があったのか、設計漏れがあったのかを特定します。
原因の探索：流入工程が特定できたら、詳細プロセスや仕事の流れを書き出し、問題の流入ポイントを絞り込みます。関係者と集まって根本原因を探索します。
問題流出ポイントの把握：問題が流出してしまったポイント（レビューやテスト工程など）を特定し、摘出すべき工程で摘出できなかった原因を掘り下げます。
根本原因の特定手法
根本原因の特定には、以下の手法が有効です。
5Why分析：「なぜ？」を5回繰り返すことで、表面的な原因だけでなく、より深い根本原因に迫ることができます。ただし、同じ「なぜ？」を繰り返してしまうことがあるため、注意が必要です。
ブレーンストーミング：関係者と自由に意見を出し合い、多角的な視点から原因を洗い出します。
ロジックツリー：問題をツリー状に分解し、原因を段階的に掘り下げていきます。ロジックツリーを作成する際には、漏れや重複がないようにMECE（ミーシー）の原則に注意を払います。
ミーティングの進め方
ミーティング時間は30分程度と短く、集中的に行われます。参加者は、バグに関わりのある開発者、テスト担当者、プロジェクトリーダー、チームリーダーなど、数名程度が一般的です。場合によっては、顧客や運用担当者が参加することもあります。
会議中は事実と憶測が飛び交うことが予想されます。ファシリテーターは、発言された事柄が事実なのか、憶測なのか、仮説なのか正確に分類しながら、情報を整理していきましょう。
ファシリテーターの役割
ミーティングを取りまとめるのは、ファシリテーターの役目です。経験豊富なメンバーが担当することが望ましいですが、プロジェクトリーダーやチームリーダーが担当することもあります。
根本原因分析（RCA）実施の注意点
関係者の意見を積極的に聞く：様々な視点から意見を聞くことで、より客観的な分析ができます。
客観的なデータに基づく分析：ログや設計書などの客観的なデータに基づいて分析することで、主観的な判断を避けることができます。
組織的な問題も考慮する：不具合の原因は、個人のスキル不足だけでなく、組織のプロセスや文化に起因する場合もあります。
担当者への攻撃を避ける：問題を特定するのではなく、プロセス、環境、組織風土に目を向けます。
オンサイトメンバーへの配慮：現地での査定に関わる可能性があるため、彼らの意見を尊重しつつ、深い議論ができるように配慮が必要です。
ソフトウエア開発現場の不具合の分類
要因分析を実施するにあたり、想定されるソフトウエア不具合原因、不具合の分類をまとめておくと、分析がやりやすくなるかもしれません。
ソフトウエア開発における不具合の原因
ソフトウエアバグの分類
これらの問題は一見根本原因のように見えますが、さらに深掘りが必要です。ここから深掘りをしないと、対処療法的な改善となり根本的な改善になりません。ソフトウエア開発プロセス改善や組織風土、リソース、体制の改善までさかのぼることが望ましいです。
類似問題の探索と再発防止策の検討・実施
根本原因を特定したら、類似問題の探索を行い、再発防止策を検討・実施します。
具体的な対策の検討：根本原因に基づいて、具体的な対策を検討します。
対策の実施と効果測定：対策を実施したら、その効果を測定し、改善点があれば見直します。
プロセス改善へのフィードバック：再発防止策を、今後のプロセス改善にフィードバックします。
別の視点でも分析を行ってみる
摘出された不具合は、発生工程、チーム、バグの種類でデータを蓄積します。不具合の傾向を分析することで、プロジェクトの弱点を把握し、改善に繋げます。ソフトウエアの品質は均一ではなく、特定の箇所に不具合が集中する「バグの偏在」が見られることがあります。不具合データを蓄積・分析することで、開発チームの傾向や弱点が明らかになる可能性があります。
さらに、以下の視点で分析することで、さらなる改善にもつながるかもしれません。
不具合の重要度: 不具合の深刻度を分類し、優先度をつけて分析することで、影響の大きい不具合を重点的に対策できます。
修正コスト: 不具合の修正にかかるコスト（時間、人員など）を記録することで、費用対効果の高い改善策を検討できます。
時系列変化: 不具合の発生状況を時系列で分析することで、開発プロセスにおける問題点や、特定の時期に不具合が増加する傾向などを把握できます。類似不具合の検索: 過去の不具合データと照らし合わせることで、類似の不具合を早期に発見し、対応を効率化できます。
まとめ
ソフトウエア開発における根本原因分析（RCA）は、大きなエネルギーを必要とします。しかし、組織やプロセスの問題を改善しない限り、問題は再発し続けます。組織全体で前向きに改善に取り組むことが、より良いソフトウエア開発につながるでしょう。
この情報が、ソフトウエア開発における問題解決の一助となれば幸いです。
▼採用情報
▼新卒情報はWantedlyで