見出し画像

「EMの職務領域は広い、けど全部一人でやる必要はない」（リブセンス海野さん）【Engineering Manager】

やも

こんにちは。M＆Aクラウドという会社でエンジニアをやっています鈴木（@yamotuki）です。EMの卵です。
”卵”というのは、まだEngineering Manager（以下EM）業務をやっているわけではなくて、上長から「将来的にやって欲しいんだよね」と言われている状態だからです。

本記事は、前回の記事（「EMの仕事って何？」「評価するのが不安です。」 EMの卵がメルカリのEMに聞いてみた）同様、社外のEMの方にインタビューさせていただき、学びをまとめる記事なっています。

今回話を聞かせていただいたのはリブセンスの海野（@boscoworks）さん。EMとしての基本情報は以下の通りです。

* 関係するメンバーは正社員6人, 業務委託5人。
* 肩書きがあるポジションとしてのEMではなく、ロールとしてのEM（詳細は後述）
* 業務委託の方についても契約更新時のフィードバック、単価交渉を含む契約内容のアップデートをする

早速インタビューに入っていきましょう。

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


自己評価と他者からの評価

鈴木: 以下のような話を twitter で書かれてて気になりました。詳しく聞いてもいいですか？

海野: 現場のエンジニアの評価についてと、EMの評価どっちについて聞きたいですか？

鈴木: ではまずエンジニア評価について聞かせてください。
鈴木心の声: （しまった！ あとでEMの評価の話も聞こうと思ったが、忘れていた。またの機会に。）

海野: 技術のわかっていない人がエンジニアの上司として来ると、すり合わせも大変ですね。すり合わせのためのエビデンス準備も大変。頑張って交渉したけど、結局給与上がり幅も小さい、みたいになるとなお辛い。個々のエンジニアに説明責任はあるにせよ、上司の理解を促すのはシニアエンジニアとして必要なものですね。それがEMの役割の最たるものだと思います。組織の成り立ちにも関わるけど、組織リーダーがエンジニアとは限らない。私のチームの場合では、上司は20代の若いプロダクトマネージャー。エンジニアリングの何たるかをエンジニア個人が全部説明するのは大変ですね。

鈴木: EMの役割はクッション材みたいなところですかね？

海野: ”コンパイラ”ですかね。翻訳して伝わりやすくする。他社でも事業会社だと結構同じなんじゃないですかね？

鈴木: こういうふうに上に伝えたらうまくいったよみたいな事例とかってあったりしますか？

海野: 私はEMをポジションとしてではなくてロールとしてやっているだけです。組織としては肩書き無し。特例としてリーダー陣が参加するMTGに入らせてもらってます。部門が100人くらい。エンジニアがリーダーに一人もいない状態です。なので、エンジニア代表として入れさせてもらっています。週に1~2回、最近エンジニアがやっていること、やっている取り組み、起こった不具合などオープンにする。そこでよく名前が出てくる人が活躍していると他のリーダーにも分かりますね。ブラックボックスでやると不信感につながります。エンジニアのために社内の広報役として役割を担う、それが重要だと再認識しているところです。

鈴木: 海野さんが辞められたら大変そうですね。SPOFになってそうです。

海野: 私の部署だけじゃないですね。どこの部署も同じように余裕はないです。居なくなったら居なくなったでその時残った人が最善のことを考えるしかないですね。あらかじめ考え方を伝えておくと、課題を持った人が動いてくれるだろうと信じています。

鈴木: リーダー会に入るのは海野さんから働きかけたんですか？

海野: 元はもう一人他のEMがいて、その方がリーダー会に出ていてくれていました。その方が辞めますとなった。なので自発的に働きかけたというよりは後任になります。

成果が出たことについて

鈴木: これまで何か楽しかったこととか、成果が出たこととかってあったら聞いてもいいですか？

海野: エンジニアの都度の評価で成果が出たというのは、それが仕事なのでアピールするところではないですね。「仕事やったなあ」と思うのは、評価制度を会社全体で変えていきましょうよとムーブに乗ったこと。当時のリブセンスは「エンジニアだから特別な評価をする」はなく、全社員共通。愚直に適用すると、技術を伸ばすことをやっていきたい人が評価されない状態でした。評価されるにはマネージャーにならないといけない。そこで、「自分たちはどういうキャリアを作っていきたいのか？」というのを社員で話し合って明文化しました。（以下の）４象限でどこまでやり切ったら評価されるか？というのを言語化して現状の評価制度を拡張しました。

プロダクト・エンジニア: プロダクトのターゲットに対する施策を検討し、詳細な設計に落とし込み、技術力をもって具現化して事業貢献する
テック・リード: コードの品質や開発全体の生産性を常に意識し、チームやプロダクトの技術選定・設計・実装を主体的に実行する
スペシャリスト: 高度な技術力を駆使し、難易度の高い技術的課題に取り組む。業界内でのプレゼンスを有し、技術広報面でも会社に貢献する
エンジニアリング・マネージャ: メンバーとの間に心理的安全性を構築し、採用・評価・育成を含めたエンジニアが活躍しやすい組織的改善施策を行う　

https://recruit.livesense.co.jp/lp/engineer/overview#career

