この記事は ひまプロ談話室 Advent Calendar 2025 の 7日目の記事です！
はじめに
私はSCRUMで自社サービスを開発しているチームにて、フロントエンドやモバイルのエンジニアをやっています。
2025年度の初め、私は30代前半にして「リーダー層」（管理職層）への昇格辞令を受け取りました。
エンジニアとしてのキャリアを積み重ね、評価された結果としての昇格。
普通なら自信を持って喜ぶべき場面なのかもしれません。
しかし、その日の日記（Daily Note）に私が残した言葉は、喜びとは程遠いものでした。
ついに昇格。（中略）
入社した時はあんなに上に見えた立場に実際になってしまうとは怖い。まあまあプレッシャーあるなあ。
しかも、一緒に上がったのがあのしっかりしてそうな、むしろ既に管理職層になっていると思っていたAさん。（中略）
元からリーダーの風格があったので、自分が並んでいるのが違和感。自分は大丈夫かなと余計にプレッシャーを感じたな…
— 当時のDaily Noteより
この記事では、そんな風に昇格をプレッシャーに感じ、「自分はエンジニアとしてどうキャリアを歩んでいけばいいのか」「コードを書く割合を下げないといけないのか」と葛藤していた当時の私が、どのようにして自分なりのリーダー像を見つけていったのか。その迷いと生存戦略の記録を共有したいと思います。
同じ様に、「技術からは離れたくないけれど、キャリアアップもしなければいけない」というジレンマに悩む方の参考になれば幸いです。
何がそんなに怖かったのか 〜ロールモデル不在の暗闇〜
当時の私を支配していたのは、いわゆるインポスター症候群（自分ごときが、という不安）だけではありませんでした。
もっと根深かったのは、 「憧れのロールモデルがいない」 という孤独感でした。
私の周りにいた既存のマネージャーの方々は、ピープルマネジメントや組織調整に長けた、素晴らしい「管理者」ばかりでした。
しかし、私が心の奥底でなりたいと思っていたのは、 「現場でバリバリと技術的な意思決定に関わりながら、かつチームをリードする」 というスタイルでした。
「Aさん」のように、最初から管理者の風格がある人と自分を比べては、「自分にはあんな振る舞いはできない」と落ち込んでいました。
「リーダーになる＝コードを捨てて、彼らのような『従来型の管理者』にならなければいけない」 と思い込み、それが自分のやりたいこととあまりにもかけ離れているように感じて、不安が大きくなっていたのです。
実は昇格前から、私は無意識に限界を感じていました。
何もかも自分が抱え込まなきゃいけない気がしてしまっている。
- 技術的な面でリードする人が必要で、自分が担わなきゃ
- タスクのスピード・量でもリードする人が必要で、自分が担わなきゃ
- PMやPOへの説明を担わなきゃ
— 2024年のDaily Noteより
技術も管理も両立しようとして、既にパンク寸前。
昇格は、そんな私に対して「もう中途半端は許されないぞ。さあ、技術を捨てるのか？」という最後通告のように思えてしまっていたのです。
転機になった「スタッフエンジニア」という概念
迷いまくっていた私を救ったのは、あるシニアエンジニアとの雑談と、そこから深掘りした「スタッフエンジニア」や「暗黙のリーダー」という概念との出会いでした。
私は当時のノートに、以下のような気づきをメモしています。
「AIでコーディングスキル単体の価値はどうしても下がるので、グランドデザインを描けるようになるべき」
ポイントは、現場感を失わずに、チームを一歩先に進めるための「後ろ盾」になること
— 当時の思考ノートより
ここで私は、一つの重要な事実に気づきました。
「リーダーになること＝コードを捨ててピープルマネジメント専業になること」だけが正解ではない、ということです。
私が求めていたのは、既存の「管理者」のコピーになることではありませんでした。
現場の技術課題に深く関わりながら、その知見を持ってチームを導く存在（Tech Lead / Staff Engineer）。これこそが、私が目指すべきスタイルだったのです。
「前例（ロールモデル）がいないなら、自分がその例になればいい」。
そう考え方が切り替わったとき、今まで感じていた「組織とのミスマッチ」への恐怖が、「新しい価値を提供するチャンス」に見え始めました。
私が見つけた「泥臭いオーナーシップ」と「技術的貢献」
そこからの私は、無理に「理想の管理者」に近づこうとするのをやめ、「自分ができる貢献」 に集中し始めました。
具体的には、以下の2つの軸でチームを支えるスタイルです。
1. 「制約」を正しく認識し、壊す力（泥臭いオーナーシップ）
ピープルマネジメントの流儀では先輩たちに敵わなくても、「現場の制約を正しく認識してダイナミックに動く」 ことはできます。
メンバーは「これは他部署の領域だから」「これはルールだから」と、制約を絶対的な壁だと感じがちです。
でも、リーダーの視座で見れば、それはただの「調整可能な条件」であることが多いものです。
「話せばわかるよ」「ルールは変えられるよ」と、後輩たちが感じている壁を壊してあげること。
誰もやりたがらない他部署との調整や、プレッシャーのかかる交渉を率先して引き受けること。
これが、私が現場で見つけた最大の「泥臭いオーナーシップ」でした。
2. 全体を見通す技術的リーダーシップ（グランドデザイン）
そしてもう一つ、私が諦めかけていた「技術」での貢献です。
単に自分のタスクとしてコードを書くだけでなく、「システム全体の整合性を取る設計判断」 や 「難易度の高いアーキテクチャの意思決定」 を主導すること。
チーム全体の生産性を加速するツールを検討し導入すること。
AI時代において、コードを書く速度そのものよりも、「何を作るべきか」「どう設計すれば破綻しないか」「どうすれば組織の生産性を上げられるか」というグランドデザインを描く力。
これこそが、技術を自らが使うことを大事にしてきた私だからこそ提供できる、独自の価値でした。
まとめ
最後に、かつての私と同じように「コードを捨てなきゃいけないのか？」と不安の中にいる方へ、今の私から伝えたいことをまとめておきます。
- リーダーの形は一つではない：周りの「完成された管理者」と自分を比べる必要はありません
- 技術は捨てなくていい：昇格は技術を取り上げる辞令ではなく、技術を使ってより広い範囲（チームや組織）に影響を与えるための 「許可証」 です
- ロールモデルがいなければ作る：あなたのその迷いこそが、次の世代の新しいロールモデルを作る原動力になります
あの日、昇格辞令を見て震えていた自分に、今ならこう声をかけられる気がします。
「大丈夫。泥臭くチームを守りながら、技術で未来を示す。そのあなたなりのリーダーシップを、必要としてくれる仲間が必ずいるから」と。