末永雄大＠すべらないエンジニアのキャリア論

新卒リクルート→サイバーエージェント→アクシス起業｜
登録8.4万人のYoutube「すべらない転職」を運営

約20年、数万人以上のキャリア支援をおこなってきた知見をもとに、これからのエンジニアのキャリア論を発信していきます🫡

職種を問わないキャリア論・経営者としての発信はこちら → @yuutasue0501

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

あなたは「テックリード」に向いているか？

□ 自分が手を動かすより、チームの実装が速く正確になるほうが嬉しい
□ 技術選定で、採用する理由だけでなく、採用しない理由も説明できる
□ レビューを「指摘」ではなく「設計の合意形成」として使っている
□ 障害が起きたとき、犯人探しではなく、再発防止の仕組みに意識が向く
□ 難しい技術の話を、非エンジニアにも伝わる言葉に翻訳できる
□ 「これは今やる、これは後で返す」と技術的負債の優先度をつけられる
□ メンバーが詰まっているサインに、聞かれる前に気づける

7つのうち5つ以上当てはまれば、テックリードの素質は十分。
テックリードはコードが一番うまい人がなる役割ではない。

[カール｜AIで内定率を上げる中高年転職コーチ @karl_workstress]

経験をどう伝えるかで価値は大きく変わるよね。 30代転職は足し算より翻訳が近道。 自分の強みを 別の文脈 で示すことが大事。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

30代の転職でいちばん大事のは、新しいスキルを足すことではなく、これまでの経験を「翻訳し直す」ことだと考えています。

理由は、30代に求められているのが、ゼロからの伸びしろではなく、すでに持っている「経験の再現性」だからです。

たとえば、SIerで長く保守をしてきた方がいたとします。
本人は「保守しかやってこなかった」と弱気になりがちですが、その経験を「止められないシステムを支え、障害の原因を切り分けてきた」と解釈し直すと、事業会社のデータ基盤やSREの文脈で、急に価値が伝わるようになります。

実際、職務経歴書を「担当した作業」から「解決してきた課題」に書き換えただけで、書類の通過率が体感で大きく変わる方を、何人も見てきました。

新しい言語を一から覚えるより、まず手元の経験を棚卸しして、別の文脈で通じる言葉に翻訳してみる。

30代の転職は、足し算よりも、「翻訳」から始めたほうが、実は近道になることが多いです。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

ありがとうございます！

本当にそうで、求人票に「自社開発」と書いた採用担当の方自身が、現場の実態と離れているケースは少なくないと感じています。

人事が魅力的に書いた求人と、入って配属される現場の温度が違う、という。。。。

だからこそ候補者側は、求人票の言葉だけでなく、面接で「実際に使っている技術」と「直近で内製したもの」を、現場のエンジニアに直接聞いてみるのが安全ですよね。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

「事業会社に転職すれば、モダンな自社開発ができる」

転職相談を受ける中で、この前提を持っている方はとても多いですが、これは少し雑な解釈だなと感じています。

「事業会社」と一口に言っても、中の開発組織は大きく分かれていて、入る場所を間違えると「思っていたのと違う」となりやすいです。

ざっくり整理すると、こうなります。

①情報システム部門。社内システムの企画とベンダー管理が中心で、自分でコードを書く比率は低めです。

②基幹系の社内開発。COBOLやレガシーなJavaやSAPなど、止められないシステムの保守が主戦場です。

③プロダクト本部やテクノロジー本部。Reactや Go、クラウドネイティブな構成で、toC/toBのプロダクトを内製しているところです。

④メガベンチャーやSaaSのエンジニア組織。モダンスタックに加えて、技術投資や採用にも積極的です。

「自社開発でモダンな環境」をイメージしているなら、それは③か④の話で、①や②に入ると、ギャップが大きくなります。

見極めのポイントは、求人票の「自社開発」という言葉ではありません。
技術スタックが具体的に書かれているか、内製比率はどのくらいか、技術ブログやGitHubでの発信があるか。

このあたりを見ると、その組織が実際にどのパターンなのかが見えてきます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

第一位
うまくいった実装の話しかしない。

