ODC分析についてのよもやま話〜 ソフトウェア不具合についてのあれやこれや・・・〜第５回「ODC分析のコンセプト」

①  開発プロセスの観点からの気づき

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

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

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

Zoom

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

個々の不具合は、独立した三つの側面とそれぞれに属する四つのOrthogonalな属性（要素、要因）で構成されている。

　▶それらの属性を明らかにすることで、個々の不具合の成り立ちが説明できる。

Zoom

③     プロセス実施の質と属性との関係についての気づき

開発プロセス実施の「やり方」の質は、ODC分析の不具合属性の出方から読み取ることができる。
例えば、開発プロセス各工程で出て然るべきタイプ副属性は、理論的に下図のように予測できる。

Zoom

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

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

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

以上の前回まで説明してきた「不具合についての３つの気づき」から、次のような着想が生まれました。 

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

この着想を具現化すべくODC分析が発案されました。
ODC分析の発案者であるRam先生から各国IBMの研究所に招集がかかり、私も参加したODC分析手法化と教育展開の社内タスクが開始されることとなりました。

このRam先生の社内タスクでは、先生自ら指導の下、次の活動が行われました。

　▶ODC分析のコンセプトを共通理解するための輪講

　▶各自持ち寄った自組織での不具合の分類・分析の発表と講評

　▶このタスクの目的である、ODC分析を「人に教える」ためのトレーニング

なかなかタフなプログラムで実施され、修了時に各自に社内講師として自組織に展開する任が与えられました。

こうしてODC分析手法が確立され展開されてきました。

それでは、Ram先生から直伝を受けたODC分析のコンセプトの概略を説明します。
ODC分析のコンセプトは、Ram先生の言を借りると次の言葉から始まります。

ソフトウェア開発において、その進捗を妨げる主たる要因は不具合の発生です。
その妨げを低減するには、｢不具合を抑制する (Defect Control)」ことが重要であると考えます。 

「不具合を抑制する」とは、現状このまま推移すると、この先でも起こることが予測される不具合の発生を、事前にしかるべき手を打つことで、未然に防ぐ（control: 抑制する）ことです。
そのためには、次の二つのことが求められ、そのための方法論が必要となります。

　▶まず、それら不具合を生み出している「やり方」を発見する。

　▶その「やり方」を改善するためのアクションを策定し、実施する。

すると、上記の言葉は、「不具合を抑制する (Defect Control) には、ソフトウェア品質改善への洞察と示唆を得ることが必要である。そのための計測方法と分析方法論の基になるのが、Orthogonal Defect Classification (ODC)である。」と、読めます。

 その実践的試行である、不具合研究チームの調査・研究の成果*1として、次の考察が得られました。
「意味論的に不具合を分類(classify)し分析する事によって、不具合を抑制(Defect Control)することができ、適用する開発プロセス実施の改善への提言を生み出せる可能性があることを、探り当てることができた。」
このことから、「ODC分析の目的は、開発プロセス実施の「やり方」の質の改善にある。」と理解することができます。

「不具合を抑制する」ことがどう改善に結び付くのでしょうか？　以下にて三つの想定を提示した上で、考察してみたいと思います。

想定：

1. 開発工程での不具合発生は、適用する開発プロセス実施の妨げになる。
2. 適切に設計された開発プロセスならば、その通り実施すれば不具合は出ない (少ない) はずである。
3. 不具合が多発するのは、不具合を生み出す「やり方」の質をしていると考える。

判定基準：

各工程において出てしかるべき不具合と、予期しない不具合とが存在する。
それらの出方を識別することで、以下の判断を行う。

　▶前者は開発プロセスの検証規定自体の妥当性・十分性が示唆される。

　▶後者は開発プロセス実施の「やり方」の質に問題ありが示唆される。

改善アクション :

　▶適用する開発プロセスの弱点、実施の「やり方」の質など示唆される改善点に対するアクションを策定し、実施する。

　▶速やかに実施することで、以降の不具合(特に予期せぬ不具合)の低減が図れる。（不具合を抑制できる）

このような活動がもたらす改善効果により、円滑な開発プロセス進捗と品質検証に結び付くはずです。すなわち、真のプロセス評価（適用する開発プロセスの妥当性、的確性、充分性の評価））ができると考えられるのです。

