メタ・コンウェイ思考

組織の構造がシステムの設計に反映される（コンウェイの法則）ならば、逆に組織の構造を望ましいシステムの設計に合わせて変えよう、という発想があります。逆コンウェイと言われています。いまこの話がされるなら、大抵は疎結合なシステム設計を実現するために組織の構造を変えていこうという話になると思います。システムを弱く依存し合ういくつかのモジュール（機能、コンテクスト、サービス、API）に分割し、それぞれのモジュールを担当するチームを作ろうと考えます。

僕はこの発想が嫌いです。「組織図をいじくれば人間どもが思い通りに働くだろう」というワンマン経営者の浅ましく邪悪な思いつきと支配欲を裏に感じ取ってしまうからです。これは個人的な曲解と偏見のかたまりで、逆コンウェイに対する真っ当な批判ではありませんが、建設的な側面がまったくないとも思いません。

「逆コンウェイを実現しよう」という発想が組織のどこにどう生まれるのでしょうか。あえて「逆コンウェイ」的に考えるならば、「その構造」もまたシステムの設計に影響を及ぼすでしょう。

「CTOが、そうだ！逆コンウェイだ！と思った。そこでCTOは開発チームをいくつかのチームに分割し、それぞれのチームに担当機能の開発だけを行うよう命令した。そして開発チームメンバーはそのとおり仕事するようになった」

このおとぎ話を「逆コンウェイ」的に解釈するならば、このシステムは「権力者の思いつきによって容易にシステムの設計が変化する（変化させることを試みる）システム」になるでしょう。これが悪いと断言することはできませんが、悲劇を想像するほうがはかどりそうです。（システムにおける「権力者」とは何かというと解釈の余地がありますが、「既存コード」「依存する技術パッケージ（フレームワークやライブラリ）」「声の大きい（偉い人の）ビジネス要求」「声の大きいユーザー（クレーマー）要求」などがあるかもしれません）

逆コンウェイを実践する戦略を立てるときには、組織に逆コンウェイという発想をどのような道のりで導入するか、その発想を解釈するチーム文化をいかに醸成するか、という視点もまた重要だと思います。いわばメタ・コンウェイの視点が必要だと思います。そこで先ほどの「CTO」は、みずからの思いつきをどう組織に現実的に取り入れる（または取り入れない）かを反省することになる（またはならない）でしょう。

コンウェイの法則が「〈組織のコミュニケーション構造〉がシステム設計に反映される」と述べているのは示唆的だと思います。「組織図上の組織構造」が反映されるとは言っていません。ここに先ほどの悲劇を避けるヒントがあるように思います。