はじめてのコムウェイの法則と逆コムウェイの法則
だいぶ前になってしまいましたが、9月30日にFindyさんが開催してくださった『【エムスリー×MonotaRO】急成長メガベンチャーのエンジニア組織づくり最前線』というイベントに参加していました。
その中でふと話にでてきたのが『コムウェイの法則』でした。今回のイベントでは特に主題ではなかったので「コムウェイの法則を知らない人はググってください」と、いった形で終わってしまったのですが、個人的には気になったので調べてみました。
## コムウェイの法則とは
コムウェイの法則とは、1968年にメルヴィン・コンウェイという人が『Datamation』という雑誌に発表した論文で紹介された経験則の法則です。その内容は以下の通りです。
「システム（ここでは単なる情報システムよりも広く定義されたシステム）を設計する組織は、必ずその組織のコミュニケーション構造を倣った構造を持つ設計を生み出す」 (原文: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.")
論文の原文はこちらにあります。
具体的な例を用いた言い方をすると「密結合組織の場合は、システムも自然に密結合に（モジュール性が低く）なる」という感じです。図にすると下記のようなものになると思われます。
なぜこのようなことが起こるのかというと、密結合された大きい組織でシステムを開発すると、誰が何の機能を開発しているのかがわかりにくく、多くの人たちに役割が割り振られます。そうするとたくさんの機能に触れることになるので、マイクロサービス化する意識が生まれず、モジュール性の低いシステムができあがるそうです。
反対に疎結合組織の場合（ちなみに、疎結合とは細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことです）は、小さなチームが独立して、それぞれのチームが担当するサービスを開発していきます。こうすることによって意思決定が早く勧められるうえ、モジュール性の高いシステムを作ることができるようです。
## コムウェイの法則の何が重要なのか？
上記のように組織のコミュニケーション構造が、システムのアーキテクチャーにまで影響するというのがコムウェイの法則です。しかし、この法則の何が重要なのでしょうか？
現在のソフトウェア業界ではサービスのリリース速度は他社との差別化をはかるうえでとても大切です。しかし、密結合の大きい組織で巨大なモノリシックなコードを相手にしていると、依存関係のエラーが起こってしまったり、活躍できない人材がでてきてしまったりするなどでリリース速度が落ちてしまいます。
疎結合の組織でモジュール性が高いシステムの場合、チームが開発のライフサイクルを管理し、スコープの調整やデブロイ速度の向上などができるので、結果的にリリース速度を早めることが可能となります。
この疎結合組織として有名なのがAmazonです。Amazonでは『ピザ2枚ルール』というルールがあり、これはピザ2枚で足りないような人数のチームを作らないというルールです。
このようにシステム改善を行うのにアーキテクチャーばかりを見るだけでなく、組織の状況をよく調べることが重要という理解につながることがコンウェイの法則の重要な点のようです。組織は大きくなるほど、システムの柔軟性が低下し、リリース速度が遅くなるので、コンウェイの法則を意識することが重要になるとのことです。
コンウェイの法則の付き合い方として、Youtube動画で良いまとめがありましたので、こちらに引用いたします。
- コードがすべてではない（It’s not all about the code!）
- 小さなチームは大きなことができる（Small teams can do big things.）
- フルスタックのチームはアーキテクチャーの柔軟性をキープする（Full Stack teams keeps your architecture flexible.）
- コムウェイの法則と戦わず、一緒に働く意識を持つ（Don’t fight Conway’s Law, work with it.）
## 逆コンウェイの法則
上記のようなことから、アーキテクチャーをマイクロサービス化し、システムを改善していくには、組織を疎結合組織にし、まずは組織を変えていくことが勧められています。近年では「アーキテクチャーが組織を変えることができるのではないか」という、別の見方もでてきました。まずアーキテクチャーを改善し、その後、プロダクトにそって組織を改善することを逆コンウェイの法則と言うそうです。
図にすると、矢印を逆にするだけなので、こんな感じですね。
少し調べただけなので、間違った認識のところもあるかと思いますが、参考にしたのは下記の書籍です。今度第2版がでるそうですね。
参考：
マイクロサービスアーキテクチャ
参考にした動画
「コンウェイの法則を忘れないでください」 - サラ・ノボトニー基調講演
