チーム人数肥大化によるリスクの顕在化

弊社では順調に採用で人数を伸ばしていましたが、一方で開発チームの肥大化を招き結果として様々なリスクを併発していました。

チーム分割の直前ではなんと１４人ものチーム編成だったと記憶しています。

多人数化したスクラムにおけるイベントの非効率性

例えばデイリーミーティングは30分で収まれば御の字で30分を超えることもママありました。他にもプランニングでは大人数が故に着手案件が多様化しており、当事者意識を保ちにくい状態が発生してしまい、全員が一つの案件に集中できず、結果的にフロー効率もリソース効率も損なっており、とても健全とは言える状況ではありませんでした。

スクラムの中で（個人的に）最も重要視していた振り返りも、上がったKPTを読みきれないという非常に申し訳ない気持ちだったのを覚えています。

案件認知負荷の増大

チームとしてはスプリントバックログに入っている案件については、把握をする必要があります。ただ、通常の１チームスクラムの倍の人数がいるともなると、案件概要を把握するだけも一苦労の量です。

それを（ヘルプやレビューのために）設計やコードレベルまで認識するのはかなり難易度の高い技量を求められる状態になります。

幸いにも具体的な事故には紐付きませんでしたが、このまま人数が増えていった場合に同様のやり方で進められない、つまりスケーリングできないリスクを抱えていたと考えられます。

チーム分割の方針策定

テックタッチのチーム構成についてお話したいと思います。

もともとのチーム構成

実は私が入社する前は２チームだったのですが、入社後開発者の意見も聞きながら１チームに統合していました。

コードレビューのコストや特定技術スタックの開発者が一人になってしまったりすることで認知負荷が高かったこともありますが、当時の私は「ミッションや目指すゴールが同じなのであれば同じチームにした方がやりやすい」という思いもあって、統合という結論で進めさせていただきました。

この事自体は問題解消としてかなり効果を発揮したのですがその一方で、人数が増え、嬉しい悲鳴とともに出口戦略が必要になりました。

転機の時

採用が進んできて、ちゃんと分割できる状態が何となく見えるようになった時（と言っても入社して３ヶ月ほど経った時ですが）に、CTOから「そろそろチーム分割について考えてほしい」というオーダーをもらいました。

当初こそ「ミッションが明確に設定できない限りは分ける意味はない」と否定的に考えていましたが、前述したようなリスクが顕在化し始めておりチーム運営的にしんどい時期でもあったのでチームに対峙するミッションから検討し始めました。

コードレベルまで至らなかったコンポーネントチームの罠

最初に考えていたのはユーザーのロールごとにチームを分けるという案でした。

弊社のプロダクトはローコードツールなので、設定を編集するユーザー（ガイドデザイナー）と、設定をもとにガイドを再生するエンドユーザーの大別すると２つのユーザーセグメントが存在しています。

それぞれのユーザーに対峙しながら開発することで、ユーザーのペルソナに向き合い、寄り添った開発がしやすいのではと考えていたのですが、そう一筋縄では行きませんでした。

まず、アプリケーションは別ではあるものの共通化されたコード群も多数あり切り離しに時間がかかってしまうことと、Componentチーム（後述）に近い体制となってしまうため、ユーザーストーリーが完結しにくいのではないか？という懸念が浮き彫りになりました。チームメンバーとも話ながら「これはちょっと難しいかも・・・」と感じ始め、もう一度やり方を模索することに。

参考）ComponentチームとFeatureチームの違い

Componentチームはコードによる境界をコンポーネントとし、下記図のようにチームごとの守備エリアを明確に決めるというものです。

認知負荷は明確に低減できるものの、案件ごとに擬似的なプロジェクトを組む必要があり、都度調整が必要になってしまいます。もちろんひとつのコンポーネントで完了できるタスクもありますのでちょうどよい切り方ができればうまくワークするのではと思います。

一方でFeatureチームは、コード境界によるコンポーネントで分けず、1つのアイテムをやりきれるメンバーをしっかり抱えたチームになります。認知負荷はComponentと比較して減りにくい一方で、1チームで完結しやすくなるため自律的なチームがワークしやすい環境づくりが可能です。

	Pros	Cons
Componentチーム	認知負荷の低減	ユーザーストーリーが１チームで完結しにくい
Featureチーム	ユーザーストーリーを１チームで完結しやすい	認知負荷が低減しにくい

※こちらからのリンク

ユーザーストーリーの特性に合わせたFeatureTeam

当初の課題に加えて守りたい物もありました。それは「お客様への価値貢献を考えるチーム」であることです。

そのためにも下記の2つはかなりこだわりを持ちながらチーム構成を検討していました。

クロスファンクショナルチームであること
価値に向き合えるチームであること

とすると、先程述べたフィーチャーチームとすることは必要な一方で、当初の課題がのしかかります。

「スクラムイベントの肥大化を抑える」
「案件及びコードの認知負荷を下げる」
「スケール可能なチームづくり」

テックタッチはワンプロダクトSaaSであるため、分解するにも一筋縄では行きません。

単に同じ目的を持ったチームを複製することで解消は可能ですが、そうなると認知負荷の低減効果はかなり薄れてしまいます。

考えた結果としてのプロダクト基盤チーム

様々な切り口での検討を進めていましたが、CTOやPdMと会話する中で基盤チームはどうかという話が出ました。

他の切り口ではどうしてもスポット対応なチームだったり、案件量が安定しないものだったのでなかなか採用に至りませんでしたが

テックタッチの権限などのユーザー基盤
テックタッチを利用できるプラットフォームの拡大
管理系機能の拡充

などに重きをおくプロダクト基盤チームを設置することでうまく切り分けることができました。

複数チームの運営

ただ、チームを分割することはできてもうまく意思決定をするための運営ができなければ、元の木阿弥です。

ここも思考を巡らせましたが、大規模スクラムとしてのLeSSを装着することにしました。 LeSSの採用についてははそこそこの分量で語れそうなので別エントリにて記載したいと思います。そのため、ここでの説明は割愛します。

結果はどうだったか？

これを記載しているのが９月下旬頃ですが、実は分割からすでに４ヶ月ほど経っています。

当初より３ヶ月ほどで振り返りを行うという想定でしたので、アンケートを取った結果下記となりました。

チーム人数が減となったことによる評価
- チームごとのタスクが明確になって、やるべきことが把握しやすくなった
- 動きやすく、やるべきことに集中できるようになった
- （チーム内の）会話がスムーズになった
スクラムイベントの評価
- より短時間で完結できるようになった
- 振り返りで全部の意見を拾え、話すべきことが話せるようになった（以前は時間制約のため、話しきれない事が多かった）
- デイリーは進めやすくなった
認知負荷の減少評価
- 同時並行するストーリータスクの数が減り全体把握がしやすくなった