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

前回から、ODC分析を発案する動機となった「ソフトウェア不具合についての３つの気づき」
①開発プロセスの観点
②不具合の持つ属性の観点
③プロセス実施の質と属性との関係
について話を始めました。

前回は、その一つ目　① 開発プロセスの観点からの「気づき」として、
（正確には、開発プロセス実施の質の観点からの気づきというべき）次のように述べました。

▶　工程ごとの不具合の出方を見ることで、そのプロジェクトの行末が予測できる。

その根拠となる見方として、

▶　不具合は少ない程、開発プロセスの期待通りの開発活動を行っている。

▶　不具合が多発しているのは、逆に「何かおかしい」ことを行っている。

ということです。
このことを追求した結果、

①開発プロセスの観点での「気づき」

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

前回は、ここまで解説しました。
今回は、ODC分析の象徴的な特徴である二つ目の「気づき」、不具合の持つ属性について説明します。

②不具合の持つ属性の観点での「気づき」

少しでもODC分析のことを学ばれた方は、ODC分析といえば「属性」を連想されるのではないかと思います。そのことが漠然と難しさを感じさせ、ODC分析を始めようにも二の足を踏んでしまう理由の一つではないかと、常々ODC分析研究会を通して感じています。
私が思うに、その理由はこれまで属性の意味を正しく理解する機会がなかったからではないかと考えています。
ぜひこの機会に理解を深めて、親近感を持っていただきたいと思います。

ここで「属性」の話を始める前に、知っておいていただきたいことがあります。
それは、そもそもODC（Orthogonal Defect Classification）という言葉に込められた意味のことです。
原典としているRam先生（Dr. Ram Chillarege）の論文によると、おおよそ次のように説明されています*1)。

「Orthogonal」という単語は、数学や統計学をやられている方でない限り、なかなか日常的に使う単語ではないと思います。辞書を引くとまず「直交」という訳が目に入ります。
すると、ほとんどの方は直交する２本の直線をイメージされるでしょう。

しかしながら、ここで「Orthogonal」を使う理由は、次のことからだと述べられています。
個々の不具合について説明するには、周囲を直角に交わる(orthogonalな)壁と床に囲われた部屋の中で、ある物の位置を説明するのに似ているからだと。つまり床から何cm、右の壁から何m、奥の壁から何mという言い方をすると、そのある物の位置は特定できます。

それと同じように、個々の不具合には、それぞれ生い立ちや素性があり個性があります。
それらは独立した三つの側面とそれぞれに属する四つの排他的 = Orthogonal（相互依存のない）要素、要因で構成されていると考えると、 その一つ一つを明らかにすることで、個々の不具合の成り立ちが説明できるからである、と説明しています。

この説明だけでは何のことか分かりにくいので、私は次のような絵を描きました。（図１）

いかがでしょうか、イメージが湧きましたでしょうか？

続く「Defect」です。
“Defect（不具合）”という言葉は、普段から使われていて、「障害」あるいは「欠陥」とも呼ばれています。

そして、「Classification」。
“Classification（分類）”という言葉こそ、このODCを理解するための核となります。
何かを分類 (classify) するとは、意味のある種類ごとに振り分けることだからです。

名は体を表すの通り・・・
くだんの論文の中で、Ram先生と彼の研究チームの調査・研究の成果*1として、

• 意味論的に不具合を分類(classify)し、分析する事で、不具合を抑制 (Defect Control) する策ができ、適用する開発プロセス実施の「やり方」の質を改善できる可能性があることを探り当てることができた。

とあります。
言葉の話の続きとして、本来、ODC (Orthogonal Defect Classification)という完結した言葉そのままで、「直交的不具合分類」とでも訳せますが、「ODCする？」ではどうも日本語的には据りが悪いのです。
そこで、日本科学技術連盟(日科技連)でのODC分析研究会で使い始めた「ODC分析」と表現するようになりました。

不具合の三つの側面と四つの属性

ODC分析が定義した「属性」正確には「ODC分析属性」を説明します。
前節で述べたように、

