EM見習いとして1on1と採用計画見直しを実施して感じたこと

自己紹介/経歴

コミューン株式会社でcommmuneチームのEM(Engineering Manager)見習いをやっているいちろーと言います。
今迄20年間位、ほとんどのキャリアを開発につぎ込んで決ましたが、2022/02のコミューンへの転職を機にEM的な仕事を行なうようになりました。

27歳位まで、とあるSIerの下請け会社の技術サイドのトップをやっており、技術的なマネージャ、アーキテクト、技術チームの評価、メンタリングなどをやっていました。
でも、その会社を辞めた後は、一環してアーキテクト、プログラマーとして物作りを行なっており、それがプライドでありアイデンティティでありました。
というわけで、現在のWeb系でモダンなマネージメント手法に関しては情報をあまり持っておらず、素人の気持ちで職務に当ってます。

このentryで伝えたい事

EMの仕事って意外とフワフワしている部分があるかなと思います。その中で、とりあえず一歩を踏みだしてみたEM見習いがこういう事をやってみて、それなりに成果は出たよという共有が出来れば良いと思っています。

コミューンに入社してEMとして最初に実施したこと

コミューンにEM見習いとして入社した時に自分に対して決めた事として、プロダクトその物より、プロダクトを支えるエンジニアに向き合うという事があります。その為、現状エンジニアが何を考えているのかを把握する為に、とにかく社内資料を読みまくりました。みんなが何を考えているのか、どうしたいのか、何が足りていないのかを吸い上げ、そこからどういうアクションを取るべきかをまず整理しました。

そこから拾えた事として、大きくわけて、

1on1をなんの為に実施するのかブレている
ロードマップとそれを達成する為の採用計画に無理がありそう

という事でした。もちろんそれ以外にも色々ありましたが、それはまた別の機会にblogで書ければと思います。

1on1の実施を再定義し、運用に乗せる

目的

エンジニアメンバーは会社の宝であり、彼らに気持ち良く仕事をしてもらう為には、各々が何を考え、何に不満/不安を持っているかを一早く吸い上げ、対処出来る体制を作る必要がある。それには適切な1on1運用が必要と考えました。

やった事

今迄も1on1は行なわれていましたが、目的等が結構定まってなくて、なんとなくの雑談になっているのかなーという印象があったので、以下3つを行なう場と定義しました。

メンタリング: 1on1で一番大事だと思います。
- 直近ネガティブだった事は相談に乗ったり次週までの宿題を作り解決を促したり、モチベーションが持てなければどうすれば良いのか相談に乗ったり、勉強の方向性を指し示したり、千差万別色々な角度の相談に乗ってます。次にやるべきゲームが見つかりません。とからーめん美味しいなんていうのもあります。
直近1週間のやった作業の僕に対するプレゼン(5分くらいで)
- 評価を行なう際に、一番重要なのは如何に御互いの納得を醸成するかという事だと思います。その為にも、短いサイクルで(忘れないうちに)、自分のやった事をメンターにプレゼンしてもらい、「これだけやったから評価してよ。」の積み重ねの情報を作っておく事が重要と考えます。弊社ですとクォーター毎で評価が行なわれるのですが、3ヶ月やった事を寝かせると何をやったか忘れてしまうので、結構重要だと思っています。
OKRの見直し
- OKRが現在のやっている作業とズレはじめた時にその調整をおこなっています。

また、今迄は、特に話す事が無ければスキップというのが横行していましたが、コミュニケーションが大事なのでよっぽどの事が無い限りスキップは無しとしました。

苦労した事

1on1自体、色々な目的があり、結局なんの為に1on1を行なうのかという一番大きな目的を立てるのに苦労しました。結果的に目的はEMとしてのミッションと重ね、プロダクトその物より、プロダクトを支えるエンジニアに向き合う 為に各メンバーとコミュニケーションを取る事を一番大きな目的としました。

これには、叩き台を僕が作成し、仲間であるManager / ActingManager(弊社のManager見習いをこう呼びます)の力を借りて、組み上げました。
仲間のありがたみをすごく感じました。

