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

by HIGUCHI.Takashi

Slide 1

Slide 1 text

Slide 2

Slide 2 text

樋口貴志（ひぐちたかし）株式会社SmartHR / SRE ・北海道に住んでます・夏だけバイク乗ってます（ SR400） @super_takashi_o 2 ⾃⼰紹介

Slide 3

Slide 3 text

認知負荷とは⼈間が情報を処理‧理解する際に、脳（ワーキングメモリ）にかかる精神的な負担の⼤きさ 3

Slide 4

Slide 4 text

アジェンダ 1. SmartHRの事業と開発組織体制 2. SmartHRのSREの役割と歩き⽅ 3. ⾼品質かつ効率的なオブザーバビリティの実現 4. 少⼈数のSREチームによる全チームへの SLO導⼊ 5. さいごに

Slide 5

Slide 5 text

Slide 6

Slide 6 text

SmartHRの事業 6

Slide 7

Slide 7 text

7 ⽬指す先

Slide 8

Slide 8 text

信頼性とアジリティの両⽴が不可⽋ ※アジリティ（Agility）：変化に対応し、価値（新機能や改善）を素早くユーザーに届ける能力 8 社会インフラ企業になるには‧‧‧

Slide 9

Slide 9 text

9 新機能開発を避けたり、リリースの頻度を下げる … 信頼性 ↑↑↑ アジリティ ↓↓↓ 頻繁な新機能開発やリリース … 信頼性↓↓↓ アジリティ↑↑↑ トレードオフだが、なんとか両⽴させたい！ SREがその責務を担う！！信頼性とアジリティの関係

Slide 10

Slide 10 text

給与計算機能勤怠機能組織図機能 ‧ ‧ ‧ Dev Team A Dev Team B Dev Team C 従業員サーベイ機能約４０チーム約２００名 ‧ ‧ ‧ 10 開発組織体制

Slide 11

Slide 11 text

給与計算機能勤怠機能組織図機能 Dev Team A Dev Team B Dev Team C 従業員サーベイ機能 SRE Team ４名 Enabling 11 約４０チーム約２００名 SREの⽴ち位置

Slide 12

Slide 12 text

12 ● 信頼性を上げるために、オブザーバビリティとSLOの導⼊を⾏いたい ● しかし、新しい仕組みを何も考えず導⼊すると、開発チームの認知負荷が上がり、アジリティが下がってしまう ● とはいえ、認知負荷を下げるためにEmbeddedできるほど SRE⼈数もいない課題感

Slide 13

Slide 13 text

少⼈数のSREが、認知負荷を最⼩化しながらオブザーバビリティとSLOの導⼊にChallenge！ 13 今回のテーマ

Slide 14

Slide 14 text

Slide 15

Slide 15 text

「SRE」の役割の定義は組織によって違う期待値が⼈によって異なる SREの役割とはインフラ全般の管理運営？運⽤業務の⾃動化？開発チームの⼀員として⼊ってくれる？ 15

Slide 16

Slide 16 text

SmartHRのSREが本当にやりたいこと期待値ズレ（期待過剰）があったまま進むと‧‧‧ １つのチームへの対応⼯数でSRE４名のリソースを使い切ってしまい、横断的な活動ができない可能性がある本当にやりたいのは、「SmartHR」の信頼性とアジリティの両⽴ 16

Slide 17

Slide 17 text

SREチームとプロダクト開発チームの責任分界点の明確化 17

Slide 18

Slide 18 text

● SRE ○ SLO計測の仕組みを提供 ■ SaaS×APMを活⽤して計測及び運⽤環境を提供 ○ SLO振り返り会の参加‧助⾔ ● 開発チーム ○ SLO⽬標値の策定 ○ SLO運⽤ ■ 定期的な振り返り会の実施 ■ 違反時の信頼性改善活動⽂書化して全社展開して期待値を調整 18 責任分界点の明確化 ※SLOに絞って⼀部抜粋

Slide 19

Slide 19 text

SREの役割を整理し、チーム全体への貢献をする準備が整ったしかし、何をすればよい‧‧‧？４名という少⼈数で「やれること」をやるのではなく、「やるべきこと」をやりたい 19 「SmartHR」の信頼性とアジリティの両⽴のために

Slide 20

Slide 20 text

SRE ロードマップの策定 20

Slide 21

Slide 21 text

SmartHRの事業計画各領域の中⻑期事業戦略計画通りに進められるように、 SREは、「信頼性とアジリティの両⽴」という観点で貢献したい → しかし、⽬の前の問題ばかり解決していては中⻑期的な事業貢献はできない 21 なぜロードマップが必要？

Slide 22

Slide 22 text

キャパシティプランニング負荷試験の計画‧実⾏⾼トラフィックでも変わらず快適に使える状態？？？？？⼀部メソッドの速度改善ロードマップがある場合ロードマップがない場合クラウドの新サービス検証トップページのエラー率計測事業計画 n千⼈規模のお客様へのサービス提供をする「”SmartHR”の信頼性は上がった？」という問いに答えられるのか？ 22 事業計画から逆算して考える

Slide 23

Slide 23 text

とはいえ、やるべきこと（GOAL）はたくさんある CCCCCCCC AAAAAAAAA DDDDDDDD 業務効率化スクリプト実⾏基盤が整備されている⾼トラフィックでも変わらず快適に使える状態になっているインフラコストが最適化されている SLO運⽤出来ているチームがnチームを超える 23 優先順位を決める 4名ですべてを網羅するのは不可能。どうしようか‧‧‧ → RICEスコアで順位付けして実施可否＆優先順位を整理

Slide 24

Slide 24 text

RICEスコアとは... 評価フレームワークの１つ Reach（到達範囲） Impact（影響度） Conﬁdence（確信度） Eﬀort（⼯数/労⼒） 24 RICEスコアの紹介 R × I × C ÷ Eの計算式で算出されるスコアを最終的なRICEスコアとする

Slide 25

Slide 25 text

スコア基準 5 ほぼ全チーム 4 70%くらいのチーム 3 50%くらいのチーム 2 30%くらいのチーム 1 10%くらいのチーム例）Reach（到達範囲）の基準を定義 25 RICEスコアの基準例

Slide 26

Slide 26 text

スコア 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スコアによって整理された「やるべきこと」

Slide 27

Slide 27 text

少⼈数のチームであるがゆえに、「取捨選択」、「優先度」をあるべき状態から逆算して明確にすることが⼤切 27 まとめ

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 SaaS（New Relic）を活⽤し、APM×ServiceLevels機能でSLO運⽤をしている SmartHRのオブザーバビリティ基盤

Slide 30

Slide 30 text

現在16チームがオブザーバビリティSaaSを活⽤してSLO運⽤している状態 SLO導⼊はうまくいっているものの、運⽤フェーズでは分析対応にブレがあった 30 SLO運⽤の課題

Slide 31

Slide 31 text

SLO振り返り会にて ● チームA ○ 直近のレイテンシやトレース情報を⾒て傾向を確認 ● チームB ○ 直近のレイテンシがどの画⾯から⾒られるのわからず、分析があまり出来ず次週持ち越し 31 例

Slide 32

Slide 32 text

32 開発チーム１つ１つにオブザーバビリティSaaSの使い⽅を Enablingするには、⼈数が⾜りない → ソフトウェアエンジニアリングによってこの課題を解決！少⼈数SREであるがゆえの制約

Slide 33

Slide 33 text

カスタムダッシュボード ×IaC 33

Slide 34

Slide 34 text

34 SLO違反時に原因を分析できるダッシュボードの設計

Slide 35

Slide 35 text

⽬標値に対してどのくらい離れている？残りのエラーバジェットは？ 35 ⽬標値の可視化ウィジェット

Slide 36

Slide 36 text

レイテンシ低下は継続的？突発的？いつから悪化？⽬標に対してどのくらい悪化？ 36 傾向分析⽤のウィジェット

