1週間？2週間？スプリント期間で迷ったときの決め方とレビューを分けた話

はじめに

今回はプロジェクトの新しいチームの立ち上げをしている中で、スクラムイベントの調整が主要メンバーの多忙なスケジュールによりなかなか悩ましい状況にあり、どのように考えて決着したのかの体験談を書いていこうと思います。ただ、まだチームとしてのスプリント活動は開始していないので、結論で出したやり方が結果どうだったかについてはここでは言及していません。

直面した課題

スクラムイベントの調整に際して、スプリントレビューを設定するのに全員が参加できる時間を確保するのがなかなか難しく・・・。特に、ドメインオーナー・ドメインサポーターは必須参加としつつ、他のステークホルダーもできれば必ず参加して欲しいけど、かなり忙しいメンバーだったのでできる限り合わせられる時間を模索していました。

スケジュール調整を進める中で、「そもそも他チームと同じ1週間スプリントにこだわる必要はないのでは？」という疑問が生まれ、2週間スプリントという選択肢の検討もし始めました。
同じプロジェクトの中でほとんどのチームは1週間スプリントで進めていますが、一部のチームは2週間スプリントをしているところもあるのを思い出したためです。

状況

• 主要参加者全員のスケジュールを合わせるのは不可能に近い
• 開発チーム立ち上げ初期で業務理解も開発も始まっていない・軌道に乗っていない状態

やったこと

最初は、単純にカレンダーと睨めっこして比較的全員が参加できそうな曜日・時間にあたりをつけて提案するということをしてました。ただ、それだと「この人は必ず毎週いて欲しいのにこの時間だとそれは無理・・・」とか、「結局この時間だとこの人が参加できるのは 1、2ヶ月先だぞ・・・」とかになってしまったので、あまり良くないなと。

そこで、招待しようとしているメンバーのロールによってプロダクトに対する関心ごとは違うということに着目し、そこから複雑に絡み合っている要素を整理してうまく合わせられないかと考えました。

1. スプリントレビューの目的を分解する

まずは、スプリントレビューって何のためにやるんだっけ？というところを以下のように整理しました。

• 仕様確認・フィードバック収集：作っているものが合っているか、どう作るべきかを頻繁に確認したい
• 進捗・状況報告：プロジェクト全体の進捗を関係者に共有したい

2. 参加者を目的別に分ける

目的が整理されると、ではそれを知りたいのは誰か？気にしているのはどのロールか？というのが分けられました。

• 仕様確認が必要な人：実際に触ってもらい、仕様を詰めていく必要がある業務担当者
• 状況把握が必要な人：進捗やゴール達成状況を知っておきたいマネージャー層

3. 会議を分離して最適な頻度を決める

幸いなことに、目的別に対象者を分けると、それぞれのグループで参加可能な時間帯の傾向が見えてきてスケジュールの確保の容易さも上がったので、ちょうどいい日時を押さえられることに気づきました。

• 仕様確認ミーティング：業務担当者と開発チームで、仕様の確認やデモで作っているものを見せてフィードバックをもらう
  • ここのサイクルは早く回していきたいので、週次のタイミングにする
• スプリントレビュー：より広い関係者に対して、スプリントゴールの達成状況や進捗を報告する
  • 重要ではあるが、ここのメンバーの時間確保が難しいため、隔週のタイミングにする
  • （同じメンバーに対するレビューを他のチームが隔週で行っていため、それとずらせば時間確保が比較的容易という経緯もありました）

最終的な判断

スプリント期間を2週間にするか？

レビューの目的別に参加者を分けて会議を分離するのがいい塩梅で調整できそうだったのでよかったのですが、気になっていたのは進捗・状況報告が2週間ごとになることでした。

そのタイミングに合わせてその他のスクラムイベントを組んで2週間スプリントにするかも検討したのですが、それだと取り返しのつかない遅れが発生してしまうのも怖い・・・ということで、各種スクラムイベントについてもそれぞれチームにとってベストな頻度で行うのが良いと判断しました。

決定したスケジュール

最終的には以下のようなスケジュールで進めていくことにしました。

• 仕様確認ミーティング：1週間ごと
  • 短いサイクルで仕様を理解したりデモを行い見てもらうことで、要件のキャッチアップと開発の速度を上げられるようにする
• スプリントレビュー：2週間ごと
  • プロジェクト管理を行っているメンバーに対して、最低限の時間で進捗や状況の報告を行う
• スプリントプランニング：1週間ごと
  • レビューが隔週になる分、チームとしてはゴールの検査と予定立ては1週間ごとに行い、リスクの早期発見ができるようにする
• レトロスペクティブ：2週間ごと
  • レビューの後に設定し、ステークホルダーからのフィードバックを受けた上で振り返りができるようにする
  • 足りなければ追加も検討する

体裁としては、スプリントプランニングを1週間ごとに行うので1週間スプリントとしています。

学んだこと

スプリントレビューは必ずしも1つの会議である必要はない

スクラムガイドに忠実であろうとするあまり、スプリントレビューを1つの会議として全員を集めることに必死になっていました。しかし、実際には：

• 仕様確認のための「動くものを見せる会」
• 進捗報告のための「スプリントレビュー」

と分けることで、参加者のスケジュール調整がしやすくなり、それぞれの目的に集中できるやり方を見つけることができました。

スプリント期間は「スプリントプランニングの頻度」で決める

スプリントプランニングがスプリントゴールを達成するための計画作りであり、スプリントの開始を意味することから、プランニングの頻度がスプリント期間を決めると言えます。

今回の実践を通して、スプリント期間を決める際の判断軸を自分の中に確立できた気がします。
チームとプロジェクトの状況を鑑みて、以下のように考えると良いと感じました。

• プランニングとゴール検査の頻度：まだ開発が軌道に乗っていない・リリースまでの期間が短い状況では、短いスプリントが適している
• レトロスペクティブの頻度：チームの成熟度や改善の必要性に応じて調整可能
• スプリントゴールの粒度：どれくらいの単位で達成可能なゴールを設定できるかも重要な判断軸となる

柔軟性を持ちながらも原則を守る

固定観念にとらわれず、チームやプロジェクトの状況に合わせてそのチームにとって何が最適かを柔軟に考え突き詰めていくことが大切だと感じました。

• スプリントレビューの「動くものを見せてフィードバックをもらう」という本質は守る
• ただし、実施方法は組織やプロジェクトの状況に合わせて柔軟に調整する
• 困ったら試してみて、レトロスペクティブで振り返って改善する

まとめ

当初は「他のチームがこうしているから」や「レビューってこういうものだから」みたいな意識に囚われてしまっていて、柔軟な考え方ができていなかったように思います。

大切なのは：

1. 何のためにそのイベントをやるのか目的を明確にする
2. 目的に応じて参加者や実施方法を柔軟に調整する
3. チームの状況（成熟度、プロジェクト期間、不確実性）に応じて判断する
4. 実際に試してみて、うまくいかなければ改善する

今回のケースでは、1週間スプリントで週次の仕様確認と隔週の進捗報告を組み合わせることで、スケジュール調整の課題を解決しながら、必要な頻度でフィードバックと検査ができる体制を作ることができました。

また、悩んでいるときに他のスクラムマスターのメンバーとの壁打ちでこのような結論を出すことができたので、相談することの大切さや、スクラムを実践している人たちの経験談や知見を知ることが自分を成長させてくれると感じました。

スプリント期間やイベントの頻度に正解はないと思っているので、まだこのチームも立ち上がったばかりでこの判断でうまく回っていくのかも未知ですが、検査と適応を繰り返してベストなやり方を今後も模索していきたいです。