システム境界と組織境界をどう揃えるか――Conway の法則と逆 Conway マヌーバー

第 1 本「責務を固定し、統合を固定しない」では、マイクロサービスを単なるプログラムの分割ではなく、比較的安定した責務を独立させ、利用目的に応じて再構成できるようにする設計として整理しました。そこでは、正式なデータと業務ルールを所有するドメインサービス、複数サービスを業務目的に合わせてまとめる構成層、認証、イベント、監視などを提供する共通プラットフォーム、履歴を横断的に扱う分析基盤を分けて考えました。

しかし、システム上の責務を定義しただけでは、その境界は維持されません。誰がサービスを変更できるのか、誰が障害に責任を持つのか、どのチーム同士が日常的に調整するのかによって、実際のシステム構造は変化します。システム境界の設計は、同時に組織境界の設計でもあります。

第 2 本である本記事は、第 1 本で定義したシステム境界を、組織境界へ対応させる位置付けです。ドメインサービス、利用目的別の構成層、共通プラットフォームという分け方は、システム構成図だけでは維持できません。誰が変更し、誰が運用し、誰が責任を持つのかをそろえなければ、境界は実際のコミュニケーション構造によって崩れていきます。

本稿では、Conway の法則と逆 Conway マヌーバーを手掛かりとして、ドメインサービス、利用目的別の構成層、共通プラットフォームなどを、組織上どのように所有すべきかを考えます。

Conway の法則は組織図が画面に出るというだけではない

Melvin E. Conway は、1968 年に How Do Committees Invent? を発表しました。同論文の中心的な主張は、システムを設計する組織は、そのコミュニケーション構造を反映したシステムを作るよう制約されるというものです。Conway は、設計チームを組織する行為そのものが、実現可能な設計案を限定すると論じています。必要なコミュニケーション経路が存在しなければ、その経路を前提とする設計を効果的に追求できないためです。

この法則は、単に「会社の組織図とシステム構成図が似る」という話ではありません。重要なのは、正式な組織図よりも、実際に誰と誰が日常的にコミュニケーションできるかです。誰が同じチームに所属しているか、誰が同じ成果指標を持っているか、誰の承認が必要か、誰が同じコードを変更できるか、誰がデプロイと障害対応を行うか、チーム間の依頼が直接の会話で済むのか、正式な申請を必要とするのか。こうした経路が、システム内の接続関係や変更単位へ反映されます。

Conway の原論文では、二つのサブシステムが通信するには、それぞれを担当する設計グループがインターフェースについて交渉し、合意しなければならないと説明されています。システム内の接続には、組織内にも対応するコミュニケーション経路が必要になるということです。

技術別組織は技術レイヤー型のシステムを作る

たとえば、通信サービスに関係するシステムを、フロントエンドチーム、API 開発チーム、データベースチーム、ネットワークチーム、監視チーム、インフラチームといった技術別チームで開発するとします。「通信が遅い顧客の原因を調査できるようにする」という機能を追加する場合、複数チームへの依頼が必要になります。

フロントエンドチームが画面を作り、API チームがデータを集約し、データベースチームがスキーマを変更し、監視チームがメトリクスを提供し、ネットワークチームが経路情報を提供します。一つの業務機能を変更するたびに、技術レイヤーを横断した調整が発生します。このような組織が作るシステムは、フロントエンド層、共通 API 層、共通業務ロジック層、共通データベース、共通監視基盤のような、技術レイヤー中心の構造になりやすいでしょう。

技術的には整然として見えます。しかし、一つの業務変更が複数レイヤーへ波及し、それぞれ別チームの作業を必要とします。Martin Fowler も Conway’s Law で、フロントエンド、バックエンド、データベースなどのソフトウェアレイヤー別にチームを分けると、各機能の実現にレイヤー間の密接な協働が必要になり、システムにもレイヤー中心の構造が生じると指摘しています。

この状態では、システムが一つのプログラムであるか、多数のマイクロサービスであるかは本質的ではありません。サービスを多数作っていても、変更のたびに同じ複数チームが同時に動かなければならないなら、それは組織的にも技術的にも分散モノリスです。

システムの責務とチームの責務を対応させる

第 1 本では、システムをドメインサービス、利用目的別の構成層、共通プラットフォーム、分析基盤に分けました。組織についても、それぞれを誰が所有するかを定義する必要があります。ここでいう所有とは、単に担当者名が決まっていることではありません。何を提供するかを決め、内部実装を変更し、API やイベントの契約を維持し、品質とセキュリティーを管理し、本番環境の状態を観測し、障害や問い合わせに対応し、廃止や移行を判断する責任を含みます。

