当時、ハーバード ビジネス レビューは、彼が自分の仮説を証明できていないという事実に基づいて彼のオリジナル論文を却下しました。 それでも、この観察はコンウェイの法則として知られるようになり、私の同僚と私自身の経験の積み重ねが、この文言の真理を何度も補強してきたのです。 しかし、私たちの言葉を信じる必要はありません！
The Harvard Business School による研究「製品と組織アーキテクチャの間の二元性の探求」では、ソフトウェア システムに適用したコンウェイの元の仮説を証明できるかどうかを調べるために、異なるコードベースの分析が行われました。 この研究では、同じ目的を解決するために作られた複数のソフトウェア（例えば、ワープロ、財務管理、データベースソフトウェア）を例にとり、疎結合のオープンソースチームが作ったコードベースと、密結合のチームが作ったコードベースを比較しました。 その結果、同じ場所にいることが多い製品チームは、密結合でモノリシックなコードベースのソフトウェアを作成する傾向があることがわかりました。 一方、オープン ソース プロジェクトでは、よりモジュール化された、分解されたコードベースが作成されました。 たとえば、Netflix や Amazon は、複数の小さなチームを中心に構造化し、各チームがシステム全体の小さな部分に責任を持ちます。 このような独立したチームは、自分たちが作るサービスのライフサイクル全体を管理することができ、モノリシックなコードベースを持つ大規模なチームよりも高い自律性を確保することができます。 このような独立した懸念事項を持つサービスは、互いに別々に変更と進化を行うことができ、その結果、変更をより迅速に本番環境に提供することができます。 これらの組織がより大きなチーム サイズを採用していた場合、より大規模なモノリシック システムが出現し、実験、適応、そして最終的には顧客の満足度を維持するための同じ能力を得ることはできなかったことでしょう。 たとえば、分散したチームが同じモノリシックなコードベースで作業しようとするときに起こる課題を見たことがあるかもしれません。 この場合、Conway氏が言うコミュニケーション経路は、コードそのものとは対照的で、単一のコードベースではきめ細かいコミュニケーションが必要なのに、分散したチームでは粗い粒度のコミュニケーションしかできないのです。 このような緊張が生じる場合、組織の境界でモノリシックなシステムを分割する機会を探すと、多くの場合、大きな利点が得られます。
以前の Technology Radars では、マイクロサービスの人気が高まっていることを取り上げました。 Martin Fowler氏とJames Lewis氏の記事では、このテーマをより深く掘り下げ、これらのアーキテクチャによって、コンウェイの法則が確実に機能するように、システムのアーキテクチャをチームの構造に合わせる上で、組織がより柔軟に対応できるという事実を強調している。 次回のTech Radarでは、PackerやDockerなどのインフラ技術からサービス発見ツールConsul、あるいは人気のDropWizardやかなり新しいSpringBootなどのマイクロコンテナまで、マイクロサービスの影響力が高まっていることの反映について説明します。
Microservice アーキテクチャを実現するために、さらに多くのテクニックやサポート技術が登場することを期待しており、今後数か月にわたって追跡していく予定です。 さらに詳しく知りたい場合は、最新の Tech Radar にサインアップし、マイクロサービスに関する Martin と James の記事、またはオライリー社の拙著 Building Microservices をチェックしてください。