メルカリの中で働くメンバーが、日々どのようなことを考え、どのようにチャレンジしているのかを紹介する場として初めて開催した『Mercari Day 2017』。

本稿では、CTOの柄沢聡太郎が登壇したセッション「Mercari – Moving Beyond Borders」の模様をお届けします。

メルカリでは、日本、US、UKと文字通り「国境＝Borders」を越えたプロダクト開発を行っています。その中心を担うエンジニアリングチームがどのように作られているのかをご紹介しましょう。

speakerdeck.com

体制について～US、UKと拠点が広がっても「開発の中心は日本」

柄沢が最初に話したのは、3拠点におけるエンジニアリングチームの人数や役割について。拠点数が増えた今、これまでと何が変わり、何が変わっていないのかを説明しました。

僕がメルカリにジョインしたのは2年前の5月。もうすぐ2年が経ちます。その間にいろんな変化がありましたが、このセッションではメルカリのエンジニアリングチームがどういう哲学で開発しているのか？などをお話したいと思います。

その前に、まずは開発体制についてご説明しましょう。

メルカリは現在、東京と米サンフランシスコ、英ロンドンの3拠点で開発していて、東京の開発陣は60名を超えるくらいの規模になりました。

各拠点のサービス運用も東京で行っており、その他、採用、教育といった開発組織の運営にまつわる部分も主導しています。なので、メルカリ開発の中心は今もここにあると言えます。

次に、2014年に拠点を構えたサンフランシスコオフィスについて。8名のエンジニアが在籍していて、ローカライズをメインに行っています。現地採用者と東京からの赴任者による混成チームで、言語だけでなく現地の文化・習慣なども含めてローカライズを進めているのが特徴です。

とはいえ、USアプリの開発は、現地チームのみで行っているのではありません。東京のエンジニアも約9割くらいがUS向けの開発に携わっています。メルカリは今、全社的に「USフォーカス」で動いているからです。USで勝つことを最優先に、日々現地のエンジニアたちと密に連絡を取り合って仕事をしています。

ロンドンオフィスは、2016年に立ち上げたばかり。2017年内を予定しているUK版のリリースに向けて、エンジニアたちがローカライズや現地の法令に適応させるための作業を進めています。

チームづくりについて～何事も「プロダクトファースト」で行うための布陣に

グローバルな開発体制についての説明が終わった後は、より具体的なチーム編成の話に移っていきました。開発組織の中心を担っている柄沢だから語れる「今の編成にした狙い」とは？

メルカリのエンジニアリングチームは、大きく2種類のチームに分かれて動いています。ひとつは「プロジェクトチーム」で、もうひとつは「機能でわけられたチーム」です。

プロジェクトチームはミッションごとに細分化していて、それぞれのチームにエンジニアやプロダクトマネージャー、プロデューサー、QA担当者がいます。

1つのチームに各職能のメンバーを揃えているのは、現場にどんどん権限委譲して開発を進めるための工夫です。1チームだいたい5～10名くらいの規模にしていて、すべてのプロジェクトチームが四半期ごとに定めるOKR（Objective and Key Result）に向かって動きます。

例えば「Seller UXチーム」は、メルカリに出品する売り手の体験をより良いものにすることにフォーカスして業務を行うわけです。

こういったチームが5〜6つくらいあり、ここにデザイナーチームが連携することで、日々の改善が進められます。

そして、もう一方の機能でわけられたチームは、開発組織を横断して取り組むべき課題を解消していくチーム。今は

• SRE（Site Reliability Engineering）
• SET（Software Engineer in Test）

の2チームがあり、SETは昨年立ち上げました。

それぞれの役割を簡単に説明すると、SREはインフラ運用を含めて「いつでも快適・安全・安心にサービスを使えるようにするチーム」で、SETは開発環境やテスト環境を整備することで「エンジニアリングの面からメルカリの品質を支えるチーム」です。

こういったチームで開発しているメルカリですが、僕らがプロダクトを作るうえで大事にしている、エンジニアにとってのいくつかの考え方をお話できればと思います。

ひとつめは、何事も「プロダクトファースト」で進めていくことです。

