メルカリのエンジニアが、エンジニアとしてあるべき姿を共有し、エンジニア文化の醸成とともに互いに強みを活かす組織を作るために生まれたのが「Engineering Ladder」。同社CTO名村卓氏が感じていた課題とこれからの組織拡大を考える中で生まれ、現在はエンジニアチームの強化に活用されています。

今回、同社Engineering Officeマネージャーの廣井智一氏に、Engineering Ladder誕生の背景を振り返りながら、メルカリはEngineering Ladderをどのように活用し、評価の運用をしているのか、そして、その先にあるエンジニア文化の醸成について伺いました。

株式会社メルカリ　Engineering Officeマネージャーの廣井智一さん

事業成長、組織の拡大で見えた「規模拡大」という壁、D＆Iを意識した文化の醸成

――メルカリ社では、「Engineering Ladder」と呼ばれるエンジニアの行動を明文化したドキュメントがGitHubで公開されています。ドキュメントなどを読むとエンジニアとしての価値観の共有と組織の強化が目的のように感じます。この、Engineering Ladderはなぜ生まれたのでしょうか？

廣井さん（以下「廣井」）：Engineering Ladderが生まれた背景は、メルカリの事業成長、そして、組織拡大のタイミングが影響しています。今から約3年ほど前、上場後から、次のフェーズに向けての事業成長、そして、それに伴う組織の拡大が進行している最中でした。

さまざまなメンバーが増える中でも、とくにメルカリ東京オフィスのエンジニアチームに関しては、日々新しいメンバーが加わり、「顔を合わせたことがないメンバーが増える」状況が生まれました。また、国籍も多様化する中で、価値観の多様化も同時に進み、それとともに、コミュニケーション上の弊害が見えてきました。たとえば、メルカリがミッションを達成するために大切している3つのバリュー「Go Bold」「All for One」「Be a Pro」のうち、「Go Bold」をどう捉えるか、国籍によって言葉への印象が違うことはもちろん、100人時代のメルカリにいた人と、1,000人時代に入社した人でも解釈が異なり、価値観のズレが生まれていたのです。

そのころから、CTOの名村がこの課題を解決するための仕組みづくりについて考えはじめ、プロダクトの構造の変化、それに伴う有機的な組織づくりに着手し、周囲のメンバーと議論がスタートしたのがEngineering Ladder誕生のきっかけです。そして、2019年5月に名村が社内向けに共有したドキュメントから、Engineering Ladderの素案が生まれました。

――現在、メルカリグループの組織と構成はどのようになっていますか？

廣井：メルカリグループとして、「メルカリ（JP）」「メルカリ（US）」「メルペイ」「Mercari, Inc.」、そして、先日設立した「ソウゾウ」とJリーグチーム「鹿島アントラーズ」があります。

エンジニアの構成という点で、各グループ企業の詳細は公開していませんが、たとえばメルカリ（JP）の場合、エンジニアの約5割が外国籍（海外）メンバーで、まさに多様化が進んでいます。これは、メルカリが掲げている「新たな価値を生みだす世界的なマーケットプレイス」を実現し、多様性のあるプロダクトを目指すことの一環で、先日、弊社代表山田が社外取締役篠田真貴子氏との対談でも触れている「D&I」の考え方に基づくことでもあります。

Engineering LadderとMercari Engineering Principles

――改めて、Engieering Ladderについて教えてもらえますか。

廣井：Engieering Ladderはメルカリが社内で設定している等級（グレード）に対して、上位を除いた6つのグレードごとに期待されるスキル、コンピテンシーを記載しています。現在は、評価や採用、ゴール設定などの基準として使用しています。

先ほど紹介したメルカリグループの中で、現在のEngineering Ladderは、メルカリ（JP）のエンジニアを対象としています。

Engieering Ladderを説明する上で、もう1つ大事な考え方としてMercari Engineering Principlesがあります。Mercari Engineering Principlesは、前述の3つのバリュー「Go Bold」「All for One」「Be a Pro」をさらに分割し、メルカリのエンジニア組織の考え方を9つに明文化したものになります。

