誰も教えてくれなかった、エンジニアからマネージャーになるということ〜現場と理想のあいだで僕が壊れかけた日々と、その先の景色〜

🎯 本作品は「note創作大賞2025」#ビジネス部門 応募作品です。

「誰も教えてくれなかった、エンジニアからマネージャーになるということ」

技術者として順調にキャリアを歩んできた私が、初めてマネージャーに抜擢されたとき。
「昇進」という甘い期待とは裏腹に、待っていたのは戸惑いと孤独と、“正解のない苦しみ”でした。

これは、そんな“エンジニアからマネージャーへの転換期”をリアルに綴った実録です。

はじめに

2006年、僕はエンジニアとして社会に出た。
同期に負けたくない。その一心で、がむしゃらに働いた。

技術がすべてだった。
速く、正確に、美しく。
誰よりもコードを書き、誰よりも評価され、昇進の話もすぐにやってきた。

「チームを任せたい」と言われたとき、少し誇らしかった。
頑張りが、ちゃんと認められたんだと思った。

だけどそれは、地獄の始まりだった。

自信に満ちていた自分が、なぜか無力になっていく。
これまで通用してきた“すべて”が、マネジメントの世界では何の役にも立たなかった。

この連載は、そんな僕が経験した、
エンジニアからマネージャーへの“転職”物語である。

📚 第1章：マネージャーは“昇進”ではなく“転職”だった

「マネージャーになってもらいたい」
上司からそう言われたとき、少しだけうれしかった。
自分の努力が認められたような気がしたし、役職がつくというのは、やはりちょっとした“ステータス”だと思ったからだ。

だけどそれは、「職種が変わる」という意味でもあった。
実際にその役目が始まってみると、私はようやく気づくことになる。
マネージャーという仕事は、エンジニアとしてキャリアを積んできた人間にとって、まるで別の職業だということに。

◆ 本を読めば、うまくいくと思っていた

就任当初、私は責任感に燃えていた。
「ちゃんとやらなければ」「成果を出さなければ」
その思いで、ありとあらゆるビジネス書を読み漁った。

リーダーシップ論、マネジメントの黄金法則、1on1の技術、心理的安全性、評価制度の正しい運用。
理屈はわかった。頭でも理解できた。

でも、現実は違った。

生意気な新人、言うことを聞かない中堅、割り振った仕事に文句を言うベテラン。
「なんでこれをやらないといけないんですか？」
そう言われるたび、私は説明し、説得し、納得させようと試みた。

だが思ったように人は動かない。
教科書通りのマネジメントは、人間の感情と矛盾した。

◆ 仕事を「渡す」という苦しみ

マネージャーの仕事は、コミュニケーションがすべてだ。
人に仕事を割り振り、進捗を見て、課題を拾い、方向性を修正する。

でもそれが、恐ろしいほどストレスだった。

私は、自分がやるべきことは自分でやるタイプだった。
与えられた仕事に不満を言ったことなんて一度もない。

だからこそ、他人に仕事を「渡す」という行為がこんなにも苦しいとは思わなかった。

何をどこまで任せるか。どう伝えるか。どうフォローするか。
毎回、神経をすり減らしていた。

◆ 自分の時間は「定時後」にしかなかった

部下に仕事を振る。
チームの問題を処理する。
会議に出る。資料を読む。報告を書く。

そのすべてを終えてから、自分の本来の仕事に取りかかるのは、いつも定時を過ぎたあとだった。

エンジニアとしてのスキルを磨く時間も、マネージャーとしての反省をする時間も、全部「残業時間」でやるしかなかった。

責任だけは増えていく。
なのに、給料はそれほど変わらなかった。

◆ 「うれしい昇進」は、甘い幻想だった

私は気づいた。
マネージャーとは“昇進”じゃない。職種が変わることなのだ。

必要とされるスキルも、見ている景色も、価値観も、すべてが違う。
コードが書けることも、効率的に作れることも、マネージャーにはほとんど通用しない。

だけど、誰もそれを教えてくれない。

次章の紹介

プレイヤーからマネージャーに転身したとき、誰もがこのギャップに戸惑う。
私も、正直に言って「何度もやめたくなった」。
でも、この違和感と葛藤の中にこそ、本当の成長のヒントがあった。

次の章では、「自分でやった方が早い」という呪いと、どう向き合えばよかったのかを話したい。

📚 第2章：「“自分でやった方が早い”という呪い」

◆ 「それ、俺がやったほうが早いんだけどな」

マネージャーになってから、何度も頭に浮かんだフレーズがある。
「それ、俺がやったほうが早いんだけどな」——。

誰かにタスクを振ったものの、動きが遅い。
説明しても、意図が伝わらない。
やってみた結果、品質もイマイチ。

