# 直交欠陥分類 ## 定義 直交欠陥分類(orthogonal defect classification, ODC)とは、IBM Watson Researchの Ram Chillarege が開発した、ソフトウェア開発プロセス中に生じる欠陥(defect)を少数の意味論的属性(defect type・defect triggerなど)で分類し、その分布の変化を工程進捗・検証効果の測定値へ変換する手法である。統計的欠陥モデル(定量的だが原因を語らない)と根本原因分析(原因を語るが労力が大きくスケールしない)という2つの極の間のギャップを、意味論に基づく測定システムとして埋める設計思想を持つ。分類が測定システムとして成立するには、属性の値集合が互いに独立である(直交性)、分類が工程を通じて一貫している(工程間一貫性)、特定の製品・組織に依存しない(製品間均一性)という3要件を満たし、かつ分布がプロセス活動の関数として変化すること(必要条件)・値集合がプロセス部分空間を張ること(十分条件)を経験的に検証する必要がある。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]]) ## 属性の構成 - **defect type(欠陥タイプ、8種)**: function・assignment・interface・checking・timing/serialization・build/package/merge・documentation・algorithm。開発プロセス(設計・コーディング・テスト)のどの局面で対応すべき性質の変更かを表し、「開発プロセスへのフィードバック」を担う。(Source: ch.9 §9.4) - **defect trigger(欠陥トリガー)**: 休眠中のフォールトを表面化させた条件。review/inspectionトリガー(人間の思考起因、7種)・function testトリガー(テストケース設計の動機起因、6種)・system testトリガー(顧客利用条件を模した環境起因、6種)の3系統に分かれ、「検証プロセスへのフィードバック」を担う。(Source: ch.9 §9.6) - **多次元枠組み(6属性)**: defect type・triggerを causal attributes(原因系)、source(修正コードの種別)・phase found(発見工程)を sub-population attributes(母集団分割系)、impact(顧客への実効影響)・severity(重大度)を effect attributes(効果系)として整理し、原因と効果を結ぶ多次元解析を可能にする。(Source: ch.9 §9.7, Fig.9.18) - **defect typeとtriggerの掛け合わせ**: 単一属性では見えない検証プロセスの穴(例: あるチームがlateral compatibilityトリガーを使いこなせていない)を、defect type×triggerのクロス集計によって可視化する。ch.9の実例では、この掛け合わせによって高レベル設計インスペクションのスキルギャップを発見し、追加レビューで102件の欠陥・100万ドル超のコスト節約につなげた。(Source: ch.9 例9.5) ## 横断的知見 - **成長曲線モデルの限界を、原因の異なる欠陥群に分割することで補う**: [[ソフトウェア信頼性成長モデル]](SRGM)は欠陥をすべて均質(homogeneous)なプロセスの実現値として扱い、単一の成長曲線(Jelinski-Moranda以来の100以上のモデル)を全欠陥データに当てはめる。ODCはこの前提を破り、defect typeでfunction・assignment+checking・miscellaneousのように欠陥群を分割してから個別に成長曲線を当てはめる。ch.9の実例9.4では、全体の累積欠陥数だけでは安定化の兆しが見えなかったプロジェクトが、type分割後の成長曲線比較によって「設計・コード品質は近く安定化するが、miscellaneous群(documentation・panel/message)は安定化の見込みが立たない」という、単一モデルでは得られない診断に至った。SRGMが「いつ安定するか」を問うのに対し、ODCは「どの性質の欠陥が安定を妨げているか」を問うており、両者は同じ数学的道具(inflection S-curve等)を異なる粒度で使う関係にある。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]] 例9.4, [[@2007__FOSE__Software Reliability Engineering - A Roadmap]]) - **開発時点の欠陥分類と本番運用後の障害分類は、設計原理として同型の課題を共有する**: [[運用障害分析]]で扱うOppenheimer(2003)のcause×location分類やGhosh(2022)のroot-cause×mitigation分類は、本番障害を事後的に多次元へ分解し、単一次元の集計では見えない相関(例:「設定バグの47%がロールバックで緩和」)を導く。ODCは開発時点の欠陥に対して同じ発想——単一の集計値ではなく直交した複数属性の掛け合わせで初めて実務に効くフィードバックが得られる、という設計原理——を1990年代前半に体系化していた。両者の違いは、ODCが分類属性の直交性・工程間一貫性を経験的必要十分条件として明示的に定義し検証する点にあり、運用障害分析側の各分類スキームは属性設計の妥当性を同水準で検証していない。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]], [[運用障害分析]]) ## 未解決の問い - ODCのdefect type・trigger値集合は1990年代のウォーターフォール〜反復開発・メインフレーム/ミドルウェア中心の開発プロセスを前提に設計された(8種のtype、review/function test/system testの3系統trigger)。マイクロサービス・継続的デプロイ・LLMを用いたコード生成が主流の開発プロセスにおいて、同じ属性設計(特にtriggerの3系統区分)は直交性・工程間一貫性の条件を満たし続けるか、それとも新たな属性体系が必要か。 - ch.9は分類コストを「欠陥あたり約2分」と報告するが、これは人間のレビュアーが遡及的に分類する場合のコストである。LLMによる自動分類がこのコストをさらに下げられるとして、直交性・工程間一貫性という経験的検証済みの条件を、人間の判断を介さずに満たせるか(=LLM分類器の出力がODCの必要十分条件を満たすかを検証する枠組みは存在するか)。 - ODCのsource属性(new/old/reused/vendored/re-fixedなど、修正されたコードの種別)は、Chapter 9では簡潔にしか扱われていない。オープンソース・サードパーティ依存が支配的な現代のソフトウェア構成において、source属性はどのように再設計されるべきか。 ## 関連 - source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]] - entity: [[Ram Chillarege]] / [[wiki/entities/IBM T.J. Watson Research Center|IBM T.J. Watson Research Center]] - 隣接concept: [[ソフトウェア信頼性成長モデル]] / [[運用障害分析]] / [[根本原因分析]] ## 出典 - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]] — ODCの一次出典。defect type・trigger属性の定義、必要十分条件、多次元解析の実例。