「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアというものがあるという前提で、従来から研究されている信頼度成長曲線の理論を適用した論文が非常に面白い。
もし、この論文の指摘内容が実際のソフトウェア開発の現場に適用できるならば、そんなソフトウェアはアジャイル開発こそ向いている、と言えるし、アジャイル開発の有効性の範囲が特に最近は広がっている、という事実を補強できるのではないか、と思う。
ちなみに、この論文は@sakaba37さんから教えてもらった。

以下は、浅はかな理解の元でのラフなメモ書き。

【参考】
ソフトウェア・シンポジウム 2018 表彰論文

ソフトウェア・シンポジウム 2018 最優秀論文賞 [研究論文]バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察

【１】研究論文の内容は、正直難しいです。
僕も細かな内容は分かってない。
しかし、言わんとする内容は、とても刺激的。

【２】従来のWF型ソフトウェア開発では、「バグ発見時間が遅いほど、バグ修正時間も長くなる」という前提で、いかにバグを早く発見して修正するか、さらに、バグを作り込まないように予防対策を行うか、という考え方が主流だった。

この発想は、製造業の源流管理ともマッチするので、日本のWF型開発では、上流工程や超上流工程でいかにバグを作り込まないように、漏れなく高品質なものを作って後工程に流すことばかり、考えるように仕向けられていた。

つまり、「バグ発見時間が遅いほど、バグ修正時間も長くなる」は正の相関関係を意味している。

【２－１】しかし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが存在するとしたら、どうなるのか？

もし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが世の中の大半を占めていたとしたら、今までの品質予防の対策ノウハウは無意味になるのではないか？
むしろ、バグなんか気にせずにいち早く作ってリリースして、ユーザの反応を見ながら修正していく方が効率的ではないのか？

つまり、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアとは、アジャイル開発が適用できるソフトウェアと同一視できるならば、ソフトウェア開発はアジャイル開発に特化してしまえばいいのではないか？

すなわち、「バグ発見時間が遅いほど、バグ修正時間が短くなる」は負の相関関係を意味している。

【３】この論文では、信頼度成長曲線という古典的理論を使って、「修正時間を考慮した最適リリース問題」として置き直して、モデル上で理論的な計算を行っている。
確率分布を使った計算なので、細かい内容はきちんと追わないと理解したとは言えないので、僕はすぐには分かってないが、下記の結果は理解できた。

【３－１】「バグ発見時間とバグ修正時間の相関関係」について、いくつかの前提をおいた上で、モデル上で計算を行った結果は、４ページの「表 1. 最適リリース時刻と最小総期待費用」で説明されている。

ここで、α：相関関数なので、
α＝＋１：完全な正の相関
α＝－１：完全な負の相関
になる。

また、総期待費用 C(T) 、最小総期待費用 C(T*)である。

その結果、αが＋１に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が増えていくので、「バグを放置していたら、修正コストは増えていくよ」というメッセージなのだと常識的に理解できる。

一方、αが０から－１に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が小さくなっている。
つまり、このモデルでは、「バグを故意に放置した方が、修正コストは最小になるよ」というメッセージを伝えている。
これは、従来のWF型開発における品質の源流管理という常識とは異なる結果だ。

【３－３】この結果は、反常識的で面白いが、「バグ発見時間とバグ修正時間の相関関係」の観点で読み直せば、ストーリーはよく分かる。
つまり、従来の源流管理重視の品質管理では、「バグ発見時間とバグ修正時間は正の相関関係」の前提で語っていたけれど、それはWF型開発しか頭にない人がそういう前提で語っているだけ、とみなせる。
「負の相関関係」の前提となるソフトウェアもあるのではないか？

常識で考えると「バグ発見時間とバグ修正時間は負の相関関係にある」ソフトウェアはすごく変だ。
なぜなら、バグを放置した方がバグを速く直せる、と言っているのだから。

しかし、MTBFを高めることに注力するよりも、MTTRを短くする方に注力するソフトウェア開発プロセスがあるように、「負の相関関係」の前提となるソフトウェアもあるはずだ。
たぶん、そのようなソフトウェアはアジャイル開発に向いているソフトウェアなのだろう。

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

実際、昨今のWebサービス開発では、いち早くリリースして、頻繁にリリースしながら品質向上していく開発プロセスが主流だ。
何年もかけて品質を作り込んで、ドカンと一発リリースするソフトウェアとは全く違う。

もちろん、そういうコストを掛けて品質を高く保つソフトウェアもあるし、従来はそういうソフトウェアばかりだったように思う。
今でも、航空宇宙や組込みソフトウェア、業務システムはそういう部類に属するだろう。

しかし、従来は周辺的な位置付けに過ぎなかったWebサービスのマーケットが広がり、皆が２４時間スマホを触っているのが普通な現代では、アジャイル開発に向いているソフトウェアが多くなった。

とすれば、アジャイル開発に向いているソフトウェアでは、「バグ発見時間とバグ修正時間は負の相関関係にある」という事実と表裏一体なのではないか。

【４】但し、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張は、僕個人の意見に過ぎない。
上記の研究論文でも、そこまで触れられてはいない。
しかし、上記の研究論文では、理論上そういうソフトウェアが存在する前提で、モデルから何が言えるのか、を示唆している。

自分のラフなイメージとしては、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張が、上記の研究論文の発展形で保証できれば、アジャイル開発の有用性を証明できた、ということになる、と思う。

そのためには、実際のアジャイル開発の現場で、そのようなソフトウェアメトリクスを採取して、上記の研究論文の理論的検証が正しかった、という体験論文ないし実験論文が続編になればいいだろうな、と思う。

【５】信頼度成長曲線の理論は１９７０年代からずっと研究し尽くされていて、かなり枯れた理論と聞いているが、この研究論文では、アジャイル開発の要素を取り入れたモデルで考え直すと、古典的な理論から新たな知見が生まれる、という可能性を示唆している、と思う。
そういう意味では、久しぶりに自分の中ですごくホットになって、面白かった。

個人的には、「アジャイル開発はソフトウェア開発ですごく有効である」と証明できるソフトウェア工学の学術論文をもっと読んでみたいし、そういう論文集があると面白いだろうな、とも思う。