国境を越え、一丸となって「勝ちにいく」 US版メルカリを支え続けてきた開発メンバーの挑戦

f:id:mercarihr:20180411052128j:plain
吉岡さん(写真左)、多賀谷さん(写真右)

先日、US版メルカリがリブランディングしたことをこちらの記事でお伝えしました。

mercan.mercari.com

今回のリブランディングは、メルカリUS CEOのジョン・ラーゲリンが記事中でも話しているように、USでローンチしてから最も大きなアップデートです。

しかし、実はそれ以前にもUS版メルカリではさまざまなアップデートが行われてきました。US版メルカリに関わるメンバーはJPオフィスとUSオフィスに分かれ、リモートなどでやりとりしながら開発しています。今回のリブランディングに至るまでのアップデートは、彼らが試行錯誤しながらもチャレンジし続けた結果とも言えます。

今回のメルカンでは、US版メルカリを開発し続けてきたiOSエンジニアの多賀谷洋一(現在はメルカリJPエンジニアリングマネージャー)と、Androidエンジニアの吉岡毅にこれまでの開発を振り返ってもらいました。

多賀谷洋一(Yoichi Tagaya)
Mac OS X登場当時からApple Platformでアプリを個人開発。外資企業、フリーランス、スタートアップを経て2017年1月に株式会社メルカリに入社。US版メルカリのiOSアプリ開発を担当した後、2017年11月よりエンジニアリングマネージャーとして開発組織の強化に従事。SwiftのDependency InjectionフレームワークでデファクトスタンダードとなっているSwinjectの作者でもある。


吉岡毅(Tsuyoshi Yoshioka)
大学院卒業後、ソニー・エリクソンモバイルコミュニケーションズ株式会社(現 ソニーモバイルコミュニケーションズ株式会社)に入社。世界展開されていたフィーチャーフォンの開発から始まり、Symbianスマートフォン、Xperiaシリーズのスマートフォンの開発に従事。2016年3月よりメルカリに入社し、以来、US版メルカリのAndroidアプリを担当。『Android アプリ設計パターン入門』の著者の一人でもある。

US版メルカリは「JP版メルカリと同じソースコードだった」

ーまず、US版メルカリのリリース当時を教えてください

吉岡:もともとUS版メルカリは、JP版メルカリをベースに開発がスタートしました。1つのソースコードから2つのアプリケーションをつくっていたので、見た目も「メルカリの英語バージョン」でした。

f:id:mercarihr:20180410150606j:plain
リリース当初のUS版メルカリ

多賀谷:体制も、JP版メルカリと同じプロダクトチームでした。当時はUSオフィスでも実装を行いつつ、プロダクト施策の考案やおもな実装はJPオフィスにいるメンバーで実行していたんです。そのため、多くのJPメンバーが定期的にUS出張し、現地の様子を調査して「どういったものをつくっていくべきか」を主体的に考えていましたね。

JP版とUS版を完全に分け、新しいアプリとしての開発が始まったのは2016年11月ごろ。フルスクラッチで書き直すなど、US版メルカリを完全に置き換えるプロジェクトとして約3ヶ月で実行しました。

f:id:mercan:20180322102131j:plain
US版として独立した当時のメルカリ

ーなぜ完全に分けることにしたのでしょうか?

多賀谷:メンバーのUS出張によりJP側でプロダクトの方向性を決めて実装…というのはPDCAサイクルを回すコストが高いものでした。しかし、それではUS版メルカリの成長が遅いものになってしまいます。そこでアプリを独立させ、開発の拠点をUS現地にすることで、開発スピードをより上げていくことにしたんです。

実際にその開発が決まってからは、US側にもVPが就任し、プロダクトや全体の方向性を現地で判断していくようになりました。

f:id:mercarihr:20180410152213j:plain

吉岡:これは、わりと自然な流れだったと思います。現地に住んでいれば、お客さまの生活を見たり、そこで使われているほかのアプリを見たりできます。その環境下でお客さまのニーズを拾い、「こういったものをつくろう!」とダイレクトに決めてプロダクトの舵を切ったほうが価値の高いものを届けられますよね。

多賀谷:とはいえ、現在はUS現地を拠点にしつつ、JPオフィスでも開発などを担っています。そのため、JPとUSそれぞれがリモートでやりとりしながら開発を進めています。

