2021年も残りわずかとなりました。メルカリのエンジニアリング組織の1年間を振り返るとさまざまなできごとに遭遇したり、新たな取り組みにも挑戦しました。
本編に入る前に、過去記事でも何度か取り上げた大きな動きを紹介しておくと、まずはWeb版メルカリの大幅アップデートの完了があります。
また、2017年から取り組み初めたマイクロサービスマイグレーションですが、ようやくほぼ全てのチームでマイクロサービスによる開発ができている状態にまで至ったことも大きな前進でした。
そしてその次のステップとして現在まさに注力して推進しているのが、ビジネス基盤強化に投資する「Robust Foundation for Speed」です。
さて、今回の記事では、上記のように過去記事で発信してきたできごと以外には、2021年どんなことがあったのか。どのようなことに取り組んできたのか。
エンジニアリング組織をリードするメンバーに振り返ってもらいつつ、それを踏まえて来年にはどのようなことに取り組んでいくかを聞いてみました。
聞き手はEngineering Officeの@afroscriptで、インタビュイーは次の6名です。
- @kwakasa: CTO
- @stanaka: VP of Backend
- @mtsuka: Developer Productivity Engineering Team Director
- @CaDs: Personalized Marketplace & Engagement Platform Team Director
- @kimuras: AI & Search Team Director
- @hisahiko: Engineering Office Team Director
目次
印象に残った2021年のできごと(技術編)
メルカリグループ横断で対処したインシデント
— さっそくですが、まずは技術面で今年印象に残ったできごととして何がありますか？
kwakasa:
そうですね。まずはポジティブなことではないですが、Codecovへの第三者からの不正アクセスによるインシデントを取り上げない訳にはいかないですね。
まずは本件の影響で、ソースコードの一部および一部顧客情報の外部流出を招いてしまい、お客さまには大きなご迷惑をおかけしてしまったことを改めてここでお詫び申し上げたいと思います。
現代のソフトウェア開発は、さまざまなサプライチェーンを組み合わせて行われています。そのサプライチェーンを使った攻撃（サプライチェーンアタック）に対する意識がなかった訳ではありませんが、十分ではありませんでした。
そして、メルカリの開発においてこれまで積み上げてきた技術資産の中に良くないエンジニアリングプラクティスが残っており、今回のサプライチェーンアタックによって、このような状況を招いてしまいました。
— このインシデントへの対応はどのように行われましたか？
CaDs:
今回の問題はリンクしてはいけないデータをリンクしてしまったことによるもので、それは改善ポイントとして対応しました。似たようなインシデントはこれからも起こる可能性はあるので、ソフトウェアライフサイクルの中で予防しなければいけないと考えています。
kwakasa:
ツールやシステムを正しく使うことを理解するのが大事ですね。これをリテラシーとして、全メンバーに徹底していくのが重要です。もちろん個人の努力に委ねるだけでなく、組織として問題が起こったらちゃんと検知して、アラートをあげる仕組みにも投資していかなければいけません。
mtsuka:
やるべきところが足りていなかったという点はもちろんあります。しかし、逆にガバナンスを効かせる方に傾けすぎると、メルカリの良いところも失われてしまう可能性があり、バランスが大事だと思っています。上場企業でもありますし、個人ではなくチームで仕事を行っていくのは必要なことです。しかし、あまりチーム単位での動きを徹底しすぎると、小回りが利かなくなるかもしれないので、そうしたバランスの難しさは強く感じています。
kwakasa:
そうですね。メルカリはいい意味でとても真面目な人が多いのですが、逆に言うと0か1になりがちでもあります。バランスをとっていくのが重要ですね。攻めと守り、両方をやるのが大事でどちらか一方に偏ってしまってはいけないですね。スポーツでいえば、攻守がはっきりしている野球ではなく、サッカーに近いといえます。
CaDs:
あとはエンジニアのマインドセットも考えていきたいですね。これからもCIなどさまざまなツールを使っていくと思います。これらのツールにはある程度のリスクが内在しています。ツールを使わないではなく、リスクを考えながら適切に利用しなければいけないでしょう。こういった認識やマインドセットの育成を行っていきたいです。
kimuras:
別の視点からみると、このインシデントは、メルカリグループのエンジニアリング組織が現在の規模感になってはじめて、グループ横断で一つの事象に取り組んだできごとでもありました。各グループでさまざまな形のリーダーシップを発揮して、情報整理に取り組むメンバーが出てきました。そうした意味では新しいリーダーが出てきたことも印象深かったです。
hisahiko:
確かに。メルカリがサービスとして大きくなる中で、各組織やチーム間の関係性もより複雑化しています。そうした中でも、各メンバーが主体的に情報をきちんと取りまとめて問題解決に取り組まなければならないという、まさに今組織内で提唱している「Accountable Autonomy*」の重要性を再認識させられたできごとだったと思います。
*Accountable Autonomy…「自立性を持って主体的に仕事にあたる」こと（参考記事: 「メルカリCTOが今、一番頭を抱える課題とは？技術と組織、その両方から振り返る」）
ソウゾウの設立、およびメルカリShopsのローンチ
— 他に2021年に印象に残ったできごとは何がありますか？
kwakasa:
ソウゾウの設立、そしてメルカリShops（以下Shops）のローンチもありましたね。
ソウゾウはカンパニーとして独立しているので開発組織は別ですが、当然ながらメルカリと共有している部分も多くあるので、メルカリ側でもそのリリースに関連した開発は行われました。特に印象的だったのは、ソウゾウの開発チームでは、Shopsは疎結合で開発すると言う決断が早い段階で行われていた点です。賛否両論ある中でしたが、結果的にMove Fast(ソウゾウのバリューのうちの1つ)な開発が行われ、Go Boldな決断だったと言えます。
CaDs:
私はメルカリ側で、ソウゾウとのインテグレーションを行っていました。最初はメルカリアプリの中にタブを置いて、独立してShopsが存在する状態を想定していました。しかし、お客さまの体験を重視すると、メルカリの使い方に近い体験を提供する方が良いだろうという判断になりました。例えば、いいね機能などは本来のメルカリと共通の機能がShopsでも使えるようになっています。Shopsのリリースに向けて、All for Oneなサポートができたと思います。
kwakasa:
開発は疎結合に、カスタマーエクスペリエンス（以下CX）はシームレスというのが目指したい姿です。しかし、これは簡単なことではありません。現状、メルカリは疎結合に作るとCXが途切れてしまう作りになっています。高いCXを実現するためには、特にインターフェース部分において、機能やデータをwell-defined interface経由で提供しなければいけません。前々から分かっていた課題なのですが、Shopsの開発を通してより明確になりました。
コンピュータサイエンスの歴史でいえば、昔はオペレーティングシステムはありませんでしたが、今はオペレーティングシステムが存在します。また、インターネットやTCP/IPも昔はありませんでした。そういった皆で使える共通レイヤーを作っていくということが、歴史の中で繰り返されています。メルカリでも同じようにやらないといけませんし、それができてこそのテックカンパニーだと。プラットフォームやエコシステムと呼ばれるものは、これを高いレベルで実現していますね。
— あと、サーチ回りでかなり試行錯誤を重ねていると聞いています
kimuras:
そうですね。サーチエンジンもメルカリ側で作っています。メルカリの商品はとてもユニークです。一人ひとりのお客さまが、それぞれいろいろな商品を出品できるので、出品数がとても多いです。そして在庫という概念はありません。
それに対してShopsは基本、ビジネスとしての出品になるので在庫の概念が存在します。そのためShopsを利用しているお客さまの出品回数は、通常のお客さまの出品回数と比べて少なくなり、検索結果のランキングのバランスを保つのが難しくなります。しかし、世の中的にそういった更新や出品頻度の異なるものを組み合わせるサーチエンジンにおけるベストプラクティスは確立されていないので、今後も検索結果のチューニングは自分たちで模索していかなければなりません。これは世に提供されている検索エンジンの中でもユニークな課題であり、エンジニアとしてはおもしろい課題だと思います。
そして当然ながら出品するお客さま側だけでなく、商品を購入するお客さまにとって、どのようにサービス提供すれば一番心地よく個人やShopsから購入できるのかの視点も忘れてはいけません。これはシステムアーキテクチャだけでなく、UI/UXであったり、お客さまのご期待への対応なども考える必要があります。これを解決するためには、データから得られる定量的な情報、お客さまのニーズという定性的な情報、そしてこれらの情報から得られた改善策を実現するための高度なエンジニアリングが必要であり、非常に難易度が高いが、おもしろい課題だと思っています。
データ活用基盤の整備とパーソナライゼーション
— 技術面で2021年に印象に残ったできごと、さらにもう1つ挙げるとしたらどんなことですか？
kimuras:
2021年はデータ基盤の整備に注力した年でもあります。それによりレコメンデーションやパーソナライゼーション、Experimentation platformの強化を推進できました。
メルカリはこれまでもお客さまの行動を分析して、高速にUI/UXの改善を繰り返してきた歴史があります。その結果としてMAUが2,000万を超えたのですが、より一層UXを改善していくためには、全社的にデータドリブンでサービス改善に力を入れていく必要が出てきました。そして、その文脈でAI活用にフォーカスしてきました。
データ活用の中でも特に効果が大きいサービスの一つであるパーソナライゼーションについて、今まで以上に注力していこうとしています。お客さまが商品を探さなくても必要なものが見つかる、また新しい気付きがあるUXを提供しようとしています。
これを実現するためには、正しいデータをリアルタイムに使えるようにしなければなりません。そのためにクライアントイベントログとそのデータを的確に管理する仕組みの構築を進めてきました。今現在でも改善と適用を進めていますが、すでに利用を始めています。例えばお客さまの購入した商品だったり、いいねやコメントした商品がリアルタイムにパーソナライゼーションに活用できる仕組みができあがったので、そこから興味がありそうな情報を推定することで、検索する手間を省くようなレコメンデーションサービスを提供できるようになっています。
それと同時に整備しているのがExperimentation platformと呼んでいるA/Bテスト基盤になります。このExperimentation platformを使うことで正しくお客さまをサンプリングし、統一された形でA/Bテストを行うことができます。すでに各施策に導入されていて、データドリブンな意思決定やサービス改善に用いられています。
kwakasa:
ユニバーサルコントロールグループの管理もできるようになりましたよね。
kimuras:
そうですね。ユニバーサルコントロールグループというのは、改善を行わないグループのことです。例えばサーチエンジンなどで細かな改善を繰り返したり、A/Bテストを行っていると、本当に改善が良かったのかどうか、半年後や1年後に評価しづらくなります。そこで一定割合のお客さまには、何も適用しない状態を維持します。これをユニバーサルコントロールグループと言います。このユニバーサルコントロールグループと、改善を実施したグループを比較することで、我々が改善していった結果がどれだけ良かったのを比較できます。これもExperimentation platformに組み込まれた機能です。
— 具体的にはどういうパーソナライゼーション機能が実装されましたか？
kimuras:
一番効果が大きかったのは、「閲覧した商品からのおすすめ」と呼ばれる機能です。閲覧した商品からお客さまの好みの商品を推定して抽出するのですが、これは先ほど言ったログデータ管理の仕組みを利用して、リアルタイムなレコメンデーションを行っています。これがリリースされて、コンバージョンレートが大幅に改善されました。
それ以外にもさまざまなレコメンデーション用のコンポーネントを作って、順次テストを行っています。それぞれのお客さまにとってどのコンポーネントが一番適切かというのは、もう一段上にLayout Optimizerというものがあって、そこで最適化するロジックが走っています。メリットとしては常に複数のコンポーネントがテストされている状態になっていることです。それぞれのコンポーネントには異なる軸、例えばいいねの軸やコメントの軸があって、どの軸でレコメンデーションするのが最適かはお客さまによって異なります。そういったお客さま一人ひとりに合わせたコンポーネントを提供していこうと、最適化に力を入れています。
- 参考記事:
印象に残った2021年のできごと(組織編)
コロナ禍での採用と新時代のワークスタイル
— 続いては組織編ということで、組織づくりにまつわる印象に残ったできごとをお聞きしたいです。
kwakasa:
最初に浮かぶのはコロナ禍での採用でしょうか。2020年に採用抑制をしていたこともあり、その間に薄れてしまった採用候補者とのつながりを再構築していくのが大変でした。
hisahiko:
僕も同感です。採用活動を一度抑え気味にしたインパクトは大きかったと思います。
kwakasa:
ただ、採用抑制をしていたこと自体は間違っていなかったと思います。コロナ禍、特に初期は何が起こるか全く読めない状態だったので、投資を今まで通り行う決断はできませんでした。正しい決断ではあったのですが、後遺症は思ったよりも大きかったと実感しています。
mtsuka:
僕は自分の責任範囲内で、細々と採用活動的なものは続けていました。そのおかげか、採用をリブートする際のコストは低くて済んだかなと。ただ、採用に関して今までと違うものになってきた気もしていますので、苦労は絶えませんね。
kimuras:
そうですね。採用会食も難しくなってきましたね。弊社でも工夫を凝らし、オンライン採用会食などを行っており、状況はとても改善してきましたが、採用のアプローチであったり、メルカリの魅力をお伝えする手法が大きく変わりました。
mtsuka:
お作法は確実に変わったという感じですね。
hisahiko:
オンライン前提の新しい採用のパターンを考える良いタイミングかもしれませんね。一方で、良かったこととしては、どれだけ採用候補者とのつながりを強化できたかをKPIとして設定し活動できたことだと思います。
mtsuka:
そうですね、採用数ではなくそこを目標においたのは良かったと思いますね。
kwakasa:
全社OKRでもAll Tech Recruitersと称した目標を設定し、エンジニアリング組織のみならず全社で採用を推進できました。全社的に全員で採用を行っていこうというHiring Cultureを浸透させる良い機会にもなったと思います。
— 9月にはメルカリのニューノーマル・ワークスタイルとして「YOUR CHOICE」が導入さましたが、その反響はいかがでしたか？
kwakasa:
面接をしていて、トラディショナルな会社とは違うんですねといった印象は持ってもらえますね。テック企業であってもMeta（旧Facebook）やTwitterはリモートに寄せていて、AmazonやGoogleはオンサイトに寄せようとしています。各社対応が分かれる中でさまざまな議論があって、メルカリのこのGo Boldなアプローチはポジティブに評価してもらっています。
mtsuka:
都心に住んでいなくとも優秀な方はたくさんいます。その方たちはそれぞれの希望や事情があって、その土地に住んでいると思います。そうした方々に対して、お互いのために機会が得られたのは良かったと思います。
kwakasa:
社内のエンジニアからの反応も総じてポジティブだと思います。これを機に希望の地域に移住したという話も聞きます。色々なライフスタイルがあって、各々が選べるようになったのは良いですね。時代の要請に応えられているかなと思いますし、D&Iの観点でも重要ですね。
hisahiko:
早めにリモートワークに舵を切れていたのも、YOUR CHOICEに踏み切る材料として良かったですね。昨年の初め頃から一年以上のリモートワークを通じて、大丈夫そうだと思えたのもあって判断することができたのだと思います。
kimuras:
僕が良かったと思うポイントは、リモート前提に切り替えても何も問題が起こってないことですね。さまざまな懸念はありましたが、機器トラブルを除いてリモートに関連する問題は起きませんでした。僕のチームでは何人か地方に引っ越した人もいますが、何の問題もないです。
kwakasa:
個々人の価値観に合わせた生き方ができるっていうのはいいと思います。
mtsuka:
介護などさまざまなライフイベントが理由で、オフィスに出勤できる距離に住めない方/住めなくなる方は多いと思います。仕事の機会は残しながら、そのような社員のプライベートも大事にできたという意味において、すごく良かったと思います。
外国籍メンバーが半数を越えた組織でのコミュニケーション方法
— 今年の1月にはCEO直轄の社内委員会「D&I Council」を設立するなど、全社的にもD&Iを推進した年とも言えます。エンジニアリング組織におけるD&I推進の状況はいかがですか？
stanaka:
分かりやすい活動としては、去年に引き続きBuild@Mercariを開催したり、Mercari Restart Programという新たなプログラムを開始し、それを通じてさまざまな事情で一度キャリアを離れた方にソフトウェアエンジニアとしてキャリア再開を支援できるような取り組みが始まったりしています。
また、内部的なところでは、現在エンジニアリング組織の5割以上が外国籍エンジニアですし、今年は@CaDsがディレクター陣に加わり、リーダーレベルでもダイバーシティが広がってきています。
— 外国籍エンジニアの割合が増えてきたことで、社内でのコミュニケーションに変化はありましたか？
kwakasa:
Broken Englishでも良いんだという意識が社内で浸透してきたと思います。完璧に正確な英語を話す必要はなく、まず伝えたいことを相手に伝えることが重要なので。英語はあくまでツールなので、人によって得意・不得意があるのは当然のことです。英語が苦手な人でもインクルーシブに働くにはどうすべきか。メルカリが追求しているのは、そういった意味での本質的インクルーシブな環境です。
mtsuka:
英語でコミュニケーションをとる機会があるといっても、英語話者のうちネイティブな英語を話すのは2割程度です。だから多くの場合はネイティブでない人同士がコミュニケーションをとるために英語を使っているにすぎません。そうした背景を理解する姿勢も必要です。自分が日本人であり母国語でない英語を使ってなんとかコミュニケーションをとろうとしているように、相手も自分の母国語以外の言語でコミュニケーションをとろうとしてるのだと。最近は、そういった認識がお互い芽生えてきてるように思えます。
また、そのうえでどのような工夫をすればお互いの意思疎通がしやすくなるかは、Language Education Teamが実施する「やさしいコミュニケーションワークショップ」で学ぶことができます。「やさしい」は、”Easy”=易しいと、”Kind”=優しいの2つの意味が込められています。短い文章で伝えたり、慣用句やスラングをなるべく避けたりするだけで、母国語以外の言語でのコミュニケーションはずいぶんと楽になるのです。
僕のチームでは新しいメンバーが入るたびにこのワークショップを必ず行っています。その度に色々な気付きがあったり、自分では認識していなかった思い込みが確認できるのでとても良いですね。
成長機会の創出
— エンジニアリング組織内で社内異動制度が始まったのも今年だと記憶しています。この制度はどのようなもので、生まれたきっかけは何だったのでしょう？
stanaka: 文字どおり社内でメンバーを募集しているチームに、各エンジニアが自ら応募し、異動することができる仕組みです。メンバー募集中のチーム一覧は常に公開されており、現在の仕事での技術領域に関わらず応募できますが、社外からの応募と同じ基準・プロセスで選考されます。
始めたのは、社内で実施しているエンゲージメントサーベイを通じて、成長機会の有無とエンゲージメントの高さに相関があることが見えてきたからです。自ら成長機会をもとめてチャレンジがしやすいようにこの制度を整えていきました。
kwakasa:
メルカリはまだ巨大な会社とは言えませんが、ある程度の規模になってきたことで、新しいビジネスや事業が増えてきました。そこで外部の人材だけでなく、内部の人材にもフェアに機会を提供しようと考えました。
あと、新しいチャレンジを求めて転職しようと思っている人に対しても、社内にもこんな機会があるんですよと示すことで、もしマッチするものがあれば双方にとってうれしいことだと思います。各メンバー、それぞれやりたいフェーズや得意なフェーズは違いますし。
hisahiko:
チャンスを適切に配分したいという話と、会社が大きくなることで社員の成長に合わせた選択肢を提供したいという話を両立できる仕組みが整い始めましたね。
— 1年間運用してみた反応はいかがでしょうか？
kwakasa:
どうでしょう。少なくともこの制度で異動した人は、異動先で活躍してくれています。メルカリに長くいても機会はあると思ってもらう1つの手段になったのではないでしょうか。
課題としては、残されたチームメンバーたちのモチベーションに対してネガティブな影響を与えてしまうことがある点です。チームメンバーの数が減るわけですから、そのあたりはフォローが必要ですね。組織としての余裕が必要な制度だと思っています。余裕がないのにあまりに異動者が増えると、みんながしんどくなってしまうでしょう。
mtsuka:
変な偏りができる可能性もありますよね。
kwakasa:
そうですね。だから、いい意味で余裕がある状態というのが前提条件の1つになると思います。組織として、これを継続できるように、良い意味での余裕を作っていきたいですね。
2022年に向けた意気込み
— 最後に来年に向けて取り組みたいことや意気込みをお願いします
kwakasa:
今後のメルカリグループの事業・サービスの迅速な拡大を支えるために、技術と組織の両面で基盤強化をさらに推進していきたいです。
stanaka:
エンジニアが自発的に生産性を向上させるために行動できるように、メカニズム、アーキテクチャ、そしてチームをアップデートしていきます。
mtsuka:
来年のテーマはMore with Lessです。なるべく少ないものでなるべく多くのものを生み出していきたいです。そのためにKISS（Keep it simple, stupid）やYAGNI（You ain’t gonna need it）といった原理原則にフォーカスし、組織に浸透させていきたいです。また、現在プロジェクトをリードしているRobust Foundation for Speedについては、誰もが結果を認知しやすい形にすることを目指していきたいです。
CaDs: バックエンドアーキテクチャの改善に取り組みたいのと、Growth Engineering Teamとともにさまざまな実験を試していきたいです。
kimuras:
お客様に寄り添ったデータドリブンな意思決定ができる組織づくりはまだ道半ばです。データマネジメントを拡充し、それを適切に活用できる組織づくりを今以上に洗練させていきたいと思います。データ活用法の改善にゴールはないですが、これを洗練させ続けることによって開発メンバーもお客様もともに幸せになると信じています。
hisahiko:
来年も今年以上にチャレンジングなことが多くなりそうな予感がしてます。いろいろなことを実現していくために、エンジニアリング組織としてもう1段も2段も上に上に行けるように取り組んでいきたいと思います。
— ありがとうございました！
採用情報
メルカリでは一緒に働くメンバーを募集中です。 少しでもご興味のある方は、ぜひともMercari Careersの募集要項やRobust foundation for Speedの特設ページをご覧ください。
