Magnolia Tech

いつもコードのことばかり考えている人のために。

『チームトポロジー』と、『How Do Committees Invent?』を読み直して「コンウェイの法則」について考え直した

コンウェイの法則」というのがある。

Melvin Conwayが『How Do Committees Invent?』という論文にて発表した考え方を指す言葉。筆者自身による論文の紹介文に書かれている、以下のくだりが端的にその内容を表している。

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.

システムを設計する組織(ここでは情報システムだけでなく、より広い意味で定義する)は、必然的に組織のコミュニケーション構造をコピーした構造を持つ設計を生み出すことになる。

「組織をつくる人」は、それぞれの階層に於いて、その課せられた目的を達成するために自分がコントロールし易いように成果や役割を分割し、それに合わせた「組織」を作り上げていく。当たり前だけど、「組織をつくる人」の視点から見れば、それらの分割された成果は合成可能であり、その統合によって目的が達せられる。

初めてこのコンウェイの法則を聞いたとき、「それは組織をつくる人の意図通りの結果なのだから、当たり前では?」とか、「縦割りの組織に所属している人からの悲鳴?」とか、「組織を外から見ている人の皮肉?」とか色々な考えが巡った......つまり、「組織をつくる人」「組織に所属する人」「組織を外から評価する人」…誰の視点からのメッセージなのか、よく分からなかった。

一方で、「逆コンウェイ戦略」と呼ばれる考え方がある。

組織の構造がシステムの構造を規定するのであれば、作るべきシステムの構造に合わせて組織を作る考え方だ。これは…確かにその通り…というか、元から組織は目的に合わせて作られるべきだし、目的に合っていなければスクラップ&ビルドされるべき……後から見ればいくらでも言えるだけなのだけれど。

ちなみに、元の論文をよく読むと、最後にちゃんと書いてある。

Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.

それは、「デザインはコミュニケーションの必要性に応じて組織化されるべき」という、デザイン組織の構造化の基準を見出したことである。

This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

この基準では、その時々のシステムコンセプトによって通信の必要性が変わるという問題が発生します。なぜなら、その時点のシステムコンセプトによって、いつでもコミュニケーションが必要だからです。したがって、効果的な設計を行うためには、組織の柔軟性が重要である。

わざわざ「逆コンウェイ戦略」とか言わなくても、大事なことはちゃんと書かれている。逆じゃなくない?


で、じゃあその考え方をうまく取り入れて組織を作っていくにはどうしたらいいか?「コンウェイの法則」をベースにした具体的な組織構造の作り方が『チームトポロジー』に書かれている。

現代的なソフトウェアアーキテクチャの特性を背景に、チームの構成や、人数、コミュニケーション設計の方法などが解説

もちろんそのまま取り入れればいいというものでもないし、謎のカタカナ用語が多すぎて(「イネイブリングチーム」とか、「コンプリケイテッド・サブシステムチーム」とか...)、そのまま発声するにはちょっと躊躇するけど、「具体性」という意味では非常に参考になる事例が多く掲載されていて、最初に書いた疑問である「この法則は、誰が理解すべきなのか?」ということに対しては「組織をデザインする人」ということがようやく理解できた。

個人的には、「ソフトウェアの境界のサイズをチームの認知付加に合わせる」という考え方が非常に納得感が有って、ここを失敗すると組織の生産性や品質は格段に下がってしまう、と感じている。


コンウェイの法則」以外にも、色々なソフトウェアエンジニアにとって有益な考え方や、視点がざっとまとまっている『達人プログラマ』もお薦めです。一つ一つのことを深く掘り下げるより、ざっと「こういう視点がある」ということを掴むのに、お薦めの1冊です。