コンウェイの法則とマイクロサービス

システム開発においてはコンウェイの法則が稀によく観測されます。

コンウェイの法則とは「システム設計は、組織構造を反映したものになる」法則のことです。

社内の開発体制とシステムアーキテクチャは密接な関係になり、社内のコミュニケーションパターンがDevOpsに影響を与えます。

ところで昨今、開発プロジェクトに関わるごとにマイクロサービスを採用したい人をよく見かけるようになりました。

1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ

です。

一つの膨大なシステムを開発運用するより、システム全体を小さく分割された複数のサービスにしておけば、各担当者はそれぞれ単体のサービスにフォーカスを絞って開発運用ができるようになります。

全体をまとめて管理するより運用コストを下げることができます。

また、サービスがモジュール化(疎結合化)しているのでシステムが冗長化しやすかったり、改修にかかるスコープが限定的で済んだり、継続的デリバリーとも相性がいいです。

すごくいい事だらけなような気がします。

しかし、この世に銀の弾丸はありません。

マイクロサービスを採用しようとしている現場のほとんどはベンチャー企業やスタートアップだったりします。

全員集まっても数人、多くても数十人ぐらいの規模感です。

そもそもチームを分割できるほど頭数がいません。

マイクロサービスは基本1チーム1サービスです。

しかし現実は1チーム複数サービスになっており、結局は全体をまとめて管理運用することになっています。

一つのシステムだと一つのサービスの運用管理で済みますが、複数のサービスに分割されていると、サービスの数だけ運用管理の手間がかかります。

分割した分、一つの状態のときより分量は増えますし、各サービス間のI/Fや連携に携わる手間も追加で発生します。

また、開発時にそれぞれのサービスを別々の開発チームにお願いしていたりすると、DDDにおけるドメインモデルの振れやユビキタス言語の差異が発生し、システム全体の統一性を保つことができなくなり、仕様の面から技術的負債が膨れ上がることになります。

ここで最初に話したコンウェイの法則が牙を向きます。

多チーム多サービスはコンウェイの法則を満たします。

しかし、1チーム多サービスはコンウェイの法則により1チーム1サービスに収斂していきます。

いくら口でマイクロサービスと喚いたところで、最後に蓋を開けてみれば、そこに存在するのはキレイに疎結合化されたサービス群ではなく、なんだかよく分からない十把一絡げになったシステム的なサムシングになるのがオチです。

そもそもベンチャーやスタートアップはビジネスモデルも確立できていないし、人の入れ替わりも激しい業界です。

朝令暮改やピボットが当たり前の世界です。

システムに期待される要件はカオスにさらされ、少人数でPDCAを高速で回す分、システムの実態は密結合にならざるを得ないでしょう。

ビジネスが不安定であり、組織が密結合なのですから疎結合のアーキテクチャであるマイクロサービスを採用すること自体、コンウェイの法則的に無理があるのです。

組織が密結合であるにも関わらずマイクロサービスを採用するものの、コンウェイの法則によりシステムは密結合に収斂していく、これがマイクロサービスがうまく機能しない理由です。

システムの所有者が大手大企業であり、その子会社がサブシステムを持っている、ぐらいの規模感がないとマイクロサービスは実現できないのです。

About