はじめに
株式会社GENDAでSRE/インフラエンジニアをしている布田です。本記事では、私が所属しているSRE/インフラチームでスクラムを導入した事例について紹介します。
ちなみに、この記事はGENDA Advent Calendar 2025 シリーズ3 Day24 の記事です。他の記事もぜひ読んでください！
SREチームのタスク管理について
私が入社した当初、SREチームとしてやるべきことはわかっているものの、タスクを進める中で「このタスクいつ終わるんだっけ？」「今って何を優先すべきなんだっけ？」というようなことを考える時間があり、改善できないかなぁと思っていました。そこで、まずは課題を整理することから始めました。
課題1：タスクをいつまでに終わらせられるのか把握しづらかった
絶対的な期日がないタスクもあり、いつまでに終わらせるべきなのか分かりづらくなっていたと感じます。そのため、いつまでも終わらずに残っているようなタスクもありしました。
タスクを細かく正しく見積もることができれば、何をしなければいけなくて、どれぐらいかかるのかわかるのでこの課題は解消するはずです。ただ、必要以上に管理コストを上げてストレスを高めるのも良くないと思っているため「適度な管理」と「柔軟性」のバランスをどう取るか考える必要がありました。
課題2：計画性と優先度判断の難しさ
日々の業務の中で「今週何にどれぐらい時間を使っていいのか」「次に何をやればいいのか」を都度判断しなければ行けないことも課題でした。「進んではいるけど、今選んだタスクが正しいのか分からない」「このタスクにどれぐらい時間を使えるのかがわからない」という不安を抱えながら作業を進める時もありました。
これらの課題解決のためのスクラム導入
こうした課題を解決するために、タスク管理の方法を検討しました。
最初はカンバン方式も考えましたが、最も解決したかったのは上記2つの課題に共通する「計画性」でした。カンバンにはタイムボックスの概念がないため、「いつまでに何を終わらせるか」という見通しを立てにくいと判断しました。
一方、スクラムには以下の要素があり、私たちの課題感にフィットすると考えました。
タイムボックスによる計画性
タイムボックスを設けることで、「このスプリントで何を達成するか」が明確になります。期限があることで、タスクの粒度を適切に保つ動機付けにもなりますし、完了したタスクを定期的に振り返る機会も生まれます。タスクを無理に細かく管理しなくてもタイムボックス単位でタスクの予実を管理すれば、チケットがおわらなかったらサポートにはいったり、遅れを確認することができると考えました。
定期的な振り返りによる改善サイクル
タイムボックスごとにやるレトロスペクティブで「予定どおりコミットできたか」「できたなら何がうまくいったか、できなかったなら何がうまくいかなかったか」を共有し、次のスプリントで改善を試せます。チームとしての学びが蓄積されていくのも良い点です。
チームの透明性向上
スプリントプランニングで全員が「誰が何をやるか」を把握できます。進捗が可視化され、困っているメンバーをサポートしやすくなりますし、完了したタスクが明確になることで達成感も得られます。
スクラムの実践内容
ここからは、実際にどのようにスクラムを運用しているかを紹介します。
スプリント設計
期間は2週間
2週間という期間は、以下の理由で選びました。
- 1週間だと計画と振り返りの頻度が高すぎて疲弊しそう
- 3週間以上だと振り返りの頻度が下がり予実の差をフォローできなさそう
- 2週間なら適度な計画性と柔軟性のバランスが取れそう
純粋に「まぁ2週間でやってみよう」という感じで最初は始めました。実際、取り掛かると1週間でおわらなタスクが多く、2週間がちょうどよいと感じました。
ストーリーポイントのキャパシティは7pt上限
ストーリーポイントには良かった点があるのですが、一人あたり最大7ポイントに制限したことです。以下、ざっくりとした内訳です。
想定される時間配分（2週間 = 80時間）:
- 打ち合わせ: 8時間
- 管理・軽作業: 8時間
- その他割り込みなど: 8時間
- 計画タスク: 56時間 → 7ポイント相当
残り3ポイント分は割り込み作業用のバッファとして確保
この設計により、割り込み作業が発生しても計画タスクを完遂できる確率が高まりました。これは、PRレビューなど自身が持つチケット以外についてはどうするという話が合ったときに余裕を持つように設定しました。でも、ついギリギリまでタスクを入れてしまいそうになるのが課題ですね。
スプリントゴールの考え方
私たちのスプリントゴールは、 「プランニングで決めたタスクをやり切る」 ことです。
一般的なスクラムでは、「〇〇機能をリリースする」といった統一されたゴールを設定すると思いますが、私たちのSREチームは複数プロダクトの様々な課題に対応しているため、全員が同じ方向を向いたスプリントゴールを設定するのが難しい状況でした。このアプローチにより、「何をやるか」は人によって異なっても、「決めたことをやり切る」という共通の目標を持つことができました。
そしてそれを積み上げていくことで結果的に大きな成果を出すことができると考えています。
各セレモニーの運用
レトロスペクティブ/スプリントプランニング（2週間に1回、スプリント最終日）
所要時間は1時間で、以下の流れで実施しています。
- レトロスペクティブ（30分）
- タスクの見積もりと優先度付け（30分）
レトロスペクティブ
レトロスペクティブでは、各メンバーが以下を共有します。
- よかった点
- 気づき
- 次やること
重要なのは評価や反省ではなく、「気づきの共有」を目的とすることにしました。KPTのKもPも気づきとして捉えたほうがアクションに繋げやすいと考えたからです。過去に出たアクションは毎回実施できているか確認しています。
一例ですが、レトロスペクティブから生まれた重要な気づきの一つに 「調査と実装を分離する」 というものがあります。見積もりが難しいタスクは、いきなり実装チケットを作らず、まず「調査タスク」を作成するようにしました。
調査フェーズで技術的な実現可能性や工数の目処を立て、その結果をもとに次のチケットを切る流れにすることで、不明瞭なタスクでも着実に進められるようになりました。最初から完璧に見積もろうとするのではなく、「まず調査して見通しを立てる」というステップを挟むことが重要だと学びました。
プランニング
導入時の計画では、バックログの優先順位付けでは「SREチームの目標」に紐づくタスクを優先しつつ、緊急度・影響範囲・工数を考慮しようと考えていました。
ただ、プランニングで目標をベースに議論しなくても優先度が割と明確なタスクが多く、最終的には目標が忘れられてしまったので次回はちゃんとこの目標をベースとした議論を取り入れたいと考えています！それでも、全体として優先すべきテーマ（セキュリティ等）はちゃんと取り込むように事前に軸として整理していました。
デイリースクラム
別のコミュニケーションの場があるので、不要としました。今のところ開始するつもりはありません。
ちょっと余談ですが、コミュニケーションにおいては週3で開いている「雑談会(15分)」というのがあるのですが、コミュニケーションを取るには一番効果的だったと感じています。気軽に相談してタスクを進めることができるようになったり、各メンバーの課題感をしることができるようになりました。
棚卸し会（毎月月末）
全チケットを見直し、不要なものを削除します。プランニングで毎回やると重いため、月次で実施しています。リファインメントみたいな位置づけです。
バックログ管理
カンバン方式でタスクを管理しています。レーン構成は以下の通りです。
- INBOX: アイデアレベル、気になることを自由に追加
- TO DO: 完了条件が明確なもの
- 進行中: 実施中のタスク
- 確認待ち: レビュー・確認依頼中
- 完了: 期待される成果が達成された状態
とにかくInboxに入れて完了条件とかが整理できたらTO DOにするみたいな感じで進めています。
ストーリーポイントの基準
| サイズ | ポイント | 目安 |
|---|---|---|
| S | 1 | サクッといける |
| M | 3 | 1-2日程度 |
| L | 5 | 0.5スプリント（1週間） |
| XL | 10 | 1スプリント（2週間） |
ただ、先程あったようにスプリントでの最大は7としたいので、大きいタスクはできるだけ5とか3で収まるように整理してチケットを切ってもらいます。
導入後の変化
スクラム導入から3ヶ月が経過し、チームに様々な変化が生まれました。大きな効果としては、「今（週）何をすべきか、どれぐらい時間をとるのか」が見えるようになったことです。導入前は「このタスク、いつ終わるんだっけ？」という状態でしたが、スプリント単位でタスクを管理することで、「今週は何に取り組んでいるのか」「あとどれくらいで完了しそうか」「遅れているタスクはあるか」といった現在地が明確になりました。
これから導入する人へのアドバイス
小さく始める
いきなり完璧なスクラムを目指す必要はないなと思いました。私としては、以下を意識すると良いかなと思います。
- まず2週間のタイムボックスを設定
- チケットの粒度は最大で2週間で終わる粒度。ただ、管理のしやすさとしてストーリーポイントに合わせて１・３・５ぐらいの大きさで作成
- デイリースタンドアップやスプリントレビューは、チームの状況に応じて判断
割り込み作業を前提とした設計
SREチームは割り込み作業が避けられません。それを前提とした設計が重要です。
- キャパシティにバッファを持たせる（7pt + 3pt）
まとめ
最初はうまくまわせるか不安でしたが、完璧を目指すよりまず始めてみることが重要だったなと思います。運用しながら改善していくスタンスで、チームにフィットさせていくことが良いのではないでしょうか。まだまだ改善の余地はありますが、定期的な振り返りを通じて、少しずつ改善していけると感じています！
Discussion