YT YouTube2Text

YouTube2Text → Transcripts → AI Coding Meetup #3 AI時代の開発スピードと品質のバランス術

AI Coding Meetup #3 AI時代の開発スピードと品質のバランス術 — Transcript

by LayerX 公式 · 1,635 words · 1,635 segments · language ja · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:02はい。えっと、書いてます。声聞こえます
0:05か?
0:07はい。えっと、皆さんこんばんは。
0:11えっと、AIXAIコーディング
0:13ミートアップ第3回、えっと、AI時代の
0:15開発スピードと品質のバランス術というの
0:18で、えっと、始めさせていただきます。
0:20オフラインの皆さんも、オンラインの皆
0:21さんもよろしくお願いします。
0:24[拍手]
0:28ほい。
0:30はい。えっと、まずちょっとこの会社、
0:32ちょっと皆さん来ていただいた会社につい
0:34て軽くご紹介させてください。えっと、僕
0:37たちはこのレイヤXという
0:413つございまして、えっと、2B向けAI
0:43を使ったサズの、えっと、爆落事業とAI
0:46LLM、LMLLM事業で、あとはその
0:50AIDXドメインとしてFINECHの
0:53事業の3つの事業をやっておりますと。
0:57はい。ちょっと皆さん早くお話を聞きたい
0:59と思うので、ちょっとさっくり会場の注意
1:02とか、ま、そういうのをさせてください。
1:04えっと、まずこのオフラインの会場につい
1:05てですが、えっと、Wi-Fiについては
1:07、えっと、ホワイトボード、
1:10ホワイトボード、それかなに、えっと、
1:12記載がございますので、ちょっと皆さん、
1:14Wi-Fiが必要な方はそれご確認
1:16ください。で、お手洗いなんですけど、
1:18その皆さん入って来ていただいたその中央
1:21の扉、ま、あのWi-Fiのボード超えて
1:23中央の扉から出て、えっと、左手側かなに
1:27ありございます。で、えっと、向えの
1:29オフィスフロアなんですけど、えっと、
1:31レイアXではない様のオフィスの、えっと
1:33、質エリアとなっておりますので、通路で
1:36のご引色とか会用はご控えください。で、
1:39えっと、イベントの終了後はアンケートの
1:40回答もよろしくお願いいたします。
1:46はい。で、えっと今回のイベント、この
1:48AIコーディングミートアップなんです
1:50けど、えっと、ま、今回が第3回になるん
1:52ですけど、ま、AIコーディングとかAI
1:54コーディングのエージェントの個人利用
1:56って、ま、皆さんされてると思うんです
1:57けど、ま、それってまだそのチームとか
2:00個人でやってみるぞっていうのは、ま、
2:02やってる方いっぱいいると思うんですけど
2:03、ま、それをチームとか組織で実践的な形
2:06で、えっと、ま、導入とか活用をしてい
2:09るっていう地見って、ま、まだまだ共有が
2:11十分にできてない。ま、みんな探索してる
2:13フェーズなのかなと思っていますと。で、
2:15ま、そういう状態の中で、えっと、組織で
2:17、ま、それを活用していき、活用していく
2:20ぞっていう、ま、その実践している人が、
2:22ま、どういう思考錯誤をしているのかとか
2:23、ま、課題とかを、えっと、皆さんに共有
2:26することで、ま、みんながその次の
2:28ステップに行けるように、ま、そのどう
2:29やったら次のステップに行けるかをサルバ
2:31が必要だと考えて、えっと、このイベント
2:33をやってますと。で、あとはレックスの
2:35行動指針にベッドAIと解くというのが
2:38あるんですけど、ま、この観点からこの
2:40イベントを通じて、ま、AIコーディング
2:42であるとかのそのを広げていきたいと思っ
2:45ております。
2:47はい。で、えっと、今回のテーマはAI
2:50時代の開発スピードと品質のバランス術と
2:52いうことで、えっと、TwitterXの
2:57ハッシュタグAIコーディングという、
2:59えっと、ハッシュタグでやっておりますの
3:00で、皆さんこう感想とかあたこういうとこ
3:02どうなんだろうみたいな質問とかあれば
3:04ちょっと僕の余裕があるかどうかわかん
3:06ないので拾えないかもしれないですが、
3:07えっと、是非、えっと、投稿してください
3:10。
3:12では、えっと、そんな感じですかね。えっ
3:15と、エアコーディングミートアップ第3回
3:17始まります。
3:18よろしくお願いします。で、えっと、ま、
3:251
3:25番最初まずその導入セッションなんか、ま、今回のイベントそのほぼディスカッションで進めます。で、ま、でも突然パネルディスカッションが始まっても、ま、今人たちは何の議論をしてるんだろってなると思うので、ま、その論の前提を一旦ちょっと自分の方から共有させていただきます。で、その後
3:41パネルディスカッションの方に、えっと、移らさせてきます。はい。
3:46ということで、このまま
3:49このまま
3:53よいしょ。
3:57はい。えっと、AIコーディング
3:59ミートアップ第3回の導入ということで、
4:01えっと、ま、今回のこのAI時代の開発
4:03スピードと品質のバランス術というテーマ
4:07で、ま、どういう話をしたいのか、ま、
4:09どういう議論をしたいのかについて、えっ
4:10と、共有させていただきます。で、ま、
4:13さっきから話してるお前は誰やねんって
4:15いう感じだと思うんですけど、えっと
4:16このレアXの爆落事業部で、えっと、
4:18スタッフエンジニアをしておりますと泉5
4:20日0と言います。僕は今日なんかこういう
4:24ディスカッションしたらこの人たちで
4:25ディスカッション、ディスカッションし
4:27たらめっちゃ面白いんじゃないってなんか
4:29スラックで無責任なこと言ったらなんか今
4:31僕はここにいます。怖いですね。ま、
4:35ちょっと、ま、私化して楽しませて
4:37いただきますと。で、ちょっと、ま、最初
4:40にこの今日は話さないことを共有させて
4:42ください。ま、やっぱりそのAI時代って
4:46どうやってこうエンジニアを育てるんで
4:47あろうみたいなとこって結構こう難しい
4:49議論としてあるんですけど、今日は
4:50ちょっとそこスコープアウトさせて
4:51ください。で、あとは住宅開発とりは
4:53どっちかって言うと、ま、自社プロダクト
4:55とか、ま、自分たちプロダクトを作って
4:57いくその世界について中心に話します。で
5:00、あとは個別の利用、ツールの利用方法、
5:02今だとクロードコードをこういう風に使う
5:04といいよねみたいな、そういう、ま、
5:06めちゃめちゃ具体のプラクティスとかは
5:08あまり扱いません。で、えっと、書き忘れ
5:11たんですが、あとそのプロダクトにAI
5:13エージェントを組み込むぞというよりは、
5:14えっと、開発する時にAIエージェントを
5:16どうやって活用していくかという話を、
5:19えっと、メイントピックとして扱います。
5:23はい。ということで、えっと、導入なん
5:24ですけど、皆さんAIコーディングまずし
5:26てますか?してます。AIでコーディング
5:28してるぞって方、ま、結構やっぱり多い、
5:32多いですよね。ありがとうございます。
5:35AIコーディングでアウトプット増えまし
5:36た。もうめっちゃコードいっぱい書ける
5:38ようになった。めっちゃ成果出るように
5:40なったって人、成果というかも作れるよう
5:42になったって人をやっぱり多いですよね。
5:47じゃあアウトカム増えましたかってこう
5:49自信持って手上げられる方どれぐらいい
5:50ますか?
5:52だいぶ減っちゃいましたが、
5:55ま、別にあの大丈夫です。その別にそれで
5:58攻めることはないので、ま、もちろん
5:59アウトカムが増えるところまで繋がって
6:01いる方もいると思うんですけど、ま、一方
6:03で自信がない方もやっぱ多いですよね。
6:05こう、ま、事業会社であればその作ってる
6:08プロダクトがお客様に提供する価値の送量
6:10が増えてるであるとか、そもそも会社の
6:13成長を加速してるのかとかって、ま、結構
6:15難しいトピックだと思いますと。
6:19で、えっと、これ今日のイベントコンパス
6:21のページの説明を引用してきてるんです
6:24けど、ま、やっぱりそのぱ行動を書く量と
6:27か、ま、そういうのは結構早くなったって
6:29実感ある方いると思うんですけど、でも
6:32開発フロー全体を見るとやっぱりこう
6:34ちょっとずつ歪みが溜まっていってる場所
6:36もあると思うんですよね。で、それをま、
6:39どういう風に考えていくかという話が今日
6:41のメイントピックですと。ま、実際こう
6:44すごいすごい観略化した開発プロセスが、
6:47ま、ありますと、プロダクトをどういう
6:49ものを作るかを計画してそれを設計して、
6:51ま、どういう風に実装して、ま、レビュー
6:53とかテストとかQA品質保証をしていくか
6:56っていうのがあると思うんですけど、ま、
6:58やっぱこの実装のところ、ま、クロード
7:00コードでブわっとコード書くみたいな、
7:02ここはAIコーディングの恩恵は絶対受け
7:04やすいと思うんですよ。ま、実際これで
7:05アウトプットは増えると増える人、増える
7:08という方はいると思いますと。またこの
7:11前段も結構、ま、加速しやすいと思うん
7:15ですよね。ま、弊車だったらそのカーソル
7:17を使って、ま、PDMがそのアウトプット
7:20の量を増やすみたいな活動があったり、ま
7:23、あと設計をそのチャトGPTとかと
7:26やり取りして、ま、設計の
7:27ディスカッションすることで僕らの設計
7:28活動も、ま、より加速するっていうのは、
7:30ま、感じてる方はいると思います。
7:34じゃあ、ま、アウトカム増えてんじゃな
7:35いって言えそうな気がするんですけど、ま
7:38、ちょっともうちょっとこう開発プロセス
7:40を広げると、ま、本来一直線じゃないと
7:42思うんですけど、
7:44ま、こうそもそも最初後は、ま、ユーザー
7:47への価値提供であるとか事業成長を加速さ
7:49せさせたいっていうのが、ま、1番欲しい
7:52アウトの1つなのかなと思ってますと。で
7:55、ま、実際どうなるかって言うと、その
7:57実装のアウトプットの流量はめっちゃ増え
7:59たとして、じゃあ何が起きるかって言うと
8:01、ま、当然なんですけど、後工程に流れて
8:04くるものが増えるんですよ。ま、コード
8:07レビューめっちゃすることになってるんだ
8:09けどとか、なんか動作確認んだけどとか、
8:12ま、その辺も全部AIにやらせてるけど、
8:14実際どうなんだろうであるとかで、それが
8:17その、ま、単純に流量が増えると大変だし
8:19、ちょっとこうAIがやチすることって皆
8:22さんあると思うんですけど、ちょっと
8:23やチ家が多いと、ま、どんどん後工程は
8:26大変になっていきますと。
8:28で、ま、ここが大変なって、あと何が
8:30起きるかって言うと、例えばその、えっと
8:33、マージした後のデプロイ前の救でバグが
8:36見つかったって言って手戻りをするである
8:38とか、ま、そこで見つかればまだいいん
8:40ですけど、本番まで行っちゃうとその、ま
8:42、ロールバックとホットフックスすげえ気
8:44を使いながらエンジニアを作業するし、ま
8:46、コンテストスイッチも発生するし、お客
8:49様にもご迷惑をかけてしまう。ま、これが
8:511番難しいですと。で、そうなってくると
8:54、まあ、1番最後までこうのスピードが
8:58上がるかってと、結構厳しいと思うんです
9:00よ。なんならそのバグが増えてしまうと逆
9:02に信用を既損して下がるまであり得ると、
9:05ま、ちょっと極端な例ですけど
9:08なので、こう全体を本当に1番最後の活正
9:13を増やそうとするとこのプロセス全体で、
9:15えっと、最適化を考える必要がありますと
9:17。えっと、ま、エンジニアでその
9:19パフォーマンスチューニングとかすること
9:21あると思うんですけど、あれってこう見え
9:23てるボトルネックを1個潰したら別のとこ
9:25にボトルネック映るんですよね。なんか
9:27DBを早くしたと思った次
9:28アプリケーションサーバーのCPUが
9:30ネックになるみたいな。同じこと多分
9:32起きると思うんですよ。実装ボトルネック
9:34解消したらなんかレビューの方にボトル
9:36ネックが映りましたみたいな。なので、
9:38えっと、本来多分ここは全体の目線で最適
9:41化を考えていく必要がありますと。
9:45で、ま、やっぱAIコディングで実装
9:47スピード上げるって大事なんですけど、ま
9:50、最終的にはその会社としては最終的な
9:52価値が、ま、増えないとあんまり意味が
9:54ないと。で、ま、実装だけじゃなくて
9:57プロセス全体をどうしていくか、ま、企画
9:59段階かもしれない、デザインかもしれない
10:00。ま、設計、レビュー、テスト、ま、
10:03いろんなプロセスがあると思うんですけど
10:05、そういうのがAI時代にどうなっていく
10:07かっていうのを、ま、これ僕は考えたら
10:09面白いんじゃないかって思ったんですよね
10:10。これからのソフトウェア設計って何なん
10:12だろうとかで、そういうのってこう、ま、
10:15僕ら、ま、僕はソフトウェアエンジニアな
10:17んですけど、ま、それ以外のいろんな
10:19フェイズを見れる専門家みたいな人とか、
10:21ま、広い範囲を見れる方ってやっぱ
10:23いっぱいいるので、ま、そういう人たちを
10:25交え、人たちを交えて、ま、議論すると、
10:28ま、絶対面白いよねっていうのが、ま、
10:30このイベントで僕がやりたかったこと、僕
10:33が言い出した理由ですと。で、えっと、
10:35それをするために、えっと、今日はおさ方
10:37、えっと、来ていただいています。で、後
10:40で入ってきていただくんですけど、えっと
10:42まず、えっと、Tさん、
10:46ま、やっぱこうテストのライオンとかを見
10:48た方、見たことある方多いと思いますし、
10:51SQLアンチパターンとか、ま、読んだ
10:52ことある人も多いと思うんですけど、ま、
10:55やっぱソフトウェア工学、ソフトウェア
10:56設計とか、ま、テストとか、ま、そういう
10:59開発プロセス全体における、ま、専門性を
11:02いっぱい持っている方で、えっと、あとは
11:04伊藤屋さん、えっと、ま、一級さんの
11:07CTOということで、こうそもそも事業
11:09会社のCTOなので、ま、考えることは
11:12当然多いし、1番最後の事業価値のことを
11:151番考えている方ですと。で、ま、規模の
11:18サービスの開発とかそれを長期で運用した
11:20経験もすごい豊富なので、もうその視点
11:23からもいろんな地見を、ま、聞けると
11:25すごい楽しいかなと思ってお声がけをさせ
11:27ていただきました。で、あともう1人、
11:29えっと、山口絶平さん。これレアXのQA
11:32エンジニアなんですけど、ま、QAエンジ
11:35リングってすごい専門的な領域なんですよ
11:37ね。ただのテスターテストをしていくだけ
11:40じゃなくて、こう開発プロセス全体で品質
11:42を保証するためにどういうことをする必要
11:44があるか、どういうあるいは基盤が必要か
11:47、どういう意識が必要か、ま、そういうの
11:49専門家、ソフトウェア解説プロセスとか
11:51品質保障の専門家として、えっと、ま、
11:54面白い話をしていただけるんじゃないかと
11:56思っております。で、えっと、ま、改めて
11:59このおさ方を4及び、えっと、ま、結果
12:02そのAIが来た世界でプロダクト開発って
12:06どうやって変わ、どう変わっていくん
12:08だろう。で、あるいは、ま、僕らはどうし
12:10ていきたいんだろう?どうあるべきなん
12:11だろう。で、ま、あとボトルネックとか
12:14あると思うんすけど、そのボトルネックを
12:16どう解消できるんだろう?もしく解消でき
12:18ないんだったらどうあるべきなんだろう?
12:20なんかみたいなそういうちょっと中小度
12:21高いんですけど、いつもよりなんかこう
12:24いう風に構造書くとイオネよりは1段階
12:26抽象的な議論なんですけど、ま、そういう
12:29議論を、ま、これせっかくの機会なので、
12:32ま、できるといいかなと思っております。
12:36ということで僕の導入セッションはここまでなのでお参方に来ていただいて来てただけますか?ちょっと振り方考えてなかった。冷静に考えたら紹介してる時に出て欲しかったですね。
12:43[笑い]
12:50ごめんなさい。
12:51[拍手]
13:03はい。ありがとうございます。
13:05では、えっと、スライドを戻して、
13:08よいしょ。
13:11もう僕はこっからなるようになれで面白い
13:14議論が聞けたらいいかなと思っているので
13:16、えっと、特に映すものがないので、
13:18ちょっとこれ出しときますね。
13:21はい。では改めてよろしくお願いします。
13:25よろしくお願いします。
13:28ふう。
13:29そうですね。ちょ、ちょっと口乾いたから飲ましてください。はい。えっと、ちょ、冷静に考えてさっきのスライド出しといた方が便利だったな。よいしょ。い、では始めさせていただきますと。
13:54で、えっと、ま、まず、ま、僕たち、ま、レックス、僕は爆落事業部で、ま、事業会社で事業プロダクト作ってるエンジニアとしてはやっぱりこうなんだろう、事業会社の
14:05CTO
14:05としてちょっと名古屋さんに、ま、どう実際変わってますか?なんかどうなってますっていうのを聞いてみたいんですけど
14:11はい。
14:12いかがですか?
14:13あ、入ってますか?大丈夫。
14:15えっと、あ、一級の伊藤です。よろしくお願いします。
14:19えっと、ま、あの、まず前提としてうちの
14:22会社ももうそのAIツール、フロード
14:24コードとか、ま、最近あとコデックスとか
14:26ありますけどを使うのがもう当たり前に
14:28なってます。
14:29で、あの、一時期は結構なんでこのクロードコードどうやって使うかみたいのみんなでディスカッションしたりしてワイワイやってたんですけど、最近はもうなんか結構当たり前になってきて、あんまりそういう会話も
14:40車内であまりしなくなっていて、普通にこう、
14:43エンジニアのデスクに行って画面見ると普通にその、
14:47そういうので開発してるみたいな状況にまずまずなってます。
14:49うん。
14:50で、じゃあそれを経営者としてその状況でこう会社のさっきアウトカムってやりましたけど増えたかと言われると、ま、結論増えてない。
14:59増えてない
15:00ですね。
15:01うん。ま、もしかしたらその
15:0310%20%
15:04ぐらいもしかしたらその開発スピードが早くなってるみたいなことは起きてるかもしれないんですけど、なんてかその例えばこれまで
15:111ヶ月かかってたものがその3
15:13日で出来上がってくるとかなんか
15:155人かかってたものが1
15:16人で住んでるとかっていうのはあんまり
15:19うん。
15:19起きていない。
15:20で、あの、例えば、あの、営業さんが使う簡単なツールをそのクロードコードで
15:261
15:26日で作りましたみたいな話とかは車内でポンポンポンポン色々あるんですけど、その
15:321
15:32級コの本体のその結構深いところに手を入れるみたいな開発でそういうことが起こるってことはまだ起きてないです。
15:39うん。うん。
15:41なるほど。ありがとうございます。
15:43それはそうですね、新規プロダクトとかというよりは
15:461級.com
15:47のその、ま、コアのところというか事業価値の
15:50中心で我々バレの場合、まあ当然ですけどその既存のこう結構大きなもう
15:5520
15:55年ぐらいかけて作り続けてるシステムがあってそれの変更っていうのがそのあのシステム開発の
16:029割5部ぐらいのテーマなので
16:05もう新規で作るってことは
16:07その年に1回あるかないかなんです。
16:08うん。
16:08なのでそれにどうやってその
16:11AI
16:11エージェントツールを適用していくかっていうのがテーマになるからなんかいわゆるその新しくプロダクト作る、スクラッチから作るみたいな議論と全然違うんですよ。そのテーマがうん。ま、それもあってうん。
16:23そこまででもないなっていうのが、ま、随張うん
16:25です。
16:26ただあの現場のNG
16:27のみんなに聞くと生産戦上がったって言うと聞くと多分全員上がったって言うんです。
16:32ああ、みたいな感じです。はい。
16:35面白いですね。
16:36若干その認知にギャップがあるというかなんですね。
16:40はい。
16:42質問いいですか?あ、あ、すいません。レア
16:44X
16:45の山口と申します。えっと、逆にその伊藤さんの立場からすると
16:49変わってないけど使い続けてまいかって思わってる部分があるわけですよね。そこってどういうとこなんですか?
16:57はい。
16:57と、それは多分エンジニアの皆さんがその生産性を上がったと言っているのは、えっと、いわゆるその開発スピードが上がったとかではなくて楽になったってことを多分言ってるんですよ。
17:08うん。
17:09だから今までだったらなんか例えばほんのちょっとしたコード書く時にうんってなんか
17:131
17:13時間どうでもいいことで詰まってたみたいなあ、ここタイプあったみたいな見つけるのに時間かかったみたいなことが多分なくなってるじゃないですか。
17:21うん。
17:21だからまあ多分みんなのその作業負荷は下がってるんだと思うんですよ。
17:26ま、であれば、ま、とりあえず使ってればいいんじゃないのっていう感じで、ただそれがその
17:30劇的なこう
17:32品質改善であったりスピード開発速度の向上には繋がっていないってのが、ま、とりあえず現状かなっていう気がします。はい。
17:40あ、
17:41ありがとうございます。
17:43それてっぺ平さんとか裸館なんかありますか?
17:46ああ、そうですね。僕は、ま、それこそ
17:50プロダクト皆さん書いたコードとかを
17:52テストしたりとかそもそもそういうのは
17:54どうなってんのかよく見たりする立場では
17:56あるんですけど、僕から見ても
17:59そんなになんか劇的に変わった感じはなく
18:02て、そのもちろん高等が気持ち増えてるん
18:07ですけど、その雑な増えてる感覚は正直
18:13あって、ま、気をつけないとこれ
18:16は、あの、今はいいんだけど、今後メンテするの結構大変になるかもなっていうのがある感じがするコードがありますね。はい。
18:27ふん。ふん。それはなんか開発してるできたもののプロダクトがコードを読んだ感じの印象。
18:33ま、コードもそうですし、あと開発者と話してみると
18:37うん。うん。
18:38あまりなんかどうなってるのの時にみたいなのが出やすくな、従来より出やすくなったかなっていう感覚が少しありますね。
18:48うん。なるほど。ちょっと会場にもたまに苦にしい顔してる方がいらっしゃるようですか?
18:52[笑い]
18:56あ、そういうのってどうやって対処していくといいんですかね?めっちゃオープクエスチョン突然ぶん投げちゃうんですけど。
19:04ええ。
19:04やっぱこう僕ら結構今までてそのソフトウェアの品質、ま、いい設計にするぞとかなんかテスト書いてすごい壊れにくいプロダクトにしていくぞって結構考えてたような気がするんですけど、なんかそこで考えてたことと今の今の話の現状って
19:18なんかちょっとずれてるじゃないですか?
19:20あ、そうですか。
19:21なんか方向ちょっと変わったって。
19:23ま、方向というかですね、僕の感覚からすると安きに流れるっていう言葉で多分集約するのかなと思っていて、そのやっぱさっき伊藤さんおっしゃってた楽なんですよね、事実。
19:38で、それにやっぱ乗りたくなるのは多分人間の設理だと思ってて
19:43うん。うん。
19:44え、わざなんかそこで考えなさいよっていうのをなんかしんどい位置じゃないですかなって僕は思ってます。
19:52ああ、なるほど。
19:54なんか、あの、同じシステムの中でも、あの、ある程度コードの変が、ま、雑でいいとは言わないけど、そこまで求めない部分と
20:03うん。
20:03あの、ここはちゃんとやらなきゃいけない部分ってのがやっぱ存在するんですよ。特に我々のようシステム。例えば我々のその料金を計算するとか予約を取るみたいなところのコードが結構適当でなが入ってバグを起こすとすごい大変なんですよ。
20:17特にその料金算間違ってると
20:20あのリカバリーをしなきゃいけなくて全部お客さんに連絡してみたいななんか一方でそのフロンテンドのユーザーが触るそのなんてかユーザーインターフェースのコードとかはまきあのごちゃごちゃだと困るんですけどまある程度そういうその品質に目を潰れるところがあって
20:34で現状その
20:36UI
20:36の生成とかそういうところの部分は結構その
20:39AI
20:39エージェントが有効に使えているうん。ただまその行動の品差多少下がってるみたいな部分は
20:45まやっぱりあるかなっていう気はします。
20:46うん。うん。
20:47なんかそこはもうなんていうかなんか割り切って受け入れてもいいんじゃないかっていう感じ
20:54ああ
20:54ですかねうんの品質がま全部言い訳けじゃない部分的には下がっているがまあ大丈夫というか大きな悪い影響はないんじゃないかといううん。いや、例えばそのもっとミクロの話するとそのデザインをえっとデザインフィグマからえっと実際に
21:11UIを作る時ってCSS
21:13に落とし込なきゃいけないじゃないですか。
21:14だけど最近みんなテイルウンドウ使ってて別にあそこ綺麗に書こうなって人誰もいない。
21:19はい。
21:20うん。それはなんかみんなそのそこ一生懸命そのメンター部にあの頑張ったところで大してそれこそアウトカムがないから
21:26もうテールウィンドみたいなもんでいいと
21:28いう風にこう多分やっていてだそこはある程度その割り切りでそのぐらいでいいという風にその品質をうん
21:35担保するじゃないですかぐらいで
21:37みたいな話とそのAI
21:39のその噛み合う領域が結構似てるんですよ。
21:41ああ。
21:43だからそこでだからトータルで言うと僕らの場合ただその時間がかかるのはそういうその
21:47UIの生成とかそっちじゃなくて
21:49うん。うん。
21:49やっぱりその業務ドメインの深いモデリングモデルのところの変更にすごい時間がかかるしテストも時間がかかるから
21:55そこにまだそのAI
21:55エージェントそのそん公開に適用できてないみたいなのがトータルで言うとそのスルプットが大きく改善してないとこの原因だと思うんですよ。
22:01うん。ありがとうございます。
22:05でも今の話だと逆にその今までま、ある
22:08意味手こう抜くとは言いませんけど
22:11ちょっと弱めても良かったままフロント側
22:13とかそういうところを弱めて代わりにそう
22:15いうモデルとかすごい重要なロジックに
22:18エンジニアが頭を使えるようになった
22:19みたいなのはポジティブな変化ではあるん
22:22ですかね思うですかて思うですかAIに
22:27書かせたり要件定義をさせて時間が開き
22:30ました。
22:31じゃあその空いた時間をより本質的な課題に使おうってみんなが思ってくれればいいんですけど、みんなじゃあ時間空いたら倍仕事するかつったらしないじゃないですか。そうはならないんですよ。みんな楽になったなって言ってインスタ見たりコーヒー飲んだりそしてあ、今日
22:471
22:47日いいつもより楽に仕事が済んだらハッピーだって言ってその
22:50QLが上がってるんです。
22:51ああ、なるほど。
22:52でも会社のアウトカムはさほど増えてないってのが多分現状だと思う。
22:56うん。だ演者のみんなは多分ハッピーになってるじゃないですか。トータル。
23:00ああ。
23:01ちょっと耳が痛すぎてちょっと
23:04だって倍働いたら倍給料もらえるわけじゃないし。
23:07ま、確かにそうですね。
23:08なんでま、そこ今今んとこはそこまでそういう強いセティブが働いてないって。
23:13ふんふんふん。
23:17ん、
23:18浸透してしまった。いいのかもっと受けるかと思ったらさ。
23:22じゃあ逆になんかその
23:25このAIコーディングの流れとか、ま、今
23:27作られてるAIがその事業にを加速させる
23:31ようになるためにはなんか逆になんかどう
23:34いうものが足りないそれが実はなし得ない
23:37とかもあるんですかね。なんかその辺どう
23:39考えてるかおさん方お聞きしたいです。
23:41なんかありますか?
23:45僕喋てる。あ、じゃあ、僕喋る。
23:48え、まずまずまず思ってることはちょっとまだ早すぎるんですよ、評価が。
23:53うん。
23:53そのAI
23:54エージェントによって開発が良くなるかどうかみたいなというのはトータル最終的には多分開発のスピードが早くなったってことはそんなに重要じゃない
24:04うん。くなると思うんですよ。それは過去その僕らがそのオープンソースのソフトアを使った、クラウドを使った、ま、あるいは何でも、ま、リアクトが出てきましたみたいなことでみんな生産性が上がったと言うじゃないですか。
24:16だけど実際はえっと
24:1820年前より今の方が
24:19Webアプリケーション1
24:20個作るのに時間かかるようになってるんですよ。
24:22うん。
24:23分かります。昔はそのネットサービス
24:251
24:25個作るのに例えば僕はテナブックマークってサービス作りましたけどあれ
24:281週間で作ってしてるんです。
24:29すごい。
24:30で計なんか3日で作ってる。でも今その1
24:32週間でネットサービス作ってできなくて大体どんなサービスも
24:363
24:36ヶ月とか半年ぐらいかけて作るじゃないですか。だからみんななんかスピードを上げるためにそのそういうそのソフトの部品を作ったんだけど実際に逆のことが起きている。
24:45うん。
24:45じゃあ何が変わったかっていうと、クオリティが上がってるじゃないですか。
24:48今昔よりもそのもっとそのアプリみたいにグリグリ動くアプリケーションだし大規模にスケールしているしだからどっちかというとそのテクノロジーの進化はその開発のスピードの方じゃなくてその後のそのクオリティとか世の中のその常識のそのラインを上げるってことに多分その相当なインパクトを与えるんですよ。で現状はまだそのそんな社会的にそのマクロに見てまだその
25:11AI
25:11エージェントのそのコードのあが確になったこと結果が出てない。
25:15ないからどのぐらいその常識感が変わるか
25:17と僕ら誰も分かってないんですよ。うん。
25:20でもいつか多分なんか5年前ぐらいを
25:22振り返るとじゃない5年後かわかんない
25:25けどそのぐらいのタイミングであもう
25:26世の中このぐらいのソフトのクオリティが
25:29ユーザーようになってるからこれを作るに
25:31は多分AIを使わないと無理だっていう風
25:33な時代に多分なるんですよ。うん。
25:35うん。その時に初めてAIエージェントが
25:38入ってきたこと意味が分かること。ああ
25:41うん。
25:42ま、これはさっきリアクトの話したけど、リアクトで宣言的
25:45UI
25:45が作れるようになったからって言って、その瞬間からその世の中が大きく変わったわけじゃなくて、でもあれから
25:5110
25:51年ぐらい経って、今なんかシングルページアプリケーションで動くアプリケーションがもう普通にその辺に巷に溢れていて、何の不思議もないじゃないですか。ま、多分そういう変化が起きる。うん。そこが事業会社にとっては
26:00[音楽]
26:021
26:02番その重要だし、怖いところだと思います。
26:04ふん。ふん。AI
26:06が入ったことで、ま、今その直接速度が上がるとよりは同じ速度で出せるクオリティが変わってくる。
26:14てか分からない。どういうその負荷の提供の仕方がこれからソフト回されていくかまだ分からないんで。
26:21うん。あ、確かに僕らが今まだ知らない何か別の作用が起きるかもしれない。
26:26そうです。で、例えば一言うと僕らその最近あの
26:291級.com化したんですよね。
26:31うん。で、これ今回のそのAI
26:33とツールの話だ、どっちかというとAI
26:34活用の方なんですけど、
26:36ま、要するにそのAI
26:37だったらそのデータベースにあるデータ全部日本のやつをその
26:40AI
26:40で全部翻訳すれば国際化サイト簡単に作れちゃうんで、
26:44あ、もう国際化してるんですよ。で、やってみて思ったことはすごい簡単なんですよ。
26:48うん。
26:48で、そうすということは例えば例えばですよ、ウェアブリケーションフレームマークにそもそもその国際化の機能自体がもうビルトインされるようになるかもしれないじゃないですか。
26:56AIがって。
26:57うん。
26:57だからなんかウェブアプリ作ったら勝手にその他語対応してくれるみたいなプレマークが出てきたら多分それによってそのサイト作ると今まではそのこう日本に閉じてたアプリケーションが簡単にそのグローバル対応するみたいなことになってだからそういうことが色々起こるじゃないですか多分これから
27:14うん。
27:14そうなってきた時に多分世の中のその常識は変わるですよ。え、なんでこれって日本語でしか使えないの?みたいな
27:20うん。
27:21アプリが
27:22うん。
27:24そういう変化が起きるのがまだこのこれから先だろうなと思っていて、今まだその本当
27:281
27:28番最初の段階気がします。うん。うん。うん。確かに。確かに僕らはまだ
27:33AI
27:33のことも何もわかんないし、この世界のこの後のこともわかんないわ。確かにそれはそうだなって思いました。こあと二方なんかありますか?
27:42Tさんとか。
27:43えっと質問は何でしたっけ?
27:46はい。あの、今の時、
27:48えっと、AI
27:49でその、ま、品質とかなんか事業
27:53に対する影響、ま、今すぐは出てないってなったとして、じゃあこの先なんかどういう風に変わっていくのか、ま、あるいはなんかうん、
28:01もしくは変わらないのかもしれないし、何が変わるとじゃあ影響が出るのかとか、ま、そういうことをちょっと考えていることとかがあれば
28:08そうですね。
28:09えっと、そのだと
28:11AIAもうは出て半年ぐらいですかね。
28:14だいぶみんな使うようになってからで、最初の
28:171
28:17ヶ月ぐらいみんなあのすごいフィーバーしていて、で、今どっちかっていうと厳滅鬼に入ってるっていうか思ったほどのものではないなという感じに
28:26なってい、あの難しいところもあるなみたいな感じになってると思ってて、で、だけど最近考えるのはその
28:33AI
28:33と一緒にあの行動書くとかソフトア作るとかはあの最近いろんなとこ見て思うのはそのソフトエンジニアじゃない人がソフトウェア
28:43をサクっと作れるようになったっていうことのインパクトの方がでっかいなと思っていて
28:48うん。
28:49あの従来だったらソフトエンジニアに頼まないと何かえ、あのやりたくてもできなかった人たちが割と自分
28:581
28:58人が使うソフトアっていうのを作るようになってきているんですね。
29:02で、実際僕が見てるところでもその
29:05たくさんの自分しか使わないソフトウェア
29:07が生まれ始めていてで自分自身の問題解決
29:12を自分自身で行うみたいな感じになってき
29:14てるのでそういうそのなんかAI
29:16エージェントって僕らつまりソフト
29:18エンジニアが使うもんだと思ってたんだ
29:20けどあの社会的なインパクトがあんのは
29:22ソフトエンジニア以外の人が使う方が
29:25明らかに社会的なインパクトがあるなと
29:28いう風には思ってて、まだそこまで全然
29:30言ってないんですけど、あのた
29:34見るからに小規模住宅案件ってやつは減ってるんですね。
29:38うん。
29:38あれでもそれはそうかも。
29:40そう、そう、そう。あの、つまり、えっと、予算はそんな大きくなくて回復機関も長くなくてで、えっと、依頼者が
29:471人でで、受注者も1
29:48人ぐらいの感じのところで、従来なんかなんだろうな、なんかサクっと作ってた、あの、リアクトでサクっと作るとかレールズでサクっと作るぐらいの規模感の案件ってやつはめちゃくちゃ減り始めて、な
29:59んでかって言うとそれは発注者が作れるから。
30:02ですよね。
30:03でも発注者が作れる方が自分が
30:051番あのなんてか2人2
30:07人でも電言ゲームは発生するんです。当たり前だけど。
30:10だから自分が欲しいものっていうのを自分
30:12で作れてでフィードバックサイクルもあれ
30:14でなんかうまくいかないってところだけ
30:16エンジン頼むみたいな感じであればもっと
30:19ずっとソフトウェアウェアを作る人が
30:22増えるでソフトウェア作る人が増えれば
30:24ソフトウェア作るとはどういうことかって
30:26いうのを理解肌感覚として理解してる人が
30:28増えてもうちょっとなんだろうな世の中的
30:30にはその発注の制度とかえっとプロダクト
30:33マネージャーのえっとビジョンを
30:35エンジニアに落としてくる時のえっと摩擦
30:38コストとかそういうのが下がってくると
30:41いいなとは思ってて、そうするとソフト
30:43エンジニアの世界にも還元されてくるとは
30:46思いますと。
30:46で、世の中のクオリティに、ソフトウェアのクオリティに関する意識としてはなので、えっと、人がソフトウェアを触るようになるとクオリティソフトアの質に対する評価自体は全体としては下がると思っていて、
31:03下がるっていうのはこのこの程度のソフトアで良い、
31:06この程度の問題解決で良いっていうものがたくさん裾が広がるので全体のその質のあの体感としては下がる。
31:16うん。
31:16で、企業のソフトに対する質の期待感としては、だから個人が作れる以上のものをちゃんとやってくれっていうので上がるっていうんです。そのがバーっと広がっていだきは高くなる。
31:26だからソフトエンジェンの仕事はもっと辛くなるみたいなそんな感じのところかなとは思ってます。
31:32うん。
31:33今の質、その下がってくる質っていうのはその、ま、バグの量とかという、
31:38あ、児の品質のことですね。用児の品質のことです。
31:40うん。
31:41の、ま、期待値が、ま、下がってくるそのが広がって、
31:45ただ僕らプロフェッショナルとしては、ま、よりハードな、え、そんなとこプロなのに壊れちゃうのみたいなのを思われてしまうとかはあるんですかね。
31:55うん。もあるし、まあ、いや、この程度であれば良いよとか、この程度あれば自分でなんとかするよというようなそのうん。そうだな。
32:03その社会全体としてうんとんに日本はどちらかというとその品質にこだわりのある国と言われていて
32:06[音楽]
32:15うん
32:16でその品質へのこだわりがいいところもあれば悪いとこもあるみたいな感じで作用してきましたと。
32:22うん。で、それはその品質の評価自体が
32:28あの、ま、仕組み上なんだろうな、日本の
32:32国民性として結構その品に対するあの
32:38望みが高いとかそういうのがあって今の
32:40自動運転とか色々壁に当たってるわけです
32:43よね。うん。ってのでその
32:45辺りのそのなんか自分で作ったらどうだ
32:47から今のソフトウェアに期待できるのは
32:49大体このくらいみたいなところのその品質
32:52の肌感覚みたいなのがもうちょっと全体と
32:54して下がっていくと企業としては挑戦し
32:59やすくなるのであの裾は広がるし挑戦の口
33:04は増えるのでそちらの方がいいかなと
33:06は思ってます。
33:08挑戦の口が広がる技からスタートアップが新しい問題を解決するとか僕らが進品質所の品質がものすごく高いものが求められると利用所の品質高いものが求められるソフトア開発をするのは本質的に難しいのでえっともう少しなんだろうなバラつきのあるソフトアがでもたくさんできるとかの方がま対多様性はあるかなとは思います。
33:35うん。ありがとうございます。
33:38今のお話でちょっとあったのがその、ま、
33:40僕らが作ったプロダクトとかで、ま、なん
33:43か、ま、今ちょっとちょ宅っぽいというか
33:46例えになっちゃうんですけど、ま、気に
33:48なるところがあったらその発注元が、ま、
33:51ちょっと直してちゃうよねみたいな
33:52ちょっとそのエンジニアリングの、ま、
33:54民主家に近いことが起きるみたいな話が
33:56あったんですけど、それって多分事業会社
33:58の中でも同じような構造はある気がするん
34:01ですよね。そのデザイナーとかPDMが
34:03その最後の生物見て、あ、ここちょっと
34:05こうした方がいいよねって思ったのを、ま
34:07、自分で直しちゃうみたいなのもあると
34:09思うんですけど、なんかそういうのがこう
34:11いろんな人が、ま、
34:13その同じ大きなソフトウェアを触る人の
34:15バリエーションというかが豊かになる世界
34:18で、なんか僕らエンジニアとしてはなんか
34:20こういう風に気つけてた方がいいよねとか
34:22、ここ危ないよねとか、なんかそういう
34:24のってあったりしますか?今あの
34:27デザイナーがうちの会社はそのう
34:31ロードコードかな使ってプロダクションのコードを修正するってことはやるようになりました。
34:37うん。
34:37おお。
34:38ただ、ま、もちろんその大規模な修正は無理で
34:40うん。うん。
34:41ただほら、あの、あそこ本当はもうちょっとボタンをこういう風に動かしたいんだけどとか本当はあそこにこういうトランジション入れたいみたいな、でもエンジニアにお願いしないとそもそもデプロイが
34:51できないみたいなのよくあるじゃないですか。だからそういうのはもうデザイナーがプルリクエスト作ってエンジンがレビューしてマジするっていうので
34:58できるようにはなってきましたよ。
35:00うん。
35:00ただ、ま、そのデザイナーのその先にいる
35:03例えば、ま、営業の1
35:04社員とかマーケの人がプロダクト開発に参加するみたいなことはさすがに起きてない。うん。
35:09うん。
35:10で、デザイナー、あと、ま、ディレクターぐらいだったら多少のことは参加できるみたいな感じ。あ
35:16あ。
35:16うん。ただプルリクやっぱ大きくなってきた時にちょっと問題が出ますね。
35:20ああ。
35:21うん。そのコードの品質誰が担保するのかっていうでちょっと忙しいからできる。
35:24はい。うん。
35:25あ、それ実際そのデザイナーとかディレクターの方が結構大きめだというか変更規模が大きいプロリ陸を
35:32投げてくるちゃう時がある。え
35:34え。
35:34うん。だからエンジンあるとやっぱりそのこの変更だと大体どのぐらいの規模の変更になるかって事前に見積もれるんだけどデザイナーさんだとそこは分からないからとりあえずやらせてみたらめっちゃその後の変更き多くなりましたと。
35:46でイナーさんから見るとコードの変更量が大きいけどあの実際にはエンジニアにとっては
35:512
35:51行だっていうケースもあるじゃないですか。
35:53はい。はい。
35:53あの、アセットがただ変更されてるだけでっていうのと本当にでかい変更っていうのは区別がついてないから、
35:59とりあえずエンジア投げてくて、いや、これちょっとさすがに大きいみたいなやり取りがされてるみたいな感じです。うん。
36:04[音楽]
36:05でも、ま、そのやり取りをの中でフィルターされた簡単な変更みたいなどんどん反映できるようになってきてるんでうん。そういうことは起きてるっていう感じです。
36:13うん。うん。
36:14ありがとうございます。なんかこうそう
36:17いう方々がコード変更入れてくれるのは
36:19すごいポジティブで、ま、それこそ、ま、
36:22プロダクトのなんか細かい優しい改善とか
36:25、ま、エンドユーザーにとってはやった方
36:26がいいんだけど、エンジニアコースの大変
36:28みたいな優先度が列合しちゃうものとかが
36:30さけるという意味ではポジティブな一方で
36:32、なんかでもそういう大きいのが増えて
36:34くると結局それは周り回ってレビュー
36:36コスト増えて最初からエンジニアがやった
36:39方が早かったのでみたいな問題も起きそう
36:41な気がするんですけど、そういうのって
36:44どうしていくといいんでしょうね。めちゃめちゃまたオープンになってしまいましたが。
36:51いや、その解決策分かったらあったら教えて欲しいって。いや、難しいんじゃないですか、現状は。うん。
36:53[笑い]
36:57うん。
36:58実際のチームでもテックリードみたいがやなんか
37:01AI
37:02にかせたこのままプリク投げるなってこと怒ってましたよ。それ僕も似たようなこと今日言いかけました。
37:10ええって。
37:13そうですよね。結構なんか分からないですよね。分からない人から見るとこれが本当にいいなんか問題ないのか問題あるのかなんていうのはやっぱりわ
37:25AI
37:26ったからと言ったって分かるわけではないので
37:28うん。
37:29なんかそのままポイって出したくなりますよね。
37:33[笑い]
37:35分かる。
37:36で、その出てきたコードを真面目にレビューすべきか、
37:40AI
37:40に書かせたままのコード投げやがってって文句言って突き返すかを葛藤してる人は車内を見ると特見るのを見かけます。
37:48いや、それでもやっぱ、ま、今の話はこうデザイナーとかディレクター
37:52PDM
37:53の方から来るプルリクから始まったけど、
37:56そう、そう、全部ですよね。
37:58いや、どうするといいんでしょうね。ま、
37:59エンジアとしてもやっぱりこうAIが書い
38:01た行動ざっとざっと眺めていしょつって
38:04出らしちゃう気持ちは、ま、僕もちょっと
38:05分からなくはないんですけど、ま、
38:07やっぱりそう後の人が大変とかは絶対ある
38:10と思うんですけど、そういうのって今後
38:12こうどうしていくといいんでしょうね。
38:15やっぱりこうみんなが自分の行動責任も
38:18自分がAIにかした行動を責任持って読ん
38:21でからプロリ出すべき
38:24ま、現時点はそっちなんじゃないですか。
38:25ま、そのプロのプログラマーとしては人間側がきとそのコードの品質を担保して
38:31レビューは
38:32に負担をかけないようにしましょうって。現時点では多分足元のプラクティスはそっちの方がいいと思うんですよね。ただま将来それその問題自体を
38:39別の方法で解決できるようになるかもしれないけどまだちょっとそれ分からないって感じなですかね。
38:44うん。
38:46ありがとうございます。やっぱりそうっすよね。
38:50ま、あとはそれで結局コードの量が、ま、
38:53エンジーが問題ないって判断したとはいえ
38:55、やっぱAIがすごいコードの分量自体が
38:57多いからやっぱり後のレビューが大変と
39:00かっていう話はま、あると思うんですけど
39:02、ま、そういうのレビューはレビュー
39:04受ける側としてはなんかこうこういう風に
39:06していった方がいいんじゃないかとか
39:09なんかレビューする側の気持ちとしては
39:11なんかこういう風に思っといた方がいいと
39:13かそういうのってあったりしますか
39:20いやいや、そうですね。
39:22まずなんか、ま、僕自身そんなに行動
39:26しょっちゅしょっちゅ、ま、見ることも
39:27あるんですけど、プルリク今のよく見てる
39:31プロダクトプルリクプロディンクなって
39:34いうのはよく聞いてはいるんですけれども
39:36、その、ま、た時の意図とかそういうのは
39:40聞いた上でそっから大体イメージする変更
39:44とか起こり得そうなことっていうのとの
39:47ギャップは僕は見てますね。なんかこんな
39:52簡単。さっきのボタンちょっとずらすだけ
39:55なの。なんでこんなに変わるんだっけって
39:56多分皆さん思われてるし見る時すぐ感じる
40:00と思うんですけど、そういうのは見てるか
40:02なと思いますね。あとなんかあるのかな?
40:08レビュアーとしての意見。
40:10けどなんかレビアとしての意見じゃないんですけど、そのまま
40:16AI
40:17コーティングツール使ってやってるのはいいんだけどテストはってよく聞いてますね。
40:23テストテストコードだけんじゃんって言った時の反応とかも時々言うようにはしててそこでなんかそのテストとして何が考えられてるのかなっていう、ま、レビュー
40:37E
40:37の方が何を見るべきかっていうのは理解されてるのかいのは聞いたりはしてるかな。
40:44そこでなんか、ま、遠いた回答がない時とかは結構気をつけるっていうかやばいかもしれないなって思ってそれを見るとかはあるかなって感じですね。
40:55うん。
40:57あります。お2人なんかレビューE
41:00レビューアとしてなんか
41:02レビューアとしては
41:04AI
41:04が書いたコードがどうとかじゃなくて、えっと、ちゃんとモデリングをしてくれっていうことの方が大きいんですけど。
41:12ああ。
41:13うん。で、なんかちょっとそのAI
41:14エージェントの話になるとみんな実装の話ばっかりしてるじゃないですか。
41:18うん。
41:19でもやっぱりその繰り返しになんですけど、やっぱ僕らみたいな大きなその業務システムになるとその上のモデルのせ、モデルが大事なんですよ。だ、実装じゃないんですよね。で、そのモデルをきちんとトレスした実装になってるかどうかってことがレビューの時最も重要な
41:35ポイントなんですよね。
41:37だから全然そのモデリングをせずにコードの変更だけしてできましたってプルリック投げてきたらもうその時点で却下なんですよ。
41:44おお。
41:45いや、これはモデルにどういう変更を加える意図のコードなのかっていうことに答えられないじゃないですか。
41:50うん。
41:50で、現状はそのモデルの変更自体を
41:54AI
41:54にうまくそのやらせたところで、えっと、そのモデルにどう変更を加えたっていうことをちゃんとその人間が理解してることが最もその重要なので
42:03うん。うん。うん。だ、そこにAI
42:04を使ってもあまりその会社としてみがないんですよ。
42:07うん。
42:07うん。それがなんかそのレビューというかエアエージェントを使う時の結構その現状乗り越えられない壁っていう風に思って、で、それがだからレビューの時もその観点が出てくるって感じです。
42:19うん。うん。
42:19分かりますかね?
42:21分かります。なんだ、その、ま、人間か、ま、
42:24AI
42:25と相談してモデルのそのモデルを上流するならまだ分かるけど、
42:29AIがバイブスでモデルを変更するのは
42:31うん。そうなんですよ。
42:34人間がそのモデルを理解するとかモデルに対する変更をどう考えるべきかって概念を整理するのに
42:39AIを壁打ち相手に使ってるってのは
42:41うん。
42:41それはすごくいいと思うんですよ。で、それ多分みんなやるようになってきて昔よりも議論の質が上がってるなとは思うです。うん。
42:48ただですよ、チーム活動でこと言うとそのモデルの変更に関しては
42:52AIと壁打ちして1
42:53人の中で閉じてもらっても困っちゃうんですよ。
42:56確かに
42:56モデルはみんなで共有してるものなので。
42:58だからちゃんとチームでディスカッションした上でその皆そのチームにいるメンバーの関係してる人のメンタルモデルをその新しいモデルに適合させなきゃいけないので
43:07でそこ全然エア関係ない領域なんですよ。
43:10うん。
43:11で、そこが最もそのえっと業務システムにおいては難しいしコアになるので
43:16うん。
43:16まだそこはAI
43:17の影響が限定的っていうのが今思ってることです。
43:21うん。
43:22結果チームでそのモデルを共有するモデルの共通認知を取るところまでが、ま、仕事
43:291
43:29番大事な仕事だからそっちがボトルネックになる。
43:31そうです。で、なんか昨日もちょっとそれで障害があったんですけど、その会社にね。で、それは結局だからそのモデルのことをあんま考えずに割と、ま、
43:40AI
43:40がやったかどうか分からないんだけれどもコード中見て多分ここにこういう処理を入れればあの
43:44CO
43:45実現できるだろうってピッてやったら、まあなんか色々あって
43:48料金計検査間違ってましたみたいな。
43:50あ、具合があったんですよ。だから結局その上側のそのあの、ま、要件というかもっとそのモデル自体をあのちゃんとチームがきちんと隅々まで理解していてそれに対する変更をどうコードにあの加えればえっと権なモデルにできるかっていう
44:07うん。
44:08その議論が大事っていう感じです。
44:10うん。もう確かにもはや
44:13AI
44:13関係ないというかつも通りのその設計の議論テストの議論とかですよね。
44:18そう。
44:18だ、クオリティの担保っていう意味でもそのもちろんその小さなバグをなくすとかいう意味では
44:23AI
44:23にテストを欠かせるとかなんかそういうので色々防げることはあるんですけど、今行ったみたいなところってそれで防げる領域じゃないじゃないですか。
44:29そうすね。
44:30うん。なのでまだその、えっと、適用領域は限定的だなっていうのはその、その点でもそうです。
44:37うん。
44:39ありがとうございます。
44:40もうテストと設計の話が出たということで一旦
44:43T
44:43さんに振ろうかと思うんですけどどうでしょう?
44:46えっと難しい振られ方
44:50あ、だからその
44:52AIが出てきての品質周りでテストりとか
44:55ま結局そうすね僕らの普段今までのエンジニアリング深いエンジニアリングの営みとま変わんないっちゃ変わんないような気もするんですけど
45:04うん。
45:04ま、その上でそのテストとか設計とかを、ま、僕らがどう取り組んでいくのかとか、ま、取り組み方、考え方が、まあ、今まで通りやるのはもちろなんだけど、ま、プラス
45:17AI
45:17が入ったことでそこにちょっと変わることがあるとかあるんですかね。
45:21うん。
45:21あの、そうやと現場レベルで言うと、あの、テストコードがプルリクエストに追加される割合っていうか、ま、テストコード
45:30AI
45:31の重力を得ていう人の割合はめっちゃくちゃ増えました。
45:35で、これはこれまでもテスト書かなきゃいけないとか書かなきゃ怒られるとかみんな思ってたんだけどでもな、学習コストがあるんです。
45:43結局やっぱテストコード書くためにはちょっとぐらい勉強が必要で対象のドメインもちょっと理解してなきゃいけなくてであのコードの分流はそれなり多くてっていうのでなんかやらなきゃいけないと思ってても難しいとかあるいは既存のテストコードのコピフェでごぼちょごちゃやるとかそんなのが
45:51[拍手]
46:01多かったんですね。
46:03なので実装コストも学習コストも20重に
46:05かかってたから、ま、やれって言われてる
46:07けど、そうは言っても難しいよねっていう
46:09ところだったのが、ま、テストコードって
46:12書くもんですよねと。で、テストコードっ
46:14ていうのはこうやって書きますっていうの
46:15はAIの方はもうもう存分に知ってるので
46:19テストコード書いてくださいと言うと
46:21テストコードと一緒に書いてくださいって
46:22言うと書いてくれるようになった。だから
46:25その意味だとうんとハードルを2つぐらい
46:28あの
46:29クリアした状態
46:31にあります。
46:32だから、えっとね、スタート地点はだいぶシフトして、いい方にシフトしました。あとはだから人間側がそれどうやって使うかって話なんだけど、で、じゃあテストコードのクオリティ自体はどうかって言うとなんていうかなん、えっとね、えっと
46:46[笑い]
46:510から欠かせるとあまり良くない
46:53うん。
46:53というとこなんですよね。で、なので、
46:56あの、自分たちのチームでテストの方を作ってで、これを模法してください。
47:01だと模法が上手なのですごくうまくいくで
47:05テストコードが増えすぎるのを抑制する必要があってで、ま、これまで我々の世界ってそのテストコードを増やさずにテストケースを増やすやり方っていくらでも研究されてきたのでそれによってプロダクトコードとテストコードの比率テストコードですよって言うんですけどそれを一定に収めるみたいな感じで式位置を設けてあのなんかテスト書いてくださいって言うと無限にコピフェでテストコードが出てくるみたいのを制御したりと
47:30とか、ま、そういったなんていうか現場
47:33レベルでの取り組みっていうのは色々あり
47:35ます。で、えっと問題になるのはどっち
47:39かっていうとそれによって、えっと謝った
47:42安心感が生じることで、あの、いわゆる
47:46コードカバージってやつはだいぶ増えてい
47:49ます、各現場で。だけどその増えたコード
47:52カブレッジってどうやって増えたかって
47:55いうとAIが力づくで書いたテストコード
47:58とAIが力づくで書いたモック
48:00オブジェクトで、え、カバレジが上がっ
48:03てるんでしたね。で、これ我々の歴史では
48:05その1度ユニットテストに対してすごく
48:09情熱的な人たちがユニットテストを書き
48:12まくった時代に起こったことをなぞってる
48:15んですよ。えっと、具体的は
48:182011年12年、13
48:19年ぐらいにソフトエンジニアの歴史で起こったことを綺麗にトレースしていて、つまりこの後何が起こるかってのは、ま、分かってんですよね。大体あの木オブジェクトのメンテナンスであのだいぶはまることがもう確定していますと。
48:32で、なん、なんでもそうなってるのかって
48:34言うと、そういう歴史を辿どってきて、
48:36そういうソースコードがいっぱいあって、
48:38で、カバレッジを上げるのが良いことで
48:40あるて評価が与えられると木オブジェクト
48:42でカバレッジを上げようとすることが発生
48:45するんですよね。これだから報酬設計の
48:48謝りんですよ。うん。ので、えっと、人間
48:51側がもうちょっとだからその歴史ちゃんと
48:53してなきゃいけないし、何が起こったか見
48:54てなきゃいけないし、木オブジェクトを
48:56使わずに、え、ま、専門用語画で言うと
49:01対象とのこ、えっとね、構造的結合合度を
49:05下げてでもカバレッジを上げ
49:07るっていうつまりうん、身も負担もない
49:09こと言うとユニットテストを書くのが
49:11うまくならないとダメ話なんですよね。
49:14っていうので人間側がやっぱり鍛えられて
49:16いけないわけ。
49:16で、うまいユニットテストを示すとまいユニットテストを模法してくれるので、結構だいぶ嬉しい感じのユニットテストが増えるんですよ。だから
49:25うん。
49:26うんと構図が変わらないんですよね。
49:28あの、プロジェクトって1番最初に書かれ
49:31た品質を薄く薄く伸ばす方向にしか、だ
49:35からプロジェクトがよっぽのことない限り
49:37品質上がることはない。っていうのが一緒
49:40で、あの、示したお手本を薄く薄く
49:43引き延ばので、よくも悪くも、あの、人間
49:46側がどういうお手本を見せるかに、今の
49:49ところはだいぶ影響されてるって感じです
49:51。
49:53なるほど。いや、僕も結構そのAIが入っ
49:56てくるとそうテスト書くハードルが下がる
49:58というか、書いてくるから楽じゃんって
49:59やっぱ思っちゃうんですけど、こう
50:00とんでもない量のテスト入ってくれますよ
50:03ね。その、ま、いいか悪いかは置いといて
50:05。で、ま、やっぱりそうなんか肌感は結構
50:09そうだなと思って意味のない、ま、意味の
50:11ないテストって言うとあれですけど意味の
50:13あるテストを書いてで、ま、それを枠を
50:16作くればケースはケースのはAIはま、
50:20うまい。うん。うん。うん。うん。
50:22だからちゃんと地になるとはあってでだから壁打ちしてどんなケースが必要だと思うとかであのテストコード呼吸せずにテストケース増やすのにはどこをどういじればいいかなとかそういうのは色々相手できるし
50:37あのなんだろうなメンテナビリティテストコードのメンタビリティを維持したままケースを増やすの使用レベルのカバレッジを増やすとかそういうのもできるようにはなってきてるのでその辺はあのだいぶ進化ですね。
50:49うん。
50:50けどそれを逆に指示できないとできないですよね。
50:54てことは指示できる人は分かってる人ですよね。
50:57そう。そうですね。っていう、そう、
50:59トートロジーが若干あるかなっていうか、
51:01なんか分かってるからできるし、できる
51:03からさらに生きるっていうのは少しその
51:05領域あるかなと思って、
51:09じゃあそういうのがまずないところには
51:11どうなのかなっていうとさっきのま、
51:14一般的なのスパイラルが走ってくてのを
51:17考えるとなかなか
51:19厳しいもんがあるなっていうのは思う時は
51:21ありますね。うん。
51:23やっぱり、ま、本当に問ないけど、ちゃんとテストを、まべというかけるようにする。そうですね。そう、逆にそ、ま、教育の話しないとは今日言ったわけですけど、ま、やっぱとかっていうの道具には
51:37いいし、そ、先ほどおっしゃった、ま、ハードルを
51:392
51:40歩下げるとかっていうのにはいいから、そういうのでも本当
51:44使っていく。先ほど、ま、0
51:46から書くのはっていう話ありましたけど、個人的には逆に全くわかんないんだったら
51:530の時に使ってもいいかなと思って。
51:55あ、うん。
51:56一般的な
51:58会は出してくれると思ってるので。
52:00うん。うん。うん。
52:01なんで、ま、他の領域だ設計とか、ま、計画とかでもそうなんですけど、自分が問害感だなって思ったりしてる時にはとりあえずやってみるっていうのは僕結構ありかなとは思ってますね。
52:11[音楽]
52:13それ、それは、そう、そこは
52:15AI
52:15が少しすごいわけです。自分があの最も得意してる言語とかは多分自分で書いた方が早いケースがすごく多いんですけど、
52:23なんかこの言語あんま書いたことないな。でもやんなきゃいけないなっていう時は
52:26AI
52:26にとりあえず書かせて見ながらうん、多分こう直せば大丈夫だろうみたいなのはめっちゃ役たつありますよ。
52:33そういうのはなんかありだなと思うし、ま、見てても有益に使えてるなっていうのは今でも思いますね。
52:41うん。
52:43なんか納得できる反面、その文会感であるってこと認識するのも結構難しくないですか?実はなんかテストとかってそのテストのドキュメントを読んだらかける気がしちゃうんだけどなんか本質的にはあまり良くないんじゃないかみたいな
52:56そこの
52:57いや思えたら書いたらいいんじゃないですか?
52:59あ、書く書いて評価なんか良くないよねいいよねの評価とかってどうするんですか?その書いたものの評価?
53:06あ、けどそれは変な話ですけどさっきの負のダ
53:11ダメージを受けるしか多分手はないと思ってて
53:141回自分であ、これは
53:17しんどい
53:19モックだらけでしんどいメしんどいっていうのを学ぶかま歴史に学ぶとか
53:25そういうのがありかなとは思いますけどね。
53:27一旦痛い目を見るか
53:29うん。
53:30ま、歴史から学んであ、こうするといいんだってで修正をする。
53:34一応あの開発者テストその開発者がテストコード書きながら開発するという分野で言うと
53:41うん
53:41うんとそのえっと目ック地獄の時期
53:4520111213
53:46年あたりを経下手書籍っていうのは出てきているのでまユニットテストかやちゃテストの分野で言うと
53:54あの古典派への会議機っていうのが起こってるんですね。
53:57古典派っていうのは、まあ、なんていうか、あまり目ックオブジェクトを使わないで開発、あの、していける方が良いねっていう、ま、波みたいなもんなんですけど。うん。
54:06で、だから最近出版された本ってのはその古典派が復合、ま、復活してきたの本が多いので、そうするとなんか
54:15うん。そうだな。
54:16あの、歴史から学んで、あの、ショートカットすることはできるので、
54:22その最近出た本たち、古典派の留派の本たちを読むと、その木ック地獄とかは昔あったことで、そこからもうあのリカバリーしてる人たちが書いてる本を学べ最初からそっからショートカットできるので具体的にはだから単体テストの考え方、使い方って本とか
54:42Google
54:43のソフトエンジニアリングとかグッドコード、バット
54:45コーって
54:46本とかその辺りってのがそのうん、ボック地獄以降の古典派復興以降の本なのでその辺り読んでとかこのスタイルでやってこうとかあるいはもうほ、ま、ズバり古典派クラシシシストのスタイルでやってくれでもある程度通じると思うのでやっぱりその辺の合意をと歴史を学んでそうすればだからショートカットはできるっちゃできる
55:08ですね。はい。てことですけどその
55:11それを自針にしろという指示がテストの知識がない人やってない。
55:15そうね。
55:16結局だから分かってる人じゃなければある程度のクオリティのコードを
55:20AI
55:20に欠かせることすらできないという結論に到達するですよね。
55:24あとチームレベルで言うと、だから個人
55:28あのテックリードはその辺のそのテストの
55:30ある程度の方針、テストコード書く方針と
55:33かをまエージェントMDに書いてチームで
55:37共有するとかちょっとしたい底上げみたい
55:39のはできるかなと思うけどでもそれチーム
55:41メンバーが古典派のかわかんないとそれで
55:44やっぱりそこはだからやっぱある程度何ら
55:46かの学習とか
55:48読み合わせとかそういったのはある方が
55:50効果的ですよね。うん。
55:54ありがとうございます。やっぱりなんか
55:56こう岩田さんがたまにおっしゃってるあの
55:58技術の螺線に近い話で、ま、こういうのも
56:01その螺線を描いてなんか戻ってきていると
56:03いうかってことなんか僕らも認識してそう
56:06いうま、学び直しというか先人の知恵を
56:09借りるの結構大事なのかなというのを
56:11ちょっと改めて認識しました。
56:16はい。ちょっとめっちゃ話がどっからここ
56:20に来たんだ。
56:25そうですね。ま、今ちょっとテストの話を
56:27したので、もう1個さっきトピックがあっ
56:28たモデリングとか設計の方もちょっと聞い
56:31てみたいなと思いました。ま、ここもでも
56:34やっぱりその、ま、今まで通りというか
56:36そのドメインにちゃんと潜ろうとか
56:39ちゃんと設計しよう。特に大事なところは
56:42ちゃんと設計モデリングをしよう、モデル
56:44に向き合おうみたいなのが、ま、やっぱり
56:46ポイントになるのかなと思うんですけど、
56:48ま、ここに関して何かもっとこう言いたい
56:50こととか思ってることとかなんか逆に最近
56:54こうなって困ってるみたいなのとかって
56:56あったりしますか?
56:58良かったことはモデルをなんか理解
57:03をするのが楽になったっていう。あ
57:06うん。これはだからAI
57:07に聞くとかあるいはま、既存のコード読ませてこのコードにはどういうはどういうモデルを前提にしてるか抽出しろって言うと敵台みたいなの
57:15うんうん
57:16出来上がってくるんでそれは多分昔より効率的になったかなっていう気はします。
57:20うん。
57:21うん。ただそのAI
57:22が抽出してきたものは大体間違ってるんですよ、残念ながら。だからそれを正しい理解に近づけていくみたいなところはまだ全然その人間が頑張らなきゃいけないみたいな感じなんですよ。い
57:35うん。うん。
57:37ま、でもゼロより始めるよりはだいぶハードルが低いですよね。
57:40そうですね。
57:41人間が最初から全部行こう読むとかよりは
57:43うん。
57:45かな。
57:46うん。
57:47そうですね。怪しい。
57:48間違ってるところがわかんないので、その、その受けた人をこの
57:54AI
57:55が出してくださくれたモデルこんなんですって言われた。
57:59ほうって言ってなるほどって言った後にその詳しく知ってるチームメンバーとかに質問できる立場だったらすごいそれっていいま特仮かなと思うんですけどそれを鵜呑みにそのまま行こうとすると偉いことになるなっていうのは本当そう
58:13いやもう全然全然ですよ大体だからその既存のコードの中からまモデルとやらないけどなこのシステムは何をしてるかドキュメントを書いてくれてで行き上がってきたのを
58:22全然わかんない人が見るとおなんかそれっぽいこと書いてあって結構これいいんじゃないと思うんだけどよくわかってる人
58:28に読ませると全然ダメみたいな。まず全然その細かいこと書いてないし、ここに書いてること間違ってるしみたいな感じ。なんか、ま、そういうレベルかっていう感じなんですよね。ね。うん。
58:37ただ、まあ、ないよりはマしみたいな。うん。何かしらの叩き代があってそっから理解してくって意味ではうん。
58:42良くなりました。ただ逆言うとその程度なので
58:45モデル自体をAI
58:46に変更させるのはさっき話した通りまだ全然難しいです。
58:49うん。
58:50うん。
58:51そもそもなんかなんだろうな、その僕らがやってるその事業のあの業務システムモデルとかま、簡単とテキスト全部表現できるほど単純じゃないんですよね。うん。その図表とかあの資料とかプレゼンテーションとか使ってその理解していくのもなんで
59:07うん。
59:08なんかそこがまだ全然その
59:10AI
59:10の現状と追いついてないっていう感じ。
59:12うん。
59:15あ、それはそのドメインを解釈するのに必要なんかメディアの種類というかマルチモダルになってしまうから今のだと解釈が難しい。それとも単純に取りこぼしちゃうみたいな。
59:27うん。
59:28いや、なんかよくちょっと難しいんですけど、単純にここが足りてないって言えるほど僕もまだふん割りとしか分かってないんですけど、ただ例えば僕らがその
59:381級.com
59:38のあのホテルの料金計算っていうものを普段どうやってそのみんなで理解してるかって言うとやっぱりみんながプレゼンテーション資料を作ってきて、あでもないこうでもないって言ってでそのプレゼンテーションの中にそのいろんなその例えば俺は有効になってとこういうその状態専用をしてるよねみたいなグラフがあったりなんかめっちゃ表があってでそこになんか具体的にう
59:57にこういう場合はこういう風に計算するみたいなその計算のなんていうかこう具体的なて計算なんだ結果が書いてあったりとかっていう資料をたくさんこう見てでみんなで会話をしながらあここてこうなってんのこうなってんのって言ってなんとなくそれで頭の中に抽象的なモデルが飲みその中に出来上がるみたいな感じなんですよ。
1:00:14うん。
1:00:15だからそれを全て言語化することができたらそれはいいんですけどちょっと無理かなみたいな。うん。
1:00:24人間そこまでその言葉で全てを表現してる、受け取ってないっていう感じがあるじゃないですか。
1:00:30チーム活動の中で。
1:00:31うん。
1:00:33その辺はなんかテストしてる立場からしてもなんか時々最終的にいらなくなるんじゃないのみたいな話が、ま、そのドキュメント全部壊したらいいじゃんみたいな話出るんですけど。
1:00:43うん。うん。
1:00:44いやいや、そんなんみんな全部書くことないし、どんどんここと変わってるんだから絶対漏れるじゃんていうかずれるじゃん。
1:00:52そうなんですよ。ドキュメントにその全てのことが書かれてるわけではない。そう。
1:00:56うん。
1:00:57それをそこに書かれてないことを多分みんな補いながら自分の頭の中にメンタルモデルテスタルをこう構築していくんで
1:01:05うん。
1:01:06そこが現状その
1:01:08AI
1:01:08とり合ってないみたいな感じですよね。
1:01:10うん。
1:01:10うん。
1:01:11ま、個人的にはそれ永久に来ないかなと思ってて。
1:01:14あ、
1:01:15うん。
1:01:16その今生まれるとか後等で生まれた新たなそのドメインに関する共通理解をじゃあすぐモデルの中にその
1:01:26AI
1:01:26の中で入りますかって言ったらなることはない
1:01:29しそれの立ちごっこが
1:01:31まあ作り切りのプロダクトだったらともかく
1:01:34うん、
1:01:35ま、授業を作るようなプロダクトって当然進化していくわけなのでそう考えるとそこって絶対にギャップがあるし人間が表
1:01:46あの、言語、特に機械が読めるようなものに言語化しきらないっていうのはずっと続くかなと思うと、ま、
1:01:55100%
1:01:56の、ま、モデルというか表現されたデータっていうのは、まあ、ないのかなっていう思いますね。
1:02:03そうです。実際あれなんですよ。モデルを更新するって、まあ、ま、モデルを更新するって言い方す難しそうなんでうん。なんだろう。
1:02:09例えばその一級のその料金計算の話をした料金計算すると料金計算に何か変更を入れるみたいなことがあるとするじゃないですか。で、そういう場合っていきなりそのシステムの話にならないんですよ。
1:02:21うん。
1:02:21で、最初は例えばその営業の人たちが経の人が手作業でやってたりするんです。そういう新しい
1:02:26うん。うん。
1:02:27あの請求の仕方とかを。
1:02:29で、そこになんかプロセスが出来上がって、で、だんだんそれでみんながやってることっていうのはこういうことをやってることだねっていうのが分かってきて、で、それがシステムに落とし込むためのモデルにこうなんかフィードバックされて反映されてくみたいな感じだからそのみんなが手作業でやってる間っていうのは誰もなんかそこに存在するモデルをあのクリアに理解していないんですよ。
1:02:48だけどこういうプロセスでここのここのあのお客さんとあのやり取りしてればうまくいくってのはみんななんか勝手にルールを作ってやってますみたいな状態なんで
1:02:57だからどこにも言語化もされてないし企業の中でもあのクリアに認識できていないっていうのがモデルのすごい最初の初期状態なんですよね。
1:03:04うん。
1:03:05だからそこをAI
1:03:06に発見させるって言ったってAIは
1:03:07そこに対するインターフェイスを持ってないから見つけることができないじゃないですか。でシステムの近くなってきたこで初めて
1:03:12AI
1:03:13との接点が生まれるって現状まになることはないってそれはそうだなっていう。うん。
1:03:18リアルワールドで動いているモデルとエンジニアがそれを、ま、モデリングというか頭の中で体化したモデルでコードに落としたモデル
1:03:28うん。
1:03:28ドキュメントに落ちたモデルとなんかモデルが何回層かあるが、ま、当然どれも進は完全にはしないから。
1:03:36そうですね。
1:03:36少しずつその過程でいろんな情報がこう、ま、車掌されていって抽象化されて
1:03:41ようやくシステムに落とし込める程度の、
1:03:44ま、モデルだったら業務フローになるわけじゃないですか。その手前の段階っていうのを
1:03:49AIに察知させるのちょっと、ま、
1:03:51そもそも難しいっていう感じですよ。うん。
1:03:53うん。
1:03:54逆にその、ま、やっぱリアルワールドからの追い上げとかは人間の両文ではあるとして、そのモデリングの過程、その車掌してく過程というか、次の中に移ってく過程で
1:04:05AI
1:04:05がじゃあ逆に活用できる場面とかってあるんですかね?
1:04:09ま、そのうち多分だからモデルをきちんとある程度そのシステムの使用に落としの得まで言語ができたらそっから先のコードを生成するとか自動でやるみたいなのは多分できるようになると思うんですよね。
1:04:18うん。
1:04:19ただもうそこまで行くとコ度書くのってなんかもうほとんど考えないで書く領域に到達するじゃないですか。
1:04:25うん。そうすね。
1:04:26あ、それってAI
1:04:27に自動化させたところでそこまで生産効率上がんないよなっていう感じはするんですよ。
1:04:33ああ、もうそこまで行ってるとその道の
1:04:358割は走り切ってるから。
1:04:37うん。そうなんです。
1:04:39確かにそれはそうかもしれない。もうモデルをエンジンが理解するところが
1:04:441番遠いのはまさに
1:04:45うん。
1:04:45実際今話したみたいなその料金の変更とかなんか空出チェックの変更とかってその事前のそのモデリングになんかめっちゃ時間かかるけど実際コードにしたら本当にプルリクトしてはめっちゃちっちゃかったみたいなことよくあるじゃないですか。
1:04:58だからそこのちっちゃいコードをAI
1:04:59に生成させたから何なんだって話
1:05:01うん。
1:05:02ですよね。
1:05:03うん。
1:05:05いや、そうですよね。いや、めちゃ頭の中で解釈してた。これ大丈夫ですか?この話。僕設計の話好きだから一生こう行っちゃうんですけど。
1:05:15皆さん大丈夫ですか?元気ですか?ちょっと僕喉乾いたんでちょっとはモデリングを
1:05:21AI
1:05:22と一緒にやる時になんか平均に回機していくのであのそこは注意し、あの要するに例えばだからなんか一級みたいなシステム作るとしたらこんな設計とかあの
1:05:33EC
1:05:33サイト作るとしたらこんな設計みたいななんか典型的なやつに寄っていくので
1:05:38それ自社のその競争領域としてそれ正しいのっていうのちゃんとあの目を持
1:05:44てないとなんていうかめちゃくちゃ普通のやつが出あ、だから悪くもないんですよ。
1:05:4970
1:05:49点ぐらいのやつが出てきて、でもそれそこそういう関係性じゃないよねとか、ここの出現準が逆だからうちに競争優意位があるんだよねとかそういったところてあのどっちかっていうと人間が
1:06:03AI
1:06:04から離れていかないといけないところでなのでうん。
1:06:08逆にその最初の叩き台としてぴょンと出すにはいいやっぱり良いでそのなんてかマクドナルド理論みたいなもんで
1:06:181番最初になんか70
1:06:20点ぐらいの買出していやそうじゃないねその差として自社にとって大事なところを認識するとか
1:06:27そういったプロセスが始まるのでそのなんか
1:06:30100%
1:06:30人間が手でやりましょうとかそういう話ではなくて
1:06:33うん
1:06:33うんと鵜呑みにするのもやめた方がいいし叩き代にするのはとても効果的だ
1:06:38とはいえなんか思いっきり平均的な設計にえっと寄っていくのでそれは競争力になるかって言うと非競争領域だったらそれでいいけど中核領域だったらそれじゃダメすよね
1:06:52うんて話なので
1:06:54そこはきちんと認識した方がいいですというのとま基本あのうんと今の学習のされ方が足し算思考なのでえっと機能は多いほど良いとかあのそういった方
1:07:07こになってしまいがちです。で、モデル、
1:07:10モデリング一緒にする時もなんていうか
1:07:12割と備えるんですね。こういうことも
1:07:14あろうかとみたいな感じの構造になって
1:07:16たりするので、いや、それはいらないとか
1:07:19あえてやらないとかどっちかっていうと
1:07:21人間側の指示ってあの引き算の方ばっかり
1:07:26んですよね。うん。
1:07:27でもうちょっとだから最初から
1:07:30あのうまく伝わってればこんなに
1:07:31引き算繰り返す必要はなかったんだけどな
1:07:33とかそういうのはあったりしますね。うん
1:07:35。うん。それはAI
1:07:38が、ま、平均的に世の中のものを色々見ているから、
1:07:41たくさんのものを見て学習してるので、例えば
1:07:44ECサイトってのはこういうも、あ、EC
1:07:45サイトってのは商品があって取引があって、顧客があってっていう黄金の三角形があって、そっから放射上にいっぱい伸びてますよねっていう一般すごい普通の
1:07:53ECサイトが出てきてうん。
1:07:55で、そのすごい普通のEC
1:07:56サイト作ってどうすんだよって話になるわけですよね。という感じそういう風に書けるんだったら
1:08:04別にいらないですよね、誰も。
1:08:07なんでAI
1:08:08がかけるんだったらそれ売るものに他の人もかけるってことなので
1:08:12それ売りもなんないんですよね。なんでさっきのま自社の競争領域としてそれをやるっていうのはやはりちょっと違うよねっていう風には考えないといけないかなとは思いますけどね。
1:08:14[音楽]
1:08:25うん。ふんふん。確かに
1:08:27AI
1:08:27がなんかやっぱ平均的なというか世の中にあるものを喋ってるので世の中にないものを作るんだったらちゃんとそっから意識して離れる必要があるよね。
1:08:35うん。ネ論ですよね。その領域に特化した引き算が苦手なのはもうティアさんが言ってる通りだなと思っていて
1:08:43うん。
1:08:43ちょっと話業務システムが全然ずれて競技プログラミングの話なるんですけど僕プロやってて、あのプロのコードを
1:08:49AI
1:08:50に書かせるとあの競技プログラミングの制約の文脈がすっぽ抜けるんですよ。
1:08:55ああ、
1:08:56要するに競技プログラミングってあの緑色の正解さえすればいいのでなんかエラー処理とか丁寧にやる必要一切ないんですよね。
1:09:04で、多分計算量的に、あの、このせ、物
1:09:08制約だったらそんなコーナーケース考え
1:09:09なくていいとかて言って、いろんなこう、
1:09:11引き算をしてすごいそのシンプルにコアの
1:09:13ロジックだけをバッと書いて終わらせたい
1:09:16んですよ。だけAIに書かせるとなんか
1:09:18いろんなこうこういう場合はこうです、
1:09:19こういう場合こうです。ここのデータが
1:09:20こう膨れ上がったらこういうことを変え
1:09:22なきゃいけませんみたいなことをバーと
1:09:23生成してきて、あ、なんかすごいなこと
1:09:25やってんだみたいな感じです。だけどそれ
1:09:28はだからずっとそのプロやる人にとっては
1:09:30当たり前のそのドメン知識みたいなことが
1:09:32存在していてうん。
1:09:33その暗黙の引き算ができるわけですよ。これはいらん、これはいらんって言ってで必要なことだけ書くみたいな。で、現状のエアは多分それが結構苦手だなっていう印象を受けます。
1:09:42うん。
1:09:43確かにプロダクトのコード書いてても、え、そこのその細かいエラーハンドリングいるみたいなのとかたまにやっぱりあったりとかなんか常にフルパワーを出してくれますよね。
1:09:52そう。それでプロダクトコードコードその方だったら、ま、それでも、ま、
1:09:55100分譲っていいかもしれない。
1:09:56いいかもしれないけど、さっきのその要件とかそのモデルのところでその引き算ができないとそれこそそのモデルってある意味その引き算して必要なその抽象度にこうしっかり抑えることが最も重要なポイントじゃないですか。だからそこでこう結構上調なモデル作られてもそれこそ競争にならないんで
1:10:14うん。
1:10:14ま、そういう意味でもちょっとまだ難しいかなって気がします。うん。
1:10:17うん。うん。
1:10:19余計なモデルを作ると、ま、本来ない業務とかドメインがそこになんか勝手に連されてるみたいになってノイズ間違う。ノイズになるとか、ま、実に落とした時にスケールラビリティがでスケールしないとか、ま、いろんな多分問題を起こすんで。
1:10:35うん。
1:10:35うん。そこはやっぱりそのドメインを理解してどう、どう車掌するか捨てるかっていうのが多分本質の領域っていううん。
1:10:43うん。確かにAIに、ま、欠かせるところ
1:10:46はいいけど、人間がちゃんと考えて、人間
1:10:48がちゃんと見て、あ、これは本質じゃねえ
1:10:50みたいな、これはいらんみたいなの
1:10:52ちゃんと、ま、考えましょう。やっぱ特に
1:10:56業務とか作ってるプロダクトとかだと
1:10:59ドメインがコア、モデルがコアだから
1:11:01やっぱそこはそうです。ちゃんと守ろう。
1:11:04例えば、ま、ちょっと具体例で話した方が
1:11:06いいと思うんで、具体例で言うと、あの、
1:11:08レストラン僕らは使ってるんですけど、
1:11:10レストランのあの、空席あるじゃないです
1:11:13か。
1:11:13それをなんでそのモデリングしなきゃいけなわけですよ。レストラン天内の今席がいくついてるかってだけどレストランの席って
1:11:21あの4
1:11:22人席だと思ってたやつをちょっと動かしてくっつけたら
1:11:248人席になったりするじゃないですか。
1:11:27で、なんだったらそのあの椅子もう1個
1:11:29持ってきたら急に席になりますみたいな
1:11:30なんかそういうのがあるんで、そこは
1:11:33やっぱりそのえっと実際のそのえっとこの
1:11:36ぐらいまで実現できてればまあまあ多くの
1:11:39ユースケースはサポートできるだろうこう
1:11:41ちょうどいいラインでこう全員引きすい
1:11:44ませんこさにそんなマニアックなことは
1:11:46できません言って仕様を作るしかないん
1:11:47ですよ。うん。だけ多分Aに合わせると
1:11:49そこまで全部ゴルしちゃうんですよ。
1:11:51そうっすね。
1:11:51うん。そのなんかあれもできなきゃいけ
1:11:52ない。これもできなきゃいけないみたいな
1:11:54。
1:11:54で、その引き算のそのによってそのビジネスとしてどこまでをその自分たちのなんかなんていうかえっとスコープに含めるかっていうあのがモデリングと直結するんで
1:12:05うん。
1:12:06例えば高級点だったらそこまでそのあの細かい席の動かし方しないけどカジュアルなチェーン点とかはなんか
1:12:125人来たらあ5人入れますよって言って5
1:12:14人席作るみたいなことやるじゃないですか。
1:12:15で、どっちの事業ドメインに僕たちは適合するかでそこのモデルが変わってくるんで、
1:12:21そういうことは平均に解させると結構そういう割り切りができないっていううん。うん。
1:12:25は、あると思います。
1:12:27ま、考慮してくれることでその僕らの考慮漏れとか、ま、あとは考えたくないことを逆に考えてくれてラッキーはあり得るが、ま、一方で今回はいらんでしょうをやりすぎちゃう。
1:12:36そう。その引き算をすることが難しいっていう感じです。
1:12:39うん。
1:12:41確かにここは結構なんか活用活用はし
1:12:43やすいが一方で鵜呑みにはしいけないと
1:12:46いうか、ま、あくまで大当な議論相手
1:12:48みたいなそういう使い方、付き合い方が
1:12:50大事ということなんですかね。
1:12:53ありがとうございます。
1:12:56もうちょっと、もうちょっとやっていい?
1:12:58もうちょっとやっていい?ああ、いいて
1:12:59言われた。いや、若干時間が伸びてるので
1:13:01どうしようかなと思ったんすけど。えっと
1:13:04行きます。何の話したっけ?
1:13:07引が、引き算が似合ててか僕あのちなみになんか実感としてなんですけど、
1:13:12GPT
1:13:13はい。5
1:13:14になってから
1:13:14うん。
1:13:15GPT5
1:13:15になったからすげえコード書かせると余計なことすんなっていう印象です。
1:13:20あ、そう。コードを書かせると
1:13:22うん。だからそれこそ強プロの問題をなんかわかんない問題一緒に考える時にここ解いてもらうんですけど、こんな感じのコード書いたんだよね。どうって
1:13:30聞くといいやなんかあなたのコードはこういう考慮は足りてませんって言って余計なコードを書き始めるみたいな。
1:13:35思ってなんか前よりそのあの振る舞が増えました。
1:13:38ああ。
1:13:39うん。で、なんか結構イラっとすることがうん。だからなんかモデルの性格付けにもよるかなとは思うんですけど。うん。
1:13:40[笑い]
1:13:47うん。
1:13:48確かに。
1:13:49だ、なんかモデルの性能が上がったらよりこうシンプルで美しいコード書いてくるかとくれるかと思ったら逆にそのなんかコーナーケースとか異常に気にし始めて余計なことするようになったみたいな感じですよ。
1:14:00うん。
1:14:00確かに。それもやっぱタタタスクの特性とかにもよるんですかね。
1:14:04そのあんまりそういうシンプルなケーストよりはもっとジェネラルにでかい問題も解いてほしいからというかそもそもなんかモデルを作っている
1:14:12LM
1:14:12を作ってる人たちがそこのをうまくコントロールすること自体が難しいんじゃないですかね。
1:14:17うん。
1:14:18うん。ちょうどいいか具合の行動を書かせるモデルに仕上げたいんだけど、いざ出来上がってみたらなんか余計なことばかりするモデルにアップグレードしてましたみたいなことが起こってそうな気がします。
1:14:30なるほど。
1:14:31僕たちはまだまだそういうことを振り回せれながら
1:14:34あれを使っていくんだろうな。うん。
1:14:38ま、彼らがいらんことも言ってくるかもしれないとか、ま、こういうこと出力するからこは抑えてもらおうみたいなことを考えながら、ま、議論相手とかコーディングパートナーとして付き合っていくみたいな。
1:14:49そうですね。
1:14:51はい。
1:14:51なるほど。ありがとうございます。
1:14:53質問触れって感じです。
1:14:54え、
1:14:55質問を、
1:14:57質問触れて、あ、
1:14:59Twitter上の質問を、
1:15:02えっと、ちょっと待ってくださいよ。
1:15:07今ちょっとXにある質問を
1:15:11見ているんですけどああ、確かにとある質問でえっとま、さっきちょっとテストの話に戻るんですけど、その、ま、うまいユニットテストをもうかけてるっていう時点での設計思想と実装がすごいちゃんとまいこと言ってるんじゃないかみたいな結果としてこう結
1:15:31結局ん、うまいユニットテストかけてる視点でうまい設計構想と実装ができている。だからもうテストうまいこと書こうと思うとそもそも設計は多分うまくやんないといけないみたいな話があるということですかね。
1:15:47質問じゃなくて主張です。
1:15:50て思うんだけど、その辺の議論はどうなんでしょうかっていうま、ま、イエスだと思いますよっていう話で、それはあのユニットテストと設計
1:15:58っていうのは一体のものなので
1:16:00うん。
1:16:00いい設計。あ、まあ、だからそうか。いい設計だけどテストが下手はあるな。その、その逆はないな。
1:16:06ああ。
1:16:07うんと
1:16:09いい設計は前提ではある。
1:16:11うん。あの、そう、いい設計だけど残念なテストってのは確かにありますね。
1:16:15だからそのテストコードとかテスト設計のうまい下手は良い対象が良い設計であるということと、え、それに加えて対象とうまいことも相取りつつ、あの、きちんとテストの価値を出してるみたいな書き方っていうのは、ま、ベッこのスキルなので
1:16:34うん。
1:16:35まあ、どっちも良いのがいいでしょうっていうもない話になるんですけど、対象の設計が良くないとそれにテスト設計って大体引きずられるので、まあ、だからやっぱあの、基本はその通常のプロジェクトにおいてはどっちも良くなっていくもので、大体その品質っていうのは連動するけどうん。
1:16:53最近AIにテストコード書いてって言うと
1:16:55、その良い設計だけど悪いテストコードっ
1:16:58てのは発生するようにはなってきてるので
1:17:01その辺はなんかこれは変なのではって
1:17:04気づけるようになるっていうのはまず第1
1:17:07歩だと思います。で、例えば良い設計
1:17:12とは実レベルですけど、さっきの木の話で
1:17:14いくと木を使わずにちゃんとテストを
1:17:17かけるようにするには本体の方がI用分離
1:17:20をきちんとできないといけないじゃない
1:17:21ですか。そう。
1:17:22今田さんが言ったのは愛離本体でせっかくちゃんとやってんのにテスト書かせたらも句使いまくるみたいなこと言。
1:17:27そうそうそうそうそうそう。例えばそういう
1:17:30本末点
1:17:30そういう話。
1:17:32それはだからせっかく何のためにあの愛を脇に寄せてんだっていうのを人間が気づかなきゃいけないっていう
1:17:40やっぱりなんかなんかAI
1:17:41の時代だと逆にその極端な話をすると高速にコードを書いてくれてテストをしてくれるからテストさえあれば設計はなんか多少ロックでもなんかパンクの設計でもなんかバイルの設計でもいいという考え方もなくはないがやっぱりそこはちゃんと一定綺麗なというかテスタブル
1:18:01設計で行動を変いていこう。ユニットテストをしやすい設計で行動を変えていこうっていうのは引き続き重要ではある。
1:18:10うん。それも先ほ最初の方に伊藤さんおっしゃったようなそのプ
1:18:15コードが閉めているプロダクトのまビジネス上の価値によるんじゃないですかね。あ、
1:18:20ま、使え捨てていいんだったらそんなロックでもいいじゃん。
1:18:24どうせするんだになるし、その中心の授業の中心になるとこだったらおっしゃる通りなるかなと思うので
1:18:32うん。
1:18:33ま、下手するとそのね、テストコートなくてもいいじゃんっていうのを極論すると出るかもしれないなと思う。あります。あります。
1:18:40そんな真面目にあの事業領域全体にテストコード書く日がくれます。
1:18:45はい。ですよね。
1:18:46なのでそこは多分そもそもじゃあそのコードが持つ事業的な価値とか位置付けとかにまずベースラインがあってっていうのはあるんじゃないかなって思いますね。
1:18:59ま、ただそれもあれですけどね、あくまで理論としてはリソ論としてですよ。あの分かってる人がその手を抜くべきところは抜いて手を入れる、あのやるとこはやってほしいんですけど、分かってない人が手を抜いてるのはそれはなんか
1:19:11何の意味があるんだ。
1:19:12そういから書きなさいっていうので終わりですね。はい。
1:19:16厳しい。なん、ま、その分かる、分かる、わからないはどっちかっていうとやっぱ事業に対するわかるわからないテストに対する分かるわからないでどっちでテストの強さをが変わるんですかね?
1:19:30いや、両方です。両方
1:19:31両方そりそうか。
1:19:35はい。じゃあ、ま、テスト、ま、事業の
1:19:38性質に合わせて、ま、最テストかなくて
1:19:40いいところもあるし、ま、壊れてないこと
1:19:43が保証できればいいところもあるし、ま、
1:19:45今後の拡張が
1:19:47あるので、そこをちゃんと、ま、
1:19:48メンテナブルな継続的なテストができる
1:19:50ような設計あるいはテストが必要になる
1:19:53ところもある。そう。メンテナブルな
1:19:55コードを基本的にやっぱ目指さないとうん
1:19:59。結局なんだっけ?理解なんか岩田さん
1:20:03今日あげてましたよね。
1:20:04回復が負債でした。
1:20:05あの、そう、負債が発生ですよね。
1:20:07ま、要するにある程度のところまで行くともうその、あの、ま、まあ、ま、みんなよく分かってるけどコ度自体が理解不能になって負債化するじゃないですか。そうすると
1:20:15AI
1:20:15自体もそれ理解できなくなってぐちゃぐちゃになって、
1:20:17だからAI
1:20:18開発してるとある程度のとこまでは開発できるけど、ある一定のところをあの、超えるとそのコンテキスト溢れたりとかいろんなことが原因でちゃんとか書けなくなるじゃないですか。
1:20:26うん。
1:20:27だからそのためにやっぱビルディングブロック綺麗に積み上げていかなきゃいけないのはそうでうん。
1:20:30で、ただただし同じ
1:20:331
1:20:33つのアプリケーションの中にはそのビルディングブロックを丁寧に積み上げないといけない部分と、ま、ここは大したことないよねって部分があるんで、そこの労力を同じだけ払ってもしょうがないから
1:20:42うん。
1:20:42ま、そこはまだ人間がやらなきゃいけない領域なんで、その力を入れるべきところと抜くべきところをきちんと把握しましょうっていうのがトータルだと思う。
1:20:50うん。
1:20:51うん。
1:20:52ありがとうございます。確かになんかAI
1:20:54だからコードがバッと変えてくれるから
1:20:56コードバット解釈してバッと書いてくれる
1:20:58からいいでしょって思っちゃうけど、ま、
1:20:59僕らと一緒で認知の限界を迎えると、ま、
1:21:03偉いことになっちゃうので、ま、そこは
1:21:05やっぱり一定綺麗な設計というか、
1:21:06ちゃんとしたコードを書きましょう。
1:21:08やっぱ今後の時代でも、ま、当意識しない
1:21:12といけないところですかね。透明は意識し
1:21:15なきゃいけないところだと思うんですけど
1:21:16、昨AIの話ばっかりになっちゃ、
1:21:21コミュニティ含めてね。うん
1:21:23なんかみんなあんまりコードのをどう書くべきかって話しなくなったなと思っ
1:21:26はいはいはい。
1:21:27これはいいのかなって思いながら見てました。
1:21:29いや、難しいですよね。実際実際小価値に向き合ってる時間のが長いですもん。小価値難しいドメイン。
1:21:39うん。
1:21:42そこは確かにもっと僕ら逆に行動をどう書くかどう、ま、長期面頼絶頼る実装にしてくかとか、ま、より意識して議論する議論したいんだけど今日もそうだしカンファレンス全部
1:21:58AIになっていて
1:21:58はいはいはい。
1:21:59あの、はてな物ッ価マクのテクノロジー多分もそうだし全もそうだしキータもそうだし、なんかドップ全部
1:22:05AIになってて、みんなAI
1:22:07にしか関心ないのかなみたいな感じですけど、ま、実際には多分それだけでは難しいんじゃないかなってのがみんなの実感なんじゃないですか。
1:22:15うん。
1:22:15うん。
1:22:17いや、ありがとうございます。
1:22:18そろそろそろそろ時間が結構長くなっていそうなのでちょんおさん方こう最後言い残したいことみもっとこうみんなにこうこうしてくれみたいなのとかメッセージとかあったりしますか?じゃあてっぺさんからで。
1:22:37ええ、
1:22:38難しいお題ですね。いや、ま、そうですね。ま、興味持たれてる。
1:22:44今日来てくださってる方興味持たれてると
1:22:46思うんですけど、AIに、ま、個人的には
1:22:48、ま、もちろん興味持って触っていくって
1:22:51いうのはすごくいいことなんですけれども
1:22:52、先ちょっと出たようにですね、そもそも
1:22:54ソフトウェア開発というものが、えっと、
1:22:57変わる可能性はもちろんあるんですけど、
1:22:59今じゃないんですよね。少なくとも。ま、
1:23:01多分少なくともうん。3年は絶対変わん
1:23:04ないかなと思うし、
1:23:07変わったとしても多分このくらいだと
1:23:12そんなにソフト開発っていう、ま、40年
1:23:1550年の歴史からすると多分まだまだ
1:23:17やっぱり抜婚的に変わるっていうことは
1:23:20ないかなと僕は思っていて、そういう意味
1:23:22でもソフト開発そのものっていうのを
1:23:24しっかり学んでいく必要はあるし、理解を
1:23:27する、やれるようになっておくっていうの
1:23:29は必要かななんて思ってます。はい。
1:23:32そんなとこでパス考えてんでさん先どうした?
1:23:39えっとですね、あのその意だともうあの今日
1:23:453
1:23:45人喋ってるとこいてなんかあまり夢がないなって思われた思うんですよ。
1:23:51もっとこれからの開発ってなんか夢があっ
1:23:55て花があって、あの、どんどんいろんな
1:23:58ことできるようになるんじゃないかって
1:23:59いうとなんか全然できないって話ばっかり
1:24:02している気がするんですけど、今のところ
1:24:04そうですと。で、えっと、な、何て言った
1:24:07かな、あの、基本今AI周り全部バブルな
1:24:11ので、えっと、実質実態より機待値の方が
1:24:15はるかに高いところずっとせ推移してるん
1:24:17ですよ。でも現場レベルで言うと、えっと
1:24:20、期待機を、あの、過ぎて、今現場レベル
1:24:24で言うと厳滅機に入ってんですよね。なん
1:24:26か思ったほどじゃないな感があって、でも
1:24:28思ったほどじゃないか、ないな感がある
1:24:31ところで、その過去振り返ってみて1年前
1:24:34にできなかったことはできるようになっ
1:24:36てるよねとか、あの、もっと色々あの、
1:24:39諦めてたことができるようになって
1:24:40るっていうので世の中明らかに前には進ん
1:24:42でいて、思ったほどすごくはないし、思っ
1:24:45たほど早くはないけど明らかにじわじわ
1:24:47変わってるしで、ま、厳滅器ってやつの
1:24:50あとはハイプ何があるかっていうと、普及
1:24:52ってやつがあるんですよね。で、普及って
1:24:54のはだから人間とAI共存のやり方とか、
1:24:57ここを使うといい感じ。僕はやめといた方
1:25:00がいいかもみたいな、あの、ちょうどいい
1:25:03乗りこなし方っていうのを肌感覚で
1:25:051人1人が理解してで、えっと、美味しい
1:25:08ところを使っていくで、えっと、結果的に
1:25:11はこれまでできなかったことができるよう
1:25:13になっていくみたいな社会が対現するって
1:25:15いうのが、ま、ソフトエンジニアリングの
1:25:18現場としてはいいなと思ってるしで、
1:25:20ソフトウェアエンジニアリングの現場
1:25:22離れるとこれまでプログラミングと関係
1:25:24なかったでも自分の欲しいものがある人
1:25:26たちが1人1人あと自分が欲
1:25:29しいソフトウェアをいっぱい作ってで、自分
1:25:311
1:25:31人が使ってるっていう世界、あの、もっとずっと多様な世界っていうのがそのままで広がっていくっていう方がなんか革命、社会革命感がなるので、そっちは本当にガチでとても夢があるなと思ってます。で、そこがね、その全体として社会のソフトに対する理解の度合を高めて、で、ま、あの、もうちょっとなんだろう、デジタルネイティブっぽい社会になればいいなとは思ってます。
1:26:00お願いします。
1:26:01あ、今の話の後にあ、そうですね。
1:26:03[笑い]
1:26:11えっと、まず、えー、別にあの、ちょっと今日生産性が上がってみたいな話をし、上がってみたいな話をしたんで、ま、否定的に捉えられるかもしれないけど、実は全然そんなことは思ってなくて、多分、ま、長い時間かけて変わっていくのはそうだから、
1:26:27まずそれには乗っかってた方がいいよね。それは間違いないと思うんですよ。
1:26:31で、ただそん時にあの、えっと、時期が来たら乗っかりましょうとかっていうのは一方でアクテだなと思っていて
1:26:40うん。
1:26:40やっぱりその手を動かしてその時点での洗脳限界みたいなを冷静に見極めるってのが僕たちエンジニアに求められる態度かなってのは思うんですよ。うん。で、手動かすとすごい夢中になっちゃって、ま、ある意味その驚き屋みたいになっちゃうの。それはそれでちょっと問題じゃないですか。
1:26:57だからその冷静にこう現時点の性能とはこのぐらいみたいなのを考えてやっていきたいし僕はね。で、その方がいいんじゃないかなと思うのと
1:27:07あ、そう思います。
1:27:08はい。
1:27:09はい。あともう1
1:27:10個なんか言ようとしたけどちょっと忘れちゃいました。
1:27:11[笑い]
1:27:13はい、じゃあちょっとありがとうございました。だいぶ長場だったんですがパネルディスカッションは一旦ここまでとさせてください。ではお参加ありがとうございました。よいしょ。やべ。
1:27:23[拍手]
1:27:34えっとで、えっと、こっからおろに宣伝とアンケートなので、ちょっとじゃあおさん方は
1:27:45はい。
1:27:46はい。ありがとうございました。
1:27:50で、えっと、ちょっとめちゃめちゃ伸びて
1:27:53しまったんですが、えっと、皆さんパネル
1:27:56ディスカッション、パネル
1:27:57ディスカッション楽しかったですか?得る
1:27:59ものありましたでしょうか?
1:28:04ああ、よかった。ちょっとあんまり僕の
1:28:06好きなトピックに行きすぎてちょっと自己
1:28:08になってないか不安だったんですけど、ま
1:28:10、皆さん得るものがあったな、あったので
1:28:12あれば良かったです。ちょ、是非この情報
1:28:15を持ち帰って、ま、明日からの開発とか
1:28:18明日、明日休みですね、えっと、来週から
1:28:20のその、ま、プロダクト開発であるとか、
1:28:23え、チームに持ち帰って、ま、是非活用し
1:28:26ていただければと思います。で、えっと、
1:28:28最後お知らせなんですけど、ま、レアXで
1:28:32は引き続きこう技術系の勉強会なイベント
1:28:34をやっていきますので、えっと、ま、是非
1:28:37コンパスとか、えっと、Xのアカウント、
1:28:38レay、XTECHをフォローして
1:28:40いただいて、えっと、ま、是非ぜひこれ
1:28:43からのイベントにも参加していただけると
1:28:45嬉しいです。で、あとはもうこれもお知ら
1:28:48せで、ま、今日そのAIの、えっと、僕ら
1:28:51が使う方の、ま、コーディングとか
1:28:53プロダクト開発でAIを生かすぞっていう
1:28:56話だったんですけど、ま、それはそれとし
1:28:58て、ま、プロダクトにAIを使った機能を
1:29:00組み込んで、ま、新しい体験を作ろうでも
1:29:02難しいよねっていうので、ま、そのAI
1:29:05エージェントを組み込んでいくためにどう
1:29:06いう難しさがあるかとかを、ま、今
1:29:08エンジニアブログを、えっと、毎日2週間
1:29:113週間ぐらいやってるので、ま、これ
1:29:12引き続きみんなが、えっと、疲れ果てる
1:29:15までやるので、ま、これも是
1:29:17TwitterXをフォローしていただい
1:29:19て、えっと、ウォッチしていただければと
1:29:21思います。で、お、さっきからずっと言っ
1:29:24てるけど、えっと、レクステックと、ま、
1:29:26コンパスと、ま、是非フォローして
1:29:28いただけると嬉しいです。で、えっと、ま
1:29:30、最後、えっと、アンケートにご協力
1:29:32ください。ま、これから、ま、レアXその
1:29:35技術的なイベントとか色々やっていくに
1:29:37あたって、ま、是非こう皆様からの
1:29:39フィードバック、率直力なフィードバック
1:29:40とか感想とかいただけると、ま、運営とし
1:29:42ても励みになりますし、ま、登壇者
1:29:44パネラーとしても、ま、嬉しいので、えっ
1:29:47と、是非アンケートの回答をよろしくお
1:29:49願いいたします。ちょっとじゃあこれを
1:29:52アンケートを回答していただく時間を取る
1:29:54ので書いてください。よいしょ。
1:30:03大丈夫す。取れます。取れる。取れそう。みんな入力してくれそう。よいしょ。
1:30:50ええっと、
1:31:03概いていただけましたかね
1:31:21まだちょっと書いている方もいるかもしれない。ちょっと
1:31:28ほい。じゃあちょっと、えっと、あ、オン
1:31:30ラインの方も是非アンケートをご回答
1:31:32くださいっていうのと、えっと、ま、オン
1:31:34ラインの方、えっとだいぶ長丁場でしたが
1:31:36、ん、カメラ、そ、それよね。えっと、
1:31:40ありがとうございました。えっと、ま、
1:31:43オンラインの方もこう今日得た話とかを
1:31:46是非現場に持ち帰ってご活用して
1:31:49いただければと思います。では、一旦配信
1:31:51の方はこれで終了ですかね。ありがとう
1:31:54ございました。
1:31:57[拍手]

About this transcript

This page contains the full transcript of AI Coding Meetup #3 AI時代の開発スピードと品質のバランス術 by LayerX 公式, generated from the public captions YouTube serves with the video. The transcript has 1,635 words across 1,635 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.