VTRyo Blog

一歩ずつ前に進むブログ

SRE Kaigi 2025 感想と 「一人から始めたSREチーム3年の歩み」のスライド補足

sre イベント 登壇

2025年1月26日に行われた、SRE NEXTに次ぐ国内2つ目のSRE向けカンファレンス。この記事はその感想と、登壇したスライドに対する文言補足です。

SRE Kaigi 2025は、「More SRE !」をテーマに開催される、SREを中心として知見の共有と参加者との交流を楽しむ技術カンファレンスです。

2025.srekaigi.net

SRE Kaigi 2025の感想

まずは関係者のみなさまお疲れ様でした。初回とは思えぬ練度と完成度、そして溢れるホスピタリティ。

初回とは思えぬ完成度でとても楽しかったです。その第一回の開催で登壇できたことを嬉しく思います。

何と言っても杉田智和氏に自分の名前を呼ばれるという、人生でも類を見ない思い出ができたことが最高でした。

指圧体験や屋台もよいなと思いました。すべてのセッションを聞くのは体力的に大変なので、最近は間をあけてゆっくりすることが増えたんですが、その時間の過ごし方としてGoodでした。休憩所的なものって他のカンファレンスではあまりないような？（正確に調べてないからわからないけど）

スポンサーブースにずっといるのも疲れるので、個人的には助かりました。

懇親会でも多くの方から登壇のフィードバックを頂き、とても嬉しいものでした。興味を持ってくださった方々ありがとうございます。

また、わざわざお声がけしていただいた方や、なんと7年ぶりにお会いした方、コロナを挟んでお久しぶりした方もいらっしゃいました。SRE界隈で遭遇するとは思っていない方もいましたので、この職業が広く受け入れられるようになったんだなと感慨深かったです。

SRE界隈の間口が広がることで多くのITエンジニアが関心を持ち、結果的にこの世界が良くなると信じています。

次回開催にも楽しみにしています！

スライドの補足

現地での発表は言葉で説明した部分を増やしていましたので、スライド以上の情報量がある部分を補足をします。

全体スライドはこちら。

2024年時点、マネーフォワードSREの前提です。一番左のPlatform and Reliability Engineering部が私たちが所属している部署。A部署特化SREとして配置されており、A部署のプロダクトを管掌しています。PlatformチームとプロダクトSREチームは明確に役割が異なります。

入社当初、私はA部署自体に所属していました。当時はPlatform and Reliability Engineering部は存在していておらず、それぞれの部署に配属されていました。
そこで私はまずプロダクトチームとともに過ごしながら、あくまでSRE因子を持ったSoftware Engineerとして行動していました。

SREとは何か・どういう役割なのか・これからチームにどんな良いことがあるかをエンジニアに限らず、デザイナーやプロダクトマネージャーといった関係者の方々に説明していました。機会を得たときはビジネスチームにもLTしたりしています。

手を付ける優先度は、基本的にこのサービスリライアビリティヒエラルキーを参照すれば大きく迷うことはないはずです。ただし、最初はみえていなかった問題が発生することはあります。 ロードマップを設定したものの、変更を余儀なくされるケースも実際にありました。SREチームとして確立されていれば計画を大きく変更しなくても対応できると思いますが、一人しかいない場合は柔軟に変更する余地を残しておいても良いと思っています。

ピラミッド一番下の、モニタリングから改善したときの資料を見てみます。 アラートをベストプラクティスに基づいて設計しなおし、Datadogのダッシュボードを整理したときの画像です。 プロダクト初期フェーズでモニタリングに中々時間が避けない部分であることも重々承知してます。「そろそろ精神に良いアラートを設定する時期だぜ」というだけですから、これまでプロダクトを守ってきた開発者への敬意は忘れないようにしましょう。 この情報があればメンバーはDatadogを見て自分たちのサービス状況をふりかえることができます。

