「メトリクスを考えてみよう！」の後半編です。
前編はこちら
。
QAの福島さんのほうからQAの考え方、実際に使っているメトリクスを発表してもらいました。
メトリクスに入る前に、まずは品質というものを考えてみましょうということで、当たり前品質と魅力的品質についての説明がありました。
当たり前品質
満たされているのが当たり前で、満たされていないと著しく価値を失うもの。
魅力的品質
満たされていなくても不満はないが、満たされていれば価値が著しく向上するもの。
そして、自分達のプロダクトについて当たり前品質と魅力的品質について考えてみました。
なかなかパッとは出ないですねぇ。。。
魅力的品質を出せない参加者もいたようです。
福島さんは魅力的品質を考えることが、開発を楽しくする方法の一つだと言っていました。
また不具合件数の数＝品質と考えることは、当たり前品質のみしか見ていないことと一緒であり、本来のQAとしては当たり前品質＋魅力的品質の両方の品質（＝プロダクト品質）を保証しなければいけないですと言っていました。
ただし個人的には魅力的品質全てを数値として測るのは結構難しいと思っています。
続いてプロセス品質の話です。
一般的にモノ作りの現場ではQCD（Quality-Cost-Delivery）が大事と言われますが、このQualityを司っているのが品質保証部門になります。
ただし、多くの会社ではDeliveryが一番の優先になり、納期に間に合わせるためにはQualityやCostは度外視になることが多いです。例えば異常系のテストはほとんどしていないけどリリースとか、赤字覚悟で人数をドンと入れるとかですね。
福島さんは、やはりQCDのバランスが重要であると言っていました。
一般的にはプロダクト品質(Q)を達成するためのプロセス品質と言われますが（※1）、品質(Q)だけではなくQCD全体のバランスを良くするための手順がプロセス品質にあたるのではないかということを言ってました。
※1 参考 ITPro http://itpro.nikkeibp.co.jp/article/COLUMN/20121105/435003/
自分も確かにそうだと感じました。
このバランスが取れていなければ継続的に事業としては成り立たないし、ひいては顧客満足にならないと思っています。
ただし、『アジャイルサムライ』ではQCDに加えてS（Scope～機能）を加えて、機能の削減も視野に入れてバランスを取ることを提案しています。ちなみに本文中ではQCDSのことを『荒ぶる四天王』と表現していて、個人的にはカッコ良くてとても気に入ってます。
続いて、工程別欠陥除去率の説明。
欠陥除去率はどういうものなのかという説明と、各工程で取り除くことができる％を出してくれました。コードレビュー（Code Inspection）で除去できる欠陥が一番多くて平均で60%くらい。ユニットテストで除去できる欠陥は25%くらいとのことでした。
生データはJaSSTのCapers Jonesさんの発表（p46 RANGES OF DEFECT REMOVAL EDDICIENCY）です。是非参考にしてみてください。
http://www.jasst.jp/archives/jasst08e/pdf/A1.pdf
開発者にメトリクスを伝えるときはデータだけを提示するのではなく、そのメトリクスが何を意味しているのかまで伝えると良いとのことでした。これは前編のGQMの話とも被っていますね。
ここで2枚の絵の良くある間違い探しを実施しました。
間違いが7つあるのですが、最後の一つってなかなか見つけられないですよね。
欠陥除去能力のメタファとして実施したということで、「今と同じくらいコードレビューもしてください」と言われました。確かに皆さん異常な集中力で間違いを探していました（笑
以下のような感想をつぶやいている学生の参加者もいました。
『今のケースは比較対象がちゃんとあって，しかも欠陥の個数が予めわかってるからいいけれども，実際のコードレビューはそこら辺が全部未知だからすんごく難しいだろうなぁ 』
確かに実際のコードレビューは単純にDiffを取るわけではなくて、自分の中に確固たる良いコードのイメージがあって始めて指摘できるようになるのだと思います。
続いて実際にメトリクスを取るときに福島さんが気をつけている事を教えてくれました。
・時間をかけない。
“今”はすぐに過ぎ去っていく。
・観測対象に影響を与えない。
開発者の負荷を増やしてはいけない。
作業遅延の原因を調べるために、新たな作業を増やす！！？？
・手持ちのデータを使うのが一番
成果物の量。日付。作者。手順を守った証拠。ざっと見た質。
人間も品質の一つの要素と考えたときにチームの士気を計るメトリクスとして、ニコニコカレンダーというものもあります。
これも各顔に点数をつけて集計すると立派なメトリクスになりますよね。
http://ja.wikipedia.org/wiki/%E3%83%8B%E3%82%B3%E3%83%8B%E3%82%B3%E3%82%AB%E3%83%AC%E3%83%B3%E3%83%80%E3%83%BC
最後に信頼度成長曲線の話をして終わりました。
数本のデータがあったのですが、ある時間で正規化することで2つの傾向に分かれるようでした。
ある一定の期間までにバグを出せているかどうかでまだバグは出続けるのか、それとも飽和しているのか傾向が分かるのではないかということでした。
同じ開発スタイルだと使えそうですね。結構面白い考えだなぁと思って聞いていました。
