エンジニアのキャリアラダーの横断比較
そだてる編集部|2026.10.10
先に結論
- 公開されている国内外 10 社のラダーは、段数が 5 段から 8 段までばらつき（段数を公開していない会社もある）、IC と EM の分け方は「別のトラック」「同じラダーに EM 向けの項目を足す」「EM 専用」の 3 型に分かれる。評価に使う会社と、評価と直結させない会社がはっきり分かれる。
- 作った会社が後から直したのは、全社の等級との食い違い、記述の抽象さ、評価の手間、生成 AI による期待の変化だった。作ったまま廃止したという公開の記録は見つからず、公開されているのは半年ごとの改定や数年での全面刷新といった、直し続けた記録だった。
- 編集部の見立ては、ラダーは作ることより使われ続けることで効くということ。作る前に、評価に直結させるか、IC と EM をどう分けるか、誰がどの間隔で直すかの 3 つを決めておく。
エンジニアの等級や評価制度の見直しを任されると、最初に出てくる言葉がキャリアラダーです。ラダーは「はしご」のことで、エンジニアが段ごとに何を期待されているかを書き出した表を指します。全社の等級制度とは別に、エンジニア向けに作る会社が増えています。
「キャリアラダー エンジニア」で検索すると（2026年10月10日、編集部が Google で確認）、メルカリや LayerX の公式の記事、海外の Engineering Ladders の翻訳、個人の設計ガイドが上位に並びます。各社の例は 1 社ずつ読めますが、同じ物差しで並べた比較は見つかりませんでした。「エンジニア 評価制度」で検索すると、上位は人事 SaaS や転職媒体の記事が占めています。
この記事は、ラダーを公開している 10 社の例を次の物差しで並べます。
| 物差し | 見ること |
|---|---|
| 段数 | 何段に分けているか |
| 評価の軸 | 何を見て段を決めるか |
| IC と EM の分け方 | 専門職とマネージャーの道をどこで、どう分けるか |
| 評価との結びつけ | 人事評価や給与に直接使うか |
| 改定 | 作ったあと何を直したか |
先に用語をそろえます。
| 用語 | この記事での意味 |
|---|---|
| IC（Individual Contributor） | 部下を持たず、自分の技術で成果を出すエンジニア |
| EM（Engineering Manager） | エンジニアのチームを率い、採用・育成・評価を担うマネージャー |
| TL（Tech Lead） | チームの技術的な方向を決めるリーダー。部下の評価は持たないことが多い |
| グレード・等級 | 社員の段。多くの会社で給与の幅と結びつく |
| ラダー | グレードごとに期待される行動や成果を書き出した表 |
全社の等級がエンジニアの仕事を表せない
各社がラダーを作った理由を並べると、共通する言葉が出てきます。全社の等級の言葉が抽象的で、エンジニアの仕事に当てはめられないという言葉です。
| 会社 | 作った理由として書いていること |
|---|---|
| メルカリ | 全社のグレード定義はすべての職種に使えるよう抽象度が高く、エンジニアの仕事に当てはめにくい場合がある |
| アンドパッド | 旧制度はセールスやカスタマーサポートと共通で、エンジニアのキャリアパスを表せなかった。表現が抽象的で解釈に幅が出て、評価者ごとにずれた |
| みてね（MIXI） | MIXI の全社の等級定義は職種を問わない汎用的な内容で、みてねのエンジニアに求められるスキル・マインド・行動が不明確だった |
| LegalOn Technologies | 旧基準では、技術力は高いが成果に結びつかない人のほうが、安定して成果を出す人より高く評価されてしまった |
| LayerX | 組織の急拡大で文化や習慣が薄れるリスクがあった。半年で EM になった 3 人は入社 3 か月以内だった |
出典は、メルカリ（2023年9月8日）、アンドパッド（2025年11月21日）、みてね（2024年3月12日公開、2026年4月10日更新）、LegalOn（2023年8月4日）、LayerX（2023年11月7日）です。
みてねはもう 1 つ理由を挙げています。育成・目標設定・人事評価のサイクルが、各 EM の属人的なマネジメント力に左右されることです。同じ等級の言葉でも、読む EM によって期待が変わってしまう。ラダーは、その解釈の幅を狭めるための道具として作られています。
エンジニア組織での違い
段を分けるのは「影響範囲」
全社の等級は、職種を問わない言葉で書く必要があります。エンジニアのラダーは、段の違いを仕事の影響が届く範囲で書く例が目立ちます。
- メルカリは、能力は影響範囲（自分の仕事からチーム、複数チーム、組織全体、会社全体へ）と頻度（ときどき・たいてい・一貫して）で段が上がるとしています（mercari/mercari-engineering-ladder、2025年7月11日最終更新）
- LayerX は、高いグレードに求めることを「不確実性が高いことを任せられること」と一言で定義しました。不確実性は「対象の大きさ・複雑さ × 時間軸 × コミュニケーションおよび影響の範囲」で決まるとし、グレード 1（機能・3 か月）からグレード 5（会社・複数年）までを表で示しています
- はてなの EM のラダーは、各レベルを影響範囲（自分・ペアから本部全体まで）と社内のグレードに対応させています（はてな、2025年12月8日）
人事の目線で言い換えると、「Go が書ける」「AWS が分かる」のような技術の名前は段の違いになりにくい、ということです。どの技術でも、届く範囲が自分の担当か、チームか、会社全体かで段が決まります。
専門職とマネージャーの二本立て
もう 1 つの違いは、マネージャーにならなくても上がれる道を用意することです。エンジニアは技術を深めて組織に効く人と、チームを率いて組織に効く人に分かれます。全社の等級が管理職になることを上の段の前提にしていると、技術を深めたい人の行き先がありません。
ただし、二本の道をどう作るかは会社で分かれます。次の章の比較表で見ます。
公開例の比較
10 社の比較表
公開資料で確かめられたことだけを並べます。空欄や「公開されていない」は、やっていないことを意味しません。
| 会社 | 段数 | 評価の軸 | IC と EM の分け方 | 評価との結びつけ |
|---|---|---|---|---|
| メルカリ | 8 段のうち MG1〜MG6 の 6 段を記述 | 7 項目（Commending Bold Challenges・Vision・Focus on the Mission・Teamwork・Professionalism・Continued Learning・Move Fast for Engineers） | 同じラダーに EM 向けの記述を足す（MG3 以上） | 主に評価と目標設定に使う |
| LayerX | 5 段 | 各グレードに 3 つの軸（名前は公開されていない） | 公開されていない | 評価と直結させない。2023年10月から一部のロールで仮運用 |
| LegalOn Technologies | L1〜L6 の 6 段 | 成果・振る舞いベース | IC・TL・M の 3 つの Job Track | グレード評価（通期、年額給与に反映）の基準 |
| アンドパッド | 5 段 | 約 200 項目（各職種 20 項目前後） | IC・Manager・Director の 3 職種 | 項目ごとのコンピテンシーシートと半期のコミットメント評価を組み合わせて評価 |
| みてね（MIXI） | 公開ページから確認できず | 公開ページから確認できず | 分けない。項目や等級ごとに EM 向けの項目を明示 | 育成・目標設定・評価のサイクルに使う。項目の網羅は必須としない |
| サイバーエージェント | 公開されていない | 5 つの観点（専門性・戦略性・業務遂行力・オーナーシップ・フォロワーシップ） | 4 つのキャリア（エキスパート・テックリード・ビジネスリード・EM） | 評価制度そのもの（JBキャリアプログラム） |
| はてな | EM の 4 領域を各 LV1〜10 で示し、社内のグレード 1〜6 以上に対応 | ピープル・プロジェクト・テクノロジー・プロダクトの 4 領域 | EM 専用のラダー | 「育成と評価軸」として発表 |
| オープンワーク | 5 レベル | 5 軸（テクノロジー・システム・人・プロセス・影響） | 公開されているのは職種別の 2 本（Web・インフラ） | 評価に使うことは想定しない |
| ispec | Developer 1・2 のあと、TL 1・2 と EM 1・2 に分岐 | 5 項目（Technology・System・People・Process・Influence） | Developer 2 のあとで分岐 | 公開されていない |
| Dropbox | IC1〜IC7、M3〜M7 | 職種ごと（SWE・QE・SRE・MLE など）に定義（評価の軸は調査していない） | 別のトラック | 昇格のチェックリストではないと明記 |
出典は各社の公開資料です（末尾の「出典」にまとめました）。オープンワークと ispec は、海外の Engineering Ladders（Jorge Fioranelli）を土台にしています。Engineering Ladders は Developer・Tech Lead・Technical Program Manager・Engineering Manager の 4 本のラダーを持ち、マネージャーが部下と次のレベルを話すための枠組みとしています（engineeringladders.com）。
表から読めること
段数はばらつきます。 LegalOn は 6 段、アンドパッド・LayerX・オープンワークは 5 段です。一方で、Dropbox は IC が IC1〜IC7 の 7 段（EM は M3〜M7 の 5 段）、メルカリは全 8 段（記述は 6 段）、はてなは EM の領域ごとに LV1〜10 を置いています。ispec は Developer 2 段のあと、TL と EM がそれぞれ 2 段です。みてねとサイバーエージェントは段数を公開していません。上位の段に肩書きを与えている例もあります。メルカリは MG6 に Principal Engineer、MG7 に Distinguished Engineer の肩書きを与えています（Roles | メルカリエンジニアリング）。
IC と EM の分け方は 3 型あります。
| 型 | 会社 | 特徴 |
|---|---|---|
| 別のトラックにする | LegalOn・アンドパッド・サイバーエージェント・Dropbox・ispec | 道ごとに期待を書く。TL を IC と EM の間の独立した道にする会社もある |
| 同じラダーに EM 向けの項目を足す | メルカリ・みてね | 期待の土台は全員共通。EM になると項目が増える |
| EM 専用のラダーを持つ | はてな | EM の能力を領域ごとの「凹凸」として扱う |
アンドパッドは、Tech Lead から IC に戻ることを降格としないとラダーの図で明示しました。道を分けるなら、道の間を行き来できるかも決めておく必要があることを示す例です。
はてなは、EM の 4 領域すべてを 1 人でカバーするのは難しいとし、どの領域が得意かを「EM の個性」として扱っています。はてな全体、あるいはチーム全体で必要な能力がそろえばよい、という考え方です。
評価との結びつけで、立場がはっきり分かれます。
| 立場 | 会社 | 理由として書いていること |
|---|---|---|
| 評価に使う | メルカリ・アンドパッド | 全社の等級がエンジニアの仕事を表せないので、エンジニア向けの評価の基準として作った |
| 評価に使う | LegalOn | 旧基準では、技術力は高いが成果に結びつかない人のほうが高く評価されてしまった。創業初期の IC の評価軸が中心で、EM の評価が評価者によって大きく異なるおそれがあった |
| 評価に使う | サイバーエージェント | AI によって開発生産性が高まるほど、「何を作ったか」だけでなく「技術によってどのような変化を生み出したか」が問われる（刷新の背景として） |
| 評価と直結させない | LayerX・オープンワーク | 制度を組織の変化にリアルタイムで追随させるのは現実的でない（LayerX）。評価はパフォーマンスとスタイルで行っている（オープンワーク） |
評価に使う会社も、ラダーを機械的に当てはめることは避けています。
- メルカリの README には、ラダーは文字どおりに読むものではなく、自分の仕事に当てはまる部分だけを見てマネージャーと期待をすり合わせるものだと書かれています
- みてねは、各等級の項目を網羅的に満たすことは必須とせず、EM とメンバーの対話で濃淡をつけて運用します
- Dropbox は、フレームワークは昇格のチェックリストではないと明記しています
- LayerX は、マス目を埋めると自動的に昇給する「星取表」をアンチパターンとして挙げています
LayerX は社内の文書にも、ラダーに書かれたとおりに行動しても高い評価に直結するわけではないと明記し、業績評価や昇給を約束するものではないとしています。
他社のラダーを借りてよいか
メルカリのラダーは CC0（著作権を主張しない宣言）で公開されています。LegalOn は新しい基準を作るとき、メルカリ・CircleCI・Dropbox のラダーを参考にしました。メルカリには文言の水準で参考にした許可を取り、快諾を得たと書いています。メルカリの側も、LegalOn がこのラダーを参考に評価基準を作ったことを振り返りの記事で紹介しています。
一から書き起こす必要はありません。ただ、次の章で見るとおり、借りた文言を自社の全社の等級とどうつなぐかで、作った会社は苦労しています。
作ったあとに直したこと
各社の記録で最も役に立つのは、作ったあとに何が起きたかです。
メルカリ: 全社のグレードと合わなくなった
メルカリは 2023年9月の時点で、ラダーを作ってから約 3 年が経っていました。1 年目の課題として次の 2 つを挙げています。
- 書かれている内容にわかりにくい部分がある
- 全社のバリューやグレード定義と完全に一致していないようにみえる
その後、全社のグレード定義が刷新され、ラダーとの整合が崩れました。エンジニア組織だけが独自の評価記入フォーマットを使う状態になっていたため、2 年目に全社のグレードを分解した Key behaviors でラダーを構成し直し、全社と同じフォーマットに戻しています。
直し方も仕組みにしています。ラダーは社内の GitHub で管理し、メンバーが Issue や Pull Request で改善を提案できます。プロジェクトのメンバーがレビューしたうえで、半年に一度リリースしています。GitHub はプログラムのソースコードを管理する場所で、Pull Request は変更の提案を指します。エンジニアが普段の仕事と同じやり方で制度に意見を出せる形です。
ラダーと合わせて、1 か月程度の短い間隔でマネージャーとメンバーが認識をすり合わせる Continuous feedback も進め、メンバーの評価への満足度が上がったとしています。満足度の数値は公開されていません。
一方で、ラダーを重視しすぎると、入社したばかりのメンバーがラダーの内容がすべてだと考えてしまう恐れも挙げています。
LegalOn: 評価はしやすくなったが、育成で使いにくくなった
LegalOn は 2022年10月に評価基準を刷新し、約 10 か月後の 2023年8月に Job Expectation として公開しました。旧基準は社内の相対的な能力をもとにした 4 つ程度の評価軸で、創業初期に必要だった IC の軸が中心でした。EM の評価が評価者によって大きく異なるおそれもありました。
新しい基準は能力ベースから成果・振る舞いベースに変えました。結果として書いていることを並べます。
| 変化 | 内容 |
|---|---|
| 良くなったこと | 評価はしやすくなった |
| 悪くなったこと | 評価の観点が増えて、評価にかかるコストは上がった |
| 悪くなったこと | 入社前の実績が無い採用と、身につける能力を示したい育成では、かえって使いにくくなった |
| 残っている課題 | 成果基準の記載が抽象的すぎて、何ができればどのグレード相当かが分かりにくく、属人化している |
| 残っている課題 | 評価以外の日々の指針としても使ってほしいが、まだ根付いていない |
社外に公開した理由の 1 つに、社内のエンジニアが目にする機会を増やすことを挙げています。作った基準が社内で読まれ続けるかを、作った側が気にしていることが分かります。
LegalOn は現在、グレード評価（通期、年額給与に反映）と成果評価（半期、成果賞与に反映）の 2 つを分けて実施しています（開発職向け会社紹介資料、2026年10月2日最終更新）。
アンドパッド: 試行のあとに正式運用、そして生成 AI
アンドパッドは 2025年上期に新しい評価のプロセスを試行し、2025年下期から正式に運用を始めました。その 1 年を振り返る記事で、AI コーディングの進化で、1 年前に想定した「求められる能力」が変わってきていると書いています。Grading Definition は更新し続けるものと位置づけています。
サイバーエージェント: 2026年に全面刷新
サイバーエージェントは 2026年に、エンジニア向けの評価制度「JBキャリアプログラム」を全面刷新しました。背景として、AI によって開発生産性が高まるほど、「何を作ったか」だけでなく「技術によってどのような変化を生み出したか」が問われることを挙げています（Careers | サイバーエージェント 技術情報）。同じグレードでも、キャリアごとに求める強みが異なるとしています。
改定の記録のまとめ
| 会社 | 直したきっかけ | 直し方 |
|---|---|---|
| メルカリ | 全社のグレードの刷新で整合が崩れた。記述が分かりにくい | 全社のグレードを分解して構成し直す。半年ごとのリリース |
| LegalOn | 能力ベースの旧基準で、成果を出す人が報われなかった。EM の評価がぶれた | 成果・振る舞いベースに刷新。その結果、評価のコストと育成での使いにくさが出た |
| アンドパッド | 全社共通の制度がエンジニアのキャリアを表せなかった。生成 AI で期待が変わった | 試行を経て正式運用。定義は更新し続ける |
| サイバーエージェント | 生成 AI で問われる成果が変わった | 4 つのキャリアと 5 つの観点で全面刷新 |
作ったまま運用されずに廃止した、という国内の公開の記録は見つかりませんでした。公開されているのは、使い続けて直した記録だけです。うまくいかずにやめた会社は記事を書かない可能性があるため、「廃止した例が無い」とは言えません。
ラダーの副作用
ラダーを作ることに慎重な立場も、根拠とともに並べます。
- オープンワークは、ラダーはマイナスに働くこともあるため、評価との紐付けは慎重に検討したほうがよいと書いています（オープンワーク、2022年2月9日）
- LayerX は、ラダーは下手をすると生産性の悪化や成長の妨げになる可能性があると書いています
- LegalOn は前述のとおり、評価基準に寄せた結果、採用と育成では使いにくくなったと認めています
- 組織の規模が 200 名弱のスタートアップでエンジニアの評価制度を作り直した元 CTO は、個人の note で、正しく評価しようとするほど運用コストが跳ね上がり、等級を上げて給与を上げることだけを目的にする動きも生まれたと振り返っています（2024年1月28日）。企業名は書かれていません
- 同じ元 CTO は、エンジニアが数名の規模や、評価に相応のコストを払えない組織では、こうした制度作りは不要だと書いています
オープンワークは、ラダーを評価に使わずに、自社の等級との関係を確かめています。等級が高いほどラダーのレーダーチャートの面積が大きく、ある程度の関連が見られたとしています。評価に直結させなくても、ラダーが等級の説明として働くことを示す例です。
編集部の見立て
ここからは、この媒体の見立てです。
ラダーは、作ることより使われ続けることで効くと考えます。
根拠は 3 つです。
- 公開されている改定の記録は、どれも運用の中で見つかった問題を直したものです。メルカリの全社のグレードとの食い違い、LegalOn の抽象さと評価のコスト、アンドパッドとサイバーエージェントの生成 AI による期待の変化は、作った時点では見えていませんでした
- 作った側が「読まれ続けるか」を気にしています。LegalOn は日々の指針として根付いていないことを課題に挙げ、社内で目にする機会を増やすために社外へ公開しました。メルカリは改善の提案を Issue や Pull Request で受け、半年ごとにリリースしています
- 評価に使う会社も使わない会社も、ラダーを EM とメンバーの対話の材料にしています。メルカリの README、みてねの運用、Engineering Ladders の目的は、どれも「話し合うための枠組み」として書かれています
反対の根拠も重く見ています。運用し続けるにはコストがかかります。LegalOn は評価のコストが上がったと書き、元 CTO の note は運用コストが跳ね上がったと書いています。エンジニアが数名の組織では、ラダーを作るより、EM が 1 人ずつと期待を話すほうが安いかもしれません。また、作ったまま使われなかった例は公開されていないため、「使われなかったラダーは効かなかった」と確かめることはできません。
評価に直結させるかどうかは、この記事の範囲では答えを出せません。評価に使えば読まれ続けますが、LegalOn のように評価の言葉に寄って育成で使いにくくなる。評価から切り離せば柔軟に直せますが、オープンワークの例のように、評価とは別の場で使い続ける仕組みが要ります。どちらを選んでも、誰が、どの間隔で直すかを最初に決めておくことが、使われ続ける条件だと編集部は見ています。
作る前に決めること
人事が現場の EM と話すときの問いを、各社の例と一緒にまとめます。
| 決めること | 選択肢 | 参考になる例 |
|---|---|---|
| 全社の等級とどうつなぐか | 全社のグレードを分解して作る / エンジニア独自に作る | メルカリは独自に作ったあと、全社のグレードを分解する形に構成し直した |
| 段数 | 全社の等級に合わせる / 独自に置く | 公開例は 5〜8 段とばらつく（Dropbox の IC は 7 段、メルカリは 8 段） |
| 段を分ける言葉 | 影響範囲 / 不確実性 / 技術の深さ | メルカリは影響範囲と頻度、LayerX は不確実性 |
| IC と EM の分け方 | 別のトラック / 同じラダーに EM 項目を足す / EM 専用 | 3 型。道の間を戻れるかも決める（アンドパッド） |
| 評価に直結させるか | 評価の基準にする / 育成と対話の材料にとどめる | 評価に使う 4 社と、直結させない 2 社 |
| 能力で書くか、成果で書くか | 能力ベース / 成果・振る舞いベース | LegalOn は成果ベースで評価しやすくなったが、採用と育成では使いにくくなった |
| 誰がどの間隔で直すか | 改定の担当と周期 | メルカリは GitHub で提案を受け、半年に一度リリース |
現場の EM に持っていく質問の例です。
- 今の全社の等級で、エンジニアの昇格の理由を説明できない場面はどこですか
- 技術を深めたい人と、チームを率いたい人で、上がり方を分けたいですか
- TL から IC に戻る人がいたら、降格と扱いますか
- ラダーの文言が古くなったと気づいたとき、誰に言えば直りますか
うまくいっているかの測り方
ラダーの導入で、昇格の説明のしやすさ・離職・異動がどう変わったかを数値で公開している国内の会社は、見つかりませんでした。メルカリは評価への満足度が上がったと書いていますが、数値は出していません。
公開例から、見るとよいものを編集部の提案として挙げます。
| 見るもの | 見方 | 手がかりにした例 |
|---|---|---|
| 昇格の理由をラダーの言葉で説明できるか | 評価会議の記録で、ラダーの項目に触れた昇格の割合を見る | LayerX の「星取表」への注意。項目の数ではなく、説明に使われているか |
| ラダーへの改善の提案が来ているか | 半年ごとの改定で、現場からの提案の件数を見る | メルカリの Issue と Pull Request |
| 評価への納得感 | 評価のあとのアンケートで、期待が分かっていたかを聞く | メルカリの評価への満足度 |
| 道の間の移動 | TL と IC、IC と EM の間を移った人の数と理由 | アンドパッドの TL から IC に戻る道 |
| 等級を上げることだけが目的になっていないか | 1on1 で、目標がラダーの項目の消化になっていないかを見る | 元 CTO の note の等級目当ての動き |
他社と比べて自社がどうかを知りたいときは、比べる相手の数が要ります。公開されている例は 10 社ほどで、ラダーを持たない会社や、持っていても公開していない会社の姿は見えません。この媒体のエンジニア育成の定点観測は、公開資料に出てこない各社の実態を集めるためのものです。
出典
- メルカリ: キャリアの明文化から3年間、どんな変化が？ Engineering Ladderの活用と改善、2023年9月8日 / mercari/mercari-engineering-ladder、2025年7月11日最終更新 / Roles | メルカリエンジニアリング
- LayerX: Engineering Career Ladderを作るときに気をつけたこと 其の一、2023年11月7日
- LegalOn Technologies: LegalOn Technologies のエンジニアグレード評価基準を公開します、2023年8月4日 / 開発職向け会社紹介資料、2026年10月2日最終更新
- アンドパッド: エンジニア評価制度を再設計した1年の軌跡とこれからのチャレンジ、2025年11月21日
- みてね（MIXI）: みてねのエンジニアリングラダー、2024年3月12日公開、2026年4月10日更新
- サイバーエージェント: Careers | サイバーエージェント 技術情報
- はてな: エンジニアリングマネージャーの育成と評価軸の考え方、2025年12月8日
- オープンワーク: エンジニアラダーでメンバーの成長を支援する取り組み、2022年2月9日 / openwork-oss/engineeringladders
- ispec: ispec-inc/EngineeringLadders
- Dropbox: Dropbox Engineering Career Framework / Overview
- Engineering Ladders: Engineering Ladders: A framework for Engineering Managers
- 元 CTO の note: エンジニア評価制度をゼロから作り直して運用した話、2024年1月28日
確かめられなかったこと: LayerX の 3 つの軸の名前と仮運用の結果、みてねの等級の数と評価項目の名前、サイバーエージェントのグレードの段数は、公開資料で確認できませんでした。研修資料の索引にある SmartHR・サイボウズ・freee・エムスリーは、エンジニアのラダーや等級の公開を確認できなかったため比較から外しています。クラスメソッドのキャリアラダーの記事は一般的な考え方の解説で、自社のラダーの段数や軸が書かれていないため、比較表に入れていません。
