こんにちは。ファインディのPlatform開発チームでSREを担当している原です。
ファインディでは、普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。
今回は、そのイベントの第二弾となる「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」を開催しまして、その当日のそれぞれの登壇内容について書いていこうと思います。
今回のイベントでは、Platform開発チーム(以下、SREチーム)が登壇し、チームのミッションや普段の業務内容について各々の立場から発表していきました。
本記事では、イベントでの登壇内容をベースに「横断SREチーム」の立ち上げ戦略や、AI(Devin/Claude Code)による運用自動化、未経験からのキャリア形成など、登壇者自身からダイジェスト版にてお届けしていきます！！
登壇内容
SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント
SREチーム サブマネージャーの安達(@adachin0817)です。Findyのサービスを横断的に支えるSREチームの立ち上げから現在までの3年間における「技術的な挑戦」と「マネジメントのリアルな葛藤」の2つについてお話させていただきました。
SREチームは、この3年間で多岐にわたる基盤整備と改善を実行し、着実に土台を整えてきました。
- 基盤のコード化・標準化
- 全環境のTerraform import化や、GitHub Actionsのテンプレート化を実施。
- オブザーバビリティと信頼性の向上
- Datadogの導入や、全サービスにおけるSLI/SLOの計測。
- セキュリティの強化
- Shisho Cloud(CSPM)やTakumi(SAST/DAST)を導入し、SOC2 Type2への対応。
- 開発体験の向上
- 開発環境の改善に加え、AI(Devin等)を活用した運用・構築の自動化など、先進的な取り組みも行う。
また、技術面だけでなく、チームビルディングやタスク管理の苦労、そしてその解決策についてもまとめていきました。
サブマネージャーとしてはマネージャーの右腕となり、メンバーへの技術指導・リスクマネジメント（過稼働の防止など）・ロードマップの策定を担っています。 チーム結成当初は、ビジョンやミッションが抽象的だったり、誰がどのサービスの責任を持つかが不明確で属人化しやすいといった課題がありました。 そこで「SREよもやま会」を実施してチームの方向性やマインドセットを議論し、GitHubのカンバンやロードマップでタスクと優先順位を可視化・管理する改善を行いました。
去年から新サービスが増加し続ける中で、SREチームだけで全ての工数や問い合わせを抱え込むことには限界が見えてきました。
そこで今後は、SREチームが全てを巻き取るのではなく、各部署内でSREの知識や運用方法を展開・定着させるEnabling(SRE社内留学制度)を推進する方針へとシフトしていきます。
具体的には、ドキュメントや動画を用いた学習、Sandbox環境での実践（SRE社内留学制度）などを通じて各部門の自律性を高め、組織全体としてスケールできるSRE体制への成長を目指しています。
去年のチームの振り返りについては次のTechBlogに記載されていますので、ぜひご覧ください。
Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果
原からは、「Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果」と題して発表しました。
入社してから1年間で行った取り組みの中から、Terraform汎用モジュールとDevinを用いたAI活用でのトイル削減についてピックアップして紹介しました。
昨年ファインディがリリースした新サービスについて、品質を保ちつつスピード感を持ってインフラ環境構築を行う工夫を紹介しました。
SREチームが担当したサービスは次のとおりです。
- Findy Conference
- Findy AI+
- Findy Team+ AIチャットボット
- Findy ID
- Findy Insights
- アーキテクチャ壁打ちAI by Findy Tools
品質とスピードの両立を目指した「汎用モジュール」では、ファインディのプロダクトで頻繁に利用するリソースをモジュール化して、モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組みを整備しています。
汎用モジュールを使ったインフラ環境構築は、今では開発者自身に担当してもらうこともあり、SREチームのEnabling活動の一環となっています。より構築しやすい汎用モジュールにアップデートし続けていきます。
詳しい内容は、次のTechBlogにも記載されています。
もう一つ、Devinを使ったAI活用によるトイル削減についての事例を複数紹介しました。
例えば、SREチームではコーポレートサイトの運用も担当しており、会社概要や利用規約の変更依頼が来ることがあります。以前はソースコードを直接編集していましたが、現在はこれらの作業をDevinに任せています。
Slackのワークフローから申請するとDevinが自動起動する仕組みを整備しました。事業部からの依頼をワークフロー経由で受け付けることで、SREチームはPRレビューのみに注力でき、工数削減を実現しました。
このように、汎用モジュールやAI活用でのトイル削減について紹介しました。
発表の最後では、ログ基盤の整備やAIOpsなど今後の取り組みについても触れました。これからも信頼性向上に向けたプラクティスを続けていきます。
フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告
SREチームのもずます(@mozumasu)です。 フリーのインフラエンジニアからSREへの転身を果たし、入社後3週間の活動報告をさせていただきました。 フリーランスから正社員になって変化したことや、お気に入りの自動化の仕組みなどを紹介しました。
まず現状の把握として、Findy ToolsのTerraform構成に触れました。現在は汎用モジュールがなく、environmentsとmoduleで管理しており、環境ごとのtfファイルでmoduleを呼び出す構成になっています。
運用を楽にするための自動化も進んでおり、次のようなツールが組み込まれています。
- Renovate: 依存関係の自動アップデート
- tfcmt: PRに対してTerraform planの結果を自動コメント
- Trivy: 脆弱性スキャン
この3週間で、主に2つの大きな取り組みを行いました。
- SLO定点観測会の改善
SREチームと各プロダクトのエンジニアで、隔週で「SLO定点観測会」を実施しています。 これはDatadogやGrafanaを見ながらサービスの状態（SLO、ステータスコード、レスポンスタイム、APM、インフラリソースなど）を確認し、SLI/SLOの達成状況を把握する会です。 以前は、ダッシュボードの画像をGeminiで画像解析し、その結果をNotionに自動記載するという運用をしていました。 しかし、この運用には次の課題がありました。
- 画像から分かる情報が冗長に記載されてしまう
- 重要な情報が埋もれやすい
- 解析結果が誤っていることがある
- 議事録の準備に工数がかかる
そこで手法を見直し、現在では「注視するべき部分（項目）のみを手動で記載する」というシンプルな形へと変更しました。
- DatadogのダッシュボードをClaude Codeで作成
現状、SLO、Synthetic Testing、Slack通知などはTerraformで管理していますが、ダッシュボードのレイアウトなどはTerraformの管理外になっています。既存のダッシュボードをエクスポートすると約2000行のJSONになり、非常に可読性が悪いという印象を受けました。 そこで今回、Claude Codeを使ってこれを解析し、HCL（Terraform）化を試みてみました。
結果として、HCLにしても約1500行と行数自体はそこまで劇的に減りませんでしたが、HCLであれば変数の参照ができるようになるため、ダッシュボードをコード管理するならHCL化するメリットは十分にあると感じました。
入社からの3週間で、Datadogの設定やSLO定点観測会の改善など、SREとしての第一歩を踏み出すことができました。 今後はセキュリティ周りの改善などにも力を入れていく予定です。
BEから未経験でSREへ：オンボーディングとトイル改善の記録
SREチームの富田です。「BEから未経験でSREへ オンボーディングとトイル改善の記録」というタイトルで登壇予定でしたが、当日は諸事情により欠席となりました。
この記事では、発表予定だったスライドをもとに、SREとして未経験から立ち上がるまでの過程と、実際に取り組んだトイル改善の内容をお伝えします。
バックエンドエンジニア（BE）から未経験でSREへキャリアチェンジした背景と、入社してからの半年間で行った取り組みの中から、「SLO定点観測会」と「GitHub Actionsを用いたトイル削減」についてピックアップして紹介します。
BEとして働いていた時代、当時のCTOが自ら新サービスの環境構築やデプロイフロー改善を行う姿を目にしました。その経験から、アプリ開発にとどまらず開発環境そのものを整備し、エンジニアの開発生産性を支えたいと考えるようになりました。これがSREへ転向したきっかけです。
SREへ転向してから取り組んだこととして、1つ目は「SLO定点観測会」です。
SREチームの各担当と各プロダクトのエンジニアが隔週で集まり、DatadogやAmazon Managed Grafanaを見ながらアプリケーションの状態を確認する定点観測会を行っています。
この会でモデレータを務めることで、次のような学びを得ました。
- 対話しながらDatadogを確認することで身についた、実践的なダッシュボードの読み方
- 開発者の視点を聞きながら状況を判断することで得た、複数の角度からシステムを捉える力
- 「なぜこの数値になっているのか」を問い続けることで養われた、分析的な視点
地道な積み重ねですが、SREとして考える力の土台になっていると感じています。
2つ目は、ファインディのサービスの一つ「Findy Conference」の運用で発生していたトイルの削減事例です。
Findy Conferenceはセッション終了時などに瞬間的なトラフィックが集中するため、事前にコンテナ数の調整が必要でした。
以前は本番環境のAWSマネジメントコンソールにて手動で作業しており、ペアオペ必須で毎回約1〜2時間弱もの時間がかかっていました。 このトイルを削減するため、GitHub Actionsのworkflow_dispatchとAWS CLIを活用し、GitHubの画面上からフロントエンド・バックエンド両方のコンテナ数を変更できる仕組みを構築しました。
これにより、約2時間かかっていた作業が数分へと大幅に短縮されました。さらに、本番環境での手動介入がなくなったことでヒューマンエラーの心配が解消され、SRE以外のエンジニアでも安全にコンテナ調整が可能な状態を実現しました。
詳しい内容は次のTechBlogで紹介しています。ぜひご覧ください。
以上が、登壇で伝える予定だった内容です。BEからSREへ転身し、できることから着実にトイル削減に挑戦した記録が、同じような境遇の方の参考になれば幸いです。
まとめ
以上、SREチーム主催のFindy Tech Talk「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」での登壇内容となります。
イベント当日は多くの方に参加いただき、賑やかな中開催することができました。参加いただいたみなさん、本当にありがとうございました！
いただいたアンケート結果より、またブラッシュアップしたFindy Tech Talkをお届けできればと思います。
次回イベント開催の際はぜひお越しください！
現在、ファインディでは一緒に働くメンバーを募集中です。
興味がある方はこちらからご覧ください。 herp.careers
