ODC分析についてのよもやま話〜 ソフトウェア不具合についてのあれやこれや・・・〜第４回「ソフトウェア不具合についての３つの気づき」(3)

ODC分析発案の動機となった「ソフトウェア不具合についての３つの気づき」は以下の通りです。
①開発プロセスの観点
②不具合の持つ属性の観点
③プロセス実施の質と属性との関係

これまで①開発プロセスの観点と②不具合の持つ属性の観点の「気づき」を説明してきました。

①開発プロセスの観点からの「気づき」として、「工程ごとの不具合の出方を見ることで、そのプロジェクトの行末が予測できる。」ということです。
その根拠となる見方として、「不具合は少ない程、開発プロセスの期待通りの開発活動を行っている。不具合が多発しているのは、逆に「何かおかしい」ことを行っている。」というものです。このことを下図を使って説明しました。

開発工程ごとに不具合の出方を捉えることができれば、それらを生み出した工程ごとの開発プロセス実施の「質」すなわち不具合を生み出す「やり方」をしているかどうかの推察が可能となる、という「気づき」です。

次に、ODC分析の象徴的な特徴である②不具合の持つ属性の観点での「気づき」として、個々の不具合には、それぞれ生い立ちや素性、個性があり、それらは独立した３つの側面とそれぞれに属する４つの排他的 = Orthogonal（相互依存のない）要素、要因で構成されていると考えます。その一つ一つを明らかにすることで、個々の不具合の成り立ちが説明できる、という「気づき」です。

概念的な絵にすると次のようなことです。

ODC分析では次の３つの側面とそれぞれに属する４つの属性 (Attributes)を定義しています。

また、1件の不具合は４つの属性の相互作用によって成り立ち、発生していると捉えます。
さらに、それぞれの属性にはおのおのに属する副属性（原典ではValue: 選択肢と解釈すると分かりやすい）が定義されており（第3回参照）、ODC分析の手法となる不具合分類において、これら副属性（選択肢）のどれに当てはまる不具合かを選択していきます。

そして今回、③プロセス実施の質と属性との関係の「気づき」について説明します。
正確にいうと「開発プロセス実施の質とODC属性の出方との関係」となります。
この３つ目の「気づき」こそが、これまでの２つの「気づき」に立脚したODC分析評価の着目点、考え方になっている重要な部分であり、ODC分析発案の原点になります。

この「気づき」から導き出されたことは、「開発プロセス実施の「やり方」の質は、ODC分析の不具合属性の出方から読み取ることができる。」ということです。
それがどういうことかを説明していきます。

不具合研究チームの分析*1によると、開発プロセスで定義されたそれぞれの工程において、かなりの確度で発生する（出てしかるべき）タイプ属性 (Defect Type) の分布が明らかになっています。
開発プロセスの各工程で出てしかるべきタイプ副属性は、理論的に下図1のように予測できます。

注）タイプ属性の分布は、前提とする開発プロセスのコウテイ定義に依存します。ここで示す分布は、一般的なV字プロセスモデルに基づいています。
正しく実装された実プロジェクトでの結果も、多くの場合これに近似していることが実装されています。

なぜ、そう言えるのか、開発プロセス工程ごとにタイプ属性との関係から以下にひも解きます。

(1)基本設計工程

基本設計レビューでは要求仕様と設計仕様との整合性比較が主眼となります。
従って、ここでの指摘事項（不具合）は「要求仕様にある機能性」を具現化する「設計仕様の機能性」への指摘すなわちタイプ副属性「Function（機能性）」に関わる「Missing（欠如）」、あるいは要求の理解不足や仕様の不整合など正しさについての「Incorrect（誤り）」が発見されてしかるべきです。

(2)詳細設計工程

詳細設計レビューにおいては、基本設計仕様をさらに詳細化、具体化した詳細設計仕様の妥当性、整合性、実現可能性が主眼になります。
そのため、機能間あるいは処理間での処理条件、処理順番、処理タイミングに関わるタイプ副属性である「Checking（条件分岐）」「Timing/Serialize（タイミング/処理順番」、あるいはAPIなど機能間のやり取りに関わる「Interface（インターフェース）」などの「欠如」か「誤り」の指摘（不具合）が発見されてしかるべきです。

(3)コード / 単体テスト工程

コード・インスペクションあるいは単体テストにおいては、コード上で有無や正誤が一目で分かる「Assignment （値設定）」や「Checking」、あるいは起動をかけても動かない、動きがおかしい、予期せぬエラーが出るなど「Algorithm（アルゴリズム）」や「Interface」という表面化しやすく、視覚的にも発見しやすい不具合の「欠如」か「誤り」が発見されてしかるべきです。

(4)機能テスト工程

詳細設計書にある機能仕様の記述と実装されたコードとの機能の動き、振る舞いの整合性を検証することが機能テストの主眼になります。従って、タイプ副属性として機能の妥当性に関わる「Function （機能性）」、あるいは機能間連携に関わる「Interface」、また処理ロジックなど「Algorithm」に関わる「欠如」か「誤り」の不具合が発見されてしかるべきです。

