だから、逆流させるんだ。

前回の記事で言ったように、ソフトウェア開発って言うのは問題発見とその解決で、
組織戦略と同等レベルの知的作業なんだ。
そして、ソフトウェア会社というのは、この２つが密接に絡み合う。

ソフトウェアアーキテクチャはそのまま組織戦略だといっても過言じゃない。
それだけソフトウェアアーキテクチャは重要なものなんだ。

だから、アーキテクトは必要充分な情報を得る必要がある。
そして、各ステークホルダーに対しての問題を再定義して解決する必要がある。
わかってる。多くの場合、それはうまくいかない。

アジャイル開発プロセスほどに新進気鋭な（といってももう十分な歴史があるが）界隈ですら、
恐れて言わないようなことだ。

何もかも管理したいか、
何も管理しないかのいずれかしか手段を知らないような一般のマネージメント層やスーツの連中に
それが理解できる訳が無いんだ。

そういったわけで、アーキテクチャもシステムも新しい物好きの宇宙飛行士によってぐちゃぐちゃにされたり、
人間嫌いの破滅主義者によって未定義エラーを吐き続けることになるんだ。
そして、その理由をマネージメントにおっかぶせて、安い酒の肴にするんだ。

そんなわけで、システムを知らないマネージメントと要求と対話しないアーキテクトによって、
とても信頼のできる法則が生まれることとなった。

それは「コンウェイの法則」だ。

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

問題意識を一度でも持った人にはあまりにも有名で、最低限度の教養なんだが、
問題意識を持ったことが無い（得てして最も知っていなければならない）人には全くの無名なこの法則は、
半世紀近くたった今でも有効でむしろ、世界中で実験的に実証され続けている。

じゃあ、何もかも捨てて逃げ出すのか。
そうじゃない。この法則は信頼できる。だからこそ使える手段があるんだ。

この法則を逆流させるんだ。
つまり、

「アーキテクチャ設計が、組織構造を再設計する」

ということだ。
そんな馬鹿なことがあるか。と読んでいる人は言うかもしれない。
でも、馬鹿げているのは組織構成がアーキテクチャに反映されるということも同様で、
それだけこの２つが相互作用を起こすという事実が捉えがたいことだということだ。

これのざっくりとした機序を説明するなら、（屁理屈なのはお互い様だ）
アーキテクチャは、ソフトウェアプロダクトの拡張に対してコストコントロールをするものだ。
組織構造は、コストに強く反応する。２０のアウトプットを得るのに１００の資源が必要なものは採用されないが、
１０の資源で済むものであれば鈍重ながらもそれを採用するインセンティブが働くからだ。

これは要するにクーデターだ。「射撃しつつ前進」なんて甘っちょろいものじゃない。
気づかないうちに、コンウェイの法則を逆流させて、ソフトウェアアーキテクチャが、組織構造・思考をも支配し始めるんだ。
わくわくしない？

このクーデターがうまくいく条件は、しつこいけどソフトウェアによる「問題の再定義と解決」だ。
だから、望んでいるものが全く違っていれば話にならない。
問題が解決された暁には、もしかしたら、マネージメントもその魔法に驚いて何が起きたのかということを不思議がるかもしれない。
そのとき、ようやく組織とソフトウェアの関係に気がつくかもしれない。

で、次に君はこう言う。

「ご高説はわかった。
だけど、今のアーキテクトには、組織の問題もソフトウェアの展望もリードできるような能力は無いし、
そもそも誰も問題の所在なんてわかってないんだ。」

なるほど、そうなると選択肢は決まってくる。
自分がアーキテクトになるか、
アーキテクトになれる誰かに問題を理解するための情報を集める人になるか、
その誰かが生まれてくるように仕掛けをつくるか。

あるとしても、この３つくらいだよね。
おっともう一つあった。
この全部をやることだ。