CTOとしての初期の取り組み
日本最大級のエンジニアコミュニティ、Qiita プロダクトマネージャーの清野俊予です。
この番組では、日本で活躍するエンジニアをゲストに迎え、
キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続きゲストは、コードが動かないので変えれません、の強調者で、
株式会社ナナビット代表として、日本最大級のエンジニアコミュニティ、
コードが動かないので変えれません、の強調者で、株式会社ナナビット代表の桜庭ひろゆきさんです。よろしくお願いします。
よろしくお願いします。ナナビットの桜庭です。ザルというIDで活動しています。よろしくお願いします。
今回もですね、僕もザルさんとお呼びできたらなと思っています。
ザルさんとお送りする2回目のテーマは、CTOの仕事のリアルです。
今回はですね、前回キャリアのところいろいろお伺いしてきましたが、
今回はやっていらっしゃったCTOについてもっといろいろお伺いをできたらなと思っています。
改めてCTOとしてやっていたことについてお伺いできたらなと思っています。
前回CTOとして10年やっていらして、その中でフェーズが変わってきたみたいなお話があったかなと思うんですけど、
それぞれのフェーズごとにCTOとしてやっていたことみたいなところを改めてお伺いしてもよろしいですか。
僕がCTOになりたての頃、まさに10年前のときなんですけど、
前回もお話ししたように、当時の社内って開発があまり強くなくて、
エンジニアよりもビジネス、営業のほうが強いっていうような組織でした。
ないがしろにされてたわけじゃないんですけど、むしろよくしてくれたなと思うんですけど、
開発とかプロダクトの品質を上げていくってことが非常に弱かったですね。
開発環境も良くなかったですし、そういう環境の中でプログラマーとして働いていくっていうのに納得感があまりなかったので、
まずは中にいるプログラマー自身がプログラミングとかプロダクト作りを楽しめるような環境を作っていくっていうような工夫をしてましたね。
イメージで言うと、リードをしていくっていうよりも、それぞれのエンジニアのメンバーが活躍できる場を作るみたいなところを最初やってらっしゃったってことですか。
そうですね。結構いろんなことやってたんですけど、例えばいわゆる社内勉強会っていうのを週一で必ず開催していたりとか、
また社内のハッカソンとか、あと社内イスコンとかもやったりとかしてましたね。
それ以外にもまさにKITAのアドベントカレンダーがあると思うんですけど、
それを当時開発チームみんなで持ち回って記事を書いていこうみたいな、そういうイベントを作ったりして、
なるべくエンジニアがアウトプットしたりとか、あるいは技術を学ぶっていうことを積極的にできるような空気感を作っていくっていうのをやってましたね。
なるほど、そうなんですね。最初はエンジニアとしてのアウトプットとか、学習の際ぐらいうまく回っていくようなところを作ってらっしゃったってことですね。
そうですね。当時働いてたときに、僕自身はすごくインプットアウトプットとか好きなタイプだったので、それが普通かなと思ってたんですけど、
初めてBASICに入って、いろんなエンジニアの方と一緒に働いてみると、本当に様々な性格のエンジニアの方がいるなと感じて、
アウトプットがすごく苦手というか、あんまりアウトプットすることに喜びを感じない人とかもいたんですね。
でもその本人に聞くと、したいけどやり方わかんないとか、したいけどちょっと怖いみたいな、そういうことがあったので、
もっと気軽に発言できるような、そういう文化っていうのを作っていくのを重視してましたね。
プロダクト改善のアプローチ
なるほど、そうなんですね。ありがとうございます。
そこからまたフェーズが変わってきて、違うことをまたやってらっしゃっているタイミングとかもあったかなと思うんですけど、そこからアクションってどういうことに変わっていったりしたんですか?
そうですね。まずはプログラミングを楽しむ環境ができたので、みんなのモチベーションが上がっていったんですね。
本丸の事業に対してどう貢献していくかっていうところで、プロダクトの品質とか開発プロセスをもう少し良くしていこうということで、
当時まさに常に開発が炎上するような状態だったので、プロダクトマネージャーなんて当然いなかったですし、プロジェクトマネージメントもまともにやってないみたいな中だったので、
まずはちょっとアジャイルをやってみようと思って、スクラムを学んで開発チームの中に導入して、ビジネスサイトを巻き込んで勉強会とかをして開発プロセスを改善していくみたいな取り組みを中心にやってました。
なるほど。前回のお話だとエンジニアの数が20名ぐらいでしたっけ?
そうですね。そこから徐々に増えて40人ぐらいにはやってましたかね。
チームはどのぐらいあったんですかね?
チームは5、6チームぐらいいましたね。
その数のチームとかに一気にアジャイルとかそういう取り組みを導入するのって、1CTOとしてなんとかできるところから外れてるような気がしたんですけど、当時どういう取り組みをやってらっしゃったんですか?
なので、まさにスクラムをやり始めた時は、1チームをまず決めて、そこに僕がスクラムマスターとして入って、そこで一通り回せるようになるので、半年間ぐらいかかりましたけど、やって、それが効果があるなと実感したら次のチームに移るっていうことをやってましたね。
本当に一つ一つ移動しながら全部のチームをアジャイル化していくみたいな。
そうですね。
そういうことをやってましたね。
暗議してましたね。
そうなんですね。
じゃあ最初のフェーズとしてはアウトプットみたいなところで、エンジニアが楽しめる状態を作る。そこから次はチームを良くしていくというところをやってらっしゃったんですね。
そうですね。あとは、その当時まさに機械学習が流行っていて、まだ事業にどうやって活用できるかっていうのは見えてなかったんですけど、手段として持っておいたほうがいいなと思ったので、業務時間中に新しい技術を取り組む、トライをする時間っていうのを作って、プロジェクトチームを立ち上げて、いろいろな挑戦をしたりとかもしてましたね。
なるほど、そうなんですね。そこからまたフェーズが変わっていったりするんですかね。
そうですね。その後は、いわゆる採用と評価育成という組織のほうにフェーズしていって、いわゆるエンジニアで100名ぐらいの組織規模を目指そうよみたいな中で、どうやっていい人を効率的に採用できるかみたいなところに移っていきましたね。
採用と組織育成
なるほど。じゃあちょっとまたそこのタイミングでやることは変化が起こったってことですね。
そうですね。その時、まさに僕が自分で採用するみたいなところでスカウトのリストを作ったりとか、スカウティングのメッセージを書いたりとかっていうのもずっとやってました。
そうなんですね。なるほど。イメージでいうとそういうところって、ちょっとおっきめの組織の階層でいうと、CTOがいて、その下に部長だったり事業責任者みたいな人がいて、そこにマネージャーだったりがいて、次いわゆるアシスタントマネージャーとかチームリーダーみたいな人たちがいて、みたいなタイプの組織多いんじゃないかなと思うんですけど、当時のBASICさんはどういう組織構造だったんですかね。
時代によって変わるんですけど、中盤以降は僕とあとVPOEがいて、それ以外は各チームのリーダー、マネージャーですね、がいるっていう割とフラットな組織ですね。
そうですね。かなりフラットですね。そこの採用周りとかはザルさんが一手に引き受けてやってらっしゃったって感じですかね。
そうですね。僕だけじゃないんですけど、いわゆる採用プロジェクトチームみたいなので、僕とVPOEと、あとはその有志の開発メンバー3人ぐらいでやってましたね。
そうなんですね。ありがとうございます。ちょっと先ほどのお話に戻っちゃうんですけど、エンジニアとしてそれぞれの文化とか組織を作っていくってところをやってらっしゃったときって、
いわゆる数字としてのROIとか成果ってすごい表現しにくいところが故に結構取り組むところでなかなか二の足踏んじゃうみたいな会社さんとか組織ってそんなに少なくないんじゃないかなと思ってるんですけど、
当時ってそういう経営、他のCTOとしてやってらっしゃったと思うんですけど、違う経営層の人たちにどういうメッセージを伝えてそういう取り組みの承認を得ていたかとか、そこにゴーサインをもらってたかみたいなのってありますか。
これを言うと身も蓋もない話になるんですけど、いわゆる僕が圧倒的な成果を常に出し続けるので、僕を信頼してくれて僕が言うことならOKという雰囲気を作ってましたね。
そうなんですね。
なので、いわゆるプレゼンをしたりとか寝回しをしたりとかっていうのはほぼなく、こういうふうにした方が良くなるよっていうそのメッセージングだけして、あとは割と自由にやらさせてもらってましたね。
そうなんですね。じゃあ結構そこは一任してもらっていたみたいな。
そうですね。いわゆる僕がよく使うその信頼残高みたいな考え方をしてるんですけど、普段の仕事の仕方とか成果とかで信頼が少しずつ溜まってくると思うんですね。
それが一定の敷地超えると、こいつが言うんだったら任せてみようみたいな状態になるので、そういうのをすごく意識してやってましたね。
そうなんですね。じゃあ本当にそこまでやってきた実績っていうところをベースに、それ以降の取り組みも信頼してもらっていたっていう感じですか。
そうですね。
今のチームとしての動きのところまでは、ある意味でエンジニアとしての領域にも近いというかチームビルディングとかにも近いところなので、いろいろとっつきやすさあるような気がするんですけど、
その後半の組織的な動きとかいわゆる経営的な動きのところって単純にエンジニアとしていろいろ学んでいるだけではキャッチアップできないところとか、
とっつきにくさみたいなところもあるんじゃないかなと思うんですけど、当時ってそこら辺でどうキャッチアップしていたかというか、どうこういう方針で行こうみたいなところの指針って作ってたんですか。
いやこれは結構悩み続けてまして、当時CTO協会とかが発足し始めたりとかして、いわゆるCTOとは何かみたいなことがいろいろ論ぜられるようなタイミングで、
そういうイベントとかに顔を出したりとかしていろんな人の話を聞いたりとかしたんですけど、全員言うことは違いますし、全員悩んでると。つまり答えないなと思ったんですね。
なので、あんまり外向いても仕方ないなと思ったので、まさに一緒に働いてる人とコミュニケーション取りながら、何が課題なのかとか、どういうところに不満があるのかみたいなのを聞きながら、自分がいいと思うものを信じてやるっていうような感じで何とか踏みとどまってたっていう感じですね。
なるほど、そうなんですね。いわゆる定量的に評価しづらいようなところなのかなと思ったんですけど、特に採用とかって結構足が長いというか、まずは会社を認知してもらって印象アップをして、そこで興味を持ってもらってみたいな感じで、結構足が長い取り組みにはなるかなと思ったんですけど、いわゆる改善とか、今お話していたやってみるしかないというところはある一方、やってみたことの振り返りとかってどうやってやったのかなみたいなところも気になるんですけど。
まさに採用は数字に起こして、どこにボトルネックがあるのかとか、何が課題だったのかっていうのを常に振り返るようにしてましたね。
そうなんですね。
採用と評価制度の重要性
なので、例えばこういう候補者にはこういう面接のメンバーを当てようとか、その相性によって候補者の魅力をどう引き出せるかっていうのが結構変わってくるので、そこも考えてフィードバックサイクルっていうのを回してましたね。
そうなんですね。じゃあ結構そこは定量的にいろいろ見ることができたってことですね。
そうですね。で、これ笑い話なんですけど、僕が一例面接を担当すると、その後の採用に至るまでの率が異常に低いという数字結果が出て、桜場に面接を任せるのはまずいんじゃないかっていう問題も出てきたりとかしてましたね。
そうなんですね。じゃあ結構そこまでいろいろ定量化されて評価振り返りっていうところはしてたってことですね。
そうですね。
ちなみに今組織的なところっていうところでされていたというお話は今伺ったと思うんですけど、それ以降採用ってところは人が例えば増えた後の組織っていうところでやっていることみたいなところも変わったりはしたんですかね。
基本的に新卒採用を毎年していたので、いわゆるその組織の育成とかっていうのは新卒がどんどん代替わりしていって、後輩に教えるみたいな形でできていたので、そこのバランスはすごく良かったなと思ってますね。
逆に言うと中途採用とかはすごく難しくて、どういう人をどういうポジションに取ればいいかっていうそこら辺はすごく課題が残って、結果的にはそんなにうまくいってなかったですね。
なので、その組織自体も新卒が入るベースぐらいなので急激に大きくなるっていうこともなかったですし、ある種同じ状態を維持してても問題なかったとも言えますし、大きく変化させることができなかったっていうことでもあるかなって思ってますね。
なるほど。そういう、ある意味で組織として成長できる状態とか、大きくなって、自分たちが大きくなっていけるフェーズになったときって、ザルさんはどういうことをやってらっしゃったりしたんですか。
いわゆる評価制度の設定というのはやりましたね。改善というよりは抜本的に評価制度を変えるっていう機会が前者的にあったんですけど、そのタイミングでエンジニア組織も評価制度を変えましたね。
組織が大きくなってくると、いわゆる階層がどうしても増えてくるので、今までは僕がほぼ全エンジニアの評価っていうのを割とリアリティを持って見れてたんですけど、30人、40人超えてくると全員の働きぶりっていうのは当然見れてこないので、誰かに評価を任せなきゃいけないと。
そこらへんの評価の信頼度とか制度とかっていうのがどうやって担保できるかみたいなのはよく話し合って改善してましたね。
なるほど。次は社内の仕組みとか構造とかそういうところに対していろいろアクションを取ってらっしゃったってことですね。
CTOとしての役割分担
そうですね。ただもう評価制度は僕なるべく軽い方がいいと思っているので、極端には評価しなくても済むような状態が理想だなっていう中で、どうやってその説明責任というか会社に対してこの人の給料を上げるべきかっていうのはいろいろ当時のVPOEと一緒に考えてやってましたね。
そうなんですね。ありがとうございます。先ほどからVPOEっていう方のお話ちょこちょこ出てるかなと思うんですけど、VPOEの方とCTOとして役割ってどういうふうに分けていたんですか?
もう完全に僕が技術で、VPOEは組織で分離させてましたね。
なるほど。具体的に取り組んでることってどういう違いがあったりしたんですか?
いわゆる技術的に難しい部分だったりとか、これ誰もできないなみたいなところを僕がスポットで入って現場を荒らしていくみたいなやり方と、あとVPOEはきちんと事業と組織っていうのを考えながら開発チームがどうあるべきかみたいな。
なので育成もそうですし、プロダクト、ビジネス側も含めてどういう体制でプロダクトを作っていくべきだみたいなところをすごく事業部長と議論していくような役割分担でしたね。
なるほど。じゃあ、もともとザルさんが当初CTOになられたタイミングでやってたようなところと後半でやっているようなところが役割がちょっと分かれたような感じのイメージなんですかね?
そうですね。なのでVPOEが立てられてからは、より僕が好きな得意な技術領域に特化できたっていうのはあるかなと思います。
そうなんですね。なるほど。ありがとうございます。
ここまででCTOとしてやられていたことをいろいろお伺いしてきたと思うんですけど、ここでお伺いしたいのが、ぶっちゃけCTOをやって面白かったか楽しかったかしんどかったかで言うとどうですか?
一言ではちょっと言い表しにくいんですけど、最後は本当苦しかったですね。最後の2年間本当苦しかったんですけど、それ以外は基本的にもうめちゃくちゃ楽しかったです。
いわゆるCTOとしての面白さ楽しさってどういうところなんですか?
これを言うとすごく語弊があるかもしれないんですけど、全部自分で決められる感。でも実際自分で全部決めるわけではないんですけど、この方向性なんじゃないかってみんなにプレゼンをしたときに賛成するメンバーもいれば、それはなんかないんじゃないかって反対するメンバーも当然いるんですよね。
ただその議論自体がそもそも面白くて、その議論の渦を自分で巻き起こしてるっていうところの感覚がすごく面白かったですし、それを実際にこう遂行していく中で結果が出せた時とかっていうのはやっぱすごく面白かったですね。
組織を自分がこう何かを巻き起こしている感というか、そういう感覚なんですかね?
そうですね。ただ僕の中ではそんなに会社を変えてやろうとか事業をどうにかしてやろうみたいな、そんなに広い目線を持っているというよりは、もう本当純粋一プログラマーとしてより楽しい方向を選ぼうよみたいな、そういうのをみんなと一緒にワイワイやっていくっていう感覚ですかね。
そうなんですね。逆に最後の2年はしんどかったってお話もあったと思うんですけど、CTOとしてのしんどさというか辛さっていうのはどういうところにあるんですか?
やっぱりCTOっていろんなロールあると思うんですけど、究極絶対経営に関わるメンバーだと思うんですよ。
なので経営にコミットするっていうことなんですけど、エンジニアとしてのその考え方と全く違う考え方をしなくちゃいけないので、ある種エンジニアである自分を殺さなきゃいけないっていうそういうところが自分の中でやっぱり割り切りができなかったですし、
よく言う役割を演じるみたいな、そういうことも頭では理解してても体がついていかないっていうところが結構辛かったですかね。
なるほど。本当にCTOってエンジニアではなくてエンジニア観点での経営者になっていくのかなと思うので、やっぱりそこのシフトチェンジというか、
もともとエンジニアやってる人ってみんなエンジニアリングが好きでやってる人が多いと思うので、やっぱりそこの葛藤みたいなのはあるんだろうなと思いますね。
それってCTOが多分最低のレベルかなと思うんですけど、いわゆるマネジメントとかそのぐらいのレベルでも僕自身も葛藤を感じていたタイミングとかはあったりするので、
結構みんな同じようなところを感じたりするんじゃないかなってお話聞いて感じました。
これも一言で表現しづらいかもしれないんですけど、CTOやってよかったなって思いますか。
やってよかったですね。
さっき言った最後の2年間以外は本当に楽しかったですし、いろんな挑戦もできた時間だったし、
あと一緒に関わる人からのフィードバックっていうのもある種厳しい意見とかもあったりするんですけど、
CTOの挑戦と次のキャリア
そういうのが得やすいポジションだなとも感じてたので、そういう意味ではすごくやってよかったなと思いますね。
なるほど。どんな人におすすめとかありますか。
絶対必要なのは衝動がある人かなと思っていて、なんか自分で何とかこうしてやりたいみたいな、
そういう強い思いがある人がやっぱ向いてるなと思っていて、誰かからお願いされてやるような役割じゃないなと思ってるんです。
いつの間にかCTOというロールがついてきたみたいな、そういうことが自然で力を発揮しやすいなと思うので、
自分の中にこうなんかよくわからないエネルギーみたいなものがマグマみたいに溜まってるみたいなタイプの人はすごく向いてるなと思いますね。
なるほど。なるほど。その衝動みたいなところが大事なんですね。
大事だと思いますね。やっぱそのよくビジネスで言われるパッションみたいなものだと思うんですけど、
そういうのがないと困難に理不尽な状態に対して立ち向かっていくときにエネルギー不足になるというか、
っていうのは僕自身も感じてたので、そこに対してモチベーションを持ち続けられるっていうのはすごく一つの能力とも言えるかなっていうふうには思ってます。
ありがとうございます。逆にこういう人向いてないだろうなとかありますか?
向いてないのは、さっきも言ったんですけど言われたことを淡々とこなすとかうまくやるみたいなタイプの人はあんまり向いてないかなって気はしますね。
合理的すぎるとか効率的なものを目指しすぎるみたいなタイプの人は理屈っぽくなっちゃうだけで下のメンバーの人たちがあんまりついてこないみたいなところはあるかもしれないですね。
ある意味でカオスなものをカオスなりに進められるパッションみたいなところが大事みたいな。
そうですね。カオスを楽しめるタイプの人はすごく向いてると思います。
なるほど。ありがとうございます。今いろいろお話聞いていく中で、自分もCTOみたいなそういうロールやってみたいかもって思ってるリスナーの方とかもいるんじゃないかなと思ったんですけど、
CTOになりたいなって思ったらまず取ったほうがいいアクションってどういうものだったりしますか?
暴力的な意見になるんですけど、情緒を吸っ飛ばして自分がやるべきだと思ったことを勝手にやるっていうことですかね。
なるほど。
失敗したら後で謝りましょうっていう。
当然普段のコミュニケーションの中で寝回しじゃないですけど、自分がそういうことをやっても信頼されるような取り組みしてるっていうのが大前提だと思うんですけど、
自発的に何が課題なのかを自分で見つけ出して、それを自分の力で解決していく。
会社の何かリソースとかを通報してもらうっていうよりは、自分のパワーで何とかしていくみたいなところがいいんじゃないかなとは思いますね。
なるほど。じゃあ日々の工業は普通にこなしつつ、自分で追加で仕事を作っていけるというか、
そうですね。
自分でやるものを作ってそれをこなせるぐらいの大胆なアクションが取っていけると、CTOに近い素養とかそういうものがついてくるってイメージですね。
そうですね。ただ完全にこれ生存バイアスというか、その人の精神的あるいは体力的な問題も結構絡んでくるので、ただの一位、僕の意見っていうぐらいで聞いてもらえればなと思います。
ありがとうございます。
あとそうですね、これもちょっと僕聞いてみたいなと思っているところが、CTOとかいわゆる最高責任を持っているロールになった後の次のキャリアってあんまりイメージ持ってない人多いんじゃないかなって気がしていて、
そこがある意味でゴールっぽくなっちゃうというか、そこから先があんまりイメージない。とはいえでもCTOとして定年まで仕事をし続けるみたいなパターンってそんなにないかなと思うんですけど、
CTOに実際になってみてから次のキャリアってどういう選択肢がありそうかみたいなところってありますか?
CTOの役割とキャリアの選択
多分二分されると思うんですけど、自分でいろいろ決めて自由にやっていきたいっていうふうに感じる人、CTOとか経営者、ボードメンバーとかでそういうのを一度体験したときに、
これはいいなと思った人は独立した方がいいなと思いますね。そうじゃなくて、みんなと一緒に何かをやっていきたいとか、
一開発者として開発に集中したいみたいな、そういう現場感が強い人は別の組織とかに移って一コントリビューターとしてやっていくっていうのがいいんじゃないかなと思いますね。
なるほど。じゃあもうそこから自分で、一組織の責任者というところから自分でも会社を立ち上げるみたいな選択肢と、ある意味そこまでやったらまたゼロからのスタートというか、
新しい挑戦としてまた一エンジニアとしてキャリアを積んでいくみたいな選択肢がありそうっていう。
そうですね。正直技術領域ってもう海のように広がっているので、自分が得意としている領域なんてほんと小さなところなんで、
他の領域に飛び込んだらまた新しい挑戦が技術的な挑戦が続いていくっていうのはすごく刺激的な職業だなっていうふうに感じているので、
たぶん次のキャリアで悩むというよりはもはや自分の気になったところとか、なんか面白そうだなと思うところに飛び込んでいけば自然とうまくいくんじゃないかなっていうふうに思います。
もう一個そこで聞きたいのが、マネジメントとか経営とかに一回携わってしまうと、技術っていうところに対して、
シンプルな仕事の中でいうと設定を持つ機会ってどうしても減ってしまうってよくあることなんじゃないかなと思うんですけど、
そこのブランクみたいなところを、どんぐらい影響するのかというか、一エンジニアとしてまたキャリア積んでいきたいなってなったときに、
どんぐらい経営に集中するとかマネジメントに集中していた期間っていうのがブランクになるのかなっていうのはちょっと気になりました。
エンジニアとしての再出発
ブランクは全く影響しないと思ってます。
そうなんですね。
水泳とかと一緒で、一度身についた基礎的なものってそんなに忘れないんですよね。
さすがに久々に泳いだらめっちゃ筋肉痛になるとか、すぐ息上がるとかはあると思うんですけど、
そういうのもまた日々のトレーニングですぐ取り戻せるものだったりするので、
プログラミングをあんまりやってない人がブランクを開けたら当然何もできなくなってると思うんですけど、
そうじゃない人であれば割と半年とか経たずにキャッチアップして戻ってこれるんじゃないかなっていうふうには思ってますね。
なるほど。ありがとうございます。
じゃあある意味でそういう一旦現場でのプログラミングとか開発ってところが離れたとしてもそのキャリアが立たれるわけではないってことですね。
そうですね。なので全然不安がらずマネジメントとエンジニアリングを行き来するぐらいの感じでやっていければいいんじゃないかなと思いますね。
ザルさん今日はありがとうございました。まだまだお話ししたりないので次回もザルさんとお送りします。
今回はCTOのお仕事のところについていろいろお伺いしてきました。
やっぱりCTOっていう役割自体が本当に広いというか本当にいろんなことをやる仕事なんだろうなっていうところはお話し聞いて感じたのと、
そこはすごい面白そうだなって思う一方、やっぱりいろんな葛藤とか難しさっていうのもあるんだろうなっていうふうにいろいろ話を聞いていて感じました。
ぜひ今回のお話を聞いたリスナーの方とかから、やっぱりそこら辺に挑戦したいなって思った方とかがいらっしゃったら、
今日お話しした内容とかを参考にしていただけるとすごい良いんじゃないかなと思いました。
僕も今回のお話はすごい参考になったので、これからいろいろキャリアのこととか自分の役割みたいなところを考えるときは参考にさせていただきます。
さてこの番組では感想や次回のゲストへの質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
XではハッシュタグKiitaFMをつけてポストしてください。
表記は番組名と一緒でQFMが大文字、残りは小文字です。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録・共有するためのサービスKiita、社内向け情報共有サービスKiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
来週も火曜日の朝6時に最新話が更新されます。
番組のフォローをして最新話もお聞きください。
お相手はKiitaプロダクトマネジャーの清野俊文と、
7bitのザルでした。
