こんにちは。ニーリーQAチームの関井です。
今回はQAチーム紹介の記事の中で別の記事で紹介しますと書いていた、ニーリーの主力プロダクトである「Park Direct（パークダイレクト）」のバグレベル定義と変更障害率の計測についてお話できればと思います。

当時の課題と背景

チーム紹介の記事で述べた通り、QAチームのミッションは「品質とアジリティの両立」です。これはQAチームが発足する前（1人目QA時代）からQAのミッションであり、チームが発足してからこれまでやってきた取り組みもこのミッションをベースに考えてきました。ただ、「品質」と「アジリティ」を同時に上げていくことは難しいので、「アジリティ」も維持しつつまずは「品質」を上げていくことにしました。
その中で、最初に取り組んだことがバグレベル定義です。

QAチームが発足した後、現状の課題を整理する中で、品質に対する認識が合っていない（ルール化されていない）ことが問題であるという話になりました。
この問題を分解すると大きく2つに分けられます。

1. バグが見つかった際、重大なバグなのか軽度のバグなのかを感覚的に判断している

2. テストを実施する際、どのくらいテストをしたらいいのかわからない（テスト担当者の感覚に依存する）

1つ目については、どのようなバグが重大であり、どのようなバグが軽度なものかを判断する軸を作ることで解決できます。
2つ目については、テストのルール化をすることになりますが、そのルールを作るための前提として、プロダクトの品質を定義をし、開発組織で品質に対する認識を合わせる必要があります。
「プロダクトの品質」は、バグの判断軸や追うべき指標を決めることで、逆にプロダクトがどういう状態だと品質が高いと言えるのかが浮き彫りになると思い、まずは1つ目の課題に対してアプローチすることにしました。

品質に対する認識を合わせる取り組み

バグレベル定義

バグレベルは一般的に、重大度と発生確率（※）をそれぞれを評価し、バグレベル決定のマトリクスで最終的なバグレベルを決定することが多いかと思います。Park Directでも同様のアプローチでバグレベルの決定を行うようにしました。しかし、ここで重要になってくるのは、重大度や発生確率の定義です。この部分についてはプロダクトごとに違うため、自分たちで考える必要があります。

※ 致命度や再現度などと呼ぶこともあります。

重大度は次のような定義としました。抜粋して掲載していますが、実際にはもっと具体的に定義をしていて、例えば「ビジネスインパクト、レピュテーションリスクが大きいもの」は「決済機能など金銭的なエラーにつながるもの」などに細分化されます。また、SLOベースのレベル定義もするほか、「この画面でこの機能が動かないとCritical」のような具体例も記載することで、人によって判断するバグレベルが揺らがないように工夫しています。

重大度は高い順にCritical、Major、Minor、Infoの4段階で定義しています。
定義のポイントは、代替手段や回避方法の有無を判断基準にしているところです。Park Directでは、代替手段や回避方法があることが多く、機能が使えなくなったとしても別手段で目的を実現できるのであれば重大度は下げても良いという判断にしています。

発生確率は次のような定義としました。

発生確率はGenerally、Occasionally、Rarelyの3段階にしています。
条件と頻度（再現確率）のいずれか低い方を発生確率として選択するようにしています。重大度と同様に、条件には具体例がないと人によって判断が異なってしまうため、具体的にどういう条件が揃うとどのレベルにあたるのかを例示してあります。

そして、バグレベルは次のマトリクスを利用して決定しています。

バグレベルは高い順にCritical、High、Mid、Lowの4段階で定義しています。
バグレベルのマトリクスを見ると重大度のウェイトが大きいですが、発生確率がRarelyの場合ではバグレベルが一段回下がるような設計にしています。
ちなみに、発生確率がGenerallyとOccasionallyでバグレベルに変化がありませんが、後々の不具合分析用としてOccasionallyは用意しました。
バグレベルによる修正目安も決めており、High以上ではすぐに対応し、Mid以下であれば他の開発案件と優先度比較の上でいつ修正するか決めるといった運用をしています。よって、バグレベルはHigh以上とMid以下で対応が大きく分かれるような設計となっています。
バグレベルはインシデントの定義にも利用されており、Park Directの本番環境での不具合のうち、バグレベルがCriticalまたはHighのものをインシデントと定義しています。

変更障害率の計測

バグレベルを定義し、インシデントの基準も決めることができたので、次に品質を定量的に表すことに挑戦しました。QAの方は共感いただけると思いますが、品質を定量的に表すのは難しく、一般的にこういう指標がよく使われているというものは今のところないと思っています。ただ、やはり何かしらの指標は設定したく、Park Directではソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour KeysのうちChange failure rate（変更障害率）を品質の指標として設定することにしました。
変更障害率の計算式は下記になります。※一定期間は過去90日を基本としています。

