本記事は、Luup Advent Calendar 2025の11日目の記事になります。
はじめに
こんにちは、Luup Quality Team QAのかすみです。
Quality TeamというSREとQAを合体させたチーム編成になってから、少しだけSREチームの業務を覗かせてもらったので、それについて書こうと思います。
（ほぼ）未知の世界へ
システムテストの設計実行を中心に10年近くQA業務を行ってきました。
そんな自分がSREの業務として参加するようになったものは以下です。
- ソフトウェアインシデントの管理
- Monte Carlo
- SLOの設定方法
上から感じたことなどを書いていきます。
ソフトウェアインシデント管理
※ここではソフトウェアインシデントをインシデントと記載します。
Quality Team誕生前まではインシデント管理はSREチームが担っていました。
リリース後はSRE、リリース前はQAというようなざっくりとした線引きをして業務を分けていたので、そのような形になったのですが、今インシデント管理に携わってみて、これはQAも関わった方がいいなと考えるようになりました。
理由は以下です。
-
そもそも流出不具合なのでQAは把握していた方がいいものも多い
-
流出不具合 ≠ QA見逃し不具合ではあるが、インシデントを眺めているとQAでどうにかできるパターンや、そもそもの仕組みがいけてないパターン、致し方ないパターンがある
-
今まではポストモーテムに招集される側で、QAとしてどうやったら漏れが防げたかの観点で喋ることが多かった
- が、ポストモーテムを開催する側に立つことで、QAだけでは防げない、むしろシステムをどうにかすればいいのではないか？となる観点を持てるようになった
-
インシデント（本番流出不具合）のラベリングと不具合（テスト環境不具合）のラベリングは揃えた方が異なる環境でも現象をリンクさせやすく、不具合がどこに潜みやすいか分析しやすくなりそう
インシデントに関して受け身でいることをやめることで新しい価値観が出てきたというのが学びです。
Monte Carlo
Quality TeamになってSREの業務を覗いてから初めて聞いた言葉でした。
そもそもなんだ？とその存在を知るところからが始まりでした。
以下に自分の理解を記載しておきます。
Monte Carloとは
BQに入ってくる値を数値として記録します。
そして日々のデータを蓄積してMonte Carlo側で閾値を設定します。そこから外れるとアラートが飛んできます。
ここでの閾値やアラートの設定はMonte Carlo側が自動で行なってくれます。
定例でアラート内容を確認し、値の変化は何が影響して発生したのかをデータエンジニアと共に確認します。
その結果、一時的な値の変化であれば問題なしとしたり、逆に値が回復しない場合は関係するエンジニアや部署と連携を取ります。
また、特定の日付で大幅に閾値から外れた値が検出された場合にも、同じように関係各所と連携を図ります。
日々の蓄積データの数値化と閾値の設定をすることで、本番環境で発生している違和感を可視化し、それについて確認を行えるというものがMonte Carloです。
参考URL：https://www.montecarlodata.com/why-monte-carlo
Monte Carlo定例に参加して
定例へ参加するようになって、Monte Calroのメリットを見出しました。
- 本番環境での異常を数値で確認できる
- 実際にユーザーの触った情報が数値化されているため、QAメンバーで本番確認をするよりも遥かに得られる情報が多い
- そもそもこういったデータでの品質管理が行われているという安心感がある
例えば技術的な変更やアプリUIの変更などに関しては、リリースされたら全国各地のユーザーが触ってくれるので、QA数人が本番で触るのとではデータ量が違います。
その実際のデータ量が規定値を上回っていたり下回っていたりするとアラートが飛ぶので、何かが発生している可能性が高くなります。
実際の何がセーフなのかアウトなのかはデータエンジニアなどと一緒に確認をするのですが、Monte Carlo定例を経て、何かを検知できるので、何も知らなかったという状態ではなくなります。
QAもMonte Carloに関わることで、本番環境で何が起きているのかを数値で察知できる為、Qualityを向上するための知識の1つになると思います。
SLOの設定方法
SLOはいつもSREのメンバーが設定してくれていたものを眺めて、これはどうにかならないのかと言っているだけでした。
弊社の施策の1つにマップのUIをガラッと変えるものがありました。自分はここのSLOの設定に関してSREメンバーと担当PMと共にとどういったものを取得するべきか、また変更前のUIで取得したSLOと比較して、ユーザーにとって良い品質のものを提供できているのかを検証するために、CUJと機能重要度をベースに新UIのSLO設定に関わりました。
今後、情報が蓄積されたら改めて比較する予定です。
QAの業務だけでは見えてこなかったものが、Quality Team発足後に見えてきました。
自分は割と手を動かそう！不具合を出さないために隅々まで検証しよう！というパワータイプではあったのですが、SREの業務の一部に携わって、その考え方が変わりつつあります。
- 不具合の発生を前提とする
- その重要度や対応の温度感を整理する
- 不具合が出た時にどれだけ早く検知するか
- 検知した後にどれだけ早く塞げるか
- 塞いだ後にどれだけ早く補填できるか
Criticalの不具合流出はもちろん事前にテスト環境でQAがブロックしますが、それ以外の不具合に関しては絶対に流出させない！そのためにテストをするんだ！という気持ちから、何か起きたら即対応できるようなリカバリー態勢を整えていこうという気持ちに変化しています。
目標の持ち方が「不具合を出さない」というものから「如何に早くユーザーに届けるか」を重視し始めることができました。
どちらにもメリットデメリットがあると思いますが、自分の視野を広げられた点で言えば、Quality Teamの発足とSREの考え方を知るというのはポジティブな方に働いています。
未知の業務に対するスキルや知識は後々培っていくとして、この考えをもっと広げられていければと思っています。
これをベースに弊社のQAの仕方ももっとスピードに合わせて変えていきたいと考えています。
考えていることとしては、E2Eテストの自動化をアップデートしたり、APIベースの自動テストを導入してみたいと考えています。
SREとQAの統合について、SRE側の視点で記載している記事もあります。
もしよろしければ閲覧をどうぞ！
最後に
Quality TeamはLuupのプロダクトの品質をより良くするための活動を行なっていきます。
新設されたチームのため、手探りのところはありますが、一緒に品質向上について考えていくメンバーを募集しています。
もし、興味のある方はぜひお気軽にお問い合わせください。
Discussion