メルペイに入社して 8 月で丸 3 年経った。そして 2020 年 10 月からは Engineering Manager (= EM) をやっていてもうすぐ 1 年になる。「EM って何やっているの？」とよく聞かれるし、自分もやる前は正直そう思っていた。「コードを書かなくなることへの恐れ」もあったが、色々と見えてきたこともある。この 1 年間を振り返ってみる。

現職における EM の定義

会社によって EM の定義は異なると思う。メルペイにおける EM 定義は下記の通り。

  • 役職ではなく役割 (EM に限らず Manager は役割)
  • 戦略・業務・チームをマネジメントして成果創出をする
  • 主に Who, Where, How に責任を持つ
  • 縦軸 Project に対して、横断的に関わる (下図参照)

図:縦軸 Project に対して、横軸 Function で横断的に関わる

期待値は Engineering Ladder 1 の [Engineering Manager Skills] に記載がある。他にも Manager 全般の定義もあるがここでは割愛する。

私は Frontend チームの EM。2021 年 8 月現在、総勢 14 名が在籍しているチームで、EM は私を含め 2 人、業務委託＋インターンの方も在籍している。私は 5,6 人を直属のレポートラインとして見ている。

EM の中にも色々なタイプの人がいる。EM 兼 TL2 としてプロジェクトに入ってガッツリコードを書く人、チームマネジメントやプロジェクトマネジメントに比重が大きい人、など様々だ。

はじめの数ヶ月は EM : TL = 5 : 5 くらいの割合の前提でスタートした。コードを書かないとエンジニアとしての成長が止まるのではないかという懸念があり、ある程度プロジェクトにもコミットすることを望んでいたし、そのときの会社の状況だとそれを期待されていた。しかし実際やってみると時間が足りない。早々に TL としてやっていたことを他のメンバーに委譲し、平均すると EM : IC3 = 9 : 1 くらいになっている。 時期によってムラもある。四半期ごとに評価をしていて、四半期を跨ぐ前後の一ヶ月は特に EM の比重が大きい。

EM を志したきっかけ

EM がいる会社が現職が初めてだった。前職・前々職は少人数のスタートアップだったり個人プロジェクトで、各自がセルフマネジメントすればよいという考えだったので、人や組織をマネジメントしている人がいるということ自体が新鮮だった。

私が入社する 1 ヶ月前の 2018 年 7 月辺りから PM-TL-EM 体制がスタートしていた 4。実はまだこの体制が始まって 3 年ほどしか経っていない。メルペイの立ち上げ、サービス急成長に併せて体制が見直されブラッシュアップされてきた。サービスが非連続な成長をするためには組織構造やそこにいる人の変化や成長が不可欠であり、それを支えるマネジメントの役割が重要であることはマネージャーでない自分から見ても感じ取れた。

色々懸念があり、EM になるかどうか半年以上悩んでいた。しかし、ある EM と 1on1 したときに「前職で EM をやれる機会があったけどやらなかった。今思うとやっておけばよかった」という話を聞いた。自分が興味もあって、組織としてもそれを求められている、今まさに Just Do It だと思った。

コードを書けなくなることの恐れ

「マネージャーになるとコードを書けなくなる」というのは、エンジニア界隈だとよく言われていることである。技術力の向上のために、手を動かす過程で技術の深堀りをしていくことが板についていた私もそう思っていた。コードを書く時間が明らかに少なくなるのは事実である。しかし、技術力の維持・向上は、必ずしもコードを書くこと・プロダクト開発することだけではないということがわかってきた。

EM 経験で得たもの・失ったもの

マクロ視点

EM は複数プロジェクトに横断的に携わるため、関わる人数と職種が圧倒的に増える。経営に近い VP, Director などとの接点が増えるのも大きな変化だ。各職種がそれぞれのプロフェッショナルとして連携しているので、会話をするに際に必要となる前提知識が自ずと広くなる。

