バックエンドマスター

10_キャリア

94 min read

10. エンジニアのキャリアの考え方 - 役割・分岐・長期戦略

読了時間: 60-90分（移動中に分割して読むのに丁度よい長さ） 想定読者: バックエンドの基礎を学び始めた人 / 数年やってきて「次どうしよう」と感じている人 ゴール: キャリアの選択肢を地図として持ち、自分なりの軸で意思決定できるようになる 手は動かさない: スマホ片手に通勤中・寝る前に読むだけでOK

この記事で持って帰れること

  • エンジニアの5レベル (ジュニア → プリンシパル) を「タイトル」ではなく「役割」で語れる
  • T字 / π字エンジニアの考え方を踏まえ、自分の「縦棒」をどう作るか描ける
  • バックエンド系の職種分岐 (SRE / Platform / セキュリティ / データ) の違いを言語化できる
  • IC路線とマネジメント路線、それぞれの旨み・落とし穴を比較できる
  • 「給与・技術成長・自由」3軸での意思決定フレームを持つ

連載のまとめとしての位置付け

ここまで9本、技術の話だけしてきた。最後の10本目はあえて 「人」 の話。技術スキルだけ伸ばしてもエンジニア人生は最適化されない。むしろ「どこで誰と何を作るか」「いつ動くか」「何に時間を投資するか」で大きく差がつく。コードのバグは git で戻せるが、3年間の時間は戻せない。

全10本の読み物章の締めとして読んでほしい。

大前提: なぜ「キャリアの考え方」を学ぶのか

技術書はたくさんある。Go の本も、データベースの本も、分散システムの本も、本屋に行けば棚にぎっしり並んでいる。でも「エンジニアとして30年食っていく地図」を書いた本は、意外と少ない。

理由はシンプルで、業界の変化が早すぎて「これが正解」と書ききれないからだ。1995年に書かれたキャリア本は今ほぼ無価値になっている。2010年に書かれた「これからはモバイルだ」も、もう古い。なので本記事も「永久に通用する真理」ではなく、「2026年時点で観測できる構造」として読んでほしい。

それでも、わざわざ1本の読み物を割いてキャリアの話をするのには理由がある。技術スキルだけを伸ばしてもエンジニア人生は最適化されない。むしろ多くの人は技術より「どこで誰と何を作るか」「いつ動くか」「何にお金と時間を投資するか」で大きく差がつく。コードのバグは git で戻せるが、3年間の時間は戻せない。

本記事では断定を避ける。「俺はこうやった」より「こういう選択肢があり、それぞれにこういうメリットとデメリットがある」を並べる方針で書く。最終的に何を選ぶかは読み手次第だ。

この記事の楽しみ方

一気に読まなくていい。電車で1章、寝る前に1章、と分けて読めるサイズに切ってある。 コードはほとんど出てこない。地図を眺めるつもりで読む。 各章末で「自分の今の位置はどこか」「3年後どこに居たいか」を軽く考えるとよい。メモを取らなくていい、頭の中で言語化するだけで十分。

第1章: そもそも「エンジニアの役割」って何段階あるのか

1-1. タイトルではなく「役割」で考える

「ジュニアエンジニア」「シニアエンジニア」「スタッフエンジニア」。これらは会社によって意味が全然違う。A社のシニアは B社のミドルだし、スタートアップの CTO 経験者がメガテックでは「シニア」スタートになることもある。

なので、タイトルは無視していい。代わりに「何ができるか」「何を任されるか」で5段階に分けて考える方が実用的だ。以下は業界で広く使われる粗いマップ。

エンジニアの5レベル(役割ベース)

レベル1: ジュニア (Junior)

  • 与えられたタスクを、上司のレビューを受けながら完了できる
  • 既存コードの真似と質問でなんとか進められる
  • 期間: 0-2年目

レベル2: ミドル (Mid-level)

  • 機能単位のタスクを自走できる(設計から実装、レビュー対応まで)
  • 「ここは詰まりそう」を事前に察知できる
  • 期間: 2-5年目

レベル3: シニア (Senior)

  • 複数機能、サービス単位の設計を主導する
  • 他人をブロッキングしない、むしろ他人の生産性を上げる
  • チームの技術的意思決定に責任を持つ
  • 期間: 5-10年目

レベル4: スタッフ (Staff)

  • 複数チームをまたいだ問題を扱う
  • 技術戦略、横断的な基盤、技術文化を設計する
  • 自分でコードを書く時間より、他人にコードを書かせる時間が多い
  • 期間: 8年目以降

レベル5: プリンシパル / ディスティングイッシュド (Principal / Distinguished)

  • 会社全体の技術方針に影響を与える
  • 業界レベルで認知されている(OSS、論文、講演など)
  • 期間: 15年目以降、しかも一握り

↓ エンジニアのキャリアラダーと分岐 ↓

graph TD
    Junior[レベル1: ジュニア<br/>0-2年] --> Mid[レベル2: ミドル<br/>2-5年]
    Mid --> Senior[レベル3: シニア<br/>5-10年]
    Senior --> IC[IC路線]
    Senior --> Mgmt[マネジメント路線]
    IC --> Staff[レベル4: スタッフ<br/>8年+]
    Staff --> Principal[レベル5: プリンシパル<br/>15年+]
    Mgmt --> EM[エンジニアリングマネージャー]
    EM --> VPE[VPE / CTO]

1-2. レベルを分けるのは「コード量」ではない

ありがちな勘違いが「シニアはコードがたくさん書ける人」というイメージだ。実際は逆で、レベルが上がるほど「自分でコードを書く時間の割合」は減っていく。

ジュニアが1日8時間コードを書くとして、シニアは4時間、スタッフは1時間、プリンシパルは0.5時間くらいになることが多い。残りの時間は何をしているか。設計、レビュー、メンタリング、調査、文書化、ステークホルダーとの調整。「コードを書かない時間」が「コードを書く時間」より価値を生む段階に入っているからだ。

「IC ラダー」という考え方

IC = Individual Contributor (個人寄与者) の略。マネジメントせず、現場で手を動かし続ける専門職の道のこと。Google や Meta などのテック大手は IC ラダーをマネジメントラダーと同等に扱う仕組みを整えており、シニア → スタッフ → プリンシパル → ディスティングイッシュド と上がっていける。

日本企業ではまだ「上に行くにはマネジメント必須」の会社が多いが、外資・先進的な日本テック企業では IC のまま年収を上げ続けられる仕組みが広がりつつある。「コード書き続けたい人にもキャリアパスがある」というのは数年前まではあまりなかった選択肢。

1-3. 「シニア」になるのに時間がかかる本当の理由

3年やればシニア、と思っている人もいるかもしれないが、5-10年かかると書いた。これにはちゃんとした理由がある。

シニアに求められる「経験」とは、本やドキュメントでは得られないもののことを指す。具体的には:

  • 自分が書いたコードが本番で大規模に動き、障害を起こし、復旧した経験
  • 設計判断を間違えてリファクタリングコストを払った経験
  • チームメンバーと衝突し、解消した経験
  • 「正しい技術」と「組織の都合」が衝突した時の判断経験

これらは時間の関数になっている。コードを書く速度を10倍にしても、本番障害が起きる頻度は変わらない。だから「最速でシニアになる方法」は存在しない。早い人で5年、平均で7-8年、というのが業界の感覚値だ。

「年数が足りないのに自分はシニアだ」と思う罠

技術ブログや SNS でアクティブな2-3年目のエンジニアが、自分のことを「もうシニア相当」と感じてしまうことがよくある。技術的な知識量は確かに多いかもしれない。でも、シニアの本質は「他人を巻き込んで価値を出すこと」にあり、これは知識量とは別軸の能力。

焦らない方がいい。レベルアップを急ぐと、表面的な「シニアっぽさ」だけ身につけて、中身がスカスカになりがち。

第2章: コードを書くスキルと、価値を出すスキルは別物

2-1. 「うまいコード」と「価値あるコード」は違う

エンジニアの新人は「綺麗なコードを書きたい」と思いがちだ。SOLID原則、デザインパターン、関数型プログラミング、テスト駆動開発。これらは確かに大事な技術だ。でも、「綺麗なコード」を書けることと「価値あるコード」を書けることは、別のスキルとして扱った方がいい。

ある会社で、技術的に完璧な認証システムを6ヶ月かけて作ったとしよう。一方、別のエンジニアは Auth0 を2日でセットアップしてリリースし、その後の6ヶ月で別の3つの新機能を出した。プロダクトの価値で見たら後者の方が圧倒的に高い。「自前で作る」がエンジニア的に楽しくても、ビジネスにとって正しいとは限らない。

