エンジニアと立ち話。Vol.47 @sinmetal, @vvakame, @orfeonjp, @apstndb（メルペイSolutionsチーム）ちょっとお話いいですか？

メルカリグループで働くソフトウェアエンジニアに、ちょこっとお話を聞いていく本シリーズ。第47回は、メルペイSolutionsチームの@sinmetalと@vvakame、@orfeon（Twitter名は@orfeonjp）、@apstndbの4名が登場します。

シリーズ過去最多人数で立ち話するのは、まさにメルペイSolutionsチームの実態について！です。

彼らのミッションは「社内を横断し、技術課題を解決する」。そのルーツを辿ってみると、そこにあったのはメルカリのグループ会社だった「ソウゾウ」。今回の立ち話は、Solutionsチーム誕生の経緯、脈々と受け継がれているものなどを探りました。聞き手は、メルペイVP of Engineeringの@hidekです。

領域ごとのエキスパートが集まったチーム！

@hidek：Solutionsチームのみなさーん、MTGしますよー！集合っ！！

@vvakame・@sinmetal・@apstndb・@orfeon：はい！

@hidek：…と見せかけて、ちょっとお話いいですか？

@vvakame：なるほど、これはメルカンですね。そして「エンジニアと立ち話」シリーズだから、このあと自己紹介が続くとみました。自己紹介はあとになるほどハードルが上がりそう！だから、先に名乗ります！@vvakameと申します！ニックネームのように思われますが、本名が「若命（わかめ）」なので、実はそのままなんです。担当領域はライブラリやフレームワーク。GoやTypeScriptなどが得意です。

@sinmetal：先に名乗っちゃうのズルい！僕は、@sinmetalと言います。担当領域はGoogle Cloud Platform（以下GCP）です。入社当時はAppEngineを見ていて、最近は、Google Cloud Spanner（以下Spanner）を担当することが増えつつあります。

@orfeon：僕の名前、読み方がわからない人も多いのですが（笑）。@orfeon（オルフェオン）と読みます。担当はGCPのデータ周り。加工したり、それを活用したパイプラインをつくったりして、データを移動できるパーツを開発しています。そう言えば僕、当初はソウゾウに入社する予定でした。二次面接まではソウゾウで話が進んでいたのですが、最終面接でいきなり「メルペイです」と言われて。

@hidek：えっ！

@orfeon：少し不安でしたが、結果的にはよかったです（笑）。

@apstndb：@apstndbと申します。名前はOSI参照モデルの各層をもじったものです。担当領域はGCP全般で、それに関連するところにはほぼ首を突っ込んでいる気がします。ちなみに、入社したのが2020年1月なので5ヶ月経ったくらいですね。よろしくお願いします！

誕生当初は技術的サポートがおもなミッションだった

@hidek：今日は「そもそもSolutionsチームとはなんぞや？」を明らかにしたくて、みなさんにご登場いただきました。そして、立ち話シリーズ過去最多人数の可能性があります！

@vvakame：リモートで話しているから、みんな座ってますけどね！

@hidek：そうね！では、さっそくですが、Solutionsチームのミッションは「社内を横断し、技術課題を解決する」です。実際には、技術課題の解決のほか、知見共有やDX向上などしています。このチームは、僕がメルペイに入社する前からあったと思うのですが、誕生の経緯は何だったのでしょうか？

@sinmetal：ここは、このなかで一番古株な@vvakameさんに…。

@vvakame：ちょっと！僕ら、ほぼ同期でしょ！（笑）。僕は2017年10月入社ですが、@sinmetalさんより社員番号が1つ若いだけです。

@vvakame：では改めてお話しすると、僕と@sinmetalさんが当初入社したのは、ソウゾウでした。ソウゾウは、新規事業をメインとした会社。そのため、新しい技術もどんどん取り入れていくスタンス。しかし、ソウゾウにいるみんなが新しい技術を熟知しているわけじゃない。でも、プロダクトをつくらなくちゃいけない。そこで、技術サポートに特化したチームをつくったんです。それが、Solutionsチームでした。@sinmetalさん、補足あれば。

@sinmetal：加えて言うと、ソウゾウではGCPを使い倒したいけれど、わかる人がいなかったんです。当時、僕や@vvakameさんは前職を含めてGCPに長く関わっていた経歴があり、関連コミュニティでの登壇経験もありました。その流れから、サポート役を任命されたのです。

@hidek：メルカリでは基本的にオンプレミスで、自社の開発環境内で管理・運営していましたよね。ところが、ソウゾウでは初めからGoogleのApp Engineで開発を行おうとしていたということですか？

@sinmetal：先ほど@vvakameさんも話していましたが、ソウゾウは新規事業をメインとした会社。どんどんサービスをつくり出せる環境が必要でした。でも、インフラ系ができるメンバーがいなかったんです。そのため、App Engineを使った構成を選んでいました。

@vvakame：あと、@tenntennさんのようなGoのエキスパートがいたことも大きかったですね。そして、メルペイへ異動。メルペイはソウゾウからの流れがあり、Goを使っていました。元ソウゾウメンバーも多かったので、チームごと移りました。

技術課題解決と同時に、問題提起もする

@hidek：リリースするまでの開発はどうでしたか？メルペイとしては、初めてSpannerを使った開発をしていたわけですが？

@sinmetal：そもそも、Spanner自体が新しい製品です。僕も初めて使うので、試行錯誤しました。ちなみに「Spannerを使おう」とGo Boldに決断したのは@sowawaさん（メルペイCTO）です。新しい技術で大事なデータを扱う意味では慎重になるべきシーンでしたが、その決断が結果的によかった。

