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

SRE Kaigi 2025の登壇資料です #srekaigi

https://fortee.jp/sre-kaigi-2025/proposal/ba2b0f88-e242-4d5d-9878-74296fa721b3

1. ©MIXI 2,000万ユーザーを支える SREチームの6年間のスクラムのカイゼン SRE Kaigi 2025 2025/01/26 15:05〜 ルーム B 5
2. ©MIXI 本間 匡晃(ホンマークハント) (株)MIXI みてねプラットフォーム部 SREグループ マネージャー ・4歳と1歳の娘がいます ・スニーカー収集・筋トレ・キャンプ ・先週だけで2足買ってしまった ・iPadの購入を検討して早2年経過 @HonMarkHunt @honmarkhunt
3. ©MIXI サービス紹介
4. ©MIXI 家族アルバム みてねはスマホで撮った子どもの写真や動画を家族と共有し、 コミュニケーションして楽しむ家族アルバムサービスです。
5. ©MIXI * iOS・Android™ アプリ登録者数、ブラウザ版登録者数の合 計
6. ©MIXI 世界中の家族のこころのインフラをつくる みてね事業のMVV | Mission
7. ©MIXI Agneda ❏ スクラム失敗の歴史 ❏ SRE x スクラム の難しさ ❏ みてねでの対応 ❏ 現在のスクラム ❏ まとめ
8. ©MIXI スクラム失敗の歴史
9. ©MIXI 前提 　 スクラム ❏ みてねSREは6年前のチーム発足時から スクラムを採用 ❏ プロダクトチームで採用されていたの でそのまま流用される形で導入 ❏ 2年ほど前から組織全体でアジャイル/ スクラムの導入促進 ❏ みてねのエンジニアリング組織のこれ までとこれから ❏ 組織のVisionに“Be Agile” 　 組織 ❏ 6人 ❏ Embedded SREではなく 独立チームで支援するSRE ❏ Platform Engineeringも兼ねている SRE A B C プロダクトチーム 支援
10. ©MIXI 　 昔のスクラムの流れ Product Backlog Backlog Refinement Sprint Review Retrospective Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum
11. ©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
12. ©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も未設定
13. ©MIXI 　 昔のスクラムの流れ Product Backlog Backlog Refinemnet Sprint Review Spring Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Sprintは1week ❏ 2wになったりもしたが 今は1wで落ち着いている ❏ 期間中は個人にアサインされて るタスクを各自消化していく ❏ Daily Scrum ❏ やる/やったなどの共有 ❏ 思わず長くなることも Retrospective
14. ©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
15. ©MIXI 　 昔のスクラムの流れ Product Backlog Backlog Refinement Spring Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum ❏ Retro Spective ❏ Sprintの終わりに実施 ❏ KPT ❏ Pivotal Tracker Retrospective
16. ©MIXI SRE x スクラム の難しさ
17. ©MIXI 　 実際にやってみて難しいと感じた点 Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Retrospective
18. ©MIXI 　 差し込みが多い Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Alert対応 問い合わせ対応 他チームとの連携 Sprint開始時に 立てた計画 何も全うできない Retrospective
19. ©MIXI 　 Backlogがわんぱくになる Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum アラートや 問い合わせも管理 課題とタスクが両立 SREのタスク ユーザーストーリー にしにくい！ Retrospective
20. ©MIXI 　 補足: わんぱくBacklogによる属人化 8P 1P 13P 1P 1P Product Backlog 1. せっかくなのでやるべきことは全部Backlogにまとめる 2. 元々持っていた大きな課題を追加する 3. アラートの恒久対応やポストモーテム後の対応なども追加する 4. 結果Backlogに細かいタスクと大きな課題が共存する
21. ©MIXI 　 補足: わんぱくBacklogによる属人化 8P 1P 13P 1P 1P Product Backlog 5. Backlogの上から順に着手していく 6. 細かい課題は即消化されていくので最終的にみんなでかいタスクを 　 取ったところで止まる
22. ©MIXI 　 補足: わんぱくBacklogによる属人化 7. でかいタスクを個人で消化していくので 8. 続けていくと「なんとなくこの辺はxxさん」のような暗黙のアサイン = 属人化 9. 問い合わせなどもなんとくなく属人的になる 1P 1P 13P 8P 13P Product Backlog
23. ©MIXI 　 中長期目標が描きづらい Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum 気づいたら アップデート ばっかりしてた 中長期的に 物事を成し遂げるのが 難しい Retrospective
24. ©MIXI 　 細かいこと言うともっとあるが.... Product Backlog Backlog Refinement Sprint Review Sprint Planning Sprint : 1week 1day SRE Team Daily Scrum Sprint Goalって なんだっけ！ SREの ステークホルダー is 誰？ Retrospective
25. ©MIXI みてねSREでの対応
26. ©MIXI みてねSREでの対応 それぞれ深掘りして考えてみてねSREで行った対策を紹介していきます ❏ 差し込みが多い ❏ Backlogがわんぱくになる ❏ 中長期目標が描きづらい
27. ©MIXI 差し込みが多い
28. ©MIXI 差し込みが多い 差し込み(計画外)は全ての職種で発生している ❏ デザイン「POに見せたら毎回想定と違う手直しが...」 ❏ フロントエンド 「デザインやバックエンドの変更に左右される...」 ❏ バックエンド 「ユーザー問い合わせの調査が...」 一般論だとSprint期間中に発生した計画外の出来事は減らす or コントロールする。 SREの「差し込み」はPlatformerとしてのホスピタリティ担保のため減らすのが 難しかったり、アラートなど外部起因でコントロールが難しいものが多いのでSREには 一般論が当てはまらない難しさがある。
29. ©MIXI 差し込みが多い SREはアラート対応、Platformerとしてのサポートなど計画外で優先度の高い対応が多い 改めて、差し込みが多いと何が問題なのか？ ❏ Sprintの最初に立てたPlanningの通りにならない ❏ Velocityが安定しない ❏ Sprint Goalが達成できない 実は価値提供に直結する問題はない？
30. ©MIXI ❏ 差し込み業務はあるものと割り切る ❏ サポートや相談を減らそうとすることで聞きづらい雰囲気になるならいっそ割り切る ❏ toilの文脈とは別 ❏ Velocityを計測しない ❏ 他職種に比べマーケットプレッシャーが少ない ❏ Sprint Goalを設定しない ❏ とはいえ目標は必要なので月単位で目標を設定し、Sprint単位で達成率の確認 差し込みが多い 対策
31. ©MIXI Backlogがわんぱくになる
32. ©MIXI Backlogがわんぱくになる なぜわんぱくBacklogが生まれるのか？ ❏ PO/PdMの不在 ❏ SREチームには本来Backlogを見てくれるはずのPO/PdMがいないケースが多いため自ら管理する必要が有る ❏ チームが成熟してBacklogを委譲されるのではなく、最初から自分たちだと難しい ❏ アップデート系のタスクなど定常業務がユーザーストーリーベースのBacklogアイテムと相性が悪い ❏ Backlogを整理しようとしてユーザーストーリーベースの書き方をしようとしても アップグレードやEOL対応などの取り扱いが難しい ❏ 課題ベースでBacklogアイテムを作りたいが「xx.xへアップグレード」以外書く事がない
33. ©MIXI Backlogがわんぱくになる 対策 ❏ Backlogで管理するものとその他を切り分ける ❏ 「Backlogが複数できる問題」はあるが、所謂差し込みはTODOとしてBacklogとは別で管理 ❏ 一番恐ろしいのは「属人化」 ❏ 数週間以上かかる/属人性の高くなる恐れのあるタスクのみBacklogで管理する ❏ Backlogに追加するかどうかはRefinement以外でも常に会話 ❏ ベースの会話の回数を増やすことも重要
34. ©MIXI 中長期の目標が描きづらい
35. ©MIXI 中長期の目標が描きづらい なぜ中長期のヴィジョンを描きづらいのか？ ❏ そもそもスクラムが中長期のフレームワークを提供していない ❏ SREはEOLの対応など目先の優先度の高い業務が多く、 短期的には意味のあることを続けているはずが 中長期ではあまり積み重ねできていないパターンになる事が多い
36. ©MIXI 中長期の目標が描きづらい 対策 ❏ Sprintからの積み上げを常に意識する ❏ Mission/Vision ❏ 中期目標 ❏ Backlog ❏ 1ヶ月目標 ❏ Sprint
37. ©MIXI 現在のスクラム
38. ©MIXI 　 現在のスクラム Product Backlog Backlog Refinement Sprint Review 月目標 設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum Retrospective
39. ©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
40. ©MIXI 　 現在のスクラム Product Backlog Backlog Refinement Spring Review Retro Spective 月目標 設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏
41. ©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 名を交換
42. ©MIXI 　 現在のスクラム Product Backlog Backlog Refinement Sprint Review 月目標 設定 Sprint : 1week 1day SRE Team1 SRE Team2 Daily Scrum ❏ Sprint Review ❏ 達成した価値のみを共有 ❏ Velocityの計測はやめたので共有も廃止 ❏ チーム内のReview ❏ 2チーム制にしたため細かいコードの 共有は廃止 ❏ 同じチームのメンバーは細かいこ とまで理解できているので属人化 を回避できるようになった ❏ 価値とは別で共有したいことは 別のタイムボックスを用意して共有 Retrospective
43. ©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
44. ©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
45. ©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
46. ©MIXI まとめ
47. ©MIXI まとめ ❏ 「差し込み」は意外と怖くないかもしれない ❏ 価値に繋がらずコントロールが難しい要素は勇気を持って捨てるか受け入れる ❏ ベースの会話の回数は大事 ❏ Refinement以外でもSlackや他のスクラムイベント中にもBacklogについて触れたりなど ❏ 「スクラム最高！SREも絶対スクラム！」とは言わないが 「SREだからスクラムは無理」と諦めるのは勿体無いかも