Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
入社後SREチームのミッションや課題の整理をした話
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Morix
April 04, 2025
Technology
570
1
Share
入社後SREチームのミッションや課題の整理をした話
株式会社tacomsにSREチームとして入社後、課題の進め方に関する課題があった。
課題をどう整理していったかを紹介していく。
Morix
April 04, 2025
More Decks by Morix
See All by Morix
AIでAIをテストする - 音声AIエージェントの品質保証戦略
morix1500
1
170
[EC2からKubernetes]楽天ラクマのコンテナ化の歩み
morix1500
24
8.9k
AWS EKSでClusterAutoscalerを使うときはNodeGroupの分け方に気をつけろ!
morix1500
0
1k
FirebaseとNetlifyを使ってサーバーレスでサービスを作った話
morix1500
2
3k
オーバーロードで学んだチームマネジメント / Team management learned through overlord
morix1500
1
2.2k
転職をする前にやっておきたいこと / What you want to do before you change your career
morix1500
0
4.1k
自分を強くするためにやってきたこと
morix1500
7
2.7k
個人事業主になりたい!どうやって?調べてみよう!
morix1500
1
450
負荷試験入門
morix1500
0
1.7k
Other Decks in Technology
See All in Technology
拝啓、あの夏の僕へ〜あなたも知っているApp Runnerの世界〜
news_it_enj
0
240
自動テストだけで リリース判断できるチームへ - 鍵はテストの量ではなくリリース判断基準の再設計にあった / Redesigning Release Criteria for Lightweight Releases
ewa
7
3.6k
Purview Endpoint DLP 動かしてみた
kozakigh
0
340
なぜ、私がCommunity Builderに?〜活動期間1か月半でも選出されたワケ〜
yama3133
0
120
[Scram Fest Niigata2026]Quality as Code〜AIにQAの思考を再現させる試み〜
masamiyajiri
1
310
Sociotechnical Architecture Reviews: Understanding Teams, not just Artefacts
ewolff
1
160
そのSLO 99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜 / Is that 99.9% SLO really necessary? Design philosophy of shared responsibility through prioritized SLOs
vtryo
0
570
AIが盛んな時代に 技術記事を書き始めて起きた私の中での小さな変化
peintangos
0
370
フロントエンドの相手が変わった - AIが加わったWebの新しいインターフェース設計
azukiazusa1
33
11k
AIが自律的に働く時代へ Amazon Quick で実現するAIエージェント紹介
koheiyoshikawa
0
200
AIの揺らぎに“コシ”を与える階層化品質設計
ickx
0
270
小さいVue.jsを30分で作る
hal_spidernight
0
150
Featured
See All Featured
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.4k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
190
Music & Morning Musume
bryan
47
7.2k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
0
300
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
540
Crafting Experiences
bethany
1
140
4 Signs Your Business is Dying
shpigford
187
22k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
2k
Done Done
chrislema
186
16k
Transcript
⼊社後SREチームのミッションや課題 の整理をした話 株式会社tacoms SREチーム Morix 2025/04/04 ゆるSRE勉強会 #10
⾃⼰紹介 • 2024年11⽉に株式会社tacomsに⼊社 • SREチーム テックリード兼マネージャー • 1児(3歳)のパパ • 最近の趣味はランニング
• SRE NEXT 2025のコアスタッフ ⻄野翔太 ( Morix )
01 tacomsについて About tacoms
None
None
6 あらゆるサービスとAPIで連携 店舗の課題を解決するSaaS「Camel」 注⽂サイト POS‧基幹システム
7 店外注⽂への、店舗オペレーションが 1台のタブレットで全て完結 タブレットが乱⽴ 1台のタブレットで完結
02 本題 Main Theme
アジェンダ • tacomsのSREチームの当時の課題感の共有 • 課題の整理をどう進めたかの紹介
tacomsのSREチームの構成 • 4名(2025/04現在) • 参画時期 ◦ 1⼈⽬: 2022/03 ◦ 2⼈⽬:
2024/07 ◦ 3⼈⽬: 2024/10 ◦ 4⼈⽬: 2024/11 ← 私 • できたてのチーム!!
私が⼊った当時のSREチームの課題 • 今後やりたいことは⾊々あったがどう進めていくか整理できてない • 課題がたくさんあったがどう進めていくか整理できてない • ⾒えてない課題もいろいろありそう
課題整理のゴール • 半年先くらいまでの開発計画を⽴てられるようにすること • CTOやSREメンバーが納得感のある計画を⽴てるための優先度の考え⽅ を決めること
課題整理の進め⽅ 課題の内容理解 課題からミッションを抽出 ミッションをもとに⾒えない課題の洗い出し ミッションからプロジェクトへの落とし込み 課題を再整理しプロジェクトに分類 開発計画の作成‧プロジェクトにメンバーアサイン
1.課題の内容理解 • GitHub issuesにSREの課題や今後やりたいことを挙げてくれていた • それらをCTOやSREメンバーに説明してもらい内容の理解 • SRE全員で内容理解を進めたのでチームビルディングにもなった
2.課題からミッションの抽出 • 課題や今後やりたいことを整理すると以下の4つのカテゴリに分類できた • これらをSREの「ミッション」として定義した
3.ミッションをもとに⾒えない課題の洗い出し • まだ⾒えてない課題を洗い出すためにISO/IEC 25010:2011を参考にした • この規格はソフトウェアの品質に関する国際標準規格 • これらの品質特性を向上させることが我々のミッションと⾔えそう ISO/IEC 25010:2011について:https://www.iso.org/standard/35733.html
3.ミッションをもとに⾒えない課題の洗い出し • 直近1年で注⼒すべき品質特性を定めた • 今まで挙がっていた課題を品質副特性に当てはめていくと、課題が少ない or挙がっていない品質副特性があった • その特性で課題がなさそうかを⾃分で調べたり周りにヒアリングし新たな 課題を⾒つけられた
4.ミッションからプロジェクトへの落とし込み • 課題が⼀通り洗い出せたので、どうやって進めるかを考えた • 課題の他にも今後やりたいこともある。しかし、やりたいこと=プロジェ クトとはならない • 例えば「この時期までに〇〇というイベント時のアクセススパイクに耐え られるようにしたい」というやりたいことがあった場合 ◦
アプリケーションのあの部分のパフォーマンスをあげたほうがいい ◦ インフラのこの部分のスケーラビリティをあげたい ◦ 過度なアクセスは待機画⾯にしたい • これらはひとつのプロジェクトとして進めるには重い • そのため「やりたいこと」をストラテジーと命名
4.ミッションからプロジェクトへの落とし込み • 次のような3層構造でプロジェクトを管理するようにした • プロジェクトの⽬的がわかりやすく、納得感を持って仕事ができる! ミッション ストラテジー プロジェクト
5.課題を再整理しプロジェクトに分類 • 課題やストラテジーを1つ1つ⾒ていき次のように分類 ◦ ストラテジーまたは重要な課題で注⼒品質副特性に当てはまるもの ▪ -> ストラテジープロジェクト ◦ 重要な課題だが注⼒品質副特性に当てはまらないもの
▪ -> バックログプロジェクト ◦ 軽い課題 ▪ -> バックログタスク • 基本的にストラテジープロジェクトを優先し、プロジェクトの切れ⽬や⼿ が空いたときにバックログプロジェクトやバックログタスクをやる
6.開発計画の作成‧プロジェクトにメンバーアサイン • 今回整理した結果をもとに開発計画(ロードマップ)を作成しプロジェク トにメンバーをアサインした • SREのメンバーはプロジェクトロードマップを⾒れば今後⾃分たちがやる ことがわかるようになった • 私とCTOはストラテジーロードマップをもとにコミュニケーションをすれ ばよくなった
• みんなが納得感のある計画を作れるようになった!!
まとめ • 新しいチームにジョイン後に課題整理をするのはチームの責任範囲やシス テムの把握に役⽴つ • チームのミッションを定義することで、そこから⾒える課題をカテゴライ ズしたり、システムの品質特性をもとに⾒えてない課題を洗い出せた • ミッションをもとにストラテジーが⽣まれ、そこからプロジェクトに落と し込み、プロジェクトの⽬的を忘れないようにできた
• 課題をプロジェクト化し、ロードマップにまとめ、納得感のある計画を作 れた