「価値を出すスキル」を構成する要素

  • 問題の特定: 何を作るかを正しく見抜く。技術的興味より顧客の課題優先
  • トレードオフ判断: 自前 vs 既製品、速度 vs 品質、汎用 vs 特化、を意思決定できる
  • コミュニケーション: チーム・PM・顧客と認識を合わせる
  • やらないことを決める: 工数より「やらないリスト」を作る方が効果的なことが多い

2-2. シニアになるほど「書かないコード」を評価される

シニアエンジニアの隠れた評価項目に「無駄なコードを書かなかった件数」がある。意味が分かりにくいので具体例で説明する。

ある PM が「ユーザーアバターのアップロード機能を作ってほしい」と依頼してきたとする。新人なら張り切って S3 にアップロードする処理、画像リサイズ、CDN 配信、フォールバック画像、削除機能、それぞれのテスト、を3日くらいかけて実装する。

シニアはこう聞く。「これって、本当にユーザーがアバター変えたいって声多いんですか? Gravatar 連携で十分じゃないですか? その時間で別の機能を作りませんか?」と。結果として、3日分の工数が浮き、別の優先度の高い機能が前に進む。書かれなかった200行のコードが、書かれた200行のコード以上の価値を出している。

価値判断ができないエンジニアの典型行動 

PM: 「この機能作ってほしい」
エンジニア: 「分かりました。来週には作ります」

一見良いやり取りに見えるが、「なぜ作るか」「他の選択肢はないか」「優先度は適切か」を一切問わずに進めている。これを繰り返すと、技術的には優秀だが「便利屋」ポジションから抜け出せないまま年数だけ積み上がる。

2-3. かといってコードを軽視すべきではない

ここまで読むと「ビジネス視点が大事で、コードはどうでもいい」と思うかもしれない。それは違う。

コードが書けないエンジニアの「ビジネス判断」は信頼されない。なぜなら、技術的な実現可能性や工数感覚を持っていない人の意見は、現場と乖離していくからだ。「綺麗なコードが書けるのは前提」の上で「価値を出すスキル」を積み上げる、という二段構えになる。

逆に言えば、「綺麗なコードだけ書ける」だと年数が増えても評価は頭打ちになる。両方やる。これがバックエンドエンジニアの長期戦略の基本構造だ。

第3章: T字型エンジニア、π字型エンジニア

3-1. 「広く浅く」か「狭く深く」かの議論は古い

エンジニアの専門性の話で昔からあるのが「広く浅く」vs「狭く深く」の論争だ。フルスタックは中途半端、スペシャリストになれ、という意見と、現場では幅広い対応力が必要、という意見が常に対立してきた。

結論から言うと、どちらも正解じゃない。今の現場で評価されるのは T字型 あるいは π字型 のエンジニアだ。

T字型エンジニアとは

縦棒が深い専門性、横棒が広い基礎知識を表す。

━━━━━━━━━━━━━━━  ← 広い基礎(全領域を一通り知っている)
        ┃
        ┃
        ┃
        ┃  ← 1つの深い専門(自分の中核領域)
        ┃
        ▼

例: 「Web 全般を知っているが、特にデータベースが深い」「インフラ全般を知っているが、特に Kubernetes が深い」

π字型エンジニアとは

縦棒が2本ある形。深い専門領域を2つ持つエンジニア。

━━━━━━━━━━━━━━━  ← 広い基礎
     ┃        ┃
     ┃        ┃
     ┃        ┃  ← 2つの深い専門
     ▼        ▼

例: 「バックエンド(Go) と インフラ(AWS/k8s) の両方ができる」「Web フロントエンド と モバイルアプリ(iOS) の両方ができる」

↓ T字型エンジニアとπ字型エンジニアの構造 ↓

flowchart TD
    subgraph Tgata [T字型]
        T_Base[広い基礎: HTTP/SQL/Linux/Git/クラウド]
        T_Deep[縦棒1本<br/>例: データベース深掘り]
        T_Base --- T_Deep
    end
    subgraph Pigata [π字型]
        P_Base[広い基礎]
        P_Deep1[縦棒1<br/>例: バックエンドGo]
        P_Deep2[縦棒2<br/>例: インフラk8s]
        P_Base --- P_Deep1
        P_Base --- P_Deep2
    end

3-2. なぜ T字 か π字 が評価されるのか

理由は2つある。

ひとつめは、現場の問題が「単一領域に閉じない」ことが多いから。例えば「ページの表示が遅い」という問題は、フロントの描画、API レイテンシ、DB クエリ、CDN キャッシュ、DNS、TCP コネクション、どこにでも原因がありうる。深い専門領域が1つしかないと、自分の専門外の問題が見えない。

ふたつめは、技術領域の境界がどんどん曖昧になっているから。「フロントエンドだから DB のことは知らない」と言うエンジニアは、今や Next.js のサーバーサイドレンダリングで DB を直接叩いてしまう状況に対応できない。「バックエンドだからフロントは知らない」と言うエンジニアは、API 設計でクライアントに優しい形を出せない。

フルスタックという言葉の罠

「フルスタック」と「広く浅く」は違う。フルスタックは “全領域で実務レベル” を目指す難易度の高い形態だが、現実には “どの領域も中途半端” になっている人も少なくない。

フルスタックを目指す場合は「全方向に基礎を持ち、いずれかで深さを獲得する」のが現実的なルート。最初から全方向に深くは無理。

3-3. 縦棒を作るタイミング

新人時代の最初の3年は、横棒(広い基礎)を作る期間だと考えていい。HTTP、TCP、DNS、SQL、Linux、Git、シェル、簡単なクラウドの使い方。バックエンドエンジニアならこれらは全部触っておく。

3-5年目あたりで、自分が好きな縦棒を1本選ぶ。データベース、分散システム、ネットワーク、セキュリティ、パフォーマンス、何でもいい。「これは他の人より詳しい」と言える領域を作る。

7-10年目以降で π字 を狙うかどうかは個人の好みだ。1本の縦棒を更に深くする道もあれば、2本目を作って汎用性を上げる道もある。どちらも正解。

第4章: バックエンド系の職種分岐

4-1. 「バックエンドエンジニア」の中にも分岐がある

「バックエンドエンジニア」と一口に言っても、3年目を超えるあたりから細分化が始まる。求人票で「バックエンドエンジニア募集」とあっても、実際に求められているスキルセットは会社によって全然違う。代表的な分岐を見ていく。

↓ バックエンド系の職種分岐マップ ↓

mindmap
  root((バックエンドエンジニア))
    純粋なバックエンド
      API設計
      ビジネスロジック
      ドメインモデリング
    フルスタック
      フロント+バック両方
      小規模チーム向き
    SRE
      信頼性/監視
      SLI/SLO
      障害対応
    Platform / DevOps
      CI/CD
      社内開発基盤
      生産性向上
    セキュリティ
      脆弱性診断
      認証認可
      コンプライアンス
    データ
      パイプライン
      DWH/ETL
      ML/分析隣接

純粋なバックエンドエンジニア (Backend Engineer)

  • メインの仕事: API、ビジネスロジック、データモデリング
  • 使う技術: Go / Java / Python / Node.js / Ruby、PostgreSQL / MySQL
  • 強み: ドメインモデリング、API 設計、テスト
  • 想定企業: ほぼ全ての Web 系企業に存在する基本職種

フルスタックエンジニア (Full-stack Engineer)

  • メインの仕事: フロントもバックも書く
  • 使う技術: TypeScript / React / Next.js + Node.js or Go + DB
  • 強み: 1人で機能を完結できる、小さいチームで重宝される
  • 想定企業: スタートアップ、小〜中規模スタジオ

SRE (Site Reliability Engineer)

  • メインの仕事: 本番システムの信頼性、監視、障害対応、自動化
  • 使う技術: Kubernetes、Prometheus、Grafana、Terraform、各種クラウド
  • 強み: 大規模システムを止めない、SLI/SLO 設計、障害の根本対応
  • 想定企業: ある程度規模がある会社(月100万 UU 超など)、メガテック
  • 由来: Google が2003年頃に “ソフトウェアエンジニアに運用をやらせる” 思想で作った職種。著作 “Site Reliability Engineering” (Google刊) が無料公開されていて読める

Platform Engineer / DevOps Engineer

  • メインの仕事: 社内エンジニアが使う基盤(CI/CD、開発環境、デプロイパイプライン)を作る
  • 使う技術: GitHub Actions、Argo CD、Backstage、Terraform、k8s
  • 強み: 「他のエンジニアの生産性を10倍にする」インフラを作る
  • 想定企業: エンジニアが50人以上いる規模感の会社で必要になる

