CREがSLOを握ると 何が変わるのか

SREに所属していた際、設定したSLOがユーザの期待値と乖離してしまうことを課題に感じていました。CREでは顧客からもっと近い位置に居るエンジニアとして、環境変化に合わせて「ちょうどいいSLO」を保つことが出来るのではないかという話をしました。

Transcript

1. CREがSLOを握ると 何が変わるのか SRE経験者が⾒たCRE×SLOの可能性 nekomaho
2. nekomaho(masuda.satoru): GitHub: https://github.com/nekomaho Backend Eng. 5年 → SRE 4年 → 2025/12⽉〜 CRE Enabling SREとして開発チームへのSRE活動の浸透 を推進していた。 本⽇のテーマ： 「SREとして4年間SLOを運⽤してきた経験から、 CREがSLO設定のペインを解消できるかもしれな い」 という話をします。 ⾃⼰紹介
3. CUJベースの策定 Critical User Journeyベースで、 プロダクトマネージャーなど関 連部⾨も巻き込んで制定してい た。 定期的なレビュー ⽉次での運⽤レビューに加え、 半年ごとの抜本的な⾒直しも⽋ かさず実施していた。 ※SLOの⾒直しは関連部⾨の関係者を全員招集し ないといけない関係上、半年のスパンになってい た 初期は好調に稼働 最初は運⽤がうまく回り、SLO低 下に対してチームが⾃発的にア クションを起こそうとしてい た。 SREでやっていたSLOの設定⽅法
4. 形骸化の始まり • 定期的なレビューを⾏っているのに、 • だんだんと開発チームがSLO違反に対してアクションを起こせなくなっていった。 • 開発現場のリアルな声： 「重要なのはわかるが、優先度が上がらない」 • 勉強会を実施し、レビューの仕⽅を⼯夫したが、⼀向に改善しない。 当時はこれを完全に「伝え⽅の問題」だと思い込んでいた。
5. 「優先度が上がらない」本当の理由は、 設定されたSLOがユーザの求めるものではなかったからだった。 ヒアリング前の仮説 「信頼性起因の問い合わせからSLOの重要性を 裏付けられるのではないか」 突きつけられた現実 ユーザの不満は「遅い」「落ちる」ではなく、 「もっと機能を充実させてほしい」であった。 ユーザの声 SLOを守るための強い動機付けを得るために カスタマーサポート、ビジネス部⾨へのヒアリングを実施した
6. もっとユーザの近くに居ることが出来れば 上⼿く⾏ったのではないか ⽇常的にユーザに接しているCREならば ユーザに対する解像度が上がるのではないか
7. CREはプロダクトの最前線にいるため、顧客からの 問い合わせ等を通じてユーザの期待値をリアルタイ ムに把握できる。 CREがSLO策定に関わることで、ユーザの期待に即 した「より意味のあるSLO」を設定できる。 実態と乖離した時の検知‧更新もフレキシブルに⾏ える。 正しいSLOは「ユーザの信頼性に対する満⾜度」の 指標となる。 CRE だからできること
8. 市場環境やユーザ期待は常に変化する。SLOもそれに合わせて変えていく必要がある。 ユーザに近いCREならその変化を捉えられる。 ⾼すぎるSLO 開発リソースを過剰に信頼性に ⾷われ、プロダクトの機能的競 争⼒を弱めてしまう。 低すぎるSLO ユーザが不満を抱え、チームが 気づく前に黙って解約‧離脱し ていく。 ちょうどいいSLO これをリアルタイムに保ち続け ることが、プロダクト運営にお いて最も重要である。 気づき ― SLOは「⽔物」である
9. CREとして取り組んでいること SLI/SLO導⼊のナレッジを チーム内でシェア。チーム全 体でSLO策定に取り組めるよ うにする フェーズ 1 (current) CRE主導でCUJを⽤いたSLO 策定に挑戦 フェーズ 2 顧客からのフィードバック データを⽤いたSLO妥当性評 価の仕組み作り フェーズ 3
10. 正しく設定されたSLOは単なる指標ではなく、 ユーザの期待を写した鏡と⾔える 故に、ユーザに最も近いCREこそSLOを正しく捉えられる " "