11 ポイント 投稿者 GN⁺ 2026-03-04 | 3件のコメント | WhatsAppで共有
  • 技術変化のスピードが急激に速くなった時期において、管理職へ転換すると技術への適応力や実験の機会が減るリスクが大きくなる
  • 企業構造がフラット化し、EM → Director → VPへと続く昇進ルートが狭まり、競争が激化している
  • 業界全体でシニア・スタッフエンジニアの報酬がEMより高く設定される傾向があり、管理職への転換が経済的に不利になる可能性がある
  • それでも仕事そのものの楽しさや、人をマネジメントする満足感のためにEMの役割を続けるケースもある
  • 現時点では管理職への転換より技術中心のキャリアを維持するほうが有利な時期であり、慎重な判断が必要

1. 技術から離れるには良くない時期

  • この1年、技術変化のスピードは非常に速く、仕事の進め方のほぼあらゆる部分が変わっている
    • AIコーディングツールや新しいプロジェクトの登場が相次ぎ、OpenClawのような新しいプロジェクトも急速に広がっている
  • Claude Codeの開発者が、なぜAnthropicに今もソフトウェアエンジニアが必要なのかを説明するツイートが話題になったことがある
    > 誰かがClaudeに指示を出し、顧客とコミュニケーションし、他チームと協力し、次に何を開発するかを決めなければなりません。エンジニアリングは変化しており、優れたエンジニアはこれまで以上に重要です。
  • このような変化の中で、マネージャーは実験と学習に使える時間が不足しがちで、特に6人以上のチームを担当するとさらに難しくなる
  • 技術を直接扱いながら新しいアイデアを試したいエンジニアにとって、管理職へ転換すると時間が絶対的に足りなくなる

2. 管理職昇進構造の競争激化

  • 従来のEMキャリアパスは EM → Senior EM → Director → VP だったが、この2年で企業は組織構造をフラット化する傾向にある
  • AmazonはIC対マネージャー比率を15%高め、他の企業もこれに追随しているため、上位職が減っている
  • DirectorやVPのポジションは減り、Senior EMの役職も減少しており、有能なEMでも何年も同じ位置にとどまる可能性がある
  • フラット化した企業で解雇された経験豊富なリーダーたちとも競争しなければならず、Senior EM以上の競争の強さは以前よりはるかに高い
  • その結果、社内昇進の機会は減少し、より多くの人数を管理しなければ昇進は難しく、同じチーム内では担当範囲を広げることしかできない
  • 一方で、IC(Individual Contributor) として優れた技術力を発揮すれば、より速く成長できる可能性がある

3. 報酬面での不利さ

  • EMへの昇進時に給与アップを提示されても、他のスタートアップのSenior/Staff Engineerオファーより総報酬が低いことがある
    • 同じ会社内ではEMのほうがSenior Engineerより報酬が高くても、業界全体で比べるとStaff Engineerのほうが高報酬になる
  • これはそうしたエンジニアに対する需要が非常に大きく、今後も続くためである
  • ICトラックを維持しながらStaff Engineerへ成長した後に転職すれば、EM昇進と比べて約20〜30%高い報酬を得られる可能性がある

4. それでもEMであり続ける理由

  • ハンズオンを維持する経験豊富なEMについては楽観的であり、長年積み上げたマネジメントスキルは今もなお有効である
    • 依然として価値のある役割を果たすことができ、技術的な鋭さが多少落ちても、管理経験が強みとして働く
  • 個人的には仕事に対する楽しさと満足感が大きいため、引き続きEMとして働いている
  • ただし2026年時点では、ICの道のほうがより合理的な選択だと考えている

5. 結論と助言

  • シニアエンジニアであれば、当面は管理職への転換を見送るのが望ましく、今後2〜3年は状況を見守ることを勧める
  • ただし、内発的な動機と情熱が明確であれば挑戦は可能であり、単なる報酬や昇進の論理だけで判断すべきではない

3件のコメント

 
coremaker 2026-03-05

これに共感するマネージャーの方は多そうですね。

 
kalista22 2026-03-05

