レイヤの多い組織は無駄に複雑なシステムを作る～Conwayの法則

Conwayの法則とは「アーキテクチャは組織構造に従う」という経験則。
よく出る例は、4チームで作ったコンパイラは4パスのコンパイラになってしまい、複雑なアーキテクチャになってしまうというもの。
レイヤとConwayの法則について考えたことをメモ。

【元ネタ】
Togetter - 「RxTstudy Redmineでのタスク管理を考える勉強会＠大阪」

Twitter / @cero_t: 「アーキテクチャは組織構造に従う」という経験則。 ソフトウェアのどの部分であれ、それを作った組織の構造を反映する。 ・・・いや、これは深いですね。なんか分かる気がする。今まで気づいてなかったけど、言われてみれば、確かにそうだ。 #RxTstudy

[#TiDD] アジャイル開発への壁 #RxTstudy: ソフトウェアさかば

Redmineプロジェクトの構造とConwayの法則: プログラマの思索

10年前にJavaでWebアプリを作っていた頃の話。
まだStrutsのような汎用フレームワークもなく、各SI独自のWebフレームワークが乱立していた。

その頃のWebアプリのアーキテクチャは、DB層(EJBないしJDBC)・ビジネスロジック層(Servlet)・画面層(JSP)の3層構造でMVC2モデルと呼ばれていた。
開発チームのメンバーは、SQLを作る人、Servletを書く人、JSPを作る人のようにレイヤごとに分別されて作業していた。
レイヤごとに分ける理由は、各層で共通のロジックを作っておき、それを参照するようにしたかったからだ。
だから、WF型開発の設計工程で詳細な部分まで設計書を作る必要があり、オブジェクト指向設計が流行していたから、その影響を受けてかなり細かいクラス図やシーケンス図まで書いていた。

しかし、実際の開発では、結合テストで、各層のインターフェイスが合わなかったり、バグが多発したりして大変だった。
Conwayの法則に従えば、3層構造の開発チームだったので、3層構造のアーキテクチャになってしまい、バグ修正のパッチを当てるたびに複雑になっていくシステムだったのだろう。

最近では、Railsの開発が特徴的なように、一人の開発者がActiveRecordからrhtmlまで一気通貫で作る。
つまり、ユーザから見た機能単位で開発者が実装していくのが最近の開発スタイルだろう。
この開発スタイルが可能なのは、Railsのような優れたWebフレームワークがユーザインターフェイスから業務ロジック、DB層までのコーディング規約(CoC)が徹底しており、言語の高い生産性のおかげで以前よりも実装も楽になったからだ。
Conwayの法則に従えば、一人で開発するのだから無駄なレイヤがなく、機能単位で作るので、一つの機能の中でアーキテクチャも閉じている。

WF型開発では、元請のリーダーとたくさんの協力会社の開発者がチームを形成して、レイヤ単位で実装していくパターンが多い。
その理由は、技術上のアーキテクチャの観点もあろうが、開発チームが混成部隊ゆえに指揮命令系統が複雑になるという特徴もあるのだろうと思う。
特に受託開発では、元請けが要件定義の工程、下請けが設計や開発、単体テストまでの工程というふうに分けて開発するために、レイヤが発生する場所で必ず設計漏れやテスト漏れが発生する。
下請構造が深い階層になっているほど、レイヤが増えるのでその分コミュニケーションロスも大きくなる。
だから、無駄に複雑なアーキテクチャになってしまい、システムを保守しにくくなる。

Agile開発なら少数精鋭部隊で一気通貫でシステムを作るから、無駄なレイヤがない。
またリーダーはファシリテーターの役割なので、メンバーの意識も高く、チームは自己組織化されているだろう。
Conwayの法則の観点で見れば、Agile開発は理にかなっているように思える。