SRE依存からの脱却 運用を開 発チームへ移す、 フルサイ クル開 発体制の実践

2026/07/11 SRE NEXT 発表資料
kurashiru株式会社 joooee0000 髙山さやか
https://sre-next.dev/2026/schedule/#slot092

Transcript

1. SRE NEXT SRE依存からの脱却 運用を開発チームへ移す、 フルサイクル開発体制の実践 Speaker joooee0000 （レシチャレ事業部） Service レシチャレ ／ クラシル Date 2026.07.11 © dely, Inc. All Rights Reserved. 01
2. 自己紹介 joe クラシル株式会社 ／ バックエンド・SREチームリーダー @joooee0000 2014 年から2社でバックエンド・SREを各6年ずつ経験 6歳の息子と犬を飼っています © dely, Inc. All Rights Reserved. 02
3. 会社紹介: クラシル株式会社 国内最大級の toC サービスを複数運営 国内No.1 レシピ動画プラットフォーム 「クラシル」 節約アプリ 「レシチャレ （旧クラシルリワード） 」 国内No.1 ライフスタイル情報メディア 「TRILL」 国内最大級クリエイターマネジメント事務所 「LIVEwith」 © dely, Inc. All Rights Reserved. 03
4. 今日の話 サービスが急拡大する中、 運用一人体制からフル サイクル開発体制を目指した4年間の学びと工夫 © dely, Inc. All Rights Reserved. 04
5. フルサイクル開発体制とは？ 開発チームが、 設計から開発・デプロイ・運用・改善までを一気通貫で担う体制. 「作る人」 と 「運用する人」 を分けず、 作ったチームが運用まで責任を持つ. 設計 → 開発 → デプロイ → 運用・監視 → 改善 同じチームがすべてのフェーズを担当 当事者意識が生まれる 運用の痛みが設計にフィードバックされ、 品質が上がる 引き継ぎコストの削減 チーム間の受け渡しが減り、 リードタイムが短縮 運用の属人化を防ぐ 特定個人ではなくチームで知見を持ち、 持続可能に SRE は伴走役へ 基盤・ガードレールを整え、 開発チームを支える SREの方々には 「SRE の民主化」 という言い方が馴染みがあるかもしれませんが、 SRE以外のメンバーにとって 「フルサイクル開発体制」 のほうが直感的に理解しやすい・プロ ダクトの全体を通してチームで責任を持つというコンセプトに魅力を感じたため、 こちらの言い回しを初期から使っています. © dely, Inc. All Rights Reserved. 05
6. 運用体制の変遷 ── 4つの時期 サービスローンチから約4年. サービスとチームの拡大に合わせて、 運用体制は4つの時期を経て変化. 一人運用期 一人で運用を担う PRE SRE プラクティス 導入期 運用の民主化を試みる フェーズ ① 形骸化期 拡大によりプラクティスが形骸化 フェーズ ② 組織としての 仕組み化期 仕組みで運用を組織に定着 フェーズ ③ © dely, Inc. All Rights Reserved. 06
7. 運用体制の変遷 ── 4つの時期 サービスローンチから約4年. サービスとチームの拡大に合わせて、 運用体制は4つの時期を経て変化. サービスの拡大・複雑化 サービスリリース （4年前） 自社 ID 基盤統合 自社コイン基盤 構築 派生サービス リリース ×2 ゲーム事業 チームの拡大 1 チーム 5 -10チーム 一人運用期 一人で運用を担う PRE SRE プラクティス 導入期 運用の民主化を試みる フェーズ ① 形骸化期 拡大によりプラクティスが形骸化 フェーズ ② 組織としての 仕組み化期 仕組みで運用を組織に定着 フェーズ ③ © dely, Inc. All Rights Reserved. 07
8. 運用体制の変遷 ── 4つの時期 それぞれの時期でどのような課題や学びがあり、 どう改善してきたか、 どうなったかをお話しします. 一人運用期 SRE プラクティス導入期 形骸化期 組織としての仕組み化期 © dely, Inc. All Rights Reserved. 08
9. フェーズ 0 一人運用期 一人で運用を担う © dely, Inc. All Rights Reserved. 09
10. 運用を一人で担っていた時期の課題感 リリース後から急速にサービスが拡大していた オンコール一人体制で、 365日PC持ち歩き生活 進む属人化 SRE の採用難易度が高かった、 過去の経験もあり、 危機感 © dely, Inc. All Rights Reserved. 10
11. なぜフルサイクル開発体制を目指したか Spotify の事例 ── 7.1.2 重要な学び こうした会社の草創期からは次のように重要な学びがありました。 最初から運用エンジニアをチームの一員に加えたことが、 エンジニア リング文化に影響を及ぼし、 成長するにつれて大きなメリットとなるこ とが明らかになりました。 運用重視の考え方は、 できるだけ早い段階からエンジニアリング文化 に取り入れる必要があります。 ── 『SREの探求』 より この存在は憧れる！ 属人化やSRE不足の課題解消 小さいチームのうちに運用文化を浸透させたい フルサイクル開発体制で開発チームに早くから運用文化を浸透させ、 強固な体制にしていきたい © dely, Inc. All Rights Reserved. 11
12. 目指したチーム像 開発と運用のバランスを取りながら、 チームが自律的に品質・信頼性を担保できる 機能開発と保守運用のバランスが取れ、 事業推進スピードと品質が保たれている 運用改善が継続的に行われ、 手動運用が少なく自動化されている 障害の振り返りでフィードバックループが回り、 開発時に運用面が考慮されている © dely, Inc. All Rights Reserved. 12
13. フェーズ 1 SRE プラクティスの導入期 運用の民主化を試みる © dely, Inc. All Rights Reserved. 13
14. フェーズ 1 整えたもの 運用の民主化を目指してまずは SRE プラクティスを整え、 開発者への浸透を試みた. 運用のアラート化 DB コネクション上限・キャパシティ・AWS Health などの通知 障害対応・運用作業のRunbook の作成 SLI / SLO の策定、 SLI / SLO のIaCテンプレート化 開発者を含むオンコールローテーション／障害対応フローの明文化 ポストモーテムの実施 SLI / SLO についての記事 — aws.amazon.com/jp/builders-flash/202601/slo-separation-complecated-service / tech.dely.jp/entry/2024/03/22/164357 © dely, Inc. All Rights Reserved. 14
15. フェーズ 1 徐々に開発者が運用に関わる体制に変化 当時の役割イメージ 項目 SRE の役割 開発者の役割 SLI / SLO 指標設計・目標設定 SLO 達成に向けた改善実施 ポストモーテム ファシリテート・改善推進 原因分析・改善実施 モニタリング ダッシュボード・アラート整備 一部監視結果の確認・活用 障害対応 メイン担当 トリアージ・調査 EOL 対応・システムメンテ 計画策定・推進 実施・動作確認 運用改善・トイル削減 推進・リード 実施 運用メンバーを中心として、 開発者も徐々に運用に関わるように © dely, Inc. All Rights Reserved. 15
16. フェーズ 1 ・ そのときの手応え 少しずつうまく回っているかも？😏 © dely, Inc. All Rights Reserved. 16
17. フェーズ 2 形骸化期 チーム拡大により運用課題が大きくなっていった時期 © dely, Inc. All Rights Reserved. 17
18. フェーズ 2 チーム拡大による形骸化 サービスの成長とともに、 あらゆるものが同時に増加 メンバー ↑ チーム数 ↑ 関連サービス ↑ 共通基盤 ↑ © dely, Inc. All Rights Reserved. 18
19. フェーズ 2 当時の課題 SLI / SLO の改善やポストモーテムはなんとなく続けているものの—— 改善が後回しになり、 改善に向けた議論も少ない 運用責任が一部メンバーやSREチームに集中 機能開発重視で運用面は後から考慮 サービス拡大でSREがキャッチアップできていないドメイン固有の障害が増加 複数サービスが依存した責任者不在の基盤システム © dely, Inc. All Rights Reserved. 19
20. フェーズ 2 当時の課題 SLI / SLO の改善やポストモーテムはなんとなく続けているものの—— 改善が後回しになり、 改善に向けた議論も少ない 運用責任が一部メンバーやSREチームに集中 機能開発重視で運用面は後から考慮 サービス拡大でSREがキャッチアップできていないドメイン固有の障害が増加 複数サービスが依存した責任者不在の基盤システム © dely, Inc. All Rights Reserved. 20 全体的に信頼性・運用が足りていない・後手に回る状態に
21. フェーズ 2 ・ 気づき ツールがある ≠ 運用文化が浸透する SRE のプラクティスはツールとして必要不可欠.しかし、 それだけでは文化は根づかない. © dely, Inc. All Rights Reserved. 21
22. 形骸化の構造 ── 個人と組織 個人 メンバー増加により運用に対する認識の違いが出る が、 運用との接点がない 組織 スピード感があり、 サービスを前進させる力学が強い © dely, Inc. All Rights Reserved. 22
23. 形骸化の構造 結果としてチーム全体の力学がアンバランスに 機能開発 運用 片方に引っ張られる 当時 GOAL • 機能開発 • 運用 同じゴールへ並走する 理想 © dely, Inc. All Rights Reserved. 23
24. 形骸化の構造 結果としてチーム全体としての力学がアンバランスに 機能開発 運用 片方に引っ張られる 当時 GOAL • 機能開発 • 運用 同じゴールへ並走する 理想 © dely, Inc. All Rights Reserved. 24 左の状態は特定の個人に負荷がかかり 持続可能ではない
25. あるべき姿は？ ❌️ 意思を持った特定の人物が 「必要！」 と声をかけ続けないと信頼性や運用が後回 しになり、 誰かが消耗する構造 ⭕️ 組織として自然と開発に運用設計や工数が組み込まれる、 複数人で意思を持て る構造 誰か一人のカリスマ性やリーダーシップではなく、 組織として運用 （信頼性担保と開発速度のバランス） が回る土壌 を整える必要性 © dely, Inc. All Rights Reserved. 25
26. フェーズ 3 組織としての仕組み作り 運用を組織に定着させる © dely, Inc. All Rights Reserved. 26
27. 解決の方針 組織として運用が自然と回る状況をどのようにつくるのか SREは文化 → 文化を作るためには 実行を繰り返す必要がある → 実行できる 土台が必要 実行できる土台とは？ © dely, Inc. All Rights Reserved. 27
28. 解決の方針 組織として運用が自然と回る状況をどのようにつくるのか 実行の土台: 基準や指針があり、 実行責任と権限があり、 そのアクションが評価されること 文化: 実行を繰り返し、 フィードバックを体感し、 あたりまえになっていくこと 責任・権限 誰が決め、 動かすか 評価 結果をどう測るか 基準の明文化 目指す状態を言葉にする 接点・フィードバックサイクル 全体をつなぎ、 回し続ける 実行に必要な仕組みを整え、 最終的には開発プロセスにシステムの信頼性が組み込まれる文化を目指す. © dely, Inc. All Rights Reserved. 28
29. フェーズ 3 組織に運用を定着させる、 具体的な仕組みの実践 各要素で下記のような仕組みを半年ほどかけて策定・段階的に導入 責任・権限 1 組織との運用責任・作業割合の 合意形成 2 運用責任チーム導入 3 インフラ権限設計 評価 4 システム運用 評価制度 基準の明文化 5 運用できている状態の明文化 接点・フィードバックサイクル 6 運用オンボーディング 7 モニタリング・運用定例の実施 8 Enabling SRE によるサポー ト © dely, Inc. All Rights Reserved. 29
30. フェーズ 3 組織に運用を定着させる、 具体的な仕組みの実践 それぞれの項目で中心的な取り組みを紹介します 責任・権限 1 組織との運用責任・作業割合の 合意形成 2 運用責任チーム導入 3 インフラ権限設計 評価 4 システム運用 評価制度 基準の明文化 5 運用できている状態の明文化 接点・フィードバックサイクル 6 運用オンボーディング 7 モニタリング・運用定例の実施 8 Enabling SRE によるサポー ト © dely, Inc. All Rights Reserved. 30
31. 仕組み 1 組織との責任・作業割合の合意形成 課題感を伝え、 以下を組織として合意形成. • 運用責任を開発チームでもつこと • 運用に20% 目安の時間を割くこと © dely, Inc. All Rights Reserved. 31
32. 仕組み 1 組織との責任・作業割合の合意形成 合意をとる、 というとシンプルだが、 20%とる、 みたいな話は開発速度を犠牲にする (特に短期は) ように うつるため、 丁寧な進め方が必要だった 組織と合意形成をとったときのアクション 1. 現場の違和感を組織課題として言語化する 2. 同じ課題感を持つ人と協働する 3. 組織と課題・解決策の合意形成 → 現場で危機意識を高めることで、 CTO が中長期的に安定運用する投資と判断 約3ヶ月 4. ビジョンと戦略の策定 約1か月 5. 継続的なビジョンの発信 1on1 朝会 All Hands ※ 当時知識として持っていたわけではないですが、 あらためて当時の流れを整理すると、 「ジョン・コッターの変革の8段階」 にとても近いなーと感じました. 参考: https://note.com/genda_jp/n/n19941436f36b © dely, Inc. All Rights Reserved. 32
33. 仕組み 1 組織との責任・作業割合の合意形成 2 同じ課題感を持つ人と協働する この中でも特に大事なステップ 課題を持つ人: 一人 <<<< 二人. 一人でやるより格段に課題感が伝わりやすい 今回のケースでは、 属人化を防ぐためにSRE ロールとしてのポジションを一度インフラ経験のあるバックエンドメンバーに交代していたこと で、 課題意識の冗長化ができていたことが成功の鍵でした. 現在自分だけで課題を抱えている・合意できるかわからない場合、 もう一人仲間 を作ることや役割をローテーションしてとにかく冗長化するところから始めることがオススメです. © dely, Inc. All Rights Reserved. 33
34. 仕組み 1 組織との責任・作業割合の合意形成 3 組織と課題・解決策の合意形成 まずはCTO / EMに危機感と解決策を提示 => 上位レイヤーのメンバーにはCTOがFAQ を実施することで合意 フルサイクル開発体制移行時によくでそうな質問 「今でも動いてるよね？」 → 「動いている」 のではなく、 「個人の頑張りで支えられている」 「開発で忙しい」 → 「新規採用決定のタイミングなどと合わせて段階的に移行する」 「評価されない」 → 「評価制度も合わせて変える」 「なぜ分業ではない？」 → 「運用を設計に組み込みながらスピード感を持って開発を進める ため」 © dely, Inc. All Rights Reserved. 34
35. 仕組み 1 組織との責任・作業割合の合意形成 5 継続的なビジョンの発信 一度の合意で終わらせず、 複数のチャネルで繰り返し発信し、 方針を組織に定着さ せる必要がある. 合意はただのスタートラインで、 浸透はまた別のフェーズ 1on1 個々のメンバーと目線を合わせ、 疑問や不 安を丁寧に解消する 朝会 日々の場で方針や進捗に繰り返し触れ、 チームの共通認識にする All Hands 組織全体へ向けて意義と成果を発信し、 取り組みへの理解を広げる © dely, Inc. All Rights Reserved. 35
36. 仕組み 2 運用 評価制度 組織の期待を制度として定着させるのが評価制度 ✕ 特定の人物に負荷 ◎ 組織の制度として期待が行き渡る 特定の人に依存した体制ではなく、 組織 (複数人) として意思をもてる構造に © dely, Inc. All Rights Reserved. 36
37. 仕組み 2 運用 評価制度 ── Tier 定義 Tier 1 〜 4 で役割・権限・期待を言語化し、 半期評価 Tier 化するメリット 本番環境の実行権限と紐づけることができる SREサポートの厚みをメンバー構成を見るだけで調整しやすい 弊社ではTier3 以上は実質 Embedded SRE のような立ち位置 1 運用サポート (Tier1) 本番変更権限：なし 役割 基礎知識を理解し、 運用に協力する 障害時 速やかに認識し、 関係者へ共有・エスカ レーション 3 運用自走 (Tier3) 本番変更権限：あり 役割 課題発見・解決策を策定し、 改善を自走 して実行する 障害時 正確な原因調査と、 迅速な復旧対応 4 運用管理 (Tier4) 本番変更権限：あり 役割 運用状況を把握し、 改善計画を策定・推 進する 障害時 リーダーシップを発揮し、 意思決定と復 旧を主導 協力 自走・管理 ※ 実際の定義を簡略化したもの 2 運用実践 (Tier2) 本番変更権限：あり （Runbook実行限定） 役割 サポートを受けながら課題を解決する 障害時 ログ・メトリクス調査、 影響範囲確認など 初動対応 © dely, Inc. All Rights Reserved. 37
38. 仕組み 2 運用 評価制度 ── 評価体制 運用の評価を、 現場任せにせず第三者の視点を入れて公平にまとめる体制を構築し、 評価の安定性を担保 1 各運用チームに、 担当の Enabling SRE がつく ↓ 2 Enabling SRE が、 メンバーの運用評価を セカンドオピニオンという立ち位置でまとめる ↓ 最終判断 EM ＋ バックエンドチームリーダー © dely, Inc. All Rights Reserved. 38
39. 仕組み 4 PRC の策定 今日から 「システム運用をやってください！」 は難しい——基準を設け、 システム品質の属人化を解消と理解促 進 下記項目ごとに基準を明確化 バックアップとリストア 定期的なバックアップの取得とリストア手順の整備 キャパシティ管理 リソース使用状況の把握とスケーリング戦略の明確化 監視とアラート システム全体に対する監視・アラートの整備や管理 障害対策・インシデント対応 RunBook の整備、 振り返りと再発防止策の運用 セキュリティ 最小権限設計・脆弱性管理・秘密情報の適切な取り扱 い, EOL対応 顧客への信頼性の担保 SLI / SLO の策定・依存関係, 影響範囲の明確化 リリース CI / CD の構築や開発環境・ロールバック手順の策定 作成にあたり、 Atlassian の operational readiness という指標を参考にしながら自分たちのケースを補足 atlassian.com/devops/what-is-devops/operational-readiness 基準を設けある程度均一に、 サービスを安全に運用できる状態を目指す. © dely, Inc. All Rights Reserved. 39
40. 仕組み 4 PRC の策定 PRC は GitHub でマスターを管理し、 dir ごとコピーして自サービスの Terraform リポジトリにて運用. PRC項目例 © dely, Inc. All Rights Reserved. 40
41. 仕組み 4 PRC の浸透 PRCは作って終わりではなく、 開発フローに組み込む必 要があるが、 、 弊社はスピード感のある組織 そこにPRCの理解度が薄いまま開発フローに入れると… というリスク ⇒ 既存サービスの課題洗い出しに活用して、 まずは理解度を高める 当時とったアンケート 一方で負荷が高かったという意見もあったので、 フロー を改善中 負荷が急に上がる 納得感が薄まり、 開発者がトレードオフを判断できず板挟みになる 設計 → 開発 → デプロイ → → 運用・監視 PRC 改善 フルサイクル開発体制: 同じチームがすべてのフェーズを担当 © dely, Inc. All Rights Reserved. 41
42. 仕組み 6 モニタリング・運用定例の実施 文化として定着するには、 接点とフィードバックサイクルが重要 ▶ 詳しくは：zenn.dev/dely_jp/articles/bd4423efabe67d 週 1 で運用・システムモニタリング定例 を実施 Enabling SRE との課題相談の場 © dely, Inc. All Rights Reserved. 42
43. 仕組み 6 モニタリング・運用定例の実施 やってよかったこと 基本デメリットは思いつかず、 フルサイクル開発体制をやる・やらないにかかわらず、 モニタリング定例は必須 開発 ⇄ 運用のフィードバックサイクルができ、 改善が進んだ SRE との協働の場ができた 意図しない攻撃や不当なリクエストなど、 アラートに出ないコスト・セキュリティの不具合に気づけた 特定の絵文字を付けると自動的に fullcycle-outcome チャンネル に飛ぶようにして、 成果を貯めてい っています © dely, Inc. All Rights Reserved. 43
44. RESULT 約1年半、 運用してどうなったか 運用に自然と関わる土台ができた © dely, Inc. All Rights Reserved. 44
45. 感覚値 体感としていろいろな改善が見られてきた ダッシュボードにドメイン固有の必要な指標が組み込まれて いく 着手できていなかったコスト削減に着手できる SREが見えていないドメイン固有の知見が必要な領域にアプ ローチ可能に 例) 無駄なリクエスト減により、 ECSの台数が半分に メトリクス異常の因果関係の結びつけが速い 設計段階でWAFやアラートなどの運用が考慮される 開発・運用が同じ方向を向いて会話できるようになった 例) 開発者がSREの席に来てオートスケールについて熱く議論していたり、 PRC について議論したり ◎ チーム全体で運用に対する理解度や実行力が上がり、 徐々に自走できる体制に © dely, Inc. All Rights Reserved. 45
46. 具体の成果 「開発チームで運用が回る」 を実現する、 多くの項目が改善された 領域 形骸化期 仕組みを導入して1年半 （開発者が担当） パフォーマンス改善 改善が後回しになりがち 1年弱でパフォーマンス改善 20件以上実施, 先月ワーニング チャンネルのレスポンス率が95% (AI調べ) コスト効率化 SREが優先順位をつけて対応 開発者によるインフラコスト削減額 年間 1500万円以上 キャパシティプラン ニング SREが検知・対応 - スパイク時のスケールアウトの自律的な調整・改善 - 自律的なTV負荷対策 SLI / SLO 策定 SREが作成 サービスの SLO / SLI を定義・実装・改善が実行される ダッシュボード構築 SREが作成 自律的に重要指標をダッシュボード化、 インシデント調査の起 点として常用 障害対応 SREがオンコールメイン担当 開発者のみでオンコールが回るチームがでてきた © dely, Inc. All Rights Reserved. 46
47. 具体の成果 SREチームはEmbeddedの割合が減少し、 Enablingやセキュリティのガードレール整備やチーム共通の生 産性課題の解消に時間を使えるように 3つのモード Embedded チームに入り込み、 共に運用する Enabling チームが自走できるよう支援する Platform / Security ガードレール設計 などの基盤づくり BEFORE Embedded 60% Enabling 40% AFTER Embedded 10% Enabling 20% Platform / Security 70% Embedded の比重が下がり、 Enabling・Platform・Securityへシフト © dely, Inc. All Rights Reserved. 47
48. 具体の成果 放置気味だった基盤システムが安定 ID 基盤のパフォーマンス 1/10 セキュリティ脆弱性 アラート数 1/10 CI / CD の速度 1/10 外部攻撃リクエスト 遮断数 2倍 DB / ライブラリ群は最新 に追従 管理画面のゼロトラスト 化 複数名で定期モニタリン グ Rails バージョン 6系 → 8系 © dely, Inc. All Rights Reserved. 48
49. この1年半をふりかえって うまくいってる？ ——半分 No © dely, Inc. All Rights Reserved. 49
50. 半分 NO 半分Noの理由 運用は永遠に20%固定でいいのか？ 信頼性を開発プロセスに組み込めておらず、 担当者依存 © dely, Inc. All Rights Reserved. 50
51. バランスと開発プロセスの重要性 開発・運用のバランス 開発プロセス ここが曖昧だと 現場(開発チーム)で優先順位の摩擦が起きる 事業スピードが下がるか信頼性が落ちる or 改善フェーズが膨らむ © dely, Inc. All Rights Reserved. 51
52. 再掲: 目指したチーム像 開発と運用のバランスを取りながら、 チームが自律的に品質・信頼性を担保できる 機能開発と保守運用のバランスが取れ、 事業推進スピードと品質が保たれている 運用改善が継続的に行われ、 手動運用が少なく自動化されている 障害の振り返りでフィードバックループが回り、 開発時に運用面が考慮されている © dely, Inc. All Rights Reserved. 52
53. これからの問い 20%固定で運用をやってきた結果、 運用・改 善フェーズはだいぶ整ってきた. 今後は 「バランス」 と 「シフトレフト」 © dely, Inc. All Rights Reserved. 53
54. 今後の展望: 運用固定から開発と運用のバランスをとる 1 指標の強化 開発と運用のバランスをとるための指標の 強化 2 個人の運用解像度・合意形成力 開発者一人ひとりが事業・運用を理解し、 チ ームで適切に判断・合意形成する 3 戦時モード・平時モードの可視化 最優先事業なのか、 運用改善に時間を割け る時期なのかを可視化する ※ 「戦時／平時モード」 という言葉は 『ソフトウェアエンジニアガイドブック』 第5章 「多様な環境で成功を収める」 を参照しました — oreilly.co.jp/books/9784814401215 指標だけですべてを補うのは難しい. 最終的には、 次の3つの柱でバランスを支える © dely, Inc. All Rights Reserved. 54
55. 今後の展望: 運用考慮のシフトレフト 運用・改善で得た知見を、 より前段の設計・開発フェーズへ前倒しし、 開発プロセスの一部にする ただし、 開発スタイルに合わないプロセス化は危険 設計 → 開発 → デプロイ → → 運用・信頼性考慮のシフトレフト 運用・監視 ✓ PRC 改善 ✓ フルサイクル開発体制: 同じチームがすべてのフェーズを担当 シフトレフトにより、 改善フェーズの負荷を削減することができ開発速度が早くなる © dely, Inc. All Rights Reserved. 55
56. 結論 現状組織に仕組みを組み込むことで、 達成されたのは—— ◎ 信頼性と運用の理解を促進し、 実行される組織の土台ができた. フィードバックサイクル が回るようになった これから 積み上げてきたフィードバックを活かして適切な信頼性への投資と信頼性注入のシフ トレフト © dely, Inc. All Rights Reserved. 56
57. まとめ SRE のプラクティスが組織の仕組みと紐づいていないと形骸化した 信頼性と運用が実行される土台を作り、 フィードバックサイクルが回るようになった SRE プラクティスはツールとして不可欠だが、 浸透そのものを促すものではない 今後は、 現状状況に応じた開発と運用のバランスが取れる状態を目指す © dely, Inc. All Rights Reserved. 57
58. バックエンドエンジニア採用強化中 実際にフルサイクル開発体制で開発しているエンジニアのインタビュー記事もあるので、 ぜひ参考にしてくださ い！ 「クラシルリテールネットワーク」 立ち上げから1年 半 ─ 急成長の裏側と開発チームの現在地 note.com/kurashiru_jp/n/nab448faa67f5 AI時代に淘汰されないエンジニアに。 「フルサイク ル開発」 と 「新規立ち上げ」 の両軸を担う note.com/kurashiru_jp/n/nf08a54264806 「レシチャレ」 1,000万DLを支えてきた開発のリア ル ─ スケールの舞台裏とこれから note.com/kurashiru_jp/n/n94b206bf668d © dely, Inc. All Rights Reserved. 58
59. THANK YOU ご清聴、 ありがとうございました. © dely, Inc. All Rights Reserved. 59