エンジニアから様々な領域への挑戦の魅力
日本最大級のエンジニアコミュニティ Qiita プロダクトマネージャーの
清野俊文です。この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続き、ゲストは日本CTO協会理事の藤倉さんです。よろしくお願いします。
よろしくお願いします。藤倉さんとお送りする3回目のテーマは、「エンジニアから様々な領域へと挑戦することの面白さ」です。
今回、僕自身も元々エンジニアではキャリアを始めつつ、いろいろこんな感じでポッドキャストをやっていたり、いろいろやっていたりするので、
いろんなことに挑戦することの面白さとか、悩みみたいなところをいろいろご相談できたらなと思っています。お願いします。
最初にお伺いしたいのが、結果的に藤倉さん、エンジニアから開発部長だったり、プロダクトマネージャーだったりとか、今VPOEとか、いろんなことされていると思うんですけど、
それは元々やりたかったことなのか、結果的にそうなっているのかというとどういう感じですか?
全て結果的にですね。
結果的になんですね。
そもそも私はあんまり自分のキャリアをこうしたいみたいなもので、強く思わないタイプ。
でも最初はやっぱりアメリカに行きたいとか、一流のエンジニアって言われるようなところまで行ってみたいとか、最初はあったんですけど、
そのうちそういうことを考えなくなりましたね。
なんかそれよりは本当にその自分が携わる事業や会社が成長するためにできることは全てやるみたいな、
そうですね、なんかそういうマインドになってからは本当になんかキャリアはある、なんかあるとき立ち止まって振り返ったら、
ああこうなったんだなーって思うみたいな、それでしかない感覚になってますね。
そうなんですね、じゃあ本当に結果的にいろいろその瞬間にこうやった方がいいことっていうのをやっていったらこうなってたみたいな。
そうですね、はい。
なんかもともとこうエンジニアからキャリアを始めてると思うんですけど、
そのエンジニアっていう領域の中でやれることをいろいろやっていくみたいなキャリアの作り方もあると思うんですよね。
だからそこではなくて本当になんか手段を選ばずいろいろやっていくみたいな趣向性なのはなんかこうなんですかね、
自分の中でもこだわりとかスタンスとかあったりするんですかね。
いや本当になくてですね、
それもないんですね。
はい、多分その前職に転職をしたときに自分のマインドが、私前職は社員番号が18番だったんですね。
なので本当に初期の初期にジョインをしていて、やっぱり事業としてもまだまだ立ち上がったとは言えない、これから頑張んなきゃっていう会社だったので、
自分もその一員として絶対この会社成功させる、この事業をちゃんと成功させるって思ってたんですよ。
なのでそのときそのときで会社の中、もしくは開発チームの中で、これ誰かやったほうがいいよね。
これちょっと藤倉いけないって言われたらだいたいあんまり深く考えずにいけますっていうみたいな、
そういうことをしてたらキャリアがこうなったっていう、そういう感覚ですかね。
なるほど。
ちなみになんですけど、その前職333に入ったときって、社員番号18番ってお話あったと思うんですけど、
入るタイミングでこれ結構いろいろやるだろうなと思いながら入ったのか、もともとエンジニアとして入ったのかというとどういう感じなんですか。
挑戦のスタンスとキャリア形成
本当立場としては6番目ぐらいのエンジニアとして、1エンジニアとして入っていて、
アメリカの頃の経験だったりとか、一番最初の会社の経験で割と全体アーキテクチャを設計するとか、
ミドルウェアとかインフラ周りみたいなことに技術的には少し経験がつかったので、
そのあたりでまずは貢献できればいいのかなぐらいの感じで。
ただ、いわゆるベンチャー企業に入社をするときの私のマインドとしては、
本気で仕事してみたいって、もうやり尽くしたって言えるぐらいまで本気で仕事したいなみたいなのもちょっとあって、
やっぱり一番最初の会社が大阪ガスグループの本当に大きな会社だったので、
もちろんそれはそれで頑張って仕事はしてましたが、
やっぱりそういう大企業でこれまで培ってこられた何かの上で仕事をさせていただくっていうのと、
自分がゼロからやらなきゃいけないってやっぱりちょっとマインド違うので、
そういうふうに挑戦をするみたいなマインドもあったので、
それもだからこれいけるって言われたらとりあえずいけますっていうみたいなのに影響してるのかもしれないですね。
なるほど。じゃあもうそのときはある程度覚悟を決めていたというか、
本気で何でもやっていくぞっていう気持ち自体はあったってことですね。
そうですね。
ありがとうございます。
ここ僕ちょっと1個悩みとして相談したいなと思ってるところなんですけど、
僕自身も結構似たようなスタンスでやってて、
元々エンジニアでは入ってるけど、僕も会社だったりとか一緒に働いてるメンバーが一番いい状態に持っていくこと自体が
僕もとしてもすごい嬉しいことだと思ってるので、
もう何でも二つ返事でやりますって言っちゃうタイプなんですけど、
それをやっていくと何て言うんですかね、その瞬間瞬間新しい領域をインプットするじゃないですか。
そのインプットっていうところに対してある程度年度が高まるまで時間がかかるっていうのと、
逆に元々持っていたスキルのところをそのタイミングで伸ばすところに時間をあまり費やせないみたいなのがあるなって、
今振り返って思っていて、
そこら辺の切り戻ししづらさというか、そこみたいなところってどうやって考えてましたか。
そうですね。
その一つの領域で深掘っていくと、
まさに年度というか能力値ってもしかしたらリニアに言い方に上げていけるものが、
一旦ちょっと下げて、
またベクトルの方向も違うところに行って、またそこからグッて上げていく。
その時に毎日使っていたものってどうなるんだっけみたいな話ですもんね。
例えば私がエンジニアとして、
もう本当にプロダクションの行動を書かなくなったから10年以上経ってしまうので、
多分今私はエンジニアとして最前線に出ることはできないと思いますが、
でもその時に考えていた、
例えばアーキテクチャの設計に関する自分なりの方法論とか、
こういうケースではこっちにした方がいい確率が高いとか、
その時の判断基準としてはこうだみたいな、
ちょっとこう思考のフレームワークというか、
いうものを一定持っているので、
時間をかけてやらなきゃいけないのは、
例えば今本当にトレンドに上がっているような言語、フレームワークは触ってないので、
それは多分時間をかけないと絶対に取り戻せないと思います。
ただ、もともと使っていたものは今も存在はしているので、
そこをきちんと応用できれば、
言語の文法とかを習得するだけなので、
割と短時間にそっちに戻れる気もしますし、
開発部長みたいな割と現場に近いマネージャーも、
そういうポジションのマネージメント、
マネージャー業としてはこういう考え方で、
こういうプラクティスが自分の中にあってとかって、
そういう考え方を私は、
再現できるように整理しておきたい欲求が強いので、
それが本当に再現できるかどうかはやってみないとわからないところがあるんですけど、
少なからずそこで不安に感じることはないというか、
エンジニアリングの知識とマネジメントの結びつき
そういうこれまで使ってきたフレームワークは自分の中にあるので、
あとはそれをきちんと引き出して、
で、ちょっと忘れていたものは勘を取り戻すために訓練をすれば、
そこそこ全く足を引っ張るみたいなことにはならんだろうなみたいな気持ちではありますかね。
なるほど。
じゃあなんかこう取り組むところの表面的な知識っていうよりも考え方とか、
コンセプトみたいなところを一般化して自分のスキルにしているみたいな、
そういうイメージなんですか?
そうですね。
そうだと思います。
特に、やっぱりシステム設計って別に答えないですし、
絶対的な正しい考え方、アプローチってないですけど、
どういう時にどういう判断をしなければならないのか、
みたいなことはある程度自分の中には蓄積はしているので、
それをできるだけ言語化をするとか思考整理するとか、
似たようなシチュエーションがあったらいつでもその判断が使えるようにしておくみたいなことは、
まさにアーキテクチャ設計とかマネジメントとかでは気をつけている、
中傷度が高い判断しなきゃいけない仕事ってなかなかふわっとしてしまいがちというか、
フィーリングでやらなきゃいけないこともあるんですけど、
やったとしたらじゃあなんでそのフィーリングだったんだっけとか、
そのフィーリングをロジックに変えることができるんだっけみたいなことはやってるかもしれないですね。
なるほど。
ちなみにそもそもエンジニアリングのところで培った知識とかが、
そのままマネジメントとか経営とか、いわゆるプロダクトマネジメントとか、
そういうところに生きている感覚はありますか?
いやでもあるんじゃないですかね。
でもやっぱり私もマネージャーをやると言っても、やっぱり開発組織のマネージャーしかやってきてないですし、
今もVPOEっていう立場もそうですし、CTOみたいなものもやっぱり技術に関するオフィサーなので、
やっぱりそういう、それはベースにあるし、
どんな立場であれプロジェクトの中で頑張ってくれてる第一線のエンジニアたちとの、
それこそ会話、議論、信頼関係とかももちろん重要じゃないですか。
そうですね。
それってやっぱりそういうものが分かっているからこそ作れる関係性ってあると思うので、
そういう意味でも役に立ってると思いますけどね。
もともとプレイヤーやってて、マネージャーとかになった時あるあるで、
メンバーが出してくるアウトプットの詳細が気になっちゃうとか、
自分で手を動かしたくなっちゃうとか、
結構最初になった時ってあるあるである気がするんですけど、
そういうのを感じたりしたことはありますか?
あるかないかでいうと、あるという答えにはなるんですけど、
マネージャーとして私の目線は、とにかくそのチーム、
自分が所属するチームのパフォーマンスを最大化するっていうミッションで、
もちろん自分がみんなの100倍動けるんだったら、
全部自分がやっちゃった方が早いと思いますと。
ただ実際そんなことはあり得ないので、
基本的にはみんなを後押しすることでレバレッジをかけていくべきだなと思ってますと。
ただどうしてもこれは今のチームの中では、
自分以外にできる人がいないってなったら自分がやる。
それはどうしてもやらなきゃいけないからっていう感覚なので、
みんなのアウトプットが気になってうっかり手を出しちゃう、
口を出しちゃうみたいなことはあんまりないんですかね。
ありがとうございます。
結構そこも僕自身も考え方に似てるなと思ってて、
僕自身も本当にマネージメントの役割ってチームのパフォーマンスを最大化することだと思っているので、
それぞれが個人で動くよりもチームでまとまっているほうがアウトプットが大きくなるというか、
パフォーマンスが良くなるっていうところをミッションだと思って色々動いてはいつつ、
実際その細かい業務レベルのところまで見ると、
メンバーめっちゃやってくれてるけど、
自分何もやってない瞬間みたいなのがやっぱりマネージャーだと、
エンジニアとしてのマネジメントとリーダーシップ
開発っていう文脈だけでいうとやっぱりある気がしてて、
任せたみたいな。
そこのこうなんか、
これまさに最近ちょっとこう、
僕自身がぼんやりモヤっとするところなんですけど、
これなんか自分がエンジニアとしての感覚でいうと若干サボってる感があるみたいな。
メンバーめっちゃ手動かしてくれてるのに。
自分マネジメントとして違うことやってるんですけど、
そこをこうなんか難しいなーってメンタリティ的に思ったりするんですよね。
なるほどなるほど。
何かおっしゃってることは分かる気がしていて、
私が思うのは、
もし仮に今目の前にあるプロジェクトとか、
みんなの日々の業務がつつがなく進んでいるんであれば、
それは多分マネジメントとして半分は成功してる状態だと思っていて、
じゃあ残りの半分何かっていうと、
この後1年後2年後この組織が今の何十倍にも成長する。
それは生産性なのか人数なのか。
ために今やらなきゃいけないことは何かってことを考える時間に、
私は全振りします。
なので、
マネジメントって何か、
そうですね、
いろんな人のいろんな考え方とか言葉あると思うんですけど、
マネージャーとリーダー。
でもこれって一つの人格によく同時に期待されちゃいますよねみたいな話もあるじゃないですか。
私なりの解釈は、
その文脈で言うところのマネージャーって、
今目の前にある、もしくは直近この3ヶ月くらいどう過ごしていくかってことに対する、
なんでしょうね、
業務。
リーダー、リーダーシップみたいなものは、
もっと先の時間軸の長い話のための仕込みっていうことだと思っているので、
大体多くの日本企業で言うと同時にやっぱり求められることはあるし、
ファーストラインというか前線に近いマネージャーはどちらかというと、
現場よりというかこの短い時間軸が強く求められて、
中小度が上がっていけば上がっていくほど、
ちょっと時間軸の長い要件のほうが強くなっていくみたいなバランス、
グラデーションみたいなものがあると思っていて、
なので、もし本当に目の前のプロダクトが、
本当にいいものがみんなガシガシ作れていて、
KPIがガンガン上がっているんだったら、
そっちに置く時間を使えばいいんだと思うんですよね。
ありがとうございます。まさにって思いました。
今聞いていて、
そういうところをそもそも考えている場合じゃないなって思いました。
多分そこを考えている時点で、
マネージャーとしては二流なんだろうなって思ったので、
ちょっとメンタルを切り替えていきます。
今お話し聞いていてまた感じたところで言うと、
いわゆるマネジメントと経営って近い領域ではあるなと思っていて、
もちろん違う領域ではありつつもグラデーションとしてつながっているというか、
という感じがしているんですけど、
実際CTOもされているという中で、
いわゆる開発部長とか現場のマネジメント寄りのことをやっているときと、
CTOとしてもう一個上のレイヤーでやっているときって、
具体的に考えることってどういう違いがあったりしましたか。
マネージャーとリーダーの違い
一番端的に言うと、
現場に近いマネージャー、部長であったりとか、
グループのマネージャーであったりとか部長とか、
そのぐらいのポジションだと、
これもグラデーションみたいなものがあるんですけど、
やっぱり時間軸がやや短めに設定されるので、
長くても多分1年とかぐらいになるので、
割と課題みたいなものとかテーマみたいなものがシャープに分かりやすいというか、
本当にこの直近3ヶ月でこのプロジェクトが、
例えばこのプロジェクトがうまくいくかどうかって言ったら、
うまくいかない要因ってこの3ヶ月以内のことを予測するみたいな話なので、
割と具体性があるじゃないですか。
やっぱり時間軸が長くなっていくと、
指導とかの立場になっていくと、
そもそも何が課題なのかなんて誰も分かってないので、
課題を定義しにいく。
割と比較的想像しやすい課題を解決にいくっていう方にパワーを使うのか、
課題を特定する、課題を決めるっていうことにパワーを割くのかの違いなのかなって気はしますね。
なるほど。
一つの観点としては。
そのCDOみたいなレベルまでいくと、そもそも問いを作るところに時間を使うとか。
そうですね。
なるほど。
その問いって具体的にどう作っていくんですか。
例えば、前職時代に最後私、フィリピンセブ島での開発拠点の立ち上げっていうことをやらせていただいてたんですけど、
その時っていろんな課題というか、未来に起こる可能性のある問題っていうのがあると思っていて、
例えば一番分かりやすいところで言うと、エンジニア採用、国内ではとても大変ですねっていう。
もっともっとスピード上げるためにはどうしたらいいんだ。
例えば海外に住んでいる、働いているエンジニアを日本に来てもらう。
こういう採用もあれば、海外で拠点を作ってそこで採用を進める。
開発チーム全体としては、当然チャンネルが広がる分成長のスピードが上がると思うんですよね。
っていう話とか、前職時代、事業もやっぱり海外に持っていく。
そこでちゃんとグロースをさせるっていうのも経営の一つのテーマだったので、
国外のユーザーさんとか、これが進んでいくと国外で一緒に働いてくれるセールスやCS、
マーケティングのメンバーたちの声とか、彼ら彼女らを通じて得られるお客様の声。
誰がどう解釈してどうやって実装していくんだっけとか。
っていうことを考えたときに、やっぱり一定英語話者のチームがいないとできないですよねと。
それが3年後に、例えば本当にそれが問題が顕在化したときに動き始めたらもう遅いので、
であれば、そこを一つのテーマとして海外の拠点立ち上げたほうがいいですねとか。
でも仮に事業のグロースがそこまでいかなかったとしても、最悪そこで一緒に働けるエンジニアは、
日本国内の案件とかをやってもいいわけなので、全然やったことが無駄になっちゃうみたいなことはないとか、
どうリカバーするかとか、どういうオプションのとき、どういう可能性があるときにどういう打ち手を打っていくのかとか、
そういうことを考えてる気がしますね。
なので、3年後に今の自分たちが最大のパフォーマンスしてることを想像したら、何が足りないんでしたっけとかいう感じですかね。
なるほど。むしろ時間軸が違うっていうより、そもそも見ているところの時間が違うみたいなイメージなんですかね。
おっしゃる通りで、単純にその時間軸をギューって伸ばしただけではないですし、
3年後の未来をどう想像するかとかいう思考なので、分かんないですけど、3年後どのぐらいのことまでできるのか、
時間軸の違いによる差異
今は想像できないぐらいの何かになっているんじゃないかと思ったときに、
じゃあそのとき自分たちはどうあるべきなんだっけとか、そういうことを考えてますね。
なので、地続きじゃないというか、非連続にするには今から何しこまないといけないんだっけというか、そういう感覚かもしれないですね。
予測をするっていうより逆差に近いってことですよね。
そうですね。
こうなりたいというところから今をリファインメントしていかないといけない。
そうですね。おっしゃる通りでまさに予測ではないですね。
なるほど。だからそういうところの知識とかスキルってどうやって身につけるんですか。
私はもう本当に失敗の連続というか、私は器用なタイプでは全くないので、
そういう新しい役割とかを応勢使ってとりあえず積水反射でやりますって言ってやってみると大体うまくいかないですよ。
前職時代は本当に経営の皆さんとかにはフィードバックをもらっていて、今日もできなかったなとか思ってたんですね。
その時になぜ自分はできなかったのか、なぜあの問いに答えられなかったのか、なぜ事前に準備しておけなかったのかっていうことを考えるんですよ。
それを本当に一つ一つ一個一個の周りからのフィードバック、いわゆるダメ出しを、
次同じこと言われないためには自分は何を考えておくべきなのかってことを整理して、
それが今ちょっとお話したような時間軸みたいな表現、これは自分の理解の整理のためによく使う表現なんですけど、
そうなってた感じですかね。
なので最初は上手にできないので失敗ばっかりなんですけど、そこから一個ずつ潰していくみたいな、そういう感じですかね。
最初にすごいちゃんと準備していろいろインプットしてっていうよりも、やる中でミスをしつつそれを学びに変えていくっていうのを常にやり続けるみたいな、そういうイメージなんですかね。
そうですね、なんかCTOの教科書って世の中にないじゃないですか。
ないですね。
マネージャーもいくつかの書籍はあるけど、個別具体に落ちていくと自分の今の環境に適応できるかどうかわからないというか、
個別具体に依存する場合が多くなりますし、もうちょっと抽象度高いような普遍的なものになると思考とか考え方みたいな話になっちゃうので、
なかなかパチっていう自分に合った教科書とか自分に合ったプラクティス集みたいなのってないと思うんで、
それはもう作るしかないなっていう感じですかね。
もちろん参考になるものがあれば、それはそれで事前にインプットするべきだと思いますが、それだけではどうにもならないっていう感覚はありますね。
ありがとうございます、なるほど。
でも本当にそこも、今回前回前々回ともいろいろお話を伺ってきましたけど、やっぱりとにかくやってみるっていうところがすごい一個のマインドとして大事なんだろうなってお話聞いて感じましたね。
番組ではリスナーの皆さんに参加してより楽しんでいただけるよう、ゲストに質問したいことを番組詳細欄にあるフォームにて事前に募集しています。
採用されたご質問は番組内で紹介し、直接ゲストの方にお答えいただきます。
はい、では早速、リスナーネーム、ジョーク・ジョークです。
いや、難しいですね。先程もちょっとしたように、教科書的なもので、まず考え方としては、そのチームについての資料を自分で集めるのが、
リスナーネームのマネージメント系の職種に移る際に一番初めに身に付けるべきスキルは何ですか?ときています。
こちらはどうでしょう。
何ですかと来てますこちらどうでしょう いやー難しいですねその先ほどもねちょっとしたように教科書的なものってないので
まず考え方としてはそのチームのマネージャーとしての成功って何ですか っていう定義をすると
これは多分その組織の立ち位置とか会社のフェーズとか 事業形態にもよると思うので答えを私がお出しすることはできないんですけど
まずそれを周囲の省庁の方であったりとか経営の方であったりとか 議論しながらまずマネージャーとしての成功っていうのを明確に言語化する
でそれをどう測るか それが定量でできれば定量がいいですけどもちろんそんなことばっかりではないので
定性であったりとか 定性的なものであっても客観的に観測できる事実できちんと測るとか
いうことを設計をしてことですかでなんかそれは多分ある種スキルというか 練習すればできる種類のものだと思うので
エンジニアから異なる領域への挑戦
なんかそういうところはやってみないとこれもねなかなか訓練は事前にできないんですけど 一番最初にこれができてるとマネージャーとしての立ち上がりは早いんじゃないかなって私は思ってますね
ありがとうございます じゃあこうなんかすごいマネジメントしての具体的なスキルっていうよりまず自分の役割とかミッションとかそういうものをちゃんと明確化して
それに向けてどういうことをやっていこうかっていうのを考えられるようにするっていうのがまず大事って感じですかね
そうですねまあそれを本当になんかふわーっとマネージャー上手だねとかではなく
これこうでこうだからこういうエビデンスがあるからこの成功だと思うとか 途中経過も測りながらそれを途中経過をいい感じにしていくために必要な個別具体のスキルテクニック
っていうのはあると思うのでそこまでいけば教科書的なものっていうのはかなりあると思いますが
まずはその前段にあるその目的とか目標とかを明らかにするところの方が重要だ高い気がしますね
今回はですねもう一つご質問いただいています 続いてがですねリスナーネームねむねむさんからのご質問です
藤倉さんの過去のインタビューを拝見させてもらったのですが職種の変化 エンジニアからマネージャーだったり今回のキャリーさんへの参画だったり
新しいチャレンジだったり不安に感じてしまう人もいそうなことを安定して前向きに 取り組まれていてすごいなと感じました
これまでのキャリアなどでこういった考え方に至ったきっかけなどあれば知りたいです とのことです
はい これもだからわかんないんですけどまぁ
もちろんその元来楽観的だからっていうのは多分にあると思うんですけど まあ何かそのやっぱりうまくできなかったとしてもそれは自分が得意では
ないということが明らかになるというポジティブな現象だなと思っているということと まあもちろん会社からの期待があればそこに対して期限とか時間軸みたいなものはあるとは思いますが
とはいえなかこう自分がうまくできなかったなって諦めるまでは失敗じゃないって思ってるんで で自分がいやー上手にできたなって言えるまでしつこくやるっていう感じ
だし あと何かそのそうですねロールを変えたりとか
えっと転職をするって時にまあもちろんでその 今まあキャリーという会社に入ってうまくいかなかったからといって全職に戻るみたいなそういう話
じゃないんですが とはいえなかその過去に成功してきたものっていうのはこれ多分事実なので
なんかそこには自信を持ってもいいんじゃないかなって思うんですよ でもし今回うまくいかなかったら自分の自信なる領域に戻せばいいだけの話なので
そしたらねやっぱり実績があればそこで活躍できるはずですから っていうなんかそうですね
うまくいかなくても損がないしその得意じゃないってことはわかるとか チャンスはあるしやらないてはないなって思ってるみたいな感じでまあそう考えるのが
多分だから楽観的だからなんですかねはい ありがとうございます
前向きな態度で不安に立ち向かう
まさに藤倉さんのマインドというか 今回3回にわたりいろいろ聞いている中で感じたのはそこのこう
そもそも失敗なんてないよねっていうのとそこに対してとにかくいろいろやってって でもそこの成功ができたらそこを積み重ねていくっていう本当にそのマインドそのもの
だなって思ったので 僕も是非そういうマインドにしていろいろ挑戦していきたいなって思いました
藤倉さん3回にわたりありがとうございました ありがとうございました 最後にですね何かお知らせなどあったらお願いします
はいこれを聞いてくださっている方々はエンジニアの方とかこれからマネージャー 住んでいくとかいろんな工作種5年で経験の方いると思うんですけど
やっぱりなんか皆さんには前向きにいろんなことチャレンジしてほしいなと思いますし 私がお話しした海外の経験だったりとかも一つ参考にしていただければと思います
では私の日々の役割でいうと日本CTO協会の理事をやらせていただいているので何か例えば会社を立ち上げてファウンダーとしてCTOになられた若い優秀な方々とかも個人会員として入っていただければ同じような競技だったりとか大先輩CTOとかもいらっしゃるので
そういったところでネットワーク作っていただきたいなと思いますし 一方で私が所属している企業のキャディ株式会社もエンジニアの採用とか一方でやっているので
製造業で何かインパクトのあるようなソフトウェアの開発っていうのが興味があるなという方がいらっしゃればもちろんご応募いただければ嬉しいなと思っています
藤浦さん3回目あたり本当にありがとうございました
ありがとうございました
すごく学びが多くてとても楽しかったです
さてこの番組では感想や次回ゲストリクエストなどお待ちしております
番組詳細欄にあるリンクよりお気軽にご投稿ください
Xではハッシュタグ聞いたFMをつけてポストしてください
表記は番組名と一緒でQFMが大文字残りは小文字です
そしてアップルポッドキャストやスポティファイのポッドキャストではレビューもできますのでこちらにも感想を書いてもらえると嬉しいです
聞いた株式会社はエンジニアを最高に幸せにするというミッションのもと
エンジニアに関する知識を記録共有するためのサービス聞いた車内向け情報共有サービス聞いたチームを運営しています
ぜひカタカナで聞いたと検索してチェックしてみてください
来週も火曜日の朝6時に最新話が更新されます
番組のフォローをして最新話もお聴きください
お相手は聞いたプロダクトマネージャーの清野俊文とキャリー株式会社の藤倉重本でした
