集中力の重要性
皆さんお疲れ様です。今日は10月の21日ですね。夕方5時半になりました。
DevRel Radioの238回目、やっていきたいと思います。
まず最初にですね、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、大体ライブでやっているというものになります。
DevRelというのはですね、Developer Relationsの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えばテクノロジーエヴァンジリストとか、デベロッパーアドボケイトとか、
コミュニティマネージャーとか、マーケターとかですね、
そういった方々が集まって情報交換したりとか、
イベントをやっているといったコミュニティになっております。
DevRel Tokyoの公式サイトがありまして、
DevRel.Tokyoというサイトになります。
そちらからスラックに参加したりとか、
最近のイベントの情報とかチェックできますので、
ぜひウォッチいただければと思います。
あとはですね、公式のXアカウントが、
アットデブレル東京ですね、
あと公式のYouTubeチャンネルがあります。
ぜひチャンネル登録していただいたりとか、
Xのほうをフォローいただいたりとか、
いただけると嬉しいですというところで、
あとはXは普段、
シャープDevRelJPというハッシュタグでポストしてますので、
ぜひそちらもですね、
ウォッチいただけると嬉しいなと思いますというところで、
今日のですね、メインテーマが、
集中モードの作り方となっております。
仕事する上でですね、
どうやって集中するかというところ、
大事になるかなと思うんですけど、
最近あれですね、
生成AIでバイブコーディングとかやってるせいで、
ターミナルでガチャガチャ動いている状態と、
あと自分でブログ記事を書かなきゃとか、
自分の仕事のほうとかを並行してやっていると、
結構チラチラチラチラ集中力が途切れがちな気がするんですよね。
今もその作業をやりながら、
あんまりしつこく問い合わせしてほしくないなって思いながらも、
回答しないと先に進まないんでやっていたりとか、
ちょっとコンテナを作り直していて、
そのコンテナの中だったらいくら暴れても大丈夫なようにしていこうかなと思って、
今やってたんですけど、
ちょっとそれがうまくいかなくてですね、
VSコードでやるんだったら動くんですけど、
VSコードを立ち上げるの最近めんどくさいなって思い始めてるんで、
それを使わずに何とかうまくコンテナだけで開発できないかなって、
コンテナだったらこっち側に問い合わせをしないようにしながら、
ガツガツ作らせていくことできるんじゃないかなと思ってるんですけど、
それでもターミナルがガチャガチャ動いてる状態って、
集中しづらいような気がするんですよね。
というところで、
皆さんがどうやって仕事に集中するために工夫していることがあるかというところを、
ぜひお聞かせいただければなと思っております。
パネルディスカッションの内容
個人的にはなんだろうな、
一番良くないのはネットワークだと思うんですよね。
インターネットがあると集中が途切れる気がするので、
本当に集中したいときには作業する内容だけ持って、
どこかネットが使えないところに行くのが一番、
個人的には集中できたりしますね。
一番集中できないのは新幹線とかですね。
あれが最近中途半端にネットが入るようになって、
名古屋、新横ぐらいから名古屋に行くくらいの骨の過ぎたあたりとか、
あとどこだろうな、大阪から神戸に行くあたりとか、
さらにちょっと先とか、
ネットワークがすごい弱いんですよね。
使えないんだったら全然いいんですけど、
微妙に使えるみたいな感じで、
でもタイムアウトし続けるみたいな感じで、
あれがすごく集中しづらかったりするんですよね。
なので、ネットワークなしにするんだったら、
飛行機のほうがよっぽどいいかもしれないなって思いつつ、
最近確かANAとかも国内線で普通にネットワーク使えるようになっちゃってるんで、
自分をネットワークのない環境に追い込むのが、
一番集中しやすい環境にできるかなと個人的には思いますね。
というところで、まだまだそちらの話題は、
まだ30分ぐらいしてから取り上げていこうかなと思うんで、
ぜひ今のうちに皆さんご意見いただけると嬉しいですというところで、
それまでは最近のDevRelに関連した話題を取り上げていこうかなと思うんですけど、
まず最初は先週に引き続きDevRel会議の話ができればなと思うんですけど、
まず最初がパネルディスカッションですね。
先週は確か日本語のキーノートのお話をしたかなと思うんで、
今週は英語のほうですね。
まず最初がパネルディスカッション。
こちらは10月4日の内容ですね。
デベロッパーコミュニティをテーマにしたパネルディスカッションをしまして、
そちらのほうのお話となっております。
今回ですね、もともとその10月4日がテーマがデベロッパーコミュニティデイっていう形だったんですけど、
そこキーノートスピーカーはいたんですね。
ちょっとこう急遽来れなくなったっていうところがあって、
そのキーノートの部分どうしようかなっていうのを考えた結果、
パネルディスカッションにしましたと。
とりあえず1人モデレーターがいて、
あと3人パネルリストがいればどうにか形にはなるだろうというところがありつつ、
英語が問題なく話せて、かつ日本でやるんで、
わざわざ外国人の人にパネルリストに入ってもらったりとかするのももったいないかなというところがあって、
日本人の方だけでいければなと思っていたんですね。
最初、ヒアテクノロジーズの大地さんに打診してOKもらって、
その後Linux Foundationの福安さんにお話しして、
福安さんもOKいただいて、
最後GitHubの服部さんにお話しして、
OKもらって、パネルリストが3人揃って、
モデレーターは誰にしようかって考えて、
最悪私がやればいいと思ったんですけど、
でしゃばりすぎるのも良くないので、どうしようかなと思った結果、
オースゼロの池原大前さんに打診したら、
彼もOKもらったというところで、
無事形になったかなというのが10月4日のパネルディスカッションになりますと。
お三方とも幸い会社コミュニティに関わっているというところがあったんで、
日本のコミュニティの独自性みたいなところもお話ししつつやっていったというものになります。
まずグローバルなDevRelというところでいくと、
割とオープンソースへの貢献であったりとか、
文化的・言語的障壁
純粋な開発者コミュニティ、技術フォーカスした開発者コミュニティの拡大みたいなところに
フォーカスすることが多い一方で、
日本の開発者コミュニティって割とベンダー寄りのところ、
一番有名なのだとジョーズUGみたいなものもありますし、
他にもキントンカフェとかもあるかなと思うんですけれども、
日本の場合でいくと割と企業ユースに密接に結びついた形が多いんじゃないかという話がありました。
海外に関しても別にユーザーグループ、そういったユーザーグループがないかと言われるとそんなことはなくてもちろんあるんですけれども、
それ以上にオープンソースのコミュニティとか、
純粋な技術にフォーカスしたコミュニティもかなり強いといったところですね。
その後がベストプラクティスに関する話に移っていきましたと、
そのコミュニティ参加の目的をどこに置くのかみたいなところが重要だよねっていう話をしたりとか、
あとはお互いの参加者同士の知識の共有の価値みたいなところを取り上げたというところですね。
あとはマーケティングとかでよくありがちなんですね。
ミートアップをマーケティングの機会と捉えることに対する警戒を促し、
お互いの競争関係を作るというところに重視すべきだというところをトピックとして取り上げていったというところですね。
あとはKPIに関するところに関してなんですけれども、
参加人数であったりとか、あとドキュメントの作成とかオープンソースへのコミットといったところを測定していくというところの提案がなされたというところですね。
ドキュメントの作成は、これはハットリさんが言われていたんだったかな?
それともLinux Foundationだったら当然、さまざまなドキュメントの修正とかがコミュニティベースでやられていたりするんで、もしかしたらそっちかな?
富谷さんのお話かもしれないですね。
そういったKPIを置くというところですね。
最後に日本のコミュニティ環境を形成する文化的、言語的障壁についてのお話がありました。
これは文化的ってどうなんでしょうね。
言語の障壁はすごくあると思うんですよね。
私がパネルディスカッションで一つ質問させてもらったのが、言語の障壁に関してですね。
どうやってそれを改善していくというか、破っていくのかみたいなところを質問であげたんですけど。
やっぱり難しいですよね。
イメージとしてなんですけど、
ミートアップの中にですね、外国人の人が来ましたと。
その人は日本語あんまり喋れないんだけど、日本のテックシーンというところを知りたくて参加して、もしかしたらLTとかをすると。
まずその、逐次ついてくれる人がいないというところがあり、
万が一いたとしても、その後の交流みたいなところが、なかなかその積極的に話しかける人がいない場合が多いかなという気がするんですよね。
逆にその、英語のコミュニティは日本でもいくつかあって、
このパネルディスカッションとは別で、
名前が出てこない。
ミッチェルではなく。
名前が出てこなくなっちゃったな。
リンクトインのメッセージが全部消えてしまって、
名前が出ないんですけど、
一人ですね。
登壇の方から調べればいいんだ。
デブレル会議の登壇者。
ミッチェルでいいのか。
あれ、私いつもミッチェルって呼んでたかな。
ミッチェルさんですね。
ミッチェルさんが日本でコミュニティをやっていて、
DevJapanっていうコミュニティか。
多分これがね、
外国人向けにやられて、外国人って言っちゃよくないですね。
英語話者向けにやられている日本の開発者コミュニティとしては、
多分一番大きいんじゃないかなっていう規模のものですね。
ずっとやられていて、
私も何回か参加させてもらったことあるんですけど、
まず日本人いないんですよね。
いても一人、二人ぐらいポツンといて、
逆にめちゃくちゃアウェー感を味わうんですけど、
っていうぐらい、
英語話者と日本語話者のすごい壁を感じるんですよね。
これを何とか壊せるといいなって思ってるんですけど、
なかなかうまくいかないなというところも感じてますね。
登壇者の方はAIツールによる翻訳であったりとか、
Q&Aの自動化を通じて知識交換を変革する可能性はあるものの、
コミュニティ構築における人間関係の中核的価値は、
だいたい不可能であるというところを挙げていたということですね。
そうなんですよね。
AirPods Proで音声翻訳してくれるみたいな機能が出たと思うんですけど、
じゃああれが翻訳こんにゃくじゃんみたいな反応とかあったりするんですけど、
あれつけてコミュニケーションするってまずありえないと思うんですよね。
一方的に聞くだけで、
例えば英語セッションを聞くみたいなときに、
ああいうAirPods Proを耳に当てはめて、
その登壇されている方のしゃべる、
英語じゃなくても多分使えると思うんですけど、
そのしゃべっている言語がその場で翻訳されて、
耳に日本語で入ってくるみたいな、
そこはすごく使い勝手がいいと思うんですよ。
それはすごくお勧めだなと思うんですけど、
あれを耳につけて目の前にいる人とコミュニケーションするって、
すごく難しい気がするんですよね。
向こうは普通に英語でしゃべっていて、
こっちは日本語で耳に入ってくる。
それに対しての返答を英語でするのってすごく、
多分私はめちゃくちゃ難しいと思っているんですよね。
それだったら英語で入ってきて、
英語で返す方がまだ楽な気がしていて、
それに対して相手にAirPods Pro片耳だけ渡して、
そこからボローンみたいな音がしたら、
そこから会話スタートみたいな、
デブレル会議のコミュニケーション
それもコミュニケーションとして難しい気がするんですよね。
なので一方的なコミュニケーションで、
その登壇する人、聞く人みたいな感じであれば、
そういうAI活用みたいなものはありえるかなと思うんですけど、
ことコミュニケーションっていう部分において、
相互に情報を、相互に発話し、相互に聞くっていう場面において、
なかなかこのAIで変えられる部分っていうのは、
少ないんじゃないかなと思うんですよね。
今回のデブレル会議とかでもそうなんですけど、
デブレル会議の場合って、
英語トラック2つ、日本語トラック2つみたいな形式でやった場合に、
その英語トラックに来てくれる日本人の人めちゃくちゃ少ないんですよ。
それがすごい残念だなっていう部分があって、
デブレルコン東京の場合は、
もう全部英語トラックっていう縛りでやっていたので、
強制的にもう英語を聞くしかないっていう状態にはなっていたわけですよね。
話す人も登壇する人も強制的に英語で話すしかない場合、
そういう状況に追い込んでいたので、
そうすると英語でコミュニケーションするっていうところも、
スムーズではないかもしれないですけど、
それぞれみんなトライできるし、
英語のセッションを聞いて、
意味がわかる状態になるっていうことはできていたと思うんですよね。
デブレル会議っていうたてつけで、
日本語トラックが追加されたがために、
日本語の方に人が偏りがちだったっていうのは、
残念だなっていう気はしたんですよね。
それこそさっきのAirPods Proみたいに、
とりあえず耳に当てはめてアプリなりを使えば、
英語のセッションでもそれなりにわかるように聞き取れたと思うので、
そこのチャレンジできる場面をなくしてしまったというか、
提供できなくなってしまっていたっていうのは、
ちょっと残念だったなと思いますね。
DevRelとマーケティングの関係
というところが、
こちらがパネルディスカッションのトラックの紹介になります。
もう一つのほうが、
10月3日ですね。
こちらはフォーマンスという決済の会社があるんですけれども、
そちらのマーケティングマネージャーをやっている
ドン・グッドマンのセッションになります。
こちらもXに投稿しておきます。
そちらの内容なんですけれども、
面白いのがですね、
もともとドンっていう人は、
GitHubで働いてたんですね。
GitHubのデベロッパーアドボケイトをしていて、
その後、B2Bマーケティングに入ったというところで、
フォーマンスのプロダクト、
違う、マーケティングマネージャーになったのか。
というところで、
DevRelに関してですね、
その存在意義によって自らを定義し、
ある意味空に閉じこもってしまっているというふうに主張していると。
そのマーケティングっていう部分と
DevRelっていう部分に、
自ら壁を作ってしまっているということですね。
そのドンにしてみればですね、
開発者と他のマーケティングで一般的に言われるようなオーディエンスと、
何ら根本的に異なるものがあるわけじゃないということですね。
ただ、DevRelの独自性っていうのは、
従来のマーケティングにおいてですね、
特に人っていうものにフォーカスしないと、
マスであったりとか、
人をグルーピングするような、
ペルソナみたいなものであったりとか、
あと、個別の人ではなくて、
リードみたいな感じで、
人くぐりにくくってしまうということが多かったと思うんですけど、
DevRelの場合は、
リデーションっていうところなくて、
人を見ると、個別の人を見るっていうところに、
独自性があったというところを紹介していますと。
ただ、逆にですね、
DevRelもですね、
いわゆる一般的なB2Bマーケティングから、
学べきポイントがいくつもあるというところで、
例えば、
信頼性が高く有用なコンテンツを作成するであったりとか、
あとは、いわゆるゲート付き、
これはお問い合わせしないと、
資料がダウンロードできないみたいな、
そういったことをしないとかですね。
あとは、
定量的な指標よりも、
人間関係の構築を優先するといった部分はですね、
逆か、ごめんなさい。
DevRelがB2Bマーケティングに対してですね、
提供できるいいポイントだというところを挙げています。
逆にDevRelというのはですね、
自分たちはマーケティングとは違うんだみたいな感じで、
ちょっとこう、悪い意味で、
湾曲して解釈して、
そういうマーケティングとかいわゆる営業みたいなものを
拒絶する動きもあるというところを
注意点として挙げているということですね。
DOMはですね、
DevRelの専門家、
テクノロジーエヴァンジリストとか、
デベロッパーアドボケートとか、
コミュニティマネジャーに対してですね、
DevRelを高めるチャンスとして、
マーケティングを受け入れていこうというところを
進めていると。
DevRelの共感と信頼性を、
B2Bマーケティングのデータ駆動型の厳密さを融合させ、
より新しいコミュニケーションモデルを構築することが、
将来への道だと提案しているというふうに書かれています。
技術発信の課題
これは非常にシジュに飛んでて、
私もすごくそこは納得する部分があるんで、
面白いなと思うんですけど、
これをですね、
どんには当然動画アップロードしたよっていうのは連絡したんですけど、
一緒にですね、
Redditにも投稿してみたんですね。
そのURLは今、Xでポストしたんですけど、
そこに対してですね、
2人ぐらいレスをくれていてですね、
それをどんにもですね、
ここに、Redditのここに投稿したからというふうに言ったら、
本人がコメントに答えてくれたりとかしてですね。
DevRelはトレーニング、ドキュメンテーション、オンボーディングなどではなく、
マーケティングにシフトしているという、
そういったとの意見はですね、
当然といえば当然だと。
ビジネスを生み出す側の一員であることは、
高い給料を意味し、
文書作成やトレーニングはコストセンターと見なされることもあるということですね。
このFisboさんという方がコメントをくれてるんですけど、
この視点もすごく大事だと思うんですよね。
DevRelがプロフィットセンターなのか、
プロフィットセンターなのかコストセンターなのかっていうのを、
ちゃんと明示しないと、
ちょっと前によくあったような、
レイオフみたいなところの嵐に巻き込まれる可能性は、
すごく高いと思うんですよね。
どうしてもコストセンターになってしまうと、
いらない人はいらないですけど、
予算を削られやすい存在になりますし、
AIとかで大体できるよねみたいなところが、
すごく分かりやすいというか、
マネージャーの人からすると判断しやすい存在になってしまうのかなと思いますね。
あくまでもビジネスを生み出す存在であるっていうところを、
保証し続けないといけないというところは強く感じますね。
もう一人の人がコメントをくれているのが、
その動画に対してまさにその通りだと、
DevRelの我々はマーケティングではないというのは、
あまり良くないんじゃないかというところですね。
確かに開発者は押し売りを嫌うという傾向はありますけれども、
それは他のみんなも同じことであるということですね。
これは言われて確かにそうだよなと思いましたよね。
別に開発者だけがそういうマーケティングメッセージを嫌うのかと言われると、
そんなことはなくてですね、みんな嫌いなわけですよね。
なのでそういった意味で従来のマーケティングのやり方っていうのも、
DevRelに取り入れる必要があるかなとは思いますね。
DevRelはリードではなく人に焦点を当てるという点は非常に大きいと、
ほとんどのB2Bマーケティングはホワイトペーパーをダウンロードしただけで、
コンバージョンに至るかのように開発者を扱っているということですね。
これはね、何をもってコンバージョンとするかというところかなと思うんですけど、
少なくともホワイトペーパーをダウンロードしたっていうのは、
コンバージョンではないとは思いますかね。
そこにコンバージョンを置くのは、
その後それをどうやって生かすかっていうところが分業されていると、
もしかするとそういったリードを作るだけっていう作業でいえば、
コンバージョンになっちゃうのかもしれないですね。
実際にはまず彼らの問題を解決し、
時間をかけて信頼を築く必要があるということですね。
そういったコメントもいただいていてですね、
なかなか今後英語の動画に関してはですね、
こうやってRedditにもどんどん投稿していこうかなと思っています。
というのがどんどんですね、
2つ目というか、本当はこっちが最初ですね。
どんの方が10月3日、パネルディスカッションが10月4日にやったものですけれども、
それぞれですね、YouTubeの方にはアップしてありますので、
ぜひご覧いただければと思います。
たぶんあれですよね、自動翻訳みたいなものもあったりしますし、
あとYouTubeのサブタイトルを表示するChromeの拡張とかで、
全部のサブタイトルをコピーして、
それを翻訳とかにかけると、結構ちゃんと予約してくれるので、
個人的にはおすすめですね。
あれ使うと理解度が全然違うんじゃないかなと思いますね。
今日は別な話題も取り上げたかったんですよね。
2つぐらいあったんですけど、
1つ目がですね、これはるさんちまんさんのブログで、
エンジニアが外部への技術発信をしない3つの理由と、
EMができることっていうところをですね、書いてあります。
もう1つの記事もこれも似ていて、
これはレバテックラボさんの記事で、
イベント以降のやらされ感をなくす、
ゼロから技術発信文化を組織に根付かせた方法、
ログラス飯田さんの記事ですね。
この中どっちだったかな、ちょっと待ってくださいね。
これはるさんちまんさんの記事の方で、
外部への技術発信を阻害する3要因というのを挙げてくれてます。
まず1つ目、発信することの価値がわからない。
2つ目、何を発信すればいいかわからない。
3番目、一歩を踏み出せないというですね、この3つを挙げてますね。
この中にですね、1番発信することの価値がわからないというところで、
エンジニアリングマネージャーとしてですね、
EMとしてこの課題に対して最初にやるべきことは、
エンジニアの評価項目に技術発信を組み込むというのを挙げています。
これがね、結構ね、あまりネガティブな反応が多かった部分なんですよね。
もしエンジニアの評価の技術発信しているかどうかみたいなところが
過点になっている場合、プラスにしかならないというふうにやると、
仕事の評価はそんな高くないのに、発信めっちゃしてる人っていうのが、
なぜか評価が高いみたいになりがちなんですよね。
エンジニアとしてまずやらなきゃいけない仕事があるはずなのに、
ブログ書いてますとか、どんどん外部に行って登壇してますみたいな人の方が
評価が高いみたいになると、若干真面目に普通にエンジニアとしての
システム開発であったりとか、テストであったりとか、
インフラの整備であったりとかっていうのをやっているからすると、
おいおいちょっと待てよと。
自分たちちゃんと普通に仕事してるのに、それ以上に
実は仕事量が自分たちの80%なのに外部登壇いっぱいしてる方が評価されるやんけみたいなことは
割とありがちなんですよね。
っていうところがあるのと、あとは技術発信をしなかった場合に
ちゃんとマイナス評価になるのかどうかっていうのが
コメントとして散見されたというところですね。
技術発信しなかった場合のリスクがないんだったら
多分しない人が多いのかなというところですね。
あともうちょっとあったのが
外部発信する前に車内のドキュメントをきちんと書けみたいな
そんな話もあったりとかして
そういうサービスがあるのかもしれないですね。
ドキュメントが仕様書であったりとか、詳細設計であったりとか
そういうドキュメントをお座りにして
業務における集中の難しさ
プレゼンテーション作ってる場合じゃねえだろうみたいな
そういう話かもしれないですね。
あと何があったかな。
あとはきちんとした記事を書こうと思うと
それなりに時間を要するものだと思うんですよね。
動作する時間をしっかり
それをちゃんとレビューするとかですね。
そういったところで時間がかかるのは
いたしかたない部分があるのかなと思うんですけど
その部分をちゃんと業務として取り組めるようにしてくれているのかどうか
っていうところが気になると。
言ってみれば情報発信に関しては業務時間外でやって
それに対して評価がつくんだとしたら
それってただの残業とあんま変わんないわけで
そういった時間も確保できず
プロジェクトの評価は求められるのに
さらにアウトプットまでしろって言われたら
それはやってらんないよっていうのは
確かにわからないでもないというところはありますね。
朝のルーティンとタスク管理
何を発信すればいいかわからないっていう
これもよくあるネタというかよくある話ですね。
この程度の内容では価値がないのではと
不安になってしまう声もよく聞かれるということですね。
これは何でしょうね。
意識的な声がけっていうのはすごく大事になるのかな
とは思いますかね。
あと一歩を踏み出せないと。
これは勝手にやってくれる人はいいですけど
そんな人ばっかりじゃないですからね。
なのでこれは伴奏が大事というところを挙げてましたね。
もう一個のほうですね。
これはログラスさんの記事になっているんですけれども
会社の中にそういったアウトプット
コミュニティ活動していくみたいな文化を作るためには
まず分かりやすい実績を見せていく必要があるということですね。
環境としてはコミュニティ活動しやすい環境を整えていくとか
あとは自分でプロポーザルを提出してイベント登壇して
その後のSNSの反応を見せていくと
レポーティングしていくというところで
その価値があるんだというところをちゃんと示していく必要があるんじゃないかと
いうふうに書いてあります。
あとはですね
この中でちょっと面白かったのが
イベント行こうよと誘っても
業務が忙しいから行けませんと
敬遠されるケースもあるかと思います。
どのように対処すればいいですかというところが書いてあって
業務時間を使ってイベントに参加することに
周りの理解が得られないケースが多いということですね。
これはさっきのアウトプットと変わらないかなと思うんですけど
その業務の時間の中で
何かをする、別なことをするということに対して
すごいストレスがある組織が多いですよね。
そういったことを聞かれたときに
この飯田さんの場合ですね、私はいつも
イベントはインプットの場としての
イベントはインプットの場として以上の価値があると説明しています。
例えばコミュニティでは経験豊富な専門家と気軽に話せたり
自分たちのリアルな悩みを相談して
多様な意見をもらえたりと
より実践的な学びが多くあります。
自分が参加しているアジャイル界隈のコミュニティだと
経験豊富なアジャイルコーチが
会場で気軽に雑談をしてくれることも多いですということですね。
面白いのがですね
ボッチでそういうイベントに参加するのは怖いし
リソースもないというところで
このログラスでは社内のエンジニアがよく行くコミュニティに
それぞれ長く活動しているキーマンを作るようにしていますというところですね。
その人が懇親会で他の人が参加しやすいように
会話の輪に入れたりとか
コミュニティへオンボーディングする役割を務めているというところですね。
この話を聞いて思い出したのが
何でしたっけ
カンファレンスバディだったかな
カンファレンスバディっていう
これは多分海外の仕組みなんですけれども
そういうテックカンファレンスに対してですね
一人で参加するの怖いよという人は当然多いと思うんですよね。
それに対してですね
一緒に突き沿ってですね
全部突き沿う必要はないと思うんですけれども
最初のオンボーディングみたいなところを助けてくれるという
そういったグループですね。
カンファレンスバディという
これの社内版に近いのかなっていうのは感じましたね。
確かにすごく初めて参加するところって
敷居が高いのかなと
無理に参加しなくてもいいというかですね
当然得られもあるんですけれども
そこでちょっとでも嫌な思いをするっていうのはですね
それはそれで嫌なことだと思いますし
そういった意味でもイベントとかに
同僚を連れてきたりとか
チームメンバーの方を連れてきたりとかしてくれると
その人も最初の一歩が踏み出しやすくなるのかなっていう気はするんで
こういうカンファレンスバディであったりとか
そのコミュニティ自体に
そういうメンター制度みたいなものがある方がいいのかなって思ったりしましたね。
そういう役割なんですよっていう風に言われていると
その役割がその人を作るっていうところもあったりするんで
あらかじめそういう制度を中に作ってしまうというのは
一つの手かなと思ったりしますね。
ということで
今日のメインテーマの方に入っていこうかなと思います。
今日のメインテーマは
集中モードの作り方ですね。
ではまずお一人目ですね。
ジェブレルネームジャーニーマンさんですね。いつもありがとうございます。
自宅警備員なので常に雑音ありですと。
まだ業務では取りまとめる立場なのでビジネスチャットのメンションも
また業務では取りまとめる立場なのでビジネスチャットのメンションも多いです。
集中したくてもできないケースが少なくないので
スイッチングコストは多少かかっても
細切れで進めて期日内に終わらせるスタイルに落ち着きました。
集中してできるときは幸運だと思っています。
皆さんのお便りも楽しみですということですね。
そうですね。
自宅警備員だから集中できないというわけではないと思うんですけれども
結構コロナ禍の最初の頃よく聞いた話ですよね。
リビングで仕事する人も中にはいたりとか
さらにお子さんが小さい環境の中で仕事しなきゃいけないとかですね。
本当そういうのはよく聞かれたなと思うんですけど
細切れで進めるのはすごい難しいと思うんですよね、個人的に。
なんでしょうね。
電車の乗り換えとかで、私結構電車の中で仕事すると集中できるタイプなんですけど
あればネットワークあんま使わないので
そのスイッチングコストがかなりでかい気がするんですよね。
この間も人と食事に行くために移動中、電車で仕事してたんですけど
思いっきり降り過ごして
隣の駅に行ったときに気づいたんでよかったんですけど
このまま行ってたらもっと先行ってたなって思うんですよね。
集中すると電車の場合、本当に降り過ごすことが多いので危険だなって思いつつ
ネットワークがあんまない環境っていうのは
集中しやすいんだなってつくづく思うんですよね。
細切れでスマホのゲームとかは隙間時間でできるみたいなのはありますし
あとはクロードコードみたいにGitHub Actionsでコミングとかできるようになっていると
最悪電車で立ちながらとかホームで電車待ってるときに
仕様を書いて送信してクラウドで作業させておくみたいな
そういったことはできるかもしれないですね。
今パッと思い出したのはDevRel会議の何日目か忘れちゃったな
ワシムさんが話してくれたN8nっていうオープンソースのノーコードツールがあって
いわゆるノードを組み合わせてデータを収集したりとか
データをカスタマイズして最終的にアウトプットするみたいなツールがあるんですけど
あれとかを使うと細切りであったとしてもどこまで進んだかっていうタスクが管理できるので
進めやすいかもしれないですね
本当にぶつ切りでいきなりここから始めてくれって言われると
私はなかなか集中するの難しい人種な気がしますね
では続いてですね
DevRelネーム西から来た馬面の男さんですね
今週のテーマは集中モードの作り方ですと
集中するときしたいとき前に何をやっているか
単純作業のタスクを朝一でやってから仕事に入ります
例えば朝食器の片付け洗面所の拭き掃除布団を畳むなど
簡単で達成感あるタスクをしてから仕事に入ります
あとは頭の中にいっぱいタスクがあったときは
一旦紙のノートに書き出してそれを眺めてから作業に入ります
途中であれこれ考えたり思ったりすると気が散るので
先に全部を書き出すことが大事と思っています
紹介したのは私の朝のモーニングルーティーンですと
以上ですといただきました
これは言われてみれば私も
集中したいときではないんですけど
頭の中にいろんなあれもやらなきゃこれもやらなきゃみたいな
のが溜まっているときには
一旦全部書き出すっていう
私の場合は紙ではなくトゥードゥイストっていうサービスに
とりあえず全部タスクにして書き出すっていうのはやってますね
頭の中に余計なものはない方がいいと思うんですよね
そうしないと作業しているときに
これもやらなきゃみたいな感じでそっち側始めると
手元の作業がずっと止まっちゃったままになったりとか
さらにメールが来ましたとか
メンションが来ましたみたいな感じで
作業がどんどん分散というか気が散っちゃう方向に行くと
良くない傾向があるので
それを一旦全部タスクにしてまとめると
優先順位も見えてくるし
あと今日これを全部やらなきゃいけないんだっていう覚悟は決まるので
だいぶ作業をする気になるっていうのは確かにありますね
これが集中モードを作ってるのかどうかって言われるとちょっとわかんないですけど
とりあえず頭の中のモヤッと全部書き出すっていうのは
大事なところかなとは思いますね
最近あんまやってないなぁ
どういう時にやってるんだろうなぁ
追い込まれるとやるんですよね
追い込まれると
自分の頭が今ちょっとパニックになってるかもみたいな感じになって
これはこう一旦全部書き出そうみたいな気になってくるんですよね
ただそれは割とめちゃくちゃ忙しい状態かって言われると
そうでもないんですよ
人によると思うんですけど私の場合は
とりあえず細々したものも含めてタスクがとにかくいっぱいあるみたいな状態になると書き出すっていう感じですね
なのでタスクガーって書き出しながら
普通にジム行って運動して帰ってきてからやるみたいなこともやってたりするんで
時間に追い詰められてるっていうよりは
とにかく頭の中がタスクでいっぱいになったって感じたら書き出しておくみたいな感じですかね
あとは単純作業のタスクを朝一でやると
これもよく聞くところではありますよね
いきなりでっかい階段を越えようとしても難しいので
ちっちゃい階段を順番にステップを踏んでいくと
いつもより大きいステップも踏めるようになっていくっていう
そういうやり方に近いのかなっていう
小さい達成感を積み上げていくと
大きい達成感も得やすくなるというやつだと思いますね
この中で食器の片付けとか洗面所の拭き掃除とか
簡単で達成感あるタスクをやるということですね
これも確かに有効そうな気がしますね
小さい達成感を積み重ねていくと
たぶんそのうち集中モードが作れていくんでしょうね
イベント参加におけるコミュニティの価値
そこで下地を作るというか
ステップを上がっていくっていう感じなのかな
そうですね
私もここの西から来た馬面の男さんが
やられているようなことはやっている気がするんですが
それが集中するためにやってたのかって言われると
確かにそういうふうに言われてみればそうかもみたいな感じですね
割とこの方法自体はすごくおすすめで
あとはあれですね
夜というか最後仕事を中途半端に終わらせるっていうのも手ですよね
昔やってたのが
会社を出る前に机の上を全部片付けるっていうのをやってたんですね
その仕事が全部終わったら
一通り霧のいいとこまで終わったら
机の上を全部朝の状態に戻して帰るみたいな
でもそれはあんまり良くないらしいんですよ
それをやると区切りが完全についてしまって
次の日の仕事が始めづらくなるらしいんですね
なのでむしろ一日の仕事の最後を残しておくと
集中モードの探求
次の日会社に来たりとかこれから仕事しようっていうふうになったら
そこの終わりかけのものから始めると
当然終わりかけなんですぐ終わって
じゃあ次の仕事っていう感じに区切りをつけないっていうのが
仕事のやり方として上がってたことがあって
ああそうなんだと思って
それから帰る前に片付けるっていうのをやめたんですけど
良かったのか悪かったのかはちょっとわからないですけど
そういう仕事のやり方を途中で切り替えた覚えはありますね
何だろうな仕事するときに注意していること
個人的には一つの場所だとあんま集中できないんですよね
集中力がすごく短いというか持たないんですよね
なので今はラジオをやるときは
自分のオフィスの仕事部屋の中の座ってやるっていうのが基本なんですけど
それこそこのスペース自体は昇降デスクになってるんで
立ってシットしたりとか後 後ろに人をダメにするクッションがあるんで
そこで寝転がって仕事するとかソファに行くとか
ハンモックで仕事するとかカフェに行くとか電車に乗るとか
とにかく状況を変えてないとダメなんですよね
そうしたら場合によってはカラオケとかそういう場所に行った方がいい場合もあるかもしれないなって思ったんですけど
多分カラオケに行ったら遊んじゃうんでダメでしょうね
漫画喫茶もダメでしょうね
あと何だったかな
コワーキングスペースとかも
時々行ってドロップインでできるところとかは
そういう場所を変えるっていう目的だけで使ってたりしますね
会社とかでずっと机に向かって作業し続けられる人って本当すごいなって思うんですよね
昔からできてなかったような気がしますね
超昔はずっとラップトップを使ってたせいかもしれないですね
デスクトップって全然個人的には使ってなくてずっとノートパソコンばっかりだったんで
どこにも持ち歩いて会議室にこもったりとか
一人でもくもく作業できるスペースとかで仕事するのが
当たり前というかそういう部分を作ってきたので
少なくともどこの会社にいた時も大体3カ所ぐらい仕事する場所がありましたね
それこそ前職の時とか倉庫の中で作業したりとかしてましたね
倉庫だと割といいんですよ
トラックが来る音とか作業の台車のちょっとでかいやつとかのゴトゴトゴトっていう音とかが
ホワイトノイズみたいになって作業しやすかった覚えがありますね
あと会議室とか行ったりとか
その会社の時だったかな
ソファーのある部屋とか行ったりとかして
その場所を変えると気分も多少変わって仕事ができてたような気がしますね
それも集中モードの作り方といえば作り方な気がしますかね
デブレルのブランディング
というところで今日はお二人のご意見を取り上げましたというところで
最後イベント
イベントではないんですけど
さっきこのデブレルラジオとか
デブレル東京っていうコミュニティ自体は
一般社団法人デブレルっていう法人があって
そこで運営してるんですね
そこのメンバーとかにはちょっと話してたんですけど
デブレルっていうもの自体の取り組み方を
分かりやすく言うとデブレルのブランディングを
ちょっと考えた方がいいんじゃないかなという提案をしてたんですね
私も全然まだそのモヤっとしていて分かってないんですけど
この間今はデータドックにいるデブレルを統括しているブランドンっていう人がいてですね
その人昔10年ぐらい前にセンドグリッドにいて
その時にデブレル3Cっていうのを提唱したんですよ
センドグリッドコンテンツコミュニティのデブレルの3要素みたいな感じですね
の話をしてそれが10年経ってもいまだに変わってないんですよ
それってもう本当に根幹に関わるところで
そこからアップデートされてないんですよね
そのデブレルに関する話とかもやっぱそこから出てくるものが基本で
特にそこから大幅に変わった何かが
AIとかが多少絡んだとしてもそれは技術要素の話であって
やっぱその3Cの部分っていうのはあんま変わってないんじゃないかなっていうところがあり
そうするとそのデブレル会議にしてもデブレル東京としてやるイベントにしても
コンテンツがそこからすごい飛び抜けたものが出てこない感じはするんですよね
デブレルに長く関わっている方からすればそうだよねっていう話になりがちですし
逆にあんまり細かい話になるとデブレルに関わってない
これから関わっていこうっていう方からするとですね
ちょっと何のこっちゃみたいな 具体性が見えてこない部分があるのかなというところで
その一般社団法人デブレルとしてはですね
デブレルに関わる方々を増やしていきたいというところがあるので
あとは啓蒙ですね デブレル自体の啓蒙っていうところが
やっていかなきゃいけないところになるんで
その我々のデブレルっていうものを届けたい対象っていうのはですね
ちょっと違うかもしれないというところですね
イベントのテーマとかと合わせたときに
もしかしたらちょっとテクニックに寄りすぎていたりとか
内場感が出てしまう感じになってんのかなっていうのをですね
もやっと感じてるんですよね
なのでそのイベントのテーマとかを
もうちょっとより広くデブレルに興味を持ってもらえるようなものにして
いかなきゃいけないのかなっていうですね
思っているところですと
このあたりですね 何かご意見があれば
ぜひスラックとかで教えてもらえるとですね
嬉しいなと思っております
スラックに参加する場合は
devre.tokyoというサイトの方から
ジョインできますんで
ぜひ入っていただければと思っております
最後そんな取り止めのない話になってしまったんですけれども
本日のデブレルラジオ238回目ですね
集中モードの作り方はこちらで終了していこうかなと思います
もう10月の後半ですね
ってことは今年はあと2ヶ月か
2ヶ月と2週間
早いですね
いやー早い
そうですね もうあとつまり
火曜日が10回
今日入れたら11回しかないんですね
早いですね 怖いですね
皆さんくれぐれも風邪とかですね
そういった体調不良になることなく
残り約10週ですね
いつぐらいでみんな冬休みになるんですかね
26が今年最後ってことなんですかね
26日が金曜日なので
そうすると12月の30日の火曜日は
あんまりやらなくてもいいかもしれないですね
だとするとデブレルラジオはあと4回4回か
あと今年は9回かもしれないですね
来週は10月の28日になっております
皆さんお仕事引き続き頑張ってくださいというところで
今週のラジオはこちらで終了していこうと思います
また皆さん来週お会いしましょう
さよなら
