求人情報には、必須・歓迎条件、求める人物像が記載されているわけですけれど…それって、もう少しくわしく言うとどんな人?
そこで誕生したのが、メルカリ・メルペイで採用に関わるメンバーが“仲間募集中”なチームのマネージャーに根堀り葉掘り質問していくシリーズ企画「#今メルカリが一緒に働きたい仲間」!
今回登場するのは、メルカリグループの3本柱の1つである「米国事業」としてUS版メルカリを日本オフィスから開発するUS@Tokyoのデータエンジニアです。
米国事業を行うメルカリUSのオフィスがあるのは、パロアルト。しかし、データエンジニアはパロアルトだけでなく、ボストン、日本の3拠点で連携しながら開発しています。
そこで本記事では、US版メルカリのデータエンジニアである@ryotaと@hatone、@sudarsanにインタビュー。国籍も言葉も違う彼らが「一緒に働きたい!」と思う人物像とは?聞き手は、US@Tokyoのマネージャーである@kumonです。
※撮影時のみ、マスクを外しています。
この記事に登場する人
-
加藤亮太(Ryota Katoh、@ryota)2015年株式会社Origamiへ入社。データエンジニアリングチームの立ち上げ、マネージャーを担う。同社のメルカリグループ参画により、2020年3月にメルカリグループへ入社。2020年6月よりUS@Tokyoに転籍し現職。Slack名は@ryota。 -
大島孝子(Takako Ohshima、@hatone)2017年2月にメルカリUSへジョイン。CS(カスタマーサポート)業務での「不正出品を減らすにはどうすればいいのか」「CXを向上するために、ユーザーコミニケーションをどのように最適化するか」を技術で解決するCXIチームを経て、現在はUSのMachine Learning & Data Engineering Teamに所属。Slack名は@hatone。 -
名前(Namae)スタートアップから大企業までの様々な環境で分散システムおよびデータパイプラインを構築。2019年よりメルカリUS パロアルトオフィスに勤務し、ナレッジグラフシステムやイベントストリーミングシステムの開発を担当。休日には、ハイキングやサイクリング、お菓子作りなどを楽しんでいる。Slack名は@sudarsan。 -
山口拓真(Takuma Yamaguchi、@kumon)学生時代より、パターン認識・機械学習の研究に従事。博士(工学)。コンピュータビジョンやオペレーションズリサーチなどの研究、および、データ分析システムの開発・運用を経て、2016年にメルカリ入社。現在は、データエンジニアリングとAI・機械学習のチームでエンジニアリングマネージャーを担当。Slack名は@kumon。
US版メルカリを担当するデータエンジニアに求めるもの
@kumon:「US@Tokyoのデータエンジニア募集中!」ということで、パロアルト、日本それぞれのオフィスにいるデータエンジニアのみなさんに、いろいろ聞いていきたいと思っています。ちなみに、@hatoneさんはパロアルトのオフィスで働くメンバーですが、偶然にも帰国していたので来てもらいました!
ではまず、おもな業務と求めるスキルセットはこちら!!
<おもな業務内容>
・ データ分析およびサービス向けのETL/データパイプラインの設計、開発、保守運用
・ データ分析システムの改善および運用
・ 外部データも含む、さまざまなデータを融合した、機械学習やAI機能開発の加速
・ 日本およびアメリカのチーム(データアナリスト、プロダクトマネージャー、エンジニア)と連携した、データドリブンなビジネス成長の加速
・ データ分析やデータパイプラインツールやプロセスの標準化による組織全体の業務効率の改善
<求めるスキルセット>
・ 5年以上のソフトウェアエンジニア経験、および、3年以上のPython、または、PHP、Golangでのサービス開発経験
・ 要件定義から開発、運用までの一貫した、バックエンドシステム開発経験
・ データベース、リアルタイムおよびバッチデータパイプライン、SQL、データ分析の豊富な知識と経験
・ セキュリティ、Linux、ロギング、システム運用の基礎知識
・ さまざまな職種のメンバーと円滑にやり取りができるコミュニケーション能力
全データに責任を持ち、どうリードしていくかを考える役割
@kumon:US版メルカリのデータエンジニアは、合計4名。パロアルトや日本、ボストンに散らばっています。拠点は違えど、僕らが向き合っているのはUS版メルカリの全データ。そのなかで、どんな役割が求められていると感じていますか?
@ryota:僕らのミッションは、データをアプリケーションにつなぎこむこと(=データパイプラインをつくる)。そのため、データエンジニアとして「データを使ってサービスをどう良くしていくか」「データパイプラインを他職種メンバーでも扱いやすくするために必要なこと」を考えるスキルが求められると思っています。
加藤亮太(@ryota)
@sudarsan:「データパイプラインを他職種メンバーでも使いやすくする」は大事。僕らが扱うデータは、開発メンバーだけでなく、経理やIRを担当するメンバーも扱うことがあります。この両者間では、データの観点にギャップが起こりがちです。そこがズレたままだと手戻りが多く、お互いにコストがかさんでしまうんですよね。さらに言うと、経理はJP版メルカリと共通する部分も多く、日本事業であるメルカリJPのメンバーともやりとりします。しかし、英語がわかるメンバーばかりではないので…。そういった壁を乗り越えながら目線合わせができるスキルは貴重です。
@hatone:私にとってUS版メルカリのデータエンジニアは、全データに責任を持ち、どうリードしていくかを考えるのが肝な仕事だと思っています。大切な情報が詰まっているからこそ、サービスへ落とし込むスキルを持ちつつ、管理することもしっかり考えられるスキルも問われる気がします。
@kumon:確かに、僕らはUS版メルカリの全データにアクセスできるからこそ、それぞれの内容をしっかりと理解するなど、品質やセキュリティへの高い意識が大事ですよね。
@sudarsan:エンジニアリングスキルに関しては、アルゴリズムとデータ構造の知識が必要です。あとは、分散システムを使った経験があるかどうか。今、メルカリUSには分散システムの経験を持っているメンバーがそんなにいないので、強めていきたい気持ちはあります。
Sudarsanan Janakiraman(@sudarsan)
チーム内で、各国の開発文化が融合されるメリット
@kumon:僕らは国境を越えて一緒に仕事をしているわけですが…言葉もカルチャーも違う者同士で開発してみてどうですか?
@sudarsan:拠点の位置から考えると、言語の違いだけでなく、時差の壁もけっこう厚いですね。重要なMTGをやろうとすると、誰かが早朝もしくは深夜に参加することになるんです。もちろん、参加可能な時間帯で複数回に分けて実施することもできますが、そうすると効率が悪いですし…。でも、各国のエンジニアリングやカルチャーの違いが融合されていて、面白いチームですよね。
@hatone:メルカリUSって、アメリカの雇用形態によるものでもありますが、けっこうイケイケドンドンな勢いで開発を進める成果主義なところがあります。でも、JP版メルカリを開発するメルカリJPは、しっかりとプロジェクト管理されていて、開発体験を良くすることを目指しています。最近では、メルカリJPの開発文化がメルカリUSでも導入され、いい具合に融合され始めているように感じますね。
大島孝子(@hatone)
@ryota:日本オフィスにあるUS@Tokyoでも、融合を感じています。日本にいながら海外向けサービスをやろうとなると、どうしても国境を感じることになる。でも、US@Tokyoでは、触れるもの・見るものすべてがアメリカにつながっているんですよね。課題もいくつかありますけど、それでも「海外向けサービスを開発しているんだなぁ」とここまで強く感じられるのは、US@Tokyoならではだと思っています。
@kumon:@ryotaは2020年3月にUS@Tokyoへオンライン入社したこともあり、チームの雰囲気を掴むのは大変だったと思うのですが?
@ryota:そうですね(笑)。入社してまず面白いと思ったのは、JP版メルカリに比べて、US版メルカリには「メルカリを使い慣れていないお客さま」が多いこと。JP版メルカリにはサービスを使い慣れたお客さまが多く、新機能を出しても使ってもらえないことが多い。でも、US版メルカリは、レコメンドしたら従ってくれる方々の割合が高く、JP版メルカリではなかなか動かない数字でも、US版メルカリでは動いたりするんですよね。
一方で、US@Tokyoは日本にいながら海外向けサービスをつくることになるので、アプリ内の機能を触れても、実際にお客さまとしてやりとりできません。データエンジニアリングは、サービスからどんなデータが求められ、どういった使い方をされるかを考えながら開発をします。データ構造や形式について、メルカリのアプリ内で完結することなら開発環境からわかるものの、複数のサードパーティー(配送・決済業者)のデータを含めるとより複雑性が増します。ここに、日本にいながら開発することの難しさを感じているところです。
US版メルカリが目指す、データドリブンなビジネスの成長
@kumon:US版メルカリのデータエンジニアとして「合う人・合わない人」は、それぞれどんなイメージですか?
山口拓真(@kumon)
@ryota:成熟した企業に比べると、立ち上がったばかりのスタートアップのように、個人が裁量を持って働ける環境です。なので、専門性が高く「それ以外はできません」というタイプは合わないかなと思います。具体的には、分散処理やデータサイエンスといった専門性を活かしつつ、必要であればサーバーサイドにも関われないといけない。フルスタックエンジニアを求めているわけではなく、「サービスのためにすべてやっていくぞ!」のマインドを持っていたほうがいいと言いますか。
@sudarsan:うれしいことに、メルカリUSは配送手続きの簡略化やAIを活用した新機能の追加などの独自施策が成功し、GMV(総流通総額)も大幅に伸ばすことができました。けれど、まだまだ規模は小さく、フェーズも「スタートアップ」のままです。データのサイズ感も、GAFAなどと比較すると大きくはない。だからこそ、今のうちにスケーラブルなデータ分析環境の整備やデータに基づくオペレーションの自動化を推進したい。例えば、不正検知とかコンテンツモデレーション機能をよりリッチにしたり、リアルタイムでユーザーの動きがわかるようにしたりなど、健全なマーケットプレイスの維持をしたいですね。
@ryota:いい話!今後も求められるのは、データドリブンなビジネスの成長。これまでは、サービスとしてやらなくちゃいけない開発を急ピッチでしてきました。だんだんいろいろな機能が整ってきた今、サービスを改善したり新しい機能でどんなデータを使うことになるのかを判断するための材料としてデータを活用していきたいですね!
@hatone:今までは、一つひとつのプロジェクトをやって終えて…をくり返してきました。現在は、人も増えたことでパイプラインなどを整え始め、データエンジニアリングがチームらしくなってきたフェーズです。これからは個々の強さをキープしつつ、チームとして働く取り組みもできます。実は私、メルカリUSへ入社当初、ずっとぼっちでデータ分析していたんです。だから、わいわいできるのはうれしい!
@kumon:メルカリUSは、スピードと結果を求めるところから「しっかりつくろう」へ移りつつります。スピード優先でつくってきたシステムはメンテナンス性やスケーラビリティに課題があるので、そこは時間をかけて改善していきます。今後もプロジェクトによってはスピードを優先し、そのあとに改善するといったことをくり返すことになると思っているんです。
僕としては、データエンジニアの個々の力で積み上げてきたものをチームとして見直し、10年後も使えるデータ基盤…といったものを目指しているわけではなく。どちらかと言うと、サービスのフェーズにあったものへと成長させ、よりデータドリブンな意思決定や自動化の促進に寄与していきたいですね。
US版メルカリのデータエンジニアに挑戦したいと思ってくれた方とお話しできることを、楽しみにしております。
ご応募、お待ちしています!!