セキュリティエンジニア (Security Engineer)

  • メインの仕事: 脆弱性診断、セキュアコーディング、インシデント対応、認証認可基盤
  • 使う技術: OWASP、SIEM、IDS/IPS、IAM、ペネトレーションテストツール
  • 強み: 攻撃者視点で設計を見られる、コンプライアンス対応
  • 想定企業: 金融、医療、政府、大企業
  • 市場性: 慢性的に人が足りていない。給与高め

データエンジニア (Data Engineer)

  • メインの仕事: データパイプライン、データウェアハウス、ETL/ELT、BI 連携
  • 使う技術: BigQuery / Snowflake / Redshift、Airflow / Dagster、dbt
  • 強み: SQL、データモデリング、分析チームとの橋渡し
  • 想定企業: データドリブンを謳う全ての会社
  • 隣接職種: 機械学習エンジニア (ML Engineer)、アナリティクスエンジニア (Analytics Engineer)

4-2. どの分岐を選ぶかの判断基準

分岐が見えたところで、「じゃあ自分はどれを選ぶか」という話になる。これは正直、好みと相性の問題が大きい。ただし、いくつか考慮ポイントはある。

ひとつめ、市場での需要と給与レンジ。2026年現在、日本市場で言うと SRE と セキュリティエンジニアは需要が供給を大きく上回っており、給与が高めに出る。逆に「ただのバックエンド」は人数が多く、給与の上振れが起きにくい(下振れも少ないが)。

ふたつめ、自分の認知特性との相性。インシデント対応や本番障害の電話を受けるのが平気な人は SRE 向き。コツコツとデータ整形を続けられる人はデータエンジニア向き。ユーザーに近い機能開発で報酬を感じる人はフルスタック向き。

みっつめ、長期的に何が残るか。例えば SRE のスキルはクラウドが変わっても応用が効くし、データエンジニアのスキルもデータ量が増え続ける限り需要は減らない。一方、特定の言語やフレームワーク特化のスキルは、その技術が衰退すると価値が下がる。

「楽そう」で職種を選ばない

SRE が高給だから、と興味もないのに移ると、夜中に PagerDuty で叩き起こされる生活が苦痛になる。データエンジニアが流行りだから、と SQL が嫌いなのに移ると、毎日 SQL を書く仕事が苦痛になる。

給与だけで選ぶと、3年後に「自分は何が好きだったんだっけ」を見失う。最低限「嫌いではない」が必須条件。

4-3. ロールチェンジは何回でも可能

「いったん SRE を選んだら、他には移れないんですか?」とよく聞かれる。そんなことはない。むしろ、5-10年単位でロールチェンジしているエンジニアは珍しくない。

純粋バックエンド → SRE → プラットフォーム、という流れもある。データエンジニア → ML エンジニア、という流れもある。フルスタック → エンジニアリングマネージャー、もよくある。

ただし、ロールチェンジには「学び直しコスト」がかかる。3年で慣れた専門領域を捨てて、別の領域で1年目からやり直す覚悟が必要だ。年齢が上がるほどこのコストは上がるので、20代のうちはまだ気軽に試してよい。

第5章: フレームワーク追っかけ症候群の罠

5-1. 「次の Next.js」を追いかける人々

技術系の Twitter や Zenn を見ていると、「Next.js のサーバーアクションが」「Remix の loader が」「Astro の islands が」みたいな投稿が毎日のように流れてくる。これらをキャッチアップし続けることが「最先端のエンジニア」だと思っている人がいる。

実際のところ、これらのフレームワークは半分くらい同じことをやっており、片方を知っていれば反対側はドキュメント1日読めば書ける。にもかかわらず、毎週のように新しいフレームワーク、新しいバージョン、新しい記法を追いかけ続けるのは、コストパフォーマンスが悪い。

これを フレームワーク追っかけ症候群 と呼ぶ(造語ではなく、英語圏では FOMO-driven development とも呼ばれる)。

フレームワーク追っかけ症候群の症状

  • 新しいフレームワーク(過去1年以内に出たもの)を3つ以上学習中
  • 「これからは○○の時代だ」と毎月言葉が変わる
  • 自分の業務で使うわけでもないのに最新版を追っている
  • 一方で、TCP/IP、HTTP、SQL の基礎を聞かれると答えに詰まる

上の症状が複数当てはまる場合、注意。表面のキラキラ技術を追っている間に、骨太な基礎が空洞化している可能性が高い。

5-2. なぜ「本質的な技術」と「流行りの技術」を区別すべきか

両者にはレイヤーの差がある。

本質的な技術 とは、10年以上変わらないもの。SQL、HTTP、TCP、Unix の哲学、データ構造、アルゴリズム、分散システムの原理。これらは「賞味期限」がない。1995年に書かれた SQL の本の知識は今もほぼ通用する。

流行りの技術 とは、3-5年でメジャーバージョンや代替品が出るもの。各種フロントエンドフレームワーク、サーバーレスプラットフォーム、Web 系のビルドツール、JavaScript の最新の構文。これらは便利だが「賞味期限」がある。

本質的な技術を抑えていれば、流行りの技術は「あの概念のバリエーションね」と認識できる。逆に、流行りばかり追っていると、その流行りが終わった時に何も残らない。

流行り技術と本質技術の区別の例

流行り技術その下にある本質
Next.js のサーバーアクションHTTP リクエスト/レスポンス、関数呼び出しの抽象化
Remix の loaderサーバーサイドレンダリング、データフェッチング
tRPCRPC、型システム、シリアライズ
GraphQLAPI クエリ言語、スキーマ駆動
サーバーレス関数プロセスとライフサイクル、スケジューラ
Kubernetesプロセス管理、ネットワーク名前空間、cgroups

本質を抑えていれば、新しい流行りが出ても「ああ、あれの新版ね」で済む。

5-3. 「流行りを追う時間」と「基礎を作る時間」の比率

完全に流行りを無視しろ、と言うわけではない。実務で使うなら追う必要があるし、好きで楽しいなら止める理由もない。

ただし、特に新人〜中堅(0-5年目)の段階では、両者の時間配分を意識した方がいい。目安として、学習時間の 7割を本質的な技術、3割を流行りの技術 に当てる、くらいがちょうどいい。

7-10年目以降は、ある程度本質が固まってくるので、流行りの比率を上げてもいい。「広く流行りを追える」のは経験者の特権でもある。

第6章: 給与カーブと交渉

6-1. 日本市場の給与レンジ(2026年現在)

ここからは、お金の話を淡々とする。タブー視されがちだが、知らないと損する領域なので、可能な限り具体的な数字で書く。あくまで2026年時点の感覚値で、企業規模や業種で大きくぶれることを前提にしてほしい。

日本のバックエンドエンジニアの年収レンジ目安

レベル中小・受託自社開発スタートアップメガベンチャー外資テック
ジュニア(0-2年)350-450万400-550万500-700万800-1200万
ミドル(2-5年)450-600万500-800万700-1100万1200-1800万
シニア(5-10年)550-750万700-1200万1000-1600万1800-2800万
スタッフ(8年+)700-900万1000-1500万1400-2200万2500-4000万
プリンシパル(15年+)-1500万+2000-3500万3500-6000万+

外資の数字は基本給+RSU(株式報酬)+ボーナス込みのトータル。RSU の評価は時価で変動する。

6-2. 海外との比較

同じスキルでも、米国(特にベイエリア・シアトル・NY)で働くと給与は2-4倍になる。例えばシニアバックエンドで日本だと年収1000万円のところ、米国メガテックだと$200,000-300,000(2026年のレートで3000-4500万円)になることが普通。

これは「米国エンジニアの方が優秀」だからではない。市場の単価差と、株式報酬の文化が大きい。GAFAM や OpenAI、Anthropic などのトップ企業は、エンジニアに対して株式での報酬を厚く払う仕組みを持っている。

ただし、米国は税金、家賃、健康保険、教育費なども高い。サンフランシスコのアパートは家賃月60-80万円が普通。額面が3倍でも、可処分所得で見たら1.5-2倍くらいに収まることも多い。

リモートワークと給与アービトラージ

米国企業が「日本在住者をリモートで雇う」ケースが2020年代に増えた。この場合、米国給与の70-90%が払われることが多く、日本の物価と組み合わせると相当の可処分所得になる。

ただし、英語力(特に同期/会議の英語)が必須で、職務範囲によっては時差(米国西海岸と16-17時間差)で生活リズムが崩れる。「リモートだから楽」というほど甘くはない。

6-3. 給与交渉のリアル

