Slide 1

Slide 1 text

⼊社後SREチームのミッションや課題 の整理をした話 株式会社tacoms SREチーム Morix 2025/04/04 ゆるSRE勉強会 #10

Slide 2

Slide 2 text

⾃⼰紹介 ● 2024年11⽉に株式会社tacomsに⼊社 ● SREチーム テックリード兼マネージャー ● 1児(3歳)のパパ ● 最近の趣味はランニング ● SRE NEXT 2025のコアスタッフ ⻄野翔太 ( Morix )

Slide 3

Slide 3 text

01 tacomsについて
 About tacoms

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

6 あらゆるサービスとAPIで連携 店舗の課題を解決するSaaS「Camel」 注⽂サイト POS‧基幹システム

Slide 7

Slide 7 text

7 店外注⽂への、店舗オペレーションが 1台のタブレットで全て完結 タブレットが乱⽴ 1台のタブレットで完結

Slide 8

Slide 8 text

02 本題
 Main Theme

Slide 9

Slide 9 text

アジェンダ ● tacomsのSREチームの当時の課題感の共有 ● 課題の整理をどう進めたかの紹介

Slide 10

Slide 10 text

tacomsのSREチームの構成 ● 4名(2025/04現在) ● 参画時期 ○ 1⼈⽬: 2022/03 ○ 2⼈⽬: 2024/07 ○ 3⼈⽬: 2024/10 ○ 4⼈⽬: 2024/11 ← 私 ● できたてのチーム!!

Slide 11

Slide 11 text

私が⼊った当時のSREチームの課題 ● 今後やりたいことは⾊々あったがどう進めていくか整理できてない ● 課題がたくさんあったがどう進めていくか整理できてない ● ⾒えてない課題もいろいろありそう

Slide 12

Slide 12 text

課題整理のゴール ● 半年先くらいまでの開発計画を⽴てられるようにすること ● CTOやSREメンバーが納得感のある計画を⽴てるための優先度の考え⽅ を決めること

Slide 13

Slide 13 text

課題整理の進め⽅ 課題の内容理解 課題からミッションを抽出 ミッションをもとに⾒えない課題の洗い出し ミッションからプロジェクトへの落とし込み 課題を再整理しプロジェクトに分類 開発計画の作成‧プロジェクトにメンバーアサイン

Slide 14

Slide 14 text

1.課題の内容理解 ● GitHub issuesにSREの課題や今後やりたいことを挙げてくれていた ● それらをCTOやSREメンバーに説明してもらい内容の理解 ● SRE全員で内容理解を進めたのでチームビルディングにもなった

Slide 15

Slide 15 text

2.課題からミッションの抽出 ● 課題や今後やりたいことを整理すると以下の4つのカテゴリに分類できた ● これらをSREの「ミッション」として定義した

Slide 16

Slide 16 text

3.ミッションをもとに⾒えない課題の洗い出し ● まだ⾒えてない課題を洗い出すためにISO/IEC 25010:2011を参考にした ● この規格はソフトウェアの品質に関する国際標準規格 ● これらの品質特性を向上させることが我々のミッションと⾔えそう ISO/IEC 25010:2011について:https://www.iso.org/standard/35733.html

Slide 17

Slide 17 text

3.ミッションをもとに⾒えない課題の洗い出し ● 直近1年で注⼒すべき品質特性を定めた ● 今まで挙がっていた課題を品質副特性に当てはめていくと、課題が少ない or挙がっていない品質副特性があった ● その特性で課題がなさそうかを⾃分で調べたり周りにヒアリングし新たな 課題を⾒つけられた

Slide 18

Slide 18 text

4.ミッションからプロジェクトへの落とし込み ● 課題が⼀通り洗い出せたので、どうやって進めるかを考えた ● 課題の他にも今後やりたいこともある。しかし、やりたいこと=プロジェ クトとはならない ● 例えば「この時期までに〇〇というイベント時のアクセススパイクに耐え られるようにしたい」というやりたいことがあった場合 ○ アプリケーションのあの部分のパフォーマンスをあげたほうがいい ○ インフラのこの部分のスケーラビリティをあげたい ○ 過度なアクセスは待機画⾯にしたい ● これらはひとつのプロジェクトとして進めるには重い ● そのため「やりたいこと」をストラテジーと命名

Slide 19

Slide 19 text

4.ミッションからプロジェクトへの落とし込み ● 次のような3層構造でプロジェクトを管理するようにした ● プロジェクトの⽬的がわかりやすく、納得感を持って仕事ができる! ミッション ストラテジー プロジェクト

Slide 20

Slide 20 text

5.課題を再整理しプロジェクトに分類 ● 課題やストラテジーを1つ1つ⾒ていき次のように分類 ○ ストラテジーまたは重要な課題で注⼒品質副特性に当てはまるもの ■ -> ストラテジープロジェクト ○ 重要な課題だが注⼒品質副特性に当てはまらないもの ■ -> バックログプロジェクト ○ 軽い課題 ■ -> バックログタスク ● 基本的にストラテジープロジェクトを優先し、プロジェクトの切れ⽬や⼿ が空いたときにバックログプロジェクトやバックログタスクをやる

Slide 21

Slide 21 text

6.開発計画の作成‧プロジェクトにメンバーアサイン ● 今回整理した結果をもとに開発計画(ロードマップ)を作成しプロジェク トにメンバーをアサインした ● SREのメンバーはプロジェクトロードマップを⾒れば今後⾃分たちがやる ことがわかるようになった ● 私とCTOはストラテジーロードマップをもとにコミュニケーションをすれ ばよくなった ● みんなが納得感のある計画を作れるようになった!!

Slide 22

Slide 22 text

まとめ ● 新しいチームにジョイン後に課題整理をするのはチームの責任範囲やシス テムの把握に役⽴つ ● チームのミッションを定義することで、そこから⾒える課題をカテゴライ ズしたり、システムの品質特性をもとに⾒えてない課題を洗い出せた ● ミッションをもとにストラテジーが⽣まれ、そこからプロジェクトに落と し込み、プロジェクトの⽬的を忘れないようにできた ● 課題をプロジェクト化し、ロードマップにまとめ、納得感のある計画を作 れた