この記事は、アトラシアン社によって2020年2月に公開された『 3 research-backed principles that help you scale your engineering org 』の翻訳転載です。著者の許可を得て配信しています。
チームやビジネスの成長、変革、チーム設計のヒントは、社会科学の法則とプロジェクト管理にある。
エンジニアリングチームが成長するにつれて、チームには明らかに困難が生じるものです。それは簡単な算数の理論と一緒で、かつてチームが小さかった頃のように、すべての人に歩調を合わせることが難しくなります。今後も高レベルの影響を維持していくには、働き方を変える必要があります。
幸いなことに、社会科学とプロジェクト管理から生まれたいくつかの原則と法則、つまりコンウェイの法則、ダンバー数、ブルックスの法則などは、チームの成長を促しそれを理解することに役立ちます。チームダイナミクスとシステム設計の原則によって、明らかにされた事実をもって、より良い結果とチームの満足度の向上が見込めることもあるのです。
これらの法則は、いずれの分野にも適用できるものですが、エンジニアリングチームへの影響力はとても大きいです。これらの法則を活用すれば、規模、変革、最適な組織をデザインすることができるようになります。
原則#1 : ダンバー数
1990年代に初めて提案された人類学者ロビン・ダンバーの研究によると、人間の新皮質（言い換えれば脳の最も進化した部分）が対応できる社会的集団の規模は最大で約150名までであるとされています。小さなチームでは、それぞれのお気に入りのランチや、自由時間の過ごし方など全員について理解しあえているかもしれません。しかし、チーム規模が大きくなるにつれて、彼らについて知っているのはファーストネームだけ、または所属部署だけだったりするかもしれません。大企業では、自分の所属組織内の人物さえ認識することができない場合もあるかもしれません！
ダンバー数
ダンバーの調査結果は、多くの研究と社会実験によって裏付けられています。エンジニアリング組織の設計に適用する場合、ツール、プロセス、組織構造など、いずれも組織の拡大と共にベロシティに影響する事項に関する意思決定に役立ちます。たとえば、特定の製品などテクノロジー別に水平方向に、またはモバイル、ウェブ、インフラストラクチャなどの機能別に垂直方向に特化することを決定する際に、ダンバー数を適用すると効果が出る場合があります。または、効果的な地域拡大に関する決定や、所属部署の管轄範囲における責任意識を維持する方法の決定にも適用することもできます。
150人という値については頻繁に議論される数値ですが、組織は規模が拡大するにつれて、この数を下回っていても問題は生じます。共同作業に最適と見なされるのは、チーム規模が10人以下の場合です。しかしながら、チーム規模が35人以上に成長すると、その最適化には、システムレベルのインターフェイスとロードマップ （これにはJira のようなツールが含まれます）によって、目標とタイムラインを調整する必要があります。
150人以上の場合、システムは完全に独立する必要があります。この規模になると知っていること、可視性、およびコミュニケーションが失われ始め、お互いの名前や役割を知らない、組織全体でどのような作業が行われているのかが把握できない、そしてスケジュールの調整や方針の共有が難しい状況に陥ります。
アトラシアンがConfluence Cloudのチームをある場所から別の場所に移動させた際、課題解決のためにダンバー数を適用してチームの規模を調整しました。まず、新たにできるチームが、緊密で、信頼感があり、かつ効率的なプロセスを築くために規模を縮小しました。そしてチームがより多くの仲間とコラボレーションするためのシステムとツールが整っていることを確認してから、再びチームの規模を拡大しました。これらの変更を通して、初期のチームの立ち上げについて、また時間が経つにつれてチームの結束を維持するために必要なこと、そして水平または垂直の連携に関する重要な教訓を学びました。
以下にダンバー数の影響を軽減するためのヒントをいくつか紹介します。
- 可能な場合はチームの規模を小さくしてください。たとえば、チーム構築の初期段階では、同一拠点にて、同一マネジャーの下に配置する開発者数は3〜5人から始めると、開発者の間で親密な関係を築くことができます。
- 毎月チーム間でデモを実施して、知識を共有します。
- チームの成長に合わせて、チーム外の人との関係を築く時間を作ります。
- カジュアルなコーヒーブレークミーティングから全員参加のミーティングまで、チームの一員が仕事以外でも同僚とつながっていると感じることが重要です。
原則#2 : コンウェイの法則
1967年に初めて提案されたコンウェイの法則によれば「システムを設計する組織は、そのコミュニケーション構造に似通った構造設計を生み出す」とされています。実際にこれは「組織図を出荷する」ようなものですが、ユーザーを満足させるものを生み出すのは難しいことと言えます。コンウェイの法則は、インパクトのある結果を得るべく利用するか、または予測が可能な故に無視することもできます。
組織を設計する場合、システムアーキテクチャは選択したモデルを反映しています。たとえば、システムの一部分を構築する2つのサブチームがある場合、そのシステムには2つの要素があります。これは、ソフトウェア開発の全ての段階で繰り返し起こることです。組織のモデルを作成する際に、戦略モデル⇒ 組織 ⇒ 人を適用することで、コンウェイの法則を有利に活用できます。これにより、重複作業を減らし、より少ない調整コストで、よりシンプルなソフトウェア提供することができるのです。
最近では「逆コンウェイの法則」（理想のソフトウェアアーキテクチャに合うようなビジネス組織を設計する手法）という、コンウェイの法則を教訓とするのではなく、ツールとして活用すべく進化した戦術があります。たとえば、重複システムが構築されているシナリオでは、2 つのシステムの所有権を 1 つのチームや組織に統合することが可能になり、重複システム自体が急速に減少します。
アトラシアンでの移行期間中、私たちは新しいチームをつくる機会があり、Squad（分隊）とTribe（部族）のモデルを試しましたが、うまくいきませんでした。このような複雑なシステムには、あまりにもランダム化し過ぎていたのです。ここから判明したのは、毎月または四半期ごとに、分隊と部族のどの部分に移動しても、効果的に必要な知識を増やすのは難しいということです。
コンウェイの法則の影響を軽減するためのヒントをいくつか紹介します。
- 2つのチームが同様のシステムを構築している場合は、逆コンウェイ戦術を適用して、重複するシステムの所有権を持つ単一のチームになるようにします。
- 類似システムが構築されていることを知るのは困難です。サンプル信号は、2つのシステムのどちらが優れているのか、どちらを使った方がよいのかといった、システムユーザーの意見や技術論争によって生じる混乱です。
- 同じチームが重複システムを所有することによって、１つのシステムにまとまります。
原則#3 : ブルックスの法則
ブルックスの法則は、著名な書籍である「人月の神話」に由来します。その書籍の中で著者は「遅れているソフトウェアプロジェクトへの要員追加は、そのプロジェクトをさらに遅らせるだけである」と述べています。
これは、プロジェクトの進捗が遅れ気味で、チームが遅れへの対策を講じる中で、エンジニアリングリーダーが常に思い起こし、よく口にする言葉です。この矛盾は、あらゆる規模のエンジニアリングチームとあらゆる期間のプロジェクトで実証されています。
「ホフスタッターの法則を考慮しても、常に予想以上の時間はかかるものである」というホフスタッターの法則は「人月の神話」と併せて頻繁に引用される言葉です。予想以上に時間がかかることに加え、既に失敗しつつあるプロジェクトに要員を追加することでプロジェクトの進行をより遅らせることは、さらなる遅延が許されない時期にあるプロジェクトに悪影響を及ぼす可能性もあります。
「人月の神話」の教訓を適用することは、プロジェクトチームが多大なストレス下にある時に、予測しながらプロジェクトの範囲を決めることに役立ちます。エンジニアリングマネージャーは、時には状況を悪化させる人員の追加によるポジティブなスケジュールへの影響に過度にコミットせずに、さらなる処理能力を追加することが可能になります。人員の追加が正しい判断の場合もありますが、その判断は「人月の神話」の洞察をよく把握した上での判断であるべきです。
アトラシアンは、頻繁にこういった状況に直面しています。大規模で長期にわたるプロジェクトで、予定を切り詰める必要がある場合は、コードベースに実践的な経験を持つ人を配置します。あまり痛みを伴わないオプションも多々ありますが、私たちは妥協を受け入れます。そして場合によっては、複数のチーム間で人員をシャッフルすることで二次的効果を見出すことがあります。時には、スケジュールの遅れを取り戻すことが難しいことを受け入れて期限を変更します。
以下、「人月の神話」による影響を軽減するためのヒントを紹介しています。
- 既存のプロジェクトに要員を追加する、新人の強化期間、既存のチームのトレーニング時間の組み込みといった真の損益分岐点を見つけます。その損益分岐点は、あなたが思っているよりも遠いところにあります。
- この法則のタイトルには「神話」とありますが、私たちは常に生身の人間と接しています。チームメンバーのいずれかを別のプロジェクトに異動することは、そのマネージャーと相談することが、潜在的な利点とリスクを理解する鍵となります。