ゲストの紹介とテーマ設定
日本最大級のエンジニアコミュニティQiita プロダクト開発部部長の清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、
キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続き、ゲストは、AWSジャパン 技術統括本部 シニア機械学習デベロッパーリレーションズで、
Qiitaアカウントネーム icoxfog417さんこと久保隆宏さんです。よろしくお願いします。
よろしくお願いします。
久保さんとお送りする2回目のテーマは、技術ドリブンvs顧客ドリブン 生成AI時代のプロダクト開発です。
2回目のテーマは、デベロッパーリレーションズというところもそうですし、
AIみたいなところについてお話を伺えたらなと思っております。
1回目から改めてにはなってしまうかもしれないんですが、現在のAWSさんでのお仕事についてお伺いしてもよろしいですか。
そうですね。私はAWSの機械学習領域のデベロッパーリレーションを担当してまして、
もちろんAWSのサービスというのを分かりやすく皆さんにお伝えするために、
ブログであるとかイベントの登壇をする、あるいはビジネスの方にどうして生成AIに取り組むべきなのかみたいなところをお伝えするというところもやっていて、
なるべく生成AIというのを皆さんの業務とか、あるいはプロダクトに活かしてもらうにはどうしたいのかというノウハウを伝えるという活動をしていると。
そこから得られてくるフィードバックというのがあるので、サービスチームのほうにしっかり伝えて、プロダクト自身の改善を図っていくというのが主なお仕事ですね。
ありがとうございます。まさに機械学習というところとデベロッパーリレーションというところをうまく、
機械学習というものをうまくデベロッパーリレーションというところでいろいろな人に伝えていくというところが仕事としてされているってことですね。
これももしかしたら改めてにはなってしまうかもしれないんですが、1回目のお話だと、いわゆる機械学習を始めたきっかけっていうところは、
DISさんの中で研究というところで始めたってお話あったと思うんですけど、そこを今キャリアとして、一個軸としてずっとやっているという中で、
いわゆる機械学習ないし、AIみたいなものの面白さみたいなところを、くぼさんがどう感じているのかみたいなところをお伝えしたいなと思っていて。
そうですね。機械学習AIの面白さは2つあるかなというふうに思っていて、1つは純粋にこれまでのシステムと挙動が全く違うっていうところがあると思っていて、
普通のソフトウェアってプログラミングしたとおりに動くって当たり前の話ですけど、機械学習っていうのはデータを入力してデータによってモデルを作って、
その結果モデルが推論をするというところで、大まかに見れば人間にはどういう挙動をするか予測がつかないっていうところがあって、
そこが普通のソフトウェア開発とは違った特色だし面白さかなというところですね。
もう一個はやはり進化が激しいっていうところですね。
どれだけキャッチアップしても抱えきれない情報というのが山のように出てくるというところもあるので、
私も論文結構ヘビーに読んでいた時はありますけど、何本読んでも論文読んでも全体像が理解できないっていうしかどんどん広がっていくという、
本当に技術の最先端にいるっていう、そういうところも一つエンジニアとして面白さを感じられるポイントかなというふうに思いますね。
ありがとうございます。まさにやっぱりAIの面白さってそういうところなんだろうなというのは、
僕も大学時代とかはちょっと勉強したりしてたので、そこら辺の面白さはすごい分かる一方で、
ここはちょっと気になるなというところで言うと、生成AIはもしかしたらまたちょっと違うかもしれないですけど、
いわゆる機械学習って当時ってすごい手法とかがいろいろ出てきてて、
それでいろいろこういうことができるようになったというのが出てきている一方で、
それを例えば世の中に活かすとか、それでビジネスに活かすというところが結構やっぱりいわゆるソフトウェアとは思いますね。
結構やっぱりいわゆるソフトウェアとはまた違った難しさもあるなと思っていて、
そこら辺のまさにTISの中では研究もされてたというのはある一方で、
最終的にそれをビジネスに活かすというところもスコープとして入ってたんじゃないかなと思っているので、
そこら辺の難しさってどうだったのかなというのをお伺いしたいなと思うんですけど、どうでした?
そうですね。機械学習をビジネスに活かすことの難しさというのはどちらかというと、
デベロッパーリエーションを担当してから感じることが多かったですね。
というのも、AWSのサービスって一般の人が普通に使ってサブスクリプションするという感じとは少し違って、
本格的にシステムを開発する方がどちらかというと使うというところがあるんですけど、
機械学習領域のデベロッパーリレーションとして皆さんにAWSのAI MLのサービスを使っていただくというふうに考えると、
AI MLっていうのがいわゆる本番業務とか本番のプロダクション環境で活かされる状況っていうのをどんどん作っていかないといけないという話になるんですね。
それに対して現実はどうだったかというと、機械学習のプロジェクトって約80%が失敗するというふうに言われているんですけど、
やはりPOCで止まったとかですね、やはり機体精度が出なかったとか、やはり本番で稼働してみたら、
そういうようなドリフトが起きたとかですね、本当にトラップが多くてですね、
知っている方は機械学習の隠れた芸術的スタイルという論文とかを読んだことがある方もいらっしゃるかもしれないですけど、
とにかく落とし穴が多いテクノロジーで、どういうふうにこの機械学習というところを組み入れたりとか、
ビジネス的にも技術的にも組み入れていくと本当に活かせている状態なのかというのは、
むしろAWSのデベロッパリエーションとして担当してからのほうが考える機会は多かったですね。
そうなんですね。やっぱり難しさというのは実際あるというところはある一方で、
そこに対して何ですかね、エンジニアとしての効力感というか、
ある意味でのちょっとした80%がうまくいかないという前提の中での虚しさみたいなのって感じたりしないですか。
虚しさはあんまり感じることはなかったですね。
もし私が機械学習エンジニアで、自宅とかプロダクトの開発をしていたら、
成功の定義と組織間の連携
また俺の作ったモデルが入らなかったで、すごい泥棒を感じるというところはあったと思うんですけど、
私はデベロッパリエーションの職で、どちらかというとプロダクトマネージャーの方とかにアプローチをして、
そもそもARMLっていうのがプロダクトにどういう風な価値を与えるのかっていうところを、
どういう風に考えていくのかみたいな、そういったようなワークショップであるとか、
あとは説明講演みたいなところをよくしていたので、
あんまり自分のモデルが無になったっていう経験がなかったからっていうのはあるかもしれないですね。
ありがとうございます。
ただ、私がそうしてプロダクトマネージャーの方とかにアプローチしたりとか、
機械学習を用いたプロダクトの開発をサポートするワークショップとかを開発して提供しているんですけど、
それが虚しさを感じるエンジニアたちを少しでも救えていたら、本当にそれは嬉しいなっていう風には思いますね。
ちょっとまた具体の話になっちゃうかもしれないんですけど、
AIを活用してうまくいくものと80%うまくいかないものっていうのがあるときに、
それを生んでしまう要因というか、何がうまくいってるとうまくいくのか、
何がうまくいってないから結局80%失敗してしまうのかみたいなところをもうちょっと改造であげたいなと思ってて、
そこら辺でどうなんですかね。
これは生成AI含めてっていう話ですけど、
まず成功の定義がはっきりしないっていうのが一番良くないパターンですね。
成功の定義っていうのはですね、実は人によって違うっていうところが少々あって、
例えば機械学習モデルを組み込もうとしている研究開発部門であれば、
モデルができたっていうのが成功なんですよ。
とはいえ、実際のプロダクトを作っている人は売り上げが伸びないと成功じゃないというところがあったりして、
そうした連携する部署間での成功の定義のクイッチっていうところが、
成功の指標の定義を難しく知ってるっていうところがまずあるかなという風に思います。
最終的なビジネスのアウトカムを成功にするっていう話になると、
やっぱり組織間で結構連携が必要というところがあるんですね。
やっぱりモデルを作ってるっていうところになると、
テクニカルなモデルの制度とかっていうところに話が行きがちなんですけど、
制度が100%でもこれ儲からなくないですかみたいな話が結構あったりしてですね、
機械学習のモデルの開発に慣れてる人、ビジネスをうまく考えられる人、
それをアプリケーションの体験として落とし込める人とか、
いろんな人が連携しないと成功にたどり着けないっていうのが、
たぶん機械学習、あるいは生成を使う上での根本的な難しさとしてあるかなっていう風には思います。
ありがとうございます。
今お話の中にあった成功っていうものをどう定義していくかってところと、
やっぱりロールによってそこの成功の意味が変わってくるみたいなお話を聞いてて、
まさにそうなんだろうなっていうのは思っていて、
それって機械学習もそうだと思うんですけど、
いわゆるリサーチ部門とプロダクト部門みたいなやつでよく発生するすれ違いに近いなって気がしてて、
その現象って、リサーチ側としてはいいモデルが作れたら成功だけど、
それが使えなかったらプロダクト側的にはそれは成功じゃないみたいな、
それ逆もしかりだと思うんですけど、
そこら辺の組織のコンテキストの変えりというか、そのギャップすれ違いみたいなものって、
まさにいろんな組織のところでワークショップをされていると思うので、
いろいろ見ているかなと思うんですが、
どうやってそこを歩み寄っていくといいのかとか、
どうそこを擦り合わせていくといいのかみたいなのって、
何か今までの経験の中での知見とかであったりしますか。
会社のカルチャーとかプロダクトが目指していく方向性とかっていうのが、
その紙に書いてある画面とかじゃなくて、
人とかプロセスの面で本当に徹底されているかどうかっていうのが、
やっぱり一つキーになっているかなっていうふうには思いますね。
モデルを作っているデータサイエンティストも、
誰に価値を届けるために今こういうモデルが必要で、
そのための精度が何パーセントぐらい必要なのかっていうところを理解しているし、
ビジネスサイドとしてもそのモデルを入ることによって、
どういうふうに差別化されて、
どういうふうに継続的に例えばデータを貯めて、
より顧客の体験を高めていくのかっていうロジックが、
そのモデルの精度が改善するっていうのと、
ビジネスの成長が行われるっていうのが、
ちゃんと比例関係にあるっていうところのロジックが頭に入っているかどうかっていうところが、
ベースとして共有している会社としてのミッションとか、
プロダクトとしての目指すところっていうのが、
全員共有されていて、
いろいろ専門知識は違うけど、
全員同じ方向を向いているかどうかっていうのが、
結構大きな決定要因かなっていうふうには感じますね。
ありがとうございます。
本当にそれこそ組織間での目標みたいなのもそうですけど、
よりコンセプチュアルというか、
結局自分たちが何を価値として提供したいんだっけとか、
それで何を実現したいんだっけみたいなところを、
もうちょっとすり合わせていったりすると、
そこを分解したKPIベースとか、
そうですね。
組織が大きくなると、
やっぱり部門ごとに独立した目標数値っていうのが決められて、
その目標数値っていうのが、
本当に会社が達成したいことのために連携しているんだっけっていうのが、
多分トラックするのがどんどん難しくなってくるっていう、
現象が発生しますねと。
生成AIの進展とプロダクトの課題
それをどういうふうにうまく連携させていくのかっていうのが、
マネジメントとしての難しさ。
そこができていると、
異なる部署間でも機械学習に関わらず連携して、
一つの目標を達成しやすい状況になるかなっていうふうには思いますね。
またちょっと違った視点の話で言うと、
ディープラーニングとかマシンラーニングみたいなのが結構盛り上がってた時代って、
よりそこが専門的な雰囲気とか、
実際専門性が必要な領域だったと思うんで、
そこに対してのある意味でそういう感じのとっつきにくさというか、
お互いの歩み寄りのところで若干すれ違い生まれやすいみたいなのがあったのかもしれないなと思ってるんですけど、
今ってやっぱり生成AIの登場によって、
そこが敷地ってめちゃくちゃ下がってる気がしてて、
いわゆるプロダクト、それこそプロダクトマネージャーが、
生成AIを使って何か作りたいで実際作れちゃうみたいな、
そういう時代になっている中での、
やっぱそこら辺の難しさとか、
でも先ほどのお話だとその一方で80%失敗するっていうのは、
生成AIも一緒ってお話あったと思うんで、
そこら辺の難しさの変化みたいなのは、
生成AIの登場によって変わってたりするんですかね。
ちなみに80%の失敗っていうのは、
旧来のいわゆるAIML時代に言われていたことで、
生成AIでは必ずしも当てはまらないかなというふうな理解ですと。
生成AIで変わったところは、
とにかくビジネスのアウトカムを計測するスピードが圧倒的に速くなったっていう、
ところが一つ挙げられると思います。
なぜかというとデータを準備する必要がないし、
モデルを作る必要もない、
機械学習のいわゆるMLopsっていうふうに呼ばれていたパイプラインの中のうちの、
データの準備、モデルの学習、そしてホスティングして推論っていううちの、
もう本当に大半がカットされた状態で、
機能だけ組み込めるっていう状態になったことで、
いわゆる機械学習的な機能、
しかも高精度っていうものを、
どんどん実験、リリースというのがしやすくなったっていうのが、
破壊的に変わったところかなっていうところですね。
それによって試行錯誤がしやすくなったので、
よりビジネス価値も出しやすくなったし、
連携も取りやすくなったのかなっていうところは、
大きく変わったところかなと思いますね。
基本的にそこの敷地が単純に下がったみたいな、
そんな感じのイメージですね。
技術ドリブンの考え方の変化
そうですね。敷地はもう本当に単純に下がりましたね。
逆にやっぱりそういう時代に入っている中で、
生成アイに取り組めていないっていうのは、
それ自体が何て言うんですかね、
何かに出遅れている可能性があるみたいなのもあるんですかね。
そこはそうだと思いますね。
生成アイ自身も、いわゆるインとアウトのチャット型っていうところから、
だんだんアウトする情報っていうのが、
システム理解可能なJSONとかの構造化データになって、
構造化データと連携できるよねっていうふうな形になって、
ツールユースが生まれて、
ツールユースができるっていうんだったら、
自律的に行動させることができるんじゃないかっていう形で、
モデルのリーズニング性能が上がったこともあって、
今エージェントっていうところは出てますけど、
一口に生成アイって言っても、
すごい応用の幅が長くなっていると思っていて、
今は生成アイで、生成アイってチャットっぽいやつだろうみたいな、
っていうところからすると、
この1,2年で本当に入り口から出口、
出口というか最先端までめちゃめちゃ距離が空いたなっていうところがあるので、
なるべく早く取り組みに越したことはないっていうのは、
一つ言えるところではあるかなと思います。
ありがとうございます。
もう大体、それこそ、
AWSさんのイベントとか行くと、
生成アイはプロダクションに組み込むのが当たり前じゃないですか。
それに近いニュアンスみたいなのを、
結構おっしゃってるところも多いなと思っていて、
僕もそれを聞きながらすごい焦っているんですけど。
実際、僕たちKiritaもいろいろ取り組んでいく中で、
ちょっと悩ましいなって思っているのが、
生成アイっていうものを活用したいって思って、
いろいろ試すっていうのはやっている一方で、
それっていわゆるエンジニアリングのアンチパターンとは言わないですけど、
プラクティスとしての技術ドリブン的な感じになってしまっている。
手段が先行していて、何を作るかが後になっているみたいな。
それって一昔前はあんまり良くないよねみたいな感じで、
何を作るかにフォーカスしようよみたいなのを、
結構そういう言説みたいなのが流行っている時期だったと思うんですけど、
逆にやっぱり生成アイって、逆にそれをどう活用していくかっていう、
ちょっとある意味での技術ドリブン的な考え方も必要になってきているなと思っていて、
結構僕自身はそこの考え方のシフトみたいなのが、
やっぱりすごい難しいなって思ったりするんですけど、
生成アイ時代での生成アイの活用みたいなところって、
どういう考え方でいろいろ向き合っていけばいいのかみたいなところを
もしアドバイスがあればお伺いしたいなと思ったんですけど。
これは結構難しいテーマだと思いますね。
AWSとかAmazon自身はワーキングバックワードっていって、
お客様の喜んでいる姿から逆算して物事を作っていく、
いわゆる顧客基点で物作りをするっていうのが徹底されているというところなんで、
そういう意味ではプロダクターと技術がこういうのができるから、
ちょっと出してみましたっていうところからは、
かなり遠いっていう考え方をしているっていうのは一つあるし、
それがAWS Amazonに限らず、
一つベストプラクティスとして徹底されてきたというところはあると思います。
ただおっしゃる通り、
生成アイの領域ってすごいテクノロジーの進歩が早くて、
こういうことができるようになりましたっていうふうな、
いわゆる技術ベースのアプローチっていうのも一定考慮に入れておかないと、
そもそもどういう価値が届けられるのかっていうと、
このチャンスを見逃してしまうんじゃないかっていうところは、
一つ大きい課題としてあるんじゃないかなというふうに思います。
なので今のポイントっていうのは、
エンジニアがもっとプロダクト作りに関わるっていうところが、
一つ大きいポイントなんじゃないかなというふうに思います。
こういうことができるようになりました、こんなことができますっていうのを、
どんどんプロダクトマネージャーとかビジネスの企画の人に、
恐れずインプットしていくっていうところの文化が必要だなというのは、
個人的には感じるところです。
なんか一分かし前だと、
こういうの作っていました、技術を使っていましたっていうと、
いやいや出たよそれ、エンジニアの悪い癖みたいな、クスクスみたいな。
そういう穿った見方をされてきたっていうのが、
ある意味不健全な雰囲気を生んでるかなっていうふうに感じていて、
エンジニアはエンジニアの立場からこういうものができたっていうのは、
積極的に伝えたほうがいいと思っていて、
そこに対して何かしら、
ある意味穿ったような見方をしているようなバイアスをかけるべきじゃないし、
今もっとお互いにコラボレーションする時期に来ている、
だなっていうのは、私は個人として感じるところありますね。
ありがとうございます。
じゃあこうある意味でやっぱりその、
技術取り分というか、
エンジニアの役割と今後の展望
やっぱそれをこうある意味で使ってみるっていうのが、
やっぱ今大事なフェーズでもありますし、
そもそも何かをやりたいなってなった時に、
ちゃんとその新しい技術とかが早期できる状態をちゃんと作っていく、
そのチャンスを見逃さないっていうのがすごい大事なのかなって、
お話聞いていて感じました。
そうですね。
今のエンジニアであれば、
もっと強気になっていいのかなっていうふうには思いますね。
今まで土地垢というと、
ビジネスの企画の人とかプロダクトマネージャーが
こんなことできないって聞かれたら、
答えるみたいな感じだと思うんですけど、
今だったらもっとエンジニアから、
なんで正々堂々もっと積極的に使わないんだと、
ここまでできるんだと、
なんでだよ、もっと使えるとこないのかっていうふうに
詰めるような感じで、
もっと現わってディスカッションするっていうシーンが
どんどん生まれてもいいんじゃないかなっていうふうに思いますね。
ビジネスの企画がもうなんか、
いやなんかエンジニアが技術ドリブンで
なんか言ってるよとかってんじゃなくて、
やっぱさっきの、
お互いに目指すところは一緒なわけですから、
同じプロダクトで目指す仲間として、
そういうインプットっていうのを本当に
真摯に受け止めるっていう、
そういうコミュニケーションが取れる企業っていうのが
今後伸びるんじゃないかなっていうふうには思いますね。
ありがとうございます。
やっぱりまさにちょっと前までは
エンジニアとプロダクトマネージャーの
コミュニケーションが
まさにやっぱりちょっと前までは
ソフトウェアって根本的な
発揮できるバリューって
そんなに変わらなかった時代っていうのは
やっぱりあると思っていて、
やっぱ今ってそこからこう、
ある意味でパラダイムシフトが
すごい起こり続けてる。
連続的に起こり続けてるのが今みたいな感じだと思うので、
やっぱそこら辺のスタンスとか考え方っていうのは
ちょっと今はあえて変えてみるみたいな
やっぱ大事なフェーズなんだろうな
っていうのは今お話聞いていてすごい感じました。
AWS、Amazon含めて
いわゆるリターントオフィス
現地に回帰するような会社
っていうところがいくつか出てきている
っていうところがあると思うんですけど
そこと生成へのこの技術進化は
無関係ではないかなっていうふうに
考えていて
やっぱりその対面でガッチガチで
どういうふうにすれば
こういうふうにしたほうがいいんじゃないかとか
っていうふうに議論するっていうのがやっぱり
まだまだリモートに比べて
創造性をハズルする場として
適切っていうところがあるというふうに考えていて
だからそういう場とか
コミュニケーションの仕方っていうところも
一つのオプションとして考えていく
っていうところが重要になってきているのかな
というふうには思いますね。
ここまでで機械学習ってものの
面白さ難しさってところから
生成AI時代のまたいろいろな
エンジニアとしての在り方みたいなところは
覚えてきたかなと思うんですけど
逆にその生成AIが
登場してきた中での
エンジニアとしての
バリューの発揮の仕方みたいなのも
もちろん変わってきてるなと思っていて
ものづくりっていうのももちろんそうなんですけど
エンジニアとしての仕事の仕方というか
アウトプットの仕方みたいな
いろいろな仕方が変わってきてるなって
フェーズに入ってきてる気がするんですけど
エンジニアとして
生成AIに対して
どう向き合っていくといいかっていう
またちょっとさっきの話とはちょっと違う観点で
お伺いできたらなと思ってるんですけど
例えば最近って
コーディングエージェントみたいなの出てきて
エンジニアの役割の変化
エンジニア不要なんじゃないかみたいな
言説が流行りだしてたりもするじゃないですか
その中でのエンジニアとしての
結局じゃあどういうバリューを
発揮していくべきなのみたいなところは
もしコウホーさんも何かあればお伺いしたいな
と思ったんですけどどうですか
これはもう私自身もめちゃめちゃ
悩んでるところ
なので
自分としてこうあるべしみたいな答えっていうのは
まず持ってないっていうのが前提になります
特に私は
機械学習の研究者で
あったので
もう機械学習は
TensorflowとかPyTorchなしで
誰もほぼあんまり聞かない
状態になってきて
モデルはもう基盤モデルがあることが
ほぼ前提っていう状態になっていて
じゃあ俺たちが磨いてきた
このMLopsとか
データパイプラインを構築してとか
モデルの継続的なアップデート
っていうのは
いわゆるもう失われた技術になるのか
みたいな
そういうような破壊的な変化っていうのは
自分の格好だと触れてるし
今おっしゃってる
私も普通に先生へのコーディングは使いますけど
自分の格好というのは
もう2,3割あれば
いいほうみたいな
そういうような状況になりつつある中で
俺の役割は一体みたいな
っていう風な
感じることっていうのは実際にありますと
楽観的というか
じゃあビジネスを企画するとか
プロダクトを企画するが今あればいいんでしょう
なんていう
気軽な声が聞こえたりもするんですけど
これだけプロダクトが
世に溢れていて
しかもエンドユーザーが自らアプリケーションを
作ることもおそらく
簡単にできるようになるっていう中で
いわゆる大プロダクト
飽和時代
大アプリケーション飽和時代っていうのが訪れる中で
あなたは当格を表せるんですか
企画者としてねっていう風な話になると
それはそれで生きていくのつらくないですか
っていう話になる
というのがある中で
どういう風に
私はもう今40過ぎっていうところですけど
まだ20年以上キャリアがあるし
若い方にとってはまだ
30年40年っていうキャリアがある中で
どういう風に自分のキャリアをデザインしていけば
いいのかっていうのは
本当に難しいトピックだなっていう風に思いますね
その中で今
意識して動いていることとかってあったりしますか
私が意識して
動いているのは
いかにプロダクトチームを作るかっていう
ことですね
そういうバリエーションとしてのミッションとしても
かかるんですけど
やっぱりいいプロダクトが
数人でいいプロダクトを
作ることができて
その数人で作ったプロダクトっていうのが
本当に大きなビジネスインパクトを生むと
あとはアベネスを生むという
時代が来ているかなと思います
県庁の例はカーソルとか
十数人とかで
ドル100Mの
ARRを達成するとかっていう
話があったんですけど
AWS自体もEC2とかS3が
始まった時って
十数人くらいのチーム
人数しかいなかったっていうところもあるので
いかにその
AWSアマゾンとかでは2ピザチームって
2枚のピザが食べられるくらいの
チームでやろうっていう話があるんですけど
そこからイノビティブな
革新的なですねプロダクトを
作れるチームっていうのをどんどんどんどん作って
いろんなプロダクトっていうのを
世に出していくことができるのか
その時チームを蘇生するために
どんな要素が必要なのかっていう
チーミングを極めるっていう
ところは一つ
意識して経験と実践を
積んでるとこですね
ありがとうございます
本当に
今エンジニアが
非常じゃなくなるんじゃないかみたいな
雰囲気もある中で逆に言うと
今エンジニアとして一人で出せる
バリューみたいなのも逆に
エンパワーメントされてるみたいなところも
側面としてあると思うので
本当にどう系統できるかというか
自分のバリューをどう増やせるか
みたいなところで
生存戦略は組んでいかないといけないんだろうな
っていうのを今お話聞いていて
改めて感じました
昔タイピストっていう
職業があったじゃないですか
今はもうない
その単語を使わないっていう状態になってる
と思うんですけど
多分エンジニアとはまた違う
新しい触手の名前が
必要になる時代が来るんじゃないかなと
いうふうに思います
なのでエンジニアっていう
カタカナの5文字ぐらいの
触手にとらわれるんじゃなくて
プロダクトチームの構築
どういう生き方とか
どういうキャリアで
ある意味で生きたいのかっていう話と
そこにもし名前を付けるとしたら
どんな名前がいいんだろうっていう
そういう考え方をしていた方が
今はいいのかなっていう気がします
久保さん
今日はありがとうございました
まだまだですねお話ししたりないので
久保さんとお送りします
ということで
久保さんとこれまでの
AIっていうところの面白さ難しさ
っていうところもそうですし
これからのエンジニアのあり方みたいなところまで
幅広くいろいろなお話をしてきました
やっぱり
そうですね
AIっていうものは日々進化してますし
その中でそれを
プロダクトに生かすっていうところの難しさもあれば
自分たちの仕事が
失われるんじゃないかっていう不安みたいな
いろいろある一方で
逆にそれを使ってできることっていうのも
確実に増えてはいると思うので
今
いいほうにどう使っていくのかっていう
もうちょっとポジティブな気持ちを持ちながら
生成アイテムに対しては
いろいろ向き合っていけるといいなっていうのは
無事に改めて気づかされました
ありがとうございました
さてこの番組では感想や
次回ゲストへの質問 リクエストなどをお待ちしております
番組詳細欄にあるリンクより
お気軽にご投稿ください
次回GitHub Xではハッシュタグ
Kiita FMを付けてポストしてください
表記は番組名と一緒でQFMが大文字
残りは小文字です
そしてApple PodcastやSpotifyのPodcastでは
レビューもできますので
こちらにも感想書いてもらえると嬉しいです
Kiita株式会社は
エンジニアを最高に幸せにするという
ミッションの下 エンジニアに関する
知識を記録 共有するためのサービス
Kiita 社内向け情報共有サービス
Kiitaチームを運営しています
ぜひカタカナでKiitaと検索して
チェックしてみてください
来週も火曜日の朝6時に最新話が更新されます
番組のフォローをして
最新話もお聞きください
お会いではKiitaプロダクタ開発部
部長の喜山俊嵩と
AWS 深夜機械学習デベロッパーリレーションズの
久保隆博でした