@hidek：当時は事例もなかったし、メルペイは決済サービスだし。僕も、あの決断はGo Boldだなと思いました。GCPに関わるみなさんも、そう感じていたんですね。

@sinmetal：DB（データベース）の候補としては、MySQLをGoogle Compute Engineにインストールして自前で運用することも検討されましたが、DBA（データベース管理者）が社内にいなかったため、外部ベンダーを頼ることが必要になりそうでした。ただ、マイクロサービスの各チームがDBを管理できるのが理想なので、悩んでいた感じですね。Spannerを最終的に選択してよかったですが、Client Library起因の問題はけっこう多かった。僕自身もこれまで運用したことがない規模感のものを動かしているので、問題の切り分けが難しかった記憶があります。あと、@vvakameさんへ無茶ぶりもあったようです。

@vvakame：ありましたね。リリース2〜3ヶ月前にデータ暗号化のトラブルがあったんです。急いで別のものに変更することになり、さまざまな調査をした結果、全部自作するということで、HashiCorp社のVaultを採用する方針をたてました。そして、SRE（Site Reliability Engineering）チームに契約をすすめてもらったのです。あわせて、Vault用のフロントエンドライブラリを僕が作成。あれは大変でしたね。今でも、サービス間での連携で困ることがあるので、問題を見つけ次第、担当チームに伝えています。

@hidek：Solutionsチームは課題解決と同時に、問題提起もする立ち位置です。@orfeonさんと@apstndbさんは、今はどういったことをしているんですか？

@orfeon：メルペイはリリース後、さまざまなマイクロサービスから多種大量のデータが蓄積され続けています。それに伴って蓄積されたデータを活用したい人も増えつつあります。でも、センシティブなデータを含む各種DBから、ほしいものだけを安全に取り出して加工する処理を、活用目的に合わせて個別につくるのは無駄が大きいと思いました。そこで、ほしいデータを簡単に取り出して加工するパイプラインを、社内メンバーみんなが使える共用部品として提供しています。

@hidek：それはいい！

@orfeon：これまでは、こうしたパイプラインを要望や入力、出力形式ごとに用意していました。最近では、Dataflow Flex Templateを使うとよりさまざまな処理を共通化したパーツとして提供できそうなので、今Qはこの整備に取り組んでいきたいです。

@apstndb：僕の方では、コスト削減を進めています。これまではリリースを優先していたので、コストが可視化できておらず、現場で意識できていないところがありました。まずは、コストを意識できるようにし、削れるところから削っています。

@hidek：データを適切に取り出すための仕組み化も、コスト削減も、技術に対するスペシャリティがあるからできるんですよね。

Solutionsチームは、ソウゾウ時代の大事な財産

@hidek：僕としては、Solutionsチームには今後も社内の技術的課題をなめらかに解決してほしいと思っています。みなさんとしては、今後やりたい領域などありますか？

@sinmetal：教育系がおざなりになりつつあるので、もう少し力を入れたいと思っています。僕らが手を動かすことで解決できる範囲は限られています。でも、みんなが技術をわかっていれば、解決できる範囲は一気に広がる。教育には時間をかける必要があるので、今からじわじわ進めていきたいです。

@orfeon：そうですね。先日、僕も非エンジニア向けにSQLの講習をやってみました。基本的なSQLを使えるだけでも、ちょっとした調査など業務で活用できる範囲が広がりそうだとわかり、非エンジニアでも技術を使える人を増やすのはコスパが高いと思いました。

@hidek：@orfeonさん自身のやりたいことは？

@orfeon：引き続き、データ周りの整備のため、これまで以上に社内に蓄積された多種大量なデータの加工や移動を、柔軟かつ簡単に扱えるツールを提供していきたいですね。メルペイでは、CSメンバーがSQLを使ってお問い合わせ内容の原因追求をしていたりします。そこをもっと仕組み化して、今以上に早く原因がわかるようにできたらいいなと思っています。あとは、GCPにはAutoMLなどのML（Machine Learning）を便利に使えるサービスがあるので、ノウハウを溜めて非エンジニアも含む社内メンバーにこうしたサービスを使ってもらえるよう紹介していきたいです。

@vvakame：僕は「外に出す」を意識していろいろ進めたいですね。例えば、メルペイは共通のプラットフォームで開発していますが、他社と連携するものとしてはまだ弱い。そこを、僕らが何かしらいい感じに露出できるようにしたいです。もう1つ、個人的には他チームのコードに触れる機会があまりないことも気になっています。もっとPull-Req（プルリク）を送り合うようなことがあってもいいので、このあたりも何かしたいですね。

@hidek：Pull-Reqに関しては、Solutionsチームの立ち位置だからこそ、声をかけやすそうですね。

@apstndb：僕は、他のチームとの連携を明確にしていきたいです。現時点で、アーキテクトに関してはSREやプラットフォームチームなどが実行責任を持っています。開発チームと実行責任者との間でこぼれてしまっているものがあるので、それを拾って担当チームに渡せるように整備したい。

@hidek：例えば？

@apstndb：Spannerクライアントは、バージョンを上げるとサービスへの速度面の影響が大きい場合があります。だから、プロダクト開発チームは新しいものへ容易に乗り換えられない。それを解決するために、すべての差分を確認し、どれくらいの影響がありそうかを資料にまとめて共有。そうすることで、何を検証すべきかを明示しようとしています。

@hidek：なるほど！みなさんが話していることは、プロダクト開発と同時に進めるのはリソース的に難しいものばかりです。そういう意味では、別腹的にSolutionsチームが存在していることは、ソウゾウ時代からの大事な財産ですね。