00:08
5時半になりました。皆さんお疲れ様です。DevRel Radioの、今日が57回目ですね。お届けしていきたいと思います。
今日はですね、多分イベントページの方に書いてあると思うんですけれども、もしかしたら録画配信になりますと書いてあったと思うんですけれども、
反応上ですね、予告通り録画配信になっております。
なのでですね、今日のメインテーマがですね、仕事中のBGMとなっているんですけれども、
今のうちに来ていると思ったんですが、今日は来てないですね。
はい、すいません。多分ですね、もしかしたらこの後ですね、送ってくれている方がいらっしゃるかもしれないんですけれども、
そちらは取り上げることができませんというところでご容赦ください。
ということで、今日はメインテーマはなくてですね、これ来週に持ち越そうかな。
ぜひぜひですね、今のうちに送っておいていただけると、来週それを取り上げようと思います。
ということで、今日のメインテーマは消えたということですね。
今日はDevRel系のニュースとかをですね、ぼちぼち取り上げながらやっていこうかなと思います。
まずですね、このDevRelラジオに関してなんですけれども、DevRel Meetup in Tokyoがお送りしているネットラジオになります。
毎週火曜日の夕方5時半からですね、やっているんですけれども、このDevRelっていうのはですね、
Developer Relationsの略で、自社とか自社製品と外部の開発者との良好な関係性を築くという、
それを目的にしたですね、マーケティング活動になりますと。
DevRel Meetup in Tokyoはですね、それに基づいて、例えばエヴァンジェリストとかアドボケイトとか、
あとコミュニティマネージャーとか、あとマーケターの人とかですね、
そういった諸々の方々が集まってDevRelに関する知見を共有し合うコミュニティになっています。
普段のイベントはですね、毎月第一水曜日にやっていたりするんですけれども、
そちらはですね、後ほど最新のイベントに関してですね、共有はさせていただきますと。
あとはですね、Twitterアカウントがあります。
Twitterアカウントは、アットマークDevRelTokyoですね。
ハッシュタグがシャープDevRelJPとなっていますので、ぜひツイートいただけると嬉しいですと。
03:07
あとはFacebookもやってまして、同じですね、Facebook.comのDevRelTokyoとなっていて、
最近YouTubeが名前変わったんですよね、確かね。
やってる途中で変えたような気がするんだよな、東京。
違うな。でも、Youは違うんだな。びっくりした。
全然関係ないアカウントが表示されたので、
名前が使われたのかと思ってしまったんですけれども、そうじゃないですね。
これを見て、これを押すと。
あれ?チャンネル名全然変わってないな。おかしいな。
あれ、なんかこないだ変えたような気がしてたんですけど、あれは夢だったのかな。
チャンネルをカスタマイズを押して、基本情報の。
これはパッと見では出ないのかもしれない。
でもアクセスはできますね。
youtube.com//DevRelMeetupで見ることができますと。
どうなんだろう。統一されてる。DevRelTokyoじゃんね。
この名前はダメですね。DevRelTokyoですね。
削除すればいいのかな。
削除。カスタムURL。
カスタムURLを公開するユーザー。
これ削っちゃっていいのかな。
大丈夫ですね。カスタムURLは削っちゃいます。
これをカスタムURLをまた設定できると。
DevRelTokyoですね。
変更できなくなっている。
なんてこった。
もしかしたらこれはチャンネル名と連動しちゃってるのかな。
辛いな。しょうがないですね。
06:02
youtube.com//DevRelMeetupという名前になります。
Twitterアカウントとかと統一されてないのは悲しいところではあるんですけれども、しょうがないですね。
そんなYouTubeチャンネルもありますので、ぜひ購読いただければと思います。
あとはスラックがやってますね。
スラックは公式サイトのDevRel.Tokyoのサイトから入ることできますので、ぜひジョインしてみてくださいというところです。
今日はそういったところで、以前のアンケートがないので、
DevRel周りのニュースを紹介していくというところでやっていきたいんですけれども、
まずDevRelキーンっていうですね、Googleがやってるキュレーションサービスがあるんですけれども、
そちらにですね、DevRelのキュレーションをいろいろ集めてるんですね。
そこからちょっとお届けしていこうかなと思うんですけれども、
まずはですね、これはDeveloperRelations.comのニュースレターで知った記事なんですけれども、
あれ、これもしかして結構この記事古いのかな。
ちょっと記事の新しさとかわからないんですが、
Your slides are not your talkというところで、
あなたのスライドはトークじゃないよというところで語られている記事ですね。
これは誰しもが思い当たるところあるんじゃないかなと思うんですけれども、
いわゆる説明の過剰書きとかですね、
スライドの中についついコンテンツをてんこ盛りにしちゃうってやつですね。
これはこの間だから、先月2月だったかな。違うかな。3月か。
3月のときのDevRel Meetupでですね、プレゼンテーションをテーマにしたと思うんですけれども、
1段上のプレゼンテーションを目指してっていうテーマでですね、
その中の1人の山崎渡さんもこれを散々言ってましたね。
資料に書いてあることを読むんだったら、あなたが話す意味がないというところだと思うんですよね。
おそらくスライドの考え方がもうそもそも根本的に違くて、
ビジネスのちょっと眠気を誘うようなスライドを作る利用している場合っていうのは、
09:07
その資料が誰かに本人がいないところで渡されたとしても、
その内容を見れば言いたいことがわかるみたいな。
つまり、実はトークする人っていらないみたいな感じの内容だと思うんですよね。
でも、そういうものも多分あるとは思うんですけれども、あんまりないかな、いらないと思うんですけど、
ここで言っているこの記事の中で言っているですね、トークっていうのは話す人がメインですね。
それを補助するためとか、視覚的効果をプラスするためのものがスライドであるといったやり方ですね。
なので、どちらかというとビジュアル重視。写真があったりとか、文字は少なめにとか、
結構巨大な文字でやっているみたいな感じですね。
その中のトピックとしては、もし聴取の人たちがあなたのスライドを読んでいるとしたら、
彼らはあなたの話を聞いていないと。これはまさにその通りかなという気がしますよね。
だって書いてあることをそのまま読んでるんですもんね。
それだったら別に人の話聞く必要ないし、人の話のほうが大抵遅いから、
そうなんだと思って、早く次のスライド行ってくれないかなみたいな感じになっちゃいますよね。
文字は少なく、なるべく大きくということが書いてあって、
その中に意見として、もし文字を大きくしちゃったら、
自分のテキストがそのスライドの中に入らないみたいな感じの意見があるんですけれども、
それに対して文字が多すぎるからだよというふうに書いてありますね。
なので、文字を入れたいがためにフォントを小さくするんじゃなくて、文字を減らせばいいじゃないということですね。
なので、大きな文字を使い文字を減らせというふうに書いてあります。
これは本当立ち位置によるところもあるんじゃないかなと思うんですけれども、
やっぱりプレゼンテーションというのは、その人が主役ですよね。
もしですね、その人がいないときにでも、そのスライドの資料というか、
それが使われたいんだったら、配布用の資料は別で作ればいいのかなという気がしますね。
12:06
あえてプレゼンのスライドと配布用の資料を同じものにするとかですね、
どちらも兼ね備えるようにするっていう考え方がちょっと違うのかなという気はいたしますね。
そんなところで、次の記事なんですけれども、
次はですね、これもまたDeveloper Relations.comのニュースレターからなんですけれども、
こちらはですね、サイトがHeavybitというところですね。
そちらのこの方が20年以上DevRelのプログラムに関わっている、
キャロライン・リー・リョーコみたいな、そんな感じの方ですね。
その方がですね、デベロッパーのセグメンテーションに関して書かれていますと、
セグメンテーションは、マーケティングやるときとかに、
自分たちが対象としているユーザーですね、開発者の人をグルーピングしてですね、
ここに対してアプローチしていかなきゃいけないみたいなのを考えるときに使うと思うんですけれども、
そのときの考え方っていうのがですね、いろいろと書いてあったりとか、
あとそのフレームワーク的なものもですね、最後にあったりするので、
見ておいて損はないかなという気がしますね。
その中でですね、いわゆるペルソナにちょっと近いところもあるんですけれども、
開発者の場合ですね、どうやってセグメンテーションしていくのがいいのかというところで、
4段階上がっていますと、1つが技術要素ですね。
技術要素っていうところで、これはプロダクトフォーカスしたものですと、
2番目がユーザーですね、開発者の人で、これはデベロッパーフォーカスですと、
さらに組織っていうところで、ユースケースフォーカスと、
あとはマーケット、市場ですね、そのあたりに関してですね、
4つそこから分類していくのがいいんじゃないのかということを挙げていますと。
それぞれの技術とかに関してですね、自分たちのサービスがですね、
どういった技術が求められているとか、どういった経験を積んだエンジニアにフィットするとか、
組織規模はどうなのかとか、あと最終的にどういうマーケットがフィットしているのか
15:02
みたいなのを考えていくというのが挙がっていますと。
テクニカルについて言うと、例えばAndroid、Unity、Java C++とか、
ユーザーについて言うと、モバイルゲームのデベロッパーで、
5年以上の経験を積んでいる人とか、採用が決められる人とか、
あとは企業について言うと、大規模なゲームスタジオとか、
あとはシリーズAのスタートアップとかですね、市場について言うと、
エンタメとかメディアとか、場所で言うとですね、
サンフランシスコ、バンクーバー、モンテリオールとかフランスとか、
そういったところが挙がっていたりしてですね、
そうすることで自分たちがどういうユーザー、どこにいるユーザーに対して、
どういうふうにアプローチすればいいのかみたいなのがエクササイズされるというのが、
こちらのheavybit.comの記事としてアップされているので、ぜひ見ていただきたいと思います。
続いてですね、これちょっと自分で書いたやつなんであれなんですが、
この間書いたブログ記事で、なぜ私はDevRelを愛しているのかという記事をですね、
アップしてあります。
この中で何が言いたかったかというとですね、
なんでMoonGiftってDevRelやってるんですかみたいな感じでですね、
聞かれることが多いというかですね、よくあってですね、
それに対してなんでだろうっていうのは、
このブログ記事ではですね、結構ずらずらずらっていろいろ長く書いてるんですけど、
その場はですね、結構簡単に答えちゃったりとかしているんですよね。
それをちょっと噛み砕いたりとか、自分の中で反数した上でですね、
詳しく書いたのがこちらの記事になっていますと。
すごくざっくり言うと、現体験としてはですね、
いくつかあったなと思っていて、
高専時代の経験ですね、学生生活の時の経験が一個というところと、
あとオープンソースを紹介するメディアとしてのMoonGiftっていうのを運営していた経験ですね。
あとは、この記事の中にも勝手に書いてるんですけど、
マスイドライブさんっていう人がいてですね、
彼との出会いとか、彼とのチャットを通じて、
DevRelの骨格みたいなものが固まっていたという経験があって、
18:03
その結果として、DevRelいいなと思ってやっているっていう感じですね。
最終的にですね、何でDevRelやってるかって言ったら、
開発者を支援したいっていうのがですね、ずっとMoonGiftの時代から変わっていないと。
会社のミッションとしてもですね、そういうことを掲げていたりするので、
継続してやっているっていう感じですね。
そんな記事をですね、DevRelJPのところにアップしてありますので、
もしですね、何でMoonGiftずっとDevRelやってるんだろうっていうので、
気になる方がいたらですね、見ていただければと思います。
続いてなんですけれども、イベントに関連した内容ですね。
先日、先週ですね、4月6日にですね、DevRel Meetup in Tokyoの40、違う、嘘嘘。
全然嘘ですね。失礼しました。73回目ですね。
全然40っていうのは大嘘ですね。びっくりした。
DevRel Meetup in Tokyo73回目、ソーシャル活用術というのをやったんですね。
久々ですね。この間やったのが去年の12月にオフライン開催、オフラインとオンライン開催してからなんで、
もう1月はやってないので、3回ぶり。2、3、4、そうですね。
月にすると4ヶ月ぶりっていうところで、久々にオンラインとオフラインとですね、
会場両方を設けてイベントをやりましたと。
12月は結構テストパイロットだったっていうところもあってですね、
いろいろ物足りないところとか、こうしたらよかったなみたいな部分もあったりしたんですけれども、
そこら辺をいろいろフィックスしてですね、4月またやりましたと。
そのパネルディスカッションでやったんですけど、
オフライン側は3人ですね。パネルリスト2人とモデレーター。
オンライン側にもパネルリスト1人みたいな感じで、まさにハイブリッドですね。
オンラインとオフラインでみんなでパネルディスカッションをするといった形ですね。
なかなか今後占う上ですね、こういう形はありなのかなという気がする形でイベントをやりましたと。
そんなイベントでですね、イベントの感想を書いてくださっている方もいてですね、
21:01
こちらは野崎さんという方ですね。
こちらがLinkedInのブログとしてまとめてくれていますと。
LinkedInでつながった鈴木翔太郎さんにご招待いただき、
自分自身のキャリアとは少し違うもののデベロッパーコミュニティイベントに参加してきたので、
その学びをまとめたいと思いますというふうに書かれてますね。
非常にありがたいことですね。
特にこのオンライン時代になってですね、
人に招待されてとか人に連れてきてもらってイベントに来ましたっていう人が本当に極端に減ったんですよね。
当たり前ですよね。
多分社内のスラックとかで言われる、貼り付けられるだけですし、
別にオンラインだから会社の人と一緒に参加してる感みたいなものって全然ないと思うので、
なかなか誘う方も誘われる方も微妙なのかなっていう気がするんですよね。
でもオフラインだとリアルの場で会うというふうになるとですね、
やっぱり知り合いが一緒に来るとかですね、一緒に行くってなると結構心理的な障壁って下がるかなと。
アウェイに行く気分だと思うんですよね、最初はね。
明らかにドアウェイの場所に行くので、行ってなんかすごい嫌な気分にあったらどうしようとか、
まさかり飛んできたらどうしようとかいろいろ悩まれると思うんですけれども、
そんな時に隣に少なくとも知り合いがいるっていうだけでもですね、
多少なりとホーム感というか安心感みたいなものはあるかなと思うんで、
やっぱり連れてきてもらう経験っていうのはですね、大事かなという気はしてますね。
そんな中でですね、
LinkedInメインで交流している僕が知り得ない、より成熟したSNSの状態から見た活用方法が議論されていたので、
これは本当にためになりますと。
Twitter配信を含めTwitter活用が多い、息をするようにつぶやく使い方なので、
オンラインイベント参加時との親和性が高いとか、
意見を集めたいときはレスがつきやすいFacebook活用、
プラスSlackのコミュニティも活用とか、
LinkedInはオフィシャル感が強く気軽さがあまりないという印象が強めとか書いてありますね。
結構細かくまとめてくれてますね。
ソーシャル利用で気をつけるべきことと、
24:01
絶対にディスらない、ネガティブな人間と思われないよう振る舞う、
裏表を作らず一貫性を持たせると、キャラがぶれないのは大切と、
発信を実名で行い責任を持つと、これは本当に大事なことですよね。
炎上した場合の対処について、どこを切り取られても問題ないツイートとなるように苦労すると。
そうですよね、これね140文字っていう制限が難しいと、
Twitterに限定しちゃうとあれなんですけど、
どっか変なところを切り取られて炎上するっていう場合もあったりするので、
注意が必要かなという気はしますね。
この苦闘点があると威圧感を感じるというのが、
最近の若者の声で上がっているっていう話があって、
これなかなか面白いなという気がしましたね。
かといって常に語尾に絵文字とか使ってると、
本当それはそれでおっさんっぽくなって気持ち悪いので、
ケースバイケースなのかなって思いたいというふうには思ってますね。
最後に野崎さんの所感としてですね、
自分は長文になりがちでTwitterをあまりやっていませんが、
SNSとしての成熟度の高さからもう少し理解を深めるべきと痛感しましたと。
切り取られても大丈夫な内容となるよう気を使うのは、
例えばLinkedInに比べて1投稿あたりの文字数が少ない短文に上に、
言葉足らずになりやすいTwitterでは一層重要であると。
逆にTwitterはテキスト投稿のスキルが鍛えられる場所とも言えると。
上記のような僕から見たSNSの先輩、モサのような方々でも、
意外とLinkedInは堅苦しいというイメージや、
どう使えばいいかわからないというコメントがあったのが意外であり、
まだまだ現在のLinkedInの空気感が世の中一般では伝わっていない。
まだまだ伸びしろはあると痛感と。
鈴木さんと初リアル対面だったのに一緒に写真を撮るのを忘れたのは、
多分一生の不覚というふうに書いてくれてますね。
本当に鈴木さんまとめていただいてありがたいですね。
イベントのこういうレポートとかもオンラインになったら結構減りましたよね。
特にアーカイブがあるからまとめる必要がないというのが、
一番大きいところなのかなという気はするんですけど、
アーカイブがあるからといって見直すことないんですよね。
27:00
インプットはやっぱりアウトプットしないと、
なかなか形になりづらいという気はするので、
オンラインのイベントとかオフラインに関わらず、
こうやってまとめてくれる方の存在というのは、
とても大事かなという気がしますね。
私がURLを違うのをメモってたような気がするので、
変更しておこうかなと思います。
野崎さん、ありがとうございましたと。
ではですね、それに引き続いてというか、あれなんですけど、
一応今回、久々のハイブリッドイベント。
かつ12月に1回やって、
ちょっと物足りない部分とかもあった上でのイベントだったので、
私の方でも多少なりとも工夫した部分とかがあったので、
それはブログ記事としてまとめているんですね。
例えばどんなことをやったかというとですね、
一つは会議用のスピーカーシステムで、
Anker Power Conf S500っていうのを買ったんですけれども、
これがかなり良かったなと思ってますね。
もし同じようにですね、
10人、15人ぐらいの規模でオフラインやられる場合にはですね、
結構必須かなという気がしますね。
これがあったおかげで、
他のリアルの場所にいた参加者の人はですね、
そもそもPCをオンライン側のほうに入る必要もないですし、
スピーカーのパネリストの方もですね、
同じ共通のマイクにしゃべるだけでいいっていう形にできたので、
良かったかなと思ってますね。
このAnker Power Conf S500はですね、
今回1台でも良かったんですけど、
本当は2台をですね、接続することもできて、
そのスピーカー側と、
あと参加者側のところにですね、
一つずつ置いても良かったかなっていう気はしてますね。
あとはですね、今回はiPhoneをウェブカメラとして使っていますと、
ノートPCのウェブカメラってね、
画質も高かしれてますし、
画面の向きをですね、
映し出す向きを変更するのも面倒だったりするので、
iPhoneとかスマホをですね、
ウェブカメラにできるソフトって色々あったりするので、
30:01
その辺りと組み合わせてやることですね。
簡単にそこら辺は実現できますと。
なので、配信用のPCもZoomでオンライン側に入って、
そのPower Confの音声と、
あとウェブカメラの映像をオンライン側に流すと、
そうするとオンライン側でもですね、
こんな感じで全体見えてるんだっていうのが見えて、
それはそれで良かったかなと思ってますね。
あとですね、良かったのはテレビが会場にあったことですかね。
テレビがないとですね、大抵プロジェクターになると思うんですよね。
プロジェクターが相当強固なプロジェクターであればいいんですけれども、
大抵のこういうイベントスペースにあるプロジェクターってルーメンが低くてですね、
そのままだとなかなか映し出すのが難しくて、
会場を暗くせざるを得ない時が多いんですよね。
そうすると見栄えも悪いというかですね、
せっかくパネリストの人とかいるのに見えづらいという状態になってしまうので、
その場合はですね、テレビの方がよっぽどいいなというのは今回思いましたね。
テレビであればですね、多少遠くても大画面であれば見えますし、
映し出す上でルーメンとか関係なくですね、きれいに出るので良かったかなと思ってますね。
今回そういうイベントスペースの場所を借りてですね、やってるんですけれども、
なんでこういう場所になったかというと、結局今度こそもうコロナ禍になってですね、
イベントを会場を貸してくれる会社さんはほぼ皆無になってきてるんですよね。
当たり前っちゃ当たり前なんですけど、そもそも会場の担当者が自宅勤務していてですね、
その夕方7時とか、夕方じゃないですね、夜ですね。
夜のイベントのためにわざわざ会社に行ってですね、その管理するって本当めんどくさいですよね。
こっちとしても申し訳ないので、そういったケースはかなり減ってるかなと。
さらに会場もですね、このコロナ禍になってもう閉鎖しちゃったとかですね、
そういうスペースは閉じちゃいましたみたいなケースも増えていたりするので、
なかなかもう会社さんで借りるっていうのは難しくなってるのかなという気はしますね。
今回はイベントスペースが10人でオンライン側は無制限という形でやったんですけれども、
そんな感じで基本オンラインで安心して自宅でも見れるし、
ちょっとプレミアムとしてコミュニケーションを楽しみたい場合はオフライン側でも集まれるよみたいなほうがですね、
33:06
オフラインプレミアム的な考え方っていうほうがいいのかなという気がしてますね。
なのでそのベースはオンラインなので、やっぱオンライン側でもちゃんと楽しめるっていう工夫であったりとか、
品質担保っていうのはまず間違いなく必要かなと。
オフライン側、ごめんなさい。
リアル側をですね、メインのほうに寄せちゃうと、
多分オンライン側で見てる人たちはですね、
オフラインで楽しんでる様子を外野として見てるだけみたいになっちゃうと思うので、
それはそれであんま面白くないのかなと。
そしたら多分自宅で見ていてですね、
リラックスできる空間で、
よくわからないわちゃわちゃを見せられてるみたいな感じになると、
イベント自体からスーッと遠のいっちゃうとか、
コミュニティからも遠のいっちゃう感じがするんで、
まず基本はオンライン側でもきちんと楽しめると。
オフライン側はそれプラスアルファで楽しめるみたいな感じの仕組み作りっていうのが必要かなと思ってますね。
あとは用意したものは、
パネリスト同士の感染防止をするフィルムですね。
これはこれで必要かなと思ったので立ててましたと。
あとはですね、名刺ですね。
名刺ってね、もう忘れてましたね。
そんなものが存在することもすっかり忘れてましたね。
次回は忘れないように持っていこうと心に決めましたね。
あとはですね、オンライン側のファシリテーション。
これも必要ですね。
今回はちょっとですね、ネットワークのトラブルがあって、
一時通信できない状態になっちゃったんですよね。
そうするとオフライン側では一生懸命復旧の手続きしててですね、
オンライン側のサポートができない状態になっちゃうと思うんですよね。
そうするとオンライン側の人にしてみれば、
なんか突然ネットワーク切れて何も進まないんだけどみたいな感じになったら、
まず離脱しますよね。
そうならないためにですね、
今回はオダショウさんにですね、
運営の一人のオダショウさんに、
オンライン側のファシリテーションお願いしますって言ってて、
万が一何か起きたときにはお願いしますって言って、
その万一が起きてすぐにですね、
彼が問題が発生している間ですね、
ずっと繋いどいてくれたということがあったので、
オンライン側のですね、
ファシリテーターっていうのも必ず必要な存在かなと、
36:00
思っています。
そういったですね、
ちょっと今回のイベントを通じて学んだこととかをですね、
ブログ記事としてまとめてあるので、
今後ですね、多分開催増えていくと思うので、
そういった際のですね、
知見として使っていただければありがたいかなと思っています。
はい、そんなところで、
続いてなんですけれども、
次はですね、どれがいいかな。
Kiitaの記事でですね、
新人さんに勧める有益な技術書たち1022春というのがですね、
Kiitaの記事で出ていますと、
これなかなか有益かなと思いますね。
まず基本としてはプログラムはなぜ動くのか。
イラスト、図解式、この1冊で分かるウェブ技術の基本。
DWコード、プログラマーの数学、
Web API、プリンシプルオブプログラミング、
ライトついてますかと。
あとは作文、理科系の作文技術。
なかなかこれで面白そうだな。
改善系として、リファクタリング、
レガシーコード改善ガイドと。
チームワークはチームギーク、改善ジャーニー、アジャイルサムアイ。
あと、なぜかJava。
これすごい偏りを感じるな、突然のJava。
パーフェクトJava、エフェクティブJava、プロになるJava。
Java言語で学ぶデザインパターン入門。
テスト、技術書ではないが、
開発者として必要なビジネス理解ができる書籍として、
世界で一番優しい会議の教科書。
チーズはどこへ消えた。
コンサル1年目が学ぶこと。
カスタマーサクセスとは何か。
ほかもろもろWebエンジニア系の記事というのが並んでますね。
ちょっと偏りももしかしたらあるかもしれないですけれども、
多分もう新人さん入られてますよね、皆さんね。
最初は多分全般的な、別に技術者に限らない研修が続くかなと思うんですけれども、
最終的に技術部署に配属されたりしたらですね、
先輩としてはこういう書籍を進めるといいんじゃないかなという気は確かに出します。
39:01
新人さんに進める有益な技術書たちというのがあります。
次ですね、これなかなか面白いんですけど、
原稿が終わらないと出られないカフェが爆誕。
ルールがガチすぎて帰れませんシステム。
入ったら出てこれないやつやというのが、
これはTogetherの記事に上がっていますね。
これは原稿執筆カフェというのが高円寺にあるようですね。
原稿執筆カフェは締め切りに追われていない人は入場できませんと。
店内の緊張感維持のためにご理解とご協力をお願いいたしますと書いてありますね。
入店時に作業目標を記入いただき、その目標を達成しないと退店できません。
おー恐ろしい。
あとはですね、ルール。
入店時に受付で何文字の原稿を何時までに執筆するか記入します。
ルール2、店長が1時間ごとに原稿執筆の進捗をお尋ねします。
ルール3、原稿執筆が終わるまで退店することはできません。
恐ろしすぎますね。
原稿執筆はですね、ライトなものであればウェブメディアの機構もありますし、
さらに言えば社内のテックブログで書かなきゃいけないとかですね。
あと技術書店の締め切り間近とかですね、
MOOC本とかの執筆、普通の商業出版する書籍の執筆とかですね、
いろんなケースがあるかなと思うんですよね。
そういった執筆系、私もそうですけど、なかなかこう、
締め切りに余裕があると動かないというのはですね、あるあるだと思うんですよね。
なのでこういうところにですね、自分に今締めるためにですね、
行ってみるというのはなかなかありなのかなという気がしますね。
ただここはですね、常時やるわけではなくてですね、1ヶ月2回ぐらいっぽいですね。
4月の7日と4月の20日にしかやらないようですね。
そういう日に行くことでですね、たぶん現行執筆進みますよね。
42:09
こういう緊張感を持って取り組めれば。
4月の20日、もし執筆系で困っている方がいたらですね、
通ってみてもいいんじゃないでしょうかというところであります。
では続いてですね、こちらはESMさんなのかな。
ESM、アジャイル事業部開発者ブログからですね、
リモートワークスタイルチェックをやってみたと。
平和システムさんですね。
リモートワークチェックスタイルはGitHubのGistに上がってるんですね。
どの程度リモートワークに比重を置いて導入しているかのチェックリスト。
数字を合計し、高いほどにオフラインよりオンラインに比重を置いている傾向があります。
例えばリモートワークの導入期間。
あとはリモートワークの導入ポリシー。
リモートワークのマジョリティドアイ。
申請許可の必要性。
すごいな。一番申請許可が必要。
リモートワークを行うたびに都度申請が必要であるというのは、
かなり低いほうになるということですね。
リモートワークの適用範囲。
出社義務。
リモートワークで必要なサービス。
アプリケーションの取り扱い。
情報のアクセス範囲。
その他。その他は例えばですね。
社内において一定の権限を持つ人物がリモートワークを実践しているかどうか。
これ結構大事ですよね。
役員とかだけリアルに行く人とか聞いたことありますね。
月5000円以上のリモートワークに関する手当があるかどうか。
でもどうなんでしょうね。
インターネットの接続費用とかですね。
電気代とかかかると思うので、
そのあたりは手当があってもいいのかなという気はしますかね。
通勤手当とかかなり減額できてるはずなんで、
そこから割引いて出せばいいと思いますよね。
オフィスが存在しないと。
オフィス存在しなかったらリモートワーク以外やりようない気がするんですけどね。
45:04
あとは対外的にリモートワークに関する発信発表を積極的に行っているかどうかというのもあったりしますね。
あとはリモートワークの文化に関してもいろいろ書いてありますね。
働く時間、コミュニケーション頻度、テキストコミュニケーションの割合、
同期非同期コミュニケーションの割合などなどというのが並んでますね。
それを実際にやってみたのがAWAシステムマネジメントさんのアジャイル事業部というところですね。
結果が書いてあって、
AWAシステムマネジメントは想定外にリモートワークできている印象かもしれません。
これは私たちがお仕事でも繋がらせていただいているRubyコミュニティの企業はリモートワークが進んでいることで、
当事業部も事実上のフルリモートワーク化が実現できていると思いますと。
そして麦安子宇野さんによるチェックリストは、
現在のリモートワークへのいい振り返りの機会になりましたというふうに書いてありますね。
オフィスは存在するにはもちろんなっているし、
あとは対外的に発信しているか発信していないかというと発信していないみたいになっていますけれども、
他に関しては5455543とか5とか結構高い数字のものが並んでいるようですね。
ぜひ皆さんもこれやってみてもいいんじゃないですかね。
記事の中にGISTでアップされているリモートワークスタイルチェックリストというのがありますので、
ぜひ自社を振り返りながらやってみてもいいんじゃないでしょうか。
では、あと一つぐらいかな。
これ記事に悪意をちょっと感じるんですけれども、
人気メタバース、ユーザー数が伸びず市場の期待値を下回るというのが、
これはコインデスクジャパンだからか。
だからこれは仮想通貨に関連している話なんですけど、
別にこれはメタバースが云々という話ではなくて、
メタバースと仮想通貨を組み合わせたようなサービスですね。
48:05
そういったサービスにおいて、トークン価格がちょっと伸び悩んでいるというのが記事になっているんですね。
多分最近ですね、ちょっとWeb3っていうのが何者なのかっていうのをちょっと調べてですね、
多分これもそれに関連してくるんだろうなという気はするんですけれども、
ゲームをしてトークンがもらえるみたいなですね、
ゲームファイみたいな考え方というかスキームがあるんですけれども、
それがあまりゲーマーに好まれていないと、
ゲーマーに求められていないゲームファイ、ゲームファイでいいのかな、
ゲームFYって存在価値があるんだろうかっていう気がするんですけれども、
それが失敗しているぽいですね。
NFTとかゲーム内通貨をゲットできるとかですね、
ダメだよねみたいな感じのことも書いてありますね。
最も成功しているゲームはスキルを共有して何人もの強いプレイヤーが競い合う体験を作り出し、
勝つまでクレジットカードを使い続けるという選択肢を避けているものが多いというふうに書いてありますね。
金の匂いがプンプンするようなゲームって基本的に嫌われるのかなという気はしますね。
これはメタバースが悪いとかそういう話ではないのでご注意いただきたいんですけれども、
そんな記事がコインデスクの記事に上がってましたというところですね。
あとはもうちょい行けるかな。
こちらは秋西っていうブログなんですけれども、そちらの記事ですね。
Piユーザーが削除されたRaspberry Pi OSと公式ヘッドレスセットアップのやり方研究っていうのが記事に上がってましたと。
いわゆるRaspberry PiのOSなんですけれども、基本的にはPiっていうユーザーがデフォルトでできていて、
パスワードがRaspberryだったりするんですけれども、
Piっていうユーザーがデフォルトでいなくなったと。
当たり前だと思うんですけれども、デフォルトのパスワード変えてない人結構多いのかもしれないですね。
51:05
そうすると簡単にログインとかできてしまうので、ユーザー自体を消したということですね。
これはなかなかいいことなのかなと思いますね。
最近、Raspberry Piを屋外で使ったりとか、インターネットで公開して屋外から自分の家庭内にある数字を見るとかですね。
そういうことをやられている方も多いと思うので、お急れとRaspberry Piを外に出していて、
デフォルトのユーザー名、デフォルトのパスワードで運用しているみたいになったら、
それって結構セキュリティリスク高いよねっていう気はしますね。
なので、Raspberry Piがこんだけ普及したことによって、そういうセキュリティリスクも顕在化したというかですね。
流行っているからこそという気はしますかね。
この記事の中でその対処法というか、セットアップのやり方とかも書いてあったりするので、
参考になる部分は多いかなと思いますね。
基本的にはRaspberry Pi Imagerっていうソフトがあるんですけれども、
それを使うのが一番いいみたいですね。
これを使ってやれば、基本的にユーザー作ってパスワードも指定した形で出来上がるということですね。
Wi-Fiのセットアップとかもできるのかな。
デフォルトでWi-Fiが書き込まれてないんですよね、Raspberry Piって。
毎回ブートの下に設定ファイルとか置いて立ち上げるとかやらなきゃいけなかったんで、
そこら辺はやっぱりないのかな。
ちょっとImagerを実行してみないとわからないですけれども。
そこら辺も含めて、デフォルトでWi-Fiが使えるようになるスクリプトじゃない気もするな。
それは設定ファイルを自分で作ってそれを流し込んでおくだけなんで、大した問題ではないんですけれども、
あそこで詰まっちゃう人結構いるんですよね。
起動してみて、あれWi-Fi繋がらないっていう。
Wi-Fi繋がってるかどうかわかんないですよね。
ディスプレイがなかったりするんで。
SSHでも入れないみたいになって結構詰まっちゃう人多いので、
54:05
その辺りはインターネットで検索すればたぶんすぐ見つかると思うので、
これでPiユーザーも削除されたということだけきちんとわかっていればいいのかなと思います。
そんなところで、あとはイベントに関してのご案内になりますと、
まず次回の通常回ですね。
そちらが5月の11日ゴールデンウィーク挟むんで1週明けます。
本当は4日なんですけど、テーマがアウトプットとなっておりますと。
全部で3人の方に登壇してもらう予定になってまして、
まず1人目が小島さんですね。
小島さんは前に聞いたで、30代後半になって初めて発信活動を始めたら
人生が変わったというブログ記事がアップされてめちゃくちゃヒットしたんですよね。
LGTMが1240っていうところでめちゃくちゃヒットした記事を書かれた小島さんのお話をお聞きしますと。
2つ目がSMSっていうところのテックブログを立ち上げて、
その1年間の取り組みと学びっていうところで小島さんにお話を聞きますと。
最後はメルカリエンジニアリングブログの話というところで、
アフロスクリプトさんですね。
もっとレバレージズの木下さんですね。
テラテイルとかやられてましたね。
その木下さんにお話を伺うというところで、
かなり豪華な方々にお話を聞ける内容となってますので、
ぜひ皆さん楽しみにしていただければと思います。
今回もオンラインの会場とオフラインの会場2つ設けておりますので、
ぜひ気になるほうで入っていただければと思います。
オフラインのほうはマックス16人となっています。
今回場所は参加してくれれば見えますので、そちらになりますと。
前回よりちょっと広がっているのと、
あと幸い今回場所をお借りすることができたので、
リアル参加であっても無料で参加できますと。
いつも場所借りる費用は買っちゃうので、1000円いただいてたりするんですよね。
申し訳ないんですけれども。
今回は無料で参加できますので、ぜひご参加いただければと思います。
57:02
オンラインのほうはもちろん人数無制限で募集しておりますので、
ぜひこのアウトプットの大切さとか、
エンジニアリングブログの運営の難しさとか、
聞いてみていただければと思います。
あと今回からちょっと一個、アンチハラスメントポリシーというのを掲げておりますと、
詳しくは言わないんですけれども、
前回それに反するような行為があったので、
そこらへん普通考えれば分かるやろうって正直思うんですけれども、
それが良くないですね。
常識で分かるやろうっていうのがそれがちょっとダメで、
きちんと言語化したりとか徹底しないと、
私の常識はあなたの非常識っていうところで、
完璧にそれを意見を一致させるっていうのは難しいと思うので、
言ってなかった部分でもあるんで、
そこは足りなかったかなと思うんですけれども、
今回はきちんと明示してあります。
これはベースにDevRel Meetup in Tokyoとしての
アンチハラスメントポリシーにしていこうと思っているので、
何かあったら基本的に私に言ってもらえればいいですし、
そもそも私がハラスメントしてるみたいなケースがあったら、
それは他の運営メンバーに相談したりとか、
あと性別的に言いづらいというところがあったりしたら、
運営メンバーには徳良屋さんって女性の方もいらっしゃるので、
そちらに相談していただくのもいいかなと思いますので、
できればこういうのが使われることがないようにしていきたいと思ってはいますし、
なるべく皆さんに楽しんでほしいと、
私自身が一番楽しみたいというふうに思っていて、
こんなアンチハラスメントポリシーに関わるようなことが発生すると、
たぶん一番嫌な思いをしたのはそれに関わっちゃった方ですよね。
やられちゃった方ですよね。
その方はすごくDevRel Meetup in Tokyoで言って、
嫌な思いをしたなというふうに思っちゃうと、
今後参加するの嫌だなというふうに感じちゃうと思いますし、
我々もそこに介在しなきゃいけないというのは本当に嫌なものだなと、
今からでも予想できるので、
なるべくこのアンチハラスメントポリシーが使われるような機会にはなりたくないというふうに思うので、
できるだけ皆さんにもこのことを理解していただいて、
そういうふうになることをしないというところでご協力いただけると、
みんながハッピーかなというふうに思いますね。
1:00:04
滅多なことじゃこういうことにならないとは思うんですけれども、
時々こういうこともあるという話なんで、
みんなでいい空間を作っていければなと思っています。
今日は57回目終了していきたいと思います。
また次回は4月の19日やりますので、ぜひまたお聞きいただければと思います。
それでは皆さんお仕事を引き続き頑張ってください。さよなら。
