「アーキテクチャは組織構造に従う」という経験則には2つの意味がある

「アーキテクチャは組織構造に従う」という経験則には2つの意味があるのではないか、というアイデアについてラフなメモ書き。

【元ネタ】
akipiiさんはTwitterを使っています: "これに今悩んでる。RT @sys_architect1: アーキテクチャは、ステークスホルダーのニーズを満たすためだけに作成される。また、優れたアーキテクチャとは、ステークスホルダーの目的や目標及びニーズと見事に一致しているもののことである。p.21"

akipiiさんはTwitterを使っています: "「アーキテクチャは組織構造に従う」という経験則には2つの意味があると思う。1つは、サイロ型組織の構造はそのままソフトウェアに反映されて複雑な仕組みになってしまうこと。例えば、4つのチームでコンパイラを作ると無駄な4パスコンパイラになる。1パスコンパイラでいいのに。"

akipiiさんはTwitterを使っています: "もう一つの意味は、アーキテクチャとは、多数の利害関係者の思惑や要望という政治的利害によって決まる場合があること。経営企画部、営業部、製造部、ベンダー、運用部隊などの思惑を全て満たすアーキテクチャを決めようとすると、本来は単純な構造で良いはずなのに、複雑な構造になってしまう時がある"

akipiiさんはTwitterを使っています: "エンタープライズ界のアーキテクチャは、プログラマが考えている「ソフトウェアのあるべき姿」で決定されるのは稀。むしろ、アーキテクチャはステークホルダーの政治的利害によって決まる。だから「ソフトウェアは政治的利害を持つ組織群の構造に従う」。"

akipiiさんはTwitterを使っています: "アーキテクチャは、エンタープライズ界よりもオープンソース界の方が、プログラマが考えるあるべき姿で決めやすい。受託開発ならコスト・納期の制約でアーキテクチャやテストは制約を受けるので、無限のコストをかけて理想のシステムまで開発できない。でもOSSなら自分の気が済むまで開発できる。"

akiyama924さんはTwitterを使っています: "“@akipii: 「アーキテクチャは組織構造に従う」という経験則には2つの意味があると思う。・・・” 私の周りでは逆、すなわち、「組織構造は、開発対象商品のアーキテクチャの変化に依存して作りかえられる」でしたが、組織構造を変えるのが好きな会社だったからなのだろうか。"

akipiiさんはTwitterを使っています: "@akiyama924 製品に合わせた組織構造にする会社はトップダウンの会社でしょうね。マーケットの動きに敏感でビジネスライクな部分はいいでしょうが、慣れ親しんだ部署から突然、人事異動を受けて単身赴任させられたり、子会社に出向されたり、リストラされるのは嫌ですね笑"

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "そうか、生産性や保守性といった作り手の論理で考えると中央集権的な標準フレームワークが重要になるけど、サービスの論理では個別ドメインの課題に沿ったフレームワークが求められて分権化されたマイクロサービスが求められる、という説明が分かりやすいな。"

akipiiさんはTwitterを使っています: "この議論に注目。RT @haradakiro: @yusuke_arclamp ステートを持っている場所の移り変わりという話をすると面白いかも、と思っています。場所とちらばり具合の変化。"

鈴木雄介/Yusuke SUZUKIさんはTwitterを使っています: "アーキテクチャ設計ってのは四角と線を引く仕事じゃない。可能な限り情報を仕入れ、予測から判断し、関係者を調整し説得する。この泥臭さこそがアーキテクトの醍醐味なんだよ。"

【1】「アーキテクチャは組織構造に従う」という経験則には2つの意味がある。
1つは、サイロ型組織の構造はそのままソフトウェアに反映されて複雑な仕組みになってしまうこと。

例えば、4つのチームでコンパイラを作ると無駄な4パスコンパイラになる。
本来のあるべきアーキテクチャは、1パスコンパイラでいいのに、開発組織の無駄な構造がそのまま反映されてしまい、その後の保守がすごく大変になってしまう。

この事象は、個人的には日本の製造業系のSIで多いのではないかと思う。
普通のメーカーでは、一つの工業製品を作る工程では、営業→設計部門→製造部門→各工場→品質保証部門→サポート部門のように、故意に複数の部門を横断させるように担当させる。
品質チェックするために、複数の部門の相互牽制を効かせるみたい。

すると、一つの製品を作るリードタイムは、単なる作業時間だけでなく、複数の部門間のコミュニケーションロスも含まれるから、かなり長くなる。
工業製品なら仕様や規格が明確に決められているから問題ないように思えるが、ソフトウェア開発では、このやり方が正直うまくいった事例を見たことがない。

ソフトウェア開発はコミュニケーションロスの塊だ。
ユーザ企業の経営企画部門→ユーザ企業の情報システム部門→プライムSI→2次請けSI→オフショア開発→品質保証部門のように工程が分断されると、コミュニケーションロスがすごく大きくなる。
下請け会社ごと、人ごとに作ったソフトウェアのI/F部分で設計仕様が分断され、結合テストになって初めて大きな問題が発覚し、その後のテスト工程で火を噴く。

