【連載】ODC分析についてのよもやま話〜ソフトウェア不具合についてのあれやこれや・・・〜第1回：ソフトウェア開発の見える化とは？

読者のみなさん、はじめまして。
この度本誌コラムの連載を開始します杉崎眞弘です。

 私は、長年日本アイ・ビー・エム株式会社（以下、IBM）の研究開発部門で製品開発の業務に従事してきました。特にそのキャリアで長かったのが品質保証業務で、中小型システム、P C (THINKPAD)、組み込みシステムのOSやシステムソフトウェアの品質保証を担当する部門長を歴任してきました。

そのキャリアを通じて学び取ってきたことの一つに、ソフトウェア品質は個々の技術者のスキル・知識以上にその組織の開発の「やり方」が正しかったか否か、理にかなっていたかどうかに多分に依存していると考えるに至ったことです。言い換えると、製品品質はその開発組織でこそ改善し向上させることができるということです。

本コラムの主題であるODC分析は、まさにその開発の「やり方」の良しあしを可視化でき、示唆される改善すべき点を実際の改善に結び付けるための不具合分析手法です。

ここで、なぜ私がODC分析の話をしているかというところに触れておきます。

かつて、IBMがソフトウェアの不具合に本気で取り組み出した80年代後半から90年代前半にかけて、当時IBMの基礎研究部門であるワトソン研究所でソフトウェア品質を研究していたDr. Ram Chillaregeと彼の研究グループが、社内の膨大な不具合を分析した中から発案したODC分析の萌芽に端を発します。その発案を社内分析手法の一つとして確立すべく社内タスクが発足し、日本の研究所から私が参加し、くだんの大先生からODC分析のコンセプトとそこから導かれる開発の「やり方」の見極め方までみっちりと直伝されました。帰国後は日本の研究所内への展開に取り組み、実績を積んできました。そうした経緯から後年もっと広く多くの技術者の方々にも、このODC分析の有効性、有用性を知っていただきたく、研究会、セミナー、書籍を通じて普及振興に務めている次第です。

この辺りの私とODC分析の関わりは連載の中でも都度紹介していきたいと思います。

さて、本題に入る前に何よりお伝えしておかなくてはならないことは、タイトルにある「ODC分析のよもやま話」の「よもやま話」とはどういう類いの話かというところです。

長年ODC分析の実施支援や普及に携わってきて感じているのは、確かにODC分析はソフトウェア開発の「やり方」改善に実績のある優れた不具合分析手法であるいうことです。

と同時に思うのは、ODC分析を有効に使うにはその背景にある不具合についての捉え方と、それを裏付ける開発プロセス理論の実践的理解が必要不可欠であることが事実だということです。

その辺りが初学者の方々の始めの一歩や、自己流で始められて行き詰まっている方々の障壁になっているのではないかと常々ODC分析研究会での事例研究からも感じています。

その課題を解くヒントとして、これまで書籍やセミナーでは言い尽くせていないODC分析にまつわる不具合についての味わい方、開発プロセスの志の再認識、さらにソフトウェア品質についての考え方や捉え方にまで話を広げて、あれやこれや「よもやま話」としてお伝えしていきたいと考えています。

この書き物が、ODC分析に興味のある方のみならず、ソフトウェア開発に携わる方々にとって日々の業務改善のお役に立てれば幸いです。

では早速話を始めます。

まずは、こんな事例から・・・

ソフトウェアの開発現場において、「ソフトウェアができました」という言葉をよく耳にします。では「ソフトウェアができました」とはどういうことを言っているのでしょうか？

おおよそ返ってくる言葉は、「テストでバグが出なくなりました。」ということではないでしょうか？もう少し報告調にいうと；

• 設計した仕様は全て実装できていることを確認し
• テストケースも全て実行を完了し
• 摘出した不具合も全て修正を完了しました

と、いうようなところではないでしょうか。

その根拠としてよく用いられるのが、下図１のような摘出した不具合数の累計を時系列にプロットしたグラフだと思います。

（実際は、こんなきれいな遅れS字カーブにはなかなかなりませんが・・・）

このグラフ、「信頼度成長曲線」と呼ばれています。信頼性が成長していることを示しているかどうかはともかくとして、示しているのは、時系列に見て一定期間内の不具合の摘出数が減少してきているということです。俗にいう「寝てきて」いるので、もうそろそろプロジェクトを完了してもいいのではと思えてくるところです。

