コンウェイの法則で思ったこと

コンウェイの法則って知っていますか?

以下のような法則です。

システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう

だそうです。
この法則について書かれた本を読んだわけではないので、詳しくは知りませんが、メルヴィン・コンウェイという方が言われた法則らしいので、コンウェイの法則なんですね。

メルヴィン・コンウェイ - Wikipedia

このコンウェイの法則、最初に何かで読んだときはそんなことないやろと思っていました。
システムの設計なんて、その時々で変わるはずだと思っていたからです。
当てはまらないなと思いつつも、そういう考え方もあるんだなと印象に残りました。
どこで読んだかは覚えていないですけどね!

先日、「エンジニアリング組織論への招待」を読んでいるとまたコンウェイの法則が出てきました。
技術組織の生産性を語る中での登場です。
ここであげられていたコンウェイの法則の例は以下のようなものでした。

ある機能開発をするために3つの別のチームとの協議と4つの稟議書に印鑑が必要となる。
その結果、そういったコミュニケーションを回避しても実装できるような機能を重点的に開発した方が効率が良いと判断するようになる。

この例には納得です。
ありそうなものです。
システムを改良するときに、改良の方法としてA案とB案があったとしてA案の方が変更点も少ないし今後のメンテナンス性も良いんだけど、B案の方が(組織構造的に)段違いに早く実装できるとなればユーザーに提供するスピードやその他のタスクなども考慮してB案を選んでしまいそうです。
その繰り返しでシステムが出来上がっちゃう。
この例が組織構造か?と言われると疑問なところも感じますが、本の中で話されていたコミュニケーションの構造=組織構造と考えれば、法則に当てはまるなと思います。法則の原文にも the communication structures of these organizationsってあるんですね。

そして、今週、あるタイミングでまたまたコンウェイの法則が頭に浮かびました。
目指すべきシステムを作るために何かしらの仕組みを作るのも良いのですが、法則とは逆説的に、意図したチーム体系を作るのもありなのかなと。
例えばバグが少ない安定したシステムを作るために常に複数人で作業するようにするとか。
ここでも出てきたか、コンウェイの法則みたいな感じです。

今振り返れば、私が最初にコンウェイの法則を知ったときは、比較的に自由にやらせてもらえる組織構造だったんですね。
だからシステムの設計=自分の思想であって、組織の構造が反映されるなんて結びつかなかったのかなと思いました。
システムはどんなチームがつくっても一緒だと思っていましたが、実際は色濃く反映されるんですね。

こんななんでもない話で3月のブログは終わりとしたいと思います。

以上。

これもどうでもよいですが、ある言葉を知ってから、その単語が目に飛び込んでくるようになったとかありますよね。
いやー最近流行っているなぁとか思うのですが、実は前からバンバン使われていたけれど自分の意識に入ってこなかっただけだったという。
今回のコンウェイの法則がそうですし、他では、最近は「泰斗」って言葉がそうでした。