システム上の責務	主な組織上の所有者	主な責任
ドメインサービス	ドメインチーム	正式なデータ、業務ルール、API、変更、運用
利用目的別の構成層	プロダクトチーム・業務チーム	特定の利用者や業務に必要な UI、BFF、ワークフロー
共通プラットフォーム	プラットフォームチーム	認証、イベント、デプロイ、監視などの共通能力
分析基盤	データ・分析チーム	履歴収集、データ品質、集計モデル、分析環境
高度な専門サブシステム	専門チーム	特定領域の高度なアルゴリズムや低レイヤー処理
横断的な能力向上	一時的な支援チーム	技術移転、学習支援、能力上の障害の解消

設計責任だけを持ち、実装は別部門、デプロイは別部門、運用はさらに別部門という構造では、サービスのライフサイクル全体を所有しているとは言えません。責務、権限、必要な能力が同じ境界にそろって初めて、自律したサービスとチームが成立します。

Team Topologies の 4 つのチームタイプ

本稿で使っているドメインチーム、プロダクトチーム、プラットフォームチームという区分は、システム上の責務を誰が所有するかを説明するためのものです。一方、Matthew Skelton と Manuel Pais による Team Topologies は、組織設計の基本形として、4 つのチームタイプを定義しています。ここでは、本稿の責務境界と対応させながら整理します。

チームタイプ	役割	本稿との対応
ストリームアラインドチーム	特定の顧客価値や業務上の価値の流れに沿って、設計、構築、運用を長期的に担当する。	ドメインチームやプロダクトチームが、多くの場合ここに相当する。
プラットフォームチーム	共通の技術的問題を内部サービスとして提供し、ストリームアラインドチームの認知負荷を下げる。	認証、イベント配信、CI/CD、実行基盤、ログ、メトリクス、トレースなどを提供する。
イネイブリングチーム	不足している能力を獲得できるよう、一時的に支援する専門家チーム。	Kubernetes 運用、セキュアコーディング、SRE、責務境界の発見などを支援する。
複雑サブシステムチーム	高度な専門知識や複雑なアルゴリズムを必要とするサブシステムを担当する。	経路計算、暗号処理、低遅延パケット処理、特殊な統計モデルなどが候補になる。

ストリームアラインドチームは、価値の流れに沿って設計から運用まで責任を負うチームです。本稿のドメインチームやプロダクトチームは、多くの場合、この型として設計できます。ただし、両者は完全に同義ではありません。ドメインチームは、顧客、契約、監視などの責務とデータ所有に注目した呼び方です。プロダクトチームは、顧客ポータルや障害調査など、利用者へ届ける価値と体験に注目した呼び方です。

イネイブリングチームの成功は、そのチームへの依頼が増え続けることではありません。支援先が自力で扱えるようになり、支援が不要になることです。複雑サブシステムチームについても、技術的に難しいという理由だけで、すべてを専門チームへ分離すべきではありません。その複雑性が本質的であり、複数の価値ストリームから利用され、各ストリームアラインドチームが個別に理解するよりも、専門チームがサービスとして提供した方が全体の認知負荷を下げられる場合に適しています。

ドメインサービスと複雑サブシステムは同じ分類ではない

第 1 本で扱ったドメインサービスと、Team Topologies の複雑サブシステムは、分類の軸が異なります。ドメインサービスは、顧客、契約、監視など、業務上の責務とデータ所有の境界を示します。複雑サブシステムは、その実装や維持に必要な専門性と、他チームへ与える認知負荷に注目した分類です。

たとえば経路計算機能が、通信サービスの中核的な業務能力であり、一つの価値ストリームに閉じているなら、ストリームアラインドチームが所有するドメインサービスとして扱えるかもしれません。一方、複数のサービスから共通利用され、高度なアルゴリズムと性能最適化を継続的に必要とするなら、複雑サブシステムチームが所有し、明示的なインターフェースで提供する方が適切な場合があります。

したがって、ドメインサービスは必ずストリームアラインドチームが所有する、という単純な一対一対応にはなりません。サービスの業務上の責務、利用範囲、専門性、変更頻度、チームの認知負荷を見ながら、所有形態を決める必要があります。Team Topologies の 4 タイプは、組織図へ貼り付ける固定ラベルではありません。価値の流れと認知負荷を改善するために、チームの役割を考えるためのパターンです。

ドメインチームはデータと判断規則を所有する