日本企業の多くは「給与交渉」の文化が弱い。提示額をそのまま受け入れる人がほとんどで、交渉する人は少数派。一方、外資、スタートアップ、ハイクラス転職では交渉が前提になっていることが多い。

交渉でよく使われる手段:

  • 複数オファーを取って比較する: 「A社からは900万円のオファーがある」とB社に伝えて引き上げる
  • 現職の年収を強気に書く: 嘘はNGだが、変動賞与込み、ストックオプションの想定額を含める書き方は許容
  • 「ベース」「ボーナス」「サインオン」「RSU」を分けて議論する: 「ベースは下げてもいいのでサインオンを増やしてほしい」など条件設計

交渉で気をつけること

  • 嘘の年収を伝えるのは確実にNG(バレた時の信頼喪失が大きすぎる)
  • 「今すぐ決めてほしい」と急かす会社は要注意(検討時間を1週間取らない会社は焦らせている)
  • 給与だけ見て選ぶと、3ヶ月後に「合わなかった」となる。給与・働きやすさ・成長機会の3つで判断する

6-4. 給与カーブは「指数」ではなく「階段」

「年収を上げる」と聞くと、毎年5-10%ずつ上がるイメージを持つかもしれない。実態は階段状で、転職やレベルアップのタイミングで一気に上がる。

例えば、ジュニア→ミドルの転職で年収が400万→700万になり、3年そこで働いて650万→800万になり、ミドル→シニアの転職で1100万になる、という階段状の動き。「同じ会社で長く働く」だけだと、階段の上り幅は小さくなる傾向がある。

「同じ会社に長くいる」のメリット/デメリット

メリット

  • 信頼の蓄積、社内ネットワーク、暗黙知の獲得
  • 大きなプロジェクトを最初から最後まで見られる
  • 退職金、ストックオプション、確定拠出年金の積み立て

デメリット

  • 給与カーブが緩い
  • 他社の文化を知らないので「井の中の蛙」になりやすい
  • 業界の市場価値が分からない(自分のレベル感が曖昧になる)

どちらが正解、というわけではない。バランスで考える。

第7章: 転職のタイミング

7-1. 「2-4年」が業界平均

業界の感覚値として、エンジニアの平均在籍年数は2-4年と言われる。これより短いと「ジョブホッパー」と見られるリスクがあり、これより長いと「成長機会が止まる」リスクがある。

なぜ2-4年か。1年目はキャッチアップ、2年目で実力発揮、3年目で大きい成果、4年目以降は「同じことの繰り返し」になりやすい、というサイクルがあるからだ。もちろん、4年目以降も新しい挑戦が会社から与えられるならいい。問題は、本人が成長を感じなくなった場合だ。

転職を考えるサイン

  • 同じレイヤーの仕事を1年以上繰り返している
  • 上司から見ても「もう教えることがない」状態
  • 業界の同年代と比べて給与が大きく見劣りする
  • 会社の技術選定が古く、市場価値のあるスキルが身につかない
  • 燃え尽き、人間関係、ハラスメント等の重大要因がある

上が複数当てはまる場合、転職市場をのぞいてみるだけでもよい。実際に動くかは別判断で。

7-2. 「長すぎる」問題

逆に、1社に7年、10年、15年と居続けるパターンも問題がある。本人の安心感は高いが、外から見た時の市場価値が分かりにくくなる。

具体的に何が起きるか:

  • その会社固有の暗黙知ばかり蓄積する(別会社で通用しないスキル)
  • 採用面接の経験がないので、いざ動く時に通じない(面接スキルも錆びる)
  • 給与が市場相場から大きくズレている(上にも下にもズレる)
  • 「ここしかない」と思い込むので、不当な扱いがあっても抜けられない

長く居ること自体は悪ではない。ただ、長く居る場合は「2-3年に1度は外の世界を見る」(カジュアル面談を受ける、技術コミュニティに顔を出す、別会社の友人と情報交換する)、という習慣を持っておくと、市場感覚を失わずにすむ。

7-3. 「短すぎる」問題

逆に、半年や1年で次々と転職するのも問題だ。3社で各1年、というキャリアは採用側から見ると「またすぐ辞めるんじゃ」というリスクとして映る。

短期離職の理由は色々あるが、共通する根本要因は「自分が何をやりたいか分かっていない」ことが多い。「給与」「働き方」「技術」「人間関係」など、何を最優先するかが定まっていないと、入社後に小さな不満で揺らいでしまう。

転職前に決めておくこと(3つの軸)

転職活動を始める前に、自分の優先順位を3つ書き出すといい。例えば:

  1. 給与: 今の年収から最低でも +200万
  2. 技術: モダンな技術スタック(Go / k8s / クラウド)で開発できること
  3. 働き方: 週3以上のリモート、フレックス

この3つの順序をつけて、「給与は満たすが技術がイマイチ」のオファーが来た時に判断できるようにする。順序がないと、提示された条件に流されて決めることになる。

7-4. 「会社を辞める前に転職先を決める」原則

経済的な余裕がよほどない限り、現職を辞めてから次を探す、はおすすめしない。理由は3つ。

ひとつは、無職期間が長くなると採用側からの目線が厳しくなる(空白期間の説明を求められる)。ふたつめ、給与交渉で現職の給与を出せないと、相手の提示額がベースになる。みっつめ、無職の精神状態は焦りで判断を狂わせる。

例外として、メンタル不調で休む必要がある場合、副業や個人開発で生活が回る場合、留学や大学院進学などの計画がある場合は、辞めてから動くのは合理的な選択。

第8章: リモートワークと AI 時代の働き方

8-1. リモートワークは「定着」したが「主流」ではない

2020年のパンデミックでリモートワークが急速に広まった。2026年現在、業界の構図は以下のように分かれている。

  • 完全リモート: スタートアップ、外資の一部、リモートファーストの会社
  • ハイブリッド(週2-3出社): 日本企業の半数以上、外資の多く
  • 原則出社: 大手SIer、金融、製造業の多く、メガテックの一部(Google、Amazon、Meta等は2024年頃から週5出社に戻し始めた)

「リモートで働ける会社が当然」という前提で会社を選ぶと、選択肢が狭くなる時代になっている。むしろ「ハイブリッドが普通」「リモートはオプション」と考えた方がよい。

リモートワークのメリットとデメリット

メリット

  • 通勤時間ゼロ(平均1時間/日が浮く、月20時間)
  • 集中できる時間を作りやすい
  • 居住地の自由度が上がる(地方移住、海外移住)

デメリット

  • 雑談・偶発的な学びが減る
  • 新人の成長スピードが遅くなる(これは観測的に明らか)
  • メンタル不調の早期発見が難しい
  • 評価が「成果物」中心になる(プロセスが見えにくい)

8-2. AI 時代に「価値が下がる仕事」「上がる仕事」

2023年以降の生成AI(Claude / ChatGPT / Copilot 等)の進化で、エンジニアの仕事のうち「定型的なコーディング」「単純な翻訳的作業」は AI の補助で1人あたり生産性が2-5倍になっている。これは数字を盛っているわけではなく、実測でこれくらい出ている。

この変化で「価値が下がる仕事」と「価値が上がる仕事」が明確に分かれている。

AI 時代の価値変動

価値が下がる仕事(AI で代替されやすい)

  • 仕様書通りのコーディング(指示を実装に落とす)
  • 既存コードのテストケース作成
  • ドキュメント翻訳、コメントの英訳
  • 単純な CRUD API の量産
  • 簡単なバグ修正(Stack Overflow ですぐ出るレベル)

価値が上がる仕事(AI ではまだ難しい)

  • 不明瞭な要件を整理して仕様に落とすこと
  • 複数のステークホルダーとの合意形成
  • システム設計の意思決定(「ここはマイクロサービスにすべきか」)
  • 障害時の判断(「サービス全停止 vs 一部機能停止」)
  • レガシーシステムの構造理解(コンテキストが膨大すぎて AI が追えない)
  • 新規性のあるアルゴリズム設計(学習データの外側)

8-3. AI を「使いこなす」エンジニアの希少性

2026年現在、AI を本当の意味で業務に組み込めているエンジニアは、業界全体で見るとまだ少数派だ。多くの人は「ChatGPT で簡単な関数を書かせる」程度の使い方にとどまっている。

「使いこなす」とは、もう少し踏み込んだ使い方を指す。具体例:

  • 自分の生産性を Claude Code や Cursor で2-5倍にする(設計レビュー、リファクタ、テスト生成)
  • AI エージェントを業務フローに組み込む(自動レポート、自動レビュー、自動運用判断)
  • AI に渡すコンテキスト(ドキュメント、コード、データ)の整備を仕組み化する
  • AI の出力を盲信せず、検証・修正できる(これが一番大事)

