【SRE Kaigi 2026】認知負荷を最小化するオブザーバビリティとSLOの導入 ―4名SREが200名のコードエンジニアを支援

SRE Kaigi 2026で登壇した内容です

Transcript

1. © SmartHR, Inc. 認知負荷を最⼩化するオブザーバビリティと SLOの導⼊ ―4名のSREが200名のプロダクト エンジニアを⽀援 樋⼝ 貴志 株式会社SmartHR / SRE 2026/01/31
2. 樋口 貴志（ひぐち たかし） 株式会社SmartHR / SRE ・北海道に住んでます ・夏だけバイク乗ってます（ SR400） @super_takashi_o 2 ⾃⼰紹介
3. 認知負荷とは ⼈間が情報を処理‧理解する際に、 脳（ワーキングメモリ）にかかる精神的な負担の⼤きさ 3
4. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
5. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
6. SmartHRの事業 6
7. 7 ⽬指す先
8. 信頼性とアジリティの両⽴が不可⽋ ※アジリティ（Agility）：変化に対応し、価値（新機能や改善）を素早くユー ザーに届ける能力 8 社会インフラ企業になるには‧‧‧
9. 9 新機能開発を避けたり、リリースの頻度を下げる  … 信頼性 ↑↑↑  アジリティ ↓↓↓ 頻繁な新機能開発やリリース  … 信頼性↓↓↓  アジリティ↑↑↑ トレードオフだが、なんとか両⽴させたい！ SREがその責務を担う！！ 信頼性とアジリティの関係
10. 給与計算機能 勤怠機能 組織図機能 ‧ ‧ ‧ Dev Team A Dev Team B Dev Team C 従業員サーベイ機能 約４０チーム 約２００名 ‧ ‧ ‧ 10 開発組織体制
11. 給与計算機能 勤怠機能 組織図機能 Dev Team A Dev Team B Dev Team C 従業員サーベイ機能 SRE Team ４名 Enabling 11 約４０チーム 約２００名 SREの⽴ち位置
12. 12 • 信頼性を上げるために、オブザーバビリティとSLOの導⼊を ⾏いたい • しかし、新しい仕組みを何も考えず導⼊すると、開発チーム の認知負荷が上がり、アジリティが下がってしまう • とはいえ、認知負荷を下げるためにEmbeddedできるほど SRE⼈数もいない 課題感
13. 少⼈数のSREが、認知負荷を最⼩化しながら オブザーバビリティとSLOの導⼊にChallenge！ 13 今回のテーマ
14. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
15. 「SRE」の役割の定義は組織によって違う 期待値が⼈によって異なる SREの役割とは インフラ全般の 管理運営？ 運⽤業務の ⾃動化？ 開発チームの ⼀員として ⼊ってくれる？ 15
16. SmartHRのSREが本当にやりたいこと 期待値ズレ（期待過剰）があったまま進むと‧‧‧ １つのチームへの対応⼯数でSRE４名のリソースを使い切ってし まい、横断的な活動ができない可能性がある 本当にやりたいのは、 「SmartHR」の信頼性とアジリティの両⽴ 16
17. SREチームとプロダクト開発チー ムの責任分界点の明確化 17
18. • SRE ◦ SLO計測の仕組みを提供 ▪ SaaS×APMを活⽤して計測及び 運⽤環境を提供 ◦ SLO振り返り会の参加‧助⾔ • 開発チーム ◦ SLO⽬標値の策定 ◦ SLO運⽤ ▪ 定期的な振り返り会の実施 ▪ 違反時の信頼性改善活動 ⽂書化して全社展開 して期待値を調整 18 責任分界点の明確化 ※SLOに絞って⼀部抜粋
19. SREの役割を整理し、チーム全体への貢献をする準備が整った しかし、何をすればよい‧‧‧？ ４名という少⼈数で「やれること」をやるのではなく、 「やるべきこと」をやりたい 19 「SmartHR」の信頼性とアジリティの両⽴のために
20. SRE ロードマップの策定 20
21. SmartHRの事業計画 各領域の中⻑期事業戦略 計画通りに進められるように、 SREは、「信頼性とアジリティの両⽴」 という観点で貢献したい → しかし、⽬の前の問題ば かり解決していては中⻑期的 な事業貢献はできない 21 なぜロードマップが必要？
22. キャパシティプランニング 負荷試験の計画‧実⾏ ⾼トラフィックでも 変わらず快適に使える状態 ？？？？？ ⼀部メソッドの 速度改善 ロードマップがある場合 ロードマップがない場合 クラウドの 新サービス検証 トップページの エラー率計測 事業計画 n千⼈規模のお客様へのサービス提供をする 「”SmartHR”の信頼性は上がった？」 という問いに答えられるのか？ 22 事業計画から逆算して考える
23. とはいえ、やるべきこと（GOAL）はたくさんある CCCCCCCC AAAAAAAAA DDDDDDDD 業務効率化スクリプト 実⾏基盤が整備されている ⾼トラフィックでも 変わらず快適に使える状態になっている インフラコストが最適化されている SLO運⽤出来ているチームがnチームを超える 23 優先順位を決める 4名ですべてを網羅するのは不可能。どうしようか‧‧‧ → RICEスコアで順位付けして実施可否＆優先順位を整理
24. RICEスコアとは... 評価フレームワークの１つ Reach（到達範囲） Impact（影響度） Confidence（確信度） Effort（⼯数/労⼒） 24 RICEスコアの紹介 R × I × C ÷ Eの計算式で算出さ れるスコアを最終的なRICEスコ アとする
25. スコア 基準 5 ほぼ全チーム 4 70%くらいのチーム 3 50%くらいのチーム 2 30%くらいのチーム 1 10%くらいのチーム 例）Reach（到達範囲）の基準を定義 25 RICEスコアの基準例
26. スコア Reach Impact Confidenc e Effort RICE 実施可否 ⾼トラフィックでも 変わらず快適に使える 状態にする 5 5 3 3 25 やる SLO運⽤が出来ている チームを更に広げる 3 5 3 4 11.25 やる インフラコストを 最適化する 4 3 2 3 8 やる 業務効率化スクリプト 実⾏基盤を整備する 2 1 4 3 2.7 やらない スコアが低いものはDrop 26 RICEスコアによって整理された「やるべきこと」
27. 少⼈数のチームであるがゆえに、 「取捨選択」、「優先度」を あるべき状態から逆算して明確にすることが⼤切 27 まとめ
28. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
29. 29 SaaS（New Relic）を活⽤し、APM×ServiceLevels機能でSLO運 ⽤をしている SmartHRのオブザーバビリティ基盤
30. 現在16チームがオブザーバビリティSaaSを活⽤してSLO運⽤して いる状態 SLO導⼊はうまくいっているものの、運⽤フェーズでは分析対応 にブレがあった 30 SLO運⽤の課題
31. SLO振り返り会にて • チームA ◦ 直近のレイテンシやトレース情報を⾒て傾向を確認 • チームB ◦ 直近のレイテンシがどの画⾯から⾒られるのわからず、分 析があまり出来ず次週持ち越し 31 例
32. 32 開発チーム１つ１つにオブザーバビリティSaaSの使い⽅を Enablingするには、⼈数が⾜りない → ソフトウェアエンジニアリングによってこの課題を解決！ 少⼈数SREであるがゆえの制約
33. カスタムダッシュボード ×IaC 33
34. 34 SLO違反時に原因を分析できるダッシュボードの設計
35. ⽬標値に対してどのくらい離れている？ 残りのエラー バジェットは？ 35 ⽬標値の可視化ウィジェット
36. レイテンシ低下は継続的？突発的？ いつから悪化？ ⽬標に対して どのくらい悪化？ 36 傾向分析⽤のウィジェット
37. 37 分析⼿順ウィジェット
39. 39 得られる効果 • 分析⼿順が明確になっているため、限られた時間の中で傾向 が把握しやすい • 開発チームはオブザーバビリティSaaSを熟知していなくても 傾向分析ができるので、認知負荷を低く保ったままSLO運⽤ ができる
40. 40 今後 • 汎⽤的な項⽬だけではなく、プロダクト特性に合わせた分析 ができるようにしていく ◦ 例）年末調整：提出書類の数と処理時間の相関 など
41. 41 開発チームへ展開 ダッシュボードは設計できた。しかし‧‧‧ SREが各チームを回ってダッシュボード設定をするには時間も⼈ 数も⾜りないし運⽤も⼤変 効率よく展開するため、Terraformを使⽤してIaC化
42. IaC化したコードを全チームが使⽤できる共通モジュール化して提 供し、初期構築を数分でできるように チームAのダッシュボード.tf ダッシュボード共通モジュール • SLO Targetウィジェット • Error budgetウィジェット • Latency Graph ウィジェット チームBのダッシュボード.tf 42 Terraform設計：共通モジュール化
43. 43 得られる効果 • 開発チームは共通モジュールを呼び出すだけでよいので、 Terraformへの認知負荷が低いままダッシュボードを導⼊で きる • 共通モジュール化したことにより、変更を素早く各チームに 反映できる
44. 44 今後 • まだ⼀部のチームに導⼊している段階なので、これから効果 を実証していく
45. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
46. SmartHRではSLI∕SLOを導⼊するにあたり、CUJを基本軸とした 設計を⾏っている CUJ(クリティカルユーザージャーニー)とは ユーザージャーニーの中でも、これができることがそのアプリの ⽬的だと⾔えるようなものをCUJ(クリティカルユーザージャー ニー)と呼ぶ 46 CUJを基本としたSLI∕SLO
47. • ⼈事評価機能 ◦ 管理者が評価を設定する ◦ 被評価者が評価を⼊⼒する → それぞれにとって重要なAPIと設定すべきSLOは別のものに なる 47 CUJの例
48. とはいえ、開発チームにいきなりCUJを考えてSLI∕SLOに落とし 込んで運⽤してもらうのは難しい 少⼈数ゆえに１つ１つのチームにEnablingも難しい ユーザージャーニー はいくつか思いつく けど、どれがCUJな んだろう‧‧‧ SLOのしきい値っ てどのくらいにす るのがいいんだろ う‧‧‧ SLI∕SLOって そもそもなん だろう‧‧‧ 48 課題感
49. 「SLO導入ガイド」を作ってハード ルを低くする！ 49
50. 50 「SLO導⼊ガイド」内容 • SLI∕SLOとは？ • CUJを軸としたSLI∕SLO設計⽅法 • CUJからSLI∕SLOを導き出すためのワークショップ • オブザーバビリティ基盤へのSLO設定⼿順 • SLO違反時の考え⽅
51. 51 「SLO導⼊ガイド」内容 • SLI∕SLOとは？ • CUJを軸としたSLI∕SLO設計⽅法 • CUJからSLI∕SLOを導き出すためのワークショップ • オブザーバビリティ基盤へのSLO設定⼿順 • SLO違反時の考え⽅
52. 52 ワークショップの⽬的 SLI∕SLOの導⼊におけるハードルを下げて ⼩さく運⽤を始められるようにする
53. 53 ワークショップの構成 • （別紙）ワークショップの実施⽅法 • プロダクトの価値と登場⼈物の整理 • CUJ候補洗い出し • CUJで通るタスクの洗い出し • CUJで使⽤するAPI • SLOのしきい値決め
54. 54 実施⽅法抜粋
55. 55 STEP1
56. 56 STEP2
57. 57 STEP3
58. 58 STEP4
59. 59 STEP5
60. Point • 画⾯やAPIからユーザジャーニーを考えるのではなく、ユーザ ジャーニー（顧客の価値）からクリティカルなAPIを考える • エンジニアだけではなく、PMなども参加し多⾓的な視点で議 論する 60
61. • ワークショップの⼿順を⽤意することで、SLOの前提知識‧ 経験がない状態でもCUJを考えてSLOを導⼊することができる ◦ つまり、SLOに対する認知負荷が低いまま導⼊できる 61 得られる効果
62. • 継続して信頼性向上ができるようにEnablingする ◦ 例）しきい値の全社的な標準を整備し、信頼性の基準を底 上げするなど 62 今後
63. → 少⼈数ではチーム１つ１つの状況を追えない Dev Team A Dev Team B Dev Team C ‧ ‧ ‧ Dev Team Z SRE Team • SLI∕SLO定義できましたか？ • 次なにを⽬指すかわかりますか？ • 適時しきい値の調整できてますか？ 63 SLO運⽤の課題
64. 共通言語「 SLO星取表」 による方向性の統一と 進捗の可視化 64
65. SLO星取表の抜粋 65 チームを⾏、成熟レベルを列とした表。成熟レベルはエンジニア ではない⼈にもわかるような表現で共通⾔語として機能する形に
66. • 開発チーム ◦ SLO振り返り会の最後に⾒直して次に⾏うべき⾏動を把握 する ◦ 進捗をPM等と共有し、開発計画の中に信頼性投資の⼯数 を⼊れる • SREチーム ◦ 進捗が少ないチームにはSREが積極的に関わる 66 SLO星取表の使い⽅例
67. • 進捗が可視化されたことで、少⼈数のSREでも的確なフォ ローができるようになる • 開発チームが次に何をするべきかが明確になっているため、 SLOに対する認知負荷が下がった状態で運⽤できる • 共通⾔語化したことで、PM等のプロダクトのステークホルダ とも会話が可能となり、信頼性投資の判断が正しく⾏える場 ⾯が増える 67 得られる効果
68. • 信頼性投資の判断が正しく⾏えた事例をさらに増やすため、 SREが積極的に⼲渉して開発エンジニア⇔ステークホルダの 会話を促す 68 今後
69. アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティ の実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに
70. 今回お話したようなアプローチで活動を⾏うことで、少ない⼈数 でも⼗分にレバレッジの効いたSRE活動を⾏うことができる …とはいえ、信頼性の⼟台はまだ出来たばかり。さらに発展し進 化し続ける様⼦をテックブログにてご紹介していきますので、是 ⾮ご覧ください！！ 70 少⼈数SREでもできること
71. 開発チームの認知負荷を最⼩限に抑えながら 情報や仕組みを展開していくことが⼤切！ 71 多くのチームにオブザーバビリィやSLO導⼊するには
72. 今回具体的な施策をいくつかご紹 介したので、是⾮実践してみてく ださい！！！ 72
73. ご清聴ありがとうございました! この後はAsk the Speakerコー ナーで質疑応答後、SmartHRス ポンサーブースにおりますので、 是⾮お越しください！ 73