エンジニアリングチームの問題
株式会社KabuK Styleの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、公開1on1です。ゲストをお呼びして、ちょっと1on1チェックにお話ししてみるという、これまでちょっとやったことないようなパターンで、今日はお送りしてみようと思っています。
エンジニアリングマネージャーの問題集。本日のゲストをご紹介します。株式会社KabuK Styleエンジニアリングマネージャーの天形元輝さんです。元輝さん、軽く自己紹介をお願いします。
はい、よろしくお願いします。今、エンジニアリングマネージャーをしている元輝と申します。後藤さんとは、昨年11月から副業で入って、2月から正式に入社して、下で働いている元輝と申します。よろしくお願いします。
エンジニアリングマネージャーではありますが、フロントエンドエンジニアではあるので、頑張ってやっていこうかなと思っています。以上です。
はい、ありがとうございます。そうですね、まだ会社でエンジニアリングマネージャーとして働き始めてもらって、3ヶ月とちょっとっていうところではあるんですけれども、すでにいろいろ活躍いただいて助かってますというところだったりしております。
今日は元輝さんに会社に入って、エンジニアリングマネージャーとして入ってもらって、仕事する難しさだったり、いろいろ見えてる問題だったりだとか、そういうところいろいろあるので、お話してもらえるといいなと思ってます。
そういうわけで、どの辺から話し始めようかなと、悩む部分もいっぱいあるというか、いろんな話をしたいなと思ってるんですけど、ちょっと順を追って会社にどんなふうに入ってきたのかなっていうところから、視聴者の方にわかりやすいように話していけるといいのかなと思っておりまして。
僕の方から軽く話すと、去年の10月、11月ぐらいだったかな。まずプロジェクトがあって、そこに業務委託として入ってもらったんですよね。
はい、そうです。
ちょっとなんかその辺、元輝さんの方からこんな感じの流れでみたいなところを話してもらえます?
はい、今後藤さんがおっしゃっていたように、10月、11月ぐらいからあるプロジェクトに対してジョインをして、その時はもう完全にフロントエンドエンジニアとしてワークをしていたっていうような形でしたね。
そこから1、2ヶ月経ってから、12月に弊社の代表と後藤さんが福岡に、僕が今住んでいるのが福岡なんですけど、福岡に来てくれて、そこで代表の話を聞いて、やばい、ここの会社に入りたいと思って、
その次の日か2日後ぐらいに後藤さんとまた飲みに行って、入社したいんで、ここどう進めていけばいいですかっていうような話をしたっていうのが僕の思い出なんですけど、どうですかね?合ってますかね?
いや、なんかそれぐらいの勢いだった記憶がない。そうですね、最初に入ってもらったプロジェクトの話も実は結構いろんな苦労があって、つい最近リリースはしたんですけれども、そこは結構話したかったりもするんだけど、ちょっとこのポッドキャストとはトピックが違うので、また別の機会にと思っております。
そうですね、福岡に機会があって、なんか話がすごい盛り上がったんですよね。まずそもそも飲み会なんかで。
そうですね、これ話してもいいのかな。それで言うと、うちの代表と後藤さんともう一人の外部の方がいらっしゃったんですけど、4人でご飯食事に行って、その時にワンピースの例えをされながら会社の説明をしてもらって、その時にワンピースで言うとルフィがいたりとかウソップがいたりとかラミがいたりとかいろいろあると思うんですけど、
後藤さんのキャラクターどうやって船に乗っているかっていうのがすごいイメージ入ったし、自分自身がどのキャラクター、まあ自分はチョッパーだったんですけど、自分はチョッパーとして、この会社に今いるわって思えてしまったんで、そこで入社したいっていうのが決まって、次の日ぐらいかな、本当にもう後藤さんにすぐに連絡をするっていうような感じでした。
そうですそうです。
その時って何でしたっけ、僕はどういうふうに見えたんでしたっけ。
後藤さんはウソップに見えてましたね。
ウソップで絶対にルフィを裏切らず、最後の最後についていくし、いろいろあるけど成功にどんどん導いていくような感じでしたね。
僕なんかそういうふうに例えられたの初めてだったんで、自分で認識したことがなかったんで、なるほどなって思ったりして、まあそれも面白かったですね。
でその2日後ぐらいにまた別途あれですよね、なんか焼き鳥屋に2人行ったんですよね。
そうですね、焼き鳥屋行かせてもらって、酔っ払って僕は帰った時、ちょっとジーンズ破けてましたけど。
まあだいぶでしたけどね。
はい、だいぶ酔っ払ってましたけど。
そこで実際なんか入りたいんですみたいな話をされて、改めて知ってもらって、
じゃあ具体的にどういう入り方をしようかみたいな話もある程度そこでしたりしてたんですよね。
はい、そうですね。そこでも結構僕も多分お酒入ってたんで、すごい熱く自分の思いとかも伝えてたなっていうのを思いながら、
後藤さんにもいろいろ聞かせてもらいながら、すごい入りたいと思ってました。
そうそう、なんかそんな勢いありつつ、うちの会社としてもちゃんとエンジニアマネージャーとして入ってもらう先行プロセスを受けてもらわないといけないので、
実際年明けぐらいでしたっけ、改めて先行プロセス受けてもらって。
そうですね、僕もその時にエンジニアリングマネージャーとしてっていうところがそれでいいのかなとかちょっと思いつつも、面接受けさせてもらったっていう感じですね。
そうですよね。そういう流れを経て合格を出させていただいて、会社からは。
2月ぐらいからでしたっけ、実際フルタイムのエンジニアリングマネージャーとして働き始めてもらうっていうふうにしましたよね。
そうですね、1月半ばぐらいにはもうじゃあ行こうという話になり、2月頭が最短でフルタイムで働けるっていうことだったので、2月頭、2月1日からフルタイムに行こうっていうような形でした。
そうそう、そんなんでしたね。いや懐かしいです、すでに。
いやースピード感がありすぎて、今やっていることが多すぎて結構本当に昔の話に聞こえてますね。
そうっすよね。はい。
ちなみにそんな感じでエンジニアリングマネージャーとして働き始めてもらうことになったんですけれども、
どうです?僕と話す前にエンジニアリングマネージャーとして仕事するみたいなところって、元気さんの中でイメージは持ってたりしたんですかね。
そうですね、過去に一度エンジニアリングマネージャーとしてスタートアップで働いていたり、
本当に直前の全職とかもエンジニアリングマネージャーとしての肩書きではなくても、エンジニアチームのマネジメントっていうことはしていたので、
結構イメージとしてはすごいありました。
元輝さんの入社経緯
そうっすよね。確か最初の頃からそういう話してましたもんね。
はい。
なるほど。ありがとうございます。
じゃあ、そんな感じでエンジニアリングマネージャーとして、家福スタイルという会社で改めてスタートしてもらうことになって、
その後、そこからまたいろんなことがあったので、思い出しながら話をしていきたいなと思ってます。
よろしくお願いします。
そうですね、エンジニアリングマネージャーとして新しい会社で仕事スタートするのって、結構難しいことなんだろうなって一般的に思っていて、
どっちかっていうと、まずエンジニアとして新しい会社に入って、普通にものを作って成果を出して、そこからチームのリーダー的なのになって、マネージャーになるみたいな、
そういうパスの方が多分多くの人にとってはやりやすいんじゃないのかなというふうには、今でも僕は思ってるんですが、
とはいえ、そういうスピード感じゃない会社だったりだとか、一定経験のある人だったらやっぱりマネージャーとしていきなり入ってもらうっていうところも、
それはそれでできるならできた方がいいことだったりするので、できる人はできるんだろうなと思っています。
で、今回歌舞伎スタイルでの元気さんの場合は、エンジニアとして業務委託っていう結構限られた入り方が、3ヶ月くらいですかね。
あった後で、エンジニアマネージャーとしてスタートするみたいなところがありましたと。これ実際なんかそういう形でのスタートって、元気さん的に何ですかね、
これは結構ハードモードだなぁみたいなのとかあったんですかね。 ハードモードかイージーモードで言えたら、バリバリのハードモードでしたね。
ですよね。 そこに関しては、なんでハードモードかっていうと、僕が入っていたプロジェクトって結構閉鎖的なプロジェクトだったと思うんですよ。
なので、会社全体のエンジニア組織を見れていたかどうかって言われると全然そこはノーっていうところで、もうほぼ入ったのは入社に近い。
もう新しく入ってそのままエンジニアリングマネージャーをやっているっていうのとイメージと似ているかなっていう形ですね。
ですよね。あのプロジェクト、聞いてる方の中にはわかる方もいるかもしれないんですが、某プロジェクトがあって、それは本当に既存に提供しているサービスに対して、
かなり独立した機能を作っていくようなプロジェクトだったので、既存のプロダクト開発チームとほぼほぼコミュニケーションせずに、そのプロジェクトの中だけで仕事するって感じでしたもんね。
そうですね。
なので確かに、知らなくちゃいけないことが膨大にあったりだとか、そういう状態でスタートする感じでしたよね。
コミュニケーションとして、他のチームメンバーとも話していなかったので、社内のエンジニアからの認知もなかったっていうような状態ですね。
そうですね。
そういう中で、この辺はマネージャーとしてのアプローチみたいなところだと思うんですけど、
元気さんって最初、いろんな人と直接関わるメンバーだけじゃなくて、他の部署の人とか、いろんな人と話すっていうのをやってましたよね。あれってどんな感じでしたっけ?
そうですね。エンジニア組織内で言うとチャットバトンっていうのをスタートして、
1人のワンオンワンが終わったら次の人を紹介してもらって、次の人とワンオンワンをするっていうような形で、
エンジニアメンバー全員と話せるっていうような土台作りをしました。
ビジネス側で言うと、ここはフットワークの軽さを思いっきり出すという形で、
どこかで会社のイベントだったり、飲み会等が行われていたらすぐにそこに行って、部署を超えたコミュニケーションっていうところを主にやってました。
僕自身も割と自分の担当してるチームとかメンバーとかだけではなくて、
その責任範囲の外側のステークホルダーとは言わないんですけれども、関係しそうな部署の人たちと、結構早い段階でちゃんとコミュニケーションして、
自分のチームがどう見えてるのかだったり、自分のチームの外側にどんな課題があるのかっていうのを、やっぱりコミュニケーションして知っておくっていうのを最初にやるはずだし、
僕が1年前にこの歌舞伎スタイルの仕事を始めた時も、そういうことをやったので、
なんかその辺で結構アプローチが似てるなっていうふうに、元気さんの動き見て思った記憶があります。
それって結構大事にしてることなんですかね、元気さん的に。
そうですね。ただちょっと後藤さんと少し違うのが、どういうところに問題があっていう以上に、もう少し自分を知ってもらう、相手を知るっていうところと、
あと自分を知ってもらって、オンラインのコミュニケーションになってくるので、その時にいかにお願いをした時にやってもらえるようになっていくかとかも含めて、
そこってコミュニケーションすごい大事だなと思っているので、全員とちゃんと顔を合わせなくても話すタイミングっていうのは作ろうかなと思ってます。
いやここ結構深掘りたいテーマだったりするんですよ、僕的には。なんか多分今の話の中で自然に出てきたんですけど、僕ってどっちかっていうと、なんか問題とか目的とか、なんかそういう方に頭が寄りがちなんですよね、どうも自然と。
でも元気さんって、バランス取れてる部分もあるし、やっぱり僕からすると結構人を大事にしてるっていうか、なんかそういう考え方を持ってマネジメントしてるように見えることがあるんですよ、すごく。
それってすごい大事、特にマネージャーとして大事なことなんだろうなっていうのも思ったりするんで、なんかさすがだなって思ったりもしてます。
ありがとうございます。ただね、ビジネスがまだまだ見れていけてないっていうところで、まずは人に自分ができるところにフォーカスはちょっと心がけてはいます。
まあまあでもその人のこと結構、信頼関係作らないと仕事進まないところもあったりすると思うので、そういう観点で動けるのっていいなっていうのはすごく思いますね。
それで言うと、その問題が発生した時にどうするのが一番円滑に進むかって言った時にお願いができる人がたくさんいた方がやっぱり解決するなーと思っているんで、私はそのバンドを作りたいっていうところですね。
なるほどね、なるほどね。そうですよね。まあどっちが先とも言えないですけどね。
なるほど。ありがとうございます。そういうのやってて、そうですね、なんかその人との関係地みたいなの結構大事にされてた印象で、なんか逆に言うとなんすかね、それが出来上がるまでってちょっとなんか元気さん的に動きづらいなんかフェーズみたいなのがあったような気もしてるんですよ。
そうですね、それで言うと本当なんか人を知らないとコミュニケーションがそもそもできないっていうレベルにもなってしまうので、多分昔のスラックとか見返してもらうと僕多分喋ったことない人とのスラックコミュニケーションほぼないですね。
なので挨拶とかも含めて、うちだとなんかZoomがメインルームとか、そういう全員が集まるようなZoomの部屋があるんですけど、そういったところでも知らない人に挨拶かけたりとか、そういったことはちょっと自分で能動的にやってますね。自発的にやりながら、できる限り話せる人を増やしてます。
いや結構そこまで行くとだいぶ僕と違うなんか、当然なんですけど違う人間なんだなっていうのを感じますね。僕なんかどっちかっていうとなんだろう、テキストコミュニケーションだけでやれてる気がする人間なので、なんか一度も顔を合わせてなくても、テキスト上のスラック上のアイコンで人を認識してるっていうか。
それだけで、向こうがどう思ってるかはもちろん別の話としてあるんですけど、僕自身は普通にもう、この人こういう人だっていうのを、スラック上のテキスト情報だけで認識してコミュニケーションするっていうことが、僕は違和感がないんですよね。
それで言うと僕はテキストから読み取れる表情っていうのがないので、自分が発信した情報を相手がどう認識してくれるかっていうのが結構見えないと怖すぎて、まず僕のこと知っといてねっていうのも含め、本当に相手を知るっていう以上に自分のこともちゃんと知ってもらうっていう場が欲しいと思ってますね。
いやでもわかるような、当然わかるような気がするっていうか、結構わかるんだろうな。僕もなんかそのテキストだけで仕事ができてると言いつつ、やっぱりこの会社での仕事を始めて、最初の数ヶ月間とかは何ですかね、
いってこ自信が持てないっていうか、自分が問題だと思ってることをちゃんと理解してもらえてるのかだったり、認識が揃ってるのかどうかだったり。
そうですね、同じ方向を見て会話ができてるのかみたいな感覚が、確かにそこまで持っててなかったのはありますね、正直なところ。そのテキスト上で当然やってはいるんだけれども。なんか上手く揃ってないなぁだったり、自分が空回りしてるのかなぁみたいな感覚を持ちながらやってたところは、あるっちゃあるので、なんかそういうことなのかもしれないって今思い始めました。
そうですね、なんか空回りしてるのかなって思い始めると本当にテキストだとどんどん辛くなってくるんで、もう一回顔を知りたい。
そうですね、なんで、そういう意味では僕もそっちをもう少し意識してやった方がうまくいくのかもしれないですね、僕的に。できてると思ってたけど。
IT・インターネット業界に強い転職アプリGreenは、今話題のテック企業、プロダクト開発、DX案件などGreenだけの良質な求人を数多く揃えています。正式応募前に企業の中の人とカジュアル面談ができるので、仕事内容やメンバーのことをしっかり理解した後に先行に進めます。カジュアルに始める転職活動にGreenをご活用ください。
そんな感じで、元気さんが会社でマネージャーとしての仕事をスタートして、ちょうどそれくらいの時期に、うちの会社も採用頑張っていて、3月、4月、5月とかでグローバルから新しい方とかが入っていただけることになって、
その方たちによりスムーズに仕事をスタートしていただくためのオンボーディングみたいなのを改めてちゃんと準備しようぜっていう話を、エンジニアリングマネージャー間で課題として持ち上げてやることになった時に、元気さんにその辺を担当していただこうっていう流れになったりしたんですけれども。
オンボーディングの課題と改善
元気さん的に、会社に入ってまだそんなに長くない中でオンボーディングを担当するみたいな流れだったりもしたんですけれども。元気さん的に、そもそもオンボーディングっていうものに対する思いだったり、モチベーションだったりっていうのが元々あったんじゃないのかなとも思うんですけど、その辺ってどうだったんですかね。
たぶんめちゃめちゃ強かったと思いますね。もう一人の別のエンジニアリングマネージャー、同僚のエンジニアリングマネージャーともすごいディスカッションを重ね、折れず折れず平行線をつながるぐらい本当に強い思いがあったと思います。
思いとしては、やっぱりエンジニアが入ってっていうか、入社されて一番重要な3日間とか4日間、3日間ですね。僕が見てるのは3日間までなんですけど、3日間っていうのはやっぱり自分がちゃんとこの会社に入って受け入れられているかであったりとか、
あとは自分がこの会社に入ったらどういう仕事ができるんだっていうところをイメージしてもらうっていうすごい重要な時間なのに、そこが全く欠けていたチームに僕は一番最初この歌舞伎で入らせてもらったんで、そこから含めてもう絶対にここはすごい進歩を上に上げて、次から入ってくる人たちが問題にならないようにっていうところにフォーカスしてました。
そうですね。
まあちょっと元気さんが入った時にバッド体験だったのは非常に申し訳ないですけども。バネにちゃんと整備していただいたっていうところがすごくいいところで、実際どういうことを準備していったのかっていうのって、ちょっと今お話いただけますか。
そうですね。まず準備前の話の段階で言うと、もともと5日間に分けて1時間ずつやりながらオンボーディングをちゃんとしていくよという形だったんですが、そこで学んだことはちゃんと自分で次の日やってねっていうような雰囲気のオンボーディングチームがあったんですね。
ただそうしてしまうと、今必要ないことをエンジニアにその場で説明しても結局自分が実際にやる時って覚えてないよねだったり、その時にまた必要になって戻ってくることってあるよねっていうバッド体験が生まれているなっていうのが、僕以外のオンボーディングでもそれが発生しているっていうことが分かりましたと。
なので実際に僕今回作らせてもらったオンボーディングでは、新しいオンボーディングスタイルでは、もう彼らが学んだことをその場で試すっていう体験まで絶対に一緒にやるっていうのを主にして、必要ではないけど将来的に必要になるかもしれない、もしくはたまに必要になるかもしれないっていうことに対しては、もうドキュメントがここにあるかもしれないから、
もし必要だったらその初めての時に一緒にやりましょうというスタイルにして、基本的な開発体験で必要な体験、必須体験っていうところに関しても絶対にオンボーディングで一緒にやるぞっていうスタンスで動いて、それがちょっと好評だったかなっていうところでした。
あれですよね、元気さんに整えてもらう前は、ドキュメントとかが一定ありはして、読んどいてねみたいな感じでしたかね、基本的に。
僕が入ったチームはもう完全にここら辺にあるからぐらいの。別チームはまたちゃんとドキュメントに対して、ちゃんと読み合わせをするっていう時間はあったんですが。
インプットはやってましたよね。
実際のオンボーディングプログラム
ただそのインプットと体験っていうのをアウトプットと一緒にやれないものとか、ただインプットだけで終わってしまうところだったりが多くて、結局身についてないよねっていうところで、覚え切れてないよねっていうところで、必要なところは必要なタイミングでっていうスタイルに切り替えたっていう形ですね。
そうですね。やっぱりその場でやらないと、わかんないというか、少なくとも覚わらないですよね。何か必要性を感じなかったりするんで。
で、教えた側からも、これ前言ったよねになってしまったら、聞いた方もかわいそうだし、教えた方もかわいそうだし、誰がハッピーになるのかわかんなくなってしまうんで、ハッピーにならないように言って、全員がハッピーにっていうような形で操作してますね。
ちなみに、プログラムの流れとしてはどんなふうに今最終的になったんでしたっけ。
プログラムの流れでは、一旦Day1,2,3と分けているんですが、Day1では会社のことを知ってもらうということで、会社のMVVだったり会社のコミュニケーションの仕方っていうところを最初にやって、
その後に実際の開発フローの全体の流れっていうのを軽く説明して、あとは開発環境をセットアップしてもらうっていうところまでが必須体験になっている。
で、その後に開発ローカル環境が立ち上がったら、めちゃめちゃ小さいオンボーディングタスクっていうのを振って終わり、1日目は終わりっていう形ですね。
あとはチェックアップで1日の終わりに10分15分、新入社員と一緒にエンジニアリングマネージャーが話すっていうのがDay1。
で、Day2では初日に作ってもらったオンボーディングタスクを一緒にデプロイするっていうフローを1時間取って一緒にデプロイをして、実際にどういう開発体験があるかっていうのを完全に体験してもらう。
で、ここの今Day1,2,3って言ったんですけど、ここをDay2で終わらせたりとかがあって、あとはもう一つ、実際にサービスを触ってもらう。
ユーザーとして触ってもらうのと管理画面として触ってもらう。この2つをちゃんと全部投資でやって、実際にサービスを知ってもらうっていうことを合わせてやってますね。
これをDay1,2,3のどこかで全てやるっていうようなイメージです。ちょっとタイミングによって流動的にそこの順番を入れ替えてるっていうような流れですね。
最低限のものをきちんと抑えられてるなっていう感じがしますよね。
結構海外のメンバーもいて、普通のサービス、自社サービスを抱えているところで、ユーザーが一般コンシューマーとか一般消費者がユーザーになるようなものに対してだと、
結構触ってきてくれている人が多いとか、元々ユーザーだった人が多くて、エンジニアになっているから一定の知識前提であるよねっていうのが、たまにそういう流れがあるかもしれないんですけど、うちのサービスだと海外メンバーそもそも登録してないし、旅行をそこまでやってないエンジニアとかが入ってしまうと、全くサービスについても理解が追いつかないっていうところがあるんで、
結構サービスの説明っていうところには重きを置いてやっていますね。
そうですね。実際今のサービス、インドで使ってねって言われても使えませんもんね、そんなに。
使えないですね。もう本当にこの前はインド、パキスタン、スリランカ、ポーランドと僕日本で5カ国のオンボーディングがあったんですけども、全員使えないでしょみたいな。
まあ仕方ないですよね今は。
はい、ですね。
フィードバックと成果
なるほどなるほど。なんかその辺やっていく上で何ですか?メンバーからはなんかどんな感想が出てきたりしてるんですかね、今の時点では。
はい、今の時点で言うと、そうしていろいろいいフィードバックを、一応フィードバック制度を使っていて、入所以内にはここにフィードバック書いてねっていうのをちゃんと最初に説明をしてフィードバックノートを用意するところからまず入って、
いいフィードバックをもらうこともあったりとか、改善できるようなフィードバック、修正悪いところのフィードバックですね。そういったところに関してもらったら次のオンボーディングではもうそれが修正されているっていうような形でやっているので、なんかいいPDシェア回せているのかなとは思っています。
結構その後のチェックアップとかで話を聞いても、自分の想定よりいいフィードバックをもらえて、すごいやりがいがあったなって思いますね。
ありがとうございます。僕も自分がこの会社に入ってきて、最初もうあんまり何も用意されてない中で、自分自身でサービスも登録して触ったりしますし、ソースコードも自分で読んで自分で理解するみたいな感じでやってきているので、自分はそれでなんとかなったんですけど、
そういう人が全てじゃない前提で回していかないとスケールしないだろうし、よりスムーズに入社してパフォーマンス出していくみたいなところにならないので、オンボーディング結構大事だなっていうのは相変わらず思ってますね。
そういう意味では、この短期間にマネージャーとして結構いい仕事をしてもらえたんだなっていうのはすごく感じています。
良かったです。本当に。自分がやりたかったことができて本当に良かったです。
そうですね。一つ成果が出たっていう感じがするんで、それはすごくいいことなんじゃないのかなって思ってます。
ちょっとオンボーディングいろんなことをやってもらったので、いろいろ聞いたんですけれども、ちょっと違う観点の話もしてみましょうかねと思っていて、
例えば、改めてこの会社でエンジニアリングマネージャーとして元気さんに仕事をスタートしてもらってるんですけれども、
この先、元気さんはどんなエンジニアリングマネージャーになっていきたいのか、そもそもエンジニアリングマネージャーじゃない何かになっていきたいみたいなキャリアっていうか成長っていうか、
そういう観点だと何かどんなことを考えてるんですか。
そこで言うと、完璧なエンジニアリングマネージャーになるには、僕の目指す最強のエンジニアリングマネージャーっていうのは、
やはりエンジニアに対する深い認識、開発ですね、バックエンド、フロントエンド、インフラ、ここに対する深い知識っていうのと、
ビジネス理解っていうところと人をちゃんと見れるっていうところ、この3点かなと思っていて、
ここは今、まず一番自分が強い人っていうところにフォーカスしつつ、
今、これまで日本メンバーしか見たことなかったけど、これから海外も見つつ、そのグローバルな視点でエンジニアリングマネージャーとして、
people management、エンジニアリング組織のマネージメントっていうところができるっていうのが、まず第一の目標かなと思っています。
そこに肉付けで、そこの軸を横から追加していくような形で、開発についてもう少しインフラとかバックエンドっていうのが弱いので、
そこら辺をつけていったりとか、ビジネスっていうのをつけていくっていうのがやっていくことかなと思っています。
なるほどな。
まあでも、基本的にはエンジニアリングマネージャーとしてやっていくっていうようなイメージを持っています。
ですね。いずれもしキャリア名が変わるって、ポジション名が変わるとなったら、CTOではなくVPOEとかに行きたいなと思っています。
なるほど。その心はっていうか、その違いはなんだろう、元気者の中では。
僕の中でのCTOは、もう技術に対する最高責任者なので、何かセキュリティも含めて、セキュリティインフラ、将来的なコストっていうと、
もう開発に関する全ての方針決めはしないといけないっていうところですが、そこに対してVPOEとしては、
それを達成するためにどういう人材が欲しいっていうところがあったら、そういう組織を作るだったり、そこに対してうまく動けるような開発組織作りだったり採用だったり、
そこら辺のマネジメント、またビジネスに対して、そのCTOの決定を、CTOからの発表も含めて、自分がそれをサポートできるような形ですかね。
やっぱりだから、人、組織みたいなところがコアにあるっていうか、そこを中心に自分のキャリアを歩いていくみたいな、そういうイメージってことなんですかね。
そうですね。そこはビジネスもちゃんと見なさいってすごい今言われているので、そこも見つつ、一番は人だったり、人のマネジメントとかそっちを見るっていうところが強いかなと思います。
うんうんうん、なるほどなるほど。そうですね。まあ、その意味で言うと、僕、今たまたまなのか、CTOっていう役割を持ってはいますけれども、過去に自分がどうだったのかなっていうのを振り返ると、
もっと人とかチームにフォーカスして、なんならそこが今の元気さんみたいに、そこが自分のコアだみたいに思って、いろいろ勉強したりやってた時期もあったんですよ。で、もうなんでそうだったのかって思い出せないんですけれども、
やっぱり何ですかね、その取り組んでいる問題の、なんかその時のタイミングっていうかフェーズだったり、所属している会社だったり、与えられている役割だったり、なんかそういうので変わるものなのかなっていうのが、今の僕の持っている感覚だったりして、たまたま今僕はCTOっていう椅子に座らされているというか、まあそれをやっているので、
どっちかっていうと元気さんの言葉で言うと技術みたいなところに最終責任を持つだったり、経営とかにもタッチしなきゃいけないので、そういった観点でよりビジネスと接続する部分とかいうところにも責任を持っているから、なんかそういう考え方がより強く前に出てきているのかもしれないんですけれども、
そうじゃない椅子に座るってなったら、もっとこう人と組織をしっかり見ていかなきゃなっていうふうにウェイトが変わるかもしれないですね。なんで、なんかなんだろう、わかんないです。元気さんがもし違う状況にあったら、その辺が変わるのかもしれないなって思ったりもしましたけれども。
エンジニアリングマネージャーとしての役割
まあでも強みで言うとやっぱり元気さんは人のところが今少なくともあるかなっていうのは思いますね。
そうですね、そこはもう頑張って伸ばしていきたいっていうところでもある強みだとは思います。
じゃあ伸ばしていくっていうときに、今できていることと、さらにVPOEみたいな仕事をするときに、ここはビジネスとかじゃなくて人組織面で、こういうことはまだ学んだり、トライしていかなきゃいけないよねみたいなギャップとかっていうのは何か今見えてたりするんですか?
そうですね、そこは結構感覚でやってきた、感覚で人の管理をしたりとか、あとは自分の過去に読んできたブログだったり記事とかで学んできたものを試すっていうことをしていても、ちゃんと体系立てて学んだことがなかったので、今はすごいそのインプットを大量にしていますね。
あとはなんか以前、別の収録、僕めちゃめちゃこのヘビーリスナーなんですけど、周りのEMと話すとか、周りのマネージャーと話すのがいいよっていうところもあって、それも含めてちょっと別のEMだったりCTOと話したりはしますね。
いいっすね、いいっすね。何の時だったかな?なんかその、仕事でワンワンを僕と元気さんでやってて、何かの仕事をした時に、なんかやり方のアドバイスをした記憶があって、オンボーディングの話でしたっけ?
あのー、なんかやり方がなかなか決まらないみたいな時に、ゴールから話をしようみたいな映像とかありませんでしたっけ?
はい、それこそ一番揉みに揉んだオンボーディングですね。オンボーディングはやっぱり平行線で、他のEMと話し合ってもずっと平行線があった時に、その話をしていただいたっていうところではありますね。
あれはなんか効果とかどうだったんですかね?
あれはめちゃめちゃ効果があったなーっていうところで、今でもすごい自分で気をつけて、他のEM、別のEMに話す時だったりとか、共通認識を持ってそこに対して話す時に、一番やっぱゴールから入って、その後だからっていうと、ずれたらゴールを修正するのか、ゴールをちゃんと見直すのかっていうこと、立ち返りができるんで、ゴール戦法は今すごい使ってます。
ゴール戦法になってるんですね。面白い。たぶんそれ一つぐらいしか僕アドバイスしてないような気がするんですけど、一応元気さんのマネージャー的立ち位置で僕が今いる状態なので、僕的には一つぐらいいいアドバイスができたなっていうので、それは思ってたりしますね。
で、元気さんの話に戻ると、あれですかね、そういう自分自身の物事を進めたり整理したりするスキルみたいなところもいって、これから学んでいくみたいなところもあったりするんですかね。
ですね。まだまだ、まだまだ。
はい。ありがとうございます。ちょっと話が前後するかもしれないんですが、業務委託で仕事をスタートした後に改めてエンジニアリングマネージャーとして、この会社で仕事をスタートするみたいな感じになった時に、
その元気さんの中で何か考え方とか、何ですかね、マインドチェンジみたいなのってどうなんでしょう。あったりしたんですか。
そうですね。エンジニアリングマネージャーになる時っていうことですよね。
そうですね。いろいろなんか変化があった。そもそもの働く時間とかね。
そうですね。そこで言うと、副業からフルタイムになって、僕副業の時、本当は週20時間とか10時間くらい働くとか言ってたのに、全然働けてないっていうのもあって、時間取れてなくてフロントエンドエンジニアやってたんですけど、
2月1日からもうフルタイムになって、めちゃめちゃ時間が取れるようになって、キャリアチェンジも行われたっていうところで、すごい意識としてはすごい変わりました。
どこまで、どんだけ会社に対して貢献できるかっていう意識がめちゃめちゃ上がったので、見るところはすごい広がっていたっていうイメージですね。
それって何ですかね。単純に時間が増えたからなのか、マネージャーっていう役割っていうか、そういうところによって、何かそういう変化が起きたのか。
元木さん的にはどうなんですかね。
そこで言うと、単純に時間が増えたからっていうのが、まず最初のフェーズだったかなと思いますね。
エンジニアとして見れなかった部分も、時間が増えて、よりちょっと周りが見えてきたっていうのが第一フェーズだったかなと思ってます。
2月中盤から3月にかけて、2月中結構厳しかったんですけど、3月になって一気により時間が追加できるようになって、そこでエンジニアリングマネージャーとして時間を使うことができたかなっていうところでしたかね。
なるほどね。それって何ですかね。具体的にどういうことができるようになったって感じてるんですか。
それで言うと、2月の正直な話で言うと、すごい辛いプロジェクトがあってですね。
1ヶ月間もう何もできないっていうところで、ストレスも半端なかったんですけど、あまり周りが見れてなかったんですけど、3月から見えるようになって、
エンジニアリングマネージャーとして見ることができたって言ったのは、結構自分が働いている領域以外も含めて、会社全体を見れたかなっていうところが、3月からのエンジニアリングマネージャーとして良かったところかなと思ってますね。
その時期にあれでしたっけ。さっき話したいろんな人とワンワンしたりとかもやったんでしたっけ。
そうですね。そこら辺からようやくそういったことができたりとか、あとは会社全体のどういうプロジェクトが走っていてとかも含めて、ようやく見ることができたかなと思ってます。
そういう視点が広がったっていうことに伴って、当然やらなきゃいけないことが増えるとかだったりするってことだと思うんですけれども、それって何ですかね。その働き方っていうか考え方っていうか、そういうところにも大きく影響したりするんですか。やりがいとか。
エンジニアリングマネージャーとしてのやりがい
そうですね。最後のやりがいっていうところにすごい僕の中ではヒットしたかなっていうところで、これまで僕エンジニアで働いている時って自分の持っているタスクに追われたりとか、そういったことがすごい多かったんですけど、
エンジニアリングマネージャーで若干の全体を見通す位置的な場所で俯瞰してみるような環境に自分を置いたときに、置かなければならないので一旦そこに置いて俯瞰してみるときで、そういったところを見たときに、ここら辺何か足りてなさそうじゃん、何かやっとこうとか。
それでオンボディングが見つかったりとか、ここら辺何か足りないじゃんっていうようなものがすごい見通せることができて、そこに対してうちの会社だとやりがいっていうところで言うと、オーナーシップ、プロフェッショナリズムとオーナーシップっていうところで、自分で何か責任を持ってそれを最後までちゃんとやり通すんだったらどんどんやらせてくれるっていうポジションでもある。
ポジションというかその環境でもあるので、そこで全力でできるっていうのが僕の中のやりがいですかね、本当に。オーナーシップはすごい良いなと思ってます。
そうですね。実際、これ会社のサイズだとかによらないとは思うんですけれども、いろんな問題が会社の中に基本的には散在してるんですよね。ただそれに対して、何ですかね、責任を持ちつつ自分の裁量とかで自分の仕事にして解決していくみたいなことができるできないっていうのはちょっと会社によって違うかもしれないですよね。
あとまあその役割、ポジションによってもそれができるできないっていうのはあると思うので、その辺はもしかするとエンジニアリングマネージャーっていう形で入ってもらったからそういうことができたとかいうことでもあったりするんですかね。
いやどうですかね。僕は多分今のチームはエンジニアとしてやっていたとしても多分エンジニアとしてメンバーがそういったことをやるって言っても多分できると思うんですよ。他のところにも領域にも手を出してって。ただそこに対してちゃんと自分の追われているタスク等も含めて考えないといけないっていうところでなんか大変さは出るんじゃないかなと思っていて。
なんかそこがエンジニアリングマネージャーとエンジニアの違いが出るかって言ったらちょっと違うかなと思うんですけど、僕の場合だとエンジニアになってると本当になんかもう目線が真っ直ぐになっちゃって、それ以外何も見えないっていうようなタイプの人間なので、僕としてはエンジニアじゃなくてエンジニアリングマネージャーっていう立場でいた方がそれらがうまくできたんじゃないかなと思ってます。
まあそれはありますよね。やっぱり人によってエンジニアのままステークホルダーをうまくコントロールしているような人も過去に見たことがあるし、エンジニアリングマネージャーとエンジニアを行ったり来たりしながらうまく自分の動き方をコントロールしているような方とかもいらっしゃるので、人によってだったり環境によってなんかもういろんなやり方があるんだと思うんですけれども。
もしかすると元気さんにとっては今回エンジニアリングマネージャーとして入っていただいたのが結構いい形になったんじゃないのかなって僕的には思えたりしています。
本当になんかいい環境だなーっていうのを自分の中ですごい思ってますね。良かったっていうのを。
ありがとうございます。まだまだ課題は三石しているので、今後とも頑張っていきましょう。
はい、やっていきましょう。
はい、じゃあ今日は元気さんとたっぷりお話しさせていただいて、私自身も楽しかったんですけれども、元気さんなんか今日話してみて感想とかあったらいかがですか。
はい、ありがとうございました。今日僕もなんか話してみて楽しかったなーっていうところと、ワンワンもたまにやってるんですけど、それ以上に話できて良かったなと思ってます。
今日は僕の中で一番なんか、やっぱり自分をちゃんと振り返る時間っていうところを今回40分撮れたっていうところと、自分がそんなにビジネスとかより人にすごいフォーカスしてしまうっていうところが話しててもやっぱりそう出てくるんだなっていうところがあったので、
そこを伸ばしていくっていうところも含めて、別のところでビジネス側の肉付けとか、あとはエンジニアとしての肉付けっていうところをもっと頑張っていけたらなっていう再認識ができてとても良い時間となりました。ありがとうございます。
はい、ありがとうございます。なんか公開ワンオンワンみたいな感じかもしれないですけれども、まあでもお話できてすごい僕的にも学びもあったし楽しかったです。ありがとうございました。
公開ワンオンワン
はい、というわけで今回公開ワンオンワンっていうような雰囲気な感じでお送りしました。実際同じ会社で働いている元気さんといろいろお話しして、普段もワンオンワンで実際に仕事の中でやっていていろんな話はしてるんですけれども、改めてこういう場で話をしてみるっていうのは、僕自身にとっても新鮮というか、普段とは違う元気さんが見れたのかなっていう面もあって。
そういう意味でとても有意義でした。聞いている皆さんにもなんかちょっと面白い情報というか学びというのを提供できたんじゃないのかなと思ってますし、今後もちょっと社内の方かどうかわかんないんですけれども、なんかワンオンワンチックにお話しするっていうのは他の方ともやってみたいなと思っております。
さて、この番組では感想や質問、リクエストなどお待ちしております。番組詳細欄にあるリンクよりお気軽にご投稿ください。TwitterではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
