メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第27回ではメルペイ アーキテクトチームに所属するBackendエンジニアの@zoncoenにちょこっと話を聞きました。

アーキテクトチームのミッションは、メルペイとして一貫したシステムを提供するために、全体の方針や設計を決め、必要なインフラやツールを導入し、各エンジニアに浸透させること。いわば、システム全体の「指揮者」のような役割を担うチームです。そんななか、@zoncoenが感じているミッションとは？　聞き手は本連載でお馴染み、メルペイ VP of Engineeringの@hidekです。

技術力を活かし、世の中を便利にしたくてメルペイへ！

@hidek：あ、@zoncoenさん、コーヒーが出来上がるのを待っているんですか？　今忙しいですか？　ちょっとお話、聞かせてもらえますか？　なんで@zoncoenというアカウント名なんですか？

@zoncoen：え、いいですよ。@zoncoenの由来ですか？　大した理由じゃないんですが……高校生のとき、部活の先輩から「もりぞん」と呼ばれていました。それと、Twitterのアカウントをつくるときに、たまたま「coen」というファッションブランドのショップバックが目についたので、あわせてzoncoenになりました。

@hidek：思っていたより、由来の内容が薄かった……。それでは気を取り直して、メルペイのオフィスを歩きながら@zoncoenのプロフィールを教えてください。

写真奥から@zoncoen（Backendエンジニア）、@hidek（メルペイ VP of Engineering）

@zoncoen：2018年6月に入社しました。コード払いに関わるマイクロサービスの開発チームから、今所属しているメルペイのアーキテクトチームに移りました。

@hidek：メルペイに入社する前は何をしていたのですか？

@zoncoen：2014年に新卒で入社した会社で、ライブストリーミングサービスの開発に携わっていました。その後、社員が50人ほどの会社に転職。Google AnalyticsのデータをもとにWebサイトの分析と改善提案を行うサービスで、BackendエンジニアとしてGoを使ってAPIサーバーを開発していました。

@hidek：そこからなぜメルペイへ？

@zoncoen：自分の技術力を活かして、世の中を便利にしたかったからです。決済サービスにも興味がありました。それに、自分もキャッシュレス派だったので！　またGoの勉強会で@deeeetさん（Microservices Platformチーム）と一緒になる機会があったり、@kazegusuriさん（アーキテクトチーム）から入社前にメルペイのアーキテクチャについて話をしてもらったりしたことがきっかけでした。

エンジニアリングにおける「アーキテクトチーム」とは？

@hidek：改めて聞きたいのですが、@zoncoenさんが所属するアーキテクトチームはどんな業務をしているのでしょうか。

@zoncoen：簡単に言うと、システム全体のアーキテクチャを設計したり、複数のチームに共通するような課題を技術的に解決したりするチームです。

@hidek：メルペイでは、マイクロサービスというアーキテクチャを採用しているのですが、厳密に定義されている面もあれば、ふわっとしている面もあります。なので、そのすべてを統制する「指揮者」が必要だったんです。その役割を、前述の@kazegusuriさんが担っていました。でも、たった1人ではこれだけの規模のサービスは見きれませんので、手を動かせるメンバーが必要。そこで、アーキテクトチームが組成された経緯があります。そもそも「アーキテクトチーム」そのものが、他社でもそれほど存在していないんですよね。

@zoncoen：@kazegusuriさんの存在は、とても大きいですね。

@hidek：またアーキテクトチームとしては、DX（Developer Experience）を良くする、という役割もありますよね。

@zoncoen：メルペイではデータベースにGoogle Cloud Spannerを利用しているサービスが多いのですが、Spannerにはエミュレーター（代替的に用いることができるソフトウェア）がないんです。なので、テストでもSpannerをそのまま利用しているのですが、そこでいくつか不便なところがありました。自分のチームも含め、困っている人たちがけっこういたので、それを解決するための簡単なツールをつくりました。それが他のチームでも便利に使われているのを@kazegusuriさんが見ていてくれたそうなんです。それも、アーキテクトチームに入ったきっかけの1つです。

アーキテクトとして、具体的な役割は？

@hidek：僕から見ていて、アーキテクトチームは全員で1つのミッションに向かいつつ、業務としてはメンバー一人ひとりが個別に取り組んでいる印象もあるのですが？

@zoncoen：そのイメージは合っているかもしれません。メルペイのアーキテクトチームは、チームとして1つのタスクを一緒にやることはあまりなくて、メンバーが個別に自分のタスクに取り組んでいます。もちろん、緊急度の高いものは力を合わせて優先的に取り組みます。最近だと、メルペイのサービスもリリースされたので、少し落ち着いてきました。個々人がやりたいものをピックアップして、そこから優先順位決めて取り組んでいる状態ですね。

@hidek：では、総動員して動く機会はそんなにない？

