はじめに
SREグループでマネージャーをしているyoshiroooです。
私たちSREグループでは、運用の効率化と改善スピードの向上を目指して、スクラムのフレームワークを取り入れた開発・運用サイクルを回しています。
とはいえ、SREは開発チームとは異なり、突発的な障害対応や調査依頼などの「差し込みタスク」が頻繁に発生する職種です。
そのため、教科書通りのスクラムをそのまま導入するのではなく、現場の状況に合わせてアレンジしながら運用しています。
今回は、私たちが実際にどのように運用しているのか、簡単ではありますが、ご紹介します。
スクラム導入の背景
以前からスクラム自体は導入していたものの、運用を続ける中で以下のような課題に直面していました。
- 差し込みタスクの多さ: 障害対応や調査依頼などにより、計画していた改善作業が中断されてしまう。
- 改善タスクの滞留: 「本来やるべき重要な改善」が、緊急度の高い目先の運用タスクに埋もれて進まない。
- チーム状況の不透明化: 誰が今どのくらい負荷を抱えているのか、進捗はどうかが外から見えにくい。
これらの課題を解決し、「運用のリズムを作りながら、着実に改善を進められる状態」を目指しました。
運用の前提
SREの業務特性に合わせ、あえて「型」を崩して運用しています。
- スクラム × カンバンのハイブリッド: 流れの速い運用タスクは「カンバン」で可視化・フロー管理し、中長期のプロジェクトは「スクラム」的な計画性を持って進める形にしています。
- PO/SMを置かない軽量な運用: メンバー全員が技術的なコンテキストを共有しているため、専任のプロダクトオーナー（PO）やスクラムマスター（SM）は置かず、エンジニア同士の合意形成で優先順位を判断しています。
運用の全体サイクル
SRE特有の不確実性に対応するため、「月・週・日」という3つのリズムでサイクルを回しています。
サイクルイメージ
-
月次：バックログリファインメント ＆ 月目標設定
- バックログを最新化し、「この1ヶ月で何を達成するか」の目標を定める。
-
週次：スプリントレビュー
- 1週間の進捗同期と、差し込み状況に応じた計画の微調整。
-
日次：デイリースクラム
- 今日のタスク確認と、突発的な問題への即時対応。
-
隔月：レトロスペクティブ
- 2ヶ月に一度、チームの仕組み自体をアップデート。
各イベントの内容
■ バックログリファインメント ＆ 月目標設定（月1回）
- 1週間単位の忙しさに流されず、中長期的な視点を維持するための場です。
- 単なるタスク整理ではなく、SREロードマップや会社の状況に合わせ、「この1ヶ月でどのタスクを完了させるか」という月間目標を設定します。
- 同時にIssueの優先順位を再精査します。
- 割り込みが増えすぎてキャパシティを超えている場合、あえて既存タスクを「IceBox（保留）」に戻す決断もここで行い、チームの過負荷を防ぎます。
■ デイリースクラム（毎日）
- 現場の微細な変化をキャッチし、チームの詰まりを解消します。
- 差し込みの即時評価: 新規タスクを真っ先に確認し、優先順位をその場で調整します。
- デッドラインの死守: 期限が近いタスクのフォローをチーム全員で行い、サービスや業務への影響が出ないよう調整します。
- 透明性の確保: 相談事はIssueのコメント欄に集約し、情報の非対称性をなくします。
■ スプリントレビュー（毎週）
- カンバンの「流れ」を重視しつつ、週単位で立ち止まってチームの同期を取ります。
- SREの現場は状況が変わりやすく、計画が形骸化しやすいため、短いサイクルで「仕切り直し」をしています。
- WIP（進行中の作業）制限を設けており、仕掛かり中のタスクが上限を超えていないかを確認。もし溢れていれば、その場で作業調整を行います。
■ レトロスペクティブ（2ヶ月1回）
- チームの動きをスムーズにするために、運用ルール自体をアップデートする場です。
- 頻度の理由: 実施が頻繁すぎると改善策の実施が追いつかず、効果測定も難しいため、中長期的な変化を観察できる「2ヶ月」というスパンにしています。
- TryのIssue化: KPTで出た具体的な改善案は必ずIssue化し、次サイクルのタスクとして確実に実行します。
まとめ
この運用を始めたことで、差し込みタスクに振り回されすぎず、**「今月はこれをやり遂げる」**という軸を持って動けるようになりました。
もちろん、これが完成形だとは思っていません。
私たちは2ヶ月に一度のレトロスペクティブを通じて、「今の自分たちにこのルールは合っているか？」を常に問い直しています。
また、日々の業務で出てくる小さな課題や違和感も、デイリースクラムなどでその都度柔軟に見直すようにしています。
大切なのは、特定のフレームワークに自分たちを強引に合わせるのではなく、「自分たちの特性に合わせて、改善し続ける」ことだと考えています。
この記事が、同じように運用と改善のバランスに悩む方々の参考になれば幸いです。