見出し画像

「1on1の目的って何？ EM採用面接は何を話す？」 EMの卵がBaseconnectのEMに聞いてみた【Engineering Manager】

やも

こんにちは。M&Aクラウドという会社でエンジニアをやっています”やも”こと鈴木（@yamotuki）です。EMの卵です。

本記事は、以下の記事同様、社外のEngineering Manager（以下EM）の方にインタビューさせていただき、学びをまとめる記事なっています。
* 第1回: 「EMの仕事って何？」「評価するのが不安です。」 EMの卵がメルカリのEMに聞いてみた）
* 第2回: 「EMの職務領域は広い、けど全部一人でやる必要はない」（リブセンス海野さん）

今回お話を聞かせてくれたのは、企業情報データベースMusubuで有名なBaseconnect社の米丸（@chome）さん。

今回は”鈴木”と”米丸”ではなく、ハンドルネームで呼び合う流れになったので本文も"やも"と"chome"となっています。我々二人は初対面です。

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

導入

やも: 今回の目的についてですが、私がこれからEMになる可能性があってその学習目的がまずあります。あとは、同じような状況に置かれている人が同じように学びたいニーズがあるかなと思い、記事として発信させていただいています。

chome: 他の方にインタビューされてきた記事も読ませていただきました。最初に期待値調整させていただくと、私はEMになってまだ半年くらいで、どっちかというと立ち上がりフェーズです。参考になることがあるのかどうか。

EMになったきっかけについて

やも: chomeさんは前職でマネージャーはやっていたとのことですが、どういう役回りだったのでしょう？

chome: 前職は受託開発の会社でした。私は、チームにディレクターやテスターもいる総合的なマネージャーとしての役割でした。エンジニアリングというより、事業的なマネジメントが多かったです。エンジニアチームも含まれていたのですが、スケジュール管理だとかリソース管理だとかに比重が重くありました。

やも: なぜエンジニアのみを対象とするマネージャーという形で転職されたんですか？

chome: きっかけは、「やっていることが広くなりすぎたな」と感じたところでした。その時やっていたことと、世の中でEMとして求められていることが食い違っていると感じました。前職では企画にも入っていたので、エンジニアだけ見ているということはできませんでした。”マネジメント”をスキルとして伸ばしていきたいなと思った時に、スコープを絞った方がやりやすいと考えました。

やも: 確かに、前の記事で私がお話を聞いたお二人も、EM領域はすごく広いというのは共通した考えでした。さらにそれ以外の領域も一気にやるとなると集中して学ぶというのは難しそうです。
やも: そう考えた時に、会社選びとしてはどのようにしましたか？

chome: 自社サービスを運営していて、ビジョンやプロダクトが目指すところに共感できるかどうか、という軸はありましたね。

現職での動き

やも: 現職としてのEMの動きとしてはどのような形でしょうか？　

chome: 「全体を支援する」みたいなところをやっていきたいと思っています。調整をして障壁を壊していったりとか、スケジューリングを考えたりとか。そういうのは苦手としているエンジニアが多いので、間に入って繋ぐようなやり方で全体の成果を上げるという仕事がしたいなと思っています。

やも: 技術選定だとかテクニカルなところはいかがでしょう？

chome: 社内にテックリードも別にいて、テクニカルなところはテックリードが強いですね。

やも: それぞれどれくらい人数いらっしゃるんですか？

chome: テックリードは数名。どこまでをEMと呼ぶか問題もあるのですが、EMも同程度で数名。サブマネージャーも含めるとEMは4~5人ですかね。社内のエンジニアはインターンメンバーを含めて35人くらいです。

やも: EM1人当たり約8人のエンジニアとなると、ピザ2枚ルールでギリギリのところですね。

chome: そうですね。ただ、EMは採用が難しいのでなかなか増えにくいですね。特にカルチャーに合っているかというのが大事です。合わなかった時のリスクが、エンジニアよりEMの方が高いと感じます。

やも: EMの採用についても興味あるのでお話聞きたいです。

EM採用面接について

やも: そもそも市場の候補者も少ない上に、カルチャーも大事となると、やはりEM採用は大変ですね。カルチャーフィットも見ないといけないとなると、EMは採用面接はどのようなものがいいんでしょう？

chome: 私もそんなに沢山面接しているわけではないですが、面接ではディスカッションしたいなと思っています。私が受けてよかった面接で、POが持っている組織課題についてディスカッションするというのがありました。「こういう場合どうですかね？  こうなったとしたらどう考えますか？」みたいな会話形式。面接を通して組織課題が見えてくるし、カルチャーもあっているか分かる。実は私がBaseconnectに入る時にやってもらった面接なのですけどね。

やも: いいですね。参考になります！

EMや他の役割を誰がやるか

chome: やもさんのところでEMに当たる人はいるんですか？

やも: 荒井さんという方がCTOでエンジニアの長としてEM的な役割もやっていますね。目標設定とか、1on1とか評価とか。今はPdMとしての役割も強くなっているので単なるEMかというと怪しいですが。