@zoncoen：いえ、フロントに立っているAPIゲートウェイの開発や運用に関しては、全員で取り組んでいますね。

@hidek：「個々人がやりたいものをピックアップして取り組んでいる」とのことですが、@zoncoenさんが最近取り組んだことは？

@zoncoen：自分が取り組んでいたことだと、E2Eテスト（End to End、Webサイトやアプリケーションが理想的に動いているかどうかのテスト）を簡単に書ける仕組みをつくりました。別のサービスに依存しているサービスの場合、そのサービス単体のテストでは気づけず、実際につないでみて問題が発覚するみたいなことがどうしてもあるんですよね。特にリリース前は、みんなでマイクロサービスを「がーっ」とつくっていたので、依存先の変更でDev環境が動かなくなって困ることもありました（笑）。そんなときにも早めに気づけるようにしたかったので、簡単に自動化できるテストの仕組みをつくったのです。

@hidek：エンジニアでも使えるテスト環境の整備的な？

@zoncoen：そうですね。YAMLでテストシナリオを書いておくと定期的にDev環境で実行して、落ちたらSlackに通知される仕組みにしました。YAMLで書けるようにしておけば、エンジニアだけでなくQA（Quality Assurance）の方にも簡単に使っていただけるんじゃないかという話もあったので。今はPostmanを使って自動化している部分もあるのですが、メルペイでのユースケースにおいてより使いやすいものを目指しました。

@hidek：なるほど。

@zoncoen：もちろんリリース前にはQAの方に確認をしてもらうんですが、エンジニアのなかには「自分でつくったサービステストについては、デグレード（ソフトウェアの品質が以前より悪くなること）などがあれば早めに気づきたい」というニーズを持つ人も多いです。なので、簡単にテストを書いてDev環境で確認できるようにし、サービスの安定性や品質を担保できるようにしました。

@hidek：マイクロサービス間のテストって大変ですよね。理想的には、たくさんリリースして、影響範囲を絞ってやっていくことですが、それだけだと品質安定させるのは難しい。

@zoncoen：そうなんです。ユニットテストなどはもちろん書いているけれど、依存しているすべてのサービスを繋げてテストするのは、時間もかかるし大変なんですよね。

@hidek：金融事業なので、プロダクトの品質に対する考えは、一段上である必要があります。一方でスケジュールに追われたりすると、「初期品質が悪い問題」が発生しがち。具体的に言うと、エンジニアがサクッとつくって「できました！　QAをお願いします」としても、実際には動きもしない問題があります。マイクロサービスにはオーナーシップが重要という考えのもとで、ユニットテストだけではなく、E2Eテストも含めて、テストコードをエンジニアも書けるようにするのはすごく理想的だと思います。あ、褒めています（笑）。

@zoncoen：ありがとうござます（笑）。各チームにQAメンバーがいたらいいのかもしれませんが、そうでない場合もあります。マイクロサービスを開発するなかで、オーナーシップを持って取り組むためにも、QAチームに確認を押し付けるようになるのは良くないと思っています。

「@kazegusuriさんが目標です！」

@hidek：今後チャレンジしたい領域は？

@zoncoen：いろいろありますが、まず直近だと、今回つくったテストの仕組みをもっと浸透させていきたいですね。多くの人に使ってもらえるように導入の支援をしていきたい。また、メルペイでは新メンバーのオンボーディングは各チームのテックリードに委ねられている部分があります。もちろん、それぞれのチームに適したオンボーディングは必要ですが、メルペイで開発していくうえでの共通の知識はあると思うので、それをハンズオン形式で学べる機会を提供できるといいなと思っています。

@hidek：マイクロサービスのアーキテクチャをやっていると、それぞれのチームで独立性があるのがいいところでもありますが、一方で情報やノウハウがチーム内で閉じてしまう面もありますよね。一定のベストプラクティスが共有されるのはいいですね。

@zoncoen：エンジニア全体のレベルを上げるというのも、アーキテクトチームで取り組みたいと思っています。

@hidek：最後に、メルペイに入って良かったところや、今後目指していきたいものステップなどあれば教えてください。

@zoncoen：声を大にして言いますが、僕は@kazegusuriさんが目標です！　知識豊富でコードのレベルも高いし、視座が高くてプロダクトのこともめちゃくちゃ考えている。@kazegusuriさんと同じように動けるようになりたいですね。

@hidek：@kazegusuriさんすごいな！

@zoncoen：あと、メルペイの魅力は、メルカリの文化を引き継いでいるのだと思いますが、とにかく風通しがいいんです。マネージャーだから偉いわけではなく「あくまでも役割である」としていて、率直に意見を交わし議論しています。エンジニアとして働くうえでも働きやすいです！

@hidek：いい話をありがとう。今日はありがとうございました！