確かに私たちは、仕事としてビジネスとしてソフトウェア開発業務を行っているのですから、ある判定基準、完了基準を持って仕事に臨み、その基準を満たせば組織として完了と判断するのは妥当な事と言えます。

しかしながら、この一面的なグラフの傾向を見て出荷可能と判断したが、市場に出た結果「あれ〜」ということが起こってしまったという経験は少なからずどなたにもあるのではないでしょうか。

前述の事例で、システムテストも終盤になり累積不具合数も「寝てきた」状態ながら、次のようなことが分かったら、どうでしょうか？

ODC分析の片りんに触れてみます。

工程を通じて摘出された不具合を、次の四つの種類に分類し、各工程単位で摘出された不具合中でそれぞれの種類が占める割合(%)で示すと下図（図２）のようになりました。

分類した不具合の四つの種類は、次の通り。

• 機能性に関わる不具合
• 初期化や値設定に関わる不具合
• 条件分岐に関わる不具合
• インターフェースに関わる不具合

さて、みなさんはこの図２のグラフを見て、どう感じますか？

見えている事象：

前出の累積不具合数のグラフ（図１）では、摘出される不具合数は減少傾向にあり、ソフトウェアの出来具合が安定してきているように見えています。

見えていなかった事象：

しかし、摘出されている不具合を種類ごとに分類して、工程ごとに各種類の不具合の割合を示してみると図２のようになりました。

「何かおかしい・・・」ですよね？

「何がおかしいか？」を考えてみましょう。

着目すべき点：機能性に関わる不具合の割合が、依然増加傾向にある

と、いうところです。

機能性に関わる不具合の割合が、減少傾向にある他種類の割合の変化と異なり、工程が進むにつれて相対的に継続して増加傾向を示しています。（図２の赤の矢印が示す通り）

つまり、「見えていなかった事象」として、

• 機能性に関する不具合は相対的に増加傾向にある

  さらに、今後も出続ける可能性を示している

と、いう事です。

なぜそう言えるのか？

機能性に関わる不具合は、設計レビュー、コード検証、単体テスト、機能テストの実施により、既に摘出されている(はず) なのではないでしょうか？

しかし、図２が示す通り、開発前半での機能性の不具合の割合が他と比べて特に多くはないことから、次のようなことが示唆されます。

• 開発前半工程での機能性の検証が十分ではなかったのではないか？

  よって、機能性の不具合が後工程へ残存し、単体テスト、機能テストで摘出しきれず、システムテストにおいて依然摘出され続けている

そのことがなぜ問題なのか？

• 現在進行中のシステムテストにおいて、残存している機能性の不具合対応により、

  システムテスト実施がしばしば妨げられ、十分なシステムテストになっていないのではないかと捉えられるため

以上の考察から、この状態で出荷すると次のリスクがあることが示唆される。

• 機能性の残存不具合が市場に漏れてしまう
• 機能性の残存不具合への対応により、システムテストの実施が度々阻害され、十分なシステム検証がなされていないことが想定され、さらに重大なシステム障害を起こす可能性がある

このように、これまで見えていなかった事象をもっと早い段階で知ることができれば、早計な出荷判断に至らずに済むことは、理解いただけると思います。

では、どうすべきだったのでしょうか？

この事例では、システムテストも終盤に差しかかっている時期にこのようなことが分かること自体が大きな問題です。いささか時期が遅過ぎるわけです。

ではもっと早い段階であったなら、またタイムリーに前述で示唆されていることが知れたなら、いくらでも対応策が打てたのではないでしょうか。例えば、

• 設計レビューやコード検証での機能性に限らずレビュー観点の見直しと再検証の実施

  ＞レビューの観点に偏りはなかったか再検証する

  ＞レビューアに幅広い知識を有するメンバーが参加する

  ＞レビューでの指摘事項に対する対応を確実に管理する

• 単体テスト・機能テストでの、機能性に限らず検証観点、テスト項目・カバレッジの要求仕様とのひも付けなどの見直しと再実行

などが期待したいところです。

こうなる前に考えるべきこと

ここまでの「よくある判断基準」の事例から言えることは、

