はじめに

これまでQAエンジニアとして統計データを用いた不具合分析を実施してきましたが、根本的な原因の把握〜プロセス改善までに時間がかかるという課題感がありました。

テスト完了時では統計分析を、リリース後に障害として見つかった不具合に対してはポストモーテムに向けてRCA分析を行っていました。

ODC分析は「統計分析」と「原因分析」のちょうど中間に位置する分析手法にあたり、両者の良いとこどりのようなイメージだと理解しています。

ソフトウェア不具合改善手法 ODC分析工程の「質」を可視化する　杉崎眞弘・佐々木方規　著　を読んでみて、どのような背景でODC分析が誕生して、どのような考えを大切にしているのか、に触れていきます。

どんな人に読んでもらいたいか

PdMやPO、QAエンジニア
ゲートキーパー的なQAスタイルを継続している
開発を繰り返し進めている中で似たような不具合が毎回出つづける
統計分析の一歩先に進みたい方
RCA分析が大好きだけど時間がかかると思っている方

そもそも不具合分析に興味を持ったキッカケ

QAエンジニアとして品質と向き合う機会は多いですが、不具合が多いプロジェクトでは得てしてプロセスに問題があることが少なくないと思います。

サービス品質やプロダクトの品質を決めるのはプロセス品質であり、そのプロセスに問題が潜んでいれば、最終的な品質も下がるのが必然です。

プロセス品質の大切さについてはログラスさんの資料がわかりやすいので以下を参照ください
参考資料：品質富士山（ログラスさんの資料）

そりゃそうですよね
アスリートの世界でも、厳しい食事制限や過酷な日々のトレーニング、睡眠やメンタルケアを繰り返すことでファンを魅了するパフォーマンスを発揮できるわけですよね。

「サービス品質」や「プロダクト品質」も同じだと思います。
「開発の進め方」で「品質は決まる」と言っても過言ではないと思います。

ODC(Orthogonal Defect Classification)分析とは

不具合の「出方」を分析することで開発プロセスの「やり方の質」を改善していく分析手法です。

不具合(Defect) を3つの側面(Orthogonal)からなる 4つの属性に分類(Classification) し、個々の不具合の意味を定量的に捉え、開発の「やり方の質」を改善し不具合の再発防止に繋げることを目的としています。

その分析手法は 「DPP」と「プロセス・シグネチャー」 の考えに基づいています。

ODC分析の誕生

米IBM社で不具合を研究していた品質研究チームが不具合と開発プロセスの関係性の気付きから誕生しました。

実際のODC分析手法を生み出すまでの」「3つの気付き」は、

開発プロセスに関する気付き

上流工程の十分な設計・検証と不十分な設計・検証とでは、その後のテストで見つかる不具合の出方（質と量）に差が出る

不具合に関する気付き

不具合はプロセス品質の健全性を示す効果的なサンプル
不具合は互いに依存しない4つの属性（生い立ち・成り立ちなど）で分類できる
- 属性：タイプ / トリガー / ソース / インパクト
不具合はそれぞれ固有に発見されるが、その原因は固有でない

開発プロセスの質と不具合関係からの気付き

不具合には、出てしかるべき工程と出るべきでない工程がある

プロセス・シグネチャー

本書の中に「プロセス・シグネチャー」という言葉が登場します。
これは、正しいプロセスを実施していれば、**「しかるべき不具合」が「しかるべきときに出る」**という意味で用いられています。

例えば、機能漏れや機能の仕様誤りに分類されるような不具合はリリース間近で見つかるような不具合ではなく、このような不具合がリリース間近で見つかるということはプロセスに問題があったということが言えるようです。

至極当然のような話で、ゲーム（RPG）に置き換えてみるとわかりやすいかもしれません。
ゲーム序盤でラスボス級の敵が出現してもゲームバランス崩壊となり、そんなゲーム誰も買わないですよね。
この考えが「プロセス・シグネチャー」で「しかるべき時に出る」ということなのかと思います。

話は変わりますが、多くの方が未だに「テストは不具合を見つけるため」と思っています。
テストの目的としては、正しいです。

しかし、テストで不具合を見つけたと言うことの意味するところは不具合がテストまで漏れてきたと言うことです。
なぜ要件決めや設計、コーディング、ユニットテストの段階で不具合が発見できなかったのだろうか、テストより前工程の検証は機能しているのか、ということが言えます。
つまり、テスト工程で不具合が多発していたり、テスト工程終盤で見つかった不具合の質によっては、それまでのプロセスの何かがおかしいと言えることになりますね。

では一体どこでどんな不具合が見つかれば良いのでしょうか？

開発プロセスと「しかるべき不具合」の傾向

一例を挙げると、
システムテスト（以下、ST）を手動で実施するとなった場合、一般的にプロジェクトの終盤で実施される方が多いと思います。

V字モデルの開発工程とテスト工程を対比して見た時、STは要求仕様や要件定義における機能要件や非機能要件を満たしているかを検証するものになります。

つまり、STの段階で見つかる不具合の多くは「機能要件や非機能要件におけるユーザーの期待に対する満足度に関する不具合」を検出することが期待されるわけです。

STの段階で設定値や条件分岐、処理順、制御ミスに分類されるような、コーディング誤りに起因する不具合が見つかることはないに等しいわけです。

上図は、「しかるべきタイミング」で「しかるべき不具合がきちんと見つけられている」という定量グラフになり、テストで狙った不具合が検出できていることの裏付けにもなります。

「Function」に分類される不具合検出数がテスト終盤に向けて収束している
「Timing/Serialize」に分類される不具合がシステムテストにかけて多く検出されている
「機能テスト」では「Interface」に関連する不具合が突出している

DPP(Defect Prevention Process)

本書から引用

愚行とは、同じこと(同じ不具合)を何度も繰り返しながら、システムが正しい振る舞いを返すことを期待していることである

DPPとは、不具合の再発防止を開発プロセスの「やり方の質」に求めて、組織やチームとして「やり方の質」を改善していくための「不具合再発防止プロセス」です。

DPPの目的は、一度起こした不具合は、二度と繰り返さないようにすることです。
そのためには実際に起きた不具合を分析して、原因となる開発プロセスの「やり方の質」に修正・改善をかけることが必要です。

一見当たり前のように聞こえますが、このプロセスが現実では怠りがちになります。
その理由は、間違った考え方を持つ組織やチームが多いということにあります。

「起きてしまった背景や経緯に時間をかけるより、不具合を直すことが大事」という考え方
不具合の原因は時間的制約・個人の経験やスキル要素が多分にあり、普遍的な解決策などないという盲信
リリース後の不具合は専門の組織やチームに任せて、次の開発に専念することの方がプライオリティが高いという考え方

さいごに

プロジェクトを通して、不具合が収束しなかったり、毎回同じ不具合を見かけたり、致命的な不具合がリリース後頻繁に見つかる原因は、往々にしてプロセスに問題があると思います。

人は必ずミスをします。ミスをする前提のもと、仕組みで解決しなければ根本的な原因解決は難しいと考えます。
この仕組みをODC分析を通じて「改善ポイント」として見つけ出し、「しかるべき不具合」を「しかるべきタイミング」で見つけることは、開発プロセスの健全化と言えるのではないでしょうか？

不具合を資産として活用し、不具合分析から得られた再発防止に繋がる改善策をチームや開発プロセスにフィードバックしていくことはQAエンジニアにしかできない業務の一つと言えるかもしれません。

出典

ソフトウェア不具合改善手法 ODC分析工程の「質」を可視化する
日科技連ODC分析研究会　編
杉崎眞弘・佐々木方規　著