300人から1000人へ――メルカリは開発組織を拡大するため「マイクロサービスアーキテクチャ」を採用した（前編）：Mercari Tech Conf 2018（2/5 ページ）

[新野淳一，Publickey]

専門性でチームを分けるとサイロ化が進む

　ソフトウェアのライフサイクルは大きく4つに分かれています。開発、テスト、デプロイ、運用、これを繰り返します。

　モノリシックなアーキテクチャでよく見られるのは、専門性で分けられたチームです。開発を行うバックエンドチーム、テストを行うQAチーム、そしてデプロイや運用を行うSREチーム（もしくはオペレーションチーム）に分けられるのが一般的です。

開発、テスト、デプロイ、運用というフェーズによって、チームが分けられるのが一般的

　仮に、組織のことを考えずにアーキテクチャのみをマイクロサービスに変えると、マイクロサービスの利点を失ってしまいます。例えば、バックエンドチームをそのままにすれば、マイクロサービスのサービスごとのオーナーが不明瞭になります。その結果、誰が責任者か分からず、誰にも触れないサービスができてしまいます。

　また、QAチームやSREチームをそのままにすると、サービスの増加に対して、彼らの作業が追い付かず、ボトルネックになりかねません。そうなれば、マイクロサービスの開発スピードを失ってしまいます。

　専門性でチームを分けることを続けていると、チーム間のコミュニケーションや知識の共有が薄くなってサイロ化が進むでしょう。チーム間のコラボレーションがなくなれば、開発効率を改善できなくなってしまいます。

サービスごとにチームを構成し、開発から運用までを行う

　こうした課題を解決する、マイクロサービスアーキテクチャにおける理想の組織構造は、「サービスごとにチームを構成する」ことです。チーム内で開発、テストからデプロイ、オペレーションまでを行うようにすれば、先ほど挙げたようなボトルネックはなくなるでしょう。

サービスごとにチームを構成し、開発から運用まで全てを行う。これがメルカリが考えるマイクロサービス向きの組織だという

　各チームは自律的に独立した意思決定を行って、効率的な開発を自分たちで回すことができるようになります。また、チーム内でソフトウェアライフサイクルの全てを担うことで、チーム内で開発、デプロイ、オペレーションという各領域の知識共有もできます。それによって、より良いサービスの開発や問題解決をチーム内でできるわけです。

　一方でこの組織は、新たな課題も生み出します。

　これまで開発のみに集中していればよかった開発者が、自分たちでデプロイや運用までやらなくてはならなくなった。つまり、マイクロサービスアーキテクチャにおける開発者の役割というのは、開発だけでなくソフトウェアのテストのスペシャリストとして、運用のスペシャリストとしても行動する必要があります。これはなかなか難しい要求だと思います。いきなりやれといわれて、すぐにできる人はいないのではないでしょうか。

　そこで、これを助けるために設立されたのが「Microservices Platform Team（マイクロサービスプラットフォームチーム）」。開発者が自分たちでマイクロサービスの開発からデプロイ、運用を行うことを助ける組織です。

　mercari.jpがマイクロサービスへの移行を始めたのは、ちょうど1年前でした。このグラフは、マイクロサービスの数を示していて、赤い線がすでに本番で動いているサービス、青い線が開発中のサービスを示しています。1年前は1つずつしかありませんでしたが、今では本番で動くサービスが19個、開発中のものは73個あります。

　それでは、ここに至るまでにマイクロサービスプラットフォームチームが何をしてきたかを紹介します。

現在、メルカリでは本番で動くサービスが19個、開発中のものは73個あるという