DevRelラジオの紹介
皆さんお疲れ様です。2月6日夕方5時半になりましたDevRelラジオの、ついに今日は150回目というところをお届けしていきます。
150回目と言っても、別に大したことは考えてはいないんですけれども、いつも通りやっていきたいと思います。
まずですね、DevRelラジオの紹介ですね。DevRelラジオは、DevRel Tokyoでやっているネットラジオになります。
DevRel Tokyoっていうのは、DevRelに関するコミュニティになっていて、2014年の9月ぐらいからですかね、やっているそんなコミュニティになります。
DevRelっていうのはですね、デベロッパーリレーションズの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わる方々、例えばテクノロジーエヴァニリストと言われる方とか、デベロッパーアドボゲートとか、コミュニティマネージャーとかですね、
そういった方々が集まって情報交換をしたり、イベントをやったりしているといったそういったコミュニティになっております。
DevRelに関わっているよという方はですね、ぜひスラックがありますので、DevRel.Tokyoという公式サイトの方から参加いただければと思います。
あとはですね、そこまでじゃないよという方でDevRelに興味があるという方はですね、Xアカウントがあります。
アットデブレル東京となっておりますので、ぜひフォローいただければと思います。
普段はですね、シャープデブレルJPっていうハッシュタグで情報を発信していますので、そちらもぜひ見ていただければいいかなと思っております。
というところで、今日はメインテーマがですね、私の最新のブログ記事となっております。
コミュニティ参加の重要性
アウトプットは大事っていうお話をですね、多分前回やったと思うんですけれども、そんな中でですね、一番好評を得た記事であったりとか、一番バズった記事とかがあればですね、ぜひご紹介いただきたいなと思っている次第ですね。
はい、ぜひぜひ。多分取り上げるのは6時過ぎなんで、まだあと30分以上ありますんで、今のうちにですね、投稿いただければと思っております。
はい、早速そんなコメントもいただいてますね。ジャニーマンさんからですね、よろしくお願いします。お便り今から出しますときてますね。
はい、ぜひぜひ。まだまだ時間は間に合いますんで、ゆっくりですね、最新のブログ記事を探した上でコメントいただければと思っております。
それまではですね、最近のDevRel周りのニュースというのを取り上げていきたいんですけれども、なんか1年ぐらい前とかは結構DevRel周りのレイオフの話がですね、続いていて、
国内企業の場合ってあんまそういうのなかったかなと思うんですけど、海外の場合っていろんなところでレイオフの話が話題に上がってた時期があったかなと思うんですけど、
ここ数週間、この1月になってからまたその話がですね、いろんなところで聞こえるようになってるんですよね。
で、多分一番直近だと、あれですね、スナップチャット、スナップですね。スナップのDevRelチームの方がですね、レイオフ食らったって言って、
リンクトインで食探してます、みたいなことを書いてたりとか、あとちょっと名前出しづらい某社のところがですね、レイオフやってるって言って、
それはXで言ってる人がいて、朝起きたらレイオフのメッセージが来て、すごい寝起きが悪いみたいなことを書いてる人がいてですね、そこの日本の担当者の人はレイオフにならなかったって言ってましたね。
あともう一つのところも、別なところは日本の方がレイオフ食らったっていう風に言っているみたいな感じですね。このレイオフされたりとかするのは外資系企業なんでしょうがないなっていう気がするんですけど、
イベントの登壇とかめちゃくちゃしづらいんですよね。イベントの登壇依頼をしていて、そういう噂が多分あったんだと思うんで、その方もちょっと今コミットするの難しいかもみたいな感じで言われていて、レイオフされたって言ってたんで、
じゃあそのことだったんだみたいな感じだったんですけど、デブレルコンとかやってても登壇決まったときはとある会社だったのに、途中でレイオフ食らって登壇までに肩書きとか会社名とか全部変わっちゃうみたいなケースがあったりするんで、
結構そのコミュニティイベントとかって、そのバックグラウンドにいる会社の話が聞きたいっていうところがあって、その人に登壇依頼してたりする場合もあったりすると思うんで、そのときに後ろ盾がなくなっちゃうと登壇もできなくなっちゃうんですよね。
なのでそこがなかなか辛いなっていうところがあって、レイオフ食らう前に登壇してもらうのが一番いいんだろうなみたいな。何ヶ月とか間があると結構怖い感じがしますかね。
コメントきてますね。じゅんさんからこんにちはときてますね。はいこんにちはよろしくお願いします。
ジャニーマンさん聞きますね。そのレイオフの話ですね。私もここ1月になってからですね、2020年になってからちらほらと3、4件ぐらい聞いてたりとか、一社は会社自体吹き飛んだみたいな話とかもありましたね。
そこは多分デブレルコンで登壇してくれてた人のいる会社なんですけど、Kubernetes系のツール作ってる会社ですね。そこが吹き飛んだみたいな感じで、あんまり景気のいい話が海外からは聞こえてこないなみたいな気がしておりますね。
そんな中なんですけれども、まず1件目、これはせっかくなんで日本の記事からいこうかな。これは聞いたの記事ですね。小島さんの記事なんですけれども。
コミュニティに参加したら人生が劇的に楽しくなって成長できましたという記事ですね。
この間はアウトプットするにはどういうお声掛けがいいかみたいな話をちょっとしたと思うんですけれども、コミュニティも同じように、なんでコミュニティに参加した方がいいよみたいな、そういう話ができるといいかなっていう風に思ってるんですけれども、
それの千遍というかですね、なかなか至順に富んだ記事を小島さんが書いてくださっていますと。
まず初めにというところで、数年前、私は社外のコミュニティに参加する前は以下の状態でしたと。
技術記事の投稿経験なし、社外での勉強会の参加経験なし、社外での発表経験なしっていう、いわゆる普通そうだと思うんですよね、どっちかっていうと。
そんな小島さんがですね、コミュニティに参加した後は人生が劇的に変わり、エンジニアとして楽しく成長できるようになりましたというところで、
今はソフトウェアデザインですね、そちらの方でハピネスチームビルディングっていうテーマで連載も書いているということですね。
これもコミュニティに参加していたことがきっかけになっているということですね。
で、いくつかの見出しがあるんですけれども、楽しく成長するために刺激し合う仲間は重要ということですね。
これなかなか難しいなと思うのが、社内にそういう仲間がいないケースが多いのかなという気がするんですよね。
社内にいればそこで満足できると思うので、社内である意味満足できないというか、刺激し合う関係性が築けないとコミュニティに参加するようになるのかなという気がするんですよね。
自分自身の成長を加速させるきっかけとしてですね、やっぱりチームの中で小島さん自身が一番開発経験が長く、他のメンバーを教える立場であり、
自分がチーム内で一番活躍できる状態だったので、逆に自分が成長する必要を強く感じていない、お山の対象となっていたとかですね。
チーム内で活躍できることだけで得意になってしまい、自分がどれだけ知識とスキルが足りないか気づいていない、意の中の変わず状態だったということですね。
そういうところで自分自身が危機感を持ってですね、外部のコミュニティに参加するようになっていったということですね。
コミュニティに参加することで成長しやすい価値観に変わるということですね。
さらにフィードバックをもらえると、それは聞いた絵とかの技術記事の投稿だったりとか、オープンソースソフトウェア作ったりとか、さらに登壇したりとかですね。
一番最後、自分で社外勉強会を主催するみたいなことも書いてありますけれども、
そういったアウトプットをすることによって逆にフィードバックをもらえるということですね。
アウトプットするからこそのインプットというところだと思うんですけれども、そういった得られがあるということがメリットとして書いてくれてますね。
これはとても嬉しいですよね。
コミュニティの探し方というのは基本的にコンパスくらいですね。
コミュニティの具体例と、それが小島さんが所属しているコミュニティなんですけれども、
エンジニアと人生コミュニティですね。
あとは運営者ギルド、個人開発系の方がいっぱい集まっているやつですね。
あとはユニティゲーム開発者ギルドというのが上がってます。
コミュニティに入ったらやるといいことというのが、まずスラックがある場合はとにかく投稿してみることと、
ROMから始めてもいいけれども投稿した方が個人的には100倍くらい楽しいですというふうに書いてありますね。
小島さんは前にもDevRel Meetupで登壇してもらったことがあるんですけれども、
コミュニティに参加する前の状態も冷静に分析されているし、
なんでコミュニティに参加するようになったかというところの理由付けとかも、
具体的に説明してくれるのですごく分かりやすいんですよね。
なんで参加しなきゃいけないのかとか、
マストではないんですけれども、
なんで参加すべきなのかみたいなところもちゃんと言語化してくれるので、
コミュニティに参加している人たちからするとすごく納得感がある話なんですよね。
でもDevRel Meetupで話しても、それはコミュニティに参加している人たちになってしまうので、
その先のところに届かないというのはちょっと感じるところはあるんですけど、
アウトプットの働きかけ
オンラインとかでもし最初お話してくれたりすると、
リアルで参加するのはちょっと奥だけど、
オンラインだったらいいかみたいなくらいの人たちに
コミュニティに参加した方がいいのかもなというふうに思ってもらうきっかけには
すごくなるのかなという気がしますね。
小田翔さんからもコメントきてますね。
小島さんはいいぞと。そうなんですよね。
小島さん確かマイクロソフト系かなんかだったようなところで、
小田翔さんに紹介してもらった覚えがありますね。
先日名古屋を訪れた際に初めて物理エンカウントしましたということですね。
確かに私もそうか。
私も多分小島さんリアルでお会いしたことないかな。
そんなような気がしますね。
そんな小島さんの体験記が書かれておりますので、
コミュニティに既に参加されている方というよりも、
メンバーであったりとか、最近ちょっとコミュニティに参加できてないんだよなみたいな方に
とても読んでいただきたいなという気がしますね。
次なんですけれども、こちらはレバテックラボさんの記事ですね。
連載らしいんですけれども、新連載。
まずは自分のために岸田直樹が提案する自己成長を目的としたアウトプット駆動勉強術という記事がですね、出ております。
これもアウトプット系の話かなという気がするんですけれども。
ツイートができなくなってしまった。大丈夫かな。
岸田直樹さんという方はフリーランス活動を経て、現在はLINEやYahoo株式会社に所属しているというところで、
Java系の本を何冊か出されている方ということですね。
このレバテックラボの中のこの連載の中では、
全体の連載としてはエンジニアとしてキャリアを作っていくための勉強法というところなんですけれども、
この記事に関してはアウトプットに注目して書いてくれているということで、
アウトプットの種類というのがいくつか挙がっています。
ソーシャルメディアの投稿もちゃんとしたアウトプットだよというところで書いてくれてますね。
ソーシャルメディアではアウトプットをあまり気負うことなく行うことができます。
何を勉強しようとしているか、試そうとしているかといったことを投稿するのがいいと思いますというところで、
完了形というよりはこれから何をしますみたいなのがいいというふうに書かれてますね。
ここで注意すべきなのは、開発に関することだけ書いていると、
各方だけでなく見ている方も疲れてしまいますというふうに書いてありますね。
そのためご飯や他の趣味など生活に関することも混ぜて投稿していくと続きやすくなりますというふうに書いてありますね。
ソーシャルメディアへの投稿はアウトプットの習慣化のためという側面がありますということですね。
エンジニアは議論がうまい人が多く、前提も共有しやすいので、
ソーシャルメディア上で建設的な議論は比較的行いやすいように感じていますということですね。
SNS上での議論で岸田さんが注意されていることというのは、
相手も相手の観点から正しいと思うことを言っているということです。
会議などで同じ目的に向かって意見を出し合う議論と違って、
ソーシャルメディアでの議論は異なる意見の擦り合わせになりがちです。
アウトプットの効果とDevRelのパフォーマンス評価
ソーシャルメディアでは何らかの異なる視点や知識が前提となっているので、
お互いのどこに差異があるのかを見つけるようにやり取りをすると建設的な議論になりやすいですというふうに書いてありますね。
もう一つアウトプットとしてブログを挙げています。
積み重ねの効果が現れやすいのがブログだと思いますというふうに書いてありますね。
大筋はすでにソーシャルメディアに投稿しているので、
あとはまとめるだけだなと思ってもブログとして書くには詳細が足りなかったり、
正確な記述であるか確認するために実際は結構な時間がかかります。
しかしこれがより深く調べるきっかけにもなり、
他の人が見たり自分が後で見返すときにも読みやすい文章になりますということですね。
前回も多分アウトプットのときにもありまして、
未来の自分のためのメモみたいな話があったと思うんですけど、
ここにも書いてありますね。
後から自分で試せるように書いておくのが大事ですというふうに書いてあります。
そしてあとアウトプット三つ目、イベントなどでの登壇というところですね。
登壇者としての認知が高まり、
自分がその技術に興味があるということを強く認識してもらえますというところで、
あとは登壇資料は理解しやすい構成が求められるので、
ブログよりもわかりやすさに気を使う必要があったりとか、
あとは話を組み立てる能力が高まるということですね。
あと一番最後にいいこと書いてありますね。
登壇のいいところは絶対的な締め切りがあるところですということですね。
ブログとかもそうですよね。
私できるだけ途中でやめるということはしないようにはしてるんですけど、
ちゃんと書き切るところで調べ物が多かったりとかすると、
とりあえずドラフトの状態とか下書きの状態で取っておこうかなみたいになると、
つんどくならぬ、つん書きみたいなのがどんどん増えていく傾向があるかなと思うんですけれども、
そういったところを登壇は絶対的な締め切りがあるんで、
必ずやらなきゃいけないというところで、
筆者のようなだらだらやりがちな人間にはとてもいいプレッシャーですというふうに書いてありますね。
あと四つ目、勉強会を主催すると。
登壇できるネタがあっても、
近所で良さげな勉強会がないというときには、
自分で勉強会を開くしかないということになります。
この場合は他の勉強会に参加して、
直接告知をし集客することが大切ですというふうに書いてありますね。
あとは動画投稿は作業負担がちょっと重いということですね。
勉強のモチベーションとしてのアウトプットとしてはあまり向かないように感じます。
もちろん動画投稿自体は楽しいし、人の役に立つものでもあります。
動画投稿をやる場合は、
まずその動画投稿自体をやりたいということを
モチベーションにする方がいいでしょうというふうに書いてありますね。
そうですね。
動画投稿っていうとこのDevRelラジオも半分動画、後日音声みたいな感じですけれども、
これもね、ライブだから続けられてると思うんですよ、正直。
これ録画して1時間のやつを作って、それを毎週火曜日公開でやるっていうのは
多分私は続かないと自分自身で感じるので、
ライブでなんちゃってでフィラーみたいな部分も含め、
垂れ流し状態というところで多分できてるんじゃないかなっていう気がするので、
動画投稿はなかなか大変ですよね。
コメント来てますね。
ジャニーマンさん、つんがきたくさんです。
そうなんですよね。
やっぱりドラフトで置いちゃいけないと思うんですよね。
ドラフトで置くと本当に厳しいと思うんですよね。
どんどん溜まると思うんですよね。
あとはOSSや個人プロダクトは勉強の目標にすべきと。
そういったOSSや個人プロダクトは勉強のモチベーションとしては適していないというところで、
最終的な目標にすべきということですね。
大変だけどチャレンジしたい書籍出版というところで、
例えば技術書店とか、あとはKindle Direct Publishingとかですね、
そういったものを使えば誰でも自分でアウトプットできるということですね。
アウトプットの効果を3つ挙げてくれてますね。
1つ目が多分これかな。
周りの反応による効果と。
アウトプットすることで気になるのは周りからの反応です。
ここにはいいものも悪いものもあります。
役に立ったとか面白かったという反応は嬉しいもので、
次のアウトプットへのモチベーションにもなりますということですね。
ただ自分にとって役立つのは誤りの指摘だと。
ここ違いますよとか、ここもうちょっとこうした方がいいですよみたいな、
そういった指摘の方が役には立つということですね。
あとは自分自身への効果。
気になっていたことを調べてアウトプットしていくと、
その事柄に関して考えることがなくなり、
次に進めるようになりますと。
これは面白いですね。
もんもんと気になるなというところで放置していると、
それが気になっちゃって、
次に進めないみたいな場合も確かにありそうな気がするので、
そういったところをアウトプットしてしまうことによって、
その事柄自体も考えなくて済むようになるということですね。
そういった感じですね。
アウトプットというところが、
アウトプットの具体的な効果と成果
勉強とか学習に対してどれぐらい効果的かというところですね。
いろいろ挙げてくれているので、
ぜひぜひ読んでみてくださいというところですね。
では続いて、どれがいいかな。
この記事、海外の記事で、
これ全然私知らなかったんですけれども、知ってたかな。
いや多分、全然忘れてるんですけど、
DevRelCore.comっていうサイトがあるんですね。
どんなサービスなんだろうな。
クリエイティングデベロッパー、エンパワーリングコミュニティ、グローイングエコシステム。
教育系なのかな。ちょっと分からないんですけれども、そこのブログ記事ですね。
クリエイティングなDevRelエバリューションフレームワークというところで、
こういうフレームワーク系の話って、
DevRelに関わる人ってめちゃくちゃ好きなんですよね。
私も好きなんですけど、
KPIの話とか、ちょっとふわっとしてる部分があったりするんで、
何らかフレームワークがあるといいというところで、
この日本語訳で言うと、
DevRel評価フレームワークの作成という記事になっております。
このときですね、そのモデルの基礎となるのは、
成功を定義するために使用される評価基準の階層わけです。
全部で3つの階層があって、成果ですね。
DevRelの具体的なインパクトを指し示すと。
もう一つはアウトプットですね。
これはこの成果というところをより向上させるのに役立つ内容ですと。
最後は活動ですね。
これはアウトプットを提供するために必要ですと。
これ面白いですね。
何のために活動するのかというところで、
例えばフォーラムを立ち上げるとか、
ここではカンファレンスを開催するとか、APIを公開するとかですね。
そういった何らかの活動をすると。
それが何に繋がるのかというと、アウトプットに繋がりますと。
DevRelイニシアチブのリスクと報酬の最適化
アウトプットは例えば何があるかというと、
ブログ記事で書いたブログ記事とか、
あとは具体的な開催したイベントの話とか、
あとはサポートしたユーザーの数とかですね。
そういうアウトプットに繋がるものですと。
その結果として、アウトプットの結果として、
製品売上の成長だったりとか、製品採用数とか、収益、あとはレビューとかですね。
そういったところのビジネス目標に結びつく内容になるというところで、
活動、アウトプット、成果というのがしっかり繋がってくるということですね。
それぞれに対して採点をするというところで、1から5のスコアをつけると。
1は改善が必要、5は優れているという判定ですね。
それぞれの根拠を明確にしましょうとか、
ビジネスへの影響が大きいメトリックスに関しては重みをつけたりとか、
逆に今フォーカスしていないものに関しては軽くするとか、
そういった重みづけをするということですね。
例えば、所有するコミュニティ内の規模と活動を測定し、
全市販機と比べてその活動の内容、活動の活発さ、
加減みたいなものが減少していたとしたらスコアは1になりますと。
全市販機と比べて5%は活動が活発になっているとか、
参加している人数が5%増えているみたいになったら、
それは3点として評価しましょうとか、
さらに5点の場合は15%以上とか、そういう感じで得点づけをすると。
さらに、例えばeBookとかそういったものを提供するというところを判断するとしたら、
何も市販機で作りませんでした、
新しいハンズオンコンテンツとか作りませんでしたみたいになったら、
ポイントは1ですと。
4件作るのがちゃんとしたノルマとして設定されているんだったら、
それを達成したら3ですと。
8件以上作った場合はさらに素晴らしい成果なんで、
5ポイント与えますとかですね。
あとはイベントの参加とかに関しては、
来場者数が前年度比で減少しているとか増えているとか、
そういったところで採点するということですね。
採点が完了したら、成績分布を分析することで、
DevRelのパフォーマンスに関する洞察を得ることができるということですね。
分布によって強みとか弱みはどこにあるか分かるとか、
指標の傾向から長期的な進捗が分かるとか、
あとは他のチームとの比較により改善を促すことができるということですね。
これがなかなか面白い考え方というか、
当たり前っちゃ当たり前な気がするんですけれども、
いかんせんDevRelでKPIで悩むみたいな話はよく聞く話なんで、
この活動アウトプット成果でそれぞれをちゃんと結びつけた上で、
1から5点の評価をしていくという考えは、
なかなかこれは面白いというか、すごい役立ちそうな気がしますね。
これ文章だけで書いてあるんで、
ちょっと分かりづらいところがあるかなと思うんですけれども、
普通にちゃんとフレームワークとして使えそうな気がする内容となっております。
ということはもう一個あるんですよ。
このDevRelコアのブログ記事なんですけれども、
これはOptimizing Risk and Reward in DevRel Initiativesというブログ記事になっております。
これがスイート、できる。
DevRel Initiativeにおけるリスクと報酬の最適化という記事になっていて、
昨今の一番最初にレイオフの話もネガティブな話から入っちゃったんですけれども、
DevRel自体がROIをきちんと考えていくべきみたいな話もあったりするわけですね。
ちゃんと予算に対してより高い成果を求めるようになっているという傾向がある中で、
例えばROIを最適化することは優先順位的にきちんと考えなきゃいけない指針となるべきであるというところで、
例えば主要な開発者パルソナのロイヤリティを高めることで採用率と定着率を高めるとか、
あとセルフサービスによるサポートコストの削減でエンジニアリングリソースを開放するとか、
あとは新規ユーザーを獲得することでコンバージョンによる収益の可能性が広がるみたいな感じで、
課題はどのイニシアチブが定量的にROIに対してとかKGIに近いのかな、
会社としての目標にわたってリスクと報酬のバランスを最もよく取ることができるかを決定する必要があるということですね。
そのときの採点モデルの要因というのを挙げていて3つの要素があります。
期待されるビジネスインパクトがまず1個で、
これはサインアップとかリテンションとかサポートコストの削減などのKPIにマッピングされて、
現在のベンチマークに基づき1から10のスコアで評価すると。
例えばコンバージョン率を20%向上させるんだったらそれは8ポイントですとか、
あとはオンボーディングの摩擦を減らして定着率を向上させるみたいなものは7ポイントですとか、
さらにセルフサービスでサポート件数を30%削減しますみたいなのが9ポイントですみたいな感じの、
達成できる数値的な内容に対してきちんとスコアをつけていくということですね。
それぞれのイニシアチブのタイプに基づき、
イニシアチブのリスク評価と緩和
そのイニシアチブが意図した結果を達成できるかどうかの本質的な不確実性をリスクとして評価するということですね。
例えばオンラインコミュニティフォーラムを立ち上げるということが、
それぞれのオンボーディングの摩擦を減らすとか、
コンバージョン率を改善するみたいなところにどれぐらいのリスクを与えるかっていうところを考えるということですね。
ここでいうとオンラインコミュニティフォーラムの立ち上げは2って書いてあるんで、
1、全くリスクがないわけじゃないけど、そんなにリスクは高くないということですね。
年次開発者会議、いわゆるアニュアルのカンファレンスに関してはリスク4っていうのを上げてますね。
結構予算かかるお話だったりしますもんね。
あとはビデオチュートリアルシリーズの公開みたいなものはリスク1になってるんで、
こういうリスクが低いものからやったほうがいいみたいになるんですかね。
3つ目が緩和レベル、実行リスクを管理するための戦略が実施されているかどうかを評価するものです。
1は不十分、5が十分に管理されているというところで、
例えばテクニカルモデレーターみたいな職業を募集しているというところは、
リスクを緩和するためにやっている大事なところみたいな感じですね。
早割チケットの販売、これが3とか、
これが開発者、カンファレンスを成功するためにやっていることとかなんですかね。
あとは多段階ビデオ展開、
多段階っていうのが本訳しちゃってる内容なんでちょっとわからないんですけれども、
多分マルチプラットフォームとかなのかな、
1個のプラットフォームだけに頼らない展開みたいな、そういうことなんじゃないかなと思いますね。
これらの各変数のスコアを数値化することで計算式を作り、
リスク調整後のROIを決めていくということですね。
さらに優先図形のガイドラインに沿って、
実質的な緩和策を講じた上でビジネス価値の高いイニシアチブのみを追求するとか、
軽減可能であったとしても過度のリスクを内在する価値の低いイニシアチブを避けるとか、
ビジネスインパクトがとても多分、カンファレンスとかは高いとは思うんですけれども、
やっぱりリスクもそれなりに高かったりするし、
多分コスト的な問題とかもあったりするので、そういうのを避けるとかですね。
価値の高い活動に関しては、その上積みが保証されるのであれば、
リスク管理をさらに強化すると。
そこにさらにリスクを防止するための投資をしてもいいみたいな感じですね。
まずは少ないリソースでROIの高いQuick Winに集中するっていうのが4つ目として書いてありますね。
これは当然ですよね。
DevRelはやっぱり低リスク、ローリターンとか、ローリスク、ミドルリターンぐらいですかね。
そこら辺から始めていかないと、すごい期待値ばっかり上げまくってしまって失敗するケースを嫌ってほど見てるので、
あんまりいきなりカンファレンスやるぞみたいなのは、私はお勧めしないんですけど、
盛り上がっちゃってるところとか、そういうでかいところから入っちゃったりしますよね。
一番最後に書いてあるのが、そのROI重視でDevRelに取り組んでいくためにですね、
まずリスク対リターンのスコアリングを行い、過去および提案されたイニシアチブの目録を維持すると。
実際の成果に基づいて、市販機ごとに格付けを再評価すると。
最後、新しい取り組みや計画が徹底的な評価を受けるようにするということで、
リスクとリターンのトレードオフのバランスに基づくデータ主導の意思決定とリソースの最適化が行われると。
それによってイニシアチブプランニングは直感から卒業し、DevRelのコアコンピテンシーになるというふうに書いてありますね。
この内容とかは、超大手の外資とかはやってはいるのかなっていう気はするんですけどね。
あまり表に出てこないだけだったりするのかなという気はしますね。
このDevRelコアの記事、なかなか面白いのが多いんじゃないかなという気がしますね。
ぜひぜひDevRelに関係する方々は読んでみていただきたいなと思います。
AWSのコスト削減展開地武道会の振り返り
あともう1個ぐらいなんかいるかな。
これいいな。
これはスイートエスケープっていうブログですね。
第1回AWSコスト削減展開地武道会を終えてという記事が出ております。
これいつでしたっけ。2月の頭ぐらいにハイブリッドでイベントやったんですけれども、
それが確かに3000人ぐらい集まってるんですよね。
そのイベントを開催したところで2つ記事があってですね。
まず1個目が今言った第1回AWSコスト削減展開地武道会を終えてってやつですね。
今ちょっとゲスト来られたのでお呼びしますね。小田昭さんお疲れ様です。
お疲れ様です。聞こえてますか。
大丈夫ですよ。聞こえますよ。
参加しましたよ。展開地武道会のやつ。オンラインですけど。
これはね、相当盛り上がってましたよね。
そうですね。コスト削減確かにホットなネタかもしれないですよね。
そうですね。
為替の影響とかもあって、どんどんうなぎ登り。
うちは一旦ドルを円に変えるスタイルなので、円安であればあれほど僕は嬉しいんですけど、給料的には。
はいはい。
給料的には嬉しいんですけど、コストにもそのまま反映されちゃうというか。
特にアメリカの製品とかね、アップルビジョンプロとかもサクッとハネムンツイレに買いに行きたいんだけど、高いなみたいな。
そうですね。この間、某社でオンプレでシステムやってたんですけど、それをAWSに乗せ替えたんですよね。
上層部の方々と現場の方々のコミュニケーションをうまくやってなかったのか、
リプレイスしたら実際の現金高くなってんじゃんみたいな。
なるほどね。
担当者がすごいその後の説明とかで苦労してるみたいな話があって。
その目に見えるコストと目に見えないコストがあるじゃないですか。
多分このAWSの展開地武道会は目に見えるコストの話をしてるわけですよね。
そうですね。具体的にどのぐらい元から削減できたかパーセンテージで。
時数はなかなか出てこなかったんですけど、パーセンテージでどのぐらい削減できたみたいな話は出てましたね。
そうですよね。
多分上層部の人ってそういう上辺の数字だけで判断されるので、
なかなかおだしょーさんが携帯電話持って寝なきゃいけない状況ってどうなるとかね。
そうですよね。そういったところは多分考えてないというか見えないというか判断材料に入りにくい部分ありますよね。
さくたろうさんから質問が来てますよ。
コスト削減は永遠の課題かもですね。外資ベンダーの方はどういう視点で主張されていたのか気になります。
これ多分現職もあるし前職の話もあるかなと思うんですけど、おだしょーさんどうですか。
そうですね。ドルベースで考える風に頭が切り替わってるんですよね。やっぱり外資長くなってくると。
そうだよねぐらいな感じなんですけど、ただ一方でやっぱり円ベースで見たときには何パー上がってるみたいな感じがあるので、お客さんと話しするときとかはね。
その辺かなり気を使うというか、ちょっと前までこのぐらいの金額だったんですけどね、みたいな会話になることもないこともないかなっていうところですかね。
ちなみにあれはマイクロソフトはAzureってどれだって何でしたっけあれ。
コスト計算ツールっていうのがあって、そこでドルだてか円だてかみたいなのを選べるんですけど、
円だてかっていうか、そういった表示に切り替えることでかかるコストっていうのが計算できるようになっているんですけど、
実際はあれどうなったかな。社員って当然Azure無料で使い放題なので、あんまり気にしてなかったが正しいですね。
だめだ、それは作太郎さんのコメントに対しての答えになってない。ベンダー視点にしてないっていう。
そうですね、あんまり気になってなかったが正しいかもしれないですね。
それはひどい。
そうなんですよね。ベンダー、今はMableとかもそうですけど、やっぱり自社製品は制限なく使えるっていうのは一つのベネフィットなので。
かかった分は当然払うし、これだけじゃなくてサブスクとかでもろもろやってたりとかして、値段上がったなみたいな。それこそJATGPTのサブスクとかあるじゃないですか。
あれ一人で払ってるけど、ちょっと上がったなみたいな感じだけど。
でも上がったって言っても大規模じゃなければ、数百円とかの単位なんでそんなに気にならないんですけど、
エンプラのシステムってなると上の方々はやっぱり気にするだろうな、出て行こうかねわって感じですかね。
そうですね。特に重量課金だったりするじゃないですか、基本的に。
なので、トラフィックの部分とかで金取られてると、なんでこんなかかってるんだっけっていうところがうまく説明できない場合は多いのかなっていう気がするんですよね。
あると思いますね。そういった流れを受けてのコスト削減みたいな感じの話はすごく流れが綺麗というか、
それは節約できるものはしたいよねっていう。
そうですね。
本当は現地行きたかったんですけど、ちょっとまだまだ仕事がバタバタしてしまってですね。
またまたなかなかちょっと外出できてないですね。
このブログ記事の方の最後の方にもあるんですけど、結構出し切った感があるっていうところで、
2回目をやるかどうかは未定っていうふうに書いてありますね。
確かにテーマが絞られてるので、ちょっと膨らますのなかなか難しいところはあるかなっていう気はしますかね。
そうですね。単発でいいと思う。
それこそ半年か1年に1回ぐらいやるかやらないかぐらいの、そのぐらいのケイデンスでいいような気はしますよね。
聞こえないですしね。
そう。確かにね。
展開寺武道会って言いながら、第2回戦あり得ないので。
そうなんですよ。
そうなんですよね。ちょっとその辺はワードチョイスというかね。
ちょっとキャッチーな言い方して引き継げてるっていう感じがありましたね。
配信とかもお手伝いしようかなと思ってたんですけど忙しかったので手は挙げませんでした。
メインテーマを今後GoogleとかAzureにして開催することもできなくはないけれども、集客面だけで見れば圧倒的に厳しいというふうに元Azureの関係者としては厳しい意見が来てますね。
だと思います。やっぱりコミュニティの盛り上がりにかなり依存するというか。
例えばマイクロソフトの立場でコスト削減しましょうなんていうふうな言いぶりにはおそらくならないと思うので。
そうなんだ。でもこれ上手じゃないんですよ。
そうですね。上手じゃない。
一応AWS。
そうですね。ただあれですよね。西谷さん元AWSだしやっぱりコミュニティとの親和性高いところでやっていたので。
もちろんAzureもコミュニティの皆さんいらっしゃって自分たちでコミュニティ運営すごくされてしっかりされてるんですけど。
コスト削減ってなったときにコミュニティの盛り上がりだけでいうとそのAWSのほうが盛り上がってるようには見えなくはないのかなみたいな。
それをやろうと思ったときにどれだけみんな参加してくれるんだろうっていうのはちょっと不透明でありますよね。
うん。
イベント会場タイミーさんに借りたらしいんですけど。
キャパ70って聞いてたのに最大130入れるとか言ってごめんなさいとか。
2倍か。
大変ですよね。
もうそこでオンラインっていうかオフラインかオフラインの方でそんだけ人が集まるっていうのが結構強いですよね。
どちらかというとユーザー主導なんだろうなというベンダー主導よりユーザー主導なんだろうなって感じですよね。
そうですね。
っていう感じがしました。
LT形式で1本30分の枠で何人やったの?1,2,3,10人ぐらいかな。
途中からLTに変わったのか。
そうです。2人3人ぐらいが普通にセッションやってその後LTやってましたね。
うん。
この怒涛のセッションの感じとかも勢いがあっていいですよね。
そうですよね。その勢いも演出したっていう風に言ってました。
気持ちは分かるなって感じですね。
急爆感を出すというか、勢いがあるように見せる演出は上手だったなという風に思います。
そうですね。
いろいろ別な記事もあって、どうやってやったかみたいな盛り上げ方の話とかもある記事があるので、
イベントをやる方はぜひ見て欲しいなって思いますね。
振り返りのやつも参加しましたけど、勉強になりましたね。
ではですね、今日のメイントピックの方ですね。
私の改新のブログ記事というところに入っていきたいんですけれども、
小田尚さん1つ目読んでいただいてもいいですか?
はい。今日もすごいですね。
技術書同人誌への参加
DevRelName 札幌のじゅんさんですね。いつもありがとうございます。
他方面に書いているので、これというのを決めきれませんが、
直近でよくできたと思った記事は、軽率に技術老人誌の執筆レビューしてみた話、
LT否定の書編かなと思います。
技術書同人誌博覧会というイベントがあり、
ライトニングトークの発信をしやすくする書に寄稿した一連の流れをまとめた記事です。
他の執筆者の方の記事もよくノリで参加した割にはとても良いプロジェクトだったと思っています。
私の中で改新だったポイントは複数あり、
1、執筆活動そのものでLT登壇のハードルを下げたい。
2、LTイベントの運営者になる道も示したい。
3、技術書同人誌執筆へのハードルを確認しできることならそれも下げたい。
4、実際にXR分野以外で発信ハードルを下げる活動をされている人々と知り合いたい。
5、発信ハードルを下げる人というキャラを認知してもらうための根拠を増やしたい、
みたいな要素が全てまとまっていたと感じています。
執筆内容も先に公開したものを移植したので、
自分の担当箇所は好きなときに見せびらかせます。
本の中では移植の記事ではありますが、
イベント運営者になる方法として一つの道であるので、
内容もシェアしておきますとURL付きで頂戴してますね。
ありがとうございます。
うーん。
技術者、技術上人士、前に執筆に参加したっていうのを
じゅんさんが書いてくれてましたけど、
それを他方面で使い倒しますよね。
まあまあ、せっかく作ったんだったらね、
もう本当味がしなくなるまでも噛み潰した方がいいですよね。
なんかこう、何回も何回も寝っ転がして寝っ転がして
使いまくるっていうのがすごいなと思います。
いやでも大事ですよ。
それこそMSの時もそうし今もそうなんですけど、
同じ話をするにしてもオーディエンスが違うと
響き方が全く違うのと、何度も何度も同じ話してるんだけど、
結構何度も何度もリアクションが新鮮な方がいらっしゃるんですよね。
だから言うほど自分たちが何かアウトプットしたのって
広がってないんですよ。
自分の身の回りだから自分とその身の回りは知ってるよねみたいな。
例えば青田翔だったら毎年iPhone買ってるよねって知ってる人は知ってる。
周りの人は知ってるんだけど、
一歩外に出たらそんなこと知らないわけじゃないですか。
他の方なんて。
みたいな形で同じネタを何度もこすったりとかも
本当に味しなくなるまでガム噛むみたいなのって
実はすごく必要なんじゃないかなと思うんですよね。
うーん。確かに。
そのガムをまだ必要としてる人たちはいますからね。
そうなんですよ。何でも落ちてるガム食べた方がいいぐらいですよ。
うふふ。
あははは。
あんま同意できないけど。
あははは。
そのぐらい。そのぐらいやった方がいいですね。
はい。ではですね。
2件目に行きたいと思います。
2件目はですね。
DevRelネームみきほさんですね。
いつもありがとうございます。
URLはちょっと後ほど投稿しておきます。
入社したばかりの時に書いた
ジラなどのチケットってなぁに
プロジェクト管理タスク管理ツールも解説
ハッシュタグIT企業転職あるあるという記事です。
DevRel界隈にいる人から
開発プレゼン会の共有
人からにすれば信じられない話かもしれませんが
世の中の半分以上はまだExcel方言紙を駆使して
プロジェクトをWBS引いているそうです。
この記事が入社したばかりの頃
GM層にめちゃくちゃ受けました。
またこの記事は長期にわたって読まれている
検索流入が一定数あるので
チケットってなぁにという人はまだまだいるんだなぁと
実感できますというところで
これさっきの小田翔さんのガムの話に
ちょっと近いものを感じますよね。
大事だと思いますね。
なんだろうな、ある種デファクトを解説する記事みたいなのは
長く噛まれますよね。
そうですね。どこまで目線を落とせるかですよね。
そうですね。なかなか難しいですよね。
要はその読んでいる対象者がめちゃくちゃ広くなるわけですからね。
どのぐらいまで目線を落として書けばいいかみたいな
すごく難しいなと思いつつ
カチッとハマると今回この三峡さんの記事みたいな形で
長くいろんな方に見ていただけるようになるんじゃないかなと
思いますね。
そうですね。しかもこれ入社したばかりの時しか書けない記事なんですよね。
そうかもしれないです。
目線が上がっちゃうので
多分三峡さんも今だったらチケットって言われたら
仕事上のチケットって言われたらなんだっていうのが
思いついていると思うんですけど
そうじゃない時にしか多分この目線の記事って書けないと思うので
間違いない。そうなんですよね。
いいタイミングで
わかるようになっちゃうと書けないんですよね。
当たり前のレベルが上がっちゃうから。
そうなんですよね。前提知識がちょっと得てしまうと
余計な3文字の英単語とかね
頭文字だけ集めたやつが出ちゃったりするので
ある程度レベル上がらないと読み解けない感じの記事が書けなくなっちゃったりとかするので
その辺は逆にフレッシュなうちに何かを書くっていうのも
一個大事な経験なのかもしれないですよね。
初心に戻れたりとかするし。
僕が前に会社勤めてた時は
入社した新人の人に会社のヘルプ資料とかを書いてもらって
そのメンテナンスも新人の人にお願いしてたんですよ。
いいですね。
講師みたいな人はオンボーディングで教えるので
その結果を受けてドキュメントの修正は
彼らの目線で彼らが分かる形で直してもらうみたいなことはやっておきましたね。
そうしないと役立たないドキュメントが出来上がるので。
ありますね。若手にレビューしてもらうみたいなやつは
自分もちょっとやってましたね。
お客さんに渡す資料とかで
書いてあるとかでわけわかんないとかあったら教えてみたいな感じで
でもそれもある程度のレベル感が必要なんですけど
本当にマジで何もわかんないやつは
これ書いてある内容一個もわかりませんでしたって
してきちゃうんで。
そうですね。
塩梅が難しいんですけどね。
いずれにしてもどういった形でも
貢献できる余地はあるんだなってその時は思いましたけど。
作太郎さんからコメントきてますね。
チケットイコールパーティー券で認知されてることありますよね。
そうですね。
これは
何でしたっけ。
あれなんだっけ。
よくあるあるですよね。
技術系というか
なんだろうな。
プルリクとかは関係ないけど。
Amazonだね。
昔はAWSじゃなくて
Amazonって本屋じゃんみたいな話とかね。
言われるとか。
日英で意味合いが微妙に異なる言葉とか
本当に要注意でその辺とかって。
微妙に日本に入ってきた途端に
魔改造を食らって
言葉の意味変わっちゃうやつとかは
特に外資の日本支社にいる人たちは
その辺を強く意識している人が多いと思うんですけど。
コミュニケーションエラーが発生しちゃうので。
そうですよね。
知らないでコミュニケーションエラーが発生してたら
外じゃさらに無理でしょって思いますよね。
そうそうそう。
ある程度プロトコル揃ってたとしても
その辺でよくわからないエラーが発生するんで。
会社の外はなおさらだよねみたいな。
難しいですよね本当にね。
では3件目は和田翔さん読んでもらっていいですか。
3件目は
ちょっと待ってくださいね。
いつもありがとうございます。
今週のテーマは
私の会心のブログ記事とのことでお便りします。
今まで会心の一撃という記事は特に思い当たらず
自分の中でなんとなく手応えがあったものを
あげてみたいと思います。
1本目会社の技術ブログで
月1回社内で行ってきた開発プレゼン会で
技術的な知見の共有をしている
という話を執筆しました。
我々のようなITを成りはいいとしていない企業にも
内製エンジニアがいて日々開発に奮闘しているので
その裏側や雰囲気を知っていただけると
嬉しいなと思った次第です。
開発で得た知見を毎月登壇者が発表しており
社内の取り組みをオープンにして
親しみを感じてもらうという意味でも
外部のエンジニアに認知してもらえたら
プロジェクトマネージャーの文化
嬉しいと思っています。
2本目の記事は
カンファレンス関係で長くなりそうなので
この辺りで
今週もデビューラジありがとうございました。
ということで。
なるほど、なるほど。
そうですね、この辺。
会心って難しいですよね。
そう言われると。
自分の中でいいと思えばそれは会心なので
別に他の評価じゃないので。
なのでこの西から北をまづらの男さんでいうと
さっきのじゅんさんじゃないですけど
勉強会とかプレゼン会をやってきた内容を
まとめるみたいなとか
横に展開してコンテンツにしていくっていうのは
いいやり方ですよね。
そうですよね。裏側って結構ニーズありますしね。
裏側というかメインのコンテンツがあって
それの裏側というか詳細というか
それに至るまでの経緯とかも含めて書く。
どういった思いでこういうアウトプットに至ったのか
みたいなのは結構経緯ですよね。
振り返りの意味でもとてもいいですしね。
確かにさっきの展開地武道会もそうですしね。
振り返り系のイベントも人気ありましたしね。
と思ったら今度はイベントやる前の
運営のわちゃわちゃしてる様子見たいみたいなね。
まるはだかですよね。
確かに。ほんとこすってますね。
面白いですね。
そうなんですよ。その周辺にね。
一等前後賞みたいなのをみんなやりたがるというかね。
確かに。
でもわかる気がします。
ちょっと経路違うけどやっぱり
退職ポストっていうか退職ブログとか
入社ブログとかっていうのもある種メインの仕事の
傍らのどういった経緯があってこうなったみたいなのって
めちゃくちゃ会心出やすいじゃないですか。
ブログとしてはやっぱりサイドストーリーとかもね
すごく知りたい方って多いんだろうなっていう感じがしますね。
確かに。
ではですね。
4件目のご意見ですね。
DevRelNameジャーニーマンさんですね。
いつもありがとうございます。
技術系DevRel系というところで
6年前のキートの記事を紹介します。
システム開発のプロジェクトマネージャーが
キャリアの大半なのですが
そのノウハウについて書いた
プロジェクトマネージメントで大切にしている文化についてです。
果て部のホットエントリーに一瞬乗った唯一の記事で
聞いたのいいねが26、ストックが16も過去最大です。
文化という言葉を使っていますが
今見返すと昨年のミッション、ビジョン、バリューが
大事に通ずるところがあると思いますと
お役に立てば幸いですと聞いていますね。
なんか結構エモーショナルな記事なんですかね。
そうかもしれないですね。
カッチャー系の話は大抵エモくなる傾向があるけど
共感してくれる人が多いと
いいねついたりとかしますよね。
確かに。
別枠で同じような経験をした人が多い記事なのかな
なんて思ったりもしますけど。
確かにこれを多分読んで
そうだよねって思う人が多いんでしょうね。
そうですね。だからおかれ少なかれ
近しい経験をする人が多いトピックだと
会心出やすいみたいな。
確かに。エモーショナル系は確かに
そっちの方がいい気はしますね。
そうですよね。
共感系。
みんな言語化できなくて腹に据えかめてる思いとか
どこかにあるかもしれない。
腹に据えかめてるのはネガティブですね。
ちょっと言い方ネガティブですけど
大体場合によりますけど
現状があって現状がちょっとおかしいから
こうなんじゃないのみたいなのって
ちょっとバズったりするじゃないですか。
良い悪い含めて共感得やすいのかな
バグりやすいのかなみたいに思ったりします。
了解です。きれいにまとめたというところで
ちょっと頑張ってみましたよ。
イベントのご案内
では最後イベントのご案内ですね。
DevRel東京の89回目のイベントですね。
テックブログ運営。
明日ですね。
明日やります。
今のところ78人ですね。
登録してくださって。
オンライン多いですね。
そうですね。内容的にも結構カジュアルなものにしたんで
ぜひぜひ皆さん参加いただけると嬉しいなと思っております。
イベントのツール全然まだ考えてないですけど
Google Meetのビジネス系のプランで100人入れるらしいので
ちょっと試してみたいかなって
Google Meetで100人いたら結構やばいんじゃないかと思うんですけど
確かに今、うちの会社Google Meetを社内では使ってるんですけど
昨日だっけ?
社員が1人増えてカントリーマネージャーが増えて
ようやく6人かなとかになったので
その規模感で使ったことないんで
100ってどんな風に表示されるんだろうなみたいな
Google Meetで100人ってすごいですよね。
そうですよね。どんな感じになるんだろう。
もうみんな豆粒みたいになっちゃいそうですよね。
確かにスクロールできるんだろうけど。
一応ズームとかも50人ぐらいだっけ?
いっぺんに表示できたりとかするんですもんね。49人か。
確か7×7。
そうですね。同じみたいですね。
Google Meetで49人までみたいな感じみたいですね。
これちょっと試してみたいな。
そうですね。念のためバックアップあった方がいいかもしれないですね。
確かに。
そのまま動くといいけど。
今、ジャニーマンさんがMeetもっさりしそうみたいなこと言ってたんで
めっちゃもっさりしそうですよね。
ですよね。ちゃんと書き込めねえよみたいなね。
これをやっても使えねえよみたいな感じになりたいっていう思いがある。
確かに。確かめたいですよね。
実用的かどうかっていうの。
そうそう。
ハイブリッドになってからツール側がやっぱり
目黒みどりシンプル寄りになってきましたね。
先週も同じような話したと思ったけど。
僕ビジネススタンダードっていうやつで
ビジネススターターでも100人
ビジネススタンダードって私が入ってるプラン150人
ビジネスプラスは500人ですって。
すごい。
Meetで500って使う?
使うかみたいな。
すごいですね。500人ですって。
じゃあいけんじゃないのこれ、余裕で。
なんかね、いけそうですね。
ちょっとね、明日はオンラインでやりますんで
ぜひぜひ皆さんお気軽にご参加くださいというところで
本日はDevRelラジオ150回目はこちらで終了していこうと思います。
ご参加ありがとうございます。
ありがとうございます。
ではまた皆さん来週お会いしましょう。
さよなら。
さよなら。