顧客管理サービスであれば、顧客とは何か、どの情報が正式なものか、どのように登録・変更・削除できるかを、顧客管理を担当するチームが所有します。契約管理サービスであれば、契約の成立条件、変更条件、終了条件を、そのサービスを担当するチームが所有します。監視サービスであれば、何をどの単位で観測し、どの状態を異常と評価し、どのようなデータを外部へ提供するかを所有します。

他チームは、これらのデータベースを直接変更しません。公開された API やイベントを通じて利用します。その代わり、ドメインチームには、他の利用者が必要とする情報を、安定した契約として提供する責任があります。「自分たちのサービスだから好きに変更できる」という意味での自律ではありません。外部との契約を守りながら、内部を自律的に改善できる状態が必要です。

一つのドメインチームが、必ず一つのマイクロサービスだけを担当する必要もありません。責務が密接で、同じ知識と変更サイクルで扱えるなら、一つのチームが複数のサービスを所有できます。逆に、一つのサービスを恒常的に複数チームで共同所有すると、変更判断や障害対応の責任が曖昧になります。重要なのは、サービス数とチーム数を一対一にすることではなく、サービスの変更に必要なコミュニケーションを、チーム内部で完結できる範囲へ収めることです。

構成層は利用目的に近いチームが所有する

顧客ポータル、障害調査画面、開通ワークフロー、経営分析画面では、同じドメインサービス群を異なる形で利用します。そのため、BFF、API 集約、UI、ワークフローなどの構成層は、個々のドメインチームではなく、利用目的を理解するチームが所有する方が自然です。

たとえば障害調査機能であれば、顧客と契約、対象サービス、回線と装置、アラームとメトリクス、構成変更、障害チケットを組み合わせます。これらの正式なデータは、それぞれのドメインチームが所有します。一方、「通信遅延を調査する際に、どの順番で何を表示し、どの操作を可能にするか」は、障害対応業務を担当するプロダクトチームが所有します。このプロダクトチームは、障害対応という価値の流れへ責任を持つストリームアラインドチームとして位置付けられます。

構成層を中央の共通チームへ集めると、そのチームがすべての業務を理解しなければならなくなります。新しい画面を作るたびに中央チームへの依頼が必要になり、中央チームが各ドメインの内部事情まで知るようになり、API 集約サービスに業務ロジックが集中します。これは、統合層を新しいモノリスにする組織構造です。利用目的に固有の統合は、その利用目的に責任を持つチームが所有する方が、システムと組織の双方で境界が一致します。

プラットフォームチームは業務判断を所有しない

認証、イベント配信、サービスディスカバリー、CI/CD、ログ、メトリクス、トレースなどは、多くのチームが必要とする共通能力です。各チームが個別に実装すると、重複、不統一、セキュリティー上の差異が生じます。そのため、これらをプラットフォームチームが内部サービスとして提供することには合理性があります。

ただし、プラットフォームチームは、すべての変更を審査する中央管理部門ではありません。役割は、他のチームが自律的にシステムを作り、運用するための技術能力を提供することです。Team Topologies の公式解説でも、プラットフォームチームは、ストリームアラインドチームの認知負荷を減らすため、差別化要因ではない共通機能をサービスとして提供するものと位置付けられています。

良いプラットフォームは、利用チームが毎回プラットフォーム担当者へ作業を依頼しなくても使えます。API として利用できる、宣言的に設定できる、ドキュメントとテンプレートがある、利用状態を自分で確認できる、標準的な範囲では個別承認を必要としない、といった性質が必要です。反対に、Namespace 作成、CI/CD 変更、監視項目追加、API Gateway 設定変更、障害一次対応のすべてが中央チームへの依頼になるなら、プラットフォームチームがボトルネックになります。

共通基盤を中央化することと、すべての操作権限を中央へ集中させることは別です。プラットフォームは、統制のための関所ではなく、自律性を支える製品として設計する必要があります。

チームタイプと相互作用モードを混同しない

Team Topologies では、4 つのチームタイプとは別に、チーム間の関係を Collaboration、X-as-a-Service、Facilitating という 3 つの相互作用モードとして整理しています。チームタイプは、そのチームが組織内でどのような責務を持つかを示します。相互作用モードは、二つのチームが、特定の時点でどのような関係を持つかを示します。