AI 時代のスキル投資の優先順位

  1. AI ツールを毎日業務で使う: Claude Code、Cursor、GitHub Copilot のいずれかは必須
  2. プロンプト設計の感覚を身につける: 良い文脈・良い指示が良い出力を生む
  3. AI の限界を知る: ハルシネーション、古い情報、コンテキスト超過の挙動
  4. AI 抜きでも書けることが前提: AI が止まった時に何もできない人にはならない

8-4. 「AI に仕事を奪われる」の正体

「AI でエンジニアは要らなくなる」という言説が時々流れる。これは半分正しく、半分間違っている。

正しい部分: 「コード生成だけ」をやっていたエンジニアの仕事は、確実に圧縮される。生産性が2-5倍になるということは、同じ仕事量を作るのに必要な人数が減るということでもある。

間違っている部分: エンジニアという職種が消えるわけではない。むしろ、AI を使って3人で5人分の仕事ができるチームは、6人で5人分の仕事をしているチームより圧倒的に評価される。AI を使えるエンジニアの需要は増え続けている。

奪われるのは「AI を使えないエンジニアの仕事」であって、エンジニアという職種そのものではない。

↓ AI時代の働き方シフト (Before / After) ↓

flowchart LR
    subgraph Before [Before: AI登場前]
        B1[要件を仕様に落とす] --> B2[手でコードを書く<br/>大半の時間ここ]
        B2 --> B3[テストを手で書く]
        B3 --> B4[障害時は手で調査]
    end
    subgraph After [After: AIを使いこなす]
        A1[要件整理・合意形成<br/>ここに時間を投下] --> A2[AIに大量に書かせる]
        A2 --> A3[出力を検証・修正<br/>判断力が価値]
        A3 --> A4[障害時の判断・設計]
    end
    Before -.シフト.-> After

第9章: 副業・OSS・個人開発のリターン

9-1. 副業: 経済的リターンとそれ以外

2018年に厚労省が「副業解禁」を打ち出してから、副業可の会社が増えた。エンジニアの副業は時給5000-10000円、月10-30万円くらいが相場感だ(月20-40時間程度の稼働で)。

経済的リターンは確かに大きい。ただ、副業の本当の価値は経済面より「別環境を見られること」にあると思っておくとよい。本業1社しか知らないと自分のレベル感が分からないが、副業先と本業を比べると相対化できる。

エンジニアの副業形態

形態報酬学べること
業務委託(リモート稼働)時給5000-10000円別企業のコード・文化
受託開発(個人で受注)案件単価 50-300万円顧客折衝、価格設定
技術顧問月10-50万円設計レビュー、技術選定
技術記事執筆1記事 1-10万円言語化能力
講演・登壇1回 3-30万円業界での認知獲得

9-2. OSS への貢献

オープンソースへの貢献は、エンジニアの市場価値に直接効く活動だ。理由は3つ。

ひとつめ、「他人のコードを読み、改善する」スキルは、シニア以上で必須になる。OSS への PR は、その実践そのものになる。ふたつめ、世界中のエンジニアと議論する経験は、社内では得られない。みっつめ、採用市場で「OSS への貢献歴がある」は強い武器になる。GitHub プロファイルが履歴書代わりになる時代だ。

ただし、最初の貢献は心理的なハードルが高い。タイポ修正、ドキュメント改善、テスト追加、くらいから始めるとよい。コード変更を含む大きな PR を最初から狙わなくていい。

OSS 貢献の入り口候補

  • good first issue ラベル: ほとんどの主要 OSS が初心者向けの Issue にこのラベルを付けている
  • 自分が普段使っているライブラリ: バグを踏んだら直して PR を投げる
  • 日本語ドキュメントの翻訳: 英語力ハードルが下がる
  • テスト追加: 既存機能のテストカバレッジ向上は歓迎されやすい

9-3. 個人開発

個人開発(自分で作るプロダクト、サイドプロジェクト)は、エンジニア活動の中で最もリターンの幅が広い。

リターンの幅、というのは、当たれば月100万円以上の不労所得になるが、外れれば0円のままだ、ということ。期待値で計算すると割に合わないことが多い。ただし、「お金以外のリターン」を含めると話が変わってくる。

個人開発の「お金以外」のリターン

  • 本業では使えない技術を試せる: Rust で書いてみる、Edge コンピューティングを試す、など
  • 企画から運用まで一通り経験できる: バックエンドだけのエンジニアでも、UI、決済、運用、マーケティングを全部やる
  • ポートフォリオになる: GitHub に上がっている、本番運用中の自作プロダクトは強力な実績
  • 転職時の話題: 面接で「個人で何を作りましたか」に答えられると、評価が一段上がる

9-4. 副業・OSS・個人開発をやるべきか

「全部やった方がいい」と言うつもりはない。本業だけでも8時間使う仕事だ。家族、健康、趣味、休息も大事。

ただし、20-30代のうちに「何か1つは課外活動を持っておく」と長期で効いてくる。それが副業なのか OSS なのか個人開発なのかは、本人の好みでいい。あるいは、技術記事を書く、登壇する、コミュニティに顔を出す、なども同じカテゴリだ。

↓ 副業・OSS・個人開発のリターン構造 ↓

flowchart TD
    Side[副業] --> M_Side[経済リターン:<br/>月10-30万円]
    Side --> L_Side[学び:<br/>別企業の文化/相対化]
    OSS[OSS貢献] --> M_OSS[経済リターン:<br/>原則ゼロ]
    OSS --> L_OSS[学び:<br/>他人のコード/世界中と議論]
    OSS --> Brand[ブランド:<br/>GitHubが履歴書代わり]
    Personal[個人開発] --> M_Personal[経済リターン:<br/>0円〜月100万円超まで幅広]
    Personal --> L_Personal[学び:<br/>企画から運用まで全部]
    Personal --> Brand2[ブランド:<br/>面接で強い実績に]
    Write[記事執筆・登壇] --> L_Write[学び:<br/>言語化能力]
    Write --> Brand3[ブランド:<br/>採用市場での認知]
    Brand --> Career[長期キャリア複利]
    Brand2 --> Career
    Brand3 --> Career
    L_Side --> Career
    L_OSS --> Career
    L_Personal --> Career
    L_Write --> Career

燃え尽きと副業の関係

副業も個人開発も「やりすぎる」と本業に影響する。睡眠時間を削って3年は続かない。週末は休む、平日夜の活動は週3まで、など自分なりの上限を決めておく。

燃え尽きると「半年から1年、何もできない」状態になる。長期で見たら大損なので、ペース配分の方が重要。

第10章: 学習投資の戦略

10-1. 「給与の10%を技術に投資」は今や古い

エンジニア向けキャリア本でよく出てくる助言に「給与の10%は技術書とコースに投資せよ」というものがある。これは1990-2000年代の助言で、当時は技術書が高価で、有料カンファレンスや有料コースが学習の中心だった時代の発想。

2026年現在、学習リソースの大半は無料か非常に安価になっている。MIT OpenCourseWare、Stanford CS の YouTube 公開講義、無料の OSS チュートリアル、Anthropic / OpenAI の公式ドキュメント、Coursera の聴講モード、技術書の DRM 解除版。情報は無限にある。

問題は「お金を払うこと」ではなく「時間を投資すること」になっている。10万円の本を買うのは簡単だが、月20時間を継続して学習に投じるのは難しい。

2026年の学習投資の優先順位

  1. 時間: 週5-10時間の継続学習時間を確保すること(最重要)
  2. AI ツールの月額: Claude Pro / ChatGPT Plus / Cursor で月20-30ドル × 2-3個
  3. 書籍: 月1-2冊、3000-5000円(技術書、英語のものも含む)
  4. オンラインコース: 必要に応じて Coursera / Udemy で1-2万円のコース
  5. カンファレンス: 興味あるもの年1-2回、各2-5万円
  6. 書籍の DRM フリー版: Pragmatic / Manning / O’Reilly 直販で割安に

10-2. 「読書」より「実装」が学習効率が高い

書籍を読むのは大事だが、読んでばかりだと知識が定着しない。特にエンジニアリングは「動くもの」を作って初めて身につく。

学習効率を上げるルール: 読書時間 ≤ 実装時間 を目安にする。1時間本を読んだら、最低1時間は手を動かす。読んだだけで「分かった気」になるのが一番危険。

効率の良い学習サイクル

  1. 目的を決める(何を作るか、何を理解するか)
  2. 本やドキュメントを1章/30分読む
  3. 同じ時間で手を動かす(写経でなく、自分の問題に当てはめる)
  4. 書いたコードを誰かに見せる(レビュー、ブログ、Twitter、AI でもよい)
  5. 次の章へ

