SREKaigi2026_ゼロからはじめるSRE一人運用から複数プロダクト_SREチーム立ち上げまでの軌跡.pdf

by ybalexdp

Slide 1

Slide 1 text

ゼロからはじめる SRE：一人運用から複数プロダクト・ SREチーム立ち上げまでの軌跡 2026/1/31 SRE Kaigi 2026 籔下直哉 / @ybalexdp 株式会社TalentX 上席執行役員CTO

Slide 2

Slide 2 text

自己紹介籔下直哉（やぶしたなおや） Naoya Yabushita X：@ybalexdp 株式会社TalentX 上席執行役員 CTO 大手メーカーにてプライベートIaaS基盤を中心にNFV/SDN領域やWeb領域での開発を担当。 2018年TalentXに入社し、その後Tech Lead / EMとして技術及び開発組織全般を管掌。2023年執行役員CTOに就任 2

Slide 3

Slide 3 text

採用DXプラットフォーム「 Myシリーズ」 3 　　　　　　　　　　　　　　企業の採用マーケティングを促進するための人的支援やコンサルティングサポート採用マーケティングノウハウの提供人事担当者の運用工数削減データ分析候補者を惹きつけるブランディング機能候補者との関係を育むナーチャリング機能社員と候補者を信頼でつなぐリファラル機能 Myシリーズは、企業の人材獲得力そのものを強化するご支援をしていますシームレスな接続シームレスな接続過去接点者を資産化し半自動的にナーチャリングする採用 MAクラウド社員をファンにする国内初のリファラル採用クラウド採用ブランディングを加速するノーコード CMSクラウド

Slide 4

Slide 4 text

会社沿革と技術基盤の進化：創業から SRE立ち上げまでの軌跡 4 創業 2015 大手人材企業の新規事業として MyRefer立ち上げ。 2018年までは社内新規事業として運営インフラはさくらのクラウド 2018 会社設立 MBOによりスピンアウト株式会社MyRefer設立 2022 新規事業立ち上げ MyTalent立ち上げこちらは最初から AWSで構築マルチプロダクト体制へ移行 AWS移管さくらのクラウド AWS MyReferのインフラをさくらのクラウドから AWSへ完全移管 2023 ID統合（認証基盤構築） SRE立ち上げ MyRefer ID MyTalent ID ID統合 2つのプロダクトの認証を統合し、 1つのIDでアクセス可能に SRE専任私(兼任) 専任1名採用、2名体制で SREチーム始動

Slide 5

Slide 5 text

アジェンダ 5 1. AWS移管前 2. AWS移管後 3. SRE立ち上げ

Slide 6

Slide 6 text

6 AWS移管前

Slide 7

Slide 7 text

創業期〜会社設立期 7 背景（想像） ● 別のプロダクトの構成をそのまま流用 ● 最短で構築可能な構成を優先（スピード重視） ● 将来的なスケールは優先度 ⬇ ※当時、自分は未ジョインのため上記背景は想像インフラ構成さくらのクラウド Webサーバ Webサーバ Webサーバ DBサーバ (MariaDB) バッチサーバ DBサーバ (MariaDB) DBサーバ (MariaDB) DBサーバ (MariaDB) Galera Cluster (マルチマスター ) 構成管理・プロビジョニングアラートモニタリング・ログ分析

Slide 8

Slide 8 text

会社設立時期（ MBO直後）の体制とインフラ運用 8 状況サマリ ● 創業3年経過、MBOを経てスピンアウト ● スピンアウト 1ヶ月前に自分がジョイン ● エンジニア数名。インフラは当時の Tech Leadがほぼ一人で運用 ● 他のエンジニアとの相対比較でインフラに比較的明るかったため徐々に自分がインフラ周りの運用タスクやセキュリティ周りを対応体制とインフラ運用チーム体制（エンジニア数名）・・・役割分担は特に無しインフラ運用（Tech Lead一名対応） Tech Lead ほぼ一人で運用責任のデリゲーション（私への移行開始） Tech Lead 私 (ジョイン直後 ) インフラ・セキュリティ対応徐々にタスク・責任を移譲

