「信頼度成長曲線」を信頼しない勉強会

　SQuBOKユーザ会主催の「信頼度成長曲線 勉強会」に参加してきました。

　『SQuBOK Guide』は2007年に刊行されて以来、認知度が高まってきていています。その一方で「どう使っていいかわからない」といったユーザの声があることから、様々な活動に着手しているとのことです。

ソフトウェア品質知識体系ガイド―SQuBOK Guide

ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)

　たとえばfacebookアカウントであったり、googleドキュメント上でSQuBOK知識エリアに肉付けしていく「進化系」の取り組み。
　勉強会もそのひとつで、今回の第1回を起点に、今後さまざまなトピックを取り上げていく予定です。

　さて、今日は信頼度成長曲線。
　品質に関わるメトリクスにも賛否両論ありますが、信頼度成長曲線はさらに微妙な存在。「品質が安定すると、曲線が寝る」。何かもっともらしいけれど、「寝る」とは何か。テストやめれば寝るではないか。などと各所からのツッコミを浴びることは避けられません。

　今回はライトニングトークス（LT）形式で、4人のトーカーが10分間ずつプレゼンし、15分間ずつディスカッションするという流れになりました。面白いことに、4人みなさん切り口が違っていて、バランスのよい展開。

1. 信頼度成長曲線を利用するためのツール
2. 信頼度成長曲線の現場での利用と疑問
3. 信頼度成長曲線のモデルの意味
4. ネタ(笑

　以下簡単に、LTの内容をシェアしたいと思います。

佐々木さんのLT

　広島大学の奥村先生の開発されたツールSRATSの紹介。
　Excelアドインで、欠陥の摘出実績を元に、適切なモデルの選択と信頼性評価をほぼ自動で行なってくれるものだそうです。わたし自身は使ったことがありませんが、そのうち試して紹介しようと思っています。

　さてこのSRATS、モデルの理論的な背景を知らなくても曲線が出てステキです。が、佐々木さんを初めとして、会場にいらした他のユーザの方も、「正しく使えているか不安」「残存欠陥数など出せるが、本当か？」といった、漠然とした疑問をお持ちのようでした。
　手でやる・ツールでやるという話以前にやはり、「信頼度成長曲線って結局何者なのよ・・・何を教えてくれるのよ・・・」というところで、ぼくも含めみなさん、釈然としないところが大いにあるのですね。

　このツールの使用手順を聞いてぼくが「えっ？」と思ったのは、実績から、フィットしそうなモデルを選ぶという流れです。
　それぞれのモデルには前提があります。たとえばロジスティック曲線であれば、「ある数量の増加率は、その時点での数量に比例する。ただし数量には上限があり、それに近づくと増加率が下がる」といったものです。にも関わらず、その前提をスルーして、「この曲線に似ているみたいだよ！」と当てはめるのって、本末転倒じゃないのかなあ。※ツールに対する疑問ではありません。

岩坪さんのLT

　信頼度成長曲線を現場で適用している中で、実際の使い方と、日々疑問に感じていることを発表されていました。
　横軸は日付、工数、テストケース数のどれを選ぶべき？ 1つのグラフに乗せる対象とするのは、テスト工程全部か、それとも単体・統合・システムテストのそれぞれ？ といった、かなり具体的なお話です。

　岩坪さんの組織では、横軸は日付、対象はそれぞれのテスト工程ごとということでした。わたしの経験上もそのケースが多いのですが、個人的には横軸にテストケースを使う方がよさそうな気もしています。工数の測定は手間がかかりすぎるし、テスト担当と改修担当が同一になってしまうツライ戦いでは、日にちが意味をなさないからです。

　なお、品質の判定に信頼度成長曲線を使うには使っていますが、「寝ている」ことを絶対条件にするのではなく、得られた曲線の意味が合理的に説明できるのであればかまわないという程度の位置付けだということで、まったくもって同意します。
　テストケース密度や不良密度でも同じですが、1つのメトリクスだけ使うとか、最初に定めた基準値を満たしていないと問答無用で却下とか、そういうことをすると、現場のメトリクスアレルギーが進む結果になりますよね。

丹羽さんのLT

　今回の内容は、ご本人のブログでも紹介されているISSRE2011での発表を、LT用にアレンジしていただいたようです。

soft-dev.cocolog-nifty.com

　現場での適用とか、品質の判定の仕方といった現実的な問題はあるとして、それ以前に、「そもそもどうして信頼度成長曲線って寝るの？」という根本的な疑問を解こうという試みです。確かに、「だんだんバグが出なくなって、寝る」はなんとなくそういう気がしますが、ロジカルに説明してみろと言われると難しい。

　丹羽さんは、「1つの欠陥が、複数のテストケースで摘出されうる」という「重複」が、曲線に収束をもたらす1つの要因であるという結論を出されています。
　1つの欠陥が1つのテストケースでしか摘出できない場合、テストケースをランダムに消化すれば欠陥数のグラフは線形になるでしょう。一方、複数のテストケースで摘出できる欠陥が多ければ、初期のテストケースでは欠陥を見つけやすいから曲線は強く立ち上がり、だんだん収束していくということになります。

　収束をもたらす今一つの要因として、テストケースの消化順番の恣意性についても言及されていました。危なそうな場所から取り組んだり、探索的テストの手法でテストを進める場合は、これもまた鋭く立ち上がりそうです。この話についてはまた別の場所で語るつもりとのこと。

渡辺さんのLT

　「ネタ」と上では書きましたが、おふざけの中にも、止むに止まれぬ現実の問題をえぐっていて、考えさせられる内容でした。その現実とは、「曲線の収束が、受け入れの絶対条件になることがある」というものです。
　岩坪さんのLTでもあったように、曲線が寝ていなくてもその理由が明確であれば問題ないでしょうし、逆に寝ていたからといって、それだけで品質が安定したと判断するのもおかしいのですが、そう考えない組織もあるのかも知れません。その結果、現場が「空気を読んで」、「信頼度捏造曲線」を作り出すことがありりうるんじゃないか？という懸念があります。

　そこで渡辺さんが、ジョージ・ジョースター1世にならって半ば逆説的に提案するのが、「捏造されちゃってもいいさと考えるんだ」。ウソをつくならもうウソはつく前提でいいから、「健全なウソ」をつけよと。やってないテストをやったというのは許されないウソだけど、やったテストをやった日を改竄するのはいいんじゃないの？という開き直りです。
　なかなかギリギリのご提案ですが、極論の中によく考えてみるべき事柄が散りばめられていました。

全体を通して

　テーマがテーマということもあり、終始ディスカッションの活発な場でした。特に、「信頼度成長曲線を信用している人」という堀さん（お世話人のお一人）の問いかけに、上がった手の少ないこと・・・。みなさん、「やっぱよくわからんけど、みんなもよくわかってないな」と感じて帰路についたと思われ、何よりです！
　参加者がオンライン含めて50人近くと、日科技連の講堂を借りての開催は正直ものものしいところもありましたが、第1回として大成功だったと感じます。お世話係の方、日科技連事務局の方にお礼を言わせていただきます！

　なお次回のテーマは、「レビューの質」となるようです。
　興味のある方はぜひ、参加してみてください。