hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

EMになりたての頃の自分へ伝えたいこと

f:id:katsumata_ryo:20211211164854p:plain

(こちらは hey Advent Calendar 12 日目の記事 と Engineering Manager Advent Calendar 2021 カレンダー2 15日目の記事です)

数年前のかつまたさん、元気ですか。私は2021年からきたかつまたです。こんにちは。

エンジニアリングマネージャー(以下、EM)になったばかりの君へ、今の自分からアドバイスを書きたくて手紙を書きました。

(本当は「EMになりたてのあなたに伝えたいこと」というタイトルで記事を書こうとしました。でも人にそんなアドバイスなどできる存在だろうかという気持ちがもたげてしまい、過去の自分に手紙を書くという逃げをしました。)

前提の共有

プロダクト開発をしていてチームのみんなの前提が揃っていることが大事なことはきっと感じていると思うから、この記事も簡単にだけど前提を合わせつつ手紙を書いていきます。

■前提

  • 書き手はソフトウェアエンジニア(バックエンド)出身のEM。
  • 過去他組織でのマネジメント経験はなし。
  • あくまで現組織の N=1 な内容なのでそんなこともあるのかぐらいで読んで欲しい。
  • この記事に書いてあることはできているわけではない。日々できてないことを感じている昨今である。

では早速本題に入ろう。

リーダーからマネージャーへ

きっと今プロダクトをチームのみんなと開発しているところだと思う。バックエンドのメンバーやエンジニアさん・プロダクトマネージャーさん・デザイナーさんたちと一緒にプロジェクトをリードしてくれているタイミングかもしれない。

リーダーからマネージャーになるタイミングで起こっていること

f:id:katsumata_ryo:20211211212743p:plain

今のあなたにはこんなことが起こっているのではないでしょうか。

  • 今まで実装タスクをメインにしていたところからチームをうまく回すためのタスクが増えている
  • 例えば、
    • プロダクトマネージャーさんやデザイナーさんとMTGをする機会が増えたり
    • チームのメンバーが仕事を進めやすいように交通整理をしたり
    • プロジェクトの状態を連携したり課題があったときに上長に連携したり
    • するとコードをバリバリ書く時間が減って自分がボトルネックになる瞬間を感じたり
    • ボトルネックになると困るタスクを持たないようにしたり、レビューを厚めにするようにしたり
  • その他もしかしたらこんなことも増えたりしているかも
    • 採用面接に関わる機会が増えたり
    • チームの生産性計測や向上を考えたり

どうでしょう、当たってるでしょうか。

チームの中でリードを取っていくとおそらく実装者の時見えていたものとは違うものが見えて来る。その度に「必要に感じられるもの」に対してTryを重ねてきたのではないでしょうか。

きっと、リードを取っていくことで「課題を見つける」→「自分が主体的に動くことでスループットがよくなる」という体験にモチベーションがあがった事も多かったのではないでしょうか。

「マネージャーに!」と声がかかったあなたのそんな姿に、チームのみんなや上長は信頼を感じてくれているのではないでしょうか。

EMになるあなたへ

リーダーになったときはものを作っていく仕事がメインだったところから、それをなめらかにする仕事が増えたのではないでしょうか。きっとコードを書く時間が減ったなと感じましたよね。

これからEMになるあなたに1つまずお伝えしたいことは、EMになることでその流れはさらに強くなるということです。

自分がEMになった際、その流れを自分で感じ悩んでいく中で考え方をスイッチしたポイントがいくつかあります

  1. 先頭をきろうという気持ちから先頭をきってもらう気持ちにかわった。
  2. チームの成果を自分の成果とちゃんと紐付ける。
  3. プロダクトをつくるという関心からプロダクトをつくる人への関心へ。
  4. 悲観的に見て最後は楽天的にまとめる。

1つずつ書いていきます。

1. 先頭を切ってもらう

リーダーのときは自分で頑張って解決をしていく方向に頭を使うことが多かったです。ですが、マネージャーになってからは先頭を切ってもらう人がどうしたら仕事がしやすくなるかというところを考えるようになりました。

