欠陥分析の基礎知識
欠陥分析とは、欠陥に纏わる情報を調査し、原因や影響を分析する作業です。不具合分析やバグ分析とも呼ばれますが、JSTQBでは、作業成果物に存在する、要件または仕様を満たさない不備または欠点を「欠陥(defect)」と表現している為、本記事では「欠陥分析」と統一しています。
欠陥分析は、目に見えない「品質」の問題を可視化する手法です。欠陥分析を行うことで、欠陥の傾向や発生状況、プロジェクトの進捗状況やテストの状況などを定量的かつ定性的に把握することができます。例えば、テスト期間中の欠陥の検出数が右肩上がりになっている場合は、欠陥が収束しておらず、製品の品質が低い可能性が考えられます。また、欠陥の混入原因でデグレードが多かった場合では、開発状況が逼迫しており、十分な確認行為が行われていない可能性があります。もしくは、仕様やテストミス等が多い場合は、テストの仕様理解が不足している可能性が疑われます。
要するに、欠陥の傾向を把握することで、プロジェクトの様々な側面が明らかになります。
欠陥分析の種類
欠陥分析には様々な手法がありますが、代表的なものは以下の通りです。
この手法は、トヨタの改善方式等で有名ですが、欠陥の根本原因に辿り着くまで、なぜその欠陥が発生したのかを問い続け、欠陥を改善するための手法です。
例:不具合の混入要因が設計ミスである場合
・なぜその設計ミスが発生したのか
→ヒューマンエラーなのか、ドキュメントの記載が分かりにくかったのか
→なぜドキュメントの記載が分かりにくいまま、開発が進んでしまったのか
上記のような「なぜ?」を繰り返して分析し、欠陥の原因を突き止め、対策を検討します。
期間経過と欠陥累積数に基づいて品質を分析する手法で、不具合曲線やバグ曲線とも呼ばれます。テスト開始時は欠陥の検出数が少なく、テストが進捗すると共に検出数が増え、欠陥が修正されるため、後半では検出数が減少するというモデルに基づいて分析します。統計的な分析方法であり、欠陥の量を分析します。
欠陥にラベルをつけて分類し、品質と量の側面から分析する手法です。この分析方法は後述します。
※ODC…Orthogonal Defect Classification 以下ODCと省略します
ODC分析の方法
上記でいくつかの分析方法をご紹介しましたが、今回はODC分析に焦点を当てて説明します。ODC分析とは、欠陥に関するいくつかの情報を追加して分類し、欠陥の質の分析と、分類された欠陥数から量の分析を同時に行う手法です。以下に、ODC分析の進め方を概説します。
1.ODC分析に必要な情報を定義
2.欠陥に対し、情報を付与し分類を行う
3.分類を集計し分析を行う
情報を定義したら、その情報の値(ラベル)を定義します。情報の値についても、分析の目的により異なりますが、例えばシステムテストでの欠陥を分析する場合、次のように値を定義します。