成果

この結果、結構強引に1on1の進行方法を変更しましたが、1on1をある程度システマチックにした事により、拾い上げ損ねる情報とかが減った気がします。

たとえば、

自分の能力をもっと伸ばすにはどうしたら良いか?
チームの○○さんと会話のトーン、展開のさせ方が違っていて、上手く会話が噛み合わない。
自分の評価(Rankという概念の評価システムがある)を上げるにはどうしたら良いか。

など、悩んでいる思いをぶつけてくれて、それに対して一定の解を示せ(プライバシーに関係するのでどういう事をしたかはここでは述べません)、ネガティブな考えを追い払う事に成功したと思っています。

採用計画の見直し

目的

弊社の機能開発ロードマップがありますが、それが実現出来るだけの採用計画になっているかを、エンジニアの目線で再確認する必要を感じました。

やった事

既に採用計画は存在していたけど、本当にそれで良いのかを各チームにヒアリングしなおして、調整しなおしました(予算の範囲内で)

苦労した事

基本的に大きく計画を変更する必要は無かったのですが、下記の2点に遭遇しました。

あるチームの枠が考慮されておらず存在しなかった
- チーム毎に何月に何人採用という計画の為、チームの枠が無いのは致命的

なぜ無かったのかを周りからヒアリングし、状況整理をして、CTO, 採用/人事に説明をしました。現状の採用計画と、そもそもその採用計画が作られた時はそのチームの編成があまり考えられていなかった為、抜け落ちた可能性があるとの説明を行ないました。この説明自体の受け入れは意外とすんなりと行なわれましたが、該当チームの必要人数が多かったりで、そこの調整には手間取りました。結局Managerに無理を飲んでもらって、だいぶ人数の少ない編成とさせてもらいました。

ヒアリングした結果、チームが要求している人数が大きくずれていた
- 特に上振れている場合は予算をどこかから調達しなければならない

該当チームのManagerとCTOに採用人数増の相談をさせてもらい、必要ならばという事で、こちらも比較的すんなりと数字が通りました。

本来はこんなに簡単に予算決定後からの変更は効かないと思います。今回の場合、弊社のActing Manager/Managerが比較的状況をわかってくれているので、「無理なんでゴメン」が通ってしまい、そういう意味ではすごく楽をさせてもらいました。彼らもこちらの辛さをわかってくれている、御互い様というチームワークが出ているかなと思います。
毎回、こうすんなりと行く事を当てにして動いては、まずいと思います。ここらへんは気を引き締めて望むべきだと思います。

成果

採用計画をより開発ロードマップを達成するのに必要な、現実的な人員計画に引き直せたと思います。
これにより、

いついつまでにどんな人間を何名採用する必要がある。
今オンスケなのかビハインドしているのかなどが見える化出来る。

が達成され、採用のスケジュールに対して、より緻密に対面出来るようになった事は大きな成果だと思います。

まとめ

最初に述べたように、EMはプロダクトその物より、プロダクトを支えるエンジニアに向き合う 事がミッションかと思っています。
- 1on1
  - 1on1 でメンバーと向き合う事が凄く大事な事だと思い、プライオリティも一番高いと思っています。
  - いかに質の良いメンタリングが行なえ、メンバーを支えられるかがキモになると考えます。
- 採用計画の見直し
  - 開発ロードマップと予算と各チームリーダーとの鬩ぎ合いかなと思います。
  - 今回はチームリーダーが寛容な理解を示してくれたのと、予算的になんとかなったので突破出来ましたが、いつでもそうとは限りません。早め早めの調整が必要だと痛感しました。
「1on1の実施を再定義し、運用に乗せる」でも「採用計画の見直し」でもそうだったのですが、他のManager / ActingManagerにだいぶ助けられています。弊社のValuesの一つに「チーム・コミューン」というのがあるのですが、これが発揮されたシーンでもあったのでは無いかと思っています。