はじめに
メルカリ Engineering Office マネージャーのhiroiです。
我々のチームでは「全てのエンジニアに最高の従業員体験を」というミッションを元に、様々な活動を行なっています。あまり馴染みのないチーム名だと思いますが、もっと詳しく知りたいという方は、こちらの記事で活動の紹介をしています。
私が入社して初めて携わった仕事が、Engineering Ladderの作成です。
これはエンジニアとしてのあるべき姿や、キャリアステップを言語化したもので、先日、Mercari Engineering Webサイトにてどなたでも見られる形で公開しました。
これを機に、Engineering Ladderがなぜ作られたのか、どうやって作ったのか、実際作ってみてどうだったのかということについて、記事にします。
こんな人におすすめの記事です
本記事は、エンジニアのキャリアや文化形成に関わるEngineering Ladderについて、メルカリでそれを作ることになったきっかけ、作成の過程、そしてどんな効果があったのかを解説します。
エンジニアの組織作りや、文化作りにトライしている方はもちろん、組織作りに影響をもつEMや、将来EMを目指している方などにもオススメです。
メルカリのEngineering Ladderは、ボトムアップで、継続的にバージョンアップされる文書化された文化という点が特徴です。そういった仕組みを作りたいと思っている方には特にオススメです。ご意見もお待ちしています。
要約
メルカリの成長によって多様性が増していくのと同時に、エンジニア達の方向性、認識のズレが発生しやすいという課題が生まれました。この課題を解決すべく、Engineering Ladderという仕組みを導入するプロジェクトが立ち上がりました。
エンジニア文化の詳細な言語化により認識ズレの防止と、議論の場を作ることが目的です。Engineering Ladderは、EM、メンバーなどのボランティアを中心としたプロジェクトにより作られました。
様々なトライアルを重ねた後、現在では正式なエンジニアの評価や採用の軸として利用されています。Engineering Ladderを作った結果、評価や採用に関するメンバー間のズレが減ったり、文化発信がしやすくなったりといった効果があらわれました。
そもそもEngineering Ladderって？
Engineering Ladderと聞いて、ピンと来る人は少ないと思います。私も入社するまで知らない概念でした。
もともとEngineering Career Ladderがフルネームで、一般的にはCareer Ladderと呼ばれるものの一種です。今は社内ではEngineering Ladderと呼んでいます。
一般的には、会社内での仕事の内容を難易度や給与に応じて細分化し、職務に必要なスキルを明確にすることで、どんなキャリアを歩めるかを見える化する仕組みのことです。他社の例をみていると、等級（グレード）と紐づいていることも多いです。
エンジニア向けには海外の事例が多く、Spotify、Medium、Circle CI、Googleなどで利用されています。興味がある方は「Engineer Career Ladder」などで検索してみてください。
メルカリでのEngineering Ladder
メルカリのEngineer Ladderでは、社内のグレードシステムに合わせて細分化をし、グレードごとに期待されるスキル、コンピテンシーを記載しています。主に評価や採用、ゴール設定などの基準として使われています。
評価の際に、自分のグレードのスキルを満たしているか、次のグレードのスキルをどのくらい習得できているかといった確認をすることで、何が強みで何が弱みか、次にどんなスキルを習得することで、キャリアアップが可能かということが、マネージャーと擦り合わせることができます。
評価での実例
例えば、メルカリでは、もともと3つのバリュー（Go Bold, All for One, Be a Pro）で評価を行なっていますが、それをEngineering Ladderで解釈することで、こう変わります。
[バリュー]
Be a Pro（プロフェッショナルであれ！）
[Engineering Ladder]
テストがしやすく、可読性が高いコードを意識して書ける
バリュー自体は社員にとても浸透しているのですが、「あの行動はプロフェッショナルだったか」「プロフェッショナルな能力があるか」ということを判断する必要があり、人の感じ方に強く依存します。認識がズレやすいですし、議論は平行線になりがちです。
一方、「テストがしやすいコードが書けたか」は、広く知られているノウハウもありますし、評価や認識を揃えることが、比較的スムーズにすみそうです。仮に意見がぶつかったとしても、議論はしやすいはずです。
キャリアアップを考える際にも「もっとプロフェッショナルになってほしいんだよね」と言われるより、「テストがしやすいコードを書けるようになる必要があるね」と言われた方が、どんな学習をすることでキャリアアップができるか、想像がしやすくなります。
このように、Engineering Ladderは評価や、ゴール設定、将来のキャリアイメージ想起、文化醸成等に使われます。
成長し続ける組織で発生した課題とは
Engineering Ladderを作り始めたのは2019年くらいです。当時メルカリのエンジニア組織にはいくつか課題がありました。
組織拡大による課題
一つ目は、組織拡大による働き方の急速な変化による、期待値のズレです。小さい組織と大きな組織では働き方が異なることが多く、一般的には大きくなるにつれ、複雑性が増し、調整や、全体最適のための様々な行動が求められるようになります。
メルカリは急速に拡大したため、大きな組織向けの働き方をする人もいれば、そうでない人もいたり、様々な働き方をしている人がいて、どういう行動が賞賛されるべきなのかという問いに対して、皆が違う答えを持っている状態でした。
そのため、社員同士の期待値が異なり、コミュニケーションや、仕事に対するスタンスなどがバラバラになり、様々な問題が発生していました。
グローバル化による課題
2019年の新卒研修の写真
二つ目は、グローバル化を目指したことによる多様性と、それによる認識のズレの加速です。
現在メルカリのエンジニア組織は約半分が外国籍で、グローバル化が進んでいます。
文化的背景が違う中で、「Go Bold」といったシンプルな言葉に対する認識は、非常にズレやすいという問題がありました。EMも今や半分以上が外国籍の方ですが、EM間でも何がGo Boldなのか、というところにズレがあり、メンバーから「昔のEMはこの行動をGo Boldとして認めてくれたけど、今のEMは違うことをいう！」といった声もあがっていました。
上で紹介した二つの課題、原因はそれぞれ違うのですが、共通しているのは、文化や、皆が目指すべき方向に対して、ズレが発生しているということです。
そのため、目指すべきエンジニア像を明確にすることが、強いエンジニア組織を作るために必要でした。
同じ認識をもつための土台を作り、何がズレているかを議論ができる状態にし、エンジニア組織のカルチャーを強くするためにEngineering Ladderという仕組みが採用されました。
Engineering Ladderによる文化の言語化とリリース、運用
アイデア出しとブラッシュアップ
スタートは、CTOのsuguruさんのドキュメントでした。メルカリのエンジニアに必要とされるコンピテンシーとはというドキュメントが作成され、オープンなディスカッションが行われました。約20のコンピテンシーがこの時点ではあり、それに対し何十人ものエンジニアがディスカッションを重ねて、version1, version2, version3とブラッシュアップされていきました。
Docs上での全てのコメント一つ一つに対し、議論を重ねていくCTOのsuguruさん
また、このブラッシュアップの過程でEngineering Officeをプロジェクトマネージャーとし、EM十数名に参画していただいたコミッティーが発足しました。
このコミッティーを中心に、実際にEngineering Ladderをどう利用するか、どうやってバージョンアップをしていくのかという話がここから進んでいきます。
試験運用からリリースへ
メルカリのエンジニアに必要なコンピテンシーが言語化された後、それを実際に使うためにいくつかの課題がありました。
一つ目はバリューとの関係性の問題です。メルカリとしての文化を失わずに、エンジニアとしての理想のあり方を示す必要があったのです。
ここで、エンジニアに必要な基本的な行動原則として9つの「Engineering Principles」が作られました。類似したコンピテンシーをグルーピングし、バリューとの紐付けを行なったのです。
9つのEngineering Principles。メルカリの3つのバリューを元に作られた
また、どう使っていくかという点で、我々は最初に評価で利用することを決めました。
実際に、評価の軸が変わるということが、文化を変えるということに一番大きな影響を与えるからです。ここで、評価でどのように使うべきか、運用を考える必要がありました。これが二つ目の課題です。
一番大きな論点となったのが、各スキルごとに全グレードを見るのか、それとも自分のグレードを見るのか、という点です。メルカリはグレード制で、一人一人にグレードが定められています。一方、個人個人で得意不得意があるため、当然あるスキルは習得しているが、あるスキルは苦手、ということがありえます。同じグレードだとしても、もっているスキルが全く異なることがあるということです。そのため、グレードとPrincipleでマトリクスを作り、それぞれに点数をつけていく、というアプローチを初めはとりました。できる限り多様性を重視する形で進めたかったのです。
Principleとグレードのマトリクス。Principleごとに全レベルを見るモデル
実際に、プロジェクトメンバーや、募集したボランティアを対象に、このマトリクスを利用した検証を行いました。結果、この手法はいくつかの課題があることがわかりました。
一番がコストの問題です。言語化されたことにより、スキルの一つ一つが今までより詳細に書かれていたため、全ての説明を読むの自体に時間がかかるようになっていました。全文読むとなると、1時間以上かかるという方もいました。また、一つ一つ点数をつけていく際に、他のメンバーと比較するのに膨大なコストもかかっていました。今までは同じグレードの人と比較すればよかったのですが、スキルごとに比較をすることによって、違うグレードの人との比較が発生するようになったためです。
メルカリは年4回の評価を行い、ピアレビューも導入しているため、評価を丁寧にやれる反面、元々工数がかかりがちでした。特にEMの評価工数は、大きな課題となっていました。EMは何人ものメンバーの評価を行い、更にたくさんのピアレビューが依頼されることが多いためです。そのため、この方法は一つの理想かもしれないが、今のメルカリのエンジニア組織で運用するには現実的ではないという結論に至りました。
更に議論を重ね、自分のグレードを中心に見つつ、一つ上のグレードのスキルがあるかも見ることを推奨する、という運用に落ち着きました。一つ上だけを見ることを推奨にしたのは、多くのメンバーはこの条件でカバーできるということと、どうやったら次のレベルに上がれるのかという目線を持って欲しい、という想いからです。
自分のグレードに対する説明が表示され、それを基準に評価する
この運用で更に細かい検証、調整を行なった後、実際にメルカリJPのエンジニア全員を対象とした検証を行いました。実際の評価プロセスの際に、既存評価をしつつ、Engineering Ladderの評価も行う、というものです。既存の評価に加えての作業ということで、かなり大変だったと思うのですが、8割以上の方が実際に評価をしてくれ、仕組みに対するフィードバックをくれました。結果として、全体としての反応は悪くなかったため、その次の評価より、既存評価から差し替えに踏み切り、今では正式にエンジニア評価に利用されています。
リリース後の運用
リリース後も、課題がゼロというわけではありません。現在は、縮小化された数名のボランティアと、Engineering Officeを中心としたコミッティーにより、継続的に改善できる仕組みを提供しています。評価の後にSurveyを行い、定量的な満足度や、使われている時間、定性的なコメントなどを集め、課題登録をし、改善をする、というサイクルです。
Engineering Ladder自体はGitHub上で管理していて、Issueの登録や、改善のためのPull Requestといったコントリビューションは誰でも出来ます。今この記事を書いている時点では、Issueが40を超えています。改善されたEngineering Ladderは、半年に一度リリースされ、評価や採用へ新しいバージョンが適用されます。半年に一度にしているのは、更新頻度が高いと、評価期間中に評価の基準が変わるといった混乱が起こるのと、全社の評価基準とのすり合わせを適宜行う必要があるためです。
社内外への文化発信と、バージョンアップしていく価値観
評価への適用
評価にLadderを利用することにより、マネージャー同士や、メンバー・マネージャー間での理解が促進されました。
評価の満足度を10段階のSurveyでとっているのですが、6以上と回答しているメンバーが約9割で、平均が約8ということで、満足しているエンジニアが多い状態となっています。
2020年8月に行なったSurveyの結果
個々のコメントを見ていくと「エンジニア目線の指標のため、評価がしやすくなった」であったり「評価の理由が今までより納得できる」という意見をいただいています。
採用への適用
採用においては、元々バリューを基盤とした評価があったのですが、Ladderと結びついたことにより、社内の評価制度とより結びつきが強くなりました。
今では、Ladderをベースとした質問項目なども作られています。
候補者の方に対して、メルカリがどんな人物を求めているのか、どのようなスキルがあれば、どのようなポジションをメルカリで担えるのかということをオープンにすることが可能になりました。
社外公開を始めたのはまだ最近なため、数値的な結果が見えるのはまだまだ先ですが、メルカリの現場が持っているカルチャーをオープンにすることで、会社とマッチしているかを候補者の方がより判断しやすくなったのではと思います。
文化発信への影響
当初予想していた評価や採用以外に、文化発信への影響がありました。目指すべきエンジニア像が明確になったというだけでなく、細かい方向転換や、アップデートの発信がしやすくなったのです。
例えば、今メルカリではドキュメンテーションカルチャーが統一されておらず、大きな課題となっています。今後ドキュメンテーションカルチャーを作っていくといった際に、Engineering Ladder上で、ドキュメンテーションに関するスキルや、期待値を記載することで「こういうドキュメンテーションが出来るエンジニアが求められているんだ」ということを発信することができます。
大元となるバリューを変えるということは中々出来ませんが、それを元に、今、どんな行動が求められるかというのを、組織のチャレンジと共に柔軟にアップデートできるのは、メルカリには非常にマッチしていると感じます。
コントリビューションできる文化
Engineering Ladderというボトムアップな仕組みにより、文化が上から与えられるもので終わらずに、自分たちが作っていけるものへと変わりました。
今までは課題があってもバリューに手を加えることはできませんし、HRに対してフィードバックをすることはできるものの、そもそも「解釈がどうあるべきか」という言語化されていないものに対して、コントリビューションの方法は限られていました。
今は、Engineering Ladderという目に見える文言があり、それをベースにどこに問題があるのかを議論することが出来るようになりました。それに加え、課題の提示にとどまらず、実際に文章をアップデートするためのPRを出すことにより、社内の全エンジニアが直接コントリビューションすることが可能です。もちろん全体の整合性を保つためにきちんとしたレビュープロセスは通るものの、誰もが文化のアップデートに携われるという仕組みは、エンジニア文化とは親和性が高いと感じています。
今後の課題と展望
まだまだEngineering Ladderは課題も多く、やりたいことだらけです。
一つ目は、より使いやすくするための工夫です。今現在メルカリJPには約300人のエンジニアがいて、ほぼ全員がEngineering Ladderを使っています。バリューと比較すると会話がしやすくなったものの、「メンバーと認識が違っている気がする」といった声や、「もう少し具体的でないと考えづらい」といった声も残ります。この課題に対し、詳細な具体例や、こういう行動をしていたらこういう能力がもっていると示せる、といった実例を、誰もが共有できる場を作れないか、といった話を今はしています。
ツールに関しても課題が残っています。元々メルカリでは内製の評価ツールを利用しているのですが、Engineering Ladderを利用した評価をするにあたり、検証の側面が強く、実施後に調整が必要になると見込んだため、内製ツールの実装をいきなり行うのではなく、別ツールによる評価を行なうことにしました。キャリブレーションや給与調整などは全社に合わせて内製ツールを使っているので、評価に関してツールが二つある状態となってしまっていて、ユーザーからはわかりづらいという声があがっています。ツールの一本化が必須です。
また、適用範囲に関しても、やりたいことがあります。メルカリグループでは、メルカリJP、メルペイ、Souzohで共通のグレードをもっており、組織間のエンジニアの流動性も低くありません。本来的には同じ指標が浸透すべきだと考えています。
そのため、範囲の拡張を検討しており、メルカリJPだけでなく、メルペイ、SouzohでもEngineering Ladderの利用を使うための整備をはじめています。
メルカリの良い点の一つとして、グループごとに異なるチャレンジが出来るということがあげられると思います。メルカリ、メルペイ、Souzohで、協力する点はありつつも、組織としてのチャレンジは異なります。エンジニアとしてのキャリアを考えた際に、メンバーがグループ内で別のチャレンジができる形を作れればいいなと思っていて、その際に根本となる文化の軸が同じだと、異動がしやすいし、組織としてより一体感を出せるはずです。
おわりに
以上が、ボトムアップで、継続的にバージョンアップされる文化がどうやって作られるのか、それによってどんなことが起きるのかというメルカリでの事例です。長めの記事となりましたが、メルカリのような規模かつグローバルな組織で、組織文化がどう作られているのかということに興味がある方に、少しでもリアルな現場が伝わればと思います。
また、もし似たような文化が作りたいというチームや、エンジニアがいて、その方の参考にしていただけたら、これほど嬉しいことはありません。ご意見などもお待ちしています。Engineering Ladderも、それに関連する仕組みも、まだまだ発展途上のため、今後もアップデートしていく予定です。
組織全体としてエンジニアがどうあるべき、そのためにはどんな環境が必要かという話がこちらの記事に載っているので、興味がある方は是非ご覧ください。そういう環境で一緒に働きたいという方も募集中です。
