DevRelの紹介
皆さんお疲れ様です。6月の3日ですね。夕方5時半になりました。
DevRelラジオの今日は、218回目ですね。やっていきたいと思います。
まず最初にですね、DevRelラジオの紹介からですね。
DevRelラジオは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半から1時間程度お送りしているというものになります。
DevRelっていうのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に
良好な関係性を築くためのマーケティング処方となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々。
例えば、テクノロジーエヴァンジリストとか、デベロッパーアドボケイトとか、コミュニティマネージャーとかですね、
マーケターとか、そういった方々が集まって情報交換したり、イベントをやったりしているといったコミュニティになっております。
公式サイトがありまして、DevRel.Tokyoというサイトになります。
そちらからですね、スラックに参加できますので、DevRelに関わっているとか、興味があるという方はぜひジョインいただければと思います。
あとは公式のXアカウントがありまして、AtDevRelTokyoというアカウントですね。
普段はハッシュタグ、シャープDevRelJPというのをつけてですね、ポストしてますので、
ぜひそちらウォッチいただいたりとか、フォローいただいたりとか、あとはこのYouTubeの配信とかですね、
チャンネル登録とかしていただけると嬉しいですというところで、
AIとドキュメントの話題
今日のメインテーマはですね、技術かける○○ですね。
○○の部分はですね、何でもいいと思うんですけれども、
昨今のAI関連の進化がとても早くてですね、
とても多分技術一本で食っていくっていうのが難しいんじゃないかなと思ってるんですよね。
なので、そんな中でですね、自分の価値をどこに見出していくのかみたいなところで、
多分AIには難しいよねみたいなところの話が出てくるのかなと思ってはいるんですけれども、
ぜひ皆さんですね、その○○の部分に当てはまる、
自分の強みでもいいですし、自分が今後やっていきたい領域でもいいと思うんですけれども、
ぜひ上げていただければと思っております。
そちらの話題はですね、多分6時過ぎぐらいからやっていこうかなと思うんで、
まず最初はですね、最近のDevRelに関連した話題をですね、取り上げていこうかなと思います。
今週というか、先週とか今週ですかね、やたら多かったのが、
ドキュメントに関する話題が海外で多かったんですよね。
日本も多かったかなと思うんですけど、
例えばですね、これはまた人の名前が読めない、エングロッソさんですね。
Should you trust AI with your docs? ということで、
ドキュメントをAIに任せるべきか否かという話題ですね。
この方はインドの方ですね。
というものがありまして、
この方はどこの会社かは書いてない。
エングロッソっていうのが会社なのかな?
いや、違うな。
ミントリファイか、ミントリファイの方みたいですね。
その方はデベロッパーアドボケイトとして働かれているみたいなんですけれども、
そのドキュメントをAIに任せるべきかという話題を上げています。
その中で面白いのはですね、
まずAIによってですね、
アドボカシーの可能性が広がっているんじゃないかというところで、
AIはコードの生成はもちろんのこと、
講演の準備、その登壇の資料を作ったりするとかですね、
あとはアイデア出しとか、
ドキュメントの改善まで多方面でAIの支援を受けているということで、
これは結構ポジティブなところですよね。
あとは技術文書とAIの相性というところを上げていて、
いくつかはいいと、いくつかは良くないみたいな感じなんですけど、
多分ここで上がっている4つ、
チュートリアル、ハウツーガイド、説明文書、リバレンスっていうのが上がってるんですけど、
これは多分あれですね、
フランスのドキュメントの考え方、
ちょっとこれの記事をポストしておきますね。
何だっけ、なんか独自資源みたいな、
そんなような名前だった気がするんですけど、
一回ちょっと書いたことあるんだよな。
多分ラジオでも一回紹介したような気がしますね。
あれ、ないな。
ドキュメントの話がすっかり自分のところから抜け落ちている。
マジか。おかしいな。
ない。何だったかな。
ドキュメントのフレームワークなんですよね。
誰かがコメントくれれば一番ありがたいんですが、
コメントも来ないので、
これだ。読み方何だったかな。
リアタクシスですね。
これはフランス初のドキュメントフレームワークなんですけど、
チュートリアル、ハウツーガイド、
エクスプラネーション、説明みたいなのと、
あとリファレンスっていうその4つですね。
多分この記事の中でもチュートリアル、ハウツーガイド、説明文書、
あとリファレンス、やっぱりそうですね。
もうほんと覚えられない。
フランス語っていう時点で覚えられないんですけど、
リアタクシスのフレームワークにのっとった考え方ですね。
それぞれに対してAIとの親和性みたいなところを書いてあって、
まずチュートリアルに関して言うと、初心者向けの文章なので、
AIは手順の自動生成に強いということですね。
これ確かにAIって細かく書いてくださいとか、
初学者向けに分かりやすく書いてくださいとか言えば、
そういうふうに書いてくれるので、
確かにこれは分かるところかなと思いますね。
続いてがハウツーガイドっていうところで、
ここは中級者向けで、
AIはタスクベースの手順生成が得意だというふうに書いてありますね。
続いてが説明文章なんですけど、
Explanationのところは、
深い理解を促すというところで、
AIのサポートはちょっと限定的なんじゃないかというところで、
書いた文章の要約とかはできると思うんですけれども、
全部を任せるっていうのはちょっと難しいんじゃないかということですね。
最後、リファレンスですね。
特定情報の参照用というところで、
AIは整理とか文章からのキーワードの抽出とか、
そういったところは向いているということですね。
逆にそのAIに任せてしまってですね、
うまくいかないみたいな部分もあるかなというところなんですけれども、
その一つが背景理解の欠如と、
プロジェクトの文脈や意図を正確に把握できないということですね。
これは本当何でもそうですよね。
別にドキュメントに限らず、
コードを生成するときもそうですし、
あとコードレビューとかもそうですし、
でもその文脈理解、背景の理解させるっていうところが、
今のAIだとコンテキストが増えすぎちゃうっていうところが、
一番大きい問題にはなってますよね。
これをうまくできるようになるといいなって思うんですけど、
英語圏の記事を一個訳してたんですけど、
そのときにコンテキストを増やせば解決できるのかっていうと、
そうではなくて、与えたコンテキストがノイズになってしまって、
かえって間違いを出力してしまうという問題があるというのが書いてあったんですよね。
なのでそのAIに対してコンテキストが不足しているから、
背景情報が不足しているから正しくできないんじゃないかって考えるんですけど、
そのときにかといって大量に与えればいいかといえば、そうではないと。
やっぱその必要な情報をうまく整理した上で与えてあげないといけないということなんですよね。
これは普通に働いててもそうですよね。
この新入社員みたいな方がいて、
とにかくプログラミングスキルの超高い新入社員みたいな感じですよね。
そういう方に対してドキュメント全部バーンと渡して、
これでやってくれみたいに言っても、
いろんな情報を読み込んでいくうちに自分でもよくわからなくなってしまって、
本来できていたはずのコードが書けなくなるとか、
ドキュメントが書けなくなるとかっていうのは十分誇り得ると思うんですよね。
なのでその情報の主査選択みたいな部分が、
割とちょっとAIがまだ苦手としている部分なのかなと思ったりしましたね。
というところもあり、背景理解の欠如。
とはいえ与えすぎてもいけないという問題はあるのかなと思いますね。
あとはハルシネーションの危険性というところで、
事実でない情報を出力することがあるということですね。
この問題もいつまで経っても解決しないですよね。
コードとか出力してもらってても、
動きそうで動かないコードとかを平気で出力してきますよね。
で、ある程度こっち側で要件が分かっていて、
出力されるコードもこういう風になるだろうなっていう予想を立てている上で出力するので、
そのコードが間違っているとか、ここがダメだっていうのは分かるんですけど、
その今までうまくいっていて、
1,2,3,4とどんどんステップを重ねていって、
10ぐらいのステップになったときに、
いきなりよくわからないエラーで落ちたりとかすると、
本当その今まで出力した9までの分をちゃんと理解していないと、
こちらも修正するのめちゃくちゃ大変なんですよね。
なのでマイクロサービスとは言わないですけど、
もっと細かく出力単位をちっちゃく分けていかないと、
なかなかうまくAIとコミュニケーションできないのかなって最近思いますね。
結構出力はしてくれるんですけど、
それがうまく動かなくて、
再度修正したとしてもさらにダメになるみたいな感じなんで、
しょうがないから一回Gitをチェックアウトして、
また一番最初に与えた指示を見直して作り直すみたいなことを、
最近はよくやっているような気がしますね。
ハルシネーションはいつまで経っても終わらないですよね。
クラウドコードでさえそうなので、
クラウドコードアクションとかにして、
もう完全に仮想環境で作ったコードとかバーンとか投げられても、
なかなかレビューするの大変な気がしますよね。
あと3つ目の話題があって、
AIドキュメント作成のベストプラクティス
ミントリファイのMCPサーバーの活用っていうところを挙げてますね。
MCPによりAIがドキュメントの文脈を理解できる。
そういうことですね。
一貫性と効率性というところで、
そのごちゃっと情報があったとしても、
MCPを使って、
例えば物流管理システムに関する要件だけちょうだいみたいに言ったら、
そのドキュメントを管理している方のMCPサーバーで、
そこの要件を短くまとめた上で返してくれれば、
確かにさっき言っていた背景理解の欠如みたいなところは、
改善できるかもしれないですね。
AIドキュメント作成のベストプラクティスというところで、
4つ挙げていて、
まず1つ目が文脈の提供と、
プロジェクトの目的や詳細を明確に。
この明確にっていうのが、
一番難しいところですよね。
あとは目的の明示と、
AIに求める成果物を具体的に伝えると。
あとは例示というところで、
スタイルやトーンの見本を提示して統一感を保つと。
あと最後、改善の繰り返しというところで、
出力結果に応じて調整し、
最終品質を高めるということが書いてありますね。
この例示っていうのは、
例を示すっていうのはなかなか難しいなと思ってて、
例えば私が20個文章書いて、
AIにその文章を読み込ました上で、
トンマナとかを合わせた上で文章を出力してもらうと。
AIによる文章生成の信頼性
そうすると21個目の文章ができましたと。
さらにそれを3回、4回って繰り返していって、
そのうち私が書いた文章よりも、
AIが書いた文章の方が多くなる瞬間が来るわけですよね。
何だったら参照してくださいって言ったときに、
全部の文章を読み込まずにピックアップして読み込むので、
そうすると自分のAIが出力した文章を読み込んで、
それを参照してまた別の文章を作るっていうのを繰り返していくと、
そのうち全くの別物、
誰かが書いたよくわからない文章が出来上がるような気がするんですよね。
常に自分が書いたドキュメントをパスで指定して、
これだけ参照してくれっていう風にしておけば、
いいのかもしれないですけど、
だんだんコピーのコピーのコピーのコピーのって繰り返していくと、
だんだん伝言ゲーム的に崩れていくんじゃないかなって、
ちょっと心配になったりしますね。
といったところがですね、
Should you trust AI with your docs? という記事になっております。
開発者向け執筆ガイドの紹介
さらにですね、これはブックレビューなんですけれども、
Writing for Developersっていうね、
これもう技術者向けのドキュメントの書き方ガイドみたいな本があるんですよね。
多分どこだろうな。
多分これオライリーから出てんじゃないのかな。
Writing for Developers。
いや、違うかな。
違うのかな。
違いましたね。
オライリーではないんですけれども、
ちょっとなんか体裁に似てたなっていうところで。
なんかこの系統他にも見たことあるような気がするんだよな。
Writing for Developers.
Blogs that get readという内容なんですけれども、
開発者のためのライティングガイドっていうところですね。
全部で17章とブログが2つあって、
345ページだそうですね。
電子書籍版が40ドルってことなんで、
日本円にすると約6000円弱くらいですかね。
この本、良かった点がですね、
まず開発者が執筆を避ける理由を挙げ、
それに対する反論を丁寧に提示しているということですね。
あともう1個はブログ記事の分類が明確で、
初心者にも分かりやすいということです。
逆にあんまり良くなかった、惜しかった点としては、
企業の秘密を公開する前に確認を取るべきとの注意が何度も繰り返され、
やや過保護に感じたということですね。
この間ね、某自動車会社のところで、
ブログ記事出たすぐ後に公開停止になるということもあったりしたんで、
この企業の秘密がね、その人にとって秘密なのか、
それとも城長とか経営人にとって秘密なのか、
人事担当者にとって秘密なのかって全部違ったりするので、
確認を取るべきというのは分からないでもないかなとは思いますね。
エンジニアだとブログが書きやすいというのは、
技術の部分だけ取り出して書けるというのが魅力だと思うんですよね。
そのデータベースの話とか、ネットワークの話とか、
PHPの話とかっていうのは、
お客さんとか自社のサービスのビジネス部分とは切り離せるので、
なのでブログ記事が書きやすいと。
これが営業職とかであればですね、
どこどこのお客さんの方に行きましたとか書けないわけですし、
経理の人とかが書いちゃうと、
それはインサイダーにつながる可能性があるところもあったりするので、
なかなかアウトプット文化っていうのは難しいのかなと思うんですけど、
そう考えるとエンジニアがアウトプットしやすいとはいえ、
その場合によっては扱ってた案件の内側の情報だったりとかする場合は、
大いにある可能性があるので、
企業の秘密を公開する前に確認を取るべきっていうのは、
このぐらい何度も何度も口を酸っぱくして出さないと、
出てしまう可能性があるのかなというところですね。
おすすめの対象者がテクニカルライターとかデブレルの担当者、
あとは自分でブログを始めたい開発者となってますね。
なのでこれは多分デブレルの関係の方にはすごくおすすめの書籍かなと思うんですけれども、
多分まだ日本語版はない気がしますね。
イベント運営とコミュニティの重要性
e-bookだと27ドルみたいですね。
そうですね。
Lightning for Developer Blogs That Get Readという本なんですけど、
英語版はあります。
Amazonにもありますね。
ぜひ興味がある方は読んでいただければと思います。
そうそう、あれですね。
最近デブレルブックっていうのをやっていて、
その対象としてですね、
最高の集い方っていう書籍を取り上げてるんですけど、
それがLibsenseさんのエンジニアブログでも取り上げられてたんですよね。
なんとなくでイベント運命をしているあなたに読んでほしい最高の集い方という本ですね。
ブログ記事ですね。
このLibsenseさんなのか、その個人としてなのかちょっと分からないですけれども、
ここ数年ゆるSRE勉強会や、
yabaibuki.devなどのイベント運営に関わらせていただくことが何度かあり、
少しずつイベント運営にも慣れてきましたというところで、
片井中さんが書かれているんですけれども、
印象に残った箇所っていうのがいくつか挙がっていて、
ホストが主導権を適切に発揮しないとゲストにゲストの世話をさせることになるということですね。
そうですね。
良くない場合も当然あるとは思いますけど、
基本的にはあくまでもコミュニティという前提には立つと思うんですが、
ゲストのままだとそれはコミュニティとして健全ではないと思うんですよね。
むしろゲストをホスト化していくというか、何回か参加していった方は
そのコミュニティにいるということを自分ごとだと思って、
新しいゲストの方をウェルカムなムードで迎え入れてほしいというところはあったりしますかね。
あともう一個が、マウンティング合戦を防ぎ、共感のある議論をということで、
マウンティングはダメですよね、本当にね。
これはちょっと前で言うとこのまさかりとかの議論につながるかもしれないですけど、
最近はでもまさかりっていうキーワード自体、もう死後になってきてるような気がしますね。
その意味ではマウンティングみたいなところが減ってきてるのかもしれないですかね。
あと三つ目、イベントのオープニングとクロージングでの工夫ということで、
イベントでの司会をする人なら一読の価値ありですということで、
オープニングにはイベントという別世界に引き込むという役割があり、
クロージングにも学んだことを振り返ってもらった上で、
外の世界に持って帰ってもらうという役割がありますということですね。
特にこのオープニングですよね。
オープニングのイベントという別世界をいかにうまく作るかっていうところが4章とかでも書かれていて、
この間それの話とかをしてたんですけど、
フランス初のディナー会があって、
シロのディナーっていうやつなんですけど、
これだ、ディナー&ブランクなのかな、ちょっと読み方すいません、わからないんですけれども、
そういうやつがあってですね、それの東京は前に開催されたらしいんですけれども、
これはそのシロのディナーっていう風についている通り、
参加者が必ず白い服装をしなきゃいけないとか、
食べ物を一品用意しなきゃいけないとか、
視界がいちゃいけないとか、
あと場所は秘密とか、
っていうようなすごいいろんな縛りがある中で、
みんなが参加してですね、
4時間ぐらいのディナー会を楽しむっていう、
そういうイベントなんですけど、
その縛り、いい縛りが、
みんなに別な非日常の体験を提供するっていうところをですね、
結構強調されてたんですよね。
これはすごくよくわかるというかですね、
わかりやすい例だなって思ったりしたんですけれども、
やっぱりイベントは、
例えばその海外のカンファレンスとかもそうですけど、
あと地方のカンファレンスとかも、
逆にその東京のカンファレンスに、
他の地域からの方が参加されたりする場合もそうかなと思うんですけど、
やっぱりその場所に来るだけで、
非日常感っていうのがあるべきだと思うんですよね。
多分私が一番最初に参加した海外のカンファレンスは、
多分オープンソースカンファレンスかなんかで、
オランダでやったやつだと思うんですけど、
そのオランダに行くのが初めてじゃなかったかな。
でも一応仕事みたいな感じで行ったんですけど、
半分プライベートみたいな感じで、
そういうオランダに行くのも初めてだったし、
エアビーで泊まって、
とある方の3階の屋根裏部屋みたいなところに泊めさせてもらったりとか、
そのオープンソースカンファレンスで、
でっかい外国人いっぱいいる中で、
完全にアウェーの中、
喋ったりとかするみたいな、
そういうのもすごく楽しかったっていうか、
非日常だったなとは思うんで、
いかに非日常空間を作り出せるかっていうのは、
大事なポイントなのかなって思ったりしますね。
ジャニーマンさんからコメントきてますね。
非日常、良い緊張感がありそうですということですね。
本当にそうですよね。
コミュニティのサミット、大島さんがやっているやつ。
コミュニティリーダーズサミット、コーチですね。
これとかも、わざわざコーチで開催しているっていうところであったりとか、
CLSですね。
そこでの体験みたいなところとかを設計されているんだろうなって、
すごくよくわかりますし、
わざわざその3日間とか、
そういった場所まで行って、
そのカンファレンスを楽しむみたいなところが、
まさに非日常を作っているのかなとは思いますよね。
外国人とかにしてみれば、
日本のカンファレンスに来るっていうだけで、
非日常が味わえると思いますし、
何回もイベントをやっていると、
だんだんこなれた感が出てしまうんですよね。
毎回新しい何か、
サムシングニューを作っていかなきゃいけないんだろうなとは思ってはいるんですけど、
なかなか難しいっていうところがあったりしますね。
コロナ禍とかもいろんなカンファレンスがオンラインとかで開催されて、
最初は楽しかったですよね。
最初は楽しかったっていうと、
ちょっと語弊があるというか、
今つまらないかいって言われちゃうとあれなんですけど、
昔はオービスっていうサービス使ったりとか、
ギャザー使ったりとか、
スペシャルチャット使ったりとか、
オンラインながらその空間にいる感みたいなものを演出するっていうところが多かったかなって思うんですけど、
だんだんああいうのもめんどくさくなってくるというか、
意外と参加者とか運営側両方に対して敷居が高くなってしまっていたっていうところがあって、
もうZoomでいいじゃんとか、
YouTubeライブでいいじゃんみたいな感じになってきてるのかなって思ったりするんですよね。
なので、もうセミナーにしてもミーティングにしてもカンファレンスにしても、
オンラインだったらZoomとかMeetとかYouTubeとかになってしまっていると、
もう非日常感みたいなものは全然ないですよね。
なんでしょうね、その意味でいうと、
テレビとかそういうメディアを作ってきた方っていうのは、
技術とコミュニケーション
ほんとすごいなって思うんですよね。
テレビなんかも非日常なんてどこにも、
テレビっていうメディア自体には非日常が全くないと思うんですよね。
なので、そういった中でテレビを見ている時のワクワク感であったりとか、
なんでしょうね、驚きであったりとか感動みたいなものを生み出せるっていうのは、
やっぱそのテレビのカメラの見せ方であったりとか音声であったりとか、
編集とかがすごく効果的なんだろうなって思ったりしますね。
なので単純にずっとこのラジオとかもそうですけど、
一つの見せ方だけで、
しかも一人がずっと喋っているみたいな感じだと、
飽きられるんだろうなって思いますね。
自分で言ってて自虐的なところあるんですけど、
本当はもっとちゃんと編集したりとかして、
効果的な情報発信みたいなものをやらないといけないんだろうなって思いますけど、
このラジオに関してはライブでやっているっていうところがいいところかなと思うんで、
そこはちょっと比べないようにはしたいなというところですね。
では、あともう一個このドキュメント関係ですね。
What comes first when writing documentation?
The product or the usersというタイトルで、
ドキュメントを書くとき何が先かと、
製品またはユーザーということですね。
その製品についてドキュメントを書くというときは、
どっちかというと自分たち主体なんですよね。
サービスを提供側の主体というところで、
ユーザー視線でユーザー目線で書く場合っていうのは、
もうちょっとよりユーザーの困ったとか、
ユーザーの解決したい課題みたいなものにフォーカスして書くんだろうなと思いますね。
今ゲストが来られたんでお呼びします。
はい、お疲れ様です。
お疲れ様です。聞こえてますかね。
はい、大丈夫です。聞こえます。
はい、こんにちは。
お疲れ様です。
おだしょーさんはドキュメントは何か作業していたりとかしますか?
何か翻訳とか。
そうですね。翻訳は結構多いですね。
先日、年一で大規模なレポートを今の会社は出しているんですけど、
英語版しか当然リリースされないので、日本語翻訳みたいなところは結構一生懸命やってますね。
近年は本当に翻訳だけするのであれば、
先生AI君がとても有能だなぁみたいな感じはありますけど。
確かに。
私もブログ記事とか翻訳するんですけど、
粗い翻訳とかはそれこそChatGPTでもクロードでもDPLでも何でもいいと思うんですけど、やるじゃないですか。
ニュアンスが微妙というか、海外の人はこういう表現するよねみたいな。
バタ臭い感じというのかな。
マイクロソフト時代の時はですね、よく言われてたのが、読んでて疲れる日本語って言ってましたね。
そうですね。多分カロリー高いんですよね。
そうそう。いわゆるネイティブスピーカーが見た時にスッと入ってこない文章のことをおそらく言うと思うんですけど、
やっぱりどこまで翻訳するかみたいな、特に日本語っていうのは省略を良しとするというか傾向がある中で、
外国の文章ってやっぱり主語がしっかりしてる、主語、述語みたいなのがしっかりしてるばっかりに、
少し読む側はストレスがかかるみたいな、適切な省略とか、あとは、
少し例え話が入ってくるところとかも、外国人的にはすごくしっくり振るような言葉選びをしてるんでしょうけど、
日本人が見た時にあんまりしっくりこないというか。
そういう時はちょっと置き換えたりとかっていうのはよくやってますよね。
某企業の翻訳やった時に、パン屋さんの話が一番冒頭に出てきて、
いや、これは訳しても誰も理解できないやろうみたいな感じで、全部消しちゃったことあります?
そうですよね。よっぽど有名な漢詠句とかだったら、日本語の適切な漢詠句に置き換えられたりとかするんですけど、
そうじゃないものもね、山ほどある中でどうやって近しい、似たような言葉だとかあったりするじゃないですか。
外国から日本から、表現のニュアンスは違うけど。
そういったのは勝手に置き換えたりとかすると頭いいなとか思うんですけど、そんなのばっかりじゃないので、
ちゃんとレビュアーとして自分を動かして適切な修正をするみたいなのは結構やってる方かなと思います。
ドキュメントはできれば日本語で提供されている方が、日本人の開発者にアプローチするときにはいいかなって思いますし、
何よりもウェブの検索で見つかるので、まだだ英語で検索しないじゃないですか、日本のエンジニアの方が。
基本はしないですね。機械翻訳とかで粗く日本語訳してある文章とか読むんですけど、さっきの話と繰り返しで。
ちょっとユーザーフレンドリーじゃないなって感じてしまうと、
実際のユーザーとか開発者のことに対してプライオリタイズがちょっと低めなのかなとか思っちゃったりすることはありますよね。
そうですね。年一のレポートとかだったらいいんですけど、
頻繁にアップデートされるようなドキュメントとかがあると、なかなかちょっとそこに予算をかけるのが難しいみたいな。
そうですね。簡単な修正だったら権限さえもらえれば、勝手に修正してこんな感じで修正したてみたいな感じの情報共有ぐらいでもいいのかもしれないんですけど、
それでプロダクトが少なかったりとかドキュメントが少ないと難しいですよね。適切な管理になると途端に難しくなるなと思う。
そうなんですよね。最初頑張ったら頑張った分だけ後が大変みたいな。
本当に本当に。結構その辺は特にマイクロソフトの時は苦労しましたね。
2週間に1回か4週間に1回ぐらい、本国のいわゆるドキュメンテーションチームと打ち合わせの場を持ったりとかしてました。
それはもう開発者のためになったやつですね。やってました、この当時は。
ではですね、お時間もいいところなので、今日のメインテーマですね。技術×ほにゃららっていうところで、小田将さんどうですかね。
技術、小田将さんから技術取り除いたら何が残りますかね。iPhoneしか残らないですかね。
ネタ系ですよね。基本的にはね。
ネタだけ残る。
面白いしか残らないですね。
最近備蓄米の放出が始まって、昨日か一昨日ぐらいにタイムライン見てたんですけど、iPhoneの行列みたいなコメントしてる方がたくさんいたので、今年は米かつゆで並んだ方が面白いのかなとか。
備蓄米屋に差し掛ける可能性もあるから、炊飯器とか持ち歩いた方がいいのかなとか。
そういうこと考えてます。
Tシャツスポンサーの人にそれに掛け合わせたんじゃない?
そうですね。
そうですね。コココ米みたいなね。
そういう感じでね。
そしたらね、備蓄してるiPhone放出してくださいって誰かが返信投げてて、コココiPhoneねとか思いながら、もう特に売ってるわと思いながら。
エノキじゃなくてドコモとかでいいですよ。
確かにね。70匹くらいいますからね。まだね。
公司で増え続けてますからね。
ではですね、1件目こちら小田翔さん読んでもらってもいいですか?
はい、1件目ですね。デブルルネーム西から来た馬ぞらの男さんですね。いつもありがとうございます。
今週のテーマは技術かける○○ということで答えをします。
技術力だけで食っていくのはとありますが、生成AIの登場により危機感を抱きます。
何かと何かの掛け合わせ、技術とは何かの組み合わせですね。
技術かける発想力、技術かけるコミュニケーションでしょうか。
発想力、コミュニケーションで人間同士の対話で何かが生み出せるといいですね。
AIは既存の知識、基地のものに詳しいですが、未知のものは分かりません。
新しく色はないものを生み出す、発想するというのは我々人間が求められているものだと思います。
何かと何かを組み合わせる新結合が生み出せるといいですね。
今週のお便りは以上です。
農業と技術の融合
先週はデブルル界隈の方と何かリアル開催の勉強会をしていただいてよかったです。
会って少し話すだけでも刺激がもらえますということで、今週もありがとうございましたとのことです。
ありがとうございます。
確かにロボットは、ロボットというかAIは握手できないからね。
そうですよね。そういったAIは別に持ちつけもできないわけで。
物理的なあれですよね。
何ですか?
僕らは持ちつきしか残ってないのに。
いや、そんなことないです。
ただ、お互いちょっと顔も知らないフォロワー、
顔の知らないフォロワーの人と昨日ちょっと話してたんですけど、
農業系のところにちょっと興味があって、今全然違う仕事してるんですけど。
知見の掛け合わせ
そういったアグリ系って確かに、IoTの文脈とかでITが入り込む誘致あるんですけど、
やっぱりフィジカルで何かを行うってなったときに、生成ITはやっぱりできない。
もちろんね、いろんな機械が組み合わさって、
それに近いことはできると思うんですけど、
ただ、人間みたいにはできないので、そういったところにはいわゆるチャンスがあるのかもしれないなというか、
一時産業に巻き戻ったりとか、下手すりゃブツブツ効果の時代に巻き戻ったりとかするのかなとか、ほんのり思ったりもしたんですけど。
本当ね、一時産業強いんだけど、
そこに行ける、自分が入り込めるかって言われると、
全然イメージできないっていうところはありますかね。
なるほど、なるほど、なるほど。
今持ってる自分たちの知見×農業みたいなのは全然いけるような気がするんですよね。
もちろんね、取り組み方にもよると思うんですけど、
結構土地余ってるみたいなので、
最近タクシーとか乗ってるとよく出てくるマンションか土地化を分割でみんなで所有してみたいな、
そういった塩梅で区画をサブスクっぽくやって、
光がよく当たる土地はちょっと高めだけどみたいな、
そんな感じの農業のスタイルっていうのもできるんじゃないかなみたいな。
当然、サブスクだったりちょっとクラウドっぽい感じの発想で、
物理的な区画を作ってみたいなやり方とかって意外とありなんじゃねーのみたいな話を昨日ちょっとしてて、
要は今我々、どうぞ。
実際のやるのはたぶん農業に熟知した人がやった方がいいと思うんですよね。
あ、ですですです。
なんか所有だったりとか。
シェアですよね。
そうですそうです。
イニシャルかかるじゃないですか。
高谷市で一人の、一人のこうなんだろうな、
そういった事業者がそういったことをやろうと思うと大変なので、
あそこら辺を統括管理して適切な管理運用していくんだけどもみたいな。
こういった形なのはありかな。
いずれにしても今のところ物理では勝ってるので、
パソコンの電源さえ入らなければChatGPTには勝てる。
そうですね。
向こう側に、僕らじゃない誰かを動かしてるので、
僕らがChatGPTに勝ってもさ、それは本当個人的な話で、
他の人はもっと活用しちゃってると。
そうなんですよね。
単純に武器移行しちゃってるだけなんだよな、みたいな。
そうそう。
博太郎さんからコメント。
僕は祖父母が農業でしたが、そもそもの資金がないんですよね、
ということですね。
なるほど。
そうですね。
そういった切実な問題はあるのかな、という気はしますよね。
そうですね。
別に答えは出なかったんですけど、その会話の中で。
結構仕事してる手止めて、面白くて話し合っちゃったんですけど。
答えは明確なものは出なかったんですけど、
自分たちが持っている知見と何か全然別のものを掛け合わせるっていうのは楽しい。
そうですね。
AIと教育の変化
和尚さんとかだと体育教師の免許を持ってるじゃないですか。
フィジカルの部分って残ると思うんですよね。
数学の先生とか国語の先生とか英語の先生とかって
割とAIに置き換えやすいというか、
何だったら先生に繰り返し聞いたら先生もイラッとするけど、
AIイラッとせずに優しく教え続けてくれるからむしろいいかなみたいな。
でもさすがに体育は無理じゃん。
体育は確かに難しいですね。
その辺は反復練習で体に覚え込ませるっていうのが必要だから、
人間が覚えないといかんともしがたいというか。
そうですよね。
飛び箱を飛べない生徒に対して、
ロボットがこうやって飛べばいいんだよとかって、
超かっこいい動き見せられてもお前はロボットだからって。
揚力がみたいなね。
理屈で分かってもできるかどうかまた別問題みたいな。
ショートカットはできるでしょうけどね。
ショートカットはできると思いますけど。
確かにAIって何回聞いても教えてくれる。
近所のパソコン教室で100回聞いても笑顔で教えますみたいな看板出してるとこあったんですけど、
間違いこれ俺1回目で絶対切れるけどなって思いながら。
1回でも俺自信ある。
101回目で切れそうですね。
だから人間でもそれを謳ってるところはあるはあるっていうね。
私はChatGPTより優しいですみたいな。
そこまでのニュアンスあるか分からないけど。
絶対1回目で切れるだろうこれと思いながら。
さくたろうさんからコメント来てますね。
ChatGPTで要要がうまくなりiPhoneの行列体力を持ちたいとか相談しても筋トレなんですよね。
そうなんですよ。
筋力は全て解決しますよね。
大体筋肉で解決できます。
最近運動不足でちょっと歩くだけで次の日ふくらはぎと筋肉痛になるんで。
そうすると今年は並べきれないかもしれない。
立ってなきゃいけないってこと?椅子持ってけばいいんじゃないの?
ソフトスキルの重要性
銀座じゃなければ座れるので。
銀座の場合だと17時間仰立ちしたという実績が一昨年ぐらいでありますね。
あれはもう多分無理かな。
そっか。
昔の銀座とかみんな地べたに座ってずっと待ってましたよね。
ですよね。
少なくとも表参道の方々はここまでだったら並んでOKっていうラインを自分には示してくれるので。
そこさえ守っていれば朝まで平穏に過ごせるかなって感じ。
うーん。
そうなんだよな。
用語がうまくなり面白いな。
モチベーターが多いといいですね。
ではですね、2件目は私の方から。
デブレルネームジャーニーマンさんですね。いつもありがとうございます。
B2Bの世界はクライアントワークが多いので顧客と向き合う力でしょうか。
業界、業務知識、技術的な設計スキル、プロジェクトを進めるマネジメント力、
報告、連絡、相談などのコミュニケーションを通した期待値コントロール力、
システムをデリバリーした後の運用や改善を推進する力など、
いわゆる広範囲なソフトスキルが求められるのではないかと思います。
皆さんのお便りも楽しみですということで。
ソフトスキル全般、AIだと難しい部分はあるのかなという気はしますかね。
そうですね。まずそもそも人間がとんでもない変数なので、
フィットした空気を読む能力も含めてだと思うんですけど、
この辺は人間にしかできないでしょうね。
そうですね。確かにその意味ではプロジェクトマネージャーとかは求められ続けるかもしれないですね。
そうですね。確かに。
人間くさい仕事みたいなところは残りやすいような気はしますよね。
そうですね。
これがSIとかにつながってくると、
システムエンジニアみたいな人たちがドキュメント書いて、
顧客と接種をしてみたいな感じになると思いますよね。
いわゆるプリセールスのシステムエンジニアに行ってみたいな。
技術的なあれ見してみたいな。
結局まだ一応エージェンティックなところは除けば、
判断は人がやっているので。
その部分ですよね。
判断の部分、本当に人がやっているのかな。
Aという結論が良いですと言われた時に、
いやいやBだろうと。
そんな強い反論を出せる人っているんですかね。
どうでしょうね。
造形が深ければそういったのもあるでしょうけど、
いずれにしてもAを提案された時に、
これで行こうと判断は良くも悪くもしたことになっているので。
そうなんですけどね。
自分で判断した気になっているだけで、
メンタリストの選ばせるやつあるじゃないですか。
トランプとか。
ありますね。
あの世界な気がしなくもないですね。
選んでるつもりが選ばされている。
それはあると思います。
ただね、犯行した時点でもそこで責任が発生するので。
そうですよね。
僕らの残っている仕事は責任を取ることだけっていうね。
日本企業一番苦手なやつですからね。
そうですけど、やっぱりドライバーが責任を持つみたいなね。
ちょっとでも考えるんですよね。
責任を取るっていうこと自体が、
もうなんか古臭くなってきてないかなみたいな。
つまり。
ともちょっと考えていて、
つまり、いろんなエージェント的な機能とかいろいろ使うと、
意思決定の部分とかも結構やってくれたりとかするじゃないですか。
まあでも、一応そういった情報をアウトプットした人が責任を持つことになってるんですけど、
それこそ責任を持たされてるだけみたいな感じなわけで。
いや、無責任になれとは思わないんですけど、
責任を取るということによって、
いろんなもののスピードが遅くなっているような気もしてるんですよね。
責任をどこまで取るのが正しいかみたいな。
エージェントは割とその、
もうこれはここのフォルダ以下だったら自由にファイル作ってみたいな。
もうなんかオートアップローブみたいな感じにはなりますよね。
めんどくさすぎて。
そうそうそうそう。
熱井さんの話じゃないんだけど。
責任を取らされるみたいな形の存在だったら、
ネットワークと個人の役割
もう考えなくてよくねってちょっと思ったりもするけど、
難しいところですね。
無責任でOKっていうわけではないので。
そのうち合議制とかになるんですかね。
10人ぐらい集まって10人がアップローブしないと実行されないタスクみたいなね。
責任が10個に分断しちゃったらもう誰が責任に乗るかわからんみたいな。
いや本当そうですよね。
少なくともね、
オープンAIとかアウトロピックとかもそうですけど、
出力機関に関しては責任を取らないでって一文書いてあるので、
全てのプロダクトにその一文入れてやればいいんじゃないかなとも思いますけど。
確かにね。
それがマカリトールだったらマカリトールでしょって。
確かにね。
その業務システムとかで、銀行の振り込み手配とかで一番最後のところに責任取れませんって。
正しく支払われるかわかりませんみたいな。
余金算でが丸1個少ないかもしれません。
ちょっとおもろい。
怖いわ。
怖いですね。
確かにAIはなぜか許されてますね。
そうそうそう、許されてるから。
そのノリで全部許されれば面白い。
いい意味で、いや悪い意味だな。
カオスになりそうな気がしますけどね。
確かに。
面白そう。
3件目小田翔さん読んでいただいていいですか。
はい、3件目ですね。
今週長崎のじゅんさんですね。
ありがとうございます。
いいですね長崎ね。
ちゃんぽんとピードロですかね。
技術×巻き込まれ力の重要性が上がっていくのかなとぼんやり思っています。
AIが汎用的に使えるようになっていって、
もともと分業だった仕事が一人で終わるような感じになると、
その発信も一体多数の方になっていくように思います。
ごく一部のインフルエンサーは増えていくと思いますが、
その他大勢は埋もれて苦しくなると考えます。
そこで揺り戻しのような形で、
人のネットワークの重要性が見直される場面が来て、
冒頭の巻き込まり力が意味を持ち始めます。
一人でも十分なんだけど、
この人がいると別の価値をもたらすみたいな枠の人が
複数のプロジェクトに巻き込まれて、
その人をハブとしたネットワークができると、
一人でいるよりは存在が安定しそうだなと思っています。
現在、コミュニティ間のネットワークを作っている
私のガネ・インスピーナは冒頭でした。
ありがとうございます。
やっぱり人ですかね。
まあ、そうですね。
例えば、AIが本当に人を介在することなく
全てを完結できるという、むしろ
人間は地球のガンダムみたいなのか、
どこかの映画みたいな感じになってこない限りは、
人間が人間同士のネットワークみたいなのは
確かに重要な意味を持つのかなって気はしますけどね。
でも、ネットワークを作るっていうのも
一挙一績にできるわけじゃないじゃないですか。
そうですね。
例えば、どこかで登壇するとかで
自分をアピールしないといけなくて、
その時って経験があったからこそ喋れるみたいな
本当に鳥玉の話で
ネットワークを作るためには何か自分がやらなきゃいけなくて
それをやっているのがAIになると
実は自分は何者でもないみたいな。
それは今後増えてくるような気がします。
最近、LLM無職とかそういったのが流行っていると思うんですけど
本当に処理医者みたいになる
そういう風に歌ってたりとか
そういうムーブに乗っかっている人がちょこちょこ参見されるんですけど
本当に一人医者の時代来そうだなって気はちょっとしますね。
確かにね。
みんな自分のビジネスを持っているみたいな。
どこかに所属するってことはなくなきゃしないんだろうけど
どちらかというと影響力を強めていくのが
一人医者みたいな感じになるような気はするんですけど
経営している方々も自分たちのビジネスを進めるために
人の力が必要だから雇っているわけであって
そこが置き換えてきてしまえば別に従業員なんていらないわけですよね。
っていう外資の最近で流行ってますけど。
確かに確かに。
だから一人ない少人数みたいな企業構成になって
そことの繋がりみたいな感じは
そう遠くない将来で起こり得るような気はするんですよね。
それができる方はそうなるでしょうね。
それができないからいきなり独立しろやって
みんなを追っ掘り出されても困っちゃうので
だったと思います。
会社に所属したりとかするわけで。
もう今そんなことになったらね
代わりに並びますぐらいしかできないので。
代わりに並びますって自分が手に入れたいんだから変わんないでしょ。
そっかそっか困ったな。
そういうふうな世の中にちょっとなっていくような気はするんですよね。
何かを達成したいときの最小構成人数で物事が進むみたいな。
そんな感じの世の中になるような気はしますね。
確かに。
やっぱり今日のお便りを見る限りは
みなさんのソフトスキルの部分ですよね。
確かに。
AIに勝てるコーディング力みたいな話が出てこないってことは
そういうことなんだなって。
そこでは対抗できないよね。
みんなもううすら分かってるんだよねその辺はね。
技術とオリジナリティ
本当に全然切り口が違うものを掛け合わせることによって
オリジナリティだったりとか差別化を図るというような形になっていくのかなと気はします。
そうですね。
どうなるんだろうな。
アイデア支援だと思うけど難しいですよね。
IT業界にどっこり使ってる我々とするとね。
そうですね。
私は何らかのピン芸人にならなきゃいけないのかなと思ってはいるんですよね。
はいはい。
その他大勢になると本当に飲み込まれちゃう気がするので
別に何でもいいんですけど
ITだともううぞうもぞいっぱいいるし
私より技術力ある人いっぱいいるので
そうじゃないところだと
何らかのピン芸人になれるところを見つける必要あるのかなとは思いますかね。
そうですね。
沢窪さんが本に書いてたか忘れましたけど
あれですよね。競技人口少ないところに
何なら一人みたいな。
競技人口一人みたいな。
俺が世界チャンピオンみたいな。
需要がないピン芸人はダメでしょう。
まあまあもちろんそうですね。食えなきゃ意味ないですからね。
その辺とかを隙間産業的に目指していくのかなと。
そうですね。
AI界隈もそうだし
ちょっと前のWeb3界隈とかもね
それぞれにピンを目指すというか
すごい驚きで言われるような人たちがね。
いますね。
よくまとめてくれてるなとは思いますけどね。
ただビジネスに対して明確な回位を提供しないってあたりで
なかなか厳しいものを感じることは確かにあるけど
でも情報まとめてくれてるから
時間がなくてさまったものはあるといいなと思って
見てたら出てくるからありがたいと思い出しておりますけど。
デブレルイベントの紹介
そうそう。
あの界隈もね多分1人2人ぐらいしか生き残れないだろうし
別なものが出てきたらまたそれはそれでね
生き残れる人少ないだろうしって思いますね。
そうですね。
そういったのも提供ベンダー側に行くって言ってもらったりするかも
思いますけどね。
確かに。
結局法人の方がうまくやったりするんですよね。
そのあたりね。
まあまあまあそうなんですよ。
なかなか個人で最後まで戦い切るのは結構タフだと思います。
そうですね。
はいではですね最後イベントのご案内だけ
明日ですねデブレル東京の101回目
デブレルの始め方っていうちょっとタイトル変更したんですけれども
ありますというところで
少人数とかですね
あとまあ私は私資料作ってねーややっべ
えっと
えっと
外資のヘッドクォーターはあるんだけど
日本側1人しかいないみたいな
そういった時に何にするのか
話とかをね
しようかなと思っているので
これからデブレルを始めるとかいう方にはですね
いい対応かなと思っておりますので
ぜひご参加いただける方は
参加登録の方をお願いいたしますと
であとは
ありがとうございますデブレルブックスの3回目は
えっと30日でしたっけね確かね
そうですね
ごめんなさい
20日
確か20日ですね
はい
ちょっと今イベントまだ作ってないですけど
作っておきますと
あとはデブレル会議が10月2日から4日ですね
まだちょっと
募集ページはまだ作ってないというか
まだ7月からかな
になるんですけれども
ぜひ皆さんとりあえず予定だけ
開けておいていただければと
そうですかね
はい
はいということで
今日はですねデブレルラジオ218回目やっていきました
はい小田翔さんご参加いただきありがとうございます
はいありがとうございます
ではまた皆さん来週お会いしましょう
さよなら
さよなら