▶　不具合には生い立ちや素性があり、それらを明らかにすることでその不具合の成り立ちが説明できる。

という想定から、さらに見方を変えて不具合の分析という観点から追求すると、

▶　不具合の成り立ちは、生い立ち、素性という観点から見た属性で分類できる。

という見解に至った、とあります。
この属性定義を、原典に基づいて一通り説明していきます。

ODC分析では次の三つの側面とそれぞれに属する四つの属性 (Attributes)を定義しています。(図１参照)
それぞれの側面とそこに属する属性を図２に示します。

ODC分析では、1件の不具合は四つの属性の相互作用によって成り立ち、発生していると捉えます。
さらにODC分析では、それぞれの属性にはおのおのに属する副属性（原典ではValue: 選択肢と解釈すると分かりやすい）が定義されています。
ODC分析において不具合を分類する際には、これら副属性のどれに当てはまる不具合かを選択していくので、まさに選択肢と言えるわけです。

次に、それぞれの属性における副属性（選択肢）の定義を説明します。

タイプ属性 (Defect Type)

定義：
不具合の意味するところの理解に最も影響力のある属性がタイプ属性です。
意味論に基づいて分類され、適用する開発プロセスに呼応した示唆を含んでいます。

タイプ属性の副属性：
タイプ属性に属する副属性は図３のとおりです。

▶　タイプ属性の副属性（Value: 選択肢）は、上図３のように定義されていて、お互いがorthogonalな（依存性がなく、相入れない）ものとなります。

▶　タイプ属性の特異点として、副属性それぞれに対して「誤り (Incorrect): 間違えました」または「欠如 (Missing): 忘れてました」のいずれかの識別子 (Qualifier)が必ず付随します。この識別子については後述します。

▶　タイプ属性の副属性の選択は、その不具合の修正内容を把握している不具合修正者が最もふさわしく、修正確認がされた時点で決定されるべきものです。

タイプ属性の識別子について

タイプ属性において、不具合の要因として「間違えました！(Incorrect)」と「忘れてました… (Missing)」とでは意味論的に異なる要因による不具合と分類します。

• Incorrect (誤り)：

  仕様記述、コーディング、テストケースなどの間違いによる不具合を示唆することが多いです。

  Incorrect (誤り)は進行中の工程での不具合混入の場合が多く、すぐに発見されるべき不具合です。

• Missing (欠如)：

  要求の見落とし、仕様の抜け、実装漏れなどによる不具合を示唆することが多く、

  Missing(欠如)は混入された工程以降で発見される場合が多いです。
  プロセス規定、レビュー規定などの不備あるいはそれら実施の不十分さなど、開発プロセス実施における根深い原因が考えられます。

トリガー属性 (Defect Trigger)

定義：
トリガーとは、不具合が表面化あるいは発見された行為または条件を指します。
トリガーは、適用する開発プロセス規定に依存し、開発工程ごとに定義された検証作業の具体的な行為とも言えます。
トリガー属性は、それら各工程のトリガーを汎化し、不具合が発見されたトリガーに呼応して付記されます。

▶　トリガー属性は検証作業の効果への示唆を提供します。
(開発プロセスには直接ではないが、検証プロセスには直接の示唆となります)

▶　上記定義から、トリガー属性は適用する開発プロセス定義にその登場が依存するため、工程定義によって異なるトリガー属性を定義します。

▶　トリガー属性の選択は、不具合を発見したレビューアあるいはテスターが行うのが適切です。

工程ごとのトリガー属性

レビュー/インスペクション工程でのトリガー属性

レビュー/インスペクション工程とは、要求分析レビュー、設計レビュー、コード・インスペクションなど開発上流での設計ドキュメント、成果物のレビューを含めた検証作業工程を指します。（図４）

注）トリガー属性の場合、工程ごとに異なるトリガーが選択肢となるので、あえてトリガー副属性と呼ぶ必要はないと考えます。

単体/機能テスト工程でのトリガー属性

テスト工程におけるトリガーは、不具合を検出したテストケースが何を意図したものであったかを表します。（図５）

