2,500万ユーザーを支えるSREチームの6年間のスクラムのカイゼン

by HonMarkHunt

Slide 1

Slide 1 text

©MIXI 2,000万ユーザーを支える SREチームの6年間のスクラムのカイゼン SRE Kaigi 2025 2025/01/26 15:05〜ルーム B 5

Slide 2

Slide 2 text

©MIXI 本間匡晃(ホンマークハント) (株)MIXI みてねプラットフォーム部 SREグループマネージャー・4歳と1歳の娘がいます・スニーカー収集・筋トレ・キャンプ・先週だけで2足買ってしまった・iPadの購入を検討して早2年経過 @HonMarkHunt @honmarkhunt

Slide 3

Slide 3 text

©MIXI サービス紹介

Slide 4

Slide 4 text

©MIXI 家族アルバムみてねはスマホで撮った子どもの写真や動画を家族と共有し、コミュニケーションして楽しむ家族アルバムサービスです。

Slide 5

Slide 5 text

©MIXI * iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合計

Slide 6

Slide 6 text

©MIXI 世界中の家族のこころのインフラをつくるみてね事業のMVV | Mission

Slide 7

Slide 7 text

©MIXI Agneda ❏ スクラム失敗の歴史 ❏ SRE x スクラムの難しさ ❏ みてねでの対応 ❏ 現在のスクラム ❏ まとめ

Slide 8

Slide 8 text

©MIXI スクラム失敗の歴史

Slide 9

Slide 9 text

©MIXI 前提　スクラム ❏ みてねSREは6年前のチーム発足時からスクラムを採用 ❏ プロダクトチームで採用されていたのでそのまま流用される形で導入 ❏ 2年ほど前から組織全体でアジャイル/ スクラムの導入促進 ❏ みてねのエンジニアリング組織のこれまでとこれから ❏ 組織のVisionに“Be Agile” 　組織 ❏ 6人 ❏ Embedded SREではなく独立チームで支援するSRE ❏ Platform Engineeringも兼ねている SRE A B C プロダクトチーム支援

Slide 10

Slide 10 text

©MIXI 　昔のスクラムの流れ Product Backlog Backlog Refinement Sprint Review Retrospective Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum

Slide 11

Slide 11 text

©MIXI 　昔のスクラムの流れ Spring Review Spring Planning Sprint : 1week 1day SRE Team Daily Scrum Product Backlog Backlog Refinement ❏ SREとしてやるべきことをProduct Backlogにまとめる ❏ 優先度順に並んでいる ❏ 上から順番に着手 ❏ Backlog Refinement ❏ Backlog Itemの作成 ❏ Story Pointの付与 ❏ 優先度の並び替え ❏ Pivotal Trackerを使用 Retrospective

Slide 12

Slide 12 text

©MIXI 　昔のスクラムの流れ Product Backlog Backlog Refinement Spring Review Retro Spective Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Sprint Planning ❏ 開始時に今Sprintでどこまでやるかを設定する ❏ 概ね個人ごとにBacklog Itemがアサインされているので実質終わるまでやるのであまり意味はなしてなかった ❏ Sprint Backlogまでは作成していなかった ❏ Sprint Goalも未設定

Slide 13

Slide 13 text

©MIXI 　昔のスクラムの流れ Product Backlog Backlog Refinemnet Sprint Review Spring Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Sprintは1week ❏ 2wになったりもしたが今は1wで落ち着いている ❏ 期間中は個人にアサインされてるタスクを各自消化していく ❏ Daily Scrum ❏ やる/やったなどの共有 ❏ 思わず長くなることも Retrospective

Slide 14

Slide 14 text

©MIXI 　昔のスクラムの流れ Product Backlog Backlog Refinement Sprint Review Spring Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Sprint Review ❏ ステークホルダーにSprintの成果を共有 ❏ Product Ownerは1名 ❏ 部長数名 ❏ Velocityの変化も共有 ❏ チーム内でやったことの共有も別の時間で行う ❏ PRを見たり ❏ 仕様の質問したり Retrospective

Slide 15

Slide 15 text

©MIXI 　昔のスクラムの流れ Product Backlog Backlog Refinement Spring Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Retro Spective ❏ Sprintの終わりに実施 ❏ KPT ❏ Pivotal Tracker Retrospective

Slide 16

Slide 16 text

©MIXI SRE x スクラムの難しさ

Slide 17

Slide 17 text

©MIXI 　実際にやってみて難しいと感じた点 Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Retrospective