Slide 9

Slide 9 text

Tech Lead退職に伴い、属人化（責任の集中）からの脱却を目指すことに 9 Tech Lead退職により責任が集中インフラ全責任インフラ + セキュリティの責任者に中長期的な目標：属人化と責任の集中からの脱却 ● 自分一人に集中している運用責任からの脱却をはかりたい ● 将来的な組織拡大・チーム運用を見据えた構成へ移行 ● 持続可能な運用体制の構築を目指す

Slide 10

Slide 10 text

中長期的な視点とレガシー脱却のジレンマ 10 解決策のジレンマ：フルリプレイスの時間的制約現状（当時）の課題：レガシーな構成による採用の壁アプリケーション・インフラ共にかなりレガシーな構成将来、エンジニア採用で苦戦が予想される魅力不足、スキルミスマッチの懸念フルリプレイスには相当の時間が必要ビジネススピードは落とせない一足飛びの解決は困難将来を見据えつつ現実的な最適解を模索する必要があった

Slide 11

Slide 11 text

新規機能開発と技術負債の解消の両立 11 【攻め】会社設立 2年目：成長への全力疾走まだまだ新規機能開発に全振りが必要なフェーズ事業成長のための機能追加が最優先難しいリソース配分の決断・会社は設立間もないが、サービスは中堅という複雑な状況・全てのエンジニアリングリソースを負債解消には割けない（事業成長は止められない）・しかし、何も手を打たない選択肢はない新規開発負債解消【守り】サービス運用 5年目：蓄積する技術負債サービス自体は 5年以上の運用歴（設立前からの継続）。技術負債が顕在化。

Slide 12

Slide 12 text

経営層への説明と合意形成セキュリティ面では前進点がある点も協調インフラ刷新の必要性を説く 12 現状課題の説明：インフラの老朽化、運用負荷、パフォーマンス問題、セキュリティコストの擦り合わせ：リプレイス後の想定、対応工数、業務委託費用など WAFの導入： Webアプリケーションの保護を強化各種監査ログの強化：その他、多くのセキュリティ恩恵を享受工数と体制の再構築自身の工数見直し：インフラリプレイス対応に一部工数を割く有識者の採用： 2名体制で進行体制を確立 2名体制

Slide 13

Slide 13 text

インフラリプレイスにおける重要コンセプトと将来展望 13 将来のSRE採用を見据えた技術選定（戦略）新しい技術要素現在の技術スタック将来的な SRE専任者の採用を視野に入れ、魅力ある技術スタックを採用自前運用から脱却し運用負荷軽減（効率化） (self-hosted) 運用工数削減（SaaS/PaaSへ移行）自前運用していた各種サービスから脱却。運用工数を削減し、ビジネス価値向上へリソースを集中マルチプロダクト展開を見据えた基盤設計（拡張性） MyRefer Future Product A Future Product C Future Product B 共通基盤将来複数のシナジー効果を生む新規プロダクトの計画があり、それを見据えた設計に

Slide 14

Slide 14 text

インフラリプレイスにおける重要コンセプトと将来展望 14 (self-hosted) 運用工数削減（SaaS/PaaSへ移行）自前運用していた各種サービスから脱却。運用工数を削減し、ビジネス価値向上へリソースを集中自前運用から脱却し運用負荷軽減（効率化） MyRefer Future Product A Future Product C Future Product B 共通基盤将来複数のシナジー効果を生む新規プロダクトの計画があり、それを見据えた設計にマルチプロダクト展開を見据えた基盤設計（拡張性）新しい技術要素現在の技術スタック将来的な SRE専任者の採用を視野に入れ、魅力ある技術スタックを採用将来のSRE採用を見据えた技術選定（戦略）

Slide 15

Slide 15 text

