LoginSignup
19
3

既存のチームに新しいエンジニアリングマネージャーとして入りキャッチアップするためにやったこと

Last updated at Posted at 2023-12-23

はじめに

この記事は「LITALICO Advent Calendar 2023」カレンダー2の23日目の記事です

株式会社LITALICOの @KakkiiiiKyg です。エンジニアリングマネージャー(以下、EM)を務めています。本記事では、私が既存のチームに新しくEMとして入った際に、情報のキャッチアップのために行ったことについて書きます。

昨年もLITALICOのアドベントカレンダーを担当させていただき、その際には新しくチームに入っていただいた方のオンボーディングの取り組みについての記事を書かせていただきました。

今年は立場が逆転して、自分が新たに既存のチームに入るという経験をしました。また元々EMを務めていましたが、新卒入社後から同じチームで働き続けそのチームでEMとなったため、環境が変わるのは私としては初めての経験でした。なおかつ、EMとして既存のチームに入るのは不安な部分も多かったので、そのような方にとって少しでも参考になるような記事が書けたら嬉しいなと思います。

前提

  • ここでいう「キャッチアップ」とは、参画から2〜3週間くらいで行う情報のインプットのことを想定して書いています
  • 既存のチームは大体エンジニア5名、PdM1名、デザイナー1名と考えていただけると良いです

キャッチアップするためにやったことの概要

やったことは大きく分けて2つです。

1つ目は、自身への期待値を明らかにしていくことです。EMはやることが明確に決まっているわけではなく、事業ドメインやプロダクトの状況や特性、チームメンバーの専門性など多様な要因によってやることが変わると思います。

LITALICO Advent Calendar 2023の関連する記事

そのため、このチームでは自分が何を求められているのかを確認するようにしました。

2つ目は、これから実務を行っていく際の前提となる知識のインプットです。事業ドメインやプロダクトに関すること、技術に関すること、チームや一人一人に関すること、、など色々インプットしなければならないことがありますが、事業ドメインは経験のあった領域だったり、一緒に働くことになる方はこれまで社内で一応面識はあった方々だったりしたので、ここでは最初の2~3週間で主に時間を掛けたプロダクトに関することと技術に関することのインプットについて書けたらと思います。

自分に対する期待値を明らかにする

自分に対する期待値をチームメンバーの方々と上司それぞれから確認しました。

チームメンバーからの期待値

チームメンバーの方、お一人お一人と1on1をさせていただきました。初回はお互いの近況をざっくばらんに話しつつ、

「私に期待していることを教えてください」

という質問をするようにしていました。人によってはどのように答えたら良いか分からない方もいるので、その際には「私に手伝えそうなことはありますか?」「働いていて何か気になっていることはありますか?」など、聞く切り口をその方の日々の悩み/困り/モヤモヤに変える工夫を行っていました。すでに言語化されているものはもちろん、まだ言語化されていないものも含めて、チームメンバーの方は私がどのように動くことを期待しているのかを掴めるよう意識していました。

上司からの期待値

上司からもEMとして私が何を期待されているのかを聞き、期待値を擦り合わせました。これについては、私の方から能動的に行動を起こしたわけではなく、上司から期待値を擦り合わせる場を用意していただいたため、場を活用させていただいた形でした。

自分に対する期待値を明らかにすることは、新しくチームに来たときのみではなく常に大切なことですが、今回の既存チームに新しく入っていくという経験を通して大切さを再認識しました。つい分かっている気になりがちな部分ですが、今後もしっかり言葉で擦り合わせていこうと思いました。

プロダクトの前提知識のインプット

次は前提知識のインプットで、まずはプロダクトについてです。プロダクトのドメイン/戦略/戦術についての理解と現時点の機能について理解を進めていきました。

ドメイン/戦略/戦術

ビジネスモデル、事業KPI、プロダクトKPIから押さえていき、どのようなプロダクトなのかを理解していきました。ただここについては、事業ドメインが経験のある領域だったので、キャッチアップという意味ではあまり時間は掛かりませんでした。