日本のSI業界の悪しき慣習である多重請負構造は、サイロ型組織を蔓延させ、ソフトウェアのアーキテクチャを無駄に複雑化させる。

【2】もう一つは、アーキテクチャとは、多数の利害関係者の思惑や要望という政治的利害によって決まる場合があること。
経営企画部、営業部、製造部、ベンダー、運用部隊などの思惑を全て満たすアーキテクチャを決めようとすると、本来は単純な構造で良いはずなのに、複雑な構造になってしまう時がある。
最近は、そんな事例を経験して、正直不思議に思っている。

それは、ステークホルダーの要求によって、アーキテクチャが決まってしまうこと。
つまり、ステークホルダーが持つ政治的理由の方が、プログラマが持っている「システムのあるべき理想像」からなる「より良いアーキテクチャ」よりも、勝る点だ。

例えば、自分たちが開発するシステムは、単独では動かない場合がある。
なぜなら、ユーザ企業内の既存システムからユーザマスタや商品マスタを複製する処理が必要だったり、外部システムから発注データを取り込んだりする必要があったりするからだ。
すると、外部接続というI/Fを別に開発する必要がある。

その場合、既存システムや外部システムの保守チームに、自分たちのチームの要望を簡単に受け入れてもらえるようなら問題ない。
「ドメイン駆動設計」の「顧客・供給者の開発チーム」パターンのように、既存・外部システム(上流側・供給者)が自分たちのチーム(下流側・顧客)の言いなりになってくれるなら問題ない。

しかし、普通は、既存・外部システムは本番運用中なので技術的な冒険はあまりしたくないし、保守チームのリソースから考えて、大きな開発を担当できるほどの開発リソースもない。
だから、むしろ、「ドメイン駆動設計」の「順応者」パターンのように、自分たちのチーム(下流・順応者)は既存・外部システム(上流・供給者)の意向に逆らえず、彼らが準備しているI/F仕様に合わせて、古臭いやり方を踏襲するしかない場合が多い。

そんな場合は、「ドメイン駆動設計」の「腐敗防止層」パターンのように、外部システムの古臭いI/Fが侵入しないように、外部接続用のファサードを設けて、ラッピング処理のアーキテクチャを作る場合が多いだろう。
本来は、ラッピング処理のようなクッション(腐敗防止層)の処理を作る必要はないのに、無駄に複雑な間接層を作りこんでいるのだ。

自分たちのチームの業務システムはもっと簡単なアーキテクチャでいいはずなのに、外部の環境のせいで、無駄に複雑なロジックを抱え込んでしまうリスクがあるのだ。

特にエンタープライズにおける本来の業務システムのアーキテクチャは、もっとシンプルに作っていいはずだと思う。
しかし、現実は、利害関係者の思惑の方が、プログラマが本能的に知っている「より良いアーキテクチャ」よりも勝る。

【3】一方、オープンソース界では、プログラマが本来の理想像を求めて、より良いシステムを作れる環境があるみたいだ。
エンタープライズ界の業務システム開発では、政治的利害やサイロ型組織によって、アーキテクチャが複雑化しがちな例と好対照だ。

例えば、とある別のプログラマから聞いたけれど、仕事のプログラムのテストは、正直手を抜いている。
その理由は、スケジュール・コスト・品質の制約があるから、カバレッジを100％通すように作りこむことはできない。
だから、プログラマの直観や経験の勘によって、この部分のテストをやっておけば品質は担保されるだろう、と見込んで、テストを「ほどほど」にして終わらせる。
限られた時間内でプログラム開発を完了させる必要があるからだ。
無駄なだコストをかけてまで、赤字にしてでも、高品質にする必要はない。

しかし、オープンソースでは、自分の余暇を使って、好きなだけテストできる。
また、GitHubで自分のソースを公開する場合、この人はどこまできちんとテストしたのか、という成果物まで全部見られてしまうから、きちんとテストした方がいい、という動機も働く。
だから、オープンソースの開発では、テストプログラムはちゃんと書くし、カバレッジも100％に近くなるまで通します、とそのプログラマの方は言っていた。

そんな話を聞くと、エンタープライズ系の業務システム開発は、アーキテクチャの制約条件がきつすぎるのだろうと思う。
サイロ型組織、ステークホルダーの政治的思惑、コスト・スケジュールの制約などのトレードオフによって、本来はもっとシンプルであるべきアーキテクチャは、グチャグチャになり、綺麗な構造にならない。
テストもほどほどのレベルで終わらざるをえない。
その後の保守も大変だ。

一方、オープンソースの開発では、自分のアイデアを好きなだけ試すことができるし、プログラマが持っている「本来のあるべきアーキテクチャ」を作りこむことができる。

そんなことを思うと、大企業のような複雑な階層組織、サイロ型組織を持つ会社では、シンプルなシステムは作りにくいのだろうと思う。

シンプルなシステムを作ろうとすると、たくさんのシステムを共存せざるを得ず、SOAやEAIのように外部接続I/Fが増殖してしまいがち。
そんなアーキテクチャを多分「マイクロサービス」と呼ぶのだろうが、個人的にはそれが本当に良いアーキテクチャであるのか、僕は分からない。