SLI/SLO 導入で 避けるべきこと3選

Tamachi.sre#3 (2026/03/19)でのLT登壇資料です。

URL: https://tamachi-sre.connpass.com/event/381960/

Transcript

1. SLI/SLO 導入で 避けるべきこと3選 Tamachi.sre#3 (2026/03/19) Money Forward, Inc. Platform and Reliability Engineering 本部 八木 洸太
2. Money Forward, Inc. 2 八木 洸太 プロフ: • SRE at Money Forward, Inc. (2024/04~) • sig-etcd member (2025/10~) Other Notes: • ブログ執筆・登壇（たまに） • 趣味：アニメ X ID: @88888888_kota
3. 3 / 20 トーク範囲 話すこと・話さないこと ✅ 話すこと • SLI/SLO導入を通じた3つの 教訓 • 失敗から何を変えたか ❌ 話さないこと • SLI / SLO / Error Budget の用 語説明 • SLI/SLOの導入美談
4. 4 / 20 背景 1年間のタイムライン 2025/01 導入開始 2025/02-04 苦戦 2025/05-08 軌道修正 1チームで試行錯誤 2025/12 意思決定に使い始め る https://www.oreilly.co.jp/blog/2023/06/40034_implement ing_service_level_objectives.html
5. 5 / 20 SREの課題 どのサービスが信頼できて、どのサービスが危 ないのか分からない。SREリソースをどのサー ビスに投入すれば良いかの判断材料 がなかっ た。 開発チームの課題 自分たちのサービスがユーザーに良い体験を 提供できているかどうか、データで把握できて いなかった。 → データドリブンなコミュニケーションを確立したい なぜSLI/SLOを導入しようとしたか
6. Money Forward, Inc. 6 一般論じゃ人は動かない 01
7. 7 / 20 教訓1 最初の壁：「なぜ今？」 説明したこと • DevとOpsのバランスが取れる • サービスの信頼性が向上する • エラーバジェットで意思決定できる → 返ってきた反応 「重要性は理解できるけど、 なぜ今なの？」 💡 一般的なメリットを語っても「うちの会社の話」になっていなかった
8. 8 / 20 教訓1 組織の課題と紐づけて話す ❌ Before 「SLI/SLOはDevとOpsのバランスを取るためのも のです。信頼性向上に役立ちます」 → ✅ After 「今、SREはどのサービスに工数を使えばいい か分からない状態が続いている 。その問題を 解決するためにSLI/SLOを導入したい」 教訓1：組織固有の課題に紐づけないと人は動かない
9. Money Forward, Inc. 9 1チームから始めて 横展開する 02
10. 10 / 20 教訓2 15以上のサービスに同時展開しようとした 15+ サービスに 一斉にSlackで リクエスト送信 起きたこと • 複数チームから「依頼が重すぎる」と 苦情 • エンジニア・PMの時間を大量に奪う • 「勝手にDeadlineを決めないで」と言 われる • SREへの信頼度が低下
11. 11 / 20 教訓2 苦情 ① 「SLI/SLOの実装依頼が重すぎる」 💬 実際のフィードバック 1 I felt too much task to product development team from SRE from the first time. The task requires EM, engineers and product manager's time. In my idea, you should start from small steps and then make something better incrementally. I'm not sure what outcome we can get by current your team's requests, but we need to use much time for your request. I guess this is unhealthy investment and resource usage. → 「スモールスタートで進めて。今の依頼は重すぎる。」
12. 12 / 20 教訓2 苦情 ② 「開発チームの状況を考慮して期限決めて」 💬 実際のフィードバック 2 I received some negative feedback from the managers about your SLI/SLO initiative. They feel that they are not heard, and you do not listen to their situation. i.e., XXX has asked you about the strictness of deadlines before and that they should be adjusted to the team's workload and not set arbitrarily. → 「開発チームの状況を考慮すべき。勝手な期限は決めない。」
13. 13 / 20 教訓2 1チームから始めて横展開 1 1チームを選ぶ 意欲的なチームと一緒にSLI/SLOを 設計。要件を一から議論する 2 試行錯誤してテンプレ化 失敗しながらノウハウを蓄積。 3 横展開 テンプレートを持って次のチーム へ。最初のチームを成功事例とし て語る 教訓2：最初から全部やろうとしない。 1チームで学んで横展開
14. Money Forward, Inc. 14 SRE-Devの 事前合意は必須 03
15. 15 / 20 教訓3 半期プロジェクトに入れないと割り込み扱い ❌ やってしまったこと • 半期が始まってから「SLO入れましょう」 • Dev側はロードマップが既に埋まっている • SREの都合で突然リクエストが来る形にな る • → 「割り込み仕事」として扱われる ✅ うまくいったこと • 半期が始まる前にマネージャーレベルで 合意 • SREとDevの共同プロジェクトとして計画に 組み込む • 工数がプロジェクト計画に最初から入っ ている • → スムーズに進む
16. 16 / 20 教訓3 ゼロサムではなくポジティブサムゲームに ⚔ ゼロサムゲーム SREとDevの優先順位がコンフリクト どちらか一方のプロジェクトが進まなくなる → 🤝 ポジティブサム SRE × Dev の共通ゴールを作る 共同プロジェクト 両者に成果 信頼関係が向上 教訓3：半期計画の前にマネージャー合意。共同プロジェクトとして進める
17. Money Forward, Inc. 17 まとめ 04
18. 17 / 20 まとめ 3つの教訓 1 一般論じゃ人は動かない 組織固有の課題に紐づけて話す 2 1チームから始めて横展開 最初から全部やろうとしない 3 SRE-Devの事前合意は必須 半期計画に組み込み、共同プロジェクト化する
19. ありがとうございました！