その後、プロダクト戦略資料、その元となったであろう事業戦略資料、開発計画資料など、戦略戦術に関する資料を地道に読み込んでいきました。体系的に整理されているわけではないと予想していたので、方針としては片っ端から関連資料をもらい、各資料がどのような資料かだけざっと確認した後に手元でインデックスしておいて、戦略の柱になっている部分から理解を深めていくようにしていきました。加えて、PdMの方との1on1の中で質問していきながら疑問点を解消していきました。

プロダクト機能

次はプロダクトの機能についてです。ビジネスモデルやプロダクトKPIを押さえていたので、そこからまずはKPIに直結する機能から実際に触りながら把握していきました。

検証環境もありましたが、後述する技術の理解の部分で一緒にアプリケーションコード等も確認したくなるので、開発環境構築を行なって、そこでひたすら触るようにしていました。

また、明確な競合がいるプロダクトになるので、確認できる範囲で、各機能について競合プロダクトも一緒に確認し差分を整理することで現状の機能について理解を深めていきました。

技術の前提知識のインプット

技術については、使用されている技術についてまずは理解を深めに行き、その後に現在の負債状況を把握しに行きました。ここでも方針は、ある資料を片っ端から集める、確認すれば分かる事実を集める、それらを積み重ねて自身の見解を持てるようにしていきます。

使用技術

このチームはフルサイクル型の開発スタイルを取っており、フロントエンド/バックエンド/インフラ全てを見ているチームになります。そのため、その全体感を押さえにいきました。

インフラ構成図があったのでそこから確認しました。幸い全く使ったことのないものはほとんどなく読み解けたので、次にアプリケーションコードを読みにいきました。プロダクトについてインプットしたことからコアとなる機能に当たりがついているので、それらの機能を中心に処理の流れをコードベース上で追っていって確認していきました。他業務も兼務しているため、私自身が開発業務を行う予定は今のところないのですが、負債状況や開発者体験を実感するために必要な作業だと思っています。余談ですが、このチームはコード上にコメントをしっかり書く文化があり、とてもコードリーディングが捗りました。先人たちに感謝ですmm

DBのテーブル構造についても、同じようにコアとなるテーブル群から把握していきます。実データも確認できる範囲で確認し、どんなデータをどのくらい保有しているのかを肌感覚を持って理解していきました。

この辺りの自分が触ったことのないプロダクトのつくりについて理解を深めていくやり方は、人によって流儀が違うと思うので、色々な人の型を知りたいなと思いました。

負債状況

次は負債状況についても押さえにいきました。具体的にいうと、ブラックボックスになってしまっている箇所はどれくらいあるかを確認します。チーム歴の長いメンバーの方々を中心にヒアリングさせていただき、明確に認識している負債についてだったり、感覚として開発しにくいところや新しい人に説明するとなったら説明が難しい箇所だったりを確認していきました。そしてそのヒアリングに照らし合わせて、過去の障害の記録やクローズされていないイシューなどを読み込んでいきました。ここの解像度をさらに上げてしっかりマネジメントしていくのは、今後の課題だなと思っています。

おわりに

初めて、既存のチームに新しくEMとして入った際にキャッチアップのためにやったことについて書きました。

書いてみると、気を衒ったことはやっておらず、ひたすら資料をかき集めて一つ一つ読んでいくという至極当たり前のことしかしていなかったです。オンボをする側から受ける側になって「新規参画者が各情報にアクセスできる状態になっていること」が大切だなと感じました。

また、記事内には記載はしませんでしたが、チームメンバーの方々には最初の数週間は特に質問をしていました。忙しいのに嫌な顔一つせず教えてくれて本当に感謝です。

「はじめに」でも書いたように同じような状況の方の少しでも参考になっていただけると嬉しいです。

明日のLITALICOのアドベントカレンダーは

の3記事です。お楽しみに!

19
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
19
3