エンジニアリングマネージャーのオンボーディング

hidenorigoto

twitterにて、「エンジニアリングマネージャーのオンボーディングってどうしてる？」というつぶやきを見かけたので、私がやっていることをざっくり書いてみます。

以下、「自分が新しい会社に入社した際に、自分がオンボードされるためにやること」という目線で書きますが、私が実際に転職して使ったのは現職への1回くらいのものです。しかし、前職で多くの中途入社EMをオンボードしてきており、基本的には同じ考え方をベースに、入社者の特性・期待値に合わせてアレンジしていました。その経験からは、そこそこコンパクトでワークする内容かとは思います。

期待値を知る

これは私のマネジメントスタイルからくるものですが、「1にも2にも、まず期待値」だと考えています。別の言い方では「役割」と言われるかもしれませんが、それよりも抽象度が高く、また広い範囲のことを含みます。

  • 最低限何を行う必要があるか

  • 主導して解くべき問題・課題は何か。期待されるタイムラインは。

  • 物事を推進する場合に、どのように行動すべきか

  • 半年後、1年後に、マネジメント範囲に対してどのような状態が期待されるか

  • 半年後、1年後に、組織の中でどのような立ち位置になっていることが期待されるか

オンボーディングされる側の状態によっては、具体化した期待値を設定する必要があるかもしれません。私の場合はある程度抽象的なまま期待値を受け取った後、自身のインサイトによって味付けした目標やビジョンを設定し、それを用いて期待値をすり合わせるということをやります。
私がオンボーディングする側だった場合、こちらの期待値リストを渡し、それを元に入社前・後や週次の1on1で理解を深め、すり合わせを行っていました。

場合によっては、「期待値などあたえられず、好きなように良い感じにやってほしい」と言われることもあると思います。これは実は難易度が高く、ノーヒントで自身の組織に必要なものを見つけ出し、取り組んで成果を出せということです。私なら、以降で記載する別のインプットを得て慎重に自身のビジョンを描いた後、やはり一定の「握り（期待値の確認）」は行うと思います。

課題を知る

期待値と合わせて重要なのが、取り組むべき問題・課題を知ることです。会社ですでに問題・課題が顕在化しており、これを解くことを期待されている場合、当然それを知るべきです。

注意が必要なのは、「問題・課題を与えられたまま受け取って、すぐに解決に飛びついてはいけない」ことです。これが問題だ、課題だと言われているが、本当に問題なのか？ どのように問題となっていて、どういう悪影響を及ぼしているのか。それが相対的にどれくらいインパクトのある事象であり、解決することで数値的に何がどの程度良くなるのか。これらを自身で収集し理解し、「自分が解くべき問題である」と腹落ちできることが重要です。
この問題・課題理解の過程で、時に、問題の原因が他の箇所にあることが分かったりします。原因が他の箇所にあるにも関わらず、与えられた問題だけを解こうとすると、解決が局所最適になってしまいますし、組織に問題の根源が残ったままなので、再発したりもします。

会社を知る

当たり前のようにも思いますが、会社や組織についても十分なインプットが必要です。期待される成果を出すために直接関わりがあるチームや人を知るのは当然として、事業の全体像を理解するためにどのような組織になっているのか、どのような人が担当しているのかなどを、可能であれば直接話しをして知っておくことが重要だと考えています。
このような「組織と人を知る」活動は、単に自分の知識を増やすことだけにとどまらず、自身や自身のチームのプレゼンスを高めることにも繋がります。社内での課題というのが、最初からあるべき人（＝自分）のところにあるのは常ではなく、他のチームの困りごとがきっかけで自分のチームの課題が浮かび上がることもあります。そういった場合に、自分やチームにすぐに相談してくれる関係性も大切ですよね。

事業を知る

これについては会社やそのサイズなどによって変わってくると思いますが、私自身はいずれにしても事業についての理解を自分の基盤にするスタイルなので、知りに行きます。事業を知るというのは、プロダクト自体を知り、その使い方といったユーザー側の知識も含みますし、事業KPIといった数値面も含みます。さらにより重要なのは、どのようなビジネスモデルなのか、どのようなコスト構造になっているのか。そこでの自社の強みや、これからの戦略といったことの理解です。
エンジニアリングマネージャーは、経営やプロダクトサイドからくるチームへのリクエストを、チームメンバーのコンテキストでスッと理解できるように翻訳するという仕事が多々発生します。この際、事業をしっかり理解していると、経営やプロダクトマネージャー側の要求の背景をスムーズに補完し、自チームの役割へと落とし込むことができます。
また、課題に取り組む際のインパクトや優先順位の判断のためにも、自身で事業をよく理解しておくことは役立ちます。
エンジニアチームの成果を事業と接続させたいのであれば、この事業理解が結果を左右する最も大きな要素になると思います。

ソフトウェアを知る

中途入社のエンジニアリングマネージャーにとって、ソフトウェアとどの程度の距離感で付き合っていくのかは早期に考えておくべきテーマかと思います。もちろんこれも、会社の方針や期待値によって変動するものですが、私個人の考えを言えば、エンジニアリングマネージャーはすべからく、チームや組織が扱うソフトウェアに対して、アーキテクチャや設計方針の意思決定をしたり、そういった議論をリードできる程度に理解しておくべきだと考えています。
できるだけ大きな裁量をチームメンバーに持たせ、意思決定も含めて任せていく方が良いマネジメントとされますが、だからといって、エンジニアリングマネージャー自身が何の肌感覚も持っていないと、他のチームからのリクエストや何らかの方針議論の際に、自分では何も意見を言えないマネージャーと成り下がってしまうと思います。これは単なる御用聞きであって、マネジメントしていません。チームメンバーからも不要だと思われるでしょう。コードを書いたり、細かいレビューまで行う必要はないと考えますが、チームのソフトウェアがどのようなものなのか、それがどのような課題を抱えているのか等、自分の考えとして持てる状態が必要だと思います。

この状態を作るためには様々アプローチがありますが、やはりしっかりコードを読み、何らかの小さいタスクをこなしてデプロイまで自分で行ってみる、といったことを繰り返すのが近道だろうと思います。

チームを知る

順番として最後に記載していますが、決して優先度が低いわけではありません。エンジニアリングマネージャーのメインの仕事は、チームの成果を最大化することだからです。ここを疎かにして他のことに時間を使っているようだと、多くの場合「期待値とずれている」となってしまうと思います。

いいなと思ったら応援しよう！