DevRelラジオの紹介とDevRelについて
はい、皆さんお疲れ様です。今日は1月の23日火曜日の夕方5時半になりました、DevRelラジオのですね、今日は148回目をやっていきたいと思います。
まず最初にですね、DevRelラジオの紹介ですね。DevRelラジオはですね、DevRel Tokyoでやっているネットラジオになります。
毎週火曜日夕方5時半からですね、1時間ぐらいお届けしておりますと。
DevRelっていうのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel東京では、そんなDevRelに関するところに関わるですね、エヴァンジリストとかアドボケイトとかコミュニティマネージャーとか、あとマーケターの方とかですね、そういった方々が集まってコミュニケーションしたり、情報交換するといったコミュニティになっております。
もしですね、DevRelに関わっているよという方はですね、公式サイトがありまして、DevRel.Tokyoというサイトをですね、そちらの方からスラッグに参加することができますので、ぜひ参加してみてください。
そこまでじゃないよという方はですね、Xアカウントがあります、atDevRelTokyoですね。そちらの方で普段、SharpDevRelJPっていうハッシュタグでツイートとか投稿とかしてますんで、ぜひウォッチいただけるといいかなと思っております。
今日はですね、148回目というところで、もうすぐ150回ですね。あと2回なんで、じゃあ2月の頭が150回記念かもしれないですね。
今日は私の技術選定案となっております。何かのプロダクトであったりとかですね、サービスを選定するときにどういった観点をですね、重視して採用とかですね、逆に採用しないといったところを決めているかというところをですね、ぜひ教えていただければと思っております。
そちらはですね、多分6時過ぎですね。まだ30分以上ありますんで、今のうちにですね、ぜひぜひ皆さんの技術の選定案に関するところでコメントいただければと思っております。
DevRel Meetup in Bangaloreの振り返り
それまではですね、最近のDevRel周りのニュース取り上げていこうかなと思うんですけれども、まず最初はですね、私が先週インドに行ってたんですよね。
1月の20日の土曜日がですね、DevRel Meetup in Bangaloreっていう私がやってるコミュニティがあるんですけれども、そちらの方を第4回、第5回かな、第5回を開催してきたというところで、そのちょっと振り返りというかですね、雑貫みたいなのを共有できればなと思うんですけれども、
まず最初にお伝えしたいのがですね、meetup.comっていうサイトでそのDevRel Meetup in Bangaloreやってるんですけど、最初、一番最初はコロナ禍前にイベントをやってたんですね。
で、その時は本当にそんな人来てなくてですね、ファストで見るとどれぐらいだったかな、たぶん一番最初で25人登録になってるんですけど、全然そんなに来てないですね。
たぶん全部で7、8人ぐらいとかだったと思うんですよね。全然少ない人数で始めたんですけど、その後、第2回目がコロナ禍でずっとできなかったんで、第2回目が去年の6月にやったんですね。
で、その時が135人登録してるんですね。最初の人数と全然違うんですけど、135人ガーって増えて、この時はたぶん25、6人ぐらいですかね。
なので、135人登録して25、6人なんで6分の1ぐらいって考えると、せいぜい18%ぐらいっていうことですかね。そんなもんの参加率でしたと。
で、その後9月にもう1回やってて、9月が196人登録してるんですね、参加登録。なので200名弱登録してるんですけれども、この時がたぶんこの時も30人ちょっとぐらいですかね。
なので、やっぱり6分の1ぐらいとかの参加率っていうところで、もうほんとね、どんだけ人が登録しても全然お前ら来ねえじゃんみたいな。そんなような気がしてたわけですね。
で、今回ですよ。1月20日、参加登録人数ついに300人超えましたね。確かね301だったかな。301登録してるけど、けどどうせ来ないやろみたいな感じのところがあって、会場はコミュニティメンバーの人のところの会社のやつを借りたんですけど、
結局70人弱ぐらいですかね。300人登録してて70人弱ってことは23%。そんなもんなんですよね。
これ結構リマインダーとかもちゃんとやったりとかして、そんなもんだったんですけど、でもどうせこんな来ないやろみたいなところもあったりとか、会場のキャパが全然読めないところがあって、もう当日みっちみちでしたね。
もうインド人いっぱいみたいな。椅子もほんとギリギリ、そのデスクにある備え付けの椅子全部引っ張り出して全部並べて、それだけでも足りなくて会議室に入ってた椅子とかも全部取り出してそれで座ってもらって、さらにちょっと奥の方にあった2人掛けのソファーを取り出して並べたりとか、
クッション持ってきて並べたりとか、なんだったらエレベーターホールのところにあったよくわかんないプラスチック製の椅子とかも引っ張り出してきて、なんとか全員座った。全員座ってないな、私は座ってなかったからな。
そんな感じのギリギリの中でイベントができたという感じですね。インドの特性なのかちょっとわからないですけれども、結構イベントやってる最中にどんどん人来るんですよね。
もう全然時間守らないので、時間守らないって言うとちょっと語弊があるんですけど、結構みんな自由度が高い参加の仕方をするので、イベントやってる最中にどんどん人が入ってきて、どんどん席足りなくなってみたいな感じになってましたね。
あとインドの特徴なのかわかんないですけど、セッションが終わった後のコミュニケーションがめちゃくちゃ長いんですよ。いつまで経っても終わんないみたいな感じで。
今回インドにファインディーのスグさんという人が今赴任してリサーチとかやってるらしいんですけれども、スグさんも参加してくれて、スグさんと私と喋ってたんですけど、スグさんはご家族もインドにいらっしゃるので、
1時半には帰るからみたいな、そんな約束をしてたらしいんですけど、結局コミュニケーションタイムが全然終わらなくて、2時過ぎちゃって、さすがに帰らないとまずいみたいな感じになって、私とスグさんは他のメンバーに声をかけて帰るからって言って帰ったみたいな。
全然みんな喋りたがりというか、みんなコミュニケーション能力めちゃくちゃ高くて、いつまで経っても懇親会が終わらないみたいな感じでしたね。懇親会のために食べ物を用意したりとかも全然してないんですけど、みんなとにかく喋り続けるみたいな感じでしたね。
インドはお酒飲む人がほとんどいないというか、多分いないんじゃないかな。かつベジタリアンの人が多いみたいな感じの国だったりするんで、本当なんでしょうね。お酒とか入らずにあのテンションずっと保ち続けられるっていうのは本当すごいなって思いますね。
ジャニーマンさんからコメントきてますね。23%つらすぎる。そうですね。23%は参加率から言えばめちゃくちゃ低いんで、ちょっとつらいんですけど、参加数、絶対数から言えば70人とか超えちゃうので、数の暴力がすさまじいなみたいな。そんな感じでしたね。
じゅんさんからコメントきてますね。その場で喋り続ける際の羨ましい。本当そうなんですよね。何でしょうね。
インドで普通にホテルのフロントで座っててもそうですし、空港のラウンジみたいなところで座っててもそう思うんですけど、突然人が来て別の人と喋り始めるみたいな、そういうことが普通に発生するんですよね。
たまたま知り合いだったらまだわかるんですけど、その遭遇率があまりにも高すぎて、この人たちは本当に知り合いだったのかなみたいな、そんな感じに思うんですよね。その場だけですぐに仲良くなるというか、すぐに話が盛り上がる関係性があるのかなっていう気がしたりとか。
あとインドって夏とかはめちゃくちゃ暑いので、夕方過ぎぐらいからみんな活動を始めるんですね。広場みたいなところがあって、そこに毎日屋台みたいなやつが出てるんですけど、そこにみんな夜な夜な集まって、朝までずっと盛り上がって喋って楽しんで踊ったりとかしてたりするんですよ。
その時もお酒とかなしで、そんだけ盛り上がれたりとかするとか。
あと、私の知り合いでバドーダラっていう地域に住んでる人がいるんですけど、その人をいわく地域の住民がみんな夜になると橋に集まってくるんですよ。
道路っぺたの橋があって、そこのところにみんな車止めて、みんな元気いいみたいな感じで、その橋に集まってくるって言って。
実際、車で案内してもらってたときに、そこの橋のところにいっぱい人がたむろしてて、みんな喋ってて、何やってんだろうって聞いたら、夜になるとみんなそこに集まって喋るんだよねみたいな。
言ってて、その橋の下の方見たらワニがいるんだよねとか言ってたんですけど、そんなデンジャーなところで喋るなとかって思ってたんですけど、
そういうコミュニケーション能力が日本人と比べると結構アンチな感じで面白いなと思いましたね。
はい。
じゅんさんからもう1個来てますね。インドからの留学生もそんな感じだったことを思い出した。そうなんですよね。
あと今回面白かったのは、デコトラみたいなバスがあって、あれなんかこう、すごい電飾がすごい派手なトラックかなんかだなと思ったら、バスなんですよね。
バスの中に電飾がいっぱいありすぎて、そこがダンスホールみたいになってるんですよ。実際中で人が踊ってるんですよ。バス動いてるんですけど。
ちょっと動画にも撮って、それXに投稿したのかなと思うんですけど、すごいですよね。動いてるバスの中で煌びやかな電飾が輝いてて、みんなが踊ってるみたいな、そういうカオスな感じでしたね。
はい。というところでですね、今回DevRel Meetup in Bangaloreは第4回目っていうところですけど、300人ぐらい集まったんで、参加者登録はね、300人ぐらい集まったんで、十分なんじゃないかなというところですね。
日本の人もね、ぜひ来てほしいなっていうアナウンスしてたんですけど、何人かは興味ありますとかって言うんですけど、興味あるっていう割にはね、みんなインドに来ないんですよね。何なんでしょうね。
みんなインドに興味があるのに、いざ来れるっていうタイミングになるのがヘッピリ腰になるんですよね。あれ不思議ですよね。みんな何をそんなに怖がるんだろうって。めちゃくちゃ面白い国なのになって思うんですけどね。
ぜひぜひですね。次回は多分4月ですね。大体3ヶ月おきに1回やったりするんで、DevRel Meetup in Bangaloreの5回目は多分4月にやるんじゃないかなと思うんで、もしですね、皆さんインドに興味があるという方はですね、ぜひ参加してみるといいんじゃないかなと思いますね。
ファインディーの、さっきちょっと言ってたSUGさんっていう人も、来ないとわからない部分がすごくあると。
日本と社会インフラの仕組みとかが結構違うので、日本のファインディーの方に要望をあげても、いやそれいるの?みたいな話になったりする場合があるらしいんですよ。
でも、それはインドにいると、それ絶対必要だよねみたいな。それないと生活できなくないみたいな感じの話になるんですけど、なかなか日本側からそれは理解してもらえなくて、1回は社長とかに来てもらって、それで実際に体験してもらった上で、評価を得るみたいな。そういうこともやったっていうふうに言ってましたね。
そんな感じで結構来ると、インドに行くと生活習慣が違いすぎて、なかなか新しい発見というか、新しい体験ができるから楽しいんじゃないかなと思いますね。
DevRelの生産性を上げるツール
というところで、DevRel Meetup in Bangaloreの話はそんなところで続いてなんですけれども、これはDev.toの記事ですね。
13 Tools for Increased Productivity as a DevRelということで、DevRelの生産性を上げる13ツールという記事ですね。
DevRelに役立つツールを紹介してくれています。
記事を紹介するでお勧めのツール
そんなにDevRel完全に特価型みたいな感じではなくて、普通のマーケティングにも使えるようなツールとか色々あるんですけれども、有名なところだとNotionがまず紹介されてますね。
Notionは普通というか、皆さんご存知かなというところで、あとは私も使っているToDo Listかなっていうタスク管理ですね。
あとは、Daily.Devですね。
これも何でしょうね、Daily.Devって他のサイトを紹介してるのかな。
日本で言うと何だろうな。
テックフィードさんみたいな感じですかね。
そういうサイトがあるんですけど、そことかですね。
あとは、これ知らなかったな。
Roomっていう、これは知ってはいたな。
でも、使ったことがなかったんですけれども。
動画作るソフトだと思いますね。
Roomっていうソフトですね。
多分これは動画の中で自分のWebカメラを丸く加工して表示したりできたりするやつですね。
チュートリアルの動画とか作るのに便利だよということで紹介してくれていますね。
あとはDallyですね。
Dallyも有名かな。
あとはRunwayMLっていうやつで、これはソフトなのかな。
ちょっとわからないんですけれども。
静止画に動きをつけるために使っているということですね。
記事のバナーをより面白く見せるために使えるツールというふうに書いてありますね。
ちょっとリンクがなくてもわからないんですけども。
RunwayMLというソフトを紹介して。
ソフトなのかな、プラグインなのかな。
ちょっとわからないんですけれども紹介してくれてますね。
あとはGrammarlyとか、スーパーパワード。
スーパーパワードっていうのはAIノートメーカーらしいですね。
スラックとか、repurpose.ioっていうサービスですね。
これは縦型フォーマットの動画を再利用するのに使える。
ソーシャルメディアに投稿したりとか、
あとはそれを自動化したりするのに使うことができる。
repurpose.ioというサービスですね。
あとはメトリクール。
これもソーシャルメディアの投稿のスケジュールを管理したりとか、
それのPVとかを見たりするというのに使えるということですね。
メトリクールというサイト。
これはサイトですね。
そういった全部で13個。
スラックとかノーションとかも含め紹介してくれているので、
DevRelに関わっている方はこれ見てみると面白いんじゃないかなと思っております。
DevRelに関係する記事とメンターシッププログラム
あとですね、これがあったな。
Building Bridge Between Code and Community Developer Relationsっていう。
これもDev.toの記事ですね。
これをなんで紹介するかっていうと、
一番最初のところにMoonGiftによればっていうふうに書かれててちょっとびっくりしたっていう。
それだけそこから始まったんですけれども、
コードとコミュニティの架け橋っていうところの記事ですね。
MoonGiftによればDevRelとは自社とか自社製品と開発者が相互のコミュニケーションを通じて
良好な関係性を築くためのマーケティング手法と書かれているというふうに紹介してくれてますね。
この中で面白いのはですね、DXメンターシップっていうサイトですね。
ここを紹介してくれてるんですね。
もしかしたらこの記事書いてくれている、これはアラファト・レイ・ボラっていう方なんですけれども、
その方のサイトなのかもしれないですけれども、DXメンターシップっていうサイトです。
これはですね、デベロッパーリエーションのメンターシッププログラムらしいです。
3ヶ月間のDevRelを学べるコースというかメンターシップを取ってくれるサービスらしいですね。
こういうのも出てきたんだっていう感じがして、なかなか感慨深いものがありますね。
このサイト自体はちょっとあんまり見てなかったんですけれども、
デベロッパーアドボケイトのキャリアを充実したものにするための知識と情報を身につけましょう。
業界の専門家や実際の現場を想定した講義を受け、憧れの仕事に就くための準備をしますと。
そういうことね、ってことは多分期間が募集期間とか決まってる感じですね。
今は応募するボタンがまだ使える状態になってて、違った、今ちょっと閉まってるみたいですね。
DevRelメンターシップ for Dev Advocatesっていうやつなんですけど、今ちょっと募集はしていないようです。
多分またそのうち始まるのかな。
去年の11月の23日から12月の7日までっていうとこなんで、2週間ぐらい募集したみたいですね。
今までに8人ぐらいの方かなが受講されたというふうに書かれてますね。
こういうDevRelを学べるプログラムですね。そういうものもあったりするということですね。
まさかりを受け止める方法と指摘への対応
では続いてですね、この記事もちょっと紹介したかったんだよな。
これはですね、レバテックラボの記事で、飛んでくるまさかりをどう受け止めるか。
この方の名前が何と読むんだろう。
加納さんなんですけれども、たけしさんか、加納たけしさんですね。
飛んでくるまさかりをどう受け止めるか。
加納たけしが実践するアウトプットを守る参加状という記事ですね。
これちょっとタイトルだけで反応しちゃうのはあれなんですけど、
まさかりって今、通じる言葉なんですかね。
Devとかが流行ってた時期とかは、まさかりって普通に使われてた気がするんですけど、
今もまさかりって使う言葉なんですかね。
アウトプットをする時の悩みとしてよく聞くのが、
アウトプットをしたいが、まさかりが怖くてできないということですと。
そもそもまさかりとはというところで、
IT業界で言うまさかりやまさかりを投げるとは、
鋭い技術的な指摘や突っ込みの意味で使われていることが多いようですと。
正式な用法ではなくネットスラングであり、
ここ10年ほどで使われるようになった言葉のようですというふうに書いてありますね。
まさかりを受けないために何ができるかということですね。
多分これが参加状書いてあるんですけれども、
まず一つ目、可能な限り公式ドキュメントの情報を掲載するということですね。
アウトプットの受け手が望んでいるのは、発信者の主観や思いではなく正しい情報です。
紹介している技術の根拠を示すため、技術の使用書や開発者のブログといった
一時情報をできるだけ漏れなく記載するようにしましょうと書いてありますね。
続いて2つ目、攻撃的な表現をしない、煽らない。
攻撃的な表現や煽りをしてしまうと、受け手の感情的で攻撃的なまさかりを誘発してしまいますということですね。
これは大事なポイントですね。
3つ目、内容に誤りがないか何度も遂行すると。
地道なことですが、本当にこのアウトプットは正しいのかを
時間をかけて何度も見直しますということですね。
続いて4つ目、完璧なアウトプットなどないと開き直ると。
完璧なアウトプットなどないし、どんな表現をしたとしても
まさかりは飛んでくるときは飛んできますということで
正しくて分かりやすいアウトプットを行うために最大限の努力をしたら
あとはもう開き直るようにしていますというふうに書いてありますね。
まさかり対策のためにやっていることとして
ChatGPTで遂行するということを書いてありますね。
レビューとしては、誤ったことが書いてあったらそれを指摘してくださいとか
誤字・脱字があったら指摘してくださいとか
より分かりやすい内容があればそれを提案してくださいとか
そういったところを書いて文章を遂行してもらっているということですね。
面白いのは登壇スライドもChatGPTで遂行しているということですね。
そのためにはいわゆるバイナリで作るようなパワーポートだったりとか
キーノートではなくてマークダウンベースでスライドを作って
それによってテキストベースなどで検証しやすい
ChatGPTに遂行してもらいやすくなるということですね。
まさかりで心が折れないために私がやっていることというところで書いてあるのが
指摘が正しければまずそれを謙虚に受け止めて記事を訂正したりとか
あと登壇資料の補足として発信しますということですね。
指摘した人に感謝することも忘れないようにしますということですね。
大切なのはまさかりを受けたときの自分の反応です。
鋭い指摘を受けたときその鋭い言葉であったり
自分の間違いを指摘されたことの恥ずかしさであったりで
一時的にネガティブな思いを持ってしまうこともあるでしょうと。
その負の感情を持ち続けたり執着したり
反応してしまわないことが大事ですということですね。
一冊なんか本を紹介してくれてますね。
これは反応しない練習あらゆる悩みが消えていく
ブッダの超合理的な考え方という書籍ですね。
この書籍の中に書いてあるのが
怒りや苦しみは反応すればするほど大きくなってしまう。
妄想にとらわれず目の前の現実をありのままに受け止め
集中することが大切というふうに書いてあるらしいで。
あとは悪意ある攻撃は無視すると。
気をつけなければならないのは
まさかりのフリをした悪意のある攻撃です。
一見すると正しいことを指摘しているように見えて
実は攻撃したいだけの人がいます。
一例として私は次のような内容を言われたことがあります。
記事の内容は読んでいないがこれはPV化石の記事だとか
これ記事読んでないじゃんって思うんですけどね。
こんなことを書くブログは潰れてしまえとか
これはひどいですね。
これは単純にあれですね。ただの悪意ですね。
そういった悪意ある攻撃してくる人を
自分の視界に入れない工夫が必要ですというところで
Google Chromeの機能拡張ですね。
You Blacklistを使ってそもそもそのドメイン自体
弾いてしまうということですね。
これもいいですね。
あとこれは最後なのかな。
体を鍛えて心を強くするというのが書いてありますね。
筋トレのおかげでメンタルが安定しているということがありますね。
大抵のことは筋肉で解決できるというのは
よく知られているところですよね。
どうなんでしょうね。
ジャニー・マサカラコメント来てますね。
マサカリもう通じないの?使っている現場見ます。
全然すまない。
マサカリという単語がもうちょっと古いのかなと思ってしまっただけで
全然通用しているのであれば問題はないと思いますね。
マサカリどうなんだろうな。
どういう時にそういう攻撃を受けるんだろうな。
思い込みというか発信側の方も
若干の思い込みというとちょっと語弊があるのかな。
発信の仕方に断定的すぎる部分があったりとか
他者を煽るような別なプロダクト
例えば自分がとあるプログラミング言語が好きで
別なプログラミング言語は劣ってるみたいな
書き方とか私はこのフレームワークが好きで
こっちのフレームワークよりもこういうところがいいんだ
そういうような書き方をしてしまうと
それに対して反発する心を出してしまう可能性はあるのかなって
思ったりしますかね。
なので何でしょうね。
スラド終了とMoonGiftの更新停止
この発信の仕方とかテクノロジーニュートラルな内容であれば
そんなに反発って招かないのかなっていう気がするんですけどね。
では続いてですね。
これも取り上げておかないとなというところで
これはスラドが終了したというのがですね
ITメディアさんの記事になっております。
スラド終了。
スラッシュ.ジャパンから23年の歴史に巻くという記事ですね。
23年ですって。
23年ってことは2001年からサイトがやっているということですかね。
前身はスラッシュ.ジャパンで今はスラドっていうやつですね。
VA Linux Systemsが運営していたニュースサイト
スラッシュ.の日本語版として
2001年5月日本法人が正式にオープンしたサイトですね。
本当に懐かしいというか
何でしょうね。
いわゆるフォーラム文化を作ったサイトなのかなっていう気がするんですけれども
結構このサイトもさっきのまさかりじゃないですけど
尖ってたような気がしますね。
荒れ毛な人みたいな感じのね。
荒れ毛ってなんだろうみたいな感じだったんですけど
すごい懐かしいですね。
うちの私がやってたMoonGiftっていうサイトがあったんですけど
それが終了したときにもこのスラドで取り上げてくれてたんですよね。
たぶん今もあるかな。
スラド。MoonGiftとかで調べるとあったあった。
オープンソースソフトウェアの紹介サイト
MoonGiftが7月で更新停止っていう
これ2021年の6月のときに取り上げてくれているんですよね。
本当にありがたい限りで。
コメント全然見てなかったんであれなんですけど
オープンソースソフトウェアをほぼ毎日紹介してきたMoonGiftは
6月の24日ですね。
6月の24日に7月16日でサイトの更新を停止する方針を発表した。
発表記事によるとMoonGiftは2001年1月29日から運営を開始
現在までの20年間に1万6000本以上のソフトウェアを紹介してきたという
しかし2015年に執筆者がDevRelをサポートするビジネスを開始したことが
転機になったようだと。
MoonGiftとDevRelの両輪で活動を続けるのではなく
企業並びに事業運営者としてDevRelに注力するべきだと
判断したことから更新停止を決めたとしている。
これまでの記事に関しては将来的に静的コンテンツ化する予定だとしている
というふうに書いてくれてますね。
一番上にあるコメントがDevRelという単語は初めて聞いた
マーケティングの人たちはよく次から次に色々思いつくもんだと
いうことですね。
それに対するコメント。マナー行使みたいなもんかとか書いてありますね。
これはいいや。
10年くらい前、RSSリーダー全盛期に見てたな。
確かにRSSリーダーありましたよね。
懐かしいな。今DevRel周りの記事を
Feedlyというサービスでウォッチというか登録はしてるんですけど
ありましたね。もうRSSリーダーがっつり消しちゃったな。色々。
高度してたやつ。懐かしいな。
ダブライムテキストの記事とか見て使ったりしてたわ。
途中から記事を有料化とか何とか言い始めてそれきり見てなかったわ。
デジタル遺産。閉鎖ではなく更新停止ということで
静的サイトとして残すという判断を商算したいと。
動的サイトをどうやって構成に残すかという一つの見本になると思うから
注視しているということですね。
そうですね。このスラドで言われてた時に
この記事を探そうと思って調べたら
ムーニフトのサイト消えてんじゃんみたいな感じの意見があって
調べたらDNSの設定をミスってて消えてたんですよね。
多分明日あたり復活します。
DNSの設定直して一回証明書が剥がれちゃったので
今ファイアベースで証明書を貼り直してるはずなので
それが出来上がればまたアクセスできるかなと思ってますね。
そうですね。もともと動的っていうほどじゃないですけど
ワードプレスとレールズ組み合わせたようなサイトだったんですけど
静的なコンテンツに全部変換して
ファイアベースホスティングに今載せてる感じですね。
なのでこのスラドが全部コンテンツ消えちゃうらしいんですよね。
それがすごい残念だなって思うんですよね。
1月末にはサービスを停止してしまうということで
データが消えてしまうらしいです。
このVA Linux Systemsがスラド
スラッシュ.ジャパンっていうやつを運営してたんですけど
一緒にやってたのがソースポージュ.JPっていうやつがあったんですよね。
これもすごい昔からあったやつで
いわゆるオープンソースのソフトウェアをリポジトリ提供してくれるようなサービスですね。
今で言うGitHubみたいなものなんですけれども
そういうソースポージュ.JPっていうのがあって
それネーミングが一回変わってOSDNっていうやつになったんですけど
さらにそれがOSDNがアピリッツっていうところに授業が譲渡され
さらにアピリッツが中国のOSChinaっていうところに譲渡されたりとかして
その中でスラドの移転とかもいろいろあったみたいなんですけれども
うまく譲渡ができずに今回閉鎖するということに決まったらしいですね。
この関連記事のところにDPZの話とかもあったりするんで
いや何でしょうね。昔からやってるサイトとかを継続的に運営し続けるってほんと難しいですよね。
自分のところもMoonGiftも辞めてたりするんで
なかなか難しいなって思いますよね。
ずっとこう続けている方って個人でやっている方もいれば
企業でずっとやっていたりする場合もあったりすると思うんですけど
なかなか大変ですよね。
というところであと1個ぐらい何かあるかな。
面白いのは
レプロのテックブログと解約したお客様へのインタビュー
これね。これもぜひ紹介しておきたかったんですよね。
これはですね。レプロのテックブログで
解約したお客様にインタビューしてプロダクトの企画に生かすまでという記事が出ております。
これね。本当にお勧めしたいんですよね。
ぜひぜひこうやっていくべきだと思うんですけど
なかなかできないっていうのはね。それもわかるんですよね。
でもこのレプロさんではですね。解約したお客様にむしろユーザーインタビューしてですね。
どういう機能がないから解約に至ったのかとか
どういう点に不満点があるから解約したみたいな。
そういうのを聞いているということですね。
それによってですね。
ヒアリング結果と合わせることによって
より多くの企業が求めており
より多くの損失を生んだ機能はどれかというのを可視化していくということですね。
なかなか他のうちでサポートしているところとかにも
こういうのをやった方がいいですよって言うんですけど
なかなかやるの難しいですよね。
これを実際に実践していくっていうね。
だって契約切れてますからね。
契約切れている元お客さんに対して
なかなかインタビューしていくっていうのはね
勇気がいることかなと思うんですけれども。
でもできることであればですね。
これはやっていくべき施策なのかなという気はするんですよね。
ちゃんとその聞く相手によってですね。
内容を変えたりとかも設計もちゃんとしているということですね。
インタビュー相手の役職などによっても質問を変更します。
例えばツール導入の決済権のある方と施策実行する方では
ツールに対する考え方が異なります。
前者の方決済権がある場合ですね。
その方に対してはなぜそのツールを導入したのかとか
事業戦略上どのような効果を期待しているのかなどを聞いたりすると。
一方で実際施策を実行する運営側の運用側の方ですね。
その場合にはより具体的な施策の内容や業務フロー
実際のツールの使い勝手などを聞いているということですね。
結構それによってインタビューによってですね
いろいろ項目が出てきてですね。
それを分析することによって
支柱とかあと解約とかですね。
そのあたりを機能ごとにカウントしていくと。
例えばこれは架空のデータですって書いてあるんですけれども
コミュニケーションチャンネルに対して不満を感じる方がとても多かったとかですね。
データ管理に関するところで機能が足りていない場合もあったりしたとかですね。
そういうのを可視化していくことによって
どういった機能を開発していくべきかっていうのを決めていくと。
実際使っている方から得るフィードバックっていうのも当然必要なんですけれども
そういう使わなくなった方からのフィードバックっていうのも
とても大事かなという気がしますね。
これなかなかできないと思うんですよね。
本当に実践されててすごいなって思いましたね。
そんなレプロさんのですねテックブログですね。
非常にためになるというか参考になるかなと思うんで
ぜひご覧いただければと思いますね。
この辺りってね結構感情論というかですね
自分たちはプロダクトをいいものを作ってるとか
いいものを提供してるって思い込んでるし
思ってて当然だと思うんですけど
それに対してね、なかなかこう使わなくなったとか
契約終了みたいな方の思いってズレが大きかったりとかするんで
難しい部分もあるかなと思うんですけど
なるべくその冷静な目で見ていくのが大事かなという気がしますね。
ということでですね。
XR技術の技術選定と未来への展望
続いてなんですけれども
今日のメインテーマの方ですね。
私の技術選定案の方に入っていきたいと思います。
今日は3件くらいですね。
いつもよりちょっと難しいテーマかなという気がしたんで
そんな多くないんですけれども
順番に紹介していければと思います。
まず最初がですね。
DevRelネームさっぽろのじゅんさんからですね。
いつもありがとうございます。
XR技術を広める立場として
技術選定に関して気にしていることは
開発環境の構築が簡単なプラットフォームを選びたいということと
ユーザーが多くて技術情報が多く存在することですと
最近のARガジェットのコンテンツは
Androidアプリを作る延長上で作れることが多く
だいぶ取り組みやすくなったと思っています。
また家電量販店でも買えるようになり
購入もしやすくなりました。
私の主観ではこの領域の技術ブログは
2018年に最もたくさん回っていましたが
最近は減っているので
なるべく参考資料のOEガジェットで取り組むのがいいでしょうと
同時にXR技術の未来を見たい立場としては
上の前述の逆で
クラウドファンディングなどで
ニッチなものを探して支援してみたりしています。
開発しにくさはあるものの
大衆向けガジェットにはついていない
センサー情報などを扱える可能性があります。
数年後の一般向けガジェットに搭載されるかどうか
触って吟味するのも楽しいですときています。
両面ありますよね。
実際これからXRに触れていきたいという方であれば
XRデバイスの体験とクラウドファンディング
先に上がっているような開発環境の構築が簡単かどうかとか
あとはユーザーがすでに多いかどうかというのは
大事な点になってくるということですね。
あとここに書いてある
Androidアプリを作る延長上
これもねスマホアプリやっぱり
自分がスマホを持っていたりするので
学生とかもね自分の手元のデバイスで動かせるかどうかって
結構大きいですよね。
なんとなくVRとかってパソコン上でやっててもね
シミュレーターとかで2つに分けて表示されても
なかなか実感湧きづらかったりとかするんで
スマホとかで実際自分の目の前でコンテンツを展開できると
楽しさはあるというか
実感が湧きやすいのかなという気はしますよね。
ただ逆にその未来を見たい
広めていく方の立場としては
クラウドファンディングとかでニッチなものを探して
支援したりとかするということですね。
iPadしにくさはあるもののって書いてあるとね
なかなかね
私もどうなんだろうなこの
Oculusの一番最初の
なんでしたっけ
VRじゃない
DKか
一番最初多分DKみたいなやつだと思うんですけど
そこから買ってはいるんですけど
コンテンツアプリがすごい
作るのが難しく感じちゃうんですよね。
その結果として
デベロッパーとして楽しむっていうところが
個人的にはXRについてかなり失われちゃったな
っていう気がするんですよね。
Oculusのメタ2でしたっけ
クエスト2
今3だったと思うんで
その1個前の2とか買っても
コンテンツ作ってないんですよね
アプリ全然作ってないんですよね。
遊ぶ側
VRチャットであったりとか
いろいろゲームあったりとか
ホライゾンなんとかでしたっけ
ああいうので
本当に使う側に回っちゃってるんですよね
デベロップするの
難しいなみたいな感じになっちゃってるんですよね
ジュンさんからコメントきてますね
Diftかな
そうですねDift
ありましたよね
パソコンとつなげて
ケーブル長い状態で
やんなきゃいけなかったりとかして
すごい作るの大変だった思い出がありますね
最近のやつは
一体型ゴーグル自体が
Androidベースなのですよね
そうですよね
メタも
メタクエストも
Androidですよね
コンテンツ
作るのね
XR本当に難しいですよね
Unityとかでね
作れるようになってるんで
その意味では
楽になってる部分もあるのかな
という気はするんですけれども
一回ね
ちょっとそのDiftの時に
半分心が折れちゃって
そっから
未来は感じてるんで
デバイスとか楽しめるんですけど
ちょっとね
開発の方に入るのはね
難しいんですよね
なので
じゅんさんみたいに
クラウドファンディングとかでまだ
そういう未来の部分ですね
開発しにくさも感じながらも
手出しできるっていうのは
本当に羨ましいなって思ったりしますね
なんでしょうね
別にこれはXRとかの
そういうやつだけじゃないんですけど
サービス
新しいサービス作って
最初に認知度を獲得しようとするのって
個人的にあんまおすすめしてないんですよね
DevRelの時に
なんでかっていうと
最初にそんな品質が高くない状態で
いろんな人に見せちゃうと
その人がサービス見た瞬間に
あれなんかいけてねえなと思って
離れちゃうと
戻ってきてくれないんですよね
最初の擦り込みで
そのプロダクトあんまいけてないな
っていう思いができちゃってるんで
そこからどんだけ改善したとしても
なかなか戻ってきてくれないと
いうところがあったりするんで
なるべく最初は
そんな大量のユーザーを持ってこずに
ある程度密にコミュニケーションできる状態の
ユーザーを何人か連れてきて
まず使ってもらうと
改善されてある程度の品質が担保できたら
それからユーザー集めればいい
っていう風に言ってたりするんで
これねほんとね
XRまるっきり僕逆だったんですよね
最初にそこでこう
失望したというか
難しいって思っちゃったのが
そこが一番大きい失敗だったかなって
個人的に私は思ってますね
っていうところで
では続いて2人目ですね
デブレルネーム
西から来た馬面の男さんですね
いつもありがとうございます
個人で使うものに関しては
知り合いのおすすめに
左右されやすいかもしれませんと
アプリや書籍 ガジェットなど
知り合いが使っているからという理由で
採用していることが多いです
会社で使う技術は
感度の高い社員がおすすめしているのを
軸に検討が進み導入しています
海外から情報が入ってくるパターンが
多い気がします
AWSにしてもスラックにしても
その他 他サース系ツールにしても
海外のプロダクトだったりするので
割と早い段階で
社で導入されている気がします
エンジニア界隈で会話するときも
ああそれねと連発に
日本企業と海外プロダクトの選択
話題についていけた経験があります
ということですね
そうですよね
何でしょうね この
海外のプロダクト
っていう風に書いてくれてますけど
多分これ海外っていうか
いいとこ多分
西海岸の
アメリカの西海岸の話のような
気がするんですよね
サンフランシスコとか
言うてや あとニューヨークとか
何でしょうね
プロダクトのコンセプトの作り方が
うまいんですかね
マーケティングが上手なのかな
という気がしますね
見せ方なのかな
そんなね
日本のプロダクトがそんな悪いとは
思わないんですけれども
やっぱその何でしょうね
英語圏のプロダクトの方は
選ばれやすいんですかね
AWSにしても
Slackにしてもということですね
確かにな
その後
何かこう
真似したような
プロダクトが
日本でできたとしても
やっぱそれってもう
何か周回遅れ感は
出ちゃってるのかな
っていう気はしますよね
ちょっと先に
先ほどの
XRのデバイスに関するところですね
じゅんさんからコメントきてますね
生垣体験と界隈では呼ばれています
これ分かるな
生垣体験ですね
まさにね
1回でも当たるとね
もうたまたま運が悪かっただけだと思うんですけど
1回でも生垣で当たった体験をしてしまうと
その後から生垣食べれなくなるっていうのは
確かにあるような気がしますね
インドの腹痛とかも似たような感じですかね
私当たったことないんで
全然大丈夫なんですけど
こういう初期体験大事ですよね
ジャニーマンさんからコメントきてますね
生垣って大事ですね
そうなんですよね
本当に生垣の体験が悪いと
卵から帰った時の親を見た
何でしたっけ
アヒルとか
それもそうだと思うんですけど
一番最初の見た時の体験が悪いと
本当にそれ引きずられるので
注意が必要だと思うんですよね
大量の人たちに対して
最初に悪い体験を与えてしまって
その人たちが会話の中で
これこれのプロダクトって良くないよね
みたいな感じで言うと
どんどんそれが膨らんじゃって
改善しても改善しても
なかなかひっくり返せなくなってしまったりするんで
生垣体験は最高のものを
最初に提供しないといけないと思いますよね
西から来た馬面の男さんの話に戻ると
個人で使うものに関しては
知り合いのおすすめに左右されやすい
機質かもしれませんって書いてありますね
これは私もそうなんですよね
書籍とか特にそうかもしれないですね
アプリはそこまでじゃないかもしれないですけど
ガジェットもそうかな
私特にね
山崎渡さんのおすすめに
左右されること多かったんですよね
最近はそんなでもないかなっていう気がするんですけど
何年か前とか
渡さんがおすすめするといいんじゃねーみたいな感じで
買っちゃったりとかしてましたね
あとあれか
小田翔さんのおすすめにも結構左右されるかな
彼のおすすめはね
ちょっと金額がとんでもなかったりする場合もあるんで
その場合はさすがに避けるんですけど
何でしょうね
一定のフィルタリングをしてる
指揮者の人がおすすめしてくれてるんで
まあいいかなみたいな感じで
買っちゃったりとか採用しちゃってる場合は
多かったかなって気がしますね
なので私もこれは西から来た馬面の男さんと
同じ感じですね
会社の場合は
でも会社の場合も同じみたいですね
感度の高い社員がおすすめしているのをまず
軸に検討を進めていくということですね
あとは海外から情報が入ってくるパターンが多いっていうね
この辺りってどうなんでしょうね
日本企業でその
ある程度感度の高い人であれば
英語の情報でも取り入れていくイメージあるんですけど
その後運用になった時って
英語に対してストレスを感じる方がいても
問題なく導入できるんですかね
そこら辺は私は逆に
うちの場合は全然社員とかいないので
私が勝手に決めてるんで
気にしたことないんですけど
それ以外の会社さんってどうなんでしょうね
顧客要件の満たす選択と提案
英語のドキュメントしかないよみたいになった時に
どのぐらい皆さんストレスなく導入してくれるのか
ちょっと気になったりしますね
はいでは続いてですね
デブレルネームジャーニーマンさんですね
いつもありがとうございます
業務視点でお答えしますと
住宅開発がメインだと
顧客要件を満たせるのか
予算に合うかが必須なので
他の観点が入りにくいと感じます
でもこれ大事ですよね
そもそもその顧客要件を満たせるのかどうかっていうところの
設計が難しいですよね
シームレスに連動しやすいクラウドサービスで検討したが
重要な要件を満たせず
サードパーティーのサービスになるケースもあります
また最新バージョンより実績があり
具合が収束傾向にある一つ前のバージョンを選んだりします
そういう場合もあるんですね
ただ保守的な選択だけでなく
一般利用開始いわゆるGAですね
GAが発表されすぐにご提案して採用されるケースもあります
お便りを書いていて改めて関係するステークフォルダーが
Win-Winになる提案をしていきたいと思いました
ありがとうございました
そうですね
このAWSの場合って
技術選定案の提案
GAしたタイミングで提案するケースって結構多い印象ありますよね
結構それを取り入れてくれる会社さんも多いのかなっていう
なんでしょうね
AWSだったら許されるみたいな雰囲気あったりするんですかね
そういうブランディングの上手さなのかな
日本企業のサービスとかで
データがあってそれが外れたから
じゃあいきなり提案してみたいな感じになって
導入してくれるイメージが全然わからないんですよね
そのあたりどうなんだろう
GCPとかもどうなんでしょうね
GCP難しいのかな
最近のAzureとかだったらいけるのかな
でもIBMだといけないような感じもするんで
そういうブランディングって結構やっぱ大事な気がしますね
あとは受託開発の視点で考えると
やっぱ顧客要件を満たせるのかどうかとか
あと予算に合うかっていうのを重要視するということですね
このシステム開発って結構複雑だったりするんで
一番最初の基本的な要件は満たせるんだけど
細かい要件になった時に満たせない可能性があったりすると
結構怖いのかなっていう気はするんですけどね
どうなんでしょうね
そしてその時にサースを提供側とか
プラットフォームアザサービスを提供する側としては
どのぐらいの幅を持たせるかっていうところですよね
結構ストリクツに機能をバーって並べてしまって
ABCは達成できるけど
Dの機能がないから採用できないみたいになるのと
あとはAPIを公開してるから
その機能はないけど自分たちで開発すればできるなっていう風に
イメージを持ってもらえるかどうかみたいなところって
結構大きい気はするんですよね
なので何でしょうね
可能性を潰さない見せ方っていうのも
サービス・顧客体験のポイント
結構大事なポイントなのかなという気はしますね
特に住宅開発だったら
いざとなれば作れば大丈夫っていう風に
思ってもらえるかどうかっていうところは
提供側としては気にしなきゃいけないのかなっていう気がしますね
ジャニーマンさんからコメント来てますね
顧客体験が良くなるみたいな話はやっぱりいりますねと
技術的な話だけだとやっぱり採用されるのは難しいです
そうですよね そういうことですよね
わかります
なのでこの提供側が
その顧客体験の部分をちゃんと見せてあげないと
それを採用してくれるSIRとかベンダーの人たちっていうのも
それをお客さんにエンドユーザーに提示できないと思うので
そこのポップステップの部分ですよね
そこをちゃんと提示できなきゃいけないんだろうなって思いますね
すごくこれはためになるご意見で
参考にしたほうがいいと思うんですよね
特に日本の場合って
SIであったりとかクラウドSIみたいな
そういう分野でサービス採用してもらえるかどうかって
結構大きかったりするんで
こういう住宅開発をやられている会社さんの意見っていうのは
重視したほうがいいんじゃないかなという気がしますね
というところでですね
今日のDevRelラジオ148回目ですね
私の技術選定案の方は終了していこうと思います
次回が1月の30日ですね
そこは特に問題なくて
2月の6日が多分150回目
その次がDevRel Meetupの
今回は2月の7日はオンラインでやるというところで
名前はDevRel Meetup in TokyoになってるSI
DevRel Tokyoの89回目ですね
今のうちに直しちゃおう
DevRel Tokyo 89回目
テックブログ運営というテーマで行います
こちらはオンラインでやりますので
ぜひ皆さんご参加いただければと思っております
3月はオフラインでやります
3月は規模を拡大して
土曜日にやる計画となっておりますので
ぜひ皆さん楽しく参加いただければと思っております
ということで本日のDevRelラジオ148回目は
こちらで終了していこうと思います
また皆さん1月30日ですね
早いですね もう1月終わりですよ
あと11ヶ月しかないですよ 怖いな
皆さんお仕事頑張ってください
ではまた皆さん来週お会いしましょう さようなら
