ODC分析について書籍が出てることに気がつき即購入。
元論文はこちらから。
https://scholar.google.co.jp/scholar?cluster=4480059868650717347
最新の？ODCはこちらから。
https://researcher.watson.ibm.com/researcher/files/us-pasanth/ODC-5-2.pdf
「ソフトウェア開発の見える化」とは、分析過程から、以下の3つの発見に導くものである。
- 「何かがおかしい」と気づかせる。
- その「何か」が何であるかを示す。
- それに対して「何を」すればよいかを示唆する。
p. 5
私はdevelopmentとproductionの2つの側面からソフトウェアエンジニアリングを捉えているいるが、ここではproductionに対する示唆を考えたい。すなわち、上記3つの視点は「いいシステムアラート」が満たすべき特性と重なる。
また、不具合を分析することは健康診断で少量の血液サンプルから正確で重要な情報が得られることとと同じという指摘は非常に示唆に富む。
システムアラートとテストによる不具合報告の本質的な違いを考えてみたが、
- システムアラートはreal user monitoring
- テストによる不具合報告はsynthetic monitoring/real user simulation
であるというように分類ができそう。なお、私最近shift-left system
alertingという造語を提唱しているが、これはreal user monitoringをproduction以前で行うアクティビティのことを指している。
"Sacrificing quality is not effective as a means of control. Quality is not a control variable. Projects don’t go faster by accepting lower quality. They don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality standards often results in later, less predictable delivery."
via Check out this quote from Extreme Programming Explained: Embrace Change, Second Edition - https://learning.oreilly.com/library/view/extreme-programming-explained/0321278658/ch05.html
XPでも、進捗を妨げる主要因が低品質（不具合）であり、高品質にすることで進捗が速くなると主張している。
個々の不具合には、それぞれ生い立ちや素性があり個性があり、それらは独立した3つの側面とそれぞれに属する4つの相互依存性のない要素、要因で構成されていると考える。その1つひとつを明らかにすることで、その不具合の成り立ちが説明できる。
p. 13
深みのある一文である。側面のうち「影響」は結果なので多くの場合記録されていると思うが、「原因」・「環境」を記録できないことが多いのではないか。
ODC分析はプロダクト品質の評価手法であること以上にプロセス品質へのフィードバック手法であろうとすることへの強い意志を感じる。
工程ごとの不具合の出方を捉えることができれば、それに対応する工程ごとの開発プロセス実施の「質」すなわち不具合を生み出す「やり方」を推察することが可能であるという逆説的な気付きが、ODC分析の分析方法論の基礎となった。
p. 22
ここ、非常に重要な文だと思うのだが初見で何が「逆説的」なのかがわからなかったので、いくつか参考文献にあたってみる。
"SEC BOOKS 共通フレーム2013（電子版）: ～経営者、業務部門とともに取組む「使える」システムの実現～"（独立行政法人情報処理推進機構（IPA）, 独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC） 著）からのこの引用を読んであなたのことを思い出しました。
"品質保証の対象は，3つある。一つ目は成果物そのもの（プロダクト）を保証するもの，二つ目は仕事の仕方（プロセス）を保証するもの，三つ目が品質マネジメントシステム，つまり組織の品質を高める仕組みを保証するものである。"
こちらから無料で読み始められます:https://a.co/g46igSy
「共通フレーム2013」において品質保証の2つ目の対象として仕事の仕方（プロセス）が定義されている。
また、JISX25010が述べるように
- プロセス品質が内部特徴に影響し、
- 内部特徴が外部特徴に影響し、
- 外部特徴が利用時の品質に影響する
という共通の理解がある。
そもそもこの「品質は工程で作られる」という考えの源流はどこにあるのか。
品質保証は、歴史的に検査によって実施すること、検査体制を構築することから出発しました。
（…）
この検査による品質保証の不合理に気付き、工程能力を分析、向上させることで、工程を流れる全製品を良品とする研究に力を注ぎました。この考え方が、「品質は工程で作り込む」という日本式TQCの合言葉となっていきました。
（…）
やがてこの「品質は工程で作り込む」という製造部門の力だけでは、顧客ニーズに合致させるには限界があることが分かってきました。
（…）
源流管理では、大きく影響を与えることになる開発、設計工程で問題を出さないようにすることが効果的であるとして焦点が当てられるようになりました。
興味深い指摘である。引用によれば、歴史的には経験則に基づいてshift-leftがエンジニアリング業界全体として行われてきた。なお、ソフトウェア開発データが語るメッセージ「設計レビュー・要件定義強化のススメ」を公開 ～定量的データに基づくソフトウェア開発のプロセス改善を目指して～：IPA 独立行政法人 情報処理推進機構では、この経験則を定量的に証明している。
ここまで読んできて何が「逆説的」なのか私の理解をまとめると、
- プロダクトの品質がプロセスの品質に影響を受けることがわかってきた
- プロセスの品質を向上することでプロダクトの品質も向上することが分かってきた
- しかし、いかにしてプロセス品質を測定・向上することができるか（少なくとも当時）メソドロジーがなかった
- 調査の結果「逆説的」に、プロダクトの品質を向上するためにプロセスの品質を向上するためには、プロダクトの品質の負の結果である不具合を分析することでプロセスの各工程の品質を測定できることが分かった
うまくまとめられたか自信がないが、プロダクト→プロセス→プロダクトという循環が面白く、「逆説的」なのだと思う。
ODC分析では、不具合の要因として「間違えました！（Incorrect）」と「忘れてました…（Missing）」とでは意味論的に異なる要因の不具合と分類する。
p. 26
言われてみればその通りなのだが、タイプ属性の限定子（Qualifier）は腹落ちした。後で出てくるが、M/I比率の推移を追うだけでもかなり有効なプロセス品質の測定ができると考えられる。
以下、タイプ副属性についてコメント
- assignment: 代入にまつわる不具合と理解した。デフォルトnullが期待されるフィールドに、デフォルト0が代入される不具合を見たことがある
- checking: いわゆるboundary testingやC1カバレッジにより検出されそうな不具合と理解した。エッジケースなどと呼ばれることも
- algorithm: いわゆる「ロジック」と理解した
- timing/serialize: これはconcurrency anomaliesと理解した
- interface: オーバーロードされまくったメソッドの呼び間違えはこれなのだろうか
- function: algorithmとの違いがやや分かりづらいが要は機能まるごと
- bld/pkg/mrg: リリースにまつわる不具合
- documents: これはもうそのまま
以下、ソース属性についてもコメント
- reused-code
- rewritten-code
- refixed-code
- vendor-written
- old-function
- new-function
- scaffold-code
p. 39
まず上記8つのソース属性の副属性が列挙してあるのだが、参照先の元論分にもODC v5.2とも完全には一致しないので注釈の通り筆者による加筆によるものと思われる。私達は「デグレ」と読んでいるものはrefixedが該当する。