このサイクルを回せると、3ヶ月で1冊の本を「使える知識」に変換できる。読むだけだと10冊読んでも何も残らないことがある。

10-3. 「広く読む」と「深く読む」

技術書には2種類ある。広く知る本(浅く全体像)と 深く理解する本(1テーマを深掘り)。

新人時代は広く読む本を多めに、慣れてきたら深く読む本を増やすとよい。広く読む本は速度重視で1.5倍速で読み流してもいい。深く読む本は、1ページ20分かけることもある。

バックエンドエンジニアの「読むべき深掘り本」例

  • データベース: 『データ指向アプリケーションデザイン』(Designing Data-Intensive Applications)
  • 分散システム: 『Distributed Systems』(van Steen)、論文(『Time, Clocks, and the Ordering of Events』など)
  • Linux 内部: 『Linux カーネル Hacks』『詳解 Linux カーネル』
  • ネットワーク: 『マスタリング TCP/IP 入門編』『プロフェッショナル TCP/IP』
  • コンピュータ科学全般: 『コンピュータシステムの理論と実装』(nand2tetris)
  • 設計: 『A Philosophy of Software Design』(Ousterhout)
  • SRE: 『Site Reliability Engineering』(Google、無料公開)

10-4. 「英語」は学習投資として最強

英語が読めると、学習リソースの量が10倍、最新情報の到着が半年-1年早くなる。日本語翻訳を待っている間に、英語が読める人は次の本を読み終わる。

「会話の英語」より「読み書きの英語」を優先するとよい。論文を読む、英語ドキュメントを読む、英語の GitHub Issue で議論する、ができれば最初は十分。会話は後からでも追いつける。

エンジニアのための英語学習

  • 毎日30分、英語の技術記事を1本読む: Hacker News、Lobsters、技術ブログ
  • AI に「これを英語で書いて」をやらせる: 自分の日本語を Claude/ChatGPT で英訳して、相手の表現を覚える
  • 海外カンファレンスの動画を字幕付きで見る: KubeCon、re:Invent、GopherCon など
  • TOEIC 等の試験: 業務以外で証明したい場合のみ。実務には直結しない

第11章: 「採用したくなる」エンジニアの条件

11-1. 採用側が見ているもの

採用側に立ったことがあると分かるが、書類選考で見られているのは「技術スキル」だけではない。むしろ、技術スキルは最低ラインのチェックで、合否を分けるのはそれ以外の要素が多い。

採用責任者は、5年・10年単位で「この人と一緒に働きたいか」を判断している。1-2年で辞める前提で雇うことは少ない(コストが合わないため)。

採用側が見ている要素(技術以外)

  • 言語化能力: 自分の経験を整理して話せるか。「やってきたこと」を構造化して伝えられるか
  • 学習姿勢: 新しい技術への興味、過去5年でどれだけ成長してきたか
  • チーム適合性: 既存メンバーと衝突しすぎず、しかし馴れ合いすぎない人柄
  • 責任感: トラブル時に逃げず、原因と対策を語れるか
  • アウトプット: 技術ブログ、登壇、OSS、個人開発、勉強会
  • 長期ビジョン: 「3-5年後にどうなりたいか」を自分の言葉で持っているか

11-2. 履歴書/職務経歴書の書き方

職務経歴書は「やってきたことの羅列」ではなく「成果と数字」で書く。これだけで通過率が大きく変わる。

悪い例: 「Go と PostgreSQL を使って API を開発しました」 良い例: 「Go と PostgreSQL でユーザー認証 API を開発し、レスポンス時間を平均 300ms から 80ms に短縮(キャッシュ層導入とインデックス再設計による)」

数字、技術的な詳細、影響範囲、を含めると一気に説得力が増す。

よくある悪い職務経歴書

  • 「業務に従事した」「対応した」「実装した」だけ並ぶ
  • 規模感が分からない(「大規模システム」と書いても、ユーザー数や trps が不明)
  • 自分の貢献範囲が曖昧(「チームでやった」だけ。本人が何をやったか不明)
  • スキル一覧に「Word, Excel」が混ざる(エンジニア職には不要)

11-3. 技術ブログ・登壇の価値

技術ブログを書くことの第一の価値は「言語化能力の訓練」だ。第二の価値が「採用市場での認知獲得」。

ブログを書くと、自分が「分かったつもり」になっていたことが言語化できないことに気付く。説明できないなら、本当には理解していない。書くことで理解が深まる、というのはエンジニアリングでも同じ。

公開する場所は Zenn、Qiita、自分のブログ、社内 Tech Blog、note、X (Twitter)、どこでもいい。1記事1000字以上、月1-2本、を3年続けると、確実に書き手として認知される。

採用側がブログで見るポイント

  • 書いている内容の深さ: 表面の使い方だけか、内部実装まで踏み込んでいるか
  • 継続性: 1記事だけより、1年以上書き続けている方が評価が高い
  • 間違いを認める: 「以前書いた記事の認識が間違っていたので訂正」みたいな姿勢は好印象
  • 自分の言葉で書いている: AI 生成丸出しの記事はマイナス評価

11-4. GitHub プロファイル

GitHub の貢献グラフ(緑のマス目)も採用市場で見られる要素のひとつ。ただし、「毎日コミットしている」ことより、「何を作っているか」「どんなコードを書いているか」を見られる。

逆に、GitHub に何もない状態は、特に若手では「実務以外でコードを書いていない」と見られる可能性がある。中堅以上は実務の成果物が GitHub に出ないことも多いので、若手ほど GitHub での活動が効く。

若手エンジニアの GitHub 戦略

  • 本業のコードは GitHub に上げられないことが多い。なので、別の作品を作る
  • 完成度が低くてもいい: WIP のプロジェクトでも、コードの書き方は伝わる
  • README を書く: プロジェクトの説明を書く力もエンジニアスキルの一部
  • 自分が学んだことのリポジトリ: 「Go で書いた小さい Web フレームワーク」みたいな学習用 OSS

第12章: 燃え尽き対策

12-1. これが一番大事

ここまで色々書いてきたが、本記事で一番伝えたいのはこの章だ。続けることが最強。30年エンジニアを続けた人は、5年で燃え尽きた人より圧倒的に多くを成し遂げる。技術スキルも、給与も、人脈も、複利で増えていく。

逆に、燃え尽きると半年-1年は「何もできない」状態になる。さらにひどい場合、メンタル不調でエンジニアを引退する人もいる。これは個人の悲劇でもあるし、業界の損失でもある。

燃え尽きの典型的なサイン

  • 朝、起きるのがつらい(寝てもとれない疲れ)
  • 仕事のことを考えると胃が痛む、息が浅くなる
  • 趣味だったコードを書くのが嫌になる
  • 集中力が極端に落ちる、簡単なバグが取れない
  • 同僚や家族と話すのが面倒
  • 「何もしたくない」が数週間続く

上のサインが2-3個出ている場合、すでに燃え尽きの初期段階に入っている可能性がある。早めに休む、相談する、医療機関を訪れる、を考えた方がいい。

12-2. 燃え尽きを防ぐ仕組み

「気合で頑張る」では燃え尽きは防げない。仕組みで防ぐ必要がある。

燃え尽き防止の仕組み

  • 睡眠時間を最優先: 7-8時間。これを削ると他の全部が破綻する
  • 週1日は完全オフ: コードを書かない、技術書を読まない、エンジニアの自分を切り離す日
  • 長期休暇を取る: 年1-2回、まとまった1週間以上の休み。海外旅行でも、田舎でゴロゴロでもよい
  • 業務時間外の通知を切る: Slack、メールを夜と週末は見ない(リーダー職以上は完全には無理だが、努力する価値はある)
  • 運動の習慣: 週2-3回、各30分以上。散歩でも筋トレでもヨガでも何でもいい
  • エンジニア以外のコミュニティ: 友人、家族、趣味の仲間。エンジニアとしか喋らない状態を避ける

↓ 燃え尽き防止のサイクル ↓

flowchart LR
    Sleep[睡眠 7-8h を死守] --> Focus[業務時間に集中して働く]
    Focus --> OffDay[週1日は完全オフ<br/>エンジニアの自分を切り離す]
    OffDay --> Exercise[運動 週2-3回]
    Exercise --> Social[エンジニア外の<br/>コミュニティと交流]
    Social --> Vacation[年1-2回の長期休暇]
    Vacation --> Sleep
    Focus -.通知遮断.-> Focus
    OffDay -.罪悪感を持たない.-> OffDay

12-3. 「頑張りすぎる人」が燃え尽きやすい

