Engineering Manager (以下 EM) になって一年くらいが経過した。一年やってみてどうだったかなんとなく振り返りをしてみると、なんだか最近はプレイヤーとしての活動ばっかりしていたような気がする。
っていうか一年単位での振り返りってスパンが長すぎなので、もっと細かく振り返らねばならんな、と思った。一年前のことなんて覚えてない。昨日の朝ごはんだって覚えてるか怪しいというのに。
特に直近の数ヶ月、2020 年 10 月移行はプロジェクトが忙しかったというのもあるけど、特にプレイヤーとしての活動が多かったんではないかと思う。ほとんど毎日コード書いてたというか。いや、別に書いててそこまで悪いとは言わないんだけれど、本業であるはずの EM はどうなった、という。
ここ半年くらいでの EM っぽい活動といえば、
- 週に一回行うメンバーとの 1on1
- 勤怠申請の承認
- ミッションを作ること
- 採用活動 (書類選考、面接)
- よそのチームの EM と話してタスクを按配し合うとか
- あと最終的に評価 (昇格とかなんだとか) を扱う
割とあった。あんまり大したことやってないかと思ったけど改めて並べてみるとこれだけやってればまあいいか、っていう気にもなってきた…か…？
見えない障害物と向き合う
EM は何をやるロールなのか、というのを一年近く考え続けているが、結局のところ「チームを維持する上で障害になっている “何か” を検出して取り除く」ために存在するロールであるという認識になりつつある。障害はチームによって異なり、解決方法も千差万別だったりする。往々にして障害は緩やかなものであり、急に立ちふさがるというよりは真綿で首をしめられていくような性質のものが多いような気がする。対処をしなくても急に何かが起こったりはしないが、放っておけば緩やかに崩壊していく、ような。放っておくとメンバーのやる気は徐々に削がれていって、チームを異動するか転職するか、という形で発露するっていう流れなのかもしれない。
チームを維持するための努力
チームを維持するというのはつまり「メンバーがやる気のある状態をキープし続ける」というような意味で考えている。
やる気がいつも最高潮でなくてもいいんだけど (それはそれで気持ち悪い) 、忙しい時期があったり凪の時期があったり、作ったものが世界を良くしている実感を得られたり、適度に新しいものを学び吸収する機会があったり、みたいなのがやる気の維持につながる要素なのではないかと思っている。人によって何がやる気に繋がるかみたいのは違うと思うけど、最低限の報酬というのは必ず必要だとも思う。
メンバーのやりたいことにあわせて業務をアラインしていくというのは難しいことが多いが、それでもそれを意識して、なるべく良きに計らっていくというのが最低限 EM がすべき努力なんではないかな、と思ったりしている。
ずっと同じメンツでチームを続けられればそれはそれで良いんだけども、とはいえ IT 業界、特にウェブ業界というのは人材の流動が激しく、何年も同じチームが維持できるとは思わないほうがいいんだろう。だとしたら人が入れ替わる前提で建付けを考えておかねばならず、例えば新しく来た人にナレッジを授けるためのオンボーディングであるとか、プロダクトそのものもなるべく分かりやすく、壊れにくいものにしておく、一子相伝みたいなものを排除していく、というのも EM が配慮して然るべきなのかなーと思わないでもない。
ウェットになりすぎないのも大事
主に 1on1 を通して、メンバーの趣味趣向、どんな業務がやりたいかみたいなことは、なんとなくだが把握していく機会がある。
雑談のような 1on1 も多くなり、少なくとも僕からみたら「仲の良い」みたいな状態になっていくことがしばしばある気がするし、そうなりたいとも思っている。
ただ、その「仲良くなろう」みたいな気持ちは、いわゆる「ネガティブ・フィードバック」というのを遠ざけてしまうとも思う。そりゃあ気分悪くなるようなこと言ったら仲良くなるのからは遠ざかるよね、って思うんだけど、とはいえネガティブ・フィードバックの類ほど早く通達することが大事である。あとから「あのときのあれは良くなかった」みたいに回想しながら伝えるのは、記憶の鮮度が落ちているので正しく認識しにくいとか、後から混ぜ返すのはネチネチしててイヤだとか、とにかくあとから思い出したように悪かった思い出を伝えるのは一利なしである。早く言おう。言わないでほっとくのは問題を見て見ぬ振りしているに過ぎない。真綿で死ぬ。
あくまで業務であるんで、「仲良くなりたい」も大事なんだけど、それ以上に「言うことちゃんと言う」が大事だよなー、なんて思ったりしている。そんな単純なことだがなかなか実行できないのは自分が可愛いからなんだろうとも思う。嫌われなくない的な考え。ただ、そういったネガティブなフィードバックも迅速に行っていくことが、結局はチームの維持という面でポジティブに働くだろうとも思うし、何より本人のためにもなると思う。フィードバックが的を射ていればだが…。
あと苦言を言いにくい気持ちになるのは “心理的安全性” を僕自身が感じられていないせいかもしれない。思えば心理的安全性の醸成のための活動というのもしたことがなかったような気がする。今後の課題。
最近読んだ
最近読んだ記事の話。
前にも読んだことがあった気がしたけど、ふと気になって再び読んだ。
「マネージャになることは昇格ではない」ということが書いてあるけども、まあどうだろうね。昇格である会社もあるかもしれない。ただ自分も別にマネージャのほうがプレイヤーより偉いとは思っていなくて、あくまで EM もひとつのロールであり、ちょうど “野球部のマネージャ” みたいな立ち位置に自分がいることを想像していたりする。プレイヤーがしっかり実力を発揮できるように頑張るであるとか、新しい部員を探すために頑張るであるとか、みたいな。
ただあれだ、そんなふうに考えてもやっぱりマネージャとプレイヤーは必要とされるスキルセットが全く異なるような気がしていて、割とありがちな「プレイヤーがなんやかやあってマネージャになっていく」というのは全然メイクセンスではないように思えてくる。弊社のマネージャには「評価する」という役割が漏れなくくっついてくるんだけど、評価するためにはエンジニアリングのことをよく分かっていないといけないというのは分かる反面、チームの健康状態を維持するっていうのはエンジニアリングとは全然別のスキルが必要である気もするので、マネージメントする人と評価する人を一緒にしとくのがそもそも違うんかもなーなんて思わんでもない。
読んでる
人間を知るためにピープルウェアという本を読んでいる。
割とさくさく読める。読めたらまた感想でも書こう。