中途入社したEM(私)がこの1年で主に何をしたか
はじめに
この記事は Engineering Manager Advent Calendar 2024 23日目の記事です🎅
この投稿が誰かのお役に立てれば幸いです。
3行で自己紹介
エンジニア歴は約 12 年
今の会社に転職して 1 年が経過
現在は VPoE として 35 名程度のエンジニア組織をマネジメント
転職直後にやったこと
1. 前職や今までの経験と比較しすぎない
転職直後の新しい組織では新参者です。
「郷に入っては郷に従え」は言い過ぎですが、一見非効率だったり、これおかしくないか？ということがあっても、実はその組織では最適化されていることもあります。
再現性に掛けるという観点ではよろしくないですが、今の組織で最適化されていることを壊すメリットとデメリットを天秤にかけて判断し、行動すべきだと思います。
ただ、この時点で課題だと感じたことはメモしておきました。
2. 何を求められて自分が採用されたのか立ち返る
私の場合、古くからいた EM が退職するということで、まずはその代わりの人材となってくれというシチュエーションでした。
そのため、いかに組織でハレーションを起こさず、既存 EM から情報を引き出し、引き継げるかというのが目先のミッションでした。
シチュエーションによって異なりますが、ふとした時に立ち返ると軸がブレないので良かったです。
3. 全エンジニアと話す
転職直後は信頼貯金がゼロなのと情報が少ないため、とにかく色んな人と話しました。
当時は業務委託含めてエンジニアが 20 人強でしたが、全員と話してその人が考えていることや感じている課題感などをヒアリングし、1 つのシートにまとめていました。
話を聞くと、〇〇さんがキーマンということがわかったり、特に抑えるべきメンバーなどが自ずと把握できます。
また、初回に関しては自己開示することを意識しました。
4. エンジニア以外の関係者と話す
エンジニア以外の関係者は、例えば PO だったり、デザイナー、マーケター、セールスなどになります。
エンジニアからは組織内の視点でしか課題が抽出できないので、他の関係者から見てエンジニア組織やプロダクトが現状どう写っているのかを、自己紹介も兼ねてヒアリングしました。
5. 課題をまとめて優先順位を付ける
ここまででヒアリングした内容と 1 でメモした内容をまとめて、自分なりに優先順位を付けました。
このタイミングではそれなりに信頼貯金も溜まっていると感じたのと、そろそろ自分の色を出しても良さそうだと判断できたので、優先順位順に改善していきました。
また、このときは私が課題と感じた内容を改善するための是非を判断するような上司がいなかった（CTOやVPoEはいなかった）ので、他の関係者が概ね同意してくれているなら良いと判断し推進しました。
慣れて来てから何をやったか
細かいことは色々やったのですが、私が 1 番感じた課題は、ミドル〜ハイクラスのエンジニアがほぼおらず、業務委託頼みになっているという点でした。
また、中途採用もほぼ行っておらず、新卒採用か業務委託採用のみという状態でした。
そのため、社員は若くて素直で良い人が集まっているが、技術力が少し物足りなかったり、ひと通りコーディングできるようになった後に、どうやって技術力を磨いたら良いか分からないという組織的な課題を抱えていました。
この時点では特に大きな問題は起きていませんでしたが、今後プロダクトが大きくなったり、より高度な技術を求められた際に、開発組織がボトルネックになってしまうだろうと感じました。
そこで、私が取ったアプローチは、中途採用の積極開始と、セグメントされている役割の拡張（育成）の 2 つです。
中途採用の積極開始
優秀なエンジニアはどの会社からも引っ張りだこで、簡単には採用できません。
ただ、それで諦めていたら一生採用できないです。
やったことは、ビズリーチ 1 本足打法だった採用手法を変え、他媒体やエージェントも並行して活用する方針にしました。
結果的に 1 年で、4 名採用できました。
ただ、そのうち 2 名は私のリファラルなので引き続き取り組むことが必要です。
採用は会社やプロダクトの知名度だったり、使用技術やカルチャー、報酬や福利厚生など、様々な要素が絡むので短期的な改善は非常に難しいです。。
セグメントされている役割の拡張（育成）
当時の組織や開発体制がかなり分業体制になっていて、ポテンシャルのある若手エンジニアの業務がとてもセグメントされていました。
具体的には、アプリケーションエンジニアはリリース業務や CI/CD に関われず、クラウドインフラ（AWS）の権限も非常に弱いものしかアタッチされないので、ただコードを書いてプルリクが通れば仕事が終わりだと認識し、どのように自分が書いたコードが世の中にデリバリーされるのかの理解が乏しかったです。
また、ここから更にフロントエンドとバックエンドエンジニアで分かれていました。
このような状況では、自分の担当領域以外に興味を持ちづらく、〇〇を学んでみたいという成長意欲が生まれないと感じました。
分業制自体は否定しないですしメリットもあると思うのですが、組織の規模やケイパビリティを鑑みて適切に取り入れないと成長機会の妨げになると感じます。
そこでまずは、フロントエンドとバックエンドという垣根をなくし、全員フルスタックエンジニアとして取り組んでもらうことにしました。
当然、フロントエンドだけしかできない人、バックエンドだけしかできない人もいるので、個人目標に組み込みつつ徐々に領域を広げてもらうようにしました。
リリースや CI/CD、クラウドインフラに関しては、サブリーダーレベル以上であればアプリケーションエンジニアでも行えるように権限を変更しました。
もちろんリリースミス等のリスクもあるのですが、そういった失敗を重ねないと成長できないと思い決断をしました。
これらにより開発プロセス全体が見通せるようになったので、視野が広がったのではと思います。
変えた結果どうだったのかというと、エンジニアスキルを定量的に可視化することができないので、はっきり良くなったと良い切れないのですが、この 1 年でマネージャーとして 2 名の昇格者を輩出することができました👏
その他のエンジニアも定性的かつ主観的ではありますが、昨年と比べて自信が付いたり会話の語彙が増え、より若手にも任せやすい状態になってきたと感じます。
役割変更以外にも、育成に伴う成長支援や EM としての業務は色々やったのですが、長くなるのでまた来月くらいに書いてみようと思います。