今月のお題は「メトリクスを考えてみよう！」でした！！
集まった参加者は17名でそのうち学生が3名いました。スゴイなぁ。。。
場所はオラクルさんの会議室をお借りしました。ありがとうございました。
今回は開発者で気にするメトリクスということで根本が、その後QAが気にするメトリクスということで福島さんが発表しました。
参加者のTwitterでの発言のまとめはこちら。
http://togetter.com/li/490480
まずはメトリクスの定義を確認してみます。
*********************************************************
メトリクス(metric):
測定(計量)で使われる尺度と方式。[ISO 14598]
*********************************************************
メトリクスは、計測の対象をどのような方式と尺度で測るかを示すものである。
しかし、一般的には「測定したデータ」の意味で使われることが多いですね。
ということで、恒例になりつつある質問です。
「上司から言われて案件あたりのレビューの指摘数を取っているんだけど、本当にこの作業に意味があるんだろうか？」
メトリクスを取っている人であれば、一回はこのような気持ちになったことはあるのではないでしょうか？
少なくとも上記のように思っている人は何のためにメトリクスを取っているかは分かっていないと思います。
上司、または別部署のQAチームからの要請で取っているときに、開発者自身は目的を見失いがちになることがありますね。
そのときに有効な考え方の一つとして、米国メリーランド大学のDr. Basiliらによって提案されたGQM（Goal-Question-Metric）というF/Wがあります。
まず初めに達成すべき目標(Goal)を考えてから、どうしたら目標を達成することになるか？(Question)、そしてそれを知るためのデータを決める（Metric）、という流れで考えていきます。
参考）データ指向のソフトウェア品質マネジメント p11 （通称デート本）
実際にGQMを業務で使ったことがあるTEF道のQAエンジニアから聞いた話だと、GQMを開発とQAが一緒に考えることでお互いの共通認識が出来上がったとのことです。この状態になれば、先ほどの本当にこの作業に意味はあるんだろうか？という疑問は生まれなくなると思います。
「メトリクスを取るときは、目的から伝えよ！」っていうことですね、先生っ！！
東芝さんのGQMの活用事例も参考にしてみてください。
www.toshiba.co.jp/tech/review/2006/01/61_01pdf/a06.pdf
続きまして、開発時に使えるメトリクスの紹介です。
まずは、ユニットテストで使用するコードカバレッジを紹介しました。
ここらへん、色々な言い方があって本当に分かりにくいですよね。。。
参加者の方は以下のサイトなどを参考に再度自分でまとめてみることをお勧めします。
ITPro
http://itpro.nikkeibp.co.jp/article/lecture/20070209/261626/
ソフトウェアテストの勉強室
http://softest.cocolog-nifty.com/blog/2008/03/post_7864.html
ソフトウェアの品質を学びまくる
http://blog.livedoor.jp/prjmng/archives/51650711.html
・命令網羅[Statement Coverage]（C0）
・判定網羅[Decision Coverage] （C1）
・条件網羅[Condition Coverage]
・複合条件網羅[Multiple Condition Coverage]（C2）
複合条件網羅は一番厳格ですが、条件が多いとケースが馬鹿みたいに増えていきます。
たとえば1つのif文の中で条件（例えばage >= 20など）が10個あると、複合条件網羅の数は2の10乗＝1024になります。
無理ですよね（笑
ただ、仮に条件を5つずつメソッド分けができたとすると、新たに作成したメソッドは2の5乗×2=32＋32＝64と呼び出し元の4パターンで、少し現実的な数になりましたね。このことからもメソッドは小さく、テストしやすく作るというのは重要だと思います。
(※2013/04/21 秋山さんの指摘により複合条件網羅の説明を変更。秋山さんありがとうございました。）
このカバレッジを使うときに一番気をつけたいのは100%を目指さないこと。
100%って言いたいのは山々なのですが、大抵は誰かの見栄であることが多いです。
無理に90%→100%を目指すことで、開発を改善するためのデータが開発を圧迫するということにもなりかねません。
福島さんの経験によるとC1-60%がせいぜいだということでした。
実際に参加者の体験でこんな事例があったようです。((((；ﾟДﾟ))))))) ガクブル
『意地になってC0を100%を達成して、ちょっとでもリファクタリングすると、テストが全損する事案を見た事があります。』
一般的にコードカバレッジと言えば、通っているコードのこと＝命令網羅を指すことが多いと思いますが、ツールによってはC0、C1、C2など色々取れるものもあります。
http://www.techmatrix.co.jp/quality/ctest/unittest/coverage_report.html
さて、続きましてバグが潜んでいるところを探すメトリクスの紹介。
複雑度、凝集度、結合度を紹介しました。複雑度はC1と似ていますね。
やっぱり複雑度が高いということは、バグが潜んでいる可能性は高いわけです。
複雑度の数値は、一般的に下記と言われています。
・10 以下であればよい構造
・30 を越える場合，構造に疑問
・50 を越える場合，テストが不可能
・75 を越える場合，いかなる変更も誤修正を生む原因を作る
ちなみに自分が見た最高の数値は110でした。煩悩の数を超えたなぁと思った記憶があります。。。
凝集度と結合度は概念だけの説明でした。
複雑度、凝集度、結合度は設計、コードの品質の一側面をあらわしています。
是非、自分達のプロダクトで計測してみてください。
自分の発表の最後は前回に引き続きJOJO〆をしました。
「メトリクス」とは、「実力」を知ることッ！
「数値」を我が物とすることじゃあッ！
ウィル・A・ツェペリ
ジョジョの奇妙な冒険（３巻 ９７頁） （C) 荒木飛呂彦
← TO BE CONTINUED （後編につづく）