🗣️
新米エンジニアリングマネージャーのしごと

Ita
2025/02/19に公開
こんにちは。先生向け学習管理用ツールを開発しているQMチームのEM、Itaです。
ただし、EMといっても2024年の7月に就任したばかりのペーペーです。今回はそんな「新米エンジニアリングマネージャーのしごと」について紹介したいと思います。
!

 こんな人におすすめ
EMに興味があって調べてみたけど曖昧でよく分からなかったからとりあえず具体例を知りたい方
他のEMの活動が気になってるEMの方


 経緯もともとアジャイル開発やリーン開発に興味があり、開発リーダーポジションとしてチームビルディングをそこそこ進めていました。
そんな中、徐々に採用の話が聞こえるようになってきました。曰く、「エンジニアの採用難易度がめちゃくちゃ高い」と。ただ深堀って聞いてみると、「ハイスキルなエンジニアの採用難易度がめちゃくちゃ高い」という話でした。ではジュニアを採用して育成するのはどうかと聞いてみたところ、育成する体制が整っていないのでそれは難しいということでした。そこで私は、「私のチームでジュニアを受け持つと言ってしまえば、ジュニア採用を始められるのではないか」と考えました。
というのも、COMPASSに転職する前の会社では、ジュニアどころか未経験を途切れなく採用し、育成して、事業として成り立たせていたのを見ていましたし、私個人としても未経験を育成したことがあったので、ジュニアならまあ大丈夫でしょうと思ったわけです。
そして思ったことをそのままEMである上司に伝えたところ「ではEMをやってみますか？」となり、「あ、はい、やらせてください」とEMを引き受けることになりました。COMPASSの柔軟性の高さを改めて感じた瞬間でしたね。

 事前準備EMを引き受けるにあたって、まずは本を読みました。私は昔から「必要になってから勉強する」と「勉強するときは本を購入する」というスタイルを徹底しておりまして、今回もそれに倣い以下の本を購入しました。(COMPASSにはLearner支援制度という書籍購入に対する補助があります。もちろん活用させていただきました)

前職で育成経験があると言っても、巷で流行りのEMとの乖離はなんとなく感じていました。そこで、気にはなっていたものの、まだ必要性を感じられず読まないでいたこの本をついに手に取ることにしました。
ここで以下のマインドセットを手に入れたことが後々大きく響いているんじゃないかなと思います。
EM活動の分類
情報収集、意思決定、ナッジング、ロールモデルという分類。開発リーダーとしてなんとなくやっていたことを、それがEMとしての活動なんだと太鼓判を押されて自信を持って行動することができるようになりました。
マネージャーのアウトプットの定義
マネージャーのアウトプット =

\quadあなたのチームのアウトプット + あなたが影響を与えた他のチームのアウトプット
自分のチームのために活動するという原則と、周りのチームへ影響を与えることの重要さがよく分かる良い言葉だと思いました。
この書籍を通して良いマインドセットと道具箱を手に入れたので、次は実践です。

 手始めに
どこから手を付けたかというと、1on1です。

 経緯「ジュニアを採用して育成する」というところからEMの役割を担うことになったわけではありますが、私の採用スキルやリソースを鑑みた結果、私のEMとしての採用面での責任は主に「ジュニアを採用できた場合に私のチームで受け入れる」という点に限定させていただいておりました。
そして、ジュニアを採用する方針は決まったものの、実際に採用が決まるまでにはある程度の猶予があることは明白でした。また、採用後の育成に関しては前職での経験を活かせる部分だったので、今すぐ取り組む必要はないと考えました。
そこで、まず優先すべきことを考えた結果、チームビルディングを進めることに力を入れるのが良いと判断しました。これまでは開発リーダーとしてチームビルディングを少しずつ進めてきましたが、この機会にそれを本格的に進めることにしました。そして、その最初の取り組みとして選んだのが1on1でした。1on1は、メンバーの状況を理解し、信頼関係を築きながらチームの基盤を作るのに効果的でありながらも簡単に始められる方法だと思えたからです。

 実践私が所属するQMチームには当時私を除いたエンジニアが5人とQAが1人在籍していました。みなさん業務委託契約の方々でしたが、私は6人全員と毎週30分の1on1をすることに決めました。
