品質の指標と本番の品質

まず影響の確認です。どの機能で、どれだけの利用者に、いつから起きているかを調べ、重大なら切り戻しや機能フラグで止める判断の材料を、開発者や SRE にすぐ渡します。次に再現です。検証環境で再現手順を確定させ、再現しない場合は本番との違い（データ・設定・端末）を調べます。

直ったら修正を確かめ、関係しそうな周りの機能も回帰テストします。そのうえで原因の分析として、「なぜリリース前に見つからなかったか」を考えます。テストケースの抜けか、環境やデータの違いか、仕様のあいまいさかを分けます。

最後に再発防止として、抜けていたケースを自動テストに足す、テストデータを本番に近づける、監視を足すなど、仕組みで防げる対策を決め、振り返りでチームに共有します。誰のミスかではなく、どこで防げたかを話すようにしています。

「リリース前に防げなかったもの」と「テストの仕組みの健康さ」の両方を見ます。前者は、本番で見つかった不具合の数と重大度、その原因（どの工程で入り、なぜ見つからなかったか）です。後者は、自動テストの成功率、flaky なテストの数、実行時間です。リリースの安全さとして、DORA の変更失敗率（すぐ切り戻しや修正が要ったデプロイの割合）と復旧までの時間を SRE と一緒に見ることもあります。

注意点は、指標を人の評価に使わないことです。使うと、不具合を報告しない、軽い不具合を大量に起票する、といった数字を良く見せる行動が起きます。また、コードのカバレッジは「通っていないコード」を見つけるのには役立ちますが、高くても確かめる内容が弱いことがあるので、目標にしすぎないようにします。

まずスモークテストで、ログイン・検索・購入などの主要な機能が本番で動くかを短時間で確かめます。毎回同じ品質で確認できるよう、自動化しておくのが理想です。次に監視の画面で、エラー率・応答時間・注文数のような主要な操作の成功数が、リリース前の同じ時間帯と比べて変わっていないかを見ます。

その後の数時間〜数日は、フロントエンドやアプリのエラーの収集ツールで新しく出始めたエラーがないか、サポートへの問い合わせに今回の変更に関係するものがないかを確かめます。段階的なリリースや機能フラグを使っていれば、一部の利用者で問題がないことを確かめてから広げ、問題があればすぐ止められるようにしておきます。

QA は「どの機能が壊れると利用者が困るか」をよく知っていて、SRE は「本番の安定をどう測って守るか」を知っています。この2つを合わせるのが協力の中心です。例えば、主要な流れ（ログイン・購入）の成功率を SLI として監視に入れ、目標（SLO）を一緒に決めます。

ほかに、負荷テストの計画と結果の読み方、段階的なリリースのときに何を見て進めるか止めるかの基準、障害が起きたときの再現と影響範囲の調査で協力します。ポストモーテム（振り返り）では、QA から「テストでどう防げたか」を出し、テストケースや自動テストに反映して、同じ不具合が二度と本番に出ないようにします。

重大度は、不具合が起きたときの影響の大きさで、優先度は、どの順で直すかです。多くの場合は一致しますが、ずれることもあります。

たとえば、トップページの社名の誤字は機能への影響はなく重大度は低いですが、誰もが目にするので優先度は高くなります。逆に、ほとんど使われていない古い管理画面が落ちるのは重大度は高くても、利用者がいなければ優先度は低くなりえます。重大度は QA が事実から付け、優先度はリリースの予定や直す手間も含めて PdM や開発者と一緒に決めます。