登壇実績と発表ネタの出どころ
今回は、継続的に勉強会とか、あとはイベントとかで 発表していく技術について聞いていければなと思うんですけど、
国明さんって結構登壇とかしていますよね? そうですね。軽く調べた感じだと、登壇回数は50回は超えていて、
今年はだいたい、今3回やってきて、 この後10月ぐらいにもう1回あるかなっていうぐらい。4回ぐらいですね。
すごい。トータル、この人生で50回ぐらい。 社会人になってから。社会人になってから10回ぐらい。
社会人になってから何年ぐらいですかね? 10? 2014年からだから、今10ちょっとぐらいですね。
だから平均だいたい5回、4回ぐらい、毎年発表しているとですね。 4、5回発表していると。
結構な頻度ですよね、これ。 頻度結構高いです。 高いなぁと思うんですけど、
ちょっとそれを支えていく技術みたいなところも、 もしチップスみたいなのがあったら聞ければなと思うんですけど、
まず何ですかね、そもそも年4、5回みたいなのって、 目標決めてたりするんですか?
目標は決めてないですね。
じゃあもう、なんていうか、 いけそうと思ったらいけるみたいな。
そう、ネタに決めるみたいな感じ。
あとは、時々招待みたいなのが来るんですよ。 ここで発表してもらえませんか?みたいなのが来るんで、
それはもう完全にネタなしで挑む感じですね。
すごいですね、招待講演みたいなのが。 招待講演みたいなのが何回かありましたね。
お願いされると。
今年も1回あって、もうイベント告知されたと思うんで話せるんですけど、
レバレジー様から障害対応の演習かなんかの システムについて発表してくれないかっていうご相談が来て、
10月ぐらいに発表することですね。
すごい。それはあれですよね、招待講演みたいな言うのは、 今まで50回超える発表とかしてきたりとか、
あとは情報発信している中で来ているみたいな感じですもんね。
今回のケースはブログ記事が元になっていて、
障害対応のやつでコーデックスを使って障害対応技場演習みたいなのを するべき理由みたいなブログを書いたんですよ。
それがだいたい100ハテナブックマークぐらいで、 それなりに注目された記事になったんですね。
そこ経由でちょうど多分登壇テーマに合っているってことが 多分主催者様の目に入って、私に声がかかったって感じですね。
ブログとかいろんな情報発信。
結局そういうアウトプット由来で来ているっていうのは間違いないですね。
あとの年一招待系があるみたいなイメージ。
どうだろう、確かに年一ぐらいですね。
だいたい。
あとの3回から4回ぐらいは自分で応募して。
データができたら適当なところにかかるみたいな。
あとはお誘いいただいて。
そんな感じですね。
応募して発表していくみたいなのって 規模感としてはどのくらいなんですかね。
例えばやっぷしとかCFPとか最近応募あったかなと思うんですけど。
巨大イベントなのか、勉強会とかそういうところなのか。
巨大イベントは大体年に1回ぐらい。1回か2回、多くて2回ぐらいで。
大体他のは小規模なイベントなことが多いですね。
例えば大きなやつだと日本ソフトウェアテストシンポジウム。
JUSTってやつとか。
あとは昔とかだとiOSDCとかビルダーズコンとか。
あのあたりとかに出てましたね。
いわゆるカンファレンスと呼ばれるやつですね。
JUSTでしたっけ。
めちゃくちゃお堅そうですね。
そうでもないんですよ。結構意外とカジュアルですね。
それにもCFP応募して採択されてみたいな。
そうですね。論文応募してそれが発表になった時もありましたし、
あとはスポンサーワークとしてもらってという時もありました。
会社がスポンサーして、そこの中で社内で誰か発表する人いますか?
なるほど、そういうパターンもあるってことですね。
発表ネタを一般化する理由と限界
じゃあここからはネタを作る方法なんですかね。
やっぱり情報発信していく中でブログとかがどっかに拾われて、
発表してくださいよみたいなやつがあるみたいなところなんですけど、
とはいえそのネタ自体がないと何も回らないわけじゃないですか。そもそも。
そこら辺の何かあったりするんですか?
あります。ここは結構一つ大きなのが転がっていて、
一番大事なのは一般化することなんですよ。
一般化する。
一般化すること。なんでかって言うと、
例えば私がX社さんに、X社って言うと名前ついちゃってるな。
何でもいいです。ホゲ社さんに所属しているとして、
ホゲ社固有の情報を発信してもほとんど響かない。
例えばホゲ社ではPagesっていうフレームワークを使っていて、
それがああだこうだみたいなこと言われたら、
全然響かなくなるわけですよ。
そうなの?あなたのところではそうなの?って呼んで終わる。
みんなが求めているのはそうじゃないですよね。
特徴的なというか、この会社でしか使っていないフレームワークを使って、
それにすごくニッチだと思うんですけど、
それに特化した発表はニーズがないよね。
ニーズがない。なぜかというと、
私のところでどう使えるのか全く想像できないからですよね。
みんな欲しがっているのは、
私たちにとってその発表を聞くことで何のビリットがあるんだってことを、
みんなどの発表ギルメでも通ってるわけですよ。
そこにその意味を持たせるためには、
私のところでも使えるし、あなたのところでも使える。
っていうふうに一般化する必要があるんですよね。
一つのユースケースに縛られないってことです。
なるほど。一般的な方に落とし込んで、
方なのかどうかわからないですけど、
一般的なお話にまとめて、
それを聞いた人が明日から使えるものにする。
今日から使えるものにしていくっていうことが重要と。
そういうことです。
一般化する方法もいくつかあって、
例えばうちだとこのテストフレームワーク使ってますが、
すごい特殊化されてるんで、これ一般化しなきゃいけなくて、
テストフレームワーク一般的には皆さん使ってますよね。
いずれかのテストフレームワークは。
っていうふうな括りにすると一般的になるわけですよ。
そこでRスペック使ってますよねとかいう話ではないってことですね。
だからどんなテストフレームワークを使っている人にも
響く話が一番嬉しいわけです。
Rスペックでこういうプラグイン使ったらめっちゃよかったですって話よりも、
どのテストフレームワークでもこういう考え方でテストを実装するといいんですよの方が
圧倒的に聴取が広いわけですよ。
聞いてくれる数というか、響く数が多いから。
響く数が多いってことです。
なのでこういう一般化っていうのが発表したりとか
注目を集める上ではすごく重要な技術になってくるわけですね。
一般化っていうのが結構難しいなと思うところが結構あって、
あれですね、テストの話に落とし込む、
Rスペックがとかいう話ではなくて
テストケースをこう書くとよりいいよねみたいなところは
一旦一般化してるわけじゃないですか。
でもそれもある一点から見るとちょっとニッチな層って見られることもあると思うんですよね。
テストケースというものに寄ってしまってると。
もっと広くいって一般的に言うと開発という一般化もできるわけじゃないですか。
そこの敷地どうするんですか。
いいですね、めっちゃいい質問で。
問題っていうのは一般化すればするほど解くのが難しくなるんですよ。
これ何でかっていうと自分のユースケースだけ解くんだったら話は簡単なんですよね。
すごく特殊化してこのフレームワークとこのフレームワークとこのフレームワークの組み合わせでこれを解きたい。
その人のサードパーティーのプラグインをつければ終わるみたいな話とかはある。
それはすごく簡単なんですけど、
やっぱり例えばどの会社さんでも、
例えばどの会社さんっていうことは自社開発してる自サービスの人たちもそうだし
SIRみたいな人たちもそうだし
そういう人たち全部ひっくり返って開発ではこうだっていうのはめちゃくちゃ難しいんですよね。
だってみんなそれぞれ事情が違うじゃないですか。
そうなってくると自分の知り得る範囲での一般化っていうのが多分限界だと思っていて
例えばSIRの人が自社サービスの事情はわからないように
またその逆も確かにですよね。
自社サービスの人たちはSIRの事情がわからない。
のでSIRの人たちまでは一般化できないわけですよ、自社サービスの人たちは。
そこはやっぱりすごく意識しないといけないことで
じゃないと死亡がでかいと刺されるという人たちになってくるわけですね。
それはどういうことかっていうと一般化すると当てはまる概念が増えていくわけですよね。
チェック対象が増えていくんですよ。
これにも今私が一般化した対象について何とかが成り立つと思ったと。
例えばテストはした方がいいなったとすると。
このテストっていうのは例えばソフトウェアの分野でのテストっていう話を私はしたんですけども
もしかしたら人によっては教育とかの分野のテストとか取られる人もいるかもしれませんね。
それお前のテストって何かおかしくない?みたいなこと言われたわけですよ。
テストっていうのは紙に書くんだよって。
マジでいい?みたいなことになってるわけですよ。
それは一般化した対象の中に自分の予想外のものが紛れ込んできちゃったからなわけですよね。
なので一般化すればするほど予想外のものが入り込んできちゃって
解くのが難しくなってくる。
そのテストにすべてについて言えることっていうのがどんどんどんどん狭くなってくるわけですよ。
だから難しくなっていくんですね。
なんだけど、じゃあかといって特殊化すればいいかって言うと
先ほど言った通りそうじゃなくて
そうするとどんどんどんどん認知になっていっちゃうんですよ。
同じ会社の人にしか響かないみたいな話になっていっちゃって
それはやっぱりバランスを取る必要がある。
つまり自分が手の届く範囲の難しさで
なるべく多くの人に声を届けられる。
多くの人にとって意味のある情報を発信する。
そういうバランス感覚が大事になってくるってことですね。
自分の中でこういう一般化だったら
一般的な人たち、エンジニアの人たちにとって
響くんじゃないかという市場感を持つ必要性がある。
どっちかっていうと
自分が分かっている範囲全てについて言えることを言う
みたいな感じがいいかなと思います。
なるほど。自分が分かっている範囲で
言えることというか一般化できる範囲に留めておく。
別に勉強して視野を広げることは全然いいことですね。
それによって一般化する対象が増やせるかもしれないし
ここからは成り立たないんだっていう
一般化の限界を知るかもしれないですね。
だけど自分が知っている限りここまでは成り立つっていう
なるべく大きなステートメントを言うってことが
やっぱり大事ですね。
自分が知っている範囲で一般化するっていうのも
これは個々人によっては
もしかしたら一般化の自分が知り得る範囲が狭いからこそ
ニッチな発表になっているみたいなところは
現象としてあったりするんですかね。
もちろんあります。
ニッチなものほど人に刺さりやすいっていうのはよく言われるんですけど
それは人に深く刺さるんだけど深く刺さる人はすごくまばらなんですよ。
そういうふうな発表になりやすいですね。
なるほど。
聴衆とコミュニティに合わせた設計
今聞いている感じだと
場所によるのかなっていうのを若干思ったんですけど
例えばでっかいカンファレンス
例えばヤップシーだったりとか
ISDCとか
いろんな多様な人
それこそ業種も違う
同じISDCの場合だと
iOSアプリを開発しているっていう中にも
自宅の会社の人だったりとか
自社サービスだったり
はたまた全然違う業界の人だったりとか
いろんな人がいる中での
一般化して発表をする場
みたいな言うのは確かにわかるなと思うんですけど
小さい勉強会で
ちょっとニッチなところだと
またちょっと違うかなと思うんですけど
その場によって変えていくみたいなのあったりしますか?
場によって変えていくは結構なくはないですね
ニッチなものに一般的な話をしすぎると
トカーンとされるんですよ
逆にそうじゃないって食らうときがある
ある程度この範囲の深いことを聞きたいんだって人は
やっぱり一定数いて
ニッチなところで
もっと細かいすごい特殊化された事情を話すっていうのは
あり得るかもしれないですね
それでも一般化の心は失っちゃいけなくて
例えば本当に
プログラミング言語っていうのはある意味
世界の中ではニッチだと思うんですけど
プログラミング言語の中の話をしてるのに
うちはこのRubyの話しかしないんですよとか
あとmRubyの話しかしないんですよ
もっと狭いわけですよ
めっちゃ狭い
そんな話をされたら
みんなあれちょっと物足りないなってなっちゃう
Not for meの人が多くなってきちゃって
そこが難しいですね
やっぱりその深さと
その届く広さっていうのがやっぱりあって
これは
どういう対象聴取なのかってことは
あらかじめ想定した上で
ちゃんと深さが届いてるかっていうのと
その深さは届いてたとしても
その人が一人しか届かないんだったら
もったいないわけですよ
結構発表リソース的には
それだったらもうちょっと広く取ろうかみたいな
そういう風なチョイスはある程度ありますね
対象聴取を意識するみたいな言うところが結構肝
肝ですね
それは絶対意識しますね
それには1回ぐらいは
なんでしょうね
そのイベントに参加しておかないと
なんか空気感わかんない
それはあると思います
結構あると思いますね
ただゆるいのと厳しいの
両方とも経験しておくと
雰囲気は結構だいぶこの中だと
というのは推測しやすくなりますね
なんか結構特殊だなと思うのが
Ruby会議とかの場合って結構
Ruby言語自体の話が好まれる
みたいな雰囲気あるのかなと思う一方
YapCみたいな
パールの一応カンファレンスなんだけども
いろんなことを別に喋ってもいい
みたいなパターンもあったりするじゃないですか
やっぱコミュニティ次第だなというのは
若干思っていて
でもそれは空気を見つつみたいな
そう残念ながらそうなりますね
私は空気を見ることがあんまり好きじゃないんですけど
得意じゃないとも言う
例えばすごく極端な話で言うと
すごく身内のパーティーみたいなのがあったとして
そこで何話すかっつって
いきなりRubyの話とかしたら
ポカーンってなるわけですよ
それはみんなが面白いと思うネタを考えなきゃいけない
って意味で聴衆のことを考えているわけですよね
それは場を先に設定するか
テーマを先に設定して場を選ぶか
2つがあり得て
場を先に決めると聴衆の顔色を伺いながら
っていう話になりますね
なるほどそれで言うと
栗明さんはネタから決めて場所を選んでいる
そうですそれが多いですね
そのパターンが多いですよね
じゃあこのネタだったら
この一般化具合だったら
どこが適するだろう
どこが何か受けそうかなみたいなのを
発表する場を探しているみたいな
探しているってことですね
なるほど確かにそっちだったら
迎合する必要性ないですよね
そうですね
場に対して
ただ招待講演とかは空気読みますかすごく
それはしょうがないですよね
場を選べないですよね自分から
断ることはできても
なるほど
でもやはりネタありきというか
そのネタをどこに持っていくのか
そこで気にするのが聴衆の
どのぐらいのレベルの人がいっぱいいたり
どういう層がいるのかみたいなところですかね
気にすべきは
そうですね
そして彼らが何を求めているかっていうのは
結構大事で
一般的なノウハウなのか
もっと特殊化されたノウハウなのか
ノウハウというよりか
自己啓発的なものなのかとか
いろいろあるわけですよ
それのどれかっていうのは
推測することがすごく大事で
私はよく推測してますね
それによってデザインを変えたりするときもあります
スライドとかの
スライドのデザインを変えたりとか
喋り方の雰囲気をちょっと変える
そういうのどうやって分かるんですか
分かんなくないですか
これは経験ですね
回数をこなすと
この場ではこうかな
この場ではこうかなって
引き出しが広がってくるんで
それ事前に分かるってこと
事前に分かりますね大体
なんかこの参加者の層だったら
みたいなところが
どっかしらから雰囲気で分かるみたいな
分かるって感じ
例えば参加が有料か無料かとか
っていうのでも結構分かりますね
有料になった瞬間に
個人が振り落とされるんですよほとんど
趣味の個人が振り落とされるんで
深いニッチの話っていうよりか
どっちかというと
自己啓発的な内容に寄せた方が
評判が高くなりやすい
それは会社のお金とかで来てるから
会社のお金とかで来てるから
それはなるべく
技術とか特殊化せずに
一般的なことで話した方が
刺さりやすくなると思いますね
会社に持って帰りやすくなる
持って帰りやすくなるから
逆に無料だと
個人の人たちも来るから
個人の人たちも来るから
ある程度
例えばちょっとカジュアルにしてもいい
ってことになりますね
なるほど
そういう違いがあるんですね
3行とマインドマップで作るスライド
あとこれは
完全に個人的な
ノウハウの一つなんですけど
発表の起承転結じゃないですけど
どっかで落ちというか
一番伝えたいことは何かっていうの
絶対寝るんですよね
それが聴衆とマッチするかっていうのを
踏まえた上でそこを一番やるんですけど
私が絶対発表のストレートとかを作る時には
3行ぐらいで伝えたいことは何か
っていうことを
一番最初に書き出すんですよ
それを膨らませて
一個ずつ膨らませて
っていう風なことをやってアウトラインを作る
大体アウトラインを作る時間は
15分ぐらいでそれができちゃう
3つのネタさえあれば
大体できるっていう感じなので
そうすると
スライドテンプレートに機械的に流し込むだけで
大体私の場合1時間から2時間ぐらいで
80分ぐらいの
発表が一つできるっていう感じですね
もう形式化してるんですね
もう慣れちゃってる職人ですね
発表の
準備が
ぶっちゃけAIに作らせるより私が作る方が早いですね
すごい
なんかその
ノウハウというかそのスキル公開してほしいですけど
スキル?
まずはこれを一個決めて
伝えたいことを一個決めて
そこから膨らませていくんだよね
みたいな
本当にそんな感じです
そういう感じです
まずは私よくマインドマップツールを使うんですよ
マインドマップっていう
機構像で
書くツールでアウトラインを
ブログ記事でもスライドでも必ずアウトラインは
マインドマップで機構像で書きます
最初に今日伝えたいことっていう
セクションだったりスライドの1枚目があって
そこに3つ箇条書きで書くと
その書いた後に
背景と問題解決方法とか
入っていって
まとめて同じ3行の
説明がもう一回入るという
行動にすることが多くて
ここまで型が決まっているとあとは内容を埋めていくだけ
みたいな感じになるんですよね
かなりシンプルだろうな
と思うんですけど
そこ結構
難しいというか
個人的な
思いとしては
どうやってるのかな
って今シンプルにさらっと
言ったと思うんですけど
多分
そこ知りたい人かなり多いんじゃないかな
そうですね
これもちょっと難しくて
私職人気味なんで
浮かんできちゃうんですよパッて
ネタがこうあって
こういう表紙を書いて
ネタをこうかな
3行は1行目これ2行目これ3行目これ
あとは埋めるだけみたいな
すごい才能じゃないですか
それは
単純に
登壇が得意なんですね
多分そう登壇が得意です
作る時間もすごく短いし
それなりの発表
もらえるんで
評価もらえてるんで
単純に
得意なんですね
それも
特殊能力ですね
あんまり役に立たないかもしれない
アウトラインとか作る時には
ブログとかは最近アウトラインをマイナワップツールで作って
必ずAIは
ジェミニーを使って
アウトラインから本文に落としますね
クロードとか
あとはチャットGPTとかを
使うとろくなものにならないんで
私は必ずジェミニーを使います
言語化能力というか文章能力が
ジェミニーの方が高いと
命令追従性が高いって言うんですかね余計なことをしないんですよ
ジェミニーは
アウトラインそのクロードとかの
フェーブルとかに渡すとすっげー余計なこと
いっぱいしてくるんですよよかれと思って
あの文量が多くなったり
水増ししたりとか
余計な例何だってない例とかを
入れたりとかしてくるんで
ジェミニーはそういうのしないんですよね
単純にちょっとだけ並び返して
あとはその敬語とか
手にごはんとかを直してくれて
さらわって書いてくれるので直すのすごい楽
ですね
でも手直しはするってこと
手直しはちょっとだけしますね最後に
修正はするけど基本的には
ジェミニーを使って
ジェミニーが一番手直しが少ない
今のところはですね
日常の課題を発表の種にする
ちなみにあの途中であった
イベントが先なのか
ネタが先なのか
ってところで国明さんは確実に
ネタが先ってことですかね
大体そうですよね
ネタが先じゃないと
その何発表したらいいんだ
ってなっちゃいますよね中身のない発表になってしまう
いやそこで
ちょっと気づいたところがあって
自分がどうやってたかな
って思うと
イベントが発表あって応募してるんだ
よしじゃあネタ考えようなんですよ
逆なんですよね
だからこれ
ネタから考えて
どこで発表しようかなの方が
いいんだなって今思いました
あーなるほどで私は
ネタって一体何かっていうのが
一般化されたものだと思ってるんですよ結構
今Rubyで
書いたこの1行は何のために書いたかって
よりかはプログラミング
する時に何を
考慮すべきかみたいな方が一般化されてる
わけですよねこういう一般化されてる
っていうのを日々毎日全てのことについて
やるんですよ本当に全てのことについて
だから今タスクを依頼された
これは自社特有の話なんだけど
もしこういう条件だったらこれは
最適化がどう変わるんだろうかみたいなことを
考えたりしながらそれを解いておくわけ
ですねその時にツールとか
作ったりするわけじゃないですか例えば
その
すごいニッチな話で言うと
確かヘンテコさんが昔
iPhoneの
プロビジョニングプロファイルって言われてるファイルがあって
それの中身を読み解くRubyの
ファイルとか作ってましたよね
作ってくれてて
よく使ってたんですけどワイルドプロビジョン
あれみたいなものとか
作っていく中で
自社のものしか解けないものを作るか
それともどの人でも
ツールを使えばプロビジョニングプロファイルの中に
読めるかってそこに大きな差があるわけ
ですよねありますね
例えばパスを固定すれば
読み解ける
自分の開発コストが減るわけですよ
テストケースに減りますのでそれだけうまくいけばいいと
古い形式とか新しい形式とかどうでも
いいとなるんです今私の使ってる
形式だけを対応すればいいそこに
ちょっとだけ苦労を払って
古い形式も新しい形式も対応します
あるいは対応しないんだったらエラーメッセージだけ出す
みたいな選択をして
一応みんなも触れるツールに
できるって一般化してあげると
それだけでOSSにする
種になってるわけですよ
今作った自社ツールが
そういう種をいっぱい持っておく
成功したものだけ発表するんです
成功の定義
ちなみに何ですかね
例えば運用に回ったとか
あるいは
制度検査自分でしてみたら
制度が高かったとか
日常的にちゃんと使うようになった
これ絶対効果測定しないといけないんですよ
効果測定をして
それが運用として自分じゃない誰かに
運用してもらっているというのが一つのファクターだし
あとは制度が良かったというのも
一つのファクターだし
そういうのが一つの効果測定になっていて
一般化した種をいっぱいあって
成功したものだけ話す
もちろん時に失敗したものを話すのも
面白いんですけど失敗したものだけ話してると
それはそれで面白くないんで
失敗したのはまとめて
って感じですかね
成功は一回で話して
失敗はパッケージして
こういう失敗の
事例集みたいな形で
上げていくと
それも一般化した方が面白いわけです
私はこれをこうしちゃったから失敗した
というよりかは
こういう風にすると大抵のプロジェクター失敗する
って方が面白いわけですよ
失敗の3つの法則みたいな
そういう感じですよね
そういう風に一般化して
できるんだったら一般化するみたいなことをやっていくと
どんどんどんどん種が日常的に溜まっていく
なるほど
そういうのを日常的に
常日頃
招待される時にあれかなって
成功するものをストックを持っていく
AI時代のツールとOSSの価値
ちなみにOSSとして
切り出せるようにするって
一個分かりやすい例かなと思うんですよね
何らかのツール
社内ツール作って
それをもうちょっとだけ一般化して
誰でも使えるような形に落としておくと
それ自体の
ツール自体の
なんて言うんでしょう
OSSとしてのツール自体の
発表は
あんまり需要がなさそうだな
と思っちゃうんですけど
ツール自体の話だったら
ニッチなのかなと思うんですけど
そうじゃなくてちょっとずらして
なんでそれを作って
どう解決したかみたいな
一般化するってことですかね
方式としては
ここには結構大きなポイントがあって
まずそのツールのニーズはあるかないか
どれくらい広いかっていう話があって
ニーズがすごく狭いんだったら
ツール自体を添え物にしてあげないと
やっぱりどうしても
受けが悪くなりますね
例えば私がそのツールの発表を
ビムスクリプトのリントの話をしたときには
あれは確かにApp-Cで話したんだっけな
話したときにそれなりの反響があったんですよ
ツールによっても
需要があればちゃんと
響くっていう風なことになりますね
それはそのツールが
どれだけ一般化されていてニーズがあって
そういう話なんだと思ってます
OSSとしての
ツールとしての
ツールとしてのニーズが
あれば単体でもいけるよね
単体でもいける
なぜならそれを解決したいと思う人がいっぱいいて
そのツールだけを求めている状態に
そのツールが来たらみんながおーってなるわけじゃないですか
それは確実にあったような発表ですね
それがなかったらどう?
それがなかったときには
開発する過程で学んだこととか
こういう失敗もしたんだけど
最終的に乗り越えたよみたいな
そういう風な
開発の時に起こったこととかに
フォーカスしてツールはそういうものにする
っていう風にするとそれなりのネタになりますね
過程を
そう過程を話す
過程で起きた学習内容を
発表するみたいな
私が3年間これを開発してこういう失敗が
あったんだけどっていうのはその3年間分を
圧縮した情報を受け取れるわけですよ
なのでそういう風な
発表もそれなりに意味がある
それはツールはそういうものになるんですけどね
今これ聞いたのはですね
今までだったら
OSSのツールって
これ開発してくれたと
すごい便利っていうので
一定数
需要あったかなと思うんですけど
AI時代に
突入してツール
ちっちゃいツールに関しては
UTTみたいなものは一瞬で
作れるわけじゃないですか
なのでそういうツール自体の
需要っていうのが
かなり激減してきてるのかな
と思うんですよね
なのでそのツール
単体での話ってあんま
ないのかなっていうのを
思っている
極大だったらあるかもしれないですけどね
私はちょっと別の意見を持っていて
AIは
フォワットが決まっていれば
ハウを作るのはすっごく高速になったと思います
なんですけどこのフォワットを
いかに狙い定めるかっていう話っていうのは
まだまだ全然AIとしては
成熟してない部分だと思っていて
なんか当たるOSS作ってって言って
当たるOSS作れるわけがないんですよ
だから
ある程度フォワットを与えて
問題領域を与えてあげて
その上でどういう解決を図るかっていうのは
人間が今ある程度
方向感を与えてるわけですよね
これは今も人間の仕事の一つで
ここで優劣がかなりつくんですよ
と
私は思っているのでツールは
依然として必要だと思っていて
そのツールはフォワットが大事
ツールのフォワットが大事
っていうことですね
なんでそれを作り始めたのか
みたいな
どっちかっていうと何がどうなるのか
みたいな
そのツールを使ったところで
どうなるのか
どういう利益が
例えばタイプスクリプトだと
型を書けますと
でコンパイルされたら型がなくなりますと
それがフォワットです
Yは
私たちは型でよく取り違いをして
ミスをするからになってるし
っていうのがフォワットとYの違い
ですかね
なるほど
なのでツールを
作る時の
開発者の
需要だったりとか
どうしたいっていうところが
AIには
ないので
そこを注入するっていうのが人の仕事だよね
地下って言うと
何に困ってるかを上手に見つけるほうが
大事ですかね
課題の発見みたいな
なるほど
ここで困ってるよねみたいな
いうところを発見してくるのはAIじゃなくて
人間だよね
課題の発見能力みたいな
ところですね
でそれ一個見つけるじゃないですか
でもそれ
原告化するわけじゃないですか
こういう課題がAっていう課題が
ありましたって発表するじゃないですか
ツールとして
OSSとかで発表して
でもそれって別にそのツール自体じゃなくて
その課題に対して
発見価値があるのかな
と思って
それは私も同感フォワットっていうのはそういうことです
ですよねだから
課題を共有したら
ツールいらない
つまりツールはそういうものになるんじゃないのかな
と思っちゃったんですけど
だけどツール作るのにもう適切なプロンプター
を与えてテストも生成させてってやるのに
それなりのトークンと時間がかかるじゃないですか
今でもその私はAIの
速さっていうのは
一つのタスクを終える速さっていうので言うと
大したことないと思ってるんですよ
人間よりもちょっと速いなって思うところはあるんだけど
それでも10倍とか速いほどではないと思っている
一番そのAIのすごいところは並列度だと思ってるんですよね
その意味で言うと
タスクってやっぱり人が手で実装するのも
大体半分ぐらい
実感はかかっちゃうんですよね
どうしてもAI使ったとて
それがあっという間に今インストールするだけで
使えるってなったらそれは魅力的なわけですよ
はい
だから私はツールには依然として価値があるし
そのエコノミは
その経済はやっぱり成り立つと思ってます
なるほど
あのパッと使える
ところにみんな飛びつくよねってこと
そうそうそうそう
あとはこれはすごくジュニアな人に
ありがちなことなんですけど
自分の設定した問題と解放の
に自信がないって人が結構
多くいると
そういう人は他の人のツールを使うことで
その自信のなさを誰かがそれ作って
みんながいいって言ってるんだからいいだろうと
いう風にやるって人たちもいますね
そこもやっぱり経済の一つです
自信がないのをツール化を担っているという側面があるんですね
誰かが
保証してくれてるから
これ使っておけばいいよね
が成り立つってことですよね
そもそもの課題が
適してれば
適してれば
なので
依然として
OSSじゃなかったとしても
別にツールとして作って
こういう課題があったんで
こういう解決しましたみたいなのは
その課題自体に需要があれば
確実に
流行るというか
響くんじゃないかと
イベントの探し方と勉強会の立ち上げ
なるほど
ちょっとこれ
ここまで色々聞いてたかなと思うんですけど
これから
発表しようという
今年中に発表しようという
中で
ネタを先に
でもあれですかね
日常的に
一般化して考えて
こういうネタできそうだな
というのをいくつも
ストックしていく中で
ある日イベントの告知とかを見て
いけそうみたいなことを
常に待ち続けるみたいな
方がいいってことですかね
なるほど
じゃあ本当に
アンテナ張りつつってことですね
そうですね
イベントってどうやって探してます?
イベントはやっぱり
私は結構Xとかで調べますね
イベント申し込みましたとか
あるいはCFP
プロポーザル募集してますみたいな
とかっていうのがあったりするんで
それをちょっと見てることが多いですね
じゃあ基本はXですね
Xで見てます
難しいなと思って
イベント探すのって
いろんなプラットフォームあるかな
と思うんですけど
適するものを探すの難しくないですか結構
ああまあ
そうですね
別に
そうでもないですか
確かにそうだなと思いました
私が主催した勉強会とかもいくつかあるんですけど
例えばLintの勉強会とか開いてたりしたんですよ
Lint Lite
あれ私が作ったイベントだったんですけど
あれは誰もやってなかったから
私がもう主催になってやるみたいなノリで
作ったやつなんですよね
そしたらそれなりに成長で
何回も続いている勉強会になってたんですけど
なければ
最悪作ればいいですよ勉強会を
なるほど
主催をして
人を集めればいいだけ
そしたら確実に発表できますからね
ちゃんと解きたい問題が
ある程度
課題を探し続けるという結論
対象を受けするんだったら勉強会の発表者は必ずあると思います
本当に需要があるかどうかですよね
本当にそうなんですよ
課題に対して
その需要があるかどうかは
どうやって測るんですかね
まず自分が困ってたってことは
一人需要があったってことですよね
他の人も
同僚も困ってるって言ったら
二人困ってる人がいたってことですよね
っていう風に困ってる人たちを
見つけるっていうのが大事なんですよ
その上で一番大事だなって思ってるのは
困ってる人が困ってることに気づいてないケースが
多くあるってことです
本当はもっと開発早くできたらいいなって
思ってるのに
どこが悪いのか分かってない
だからこういう風になるように
しかならんのでしょうって思ってるとか
ありがちですね
そういう人たちっていうのはもっとよくできないんだろうか
っていう問いかけが必要なんですよ
それは発表者が
発表者が
発表者もそうだし日々の自分がです
これが限界だと思ってるんだけど
本当に限界なんだろうかと
そういう風に問い続けることで
問題に気づきやすくなるんですよね
その問題は
しょぼいものもあればすごくいいものも
いっぱい見つけられると思います
そのうちいいものをなるべく
ツールとかを使って
発表していくっていう風に
サイクリングができると
その道の第一印象として認められると
だんだんなってきますから
それをどんどん繰り返していくつまりやっぱり
これは確かイシューから
始めようっていう本でも言ってたと思うんですけど
イシューなんですよやっぱり
何に困ってるかそれ誰だけの多くの人が
それに困ってるかっていうのがやっぱりすごく大事で
ツールのフォワットっていうのは
そこと重なってるわけですよ
なので
フォワットが大事ですね
もう課題発見能力ですね
本当にそう
そうです
あとは諦めないことですね
諦めちゃうとそこで課題発見しなくなっちゃう
モチベーションがなくなっちゃうので
もっとよくできるのはどうしたらいいか
っていうことです
タイダであるべきみたいな
タイダであるべきだと
別に課題とかあろうがなくあろうが困るまで
いいんじゃないになるんで
タイダって言ってしまったね
今よりよくできるんじゃないかっていう
ところの視点を持ちつつ
どういう課題があるかっていうのを
できる限り
嗅覚上げて探していく
そうですね
ずっと探すってことですよね
ずっと探してますよ私も
ずっと探すっていうかそれが趣味みたいな感じですか
あー
趣味じゃないけど仕事だけど
やってるみたいな感じですね
なんか
所作として
身についちゃってるみたいな
私はよく
ある私が勝手に師匠だった
おいでた人から言われるのは
お前は一般化しすぎるってよく言われるんですよ
問題を難しくしすぎてるって言われてます
ってことは結構あってそれは私の悪い癖ですね
発表とかのネタにつなげようとしちゃって
何でもかんでも一般化するから
難しい問題を解こうとして時間を浪費している
って言われちゃった
それは
その側面だけ見ると悪いですね
そうそうそうそう
それでなんか会社の利益的には
ちょっと悪く映る面もある
悪く映るそう
これでも投資判断なんですよ
その問題に取り組んでみなければ
そのフォワットってのはどんな姿なのかってわからないから
どこで引き返すかって話なんですよ
私はちょっと引き返しが遅かったってことですね
損切りが悪かった
そういうこと
のめり込んでしまってるってこと
そこに関しては
なるほど
エンディング
じゃあ発表を
今回の結論は
継続的に勉強会とかイベントとかで発表していくには
課題を
探し続けろと
課題を探し続けて
課題をなるべく一般化した状態で
そうしてれば
おのずと
登壇回数年4回
5回ぐらいはいくでしょうと
そうですね
すごいことですよ
これが他の人も
適用されたらすごいことなんですけど
本当にできたら
とても大変
大変というか
本当にすごいことかなと思うんですが
国明さんだから
できることかもしれないですね
確かに準備の時間の短さは
私の特性ですね
今から始めるってなったら
めちゃくちゃ大変なのか
それともAIがあるから
パッとできるのかもしれないですね
でもまだね
AIの作ったスライドとかは全然ダメですよ
全然ダメですよ
そこの神秘感もありますよね
その神秘感を
どう鍛えるかはまた別問題ですよね
そうですね
爆発を踏むか
そもそも
そこにこだわりを持つかどうかとか
そういうのがありそうな気もしますが
そこはまた別の時に聞ければな
と思うんですけど
今回はここまでにできればなと思います
いい感じにまとまったので
ありがとうございます
もっと詳しく教えてください
ラジオ略職はラジではスーパーエンジニアである
国明さんに
スーパーエンジニアであるへんということが
技術的な質問をしていく番組です
今後もいろんなことを聞いていきたいなと思っていますので
お聞きのプラットフォームや
高評価やチャンネル登録やフォローのほうをお願いします
またこんなこと
聞いてほしいところがありましたら
コメントいただけるとありがたいのでよろしくお願いします
Xなどでハッシュタグ
クワラジでつぶやいてもらえると
発見しやすいので感想など
ぜひお願いします
それでは今回もありがとうございました
ありがとうございました