スプリントの期間はどう決める？　イレギュラーへの対応法は？ ─ ”とはいえ”シリーズ #5「スプリント編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第5回のテーマは「スプリント」です。前編では、スプリントについての基本的な考え方や、期間を決める基準、割り込みなどイレギュラーへの対応法についてお話します。

スプリントで行うことと、基本となる考え方

中村：
今回のスプリント編をもって、「スクラムイベント」に関するお話は終わりです。今回も楽しんでいただければと思います。
早速、スクラムガイドの「スプリント」の項目を読んでみると、まず最初の１行目から気になりますね（笑）

”スプリントはスクラムにおける心臓の鼓動であり、スプリントにおいてアイデアが価値に変わる。”
ここだけエモくなるのはなんでだろう（笑）。興味深いです。

新井：
たしかに、なんというか…エモい表現ですよね（笑）。

中村：
”プロダクトゴールを達成するために必要なすべての作業は、スプリント内で行われる”というところでは、スプリントの始まりから終わりまでの間から、はみ出る作業はないということをあらためて言っています。

新井：
スプリントの一番最後のイベントが「スプリントレトロスペクティブ」ですが、その後まで作業を続けているケースが時々あります。
それをOKにしてしまうと、さまざまなシグナルをキャッチする機会を失いかねません。もっと重要な問題が潜んでいるのを覆い隠してしまうことがあるので、やめた方がいいですね。

中村：
「あとちょっとで終わるから…」と、やってしまいがちかもしれませんね。気をつけたいところです。

もう少し読み進むと、スプリント内で行うこととして”プロダクトバックログを必要に応じてリファインメントする”とあります。
スプリントバックログに取り組みつつ、未来のスプリントに対してプロダクトバックログをリファインメントするという、二つの活動が併行して走るイメージです。

これがなかなか難しいというのは、よく耳にします。リファインメントに時間を多く割いてしまうと、スプリントバックログが終わらなくなってしまう、と。

新井：
直近と未来とで目線を行ったり来たりさせなくてはいけませんから、実践するとなると難しさがあるでしょうね。コツが必要かもしれません。

後半部分では、スプリントの期間について”スプリントの期間を短くすれば、より多くの学習サイクルを生み出し、コストや労力のリスクを短い時間枠に収めることができる”とあります。この部分を読むと思い浮かぶことがあって…。

『エクストリームプログラミング』だったかな。本の中に、「とにかくアクセルを踏みまくれ。そうするといろんなボロが、部品が落ちてくる」というくだりがあるんですよね。
例えば、車で大陸を横断しようとするとき、砂漠の真ん中で故障が起きたら致命的ですから、まだ修理が可能な市街地にいるうちにアクセルを思い切り踏み込んでおこう、ということだと解釈しているんですけど。

スプリントでも、サイクルが短ければ短いほどいろんなものが発見しやすくなりますし、フィードバックを得られることがすごくプラスであるということだと思います。これは、日々感じていることでもありますね。

中村：
私が後半部分でいいなと思うのは、”スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも１か月ごとに確実になり、予測可能性が高まる”というところ。目の前のスプリントの先にある「プロダクトゴール」についてもちゃんと見ると書いてあります。

どこに向かっているのかよく分からないままスプリントだけ回している、という状況に陥ることってあると思うのですが、そんなときに効く言葉ではないでしょうか。

それと、”プラクティスの有用性は証明されているが、経験主義の重要性を置き換えるものではない”というところ。”複雑な環境下では何が起きるかわからない。すでに発生したことだけが、将来を見据えた意思決定に使用できる”とありますよね。ここもすごく好きです。

予測は予測でしかなくて、実際に起こったこと、起こることではないんですよね。

新井：
何が起きるか分からないという経験は、みんなしています。
予定通りにはいかないことだらけなので、それを前提として向き合っていけるといいですね。