DevRel Radioの始まり
はい、皆さんお疲れ様です。今ね、ちょっとネットワークの調子がめちゃくちゃ悪いんですよね。
ちょっとごまかしながら、あ、いや、あってんなあ。あってんなあ。このネットワークまた重たいなあ。
はい、DevRel Radioのですね、今日は207回目やっていきたいと思います。
まず最初にですね、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間程度お送りしているというものになります。
DevRelというのはですね、デベロッパー・リレーションズの略で、
自社とか自社製品と開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えば、デベロッパー・アドボケイトとか、テクノロジー・エヴァンジェリストとか、コミュニティ・マネージャーとかですね、
そういった方々が集まって情報交換したり、
マンスリーでイベント、DevRel Tokyoの公式サイトがあります。
DevRel.Tokyoというドメインですね。
そちらからスラックに参加もできますので、
DevRelに関わっているとか、興味があるという方はぜひジョインしてください。
そこまでじゃないよという方はですね、公式なXアカウントがあります。
こちらはアットデブレル東京ですね。
そちらで普段、シャープデブレルJPというハッシュタグでポストしてますので、
アカウントをフォローいただいたりとか、
あとハッシュタグをですね、ウォッチいただければありがたいですというところで、
先ほども言った通りですね、ネットワークの調子が悪いんですが、
悪いなぁ、650キロBPSとかギリギリ2メガBPSぐらいしか出ないですね。
もしかしたらすいません、ちょっと映像とか音声がですね、悪い可能性があるんですけれども、
お付き合いいただければと思います。
今日のメインテーマはですね、
今日は参加するしないイベントとなっております。
特に東京界隈ですよね。
イベントがあまりにも多すぎるというところがあってですね、
同じ日で興味があるイベントが複数開催されたりみたいなことはね、
結構ザラなのかなと思っているので、
イベント参加の選択基準
そんなときにですね、
自分の選択基準というかですね、
こういう基準でジョインしたり、
逆に諦めたりみたいなところがあるというのがあればですね、
ぜひお聞かせいただきたいですね。
複数参加とかもできないわけじゃないですよね。
一瞬で切り替えることもできますし、
人によってはね、複数にジョインしておいて、
片方は音声切っておいて、
映像だけ見て状況に応じて切り替えるみたいなことをやっているかもしれないですけれども、
そのあたり含めですね、
皆さんがどういう風な感じでイベントに参加しているかというところを
聞かせていただければと思います。
それまではですね、最近のDevRel周りのニュースとか記事とか紹介できればなと思うんですけれども、
私がね、すっかり忘れてたんですけど、
忘れてたっていうのもあれですけど、
DevRel.Guideっていうですね、
サイトをやってたんですね。
やってたというか、やってたのかな。
DevRelに役立つようなサイトを紹介するというサイトをやってたんですけれども、
それと全く同じコンセプトのサイトがですね、
出来上がって、こちらもDevRel.Guideっていうサイトなんですけれども、
まんまやんけみたいな感じなんですけど、
そんなサイトがですね、できておりますと。
ドメインはDevRel.Guide.comっていうサイトで、
特徴としては、各種リソースを紹介していたりとか、
ホワイトペーパーとかですね、そういうのが紹介されているんですけど、
あと、ジョブボードもありますね。
Nintendoとかもあるんですね。
アカウントアドミニストレーター、
パブリッシャー&デベロッパリエーションズっていう題目で、
Nintendoで求人とかも書けられてますね。
で、あとはリソース的にはですね、
DevRel Strategy Playbookとかですね、
イベントプランナーテンプレートとか、
そういうのがあったりするんですけど、
その中でちょっと面白いのはね、
これがまず、まだこれを使えるのかな?
コミュニティグロウストラッカーっていう名目。
ただ、コミュニティグラフビルダーっていう名前なのかな?
例えば、自分、これはビジュアルだけなのかな?
ノードを追加してそこに対して大きさを指定すると、
それぞれのコミュニティの大きさが、違いが可視化されるとかですね。
あと、何だったかな?
これじゃない。
DevRel ROI Calculatorっていう、
これはまだ動いてない。
いや、動いてはいるのかな?
動いてはいるのか。
でも、グラフ化がうまくいってないんですけど、
インプットっていうところが、
自分たちの取り組んでいる活動の名前。
ここではデベロッパーアドボカシープログラムってなってるんですけど、
ROIのタイムフレームが、
3ヶ月、6ヶ月、1年、2年、3年みたいなタイムスパンを決められて、
あと通貨の単位として、USドルとJPYもあったりしますね。
決められて、あとはディスカウントレート。
これはよくわからないな。6%とか10%とかあるんですけど、
それを決めてですね。
それに対してのコストっていうのが、
例えば、デベロッパーアドボケイツに対していくら払ってるとか、
イベントがカンファレンススポンサーシップでいくらですとか、
そういう支出側を登録していくんですね。
最後、ベネフィットみたいなところで、
新しいユーザーが何人獲得できたとかですね。
クスタマーサクセスでサポートのコストをいくらぐらい削減できたとかですね。
あとはコミュニティのコントリビューションがどれぐらいあったとか、
リテンションはどうだったかみたいなね。
そういうのを計算していくと、最終的にトータルのベネフィットっていうのが
どのぐらいありましたよねっていうのが可視化されると。
それらを組み合わせてですね。
インプットとコストと、あと最終的なベネフィットっていうのが
どういうふうに事業に対してコミットしていったかみたいなのを
可視化できるよっていう、そういうものになっています。
技術ミートアップの成功
結構、金額的な事業に対してのコミットがどうだったかっていうところの
可視化ってなかなか毎度難しかったりするっていう
課題感が出売れるにはあるので、それをどういう形にしたとしても
こうやって一旦可視化してあげるっていうのは
結構大事なことなのかなという気がするんですよね。
これはかなり単純な図式化はされているような気はするんですけど
一つ面白いアイディアかなと思いますね。
他にもいろいろビジュアライゼーションっていうところで
コンテンツパフォーマンスダッシュボードとか
イベントインパクトアナライザーとか、あとデベロッパージャーニーマッパー
デベロッパージャーニーマッパーはない。
これもない。なんだ。ないのばっかりだな。
あとはこれは何なんだろうな。
Develop everything you need for development success
というところで、データドリブンインサイト
コミュニティビルディング、リソースライブラリ
プログラムテンプレート、サクセスストーリー、グロスストラテジー
そういうことね。ここの機能の紹介ですね。
それでいくと、リソースの中だったかな。
いや、リソースはどっちかっていうと
いろんなブログ記事の紹介みたいな感じですね。
DevRelプログラムっていうところは
これはなんだろうな。
Developer Relations Programっていうのがあって
多分コミュニティの取り組みですね。
例えばAWS HeroesとかGoogle Developer Expertとか
DockerはDocker Captainっていうのがあるんですね。
他にもあってGitHub Campus Expertとか
Auth0 AmbassadorsとかCNCF Ambassador
AWSはもう1個ありますね。AWS Community Builder
でMicrosoftのMVP。
紹介されてるのはこれだけかな。
オールプログラムでこれだけか。
もっといろいろありそうな気はするんですけどね。
ここにはそういうプログラム系。
そうだよね。IBMとかもありますよね。
日本だとLine Expertだったりしますよね。
そこら辺は載ってないみたいなんですけど
それは今後増えていくかなというところですね。
DevRel Guideっていうサイトができておりますので
気になる方はチェックしてみてください。
続いてのところで
どれがいいかな。
これもなかなか面白かった。
これはDev.toの記事なんですけど
Template for Hosting a Successful Tech Meetupということで
技術ミートアップのホスティングに関して
それを成功させるためのテンプレートが出ております。
これがどこの国に対して言ってるのかちょっと分からないんですけれども
メシを提供するっていうのが項目としてあるんですよね。
Shipyardっていうプロダクトのブログ記事ですね。
まず探すのはmeetup.comか
あとルマカレンダーっていうのもあるらしいですね。
これ日本語かもされてるな。でも知らないなこれ。
Lumaっていうやつですね。
ルマ。イベントページを作成し友達を招待しチケットを販売。
今日から思い出に残るイベントをホストしましょう。
なんとなくイベントレジストに近い。
でもなんか日本語のイベントもそれなりにありますね。
あんまないんですけどkoスタートアップフェスとか
わさびナンバーワンとか東京イベントとか
AIのイベントもそれなりに登録されてたりしますね。
誰が使ってるんだろう。外国人が多いのかな。
AIサロン東京とか。あんま日本では見ないけど
meetup.comは有料サービスなので
多分それがあってこっち側に逃げてるというか
ルマを使ってる方いるのかなという気がしますね。
そんな感じでmeetup.comとかルマカレンダーとかを使うと。
その後がアクセスしやすい会場を見つけると。
イベントを企画する際には参加者がアクセスしやすい場所で
開催したいものですと。
私たちは主要な公共交通機関の近くにある会場を
うまく利用してきましたということですね。
東京とかだったら土地感があるんで
地元のアクセスしやすい場所とかって分かりやすいんですけど
地方とかインドとか全然この土地感がないところとかで
イベントやるときってそこがアクセスしやすいのかどうかっていうのは
やっぱり地元の人に聞かないと分からなかったりしますよね。
共同ホストを見つけるのも大事ですということが書いてありますね。
少なくとも共同ホストの人は食べ物や飲み物を会場に運ぶのを手伝ってくれると。
これは大事ですね。
コミュニティ内でスピーカーを探すということですね。
これはインドめちゃくちゃ楽なんですよね。
誰か喋ってって言ったらバッって手が一気に上がるんですよね。
ミートアップの規模が大きくなったらスピーカーCFPを作成することにも意味があるかもしれません。
それも面白いですね。
そしてミートアップの宣伝としては
スラックやディスコードなどの開発者コミュニティで共有をしたり
あとはイベントブライトとかミートアップ.comもいいでしょう。
イベントへの参加者を惹きつける方法
ヒントナンバー7
ゲストに食事を与える
あなたのミートアップはおそらく仕事の直後に開催されるでしょう。
ゲストは夕食を取る時間がないのでおそらくお腹が空いているはずです。
食事を与えなければ最後まで残る可能性は低くなります。
これはどこの国のことを言ってるのかわかんないですけど
お腹空いてると帰っちゃうんですね。
わりと日本だと帰らないような傾向がある気がするんですけど
食事を与えないと最後まで残ってくれないということですね。
一人一人に完全なディナーを用意する必要はないが
前菜や軽食があれば十分。
もっとカジュアルなものならピザが一般的だと
ただしベジタリアンやグルテンフリーのオプションも見逃せないと
チーズ野菜フルーツサンドイッチパンなどを使えば
簡単にワンランク上のスタイルになる。
これは海外の話ではあるんですけど
パンデミック後の技術系ミートアップの参加者は
あまりアルコールを飲まないことがすぐにわかった。
ノンアルコールの炭酸水とビールを4対1の割合で提供するのが
効果的でしたということで
日本もその傾向が強くなっている気がするんですよね。
なんとなくなんですけど、私のあくまで裸なんですけど
私自身も本当に飲まなくなってますし
イベントとかで自分でホスティングというか
飲み物を準備したりするときに飲まない人が多いな
なので最近はソフトドリンクの種類を
いかに増やすかみたいなところを結構考えてたりしますね。
アルコールって結構単純というか
準備する方もあまり考えずに選択できると思うんですよ。
とりあえず朝日スーパードライとプレミアムモルツとか
ビールってそんなに何種類も用意しなくてもいいと思うんですよ。
1種類か2種類。
あと焼酎系のやつとかを適当にあり
ハイボールがあれば十分。
お酒のカテゴリーとしては3つか4つぐらいあれば十分みたいな気がするんですけど
ソフトドリンクってすごい種類多いんですよね。
でもそんなに飲まれるものと飲まれないものの比率が
差が激しい気はしていて
一番飲まれるのはお茶だと思うんですよね。
その後は水とか炭酸水とか
夜のイベントなのでコーヒーとかは好まれない気がするんですよね。
ウーロン茶とかを用意してもなかなか進まなかったりする傾向があるかなと思ってて。
だから最近は午後の紅茶とかは何種類も用意したりとか
あとはオレンジジュースとかどうなんだろうな。
全然用意したことはないですけど
結構ソフトドリンク悩ましいんですよね。
とりあえずこれだけいっぱい置いときゃいいやろうみたいな感じで
もしお茶ばっかりだとあんま面白くないというか飽きちゃうだろうし。
去年のDevril Japan Conferenceの時は
お茶と水を大量に用意してたんですね。
それは会場の冷蔵庫とかもキャパが決まってたので
飲み物とか前日に届けなきゃいけなかったので
炭酸は置けないというか置きづらかったんですよね。
どのタイミングだったか忘れたんですけど
コーヒーを途中で入れたんですよ。
それは冷たい状態で持ってきてほしかったから入れたんですけど
コーヒーの売れ行きがめちゃくちゃ良かったんですよね。
水、お茶、コーヒーってやった時に
コーヒーがすごい勢いでなくなって
あれは多分昼間のカンファレンスっていうのもあると思うんですけど
お茶はその次ぐらいで
水がそんなに取られなかったみたいな感じだったんですよね。
なのでソフトドリンクはね、この記事でも言われている通り
最近は参加者があんまりアルコールを飲まないということはあるんですけれども
じゃあノンアルコールのもの何用意してらいいのよっていうのは
悩ましいんですよね。
一貫した計画の必要性
続いてのところでヒント8っていうのがありますね。
例えばプレイリストを作り
バックグラウンドに音楽を静かに流すとか
イベントのスライドショーを作成し
ダウンタイムの時に会場のスクリーンで流すとか
ゲストにそれぞれに対して十分なスペースがあること
またゲストが立ち話をする場所があることを確認しましょう
ゲストがプレゼンターをはっきり見られるように
いろいろな角度から場所を確認しましょうというふうに書いてありますね。
ヒント9 参加者リストの関心を高め続ける
最終的にはアテンディの40から50%が来てくれると思ってくださいということですね。
これ割と参加率低い気がするなぁ。海外そんなもんなんですかね。
インド30%ですけどね。全然来やしない。
本当に300人くらい登録して100人しか来ない。
もう数の論理的には全然いいんですけど
来ねえみたいな感じになりがちですね。
一貫性を保つというところで最後は
ミートアップが終了したらすぐに次のミートアップの計画を立てましょう。
素晴らしいミートアップを経験したコミュニティは
さらに続いての話を聞くのを楽しみにしているはずです。
勢いはここで価値がある。
日々頻繁に開催すぎると常連が飽きてサボってしまうし
開催頻度が低すぎると人々が忘れて盛り上がりが冷めてしまうということですね。
ミートアップを開催するたびに
その前のミートアップほど大規模なイベントにする必要はありません。
カジュアルなコーヒータイムやハッピーアップタイムなどをあちこちに入れれば
時代的に開催する余裕がなくてもコミュニティが再集合する機会を得られるはずですということですね。
ドキュメントの重要性
そういったところをやってこのShipyardというところで活動をしているということですね。
ShipyardはShipyard.buildかな。
ニューヨークなんだ。
Shipyard.buildっていうのは何だろうな。
あれ?何のサービスなんだShipyardって。
セルフ開発者製品QAチームのために全てのプルリクエストで自動化されたレビュー環境を提供するサービスということですね。
自動レビューのサービスなのかな。
最近私のところでやってるCode Rabbitとかに近いサービスなのかな。
ちょっとよくわかんないですけど。
そんなShipyardというサービスのお話ですね。
ジュンさんからコメントきてますね。
札幌での駅地下解除の確保は任せてということですね。
こういうジュンさんみたいな方がいるとすごい心強いですよね。
変な場所で決めちゃったりするんですよね。
働いてる場所とかが分かっていないので。
例えば岡山とかでイベントやりますって言ったときに。
岡山でイベントやると岡山だけだとそんなに規模が大きくならないっていうところもあって。
意外と隣の県の広島からも人来てくれるんですよね。
そうすると広島からアクセスしやすい場所ってどこやろうみたいな。
前、倉敷でやったときにも人は来てくれたんですけど。
もしかすると岡山でやったときの方が広島の人も参加しやすいとかですね。
大阪でやったときも梅田のあたりとかでやると三宮の方からも人が来やすかったりとか。
それこそ京都から来てる人とかもいたりとか。
確か京都から急行で30分ぐらいとかありますよね。
なのでその場所によってすごくアクセスきやすい場所っていうのは変わりますし。
あと働いてる場所とかも東京だと山手ならどこでもいいやろうっていうのは結構乱暴ですよね。
新宿、渋谷、品川あたり。
そのあたりのラインとかでやれば割とウェブ系のエンジニアというか、
そんな規模の超でかくない会社とかは来やすいかもしれないですし、
丸の内とかになればね、金融系とは言わないですけどそういう人たちが来やすいとか。
それぞれ属性があるかなっていう気はしますよね。
じゅんさんからもう一つコメント来てますね。
ターゲット層の生息地域と公共交通の要所と懇親会会場への同棲を考えて決めてます。
確かに懇親会会場も大事ですよね。
北海道はでも、そこで会場で懇親会やらせてくれて、
かつそこの会場の近くにスーパーがあればもうパーフェクトだと思うんですよね。
生地店とか行くよりも、スーパーで8時過ぎとかに買ってきた食べ物の方がすごくおいしいっていうのが記憶の中にあるので、
スーパーがあるところは最高ですね。
で、懇親会ってなるとどうしても札幌の駅から鈴木野の方に歩いていく間とかになるかなっていう気はするんですけど、
今まで一時会でなかなか入れる店多くないんですよね。
あらかじめ決めておけば違うんでしょうけど、
結構人がいっぱい、どこのところもいっぱいで、大抵二次会ぐらいからしか店入れないイメージがあったりしますね。
トリトンのお持ち帰りを会場に運び込んだりしてましたね。
そう、こういうのがね、本当に地元の食べ物がおいしすぎるっていうのがいいですよね。
大抵のね、そこらへんのご当地のおいしいものありますからね。
意外と東京がないんですよね。東京ってご当地の食べ物、あんまりわかんないというか。
なんでしたっけ。
もんじゃ焼きとか、あさりじゃなくてしじみの混ぜご飯とかでしたっけ、確か。
あそこらへんが東京名物らしいんですけど、食べないですよね。皆さん食べますかね。
横浜の名物って言われてシュウマイとかって言いますけど、横浜の人ほとんど食べないと思うんですよね。
私も全然、清家のシュウマイとかほとんど食べないんで。
意外とそういう名物料理って、そこらへんに住んでる人は食べないんじゃないかなーっていう気がするんですよね。
でも北海道はおいしいですよね。
ではですね、もう一件とりあえず言っておこうかな。
これはですね、ブルーウィッシュの宮下さんが書いたスライドですね。
そのドキュメント、ちゃんと生きしてる、使われ続ける、生きたドキュメントの育て方という記事が出ております。
この考え方すごく大事だと思うんですよね。
本当に20年ぐらい前かな。
私が会社に所属してシステム開発してたのは、それこそ多分20年ちょっと前ですけど、
その時よりも今の方がすごいドキュメントに対する重要性っていうのは増してると思うんですよね。
特にLLMというかAI開発の時代に入って、よりドキュメントが求められる時代になってるのかなという気がしていて。
それこそ昔でいちいちドキュメントに残す文化ってあんまなかったと思うんですよね。
当然お客さんのシステムとか開発してる場合っていうのは最初ちゃんと使用書作ったりとか基本設計作ったりER作ったりとか段階経て作っていくんですけど、
そのドキュメントをちゃんとメンテナンスし続けるケースってそんな多くなかったのかなという気がしていて。
私が一回出会ったのは、とある会社の業務システムのリプレイスで一番最初に作ったシステムのドキュメントはありますと。
次にそのシステムを一回バージョン1からバージョン2に変更したプロジェクトが走ってるんですけど、その時のドキュメントもありますと。
ただ現在動いているバージョン2がどういう仕様になってるかっていうドキュメントは存在しないんですね。
バージョン1のドキュメントとバージョン2のドキュメントを全部読み込んで、それを自分の頭の中でマージしたら最新のドキュメントが出来上がるっていう内容になっていて、
バージョン1のドキュメントだけでめちゃくちゃ分厚いんですよ。バージョン2のドキュメントもそれなりにその3分の1ぐらいあるみたいな感じで、
こんなドキュメント読めるわけないじゃん。しかもそれを完璧に読み込んで、完璧に現状のシステムを把握するのって無理じゃない?みたいな話になったことがあったりとかして。
ドキュメントを作る文化がないわけではなかったと思うんですけど、この生きたドキュメントとして使われる文化って、本当ここ5,6年の話なのかなっていう気がするんですよね。
ドキュメント化の重要性
まずドキュメント化とはというところで、ある事柄に関するデータや情報記録などを他の人が理解しやすい形式の文書として体系立ててまとめることということですね。
つまりドキュメントとは情報を整理し、誰でも理解しやすい形にするということだということですね。
ドキュメントのメリット・デメリットっていうのも上がっていて、まずメリット、情報の散逸防止、業務品質の均一化、業務俗人化の解消というところを挙げてます。
ただ逆にデメリットもあって、作成コストの増大、柔軟性の低下、境界化のリスクというところが上がってますね。
確かに作成コスト、作成もありますけど更新のコストですよね、ドキュメントはね。
本当に細かいとこまで書いてドキュメント作るっていうのも大事なんですけど、
その細かく書いた内容を読み手の人が100%理解してくれるかっていうと、それはまた別問題っていう気がするので。
書いたからといって、それをちゃんと受け止められるかは別問題というところを考えると、境界化するリスクもあるのかなという気がしますね。
ドキュメントが更新されず境界化することを、ここではドキュメントの化石化と呼んでますね。
化石化を防ぎ、ドキュメントを生きた情報にするにはどうしたらいいかということで、
ドキュメントを育てるサイクルというのを4つ挙げてます。
必要な情報の選定、ドキュメントの作成、練習権限の開放、最後に定期的な更新と運用というところが上がってるんですけど、
個人的にはここら辺でAIに吉田にやってもらいたいなっていう部分ではあるんですよね。
例えば議事録であったりとか、開発者同士のミーティングであったりとか、
あとはチャットの会話であったりとか、あとはソースコード自体を読み込んでとか、
そういったところでその結果をどこが変更されていて、それがドキュメントにどういうふうに影響を及ぼすのかみたいなところは、
こここそAIにやってほしいなって思いますね。
ドキュメントの選定というところで3つタイプが挙がってますね。
1つ目、感覚型。長年の経験や知見から感覚的に対応する業務のこと。
2番目、選択型。いくつかの選択肢から適切な対応をする業務のこと。
4、単純型。誰がやっても結果は同じ単純な業務というのが挙がってますね。
ドキュメントの作成というフェーズは1ドキュメント1トピック。
これは大事ですね。更新のことを考えるとこういうふうにしなきゃいけないですね。
テンプレートを作る。テンプレートでフォーマットを統一するということで、誰でもすぐに作成できるようにする。
3番目、ビジュアルを活用。過剰書き、表、スクリーンショットを活用し、視覚的に伝わりやすくする。
過剰書きは全然OK。表もギリギリOK。スクリーンショットは更新する手間と情報量がどうしても増えてしまうので、
何らかのアノテーションを含めないとちゃんと伝わらないというところがありますよね。
ドキュメント化そのものを俗人化作業させないために編集権限を付与していく。これは大事ですよね。
結局同じ人が更新ばっかりしているとかだとすごい負担が偏りますよね。
ドキュメントは1人で作るものじゃない。チームで育てようと。これはまさにその通りですね。
ドキュメント化した後は3つやることがあります。
ドキュメントを関係者に共有する。変更や追加点があれば各自で更新する。
これも本当は思いますよね。更新しといてとか、こういうふうにやっといてくださいみたいな感じで言われるんですけど、
いや、何のための編集権限なんですかって。そういうふうに編集したいと思うんだったら自分で編集したらいいじゃんってツクツク思うときありますね。
更新したらすぐに関係者に共有するということですね。
更新されないドキュメントはやがて化石化する。
確かに。
ドキュメントは作って終わりではない。みんなで育て続けることで息をし続ける。
ドキュメントの旅は終わらない。作った後こそ本当のスタート。
いやー本当にこれは首がもげそうな感じの内容だなという気がしますね。
社内向けのドキュメントと社外向けのドキュメントって多分あると思うんですけど、
いずれにしてもこの分野こそ本当にAIにズカズカ入ってもらいたい分野だなって思うんですよね。
SDKのドキュメントとか開発系のパブリックなドキュメントとか、
更新が本当に面倒くさいじゃないですか。
更新が面倒くさいって思ってしまうのは作成コストがすごい高いからだと思うんですよね。
作成コストを下げてしまえばグッと作りやすくなるのかなと。
更新もしやすくなるのかなという気がしていて、そのためには本当にAIで回していく。
一回生成してみてうまくいかなかったら、その指示の内容を変えてもう一回生成し直してみて、
っていうのを何度も何度も繰り返していく。
一回うまくいくパターンがある程度発見できれば、
次また更新が走った時に同じことで生成し直せると思うんですよね。
そのGitとかで管理しておけば、その差分を見た上で何が変更されたのかっていうのを、
別でチェンジログとしてきちんと残していくようにすれば、
それぞれの日付ごとにどういう機能の追加があったのかとか、
どこに影響してくるのかみたいなものがドキュメントとして残し続けられると思うので、
テストとかと同じですよね。
SIRとかで、私やったことないですけどよく聞く、スクリーンショットをExcelに貼る作業みたいな。
ああいう作業とかはどんどんなくしていったほうがいいと思うんですよね。
ドキュメントも自動で作れるようになっていけば、
開発のほうにフォーカスするだけで済みますし、
SDKとかAPIとかをちゃんと適切に開発して、
TypeScriptなりPythonなりでちゃんと型の定義とかもしながら作っていくことによって、
きちんと決められた内容で作っていけるんじゃないかなって思うんですよね。
もう本当に嫌だ。
本当にドキュメントは一度作るのはいいけど更新するのがあまり好きではないので、
ここは改善されてほしいなって思いますね。
イベント参加の基準
ではですね、今日のメインテーマのほうに入っていきたいと思います。
今日のメインテーマは参加するまたはしないイベントというところですね。
まず最初はですね、DevRelNameジャーニーマンさんからですね。
いつもありがとうございます。
参加するしないの基準としては、シンプルにテーマにピンとくるかが基準です。
最近は地域、AI、AWSが気になるテーマです。
大きめのカンファレンスはオンラインがあっても交流したいのでオフライン優先です。
また遠征が伴う場合は月に2回が限度なので、その制限でなくなく参加を見送るケースもあります。
最近は西から来た馬面の男さんとオフラインでお会いするケースが減った気がします。
そうなんですね。採用を担当されているのでテーマが違うのかなと思います。
皆さんのお便り楽しみですということですね。
こういう自分なりのテーマ性を決めておくのは大事ですよね。
それが検索に引っかかる場合もありますし、もしかしたら引っかからない場合もあるかもしれないですけど、
AWSとAIだったら二大巨頭みたいなテーマかなという気がするので、
地域は言い方を変える場合もあったりするかなという気がするので、検索パターンはいくつかあるような気はしますけど、
それ以外はAI、AWS、むしろ多すぎて泣くみたいな感じですよね。
テーマにピンとくるかどうかというところでいくと、やっぱりタイトルなんですかね。
タイトルがん?って思うかどうかで、そこで引っかかるみたいな感じなんですかね。
大きめのカンファレンスは交流したいのでオフライン優先ということなんで、
イベント自体はオンラインでも全然気にしないというところなんですかね。
結構ね、オンラインのイベントに何を期待するかっていうのは個人的にまだあまりピンときてないんですよね。
情報収集っていうところはそれなりに大事なのはわかってはいるんですけど、
単純な情報収集だけだったら調べれば済むっていうケースの方がわりと個人的には多くなっちゃってるので、
イベントならではオンラインイベントじゃないと得られないみたいな、
そういう体験が個人的にそんな多くない気がするんですよね。難しいですね。
ではですね、続いてデブレルネーム西から来た馬面の男さんですね。
先ほどお会いすることが少なくなっているということなんですけれども、
今週のテーマは参加するしないイベントということでお便りします。
参加するイベントは自分の課題感や学びたいテーマに沿ったものであることです。
いろんな領域を幅広く知りたいので多様なイベントに足を運びます。
技術コミュニティが主催していると安心して参加できますね。
リアルイベントの場合は加えて交流タイムがあればベストですね。
登壇者の方と話したい場合も参加を検討します。
やっぱ登壇者ですよね。登壇者大事ですよね。
参加を見合わせるイベントは個人情報をやたら細かく聞いてくるイベントですかね。
参加登録時に記入項目が多いと敬遠したくなります。
これわかる。コンパスとかでもありますよね。やたら入れるやつ。
会社の住所や電話番号、従業員規模、当初職種、会社のメールアドレス、意思必須など。
後日忘れた頃に電話も結構かかってきて大変です。製品紹介させてくださいとか打ち合わせを求められたり、
ビジネス職があるイベントだと仕方ないのですが、リード獲得も大変なお仕事なのでわかるんですけどね。
あとセッションのタイムテーブルをきっちり選ばないといけないイベントも入力がしんどいですね。
途中でヤンピしちゃうかもということでつらつら書きました。今週は以上です。
ということですね。セッションテーブル選ぶ系は割と参加者数が多い場合ですよね。
途中でやめれればまだいいかなって個人的には思いますね。
それの選ばれているセッションの違いとかで最終的な部屋の大きさとか決める場合もあったりするかなという気がするので
そういった時にはタイムテーブルを選ぶ機能もそれなりに必要なのかなという気はしますね。
ビジネス職のあるイベントだと仕方がないんですけど最近AI系とかでもこの系統のやつが増えてる気がちょっとふつふつとするんですよね。
所詮AIって別に技術用語っていうわけではなくいろんな意味にとれる一般用語ではあるので
参加者の体験
そういった時にはビジネス系の入り込むビジネス職の強いイベントっていうのもあってもしょうがないのかなっていう気はするんですけど
技術の革をかぶったビジネス職のあるイベントみたいなのも最近増えてきているような気がしていて
参加登録時に見えてくるものは確かにありますよね。ここまではっきりしてくれるといいんですけどね。
記入項目がやたらと多いみたいなね。
ここまではっきりやってくれると逆に電話かかってくるかなみたいな気はするんですけど
そこを中途半端なスタンスでやってるイベントとかは一番最後のアンケートで入れさせるみたいなスタイルとかで
オンラインでやってると入力ウザみたいな感じになってすぐ閉じちゃうみたいな場合もあるかなっていう気はしてますね。
じゅんさんからコメントきてますね。
東京のオンラインイベントを実況しまくっているとそこの参加者がたまたま東京のイベントに行ったときに探し出して挨拶してくれたりとかはありますね。
あるある。別に東京のイベントっていうわけじゃないんですけど
この間とあるイベント行ってそこでLTしたら帰りがけに声かけられて
私別のイベントのときにこのイベントで登壇したものですって言われて
オンラインのイベントで登壇依頼したので
そのイベント自体は顔出しもしないで登壇できる感じのものだったんで
全然不一致ですよね。不一致っていうかマッチしてなくて
その人だっていう風にわからなくてああそうなんですかみたいな感じだったんですけど
時々ねそういうオンラインでのつながりの人
しかも登壇してもらったりとかした人とね
バッタリで食わすみたいなことはありますよね
東京のオンラインイベントってなんですか
オンラインイベントの特徴
東京のオンラインイベントって別にオンラインだからどこでもいいじゃんっていう気はするんですけど
やっぱなんか違うんですかね
地方のオンラインイベントって言われても私とかには全然違いがわからないような気がするんですけど
オンラインってどうしても情報収集系に偏りがちな気はしますよね
なのであんま交流を重視していない感じは
あとはそうですね
この西から来たマズラの男さん
逆に参加するイベントは自分の課題感や学びたいテーマに沿ったものということですね
そうですね個人的にはなんだろうな
自分の課題感よりは自分のクライアントとかの技術トピックに合わせて参加することの方が最近は多いかな
そうですね自分マターじゃなくなってるっていうのはちょっと寂しくもあるような気はするんですけど
どうしても体が一つしかないっていうところで
自分の趣味よりは求めに応じていってるっていう感じかな最近は
逆にこのリアルイベントの時に交流タイムがないやつってあるんですかね
リアルイベントでやる意味がないような気がするんですけどね
続いてですね
デブレルネームさっぽろのじゅんさんですね
いつもありがとうございます
初回については内容に興味が湧いたらとりあえず好き嫌い考えずに何でも参加したり巻き込まれてみるようにしています
2回目以降について明確に参加しない基準を持っており
運営側しか得しない構造になっているコミュニティイベントについてはトピックに興味が残っていてもいかないようにしています
これはすごい明確ですね
運営しか得しないというのは主にアウトプットの禁止などを参加者にかけたりして
何が起こったか外からわからないようにして
運営側は開催実績だけを得て他へのアピールに使うみたいなのが典型的です
こわ!なんだこれ!こわ!
言い分としては心理的安全性のような切り口で語られることもあるのでしょうが
盗難者たちの労力にリターンが見合わないと考えられるので
そういうのは会社などの枠組みでやった方がいいと思っています
有志でそのスタイルが続くようであれば
よっぽど扱うトピックが魅力的な場合に限られるかなと考えています
ということですね
これちょっと内容違うと思うんですけど
私スラックとかディスコードはそんな好きじゃないんですよね
それも心理的安全性っていう意味で言えば
確かにスラックとかディスコードに入って
ある意味Googleにインデックス化されない環境で
しゃべれる 会話ができるっていう
そういう安全性はあるかなと思うんですけど
とにかく閉鎖的になりがちだと思うんですよね
やっぱり技術コミュニティとかは発見されること
新しい人に発見されてまたその人が興味を持って入ってくれるとか
そこのオープンな場所で会話し続けることで
知見が溜まっていくっていうところも大事なのかなと思っているので
この運営側しか得しない構造っていうのはすごくダメダメな気はするんですけど
運営者と参加者の関係
その参加者しか 運営側と参加者しか
あとは登壇者しか得しないっていうのも
それもそれであまり良くないのかなっていう気はしてるんですよね
登壇者は少なくともスライドを外部公開することによって
さらに見てもらえるとかいうところも必要だと思いますし
できればアーカイブを残すとかソーシャル発信することによって
発見してもらいやすくするみたいな
そういう努力はやっぱ必要なものなのかなっていう気はしてますね
先ほどの東京のオンラインイベントの件かな これは
地方は現地開催イベントに降り始めて オンライン参加できないことが増えてきたかもと
そうなんですね そりゃそうですよね
オンライン開催するメリット 地方だとないですよね 別にね
やっぱそのコミュニケーションとか大事ですよね
なのでこれは全然あり得るのかなと思ってますね
もう一つ 順さんからですね
運営者総取り構造の過激派アンチです
いやいやこれは当然でしょう
運営者が得する仕組みになっているのは よろしくはないと思いますね
でもそうですね 難しいですよね
例えばJawsUGとかそういう AWS系のコミュニティありますけど
そこの運営者 運営で積極的に関わったりとか 積極的に発信してくれる方って
ベンダー系のSI クラウドSIの方とかもたくさんいて
そういうのってビジネスメリットがあるからこその発信だったりとか
運営への協力みたいなところもあったりするので
総取りではないですよね 運営総取りではないですけど
そういう何でしょうね 完全に純粋化って言われると微妙なところはある気はしますし
それはテックコミュニティだけじゃなく 一般的な地域のコミュニティとかにしても
そこのコミュニティの運営というか 管理に回る方っていうのは
どっかで利を得ている人もいるのかなという気はするので
なかなか難しい問題ですけど 運営者総取りはよろしくないなとなってですね
はい ということでですね 最後イベントのご案内で
10月の2日から4日ですね デブレル会議をやります カンファレンスです
今 CFP は絶賛オープンしているところで
なんかね 2人ぐらいからなんかね プロポーザル送れないんだけどっていう連絡が来たんですよね
今チェックする余裕がなくて チェックできてないんですけど
早々に確認はしたいなと思うんですけど
ぜひぜひ皆さんプロポーザル 今月末までとなっておりますんで
送っていただければと思っております
ということでですね 今日のデブレルラジオ207回目参加する市内イベントについては
こちらで終了していこうと思います また皆さん来週ですね
来週どうなんだろうな 私来週ちょっとね 国外にいる可能性があるんですよね
もしかしたらアーカイブになるかもしれません
時間確認してですね やっていきたいと思います
ではまた皆さん来週お会いしましょう さよなら