本当に見たいのは、本番で障害を出したとき、原因をどう切り分けて、再発をどう防いだか。
ポストモーテムを自分の言葉で語れる人は、面談で一気に評価が上がります。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

転職面接で、もったいないと感じるエンジニアの特徴

第三位
技術選定を「流行っていたから」で説明する。
なぜその言語、そのフレームワーク、その構成にしたのか。トレードオフを自分で語れるかが見られています。

第二位
実績を「規模」でしか語らない。
何万リクエスト、何億レコードよりも、その負荷に対して自分が何を設計判断したかのほうが、ずっと重要。

第一位

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

コードを書くAIの実力が、この一年でどれだけ上がったか。

SWE-benchという、実際のGitHubのバグ修正タスクをAIに解かせて正答率を測るベンチマークがあります。
ここでのスコアが、わずか一年で50%前後から80%超へと上がりました。

実際のリポジトリの不具合を、AIが八割方こなせるようになってきた、ということです。

これは「コードを書ける」こと自体の希少性が、下がっていることを意味しています。

では、何が残るのか。

①何を作るかを決める設計と要件定義。
②AIが出したコードを業務やセキュリティの観点でレビューし、責任を持って通す判断。
③AIに正しく仕事をさせるための、前提と制約の言語化。

採用の現場でも、この変化は実際に出始めています。
「実装できます」だけでなく、「AIをどう使って、何を判断したか」を語れる人のほうが圧倒的に評価されます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

エンジニアの「売り手市場」、もう終わりかけています。

エンジニアtypeが公開している2026年の市場データによると、ITエンジニアの求人倍率自体は、ここ最近ほぼ横ばいで推移しています。2026年6月の現時点でも、求人数は前年と大きくは変わっていません。

ところが同じデータで、応募数は全体で1.4倍、20代から30代に絞ると1.3倍に増えています。

つまり、求人の数は大きく変わっていないのに、その一つの枠に応募する人は増えている。
一つ一つの求人をめぐる競争が、激しくなっている、ということです。

実際、dodaなどの集計でも、企業側の姿勢は「とにかく採る」から「厳選して採る」に変わってきています。

この状況で必要なのは、応募数を増やす戦略ではないと考えています。

むしろ、一社ごとに「なぜこの会社で、自分の何が活きるのか」を言葉にできるかどうか。
競争が激しくなるほど、量で押すより、一社ごとの納得感で差がつきます。

その意味で、いまは「”数打ちゃ当たる”転職活動」から「一社ごとに深める転職活動」に切り替えるタイミングだと考えています。

求人が多いから安心、ではなく、応募が増えているから丁寧に。

具体的に何をするべきか。

一つは、応募する前に、その会社の事業やプロダクトを自分の言葉で説明できる状態にしておくこと。
求人票をなぞるのではなく、「この会社は何で稼いでいて、自分のどの経験が役に立つか」まで踏み込んでおく。

もう一つは、過去の経験を「やったこと」ではなく「どんな課題を、どのように解決したか」で語れるよう整理しておくことです。

派手な実績は要りません。
小さく良いので、自分の判断で動いた経験を具体的に話せる人が、競争が激しい局面ほど通過していきます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

伸びるエンジニアの見分け方、エラー報告編。

止まってしまう人は、「動かないです」で終わります。

伸びる人は、こう報告します。
「Aの画面でBの操作をしたら、500が返ってきました。再現は100%です。
ログを見るとここでNullPointer、直前のクエリが想定とずれているので、まずパラメータの渡し方を疑っています。」

何が起きたか、再現性はあるか、どこまで切り分けたか、次に何を試すか。
これらが、自分の言葉で話せているかどうか。

技術力そのものより、こういった部分に差が出ると感じています。

なぜなら、調べれば分かる知識はAIが埋めてくれる時代になったため、残るのは「事象を構造で捉えて、仮説を立てて、検証の順番を決める力」。

意外とエラー報告は、この力が如実に出ます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

「面接で必ず『設計工程の経験はありますか』と聞かれます。第二新卒で、設計経験なんてないのに…」

先日、20代エンジニアの方から、こんな相談をもらいました。

この手の話で毎回思うのは、「設計経験」を大きく捉えすぎている方が多いということです。