先程書いたとおり自分がボールを持ちすぎると自身がボトルネックになってしまいます。いままでとは見ている範囲が広がっていくため、当然スタックしやすくなりますよね。なるべくボールを持たないようにしたいものです。

f:id:katsumata_ryo:20211212021151p:plain

一番自分が重要だと考えているのは、メンバーのみんなに「裁量を増やしてもらう」ということです。そのために先頭を切ってもらう機会を作りたいと考えています。

裁量と書くとちょっと重いのですが、自分が見れる範囲が増えたりできることが増えたりするとそれによって給与も増えやすくなります(会社の状態に大きく依存すると思う)。理解できることが増えたり、判断できることが増えると仕事が楽しくなりますよね。もちろんその分大変なことも増えるかも知れません。すべての人がこの考え方に共感してもらえるわけではないかもですが、基本的には一人ひとりとコミュニケーションをしながら裁量を増やしてもらうことを目指しています。

2. チームの成果を自分の成果とちゃんと紐付ける

色々とメンバーに任せられるようになるとあなたなしでもチームが自走していくようになります。これは1つのチームとEMの成果です。一方で自身のエンジニアとしての関わりやプロダクトに対しての関わりは希薄になっていきます。

すると、プロダクトは進んでいきますがそこに貢献している実感がなくなってしまい「自分がいなくてもチームは回る」「自分は必要ないのでは」という発想になることもあるかも知れません。これを自分は無力感の波とよんでます。新しい領域に飛び込むたびに何度もやってきます。

ここで大事なことは

  • チームが上手く回っているのはチームのみんなとあなたが頑張ったからであるという認識をする。
  • チームが上手く回るようにあなたが頑張ったことは、仮説→実施→結果 をちゃんと振り返って持ち運び可能な学びに落としておくこと。

この2つです。

「チームが成果を出してくれているのはあなたの成果ですよ」といってくれる上長がいたらあなたの環境は最高です。もしそういう上長がいなくても自分でモチベーションを保てるようにしておくことは大事なことです。

3. プロダクトを作る人への関心

自身がプロダクト開発で機能を作ったり改善したりするのを楽しいと感じお仕事をしていました。機能を作って使ってもらうことに少し誇らしげに慣れたりするのも楽しさでした。

これは今でもソフトウェアエンジニアとして気に入っていることの1つですが、マネージャーの立ち位置としては、「関わっているプロダクトを前により推し進めるには」というのが観点になります。

自分でものを作っていきたい気持ちもありますが、実際にプロダクトを作った人の生産性が上がっていけばより多くのものがユーザーへ届くようになります。自分はここは割り切っておまかせしてしまって、その人達のスループットを落とさないように(上がるように)動くことを意識するようになりました。

4. 悲観的に見て最後は楽天的にまとめる

これはスイッチしたと言うよりもより意識するようにしたポイントという感じです。

プロダクト開発ではインセプションデッキで「夜も眠れない問題」について話し合ったりします。それと同様に、一つ一つの物事に最悪どうなるんだっけ?というポイントを意識することが増えた気がします。

EMの関心領域は人によってグラデーションがあると思います、概ね 「人・プロダクト・組織・技術」が大きな括りで関心領域と言われています。これらを全部詳細にみるのは広範囲すぎて全部に深入りするのはあまり得策ではないと思っています。

f:id:katsumata_ryo:20211212014819p:plain

やることは無数にあるため、やらないことを決める必要があります。

そのときに課題の優先順位付けをしていく中でMAX悲観的パターンを想定してみて危険領域に入ったときのフックづくりをするようにしています。

実際に悲観シチュエーションに突入した場合、「悲観だー」と嘆いていても何も解決しません。ひたすら行動していくしか無いので淡々とやっていくことと、楽観的でいることを意識します。EMが「悲観だー」と嘆いている時周りの人はどう感じるかを想像してみるとその大切さが伝わるような気がします。

