DevRel Radioの紹介
皆さんお疲れ様です。1月14日ですね。 夕方5時半になりました。
DevRel Radioの198回目、やっていきたいと思います。
まず最初にですね、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティで やっているネットラジオになります。
毎週火曜日、夕方5時半からですね、 1時間程度お送りしているというもので、
今日でもう198回目ということで、 約3年以上ですかね。
もう4年目に入ろうかみたいな。 そのぐらいのネットラジオになります。
DevRelっていうのはですね、 デベロッパーリレーションズの略で、
自社とか自社製品と外部の開発者との間に 良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、 そんなDevRelに関わるような方々、
例えばテクノロジーエヴァンジリストとか、 コミュニティマネージャーとか、
デベロッパーアドボケートとかですね、 マーケターの方とか、
そういった方々が集まってイベントをやったりですとか、 情報交換をしているといった
そんなコミュニティになっております。
DevRel Tokyoの公式サイトがありまして、 devrel.tokyoというサイトですね。
そちらからスラックに参加したりとか、 最近のイベントの状況とかですね、
見ることができますので、 ぜひウォッチいただければと思います。
あとは公式のXアカウントですね。
atdevreltokyoというアカウントがありまして、
普段はsharpdevreljpっていうハッシュタグで ポストしてますので、
ぜひアカウントフォローいただいたりとか、 そちらのハッシュタグをウォッチいただけると嬉しいです。
2025年の技術予測
というところで、
今日のメインテーマがですね、 2025年は〇〇元年となっております。
〇〇元年ってIT系でよく言われるのかなっていう気がするんですよね。
最近だと何でしょうね。
多分LLM元年とかね、 多分去年あたり言われたんじゃないかなとか。
あとLinuxデスクトップ元年もね、 毎年のように言われてたりとか。
あとは何でしょうね。
IoT元年みたいなことを言われたときも あったりしたのかなとか思うんですけど、
今年はどういったテクノロジーが来るかというところでですね、
その〇〇のところに当てはまるやつをですね、 ぜひ皆さん予想していただければと思っております。
そちらのほうはですね、まだ6時過ぎぐらいから、 あと30分以上してからですね、
取り上げていこうかなと思いますんで、
ぜひ今のうちにですね、皆さん〇〇元年に当てはまるところ。
大喜利的な感じではあるんですけれども、 ぜひコメントいただけると嬉しいですというところで、
早速コメント来てますね。
じゅんさんからですね。
こんばんはと来てます。
はい、こんばんは。よろしくお願いします。
ではですね、6時過ぎぐらいまでは、 最近のデブレル周りのニュースとか記事とか
取り上げていこうかなと思うんですけど、
まず1個目、これからでいいかな。
これは理系学生日記っていうハテナブログなんですけれども、
そちらのGitHubコーパイロットワークスペースが提供されて、
僕たちの開発はどうなっていくのかという記事が出ております。
これね、先ほど言ったLLMもそうですし、GitHubコーパイロット、
さらにこの記事の中で取り上げられている GitHubコーパイロットワークスペースですね。
この辺りが出てきたこと、あと何ですかね。
Vault.newとかもそうですかね。
すごい開発が一変しそうというか、
ずいぶんトレンドが変わりそうなテクノロジーが 続々と出てるなっていう気がするんですよね。
これをデブレル的な視点で見ると、
そのビギナー的なこれから学んでいくとか、
これから仕事で開発に取り組んでいくみたいな人たちと、
もうすでに3、40代ぐらいでプログラミング経験とかも豊富な方々との ギャップがすごく大きくなりそうな予感がするんですよね。
この理系学生日記さんのところでも、
一番最後の結論としては、
設計が重要になるというふうに書いてあるんですよね。
生成AIが高度化するほど、設計の質がプロジェクト全体の成功を左右する決定的な要因となっていきそう。
設計大事というふうに書いてあって、
確かにその通りだなと思うんですけど、
設計をきちんとやれば適切なコードとかプロジェクトが出力されて、
そのまま使えるみたいな感じになっていくんだろうなとは思うんですよね。
そうなると、出力されたコードが正しいものであるかっていう検証が、
プログラマーなのかな、コードを吐き出した出力した方の責任になってくると。
多分そのときにコードを理解しなくても、
要件に合わせた自動テストが出力されて、
その自動テストをちゃんと全部パスしていれば、
このシステムはおそらくちゃんと動いているだろうみたいな、
そういう世界観になっていくんじゃないかなと思うんですよね。
そしたら多分コードとかほとんど書かなくなっていくので、
そのデブレルみたいなところの立場の人が、
開発者に対してどうアプローチして、
どういうふうに採用してもらうのかっていうのが、
すごく難しくなっていくんじゃないかなという気がしています。
さらに言うと、多分その生成AIのGitHubコーパイロットワークスペースとか、
それ以外のツールも多分いろいろ出てくると思うんですけど、
そのツールが特定のバックエンド系のサービスとか、
特定のSaaSとかに紐づいてたりすると、
もう自然とそのツールが採用されていくと思うんですよね。
だからある意味デファクトになっているようなツールとかは、
すごく有利になるんじゃないかなと思っていて、
例えばDeFiでしたっけ?
DeFiっていうLLM系のオープンソースのツールがあるんですけど、
そのツールの場合、メール送信の部分でSMTPをサポートしてるんですけど、
あとリセンドなんですよ、サポートしてるのは。
リセンドのAPIキーを入れるとメール送信できるっていう設定になってるんですね。
そうするとそのDeFiを使いたいという人は、
SMTPの設定してもいいですし、
それかリセンドのアカウントを取って、
リセンドのAPIキーを発行して設定するみたいな感じになって、
自然と採用数が増えていくっていう流れができるんですよね。
ということを考えると、
そういう生成してくれるようなツールとインテグレーションを組んだほうが実は早い。
一人一人の開発者にアプローチするよりは、
そのツールのほうとインテグレーションしたほうがよっぽど取り入れてもらえるというか、
自然と採用してもらえるっていう流れにできるんじゃないかなと思ってるんですよね。
そうしたときにどういうふうにアプローチするべきかって、
結局デビュレルっていうよりはパートナーリレーションみたいな部分が重視されていくんじゃないかなって思ってるんですけど、
どうなんでしょうね。
そういう世の中もなかなかやるせないなと思いつつも、
いわゆる手を動かす開発を行う人口がどんどん少なくなっていくような気がするんですよね。
それはもう年齢とかじゃなく、
生成AIっていうところでかくっと人が一段階、二段階ってどんどん減っていってしまうような予感がしているので、
アプローチするエンジニアの数が減ってしまうと、
デビュレルの活動自体がすごく難しくなっていく、
高度化していく部分も出てくるのかなと思ってますね。
そんなことをGitHubコーパイロットワークスペースが提供されて、
僕たちの開発はどうなっていくのかという記事ですね。
こちらを見ていてそんなことを思いましたね。
生成AIと開発の未来
採用してもらうプロダクトを採用してもらうとか、
プロダクトを使い続けてもらうとかっていう文脈でのデビュレルっていうのは求められ続けるのかなとは思うんですけれども、
このやり方みたいなものがきちんとAI時代に合わせた考え方にアップデートしていかないといけないのかなと。
そういうワントゥーワンでやっていく方法。
昔、2016年ぐらいですかね、9年前ってことですね。
その時のデビュレルコンのロンドンでマシューっていう主催者とかがよく言っていたのは、
100回のクリックよりも1回の握手だったかなっていうようなことを言っていたんですけど、
多分そのアプローチではなくなってきつつあるのかなというふうに思ったりしますね。
今のところまだそういう新しいツールでガンガンやっていこうみたいな、
まだ今お試しみたいな部分があるのと、
生成されたものに対する信頼性みたいなところで、
まずそのまま鵜呑みにできないっていう部分があったりするので、
従来のデビュレルの立ち位置っていうのも十分生きてくるかなと思うんですけど、
そのうちこういうGitHubコーパイロットワークスペースをSIとかの方がガッツリ使ってたりとか、
事業会社の人たちがもう開発会社頼らずにこういうツールでガンガンやっていきますみたいになっていくと、
ちょっと時代が変わっていく可能性があるんじゃないかと思ってますね。
なかなか怖いですけど、そこに逆らってもしょうがないと思うんですよね。
なので常に使ってもらうためには多分パートナー戦略っていうところですね。
生成AIを使っておにゃららするようなサービス会社さんとのインテグレーションみたいなところを強化したほうがいいとか、
あとは生成AI向けのコンテンツの出し方みたいなものを結構考えていくべきなんじゃないかなと思ってますね。
公社の方に関して言うと、Googleの検索がめちゃくちゃ使われなくなってるっていう話があって、
どこだったかな?
えっとですね、多分Togetherでたまたま見たのかな?
あ、これかな?
えっとですね、Togetherの記事でブログのPVがどんどん落ちてると思ったら、
Google自体のトラフィックが1年前の4分の1になってたと。
これの要因みたいなところで、
AI側で解決しちゃってるんじゃないですか?みたいな意見があったりしたんですけど、
確かにその可能性はすごく高いかなと思っていて、
多分皆さんも使ってると思うんですよね。
検索、Chromeのアドレス版のところに上手くやると、
Chat GPTにそのまま質問飛ばせるようになってきたので、
私もちょっと込み入った質問とかプログラミングで、
ある程度自分に最適な答えとか欲しいときに、
Googleで検索して一つ一つチェックするっていうよりは、
もうまとめて質問して、
Chat GPTにうまく最適な答えを返してもらうみたいなことをやっちゃったりとかしているので、
Googleを使わずに生成AIで解決しちゃうっていう習慣は、
今後どんどんトレンドとかデファクトになっていくんじゃないかなと思ってるんですよね。
それはDevRelっていう視点で考えると全然OKで、
むしろサッコーバーフロー見ます、聞いた見ます、個人のブログ見ます、
公式ドキュメント見ますとか、
いろんな情報リソースを読んだ上で、
最適な自分の課題解決法を見出していくみたいなのって、
すごく邪魔くさいと思うんですよ。
私がよく考えるのは、
一つのブログ記事の中で、
主題がQになっていて、本文がAになっているっていうQ&Aの方式になっていると、
開発者の人はGoogleで検索をして、
自分が困っていることを検索したら、
もうバッチリタイトルにその解決法が出てきます。
実際その記事を読むと、
余計な前書きというか、余計な情報なしに、
ちゃんと答えにたどり着く最短の内容が書いてあって、
じゃあこれで解決できるって言って、またすぐ開発に戻れるっていう、
いかに自分たちの公式サイトとか、
自分たちのドキュメントとか聞いたの記事とかに、
長い時間滞在させないかっていうのが大事だと思ってるんですね。
そしたら開発者は自分の開発っていうところに、
ずっとフォーカスし続けられるので、
ある意味今回のChatGPT使った検索とかにしても、
なんか困ったからChatGPTで質問して、答えをもらって、
OK、OKって言ってまたすぐ開発に戻れるっていうのは、
これはすごく幸せなことだと思うんですよね。
なるべくそのハルシーネーションを起こさないように、
いい、正しくAIが、LLMが理解できるコンテンツを提供しなきゃいけないと思っているので、
その意味でドキュメントであったりとか、
ブログであったりとか、
様々な条件に応じた記事を量産しておくことによって、
生成AIの最適化
オープンAIとかクロードとかに正しい答えを返してもらえるようにするというのが、
コンテンツクリエイター側のデブレルのやるべきところなのかなという気がしてますね。
コードっていう側面で考えると、
SDK的なものもそうですし、
デモアプリとかもいろんな条件でいろんなコードを書いて、
それをGitHubの中にオープンで入れておくことによって、
それを正しいAIがいい感じに修正して、
ユーザーに対して届けてくれるっていう感じになるので、
そこはコンテンツの部分に関しては、
どんどん作っていくべきだと思うんですよね。
今のところ、LLMってとにかく学習量がいっぱいあれば、
どんどん賢くなるっていう前提になってるんで、
それって正直どうなんだろうなって個人的には思うんですけど、
今のところそれが最適っていうことになってるんで、
どんどんいいコンテンツを作っていくべきだと思うんですよね。
結構GPT-3とかのときってクローリングしてるデータが古かったりしたんで、
それ以降にサービスリリースしたものの使い方とかを
ChatGPTに聞くとすんごい嘘コードが吐き出されてたんですよね。
それを信用する人は多分その時代そんなにいなかったと思いますけど、
それをコピーして実行して動かねえじゃねえかつって、
そのプロダクト自体使えるかつってやめちゃうみたいになったら、
すごい残念なことだと思うんですよね。
ある意味こっち側としてはプロバイダー側としては何もしてないのに、
生成AIがハルシネーションを起こしたせいで勝手に失望して
プロダクトを使うのやめられちゃうみたいな感じになる可能性があったんで、
結構きついなって思った時期あったんですけど、
最近はクローリングの質が良くなったりとか、
あと最新のデータにも対応してくれるようになってきたんで、
今はそういう新しいプロダクトであったとしても、
割とちゃんと出たりしますね。
さらに多分もっと新しいプロダクトとかでいうと、
多分その生成AIに1回答えを出してもらって、
それに合わせてSDK作るのはいいんじゃないかなって思ったりするところがありますね。
そしたら嘘が本当になるみたいな感じで、
ハルシネーションをポジティブに受け入れるみたいなこともできるんじゃないかなって思ったりします。
そしたらユーザーの人にとっても、
全く同じコードが出るかどうかって分からないですけど、
生成されたコードがほぼそのまま使えるといった形にできれば、
ユーザー体験としても良くなりますし、
提供側としても勝手に失望されることがないという感じになるんで、
コンテンツに関してはもっとAIに寄り添った形で、
ある意味人が読むんじゃなく、
生成AIに読んでもらう前提で組み立てていってもいいんじゃないかなって思ったりしますね。
生成AIに読み込ませようと思うと、
なるべく重複は恐れないようにしないといけないんですよね。
重複している部分があったとしても、
まず一貫性を持って1から10まできちんと読み込ませられる文章みたいなものを作らないと、
かいつまんでパーシャルな部分だけで勉強させると、
間違った方向に流れていく可能性があるんで、
そういう生成AI最適化みたいなコンテンツの書き方も、
我々は勉強していかなきゃいけないんじゃないかなって思ったりしますね。
そんなテクニカルライティングに関するところで、
Dev.2の記事なんですけれども、
これはアダムス・アベ・バイオさんかな、ナイジェリアの方ですね。
Understanding the Four Cs in Technical Writingという記事が出ております。
テクニカルライティングの重要性
このCK好きですよね。
DevRelの3Cっていう元SendGrid、今はDataDocのBrandonとか、
私もDevRelの4Cとかで言ってたりとかしますけど、
これはテクニカルライティングの4Cというものについて書いてくれています。
4Cというのが一つが簡潔さですね。
英語で言うとConsciousnessかな。
これ分からないな。
で、簡潔さですね。
続いてが正確さですね。
Correctness。
で、正確さ。
次が明瞭さ。
Clarity。
最後は一貫性。
Consistencyというところで、
全部でテクニカルライティングの4Cというふうに言ってますね。
まず簡潔に書くことと情報を効率的に伝え、
文章を乱雑にする不必要な言葉や詳細を避けると、
読者を圧倒することなく、
必要な情報だけを提供するということですね。
続いてが正確さというところで、
技術文書が正確で間違いないことを保障すると、
適切な文法、スペル、苦等点、技術的詳細が含まれますということですね。
続いてが明瞭さ。
ターゲットとする読者が理解しやすいように書く。
簡単な言葉を使い、情報を論理的に整理し、
不必要な専門用語を避ける必要があります。
最後、一貫性。
技術文書全体のスタイル、書式、用語を統一する。
そうすれば、文書が見やすく、理解しやすくなります。
確かに、用語とか結構大事だと思うんですよね。
ある時には、GitHubとかよくあるんですけど、
頭のGだけ大文字で、あと全部小文字のパターンとHも大文字のパターンとか。
多分、Hも大文字が正式だと思うんですよね。
どうだったかな。
私いつもH大文字で書くんですけど、わからない。
そうですよね。
GitHubの社名とか見ると、
GitとH、両方とも大文字ですね。
それで統一してやればいいんですけど、
ライターによってHが小文字になったりすると、すごい燃やるんですよね。
あと、JavaScriptとかもそうですかね。
ユーザー知識の必要性
Sが小文字になってたりとか、JSで略すとか、逆に略さないとか、
そういうのが混在してたりするのは、すごい気持ち悪いなって思ったりしますね。
テクニカルライティングの簡潔さを向上させるヒントっていうのがありますね。
まず一つ目、冗長さを避けると。
情報を繰り返す不要な単語やフレーズを排除する。
例えば、現時点でという代わりに現在という。
あとは、能動的な文章にするとか、読者を考慮するとか。
そうですね、読者の考慮はね、時々なんか、ドキュメントを見たときに、うーんって思ったりするときありますよね。
その前提知識があまりにも求められすぎていると、
この文章、ある文章を理解するために、別な知識をまず学習しなきゃいけなくて、
さらにその知識を理解するためには、また別な知識を理解しなきゃいけないみたいな感じになって、
最終的に、そもそもどれを、何をしたかったんだっけみたいになっちゃうみたいな場合があったりするんですよね。
しかもそれが、そんな大した内容じゃないというか、そんな重要な単語じゃない場合もあるんですけど、
昔の授業に近いノリかもしれないですね。
昔、学生だったときに、すごい勉強苦手だった時期があって、
よく考えてみたら、授業をサボると勉強苦手になるんですよ。
その授業をサボったりとか、ちゃんと聞いてなかった結果として、
その時に話された前提知識が、次の授業の時に入ってきちゃうじゃないですか。
そうすると、最初、教授というか先生の話を聞いていて、
途中で理解できなくなるんですよね。その前提知識がないから。
そうすると、もうそこから先、全部何言ってるかわからなくなっちゃうんですよね。
っていうのがある時あって、その時はたまたま進級はできたんですけど、
その次の年からは授業の最初から、ちゃんと理解し続けようっていうのを心に決めて、
そうすると理解できるんですよ。一番最初の授業が理解できました。
そこで次の授業に行った時に、そこの前提知識もわかっているので、
ちゃんと理解できますっていう、その理解できるをずっと積み重ねていくと、
なかなかこう、意外と勉強面白いなみたいな感じになったりしたので、
やっぱりその前提知識をなるべくなくすようにドキュメントを書かないと、
読者を置いてけぼりにしてしまって、そうすると理解度もすごく下がってしまうというところはあると思いますね。
もちろん、我々が書くような技術者向けのドキュメントを小学生が理解できるかというと、
そういうわけではないと思うんですよね。
最低限の前提知識みたいなものをなるべく下げるというところですね。
もし何かの知識が絶対的に必要だというのであれば、
それに関してはあらかじめ前段階で書いておくっていうところかなと思いますね。
あと、例えばバースみたいなもの、バックエンダーザサービスみたいなもので、
データベースを理解しなくてもデータベースの代わりですみたいな、
そういうサービスとかであまりデータベースに関して細かいことを書いたりすると、
データベースが理解したくないからバース使ってるのに、
なんでデータベースの知識いるの?みたいな感じになっちゃったりするんですよね。
そこのバランスもすごい難しくて、とはいえインデックスとかの話とか出たりとか、
あとバースでデータベースは意識しなくてもいいはずなんだけど、
やっぱその正規化の部分とかを適切にやらないとパフォーマンスがうまく出ないみたいな場合もあったりして、
そうするとデータベースに関する知識っていうのが必要になってきちゃうんですよね。
昔、私が協力してたところで、NCMVっていうニフクラモバイルバックエンドアザサービスっていうのがあったんですけど、
そことかであったのが、データベースの前提知識いらないですよと、
我々がそのバックエンドのデータベースサービスとして使えますよっていうふうにやるんですけど、
そうするとすさまじい使われ方するんですよね。
マジかよみたいな、具体的に言えないのはあれなんですけど、
ある程度開発の知識がある方であれば、こういう使い方はしないだろうみたいな感じの使われ方とかしちゃって、
そうするとサースなので、共有サービスなので、全体に与えるパフォーマンス劣化がものすごかったんですよね。
そうすると、アカウントのところだけサービスを一回停止して、
お客さんに連絡して改善してもらわなきゃいけないとか、
どういうふうに改善したらいいかみたいなのを連絡したりとかしなきゃいけないとかですね。
なかなかサースとかで理解しなくてもいいですよって、
使うための敷居を下げたがために、
最低限このぐらいのナレッジは持っててほしいよなって期待しちゃってる部分が全くない方とかに使われると、
めちゃくちゃ痛いことになるということがあったりしましたね。
その分お金をいただければいいのかなとは思いつつ、
よくネットでクラウド破産みたいなトリガーを再起的に呼び出しちゃって、
凄まじい課金になっちゃってるみたいな場合があったりすると思うんですけど、
ああいう時にグーグルだけじゃないですね、
クラウドベンダーに泣きついたら許してもらいましたみたいな話があったりしますけど、
提供側から考えたら実際リソース食っちゃってるので、
使われちゃってるのでベンダー側としても痛いみたいな感じになってたりするんですよね。
そういう大きいテック会社から取ったらそれぐらいは許せるみたいな金額かもしれないですけど、
すごくちっちゃいまだスタートアップのSaaSとかでそういうことやられたりすると、
正直痛いんじゃないかなって思ったりしますね。
なので最低限こういうレベル、このぐらいの知識は持っていてほしいとか、
あとは何らかこうそういうことができないようにSaaS側でもエラーチェックなのか、
制限みたいなものを加えておかないといけないんだろうなとは思いますね。
APIマネジメントツールみたいなもので、
1ユーザーあたりのリクエスト数を制限するとか、
作成できるオブジェクトの数を制限するとか、
あとはデータベースであればカラム数制限するとかしないと、
結構SaaSで共有サービスになっていることが多いかなと思うんで、
ユーザーごとにネットワークが完全独立しているとか、
インスタンスが完全に独立してリソースが自由に使えるみたいになってればいいんですけど、
大抵そうなってないんじゃないかなと思うんですよね。
エンドポイント1個だったりとかするんで、
そうすると自分たちのサービスがやらかすと他の人にも大きな影響を与えかねないので、
ユーザー側にもある程度知識を求めてしまうのはいたしかたないのかなと思ったりしますね。
あとこのライティングの中で書いてあるのは文章を短くするというのもありますね。
これも大事なポイントですよね。
あとはフィラーワードを取り除くと、
とても、かなり、本当になど意味のある情報を追加しないフィラーワードはカットしましょうと。
いいですね。
あとは強い動詞を選ぶと、
メッセージを効率的に伝える強い動詞を使い、過剰な形容詞や副詞の必要性を減らしましょう。
あとはリストや過剰書きを使うと、
情報をリストや過剰書きに整理し、読者が素早く重要なポイントを読み、吸収できるようにすると。
あと面白い、これ名詞化を避けるってありますね。
動詞から作られた名詞を動詞に戻すと、
メーカーアセスメントをアセスメントに変更すると。
ほうほうほうほう。
これは日本語だとどういうのがあるんだろうな。
動詞から作られた名詞。
これを名詞化っていうふうに書いてありますけど、
具体的に日本語でこういうのがそれだなっていうのは思いつかないんですけど、
これは英語ならではかもしれないですね。
あとはテクニカルライティングの正しさを向上させるコツ。
徹底的な構成、スペル、文法、不当点の間違いがないか、文章を注意深く見直す。
これは日本語も同じですよね。
文法とかのミスって音読すると見つかったりしますよね。
なので私は大抵一回音読したりしますね。
あとスペルチェッカーを使うと。
そうですね。スペルチェッカーで言うとGoogleドライブ使って、あとワードですかね。
ワードは結構Googleドライブよりも引っかかることが多いかなと思いますね。
あとは事実の確認、すべての事実、データ、参考文献を確認し、正確さを確認すると。
あとはスタイルガイドを使う、書式と引用の一貫性を保つため、公認のスタイルガイドを使うと。
そうですね。ある程度の会社さんだとこういうスタイルガイドとか作ったりするかなと思うんですけど、
なかなか小さいスタートアップとかだと難しかったりとか、規模もそれなりにそんなに大きくないと難しいかなと思いますかね。
そういった意味ではリントとか使うとそれなりの統一感というのは出せるのかなと思いますね。
なかなかこの記事は始終に飛んでいるというか、得られが多い気がするので、原文は英語ですけど、日本語でも役立つような内容があるかなと思うんで、ぜひ読んでいただきたいですね。
うちのサービスとしてよく英文の翻訳とかやったりするんですけど、
ほんと英文だと謎のキーワードが出てきがちなんですよね。
ドキュメントなのにパン屋さんの話とか入ってくるんですよね。
それをそのまま訳してもいいんですけど、それ訳したところでなんなんみたいな文章とかがあってとか、
これは多分日本人にとっては、日本語文章としてはこれは不要なフレーズだと思うから消したよって連絡したりとか、
あとさっきのフィラーワードじゃないですけど、達成したことに対してめちゃくちゃすごいことが起きましたみたいな、
すごいおめでとうみたいな感じで書いてあったりするんですけど、
多分そんな過剰なフィラーワードとか感情を爆発させたような書き方はあんま日本語ドキュメントには向かないかなって直したりとかしてたりしますね。
結構翻訳とかもね、その意味では難しかったりするんですよね。
こないだも何だったかな、面白いのあったんだけどな。
今すぐじゃちょっと探せないかな。
個人的に英語のちょっと短い文章があって、そこに対して翻訳を提供してたんですけど、
これは個人的にいい翻訳、翻訳医薬できたなみたいな感じのものがあったんですけど、
今はちょっとすぐには探せない。
今日のメインテーマの方ですね。
2025年は〇〇元年というところに入っていきたいと思います。
今日は3件いただいてますね。
まず最初がデブレルネーム西から来た馬面の男さんですね。
いつもありがとうございます。
インドIT人材の活躍
一つ目、インドIT人材ますます活躍、存在感増し増し元年。
人口増が著しいインド。
人口第一位にふさわしく、さらにIT業界やIT人材でインド人が活躍しそうです。
インド初のサービスが身近になったり、日本でもインド人の方を多く見かけそうです。
インド料理も日本で激流行りしそうな雰囲気。
ちなみに私は二十歳の大学生の頃、インドに1ヶ月半くらい放浪旅しました。
あの頃とはインド本国は激変しているだろうなと思います。
二つ目、AIが転職活動に入り込む元年。
求職者側はもちろん、企業側にもAIの影響が増します。
企業の採用担当者がAIを駆使し始め、業務効率化で幅を利かせると思います。
私の知る限りでは、転職活動で求職者のレジュメの自動生成などありましたが、
企業側の担当者の人が書類選考するときも、AIがやってくれるのが当たり前の風景になりそうです。
求職者側と企業側の両方AIを活用して、AIvsAIとなり、
お互いそれっぽい立派な文章でアピール合戦、真偽がわからなくなる事象が勃発しそうです。
ということで、実際に会って話してみないとわからないという話になりそうです。
シニア人材と昭和の復興
3つ目、ITシニア人材活躍元年。
IT業界やスタートアップ界隈で60歳代のシニア人材の存在が増しそうです。
もはや人生100年時代ではありますが、
人材不足を背景にシニア人材がこれまで培った経験を生かすシーンが増えます。
スタートアップ界隈の新規事業創出やM&Aなど経験が物を言いそうです。
かつ、生成AIでは満たせない領域があるはずで、シニア人材はそこで持ち味を生かしそうです。
若い人や企業家にはない経験で重宝されるシニア人材が大活躍する元年です。
4つ目、昭和ラブ元年。
昭和100年にあたる2025年、昭和のレトロを懐かしむブームが起きるでしょう。
昭和の雰囲気、昭和の考え、昭和の生活スタイル。
20時間働けますかの世界観の猛烈サラリーマンは、私はごめんですが、
ホワイトすぎて自己成長しないんですという若者に一定数指示されるとかしないとか知らんけど、
昭和を懐かしむムーブメントが起こるかもしれないですね。
というわけで、思いついた4つの元年をお便りしてみました。
インド、AI転職、シニア人材、昭和の4点です。
皆さんの元年も聞いてみたいです。
以上、今週のお便りでした。
1月も半分、これからもよろしくお願いしますと来ております。
すごいですね、4つもいただきましたね。
これでいくと、1つ目からですね、
インドIT人材ますます活躍というところですが、
これはね、あるとは思いますし、
それはとても期待したいというところではあるんですが、
日本に来るかどうかが、ちょっと疑問のところはありますね。
彼らはね、英語が普通にネイティブで使われている人たちなので、
アメリカに行ってしまうとか、
あとEU、特にロンドンとかオランダとか、
あとはどこにいるかな。
私が知っている限り、あとちょっとベルギーかフランスとかかな、
にインドの方が行っているパターンの方が多いような気がします。
当然その日本でも、
うちの、私の住んでいる横浜とかはインドの人多いんですよ。
一つの街のところはインド人専門というか、
インド人の方がむしろ多い学校とかがあって、
そこではヒンドゥー教とかも教えてたりとかするところありますし、
うちの、私の住んでいるところの街もかなりインドの人が多いんですよね。
っていう意味で、インドの方が日本に来るっていうケースも、
必ずしもないというわけではないんですが、
そのためには多分日本側の受け入れ側も、
もうちょっとバージョンアップしないと難しいのかなという気はしますかね。
続いて2つ目ですね。
AIが転職活動に入り込む観念。
これきついですよね。
AI VS AIでお互いそれっぽい立派な文章でアピール合戦とか、
そもそも多分レジュメのフィルタリングみたいなところで
企業はAI使っちゃうみたいな感じになると、
これはなかなか騙し合いというか厳しいなという気がしますね。
ただ新卒とかは本当に使いやすいというか、
生きてくると思うんですよね。
正直なんか分かんないですもんね。
それをこう、人材新卒のやつとかで何百件とか来て、
それを人事の方が判断するときに、
やれ、字がきれいとか汚いとか、
そんなんで判断するのかって思ったりはするんですけど、
正直似たり寄ったりで、
ただとにかくいっぱいあるだけだと、
そういうのに頼らざるを得ないというか、
そういうポイントにせざるを得ない部分もあるのかなっていう気はするので、
それだったらAIとかでうまくなんなんとできる方がいいのかなって思ったりしますね。
続いてのところが、ITシニア人材活躍元年ですね。
これ怖いですね。
60歳代。
あともう、私も多分十何年とかしたらこういうのに当てはまってくるんで、
本当にね、会社員人生は大体皆さん20歳ぐらいから始まって、
65ぐらいまでっていうふうに考えると、
大体40年、50年ないぐらいってことですよね。
今の自分の年齢を考えると、ちょうどもう半分は超えたなっていうところか、
そういうことですね。
そうなんだよな。
怖い。なので、後半戦をしっかりと考えたりとか、戦略を練っていかないといけないですよね。
なんか氷河期、何でしたっけ、就職氷河期世代とか、
私は多分そのど真ん中というか、ちょうどそのぐらいの時期で、
たまたまそういう巻き込まれずに済んだだけというところだったりするんで、
そういう世代の方とか、あと今50代、60代の方がね、
ロールモデルとして活躍していく姿っていうのは見てみたいというか、
期待したいなというところですね。
続いてが4つ目、昭和ラブ盤年。
結構なんか最近でしたっけ、3年ぐらい前でしたっけ、
なんかこういうのありましたよね。
なんだったかな、どっかの町かなんか、町じゃないな、ごめんなさい。
アミューズメントパークかなんかだったかな、昭和の町を再現したみたいなやつとかあって、
多分今の若い人が考える昭和って、
多分昭和30年とか40年とか、わかんないけど、
40年は多分ないかな、30年ぐらいの話だと思うんですよね。
で、私が生まれた時の昭和って、
昔の昭和を再現しましたって見せられた時に、
え?ってちょっとこんな古臭い?みたいな感じの印象があるんですよね。
なので、多分私の思っている昭和、
昭和多分50年代とかは、
そこまでじゃなかったのかなって思ったんですけど、
当時、近所にコンビニはなかったですよね。
セブンイレブンは多分昭和60年過ぎとかだったり、
レンタルビデオ、TSUTAYAじゃないレンタルビデオとかも当時は全然バンバンあったみたいな感じなんで、
よくよく考えると古かったなって今思いましたね。
ではですね、続いてDevRelName ジャーニーマンさんですね。
いつもありがとうございます。
AIエージェント関連でしょうか。
LLMは確かに身近なものになりました。
一方で、自律的にタスクをこなすアシスタントのような利用形態はまだ普及していません。
そこにブレイクスルーがあるのではと期待しています。
また個人的な話ですが、年明けに温めていた上手UGトチギ支部を立ち上げたので、
上手UGトチギ支部元年になりました。
今年もよろしくお願いします。
いいじゃないですかね。
上手UGトチギ。コンパス.コムだということですね。
いいですね。
トチギ。
トチギっていうと何があるんでしたっけ。
日光か。
この東北新幹線ね。宇都宮とか走ってて、
この縦は結構移動しやすいと思うんですけど、
トチギってこの横の移動がすごい難しいイメージがあるんですよね。
なのでこの東北新幹線じゃない、秋田新幹線かな。
あとは宇都宮線とか、この界隈に住んでる人はわりと集まりやすいイメージがあるんですけど、
横に住んでると途端に日光線とか、そっち側になると結構移動しづらいっていうイメージがちょっとありますね。
ぜひこの上手UGトチギ支部元年を華やかなものにしていただきたいですね。
あとはAIエージェント元年ですね。
これもね、確かにこれが一個ブレイクスルーにつながりそうな予感はするんですよね。
面白いですよね。知識は基本的に同じはずなんですけど、
絞り込んだ方が役立つというところで、より深い議論がされるっていうところで。
AI企業元年の到来
それでいうと、どんだけ優秀な人が集まったとしても、優秀な人が集まって議論したからといって良好な結果が生まれるとは限らなくて、
それぞれの分野における専門的に研究されている方とかが集まって、そこで議論したことによっていい結論が得られるというのが一般的だと思うんで、
そう考えると、何でもできますっていう汎用的なAIよりも何かができますっていう、
マーケティング特化型のAIとかライティング特化型のAIとか、そういう存在がいた方がもしかしたらいいのかなっていう気がします。
ベースになるナレッジみたいなものは多分みんな同じものが必要だと思うんですよね。
でもやっぱり特徴というか、日本生まれ日本育ちのAIがあって、インド生まれインド育ちのAIがあって、
それぞれ置かれた立場とかが違う、バックグラウンドが違う上で議論をした方がより良い結果に結びつくのかなという気はしたりしますね。
そういった意味でAIエージェント型のいろいろ議論を積み重ねていく形は個人的にも期待したい部分はありますね。
ではですね、続いてデブレルネーム、さっぽろのじゅんさんですね。いつもありがとうございます。
東京と札幌のトレンドの来る時期が一致しないのね、なんとも言えないのですが、
東京ではAI企業元年とか言ってビジネスの界隈が盛り上がるような気がなんとなくしています。
札幌についてはそろそろAR元年が来てほしいなと思いつつ活動を続けていますが、まだ先になりそうな気がします。
技術の話で言うと裏側がAI、ディスプレイ側とセンサー側をウェアラブルデバイスにするものが流行って、
異世界転生ものでよくある天の声のような機能のものが少し増えるのかなと思っています。
カメラアクセスのしやすい端末の出現が待たれます。プライバシーの問題ありますけどねということですね。
そうなんですよね。やっぱそのウェアラブルデバイスにカメラをつけるのは常にプライバシーの問題が絡んじゃいますよね。
Google Glassがこれやってダメでしたし、
Metaの新しい、あれはARじゃないのかな?MRに近いんですかね。
あの眼鏡とかはカメラあるんでしたっけ?あるかな?あるよな。
あれも常にプライバシーの問題と絡んでしまいそうな気はしますね。
このAppleのヘッドマウントディスプレイ何でしたっけ?
Apple Glassじゃなくて、AppleのVR、Apple Vision Proかとかもそうなんですけど、
個人的にはもう目の時代じゃないと思うんですよね。
じゃあどこやねんって言ったら、僕はずっと耳だと思ってるんですけど、
耳とマイクですかね。
情報を目で確認するんじゃなくて、耳から入ってきて、
その場で音声で答えてタスクを終わらすみたいな感じにならないかなって思ってるんですよね。
その意味ではAirPods Proがもっと良くなってくれればとか、
あとはオープンエア型ですね。
カナル型で完全に塞いじゃうとまた色々問題がありそうな気がするんで、
目に頼り続けるっていうのは前時代的な気がするんですけどね。
じゅんさんからコメント来てますね。
メタのカメラ制御できないですからね。
そうなんですよね。
レイバンメタが日本で買えればいいのにと。
だったらあれですよね。
小田商さんに言っといてはいいと思いますよ。
そしたら買って帰ってきてくれるかもしれないですからね。
東京ではAI起業晩年。
なんかありましたよね。
一人でユニコーン企業を作れる時代が来るんじゃないかみたいな話がありましたよね。
先ほどのジャン・ニンマンさんのエージェントとかタスクアシスタントみたいな感じではないですけど、
それぞれにタスクを割り当てたマーケティング担当、営業担当、開発担当とか、
それぞれが密接に絡んでいって、
総指令として自分が存在している状態で会社を作り、
サービスをどんどん伸ばしていくみたいなことができるんじゃないかという話がありましたね。
これはたぶん近いうち出るような気がしますね。
流石に出資は受けづらいとは思うんですよね。
バックアップ体制なしみたいな。
その人社長しかいないみたいな感じの会社だと、
ちょっと出資を受けるという面では難しいかもしれないですけど、
それこそオンライン系のビジネスであれば、
eコマース系で、
昔の何でしたっけ、ドロップシッピングでしたっけ、
そういう製造販売とか他の会社にお願いしつつ、
自分たちはマーケティングとかセールスの部分だけ担当するみたいな感じのビジネス形態であれば、
在庫リスクもなし、製造リスクもなしみたいな感じで、
ものが販売できるみたいなことにできれば、
一人一人企業でも、もしかしたらそういうユニコーン企業みたいなものが誕生する可能性もあるのかなとか思ったりしますね。
なので、このAI企業元年というところで、
いくつかもしかしたらそういう会社さんが作られて、
かつその中で一人なのにユニコーンになっていくみたいな、
そういう会社が出ても確かにおかしくない気はしますね。
ウェアラブルデバイスの進化
ということで、3人のコメントありがとうございます。
今日のDevRelラジオ198回目ですね。
こちらで終了していこうと思います。
次回は1月21日ですね。
2月の5日がDevRel東京の今年最初のイベントとなっておりまして、
今、会場を探し中なんですよね。
会場決まり次第、ネタは決まっているので、
オープンしたいなと思っているので、
ぜひ、もし会場を貸していただけるという企業の方がいらっしゃったら、
ぜひDevRel東京のアカウントまでコンタクトいただいたりとか、
あとスラックで私のほうまでご連絡いただけると嬉しいです。
というところで、今日のDevRelラジオ198回目、
こちらで終了していこうと思います。
また皆さん来週お会いしましょう。さよなら。
