ハッピーの重篤度でみんなで品質の目線合わせをするぞ！

こんにちは。freeeのQAで品質企画を担当しているymtyです。

freee QA Advent Calendar2024 8日目です。

今回のテーマである、ハッピー（不具合のこと）の重篤度でみんなの品質に対する目線合わせをしていることについては、2024年のfreee技術の日でも同様のタイトルでプレゼンを行いました。その時のスライドや動画も公開されています。

www.youtube.com

このプレゼンの内容を元にしながらも、そもそも重篤度（Severity）ってどういうものか？ということと、freeeでは重篤度についてどんな取り組みをしてるのか？がわかるように情報を追加してこの記事を書いていきます。まずはその前提となるQAのミッションとビジョンから話を始めます。

freeeのQAのミッション

起こしちゃいけない不具合が起きにくい体質にすることでマジ価値※を継続的に届け続ける

※マジ価値：ユーザーにとって本質的に価値があると自信を持って言えること

込めた意志

当たり前品質にフォーカス。品質という言葉は広くいろいろやると中途半端になってしまうので、どこに力を入れていくかが重要

リリーススピードにこだわりたい。継続的にマジ価値を届けていくことが重要

freeeのQAのビジョン

当たり前品質の高速フィードバックの実現

どのフェーズでも目指すべき品質とのGAPを高速フィードバックすることで、手戻りがなく高頻度にユーザに価値を届けられるようにしていく

ここでいう品質について

私たちがミッションとビジョンで対象にしているのはお客様にとっての品質です。開発時の品質やプロダクト品質は大事ですが、それは最終的にお客様にとっての品質に多大に影響するからです。

お客様から見た品質を表すモデルの一つとして狩野モデルがあります。魅力的品質、一元的品質、当たり前品質といったものです。新しいサービス、コンセプトは魅力的、一元的品質を向上させますが、魅力的、一元的品質は、時間とともに当たり前品質になっていきます。例えばスマートフォンが世の中に出たばかりの頃は、画面をタップする、スワイプすると移動するといった使い勝手は新鮮で魅力的でしたし、それらがどんどんサクサク動くようになっていくほどいいねーってなりましたが、2024年になった今では、当然のことであり、特別驚きもしません。

しかし、もしタップしてもちゃんと動かなければ、「やばいな...これ」って思うでしょう。このやばい度合いを表現できるのが重篤度だと私たちは考えています。

やばいゾーンに入るような事象が起きないようにする、もし起きたらしっかり対処を行い今後同じことを繰り返さないというのがQAとしてやらなきゃいけないことだと考えています。ここでいうQAという活動は開発に関わる全員で行う活動です。

QAエンジニアは開発に関わる全員を品質面でリードして、お客様に使ってもらって大丈夫だって情報提供をするためのエンジニアです。

重篤度と優先度

ハッピー（不具合）を発見してから修正完了するまでをマネジメントしていくプロセス全体を通じて、ハッピーを上手にマネジメントするためにいろいろな情報を付与します。そんな情報の中に重篤度と優先度があります。この二つは似てるように見えますが全く別物です。

重篤度は、発見したハッピーに対して、その事象がリリース前であれば開発に／リリース後であればお客様に与えるよくない影響(インパクト)がどの程度あるかを示したものです。重篤度が高いハッピーが確実に再現する場合もあれば、本当に特殊な条件が積み重ならないと再現しない場合もありますが、その事象が発生することでお客様によくない影響を与えることに変わりはありません。わかりやすい例えで言えば、システムダウンするようなハッピーは再現が確実かどうかに関わらず、発生したら確実にお客様に迷惑がかかります。このように重篤度は基本的には変わりません。唯一変わる場合があります。それは、目に見えた事象から原因を調べて理解を深めていくことで、該当する欠陥が実は重篤度がすごく高い、深刻なインパクトを引き起こす事象となる可能性があるものだが、たまたま目に見えていることが大したことではなかった場合です。

優先度は、ハッピーに対してどれだけ速やかに対処する必要があるかを示します。例えば、システムがダウンする不具合（重篤度が高い）は優先度も高くなりますが、簡単に修正可能な軽微な不具合でも、修正の労力が少ない場合は先に対応することがあります。わかりやすい例えで言えば、「処理結果などをメール通知する機能でタイトルが特定の文字の場合だけ文字化けする」という不具合の場合、この不具合自体はシステムダウンするような不具合よりは重篤度が低いですが、修正が簡単だったとすれば、後回しにせずに優先度を上げてシステムダウンになる不具合より先に直すかもしれません。一方で、影響が軽微で再現性が低い場合は、優先度が下がることもあります。例えの続きで言えば、特定の文字の場合は文字化けするとしてもその特定の文字がタイトルに入ることは通常の操作だと起こる可能性がとても少ないのであれば優先度を下げる可能性もあります。

freeeでは上記の考えを整理してこのように定義してます。

重篤度（Severity）

事象のひどさをあらわし、ユーザーのもとで発生してはいけない度合いを示す
途中で値を変更することは基本的にない
品質の測定や分析を行う場合に利用できる