エンジニアとして、技術そのものが好き、大事にしていきたいという人はとても素晴らしい。ですが、「この技術を使いたいから」というモチベーションで開発に取り組むのはちょっと違うんじゃないかと僕らは考えています。それ以上に、「その技術を使ってユーザーにどんな価値を届けるか？」を重要視しています。

つぎに、「進みながら直す」という考え方も大切にしています。

日本やUSの市場では、日々メルカリの競合となるようなサービスが生まれています。彼らに負けないように、僕らはマーケットフィットを意識していろんな取り組みをしていかなければなりません。

その過程では、モリモリと開発が進む一方、あるときに正しかったものが徐々に正しくなくなることもあります。一般的には、技術的負債という言い方もされるわけですが、こうした負債を解消するためにまるごと書き直すなどの歩みを止めてしまってはライバルに遅れを取ってしまいます。だから、「進みながら直す」ことを徹底していきたいんです。

これが非常に難しいことは理解しています。でもやり抜かなければ勝てない。

そして、「適材適所の技術選択」をしていこう、と考えています。

例えばメルカリのサーバサイドは主にPHPで作られているのですが、並列かつ高速に処理しなければならない部分があればGoでやるし、データ解析をするのであればPythonでやった方がいいかもしれない。こういう判断を柔軟に行いながら、プロダクトファーストを貫くためには、エンジニアの技量と経験が欠かせません。

採用と研修について～バリバリコードを書けるエンジニアが人事を担当する意味

技術的な限界や制約もGo BoldかつBe Professionalに乗り越えていくことが求められるメルカリの開発現場では、優れたエンジニアに対する引き合いが絶えません。そこで柄沢は、メルカリにおけるエンジニア採用のやり方や、採用後の受け入れ体制についても説明しました。

僕らが一番大事にしているのは、「コードを見ることなく採用をしない」ということです。人づてで「優秀なエンジニアがいる」と紹介された時でも、その方の書いたコードは必ず見せてもらうようにしています。

その際に重視して見るのは、単なる“PHP力”のような特定の技術領域についての知識量ではありません。応募者の方が書いたコードを通じて、どの程度の応用力を持っているのかを探るようにしています。

この応用力を推し量る目的で、メルカリではエンジニア採用の際に“技術試験”を実施しています。面接前に技術的な課題を出して解いてもらい、その後の面接でもテクニカルな問題についての質疑応答をする時間を取っています。

詳しい内容は、後で行われるセッション「エンジニアの組織と採用」で説明する予定なのでそこで聞いていただければと思いますが（レポートは後日掲載）、ポイントはこれらの採用フローすべてにバリバリコードを書けるエンジニアがフルコミットしていること。

「エンジニア経験がある人事」や「技術のことがちょっと分かる人事」ではなく、エンジニアとして第一線で戦える人が採用にフルコミットしています。

エンジニアが採用をやることで、応募者の方にとってもメルカリの開発を理解しやすく魅力に思ってもらえるんじゃないかと思っています。

また、採用関連でちょっと変わった取り組みとして、新卒採用ではGitHubエントリー（メールアドレスとGitHubアカウントのみでエントリー可能）などもやりました。こういった「他社でやっていないこと」を、今後もどんどんやっていきたいと思っています。

なお、メルカリでは採用後、入社したエンジニアに必ずメンターを付けるようにしています。「何でも聞ける先輩社員」として、メンターには入社後の1カ月間、毎日1on1をやってもらっています。そうすることで、仕事のこと、開発環境のこと、技術的なことをいつでも聞けるようにしているんです。

入社後の研修としては、CS(カスタマーサポート)研修や、SRE研修をやっています。CSの業務は一番ユーザーに近い部分なので、ユーザーの生の声を聞くことでプロダクトとそれを使うユーザーと向き合うこと目的としています。SRE研修は、メルカリのシステム全容を把握してもらい、SREのメンバーとコミュニケーションをとってもらうことを目的にしています。どのようなエンジニアであってもSREとカジュアルにコミュニケーションをとり、気軽に相談できるようにすることがその後の仕事において重要だからです。

