1. kkeethのエンジニア雑談チャンネル
  2. No.399 「引き続きEMの勉強を..

はい!第399回は,タイトル通り引き続き自分がこの4月からチャレンジする EM(Engineering Manager)について勉強しているメモをベースにお話しました💁‍♂


ではでは(=゚ω゚)ノ


ーーーーー

🔗 LINKS

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

https://qiita.com/hirokidaichi/items/95678bb1cef32629c317


♪ BGM

騒音のない世界「月面の鯨」

https://soundcloud.com/baron1_3/kujira

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:14
はい、みなさんこんにちは。きーつくんのくわはらです。本日もやっていきましょう。
きーつのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、
雑談形式で発信していきたいと思います。
今日は、タイトルにあります通り、引き続き、EMってなんだ?とか、EMって何する人?みたいなのの勉強を、
続けているという、そういう話です。
はい、エンジニアリングマネージャーです。
とかく、EMのポジションって、やられている方とか、ご存知の方なら、評価あると思いますが、
割と何でも屋さんみたいなところが正直にあって、
僕は、この4月から新しくEMとしてチャレンジをするんで、今勉強をキャッチアップをしているんですけど、
調べれば調べるほど、本当に何でも屋さんだなっていう感じがします。
ただまあ、何でも屋さんと言っても、コードも書くし、プロジェクトマネジメントもするし、
事業計画立てたりとか、リソース管理するとか、そういう意味の本当の全部ではなくて、
あらゆることを必要に応じて、あらゆる手段でやっていくって意味で、何でも屋さんというような感じです。
ただ、タイトルというか、名前の通りエンジニアリングマネージャーなので、
開発組織とか開発現場におけるものの、マネジメントっていうところが主なんじゃないのかなというところです。
で、よくある一つの捉え方評価軸として、キーワードとして、
自チームと隣接領域の成果を最大化するっていう、
ごめんなさい、これどなたが推し立っているのか、誰が提唱したのか、
僕が把握していなくて大変に恐縮なんですけど、失礼なんですけども、
このキーワードがEM界隈ではすごくホットなキーワードで、
皆さんこれに準ずる行動してそうな気はしてます。
自分のチームとそのちょっと隣、関係するところの領域の成果を最大化するということです。
なので、結局成果の最大化になると、
とにかく現場とか組織チームというのをよく見て、観察をしておいて、
そこから前に進めるためにはこれが必要、あれが必要というものをどんどんやっていく。
どんな手段でもいいからとにかくやっていくっていう感じですね。
プロジェクトにおけるスクラムマスターに近い感が僕はあったけど、
スクラムマスターはマスターが進めるわけではないし、
どっちかっていうとサポーターに近いと思うんですからね。
なのでエンジニアリングマネージャーはどんどん手段を駆使して、
物事を前に進めるためのコミットをしていくという感じです。
なんですけど、組織とかチームのアウトプットとか、
ちょっと隣、関連する領域の人たちのアウトプットを最大化をするというので、
何が大変かっていうと、ほんと見る範囲も広いし、
形式化してるかっていうとそういうことは難しそうですね。
その場、そのケースに応じて必要なことをやっていく。
03:02
だからこういうことをやればいいと、一概に言語化できるとは思えなく、
コンテキストだったり環境、チームの状況、フェーズとか、
いろんな要因に応じて実際に行動するものが変わってくるので、
そういうのが大変ではあるんですけど、
考え方というか割り切り方と言いますかね。
一応一つの指標みたいなものがあって、
それは書籍にあるんですね。
エンジニアリングマネージャーとかプロダクトマネージャーのための
知識体系と読書ガイドみたいなものがあります。
後ほど概要欄にもリンクを貼っておきますけど、
これにはですね、業務範囲っていうのが4つに分けられています。
1つはプロダクトマネジメント、2つ目はプロジェクトマネジメント、
1つ目にピープルマネジメント、4つ目にテクノロジーマネジメントが4つですね。
ただ、テクノロジーのマネジメントもEMとしてはやるらしいですね。
技術戦略だったり、技術選定だったり、
設計もありもするというところなので、
そういう意味で何でも参加もあります。
ピープルマネジメントは文字通り、
レポートラインの上に立って、チームメンバーの人たちの評価だったり、
成長、サポートをするためのコミットを申してくださいね、
というのが書かれています。
プロダクトマネジメントはまんまですね。
プロダクト戦略と実行がありますけど、
こちらに関してはプロダクトマネジャーがそもそもいる可能性があります。
PDMがいるのであればそっちにお任せするとか、
プロダクトオーナーでもいいのかな。
ごめんなさい、僕がプロダクトオーナーとプロダクトマネジャーの
領域とかスコープの違い、ミッションの違いというのは
ちゃんと理解していないので、
同じものと…
同じものって言うとセレですね。
被っているものだという風に思っているので、
どちらかの方がいるんだったら、
プロダクトマネジメントの方に関しては、
専門をその人に任せるのがいいかもしれないですね。
プロジェクトマネジメントも一緒ですね。
PJM的な人がもしいたり、
スクラマスター…スクラマスターじゃないか。
PJMがもしいるんだったらその方に専門領域をお任せしていくと。
なのでEMは基本的にやっぱり
ピープルマネジメントとテクノロジーマネジメントの
2つを見るのがいいんじゃないかなと個人的には感じています。
チームの状況とかによりけりですし、
PDM、PJMがどちらかしかいなかった場合は
そこも自分たちで担っていくという感じですね。
そういうことを聞くと、
EMってやはりスーパーマンな感じがめちゃめちゃしてて、
何でもやっていくって本当にその通りなので。
人によっては育成もしてますし、
どんどん足りないんだったら外から人を投与する。
つまり採用もバンバン自分たちから進めていく心もあって、
でも必要なんだからやるよねっていうので、
スーパーマンにならなくていいって言われますけど、
スーパーマン感はありません。
何でもかんでもやるというところです。
ただ気をつけておきたいのは、
成果を最大化するためにいろんなものをもちろん見ていくんですけど、
しっかり現場を観察して何をしていくっていうことを動こうとすると、
結果的に具体な話が多くて、
いわゆる木を見て森を見ず状態になりかねないですね。
木ばっかり見ていって、
06:00
具体は見ていくけど全体方針とか設計みたいなところ、
全体の流れみたいなところを見ないまま、
どんどん具体の話しかしなくなるっていうのはやっぱり避けたいので、
やっぱりホワインにしっかり立脚して、
何のためにやっていくっていうところを大前提に、
ハウのところを考えていきたいですねっていうのは思ってます。
まあその必要なこととかホワインのところはチームにおいてとか、
今から関わるプロジェクトお話ではあると思うし、
まあ組織開発だったら組織全体の方針だったり、
経営計画とかに寄り添っていくと思いますけど、
それはもはやEMじゃなくてVPOEな気がしますが、
というところですかね。
いやーでも僕はその中でも、
ピープルマネジメントが特に得意かどうか別として、
人に興味関心が強いので、
私はそっちの方を結構動いていきたい感はあるし、
かといって技術にも全然関心はすごい強くて、
技術も今までに触れていきたいし、
今もこう触れ続けていきますけど、
メインで書いていないだけであって、
テクノロジーもしっかりやっていきたいなとはずっと思ってますので、
プロジェクト、プロダクトに関しては、
他のメンバーの方がいる環境に僕はよく身を置くので、
そこはそこと、メンバーに旗繰りはお任せしつつも、
エンジニア組織の方でプロジェクト、プロダクトへの
どう関わりとか関係性、
バリューの発見の仕方っていうのはやっぱり考えていきたいし、
一緒に動いていきたいなと思いますね。
一番大変なのはやっぱり評価ですよね。
今、イメインという会社が評価制度がやっぱりないので、
人の評価をされることはあっても、
自分がしたことはないので、
ここがほんと大変なので、
やっぱり定期的なワンワンをしながら、
見ていくっていうところが必要なんだろうなと思いますし、
見ていくのはいいんですけど、
僕自身もまだEMチャレンジ初めてですし、
卵でしかないので、
今から頑張っていくっていうところですね。
評価が半期とか、
もしくは1年に1回とか分からないですけど、
もしある場合は、
週間レビューをやっぱり挟むのが大事かなと思いますね。
半年とかだと、
もう6ヶ月に1回ドーンと評価されるってなると、
方向転換をしたりとか、
微調整とか、
目標に関する微調整も絶対メンバーとしてはするだろうし、
人によっては半年間かけながら、
目標っぽいものはふわっと持っておいて、
実際のコミットはその場その場に応じて
柔軟に動いていったっていうメンバーもいるでしょうし、
最初からガツンとこういう定量的な評価を、
目標立てて、
そこに対してどれだけのコミットが達成ができたか、
っていうのを見るメンバーもいると思うんで、
結構マチマチですけど、
どちらにしろ方向制度を
ちゃんと見直ししたりとか、
レビューしなきゃいけない時はあると思うんで、
定期的なレビューとか、
会社としての評価ではなくて、
このチームの中だけの評価はやはりした方がいいんだろうなと、
今感じているところですね。
いくらチームとして同じように動いているとはいえ、
日々の業務の中で、
でもちゃんとメンバーの人たちの評価のための見方を
しなきゃいけないっていうのは、
ずっとやっぱり近視眼的に近くにいると、
見てるし分かってるだろうっていうので、
メモをしたとしても、
自分でも定期的な意味で振り返って、
09:01
この人はこの期間、一定期間でどれだけコミットしたとか、
どれだけの成果、アウトカムを出したとか、
実際どれだけ挑戦と成長を出したか、
チームへの貢献をやったかみたいなのを、
自分でも振り返るタイミングが絶対あると思うんで、
そこを作っておいて、
それを僕自身で閉じるんじゃなくて、
メンバーにもやっぱり伝えていって。
本来あなたがコミットするとか、
立てた目標はこうだよね、
に対して実際自分の肌感とかどうですか、
みたいなのをちゃんとおしゃべりして、
組織にもちゃんと評価をされるように、
EMが動いていかなきゃいけないんだろうなっていうところが、
僕の大きな課題なんだろうっていうところで、
でもしっかりこれをやれるようになったら、
いろんなものを託されるだろうし、
逆に言うとメンバーにも、
全然任せていけるような気はしてるんで、
やはりキーマンだなっていうのはすごく感じますが、
やったことないんで、
やっぱ責任重そうだなっていうのがあるんで、
ほんま他の会社さん、
いろんな会社さんのEMをやられてる方とかの記事だったり、
アウトプットの発信の内容を見てますけど、
最近特にタイミーさんがすごくホットで、
タイミーさんとかあとは掛橋さんとかですね、
の方々、EMの方々の発信をよく見ながら、
ちょっと勉強させていただいてますけど、
皆さんほんとすげーなって思ったりしますね。
これ俺もできるんかいみたいな。
一発の不安もやっぱありますよ、
新しいところではあるし、
やったことはないのでね。
かつ、会社への貢献とか事業への貢献も任されてるし、
メンバーの成長とか期待値もあると思うんで、
いやー僕みたいなポンコツがEMやって大丈夫かって、
不安は常にありながらですけどね。
まあ言っても仕方ないので、
一緒に頑張っていきたいところですけど。
まあとにかくさっき言った定期的なレビューもそうですけど、
フィードバックループみたいなのがあると思うんで、
EDCAをしっかり回して、
自分の反省点もあると思うんで、
メンバーからのツッコミだったり、
ネガティブフィードバックでもいいですね。
とにかく僕に対してのフィードバックもいただきたいなと思ってるんでね。
全然僕もそんなできた人間じゃないですからね。
まあみたいなことを思いながら、
とにかくEMってやること多いとか、
責任範囲とかスコープ疲労っていうのは思いますけど、
まあ勉強すればするほど、
僕みたいにマルチプレイヤーというか、
一個一個は専門家じゃないんですよね。
企業貧乏って言ったほうがいいかもしれないですけど。
な人ほどEMの相性はいいんじゃないかなっていう、
僕の感触です。
何でもでもやる人とか。
人に興味持つ人が、
EMはやはり相性はいいんじゃないかと思うけど、
これほんと先天的なもんですからね。
人間いろんなことを経験したり、
年齢上がったり、
ライフイベントを発生すると、
考え方価値観ってガランと変わっていくもんなんで、
途中でやっぱりEMやりたいって人も出てくるかもしれないですけど。
後輩とか、
次に社会人になっていく人たちのために、
背中見せるじゃないですけど、
EMってやっぱ楽しいとか、
EMかっこいいなって思っていただけるような動きは、
していきたいなってのは思ったりはしますね。
12:01
やっぱりマネージャー大変そうとか、
いや、これ僕やりたくないって思われるような役割の姿を見せたくはないなと思ってるんでね。
でかいこと言ってますけど、
できるかは知らん。
でも努力はし続けていくってところは変わらんと思うんでね。
はい、そんな感じですかね。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
12:34

コメント

スクロール