アジャイルコーチはなぜ1週間スプリントを勧めるのか

みなさんこんにちは。@ryuzeeです。

職業柄スクラムを始めたばかりのチームを支援することがよくあります。 そのような状況で、ロールの明確化や初期のプロダクトバックログの準備とあわせて話題にのぼることが多いのが、スプリントの期間をどうするかです。 そして、多くの場合、1週間スプリントを提案しています。 今回はなぜ1週間スプリントが良いのか見ていきましょう。

1週間スプリントがよい理由

1週間スプリントがよい理由を列挙すると以下のようなものがあります。

1. レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む
2. 計画の精度が高くなる
3. 例え失敗しても一週間で済むので実験しやすい
4. ベロシティの数字がすぐ出るのでやる気になる
5. 中だるみする余裕がない・リズムがよい
6. 一週間で収まるサイズのプロダクトバックログ項目にするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい
7. スパイクが必要なプロダクトバックログ項目が明確になる
8. プロダクトオーナーが変更を我慢しやすい
9. ごまかしが効かない

順番に見ていきましょう。

レトロスペクティブ（ふりかえり）が頻繁にあるので改善が進む

大きな理由の1つがレトロスペクティブの回数です。 たとえば、スプリントに使える期間が3か月だとすると、4週間スプリントはスプリントが3回、2週間スプリントで6回、1週間スプリントで12回となります （1日スプリントでやっているチームも知っていますが、スクラムのルール外なので今回は除外します）。 改善の基本的な考えとして、うまくいったかどうかを判断しうまくいかない場合は元に戻す、一度にたくさんのことを変えないという点が挙げられます。 つまり毎回劇的な変化を加えるのではなく緩やかに変化していくことになります。 このとき改善の機会が少なければ少ないほど、試行錯誤して改善する機会が減ってしまい、最初と最後での変化は少なくなってしまいます （言い換えると上手くなる前に期限が来てしまいます）。 したがって、慣れていないうちほど、改善の機会をたくさん用意した方がよく、短いスプリントの方がその機会は多くなります。

計画の精度が高くなる

計画づくりは難しいです。もちろん見積りも難しいです。 そしてこれらは規模が大きければ大きいほど難易度が上がります。 また、始めたばかりの段階だと、スクラムチーム全体がやり方に慣れていない、過去にどれくらいの速度で開発できていたのかというデータがないといった要因も、影響を与えます。 したがって、特に慣れるまでは、なるべく小さい単位で計画をたてて、計画と実際の差がどのくらいなのかを見ながら微調整していくことが重要になります。 1週間の計画を立てられないのに4週間の計画を立てられるということはないので、まずは短い範囲でいいので確度の高い計画を立てられるようにしてください。 そうすることで、プロダクトオーナーはプロダクトの今後の見込みや予測をしやすくなります。 予測がしやすければしやすいほど、ビジネス面での計画も立てやすくなります。

例え失敗しても一週間で済むので実験しやすい

計画の精度が高くなる、というのと多少相反しますが、万が一そのスプリントが何らかの理由でうまくいかなかったり、成果が少なかった場合でも、スプリントの期間が短ければ短いほど影響は少なくなります。 あるプロダクトバックログ項目でいろいろハマってしまい、想定の時間以上をかけても完成しなかった場合のことを考えてみましょう。 この場合、スプリント期間が長いと延々とハマってしまい、長いタイムボックスを使いきってしまうリスクもあります。 一方で、1週間スプリントの場合は、すぐにスプリントが終了します。 そして着手中だろうがあとすこしで終わりそうだろうが強制的に当該プロダクトバックログの作業は停止されます。 仕掛中のプロダクトバックログ項目については、次のスプリントで継続して取り組むのか、それとも先送りにするのか、もうやめるのかを判断する機会もあります。 そう考えると短いスプリントの方がリスクが少ないことが分かります。

