拡大期のサービスのモジュラモノリス移行を考えたらチーム編成の難しさにぶつかりそうな話
背景
著者が開発に携わるサービスは拡大期にあり、リアーキしてモノリスからモジュラーモノリス化しようと計画している。
著者はモジュラーモノリス化することで著書・チームトポロジーで描かれるようなストリームアラインドチームができていく、という理想を抱いていたのだが、どうもそれにはハードルがあるように感じたので、課題感を言語化し、それにどう対処していくかを考えた。
チームトポロジー的理想と、それに対する課題
▼理想
逆コンウェイ戦略によりモジュール分割され、そこに必要な職能のメンバーが集まってストリームアラインドチームができる。エンジニアの認知負荷は減少し、コミュニケーションや意思決定はチーム内で完結し、アウトカムが最大化される。
▼課題
「PMによる日々の施策立案は、現在想定しているモジュールに閉じた形ではなされていない」という現実がある。このままでは、モジュール分割を達成しても、各プロジェクトでは常にモジュール間を跨る開発が必要になり、PMにしろエンジニアにしろコミュニケーションパスが増え、チームは不安定化しまいそうである。
システムの分割の単位と、ビジネスの関心の単位にギャップがある
この課題を分析したところ、「システムの分割の単位とビジネスの関心の単位にギャップがあるのではないか」と考えた。
その原因は著者が思うに2点ある。
- モジュール分割単位を誤っているから
- サービスがまだ小さいから(モジュール分割は将来に向けた成長戦略としてやっているから)
以降はこれについて考える。
モジュール分割単位を誤っている?
著者は以前商材単位でマイクロサービス化するECサイトの設計は有り得るか?という記事を執筆した。
これは、機能単位でのモジュール分割が提案されていたことに対するalternativeであった。
これを書いてから3ヶ月が経過して改めて思うことは、モジュール分割の単位は、ドメインモデリングをしっかり行って決定するのが筋が良さそうと思ったことである。
ドメインモデリングをして、コアドメインがどこにあるのか、コンテクストはどこで分かれるのか、を既存のシステム設計に捉われず分析する。
ドメインモデリングで得られた情報に基づいてモジュール分割をすると、システムの分割単位とビジネスの関心単位は近づいていくことが期待される。
ということで実際に職種を巻き込んでドメインモデリング(イベントストーミング)を行った。これをやってみた結果は、後ほど誰かが別記事でまとめてくれるであろうので、この記事では割愛するが、機能単位よりはかなりコアドメインを意識した分割単位に近づいたように感じる。
(追記: 記事が作成されました! イベントストーミングを実施して、3日間で境界づけられたコンテキストを定義した話)
サービスがまだ小さい?
今回のモジュール分割は、今この瞬間のためよりも、将来に向けた成長戦略としてやっている側面が強い。
小さいサービスでは、エンジニアはシステム全体を把握できているし、施策のKPIはKGIであろう売上や利益に直結しやすい。
だが、サービスが拡大するにつれ、全体を把握するのは難しくなってきて、施策立案にせよ開発にせよ専門的な知識が必要となりコアドメインに閉じたものが増えてくる。
過渡期のサービスはその中間であり、システムは複雑化してくる一方で、多くのドメインに跨る施策はまだ多く出てくる時期である。
将来のためにモジュール分割したとして、現在それをどういうチーム編成で開発していくのか、を別途考える必要がありそうだ。
現実、どんなチーム編成にする?
では現状モジュールに閉じたストリームアラインドチームを作るのが困難だとして、実際どんなチーム編成にするのがいいのかを考えてみる。
経験則から、最低限、以下の要件は満たすものとしたかった。
- PMはチームに所属する
- 1人のエンジニアは1つのモジュールを管轄する
そこから、以下の2通りの案を考えてみた。
モジュールチーム案
モジュールとチームを一致させる。将来の拡大化に合わせたチーム作りとなる。先述の通り、プロジェクトの多くでチームを越境する必要があるので、PMやエンジニアリーダーを中心に会議体を設定して密にコミュニケーションを取っていくことになる。
クロスモジュールチーム案
モジュールとチームを一致させない。各チームに各モジュールに詳しいエンジニアが配属する。これにより、各チームが全ての開発を担うことができ、チーム内で案件を完結させやすくなる。一方で、あるモジュールを複数人が並行して改修することになるので、コンフリクトを起こしやすくなるリスクがある。また、いつかはモジュールチームに移行することになるかと思うので、その際は再編成が必要となる。
結論
これについても、1年後くらいに答えが出ているはずなので、その時に改めて補足する予定である。
株式会社SODAの開発組織がお届けするZenn Publicationです。 是非Entrance Bookもご覧ください! → recruit.soda-inc.jp/engineer
Discussion