かけだしエンジニアリングマネージャーの決意表明
運命の導きにより、2024年にエンジニアリングマネージャーの役を拝命しました。非常に重要なポジションではありますが、私はマネージャーとしての経験がありません。
このままではマネージャー職についても大した成果が上げられないのでは無いかと思い、年末年始の休暇を利用して勉強した内容をここにアウトプットします。
エンジニアマネージャーとしての目標
まずエンジニアリングマネージャー（以下EM）として目標とは何か？について考えました。マネージャーといっても1社員であるから評価される立場であることは変わりありません。そこでEMとしてどのような目標を立て、その成果をもって評価してもらおうかを考えました。
エンジニアリングマネージャーとしての私の主な目標は、以下の4つです。これらを達成することで、効率的かつ効果的なチームを構築し、成功に導きます。
- スピーディーなリリースを実現する仕組みの構築
- 緊急性の高い不具合の修正に対して柔軟に対応できる仕組みの構築
- 属人化を防ぐ仕組みの構築
- 各エンジニアが持てる権限の明確化
この文脈であえて「仕組みづくり」「明確化」「運用」と言葉を使用しました。それには理由があり、それはマネージャー職と求められる業務は以下の4つと考えるからです。
- 仕組み作り
- ルールの明確化
- その運用および監視
行動指針
上記で決めた目標に沿った行動を行うためにEMとしての行動指針を以下に定めます。
- 決めた仕組みは必ず文章として残す
- KPIなどの目標は数値化でき評価できるようにする
- 優先順位を決め権限を与える
- 早めに失敗でき、その失敗を振り返る機会を作る
1. 決めた仕組みは必ず文章として残す
仕組みとは、それぞれがそれぞれの権利・権限を持って運用することで成り立ちます。その権利・権限には良いものと悪いものがあります。
- 良い権利・権限 : 文章として明確化されているもの
- 悪い権利・権限：文章として明確化されていないもの
なぜ文章で明確化されていないと悪いのかというと、その権利・権限が次第に 「暗黙の了解」「既得権益」 となり、新たにアサインされたメンバーにとって負担でしか無くなってしまいます。新しいメンバーがチームに馴染めないまたは辞めてしまうと、チームとしての成果がスケールアウトしないことになってしまいます。
それは何としても防がなければいけないため、決め事は必ず文章に残しチームメンバーに周知する必要があります。また仕組みに問題が生じた場合、具体的な問題点を特定し、改善しやすくなるメリットもあります。
逆に、文章として明確に残せない仕組みは作るべきではないし、許可もするべきではないです。
（極端な例ですが、残業はしなければいけないや育休は取ってはいけないなど）
2. KPIなどの目標は数値化でき評価できるようにする
マネージャーとして部下を評価することがあると思います。また自分が定めた仕組みが正しく運用されているか、望んだ結果が出ているか評価できるように数値化する必要があります。
数値化することによって正しくまた公平な評価ができ、またその評価に納得感を持たせることができます。
3. 優先順位を決め権限を与える
エンジニアのタスクは多岐にわたり、常にどの作業を先に着手するか悩まされます。例えば大きい実装タスクをやっている途中で緊急対応が必要になったとします。その時問題になってくるのが大きい実装タスクが期限内に終わるかどうかです。普通でしたら上長またはPMに状況を説明して期限の見直しをお願いしますが、それではエンジニアの負担でありコミュニケーションコストが重くなってきます。
そこで、優先順位を明確化して各エンジニアが持っている権限内で期限を調整して着手してもらうようにします。
この目的としては、より早い意思決定でスピーディーなリリースを実現させるためです。あらかじめ優先順位と権限を明確すれば各メンバーで判断して行動を起こしてもらおうというわけです。
4. 早めに失敗でき、その失敗を振り返る機会を作る
参考文献にもありましたが、仕事は**「能力」よりも、「機会」が先にあるケース**が多いと思っています。まさに今回私はマネージャーも経験も無く勉強もしたことがなかったが、このような機会に恵まれてこのように勉強をしました。
なので、メンバーにはより多くの機会を与えて失敗した場合はそれを振り返すチャンスを与えたいなと考えました。早めに失敗すれば大きな問題にもならずにかつその失敗を次に活かしてくれると思います。
まとめ
偉そうなことを書きましたが、ここにあるものは机上の空論でまだ結果が出ていない、というか執筆時ではまだ始まってもいません。
ですが、自分自身とチームメンバーがエンジニアとしてどのように成長していくかについて、真剣に考えてまとめました。
この文章を通じて、自己成長を目指すとともに、他のエンジニアリングマネージャーの方々にも参考になれば幸いです。
Discussion