開発組織で重要なコンウェイの法則と、もう一つの原則

原則を数個決めたら他のことはすべてそれらから導出されるような考え方が好きです。

開発組織の設計あたってはコンウェイの法則というのがよく参照されます。

コンウェイの法則：システム設計は、組織構造を反映したものになる

コンパイラーを3チームで開発すると必ず３パスのコンパイラーになる、みたいな例を読んだことがあります。

これが起こる理由は、チーム内でのコミュニケーションコストがチーム間のコミュニケーションコストよりも格段に低いためです。同じチームで開発するシステム内はコミュニケーションコストが低いため密結合になり、チーム間のシステム結合はコミュニケーションコストが高いため疎になっていきます。

これを逆手に取って、最終的に実現したいシステムの形に合わせて組織を分けるのが逆コンウェイの法則です。

大きな単位のシステム設計は、３年、５年、あるいはそれ以上の長期間に渡って影響を及ぼします。ここを間違うと、いわゆる技術的負債になる可能性が高いです。

できる限り長期に渡って変わらない会社の方針を見極め、システム境界を考え、最終的には覚悟を持って組織に落とし込む必要があります。これがうまくいったらCTO冥利に尽きますね。

もう一つの原則

長期に渡って変わらないからといって、フロントエンドチーム、バックエンドチーム、QAチーム、などに組織を分けるのは問題が多いです。

なぜなら、アジリティ（仮説検証のスピード）を損なうためです。

原則：会社が最も仮説検証サイクルを早めたいチームを組織ツリーの末端に作る

組織ツリーの末端どうしが互いにコミュニケーションを取らなければならない状況は、コミュニケーションパスの爆発を生みます。チーム間のコミュニケーションが多ければ多いほど仮説検証のスピードは落ちます。

これを防ぐには、仮説を立てて実装して検証するまでを担えるチームを最小単位として横にたくさん作るのが是となります。

２つの原則のコンフリクト

10人のスタートアップであれば、デザイナーもフロントエンドエンジニアもバックエンドエンジニアもプロダクトマネージャーも全員同じチームです。

この状態が一番アジャイルなのは間違い無いので、組織が大きくなってもごちゃ混ぜのままいきたくなるところですが…気がつくと100人以上のエンジニアとデザイナーとプロダクトマネージャーの混在チームが同じシステムに携わることになり、コミュニケーションパスが爆発します。

２つの原則を同時に満たして組織を大きくするのは無理なのではないかと思ってしまいますが、そこが頭の使い所です。

その話はまた別の機会に書きます。