ITエンジニアのキャリアをどう考えればよいのか。それは、エンジニア本人のみならず、彼らのキャリアを共に考えるエンジニアリングマネージャーにとっても難しい問いである。

人は、難しい問題にぶち当たったとき、その緊急度が低ければ後回しにしがちだ。だから、いざ答えを求められたときに、場当たり的な言動・行動をとってしまうことがある。マネージャーとしてこれは避けたい状況だ。

メンバーのキャリアを真剣に考えるとき、マネージャーの視野は自然と組織全体へ広がる。個人の成長支援だけでなく、組織戦略やチーム設計との整合が欠かせない。

つまり、キャリアの問題は組織の問題でもあるのだ。

書籍『ITエンジニアの転職学』は、エンジニア個人の転職にとどまらず、そうしたマネージャーの思考を整理する手がかりを与えてくれる。

本記事では、エンジニアリングマネジメントの視点から、エンジニアのキャリアと組織戦略の関係性を軸に本書を読み解く。したがって、タイトルにある「転職」というテーマからは少し離れ、組織論的な読み方になる。その点はあらかじめご了承いただきたい。

• 参考書籍の紹介
• エンジニアリングマネジメントの視点からメンバーのキャリア設計を見る
• エンジニアの役割を8つの分類と2つの軸で捉える
• エンジニアの能力を6つのカテゴリと5つのレベルで捉える
• 個人の成長を支援する
  • 「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性
• 個人のキャリア戦略と組織戦略を接続する
• 進化し続けるAI時代だからこそキャリアも組織も経験主義で適応を繰り返す
• 最後に

参考書籍の紹介

2025年10月24日に講談社から出版された『ITエンジニアの転職学 2万人の選択から見えた、後悔しないキャリア戦略』を、著者の赤川朗氏からご恵贈いただいた。

www.kspub.co.jp

本書は、2万人のITエンジニアのデータを分析し、転職を成功に導く知見を体系化し、指南している。その内容も網羅的だ。転職市場における読者自身の立ち位置の分析方法から、職務経歴書の作成、選考プロセスの対策、さらには転職後のマインドにまで至る。

何より素晴らしいのは、その視点が「転職」という単一イベントにとどまらず、それをITエンジニアのキャリア設計の一部として組み込んでいる点にある。転職を考えている人だけでなく、考えていない人も、自身のキャリア設計の参考書として何度も読み返して欲しい一冊だ。

エンジニアリングマネジメントの視点からメンバーのキャリア設計を見る

マネージャーがメンバーのキャリアを考えるとき、注視すべきは “個人” と “組織” の2つの側面である。どれほど優秀な個人であっても、その成長方向が組織戦略と交わらなければ十分に力を発揮できない。結果として組織も力を失う。これは、どちらにとっても不幸だ。

マネージャーにとってのキャリア支援とは、個人と組織の接点を見つける営みなのだ。そのため、マネージャーは次の三つの課題を同時に見据える必要がある。

1. 個人の成長支援
2. 組織戦略
3. 組織設計の最適化

これら三つは独立して存在するのではなく、連動している。組織戦略が目指す方向を定め、組織設計がその実行体制を形にする。そして、個人の成長支援がそれを可能にする力を育てる。現場での成長の結果は、設計や戦略の見直しにもつながる。

こうした複雑な関係性を整理するうえで、『ITエンジニアの転職学』の枠組みは有効だ。同書で定義されているエンジニアの「役割」と「能力」は、キャリアを個人視点だけでなく、組織の構成要素として捉えるための共通言語になる。まずは、この二つの概念を簡潔に紹介する。

エンジニアの役割を8つの分類と2つの軸で捉える

『ITエンジニアの転職学』では、エンジニアの役割を次の8つに整理している。詳細はぜひ書籍を手に取ってほしい。

• はじまりの開発者
• テックリード
• 横串組織（SRE, セキュリティ、CTO室など）
• スクラムマスター/プロジェクトマネージャー
• エンジニアリングマネージャー
• プロダクトマネージャー
• 専門家（エキスパート）
• 他職種との融合（技術広報、CRE, FDE, ITコンサルなど）

本書では「役割」という言葉を「キャリアパス」の段階として扱っている。つまり、「はじまりの開発者」から始まり、そこから他の7つの役割へとキャリアを歩んでいくという考え方だ。

