スケーリングはイベント設計の話ではない

こんにちは。天野です。

RSGTなどアジャイル系カンファレンスに参加していると、ここ1−2年は特にスケーリングに関するセッションが増えたように感じます。スクラム・アジャイルを実践するチームが増え、最初の導入としての単体チームの実践に関する知見から、組織としてどううまく実践するかに興味関心が徐々に移っているのかなと思いました。

自分自身も、スクラムマスターとして活動を始めた当初から「スケーリング」はとても大きなトピックでした。そして、実践から学ぶ過程で、徐々に「スケーリング」のイメージや実際にする活動の認識が変わってきたことに気づきました。

今日は、スケーリングが指すものや自分の認識がどのように変わってきたか書いてみたいと思います。

最初は「開発チームに数十人いるからスケーリング必須だよね」と思っていた

自分がスクラムマスターとして活動を始めた時は、すでに数十名が開発に関わるプロダクト開発チームになっていました。スクラムガイドに書かれているクロスファンクショナルなチームを作る重要性は頭で理解しつつも、「とはいえ現実はもっと複雑だからその中でどうやるか考えないとね」と構えていました。

最初から「数十人でどうやるか」という課題意識があったので、早い段階からスケーリングについてあれこれ調べて試行錯誤していました。一番最初に受けた認定コースはCertified LeSS Practionerで、CSMを受けるよりも1年近く早く受けていました。当時はとにかくスケーリングをどうにかしなければと考えていたことがコースを受ける順番にも現れています。

LeSSを学び、これこそ自分が求めていたものだと感銘を受け、自分のいるプロダクトチームにOverall系のイベントを導入し、複数チームが同期を取りながら開発を進められるようにしました。

複雑な問題を複雑なまま扱うためにスケーリングを導入してもうまくいかない

複数チームで協調して開発する姿は、一見スケーリングに成功しているように見えます。しかし、実態は渡されたPBIを粛々と開発するフィーチャーファクトリーのままでした。

自分が陥ったスケーリングの罠は、スケーリングをイベント設計の問題だと捉えてしまったことです。複数チームにPBIを供給し、定期的に進捗を確認するイベントを設計することがスケーリングだと思っていました。

当時は、ひとつのプロダクトの開発に関われる開発チームが多ければ多いほど偉いような感覚があり、「（USの某サービス）は300チームで開発してるらしい」といった話を聞いては憧れていました。

多くの組織では、複雑な問題を扱うためにさまざまな方法で分業をしています。ここを見直さず、大きいレベルの分業体制を変えないままでは、どのようなスケーリングフレームワークを採用してもうまくいかないと教訓を得ました。