面接官が知りたいのは、「大規模システムをゼロから設計した」のような実績そのものではなく、
「自分で考えて、選んで、その理由を説明できるか」という、判断の経験なんです。

たとえば、小さな機能を実装するときに、なぜそのデータの持ち方にしたのか。
なぜ別のやり方ではなく、この方法を選んだのか。

規模が小さくても、自分なりに理由を持って選んだ経験があれば、それは立派な「設計的な判断」です。

一つあるとしたら、過去の実装をひとつ取り出して、「なぜそう作ったか」を言葉にする練習をしてみることをおすすめします。

「言われたとおりに作りました」で終わらせず、「ここはこう考えて、こう選びました」と語れるようにする。

それだけで、面接での見られ方は大きく変わります。

設計経験がない、のではなく、これまでの判断を設計の言葉で語れていないだけ、というケースが多いなあと感じてます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

TIOBEが出しているプログラミング言語の人気ランキング（2026年5月版）では、首位は変わらずPythonでした。

上位は、Python、C言語、Java、C++、C#という並び。

この手のランキングを見ると、つい「どの言語を学べば食べていけるか」という話になりがちなんですが、本当に重要なのはもっと別のところ。

直近のトレンドとして、AIやデータ分析の主役はPython、Web開発はTypeScriptが標準、という住み分けがかなりはっきりしてきました。
言い換えると、「何の言語を書けるか」よりも、「どの領域で、何を作るために、その言語を選ぶのか」が問われ始めています。

さらに言えば、いまは多くの現場で、コードそのものはAIに書かせる前提に変わってきています。

そうなると、効いてくるのは言語の暗記量ではなく、「この設計でいいか」「この実装は適切か」を判断できる力のほうです。

学ぶ言語を選ぶときも、ランキングの順位だけを見るのではなく、自分がどの領域で勝負したいかから逆算することが重要ですね。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

鋭い視点をありがとうございます！

たしかに、所属会社が技術をくみ取ってくれても、最終的に入る顧客先が雑だと痛い目を見る、というのはその通りですね。所属と顧客先で面談が二段階ある、という指摘もまさにで、自分も見落としがちな観点でした。

挙げてくださった「案件決定までのリードタイム」と「メンバーの案件継続期間」は、どちらも営業力を測る本質的な指標だと感じます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

「SESはやめとけ」

エンジニアのキャリアの話になると、よくこの言葉を見かけます。

ただ、これは少し括りが雑だなと感じてます。

SESと一口に言っても、振れ幅が本当に広くて、ひとまとめに「やめとけ」と言える対象ではないです。

実態を整理すると、
①現場が変わるたびに技術スタックが飛び飛びになり、スキルが積み上がりにくい会社
②逆に、特定領域に強く、一貫した経験を積ませてくれる会社
③単価の透明性が低く、給与に反映されにくい会社
④単価や評価をオープンにしていて、上流案件に挑戦させてくれる会社

同じ「SES」でも、①③に当たるか、②④に当たるかで、3年後のキャリアはまるで変わってきます。

では、どこで見極めるか。

1つ、分かりやすい目安があります。
面接で技術的なことをちゃんと深掘りされるかどうか、です。

技術の話がほとんどなく、浅いところで簡単に面接が終わる会社は、正直警戒したほうがいいです。
そういう会社は、エンジニアを「人数」として見ている可能性が高いです。

逆に、技術的な経験や考え方を丁寧に聞いてくる会社は、その後の配属やキャリアも個人を見て設計してくれることが多いです。

「SESかどうか」で一括りに判断するより、「その会社が、自分の技術とキャリアをどう見ているか」で判断しましょう。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

https://t.co/R3SDqcdIqh

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

@tech_nyannya ありがとうございます！

そうなんですよね。受託だと「言われた通りに作る」が評価軸になりがちですが、事業会社は「何を作るか」に関われる分、これまでの技術経験が意思決定の武器になりますよね。

場所を変えるだけで、同じ実力でもキャリアの伸び方が変わると感じてます。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

30歳・SIerの運用保守でキャリア不安を抱いていた方が、事業会社のデータエンジニアに転身されて年収を160万アップさせた事例。

前職は、中堅SIerの運用保守チーム。
金融系システムの監視、障害対応、夜間バッチのメンテナンスが中心で、自分でコードを書く時間は年々減っていたそうです。

