求人情報には必須要件・歓迎要件・求める人物像などが記載されていますが…それって、もう少しくわしく言うとどんな人？

そこで誕生したのが、採用メンバーが“仲間募集中”なチームのマネージャーに根掘り葉掘り質問していくシリーズ企画「#今メルペイが一緒に働きたい仲間」！今回は、メルペイArchitectチームのエンジニアリングマネージャーである主森 理（@osamingo）と、チーム発足当時からメンバーとして働く佐野正浩（@kazegusuri）が登場します。

Architectチームのミッション、組織の強み、今後のビジョンを明かしました。聞き手は、メルペイHRBPの@Nozomiです。

DXを向上し、メルペイ全体の底上げを担うことがミッション

ーそもそも、Architectチームとはどういうチームなのかを教えてもらえますか？いわゆるBackendチームとは違うんですよね？

@osamingo：もともとは、@kazegusuriさんが1人で立ち上げたチームでした。最初はマイクロサービスアーキテクチャとしてのメルペイ、つまりメルペイの一番最初のフェーズから開発を担当。その後、全体的な決めごとや仕組みをつくるためにArchitectチームになり、徐々に人数が増え、現在に至ります。なので、Architectチームの役割は、プロダクトのフェーズによって変化しているんです。

今は「事業成長を支えるシームレスで信頼性の高いアーキテクチャを設計し、能動的にエンジニアリングを先導する」というビジョンを掲げ、業務に取り組んでいます。ピンポイントで問題解決に取り組むこともありますが、基本的にはメルペイ全体に関わる部分ですね。

主森 理（@osamingo）

ーBackendチームとの違いは？

@osamingo：Backendチームは、メルペイというプロダクトやお客さまにフォーカスしています。一方で、Architectチームはお客さまを意識しつつ、社内のエンジニアにフォーカスすることが多いですね。例えば、ペイメントプラットフォーム開発を担当するBackendエンジニアは、「資金移動口座」と呼ばれるお客さまのお金をお預かりする口座の履歴管理、スマート払いの残高管理を担当。お客さまにとって「サービスの価値」を感じやすい部分を担っています。「お客さまへサービス価値を提供する」に関してはArchitectチームも同じですが、同時にDX（デベロッパーエクスペリエンス、開発者体験）を向上させ、全体の底上げを進める役割もあります。

メルカリにもArchitectチームはありますが、その違いは@kazegusuriさんから説明してもらいます！

ーお願いします！

@kazegusuri：しいて挙げるとするならば、方針に関しては少し異なるかもしれませんね。

メルカリは各チームが独立し、自分たちで開発・運用できる状態にしたいというカルチャーが強く表れているように感じています。だから、メルカリArchitectチームは、ガイドラインやベストプラティクスをつくるなど、整備的な役割が期待されることも多いです。メルペイArchitectチームでも同じ役割がありつつ、各メンバーがBackendチームと協力して一緒に目的を達成していくカルチャーが根付いています。組織規模も違うので、動き方も当然変わってくるわけです。

「Backendチームならテックリード級」のメンバーが集まっている？

ーArchitectチームは今、@osamingoさんがマネージャー、メンバーが@kazegusuriさんをはじめとする5名で構成されています。チームの強みや、ご自身のモチベーションについて教えてください。

@osamingo：@kazegusuriさんが代表されるように、圧倒的に個人の力が強いことですね。マネージャーとして信頼しきっています。僕自身はメンバーと比較して技術レベルは高くないので、彼らが能力を発揮できるようにブロッカーを排除したり、他チームとのコミュニケーションをサポートしたり…といった業務に専念しています。

@kazegusuri：確かに、Architectチームは優秀なメンバーが多いですね。他のBackendチームにいればテックリードになれるような人ばかりで、こちらから特に何も言わなくても「こういうことをやるべき」と自ら考え行動してくれるのですごく助かっています。

技術的な相談もしやすく「こういう新しい技術ができたけど、どうやったらメルペイに適用できるか」みたいな話で盛り上がることもあります。幅広い技術を見ているメンバーばかりなので、ある意味、理想的なチームと言えるのではないでしょうか。

佐野正浩（@kazegusuri）

ーチームでワイワイしながら「試してみようか」みたいなことになるんですか？

@kazegusuri：“ワイワイ”はしていないですね（笑）。そして「試してみようか」よりも「試してみたんだけど…」という事後報告が多いかもしれません。

個人的なモチベーションという意味では、Backendチームにいるテックリードの存在は大きいですね。彼らも非常に優秀で、自分もある程度ドメインに対して理解しているんですが、それ以上に知識がある。そのうえ「今後こういうことをやっていきたい」というビジョンのある人が多いので、彼らと議論しながらプロダクトをつくっていくことはすごくワクワクします。

課題は、メンバーの得意不得意の領域に偏りがあることですね。あまり手を打ってこなかった部分ではあるので、今後はマネージャーと一緒に考えていくべきポイントだと思っています。また、メルペイArchitectチームは他チームと連携することもあるのですが、高いレベルのコミュニケーション力と知識が求められます。例えば決済の仕組みや認証認可といった専門領域を担当するチームとの議論なんかもありますし。

@osamingo：ですね。そういうシーンに直面したとき「楽しい」と捉えられる人が向いている仕事かもしれません。フィンテックドメインのArchitectなので、技術的・法律的なところ以外でも、金融業界の慣習みたいなものもキャッチアップしておく必要がある。+αでソウゾウやメルコインとの連携も始まったので「メルペイというプロダクトをどう拡張させていくか」はArchitectチームの大きなチャレンジだと思います。

