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

前回冒頭で、なぜ筆者の私がODC分析にまつわる話をしているのかというところに触れましたが、そもそものODC分析の生い立ちについてもう少し話を続けます。

ODC分析の生い立ち

ODC分析は、米国IBMの基礎研究部門であるワトソン研究所(IBM Thomas J. Watson Research Center, NY)で長年ソフトウェア品質の研究をしていたDr. Ram Chillaregeと彼の研究グループが1992年IEEEに発表した次の論文にその端を発します。

論文タイトルは、
Orthogonal Defect Classification – A concept for In-process Measurement*1)

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

この論文で述べられている

• 不具合についての３つの気づきとその分析から開発プロセス実施の「やり方」改善への示唆の可能性について

これこそが、ODC分析の原典であり、私のODC分析との関わりの原点です。
80年代後半、IBM社内ではPCの誕生以来ソフトウェアが汎用化し複雑化・巨大化してきて、それに伴い多発するソフトウェア不具合が大きな課題となっていました。そうした中、これまでとは異なるアプローチで不具合を分析することで開発プロセス品質が改善できる可能性を論じたこの論文をもとに手法化しようというタスクが立ち上がり、Ram先生から各国IBMのソフトウェア開発部門に招集がかかり、日本IBMから私が参加しました。

この先生のクラスでは、ODC分析のコンセプトに始まり分析から示唆される開発の「やり方」の見極め方、さらにそれをどう改善にどう結び付けていくかといった事例に基づいた実践的技術の直伝を受け、手法が確立されました。
同時にクラス全員が社内講師の任を受け、習得したODC分析手法を自組織内への展開に励み、長年社内プロジェクトでの適用実績を積み重ねてきました。

ODC分析その後の展開

後年、このODC分析をIBM社内のみならず社外のお客様にも展開することとなり、Ram先生自身、公開情報としてNASAの飛行システム・シミュレータ開発やAT&T（ベル研究所）の開発システムなどにODC分析の適用を指導されました。私自身も同時期に研究所発の開発技術コンサルティング事業部門を立ち上げたばかりで、どのようなソリューションを持ってコンサルティング活動を展開するかを考えていた時期でした。

最初のステップとして「開発現状分析と課題抽出」と銘打って、お客様の開発現状を可視化し分析して、開発課題を抽出するための方法論としてODC分析を適用することを思い付きました。

このアプローチにより、開発プロセス実施の「やり方」の妥当性、プロジェクトマネジメント技法、設計技術に関する課題を的確に抽出することができ、次なるソリューションの効果的な提供・展開へとつなげることができました。

私のコンサルティング事業部の事業領域は、主に国内製造業の電機、重工業、デジタル複写機、車載機器、携帯電話機などのお客様でしたが、このアプローチを持って結構なビジネス貢献ができました。

しかしながら、この優れた実績ある分析手法であるODC分析について、IBMはついぞ書籍を残してきませんでした。このため新たにODC分析を学ぼうにも学ぶべき教科書、教育の場がないため、仕方なく断片的で信ぴょう性に欠けるWebの情報から自己流に始めて見たものの、挫折してしまった方が多かったのではないでしょうか。

この「知る人ぞ知る」手法からの脱却を図るため、情報処理推進機構 (IPA)で知り合った佐々木方規氏を委員長として、2017年に日本科学技術連盟にてODC分析研究会を設立しました。
これまで多くの方々の参加を得て、本年度第7期の活動が続いています。

さらに、これまで書き物がなく話だけで語られてきたODC分析では、共通認識に欠けることから、また発案者のRam先生から直伝を受けた私自身の責務として、2020年に初のODC分析の解説書*2)を出版しました。

これに合わせてODC分析の普及振興活動の一環として、解説書の内容をベースにした日科技連主催の「ODC分析の基礎セミナー」を2021年の開講以来その講師を務めており、現在まで年2回、通算８回開催(本稿執筆時点)しました。

ここまでODC分析の生い立ちと展開についてお話ししてきました。

では、いよいよODC分析の中身に入っていきます。

前節で紹介しましたODC分析の原典となる論文；

Orthogonal Defect Classification – A concept for In-process Measurement*1)

には、膨大なソフトウェア不具合を分析してきたRam先生と彼の研究グループの成果として、ODC分析発案の動機となった「ソフトウェア不具合についての３つの気づき」が述べられています。

