コードを書く時間が減り、後輩の書いたコードの方が新しい技術に詳しい——EMになって半年もすると、多くの人がこの不安にぶつかります。「このまま技術力が落ちて、いざという時に何もできなくなるのでは」という恐れは、EMになった人にほぼ共通する悩みです。この記事では、この不安とどう向き合うかを整理します。
不安の正体は「技術力そのもの」ではないことが多い
よく観察すると、この不安の中身は「コードが書けなくなること」そのものより、「現場からの信頼を失うこと」「自分の市場価値が下がること」への恐れであるケースが多いです。この2つは似ているようで、対処法が異なります。信頼の問題であれば技術力以外の関わり方でも解決できますし、市場価値の問題であれば必ずしも実装力の維持だけが答えではありません。まず自分がどちらを恐れているのかを切り分けることが最初の一歩です。
現場からの信頼は「コードが書けるか」だけで決まらない
プレイヤー時代は「良いコードを書けるか」が信頼の中心でしたが、EMに対してメンバーが求める信頼は別の軸に移ります。
- 技術的な議論で的外れな判断をしないか
- 難しい技術的トレードオフを、自分だけで抱え込ませずに一緒に考えてくれるか
- 実装の大変さを理解した上で、現実的なスケジュールを引いてくれるか
これらは「最新技術を実装できるか」とは別のスキルです。設計レビューや技術的な意思決定に関わり続けることで、実装から離れていても十分に維持できます。
技術との接点を完全に切らないための現実的な方法
とはいえ、技術との接点をゼロにするのは避けたいところです。マネジメント業務と両立できる範囲で、次のような関わり方が現実的です。
- コードレビューには可能な範囲で参加する: 実装せずとも、設計判断の妥当性は把握できる
- 障害対応・技術的な意思決定の場には同席する: 手を動かさなくても、判断のロジックには触れ続けられる
- 小さな検証・PoCだけは自分でやってみる: 大きな機能実装は無理でも、新しい技術の触り心地を確認する時間は確保できる
全部は無理でも、どれか1つでも継続していると、現場との距離感は大きく変わります。
「いつでも現場に戻れる」という安心材料の作り方
市場価値への不安に対しては、資格取得や体系的な学習でカバーする方法もあります。実装量が減っても、知識の棚卸しと更新は自分のペースで継続できます。AWSなど特定領域の資格取得については未経験からAWSエンジニアへのロードマップでも触れていますが、資格は「今も学び続けている」という客観的な証明として機能し、不安の軽減に役立ちます。
むしろEM経験そのものが希少なスキルになる
技術力の維持ばかりに気を取られがちですが、視点を変えると、実装スキルを持ちながらチームマネジメントも経験しているという組み合わせ自体が、キャリア上の強みになります。技術が分かるマネージャーは、現場からもエンジニア採用市場からも評価されやすい立場です。「技術力が落ちること」を恐れるだけでなく、「マネジメント経験を積んでいること」も同時に資産として捉える視点を持つと、不安との付き合い方が変わってきます。
まとめ｜完全維持ではなく「接点を切らない」を目標にする
- 不安の正体が「信頼を失う恐れ」か「市場価値への恐れ」かを切り分ける
- 現場からの信頼は、実装力以外(設計判断・技術的意思決定への関与)でも維持できる
- コードレビュー・障害対応の同席・小さなPoCなど、できる範囲で技術との接点を残す
- EM経験自体もキャリア上の資産であることを忘れない
技術力を「プレイヤー時代と同じ水準で完全維持する」ことを目標にすると、ほぼ確実に苦しくなります。「接点を完全には切らない」という現実的なラインを目標にするのが、長く続けるコツです。
AWS・エンジニアリングマネジメントの実務ネタを発信しています
コメント