管理職への転身で失敗しないための3つのポイント

管理職は「昇進」ではなく「職種変更」

米クレオックス社で中規模チームのエンジニアリングマネージャーに昇進した筆者は、当初は「成功した」と感じていた。給与アップ、ストックオプション、経営層との近接性──。表面的には確かに昇進だった。

しかし、周囲から「管理職は昇進ではなく、仕事の転換だ」と言われても、エンジニア同士のよくある決まり文句だと軽く考えていた。

実際には、その両方が正しかった。昇進ではあったが、全く異なる仕事への転換でもあったのだ。そして筆者は、その変化に全く備えられていなかった。

優先順位の劇的な変化

新任マネージャーに対する研修は驚くほど少ない。エンジニアは技術力が高く、複雑なシステムを習得することに慣れている。そのため、多くの人が「人を管理する方が簡単だろう」あるいは「単に会議が増えるだけだろう」と考えがちだ。

だが、そのどちらも間違いだった。

確かに会議は増えた。しかし、最も大きく変わったのは、自身の成果の測り方だった。

個人貢献者時代は、自分の成果が目に見えていた。コードを書き、機能をリリースし、バグを修正していた。

管理職になると、成果は間接的なものになった。チームメンバーを通じて発揮されるようになったのだ。

この変化は当惑させるものだった。

間違った安心感：コーディングへの没頭

筆者は元の安心領域に戻った。コーディングを再開し、チームで最も優れたエンジニアであり続けようとした。生産的で測定可能な活動に思えたが、実は間違いだった。

最も優秀なエンジニアを目指すことで、本来の仕事である「チームの支援」を怠っていたのだ。シニアエンジニアの育成、システム的なボトルネックの解消、キャリアパスの構築──。筆者は、支援すべき人々と競争していたのだ。

管理職の本質は「増幅」にある。

成果の再定義：週の始めに問うべき質問

転機となったのは、毎週月曜日に自分自身に問うようになったシンプルな質問だった。

「今週、最もインパクトを与えられることは何か？」

その答えは、しばしばコーディングではなかった。方向性を明確にするドキュメントを作成すること、単一障害点となっているプロセスを修正すること、所有権を再分配して知識の集中を防ぐこと──。筆者は意図的に実装作業から距離を置くようになった。コードをほとんど書かないという決断をしたのだ。

この決断は信頼を生み、システムのギャップを浮き彫りにした。それらのギャップは、コーチング、ドキュメント整備、採用、プロセス改善といった、適切なレベルでの対応が必要だった。

1on1ミーティングの重要性：エンジニアが嫌う理由

多くのエンジニアは1on1ミーティングを苦手とする。形式的な進捗報告に終始したり、気まずい雰囲気になったりするからだ。筆者は隔週で1on1を実施し、戦術的な整合性と人間的なケアのバランスを取った。

ミーティングの冒頭でエンジニアリングの話題を出すことはほとんどなかった。

代わりに、以下のような質問を投げかけた。

• 現在の仕事に満足しているか？
• 成長を感じているか、それとも停滞しているか？
• 今、最もストレスを感じていることは何か？

バーンアウトはJiraチケットには現れない。静かな disengagement（無関心）も同様だ。そうした会話によって、離職の予兆を察知し、業務負荷の再分配、信頼関係の構築が可能になった。

キャリアラダーの重要性：チームの成長を支える

筆者は、チームメンバーにどのような仕事を与えているかをより深く考えるようになった。メンバー一人ひとりがキャリアアップできるような機会を提供することが、管理職の重要な役割だと気づいたのだ。

管理職への転身は、単なる昇進以上のものだ。それは、自身の役割と成果の測り方を根本から見直す機会でもある。エンジニアから管理職への転身を検討している方は、この変化を十分に理解し、準備することが不可欠だ。