今更ながら、この「気づき」こそソフトウェア品質評価の根源的な洞察であると感じ入っています。

「ソフトウェア不具合についての３つの気づき」とは

「ソフトウェア不具合についての３つの気づき」とは次の観点での「気づき」を指します。

1. 開発プロセスの観点
2. 不具合の持つ属性の観点
3. プロセス実施の質と属性との関係

それぞれでの「気づき」についてお話ししていきます。

その前に、ここでいう開発プロセスについて共通認識を図りたいと思います。
開発プロセスの定義は、各企業目的に沿って適用する開発対象の特徴、開発形態などを反映してさまざまなものが世の中には存在するであろうことは、承知の事実です。
ことソフトウェア開発という観点から見たとき、使われる用語、固有名詞は異なっても、「ソフトウェアを作る」という目的において、その「やるべき」手順は同じであると考えます。

要求書からすぐにコードは書けないし、コードがあってもいきなりストレス・テストをする人はいないはずです。

つまり、ソフトウェア開発は段階を踏んで思考を深めていき、作るべきものを段階ごとに明確にしながら、大枠から詳細へと詰めいく「やり方」が共通であろうと考えます。

検証については、逆に小さい対象から始めて、大きい組み合わせ、全体へと検証対象を広げていくのが一般的であろうと考えます。

こうしたことから、ここでは開発プロセスの共通理解を図るため、V字プロセスモデル(図2)を使って話を進めていきます。

ソフトウェア開発プロセスモデル（V字プロセスモデル）*3

ここで注意していただきたいのは、開発プロセスモデル（V字プロセスモデル）は、あくまで開発プロセスの一つのモデルであって、開発プロセスそのものではない、ということです。読者の方々はご理解いただけていると思いますが、以前私がお会いしたお客様で、「貴社の開発プロセスを見せてください」と尋ねたら、「うちはV字モデルでやっています」と胸を張られ閉口したことがありました。

V字プロセスモデルについては、ソフトウェア開発において要求を満たすソフトウェアを開発するのに必要な多くのことが語られていますが、詳しくはまたの機会にしたいと思います。ここでは、ソフトウェア開発の基本的な工程定義としてV字プロセスモデルの工程定義を用いて話を進めます。

話を戻し、ODC分析発案の動機となった「不具合についての３つの気づき」の話を続けます。

①開発プロセスの観点

一つ目の「気づき」は、開発プロセス実施の「やり方」の質と不具合の出方の関係についてです。

同じ開発プロセスを適用しても、その実施の「質」、すなわち実施の「やり方」の差によって、不具合の出方は変化し、やがては最終品質に影響していくという「気づき」です。

そのことは図3のように示されています。

この図が示すことは、

• 開発プロセスの進行は、図の上から下に工程を経て進んでいきます。
• ここでの工程は大きく「設計」「機能テスト」「システムテスト」に分けて観察しています。
• それぞれの工程で発見された不具合を、概して多い(H)場合、少ない(L)場合に分けると、各工程を経て最終的に最下段の八つの結果のどれかにたどり着く、ということを示しています。
  ここで不具合の「多い(H)」「少ない(L)」の判定は、組織内での類似プロジェクト、あるいは前バージョンの開発時と比較して捉えます。

この図が何を言わんとしているかというと、
例えば、

• 図中①の場合、設計レビューで指摘は少なく、機能テスト・システムテストでも不具合が少なかった場合、「良い設計」ができていたと判断できます。

• 図中②の場合は、途中まで不具合が少なく順調に見えたが、システムテストで思わぬ不具合の山ができたしまったことを示しています。
  システムレベルの要求を設計につなげる際の検証漏れがあると判断できます。
  理由は、次の二つが考えられます。

  
  1） 要求分析で、システムレベルでの大きな要求の見落としがあり、設計から漏れて、そのまま検証対象にならず工程が進んでしまった場合。

  この場合、重大なシステム不具合が含まれることが多々あります。

  2) 設計レビューから機能テストまでの検証カバレージが不足あるいは欠落していて、十分な検証がされないままシステムテストに漏れて発見された場合。

  この場合、漏れてきた不具合修正に追われ、本来のシステムテストの実施がかなり阻害されていると推察できます。

  このように、本来のシステムテストが十分に実施されないまま出荷されてしまうと、重大なシステム不具合を起こすリスクをはらんでいることが懸念されます。

  このことは、開発遅れからテスト期間が逼迫したような場合によく起こる「なし崩し開発」になってしまい、結果的に不具合が多発し、再設計、再テストなどで想定外なスケジュール遅延を起こしてしまう、ということが実際よくあります。

  だからこそ、この場合いったん立ち止まって、要求と設計間の再検証、および機能テストのカバレージの見直しと再実施という大英断が必要となることを示唆しています。

