DevRel Tokyoの紹介
皆さんお疲れ様です。DevRel Radioの223回目ですね、やっていきたいと思います。
まず最初にですね、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日夕方5時半からですね、1時間程度お送りしているというものになります。
DevRelというのはですね、デベロッパーリレーションズの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を作るためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えば、デベロッパーアドボケイトとか、コミュニティマネージャーとか、
テクノロジーエヴァンジリストとかですね、マーケターとか、
そういった方々が集まって情報交換したりイベントをしているといったコミュニティになっております。
DevRel Tokyo、公式サイトがあります。
DevRel.Tokyoというサイトですね。
そちらからスラックに参加できますので、
ぜひDevRelに関わっているとか、興味があるという方はジョインいただければと思います。
あとは公式のXアカウントがあります。
アットデブレル東京というアカウントですね。
普段はシャープデブレルJPというハッシュタグでポストしてますので、
ぜひアカウントをフォローいただいたりとか、そちらのハッシュタグを見ていただいたりとか、
あとはこの配信をやっているYouTubeとかFacebookとかありますので、
ぜひそちらの方をフォローいただいたりすると嬉しいですというところですね。
効率的なインプットとアウトプット
今日223回目なんですけれども、
テーマが効率的なインナウトとなっております。
最近テクノロジー界隈だと、とにかくAIの情報が日々出まくっているというか、
氾濫している状態かなというところがあって、
ほぼ毎日のようにプレイヤーが変わるというか、状況が変わったりするので、
インプットし続けていると結構しんどいなという状態かなと思うんですよね。
どうやっていい情報とか、自分に合った情報を仕入れてくるかとか、
あとはそれをどうやってアウトプットしていくかみたいなところを、
自分でそれぞれ気をつけているところがあるのを教えていただきたいなと思っております。
そちらのほうは、お時間的には、
今日の後半くらいですかね。
6時過ぎからそちらを取り上げていこうかなと思うので、
ぜひ今のうちにコメントいただきたいんですが、
ちょっと文章を作ったんで、
アッシュタグ忘れてたな。
じゃあこれで、FacebookとYouTubeと、あとは、
Xのほうですね。
ポストしておきましたので、
なんかXが消えたな。
大丈夫かな。
プロフィール。
大丈夫そうですね。
ぜひ今のうちにコメントのほうをお寄せいただければと思います。
では、それまでは最近のDevRelに関連したような記事とかを取り上げていこうかなと思うんですけど、
まず最初、コメント来てますね。
作太郎さんから、こんにちは。
今日は最初から視聴させていただきますと来ております。
よろしくお願いします。
はい。
今日は割と海外の記事が多くてですね、
多分同じ人だったような気がすんだよな。
How to DevRelっていうタイトルで、
5つぐらい記事書いてますね。
どれがいいかな。
何だろうな、これ。
これちょっと私も読んでないんですけれども、
How to DevRel.
I learned from Spider-Man the musical.
スパイダーマンのミュージカルからDevRelに関するところを学んだという記事が出ております。
スパイダーマンのミュージカルから何を学ぶんだろうっていう気がするんですけれども、
ちょっとチャットGPTで概要まとめてもらおう。
意外と長い記事でした。
まず、満足できるアウトプットっていうところで、
ブログとか公演であったりとか動画とかですね、
この方は自分にとっても自信の持てるコンテンツを作っていったという話が書いてあります。
その中から他の人から、これ別な形にしたらという提案が届いたと。
いわゆるリサイクルですね、再利用を促すメッセージをもらったということです。
自分としてはレオンさんとしては、自分はもう全部言ったから満足しているんだけれども、
再利用すべきかどうかというところがちょっと悩んだと。
ともすると二番煎じに感じる不安もあったということですね。
そこでスパイダーマンの例が出てくると。
スパイダーマンは同じ物語であったとしても、紙とかアニメとか実写とか、
あとこのミュージカルみたいな感じで形を変えることで異なる魅力を発揮してきたと。
ライオンキングの例も書いてありますね。
ライオンキングも同じですよね。
実写版って何かあったんだっけ、よくわかんないですけど。
確かアニメとかはありますし、あとミュージカルも有名ですよね。
そういったところで形式の変換をするということは、
再発見のチャンスがあるんじゃないかということが書いてあります。
フォーマットを変えることで見落としていた要素や新たな視点に気づける可能性があると。
再利用することによって強くなると。
単なる焼き回しではなく、むしろ内容が強く明確になる可能性があるということで、
コンテンツの再利用は劣化ではなく進化であるというところが最後に書かれているということですね。
これはすごく納得感があるというか、
かつ人によって認知できる領域っていうのが結構違うんですよね。
本で読む方が理解しやすいという人もいれば、
動画で見た方が理解しやすいとか、
耳から情報を得た方が分かりやすいとかですね、
あとは誰かから聞いた方が分かりやすいとか、
結構人によって認知特性っていうのが違うんですよね。
その登壇で喋って終わりというパターンもあればですね、
それを動画に撮っておいて、動画で展開することでより理解できるという方もいればですね、
そこで喋っていた内容をテキスト起こしして、
テキストコンテンツとして公開することで、
ウェブ検索で見つかったりとか、
あとさらにLLMで学習してですね、
それが再利用されていったりとかっていうところもあるんで、
その一つのコンテンツをむしろいろいろ使い回した方がですね、
いろんな人にアプローチできる可能性も高くなるんじゃないかなという気はしますね。
さらにこのレオンさんですね、話しているところに行けばですね、
再利用するときに多分また自分の中で再構築のプロセスが走ると、
その中で足りなかった要素を強めていったりとか、
ちょっと脱線しちゃうかもしれないけれども、
別なコンテンツを付け加えるとか、
少なくともウェブで書く場合っていうのはリンクが使えるので、
より情報に厚みをもたらすことができるとかですね、
そういったところで再利用することでコンテンツを進化させることができるといったところが、
このアイダーマンのミュージカルから学んだことというところで書かれております。
アダドさんのHow to DevRel
これはすごく学べるところが多いのかなと思いますね。
このレオンさんの肩書きがなかなか面白くて、
俳優をやっていたりとか、あと害虫駆除業者とか電気技師、大工、舞台闘技指導者、
闘技っていうのは戦う技って書いてあるので、いわゆる盾みたいなやつですかね。
あとはアメリカの手話の通訳者、日曜学校の教師として働いてきました。
コンピューターも扱います。
もう情報量満載すぎてあれなんですけど、
コンピューターも扱いますっていう、そっちのほうがすごく少なく見えますね。
仕事内容としては、ケンティックっていうところのプリンシパルテクニカルエヴァンジェリストになってますね。
もうかれこれと3年半ぐらいやられているらしいというところですね。
面白いですね。
ケンティック社がどこにあるかわかんない。
今は住んでるのはオハイオ州なのか。
ニューヨーク大学出身って書いてあったんで、
もしかしたらデベレルコンのニューヨークでお会いできるかなと思ったんですけど、
ちょっと遠いかもしれないですね。
オハイオ州がどこにあるのかちょっとわかってないですね。
じゅんさんからもこんにちはといただきました。
こんにちは、よろしくお願いします。
このレオン・アダドさんですね。
全部で5つのHow to DevRelシリーズっていうのを書いていて、
すごくアメリカ的なタイトルだな、どれも。
これがHow to DevRelのテキサスシャープシューターということで、
テキサスの狙撃手っていうタイトルがついているブログ記事が出てますね。
これもなかなか日本人でこういうタイトルを考えられる人は少ないですよね。
ここのテキサスの狙撃手というタイトルの記事なんですけれども、
新機能をリリースしたんだけれども、
無反応で迎えられる瞬間があると。
ユーザーのそのニーズとちょっとずれている場合とかですかね。
ユーザーが何これという反応を見せることがあると。
理由は単純で、その機能の意図や必要性が伝わっていないからということですね。
これは開発者ツールでこれをやると結構痛い部分あるかなと思うんですけど、
スマホアプリとかは割と昔は多かったかなというところがありますね。
2015年とかそこら辺、もうちょっと前かな2013年とか、
アプリを作るのがすごく盛んだった時期があって、
私もいくつかのところでご協力したことがあるんですけど、
その時にマーケティングの方とかがあれやこれやっていろいろ考えて、
それをなるべくイテレーションの中で収まるような形のスコープにまとめて作ってリリースしたけど、
あんまうまくいかなくて、そこでその機能を切れればいいんですけど、
せっかく作ったんだから的な感じで残し続けちゃうんですよね。
それが続いていくとだんだんごったに感が出るというか、
一番最初にあったはずのシンプルなコンセプトみたいなものが消えていって、
ユーザーとしてはこのアプリって何だったっけみたいな感じになってしまう場合があるかなと思いますね。
なのでこの新機能が無反応になるっていうのはすごくよろしくないかなという気はするんですけれども、
2つ目、HowよりWhyの説明が難しいというのが重要であると。
使い方の説明は簡単でもそもそもなぜ作ったのか、いわゆるWhyですね。
Whyを伝えるには深い理解と工夫が必要であるということですね。
これは確かにそうですよね。
何でしょうね。
作った機能が自分たちの思ってたものと違う使い方をされるっていうケースも結構あると思うんですよね。
昔、とあるサービスでDevRelのサポートしてたんですけど、
その時にクラウドサービスだったんで、エンドポイントが1個しかなかったんですね。
APIの使い方とその影響
データベースにしてもシェアの仕組みになっているので、
めちゃくちゃ使うユーザーの人もいれば、そんな使わない人もいるみたいな、
そういう混在した状態だったんですけど、
それもあって、とあるサービスの使い方がめちゃくちゃトラフィックに影響を与えるぐらい、
負荷が高い状態だったんですよね。
そういう使い方ができないわけじゃない。
APIって公開してるだけなんで、言ってみればあれですね。
Wearを使わずにデータを全部取ってきて、プログラミングの方でフィルターするみたいな、
使い方は実際は違うんですけど、
そういうふうな負荷をかけようと思えば、いくらでもかけられるわけですよね。
そういう使い方をされてしまったので、
わざわざお客さんというか利用しているユーザーの方のところまで行って、
こういう使い方をやめてくださいって言って、
データの構造とかを相談して変えて乗り切ったみたいな時があったんですけど、
こちら側としてはそういう使い方はしないよねっていうところでリリースしたはずの機能が、
めちゃくちゃ違う使い方されて、とんでもない負荷を与えられるみたいな、
そういう経験は私もありましたね。
そういったHowよりホワイの説明が難しいというところで、
テキサスの射撃手の話がヒントになるということですね。
これ面白いですね。テキサスの射撃手、何かっていうとですね、
撃ってから標的を描く少年の話らしいです。
面白い。
この話はすいません、ちょっと私が知らなかったんであれですけど、
これだったら常に100点満点になりますよね。
だってその射撃手の人がとりあえずどこでもいいんでパーンって撃って、
当たったところを中心に的を描いていけばそれはなるよねっていう話だ。
これをDevRelにおいては問題提起から開発策発表の流れに活用できるんじゃないかというところで、
まずコンテキストのギャップを意識すると、
開発側とユーザー側においては時間軸がずれている。
開発者にとっての今はユーザーにとっての未来であるということですね。
そうですね、確かに。
結構サービスとかを継続して開発していくとどんどん専鋭化されていくっていうところがあって、
新しく入ってくるユーザーが多い状態であったとすれば基本的に初心者の人が多いわけですね、圧倒的に。
そういう人たちに対してその専鋭化された機能をいきなりガチャンと見せてしまうと
結構トラブルというか戸惑うんですよね。
何ができるのか情報量に圧倒されちゃう場合があって、
一番最初にリリースしたときっていうのはすごくシンプルな機能しかないので、
使う人たちも初心者でも使いこなせたんですけど、
どんどん機能追加していくと見た目てんこ盛り、見た目めちゃくちゃリッチな状態になってしまうので、
そうすると使う側としても、特に一番最初の初心者からすると、
結構どうやって使ったらいいかわからんみたいな状態になる。
そういうときにウィザードのプローティングが出てきて矢印がついててとかあるんですけど、
あれはあれですごくウザいんですよね。
全部の機能を使いたいわけじゃなくて、結局一部の機能だけ使いたいとか、
目的が結構専鋭化されているというか、この課題を解決したいと思って使っているのに、
一番最初のウィザードがめっちゃ長い、別にそんな機能使わんしみたいな感じになっていると、
そこで結構デソッとしてくることはありますよね。
開発側としての当然伝わるはずは基本的に幻想であると、
内部で散々議論した機能もユーザーには初見、
どや顔の発表が疑問不で終わってしまうことも多いということですね。
問題提起の手法とユーザー理解
今すぐプロモーションはできなかったとしても問題提起はできると、
機能が開発する前からこの問題ってつらいよねという共感を呼ぶ情報発信が可能であるということですね。
まず問題提起から探っていくということですね。
問題に的を書いておくと、その問題がどれだけつらいか、
現状の対応がどれだけ煩雑かを記事や動画で繰り返し語っておくと、
そういう期待値を高めておくというところですかね。
ユーザーの共感を呼ぶことができると、そこに文脈ができていると、
いわゆる天の声で開発側からこうあるべきみたいなそういう話ではなくですね、
あるあるだよねというところでつながる体験の共有が
リリース時の理解を助けてくれるということですね。
複数の問題提起を並行して進められるというところがまた1個ポイントになってくると書いてあります。
DevRelの現場においては常に複数の開発が進行中であるというところで、
これから開発されていくロードマップ、公開してないところもあると思うんですけれども、
内部的にはそのロードマップってあるはずなので、
そのロードマップに則ってですね、文脈をまず作っていくということですね。
この射撃手法というのは製品の改善にも役立っていくと、
ユーザーの議論とか反応を見て、
ドキュメントやUIの改善点を先読みしていくのにつながるんじゃないかということが書かれてますね。
コミュニティの価値と透明性
これは非常に面白いですね。
あとは、これも面白いかな。
コミュニティの話なんですが、
ブックマークし忘れてたかな。
How to DevRel.
ベクデルテスト。
The Bechdel Test for Community.
ベクデルテストってすいません。
ちょっと私が知らなかったんですけれども、
これもまたちょっとサマリーでご紹介していきます。
まず、ベクデルテストの原点というところで、
女性2人が男性以外の話をするかという基準が驚くほど多くの作品で満たされていない。
全然意味がわからないな。
ベクデルテスト。
まずこのベクデルテストっていうのを知るべきですね。
ベクデルテストとは、
ジェンダーバイアス測定のために用いられるテストであると。
テストではあるフィクションの作品に最低でも2人の女性が登場するか、
女性同士の会話はあるか、
その会話の中で男性に関する話題以外が出てくるかが問われる。
2人の女性に名前がついていることも時としてテストの条件に付加される。
元々は映画を評価するために用いられ、現在ではあらゆるフィクションにおいて用いられている。
現代の映画の半分程度はこのテストをパスしないと言われており、
これは映画産業で働く女性の比率が低いことや、
業界人の観客の好みに対する想定ゆえであるとされている。
そういうことですね。
つまり女性が2人登場したら、
その人たちは男性の話題を話すよねということですね。
逆に男性が映画監督で、
女性に関する理解が低い状態で映画を作ったりすると、
そもそも女性が登場しないとか、
女性が登場しているにもかかわらず男性の話をしないというのが、
このベグデルテストの失敗というかNGになってしまう条件だということですね。
面白いですね。
今どきこの世の中において、
ジェンダー病が色々気をつけているという状態において、
このベグデルテストはなかなか危険な匂いがしますね。
ということで、ベグデルテスト自体は女性の云々みたいな感じなんですけれども、
このコミュニティ版ベグデルテストというのが上がっていますと、
本物のコミュニティとはどう思いますかね、
このベグデルテストに照らし合わせて考えた時にですね、
この中でレオンさんが言われているのは、
社員以外の人同士が会社や製品以外の話を公開の場ですることということですね。
まず営業活動は禁止であると、
コミュニティ内での営業行為は逆効果と、
ブランドを控えめにすると、
もう既にサイトの中に企業職は十分にあるということなので、
製品の情報は隅っこに置くことで、ユーザー中心にしていくということですね。
ユーザーとかコミュニティメンバーに対して無償労働を期待しないと、
例えばバグの報告とかベータテスターとかを無料で頼むんじゃないということですね。
あとは体験ベースの会話を促すと。
無償労働は期待しないというところがあるんですけれども、
参加への報酬も与えるとかですね。
公開のフィーチャーリクエストを行うとか、
ゲーミフィケーションで楽しさを求める、与えるとか、
最終的にはコミュニティは価値ある投資であるというところが書いてあります。
これは多分ユーザーコミュニティですかね。
何かの製品があってそれに対するユーザーコミュニティというところで、
このコミュニティ版ベクデルテストが使えるんじゃないかということですね。
社員以外の人同士がその会社や製品以外の話を公開の場ですることということですね。
面白い。
これ多分社員も入れてもいいと思うんですよね。
そのコミュニティとかに参加した社員がどういう立ち振る舞いをしているかっていうのは、
私は結構お客さんとかのコミュニティとかを作っているときには見るようにはしていて、
一番良くないのは端っこで座ったりとか、
一番後ろに座ったりとかする方っているかなと思いますし、
一歩引いてるんですよね。
飛び込もうとはしないし、溶け込もうともしないっていうところがあるかなと思っていて、
これはこのベクデルテストで言えば完全に赤点だと思うんですよね。
営業活動とかはしないですし、
そのブランドを控えめにするみたいなところもあるんですけれども、
自分自身があまり溶け込もうとしないっていうのは良くないと思いますし、
あくまでもユーザーの人たちが楽しんでいるのをサポートするだけみたいな、
そういう目線はあまり良くないかなと思ってるんですよね。
そのコミュニティマネージャーみたいな立場の人であればですね、
そこら辺の自分の立ち位置っていうのは分かるかなと思うんですけど、
社員がコミュニティに来たいですって言った時に、
全然個人的には来てほしいですし、来た方がいいと思ってるんですけれども、
どうせ来るんだったら、来るんだったらもうちょっと爪跡残せやっていう、
なんかこう、何でしょうね、
なんかすごく微妙な立ち振る舞いをする人が多い気がするんですよね。
なんかこう、距離感を、距離を保ってしまうのか、距離感が間違ってるのか、
ちょっと分からないんですけれども、そういう方いらっしゃるかなと思いますね。
あんまり良くないかなと思っております。
是非、ユーザーコミュニティ作るんであれば、
自分自身、会社の社員自身が楽しんで、
その上でみんなにも、参加している人たちにも楽しんでもらえるというところの
環境作りっていうのをやっていただきたいなと思いますね。
というところで、このHow to DevRelですね、
全部で5回あって、今回取り上げたのが、
情報保存の重要性
このコミュニティのためのベクデルテストっていうところと、
あとさっき言ったとおりのスパイダーマンのミュージカルから学ぶというところと、
あとテキサスの狙撃手の話っていうところで、
3つお話ししたんですけど、
あとですね、想像性を高める燃料の話とか、
あとは、これはなんだ?
It might not be new, but it's yoursということで、
新しくないかもしれないが、これはあなたのものだというのが
第1回目で書かれていますね。
この全5回のシリーズとなっておりますんで、
ぜひ興味がある方はですね、
このレオンさんのHow to DevRelシリーズですね、
見ていただきたいなと思っております。
ちょっとあれですね、
投稿するのをすっかり忘れていたので、
テキサスの狙撃手の話と、
あとはベクデルテストの話ですね。
そちらの両方をポストしておきましたので、
ぜひご覧いただければと思います。
あと1個ぐらい、日本のお話は何かあるかなとですね。
ツイログの話ね。
これいいなって思ったんですよね。
Togetherのノートですけれども、
自分の10年越え、
Twitterログが長記憶として対話可能に、
ツイログ専用MCPサーバーが使えるようになりましたという記事が出ております。
これめちゃくちゃ面白いなと思うんですよね。
何のためにツイログをやっていたのかっていうところがあり、
そのツイログにたまったものっていうのが、
いわば自分の分身とは言わないですけれども、
自分の記憶のサブストレージというか、
アーカイブになっている部分が多いと思うんですよね。
そこに対して質問をして、
それに対して返答をしてくれるっていうのは、
すごく面白い試みだなと思うんですよね。
そのMCPサーバーがクロードデスクトップとか、
クロードコードで使うのかちょっとわからないですけれども、
基本的にはクロードフォーデスクトップで使うということですね。
例えばここで書いてあるのが、
指示のポイントとしては、
タイムラインでのデータ取得とキーワードと、
あとはスタートデート、エンドデート、
あとインクルードリツイートというところの全部で、
多分5つぐらいのパラメーターがあるというところなんですけれども、
それに対して、例えばここで書いてある使い方の例としては、
去年のラーメンについてのポストを検索してっていうふうに言うと、
それを情報を絞り込んだ上で、
どこのラーメンの話とかですね、
それに対して感想みたいなものがあったりとかいうところが、
ポロポロと出てくるわけですよね。
これを本当、もともとメモ代わりとかで、
リハイの人たちがどんどんポストしていたとしたら、
本当その自分の分身みたいなものが、
向こう側に存在する状態にできるんじゃないかなと思うんですよね。
これは本当に望まれていた機能なんじゃないかなと思いますね。
個人的にはですけど、
Appleの作ってるnoteっていうメモ帳のアプリですね、
それがずっと使い続けているので、
そのnoteのmcpもあったりするんですよね。
それ使うと、noteの中の検索とかしてくれるので、
割と便利に使えたりするんですけど、
この難しいのって、
Webとかの検索で、
自分が何も知らない状態だと見つけられた情報が、
後でそれを探そうと思っても全然見つからない経験って皆さんないですかね。
私はしょっちゅうあるんですけど、
機器のものほど探せないっていう、
未知のものは探せるのに機器のものは探せないのが、
本当Googleの検索の使いなさだなってずっと思ってたんですけど、
それは私が悪いだけなのかもしれないですけど、
そういう風に思っていて、
機器の情報を探すときに、
こういうツイログとかは非常に役立つ可能性があるのかなと思うんですよね。
これって何も別にツイログだけに関係するものではなくて、
例えば自分の日本みたいなシステムと、
こういうMCPとかが合体することによって、
いつ頃やっていた作業に対しての質問であったりとか、
スラックのAIとかめちゃくちゃ使い勝手悪いみたいな話があったりするんで、
あんまり良くないかなと思うんですけど、
チャットのログが取れればいいんだけどね。
スラックのログを取得する部分も最近絞りが厳しくなってるらしくて、
自分の垂れ流した情報とか、
自分の思っているところを検索できる仕組みがあると、
それはこういう風に役立つのかなと思ったりしましたね。
今ちょっと話してて思ったのが、
最近いつぐらいだったかな、
たぶん1年か2年くらい前のデブレールラジオくらいがきっかけで、
西から来た馬面の男さんが手帳をつけていると。
ノート、普通のフィジカルなノートに物を書いているっていう話を聞いて、
その時から私もノートをつけるようにし始めたんですね。
最近ちょっとそれが発展してというか、
また別な情報源からバージョンアップして、
今全部で3冊ノートがあるんですよ。
全部大きさが違うんですね。
1つがA4のノートで、これは割と大きい、A4なので。
これは朝30分間ノートを取るという、
仕組み的に言うとモーニングノートという考え方らしいんですけど、
それがまず1つ目ですね。
これはもうしばらくやってるんですけど、
30分でA4を3枚埋めるのって結構大変で、
言ってみれば10分で1ページみたいな感じですね。
それをひたすら書き続けるっていう、
別に何書いてもいいっていうのはあるんですけど、
だいたい昨日の日記ですね。
昨日何したみたいな、何を考えたとかいうのが、
だいたい1ページか2ページぐらいに渡って書かれ、
今日やることみたいなのがまたさらに書かれ、
あと自分でその時にパッと思いついて、
このシステム作りたいなみたいなのがあったら、
その仕様をそのノートの中で考える限り書いていって、
実際その日に作ってみて、
その感想をまた次の日のノートに書いていくみたいな、
そんなことをやったりとかしますね。
あともう1個はですね、これはパスポートサイズのノートで、
トラベラーズノートっていうのがあるんですけど、
とにかくちっちゃいノートがいいというところで、
それを常に持ち歩いてですね、
何か思ったらとりあえずメモっておくみたいな、
そういうためのノートが1つ。
あともう1個はもともと西から来た馬面のお父さんが言ったときから始めてる、
これはB5サイズぐらいのノートで机の上に置いておいて、
これも仕事とかの関係とか、
何か気になることがあったらメモっておくみたいなものなんですけど、
その3冊ノートを使っているんですけど、
これを写真に撮って、
OCRかまして、
自分の知見としてどっかにアーカイブしておいたらですね、
多分それはそれで役立つんだろうなって今ふと思いましたね。
結構ノートを撮ってても見返さないんですよ。
特にモーニングノートは見返さないのがいいらしいみたいな話もあったりするので、
全然見返してなくて、
でももしかしたら役立つことをたまたま書いている可能性もあるかもしれないので、
そういったところでノートをテキスト起こしして、
自分専用のMCPサーバーみたいにしていくのはありなんじゃないかなって思ったんですけど、
1個大きい問題があって、私字が下手なんですよね。
悲しくなるぐらい字が下手なんですよ。
多分自分の字なんで読めるんですけど、
これをOCRかまして正しく認識される可能性が限りなく低いだろうなっていうのをちょっと思いましたね。
字がきれいになってからじゃないとできないかもしれないですね。
それかOCRした後、手動で修正するっていう情報みたいな作業は発生する可能性がありそうですね。
というギャッターさんの記事が出ておりました。
効果的な情報入力
こういったMCPの使い方として面白いなと思いましたね。
ある人はハテブとかの感想では、ハテナブックマークで同じことができるようになってほしいみたいな意見もあったりしましたけど、
確かにその通りで、検索の柔軟性みたいなものが担保されるんだったら、
そういう機能があっても面白いのかなと思いましたね。
ということで、そろそろ今日のメインテーマの方に入っていこうかなと思うんですけれども、
今日は効率的なインナウトというところで、情報の入力と出力のお話ですね。
個人的には、あんまり必要としない情報は仕入れないタイプなんですよね。
昔で言えば、RSSフィードとかあったじゃないですか。
もう全然使われなくなってるんで知らない人もいるかもしれないですけど、
とにかくたくさんのフィードを登録しておくみたいな、
トレンドとは言わないですけど、流れってあったと思うんですよね。
人によっては1000フィードぐらい登録してるみたいな感じで、
情報をとにかくインプットするんだみたいな感じの流れがあったかなと思うんですけど、
あんまりそれは好きじゃなくて、というか全然やってなくて、
もともと有名なIT系メディアとかも見ないし、
どうせ入れても役立たないやろうとか思ったら、
全然情報を仕入れようとしないタイプかもしれないですね。
その代わり、昔MoonGiftというサイトをやってて、
そこはオープンソースのソフトウェアを紹介するというサイトをやっていたので、
それについては、とにかくオープンソースに関連したようなサイトだったら、
全部登録しておくみたいな感じではありました。
特に人によって面白がられるのが、
宛名ブックマークでドメインのフィルタリングができるんですね。
例えばGitHub.comというふうに登録しておくと、
GitHubの宛名ブックマークが全部流れてくるようにできるんですけど、
そのときのブックマーク数を1とかにすると、
まだ本人しかブックマークしてないみたいな、
そういうリポジトリの情報とかもガンガン流れてくるようになるんですよね。
そうすると、本人が自分が作ったんで、
とりあえずセルフブックマークってしておいて、
それを私が拾って、私が紹介しちゃうみたいな感じのところで、
そのXとかで、なんでどこでこんな自分のやつ知ったんだみたいな感じで流れてくるっていうね、
そういうことはやってたんですけど、
それをやるとGitHubの情報量だけは膨大に流れてきたりするので、
それを処理するので時間かかったりとかはしてたんですけど、
効率的なインプット方法
今でいうと、今もFeedReaderはFeedlyっていうのを使っていて、
それはDevRelに関連したものだけを登録してますね。
それ以外の情報は全然見てないですね。
なので、Xとかも全然タイムラインとか見ないので、
基本的に発信オンリーみたいな感じではあるんですけれども、
情報はやっぱり仕入れないのが一番いいと思うんですよね。
ジャンキーになっちゃう可能性があるかなと思っているので、
よっぽど自分に関連する情報じゃない限りは、
極力ウォッチもしないようにしているっていうのが個人的なやり方ですかね。
ではですね、今日ご意見いただいておりますので順番にいきたいと思います。
まず最初がDevRelネーム西から来た馬面の男さんですね。
いつもありがとうございます。
今週のテーマは効率的なインナウトということでお便りします。
コンパスページにはこうありました。
現在は情報が氾濫し、気を抜くとインプットの嵐に飲まれてしまいます。
まさにそうですね。
特に生成AI関連は情報が飛び交っているので、
執着すると大変ですし、放置していたらそれはそれで乗り遅れるとかあるかもしれません。
自分なりのインプットアウトプット術があると、
差をせず落ち着けていいですねと。
そういうところでマインドセットとしては、他人は気にしないのがいいと思います。
人と比べても仕方がないので、人は人、自分は自分で。
他人から刺激を受けるのはいいけど、競っても仕方ないので。
次にアウトプット前提のインプット。
アウトプットにつなげるためにインプットするという考えが効率的でしょう。
学校の勉強ではないので、インプット型になっては意味がないと思います。
アウトプットすると決めていると、自然と情報に対して目にも止まるようになるでしょう。
私はIT勉強会に行って話を聞いてインプット、
その場で周りの人と話したりして、エクスポストしたりするアウトプットを実践しています。
効率はあまり良くないですが、自分の性に合っていると思います。
以上、私のインプット、アウトプット術を述べました。
今週もありがとうございましたといただきました。
ありがとうございます。
そうですね、このアウトプット前提というところは、
一個大事なポイントにはなるかなという気はしますよね。
さっきの私のサイトでアウトプットするというところがあったので、
それに合わせてインプットしているだけというのがあったというところですね。
レフレルに関して言うと、このラジオのネタというところが一つと、
あと自分が仕事で関わっているというところがあるので、
情報収集しているというところですかね。
あとは人と比べても仕方がないというところですね。
RSSフィード前世の頃で、
勉強会とか行くと、今のAI系もそうだと思うんですけど、
今日あった大きいニュースとか、
昨日あったでっかい出来事みたいなのが、
わちゃわちゃ話されたりするという時があったと思うんですよね。
今でも多分あるんだと思うんですけど、
そういったところで一緒に会話に乗れるようにとか、
会話を楽しめるように情報収集していた部分というのはあったのかなと思いますね。
IT勉強会に行ってインプットをし、その場の周りの人と話したり、
あとはXでポストするというところでアウトプットをしているということですね。
アウトプットは別に何も、デジタルじゃなくても、
他の人と喋るというところも素晴らしいアウトプットだと思いますので、
それもとてもいいことかなと思いますね。
あとはここに書いてありますけど、
自分の承認に合ったやり方というのは大事ですよね。
ジャンキーになってしまったりとか、
自分の必要じゃないところまで詰めてしまったりとかすると、
割と自分では実は手を動かしていないのに、
見知った情報で判断するようになってしまったりとかする場合もあるかなと思うので、
自分の承認に合ったやり方で、
きちんとその情報の試写選択をできるようにするというところが、
大事なポイントなのかなと思いますね。
ありがとうございます。
では続いてですね、
DevRelName Janninmanさんですね。
いつもありがとうございます。
効率的な情報のインプット・アウトプット術お便りします。
本音を言うと、東方も教えてほしい気持ちです。
ただ気をつけていることは、
情報をインプットするときは、
意識して行動し、だらだら見続けないようにしています。
アウトプットの実践
Xを例に出すと、意識的に情報を取りに行くときは、
フォローではなく、
おすすめのタイムラインを見るような行動の違いです。
思いがけない出会いや気づきもあったりします。
他の方の術も楽しみですということですね。
これ、おすすめタブって、
私最初知らなかったというか、気づいていなくて、
自分のフォローしている人というか、
おすすめタブっていうのがあるって知らなかったんですね。
おすすめタブがデフォルトで表示されているという時期があって、
面白い動画がめっちゃ流れてくるなみたいな感じだったんですよね。
写真でもそうかなと思うんですけど。
そこにはまると、本当に無駄な時間を
使いまくってしまう可能性があるかなと思って、
フォローとかもありますけど、
割と仕事で使ってたりする場合もあったりするんで、
DMとかは見るんですけど、
そんなにフォローも最近は見てないかなと思いますね。
Mixで情報収集してる人って本当に多いと思うんですけど、
皆さんどうやってやってるんですかね。
私全然フォローとかが相互フォローぐらいしかないような気がするので、
どうやって情報収集するのかが、
未だによく分かってないかもしれないですね。
使い方下手すぎますね。
もうちょっときちんとした使い方を 覚えなきゃいけないかなという気はしますね。
ではですね、3番目ですね。
DevRelName 札幌のじゅんさんですね。
いつもありがとうございます。
主にSNSを通じて情報を集めていますので、
吟味のいらないタイムラインを構築しておくというのが、
効率的なインプット方法の一つになります。
これよね、これ。
多分これが私できないんですよね。
仕事とかの、仕事というかコミュニティ周りとかの話で、
DMを送るためにフォローしたりとかしていたりすると、
だんだん洗練されたタイムラインではなくなっていくんじゃないかなと思うんですよね。
どっちかというと、コミュニティマーク向きのタイムラインに仕上がっちゃってるかなという気はしますね。
今現在手を動かしているのであろうエンジニアさんを少数フォローしている以外、
ほぼフォローしない方針でやっていますということですね。
ということはこれは定期的に整理しているかもしれないですね。
誰かを燃やして対立させることで利益を得る類いなアカウントはほぼブロックして、
驚き屋と呼ばれる人はミュートしています。
いずれも自分の感情のノイズを呼ぶ存在なので視界には入れません。
そうですね、私もここら辺はそんな感じですね。
超有名な芸能界の人とか、超有名な社長とかはリポストする方が多かったりするので、
その社長自身をブロックしてたりとかしますね。
驚き屋みたいな人は気になったらミュートするくらいかなと思いますね。
アウトプットについては自身の体験を詳細に報告することを続けており、
自分がまたがっている分野の数だけ使い回しが効くので、
むしろ関係する分野を増やしていくことでドキュメントの価値を上げています。
最近何やってる?などの情報交換にわざわざ打ち合わせ時間を取ることをしなくても、
記事を渡せばいいので、こちらの時間の節約にもなっています。
そうですね、レジュメとは言わないですけど、
自分のプロフィールを常に整えておくっていうところですよね。
これこそAIがうまくできそうな気がするんだよな。
ツイログのところは私は面白いと思うんですよ。
プロフィールというのかな、自分の分身というかポートフォリオみたいな感じかな。
そういうものが自動で作れる可能性があるんじゃないか。
自分が鍵垢でやっていたらあれですけど、
基本的にオープンな場所でやっているXの情報であれば、
自分が何に興味を持っていて、
最近はどういうことをポストしてみたいなのをサマライズして、
人に見える形で出したりとか、
それを100文字のプロフィールにしてまとめて、
定期的にXのプロフィールを更新するとか、
そういう使い方ができるんじゃないかなって思ったりしますね。
ちょっと期待しすぎなのかもしれないですけど、
私はツイログのMCPサーバーっていう話題は、
かなり面白いんじゃないかと思いましたね。
じゅんさんからコメントいくつか来てますね。
情報の選別と管理
ビジネスインフルエンサーとも距離を置いていますと。
そうですね。
そういう私もここら辺は、
ちょっとあまり得意ではないというか、
距離を置く傾向があるかもしれないですね。
ニッキーズ仕事と。
そうなんですよね。
私は日本の文化ってすごい嫌いなんですよね。
見りゃ分かんじゃんみたいな。
Gitのログ見りゃ分かんじゃん。
何やったか分かるし、
あとはGoogleカレンダー見れば、
ミーティング入っていたのか、
どこに行ったのか分かるし、
ミーティングだったら議事録をLLMに加わせればまとめてくれるし、
その日報を作るためのインプット情報ってあると思うんですよね。
そういうのをうまく処理してくれさえすれば、
我々はそういう無駄なところの時間はやらなくてもいいような気がするんですよね。
今逆になってきてるような気がして、
ブロードコードとかDevinとか他のAIツールとかにコードを書いてもらって、
それが何をしたかを日報として人間がまとめるみたいな。
本当に楽しかった。
ブランコのタイヤが付いたブランコ。
違う違う、あれは普通のブランコだったかな。
顧客が本当に欲しかったものですね。
多分顧客は本当はブランコが欲しかったのに、
営業の立場からするとすごいリッチなものになったりとか、
エンジニアの理解はもうちょっと解像度が低くてとか、
みんなが考えていることがバラバラだったみたいな、
そういうカードみたいなやつがありますけど、
人間が本当にやりたかったものみたいなところがどんどんAIに食われていって、
残った面白くない仕事の部分だけ人間がやっているみたいな感じの状況に
今なりつつあるのかなという気がしますね。
ではですね、最後イベントのご案内などになります。
DevRelConニューヨークについて
まず最初にですね、来週のこのDevRelラジオなんですけれども、
おそらく配信になると思います。
来週ちょっとDevRelConニューヨークがありますので、
そちらに参加するためにですね、
多分時差の関係でライブで配信するのは難しいんじゃないかなと思っております。
なのでおそらく来週は配信になる予定です。
そうなるとですね、お題のテーマは立てるんですけれども、
割とちょっと早めに回答いただいた方が読まれる可能性があるかなと思います。
おそらく日曜日とかに収録するかなと思うんで、
できればそれまでにいただいているとですね、読めるかなと思っております。
あとはですね、DevRelConから帰ってきた翌週ですね、
DevRel東京のイベントをやりますと、
まだまだちょっと参加者少ないので、ぜひですね、皆さんご参加ください。
DevRelConのリキャップっていうところをやっていきたいと思っているので、
全然ねセッションの情報とか調べてないんですよね。
これもなんか前にラジオで話したような気がしますね。
ちゃんとこうカンファレンスのことを調べて、
どのセッションを聞いてどういうところを注目するかとか、
そういうのをちゃんとあらかじめ計画立てるべきみたいな話があったと思うんですけど、
計画を全く立てていないですね。立てないといけないですね。
というところと、あとは10月2日から4日のDevRel会議ですね。
こちらの方はチケットの販売を開始しておりますので、
ぜひですね、ご参加いただきたいというところですと。
今回はですね、ランチとかアフターパーティーとかですね、
そこら辺をバラで販売しています。
全部セットになったコンボみたいなものも用意してるんですけれども、
セッションだけっていう場合もありますし、
セッションとランチ、あとセッションとアフターパーティーみたいな感じですね。
いくつかに分割して販売をしております。
参加者への案内
これは参加者が多いからといってですね、
皆さんがランチ食べるとは限らないんですよね。
これをやらかしたのが多分DevRelConの横浜とかですね、
あと去年のDevRel Japanとか、
結構その参加者は多かったので、
それなりに食べ物を用意したんですけれども、
余らしてしまったというところの反省があってですね、
今回は食べないんだったら全然安く参加していただきたいと思いますし、
食べるって言ってもそんな別にね、
暴利でこっちが儲かるみたいな感じでは全然ないので、
それに見合ったお弁当を普通に用意するというところをやっていきたいと思うので、
ぜひご自身がランチタイムも参加したいというところであれば、
ランチ付きを買っていただいて、
最後のアフターパーティー参加して楽しみたいという方は、
アフターパーティーのチケットをご購入いただければなと思っております。
というところでですね、
今日のDevRelラジオ223回目ですね、
効率的なインナウト、こちらで終了していこうと思います。
では来週はですね、おそらく配信になるかなと思うんですけれども、
また皆さん来週、
万が一ですね、万が一ライブでやるとなったら、
多分私は残念ながら日本にいるんでしょうね。
これはですね、去年のDevRelConベンガルールで、
私は直前になって腰を痛めてですね、
多分ぎっくり腰やってしまって、
本当に動けなくて、
全く飛行機に乗って7時間座り続けるなんて絶対無理みたいな感じになって、
なくなくホテルと飛行機キャンセルしたという記憶があるんで、
そうならなければですね、
そうならなければ配信になりますし、
もし万が一ライブ配信だったらですね、
何かあったんだろうなというところで、
生温かく見ていただければと思います。
ではですね、また皆さん来週ですね、
224回目でお会いしましょう。さよなら。
