10人を超えたら今すぐチームを再編成しなければいけないのだろうか
私の所属するチームの人数が10人を超えてしまった。さてどうしよう。
チームの最適な人数は10人未満である理由
こちらの記事で論じたとおりで、人と人が協力して情報交換をして目的に向かって前に進む。その人数編成に限界があると見ている。
組織が課長と平社員のような昔ながらの組織編成（例：達成型組織）であっても、ティール組織のように個々がセルフマネジメントで動く組織であっても、2,30人単位で同じ動きをするのは難しいはずだ。
スケールするスクラムを考える
スクラムにおけるチームの構成人数は3～9人程度が良いとされています
引用：https://eh-career.com/engineerhub/entry/2021/09/29/103000
ソフトウェア開発の世界のスクラム（詳細認識前提で以下解説）を参考に編成を考えても、スケールの必要が出てくるだろう。人が増えれば時間制約やコミュニケーションパスにボトルネックが生じてくるからだ。
はじめは少人数で動かしていたチームに人が増えた時にスケールする必要が出てくる。スクラムはリソース効率ではなくフロー効率と本記事では語られているが、スケールによる効率化の定義は見誤らないようにしたい。
スクラムオブスクラム
階層的にチームをスケールすることになる。15人チームを7,8人の二分割のチームにしたとすると、それぞれデイリースクラムを行う。POもそれぞれいる。各チームの代表者が集まる。このとき二人。
POはPOチームとして編成する。その代表者が一人。この合計三人と経営に関わる最終意思決定者を加えて4人で新たなチームを作り、そこで情報共有をすると理解した。
これらで対策としたのは「コンウェイの法則」に立ち向かう必要性が出てきたのだと記事より感じた。実践内容を参考に組織編成で実施の対策ができる状況を作りたい。
ユニコーン企業のひみつより見えるスケール
スピードが求められる現場では、この本のようにプロダクトに対してチームのスケールをせまられる状況が出てくる。スタートアップの話ではあるが、学習を重視していることがよくわる。
チームを再編成し続けるということは、学習を促す組織を作り続けることかもしれない。この本でもスクワッドと呼ばれる少人数（八人以下）の職能横断の自己組織化チームを提案している。ここでも10人の壁が見える。
本書の場合はスクワッドが基本だがスケールが迫られると、トライブ（Tribe）・チャプター（Chapter）・ギルド（Guild）といった役割に沿った横断グループで組織編成をすることを是としている。
これはスクラムオブスクラムのようにスケールの問題が発生したときは、組織間の連携を密にしつつも、役割で集まることで互いの学習の機会を増やしていると見ることができるだろう。
この辺りは直感的にも同意できることだ。自身の組織編成においても、目的達成組織を一つおいたとしても、それぞれの役割で産まれた横断対応による情報交換が必要な場面をよく見かける。
生産性を考えるから組織編成をする
組織編成をするのはボトルネックをできるだけ生じないように効率を求めるからやることである。チームだからこそできるとは、会社だからこそこの世に恩恵をもたらすことができると考えているからだ。
一人でやれるなら一人でやっている。二人でやるから三人でやるから大きなことを成し遂げられるとなって仲間が集まるのだろう。本書では最終的には生産性の話でも文化情勢の話が出てくる。
このnoteでも語ってきたが文化情勢があって初めて組織編成ができる。この判断も納得度が必要でデータやファクトが求められるだろう。そう考えるとますますチームづくりというのは難しい時代に入ったなと感じる。
マネージメントとしての役割でこの組織編成を考えると、やはりチームの人数は10人未満にした上で、チーム間が情報交換して行動できる状態にしたいなと感じた。