コンウェイの法則と、そこで提示された2つの組織課題

ソフトウェアエンジニアリング関連の書籍を読んでいると、「コンウェイの法則（Conway's law）」によく出会う。その引用元は、1968年4月に発表されたメルヴィン・コンウェイ（Melvin E. Conway）の論文 "How do committees invent?" で、例の有名な一文は結論（conclusion）に書かれている。

（前略） organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

（広義での）システムを設計する組織は、自らのコミュニケーション構造を真似た設計を生み出すという制約を受ける。

論文の内容はこの一文に集約されるのであるが、それに付随して2つの重要な組織課題を提示している。それは、「コミュニケーションの効率化」と「生産性向上を人数規模に頼らないマネジメント哲学の構築」だ。本稿ではこの2つの課題を中心に、コンウェイの法則について深堀りする。

コンウェイの法則とは

まず、先述した2つの課題の根幹にあるのは、システムが、それを設計する組織の準同型写像（homomorphism）であるという点だ。これこそコンウェイの法則そのものだ。課題について考察する前に、この点について理解を深めておきたい。

システムは、基本的に構造化されているものだ。それは、相互に接続されたより小さな要素からなり、その要素もまた、さらに小さな要素から構成されている。ソフトウェアシステムで言えば、この要素とは、サービスやコンポーネント、モジュールであり、最終的にはクラスやメソッドといったレベルの詳細度で構成される。これらはインタフェースを介して接続されている。

そのようなシステムを設計する組織もまた、構造化されている。組織は複数のグループに分かれており、グループは更に小さなグループや、さらには複数のメンバーで構成されている。ここではグループのことをチームと呼ぼう。システムでは要素がインタフェースで接続されていたわけであるが、このチーム間、あるいはチーム内を接続するのは、コミュニケーションパスである。

コンウェイの論文では、システムと組織が持つこのような構造が一致することを指摘している。

システム構造内で互いに接続された要素xとyがあれば、組織構造内にもそれを設計した要素XとYがインタフェース仕様を合意しているはずだ。そこにはコミュニケーションパスが存在する。逆に、システム要素xとyの間に通信が無いならば、組織要素XとYの間にもコミュニケーションパスが存在しない。

ここで、組織要素がそれぞれ複数のシステム要素を設計したなら、組織構造は、システム構造を折りたたんだものになる。このような関係を、準同型写像と呼ぶ。下図は、その説明に使われた論文内のものだ。

さて、人数規模にもよるが、組織内のそれぞれのチームやメンバーが、他の全てのチームやメンバーに対して偏りなくコミュニケーションパスを持つことはまず不可能だろう。コミュニケーションパスが存在しなければ、互いが担当するシステム要素を接続することはできない（あるいは、積極的には接続しようとはしないかもしれない）。したがって、組織構造によって、採用できない設計があり得ることになる。論文内で結論（conclusion）に記載されたコンウェイの法則と呼ばれる一文に、"constrain" という単語が用いられているのは、設計において選択可能な選択肢に対するこのような「制約」が存在するからではないだろうか。

課題1：コミュニケーションの効率化

論文内の印象的な提言として、次の一文がある。

Even in a moderately small organization it becomes necessary to restrict communication in order that people can get some "work" done.

適度に小規模な組織であっても、人々が仕事をやり遂げるには、コミュニケーションを制限する必要がある。

これは、どういうことだろうか。

よく言われるように、コミュニケーションコストは、人数に対する2乗のオーダーで増加する。n人の組織では、1人あたり最大 n-1 個のコミュニケーションパスを持つことになる。自分以外の全員とパスを持つという前提だ。そうすると、組織全体のパス総数の最大は、n*(n-1)/2 となる。2で割っているのは、パスが重複するからだ。

一方で、人数に対する組織の純粋な処理能力の伸びは線形だ。グラフで描くと分かるように、人数が増えるにつれ線形に伸びる処理能力に対し、コミュニケーションコストは放物線を描く。

組織の処理能力の一部は、このコミュニケーションコストによって消費されることを忘れてはいけない。2つの線に挟まれた距離が、組織の実質的な処理能力なのだ。したがって、増員による組織の処理能力向上という目論見はどこかの時点で破綻してしまう。コミュニケーションを制限する必要性は、このようなコミュニケーションコストを抑制する目的によって生じるのだ。