Slide 18

Slide 18 text

©MIXI 　差し込みが多い Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Alert対応問い合わせ対応他チームとの連携 Sprint開始時に立てた計画何も全うできない Retrospective

Slide 19

Slide 19 text

©MIXI 　 Backlogがわんぱくになる Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum アラートや問い合わせも管理課題とタスクが両立 SREのタスクユーザーストーリーにしにくい！ Retrospective

Slide 20

Slide 20 text

©MIXI 　補足: わんぱくBacklogによる属人化 8P 1P 13P 1P 1P Product Backlog 1. せっかくなのでやるべきことは全部Backlogにまとめる 2. 元々持っていた大きな課題を追加する 3. アラートの恒久対応やポストモーテム後の対応なども追加する 4. 結果Backlogに細かいタスクと大きな課題が共存する

Slide 21

Slide 21 text

©MIXI 　補足: わんぱくBacklogによる属人化 8P 1P 13P 1P 1P Product Backlog 5. Backlogの上から順に着手していく 6. 細かい課題は即消化されていくので最終的にみんなでかいタスクを　取ったところで止まる

Slide 22

Slide 22 text

©MIXI 　補足: わんぱくBacklogによる属人化 7. でかいタスクを個人で消化していくので 8. 続けていくと「なんとなくこの辺はxxさん」のような暗黙のアサイン = 属人化 9. 問い合わせなどもなんとくなく属人的になる 1P 1P 13P 8P 13P Product Backlog

Slide 23

Slide 23 text

©MIXI 　中長期目標が描きづらい Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum 気づいたらアップデートばっかりしてた中長期的に物事を成し遂げるのが難しい Retrospective

Slide 24

Slide 24 text

©MIXI 　細かいこと言うともっとあるが.... Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Sprint Goalってなんだっけ！ SREのステークホルダー is 誰？ Retrospective

Slide 25

Slide 25 text

©MIXI みてねSREでの対応

Slide 26

Slide 26 text

©MIXI みてねSREでの対応それぞれ深掘りして考えてみてねSREで行った対策を紹介していきます ❏ 差し込みが多い ❏ Backlogがわんぱくになる ❏ 中長期目標が描きづらい

Slide 27

Slide 27 text

©MIXI 差し込みが多い

Slide 28

Slide 28 text

©MIXI 差し込みが多い差し込み(計画外)は全ての職種で発生している ❏ デザイン「POに見せたら毎回想定と違う手直しが...」 ❏ フロントエンド「デザインやバックエンドの変更に左右される...」 ❏ バックエンド「ユーザー問い合わせの調査が...」一般論だとSprint期間中に発生した計画外の出来事は減らす or コントロールする。 SREの「差し込み」はPlatformerとしてのホスピタリティ担保のため減らすのが難しかったり、アラートなど外部起因でコントロールが難しいものが多いのでSREには一般論が当てはまらない難しさがある。

Slide 29

Slide 29 text

©MIXI 差し込みが多い SREはアラート対応、Platformerとしてのサポートなど計画外で優先度の高い対応が多い改めて、差し込みが多いと何が問題なのか？ ❏ Sprintの最初に立てたPlanningの通りにならない ❏ Velocityが安定しない ❏ Sprint Goalが達成できない実は価値提供に直結する問題はない？

Slide 30

Slide 30 text

©MIXI ❏ 差し込み業務はあるものと割り切る ❏ サポートや相談を減らそうとすることで聞きづらい雰囲気になるならいっそ割り切る ❏ toilの文脈とは別 ❏ Velocityを計測しない ❏ 他職種に比べマーケットプレッシャーが少ない ❏ Sprint Goalを設定しない ❏ とはいえ目標は必要なので月単位で目標を設定し、Sprint単位で達成率の確認差し込みが多い対策

Slide 31

Slide 31 text

©MIXI Backlogがわんぱくになる

Slide 32

Slide 32 text

©MIXI BacklogがわんぱくになるなぜわんぱくBacklogが生まれるのか？ ❏ PO/PdMの不在 ❏ SREチームには本来Backlogを見てくれるはずのPO/PdMがいないケースが多いため自ら管理する必要が有る ❏ チームが成熟してBacklogを委譲されるのではなく、最初から自分たちだと難しい ❏ アップデート系のタスクなど定常業務がユーザーストーリーベースのBacklogアイテムと相性が悪い ❏ Backlogを整理しようとしてユーザーストーリーベースの書き方をしようとしてもアップグレードやEOL対応などの取り扱いが難しい ❏ 課題ベースでBacklogアイテムを作りたいが「xx.xへアップグレード」以外書く事がない

