チームが大きくなるにつれて開発スピードが遅くなる理由

会社の規模が大きくなるにつれて、CEOやエンジニアリングリーダーが経験する特有の苛立ちがあります。10人の時、チームは迅速でした。アイデアは数日以内に機能となりました。意思決定は会話の中で行われました。誰もが何が起きているのか、そしてなぜ起きているのかを把握していました。会社はまるで、すぐに方向転換できる小さなボートのようでした。

40人になると、同じ会社がまるで糖蜜の中を進んでいるかのように感じられます。すべての決定に会議が必要で、すべての会議に事前会議が必要であり、すべての機能には1年前なら開発が終わっていたであろう時間よりも長い計画フェーズが必要になります。優秀な人材を採用し、優れたツールを提供したにもかかわらず、なぜか一人当たりの生産性は向上するどころか低下してしまいます。

自然な解釈としては、採用ミスをした、チームのカルチャーに問題がある、あるいは新入社員が初期のメンバーほど優秀ではない、といったことが考えられます。これらの解釈はたいてい間違っています。本当の原因は数学的なものであり、1975年にフレッド・ブルックスによって説明されています。

コミュニケーションパスの爆発

チーム内における1対1のコミュニケーションパスの数は、n(n-1)/2 の数式で増加します。10人の場合は45パス。20人の場合は190パス。40人の場合は780パス。100人の場合は4,950パスになります。

情報を必要とするすべての人に届くためにこれらのパスを通過しなければならない知識は、ネットワークが大きすぎて個人間の伝達ではその情報量を処理しきれないため、単純に行き渡らなくなります。その結果、ギャップが生じます。各チームは、他のチームが何をしているのか分からなくなります。組織の一部で行われた決定が、その影響を受ける他の部分に届かなくなります。かつては物理的な距離の近さによって共有されていたコンテキストを配信するには、明確な努力が必要になります。

これらのギャップに対するチームの反応は、通常、さらなる調整です。会議の増加、Slackチャンネルの増加、ステータス更新の増加、アライメントセッションの増加などです。これらはそれぞれ局所的には役立ちますが（会議の出席者は足並みが揃う）、グローバルな問題を悪化させます（会議によって開発に費やせたはずの時間が消費され、調整内容は出席者しか得られません）。

これが、チームが成長するにつれて会議が増殖する理由です。それらは機能しなくなった知識分配システムを補っているのです。そして、人員を増やすことが、多くの場合、迅速化ではなくかえって遅延を招く理由でもあります。新しいメンバーが加わるたびに、すでに過負荷状態にあるネットワークにさらに多くのコミュニケーションパスが追加されるからです。

3つの予兆

このスピード低下は、3つの具体的な方法で現れ、それぞれがしばしば誤診されます。

意思決定に永遠に時間がかかる。 優柔不断に見えるものの正体は、通常、コンテキストの不足です。意思決定者は必要な情報を持っていないため、情報を集めるために会議を招集しますが、それには複数のカレンダーのスケジュール調整が必要になり、数日かかります。コンテキストが文書化されていれば5分で下せたはずの決定に、人々の頭の中からコンテキストを再構築しなければならないため、2週間もかかってしまいます。解決策は、より素早い会議ではなく、文書化された意思決定履歴とすぐに利用できるシステムコンテキストです。

作業が重複する。 調整不足に見えるものの正体は、通常、目に見えない既存の作業です。チームAは、チームBがすでに作成したものを構築し始めます。なぜなら、チームAはチームBの作業が存在することを知らなかったからです。これは、知識が分散し、連携していないツールの間に散らばっているために起こります。解決策は、チーム間の同期を増やすことではなく、チーム間で検索可能な統一された知識です。

オンボーディングが苦痛なほど遅い。 採用の質の不足に見えるものの正体は、通常、ドキュメントの問題です。新入社員が立ち上がるまでに何ヶ月もかかるのは、読むべき包括的な資料がないため、会話を通じて組織のコンテキストを再構築しなければならないからです。解決策は、バディ制度を増やすことではなく、新入社員が自力で吸収できるドキュメントです。

構造的な解決策

3つの予兆すべてに共通するパターンは同じです。文書化され検索可能であるべき知識が、代わりに人々の頭の中やSlackのスレッドに閉じ込められているため、チームはオンデマンドで利用可能であるべきコンテキストを伝達するために、同期型コミュニケーション（会議、ダイレクトメッセージ、肩たたき）を使用せざるを得なくなっているのです。

構造的な解決策は、組織のコンテキストを自動的に取得して維持する知識レイヤーを構築し、知識を保有している人がその場にいなくても、誰でも検索できるようにすることです。

チームの既存のアクティビティ、Slackの会話、GitHubのPR、会議の録画から構築される自己執筆型ドキュメントは、誰も追加の作業を行うことなく、このレイヤーを作成します。現在、一時的なチャンネルを通じて共有されている知識は維持され、検索可能になり、他の誰かを邪魔することなく、必要なときにいつでも誰でも利用できるようになります。

スピード低下が深刻になる前にこの投資を行うチームは、個人間の知識伝達に依存しているチームが到底できない方法で、成長を通じて開発速度を維持します。知識のスケーリング問題は現実的かつ数学的な問題ですが、解決可能であり、その解決策はカルチャーではなくインフラストラクチャです。

よくある質問

これは単なるドキュメントの問題ですか？ これは知識インフラストラクチャの問題であり、ドキュメントはその中で最も目に見える構成要素です。それには、検索性（存在するものを検索できるか？）、最新性（ドキュメントは最新か？）、発見しやすさ（ドキュメントが存在することを人々が知っているか？）も含まれます。自己執筆型ドキュメントは、日々の業務を通じてすでに共有されている知識を生成、維持、検索可能にするため、これら4つすべてに対処します。

以前ドキュメント化の取り組みを行いましたが、定着しませんでした。 ほとんどのドキュメント化の取り組みが失敗するのは、既存の業務の上にさらなる作業を追加してしまうからです。エンジニアはコードをリリースするだけでなくドキュメントを書くよう指示されますが、締め切りのプレッシャーの下で追加の作業の優先順位は下げられてしまいます。定着するアプローチとは、ドキュメントを別の活動として作成するのではなく、業務そのものから生成するものです。

どの時点で懸念すべきでしょうか？ チームが15人を超え、3つの予兆（遅い意思決定、重複する作業、苦痛なオンボーディング）のいずれかに気づき始めた場合、コミュニケーションアーキテクチャはすでに悲鳴を上げています。投資は今行うのが最も安価であり、症状が深刻になってから行うのが最も高価になります。

関連リーディング：知識のスケーリング問題、エンジニアリングチームをスケールさせる方法、ブルックスの法則は今でも正しい、調整コスト。関連ページ：自己執筆型ドキュメント、あらゆるものを見つける、一括検索。