初めてEMになって半年間でやってきたことの振り返り

STORES 予約でエンジニアをしている natsume です。生後半年の子猫をお迎えし毎日癒やされています。

STORES 予約の開発チームは、自分が入社した2021年6月の段階ではエンジニア6名のチームでしたが、1年経った2022年6月では15名になり、エンジニアリングマネージャー（以下、EM）一人では全員を見るのは難しい人数となっていました。

そこでEMをもう一人立って半々で見ることとなり、そこに推薦していただきEMとなりました。

2022年7月からEMとして、開発をしつつもプロダクト開発に向き合う組織をよりよくしていくための施策を振り返っていきます！

施策は同じEMの ykpythemind さんと議論しながら考えているものです。いつもありがとうございます！

組織と開発チームの体制変更

STORES の組織構造は ◯◯部門 > ◯◯本部 > ◯◯グループという階層になっています。各グループにはマネージャーが一人就くという形です。

STORES 予約のエンジニアはテクノロジー部門 > 予約本部 > プロダクトグループに所属しています。

開発体制としてはエンジニア7人づつの2チームで開発をしています。

今回、私がEMになり1つのグループを見ていくことになるので、プロダクトグループを分けることになります。

開発チームとグループを同じメンバーとするのが一番わかりやすい形かと思います。

しかし、開発チームのメンバー移動をしようとすると、組織変更も合わせて必要となり気軽に変更ができなくなります。

それによって

のような課題が出てくるだろうと考えました。

プロダクトグループの開発チームの特徴は

など、柔軟性があり流動性を保ちつつもひとまとまりな開発チームでした。その良い点を組織構造の都合で妨げるのは悪手だと思い、開発チームとグループは一致させないようにしました。

この判断はデメリットももちろんあり、EMが自グループのメンバーを見るためには別チームの動きも見る必要があります。

しかし

もあり問題ないと考えました。

つまり、1EMが1チームを見るのではなく、2EMで2チームを見るような体制でいこうと決めました。

そうすればチームとグループのメンバーが異なっていてもメンバーのアクションを見ることができるし、EMそれぞれの視点から新たな気付きを得られることもできます。

グループ名はその名前に特性を持たない

となりました。（A / B はデザイナーグループがその命名規則を使っていたので拝借しました）

半年で開発チームのメンバーの入れ替えを2回行いましたが、特に障害はなくスムーズに行うことができ期待していた柔軟性・流動性は維持できています。

また、入れ替えによってメンバーのチャレンジを計画的に作ることができたのはかなり良い点でした。

続いてはコミュニケーションをより円滑に行えるようになるための施策として、オフラインイベントを実施しました。

急激に人数が増えたこともあり、同じ開発チームにいる方はよく話すが別チームの方とは話す頻度が減った、などの課題が出てきました。

昼会やスプリントプランニングなどのスクラムイベントは開発チーム毎に実施しており、開発チームがかぶらないと話すタイミングが少なく「ほぼ話したことがない」メンバー同士もいる状況でした。

オフィスなどでオフラインで顔を合わせて話すと、リモート環境でも話しやすくなるという経験からオフラインイベントを実施しようとなりました。

を目的とし、マネジャー陣でどのような内容を実施するか相談しました。

より課題感があったコミュニケーションを元に、相互理解を軸としたコンテンツを実施していくこととなりました。

当日タイムライン（15時 - 19時）

シャッフルして自己紹介（0.5h）
- チームにランダム分けて話す
相互理解のエクササイズ（1.5h）
- ドラッカー風エクササイズ
休憩（10分）
チームとして大事にするバリュー（1h）
- チーム分けて、重要なバリュー / 重要じゃないバリューを選定する
- 重要なバリューを体現するために、具体的なアクションまで落とし込む
懇親会
- @オフィス