DevRel TokyoとDevRel Radioの紹介
はい、みなさんお疲れ様です。夕方5時半になりました。DevRel Radioのですね、今日は152回目ですね。どんな本を書いてみたい、お届けしていこうと思います。
まず最初にですね、DevRel Radioの紹介ですね。DevRel Radioはですね、DevRel Tokyoでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間ぐらいお届けしているというものになります。
DevRelっていうのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような職業のエヴァンジリストとかアドボケイトとか、あとコミュニティマネージャーとですね、そういった方々が集まって情報交換したりコミュニケーションするといったようなコミュニティになっております。
もしですね、あなたがDevRelに関わるという方とかですね、これからどんどん関わっていきたいという方はですね、スラックがあります。
公式サイトのDevRel Tokyoというサイトからですね、参加することができますので、ぜひスラックに参加していただければと思います。
そこまでじゃないよという方はですね、Xがあります。
あとDevRel Tokyoですね。そちらの方で普段はハッシュタグシャープDevRelJPというのをつけてツイートしてますんで、アカウントとかハッシュタグとかをフォローしていただけるとありがたいですというところで、一通り案内は終わりかな。
はい、今日はですね、夕方普段5時半なんですけれども、たぶんその時間私がちょっと別な要件があってですね、たぶんライブでやるの難しそうだなという気がしたので、急遽ですね、アーカイブで今レコーディングをしているというところですね。
なので、ラジオのメインテーマの方ですね。そちらは、そうですね、既に回答していただいている方もいるので、そちらは後ほど取り上げていこうかなと思います。
はい、ちょっと今からですね、投稿いただいてもちょっと取り上げることができないので、その方はごめんなさいというところですね。
本日のメインテーマはどんな本を書いてみたいというところで、確か技術書店もそろそろなんですよね。
まだ発表されてないんでしたっけ。いや、もう発表されているのかな。予定がたぶん5月、6月開催みたいですね。
というところで、技術書店であったりとか、あと技書博とかですね。あと何でしたっけ、Zeniketみたいな、そんなような技術者向けのやつとかもあったりとかして、
自分で本を書いて販布する機会って結構増えているのかなというところですし、あと電子書籍であればね、Zenで全パブリケーションでしたっけ、書籍書くこともできますし、
KDPでAmazonで売ることもできるというところで、何か書きたいという思いがあれば、全然それをどんなことをしても簡単に出版できるようになっているというところで、皆さんがですね、
あなたがこの後書いてみたいという本があればですね、ぜひその意見を聞ければなと思っております。
技術ブログの情報収集方法
というところでですね、それは後半にやっていくとして、まずはですね、最近のDevRel周りに関するニュースをお届けしていこうかなと思っているんですけれども、
まず最初がですね、これはレバテックラボさんですね。
継続のコツは、わざわざ見に行くをなくすこと?フロントエンドエキスパート水ドラの情報収集術という記事が上がっております。
この中で、これは連載らしいんですけれども、アフターツイッター時代の情報収集と題したこの連載となっておりますね。
ツイッターを完全に代替できるサービスはまだ存在しないと書いてありますね。そうなんですよね、本当に。
結局なんでしょうね。スレッズにしても、あとミスキーでしたっけ?ちょっと読み方が間違ったら申し訳ないんですけれども、ミスキーだと思うんですよね。
ミスキーとかマストドンとかブルースカイとか、色々Xに変わるようなものってボコボコ。
去年、一昨年ぐらいから生まれたかなという気がするんですけど、なかなか乗り換えるっていう存在にはなりづらいかなという気がするんですよね。
マストドンなんかどのぐらい前でしたっけね。5年ぐらい前とかですかね。マストドンサーバーが乱立する時代とかもあったと思うんですよね。
何でしたっけ。ニコ動であったりとか、あといろんなユーザーが集まっているようなサービスとかで、ピクシブとかもそうでしたっけね。
マストドンサーバーとか立てた覚えがあるんですけど、結局定着してないかわかんないですけど、メジャーにはなりきれずに終わってるなっていう感じですよね。
というのもありつつというところで、水泥さんは情報収集には基本、X、TwitterとあとGitHubしか使っていないということですね。
面倒くさがりなので、必要な情報は全てこの2つに流れてくるように工夫していますということで、
分野を絞らずに気になる情報をまんべんなく集めるならTwitter、自分が使っている言語やフレームワークにまつわる具体性の高い最新情報を集めるならGitHubと使い分けているということですね。
インプットのルーティンが、まず毎日始業前から始業後の30分程度、朝食を食べながらTwitterを眺めて気になる情報に目を通しているということですね。
そして、Xを見ていって気になる情報があったらその場でしっかり読んでいくというふうにしているということですね。
分量の多いものに関しては、Chromeのタブとして開いておいて業務の合間に読むようにしているということですね。
はてなの方なんですけれども、はて文は使っていないのかな。
ポケットを使っていたということなんですけど、ポケットに追加すると未読のまま残っちゃっているということが多かったので、
ポケットを開く手間とかを考えると、Chromeのタブで残しておいて、そのまま読んだら消すというのを繰り返しているということですね。
GitHubでも知りたい情報は全部ノーティフィケーションを使ってチェックできるようにしているということですね。
TwitterもGitHubも情報収集のためには、自ら情報を取りに行かなくてもいいような仕組みを作っているということですね。
手間のかからない方法に落ち着いたというふうに書いてあります。
最初はいわゆるRSSリーダー、フィードリーダーを使って、気になった技術ブログのフィードを公読していたんですけれども、
フィードリーダー自体を開くというのが億劫で挫折してしまったということですね。
個人的には、昔MoonGiftというサイトをやっていたときは、オープンソースの情報を収集するのに、あれはフィードリーというRSSリーダーを使っていたんですよね。
もうMoonGiftの更新をやめた段階で、1回もフィードリーダーを読まなくなってしまって、
最近DevRelに関するものだけ収集するようにして、リソースが全然少ないので、
多分5、6個ぐらいしかないのかな。4つぐらいしかないですね。
なので、1日1回じゃないかな。2日に1回ぐらいチェックして、今3件ぐらいだけ新しいのがあるみたいな。
そのぐらいのペースで今やってますね。
全然、昔に比べると情報収集のペースが個人的には落ちてるなというふうには思いますね。
移り行くトレンドはあえて追わないと。
情報があふれ返ってしまっているし、水空さんがフォーカスしている領域はフロントエンドというところで、
分野自体が幅広いということがあるので、かつトレンドの移り変わりが激しいということですね。
フロントエンド領域の情報量が多い理由というのを3つ挙げてるんですけれども、
トレンドの移り変わりが激しいことが1つ。
もう1つは人が多い、関わる人が多いということですね。
そのために発信される情報の総量が多い。
かつフロントエンドという言葉に内包される分野が幅広いということですね。
そういうこともあるんで、素直に自分の興味関心を情報収集の軸にしていると。
その知的好奇心の延長で情報収集をしていれば、自然と必要な情報も拾えると。
かつトレンドをひたすら追う必要もないというふうに書いてありますね。
どうしても新しい技術が出てくると目移りしちゃうんですけどね。
それを追っていると、いくら時間あっても足りないと。
自分がやっていることに対して不信感というか疑問とか持ち始めちゃうと、
なかなかモチベーションが上がらなくなったりする可能性もあるので、
あえて見ないという選択肢もいいのかなという気はしますね。
これまで最新より少し遅れたタイミングでキャッチアップして、
遅かったと感じることもなかったというふうに書いてありますね。
これも本当そう思いますね。
そして技術選定の新美眼を鍛えると、取捨選択に自信が持てるということですね。
この技術選定の新美眼というのはT和田さんが2018年のデブサミで紹介していたものです。
必要なもの、逃してはならないものは取って、そうではないものをスルーするというのが新美眼ということですね。
技術に対してその技術が生まれることによってどんな課題が解決できるのか、
またその課題は解決に値するものなのかというのを考えるというのが新美眼につながっていくというふうに書いてありますね。
生き残る技術は得てして今まで解決できなかった重要度の高い課題を解決しているものですというふうにも書いてありますね。
例えばWebフロントエンドでは以前はSPAが流行りましたが、今はSSRが推奨されていますと。
SSRは単に高発だったから広まったわけではなく、SPAでは解決が難しかったパフォーマンスやSEOの問題を解決できるから受け入れられたのですということですね。
確かにね、いろいろフロントエンドに限らないですけどね、新しいキーワードいろいろ出るんですけどね。
だいたい1年ぐらい経つと、そんなキーワードあったねみたいな時ってありますよね。
Jamstackとかもありましたけど、どうなんでしょうね。今生き残っているのかな。
もう最近全然聞かないような気がしますね。
水泥さんの情報収集に関するモットーというのが習慣化すると。
あとは好奇心に逆らわないと。
あとは神秘眼を鍛えるという点を挙げていますね。
逆にDevRelに関わる方々からすると、こういう方々にキャッチアップしてもらわなきゃいけないというところがあるんで。
トレンドになったりとかキャッチアップになりすぎないと、
何かの課題に対してそれを解決するための技術だというのをちゃんと説明できなきゃいけないのかなという気がしましたね。
では続いてですね。
コミュニティの定義とコミュニティへの参加
こちらは禅の記事なんですけれども。
初学者にコンソを伝えたい。
view.jsコミュニティ入門という記事ですね。
こちらはコミュニティとはグラデーションであるというふうに書いてありますね。
まず一つ目のトピックがあなたがコミュニティの一員であるかどうか。
回答、それは分かりませんというふうに書いてあります。
自分がコミュニティの一員であるかというところを考える上でですね、
まずコミュニティとは何だろうかということが書いてあります。
この記事の中ではですね、コミュニティとはグラデーションですと。
そのはっきりとした枠組みがあって、
ここはコミュニティ。
これ以外はコミュニティじゃないみたいな感じになっているわけじゃないということですね。
ふわっとしていて、それもきれいな円形ではなくて、
ちょっと歪んだ形になっていて、
グラデーションで端っこのほうはぼやけていてという感じで、
当然中心のほうは濃かったりすると思うんですけれども、
コミュニティというのははっきりとした領域があるわけではなくて、
すごく薄いところも関わっている人がいれば、
すごく濃く関わっている人もいるということですね。
何がView.jsコミュニティであって、
何がView.jsコミュニティでないかは、
明確な境界線がないのですということですね。
あなたがコミュニティの一員であるかそうでないかについても、
明確な境界がないということですと書いてあります。
これはなかなか学びがありますね。
既存のコミュニティメンバーからあなたに対して、
今日からあなたはコミュニティの一員ですというメールが届くようなことはありません。
では何がそうさせているのかということですね。
それはあなたの普段の行動であったり、
周りからの見え方であったりしますと。
そしてあなたという1サンプルの他にもいろんなサンプルの集合体で
曖昧な輪郭を表すのがコミュニティですということですね。
確かに。
コミュニティの輪郭と特徴
例えそんなに良くないですけど、
京都とかってすごく内輪な社会コミュニティってよく言われて、
言葉遣い一つとっても裏の意味がわからない場合とかっていう、
区別するみたいな話があったりとか、
北と南でまた考え方の違いがあるみたいなところもありますし、
東京みたいな江戸っ子とかだと、
三代続かないと江戸っ子って呼ばれないみたいな話もあるし、
逆に横浜とかって3日住むと浜っ子みたいな感じで、
すごい緩いみたいな話もあったりするんで、
コミュニティによって、
何を持ってあなたが一員ですみたいなのは、
はっきりとはしないというところですよね。
いろんなサンプル、いろんな方のいろんな周りからの見え方があって、
それによって曖昧な輪郭を表すのがコミュニティだということですね。
コミュニティというのは、
特定の誰かが持つ何かの条件によって決まるものではありません。
一人一人の行動や雰囲気などがたくさん集まって、
そこになんとなく現れるものですということですね。
この方がですね、この方って言っても、
これ多分ビュービギナーズっていう、
ビュー.jsの初学者向けの情報を発信しているユーザーなんですけれども、
その方がどうしてそんな話をしたいのかというところで、
自分の行動がビュー.jsにとってどう移るのかということを
常に意識してほしいからですということですね。
コミュニティの一員になったらとか、有名になったらとか、
コントリビューターになったら気をつけるではないのですと。
みんなグラジュアリーにコミュニティの一員なんですよね。
深く関わってないところに関わらず。
みんながいい行動をとることによって、
ビュー.jsの人たちはマナーがいいという雰囲気になったりとか、
逆に誰かがマナーの悪いことをすると、
ビュー.jsの人たちはマナーが悪いみたいな感じの雰囲気になるということですね。
なぜコミュニティが大事なのかというところで、
ビュー.jsの成り立ち自体がコミュニティがあるからこそということですね。
ビュー.jsを通じたマナーの重要性
当然、もともとの開発者の方をはじめに、
多くのコミュニティメンバーによって成り立ってはいるんですけれども、
コミュニティがなければそもそもビュー.jsが成り立たないという点が重要だということですね。
忘れてほしくないこととしては、その技術の裏にいる人々に対するリスペクトですというふうに書いてありますね。
こういうのもきちんと名文化しないと、なかなか理解してもらいづらい部分はありますよね。
雰囲気でわかるよねっていうところも、そういうふうに深く関わっている方からしたら期待してしまうところがあるのかなという気がするんですけれども、
なかなかこれをしたらビュー.jsコミュニティの一員みたいなものがないと、
ちょっと傍観者でいる人もいれば、逆に自分は一員なんだというふうに思ってくれる人もいるみたいな感じになるでしょうし、
コミュニティって本当に難しいですよね。それだけに面白いんですけどね。
初学者にこそ伝えたいビュー.jsコミュニティ入門という記事になっております。
続いて、こちらはスピーカーデックの記事ですね。
コンテンツマーケティングの戦略設計。取り組むべきはオーディエンスビルディングという記事がですね。
こちらは会社名が株式会社シンシという会社ですね。
こちらの市島さんのスライドですね。
まずコンテンツマーケティングの定義なんですけれども、
コンテンツマーケティングとは明確に定義されたオーディエンスを魅了して関係性を保つために、
興味関心に沿った価値あるコンテンツを制作し配信する戦略的なマーケティングアプローチのこと。
その最終的な目的は収益性の高い顧客行動の促進であるというふうに書いてありますね。
コンテンツイズキングって言われるぐらいコンテンツはとても大事ですよね。
コンテンツマーケティングはあなたが何を売るかではなく、あなたが何を象徴するかであるというふうに書いてあります。
コンテンツを起点にして企業が特定領域を象徴する存在としてオーディエンスに認識されることがコンテンツマーケティングの一つの在り方と。
これはオンドメディアとかも若干それに近い雰囲気がありますけど、いわゆるブログの会社とかもそうですよね。
AWSといえばみたいな感じのそういう雰囲気を作るっていうのはね、あれはもうまさにコンテンツマーケティングの成功例というふうに言えるんじゃないかなと思いますね。
そういったことが書いてある中でですね、コンテンツマーケティングの4つの戦略軸っていうのが書いてあります。
これはオーディエンスを中心としていて、その周りに3つあるんですけれども、1つはコンテンツですね。これは当たり前だと思うんですけれども。
あともう1つはディストリビューション、配信チャンネルですね。あとはエンゲージメント獲得っていうこの3つの戦略軸が書いてあります。
まずコンテンツに関して言うと、誰にどのような需要に対してどのような流通経路でどういうコンテンツを届けるかという話ですね。
ディストリビューションについて言うと、自分たちが所有しているチャンネルであったりとか、あと利用できる他社のチャンネルとかですね。
そういったチャンネルを並べていって、最適なコンテンツを配信するみたいな感じですね。
エンゲージメントに関してなんですけれども、まず一番浅いレベルだと認知、閲覧、利用みたいなところで、
それよりももうちょっと深くなると理解とか、さらにコメントみたいなところの反応、評価、コメントとかですね。
あとは関連コンテンツへのアクセスとか、あとはリレーションを持つ交流とか、あとは再訪問とか問い合わせとか購入とかですね。
あとはさらに推薦みたいなところをファネルで深くしていくみたいな感じですね。
この考え方自体はかなりDevRelに近いのかなと思いますね。
分かりやすい考え方かなと思いますね。
どっちかというと、認知される方のDevRelですね。
その後のユーザーになってからのDevRelというよりは、ユーザーになるまでのDevRelに関係してくるのかなという気はしますかね。
当然ですね、その4つの戦略軸を全部ですね、網羅的にやっていくというのは難しいので、資源が限られる中なので選択あるいは優先度を設けるべきというふうに書いてあります。
コンテンツマーケティングの目的、ゴール、戦略を決めるというところで、全部で5つの段階がありますかね。
まず目的を決める、次に戦略を決める、その戦略に沿って戦術を決める、計測してゴールを達成するというところですね。
これもすごい分かりやすいですね。これもやっぱりDevRelと変わらないなという気がしますね。
まず戦略に関してなんですけれども、目的は決まっているわけで、戦略どうやって考えるかというところだと、リソースの再分配であるということですね。
よくあるところだと人、物、金みたいな、あとは時間とか、もともとの自社のノウハウみたいなところですね。
そういったリソースをどういうふうに配分して戦略を立てていくかということになるということですね。
あとはコンテンツマーケティングは、成果が出始めるまでに1、2年と長い期間を要すると、さらに難易度も年々高くなっているということですね。
本当にね、これもDevRelと変わらないかなという気はしますかね。
更新頻度っていうところの更新の問題、あとは質の問題っていうのも入ってますね。
あとは成果の問題という、その3つの問題、更新、質、成果、この3つの問題を挙げてますね。
すごいこれも通ずるものがあるなという気はしますね。
そして、そこから具体的なさっきのオーディエンスの話とかに入るんですけれども、
まずオーディエンスビルディングっていうところで、オーディエンスって何かというところを定義してあるんですけど、
コンテンツマーケティングの戦略的アプローチ
一定の熱量を伴った関係性を持つ、再アプローチ可能なユーザー群、
高読者、フォロワーというふうに書いてありますね。
オーディエンスビルディングで取り組むこととしては、まずディスカバリーでオーディエンスの発見、これは調査というところですね。
続いてプロモーション、コンテンツの告知と拡散。
最後はコネクションでオーディエンスとの関係性構築、エンゲージメント獲得というその3段階を掲げてありますね。
再アプローチ可能っていうのはなかなか難しいところですよね。
単にPVやトラフィック規模を追うのではなく、再アプローチ可能なユーザーリストを作り、
エンゲージメントを獲得しアクティブにするということですね。
例えば、XとかYouTube、あとはTikTokとかFacebookとか、そういったソーシャルメディアのフォロワーにしていくという動きであったりとか、
あとは会員登録してもらうとかですかね。
そういった形でプールをしていくということですね。
これはC層が書いてあるんですけれども、会員登録とか購入履歴とか、
あとはアプリ内での行動データみたいなもののグルーピングの方がソーシャルメディアよりは重たいというふうには書いてありますね。
これか、ファーストパーティーデータを意識すると。
アプローチ制限の可能性がある他社プラットフォームに依存するのではなく、
自社で収集するファーストパーティーデータを意識するということですね。
当然、Xのフォロワーとかに対してはアプローチするにしてもDMがせいぜいだったりとかしますからね。
それだと再アプローチするときの制限というのは若干生じてしまうということですかね。
なので、ユーザーのフォローとか会員登録のしやすさとかを考えると、
ソーシャルメディアの方がお互いいい塩梅なのかなという気もしなくもないんですけどね。
ただ、YouTubeのフォロワーとか増やしてもなかなかアプローチというところが難しいというのは確かに分かる気はしますかね。
そして、何よりもオーディエンスがいることによって判定したトラフィックが期待できるということですね。
検索エンジンベースとかのオーガニックな場合だと、
その時は来てくれたとしても次に再来訪してくれるという可能性が分からないので、
下積みがしづらいということですかね。
オーディエンスビルディングによるレバレッジ効果、その下積みの部分ですよね。
オーディエンスがきちんと構築できていれば、
その後のディストリビューションとかエンゲージメント獲得の部分にも効いてくるということだと思いますね。
どうなんだろうな。オーディエンスがある程度分かってしまっていると、
エンゲージメントにつながらない気がするんですよね。
新規獲得をどんどんしていかないと。
新規がオーディエンスとして獲得できればいいんですけど、
どっちかというとGoogleとかオーガニックから来てくれる方が若干多い気はするので、
でもXとかでリポストしてくれたりとか拡散してくれたりすると、
それが新規のユーザー獲得とかにつながっていく可能性はあるんで、
レバレッジは効くのかな。
そしてコンテンツマーケティングの質の問題、成果の問題、
これを解決する土台はオーディエンスビルディングにあると。
そうなんですね。
まず更新の問題、更新頻度、運用体制、社内評価みたいなものがあり、
それはコンテンツのオーディエンスをきちんと聞かせていくことによって
閲覧してもらえるとか、レビューがもらえるとか、コメントがもらえるみたいなところで、
多分気持ち的なところだと思うんですけどね。
それが成果につながっていくということかなと思いますね。
ページビューばかりに注目が集まり、どれだけ関係性のあるユーザーを作れたかは
ないがしろにされがちであると。
もっとオーディエンスへ注目しましょうというふうに書いてありますね。
これは本当にそう思いますね。
ページビューはあまりKPIとしてよくないと思うんですよね。
これはどういう意味だ。
オーディエンスとの関係性の段階と種類というのが挙がっていて、
縦軸がチャンネルですね。
ソーシャルメディアと動画とポッドキャスト、メール、アプリ、ファンプログラムみたいな感じになっていて、
横軸がパネルになってるんですけど、
最初、非読者の方が認知するというところから始まって、
興味を持ってくれた人が通りすがりになり、
興味を何回持ってくれたら再来、再訪問ユーザーに変わると。
コンテンツマーケティングの戦略設計
それを超えると登録してくれて初期高読者になり、
さらに継続してくれると高読者になって、最後コンバージョンが効いてきて、
VR高読者とか購入者につながっていくということですね。
そのときに最初の取っ掛かりとしていいやつが、
ソーシャルメディアとか動画、ポッドキャスト、
あとはホワイトペーパーとかの資料請求っていうのを上げてますね。
そこからまず入ってきてもらって、
興味を持ったらニュースレターの登録をしたり、
LINEの登録をしたり、アプリをダウンロードして、
とりあえずゲストで使うというのが始まりということですね。
何回も訪れていくうちに登録しようかなというふうになっていくと、
そのときに効いてくるのが、アプリで会員プログラムになるというのがここだと上がってますかね。
LINEとかソーシャルメディアとか全部そうなんですけれども、
だんだんロイヤリティが濃くなっていって、
最終的にコミュニティのアンバサダープログラムみたいなものに登録する段階につながっていくというふうに書いてありますね。
ここら辺は多分コンテンツの部分である程度収益を考えたりするのかな、きっと。
コンテンツとDevRelで提供しているサービスとで、
ここまで密接に、
ここまで高読者がユーザーにつながるみたいなのが、
ちょっと動線が難しい場合があるかもしれないんで、
ロイヤリティ高読者を作るっていうのがDevRelにどれぐらい意味があるのかというのはちょっとわからないですけれども、
この考え方はすごく面白いなと思いますね。
面白そうなのは、
コンテンツに関するところは、コンテンツで考えるのは、
誰に、どのような需要に、どのような流通で、どのようなコンテンツを届けるかということですね。
コンテンツの分類、ストックとフロー、新規作成、編集、パッケージ、最後に最適なフォーマットっていうのが書いてあります。
面白そうなのは、コンテンツで考えるべきところですね。
自分たちだからこそ伝えられることが大事なところと、
これはバリュープロポジションと書いてありますね。
自分たちも見たいものというのがさらに大事であるということですね。
他者も伝えられることっていうのが一定の割合を占めるのは避けられないですけれども、
自分たちだからこそ伝えられることとか、自分たちも見たいものというのを意識する必要があるということですね。
コンテンツの種類はいろいろありますね。
認知、コンバージョン、感情的、理性的っていう二軸で書いてあるんですけれども、いろいろあるな。
インフォグラフィックとか電子書籍とかコミュニティフォーラムとか事例紹介、シミュレーションとかいろいろありますね。
この中で多分DevRelで使えるものもいくつかあるかなと思いますね。
そしてコンテンツの分類についてなんですけれども、これは3つありますね。
ヒーローとハブとヘルプ、全部で3Hですね。
まずヒーローコンテンツというのは話題性のある注目を集めるコンテンツ。
幅広い顧客層にリーチして認知や興味関心を獲得するというのが目的というものですね。
ハブコンテンツというのは顧客層との関係性構築のためのコンテンツと、
主にすでに関係性のある顧客層に向けたプッシュ型コンテンツというふうに書いてあります。
最後ヘルプですね。具体的な課題や疑問を解決するコンテンツ。
日常的に検索されるプル型のコンテンツで関係性構築のきっかけをつけるということですね。
これはすごく分かりやすいですね。
こういうヒーローハブヘルプって付けてくれるととても分かりやすいですね。
ヒーローっていうのはすごく目立つコンテンツですよね。
どっかのカンファレンスのものかもしれないし、最新トレンドの技術記事かもしれないしみたいな、そういう感じですかね。
ハブコンテンツっていうのは既存のユーザーに対するコンテンツなんで、
バージョンアップの記事であったりとか、既にユーザーの方々にさらに使い込んでもらうためのコンテンツということですね。
AIによる仕事の代替
最後ヘルプコンテンツっていうのは何でしょうね。まとめ記事もそうだと思いますし、
もうちょっとヒーローほどじゃない、もうちょっとライトな技術動向に関する記事とかが入るかなという気がしますかね。
どちらかというとヘルプコンテンツ、一番浅いコンテンツが一番多くて、その上にハブコンテンツ、既にユーザーになっている方向けのコンテンツがあり、
最後にヒーローコンテンツで目立つものが一番少ないですけれどもあるということですね。
これはthinkwithgoogle.comっていうところで掲載されてたコンテンツなのかな。
Googleが2014年に動画コンテンツのマーケティング活用として提唱したコンテンツ分類のモデルというふうに書いてありますね。
これがヒーローハブヘルプコンテンツの考え方ですね。
コンテンツをユーザーのライフステージで分類というところで3つあるんですけれども、
頭風、毛風、防風というその3つですね。
まずはボトムオブザファネルで防風。
これはヘルプコンテンツが一番大きくタイプということですね。
続いては毛風、ミドルオブザファネル、中間というところでこれはハブコンテンツが効いてくるというところで、
メディアのリテンション評価が大事になってくるということですね。
最後頭風、トップオブザファネルのところはヒーローとヘルプコンテンツで集客力の評価というのが効いてくるものだというふうに書いてありますね。
あとはコンテンツに関してはストック型のコンテンツとフロー型のコンテンツと、
どうしてもブログとかになるとフロー型のコンテンツが多くなりがちなのかなという気はしますし、
あとはソーシャルメディアとかもそうかなという気はしますかね。
短期間での利用を想定したコンテンツ、話題性や興味関心の喚起が必要というところですね。
ストック型のコンテンツというのは長期間の利用が期待できるコンテンツで、検索性の確保が必要ということですね。
なのでストック型のコンテンツについて言えば、ちゃんと検索されるような場所に配信する必要があるし、
フロー型のコンテンツについては話題性を持てるような、バズれば強いみたいなところに配信する必要があるということかなと思いますね。
なかなかこれは役立ちますね。
まず38ページでまだ半分いってないぐらいだもんな。
すごい役立つコンテンツかなと思いますね。
別にデフレルに限ったコンテンツマーケティングの話じゃないんで、
多分使える分、使えない分ってあるかなという気はするんですけれども、
それでもすごく使える部分はめちゃくちゃあるんじゃないかなという気はしますね。
こちらの記事ですね。コンテンツマーケティングの戦略設計というスライド、ぜひご覧いただければと思いますね。
続いての記事ですね。
こちらはプレジデントオンラインなんですけれども、私が見ているのはYahooニュースかな。
プログラマーは大量失業の恐れ、ペンシルバニア大の最新研究、
ChatGPTで8割の働き方が変わるの意味という記事が出ております。
そうですね。安泰だったプログラマーは大量失業時代に突入というふうに書いてありますね。
個人的にも結構これは危惧している部分はあるんですよね。
プログラマーが足りないみたいなこと言われてましたけど、
結構あっという間にChatGPTに、ChatGPTというか生成AI系にとって変わられる可能性があるんじゃないかなという気がしているんですよね。
ホワイトカラーが担っている仕事の約30%はAIによって代替される可能性が高いというふうに書いてありますね。
結構これが個人的には戦略をある程度練れてるんで、どうにかなるかなという気がしてるんですけど、
子供とかってどうなんですかね。皆さんのお子さんいらっしゃる方いらっしゃらない方いらっしゃると思うんですけれども、
お子さんがいらっしゃるとして、もう20歳超えてたら就職してればどうでもいいんですけれども、
小学校とか中学校とか高校生とかのお子さんとかがこれから職業に就くという時に自分たちの背中を見せていると、
プログラマーとかになりたいって思われても結構辛いんじゃないかなという気がしてるんですよね。
勝ち目がないんじゃないかという気がしていて、
じゃあそのホワイトカラー系が30%代替されるって言われていて、
どんな職業だったら安泰っていうのはなかなか難しいかなと思うんですけれども、
じゃあどんな職業だったら今後40年50年とか安心して生活していけるんですかね。
DevRelの職種
本当にプログラマーは結構絶望的な気がするんですよね。
今後50年はやばいなっていう。
少なくともあと10年ぐらいでもう未来が大きく変わっているような気がしているので、
私はちょっと自分の子供にプログラマーはとてもお勧めできないなっていう気はしてますね。
じゃあ何になったらいいんだっていうところで、
例えば修行とかそういう会計士とか行政書士とか社老子とかありますけど、
ああいう修行とかもクラウドサービスとか見るともうそっちの方がめちゃくちゃ楽ですよね。
もう依頼しなくなっちゃってたりとかするんで、
そういうのを踏まえると自分が使ってないサービスの職業とかっていうのもまた結構厳しいなっていう気がしていますね。
どんな職業がいいんですかね。
生成AIはホワイトカラーにこそ大きな影響を与え、その仕事を奪う可能性が高いことを常に心に留めておく必要がありそうですっていうふうに最後書いてありますね。
本当にその通りですとしか言いようがない感じですね。
あとは海外系の方だと何かあったかな。
何か面白い記事。最近ですとこれはどうなんだろうな。
これはコートニーロバートソンという方の記事で、
関係者との関係性を探るオープンソースとワードプレスコミュニティの形成という記事で、
この方はGoDaddyですね。
GoDaddyのウェブデザイナー兼開発者アドボケイトを担当しているコートニーロバートソンさんですね。
GoDaddyでもDevRelをやっているということですね。
まずそのDevRelに関わる職業というところで、
全部で1,2,3,4,5,6,7,8個意外と上げてくれている。
エデュケーターですね。
まず1つがデベロッパー向けのエデュケーターと。
2個目がテクニカルライザー。
3つ目がマーケティング担当者。
4つ目がイベントマーケティング担当者。
もう1つがフィールドマーケティングというところと、
あとは開発者エキスペリエンスエンジニア。
これは面白いですね。
SDK APIの使いやすさに重点を置き、
開発者の製品インタラクションを強化するというのが、
開発者エキスペリエンスエンジニアというものと書いてありますね。
あとはプログラムマネージャー。
イベントやスポンサーシップなどのデブレルアクティビティを企画する人と。
最後はオープンソースプログラムのディレクターまたはマネージャーというのが、
GoDaddyの、あともあれですね。
エヴァンジェリストアドボケイトというのも書いてあるんですけれども、
そのあたりがGoDaddyのデブレルに関わる職ということですね。
GoDaddyのアドボケイトとしてワードプレスに貢献することは、
GoDaddyのサービスを強化し、ワードプレスをより深く理解するという、
私の役割の中核目標と一致しています。
それはコミュニティと関わり、知識を共有し、
ワードプレスの成長に直接貢献することです。
それによってユーザーのニーズと課題についてのインサイトが得られ、
GoDaddyのサービスがワードプレスユーザーにとって適切であり、
有益であり続けることが保証されますと。
GoDaddyはワードプレスコミュニティに結構強化しているんですね。
結構職務7つ、8つぐらいあって面白いですね。
では続いての記事で、これは個人の名前がわからないんですけれども、
What Debrel means to meという記事なんで、
Debrelが自分にとってどんな意味を持っているのかという記事ですね。
記事がどこに行ってしまった。記事がなくなってしまった。
だめだ、記事が探せなくなってしまいました。別のやつにしよう。
こっちの記事にしようかな。
Debrelコアの記事とコミュニティ生成コンテンツ
前にも何件か紹介したDebrelコアの記事ですね。
知識を満喫、コミュニティ生成のジャンクと厳選されたグルメコンテンツの戦いという記事ですね。
コミュニティ生成コンテンツというのをジャンクフードと称していますというところで、
コミュニティ生成コンテンツの長所というのは、まずいろんなところにあると。
インターネット接続があればほぼ誰でも簡単にアクセスできるというのが魅力と。
2番目は多様性というところで、いろんな種類のコンテンツがあるというのが魅力と。
最後はインタラクティブ性というところで、コミュニティとの関わりが促進され、
ユーザーがより会話にコミュニケーションに引き込まれるというメリットがある一方なんですけれども、
ここでは栄養価が低いと。
コミュニティが生成するコンテンツの多くはゼロカロリーに相当し、
実質が欠けており、知的成長や批判的思考に貢献できないとか、品質に関する懸念があるとか、
あとはプラットフォームの中毒性の設計により継続的な消費が促進され、
有意義な関与が理解が得られないまま情報型につながります。
なかなか難しい問題ですね、確かにね。
最近は本当にチャットGPTの言葉とか、あと何か意味のないまとめ記事とかもたくさん増えたりするんで、
コミュニティ生成コンテンツの良し悪しっていうのも確かにあるのかなという気はしますね。
ではちょっと時間が押しているというところもあるんで、
今日のメインテーマですね。
どんな本を書いてみたいか
どんな本を書いてみたいというテーマで、
今日は1件だけご意見いただいているのでお読みいたします。
DevRelName 札幌のじゅんさんからですね。
いつもありがとうございます。
基本的には求められる本を書いてみたいと思っています。
最近だとイベント運営の省エネ化を追求しているので、そのあたりは細かくアウトプットしています。
雑多なブログ記事の中からエッセンスを読み取ってほしいなとも思っています。
あとこれはほとんど形にしたことはないのですが、
技術コミュニティ運営者としてあえてやらないと決めている運営上の施策などは、
霊災コミュニティの寿命を伸ばす上で非常に効いていると思っています。
この中には一般的にやった方がいいとされているものもあるはずですが、
地域のエンジニアの性格を考えて、やはり相対的に違うと思っていたりもします。
いざ書くとなると主語の範囲のコントロールが難しくなるので、
よほど頭のいい時でないと書けないので、
その時期ではないという感じですというふうにコメントをくれてますね。
ありがとうございます。
そうですよね。求められる本を書くべきだというのは本当に分かりますよね。
私とか書きたい本を書いちゃうんで、それが売れるとか全く気にしたことがないので、
やっぱり求められる本を書くべきですよね。
あとは売れる本を書くべきだというのは強く強く思いますよね。
その中で自分がどんな内容で書けるかというところで、
面白いのはこのイベント運営の省エネ化ですよね。
霊災コミュニティの寿命を延ばすというところは、
とても大事なポイントな気はしますかね。
あとは地域のエンジニアの性格を考えるというところですかね。
やっぱりコミュニティって一個の正解はないですよね。
これやったらいいとかいうのは全然なくて、
地域によっても違うし、プロダクトによっても違うし、
プロダクトのステージによっても違うし、
コミュニティメンバーによっても全然違ったりするんで、
一概にこれやるべきとか、これやらなきゃダメとかいうのは全然ないと思うんですよね。
なのでその中で地域のエンジニアの性格を考えた上で、
こういうふうにしたほうがいいとか、
これはやらないほうがいいんじゃないかみたいな、
そういうトライアンドエラーをいろいろやったほうがいいと思いますし、
その結果はどんどんアウトプットしてくれるといいなと思いますね。
ただこの最後にありますけど、守護の範囲のコントロールね。
北海道のエンジニアはとか、札幌のエンジニアはとか、
そんなでかい守護で言うと炎上する可能性があるんで、
あくまでも自分の知っている範囲に留めて、
守護をちっちゃくしないと炎上リスクはあるんですけど、
ただちっちゃいと、それってあなたのところではそうだよねみたいな感じで、
それはそれで湾曲して受け止められちゃう可能性があるんで、
そこは心配が、心配というか注意が必要かなという気はしますかね。
でも求められる本を書くというのはとても大事なポイントかなという気はしましたね。
ではですね、次回のイベントのご案内で、
次回はですね、3月23日ですね。
23日土曜日にCMCミートアップさんとのジョイントイベントを企画しております。
もうそろそろですね、イベントページ公開できるかなと思いますんで、
ぜひぜひまずセーブデートしてお待ちいただければと思っております。
ということでですね、今日のDevRelラジオ152回目ですね。
どんな本を書いてみたいか。
こちらで配信を終了しようかなと思います。
また来週ですね。
次回も予定がいろいろ詰まってたような気がするんだよな。
大丈夫かな。
大丈夫か。
大丈夫ですね。
来週は大丈夫そうですね。
ライブで配信できるかと思いますんで、また皆さん来週お会いしましょう。
さよなら。
