はじめに
STORES でECサービスのSREエンジニアをしている角田と申します。 SREチームではチームのタスク管理のためにスクラムを利用しています。 スクラムを導入してから今までの半年と少しの間に感じたことをまとめてみました。
元々のSREチームの働き方と抱えていた問題
元々のSREチームは人数がかなり少なかったこともあり、個人に対して大きなタスクをアサインしていました。
ここでいう 大きなタスク とは、例えば、 パフォーマンス改善 や 監視改善 、 インフラのコード化 といったスクラムで言うプロダクトバックログアイテムのようなサイズです。
メリット
このスタイルのメリットは、
- 個人で決められる事なら意思決定が早い
- 仕事のスピードが出る(場合がある)
- 他チームからの質問を受ける担当が明確
などです。
デメリット
一方でデメリットは、
- 他のタスクとの優先度の関係でペンドや遅延することがある
- 差し込み対応の受け止め方が難しい
- 明確な答えが出しづらいことの意思決定が難しい
- 属人化する
- そのタスクが初めてだと仕事のスピードが出ない
などが挙げられます。
問題
実際私たちのチームでは、
- アサインされたタスクが進捗していない
- 差し込み
- 意思決定のための情報収集やMTG
- 他の人が主に担当しているタスクはよく分からないので引き継げない
- 進捗の遅れや差し込みにより長期間同じタスクが終わらない
といった問題が発生していました。
仕事のスピードを出すため個人の裁量を大きくし、ある程度大きな単位でタスクをアサインしていたのですが、こうした問題によってスピードが出し切れていないのではないか？と考え、社内でもいくつかのチームが採用しているスクラムを導入してみる事にしました。
SREチームのスクラム
私たちのチームにはスクラムの識者が居ませんでした。 そこで、先ずは教科書通りに進めてみる事にしました。
スクラムチーム
開始時点でチームは4名、現在は5名です。
開発者
プロダクトオーナー以外の4名です。 SREでは週替わりで運用担当を設定しています。 運用担当者は1週間、差し込みタスクやお問い合わせ対応を受け持ちます。 なので、実際にスプリントを進めるのは3名になります。
プロダクトオーナー
チームのマネージャーが担当しています。 開発チーム全体の週次ミーティングなどにも出席していて、SREチームの想定顧客の1つである、他の開発者の声を最も集めやすいので適任でした。
スクラムマスター
前述の通り週替わりで運用担当があるので、運用担当者がスクラムマスターを兼任する事にしています。 チームのスクラム習熟度が高くないので、スクラムマスターが何をするのか？という観点も身につける意味でローテーションするのが良さそうだという判断です。
この点を除けば概ね一般的なスクラムチームの構成でしょう。
スクラムイベント
私たちのスクラムでは1スプリントは1週間です。
週次で実施しているイベントは以下になります。
- デイリースクラム (30分)
- スプリントプランニング (60分)
- レトロスペクティブ (30分)
また、スクラムイベントではありませんが、これ以外に相談事や運用の引き続きなどで週次のミーティングを実施しています。
加えて四半期毎に、チーム目標を考える関係で、プロダクトバックログのリファインメントも実施しています。
デイリースクラム
デイリーでは次の事を話し、共有します。
- 昨日やった事
- 今日やる事
- スプリントゴールに対してどうなのか？(進捗や困っている事の有無など)
- 時間を取って相談したい事が無いか？
時間を取って相談したい事があればデイリーの後に時間を取って話し合います。
スプリントプランニング
プランニングでは次の事を話します。
- スプリントゴールに対して出来た、出来なかった事の確認
- 差し込みタスクの振り分け、見積もり
- 運用で対応？スプリントで対応？保留？
- 次スプリントタスクのアサイン
- 見積もられているタスクが少なくなった場合は、見積もり
以前はスプリントで消化したポイントを元に、アサインして良いポイント数の調整をしていましたが、安定してきたためやらなくなりました。
スプリントレトロスペクティブ
レトロスペクティブでは各々が考えた、良かった事や良くなかった事、感謝したい事、改善していきたい事など、自由に話します。 その中から3つ、改善点や継続したい事を選びます。 スプリントの最終日にやるのですが、思い出せず、話す事が出ないということも有ったため、今は毎日Slack通知をして記入を促すようにしています。
スクラムを導入して良かった事
スクラムを導入して良かった事は、仕事が進めやすくなったという一言で表現できます。 ここでいう仕事の進めやすさは、
- 計画が立てやすい
- やるべきタスクをスムーズに進められる
- やるべきタスクを終わらせる(Issueを閉じる)事が出来る
といった事です。 改善した理由を考えてみました。
タスクの属人化が減った
以前はプロダクトバックログアイテム(PBI)単位で個人にアサインしていたため、他の人がやっているPBIはよく分からないという事がありました。 しかし、スクラムでPBIを分割して全員で取り組むようになったため、全員がPBIの事を理解するようになりました。 また、タスクを引き継ぐ事もあるためドキュメントやIssueのコメントをしっかりと残し、経緯や終わっている事、残タスク、次やる事などがしっかりと情報共有されるようになりました。
また、全員でポイントを見積もるようになった事で、個々人のスキルや経験差による見積もりの属人性も下がりました。 そのタスクはこれもやらないといけないよね？といった、担当者以外の視点が見積もり時点で入るため、見積もりの正確さにも繋がっています。
コミュニケーションがスムーズになった
デイリーやその後の相談の時間ができた事で、細かく素早く進め方や難しい点を話し合うようになりました。 結果、全員がPBIやそのタスクについて考えられるようになり、理解が進むようになりました。 もちろん、ここまでのスプリントの中では、こうしたコミュニケーションが上手くいかなかった回もあり、そういったスプリントではほぼ必ず達成されないゴールが発生しました。 ですが、その度に 早く細かく話して決めよう！ という意思統一ができていたため、最近はコミュニケーション起因のゴール未達成はほぼ無くなりました。
また、属人化が減った事と相まって、PBIに対する責任感が全員に芽生えていて、相談に対する心理的ハードルを下げられたという側面もありそうです。
- 意味のあるコミュニケーションの増加
- 心理的ハードルの低減
- 業務知識の並列化
といった事によって、意思決定が早くなったり、メンバー同士のサポートがスムーズに行えるようになる事がスクラムの肝なのかもしれないなと感じています。
差し込み対応が改善した
以前は大きめの(1日では終わらなそうな)差し込みがあった時点で、余力のある人、ないしは、経験済みの人や得意な人が引き取るという対応をしていました。 そのため差し込み対応でその週の予定は何も終わらないという事があり得ました。 しかし今は、差し込みがあった時点で、緊急度に応じて即対応するか？スプリントに入れて対応するか？といった判断が入るようになったため、以前よりも本来のタスクの手を止める事が減りました。
また、こちらも属人化が減った事と相まって、開発者の経験差が減った事により、差し込み対応ができるメンバーが増えたという側面もあります。 結果として運用担当者が捌ききれる範囲が増えたり、経験の有無によらず本当に余力のある人が引き受ける事ができるようになってきています。
以上の様な改善によって、
- 十分に妥当な計画が立てられ
- 差し込みがあっても大きく計画に影響を出さず
- やるべきタスクを終わらせていく
という事が実践できるようになりました。
このように、タスクをこなしていく上での手戻りや見積もりのズレ、差し込みによる遅延などが減った事で、導入の大きな目的だった開発スピードは確実に改善しています。
スクラムを導入していまいちだった事
正直なところ大きなデメリットは無いと考えています。 強いて挙げるなら2点。
スクラムイベントの時間がかかる
始めこそスクラムの各イベントに時間がかかっていましたが、各イベントでやる事に対する慣れと、なによりスプリントや四半期毎にチームで達成すべき事の共通認識ができていく事で高速化してきました。 のでスクラムを導入するデメリットは特に無いと言って良いのではないでしょうか？
個人の目標を考えるのが難しい
以前はPBIが個人にアサインされていたため、遂行する上で必要な調査や他チームとの調整、もちろん実装まで含め、目標として設定、計測がしやすいという側面がありました。 ですが、現在は開発者で分担しているため、自分の目標にPBIの様な分かりやすい要素が設定されません。 スプリントと目標設定の整合性を取るという事が今後の課題の1つだと考えています。
まとめ
以上の様に、スクラムを導入した事で私たちのチームは開発スピードを改善する事に成功しました！
SREのタスクは多岐に渡るうえ、優先度が付けづらく、差し込みタスクも多いです。 私たちはスクラムによって、かなり仕事がしやすくなったと実感しています。 皆さんも是非導入を検討してみてください！