• 途中工程でのリカバリーが効いた場合が図中⑤、⑦のケースです。
  この両ケースは途中工程で不具合が多発したが、対応策として設計を見直したことが功を奏して（良い設計修正ができた）、以降の工程での不具合発生が低減しています。

• 逆に途中見直しもなくテスト工程を推し進めていったケースが図中④、⑧です。

  この両ケースは、結果どこまでいっても不具合が収束しなかったため、スケジュール遅延、コストオーバーランを起こしたプロジェクトと言えます。

  この両ケースに言えることは、テストを実施以前の設計レベルであることに気づけなかったのか、あるいはテストで修正すればなんとかなると安易な進め方をしていたと考えられます。

このように、社内の膨大なプロジェクトデータをもとに、うまくいったプロジェクト、失敗したプロジェクトを分析した結果として導き出された図3が示すことは、結果論的ではありますが、

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

ということです。

また、ODC分析での不具合に対する見方として、

• 不具合は少ない程、開発プロセス通りの開発活動がなされている。
• 不具合が多発しているのは「何かおかしい」ことを行っている。

と、考えます。
以上のことから、

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

という結果論的な「気づき」が、ODC分析の分析評価論の基礎となっています。

「テストで不具合は少ないほど良い」という考え方について

ここまで「テストで不具合は少ないほど良い」と結論づけてきましたが、このことに疑問を持つ方も少なくないと思い、次のようなテスト不具合についての考えをお話ししておきます。

この疑問の背景には、いつの頃からか「ソフトウェア開発に不具合は付きもの」とい考えが支配的になって久しく、その言い訳が「人間がやることだから」というところでしょうか。

そのことから逆に、不具合の摘出が少ないまま済んでしまうと「テスト大丈夫？」と不安に感じられるのではないでしょうか。

テストで不具合を見つけて修正していくこと自体は、品質を検証する上で必要なことではあります。とはいえ、不具合の山を片付けて「あ〜これで品質が良くなった」と悦にいってる時代遅れな人などもういないとは思います。ここでもう一歩、「なぜそんなに不具合が出たか」を反省すべきでしょう。

なぜなら、テスト工程に至る前までには設計レビュー、コードインスペクションなど開発上流での検証作業をしてきたはずだからです。そこに想いをはせていただきたいのです。

ソフトウェア工学的にいうと（筆者による要約）、

• テストは、仕様通りの動き、振る舞いをすることを検証すること（Verification）

さらにシステムテストでは、

• ユーザー要求を満たす妥当な設計・実装になっていることを検証する（Validation）

とあります。

つまり、要求品質を満たす設計仕様通りになっていることを検証することがテストであり、テストでは、その仕様通りに動き、振る舞うことを想定しているわけです。
なぜなら前述の通り、要求分析、設計レビュー、コードインスペクションという設計上流での検証作業があり、要求を満たす十分な設計がされていることが確認されているという前提のもとでテストを実施している（はず）と考えるからです。

このことから、

• 「テストで不具合が出る」=「開発上流での検証の「やり方」に問題あり」

ということを示唆しています。
それ故「上流で見落とした不具合がテスト工程に漏れてきている」と言えるわけです。

一方、「テストは不具合を見つけるため」という考えを否定はしませんが、それは工学的テスト本来の目的ではない、ということを上述からご理解いただきたいと思います。

かつて私も先輩から「不具合は、見つける気になってテストしないと見つからないぞ」と教えられました。それはそれで「テストで不具合は少ないほど良い」ということと並行して、経験則として今でも生きていると思います。

以上のことから、「テストで不具合は少ないほど良い」と言いましたが、あえて言い直すと、

• 「テストで不具合は少ないほど良い設計」

と言える、となります。

さらに蛇足ながら、「動くかどうか分からないけど、ともかくテストしてみよう」という場面もなくはないです。しかしながらそれはテストではなく「実験」と呼ばれるものです。

ここまで、一つ目の「気づき」である「開発プロセスの観点」についてお話ししてきました。

次回は、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)