エンジニアのマネジメントについて調べたことと思ってること

目的

いろんな本とかサイトとかで勉強したことをまとめる

そして、自分がどういう風にするべきと今思ってるかもまとめる

本文

1on1

何よりも1on1というか対話が大事であり、ちゃんと時間を取って話すことが大事。

オープンドアポリシーというのがあるが、これだと仲良い人はもっと仲良くなって、もともと疎遠な人はもっとそうなる。

目的は、関係性の構築というのもあるが、コアバリューを伝え続けることも大事。

何を会社がしたいと思っていて、このような方向で進みたい。その時に、本人がやりたいことやできることと、どのようにマッチさせて、やる気をもって事業に貢献してもらうかが、スキルの必要なところらしい。

あと、良いフィードバックはとても大事で、日頃からするのが良いらしい。みんなの前で褒めるのも大事そう。（だが、自分はみんなの前で褒められるの茶番に思えて、すごく苦手でいたたまれなくなるので、そこは人によりそう。）

逆に悪いフィードバックは1対1で行うのが良いとのこと。

メモもプライベートのことを除いて、ちゃんと残しておくのが良い

情報の透明性

マネジメントをすると、確実にマネージャー側が情報を多く持ち、情報格差が生まれる。

これはチームにとって健全ではないし、そういったチームは上手く回らない模様。

かといって、MTGで全てを共有しようとしたり、議事録を共有するとかも、結局人によってはみなくて、上手くいかない模様。

スライドでみたのは、マネージャーが毎日、日報を書くのがいいらしい。もちろんチームメンバーもしてくれるとなお良い。

どう考えたかとか、どういう話をしたかとかちゃんと書くことで、情報格差が薄まるとのこと。

役割の明確化

JobDescription を明確化した方がいい

採用の時に役立つし、チーム外からの理解に繋がる。

よく誰に頼んだらいいか分からないみたいなことを、エンジニア以外から言われるが、役割を明確化して発信したら明らかに減った。けど、時間がたつと何故か特定の人に偏りがちになっちゃうから、ちゃんと運用は必要。

あと、新しい人（でコミュニケーションが嫌いではない人）の場合は、社内ツールの改善をお願いすると、社内の人とのコミュニケーションが行われ、業務知識獲得と社内の人に感謝されることによる、モチベーション向上や一体感が狙えて、とてもいい仕事だなと感じた。

朝会

チームのコミュニケーション量は大事。特にコロナでそれは切に感じる。

ただ、プロジェクトチームで行うべきか、職能別チームで行うべきかが、いまだによくわかってない。

組織体制

ここは勉強が不足してるし、経験も不足してる。

会社によっても適切なものは違うとのことなので、いろんな実例を学んでいきたい。

少なくとも自分は、仕事上の上下関係は無駄だと思う。

なので、階層構造は効率の良い情報伝達のために維持しながらも、開発者もマネージャーもCTOも全うするべき役割が違うだけで、偉いみたいなよく分からない概念はないという組織を目指したい。やはり情報格差をいかに減らすかが鍵だと思っている。

採用

大きな問題で難しい...もっと勉強と実践しないと...

技術力

評価をする立場にもなるわけだから、メンバーに信頼されるように、技術についていけるようにしないといけない。 かといって、開発を引き続きして、タスクが滞るのもダメなのでバランスが大事。

思ってること

やっぱりチームメンバーが成長すれば、自分の知りたいことも増えるし、今までより使える手段が増えるし、一度しっかり経験したら次に自分をマネジメントしてくれる人のやりやすいように動けそうだし、ますます本腰を入れてやっていきたいと思った。

参考

エンジニアのためのマネジメントキャリアパス エンジニア組織論への招待 エンジニアとしてワクワクし続けるためのエンジニアリングマネージャという役割分担 - BASEプロダクトチームブログ