組織はアーキテクチャに従う、アーキテクチャは組織に従う、どちらが正しいか？

「フレームワークを使いこなすための50問」の一節にこんな問いがある。
「組織は戦略に従う、戦略は組織に従う、どちらが正しいのだろうか？」

「フレームワークを使いこなすための50問」は経営コンサルタントのためのフレームワークに関する本なので、上記の問いは、コンサルタントが顧客へ戦略を提示時の制約条件について説明している。

その回答は「両方とも正しい。でも日本企業では戦略は組織に従うのがほとんどだ」と。
組織変革を自由に行える立場の場合、経営戦略の自由度は高い。
経営コンサルタントの好きなように、あるべき理想像に従って提示できる。

例えば、IBMが90年代に、メインフレームがWindowsパソコンなどのBPRの台頭と共に販売不振に陥った時、ハードウェアからコンサルタントやサービス事業へ転換した。
その時、40万人の従業員のうち30万人を解雇し、20万人を入れ替えた。
ハードウェア事業にいる人がいきなり経営コンサルタントになれ、と言われてもすぐになれるわけがない。
経営戦略に従って人材を入れ替えて組織を従わせる方針を取ることができるわけだ。

しかし、普通の日本企業は、今ある組織、今ある人材を前提に戦略を作らざるをえない。
終身雇用制度が古いといっても、大企業ほどその制度にしがみついている。
そして、退職推奨制度を設定すれば、優秀な人材ほどすぐに逃げていくのが今の御時世。
今なら、日本メーカーから韓国や台湾、中国のメーカーへ流れる人も多いのではないだろうか？

だから、今の組織構造を抜本的に変革できる余地がない場合、戦略は組織に従う。
すると、組織変革を伴うような経営戦略を作ってしまうと、机上の戦略のように思われてしまう、と。
したがって、採用される戦略は、組織に衝突を生まないような見栄えだけの改善策になってしまい、抜本的な組織変革に至らず、経営上の課題を解決できない場合が多いだろう。

この内容は、Conwayの法則「組織はアーキテクチャに従う、アーキテクチャは組織に従う」に適用できるか？
Conwayの法則が言う所は、ソフトウェアの構造はソフトウェアチームの構造に従うという経験則。
つまり、アーキテクチャに合わせた組織構造が良い、というもの。

「プログラムデザインのためのパターン言語」では、アーキテクチャが安定した後に組織とアーキテクチャを密接に連携させるようにした方がよい、と言っている。
つまり、方式設計完了前の要件定義やシステム提案の時期に、開発チームを結成してしまうと、アーキテクチャが不安定であるがゆえに、アーキテクチャの変更のたびに組織構造に変更をもたらし、組織が不安定になることを意味している。

だから、SIの開発案件では、外部設計までは少数精鋭チームで機能やアーキテクチャをおおまかに作り、内部設計以降、大量の人員を投入して開発チームをアーキテクチャに合わせて形成していく。
その方が、組織変更が少なくなるからだ。
つまり、プロジェクト単位に人員の流動、変動が激しい。
SIにおける大量の人員を開発・テストで一括投入し、本番リリース前に人員を減らすという変動を行う理由は、Conwayの経験則に無意識に従っているのだろう。

「アーキテクチャは組織に従う」方針でアーキテクチャを組織に合わせようとすると、無駄なコミュニケーションパスが無駄なライブラリを増やす。
特に、複数の下請け会社で請負開発させると、複数の会社間のインターフェイスで無駄なライブラリが増える。
第4回shinagawa.redmine勉強会 - Togetterでもこんなつぶやきがあった。

Twitter / boochnich:Conwayの法則、「アーキテクチャは組織に従う」はよくあります。複数会社で開発すると、会社毎に共通化ライブラリができました。 #47redmine

最近なら、地理的に離れたオフショア開発でも同様のアンチパターンが生まれているだろう。

ゆえに、SIだけでなくソフトウェア業界では、安定したアーキテクチャに組織構造を合わせるように経験上無意識に運用していると言えるだろう。
ソフトウェア業界では「アーキテクチャは組織に従う」よりも「組織はアーキテクチャに従う」方が経験上良いと言える。
但し、その宿命として、案件ごとに人員の流動が激しく、組織の改変も多い。
その変化に付いていける人だけが生き残れるのかもしれない。