逆コンウェイって実は怖いものという話
逆コンウェイの法則とは？
逆コンウェイの法則（逆コンウェイ戦略）は、コンウェイの法則を逆手に取った考え方です。
コンウェイの法則のおさらい
まず、コンウェイの法則とは、メルヴィン・コンウェイが1960年代に提唱した概念で、
システム設計（アーキテクチャ）は、組織構造を反映させたものになる
というものです。例えば、モノリシックなシステムでは職能型組織（バックエンドチームなど）が存在し、マイクロサービス化するとサービスごとのフィーチャーチーム制が適している、というような相関関係があります。
逆コンウェイ戦略の理想
逆コンウェイ戦略は、この法則を逆に使う考え方です。
アーキテクチャによって組織構造を変化させるのではなく、最初から最適なアーキテクチャに合うような組織デザインを設計する
つまり、「アーキテクチャのための組織を作る」というアプローチです。理想的なマイクロサービスアーキテクチャを実現するために、サービスごとにフィーチャーチームを作るという戦略です。
一見すると、これは理にかなっているように見えます。マイクロサービス化とフィーチャーチーム制を組み合わせることで、サービス間の依存関係が減少し、リリースのリードタイムが短縮されるはずです。
しかし、実際にはうまくいかないことが多いのです。
逆コンウェイ戦略がうまくいかない3つの理由
1. コミュニケーションがかえって増えてしまう
逆コンウェイ戦略の目的は、チーム間のコミュニケーションを減らすことです。しかし、適切なモジュール分割が行われていない場合、逆にコミュニケーションが増えてしまいます。
モジュール分割の失敗例
ソフトウェアのモジュール分けには、外部との接点が少なくて済む、最小のAPIセットで分けられる単位でモジュールを分けることが重要です。
例えば、正規表現のステートマシンを開発するチームと、その外部APIを開発するチームを分けると、接点が増え、コミュニケーションコストが増大します。
【失敗例】
チームA: 正規表現エンジン（ステートマシン）
チームB: 外部API（正規表現エンジンを使用）
→ 接点が多すぎて、コミュニケーションが増加
本来、これらは同じモジュールに含めるべきものです。しかし、逆コンウェイ戦略に従って「モジュールごとにチームを分ける」と判断すると、このような不適切な分割が発生してしまいます。
データベース分割の失敗例
データベースの分割においても、トランザクションテーブル間のJOINが必要な場合、同じシステム内に収めるべきです。
不適切な分割は、以下の問題を引き起こします：
- 1+Nクエリ問題の発生：ユーザー情報を取得するのに、ユーザーテーブル→注文テーブル→商品テーブルと複数のクエリが必要になる
- スキーマ変更時の調整コスト増加：複数のチームと調整が必要になり、変更が遅延する
- パフォーマンスの低下：ネットワーク越しのJOINが増え、レスポンスタイムが悪化する
実際には、ユーザーと注文のデータは密結合しているため、同じデータベースに保存すべきです。しかし、逆コンウェイ戦略に従って「サービスごとにデータベースを分ける」と判断すると、このような問題が発生します。
2. モジュールをまたいだ改善がやりにくくなる
チームごとに責任範囲が明確に分かれると、モジュールをまたいだ改善やリファクタリングが難しくなります。
各チームが自分の領域に集中するあまり、システム全体の最適化が後回しになる可能性があります。
具体例
例えば、認証機能の改善を行う場合：
- サービスA：ユーザー認証を担当
- サービスB：商品管理を担当（ユーザー認証が必要）
- サービスC：決済を担当（ユーザー認証が必要）
認証機能を改善するには、サービスAのチームだけでなく、サービスBとサービスCのチームとも調整が必要になります。しかし、各チームは自分のサービスの開発に集中しているため、横断的な改善が進まない可能性があります。
さらに、各チームが異なる技術スタックやフレームワークを採用すると、同様のロジックを異なる言語で別々に実装することになり、共通の改善が困難になります。
3. 本来必要なコミュニケーションもなくなる
チーム間の境界が明確になりすぎると、必要な情報共有や意見交換が減ってしまう可能性があります。
コミュニケーションを「悪」とみなす誤解
逆コンウェイ戦略は「コミュニケーションを減らす」ことを目的としていますが、これはすべてのコミュニケーションが悪いという意味ではありません。
- モジュール間のインターフェース設計に関する議論
- システム全体のアーキテクチャに関する意見交換
- 共通の技術的課題の解決方法の共有
これらは必要なコミュニケーションです。しかし、チーム間の境界が明確になりすぎると、これらのコミュニケーションも減ってしまい、システム全体の品質が低下する可能性があります。
4. 現代ではコンウェイの法則の影響が弱まっている？
実は、コンウェイの法則は1960年代に提唱されたものであり、現代ではその影響が弱まっている可能性があります。
現代では、リモートワークや非同期コミュニケーションツール（Slack、GitHub、ドキュメント共有など）の発展により、物理的な距離や組織構造の影響が減少しています。
つまり、物理的に同じ場所にいなくても、適切なツールを使えば効率的にコミュニケーションが取れるようになりました。そのため、組織構造とアーキテクチャの関係を過度に意識する必要はないかもしれません。
なぜ逆コンウェイ戦略は「怖い」のか
逆コンウェイ戦略が「怖い」理由は、一見すると理にかなっているように見えるが、実際にはうまくいかないことが多いからです。
適切なモジュール分割の判断が難しい
適切なモジュール分割は、経験と知識が必要な難しい判断です。以下のような判断基準が必要です：
- 外部との接点が少ないか
- 独立して開発・運用できるか
- トランザクション境界が適切か
- データの整合性が保たれるか
しかし、これらの判断基準を理解せずに「モジュールごとにチームを作る」と判断すると、不適切な分割が発生します。
組織変更のコストが高い
一度、組織構造を変更すると、元に戻すコストも高いです。人材の配置転換、チームの再編成、関係性の再構築など、多くのコストがかかります。
そのため、失敗した組織構造を修正するのは非常に困難です。
問題が表面化するまで時間がかかる
逆コンウェイ戦略の失敗は、すぐには表面化しません。コミュニケーションの増加、開発速度の低下、品質の問題などは、数ヶ月から半年以上経ってから明らかになることが多いです。
その時点では、すでに組織構造が定着しており、修正が困難になっています。
どうすればうまくいくのか？
逆コンウェイ戦略を適用する際には、以下の点を考慮する必要があります：
適切なモジュール分割の原則
- 外部との接点が少ない：最小のAPIセットで分けられる単位
- 独立して開発・運用できる：他のモジュールに依存しない
- トランザクション境界を考慮：データの整合性が保たれる
- 適切な粒度：大きすぎず、小さすぎない
段階的なアプローチ
いきなり組織構造を変更するのではなく、まずは小さな範囲で試すことが重要です。
- 1つのサービスを独立したチームで開発してみる
- 問題が発生したら、組織構造を見直す
- 成功したら、範囲を広げる
横断的な組織も必要
フィーチャーチームだけでなく、横断的な組織も必要です。
- QAチーム：品質を担保する
- SREチーム：信頼性を担保する
- アーキテクチャチーム：システム全体の設計を監督する
これらの組織は、フィーチャーチームの「開発スピード」とは別の軸で、システム全体の「品質」や「信頼性」を担保します。
まとめ
逆コンウェイの法則は、一見すると理にかなっているように見えますが、実際にはうまくいかないことが多いのです。
- コミュニケーションが逆に増える：適切なモジュール分割が困難
- モジュールをまたいだ改善がやりにくくなる：チーム間の調整が増える
- 本来必要なコミュニケーションもなくなる：境界が明確になりすぎる
逆コンウェイ戦略を適用する際は、適切なモジュール分割の判断ができる経験と知識を持った人が主導し、段階的に進めることが重要です。
「アーキテクチャのための組織を作る」という理想は理解できますが、現実には組織構造の変更は高コストで、失敗を修正するのは困難です。そのため、慎重に検討し、小さな範囲から始めることが大切です。
Discussion