11月のテーマは『メトリクスを使ってプロジェクトを診てみよう』ということで、TEF道からJaSST北海道で使用したワークショップのお題をお借りしました。
今回の勉強会ではアンチパターンのところに注力して実施することで、メトリクスを見る目が変わると思っています。
場所はデータコムさんです。今回もありがとうございます！
今日のお菓子はかりんとうシュークリーム！
初めての食感と味です♪
まずは自分も所属しているTEF道のプチ紹介です。
濃いキャラが沢山いて面白いコミュニティですよ。
その後、メトリクスの説明です。
メトリクスというのは、プロジェクトやプロダクト状況をある視点で「数値化」したものです。
もちろんメトリクスを取得するのが目的ではなく、何らかの判断をするためにメトリクスを取得するのが目的です。
硬直化している組織などでは、取得する意味が分からないデータを沢山取ってることってありますよね？
そこらへんはGQM（Goal, Question, Metric）という考え方を使うことでスッキリ解決すると思います。
GQMに関しては以前の勉強会で実施しました。
http://ameblo.jp/sendai-test/entry-11515248308.html
それではアイスブレイクも兼ねて、メトリクスクイズ！！
***************************************************
メトリクスクイズ①
あるシステムについての想定バグ数と、実際にテストチームが発見したバグ数は以下でした。
この結果から言えることは？
想定 発見バグ数 100件
実績 発見バグ数 5件
①システムの品質がとても良かった
②テストチームのテスト技術不足
③バグ数の情報だけでは、①とも②か分からない
***************************************************
これは良くありますね。
ソフトウェアがいいのか、テストが悪いのかは分からないです。
なので、答えは③です。
***************************************************
メトリクスクイズ②
プログラム品質改善のため、開発仕様書レビュープロセスを導入し、レビュー実施時間とバグ率のメトリクスは以下でした。この結果から言えることは？
① レビュー時間とバグ率には相関関係が無く、レビュー時間を増やしても、バグは減らない
② レビュー時間とバグ率には相関関係があり、レビュー時間を増やすほど、バグは減る。
③ レビュー実施とバグ率の直接の因果関係は、このメトリクスだけでは分からない
***************************************************
さて、こちらは一見レビューとバグ率に相関がありそうです。
で、②にいきたくなりますが、本当に相関があるかは多角的に見て判断する必要があります。
ということで、答えは③です。
続きまして、実際にあった事例を元にしたアンチパターンです。
テスト勉強会ではノンフィクションでお届けします（笑
***************************************************
例題① レビューの効果？
あるシステムのバージョンごとの発生バグ件数のグラフがあります。上司はVersion18～Version20 にて実施したレビュー改善の効果がでて、バグ件数がVersion21から少なくなったと言っています。
これは本当でしょうか？本当かどうかを確かめるためには他にどのようなメトリクスが必要でしょうか？
***************************************************
バグ件数は確かに少なくなっていますが、即レビューの効果というのはちょっと短絡的な感じがします。
もしこのような仮説を立てたら、その裏付けを取りましょう。
今回の回答例としては、他にもあると思いますが、以下の二つを考えてみました。
①レビューの指摘件数/開発対象機能数
②レビュー指摘重要度の割合
もしレビューの指摘件数が多くなっていて、その分テスト工程でのバグ件数が少なくなっているということであれば、確かにレビュー効果ということができると思います。もしくは、重要度Aの割合が増えている場合は重要なレビューの効果があると判断して良いと思います。
さて実際には何が起こっていたかというと…
レビューの指摘件数/開発対象機能数を見てみたところ傾向は見えてきません。
実際はどうなっていたかというと、残業規制がかかっていて開発対象機能数が半分になっていました。
開発機能数が半分になっていたので、発生バグも半分になっていたというオチです。
こんなこと起こらないと思っていますか？でも単一の指標、特に規格化されていない指標だけを見て判断するとこのようなことが起きる可能性があります。
さて、例題が終わったところでワークの方にガッツリ入っていきます。
今回の問題はしっかり作りこまれている上に、かなり現場に即した良いお題です。（手前味噌でスイマセン＞＜）
Copyrightの関係で詳しくは書けないですが、概要だけ。
あるプロジェクトについて様々なメトリクスを取っています。
そのメトリクスに基づいてダメ社員が分析＋方針を立てているのですが、この分析＋方針が問題ありなので、どこがマズいかを参加者の皆さんに検討してもらう、というワークでした。
JaSST北海道のワークではオープンクローズチャートについてのみ実施しましたが、今回の勉強会ではここに重点を置いて以下のうち①～③を実施しました。
①オープンクローズチャート
②バグ登録状況
③テスト密度
④欠陥率／バグヒット率
参加者は一つの資料だけではなく、他の資料や仕様書なども見ながら総合的に判断をしていました。
最初はどうやって考えたら良いか分からない参加者も居ましたが、３つ目になってくると気になるところを見つける事ができていました。嬉しいですね～。
実際の業務でも単一のメトリクスから単純に判断してしまうことがありますので、本当にその結論でいいのかを考える癖をつけていきましょう。
色々な人から話を聞いた結果、やはりプロジェクトの中身をよく分かっていない人が間違った判断をしてしまうようです。
最後に全体のまとめです。
◇メトリクス分析により、「気になる箇所」の特定が素早く行える
◇正しいメトリクス分析により、プロジェクトへの有用な情報を提供できる
◇単一メトリクスだけではなく、複数のメトリクスで補完して分析すること
◇仮説を立てる→別のメトリクスまたはインタビューにて検証の流れ
◇メトリクスに振り回されない(メトリクス収集を目的としない)
そしてJaSST北海道のときに森崎先生がグッとくるコメントをしてくれたので、それを紹介しました。
『実際の現場ではワークのように和気アイアイとは行かないものです。なので、最初にどういうメトリクスを重要とするのか、関係者で合意を取っておくことが重要です。これを事前にしておかないとどうしても喧嘩腰になり、雰囲気が険悪になってしまいます。』
今月もどうもありがとうございました！