※本記事では継続開発をしているスクラムチームがまとまった機能をリリースする状況を想像してください。関係者は多くとも10人程度で、期間は3ヶ月程度のシンプルなものです。
プロジェクトのフェーズごとに適切な計画の量をイメージして共有できると上手くいく手応えがあり、それをチームに展開した時の様子を書こうと思います。自分が陥った失敗ケースも示すので参考にしてください。おそらくスクラム初心者が陥りがちな罠だと思います。
ウォーターフォール
まずは手慣らしです。古典的なウォーターフォールだと計画の量はこんなイメージです。
開発開始時に一気に計画を行い、開発がスタートすると再計画はほとんど行われません。リリースが近くなると、結合したりQAが走ったりして色々な問題が明らかになるので対処するための計画が発生します。この図のように後ろの山が小さく収まることは珍しく、実際は開発期間中にたまりにたまった問題が溢れ出して炎上します。これが散々言われているウォーターフォールの問題です。
うまくいかなかったケース
自分が初めてスクラムを実践したときは以下のような計画の量をイメージしました。
ずっと同じペースで計画をし続けようという図です。その時は、リファインメントによってプロダクトバックログアイテムを用意して、計画とレビューのイテレーションで軌道修正をしていけば、特別なイベントは必要ないのではないかと思っていました。
しかしそれは誤りで色々な問題が発生しました。その中でも最大の問題はプロジェクトの全体像が見えてこないことです。定期イベントだけでちびちび計画を更新していくので、次のスプリントか、良くて次の次くらいのプロダクトバックログアイテムしか準備されません。そうすると、全体の設計の整合性やプロジェクトのスケジュールがなかなか見えてきません。
自分のケースでは幸い整合性は保たれて無事ゴールしましたが、あとから問題が発覚してウォーターフォールと似たような失敗を経験する可能性は十分にあったでしょう。
うまくいったケース
自分がうまくいったケースでは以下のような計画の量をイメージしました。
まず、プロジェクト開始時はウォーターフォールかのように全体を設計します。ここで全てのプロダクトバックログアイテムが洗い出されるくらいが望ましいです。スクラムの文脈ではこのフェーズはあまり語られない印象があり難しいですが、必要なメンバーを集めて必要なだけ話すつもりで泥臭く進めると良いと思います。開発がスタートしたら、リファインメントや計画、レビューといった定期イベントによって、アイテムを詳細化したり過不足を補ったりします。リリースが近づいたらギアをアップして計画を増やします。POに毎日デイリースクラムに来てもらうといったことも考えられそうです。ここまでやると、だいぶ安定してプロジェクトが進むようになるでしょう。
一般的なプロジェクトマネジメントの文脈では最初にタスクを洗い出すのは定石で、いま思うと必要に決まってるじゃんと思うのですが、慣れないスクラムの文脈でもそれが必要だと認識して発揮するには意外と気づきが必要だったなと思います。
まとめ
プロジェクト進行と計画の量のイメージについて、いくつかのパターンを示しました。ウォーターフォールとスクラムもどきは、実は計画の総量は大して変わっておらず、割り振りを変えているだけです。それらが両方うまくいかないのはおもしろいと思います。安定したプロジェクト進行を得るには、計画のタイミングを調整するだけではダメで、計画の総量もちゃんと増やす必要があるということです。うまい話はタダではないんですね。計画にコストを払うことに抵抗がある人もいるかもしれませんが、プロジェクトが手戻りなく、予想通り、安定して進むのは本当に素晴らしいことです。平均的には一番早いでしょうし、成功体験にもなり、やってよかったと思えるプロジェクトになります。コストを払いすぎるということはまずないので、たくさん計画しましょう。
