team-ccでスプリントの期間を1日にした話
この記事は matsuri technologies 株式会社 Advent Calendar 2023 の 4 日目の記事です。
今回は toC 向けチームで行われたスペース X の 2 日スプリントよりも短い狂気の 1 日スプリントについて話します。
# スクラムやってますか
私たちのチームではスクラムを外部の協力ももらいながらガッツリ行なっています。スクラムが開始されたのが 5 月 31 日からなので、かれこれ半年ほどスクラムを行なっています。スクラムはいいところも悪いところもあるように感じますが、フレームワークなので適宜適した形でチームに適用していくことが大事だと最近は考えるようになりました。 この記事では toC 向けチームで導入された 1 日スプリントについて、導入された経緯と所感などをざつに書いていきたいと思います。
# スプリントについて
スプリントとは、スクラムにおける開発の 1 サイクルのことを指します。 スクラムは、スプリントゴールを設定し、開発を行い、それをステークホルダーにレビューしてもらうことを 1 サイクルとしています。 このスプリントの期間というものは一般的に 1 週間から 1 月で設定れることが多く、短くすればするほどサイクルの中でスクラムイベントの占める比重が増えていき、チーム全体の作業時間を奪っていきます。
# スペース X は 2 日スプリント！？
世界を見渡して開発サイクルが短い会社を探してみると、スペース X がおそらくヒットすることでしょう。スペース X は開発サイクルに 2 日を採用しており、製造業とは思えないほどの早さで開発が行われています。 この 2 日の開発サイクルが実現されるためにあらゆる効率化が行われています。極力会議を減らすことや、パーツの接続部分の規格を統一する等の…。2 日の開発サイクルは恐ろしい効率化の上になりったているわけです。 1 日スプリントともなるとより多大な労力が必要になるわけですが、なぜそれが導入されるに至ったかを見ていきましょう。
# なぜ 1 日スプリントが導入されたのか
1 日スプリントが導入された経緯ですが、1 週間スプリントのスプリントゴールの達成に連続して失敗してたことから始まります。 スクラムにおいてスプリントゴールが失敗することは基本的に起こり得ないことなのですが、それが連続で起こってしまい、チーム内に「なんだかやばいな・・・」という意識が蔓延していたと思います。チームのふりかえりを通して以下のような課題があがりました。
- 正しく見積もりができていない
- ゴールの達成に関係ないタスクを行っている
- Test に関する意識が共通化されていなかった
# 正しく見積もりができていない・見積もり時に想定したタスクを越えた作業をしている
チーム内で完成の定義も定めていなかったため人によっては想定しているタスクが大きく違う問題がありました。想定しているタスクが大きく違えば A さんが考えた Task を B さんが取り掛かるときに見積もりがずれてしまうわけです。
# ゴールの達成に関係ないタスクを行っている
1 日スプリントを導入したのは 9 月 5 日からでしたが、それまでの間はスプリントの作業中により良い実装が思いついた場合は見積もりを越えて実装のコストが増える場合でも、そちらを優先していました。また、スプリントに関係ないタスクを優先することがありました。
# Test に関する意識が共通化されていなかった
1 つのタスクをどのぐらいで終えるかの共通化がされていませんでした。Test を行うにしてもどの程度をカバーするのか、既存の部分への影響はどうするのかの意識が共通化されていませんでした。
他にも細かい課題は山積されており、これらを解決するいい手段が思いつきませんでした。
# 1 日スプリントがチームの問題を解決する可能性がある
ゴールが大きくなればなるほど見積もりのズレが大きくなる可能性は高く、ゴールが小さければ見積もりの誤差は小さくなるだろうと考え、1 日スプリントにすることで強制的に小さいゴールを設定して見積もりを小さくしようという魂胆です。 スプリントゴールが達成されない場合に達成確率を上げることを考えてしまうと、スプリントに入れるタスクを小さくしたり、スプリントの期間自体を長くしようとしてしまいそうですが、時には逆を行ってみたり、極端にやってみることも問題の解決の糸口になるとこともあります。
# 1 日スプリントをやってみて
1 日スプリントは結果として、見積もりのサイズを小さく正確にし、ゴールの達成に関係ない作業に取り組むことをなくし、テストの粒度を揃えることにつながりました。 スプリントゴールの達成率は向上し、1 日から 2 日、そして 1 週間にスプリントの期間を徐々に伸ばすことで、ゴールの達成率を維持したまま現在では 1 週間のスプリントに戻っています。 1 日スプリントはゴールの達成率とベロシティの改善を同時に実現しました。
# 最後に
いいことばかりに聞こえる 1 日スプリントですが、大変なところあります。
- スクラムイベントに忙殺される
- スケジュール調整が難しい
- 長期的なタスクが難しくなる
当然ですが、スクラムイベントに割かれる時間は莫大なものとなり開発する時間を奪います。チームは殺気立ち忙しくなり、それこそラグビーのスクラムのような状態となります。 また、1 日の中でスクラムイベントを行うことになるので、ステークホルダーにスプリントレビューに参加してもらうのも一苦労です。 これは、チーム全体の懸念点で長期的なことやタスクが考えられなくなる傾向がありました。
私たちのチームではやってみて良かったと言えますが、みなさんのチームでは状況を見て導入することをお勧めします。