インフラチームでスクラムマスターをやっている小川です。今回はインフラチームのスクラム開発についてご紹介できればと思います。

なぜスクラム開発を導入したのか

オープンワークにおけるインフラチームの業務というと、時期によっては新システムのインフラを構築することはあれど、基本的には既存システムの保守・運用がメインです。また、ひとつひとつの業務の粒度も比較的小さいことが多いです。
このように一般的な開発チームとは特性が一癖も二癖も異なりますが、果たしてインフラチームにスクラム開発は有効なのか、まずはスクラム導入前の課題感について見ていきます。

タスク管理に課題

もともとインフラチームでは、業務をどう進めていくかは各人に大きく委ねられていました。各々の判断でタスクを起票し、進捗させ、報告する、というスタイルだったため、

各メンバーの進捗がわかりにくい
特に経験の浅いメンバーにとって、今すべきではないタスクを進めてしまう
メンバーによっては多方面から依頼をもらうことがあり、業務量に差が生じる
今期やるべき業務ができないまま終わる

といった課題が生じていました。

割り込み業務が多く、目標達成に影響する

インフラというレイヤーの低い領域を扱っている関係上、他のチームから依頼や問い合わせがきます。また、クラウドインフラの障害対応や Action Required な対応も多いです。
これらに迅速に対応するのもインフラチームの大事な業務の一つではありますが、一方で期初に予定していた業務の進捗に影響が出てしまい、計画通りに進まないことが常でした。
正当な理由によってチームの目標達成が不可能であることが判明した場合、期中であっても目標を変更することは可能です。しかし、「何を」「どのくらい」先送りにすればよいのかがわからないという問題が生じます。結局、目標を達成してもしなくてもなんだかモヤモヤするような幕切れが多かったです。

常に忙しい

なかなか進まない進捗によって業務に追われる日々が常態化してしまい、忙しいのが当たり前という感覚をチームメンバー全員が持っていました。結果、不名誉なことにインフラチームは特に残業の多いチームになってしまいました。

チームとしての一体感に欠けている

スクラム以前から朝会を実施してはいましたが、どうしても担当者→上司という方向だけを向いた進捗報告になりがちでした。よって、他のメンバーは業務内容を把握しにくい状況でした。チームに所属してはいるものの、個人で業務を進めているような具合でした。

インフラチームのスクラム開発

前置きが長くなってしまいました。こういった課題を解決するため、2020 年にインフラチームでもスクラムを導入しました。特徴は以下の通りです。

1 週間スプリント

一般的に用いられる 2 週間よりも、より短い 1 週間の方が「割り込みタスクを次のスプリントで対応」しやすいため採用しています。割り込みがあってもスプリントゴールへの影響を最小限におさえることができます。

スプリントの始まりと終わりをそれぞれ水曜日と火曜日に設定しています。月曜始まり・金曜終わりという案もありましたが、週の初めにプランニング・週の終わりにふりかえりをするのはどちらも疲れる、というリアルな理由から週の半ばで区切るようにしました。

実施しているスクラムイベント

以下をスプリントごとに行っています。

スプリントプランニング
デイリースクラム
バックログリファインメント
ふりかえり

現時点でスプリントレビューは行っていません。レビューの代わりとして毎週のチーム定例があって、そこでステークホルダー (CTO) に報告を行っています。とはいえ、「定例」よりも具体的な目的を持つスプリントレビューに替えたらどうか、という意見もあり、検討をしているところです。

GitHub Projects を使った KPT のふりかえり。Keep の掟の威圧感

ファシリテーターはメンバーをローテーション

デイリースクラムをはじめ、各スクラムイベントのファシリテーターは日次でローテーションしています。各スクラムイベントのルールや進め方を詳しくドキュメント化しているので、約半年前に入った新卒のメンバーも今ではしっかりと場を回すことができるようになりました。

スクラムを導入してみて: 冒頭で述べた課題は解消されたか?

タスク管理に課題 → ☀☁ 解消しつつある

やることを網羅的にプロダクトバックログアイテム (PBI) 化し、プロダクトオーナー (チームの Mgr) が PBI を管理するようにしました。管理されたプロダクトバックログにより、優先度の高い問題だけに集中して取り組むことができるようになりました。
また、各スクラムイベントにより以下のようなメリットを得ました。

デイリースクラム: 各メンバーの進捗や問題点がわかりやすくなった
スプリントプランニング: 何をすべきなのかが明快になった

一方、プロダクトバックログの管理にはある程度の工数がかかっている状態であり、作業の自動化などを進めてより効率的にする必要があります。

割り込み業務が多く、目標達成に影響する → ☁ 解消しつつあるが、依然として課題も

割り込み業務についても基本的には PBI として扱い、見積もりを行います。こうすることによって、ある期間における割り込み業務の定量的なストーリーポイントがわかります。期初にチームの目標を計画する際、割り込みの過去実績を考慮することで、より現実的な目標設定ができるようになりました。

これにより、理論的には期末に目標達成できてもよいのですが、結局達成できないことがよくあります。パフォーマンスの問題、見積もり精度の問題など、いくつかの要因が考えられるため、ふりかえりながら改善をすすめています。

常に忙しい → ☀☁ 解消しつつある

スプリントプランニングで設定した PBI をすべて完了させることができれば OK なので、これまでのように「やってもやっても終わらない」問題は生じにくくなりました。ただし、前提としてスプリントプランニングで非現実的な計画をたてないよう、チームで注意しながら進めていく必要があります。
またこれは肌感覚ではありますが、スクラム導入以後で残業時間は減ったように感じています。加えて、チームで残業を減らす取り組みも行っているところです。

チームとしての一体感に欠けている → ☀ 解消

バックログリファインメントにて、チームメンバー全員で PBI のストーリーポイントを見積もることで、自身が担当しないタスクについても内容を理解する機会が生まれました。また、デイリースクラムやふりかえりではメンバーが持つ課題を共有し、チームで解決していく文化が構築されつつあります。以前よりも、チームとしてのまとまりは間違いなく向上したと実感しています。

今後の課題

1 週間スプリントの宿命ではありますが、スクラムイベントが多くなりがちです。毎週のようにスプリントプランニングやふりかえりを行っているので、心理的な「またかー」感を覚えます。とはいえ、イテレーションの期間は 1 週間と短いことから、その分イベントの実施時間も短くできるはずです。負担をできるだけ軽減するべく、メリハリのあるイベント運営が求められます。

また、現時点でインフラチームは少人数なのでなんとかスクラムの形を保てていますが、例えばチームがさらにスケールしたときに果たしていまのスクラムが成り立つのかは未知数です。ですが将来どうなるかを予測するのは難しいので、大事なことは、その時その時で最適な方針へと舵をきれる柔軟性がチームにあることだと感じています。