メルペイArchitectとは、サービス全体を見つつ、組織横断で技術的な課題を解決するチーム。マイクロサービスはもちろん、そのほかの事象に対しても他チームと連携しながら動くことが多いです。

そんなArchitectチーム体制が2022年1月より刷新。今までどおりマイクロサービスを含めたアーキテクチャ周りを担当するArchitectチームに加え、新たに社内向けシステム開発・運用を行うEngineering Productivityチームが誕生しました。

2チーム体制になり、今後どんなことをしていくの？ そこで今回のメルカンではEngineering Productivityチームのテックリードである森健太（@zoncoen）と、Architectチームを初期から支え続けてきた佐野正浩（@kazegusuri）で対談しました。

※撮影時のみマスクを外しています

メルペイArchitect初期は1〜2人体制だった

@zoncoen：@kazegusuriさんとは定期的に1on1をしますが、Architectチーム立ち上げ〜現在に至るまでの話をじっくり聞く機会はそんなになかった気がしています。2チーム体制になるので、これを機にいろいろ話を聞ければなと！

@kazegusuri：ありがとうございます（笑）。何から話しましょうかね？

佐野正浩（@kazegusuri）

@zoncoen：僕がメルペイへ入社したのは2018年6月。当時のArchitectチームは@kazegusuriさんを含めてほぼ1〜2人で担当していましたよね？

@kazegusuri：そうです。Architectチームは僕が立ち上げ、しばらく担当していました。当時のメルペイはまだ立ち上がったばかりで、各開発チームにエンジニアはいるものの「何をつくればいいのか」が明確じゃなかったんです。Architectチームは「このチームではこういうものをつくってほしい」と伝える役割として誕生しました。

同時にプロダクト開発“以外”で必要な開発も、Architectチームで担当。具体的には、社内向けシステムに近いものですね。当然ながら僕だけでは手が回らないので「この開発にはこの人が必要です」「この人ならいいアイデアをもらえそう」と感じたメンバーに、マネージャーを通じて声をかけていました。@zoncoenさんもその1人です。

@zoncoen：うっすらと覚えがありますね（笑）。僕がメルペイへジョインしたばかりのころは「メルペイのシステムを全部Cloud Spannerにするぞ！」と言っていたような？

森健太（@zoncoen）

@kazegusuri：そうそう。そもそも僕は「MySQLからCloud Spannerに置き換える」という役割を果たすためにメルカリからメルペイへ異動しています。@zoncoenさんも加わってくれたおかげで、今やメルペイのシステムの99％がCloud Spannerです。

…と、そんな感じでメルペイの開発基盤や共通の仕組みをArchitectチームでつくってきました。Gateway機能も足りていなかったのでメルカリ・メルペイで共通のものをつくったり、負荷試験をしたり。Architectチームの黎明期にこれだけのことをしているので、このペースで話していたら取材時間が足りない（笑）。

@zoncoen：たしかに（笑）。

次第に増え始めた、当初の役割“以外”の業務

@zoncoen：Architectチームにジョインして印象的だったのは、いろいろなチームのメンバーが@kazegusuriさんの自席へ訪れていたことです。@kazegusuriさんの自席横にはベンチがあり、そこに列ができていたこともありました！

@kazegusuri：プロダクト開発をするメンバーにしか見えない課題があるので、そういったものを持ち寄ってくれていてとてもありがたかったですね。僕としても、そういった情報をキャッチしやすいように、あえて自席を廊下側にしていました。

メルカリグループは、開発手法としてマイクロサービスを取り入れています。メルペイも例外ではありません。しかし、マイクロサービスは一時的に不安定になることがある。そこをどう安定させるかを、プロダクト開発メンバーと相談しながら進めていました。

同時に、チームやメルペイの組織そのものが大きくなり、開発チームが増えてきたことでマイクロサービスの状態を把握しづらくなっていきました。各チームでどんな課題を持っているのかがわからなくなっていたんですよね。

@kazegusuri：僕らとしては1つでも多くの課題を解決したい。そこで、マイクロサービスの状態を可視化する仕組みをつくり始めたんです。おかげでArchitectチームの本業としていた「アーキテクチャに関する悩みごとを解決」が各チーム内でできるようになり、相談を寄せられることが徐々に減少。一方で、特定のチームやプロジェクトの個別支援が求められるようになったんです。

@zoncoen：Architectチームが当初想定していたもの以外での業務が増えたということ？

@kazegusuri：そうです。その1つが、QAの安定化です。特に初期のころのメルペイではQA環境と開発環境が違っていたため、突然どちらかで動かなくなったりするなどのトラブルがありました。Architectチームは、そういったQA環境を安定させるためのシナリオテストのような仕組みをつくることにしたんです。それを、まるっと@zoncoenさんにお願いしました！