Slide 37

Slide 37 text

37 分析⼿順ウィジェット

Slide 38

Slide 38 text

Slide 39

Slide 39 text

39 得られる効果 ● 分析⼿順が明確になっているため、限られた時間の中で傾向が把握しやすい ● 開発チームはオブザーバビリティSaaSを熟知していなくても傾向分析ができるので、認知負荷を低く保ったままSLO運⽤ができる

Slide 40

Slide 40 text

40 今後 ● 汎⽤的な項⽬だけではなく、プロダクト特性に合わせた分析ができるようにしていく ○ 例）年末調整：提出書類の数と処理時間の相関など

Slide 41

Slide 41 text

41 開発チームへ展開ダッシュボードは設計できた。しかし‧‧‧ SREが各チームを回ってダッシュボード設定をするには時間も⼈数も⾜りないし運⽤も⼤変効率よく展開するため、Terraformを使⽤してIaC化

Slide 42

Slide 42 text

IaC化したコードを全チームが使⽤できる共通モジュール化して提供し、初期構築を数分でできるようにチームAのダッシュボード.tf ダッシュボード共通モジュール ● SLO Targetウィジェット ● Error budgetウィジェット ● Latency Graph ウィジェットチームBのダッシュボード.tf 42 Terraform設計：共通モジュール化

Slide 43

Slide 43 text

43 得られる効果 ● 開発チームは共通モジュールを呼び出すだけでよいので、 Terraformへの認知負荷が低いままダッシュボードを導⼊できる ● 共通モジュール化したことにより、変更を素早く各チームに反映できる

Slide 44

Slide 44 text

44 今後 ● まだ⼀部のチームに導⼊している段階なので、これから効果を実証していく

Slide 45

Slide 45 text

Slide 46

Slide 46 text

SmartHRではSLI∕SLOを導⼊するにあたり、CUJを基本軸とした設計を⾏っている CUJ(クリティカルユーザージャーニー)とはユーザージャーニーの中でも、これができることがそのアプリの⽬的だと⾔えるようなものをCUJ(クリティカルユーザージャーニー)と呼ぶ 46 CUJを基本としたSLI∕SLO

Slide 47

Slide 47 text

● ⼈事評価機能 ○ 管理者が評価を設定する ○ 被評価者が評価を⼊⼒する → それぞれにとって重要なAPIと設定すべきSLOは別のものになる 47 CUJの例

Slide 48

Slide 48 text

とはいえ、開発チームにいきなりCUJを考えてSLI∕SLOに落とし込んで運⽤してもらうのは難しい少⼈数ゆえに１つ１つのチームにEnablingも難しいユーザージャーニーはいくつか思いつくけど、どれがCUJなんだろう‧‧‧ SLOのしきい値ってどのくらいにするのがいいんだろう‧‧‧ SLI∕SLOってそもそもなんだろう‧‧‧ 48 課題感

Slide 49

Slide 49 text

「SLO導入ガイド」を作ってハードルを低くする！ 49

Slide 50

Slide 50 text

50 「SLO導⼊ガイド」内容 ● SLI∕SLOとは？ ● CUJを軸としたSLI∕SLO設計⽅法 ● CUJからSLI∕SLOを導き出すためのワークショップ ● オブザーバビリティ基盤へのSLO設定⼿順 ● SLO違反時の考え⽅

Slide 51

Slide 51 text

51 「SLO導⼊ガイド」内容 ● SLI∕SLOとは？ ● CUJを軸としたSLI∕SLO設計⽅法 ● CUJからSLI∕SLOを導き出すためのワークショップ ● オブザーバビリティ基盤へのSLO設定⼿順 ● SLO違反時の考え⽅

Slide 52

Slide 52 text

52 ワークショップの⽬的 SLI∕SLOの導⼊におけるハードルを下げて⼩さく運⽤を始められるようにする

Slide 53

Slide 53 text

