Future Tech Blog
フューチャー技術ブログ
Managementカテゴリ

本当は怖い、逆コンウェイ戦略

アーキテクチャの議論でよく出てくるのが、コンウェイの法則と、逆コンウェイ戦略です。これについては、うっかりIT用語をバズらせてしまう達人のマーチン・ファウラーのブログにも詳しい説明があります。角さん、いつも翻訳ありがとうございます。

この@katzchangさんのツイートもそうですが、逆コンウェイ戦略に関しては僕も少しモヤモヤするところが個人的にあり、そのあたりを周りの人（@katzchangさんや@tokoroten、@__garsue__氏）と議論したらいろいろ自分が思っていなかった知見も得られたりしたので、まとめてみます。

コミュニケーションがかえって増える問題

コンウェイの法則は、1960年代にコンウェイが書いた記事が元になっています。物理的に離れた3箇所で分担してシステムを開発したら、システムも自然とそのチーム構成に合わせたアーキテクチャになってしまったと。それを逆に応用し、分割したいソフトウェアの単位でチームもモジュールも一緒に分割すれば良い、というのが逆コンウェイ戦略（もしくは作戦）です。逆じゃない方は、観測された事実から導きだされたものなので「法則」ですが、逆の方はそれを積極的にプロジェクト運営に活用するためのアクティブな選択なので、「法則」ではなく「戦略」などが用いられているようです。

モジュール分割の失敗

マイクロサービスだと、すぐに「逆コンウェイだ」という話が出てくるのですが、適切なモジュール分割の方法は？という話がセットで出てくることがあまりないように思います。これが僕のモヤモヤポイントです。

ソフトウェアのモジュール分けについては、多くの流儀や方法論があります。最近読んでいていいな、と思っているのは、A Philosophy of Software Designの提唱するデザインで、外部との接点が少なくて済む、最小のAPIセットで分けられる単位でモジュールを分けましょう、というものです。正規表現などは内部でステートマシンなど複雑な要素を持っていますが、利用者はパターンを入力し、match/search程度の簡単なAPIで利用できます。そのように接点が少なく、中が深いモジュールが良いと述べています。

この場合、正規表現のステートマシンを開発するチームと、その外のAPIのチームを分けると、大量の接点が生まれてしまい、かえってコミュニケーションが増えてしまいます。チームを分ける＝チームを跨いだコミュニケーションを減らす、という観点では、接点が少ない境界を見つけるのが大切、というのがわかると思います。

データベース分割の失敗

あとは、RDB観点の切り方もありますね。DBのテーブルには日々の業務で増えて行くテーブル＝トランザクションと、読み込み専用で変化が少ないデータ＝マスターがあります。テーブル間には外部参照があってJOINをしたりしますが、読み込み専用のマスターは各アプリケーションにコピーを配っても問題ありません。問題はトランザクションです。トランザクションのテーブル同士のJOINが必要なら同じシステムに収めるべきです。JOINが必要がない境界線がうまくひけると、そのモジュール間では複雑な参照はないということになります。1+Nクエリー問題もおそらく減るでしょう。うまく分割できるとシステムの境界でデータベースのインスタンスも一緒に分割できます。インスタンスもモジュールとセットで分けられれば、モジュールの都合でDBスキーマの変更も自由にできることになります。

一方で、インスタンスの境界とモジュールが一致しないと、システム間で大量の1+Nクエリーを発射する必要がでてきますし、スキーマ変更やら何やらではチーム間の調整が必要になります。こちらも、コミュニケーションがかえって増えるのは想像に難くありません。マイクロサービスなのに、リリースサイクルやデプロイの調整が大変というのがボトルネックになります。

モジュールをまたいだ改善がやりにくくなる

マイクロサービスでつくられるが、言語やフレームワークなどのそれぞれの要素技術が違いすぎて、知見が生かせない、という事例も聞いたことがあります。同じようなロジックを、別の言語で別々に実装すると。

独立した組織に裁量を与えて自由を与えるとその分他の組織と独立した進化を始めてしまいます。メルカリのマイクロサービス開発は言語の選択はさせないようにして、共通のスターターキットを提供して、アーキテクチャを均質化しているという話がありました。何かしらの横断チームをおいて、良い設計の水平展開は必要ですね。

また、複数のモジュール間をまたいだ改善が必要な場合には、それぞれ歩調を合わせてやる必要があるため、チーム間の密なコミュニケーションは発生します。これは、技術ではなくて、相当なマネジメント力が必要な必要になるし、リーダーシップも必要になります。特定のチーム内だけのリーダーシップだとチーム間調整で空回りしたり・・・という事例はよく聞きます。なんかチーム間の調整の打ち合わせが増える、というのが副作用としてよく観測されます。

本来必要なコミュニケーションもなくなる

