1. Qiita FM-エンジニアのキャリアを深掘り-
  2. #70 失敗と学びから見つけたエ..
2025-09-01 27:12

#70 失敗と学びから見つけたエンジニアキャリアの道【ゲスト:AWSジャパン 技術統括本部 シニア機械学習デベロッパーリレーションズ 久保 隆宏( icoxfog417)さん】

spotify apple_podcasts

今回からのゲストはAWSジャパン 技術統括本部 シニア機械学習デベロッパーリレーションズ 久保 隆宏( icoxfog417)さん


<トークテーマ>

・大学時代にC++から始まったプログラミング人生

・機械学習との再会:研究開発部門への転機

・プロダクトマネージャー挑戦と大きな挫折

・転職直後のプレッシャーと不安の3つの要因

・目標設定における「ロジック90%+パッション10%」の考え方


<久保 隆宏(icoxfog417)さんX(Twitter)ページ>

https://x.com/icoxfog417


<X(Twitter)ハッシュタグ>

#QiitaFM


<番組へのメッセージはこちらから>

https://forms.gle/K9HyUGy7phDBGpht7

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

サマリー

今回のエピソードでは、AWS Japanの久保隆宏さんをゲストに迎え、彼のエンジニアキャリアにおける失敗と学びを深く掘り下げます。プログラミングの始まりやキャリアの転機、機械学習への道筋についての貴重な経験が語られます。久保さんは、AWS Japanでの機械学習デベロッパーリレーションズとしてのキャリアを振り返り、失敗を経て成長していく過程について話します。特に、デベロッパーリレーションの価値をどのように確立していったか、その課題についても深く掘り下げます。久保さんは、自身のエンジニアキャリアや失敗から学んだことを共有し、AWSのカルチャーやプロダクトに基づく意思決定の重要性を強調します。チャレンジを通じて得られる学びがキャリアに繋がるというメッセージが印象的です。