正直、正解がないことに立ち向かう機会が増えるので自分は(能力のなさが多分にあるとおもいつつ)うまくいかないことが多いと感じています。その都度「向いてないかもしれない」という考えが頭をもたげるんですが、あんまり向いているか向いていないか深追いすることに意味がないように感じています。

結局目の前に課題があってそれとどう向き合っていくかの連続という感じなので「EMをやめてくれと言われてないってことは続けてて良いのだろう」ぐらいな感じで、自問はしつつ深追いはせずに楽観的にやっていくのが良い気がします。

自分が考えるやりがい

ソフトウェアを作っていた立場からマネージャーになると、やっていることは全然違っているように感じるんですよね。最初はやりがいを感じるよりもこなす・ちゃんとやるっていうところに集中してしまうかなと思います。 今私がEMに対して楽しみを感じている部分、やりがいと感じている部分について書いて終わろうと思います。

自分がやりたかったことが実現されていく

もともと出自としてはバックエンドのエンジニアなので自分の手でものを出したいという気持ちはあります(もしくは単純に実装したい)。ですが、チームという単位では自分が一人でアレコレするよりも確実にたくさんものがリリースされますし、品質の良いものがユーザーに届きます。

それってすごく良いことだとおもっていて、自分はそこのスループットがなめらかになるようにしたり、よりよく流れていくようにみたいなところでサポートできることに喜びを感じているところがあるなと気づきました。これがひとつEMとして関われる楽しい仕事の角度かなと思います。

目的を共にしている人とのコミュニケーションを楽しむ

EMになってからコミュニケーションの窓口になっていくことが増えました。しかし自身が思っていたよりコミュニケーションが増えることは苦になりませんでした。

単に雑談が好きというというのは元の性格としてあるかも知れません。チームで活動しているとチーム内外で時々コミュニケーションが滞留してしまうことがあります。そういうときにコミュニケーションに介入して落とし所を見つけていく動きがみんなの目線が揃っていく感じがして好きだったりします。よく私は「課題VS私たち」という言葉を使います。みんなもともと同じ目的に向かって集まった人たちなので目線って合うはずですよね。

その中でコミュニケーションの流れを作って整理したときにうまく開発が進んだ時喜びを感じるタイミングがあったりします。

課題と仮説の適用箇所がある

今働いている組織はこれから色々な仕組みを充実させていくぞというフェーズです。なのでまだまだやらなきゃいけないことがあります。自ずと解決しなければいけない課題がたくさんあり、それを誰かがやらないといけない。

最近、採用や組織というところに関心を持つようになりました。知識は本などで得られますが、その得たものを適用する場所は課題がないと適用して学びを得るということはできません。

EMにはこの課題と適用箇所がたくさんあるので飽きるということがなく、会社のフェーズも相まってこういう環境の中にいられるのはなかなか得られる経験ではないと感じるのでありがたいことだと思っています。

チームメンバーの変化を感じられるのが嬉しい

マネジメントの喜びはこれに尽きるかと思うのですが、一緒に働いている人の変化を傍で見ることができるのはすごく嬉しい。それ自体がすごく喜びだと感じています。

色々書いたけれど

冒頭に書いたように、マネジメントを任され始めた今は色々タスクを抱えているところにEM業務が入ってくることに困惑してるんじゃないかと思います。まずは少しずつ自分の体がどうやったら空くかということを考えて実行していきましょう。体が空くと自然と新しいものがきっと入ってくるはず。

わたしの経験なのであなたの参考になるかわかりません。自分の場合EM業務を体験できていることは、自分の認識の壁を常に破って広げられ続けている感覚があります。そういう環境がそれじたい楽しみに足るものかと思っています。

というわけで、色々書きましたが! ぜひ新しいことの一つ一つを楽しんでくださいまし。身近にEMの先輩がいたらやったこと感じたことを壁打ちすることを定期でやると良いんじゃないかと思います。

あなたのEMが大変ながらも楽しいEMになることを!