エンジニアリングマネージャーという仕事について

今自分が働いている会社ではエンジニアリングマネージャーという肩書で仕事をしています。「ああ、エンジニアのマネジメントをする人ね」ってことなんですが、具体的にどういうことを考えてどういう仕事をやってるかを実際にやってみて分かったこともあるのでまとめておこうと思います。

一応注意としては、「自分はこう考えて仕事してるよ」っていうだけの話で、会社や組織によっては全然違うことを考えたり実行してる人も一杯いると思います。自分の仕事はピープルマネジメントがメインです。

ミッションは「エンジニアチームの生産性を最大化すること」

そもそもエンジニアリングマネージャーって何のために存在してるかというと、エンジニアチームの生産性を最大化するために存在してると思ってます。生産性を上げるためには、各メンバーのモチベーションを高く維持しないといけないし、メンバーのキャリアアップをサポートしないといけないし、メンバーが困ってることがあれば積極的に動いて問題を潰していくことが必要ですね。

重要なのは、「チームの生産性=各メンバーの生産性の合計」ではないということで、いっぱいコード書けるメンバーが集まっていてもコミュニケーションに壁が合ったり心理的安全性がなかったりすると、ナレッジが共有されなかったり属人化したりしてチームとしてはイマイチだったりします。なので、いかにしてチームのコミュニケーションを活性化するかみたいなのは重要視しています。話しやすい席になるようにこまめに席替えしたり、どうでもいい雑談をSlackに投げたりしてます。

一番大事なのは採用

とはいえ、そもそも集まってるメンバーがイケてるメンバーばかりであれば、あまり問題は起こらないのでマネジメントって楽なんですよね。逆にスキルが足りなかったり性格に難があるメンバーがいると、周囲のメンバーが気を使ったりしてストレスを抱えやすいので、マネジメント難易度は異常に上がってしまいます。

なので、結局の所入り口のところでちゃんとフィルターするのが大事だと思っています。スキルはもちろん、チームに入ってもらうイメージが湧くか、一緒に長時間いても楽しいか、みたいなレベルでちゃんと見極める必要があると思っています。

採用については自分は「How Google Works」「WORK RULES」（どちらもGoogleの人事制度や採用について書かれた本）を参考にしていて、個々の面接官の面接スキルにできるだけ依存しないように構造化された選考プロセスを設計しています。そもそも「常に面接の精度が高い人間などいない（だから複数人がちゃんと見ろ）」というのがこれらの本には書かれています。「自分たちはGoogleの人よりは面接が下手クソだろう」という前提のもとに、最低4人で面接する、面接官が一人でもNGを出せば原則不合格とするといったプロセスを導入しました。

今いる会社も他の会社と同じくエンジニアは超不足しているので、自分の工数のほとんどは採用に費やしています。夜はほとんど面談や面接、昼も書類選考、採用広報、採用目的のイベント企画など、マネージャーの最優先タスクと位置づけて採用に集中しています。それでも全然採用できてないので、たまに採用基準を落としてでも採用したくなる誘惑に駆られるときはあるのですが、そこはグッと堪えて厳しく見るようにしています。

エンジニアの評価制度設計

採用以外の仕事だと、評価制度の設計なども仕事になります。今の会社はこれまで半年に一回社長と面談してふんわりと評価と給与が決まっていたところを、ちゃんとした評価制度を導入しようとしています。

よく言われる「プレイヤーとして優秀なエンジニアが昇給していくためには望んでないのにマネジメントにならないといけない」問題の対策として、マネジメント系のキャリアパス以外にもエキスパート系のキャリアパスを定義し、「それぞれのキャリアパスの各グレードってどういう役割が期待されているんだっけ」などと考えて設計しています。とはいえ最近この辺のグレード設計の話はよく聞くので、割と他社では普通のことを普通にやってるだけかもしれません。

ちょうど6~7月が評価の季節だったのでこの頃は評価系の仕事ばっかりしていましたが、今は特に何もやってないです。多分次はQ3の終わり（9月末〜10月頭）にまた評価の仕事で忙しくなると思います。

1on1

最近は多くの会社で実施されていると思うのですが、メンバーとは1on1を隔週で実施しています。1on1の位置付けは「メンバーの抱えている課題の発見」と「成長のための壁打ち相手になること」と定義しています。他社のエンジニアリングマネージャーに推薦された「ヤフーの1on1」という本を会社の経費で購入してもらい、書いてあることを実践しています。

1on1はもう少しテクニックが必要だなと思っている部分で、メンバーが何か課題を感じているけど上手く言語化できないときに、言語化の手助けをできるようになるような問いかけができればもうちょい良くなると思います。メンバーがマネージャーに対して課題を正確に伝えられるかは性格や言語化能力に依存していると思っていて、伝えるのが苦手なメンバーが伝えやすくするコミュニケーション能力があったらなーと思うときがたまにあります。コミュ障には辛い。

悩みは「悩みを言えないこと」？

さて、「マネージャー業やってみてどうなの？」「コード書く仕事に戻りたくない？」とかよく聞かれるのですが、意外に（？）楽しくやれてます。

自分がマネージャーになったときはメンバーの退職があったりしてチームがぐらついてたタイミングだったんですが、その後良いメンバーが入ってくれたりチームのコミュニケーションが良くなり始めたりとチームの生産性が向上してきた実感があります。まー、自分の働きのおかげというより、メンバーが優秀なのに助けられてるだけなんではという気もしていますがｗ

唯一悩みがあるとしたら、何か自分の仕事や会社について違和感を感じたり悩みがあったりしたときに、それをメンバーには共有できないことでしょうか。滅多にないんですが、「自分モチベーション下がってます」「hogeさんがfugaについて不満をためてる」みたいな話をメンバーがマネージャーだからこそ信頼して相談してくれるときもあるので、そういった話は自分とその上司で閉じて解決しようとしています。

一応自分の直の上司としてVP of Productがいるので、何か気になることや頭に来ることがあったらできるだけ早めに共有するようにはしてるんですが、この辺他のエンジニアリングマネージャーがどうしてるのか是非聞かせてほしいです。