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

by sugitak

Embed

Start on current slide

Slide 1

Slide 1 text

©estie inc. SREとQA 二人三脚で進めるSLO運用株式会社estie SRE 杉田毅博 (X:@sugitak06) 於 SRE Next 2026 1

Slide 2

Slide 2 text

©estie inc. • estie では SRE と QA Engineer (QAE) とが協力して CUJ を設定した • お互いの目線の違いと、「事業を推進する」という共通の目線が活きた • 違いを知ろう。同じものを見よう。協力しよう本日の内容 2

Slide 3

Slide 3 text

©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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 9

Slide 10

Slide 10 text

©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 10

Slide 11

Slide 11 text

©estie inc. • 当時、単一プロダクトからマルチプロダクト体制へと変わっていく最中だった • 開発に信頼性が追いついていなかった • 問題の原因もバラバラ。「改善していかなければ……」数年前、プロダクト全体で障害が多発 11

Slide 12

Slide 12 text

©estie inc. • 多くのサービスが存在 • システム構成はほぼ均一 • 3層構造 • データパイプラインとのデータ同期あり • 顧客に提供する価値に占めるデータの割合が大きい SRE視点で見た私たちのサービス 12

Slide 13

Slide 13 text

©estie inc. • 問題の原因はバラバラ、かつテストしにくい部分 • フロントエンド修正で別の箇所に影響 • データ不整合 • 内部APIでのプロダクト間通信 • 共通点は「顧客影響」……そうだ！問題の分析と解決方法の模索 13

Slide 14

Slide 14 text

©estie inc. • ……があれば、変更による問題をかなり検知できる • 我々が最重要視している価値を継続的に提供できているか、正しく確認できる • 一方で、 CUJ を定めるためには、以下の問いに答える必要がある：「このプロダクトにとって、本当に大事なことは何だろう？」 Critical User Journey (CUJ) を実行する E2E テスト 14

Slide 15

Slide 15 text

©estie inc. • 応えるためには、そのプロダクトについて深く知る必要がある • プロダクトの価値は、顧客が受け取る価値である • 顧客の問題を解決してこそ、プロダクトには価値がある • 同時に、プロダクトの価値とは祈りでもある • 社会をこのように変えていきたい、という願い・哲学が、プロダクトの根っこにはある（プロダクトビジョン） • Platform 型 SRE が、多くのプロダクトがある中、その全てを深く理解して CUJ を定めに行くことは容易ではない => どうしよう？「このプロダクトにとって、本当に大事なことは何だろう？」 15

Slide 16

Slide 16 text

©estie inc. 16 ここまでのまとめ多数のプロダクトで問題が散発共通点は「顧客影響」だけ CUJ のテストを作れば守れそう全プロダクトで CUJ を定めるのは大きな仕事。困った

Slide 17

Slide 17 text

©estie inc. • E2E テストを全プロダクトに展開したい • 少ない QAE 人数でも、複数プロダクトで継続的な品質を維持したい • 開発者によって維持できるような、「最重要なテスト」だけを作りたい • E2E ブラウザテストは結果が崩れやすい。テストは厳選したい • Core User Scenarios (CUS) と呼ぶ、最重要ユーザーシナリオ一覧を作成した • Staging デプロイ後、この E2E をクリアできれば production deploy が可能になる 17 QA チームが、たまたま「テスト拡充」をしていた

Slide 18

Slide 18 text

©estie inc. • 5~10個程度の、典型的な「ユーザはこの行動ができるべき」を表すシナリオ • シナリオの中で重要性によってTier分け。最重要なテストを CUS と命名 • 一般用語ではない。 estie 社内用語 • CUJ にインスピレーションを受け、 QA 視点で再構築した • 詳しくは別途、 estie QAE のスライドを！ Core User Scenarios (CUS) について https://speakerdeck.com/ma_cho29/core-user-scenarios 18

Slide 19

Slide 19 text

©estie inc. CUS と CUJ との違い CUJ Critical User Journey CUS Core User Scenarios 見ている人 SRE QAE 意味合い「サービスが動いている」ことを示す最も重要な一連の操作プロダクトとして保証したい最小限のユーザーシナリオ個数 1 5~10 実行環境 Production Staging 実施タイミング定期的に確認 Staging deploy 時 19

Slide 20

Slide 20 text

©estie inc. • QAE が開発チームと合意したユーザーシナリオは、間違いなくプロダクトの最重要なシナリオである o CUS の定義には QAE の魂が込められている！ • 最重要なユーザーシナリオの中から、もっとも重要なものを CUJ として選択。本来いちばん難しい「チームとの合意」部分を QAE が実施済みだった！ CUS を元に CUJ を作ることができた https://speakerdeck.com/ma_cho29/core-user-scenarios?slide=11 20

Slide 21

Slide 21 text

©estie inc. • 開発全体に不安定問題が発生。品質・信頼性の両面の対応が必要になった • QAE-SRE の相互の情報交換により、互いのノウハウと成果物を持ち寄って品質・信頼性を向上させられた事例のまとめ 21

Slide 22

Slide 22 text

©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 22

Slide 23

Slide 23 text

©estie inc. 1. Team Topology https://teamtopologies.com/key-concepts 23

Slide 24

Slide 24 text

©estie inc. QAE がチームの深い理解をしていた。 SRE はその知識を借り、広く展開することができた一般に、 SRE より QAE の方がプロダクトを深く理解していることはよくある Team topology の違いが活きた 24

Slide 25

Slide 25 text

©estie inc. 1. SREとQAEとで協力してCUJを定めた事例 2. 事例から得られたまなび 2-1. Team Topology 2-2. SREの視点、QAEの視点 2-3. 同じものをみる大切さ 3. まとめ 25

Slide 26

Slide 26 text

©estie inc. • QAE ：「高速な価値提供サイクルの支えになる」 • 提供スピードも品質の一部 • 支えるためには何でもやる！開発、運用、PM、…… • SRE：「プロダクトの信頼性を高めるための SRE 文化と基盤を切り拓く」 • Enabler であり Platformer である、という立ち位置 • 常にしんがりを務める気概でプロダクトを保護 estie における QAE と SRE 26

Slide 27

Slide 27 text

©estie inc. • 品質工学的には、信頼性は品質の一部 • ハードウェア的な製品として考えると、 Quality は初期不良、 Reliability は長期利用での故障のしやすさに影響する要素 • ソフトウェア開発にこのアナロジーを持って来ると、よりソフトウェア開発ライフサイクル（ SDLC）に関心があるのが QA 、サービスを提供し続けることに関心があるのが SRE • 専門が変われば、着目するものも変わる Quality と Reliability の一般的な話 27

Slide 28

Slide 28 text

©estie inc. 28 QAE と SRE の視点の違いレイヤ・技術・場所の違いというよりものの見方が違う QAE の見方開発と実環境のループから、顧客に渡せる価値を高める SRE の見方常に実環境に着目。ブラックボックス前提で考えており、可観測性が課題

Slide 29

Slide 29 text

©estie inc. 29 QAE と SRE は相互の補完関係 • QAE は開発を通じて安定したプロダクト品質を提供できる • SRE は運用の高度化によりフィードバックを高精度化する • 互いの強みを活かし、相互補完して品質を高めていける QAE

Slide 30

Slide 30 text

Slide 31

Slide 31 text

©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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©estie inc. • SRE と QA とが協力し合うことで CUJ を整備することができた • SRE と QA とは互いに補完関係 • 同じ目標を持つからこそ、違いが活きてくる • 同じものを見れば、きっと協力し合える一丸となって最大の出力を出そう 36 まとめ