「あの人、技術力はあるんだけどね……」
エンジニアの評価について議論していると、この言葉をよく耳にします。その逆もあって、「技術力は突出していないけれど、あの人がいるとチームが回る」というケースもあるでしょう。
多くの組織で、エンジニアの評価は暗黙のうちに「技術力」と同義で語られています。コードが書ける、アーキテクチャが設計できる、難しいバグを解決できる。たしかにこれらは重要なスキルです。しかし、技術力だけでエンジニアを評価することは、サッカー選手をシュートの精度だけで評価するようなものではないでしょうか。
僕は株式会社MIXIのみてね組織（株式会社MIXIの家族向け写真・動画共有アプリ）で、エンジニアとデザイナーの評価指標——いわゆるキャリアラダー——を自ら設計しました。それぞれ「みてねエンジニアリングラダー」「みてねデザイナーラダー」と呼んでおり、現在はどちらも社外公開しています。
- みてねエンジニアリングラダー: https://team.mitene.us/engineering-ladder
- みてねデザイナーラダー: https://team.mitene.us/designer-ladders
これらを作る過程で、「エンジニアの評価とは何か」という問いに真正面から向き合うことになりました。
そして行き着いた結論は明確でした。技術力は、評価軸7つのうちの1つにすぎないということです。
なぜ「技術力＝評価」という思い込みが生まれるのか
エンジニアリングという職種の性質上、技術力が最も可視化しやすい能力だからではないかと考えています。
コードレビューを見れば実装の質がわかります。技術選定の議論を聞けば知識の深さがわかります。GitHubのコントリビューションを見れば活動量がわかります。一方で、「チームメンバーの成長にどれだけ貢献したか」「顧客価値をどれだけ理解しているか」といった側面は、定量的に測りにくく、評価の対象として取り上げられにくいのです。
結果として、測りやすいものだけで評価が行われ、測りにくいけれど本質的に重要な貢献が見過ごされがちになります。Camille Fournierは著書『The Manager's Path』（2017年）の中で、エンジニアリングマネジメントのキャリアパスにおいて、技術的なスキルだけでなくメンタリングやリーダーシップといった多面的な能力の重要性を段階的に示しています。技術力だけの評価軸では、組織が真に必要としている貢献を正しく認識することが難しいのです。
ラダー設計の背景と哲学
このエンジニアリングラダーを設計するにあたり、出発点にしたのは一つのシンプルな問いでした。「エンジニアとして優秀とは、どういう状態を指すのか」。
このとき、技術力だけを軸にすると、ある問題が起きます。組織にとって不可欠な貢献をしているエンジニアが、「技術力」という物差しでは適切に評価されないという問題です。
たとえば、プロジェクトを確実にデリバリーするエンジニア。顧客のペインを深く理解してプロダクトの方向性に影響を与えるエンジニア。採用活動に積極的に参加し、チームの成長に貢献するエンジニア。技術ブログを書いて組織のブランディングを高めるエンジニア。これらの貢献はすべて、組織にとって非常に大きな価値を持っています。しかし「技術力」という単一の物差しでは、これらを正当に評価できません。
だからこそ、エンジニアの仕事の全体像を捉える多面的な評価軸が必要だと考えました。
Spotifyが公開したホワイトペーパー（Henrik Kniberg & Anders Ivarsson, 2012年）では、自律的なスクワッド（小チーム）によるアジャイル開発が強調されています。こうした自律的なチームが機能するためには、個々のメンバーが技術以外の領域——コラボレーション、リーダーシップ、顧客理解——にも能力を持っていることが不可欠ではないでしょうか。自律的な組織を支える個人に求められる能力は、単一の軸では捉えきれないのです。
7つの評価軸 — エンジニアの仕事の全体像
このエンジニアリングラダーは、7つの評価軸 × 6段階のグレード（G1〜G6）で構成されています。ここでは、7つの軸それぞれについて、なぜその軸が必要なのか、組織にどのような影響を与えるのかを解説していきます。
1. 開発技術 — 実装スキル、ドメイン知識、内部品質、技術的負債、技術的意思決定
最初に挙げるのは、やはり技術力そのものです。実装スキル、ドメイン知識、内部品質への感度、技術的負債への対処、そして技術的意思決定の質。これらはエンジニアの基盤であり、他の6つの軸を支える土台です。
ただし、これは7軸の1つです。7分の1です。もっとも、7軸が均等に重要だと言っているわけではありません。グレードやキャリアの方向性によって重みは変わります。しかし、技術力「だけ」が評価のすべてではないという構造的なメッセージは、ラダーの設計思想として明確に込めています。
Will Larsonは著書『Staff Engineer』（2021年）の中で、Staff Engineerのアーキタイプとして「Tech Lead」「Architect」「Solver」「Right Hand」の4つを挙げています。いずれのアーキタイプも、純粋な技術力だけでなく、組織的な影響力やコラボレーション能力が不可欠とされています。シニアになればなるほど、技術力の比重は相対的に下がっていくのです。
2. 開発プロセス・プロジェクト管理 — プロジェクト管理、プロセス改善
優れたコードを書けるだけでは、プロダクトは届きません。それを計画的にデリバリーするプロセスとプロジェクト管理の能力が必要です。
この軸では、スケジュールの見積もりと管理、リスクの早期発見、ステークホルダーとの調整、そして開発プロセス自体の継続的な改善を評価します。
「エンジニアはコードを書くのが仕事」と思っているエンジニアは少なくありません。しかし実際には、コードを書いている時間よりも、何を作るか決める、どう作るか設計する、進捗を管理する、問題を早期に検知する——こういった活動に費やす時間のほうが多いのではないでしょうか。特にグレードが上がるにつれて、個人の実装よりもチーム全体のデリバリーに責任を持つ場面が増えていきます。
プロジェクト管理能力のないシニアエンジニアは、いくら技術力が高くても、チームのアウトプットを最大化することが難しい可能性があります。逆に、技術力は平均的でもプロジェクトを確実に前に進められるエンジニアは、組織にとって極めて価値の高い存在です。
3. 顧客価値・ビジネス — 顧客理解、ビジネス貢献
エンジニアが作っているものは、最終的に顧客に届くプロダクトです。顧客が誰で、何に困っていて、何を求めているのかを理解しているエンジニアと、仕様書通りに実装するだけのエンジニアでは、アウトプットの質が根本的に異なります。
顧客理解が深いエンジニアは、仕様書に書かれていない「行間」を読み取ることができます。「この仕様だとユーザーは混乱するかもしれません」「こういうエッジケースが実際のユーザー行動では頻繁に起きるはずです」——こうしたフィードバックは、プロダクトの品質を飛躍的に向上させます。
また、ビジネス貢献という観点では、技術的な判断がビジネスインパクトにどう繋がるかを理解していることが重要です。パフォーマンス改善がコンバージョン率にどう影響するか、技術的負債の返済がリリースサイクルの短縮にどう貢献するか。こうしたビジネスとの接続を意識できるエンジニアは、単なる「実装者」ではなく、プロダクトの共同オーナーとして機能します。
4. 開発コラボレーション — コミュニケーション、チームワーク
ソフトウェア開発は、ほぼ例外なくチームで行われます。一人で完結するプロダクトは存在しないと言ってもよいでしょう。コラボレーションの質が、チームのアウトプットの質を直接的に左右します。
この軸では、日常的なコミュニケーションの明瞭さ、レビューの建設性、他チームとの連携、異なる職種のメンバーとの協働を評価します。
Patrick Lencioniは著書『The Five Dysfunctions of a Team』（2002年）の中で、チームの機能不全の根底には「信頼の欠如」があると指摘しています。信頼は、日々のコミュニケーションとコラボレーションの積み重ねから生まれるものです。コードの品質がいくら高くても、レビューで攻撃的なコメントを残すエンジニアや、情報を共有しないエンジニアがチームに与えるダメージは非常に大きいです。
反対に、コラボレーションが優れたエンジニアは、チーム全体の生産性を引き上げる触媒のような存在になります。自分一人のアウトプットが100だとしても、5人のチームメンバーのアウトプットをそれぞれ20ずつ引き上げることができれば、組織へのインパクトはそちらのほうが大きい可能性があります。
5. リーダーシップ — 課題特定・解決、推進力
リーダーシップというと、マネージャーの専売特許だと思われがちです。しかし、ここでいうリーダーシップは役職としてのリーダーシップではなく、行動としてのリーダーシップを指しています。
課題を自ら見つけ、解決に向けて周囲を巻き込み、推進していく力。これは役職に関係なく、すべてのエンジニアに求められる能力です。
Will Larsonの Staff Engineerのアーキタイプでも、すべての類型に共通するのは「組織的な課題を見つけ、自ら動いて解決する」という行動パターンです。指示を待つのではなく、自ら課題を定義し、解決策を提案し、実行に移す。このプロアクティブな姿勢こそが、シニアエンジニアを単なる「ベテランプログラマー」から組織のリーダーへと昇華させるものではないでしょうか。
6. 採用・育成 — 採用活動、メンバー育成
組織は人で成り立っています。どれだけ優れたアーキテクチャを設計しても、それを維持・発展させる人材がいなければ意味がありません。
採用活動への参加は、シニアエンジニアにとって特に重要な貢献です。技術面接でのスキル評価、候補者体験の向上、技術ブランディングを通じた母集団形成。これらはすべて、組織の持続可能性に直結する活動です。
メンバー育成も同様です。コードレビューを通じた技術指導、ペアプログラミング、キャリア相談、暗黙知の言語化。シニアエンジニアが育成に投資した時間は、長期的には自身のコーディング時間よりもはるかに大きな組織的リターンを生む可能性があります。
Camille Fournierは『The Manager's Path』の中で、メンタリングを技術リーダーシップの最初の段階として位置づけています。個人の技術力を高めるフェーズを経て、他者の成長を支援するフェーズに移行することが、エンジニアとしてのキャリアの自然な発展であると述べています。育成は「余裕があればやること」ではなく、シニアエンジニアの本質的な職責だと考えています。
7. 情報発信・アウトプット — 社内外へのアウトプット
最後の軸は、情報発信です。技術ブログの執筆、カンファレンスでの登壇、社内勉強会の主催、ドキュメンテーションの整備。
これらの活動は、しばしば「本業ではない」と軽視されがちです。しかし、情報発信には少なくとも3つの大きな価値があります。
第一に、組織の技術ブランディングです。優秀なエンジニアを採用するためには、その組織がどんな技術課題に取り組み、どんなカルチャーを持っているかを外部に発信する必要があります。
第二に、知識の構造化です。アウトプットする行為そのものが、暗黙知を形式知に変換するプロセスです。野中郁次郎と竹内弘高が『知識創造企業』（1995年）で示したSECIモデルにおける「表出化」にあたります。書くことによって初めて、自分の知識が整理され、他者に伝達可能な形になるのです。
第三に、個人の成長の加速です。アウトプットすることで、自身の理解の浅い部分が明確になり、学びが深まります。発信は受信の何倍も学びがある、というのは多くのエンジニアが体感していることではないでしょうか。
7軸の構造が生むメッセージ
この7つの軸を並列に置くことで、ラダーは一つの強いメッセージを発しています。
「エンジニアの仕事は、コードを書くことだけではない」
このメッセージは、評価面談の場だけでなく、日常のあらゆる場面でエンジニアの行動に影響を与えます。プロジェクト管理を「面倒な雑務」ではなく「評価される貢献」として認識できるようになります。採用活動を「本業の邪魔」ではなく「組織への投資」として捉えられるようになります。
逆に言えば、評価軸が技術力だけで構成されていると、「コードを書いていないと評価されない」というメッセージを組織に発してしまいます。するとエンジニアは、プロジェクト管理や採用、育成にリソースを割くことに後ろめたさを感じるようになる可能性があります。評価制度は、組織の行動規範を規定するものだからです。
デザイナーラダーという拡張
エンジニアリングラダーと並行して、みてねデザイナーラダーも設計しました。
デザイナーラダーは、全社共通のグレード定義と事業部固有の専門領域の2層構造で構成されています。G1からG6の6段階で、エンジニアリングラダーと同様に積み上げ型を採用しました。
デザイナーラダーで特に意識したのは、キャリア志向に応じたカスタマイズの余地を残すことです。UIデザインに特化したいデザイナーもいれば、UXリサーチに軸足を移したいデザイナーもいます。あるいはデザインマネジメントに進みたい人もいるでしょう。単一のキャリアパスを強制するのではなく、個人の志向と組織のニーズを擦り合わせながら成長できる設計を目指しました。
このデザイナーラダーの存在も、後述する「超・T型人材化」と密接に関連しています。
AI時代の超・T型人材化 — 専門性だけでは不十分な理由
ここで、評価の話を少し広い文脈に接続させたいと思います。
「T型人材」という概念は、1980年代にMcKinsey & Companyで使われ始めたとされ、IDEOのCEOであったTim Brownがデザイン組織の文脈で広めたことで広く知られるようになりました。深い専門性（Tの縦棒）を持ちながら、隣接領域にも越境できる幅広さ（Tの横棒）を備えた人材像です。
僕はこれをさらに発展させた概念として「超・T型人材化」と呼んでいます。
AIの力によって、自身の専門分野だけに業務を閉じていると、必然的に時間的余裕が生まれてきます。AIコーディングツールを使えば実装のスピードは劇的に上がります。AIデザインツールを使えばプロトタイプの作成は格段に早くなります。この「余った時間」は、ミッションや目的のために業務範囲を広げる方向に使われるべきでしょう。
つまり、エンジニアがデザインの領域に越境する、デザイナーがビジネスの領域に越境する、といった動きが加速していく可能性が高いのです。
ここで重要なのは、評価軸も超・T型人材化に対応していなければならないという点です。
もし評価が「技術力」だけで構成されていたら、エンジニアが越境する動機は生まれません。「デザインの領域にも踏み込んだけど、評価には反映されない」という状態では、合理的な個人は越境をやめて、評価される技術力の向上に集中するでしょう。
7軸のラダーは、この問題に対する構造的な回答です。顧客理解、ビジネス貢献、コラボレーション——これらの軸があることで、越境した先での貢献も正当に評価されます。超・T型人材化を促進するためには、評価制度自体が多面的でなければならないのです。
ラダーと1on1の接続 — 評価を日常のマネジメントに落とし込む
ラダーは、半年に一度の評価面談だけで使うものではありません。日常のマネジメント、特に1on1との接続が極めて重要です。
1on1について、僕はこう考えています。うまくいっていないと感じても、とりあえず定期的にやっておくのがよいと。うまくいかない理由は、多くの場合、1on1というフォーマット自体にあるのではありません。相手や相手の業務、組織や事業、課題への関心が薄いという、本人たちの意識の問題であることが多いのです。
たとえば、特定のトピックだけに焦点を当てて、毎回「特にありません」で1on1が終了してしまうケース。これは1on1の設計というよりも、対話の幅が狭すぎることが原因ではないでしょうか。こういう場合は、とにかく話題を広げて新しい可能性を模索するほうがよいと考えています。
ここで7軸のラダーが活きてきます。1on1の話題が技術の話だけで終わっているなら、プロジェクト管理の軸について話してみる。コラボレーションの軸で、他チームとの関係について聞いてみる。育成の軸で、ジュニアメンバーの成長をどうサポートしているか議論してみる。
ラダーの7軸は、1on1の「話題のフレームワーク」としても機能するのです。
最終的に1on1で確認すべきことは、個人やチームの目標に向かって計画的に進捗できているか、障害があるか、協力ができるかということです。この目標とラダーの7軸を紐づけておくことで、日常のマネジメントと評価が一貫した体系として機能し始めます。
「目標の時間軸を変える」というテクニック
1on1のもう一つの重要なテクニックがあります。目標の時間軸を変えることです。
多くの1on1は、直近の業務——今週のタスク、来週のリリース、現在のプロジェクトの進捗——に焦点が当たりがちです。もちろんこれは重要ですが、それだけでは長期的な成長やキャリア形成の議論が不足します。
意識的に時間軸を変えてみることをお勧めします。
短期（1〜3ヶ月）: 現在のプロジェクトの目標に対する進捗。目の前の課題と打ち手。
中期（半年〜1年）: ラダーの次のグレードに到達するために必要な成長。現在の評価軸のどこに伸びしろがあるか。
長期（2〜3年）: キャリアの方向性。マネジメントに進むのか、ICとして専門性を深めるのか。あるいは超・T型人材として越境するのか。
コンピテンシー軸: ラダーの7軸それぞれについて、現在地と目標地点のギャップ。
事業目標軸: 事業の成長に対して、自分がどう貢献できるか。プロダクトのロードマップと自身の成長計画をどう接続するか。
時間軸を変えるだけで、同じ人との1on1がまったく異なる対話になります。短期の話ばかりしていた人と3年後の話をすると、「実は将来的にはマネジメントにも興味がある」といった新しい発見が生まれることは珍しくありません。
こうした対話の蓄積が、ラダーの各軸における成長の解像度を上げ、半年後の評価をより納得感のあるものにしていくのです。
採用とラダーの一貫性
補足として、採用の話にも触れておきたいと思います。
僕が採用面接で見ている項目は、大きく6つあります。人柄、プロダクト愛、自発的コミュニケーション、リーダーシップ、視野の広さ、頭の回転の速さ。
これらをラダーの7軸と対応させると、かなりの部分が重なっていることに気づきます。
- 人柄 → 開発コラボレーション（コミュニケーション、チームワーク）
- プロダクト愛 → 顧客価値・ビジネス（顧客理解、ビジネス貢献）
- 自発的コミュニケーション → 開発コラボレーション、情報発信・アウトプット
- リーダーシップ → リーダーシップ（課題特定・解決、推進力）
- 視野の広さ → 複数の軸にまたがる横断的な視点
- 頭の回転の速さ → 開発技術（技術的意思決定）、開発プロセス・プロジェクト管理
つまり、採用の段階から「技術力だけではない」多面的な評価を行い、入社後のラダーでもその哲学を一貫させているということです。採用基準と評価基準が乖離していると、「入社したときに期待されていたことと、評価されることが違う」というギャップが生まれます。この一貫性は、組織の信頼性を支える重要な要素ではないでしょうか。
積み上げ型の設計思想
このラダーは、G1からG6までの積み上げ型で設計されています。これは「G3ができることは、G4もできる」という前提に立っているということです。
なぜ積み上げ型にしたのか。それは、グレードが上がるにつれて「やらなくてよくなること」はないからです。G4になったからといってコードを書かなくてよくなるわけではありません。G5になったからといってチームメンバーとのコミュニケーションが不要になるわけではありません。
むしろ、グレードが上がるにつれて、すべての軸で求められるレベルが上がるのです。G1では自分のタスクを完遂することが求められ、G3ではチーム全体の成果に責任を持つことが求められ、G5以上ではプロダクトや組織全体への影響が求められます。スコープが広がりながら、すべての軸のレベルが底上げされていく。これが積み上げ型の本質です。
ラダーは「地図」であって「答え」ではない
最後に、ラダーの限界についても触れておきたいと思います。
ラダーは完璧な評価ツールではありません。7つの軸を定義しても、それぞれの軸の中での具体的な判断には、評価者の解釈が必ず入ります。同じ「コミュニケーション能力が高い」でも、評価者によって基準が異なることは避けられません。
しかし、ラダーがない状態に比べれば、共通言語としてのフレームワークがあることの価値はとても大きいと感じています。「あの人は技術力が高い」としか言えなかった組織が、「あの人は開発技術は高いが、顧客価値・ビジネスの軸では成長の余地がある」と具体的に語れるようになります。
ラダーは地図です。地図は現実の完璧なコピーではありませんが、地図がなければ目的地にたどり着くことは困難でしょう。ラダーがあることで、エンジニア本人も、マネージャーも、組織全体も、「どこにいて、どこに向かうべきか」を議論するための共通の土台を持つことができるのです。
おわりに — 評価制度は組織のメッセージである
エンジニアの評価に「技術力」は7分の1でしかありません。
この言い方は、もしかすると技術力を軽視しているように聞こえるかもしれません。しかし意図は正反対です。技術力を大切にしているからこそ、技術力だけに評価を押し込めるのは危険だと考えているのです。
技術力だけで評価される組織では、コラボレーションやリーダーシップ、育成に時間を使うことが「損」になります。結果として、高い技術力を持ったエンジニアが孤立し、チームは分断され、組織は脆くなっていきます。
7つの軸で評価される組織では、エンジニアは自らの成長の方向性を多面的に選ぶことができます。技術を極める道も、マネジメントに進む道も、越境して新しい領域を開拓する道も、等しく「価値ある成長」として認められます。
評価制度は、単なる人事ツールではありません。「この組織はエンジニアに何を期待し、何を価値とするか」というメッセージそのものです。
7つの軸が示しているのは、技術力を起点にしながらも、プロジェクトを動かし、顧客に向き合い、仲間と協力し、課題を解決し、人を育て、知見を発信する——そういったエンジニアの仕事の「全体像」への敬意なのだと思います。
参考文献: - Will Larson, Staff Engineer: Leadership beyond the management track, self-published, 2021 - Camille Fournier, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, O'Reilly Media, 2017 - Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass, 2002 - 野中郁次郎, 竹内弘高, The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation（知識創造企業）, Oxford University Press, 1995 - Henrik Kniberg & Anders Ivarsson, Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, 2012
