はじめに
「この不具合、リリースブロックになる？」
QA で不具合を検出するたびにこの議論が発生し、人によって判断基準がバラバラであるため、貴重な時間を消費していました。本記事では、この課題を解決するために私たちのチームが導入した不具合ランクのスコアリングによる運用を紹介します。
結論から言うと、「致命度 × 再現度」で算出した不具合ランクが A 以上ならリリースブロックというルールを決めました。以下、その設計過程と運用ルールを共有します。
想定読者
- QA 体制を立ち上げ中で「リリース判断どうする？」を議論しているチーム
- 開発と QA で「不具合の重要度」の認識がズレた経験がある方
前提：私たちのチーム構成
- Tech チーム: 7 名
- QA 担当者: 1 名（他業務と兼任）
- QA 体制の発足時期: 2025 年 10 月（本記事執筆時点で約 2 ヶ月）
少人数で 2 つのプロダクトを並行開発しており、QA 担当者も兼任のため、リリースブロックかどうかの判断に多くの時間を費やしたくないのが本音です。だからこそ、判断基準を仕組み化することで、議論の時間を極力抑える必要がありました。
課題：判断基準がなかった
以前の私たちは、リリースブロックかどうかを毎回その場で議論していました。
具体的に困ったケース:
ケース 1: Tech は深刻、QA は軽視
- QA: 「UI 上は問題なく見えるからリリースしていいのでは」
- Tech: 「いや、内部的にデータ不整合が起きるから絶対ダメ」
QA からはサーバー側の影響が見えないため、表面上は問題なく見えてしまいます。
ケース 2: QA は深刻、Tech は軽視
- Tech: 「表示が少し崩れるだけ、機能は動くから軽微でしょ」
- QA: 「いや、この画面はお客様が毎日見る場所。体験としては致命的」
Tech は「動くかどうか」で判断しがちですが、QA はユーザーの利用シナリオを熟知しているため、体験上の深刻度を重視します。
このように、リリースブロックかどうかを判断するうえでどちらか一方の視点だけでは見落としが発生するという問題がありました。
では、どうすればこのズレを解消できるのか。次のセクションで、私たちが導入したスコアリングの仕組みを紹介します。
不具合ランクのスコアリングとリリースブロックの定義
不具合を発見した場合、以下の定義に従い致命度・再現度を S から D までの 5 段階で評価します。
致命度
| ランク | 定義 | 事例 | スコア |
|---|---|---|---|
| S | 全プラットフォームでアプリの利用可否にかかわる影響を与える不具合 | アプリがクラッシュする、メイン機能が動作しない | 5 |
| A | 一部プラットフォームでアプリの利用可否にかかわる影響を与える不具合 | スマートフォン版でアプリがクラッシュする、メイン機能が動作しない | 4 |
| B | アプリは利用可能だがユーザーに影響を与える不具合 | サブ機能が動作しないが代替手段がある | 3 |
| C | ユーザーにあまり影響を与えない不具合 | 重度なレイアウト崩れや文言の誤り、仕様通りだが動作として不適切 | 2 |
| D | ユーザーにほとんど影響を与えない軽微な不具合 | 軽微なレイアウト崩れや文言の誤り | 1 |
再現度
| ランク | 定義 | スコア |
|---|---|---|
| S | 全プラットフォームで条件なしで必ず発生する | 5 |
| A | 60%以上のユーザーが満たす条件で発生する、もしくは特定のプラットフォームで必ず発生する | 4 |
| B | 30%以上のユーザーが満たす条件で発生する、もしくは管理機能など少数のユーザーのみ使用する機能で必ず発生する | 3 |
| C | 10%以上のユーザーが満たす条件で発生する | 2 |
| D | 発生条件を満たしづらく大部分のユーザーでは発生しない | 1 |
不具合ランクの決定
評価した致命度スコアと再現度スコアをもとに、不具合スコアを計算します。
不具合スコア = 致命度スコア × 1.1 + 再現度スコア × 0.9
計算した不具合スコアをもとに、不具合ランクを決定します。
| 不具合ランク | 不具合スコア |
|---|---|
| S | 9 以上 |
| A | 7 以上 9 未満 |
| B | 5 以上 7 未満 |
| C | 3 以上 5 未満 |
| D | 3 未満 |
Tech と QA 両方がスコアを算出し、高い方を採用
これが本システムの肝です。
Tech と QA が同じ不具合に対してスコアを入力し、高い方のランクを採用します。高い方を採用する理由として、QA が「軽微」と判断しても Tech が「内部的に危険」と判断するケースがあるからです。逆もまた然りで、Tech が軽視しても QA がユーザー体験上の深刻さを指摘することもあります。
どちらかが危険信号を出していれば止めるという「安全側に倒す」設計により、片方の視点だけでは見落としてしまうリスクをカバーしています。
リリースブロックの閾値
算出した不具合ランクが A 以上であればリリースブロックと判定します。
この閾値については感覚値で決めました。厳密な根拠があるわけではなく、まずは運用してみて調整する前提です。
まとめ
本記事では、リリース判断を属人化させないために導入した不具合ランクのスコアリングシステムについて紹介しました。
不具合の「致命度」と「再現度」を掛け合わせてスコアを算出し、Tech と QA 両方のスコアのうち高い方を採用する仕組みにより、どちらか一方の視点では見落としてしまうリスクをカバーしています。暫定的にランク A 以上をリリースブロックと定義し、判断基準を明文化しました。
コミュニティオのテックチームはコミュニケーションが非常に活発で何でも相談し合える組織風土のため、運用していく中で困ったことはコミュニケーションで解決することを前提としました。そのため、まずは運用を開始することを第一優先とし、不具合スコア算出の係数やリリースブロックの閾値は仮置きの状態です。今後は運用データを蓄積しながらブラッシュアップし、リリースブロック判定の精度を定期的に振り返っていく予定です。
Discussion