年収は480万。
夜間のオンコール対応もあり、本人としては「このまま保守を続けて、3年後に何のスキルが残るんだろう」という不安が、大きくなっていました。

最初にご相談をいただいたとき、本人がおっしゃっていたのは「もう一度、手を動かす仕事に戻りたい」ということでした。
ただ、30歳で実装からしばらく離れていたこともあり、「いまさら開発職に戻るのは難しいですよね…」と、ご自身ではかなり弱気になっていらっしゃいました。

実際には、30代前半で保守から開発・データ領域に移る方は、決して珍しくありません。
むしろ運用保守で培った経験が強みになることもあります。

最初に一緒にやったのは、求人を探すことではなく、これまでの仕事の棚卸しでした。

保守の仕事の中で、本人が何にいちばん集中できていたかを丁寧に書き出していくと、ある共通点が見えてきました。

「障害の原因をログから探り当てる作業や、夜間バッチのデータの流れを追う作業のとき、時間を忘れて没頭していた。」
ここから、「データの流れを設計し、構築する仕事が合っているのではないか」という仮説が立ちました。

ちょうど市場でも、データエンジニアは需要が伸びている一方で、担い手が足りていない職種。
保守で培った「データの流れを追う力」「障害に強い堅牢な設計の感覚」は、そのまま活きる領域でした。

そこから、平日の朝1時間と週末を使って、SQLとPythonを学び直し、クラウドのデータ基盤サービスを実際に触ってみる。
保守時代に自分が書いていた夜間バッチ処理を、モダンな構成で作り直したものを、ポートフォリオとしてまとめました。

職務経歴書も、書き方から見直しました。

「運用保守をしていた」ではなく、「データの流れを監視し、障害を解決し、システムの堅牢性を担保してきた」という軸で書き直す。
同じ経歴でも、どのように表現するかで、書類の通過率は体感で大きく変わります。

面接対策では、保守経験を「守りの仕事」ではなく「データ基盤を支えてきた実務」として語れるように、エピソードを一緒に整理していきました。

たとえば、深夜に起きたバッチの障害を原因まで追い切って復旧させた経験。

これを「大変だった苦労話」で終わらせるのではなく、「データの流れのどこで何が詰まるかを構造で理解している」という強みのエピソードに組み替える。
同じ出来事でも、見方を変えるだけで、面接官への伝わり方がまるで変わります。

準備期間は、およそ4ヶ月。

働きながらの学び直しなので、決して楽ではなかったと思いますが、それでも「保守の延長ではない場所に行きたい」という軸がはっきりしていたので、走り切れました。

応募は9社、書類通過6社、最終まで進んだのが3社。

最初の数社は手応えなく落ちましたが、面接での経験の語り方を一社ごとに振り返って磨いていった結果、後半の通過率は上がっていきました。

最終的に、SaaSを提供する事業会社のデータエンジニアとしてご入社されました。

提示条件は、年収640万、フルリモート可、オンコールなし。担当は、プロダクトのデータ基盤の構築と、分析チームへのデータ提供です。

転職後しばらくしてお話を伺うと、年収が160万上がったこと以上に、本人が変わったとおっしゃっていたのは、別のところでした。

「自分が作ったデータの流れが、そのままプロダクトの意思決定に使われている」
「保守で身につけた"壊れにくくする感覚"が、評価されている」

保守の経験は、決して無駄ではなかった。
むしろ、それが強みになる場所に移れたことが大きかったと話されていました。

この方が転職に成功した一番の要因は、新しいスキルをゼロから詰め込んだことではなく、
すでに持っていた「データの流れを追う力」と「壊れにくく作る感覚」を、ちゃんと言葉にして、それが活きる場所を選んだこと。

未経験の分野にいきなり飛び込むより、いまの経験が"強みとして翻訳できる領域"を探すほうが、30代の転職では現実的で、しかも入社後に伸びやすい。

この事例から、いまの仕事が地味に見えても、その中で集中できている瞬間にこそ、次のキャリアのヒントが隠れていることが多い、と改めて感じました。

「実装から離れたから、もう戻れない」と思い込んでいる方にこそ、一度、自分が没頭できていた作業を棚卸ししてみてほしいなと思ってます🫡

