ニュース
» 2018年10月11日 08時00分 公開

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

[新野淳一,Publickey]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -