コミュニケーション的負債よりチームの増殖を

システムの処理能力の規模を拡大するときにはスケールアップやスケールアウトする、なんて言ったりますね。今はオートスケーリングでしょうか。

処理させたい能力のキャパシティを広げるだけのニーズが見込めるけれど、今は需要が小さいからスモールで始めて、みたいな。

チームの人数問題

チーミング、チームを組織化して機能させ、期待する結果を確実に得ようと思ったら、チームの人数は少ない方がいいです。チームの人数が1人増えれば作業を分担して、増えたメンバを立ち上げるまでのリードタイムやその後続くコミュニケーションコストが人数の数だけ増えるので結果的に一人当たりの生産的な活動に使える時間が削られてしまうからです。

ここのところは経験知や感覚ではわかっているけれど埋もれてしまうので逆に気づきにくいのですが、エンジニアを1人増やしたからと言ってすぐに一人分の出来高が得られるわけではない（投入されたエンジニア＋周りのサポートコスト（複数人数）と可視化されないコストが大きいんだよ）ことを仕事の中で意識すると理解できます。

アジャイル開発でもチームを作ったらメンバの入れ替えは避けよう的な物言いがあると思うのですが、前述のことも含まれていると思うのです。

チームのスケールアウト

 チームがあって、開発規模が増えてくると人数を増やしたくなるものです。だって需要があるのですから。例えば、ウォーターフォールでのシステム開発は、局面ごとに工数を見積もって捌けるだけの人数を積み上げます。基本設計で○○人、詳細設計で△△人、コーディングUTで□□人、のように。

ウォーターフォールのシステム開発自体が労働集約型の性質を持っているのでこうした局面での規模を見積もり（精度はここではスコープ外）して、工程で必要となるスキルとスキルレベルを持っているエンジニアを調達する（集められるかどうかはスコープ外）わけです。

チームは機能別の分掌担っていることが多いので、分掌したグループにジョインすることになり、先に述べたように可視化されないコミュニケーションコストがじわじわと積み上がっていくのです。

コミュニケーション的負債の誕生です。

コミュニケーションコストが積み上がっていくということは、誰かが情報を待っていて、誰かがずっと供給することになります。なぜなら、階層型の組織のデザインとなっていて、階層ごとに権限を割り当ててしまうから。階層構造を取ると必ずそうなります。

チームの増殖

チームのエンジニアが増えるたびにしなければならないことの一つに、チームの行動規範、つまりチーム共通の価値観をインストールすることがあります。それをするのはリーダの仕事です。なぜならリーダがそれをチームとして実行してほしいから。

でも、リーダはリーダで仕事もあるし、やらなければならないけれど時間の優先順位をつけるとやはり優先したいけれど…となるのです。それで新規参加メンバの行動をモニタリングするのもリーダのリソース問題が。

なので人数を増やすのではなく、チームを増殖するのです。

コアなチームメンバによりチームの行動規範を実践し、ビジネスのスケールに合わせてチームを増殖するのです。ただチームを増やすのではなく、行動規範を実践できるコアメンバを2つに分け、それぞれに新規メンバを入れチームの価値観を共有しながらメンバを育てるのです。チームを自己増殖させるのです。

人の細胞だって、スケールアウトもスケールアップもしないですよね。だったら人をチームの細胞と見たてたら同じように細胞を増殖させた方が自然ですし。

これがエンジニア個人に向くとなぜかエンジニアのスケールアップ、つまり謎の生産性向上という精神論を持ち出す輩が出てくるのが解せないですが。