だったら自分でやった方が、速くて正確でストレスもない。
そう思うたび、手が伸びそうになる。

でも、それをやってしまうとチームが育たない。

◆ 任せることは「手放す」ことじゃない

マネジメントの本には、こう書いてある。
「信じて任せましょう」と。

でも、任せるってそんなに簡単なことじゃない。
相手の力量を見極めて、タスクを分解して、リスクを許容して、進捗を見守って、必要ならフォローする。

むしろ、自分でやるより数倍エネルギーを使う。
なのに、感謝もされないし、成果も自分のものにならない。

しかも、相手の行動や結果には、責任だけがこちらにのしかかってくる。

◆ やったつもり、伝えたつもり、育てたつもり

私は、何度も「ちゃんと任せてる」と思っていた。
でも実際には、細かく口を出したり、途中で巻き取ったり、指示が曖昧だったりした。

そのせいで、部下はこう思っていたらしい。
「結局、全部自分でやりたいんでしょ？」

信頼していたつもりだった。
でも、それは“自分が安心するやり方”でしかなかった。

◆ チームを“信じる”ことの怖さ

任せるって、信じることだ。
でも、それは「絶対できる」と信じることじゃない。

失敗もある。遠回りもある。
でもそれを一緒に受け入れることが、信頼なんだと、ようやくわかってきた。

マネージャーは「自分の正しさ」でチームを動かしてはいけない。
チームが自分で考え、動き、学ぶ時間と空間を確保することこそが、仕事なのだ。

◆ 「早くて正確」より「遅くても育つ」を選べるか

マネージャーの価値は「自分が何をしたか」ではなく、
「自分がいなくても、チームが動くようになるか」にかかっている。

だから、多少の遠回りでもいい。
ムダな時間や失敗にも、意味がある。

「自分でやったほうが早い」と思ったとき、
私はこう自分に言い聞かせる。

「いや、それは“今だけの話”だ」と。

🔗 次章予告

指示したはずなのに、やってくれない。
伝えたと思ったのに、全然伝わっていなかった。
——なぜ、そんなすれ違いが起きるのか？

次章では、“伝える力”が武器になるまでの試行錯誤を綴ります。

📚 第3章：なぜ、伝えたのに伝わらないのか？

◆ 「言ったよね？」は、言ってないと同じ

マネージャーになって最初に直面した壁、それが“伝わらない問題”だった。
ちゃんと説明したはずなのに、なぜか意図通りに動いてくれない。
「いや、言ったよね？」と心の中でつぶやいて、イライラしたこともある。

でもある時、気づいてしまった。

「伝えたつもり」なんて、伝えてないのと同じだと。

◆ 指示＝命令じゃない。「理解と納得」がセットで必要

部下にタスクを依頼するとき、私は最初こう考えていた。
「やるべきことが決まっていて、それを割り振るだけ」だと。

でも実際は、タスクには背景、目的、優先度、意義がある。
ただ「これお願い」では、人は動かない。
特に、経験のあるメンバーほど、「なぜ自分がこれを？」という意識がある。

だから必要なのは、納得感のある指示だった。
納得感とは、「このタスクがなぜ必要なのか」「どう進めてほしいのか」「あなたがやる意味」までセットで伝えること。

◆ 「伝える」と「伝わる」は、まったく別の技術

プレイヤーだった頃の私は、「言えば伝わる」と思っていた。
でもマネージャーになって気づいたのは、“伝える”には技術が要るということだ。

相手の立場、知識、感情をふまえた上で、どう言うか、何から言うか、何を省くかを考える必要がある。

曖昧な言葉、抽象的な目的、急ぎの雰囲気。
そういった“ノイズ”が、伝わらなさの原因になる。

◆ 「何度も言ってるのに…」は、あなたの責任かもしれない

繰り返しても伝わらない。
そんなとき、昔は「相手の理解力の問題だ」と思っていた。

でも今ならわかる。
それはたぶん、伝え方を変えていなかった自分のせいだ。

理解されない伝え方を、何度繰り返しても無意味なのだ。

◆ 伝えるべきは「正解」ではなく「意図と期待」

マネージャーが伝えるべきなのは、「正解」じゃない。
目的・意図・期待値だ。

・このタスクの背景にはどんな課題があるのか？
・どういう状態になれば“完了”なのか？
・なぜあなたに頼むのか？

これらが共有されていれば、途中で迷っても、自分で考えて進めるチームになる。

◆ 伝える力は、最も重要なマネジメントスキルだった

技術でも、戦略でも、KPIでもない。
マネージャーにとって最も大事なのは、「人に思いを届ける力」だった。

「伝える」ことを雑にしたとき、チームは必ず止まる。
「伝える」ことを丁寧にしたとき、チームは自走し始める。

