チームのスケールとリーダのキャパシティ問題

チームをスケールさせることの難しさはリーダかマネージャのロールをやってみないと実感出来ない。やってみたことがないと経験知を持ち合わせていないから自分の担当としての経験値で判断してしまうためだ。

そしてやってみてわかることは、世間で、あちらこちらで見かけるチームビルディング、チームの向かう方向性、チーム内の意思伝達などである。

その点を事例として学ぶには次の記事の「SmartHR使い物にならない問題」から読むと良い。

チームをスケールするのはビジネスニーズに応えようとするからだ。手のつかないバックログ、多忙なエンジニアの負荷軽減など見えている事由は様々であっても、結局は、エンジニアのリソース以上に仕事が多いことが原因だ。

エンジニアサイドで期待値に応えられるベロシティが出ていればバックログがあっても問題ないかもしれないが、そうでないと外部からのプレッシャーが高まる。エンジニアも期待に応えたいからと良心に任せてしまうとそのツケはいずれ利子がついて回ってくる。

経験から言えば、リーダのロールを担う人材、例えばマネージャやVPoEのキャパシティでエンジニアの組織の構成を構築する必要がある。

なぜここでマネージャのキャパシティが関係してくるのかというと、人は一度に目を掛けられる人数がバラバラであるからである。3人のチームなら目が行き届くリーダもチームが5人になった途端、2人は視界から消えてしまう。これをリーダのキャパシティ問題と個人的に呼んでいる。

このキャパシティ問題を知った上で、組織構造を見つめ直すと見え方が変わってくる。例えば、リーダとメンバのフラットなチームを考える。

2が成り立つのは、リーダが50人に渡って目が届くことが前提になる。つまり、チームがチームとして機能するかどうかはリーダの資質に強く依存する。

それを認識しないでメンバをスケールし続けるとどこかで崩壊し始める。その崩壊も自然に始まる。なぜなら、リーダ自身がキャパシティの閾値を知らずにスケールさせているからだ。

この崩壊は、リーダの世代交代で突然起きることもある。想像がつくだろう。キャパシティはリーダの資質だからだ。

このように組織構造を眺めてみると、構造化した組織は一概に悪いとは決め付けられないことがわかる。

であればリーダの資質で組織は少しだけ階層を持たせた方が良い。単純なケースではプロダクトやシステム単位の機能で分割する。

ここで次世代のリーダを育てることを考えるのは正しい。ただ、チーム分割をするとチーム内の文化が生まれてしまうので、全体での方向性やシャッフルをしなければ技術が固定化されてしまう。

エンジニアには常に新しいテーマの選択肢を与えることもリーダの仕事である。