SREには開発組織全体で向き合う

Transcript

1. SREには開発組織全体で向き合う 株式会社スリーシェイク　永瀬滉平 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. - 所属: 株式会社スリーシェイク - 仕事: マネージャー・エンジニア - 所在: 岩手県某所 - 今年は雪が多くなりそうな予感がしています 永瀬 滉平 (@koh_naga)
3. Copyright © 3-shake, Inc. All Rights Reserved. 会社名 株式会社スリーシェイク 設立日 2015/1/15 Mission: インフラをシンプルにして イノベーションが起こりやすい世界を作る 3 About US Vision: 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける Value: エンジニアリングレイヤーに横たわる人、手法、ツールが サイロ化されて労苦が発生しているプロセスをシンプルにし サービス機能開発に集中できるソリューション （SRE、DevSecOps、DataOps、HROps）を提供する 2015 2016 2017 2018 2019 2020 2021 2022 0 50 100 従業員: 200名over Engineer 60% 所在地 東京都中央区銀座8丁目21番1号 　　 住友不動産汐留浜離宮ビル7F　 代表者 代表取締役社長　吉田 拓真 沿革 2021年1月 JAFCOから総額5億円の資金調達 2022年8月 自動脆弱性診断ツール「Securify Scan」をリ リース。JAFCO、MUCAPから総額8.48億円の資金調達 2025年9月29日 新オフィスに移転 Googleクラウド・AWSの両方のエンジニアリングに強みを持つ （2024年8月に国内2例目の、GoogleCloudのDevOpsスペシャライゼーションを取得） Google Cloud×SRE / GenAIにおいて、スリーシェイクは国内トップパートナー
4. SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ対 策を全方位支援 ・Geminiを用いた生成AIの活用支援 ・ワンストップで脆弱性診断を行う セキュリティ対策SaaS ・クラウド型ETL/データパイプ ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランスエンジニ ア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上
5. SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 SRE/DevOps SecOps BizOps HR ・SRE総合支援からセキュリティ対 策を全方位支援 ・Geminiを用いた生成AIの活用支援 ・ワンストップで脆弱性診断を行う セキュリティ対策SaaS ・クラウド型ETL/データパイプ ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランスエンジニ ア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上 Sreake事業でSREに関するコンサルを実施している中で感じた難しさを共有し、 そこから得られた SRE的なムーブメントの定着で大事なことをお話したいと思います。
6. 何があった？ 01 Copyright © 3-shake, Inc. All Rights Reserved.
7. 何があった？ 私が行なっていたコンサル業務では以下のような状況があった • ミッションも見直してインフラチームではなく SREチームを立ち上げたものの、 今までのようにインフラ作業担当に終始している • 業務が逼迫していて SLO/SLI、トイル削減といったいわゆる SRE的な業務内容に取り組めていない • チームメンバーも依頼に対して言われた作業を行うに終始しており、ビジネス観点から意義のある仕事になっ ているかが懐疑的 状況打破とともに、開発生産性向上や全社的な課題解決に取り組ん でいく術を模索していく
8. どうもつながっている気がする・・・
9. どうもつながっている気がする・・・ ミッションも見直してインフラチームではなく SREチームを立ち上げたものの、 今までのようにインフラ作業担当に終始している 業務が逼迫していて SLO/SLI、トイル削減といったいわゆる SRE的な業務内容に取り組めていない チームメンバーも依頼に対して言われた作業を行うに終始しており、ビジネス観点から意義のある仕事になっている かが懐疑的 • 部門横断化したため全プロダクトチームから業務依頼が発生する • BIシステムや各種ツール管理などプロダクト開発業務以外が集約しやすくなってし まった • 発生する作業がどこに端を発していて、どのような課題を解決するかの理解が十 分でないまま業務に当たっている
10. どうもつながっている気がする・・・ ミッションも見直してインフラチームではなく SREチームを立ち上げたものの、 今までのようにインフラ作業担当に終始している 業務が逼迫していて SLO/SLI、トイル削減といったいわゆる SRE的な業務内容に取り組めていない チームメンバーも依頼に対して言われた作業を行うに終始しており、ビジネス観点から意義のある仕事になっている かが懐疑的 • 部門横断化したため全プロダクトチームから業務依頼が発生する • BIシステムや各種ツール管理などプロダクト開発業務以外が集約しやすくなってし まった • 発生する作業がどこに端を発していて、どのような課題を解決するかの理解が十 分でないまま業務に当たっている 業務量の増加 プロダクトチームとSREチームのサイロ化
11. プロダクトチーム側の状況はどうだろうか？
12. プロダクトチーム側の状況はどうだろうか？ 経営的には機能追加や既存機能のアップデートなどを通して、企業価値向上にコミットしたい。 やりたいことはどんどん出てくるが、開発が追いつかない・・・ ここを直して... この機能も追加して... ここを直して... この機能も追加して... 間に合わない・・・ リクエスト
13. プロダクトチーム側の状況はどうだろうか？ 経営的には機能追加や既存機能のアップデートなどを通して、企業価値向上にコミットしたい。 やりたいことはどんどん出てくるが、開発が追いつかない・・・ ここを直して... この機能も追加して... ここを直して... この機能も追加して... 間に合わない・・・ リクエスト プロダクトチームも必死だった
14. システム部門内でできることから始めてみる 02 Copyright © 3-shake, Inc. All Rights Reserved.
15. システム部門内でできることから始めてみる • 課題はあれど、システム自体は障害だらけというわけではなくしっかり運用できている状況がある • システム部門全体が業務逼迫状況にあるので、トップダウンで取り組みを増やしかねない状況は避けて、自 部門内でできる小さな取り組みからまずは始めてみる • SLO/SLIといった SRE的な取り組みに着手する前に、部門内が一枚岩で動ける土壌づくりが必須 -> プロダクトチームとSREチームのサイロ化の解消 パフォーマンス計測のための継続的負荷試験環境を構築する案件を立ち上げる プロダクトチームに所掌範囲におけるインフラの責務を追加する チーム間移動や組織改変
16. プロダクトチームとSREチームのサイロ化 課題感（再掲） • お互いのチームが状況を把握できておらず、互いを慮りながらの仕事になっていない • 発生する作業がどこに端を発していて、どのような課題を解決するかの理解が十分でないまま業務に当たっ ている まずはコミュニケーションをコンスタントに取れている状態を作りたい！ SREチームもプロダクトチームの MTGに参加して、口頭で依頼をもらったり、案件があれば冒頭から入ってアー キの妥当性を一緒に考える。 プロダクトチーム: xx機能追加に着手します！ SREチーム: アーキテクト的にはaaをbbのようにする方がいいと思います！ プロダクトチーム: 開発でhogehogeという問題があるのでインフラでこういう 変更をお願いしたいです SREチーム: 了解です、持ち帰って相談してみます！
17. 稼働逼迫の軽減 課題感（再掲） • SREチームもプロダクトチームも稼働が逼迫 前段のコミュニケーションの中から、費用対効果が高そうな自動化や業務効率化の芽を見つけて SREチームで 対応する。 注意：プロダクトチームもタスクやインプットが増えることで認知負荷が高くなるのは避けたいと思うので、自動化 にしてもプロダクトチームに使ってもらうというものではなく、 SREチームが依頼を楽に捌けるようにというコンセ プトで始めるなどの配慮が必要 互いに敵だと思われたり、自分たちの負荷を増やしてくる人たちだと思われると辛い 環境変数の変更依頼が多いから、まずはここをプロダクトチーム内で完結できる仕組み 作りをしよう。 ECSタスク・サービス作成は大体触るパラメータが固定化してきたから、テンプレート 化して手順少なく作れるようにしよう。
18. 終わりに 03 Copyright © 3-shake, Inc. All Rights Reserved.
19. 終わりに 今回お話した改善に向けた大まかな方針は以下の通り。 1. SREのプラクティスに取り組む前に組織としてコミュニケーションがしっかり取れて、一枚岩で動ける状態を目 指す 2. メンバーに余裕がなければ新しい取り組みや改善活動も差し込めないため、互いに協力しながら少しずつ稼 働的にも精神的にも余裕を産んでいく 3. 余裕を生かして大きな効果を得れる、トイル削減や SREプラクティスの実践のようなトピックにチャレンジする
20. 終わりに SREのプラクティスに取り組んでいくには一定のハードルがあると思う • SREプラクティスを実践していくこと自体幅広い領域に及ぶため、アプリ・インフラ間に垣根があるだけで遂行のハードルにな る • Google社に倣うだけでは抱えているシステム規模などの前提が違うので、自分たちなりに濃淡を考えてチューニングは必要 • 「信頼性」の定義自体が事業規模やユーザ性質の変化に伴って変わってくる可能性もある • SREチームだけが気を吐いて頑張っても、ビジネス上のメリットが理解されず評価されない可能性もある これらのことから市場競争力を強く気にするプロダクト部門やビジネス部門、ひいては経営層と密接に関連し 合いながら SRE組織は動いていくことが必要になる
21. ご清聴ありがとうございました 3-shakeでは一緒に働く仲間を募集しています！ 気になる求人がありましたらぜひお話を聞きにきてください Copyright © 3-shake, Inc. All Rights Reserved.