優先度（Priority）

作業の順番をあらわし、即座にに対応すべき度合いを示す
状況によって変化することがある（変化してもおかしくない）
品質を示す指標とはならない、期間内の作業量を示す指標にはなる

freeeでは重篤度を4段階で、具体的に定義している

まず、全社的に共通で使う重篤度の定義を以下に掲載します。

しかし、誰が見ても理解できる定義である反面、自分たちのプロダクトに当てはめると判断が分かれる場合があります。特に、事象と事象に該当する欠陥で重篤度が違うような場合に混乱します。この場合は欠陥が「深刻なインパクトを引き起こす事象となる可能性」があることに対して重篤度をつけていることがわかるようにします（逆のケースもしかりです）。

なので、各プロダクトごとに具体的にこの事象はどの重篤度に当てはまるかといったように判断できる定義をするようにしていきました。その機能がユーザーにどう使われるのか、システムの作りから考えてどういう意味があるかといったことを知っている、プロダクトに詳しい自分たち自身で重篤度の定義を具体的に決めるとすっきり理解できるからです、

定義する際には、リリース後に発生してしまった事象をピックアップして「これはどのレベルになるか？」っていうことをプロダクトマネージャー、デザイナー、エンジニア、QAで話し合って決めてもらいました。

各プロダクトで決めていくという活動は実は2020年にも行ったのですが、2023年に再度行いました。人数が増えたりプロダクトが増えることで気がつくと風化していってしまったからです。

具体的に定義している重篤度っていうのがどの程度あるのかわかるように以下にリストを掲載します。たくさんあるんだなってわかってもらえると思います。（リストの中身を具体的に見てもらう必要はないので、全体がわかるように縮小した図を掲載しています。）

重篤度を浸透させることによる効果

重篤度の目利きでハッピー（不具合）を未然防止する

最初の方で、重篤度は「品質の測定や分析を行う場合に利用できる」と記載しました。重篤度がわかってくると、出してはいけないハッピーって具体的に何か？っていうことを関係者が判断できるようになります。重篤度をみんなで決めていく活動は、品質の測定や分析がみんなの目線があった状態でできるようになるためにしていますが、出してはいけないハッピーを減らすためには、ちゃんと目線合わせができることが大事だとも言えます。まず、どのようなハッピーがお客さんの元で起きるといけないのか？という目線が合います。起こしてはいけないハッピーをfreeeでは障害と呼びますが、どのようなハッピーが障害なのかが目線がブレずにわかるようになれば、開発前からプロダクトマネージャーも重篤度を意識できるようになり、開発中もエンジニアが重篤度を意識して作り、テストできるようになります。そしてQAがテストをする際にも重篤度が高いハッピーが残ってないか？って観点でテストしていけば結果的に障害が出ないことにつながります！

リスクベースドテストの達人になる

重篤度を考慮してテストをすると、「重篤度が高くない機能は短時間で動作確認をする」「重篤度の高い機能に対してしっかりテスト設計を行い一定期間を確保してテストを行う」といった選択と集中でリソースの有効活用ができるようになります。また、無駄にたくさんのリグレッションテストをしなくなるように選択ができるようになります。もっというと、重篤度が高くなる機能から先にテストができるように開発をして、ハッピーがあれば直し、なければ安心できるタイミングを早めることもできます。

重篤度で目線合わせができるようになるためにやっていること

ここまで書いてきた内容をまとめる意味も込めて、どんなことをしたか／しているかを書きます。

定義を決める
- 4段階で定義（全面的に使えない、主要機能が使えない、代替手段がある、実影響なし）
- 優先度と重篤度の違いを明確に定義（重篤度を病気、治療の順序が優先度でたとえる、糖尿病がMajorで擦り傷がMinorだが擦り傷歯すぐ治療できるといった具合）
- 重篤度とお客様へ与えてしまうよくない影響度合いの関係を定義（地震で例える、マグニチュード＝重篤度、震度＝影響度合いといった具合）
ひたすら周知する
- Slack、ブログ
- いろいろな振り返りに参加、なんかといえば重篤度の話をする
- 全社ミーティングでも重篤度の話をする
- 「重篤度おじさん」を名乗る
- PdM、エンジニア、デザイナー、QA全員必須参加の研修（クイズ付き）を行った
具体例はプロダクトごとに決めていく
- 同じような事象だとしてもプロダクトが違うと重篤度が変わることもある
- 2020年にも決めたが、メンバー、プロダクト拡大で再度定義の必要があった

実際、昨年の今頃よりエンジニアの多くが重篤度について話をするようになりましたし、QAのテストプロセスではリスク洗い出し会ででたリスクアイテムに重篤度をつけるチームが現れたり、DesginDocの内容からここはMajorの可能性あるとか話をするようになるチームも増えました。実際に障害が出てしまった時でも、重篤度についてみんなが認識合うかを確認するようになりました。品質分析に重篤度を使うことも浸透してきました。