この記事は、and factory Advent Calendar 2020 の8日目の記事です。
昨日は@ayatothosさんの図解『実践Terraform』でした。
はじめに
私は、およそ1年ほど前から、iOSチームのエンジニアリングマネージャーをやっています。
何をするべきなのか最初は迷うこともありましたが、徐々に方向が定まってきたかなと思うので、考えや心掛けを書いていきます。
そもそもエンジニアリングマネージャーって何？
マネージャーという言葉どおり、管理する人ということになりますね。
エンジニアリングマネージャーであれば、エンジニアを管理する人ということになるかと思います。
調べてみると、だいたい以下のような項目が挙げられていました。
- ピープルマネジメント
- 環境整備
- 採用
- 評価
わりと人事寄りの仕事が多いように感じました。
でも、エンジニアの何をどう管理すれば良いのか？という点は、モヤモヤしていました。
私なりのマネジメントの考え方
採用に関しては、今までも行っていたので、それは続けていくとして。
ピープルマネジメントや環境整備ってどんなことが出来るんだろう？と考えていたとき、ふと頭に浮かんだことがありました。
それは、管理するというより、サポートをする、という考えのほうがしっくりくるな、ということです。
「ピープルマネジメント」にはマネジメントという言葉が入っているので、マネージャーが主体となって何かをするという風に考えていました。
しかし、実際に行動するのは、メンバー（マネジメントされる側）です。
例えば、ピープルマネジメントですぐに思いつくこととして、キャリアパスをたてるとか、スキルアップの為に勉強するというのが考えられますが、計画をたてた後に行動するのはメンバーです。
なので、あくまでも主役はメンバーで、私はメンバーが動きやすいようにサポートをしようと考えるようになりました。
ちょうど、学校の部活動におけるマネージャーのように、選手がプレーに集中できるように環境を整える、という感じです。
強制しない
人間それぞれ個性がありますし、エンジニアとして考えた時にも興味のある分野、好きな分野、嫌いな分野など、完全に同じ人は稀だと思います。
なので、キャリアパスや勉強のプランを考えるときも、サポートやアドバイスをすることはありますが、強制はしないように心掛けています。
メンバーが、自分に必要と思うことを、自分自身でしっかり考えて実行することが重要と考えているからです。
（強制してしまうと、やらされてる感も出てしまって、効率が悪くなったりモチベダウンしたりというデメリットが多そうですし。）
アドバイスもちゃんとメンバーが納得した上で、自分に必要だと感じたら実行するという温度感で良いと思います。
なぜなら、アドバイスも結局は私の経験に基づくものだったり、一般論でしかないからです。
どちらにせよ失敗するときは失敗しますし、失敗した経験から学ぶことも多いはずです。
なにより、必要になったらきっと自分から行動するでしょう。（勉強するなり調べるなり。）
何をやるのか
メンバーが開発に集中できるような環境を作ったり、そのサポートに尽きると思います。
手段はいろいろあると思いますが、最終的にそれがメンバーのパフォーマンス向上に繋がるのであれば、きっとそれが正解なのでしょう。
1on1はメンバーの人となりを知る手段で、人となりを知ることができれば、そのメンバーにあったサポートができるかもしれません。
あるいは何かしらの不安があったり、会社に対する不満があるならば、それを取り除くように働きかけることも必要になりそうです。
おわりに
エンジニアリングマネージャー自体がまだ歴史が浅いこともあり、何をするべきなのか迷いがちですが、迷ったら『メンバーの為になることは何なのか？』という原点に戻って考え、思考を整理していきたいと思います。
一つの考えとして、この記事が参考になれば幸いです。