メルペイCTOの曾川 景介とメルペイアーキテクトエンジニアの伊藤 雄貴が対談。その時の様子をお届けします！
- メルペイCTO x アーキテクトエンジニア対談 1/3 〜注目の技術〜
- メルペイCTO x アーキテクトエンジニア対談 2/3 〜伊藤のキャリアとメルペイアーキテクトチームについて〜
- メルペイCTO x アーキテクトエンジニア対談 3/3 〜メルコインのアーキテクトについて〜
（旧）ソウゾウでIDPの開発を経て、メルペイへ
◇sowawa：
それでは、次は伊藤さんのキャリアについて話していきましょう。
伊藤さんはアーキテクトチームで、メルペイにおけるマイクロサービス間の連携だったりとか、マイクロサービス自体を一つ一つどう設計するか、という課題に当たってもらっています。
他にも、マイクロサービス同士をどうやったらうまく協調して動かせるか、ただサービスを開発して動かすだけでなく前回の最後のお話のような問題だったり、自分の参照先のマイクロサービスが壊れているとか、ちゃんとレスポンスを返さないとか…そこも含めてどうするかみたいなことを考えてくれているのがアーキテクトチームです。
そういう意味で『Architect（アーキテクト）』は、いわゆるマイクロサービスの周辺にある技術開発、もちろん自社で全部開発しているわけではなくてかなりの部分が外で使われている技術を使うのですが、そのような技術をサーベイして自分たちのクラスタに適用していくようなことも考えてくれています。
伊藤さんが入った当初は、実際にアーキテクトの領域をやることを目的にメルペイというか、メルカリ、ソウゾウに来たわけじゃないと思うので、そこをちょっと話しましょう。
◆yuki.ito：
そうですね。入社時期は、2018年3月のちょうどメルペイを立ち上げていくぞ、という時期でした。そのときは実は最初はソウゾウでの採用でした。
当時のソウゾウでは「アイデンティティプラットフォーム(IDP))」をつくろうという取り組みがあって、最初はそのプロジェクトに入っていました。そのときは前職のDeNAでID関連の技術を少し触っていたこともあり、この分野はおもしろそうだなと思っていました。
そこから、アイデンティティプラットフォームをメルペイに提供する上で解決しないといけない課題が色々ある、ということでメルペイ立ち上げのタイミングで加盟店さま・パートナーさまが使って下さる管理ツール（例えば加盟店の方がログインしてメルペイでの売上を見られるような）を開発するチームのテックリードとして、2018年3月ぐらいから1年間、マイクロサービスをガリガリ開発していました。メルペイでのお仕事はこれが最初ですね。
1年間ビジネスドメインのマイクロサービスをテックリードとして開発していた経験は現在も広く活かせています。例えば、メルペイは今ではほぼすべてのマイクロサービスが「Cloud Spanner」というGoogle Cloudのマネージドデータベースを使っているんですけど、当時はまだデータベース選定で標準みたいなものが決まっていませんでした。自分がわりと最初のほうでCloud Spannerを選定したんですが、そのあとほかのマイクロサービスもCloud Spannerでつくっていく段階で、例えば「スキーママイグレーションツールが必要だよね」という課題がでてきたりしました。そこで自分がマイグレーションツールを開発して社内に広めていきました。
そのような動き自体がおもしろいし、なにより自分がバックエンド開発で感じた課題感も、組織横断的な課題もまだまだたくさんあると思っていました。その課題の解決は技術的にかなりおもしろそうでチャレンジングだなと思っていたので、今でいう『アーキテクトチーム』みたいなところに行きたいなと思うようになった、という感じですね。
◇sowawa：
なるほど。ありがたいというか、自分で行きたいと思うようになってくれたというのがすごくうれしくて（笑）
アーキテクトチームって最初は、kazegusuriさんとメルペイの中でマイクロサービスだけだと解決できなかったり、たくさんのマイクロサービスを一緒に動かしていくために必要なこととかを、それこそ一つ一つのクオリティーだったりをどう上げていくかみたいなことを考えて始めた活動なんですね。
もちろん、各チームの中である程度解決してもらうことを前提としていたんだけど、どうしても難しい技術課題だったりとか、すべてのマイクロサービスで使うような共通のものの提供というのは正直できていなかった。そういう状況の中でアーキテクトチームを始めたという経緯がありました。そこの部分に興味を持ってくれて来てくれたというのは、今、ここで聞いてすごくうれしい話ですね（笑）
◆yuki.ito：
まさに、そういう組織横断的な課題は横断しているがゆえの難しさがあって、ちゃんと汎用的な課題としてしっかり抽出して組織全体に適用していくみたいなところは、抽出過程でも難しかったり単純に技術的な難易度が高かったりもします。そこが個人的にはチャレンジング、かつ、おもしろいし、成長の機会もかなり大きいのでまさに今やりたいなと思ってアーキテクトチームに異動させてもらった、という感じですね。
◇sowawa：
ありがとうございます。Envoyやそのコントロールプレーンがおもしろいね、という話をしてくれていたりとか、技術に関して本当に好きだというところは明確だったと思うんですね。
それと同時に伊藤さんと継続的に話していて感じるのは、会社のサービスの状況とか将来こういうことをやるからこういうことが必要になりそう、みたいなところを見立てる力は最初に比べると飛躍的に上がったと感じています。
それはもちろん経験みたいなものもあるし、アーキテクトチームは少数精鋭で人数が少ないチームなので、一人一人が一つの領域をオーナーシップを持ってやっていかないと回らないみたいな状態だったというのもあるとおもいます。そこで責任感を持って取り組んでくれたことが、今振り返ってみると良かったのかなと思うんですけどその辺の振り返りはどのように思っていますか。
◆yuki.ito：
当初はまず、自分が直接経験した課題の解決みたいなところが大事かなと思っていました。例えば「Cloud Spanner」や「データベース」を使う上での困ったことの解決とか、QA部分での柔軟性のなさによる問題の解決とか、自分が感じていた課題を組織横断的に解決することがスタートでした。
その後は、「どのようなアーキテクトが組織に対して価値を出せるのか」を自分なりに模索するようになりました。今では自分の経験だけではなくて、エンジニアリングに限定しない様々なチームの様々な課題を吸い出し、会社としてどうしていくべきか、という高い視点を意識して動くようになったと思っています。
「どのようなアーキテクトが組織に対して価値を出せるのか」を考える
◆yuki.ito：
最近読んでいる、『The Software Architect Elevator』という本が「アーキテクトはどうあるべきか」というところにアプローチしていて良い本だなと思っています。この本のなかでは、アーキテクトは会社の様々なステークホルダー、例えばそれは経営も含んでいますし、コンプライアンスやリーガルのチームなど、いわゆる非技術的な部分で持っている課題も含めて咀嚼して、最終的に各エンジニアリングチームと協力してどのように技術的に解決していくかを考えるようなロールである、と語られています。例えば、認証・認可は技術的にも考えることが多いですが、コンプライアンスなどにも直結してくると思うんですね。
◇sowawa：
そうですね。（認証・認可が）ハックされたらやばいからね（笑）。
◆yuki.ito：
課題を解決するうえで、組織横断的な動きができると良いかなと思っています。様々なチームと会話ができて、かつ、会社の今後を考えて技術的な決断をしていくような動きができるアーキテクトというのを意識するようになりました。今、自分がやれているかはちょっと分からないんですけど（笑）。
◇sowawa：
いやいや、僕から見たらかなりやっていると思うよ（笑）。
最初のころに僕と1on1をかなりの頻度でしていたからよく覚えています。会社として達成したいマイルストーンをとても意識して取り組んでくれているのがよく伝わって、すごいなって。僕以上にすごい人がいるから、僕は何もしなくてもいいんじゃないかと思えるぐらい本当にすばらしい動きをしていると思います。
今回はこういう話だから例を出して話したいのですが、伊藤さんが最初に来てくれたときから取り組んでくれた課題に、Istioの導入や、それを用いたQA環境の改善などがありました。
当時はメルカリグループとして見たときには、QA環境、テスト用の環境が充実していませんでした。マイクロサービス化していない部分もたくさんあったし、そういったものが混在する中で、先にマイクロサービスを前提としたメルペイというサービスが生まれました。
例えば「マイクロサービスA」と「マイクロサービスB」はこのバージョンで動いていなければならない、というQA環境を考えたときに、それらをオンデマンドにうまく切り替えて使うことができなかった。けれど、Istioの導入と、その機能を利用するコンポーネントを開発することによって、柔軟なQA環境を構成することができた。これのおかげで、いろんな機能を並行して開発してリリースして、完成したものから順にリリースしていくことが可能になりました。
今言ったような仕組みを、会社自体がどうやったら早く新機能をデリバリーできるか、みたいなところの課題として捉えて伊藤さんがハンドルしてくれました。
会社のエンジニアだったり、もちろんエンドユーザーのお客さまのことも考えたりとか、あとは僕みたいな経営をやっている人もいたり、QAの人だったり、外部のパートナーさんがいたり、そういったステークホルダーの人たちがいるということをよく理解してくれていると思います。
それはもちろん、もともとそういうステークホルダーがいる加盟店というチームでプロダクトをつくっていたというところもあるけど、さらにそこのスコープだけじゃなくて全社のスコープで考えたときにこうやったほうがいい、というのを意識して動くようになったのかなと。
◆yuki.ito：
そうですね。QA環境の課題に向き合うときにも、「品質を担保したまま新機能をより早くお客様に届けられるようにしたい」というのを経営的な課題として捉えていました。
実際には自分ひとりで解決したわけではなくて、インフラレイヤで必要なことを弊社でいうマイクロサービスプラットフォームチームに働き掛けたりなど、他のチームの協力も仰ぎつつ、最終的に自分がKubernetesのコントローラーを実装して解決する、という流れでした。
また、仕組みを作って終わりにするのではなく、デベロッパーやQAのメンバーに使ってもらえるように普及させることも意識していました。メルペイのアーキテクトが大事しているミッションの1つとして、実際に「標準化して導入する」というところまでをセットでやる、というものがあります。このQAの問題が解決できたところは、アーキテクトのミッションを体現できた事例の1つかなと思います。
◇sowawa：
そうですよね。僕も当時のことをこうやって話していると思い出すんだけど、作って終わりだとまずいよね、という話はよくしていますね。仕組みを作っただけでは問題は解決しないことが多くて、その仕組みを正しく会社に導入して実際に使われることで、はじめてその仕組みの価値が発揮されるんだと思います。
僕もいろんな仕事をしてきたエンジニアの人たちを見てきているけれど、やっぱりつくることはできたとしても、それを布教して使ってもらうところまで行くというのはなかなか難しいように思います。特にエンジニア以外のステークホルダーがいるとなると、今言ったような、実際に使ってもらうフェーズみたいなものをちゃんとこなせるかが大事です。
もちろん導入する中で問題も出てくるので、トラブルシューティングもしながら広く使ってもらえる状態を目指すのは重要だし、僕の中でも伊藤さんはそこを頑張ってきたというのはすごいなと思っています。
◆yuki.ito：
ありがとうございます。まさに標準化させるところは重要なミッションだなと思っていて、標準化するに当たって使ってもらいやすくする、作った仕組みのインターフェースをどう定めるか、みたいなところはアーキテクトの力の見せどころかなと。
いかに使いやすくて、かつ、バリューを発揮できるコンポーネントなのか、どういうインターフェースで設計してつくるか、みたいなところを考えるのはおもしろいですね。
例えば先程のQAの仕組みに限らず、アーキテクトチームは全社で使っているような、Goの共通ライブラリのサポートをしていたりもするので、そういうところでもどのようにに使ってもらうかというインターフェースを考えるところは、腕の見せどころになりますね。
以上、メルペイCTO x アーキテクトエンジニア対談 2/3 〜伊藤のキャリアとメルペイアーキテクトチームについて〜編でした。