振り返り： SRE採用を見据えた技術選定 15 新しい技術要素現在の技術スタック将来的な SRE専任者の採用を視野に入れ、魅力ある技術スタックを採用将来のSRE採用を見据えた技術選定（戦略）・結果論だが現在の SRE専任者は Terraformに精通・採用時に datadogやk8sの採用で一定の応募自体は獲得できた良かった点：現在のSRE専任者の採用・0からのアーキテクチャ構築機会に欲が出た・当時の身の丈に合わない選定をしてしまった失敗した点：欲と流行の代償

Slide 16

Slide 16 text

振り返り：自前運用から脱却し運用負荷軽減 16 　とにかく楽になった！！良かった点 (self-hosted) 運用工数削減（SaaS/PaaSへ移行）自前運用していた各種サービスから脱却。運用工数を削減し、ビジネス価値向上へリソースを集中自前運用から脱却し運用負荷軽減（効率化）

Slide 17

Slide 17 text

振り返り：マルチプロダクト展開を見据えた基盤設計 17 MyRefer Future Product A Future Product C Future Product B 共通基盤将来複数のシナジー効果を生む新規プロダクトの計画があり、それを見据えた設計にマルチプロダクト展開を見据えた基盤設計（拡張性）背景と目的：将来的なシナジー創出を見据えて・複数プロダクト連携による相乗効果（シナジー）の創出を計画・新規事業の迅速な立ち上げと即時連携が可能な状態が目標アーキテクチャ選定の背景・モダンな技術トレンドへの意識・プロダクト横断の「共通 API」・将来的な ID統合を見据える EKSをベースとしたマイクロサービスライクな構成

Slide 18

Slide 18 text

チキンレース状態と多重責務の重圧 18 希望の終焉早急なリプレイスを強いられる自体に Galera Cluster DOWN 再構築しクラスタへの追加を試みるが膨大なデータのためデータ同期が間に合わず失敗 4台→3台に縮退サービス停止リスク増精神的負担の増加（不安）バックエンド開発インフラ運用新規機能要件定義 PJディレクション EM業務

Slide 19

Slide 19 text

リスクを正しく評価できているか 19 個人にまつわるリスク（当時の私自身の目線）　　不安：不安をストレスに感じるあまり、最悪のシナリオを頭から閉め出し、考えまいとする。 → 深刻なリスクへの準備不足極端な楽観主義：事故は「よその話」と現実を歪めがち。リソース不足とリソースマネジメント『もし、リソース不足の部署や人手不足が当たり前のスタートアップで働いているのだとしたら、必要なリソースを揃えようとする努力は、終わりのない苦行となるでしょう。（中略）限られた時間でリスクマネジメントを行うには、徹底的な優先順位づけが必要です。』 ※上記は逆の思考だが、当時の自分の中では両立していた

Slide 20

Slide 20 text

緊急対応への方針転換：理想の追求から現実的なスピード優先へ 20 当初の構想と現実のギャップ（時間的余裕の喪失）理想のEKSマイクロサービス基盤時間をかけた理想的な（EKSマイクロサービス基盤）アーキテクチャ実現の余裕がなくなった既存事業の緊急 AWS移管早急な移管途中までの設計・検証・移管準備は活かしつつ（EKS）、まずはスピード優先でAWSへ移管することを目的に切り替え新規事業のスピード立ち上げ新規事業別AWSアカウント ECS（最小構成）同時期に始まった新規事業は、準備中の EKSではなく、スピード優先で別アカウントの ECS最小構成で立ち上げることに

Slide 21

Slide 21 text

その結果... 21 MyRefer（既存プロダクト） AWSアカウント A MyTalent（新規プロダクト） AWSアカウント B EKSで構築 ECSで構築立ち上げ当初はそこまで連携機能もなく完全に独立した別プロダクトとして運用を開始

Slide 22

Slide 22 text

22 AWS移管後

Slide 23

Slide 23 text