この観点は僕は持っていなかったやつです。本来は別のサービスと連携するには、IT部門に調整してAPIを出してもらってやるのが「壊れにくいシステム」には不可欠ですが、その調整が面倒、手っ取り早く済ますという目的で利用されるのがRPAですね。システム向けのAPIがないところを強制的にAPI化します。

まあ、僕の経験上はそこまでの状況はないのですが、アサイン権限とモジュール設計権限の両方があると、嫌いな人を会話しなくてもいいチームに押し込む、というのもあるとかなんとか。そういう殺伐現場、経験ある方いますか？

そもそも、コンウェイの法則は21世紀も現役なのかどうか

そもそもコンウェイの法則は1968年の事例で、チームというのはアメリカ大陸を横断して作られたものでした。当時の技術ではチーム間のコミュニケーションはかなりやりにくく、チーム同士を打ち合わせも飛行機での移動が必須で、ソフトウェアの構造もこれに引きずられるというのはわかります。

image.png

一方で、現代はチャットもテレビ会議もあり、ソースコードはネットワークを超えて管理しやすいGitなどを使って管理されますし、Pull Requestなどの非同期コミュニケーションを主体とした開発プロセスが一般化しています。いくつものオープンソースのプロジェクトが世界中に分散して開発されていたりします。フューチャーもロケーションフリー制度があり、チームリーダーがいつもオンライン、みたいなチームもあります。そのため、チームが分かれると会話がなくなる、というのは現代ではないでしょう。

リモートワーク以前にも、木構造でチームを編成して関連するチームを近い場所にしたり、職能で分けたチーム（横串）と、プロジェクト（縦串）でマトリックス組織にするというのも行われていますし、必要なコミュニケーションの量の流量の大小を勘案したチーム分けというのがこれまでも試行されてきました。チームが分かれると即座にコミュニケーションがゼロということはなく、チーム同士の繋がりはもっと有機的なものになっています。

コンウェイの法則という言葉を知っている人はアムダールの法則もご存知でしょう。結局チームが1箇所であっても、チーム内をどんどん非同期で動けるようにしないことには、チーム全体のスループットは上がりません。そして非同期にする仕組みというのは、ちょっとぐらい場所が違っても、作業効率を減らさない方法です。地球の真裏で時差がすごい場合はちょっと大変ですが、日本とインドぐらいなら全然平気だな、というのが僕の実感としてあります。

これらの話を総合すると、現代で同じ状況で開発を行ったら、おそらく1968年とは別の結果になるということは容易に想像できます。そうであれば、コンウェイの法則はほとんどの場合では当てはまらなくなるし、そうなると逆コンウェイ戦略もそんなに意識する必要もなくなるのかな、と思います。

もちろん、組織間の調停のために内部裁判所を作ったみずほ銀行のプロジェクトとか、マイクロソフトのOS開発とかだとよりシビアなチーム編成が求められるのでしょうけども、ほとんどのプロジェクトでそこまで意識するほどチーム分けなんて考えなくてもいいんじゃないかな、と思います。チーム分けたってどうせ一部の人に質問が集中したりするんですよね。「逆コンウェイが〜とか言ってる人らそんなにチーム分割できるほどデカい組織で働いてるのかも怪しい」(@__garsue__曰く)という意見もあります。マイクロサービスだから、とかそういう言葉に引きづられて、余計なことをしているんじゃないでしょうかね。

宇宙開拓時代になって、光の速度ではリアルタイム通信ができないという時代が来たら、大陸間の分断と同じ効果はあるので、宇宙に進出するまではコンウェイの法則は気にしないでいいんじゃないですかね。

あとは、外注する境界がシステムの境界になったり、というのはあるかもしれません。請負契約だと発注側と、作業員同士での直接の会話は基本的にするな、というのがあります。複数のサブサービスを別の企業に請負契約していたりすると、チーム間の会話は発注者を介在する必要があって減るので、大陸間の分断と同じ効果はありそうですが、まあこういうのは今後減らしていこうねというのがDXではコンセンサスのとれている話だと思うのでみなかったことにしておきますかね。

まとめ

コンウェイの法則は経験則から導き出されたもののようですが、それを逆転させてみよう、というのが逆コンウェイ戦略です。ですが、この逆転させるためには、「コミュニケーションが少なくなるような適切なモジュール分け」が必要だろうということを説明しました。それに失敗すると逆にコミュニケーションが増えることになるぞ、というリスクも説明しました。それ以外にもチームを分けることで生じるデメリットもいくつか紹介しました。

あとは、コンウェイの法則自体も、時代の変化で影響が減っているのでは、という話もしました。

まあ、このツイートの攻撃力の前にはすべての細っかい議論は吹っ飛びますけどね。今度から冷静な気持ちでコンウェイの法則に向き合えなくなる呪いがかかります。