[鈴木将斗｜キャリアコーチ @Masatoocoach]

今は答えは出してくれる世の中なので何事も決める力が大事になりそうですね。

[末永雄大＠すべらないエンジニアのキャリア論 @sue_engineer]

「AIに仕事を奪われるかもしれない」という不安を、エンジニアの方からよく聞くようになりました。
ただ最近、この前提をひっくり返す事実が分かりました。

経済産業省が2026年3月に公表した「2040年の就業構造推計」が、ここ最近メディアで引用されるようになってきました。
そこで示されているのはくっきりとした二極化で、AIで省力化が進む事務職は、2040年に約437万人の「余剰」。

一方で、AIやロボットを使いこなす専門人材は、339万人の「不足」（需要782万人に対して供給443万人）。
つまり、国の公式データが「事務は余り、AIを使いこなす専門人材は足りない」と裏付けたわけです。

ここでエンジニアの方にとって大事なのは、自分たちが「奪われる側」ではなく「足りない側」に分類されている、という事実だと思っています。

ただ、足りないのは「AIを使いこなす専門人材」であって、「すべてのエンジニア」ではないんです。

代替されていくのは、決まった仕様どおりにコードを書く工程。
代替されにくいのは、何を作るかを決める設計、顧客との対話、技術選定やトレードオフの判断。

同じ「エンジニア」という肩書きでも、自分の仕事のうちどちらの比重が大きいかで、3年後の立ち位置は大きく変わってくると考えてます。

実際、2026年に入ってからのグローバルテック業界では、四半期だけでおよそ8万人規模のレイオフが起きている。
その一方で、AIエンジニアやデータエンジニアの求人は増え続けていて、年収レンジも上振れしている。

「テック全体が縮んでいる」のではなく、「巻き取られる仕事」と「足りない仕事」の差が開いているだけ、という解像度で見たほうが正確だと感じています。

では、いまの市場で「足りない側」とされているのは、具体的にどんな職種なのか。

私が見ている範囲では、上昇トレンドにあるのは以下のような方々です。

・何を作るかを決めるプロダクトマネージャー。
・AIの実装を担うAIエンジニアやLLMエンジニア。
・データの基盤を設計するデータエンジニア。
・複雑なシステム全体を描くクラウドアーキテクト。
・そしてチームの技術方向を決めるテックリードやVPoE。

共通しているのは、どれも「コードを書く速さ」ではなく「何をどう作るかを決める力」が問われる仕事だということです。

では、何から始めれば良いのか。

私が普段おすすめしているのは、いきなり転職ではなく、いまの仕事の中で「設計・AI活用・上流の判断」に触れる時間を意識的に増やすことです。

・要件定義に一度入ってみる。
・チームでAIツールの使い方を整理する役を引き受けてみる。
・小さくてもアーキテクチャの意思決定を任せてもらう。

こうした経験の積み重ねが、「不足する339万人の側」に回るための、地に足のついた一歩になります。

「AIに奪われるかもしれない」と身構えるより、「足りない側にどう回るか」で考えたほうが、打ち手はずっと具体的になります。

[末永 雄大｜アクシス(株)代表取締役＠20代のキャリアをサポート（マジキャリ） @yuutasue0501]

新しく、「エンジニアキャリア特化」のサブアカウントを立ち上げました。

→ @sue_engineer

ここ1〜2年、AI時代に入ってエンジニアの方からのキャリア・転職相談が目に見えて増えてきたのが背景です。

「コードを書き続けて、3年後どうなっているんだろう」

「上流の意思決定に近い仕事がしたいけれど、何から始めればいいか分からない」

こうしたご相談を、毎週のように伺うようになりました。

本アカウントでは引き続き、職種を問わない転職市場の話やキャリア論、経営者としての発信を続けていきます。

新しいサブアカは「エンジニアキャリア特化」に振り切って、業界構造・年収レンジ・市場価値の上げ方・AI時代のスキル投資・面接準備まで、エンジニアの方に向けて率直に書いていきます。

エンジニアの方や、お知り合いにエンジニアの方がいらっしゃるフォロワーさんは、よかったら覗いてみてください！