まず第一にやったことは、Slack やドキュメントを読んで常に状況を理解しておくことだ。プロジェクトに関わる雑談チャンネルや開発チャンネルをはじめ、一見関係ないと思われそうなチャンネルにもジョインしてウォッチする。また、社内には様々なドキュメントやスライドが膨大に転がっている。それらを能動的に探して読む。これまでは読まなかった書籍も読むようになった。エンジニアリングだけではなく、ガバナンス・経営戦略・HR・PR などこれまでは触れてこなかった領域にも踏み込むことになった。

こういった取り組みを通して、組織を俯瞰的にみれるようになってきたのが一つの収穫だった。TL や IC としてあるプロジェクトの内側から見えていた世界と、外側から見える世界は異なる。何か事が動く時、プロジェクト内外の事象が関連している。しかし、内側からみただけでは理不尽に思えることもあるだろう。あらゆる情報を理解し、それをメンバーが自分ごと化できるように伝えられる準備を普段からやっておく。経営陣が考えていることをメンバーに伝えるのも重要な役割だと思う。

組織学習と疑似学習

個人が成長することは組織に変化がもたらされ、環境が変化した結果、またさらに個人の成長に影響するというサイクルを一般に「組織学習サイクル」という。マネージャーは個々の育成を通じてこのサイクルを効率化することでチーム力の強化を図る。

組織学習が捗ると EM 自身の疑似学習が捗るようになる。実際に手を動かしていなくても、組織の技術レベルが向上するとそれに関わる EM 自身が触れる技術レベルが上がるからだ。マネジメントを追求することで結果、エンジニアとしての技術力向上にも寄与するかもしれないという点は、以前にはなかった観点だった。

言語化力

他人に動いてもらうために考えていることを言語化して伝えることは、マネジメントにおいて重要な能力の一つだと思う。伝わるかどうか、動いてもらえるかどうかは伝え方次第である。メルペイを始めメルカリグループには多くのマネージャーがいて、日々学ばせてもらっている。一見シンプルに見える内容でも、表現の仕方やタイミングに気を配り戦略的に言語化しているのを間近にみて、それが効果的だったケースやそうでなかったケースもあり難しさを感じつつも、経験値が蓄積されている。

言語化力は言語力よりも重要だ。EM になる上で英語力も一つの懸念ではあったが、どんなにスラスラと英語が話せても、複雑で整理されていない内容だと伝わらない。多少英語の文法が間違っていても、シンプルに言語化されいて主張が明確であれば相手に伝わる。日本語でも自分の中で整理しきれてなくてうまく伝えられないことがある。結局、整理して自分の言葉で伝えられるかどうかが重要だった。

メルカリグループはエンジニアの約半数を外国籍メンバーで占めている。日本人にとって英語はコミュニケーション難易度を上げる一つの要素ではあるが、それとセットで言語化力も欠かせないと思う。

退化した能力

上記のように、技術力の底上げに繋がる(かもしれない)成長を実感している一方で、明らかに退化していることもある。肌感やコードを書く体力だ。スポーツで毎日練習しないとすぐ鈍ってしまうそれと同じような感覚。久しぶりにコードを書いたときの疲労感が半端なかったり、デバッグに時間がかかったりする。時には手を動かす、プライベートプロジェクトなどで定期的に素振りしておくなどが必要。

まとめ

いちエンジニアとして、いちビジネスパーソンとしてマネジメントを経験することは見識を広げる一つの手段となると強く思う。やってからはじめてわかることがある。コードを書けなくなることの恐れに関しては、それを差し置いてでも得られるものは大きかった。向き不向きもある。やってみて合わなければ戻ればよいので、何か不安があるならばとりあえずやってみるとよいと思う。

これらは、とある企業のとある EM の視点での実体験であり、社によって EM/Manager によって感じ方や視点が様々だ。社内外の色々な人とマネジメントに関する話をしていきたい。

  1. Mercari Engineering Ladder https://engineering.mercari.com/ladder/ ↩︎

  2. TL = Tech Lead。What,How,When に責任を持つ役割 ↩︎

  3. IC = Individual Contributor。EM,TL 以外のエンジニアを指す ↩︎

  4. メルペイEMが語る、開発組織の立ち上げから現在までの軌跡 https://logmi.jp/tech/articles/322239 ↩︎