業務委託という契約上、即戦力で育成不要という見方も可能で、1on1という長い目で見れば大きく工数がかかることにEMのリソースを投入しても良いのかと疑問の声が挙がることもありました。正社員からではなく業務委託の方から挙がりました。「え、助かりますけど本当にいいんですか？」
そこはマネージャーのアウトプットの定義に立ち返るときです。目的はチームのアウトプットの向上です。1on1は契約形態に関係なく有効だと思えたので全員と1on1をしました。
1on1の議題は書籍から拝借したり、本当に聞きたいことを考える時間を取って、お手製の議題を作ったりしていました。また工夫した点として、議題と議事録はドキュメント管理ツールではなくAsanaで管理しました。これはAsanaが全社の標準的なタスク管理ツールとして運用されていることに起因しています。1on1の中でネクストアクションが生まれることは少なくありません。ネクストアクションを普段使用しているタスク管理ツールにすばやく書き起こせる状態で1on1を行うことが、ネクストアクションの実行漏れを防ぐ上で重要なポイントだと思っています。

 結果業務委託という契約上仕方のないことではありますが、育成・評価という観点を強く盛り込むことは流石にできませんでした。しかしそれにもかかわらずチームビルディングとしての効果は予想よりも遥かに大きく、そして個々人のことを深く理解できるようになりました。
その効果の一例を挙げると、従来の体制ではフロントエンドとバックエンドの開発の担当者は明確に分かれていました。しかし1on1を継続していく中で、ほぼ全員が両方の経験があるかまたは興味を持っているということがわかりました。その結果、職能を分けずにモブプロしたり、逆に１人にフルスタック的にタスクを遂行してもらったりすることができるようになりました。柔軟な開発体制を敷けるようになったのは大きな収穫の一つです。

 次にやったこと
QMチームを2つのサブチームに分割しました。
元のチームの境界は、朝会や振り返りといったイベントで残しつつ、タスクのアサインと遂行をそれぞれのサブチーム内で完結できるようにエンジニアを振り分けました。

 経緯重要度も緊急度も高く、しかし要求がなかなか定まらない開発アイテムがありました。そのため些細な変更にチーム全体が右往左往してしまっているような状況になってしまっていました。
更に、これまでも重要度と緊急度が高い開発アイテムを優先してきた反動で、重要度は高いけれど緊急度が低くなりがちな改善タスクが溜まってしまっていました。
これらの状況を解決するにはどうすればいいか考えたところ、開発ラインが２つあればすべて解決するのでは？とひらめき、棚で眠っていたチームトポロジーを引っ張り出しました。


 実践まずはAsanaで管理しているタスクをドメインで分類して現状を把握することから始めました。そしてタスクをドメインでグルーピングして、責務、関連度合い、複雑度、タスク量に着目すると良い境界線が見つかりました。
さらに、人が減っても本当に大丈夫そうか各エンジニアに1on1でヒアリングしたり、サブチームとチーム全体それぞれの会議体の設計をしたりしました。そして、これなら運用できそうだと判断できたので実施しました。

 結果狙い通り、要求の変更の影響は一つのサブチームに抑えられ、もう片方のサブチームでは改善タスクに継続して取り組めるようになりました。

また、コンテキストスイッチが減ったとメンバーからも好評価でした。チームサイズは6~8人が適切だとよく言われていますが、リモートワークだとコミュニケーションコストが高いので実はもう少し減らしたところに適切なサイズがあるのではと期待させる結果となりました。
ただしこのサブチーム分割は、各メンバーの在籍期間が長く、プロダクトおよびプロダクションコードへの深い理解があったからこそ成功したのだと思います。エンジニア5人のチームを分割することは一般的にはおそらく悪手だと思います。

 白状さらっと成功したと言いましたが、もちろんすんなり成功したわけではなく、途中落とし穴にハマりました。上流工程を担当するPO、デザイナー、そして私にコンテキストスイッチが集中しだしたのです。仕様作成、会議、相談、状況把握等々。規模こそ小さいですが2つのチームに関わることの意味を身を持って知りました。
今回の事態に対しては、機能開発後に技術的負債の解消期間を明確に設けたり、移譲を進めたりすることである程度対応することができるようになりました。
本質的にEMはコンテキストスイッチから逃れられないと思います。しかしEMも人である以上、コンテキストスイッチを抑えられれば抑えた分だけパフォーマンスが上がるはずなので今後も諦めずに対応していきたいと思います。

 今回のまとめ1on1はいつでも大事
条件がそろえば少人数でのサブチーム分割も可能

 次回以降のトピック今回が私の初投稿となります。意気込んでいたら詰め込みすぎて読み辛くなってしまったのでそこそこ削りました。書きたかったトピックはまだまだあります。
ジュニア採用できました
Notionのデータベースで開発ドキュメントを正規化する
振り返りに定量データを持ち込む
TDR(Team Decision Record)の導入
改めて、ペアプロ
焦ってタスクを取ってチームに迷惑をかける
忙殺されるとリファインメントとプランニングさえも消してしまう
委譲。そして放り投げ。
棚卸しも兼ねてブログという形でまとめていくのはアリだなと感じました。また執筆させていただきたいと思います。
最後までお読みいただきありがとうございました。