chome: 最近EMやっていて大事だなと思ったことがあったのですが、それは「自分がどこに力を入れるべきか判断する力」。今ピープルマネジメントに力を入れるべきなのか、それとも他のことに力をかけるべきなのか。

やも: 弊社でCTOがPdMやっているというのはそういう判断を荒井さんや経営陣がした結果かもしれないですね。会社は成長しているけど理想とする爆発的な成長を達成していない状態で”何を作るか？”が大事なフェーズになってきた。そこで”何を作るか？”を考えられる人としてCEO及川さんかCTO荒井さんが適任で、それで荒井さんがPdMをやることになった理解です。

chome: なるほど。そういうのは会社として何をやっていくかというのは議論している感じですか？

やも: 会社全体で議論というよりは、経営会議だとかで話されて、その議事録が公開されているので知ることができるイメージですね。何か課題かとか、ボトルネックが何でどこに資源を投下するの、とかの話が見れて透明性はあります。

技術力の維持について

やも: EM 1人当たり8人もエンジニアがいたら手はあんまり動かさないですか？　

chome: キャッチアップのために動かすことはありますね。でも最近なかなか手は動かせなくなってきて危機感を覚えています。

やも: EMはどれくらい技術力が必要だと思われますか？

chome: EMとしてどこまで必要か、というのは考えますね。最低限としてまずは今まさに会社で使われている技術についてはキャッチアップします。時流に乗った技術は今はキャッチアップするのは無理。あとはテックリードの人と連携してなんとかやっています。

chome: やもさんはプレイングマネージャになることについてはネガティブですか？

やも: 私はネガティブだとは思わないですね。やっぱりチームについてのなんらかの判断をする時には現場で実際に何が困っているか知っておかないといけないと思います。例えば、弊社だとフロントエンドのビルドが遅いという問題があって生産性が低下することがあるのですが、実際にやっていないと肌感で理解できないのでEMとして大事だと思ってます。

chome: 私もまさにそう思っていて、現場感って大事だなと。最近思ったのは、理想的な組織は、プレイングマネージャーが複数いて、それの上に manager of manager がいる形だなと。manager of manager はマネージャ専任で。ただ、会社によると思いますが、EMの人数が必要なのでなかなか難しいなと思ってます。

1on1の効能

やも: 話題は変わって、マネージャー同士で1on1をされたということをtweetされていて興味深かったです。

やも: 特に「コーチングの向きが変わる」という話がめっちゃ面白いなと思って。

chome: 他のマネージャーの方と話してみたら、1on1についての課題が浮かび上がりました。現場エンジニアと1on1やってみると「やってよかったね」となるが、本当によかったのかわからない。クローズなところでやることですし。「そういえば1on1を受ける側の気持ちになってみる機会があんまりないよね」という話になりましてマネージャー同士でやってみました。”こんな質問の仕方があるんだ”とか大変勉強になりました。

やも: 確かに 1on1の成果って見えづらいですね。数値化とかは難しい。

chome: 予防って考えるといいかなと。明確な効果を求めるものではなく、長期で何も変化がないことを良しとして、メンタルダウンとかを予防する。離職率低下とかが 1on1 の効果なのか、は正直なところ分からない。メンバー側から「1on1 必要なんですか？」と言われたら「必要ないかもだけど風邪ひいちゃうかもかだらやっておきましょう。」というところですね。

やも: 長期効果の体感みたいなところあってありますか？

chome: 前職でやっていた時には、チームの連携がしやすくなったと感じました。マネージャーがメンバーのことがよくわかるようになり、マネージャーとして動きやすくなった。相互理解ですね。メンバー側がどう思っているかはわからないですが、組織としてプラスになったとは思います。

相互理解ってどこまでやったらいいんだろう？

やも: 相互理解ってどこまでやったらいいと思いますか？　弊社でもこの数ヶ月で40人くらいだった会社が60人を超えるくらいになってきてます。相互理解は大事だと思いますが、どこまでなんのためにやるのか、というのを模索しているところでして。どこにその効果が現れますかね？

chome: まずはメンバーのエンゲージメント。仕事が楽しいと思ったり、長く仕事が続けられるとか、仕事がやりやすくなっていくとか。

やも: 弊社でやっている事例なのですが、エンジニアが勝手に16:00になると ”developers radio”と称してラジオ形式の雑談を始めます。これは10分だけなのでリターンの方が優っていると思っているのですが、仮にこれが20分, 30分, 1時間になった場合にどこまでリターンがあるのか。

chome: 面白いですね。弊社だと developer closer という企画を月の終わりにやっています。ゆるくLTとかする会ですね。エンジニアからは好評ですが、社内からは費用対効果の面で説明が求められることもあります。対策として、社内アンケートをやるようにしました。その会の目的である、各チームや人となりの理解、ナレッジ共有について「今回はどれくらいできましたか？」というのを数値で出すようにしました。定量化したことで「こういう数値が出ているのでポジティブな結果になっているよ」と言えるようになりました。

やも: なるほど。ROIまでは考えられなくても、まずはリターンを定量化するというのは大事ですね。

おわりに

noteの「スキ」よろしくお願いします！
自分の学びとして、また、これを見てくれた同じような立場の方の学びの形として続けていきたいと考えております。

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