Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。
しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。
なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？
そういうことを考えてみた。
最初から人がたくさん必要な場合
そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理想だが、世の中にはそんなわけにもいかないシステムはいくつかある。
大企業の基幹システムなどは、最初からそれなりのサイズでリリースしなければいけないものもあるだろう。当然リリースしながら育てていく漸進的なやり方はこういった場合でも有効ではあるが、いかんせん規模がとてつもなく巨大であるならば、それを現実的な工期で収めるにはどうしてもマンパワーがいる。このような開発現場でスクラムを採用する場合、スケーリングスクラムの手法は有効だろう。
しかしこれは楽な部類ではある。
最初から人がたくさん必要ならば、そのように組織設計をすればよいし、複数のフィーチャーチームを維持する前提でアーキテクチャを含めた全体設計が可能だからだ。 最初からわかっているのなら、そういう準備をしてから導入すれば良い。やればできる。
あとから人を増やしたくなる場合
厄介なのはこちら。
最初は1つのスクラムチームで開発を開始し、ローンチし、そこからさらに継続的に開発する。そのようなチームをスケールしたくなる場合。 「我慢しろ。スケールするな」が1つの答えではあるのだが、なかなか現実はそのようにうまくいかない。
6人のスクラムチームが8人になる。さらに人が増えて10人になる。このあたりからスクラムチームの維持は難しくなる。では5人のチーム2つに分割するか？ しかしこの段階ではチームを分けたことによって生じるコミュニケーションパスの増加による負担が、チームのスケールメリットに見合わない。システムのアーキテクチャも、チーム分割に耐えられるようなスケーラブルに設計になっていない。
こういう感じでどんどんチームは追い詰められていく。
ではそもそもなぜチームは人を増やしたくなるのだろうか。作業の優先順位を適切にコントロールして、やるべきことを厳選すれば1つのスクラムチームでの開発を維持できるのではないのか。
やりたいことではなく、やらないといけないこと、が増えてくる
長期間ソフトウェアを運用し、そして幸運にもその事業が成長した場合、チームとしてやりたいことよりも、「やらないといけないこと」が少しずつ増えていく。
たとえば、ユーザーの増加に伴ってカスタマーサポートの負荷は少しずつ増えていく。ソフトウェアのサポートには、当然場合によってはエンジニア稼働も必要であるから、そのような仕事がちょっとずつ増える。
技術的負債も積み上がる。もちろん、定期的に返済したり、そもそも負債が生じにくいように注意深く開発はするのだが、それでもシステムのスケールに伴ってこれらへの対処は増えていく。5年以上稼働しているシステムであれば、スプリントバックログには常時なにかしらの負債返済のタスクが入っているだろう。
こういう「やらなければならないこと」に少しずつ圧迫され、「やりたいこと」に振り分けるリソースはちょっとずつ減っていく。なので、ちょっとずつ人を増やしたくなる。
急激に事業が成長して、一気に人を増やさなければならない、という状況ならまだ幸運かもしれない。諦めもつくし、一気にスケールすればスケールメリットがデメリットを上回ることもあるだろう（それはそれでカルチャーの維持とか、組織づくりとか別の厄介事はたくさん生じるが、これはスクラムチームの話なのでそういうのは今は忘れておく）。
このような事態において、歯を食いしばって「1つのスクラムチームを維持する」良い方法はあるだろうか。 そもそも事業が成功しているなら、人（雇用）を増やして幸せを大勢の人と分かち合いたい、という動機もあるんじゃない？
こうして、ぼくは今日も出会うアジャイルコーチに質問するのである。「スクラムチームをスケールするにはどうしたらいいですか？」
なにかいい方法があったら教えて下さい。