相互作用モード	意味	注意点
Collaboration	異なる能力を持つチームが、境界や解決方法を発見するために、期間を限定して密接に協働する。	恒常的な協働が必要な状態は、責務境界やインターフェースが未確立である可能性がある。
X-as-a-Service	提供側が明確な責任を持つサービスを提供し、利用側が内部実装を知らずに利用する。	API が存在するだけではなく、品質、利用方法、フィードバックによる改善が必要になる。
Facilitating	一方のチームが、別のチームの能力獲得や障害解消を一時的に支援する。	作業を恒久的に代行するのではなく、支援先が自分で扱える状態を作る。

「連携が必要だから横断組織を作る」というだけでは、チーム間の依存は解消しません。何をサービスとして提供し、何を期間限定で共同設計し、どの能力を移転するのかを明示する必要があります。

逆 Conway マヌーバーは組織図の書き換えではない

Conway の法則を受け入れるだけであれば、現在の組織構造に合わせてシステムを作ることになります。逆 Conway マヌーバーは、望ましいシステム構造を促すように、チーム構造やコミュニケーション経路を意図的に変える考え方です。Thoughtworks Technology Radar は 2014 年に Inverse Conway Maneuver を取り上げ、望ましいアーキテクチャを促進するよう、チームと組織構造を進化させる手法として説明しました。

ただし、これは組織図の箱を描き直せば、システムが自動的に疎結合になるという話ではありません。コードの変更権限が旧組織に残っている、データベースを複数チームが共有している、予算や要員を中央部門が個別に承認する、リリースを別の運用部門へ依頼する、障害対応を別チームへ引き渡す、技術判断が上位の委員会に集中している、成果指標がチームごとに矛盾している。こうした状態が残っていれば、実質的なコミュニケーション構造は変わりません。

正式な所属を変えることよりも、変更、運用、データ、予算、意思決定の経路を変えることの方が重要です。組織図を更新しても、実際の変更権限と責任の流れが旧来のままであれば、システムは旧来のコミュニケーション構造へ戻ります。

逆 Conway マヌーバーを反復的に進める

既存システムへ逆 Conway マヌーバーを適用する場合、先に大規模な組織再編を行うのは危険です。既存システムの境界と新しいチーム境界が一致しない期間には、かえって変更の摩擦が増えるからです。Fowler も、既存の硬直したアーキテクチャに対して組織だけを変更しても即効性はなく、コードと組織の不一致による摩擦が生じるため、アーキテクチャと組織の進化を並行して行う必要があると述べています。

段階	実施内容
現在の変更の流れを観察する	機能変更に関与したチーム数、承認、待ち時間、同時変更、責任が不明確になった箇所を確認する。
安定させたい責務を仮説として定義する	顧客、契約、サービス構成、監視など、長期間独立して維持したい責務を特定する。
チームタイプと所有者を設計する	ストリームアラインド、プラットフォーム、複雑サブシステム、イネイブリングのどの型が必要かを考える。
利用目的別の構成をドメインから分離する	特定の UI やワークフローの都合が、ドメインサービスの責務へ流入しないようにする。
必要な権限と能力を移す	設計、実装、テスト、デプロイ、監視、障害対応を、同じチームが扱えるようにする。
結果を評価し、責務定義へ戻る	変更速度、障害復旧、チーム間依頼、認知負荷、API 変更頻度などを観察し、境界を見直す。

この反復で重要なのは、境界を最初から完成形として扱わないことです。二つのサービスが常に同時に変更される、複数チームの恒常的な Collaboration が必要になる、一つのチームの認知負荷が高すぎる、共通機能が複数チームで重複している、プラットフォームの利用に人手の依頼が必要になる、複雑サブシステムの内部知識が多数のチームへ漏れ出している。このような状態が続いているなら、責務を分離するだけでなく、細かく分けすぎたサービスやチームを再統合することも必要です。

逆 Conway マヌーバーとは、完成したシステム構成図を組織へ押し付けることではありません。望ましい責務境界を仮説として置き、実際の変更の流れを観測しながら、システムと組織の両方を反復して調整することです。

一つのサービスに一つのチームを作ればよいわけではない

逆 Conway マヌーバーを単純化すると、「マイクロサービスごとにチームを作る」という誤解が生じます。しかし、サービスが 50 個あれば 50 チーム必要になるわけではありません。細かすぎるチーム分割は、API 調整を増やし、小規模な変更にも複数チームを必要とし、当番や運用要員を維持しにくくし、業務全体を理解する人を減らし、管理職と調整役ばかりを増やします。

