見出し画像

「EMの仕事って何? 評価するのが不安です。」 EMの卵がメルカリのEMに聞いてみた 【Engineering Manager】

こんにちは。M&Aクラウドという会社でエンジニアをやっています鈴木(@yamotuki)です。EMの卵です。
”卵”というのは、まだEngineering Manager(以下EM)業務をやっているわけではなくて、上長から「将来的にやって欲しいんだよね」と言われている状態だからです。これから行こうするキャリアの先があんまり分からないから不安なわけですね。

そういうわけでTwitterでこんな感じで呟いてみました。

それなりに反響をいただき、フォローしていただける方も少なからずいました。
そこで、思い切って「話を聞かせてもらえないか」とDMを送ってみたところ、何人かからお話を聞かせて頂けることになりました。

というわけで、最初にお話を聞かせて頂いたのは、メルカリの Hidenori Goto さんでした。

お話しした内容は私だけでなく、すでにEMをやられている方、これからなろうという方の学びになるかなと考え、アウトプットしようと考えました。

というわけで早速ですが、お話を聞いた内容を以下に書いていきます。

※口頭インタビュー形式で書かれていますが、私が聞きながら話しながら書いたメモを元に記事を書いているので、必ずしもこの順番で話したわけではなく、発言ニュアンスもやや異なる場合があります。

GOTOさんについて

鈴木: GOTOさんの印象ですが、フォロワーも多いし、コミュニティ運営もやっているので、界隈のボスだと認識してます。

GOTO: そんな大層なものじゃないですよ笑。コミュニティといっても細々ゆるく運営しているだけです。

鈴木:  なんてお呼びすればいいですか? GOTOさん、後藤さん?

GOTO: GOTOさんと呼ばれることが多いですね。メルカリ社内では外国の方も多いですが、同じように呼んでもらってます。

鈴木: エンジニアだと go to さんと呼ばれることとかないですか?

GOTO: ないですね笑。最初にGOTO(ゴトー)ですって自己紹介しちゃうからかもしれません。

鈴木: OKです! よろしくお願いします。

EMの卵の鈴木の置かれている立場

鈴木: 今日の目的なのですが、二つあります。
鈴木: 一つ目は私がこれから5月とか6月とかにEMになるかもというところで不安解消が一つ。経験としてはプロジェクトマネージャーやリーダー経験がありますが、メンバーの目標設定や評価経験はありません。
鈴木: 二つ目は社としてEM採用を進めているが、採用媒体を通してほぼEMと会えない。まずEMが何を考えているか分からないし、それを知りたい。また、ゆるい繋がりが業界内にできれば、将来的にいいことがあるかもという打算もある。

GOTO: 会社によってEMの役割って全然違うので、鈴木さんがどういう役割を想像しているのか教えてもらっていいですか? 評価をやらないEM、みたいな人もいます。鈴木さんのところはメンバー評価をやるというのが前提になっていますか?

鈴木心の声: どういう方向に進む人かGOTOさんから見ると分からないので、まず情報を吸い出してもらってます。GOTOさんが”EMといえばこうだろう”と思い込みで喋り始めないところは優秀なEMさを感じました。

鈴木: そうですね。上長からは、個人の目標と組織の目標を擦り合わせるのがEMの仕事であると言われています。1on1や評価はツールとしてつかって欲しいという話をされてます。

GOTO: メルカリの場合だと、評価は仕事の一つではあるけど、それだけをやるわけではない。マネージャーの定義は「全体の成果を最大化する」です。評価とかは道具としての扱いです。

GOTO: POはいますか? 
(弊社EMが考えるべきスコープってどこまで?という情報。施策を考えるのは誰なのか?)

鈴木: M&Aクラウドでは社としてKPIを決めていて、それに合わせてタスクの優先順位はPOが責任を持って決めています。エンジニアは目標数値を決めることはないです。
鈴木: 一方でエンジニアの責務はPOが考えたユーザーストーリーやAC(Acceptance Criteria)などを前提にユーザが使いやすいように細かい仕様を考えるのがエンジニアの責務。

GOTO: 目標はどのようなもので、どのように運用されてますか?
(EMが目標設定をするのか、他の人の責務なのかはっきりさせる。)

鈴木: メンバーの目標と上位の目標との関係としては、MBOの枠組みの中で、個人目標と上位目標とのすり合わせをして作ります。また、目標に対して個人の行動がそれに沿っているか定期的にチェックしている。EMとしては、上位目標から、個人の目標に落とし込んでいくのが私の仕事になると理解してます。

