00:01
こんにちは、エンジニアの三田です。
こんにちは、エンジニアの博崎です。
ゆるテクは、三田と博崎が緩く技術の話をするポッドキャストです。よろしくお願いします。
よろしくお願いします。
はい、というわけで、今日の収録をやっていこうかなと思います。
やっていきましょう。
はい。ちなみに、いつも2人で収録前にアイスブレイクとか言いながら、いろいろ近況報告とかしてたりするんですけど、
今日あれでしたよね、Eclipseのバージョンなんだっけな、みたいな話してましたけど、
使う言語によってだいぶIDEとかって変わってくるなって思ってて、
Eclipseとか数年単位で使ってないなって思うと、本当使わないものって追わなくなりますよね。
そうですね。でも三田さん、Java書いてた時期長いですよね。
長いです、長いです。
その時はID何使ってたんですか。
私その時IntelliJ使ってたんですよ。
IntelliJか、はいはい。
たぶんその時にEclipseからIntelliJに乗り換えたんですけど、
たぶん6、7年前ぐらいなんで、
おそらくその時Eclipseと比べてIntelliJの方が起動が早かったり、
っていうのがあって乗り換えた気がしますね。
なるほどな、そういうことか。
という話をしてたりするんですが、
もしおすすめのIDEはこういうのだぜとかがあったら、
コメント寄せていただけると使ってみようかなと思うのでよろしくお願いします。
戦争が起きるやつだな。
戦争が起こるかもしれないけど。
今日のホストは私なのでちょっとネタを用意して持ってきました。
AI技術の進化と生成AIの応用
今日は読書ネタです。
全然さっき話したアイスブレイク関係ないんですけど、
生成AI時代を勝ち抜く事業組織の作り方っていう書籍が発売されてて、
それを読んだのでまたこういうこと書いてあったよ、
どう思うみたいな話を博多家さんとできるとめっちゃ嬉しいなって思ってます。
当初は3日ぐらいで読むつもりだったのがすごく時間かかったっていうのもありますけど。
そんなもんです。
書籍の中身全部話してたら多分すごく時間長くなっちゃうんで、
全体的な概要はざっくり共有させてもらうと、
しょうたてとして前半の方で、
昨今の生成AIってどんどんこういう領域に実力伸ばしてきたよねっていう紹介がされてて、
その途中でとりあえず生成AI使えばいいじゃんっていうプロダクト作りって受けないよね。
じゃあ生成AIの強みって何だろうっていうのを分析してくださってる。
その先で生成AI使ってプロダクト作るときに、
よくある4省言がどうこうとかいろんな書籍であるじゃないですか。
ああいう4省言の紹介をしてくださってて、それが多分前半。
後半になると今度は生成AI使ったプロダクトじゃなくて、
生成AI使ってどうやって現場のエンジニアたちが、
エンジニアに限った話じゃないと思うんですけれども、
組織が生産性を上げていくかっていう話。
大きくわけで2本立てだったのかなっていう印象です。
じゃあ前半でそもそも生成AI時代何ぞやの説明があって、
後半で応用っていう入りやすい構成というか。
そうですね。
そういう感じにしてあるんだ。
なので今日は前半の生成AI何ぞやって話をすると、
プロンプトのテクニックと生産性向上
我々多分2人ともそんなに授業がとかプロダクトがあって、
話しても3分ぐらいでネタがつけちゃいそうなので。
無理ってなっちゃいますね。
無理ってなっちゃうんで。
ちなみに生成AIってここで言ってるのは、
まあまあ主にチャットGPTのことを結構指してたりするんですか?
だけではなかったです。
もちろんチャットGPTとかも出てきてたんですけど、
結構世の中で今流行ってるっていう表現が正しいかわからないですけど、
生成AI使った製品とかの紹介もたくさんされてましたね。
結構広いんだ。
確かに今目次を見てるんですけど、
各カテゴリーにおける生成AIの実力っていうところに、
テキスト生成、画像生成、コード生成、ビデオ生成、音楽再生とかあるから、
確かにそうなんですね。
結構具体的なプロダクト名とか紹介してくれてるので、
あんまり普段そういうツールというかサービスに触れない自分でも、
こういうのあるんだったらちょっと触ってみようかなとは思えた感じでしたね。
そんな感じなんだな。
という前半があったんですけど、
今日主に2人で話したいなと思ったのが、
後半のそういう生成AI使って、
どうやって私たちの生産性上げていこうかね、
みたいなところの話ができると嬉しいなって思いました。
話せるかな。
話せるかなってなりますよね。
とはいえ本の内容に沿って話すっていうよりは、
我々が特にエンジニアが身近で使ってそうなものを偏見で話をすると、
多分ここ数年で我々がコードの開発であったりとか、
調べ物をするときによく使われるサービスって、
先ほど少し名前も挙がったChatGPTであったりとか、
あとGitHub Copilotとかを結構ここ1,2年とかですかね、
使う人って増えてきたんじゃないかなって思ってて、
なんかその辺って博多家さん普段使ってたりします?
そうですね、使いこなしてる人ほどは全然使ってないですけど、
ないと厳しい程度には使ってるかもしれないですね。
そうなんですね。
もう割と結構、
例えば分からないところとか書き方とかあったら、
とりあえず検索するより先にChatGPTに効くようになったかもしれないですね。
だいぶそういったところで、
たぶん我々が昔で言うググラビリティ的なやつの体験は変わったって感じなんですかね。
変わりましたね。
なるほど。
今の質問をした意図として、
今回の書籍の中に、
AIによる回答改善と便利さ
私はどう使ってるかみたいな紹介もされてて、
平たく言うと、
生成AI使って生産性爆上げするためにはどうすればいいかっていう問いに対して、
プロンプトのテクニックを鍛えればいけるよっていうような話がされてました。
そうなんだ。
あれ、それでいいんだ。
主にChatGPTとかそういうのを使う時の話だと思うんですけど。
確かにそういうの出てきた時に、
プロンプトエンジニアリングとかっていう資料とかスライドとかも一時期よく読んでたなって思ってて、
突き詰めると結局そこのテクニックがあれば使いこなせるんだねっていうのは、
そうなんだっていうのは私も同じ感想でした。
割と直近の話なのかな。
そういう話が出てくる時って、
自分がたまに見る言説とかだと、
将来的には結局プロンプトのエンジニアリングなんてものはあまり必要なくなるみたいな、
ちゃんと向こうがEを汲み取ってくれたりとかするからみたいな。
そこの話は確か出てなかったかもしれない。
あんまりプロンプトエンジニアリングを頑張ることは本質ではないみたいな、
話が多い気はしてたんですけど、
とりあえずそんなことはまずないんですね。
この本だとまずないと思ってます。
もしかするとプロンプトエンジニアリングってほど大それたものじゃなくて、
AIに対するインプットの仕方をとにかく工夫しろっていうぐらいの感覚で言ってるのかもしれないですね。
確かによく言いますもんね。
ガーベージインガーベージアウトか。
ゴミを入れたらゴミしか出てこないみたいな。
それはデータの話か。ちょっと違ったかも。
でも近しいものはあるのかなと思ってて、
それを読んでみて早速最近自分が使い始めたのが、
前もたまに使ってたりするんですけど、
この著者の方のチャットGPTの使い方がちょこちょこ紹介されてて、
それ見るとめちゃめちゃフォーマット作られてるんですよ。
ちゃんとこれを言う、これを言うみたいなのがテンプレート化されてるんですかね。
テンプレート化されてる。
全部参考にして、今度から自分もそれやろうっていうのは
フォーマットデカすぎてまだ頑張れてないんですけど。
そんなに多いんだ。
とりあえず最近真似してるのが、
これ博多家さんとかももしかしたらやられてるかもなんですけど、
AIに問いかけるときに前提条件を与えますと。
前提条件というか役割か。
例えばあなたはAWSのスペシャリストですみたいな。
役割を与えてからちゃんと質問しましょうっていうのを書かれてて、
それはちょこちょこやったことあるから別にそっかって感じだったんですけど、
今一番いいなって思ってるのは、
自分の回答に対してN回改善を図りましょうみたいな。
なるほど。
そうすると1回目の回答が出て、
AIが勝手にそれをまたインプットして2回目の回答にしてみたいな。
N回繰り返すんで最終的な回答の精度が上がっていきますよっていう話が紹介されてて、
それ実際やってみるとめちゃめちゃ便利ですね。
それって2回目の回答を出してもらうときに、
いわゆる1回目の回答に対してのフィードバックを与えてからなんですか?
自分でも全部勝手に、
多分ここが良くないだろうっていうのを改善点上げてきて2回目の記事を出してくれます。
そういう感じなんだ。
1回問いを投げると、例えば5回繰り返してねって言えば、
5パターン回答が返ってくるというか、一度に。
そういうやり方があるな、ちょっと今想像できてないですけど。
ですです。
なので結構最近私もあんまり触ったことない技術を調べてたりするんですけど、
それ繰り返すと角度高くなってるなっていう印象がありました。
なるほど。
教師あり学習みたいな正解がこれですっていうフィードバックを与えなくても
精度良くなっていくっていうのはどういう理屈なんでしょうね。分かんないけど。
ごめんなさい、それでいうと1個ちょっと抜いちゃったところありますね。
そのフォーマットの中に一応良い例と悪い例も入れてます。
こういう回答が良い例だよ、例えば具体的であるとか、抽象的じゃないとかっていう良い例の回答と
悪い例の項目を書いてAIに投げてるんで、
多分それを元に自分の中で学習してるんじゃないかなっていう予想。
それを勝手に何回かやってくれるんだ。
すごい便利そうですね。
便利そう。なので何なら文章を作ってもらう時とかその方法でやるとだいぶ助かるかもしれないですよね。
確かに文章とかあからさまに人間がやる時も遂行っていうプロセスがあるわけだから。
です。
っていうのが結構具体的な使い方で紹介されてたので、これは早速自分でも使えるんだなっていうのがあったんですけど、
はくたけさん先ほどチャットGPTとかないとちょっと大変かもってお話あったんですけど、
実際結構調べてて正解が出てるというか、それとも出てきたものに対してある程度自分がもう一回考えないとなかなか正解にたどり着けない感じなのかというと、
今ってどっちの感じが多かったりするんですか。
自分がまず主に使っているのがプログラミングのコードを書いてもらうっていうことと、
あともう一個が文章ですよね。日本語の文章を書いてもらうんですけど、ちょっと固い文章というかみたいな感じなんですよね。
その2パターンあって、どっちもいわゆる叩きを作ってもらうことが多いですかね。
なるほど。
そうですね。細かい使い方だったら、プログラミングだったら変数名とかもあったりするんですかね。
ありますね。
主な使い方は叩きを作ってもらうですかね。
なるほど。結構私も同じような感じで使ってるんで、周りの人ってうまく活用してる人ってどういうふうな使い方してるのかなって思って聞いてみたいですよね。
聞いてみたいですね。文章とかだったら、自分が書いたやつを遂行してもらうってやってほしいんですけど、
あんまり遂行してもらった時に、自分の感覚で良くなった文章が返ってきた経験があんまりなくて、そこを削られると辛いなとか、そういうことが多いんで使わなくなっちゃったんですけど、うまい使い方あるのかな。
だからそれこそあれですよね。今聞いてて思ったんですけど、多分その遂行するのところっておそらく博多家さんが思う良いポイントと悪いポイントというかがきっとあるんですよね。
はいはい。
なのでそれをもしかしたら条件に与えた上でこれ遂行してってやると、もうちょっとその博多家さんが好きなタイプの最終成果物が出てくるかもしれないですよね。
確かにな。やっぱそういうメタデータっていうか、それもコンテキストの一つなのかな。そういうの当てないとダメなんですね。
今は多分そうですよね。
ちょっとちゃんとやろう。あんまりそういうのをちゃんとやろうとしてないからかもしれない。
私も割といつも雑に聞いちゃってたんで、こういうことしたいんだけどどうすればいいのぐらいのすごい雑な。
そうですそうです。ちゃんとは前提条件を与えてあげないといけないですね。
ですです。っていう話がちょっとあって、これは身近に使える参考だなってなりましたと。
いいですね。
もう一つちょっと気になったところはありまして、前半の終わりか後半の始まりぐらいのところで、
必要とされる中核能力がこれから変わっていくだろうみたいな表現があったんですよ。
それは使う側の人間にですか?
使う側の人間というよりは多分我々が社会の中で自分たちの評価であったり存在意義を見出すための中核能力。
その中で本で出てた例って、例えば大昔とか狩りをしてた時代とかで言うときっとフィジカルが強い人が偉いというかいいじゃないですか。
なぜならば狩りをするときに動物に追いつけるから勝てるからっていう。
狩猟民族が狩猟の生活をしてたわけですね。
狩猟スキルが高いっていう話で、それが現代になっていくと徐々に理性であったりとか知能がある人の方が成功しやすいというか評価されてるって流れになってきたときに、
AIが出てくることによってその知能の部分ってちょっと変わってくるよね、個人の能力のところちょっと変わってくるよねって話が出てました。
その外部化できるというか。
そう、外部化できるみたいな感覚ですね。
例えば、AIの話ではないですけど、多分デジタルなものができたことによって、
例えば我々人間で言うと記憶するっていう力をそのデジタルな部分に移情できたりするじゃないですか。
そうですね。
っていうのが今度考える力っていう部分も、実はそのAIの部分に徐々に移情というか活用させられるはずだから、
シンプルに1個体として考える力超強いっていう人より、いかにAIと接続してAIを活用できるかの方が今後実は大事になってくるんじゃないかっていう話が出てて、
そうなのかって思うとともに、
じゃあそうなってくると、わりと私のイメージってエンジニアってそうやって考えるところが得意な人たちが多いのかなと思ってたんですけど、
そうなった将来のエンジニアって何していくんだろうなっていうのをすごい考えさせられました。
確かにな。でも、さっき話した内容にちょっと近いって思ったんですけど、
前提条件を整えたり、必要な前提条件を与えるというか、
その辺はまだ人間にしかできないとしたらやっぱそのスキルは大事というか、そこがエンジニアにも求められるのかもしれないですね。
確かにそうですね。そこの組み立て方じゃないですけど、といったところですよね。
そうですね。これはこういう、例えば仕事があり、こういうことをしなければいけないから前提条件として、
これがありみたいな入力をちゃんと考えてあげないと、良い答えが入ってこないから。
確かに確かに。
っていうのはエンジニアに必要なのと、あとありきたりですけど、現実社会と直接は多分まだAIも接続できないから、
そこはまだ時間が排結するのかもしれないですけど、そこは必要かもしれないですね。
現実世界にちゃんと影響を及ぼせる人間としての仕事は。
確かにそうですね。
そこかな。難しいな、エンジニアか。
漠然と今の本を読んだ時にも考えてたんですけど、今時点かは分からないんですけど、
なんとなくエンジニアってプログラミングしてる人たちとか、インフラ触ってる人たちとか、
特にITエンジニアとかそういうイメージなのかなって思うんですけど、
そういったところが今後、割とAIに置き換えられる可能性が出てくるってなった場合に、
我々は物事を見て問題の本質を見分けるスペシャリストにならなきゃいけないのかなと思ってて、
全然問題の本質じゃないことをエンジニアリングで解決したところで、
大した成果とかって見込めないじゃないですか。
そうですね。
なので、よりそこに対して嗅覚が鋭くならないと将来的にエンジニアとして実はうまくやっていけないんじゃないかなとかっていうのは考えちゃいました。
本質、本質難しいですね。
自分の感覚だともはや本質を解く能力とかの方もAIの方が高いんじゃないかっていう。
気がしていて、ある程度の情報とかそういったコンテキストが揃っていれば、問題を解く精度も速さもAIの方が人間より良い、吉那にできるっていうイメージがあるんで。
なるほど。そこすら。
そこを考えると、エンジニア本当に何するんだろうなって感じはありますね。
そうですよね。同じエンジニアっていう表現でもやること全然違ってるかもしれないし、とはいえ将来のことなんて分かんないですけど。
そうですね。エンジニアは人間のご機嫌を取るのが人間の仕事になるかもしれない。
いや、やだ。なんか機嫌なんて自分で取ってほしい。
それ、もうあれじゃないですか。それだけで1エピソード取れるやつじゃないですか。
ね、ほんと。
っていうところもちょっと考えさせられる文章だったな、章だったなっていうところがありました。
これ、もうみんな考えてるでしょうね。仕事が奪われるっていうか。
たぶん奪われた代わりにまたそれを使った新しい仕事は出るんでしょうから、
この仕事がすごい好きだっていう人は悲しい思いになるかもしれないけど、いやいややってる人からすると、
じゃあ好きなことやれるってなるかもしれないし、見方によるなと思いますよね。
そうですね、なんかあれですよね。今までの歴史がそうなってるっていう話は見ますよね、よくね。
ですです。
確かにな、その伝統工芸みたいなやつは残るけど、
その、産業革命か、みたいなのが来て大量生産ができるようになって、
手作業みたいなのがなくなって喜ぶ人はいたかもしれないけど、それが好きだった人はまあ。
まあまあまあ。
って感じですよね。
ですです。とかを考えると、すごく歴史って繰り返されてるんだなって思いますよね。
そうですね、新しい仕事が。仕事が見つからなくても、食っていけるんだったら、仕事はどんどん奪ってくれていいんですけど。
確かにね。
なるほど、なるほど。はい、ちょっとそういう話もあってっていうところで。
何だろう、事業作りとか組織作りにすごく関心があるとか、興味がある人はきっと前半とかちゃんと読んでみると面白いなと思ってて。
私も最初はそっちに興味があって読んで、でも話すにはまだ理解が進んでないなって思って今回諦めたんですけど。
あとは最後に一個だけ、これ全然AIと関係ない話になっちゃうんですけど。
組織作りのステップと準備
この書籍の中で最後に紹介してたのが、要はタイトルが事業組織の作り方じゃないですか。
なので、その生成AIネイティブにするための組織作りっていうのが最後の章で紹介されてて。
面白そう。
で、別に生成AIネイティブにする組織作りが面白いっていうよりは、この考え方って全体的にいろんな場面で応用できる、活用できるんだろうなって思ったのがあったんで紹介させてもらうと。
社内に何かを導入するっていう風になった時に、331のステップでやるといいですっていうのが書かれてました。
どういうやつですか。面白そう。
最初はまず意識の共有と準備をするフェーズですと。
意識の共有と準備。
それは何をやる必要があるかっていうと、まず上位レイヤーがそこに対してコミットメントする。
で、その人たちが多分ビジョンを決める。
で、それを多分導入するためのコアチームを作るっていうのが最初の準備フェーズみたいです。
なるほど、トップがまず本気ということを示し。
ですです。
ちゃんとチームを作って準備をまずしなさいと。
ですですです。
それが最初の3。
実行と拡大のフェーズ
で、次の3が実行と拡大のフェーズ。
実行と拡大。
まず最初に、そのさっきの準備フェーズで決まったことを、どっか特定の業務とか特定のチームに対して実践する。
で、その次に多分それができるようにメンバーを育成する。
で、それをさらに事業に生かすっていうことらしいです。
なんかここは納得というか、はいはいという感じしますね。
よくあるあれですよね、じゃあこれからうちの会社これやるからみんなやってねーじゃなくて、まずここに入れてみましょう。
で、そこに対して多分フィードバックサイクル回しまくって動向するって話をしてるんだと思ってて。
で、なんか最後の1がそれを全体浸透させる完全移行のフェーズってことらしいです。
これ1なの?
えっと、勘違いしてるかもしれないですけど、331っていうのはこれはなんだろう、その時間とかボリューム的なことですか?
というよりは、なんかやる項目を箇条書きで紹介されてて。
あ、なるほど、3項目やることがあるって。
そういうことです。
なんか完全移行フェーズが一番難しそうだけどな、1個しかないんだ、割合として1しかないんだと思ったんですけど、項目の数か。
そうですそうです。
で、これ読んでてすごい思ったのは、この書籍のテーマ上、生成AIを入れる順番というか方法という紹介をされてますけど、
多分何かしら社内で新しい考え方であったりとか、社内というか組織に新しい考え方であったりとか仕組みとかを入れるときって、
大体こういうこと使えるだろうなってすごい思いました。
そうですね、余談というか話中ちょっとあれなんですけど、最近読んだのが本にGitLabのリモート組織の何たらみたいな本があるんですけど、
あれも大体似たようなこと書いてありましたね。
そうなんですね。
GitLabは上位レイヤーが本気になって本気ということを示しているみたいな。
このコアチームを作るはなかったかもしれないけど、何となくこのフェーズとかもリモートワークを進めてきた流れみたいなところに通ずるものがあるなと思いましたね。
いいですね。今、博多家さんのお話であったリモートワークとかっていうところも確かに上位レイヤーのコミットメントという話だと思うんですけど、
すごく個人的に染みたのが、これって例えば組織で、うちの組織もSRE始めますとかってなったときも同じなんだろうなって思ったんですよ。
なるほどね。
きっと上位レイヤーがじゃあ俺たち本気でこのSREっていう考え方というか役割が必要だと思ってんだって、それがいるとこうなるんだってビジョン決めて、
それでSREチームっていうコアチームが作られみたいな感じなんだろうなって思ってて、
きっとその次ってそういうチームがどっかの改善対象のチーム決めてそこに入り込んでまず一緒にやってとかがいいんじゃないのかなって思ったりしました。
そうですね。全体に影響があるやつとか、そういうもの大体この進め方が必要そうですね。
そんな感じがして、なので結構今後何かこう新しいことを始めようって思ったときに、これをちゃんと思い返そうかなって思えた話だったんで、最後に紹介しておきます。
なるほど。最初に上位レイヤーのコミットが必要、それが一番難しいんだよって感じしますね。
難しいですよね。多分そのコミットメントする気持ちで伝えてても意外と伝わらないパターンもあるじゃないですか。
そうですね。
そもそもコミットメントしようとしてないもあるし、いろんなケースがあるから、項目として書き出すと簡単に見えるけど、いざやってみるというのは難しいですよね。
そうですね。ここでいう意識の共有と準備フェーズのところのビジョンを決める。
このビジョンを決めるのビジョンは、いわゆるミッションビジョンバリューとかのMDVDですか?
上位レイヤーのコミットメントとビジョンの決定
厳密にそれとは書いてないですけど、私はそれに近いものだと思っている。
あれとかだとね。でもあれは会社であるやつだから、あれに沿えばいいのかな。なかなかこれを決めるのはすごく難しいことだろうなと思うんで。
難しいですよね。きっと。それを考えると、やっぱり組織にそういうものを新党導入するっていうのは簡単なことじゃないっていうのがよくわかりますよね。
そうです。なかなか何か社内導入するときに、自分の中でも絶対導入するんだっていう強いやりきる意志がないと難しそうですね。
難しいですよね。難しい。
覚悟が必要だな。
博多家さんそういうのってありました?覚悟決めて。
いやー、なかったかもしれないですね。
なんか、よく言う2wayドアだったっけ。ベソスか誰かが言ってた言葉で、戻れるドアと戻れないドアみたいな確かじゃなかったかな。
後から無しにできる意思決定とそうじゃない意思決定があるっていう話で。
はいはいはい。
自分はその後に引き返せる意思決定しかしたことがない気がします。
後に引き返せる意思決定。
これやってみて、ダメだったら無しねっていう感じの意思決定ですね。
逆に後に引き返せないのって例えば、どんなものがイメージしやすいですかね。
自分がやったこともちろんないんで想像ですけど、会社のミッションはちょっと変えないか、ビジョンぐらいのやつを変えるみたいなことですかね。
変えてみてダメだったから元に戻すってあんましなくないですか。
確かにね。
そのぐらいのでかいことは自分の人生でなかったですね。
はい、というところでなんとなく話も落ち着いてきたんで今日はここまでしましょうかね。
なんか面白かったですね。自分は結構その厳禁な人間なんで、最初の方のいわゆる正々堂々うまいことを使うTipsみたいなのがちょっと気になりましたね。
ぜひぜひそれはじゃあ読んでみてください。
ちょっと見てみようかな。
はい、じゃあ今回は生成AI時代を勝ち抜く事業組織の作り方という書籍の感想について話しました。
感想などはハッシュタグユルテクをつけてポストお願いします。
Googleフォームからも送れます。
お願いします。
今日はありがとうございました。
ありがとうございました。
