DevRelの現状とニュース
はい、皆さんお疲れ様です。DevRel Radioの今日は168回目ですね。
ちょっと私のミスで、時間ギリギリになってしまったんで、 いつもはオープニングからやるんですけど、
今日はいきなり配信という形になりました。
ではですね、まずDevRel Radioの紹介ですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日ですね、夕方5時半から1時間程度お送りしているというものになります。
DevRelというのはですね、Developer Relationsの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を築くための マーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関する職業の方、
例えばテクノロジーエヴァンジリストとか、 デベロッパーアドボケイトとか、
あとコミュニティマネージャーとかですね、
そういった方々が集まって情報交換したり、 イベントをやっていると、そんなコミュニティになります。
はい、公式サイトがあります。 devrel.tokyoというサイトです。
そちらからですね、スラックに参加することができますので、
DevRelに関わっている方とかですね、 興味がある方はぜひスラックに参加してみてください。
で、あとはXアカウントがあります。
ハットマーク、DevRel Tokyoですね。
そちらの方で普段は、 シャープDevRelJPというハッシュタグですね、
投稿してますので、もしよければフォローなり、 そちらのハッシュタグをですね、
ウォッチいただければいいかなと思います。
はい、ではですね、そんなところで今日のメインテーマはですね、
今学んでいる、学びたいこととなっております。
テクノロジー界隈はですね、いろいろ変化が激しい業界かなと思いますので、
そんな中でですね、今こう、新しく学んでいることとかですね、
これから学んでいきたいと思っているようなことがあればですね、
ぜひ教えてくださいといった内容になっております。
今、何件くらいだろうな、3件くらいいただいているかな。
はい、まだまだですね、皆さんのご意見、 頂戴したいなと思っておりますので、
ぜひ今のうちにですね、まだ30分後ぐらいですね、 からそちらの方が入っていこうと思いますので、
今のうちにですね、ぜひ今学んでいることとかですね、
これから学びたいことも含め、 コメントいただければと思います。
はい、それまではですね、最近のDevRel周りのニュースというのを 取り上げていこうかなと思うんですけれども、
最近また何かあれですね、昨日WWDCが始まったと、 昨日というか今日ですかね、
今日の午前2時ぐらいから昨日とあったと思うんですけれども、
そこでも何かね、AI周りの話ばっかりで、 ばっかりってわけじゃないか、後半ですかね、
後半がAIの話一色っていう感じで、何でしょうね、
Appleは何て言ってましたっけ、 Apple Intelligenceでしたっけね、
ちょっと言い方を変えてきたなっていう気がするんですけれども、
スマホの次ですよね、多分、スマートフォンじゃなくて、
インテリジェンスフォンみたいな言い方も 誰かがしていたような気がしますけれども、
その次のやり方がどこもかしこもAIばっかりみたいな感じになってきてるなっていう気がするんですよね。
そのちょっと前ですよね、Google I…失礼しました。
Google IOが発表していたやつもAI周りで、何でしたっけあれは、
Notebook LMでしたっけ、あれがGoogleのラグに対する 新しい答えなのかなみたいな気がしてて、
ちょっと試してみたんですけど、 ソースが出てくれるのはありがたいんだけど、
まだちゃんと正しく答えてくれないみたいな感じはするかなっていうところですね。
あれをどれぐらい特化させることができるのかなっていうのが 結構楽しみな感じですね。
あれのAPIとか出てくれれば、それこそもうラグ使ったシステムとか 絶滅しちゃうんじゃないかみたいな感じもするんですよね。
あとはマイクロソフト系は何でしたっけね。
Devynでしたっけ、あれを確かAzure上で できるようにするみたいな話ですよね。
GitHubはGitHubで、 GitHub Copilot Workspaceとか出してて、
こないだデモを見たんですけど、 上流工程めちゃくちゃ重要になるっていう感じがしましたね。
ちゃんと日本語で仕様を説明して、 そういうのを作ってっていうふうに依頼すると、
GitHubのほうがそれを解析した上で、 じゃあどのファイルを修正すればいいよねっていうのをリストアップしてくれて、
そこでコメント書いたりとか、 ここのファイルも追加で修正してよみたいな依頼をすると、
今度多分、ごめんなさい、その前か、 まず仕様を書いて、
そうするとGitHubのほうで、 それってこういうことだよねっていうアウトラインを出してくれるんですよね。
そこでOKを出すと、今度修正対象のファイルがリストアップされて、
さらにそこでOKを出すと、 実際にコードが修正されたDIFが表示されて、
そこでOKと押すと、プルリクのメッセージを作った上で、 新しいプルリクを送るみたいな感じになるんですよね。
ほとんど開発者がやることがポチゲーになっているというか、
その割には最終成果物に対する責任だけは エンジニアにあるっていう感じがするんで、
なかなかやりづらいなっていう感じがするんですよね。
全部をAIに任せてしまうんだったら、 それはそれでいいと思うんですけど、
GitHubとしてはそれをやってしまうと、 エンジニアのためのプラットフォームじゃないというか、
エンジニアの職を奪ってしまうサービス作っただけみたいになっちゃうんで、
AI技術とエンジニアの成長
毎回確認を取るんですよね、1個1個のステップに対して。
それで、エンジニアに責任を持たせるというか、 責任分解点をそこに持っていってるっていうやり方なんですよね。
AIとか機械学習が流行り始めたときに、 医者のサポートというか、
医師の診断を全部機械学習に任しちゃおう みたいな流れがあったときに、
医者の人たちがすごいそこに対して 反発したっていう話があって、
今って結局レントゲンとかの画像があって、 それをAIに渡すと、
こういう症状が見られますとか、 こういう病変があるかもしれませんみたいな
アドバイスを出すまでにしてるんですよね。
そこに対して、医者とか技師の人が 最終的な判断を下すみたいな感じになってるんで、
ソフトウェアエンジニアとかも 同じようになっていく感じがしますね。
データを渡して、最終的な成果物みたいなものが 上がってくるんですけど、
そこに対してOKボタンを押すかどうかは エンジニアの役目みたいな。
だからエンジニアがちゃんとやろうとしていることを 正しく判別できなきゃいけないんですよね。
そのときにプログラミング言語、 素のプログラミング言語だったらいいと思うんですけど、
外部のサードパーティーのAPIとか サードパーティーのSDKとかそこに組み込まれちゃったときに、
それが正しく動くっていう保証をするのって 結構大変な気がするんですよね。
それに対して責任を負わされるのって なかなか辛いなっていうふうに思うんですけど、
でも多分もう止まらないですよね。
多分今年いっぱいにはGitHubの コーパイロットワークスペースとかも当たり前になっていくと思いますし、
来年はもっとすごいものとか出てくるんだろうなっていうふうに思うと、
この流れの中でエンジニアがどう成長していくかとか、
それに対してDevRelに関わっている人たちが どう情報提供できるかみたいなのが、
なかなか難しくなっていくんだろうなっていう気がしていますね。
DevRelコンテンツの負債と影響
小田翔さんからコメント来てますね。
眼下行ってきたと。
Vision Proのためと。
そう、Vision Proあれですよね。
もうOSバージョン2になったんでしたっけ。
まだベータでしたっけ。
そこで日本の議的が通るみたいな話になってますよね。
ソフトウェアだけで議的通せんのすごいですよね。
だからもともとハードウェアは通るものを使っていた上で、
あと日本で発売するにあたって、 ちゃんと検査を出すみたいな。
そこで通ればちゃんとOSのところに行って、 日本の議的のアイコンが出せるっていうね。
すごくいいですよね。
いくらって言ってましたっけ。
確か59万とかでしたっけ。
確かVision Pro。
プロなんでね。
明らかに人柱端末なような気はするんですけれども、
実際に何か作らないといけないですよね。
小田翔さん何か作ってんのかな。
ただ被ってるだけだともったいないなっていう気はしますかね。
最近のDevRel周りのニュースっていうところで、
これちょっと面白いなと思ったんで。
これは何だろうな。
サブスタック。
お名前が分かりづらいな。
エテルさん。
エテル・スベルドロフさんの、
エテルズサブスタックっていうブログがあるんですけれども、
そちらから題名がThe High Price of DevRel Depthということで、
DevRel負債の高値。
まあ何でしょうね。
DevRelの負債が高くついたみたいな、
そんなような意味のブログなんですけれども、
このDevRel負債っていう言い方、
これ結構初めて聞いたような気がするんですけど、
なかなか面白いですよね。
その記事の中で取り上げられてることなんですけど、
結構分かりやすいなというところがあって、
コンテンツですね。
DevRelのコンテンツに対する負債っていうところを取り上げていますと。
ドキュメントに関しては、
ちゃんとメンテナンスされ続けなきゃいけないというところがあるんですけれども、
例えば動画であったりとか、
あとブログ記事であったりとか、
あとGitHubのリポジトリとかですね、
ワークショップのコンテンツだったりとか、
それに対するコードもそうですし、
多分マークダウンのドキュメントとかも含めたりとか、
あとプラグインとかですね、
そういったものを作っていくうちに、
製品自体がメジャーアップデートしたタイミングで、
全く使えないものになると。
そういったものがあると、
どういうことが起きるのかという話で、
まず1個目挙がっているのが、
ユーザーとの信頼関係の喪失というのがあっています。
これは結構わかりやすいですよね。
やっぱりこういうプラグインがありますみたいなブログ記事があって、
その通りに導入してみたんだけど動かない。
実は製品の本体のほうがバージョンアップしてしまったがために、
もう古くて使えませんみたいになっちゃったら、
えーっていう気分になりますよね。
なのでユーザーとの信頼関係が悪化するということですね。
続いてサポート負荷の増大というのが上がっていますと、
サービスの足固め
これもあり得ますよね。
動くはずのツールで、
このブログ記事見て動かしてるんだけど動かないんだけどみたいな、
そういうこと言われる時ってあると思うんですよね。
そういう、そもそもメンテナンスコストも高くつくというのも上がってますね。
あとは時間が経つにつれて獲得コストが悪くなるということですね。
古いアセットから生まれる悪い評判は、
会社とかサービスの悪い評判よりも先行する可能性があるため、
ユーザーが採用する障壁を高くする可能性があると。
必要な時間を投資して、
それをブログ記事とかプラグインとか使おうとしてみたら失敗したみたいな人が多いと、
全体的な体験が悪化してしまって、
別な競合を選ぶという方に影響するかもしれないということですね。
とはいってですね、
問題の、それは問題な点で、
なぜメンテナンスが新しいコンテンツの開発に荷の足を踏んでしまうのか、
もう少し詳しく説明しようと。
一つは楽観主義ですね。
スタートアップの頃は製品は画期的でコンテンツも新鮮だと。
コンテンツ制作の最初の半年から1年ぐらいはコンテンツの増強とか、
効果的なチャンネルの実験とかブランドの構築に集中すると。
この時点ではメンテナンス作業というのは基本的に不要であるということですね。
最初はですね、それがうまくいっているというふうに思うので、
リーダーとかマネージャーの人っていうのは、
製品がバージョンアップしても同じことやればいいんじゃないみたいな、
そういうふうになりがちだということですね。
そうですね。
古い資産をメンテナンスするコストって本当に大きいんですよね。
ノードJSでSDK作ってて、それのNPMが通らないとか、
自分たちのプラグインが原因だったらいいですけど、
例えばリアクト使っててリアクトのバージョンが上がっちゃって動かないとか、
ビューとかもそうですし、
関連するライブラリーがセキュリティ上のリスクがあるとかですね、
そういう諸々の原因で動かなくなっていく資産っていうのは、
常に一定数存在するんですけど、
ユーザーは新しい人がどんどん入ってくるんですよね。
そういう人たちはそういう古い資産なのかどうかなんて知らないですよね、
自分が触ろうともしているものが。
そうすると、楽観主義で構えていて、
いつもにかニュービーの人たちの信頼をただネガティブにしていくだけみたいな、
そういう可能性もあるかなと思いますね。
そして、あとは知識や経験の不足というところで、
メンテナンスの価値とか、
それにそれを行う方法に関する知識が少ない場合があるということですね。
特に何だろうな、これが発生するのが、
いくつかDevRelのコンテンツ上がってるんですけれども、
ブログ記事、チュートリアル、製品ガイド、GitHubリポジトリ、
ワークショップ、デモアプリ、統合とプラグイン、ビデオですね。
この中でよく発生するというか、
メンテナンスがなかなか難しいのはビデオかな。
動画はメンテナンスめちゃくちゃめんどくさいですよね。
ちょっと差し替えるだけでできるみたいな感じではないので、
一回作ったらちょっとUI変わったんだよねって言われても、
なかなかバージョンアップするのは難しいかなという気はしますね。
ブログ記事に関して言うと、
メンテナンスはそんなに難しくはないし、
何だったら何年も前の記事に関しては事前に忠告を入れておく。
この記事は何年経ってますみたいなのを入れておくということも対応できるかなと思いますね。
チュートリアルも他のクライアントとかですっごい古くなってるやつとかあるんですよね。
結構懲りにこって、チュートリアルってどうしてもファーストインプレッションに近い部分というか、
製品をまだ触り始めて間もない人たちがちょっとワクワクしながら触れるみたいな感じでやろうと思うと、
割と凝ったコンテンツで作っちゃったりするんですよね。
画像とか使ったりとかして。
そうするとメンテナンスがもう無理みたいになりますよね。
あとはワークショップか。
ワークショップもそうですね。
GitHubリポジトリと結構ひも付いてたりしますよね。
会社のドキュメントについてはできる限り真面目に保守し、
各製品の最新バージョンを反映させるべきであるというのはあるというふうには書いてありますね。
ただこれ最近思うんですけど、
本当にそのドキュメントがちゃんと作られてないサービスって多いと思うんですよね。
本当に使い勝手悪いみたいな。
ドキュメントで嘘は書いてないんだけど本当のことが足りてないみたいなドキュメントって結構多くて、
ドキュメントが悪いと本当の意味でDXが悪くなるなっていう気はしてますね。
そんなエサルさんのブログ記事からでしたというところで、
今日ちょっと話を入れたいなと思っていたのが、
最近というかここ何年かいろんなお客さんとかのサポートをしていく中で、
多分DevRelのステージって3ステージぐらいあるのかなと思ってるんですね。
まず一つ目は足固めをする時期。
ベースを作る時期ですね。
次がアウェアネスの認知を獲得していくDevRelの時期と、
3番目がコミュニティだったりとかチャンを下げるとかカスタマーサクセスとか、
アウェアネスの認知
そういう既存ユーザー向けのファシリテーションというか手厚くサポートをしていく時期みたいな、
そういう3つのステージがあるんじゃないかなと思ってるんですね。
結構元々の2014年とか15年ぐらいとかですかね、
その頃のDevRelってついついアウェアネスの部分を知ってもらう方に重点が置かれる傾向が強くて、
新しく出来上がったばかりのサービスなんだけど、
ガンガンブース出したりとかブログ記事出したりとか、
あと書籍書いたりとかコミュニティのイベントを開催したりとか、
どっちかというと外向きの施策がすごい多かった気がするんですよね。
それ別に悪いわけじゃないんですけど、
それをやってもユーザーになり得る人が本体のサイトに来るじゃないですか。
ブログ記事見たりとかイベントで自分たちのサービスを知ってくれてサイトを訪れるんですけど、
その時にそもそもそのサイトが微妙なわけですよ。
コンセプトがよくわからないとか、
ドキュメントが過不足があるとか、金額よくわからないとか、
あとユーザー登録のフローがすごいわかりづらいとか、
アンケート項目がやたらと多いとか、
ユーザー登録が終わってすぐ使えるのかなとか、
1営業日とか2営業日待たされるみたいな。
今ゲスト来られたのでお呼びします。
はい、たいじさんお疲れ様です。
どうもお疲れ様です。
今の話聞いてました?
いや、直前までミーティングやってたんで今。
じゃあ今ちょっともう一回言うと、
ウィブレムのステージの話で、
最近3ステージに分かれるなと思ってて、
まず1個目は足固めの時期。
自分たちのサイトのところとかドキュメントの部分とかを
ちゃんと作り込むっていう時期。
2番目がアウェアレスの部分で、
ブログ書いたりとか動画でもいいですし、
外部のカンファレンスのスポンサーでもいいと思うんですけど、
認知を獲得していく時期。
ある程度ユーザーが獲得できてくると、
コミュニティであったりとか、
既存ユーザーのアップセルを狙うのかクロスセルを狙うのかわからないですけど、
チャンを防ぐとかカスタマーサクセスするとか、
そういう既存ユーザーを大事にしていく時期みたいな。
コミュニティのファシリテーション
そういう多分3パターンあるかなと思っているんですね。
昔の2015年ぐらいのDevRelってどっちかっていうと、
アウェアレスばっかり知ってもらうみたいなところばっかり売ってたんですけど、
本当に新しいサービスとかって、
サイトが異様にしょぼかったりとか、
ユーザーフロー、ユーザー登録フローこれでいいの?みたいな感じだったりすることが、
最近結構多くて、
お客さんとかにもまずちょっと認知獲得よりも、
まず足固めちゃんとしましょうみたいな。
そういう機会が多くなってるんですね。
ただ、それをちゃんと説明すれば意外と分かってくれるというか、
DevRelをこれから始めていくっていう会社さんが、
何からやればいいですか?みたいに。
まずブログからやるべきですかね?みたいに言われるんですけど、
まずサイトのコンセプトとドキュメントをちゃんと見直しましょう。
そこがちゃんとできていれば呼び込んでもいいと思うんですけど、
悪い例で言うと、
昔、今もありますけど、コルドバフォンギャップあったじゃないですか。
タイジーさんとかも使ってたと思うんですけど、
あとセレニウムとか、ごめんなさい、タイタニウムとかもそうだと思うんですけど、
JavaScriptでスマホアプリが作れますとか、
ウェブ技術で作れますって言った時に、
すっごい開発者の心が踊ったと思うんですよ。
で、実際試してみたら、
その時のJavaScriptエンジンの性能とか、
JQueryモバイルのもっさりした動きとかで、
みんな超がっかりしたと思うんですよね。
なんでこれか?みたいな。
で、みんな離れちゃって、
今、コルドバとか使ったようなモバイルアプリとかも、
ビジネスサイドだとすごいよく使われてますし、
性能的にも、ネイティブにはかなわないけど、
多分80%か70%くらいの性能で動くようになってたりして、
どっちかっていうと、ネットワークの速度の方が問題とか、
いう場合もあったりするかなと思うんで、
使えるようになってるんですけど、
未だにいや、遅いでしょ、みたいなことを言う人もいるんですよね。
そういうネガティブな印象って、
意外と長く引きずりがちな気がするので、
まず、そういう超すごい夢を見させるっていうよりは、
ちゃんとこういう目的で使えるんですよとか、
こういうものができますよっていうのを、
ちゃんと正しい目線で発信していたら、
こうはならなかったのかなって思うんですよね。
うんうん。
一回ね、悪いイメージついちゃうと、引きずっちゃいますよね。
そうですよね。
その人たちってもう、改善された情報を見に来てくれないので、
僕らが、いやいやそんなことないですよ、
今だいぶ良くなってますよって言っても、
全然信用しないというか、来てくれないんですよ、サイトに。
そうですね。
プロダクト、なんだろうな、
フィジカルなもの、製品の販売とプロモーションを考えたら当たり前ですけど、
片手打ちの不完全なものをいくら認知上げて、
みんなに気に入ってもらおうと活動したって、
ものが不完全だったらファンも固定しないし、
どんどん離れていっちゃう。
これ誰が見ても多分自明だと思うんですけど、
ソフトウェアとかサービスだと、
なんとなくそこが片手打ちでもいけちゃう感じがしちゃうんでしょうね、きっと。
そうですね。
ベータリリースとかアルファリリースも許される分か、
もちろんあると思うんですけど、
僕の中では対開発者っていう面で、
アルファでもいいんですけど、品質がアルファなのは勘弁してほしいと思うんですよね。
そうそうそう、そうなんですよ。
昔絵が流行ったと思うんですけど、
アジャイルでもなんでも、
ものを段階リリースしていくときに、
最初に三輪車作って、自転車作って、エンジン付いたバイク作って、
外側の付いた車作って、
少なくとも全部において移動手段としては確立できるよねっていう、
絶対にぶらしてはいけない軸は保ってる。
これが多分最低品質っていうところで。
だけど最初にタイヤ作って、次にフレーム作って、次にハンドル作って、
これは意味ないよねっていう、その話ですよね。
そうですね。
それか、最初からバイクが出てきたんだけど、
ナットの締めが甘かったりとか、
ハンドルがガクガクだったりとか、
これは乗れないだろう。
品質が悪いパターンですね。
っていうのは良くないと思うんですよね。
それってベータじゃないと思うんですよ。
出すのが恥ずかしい。
見せちゃいけないやつみたいな。
というかもうね、ただの未完成品ですね。
そうですね。
未完成品とベータは違うんだ。
意外とそういうプロダクトが多い気がしたりとか、
あとはコンセプトがひとりよがりというか、
プロダクトとしてちょっと甘い部分がある場合が多くてですね。
その足固めちゃんとする前に、
アウェアレスの部分、いくら頑張っても、
そりゃユーザー取れないよねっていう気はしますね。
というのが最近、そんなことをよく考えますね。
なので、DevRelを何から始めればいいみたいな、
もし悩んでいる方がいたとしたら、
まずサイト見直すべきじゃないかなって思いますね。
ではですね、先にあれですね。
次回のイベントのお話をしておくと、
たぶんまだ参加者全然増えてないので、
皆さんぜひ来てくださいっていうところなんですけど、
次回はPengoshi.comさんで、
グラレコのワークショップですね。
どうしても私がやりたいっていうところで。
こないだ、たいじさんの絵も一回何回かアップしましたよね。
前回の、僕が飛び込みLTやった時じゃないですか。
そっかそっか。
たいじさんのイラストは最初にできていたので、
あれ使い回すだけでいいんですけど、
グラレコってグラフィックスが多分大事なので、
美容師って言われた時に美容師って書いちゃダメなんですよね。
ハサミ書かなきゃいけないみたいな。
その武器をどれぐらい持てるかなんですよね。
フラッシュって言われた時に、
Fしか思い浮かばないんですよ。
フラッシュのロゴがパッと出てくれば分かりやすいんでしょうね。
そうですね。
フラッシュっぽいものって言われても、
アイコンぐらいしか出ないので。
たぶん赤でちょっと引きたいっぽいFを書いておくと。
そうですよね。
IT系だとそういうアイコンを描くと、
分かる人には分かるみたいな。
だからこそアイコンって呼ばれてるわけですよね。
そうですね。
でも今時の若い人はフラッシュなんて知らないですよ。
マクロメディア時代ですからね。
しかも私が使ってたの。
マクロメディアすら知らない人いるんじゃないですか。
若い人。
マクロメディアは知らないでしょうね。
しかもだってスマホが出てきてから
エンジニアになりましたみたいな人からしたら
フラッシュなんてもう駆逐される寸前ぐらいだったわけじゃないですか。
本当ですよね。
スマホのせいでなくなったと言ってもいいぐらいなんですか。
ジョブズのせいですね。
ジョブズ。
一時はアドビエアとかありましたけどね。
あれスマホ対応したんですけどダメでしたね。
フラッシュ良かったんだけどなあ。
使いやすくて。
そうですね。
私の知り合いの会社はエンプラ系で
フレックスにオールベッドした会社があって
大変なことになってましたね。
一時期そういう流れがありましたからね。
あの時のLTでもちょっと触れましたけど
自分もフロントエンドフラッシュサーバーサイドJavaの
当時鉄板だった組み合わせの技術を学んでたし
それがあったから当時の会社に引き抜かれたっていうのもあったので。
多分その時のフラッシュとJava側の通信手段って
RPCか何かでRESTみたいなそういうやつじゃなかったですよね。
当時はサーブレットですね。
サーブレットだ、そうだ。
HTML5になっちゃってそこも全部作り変えなきゃいけないみたいな
結構大変なことになってましたね、その会社も。
本当にJobsの罪は重いなって思いましたね。
ではですね、大地さんにチャットでURLをお送りします。
今日のメインテーマは今学んでいる学びたいこととなっておりますが
大地さん何か覚えようとしてること何かあったりしますか?
デジタルトランスフォーメーションとDX
覚えようとしてるというか改めて学習し直してるって方が正しいかもしれないですけど
DX、デベロッパーエクスペリエンスの方のDXではなくて
デジタルトランスフォーメーションの方のDXと
いわゆる日本国内のエンタープライズ企業、事業会社みたいなところが
ITの文脈のところで正しくどうDXというのと付き合っていくか
というところに対して勉強し直してますね。
自分がその領域でバリューを出せることがないかなというのを最近考えています。
DXって昔で言えばIT化であり、その昔であればユーザーコンピューティングであり
その前であればオフィスのOTA化みたいな
やってることを言い方変えただけで同じじゃね?って思うんですけど
そう思われちゃってるのでそこの認識を正しく伝えていかなきゃいけないかなというのが一個
確かにデジタル化、新しい技術でITを刷新していくとか
今までアナログだったのをデジタル化していくとか
それは目的にたどり着くための手段、方法の一つとしてもちろん正しいんですけど
本質はデジタルのアプローチでその企業が持っているもの、既存から持っているものではない
既存に持ってない新しいバリューを生み出すというところが本質なので
そのための方法論、手段としてITの自動化とかいうのがあるというイメージですかね。
大きい枠の中の一部分としては確かにそういう部分はもちろんあるしそこは正しいんですけど
そこだけザッツオールってなっちゃうと誤解が生じちゃうかな
ただ日本企業の方はそういうふうに認識されている方も多いというのも事実で
ここはやっぱりうまく認識そこなくしかも反発が起きないように話を進めていけるやり方がやっぱり必要かなというところを今勉強しています
確かにIT化とかユーザーコンピューティングとかも社内の反発で潰されたケースいっぱいありますからね
ありがとうございます。じゃあ大地さん1件目読んでいただいてもいいですか
デブレルネーム西から来た馬面の男さんです。ありがとうございます
今週のテーマは今学んでいる学びたいことでお便りします
ワンオンワンスキルとコーチングスキル
今年から社内の周りの人とワンオンワンをするようにしました
人との関係強化やサポートなどが目的です
ワンオンワンのスキルを学んでいます
ある一定の方はあると思いますが人によりやり方はまちまちだと思うのでワンオンワンスキルを学びたいです
あと合わせて言われることが多いコーチングスキルやフィードバックスキルですね
今実践を伴って学ぼうとしている形です
もう一つ学び中というと生成AIの個人や企業での活用を学んで生産性を高めていきたいと思っています
時間は有限なので頼れる部分は頼って時間を大事にしたいです
ということで今週のお便りでした
ちなみに今週末は札幌で開催されるクラウドネイティブデイズサマーに参加する予定です
6月15日は現地での交流 レストワーキング楽しみです
以上です 今週もありがとうございました
こういうヒューマンスキルは常に需要あり続けますよね
私も会社員の時代はリーダー研修って言ってたかな 当時は
リーダーシップ研修とかそういうのありましたね
ありましたよね そういうのに行ってこういう風に話すとか受け止めるとかやらされた覚えがありますね
僕もやりましたね リーダーシップ研修 マネジメント研修 あとファシリテーション研修とか
要は管理職になるために必要なスキルを受けさせる スキルをつけさせる研修
どうですか 今役立ってるものありそうですか
そうですね 今役立ってるかどうか分かんないですけど 当時確かに役立ったような気はしてます
そこにその後の自分の経験が積み重なって今になってるっていうのを考えたら 今でも役に立ってるって言えるかもしれないですね
素晴らしいですね 私全然役に立ってないというか
逆張りというか本当に無理な人は無理だと
無理な人を引っ張っていくのは 私には向かないリーダー像だというのが
少しずつ思っちゃって 次の会社の時にはもう無理だと思う人は
もうあなたには向いていないから別の部署に行くか 退職した方がいいよっていう風に
もう本人に告げちゃうっていう そういうスタイルやってましたね
なるほど 全然ダメでしたね 向かなかったですね
難しいですよね これは
難しいですよね ワンワンでそういうのをサポートするってことですよね 一人一人を
やっぱ難しいのが一つ もう一個はどっちに楽しさを覚えるかで
僕は今はICの方が楽しいと思うんで ICとしてやってますが
管理師 ピープルマネジメントとかが興味出てきたら そっち行くかもしれないしみたいな感じです
そうですね 面白い人たちとか 自分がリスペクトできる人たちと一緒に仕事するのは楽しいんですけど
ピープルマネジメントが入ると そうではない場合も多いのかなっていう気がするんで
なかなかそこがフラストレーションになって 自分のポテンシャルが下がっちゃうのがすごく嫌なんですよね
ではですね 続いて私からいきます
DevRelName 札幌のじゅんさんですね いつもありがとうございます
やってみたいこととして頭の片隅に ずっと引っかかっているのが楽器のミディ化です
エレキバイオリンから制御信号を出すことで コントローラーとして使えるだろうと想像だけしているのですが
身近にやり方を聞ける人もおらず 揃えるべきものが何なのかも把握していません
エンプレスエフェクツのZOIAについて
エンプレスエフェクツのZOIAでハードウェアを買えば その中でいろいろ遊べるらしいことは調べたので
購入を迷っています 迷っているうちに円安で機材が高くなったり
思いつきで出張して当面の予算がなくなったりで だいぶ経ってしまいました
こういうのもレンタルがあればいいのにと思ったりします
来月の不公開期を決めてしまったので 今月も買えませんということですが
タイジュさんはMIDIはやってないんですか?
仕事をしてましたよ MIDIで
MIDIで音源を作る仕事をやってました
もう25年前くらい
それはキーボードで?
キーボードですね 基本的に
キーボードとDAWっていうアプリ上でやってましたね
僕はアナログ楽器のプレイヤーなので
ギターを音として入れたいときは
同じようにアナログ楽器のMIDIコントローラー化は難しいというか
当時はほぼ無理だったので
今はわからないですけど
ミディギターと音源制作
そこは普通にオーディオインターフェースで音を入れ込んで
そのまま音としてデジタル音源として認識させて
曲にミックスするということをやってましたね
一番簡単なのはMIDIコントローラーを使っちゃう
キーボードを使っちゃう
今は色々ありますよね
MIDIコントローラーもキーボード型だけじゃなくて
もともとあるアナログ楽器をMIDIコントローラー化するのは難しいと思うんですけど
例えばギターの演奏のフィーリングに近い形で
インプットできるMIDIコントローラーは売ってたりする
ドラムならドラムの
アナログ系のデジタルじゃないですね
専用のやつですね
そうしても結局は電気信号でコントロールしないといけないので
アナログ楽器はあくまで音の波形を出力してるだけなので
ミディギター持ってるって言ってますね
ジューンさんから見てますね
昔耳コピー流行りましたよね
映画とか音楽とかのMIDI電源みたいな感じで
よくダウンロードして聞いてましたけど
あれもガラ系の着メロとかも一時期自分でインプットできるとか
あの辺でいろんな人がそういうのやってたような気がします
やってましたね
私はそういうのできないので
雑誌とかに書いてある番号を押すやつで作ってましたね
あったあった
着メロ懐かしいですね
じゃあ本当はミディギターならぬ
MIDI用のバイオリンみたいなやつを使うのがいいんですかね
バイオリンのフィーリングで使えるミディコントローラーがあればいいですよね
いいですねこういう全然違うチャレンジ面白いですね
ではですね3件目タイジさん読んでもらってもいいですか
はいデベロルネームジャニーマンさんからですありがとうございます
AWSの学習と技術の選択
AWSですなかなか進捗が出せてないのですが
基礎固めのAWS認定の勉強とちょこちょこ触って学んでいます
それにしても広大すぎて全然先が見えないです
いや本当にこれは本当そう思いますね
もう作りすぎやろっていうぐらい多いですよね
確かに難しい
皆さんどうするんですかね
技術者である分野に特化している技術者であれば
全部覚える必要はないと思うんですけど
ソリューションアーキテクトみたいな人とか顧客提案する人とかになると
やっぱり全体把握するんですかね
必要な部分から広げていくイメージが多いと思います
必要な領域から
そうですよね
多分昔からAWSを触っている人だったら
一番最初EC2使ってJS3使ってとか
いろいろと決まった順番というか
限られた中でやってたかもしれないですけど
ここまで大きくなってしまうと
自分の案件で必要な部分から
そんなにあれですよね
だいたいはストレージとコンピュートとサーバレスト
最近だったらコンテナーとか
そんな感じになってくる
あとセキュリティ部分ID管理だったりとか
そうですね
あとは案件によって仮想通貨系だとブロックチェーン系
どっちかって難しいのは
そういうのを作るためのオペレーションというか
お作法の部分な気がするんですよね
環境を作るために
設定項目を入れてポチポチやってれば
普通にできるものでも
そういうプロジェクトで普通に
自動化
手動オペレーション排除するようにやっていこうと
IAC使わなきゃいけない
そのためにはどうする
テラフォームを使うか
テラフォームの書き方
テンプレートの構成ファイルの書き方を
勉強しなきゃいけなくなったりとか
そういう難しさのほうが大きい気がしますね
AWSの機能そのものというより
確かに
プログラミングもあるあるですけど
本当にやりたかったことをやるために
別なことを覚えなきゃいけなくて
それをやるためには
さらに別なことを覚えなきゃいけないみたいな
結局一番最初に立ち戻ると
何がしたかったんだっけみたいな
なんで私はAWSを勉強してるんだろうみたいな
場合ありますよね
結局
何だろうな
全部手動オペレーション
手動運用でいい
であれば
全部そんなに多分難しくなくできることが
多いと思うんですよね
これを
やっぱ自動化させる
人の手を排除するっていう考え方が
やっぱりセキュリティで今主流なので
そうなってくるとどうしても
それを実現するためのお作法を学ばなきゃいけない
っていう話で
そこがすごい難しくなってる気がします
そうですね
ではですね
次回のイベントは
さっきお伝えしたので
そうですね
DevRel Japan Conferenceの
お話ですね
今年は9月の14日の土曜日に
TOKOMOさんのR&Dオープンラボというところで
1DAYで開催します
大地さんまだあの会場って行ったことないですかね
ないですね
結構12階なので
割と高くて
お台場も斜め
斜め下ぐらいのところにすぐ見えたりする
結構いい会場ですね
レインボーブリッジも見えるかな
ちょっと本当サイボーズさんを彷彿とさせるというか
こういう見晴らしのいい会場いいなっていう感じですね
楽しみですね
今年はキーノートが1つと
あとは普通のセッションは12項ぐらいの予定となっております
10時に多分オープンする形なので
今年は朝ごはんは
朝ごはんっていうかモーニングはないかなと思ってますね
やっぱりカンファレンスっていうと
モーニング出るイメージありません
海外カンファレンスのイメージだとそれ強いですね
ですよね
なんとなくモーニング出したいような気はするんですけど
さすがに10時オープンで
ランチもあるしっていうところで
なのでランチは出ますけれども
モーニングはなしという形で考えてます
あとはキッズルームはまた今年もやりたいなと思うんですけど
去年はお一人だけしか
しかって言っちゃ良くないですかね
お一人の利用だけだったので
もっと使ってくれるといいなと思うんですけど
どうなんでしょうね
この界隈にどれぐらいいらっしゃるのかなっていう
お子さん連れの方が
そうですね
子供を連れてでも参加したいと思っていただけるかどうかの感じもしますけれども
もうたいじさんのところはそういうキッズルーム使う年齢じゃないですもんね
もう全然ですね
ですよね
ってことはちょうどピンポイントですよね
多分2歳ぐらいから6歳ぐらいとか
もうちょっと大きくてもいいのかな
そのぐらいの年齢の方が
なんか最近出産ラッシュというか
デブレル界隈というかコミュニティー界隈の人
出産してる人多くないですか
去年今年
ちらほら聞きますね確かに
なんかなのでそういう方は多分ゼロ歳児とかなので
さすがにちょっとねゼロ歳児だとお預かりするのは難しいのかなと思うんですけど
来年再来年とかはね増えるのかなとかって思ったりしますね
そうするとあれですね
なんかキッズ向けのなんかこう楽しめるようなことができるといいんですけどね
そうですね難しいですね
難しいですよね
なんかおっさんが考えてもなかなかいいアイデア出ないですよね
もうそれこそ本当に今子育て世代の方のご意見が参考になるかもしれないですね
そうですね
私自身がでも子供を連れてカンファレンスに行ったっていう経験がないので
何があれば行きたいかっていうアイデアが全然わからないですよね
他に安心して預けておけるかどうかじゃないですか
言ってもキッズルームがあるとはいえ
例えばそれがもうなんか国の認可保育園で保育所で決まった時間ずっとフルで面倒見てくれるよ
だったら多分安心して預けて自分はカンファレンスで集中できると思うんですけど
そこがわからないどの程度信用していいのかなっていうレベルだと
やっぱなかなかカンファレンス集中できないですよね
大丈夫かなみたいな感じになっちゃう
確かにキッズルーム提供しますよって言って
それじゃあ誰が担当してるのかが見えてないと難しいですよね
キッズルームあるのはわかったけど
例えばショッピングモールとかにあるキッズエリアとかって
普通に遊べる場はあるけど別に保育士さんがいるわけでもないし
確かに去年それ全然やってないわ
イメージがわかんないかもしれないです
ですよね
そうだよな確かにそれは大事ですね
それはちゃんと告知しないといけないですね
一応去年もちゃんとそういう出張保育を
手掛けている会社さんにお願いした上で設置はしていたので
今年はねもし皆さんがお子さんがいらっしゃるよという方がいらっしゃればですね
ぜひ使ってみていただきたいなと思いますね
確かにプロポーザルにも一見来てましたね
そういうキッズルームの話のプロポーザルは
なるべくDevRelのカンファレンスは若い人
若い人って言うとちょっと語弊がありますけど
そういうなんとなく年齢層高めなイメージがあるんですよ
私の中で35歳以上の方ばっかりだなみたいな
なんとなくある程度エンジニアとして経験もあるみたいな方が多いので
ちょっと年齢層が他の言語系のコミュニティとかに比べると
ちょっと年齢層高めかなという気がするんで
でもたぶんCMCとかコミュニティマネージャーとかだと
年齢層下がるような気がするんですよもっと
確かに若い方もいますね
そうですよね
どこの会社かとかじゃなくて
世間一般的に会社としてコミュニティマネージャーとか
コミュニティマーケティングのポジションに
デベロッパリレーションの最新動向とカンファレンスのご案内
アソシエートのポジションを設けてるところが多いんじゃないですか
だから比較的ジュニアレベルの業界経験年数がまだ
数年とかそういうレベルの人でも入りやすくなってるのかもしれないですね
ちょっと時間があるんであれなんですけど
コミュニティマネージャーになられてる方のバックグラウンドというか
その前って何をやってる方が多いんですか?
マーケティング
文脈にもよりますかね
さっきのデブレイのフェーズの話じゃないですけども
最近は今順さんもコメント出してくれてますけど
フェーズでいうと最近はポストフェーズが結構重視されてきたりもしてるので
特にSaaS系だと
そうするとやっぱりカスタマーサクセスチームの人が
コミュニティの担当になってくっていうケースは
ちらほら見聞きはしますね
はいはい
カスタマーサクセスになる場合って
ある程度プロダクト理解がなきゃいけないとか
お客様の業務理解っていうところで
ある程度経験も必要かなと思うんですけど
それでも若い人が多いんですね
なので当然グループの中には
シニアレベルとかスタッフレベルの人もいて
そこにアソシエイトとして若手も入ってくる
例えばデータドックなんかはそんな感じなんですよ
カスタマーサクセスマネージャー
アソシエイトのポジションとかで募集すると
そこは比較的まだ経験値が少ない方とかが入ってきて
シニアレベルスタッフレベルの人と一緒に
仕事して経験積んでいくみたいな
コミュニティを通じてお客様を知るみたいな
そういうところもあるって感じですかね
カスタマーサクセスのメインミッションからすると
コミュニティっていうのはどっちかっていうと
付属的な部分になるとは思うんですけどね
実際は各担当のお客さんアカウントとして
担当してるアカウントとの実際にフェイシングをしながら
お客さんの内部的な対象の製品の利用促進であったりとか
そういったところをサポートしていくというのがメインなので
それの手段としてコミュニティを活用しやすいよねっていうところで
カスタマーサクセスとコミュニティマネージャーの重要性
文脈的にカスタマーサクセスの人が
コミュニティをリードしていくケースっていうのは
最近見たり聞いたりすることが増えてるなという感覚ではあります
分かりました ありがとうございます
小田翔さんからコメント来てますね
平均年齢上がってきましたね
そうですよね だって立ち上がった時は小田翔さん
アラフォーでしたからね きっとね
うん
今はアラフォーですか
30ぐらいじゃん
いやいやいやそんな
そういうこと?
8年前でしょ
8年前か 本当ですよ
30ぐらいですよね そこそこ
今じゃもう立派なアラフォーですからね
年齢上がってますよ
私なんかもうすぐ50が見えてきてる
アラフィフですね
そう もう完全に
なのでね なるべくその
若い方 30代とかの方も
安心して来れるような
カンファレンスにしていきたいなというふうに思っております
ではですね 大地さん何かイベントのご案内とかありますか
2つですね
1つは今日の夜
ウォータークラーカンバーセーションという
会話のアウトプットのオンラインのやつですね
無料で参加できる
いつものやつやります
先ほどDevRelJPのハッシュタグつけて
XとLinkedInにポストしてますというのが1つ目
もう1つは
今週とかじゃないですけれども
7月に
あれですね
DevRel Asiaの
ミートアップイベントやります
英語版のセッション
3つほど
提供する予定ですので
ぜひ英語の練習なんかも兼ねて
参加してもらえると嬉しいなと思います
コンパスの方でチェックできますので
よろしくお願いします
コンパスじゃないよ ごめんなさい
ミートアップ.コムだ
データノックさんでやりますね
そうです
ってことは
当日は飲み物OKでしたっけ
飲み物OKなんですけど
多分そこまで大人数にならないような気がするんですね
今までの感じで
なので
うちのサーブできる範囲でいいかなと考えてます
マジですか ありがとうございます
ミートアップ.コムの方では会場費は設定してないですね
そういうことですね 了解です
はい じゃあぜひぜひ
日本にいるとなかなか英語でコミュニケーションする手段
する場が少なかったりするんで
ぜひ皆さん来ていただいて楽しんでいただければと思います
はい ではですね
今週のDevRelラジオ168回目ですね
今学んでいる学びたいことに関してはですね
こちらで終了していこうと思います
大地さん いつもご参加ありがとうございます
はい ありがとうございます
ではまた皆さん来週お会いしましょう さよなら