ここまでが、ODC分析のコンセプトの概略です。

ここまで説明してきたコンセプトに基づいて手法化されたODC分析は、どういう使い方をするのか、そして何を示唆してくれるのか、という分析・評価の「やり方」について話を深めていきます。
まず、「不具合についての３つの気づき」から発案されたODC分析のコンセプトを基にODC分析の定義と目的、そして手法化に至るまでの思考のアプローチを整理してまとめておきます。

ODC分析の手法の定義と目的

　▶ODC分析は、ソフトウェア開発の「やり方」の「 質」 が「見える化」ができる不具合分析理論と手法です。

　▶ODC分析は、不具合低減 (Defect Control) のため、プロセス実施の「やり方」の「質」を改善することを目指します。

ODC分析の手法としてのアプローチ

　▶適用する開発プロセスの特性から不具合の出方を定量的に分析する手法です。

　▶定義した属性に基づいて不具合を分類し、可視化（グラフ化）することで開発プロセス実施の「やり方」を多角的な見方で分析を行います。

　▶適用する開発プロセスの持つ理論的不具合分布と実際の分布を比較することでその差異を評価します。
        ・「何かおかしい？」ことを気づかせてくれる。
        ・同時に、「何がおかしいか？」「どうするべきか？」を示唆してくれる。

　▶示唆される改善の必要性を具体化して改善策として実施します。
         ・改善策は、個々の不具合に対してではなく、
         ・不具合を生み出した開発プロセス実施の「やり方」の質を改善するためのものです。

こういったアプローチが、ODC分析の手法となります。
ここで登場した「理論的不具合分布」という言葉に戸惑われたかと思います。そこで次項では、これの説明を行います。

「理論的不具合分布」こそ、ODC分析・評価の観点と言えるものです。
ではどういうことを言っているのかを解説します。

 本連載の第2回で登場したV字プロセスモデルを基に開発プロセスについて捉え方をさらに掘り下げてみます。

Zoom

INCOSE SYSTEMS ENGINEERING HANDBOOK V.4 「A GUIDE FOR SYSTEM LIFE CYCLE PROCESS AND ACTIVITIES」より。著者による改編と日本語訳および加筆

注）V字プロセス・モデルは、プロセスの1つのモデルであって、開発プロセスそのものではない

V字プロセスモデルをベースに考えられた開発プロセスは、名称、用語はさまざまであっても、一般的に次の図１のような工程定義と工程目的、検証目的になっていると想定しています。

Zoom

さらに、前回（第4回）での ③プロセス実施の質と属性との関係の「気づき」でお話しした各工程で予想される（期待される）不具合をマップすると次の図２のようになります。

Zoom

そこから示唆される（出てしかるべき）タイプ属性をマップすると下図3になります。

Zoom

ここまで展開すると、はたと気付かれた方も多いと思います。
そうです、前回（第4回）で説明しました下図のタイプ属性分布の開発プロセス観点からの理論的裏付けになっているわけです。

Zoom

以上のように少し大掛かりに説明してきたのは、先に登場した「理論的不具合分布」すなわちODC分析の評価の観点をお話ししたかったからです。

つまりは、ここまでの開発プロセスの展開が示そうとしていることは、「開発プロセスと不具合との関係についての捉え方」であり、次の三つのことが言えます。

　▶検証の目的は、検証する各工程の目的と対応しているべきである。

　▶従って、検証作業の観点は、必然的に「工程作業内容が工程目的を達成しているかどうか？」という観点になる。

　▶従って、検証での指摘事項や不具合は、対象となる工程目的、作業内容に対応する（しかるべき）ものになるはずである。

 この一連の開発プロセス・モデルからの展開をまとめると下図４となります。

Zoom

 このことは、ある程度ソフトウェア開発経験のある方なら、感覚的、経験的に感じとられていることではないかと思います。
また、次のようなことを想定しながら検証作業をしているのではないでしょうか。

　▶基本設計レビューで要求機能が設計仕様の機能性と不足なくひも付いているか？

　▶機能テストのテストケースからここではこういうテストをしているから・・・

　▶システムテストで要求にある非機能要件はこういうテストをしているから・・

こういったことを「洞察 (Insight)する」とRam先生は言っています。
このように、想定、洞察されることの理論的裏付けが、上述してきたこととなります。

以上のことが、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)