それを知ったとき、ようやく私は「リーダーっぽくなれた気がした」のだった。

🔗 次章予告

これまで“評価される側”だった自分が、
人の働きを“評価する側”になったとき、世界の見え方が一変した——。

次章では、評価の苦悩と、その先で見つけた「信頼の正体」について語ります。

📚 第4章：「“評価する側”に立ったとき、すべてが変わった」

◆ これまで、ずっと「評価される側」だった

エンジニアとしてのキャリアの前半、私はずっと「評価される側」だった。
どれだけコードを書いたか。どれだけ早く仕上げたか。
自分のアウトプットの質と量で、評価は決まると思っていた。

そして、頑張れば報われた。
深夜までコードを書き、知識を詰め込み、レビューもテストも完璧にこなす。
その努力が数字になり、言葉になって返ってきた。

でもある日から、私は「評価する側」になった。

◆ 評価は“点数付け”ではなかった

最初は単純に思っていた。
「仕事ができている人を正しく評価するだけ」だと。

でも現実は違った。
成果だけを見ても、チームに与える影響がバラバラだった。

・文句は言うけど結果を出す人
・目立たないけど他人を助けて支えている人
・アウトプットは多いが、周囲との協調性に欠ける人

評価とは、数字では見えない“関係性と信頼”のマネジメントだった。

◆ フィードバックの一言で、人は壊れる

「君の評価はBです」
そう伝えたとき、相手の目が少し曇った。

それまで頑張っていた姿を見ていたからこそ、私の心も痛んだ。
「本当はもう少しうまく伝えられたはずだ」
そう思っても、後の祭りだった。

マネージャーの言葉には、“正解以上の意味”が宿る。
何を評価し、何をスルーしたか。
それが、相手のモチベーションを大きく左右する。

◆ 自分の“物差し”では測れない

評価が難しいのは、「自分ならこうする」が通用しないこと。

自分のやり方、自分の基準、自分の価値観。
それで他人をジャッジすれば、必ずどこかでズレる。

相手の背景、得意・不得意、努力の方向性。
それをちゃんと見ようとしなければ、正しく評価などできない。

◆ 評価制度が完璧でも、評価は“人間関係”で決まる

いくら制度が整っていても、
評価の場面には人間の感情と信頼関係が介在する。

「あの人にどう思われているか」
「ちゃんと見てくれているか」
「評価の理由を納得できるか」

それがすべてだ。

◆ 評価は「信頼を可視化する行為」だった

マネージャーの評価とは、過去の結果を整理することではない。
チームメンバーの未来に、どんな可能性を見ているかを示す行為だ。

だからこそ、マネージャーが見ている世界の“軸”が問われる。
どんな姿勢を評価するのか。
何を見逃さないのか。
どう伝えるのか。

すべてが、その人の“器”を映し出す。

私はようやくそれを知った。
評価される側の頃より、ずっと責任が重く、ずっと孤独なポジションだった。

でも同時に、そこには人の成長を支えるやりがいがあった。

🔗 次章予告

つい口を出したくなる。
完璧を目指して、全部自分で整えようとする。
でもその結果、チームは崩れていった——。

次章では、「任せられない自分」がチームを苦しめた実体験を語ります。

📚 第5章：「“完璧主義”のマネージャーが、チームを壊した話」

◆ 「ちゃんとやらないと」が、すべての始まりだった

マネージャーになってから、私はずっと「ちゃんとやらないと」と思っていた。
プロジェクトを成功させる。納期を守る。ミスを防ぐ。
そして、チームに迷惑をかけないようにする。

その意識が、気づかないうちに“完璧主義”になっていた。

設計にも、レビューにも、スケジュールにも口を出す。
自分の理想通りに進めようとして、どんどん手を出していった。

でも、チームの空気は、徐々に冷たくなっていった。

◆ 「全部自分でやる人」が、リーダーになるとこうなる

プレイヤー時代、私は“全部自分でやるタイプ”だった。
自分で調べ、自分で手を動かし、遅れがあれば巻き取る。

成果が欲しければ、自分が動けばいい。
その方が早いし、品質も保てると思っていた。

でも、リーダーになってもそのままのやり方を続けると、
チームは機能しなくなる。

◆ メンバーが「指示待ち」になっていった

気がつくと、メンバーは何も言わなくなっていた。
自分から提案もしないし、判断もしない。
常に「これ、どうしたらいいですか？」と聞いてくるようになった。

「なぜだろう」と思った。
でもそれは、私自身が“考える余地”を奪っていたからだった。

最初から正解を言う。ダメ出しをする。先回りして直す。

それでは、誰も自分の頭で考えようとしなくなるのは当然だった。

◆ 「任せる」の本当の意味を知らなかった

“任せる”というのは、ただ仕事を渡すことじゃない。
うまくいくまでを信じて、見守り、支えることだ。