(5)システムテスト工程

システムテストでは、機能の検証が完了したソフトウェアが、要求を具現化した基本設計書にある機能要求、非機能要求を満たしているかをユーザーの立場から検証することが目的です。
よって、ユーザーの使い方、使用環境などを考慮した過負荷なストレス・ロングランテスト、エラー復旧テスト、外部機器との接続テストなどクリティカルな状態でのロバストネス(堅牢性)が試されるテストになります。
従って、「Timing/Serialize」あるいは「Interface」というタイプ副属性の「欠如」か「誤り」の不具合が多く発見されてしかるべきです。

と、考えます。以上のことから、タイプ副属性と開発プロセス工程との関係（図１）の見方を変えると以下のような、タイプ属性分析の観点となります。

▶タイプ副属性には、それぞれに検出されてしかるべき工程がある。

ということに着目することで、次のようなタイプ属性分析による改善への「やり方」が発案されました。

1）個々のタイプ副属性それぞれが、図１に反して出てしかるべき工程以外で頻繁に検出されるのは、「何かおかしい？」と捉えます。

2）その「何か」は、適用する開発プロセスの規定(期待)と実際のプロセス実施の「やり方」にギャップ（何かおかしいことをやっている）があることを示唆している

と考えます。

3）そこからアクションとして、「何がおかしいか？」を現工程での実施内容さらに前工程までの実施内容を見直して、「何が」開発プロセスからの逸脱、抜け、漏れ、間違えているかを特定し、その原因である「おかしいこと」つまり「やり方」のギャップを改善していきます。

「何かおかしい？」ことのよくある事例として、次のようなものが挙げられます。

機能テストで、「Timing/Serialize」の不具合が頻発する。

機能テストで仕様書通りの機能性の検証が完了していないまま、システムテストでやるべきテスト項目をやり始めていることを示唆しています。
機能性の検証あるいは修正が完了していない状態でのシステムテスト項目の実施自体無効なので、無用に不具合件数を増やすだけです。スケジュールが逼迫した場合に起こりがちな先を急いだ「なし崩しテスト」は即中止して、機能テストをまず完了すべきです。

システムテストで、「Function （機能性）」の不具合が多い。

機能テスト完了時点においては、既にあらかた摘出されているべきタイプ副属性「Function」の不具合が、システムテストに漏れている（残存している）ことを示唆しています。
このままシステムテストを継続しても、前工程からの漏れ不具合によってシステムテストの遂行が阻害されるだけです。機能テストの「やり方」（カバレージやテストバリエーションなど）を見直し、再テストすべきです。さらには必要なら設計見直しをすべきであると考えます。

次に、ここからはタイプ属性分析でもう一つ、識別子「Missing（欠如）」と「Incorrect（誤り）」の示す特性を説明します。

▶ODC分析では「Missing（忘れてました）」と「Incorrect（間違えました）」とでは、意味合いの異なる不具合として識別します。

と、前回のタイプ属性の説明で書きました（第3回参照）。以下にこの識別子による評価観点について説明します。

不具合研究チームの分析*1によると、タイプ属性の識別子である「Missing（欠如）」と「Incorrect（誤り）」にも同様に開発プロセスの「やり方」の質との関係があることが説明できます。（下図２）

▶要求分析や基本設計では、要求の具現化を検討している過程では、要求の抽出漏れや理解不足、考慮不足などで、識別子「Missing」が多くなる傾向にある。

▶工程が進み、設計詳細化やそのレビューが進むと、漏れや不足は減少し、当初設計したことの誤りに気づくことが増えるため、識別子「Incorrect」が主体となる。

そのことから、次のことが言えます。

▶工程が進んでも「Missing」が多いのは、上流設計でのレビューの抜け、漏れや不十分さ、あるいは急な要求変更や仕様変更への未対応が示唆される。

ここまで、タイプ属性と開発プロセスとの関係についての「気づき」を説明しました。
次に、トリガー属性についての「気づき」を見ていきます。

前述のタイプ属性は、「不具合の不具合たるゆえん」つまり不具合の特徴、特性を直接に分析していくための属性であると言えます。

一方、トリガー属性は、「不具合を発見した動機」という定義から、不具合をどのような検証作業をしていて発見したかという人為的行為を分析することで、開発プロセスで期待されている検証内容に対して実際の検証作業の妥当性、的確性、合目的性を分析します。こうすることで、検証作業の「やり方」を改善していくための属性であると言えます。

検証作業（トリガー）は、適用する開発プロセスの定義や特性（工程定義、作業定義）に従って発生します。それゆえ各工程での検証作業に伴うトリガー属性は異なっています。
そこで、工程を設計とテストに大別して、どのような観点でトリガー属性分析するかについて説明します。

設計の観点：トリガー属性とレビューアの経験値との関係を分析

レビューを実施するレビューアの知識や経験値によって、レビュー観点や視野に差が出ます。
このことから不具合研究チーム*1は、レビューアの知識・経験の差によるレビュー観点の異なりが、トリガー属性と関係付けられることに気づきました。（下図3）

上図３からレビューアは自身の持つスキル領域と経験によって、それぞれ異なるレビュー観点を持って異なる不具合を見つけようとしていることが分かります。
別の言い方をすると、レビューアの経験値に伴う「やり方」の質に呼応するトリガー属性のカバレージを示しています。

例えば、設計レビューにおいてレビューアの経験の有無で次のような差が出ます。

• 経験の浅いレビューア(新人/見習)は、設計仕様書の記述のみで処理の詳細の正しさを検証しようとする傾向があります。このことは、直接設計を担当する設計者のみのレビューにおいても多々起こります。

• 経験のあるレビューアは、設計仕様書の正しさを検証するにも、設計仕様書の記述と、設計の元となる上位の要求仕様書や関連する設計ドキュメントとの整合性、妥当性を検証しようとします。

どちらもやるべき検証ですが、新人のみでレビューをした場合、設計仕様書の記述のみのレビューにとどまりがちで、実は設計の基となる要求仕様書との仕様解釈に不整合があっても気づけない場合があり得ます。

これらの「気づき」から次のことが考察できます。

• どの工程レビューにおいても、何を持って「良し」とするかという判断基準を定義しておくべきで、レビューア自身もそれを理解しておくべき。

  基本的には、その判断基準は前工程の成果物（検証済み上位文書）に解を求めるのが、プロセス的な正しさとなる。

• レビューの指摘事項が特定の範囲や観点に集中しているような場合は、レビューア選定の妥当性を見直す必要があることを示唆している。

  レビューに際しては、広範に異なる知識・経験を有するレビューアを選定して実施することが網羅性や検証深度向上に必要となる。

  また、特定領域では代替が利かない専門性を持つレビューアが必要なことを認識しておく必要もある。

テストの観点：トリガー属性とテスターの経験値との関係を分析

テスターの持つ経験値によりテスト観点、深さが異なるため、検出される不具合のトリガー属性も異なってくることが分かっています。
テスターの経験値でテストの観点・カバレージに違いや差が出てくることを、下図4に示します。

この図４が示唆すること、および考察できることをまとめると、以下の３つのことが言えます。

• テスト計画、テスト仕様書、テスト結果などのレビューにおいて、経験値の異なるテスターを組み合わせて、レビュー観点や視野を広げて行うことが、検証漏れ、テスト漏れを防ぐために必要である。
• 逆の見方から、テスト仕様の設計時に、トリガー副属性を意識して作成したテスト・ケースを分類してみると、テスト目的、領域、項目の偏りや抜けがテスト実施前に発見できるようになる。
• テスト漏れ、不備などで不具合を漏らした時には、テスト管理者のみならず、テスト担当者自身も真摯に反省して、テスターとして欠けていた観点、深さ、範囲が認識できるよう指導する場が必要となる。

こうした知見や反省は、Know-Howとして蓄積して、テスター教育に反映されるべきなのです。

ここまで、ODC分析発案の動機となった不具合についての３つ目の「気づき」である ③ プロセス実施の質と属性との関係を説明しました。
ODC分析をご存じの方からは、「まだソース属性とインパクト属性が登場してませんが・・・」という声が聞こえてきそうです。その通りです。

タイプ属性とトリガー属性は直接的、人為的要因で分析・評価でき、改善項目の具体化に結び付いていきますが、ソース属性とインパクト属性は対象不具合の結果論的要素ゆえ、これまで特に「気づき」について論じられてきませんでした。
興味のある方は、ぜひ研究して成果を教えていただきたいものです。

 3回にわたってODC分析発案の動機となった「ソフトウェア不具合についての３つの気づき」についてお話ししてきました。
そして、これら「３つの気づき」から生まれたのが次のような発案です。

「不具合を属性ごとに分類することで、意味論的議論が可能となり、不具合を生み出す「やり方」を特定することができるのでは・・・」

この発案から、Ram先生の掛け声でODC分析手法化の社内タスクが開始されることとなったのです。
次回は、これまでの「３つの気づき」から導出されたODC分析のコンセプトと分析手法の「やり方」について解説します。

参考文献：

*1) Orthogonal Defect Classification – A concept for In-process Measurement
Ram Chillarege, Inderpal S. Bhandari, Michael J. Halliday, etc., IBM Thomas J. Watson Research Center
IEEE Transactions on Software Engineering Vol .18, No. 11, Nov. 1992ⒸIEEE
　https://ieeexplore.ieee.org/document/177364

*2) ｢ソフトウェア不具合改善⼿法ODC分析」 〜 ⼯程の「質」を可視化する 〜
⽇科技連ODC分析研究会編 杉崎眞弘・佐々⽊⽅規
株式会社⽇科技連出版社 (ISBN978-4-8171-9713-9)

*3) INCOSE SYSTEMS ENGINEERING HANDBOOK V.4
A GUIDE FOR SYSTEM LIFE CYCLE PROCESS AND ACTIVITIES
WILEY (ISBN: 978-1-118-99941-7)