チーム境界は、技術コンポーネントではなく、意味のある責務と変更の流れを基準に置く必要があります。一つのチームが、同じドメインに属する複数の小さなサービスを所有することは自然です。逆に、規模が大きいからという理由だけで、一つの責務を複数チームへ水平分割すると、内部調整が必要になります。複雑サブシステムチームについても、専門技術ごとに恒久的なチームを増やせばよいわけではありません。専門性を分離することでストリームアラインドチームの認知負荷が本当に下がるのか、利用者にとって明確なサービスとして提供できるのかを確認する必要があります。

目指すべきなのは、すべてを最小単位へ分解することではありません。チームが理解し、変更し、運用できる範囲で、外部との依存を限定することです。サービス境界とチーム境界は、数を増やすためではなく、変更に必要なコミュニケーションを適切な場所へ収めるために設計します。

自律した組織は横断連携を不要にするものではない

責務を明確にすると、「縦割りが強くなるのではないか」という懸念もあります。しかし、責務境界があることと、他チームと連携しないことは別です。自律したチームにも、他のチームとの調整は必要です。違いは、調整対象と関係の形が明確であることです。

API やイベントの契約、共通識別子、SLA や品質条件、変更通知、障害時の責任分界、廃止や移行の計画、期間限定の Collaboration、X-as-a-Service として提供する範囲、Facilitating の目的と終了条件。境界が曖昧な組織では、あらゆる問題について「あの部門にも確認する」必要があります。境界が明確な組織では、どの契約について、どのチームと、どの相互作用モードで調整すべきかが分かります。

良い疎結合は、コミュニケーションをなくすのではありません。日常的に必要な高密度のコミュニケーションをチーム内部へ収め、チーム間のコミュニケーションを、明示的な契約や期間限定の協働として扱えるようにします。

組織設計も固定しない

Conway の原論文は、設計の初期に置いたシステム概念が常に最善とは限らず、設計概念の変化へ対応できる組織の柔軟性が重要であると結論付けています。これは、逆 Conway マヌーバーを一度だけの組織再編として扱ってはいけない理由でもあります。事業、技術、利用目的が変われば、適切なシステム境界も変わります。システム境界が変われば、チームの責務やコミュニケーション経路も見直す必要があります。

一方で、短期間に何度も組織を組み替えれば、チームが共有してきた知識や信頼関係が失われます。したがって、変える対象を区別する必要があります。比較的安定させるものは、正式なデータの所有、業務上の判断規則、サービスの品質責任、API やイベント契約です。目的や状況に応じて変えるものは、どのチームと一時的に協働するか、どの機能を X-as-a-Service として提供するか、どの能力をイネイブリングチームから移転するか、どの業務目的でサービスを組み合わせるか、どの責務を次に分離または統合するかです。

組織もシステムと同様に、すべてを固定するのではなく、安定した責務を中心に再構成可能である必要があります。固定すべきなのは責任を持つ対象であり、変えるべきなのは、目的に応じた協働、提供形態、能力移転、分離と統合の判断です。

システム境界と組織境界は同時に設計する

Conway の法則は、組織構造が悪いからシステムが悪くなる、という単純な責任論ではありません。人間が複雑なシステムを分担して設計する以上、コミュニケーション構造がシステムへ反映されることは避けられません。問題は、その影響を無視することです。

ドメインサービスを独立させたいなら、そのサービスの状態、判断、変更、運用を所有できるチームが必要です。利用目的別の構成を変えられるようにしたいなら、その業務を理解するチームが BFF、UI、ワークフローを所有する必要があります。共通プラットフォームを提供するなら、プラットフォームチームは業務判断を集中させるのではなく、他チームの自律性を高める内部プロダクトを提供する必要があります。

本質的に高度なサブシステムがあるなら、専門性を各チームへ拡散させるのではなく、複雑サブシステムチームとして明確なサービス境界を設けることも考えられます。新しい能力を組織へ定着させる必要があるなら、イネイブリングチームが一時的に支援し、恒久的な依存を作らずに能力を移転します。

逆 Conway マヌーバーとは、システム構成図に合わせて人を並べ替えることではありません。長期間維持したい責務に、必要な知識、権限、資源、コミュニケーション経路をそろえ、その境界が機能しているかを継続的に見直すことです。システム境界と組織境界のどちらか一方だけを設計しても、もう一方がそれを元の形へ引き戻します。両者を同じ設計問題として扱うことが、疎結合なシステムと自律した組織を成立させる条件です。

参考情報

• Melvin E. Conway: How Do Committees Invent?
• Martin Fowler: Conway’s Law
• Team Topologies: Team Interaction Modeling with Team Topologies
• Thoughtworks Technology Radar: Inverse Conway Maneuver

関連する記事