私がチームと最もよく交わす議論は、組織の大きさについてです。より正確には「我々には来年、2 倍 / 3 倍 / 4 倍のエンジニアリングチームが必要になり、今、その経験を持つリーダーを雇わねばならない」というような議論になるのです。そしてその議論をうまく進めるためには、組織の規模に関する理論が必要です。
チームを成長(grow)させるためにはチームを大きく(grow)しないこと、これは明らかです。チームを大きくすることはむしろ、他の差し迫った問題を解決するためのツールです。実際には、多様な課題に直面している何百人ものエンジアリングリーダーや CEO との会話において、「我々には十分なエンジニアがいない（適切なエンジニアがいない）」という結論には、全世界的なカバレッジがあります。そして私の記録によると、ほとんどのチームは採用に十分な時間を使わず(原題 "FAQs from Coaching Technical Leadership")この頭数のパーセンテージ（または乗数）としてのチーム成長モデルは致命的な欠陥をはらんでいます。
雇用はしばしば、プロダクトを構築・運用するときに発生する、いくつかの高ぶる緊張の解決策として提案されます。十分ではない？もっと人を雇います。バグが多い？バグ回収のために人を雇います。安定性に問題が？シニア/インフラ/SRE/バックエンドの人を雇います。技術的負債が重要な仕事を遅らせる？コアチームが負債を返しているあいだの開発をするために、新しいチームを雇います。成長の鈍化？成長のためのチームを雇います。各々が優先順序に妥協しなくて良いのが、このモデルの素晴らしい点です。欠点は、機能しないことです。
ちょっと雇用を横に置きます。これは深くリンクしていますが別のトピックです。ここに、たとえば年次（または複数年！）の採用プランを予測するよう求められたときなど、チームの大きさを考えるときに念頭におくべき 3 つの考え方があります。
効果的なソフトウェア開発は、高度な自律性と成果の所有権を持つ、小さく集中した、部門横断的なチーム（4〜12人)によって行われます。そうしたチームはゴールを持つべきです。ひとつのゴールです。彼らを分隊、スクラムチーム、ワーキンググループと呼んでください。原因と結果を混同してマイクロサービスと呼ぶことも歓迎します。2019年においてはそれががじゅうぶん広く実践されていなくとも、よく理解はされています。小さく集中したチームは、予測ができ持続的なモメンタムという文脈において、鍵となる利点を 2 つ提示します。ひとつめは、彼らが悪名高い「エンジニアの吹き溜まり」など外界からの影響を受けにくい傾向にあるということです。ふたつめは、彼らがビジネス目標を解決し、スペックに準拠するソフトウェアを提供することを好むということです。今後の投稿にワーキンググループについての詳細があります。
あなたのチームの最大のゴール、優先事項は何ですか？会社全体で明確にこの問いに答えられないということが、「動きが遅すぎる」ことの最たる理由です。エンジニアが自制心を失い、彼らが望むいかなるものにでも取り組む資格を与えられているのが、良いチームのデフォルトであるように見えます。私の経験によると、ほとんどのチームは、時間とともに、何らかの「アジャイルプロセス」の適用を経て、「バックログで自分に割り当てられたチケットを実行する」が最優先のデフォルトであるような状態に至ります。ソフトウェア開発を工業コンベアベルトにあてはめようとする、潜在的な無意識によるこの試みは、失敗する運命にあります。それには良い点もあります。それは、とても低いマネジメントスキルがあれば良いということです。凝集された大きいチームの一部としてではなく、それぞれを独立してマネージすることができるわけです。残念ながら、それはソフトウェア開発には悪い方法です。(補足: ソフトウェア開発において、「速度」は、誤りと実害のある名前です。目的地へ向かってどれだけ速く動いているかということは、車輪がどれだけ速く回っているかということとは別なのです）(補足の補足: 製造ラインでハイパフォーマンスを出すよう、エンジニアに求めるために高い支払いをしているというなら、それは払い過ぎです)
小さいチームはあなたの並列性の単位であることをひとたび理解すれば、どれくらい大きな開発組織になるべきかという問いの答えは「同時に最優先となるものをいくつまで許容したいのか」になります。
ソフトウェア開発において、調整は他の全てのコストを圧倒します。もしあなたの勢いを制限しているのが並列性であるなら、効果的な開発組織はいかに効果的にコミュニケーションと一貫性を管理するかによって特徴が出ます。
エンジニアグループ（つまり、一般には、人のグループ）を管理する難しさは、グループの大きさに基づくステップ関数を示します。8 〜 12 人のときはほとんど何でもうまくいきます。12 〜 25 人は良いツールを要します。これは 〜 40, 50 人のときに再度、そして 〜 100 人のとき、〜 150 人のときに再び（これら数値は、ダンバーが人々の文化で広く誤用されているにも関わらず、不審なほどダンバー数に近い値です）、〜 250 人, 〜 400, 500 人のときも起きます。
これら良いツールは以下を含みます。より良い管理、豊かな文化、明確な階層、技術水準、職務レベル、決定のための枠組み、CI や lint ツール、監視と可観測性、製品テストのための設備、共有されたゴールと成功の定義、従業員名簿など。
「より良い管理」を例に取って、「あなたの組織がこうしたステップ関数にあたる時々にこのツールをアップグレードする」ということがいったい何を意味するのか、より深くみてみましょう。
一般に、12 人未満の組織は、個々人の関係に基づいてよく理解された暗黙的な階層をもち、正式な役割と責任はほんの少し必要なだけです。ひとたび 12 人以上になり始めたら、管理者が必要です。それはメンバーがどう時間を過ごすかということを専門にする人です。さらに、それら管理者は、小さいグループの調整を簡単にしていた暗黙の信頼と文脈の共有が、今となっては明示的な作業を要することに気づくでしょう。
皆の名前を知っている 40 〜 50 人の組織で、彼らのすべてを安全であると前提することは、もはやできません。このサイズは指導者を必要とします。指導者は、組織内で調整がおきていることを確認することに責任を持つ、組織化の専門家です。彼らは、プロセスの配置、スピーチ、オフサイト、オンボーディング、文化強化、パフォーマンス管理、ティーチングなどを含むバリエーション豊かなツールを使って、これを達成します。いくつかの組織の指導者は学習および開発コーチ、採用担当者、人事ビジネスパートナー、プロジェクト管理者、テクニカルライター、報酬のスペシャリスト、エグゼクティブアシスタントなどを含むスペシャリストと協力することがあります。これらの人々はあなたが組織の成長にあわせて雇ったエンジニアリングの専門家に近い役割を果たします。あなたの献身的な DevOps チーム、インフラチーム、または devtools チームです。彼らは、あなたのチームの複雑性を上げるサポートをするための、組織インフラのアップレードを専門とするスペシャリストです。
大きな組織がアップグレードの必要性を内在化すると、私たちは最優先事項を同時的に設定することがいかに重要となるかという問いを理解し始めることができます。4 つの同時的な最優先事項に取り組むには、エンジニア 16 〜 40 人の間のどこかで必要です。2 〜 5 人の資格を持った技術管理者を必要とします。資格を持った技術ディレクターが必要になるかもしれません。4 〜 5 人の追加の専門スタッフも要るでしょう。60 名余りの人を見ているかも知れません。そのためには、最も簡単なレベルでプレーすることから、非常に高度なプロの精巧さでプレーすることへの飛躍が必要でした。それはソフトウェアエンジニアリングによるトレーニングマネージャへの投資が、残念ながら長らく過少であった、という現実を指摘する価値もあるのです。それは彼らを確保するために高機能エンジニアを「昇進させる」という、ありがちな失敗モードであり、私は彼らがその状況を理解することを願っています。新しい管理者が一年目に失敗をやらかす確率は 80 〜 90% です。
あなたが組織的に取り組んでいる目標の多さによって信じられないほど自制的にならざるを得ないという洞察を、進行中の作業についての Toyota/カンバン/Lean といった洞察の 1 つとして考えることができます。
ここに 2 つの一般的な悪化ケースがあります。これは複雑さが増すのにあわせて良いツールに投資しないチームで目にします。
多くのチームは、チームを全体に薄く分散させることによって、チーム全体で多量の優先事項に取り組もうとします(それはまるでバターでパンを掻き取ったかのように）。これは予想に反して、納品できないとか、納期にあわせた納品が費用便益解析にそぐわないとか、納品されたソリューションがビジネスニーズに即していないといった、プロジェクトの高い失敗率につながります。
時間とともにチームは失敗モード「後部の木が少なすぎる、多くの矢」を見極めます。そしてそれぞれのチームの取り組みを一括する傾向があります。このモデルでは、採用は主要な投資であると認識され、チームの成長に必要な組織的なツールへの投資は起こりません。このパターンは、業界で中規模以上のチームに共通の、以下のような陳腐な文句へ導きます。「その場で走るためには毎年 20% の年数を雇う必要がある」（これはコストと複雑さを招き、次の大きな組織再編やレイオフまでコントロール不能になります）
チームの規模を完璧に計算する理論は、管理下にある 3 つの確率化要因を考えることなしには完成しえません。
もっとも優秀な（一定以下のサイズの）チームは期待される離職率を持たず、それぞれの離職が驚きに値します。これはソフトウェアエンジニアのキャリアについて私たちが知っていること -- 平均的な会社の在職期間はここ何年も 18 ヶ月である -- にいくらか反します。多くのチームは離職のようなサプライズを吸収できるようにするためにシステム的にいくらかの余裕を持とうとします。私たちは時々「バス数」や「ベンチ持ち」としてこれに言及します（おかしなことに「バス数」は普段 IC のメタファーに使われ、「ベンチ持ち」は普段マネージャに使われます）。私たちは、誰かが去ったり、長期休暇を取る必要があったり、転職したり、解雇されたりした場合に、すぐに代わりを雇ったりトレーニングすることはできないということを知っており、だから私たちはそれを先取りしようとするわけです。
もっとも優秀なチームは計画を立てようとします。ほとんどは、まだそれをうまくできません。もっとも一般的な計画の失敗は、現在の計画の確実性レベルの誇張です。計画が高い信頼性とともにあるとき、計画の基礎を築くことに大いに投資することは合理的です。例えば新テクノロジー、専門家の雇用、徹底した設計とアーキテクチャの段階への投資です。高い信頼のあった計画が頻繁に変わるとき、チームは大きな先行投資を失い、将来のプロジェクトへは十分に投資しなくなります。私たちはふつうこの過不足ある投資の変動パターンをスラッシュとして経験します。それは、シニシズム(皮肉癖)はもちろんのこと、技術的債務の主な要因です。（技術的負債は存在しない(原題 "Technical Debt Doesn’t Exist")も見てください）
私たちは新しいチームメンバーがいかに早く組織の熟練メンバーになれるかということについて、ある程度制御しています。オンボーディングへの投資は、拡大する投資コストのひとつであり、それは組織の複雑性の増加とともにあらわれます。大規模なチームでコストが均等に償却されるようになります。もしあなたがオンボーディングへの投資に過少に投資するのであれば、消耗とスラッシュはより強くあなたを打つでしょうし、あなたはそれに応じた計画をせざるを得ないでしょう。半分の能力でイライラする 6 ヶ月を過ごすエンジニア達は、最初の 30 〜 60 日をスピードアップしその後 3 〜 6 ヶ月でチームの平均的な生産性を達成するよう明確に求められているエンジニアよりも、はるかに少ない実績しか出せません。またそうした苛だたしい 6 ヶ月を過ごしたエンジニアは辞めやすく、解雇されやすいです。チームの消耗について考えるとき、その人がもうチームに参加しない根本的な動機の理由モデルを仕分けることは、次回の改善のためにできることよりも重要ではありません。
これはややこしく感じられるかも知れないし、簡単に感じられるかもしれない。それは意図的にチームサイズについて考えることの複雑さをチェーンの上に移動させ、会社に、より良い計画とコミュニケーション目標、また優先順位づけについて厳粛であるよう要求します。これは大変な作業のように感じるだろうし、いくつかの組織ではそうです。しかしこれは貧相な計画、貧相なコミュニケーション、人の増加率に直面したときに経験則に頼って成功を狙うよりも一般に簡単です。さすれば来年 20% の成長の計画が可能でしょう。