00:07
はい、皆さんお疲れ様です。5時半になりましたので、DevRel Radioのですね、今日は61回目ですね。やっていきたいと思います。
ではですね、まず最初にこのDevRel Radioの紹介なんですけれども、DevRel Meetup in Tokyoというコミュニティで運営しているネットラジオになります。
今61回目ですね。先週5月の3日か、そこが60回目で粛々とやっているネットラジオなんですけれども、
このDevRel Meetup in Tokyoはですね、2015年の9月から始まったコミュニティで、ちょうど明日ですね、イベントがありますと。
明日か、74回目ですね、のイベントがあったりしますと。
Developer Relationsっていう自社とか自社製品と、あと外部の開発者とですね、いかにいいコミュニケーションをしていくかみたいな、そこにフォーカスしているDevRelという活動があるんですけれども、それをテーマにしたコミュニティとなっております。
もしですね、DevRelに興味があればですね、公式サイトがDevRel.Tokyoというサイトがありまして、そちらからスラックに参加することもできますので、もしご興味があればぜひご参加ください。
他にもですね、TwitterアカウントがハットマークDevRelTokyoですね。ハッシュタグはシャープDevRelJPと、FacebookもDevRelTokyoでやっておりますので、ぜひフォローなりいただけると嬉しいです。
今日のメインテーマがですね、私のこだわりとしております。皆さんがですね、DevRel活動をやる上で大事にしていることであったりとか、ここを注意しているとかですね、自分なりのこだわりを持って活動されている方も多いかなと思いますので、そのあたりをぜひコメントいただければと思います。
今、ソーシャルのほうにもお送りしましたので、今のうちにですね、ぜひ投稿いただければ嬉しいです。
そんなこんなでですね、ゴールデンウィーク明け一発目というところでですね、結構仕事が立て込んでる人多いんじゃないかなと思うんですよね。
03:07
私もゴールデンウィークはですね、自分の趣味の開発とか、趣味じゃないな、仕事半分、趣味半分みたいな開発とかしててですね。
それはそれで楽しかったんですけど、それをやっていたら本当にやらなきゃいけないことっていうのがですね、いくつかちょっと停滞していたようでですね。
このゴールデンウィーク明け、昨日、今日とすごいバタバタしていてですね、結構しんどいなっていう感じですね。
そんなのもですね、多分今週ぐらいでさっさと肩をつけてですね、次のことやっていかなきゃいけないので、さっさと仕事は片付けようと。
ゴールデンウィークちょっと遊びすぎた感がありますね。それじゃあよくないなと思っているところです。
そんなところでですね、ゴールデンウィークはですね、アドベントカレンダーをやっていたんですよね。
ちょうど日曜日までか、9日までだったと思うんですけれども、無事全部完走できたんですよね。
とても素晴らしいなと、皆さんの発信欲のおかげだなと思うんですけれども、それを取り上げたいんですが、
ゴールデンウィークアドベントカレンダーのDevRel Meetup in Tokyoで、この間はですね、札幌のじゅんさんの書籍、遠くへ行きたければみんなで行けっていうやつで、
私も読み始めて3割ぐらい読んだんだったかな。なかなか面白い本ですね。皆さんにもお勧めですと。
そこからなので、船木さんのサークルCIで2年ぶりのオフラインミートアップを開催したと。
それの裏側という話ですね。こちらもソーシャルに投稿しておきます。
こちらはですね、まずサークルCIで2年ぶりのオフラインミートアップを開催したというところで、
開催したのが4月の21日に開催したと。人数は40人までで、ビールは通常通常通り提供と。
06:05
プラスソフトドリンクなど、ボトルや缶など個人にお渡しできるものをサークルCIで用意したと。
フードは無しというところでやられたそうですね。
この着席しながらお弁当だったらいいんじゃないっていうのもですね、デブレルミートアップでも考えたりはするんですけれども、
なんかそれだと味気ないしなと思ってやめたりはしてるんですよね。
場所がWeWorkの渋谷スクランブルスクエアということで、ビールはWeWorkで提供されてるものだと思いますね。
はじめはフードを提供する予定だったのが、3月30日に食事提供負荷が明らかになったと。
さらにお菓子を配ってはダメかと交渉したんだけど、それもダメということで、食べ物は無しということになったということですね。
食事の準備が必要なくなったので、用意したのはスワグと飲み物ということですね。
今回はスワグでTシャツを用意したと。
このTシャツは結構なんか生地良さそうですね。
結果的にイベントが40人いっぱいだったのかな。
イベントのURLがないな。
32人でLT枠が2人来てくれているというところで、結構十分な人数かなという気はしますね。
ツイートもあってですね。
オフラインの勉強会、あらゆるすべてに懐かしさを感じるとか、まさにっていう感じですよね。
皆さんツイートもちゃんとしてくれていて、ありがたい限りですよね。
そちらがですね、ふなきさんのサークルCIで2年ぶりのオフラインミートアップ開催の裏側という記事になっております。
続いて5月の4日ですね。
5月の4日が職業、徳良彩さんからですね。
09:00
マネージャーに任命され300日やってみた感想。
カスタマーサクセス部長の日記というノートの記事があります。
ありがとうございます。
7月の1日でカスタマーサクセスのマネージャーに着任して約300日経ちましたと。
うまくいったこととして、マネージャーのオンボーディング、周りのサポートやフィードバックを受け入れると。
あと時間の使い方が変わったということも書かれてますね。
やってよかったこととしては、メンバーの成長を実感できて、組織を変えることに関与できると。
あと3つ目が、周りからより多くの信頼やサポートを得ながらDevRelを推進できるということを挙げられてますね。
こちらもソーシャルのほうに上げておきます。
逆に難しいと感じたことで、メンバーに任せる勇気が必要でしたとか。
アドバイスを伝えたつもりでも、メンバーにとっては業務命令に受け止められてしまうケースもあったとかですね。
結果的に想像以上にやりがいのある仕事だったというふうに書かれているので、ますますの発展を期待したいですね。
続いてが、5月の5日ですね。
こちらは西から来た馬面の男さんの私の好きなDevRelラジオと。
いや、まさに今やっているこれですね。ありがとうございます。
DevRelラジオは、私とDevRel仲間がパーソナリティとなり、
DevRelにまつわるニュースをネタに小気味いい投稿を繰り広げられていますと書かれてますね。
ありがとうございます。
事前に提示されたテーマについて投稿すると取り上げてもらえることがあります。
インプットの場だけではなく、ちょっとしたアウトプットの場としても活用させてもらっています。
確かにそうですね。
自分のコメントを読み上げてもらえると嬉しいものですと。
パーソナリティの方々に確かにそうですねとか、こういう考え方もあるんですねと共感してもらえたり、
コメントをもらえる体験は大変ありがたいと思っていますと。
DevRelラジオのコンテンツに関わることができた満足感もありますというふうにいただいてますね。
ありがとうございます。
そこまで深く考えてやっているという感じではないんで、
12:04
ちょっと申し訳ないなという面もあったりするんですけれども、
そういうふうに捉えていただけるとですね、こちらとしてもありがたいなというところですね。
ではですね、続いてが5月の6日ですね。
一番最初のサークルCIでご紹介もしたふなきさんの記事ですね。
ボイスピークを使ってサークルCIのチュートリアルビデオを作成してみたという記事ですね。
このボイスピークはですね、私も購入はしていながら、
これゴールデンウィークに試そうって先週言ってたのに結局やってないんだよな。
やらなきゃいけないよなって思っているんですけど、購入はしてあるんですよね。
いわゆるテキスト読み上げなんですけど、AIを使っていて結構質がいいという話ですね。
それを使って実際にチュートリアルビデオを2本作ってみたということで、
一つ目がサークルCIを使ったMacOS上でのビルドテスト、実行ファイルの生成と、
もう一つがサークルCIでヨロバージョン5を使ったマスク検出、
クラウドとローカルのGPU活用というところですね。
動画を作られたということですね。
やっぱり技術用語は弱い部分があるので、
辞書登録が必ず必要ということですね。
さらに辞書登録しても反映されないケースがあるということもありますね。
あとこれ痛いですね。辞書登録内容のエキスポートインポートができないと。
これちょっと辛いですね。チームでやる場合は辛いなと思うんですけど、
逆に言うとあれですかね。チームを想定していないとかということですかね。
登録した単語としてはサークルCIはもちろんのこと、
MacOSとかGitHubとかForkとか、あとはXcodeとか、結構ありますね。
Siliconとか、その辺りもいろいろ登録していかないと聞きやすいテキスト音声にはならなかったということですかね。
でも動画見てみたんですけど、普通に聞けるので、悪くないなっていう気がしました。
私もちょっとボイスピーク使って、まず使い方を覚えるところからやっていこうと思います。
15:05
皆さんもぜひ使ってみてください。いわゆる棒読みちゃんとかよりは全然いいと思いますね。
続いてが5月の7日ですね。5月7日は大地さんですね。
DevRel関連職の所属部門についての考察ということですね。
これは前の記事が確か転職に関するところで、今回は所属に関するところというところですね。
その中ですね、DevRel関連職を一旦定義するというところで、
テクノロジーエヴァンジリスト、テクニカルエヴァンジリスト、
あとはデベロッパーアドボケイト、テクニカルコンテンツクリエイター、ライター、
ウェブサイトの編集長、コミュニティーマネージャー、あとはプログラムマネージャーですね。
それが挙がっております。
それの想定し得る所属部門としてですね、まず一番最初は営業部門がありますね。
これはなかなかな感じですね。
続いてマーケティング部門と、
マーケティング部門に所属するケースはかなり多いのかなという気もしますね。
あとR&D部門、これは人数が少ない場合、結構多いケースかなと思いますね。
そういう研究開発とかしながらですね、結構自由に動ける人がいる場合とかは、
R&D部門の一環としてやるということはあったりしますね。
あとはコーポレート部門と、バックオフィス系ですね。
その中も割といるかな。
これも結局人数が少ない場合という印象はありますかね。
広報だとまたちょっと違うかなという気はしますね。
それぞれに対してですね、メリット・デメリットというところを挙げてくれていますね。
そうですね、どこが一番いいかって言われると、
個人的にマーケティング部門が一番動きやすいのかなという気はしますかね。
ただ予算配分がどうしてもマーケティング部門だと広告とかの予算と
かにばっちゃうところがあったりするので、
もうちょっと予算の取りやすいところが良かったりはしますかね。
そして5月の9日、こちら最後ですね。
こちらがゆうすけさん、スライディクトというサービス。
これはマークダウンを書いて、
ウェブのスライドに転換するサービスですね。
18:01
そちらを作られている方なんですけれども、
初めて参加してくれたんですよね。
それに参加したのが72回目、3月ですね。
今年の3月のときのプレゼンテーション会に参加してくれたと。
素晴らしいですね。
こうやって初めて参加してくださる方がですね、
アドベントカレンダーまで書いてくれるというのは、
本当嬉しい限りですね。
そして、ゆうすけさん自身は、
40歳の節目で書こうと思いましたというところで、
さらにITエンジニアとして17年ほどキャリアを積んでいるということですね。
デブレルで調べたときに一番良かったのが、
エンジニアのためのデブレル入門。
外部の開発者と信頼関係を結んで、
コミュニティでファンを増やすと。
これはエンジニアハブっていう、
NJAPANさんがやっているオウンドメディアですね。
そちらでたいじさんがインタビューに答えたときの記事だと思いますね。
それを読んでもらって、
プレゼンテーションに興味があったというところで、
参加してくれたと。
毎回ですね、デブレルミートアップはいろいろテーマを変えながらやっていたりするので、
そのテーマが引っかかったときにですね、
来てくれれば一番良いと思いますし、
そこがきっかけでですね、
デブレル自体に興味を持ってくれれば、
継続的に参加しやすくなるかなと思うので、
今後もぜひ興味があるテーマがあったら、
参加していただけると嬉しいですね。
スライディクトを作られているということなんで、
LTのようにスライドを作れるスライディクトは相性が良さそうですというふうにも書かれてますね。
個人開発しているエンジニアやシード機能エンジニアは、
デブレルミートアップin東京へ参加して、
デブレルな人たちと意見交換するのも楽しいかもしれませんと書いてくださっています。
ありがとうございます。
これでゴールデンウィークアドベントカレンダーは全部ご紹介したかな。
全部で1,2,10日ですね。
もう最悪空いたらですね、私が埋めればいいやって思ってたんですけど、
幸いにして私初日しか書かずに済んだと。
21:00
たいじさんとふなきさんが2つずつ書いてくださってますけれども、
結構皆さんいろいろ書いてくださったというところでありがたい限りですね。
こうやって自分がアウトプットしなくても進んでいくようになると本当に嬉しいですね。
そんなところでですね、続いてはデブレルのキーンですね。
キーンっていうのはGoogleがやっているキュレーションサービスなんですけど、
そこでデブレルに関係するとおぼしき記事をまとめているんですよね。
ここのサイトがですね、SEOにめちゃくちゃ弱いんですよね。
いくらおぼしき記事を書いても、
デブレルスペースキーンとかで探しても全然検索結果が出ないみたいな感じで、
結局毎回ブックマークから飛ぶっていう、何のためのキュレーションなんだろうっていうのがですね、
よくわからないなって思うんですけど、
そんなデブレルキーンっていうのをやっているので、
もしよければですね、フォローできる仕組みもあったりしますので、
ぜひご覧いただければと。
コメントでデブレルミートアップ、デブレル肉大盛りって書いてる。
これなかなかいいですね。なかなかうまい。
確かにミートが、
お肉のミートになってますね。これ面白いですね。
まあそれはいいや。
デブレルキーンなんですけれども、何がいいかな。
先月、今月ぐらい障害系がいろいろ多かったんですけど、
デブレルキーンっていうのは、
先月、今月ぐらい障害系がいろいろ多かったみたいで、
これをまとめてご紹介になるんですけど、
一個がアトラシアンですね。
アトラシアンのサービスとしてはコンフルエントでしたっけね。
こちらなのかな。
結構これ長く復旧までに時間かかったっていうふうに認識しているんですけれども、
そちらの結構詳細なレポートが上がっておりますと、
結構こういうインシデントが発生したときのレポートとして、
参考になる部分あるんじゃないかなと思いますね。
何だろうなぜかツイートが開かなくなった。
24:06
これは結構そういうインシデントが発生したときの対応策として、
一回見ておくのがいいかなと思います。
もう一個はヘロクも障害発生したらしくて、
それのフィードバックをくれみたいな記事もあったりしますね。
これは障害に関してはあんまり細かくは書いていないんですけれども、
GitHub連携したところで障害が発生したようですと。
一旦そのGitHub連携を止めて、セキュリティとかを見直した上で、
また復活するよというのが書かれてますね。
最後三つ目がオラクルクラウドですね。
こちらは全然ちょっと状況がよく分からないんですけれども、
オラクルクラウドのアカウントが突然バンされたと。
アカウントが一時停止になったということで、
それがずっと時系列並んでその対応とかが書いてあるんですけれども、
最新のところで請求に対する支払いは問題なく完了していたって書いてあるのに、
それなのにアカウントを停止されて、
さらにリソースが削除済みみたいな感じで書かれてるのが、
結構残酷だなっていう気がするんですよね。
こういうケースはなかなか効かないなという気がするんで、
これ障害とは言わないですけれども、
この当事者にとっては障害もいいところかなと思うので、
どうなんでしょうね。
どういう決着を見るのかがすごい気になるところですね。
この対応とかをミスると、いろいろ信頼関係を損なったりとか、
この様子を見ている人が、そもそも使わないようにしようって思っちゃったりする可能性があるので、
きちんと適切に対応していくことが求められるんじゃないかなと思いますね。
そんなのがOracle CloudとHerokuとAtlassianのサービスっていうところで書かれていました。
続いてなんですけれども、これもなかなか個人的に面白いかなと思うんですけど、
27:03
ニュースピックスからですね。
どうなんでしょう。
ニュースピックスっておっさんがキラキラしているサービスだというふうに思っているんですけれども、
私はキラキラしていないので、全然このニュースピックスって見たことがほぼほぼないんですけど、
この記事、このネタですね。
採用のために技術ブログを書くわけじゃないという記事ですね。
はてぶかなんかで結構取り上げられていたので、ご紹介しようかなと思っております。
結構エンジニアリングブログを書くというのが流行りとは言わないですけれども、
結構最近は増えているのかなと思います。
ただ認知のために書いているわけではなくて、
ただ認知だけが言いたいんだったら広告を打った方がパフォーマンスがいいよねということを書かれていて、
そうではなくインプットしたものをアウトプットすること、
解きたい問題について考えた記録であれば、
その会社の知的な活動の記録が漏れ出てきて、
社内の様子や開発者の文化資本が自然と発露するはずですと、
その情報がたまたま内定を出した人のクロージングに役立ったり、
エンジニアの中でのブランド力やコミュニティの中でのポジショニングに役に立つのですというふうに書かれてますね。
このあたりは多分明日のイベントのアウトプットテーマなんですけれども、
そのあたりでもこのあたりの話ちょっと出そうな気がしますね。
どうやったらエンジニアリングブログが活性化する文化を作れるのか、
これもすごい興味ありますよね。
多分ここで悩まれている会社さんはすごい多いと思うので、
それはまずはSNSで見つけたかっこいい記事のイメージを忘れてくださいと、
そういうのを書くのが目的ではありませんと。
聞いたチームでもコンフルエンスでもいいので、
まずはインプットしたことをアウトプットする習慣をつけるところから始めましょうと。
最初からオープンに前夜聞いたでも結構ですと。
最初に書いてみるのは読んだ本やブログの感想やまとめでもいいですと。
自分のために書くので誰も読まなくてもいいですと。
次に問題に出くわしたときに調べた過程や勘違いしていたこと、
調べた内容、結果をまとめてみましょうと。
さらに疑問を持って解決まで調べてみましょうと。
例えばゴーランでスライスに対するアペンドの挙動ってどうなっているんだろうとか、
ドッカーコンテナってなぜ環境分離できるんだろうとか、
なぜ起動が早いんだろうとかそういうものでもいいですと。
30:03
その疑問を実際に試して記録に残してみましょうと。
そういうのでいいんです。
それに慣れてくるとブログに書きたいというふうになると。
インプットのサイクルが回るようになったからですと。
アウトプットをするとフィードバックがもらえるようになると。
一見でも何かリアクションがあると結構嬉しいはずですというふうに書かれてますね。
これは個人で採用のために書くとかそういうことではなく、
まず自分の小さいアウトプットを繰り返していきましょうということが書いてありますね。
今頃取り上げなんですけど、キザワさんからこんにちはと来てますね。
こんにちは。よろしくお願いします。
これ面白い記事だと思うので、
企業がエンジニアブログを始めるところと、
あとは個人がどうやってアウトプットの習慣を身につけるのかというところが書かれていますので、
ツイートはしたはずですよね。
ぜひ読んでみてください。
まだいけるかな。
続いてはどれがいいかな。
ここら辺は紹介したので、
最近のネタでいくと、
じゃあこれかな。
これはゆうすけ安藤さんのブログ記事で、
プログラミング学習の挫折を防ぐにはという記事になっております。
多分、DevRelに関わる人って、
割とそれなりに技術的な経験を積まれている方が多いのかなというふうに思っていて、
もうすでに何十年もエンジニアをやっている方というのも少なくないかなと。
さっきのユーベルさんですね。
DevRel Meetup in Tokyoに参加してみてという記事を書いてくださった方も、
17年ほどキャリアを積んでいる方という話もあったりするので、
それなりに経験が長い人が、
参加者層とか見ていても、そこそこ年齢は高いのかなというふうに思うんですよね。
そうすると、プログラミング学習とかっていうのは、
とうの昔にやったことで、
なんでプログラミング学習で挫折しちゃうのかっていう経験をもう忘れ去っていたりするんじゃないかなと思うんですよね。
33:04
そういうときに、こういう記事を読むと、
こういう考えがあるんだみたいな感じの、
懐かしい感情とは言わないですね。
昔プログラミングやろうって思っている人と、
今プログラミングやろうって思う人って、
全然スタート地点が違うのかなというふうに思ったりもするので、
今をちゃんと正しく理解しないと、
彼らをうまくサポートすることはできないのかなという気はしますね。
なので、こういう初心者、今の初学者目線の内容っていうのは、
とても役立つところが多いのかなと思いますね。
ただ、これは日本の内容ではなくて、
2015年にダトビア大学の方々が書いた、
コンピュータープログラミング適正検査による中退学生の削減という論文ですね。
そのコンピュータープログラミング適正試験を行うことによって、
中退してしまう人、ドロップアウトしてしまう人を削減したということですね。
もともとは半数近くの学生がコンピュータサイエンスを初年度に中退していたということですね。
なかなか全員に確率的にやらせようと思っても難しいんだろうなっていうのは確かに思いますよね。
日本だと高校だけじゃないか、もうちょっと前でしたっけね。
中学高校ぐらいからプログラミング教育やってますけれども、
とても全員に向くものではないのかなっていうのは確かに思うところはありますかね。
ラトビア大学も大学生ではあるんですけれども、
それでもコンピューティング学部に所属している学生の3分の1から半分の学生が初年度に中退するっていう、
コンピュータ学部に入ったんじゃないのっていう気もしなくもないんですけれども、
入ってみて初めて自分の適性がないことに気づいたとかそういうことなんですかね。
プログラミング適性検査の手法の一つとして心理テスト、MBTIというのが行われていたと。
これはどっちかというと心理テストで、
感覚型の学生は直感型の学生よりもプログラミング課題の成績が優れていましたと。
また判断型の学生は認知型の学生よりもプログラミングの水準が優れていたというのが書かれていますと。
36:05
そしてあとは別の研究ではSQとEQという、SQはシステム化指数と呼ばれシステムの理解関心を測ります。
一方のEQは共感化指数と呼ばれ他者の感情への理解関心を測るというものなんですけれども、
そのEQですね。他者への感情の理解関心が高い方が、逆だ、低い方がプログラミング能力が高いと。
つまりは空気の読めない人はプログラミング能力が高いっていうことですかね。
どうなんだろうと。一応論文ではそういうことになっていますね。
ただ単純に共感化指数が低いだけではないみたいですね。
そのシステムへの理解が高くて、共感能力が低い人はプログラミング課題の成績が優れていたということですね。
そうしたタイプの人は理解できない他人と関わるよりも、理路整然としたシステムと関わることを好む傾向があるということですね。
分からないでもないですよね。今ぐらいになって自分が年を取ると、世の中グレーなことの方が多いっていうのは分かるんですけれども、
20歳そこそこぐらいだと白黒はっきりしている方がいいですよね。
人間関係の煩わしいグレーな関係とか、微妙な距離感とか考えるぐらいだったらプログラミングの方が答えはちゃんと出るからいいなって思ったりしますよね。
どうせバグをもし作るとしても、それは自分のせいという気はしますね。
プログラミングか数学が好きだと、好影響というところなんですね。
最終的にラトビア大学のドロップアウト対策としては、スクラッチを利用したプログラミング体験を挙げてますね。
プログラミングがどのような作業なのか、自分が好きなのかどうかを確認させようとしています。
その意味でスクラッチ、ビジュアルプログラミングが良さそうということですね。
39:05
同様に、性格テストなどの適正試験も出願や履修の前に活用することで、自分自身の性質に合った取り組みを行うように活用されています。
2つ目が、在学生・卒業生と新入生をペアにしたメンタリングプログラムです。
これも面白いですね。
大量の情報と新しい環境に直面する新入生に、経験者の視点でアドバイスをすることで、初年度のドロップアウトを防ぐ試みです。
このメンタリングプログラムに登録した学生は、8割が次年度に進級しましたが、登録しなかった学生は6割しか進級しませんでした。
だから結構メンタリングプログラムが効果的だということですね。
あと3つ目が数学の補修講座の活用です。
高校での数学の学習状況が高くない学生がドロップアウトしているということから、
出願時のスコアに応じて、高校数学の補修講座を学生に義務付けることで、学生のギャップを埋めようとするということが書かれていますね。
このあたりは別に学生に限らず、社会人の教育とかにも役立つ部分が大きいのかなという気がしますね。
日本の場合は文系プログラマーって多いとかって聞くんですけど、
実際どれぐらいいるのかちょっとわからないですし、
今がそういう状況を引きずっているのかどうかというのもわからないんですけれども、
そういった会社に所属してから技術部に行って、そこでプログラミングを覚えるみたいな方も多少なりともいるのかなという気はしますので、
そういった方向けに教育する上で、まずスクラッチでやるのがいいのかというのはちょっとわからないですけれども、
少なくとも素養を見る上で、まず全員にやってもらってスクラッチを楽しんでできるとか、
スクラッチに対して興味を持つかどうかみたいなのをまず見た上で、
技術の部門に進んでもらうかどうかみたいなのを判断するっていうのはいいのかなと思いますね。
ここは人事とかにお願いしたいところですかね。
あとはメンタリングプログラムについて言えば、これは別に技術に限らずっていうところですよね。
先輩後輩といえば、そういうシステムもともとありますかね。
42:01
これは日本企業の場合よくやっていることかなという気もしますね。
あとは数学の補習講座ですね。
これは人によるかなと思うんですけれども、やっぱりプログラミングは数学の知識があるかどうかで結構やりやすさも変わるかなと思うので、
それがちょっと数学の知識が思わしくないという場合は、それをやる講座を作ってもいいのかなという気はしますね。
特に3Dとか使うんだったら行列であったりとか、機械学習とかもやっぱり専門知識が必要ですし、
それのベースになる数学の知識っていうのが必ず入ってくるので、それを基礎から教えていくみたいなのもあってもいいのかなという気はしますね。
本当は即戦力が取れ続けるのが一番いいのかなという気はするんですけどね。
というところでニュース系はそんなところにしたいなと。
今日のメインテーマですね。私のこだわりというところなんですけれども。
5月の3日以降だな。
ここまでは非表示にして。
今日は全部で4件いただいてますね。ありがとうございます。
ではですね。まず一つ目がDevRel Name 札幌のじゅんさんからですね。いつもありがとうございます。
ブログ記事などアウトプットのこだわりとして、最低2分野以上の人が読めるものを必ず作ることを自分に課しています。
面白いですね。
例えばDevRelの文脈に沿った投稿でも、XRの人が読めるように用語を選ぶとか構成を考えるとか例を出すとかを意識的にやっています。
XR文脈でDevRelがサブになることもあります。
別の2分野に向けた作文をすることもあります。
こうしておくことで自分のアウトプットを読んだ人が新たな選択肢を見つけられるようにしています。
また、公開記事が複数分野にまたがっていることを可視化しておくと、
それら複数がわからないと困るプロジェクトが出てきたときに思い出してもらいやすい効果も狙ってはいます。
こちらはまだまだイマイチな状況ではありますというふうにいただいてます。
ありがとうございます。
これなかなか考えてできるもんなんですかね。
あとは何でしょう。
例えばDevRelの円とXRの円があって、それをどのぐらい重ねるかですよね。
45:00
ちょっとしか重なってないところで記事を書くと、
実はどっちの人にも刺さらない記事になってしまう可能性もあるので、
XRの人たちが読んでも、DevRelってこういうもんなんだっていうところを理解してもらえないといけないし、
その逆もしかりっていうところで結構難しいチャレンジなんじゃないかなという気がするんですけどね。
どうなんでしょうね。
すごいですね。
ちょっとその視点で今後、じゅんさんの記事は読むようにしてみたいと思います。
では続いてですね。
続いてがDevRelネーム西から来た馬面の男さんですね。
いつもありがとうございます。
コミュニティでの動きについてですと、
参加者側の立場でコミュニティに関わる上で大切と思うのは、
何らかのアウトプットをすることですと、
一番お手軽なのがツイートにより発信することですと、
コミュニティイベント冒頭の自己紹介タイムも同様かと思いますと、
アウトプットすることにより、
同じ関心軸のメンバーと関わり、
コミュニティを形成することができると思いますと、
逆に主催者側の立場としても、
参加者の積極的なアウトプットは歓迎されると思いますと、
というわけで私のこだわりは、
どんな小さなことでもいいのでアウトプットすることですといただいてます。
ありがとうございます。
本当これ大事ですよね。
アウトプットが少ないと、
何のためにイベントやってるんだろうって思ってしまうときも少なからずあったりしますので、
皆さんのアウトプットありきというところでイベントやっていたりもするので、
こういうふうに自らアウトプットを意識的にやってくださってくれている方っていうのはとても貴重ですね。
これがオンラインになると、
オンラインイベントになったら結構アウトプット量は減衰した感はありますよね。
最初はオンラインもいいよねみたいな感じで楽しんでもらえているっていう感じもしてたんですけれども、
そのときはそれなりにアウトプットも多かったんですけど、
だんだん慣れていっちゃうとアウトプットも減衰するというか、
だれかんというか刺激が減ってしまっているのかなという気はしますね。
その意味オフラインでやると会場を変えたりとか装飾したりとか、
あとは隣に人がいる感とかですかね、そういった感覚もあって、
48:01
刺激がオンラインでただディスプレイを見ているのに比べると刺激が多少なりとも強かったりするんで、
アウトプットを生み出しやすい傾向があるかなという気はしてますね。
では続いてDevRelName、ジャーニーマンさんですね。
ツイートまとめサービスのトギャッターでまとめることです。
これはもうまさにジャーニーマンさんのある意味、お仕事みたいになってますね。
オンラインでもオフラインでもコミュニティに関するログとして、
比較的生の情報をログできるからですと。
今でこそ動画アーカイブが残りますが、
後から自分のペースで読めるコンテンツとして成立するのはとても優秀だと思います。
今後もこだわってまとめていきますと。
あともう一つが、初参加が最高の体験になるように現場運営としてケアすることですと。
初めてのコミュニティイベントで運営の方に気遣っていただけた経験が今につながっているからですと。
今でも感謝していますというふうに来てますね。ありがとうございます。
この二つ目のやつは一番大事ですよね。
初参加が最高の体験にならなかったら、絶対に二度と来てくれないですよね。
個人的に思うのは、内輪感はとにかくなくしたいんですよね。
知っている人にしかわからない文脈でしゃべるとか、
既に見知った人たちがワイワイしゃべって、それ以外の初参加の人たちがポツンとしちゃうみたいな、
そういうのはなるべく避けたいというのはあるんですよね。
運営メンバーであったりとか、既に慣れている人とかは別にスラックでもしゃべれますし、
Twitterでもおしゃべりできると思うので、初参加の人たちにいかに場を楽しんでもらうかとか、
いかにその人たちのことを知ろうとするかみたいな、
そういったところは結構個人的には注意はするようにしてますね。
初参加したときに嫌な思い、嫌な思いって言うとちょっと語弊があるんですけれども、
なんとなくのいずらさみたいなものを感じると、次は多分来ないでしょうし、
私もいくつかコミュニティとか、外部のコミュニティとかに参加して、
なんとなくいずらさを感じるなと思っちゃうと、次行かないかなっていうのはありますかね。
51:06
どうしても最初に参加するときってアウェイなんですよね。
アウェイに参加したときにアウェイのままの気分だと、
いきなりフォームっていうのは難しいと思うんですけれども、
少なくとも最初にそれなりに普通とは言わないですけれども、
そんな悪い気分じゃなかったなと思えれば、次も参加してみようかなと思って、
それを何回か繰り返しているうちに、だんだんフォーム感というか、
自分の知り合いが増えてくるみたいなところがあるかなと思うので、
初参加の、初の人を無理に持ち上げるとかっていうのは、またそれはそれで変かなと思うんで、
少なくとも嫌な気分にさせないとか、次も来たいと思ってもらえるようにするっていうのが、
大事なところかなという気はしてますね。
では続いて、こちらが今日は最後のメッセージかな。
DevRelNameまさひこさんからですね。
ハードルを低くすることでしょうかと。
オンラインイベントは朝昼夜開催してみたり、ビデオに字幕を入れてみたりと。
音声なしでも理解できる。
横文字は耳で聞いてわからなくても目で読めるようにするなどということを書かれてますね。
これも確かに大事ですよね。
こないだプレゼンの壁打ちを頼まれてですね、見たことがあるんですけれども。
横文字短縮文字とかカタカナが多くてですね。
それはこう全部直した方がいいですよっていうふうに言ったんですけれども。
何でしょうね、プレゼンを作るときに格好良く作りたいのか。
洗練された感じにするために業界用語とかを入れてしまう傾向があるかなと思うんですけれども。
それをやるとですね、プレゼンを聞く方っていうのはほぼ皆さんは初級者の方が聞いているわけで。
ベテランの人たちはそんなプレゼン聞く必要はないので。
基本的に聞く人っていうのは初級者であったりまだそこまで熟練じゃない人たちが聞いていると思うんですけれども。
そういったところでやたら激しくわかりづらいキーワードを突っ込んでいくと、
54:03
そのキーワードばっかり気になっちゃってですね。
その後の内容が頭に入ってこないという感じになってしまうかなと思うので。
なるべくここのまさひこさんも書いてますけれども、
横文字は耳で聞いてわからなくても字幕に入れておくことですね。
ケアできるようにしてあげるとかっていうのは大事なところかなと思いますね。
特に横文字を入れた後に字幕でそれの意味を解説しておくとかですね。
そういうのも大事なことかなと思いますね。
オンラインイベントは朝昼夜開催してみたりとかっていうふうに書いてありますけれども、
個人的に朝ちょっとやってみたい気もするんだけどなかなか勇気が出なくて、
ハンズオンは昼と夕方ですね。
その2回やっていたりはしますね。
昔は朝活とかもやろうとしたりしてたし、やってたりもしたんですけれども、
今多分朝イベントやっても、
今でもオンラインか、オンラインで朝どのぐらいの人が来るんだろうな。
勇気を持って繰り返していけばそのうちだんだん定着するのかな。
うまくやったらブルーオーシャンですよね。
今って開発者系のイベントは夜が圧倒的に多いのかなという気はするので、
その中で朝ブランドを1個立てられれば、
そこは結構ブルーオーシャンの可能性があるかなという気はしますね。
朝は運動しに行っちゃうからな。
コメントで木澤さんから、
上手UGの朝会はそこそこ成功していますねと来てますね。
そうなんですね。ちょっと後で。
上手UGの朝会は、上手UGのドアキーパーなのかな。
朝7時でも参加者はいるんですよねというのが船木さんから来てますね。
上手UG朝会。朝7時半からやってますね。
しかもジャーニーマンさんもフォローブックマークとかしてますね。
57:04
上手UG朝会34回、35回。
毎月1回やるやつがもう9月まで入ってますね。
すごいな。でも100人超えですね。
何をやっているんだろう。
朝で、夜開催されている勉強会に参加できない方向けに上手UG朝会を開催しますと。
朝ごはんをもぐもぐしながら参加でもOKですと。
なぜか7時35分から7時40分にラジオ体操が入ってますね。
すごいな。
7時40分から8時で20分のセッション1つ。
そのあともう1つセッションがあり。
LTがあり。
8時40分から9時までが雑談タイムという形になってますね。
面白いな。やってみようかな。
誰かやりたい人がいたら、DevRelで朝会やりたい人がいたらぜひ言ってくれればですね。
私は応援します。
私も運営やれって言われたら喜んでやらせていただきますっていうところですね。
高見智恵さんからですね。
8時から10時でやっていると。
2時間か。2時間ちょっと長いかな。
上手UGの朝会が7時半から9時までっていうところで1時間半、90分ですよね。
オンラインだと特に2時間だとちょっと長い気はするので1時間半。
1時間とか1時間半にまとめられるといいなという気はしますかね。
結構あるんですね。
では最後にイベントのご案内でDevRel Meetupの先ほどもお話になったんですけれども、
明日イベントがありますと。
テーマはOutputっていうテーマですね。
やりますのでまだオフライン会場の方も人は空いてますね。
もしオフラインで久々にお話ししたいという方がいらっしゃったらですね。
そちらご参加くださいというところですね。
まだまだオンラインの方は人数無制限で募集しておりますので、
ぜひご参加いただければと思います。
1:00:02
ではですね。そんなところで今日のDevRelラジオは終了としていきます。
引き続き皆さんお仕事頑張ってください。さよなら。