また、同様の理由で、プロダクトオーナー側の観点としても、挑戦的なプロダクトバックログ項目をスプリントに投入しやすくなります。

ベロシティの数字がすぐ出るのでやる気になる

これは大した理由ではないのですが、スプリントが短いとベロシティの数値がすぐに見える化されます。 過去のベロシティとすぐに比較できるので、成長を実感したり停滞に気づいたりするのが簡単になります。

中だるみする余裕がない・リズムがよい

1週間スプリントでは、例えば以下のような週間スケジュールになります。

• 水曜日午後にスプリントプランニングを2時間のタイムボックスで実施し、完了後に夕方からスプリント開始
• 金曜日か月曜日くらいにプロダクトバックログリファインメントを実施して次のスプリントを準備
• 火曜日の夕方に翌日の準備をして、水曜日の午前中にスプリントレビューを1時間、スプリントレトロスペクティブを1〜2時間実施

毎週同じ曜日の同じ時間にイベントが行われることになるので、スケジュールを考えたり調整したりする必要がなく、リズムが出やすくなります。 イベントをオープンスペースでできないような場合でも、単純に毎週繰り返しで会議室予約をしておけばよいだけです。 何曜日の何時くらいにどういう状態だったら、マズイとか大丈夫そうだ、というのも分かりやすくなります。 スプリント期間が長くなると、スプリントプランニングのあとや翌日などはペースダウンしがちです。 またスプリントの後半に向けて追い上げ型にもなりがちです。 ところが、1週間の場合は後半も何も、そもそも時間が短いので追い上げが効かず、いつも同じペースで着実にこなしていくことになります。

一週間で収まるサイズのプロダクトバックログ項目にするので明確な完成を定義しやすい。従ってプロダクトオーナーの受け入れを取りやすい

スクラムでは、スプリント単位で、完成の定義と受け入れ基準にしたがってプロダクトバックログ項目を完成させなければいけません。 プロダクトバックログ項目が大きいので、複数スプリントにまたがって1つのプロダクトバックログ項目に着手しようとしてはいけないのです。 つまり、スプリント期間が短ければ短いほど、プロダクトバックログ項目のサイズは小さくなるのが普通です （1つのスプリントに投入するプロダクトバックログ項目が1つということはなく、大きくてもスプリント期間の半分以下で終わるようなサイズの項目を複数個投入するのが一般的です）。 時間が短くプロダクトバックログ項目が小さいということは必然的に中身が明確であることにつながります。

スプリントに投入したプロダクトバックログに関してスプリント開始後にたくさん不明点が出てくるような状況だと、そのプロダクトバックログ項目は完成しない確率が高くなります。 長いスプリント期間であれば、とはいえ、なんとか頑張って吸収するということができるかもしれませんが、それは本来やるべき事前準備不足を隠してしまうことにもなります。 一方で、1週間スプリントだと、もし不明点がでてその時すぐにプロダクトオーナーと会話ができないような待ちが発生するとどうにもならなくなります。 したがって、プロダクトバックログリファインメントで事前に次以降のスプリントに投入される可能性のあるプロダクトバックログ項目が本当にReadyなのかを精査するようにもなります。 そして1週間の半分くらいの規模のプロダクトバックログ項目であれば、「なにができれば完成なのか」の認識は比較的容易に合わせられるはずです。 認識があっていれば、プロダクトオーナーの受け入れ確認も容易になります。

スパイクが必要なプロダクトバックログ項目が明確になる

上の項目に関連して、スプリント期間が長いほど、あるプロダクトバックログ項目を実装するのにあたって、調査系のタスクも一緒に含めてしまいがちです。 完成とは何なのかは合意できていても、それをどうやるのかはスプリントに入ってから調査して進めていってしまうのです。 一方で、1週間スプリントのような短い期間では、特定のプロダクトバックログに関する調査をスプリントに入ってからやっていたのでは、プロダクトバックログ項目が完成しないリスクが高くなります。 つまり事前に調査まで終わらせておいて、開発チームが自信をもって作れる状態までもっていくような力が働きます。 プロダクトバックログリファインメントなどで、調査が必要なプロダクトバックログ項目を明らかにして、バッファを使って事前調査したり、場合によってはプロトタイプなどを作るプロダクトバックログ（タイムボックス上限を定める）を事前にこなすようになっていきます。 こうすることで、プロダクトバックログ項目がスプリント期間中に完成する確率が上がっていきます。