GOTO: なるほど。鈴木さんの置かれている状況の解像度がだいぶ上がりました。

メルカリにおけるEM

GOTO: メルカリだと、チームによっていろいろなやり方はありますが、個人目標はあまり重視していないですね。チーム単位でOKRを立てています。メンバーはチームの成果を出すことにコミットするようにしてます。チームで目標を考える。その中でメンバーがうまく進めていくために、その人の成長を考慮しながら、個人の話を考えます。もちろん、どうしても達成しなきゃいけない目標がある時にはそういうことを考えられないことはありますけどね。

鈴木: 目標はチームが自律的に決めるんですか?

GOTO: メルカリの中の大きな組織の中のドメイン(ある程度扱う機能として独立した塊)をチームにアサインしてます。例えば出品物関係を扱っているチーム。配送関係を扱っているチーム。上位でプロダクトとしてKPIが設定される。例えば「出品を伸ばしたい」(※ここは多分数値があるのだろうなと思ったけど、社外に詳細は出せないと理解した)。その目標をサポートするために各ドメインで目標を考える。

鈴木: ドメインとチームって同じですか?

GOTO: 概念は近いです。チームが二つのドメインを持っているとかある。チームが複数の機能を見ているということ。
GOTO: ドメインによっては閑散期がある。時期によって上位目標と食い違うケースとか。そういう時には、内部的なアーキテクチャを考えたり変えたり、機能追加ではないことをやっていることもある。

GOTO: "目標はチームで決めるか?"についての答えとしては「自分たちが何ができるか?」をエンジニアたちで考えますね。そこにプロダクト目線が入ってくる。ドメインにはPOが入っていたりいなかったりする。絶対POが主導しているというわけではないです。テクニカルの視点でやっていくことも多い。より扱いやすいソフトウェアコードにするにはどうしたらいいかとか。

鈴木: エンジニアの主体性を求められる環境ですね。

GOTO: その理由は、ソフトウェア的な問題が大きいからですね。機能追加をしたいけど、ソフトウェアの構造の問題ですぐに追加できないというのがある。機能を追加しやすい形にする、というのも重要な仕事。

鈴木: 比較するとM&Aクラウドだとそこまでソフトウェア的な問題がないかもしれません。追加したい機能に対して、準備がめちゃ必要です、みたいなことは頻発はしていない。そういう問題が起こり、エンジニアがソフトウェア的なところを変えることでバリューが出せるのは大きな組織ならではですね。

鈴木: その中でEMの動きってどんなことをするのでしょう?

GOTO: EMはまず、成果とは何か?をよく考える必要がありますね。よりインパクトのある問題を解決している状態。問題設定がまず大事。誰が聞いても「やればいいよね」となるものもあるがそうでないものもある。ステークホルダーの説得が必要。問題の問題化からやりますね。技術的な問題や、チーム同士の連携の問題があるかもしれない。上長や他のチームから自分のチームと仕事をした時に困っていることを聞くことがあります。連携でうまくいかなかったことがあったとしたら、例えば仮説としてソフトウェアだったり働き方だったり解決するべき問題がある。
GOTO: 解決すべき問題はテックだけに限らない。例えば評価制度自体に問題がある。メンバー同士のすれ違いがあったりすると、評価制度の文言をちょっとだけでも直しに行く。成果に対して特段問題がなければ、チームのメンバーを無理になんとかする必要もない。メンバーが評価されるようないい問題を取ってくるとかもEMの仕事だと思いますね。

評価について

鈴木: 評価制度ってエンジニアとそれ以外で分かれていたりします? 

GOTO: ベースは同じだけど、職種によって当てはめ方が違います。Go Bold, All for One, Be a Pro というベースのバリューは同じだけど、それを適用する例みたいなのが違う。

鈴木: EMってどう評価されるんですか?

GOTO: 答えは持っていないです。チームの成果を見ますが、客観的に測るのは難しい。分かりやすい一つの指標にはならない。評価されるためには、問題を問題化する、やったことを成果化する、それが必要なスキルだと思いますね。

鈴木: 何ができるとどういうEMになるんでしょう?

GOTO: より広い範囲の問題にアプローチする、大きなチームの成果を出していく人は、EMの中でも経験が長いレイヤ。

鈴木: GOTOさんはどれくらいの範囲見られているんですか?