さらに秀逸なのは、これらの役割を2つの軸で整理している点である。この図により、エンジニアとしてどの方向で成果を発揮していくのかを俯瞰できる。

• 縦軸:
  • 上方向: ユーザー・事業・組織課題を解く力
  • 下方向: 技術課題を解く力
• 横軸:
  • 左方向: 個の力
  • 右方向: 組織の力

軸のラベルは「力」と表現されているが、これは、その力を用いて発揮する「成果」の方向性だととらえるとよい。たとえば、「はじまりの開発者」は中央に位置し、「EM」は右上、「専門家」は左下にプロットされる。このマップを使えば、自分の立ち位置や次に伸ばすべき力を具体的に考えられる。

余談であるが、「はじまりの開発者」というネーミングがロールプレイングゲームの職業名っぽくて気に入った。エンジニアとしての冒険が、今まさにはじまるようだ。

エンジニアの能力を6つのカテゴリと5つのレベルで捉える

エンジニアの能力については、6つのカテゴリと5つのレベルで整理されている。この枠組みによって、個々のスキルを俯瞰的に捉えることができる。

• カテゴリ:

  • 設計力・実装力
  • 専門性の深さと広さ
  • 推進力・プロジェクト貢献
  • 組織貢献
  • 事業・顧客貢献
  • 情報発信・プレゼンス

• レベル:

  1. 要支援
  2. 自立
  3. 主力
  4. リーダー
  5. 社内第一人者・業界リード

本書では、これらをもとに各役割をレーダーチャートで可視化している。しかも、役割ごとに年収データと連動したチャートが描かれており、極めて実践的だ。この枠組みを活用すれば、自社内の評価に閉じず、客観的な役割・能力定義に基づいてキャリア設計や組織設計を進めることができる（できれば、毎年このチャートを更新して公開して欲しいところだ）。

個人の成長を支援する

役割定義と能力定義は、マネージャーがメンバー本人とキャリア支援を対話で合意し、行動に落とし込むための共通言語になる。

たとえば、次の順で対話を進める。

1. 役割: どんな役割を担いたい/担ってほしいか
2. 方向: その役割は2軸上でどこに位置し、どんな力と成果が求められるのか
3. 適合性: 役割に対して各能力カテゴリのレベルがどれだけ充足/不足しているか
4. 計画化: どの能力カテゴリを、どのように伸ばしていくか

注意したいのは、すべての能力を一様に上げようとしないことだ。現実的には、強化すべき能力を絞り、そのための機会設計（任せる仕事やレビュー観点、伴走の仕方など）まで具体化することが重要である。

また、キャリアの方向は後述する組織戦略と接続して考える必要がある。もちろん、本人の意向を無視してはならない。両者が交わる領域を見いだし、そこに成長機会を設計することが肝要だ。

「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性

エンジニアのキャリアパスを、大きく「スタッフプラス」と「エンジニアリングマネジメント」という2つの方向性に分けて捉えると、キャリア設計に関する対話が格段に整理しやすくなる。

書籍『スタッフエンジニア　マネジメントを超えるリーダーシップ』では、キャリアラダーを「シニア」を起点にこの2つへと分岐させている。

この考え方は、『ITエンジニアの転職学』で示された二軸のキャリアマップにも対応づけられる。左上から右下に一本の対角線を引くと、左下がスタッフプラス、右上がエンジニアリングマネジメントの領域となる。中央付近の領域は、キャリアラダー上の「シニア」以下のポジションにあたる。

スタッフプラスの4つのアーキタイプ──「テックリード」「アーキテクト」「ソルバー（解決者）」「右腕（ライトハンド）」──は、この左下の領域に位置づけられる。実際、『ITエンジニアの転職学』でも、テックリードが下段中央に描かれており、整合が取れる。

この整理により、マネジメント方向に進むか、IC（Individual Contributor, 個人貢献者）として専門性を深めるかというキャリアの方向性を、マネージャーとメンバーの双方で明確に話し合いやすくなるだろう。

個人のキャリア戦略と組織戦略を接続する

エンジニアリングマネージャーが向き合うべきは、個人のキャリアと組織戦略の接続点である。メンバーの成長を支援することは、同時に組織の進化を設計することでもある。

組織戦略とは、目指す組織（ToBe）と現在の組織（AsIs）とのギャップを、どの軸で埋めていくかを定める方針だ。ToBe像は決して固定された形ではなく、環境変化やビジネス戦略に合わせて絶えず変化する。

