マイクロサービスをチームで開発するには?

マネージャーの常松です。この記事はRetty Part1 Advent Calendar 2021の2日目の記事です。

少し前にマイクロサービス移行の経過を本ブログでまとめましたが、今日はマイクロサービスを開発する際のチーム編成について、考えていることを紹介します。

マイクロサービスは専門チームが開発するものでしょ?

「マイクロサービスの開発・運用は専門チームで受け持つものだ」という考えが一般的に広がっているように感じます。どこ発祥の考え方なのか見つけられなかったのですが、メルカリさんがまとめてくれているブログ「マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 | メルカリエンジニアリング」から辿れる先に源流があるのかもしれません。

「2枚のピザで足りる人数で、特定マイクロサービスを所有し、ドメイン知識を深めつつ単独してデリバリーができる。ドメインに沿ったチーム分割を行うことで逆コンウェイの法則を活かしたソフトウェアアーキテクチャを作るんじゃー！」そんな背景からかマイクロサービスでは1つのマイクロサービスを1つのチームで開発する体制の話をよく聞きます。

ところで、これは現実問題として成立するのでしょうか?

Q : エンジニア人数とマイクロサービスの数はバランスが取れるのか?
- 「うちはエンジニアまだ少ないので、1マイクロサービスあたり2人でお願いします」は無いと思います。
- 「マイクロサービス分割したいのでエンジニア増やさないと」は何かおかしな気がします。
- 「チームが作れないからマイクロサービス分割・切り出しをやめよう」は本末転倒。
Q : マイクロサービスの責務の切り方はそもそもあっているのか?
- 簡単に作り直せるのがマイクロサービスの利点のはず。
- チームごとにマイクロサービスを所有していたら全体の整合性は誰が指摘するのでしょう。
Q: マイクロサービス/チームごとに独自の実装進化を遂げないか?
- チームごと・サービスごとのお作法が発生しやすいはず。
- 横串を挿したり、標準化が必要では無いでしょうか。

上記の悩みを経て、現実としては「1チームで複数のマイクロサービスに責任を持つ」運用に落ち着くのが多いのではないかと思います。チームが単独してマイクロサービスの「リリース」はできるものの、ユーザーに価値を届ける「デリバリー」がチーム単独できるかは運次第な気がします。一定以上の大きさの機能開発を行うには、プロジェクトマネージャーを別に立て、複数チームが互いに協力しながら開発を進める必要があるのではないでしょうか?

複数チームで複数のマイクロサービスを見るのは現実的?

RettyではLeSSを導入しており、互いに対等のチームが単独でデリバリーまでできる形を模索しています。マイクロサービスでもサービスやリポジトリの所有者は設けておらず、どのチームもすべてのマイクロサービスに手を入れることができます。この形式を取ったことで、うまくできていることが多数あります。

サービス全体で責務・分割をどうするべきという話がしやすい。
サービス間で設計や方針が揃ってない箇所に目が届きやすい。
API界面を決定するときに十分な議論がチーム横断でできている。
チームが単独で顧客価値をデリバリーできる。他のマイクロサービスチームの開発を待つことがない。
みんながマイクロサービス移行の当事者なんだという意識が醸成できている。

もちろんうまくいったことばかりではなく、マイクロサービス移行を進める中でつまづいたこともあります。

サービス全体の知識が足りず、うまく議論できなかった。
マイクロサービスの知識が足りず、うまく議論ができなかった。
サービス・リポジトリの所有者が明確に定まっていないため、大きめの改善を入れることに躊躇する。
良い設計や改善のサービス横展開ができていない。

特にうまく議論を行うことは最初につまづいたことでした。RettyではマイクロサービスのAPIをgRPCを用いて定義しており、protoファイルは別リポジトリに分けた構成をとっています。このことからサービス分割・API追加を行う最初の1歩はprotoファイルリポジトリの修正となります。 Rettyでは全てのリポジトリでエンジニア間のレビュー・Approveを持ってマージするようにしていますが、このリポジトリは2人以上のApproveでマージできるルールとしています。したがってペアを組む二人の阿吽の呼吸で決まることが少なく、第3者や他のメンバーを交えた議論が自然と始まる仕組みです。当時はレビューを見てくれるメンバーが少なく、開発・リリースのブロックになっているという課題もありましたが、皆が開発の流れをつかみ、「マイクロサービス時代のRettyはprotoで議論をきちんとやっていかないといけないんだ」という意識が醸成された結果その問題も解消できたように感じています。

もっとマイクロサービス開発をやりやすくするために

決まったルール・議論したい事項をまとめておく

マイクロサービスの開発を始めて3年が経ちましたが、長い間やっているとメンバーが入れ替わり、過去に決めたルールや経緯が忘れられがちです。また良い開発の仕組みや新たに直面した課題も色々出てきますが、普段の業務と並行して検討することが多く、つい忘れてしまいます。

この課題を受け、マイクロサービス全体の議論事項をまとめておくリポジトリをIssueで用意し、社内・Slackで議論を見かけるたびにIssueを更新するようにしました。また決まったことはIssueをクローズし、同リポジトリに置くドキュメントを更新するようにしています。これにより途中からメンバーが入ってもどんな議論があり、どう決まったのかを以前より追いやすくなったと考えています。

マイクロサービスの勉強を継続して実施する

f:id:tune:20211120100016p:plain

当たり前ではありますが、マイクロサービスをやっていくのにマイクロサービスの基本的な知識は知っておく必要があります。マイクロサービス移行を始めた2年ほど前にマイクロサービスアーキテクチャの読書会を行なっていましたが、今年になってモノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイドの読書会も実施しました。読みやすい日本語でマイクロサービスの考えた方基本が解説されている本書ですが、複数人で読むことで理解の浅いところや自分たちの会社の実情に合わせた議論が起こりました。

社内メンバーのみで読書会を完走したのですが、さらにiCAREさんにもお声がけいただき、一緒に読書会2週目も実施しています。 PHPでマイクロサービス移行を進めているRettyと、Rubyでサービス運営をしているiCAREさんとでは直面している困りごと・視点が異なり、出席している自社メンバーもいろいろと勉強をさせていただいています。

横串で仕様を揃えていく

f:id:tune:20211120101550j:plain

この記事を書いている時点で16のマイクロサービスと1つのモジュラモノリスでマイクロサービスが構成されています。これだけの数になると初期に作ったものと最近作ったもので設計や動かし方が違うものも出てきました。そこで仕様が揃ってなく開発がやりにくかったものをヒアリングし、まとめながら少しずつ修正を加えて行っています。