システムテスト工程でのトリガー属性

システムテスト工程におけるトリガーは、要求から導かれたテストケース、あるいはテストシナリオが何を意図したものであったかを表します。（図６）

なお、トリガー属性はレビュー観点の偏りやテストケースのカバレージの妥当性を見るには適していますが、不具合の本質的な議論には結び付かない面があります。

ソース属性 (Defect Source)

定義：

不具合が発見あるいは修正された開発関連文書あるいはソースコードの箇所の、開発履歴に関わる観点からの不具合属性をソース属性と言います。

ソース属性の副属性（選択肢）

ソース属性には、不具合を含んでいた箇所から次のような副属性が定義されています。

▶　ソース副属性の選択は、対象不具合を修正した開発者が決めます。

▶　ソース副属性の選択で注意したいのは、次の二つです。

• Reused-code（再利用）は、再利用を目的としたコンポーネント、機能群など管理されたライブラリーから持ってきたコードに不具合があった場合のことを言います。混同されやすいのは、単に他のソースコードから一部を切り出して持ってきたような場合は、流用であって再利用とは異なるということです。

• Scaffolded-codeあるいはTemporally-codeと呼ばれる、試しに組み込んで実験的に試したコードを指し、テスト対象には成り得ないコードがそのまま残っていて、そこに不具合があった場合の選択肢です。

▶　ソース属性は、ソースコードのみならず要求仕様書、設計仕様書など開発関連文書に不具合があった場合も適用します。

▶　ソース属性とタイプ属性を組み合わせて分析すると、検証の疎密、カバレージの偏り、検証担当者の適切さが明らかになります。

インパクト属性 (Defect Impact)

定義：

発見された不具合が、お客様 (ユーザー) にどのような影響を与えているかを示すのが、インパクト属性です。

インパクト属性の副属性

インパクト属性の副属性は次のように定義されています。（図８）

▶　図8で示すインパクト副属性は、ODC分析確立時に当時のIBM社の品質メトリクスを採用したもので、長年全社で使ってきた実績のあるものです。

▶　一見、品質特性の非機能要件のように見えます。その通りで、この定義は企業や組織で規定している品質メトリクスから引用して、対象とする製品開発の特徴に合わせて再定義してもよいものです。

▶　対象製品によっては、昨今重要視されている「利用時の品質」特性(ISO/IEC 25010)も考慮すべきです。

この「利用時の品質」（ISO/IEC 25000シリーズ：SQuaRE）については、この連載の後半で改めて説明するつもりです。

▶　インパクト属性は、不具合によって引き起こされるお客様への影響度合いであることから、この不具合の分類はお客様側に立って評価すべきで、直接不具合に直面したレビューアあるいはテスターが決定すべきです。

ここまで、不具合についての３つの「気づき」の二つ目、不具合の持つ属性を説明しました。

実際に、これら四つの属性を使って分類ができる（精度を持って）ようになるには、書き物を読んだだけですぐできる方は少なく、多くの方々は属性選択の適切さに悩むと思います。とはいえ、まず自身で手を動かして分類してみる、悩んだら周りの人の意見を交わしてみることが大事で、その積み重ねが選択精度向上の経験値になってくるのです。

 私自身、Ram先生直伝のODC分析を、一人で自分の担当するプロジェクトでの不具合を属性分類してみることから始めました。
そしてその属性分布をグラフにしてみる、そこから得られる示唆を関係者に説明し、議論する、そうしたことが次第に経験値になっていったと思っています。

ここで重要なのは、その示唆していることが事実と合っているかを裏付け調査することです。この事実確認を必ず行うことで、自分の見立てが正しいかどうかを確認してください。
裏付けのない説明は、まるで怪しい占い師のお告げのように見えてしまうからです。

結果、事実と合っていれば自慢し、違っていれば間違いを調べ直す。そんなことを繰り返すことで、だんだん分析の精度が上がり、説明に自信が出てきて、周りからもODC分析が認められるようになっていきました。
そんな私の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

*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)