コンウェイの法則(Conway's law)についてご存知でしょうか。
システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう
といったもので、大抵はネガティブな意味合いで引用されています。
引用している本を2冊ほど紹介しつつ、実体験とその本質について話していきたいなと思います。
モノリスからマイクロサービスへ
この本では、3層構造のアーキテクチャのようなサイロ化を促しやすいという説明に用いられていました。
FEチーム、BEチーム、DBチームと組織上分かれてしまっていると、機能追加などのコンポーネントをまたぐ変更をすぐに提供できないというデメリットがあります。
柔軟さの欠けるアーキテクチャを生み出しかねないということの説明のために、割と言葉通りの意味で使われている印象でした。
エンジニアリング組織論への招待
この本では少しブレークダウンした紹介がされていて、コンウェイの法則の本質は”コミュニケーションコスト”である、と書かれていました。
コミュニケーションコストの低いところから開発が進みやすいので、結果としてシステムのアーキテクチャにも大きく影響を与える、というのがこの本での主張でした。
両者の違い
前者はシステムアーキテクチャ設計に関わる本で、後者は組織論の本であるため、結果”引き起こされる現象”がなんなのか、”どう対処”しなくてはいけないのかの説明が違いました。
ただ、引き起こされる原因については一緒で、コミュニケーションコストこそが本質なのだと思います。
”コンウェイの法則”の実体験
組織構造について
自分のチームではマイクロサービスと呼べるほどの単位ではありませんが、依存するPFは同じ部ないしはチームに集約されているのでコミュニケーションコストは小さいのかなと思います。
なので、機能追加やDB側の変更も特に苦ではなく『モノリスからマイクロサービスへ』に挙げられるような課題はクリアしていると思っています。
チームを機能単位で集約しようという試みは”逆コンウェイの法則”と呼ばれ知られている通りで、何よりも先に実践すべきことなのかもしれません。
コミュニケーションについて
では組織構造だけを変えれば解決かというと、自分としては少し疑問に感じます。
自分のチームでは昨今のコロナの状況もあり、リモートワークが主体になりました。
結果としてチームメンバー間の意思疎通が取りづらくなり、コミュニケーションせずとも進められるところを先に取り組んでしまった結果、手戻りが発生したり責務が不明瞭になってしまった経験があります。
なので、個人的には『エンジニア組織論への招待』での抽象度の高い表現がしっくりくると感じていて、単に組織構造だけを変更するのではなく、コミュニケーションを行う単位や節度にも目を向けてあげる必要があるように思いました。
まとめ
- コンウェイの法則
- システム設計の構造は組織構造に影響されやすい
- 逆コンウェイの法則
- システム設計のために組織を作る
- 法則の本質はコミュニケーションコスト