そして、その方針を具体の構造に落とし込むのが組織設計である。どのようにチームを分け、どんな人材をどこに配置するかがここで決まる。

では、それをどう構造的に捉えればよいか。ここでもまた、『ITエンジニアの転職学』のキャリアマップは有効なフレームワークとなる。

たとえば、2軸マップ上に、ToBeとAsIsの人材分布を重ねて描くことができれば、どんな人材や役割を強化すべきかが見えてくる。「テックリードや（特定領域の）専門家を増やさなければならない」といった具体的な課題が見えてくるだろう。そのギャップを埋める戦術として、採用や異動を選択することもあれば、育成を選択することもある。

重要なのは、個人のキャリアを独立したものと見なさず、組織の設計要素として扱う視点を持つことだ。

こうしたアプローチをとることで、キャリア定義という “個人の道具” が、“組織を設計するための地図” にもなり得る。『ITエンジニアの転職学』は、エンジニア一人ひとりのキャリアを見つめるための書であると同時に、マネージャーが組織を設計するための座標軸を与えてくれる本でもあるのだ。

進化し続けるAI時代だからこそキャリアも組織も経験主義で適応を繰り返す

エンジニアリング領域におけるAIの進化の速さが、組織戦略と個人のキャリア戦略のあいだに“ずれ” を生んでいる。組織戦略からトップダウンで導き出したキャリアパスが、AIによる現場の変化に追いつけていないのだ。

この状況が、キャリアに対するメンバーらの漠然とした不安を呼び起こしている。「自分の役割がこの先どうなるのか」「このスキルはもう古いのでは」といった不安は、このずれの中で生じるものだ。

『ITエンジニアの転職学』で赤川氏は、AIの得意領域が2軸のキャリアマップの中心から同心円状に外へと広がっていくと予測している。現在のAIは、主に定型的な形式知を扱うことを得意とするからだ。

だが、読者であるエンジニアやマネージャーが、そこから短絡的に次の図式へ飛ぶのは危うい。

1. キャリアマップの中心に位置するジュニアエンジニア（はじまりの開発者）の活躍と経験の場が失われる
2. より外側に位置するシニア以上のエンジニアの活躍と経験の機会が増える

実際のダイナミズムはもっと複雑だ。ジュニアが経験を積めなければ将来のシニアは育たず、シニアばかり残れば組織は硬直化する。さらにAIの得意領域が外側まで広がれば、シニアさえ代替される。

だが、きっとそうはならない。

AIの進化によって、否応なく構造的変化が始まるはずだ。エンジニアに求められる役割も能力も、変化が強制されるのだ。もし組織がその変化に受け身でいたなら、エンジニアの努力は旧来の枠組みに閉じ込められ、力を発揮できなくなる。

だからこそ、変化によって生じる “ずれ” を早く検知し、素早く更新する仕組みを持つことが重要だ。AIによって変わる現場の実態に、組織構造を合わせていく。それが、組織を進化させ続け、キャリア不安を和らげる有効な方法である。

私たち人間はまだ、AIとの協働に関する知識と経験を十分に持っていない。それらが不足すれば、組織設計に関する意思決定も最適にはならない。

だからこそ、経験主義による意思決定が力を発揮する。小さく試し、学び、修正を重ねる。その探索プロセスを回し続けるのだ。プロダクト開発と同様に、組織設計も仮説検証を繰り返す学習システムとして捉えるべきである。

余談であるが、AI時代に変わりゆくエンジニア、チーム、組織については、こちらの記事も参考にして欲しい。

mtx2s.hatenablog.com

最後に

『ITエンジニアの転職学』を読んで感じたのは、著者である赤川氏のエンジニアへの深い愛情だ。ひとりでも多くのエンジニアが後悔なくキャリアを歩めるように――その願いが全編を通して貫かれている。

本書は転職の指南書であると同時に、「エンジニアの人生をどう設計するか」を問う一冊でもある。エンジニアのキャリアがAIによって大きく変わり始めた今だからこそ、手に取ってほしい。

あわせて、本稿のテーマにも関わる自身の取り組みを紹介したい。

2025年8月25日に拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された。

エンジニアのキャリアそのものには触れていないが、チームや組織の設計について詳しく解説している。両書を併せて読むことで、キャリアと組織を結ぶ全体像がより明確に見えてくるだろう。

gihyo.jp