DevRelラジオの紹介
お疲れ様です。今日は3月25日ですね。夕方5時半になりました。DevRelラジオの208回目ですね。やっていきたいと思います。
まず最初にですね、DevRelラジオの紹介からですね。DevRelラジオは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日夕方5時半からですね、1時間程度お送りしているというものになります。
DevRelというのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、例えば、テクノロジーエヴァンリリストとか、デベロッパーアドボケイトとか、コミュニティマネージャーとかですね、
そういった方々が集まって情報交換したり、イベントをしているといったコミュニティになっております。
DevRel Tokyoはですね、公式サイトがあります。DevRel.Tokyoというサイトですね。
そちらでスラックに参加できますので、DevRelに関わっているとかですね、DevRelに興味があるという方はぜひジョインいただければと思います。
そこまでじゃないよという方はですね、公式のXアカウントがあります。
AtDevRelTokyoというアカウントで、普段はSharpDevRelJPというハッシュタグでポストしてますので、
そちらのアカウントフォローいただいたりとか、ハッシュタグを追いかけていただければと思います。
というところで、今日はですね、いつもとちょっと場所が違ってですね、今アメリカにいるんですけれども、
なので、普段の夕方5時半というとですね、こっちが多分朝3時半とかなのかな。
なので収録にしていますという形です。
かつですね、日程も微妙なところがあるのかなというところで、
まだ今のところですね、ラジオの今日のメインテーマの方ですね、
もう一度チャレンジしたいことに関する回答が来ていないというところで、
このネタ自体、このテーマ自体をですね、ちょっと来週にずらす、もう一回やろうかなと。
もう一度やりたいことをもう一度やるっていうね、なんかメタ的な感じになってしまって微妙なんですけれども、
そちらのネタはですね、来週209回目も継続してやっていこうと思いますので、
ぜひですね、皆さん今のうちというか、多分ね火曜日にはですね、いくつか回答来てるんじゃないかなと思うんですけれども、
今週は申し訳ないちょっと取り上げられないので、ぜひ来週楽しみにしておいていただければと。
もうちょっとネタをよくよく考えたいなという方がいれば、もう一回送っておいてもらえればですね、
新しい方だけ取り上げていこうと思いますので、ぜひコメントいただければと思っております。
AI時代のプログラミング
ということでですね、今週のラジオは最近のDevRel周りの記事とかを取り上げていこうかなと思うんですけれども、
まず1個目ですね、これは西尾さんのブログで、西尾ひろかずさんですね。
西尾ひろかずさんのブログで、AI時代の技術力獲得プロセスという記事が出ておりますと。
AIでプログラミングやるっていうのが当たり前になっている時代であったとしても、
いわゆるプログラミングの社境みたいなものが必要かという問いに対する暫定解答というところで、記事が書かれております。
新しいプログラミング言語を学ぶときには、まずチュートリアルはマニュアルの通りに淡々と入力して、
結果を観察するセファリの種とか行的な作業が必要になる。
そしてその先で難しい問題に出会い、時間をかけて乗り越えていくということなんですけれども、
これはプログラマーであれば誰しもが通った道なのかなっていう気はするんですよね。
AIでプログラミングやるのが当たり前になっていく中で、また同じようなことをやるのかというところがあるかなと思うんですけれども、
それに対して西尾さんの回答というところがこの記事の中で書かれている。
基本的にAI時代であったとしても、基本的にはそれは変わらないというところですね。
ただ違いは、その社協の対象が大勢の人向けに書かれたチュートリアルから、
AIが自分のために生成してくれた手順書に変わることということですね。
その手順書の作者、いわゆるAIが質問に対して答えてくれるということになる。
なので、そのAI時代の前のプログラマーは社協をしていって、そこで社協が終わって、
実際にプロジェクトにコードを投入してみると、ちっちゃい課題がトラブルがあって、
それを乗り越えて、乗り越えて、乗り越えてっていうのを繰り返していくうちにだんだん成長していくっていう形だったのが、
AI時代になると、そのちっちゃい山を乗り越えるのは結構容易になるんじゃないかというふうに書いてあります。
ただ、AI時代のAIによってアシストされた学習者は、
同じ時間でより遠くまで進み、より大きな壁にぶつかることになると。
そうですね。このちっちゃい山、ちっちゃい課題は簡単に乗り越えられるだろうというのは予想はつくんですよね。
ただ、そのときに、そのちっちゃい課題を乗り越えるのが自分の力だけじゃない気がするんですよね。
またそこでAIが使えるような気がしていて、うまくいきません。こういうエラーが出ますっていうふうにAIに言うと、
AIがここをこうしたらいいですよっていうふうに言ってくれて、
何だったらもうエージェントみたいな感じでコードの修正まで行ってくれると。
無事動きましたね。問題解決ですねみたいな感じで次のステップに進んでしまうと、
実際ギリギリというか、スパランが何も得られていない気がするので、
そうなると、得られがほとんどないような気はするんですよね。
そんな困難で繰り返していって、実際もうちょっと大きい壁、
AIでも乗り越えられないような壁にぶち当たったときに、何もできないという状態になる気がするんですよね。
多分それがこの西尾さんに言われている、より高い壁なのかなという気はしますね。
多分その大きい壁っていうのは人それぞれな気はするんですけど、
本当の熟練のプログラマーであれば、多分解決できたであろう課題もするんですけど、
AIもすごい進化し続けているので、その大きい山の大きい壁すら乗り越えていけるようになるんじゃないかなという気がするんですよね。
厄介なのがあるとしたら、多分その業界のドメインだったりとか、
その企業の中にあるナレッジみたいなものを生かさないといけないという場面で、
汎用的なAIだとそこが理解できない可能性があるかなっていうところですかね。
そうなった時に、その高い壁の種類が多分違うと思うんですけど、
そこが乗り越えられるかどうかというのが問われるのかなって気がしますね。
西尾さんはXで書いてるみたいなんですけど、最初はAzure何もわからんという状態からですね、
AIが支援してくれたからAzureがわかる、どんどん設定進むというふうになったけど、
不可解な現象に出会い、Azureのこと何もわからんという状態に出くわす。
まさにこの状態ですよね。
この状態になった時に、結局AIの補助がなかったら問題解決できませんという状態だと、
それだと多分エンジニアとしては二流になっちゃうんだろうなっていう気がしますね。
次の一手は、この行き詰まるところまでの成果を見直して、
有用な部品を取り出して再利用することで、1回目の道よりもいい道を進むことになると。
例えば、MacBookでDockerビルドしてAzureにプッシュしたら、
CPUアーキテクチャが異なるので、わかりにくいエラーが出た。
解説は同じアーキテクチャを仮定してシンプルに書かれているので、
読み替えるかビルド環境を揃える必要がある。
これあるあるですよね。
確かにな。
これは別なところのDockerコンテナを実行するサービスを使っていたときにも
出くわしたことがあって、結構変なエラーが出るんですよね。
MacでビルドしたImageプッシュして実行させると、
コンテナおにゃららエラーみたいな感じのやつが出て、
言ってみれば、実行環境はLinuxなので、
Linuxのところでビルドしてプッシュすればいいというだけの話なんですけど、
コマンドだけ提示されても、これは解決しづらいかもしれないですね。
それつかないですよね。
自分たちがプログラミングやっていた時代しか知らないので、
その前のアセンブラーとかの時代をね、
学校の授業とかそういうレベルであればやりますけど、
実践的に仕事の中でそういうことをやってたわけじゃないので、
そこまで詳しくないわけですね。
コモルとかも知らないし、スイプラとかも業務で書いたわけじゃないので、
その具体的なトラブルみたいなものをあまり知らないので、
その状態から自分たちの時代で言えば、
VBであったりPHPだったりJavaだったりRubyだったりとか、
そういったある程度高級な言語を使った経験しかないので、
AIの時代の学習曲線も分からないし、
アセンブラーの時代の学習曲線も分からないという、
結局何も分からないというところではあるんですけど、
これからAI使ってプログラマーをやっていくっていう
ジュニアのエンジニアの方は全く新しい学習曲線を
作っていかなきゃいけないんだろうなというのは分かるというところですね。
Salesforceのエンジニア採用の停止
キサンハナですね。では続いて、こちらはSASKI AIかな。
こちらの記事で、AIがあるので今年はエンジニア採用をやめました。
セールスフォースという記事が出ております。
これはサンフランシスコスタンダードというメディアで報じられたらしいんですけれども、
セールスフォースの決算発表会において、マーク・ベニオフ CEO、
自ら公表したものだと。
同志はセールスフォースが開発、実際利用しているAIエージェントの成功により、
2025年はエンジニアの採用予定がないことを明らかにした。
セールスフォースは2023年に約7000人、
2024年には約1000人と大規模な人員削減を実施していると。
2025年も既に1000人以上を削減する一方、
営業担当者の採用は拡大しており、
AIにできることはAIが、できないことは人間が対応する形に移行しつつあるということですね。
実際セールスフォースが開発しているAIエージェント、
エージェントフォースというものらしいんですけれども、
それは5000件以上の契約を獲得していると既に、
我々は人間だけを管理する最後の世代であると述べたということですね。
エンジニア採用しないという選択を取る会社があるということですよね。
その間、イベントでAIエージェントの話をしてたんですけど、
そのAIエージェント、例えばデビンとか、
デビンは結構チャットベースで1個マスクを投げたら、
向こうでいろいろ考えていろいろ実行して、
最後にプルリクを送ってくれるという形になってるんですけど、
そこまでじゃないAIエージェントとかもあるわけですよね。
例えば、カーソルのやつとか、あとはルーコードとか、
そういうのって、何かメッセージ指定して、プロンプト打って実行させて、
じゅんぐりじゅんぐりいろいろ実行していって、
最後にクステみたいなことをやるわけですけど、
結構その過程が段階的なんですよね。
全部任せてもいいんですけど、
でも結局そのやっている作業とかが正しいのかどうかみたいなところを、
ある程度人が見ないと難しいみたいな場面があるんですよね。
それを見ていないと、デビンとかもそうなんですけど、
結構同じことをじゅんぐりじゅんぐりやって、
同じことを繰り返して、完全にはまってしまって、
無駄にコストがかかるみたいなケースもあるんで、
そうすると意外と人が完全に任せられないんですよね。
そうすると定期的にチェックとかを、
自分のタスクもあるんだけど、
実はやってることはAIがやっているタスクを監視しているだけみたいな、
状態になってしまうっていう話を、
この間ちょっとしてたんですよね。
本当のAIエージェントみたいなものが、
独立して動いてくれる時代になったとしたら、
本当タスクを、
デブレルの重要性と自動化
全然同時並行で動かせるようになるはずなんですけど、
まだ今、そこまでは全然至ってないっていう状態なんですよね。
結局、1つのタスク、
コンピューターが、AIがやってくれているタスクを監視して、
ある程度ちゃんと動かせるようになったとしたら、
本当に自分のタスクを、
AIがやってくれているタスクを監視して、
ある程度ちゃんとできているなっていうのを確認していかないと、
どつもにはまりやすいっていう状態だと。
そうなると、自分のタスクをやりながら、
Devinと対話しながらもできるんですけど、
結構並列で頭使わなきゃいけなくて、
疲れるという話もしてましたね。
なので、このSalesforceとかが、本当に完全独立型ですよね。
それでどこまで仕事がこなせるのかわからないですけど、
人の手を煩わせなくなったとしたら、
結構使えるようになるのかなと思いますね。
まだまだそこまでじゃないと思うんですけどね。
何でしょうね。
例えば営業の方とかが、要件に合わせてポチポチポチって条件選んでいって、
あと実行ってやったら、
今までエンジニアに任せてたようなタスクが、
完全に自動でやってくれるみたいな状態になれば、
それはそれで自動化できる可能性があるのかなと。
エンジニアが不要な世界っていうのが、
そこに見えてくるのかなという気もしますね。
スパベースとNext.jsの影響
続いてが、これはDev.toの記事ですね。
ケニアのナイロビの方で、
パトゥマ・アブ・ドゥラヒという方なんですけれども、
The Superbase Influence on My Developmental Modelという記事が出ております。
こちらは、スパベースの話ですね。
この方自身はスパベースの社員ではないと思います。
確かないはず。
スパベースのコミュニティがスパスコードっていうのが、
非公式にあるらしいんですけれども、
そちらに参加してコミュニティに貢献してきた経験を書いてくれています。
いつの時代も割とデブレルの成功企業とか、
成功プロダクトみたいなものが語られるような気はしていて、
最近はスパベースのデブレルがすごくポジティブな反応が
入ってくるのかなという気がしますね。
デブレルでうまくいっているのか、
それともそういうふうになっているから
デブレルがうまくいっているように見えるのかって
とりたまの話ではあるんですけれども、
割と同じ開発者向けのプロダクトっていうのがあったときに、
スパベースと組み合わせてやるにはみたいな、
そういう文脈で語られることが多いのかなというふうに見えますし、
何かのプロダクトがあって、
Nextとかもそうですよね。
この我々のプロダクトをNext.jsで使うにはこうしたらいいよみたいな、
そういう記事が出てたりとか、
ドキュメントの中で公式サポートされていたりみたいなのは、
やっぱりデブレルがうまくいっているからこそ
生まれるものなのかなという気がしますね。
なので、最近だとスパベースでちょっと前、
ほんとちょっと前だとNext.js。
あと最近名前聞くようになってきたのが、
リセンドっていうメール送信のサービス。
このあたりがいろんなサービスとか、
いろんなプロダクトとかと組み合わさって、
使われる傾向がある気がしますね。
リセンドとかはDeFiとかでも、
公式のツールとして組み込まれていたりするので、
最近はスパベースですね。
そちらの話をよく聞くなという気がしてます。
スパベースの考え方がこの記事を書かれたんですね。
パトマさんのデブレル全体のメンタルモデルに影響を与えていたと。
スパベースが広告費ゼロドルに近い状態で、
いかに大人気になっていたかを考えると、
その影響はとても大きかったんだなと感じるということですね。
このときのその人気っていうのは、
GitHubのスターで見てますね。
いくつかあるんですけど、
スパベースとLimescaleDBとMongoとCockroachDB、
その4つを比較しているグラフなんですけど、
スパベースは2020年ぐらいに生まれて一気に伸びているという感じですね。
Mongoは3番目なのか、CockroachDBが2番目みたいですね。
LimescaleDBはそんなでもないかなという気がするんですけど、
GitHubスターが人気っていう意味では確かに人気はあるのかなという気がしますね。
人気とビジネスとはちょっとまた違うかなという気がするんですけど、
スパベース、広告費ゼロドルに近い状態で
とても人気になっているということですね。
デブレルの基本思想と未来
デブレルは死んだのかというのが定期的に話題になると。
そういったデブレルは死んだのかっていう話が定期的に話題に上がりますよねというところで、
開発者向けの製品が存在する限りデブレルは常に必要とされる。
それはむしろ機体や環境の進化の問題であるということです。
これは個人的にちょっと思うところがあるんですよね。
私もデブレルは死んだのかみたいな議論に対しては全然そんなことは思わないんですけど、
ただその開発者向けのプロダクトのステージによって、
デブレルの求められる成果っていうのは常に変わってくるんじゃないかなという気がしているんですよね。
最初はプロダクトの生まれたばっかりの状態とかでやることって、
やっぱ認知の獲得っていうところがあるので、
分かりやすいブログ書いたり、ドキュメント整備したり、
あと登壇したりとかいうところが必要になりますし、
ちょっと拡大してくるとコミュニティを作ったりとかいうところもあるかなという気はするんですけど、
そのうち安定期というか踊り場に差し掛かったところで、
あとビジネスのほうですね。
とにかく広めるっていうフェーズからある程度刈り取りをしなきゃいけないみたいなフェーズに入っていったときに、
デブレルの求められるものが変わっているのか、
それともデブレルからデベロッパーマーケティングのほうに移行するのかというところが変わってくるのかなと。
なのでスパベースとかももしかすると純粋にデブレルとして認知の獲得みたいなところをガンガンやっていくフェーズと、
でもそれだけだとやっぱり趣旨を仰いで常に成長できればいいんですけど、
そうじゃなくなったとか、
よりビジネス的な成果を求められるようなフェーズになったときに、
デブレルだけでよかったんだっけみたいなことは言われるんじゃないかなと思っております。
それがあまり続いたりすると、
デブレルって思い出しちゃったりとか、
デブレルとデベロッパーマーケティングとデベロッパーマーケティングとデベロッパーマーケティングとデベロッパーマーケティングとデベロッパーマーケティングが
あまり続いたりすると、デブレルってもう必要ないんじゃないみたいなことが言われる可能性があるのかなという気がしますね。
このデブレルの基本思想みたいなところでいくつか同じような記事を見たんですけど、
この記事ではデブレルは3つの柱に基づいて構成されていると。
1つ目がデベロッパーアドボカシーというところで、
技術的なコンテンツの作成、コミュニティとの関係構築、
あとはコミュニティから製品チームへのフィードバックというところがデベロッパーアドボカシーという柱ですね。
もう1個目、デベロッパーエクスペリエンスというところで、
開発者の生産性を向上させるというところをゴールとしています。
一般的に明確なドキュメント、コミュニティ向けのSDKの作成、
信頼できるサンプルコードの提供などが含まれるということですね。
3つ目、コミュニティマネージメント。
コミュニティの構築と育成に重点を置く。
積極的なコミュニティメンバーに報酬を与え、
コミュニティが参加できる方法を作り、健全なコミュニティ空間を作るということですね。
この方の個人的な見解では、デブレルは技術サポートに近いんじゃないかというふうに書いてあります。
デブレルを必要とする企業は開発者をターゲットにしており、
そのテクニカルサポートはユーザーへのサービスであり、
そのユーザーは開発者であることを考えると、
デブレルがサポートを行うというのは最も理にかなっていますということですね。
確かにマーケティングとセールスは重要だが、
テクニカルサポートチームと密接に協力するデブレルは、
全ての目的を果たすキラーコンボだと思う。
この記事はいろいろ手順に富んでて面白いかなと思うので、
この方自身はデブレルの方ではないんですけれども、面白いかなと思います。
面白いそのあたりの記事が多いんですけど、
ゲッティングスターティッドオンデブレルとデブレルの始め方ですね。
この方はまずデベロッパーアドボケイトの3つの役割というところを挙げています。
1つ目がデベロッパーエクスペリエンスエンジニアリング、
もう1個が開発者マーケティング、3つ目がコミュニティー管理、
3つ目がコミュニティー管理というところですね。
さっきとちょっと似てるかな。さっきもエクスペリエンスの話がありました。
デベロッパーエクスペリエンスと、さっきも開発者マーケティングの項目がなかったですね。
今度はあるというところで、1個目デベロッパーエクスペリエンスエンジニアリング
というところですけれども、ここはAPIの設計、ドキュメントの改善、
開発者と製品のシームレスなインタラクションを保障する役割であるということですね。
APIの設計までレベルがかかるというのはなかなか難しいのかなという気はしますかね。
2番目、開発者マーケティング。ユーザージャーニーの追跡、競合分析、
戦略的キャンペーンによる開発ツールのプロモーションなどが含まれると。
そうですね。ここら辺結構専門家としてのマーケティングのマーケターの方はいると思うので、
そういう人たちとどうコミュニケーションを取るのかが大事なのかなという気はしますね。
完全にマーケティングの方とかに任せると、それでよかったんだっけみたいな時もあったりするんですよね。
渋谷のスクランブル交差点で広告出すとかね、やったりする場合もあったりするので。
3番目、コミュニティ管理というところで、ここではオンラインのフォーラム、
ハッカソン、ソーシャルエンゲージメントを通じて開発コミュニティを構築、育成することを重視する。
コミュニティ管理に関しては、技術的な専門知識はあまり必要とされず、
人間関係の構築に重点が置かれますということですね。
DevRelに関する3つの柱というところは、またちょっと微妙に違うんですけど、
教育、アドボカシー、コミュニティ構築、その3つを挙げていますね。
さっきのデベロッパーエキスペリエンスって言っていたものが教育に当たるのかな。
開発者に製品の効果的な使い方を教えるというのが1個目。
その後の用語。用語は社内で開発者のニーズを代弁するという、これはフィードバックルートのところですね。
3つ目のコミュニティ構築、これは変わってないですね。
なので、いろんな人がいろんなことを言っているんですけど、結果的に言うと、
教育とコミュニティ構築、これは相手共通しているのかなという気はしますね。
用語、いわゆるフィードバックループだったりとか、あとはデベロッパーエキスペリエンスの部分とかは、
ちょっと人によって言い方は違う場合もありそうな気がしますね。
DevRelの未来は、AIやブロックチェーン、その他の振興テクノロジーによって形作られると。
本当そう思いますよね。ブロックチェーンは分からない。
Web3とか、いつぐらい?一昨年ぐらいとかですかね。
すごい騒がれて、これ一気にAIに飲まれちゃった感があるかなという気がするんですけど、
今はもうAI一色ですよね。
DevRelとエンゲージメントの進化
テクノロジーのエンドにすごく影響は受けやすいのかなという気はしているので、今はAIですよね。
企業が製品の普及を促進するために、開発者のエンゲージメントに依存し続ける中、
DevRelの専門家は自分のエンゲージメントに依存し続ける中、
DevRelの専門家は自分のエンゲージメントに依存し続ける中、
DevRelの専門家はこれらのトレンドに合わせて進化しなければならない。
メンターシッププログラム、教育リソース、保護システム、パートナーシップを通じてコミュニティと関わることが、
開発者の存在感を強く支持する鍵となるということですね。
AIに関しては影響を受けないエンジニアの人なんて誰もいないと思うんですけど、
DevRelに関わるような方というのは強く影響を受けているのかなという気はしますね。
これはどうかな。
これはリモートシンセスというサイトのYourDevRelQuestionsAnswersFinallyという記事ですね。
ライアン・ディナルディさんという方の個人ブログらしいんですけれども、
DevRelに関する質問にお答えしますというところで、
DevRelはマーケティングとプロダクトのどちらにあるべきかという疑問に対してなんですけれども、
正解はどちらでもないと。
GTO室やその他の独立した組織構造に置くと。
それがベストには思うんですが、
正直マーケティングの方がまだ予算を持っている気がするんですよね。
開発部隊、プロダクト部隊の方にほとんど予算がない気がするんですよね。
ツールを買うとか、組織を買うとか、
開発者の開発環境を整えるとか、
そういう予算っていうのは割とあるんですけど、
そのDevRelに即するような予算って、
なかなか持ってないことが多いんじゃないでしょうかと。
ディナルディさんにお答えします。
結局のところ、どの部署に配属されたとしても、
DevRelの役割と目標についてリーダーシップと一致する必要があると。
これはとても大事ですね。
理想的なのは会社のリーダーシップが、
DevRelの重要性を理解しているか、
開発者のリーダーシップと一致する必要があるか、
といったことです。
理想的なのは会社のリーダーシップが、
DevRelの重要性を理解しているか、
ということです。
悲しいことに多くは理解していないと。
リーダーシップの中に、
DevRelのチャンピオンがいることであると。
それは、
それは、
トラコムですよね。
トラコムの田川さんが、
自らがやっぱりAWSのエヴァンジリストをやっていたっていうのは、
すごく強いですよね。
DevRelの活動とマーケティング
上の人が理解してくれるかどうかっていうのは、
大事なポイントかなという気はしますね。
DevRelはどのようなアクティビティがありますか、
というところで、
これはちょっと多すぎる。
まずテキストコンテンツ。
ブログ、チュートリアル、ケーススタディ、書籍、
ホワイトペーパーなど。
ビデオコンテンツ、
ウェビナー、YouTubeビデオ、
ショートムービー、トレーニングビデオ、
プロモーションビデオ。
スパイ、
カンファレンスでの講演、
ワークショップ、ブースサポート。
イベントの運営、
事業カンファレンス、
コミュニティカンファレンス。
コミュニティの管理、
チャンピオンプログラム、
スラックとか、
Discordのコミュニティ、
サーバーフロー、
オープンソースユーザーコミュニティ、
ドキュメントの作成、
セールスイネーブルメント、
カスタマーミーティング、
カスタマーサポート、
パートナーシップ、
デモ、
ブースのデモとか、
サンプルアプリとか、
再開発とか、
といったところを
いろいろやってきたということですね。
どれが一番良かったかというところで、
私は企業がコンテンツに焦点を当てた活動、
テキストと動画から
最もお得感を得られると考えていると。
これらのコンテンツは
多くのオーディエンスにリーチできる可能性があり、
ロングテール、検索エンジンに取り上げられ、
リリース後もトラフィックを促進し続けることができるからだということですね。
DevRelは通常コミュニティの管理にも非常に長けているが、
それらはしばしば非常に労力を要する活動であり、
多くの企業にとっては贅沢なことかもしれないと。
逆にイベントは最もリスクの高い投資だと思う。
スポンサーになる場合は特にそうだが、
登壇するだけでもと。
金も時間もかかるし、
見返りがはっきりしないことが多い。
イベントをするなと言っているわけではないが、
多くの企業、特に資金調達ラウンドの即後などは、
DevRelがすべてのイベントに参加することを望んでいるとあるある。
でも、もっと慎重にアプローチし、
どのイベントが自社の理想とする顧客像をターゲットにしているのかどうか、
また自社の広範な戦略に合致しているかを検討することをお勧めすると。
CFPやスポンサーシップを一律に提出するのはやめましょうということですね。
KPI、DevRelの正しい測定方法とはというところで、
多くの場合、DevRelは自分が主要な貢献者である活動のトップレベルの成果さえも所有していないと。
例えば、DevRelはお客とのミーティングやセールスイネーブルメントを支援することがあっても、
そのどちらも所有することはないと。
基本的に営業さんのサポートというところですよね。
DevRelはブーススタッフを務め、イベントで講演し、デモを準備しますが、
通常イベントでのリード・ジェネレーションの主な目標はマーケティングにありますと。
これもそうですね。
DevRelはあらゆるコンテンツの作成に大きく貢献していますが、
よりハイレベルの指標、SEOとかコンバージョンの目標は通常他のチームが所有していると。
DevRelが具体的に数字を追いかけて何かするというところが薄いんですよね。
だから、成功責任みたいなものが追いづらいっていうのは確かにありますね。
DevRelが活動全体を所有しているものとしてはコミュニティーが挙げられるというところなんですけれども、
これらの活動の影響を測定するのは非常に困難です。
そうはいえ、この種の活動は定量的なアウトプットに基づき測定するのがベストだと考えている。
例えば、私ならDevRelが直接コントロールできないかもしれないトラフィックを重視するのではなく、
市販機ごとにリリースしたいブログ記事、ビデオ、その他のコンテンツの数を目標に設定します。
コンテンツに収益やリードジェネレーションの目標を追加することは絶対にしない。
というのも、DevRelが作成する種類のコンテンツは一般的に購買ジャーニーにおいて役割は果たすが、
それが直接購買につながることはほとんどないからです。
これは本当その通りだと思いますね。
ブログ全体のトラフィックを前年比25%増加させるようなことを目指すのは妥当な目標だが、
それをチームの成功の直接の指標にするのはためらわれる。
これは本当ダメですね。
DevRelを構成するインセンティブの種類には注意をしたほうがいい。
コンテンツの場合、この目標を達成するためには2つのレバーがある。
コンテンツの量を増やすという方法もあるけど、
これは全体の質を下げる可能性があります。
または、コンテンツのリリースについては、
コンテンツの質を下げる可能性があります。
またはコンテンツの種類を変えるという方法もあるけれども、
これはフリックベイトのようなものを利用することにつながる可能性がある。
また、CBCが必要なコンテンツ、
例えば顧客の重要なペインポイントに対処しているかもしれないが、
大きなトラフィックの権威役になりそうもない投稿に取り組む意欲を失わせる。
CVとかを目標にすると本当にダメですよね。
増やそうと思えばいくらでも増やせますからね。
というところで、この方はですね、
ブログ投稿が月とか市販期にどれくらいの量が期待されるのか、
妥当かを考えるようにしていると。
他の活動を考慮すると、
ある月にアドボケイトを1人当たり2本のブログ記事を書くので、
3人のアドボケイトがいるならば1ヶ月当たり6本、市販期当たりは18本になります。
これが前年より増えている、またはそのために時間を割いているのであれば、
トラフィックは増加するはずであると。
これが前年と同じであれば、
トラフィックの劇的な増加を期待するのは無理があると思うということですね。
イベントでも同じで、参加者の数を目標にするのは無理がある。
これは本当そう思うんだよね。
かといって、何を目標にイベントを実施するかっていうのはね、
本当に難しいところではありますよね。
DevRelはマーケティングなのかという質問に対してなんですけれども、
正解は多かれ少なかれイエスである。
マーケティングという用語が指し示す活動の範囲は、
DevRelが指し示す活動の範囲とかなり重複している。
DevRelをマーケティングと表現することは十分に正確であり、
どちらの用語もいずれにせよかなり曖昧である。
技術畑以外の人々には、私はいつもDevRelを基本的に
マーケティングが嫌いなふりをした開発者向けのマーケティングだと説明していると。
マーケティングが嫌いだという開発者は、
お気に入りの技術系企業のロゴで飾られたTシャツと靴下を身につけ、
様々な技術系企業のステッカーで覆われたノートパソコンを手にしているということですね。
それも一種のマーケティングとしてつけているはずなのに、
自分はマーケティングが嫌いだというふうに言うということですね。
とはいえ、DevRelはマーケティングのサブセットではない。
コミュニティとかはそうですよね。
デベロッパーアドボケイトのキャリアパス
完全にマーケティング寄りというわけではないので。
他の活動とかもそうですけれども、フィードバックループの部分もありますし、
純粋にマーケティングかと言われると、そうではない部分もあるというところですね。
続いてが、デベロッパーアドボケイトのキャリアパスを教えてくださいというところで、
DevRelにとどまるキャリアパスは非常に限られていると。
昇進パスがある会社では、
肩書がジュニア、シニア、プリンシパル、スタッフを向上させることはできると。
これは日本でも呼び方はともあれ、
そういった垂直型のキャリアパスがあるんじゃないかというところではあるんですけど、
デベロッパーアドボケイトは、プロダクトマーケティングマネージャーやプロダクトマネージャーの役割に移行する人もいると。
あとは、エンジニアに提供されるキャリアパスもあるんですけれども、
あとは、プロダクトマーケティングマネージャーやプロダクトマネージャーの役割に移行する人もいると。
あとは、エンジニアに転職することも選択肢の一つ。
もう一つは、セールスエンジニアへの転職というのもある。
ただ、これは決定的なリストではない。
重要なのは、DevRelに上がる道はそれほど多くない一方で、
DevRelから上がる道はたくさんあるということですね。
そうですね。海外とかだとちょっと分からないですけど、
日本だとどうなんでしょうね。
DevRelという組織自体がそんなに創大している感じはしなかったりするので、
多くても3人ぐらいのチームとかで、
そこからの横転がそんなにあるのかな。
プロダクトマネージャーとか、プロダクトマーケティングマネージャーとかの役割は全然行けそうな気はするんですけどね。
DevRelの現状と影響
その後、DevRelの後のキャリアというところは、なかなか見えてこない部分はありますね。
続いて、DevRelは死んだのか、それとも死にかけなのかというところで、
この方自身がDevRelで15年以上のキャリアを積んできた中で、
最悪の後退の真っ只中にいると。
DevRelはマーケティングと密接に連携しているため、
エンジニアリングよりも引き下げの規模が大きく、
ハイテク業界全体でも大きな打撃を受けていると。
このためほとんどの場合、プロダクトやエンジニアリングよりもDevRelの方が大きな打撃を受けているということですね。
私はDevRelとマーケティングの重要性と影響力を理解し評価しているが、
どちらか一方、あるいは両方をカットしたとしても、一般的にはすぐには影響は出ないと。
その影響は一般的にパイプラインが枯渇し、消費者心理が製品に傾き、
最終的に売り上げが悪化する何ヶ月の先に感じられるものだと。
いつ書かれた記事なんだろうな。
いつ書かれた記事かわからないんですけど、
いやいや、もうでもつい先週ぐらいの記事ですね。
今は一番最悪期にあるということですね。
過去の経験からすると、売り上げが悪化する直前くらいに
DevRelとマーケティングを再雇用する可能性があるということですね。
DevRelの雇用はいつ改善されますかというところで、
レイオフの急増と雇用の迷走が始まって、
1年以上が経とうとしていると。
以前であればすぐに好転していただろう。
しかし今はそうではない。
DevRelを採用している企業はほとんどなく、
採用している企業も多くの場合、
ハイブリッドやオンサイトの要件を追加する一方で、
かなり低い給与を提示しているようだということですね。
IT企業の現在のリーダーたちは、従業員と戦争状態にある。
彼らは現在の労働力をAIによって構築された
人工的な労働力に置き換えることに積極的に夢見ている。
さっきのセールスフォースの話がこれですね。
AIが生産性を向上させる可能性を示しているエンジニアとして、
人工的な労働力に対して、
AIが生産性を向上させる可能性を示している
エンジニアリングだけではなく、
マーケティングやデブレルにも影響を与えている。
加えて彼らは自社製品をAIと何らかの形で
連携させるために投資していると。
一方で金利は依然として上昇し、
VCのお金はすごく枯渇状態にある。
存在するとしてもAIに過度に注ぎ込まれており消費されていると。
さらに貿易戦争が激化する中、
アメリカの景気減速あるいは景気交代が
世界的に連鎖するのではないかという懸念があるということですね。
これらは通常のシナリオではない。
残念ながら通常のルールが適用されるとは思えない。
通常であればデブレルとマーケティング部門の
デイオフの影響が今出ているので、
デブレルの雇用市場で状況が好転することを期待しているということですね。
今後の展望とイベント案内
あまりポジティブな終わり方ではないというところではあるんですけれども、
アメリカ企業の余波が日本にどれぐらいで来るかというところかなと。
結構コロナが終わる前ぐらい、
2022年とか1年とかでアメリカとかですごいデブレルの人たちの
レイオフが引き上げた時代はあったんですよね。
意外と日本は全然そういう影響がなくて、
割とないな状態で乗り越えられたかなという気がするんですけど、
今回はどうなんでしょうね。
結構テック企業とかも影響を受けているところが多かったりするので、
外資系企業を中心に影響が出てくる。
という気はしますね。
怖いですね。
というところですね。
今日はニュースはそんなことかな。
結構、今日のこの背景とか見ると、
結構暗いんですよね。
なんでしょうね。
アメリカ人、アメリカ人というか、
白人って目の色がブルーだったりとか、
結構日の入る量を強く感じやすいみたいなことを言われるんですけど、
家の中全体暗いんですよね。
今、記事とか読んでめちゃくちゃ眠くなっちゃうぐらい、
今日本時間朝3時になろうかっていう時間だったりするんで、
一応、時差ボケもほぼ解消して、
今朝は8時間ぐらい眠れたりとかしたんで、
そんなことないかなと思ったんですけど、
この家がずっと暗い状態で1時間ぐらい喋ってると、
なかなか眠くなってきましたね、まだ。
こっちの方が眠くなってきましたね。
こっちは普通の時間で言えば午後の2時だもんな。
そうなんですよね。全然お昼真っ盛りなんですけど。
ランチ食べたっていうのもあると思うんですけど、
めちゃくちゃ眠くなってきましたね。
このラジオが12時間後?
違うな、もっと後。
14時間ぐらい後かに配信されるかなと思う。
ごめんなさい、今日起きていた。
明日か。
まだ24時間以上、先は36時間ぐらい後で配信されるんですけど、
その時ちょっと私は別のところにまた移動開始しているような気がするので、
今回は動画でお伝えしたいと思います。
次回のレベルラジオも予告できます。
もう一度チャレンジしたいことに再チャレンジするというところでやっていきますので、
ぜひ皆さん今のうちにネタを投稿していただいてもいいですし、
もうすでにネタを投稿していただいてもいいですし、
もうすでにネタを投稿していただいてもいいですし、
ぜひ皆さん今のうちにネタを投稿していただいてもいいですし、
もうすでに25日に読まれる予定で投稿していた方は、
対する取り上げられればなと思っておりますので、またよろしくお願いします。
というところで最後イベントのご案内です。
10月の2日から4日、DevRel会議2025というカンファレンスを実施しています。
カンファレンスのプロポーザルCFPは今月末まで1回募集して、
その上でまた第2回を引き続きやっていくという形になっておりますので、
ぜひ皆さんプロポーザル送っていただければと思っております。
では、今日のDevRelラジオ208回目、
今日は特にテーマはなかったんですけれども、
こちらで終了していこうと思います。
また皆さん来週、来週は日本にいる予定です。
次回またお会いしましょう。さようなら。
