エンジニアはマネジメントに向いてない？迷ったときの判断軸

リーダーやマネージャーを打診されて、返事を保留したままになっていませんか。断れば成長意欲がないと見られそうで、受ければコードを書く時間が減る。周囲のマネージャーが会議と調整に追われる姿を見ていると、自分には無理だと感じる。その一方で、技術だけで何歳まで戦えるのかという不安もある。

この状態で「マネジメント 向いてない」と検索する人が本当に知りたいのは、適性診断の結果ではないはずです。断ってもキャリアが詰まらないのか、受けたら何が起きるのか、後から技術職に戻れるのか。知りたいのはその見通しだと思います。

「マネジメントに向いてない」と感じるのは自然なこと

やったことがない役割に不安を覚えるのは当たり前で、それは適性がないことの証明にはなりません。打診の時点であなたが持っている材料は、周囲のマネージャーを外から見た印象だけです。会議に追われている様子は見えても、その人が何を判断して何に悩んでいるかは見えません。

ENFIは、キャリアに迷うのは能力や才能が足りないせいではないと考えています。自分の経験や強みがまだ書き出されていないだけ、という見方です。打診への返事に迷っているときも同じで、判断に使える材料がまだ手元にそろっていません。

「向いてない」の中身を分けて考える

「向いてない」という言葉には、いくつか違うものが混ざっています。人に指示を出したりプロジェクトを自分で動かしたりすること自体をやりたくない場合と、やってみたい気持ちはあるが自信がない場合では、取るべき行動がまったく違います。

米田は、向いてないと言う人の多くは、実のところ指示を受ける側でいたいだけではないかと話します。ストレスのかかるポジションですから、避けたくなるのは不自然ではありません。ただ、これは適性の話ではなく好みの話です。自分がどちらなのかを区別しておくと、上司への返事の内容も変わってきます。

マネジメントと技術、それぞれの大変さはどこが違う？

マネジメントは成果が自分の手を離れること、技術は学び直しが終わらないことが、それぞれの重さです。どちらが上という話ではなく、負担のかかり方が違います。

マネジメント職は技術力がなくても務まる、という誤解があります。米田は逆だと考えています。技術力のないマネージャーは設計判断ができないので、メンバーの困りごとを解決できません。できるのは予定どおり進んでいるかを確認することだけで、担当エンジニアがセルフマネジメントできていれば、その役割は要らなくなってしまいます。

代表・米田の視点 エンジニアのマネジメント職はウルトラハードモードだと思っています。人を動かすにも技術力がいるからです。技術力のないマネージャーは設計判断ができないので、メンバーの困りごとを解決できません。進捗を確認するだけなら、担当エンジニアがしっかりセルフマネジメントできている現場ではマネジメント職は不要なんです。適性があるかはやってみないと分からない部分もあるので、迷っているならまずはやってみれば、と私は言いたいですね。そこから今の仕事の考え方が洗練されていく部分は、きっとあると思います。

技術を続ける道は「逃げ」なのか

打診を断ること自体はキャリアを止めません。止まるのは、断ったあとに働き方も学ぶ内容も変えない場合です。米田はかねてから、怖いのは何も変わらない5年間だと発信しています。役割の選択でも同じことが言えます。

ただし、技術を続けると決めるなら条件があります。何の専門性で「あの人といえば○○」と言われる状態を目指すのかを、自分で決めることです。米田は、AIに置き換わらない領域の技術があるならその選択もありだが、基本的に技術の部分はAIに置き換わっていくので、あまりおすすめはしないと話します。これからのエンジニアに必要になるのは人間力だ、というのが米田の見立てです。

打診を断るのは構いません。断ったうえで、その後の数年で何を積むのかを決めてください。

向き不向きより先に整理する材料

適性診断ではなく、今持っているもの（Have）と5年後のありたい姿（Be）を書き出し、その差分で決めます。ENFIのBE-DO-HAVE棚卸しは、Have、Be、Doの順に書くワークです。手段から考えないための順番でもあります。

世の中のマネジメント適性チェックは、たいてい今の行動や経験の話で終わります。ENFIが先にBeを置くのは、マネジメントも技術の深掘りも目的ではなく手段だからです。ありたい姿が決まらないまま手段を選ぶと、向いていない気がするという曖昧な不安が残ります。

経験者向けの設問のうち、この迷いに使えるのは次の2つです。Be1はエンジニアとしての専門性、つまり「あの人といえば○○」と言われたい像。Be3は人物像と影響力で、チームや後輩、社会にどんな影響を与えたいかを書きます。Be3に人を育てたい、チームの成果を伸ばしたいという言葉が出てくるなら、マネジメントは手段として合います。Be1のほうが具体的に書けるなら、技術の深掘りが手段になります。

もう1つ、Have2（誇れる成果、乗り越えた課題、チームへの貢献）も書いてみてください。コードレビュー、後輩のフォロー、見積もり、仕様の調整。名前がついていないだけで、マネジメントに近い仕事はすでに手元にあることが多いです。そのときに手応えがあったかどうかは、周囲のマネージャーを外から見た印象よりずっと確かな材料になります。

打診を受ける・断る以外の選択肢

二択ではありません。期間を切って試す、テックリードとして技術寄りで受ける、別部署で経験を積むといった中間があります。ENFIは転職ありきで考えません。残留も異動も役割の再交渉も、同じ並びの選択肢です。

返事をする前に、次の4点を上司に確認しておくと、判断材料がそろいます。

1. 社内のサポート体制。初めての役割を丸投げされないか、相談できる相手や仕組みがあるかを聞きます。米田は、ここを最優先で確認すると話します。プロジェクトがうまくいかなかったときに、自分一人の責任にされる事態を避けるためです。
2. 評価軸。何をもって成果とみなすのか、技術的な貢献はどう評価に入るのか。
3. コードを書く時間の扱い。実装から完全に離れるのか、一定の割合で残せるのか。
4. 任期と見直しのタイミング。合わなかった場合に技術職へ戻る余地があるか。

4つとも、聞いたからといって意欲がないと見られる質問ではありません。むしろ、役割を真面目に引き受けようとしている人の質問です。

今日からできる次の一歩

1つ目は、BE-DO-HAVEのBe1とBe3を1行ずつ書くこと。5年後に「あの人といえば○○」と言われたい専門性と、チームや後輩にどんな影響を与えていたいか。書けなかったほうが、今のあなたにとって考えが足りていない側です。

2つ目は、次の1on1で、社内のサポート体制と評価軸、任期の3点を上司に質問すること。返事はそのあとで構いません。保留していた時間を、材料を集める時間に変えてしまいましょう。