これらのことから、コミュニケーション効率を踏まえた上での組織設計が重要なのは明らかだ。下記は、その点について論文内で言及された箇所の引用だ。

Research which leads to techniques permitting more efficient communication among designers will play an extremely important role in the technology of system management.

設計者間のコミュニケーションをより効率的にする技術を研究することは、システムマネジメント技術において、非常に重要な役割を果たす。

コミュニケーションが非効率であるほどコスト放物線が描くカーブは極端になる。それは、組織の人数規模に対し、コミュニケーション構造の崩壊をより早めることを示している。そして、組織のこのようなコミュニケーション構造の崩壊は、システム構造の崩壊につながるのだ。

課題2：生産性向上を人数規模に頼らないマネジメント哲学の構築

コンウェイの論文は、半世紀以上も前に発表されたものだ。前提などに古さを感じる箇所もあるが、それでも今なお引用され続けることからも分かる通り、価値ある文書だ。そこでは、マネジメントの問題についても触れられている。それは現在でも見かける問題ではないか。

その問題とは、プロジェクトにおいて、可能な限りすべての人的リソースを投入することなくスケジュールに間に合わなかった場合、マネジメント上の問題としてマネージャーが非難を受ける可能性があるというものだ。プロジェクトの人的規模を拡大することが適切な解決策ではないとしても、そのような不合理にさらされたくないと願うマネージャーは、人をより多く投入するという選択を行ってしまう。扱うシステムの規模が大きいほど、発生しやすい問題だと言える。

このような不合理が生じる背景は、まさに『人月の神話』にあるのだろう。5人で10か月かけて完成させる仕事を、20人で2.5か月に圧縮して完成させようと考えてしまう罠だ。コストという観点では、どちらもともに50人月だ。しかし、人と月とは交換可能ではない。設計における個々のタスクは独立しておらず、多くのタスクが互いに従属関係を持つ。それらがスケジュール上にクリティカルパスを形成する。クリティカルパスは、人を増やしても短くならない。単純に人数を増やしたところで仕事が早く終わるわけではないのだ。

そして、この設計労力に対する人的リソースの過大配分には、「パーキンソンの法則（Parkinson’s law）」も関係している。利用可能な人的リソースを使い切るまでプロジェクトの人数規模は膨張する傾向があるのだ。プロジェクトに投入可能な人員を多く抱えるマネージャーほど、この罠に陥りやすい。

そもそも、労働力として同じ50人月の価値の組織であっても、そこから生み出されるシステムの価値は同一とはならない。コミュニケーション構造が違えば、生み出されるシステム構造は準同型写像によって違いが生じるからだ。そして、無理に人手を増やしすぎた結果は、課題1で述べた通りだ。

このような問題に対し、論文では組織のスリム化と柔軟性の重要性を説いた上で、次のように述べている。

There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity.

「人手を増やせば単純に生産性が上がる」という思い込みに基づかないシステム設計マネジメントの哲学が必要だ。

適切なシステム構造は価値である

コンウェイの法則が、これほどまでに様々な書籍やドキュメントで引用される背景には、システムの構造というものに関心を持つ人や組織が多いからではないだろうか。システムを扱う組織にとって、適切なシステム構造は価値あるものなのだ。フィリップ・クルーシュテン（Philippe Kruchten）は、それを「見えない（invisible）が、ポジティブな価値（positive value）があるもの」と呼んだ。そしてその逆となるものを「技術的負債（technical debt）」として仕分けした。

技術的負債となるシステム構造の崩壊は、変更容易性を悪化し、ソフトウェアに対して顧客に要求される変更を実現困難にする。つまり、左象限の「見える価値（visible value）」を受け付けなくなる。そうなったソフトウェアは、もはや "ソフト" ではない。変更できないソフトウェアは、ソフトウェアとしての価値、存在意義が失われてしまっている。

システム構造は、組織のコミュニケーション構造に強い影響を受ける。忘れてはならないのは、ソフトウェアプロダクト開発組織におけるコミュニケーションパスの有無やそのパスの太さは、それぞれが担当するコンポーネントの依存関係に強く影響されるということだ。つまり、アーキテクチャを想定せずに設計された組織のコミュニケーション構造は、不適切で非効率なものとなる。そうであるならば、効率的なコミュニケーション構造の追求のために、組織設計者にはアーキテクトとしての素養が不可欠だと言えるのではないだろうか。