コンウェイの法則と企業情報システムアーキテクチャ

コンウェイの法則とは

The organization of the software and the organization of the software team will be congruent, (中略)If you have four groups working on a compiler, you’ll get a 4-pass compiler

訳すと、

『ソフトウェアとチームの構成は一致する。4つのグループでコンパイラーを作れば4つのコンパイラーができる。』

もうちょっと意訳すると

「アーキテクチャは組織に依存する」

という話ですね。

以下の記事ではOSを例に挙げており、なるほどなぁ、と思ったり。

コンウェイの法則（Conway's Law） - Plan9日記

3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9。Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux。

ソフトウェア開発においては、

開発チームの構成に依存してアーキテクチャが決まる為

逆に

アーキテクチャに応じて開発チームを構成すべき

とも言われたりします。

コンウェイの法則と企業情報システムアーキテクチャ

よくソフトウェア構成や開発について言及されるのですが、企業情報システムアーキテクチャにおいても同様だと思っています。

というかそういう例をクソほど見てきました。

旧来の企業情報システムは組織ごとにシステム化が進んできました。

財務会計、出納、外貨管理、人事、在庫管理、生産計画、生産管理、設計、受発注などなど。

1990年台後半からERPが流行り始め、システム統合が進みました。

ERPといえば

「ベストプラクティスがー」とか「BPRがー」とか言われますが個人的にはどうでもよくて、

アーキテクチャ観点での本質は

「組織間のデータの共用化」

だと思っています。

本来的に企業の組織は相互に影響し合う振る舞いが必要で、これまでバッチでインターフェース連携していたのが、ERPになって、データの連携が自動化・リアルタイム化されて、また、領域をまたいでデータが見られるようになった。

が、最近はSaasやSoEやSoRといった考え方で、部門ごとにシステムを切り出す方向にトレンドが流れている。

多分その流れは止められないのですが、これをIT部門が弱い企業で進めると、かなりカオスになります。（というか、なっています。まじで。）

システムを分ける、というものの、一度ERPで実現したシステム間の相互連携は必要で、個別システム化にあたってのポリシーがないと、ツギハギだらけの増築を繰り返したいびつな旅館みたいなシステムが出来上がります。

利用言語、OS、MW、基盤の乱立、システム間連携のトポロジー複雑化、言われるがままに仕様追加してスパゲッティ化した仕様やコード、再利用なんてとんでもない。

企業の場合、アーキテクチャに応じて組織を設計する、というのは難しい話。

組織毎のシステム構築の流れが進む今、全体を俯瞰して計画する従来のEAを推進するような役割とアーキテクチャに対する原則やデザインルールなんかを整備できない企業は、気がついたら90年代以前の手がつけられない情報システムの状態の再来を招くことになりそうです。