チーム発足時から重視する「プロダクトファースト」

ーArchitectチームはメンバーを募集していますが、どういった方と働きたいですか？もしくはどういった方であれば活躍できると思いますか？

@kazegusuri：Architectチームを立ち上げたときから重視しているのが「プロダクトファースト」。つまり「プロダクトを成長させるために技術があるべき」が大前提です。「技術のための技術をつくらない」というか。

大事なのは、将来を踏まえて考えられること。そして、考えるだけではなく行動して実現させられる能力を持っていること。ミニマムでいうと、この2つですね。

@osamingo：僕らの仕事はアーキテクトやプラットフォーム寄りですが、これはすべて、@kazegusuriさんが話してくれたようにプロダクトのためだし、その先にはビジネス、そしてエンドユーザーのお客さまや加盟店さま、パートナーシップを結んでくれた企業さまがいます。そのことを念頭に置いていただきたいですね。

そして、僕らの存在意義は、技術的な視点で開発者に対してクオリティの高いものを提供していくこと。そのためには、技術的なビジョンや「こうあるべき」という自分の考えをある程度の説明ができ、かつ実行できる能力が必要です。

@kazegusuri：同じことを言ってますね（笑）。

@osamingo：だって、一番大切なことですから（笑）。チームには、これまで積み重ねてきた「自分たちがやっていくんだ」というカルチャーが根付いている。だから、同じ志の方であればおもしろく働けると思います。

あと、すごく安直な言い方をすると「コミュニケーション能力」ですね。先ほどから言っているように、メルペイBackendチームと関わることも多いです。「コミュニケーション能力」とは言え、単に意思疎通を図るだけではありません。ディスカッションを通じて、提案したり、課題を発見したり、落とし所を見つけたりという意味での「コミュニケーション能力」は大いに活かせます。

@kazegusuri：最後に1つ。パッションは高めでいいかもしれません。メルカリもメルペイもある程度デファクトスタンダードになっている部分はありますが、今の形が正解とも思えなくて。「自分はこっちの方がいいと思う」「もっとこういうふうにしたい」とぶつかってくるようなパッションをお持ちの方でしたら、きっと楽しくなると思います。

「Everything as Code」「Documentation and Visualization」「Zero Trust Security」

ーArchitectチームにジョインしたら、どんなところから関わることになるのでしょうか？

@kazegusuri：Architectチームには、3つのObjectives（目的）があります。それが「Everything as Code」「Documentation and Visualization」「Zero Trust Security」。

@kazegusuri：まずは「Everything as Code」。今まではマイクロサービスアーキテクチャとして「こうすべき」となったときに自分でソースコードを触って修正することも不可能ではありませんでした。ただ、だんだん規模が拡大してきたので、外部から観測可能にしたんです。その状態をコード的に定義することで、マイクロサービスアーキテクチャのアプリケーションも中身のソースコードまで見なくてもある程度外から定義できるようになる。そういう状態を目指していきたいという意味が込められています。

続いて「Documentation and Visualization」。コード化することで、マイクロサービスアーキテクチャの状態を機械的に判断できるようになる。今までは「本来、このマイクロサービスはこういう振る舞いをします」というドキュメントを書かなければいけなかったのに、ドキュメンテーションの自動化が可能となりました。さらに、そこから得られるメトリクスみたいなものを自動的に取得して可視化することができるようになるわけです。マイクロサービスアーキテクチャ全体の状態を把握するためにドキュメンテーションとビジュアライゼーションを手動でつくるのではなく、自動的につくることを目的にしています。

最後の「Zero Trust Security」。ちょっと意味合いが違うのですが、少なくともメルペイという決済金融サービスを扱っている以上、セキュリティはどんなに上げても上げ足りないことはない。より強固な状態にするために「Zero Trust」で、安全にしていきたいと考えています。

@osamingo：紹介した3つは抽象的ですが、ネットワーク周りだったり、認証認可周りだったり…と、実は具体的に動き始めています。メルカリMicroservicePlatformチームと連携して、仕組み化を進めているんです。

ーメルカリ含めて他チームとの連携は多いんですよね？

@osamingo：そうですね。半分以上は、他チームとの連携に関する業務です。もちろん大変なこともありますが、より良いものをつくるためにはネガティブに捉える必要はないです。

@kazegusuri：会社としてもプロダクトをただつくるだけよりも、品質を高くつくることを重視しているので、仕事はしやすいと思いますよ。

候補者の方へ、ひと言！

ーでは、最後に候補者の方にひと言お願いします。

@kazegusuri：メルペイは決済金融事業をやっていくなかで求められるレベルは高いと思います。ちょっとハードに聞こえるかもしれませんが、プレッシャーを跳ね除けて、技術を実現するために考えて行動できるところがメルペイの面白いところ。そのあたりの全体像を見ながら働けるArchitectチームはおすすめです。

@osamingo：フィンテック業界はレッドオーシャンだし、世論にも晒されがち。そのなかでインターネットと金融業界をブリッジしていくことにおもしろさがあると思います。技術的にまだまだやれることはあるので、メルカリ・メルペイが市場の主力プレイヤーであり続けるために力を貸してほしいですね。

ーArchitectチームと一緒に働いてみたい方からのご応募お待ちしております。今日はありがとうございました！