この記事はfreee Developers Advent Calender 2020の6日目の記事です。
ども。
id:koyatest ことコヤマンです。QAアニキやってます。
最近はQAアニキのアニキ的な方もjoinしているので僕がアニキで良いのか？と自問自答する日々を送っていますw
一応副業でQA関連の講師業したり、テストのイベントで講演させていただいたり、QA関連のイベントの主催お手伝いなどをしている程度には専門家です。
本記事ではfreeeが取り組んでいる品質指標の改善のお話 をしていきます。
freeeにおけるハッピー（defect）にまつわる背景
まずfreeeではいわゆるバグのことを「ハッピー」と呼称しています(詳しくはfreeeのエンジニアチームをご覧ください)。 以後"ハッピー"と見たらdefectと思って読み進めていただければ幸いです。
freeeでは歴史的経緯により比較的カジュアルにカスタマーハッピーが起票されます(カジュアルに起票できる仕組みが整っています)。そのためユーザーが増えれば増えるほど、指数関数的に増加します。
現状のままユーザーが増加し続けるとエンジニア、サポート、CRE(Customer Reliability Engineer)、QAのメンバーが全員対応に追われ、パンクする予測が立っている状況があり、QAは「不具合発生率」を低減することで最終的な件数を減らすことを目標の一つとしています。
また現状はQAメンバーの割合は多くなく、全てのプロダクト・コミットをQAメンバーがテストする、ということはいまだできていない実情があります。
元々の指標：QAメンバーが関わったプロジェクトにおける重要な流出数/規模
そんな中で数年前から「QA活動における目標」や「QA活動やテストの効果測定」をするために導入した指標が１つあります。
それが以下の指標です。
リリース後１ヶ月以内に流出した重要度の高いカスタマーハッピー数/当該プロジェクトの規模（kloc)
目指したのは 「シンプルに取れる指標」 であることと 「無理の無い指標とすること」
そしてリリース後すぐの差し戻しなどが少ない(=明らかに悪い状態でリリースしない)こと について意識できるものにしました。
色々と検討を重ねた上でシンプルに重要な流出をできるだけ減らすことを目標とし、それを規模によって平準化することで
例えば超大規模な新規開発のプロジェクトの成果と、小規模な機能追加を横並びで見れるようにしました。(もちろん実際には算出するハッピーの定義はもう少し厳密にしています)
上記指標のメリデメ
この指標を掲げて取得していく活動を数年間したところ、以下のことがわかってきました。
メリット
- プロジェクトを横断して同じように成果・効果を見れるようになった
- 容易に算出ができる
- 分子に「QA活動で検出したハッピー数」を加算することで、シンプルに「QAメンバーがテストする前の品質」についても着目できるようになった
運用していく上でわかってきたデメリット
- そもそもの算出対象がQAメンバーが関わったプロジェクトのため、QAメンバーが関わらないプロジェクトについての算出が難しかった
- １ヶ月以後に発覚した問題があったとしても数値上は見れない
- 質として結果指標のため、見れるタイミングが遅い
- 当該指標が良く、品質が向上している実感があっても全体的に楽になる実感まではそこまで持てていない
新品質指標：当該月の重篤度高ハッピーのプロダクト別社内検出数/全検出数
実感としてはプロダクト全体の品質が向上しつつあるという実感はあるものの、背景からくるユーザーの増加に伴うカスタマーハッピーの増加なども相まって、「現場の仕事が楽になる」実感はそこまで持てていませんでした。
そこでもう少し「チーム全体で品質をあげる」ということを意識して取り組めるようにさらにシンプルな指標にしました。
これまでは「QAメンバーが関わったプロジェクト」という枠があったのですがそれを取り払い「全てのプロジェクト」を対象にすることとしました。
当該月の重篤度高ハッピーのプロダクト別社内検出数/全検出数
基本的にJIRAやcommitから定期的に件数を取得することで算出しています。
これらの仕組みは弊社のつよつよQAエンジニアと意識の高いエンジニアの皆さんのおかげでシュッと算出できるようになっています。
(これはとある優秀なプロジェクトの事例です。)
新品質指標の課題
いくつかデメリットはあるものの、ひとまず見れるようにすることを意識して活動しています。
現状認識している課題は以下です。
- ユーザーが多いプロダクトほど数値は悪くなりがちになる
- 結果指標なので見れるタイミングが遅いのは変わらない
といった点です。
現状、最終的に「そもそもの件数」が見えるようになっていることは価値になっていると実感しています。
例えば当該月に8件検出して2件流出したら80%という割合になりますが当該月に1件検出して1件流出だと50%と算出されます。
割合としては悪くなっているように見えてしまうのですが、実際の母数(検出数)が減っているということは品質は安定している、というインサイトを得ることもできるようになります。
もちろん数値・閾値は目標値として持ちますが、最終的なゴールは「検出の総数を減らす（＝組織が上手くなってそもそもの検出数が減っていく）」ことなので目標値に一喜一憂せずにその値の本質を見ることができるようになります。
最近ではこの指標だけではなく、他の指標やデータと組み合わせることで更に意義深いインサイトが得られると言う話もしています（が、長くなるので詳細は割愛します）。
アジャイル開発の中でどのような品質指標を取っていくか？と言う課題は多くの組織が悩むところと思いますが、我々の現状の取り組みがなんらかの参考になれば幸いです。
実はQA募集中です
こういった感じで「スピードと品質と両方が求められる中で如何にシンプルで本質的なことをするか」というチャレンジをfreeeのQAは頻繁に質の高い議論をしながら進めるような活動をしています。
興味のある方は是非門戸を叩いてみてください。
明日はエンジニアからデザイナーにチャレンジしたfkadyさんの記事です！お楽しみに！