• 表面的な不具合摘出の累積数による統計的分析だけでは見えないソフトウェア開発の内実を知るには、別の見方が必要
• ソフトウェアの出来具合や完成度合いは、設計・コード・テスト作業の「やり方」の質を評価できるようにしておくことが必要

そうしたことを把握・評価できるようにしておくためには、効果的な「ソフトウェア開発の見える化」の方法論・計測方法が必要となります。

「見える化」とは

「見える化」とは、見えていないものを見えるようにすることです。

さらに、「見えてきたこと」が何を意味するのか？　が理解できるようにすることがもっと大事です。

「ソフトウェア開発の見える化」には、以下の三つのことが求められます。

1. まず、「何かおかしい？」を気付かせる
2. さらに、そのおかしい「何か？」が、「何が！」であるかを示す
3. そして「何を？」すべきかの示唆が得られる

参考文献*1) には、次のような一文があります。

「不具合は、プロセスと品質の健全性を示す効果的な診断サンプルである」*1

このことは、健康診断での血液検査と似ていると説明しています。少量の血液サンプルを採取して分析すると、その人間のさまざまな健康に関する正確で重要な情報が分かります。

例えば、現在の健康状態、症状の危険度合い、さらには改善すべきライフスタイルなどまで指摘できます。

「不具合を分析すること」はそのことと似ていて、次のような情報が提供される可能性があると述べています。

• ソフトウェア品質の成熟度合いが分かる
• ソフトウェアの特性とその複雑さを示すさまざまな要素が抽出できる
• 開発プロセスの能力を捉え、そしてその有効性が評価できる

そう言われると、不具合分析の可能性について考えを深めていきたくなってきませんか？

不具合分析についての考え方

不具合についての捉え方と不具合分析の想定として、次が挙げられます。

• 不具合は、それぞれ固有に発見されるが、その原因は固有ではない
• 分析が遅れれば遅れるほど(工程が進むほど)、真の原因を見い出すのが難しくなる
•  不具合の件数が多い場合、その分析方法は単純であることが必要である

既存の不具合分析と異なるODC分析のアプローチ

既存の不具合分析手法として、二つの分析手法が知られています。

根本原因分析（RCA: Root Cause Analysis)

• RCAは不具合を埋め込んだ個々人による分析が基本
• 不具合に対しての、多くの詳細な情報が必要
• 分析には多くの作業時間を要する
• 組織単位で実施され、組織ごとの改善につながる
• 不具合の根本原因を深く明らかにして是正案を考える

この手法は、同じ不具合の再発防止には強力な分析方法です

統計的分析（信頼度成長曲線あるいはゴンペルツ曲線）

• 評価するには、測定対象となる要素の予想が必要となる。（不具合の時系列予測）
• 曲線の描く傾向に焦点を当てる
• 不具合の意味論や技術詳細が重点ではない
• ブラックボックス的な分析方法

この手法は、進捗や状態推移の分析には優れています。

ただし、不具合に隠された意味的なものは、分析には現れにくいです。

ODC分析のアプローチ

• ODC分析は、ソフトウェア開発の「やり方」の質が「見える化」できる不具合分析理論と手法
• ODC分析は、不具合低減のため、プロセス実施の「やり方」の質を改善することを目指す

ODC分析の特徴

• 適用する開発プロセスの特性から不具合の出方を定量的に分析する手法
• 定義した属性を元に、不具合を分類して、多角的な見方で分析を行う
• 適用する開発プロセスの持つ理論的不具合分布と実際の分布を比較することで、

  ＞「何かおかしい？」ことを気付かせてくれる

  ＞同時に、「何がおかしいか？」「どうするべきか？」を示唆してくれる

• 示唆される改善の必要性を具体化することで改善策として実施可能

  改善策は、個々の不具合に対してではなく、

  不具合を生み出した開発プロセス実施の「やり方」の質を改善するためのもの

ODC分析の位置付けは、次の図３のように表せます。*1）

図３では、ODC分析の位置付けは統計的分析とRCAとの中間に位置することを示しています。

さらにODC分析の志は、

ODC分析とは（一言で言うと）

工程実施の妨げとなる不具合を低減するために(Defect control)

不具合の出方を分析することで

工程実施の「やり方」の質が見える化でき（しかも定量的に）

必要なアクションが示唆される

ソフトウェア不具合の定量的分析手法である。

と言えます。

ここまで、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
https://ieeexplore.ieee.org/document/177364

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