変更障害率の目標値は15%以下とし、日々モニタリングを行っています。（目標値の参考）

変更障害率は低ければ低いほど良いとは思いますが、QAチームとして「品質とアジリティの両立」をミッションとして掲げており、高い品質を求めすぎてアジリティの低下やコストを増加させるより、ある程度のリスクを取ってアジリティを上げていきたいという判断から、5-15%のレンジを目安として推移するよう品質保証活動を行っています。

下記の図は2023年1月からの変更障害率の推移を示したものです。
3月ごろまではリリース頻度が高くなく変更障害率も高めに推移していますが、その後リリース頻度が上がり、またQAチームが本格的に立ち上がってきたこともあり、変更障害率が15%を切るようになりました。
6月以降は15%以下で推移しており、目標としている品質レベルを維持できています。

運用して見えてきた課題

以上の取り組みで、冒頭に挙げた課題を概ね解決できたものの、運用する中でさらに見えてきたこともあります。

まず、バグレベルという判断軸を作ることで「どういうバグが重大なのか判断できない」という状況を改善することができたものの、実際に起きたバグに対してバグレベルを付けていってみると、発生確率の判断が難しいケースが少なくないことが分かってきました。

先述した通り、発生確率は発生条件と再現確率のいずれか低い方を発生確率として選択するような設計にしています。その2つをまとめてしまっていることで、どのランクを選択したらいいか迷わせてしまっているケースが出てきました。バグレベル定義をした際は、あまりパラメータが増えても複雑になるから良くないだろうと思い、条件と再現確率をまとめていたのですが、それぞれ分けて設定するような設計にするなど、バグレベルを付けやすいように改善が必要だと考えています。

また、バグレベル決定時の発生確率のウェイトが小さく、「バグレベル≒重大度」という状況になっているのも改善したいと考えています。バグレベルを導入してからバグのデータが集まってきているので、それをベースに発生確率の定義を見直す予定です。

次に、変更障害率という定量的な指標を導入することで、品質に対する基準を設けることができましたが、変更障害率だけでは指標が足りないと感じています。

今回はひとまず変更障害率を品質指標として計測していましたが、これだけでプロダクトの品質を評価できるわけではないので、他にも様々な軸で品質を表現していく必要があります。現在はバグレベルの高いインシデントを追っていますが、バグレベルの低い不具合も数が多ければ品質の低下を招く可能性があるので、例えばその数を計測するなど、多面的に品質を表現できる方法を検討したいと思っています。また、外部品質だけでなく、内部品質に関する指標も設定したいと考えています。外部品質は比較的QAチーム主導でも決めやすいのですが、内部品質はコードやアーキテクチャなどについても把握しなければならないので、これまでよりも開発チームとの協力が必要です。密に議論を重ねて、適切な指標を設定したいと思っています。

どのくらいテストしたらいいかの拠り所

冒頭で述べた「どのくらいテストしたらいいかわからない」という課題についても、バグレベルやインシデントを定義できたことにより、バグレベルがHigh以上の不具合はちゃんと防ぐ必要があるよねといった共通認識が生まれ、どのくらいテストをしたらいいかの拠り所にもなっています。

現在、開発組織内で認識を共有できているのはバグレベル定義と変更障害率だけですが、先述したように多面的に品質を表現するなかで「プロダクトの品質」を定義し、「どこまでテストしたらいいか」の最適解に近づけるよう取り組んでいきたいと思います。

さいごに

QAチームとして最初に取り組んだバグレベル定義と変更障害率計測についてご紹介しました。定義を決めるという取り組みでしたが、一度決めたらそれで終わりというものではなく、運用しながら日々変化する状況に対応してくことが大切かと思います。

QAチームでは他にもテストプロセスの改善やテスト自動化など、様々なことに取り組んでいます。この記事を読んで少しでもPark Directに興味をもっていただいた方はカジュアル面談で聞いてみてください！

株式会社ニーリー　プロダクト開発本部　プラットフォーム開発グループ
関井 祐介　Yusuke Sekii
2017年に半導体メーカーに新卒入社。車載カメラや測距センサーの信号処理SWなど、組み込み系製品を中心に品質保証を担当。また、2020年よりQA業務と並行して、UX改善やAI製品の品質保証にも従事。2023年1月に株式会社ニーリーにQAエンジニアとして入社。

herp.careers O01【エンジニア】オープンポジション

株式会社ニーリー

募集要項をみる

■開発メンバーとのカジュアル面談はこちら

・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう

・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？