「どれくらいの広さの領域に影響を与えたか？」が、グレードに紐づきます。1事業なのか、会社なのか業界なのか。技術を駆使しているのか、組織をよくすることで達成しているのかを同列に扱います。インパクトの出し方は人によって違っていいよ、ということです。

ポジションとしてのEMについて

鈴木: 海野さんはロールとしてのEMということでしたが、リブセンスにはポジションとしてのEMはいるんですか？

海野: 社内には居ますね（※所属部署ではない）。４象限のうち横並びで誰が偉いとかはないです。一方で、効率よく組織運営するためには多少はピラミッドにしないといけない。そのピラミッドの頂点の人が評価もするEMをやっている。
海野: 私のチームの場合は、この人のこういうところが良かったとプッシュして、実際の評価する人が承認する。私はエビデンスを持っていくことで、エンジニアの皆さんの評価をより納得感の高いものにするためのサポートをします。

鈴木: エビデンスはSlackの発言とかPull Requestとかですか？

海野: エビデンスは形式ばったエビデンスがあるわけではないですね。週に1回の定例やSlackだとか、あとは同僚からの評価を参考にします。公式の360°フィードバックではないですが、1on1で他の人の助かった行動を聞いておく。出てきたものについてはマネージャーが気がついていないことを再評価する必要があると思います。

鈴木: 1on1は”その人”だけの方向性や目標、問題点に話すことが多いと思いますが、同僚についても聞いておくのはいいですね。

体系的に学ぶ方法

鈴木: 話は変わって、EMについて体系的に学ぶ方法ってありますか？

海野: 特にないですね。私も体系的に学べるなら学びたい笑

鈴木: 完全に体系立ったものでなくても書籍とかはいかがですか？

海野: 株式会社Showcase GigさんでVPoEをやられている佐藤大典さんが書いている記事がバイブルですね。 ”プロダクトマネジメントトライアングル”を参考にして作られた "エンジニアリングマネジメントトライアングル" について書かれています。EMのスキルマップを言語化するとこうなった、というものです。
海野: トライアングルの中でも、何のスキルが求められるのかは組織に依存しますね。若い人が多くて技術力を伸ばしていく必要があるとか、モチベーションに問題があるならエンパワーメント、プロダクトとの溝があるならプロダクトマネージメント、とか。それに合わせた本をチョイスするのが良いですね。
海野: 例えばプロダクトマネジメントなら「プロダクトマネジメントのすべて」。元google の及川 卓也さんが書かれている本。
海野: チームマネジメントはどういうことやらなきゃいけないのとかは、以前リンクアンドモチベーションの取締役をやられていた麻野さんが書いた「THE TEAM」とか。

海野: 上司がわかるならいいけど、そうでないならEM自身が自分でトライアングルでどこが必要か、というのを自ら掘っていかないといけない。いずれにせよ大事なのは不確実性を乗りこなすスキルですね。

鈴木: リブセンスに必要とされるEMはトライアングルのどこら辺ですか？

海野: リブセンスにおけるEMはトライアングルの中の Team に寄っていますね。テックリードはチームごとにいるので、EMが考える必要性が薄い。EMのやることは採用、広報、エンゲージメント、目標評価など。

EMをやりたい人を見つける方法

海野: 鈴木さんはこれからEMということですが心理障壁はなかったですか？

鈴木: 私はあまりなかったですね。実装力みたいなのは客観的にはある程度評価されているとは思いますが、主観的には苦手なんです。それが好きな人は1日2日ハマったところで楽しくやっているのですが、私は辛くて。一応乗り越えられるまでやれるはやれるのですが。
鈴木: 打算的なところだと採用市場だとマネージメント経験がある人が重宝されるイメージです。管理不要なエンジニアをどこも求めているなと。私は、求められることが向いていることだと思って「なんでもやってみるか」という感じです。

鈴木: EMをやりたいぞという人を見つけるのはどうしたらいいんでしょう？

海野: 「みんなEMやろうよ！」というのは大体「うーん」となる。だいぶ職域が広いので漠然とした不安を持たれやすい。まず分解して、それぞれやっていく仲間を見つけるのが良いですね。私は全部抱え込んで自爆したことがあります。採用も情報発信も自分でやらないといけない、というのは無理。意外とやることが明確だとみんな協力してくれます。例えば採用広報は技術に興味がある人も手伝ってくれやすいと思いますね。
海野: EMの大きな仕事として目標と評価だと話しましたが、そこは他の人と協力するのは難しいところだからですね。採用や広報は他の人に任せやすいです。　

鈴木: 人に仕事として投げつけられないのが目標と評価？

海野: もしかしたらさらに分解できるかもしれないですが、必要性を感じていないですね。

総括: マネージャーがいないとどうなる？

鈴木: 仮にEMがいなかったとしたらどうなると思いますか？

海野: 短期的にはEM不在で不利益発生はない。中期だとエンジニアが評価面で納得が得にくくなる。EMの存在意義は、中長期的な組織課題の解決を主体的にやっていく人。役割だけのEMがいてもしょうがないですね。

鈴木: 本質情報ですね。ポジションだけのEMにならないように気をつけます！


noteの「スキ」よろしくお願いします

自分の学びとして、また、これを見てくれた同じような立場の方の学びの形として続けていきたいと考えております。
モチベ維持のため、noteの「スキ」やtwitterの「フォロー」よろしくお願いします！


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