こんにちは。エムスリーキャリアでQAを担当している@tak_koheiです。
このエントリーは、エムスリーキャリア Advent Calendar 2022の23日目です。
QA活動で収集しているメトリクスを組み合わせて新たなメトリクスを作り、品質状況の把握や改善に活用した話をご紹介します。
背景
前提
現在、私たちの組織では大小合わせて20以上のサービスにQAエンジニアが関与しています。そして、各サービスでは数時間で終わるものから完了までに数か月を要するものまで大小様々な開発案件を取り扱っています。
メトリクスの収集
そんなQAの活動状況を定量的に計測することを目的として、QA活動の状況を可視化するためのメトリクス収集を2019年から行っています。
QAが関わったほぼ全ての案件に対して、「QAエンジニアが活動に要した工数（単位：時間）」と「開発終了までに検出した欠陥数（単位：件数）」を開発終了後に収集しています。*1また、工数はテストに関するタスクだけでなく、要件確認や仕様検討の打ち合わせ、テスト分析テスト設計、レビュー、など、テスト以外の時間も全て合わせた工数の予実を収集しています。
メトリクスの活用と課題
メトリクスの収集を始めた当初は、比較的大雑把な切り分けで改善するポイントを絞り込んだり問題の原因調査の足掛かりにしていました。例えば、検出した欠陥数の多かった案件を中心にふりかえりや改善施策を実施したり、QA活動時間の予実を比較して乖離の改善に利用したり、といった感じです。
その後しばらくして改善が進んだこともあり、更にもっと詳しく自分たちの活動成果を分析したくなってきました。
また、単純なメトリクスだけでは状況の把握が難しくなっていました。案件規模の差が大きいため、単純に工数の予実や検出した欠陥の数だけでは品質の状態は推察しにくかったのです。例えば、検出した欠陥数が5件でも、全体のQA工数が100時間の大規模開発案件なのか1時間の小粒タスクなのかによって影響の大きさが異なりました。
何をしたか
既存メトリクスの組み合わせ
そこで新たな指標として活用すべく、既存の収集している数値を組み合わせたメトリクスを導入しました。
テスト実行で検出した欠陥の件数をQA活動全体に要した工数で割ることで、QA工数1時間あたりの欠陥検出数を算出しました。例えば、10時間の活動で2件の欠陥を検出した場合 計算：2÷10=0.2 で０．２が結果です。これにより案件の大小に関わらずQA活動の結果が定量的に計測できるようになるのではないか、と考えました。
また、要件定義への参加やテスト分析設計に要した工数と、テスト実行に要した工数を分ける案もありましたが、敢えてやらずに合計をそのまま使用することにしました。私たちの方針は、上流工程からシームレスにQA活動を展開して、開発プロセス全体で品質を向上維持することを考えているため、工程ごとに工数を分割するのが今後どんどん難しくなっていくでしょうし、手間もかかるだろうと考えたからでした。
メトリクスの命名
当初は「QA実績工数1時間あたりの欠陥検出数」という長ったらしい名前を使っていたのですが、普及させるためには呼びやすい名称を付けるのが良いだろうということで、この新しいメトリクスに勝手に名前を付けることにしました。*2
以前、欠陥のことをハッピーと呼んでいる事例が紹介されていたことを思い出し、単位時間あたりの欠陥、つまりアワー単位のハッピーで、ハッピーアワーという名前にすることにしました。*3
何がわかったか
品質状況の可視化
ハッピーアワーを導入したことによって各サービスの品質状況が可視化できました。サービスごとに各月のハッピーアワー平均値の推移を出すことによって、QA活動による品質状況の推移を推測できるようにしています。
これまでの傾向から、どうやら私たちの組織内ではハッピーアワーが0.2を超える状況が継続している場合、検出する欠陥が多過ぎて手戻りが増大し、開発活動になんらかの影響が出ていることが多いようです。 以下にいくつか事例をご紹介します。
考察１
年度の序盤では0.2を超えるハッピーアワーが続いていたものの、年度の後半になるにつれて数値が減少している。実態としても序盤はテスト実行で多くの欠陥を検出していたが、定期的なふりかえり活動による改善や上流工程でのテスト観点フィードバックなどを進めることで、テスト実行時に検出される欠陥数が減少。手戻りが少なくなりプロジェクト進行が円滑になった。
考察２
全体を通してハッピーアワーは低い状態で、実態としてもテスト実行で検出される欠陥が少ない。事前に要件や設計についてしっかりとした詰めが行われている影響ではないかと推察している。
11月の数値が高くなっているのは、小さな案件で軽微な欠陥の検出が続いたためで、大きな問題は無い。（小規模案件では数値が高くなり易い）
考察３
全体を通してハッピーアワーは高い状態で、実態としてもテスト実行で検出される欠陥が多く、欠陥の取りこぼしによる市場障害の発生も続いている。例1同様に地道な改善活動を進めることで、年度の終盤でようやく改善の兆しが見え始めた。
ハッピーアワーは2つ目の事例にあるように、規模の小さい案件で数値が高くなりやすい傾向があり、本当に対処すべき問題の兆候が埋もれてしまう可能性があります。そこで、一定規模以上の開発案件に絞ったハッピーアワーの推移に着目するなど、数値を見る際の切り口についても改善を進めています。*4
また、余談ですが、このように集計したハッピーアワーの推移を元に各サービスの担当QAエンジニアが品質状況についてコメントした月刊誌を、QAから開発部門全体に配信する活動などもやったりしています。
気を付けていること
それから、ハッピーアワーを日常的に使うにあたって気を付けていることがありますので、そちらもご紹介します。
ハッピーアワーを読む方法
まず、ハッピーアワーは数値の大きい小さいで良し悪しが決まるものではない、ということを十分注意するようにしています。
欠陥検出数が多いか少ないかは「プロダクトの実装完了直後の品質」と「担当QAエンジニアの技量」に大きく関わります。QA工数もまた同様です。極力、数値から状況を判断するのではなく、自分たちの活動内容や結果、そこから得られている手応え、が感覚として正しいかを補完するために数値を使うようにしています。
また、サービス間の比較はなるべく行わないようにしています。数値が出るとどうしても比較したくなりますが、私たちの組織では、担当者が違う。サービス自体の規模が違う。取り扱う課題の複雑度も違う。開発プロセスが違う。などなど、比較するための前提がそもそも合っていないことが多いので、それらを比較することは無意味だと思っています。
ハッピーアワーを使う際の注意点
ハッピーアワーを導入する際、以下のことについて全員に注意喚起を行いました。*5
【数値を目標や評価に使用しない】
- チームや個人の評価に使おうとした時点で数値の公正性が失われる
- 本来の重要な活動目的を見失い易い
【数値を使って特定の個人を責めない】
- どうやって改善していけば良いかを考えるために数値を使おう
- みんなで助け合うのが私たちの基本精神
メトリクスは定量的な数字が出せる分、いろいろな目的に使われて独り歩きする危険性を持っていると感じます。罠にハマらないようこれからも十分注意していきたいと思っています。
まとめ
ハッピーアワーの計算方法
- ハッピーをアワーで割る
ハッピーアワーの特徴
- 開発案件の規模に依存せず定量的な指標が計測できる
- ただし小規模な案件では数値が高くなりやすい
ハッピーアワーの利用方法と注意点
- 数値が低ければ良いというわけではない
- 異なるサービスを数値で比較しない
- 数値を評価や目標に使わない
- 数値を使って個人を責めない
もし似たようなメトリクスを既に収集されていたら、是非ハッピーアワーお試しください。 最後まで読んでいただきありがとうございました。
*1:他にも収集している項目はありますが、今回の内容には無関係なので割愛します
*2:自分たちで作ったと思っているだけで、既に存在する手法だったりしたらごめんなさい。→一般的には「バグ密度」という呼び方をするそうです。教えてくださったかた、ありがとうございます！
*3:QAで呼びやすいだけでなく、一部の酒好きエンジニアにも大好評だったとか
*4:それから本編では解説しませんでしたが、現状のハッピーアワーの仕組みはテスト実行の結果でした定量化できないという課題があります。より上流工程で防いだ欠陥混入のハッピーアワーについても定量化できないか、という取り組みを進めています。
*5:「メトリクス全般を使う際の注意点」と読み替えても良いかもしれません。
