スピーカー 3
ハローワールド始まりました。
今週も引き続き、ハローワールドは世界で活躍するエンジニアの方を招いてお話ししていきます。
今週はですね、僕はすごい仲良くしていて、3ヶ月前くらいにサンフランシスコに行ったときも、そのお方を呼んで一緒にビールめぐみとかしたくらい仲良い方なんですけども、
今シアトルで働いていて、元々バンクーバーで働いていて、すごい仲良くしていて、今シアトルでいるアメリカの超一流企業のエンジニアの方をお呼びしています。
スピーカー 3
今井さん、よろしくお願いします。
スピーカー 2
よろしくお願いします。
スピーカー 3
なんかあれですよね、最近ポッドキャストも始められたとか聞いたんですけど。
そうなんですよ。ホップマシマシ放送局っていうポッドキャストをやってて、もう一人やってるんですけど、毎週、毎週はちょっと言い過ぎですけど、
スピーカー 2
いろんなアメリカの都市に行ってブルワリーを巡って、クラフトビールが好きで、そういうのを話すポッドキャストをやってますね。
スピーカー 3
面白いですね。僕も井井さんとバンクーバーにいたときはよく一緒にビールを飲みに行ったような仲間で、今じゃあアメリカのいろんな都市に週末行ったりするってことですか?
スピーカー 5
そうですね。毎週はちょっと言い過ぎましたけど、機会があれば行ってるって感じで、先週もコロナ都市のデンバーでGABFっていうアメリカの中での最大級のビアフェスがあったんですよ。
スピーカー 2
そういうのを行ったりしてましたね。
スピーカー 3
すごいな。やっぱりエンジニアってなんでそういうクラフトビールとか好きなんだろうね。
スピーカー 2
何ですかね。いろいろ試せるから面白いですよね。いろいろ味が違って。
スピーカー 3
でもさ、いろいろ飲んでると、このビールはエンジニアってうんちくが好きじゃん。だからこのビールはここの人が作って、でも実はこのホップはこうで、この原料はみたいな、そういう知識も一緒に飲むのが美味しいとか
あるのかな。
スピーカー 2
正直味は私そんなに超えてないんで、情報を食べてますね。
スピーカー 5
このぶり割りが、このビールが去年のビアコンペで金賞になりましたとかっていうのを聞くとめっちゃ美味しくなるみたいな。
スピーカー 4
バンクーバーに一緒に行った時も、ここのぶり割り、ここが美味しいんだよって言ったら今井さんに違うところ連れて行ってもらって、違うよ、実はこのぶり割りはここから派生したものだからここに行った方がいいみたい
な、そういうことをめっちゃ教えてもらったような気がしていて。
スピーカー 3
何なんだろうね、そういうオタク気質なところはあるのかな、エンジニアは。
スピーカー 2
そうですね、エンジニアなんだかわかんないですけど、いろいろそういうストーリーを知るのが面白いですね。
それぞれのクラフトぶり割りが持っているストーリーとか。
あともちろんね、結構どういうものが入っているとどういう味が変わるとかっていうのを知るのが面白いですね。
なんか科学みたいなところもあるかもしれないですね。
スピーカー 2
コーヒーも好きですよ。
スピーカー 3
なるほど、コーヒーもやっぱりストーリーがあるってこと?
コーヒーはちょっとだけパラメータを変えて毎朝入れてみて、どう味が変わるかとかを眺めるのが面白いって感じですかね。
なるほど、確かに温度がちょっとね、5度違うだけで違う味になったりとか、入れる量を変えたら違うとか、水が変えたら違うとか、いろいろ。
スピーカー 2
ありますか。
スピーカー 3
なんか本当に、なんていうんだろう、やっぱり喫水のエンジニアというか、そういう感じなんだなと思っていて。
その辺でも結構気が合ってね、いろんな、一緒に飲みに行ったりしても、このビールはどうだとか、あの技術はどうだとかみたいな、同じような感じで話したりをしていて、とても仲良くさせていただいて。
さっき冒頭で言ったように、サンフランシスコで僕が出張で行った時も、今井さんわざわざシアトから来てくれて、一緒にビール巡りしたりとかもしましたね。
スピーカー 2
はいはいはい。
セナさんもね、来るって聞いてたんですけど。
セナさんも来るって聞いてないんですけど。
スピーカー 1
セナさんね、そうですそうです。
セナさんが忙しくて来れなくて、僕は会えなかったんですけど。
スピーカー 3
そうですね、もう一人のホストのセナさんは今日はいないんですけど、セナさんもよく一緒にビール飲みに行ってましたね。
はい。なんかあの、暫定で今一番おいしいなって思ってるビールって、ちなみにどこなんですか?
スピーカー 2
おー、それは難しい質問ですね。かなり。
まあでも。
スピーカー 4
上野エンジニアだからやっぱりそこは情景が必要だよね。
イフなんとかだったらみたいな感じで、そういう感じになるってこと。
スピーカー 2
ああまあでも、こういうやっぱヘイジーIPAっていうジャンルが結構好きなんですけど。
スピーカー 4
はいはいはい。それちょっと詳しく教えてください。
スピーカー 2
ヘイジー、ヘイジーIPAは、これIPAからになっちゃいますもんね。
スピーカー 3
IPAはみんな知ってんじゃないかな、最近は日本でも。
アメリカでよく見る苦いビールですよね。
スピーカー 3
苦くて度数が高いやつですね。
スピーカー 2
うん。ヘイジーIPAは、そのIPAなんだけど、
この麦に大紬とか小麦とかっていうのを混ぜたりしてて、そうすると色が濁るんですよ。
で、濁ってて味も結構苦さも抑えられつつトロピカルな印象が多いのが多いですよね、ヘイジーIPAは。
なので結構誰でも飲みやすい感じのIPAっていうイメージですね。
スピーカー 3
そうね、なんか最近日本でも結構ヘイジーIPAとか置いてるところあって、
クラフトビールの店行ったりすると出てきてるんで、日本でも飲めるかなって思ったのと、
あとやっぱそのトロピカルな感じがしますよね。
だからみんな誰でも飲めるみたいな、あんまり苦くないみたいな感じがあるんで飲むけど、結構度数は高いよね。
スピーカー 2
そうですね、結構危ない。
で、このヘイジーIPAの中で言うと、個人的に一番来てるのは、
シアトルから2時間半ぐらい南に行ったところにあるポートランドっていう町があるんですけど、
スピーカー 2
ポートランドにあるブルーホス、ブルーイングってとこがめちゃくちゃ美味しいです。
そこはもうそこで飲むのがやっぱ一番美味しい?
スピーカー 2
と思いますね。
ヘイジーIPAは結構温度が上温のまま輸送されちゃうと、結構香りとかが飛んじゃうみたいで、
なんで結構なんか輸送が難しいんですけど、それもあってブルーワリーで飲むととっても美味しいですね。
スピーカー 3
シアトルからだとポートランドは車で行ける範囲なんですか?
スピーカー 2
はい、多分車で3時間かな。3時間で行けると思いますね。
スピーカー 1
週はまた行くよね?
スピーカー 2
そうですね。北から順番にバンクーバー、シアトル、ポートランドみたいな感じで西海岸沿い。
スピーカー 3
サンフランシスコ、L.A.みたいな感じ?
スピーカー 2
そんな感じですね。
スピーカー 3
ポートランドはね、知ってる人は知ってるかもしれないけど、もともとサードウェーブコーヒーとか発祥が確かあそことかっていう話も聞いたことあるし、
なんかオシャレな感じのイメージがある。僕も行ったことないんですけど、そんな感じなんですか?
スピーカー 2
そうですね。いろいろカルチャー的な部分ではいろいろありそうですね、ポートランドは。
あと小さくて可愛い感じですね、街が。
スピーカー 3
いいですね。もしこれ聞いてくれてるビール好きの方が行くなら、まずはポートランドのそこのブルー行ったらいいってことですね。
スピーカー 5
はいはいはい。ポートランドはそこ以外にもめっちゃあります。
スピーカー 3
でもアメリカ全般で美味しいんじゃないの?結局。
スピーカー 2
そうですね。アメリカは大体どこの都市に行ってもありますからね、ドラフトブルーベリーが。
スピーカー 3
なるほど。
スピーカー 2
でもそれこそね、私たちが住んでたバンクーバーもいっぱいありましたからね、ブルーベリー。
そうですね。3つぐらいのエリアあったよね、そういうブルーベリーが並んでるみたいな。
スピーカー 3
で、今週はここのエリア行こうとか言って、3、4軒行ったりとかして、そういう感じで飲み歩いてましたけど。
スピーカー 2
いや、いいとこだった。
スピーカー 4
そう、そんなとこなんですけど、これ聞いてくださっている方、今したってビールの人みたいな感じになっちゃうけど。
スピーカー 3
初めて出てくださるので軽く自己紹介で、もちろん会社名とか言えなかったらもちろん伏せていただいていいので、今の経験とかそういうのを教えていただければと思うんですけど。
スピーカー 2
はいはいはい。私はですね、もともと日本で大学、大学院という風に行って、専攻は電気電子工学だったんですけど、そこから上海市系の会社に入って新卒で。
で、そこで5年くらいですかね、働いていて、その後そこからカナダの方に移って、カナダからアメリカに来たって感じですね、今。
カナダのバンクーバーだよね。バンクーバーのビッグテックの一つの会社に入って。
スピーカー 2
そうですね。
スピーカー 3
で、まぁそこで。
スピーカー 2
これ普通に、もっと普通に言っちゃった方がいいんですけどね。
スピーカー 1
まぁでも全然言っても。
スピーカー 2
はいはいはい、まぁいっかじゃあ別に。
スピーカー 1
まぁあの、好評してることだと思うんで、はい。
スピーカー 2
うーん、そうですね。
いやいや、すいませんすいません。
犯罪者みたいな感じになってる。さっきから言ったらやばいみたいな。
スピーカー 3
まぁビッグテックで働いてると。で、シアトルでも同じような、同じところで働いていて、カナダからアメリカに行ったっていう、結構レアなケースですよね。
そうなんですよね。そもそもカナダに就職できたのが結構奇跡的な感じで。
スピーカー 2
もともと日本にいる時にリモートでそのカナダのビッグテックの会社の面接を受けて、そしたらなんか通っちゃったんで。
通っちゃった?
カナダに来ちゃったみたいな感じで。本当にでもその時なんだろう、とりあえず受けてみるかみたいな感じで、他にどこも面接したことなかったんですけど、転職しようと思った時に。
で、その時に受けてみて、スルスルっと行っちゃったので、カナダに来たっていう感じでしたね。
スピーカー 3
いやーすごいよね。そもそもだってそんな休日もないでしょ、多分。日本から受けてカナダにみたいな。だからこそみんなさ、今、現地で一回行って就職するみたいなのが多いですよね。
あの時はコロナの終わりのバブルが弾ける前みたいな時期だったので、多分どこのビッグテックも人生を取り合ってる時期で。
スピーカー 1
いや本当なんか変なことが起きてましたよね。日本だともしかしたら違うかもしれないですけど、なぜかその時すごい就職がめっちゃ景気が良かった。景気が良いってわけじゃないよね。なんか採用がすごかったんです
スピーカー 3
よね。
スピーカー 2
そうですね。なんで私が入社してから数ヶ月ぐらいで結構大規模なレイオフあって、いろんな人がいなくなってましたけど。そこがあれでしたね。バブルが弾けた瞬間みたいな。
スピーカー 4
いやでもさ、いまいさんの話へとレイオフの話はつきものでさ、毎回連絡するためにさ、ニュース聞くじゃないですか。ニュースであの会社が何千人切ったとかって話になると、もしかしていまいさん?とか思うわけじゃ
スピーカー 1
ん。
スピーカー 4
もちろんいまいさんの能力をしたり見てたわけじゃないけど、ちょっと恐る恐る連絡したら、いや大丈夫だったけど、でもなんか机の両隣の人はいなくなったよみたいなそういう話とか多くの場合言ってて。
スピーカー 2
ありましたね。
スピーカー 4
いやすごいよね。そういう世界なんだね。
スピーカー 2
いや恐ろしい世界では、であることを気づかされますね。イベントが起きるために。
スピーカー 3
いやでもさ、やっぱそこでさ、もう長いでしょ。5年ぐらいでしょ。ずっと生き残って、やっぱ生きてるってことはやっぱ会社と必要とされてるし、能力もすごい高いんだなと思ってるんですけど。
スピーカー 2
うーん、まあうんって言いますけどね。そこらへんは。ちょっとよくわかってないんですけど。
スピーカー 3
まあ確かにその、なんか給与が高い人が逆に聞いられちゃうみたいなのも話も聞きますよね。コスト的にとかチームとかなんかそういうのも聞きますよね。
スピーカー 2
そこらへんのアルゴリズムは絶対に泣かされないんで。
スピーカー 4
そうなんだ。
難しいところですね。
スピーカー 1
そうなんだ。
いやーそうね。でもあれでしょ、もう言うても、もうエンジニアも、その最初の外資系もエンジニアやってたんですか?
スピーカー 2
あーそうですね。最初のところが、えっとなんだっけ、日本IBMってところで。
で、日本IBM自体はかなり営業系というかSI系の職種の人が多いんですけど、私が入ったのは製品開発部門みたいなところで。
そこで、えっと当時、IBMワトソンっていうAIの企画員みたいな。
スピーカー 3
めちゃくちゃ懐かしい。リープランニングのあの、なんかIBMなんかクラウドみたいなの作ってたよね、そういう。
スピーカー 2
そうですそうです。IBMワトソンがもともとアメリカのクイズ番組で人間に勝ったみたいなのから始まって。
スピーカー 5
で、そこからそのIBMのクラウドを作るっていう時に、AI系のオファリングを全部IBMワトソンなんとかだったんですよね。
スピーカー 2
っていうので、私がいたのはそのIBMワトソンの一つのあれですね、製品のところで。
なんでそのクラウド上で作る、提供されるAPIとか、コンソールとかそういうのの部分を開発していたっていう感じですね。
スピーカー 1
あーそっか、じゃあ内製のそういうサービスがあったんですね。
そうなんですよ。
スピーカー 3
なんかそれから今、今ももちろんソフトエンジニアとして働いてると思うんですけど、めちゃくちゃ開発の、やっぱね話題は全部AIに持ってかれちゃうのがあれなんですけど、
やっぱね、みんな気になるのが、やっぱ一流、世界の一流エンジニアの人はどうやって、
スピーカー 3
どうやってっていうのはもしかしたら会社のコンフィデンシャルなことがあるんで言えないかもしれないですけど、
スピーカー 1
どういうメンタルでそこを立ち向かっていっているのかとか、今の考え方とか、使ってるツールとかまでは言えないのか、
スピーカー 3
その辺も言える範囲でどのぐらい変わったのかっていうのとどう乗りこなしているのかみたいな話を聞きたいなと思うんですけど。
スピーカー 2
いやーやっぱりなんか、あれですよね、いろいろ試すのは試していると思っていて、
うまくいってすごい気持ちいい気分になる時と、全然うまく思った通りにいかなくて、すごいなんか憂鬱になるサイクルみたいなのを繰り返してる気がしますね。
スピーカー 3
ちょっとそこでめっちゃ深掘りしたくて、やっぱりいいエンジニアっていうのは自分の環境とかをハックしていくみたいな感じがあるのかなと思ってて、
いわゆる昔で言うとビムをめちゃくちゃカスタマイズするみたいな、シェルをめっちゃ改造するみたいな人が、
で、一時期そういう人たちってそんなことしなくても別にVSコードを使えばいいじゃんとかっていう風にあんまりフォーカスはやってなかったけど、
スピーカー 3
今逆にそういうデファクトスタンダードがないからこそ、そういうハックする能力っていうのはめっちゃ高い方がいいかなっていうのがあって、
そういう文脈で今井さんもやっぱりいろいろ試してるってこと、つまり業務以外でもいろいろ環境に対していろいろやってるみたいな感じ?
そうですね、私は結構、なんて言うんだろう、業務にリソース全部リフする系のあれなんで、
スピーカー 2
結構仕事の環境をどう最良くできるかみたいなことを結構考えることが多いんですけど、
今でもいろいろ試してると、でもこれあれですよね、Vimでもありましたよね、VimのVimRCの設定をいじってるだけで何も仕事進んでないみたいな。
スピーカー 3
でも昔からちょっと違くて、書くの早いのが結構良かったじゃん。書く速さっていうのが作業効率で下がったわけでしょ。
だからVimの改造っていうのはある意味受け入れられたのかもしれないかなって思うけどね。
でもそんな感じで、例えば自分のワークフローにフィットするようなツールとか作ってみようとか言って作ってると、
スピーカー 2
そのツール作ってる時間は自分の業務進んでないんで、めっちゃ時間無駄になったりして、
結局最終的には他の誰かがもっと洗練したツールとか作ったりしてて、そっちに乗った方がいいじゃんみたいな。
なったりすると憂鬱な時期が来ますね。
でもそれをやるべきというか、それをやることがエンジニアリングじゃないかなって俺は思ってて。
スピーカー 3
あとはレベルだよね。別に目の前のことやってるんだったらそういうことしなくてもいいじゃん。
でもやっぱり今井さんとかぐらいになると、レバレッジをかけなくちゃいけないでしょ。常に自分に対して。
効率化みたいな。目の前のことをただこなすんじゃなくて、目の前のことをどんだけ少なくやれるかみたいな。
スピーカー 3
で、次の時もそれを使うかみたいな。それがエンジニアリングなのかなって思ってて。
スピーカー 2
最近は特に何かありますよね。クオリティより量みたいな雰囲気ありますよね。
1日に何十コミットしたことがすごいって言われるみたいな。
そういうスループットを伸ばすことが称賛される雰囲気がありますよね。
それがいいのかどうか結構微妙だなって思うんですけど、結局何か1つフィーチャー出してそれが1コミットだとして、
それを何かめっちゃ細かく直してるのが20コミットあったら何か普通に1コミットでフィーチャー出すのと実際は変わんないけどコミット数はすごい伸びてるみたいな。
スピーカー 3
ちょっと政治みたいな話になってくる。社内の政治みたいな。
やっぱり今の時代、前社と後社っていう話だと後社の方がマネージャーには好まれそうだよね。
スピーカー 4
お前よくAI使いこなして20コミットもしたなみたいな。時間とクオリティが実は1コミットと変わんないかもしれないけど、そうやって分けた方がいいみたいな。
スピーカー 2
みたいな風潮はあるんじゃないかなと思いますけどね。
スピーカー 3
確かにね、それはあるかもしれないよね。
さっきは始まる前に話したけど、どちらかというと自分が作業者ってなるっていうところから逸脱するぐらいの方を考えないと、もしかしたら0÷1ってかかんないのかもしれないですね。
スピーカー 2
本当にそうですよね。コードのクオリティとかも、生成したものを頑張って直すというよりかは、どういうハーネスを作ったら思い通りに生成してくれるのかみたいな方に時間をかけた方が良さそうですよね。
スピーカー 3
今井さん的にはそこに結構フォーカスしてます?目の前のやる仕事よりは0÷1かけるためにそういうところを研究してみる?
スピーカー 2
結構難しいですね、バランスは。言っても仕事を進めていかなきゃいけないのはそうなんで。
そういうところも含めて多分チームでそこら辺のところをどう取り組んでいくかっていうのを影響力を出せる人がディーダーなのかなと思いますね。
多分考え方も変えなきゃいけないと思うんで、チーム全体が。
スピーカー 1
チーム自体がってことね、なるほどね。
スピーカー 3
でもそういうのは苦手なんで、頑張っていかないといけないなっていう感じですね。
スピーカー 3
個人的に今後、本当に1年2年変わったじゃないですか、世の中が。特にソフトウェアエンジニアとして。
たぶんそもそも見えてたキャリアパスとかっていうのがもう全部違う風になっちゃってとか、やりたい技術とかもなんか違うくなっちゃってとかっていう風にあると思ってて。
今井さん的には、たぶんチームでどうこうもあると思うんですけど、個人的に今後なりやりたいとかどうなっていきたいとかあるんですか?
もしくはこれを聞いてくださるジュニアのエンジニアの方たちにこうなった方がいいよみたいなアドバイスとかなんかあるんですか?
スピーカー 2
いやー、そこら辺は定まってないのが正直なところですね。
結構仕事でやってたのは、例えば結構分散してるシステムの問題解析とか、あとはすごい低レイテンシーなサービスとかを作ってたんで、
そこの低レイテンシーの部分をどう削るかとか、あとはスループットをどう伸ばすかとか、あといかにこのインフラのコストを下げるかとか、
そういう結構泥臭い部分をやっていて、だからこそ割と重宝されていた部分はあるんですけど、
スピーカー 2
そういうの結構AIがもうズンってできちゃってる感じがあるのはあるんで。
スピーカー 3
まあね、ログとか見るの得意だしね。
スピーカー 2
そうそうそうそう。
そうそう、それこそだからちゃちゃっとステルスクリフト書いてバーってやるとかを結構できますみたいな感じでしたけど、
ステルスクリフトがすごすぎるんで。
スピーカー 4
もっと高難易度なやつ書くからね。
なので、でも最近結構思ってるのは、やっぱり自分がいるチームは結構歴史が長いチームで、
スピーカー 2
実際にこうプロダクションでダウンとかできない、すごい可用性が高いような求められてるシステムなんで、
だからそういう部分に対して、今のこの最先端できてるソフトウェアファクトリーとか、
スピーカー 2
そういうものをどうやってアプライしていけるかみたいなところは結構興味ありますね。
スピーカー 3
実際に何か実験とかもされてる?
スピーカー 2
実験とまでは行かないですけど、例えばレビューをする、自動でレビューをするツールってどこかしらあるじゃないですか。
そういうところにChinoのレポジトリでレビューのスタンダードのルールを集めていくとか、そういうのはやろうとしてますね。
でもクロードコードの作者の方、ボリスさんが言ってたのは、シフティングトゥレフトみたいなことを言ってたんですよ。
ソフトウェアの開発パイプラインが左からコードを書くところからテストしてデプロイしてみたいなのがあるとしたら、
検証ができるスピードを高めるためには一番左の部分、例えばローカル環境とかでなるべくたくさんテスト検証できるようにした方が
スピーカー 5
流行を回していくのが早くなるとか、そういう話をしてて。
スピーカー 2
なので、例えばあれですよね、ローカルで動かしてるけど、ローカルで動かしてるものがプロダクションのMockみたいなので動かせるようにしてれば
開発中のAIアジェントが変更したものだけどその場ですぐテストできて、ある程度検証したもので回していけるんじゃないかみたいな。
そこら辺のところとかは興味ありますね。
スピーカー 3
テストとかすごい本当に課題というか。
逆に言うと、いわゆるE2Eテストだと思うんだけど、僕も最近そっちの考えになってるんだけど、
それがあってれば中身のコードは、もちろんパフォーマンスとかあるよ。
Nプラス1とかいろいろあるじゃん。
だけどそこまで気にしなくていいっていうのは、そういう考え方にみんな移ってきてるのかな、みたいなのもあるかなと思ってて。
スピーカー 2
いやー、それは結構移りたいけど、その勇気がないとか言われそうですね。
なんかすごい極端な例だと、ラストに移ると、ラストに書き換えると単純にメモディ使用量がめちゃくちゃ減るとか。
そういうのでラストに書き換えましょうみたいな動きもあるんですけど、結局ここであれですよね。
例えばループを回してラスト版ができるのはできるんですけど、1日くらい回せば。
それをブラックボックスのまま作業できるのかみたいな話はどうなんだろうと思いますね。
意思決定の範囲になっちゃうのかもしれないですね。
でもイマイチさんはRuby on Railsやってた?
スピーカー 2
いや、やったことないですね。
スピーカー 1
確かアクティブレコードってそんな感じなんだよね。
スピーカー 3
ブラックボックスみたいな感じで、誰も人間はあんまりよく読めないけどみたいなそんな感じだったはずなんだよね。
でもそれが便利でみんな使ってたみたいな感じだったと思うから、
それもそういうのも許容されていくのかなみたいな感じは思いますけど。
スピーカー 2
そうですね。今はコードレビューされてますか?
スピーカー 3
僕はどちらかというとモデルとかを見るようにしているのと、
あとバーって眺めてみて、それも全部自動でやってるんですけど、
スピーカー 3
コード進めるみたいなのを出すようにしてて。
2つあって、1つはAIにいろんな観点、スケーラビリティとかメンテナビリティとか、
スピーカー 1
よく言われるやつあるじゃない、セキュリティとか、その観点からコンテキストをゼロにした
スピーカー 3
エージェントでレビューをしてもらうっていうのを1個やってて、
もう1個がコード進めるって言われる変更の中で怪しいところを見つけてもらうみたいなものがあって、
最初に言ったメンテナビリティとかいろんなものは10段階のスケールにしてもらって、
7以上だったらOKみたいなので、そこは機械的にやってて、
スピーカー 1
あとはその中で出てきたP0、P1みたいなそういう直さなきゃいけないところがあったら、
それを見てやるかやらないか決める、みたいな。
スピーカー 3
コード進めるは一応見るみたいな感じにしてますね。
スピーカー 2
一応指摘が上がってきたらコードは読んでるって感じなんですね。
スピーカー 1
全部は読んでないですね。必要なところだけコード進めるところだけ読むのと、
スピーカー 3
P0、P1に上がってきたところだけ見るのと、
あとはモデルのDB設計ぐらいは見ようかなみたいな感じで見るって感じですね。
スピーカー 2
すごいですね。
スピーカー 3
でも難しいのが、そのツールを動かすたびに毎回同じP0が出てくる場合もあるんですよね。
毎回毎回。1回目やったけど2回目出なかったとかってよくあるじゃないですか。
見過ごされてたみたいなのがあるから、
スピーカー 3
それを何回やればいいんだろうみたいなところもあったりとかして、
結局それを2回目に気づいて、うわぁこれやばかったじゃん、
このまま出してやばかったじゃんみたいなのも当然あり得るから、
スピーカー 1
その辺のランダム性は結構あるなと思いますね。
スピーカー 2
難しいですね。
スピーカー 3
割り切るしかないんじゃないかなと思って。
スピーカー 5
私は、チームは普通にまだコードレビューはあるんですけど、
スピーカー 2
このプロリクエスト出してそれをレビューするみたいなプロセスはあるんですけど、
一応レビューがしやすいように、コード読まなくてもいいようにガイドを出してくれて、
それで大体デザインが分かるみたいな機能とかもあったりするんですけど、
やっぱりすごいエンジニアの人はコード見て結構指摘してるところがあったりして、
そのAIが指摘してないようなところを。
だからそういうのを見ると、なかなか難しい問題だなと思いますね、このコードレビュー。
スピーカー 1
分かりますよ、めっちゃ分かるのが、
僕もちゃんと見たらこれおかしいじゃんってめっちゃある。
スピーカー 3
なんで2箇所やってるのとかさ、凄い処方的なところもあるけど、
スピーカー 1
そこを見過ごせるかどうかみたいな、そういうニットピック的な感じかもしれない。
スピーカー 3
さっき今井さんとこの前に話した1WAYと2WAYの話、何でしたっけあれ。
スピーカー 2
ありますね。
1WAYと2WAYドアみたいな話ですね。
スピーカー 3
どういう意味でしたっけ。
スピーカー 2
1WAYドアはそっちの方向に変更を進めていったら後戻りできないみたいな。
もしくは後戻りさせることのコストが非常に高いっていうところで、
スピーカー 2
2WAYドアはそっちの方向に進んでダメだった時に戻るコストが低いからとりあえずやってみようみたいな感じの話ですね。
スピーカー 4
そうそう、だから結局前者、1WAYドアじゃなくてどっちだっけ、コストが低い方で2WAYか。
スピーカー 2
そうですね。
スピーカー 3
2WAYは別にさ、後で直せばいいっていう判断もあるじゃないですか。
スピーカー 2
それはそうですね。
スピーカー 3
ビジネスだと機能を実装することが最優先かもしれないですよね、会社によっては。
もちろんトレードオフで本当にめっちゃカッチリ作るのが絶対だっていう会社もあるだろうし、機能を絶対作るっていうのもあると思うし、
その辺のトレードオフがあるから、そこでどうするかっていう意思決定を結局誰かがするみたいな話かなって。
スピーカー 2
いやでも方向性としては絶対ガツガツ変更を入れまくっていって後から修正するみたいな方向性ですよね、時代としては。
スピーカー 3
どうなると思う?夢みたいですけど、例えば何十年後かにバグが出ました。
スピーカー 4
出た瞬間にエージェントが10ミリセックくらいで反応してコード直してデプロイして、それはもう一生起きませんみたいな、そういうこともあり得るってことですね。
スピーカー 2
確かにあり得ますよね。確かに確かに。
全ての概念がね、今だったら修正したらデプロイするのに何時間かかってるって話があるかもしれないですけど。
スピーカー 2
そんな次元じゃなく問題が見つかったらその場でホットパッチでコード直しちゃうみたいな。
それを監督してるのがただのエンジニアみたいな、そういうポジションになっていくのかなみたいな思うところもありますね。
スピーカー 3
そういう上で今何勉強したいと思います?これからエンジニアやりたい人とか。
スピーカー 2
いやー難しいですよね。何勉強したらいいというよりかは、やっぱり出力されたものを理解しようとする気持ちは必要なんじゃないかなと思ってます。
スピーカー 4
AIに丸投げしないでってこと?
スピーカー 2
そうそうそう。単純に例えばゲームを作ってって言ってゲームができた時にどうやってできてるか見ると面白いのかなとか。
内部的にどういうエンジンを使って作ったのかとか。そういうとこの好奇心があった方がいいのかなっていう気がしますね。
なんとなく何か頼んでできたのをワイってやってるだけだとあんまり自分の成長してる感はないですよね。
今井さんはどうやって気をつけてるんですか?
スピーカー 2
気をつけてる?
いやーそうですね。やっぱり最初の頃って出力は結構疑わしかったじゃないですか。
確かに。
スピーカー 5
結構今でも疑わしい気持ちはありますけどね。本当に正しいのかみたいな。
まあそういう頼りすぎないというか、一回はセルフレビューしようぜみたいなところは個人的にはすごい思ってて。
スピーカー 3
それはビジネスサイドにも言えることなんだけど、結局適当にAIで作ったものを同僚とかに渡してしまうと同僚の読み解くのがすごい難しくて。
その資料とか。でもそこでまた同僚が難しいからAIを使って読み解いたらどんどん情報がなくなっていってしまって。
どんどんペラペラのものになっていってしまうみたいなところがあるのかなと思うんで。
スピーカー 2
いやーありますね。
気をつけたいなと。僕もやっぱりたまにやってしまうんで。適当にペッて作ったものをペッて渡してしまって。
スピーカー 3
これちょっとめっちゃわかりづらかったなみたいな思う時とかあるんで。
スピーカー 2
うーん。その自分が書いたものなのに書いてあることを説明できないときめっちゃ恥ずかしいですね。
スピーカー 4
わかるわかる。めっちゃわかる。
スピーカー 2
だからその恥ずかしさを持った方がいいかもしれないですね。
恥ずかしさ。恥ずかしさ持った。恥ずかしさ。
これ指摘されたら恥ずかしいなみたいな。
そうね。
スピーカー 2
意外と言っていないしないです。
スピーカー 3
でもさ、最近また別話に行けるけど、そういう指摘するじゃん。指摘したら言い訳のようにこれAIで作ったんだよみたいな言う人もいて。
それはじゃあおかしくないみたいな。責任持って作ったものを自分のみたいな。
スピーカー 2
それはめちゃくちゃありますね。そこが言っちゃいけない感ありますよね。
たとえばプレゼントかしてるときにこれ絶対AIだろって作ったのかなってみんな頭の中で思ってるってことやから。
スピーカー 2
だから振り切るかですよね。これは完全にAI先生ですって振り切るか。
もしくはちゃんと理解するかですよね。
スピーカー 3
そうそうちゃんと理解して、たぶん個人的には2回は絶対、2,3回くらいセリフレビューして改善しないと絶対理解できないし、AI作りすぎちゃうから。
僕はAIで一発で出したやつとかは全部言います。これちょっとAIで出したんで、合ってないかもしれないですけど適当に読んでくださいみたいな。間違えてますみたいな。
参考までにみたいな感じで出しますね。これはそもそもトゥルースではないですよって感じで出しますね。
スピーカー 2
それはそれで言うようなことがありますもんね。このスピード感でパッと出して。
スピーカー 3
そうそうそう。共有だけ一旦しますみたいな感じで。