挨拶
クラシルのレシチャレチームでは、2025年の2月にSREをチーム化しています。今年は社員2 ~ 3名 + インターン生1名という体制でした。
レシチャレアプリはリリース後2年間ほどは、SREのロールを持ったメンバーを1名配置する、という形を取っていて、SREという概念はありつつもチームとして存在しているわけではありませんでした。今年はチーム拡大や分割、サービスや基盤の複雑化に伴い、SREをチーム化するに至りました。
忙しい日々の中で、雑でも書かないよりは書いたほうがいいだろう！ということで、少し荒いですが今年SREチームの振り返りを書きます。
🎅 2025年にやったこと 🎅
⚙️ フルサイクル開発体制の推進 ⚙️
今年の前半は特に、フルサイクル開発体制推進としてその制度や仕組みづくりに注力しました。
後半は、Enabling SREとしてチームで仕組みの浸透を頑張っていました。
課題感
この取り組みをはじめた課題感として、サービスの拡大や複雑化に対してSREチームの増員が追いつかないことがありました。そこを見据えてフルサイクル開発体制を早くから実践しようとしていましたが、仕組みもなく、チーム拡大によってその文化が薄まってしまってしまい、結局SREロールを持つメンバーがシステム運用や信頼性の担保で手を動かすという状態になっていました。
そうしているうちに、ID基盤やコイン基盤などの基盤系の運用も増え、事業展開スピードも速く今年は新規の派生事業が2件立ち上がり、ゲーム事業の展開も始まりました。そんな中、SREチームがボトルネックになる状況でした。
詳しくはこちらにも書いてあります。
そこで、フルサイクル開発体制として開発者がシステムの運用もある程度担えるように仕組みづくりに注力しました。
具体的には下記のような仕組みの策定と、改善のPDCAを回していきました。
- 開発者とEnabling SREの運用定例の実施
- システムの信頼性が高い状態を定義したPRC (Production Readiness Check) の導入
- 運用評価制度の策定と導入
- システム運用 / オンコールオンボーディングの実施
- 運用責任チーム分割によるオーナーシップ促進
- 運用スキルのTier分けとTierごとの権限整理による実践機会提供
- 障害時Playbookの拡充と実践オンボーディング実施
施策に関しては、こちらにも詳しく書いてあります！
どうなった？
フルサイクル開発体制で本格的に開発者が運用に関わり始めてから約8 ~ 10ヶ月ほど立ちますが、徐々に浸透と成果が見えてきて、SREが実際にEmbedded SREとして手を動かすことが大幅に減りました。バックエンドチームの状態としてはこのような感じです。
- インフラ起因の障害に対しても開発チームのみで障害対応が完結できる事例が出てきた
- 新規事業や既存領域のSLI / SLOの実装を自律的に行えている
- メトリクスを定期観測して開発者がキャパシティプランニングを行うことができる
- ポストモーテムを開発者主導で行える
- インフラリソース系のwarningアラートやインフラのコストアラートにレスポンスできる
- システムメンテナンスを開発者とSREで協力して行うことができる
システム運用の知見の浸透という意味で特に大きかったのは、
- PRCの実施
- 運用定例の実施
- 障害時Playbook
あたりかなと思います。PRCを時間をかけて既存システムに対しても実施したことでシステム運用に必要な観点を浸透させることができました。また、運用定例でのシステムの定点観測は重要メトリクス理解やサービス特性の理解に効果がありました。
かつては2人でオンコールを回す状態だったのが、充実したオンコールローテーションを組めるようになってきており、一人あたりの負荷が大幅に減りました。ここ最近は機能が複雑化していて、アプリケーション起因の障害件数のほうが多いため、対応時に開発者がいてくれるおかげでスムーズに対応できています。
キャパシティプランニングに関しても、開発者が無駄にリクエストが送られている、この実装がおかしい、というのに気づいてアプリケーション的なアプローチで改善できることが多くなり、インフラコストとしてもメリットが大きかったです。コイン基盤のリクエスト数を1/2に防ぎサーバーコストが半分になった事例もありました。
ちなみに、年末の全社会でフルサイクル開発体制推進が発明賞をいただくことができました 🎉
プラットフォームエンジニアリング周り
ここでいうプラットフォームエンジニアリングは、インフラ基盤としての実態があるというよりは、自動化や、テンプレート化などを含む広義のプラットフォームです。
SREがEmbeddedとして手を動かす機会が減ったことで、組織横断のセキュリティやTerraformのCI / CDの自動化 (開発者がTerraformを触るので課題として大きくなった) など、本質的な信頼性向上や開発速度向上・運用負荷の削減に取り組む余白がでてきました。
主に、
- クラウドセキュリティ強化
- 開発速度向上と運用負荷の削減
を目的としたシステムの改善に注力しました。
具体的には、このようなことを実施しました。
- 負荷検証環境構築
- 共通GHAの作成による開発運用効率化
- 特定領域に特化したインフラテンプレート化
- TerraformのCI / CD化
- BackupのOrganizationレベルでの強化
- ID基盤のアウトバウンド制御強化
- AWS DetectiveのOrganizationレベルでの導入
ランサムウェアの被害が大きく取り立たされたこともあり、今まで取り組むことができていなかったOrganization周りの改善も進める事ができました。
また、長く取り組みたかったTerraformのCI / CD化や負荷検証基盤の刷新などにも取り組むことができました。
徐々にこういった改善ができる体制になってきましたが、システム運用も開発者が見るという状況下では、運用の効率化や開発速度向上施策はまだまだ伸びしろがある状況です。
今後はAI Ops周りにも着手していきたいとチームで話していたり、セキュリティについてもバックログに詰んである重要タスクの半分くらいしか着手できていないので、来年の課題として残っています。また、開発速度と信頼性を両立するためのプラットフォームエンジニアリングの具体的な戦略についても考える必要があります。
新規事業立ち上げ期のEmbeddedとインフラ構築
今年はSREチームがEmbeddedとして、2件新規事業の立ち上げに関わり、信頼性設計やアーキテクチャ設計に初期から参加しました。
Embeddedと表現しているのは、インフラ構築や監視周りの実装をSREチームがやったからです。
インフラ構築は誰がやるべきとかは特に定義していませんが、下記の理由からSREチームが担いました。
- SREチームの新メンバーが初期構築に関わることでAWSのインフラアーキテクチャの解像度を上げるため
- 新規立ち上げが急務で、初期の開発者の負荷が上がることが予想されたため
また、ベースはもちろんフルサイクル開発体制のため、新規システム立ち上げ時にも開発者がシステムの運用を並走して行うことでSREチームがEmbeddedではなくなってからもシステム運用の多くを開発者だけで行うことができるようになってきました。
かなりのスピード感のある案件だったのですが、開発メンバーのスキルが高かったこともあり運用に関しても並行で手を動かしてくれました。「あのときにちゃんと一緒に手を動かしたから今運用をチームで見れる」という意見ももらいました。チームメンバーによってもサポートの濃度を変える必要があるフェーズだと感じました。
弊社の多くのサービスはAuroraのプロビジョンドを利用していますが、初めてAurora Serverlessの運用なども経験することができました。
SREチームのミッションの策定とアップデート
2月にチーム化するにあたり、SREチームのミッションを策定しました。
また、前半戦と後半戦で役割が少し変化したため、チームミッションを刷新しています。
前半のミッションはこちらです。
開発者が運用も担えるように支援するという意味合いの強いミッションになっています。
💡
ソフトウェアエンジニアが、高速でPDCAを回しながら機能の価値検証と
システムの信頼性を両立できる開発を実現する環境・仕組み・文化をつくる。
これにより、すべてのステークホルダーにとって長期的に良い状態（Trade on）を実現する。
Trade onというのは、クラシル社のValueの一つです。
- チーム・組織
- 個人
- ユーザー
すべてのステークホルダーにとってプラスな状態を目指すという意図です。
フルサイクル開発体制によって、
- チーム・組織としてアジリティが上がる. 様々な変化に追従できる
- 個人として、運用を考慮した開発・インフラスキルの向上で市場価値が上がる
- ユーザーはより安定したサービスを利用することができる
と考えています。
そして、フルサイクル開発体制が徐々に浸透してくる中で、開発者の負荷を下げる自動化だったり、組織横断の信頼性向上に注力できる状態になりました。
そこで、後半戦では新しいミッションを下記に策定しました。
💡
開発チームが自律的に信頼性を担保できるよう支援しつつ、組織全体の信頼性と開発スピード・開発者体験を引き上げる。これにより、すべてのステークホルダーにとって長期的に良い状態（Trade on）を実現する。
影響範囲をチームから組織に変更することで、よりプラットフォームエンジニアリングとして広範囲な価値が出せるようにミッションを変更しています。
今後のSREチームの動き方
弊社では、チームの状況・事業の状況や数・組織体制は変化します。クラシル社は事業チャレンジの数が多く、意思決定スピードが速いのが特徴です。
SREチームの動き方も、人数が少ない分ある程度の柔軟性が必要だと考えています。「この動き方しかしない」と決めていると、組織・事業の変化に対応できません。
そこで、その変化に柔軟に対応できるように、状況に合わせて下記のような優先順位で動くというSREチームの行動の指針のようなものを定義しました。
- Embedded軸
関わるメンバーのインフラ構築・運用スキルや、事業やチームでスピードがどうしても必要な時期は、Embeddedでサポートする選択肢も残しています。
ただし、期間は区切り、永遠にならないようにします。続くようであれば採用を強化するや開発チームからのSREコンバートなどのようなアクションを迅速に取る必要があります。でなければ、結局運用の属人化が続きます。
ソフトウェアエンジニアリングガイドブックという本に載っていた平時モード、戦時モードという言葉を借りると、戦時モードかつ、メンバーのスキル感などに応じてEmbeddedが必要になるイメージを持っています。
出典：O’Reilly Japan『ソフトウェアエンジニアガイドブック』
- Enabling軸
ベースはフルサイクル開発体制です。開発者がシステム運用も担い、Enabling SREチームがサポートします。Enabling SREの状態が今のチームでは平常状態となっています。
徐々に個別のシステムで実際に手を動かすことは減ってきましたが、メンテナンスや障害周りなどのサポート、監視周りの困りごとなどは引き続きEnablingが必要な状態です。
- プラットフォーム軸
プラットフォーム軸を強化していかないと開発生産性を上げられないので、ここに注力する必要があります。ここも優先順位を落としていい領域ではないのですが、少なくとも今の人数では、このような優先順位にしています。
実際は、2, 3は平行で行うことが多く、Enablingをしながら横断的な運用課題や信頼性課題の効率化を目指して負荷を減らす方向に動いています。
長期的には、1、２が完了し、3にフォーカスできることを目標としています。
SREチームの課題
SREチームだけでなく、バックエンドチーム全体の課題も含まれていますが、事業の成長に伴って様々な課題があります。
- 事業横断で進行するシステム複雑性と強い依存関係
- まだEnablingが前提での運用体制
- 運用・開発における効率化と自動化の余地
- プラットフォームエンジニアリング方針の未整備
- 続・セキュリティ課題の解消
この間採用面接を受けてくれた方に、色々整ってきていそうだが、課題や他にやることは？と聞かれましたが、新しくSREチームにjoinしてくれたメンバーは、「めっちゃやることある！」といっています！
事業の変化に合わせてどう開発スピードを維持するか、SREの戦略も変化するのもあり、現状の考え方もアップデートするタイミングも来るかもしれません。
まとめ
2025年は、SREチームとして「ちゃんとチームになったな」と実感できた1年でした！
フルサイクル開発体制を軸に、PRCや運用定例などを進める中で、少しずつ開発者が自分たちで運用を回せる状態が見えてきました。以前はSREが手を動かす前提だったものが、今では「開発チームでまず考えて動く」場面が増えてきています。
その結果、SREとしてはEmbeddedで入り続けるのではなく、セキュリティや自動化、CI/CD、プラットフォーム寄りの改善に時間を使えるようになってきました。
来年は、今年作ってきた土台の上で、もう一段開発者体験と信頼性を引き上げられるように、引き続きチームで試行錯誤していきたいなと思います！
Discussion