プロダクトオーナーが変更を我慢しやすい

プロダクトオーナーはステークホルダーと協働し、開発チームのパフォーマンスを踏まえて、プロダクトをどうしていくかシビアな判断が必要になります。 そして、ビジネスの状況は刻一刻と変化します。 長いスプリントになればなるほど、ステークホルダーからの要求やビジネスの状況との乖離の影響を受けて、プロダクトバックログ項目を入れ替えたいという欲求が強まります。 一方で、スプリント期間中のプロダクトバックログ項目の入れ替えは、プロダクトオーナーと開発チーム間の調整が必要です。 単に追加のプロダクトバックログ項目を依頼したり、着手中のプロダクトバックログ項目の受け入れ条件を変更したり、といったことは開発チームの合意なしではできません。 一方で、プロダクトオーナーとしては変更したい理由があるのに、それが受け入れられないのを我慢しなければいけないことにもなります。

ここでスプリント期間が短ければ、現状は受け入れた上で、次のスプリントで軌道修正をかければよいと割り切ることができます。 その割り切りによって開発チームは割り込みを受けること無く集中して作業を進められます。

なお、プロダクトオーナーにはスプリントをキャンセルする権限が認められているので、どうしてもという場合はスプリント期間に関わらずスプリントを途中中止して構いません。 ただし、いつもそれをやっているとプロダクトは何もできず、開発チームのモチベーションにも影響があるので、数か月に1度といった頻度までが限界です。 プロダクトオーナーとしての準備を怠ったが故のキャンセルは許されません。

ごまかしが効かない

最後になりますが、ここまで見てきた内容全体によって、スプリント自体のごまかしが効きにくくなります。 事前準備をきちんと行い、ムダなく着実に進めていかないと、成果がでない状況になります。 つまり、長いスプリントではなんとか吸収しきれていた問題は、短いスプリントだと大きな問題として露見していくことになります。 長いスプリントによって隠れていた本当の問題が露見すれば、それを改善することで、より成果が出やすくなります。

短いスプリントの弊害

1週間スプリントの利点ばかり説明してきましたが、いくつかの弊害や考慮ポイントがあります。 最後にそれを説明しておきます。

複数開発チームがある状況では、結合が間に合わない

それなりの規模の開発で、開発チームが複数ある場合、1週間のスプリントではそれぞれの開発チームの成果物の結合が間に合わない可能性があります（Nexusなどでも毎スプリントの結合が求められています）。 複数開発チームが存在する場合、コミュニケーションのオーバーヘッドがどうしても避けられず、またどこか一箇所の問題が全体に影響を与えやすくなります。 したがって、バッチサイズを多少大きくして確実に結合していく必要がでてくるかもしれません。

いつも追い立てられている気がする・ゆっくり考える時間がない気がする

1週間という短い期間に区切ると、どうしても残り日数や時間を意識する回数が増えます。 したがって人によっては、いつも追い立てられていると感じることもあります。 持続可能なペースで働くことが重要なので、その場合は、バッファの比率を見直すのも1つの手です。 また、プロダクトの状況次第では、祝祭日の絡む週のスプリントをときどきスキップする、という選択もできるかもしれません（あまりお勧めはしませんが）。 別の要因として、外部からプレッシャーがかかっていることもあります。 持続不能なペースで働くこと、決めたことを全て達成することを約束しているわけではないので、組織内で別のよくない力学が働いていないかどうかを確認し、それを改善していくとよいでしょう。

それでは。