DevRel Tokyoの紹介
はい、皆さんお疲れ様です。今日は4月の1日ですね。
DevRel Radioの209回目をやっていきたいと思います。
まず最初ですね、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね。
大体1時間程度、大抵生で、ライブでやっているというラジオになります。
DevRelというのはですね、Developer Relationsの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えばコミュニティマネージャーとか、デベロッパーアドボケイトとか、
テクノロジーエヴァンデリストとかマーケターとかですね、
そういった方々が集まって情報交換したり、イベントをやっているというコミュニティになります。
公式サイトがありまして、DevRel.Tokyoというサイトになります。
そちらからスラックに参加することもできますので、
ぜひDevRelに関わっているとか、DevRelに興味があるという方はですね、
スラックに参加いただければと思います。
そこまでじゃないよという方はですね、公式のXアカウントがあります。
AtDevRelTokyoというアカウントですね。
普段はSharpDevRelJPというハッシュタグでポストしてますので、
ぜひそちらのアカウントフォローいただいたりとか、
ハッシュタグ見ていただけるといいかなと思いますというところで、
今日は4月1日ですね。
たぶん新しい学校に入るとかですね、
あとは会社員になるみたいな方がいらっしゃるのかなと思うんですけど、
4月1日とは思えないぐらいすごい寒いですよね、今日ね。
てっきりもっと暖かくなるのかなと思ってたら、
全然暖かくならなくて、
今日もたぶん柔道とかですよね。
3月の末とかこんなもんだったかなって思うぐらい、
ちょっと今日は冷えるなっていう気がしてますね。
早速コメント来てますね。
ジャニーマンさんからよろしくお願いしますって来てますね。
はい、よろしくお願いします。
この間アメリカ行ってて、帰ってきたんですけど、
羽田でね、夕方3時ぐらいだったかなに着いたんですけど、
外国人入国者の列めちゃくちゃすごいですね。
たぶん桜の時期とかと合わせてっていうところなのかなと思うんですけど、
もうね、あふれてましたね。
普通の入国審査の列もあると思うんですけど、
そこから実際降りた後のしばらく歩いてくるレーンのところとかまでずっとあふれてて、
最初そこが入国レーンなのかと思って結構ビビったんですけど、
案内する人が、日本のパスポートの人はこちらですみたいな感じで案内してて、
そっちが行くと全然着いてたんですけど、
そっちの外国人のレーンは入国審査の箱みたいなやつをほぼほぼフル活動しているのに全然進んでなくて、
すごいですね。オーバーツーリズムを体感しましたね。
しかも飛行機もたぶん相当多くて、荷物が出てくるやつあるじゃないですか。
バッゲージクレームって言われる。あそこもパンクしちゃってる状態というか、
荷物が出てきても受け取る外国人が入国できてないので、
この荷物が通路とかにすごいあふれちゃってるんですよね。隅の方に。
どんどん荷物出てくるし、かといって誰も受け取らないし、
新しい荷物が出てくる隙もないみたいな状態になっちゃってて、
そのせいもあるんですけど、飛行機ついてるのに全然荷物出てこなくて、
結局1時間ぐらい待たされるみたいな感じで、誰も得しない状態が繰り広げられてましたね。
しばらくこれ続くんでしょうね。すごいなって思いました。
サイバーセキュリティにおけるAIの未来
今日のメインテーマはもう一度チャレンジしたいこと、バージョン2とV2というところで、
先週ですね、先週は配信がアーカイブ録画したものになってしまってですね、
それもあってというところで、ラジオの回答がなくてですね、
急遽2回目のもう一度チャレンジしたいこととなっております。
今のところいくつかですね、ご意見は来ておりますので、
そちらはですね、後ほど取り上げていこうかなと思うので、
ぜひ今後にですね、もう一度チャレンジしたいことがあるという方は、
そちらを送っていただけると嬉しいなと思います。
それまではですね、最近のDevRel周りの内容とかを取り上げていこうかなと思うんですけど、
海外の記事で面白かったのがあったんだけど、どれだったかな?
これかな?これだったかな?ちょっとお待ちください。
AI系の話がですね、すごくやっぱり多くて。
これがMediumの記事ですね。
Future of AI in Cybersecurity. A Developer Relation Approach for Sentinel-1かなっていう記事で、
日本語で言うと、サイバーセキュリティにおけるAIの未来。
Sentinel-1のデベロッパーリレーションのアプローチという記事になっております。
これは読み方ちょっと分かってないんですけど、
Sentinel-1ですかね、っていうところのDevRelの計画っていうのを出してくれているというところで、
戦略が全部で3つあるかなと思います。
このSentinel-1の戦略が1個目がですね、開発者の教育と支援というところで、
例えばブログ記事を作成するであったりとか、
あとはウェビナートワークショップの開催とか、
あとは研究論文の発表、これはセキュリティならではみたいなところもあるかもしれないですね。
あとですね、ライブコーディングセッションを実施とかですね。
そのあたりが教育と支援というところで挙げてます。
2つ目のところがコミュニティへの参加とオープンソースへの取り組みっていうところで、
オープンソースのセキュリティイニシアチブと協力して、
AI主導のセキュリティ検知フレームワークを強化するとかですね。
あとは開発者がユースケースについて議論し、
インサイトを共有したりサポートを求められるインタラクティブなフォーラムを作成するとかですね。
そういったところで、どっちかというと多分コミュニティはオンライン側の施策かもしれないですね。
こうやったりとか。
あと3つ目っていうところが戦略的パートナーシップの統合っていうところで挙げてるのが、
クラウドプロバイダーとの連携でAI主導のセキュリティをクラウドネイティブのアプリケーションに統合すると。
クラウドプロバイダーで挙がってるのはAWSとAzureとGoogle Cloudの3つですね。
あとはサイバーセキュリティコンプライアンス企業と協力して、
AIベースの脅威インテリジェンスを強化するとか。
これは多分よくある既存のサイバーセキュリティのサービス提供企業と戦略的なパートナーシップを作るという話かなと思いますね。
あと最後が開発者向けのサウンドボックス環境を提供し、
ユーザーがAIを活用したセキュリティ技術をテストできるようにするっていうところを、
その3つをここでは挙げてるっていうところですね。
1個目が開発者の教育と支援。
2個目がコミュニティへの参加とオープンソースへの取り組み。
最後が戦略的パートナーシップとの統合というところを挙げてますね。
測定どうするのっていうところなんですけど、
ここのステンティネル1っていうところではですね、
全部で5個挙げてますね。
1個目は開発者がどれぐらい使ってくれているかっていうところで、
APIの採用率、ダウンロード数、ステンティネル1コミュニティへの開発者の積極的な参加。
これをいわゆるDAUのところですかね。
DAU、マンスリーアクティブデベロッパーだから、
MADですね、を見ていると。
あとはコンテンツのパフォーマンスっていうところでは、
ブログの読者数とかチュートリアルの完了数、
ウェビナーへの出席者数みたいなところも見ていくと。
3番目、ハッカソンへの参加。
これは突然出てきた。
ハッカソンへの参加っていうのが、
ステンティネル1のセキュリティ課題に取り組む開発者の数。
これはでもちょっと戦略のところに入ってなかったんで、
突然出てきちゃった感がありますね。
企業への導入、業界全体におけるAIを活用したセキュリティ導入の成長。
これは多分ステンティネル1の企業の導入数自体かなという気がしますね。
あと最後、パートナーシップの影響。
これはさっきのいくつかパブリッククラウドっていうところと、
あとサイバーセキュリティコンプライアンス企業の2つがあるかなと思うんですけど、
サイバーセキュリティ研究グループやクラウドセキュリティプロバイダーとのコラボレーション。
これちょっと具体的にどう見るかっていうのは挙げてないですけど、
コラボレーションが生まれるかどうかみたいなところを図っていくというところですね。
これはなかなかこの記事に書いてあるどういう戦略を立てて、
結果としてどういうふうに成功を測定していくかみたいなところが明確になっているのはとてもいいんじゃないかなと思ったりしましたね。
本当は多分数値とかにも落とし込んでるんでしょうけど、そこまでは出してはいないですけれども、
結構参考になる部分はあるのかなという気がしますね。
オーバーツーリズムの影響
全然関係ない話なんですけど、このAI絡みっていうところで最近AIのコーディングが流行ってるじゃないですか。
多分GitHub Copilotみたいな結構シンプルなものもあれば、Debianみたいなタスクを並列で流していけるぐらいのものもあったりとかして、
多分皆さんも何かは使ってると思うんですよね。
CursorかもしれないですしDebianかもしれないですし、Root Codeかもしれない、Clientかもしれないですけど、
何らか使ってるかなと思うんですけど、個人的にはCursor Proを使っていて便利だなって感じる場面もあるんですけど、
結構うまくいかないケースが多くなっているというか、
事前知識が相当オンライン上にあるとかパブリックになっているものであれば問題はないケースが多いんですけど、
ちょっとでもマイナーになると全然うまくいかないんですよね。
そのマイナーなケースで、基本的に今すでに世にあるものであればうまくいくケースは多くて、
例えばテトリスを作るとか、マインクラフト風のゲームを作るとかって世の中にすごくあふれているので、
そういうゲームを作ってって言ったら、それができた、すごい、みたいなのはできるやろうなみたいな。
でも実際たぶん我々が解決しなきゃいけないとか作らなきゃいけないものってそういうものではないので、
もうちょっと世にないものを作ろうとしていると思うんですよね。
その時にうまくいかないことがあったりとかして、ただそのうまくいかない原因が、
ちゃんと分からないと、技術者側が分からないと新しいことを言ってもまた失敗するんですよね。
結果的に見ると自分がちゃんとそれを正しいやり方を学んだ上で、
指示を出したりとか、何かのサポートを得るようにしないと、結果的にうまくいかないと思うんですよね。
なので、極論手でやっちゃった方が、自分で書いちゃった方が早いっていう風になるケースもまたありますし、
そうはならなかったとしても、その指示の出し方自体が自分がちゃんと知っていると全然書き方が変わるというか。
なので、世にある、既にあるものを作るんだったらAIはすごく早いと思うんですけど、
世にないものを作ろうと思ったら、結局自分がちゃんと学ばないと厳しいのかなというのを最近ずつ感じてますね。
学んじゃうと、自分でちゃんと学んじゃうと、別にネットワークがAIのサポートが受けられようが受けられないが、
結果的に生産性そんな大きくは変わらないかなっていう気がしていて、
多分20%増しくらいにはなるかなと思うんですけど、なくても全然問題はない感じになるかなと思うんですけど、
思いっきりそのAIに頼り切ったプログラミングしちゃっていると、
AIが使えない環境になったとすぐにクーンって生産性落ちそうな気がするんですよね。
それはそれで怖いなってしました。すみません、全然関係ない話だったんですけど。
では続いてのところですね。日本の記事で何か面白いのあったかな。
今言ってた話これに近いのかな。これはTogetherの記事なんですけれども、
AIでプログラミングのコードを作った人から全然動かなくなって助けてほしいと頼まれたので確認したところ、
何やったかわからないから全部作り直した方が早いということになった話。
これ結構私がこの間感じたのに近い気がするな。皆さんこういうことないですかね。
何やってるかはわからないことはないんだけど、
なんか勘違いした方法で結構ブルドーザー的に、
本当は自転車の舗装された道をうまく走ってほしいはずなんですけど、
AIって割とブルドーザーで自分の行く道をとにかくまっすぐガーって進んでいってしまうので、
あと残ったものがもう道じゃないみたいな。
すごい荒れ果てた場所みたいになってるケースがあるんですよね。
そうするともう手つけられないみたいな感じになってしまうので、
そうすると多分全部作り直した方が早いってなっちゃうのかなっていう気はするんですよね。
この中にも書いてありますね。
要は動けばいいというのと、複雑なシステムの中で強調的に動くことは全然違う。
AIで動くゲームを作るためには、まず動くゲームを作れる実力が必要で、
これがないとそもそもAIに正しく動く行動を作る指示ができない。
本当そうなんですよね。そうなんだよな。
それをちょっと一歩乗り越えて、例えば自分が知らないもので、
AIだったらできるやろうみたいな感じで、
例えば自分が知らない言語のラストを使うとかゴーランを使うとか、
PHPかもしれないですけど、そういう新しい言語で何かを作ろうと思って指示したりすると、
それが本当にベストプラクティスなのかどうか、
ようわからんコードが作られたり、ようわからん修正が行われたりとかするんですよね。
AIの活用と課題
その結果としても、多分スパゲティ以上のスパゲティなんですよね。
なんだこれみたいな感じのコードになったりとかする可能性は高いなって、
最近はよく感じてますね。
AIに正しく動くプログラムを作らせるためには、
1、使用をすべて正確に書く。
2、どんな手順で処理するかを正確に書く。
3、最終的にどのような処理結果を出力するか正確に書くというプロンプトが必要だと。
そうですね。
どういうふうに、どこに作ってほしいかみたいなのを含めて、
全部書かないといけないんですよね。
ルール付けとかはできるので、それを何度も書く必要はないと思うんですけど、
そこをちゃんとやらないとうまく強調できないかなっていう気はしますね。
続いて、こちらはちょっとまだ読んでないんですがタイトルが気になったので、
はてなブログの、じゃあおうちで学べるさん。
違う。
nweizoさんですね。
じゃあおうちで学べるブログから、
3年目までに身につけたい技術ブログの書き方という記事が出ております。
自分なんてまだ1年目、2年目、経験が浅いから書くことなんてない。
そんな思いを抱いていませんかというところから始まってますね。
実際どうなんでしょうね。
一番最初にこういう記事を書くのって、確かに私の個人的な経験で言えば、
1年目、2年目とかで何かを書きたいって思ったことはないと記憶をしてますね。
じゃあいつから書き始めたんだって言われると、
全然覚えてないんですけど、
割となんか、会社でPHPを触り始めてからのような気がする。
パールとかをその前とかにやってたときって、
本当に素人状態だったので、与えられる情報を見て、
それを実際に書いて、自分なりのカスタマイズして使うみたいな、
そういう感じだったんですよね。
発信してくれている人とか、本を書いている人が本当にすごい人っていう感じで、
自分はただそれに従うみたいな感じだったと思うんですよね。
その後、会社に入ってVBやったときは、
VBも本ばっかりだったかな、あとは多少ネットで、
すごくVB強い人とかが世の中にはいて、
そういう専門サイトっていうか、
VBのことめちゃくちゃまとめたサイトとかがあって、
そういうのを参考にさせてもらったりとか、
逆引き時点みたいなものがあって、
そういうのを参考にさせてもらって、
やっぱりそのときは自分からあえてそんな何かアウトプットしたいって、
多分それなりのオリジナリティのあるコードとかは書いてたかもしれないですけど、
出したいって思ったことは全然なかった気がするし、出してなかったですね。
で、PHP触り始めたぐらいから多分、
仕様目が変わったような気がしますね。
多分ブログっていうか個人用のメモみたいなものを書いてたりとか、
あとPHP勉強会で何か発表したりとか、
そのくらいからやり始めた気がしますね。
なんなんだろうな。
なんでPHPになったらそうなったのか、
全然わかんないんですけど、
こないだデブレルの100回記念でパネルディスカッションやったときに、
PHPユーザー会で運営とかもやられているこいほげさんに来てもらって話してもらったんですけど、
PHPユーザー会っていうか、
PHPのユーザーコミュニティってめちゃくちゃ初心者に優しい雰囲気が出てるんですよね。
そのときにも話してたんですけど、
私がちょっと前に、コロナ前かな、
PHP勉強会、東京のやつ参加したんですけど、
そのときに自己紹介タイムがあるんですね。
デブレルでもやってる自己紹介タイムって、
PHP勉強会にインスパイアされてというか、
参考にさせてもらってやってるんですけど、
その自己紹介のときに、
私、PHP3日前から触り始めて、
勉強会っていうのを見つけたんで来たんですって言ってる人がいて、
すげえなと思って、
これだけPHPっていうものが普及して、
もう多分25年以上とかになるわけで、
そんな中で新しくPHPに触り始めたっていう人がいて、
かつそういう人が触って3日で勉強会に来てみようって、
思ってもらえる雰囲気があるってすごいことだなと思ったんですよね。
多分それは今でも全然続いてるらしくて、
本当数日前から使い始めましたみたいな人も、
続々来てるんですよっていう話をこいほうげさんがしてて、
本当PHPのビギナーウェルカムな雰囲気は、
すごいなとつくづく感じますね。
いろいろ激変があったと思うんですよね。
PHPって25年くらい前って、
パールから派生して出来上がって、
もうウェブ業界をかなり接近したと思うんですよね。
そんな中でもなんだかそのPHPは、
ある程度おもちゃ的な雰囲気というか、
ライトなものを作るのにはいいけど、
エンプラ系には向かないみたいな感じで、
Javaとか.NETとかが常に存在していて、
そんな中でワードプレスみたいなものができて、
それこそインターネットのサイトの何十パーセントはワードプレスでできてるみたいなこと言われたりとか、
Drupalみたいなエンプラでも耐えられるCMSができたりとか、
私が前にいた会社だったらもう社内システムを全部PHPで作ったりとか、
あの頃はまだPHP3で作り始めたような気がしましたね。
やりつつもRailsみたいなものとか、
Jangoとか出てきたりとか、
すごい変遷がいろいろあったと思うんですけど、
今なおね、生き残ってバリバリ使われてて、
初心者にもどんどん来てもらえるとか、
最近はね、カンファレンスもすごい広がったりとかするんで、
PHPすごいなーって思うんですよね。
で、その中、全然話関係なくなってましたね。
3年目までに身につけたい技術ブログの書き方というところで、
その技術ブログを書く、
技術ブログの価値
執筆がもたらす価値というところを3つ挙げてくれてますね。
まず1つ目、思考を整理する鏡と、
説明できることは理解している証拠だという言葉があります。
コードを書くだけではわからなかった理解の穴が、
他者に説明しようとする瞬間に見えてきます。
ブログ執筆は自分の思考をクリアにし、
知識の定着を促す強力なツールですというふうに書いてありますね。
あともう1つ目が、知識の共有経済への参加と、
オープンソースのコードを共有するように、
あなたの解決策や洞察も共有価値があります。
あなたが30分かけて解決した問題は、
記事を通じて何百人もの時間を節約するかもしれませんということですね。
最後3つ目、思考の足跡としてのブログと、
あなたの思考プロセスと問題解決能力を示す生きた証拠になりますということですね。
技術ブログにも6つほど種類があるというところを挙げてくれていて、
1つ目、学習ログ&チュートリアル体験記、
新人に特におすすめなものということですね。
これは先ほどの3年目というところでおすすめなんだと思います。
次、2つ目、バグハウント記事、
特定のバグや問題を発見し、追跡し、
最終的に修正するまでの旅を記録するブログということですね。
3つ目、環境構築ガイド、
開発環境や特定のツールのセットアップ方法を解説するブログということですね。
4つ目、学んだ教訓記事、
プロジェクトや技術的課題から得た教訓や気づきを共有するブログ記事と。
5つ目、プログラミング言語の乗り換え記録、
既存のプロジェクトを新しいプログラミング言語やフレームワークで作り直した経験を共有するブログと。
これ結構人気があるというか、
フレームワーク乗り換えとかだけではなく、
アーキテクチャを変えたりとか、設定の変更をしたことで負荷がすごく下がったとかそういうのがあったりしますよね。
あと6つ目がシステム開発の舞台裏、
システムや機能をどのように考え設計し作り上げたかを詳しく説明するブログということですね。
7つ目、技術トレンドの考察、IT業界の流行りや新しい技術の動きについて自分なりの意見や分析を述べるブログですということですね。
これはあれですね、3年目ぐらいはちょっと荷が重いかもしれないですね。
最後8つ目、技術の性能比較と検証、これはこれで人気ありますよね。
自社の技術がそれに絡んでいたりすると他社との比較になってしまうので、それは書きづらいことはあるかなと思いますね。
全然自分たちがサードベンダーとしてやる分にはいいんですけど、
例えば自分たちがAWSのゴールドパートナーですみたいな位置づけのときに他のところ、GCPとかAzureとかそういうのを比較したりするとね、
結局自分たちの立場みたいなものを強調するだけだったりしちゃう場合があるので、
ちょっとこの技術の性能比較みたいなところはやり方を考えなきゃいけない場合もあるかなと思いますね。
アイデアの創出と学び
始めやすいブログパターンの選択というところで、
学習ログとかチュートリアル体験記は公式ドキュメントには書かれていない、実際にやってみたらどうだったかという記録なので、
今後続く学習者にとっては貴重な情報源になりますということですね。
あとは環境構築ガイド。
一度苦労して設定した開発環境の手順は記録しておくだけでも大きな価値があります。
読者や半年後の自分も同じ苦労をせずに済むでしょうということですね。
3つ目、バグハウント記録。
解決に時間がかかった問題はその過程を含めて記録する価値があります。
デバッグの試行プロセスこそが技術的な洞察を含んでいます。
学びの教訓、何々だと思っていたけど実際は違ったといった気づきは技術記事として非常に価値があります。
誤解やミスコンセプションを正す内容は多くの人の時間を節約しますということですね。
ネタがないという場合は日常からネタを発掘する必要があるというところで、
学習過程でのなぜとか、あとは繰り返し説明していること、
チーム内で何度も同じ説明をしている内容は記事化する価値が高いと言えるでしょうということですね。
検索しても満足な答えが見つからなかった問題とか、あれと思った瞬間、予想通りに動かなかった行動とか、
そういったところをメモとして残しておくということですね。
ジェームス・W・ヤングの名著、アイデアの作り方という本に、
そういった日常の発見から何か新しいアイデアを作っていくという方法が書かれているらしいです。
アイデアの作り方という本ですね。
88年の本なんですね。これは読んだことない気がするな。
もうこれはあれですね。
Kindleにもないですね。
それもポストアしておいたんですけど、アイデアの作り方という本ですね。
その本が多分参考になるかと思います。
あなたのあれという瞬間は、ヤングの想像プロセスの一部として考えることができます。
資料収集の段階で日々の開発や読書、学習から知識を蓄え、
それらの情報を頭の中で検討し、関連づけようとし、
一度問題から働いて、無意識に働かせて、
そして最後にあれという気づきやひらめきが訪れるということですね。
ブログが書けないという方は、この思考プロセスのどこかが欠如していることがほとんどです。
どの部分が欠如しているかによって対応方法が変わりますというところですね。
全部で5つ挙がっていて、情報収集が不足している人、
情報の紙砕きが不足している人、リラックスの時間が不足している人、
ひらめきを見逃している人、書き切れない人という全部で5つ挙がってますね。
これは多分3年目だけじゃない気がする。
アウトプットが習慣づいていない方は、
この記事を読むといろいろ学びがあるんじゃないかなという気がしますね。
これは別の記事ですけど、ギガジンの記事ですね。
AIがすべてのプログラミングコードを生成するようになるので、
コーディングを学ぶのは時間の無駄とリプリットのCEOが答えると。
なかなか刺激的な内容かなと思うんですけど、
このAIがプログラミングを生成するようになるとかなってるっていうのは、
これは多分納得できると思うんですよね、皆さん。
また、すべてのプログラミングコードをAIが生成するようになったからといって、
それをそのまま100%飲み込めないと思うんですよね。
どうなんだろうな。
例えば、使用書をすごく正確に書いて、
その使用書に沿ったプログラミングが完璧に作られるという未来が来たとしても、
それをそのまま導入できるんですかね。
できるのかな。
例えば、例えばってあれなんですけど、車あるじゃないですか。
車、我々、車のエンジニアの方とか車業界の方じゃないとして、
我々とかが車に乗っかって運転して移動してとか、
あんなすごく燃えるガソリンとかを平気で車に突っ込んで運転してたりとかするのは、
車の原理を知らなくても車の運転はできると思うんですね。
なので、これも多分そのAIがプログラミングして、
そのAIがプログラミングしたものを知らなくても、
我々はそのサービスを使うことはできると思うんですよ。
なので、AIが全部プログラミングしてくれれば、
我々がプログラミングを覚えなくていいというのは、
ある意味合ってるような気はするんですよね。
だって我々ね、車の細かいこと知らないじゃないですか。
超昔の車とかだったら、
それこそ自宅で直したりとかする人もいましたけど、
今ってもうほぼほぼソフトウェアで動いているので、
普通の素人が直せる場面とかほとんどないわけですよね。
タイヤのパンクぐらいとか直せますけど。
っていうのを考えると、
もう本当に高度な世界になっていくと、
AIの作り出したものが完全にブラックボックスだったとしても、
正しく動いてるからいいんじゃないみたいな、
世界になる可能性はあると思うんですよね。
ただ、そのAIが作り出したものを、
誰かが保証しているからこそ使えると思うんですよ。
その車を誰も関与してなくて、
ガチャポンガチャポンって出来上がった車を突然乗って、
動かすのってなかなか難しいと、
信用するの難しいと思うんですよね。
やっぱりその車のトヨタだったりフォードだったりベンツだったりとかっていうところが、
その車の品質をちゃんと保証してくれているからこそ、
我々は安心してその車を使えるというところがあると思うので、
じゃあこのAIが作ったものを誰が保証してくれるんですかっていうのが、
問題になると思うんですよね。
その時に超ハイレベルな人たち、
そのAI自体を作る人たちは多分一つはありますよね。
でも彼らは、
LLMが作っているものは100%正しいわけじゃなくて、
単純にその言葉を詰め合わせて作っているだけなので、
完全に信用はできませんよっていうのは言ってるわけですよ。
今だってチャットGPTの下の方とかに、
必ず正しいとは限りませんみたいな注意書きが入っているわけじゃないですか。
ただなんとなく正しいものが出来上がっているから、
それを採用してますけど、
ただやっぱり、
生成されたものを一応確認して、
やっぱりここ違うなっていうところがあればそれを直しているわけなので、
AIとプログラミングの未来
多分100%、
AIが正しいコードを生成してくれる未来って、
来ないと思うんですよね。
っていうところもありつつっていうところで、
この記事がもうコーディングを学ぶ必要はありませんと、
発言しましたということですね。
この発言は、コードを学ぶ価値はまだあると思いますか?
という質問に対する答えです。
このレプリットのCOのマサド氏は、
回答として、最近ダリオ、
オーソドビッグのCOですね。
その方が言ったように、
全てのコードがAIによって生成されるようになるでしょう。
私が想定している最適化のシナリオでは、
AIエージェントはどんどん進化し続けると思います。
そうなると、コードを学ぶ価値はあるかという問いの答えは、
以前とは違って、いいえとなります。
コードの学習は時間の無駄になると思いますということですね。
3月中旬に行われたイベントで、
今後3から6ヶ月でAIがコードの90%を書くようになり、
12ヶ月後、つまり来年の3月には、
ほぼ全てのコードがAIによって生成されるようになるかもしれませんと、
予測を示しているということですね。
Zohoの創業者の方も、
AIがコードの90%を書くだろうと言われれば、
私も同意します。
なぜなら、プログラマーが書くコードの90%は定型文だからですと、
述べていますということですね。
そうですね。これはなんか、
すごく思純に飛んでる気がするんですよね。
AIと開発者の未来
ここの部分を、個人のエンジニアとしてはもちろんですけど、
DevRelとして開発者に相対しているところの人たちも、
ここをちゃんと考えないと、
いつの間にか開発者いなくなってたとかね、
開発者が自分たちのツールをハンドメイドで使ってくれるんじゃなくて、
AIからタッチするのが当たり前になっているみたいな感じになると、
それこそ、LLMテキストとか、
LLMフルテキストとかですね、そっち側の方に力を入れた方が、
開発者フレンドリーになる可能性は、
あるんじゃないかなと思うんですよね。
この未来は、もう間近ですね。
3から6ヶ月で90%、
1年後には、
3から6ヶ月、
3から6ヶ月でAIがコードの90%を書くようになり、
1年後には、ほぼ全てのコードがAIによって生成されるようになるかもしれませんということですね。
わお、すごい。
確かに、そうなりそうな気もしますかね。
この間、セールスフォースが、
今年のエンジニア採用凍結みたいな話もあったりとかして、
そうすると、
本当、生成AIでどうにかなってしまうという風になる未来が、
すぐ近くに来ているのかなという気がしますね。
ではですね、今日のメインテーマの方に入っていこうかなと思います。
今日のメインテーマは、もう一度チャレンジしたいことというところで、
ご意見いただいております。
再挑戦の重要性
はい、まず最初が、
デブレルネームジャーニーマンさんですね。
いつもありがとうございます。
思いつくものが多すぎました。
失敗を挽回したい意識はなく、
もう一度初回を体験し記録し、
その時だからこそ気づける、感じられることを学び直したい思いです。
これはあるね。
今考えてみれば、
もうちょっと初回を楽しめばよかったって思うときありますよね。
知っちゃってると感動が半減することはあると思うので、
もう一回頭まっさらにして体験できたらいいのになっていうことは確かにありますね。
バイクツーリング、プログラミング言語習得、
開発プロジェクトマネジメント、
大規模投資倫儀、転職などが思い浮かびました。
おぼろげには覚えていても、
記憶から抜け落ちていることが多いので、
もう一度チャレンジして体験してみたいです。
人間、今のところ過去には戻れません。
初回にこだわらなければ、
チャレンジする機会はこれからもあるので、
改めてチャレンジについて考えていきたいと思いますということですね。
確かに。
日常の中に溶け込んじゃってる初回のことって、
日常に通って過ぎて後から思ってみるとみたいなことってありますよね。
そういった意味では、
YouTuberの人とかって割といいと思うんですよね。
Vlogみたいな感じで、
自分たちの活動を何らかの形で残していたりとかするので、
後から見直しやすいのかなと。
記憶の新鮮さみたいなところ、
ここにジャニーマンさんもおぼろげには覚えていても、
みたいに書いてありますけど、
それを思い起こすのには、
Vlogみたいなものはいいのかなって思ったりしますね。
昔は携帯電話ありましたけど、
携帯電話で写真撮らなかったもんな、全然。
スマホになってから撮るようになりましたけど、
その前のPHSとか、いわゆる柄系の携帯電話とかで、
写真はほとんど撮らなかった気がするんだよな。
ああいうのも撮りたいって思うインターフェースってありますよね。
30万画素とか、すごい画素数低い状態とかで、
なかなか撮りたいって思えなかったのが、
今にしてみればちょっと悔やむところもあるかなっていう気はしますね。
画像だけで残すのがいいのかちょっとわからないですし、
今は逆にみんな写真撮りまくってて、
実際の目で見てないんじゃないの?みたいに思ったりするところもあったりするので、
やっぱり自分の肌感というか、五感で感じるのは大切だよなと思うんですけど。
そうですね。
例えばその99年ぐらいとか、私が学生だったときとかも全然写真残してないですし、
初めて海外に行ったのがたぶん97年とか98年、97年ぐらいかなとかに、
たぶんテキサスかなんかに行ったのが一番最初だったと記憶してるんですけど、
そのときも全く写真とか撮ってないんですよね。
あのときに撮ってればって思ったりもしますけど、
見返すことたぶんないんだろうなっていう気もしますね。
あったらあったで見返さないみたいに。
あとは初めて富士登山したのが私の父親と一緒に行ったんですけど、
あれは写真撮ってはあるんですよね。
写真は撮ってあるんですけど見返すこともないかな。
これ難しいですね。
初回を残しておくっていうのは大事な気がするんだけど、
残してても見ないっていうね。
しかもまあデジタルデータだからな。
富士山とかで検索したらもしかしたら出るのかもしれないですけど、
アナログだとね、物が邪魔になっちゃって、
もうそれごと捨ててしまうこともあったりするかなと思うんで。
このジャニーマンさんからコメント来てますけど、
日記もおすすめですっていうね。
日記はVlogとも同じですけど、
その時の自分のこの気持ちを残しておくっていうのは
とても大事かなというのは確かに思いますね。
小田翔さんからは、柄系でも初期はまだしも後期は200万画素カメラを搭載している。
200万画素って言っても今から見たらもうへみたいな感じの画像ですよね。
どうなんだろう。200万画素とかで撮ってたら
L版とかで印刷してもそれなりに見えたりするのかな。
そうですね。写真撮っても見ない。めちゃ分かる。見ないんだよな。
そうなんですよね。
今、私はノートに日記的なものを、
全然皆さんが想像するようなちゃんとした日記じゃないんですけど、
そういうものは残していて、そこはモバイルプリンターで
写真印刷できる、その場で印刷できるやつがあるので、
それ使ってその写真を印刷してるんですね。
ノートにペチペチ貼って、あと適当な記録書いてみたいな感じで
残すようにはしてて、そこでは写真使ってるんですよね。
見返すことはほとんどないんですけど、一応撮った写真もったいないしみたいな感じで
1日大体3、4枚ぐらいとかですかね。写真貼り付け、そこに一言コメント書いてみたいな感じで
残すようにはしてますね。
それで無理やり写真の再利用をしてるみたいな感じですね。
こういう記録系大事ですよね。
ではもう一人、デブレルネーム西から来た馬面の男さんですね。
いつもありがとうございます。
今回のテーマはもう一度チャレンジしたいことバージョン2ですね。
過去のことで今ならもっとうまくできる話思いついたらと思っていますが、
あまり過去を後悔しないタイプなのか今週はあまり出てこないです。
絞り出すと、結婚してから子供が生まれる前に妻ともっと旅行に行けばよかったなぁと
よかったかもなぁと思います。
行かなかったわけではないですが、遠出の旅行などはなかなか行けないので
旅の思い出はもっと作っておけばと思いました。
西から来た馬面の男さんはですね、先週も送ってくれていて
そこにはですね、コロナ禍でオンラインが中心になりかけたとき
リアルの勉強会はなくなり、オンラインを模索し始めた当時のことです。
2020年3月から4月ですね。
オンライン配信の方法についていろいろなツールや代替サービスが
復興してきた頃でした。
もう少しいろんなツールや組み合わせを体験してもよかったなぁと思います。
今は定番のオンラインツールとかオンライン交流の手法が確立している感じですが
当時は本当いろいろあったなと記憶しています。
雑でもいいので自分で触ってみるをやって試してみたかったなという感じです。
確かに当時いろいろありましたよね。
もう今じゃどうなっちゃったんだろうって検索することもないかもしれないですね。
本当に土手版で結局ZoomとGoogle Meet
あと配信プラットフォームとしてのYouTubeくらいですよね。
音声のやつ、クラブハウスが出たりとか
この間なんかボイシーの記事とかもありましたけど
ボイシーとか、リモとか
オービスね、あったあった。
あとスペーシャルチャットとかありましたよね。
Xとかもやってましたよね。今でもやってるような気がしましたけど。
音声の仕組みとかありましたよね。
確かにこの時いろんなチャレンジが生まれたような気がしますよね。
生まれたんですよね。
ただあまりにも生まれすぎて
みんなこれで疲れちゃったみたいな感じだったかなっていう気は残念ながら思いますかね。
あともう一個は奥さんとの旅行にもっと行けばよかったなというところですね。
別にこれはお子さん大きくなってから行けばいいだけだと思うので
全然今からでも遅くはないんじゃないかなと思いますね。
子供のことで思うと
一人目の出産は立ち会えたんですけど
二人目の出産の時に立ち会えなかったんですよ。
その理由が一人目の子供の幼稚園に迎えに行ってる間に生まれちゃったっていうのがあって
あれはちょっと順番間違えたなっていう感はありますかね。
先に子供の方に行っておけば間に合ったかもしれないですけど
理由があって後から行かなきゃいけないみたいな感じになって
行かざるを得なかったんですよね。
行ったらいろいろ時間かかっちゃって戻ってきたらもう生まれてたみたいな感じでしたね。
そんな話もありそうというところで
イベントの企画
最後イベントのご案内ですね。
思うところじゃないんですけど
今月デブレル東京のイベントを企画してないんですね。
多分また来月からやるかなと思うんですけど
コミュニティのあり方をちょっと考えてもいいんじゃないかなっていう気が
個人的にしててまだこれ運営メンバーとかにも全然言ってないんであれなんですけど
ここに運営メンバー2人くらい聞いてるんで
軽くシェアしておくと
もうちょっとライトに誰でもイベント作ったりとか
イベントっていうとすごい大事に聞こえちゃうんですよね。
もっとカジュアルに軽く集まって軽く食べるみたいな
軽く何かをやるみたいなのが
もうちょっとUGOのタケノコのようにやりたいなっていう思いがありますと
そのために満釣りのイベントですみたいな感じで
毎回企画して場所決めてみたいな感じでやってると
ちょっと重いというかですね
今時とは言わないですけど
コミュニティのあり方としてどうなんだろうなーみたいなところが
ちょっと感じてたところが
こないだ100回やってそう感じたっていうところなんですけど
ありましたね
インドとかめちゃくちゃ気軽なんですけどね
ちゃんとやってるところもあると思うんですけど
私とかがデブレルミートアップインベンガルールとかやる場合って
もっとすごくライトに
誰か喋りたい人つったらポンポンポンって手が挙がって
場所貸してくれる人つったらまたポンポンって
いいよみたいな感じで言ってくれたりとかして
じゃあやろっかみたいな
ちょっと2週間くらい前にイベント設計するみたいな
全然ザラにやったりとかするんで
もうちょっと雑にやりたいんですよね
しっかりやると
しっかりやらなきゃいけないみたいな感じの雰囲気になっていくんで
もっと雑に
もっとみんなラフに楽しめる形にできると
いいんじゃないかなーって思ったりしますね
小田翔さんは
井戸端会議的な感じですかね
そうですね
運営がやらなきゃいけないみたいな感じの雰囲気にしたくないんですよね
みんなやればいいし
そこにいる人たちに集えばいいしみたいな
ジャーニーマンさんから
ファミレス会をやりたい
いいですね
ファミレス会
そのくらいカジュアルでいいと思うんですよね
別に毎回何十人集めなきゃいけないみたいな感じではなくですね
コミュニティ
人が集まれば
それがコミュニティだと思うので
大げさにしすぎるのも良くないかなと
誰かが何かを話す
それが聞きたい人が集まる
そこに対して感想を言ったりとか
自分なりの考えを言うみたいな
そういう集まる場所であれば十分なのかなと
それがオンラインでもいいと思いますし
オフラインでファミレスでやってもいいと思いますし
デブレルとかだとバスケとかもやったりするので
そういうバスケで体を動かした後に喋ってもいいと思ったりとか
あとは何でしょうね
モンハンやってもいいと思いますし
読書の輪読会とかでもいいと思うんですけど
あんまり大げさにやりたくないなっていうのが
ちょっと最近思い始めたところです
ただその代わりにもっと
うごむたけのこようにボコボコできればいいかなっていうのが
ちょっと思っているところになっております
デブレルラジオの継続
とはいえこのデブレルラジオ自体は
定期的にこういうふうにウィークリーで配信できるのは
これこれで楽しいので続けていこうかなとは思っております
では次回は210回目ですね
4月の8日にまた配信していこうかなと思いますので
ぜひ皆さんこれもお気軽にご参加いただければと思っております
では皆さんまた来週お会いしましょう
さよなら
