エンジニアリングマネージャーの課題
こんにちは、シニアソフトウェアエンジニアのリドルです。
こんにちは、リドルソフトウェアエンジニアのひびのです。
このポッドキャストでは、2人でキャリアや困ったことなど、IT業界のリアルをガンガン届けていこうという趣旨の番組になっております。
今日のテーマが…
今日のテーマはですね、「エンジニアリングマネージャーお悩み相談室」っていう本をですね、私が最近買ったんですけども、
この本結構個人的には良い本だったので、これを使ってですね、現役のエンジニアリングマネージャーであるひびのさんのお悩みをですね、聞いて、本をベースに解決してあげようと。
駆け出しですけどね。
はい。いや、駆け出しリクエスト読んでほしいな、いっぱい書いてある。
ちょっとこのポッドキャストの収録が終わったらこっちどうかなというのを思いました。
早くない?まだ読んでからで良くない?
そうですね、しっかりと読み進めたリドルさんが、力をさらに伝えてくれました。
そんな、ちゃんと読んでないんで。
どっちかっていうと、ひびのさんのリアルな問題に対して、この本だったらこういう風に書いてくれてるよっていうのが、ピンとくれば買った方がいいかなって感じですね。
なるほどなるほど。それでいうとお悩み三席ですよね。
本当ですか。じゃあ早速お悩みいくつかもらっていいですか。
お悩みいくつか、最近特に悩んでるのは、やっぱりエンジニアリングマネージャー。
エンジニアのメンバーの人たちのピープルマネージメントと、大きな役割としてエンジニアの人たちのピープルマネージメント。
あとそれから、チームとか事業部とか、そういう組織団員で活動を前に進めるっていう、なんか両輪で2つ大きな役割があると思ってて、どっちもおろそかにできないじゃないですか。
はい、そうですね。
バランスが難しいなと思ってます。
事業を前に進めようとすると、短期的な目線でいうと、最早みんなに残業してもらってたくさん開発するとか、それもソリューションとしてはよくはないですけど、1つあるじゃないですか。
ピープルマネージャーとしては最悪ですよね。
最悪ですね。
とはいえ、どっちも大事だなっていうのは自分でも理解しているから、いや、どっちも捨てられない。この時どうすべきなんだ、みたいなことは悩むことが多いですね。
コミュニケーションの重要性
なるほど。ありがとうございます。
ちなみにですね、そのお悩みはですね、書いてないんですけど。
ほんと?
書いてないんですけど、でも個人的な話だけで言うと、ピープルマネジメントとその事業を前に進めるマネジメントを別の方が担当してなくてよかったですね。
なあ。
別の人が担当してると、絶対にお互いに譲らないじゃないですか。
なあ、そうですね。
それぞれの目標を達成するから。
そうですよね。それぞれ目標が食い違ってるとは、何というか、常にお互いで交渉し合う感じになっちゃいましたね。
うん。当然ひめのさんの場合は、うちなる自分の中だけで解決すればいいから、それと比較するとまだマシ。
まあまあそうですね。何というか、チーム単位で喧嘩になってしまわないというか、自分の中での葛藤で収まっているという点では、本人ではありますね。
そうですね。結局あとは、その事業によって達成したいものが本当にどこまで達成したいのかみたいなもので、多少メンバーに頑張ってもらうフェーズが、
2,3回あるかどうかみたいな感じのバランスぐらいですよね、きっと。
ああ、なるほど。それこそリドルさんも僕が所属してたチームでマネージャーだった時期だったじゃないですか。
その時に例えば、年に3回くらいは頑張ってもらわないといけないなみたいな、なんとなく肌感を掴んで仕事を振ってた感じなんですか?
いや、そうじゃなくて、というのは私、ピープルマネージメントやってましたけど、プロジェクトのマネージメントの方は何もやってないので、
確かにそうか、タスク自体はリドルさんを通じてアサインされるという形式じゃなかったですもんね。
そうですね、とはいえなんとなく稼働状況がわかっているので、施策の流度とか内容みたいなところは事前に聞いておいて、
なんかそれ今ちょっと難しそうですねとか、このチームだとこの人のヘルプをちょっと入れてもらわないと厳しいかもしれませんみたいな話は、
プロジェクトをある程度コントロールしてるプロジェクトマネージャーの方と会話して、
なんかこう人をちょっとこっちチームちょっと行ってくださいとか、こっちチーム手伝ってくださいみたいなことをやったりはしてましたね。
なるほど、じゃあその直接事業を進めるっていうよりは、ピープルマネージャー観点でその事業の進捗度合いをコントロール、間接的にコントロールするというか、そういう役割だったってことですね。
あとは自分をユーティリティープレイヤーとして奥の手みたいな感じで使うみたいなこともやってましたね。
そうですね、僕本当に申し訳ないことを思い出したんですけど、確かリドルさんがマネージャーに就任して3日目くらいで、僕の妻が病院に運ばれて、
僕が稼働できなくなったから急遽、しかもその時超反暴気で、
そんなことあったの。
奥の手としてのリドルさんを早速使わせてしまったなっていうのを今思い出しました。
そういう意味では今ひみのさんがどういう動き方してるかわかんないですけど、もしプレイングもしてるならプレイングの分はもうなしにして、
マネージメントに徹して、じゃあという時だけ動けるような体にしておくみたいなのはありですよね。
そうですね、確かに自分も今そうしたいとは思ってるんですが、
僕が直接マネージメントしてるメンバーが3人かな、プレイングせざるを得ないという状況なのはあり、
あとかつ今の開発チームで一つのプロダクトを見てるんですけど、
僕の扱ってるサービスだとモバイルアプリとサーバーと技術領域を大きく分けて2つあって、
サーバーの知識が現状僕にかなり偏っているという状況があって。
そうなるとなかなか厳しいですね。
そうですね、モバイルアプリのエンジニアの人でもサーバーをちょくちょく触ってくれるみたいな人はいて、
それこそ8月、9月あたりは徐々にそういう人に意識を共有していく。
自分で自分に開発するっていうところはちょっと手を離していきたいなとは考えている。
そううまくいくか、余裕が生まれるほどタスクが少なくないかもしれないですね。
じゃあもう一人でしかないな。
はい。
ちょっと次の悩みに行きましょう。この本から答えられるやつ。
答えられるやつ。次の悩み、なんとなく僕自身そもそも別に人と話すのが得意な方っていうわけでもないなとは自分で思ってるんですけど、
ワンオンは難しいなって思ってます。
というと何が難しいんですか?
というのもなんというかワンオンの主目的いろいろあると思うんですけど、
多分一番マネージャーとしてメンバーとワンオンしていて期待される成果としては、
例えば僕との対話を通じてメンバーの内省を促したりとか、
あとは僕自身がメンバーから課題感を吸い上げて、
僕が何かした方が解決しやすいこと、僕が何かアクションを起こせるようにするみたいなコミュニケーションをしたりだとか、
そういうところだと思うんですけど、
人と話してて、例えばいきなり今悩みありますかって聞いても、
いないっすねみたいな感じになるのが普通だと思うんですよ。
なかなかそういうワンオンワンの目的に沿うような意味のある話が、
そんなにまだまだ上手くできてないんじゃないかなっていうのを思ってます。
いいですね、いい悩みだと思います。
残念ながらこの本には書いてませんでした。
ちょっとちかしいやつで言うと、
メンバーに全く共感できないんですが、マネージャー失格ですかっていうお悩みと、
あとネガティブなフィードバックができません。
っていうお悩みが書かれていました。
それで言うと、僕ネガティブなフィードバック苦手ですね。
OKです。
ちょっとそれは回答しますが、
その前にさっきのワンオンワンで、
どうやってその悩み事をうまくヒアリングするかみたいな話ですよね。
多分2つやり方があって、個人的にはですよ。
1つはヤフーのワンオンワンの教科書みたいな本かなんかで提案されてたフレームワークで、
9つの証言に分けて出来事というか考えてることを区切って質問していくといいよみたいなものがあって、
これひみのさんにも使ったことあるんですけど。
そうなんですね。
横軸が過去、現在、未来で、縦軸が自分、チーム、組織みたいな。
そうすると9つに3×3なんで9つに分けられるんですけど、
例えば現在の時間軸で自分レベル、現場レベルの話だとすると、
自分が今やってる業務の話、良かった点だったり悪かった点みたいなことをトピックとして掘り下げるみたいな話になりますし、
これが部とかチームとかになると、そのチームがやっていることと現在の状況。
これが未来になったらそのチームが中長期でやろうとしていること。
過去になったらなんでこういう感じに今までなってきたのかみたいな話。
ということで、いろいろバリエーションが9パターンあるといろいろ深掘れるんですね。
そうですね、確かに何かその場で話しているトピックがあるとしたら、横移動、縦移動で話の幅を広げられるというか。
そうですね、だいたいそれぞれのトピックについて何ヶ月に1回ぐらい話すといいよみたいなのが決まってるというか、設定されてたんですよ。
要するに過去の話ってそんなに頻度高くしなくてもいいよねとか、事業レベルとか事業全体レベルの未来の話って、
ミッションバリアみたいな話になるので、そんな変わるものでもないから何ヶ月に1回でいいよねみたいなのがあるんですけど、
一方で自分の身の回りのこととか、このちょっと先の未来のこととかはもっと頻繁に話した方がいいよねみたいなものがあって、
それをベースにこの1011回につき1テーマを話すみたいな感じなんですよ。
そうなると2つ目の方法として、普段からマネージャーが各個人のスラックとかやってるタスクを一通り追っておくみたいな方法があるんですけど、
この2つをうまく掛け合わせると、最近こういう仕事をしてて、こういうプールリークのコメントもらってたんだけどとか、
いくつかタスクこなしてもらったけど、詰まったところはありますかとか、この辺こういうコメントを受け取ってみてどうでしたか、
みたいなことをこちら用意するでもいいし、2つにあのタスクどうでしたかみたいなピンポイントで聞いてみるっていうのもアリだと思いますね。
なるほどなるほど、さすがに。
今おっしゃってた方法からその当人の悩みだったりとか、次こういうことが起こり得るからどうしていこうねみたいな話はしやすそうですね。
そうですね、あとは相手にたくさん喋ってもらうとどのずと出てくるというか。
雑談の役割
なるほどなるほど。
ちなみにそれで言うと、もう一つワンオンで思ってることとして、ワンオンで業務関係ない雑談になることとか結構ありませんか。
ありますね、はい。
ありますよね、なんかそれって何だろう、例えばその人と自分の関係性を深めるっていう意味ではそれは良いでしょう。
本当にこんなことに時間を使っていいのかみたいな。
それはどっちのポジションとしてですか、マネージャー?それとも受け手側?
それはなんというか、今マネージメントとしてワンオンに関わって思って、よりなんかその自分に対してもあまり身になってないし、メンバーに対しても身になってないんじゃないかっていうことをより強くするようになったというか。
マネージャー側としてより認識するというか、この次は無意味じゃねみたいな。
あーそう、そうです。そうなんですよ、雑談は雑談で楽しいは楽しいんですが。
雑談の内容にもよりますけど、基本的にはウェルカムだと思っていて、それに差し迫った課題がないというか、課題に。
なんで特にそのフィードバックを早くしないといけないとか、こちら側が早く対応しないといけない、事象がないということが確認できたっていうのも一つ成果だと思っていて、
時代ないんでワンワンやらなくて良くないですかっていう連絡先に組んでいれば良くないみたいな話もあるんですけど、もう一個あって、やっぱりその雑談を通じて仲良くなるっていうと語弊ありますけど、親しくなるってなんかあるんですよね。
まあそうですね。 単純に受け売りなんですけど、サル山の毛づくろいっていう話があって、サル山があってその群れに所属するサルかどうかって、ぱっと見あんまり個体差だとわかんないじゃないですか、どのサルがこのサル山で、このサルはこっちのサル山みたいな。
お互いにどうやって仲間を認識してるかっていうのが、サルはお互いに毛づくろいをしていて、毛づくろいを言うと仲間と認められるみたいな。
フィードバックの重要性
で、一転して人間だと、それが雑談みたいな話があって、僕の話に論文で言われてるというか、そういう話ありますよねっていうだけの話なんですけど、その雑談、スモールトークみたいなものをやっておくと関係性が構築できるとか、雑談の中で自分の恥ずかしい部分というかプライベートな部分をより多く見せると、
ジョハリの窓っていう心理学のテクニックみたいなやつあるんですけど、関係性には近しくなるみたいな。
そういう構築にあったと考えれば、仕事の一環なのではとは思えなくもないかなっていう、ちょっと理論無双してみたいになってるけど。
おっしゃる通り、なんかおっしゃる通りだと思いました。
騙されてるよ。これっぽいこと言うと騙されちゃうよ。
やばいやばい。さっき話していたネガティブなフィードバックが苦手ですみたいな話も気になります。
ありがとうございます。ひとりにこの本を開く時が来ました。
この本の紹介と言いながらやっと紹介に入ります。
ここ書いてありますね、アドバイス。人や人格ではなく行動に対してフィードバックをしよう。
強調しておきたいのはフィードバックは決して相手を攻めるための行為ではなく、チームの成果を最大化する上で必要なコミュニケーションだということです。
いろんな悪い感情が思いつくかもしれませんが、逆にきちんと伝えられないと余計にこずれちゃうかもしれません。
そこからいろいろ書いてあるんですけど、自分の行動に蓋をしている原因をまず探しましょうと。
要するにネガティブなフィードバックができない自分側の理由ってなんだっけみたいな。
それを大体の場合、こういう評価が皆さんから来ていて、こういうところがあなたは悪いので、これやめてくださいよみたいなことを急にワンオーワンで言うと、
周りでもびっくりしちゃいますよと。そのびっくりさせるっていうのが自分的にもう嬉しくはないですよね。
意識も下がっちゃうかもしれないし。なので、一手に脳を突きつけるっていう思いではなくて、
あくまでこういった行動に対しての認識を擦り合わせたいのだみたいな感じで取り合わせて、
例えば、なんか悪い発言を、悪い発言というか、誤解を見ような発言をAさんがしたとしたら、Aさんと話す時に、
自分だけ聞くと否定的に見えたけど、その背景があれば皆の捉え方も変わるかもしれないから教えてほしいみたいなことを言いましょうとか、
なんかそのAさんの頭の中をちょっと覗いてみるかのような質問をAさんと一緒にやっていくことで、
そのAさんの裏側の気持ちは、例えばすごい良いものがあったりする。
例えば、チームが結構みんな道なさげにやってたりとか、あんまり会議の場で発言しないから、
みんななんで会議で発言しないんだみたいなことを言ってしまったみたいなケースにおいて、
それはAさんの中ではこういうふうにすればみんなもっと発言してくれるんじゃないかみたいなことを思ってくれたこと自体はとても良いことなので、
その結果としての行動が逆に意識させるものであったということだけが問題なので、
それをAさんと一緒に解き明かした上で、特定のアクションだけを別のものに差し替えるにはどうすればいいかみたいな話をしていくことで、
ネガティブというよりかはよりポジティブなフィードバックになりますよねみたいなことが、
めちゃくちゃ回数まで説明しましたけど、5、6ページぐらいに渡って書かれています。
ネガティブなフィードバックの扱い
確かに今の話を聞いて、最初に攻めるべきは悪い行動だけだっていう前提があるから、
それに至った経緯をまず2人で確認したのち、フィードバックに入るっていうのは少しマイルドになりそうですね。
いっぱいいいこと書いてあるから、即興で要約するのはめちゃくちゃ難しいな。
めちゃくちゃな結論になったら申し訳ないです。すみません。
ちなみにその本、その本はこういうお悩みに対しての説明というのはもう一等的な構成なんですか?
そうですね。悩みが合計で17書いてあって、ジャンル分けはされてるんですけども、
ちょっとかいつまんで言うと、例えばどうやったら自立的なチームになりますかとか、
メンバーに仕事を振るのが苦手です。
あとは、チームと経営方針のすれ違い悩んでいます。
あとは、これは自分もめちゃ刺さったんですけど、雰囲気はいいけど目標は達成できませんでした。
採用活動って何から始めたらいいですか?
エンジニアリングの勘が失われるのが怖いです。
そうですね。僕が今みたいな働き方をするのと同時にAIが出てきたので、
特にそこは割り切って考えるようになりましたね。
それはもうAIあるから別にいいかっていう?
いや、仮に僕が手を動かす労力だとしても、
どちらかというとAIをマネジメントするっていう仕事の方が今は多いのかなと思ってて。
ああ、なるほど。
でもエンジニアリングの勘っていうところが、
AIのバイブコーディングなのか、
そういうAIと協調した感じのコーディングをすることの知識がつかないのが怖いみたいなのがあるんじゃないですか。
それはないですか?
それで言うと、多分僕が今チームを務めつつ行動をかけてるのってAIのおかげだと思っていて。
ああ、そういうことですね。
じゃあ違うな。
そうですね。
あと今紹介してくださった中で、
エンジニアリングの勘が失われるのが怖いに似てる話かもしれないんですけど、
なかなかマネージャーって孤独じゃないですか。
そう。
というのは、孤独っていう話とも違うのかな。
なんかこれまでメンバー目線だとほぼ必ずチームにマネージャーがいますよね。
はい。
で、なんというか言ってみたら、
でかつ僕幸いなことにこれまで所属してたチームのマネージャーの人たちってみんな本当に尊敬できる、
なんか自分のロールモデルにできるような人たちだらけだったんですよ。
そういう人が今僕はこの立場で自分と自分が働いているチームにいない状態で、
誰を目指して働けばいいのかみたいなところが今ない状態で、
なんか空虚さを感じているというか。
それはもうあれですね。
心の中に理想のマネージャーを作るしかないですよね。
よく言いますね。
過去のマネージャーを脳内にたまに飼ってますね。
でもそれしかないですよね。
ある程度キャリア進むと自分が最前線に立つとか、
自分と同じキャリアを歩んでいる人が先輩にいないみたいなことがあり得るので、
そうなると心の中に飼うか、全然別業界の人を持ってきて、
精神的なところを真似するとか、そういうのが多いですよね。
なるほどね。
確かにマネージャー層とか部長クラスの人たちって、
この本を書いたこういう人を尊敬してますとか、
歴史上の偉人の人を尊敬してますみたいなことを言ってる人がたまにあるなと思ってて、
今はそういう事情があってそれに至ってるのかなって思いました。
すごいね。
会社のワリモレさんとかわかんないし、
ワリの部の部長とかも見えないじゃないですか、何やってるかとかって。
そうなんですよね。
一応多分今僕の一つ、
僕がワンオンにおけるメンバー側でマネージャーっていう立場の人は、
僕が出向している子会社のCTOの方にあたると思うんですけど、
マネージャーとしての孤独
その人も基本的にはほぼ別のプロジェクトで働いていて、
一緒に働いているっていうタイミングもあるはあるけど、
同じ業務をずっとやっているみたいな感じではないので、
このちょうど一つ上に参考にできる人がいないみたいな状況が多分今続いていて。
確かにそれは大変ですよね。
確かにおっしゃる通り、ある程度のところまで来ればそれはそうですよね。
そうですね。
もし単純に相談相手がいないとかだったらちょっと難しいかもしれないですけど、
チームのマネージャーとかエンジニアリングマネージャーをやっている人に声かけてワンオンさせてもらうとか。
リラロールで経験のある人っていうのは、それは参考にできそうですね。
そうですね。それは割とやられている感じがありますね。
良さそう。そして、それを聞いて思ったのが、
直近の僕のマネージャーだった人、もうほぼ今会社にいないなっていう。
ちょっと待って、まだこの本の紹介そんなにしてない。
じゃあ逆になんか今僕が話したようなのとはちょっと、
これ明らかに程度が違うなみたいな質問があったりします。
メンバーの成果を周囲に認めてもらえません。
あとは、職種のマネジメントをすることに何から始めればいい?
なるほど。
これ難しいですよね。
当時の僕の上司というか、オンラインのベッティングサービスをやった時の上司は、
それこそ下にエンジニアの自分とか、デザイナーの方もいたし、
事業側の人もいたし、データ分析チームもいたし、何でもあるなみたいな。
一時期僕の直属のマネージャーだったタイミングもありましたよね、多分彼は。
いや、彼女の話をしてましたね。女性の話をしてました。
そうですね。
だから何でもやってるから、特に専門的なことって難しいじゃないですか。
そうですね。
どうなると、多職種のマネジメントって難しいなと思うんですけど。
僕、これまで、一時的に自分の直属の上司がエンジニアじゃなかったことって、
タイミング的には何回かあったんですけど、
そういうタイミングはもうそういうタイミングで、成果の説明の仕方を全部変えるみたいなことはやってましたね。
確かにメンバーとしては、それはいいですよね。
マネージャー側としてはどうするか。
確かに、多分僕がペラペラ喋って、うまく騙されてくれてしまっている人もいたかもしれないですね。
悪い言い方ですけど。
結局、この本でもそういうことに踏み込んでくれていて、アドバイスとしていろいろ書かれてるんですけど、紹介すると、
詰まるところ相手のことをとにかく知りましょう、気にかけましょう、みたいなところで、
結局ね、ここはみんな同じプロダクトに向き合う。
これプロダクト開発の前提なんですけど、プロダクトに向き合っている仲間だから、
結構あんま変わんないよね。
ここはいえ、例えばデザイン全く知らない人がそのままレジャーになるっていうのは厳しいので、
座学しっかりやりましょうと。
なるほど。
多足しての人を見るということがあれば、
その、なんというか、上界については最低限しっかり自分も知る努力をしましょうって感じですかね。
そうですね。
いきなりどういうことをやるというかは、
デザインの実を例えば身につけて、
定例で使う資料をちょっときれいにしてみるとか、
そういうデザイナーの駆け出しにも及ばないけど、ちょっとしたものをやってみて、
どういうところに気をつけてるんだろうってことを知ったり、
デザイナーって一口に言っても、グラフィックとかUIとかUXとかいろんな種類あるので、
その人たちがそれぞれどういうところに専門性があって、
どういうところのアウトプットを見ればその人ことを判断できるかというか、
どうかできるかみたいなところを気にしましょうみたいなことが書かれていて、
そういうことをやってると、
そういうところで、わりと向こうも近づいてきてくれるというか、
歩み寄ってきてくれるみたいなところがあるので、
まずはそれをやりましょう。
なるほど、なるほど。
でも毎日にやったほうが難しいですよね。
まあ、そうですよね。
でもとはいえ、とはいえ、
例えばデザイナーの方が完全に個人でプラッターを使って、
いや、なりますね、それは。
そうそう、たぶんそういうことなんだよ。
いや、確かにそれは気持ちはわかるな。
今後のキャリアで加速師の方を見ることがあるかどうかはわかんないですけど、
これは確かに今大事なので。
絶対ね、可能性はあると思うんですよね。
年齢とか年齢とかに関してはね、
そうですね。
まるっとQAチームを見てよとか、
KTチームを見てよとか、
ちょっとなんかエンジニアチックだから、
データ系も全部見てみたいなこと言われないとも限らないじゃないですか。
そうですね。
AIチームを見ていいよみたいな。
なんというか、野球とサッカーを同じに見ることができるかどうかはわかんないですけど、
そういうのが大事だと思うんですよね。
AIチームを見ていいよみたいな。
なんというか、野球とサッカーを同じスポーツとしてくくってるようなもんですよね。
そうですね。
エンジニアリングマネージャーの悩み
なのでそういった形でいろいろと学びながら、
わからないといって遠ざけるんじゃなくて、
どこがわからないのかを明確にしながらフックを増やしていって、
その業界とかその人とかその仕事のことをいろいろと知っていきましょうと。
正しい。完全に正しい。
あと、背中を見せることはできないじゃないですか、技術的な意味で。
エンジニアとして、別にシニアなわけじゃないから、
ワンオンで話したところでも技術的な課題解決がAIエンジニアに対してできるわけじゃないじゃないですか。
文外科の人が。
そうですね。
これは今の自分の状況なんですけど、
今、マネジメントをしているかつプレイングをしているかつ、
今のチーム、開発チームのエンジニアでは厳密には違うんですけど、
今のプロダクトに携わっている歴が一番長いんですよ、僕。
エンジニアとして背中を見せるタイミングもまあまああって。
いいですね。いいパターンですね。
いや、いや、しんどいっすよ。
確かにそうですね、一人何役も得るのはしんどいですね。
はい、なかなかその一人の人間に収まるところ、収まる要素から若干もう本当に一つ一つこぼれて、こぼれ落ちてしまっている理覚が、
それはそれで辛いですが、エンジニアリングマネーでは専業は専業で、そういった辛さもあるんでしょうね。
そうですね、忙しすぎてどうにかしたいですみたいなお悩みは書いてなかったんですけど、忙しいですよね。
あとは仮に集中できたとしても、今度は経営のことに近づいて考えないといけないとか、
もうちょっと中長期のチームだったり組織のことを考えないといけないっていうところで、別の頭の使い方というか時間の使い方をすると思うので、しかも慣れてないだろうし。
確かに、そういうことを考えなきゃいけないタイミングって本当になんというか、スムーズに、その考えるタスクをスムーズに処理することが最初できないですね。
うん、そうですよね。
なぜなら慣れてないから。
慣れてないし、しかも慣れたとしても正解がわかんないから、本当に説明しづらいというか、こっちに行きたいです、理由はこうだからです、私別に証拠はありませんみたいな、説明しなきゃいけないから。
そこまで行ったら本当に最後は自分を信じるしかないですね。
ということは自分を信じさせるためのいろんな方法を普段からメンバーに対しては打っとかないといけないですね。
種巻きは。
そうか。自分自身が自分を信じるだけじゃなくて、自分に権限があったとしてもメンバーから合意を取るというか、そこも大事ではありますね。
最近やめられちゃうかな。
そうするとね、もっと大変だから。そうすると日頃の種巻き、それがワンワンワンなのか、もしくは別な道なのかわかんないですけど、やると忙しいですよね。
僕が今の会社に転職してきて最初にエミュアリングマネージャーだった方がいて、
結構頻繁にこれは頭出しなんですけどみたいな感じで、本当に最終的にそうはならなかったこともポンポン共有してくれる人で、
それはそれで、この人はこういうことを考えてこうしようとしてるんだなみたいなことがわかりやすくてよかったですね。
確かに上にあるといろんな情報が出てくる反面、実績にこうって決まるものは意外と少なかったりするから、それだけ降りてくると、
仕事してるのかな上の人みたいな感じになりますよね。
例えば人によってはもしかしたら、いや決まってないことをわざわざ投げてくれないよみたいなこともあるかもしれないですもんね。
確かにあれどうなったんだっけみたいなね、ずっとヤキモキしたりする可能性ありますしね。
確かに僕もその時、そういえばあの話どうなったんだろうなーみたいなことを思ってたタイミングはなくもないっすね。
そうっす。
なんかそういう意味でもなんかコミュニケーション、なかなか何というか、相手が気にしてそうなことでアップデートがあったらしっかりその次のタイミングで伝えるとかも大事なんですかね。
そうですね、相手が気になってることはやっぱり伝えてあげたりとかする方がいいっすね。
前に話してたアサインするかもってタスク、ごめんなくなったわみたいな。
そうそうそうそう。
確かにそれは大事ですね。重要じゃなくてもどうしてもなんだろう、気にしてたら脳の片隅でリソースをずっと食い続けるという。
はい、ということで今回はエンジニアリングマネージャーお悩み相談室の本を使っていくつか回答しながら、プラス自分の経験で皆さんの相談をいくつか答えました。
新田氏の著書とポッドキャスト
ありがとうございます。大変単になりました。
自分もこの本を知ったのは本当たまたまで、この本を書かれた新田さん?
レイヤーXの人?レイヤーX?
そうかも、分かんない。レイヤーXじゃない、XXでしょ。
レイヤーXですね。何かどこかで登壇されていた名前をお見かけしたなという。
本当ですか。その方がですね、ポッドキャストを何か最近始めてしまして、ヒントも1回使えないかな。
同じくエンジニアリングマネージャーを結構得意とされていて、本も出されている方ですね。
イクオさんって方かな。その2人で始めたポッドキャストでこの本を紹介されていたので気になってポツって、自分はポッドキャストのネタに使うという感じでした。
ポッドキャストで紹介し、それをまたポッドキャストで紹介するというSBTですね。
いつ頃の本ですか?いつ頃最初に出たんですか?
この本は2025年7月7日初半です。
まだまだ全然新しい本ですね。
まだ1ヶ月ぐらいしたくない。収録日が8月16日なんで、7月7日は1ヶ月ちょい前ぐらい。
買いましょう。買います。
エンジニアリングマネージャーになっている方、なりたい方で、よくあるお悩みについてですね、いろいろと知っておきたいという方は、ぜひですね、ご購入ください。
僕も買います。
これは別に宣伝じゃなく、単純に一個人が勝手に言ってるだけです。
ということで、今回は終わろうと思います。
このポーズキャストはハッシュタグLITで皆様からの感想やコメント募集しております。
また、チャンネルの概要欄にGoogleフォームのリンクもありますので、そちらからのご投稿も大歓迎です。
ありがとうございました。
ありがとうございました。