トリガー | 負荷テスト、正常系、例外テスト、起動時、互換性テスト、組み合わせテスト等 |
インパクト | 使用性、性能効率性、信頼性、機能適合性、互換性、セキュリティ等 |
タイプ | 設定誤り、条件誤り、設計誤り、実装誤り、運用不備、ドキュメント不備等 ※上記について、それぞれ「誤っていた」「考慮できていなかった」を付与することもあります。 |
ソース | 新規、更新、修正、既存等 |
次は情報を報告者、修正者が共に付与していきます。付与ができたら集計を行い、その集計結果を分析します。実際の分析では、分類数が多いものにフォーカスをあて、なぜそのような状況となっているのか、その状況は想定内なのか、どのような改善提案ができるかなどを考えていきます。なお、ODC分析は、現在のプロジェクトの状況の問題を可視化し、改善すること目的としているため、ウィークリーの進捗定例等で定期的に報告と改善提案を行うことが推奨されています。分析は多面的に行われるべきであり、1側面だけを見て「〇〇が××だから△△だ」などの結論を出すことは難しいですが、一般的に、機能適合性の欠陥が時系列的に減少している場合、品質が安定している可能性が高いと判断でき、時系列的に減少していないのであれば、品質が安定していない可能性が高いと言えます。
ただし、機能適合性の欠陥がほとんどトリガー「正常系」から発生している場合、テストの量や質に問題がある可能性があるため、次回の欠陥分析時に注意点を意識しながら分析を行いましょう。
欠陥分析をする際の注意点
欠陥分析では、必ずしも「答え」があるわけではありません。あくまで「示唆」するものであり、集計結果から品質を推測するには、欠陥分析への理解や製品に関する深い理解が求められます。洞察力や客観性、広い視野も必要です。例えば、トリガーで「正常系」の欠陥が多く検出されたとして、その意味合いは状況によって異なります。システムテストの中盤での状態であれば問題ないかもしれませんが、システムテストの終盤であれば、それは品質に問題があるか、あるいは、テスト計画に不備がある可能性があります。同様に、ソースが「新規」の欠陥が多く検出された場合も、その意味合いは新規の実装時期によって異なります。システムテストの序盤で実装されており、序盤で「新規」の欠陥が多く検出されるのは妥当ですが、終盤で「新規」の欠陥が多く検出されているのであれば、テストの実施順序に問題がある可能性があります。システムテストの終盤で実装されているのであれば、システムテストに移行した判断に誤りがある可能性があります。このように、結論が一概に出せないため、分析結果は慎重にまとめることが重要です。
実際のプロジェクトでのODC分析事例
オンラインショッピングアプリの品質向上に取り組むある企業では、顧客からのクレームや不具合報告が増加しており、これに対処するために欠陥分析が導入されました。特に、注文処理や商品表示に関する問題が顕著であり、プロジェクトチームはODC分析を通じて問題の特定と解決に取り組みました。

オンラインショッピングアプリの品質改善
ある企業が開発しているオンラインショッピングアプリで、顧客からのクレームや不具合報告が増加していました。特に、注文が正常に処理されない、商品ページが正しく表示されない、決済手続きがエラーになるなどの問題が頻発していました。
情報の定義 :欠陥に関する情報として、トリガー(問題が発生した経路)、インパクト(顧客への影響)、タイプ(欠陥の種類)、ソース(欠陥が発生した箇所)を定義しました。

トリガー | ・システムエラーが発生した際のログイン操作 ・商品をカートに追加する際のボタンクリック ・決済手続きを開始する際の画面遷移 |
インパクト | ・注文が完了しないため、顧客が不要な商品を購入してしまう可能性がある ・商品が正しく表示されないため、顧客が購入を見送る可能性がある ・決済手続き中にエラーが発生するため、顧客が支払いを完了できない可能性がある |
タイプ | ・データベースエラーによる注文情報の消失 ・フロントエンドコーディングにおける表示不具合 ・バックエンド処理の不具合による決済エラー |
ソース | ・注文処理システムのコード ・商品情報を取得するAPIのエンドポイント ・決済ゲートウェイの処理ロジック |
チームは発生した欠陥に情報を付与し、それぞれの欠陥を分類、情報を集計、問題のパターンや傾向を分析しました。分析の結果、多くの注文エラーや商品表示の問題が特定されました。特に、決済手続きに関する欠陥は、新規機能の追加時に発生しやすいことが分かりました。また、品質改善のための優先順位付けも行われ、最も重要な欠陥に対する対策として、ユーザーテストをより広範囲に拡大することとし、実際のユーザーのフィードバックを積極的に取り入れることを決定しました。
ODC分析を通じて、プロジェクトチームはオンラインショッピングアプリの品質改善に向けた具体的な改善策を導き出し、顧客満足度の向上とビジネスの成功に貢献しました。

まとめ
今回は、品質改善には欠かせない欠陥分析の手法として、ODC分析を紹介しました。最近では、ODC分析用の項目が追加されているBTSを使う機会も増えていますが、まだまだ十分に活用しきれていない場合や、導入にコストが増える、欠陥分析を実施できるスキルを持つ人材が不足しているといった課題を抱えるプロジェクトも少なくありません。本記事を読んで、興味を持っていただいた方は是非ご自身でさらに調査を行う、または、お気軽にポールトゥウィンまでご相談ください。