00:01
はい、お疲れ様です。 本日3回目になるんですけど、まあちょっと今日はいろいろ考えることが
ぐすーぽあって、はい。 3回も配信することになりましたが、早速喋っていきたいと思います。
ちょっと今日は本当に 自分の頭のせいでためだけなので、全くまとまらない可能性もありますけど
もし興味あればお付き合いいただけると 嬉しいなと思います。
でまぁ今日、今回のお話は タイトルに書いてあります通り
まあ明日の、明日って日付変わったから今日の エンジニアリングマネージャーアドベントカレンダー2024に投稿する記事
エンジニアリングマネージャーの心構えですね、について ちょっと文字書いてるんですけど、なかなかやっぱ
進む話なかなか集中しないので、やっぱ喋ろうかなと思って 喋っていこうと思います。
もともと PJM とか
テックリードだったり プロジェクトリーダーみたいなポジションを作る時もありましたけど、あとはリードエンジニアとか
もうなんか肩書きよくわからんけど、まあいわゆるリーダーぽいポジション ぽいじゃないですね、ちゃんとリーダーポジションを何度か経験をしてきました。
プロジェクトマネージャーについてはもう何案件ですかね、やってきたんですけど、 今回今いるかみなしで僕はエンジニアリングマネージャーとしての挑戦をしてて
これ面接の時にも聞かれたことがあって
EM って何する人だと思いますかって聞かれたんですね。 僕は正直にまだ全然解像度が低かったというか、全然解像度なかったので
プロジェクトマネージャーのエンジニアリングチーム特化した ミッションをやるんだろうなと思っています。
それは人の管理、リソースの管理だったりスケジュール管理、タスク管理とか プロジェクトを着地させることへのミッションを持っている人
という認識を持いました。 それをエンジニアチームなので開発という括りでいくと
一つのプロジェクト、僕はずっとウォーターホールでやることが圧倒的に多くて
アジャイルでやってたとかスクラムでやってたっていうもちろん経験は全然あるんですけど
個人的なそのちっちゃい スプリントっていう単位が一つのウォーターホールに近いようなものと思っていて
厳密には違うっていう人たちもいると思いますけど私はそういう解釈をしている
なのでスプリントプランニングで要件提起みたいな感じで、ここまでにこのスプリント中にこれをやるのが
03:06
マストだっていう感じです。 でスプリントレビューまでにずっと作りきる。スプリントレビューまでのレビューはもう
しないというか、やるとしても行動レビューとかぐらいしかないでしょうと
思っています。でステークホルダーが最終的にそれを見てチェック確認する。 これすごいちっちゃなウォーターホールの感じですよね
そういうスクラムとウォーターホールとかアジャイルとかの話がしたいわけではなくて
一応そういう経験もしてきたんですけど
アジャイルと言ってもちっちゃなスクラムでウォーターホールだと思っているので、ウォーターホールでやることが僕は結果的に多かったと思っています
そういう場における、プロジェクトにおけるマネージャーだったので
いかに着地をさせるか、遅らせることなくですね。品質とかもちろんあるし、要件定義に沿ったものがちゃんと
満たした上で納品ができているかっていうのが大事になってくるので
そういう経験はしてきました。最悪自分も手を貸して一緒にコードをガーッと書いてやっていく
みたいので良かったんですけど。僕は見積もりの精度が上がったり見積もりがすごく苦手なんで
そこは結構皆さんとかメンバーと一緒にやってたこともちょいちょいありましたね
てかもう僕の見積もりが甘いので、その見積もりのまんまメンバーにこれでスケジュール来るのでよろしくって投げたら
ソース感を食らうことになりかねなかったのし、1回だけ食らったことがあってもう大反省をしたので
見積もりをするときはちゃんと現場の人たちが今の開発環境だったりスキルだったり
状況を踏まえて出してくる見積もりを聞いてその上で
ビジネスとかマネジメント観点でいくと、そこまでバッファーを積まれるとしんどいなっていう話だったり
プロジェクト遅いなっていう風になるので、そこをうまいこと頑張る。頑張るとどうなのかって、だいたい招築場合で決めることが多かったですね
スケジューリングは。っていうような決め方をするようになりましたけど
そんな感じでやっていって、ウォーターホールでやっていくと開発フェーズっていうのが出てくるので、その開発フェーズにおける開発チームとステークホルダーと他関係各種とのコミュニケーションとかを
担当するのが僕だったと思っている。プロジェクトマネージャーだと思ってますね
スクラムマスターの可能性ももちろんありますけど
スクラムマスターではないけど、兼任しているようなものと思っております。それのエンジニアチーム特化ファンっていうのはそういう理由ですね
そんな感じの確か回答をして
上梨には泣いていただいたってとこはありますけど
ただまぁ実際にやってみ、いざやろうとした時に、PGMと違ってEMってマジ何をすればいいんだっていうのは僕は本当にわかりづらかったし
06:03
未だにはっきりこれっていうのは多分ないって言ったら語弊ありそうですけど
チームによって全然違う状況も違うし色も違うので EMとして
どういうエンジニアリングマネージャー、マネジメントをするのかっていうのはチームによって全然色が違うから
何をする人って言われるとよくわからんっていう よくわからんじゃないですね決まってないんだな
条件がない限り前提条件がない限り何をする人は決まらんというふうには思ってます
一応指標的なものとしてよく言われる 3つのBと1つのTですよね
プロジェクト、プロダクト、 ピープル、テクノロジーの4つです
これは4つに対して 責任を持つというかコミットしていくっていうのが
エンジニアリングマネージャーのポジションですと
どの会社にも多分いるでしょう プロジェクトとプロダクトどちらかを担う人は必ずいる
だいたいそれを兼任している会社も いるんじゃないかと思います
特にスタートアップとか人がそんな多くない場合は プロダクトのプロジェクトも一緒に見る、プロダクトの方はEMと
プロジェクトマネージャーが 2人3客で見るみたいなこともあるかもしれない
その時はEMとしてのポジションはPJMと プロジェクトとプロダクト半分と
あとテクノロジーになるかもしれないですね
ただテクノロジーはやっぱ開発者がいて エンジニアが普通にいると思います
プレイングマネージャーとしてやってる EMなら話は別ですが
開発は基本的にはもうエンジニアに任せてしまって っていうEMであれば一番大きな
そして必ずやらなきゃいけないのは ピープルマネジメントなんでしょうねと
いわゆる評価と目標設定と評価の時期までの目標の達成 もしくはそのグレード的なものを持っている
評価制度に入れている会社であれば グレードアップまでのそのギャップをどうやって埋めていくかっていうのが
EMのお仕事だと そのためのサポートをしたり手助けをするっていうのがEMの仕事ですね
その中でテクノロジーがもし必要になるんだったらテクノロジーをする でもそれは書くとか実際に手を貸すとかじゃなくて
テクノロジーに関する意思決定だったり 相談だったり接近についての議論だったり
ホドリビューとかをするEMもいるかもしれないですね とかをやったり
そういう意味でいくとテクノロジーに関しては割りかしやることは決まっている ピープルマネジメントもだいたい決まっている
いやそれはわかんないですね ケースバイケースによってどういう関わり方をするかによるので
テクノロジーぐらいがギリギリよく決まっていることなんじゃないですかね よりハードスキルを使う領域がテクノロジーですからね
はい そんなことを言われたり 自分もEMミートアップかEMオアシスかっていう勉強会があって
09:07
そこで他のいろんなEMの方々にお話を聞いたりとか 正直何したらいいんですかねみたいなことを
あけっぴろげにぶつけてみたんですけど そんな回答をいただいたり
登壇の内容からそういうのを教えてもらったりしていただいたと
なので 心構えというより 心構え的な話でいくとEMっていうのは
正直に何をやるかっていうのはその蓋を開くまでは決まらないし分からないので 柔軟にかつどんなことが起きてもやっていくっていう
のは割と覚悟を決めておくぐらいの気持ちでいた方がいいのかもしれないですね
そんな重く受け止めすぎてもいけないし 責任はもちろんありますけど 責任感を強く持ちすぎて自分が潰れてしまったらそれこそ
あんまりも意味がないと
さっき言った4つ プロジェクト プロダクト ピープル テクノロジー
あるんですけど 最終的にはチームの 組織の成果を最大化するってところが
非常 非常じゃない 史上名台か ミッションというとあれですけど史上名台ぐらいに僕は思ってて
そういうものだというふうに私も理解はしている
勉強会に来た時は自分のチームとか組織だけじゃなくて そこから隣だったり近いところ
関係するところだったかな ちょっと正式な言葉は忘れましたけど 身近な組織まで含めて
成果を最大化したり 良い成果を生み出すための動きをするのがEMと
いう言葉を聞いたことがあって そうなると結果的に成果の最大化って言われたらそのためにやることは何でもするって
ことなのでやっぱりEMって決まらないんですよね 逆に言うと自分がこうだと思ったりとか
こういうことかもしれないっていうのは何をやっても良い 良いっていうと言い方あれですけどどんなことをやるっても手段としてはいくらでも
出てくるので どんどん思うことをチャレンジしていく それをチームと一緒にやっていけ
実績がつけばどんどんチームメンバーからの信頼も勝ち取れるっていうところで まず動いていくとかしたり自分の中で方向性考えて
表明していくのが大事なんでしょうねっていうのを喋りながらこれは僕ができてないので 記事書くときはちょっと防衛性を張ろうかなと思ってます
そういうことなんだろうなっていうのが分かってきたっていうようなブログにしようかな と思いました
あとなんだ? やばい今喋ろうと思ったことを今忘れてしまった
こういうことがあるからやっぱりちゃんとメモしながら喋るのが良かったな これ反省ですね
はい あともうあくまで心構えの話ですからね
12:03
マインドセットっていうのはちょっと話は別ですよね 言葉の定義で心構えとマインドセットは違うので
これは確かに冒頭で先にこれは書いておいたほうがいいですね 前提としてマインドセットと心構えってちょっと違うニュアンスだし
僕はその原理主義的な立場の人なので 言葉が違えば意味が違うよっていうのでちゃんと先に前置きしようかなと思いましたね
特にやっぱりテクノロジーのところですね
自分の中で感じているものとして テクノロジーの面でも
自分が担当するというかマネージャーとして動いていくってなると やはり優れてなければいけない
テクノロジーを できるのは前提ですけど最新大手とか尖っていかなきゃいけないとか
そういうふうに思っちゃうと 大変というか重いかもしれないですね
やっぱり書いてないと技術がどんどん廃れていくのは本当に いろんな人もおっしゃってますし自分もすごい実感としてわかります
荒削りだとしても曲がりなりに技術をやってきた身として でもやっぱり書かなくなったらどんどんどんどん腕が錆びていく
これは本当その通りなので 現場でバリバリ書いているエンジニアと比較すれば
エンジニアの方がレベル高いに決まってまして テクノロジーはエンジニアの方が強くなってほしい
というかそうあるべきだと思っています
そういう人たちと会話ができるとか意思決定したり 設計レベルとかで話ができて
エンジニアメンバーが前に進むために 一緒に頭を悩ませられるぐらいの技術力が最低限持つべきなんだと思っていて
尖らなきゃいけないとか必ずエンジニアよりも強くなきゃいけないっていうふうなことを思っちゃうと大変ですし
それは違うよっていうところが次のポイントかなと思いましたね
これも書いておこうかなと 僕自身がそんな技術得意ではなかったり
自信がそれだけあるわけではないのでね
ただやってきたものはあるので 昔の勤づかで頑張ってきてる面もあるけど
さすがにやっぱりアップデートとか更新はしないといけないので
極論分からなかったらどんどんメンバーに教えてもらうのが 一番いいと思いましたね
そうだね その意味でいくと 今の神無しのCTOされている鳥さんから
1回だけアドバイスもらったんですけど
ある意味で分からないんだったら分からないを表明してしまって
無邪気に素人質問的なものでもいいので
どんどんメンバーに聞いてみるとか教えてもらう
教えをこいにいく それを表明していくのも大事かと
そうやって理解をしていく姿勢を見せたりとか
15:00
そうするとこうなんだなっていう風に意見が出せれば
ちゃんとエンジニアリングとかにも関わってきてくれるっていう風に
そこが信頼また作られる一つなんだろうなと思って
分からなくても全部任せていくっていうのは全然違う話なので
これは大事だと思いましたので
ある意味で頼るっていうところは持っておいていいと思います
頼っちゃダメだっていう風に思い込むとすごい大変で
いわゆるリアリティショックがおきかねないので
そこは大丈夫ですよっていうのを言い聞かせていくといいかもしれないですね
あと今からEMにチャレンジする人
他のチームでEMやってて新しいチームに移る人も大体似てると思いますけど
前人がいたらそれはそれであれですけど
新しくチームのエンジニアリングマネージャーに結局なるので
マネージャーとしての信頼関係とかっていう
あと実績みたいなのはまだゼロですから
そこは最初から100%こうだこうだとか
バリバリスタートダッシュで実績出さなきゃいけないっていう風に思うのも
いきなり辛くなって苦重いので
冒頭も言った通りEMっていうのは責任はあるけど
やることは結構不確定だし
やってみてどうなのっていう結果も分からないので
最初から重く持ちすぎなく
失敗してもまあなんとかなるわとか
失敗したらみんなにごめんなさいして一緒に頑張っていこうみたいな
ぐらいの軽い気持ちで始めた方が
僕はいいと思ってます
軽いからそれは無責任という意味ではないです
責任はもちろんちゃんとありますのでマネージャーとしてね
ただまだマネージャー1年生みたいなところだと思うので
そこもメンバーとしっかり会話ができていればもっといいんでしょうけどね
ただ思い込みすぎて
ついていくマネージャーがへこんでしまったりしたら
それはもともとないのでね
心は強く生きたい
そうださっき言いたかったことは
鋼のメンタルを持ってる人はある意味で
それが最強の武器かもしれないという話ですね
次の日にはコロッと直ってたりとか
昨日は昨日今日は今日ということで
割り切りがスパッとできる人とかも最強かもしれないですね
さっきの教えてもらうとかもそうだし
自分がそんな尖ってるわけではないけどっていうところに
何のコンプレックス的なところとか
ネガティブな感情とか全くない人っていうのは
強いですね
それだけで全然メンバーにどんどん取り込めたり
どんどんぶつかっていきやすいと思うので
自分そこほんと苦手なんですけど
苦手っていうのは分かった
じゃあどうするって結局やるしかないしぶつかっていくしかないので
本当に信頼されたかったりしたら
自分は自分で生存戦略考えたり
どういうマネージャーになっていくかっていうのを
18:00
考え直していったり自分を
デコ入れするだけの話ですのでね
ただそのチームでの信頼がなくなってしまったら難しいので
信頼は完全になくなることはないと思いますけど
また大変な道だけど自分を変えて
信頼関係をしっかり構築しにいくっていう
そのためには結局実績ですね
実績をどんどん積み上げていったり
ちょっとずつメンバーのサポートとかヘルプとか
大変なところになっていって
いわゆるサーバードリーダーシップじゃないですけど
っぽい動きをしていってメンバーを助けをしていく中で
ちょっとルーツ作っていくにほかならないと思ってますので
もうやればいいんじゃないかなっていうので
最悪会社をなんとかしてくれるぐらいの
あれだけではないです
マインドは良くないですけど
最悪は会社がなんとかしてくれたり周りのメンバーも
なんとかしてくれるぐらいの頼る気持ちで
いっても最初はいいんじゃないかなと思いましたね
ただよく言われていることとして
やっぱり
組織の成果を最大化をするっていうんですけど
その成果って何かっていうと
目標とかって何かっていうと結局経営人とか
会社自体が目指している世界の中を
描いてる青写真を
具現化実現化していくかっていうところを
しっかりドリルダウンしてこのチームでは
じゃあそのためにこういう目標を立てましょうとか
チームとしてこういう目標を立ててメンバーとしては
じゃあこれを目標立てて追っていきましょうみたいな
どこまでしっかり落とし込めていったり翻訳して
メンバーに伝えられる言語化できるってところが
しっかりやっていくしかない
苦手だとしてもやっていくしかない
本当に自分自身で苦手だったら
他のEMとかマネージャーとか
EM自身も上の人がいるはず評価をする人が出てくるので
相談をして一緒に言語化
作っていけばいいんじゃないかなと思います
一人で抱え込まんじゃったら大変だと思いますね
そういう意味でいくとEMってやっぱり小っちゃな会社
小会社の代表までいかないですけど
副社長レベルからみたいな感覚はあって
やること全部やるためには
経営層が見ている数字だったり
描こうとしている世界観とか実現しようとしているものっていうのを
理解をしなきゃいけない
それとほぼ経営に近いところですよね
経営をするわけではないですけど経営者の見ている世界観とか
ちゃんと理解をするにはほぼ自分も経営者ぐらいのスタンス
それを勉強したりキャッチアップするときは
そういうキャップを被っているぐらいの感覚でやっていかなきゃいけないので
EMというポジションは
キャップを被り分けるという感覚は持っておいたほうが
やっぱりいいんだろうなと思っていて
経営はしないが経営に関しても興味関心を持っていかなきゃ
いけないと
僕は僕に思ってますけど他の人にはそう言わんが
21:01
でも持っておいたらそういう観点とか
気持ちでいるほうがやりやすいんじゃないかな
とは思ったりしますね
あとは101のお話かな
EMってさっきも言った通り
ピープルマネジメントが一番重いと
それは評価もあるし評価結果
査定後のフィードバックもしなきゃいけなかったりもするし
それのためには日頃からの信頼環境を作らなきゃいけなくて
そのためにやはり101が一番の鍵であり
僕の中では101が一番大事なEMのお仕事だろうと
思っていたりします
なので101でどういうコミュニケーションを取るとか
メンバーに対してどういうアプローチをしたりとか
どうやって目標を一緒に達成できるか
っていうのを考えていくみたいなところを
日頃から考えていかなきゃいけないっていうのは
今僕は喋りながらちょっとうわーって自分を反省しているところですね
後悔じゃないです反省をしているところなので
明日からまたやり直し頑張っていきたいと思っちゃいましたね
また明日は僕木曜日なので
木曜日は僕メンバー全員とのワンワンの日なので
今からまた準備してやっていこうかなと思っております
こんなところですかね
EMって最後にちょっと長くなってきたんで
そろそろ終わらなきゃまたブログ書けないんですけど
EMの一番の大変さっていうのは
さっきも言ったように何をやるかってまだ決まってないっていうのもありますけど
成功の定義とかEMとして評価ですね
EM自身が評価されるときって
何をもって評価するかっていうと
やっぱりチームの目標とか成果ってところが
EMの評価になると思って
ただプロダクトオーナーとかプロダクトマネージャー
PDMもいたりするチームもあると思いますけど
その場合は完全にEMが責任を持つわけではないが
EMはやっぱりものづくりをしていく
評価するのはエンジニアなので
そのチームが成果を出すっていうのがすごく大事
そのチームの成果って結局グラスのチームそのものですね
開発チームじゃなくてサービスチーム全体としての成果とか目標っていうのは話が出てきて
それの達成ができなかったっていうのはつまりものができてないって話
結局はなっちゃうので
そこはEM同士の責務が重いわけなので
そこは最後自覚はしなきゃいけない
心構えというか覚悟のところかもしれないですけど
そのためにはチーム外のところにもどんどん
ヘルプを求めていったりサポートをもらったり
壁打ちをしてもらったりとか
時にはさらに上の人たちの
カードを切るっていうとあれですけど言葉を借りたり
もしくはその人たちにまさかチームに来ていただいて
ちょっと葉っぱをかけてもらったりとかも
24:03
お願いするポジションとしてはいいのかもしれないですね
やはり僕はそういう上の人とか経営層からも
ほんと頼むって言われたら
やっぱじゃあやるしかないなっていうので本気出たりするんですけど
それはメンバー次第かもしれないですけど
でも時にはマネージャーとしてそういう風なことが大事だと思うんだったら
全然そういうのやっていいと思うし
カードを切っていいと思います
エンジニアリングマネージャーって最終的に名前の話に戻るんですけど
エンジニアリングをマネージメントする人って
誰が名前つけたんだこれって
全然エンジニアリング関係ないところめちゃくちゃやるなって思いました
エンジニアリングを担当する人たちを間接的にやる
という意味だとEMという名前もそうかもしれないですけど
エンジニアリングそのもののマネージメントといったら
テクノロジーがすごく強そうなイメージになっちゃうので
EMの名前を僕は違和感を持っていたりしますけど
やってきて思うのは
エンジニアリングマネージャーって
EMってエンジニアリングマネージャーと
エンジニアマネージャー両方持つんだなっていう感じですね
実際エンジニアマネージャーで名乗っている方も
たまに見ましたねブログとかでも見ますけど
peopleの時点でエンジニアを
マネージメントする人って感じですからね
エンジニアリングマネージャーって言葉の定義だと思いますけど
エンジニアマネージャーも入るって意味で
名前を変えたくなってきたなっていうのが思ったりしますね
めっちゃ喋ってた
30分のソロ近づいたので
これを聞きながら改めて僕はブログ書けそうに
思えてきたので
頑張って書いていきたいなと思っています
参考になったら幸いですし
自分はこう思うよとかそこは間違ってないみたいなところに
ご指摘あったら
強くはないですけど
まさかりはいただきたい派の人なので
そういうの嬉しいなと思っています
では遅くなりましたので今日は終わっていきたいと思います
こんな感じで毎日
不定期に
いろいろ喋っているので
面白かったというか学びがあったとか
続けてほしいなという方がいらっしゃいましたら
ぜひサブスクライブしていただければと思います
じゃあ終わりたいと思いますお疲れ様でした
バイバイ