多少効率が悪くても、遠回りでも、
自分で考えて動く経験を積ませないと、人は成長しない。

わかっていたつもりだった。
でも、自分が“失敗を許容する勇気”を持っていなかったのだ。

◆ 完璧なプロジェクトより、大事なことがあった

あのとき、私はプロジェクトの成功ばかりを見ていた。
でも本当に大切だったのは、
「チームがどう育ったか」「次にどう動けるか」だった。

プロジェクトが終わっても、チームは残る。
その関係性と空気感が崩れていたら、次にはつながらない。

完璧に仕上げたつもりの仕事は、
「このチームでもう一度働きたい」と思える空気を、作れていなかった。

◆ 「マネージャーの完璧主義」は、チームを壊す

完璧を求める気持ちは、悪くない。
でも、それを一人で背負い込むと、チームは息ができなくなる。

マネージャーの仕事は、チームが“自分たちで進める場”を整えることだ。
そのためには、ときに不完全さを受け入れ、任せて待つ覚悟が必要だ。

私はそのことを、チームの沈黙から学んだ。

🔗 次章予告

挫折、孤独、葛藤。それでも続けてきたマネージャーという仕事。
その先に、初めて“報われた”と感じた瞬間があった——。

次章では、マネージャーという役割の“やりがい”と“希望”について綴ります。

📚 第6章：それでもマネージャーになってよかったと思えた日

◆ 辞めたくなったことは、何度もある

正直に言えば、マネージャーという仕事は、何度も辞めたくなった。
自分の時間がなくなる。
頑張っても評価されない。
部下との距離感に悩み、孤独にもなる。

「なんで自分がこんなに苦しまなきゃいけないんだろう」
そう思った夜も、一度や二度じゃなかった。

でも今、振り返って思う。

それでも、この役割を引き受けてよかったと。

◆ チームが“自走”した瞬間

ある日、私はふと気づいた。
チームが、自分の指示なしで、動いていたことに。

朝、Slackを見たら、誰かが課題を投稿していて、
別の誰かがそれに返信して、もう一人が「俺やります」と名乗り出ていた。

私が口を出す前に、問題が見つかり、共有され、解決に向かっていた。

その瞬間、なぜか胸が熱くなった。

「やっと、ここまで来たんだ」と。

◆ 部下の成長が、何よりもうれしかった

昔は、自分が目立ちたかった。
成果を出して、名前が残って、評価されることがモチベーションだった。

でも今は違う。
誰かが成長して、「これ、自分でやってみました」と見せてくれると、心から嬉しい。
任せてよかった、支えてよかったと、自然に思える。

それが、マネージャーとしての最大の報酬だ。

◆ 「あなたがマネージャーでよかったです」

あるメンバーが、異動の直前にこんな言葉をくれた。

この言葉は、いまでも胸に残っている。
成果でも報酬でもなく、“人からの言葉”が、マネージャーの心を支えるのだと、初めて知った。

◆ マネージャーは“選ばれた人”じゃない。“変わる覚悟を選んだ人”だ

マネジメントには、正解がない。
全力を尽くしても、報われない日もある。

それでも続けてきたのは、
「チームが変わる瞬間」を、この目で見たかったからだ。

マネージャーは、“偉くなること”じゃない。
“別のルールで戦う”ことでもない。

誰かのために、自分の戦い方を変える覚悟を選んだ人——
それが、マネージャーという役割の本質なのだと思う。

🎬 おわりに

これまでの章で語ってきたのは、すべて、私自身が経験してきたリアルな物語だ。
マネジメントに夢を見ていた私が、現実の中で何度も壁にぶつかり、少しずつ考え方を変えていった記録でもある。

もし、これからマネージャーになるあなたがいるなら、伝えたいことがある。

あなたが不器用でも、完璧じゃなくても大丈夫です。
大事なのは、「変わりながら、やめずに続けること」。

それができれば、いつかきっと、
「マネージャーになってよかった」と思える日が来ます。

📘 最後までお読みいただき、ありがとうございました。

マネージャーという仕事に悩みながらも、
少しずつ歩んできた自分自身の記録を、こうして言葉にできたことをとても嬉しく思います。

このnoteは、「note創作大賞2025｜ビジネス部門」への応募作品でもあります。
もし何か一つでも、あなたの心に残る言葉や気づきがあったなら——

ぜひ、スキ・フォロー・シェアで応援していただけたら励みになります。
言葉が、誰かのキャリアを少しだけ軽くするきっかけになりますように。

📝 今後について

• 書籍化に向けて、さらに内容を深めていく予定です。

• 補足コラムや続編も準備中。フォローしていただけると更新情報が届きます！

どうぞ、あなたのマネジメントの旅が実りあるものになりますように。