23 （妥協案ではあるが）無事移管完遂！精神的重圧から解放一旦の構成とはいえ、移管を機に SRE的な活動にも注力まずはSLI/SLOを定義し、可視化するところからトライを開始

Slide 24

Slide 24 text

AWS移管後の運用改善 24 アクセスログ集約ログ加工クエリ分析 AWS移管により、アクセスログ等を S3に集約 Athenaでクエリベースでの抽出・分析が可能に Athenaによる簡易ログ分析基盤の構築

Slide 25

Slide 25 text

AWS移管後の運用改善 25 セキュリティチェックで SLAの有無やSLOについての設問が多く SLOを策定すべく動き出す当時検討（理想）現実 API API … API … 重さ … API特性に応じた重要度係数など、より顧客体験に直結した定義が理想だが、複雑で管理負荷が高い顧客体験ベースの稼働率稼働率＝ 100% まずはシンプルに、全リクエストに対する 5xxエラー率をベースに稼働率を定義し、可視化・観測を開始

Slide 26

Slide 26 text

26 SRE活動に腰を据えて取り組もうとしたが

Slide 27

Slide 27 text

さらに加速するプロダクト開発 27 現状のジレンマと当初の計画一旦仕方ない。次のプロダクト立ち上げ前に全体設計・移行を進めよう MyRefer （EKS） MyTalent （ECS）

Slide 28

Slide 28 text

さらに加速するプロダクト開発 28 新たなプロジェクト： ID統合と共通機能開発 MyRefer ID MyTalent ID 統合ID認証基盤 MyReferとMyTalentのIDを統合し、シームレスに連携現状のジレンマと当初の計画一旦仕方ない。次のプロダクト立ち上げ前に全体設計・移行を進めよう MyRefer （EKS） MyTalent （ECS）次なる PJ スタート共通管理画面ログイン画面や共通的なアカウント管理機能を提供

Slide 29

Slide 29 text

さらに加速するプロダクト開発 29 現状のジレンマと当初の計画一旦仕方ない。次のプロダクト立ち上げ前に全体設計・移行を進めよう MyRefer （EKS） MyTalent （ECS）目指す姿：共通基盤を軸としたプロダクトの複合化進化 MyRefer MyTalent 共通基盤（ID統合 + 共通管理機能）独立したマルチプロダクトから、共通基盤を軸とした『複合的なプロダクト』へ新たなプロジェクト： ID統合と共通機能開発 MyRefer ID MyTalent ID 統合ID認証基盤 MyReferとMyTalentのIDを統合し、シームレスに連携共通管理画面ログイン画面や共通的なアカウント管理機能を提供次なる PJ スタート

Slide 30

Slide 30 text

結果 30 MyRefer MyTalent 共通管理（ New） Lambda Authorizer cognito Verify Token(JWT) Authentication

Slide 31

Slide 31 text

31 SRE立ち上げ

Slide 32

Slide 32 text

この直後、 SRE専任採用へ 32 AWS移管・共通基盤立ち上げ期 ○ AWS移管や共通基盤構築を通じ、徐々に現場メンバーへ権限移譲 ○ 各プロダクトチームにて運用できる状態へ ■ むしろ自分より詳細は詳しい状態 1 ● 残された課題としてプロダクト横串での最適化 ○ 各プロダクトの運用はチームで自走可能になった一方で、全体最適や将来の拡張性に対応できる横断的な体勢が整備できず 2 ● SRE専任者採用 ○ 共通基盤PJ完遂後、CTOに就任し役割が拡大 ○ 残された横断的課題を解決するため、 SRE専任者を採用 ○ 組織的なインフラ最適化体制へ 3

Slide 33

Slide 33 text

SRE専任チーム立ち上げた後、着手した内容 33 ① モニタリング整備と SLI/SLOを各チームで意識する文化醸成 ② インフラコストのモニタリング強化とコストカット施策の実行 ③ 体系的なセキュリティ強化 ④ IaC周りの整備

Slide 34

Slide 34 text