業界の観察として、燃え尽きやすいのは「頑張り屋」の人だ。手を抜くのが下手な人、責任感が強すぎる人、他人に頼るのが苦手な人。

逆に、適度に手を抜ける人、「これは自分の仕事じゃない」と線を引ける人、定時で帰る人、は長く続く。長く続いた結果、シニアやスタッフに到達する。

「頑張る」のは一見正しく見えるが、長期で見るとマイナスに働くことがある。30年走るレースで、最初の3年だけ全力疾走しても意味がない。

「頑張りすぎ」の見抜き方

  • 同僚と比べて、自分が明らかに業務時間が長い
  • 残業や休日出勤が常態化している
  • 「自分がやらないと回らない」と感じている
  • 休みを取ると罪悪感がある

上のどれかが当てはまる場合、長期的にはマイナス。仕組みで「頑張らなくても回る状態」を作る方向に動いた方がいい。

12-4. 燃え尽きてしまったら

予防の話をしてきたが、すでに燃え尽きてしまった人もいるだろう。その場合は以下の順序で対応する。

ひとつめ、仕事を減らす。可能なら長期休暇、それが無理なら有給を組み合わせて1週間以上の休みを作る。

ふたつめ、専門家に相談する。精神科・心療内科の受診はハードルが高く感じる人もいるが、エンジニア向けの理解のある医師は都市部に複数いる。会社に産業医がいれば最初の相談先になる。

みっつめ、抜本的な変化を検討する。職場を変える、職種を変える、業界を変える、休職する、を真剣に考える時期。3ヶ月以上の休職や、転職に半年かけることは、長期キャリアではノイズレベルの誤差だ。

第13章: 「楽しい」と「得意」のどちらを軸にするか

13-1. 議論の整理

キャリア論で永遠の議論になるのが「楽しいことを仕事にすべきか、得意なことを仕事にすべきか」だ。両方の主張に一理ある。

「楽しいことを仕事にすべき」派の主張

  • 楽しくないと長続きしない、燃え尽きる
  • 楽しいから自然と長時間没頭できる、結果として上達する
  • 仕事は人生の大半を占める、楽しくないとQOLが低い

「得意なことを仕事にすべき」派の主張

  • 楽しいだけでは食えない、対価が得られなければ持続不可能
  • 得意なことは評価される、評価されると報酬と機会が増える
  • 「楽しい」は変動する感情、「得意」はもっと安定した指標

どちらが正解、ということはない。状況によって最適解が変わる。

13-2. 「楽しい」と「得意」の交差点

理想は両方の交差点を見つけることだ。

                得意
                 │
          +------+------+
          |             |
  楽しい  |   ここが    |
   ──────┤   理想形    ├──── 不向き
          |             |
          +------+------+
                 │
              苦手

この「楽しい × 得意」のゾーンを見つけられた人は、長期キャリアが安定する。ただし、新人時代はまだ自分の得意・不得意が分からないので、最初は「楽しい」を入り口にして色々試し、3-5年でその中から「得意」を絞り込んでいくのが現実的だ。

13-3. 「楽しい」が変わる可能性

20代で「楽しい」と思った領域が、30代で「もう飽きた」になることもある。例えば、20代でフロントエンドが楽しかった人が、30代でデータエンジニアに惹かれる、というケースは普通にある。

これは悪いことではなく、興味の進化として受け入れていい。10年同じことに興奮し続ける方が珍しい。3-5年でメインの興味領域が変わっても、それまでに積み上げた技術は無駄にならない(横棒の基礎としては残る)。

「飽き」は成熟のサイン

「この領域、もう新しい発見が少ないな」と感じるのは、その領域である程度の深さに到達した証拠でもある。完全な初心者は「飽きる」感覚すら持てない。

飽きを感じたら、より深く掘る(プリンシパル方向)か、隣の領域に広げる(π字方向)か、を選ぶフェーズ。

第14章: 30代以降のキャリア

14-1. 30代で「マネジメント」を求められる時代の終焉

少し前までの日本の会社では「30代でマネジメントになるのが当然」「コードを書き続ける人は出世コースから外れる」という暗黙のルールがあった。今でも一部の会社では残っているが、業界全体としてはこの構図は崩れつつある。

理由は、IC ラダーの普及だ。第1章で触れたように、「コードを書き続ける」キャリアパスが正規ルートとして整備されつつある。30代でマネジメントを選ぶか、IC を選ぶかは、ほぼ等価な選択肢になってきている。

↓ 技術深堀 vs マネジメントの分岐 ↓

flowchart TD
    Senior[シニアエンジニア到達] --> Q{どこに価値を出すか}
    Q -->|技術の深さで勝負| Tech[IC路線へ]
    Q -->|チームの成果で勝負| People[マネジメント路線へ]
    Tech --> T1[専門領域の第一人者を目指す]
    Tech --> T2[横断的な技術判断<br/>複数チームに展開]
    Tech --> T3[OSS・登壇・論文で<br/>業界に名が知られる]
    People --> P1[評価・採用・組織設計]
    People --> P2[1on1・育成・心理的安全性]
    People --> P3[経営層との折衝<br/>事業戦略への関与]
    T3 --> Principal[プリンシパル / Distinguished]
    P3 --> VPE[VPE / CTO / C-level]
    Principal -.5年単位でロールチェンジ可.-> VPE
    VPE -.同上.-> Principal

30代以降の主な選択肢

マネジメント路線(EM, VPE, CTO)

  • チームを率いる、人事評価、採用、組織設計、技術戦略
  • コードはほぼ書かなくなる(月数時間以下になる人も)
  • 報酬の天井が高い(VP, C-level で年収数千万円)

IC 路線(Senior → Staff → Principal)

  • 技術で価値を出し続ける、複数チームに横展開
  • コードを書き続ける(時間は減るが、ゼロにはならない)
  • 報酬は IC ラダーが整った会社なら EM と同等以上

独立・起業路線(CTO, 個人事業主, スタートアップ起業)

  • 自由度が最大、ただし収入は変動が激しい
  • 経営、営業、財務、法務も自分で勉強する必要あり
  • 当たれば数億円、失敗すれば借金、というレンジ

副業・複業路線(複数社で並行)

  • 1社にコミットせず、業務委託で複数会社を回す
  • 自由度は高いが、安定性は会社員より低い
  • 2-3社を回せれば年収1500-3000万円が現実的

↓ 30代以降のキャリア選択肢 ↓

flowchart TD
    Mid30[30代エンジニア<br/>シニア相当] --> Choice{何を最大化するか}
    Choice -->|組織を率いたい| Mgmt[マネジメント路線<br/>EM → VPE → CTO]
    Choice -->|コードを書き続けたい| IC[IC路線<br/>Staff → Principal]
    Choice -->|自由度を最大化| Indep[独立・起業<br/>CTO/個人事業主/起業]
    Choice -->|複数社で並行| Multi[副業・複業<br/>業務委託で2-3社]
    Mgmt --> M_Reward[報酬天井 高<br/>コードは月数h以下]
    IC --> I_Reward[報酬はEMと同等以上<br/>コードを書き続ける]
    Indep --> In_Reward[当たれば数億<br/>外れれば借金]
    Multi --> Mu_Reward[年収1500-3000万<br/>安定性低]

14-2. 「30歳の壁」「35歳の壁」「40歳の壁」

転職市場でしばしば言われる「壁」がある。これは過去の慣習で、現代では緩和されつつあるが、まだ完全には消えていない。

  • 30歳の壁: 「未経験転職の限界」と言われた年齢。今はもう少し緩く、35歳くらいまでは未経験OKの会社も多い
  • 35歳の壁: 「マネジメント経験を求められる年齢」。IC ラダーがある会社では関係ない
  • 40歳の壁: 「中堅以上のポジションでないと面接通過率が下がる」。これは現実として残っている

「壁」を超えるためには、年齢に見合った経験と成果が必要、というのが現実的な見方。逆に言えば、30代後半でジュニア相当の経験しかないと、転職市場で評価が下がる。

14-3. 健康とライフイベント

30代以降のキャリアで現実的に効いてくるのが、健康とライフイベントだ。20代の頃のように夜中までコードを書ける体力はなくなる。結婚、子育て、親の介護、自分の病気、などが重なってくる時期でもある。

これらは「キャリアにとっての制約」ではなく、「キャリアの一部」として受け入れる方が良い。子育てで時間がなくなる時期に、無理に副業や OSS をやろうとすると燃え尽きる。短時間で最大の価値を出す働き方にシフトするタイミングだ。