@zoncoen：はい、まるっと任されていました（笑）。ある機能で問題が起きたとき、どのマイクロサービスで問題が起きているのかを調査するのが大変だったんです。そのため、テスト環境でのインテグレーションテストを自動化し、エンジニアが異変にいち早く気付けるようにしました。同時にQAのやり方も効率化。くわしくはMerpay Tech Festの記事にあるので、そちらを見てもらうといいかもしれません。

@kazegusuri：Architectチームの当初の仕事は、マイクロサービスのアーキテクチャ構築を支援し、共通基盤をつくること。しかし、共通基盤さえできれば、あとは各チームで組成していくことになります。それに、Microservice PlatformチームやIDPチームなど、マイクロサービスに関連した業務を行うチームも以前に比べて増えています。そのなかで、Architectチームは仕組みをつくって問題解決することと、アーキテクチャそのものを考える役割へと自然に分かれていったんです。

@kazegusuri「今までとは違うことをやってほしい」

@kazegusuri：そして、Engineering ProductivityとArchitectの2チームに分離。前者は@zoncoenさん、後者では@yuki.itoさんがテックリードを担当しています。僕にはいろいろリードする役割がありましたけれど、いちソフトウェアエンジニアに戻りました。あとは2人でチームをどうしていくのか、何をつくっていくのかを考えてほしいと思っています！

@zoncoen：引き継ぎのとき、@kazegusuriさんに「今までとは違うことをやってほしい」と言われました。この言葉の意味を、改めて教えてほしいです！

@kazegusuri：これまで、メルペイのアーキテクチャはほぼ僕1人で考え、決定してきたところがあります。それが良かったのか、悪かったのか…まだ答えはわかりません。メルペイ自体もリリースして3年以上経つので、そろそろ自分以外のメンバーが決定権を持ち、進めたほうがいい。@zoncoenさんも@yuki.itoさんも、これまで同じチームのメンバーとして一緒に働いてきたのでどんな人なのか、考えを持っているのかよくわかっています。だからこそ、僕とは違うやり方でお願いしたいと思ったんです。

逆に僕からも聞きたいことがあります。@zoncoenさんはいちソフトウェアエンジニアとしてごりごりと開発をしていたじゃないですか？そこからチームを取りまとめる役割になるわけですが、今何を感じています？

@zoncoen：前提として、僕も@kazegusuriさんと同じく、Architectチームに2つの役割ができていると感じていました。だから、今回のようにチームが2つに分かれることには賛成でしたね。

そして、前々から@kazegusuriさんの課題発見力はすごいと思っていました。ただ、僕も含めて他メンバーも同じレベルで行うにはハードルがある。そこで、今後は個人に頼るスタイルだけではなく、チームみんなで課題を見つけられるような工夫ができるようにしたいんです。例えば、他チームで起こったインシデントから共通の課題をうまく見つけ出す取り組みなど、すぐに求められる対応はもちろん、少し先回りして動いておくような取り組みにも手を広げたりしていきたいですね。

@kazegusuri：「先回りしたい」は同感です。Architectチームで担当してきた業務には感覚的なものが多く、他メンバーから「なぜ？」と聞かれてもうまく返せなくて困ることもありました。説明時の再現性を高めるのが難しいと言いますか…。

@zoncoen：だからこそ、さらに再現性を上げていきたいんです。僕だけでなく、多くのメンバーが@kazegusuriさんに感謝しているのは、「なぜ？」と思ったことを質問すると納得するまでしっかり説明してくれたこと。これは本当にありがたかった。僕はArchitectチームにいたころから@kazegusuriさんと一緒なので、そういった時間が長くもらえていて、おかげでニュアンスを掴むことができました。今度は、僕がその役割を引き継ぐ番です。

社内SaaS的なものをここまでつくり込めるチームはほかにない

@kazegusuri：Architectチームの採用は難しくて…。アーキテクチャ観点での問題解決が求められるし、実際に手を動かすことも多いですし。そういったことができる人を探すのは至難の業なんですよね。でも、僕らとしては仲間を増やさないと開発をスケールできない。2チームに分けた理由の1つは、こうした採用での課題を解決するためでもありました。

@zoncoen：2チームに分かれることで役割がより明確化しました。そういう意味では、採用関連のメッセージも伝えやすくなりましたね。@kazegusuriさんは、どんな人がEngineering ProductivityやArchitectチームに合っていると思いますか？

@kazegusuri：社内SaaS的なものをここまでつくり込めるポジションは社内でもそうそうないです。そういう意味では、社内向けサービスをつくること自体が好きな人は相性がいいチームだと思います。

@zoncoen：誰かからリクエストされてつくるより、「こういう便利なものをつくったので、使いたい人は使ってください」のスタンスのほうが大きいですよね。実際に使うメンバーのことを考え、PDCAを回していける人も相性が良さそうです。すべてに言えることですが、つくって終わりじゃないので。

@kazegusuri：賛成です。「つくったから、あとはよろしく」ではなく、各チームに導入してもらうところもセットで考えることは大事。それは、2チームに分かれても変わらずに続くのだと願っています。