「ソフトウェア不具合改善手法ODC分析」読書メモ

こんにちは。Azukaritai の村穂です。
最近、積読となっていたODC分析の本を読み進める機運が高まってきたため今回読み進めていこうと思います。1章ずつ学んだことを note にまとめていくことをめざします。

ソフトウェア不具合改善手法 ODC分析

1章　ソフトウェア開発の見える化について

この章では、ソフトウェア開発という活動の実態が見えていないまま開発現場で様々な判断をしているのではないか？という問題提起と、ODC分析の他の分析手法との違いの説明が主な内容となっていました。

リリース判断の基準として「計画したやるべきことはすべてやった。」「見つけた不具合は全て直した」「テストでの不具合は出なくなった」などを設けている現場があると思います。しかしこれらの基準を満たしてリリースを行ったとしても不具合が流出してしまうことがあります。その際、設けた基準の「質」を検証すべきではないかと本書では書かれています。

たとえば、見つかった不具合がすべて修正され、リリースの判断が下りたプロダクトがあるとします。しかし「コーディング」「単体テスト」「機能テスト」「システムテスト」の各フェーズごとの検出不具合件数を見ると「システムテスト」だけが多くの不具合を検出し、それ以外の工程では不具合をほとんど検出できていないことがわかりました。

この場合、本来「コーディング」「単体テスト」「機能テスト」で検出すべきだった機能性の不具合の検出に「システムテスト」の工数が使われてしまい、本来「システムテスト」で検出したかった機能性よりも高次の要求に対する不具合を十分に検出できない状態になっている可能性があります。
また「コーディング」「単体テスト」「機能テスト」が十分に不具合を検出できていないことから、機能性の不具合がまだ多く現存している可能性も考えられます。

このように設定した基準（今回の場合は「不具合がすべて修正されている」）だけでなく、その基準の中について分析してみると、実は懸念すべき事項があることが見つかります。

不具合は「プロセスと品質の健全性を示す効果的な診断サンプルである」と本書には書かれています。先ほどの例のように、見つかった不具合をよく調べてみることで、プロセスの問題を見つけることができます。

そういった不具合分析の手法は大別すると、1つの不具合を深堀する「原因分析」と、複数の不具合の傾向などを見る「統計的分析」に分けられます。

本書曰く、ODC分析は、それらの中間に位置する分析手法のようです。

ODC分析は、プロセスの論理的不具合分布と実際の不具合の分布を比較することでプロセスのおかしい点に気づかせるという手法です。

原因分析で得た気づきは、不具合の解消に直接利用できます。
統計的分析で得た気づきは、不具合の解消に直接利用はできませんが、それを考える上で必要な示唆を得ることができます。
ODC分析で得た気づきは、不具合を生んだプロセスを改善するために必要な示唆を得ることができます。

以上のような違いがそれぞれあるようです。

1章の感想

プロセスの質とは何なのか、イマイチ理解できていない感覚があります。
プロセスの質といわれても、ピンとこないというか、具体的に何を指しているのか正直よくわからなかったです…。

また、ソフトウェア開発の見える化とありますが、ソフトウェア開発が指しているものも、よくわかりませんでした…。

ただ、著者の言おうとしている課題感やODC分析の価値に関してはイメージできたような気がします。

引き続き読み進めようと思います。