GOTO: 3~4チームくらい。チームにつきざっくり5人くらいのエンジニア。

鈴木: GOTOさんは偉い人ですね! メンバーとしてEMが見る人と、解ける問題は相関があるとみて、見れる人数で給与は決定される?

GOTO: そうですね。相関はあると思いますね。

鈴木: 評価って難しくないですか? 給与決定プロセスを知りたいです。

GOTO: メルカリのオフィシャルなプロセスとしては、クオータ(3ヶ月)毎に、期初の目標設定と、期末の自己評価とパフォーマンス評価。最近は3ヶ月毎はやりすぎなので半期毎にしようという動きがあります。やることは、自己評価とピアレビュー360°評価、マネージャーの評価。評価は2軸で、成果評価と、行動評価。
成果評価はチームの担当したところがOKRと照らし合わせてどういう結果だったのか。PJ進捗がどうだったかとか。
行動評価はValueを体現できているか。コードレビューがどんな感じでやれるのか、どんな問題解決ができるのか。
その二つの軸をまとめて、総合評価がつく。

鈴木: マネージャークラスになるほどミックスのうち成果評価が多いのですか? 

GOTO: マネージャだからといってウェイトがどちらかに思いとかはないですね。成果評価で5段階、行動評価で5段階。総合評価でどうなるかはマトリックスがある。どちらかというと行動評価の方に重きを置かれたマトリックスになっています。たまたま出た成果より、よりバリューを発揮できる人を育てたい、というメルカリらしさだと思います。

鈴木: なるほど。単なる平均じゃないんですね。弊社もバリュー評価がベースサラリーに直結するようになっている。成果が出るとボーナスに乗ります。たまたま出た成果というのがサラリーに関係するとハンドリングしにくいですよね。

GOTO: メルカリも当初はバリュー発揮してなくても成果出るとベースが結構上がったりとかあったのですが。それは今ある種の問題ですね。

GOTOさんのマネジメントスタイル

鈴木: GOTOさんはマネジメントスタイルはどのようなものですか?
プレイイングマネージャーとか、引っ張っていく方、サポーティブ、"俺がけつもち"ストロングスタイルなどあると思いますが。

GOTO: 任せるスタイル、サポートティブが得意ですね。ただ、まずは切り開かないといけないということはある。コンセンサスがまだ得られていない時とか。方向をある程度決める必要があります。

鈴木: 任せ方について細かく聞いてもいいですか?

GOTO: レールを引いたら任せる。レールない状態で任せるのは、それをチャレンジしたい人向けだけにしてます。チャレンジしたい人には、より上のステークホルダーとだけ握れているが詳細決まっていない、みたいな状態で任せる。どのフェーズで任せるかというのは結構意識してます。

鈴木: GOTOさんはチームを持つEMのための大きなEMのレールを引いている感じなんですね。

これまでキツかったこと

鈴木: EMやっていてキツかったこと教えてもらってもいいですか?

GOTO: どうにもならなかったやつがありましたね。レールを引いて進めようとしてしていたが、問題に対応するのは1チームくらいで、そのマネージャーをやっている、くらいの想定でレールを引いていた。その現実的なムーブに進むところで、レールの土台が上位レイヤからガラッと変わってしまった。0から考え直し。

鈴木: それってどれくらいのスパンの話ですか?

GOTO: なんとかしなきゃと1年くらい整えていた案件でした。メルカリの中の昔年のレガシーのところ。ドメインとしてチームがなかった領域。でも重要な領域。やってくれるメンバーをいろんなところから集めてきたりして、チーム外とのコミュニケーションも始めていた。

鈴木: それはきついですね。2年目エンジニアとかがメンバーとして動いていたら嫌になって辞めてしまいそうな。

総括

鈴木: 改めて、GOTOさんのメルカリにおける役割って何ですか?   EMの役割って色々ある中で。ピープルマネジメント(組織と目標)、プロジェクトマネージャー、仕事の進め方仕組み作り(スクラムマスター的な動きとか)

GOTO: 全て必要だったらやりますね。メルカリにおけるEMは”チームの成果を最大化”するのがミッションなので、チームの成果を出すために必要だったら何でもやります。

鈴木: 「エンジニアリングマネージャ or エンジニアマネージャーどっち?」みたいな質問を用意していたのですが、単に「マネージャー」と言った方がしっくりくるかもしれないですね。”何とか”する人。

この記事が気に入ったらサポートをしてみませんか?