とても共感します

 
GN⁺ 2026-03-04
Hacker Newsの意見
  • 私は「tech」業界では肩書き(title) がほとんど恣意的だと感じている
    「Senior」「Lead」「Principal」「Staff」のような呼称は会社ごとに定義が異なり、実際には組織構造によって意味がまったく変わる
    例えば「Senior Backend Developer」だった時のほうが、「Staff Engineer」だった時より多くの責任を負っていたこともある
    3大陸で、6人のスタートアップから1万人超の大企業まで働いてきたが、肩書きの基準は今でもバラバラだった

    • その通り。肩書きは社内では一貫して使われるべきだが、会社間ではまったく互換性がない
      新人にこれを何度も説明しなければならなかった。「Senior Engineer」というタイトルのために何万ドルもの差額を捨てようとしていた人もいた
      採用のときは、MicrosoftやGoogleのように公開されたレベリングシステムがある会社の出身でない限り、肩書きはほぼ無視する
      「Principal Staff Engineer」や「CTO」という肩書きの人が、実際には平均的な会社のシニア水準にも達していないこともあった
      逆に「Senior Software Engineer」なのにチームの誰よりも優秀な人もいた
    • ほとんどの会社は報酬と評価のために独自のレベル構造を持っている
      一般的にはL1のインターンからL10のFellowまで続く構造で、L5(Senior)がほとんどのエンジニアにとって到達可能な「終着点」の役割を果たす
      L6以上は特別な影響力とプロダクト・ビジネスインパクトを求められる
      L9〜L10は業界全体に影響を与えた人たちで、例えばMapReduceやKubernetesを作ったレベルだ
    • IC(Individual Contributor)にとって肩書きは報酬と評価に直結する
      大企業ではStaffとSeniorでRSUの差が大きいが、スタートアップではほとんど意味がない
      評価シーズンには肩書きによって評価基準が変わるが、実際にはマネージャーがカーブに合わせるために点数を調整する
      VP、Director、Cレベルまで行くと組織間の比較が可能になり、政治的要素が大きくなる
    • 肩書きは外部に対して自分を説明する最上位ビット
      1社に長くいるなら重要ではないが、キャリア移動を考えるなら交渉ポイントになる
      私は「Senior DevSecOps Engineer」というタイトルを自分で交渉した
      このタイトルのおかげで、自分がセキュリティパイプライン管理には強いが、機械学習モデルのチューニングには弱いことを明確に示せる
    • 以前は機械・電気ベースのシステムエンジニアとして働いていたが、ソフトウェア業界が同じ肩書きを持っていって混乱が生じた
      私の役割は実際のハードウェアや空圧、電流を扱う仕事だったのに、今では検索するとUnixやPython関連の職務ばかり出てくる
      「Unix Server Engineer」のような、もっと具体的な名前を使ってくれていたらよかったと思う
  • エンジニアリングマネージャーになりたいなら、単なる次のステップだと考えず、長期的にどんな役割を望むのかを考えるべきだ
    マネージャーは技術より人の管理とHRが中心で、Director以上になると会議と情報整理にほとんどの時間を使う
    多くの開発者がPeter Principle(Wikiリンク)の犠牲になっている
    開発者のままでいることもまったく問題ない。好きな仕事をしながら続けられるなら、それだけでもう成功だ

    • 私のマネージャーは評価シーズン以外はほとんど何もしていないのに、私より年収が高く、チームの成果を全部自分の手柄にしている
      傍から見るとかなり楽な仕事に見える
    • Peter Principleを初めて知ったが、1969年の概念が今でも有効だというのは驚きだ
    • ICの立場から見ると、人の管理がその役割の最も明確な部分なのに、それを準備しないというのが理解できない
      私は休暇承認やSlackで誰かを叱るような仕事は絶対にしたくない
    • 私の経験ではPeter PrincipleよりDilbert Principle(Wikiリンク)のほうが現実的だ
      Appleでマネージャーに昇進した人たちが書いたひどいコードをデバッグしていて、彼らはそもそも最初から優秀だったことがないと気づいた
      上級管理職は実際の仕事よりも重要そうに見せる能力が重要だ
      会議を設定してスライドを作ることが、実力のように見える構造だ
    • みんな「エンジニアリング経験のあるマネージャー」を欲しがるが、肝心のそのマネージャーになりたがる人はいない
  • 業界別に分けなければ、こうした分析には意味がない
    「Engineering Manager」はあまりにも一般的な肩書きで、スタートアップ、ビッグテック、エンタープライズでそれぞれ違う
    エンタープライズではStaff Engineerはほとんどおらず、普通はSWE1/2/3 → Tech Lead → Architectという構造だ
    一方でテック企業はSWE1/2/3 → Staff → Principalという構造を持つ
    マネージャーはしばしば終着点の役割になり、20年間同じポジションに留まる場合も多い
    結局、マネージャーになるのはキャリア転換

    • ただしStaff以上はEMと報酬水準が近く、むしろ転職の自由度が高い
      EMは責任が重く労働時間も長いが、給与差はごくわずかだ
      プロジェクトが遅れると営業チームのスケープゴートにされやすく、雇用安定性も低い
  • 最近1年間の変化が「ものすごい」という主張には同意しない
    私の業務は数年前とほとんど同じで、変化は漸進的
    AIツールの発展速度が速いというのは予測であって、すでに必須だという証拠ではない

    • 「予測」とはどういう意味なのかわからない。単にAIツールを使ったことがないということか?
      過大評価されていたとしても生産性向上があるなら、すでにワークフローの変化は起きているということだ
    • その人は業界経験が5年未満なのだと思う
      学校を出てすぐ来た人はまだ学ぶことが多いので、変化を大きく感じやすい
    • AIツールに関する言説は矛盾している
      「誰でも簡単に使える」と言いながら、「今使わないと取り残される」とも言う
      どうせすぐもっと良くなるなら、今の不完全なバージョンを学ぶのは無駄に感じる
  • マネージャーへの転向については議論がある
    技術的能力より人の管理と政治力が重要で、それが向いていないならマネージャーになるべきではない

    • しかしマネージャーになると転職機会が減り、解雇リスクも高くなる
      EMは代替しやすく、プロジェクト失敗時にはスケープゴートにされやすい
      一方ICは責任を分散させることができる
  • 私はICからマネージャーに転向したが、この2つのトラックは完全に異なる
    VPはDistinguished Engineerに近いレベルだが、DEは業界で名声を得なければならない
    結局、金や昇進より何が好きかが基準であるべきだ
    AIが単純業務を代替する時代には、情熱を持つ人だけが残るだろう

  • ほとんどの会社ではマネージャーは**「内輪」**と見なされ、技術者は単なる労働者として扱われる
    マネージャーはより多くの情報と会議へのアクセス権を通じて影響力を得る

    • だが実際にはラインマネージャーが最も簡単に置き換え可能なポジションだ
      私は主要プロジェクトを担当するとき、CTOに直接レポートするよう求めた
    • こうした構造を理解していないなら、マネージャーとしての資質が足りないということだ
      会社の**「マフィア構造」**に入るようなものだ
    • マネージャーは深い技術知識が不足している代わりに、政治力と可視性で影響力を確保する
  • 報酬比較は同一条件で行うべきだ
    私はGoogleや複数の会社でStaff EngineerとEMの両方を経験した
    卓越したICなら一部の会社で100万ドル以上を得られるし、
    そうでないならマネージャーに進むほうがより良い選択かもしれない

  • 「エンジニアとマネージャーは同等のトラックだ」という話は神話に近い
    実際にはマネージャートラックのほうがはるかに昇進機会と可視性が多い
    大きな組織では内部ネットワークへのアクセス性が高く、有利だ
    しかも実力のないマネージャーがエンジニアより長く生き残ることも多い

  • 「何をするな」というタイプの助言は危険だ
    「デトロイトに行くな」「学界に行くな」「Google株を買うな」のような話は
    結局は状況によって価値が変わる市場の原理と同じだ
    人生は結局過小評価された価値を見つけるゲームだ
    みんなが嫌がる選択が、自分にとっては最高の機会になることもある