このMercari Engineering PrinciplesとEngieering Ladderが対応しており、3つのバリューを実現する考え方、そして、社内のグレードが紐づく形で明文化・言語化されたものがEngineering Ladderです。関係性としては、グレードの上にEngineering Ladderが乗るというものになります。

Mercari Engineering Principles

・Strive For Alignment（チーム一丸となってミッションおよびバリューに最も沿う合意、および明確な共通理解を目指す）
・Share To Empower（他者の成長を促す機会を生み出す）
・Foster Trust & Inclusion（インクルーシブ　(誰もが自分らしさを受け入れられている包括的な状態）で、互いを信頼しあう環境の促進）
・Seek Continuous Improvement（常に学ぶ姿勢を忘れず、質の向上を目指す）
・Take Action & Responsibility（積極的にオーナーシップを取り、課題解決に取り組む）
・Be Strategic & Efficient（ビジネスとして成功を掴むために、戦略的であれ）
・Focus On The Customer（私たちはお客さま重視の会社である）
・Go Bold, Fail Fast & Recover Faster（さまざまな試みを通して、素早く大胆に突き進む）
・Deliver With High Quality（最高水準であることを目指す）

※同社Webページ「Culture」より抜粋・引用

Engineering Ladderは、この9つの考え方を、L1～L6、それぞれのグレードで実現すべき内容に落とし込み、まとめています。

内容については、公開されているGitHubやEngineering Ladderをご覧いただきたいのですが、明文化するにあたってとくに意識しているのは、「チーム開発に貢献できる」人材であることです。1人の能力として突出していることも重要ですが、エキスパートとして周りのメンバーに良い影響を与えることができるのか、チームとしての総合力を高めることに貢献し、プロダクトを良くしていけるかどうか、その観点を重要視しています。同時に、Individual Contributorがきちんと評価される環境であることも重要視していて、Managerはあくまでロールの1つなので、Managerにならなくとも評価されるということがわかるような記述にしています。

――この文章をまとめるにあたっては、どのようなメンバーでどのように決めていったのでしょうか。

廣井：アイデアを出した名村を中心に、私の他、各EMなどさまざまなポジションですが、共通しているのは、最初に関わったメンバーは皆「自分でやってみたい」と自発的に参加している点です。

また、当初はプロジェクトメンバーの7割近くが海外メンバーだった点も特徴的でした。冒頭でも述べたように、日本と海外（とくに英語）では、単語が持つ意味、その裏に含まれる意図が異なりますから、海外メンバーが積極的に参加してくれたことは大きかったです。

――エンジニアの視点だけでは評価との整合性が難しいのではと思いますが？

廣井：おっしゃるとおりで、エンジニアのボトムアップだけでまとめたものではありません。形がまとまった後、最後にディレクターやVP、そして、HRがチェックをして、それぞれの立場でズレがないこと、その上で、メルカリのエンジニアとして行動すべき姿をまとめています。

浸透の難しさ～リリース、運用から見えたEngineering Ladderの課題

――すでにEngineering Ladderによる組織づくり、そして、評価をされていると聞きます。Engineering Ladderを導入して、社内からはどのような反響がありましたか？ また、廣井さんご自身で感じたこと、気づいたことはありますか？

廣井：Engineering Ladderは2020年の初めから導入し、運用を開始しています。まず、運用開始前から課題と感じていたのが、社内全体にどのように浸透させるか、周知の次の部分でした。というのも、もともとのドキュメントや発表自体を共有していたことで、ほとんどのエンジニアがEngineering Ladderの存在自体を知っていました。しかし、記載されている文章、9つのプリンシプルに紐づく内容を、全員に浸透させるには多くの時間がかかりました。たとえば、エンジニアでも300人いる中で、SREやフロントエンドなど、立場によって解釈が異なり、もっと抽象的にしてほしいというような意見もありました。

ですから、「この項目はこのように理解しました」「ここはこう表現したほうが良いのでは」など、エンジニア同士で共有できる場を用意しています。

この点については、実際にEngineering Ladderに触れて、使ってもらうことが一番大事で、そのためにはきちんとした効力をもつことが重要だと考え、評価での利用を決定しました。

また、運用を開始するまでに、どのようなフォーマットを利用すべきか、実際にどう運用に落とすか、マネージャと評価されるエンジニア間での意思の疎通にも苦労しました。とくに、各グレードと内容の評価をどのように可視化するかなど、評価での利用方法が難しかったです。たとえば、L1、L2と順を上げていって記載されるものの中には、プリンシプルでの順番が前後している表現があったり、また、評価においては、特定のスキルはL1でも全体の評価としてL2というような会話もされています。このように、さまざまな意見が出て議論が活発に行われました。

（出典）メルカリエンジニアリング

――約1年の運用をして見えた課題の中で、すでに解決したり、変更している部分は出てきましたか？

廣井：もちろん、100％満足した声だったわけではありません。

（出典）メルカリエンジニアリング

2020年8月に行ったアンケートの結果を見ると、74％が10段階で7以上の評価をしていますが、一方で、5以下の評価もありました。その中で、とくに多かった（ネガティブな）声は「細かすぎる」「読むのに時間がかかる」と言った、理解の部分、使いやすさの部分でした。

また、評価する側からも、Engineering Ladderに準じて細かく評価することを自分のチーム全員に対して全グレード、全スキルを見て行っていくのはコスト（工数）が大きくなるという声が上がりました。メルカリは年4回の評価を行い、ピアレビューも導入しているためです。とくに多くのピアレビューとメンバーの評価の両方を行うEMの評価工数の大きさは問題となっていました。

そこで、現在は、（評価する側・される側も）自分のグレードをしっかり見る、そして、1つ上のグレードを見ることを推奨するようにしています。

――そのような課題に対して、運用で調整をする他に、Engineering Ladderそのものをアップデートしていくことはあるのでしょうか？

廣井：はい、運用でカバーするだけではありません。Engineering LadderはGitHubで公開されているため、エンジニア自身がIssueを立てることができ、Pull Requestなどのコントリビュートは誰でも行えます。エンジニア自身がEngineering Ladderにコミットすることは、すなわち自分自身の評価にコミットすることでもあり、（評価に対する）納得度が高まります。

――GitHubでの公開は、その効果も狙ってのことですか？

廣井：その点に関しては、Engineering Ladderだけというわけではなく、CTO名村のOpen Organizationという考えがベースにあり、「コードをオープンにする」だけでなく「カルチャー（文化）をオープンにする」という考えが強く反映されています。

名村自身が発信しているメッセージや外部でのイベントでも繰り返し強調しているように、メルカリとしてはエンジニアリングカルチャーを外部に見せていく、オープンにしていくというのはエンジニアチームの根底にあります。この部分を共有していくこともメルカリのエンジニア組織として重要なことで、つねに意識して組織づくりに反映されています

今回のEngineering LadderがGitHubで公開されたという点も、その背景によるところが強いですね。

評価する側・される側双方からのコントリビュートと共通認識の余白から生まれるコミュニケーション

廣井：そもそもとして、Engineering Ladderは評価のための制度ではなく「プロダクト」に近い存在だと考えています。他のプロダクトと同様に改善し、アップデートしていきます。現在は、立てられたIssueをもとに半年に一度、アップデートしています。

このように、評価軸ではあるものの、全エンジニアが活用するためのプロダクトでもあるEngineering Ladderは、どこかの部署や特定の立場の人間だけが管理するのではなく、全員で共有して、全員で改善できる点が強みと言えるのではないでしょうか。

私としては、この点が、Engineering Ladderリリース後の1つの成果と思っています。というのも、行動の明文化という定量的ではない内容に対して、キャリアやスキル、国籍などの背景が異なるエンジニア同士が共通の意識を持つことは非常に難しい中、評価する側・される側がコミュニケーションを取ることで、そのズレの部分、言い換えれば余白の部分を埋めることができ、結果として、チームビルディングにつながっているからです。

たとえば、組織変更で上長が変わった場合に、「Go Bold」が持つ意味が人によって変わってしまうのは困るわけですが、Engineering Ladderの存在がその課題を解消してくれます。

これこそがまさに、Engineering Ladderの最初の目的の1つでもあるメルカリのエンジニア文化の醸成だからです。さらに行動の言語化、そこで見つかった余白を通じてエンジニア同士がコミュニケーションを図ること、その結果が日本と海外という言語の壁を壊し、文化の共有にもつながっていますし、Engineering Ladderがメルカリの文化発信ツールとして優れていると感じます。

Engineering Ladderの範囲を拡大し、グループ内人事交流を活性化していく

――リリースして運用がスタートして1年が経過しました。廣井さんの立場からどのように受け止めていますか。

廣井：言語化したことでの、Engineering Ladderとグレードとのブレが生じるかどうかという懸念もありましたが、私の感触としては上ブレ・下ブレは少なく、適正にではないかと感じています。

評価の点で言うと、Engineering Ladderが評価のすべてではなく、Engineering Ladderは評価のうち、行動の評価に当たります。それ以外の評価、いわゆる成果物の評価（OKR）はまた別の基準で行っています。今後もEngineering LadderとOKR双方を活用して評価、人事考課をしていきます。

その他、内部から上がった声では、採用という観点でEngineering Ladderという言語化されたプロダクトによって共通基準ができた、という好意的なものもありました。

どういうことかと言うと、たとえば異なる部署間での採用に関する話題で「自分の部署はEngineering Ladderで言えばこういう人材を採用した」「評価にあたっては○○の部分を基準にした」など、Engineering Ladderを基準にしたコミュニケーション、また、採用への利用が行われています。

――最後に、廣井さんの立場から見て、この先の可能性や取り組みたいことがあれば教えてください。

廣井：1年が経過して、今後2つのことに取り組みたいと考えています。1つは使いやすさの追求、もう1つはEngineering Ladderの適用範囲の拡大です。

使いやすさの追求は前述のように、GitHubで公開していますので、エンジニア各人がコントリビュートしながら、私たちにとって最適なもの、使いやすく、何より使った結果、メルカリのエンジニア組織が強くなることにつながるプロダクトを目指します。

また、今後、さらに組織が大きくなっていくと、Engineering Ladderを知らない人材がますます加入してくることが想定されます。使いやすさで取り組むべき次の課題は、この誰もがすぐに理解しやすいプロダクトにすることです。

それに付随する点で、各Lごとの期間（レベルアップ）の基準も検討しています。たとえば、インドのエンジニアなどは自分がいるLから次のLへ上がる期間を気にする傾向があります。これについては、もう少し利用を進めてから慎重に検討したいと考えています。

もう1つはEngineering Ladderの適用範囲の拡大です。先ほどもお伝えしたとおり、現在のEngineering Ladderは、メルカリ（JP）のエンジニアを対象としていますが、今後、メルカリ（US）、メルペイにも適用範囲を広げていきたいです。現状だと、カンパニーごとのチーム異動は人材流動の活性化は新しいシナジーを生み出す可能性がある一方で、異動した結果、チームの再構築に時間や手間がかかるというリスクも伴います。

しかし、Engineering Ladderの適用範囲がメルカリのグループ全体に広がれば、単なるスキルセットの整合性だけではなく、グループ全体のエンジニアにとって、行動、それに紐づく文化の共有・整合性が取れるようになります。結果として、前述の懸念点を気にせずに人の動きを活性化させ柔軟な組織変更がしやすくなり、新しいシナジーや新しい価値の創造につながります。

今後もEngineering Ladderを積極的に活用し、エンジニア同士のコミュニケーションの活性化、そして、エンジニア間で行動指針と目指す理想を共有することで、これからのメルカリのエンジニア文化を醸成させていきたいですね。

――ありがとうございました。

（聞き手：株式会社技術評論社　馮富久、撮影：中村俊哉）