53 ワークショップの構成 ● （別紙）ワークショップの実施⽅法 ● プロダクトの価値と登場⼈物の整理 ● CUJ候補洗い出し ● CUJで通るタスクの洗い出し ● CUJで使⽤するAPI ● SLOのしきい値決め

Slide 54

Slide 54 text

54 実施⽅法抜粋

Slide 55

Slide 55 text

55 STEP1

Slide 56

Slide 56 text

56 STEP2

Slide 57

Slide 57 text

57 STEP3

Slide 58

Slide 58 text

58 STEP4

Slide 59

Slide 59 text

59 STEP5

Slide 60

Slide 60 text

Point ● 画⾯やAPIからユーザジャーニーを考えるのではなく、ユーザジャーニー（顧客の価値）からクリティカルなAPIを考える ● エンジニアだけではなく、PMなども参加し多⾓的な視点で議論する 60

Slide 61

Slide 61 text

● ワークショップの⼿順を⽤意することで、SLOの前提知識‧ 経験がない状態でもCUJを考えてSLOを導⼊することができる ○ つまり、SLOに対する認知負荷が低いまま導⼊できる 61 得られる効果

Slide 62

Slide 62 text

● 継続して信頼性向上ができるようにEnablingする ○ 例）しきい値の全社的な標準を整備し、信頼性の基準を底上げするなど 62 今後

Slide 63

Slide 63 text

→ 少⼈数ではチーム１つ１つの状況を追えない Dev Team A Dev Team B Dev Team C ‧ ‧ ‧ Dev Team Z SRE Team ● SLI∕SLO定義できましたか？ ● 次なにを⽬指すかわかりますか？ ● 適時しきい値の調整できてますか？ 63 SLO運⽤の課題

Slide 64

Slide 64 text

共通言語「 SLO星取表」による方向性の統一と進捗の可視化 64

Slide 65

Slide 65 text

SLO星取表の抜粋 65 チームを⾏、成熟レベルを列とした表。成熟レベルはエンジニアではない⼈にもわかるような表現で共通⾔語として機能する形に

Slide 66

Slide 66 text

● 開発チーム ○ SLO振り返り会の最後に⾒直して次に⾏うべき⾏動を把握する ○ 進捗をPM等と共有し、開発計画の中に信頼性投資の⼯数を⼊れる ● SREチーム ○ 進捗が少ないチームにはSREが積極的に関わる 66 SLO星取表の使い⽅例

Slide 67

Slide 67 text

● 進捗が可視化されたことで、少⼈数のSREでも的確なフォローができるようになる ● 開発チームが次に何をするべきかが明確になっているため、 SLOに対する認知負荷が下がった状態で運⽤できる ● 共通⾔語化したことで、PM等のプロダクトのステークホルダとも会話が可能となり、信頼性投資の判断が正しく⾏える場⾯が増える 67 得られる効果

Slide 68

Slide 68 text

● 信頼性投資の判断が正しく⾏えた事例をさらに増やすため、 SREが積極的に⼲渉して開発エンジニア⇔ステークホルダの会話を促す 68 今後

Slide 69

Slide 69 text

Slide 70

Slide 70 text

今回お話したようなアプローチで活動を⾏うことで、少ない⼈数でも⼗分にレバレッジの効いたSRE活動を⾏うことができる …とはいえ、信頼性の⼟台はまだ出来たばかり。さらに発展し進化し続ける様⼦をテックブログにてご紹介していきますので、是⾮ご覧ください！！ 70 少⼈数SREでもできること

Slide 71

Slide 71 text

開発チームの認知負荷を最⼩限に抑えながら情報や仕組みを展開していくことが⼤切！ 71 多くのチームにオブザーバビリィやSLO導⼊するには

Slide 72

Slide 72 text

今回具体的な施策をいくつかご紹介したので、是⾮実践してみてください！！！ 72

Slide 73

Slide 73 text

ご清聴ありがとうございました! この後はAsk the Speakerコーナーで質疑応答後、SmartHRスポンサーブースにおりますので、是⾮お越しください！ 73