00:04
皆さん、お疲れさまです。夕方5時半になりましたので、DevRel Radioのほうを始めていきたいと思います。
カメラが微妙だな。こっちのほうがいいのかな。いつも通りのカメラでいきたいと思います。
今、オーディオも大丈夫そうですね。
今日のメインテーマは、最近学んだこととなっております。
いろんなオンライン学習コンテンツとかもいろいろ増えているということもありますので、
そういった中で、最近DevRelはもちろんのこと、それ以外のことでもコミュニティ周りのこととかも含め、
最近新しく発見したこととか、得た知見とかがあれば、ぜひそれを教えてくださいというところで、
こういうのは、こんなことは他の誰でも知ってるよねとかって思ったりしても、
意外とそれを知らないということはよくある話で、自分の常識は他人の非常識というところがありますので、
ぜひこの機会に教えていただきたいなと思っております。
まずこちらのURLを投稿したいんですが、また文字が多いな。
ここは削って、今ツイートをしました。
フォームのURLをお送りしましたので、大体6時ぐらいからそちらのほうを取り上げていくと思いますので、
ぜひそれまでに皆さんのご意見をいただければと思います。
まず、今のご意見ですね。何件くらい来てるのかな。
4件くらいいただいていますかね。
まだまだ皆さんのご意見お待ちしておりますので、大体6時ぐらいまでご意見をいただけると嬉しいです。
では、まず最初にこのDevRelラジオの紹介ですね。
DevRelラジオはDevRel Meetup in Tokyoがやっているネットラジオになります。
毎週夕方5時半から1時間ぐらいやっていて、DevRelに関するニュースであったりとか、
03:04
IT系のニュースとかキャリアの話とかを取り上げているというものになります。
DevRel Meetupはデベロッパーリレーションズに関するコミュニティとなっておりまして、
毎月1回、最近ハイブリッドですね。オフラインとオンラインでイベントをやっていたりとか、
あとスラックがありますね。公式サイトがDevRel.Tokyoというところがあるんですけれども、
そちらからスラックに参加することができます。
日々ですね、DevRelに関する話題とかを投稿していたりするので、
ご興味があればですね、ぜひジョインいただければと思います。
あとはTwitterアカウントですね。TwitterアカウントはハットマークDevRelTokyoとなっておりまして、
Facebookも同じDevRelTokyoっていうURLでやっております。
あとはハッシュタグがシャープDevRelJPとなっておりますので、
何かこのラジオの感想とかもですね、あればぜひお送りいただければと思います。
今なんかTwitterでYouTube見れないとかっていう人がいたんですが、見れますね。
多分すいません、今日ちょっと始めるのが遅かったからかなと思います。
早速コメントいただいてますね。
Kizawaさんからこんばんはと来てますね。
はい、こんばんは。
今日は雨が、もう今止んでるのかな。
突然さっき雨が降ってきて、すごいズブ濡れになってしまったんですけれども、
皆さん元気にお過ごしでしょうか。
コロナもですね、ようやく東京のほうピークアウトしてきたかなっていう感じはあるんですけれども、
なんか結構身の回りでもコロナに感染したっていう人がチラホラ聞くようになっていたりするんで、
ぜひ皆さん体調にはお気をつけくださいというところですね。
まず最初にですね、60ぐらいまでは最近のDevRel界隈のニュースを取り上げていきたいかなと思います。
どちらか。
結構最近ですね、英語でDevRelに関する情報が異常にとは言わないんですけど、結構増えてきたんですよね。
メモをいつもインスタペーパーに取ってるんですけど、
頭6件ぐらい全部英語系のものになってますね。
例えば、Starting Strong in Developer Relationsっていうタイトルですね。
DevRelを力強くスタートしていくためには、みたいな感じのブログ記事があります。
これは個人なのかな、Alex Slostさんかな。
06:05
この記事は簡単に言うとですね、
まずDevRelをスタートするにあたってですね、大事なポイントっていうのを挙げていて、
まずは自分の会社を理解するというところですね。
自分の会社、あと自分のところのプロダクト、両方きちんと学ぶっていうところが大事だよねっていうのがあってですね、
個人的にちょっと共感したのは製品を知るっていうところで、
まずですね、新人の目線で取り組まなきゃいけないっていうことが書いてありますね。
私もこれはよく言ってるんですけれども、
やっぱりその新人というか初心者の目線っていうのは、
初心者の時しかできないと得られないというふうに思っていて、
なかなかそのプロダクトについて詳しくなっちゃうとですね、
もうごく当たり前に何も考えずにできてしまったりとか、
こうだよねみたいな感じで雰囲気でできちゃったりするんですけれども、
我々のDevRelって初級者向けとか、
まだこれからプロダクトを触っていくっていう人を対象にやっていくことが多いので、
そういった方に対してですね、適切にアドバイスできるのは、
最初の初心者目線をいかに失わないかっていうのが大事になってくるかなと思ってますね。
この方はですね、知識の呪いっていうふうにそれを書いてますね。
製品を一度覚えると知識の呪いにかかりやすくなると。
これは専門家が教えるときに初心者の気持ちを忘れてしまう認知バイアスのことです。
Gitを学び始めたばかりのあなたに誰かがリバースして強制的にプッシュすればいいんだよというようなものですっていうふうに書いてあって、
確かにですね、リバースして強制的にプッシュすればいいっていうのはなかなか言わないかなと思うんですけど、
Gitのコマンドとかね、プッシュすればいいとか、プルリク送ってとか、
そういう専門用語が入ってくると初級者とかはなかなかそれについて来れなくなっちゃうっていうのはあるかなと思いますね。
無知というギフトがあるうちにそれを受け入れるとかですね、
自分のユーザージャーニーをメモしておくとかですね、そういうの大事ですって書いてありますね。
これはすごく納得できますね。
その後が仲間との出会いというところで、ユーザーが誰か知るとかですね、
そのユーザーがどこにいるのかとかを学んでいくとかっていうのが書いてあります。
あとは最終的な感想。
この方というか、このブログ記事で書いてあるデブレルに取り組み始めた最初の数ヶ月間ですね。
09:03
そこでやっていくところとしては、まず効果があるものを取り入れると。
これはそうですよね。
ここにも書いてあるんですけど、デブレルの正しいやり方は一つではありませんと。
そういった意味では、いろんなことをやらなきゃいけないと。
その数だけでもアップアップになってしまうケースあると思うんですけれども、
その中で自分たちの会社とか自分たちのプロダクトにとってですね、
効果的なものを取り入れていくというのが大事と書いてありますね。
あとは自分に時間を与えると。
デブレルは本質的にクリエイティブな活動なので、
自分の声を見つけるために時間をかけてくださいと。
様々なタイプのコンテンツを試して自分に合ったものを見つけてくださいと。
これも確かに分からないでもないですかね。
ポッドキャストが得意な人もいれば、
登壇が得意な人もいるし、YouTuberとして成功している人もいるし、
ミシェルとかもそうですね、GitHubのミシェルって彼女はアドボケイトなのかな?
なんですけど、ゲーム業界でかなり有名な人みたいで、
ゲームで楽しみながらGitHubの宣伝とかやっていたりしますね。
それは彼女のスタイルに合っているのかなという気はしますね。
あとは同僚の先輩デブレルのシャドウをすると。
あなたがシニアデブレルの仕事をフォローし観察できるのであれば、
ぜひそうしてくださいと。
彼らがコンテンツを作成し、コミュニティと関わり、
製品を使用する様子を観察することができると。
なので、彼らの知見を積極的に学んでいきましょうというところですね。
一番最後がリーチアウトと書いてあって、
これは何か迷ったことがあったら、
このアレックス・トロストさんに連絡してくれというところで記事が締められてますね。
この記事、結構いい記事だなと思うんですよね。
特に初心者というかビギナーの方は見ていただきたいなという内容になっていますので。
ツイート忘れていたのでツイートしておきましたと。
Starting Strong in Developer Relationsという記事になります。
他にもですね。
あとちょっと面白かったのが、
Udemyって多分皆さんご存知だと思うんですよね。
12:01
オンライン学習サイトですかね。
プログラミングとか学べる教材が色々あると思うんですけれども、
その中にDevRelが登場したんですよね。
URLをツイートしておきました。
UdemyのDeveloper Relations FundamentalsとDevRel Master Class 2022というコンテンツですね。
全部で2.5時間のオンデマンドビデオ。
学習期間の制限なしということになってますね。
これ購入してですね、実際見てるんですけれども。
誰なんだろうな。誰が講師をやっているのか。この人かな。
プリンスパトニーですかね。
この人は何者なんだろうな。
PI、データサイエンティストっていうふうに書いてあって、
ソフトウェアデベロッパーの方ではあるんですけれども、
この方がですね、多分インド系の方でちょっと英語が、
私はインド系の英語が不得意だったりするんですけれども、
そんな中でも字幕とかもあったりするんで、
そんな聞くのが難しい感じではないですね。
結構初級者向け、結構基礎的なところからですね、
DevRelに関して話してくれるので、
全部で2時間半とは言いつつ、
一個一個の動画はどのぐらいかな、これ。
3分、1分、長くて4分とかですね、くらいの動画になっているので、
一個ずつ聞いてですね、
学んでみるのもいいんじゃないかなと思いますね。
この1件だけだと思うんですけどね、
なかなか面白いなと思いますんで、
ぜひ皆さん、ゆでみで学んでみてください。
あれ、これ1件の検索結果で1220円になってるな。
あれ?私これ無料で買ったんだよな。
なんで無料で買えたんだろう。
料金また変わっちゃったのかな。
それとも多分まだ無料で買えるんじゃないかなと思いますので。
あ、違う。1220円になってる。
あれ、すいません。私今朝買ったと思うんですけど、
今朝か昨日か買ったと思うんですけど、無料だったと思うんですけどね。
15:01
今は1220円になっておりました。
でも特に初級者とかはですね、
これを使って学んでみるのもいいかなと思いますんで、
ぜひ見てみてください。
ではですね、続いての記事が、
こちらは行動経済学に関する記事なんですけれども、
といってもデベロッパー向けの行動経済学っていうところで、
プログラマーのための行動経済学と、
自信過剰とDWコードっていうタイトルでですね、
ブログ記事がアップされております。
これめちゃくちゃ納得感のある記事だったりしますね。
行動経済学っていうのは簡単に言うと、
人間は100%正しい行動を取るわけじゃないというところですかね。
結構エモーショナルだったりとか、その場の雰囲気だったりとか、
意外とその選択っていうのは100%正しい、
合理的なものじゃないというところが行動経済学ですね。
もともと経済学っていうのは、
人間は必ず正しい判断を正しく下すっていう前提の下で
組み立てられていたんですけれども、
なかなかそういかない、そういう結果にならないことも多くて、
そのジレンマを解決するためにですね、
行動経済学っていうのが作られたっていうのが、
まずバックグラウンドにあるんですけれども、
それを使ってですね、
プログラマーのための行動経済学っていうのがあります。
簡単にこの記事を言うとですね、
3ヶ月くらい経ってですね、
自分の行動を見返したときに、
その行動が何をやっていて、
今度何を修正しなきゃいけないのかっていうのを思い出すのに
すごい時間がかかると。
これは多分もうプログラマーであれば、
もう何回も何回も経験したことあると思うんですね。
私自身もしょっちゅうあるんですけれども、
なのに毎回同じことをやっているということですね。
サマリーとしては、
人は忘れてしまうことを忘れてしまうと。
喉元過ぎると熱さを忘れるっていうところですかね。
それで記憶に対する自信過剰はレガシーコードの一因となると。
本当これはその通りですよね。
なぜか忘れるわけはないというふうに思っちゃうんですかね。
その結果として、
とんでもないコードが書かれてですね、
18:01
3ヶ月ぐらい経つと意味わかんなくなるというところですよね。
リーダブルなコードを書こうというふうに書いてありますね。
ここで言う自信過剰とは、
自分の能力を課題に評価すること、
あるいは自分にとって都合のいい結果が起こり得る確率を課題評価することを指します。
有名な研究としては、
ほとんどの人が平均的なドライバーよりも運転がうまいと思っているということがあります。
平均的って言ってるんで、半分以上の人たちは平均以下のはずなんですけれども、
ほとんどの人が自分は平均以上だというふうに思ってるっていうのが面白いところだなと思いますね。
これもそういう研究結果があるようですね。
運転スキルだけではなくて、
さまざまな場面において自信過剰を見られますということですね。
一つの研究では、約半年後に実験の担当の人にですね、
メールをするなら20ドルの報酬がもらえると。
何もしなくても同じ時期に、
多分それより全然低いんで、2ドルもらえますよみたいな感じのことをしたと。
すると多くの人たちが、
メールしたら20ドルもらえるっていう方を選んだというふうに書いてありますね。
なので自分は半年後に必ずメールするっていうふうに、
ちゃんと記憶できてるはずだって思ってるんですよね。
でもその結果なんですけれども、
実際にメールしたのは半数ぐらいしかいませんでしたというふうになってますね。
個人的にはタスク管理にすぐ登録しちゃうんで、
さすがにこれはできるかなっていう気はしますけど、
記憶に関して言うと、自分をかなり疑ってますね。
脳みそはCPUであってストレージじゃないと思っているんで、
そういう記憶はなるべくしないようにしてますね。
全部タスク管理のto do listの中に全部突っ込んで全部忘れるっていうのが、
私自身の行動な気がしますね。
プログラミングの話に戻りましょうと。
もし将来的にコードを見返す可能性があったとして、
このままのコードだと解読に1週間かかることが事前に分かっていたとしたら、
あなたはどうしますかと。
その時はその時だという人もいると思いますが、
理想としてはやはりコードを見やすくするのではないでしょうかと。
では現実としてなぜそれをやっていないのかというと、
今現在の自分はこのコードを読めるので将来の自分も読めるだろう、
21:01
つまりある程度は覚えているだろうと考えているからですと。
しかし、さっきの研究の結果からも分かるように、
それは課題評価の可能性がありますと書いてありますね。
これは本当その通りですよね。
分かっちゃいるんですよね。
分かってはいるんですけど、
未来の自分に対してうまく投資ができていないんですよね。
これがチームだとまたちょっと違うと思うんですよね。
チームだとそもそもコードを書いていない自分の同僚とか、
自分の先輩とか後輩に対して、
自分のコードを理解してもらわなきゃいけないっていうのがあるんで、
そうするとそういうコメントとかテストとか、
そういうのをしっかりやるかなとは思いますね。
テストは一個の手ですよね。
私はテストだけはきちんと網羅的に書くようにはしていて、
同じテスト結果はちゃんと書えるようにしておけば、
もし万が一理解してなくて変更してしまったとしても、
テストをこっちで思い出すかなというふうには思ってますね。
まず対策がいくつか書いてあるんですけれども、
分かりやすいコメントを残すと、変数の命名規則をつけると、
影響範囲を最小化すると、
あと関連するコードは近くに書くというふうに書いてありますね。
最近どうなんでしょうね。
オブジェクト思考だけに限らないと思うんですけど、
結構クラスを継承継承継承とかってミックスインとか使っていたりすると、
どんどん関連するコードが遠くなる場合があるかなという気がするんですよね。
実際のインターフェースはここにあるのに、
その処理してるコードは全然別の場所にあったりすると、
それを追いかけるだけでも結構疲れちゃうみたいなという気もするんですけど、
この辺りは設計次第かなというところなんですかね。
組織として失敗を防ぐにはというところで、
読みやすいコードを書くためのコストを下げると、
あと読みやすいコードを書くことを緩く規制するということが書いてありますね。
リントとかテストとか、
あと最近ちょっと面白かったのは、
Flutterですね、DartとかFlutterのパッケージをいくつか、
いくつかというか、一つ作って今二つ目作ってるんですけど、
FlutterのDart.pubだったかな、
そこにアップするときに事前にチェックしてくれるんですよね。
例えば、アップデートしたときには必ずチェンジログをアップデートしなきゃいけないとか、
exampleのフォルダを作って、その中に例サンプルとなるコードを入れなきゃいけないとか、
24:05
そういうルールをコマンドのほうでチェックしてくれるんですよね。
readme更新されてなかったらreadme更新してからプッシュしてくださいみたいな感じで、
エラーを出してくれるので、
そうすると最低限やらなきゃいけないことをちゃんと規制してくれるというところでは、
結構いいやり方かなと思いますね。
GitHubとかでActionsでリントかけてとか、テスト回してとかそうなんですけれども、
コードをプッシュしたときにリアルタイムにそれをチェックしてくれるっていうのが、
割と便利だなって思ったりしますね。
コメントもいただいてますね。
キザワさんから、過去の自分のブログ記事に何度助けられたことかと。
いや、これは分かりますね。
私もブログというか聞いたにメモを取ったりするんですけど、
同じことで詰まってですね、Googleで検索したら自分の記事が出るみたいな。
あれはなかなか嬉しいような情けないようなっていう感じですよね。
同じことで詰まってるやんみたいな。
覚えとかなかったっていうね。
何か問題があったら覚えておくというか、本当忘れてるんですよね。
1回詰まったことをまた繰り返すのかっていう気もするんですけれども、
何らかそのうち詰まったときに、
そうだ、これ聞いたに書いたなと思って検索して探すみたいな。
もはや諦めの境地に達しているときもありますね。
高見さんからはコミットのフックにReadMeの更新チェック。
そうですね、そういうのもありですね。
ただ必ずしもReadMeを更新する必要がない場合もあるんで、
そのあたりはフックで完全に規制しちゃうとなかなか辛いところもあるかなと思いますね。
というこの記事ですね。
プログラマーのための行動経済学っていう記事になります。
個人的にもこのDevRelとかも結構行動経済学によるところが大きいかなと思っていて、
例えば小島さんとかがよく言われてたんですけど、
例えば地方とかに行くとですね、
製品を選定する理由って別に価格とか機能だけじゃないんですよね。
どっちかっていうと付き合いのあるベンダーとは言わないですけど、
そういうITのお手伝いをしてくれる人がお勧めしてくれるものとかですね。
ネットで探すっていうよりはどっちかっていうと結構エモーショナルな理由で選定されたりすることがあるんで、
そういうところっていうのは従来の経済学が働きづらい部分ではあるという気はするんですよね。
27:06
パブリッククラウドでAWS、GCP、あとAzure、IBMとか色々あると思うんですけれども、
それぞれの機能を完全に合理的な理由で選んでいるかっていうとそういうわけでもなくてですね、
意外とブランディングの部分とか、なんとなく私はAWSが好きとかGCPが好きとかですね、
そういった理由で選ぶときも多いのかなとか思ったりもするので、
そういったエモーショナルな部分とか、完全合理的な行動していない部分っていうのは、
行動経済学が活かせる部分かなと思ってますね。
意外とプログラマーとかは合理的に動きそうな気がするんですけれども、
意外とそんなことないですね。
Twitterの誰々さんがその言語を知ってるから使うとか、
ブログ記事でこのフレームワーク流行ってるって言うから使ってみるとかですね。
結構エモーショナルな理由でプロダクトとかフレームワーク選んだりする場合が多いのかなという気がしますね。
ぜひこちらお読みください。
そして次が、まずこれがいいかな。
こちらはITメディアさんの記事で、
円安でも三大クラウドを使い続ける企業は47%。
MM総研が長座。
過半数が方針を変更すると解凍というふうに書かれています。
これ実際どうなんだろうって思いますけど、
多分買えないところが多いのかなとはぶっちゃけ思いますかね。
一応円安で料金が結構勝手に上がってしまっているっていう部分もあってですね。
国内ベンダーのIaaSに乗り換えるっていう人が18%と。
利用推進するというところが28%とか。
利用方針を変更すると答えた会社が46%。
いや、逆か。
使い続けると答えたところが46%ですね。
残り53.5%は利用方針を変更するというふうに解凍したとありますね。
30:01
実際これ変えるのってIaaSだけであればまだ現実的かもしれないですけど、
それ以外マネージドとか使っていると相々簡単じゃないかなという気がしますかね。
AWS、Azure、GCPのいわば3大パブリッククラウドなので、
これ以外に乗り換えるっていったときの選択肢がなかなか狭まっちゃうというのが
辛いところかなとは思いますかね。
ただ利用の仕方次第で、どこですかね。
日本だと二福田さんとか桜インターネットさんとかに乗り換えるっていうのは
できなくもないのかなという気はしますかね。
で、面白いのが16.1%の人たちは円立ての請求代行サービスを使うって書いてありますね。
別にこれで安くなるわけじゃないと思うんですよね。
別にドル立てだったのは円に変わるだけで、
その請求代行サービスが円安になった分を面倒見てくれるわけじゃないと思うんで、
安くなるわけじゃないと思うんですけど、
この請求代行サービスを使うって16.1%が言っているのがなかなか熱いなと思いますね。
他にはプライベートクラウドの利用を検討するという意見もあったりするそうですね。
なかなか円安でも最近戻ってきたと思うんですよね。
これはYahoo Financeとかで見ればいいのかな。
グラフがドル円。
チャートが出ない。
なんてこった。
チャートはどこで見れるんだ。
楽天証券。
見れた見れた。
これを1年とかで見ると、
いやーでもそんなに上がってるなー。
すごいですね。
これだから去年の10月ちょっと前ぐらいが110円だったんですね。
それが今1回140円スレスレまで行って戻ってきたと思ったらまた140円スレスレに上がっているので、
相当効きますよね。
33:00
ドル盾は結構高くなってきているような気がしますね。
ユーロとかにしても130円弱くらいだったのが、
今139円ぐらいかな。
なのでやっぱりこちらもそれなりに上がってきてますね。
大変ですね。
パブリッククラウドを使う料金が上がっていくっていう話と、
あとドル盾で給与をもらってた人たちが勝手に給与が上がっていくみたいな話とかもあって、
なかなかドル盾ユーロ盾の話は大変ですね。
ではですね、記事系はこれで最後ぐらいかな。
こちらはまたこれもITメディアさんの記事ですね。
ITエンジニアの中途採用、合格理由の2位は技術力不足と。
第1位は何かという記事が上がっております。
そんな第1位なんですけれども、コミュニケーション不足と、
コミュニケーション能力が低いという理由で先行をお見送りになってしまったと。
お見送りっていうとまだチャンスありそうな感じに見えちゃいますけど、
そういうわけでもないと思うのでお断りの理由ですね。
お断りした理由が一番大きいのはコミュニケーション能力が低いことというふうになってますと。
その割には先行で重視しているポイントが一番強いのは技術力なんですよね。
ついで、接近はしてるんですけれども、コミュニケーション能力というふうになってるんですよね。
技術力を優先しているにもかかわらず、コミュニケーション能力が低くてお断りするというところを見ると、
意外と技術力よりもコミュニケーション能力のほうが重視してるんじゃないのかなっていう気がしますよね。
これ結構年齢とかにもよるのかなっていうところがあるんですけれども、
技術力だけではなくコミュニケーション能力や他者との調整力など、
ヒューマンスキルを求めていることが伺えると分析しているというふうに書かれてますね。
評価が高いエンジニアに共通する特徴というのが挙がってるんですけれども、
36:02
一つ目が技術的なセンスや素養があること、これが36パーセントですね。
その次が顧客や関係者との調整力が高い、マネジメント能力が高い、
論理的思考力や分析力に長けている、コミュニケーション力が高いというふうになっていて、
ほぼほぼヒューマンスキル側なんですよね。技術力ではない部分を見ているという気がしますね。
これはレバテックさんのものになっているので、多分主に日本企業向きなのかなという気がするんですけれども、
多分少なくともアメリカとかだとこういうふうにはならないのかなという気はしますかね。
よく言うアメリカ人一人一人の能力を見比べると日本人のほうがよっぽど高いんだけど、
チームで見るとアメリカ人のほうがすごく高くなるみたいな話があったりするんで、
どちらかというとマネージメントとかチームメンバーをマネージする人ですね。
そういう人の能力が高いかどうかというところでパフォーマンスは変わってくるという気がしますね。
技術者一人一人にそんなコミュニケーション能力が高いかどうかっていうのを求めるのはなかなか難しくなるのかなという気はしますね。
タコミ知恵さんからのコメントで、結局面接って一緒に仕事したいかどうかですしねというふうに書いてありますね。
それはそうですね、それ一番大事ですね。
確かにいくら能力が高かったとしても、一緒に仕事をしたくないと思う人はなかなか雇用することはできないですかね。
一緒に仕事したいかどうかってどうやって見極めるかっていうところではあるんですけれども、
それを見極めるためにもコミュニケーション能力がそれなりにないとなかなか会話にもならなかったりすると、
一緒に働こうっていう気にはならないかなと思いますね、確かに。
その意味では、関係者とのコミュニケーションがうまく取れるとかっていうよりは、
少なくとも同僚とうまくコミュニケーションが取れる人っていうのは大事かなという気はしますかね。
そんな話がITメディアさんの記事になります。
あとはもういいかな。
39:00
あとこれ最後、ヘロクの記事ですね。
ヘロクがヘロクスネクストチャプターというブログ記事をアップしていって、
いわゆるテック業界で話題になってましたけど、
ヘロクが無料プランをやめるという記事がアップされておりますと。
いつかは来るだろうなとは思ってましたよね。
セールスフォースに買われたタイミングですぐになるんじゃないかなと思ったら意外とならなくて、
このままいけんの?みたいな感じになっていたところで、
ついにこのタイミングになってしまったという感じですね。
10月26日より1年以上アクティブでないアカウントと関連するストレージの削除を開始しますと。
11月28日より無料製品プランの提供を停止しますというふうに書いてありますね。
別に決して高いものじゃないんですよね。
ヘロクダイノスは月7ドルからありますし、レディスも月15ドルから、
ポストグレも月9ドルから使えるというふうに書いてあるので、
決して高くはないかなと思うんですけれども、
個人的に思うのはワークショップとかハンズオンとかで無料の場所があると、
パッとコードをデプロイして試すみたいなことができるんで便利だったなと思うんですが、
その場所がなくなるというところですね。
どうしてもいいかなと思うんですけど、
他の選択肢としてはグリッチとかになってくるかなという気がしますね。
海外には他にもヘロクのオルタネイティブサービスっていくつかあるんで、
そこを使うっていうこともできるんですけど、
何らかヘロクのほうが知名度は高いんで、
使う人とかも安心して使えてたかなという気はしますかね。
本当、次の選択肢を考えないといけないですね。
このヘロクと同じく買われたのがスラックなんですよね。
スラックもいつ無料プランなくすかっていうのがドキドキですね。
絶対きますね、これ。
あと1年持てばいいところかなという気はするんですよね。
完全に、もともとはビジネス向けであって、
無料プランがあったからコミュニティー界隈で使う人たちもたくさんいたという気はするんですけれども、
もうそろそろ無料プランなくすっていう決断になるんじゃないかなという気がするので、
42:01
なかなか恐ろしいですね。
次の選択肢としては、今のところ選べるのってディスコードくらいかなという気はするんですけど、
ディスコードもずっとそのまま無料プランだけで突き進んでいけるのかどうかっていうのは、
個人的に結構怪しいかなと思ってますね。
料金プランのやり方が違うんで、個人個人で課金するっていうモデルをディスコーダー提供してるんですけれども、
ぶっちゃけ無料で回してるサーバーは多いというか、
個人的にも有料課金はしてるんですけど、それでも無料で参加してるサーバーの方が全然多いので、
今後を考えるとちょっと怖い部分があるかなという気はしますかね。
そのうちディスコードがAmazonとかに買われたりとかした日には、
なんか目も当てられない状態になりそうで怖いですね。
高道絵さんからコメントきてますね。
お試しに使ってみるという用途もなくなっちゃいますしね。
そうですね。せめて無料で24時間使えるとかだったらまだいいんですけどね。
ハンズオンの間だけ持つみたいな感じで使えるんですけど、
そういう使い方もできなくなりますね。
この辺りなんか面白い仕組みできないんですかね。
ぶっちゃけハンズオン提供する側でいくらか払うのは問題ない気がするんですよね。
そのぐらいの予算は出せるはずなので、問題は利用者側にクレジットカード登録してくれとか、
お金払ってくれっていうのが難しいっていうだけなので、
こっち側である程度予算加工してアカウントを発行して使ってもらうみたいな仕組みだったらいいと思うんですけどね。
スラックの件ですね。今90日対応で悩んでるコミュニティどうするだろうと。
どうなんでしょうね。
90日対応で悩んで、それなんとか解決して終わりみたいな感じなんですかね。
わかんないですけどね。
多分来年ぐらいには有料オンリーになるんじゃないかなと今のうちに予言しておきます。
ではですね、今日のメインテーマですね。
今日のメインテーマは最近学んだこととなっております。
今は4件いただいてますね。
まだ間に合いますので、今のうちにご意見くださると嬉しいです。
45:07
ではですね、まず最初がデブレルネームジャーニーマンさんからですね。
いつもありがとうございます。
サテライトスタイルのカンファレンス運営はいい経験でしたと。
振り返りの報告会でも次回に向けた具体的なアイディアを議論できてよかったですと。
運営負荷の高さも実感し運営3倍は賛同ですと。
これから主流になるかもしれないので引き続き会を重ねて経験値を増やしたいですというふうにいただいてますね。
ありがとうございます。
そうですね、この間のデブレルジャパンカンファレンスはサテライトスタイルでやったんですけれども、
それもいい経験だったというふうにいただいてますね。
で、そうですね、この中にありますけれども運営3倍っていうのが書いてあってですね。
次回ですね、デブレルジャパンカンファレンス2023というのをやる際にはですね、
運営を3倍にしたいなと思ってますね。
中心的に働くメンバーもいれば当日とか限られたリソースの中で活動してくれるっていう人も含めですね。
運営が3倍なので20人弱とかいるといろいろできることもあるんじゃないかなというふうに思っているところですね。
まだ全然ですね、計画も立てていないというか、
ザックバランナ、ブレストをこの間やったぐらいな感じではあるんですけれども、
もしですね、やる際にはぜひ一緒にやってくれる方々をですね、
これまで以上に増やしていきたいなと思っております。
ではですね、続いて2番目ですね。
デブレルネームジャニー、ごめんなさい。
西から来た馬面の男さんですね。
いつもありがとうございます。
1つ目は企業のエンジニア採用担当者としての学びの話ですと。
Meatyというカジュアル面談サービスを使ってみての学びになりますと。
このサービスはカジュアル面談をよりカジュアルに実施でき、
採用媒体などを通さず、気軽にいろいろな方と話せるのがメリットです。
主に転職・潜在層と接触が可能となっています。
せっかく話すので、面談後のフィードバックのアンケートをもらっています。
弊社にはエンジニア組織があって、自分たちで開発していることは
4割の方に知られていないので、
広報など認知獲得をしていく必要があると、外の物差しで新たに学びましたと。
2つ目はコミュニティでリアルに会ったとき、
目が合って初めましての挨拶が久々に体感できたことですと。
本当これはもう久々ですと。
48:00
おそらくTwitterなどのアイコンを見たことはあるけれど、
実際に面識がなかったですとか。
イベント後のちょっとした時間でお互いに自己紹介などを交わして
知り合いになれたことです。
オンラインイベントは参加者同士の交流ってなかなか作れませんが、
リアルだとさっとできるのが本当に魅力ですねと。
改めてリアルイベントについて学びました。
長くなりましたが以上ですというふうにいただいています。
ありがとうございます。
そうですね、個人的にMeaty使ってみたいなって思うんですけど、
なんでMeatyだと参加者側がカジュアル面談してくれるんでしょうね。
ここの部分がちょっとつながってこないですよね。
Meaty使ってみれば分かるじゃんっていう話かもしれないんですけれども、
ここの部分が分かると、
だからMeatyがいいんだみたいな感じのことが分かると、
使ってみたいなって思ってますね。
2つ目ですね、やっぱりリアルで会うといいですよね。
忘れていた感覚が本当に思い出されますね私も。
ただ毎回名刺忘れますね。
今こうやって名刺とかって言ってるんですけど、
いざ当日になると名刺のことなんかすっかり忘れていてですね。
こういうふうに交換する文化あったなとかって思いますね。
ただ、これはいつだったかな。
多分新宿でやったときのパネルディスカッションで
増井さんがやって、その後大地さんもやっていた
NFCのタッチするやつですね。
それでAbout Meみたいなやつを表示するっていうのがあるんですけど、
あれはやりたいですね。
あれのほうが個人的には合ってるかなっていう気はするので、
あれを作るならありかなと思いますね。
名刺っていうよりはデジタルデータを交換するような感じで
情報交換するほうが個人的には好きかなと思ってますね。
コメントで早速来てますね。
じゅんさんから名刺忘れますねと。
名刺忘れますねってじゅんさんの名刺忘れちゃダメですよ。
あれ結構お金もかかっているいいやつなので
あれを忘れちゃったらもったいないですね。
高道英さんは逆にカバンから出さないので忘れないときてますね。
カバンに入れときゃいいっていう気はするんですけれども忘れますね。
ポーケンですね。
ぶつけると情報が交換できるっていうデバイスが
ほんとスマホの始まったときですね。
51:01
2009年とか2010年ぐらいにあったと思うんですけど、あれですね。
あれに近い感じで今はNFCでスマホタッチするだけできるので
現代版ポーケンみたいな感じですね。
3人目デブレルネームTキザワさんですね。
いつもありがとうございます。
私はAWSの仕事をしておりますが日々勉強ですねと。
常に必死にキャッチアップしていないとついていけなくなる恐怖感と戦っていますと。
そうした先に成長があるのは過去の経験で分かっているので
エキサイティングであり楽しみですときていますね。
これは素晴らしいですね。
ほんとAWSって先端を走り続けていて
ユーザーを置いてけぼりにしていくサービスかなって日々思うんですけれども
やっぱり関わっていてもそう感じるんでしょうね。
面白いですね。
どんどん先端を走りまくっているサービスっていうところが
開発者の心をグッと掴むんでしょうね。
なんとなくいろんな世の中にサービスがあって
最初はキラキラしてるんですよね。
でもそれをずっと使っていて
サービスがどんどん成長して大きくなっていくうちに
だんだん車輪の動き方がゆっくりになっていって
大手企業向けっていうところもあったりして
なかなか変更が難しかったりとか
見た目に分かりやすい機能ではない部分で
内部のほうで改善とかが進んでいて
安定はしているんだけれども
だんだんキラキラが薄くなっていくんですよね。
そうすると他のサービスのほうがキラキラして
そっち側にユーザーが流れていくとか
なんとなくホニャララっていうサービスはもうオアコンだよね
みたいな感じの流れになるんですけど
AWSに関してはほんと走り続けているというか
キラキラし続けているっていうところが
本当に素晴らしいなと思いますね。
小田さんからコメントきてますね。
一層駅前でマンガ喫茶の宣伝しているみたいな
着るタイプのプラカードを身につけて
参加してみてはいかがだろうかと。
これはサンドイッチマンですかね。
渋谷の道玄坂とかでいらっしゃいますよね。
あれを着てどうなんだろうな。
Tシャツとかにはなんだろうな。
昔はよく会社の社員賞とか首からぶら下げてる人いましたけど
あんな感じのやつはできなくはないかなという気はするんですが
54:04
スーツとかだったらネクタイピンとかね。
衿のところにやるピンとか
そういうところにNFCとか仕込むのは
ありな気はしますかね。
サンドイッチマンはなかなかビジュアル的にきついものあるかな
という気はしますかね。
では最後デブレルネームさっぽろのじゅんさんですね。
いつもありがとうございます。
知見だけでなくガジェットの体験会を公開でアウトプットしていると
ガジェットもオフラインで集まってくるということの再認識をしました。
秋以降、少人数かつオフラインで実施できるガジェットの体験会を模索しており
試してみるごとにブログにまとめてアウトプットをしていました。
そうしていると関東のハードウェア企業から
体験してみませんかという案内がいただくようになり
札幌に来るときに声掛けをしてもらえるようになりました。
体験を独り占めしても仕方ないので体験会をセッティングして
公開情報にして次の機会の種にしています。
感染拡大対策ができていないととても公開などできず
難しい部分もありますが地方コミュニティの活路になる
引き出しの一つかなという学びでしたといただいています。
ありがとうございます。
ガジェット系札幌のじゅんさんが得意としているVR系とかは
特にオフラインでの体験が必須になってしまうかなという気はするので
そういった意味でなかなかオンラインだけだと
楽しさが分かってもらえないというデバイスの
技術の一つかなという気はしますね。
そういった意味ではオフラインに人が集まる重要性というのも
参加者の人も納得しやすい部分があるかなという気はしますね。
そうですね。
こういうのを繰り返していくことで
知見をためていくフェーズに今あるのかなというのは
確かにその通りで
なんとなくオンラインでも回ってるからいいやと思って
オンラインだけでイベントをやっていると
だんだんその熱量が下がっているのが分かるんですよね。
運営してても分かるし
参加者としても結構分かる部分もあるんで
そうするとなかなか前の状態に戻りづらくなるのかなという気はしますね。
なので結構運営メンバーとか
今も活発に活動されているコミュニティとかは
なんだかんだ言って
なんとかオフライン化していこうという努力を
今積み重ねているのかなという気がしますね。
57:02
別にオンライン側をなくしたいというふうには
全然思ってないんですけれども
いかにミックスした形、いい形を見つけ出せるかっていうのを
今ちょっと模索しているところなのかなという気がしますね。
ありがとうございますというところもあって
ちょっとイベントのご案内にもつながってくるんですが
次回のイベントが9月7日
DevRel Meetup in Tokyoの78回目というところで
商業技術書出版を学ぼうというタイトルで
イベントをやるんですけれども
こちらはオフラインでイベントをやるという形になっています。
これはさっき言っていたですね
いかにオフラインに人を戻すかと
熱量を高めるかというところを考えていて
まずオフラインのみの開催という形になっておりますというところですね。
一番最初のDevRel Meetup in Tokyoも20人ぐらいとかでやりましたし
その後もそんな急拡大とかしてなくてですね
多くても30人ぐらいとかでイベントやっていたと思うんですよね。
なのでまずそのぐらいの規模までいかに戻すかというところで
イベントをまず粛々とやっていこうかなと思っています。
オンライン側に関してはですね
このイベントをやった後別途イベントをやっていこうかなと思っていて
その中で熱量を2段階作っていくような感じですね。
何でしたっけ
Netflixとかでアニメとかを一気に投入して
一気に消費されてコンテンツが終わっていくみたいな話があるんですけど
それをいわゆるテレビとかの場合は
毎週何曜日の何時とかでやることによって
このちっちゃい山を何回も繰り返していって
徐々に火を大きくしていって
ソーシャルでバズるみたいな感じの仕組みとかを作るのが上手っていう話があって
そんな感じですね。
同じコンテンツを違う形で繰り返すことによって
ちっちゃい波を複数回作っていくみたいなことが
できるといいかなというふうに思ってますね。
例えば2週間後とかかな
イベントをやればまずオンラインで作った
オフラインで1個山を作って
その後オンライン側でも山を作るみたいな感じで
それによってデブレルの熱量を
ちっちゃくちっちゃく維持していけるといいかなとか
1:00:01
っていうふうに思っております。
はい、というところでですね
本日のデブレルラジオ77回目ですね
最近学んだことというところを終了していきます。
来週はまだ
多分ラジオの早い
来週はもう9月ですね。早いな。
怖いですね。もうあと9、10、11、12点
今年あと4ヶ月しか残ってないってことですね。
びっくりですね。
この間2022年始まったと思ったら
もう終わりかけかなという気もしますね。
びっくりですね。
というところで
来月はもう9月という
9月のデブレルラジオになりますので
ぜひぜひ皆さんまたお付き合いください。
ということで本日のデブレルラジオ77回目はですね
以上で終了となります。
皆さん引き続きお仕事頑張ってください。
私もこの後まだイベントとかありますので
頑張りたいと思います。
では皆さんまた来週お会いしましょう。
さよなら。