久保さんの自己紹介
日本最大級のエンジニアコミュニティQiita プロダクト開発部部長の清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、 キャリアやモチベーションの話を深掘りしながら、
エンジニアの皆さんに役立つ話題を発信していきます。
今回からのゲストは、AWS Japan 技術統括本部 シニア機械学習デベロッパーリレーションズで、
Kiitaアカウントネーム icoxfog417さんこと久保隆宏さんです。よろしくお願いします。
よろしくお願いします。
すいません。今回、音質にばらつきがありますが、ご了承ください。
では、最初に軽く自己紹介をお願いしてもよろしいでしょうか。
AWSでシニア機械学習デベロッパーリレーションズを担当している久保といいます。
シニア機械学習領域のデベロッパーリレーションで、機械学習といえばAWSというふうに、
皆さまに持っていただくべく、ブログやイベントの登壇というところはもちろんなんですけれども、
お客さまの事例を作ったりとか、あとは皆さんからいただいたフィードバックを
開発チームのほうに伝えて、よりAWSのサービスを良いものにしていくという活動もしております。
よろしくお願いします。
よろしくお願いします。久保さんには、Kiitaにもたくさんいろいろアドバイスをしていただいているので、
3回目のところでいろいろそこら辺もお伺いできたらなと思っております。
プログラミングとの出会い
久保さんとお送りする1回目のテーマは、失敗と学びから見つけたエンジニアキャリアの道です。
ということで、まず1回目はですね、久保さんの今までのキャリアについてお伺いをしていきたいなと思っております。
今はですね、今自己紹介で伺ったようなところをやられているんじゃないかなと思うんですが、
ずっとやっているわけではないかなと思うので、ぜひ今までの久保さんの人生についてちょっとお伺いができると
ありがたいなと思っているところです。
最初にまず聞きたいなと思っているのが、プログラミングを始めたのっていつなんですかね。
プログラミングを始めたのは私は大学時代で、ちょうど筑波大学の、まだあるのか分からないですけど、
社会工学類というところにいてですね、そこでプログラミングの授業があって、
たぶん一番最初に本格的に触った言語はC++ですね。
そこからプログラミング人生が始まったというようなところですね。
そうなんですね。
じゃあ逆に言うとその大学入るまではあんまりプログラミングとかはされていなかったという感じなんですかね。
そうですね。
私がたぶんまだ大学生の、ちょうどあんまり年齢がバレてしまうので、
ちょっとあんまりつまびらかにその、はわかられるところではあるんですけど、
あんまりこの高校の時にプログラムをやらせてやっているというところはそんなに一般的ではなくて、
たぶん大学に入って工学系とか数学系とかで、
初めてプログラムに触れるということが私の世代では多かったんじゃないかなというふうに思います。
ありがとうございます。
もともとその大学学部にはプログラミングみたいなのが興味があって入ったのか、
それか全然別の目的で入ったけど結果的にプログラミングでやったのかみたいな感じでどっちなんですかね。
これは結果的にプログラミングをやっていたというところで、
そうなんですね。
私が所属していた社会工学類っていうところは、
この社会的な問題っていうのを工学的な手法で解決するというところをアプローチしていて、
例えば現行の窓口って何個ぐらいあると適用率が少なくなるのかであるとか、
大学とかの駐車場がどれぐらいのサイズだと満杯にならないのかといったようなですね、
社会的な問題に対してその数理的な手法を用いてアプローチするというようなところを研究していてですね、
そのシミュレーションとかを行うのにプログラミングが必要なので、
じゃあプログラミングを勉強する人があるというような流れで始めたっていうところですね。
そうなんですね。
その当時プログラミングにハマってたのかどうかはちょっと分からないんですけど、
結構やられて今までキャリア積んでるっていう中で、
当時のプログラミングの面白さみたいなのってどういうところに感じてたんですかね。
面白さというか、私の場合は結構非常に痛みが深かったというところがあって、
どういうことかというとですね、
教授が書いたプログラムがあったんですね。
C++で。
この研究にこのプログラムを使うので、
ひいてはこれを理解して動かしてくれたまえと、
そういう話になるわけですね。
皆さん知ってるかどうか分からないですけど、
トラップが多い言語ですと。
そういう中で様々なですね、C++の言語の複雑な仕様を理解して、
なおかつ当然自分の研究もしないといけなかったので、
その教授のプログラムをカスタマイズする必要があったんですね。
どういうふうにカスタマイズすると効率が良くて、
バグが起こらないのかというところを突き詰めていった結果、
その調べること自体がいつの間にか楽しくなっていて、
プログラミングも最終的には教授に引き渡して返すという、
ある意味恩返しみたいなところに至って、
ある程度熟達したというところがあって、
そういうような関わり方と、あと勉強の仕方でしたね。
なので、今だとウェブアプリケーションとか作りたくて、
プログラミング学んだとかっていう方結構多いかなというふうに思うんですけど、
私の場合は教授から与えられたコードを何とかして読解して、
自分なりにカスタマイズしないといけないという、
非常に追い詰められた状態からスタートしたというのが、
私とプログラミングの接点ですね。
キャリアの転機
そうなんですね。ありがとうございます。
そこからプログラミングというものに関わりだして、
キャリアを積んでいくかなと思うんですが、
ファーストキャリアではどういうことをされていたんですか。
ファーストキャリアでは大学卒業したのが2006年で、
そこからTIS株式会社というところに所属したんですけど、
大学の時から社会的な問題をプログラムで解決するというのが、
やっぱり面白みというところがあったので、
お客さんの業務課題というところとプログラミング両方が
扱える場所がどうかというので、
一番最初は製造業向けのお客様のコンサルティングと、
その結果必要だというふうに分かったシステムについて
実装するというようなコンサルティングと開発が一緒になった部署で、
キャリアをスタートしたというような感じですね。
その当時はいわゆるシステム開発みたいなのをされていた
みたいなイメージですか?
そうですね。要件定義、コンサルティングとシステム開発。
その時は、SAPって聞いている方の中で
どれくらい知っている方がいるかというところなんですけど、
ドイツの会社が開発したSAPという、
お客様の業務全般を扱う機関系システムというのがあるんですけども、
それのカスタマイズとか周辺システムの開発というところをやっていました。
やっぱりそこでやっていることは、プログラミングがもちろんされていると思うんですけど、
もともと大学でされていた経営工学みたいなところの流れで
そういうTISさんの中でもいろいろやられていたようなイメージなんですかね?
そうですね。経営工学とは直接は関わらなかったんですけど、
お客様の業務を理解して整理して、
それの解決に最適なものを作っていくというところ。
あとは分かりやすい例で言うと、文系的な領域と理系的な領域。
その業務の理解とプログラミング両方を活かして活動するというところは、
大学の時から変わらないし、それがやりたかったところだったので、
そこにあまりズレはなかったかなというふうに思います。
ちょっと話戻っちゃうんですけど、そもそもそういう経営工学に興味を持っていたのは何でだったんですか?
どうですかね。そもそも私の中で社会工学類というところは、
3年生か4年生ぐらいで専攻が分かれるというところがあって、
都市計画科、経営工学科、あともう1個あったんですけど、どれかやるかというところがあって、
その時に一番関心があった。
プログラミングを書くとかシミュレーションをするというのがやっぱり好きだなというところがあったので、
それで選んでいたというところがあります。
なるほど、そうなんですね。
社会工学的なところとか経営工学的なところに関わっていて、
いろいろやられていたということですね。
そうですね。
今のお話の中で言うと、
今やられているエザフリスさんのお仕事にはまだちょっと距離があるなと感じているんですけど、
いわゆるキャリアの転機点というか、
そういう今までの流れからちょっと変わってきたタイミングとかっていうのはあったりするんですか?
キャリアの転機は私の中では大きく2つあって、
1つは一番最初専属からやってきたコンサルティングの事業部から機械学習の研究開発部門に移ったというところですと、
コンサルティングは多分10年ぐらいやってたと思うんですけど、
やっぱりお客様の業務を最適化していくというときになると、
いわゆる計画系、計画がそもそもうまくできていないと、
業務もその後メタメタになるというところが分かってきたので、
ただどうやってお客様が計画しているかというと、
熟達した人が鉛筆をなめなめして、
こんな感じじゃないみたいなっていう風にやっているというところがあって、
これもう少しプログラミングとかでアシストできないかなという風に考えていたときに、
ちょうど機械学習とかの技術が出てきたというところもあって、
じゃあちょっと本格的に機械学習というのを勉強したいなという風に思って、
同じ会社の中の研究開発部門で移動したというところが、
転機としては大きいですと。
そこで初めて機械学習の講座、
大学時代にやっていたとはいえ、
そのときは10年以上前でも線形台数とか記憶の彼方に消し飛んでいるという状態から、
アンドリューング先生、コーセラーで知っている人は、
スタンフォードのコーセラーの機械学習のコースを覚えているかと思うんですけど、
それで機械学習をゼロから学んで、
研究開発部門でなんとか生き抜いてきたというところが、
まず今機械学習医療機能デベロッパーの練習所なんですけど、
そこで機械学習というところの伏線が回収されたというところがまず一つあります。
転機の2つ目はプロダクトマネージャーをやったというところと、
そのプロダクトマネージャーがすごいうまくいかなかったというところがあって、
当時プロダクトマネージャーとしての私を知る人は、
あの人と一生仕事したくないというふうに思っても、
何の言い訳もできないというぐらい、
本当に今日いろいろな失敗をして、
そのときに思ったのが本当に機械学習を活かしたプロダクト、
研究開発部門でやっていた研究というのがプロダクトにできないかというところで、
事業部の方から声をかけていただいて、
それをプロダクト化するというところにチャレンジしたわけなんですけど、
この機械学習を使ったプロダクトとか、
プロダクトそのものというものがいかに作るのが難しいのかというのを、
本当に頭ではなくて、
身体ともにダメージとともに理解するという、
そういう人生の転機というか、
衝撃的なということがあってですね。
ただ、それを克服するとか、
本当にどうすればよかったのかというのを理解するには、
やっぱりバカ図を踏まないといけなくて、
プロダクトマネジメントって書籍に書いてあって、
キャリアの転機と失敗からの学び
内容は理解するのはそんなに難しくないんですけど、
それを実践するというのが本当に難しい学問領域というか、
ちょっとアートに近い領域かなというふうに思っていて、
じゃあ機械学習を使ったプロダクトのバカ図を踏んでいく、
そのノウハウというのを身につけていくとしたら、
どういうふうにしないといけないんだろうというふうなことを考えていてですね。
元の会社でプロダクトマネージャーとして、
チャレンジできる機械ってそうそうないし、
しかもバカみたいな失敗をした後だったので、
しばらくは難しいかなというふうに思っていたんですけど、
その時ちょうどAWSで機械学習領域のデベロッパリエーションのポジションというところがあるよというお声掛けをいただいて、
AWSって機械学習を使ったプロダクトがめちゃめちゃあって、
おそらく優秀な人が引いているに違いないというのは、
当然固くないというところで、
いわゆる世界でプロダクトを展開している企業というのが、
どういうふうにプロダクト作りをしているのかというところをやっぱり学んでみたかったし、
その学びというところが広まるというところがあれば、
AWSのプロダクトはもちろんなんですけど、
私のように苦しい人を救うこともあるかなというふうに思って今に至るというのがキャリアの転機というところで、
その2つが今につながっているかなというところですね。
新しい挑戦とストレス
ありがとうございます。
もうまさにスタートのところからAWSに入るところまですべて、
お答えいただきありがとうございます。
本当に今のお話を聞いていると、もちろん挫折とかもすごいされていたんだろうなというのは思う一方で、
すごいチャレンジをされていて、
かつ多分それこそTISさんの中でも評価はされていたんじゃないかなというのは何となく私は聞いていて感じていたんですけど、
そこから何て言うんですかね、
多分TISさんも今のお話だとキャリアとしても結構在籍されていた時間は長いんじゃないかなという気がしている中で、
そこで新しいところに行くところの怖さというか、そういうのはなかったですか。
それは怖かったですね。
そもそもTISに新卒で入ってから転職したことなんて1回もなかった。
ただ相談したんですよね、奥さんに相談をしてですね、
残るか、それともチャレンジしてみるかみたいな、
というふうに相談したときに、
なんかチャレンジすればいいんじゃないみたいな。
割とそういうときに第三者のカリア投資って意外と人生を決めるかなという、
ところがあって、
採用を受けてみて、
今いいだろうというところなので、
どちらかというと何だろう、
自分自身の強い意志でもって崖から飛び込んだというよりは、
自分として多分そのほうがいいとは思ってたけど踏み出せなかったというときに、
今少し背中を押してもらって今があるというような感じですね。
ありがとうございます。
実際いろいろ最初は恐怖というか悩みがある中で、
AWSさんに入って今またいろいろなことをされていると思うんですけど、
最初の頃って転職した直後ってどうでした?
スムーズに自分がやりたいことができていたのか、
いろいろ学びがあったのか活躍できたのか。
転職の直後はもうストレス半端ないですよね。
まずストレスの要因が三つあってですね、
一つはさっきお話ししたとおり、
プロダクトマネージャーとして失敗した後で入っていったので、
まず自分の能力に対しての信頼というのがない状態なんですよね。
その半端ない不安というところと、
あとちょうど子供が生まれるときだったので、
一級を取ったりとかプライベートの生活が変わる中で
状況に対処していかないといけないという話。
三つ目は機械学習域のデベロッパーリリーションって
前例がないというか初めてのポジションだったので、
誰も仕事のやり方を知らないわけなんですよね。
メンターでそのモバイル領域で先行で
デベロッパーリリーションを担当している方に
メンターについていただいたんですけど、
でも基本的には一人で全部戦略を立てて、
立てた戦略に沿って成果を出していかないという
プレッシャーがあるという中で、
プレッシャーはすごかったですね。
なるほど、でもそれでも何か辞めたいなとか
そういうのはあまり思わなかったんですか?
辞めたいなとは思わなかったですね。
この場で全力を尽くして、
そもそも自分が解き明かしたい、見つけたいという
感じていたものに取り組んでいくというところなので、
辞めたいという思いはなかったんですけど、
自分が全力で仮にこの職務を取り組んだとして
本当に成果が出るのかというところが
すごい疑心暗鬼だったというところはありますね。
その疑心暗鬼さとかプレッシャーとかって
また今は多分、もしかしたら今もあるかもしれないですけど
変わってきているんじゃないかなという前提の中で、
その不安みたいなものが払拭されていったりとか
ある意味ちょっと自信がついてきたタイミングとか
そういうのってどういうタイミングなんですかね?
多分デベロッパーリレーションを担当して
2年目ぐらいでようやく自信がついてきたなというところですね。
デベロッパーリレーションの1年目は
さっきお話しした先行でデベロッパーリレーション
モバイルの領域でデベロッパーリレーションを担当されていた
先輩がまさにメンターになってくれて
その方との出会いは私にとって非常に大きくて
本当にその仕事のやり方とか
あとは人との関わり合いとか
その1人っていうロールの中で
どういうふうに組織でインフルエンスを高めていくのかっていう
教えを本当に密に教えていただいて
途中で転職されて
大きなチャレンジをするために転職されたので
数ヶ月ぐらいの期間だったんですけど
その数ヶ月の期間は私の中で本当に貴重な話で
そこでまずは仕事のスタイルっていうところを身につけて
1年目は本当にがむしろって感じで取り組んで
一応その目標 KPI 達成っていうところだったんですけど
2年目はですね その方いないわけですね
信頼していたメンターが2年目にはもういないっていう
本当に2年目は自分で
ゼロから戦略を立てて
目標に対して達成できるかできないかっていう
本当にギリギリのチャレンジをしていくっていうところをやって
それが本当に達成できた
確かそのとき 115か120%ぐらいのアチューブメントだったんですけど
そのときに初めてようやく計画の立案から実行までっていうのが
本当にゼロからやってきたっていうところがあったんで
ようやく少し自分で走れるようになったかなっていう
実感ができたっていうところあります
目標設定と組織への貢献
ありがとうございます
最初はフィードバックだったりとか
いろいろもらいながらやれたところが
自分1人でできるようになったときに
自信がついてきたっていう
ちなみに私 さっきのめちゃめちゃ脱節したときから
1ヶ月に1回メンタリングみたいなことをやっていてですね
世にいくつか
出会えるメンタリングみたいなサービスがあると思うんですけど
それは結構存在が大きくて
月に1回会社とかの利害関係がない人にメンターしてもらう
今自分がどういう状況でどういう方向を目指したくて
次の月までにどういうことができているのかなみたいな
あんまりそこはKPIっていうよりは
パートナルな考え方とか目標みたいな
そういうところなんですけど
常にそういう客観的な意見とかメンタリングをもらえる
自分の状況 立ち位置っていうのを見直す機会が
月に1回あるっていうのは
すごい私の中では大きかったです
それは今でも続けてます
そうなんですね
それってどういう感じのフィードバックをもらえたりするんですか
フィードバックっていうよりは
むしろ問いかけの方が多いかなと思っていて
今のその状況ってご自身では
どういうふうに捉えてますかであるとか
もしもっと何か違う考え方があるとしたら
どういう考え方があると思いますかみたいな
そういう問いかけをしてもらうことで
自分の中の割と盛り固まっていた考えとか
あとは普通に会話してるだけでも
意外と自分でヒントが生まれてきて
こうすればよかったのかなみたいな
っていうところに気づきが減られるみたいな
っていうところは結構ありました
なるほど ありがとうございます
すごい順風満帆でずっと言ってきました
本当にお話聞いてると
本当に久保さん自身がいろんな
調整もしつつ失敗もしつつ
いろいろ学びつつトライしつつ
本当に今の活躍されているキャリア
築かれてるんだなっていうのは思ったんですけど
一個僕がちょっと聞いてみたいなと思ったのが
なんて言うんですかね
特にAWSさんの中でかもしれないんですけど
最初何がいわゆるデベロッパーリレーションとしての
バリューなのかみたいなのも
多分最初は定義されてない
自分自身もプレッシャーとか自信がないっていう中で
どうこれをやっていったら
このロールとして価値がある動きだとか
こういうところのKPは達成したら
絶対会社としては価値があるはずだっていうのを
どう組み立てていってたのかなってちょっと気になっていて
いわゆる目標設定とかに近いかもしれないんですけど
そうですね
そこはおっしゃる通りデベロッパーリレーションの中でも
一番難しいポイントで
よく年初でその目標を立てるんですけど
その時は上から目標が降ってくるほうが楽だなっていうのは
常で思ったりするところでもあるんですけど
デベロッパーリレーションの一番重要なポイントとしては
アウェアネスを広げるっていうところがあるんですけど
アウェアネスっていうのは何かっていうところは
自分で定義する必要があるというのが
一番難しいポイントでした
具体的にどういうKPや設定図っていうのかっていうのは
秘密っていうところもあるので
あんまり細かくはお伝えできないんですけど
どういうふうに設定してるのかっていうのは
常にこれはデータドリブンな考えでやっていて
いくつかアウェアネスとして測れる仕様
例えばプロダクトであれば
それの認知度
Googleトレンドとかそういう値であるとか
他にも聞いたの掲示数とかそういうことですね
とかそういったものがあるとか
あるいはアンケートの認知度とか
SNSでの投稿数とか
あと事例数とかですね
いろんなメトリック数がある中で
今AWSとして
弱みがあるポイントがどこなのかって
なんで弱みがあると言えるのかっていうところは
全部リズムとあとは
こういう根拠があるので
こういうふうに言えると思います
というふうな形で
私の場合はなるべく
8、90%ぐらいは合理で詰めて
あと10、20%ぐらいをパッションというか
そういう方向に行くべきだっていうような決め
これ完全に合理では決められないので
最終的にはどっか石入れが入る
っていうところなんですけど
そこを入れて
AWSのカルチャーと意思決定
最終的に目標数値っていうところを確定して
ただそれ自分で決めただけだと
ただの思い込みなので
その各種ステークオーダーですね
デベロッパーリリーション自体は
一人の職種しかいないんですけど
ソリューションアーキテクトとか
他の営業の方とか
そういう方の力を得て
目標を達成していくことになるので
それから
少なくとも10人から20人ぐらいから
フィードバックを得て
最終的に確定するっていうような感じです
なるほど
それだけフィードバックもらうんですね
そうですね
合理と最後パッションって
お話があったかなと思っていて
結構目標を決めたりとか
何かを判断するときに
最後のそのパッション
10%のパッションで
そこを決めきれない
自分の自信がないと思っている方って
結構いらっしゃる気がしてて
合理で全部ロジックとしてはこうなるけど
最終的な意思を
自分で載せるのに対して
やっぱ恐怖心があるとか
自信がないとか
そこをくもさんとして
パッション 意思
最終的に意思を載せるときに
表現が難しいんですけど
割り切ってるというか
そこの決めをどう出しているのか
みたいなところがちょっと気になっていて
そうですね
パッションを分解すると
まずAWSのカルチャーっていうところと
あとプロダクトっていうところと
あと自分の戦略っていう
3つぐらいがあって
AWSはリーダーシッププリンシパルっていう
そもそもカルチャーとか
またフライホイールって言われる
顧客満足を第一にして
拡大していくっていう
基本的なビジネスモデルっていうのがあって
まずそこに立脚してるかどうかっていうところが
一つ重要なポイントになると
あとAWSのプロダクトの性質ですね
AWSのプロダクトって
本当にB2Cというか
一般のユーザーの方が
1秒で使えるようなサービスかっていうと
そうじゃないじゃないですか
どちらかというと
本当にプロダクトを世に生んで
スケールしていきたいとか
その時のセキュリティとか
過眼屈則性とか
っていうところが担保されてるっていう強みなので
そういうプロダクトのバリュープロポジションっていうところと
その2つから
じゃあAWSのプロダクトっていうのが
レベルはその競合に対して
AWSを取って差別化していくっていうポジションなので
じゃあどういう風な
市場的なポジションっていうのがあるべきなのかっていうところの
個人的っていうか
職場としての考え
っていうところが
残りの20%のパッションの成分の中に
感じで
これは市場の状況とか
AWSのプロダクトの強さとか
そういったところによって
配分の比率っていうのは変わってくるんですけど
大まかそういったもので
最後決めてるっていうところなので
そういう意味だと
完全に自分の独断と偏見でいいやって決めてるかどうかっていうよりは
その会社が培ってきた
カルチャーとかプロダクト
っていうところから見て
どういう方向が正しいのかっていうのを
意思決定してるっていう形に近い
ありがとうございます
まさに自分自身がどう思うもちろんそうですけど
この会社の中での
何をやっていくべきなのかっていう
もう1個上の考え方というか
そこに対しての意思を持つみたいな
そんな感じのイメージってことですか
そうですね
AWSってやっぱり差別化して
初めて認識されるっていうところなので
差別化っていうのって
まずプロダクトとしての差別化っていうんですけど
会社としての差別化っていうのもあると思うんですよね
あの会社は歴史が長くて
例えば顧客に寄り添ったプロダクトを出してとか
あるいは新しい技術をどんどん取り込んでいくみたいな
そういう会社のスタイルっていうところがあると思うので
そういうところを加盟した上で
一番適切なポジションがどうなのかっていうのを
考えるっていうような方向を私は取ってます
キャリアの学びとチャレンジ
ありがとうございます
本当に結構やっぱりそういうところの
最終的に決めていくっていうところは
誰でも単力はいるところかなと思うんですけど
今日の鴨さんのお話は1個のヒントになるというか
僕もそういうのを考え方としては取り入れていきたいですし
メンバーにもそういう考え方をするといいよみたいなのは
僕 今 部長って形で海外統括でいろいろ見てたりはするので
ちょっとアドバイスしたいなっていうのは今 すごい思います
ご参考になります
ありがとうございます
久保さん 今日はありがとうございました
ありがとうございます
まだまだお話し足りないので 次回も久保さんとお送りします
ということで 今回は久保さんのキャリアについて
いろいろお伺いをしてきました
結構久保さんとしては挫折みたいなお話もあったかなと思うんですが
やっぱりチャレンジしているからこそ
いろいろな学びだったり失敗だったりっていうのをしてらっしゃるんだろうなと思っていて
そこでやっぱり終えるのではなくて
次のチャレンジにつなげていくってところが
本当にキャリアとしての学びになるというか
自分もそういうチャレンジっていうのはしっかりしていかないといけないなっていうのはすごい思いました
さて この番組では感想や次回ゲストへの質問 リクエストなどお待ちしております
番組詳細欄にあるリンクよりお気軽にご投稿ください
XではハッシュタグKiita FMを付けてポストしてください
表記は番組名と一緒でQFMが大文字 残りは小文字です
そしてApple PodcastやSpotifyのPodcastではレビューもできますので
こちらにも感想書いてもらえると嬉しいです
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと
エンジニアに関する知識を記録 共有するためのサービスKiita
社内向け情報共有サービスKiitaチームを運営しています
ぜひカタカナでKiitaと検索してチェックしてみてください
来週も火曜日の朝6時に最新話が更新されます
番組のフォローをして最新話もお聞きください
お相手はKiitaプロタクト開発部部長の清野俊文と
AWS深夜機械学習デベロッパーリレーションズの久保隆博でした
27:12

コメント

スクロール