Slide 33

Slide 33 text

©MIXI Backlogがわんぱくになる対策 ❏ Backlogで管理するものとその他を切り分ける ❏ 「Backlogが複数できる問題」はあるが、所謂差し込みはTODOとしてBacklogとは別で管理 ❏ 一番恐ろしいのは「属人化」 ❏ 数週間以上かかる/属人性の高くなる恐れのあるタスクのみBacklogで管理する ❏ Backlogに追加するかどうかはRefinement以外でも常に会話 ❏ ベースの会話の回数を増やすことも重要

Slide 34

Slide 34 text

Slide 35

Slide 35 text

©MIXI 中長期の目標が描きづらいなぜ中長期のヴィジョンを描きづらいのか？ ❏ そもそもスクラムが中長期のフレームワークを提供していない ❏ SREはEOLの対応など目先の優先度の高い業務が多く、短期的には意味のあることを続けているはずが中長期ではあまり積み重ねできていないパターンになる事が多い

Slide 36

Slide 36 text

Slide 37

Slide 37 text

©MIXI 現在のスクラム

Slide 38

Slide 38 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Sprint Review 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum Retrospective

Slide 39

Slide 39 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Spring Review Retro Spective 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Backlog Refinement ❏ 事前に必要なフォーマットを記入しておく ❏ アップデートなどのタスクもBacklogアイテムとして扱う ❏ 時間が短く再実行などの懸念がないものは個人タスクとして取り扱う ❏ 全員でStory Point, 事業インパクトの見積もりを実施 ❏ 優先度の並び替えを実施 ❏ Pivotal Tracker → Spread Sheat

Slide 40

Slide 40 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Spring Review Retro Spective 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏

Slide 41

Slide 41 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Spring Review Retro Spective 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Sprint Planningは廃止 ❏ 月単位で着手する Backlogに目標設定 ❏ Backlog着手時に Planning(タスク分解)を実施 ❏ Notion ❏ Backlogは大きいまま取り扱う ❏ 属人化を防ぐためチームを 2つに分解 ❏ 1チームが1つのBacklogに着手している状態 ❏ リソース効率とフロー効率 ❏ チームは毎月ランダムに1 名を交換

Slide 42

Slide 42 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Sprint Review 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Sprint Review ❏ 達成した価値のみを共有 ❏ Velocityの計測はやめたので共有も廃止 ❏ チーム内のReview ❏ 2チーム制にしたため細かいコードの共有は廃止 ❏ 同じチームのメンバーは細かいことまで理解できているので属人化を回避できるようになった ❏ 価値とは別で共有したいことは別のタイムボックスを用意して共有 Retrospective

Slide 43

Slide 43 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Spring Review 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Retrospective ❏ 変わらずにSprint 毎に実施 ❏ KPT → Good/Bad/Fact/Emotion ❏ Pivotal Tracker → Miro ❏ Sprintとは別のタイムボックスの振り返りを実施 ❏ 数ヶ月に一回スクラムそのものの振り返りを実施 ❏ 普段の振り返りとは別でスクラムそのもののカイゼンのアイディア出し Retrospective

Slide 44

Slide 44 text

Slide 45

Slide 45 text

©MIXI 　現在のスクラム Product Backlog Backlog Refinement Spring Review 月目標設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Retro Spective ❏ 変わらずにSprint 毎に実施 ❏ KPT → Good/Bad/Fact/Emotion ❏ Pivotal Tracker → Miro ❏ Sprintとは別のタイムボックスの振り返りを実施 ❏ 数ヶ月に一回スクラムそのものの振り返りを実施 ❏ 普段の振り返りとは別でスクラムそのもののカイゼンのアイディア出し Retrospective

Slide 46

Slide 46 text

©MIXI まとめ

Slide 47

Slide 47 text

©MIXI まとめ ❏ 「差し込み」は意外と怖くないかもしれない ❏ 価値に繋がらずコントロールが難しい要素は勇気を持って捨てるか受け入れる ❏ ベースの会話の回数は大事 ❏ Refinement以外でもSlackや他のスクラムイベント中にもBacklogについて触れたりなど ❏ 「スクラム最高！SREも絶対スクラム！」とは言わないが「SREだからスクラムは無理」と諦めるのは勿体無いかも