ライフイベント期のサバイバル戦略

  • 業務時間で完結する仕事に絞る: 業務時間外の課外活動は減らす期間と割り切る
  • 会社のリモート/フレックスを最大活用する: 通勤時間と固定時間は機会損失
  • 配偶者・家族との分担を交渉する: 自分が全てやろうとしない
  • 専門サービスに頼る: 家事代行、ベビーシッター、介護サービス。「金で時間を買う」発想

第15章: ADHD・神経多様性とエンジニアキャリア

15-1. エンジニア業界の特性

業界の観察として、エンジニアには ADHD、ASD(自閉スペクトラム)、ディスレクシア、その他の神経多様性を持つ人の比率が、一般人口より高いと言われている。明確な統計は出ていないが、自己申告ベースの調査では「神経多様性あり」と答えるエンジニアが全体の20-30%に達する、というデータもある。

これは「エンジニアが特殊」というより、エンジニアの仕事がそうした特性と相性がいい部分が多いから、と理解した方がいい。深い集中(過集中)、抽象的思考、規則性への愛着、こだわりの強さ、これらは ADHD や ASD の特性として現れることがあり、同時にエンジニアの強みでもある。

ADHD とエンジニアの相性

強みになる部分

  • 興味あることへの過集中(ハイパーフォーカス): 数時間没頭して大量に書ける
  • 既存ルールを疑う発想: 新しい解決策を生みやすい
  • 並行的な思考: 複数の問題を同時に頭の中で扱える
  • 退屈に弱い: 改善・自動化へのモチベーションが高い

弱みになりやすい部分

  • 注意の維持が苦手: 単調な作業、長時間の会議が苦痛
  • 忘れ物・期日管理: タスク管理ツールなしでは破綻
  • 衝動性: 思いついたらすぐ手を出してしまう
  • 時間感覚のズレ: 「5分で終わる」と思って3時間かかる

15-2. 「弱み」ではなく「特性」として扱う

ADHD や ASD の傾向は、医療的には「障害」と分類されることもあるが、業務環境を工夫すれば「特性」として扱える。特性は使いこなせば強みになる。

例えば、ADHD の「集中できる時間が短い」特性は、25分作業 + 5分休憩のポモドーロ・テクニックで補える。「タスク管理が苦手」は、Notion / Linear / Things / Todoist などの外部記憶に頼る運用で補える。

ADHD エンジニアの実務テクニック

  • 環境設定: ノイズキャンセリングヘッドホン、デュアルモニタ、立ち作業デスク
  • タスク管理: 紙の手書きメモ + デジタル(2つ持つ、どちらかは見る)
  • 会議対応: メモを取りながら聞く(手を動かすと集中が維持できる)、議事録は録音 + AI 文字起こし
  • 時間管理: タイマー必須、休憩スマホ放置、SNS 通知オフ
  • 得意領域を選ぶ: 退屈な保守より、新規開発・難問解決が向いている人が多い

15-3. 神経多様性に理解のある職場の選び方

最近は「neurodiversity-friendly」(神経多様性に配慮した職場)を謳う会社が増えてきている。日本ではまだ少数だが、外資系を中心に増えている。

具体的な指標として:

  • リモートワーク可(対面コミュニケーションの負荷を選べる)
  • フレックスタイム(自分の集中時間に合わせて働ける)
  • 評価がアウトプット中心(プロセスより成果)
  • 多様な働き方を受容する文化(「9時に出社が当然」のような暗黙ルールがない)

このような職場では、ADHD やその他の特性を持つエンジニアが、長期で活躍しやすい。

開示するかしないか

自分の神経多様性を職場で開示するかどうかは、個人の判断。配慮を求めるなら開示が必要だが、開示するとレッテルを貼られるリスクもある。

配慮なしでも回るなら開示しない、必要に応じて産業医や信頼できる上司にだけ伝える、というのも選択肢のひとつ。日本ではまだ「開示しないで自助努力」のケースが多い。

まとめ: 自分の地図を描く

16-1. 本記事で見てきたこと

ここまで、エンジニアのキャリアを構成する15個の論点を見てきた。最後に整理する。

章論点
1レベルの段階(ジュニア→プリンシパル)
2コードを書くスキルと価値を出すスキルは別
3T字型・π字型
4バックエンド系の職種分岐
5フレームワーク追っかけの罠
6給与カーブと交渉
7転職のタイミング
8リモートと AI 時代
9副業・OSS・個人開発
10学習投資の戦略
11採用される条件
12燃え尽き対策(最重要)
13楽しい vs 得意
1430代以降のキャリア
15ADHD・神経多様性

16-2. 自分用の意思決定フレーム

15個の論点を踏まえて、自分用の意思決定フレームを持っておくと迷いが減る。例として、3つの軸を組み合わせるやり方を紹介する。

自分用キャリアフレーム(例)

軸1: 何をやりたいか(技術)

  • 自分が深掘りたい縦棒は何か
  • 5年後にどんな技術領域で第一人者と呼ばれたいか

軸2: どう働きたいか(働き方)

  • フルリモート / ハイブリッド / 出社、どれが望ましいか
  • チーム規模、会社規模、業界の好み

軸3: 何を最大化したいか(報酬・成長・自由)

  • 給与最大化なのか、技術成長なのか、自由時間なのか
  • 短期と長期の優先順位

この3つを書き出して、四半期に1回見直すと、転職判断・案件選び・学習投資の優先順位が定まる。

16-3. 「正解」はない、「自分の選択」がある

本記事を通して、何度か書いてきたが繰り返す。エンジニアのキャリアに「これが正解」というものはない。

給与至上主義も、技術ロマンも、自由至上主義も、それぞれに合う人がいて、合わない人がいる。重要なのは、自分が何を優先するかを言語化し、それに沿って動くこと。他人の SNS の発言に流されて、本当は自分が求めていないキャリアに進むのが、一番もったいない。

そして、選択は何度でもやり直せる。30代でマネジメントに進んでも、5年後に IC に戻る人はいる。フルスタックを10年やってからセキュリティに転向する人もいる。スタートアップで3年燃え尽きてから、メガテックで安定期に入る人もいる。

最後に伝えたい3つ

  1. 続けること が最強。30年走るレースで、短期の全力疾走は意味がない
  2. 自分の地図を持つこと。他人の地図で歩いても自分の場所には辿り着かない
  3. 動き続けること。同じ場所に長くいすぎると、選択肢自体が見えなくなる

この3つを胸に置いて、また明日からコードを書き、技術書を読み、たまには休む。それを30年続けたら、振り返った時に「いい人生だった」と思えるエンジニアになっているはずだ。

振り返り: 自分の現在地を確認する

通勤中・移動中の読み物なので、ノートに書く必要はない。頭の中で以下に答えてみてほしい。

  • 自分は現在、レベル1-5のどこにいると感じるか
  • 自分の縦棒(深い専門領域)は何か、もしくは何を作りたいか
  • 直近3年で「燃え尽きそうになった」経験はあるか、その時どう対処したか
  • 「楽しい」と「得意」がズレている領域はあるか、それを放置しているか
  • 自分の3つの軸(技術・働き方・報酬)の優先順位は何か

答えがすぐ出なくてもいい。出ない部分は、これからの3-6ヶ月で言語化していけばいい。

さらに深掘りするなら

書籍:

  • 『Staff Engineer: Leadership beyond the management track』(Will Larson) - スタッフエンジニアのキャリアパス専門書
  • 『The Manager’s Path』(Camille Fournier) - エンジニアからマネジャーへの道
  • 『Pragmatic Programmer』(Hunt, Thomas) - エンジニアの仕事の哲学。1999年初版だが今も色褪せない
  • 『達人プログラマー』(上記の和訳)
  • 『SOFT SKILLS』(John Sonmez) - エンジニアのライフスタイル全般
  • 『プログラマー脳』(Felienne Hermans) - 認知科学から見たプログラマー

ブログ・記事:

  • Staff Engineer Newsletter (Lethain): https://lethain.com/ - スタッフエンジニアの一次情報
  • Charity Majors のブログ: https://charity.wtf/ - エンジニアリングマネジメントの率直な話
  • Pragmatic Engineer (Gergely Orosz): 業界動向と給与レンジの調査

統計データ:

  • Stack Overflow Developer Survey - 毎年行われる業界アンケート、給与・技術の最新動向
  • State of DevOps Report - DevOps 関連の年次レポート
  • GitHub Octoverse - GitHub からみる OSS の動向

カリキュラム本編に戻る

読み物章はここまで。骨太な読書として味わったら、次は手を動かす章に戻って、コードと向き合おう。

長期戦のレースだ。今日読んだことの2割でも、3年後に効いてくる。それで十分。

グラフビュー

バックリンク