はじめに
ある面接の場で、面接官の会社は新規事業の情報化に取り組もうとしていました。話の流れの中で、非常に現実的なシステム設計の質問が出ました：
「ゼロから事業システムの構造を設計する場合、どこから手をつけるべきか？」
私は一瞬考えた後、直感的にこう答えました：
「事業システムの構造設計は、既存の事業部門の組織構造に従い、現実の業務責任チェーンを起点にするべきです。」
これは過去の経験に基づく直感的な回答に過ぎません。しかし、面接後に振り返ると、これは本当に正しいのか、その背後には何か理論的な根拠はあるのかと考え直しました。
本稿では、この直感的な問いを体系化し、理論的根拠（例：コンウェイの法則）を検証し、現在観測可能なアプローチを整理します。
目的：組織がシステム構造をどう動かすか、そしてシステム構造が組織にどう影響するか、双方の相互作用の法則を考察すること。
現実から出発する——組織がシステムの初期形態を決める
「事業システムの構造設計はどこから始めるべきか」という質問に対し、私は直感的に「既存の組織構造から始める」と答えました。
この経験的な判断には、すでに理論的な裏付けがあります—— コンウェイの法則（Conway’s Law, 1967） です：
組織が設計するシステムの構造は、その組織のコミュニケーション構造に似る。
要するに：
組織のコミュニケーション、分業、協働の仕方が、そのままシステムに反映される。
- 部門間の責任分担や報告階層、チーム間インターフェースは、システムのサービス境界や呼び出し関係、データフローに現れる。
- 複数のチームで機能を共有すると、その部分のシステムは問題が起きやすい。
- ある部門が業務の閉ループを掌握している場合、その部分のシステムは明確で安定している。
コンウェイの法則は、組織構造に従えという指示ではなく、現実構造を尊重すべきことを示しています。
システムは空間に存在するのではなく、創設時から組織の痕跡を帯びています。
意識するか否かにかかわらず、組織のコミュニケーション、意思決定、責任境界に基づいて成長していくのです。
したがって、組織構造を理解することは、システムの生成論理を理解することと同義です。
誰が何に責任を持つのか、誰と誰が協力するのか、誰が重要なリソースを掌握しているのかを理解することは、フレームワークやパターンを理解するよりもシステムの形状を説明する力が強いです。
組織の境界はシステムの境界
システムのモジュール分割、インターフェース定義、責任範囲は、しばしば組織のコミュニケーション境界を映します：
- プロダクトラインごとに分かれた企業では、システムも自然と「プロダクトごとのサービス」に分かれます。
- 強い機能分業の企業（開発、テスト、運用が独立）では、システムは集中管理型アーキテクチャになりやすいです。
サービスの分割方法やデータの帰属ロジックの背後には、報告チェーンや協働パターンが隠れています。
システム構造設計の出発点は、システム図を描くことではなく、組織のコミュニケーション経路と責任境界を把握することです。
「誰が誰と話すか」「誰が何に責任を持つか」を理解して初めて、自然で持続可能なシステム形態が得られます。
システム構造設計の現実的出発点
システムの境界は技術的抽象から生まれるのではなく、現実の投影です。
現実的には、システムの形態は次の三つの要素により決まります：
- チームの責任範囲：誰が保守・デプロイ・意思決定を担当するかにより、どのモジュールが同じ責任単位に属するかが決まる
- 上下流関係：依存経路とデータフローが、部門間の業務協働を反映する
- コミュニケーションコスト：頻繁にやり取りするチームはデータ構造やインターフェースを共有し、独立して作業するチームは閉じた境界を形成する
これらの要素は意図的に設計されるものではなく、日常の運営を通じて徐々に固定化されます。
企業が責任、報告、協働経路を定義すると、システムも同じ方向で付随関係を形成します。
時間が経つと、コード、データベース、インターフェースは組織コミュニケーション図の技術的な鏡像となります。
組織構造が安定し、コミュニケーション経路が明確になると、システムの内聚性も強化されます。
逆に責任分担が頻繁に変わり、コミュニケーションインターフェースが混乱すると、システム構造も割れや重複が生じます。
まるで蔓植物のように、壁に逆らって生えることはなく、組織という支えに沿って少しずつ絡まり、広がり、定着するのです。
組織変化とアーキテクチャの進化的関係
組織は静的ではなく、企業の拡張、戦略の調整、リーダー層の変更は、組織境界の変化をもたらします。
システムアーキテクチャがこれらの変化を吸収できなければ、最終的に制御不能や硬直化が起きます。
アーキテクチャ進化のドライバー
現実には、システムアーキテクチャの変化は主に三つの要因によって起きます：
- 経営層の目標変化 —— 戦略方向の変更によるアーキテクチャ再編
- 組織責任の再分配 —— 責任境界の移動によるサービス所属の調整
- アーキテクトによる適応 —— 組織変化に対してシステムレベルで抽象的に吸収
理想的には、システムは小さな変更で組織変化に適応できるべきです：構造上の余白を残すことで、変化が自然な進化となり、強制的な再構築を避けられます。
システム構造の進化は「吸収力」
リファクタリングは技術レベルの最適化ですが、**吸収力（absorptive capability）**は体系的適応力です。
これは、既存の安定性を損なわずに、新しい責任、チーム、境界の変化を継続的に取り込む能力を指します。
- リファクタリング：コードやモジュールの技術的行為
- 吸収力：組織変化に対するシステムの弾力性
この能力は以下の要素で現れます：
- サービスの自治性：チームが独立して進化できる程度
- アーキテクチャの柔軟性：システム間依存関係の再構成可能性
- 技術的中立性：フレームワークに縛られず、組織との結合度を抑制
組織が再編されても、吸収力のあるシステムはすぐに崩壊せず、責任境界を徐々に再配置します。
組織駆動からシステムのフィードバックへ
初期段階では、組織構造がシステムに先行します。システムのサービス境界、モジュール分割、データフローは組織境界に沿って自然に成長します。
システムが業務価値を蓄積するにつれ、その構造と複雑性も増加します。運用コストや保守負荷、アップデートの代償が顕在化することで、企業は既存システムの最適化を検討します。
この最適化はシステムを改善するだけでなく、組織構造にも影響を与えます：
- システム境界が責任と依存関係を固め、チーム間協働パターンを可視化
- システムの進化性と自治性がチームの独立性を決定
- プラットフォーム化や統一指標、DevOps導入などの価値が新たな組織資源となり、協働の契機となる
ビジネスシステムや技術アーキテクチャの進化による影響は主に技術部門に限られます。ビジネス駆動型企業では、上位からの戦略や業務変化の方が組織変化により直接的な影響を与えます。
システムフィードバックの典型パターン
プラットフォーム化：システム抽象から部門設立へ
トリガー： 複数の事業チームが共通機能（ユーザー管理、タスクスケジューラ、決済、メッセージ）を重複構築
システム側の変化：
- アーキテクトが共通機能をプラットフォームサービスとして抽出
- 「インターフェース＝境界」の明確な分層を提供
- プラットフォームの安定性と性能が企業の基盤となる
組織側の進化：
- プラットフォームが独立部門（プラットフォーム部門、プラットフォーム技術部）へ
- プラットフォーム部門は「内部サービス提供者」、事業チームは「利用者」となる
イベント駆動型アーキテクチャ（EDA）：組織の分散化促進
トリガー： コアシステムの更新周期が長く、コミュニケーションコストが高い
システム側の変化：
- イベントストリーム（Kafka / RocketMQ / EventBridge）導入
- 新規事業チームはイベント購読により、自律的にロジック拡張
組織側の進化：
- 中央チームの承認権限が弱化
- チームの自治性向上
- コミュニケーションモデルが「リクエスト式」から「購読式」へ
アーキテクチャガバナンス体系化：アーキテクチャ委員会設立
トリガー： システム規模拡大、技術意思決定が分散
システム側の変化：
- 技術スタック規範、サービス分層、リリース管理を含むアーキテクチャガバナンス導入
- チーム間で協議・レビューが必要
組織側の進化：
- アーキテクチャ委員会成立
- 意思決定が制度化
- アーキテクトは「システムガバナー」へ変化
可観測性体系：DevOps一体化促進
トリガー： システム複雑化、部門間協働が非効率
システム側の変化：
- 統一監視、ログ、メトリクス、トレーシング（Prometheus / OpenTelemetry）
- システムからの直接フィードバック
組織側の進化：
- 開発・運用の境界消失
- チームが「自己運用型」に
- DevOpsが標準的組織形態に
データ基盤整備・指標体系化：部門間の連携を強化
トリガー： 部門間でデータ口径が異なり、指標衝突
システム側の変化：
- 統一データ基盤と指標モデリング導入
- 全社共通の指標命名空間と再利用可能なデータ資産確立
組織側の進化：
- データガバナンスチームが部門間調整の中心に
- 部門がデータ駆動の意思決定に注力
- KPI/OKRが共通指標を基盤に運用
組織変化に対するアーキテクチャ適応メカニズム
優れたアーキテクチャは、リファクタリングで変化に対応するのではなく、変化を吸収することを常態とする。
システムは徐々に「組織変化を吸収する能力」を持つことができ、頻繁なリファクタリングなしにチーム責任、境界、報告線の変化に自然に適応できます。
アーキテクチャ適応の核心
- 弾性を残す：モジュール自治、責任マッピングに余白を設ける
- 平滑に適応：変化が即座にシステム論理を壊さない
- 衝撃を軽減：頻繁なリファクタリングによるリスクを減らす
典型的な適応メカニズム例
- 責任とシステムの疎結合：構成やメタデータにより責任マッピングを解析、チーム変更がサービスインターフェースを壊さない
- モジュール自治と独立ライフサイクル：低結合、データ分離、独立移管可能
- 責任の再配分モデル：サービス登録と責任マッピングにより、新チームが迅速に引き継げる
- 組織変化検知とフィードバック：チーム調整を感知し、評価・通知をトリガー
- 跨組織ガバナンス層の安定維持：アーキテクチャ委員会がインターフェース規範と意思決定を維持し、組織変化と同期してシステム進化を支える
システムが組織変化を平滑に吸収できるかどうかは、システムと組織の結合度に依存します。
まとめ
面接の中で、何気なく答えた一つの質問を掘り下げてみると、思いのほか興味深いテーマだった。
コンウェイの法則をより深く理解できただけでなく、システム構造をゼロから設計する際には、まず組織のコミュニケーション構造と責任の境界を観察することが重要だと気づいた。
また、システムが運用され、ビジネスが発展していく中で、絶えず変化する事業形態に対応するためには、受動的なリファクタリングではなく、変化を吸収できるアーキテクチャを持つ必要がある。
組織を理解することは、システムの成長ロジックを理解することに他ならない。
そして、システムの進化は再び組織の形を変えていく。