リリース判定基準・信頼度成長曲線はまあまあ使える

2020年11月20日リリース判定

信頼度成長曲線の推定は信頼できるの?

信頼度成長曲線で推定した今のソフトの潜在バグが6件だったとしたら、この値は信頼できるのでしょうか? その答えは判りません! です。この信頼度成長曲線は、あくまでも赤い実績に対して、数学的な関数を当て嵌めただけの線です。今後あと何件のバグが殻らず見つかります、というように未来を予測する素敵な能力は持っていません。 

さらに言えば、バグの検出がゴンベルツ関数やロジスティック関数に従うという事も、何処にも明確な根拠はありません。 ただ、過去の多くの事例から考えて、バグの成長曲線がゴンベルツ曲線やロジスティック曲線などに重なる事が多かった、という先人達の経験則があるだけです。 また、入力に使うバグ検出数やテスト工数の値がブレれば、その実績値に当てはめられる成長度曲線の形状も変ってきます。

そんな物で信頼できるの?

さてどうでしょうか? 皆さんはこのような信頼度成長曲線とかバグ成長曲線による潜在バグの推定を信用しますか? 当たるも八卦当たらぬも八卦の眉唾物のように思いますか? グータラ親父は、この信頼度成長曲線の推定結果を結構信頼して、ソフトウエアのリリースを判定する時の大切な情報の1つ使っていました。

年間100件近くのソフトウエアリリースの判定この信頼度成長曲線を作っていると、根拠は無いですが、リリース時点のソフトウエアの品質つまり出荷後に市場の本番運用でバグが見つかる割合と、信頼度成長曲線の示す潜在バグの推定状況とに、充分な相関関係がありそうな感触が得らえます。

また、テストの品質やテストの量、そこで見つかったバグの件数やバグ修正の状況など、色々と集めた情報から判定したソースコード品質の状況とも、信頼度成長曲線の示す潜在バグの推定とは、感覚的に合う事が多いです。

そもそも、これから市場で発覚するかも知れない潜在バグの数、という本質的に何が正しいのか誰にも判らない未来の状況を、なんとか推定したいというのがリリース判定時点での状況です。 ですので、まだ見つかっていない潜在バグの件数を、まがりなりにもグラフにして推定して見せてくれる信頼度成長曲線は、なかなか嬉しいツールです。 

そして信頼度成長曲線が示す未来の推定が、別の方法で集めた今までに判っている事実から推定されるソースコードの品質の状況と割と合っている事が多いという自分として納得のできる経験が溜まってきているのならば、リリース判定の1つの情報として使わない手はありません。

使う決めては見栄えです

まあ、グータラ親父がリリース判定する時にどうしていたかというと、信頼度成長曲線もその他の情報と同列で、リリースできるかどうかを判定するための重要な情報の1つという位置づけです。 特に信頼度曲線を最重要の情報としてリリース判定をしていたわけではありません。

しかし、客先や社内の経営陣にリリースするソフトウエアの品質が良い事を説明する資料を作る時には、この信頼度成長曲線のグラフをまっ先に使います。 

他にも色々な情報があって表にしたりもしますが、このグラフの訴求力はダントツです。 もちろん、その時に使う信頼度成長曲線は、充分にバグの検出がおわって残存バグが殆ど残っていない状況を示しているこのようなグラフになります。

  ソフトウエアの品質は良い事を説明する訴求力

このグラフを示して、充分なテストを行いもう新たなバグが残っていないと推定できる品質に達しています と言い切ると、結構説得力がでます。

見方を変えると、このレベルまでバグの検出が収束していないと、リリース時点でなだバグが潜在しているリスクがある、と考える必要があります。 その場合には、ソースコードの品質が不十分な状態であるリスクが高いと考えて、リリースの判定は他の情報も含めて慎重に判断する必要性が出てきます。

これが正解というのは無いですね

いかがでしたか、ソフトウエアの品質を決める一番重要なソースコードの品質なので、色々な情報を集めて、多面的に判断する必要があります。 もちろん、グータラ親父がやってきたよりも、もっと多くの視点で見る必要性もあります。

ここまでに紹介してきたのは、あくまでも一例です。 理想形は描けるでしょうが、会社の業務として作業効率とリリースタイミングという市場原理を意識したリリース判定の場面では、いろいろな取捨選択が必要になり、その判断の基準は組織の成熟度や市場によっても変ってきます

ですので、どんな場合にもあてはまるこれが正解というものは無いでしょう。 判断基準は、各々の会社・判断責任者が考えて決めていく必要があります。 グータラ親父の経験が、皆さんご自身の判断基準を作られる時の参考になれば幸いです。

ところで残バグがあったらどうします?

さて、ここまではテストで見つけたバグについて考えてきました。 ところで、テストで見つけたバグはリリース時には全て修正されていますか? 修正が間に合わなくって、リリースの次期が来たのにまだバグが残っている、とい事はありませんか?

理想的には、全てのバグが修正されてからソフトウエアをリリースできれば良いのですが、理想と現実との間に大きな谷が横たわっているのは、世の常ですね。  

リリースしなきゃいけないけどまだバグが有る、そんな時のリリース判断をグータラ親父はどうしていたのか、次の記事で紹介しましょう。

(次の記事)リリース判定基準・残存バグはサービス提供への影響で判断する に続く
(前の記事)リリース判定基準・残存バグ0は必須条件じゃない に戻る
リリース判定の先頭の記事 に戻る