同じ頃、ミッションやビジョンも作成していました。これは私自身もブレないために重要なアイテムですが、それ以上に早期で作成しておくとよいものです。採用広報にも利用できるし、チームメンバーにも説明することができます。

そして私が当時決めたミッションはこちらです。 私はアポロ誘導コンピュータを設計したマーガレットハミルトンの思想が好きで、彼女は歴史上最初のSREの役割を果たしたと言われています。 彼女の偉業をもとに、「SREという単語を知らなくともSRE活動ができるチームは強い」という考えを昇華してミッションとました。

blog.studysapuri.jp

採用活動が進み、このような形でプロダクトチームにEnabling活動を行うことができるようになりました。対象の数が増えたため、すべての会議に参加するEmbedded体制は難しくなったという理由もあります。 「プロダクトチームAはほかより進捗が出ているのでもっと深堀りした課題に取り組もう」「Bはこれから参加するから、しっかり土台固めていこう」といったグラデーションがついた取り組み方になっています。 ただ人数が少ないうちは、一人で一つ（場合によっては複数以上）のプロダクトを担当するという体制を取っていました。

事前に決めていたミッションは拡大期に役立ちます。ミッションは解決する課題の手段に一定の方向性を示してくれます。 ミッションが設定されていることで、成果物に変化が出るでしょう。

例えば、「Datadogを使ってサービスに異常がないかふりかえる」といったタスクをSREが巻き取ってレポートすることも可能です。しかし、私が設定したミッションは「ソフトウェアエンジニア自身がSRE活動できる」ことです。
巻き取るよりもプロダクトチームが運用できるように一緒に取り組んだり、委譲するためのドキュメントや土台を整えることを成果物とする方が良いかもしれません。

このように、ミッションがチームの方向性や意思決定に影響するので早いうちに設定するのをおすすめします。

チーム単位でEnabling活動するようになりました。

また、このタイミングで私はリーダーを交代しました。私の得意分野はどちらかというとカオスな状態を一気に整えるような環境です。私自身、リーダーは2,3年程度で変わったほうが良いと思っていました。
より大きな問題に高い専門性を持って対応できる人が参画してくれたことで、さらにパワーを出せるようになったのが大きいです。 ただし、ここまでメンバーが減っていないという現実があり、あまり汎用性のあるケースではないかもしれません。

文化は仕組みも含めて作らないと残らない可能性があります。
CI/CDが当たり前になった現代、ユニットテストがPassしないと次のステップに移行できません。それと同じように、何らかの仕組みがあることで自然とその活動ができるようになることが理想でしょう。

また、プロダクトチーム自身がSRE活動する世界などできるのか？とミッションを変えるか迷った瞬間がありました。 しかし最初に考えたミッションは、私は心から信じているものでした。なので、そこは変えずにどうやったらそれが達成できるのかを組織の形に合わせて考える方が今は良いと思っています。

それぞれのフェーズで活躍する傾向をかんたんにまとめました。すべての能力がある人は稀です。全部得意だという人は見たことがないです。身近な人が思い浮かんだという方はすごい環境にいるんじゃないでしょうか。仮にできるとしても、得意なパラメータには多少ばらつきがあると思います。

さて、あなたはどのフェーズが得意ですか？　どの特性がいいかという優劣はありません。その人が最高に輝くフェーズというのは実際にあると思います。

しかし、ここまでチームの歩みをみてきて、初めて私は気づいたことがあります。 私達のような違う特性を持った人は、互いに良い影響を与えられるのではないかということです。

図をつくってみました。互いが自分の良さを活かしてチームに貢献するイメージです。 実際に、私が活路を見出せた関係性でもあります。安定フェーズが得意なメンバーが持っていない斜め上のルートで解決することもあって、これが自信につながった思い出があります。

輝けるフェーズを知りその場を求めて移動することも選択肢としてありですが、自分が異質な存在としてチームにインパクトを与えられるかもしれないことも、忘れないようにしたいですね。