こんにちは、クオリティマネージャーのこやまです。
QAメンバーやプロジェクトマネージャーの方で、お客様や上司から「不具合を分析して対策をまとめて」と言われたことはありませんか？
不具合分析と言われるとなぜなぜ分析と信頼性成長曲線分析が思いつきます。信頼性成長曲線分析は不具合収束の傾向を把握できますが、不具合の原因特定までできません。一方、なぜなぜ分析では、不具合の詳細な調査に多くの時間と労力が必要です。
そこで、効率よく原因と傾向が分析できる「ODC分析」があると知り、調べた内容をご紹介します。
ODC分析とは
1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」です。ODC分析のODCは「Orthogonal Defect Classification」の略称で、直訳すると「直交 欠陥 分類」となります。「直交とは直線どうしが直角に交わること」との意味で、お互いに依存しない別軸から欠陥を分類して分析する手法だと理解しました。
お客様よりテスト工程の不具合分析についてご相談をいただいたため、ODC分析を使用してみようと思い「ソフトウェア不具合改善手法ODC分析 工程の『質』を可視化する」※1を用いて更に知識を深めました。
この書籍には以下のように記載してあります。
『ODC分析は、成長曲線のような数量的状態の統計的分析とRCAのような局所的な原因分析とちょうど中間に位置づけられる。ODC分析は、個々の不具合の要因分析とその要因の数値的な分析という両面を持ち合わせている分析手法といえる』
不具合の測定・分析手法におけるODC分析手法の位置付づけ
ソフトウェア不具合改善手法 ODC分析
ODC分析の手順
ODC分析の手順ですが、大きくは３段階で分析する手順を簡単に説明します。
- A.分析したいシステムの不具合を分類
- B.定規や尺度、指標となる不具合の分類結果と比較
- C.プロセス実施の改善策を提供
A.分析したいシステムの不具合を分類
分析する前に不具合に関する考え方を理解する必要があります。ODC分析では、不具合はお互いに依存しない4つの属性（タイプ、トリガー、ソース、インパクト）で構成され、これらの属性が相互作用を起こして引き起こされると考えられております。
各不具合に対して４つの属性それぞれの属性値を割り当てて分類します。因みに属性値は選択肢として予め定義しておきます。
属性の概要※1
ソフトウェア不具合改善手法 ODC分析
属性 属性概要 例 タイプ属性 プロセスに関わる不具合を示唆する属性 値の設定、条件分岐、機能性など トリガー属性 不具合を表面化した動機 レビュー、結合テスト、総合テストなど ソース属性 不具合を含んでいたコードの箇所 新規、再利用、修正など インパクト属性 ユーザ、顧客への影響 使用性、性能、信頼性など 引用元※1には属性の詳細や選択肢も掲載されています。
Ｂ.定規や尺度、指標となる分類結果との比較
定規や尺度、指標となる分類結果は、「プロセス・シグネチャー」と言われており、「開発プロセスの期待」です。「開発プロセスの期待」とは『「正しくプロセスを実施すれば、正しく「しかるべき不具合」の分布になる」』（引用※１）というものです。
ODC分析では前記Aでの分類結果の内、「プロセス・シグネチャー」と異なる点に課題があると考えます。分析したいシステムの不具合を分類した結果と「プロセス・シグネチャー」をグラフ化すると視覚的に異なる点を確認できます。
なお、最初にODC分析を行う場合、定規や尺度、指標となる「プロセス・シグネチャー」を策定する必要がありますが、同じ開発プロセスで成功したプロジェクトの不具合内容を基にODC分析を行い「プロセス・シグネチャー」とするなどの方法が考えられます。
Ｃ.プロセス実施の改善策を提供
前記Bで比較した違いの原因を調べ、原因から示唆されるプロセス実施の「やり方」を考察し、「弱点」を見つけ出し、改善策を策定します。
例として、あるプロジェクトでのプロセス・シグネチャーと現状の不具合分類結果のグラフ、現状の評価、総合評価を以下に紹介します。
プロセスの期待（プロセス・シグネチャー）’（出典 ※1 P108）
ソフトウェア不具合改善手法 ODC分析
プロジェクトの現状（出典 ※1 P108）
ソフトウェア不具合改善手法 ODC分析
現状の評価
『設計・単体テスト工程でのFunction（機能性）の不具合が少なく、機能テスト（統合テスト）で、急増している。設計上はまだまだ機能性の不具合が残存しており、次工程で漏れ出る可能性が高い。』
ソフトウェア不具合改善手法 ODC分析
総合評価
『システムテストの開始基準を満足していないレベルと考える。このままシステムテストを開始すると、前工程で修正すべき不具合が多発し、システムテストの妨げになり、十分なシステムテストができないと考える。前工程の特にFunction、Timing/Serializeを見直しを行ったうえで、開始作業を判定すべきである。』
ソフトウェア不具合改善手法 ODC分析
試しに実施した感想
少ない件数ですが過去の不具合データで試しにODC分析を行った感想です。プロセス・シグネチャーと比較することで、プロセスにおける差異を視覚的に説明することができました。しかしながら、全不具合1件ずつに対して4つの属性を割り当てる作業は、属性毎に多数の選択肢から選ぶ必要があり作業に時間を要しました。
また、複数の担当者で作業をする場合、人により異なる解釈をしてしまうと同じ割り当て結果になるとは限らず、正確な分析ができない可能性があると感じました。分析する前に各選択肢の意味を関係者間で認識合わせしておくのがよいと思います。
導入する際は、不具合管理ツールの入力項目として4つの属性を追加し、各属性に選択肢を定義して、いつ誰がその属性を入力するのか等のワークフローを決めておき、関係者へ説明してから利用開始するのがよいと考えました。
まとめ
ODC分析を利用することで、不具合の調査から対策の策定までを行い、プロセスの品質を改善できます。ただ、属性に割り当てる選択肢が多いため、最初は時間が必要になるかもしれません。ですが、事前準備と慣れで解消できると考えます。慣れてしまえばODC分析は効率的な技法であり、QAメンバーやプロジェクトマネージャーが活用を検討してみる価値がある技法だと確信しました！
※1 杉崎 眞弘 (著), 佐々木 方規 (著), 日科技連ODC分析研究会 (編集), 2020/08/21, 「ソフトウェア不具合改善手法 ODC分析」, 日科技連出版社
