たくさんのSREにお悩み相談してきました!【SRE kaigi 2025ブース運営レポート】
はじめに
レバテック開発部、SREの金澤です!
レバテックでは先日のSRE kaigi 2025にてブースを出展させていただきました!
ご来場いただきました皆様ありがとうございました!
今回のブースは 「レバテックのSREの悩みにお知恵をお貸しください」 というテーマでしたが、たくさんの方にご意見やアドバイスをいただいたため、そのまとめ記事を書かせていただきます!
↓このように用意していたボードを埋め尽くすほどのアドバイスや共感コメントをいただきました!
お悩みNo1:SRE文化がなかなか浸透していかない...皆さんどはどうしていますか
全体的に
こちらの悩みについては、全体的に同じ悩みを抱えている方がとても多かった印象です。
粘り強くSREが何を実現したいのかを伝えていく必要があると改めて感じました。その手段として勉強会を行ったり、SREだけでなくCTOなどの上位レイヤーや技術広報と連携をして組織全体に納得感を持ってもらえるように努力する必要があると改めて実感しました!
コメント例
- CTOにSREの必要性を訴えて納得してもらい全社にプレゼンしてもらった
- プロダクトチームにEmbeddedのような形で飛び込んでイネイブリングする
- 各開発チームと定例MTGを組んでお互いのやりたいことや改善したいことを共有する
- 開発組織には納得してもらえてもビジネスサイドの理解が得られずSLOなどが進められない
印象深かったコメント
炎上させてみる
必要性を訴えた上で変わらなければ、SREがやっていることを事前に告知した上で一度やめることでどれだけ影響がでるかを実感してもらうという強めの意見もありました!
そこでSREの必要性を認識してもらえれば文化は広めやすくなるし、感じられなければSREがその組織には必要ないという判断も出来るのではないかということで、簡単にできることではないですが手段としては有効だと思いました。
SREやってみた
SREが開発チームに入り込んでいくというケースは多いかと思いますが、反対に開発チームからSREに入ってもらうという発想が自分たちにはなかったので新鮮でした。SREの活動の詳細や推進の難しさを知ってもらうことは文化の浸透への効果が期待できそうだと思いました。
お悩みNo2:SREのネクストキャリアはどんなものが考えられますか...?
全体的に
全体としては、CTOやPM、PdM、EMといったマネジメント系のコメントが多い印象でした!組織横断的に動くことの多いSREは自然とマネジメントによっていく傾向があるのかもしれません。若手の方などは改めて開発チームに戻って、SREでの経験を活かしたいという意見もありました!
コメント例
- CTO
- EM
- PdM
- SWE
- ソフトウェアエンジニア
- 研究
印象深かったコメント
CTO
SREをやっていく上で、アプリケーション、インフラ、サイト信頼性など幅広い領域や視座が付きやすいのでCTOも選択肢として挙がってくるという意見がありました。
研究
SREから、AI×SREの領域での研究をする立場に変わったという方がいらっしゃいました!SREという領域はまだまだ明確な答えが無い領域だと今回のイベントで実感しました。SREというもの自体を深ぼるというネクストキャリアも非常に面白いと感じました。
眼の前の仕事を頑張れ!
SREとして課題がいっぱいあるのに次のことを考えてどうするんだ!という至極真っ当なご意見も頂きました!間違いないと思いました(笑)
お悩みNo3:コストの妥当性はどう判断すればいい?
全体的に
コストについては妥当な金額の決定に皆さん困っていることが改めてわかりました。ARR(年間経常収益)の4%以下など明確な基準を設けている企業もあれば、定例でコストの増減を開発チームと一緒に確認していくなど、実績ベースで判断するケースが多いことがわかりました。実績ベースで判断している企業も本音ではちゃんと基準を設けたいという声が多かった印象です。
コメント例
- ARRの4%以下、2.4%以下
- ビジネスメトリクスとのROIで判断
- 新技術を採用することでコストが減らせた
- 月次でコストの変化を確認し、開発チームとのMTGで妥当性を確認している
- AWSのTAMを利用して月1でレビュしてもらっている
印象深かったコメント
経営層もエンジニアも妥当なコストがわかってないから誰も判断できない
経営層はクラウドの事を理解できていない、エンジニアは経営のことを理解できていないという状況だと、どちらもサービスを実現するための妥当なコストを判断できないという意見がありました。人件費などシステム以外の費用や売上、利益といったものと合わせて判断されるものであるため、明確な基準がなくとも、現時点での状態については認識を揃える必要があると改めて実感しました。
円安
リソースは増やしてないのに勝手にコストが上がるという状況に苦しんでいる人が多いことがわかりました。(弊社も同じです)
もう減らせるものがないといった意見や、国産のクラウドに移行するにしても、作業コストや機能面で決定しにくいという意見がありました。工夫や取り組みがあれば引き続きアドバイスを頂きたいです!
お悩みNo4:どこまでがSREの仕事なのか、スコープがはっきりしてない...
全体的に
システムの信頼性に関わるものは全部やるというポジティブな理由を元にスコープを決めないという人もいれば、スコープが分からないが故に出来そうな事は全部やるという若干ネガティブな理由でなんでもやってしまっているという意見も多かったです。弊社としては無理にスコープを決めようとしていたけど、今まで通り必要な事は全てやるということが悪い事ではないと他社のSREの方との交流を通じて実感することができました。
コメント例
- 開発チームとSRE間の責務の境界が難しい
- 信頼性に関わるものは全てやる
- 優先順位をつけて何をするかの判断する
印象深かったコメント
スコープを決めるのがSREの仕事
SRE側で今注力していることへの理由や意味を十分に共有した上で、開発チームと同意が取れていれば明確にしなくともスコープは決まってくるのかなと思いました。
スコープが定まっていないということは、ある意味SREが今一番実現したいことが十分に伝わっていないという可能性もあるのかと思いました。
それぞれの企業でSREという職能への評価基準をもてばはっきりする
明確な評価基準を設定することで、SREの責任範囲や成果物が具体的になるという意見もありました。少なくとも上位レイヤーとSREの間の期待値のズレを防ぐことには効果がありそうだと思いました。
お悩みNo5:最近実現した自動化の事例が知りたい...!
全体的に
セキュリティ通知やデプロイ、テストといったシステムのプロセスの自動化に取り組んでいる企業が多かったですが、ドキュメント生成や人の業務プロセスの監視といった開発以外の業務に対する自動化を行なっている企業も存在しました。
これらの取り組みはSREとは別にプラットフォームチームで行なっている企業もありましたが、大半がSREがプラットフォームの構築も担っている事が多いという事がわかりました。
コメント例
- SLO定義をyamlで定義してドキュメント生成を自動化した
- DBのマイグレーションやデプロイをCI/CDで自動化した
- SecurityHubの対応状況を通知させる
- 正しいレビュープロセスに則っていない場合にアラートを通知する
印象深かったコメント
正しいレビュープロセスに則っていない場合にアラートを通知する
自動化というと開発プロセスに対する事例が多い印象でしたが、障害発生の抑制のためにも人の業務プロセスの監視といった観点での自動化も重要だなと思いました。程度によっては賛否あるかもしれませんが、弊社でもできることがないか考えたいと思います。
お悩みNo6:インシデント発生時にSREはどんな振る舞いが求められますか?
全体的に
チームに障害対応時に積極的に関わる企業もあれば、ポストモーテムや事例の横展開など再発防止の部分に注力して関わる企業も存在しました。
開発チームがどれだけ自立してシステムを運用できるかによって関わり方も変わるため、明確な線引きをするのではなく、柔軟に対応できる体制は取らないといけないと思いました。
弊社ではインシデント発生時に必要な情報が見られる環境をより整備して、開発チームが独立して対応できる領域を増やしSREが関与せずに解決できる体制を作っていきたいと考えてます。
コメント例
- メトリクスを元に情報を提示して調査や原因特定に協力する
- ポストモーテムを推進してビジネスサイドに共有する
- できることはなんでもやる
- 障害対応のオーナーシップを持つ
印象深かったコメント
冷静に対応できるように声を掛ける
障害が実際に発生しているチームのエンジニアなど当事者だと心理的に焦ってしまうことが大いにあると思います。SREが一歩離れたところから、当事者が焦らないように声掛けをして、意見や情報の収集、提供を行うことが重要だと気付かされたコメントでした。
最後に
皆様からいただいたアドバイスを参考に引き続きレバテックのSREとして課題に向き合っていきます!
本テックブログでその様子を改めてお伝えできたらと思っています。
改めてたくさんのアドバイスありがとうございました!!
Discussion