Engineering Manager になって3ヶ月の私が大切にしていること

この記事は、Magic Moment Advent Calendar 2023 8日目の記事です。

こんにちは！
Magic Moment で Engineering Manager をしている 藤崎 (@k1y0h1ei6) です。

私は 2023年9月に Engineering Manager（以下、EM）になりました。
新卒でソフトウェアエンジニアになって以降 Tech Lead は経験がありますが、EM は初めての経験です。
そんな新米 EM の私がわからないなりにも試行錯誤し、大切にしてきたことをまとめたいと思います。

チームの成果が最大になるか？を常に問う

EM になる前、いくつか社内研修を受けたり、マネジメントに関する本を読んだりしました。そこで学んだことの1つとして、マネジャーは自身の行いを評価されるのではなくチームの成果によって評価されるというものがあります。
自身がどれだけの施策をしても、自身がどれだけ開発をしても、チームとしての成果がなければマネジャーとしてはまだまだです。
では、成果を最大化するために具体的になにをしているか？を3つ紹介します。

1. 決断をする

マネジャーなので当然といえば当然です。
しかし、当たり前のことだからこそ当たり前にできるよう強く意識している部分でもあります。

チームの成果を上げるためにチームとしてなにをやるべきか？逆になにをやらないか？の決断をすることであったり、日々のメンバーの取り組みの中で障害となり得るもの（または既に障害となっているもの）を取り除くということだったり、
日々目まぐるしく変化する中で沢山ある変数のうちのなにをいじると最大成果になるか？を常に問い、決断することが大事だと思っています。

「これで確実にいける」と確証のようなものをもって決断できるときは少なく、多くの場合は不安混じりです。
ただ、不確実な中でも「これでいこう」と決断し、最後は自分でそれを実現してやるという思いを持つことが大切なのかなと感じています。

例えば、ある機能開発をしている際、バックエンドの開発進捗がフロントエンドの進捗に対して芳しくなかったときがありました。
フロントエンドとバックエンドで完全分業をしているわけではないもののある程度専門性で分かれて進めていくことが多いのですが、一時的にフロントエンドのメンバーにバックエンドの方の開発に入ってもらうなどをしました。
専門領域ではないのでバックエンドに入ってもらっても状況が変わらないということも起こり得る中で、専門領域を取っ払いタスクを分担することで結果的に悪い状況は改善されました。
不確実な中でも勇気を持って決断する、ということができた1例だと思います。

2. やらないことを決める

1つ目に記載した「決断する」ことの一部にはなりますが、やらないことを決めることはとても大切です。
なぜ大切か？というと、限られたリソースの中でなんでもかんでも取り組んでしまうことは、全てが中途半端な結果に終わるリスクを含んでいるためです。
新しく作りたい機能・アップデートをしたい機能・解消したい技術負債など、やりたいことに溢れています。ただ、その全てを実行するだけのリソース・余裕がないのもまた事実です。
特にスタートアップであれば尚の事だと思います。
いかにフォーカスすることを絞り、チームでそこに集中できる状況を作れるか？を意識しています。

3. 説明責任を果たす

1,2で記載したような日々の決断・取り組みはメンバーに直接的に影響があることを含むため、どんな狙いがあるのか？なぜその決断をしたのか？がなければメンバーの納得感も生まれません。
理由もわからずやらされることは私自身やりたくないですし、それはメンバーも同じだと思っています。
そのため、こうした説明責任を果たすということも合わせて大切にしており、丁寧に伝えることや後からでもわかるように文字でも残すことは心がけています。

自己効力感・組織効力感というものがありますが、「自分ならやれる」「自分たちならやれる」という思いは大切です。
これらの思いはやっていることに納得感を持ち、自分(自分たち)がそこを目指したいと心から思える状態にならなければそう思うことは難しいです。
だからこそ、丁寧に伝えるということは大切だと考えています。

チームメンバーを信じる

なにかを進めるとき、時には「自分でやった方が早い」と思うこと(いわゆる「自分でやった方が早い病」)も事実としてあります。超短期的にみたらそれが1つ目に書いた「成果の最大化」に繋がるかもしれません。
ただ、そこに時間軸を加えて捉えてみると、それを自分がやったことでチームメンバーの機会を奪うことにもなり、チームとしてのナレッジにならず属人化を加速させる要因になってしまうことも考えられます。

EM として、各メンバーにとってちょっと難しいかな？と思うようなことであっても、その人の成長機会を考えたりその人の強い想いを汲み取ったりした場合にはどんどん挑戦をしてもらいたいと思っています。
仮にそこでちょっと失敗しても良いと思っており、むしろ失敗から学ぶことは多いので失敗してもらうべきだとも感じています。
メンバーの成長を信じているからこそこのように考えることができ、自分でやるのではなくメンバーに頼るという判断ができます。

1つだけ注意していることとして、挫折するような失敗は再び立ち上がるのも難しくしてしまうので、挑戦をしてもらうときは大きな失敗をさせないという意識も持つようにしています。
セキュアベースリーダーシップ理論にも通じますが、挑戦をするためには挑戦できる安心感もセットで考えることが大切です。

例えば、まだジュニアなメンバーにとって少し挑戦となるかな？という難易度の機能開発に関わる設計をお願いしたり、EM 候補として沢山経験を積んでもらいたいメンバーにプロジェクトリードをお願いしたりしていますが、悩みながらも試行錯誤しそこから学びを得てメンバーの変化が見えるので信じて任せて良かったと感じています。

嫌われることを恐れない

私は正直、”伝える”ということがそれほど得意なタイプではないと思っています。 また、人間誰しも嫌われたくないですし、言いづらいようなことは極力言わないで済む方が楽だったりもします。
ですが、EM になり、考えを意識的に伝えること・言いづらいことであっても言うという事は意識するようになりました。

伝えることが得意ではないと自覚しているからこそ、言わなくてもわかるだろう・これくらい伝えればわかってもらえるだろうという感覚があっても、100%は伝わっていないという意識を持つようにしています。

そのため、「そんなこと言われなくてもわかるよ」とか「当然でしょう」と思われるかもしれないと思いつつ、敢えて伝えるということを意識しています。
伝える際の言葉選びは難しいなと感じますし、間違えたらどうしようという不安も沢山あります。ですが、伝えずに失敗するよりも伝えて失敗した方が後悔しないなと思うと、やはり伝えていこうと思えます。

また、時にはチームメンバーに厳しいことを伝えなければいけない場面もあります。個人・チームとして成長するために必要な痛みもあります。
1メンバーだった頃はやはり言いづらいことを言うことは正直避けていた部分もありました。
ただ、メンバーの成長を信じるからこそ・成長の先にチームとしての成果の最大化があることを信じるからこそ、必要な痛みとして言いづらいことでも問題提起したり、フィードバックをしたりすることも大切だと今は感じています。
自分が嫌われたとしてもそのメンバー・チームが成長するのであれば EM として喜ばしいことだと思えるようになったことは自分自身の成長であったかもしれません。

最後に

いかがでしたでしょうか。
新米 EM のため、歴の長い EM の方からしたらいろいろ指摘したくなることもあるかもしれません。
また、ここに書いたことはどれも完璧にできているか？と聞かれるとまだまだだとも思っています。

私なりに考え試行錯誤してきた3ヶ月をまとめてみましたので、少しでも同じ様な境遇の方の参考になれば幸いです。

明日のアドベントカレンダーは @aqlwah の「エンジニアとしてブレイクスルーしたければまずキーボードを2つに割るんだ」です。