メルカリで働くソフトウェアエンジニアにちょこっとお話を聞いていく本シリーズ。第25回では、メルペイのバックエンドエンジニアでテックリード（以下、TL）の@hamaknにちょこっと話を聞きました。聞き手はメルペイのVP of Engineeringである@hidekです。
メルペイのダッシュボードチームで、銀行接続・NFC・コード払い・クーポンなどの各機能を加盟店さまに提供するAPI開発をTLとして担当する@hamakn。そんな@hamaknを、@hidekは「TLとして期待される役割を体現しているメンバーの一人」と話します。その理由は？
お客さまが最も触れるメルペイ管理画面の開発を担当
@hidek：（@hamaknさん、まだかな……？）
@hamakn：hidekさーん！ 「エンジニアと立ち話」、よろしくお願いしますー！
@hidek：きたー！ ぜひです。さっそくですが、メルペイに入社した時期を教えてください。
@hamakn：僕がメルペイに入社したのは、2018年6月。前職ではおもに新規事業立ち上げをしていて、音楽系SNSやコミュニケーションアプリ、チラシアプリ、インシュアテック系サービスなどを開発していました。
@hidek：そこからなぜメルペイへ？
@hamakn：実は、前職からの知り合いがすでに何人か入社していて、メルペイのことは彼らから話を聞いていました。Mercari Tech Conf 2017や、メルカリのGoエンジニアたちの社内勉強会「Go Friday」にも参加し、「ビジネス的にも技術的にもおもしろそうだ」と感じたので採用選考に応募しました。そして今は、フリマアプリ「メルカリ」内にある、メルペイ管理画面全体を担当しているダッシュボードチームで、バックエンドのTLをしています。
@hamakn（メルペイ、バックエンドエンジニア）
@hidek：メルペイ管理画面は、お客さまが最も触れる部分でもありますよね。先ほど前職での新規事業を簡単に説明してもらいましたが、どれもお客さまと接点があるものばかり。もともとC向けサービスが好きだったのですか？
@hamakn：そうですね。お客さまとのやりとりがあるサービスはフィードバックが比較的わかりやすく、直接的なところが好きです。また、僕の場合は〆切がないとサボりがちなので、そういう意味では新機能やUI改善など、常に何かしらのキャンペーンを行う業務が合っていますね。
@hidek：これは……プロジェクトのアサイン成功でしたね（笑）。
1機能につき1マイクロサービス
@hidek：改めて、@hamaknさんがいるダッシュボードチームの仕事を教えてください。
@hamakn：メルペイにある銀行接続・NFC・コード払い・クーポンなどのすべての機能をお客さまへ提供するため、マイクロサービスを集約した「API」と呼ばれる層のコンポーネントを開発しています。また、ダッシュボードチームは、メルペイ管理画面のUXを改良していくミッションもあり、機能開発だけでなく、キャンペーン開始を適切なチュートリアルやガイドで伝える画面も担当しています。ここは企画者やデザイナー、エンジニアが関わる部分であり、各マイクロサービスをつなぐ部分でもあります。「あれ、繋いでみたら動かないぞ？」とならないよう、うまく連携することが求められています。
@hidek：僕はSOAのような疎結合な設計の開発経験があるのですが、ここまでしっかりとした設計でマイクロサービスの開発を行うのは初めてです。マイクロサービスのほうがコンポーネントの粒度が細かく、機能やプロジェクトとともに増えるので、API層はけっこう大変な印象があります。
@hidek（メルペイVP of Engineering）
@hamakn：金融ドメインや、メルペイが提供している機能の複雑さ、規模を考えると、どうやっても大変になります（笑）。それに、今のメルペイの規模でモノリシック的にソフトウェアを分割せずに開発を進めるのは難しいです。
@hidek：確かに。
@hamakn：今のメルペイやメルカリでは、マイクロサービスごとに担当と責務を分けることに合意し、gRPCでインターフェースを決めて……という基本ルールを守ることでうまくいっている気がしています。しかし、どこに置けばいいのか困る機能や、ビジネスの都合上、突貫でつくったものや直したものがまだ残っているところは引き続き課題ですね。そう言えば最近、同じくバックエンジニアの@foghostさんが書いた「マイクロサービスにおける決済トランザクション管理」がおもしろかったです！
@hidek：マイクロサービスの運営は、難しいところがありますよね。今のメルカリグループには、マイクロサービスでの設計が合っていると思うのですが、過度に粒度を細かくしすぎるとオーバーエンジニアリングになったり、運用が難しくなったりすることが往々にしてあります。特に初期のマイクロサービスの粒度は、気をつけたほうがいいと思っています。
@hamakn：そうですね。個人的には、足回りとなるライブラリが共通化され、単一機能の見通しがいいマイクロサービスが揃っている状態が理想だと考えています。そうすれば、ビジネス上の都合で注力するマイクロサービスが変わっても、エンジニアのオンボーディングコストをかけず、組織をうまく動かすことができるんじゃないかと考えているんです。
TLの役割は事業側と開発側の橋渡し
@hidek：入社前後でギャップなどはありましたか？
@hamakn：先に入社していた知り合いから何度か話を聞いていたので、そこまで大きなギャップはありませんでしたね。しいて言うなら、入社して驚いたのは、メルペイメンバーにメルカリ在籍経験者が思っていたより少なかったことでした。「メルカリからメルペイへ来ました！」というメンバーのほうが多いと思っていたので。
@hidek：そう言えば、当時は僕も含めてさまざまな入社者がいましたよね。
@hamakn：ですよね。でも、メルカリ在籍経験者は少ないものの、メルペイには同じカルチャーがすでに根付いていて、風通しがいいと感じました。メルペイに限らず、メルカリグループ全体がSlackでやりとりしているため、他チームのプロジェクトややりとりがオープンです。また、アーキテクチャやSRE、ソリューションといった基盤・技術に強いエンジニアが多く、ビジネス要件を達成するためのアプローチや設計に悩んだとき、気軽に質問できることも非常にありがたいですね。自分の考えや設計と、彼らの意見が異なるとき、エンジニアとして鍛えられている感じがあります。
@hidek：@hamaknさんはTLとして、開発サイドからプロジェクトを円滑に進めようとしていますよね。僕にとって@hamaknさんは、まさにTLの役割を体現しているメンバーの一人だと思っているんです。
@hamakn：それは嬉しいですね。ちょっと聞いてみたいのですが、@hidekさんはTLに対して、具体的にどういった役割を求めているのでしょうか？
@hidek：なかなか言語化が難しいところなのですが、「事業サイドと開発サイドの橋渡し的な役割」でしょうか。また、プロジェクト運営においては、プロダクトマネージャーの技術的壁打ち相手であってほしい。そして、ただ受け身になるのではなく、エンジニアとして「こうしたほうがいい」と意見を伝えられていることがベストです。そうすることで、エンジニアのプロダクトへのオーナーシップも上がりますし、受託的な仕事もなくなっていく。エンジニアにそういったマインドを持ってもらうためにも、TLには率先して前へ出ていく動きをしてほしいと思っています。
@hamakn：TLは「テックをリードする」という字面になるので、新しい技術を生み出したり、最新の技術を導入するロールのように感じられたりするところがあります。名前だけ見てみると誤解されがちなので、業界の一般的な定義にあわせて変えてもいいかもしれませんね（笑）。
@hidek：そうですね（笑）。
@hamakn：事業サイドの橋渡し役になり、さらに要求を達成するための設計づくりは、まさにTLの役割です。ビジネスドメインや分析結果を理解・把握し、プロダクトマネージャーのアイデアも聞きつつ「技術的な都合ではこうしたい」「ここは変更可能にしたい、割り切りたい」「あのチームと調整が必要なので話し合います」とやりとりして、いいサービスとそれを支えるソフトウェアをつくっていきたい。それに、そういったことができるメンバーがもっと集まり、楽しく開発できるようにしたいですね。
「自分の足を使って動けるTLでありたい」
@hidek：@hamaknさんが今後、メルペイでやりたいことは何ですか？
@hamakn：入社時の自己紹介で「今度こそサービスを当てて成仏したい?」とコメントしたのですが、その想いは変わっていないですね。
@hidek：成仏（笑）。
@hamakn：これは僕の積年の想いでもありますので（笑）。そのための自分の役割は、企画と技術の橋渡し役として、自分の足を使って課題を解決できるエンジニアであることだと思っています。お客さまに「メルペイ、いいね！」と言ってもらえて、さらには長く使ってもらえるプロダクトにしていきたいです。成仏するのはまだ先ですね！！
@hidek：いい話だ！ 今日はありがとうございました！
関連募集要項
Share
