nishida スプリントの期間を決める基準は？
新井：
一週間にするか、二週間にするか、迷うところかもしれませんね。
実際のところはどうでしょうか？
中村：
私が関わったチームでは、ここ数年は「一週間スプリント」がほとんどですね。
「二週間スプリント」を実験的に取り入れるチームもまれにありますが、一週間に戻していることがほとんどです。
先程新井さんからもありましたけど、フィードバックループをいかに早く回すかを考えれば、自ずとそうなるのではないでしょうか。
それに、次の二週間分を予測・想定して計画を立てなくてはならない「二週間スプリント」は、ちょっと大きな「賭け」になります。
「一週間スプリント」なら半分のベットで済みますから、より気楽に臨めると思います。
新井：
サイクルが短いと実験的な取り組みもしやすくなりますよね。
中村：
二週間や一ヶ月先のことまで想定するあまり、なかなか実験的な取り組みができないという現場や組織もあると思います。
一週間や一日というもっと短いスパンで考えられるといいですね。
新井：
スプリントでは気づいたことや起こった出来事を仲間に発信することが大事ですが、謙虚さを美徳とするような文化が根強いと、自分から発信する機会が持てないまま時間が過ぎてしまうこともあると思います。
短いスパンでなら、発信することに対してより適応しやすいのではないでしょうか。
毎日の「プチふりかえり」や「5分間感想戦」なども気楽にできていいと思います。
あとは、ビジネス的な観点で、リリースを見越して区切っていくこともあると思います。
まとまった大きなリリースがあるようなとき、プロダクトゴールやマイルストーンを達成するために何度くらいフィードバックをもらいたいのか、という基準で決めていったりしますね。
中村：
方向転換のチェックポイントがどれくらい必要か、という考え方ですね。
Message from coaches
- おすすめは「一週間スプリント」。短いサイクルでフィードバックを得られるため、いろんなことが発見しやすくなる。
- 「一週間スプリント」なら予測が立てやすく実験的な取り組みも始めやすい。
- 毎日の「プチふりかえり」や「5分間感想戦」など、より短いスパンで仲間同士が発信し合える機会を持つと◎。
スプリントの期間は変えないのが基本。とはいえ、長期休暇の谷間などはどうすればいい？
新井：
連休で稼働できる日が少ないような場合は、「イレギュラースプリント」を作ることが多いかな。
休みの前後をくっつけちゃうこともありますし、浮いた一日をみんなでモブワークをする「スペシャルスプリント」にしちゃうこともあります。
中村：
谷間の一日、二日を「ボーナスステージ」として活用するわけですね。
自分たちがやりたかったことをやってみるとか、リフレッシュするのに使ってもいいですよね。
参加者コメント：
・1週間スプリントでやってます
・作業量を変えるだけでやってますね
・長期休暇等の場合はその期間を含めて2週間スプリントにしたりしてますね…。
新井：
コメントありがとうございます。基本的には、チームの判断になりますよね。
中村：
そうですね。あるチームで二日間くらいの谷間ができたことがあったんですけど、開発者から「ちょっとしたお役立ちツールやスクリプトを作ろう」という声があがって、取り入れたことがありました。
私としては、そういうのもバックログに入れてやればいいんじゃないかなと思いましたけど、「ちゃちゃっとやっちゃいたい」と。
新井：
「カイゼンスプリント」は、エンジニアにとってはやりたいことがやれるのでモチベーションが上がりますよね。
楽しい「スペシャルスプリント」になると思います。
Message from coaches
- 基本的にはチームの判断でOK。休みの前後をくっつけるもよし、浮いた日を利用して自分たちがやりたいことやリフレッシュをする「ボーナスステージ」にするもよし。
- エンジニアのモチベーションを高める「カイゼンスプリント」もおすすめ。
割り込みが多く、プランニングで見立てたスプリントバックログをこなす時間や、チーム活動する時間が確保しづらい。
新井：
これは、実際に発生している現場は多いんじゃないでしょうか。どうしたらいいでしょう？
中村：
スプリントでチームがどんな活動をしているか、データを取っておくといいですね。
数スプリントでも割り込みに全体の何パーセントを使っているか計測すれば傾向が見えてきます。
新井：
なるほど。ファクトをベースに考えていけると理想的ですね。
中村：
例えば、複数の部署やチームからの割り込みが多いのか、大体同じところからきているのか、分かってくると対策も取りやすくなります。
参加者コメント：
・調査依頼とかが多いですね
・プロダクトにもよりますが、データ修正とか調査依頼とか多いですね
・気になる割り込みが多いってことは、兼務の作業が多いってことですよねぇ。計画時にわかるとは思うけど、人員分の作業はできないですよね。
中村：
コメントありがとうございます。兼務だったり、調査依頼だったり…なるほどです。
サービス開発しながら運用もしているチームだったりすると、問い合わせ対応やデータ修正なんかも入るかもしれませんね。
新井：
そういうのも、スプリントを通して見ればある程度は傾向がつかめると思います。
中村：
予想外の出来事やタスクが発生したときは、「どうすればなくせただろうか？」という観点で考えれば、プロダクトのカイゼンアイデアが生まれるきっかけになります。
新井：
スプリントレトロスペクティブの場で話題にあげるといいですね。
言語化、活字化して意識にインプットしておくと、後々ふとした瞬間に対策を思いつくことがあると思います。
Message from coaches
- スプリントの中でチームがどんな活動をしているか、データを取っておこう。割り込みの内訳をファクトで把握すれば、ある程度の対策は立てられる。
- 予想外の出来事や発生したタスクは、スプリントレトロスペクティブで原因や対策を話し合っておこう。言語化・意識化することで今後のカイゼンアイデアに繋げよう。
redjourney.jp