① モニタリング整備と SLI/SLOを各チームで意識する文化醸成 34 APIの5xx系のレスポンス率をベースに可視化はしていたが、「とりあえず見てみよう」というレベル。チームでその数字を意識するところまで文化醸成できておらず、ほぼ形骸化。 Before ：APIベースでの稼働率の「とりあえず」可視化 After ：目的を再定義し、開発チームのアクションに連動するように設計 SREだけではなく開発チームが意識する SLOが満たされない状況を開発チームが自ら回避できる SLOを下回った際に開発チームがアクションできる目的を明確に目的を満たすために、アクセスログのステータスコードだけに収まらない範囲での SLI/SLOを定義し、モニタリングを強化する方針もあったモニタリング強化の優先度や時間軸の関係でまずは現状のSLI/SLOで文化醸成する方向とした SLI/SLO自体は変えずに文化醸成にフォーカス

Slide 35

Slide 35 text

1時間のTime Windowでエラーバジェットが 25%低下した場合通知 SlackでSREにメンション対応 SREがインフラ状況を確認し、必要に応じて開発チームに連絡 1ヶ月間のTime Windowで SLO 99.95% を下回った場合通知専用チャンネルでSREと開発チームにメンション対応開発チームとして対応方針を策定。SREは致命的な欠陥がないか確認 ❶監視&アラート (Monitor & Alert) 2つのタイムウィンドウによる多角的な監視 SLI/SLOの運用の取組み 35

Slide 36

Slide 36 text

❷共有&改善 (Share & Improve) 月次での状況共有と継続的改善 36 SLI/SLOの運用の取組みエンジニア全員が参加する月次会議で、サービスの稼働状況を共有します。 Datadogダッシュボードをベースに SRE チームと開発チーム間でエラー発生状況の認識を合わせを行います。

Slide 37

Slide 37 text

② インフラコストのモニタリング強化とコストカット施策の実行 37 直近1年の実績をベースに、感覚的な予算策定「これくらいに抑えれればいいな」というザックリとした目標 Before ：インフラコストに関して感覚的な予測と管理 After ：計画的・経営連動型の最適化 ① 多角的な妥当性評価プロダクトごとの構成差や、MRR比での妥当性など、多角的な観点で計画を再精査 ② 経営との連動 RIやSaving Planの前払い条件（期間、率）などを経営と連動して戦略的に決定足元のキャッシュ優先 or 中長期目線での支出抑制優先など ③ 運用方針の明確化極限までのコスト削減ではなく、予測超過時にコスパの良い削減策を検討・実行する方針へ

Slide 38

Slide 38 text

DashBoard 前月と比較したサービス毎の使用料金上昇率を把握予算（Budget）当月のAWS予算に対する利用料金の着地予測を週次の振り返りで確認コスト異常検知予定外の新規リソース作成および通常の利用と異なる料金の発生を検知インフラコストのコスト監視に関する運用方針最もビジネスインパクトがあり、かつ金額の変動リスクのあるAWS料金を中心に監視し予期せぬ高騰を早期に検知する活用する AWS Cost Explorerの機能

Slide 39

Slide 39 text

③ 体系的なセキュリティ強化 Before ：必要に駆られた受動的な対応 After : 現状把握に基づく計画的な強化 AWSセキュリティ成熟度モデルをベースに、組織としてのセキュリティ現在地を客観的に把握組織的な現在地の明確化半期ごとの目標と、それを達成するための具体的なKPIを定義し、計画的なアップデートを推進する方針へ移行計画的な目標・KPI設定顧客からのセキュリティチェックで NGとならないことが基準。要対応事項が発生すれば都度対応顧客対応ベースの強化会社設立1年目から外部診断を実施していたが、計画的な強化というよりは、指摘があった場合に対応する受動的なアップデートが中心定期的な外部診断

Slide 40

Slide 40 text

