エンジニアのキャリアを調べる

Date2026/08/03 Last Modified2026/08/12

私は1つのキャリアしか知らない

いま務めている企業で、あるいは私が関わってきた人たちから聞いた限り、私は1つのキャリアしか知らない。
エンジニアは一般職であり、管理職になったらコードを書くことなく現場から離れていく……。
長らくそれを疑問に思っていたが、“シニアエンジニア"とかを記事で読んだところでおよそ実感がわかないし、みんなが勝手に自分に肩書を付けてるだけなのかな、とさえ思っていた。
エンジニアとして成熟していくということは、自分一人で何でも解決していけること……?それ以上のエンジニアっていったい何者なんだろう。単なる技術オタク?資格があればいいの?

モデルケースが身近に無いからこそ、それを調べようという機会にも恵まれなかったが、たまたま手に取った本でキャリアを考え直すことになった。
ということで、キャリアについて調べてみよう。

エンジニアの等級がある企業の例から学ぶ

エンジニアに等級がある様々な企業の例をソースにして、独自の等級をAIに作ってもらった。
ソースにした企業: (メルカリ, LayerX, SmartHR, サイバーエージェント, Dropbox, GitLab)

### Level 1:ジュニア
自分に割り当てられたタスクを完了できる。

- 基本的な実装・テスト・デバッグ
- 指示の理解
- 質問と報告
- フィードバックへの対応
- 小さな変更の安全なリリース

### Level 2:自立したエンジニア
一つの機能を設計から運用まで担当できる。

- 要求をタスクへ分解する
- 設計案を比較する
- 見積もりと優先順位付け
- テストとリリース
- ログ・監視・障害対応
- ドキュメント作成
- 関係者との仕様調整

### Level 3:シニアエンジニア
曖昧な問題を整理し、チームとして成果を出せる。

- 問題そのものを発見・定義する
- 中規模システムの設計
- 技術的トレードオフの説明
- プロジェクトの技術リード
- コードレビュー・設計レビュー
- メンタリング
- 技術的負債と品質管理
- 障害の再発防止
- 顧客・事業指標を使った効果検証
- チームの開発プロセス改善

### Level 4:Staff Engineer
複数チームが、より良い判断と開発をできる状態を作る。

- 複数チームにまたがる技術戦略
- 中長期ロードマップ
- 共通基盤・設計標準・開発標準
- チーム間の依存関係の解消
- 技術的な合意形成
- 組織的な品質・セキュリティ改善
- 開発者体験と生産性の改善
- シニアエンジニアの育成
- 個人に依存しない知識・運用構造の構築
- プロダクト指標や事業成果への継続的な責任

### Level 5:Principal Engineer
事業やエンジニアリング組織全体の方向性を技術で変える。

- 事業戦略と技術戦略の統合
- 複数年のアーキテクチャ構想
- 全社的な技術投資の優先順位付け
- 複数Staff Engineerの支援
- 部門横断の難題解決
- 経営層との意思決定
- 全社品質・セキュリティ・信頼性戦略
- 新しい事業機会の技術的発見
- 社外の顧客・専門家・コミュニティへの影響

### Level 6:Distinguished/Senior Principal
会社や業界に新しい技術的方向を示す。

- 全社的な技術ビジョン
- 複数事業の技術ポートフォリオ
- 業界に先行する技術・プロダクト
- 経営戦略への直接的な影響
- 社外でも認められる専門性
- 会社全体の技術文化や判断基準の形成
- 後継となるPrincipal・Staff層の形成

私のイメージとして、「すごい仕事のデキるエンジニア=一人で何でもできる人」だった。
例えば言語を作ってしまう人とか、OSを作ってしまう人とか。
けれど、それは企業という単位で見ると別ベクトルの伸びであるということがよくわかる。

個人技がメインで求められているのはレベル2相当までで、そこから先はいかにチームへ、企業へ、未来へという軸で伸びているように見える。
つまるところ、「一人でいかに早く多くの仕事ができるか」という能力を伸ばしたところで、いきなり頭打ちになってしまうということだ。

一人でできることは思ったより少ない

最近の私の仕事ぶりは、まさにそんな感じで「いかに同時に案件を並行して把握していられるか」という勝負をしている。
ドキュメント知識はAIに負担してもらい、自分に来たボールは慣れた方式で結論を出して返して、とにかく早く返す。
そうしてなるべく最大限、自分への負荷を軽減しているつもりだが、やはりコンテクストスイッチは疲れるし、何より大きな仕事をやりきるのが難しい。
小規模な案件はうまくやれている感覚はあったが、もっと大きなプロジェクトが並行していくことを考えると根本的なリソースの不足が解決できそうにないと思った。

そこで必要なのは誰かの力である。しかし、その誰かが自分と同じスキルを持っているとは限らないとすれば……。
同じスキルを与えて同じ作業ができるような環境を作るのがもっと大きな仕事になるはずだ。
自分と同じ担い手を3人に増やして、その3人がまた3人を作れば企業にとっても大きな技術力の利益となる。
おそらくだけれども、より優れたエンジニアというのは自らががむしゃらに頑張るというよりは、全体を推進できる仕組みを作って自分も快適に頑張るということなのだと思う。

これからのキャリアをどうするか

エンジニアを志した頃、最終的には独立して暖簾を構えるのがゴールだと思っていた。
けれども、実はキャリアは多様であり、チームを牽引する存在を目指すというのは自分にとって悪くない進路にも思えた。
もっと大きなプロジェクトに取り組んでチームビルディングをしてみたいと考えたとき、必然的に求められる技術も高いものを要求されるし、より身近な組織への貢献感もあるとだろう。
今一度、自分に何が合うのかを考え直してみたい。