DevRel Radioの紹介
皆さん、こんばんは。DevRel Radioの、今日は170回目ですね。やっていきたいと思います。
メインテーマは、私のアウトプット活動となっておりますね。
ではまず最初に、DevRel Radioの紹介です。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半から1時間程度お送りしているというものになります。
DevRelというのは、デベロッパー・リレーションズの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoでは、そんなDevRelに関わっている方、
例えば、テクノロジー・エヴァンジリストとか、デベロッパー・アドボケイトとか、
あとコミュニティ・マネージャーとか人事の方とかですね、
そういった方々が集まって情報交換したり、イベントをやっているというコミュニティになっております。
公式サイトがあります。DevRel.Tokyoというサイトですね。
そちらの方から公式のスラッグに参加することができますので、
DevRelに興味があるとか、DevRelに関わっているという方は、ぜひ参加いただければと思います。
あとは、公式のXアカウントがあります。DevRel.Tokyoですね。
普段は、SharpDevRelJPというハッシュタグで投稿してますので、
ぜひフォローいただいたりとか、チェックいただけるといいかなと思っております。
そんなところで、先ほども言いましたけれども、
今日のメインテーマはですね、私のアウトプット活動となっております。
アウトプット活動の種類
アウトプットといってもですね、多分いろいろ種類があると思います。
例えば動画であったりとか、ブログもありますし、スライドもありますし、
登壇もありますし、あとは何だろうな、オープンソース作ったりとか、
SDK作ったりとかですね、いろんなアウトプット活動があるかなと思いますので、
どんなことにですね、皆さんがチャレンジしているかというところをですね、
コメントいただければと思っております。
はい、そちらの方はですね、多分30分後ぐらいから、
6時過ぎからやっていこうかなと思いますので、
ぜひ今のうちにですね、皆さんからコメントいただけると嬉しいです。
最近結構ね、同じような方ばっかりになってるかなという気がするんで、
ぜひですね、匿名でもコメントできますんで、
ぽっと自分の意見を投稿いただけるといいんじゃないかなと思っております。
はい、早速コメント来てますね。
キザーさんからこんにちはと来てますね。
はい、こんにちは、よろしくお願いします。
はい、今日はですね、アウトプットなので、
アウトプット系の話にしようかなと思っていたんですけれども、
なんかいろいろ、最近のね、デブレル系の話題調べる中でですね、
ちょっと面白そうなのがあったので、
それを取り上げたいと思ったら、
Xがうまく出ない。出るかな?
出た。
いやー、全然ダメだな。
ちょっと後で直さなきゃいけないんですけど、
これはですね、
オリビアズデブレルノート、トレーニングフォーデブレルという記事ですね。
記事の本文が全部韓国語になっているので、
これはもう単純に日本語翻訳した内容なんですけれども、
主題としてはですね、社内教育プログラムに関するところです。
デブレル担当者のための社内教育プログラムはありますか?
という内容なんですけれども、
実際ですね、多分、教育プログラムを持っている会社さんって
そんな多くないんじゃないかなと思うんですよね。
一番最初のスターフォーズの写真がブログ記事のトップにあるんですけど、
今、ゲストの方が来られたのでお呼びしますね。
北沢さん、お疲れ様です。
はい、こんにちは。お久しぶりです。
お久しぶりです。
AWSサミット、いかがでしたか?
はい、おかげさまで終わりました。
ほんと疲れた。
もうね、みんな疲れ切ってましたね。
DAS側の人たちね。
出展側は結構なかなかなボリュームですね、ほんと。
そうですね。
今、デブレルのオンボーディングの話っていうのを取り上げてたんですけど、
実際、デブレルではなくて、エンジニアのオンボーディングって
北沢さんの会社とかだとどういうことをやってたりしますか?
そうですね。
オンボーディングって要するに採用じゃなくて初期の教育のことを指してます?
採用した後の人事からのトレーニングだったりとか、
その配属が決まった後の部署特有のトレーニングみたいなもので。
新卒中心なので。
こっちですと、前者でやってから改めて
クラウド専用、我々のクラウド専門のっていうところで2ヶ月ぐらい教育してから
現場配属って感じですね。
その場合って、多分配属、北沢さんのところに来た場合っていうのはエンジニアになると思うんですけど、
どういう教育プログラムをやられてたりするんですか?
プログラミングを一から教えるみたいな感じなんですか?
それは前者の方でやってます。
そうなんですね。
北沢さんのところに来たら、クラウドの基礎からっていう感じですね。
例えば、AWSとはみたいな、そういう話から。
そうですそうです。
AWSとはっていうところは実は前者にやってるんですけど、
ちょっとした構築開発だったりだとか、サーバレスのとか、
いわゆるハッカソン的なところも付け加えて楽しくやるのを2ヶ月ぐらいやってる感じですかね。
座学だけじゃなくて、ワークショップ的に実際手を動かしながらやったりするっていう感じなんですね。
そうですそうです。
実際多分、新入社員中心という話なんで、
結構何人かまとめて入ってきて、その方々みんなでワークショップやったりとか、
ハンズオンやったりみたいな感じなんですかね。
そうですそうです。
アウトプット向きの人材採用と評価
ある程度うちのグループというか本部というか、
2、30人ぐらいかな。
とこまとめてやってる感じです。
その場合のゴールって、どこらへんまでのレベルまで持ってくとかあったりするんですか。
特にそこから先でやっぱり実際やる内容も変わるので、
一通り競わってもやっぱりもう一回現場に来てから改めてOJTはありますね。正直。
そういうことですね。じゃあOJTとは別の前段階というか。
あくまで前段階ですね。
少なくともそのOJTをやる先輩とのコミュニケーションに困らないとか、
技術用語がある程度理解できてる状態みたいなそういう感じですかね。
ただちょっとサーバレスとか、今だったらサーバレスとかで開発する経験は、
ちょっとやった経験があるなしって結構重要だと思うので、
そういったとか、実際のCICD環境とかもちゃんと、
どういうものかはちょっと理解した上で来ないとなかなか辛いところもあるんでね。
そういったところの用語、ちゃんと概念ぐらいは理解してるっていう形で来て、
配属できるようにっていう感じでしょうか。
そういうことですよね。
多分、エンジニアとしての実務ってすごいイメージが私の中でも湧くので、
オンボディングのイメージも、あとOJTのイメージも湧くんですけど、
デブレルの人で、例えばブログの書き方って習わないじゃないですか、きっと。
木澤さんにブログの書き方を教えてくれた人いないですよね、きっとね。
いないですね。そこは正直、オンボディング以前に採用にも結構悩んでます。
エンジニア経験がないと、実際アウトプットをする人にもなれるわけがないし、
とはいっても、そこってどうしても素養的なものが大きいので、
なかなかエンジニアやってる人にアウトプットしろって言って書ける人と書けない人ってやっぱりいると思うので。
そこ難しいですよね、正直。
そうですよね。
最近テックブログの話とかもよく話題に上がったりとかするじゃないですか。
ある程度、求人とか採用に対してもテックブログは有効ですみたいな、
そういう知見というかナレッジが回ってるかなと思うんですけど、
書けって言われて書けるわけじゃないし、優秀だから優秀じゃないから書けないっていうわけでもないじゃないですか。
全然別なスキルなような気がするんですよね。
そうですね。そこを測るフレームワークがあるわけでもないし、
ただ、私なんかは本人を見るとそういう素描の向きの人かどうかっていうところはわかるようになってきてるので、
コミュニケーションとアウトプットを実際に書いてくれてる人も書いてくれてる内容を見ると、
そういうのに得意な人かどうかっていうところを見極めた上で、
ちょっとそれ以降の強く押すかどうかを判断してる感じですね。
はいはい。なんかその、例えばブログを書くのを強要すべきではないと思うんですよ。
そうですね。はい。
やっぱりその向き不向きの話もあるし、
実務、業務時間削って書かなきゃいけないのみたいな感じになる場合もあるんで。
ありますね。そういうのを起こすとね、どうするかとかの話も。
こっちからきちんと依頼するとそうなっちゃいますから。
もしかするとブロハラみたいな言葉ができる可能性があるわけじゃないですか。
そうですよ。アウトプットハラスメントみたいな感じのあれかもしれない。
アウトプットハラスメントね。アウハラ嫌だな。
それを考えるとその木澤さんが思う、この人なんかアウトプットに向いてるなとか思う、
そういうのってなんか感じるところは何ですかね。
自習的にやっぱり私からはアウトプットするといいよっていうふうにすごくなんだろうな、
そういったすごいメンタル面っていうかそういったところからアピールして、
それに乗っかってくる人も乗っかってきますし、実際その乗っかってきてる内容を見るとビジネスライクなところじゃなくて、
多少の遊びというかな、多少のユーモアも交えつつアウトプットしてくるって人ってやっぱりいるんですよね。
本当にそうすると、この人書くのに結構そういったハードルが低い人なんだなっていうところがすごく透けて見えてくるんで、
アウトプットする内容をブログなんかは見て判断しています。
登壇とかはいかがですか?
登壇は最初はやっぱりね、いきなり登壇しろっていうのはハードルが高いんで、
そこはもう社内でもというところで小さいところからお願いしてみて、
すごくそこの所要がある人かどうかっていうのを見てますけどね。
ただそこはやっぱり上手い人は本当に上手いし、そこはもうちょっと技術とは別のスキルなので、
ただ経験値を積むとだんだん上手くなってくるっていうのはやっぱり思うので、
小さいところから経験を積んで大きくしていけばいいんじゃないかなと思います。
その意味では木澤さんがやってるような社内の勉強会とかはある意味…
そうですよ、そういうところも使ってます。
インターナルのイベントとか、それこそもっとちっちゃく部署内とかそういったところでちょっと発表してもらって、
徐々に大きく。コミュニティイベントとかも失敗ありですから、そういったところにチャレンジするっていうのも推奨してますし、
そういうのをうまく活用して、私なんかは啓蒙する立場ですよね、本当。
啓蒙に乗っかってくる人で、結果として先週もそうですけどAWSとかの表彰を受ける、啓蒙した結果でアウトプットして、
さらにそれで表彰を受けることができたというところであれば、本人としてもよかったんで嬉しいっていう感じになるんで、
そういったところもいいロールモデルとして、社内で啓蒙活動してる感じです。
確かに。今の若い世代っていうとちょっと語弊がありますけど大波重視だと思うんですよ、今って。
はいはい。
だから結果としてAWSで表彰されるっていう結果を最短で求めたがる人もいると思うんですよ。
はいはい。
その時にアウトプット活動って、結果は繋がってくるんだけど、
なんでしょうね、なかなか遠いというか道筋が分かりづらいような印象がある。
はい。でもまあ、近しいね。
技術ブログを通したマーケティングの有効性
近しい先輩とかが表彰されてるというところを見ると、自分も頑張ろうっていうところもあると思うし。
はい。
そうですよね。その表彰されたに至った要因みたいなものがちゃんと洗い出せていると、
アウトプット活動しなきゃいけないんだとか。
おかげさまで社内のエンジニアブログとかを使ってアウトプットした人が表彰されてるっていう風になってるし、
そのようにアピールできているので、おかげに傾向だと思います。
すごい仕組みはいいと思うんですよね。
対外的なアウトプットが外部評価されるっていうところ。
はい。そうですよね。
やっぱり若い人は特に社外での評価ってすごく重要視していて、
社内でどこも評価しきれないっていうところもありますけど、
やっぱり外で評価されて自己評価が上がるっていうのはすごくプラスになっていると思います。
そうなんだ。
そしたら特にコミュニティに参加したりとかブログ書いたり登壇したりっていう外部にアピールする活動が絶対的に必要だと思うんですけど、
そこがしたい人としたくない人はやっぱりいるんで、そこも見極めた上でやってる感じですね。
若い人の社外での評価への重視
そうですね。コメントにも何件かアウトプットハラスメントとか営業ノルマみたいなのが書かれてますけど、
本当にハラスメントになりがちですね。
そう。業務でアウトプットする、業務で何だろう、成果を出すのは別の世界なので、そこにどこまでお願いするかっていうのは、
あまり無理地するものではないとは思いますけどね、本当に。
確かに。業務で言うと多分AWSの資格を取るっていうのは業務範囲に入ってきますよね。
そう。資格を取るっていうのはあくまで自己計算、うちはその認識ですけど。
そうなんですね。
受験費用は会社の方で出しますけど。
支援はしつつ、それを取る取らないっていう活動自体は本人に依存するという感じですかね。
そうですね。
そうか。そうなんだ。
結構、ITじゃないエンジニアの場合って、その資格がないとそこに当たれない職業ってあるじゃないですか。
ITってそれないですからね、あんまり。
そういうことですね。
そうなんですね。経験の方がまず重視されるっていうところなんですかね。
IT全体でそうですよね。
私、情報処理安全確保支援紙も持ってますけど、あれも登録めんどくさい事業の割には全くないのが問題になってますけども、正直。
はい。そうですよね。
ベンダーの資格って意外と資格を取ってると名刺にシールみたいなのがあるので、
その資格がないとある意味信用されないみたいな。
それが人用なのか、あくまでも。
あくまで、資格っていうのは技術を分かりやすく示すための手段というふうに昔から自分はそういうふうに思ってますけど、
なので、形に示すと。
その結果、その先ですよね。
それが外で評価されるのか、社内で評価されるのか。
そういったところがちゃんと繋がっていかないと、本人のモチベーションには繋がらないですよね。
確かに。
実際、木澤さん、資格めっちゃ取られましたけど、業務と関係なく資格のために勉強して取ったみたいなものもあったりしますか?
昔、ただ全く関係ないのは取ったことはないかな。
クラウドやる前は結構レッドハットだとかサンジャバだとか色々と資格取ったことはありますけど、
何らかしら小さくも関係してたかなっていう。そうじゃないとモチベーション上がんないかなっていうのはありますよね。
そうですね。モチベーションが大事ですよね。
取れって言われて取るのはすごく大変なんですよ。本当モチベーション上がんないから。
資格って自分から資格ってチャレンジするとモチベーション上がるんですよ。この資格取ると取りたいっていうか、
この資格を取って他の人の必要よりも先に取るぞというふうに自分から取りに行くとすごくモチベーション上がるんですけど、
誰かしらから取れって言われて取りに行くとか、あともうみんな取ってるから自分も取らないとっていうふうに追い込まれるとすごい辛いので。
ちょっとでも前のめり。
少なくとも自分から前のめりに取りに行くように、自分を仕向けるようにコーディネートしてます。
そういうことですね。
なんとなくデブレルのオンボーディングの話に戻るんですけど、そういう指標があったほうが分かりやすいのかなっていう。
分かりやすいですよね。
いろんなデブレルだったり技術的な広報だったりだとかいろんな言い方ありますけど、ある程度そこのフレームワーク化されるといいよなって思いますね。
ちょっと話、ごめんなさいちょっと逸らしちゃうと、技術広報という名目で人を採用したこともあるんですけど、
なかなか広報経験者っていう形であっても技術にバックボーンのない人だと全く話がつくうちに全然苦労した経験もあるので。
そういうもんなんですね。
少なくともやっぱり技術に、だから私は広報的な活動が、アウトプットだとか広報的な活動ができるエンジニアじゃないとダメだと思っていて、
やっぱり若干技術に明るい広報って人もいるんですよ逆にね。
別に文句言ってるわけじゃないんですけど、ネガティブな話じゃなくて、なかなかそこの手あるんだなってちょっと最近思ってます。
その見せ方だと思うんですよ、広報のやることって。
同じリンゴだったとしても、それをどう見るかによって響くリンゴの紹介の仕方、響くリンゴのアピールの仕方をやらないと、
それを食べたいと思わないし、仕入れたいと思わない、だったら意味がないわけで。
そういった意味で多分技術が、これがどういう可能性を持っているのかとか、どこにいいのかみたいなことがきちんと理解できてないと、
多分広報としての役割を果たせないと思うんですね。
技術者のアウトプットと技術広報の役割
ただ技術者が多分それをうまく広報の人に説明してない気もするんですよ。
口下手なのか、言うのは彼だろうみたいなのかわからないですけど。
そこはライティングでやっぱりプレスリリースを書くのにとても得意な人とかもちろんいて、
そういった人たちとちゃんと役割分担してですね、やっていく。
ただまずは技術、今おっしゃられた通り、エンジニア側っていうか技術者側がちゃんとアウトプットするための元ネタをちゃんと準備できるところまでちゃんとやる。
そっちのほうが重要かなっていうところですね。
そうですよね。
それでいうと、昔Googleって今もあれですけど、ラボみたいなサービスがあって、
中からいろいろわけのわからないものをボンボン作ってた時代あったじゃないですか。
そこをGoogleのプロダクトマネージャーって呼ばれる人たちってめちゃくちゃ優秀で、
エンジニアの作ってくる意味のよくわからない安全に技術良いものをビジネスに消化させるっていうところがすごく上手だったんですね。
その人たちは技術的な素養があるかどうかって全然わかんないですけど、
アピールの仕方とか見せ方とかGoogleらしさみたいなところの打ち出し方が上手だったからこそ、
エンジニアの人たちもこれ面白そうなサービスだなとか、ビジネスの人たちもこれ使ったらこういう面白い収益方法できるかもみたいなのを考えられたわけで、
そういう候補であったりとかプロダクトマネージャーみたいな人が、
磨き方を考えなきゃいけないんですよね、見せ方がね。
そうですね。
私ももっと頑張んないと、そこは。
結構苦労してますか?
実はサービス開発側じゃないので、いつもやってるかっていうとそういう話じゃないですけども、
アピールの上手さってあるんで、そこを引き続き頑張ります。
意外と中の人ほどその価値を見誤ってるとは言わないですけど、見出せてない場合はありますね。
それを外の人とかに見せたときに、あれ?これってこういうことじゃないですか?みたいなこと言われると、確かにみたいな。
そういう側面ありますね、みたいな時ってありますよね。
特にクラウドサービスとかはそういった意味でもなるべく開発者のモチベーションをシュリンクさせないように、
なるべく創造性が広がるように打ち出さなきゃいけないんですけど、
それを下手に書くと、何言ってんだこれ?みたいなメッセージになったりしますよね。
いくつかコメント来てますね。
まず札幌のじゅんさんですね。
サイエンスコミュニケーター的なスキルの必要性は感じると。技術広報に対してですね。
サイエンスコミュニケーターっていうとあれですかね。
博物館とかにいらっしゃるような、案内してくれるような人とかでしたっけね。
さくたろうさんからですね。
技術が好きな技術広報だと魅力の発信力は格段違いますよ。
そうなんだ。
この技術が好きなってどういう感じなんですかね。
自分で手を動かしてる方ではないわけですよね。
普段手を動かなくても本当に技術が好きでテッキーな人っているんですよね。
広報側にそういう人がいると本当に魅力が増すんですよね。
でもテクノロジー企業なのでそういう方の方が広報を向いてますよね。
そういう人であることが望ましいんですけど、全員そうかっていうとそうではないので。
広報は広報で、広報はメディア対応だとかそっちの方のお仕事の方がメインですから
テクノの内容にどこまで踏み込めるかっていうと
IT企業でも限界はあるかなと思いますね。
そういうもんなんですね。
もう一個さくたろうさんから来てますね。
難しいんですよね。技術者にマーケティングスキルが求められると。
私はこっちの方が早いかなとは思うんですよね、個人的に。
私も技術者がマーケティングスキルを得た方が早いと思います。いいと思いますね。
ただ最終的に広報としてでは別にあるんですけど、それをそれとして。
そのほうが良い結果が得られると私は思います。
そうですよね。私もそう思いますね。
ジャニーマンさんからですね。
案外ハンズオンレベルはやってそうですねとありますが、これ木澤さんの会社ではいかがですか。
あれですよね、ボーディングどこですよね。
広報の方向けだと思いますね。
広報は完全にスタッフ職向けにやってないですね。
理解してもらう必要があると思うんですけど、やっぱりその実際に手を動かした方が理解しやすいかなと思うんですけど、そういうことはないんですかね。
いろんなちょっとプロダクト製品を扱っている会社なんで、クラウドだけとかAWSだけっていうところはちょっといかないもので。
はい、そういうことですね。
はい、あと作太郎さんから、そもそも広報業務っていうロールは情報発信する際に、世間にどういうインパクトが出るかっていう言語化が求められると。
そうですよね。
これが一番大事なポイント。
そうなんですよね。広報っていうのは、どれだけメディアに取り上げられて実写のプレスリリースが広まるかっていうところにKPIを持ってるので、
そういう形になりますよね。
最近だと何があるかな。なかなかこのIT系で、
例えばビジネスサテライトとか、ああいうので取り上げられるって聞かないですよね。
IoT系がちょっと前とかは、こういう自宅の鍵をクラウドで操作できるとか、そういうのがあったかなと思うんですけど、
やっぱり物があった方が普通の一般の視聴者には理解しやすいですよね。
製品という意味だとそうでしょうね。
あと最近、本当にクラウドと生成バージョンとか、
一般の新聞を読んでもそう思いますけど。
AWSサミットではどうでしたか?
やっぱり生成AIのネタをやってるところが結構お客さんを集めてましたよ。
そうか。じゃあ需要もニーズもあるんだ。
ニーズもある。
結構それ自体はビジネスにならないんで、
それを使ってどうユースケースを作ったりだとか、周りのシステムを作っていくかっていう話ですかね。
というところに、
なかなか日本のスタンプで、
ユースケースを作る人が多いので、
私もそれについても、
ユースケースのことをですね、
ちょっともう言うと、
ユースケースを作っていくというのはまさに、
技術者のアウトプット活動
一般的なモデルの人にとっては、
ユースケースを作る、
もう勝者になっちゃってるじゃないですか なかなかその日本のスタートアップとかで
そこの土俵で勝負するの難しくはなってますよ なんかニッチなところで攻めるしかないと思うんですよ
ただいろんな活用というとまだまだこれからアイデアは出せるんじゃないでしょうか
そうですね 日本人だったらね小型化とかがもともと得意だったりするんで
なるべく小さいサイズでね デバイスに持たせるとかね
地形とかになるかもしれないですね
そしてコメントまだ来てますね 小田翔さんから 確かに技術者がスキルを身につけた方が早い気がするなぁと
視点の違いも確かにありそうだけど そうなんですよね 私そのさっきの
技術が好きな広報っていうのが結構なんか引っかかってて なんか技術が好きっていうのは
ある意味その人の本当根底の素養に引っかかっちゃってる気がするんですよね そうなんですよ
もう 興味があるないっていうのではっきり分かれるものかなと思うんで
なんか広報は仕事としてやったりとかやりがいを感じるみたいなのは確かにあると思うんですけど
もう技術が好き嫌いみたいな もう何でしょうね ターミナル見ると黒白の画面見ると疎通するみたいな感じになってたら
難しいと思うんですよね なかなか
そうですね 技術者のスキルが先に来た方が私も良いような
はい 軸足は技術の方が良いと思います
じゃあニューマンさんからは 最近テレ東では AWSサミットがニュースになってました
そうですね AWSサミットは流石にニュースにはなりそうな気がしますよね
まだ来てますね 作太郎さんから 技術者が広報スキルを高める難しさって
ビジネス収益モデルを言語化できたら最高ですよねと来てますが
確かに技術者はあんまお金に関わりたくないから技術者やってる面も一部にはあるかなと思うんですけど
そういうところは営業さんとか マーケとかにお願いしたいみたいな
なかなかお金を追いかけるところって ビジネス収益の部分考えるのって難しいですよね
あとは小田翔さんから 技術者 マーケ分かる技術者 技術分かるマーケみたいな
そうそうそう
木澤さんはこれで行くと マーケ分かる技術者になり
マーケ分かる技術者の位置づけです だと思っています
ただ 当社はあんまり マーケの組織立ち上がったばかりというか
立ち上げ途中にあると まだカッテン登場の状態なので
他にマーケ担当がいないので マーケのリーダーやってる感じです
マーケ分かる技術者として
でもなかなか 新しくマーケの方が入ったとして
クラウドの世界であったりとか 自社のプロダクトとかを理解するのはなかなか難しいですよね
マーケ専門で支援してくれる担当者も 別にいるんですけど
マーケの社内にいるんですけど
ただ やっぱりサービスオーナーというか その部署の
そのプロダクトを扱う 私であったらAWSを扱う部署の人が
やっぱりリーディングしないと やっぱり分かんないよねっていう話なんですよね
話し手1 & 話し手2 うん うん うん うん
話し手1 そうですよね
ってことは木澤さんの言語化能力に 結構関わってくるってことですよね
話し手2 そうなんですよね
ちょっとそこのなんだろう ちょっと今メンバーの育成に苦労してるんですけど
話し手1 うん うん うん うん
話し手2 はい
話し手1 はい
で 順さんから 好奇心は育てられないんですよね
スポイロは簡単ですかと
そうですよね そうなんですよ
なんか技術ってほんと好奇心の世界のような 気がするんですよね
話し手2 うん うん うん
話し手1 そして小田翔さんから
たぶん我々が過去抱いた嫌悪感は
技術好きな 技術分かるマーケでない人が
分かる顔してビジネス利用を考えているからだと思うんですよね
そうですね 言いたいところは分かりますけれど
あまりこれを深く掘り下げると
反感を招きかねない
ちょっと危険な意見なような気がしますね これはね
あんまり言い過ぎないほうがいいんじゃないでしょうかね 小田翔さんね
話し手2 うん うん
話し手2 ダメですよ こういうこと言っちゃ
読むべきじゃなかったな
話し手1 ではですね 木澤さんプライベートチャットの方にURLをお送りしました
今日のメインテーマの方ですね
私のアウトプット活動と題してですね お送りしていきます
はい ではですね まず最初の1件目ですね
木澤さん 読んでいただいてもいいですか?
話し手2 はい 1件目 ミキホアさんからいただいております
JK時代は毎日ブログを書いていましたが
いつの間にか場がミクシンに移り
毎日は書くのはなんか恥ずかしいなと思って書かなくなり
GENX 旧ツイッター
ごめんなさい ちょっとこれ書く よいしょ
2番を移しましたと はい
今は産業日記をノートで書くように意識しています
先月からは技術者の人が集まる場で
ライトニングトークをかます機会をいただき
技術者じゃないけども聞いてくる人の心を掴む
発表を心がけています はい 以上です
話し手1 確かにこのアウトプット意欲って
多分ブログだろうがソーシャルメディアであろうがあんま変わらなくて
ソーシャルメディアでポロッと書くようになっていくと
ブログが止まっちゃってるっていう人は
結構多いような気がしますよね
話し手2 なかなか…
話し手1 そうですね 書きたいアウトプット意欲って意味だと
SNSでも ですけど 私はうまいこと使い分けていますかね
話し手2 そうなんですね その使い分けはどんな感じですか
話し手1 SNSは Twitter Facebookぐらいしかやってませんけども
基本アウトプットする内容を拡散するための
SNSというふうに理解しているので
使い分けている感じです
話し手2 確かに まずブログにアウトプットして
それを拡散する際にSNSを使っていくみたいな感じですね
それはいいですね 確かに
そういうふうに区切りをつけておかないと
どうしても楽な方を楽な方に アウトプットを流していっちゃうので
話し手2 それこそブログですね
ブログ意見書くのも結構ね
それなりの力量 パワーはかかるので
話し手1 そうですよね 木澤さんのところは
社内レビューとかあったりするんですか
話し手2 レビューは一応しています
一応社内的には広報のお住み付きを
広報の権限を一部移情してもらって
私に責任移情されている状況と理解しているので
やっぱり会社として出していい内容かどうかっていうのは
一応チェックしています
話し手1 そうするとなおさらやっぱり
ちょっとしたことをアウトプットしようと思った時に
ブログだと社内レビューがあるしなみたいな感じで思っちゃうと
楽な方を楽な方に見る
えーレビューあるんですかって言われることはやっぱりあって
ただやっぱりちょっと理解いただいています
ただ本当にでも個人ブログでももっとか
それこそ聞いたとかそういったところに発信できるような人であれば
勝手にそっちで出してるし
逆に当社だと自社でエンジニアブログやってて
本当に助かりましたっていう人もいるんで
当社の人がアウトプットするための手段として
会社のオスルミツ決められればさっき言った表彰にもつながるんで
そういった意味だと使い分けても
各個人で使い分けていただければそれでいいかなっていう感じですね
話し手2 確かに
AWSサミットみたいなところだとパートナーに表彰が来たりしますもんね
確かに分かりました
ではですね2件目私から読ませてもらいます
ツイッター実況の効果
DevRelName 札幌のじゅんさんですねいつもありがとうございます
いろいろやっている中で最近の重要なアウトプットは
よそのコミュニティイベントでのツイッター実況ですと
私の知る人がその実況内容を見て
そういう勉強会があることを発見してくれることを狙ってつぶやいています
配信URLやコンパスページ会の目的やタイムテーブルなどをセットでつぶやいているのは
即座に合流しやすいようにするためです
私自身の勉強のためだけであれば
別につぶやく必要がないところもポイントです
フォロワーさんは趣味や課題意識が近いところもあり
追っかけで合流している人もちらほら確認できます
単一のコミュニティに閉じこもるのではなく
コミュニティ間の行き来の中から
新しい機会につなげていってほしいなと思っていますと
これはすごいなんかギバー精神にあふれた内容ですね
勉強会でアウトプットをしている人
ツイッター実況をしている方は本当に素晴らしいなと思っていて
私は実はほとんどできないというか
発表内容を読んだらそれを理解する方に
もう能力取られちゃってアウトプットできなくなっちゃうみたいな感じですね
そうなんですね
何でしょうね
インプットとアウトプットのストリームで流すのなかなか面倒ですよね
はい インプット
脳がインプットモードになってしまうと
ずっとインプットになっちゃって
いいね いいね
そうなんですよね
質問タイムとかもそうですよね
なんか登壇終わって
インプットタイムが終わった瞬間に
いきなり質問してくれって言われても
まずそのインプットを消化するところに時間を費やす
そうそう
わかる これ難しいですよね
最初からストリームモードでやるんだっていうことであれば
そういうふうに割り切っちゃえばできるのかもしれないけども
ちゃんと理解している
ある程度もともと理解している内容のイベントじゃないと
なかなか難しいかなってありますよね
そうですよね
最近グラレコみたいな真似事始めてますけど
本当に脳みそ疲れますね
一言一句理解する必要ありますもんね
そうですね
でも全部は書けないんですよ
なので理解しつつも
ここはいらないっていうか
ここはアウトプットじゃなくてもいいなみたいな
そのフィルターを流しながらやってるんで
だからちょっとメモっといて
後でもしかしたら使うかもみたいな感じで
メモりつつ
使わなかったら消すみたいな
3件目せっかくなんで
木澤さんご自身の読んでもらってもいいですか
アウトプット実績の重要性
はい
3件目T・木澤です
人並みですがブログとイベントでの登壇中心です
ブログ記事の掲載先は
内容により会社のサイトと個人ブログサイトから
選んでアウトプットしています
マーケティング担当でもあるので
自社イベントを企画して登壇することもありますが
もちろんコミュニティイベントでの登壇の方が多い感じですね
WS界隈ですと表彰制度があって
年間のアウトプット成果をアピールする必要もあるので
アウトプット実績は一覧化するようにしています
以上です
素晴らしいですね
このアウトプット実績っていうのは
完全に個人用ですか
それとも会社のところに蓄積していますか
個人で管理しています
ブログ何件
1年間でブログ何件書いたか
アウトプット
アウトプットでは登壇は何件したかっていうのは
一覧化しています
素晴らしいですね
こういうアーカイブをね
ちゃんとやらなきゃいけないなって思うんですけど
私は逆にアーカイブがめちゃくちゃ苦手なので
レポーティングとか
後で1年間の活動実績をアピールしないと
っていうときに
あれって何件したっけなって
確認する必要があって
それもちょっとある程度メモっとかないと
特にこれは良かったねっていうのは
とか
これ何人参加しただとか
あとPVが多かったみたいなところも
ちょっとメモっとかないと忘れちゃうね
素晴らしいですね
実際登壇したときに
メタ情報として残しておくのって
例えばどんなことを残してるんですか
基本そのイベントの
オンラインイベントが中心ですけども
イベントのやっぱり参加者だったりとか
Twitterでバズったとか
そういったことはちょっとメモっておくようにはしています
素晴らしいですね
やっとかないと
オンラインイベントとかね
Zoomのときにパッて人数見たりとかしてね
何人とかやっておかないと
なかなか記録残すのめんどくさいですもんね
そうですね
コンパスでのイベントのときには
登録者数っていうのも確認しつつ
素晴らしい
見習わなきゃいけない
本当に
大事ですね
Zoomアピールしないと
なかなかっていうのがあって
でも何でしょうね
やっぱりアピールするためには
きちんと記録が必要だと思うんですよ
上司に見ててくれるよねみたいな
そういう依存しても
絶対忙しいから見ててくれないじゃないですか
ちゃんと証拠を
エビデンスを残しておくっていうのが大事ですね
先日ありましたよね
評価される
評価されるエンジニア
アピールするのが上手いエンジニアだみたいな
なんかあった気がしますけど
でもアピールするためには
ちゃんとアーカイブ残しておくっていうところですね
そうなんですよ
これやったっていうのを覚えておかないといけないです
確かに
すごい学びになるな
ありがとうございます
ではですね
続いて
DevRelNameジャーニーマンさんですね
いつもありがとうございます
アウトプットは所属に基づいた聞いたや登壇
ひも付かない実況ポストノート
Together
Together登壇ですと
スライドはドックスウェルにしています
OSS貢献に憧れがありますという風にいただいてますね
結構いろいろあれですね
いろいろされてますね
いろいろ先が多いっていう感じですね
木澤さんはやっぱりなんか絞り込んでるタイプですか
それともいろいろやるタイプですか
私はさっきの通り
ブログと登壇ぐらいしかしてないですね
スライドはスライドじゃなかった
スピーカーズデックの方に上げてますけども
それも別にどこかで登壇した内容を
後でアーカイブするために出してるだけです
ブログは完全に会社のやつとか
会社と個人ブログサイト両方やってます
どちらかというとマインド系
テックな内容であれば会社でもいいんですけども
どちらかというとパッション系の記事というか
先日取り上げていただいた例の
技術コミュニティで参加するとなぜいいのかという記事なんかは
会社のサイトでああいうの出せないので
個人ブログサイトに出したりだとか
使い分けてますね
内容によって使い分けは必要ですよね
逆に言うとカテゴリーが決まっていれば
こういう時には会社のブログで
こういう時には個人ブログでというように
使い分けができるというところですかね
そうですね
どっちも最終的なアピールにはなるので
どっちでもどっちもより効果的な方に
アウトプットしてる感じです
そういうことですね
分かりました ありがとうございます
では4件目ですね
こちら木澤さん読んでもらってもよろしいですか
こちら4件目 作太郎さんからいただいています
いつもありがとうございます
私のアウトプット活動ですが
ここ最近は些細な気づきを
思考整理としてブログに書くようにしました
こっそりとですと
私の思考整理のためだけに書いているブログなので
ブログを書いた時に
X等のSNSに書いたぞって
無理に発信せずにまとめているだけのものです
これを続けてきたことの効果ですが
求められた時の応答力が格段に向上しました
さらにこっそり書いたブログに高評価、いいねや
ハテナブックマークが付いていると嬉しいですね
以上です
いいですね
こういう些細な気づき
ブログって自身の微暴力だってよく言うじゃないですか
マックスとかも確か言ってると思うんですけど
まさにそれですよね
最終的にアピールすることばっかり
さっき言った広報的な
マーケットが広報的な方ばっかりになっちゃうと
せっかく書いたからアピールしないと
っていうようなところに目が向いちゃうんですけど
それは本質的じゃないんですよね
っていうところなんです
確かに
どうしてもせっかく書いたんだから
みたいな考えになっちゃいますよね
そこはちょっと
そっちばっかり行っちゃうところを
かなりマーケットとしては
反省するところが時々あるんですよね
アピールする方ばっかりに目が向いちゃうと
本質じゃないでしょっていうところなんですよね
ちゃんといい記事を書きましょう
そうですね
もうちょっとゆるい垂れ流しを
この作太郎さんみたいに
日々の垂れ流しをとりあえず
ストックしておく場所として
も考えるっていう感じですかね
いい話だな
確かにな
思考整理大事ですよね
私はなんかあれですね
最近はもうグッドノートっていう
手書きで残せるやつに
とりあえずメモ書きで残しておくみたいな
感じですかね
アウトプットまではしないかな
とりあえず仕事で問い合わせとかが
社内社外問わずあったときに
もう自分のブログが
はまったときの嬉しさといったら
っていうんですよね
はいはいはい
確かにねそれは分かりますね
そういう時のために吐き溜めておく
っていうことですよ
自身の微暴力のために
っていうのもあるんですけどもちろん
それが他人の役に立ったときの
嬉しさはやっぱり格段なので
そうですね
でも自分の困ったは
誰かの困ったでもあるので
そうです
でも困った人が探したときに
木澤さんのブログにたどり着かないと
つまり木澤さんが元ネタを
ちゃんと書いておいてくれないと
たどり着けもしないので
やっぱこう蓄積はしておく
必要がありますよね
そうですね
そのために日々
日々気づいたことはアウトプット
というのを野作太郎さんのように
メモ書きでもいいから残しておく
とても大事だと思います
これでいくとこの後
その後が西から来た
マザラの男さんですけど
西から来たマザラの男さんは
手書きノードなんですよ
ブログよりも
デジタルよりも
多分手書きの方が
とりあえずの気持ちを
出しておくという場としては
手軽かもしれないですね
なるほど
Apple Watchとかで
To Doに書いておいてとか
メモしといてみたいなことを
何回言って何回
何言ってるかよく分かりませんみたいな
切れたくなるみたいな
デジタルデータは
あとは
キーボードでバババって書いて
パッて見たら
全部英文字になってた瞬間とかね
日本語になってなかったみたいな
あの瞬間のやる気をなくす瞬間
なるほど
手書きの方が
残しやすいのかなって思ったり
昔ね
私も手書き習慣やめちゃって
7,8年ぐらいかな
でも前はよく書いてずっとね
お客さんとのミーティングとか
いろんな案件とか
ずっと仕事中
ノード書いてたなって
それは何で切り替えちゃったんですか
なんでかな
オンラインっていう話でもないんですけど
このツールでやったとか
そういうわけでもなく
そういうわけでもなくですね
ちょっと忘れちゃったなごめんなさい
ただ当時のメモノートはまだ残っているし
ささっとね
絵とかもささっと入れかけるので
いいんですよね
そうですね
ではですね
そんな西から来た馬面の男さんからですね
いつもありがとうございます
自分のアウトプットを紹介させていただきます
登壇でのアウトプット活動
一つ目は登壇です
自分の仕事や業務で取り組んだことで
事例として他者にも活かせそうなこと
抽象化してまとめて知見になりそうなことがあれば
登壇できると思います
30代後半からしばしば登壇するようになって
その傾向が強まりました
仕事のテーマがあり取り組む
その結果再現可能な話になりそうなら
すぐに登壇を決めて
自分の経験をまとめます
よくあるのがこれが完成したら
とか達成したらと
気が熟すまで待つというパターンがありますが
お勧めしません
アウトプットしたくなった時がその時です
途中経過でもいいので
アウトプットするといいと思います
その過程で自分の勉強にもなります
同じ課題感を持つ人がいれば
共感が得られるんじゃないかと思います
世の中のニーズも測れます
二つ目はSNSでの発信です
SNSでの発信活動
自分は特に実況中継をします
一、参加者として参加して
ただ聞くだけなら
聞くだけでは残らないので
とにかく発信します
三つ目は社内スラックです
何か参考になりそうなことを
タイムズチャンネル
文法で呟きます
反応がなくても構いません
自分の微暴力的な感じです
以上です
社内スラックでのアウトプット活動
下書きをしていてすっかり投稿を忘れていましたと
いただきましたありがとうございます
うんうんうん
登壇ドリブンなんですね
なるほど
これはこれがありですよね
うん
そう
だいたいね 登壇はまずね
まずは申し込んでから考えるって話はありますけど
そうですね
そう
うん
確かに
そして
あとは
もうある程度引き出しが
引き出しが事前に揃ってないと
なかなかこう難しいかもしれませんけども
ある程度あればできるんじゃないかな
そうですね
最近でもちょっと思うところがあって
この登壇ドリブン
じゃなくても
えーと
アウトプットって勝手にやってもいいんじゃないかな
と思うんですよ
今はYouTubeであったりとか
動画の発信する場所って
いくらでもあるので
それを録画して
アーカイブとして
残すだけでも
いいのかなと
その登壇ドリブンで
自分がそのテーマにピッタリ当てはまればいいんですけど
そのテーマが来るまで登壇できない
ということで
せっかく自分が思っていることが
腐っちゃうともったいないんで
うん
アウトプットできるんだったら
それこそスライド
パパッて作って
自分でしゃべって
パパッとアウトプットしちゃえばいいんじゃないかな
って思ったりもしますね
そうそう
以前ちょっと記事書いたことありましたけど
最近そうですよね
自分がプレゼンテーションしているのを
動画化して
YouTubeとか乗っけても
アウトプット活動とSNSの人気
面白いかなと思うこともあるし
そういうの簡単にできるよね
うん
さっきの作太郎さんの
自分の
アウトプットをするみたいな部分じゃないですけど
あんまりPV期待したりとか
そうそう
YouTuberみたいな感じではなく
単純に自分がアウトプットしたいと思っていることを
アウトプットするだけみたいな
感じでも
いいのかなと思いましたね
うん
今回は動画なのしなかったですけどね
最近の
それこそZ世代とか
の方は結構
動画から情報を得るっていうのも多いので
アプローチにはそういうのも
今後はあるのかもしれないですね
そうですね
うん
あとはSNSについては
さっきのあれですね
札幌のじゅんさんと同じで
それをとにかくツイートするという
マーケティング手法と社内コミュニケーション
実況系ということですね
うん
実況系はなかなか大変ですよね
うん
ただそれが
特にオンラインの場合は
その一つの指標なので
ありがたいですね
結構
分析すると
本当につぶやいている人と
つぶやいていない人の率が激しいんですよね
うん
もう
本当につぶやいているトップの人たちがいて
ロングテールが続くみたいな感じになりがちですよね
そして
あと三つ目が社内スラックで
分報っていうのが変わってましたけど
木澤さんの会社なんか
どうあったりしますか
うちは
社内はスラックじゃなくてチームズ
なんですけど
でもいろんな自由に作れるので
今
随分活用が進んできているかなという感じです
うん
今回のAWSサミットの出展も
ちょっと関係者がめちゃめちゃ
多かったので
もう
部署が十いくつという部署と
やり取りをしていたので
コミュニケーションが見えるだと死ぬと思って
チームズ上で全部
やったんですけども
成功しました
ちょっと話しとれちゃいましたけど
いやいやいや
はい
このタイムズ
タイムズ文化ってどこから来たんでしょうね
なんかみんな
ありますよね
個人
タイムズフォニャララって個人チャンネルを作って
そこで
日々の
それこそだから
Xにポストするような感じで
日々の気持ちをちょちょっと書いておくと
誰かしら反応してくれたら嬉しいなぐらいの感じで
まとめるのに
とりあえずスラック使うって
すごくいい文化だなと思ってて
うん
確かに
文法を調べると結構出てきますね
うん
へー
これは
あとは社内コミュニケーションみたいなところになるんですか
社内というかあくまで個人
個人としての気づきを
みんなでも
見れるようにしておいて
うんうんうん
しておいて
共有できればいいし
そんなに重要なことでもないのであくまで個人として書きだめる
うんうん
ランダムに書くような内容じゃないかな
っていう感じのやつですよね
はいはい
でなんか面白そうな内容があれば
リアクションしたりとかする
リアクションしてあげればいいし
そこら辺はあまりハードルが高くないようにして
はい
だからもうXのポストにするようなもんですよね
スラックの中で
うんうんうん
確かに
まあ社内だったらね
機密情報漏洩とかもないんで安心ですよね
うんはい
わかりました
はいではですねちょうど時間となりましたので
今日のですね
ウェブラジオ170回目ですね
私のアウトプット活動は
こちらで終了していこうと思います
木澤さんありがとうございました
はいありがとうございました
ではまた皆さん来週お会いしましょう
さよなら