AWS成熟度モデルに基づく体系的アプローチ優先順位付けによる最適化 : セキュリティ対策の導入に明確な優先順位を付け、リスク軽減とコストパフォーマンスを両立させるプロダクト横断での標準化 : 全てのプロダクトに共通のセキュリティ施策を横断的に実装し、プラットフォーム全体のセキュリティレベルを底上げする AWS成熟度モデルの採用 40 セキュリティ運用の戦略的課題スコープの曖昧さ : セキュリティ施策は、投資対効果を考慮しつつ「何をどこまでやるか」を見極めるのが本質的に難しい複合型プロダクトの特性 : 当社プラットフォームは複数のプロダクトで構成されるため、特定プロダクトのセキュリティだけが完璧でも意味はない

Slide 41

Slide 41 text

実装例：クイックウィン： WAFマネージドグループによるベースライン防御 41 　　　ベースライン：　　全プロダクトが備えるべき共通のルール例 ● AWSManagedRulesAmazonIpRep utationList AWS脅威インテリジェンスが特定した、悪意のある送信元IPからのリクエストをブロック ● AWSManagedRulesCommonRule Set OWASP Top 10に基づく、Webアプリケーションの脆弱性を狙う一般的な攻撃パターンをブロック　カスタム：　　各プロダクトの特性に応じたルール　　例） ● AWSManagedRulesPHPRuleSet PHPの脆弱性に対する攻撃をブロック https://maturitymodel.security.aws.dev/ja/1.-quickwins/

Slide 42

Slide 42 text

④ IaC周りの整備 42 AWS移管は手作業も多く、実際のリソースからコード化するところで止まっていた再現性や拡張性に課題があった Before ：手作業での構築と後追いのコード化 After ：再現性の確保とモジュール化による標準化 ① 新プロダクトでの再現今後の新規プロダクト立ち上げに備え、新規AWSアカウントに同等の構成を迅速に作成できる状態へ改善。 ② Moduleの導入・整備共通部分をModule化し、再利用性と管理性を向上。標準化を推進。 ③ 開発者との境界線整備開発チームとの責任範囲や連携フローを整備し、効率的な協業体制を構築。

Slide 43

Slide 43 text

01. 課題品質と統制の壁 ● チームごとのスキル差により、Terraformコードの品質維持が困難 ● セキュリティ基準が徹底されず、不適切なリソースが作成されるリスク 03. 効果品質と統制の壁 ● SREのレビュー待ち時間ゼロ Lambda、SQS等のアプリ関連リソースは、SREの承認なしで即時デプロイ可能 ● SREの役割シフト「承認のボトルネック」から、「ガードレール設計者」へ 02. 解決ガードレールの構築 ● GitHub Copilot / TFlint 開発者はPR依頼前に、静的解析とAIサポートでコード品質を自己解決・向上 ● AWS Control Tower 不適切なリソース作成をシステム的に予防・ブロック（例：リージョン使用制限） Terraform運用における課題の解決 43 SREを「ボトルネック」から「ガードレール」へ変革し、開発スピードとガバナンスを両立する

Slide 44

Slide 44 text

Terraformデプロイパイプライン上のコードの品質保証の取り組み Copilot Review TFLint Review

Slide 45

Slide 45 text

まとめと振り返り 45 Tech Lead時代 → “コスト意識の不足 ” CTO時代 → “経営視座の習得 ” 当時AWS移管を意思決定した頃は経営観点の視座は持ち合わせていなかった身の丈に合わない技術選定オーバーエンジニアリング → 結果：将来の負債リスク増大 → 結果：全体最適、持続可能な基盤へと改善経営と連動した意思決定の重要性を痛感 SRE立ち上げ時に実践 SLI/SLO：開発チームと共通言語を持つための文化作りインフラコスト：単なる節約ではなく、経営判断セキュリティ：顧客信頼を守るための計画的な投資 laC：開発速度とガバナンスを両立するガードレール過去の反省現在の学び

Slide 46

Slide 46 text

ありがとうございました 46 私とのカジュアル面談 TalentX採用サイト