SLOをサービス品質の共通言語にするために 取り組んできたこと

2026/06/25に開催されたAWS Summit Japan 2026のNew Relicブースにて開催されたミニシアターで発表した資料です。

Transcript

1. © 2012-2026 BASE, Inc. Service Level Management SLOをサービス品質の共通⾔語にするために 取り組んできたこと BASE株式会社 BASE Department ⼩笠原 佑樹 / 若菜 稚広 1
2. © 2012-2026 BASE, Inc. ⾃⼰紹介 ⼩笠原 佑樹 おがさわら ゆうき X: @yukineko_819 所属 BASE株式会社 BASE Department / Product Dev Division （2021年⼊社） 役割 バックエンドエンジニア（シニアエンジニア） 担当 ネットショップ作成サービス「BASE」の「メンバーシップ App」開発リード、注⽂管理リアーキテクチャ、カート負荷 試験環境の構築、などを担当 サービスレベルマネジメント（SLM）を社内で約2年推進 2
3. © 2012-2026 BASE, Inc. ⾃⼰紹介 若菜 稚広 わかな ちひろ X: @__wakanaction__ 所属 BASE株式会社 BASE Department / Product Dev Division （2022年⼊社） 役割 バックエンドエンジニア 担当 ネットショップ作成サービス「BASE」の越境EC機能「かん たん海外販売」の開発、ショップ管理画⾯の機能開発などを 担当 サービスレベル推進活動への参加歴は1年ほど。 この度リードの⽴場を引き継ぐことに 3
4. © 2012-2026 BASE, Inc. アジェンダ ◦ 話すこと １．「SLMをBASE事業部全体に展開する取り組み」を、どう進めてきたか ２．何を重視して取り組みを設計してきたか ３．今後どのような取り組みを進めていく予定か 4
5. © 2012-2026 BASE, Inc. サービスのコア体験を Tier 1 CUJと定義して SLO計測を開始 サービスレベル定点観測会 を発⾜ 立ち上げ期 2023 〜 2024前半 ／ エンジニア有志のみ 拡大と再構築期 2024 〜 2025 ／ 広げて、戻して、再出発 ビジネス接続期 2025 〜 ／ 事業の言葉とつなげる FutureStack Tokyo2023 でSLMを知る 【失敗①】 メンバーシップ App で SLI/SLO の検討 失敗① サービスレベル定点観測会 を4名から12名に拡⼤ → うまくいかず断念、4名 で再起動 失敗② Tier1 CUJを3区分に整理 事業上のKPIと接続 Looker連携でSLOを⾒える 化‧⽉次サマリーレポートを 定期的に事業部全体へ公開 全社化の⼊⼝ 2026年以前の取り組みの詳細はこちら（技術ブログ） BASEにおけるサービスレベルマネジメントのこれまでとこれから 5 ２年間の歩み
6. © 2012-2026 BASE, Inc. プロダクト紹介と話のスコープ 6 • ネットショップ作成サービス「BASE」を運営 • 2026年5⽉時点で累計開設数260万ショップ突破 • 弊社では複数の事業を展開しているが、今⽇のスコープは「BASE」のみ ◦ 参考： https://binc.jp/service
7. © 2012-2026 BASE, Inc. SECTION 1 主要SLOの策定 7
8. © 2012-2026 BASE, Inc. 2026年から「主要SLO」を策定 ✕ エンジニアだけの運⽤指標 開発チームの中に閉じた、 技術側のモニタリング指標 ではなく ◦ 事業部全体の共通認識の基準値 「ネットショップ作成サービス『BASE』として このサービス品質を維持する」ための基準値 として定義‧運⽤ 主要SLOとは 事業インパクトが強く、品質劣化が即座に収益‧UXに影響する指標群 主要SLOの運⽤を設計する上で気をつけた3つのPoint 8 1 主要SLOを事業部全体の指標に 2 運⽤主体のエンジニアに裁量を 3 SLOの提案は誰でもできる
9. © 2012-2026 BASE, Inc. 例 • アプリカートでカート画⾯が素早く表⽰されること • アプリカートで購⼊が正常に完了すること • アプリカートで商品をカートに正常に追加できること Point 1 主要SLOを事業部全体の指標として運⽤する １. 数値に着⽬してもらう • CUJとSLOを1:1で表現できる簡素なものに • エンジニア以外のメンバーにも、サービス品 質を定量化した指標としてSLI∕SLOの数値 をを意識してもらう ２. 最初からたくさん設定しない • 件数は20件と最低限に絞り、まずエンジ ニア組織が運⽤に慣れることを優先 • 質‧量は運⽤しながら洗練させる想定 で、あえて最初から作り込まない 9 主要SLOをサービス品質の共通⾔語とするため、シンプルに設計する
10. © 2012-2026 BASE, Inc. Point 2 運⽤主体であるエンジニアに裁量を持たせる 増減だけは固く管理し、それ以外は現場の判断で動かせるようにする。 対応 意思決定者 運⽤ルール 主要SLOの追加‧除外 事業部定例 事業部全体の指標の増減はフローを整備して固く守る 主要SLO‧SLIの修正 開発組織（現場） CUJの意味が変わらない範囲なら⾃由に実施してよい （SLO閾値の調整、正しいSLIへの変更 など） • 変更した事実は、⽉次のサービスレベルサマリーでまとめて周知 • エンジニア組織は、必要に応じて改善活動を四半期のOKRに組み込み、主要SLOの達成に向けて運⽤する 10
11. © 2012-2026 BASE, Inc. Point 3 SLOの提案は誰でもできる 運⽤の主体はエンジニア。ただし、提案の⼊⼝は全員に開いておく。 11 エンジニア組織 事業部定例 サービスレベル定点観測会 提案者 エンジニア以外でも、誰でも提案OK ← 主要SLOの承認 ← 主要SLO提案の⽀援∕エンジニアのSLMの⽀援∕  ⽉次定例でのサービスレベルレポート報告 ← 主要SLOの運⽤  （SLOの閾値‧SLIの調整、未達時の改善、⽉次での振り返り） ← 主要SLO変更申請のNotionのテンプレートを埋めて提案
12. © 2012-2026 BASE, Inc. SECTION 2 いつ誰を巻き込んで広げていくか 12
13. © 2012-2026 BASE, Inc. いつ誰を巻き込んで広げていくか よくある⽅法：まずエンジニア組織で ① まず エンジニア組織で定着 → “エンジニア発の活動” のまま、⻑期化しやすい ② 軌道に乗ったら 他組織‧全社へ BASEの場合：同時に⾛らせた 事業部定例で主要SLOを承認するフローを確⽴ ＝ 事業部の⽅針と接続する 同時 エンジニア組織が運⽤を開始 ＝ サービスレベルを守る責任は現場に → 運⽤開始の瞬間から “事業部全体で取り組む活動” として周知 13
14. © 2012-2026 BASE, Inc. 実際、どうだったか 同時に⾛らせた結果 ── ⼿応え と 課題 の両⽅が⾒えてきた。 BASE事業定例 提案に協⼒的な反応が返ってきた 「意義がある活動、ぜひ進めてほしい」 「もっと適切なSLOがあるはず」 「うちの取り組みも主要SLOに加えてほしい」 → 「協⼒的」な反応、これからの活動に⼿応え エンジニア各セクション 主要SLOのブラッシュアップが始まった → より良い指標に改善する次のフェーズへ 課題 各セクションの推進者が⾃分の専⾨ドメインの知識を 活かして、主要SLOをさらに洗練させようという動きが 早い段階から始まった。 - エンジニア組織の外からSLOの話が出てくる段階にはまだ⾄っていない - エンジニア組織の中でも運⽤は回りだしたばかり。さらなる習熟が必要。 14
15. © 2012-2026 BASE, Inc. これから⾏なっていくこと SLOを利⽤したくなる仕組みの強化 ビジネス上重要なセグメントに特化したSL設定 • 今まで見えなかった課題を発見し、提供する • 解約リスクに先手を打って対応する、など →メリットを体感してもらい、 利⽤を促進する → 今後増えるSL運⽤に耐えうる体制を作る エンジニア組織に向けて 運用ポリシーの拡充、運用負荷軽減の実施 • バジェットポリシー、アラート整備 • より良いSLI/SLOにする精緻化の仕組みづくり • SLの手運用をOaC化し運用負荷軽減 みんなでメリットを体感して主要SLOを全員の共通⾔語にし、BASEを次のフェーズへ！ エンジニア組織外に向けて いい土壌はできた（認知は広まった）ので、全員でメリットを体感できる 収穫期へ 15
16. © 2012-2026 BASE, Inc. SECTION 3 まとめ 16
17. © 2012-2026 BASE, Inc. 1 主要SLOを事業部全体の指標に 2 運⽤主体のエンジニアに裁量を 3 SLOの提案は誰でもできる  主要SLOとは 事業インパクトが強く、品質劣化が即座に収益‧UXに影響する指標群 SLMを “事業部全体で取り組む活動” にする 事業部定例で主要SLOを承認するフローを確⽴ ＝ 事業部の⽅針と接続する 同時に実施した エンジニア組織が運⽤を開始 ＝ サービスレベルを守る運⽤責任を現場に 全員がSLOを使いこなして次のフェーズへ エンジニア以外の組織がメリットを体感できる仕組み ＝ 誰でもSLOを起票したくなる エンジニアが運⽤に負担のかからない仕組み 同時に実施する ＝ 規模拡⼤に耐えうる体制を作る 17 まとめ