小さい組織でMicroservices Architectureは止めた方がいい

2018-12-20

この投稿はMicroservices Advent Calendar 2018 19日目の投稿です。

簡単なまとめ

マイクロサービスの大きな利点は、チームに権限と責任を委譲することで、組織が拡大してもチーム毎に自走することで開発スピードが落ちないことです。小規模組織だとチーム毎に自走することが難しい場合が多く、マイクロサービスとしてのチームを組んでいることが足枷になります。障害の局所化やビルドの高速化を欲しいならそれは垂直分割した分散システムで十分です。¹ そのため、分散システムを持つチーム（≠マイクロサービスのチームではない）という認識を持った方が、無駄なオーバーヘッドが無くなりお得だと思います。

マイクロサービスの利点とは何か

マイクロサービスではプロダクト毎にチームとシステムを分割し、各チームが独自の権限で自分達のシステムを開発していくことで、コミュニケーションコストを抑えつつ、組織が拡大しても開発速度の低下を抑えるのが大きな利点の1つです。

マイクロサービスではシステム自体は垂直分割されたシステムと変わりはありませんが、プロタクト毎にチームを分割し、権限と責任を委譲して自走できるようにしています。これにより、分散したことによる複雑さやチーム間のコミュニケーションコストよりも、開発速度の向上や組織の拡大に対応できるといった恩恵の方が大きくなり、ただの分散システムより良いというのが大きな価値の一つと考えられます。

プロダクトによるチーム分割

一方で、チームの分割の仕方としてプロジェクト単位で区切るという形があります。これは個々のシステムではなく、案件毎にチームを組んで開発していくもので、システムは特定のチームに所属せず、プロジェクトもあらゆるシステムを触り得ます。

プロジェクトによるチーム分割

前者のプロダクト単位でチームを分割する場合、マイクロサービスの恩恵を最大限に得られます。一方で後者のプロジェクト単位の分割の場合、マイクロサービスの恩恵はあまり受けられません。²

しかし、残念ながらプロジェクト単位の仕事が一切無いパターンは稀です(特殊なキャンペーンのために開発が必要)。そのため、どれだけプロダクト分権を行い独自にチームを動かせるかが、マイクロサービスの恩恵に直結します。

何故小さい組織では止めた方が良いのか？

結論を言うと人がいないため、プロダクトごとのチーム分割が事実上不可能なためです。
なお、ここでいう小規模組織は事業に対して小規模という意味であり、具体的な人数はやっている事の手広さとかに影響を受けます。

前述のようにプロジェクト型の仕事は定期的に発生し得ます。³

プロダクトチームとプロジェクトチームの両方に所属するのが上手くいかない原因なので、プロダクト毎のチームとは別に組織横断的なプロジェクトチーム用として人員を確保することで回避できます。実際、SREのようなプロジェクト型の仕事にフォーカスするチームは小規模組織だったとしてもそこまで問題にはなりません。ただし、プロダクト全般でそういった人員を確保するのは小規模組織では難しく、結果として問題を解決できません。

そのため、小さい組織でマイクロサービスアーキテクチャを採用するのは止めた方がよいです。障害の局所化やビルドの分割といった分散システムの利点を得たいのであれば、マイクロサービスを目指してプロダクトチームを作るのでは無く、分散システムを運用するプロジェクト型の組織という認識の元にチーム構成をするほうが良いと思います。

ただしこれは現在私がプロダクトチームに所属しつついろんなプロジェクト型の仕事に火消しとして突っ込まれる仕事の仕方をしている立場からの視点です(≒今回の問題点を強く受ける)。例えばプロダクトチームに専任しているのであれば、オーナーシップを持って速度を落とさず課題を解決していくことができます。基盤チームのような横断的なチームではマイクロサービスの課題は他ではなかなか無い良い課題ですし、プロダクトのみ・プロジェクトのみに所属する、マイクロサービスの恩恵をフルに受ける人からみた意見は異なると思います。

小規模組織ではいかにプロジェクト・プロダクトの軸を兼任することを減らすかということが重要になりますが、小規模組織だとそもそも不可能なことが多く、それを採用してコミュニケーションコストを増大させるよりかは、自分達の組織規模に合った構成にしてその分のエネルギーを価値創造に費やした方が良いと思います。なお、小規模組織でもほぼプロダクトにフォーカスした仕事しか発生しない組織構造であればマイクロサービスは上手くと考えられるため、そういった仕事の仕方をできるのであれば、小規模組織でもワークすると思います。

課金系を分けるとかそういうやつのイメージ、おそらく広義の垂直統合型分散システム。 ↩︎
マイクロサービスは垂直分割された分散システムとしての側面を持っており、障害の局所化やビルドの分割といった部分は得られますが、それはマイクロサービスではなく決済系を別にするといった垂直分割した分散システムの利点ですよねという話 ↩︎
会社の戦略により頻度はまちまち、うちはけっこうあるそのため、プロダクト毎にチームを分割したとしても、必要に応じてプロジェクトチームに人が招集されるといったチーム構成になりがちです。マイクロサービスではチーム毎に自走できる状態を作る必要がありますが、プロジェクト型の仕事はチームの垣根を越えて動く直行する概念であり、これら2つが同時に課せられるととてもつらい状況になります。システムを横断して仕事をするプロジェクト型と、チーム毎に決定権を持って決めていくプロダクト型のチームはとても相性がわるく、マイクロサービスは足枷になり得ます。 ↩︎