マイクロサービス化はそんなにこぞってやるべきことなのか？

最近、求人等で自社のシステムをマイクロサービスで作っているとか、マイクロサービス化していきたいという話をよく聞く。

マイクロサービス化が「必ずやるべきこと」として捉えられているようにさえ見える。銀の弾丸として信じられているように見える。もはやマイクロサービス化することは前提になっていて、それをどうやるかに話が集中しているようにも見える。

作り上げるシステムは使い手ありきで、エンジニアはそのシステムを作り上げる仕事。その中で、正しく動くこと、使い勝手がいいこと、セキュアであること、修正が早く簡単にできること、などそれぞれ大事にすべきことがある。それらをどのように重み付けをするかは、チームにより様々な価値観があり、色々な試行錯誤があるものだろうと思う。

世の中にある多種多様なチームにとって、良い選択というのは、前提や状況や文脈によって、がらっと変わるものだと思う。それなのに、これほどまでにマイクロサービスがもてはやされているのにはかなり違和感がある。

マイクロサービスを導入してよかった話として納得できたことが1つだけある。エンジニアの割り当てがやりやすくなるという話である。作っているシステムがどんどん大きくなっていくと、開発に必要な知識が膨大になっていく。また人も多くなっていくので、一日あたりの全体の修正量も多くなり、「全体を把握している」人の仕事がどんどん難しくなっていく。「全体を把握している」人がボトルネックになり生産性が落ちる。そこで、システムをどこかで分断して、それに伴ってチームも分断する。チーム内の人は担当するシステムのみの知識があればよい。必要な知識量が減る。分断された他方のシステムとの取り決めや交渉に時間は取られるものの、分断する前よりは全体としてうまく回るだろう、という話。これは、確かに、と思わされる。

しかし、最近、全然小さなシステムやチームでもマイクロサービス化をしようという話は良く聞く気がする。何故なんだろう。それぞれを並行してやってみない限り、その時々でどの選択がよかったかを知ることはできないけども（やってみてうまくいったとしても、その選択がよかったからなのかどうかの評価は簡単にはできないはず、という意味で）。

でも、個人的には、以下のデメリットが大きく、小さなシステムやチームで導入する場合はほとんどがモノリシックで作ったほうがいいのでは？と思っている。

• 各機能やデータをどこのマイクロサービスの守備範囲に入れるかで都度迷いが生じる。チームの構成員で意見が食い違う。議論する。これで結構時間を使う。
• システムが分かれるということは単純にやることが増える。共通にすべきことと分けるべきことの境界線をうまく必要がある。難しそう。
• 表面積が増える。マイクロサービス同士のやり取りを決める必要がある。モノリシックなら考える必要がなかったこと。
• 諸々の環境の構築も地味に面倒そう。

マイクロサービス化により得られるものは、本当にこれらを上回るだろうか？