いかに開発スピードを下げずにコミュニケーションをするか

ーUS版メルカリとしての独立、そして今回のリブランディングに至ります。そういったアップデートがある中、開発チームではどのような変化などあったのでしょうか?

多賀谷:チームとして明確に変化を感じたのは、やはりUSのCEOとしてジョン・ラーゲリンが参画したときですね。このタイミングで、経営側とマネージャー側との連携がより密になった印象があります。

一方で課題になったのが、実際に開発に携わるメンバー間でどう一体感を出すか、でした。

f:id:mercan:20180322102108j:plain
リブランディング後、さらに新しくなったUS版メルカリ

吉岡:US版メルカリチームは、JPとUSそれぞれにいるメンバーがフラットにやりとりしながら開発を進めています。

しかし、US版メルカリとして独立し、さらに現地でスピーディーに開発を進めていく中で、距離や時差による影響も大きくなっていきました。そこでやはり問題となったのが「いつ・誰が・なにをしているのか」がわかりにくいことと、間接的なコミュニケーションによる情報量不足でした。

まず「いつ・誰が・なにをしているのか」ですが、これの最大の問題は、なにかが起こったときに誰に相談すればいいかがはっきりしないことです。そこで始めたのが、固定の時間をつくって強制的にコミュニケーションをすることでした。

例えば、USオフィスとJPオフィスとの全体定例を隔週または月1で行っています。そして各チーム内では週1回以上の頻度で定例をするようにしています。そこで今後問題になりそうなポイントと対応できそうなメンバーを共有し、すれ違いになりそうなことをあらかじめ解消するようにしました。すれ違いによるタイムロスをなくすため、全体定例もなるべく週初めに設定しています。

多賀谷:US版メルカリチームではすべて英語で、普段はSlackやテレカンを使ってフラットにやりとりしています。しかし、先ほど吉岡さんが話していたように、文字や音声だけのコミュニケーションは「直接会って話す」に比べて情報量が限られています。

文字や音声だけのやりとりでは、フィードバックしたい内容の背景をどこまで共有しているかを確認し、適切な表現で伝えることに苦労しました。お互いが認識している背景が異なっていたりして、結果的に1日2日かけてしまったこともありました。

吉岡:これについては今でもまだ試行錯誤し続けている課題ではありますが、現段階では「理解による解決」を意識するようにしています。つまり「コミュニケーションが限られていると、歯がゆいことが起きがちだよね」と常にお互いが理解している状態をつくっておくわけです。

f:id:mercarihr:20180411052133j:plain

これがあることで、ちょっとしたすれ違いが起きても「もしかすると今、コミュニケーションによる問題にぶち当たっているかもしれない」と気づくことができます。「理解による解決」を双方で認識するようになってからは、文字だけのコミュニケーションで起こりがちな語弊があっても、無駄にヒートアップすることはなくなりましたね。

JPとUSがスケーラブルな組織になっていく過程は貴重

ー「新たな価値を生みだす世界的なマーケットプレイスを創る」をミッションとするメルカリがUSで成功するため、チームとしてどうなっていくことが理想なのでしょうか?

多賀谷:そもそも現在のUS版メルカリをUSとJPがそれぞれ役割分担をして進めている理由は、今のメルカリのフェーズでは国境を越え、一丸となって挑まないと勝てないからです。

世界で戦っている企業の多くが、技術力も人数も強力なエンジニア組織を持っています。しかし、メルカリUSはまだそこに及びません。そういった企業と対等に戦うためには、スケーラブルな組織にしていく必要があります。

吉岡:今は先ほどお話ししたやりとりで解決できていますが、事業拡大をしていく上でまた新たな問題が出てくると思います。そのたびに方法を決めて取りかかるのではなく、プロジェクトや問題によってストラテジーを切り替えて進めていくんだろうなと考えていたりします。

多賀谷:そうですね。そういった意味では、JPにいながら世界に挑戦できる環境は、メルカリが一番整っているかもしれません。さらにいうと、メンバーそれぞれがオーナーシップを持ち、国境を越えて一丸となりながら開発をしていく過程は正直楽しい。グローバルにスケールしていく組織づくりにも携われる今のタイミングは、貴重かもしれませんね。

mercari - Jobs: Software Engineer, Backend (US App) - Apply online