両方とも、より早くメルカリに慣れ、早期に立ち上がってもらうためにやっています。

評価と社内文化について～ポイントは「自発性をいかに引き出すか」

セッションの最後は、エンジニアの人事評価やキャリアパスについての説明に。そこには、冒頭で柄沢が語った「チーム哲学」が存分に反映されていることが分かりました。

メルカリでは四半期ごとのプロジェクト貢献に加えて、技術貢献も評価しています。

会社全体がプロダクトファーストで動いていると、例えばリファクタリングやドキュメンテ―ション、新しい技術習得への挑戦といった「表に出ない努力」は評価しにくくなります。でも、エンジニアはそういう部分も評価してもらいたいもの。なので、プロジェクト貢献とは別軸で評価する形を採っています。評価の際には、そういった技術貢献・スキル面とプロジェクトへの貢献を総合してメンバーにフィードバックしています。

また、エンジニアのキャリアパスは

• エンジニアリングマネージャー
• プリンシパルエンジニア

の2種類を用意しています。

エンジニアリングマネジャーの役割は、「組織面」でエンジニアリングを支えること。

開発では、「経営はこっちに進みたいけれど、技術的には今これをやるのが重要」という矛盾したシチュエーションがよく出てきます。こういった状況において、経営層やプロダクトマネージャーのカウンターパートとなってうまく開発を進めていくのがミッションです。

一方のプリンシパルエンジニアはいわゆるプロフェッショナル職で、役割は「技術面」でメルカリを支えること。

特定の技術領域、もしくは複数の技術領域にまたがるような守備範囲で、卓越した手腕を発揮してくれるエンジニアには、こちらのキャリアパスも選べるようにしてあります。

ここで大事なのは、マネージャーとプリンシパルのグレードは同等にしていることです。さらに補足すると、プロダクトファーストの開発組織の中で超活躍したエンジニアは、経営陣と同じレベルで評価をします。それだけ、エンジニアを重要視しているんです。

最後に、メルカリが大切にしている哲学についてお話して終わろうと思います。

いくつかある中で一番大事にしているのは、【アウトプットは正義】という考え方です。プロダクトのコードを書くのはもちろんのこと、対外的なアウトプットも推奨しています。

最近の事例だと、「海外の技術カンファレンスで審査が通ったので発表しに行っていいですか？」と言ってきたメンバーがいたので、すぐOKにしました。

ちなみにこれは、もうひとつの哲学でもある【アウトプットする人にはインプットの権利を】とも綺麗につながっています。価値あるアウトプットをしてくれる人には、海外カンファレンスに聴講者として渡航するための費用を全額支援したりもしています。

なぜこういう動きを推奨しているか。それは、「エンジニアの自発的な行動を支援する」というポリシーがあるからです。

メルカリでは月に一回、「Be Professional Day」という“何をしてもいい日”があるのですが、これもエンジニアたちの自発的な行動を促すため。例えば、日々の開発に追われていると、「緊急度は低いけど重要度の高い課題」が埋もれてしまうことがあるじゃないですか？そういった課題を自ら見つけて、解消するために使ってほしいんです。

そのための開発環境は、今後も一層整えていきます。

メルカリでは、AWSとGCPの2つで個人のテスト用インスタンスを持てるようにしていて、クラウド上の新サービスは自由に使っていいことになっています。もちろん、その費用は会社持ちです。

他にも、ユーザーの個人情報・プライバシー情報がマスクされた本番DBのレプリケーションを用意して、エンジニアが自由に触れても大丈夫なようにしています。データ解析などで新しい取り組みをする場合は、生のデータを触れることが非常に大事なので。

こうやって「環境」を用意することで、人は自発的に動いてくれると信じています。

メルカリは今後、3拠点をまたいだ開発を本格的に進めていくことになるので、そもそもチームをどう構成すべきか？であったり、拠点間の時差がある中でうまくコミュニケーションを取るにはどうすべきか？について考えていかなければなりません。課題は山積みです。

ですから今以上にエンジニア個々人の自発的な動きが求められるようになる。つまり僕ら全員が、「今のメルカリを越える」ための新しい取り組みを行っていかなければならないのです。