エンジニアリングマネージャーを自称してからやったこと

2023年8月7日 01:03

これはなに

ここまで自分がやってきていることの振り返りのためのメモ。
ちなみにタイトルにエンジニアリングマネージャーと入れたが、チーム内での自称であって会社の公式な役職ではない。マネージャーなる人物が上司として居て、人事評価はマネージャーにやってもらっている。EM自称おじさん

エンジニアリングマネージャーの定義は大体こちらを参照。

ピープル、テクノロジー、プロジェクト、プロダクトの４領域にまたがるマネジメント。特にピープルマネジメントを軸とし、人事評価権限を持つことがテックリード、プロジェクトマネージャー、プロダクトマネージャーなどと異なる、とある。

自分の場合はマネージャーが別に居て人事評価を持っていないため、上記のエンジニアリングマネージャーに当てはまらないと思う。

とはいえテックリードというほど技術面を担当するわけでもなく、プロジェクトマネージャーというほどプロジェクト管理に重点を置いたわけではなく、プロダクトマネージャーと名乗るほどビジネス面やユーザーに責任を負ったわけではない。

ただスクラムの枠組みを超えて開発チームをリードする役割を自分が担う必要があると考えた結果、エンジニアリングマネージャーと称するのがもっとも近いと結論づけた。

スクラムの枠組みを超えて、、と言ったがどういうことか。

プロダクト開発チームにはスクラムの仕組みに乗る部分とそれ以外の部分がありそう。

上記事ではプロダクト開発を２つの学習ループに分解している。うち一つはスクラムによって成立する学習ループに該当する。

もう一つは方針や目標を設定・検査する学習ループで、スクラムではビジネスの目標をセットすることはできないので、これはスクラムの仕組みの外側のループだと言える。

自分がスクラムマスターとして振る舞う中でスクラムがうまくいって居る感覚がチーム内にあったが、一方で「ビジネス上で意味のある開発をできていないのではないか」という声が挙がっていた。上記事を見て２つ目のループが成立してない状態だと理解したので、そのループのオーナーを果たそうと考えた。

事業責任者がリードしていたプロダクト企画のための会議体にまず参加した。
開発チーム内の課題感とずれた情報をもとに意思決定されているのを確認できたので、開発チームの情報をフィードバックすることで適切な意思決定をできるだけ支援できる体制にした。

また事業責任者の考えを開発チーム内で話すこともできるようになったので、ビジネス組織と開発チームの一体化に努められそうだと思う。

ビジネスの課題を理解する、開発の課題を伝える、それを繰り返して事業責任者と信頼関係を作ることが重要そう。

両チームの課題を列挙して、課題に対応するプロジェクトを優先度順に並べる。
プロジェクト、プロジェクトを推進するオーナー(スクラムチームまたは個人)、そしてプロジェクトの具体的な施策を想定スケジュール付きで入れていった。

大体のプロジェクトオーナーはスクラムチームになったので、ブレストの要領でアイデア出しをして話し合って施策を決める(途中)。

スクラムチームがオーナーじゃない例としては、スクラムマスターをやってみたいメンバーがいて、自分としても一つ目のループの推進は任せていきたかったので彼がスクラムを推進するというプロジェクトを立てた。これに関しては彼にオーナーになってもらって施策を自分で出してもらえるよう努めた。

施策を確定したらプロダクトバックログに入れていく。ロードマップがうまくいっているかの検査は、スクラムの仕組みとは別に用意しないといけなさそうか。。

熟練したマネージャーからは甘いと思われそうというか、プロならどんな仕事でも全力でやるものかもしれないが、主体的にプロジェクトを推進してもらうにはその人がやりたいことをやれている必要があると思う。

ということで個別に1on1を入れて、雑談したりwillについて話していった。チームの課題と結びつくことがあればプロジェクト化したり施策に入れたり。

やる前はそんなに結びつくことあるかなと思ったが、意外と大体みんなある。プロダクトに興味を持ってくれてる人たちだからとか、スクラムが上手くいってるだけに感じている課題がみんな大体同じだったりとか、興味ある領域がそれぞれちょっとずつ違うとか、そういう要因はありそう。

また1on1の副産物だが、マネージャー→メンバーの関係だと引き出しづらいような不満を聞かせてもらえることがあって、同じチームメンバーの目線で話し合えることの意味は大きいかもしれない。

このロードマップの推進をうまくやれたとして今後なにができるのかについて。

エンジニアリングマネージャーの４領域のうち、プロダクトマネジメントは訳あって意図的に後回しにしたところなので、ここに注力するようにしてそれ以外の領域は別の人に推進してもらうようにするのが一つ。
プロダクトビジョンやKPI、ユーザーからのフィードバックシステムの構築など。

あるいは、このチームだとテクノロジーマネジメントの比重が大きそうなので、その領域をロードマップの重点にしていくか。
品質保証、DevOpsなど。

公的なマネージャーじゃないけど部分的にマネジメントを担っている人は割といるんじゃないかなと思う。ここでは~~自分のモチベを上げるために~~便宜的にエンジニアリングマネージャーと自称したがどうなんでしょうね。

この記事が気に入ったらサポートをしてみませんか？