こんにちは、アソビューでEM(エンジニアリングマネージャー)をしている近藤です。
子供の夏休み中に宮古島への旅行を計画しています。宮古島で海に入ってもらいたいのですが、「海いきたくない!怖い。」と言っています。
もしかすると海には入れないかもしれませんが...景色を見たり、美味しいものを食べたり、物作り体験などをしようと思っています!
この記事では、EMに任命される前からEMの役割を始めていた実体験について紹介します。 マネージャー職になる方の参考になると嬉しいです。
~ 目次 ~
なぜEMが会社に必要で、自分が任命されたのか
PdMがプロダクトマネジメントに集中できるようにピープルマネジメントの役割をEMに委譲
アソビューの過去の体制では、PdM(プロダクトマネージャー)がプロダクトマネジメントをしつつ、ピープルマネジメントをしていました。
ピープルマネジメントも重要な役割であるため、プロダクトマネジメントに集中することが難しい状態でした。
そのため、ピープルマネジメントの部分はEMに委譲する方針となったことが、私がEMになるきっかけとして大きかったです。
EMを始めた経緯
VPoE(Vice President of Engineering)より「7月からEMをやってみませんか?」と打診がありました。
少し考えつつも「やってみます!」と回答しました。
人員配置について決める社内会議でも「近藤さんがEMになる方向で進めていきますね!」とスムーズに進みました。
期の変わり目で部署異動と共に始まる
7月は弊社では期の変わり目になります。
今までの開発部署から別の開発部署に異動もあったため、7月から一気に変わると大変だろう。という配慮をいただき、5月から部署異動とEMの準備期間が始まりました。
EM任命前に準備期間があり、その期間でやったこと
EMの役割を持って悩んだこと
コードとの距離感
部署異動してからすぐにコードを書くことがほとんどなくなりました。
コードを書いて動くとすぐに結果を得られるので満足感を覚えやすいです。
しかし、組織改善はすぐに結果が出るものではなく、しばらく経ってから結果が出てくるものです。
自分はコードを書いていたい人のため、今でもムズムズします!
組織改善のために自分がやれること(何していいのか分からない)
正直なところ、何をしたらいいのか分かりませんでした。
そこで以下のことを考え、チームごとのMTGに全て参加して観察しました。
- 組織改善するためには何が必要なのか?
- 今の組織の課題はなんなのか?
- 部署異動後なのでメンバーの信頼を得ないといけない
見えてきた課題
プレイヤーとしての視点とEMとしての視点の違い
開発リーダーの時はプレイヤーをしつつ、スクラムを運用しているため、自分のプロジェクトのことしか見えませんでした。
視点の対象は自チームのメンバーであり、広くても自部署の別チームの動向程度の範囲でした。
EMの目線では、複数チームの体制やメンバーの動向、みんなが円滑に作業できる環境であるのか。
他部署の大まかな動きも把握しつつ、どうしたら開発組織で成果を出していけるのか。
俯瞰しつつ、大きな課題が発生したらフォローに入ったり、任せてみたりと、成長を促す役割も必要なのだと感じました。
肩書きがないから話せること(話せないこともあって難しいこと)
自分は正式に任命されていない時はEMとメンバーとの橋渡し的なイメージでいました。
そのため、あまりお互いに意識せずに1on1で雑談したり、チームの課題や会社の課題を聞いていました。
EM内での情報に触れる機会が増える中で、まだ正式に決まっていないことについてはメンバーに共有できない場面もありました。
意識したこと/実践したこと
1on1の入り方
新しい部署に異動したため、まずは自分のことを知ってもらうために以前のブログでも紹介させていただいている「4つの私」を実施しました。
これは、「今までの私」「客観的に見た私」「最近の私」「実は私...」という4つのテーマで自己紹介を行うものです。
tech.asoview.co.jp
別日の1on1では自チームの課題を聞いたり、プライベートな雑談をしたり、今の作業で困っていることを聞いたりしました。
相手に話してもらうことが大事なのですが、自分の作業の相談をして一緒に考えてもらうこともあったり、あまり壁ができないように心がけています。
しかし、いつも自分が話しすぎているのではないか?と反省しています。
チームを観察する
チームのMTGに参加し以下のことを観察しました。
- 誰が発言が多いのか?
- 技術的なリードは誰か?
- 見落としがちな部分に気づいてくれるのは誰か?
- みんなで議論できているのか?
部署のオンボーディング資料作成
新しい人が入ってきた時に参照する情報として、全社のオンボーディング資料があります。
全社のオンボーディング資料では部署内で知っておいて欲しいことや実施しておいて欲しいことの記載はありません。
そのため、オンボーディング担当者によって説明内容がバラバラでした。
業務を進めるうえで、知っていることや申請などの対応にバラつきがあり、そこにコミュニケーションコストがかかってしまう点を課題に感じました。
それを改善するために、部署用のオンボーディング資料を作成し、オンボーディングを実施するようにしました。
実施した結果、認識のブレが少なくなったり、必要な申請が漏れなく実施でき、円滑に業務に入れるようになりました。
まとめ
振り返ってみて思うのは、EMは意識した時から始まっていたんだな。と思いました。
EMという肩書きがなくても意識して行動することで、メンバーにも伝わって認知してもらえるものなんだと感じました。
- やってよかったこと
- 部署のオンボーディング資料作成
- 微妙だったこと
- PdM、EM、開発チームの役割を最大化するために役割を分けるのを急ぎすぎて一時的に歯車がうまく回らなくなったこと
- 密に連携をとるために全員との1on1を設定し、予定がビッシリになって身動きが取れなくなったこと
- 今ならこうやること
- PdM、EM、開発チームがそれぞれどうなっていくべきか対話を重ねてから動き始める
- 各チームにリーダーがいるため、EMはリーダーと隔週で1on1して、メンバーとの1on1の頻度は月1にする
今後は、どのようにすれば組織でプロジェクトの成果を出せるようになるのか考えながら組織作りをしていきたいと思います。
正解があるものではないため、Try & Errorを繰り返しながらやっていきます!
さいごに
アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています!
ご興味がありましたら、まずはカジュアル面談からご応募いただければと思います!
アソビュー!の技術情報を発信する公式アカウントもありますのでぜひフォローお願いします! https://twitter.com/Asoview_dev