SREとQA 二人三脚で進めるSLO運用/sre-qa-slo

SRE Next 2026 (2026-07-11) 発表の内容です。
SRE と QA とが協力してひとつの目標に向かった事例と、そこから得られた学びを共有します。

Transcript

1. ©estie inc. SREとQA 二人三脚で進めるSLO運用 株式会社estie SRE 杉田 毅博 (X:@sugitak06) 於 SRE Next 2026 1
2. ©estie inc. • estie では SRE と QA Engineer (QAE) とが協力して CUJ を設定した • お互いの目線の違いと、「事業を推進する」という共通の目線が活きた • 違いを知ろう。同じものを見よう。協力しよう 本日の内容 2
3. ©estie inc. 杉田 毅博 github:sugitak, x:@sugitak06 • 2022~ 株式会社estie 「1人目SRE」兼 EM • 2017~ 株式会社Preferred Networksコーポレートエンジニ ア。Embedded SREも兼務 • 2015~ freee株式会社にてSRE。デプロイを60分→7分に短 縮・安定化。CSIRT立ち上げリーダー、セキュリティ開発な ど担当。自称デプロイ屋 • 2011~ IIJ にて Ruby PaaS 開発。ユーザコードのデプロイ 部分を一人で担当。自称bundlerの専門家 講演等 2017-07 Schoo にて Prometheus 講師 2018-02 Software Design 誌にて9ページ記事執筆 2026-07 SRE Next 講演 3
4. ©estie inc. Confidential © 2022 estie Inc. Our purpose 産業の真価を、さらに拓く。 4 ©estie inc.
5. ©estie inc. Confidential © 2022 estie Inc. 5 ©estie inc.
6. ©estie inc. Confidential © 2022 estie Inc. 6 ©estie inc.
7. ©estie inc. Confidential © 2022 estie Inc. 7 ©estie inc.
8. ©estie inc. Confidential © 2022 estie Inc. 8 ©estie inc.
9. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 9
10. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 10
11. ©estie inc. • 当時、単一プロダクトからマルチプロダクト体制へと変わっていく最中だった • 開発に信頼性が追いついていなかった • 問題の原因もバラバラ。「改善していかなければ……」 数年前、プロダクト全体で障害が多発 11
12. ©estie inc. • 多くのサービスが存在 • システム構成はほぼ均一 • 3層構造 • データパイプラインとのデータ同期あり • 顧客に提供する価値に占めるデータの割合が大きい SRE視点で見た私たちのサービス 12
13. ©estie inc. • 問題の原因はバラバラ、かつテストしにくい部分 • フロントエンド修正で別の箇所に影響 • データ不整合 • 内部APIでのプロダクト間通信 • 共通点は「顧客影響」……そうだ！ 問題の分析と解決方法の模索 13
14. ©estie inc. • ……があれば、変更による問題をかなり検知できる • 我々が最重要視している価値を継続的に提供できているか、正しく確認できる • 一方で、 CUJ を定めるためには、以下の問いに答える必要がある： 「このプロダクトにとって、本当に大事なことは何だろう？」 Critical User Journey (CUJ) を実行する E2E テスト 14
15. ©estie inc. • 応えるためには、そのプロダクトについて深く知る必要がある • プロダクトの価値は、顧客が受け取る価値である • 顧客の問題を解決してこそ、プロダクトには価値がある • 同時に、プロダクトの価値とは祈りでもある • 社会をこのように変えていきたい、という願い・哲学が、プロダクトの根っこにはある（ プロダクトビジョン） • Platform 型 SRE が、多くのプロダクトがある中、その全てを深く理解して CUJ を定めに行くことは容易ではない => どうしよう？ 「このプロダクトにとって、本当に大事なことは何だろう？」 15
16. ©estie inc. 16 ここまでのまとめ 多数のプロダクトで問題が散発 共通点は「顧客影響」だけ CUJ のテストを作れば守れそう 全プロダクトで CUJ を定めるのは大きな仕事。困った
17. ©estie inc. • E2E テストを全プロダクトに展開したい • 少ない QAE 人数でも、複数プロダクトで継続的な品質を維持したい • 開発者によって維持できるような、「最重要なテスト」だけを作りたい • E2E ブラウザテストは結果が崩れやすい。テストは厳選したい • Core User Scenarios (CUS) と呼ぶ、最重要ユーザーシナリオ一覧を作成した • Staging デプロイ後、この E2E をクリアできれば production deploy が可能になる 17 QA チームが、たまたま「テスト拡充」をしていた
18. ©estie inc. • 5~10個程度の、典型的な「ユーザはこの行動ができるべき」を表すシナリオ • シナリオの中で重要性によってTier分け。最重要なテストを CUS と命名 • 一般用語ではない。 estie 社内用語 • CUJ にインスピレーションを受け、 QA 視点で再構築した • 詳しくは別途、 estie QAE のスライドを！ Core User Scenarios (CUS) について https://speakerdeck.com/ma_cho29/core-user-scenarios 18
19. ©estie inc. CUS と CUJ との違い CUJ Critical User Journey CUS Core User Scenarios 見ている人 SRE QAE 意味合い 「サービスが動いている」ことを 示す最も重要な一連の操作 プロダクトとして保証したい最小限の ユーザーシナリオ 個数 1 5~10 実行環境 Production Staging 実施タイミング 定期的に確認 Staging deploy 時 19
20. ©estie inc. • QAE が開発チームと合意したユーザーシナリオは、間違いなくプロダクトの最重 要なシナリオである o CUS の定義には QAE の魂が込められている！ • 最重要なユーザーシナリオの中から、もっとも重要なものを CUJ として選択。 本来いちばん難しい「チームとの合意」部分を QAE が実施済みだった！ CUS を元に CUJ を作ることができた https://speakerdeck.com/ma_cho29/core-user-scenarios?slide=11 20
21. ©estie inc. • 開発全体に不安定問題が発生。品質・信頼性の両面の対応が必要にな った • QAE-SRE の相互の情報交換により、互いのノウハウと成果物を持ち 寄って品質・信頼性を向上させられた 事例のまとめ 21
22. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 22
23. ©estie inc. 1. Team Topology https://teamtopologies.com/key-concepts 23
24. ©estie inc. QAE がチームの深い理解をしていた。 SRE はその知識を借り、広く展開する ことができた 一般に、 SRE より QAE の方がプロダ クトを深く理解していることはよくある Team topology の違いが活きた 24
25. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 25
26. ©estie inc. • QAE ： 「高速な価値提供サイクルの支えになる」 • 提供スピードも品質の一部 • 支えるためには何でもやる！開発、運用、PM、…… • SRE： 「プロダクトの信頼性を高めるための SRE 文化と基盤を切り拓く」 • Enabler であり Platformer である、という立ち位置 • 常にしんがりを務める気概でプロダクトを保護 estie における QAE と SRE 26
27. ©estie inc. • 品質工学的には、信頼性は品質の一部 • ハードウェア的な製品として考えると、 Quality は初期不良、 Reliability は長 期利用での故障のしやすさに影響する要素 • ソフトウェア開発にこのアナロジーを持って来ると、よりソフトウェア開発ライフサイクル（ SDLC）に関心があるのが QA 、サービスを提供し続けることに関心があるのが SRE • 専門が変われば、着目するものも変わる Quality と Reliability の一般的な話 27
28. ©estie inc. 28 QAE と SRE の視点の違い レイヤ・技術・場所の違い というより ものの見方が違う QAE の見方 開発と実環境のループから、 顧客に渡せる価値を高める SRE の見方 常に実環境に着目。ブラックボックス前 提で考えており、可観測性が課題
29. ©estie inc. 29 QAE と SRE は相互の補完関係 • QAE は開発を通じて安定したプロダクト品質を提供できる • SRE は運用の高度化によりフィードバックを高精度化する • 互いの強みを活かし、相互補完して品質を高めていける QAE
30. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 30
31. ©estie inc. 3. 同じものを見る大切さ • Ultimately, user happiness is what matters -- Google SRE Book • Quality is value for some person. -- Weinberg • Quality-as-customer-value -- Martin et al. QA, SRE どちらも「顧客価値」に重きを置く価値観を持っていた 同じ目標を持っていたからこそ、違いが活きた 31
32. ©estie inc. 「同じ目標を持つ」 どこかで見た構図 32
33. ©estie inc. Site Reliability Engineering だ！ • 同じ目標を見ることは Site Reliability Engineering の根幹 o 運用と開発の組織の摩擦をなくすために Google が取った方法が「同じ目標を 持たせる」ということだった • SRE and developer organizations share common goals -- Gustavo Franco, Google, 2019 o https://cloud.google.com/blog/products/devops-sre/how-to-start-and-assess-your-sre-journey?hl=en 33
34. ©estie inc. QAE-SRE 協力体制は Site Reliability Engineering の実践だった 同じものを見て、違いを認め合ったから こそ、協力して新しい価値を創れた 結論： SRE って、力を合わせることなんだ 34
35. ©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 35
36. ©estie inc. • SRE と QA とが協力し合うことで CUJ を整備することができた • SRE と QA とは互いに補完関係 • 同じ目標を持つからこそ、違いが活きてくる • 同じものを見れば、きっと協力し合える 一丸となって最大の出力を出そう 36 まとめ
37. ©estie inc. おわりに 違いを知ろう 同じものを見よう 協力しよう 37
38. ©estie inc. We are hiring! 38 https://hrmos.co/pages/estie/jobs?category=17562936478271 65184