第10章 コンウェイの法則とシステム設計
コンウェイの法則とは
"システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう"
この章では、疎のつながりのチームで開発するとモジュール性の高いコードが生産される傾向があると説明した上で、
複数のチームで共有サービスとして開発していく場合と、1つのサービスを1つのチームで開発する場合の考え方を紹介している。
1サービス1チームで組むべき。その理由。
- 単一チームであるとコミュニケーションのコストが容易且つ、担当サービスへの境界意識が強くなる
- システムを構築する人員が疎の場合、モジュール化していく傾向にある。
よって、個々のサービスの疎結合を目指すマイクロサービスではチームごとにサービスを担当するのが効率が良いと論じている。
共有サービスとチーム分割
これいつも思うんだけど、予算、リソースの問題だと思うんだよなあ...
本書ではすべてのサービスの開発を横断的に行うチームをフィーチャーチームと称してアンチパターン的に紹介がされている。
僕も典型的な予算がない良くないパターンと思っていて、フィーチャーチームの状況でマイクロサービスの開発優先順が決まってしまうなんて事も起こりうる。
個々のサービスは自律して開発されていくのが相応しい思想だと思うんだけどねぇ。
理想として個々のサービスのビジネスドメインに沿ったチーム構成になっていると、自ずと顧客指向な機能開発となる。はずと本書では示している。
ただ、少人数であるが故に属人的になりやすいことはリスクでデリバリボトルネックとして事例が紹介されている。
個人的には"枯れたマイクロサービス"が予算がつかない、どんどん保守されなくなっていくリスクなんかもあるんじゃないのかなあと思ったりしてたんだけど、きちんと孤児サービスという名称で説明があった。
文化が変わるということ
モノリシックからマイクロに変わるということは、違う言語や新しいOSSを導入したりと未経験のものに踏み込む機会があるということ。
そこは期待もあるが不安もあるので柔軟にサポートする必要があったりする。
そしてチーム内での人間関係(笑) 幸いにもマイクロサービスなので別チームに異動できれば良い(笑) 逆に入ってくるパターン、つまり異動が頻繁に起こり得るということを考慮しよう。
