DevRelの紹介と信頼のテーマ
はい、みなさんお疲れ様です。
10月の28日ですね。夕方5時半になりました。
DevRel Radioの今日は238回目ですね。やっていきたいと思います。
また今日もですね、この後用事があるんで、外のリモートで働けるところでやってるんですけれども、
音声とかが聞こえづらくなければいいなというところですね。
ではですね、まず最初、DevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間程度、大抵ライブでやっているというものになります。
DevRelっていうのは、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に
良好な関係性を築くためのマーケティング処方となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えば、Developer Advocateとか、Community Managerとか、
Technology Evangelistとか、Marketerとかですね、
そういった方々が集まって情報交換したりとか、イベントをやっているといった
そんなコミュニティになっております。
DevRel Tokyoの公式のXアカウントがありまして、
アットデブレル東京というアカウントになります。
あとは、そこからですね、スラッグに参加できますので、
DevRelに関わっているとかですね、興味があるという方は是非、
ジョインいただければと思います。
あとは公式の、今なんかおかしかったな、公式サイトですね。
公式サイトがDevRel.Tokyoですね。
あとは公式のXアカウントが、アットデブレル東京で、
普段はSharpDevRelJPというハッシュタグでポストしてますので、
是非そちらですね、ウォッチいただければと思います。
あとは今日もですね、この配信YouTubeとかでやってますので、
是非チャンネル登録いただいたりとか、動画に高評価いただけると嬉しいですというところで、
早速やっていくんですけれども、
ジャニーマさんありがとうございます。早速コメント来てますね。
配信音声問題ありませんということですね。ありがとうございます。
今ですね、この配信やってるのはストリームヤードというサービスなんですけど、
結構いろいろほぼ毎週のように新しい機能が追加されていてですね、
今このラジオでやってるんで、ポッドキャストで見ている場合は全然関係ないんですけど、
この右下のところにですね、コメントオンザステージという機能があって、
それを有効にするとですね、右下のところにコメントが自然、
もうこっち側で操作することなくですね、多分出せる機能ができてますね。
これ昔からあったんですけど、今日ちょっと初めて今オンにしてみましたというところですね。
結構ね、いろんな機能が追加されすぎていて、終えてないっていうくらいなんですけど、
あとはノートっていう機能だったりとか、謎のピープルっていう機能だったりとか、
結構ストリームヤードをいろいろパワーアップしつつありますね。
ビジネスリテラシーの重要性
今日なんですけれども、今日のメインテーマは信頼ってなんだというところでですね、
結構深いテーマになっています。
DevRelラジオなんでね、DevRelに関連したような話題を今後は積極的に取り上げていこうかなというところがありまして、
DevRel、Developer Relationsって外部の開発者と自社とか自社製品との間に良好な関係性を築くっていうところがあるというところなんですけど、
その良好な関係性ってじゃあ突き詰めて言うと何だろうっていうところで、
信頼関係っていうところだと思うんですよね。
ただ、じゃあ私がどこどこの製品を信頼していますとか、
そこに対してテクノロジーエヴァンジリストとかDeveloper Advocateみたいな人がいて、
その人を通じて信頼関係を築くみたいなときの、その信頼ってそもそも何やねん。
何をもって信頼と言えるのかっていうところですね。
そこをちょっと考えていきたいなというところで、今回のテーマはですね、
信頼ってなんだというテーマにしております。
ちょっとね、深いのか浅いのかちょっとわからないですけれども、なかなか答えづらいところがあるかなと思うんですけれども、
そんなテーマですね、お送りしていくので、
それはまだ30分以上してからやっていきますので、
ぜひですね、ご自身の意見があるという方はですね、
そちら、今のうちにコメントいただければと思っておりますと。
人の信頼を勝ち取る、誰かを信頼するみたいなものって、
はっきりとは言えないですよね。
この後でちょっと取り上げていこうかなと思うんですけど、
そのKPIの話であったりとか、ROIの話であったりとかっていうところが、
ここ最近特にですね、デブレル周りでよく言われるようになってるんですけど、
我々の活動が開発者との間に信頼関係を築いてます、みたいなことを言ったときに、
じゃあその信頼って何なのよ、どうやって可視化できるものなの、
ところがよく突っ込まれがちなんですよね。
それに対して、きんとした説明ができないと、何でもいいと思うんですけど、
可視化された何かの指標みたいなものがないと、
その活動ってそもそも意味があったんだっけっていうのをですね、
必ず突っ込まれるんですよね。
なので、そのレポートラインの人、上司であったりとかA人であったりとかっていう人たちと、
デブレルの人との間にですね、共通の認識が握れていれば、
特にそれは問題ないかなと思っているんですけど、
じゃあ信頼を構築してるんですって言ったときに、
その信頼を具体的に測る指標を作って、
それが伸びているとか、それが良くなっているっていうのをきちんと測定していかなきゃいけない。
さらに突っ込まれると、さらにその信頼がどうビジネスにつながってるんですかっていうのを、
きちんと説明できる必要があるかなというふうに思います。
というところで、結果が求められているというところかな、というところもあってですね、
まず最初、こちらはDev.toの話なんですけれども、
タイトルが、Why Business Literacy Matters for DevRel and Why You Can't Skip This Stepというところで、
なんでDevRelの人たち、DevRelのチームの人たちにビジネスリテラシーが必要なのかという話ですね。
これはマティさん、イリノイ州のアメリカの方のブログ記事になりますと。
簡単にですね、概要を述べていくとですね、
よくあるのがAAGの人たちとか上司の人たちがDevRelを理解してくれないという問題ってずっとあると思うんですよ。
何でしょうね、私も多分何年か前とかにはよくプレゼンとかで、
上司がDevRelを理解してくれない問題をたびたび話していたかなと思うんですけれども、
この中でですね、マティさんが言っているのは逆であると。
ビジネスがDevRelを理解してくれないんじゃなくて、DevRelがビジネスを理解してないんだというのが本質的な課題なんじゃないかというふうに
言っているんですね。
DevRelとしてはですね、開発者を支援したいという思いがあるのはそこはそこで尊いんですけれども、
それだけではですね、組織内での立場を守ることができないと言ってるんですね。
これって本当に本質的なところかなと思っていて、
そういったところですね、DevRelがビジネス側を何が求められているのか、
どういう貢献をしなきゃいけないのかっていうのが分かっていないところが多くてですね、
レイオフされましたとか、予算カットされましたとか、さらにDevRelチーム解散しました、
そういったところが発生してしまっているんじゃないかというふうに書いてあります。
まさにこれはその通りかなと思うんですけれども、その要因はですね、
DevRelの価値をビジネスの言葉で伝えられていないことなんじゃないかということですね。
別にDevRelが悪いわけじゃないんです。
ただそのDevRelの価値っていうのをビジネスサイドに対して、
彼らが理解できる言葉で伝えられていないというところがですね、問題だということですね。
そこに対しての解決策っていうのをマティさんが挙げてくれていて、
我々はバイリンガルにならなきゃいけないというふうに書いてあります。
その時の言語ですね、言語が何かというとビジネス語であるということですね。
我々は第二言語としてビジネス語を学ぶ必要があるということですね。
例えば、これは例なんですけど、CFOの人がフランス人だったという時に、
自分が英語しか喋れないから、ご利用してただ英語でかい声で喋ればいいかというと、
そういうわけではなくてですね、ちゃんとそのCFOの方の言語、フランス語であったりとか、
プラスビジネス言語というところを喋らないと、そういった人に理解してもらうのは難しいんじゃないかというところですね。
それは決して、彼らに対して減り下るというわけではなくて、翻訳力を作る、翻訳力を身につけるということですね。
我々が理解しているDevRelの価値というところをビジネス語に翻訳して、
経営層であったりとか、CXOみたいな人たちに対して説明していく必要があるというところが書いてあります。
経営陣との関係性
それを翻ってみるとですね、DevRelと他の部署は異なるゲームをしているということですね。
例えば、経営陣とDevRelで見ているものが全然違うという話なんですけれども、
DevRelの人たちはですね、コミュニティが成長したとか、ブログがバズった、イエーイみたいな感じなんですけれども、
それに対して経営陣の人っていうのは、ARRにどう貢献したのかとか、リード単価はどうだったのかとか、
どれだけ商談が生まれたのかとか、そういったところを重視しているということですね。
結局のところ、最終的な決定権、そのDevRelチームの予算をどうするとか、チームを今後どうしていくみたいな決定権っていうのは、
経営陣にしか、経営陣にあるわけですよね。
そのために、ちゃんとビジネス的な価値っていうところをきちんと理解してもらわないと、
当然、レイオフであったりとか、チームの縮小であったりっていうところにつながってしまうということですね。
というところで、会社の目的を正しく理解しましょうというところで、
ただですね、DevRelの価値を証明しろ、価値を証明するっていうだけでは不十分だということも書いてあります。
ROIとかKPIみたいなものだけでは足りないと。
信頼の重要性
VXとOPXの違いとかですね、パネル構造など、ビジネスの基礎知識がなければ数値を生かすこともできないということも書いてあります。
フレームワークですよね。
経営の人たちとかマーケティングの人たちが普通に使っているマーケティングフレームワークに合わせた形で、
我々の活動っていうところを証明していくことによって、これだったら意味があるよねとか、
当然最初からうまくいくわけはないので、うまくいかなかったときをきちんと測定して、
次やったときに改善されているとか、より良い傾向が出ているっていうのを、
ちゃんと証明していかなきゃいけないのかなというところですね。
我々としてはですね、デブレルのままでいいと、
ただビジネス語も話せるデブレルになっていきましょうということが書いてあります。
例えば、営業の人と商談を加速させていく方向について話したりとか、
あとはCFOに予算を説明したりとか、
あとはCMOとパネルの役割を共有したりとか、
そういったところでですね、
よりビジネスサイドに対して適切にアプローチしていく必要があるということですね。
このマティさんの記事が、確か全部で3つのシリーズだったかなと思うんですよね。
どっちだったかな。
多分3つのシリーズで、今後ですね、
次が各部署と各部署が何をしているのかとか、
どうやってデブレルが関わっていくべきなのかみたいな話とかしながらですね、
シリーズ化していくという話なんで、
ご興味があればですね、さっきXにポストを押したので、
そちらの記事を読んでいただければと思います。
かなり学びが多いんじゃないかなというところですね。
デブレルのチームって、基本的にそんなにでっかくはないと思うんですよね。
キャリアパスの選択肢
大抵多くて、グローバルなチームとかでも、
せいぜい10人前後とかだと思うんですけど、
その一番上の人だけがですね、
シネス的なところを理解すればいいかというと、
そうではなくて、それぞれのメンバーの人たちも、
やっぱりマーケティングの知識とかであったりとか、
そういう経営層の方のビジネス語というところも、
ちゃんと理解していかないとですね、
コミュニティだけやってるみたいな感じになったり、
ブログ書いてるだけみたいな感じになっても、
それって意味があったんですかって言われたときに困っちゃう。
例えばブログ記事であればですね、
リンクのところにUTMを仕込んでおいて、
それがどれぐらい流入につながったとか、
ソーシャルでどれぐらい波及したみたいなところも、
きちんと測定しておいた方がいいというところになるかなと思います。
では続いてですね、
Redditは今月はこんな面白い話題は多くはないんですが、
最近ですね、Redditのデブレルは若干盛り上がりを見せていてですね、
私もちょっと積極的に回答するようにしていて、
随分投稿が今増えてきてるんですよね。
1週間で1、2、3、4、5個ぐらい。
この前とかはかなり止まってたんですよね。
それを無理矢理ちょっと発発しようと思って答えるようにして、
今はベイエリアのジョブハンティングに関する話とか、
あとはオープンソースプロジェクトにおけるアドボカシーアーキテクトを探してますとか、
あとはGitHubディスカッションの体験ってどうなんですかみたいなやつがありますね。
私もちょっとGitHubディスカッションあんま使ったことないんですよね。
デブレルファウンデーション、Linuxファウンデーションをやっているデブレルファウンデーションは、
確かGitHubディスカッションを使ってるんですけど、
そうですね、それぐらいかな。
なんかあんま使い勝手いいイメージがないんですよね。
あとはTips for Debrelっていうやつも一個上がってますね。
これはなんだったかな。
フルスタックのソフトウェアエンジニアとして、
これまで7年以上働いてきたという方がいて、
フリーランスでもあって、自分で会社もやっているんだけれども、
この人がエンジニアリングチームが、
私のエンジニアリングチームがマーケティング部門に移管されました。
そんなことあるんですね。
マーケティングチームの下にエンジニアリングチームが入るんですね。
プロダクトとかによるんですかね。
CMOから新たな役職として、
デベロッパーリレーションズの責任者への就任が打診されていますということで、
今までは自分のキャリアはずっと技術開発っていうところで過ごしてきたので、
デブレルに入った方がデブレルに飛び込むべきかどうかみたいなところのアドバイスが欲しいということが書いてあります。
このソフトウェアエンジニアからデブレルに飛び込んだという方のアドバイスが欲しいです。
どんな感じでしたか?楽しいですか?長期的にキャリアパスに影響しましたか?ということですね。
これはね、難しいですね。
セカンドキャリアの話も、今回のデブレル会議の時は、
ドンですね、ドン・グッドマンがキーノートをやってもらったんですけど、
彼はマーケティングマネージャー、フォーマンスっていう会社の金融系テック企業の
マーケティングマネージャーに今はなっている。
その前はGitHubにいたんですけど、GitHub辞めた後ですね、
一時自分の、今も自分の会社あると思いますけど、自分の会社やりつつスマートフォンアプリ作ったりとかして、
今は金融系のフォーマンスっていうところのマーケティングマネージャーになっている人がいたりとか、
あとは私も知っている限りでいくと、
名前忘れちゃったな、名前忘れた、マジで忘れた。
ロンドンの方でスキンヘッドの人がいるんですけど、
ロンドンじゃない、あの人はオランダ人ですね、オランダの人でスキンヘッドの人がいるんですけど、
彼はボックスのプロダクトマネージャーになったのかな、
もともとボックスのデベロッパーアドボケイトかなんかだったんですけど、
そこからプロダクトマネージャーに変わったという人が一人いたりとか、
あとはシニアデベロッパーアドボケイトみたいなのはあるあるっちゃあるあるではあるんですけど、
普通に役職がちょっと上に上がったりとか、
そういうデベロッパーリレーションとのチームのリーダーとか、
管理職になったみたいな、そういう場合もあるかなというところですかね。
あと何があるんだろうなぁ。
なかなかセカンドキャリア、デブレルの後のキャリアというところが見えづらいところがあったりとかして、
そこはね、一個悩みどころではあるんですよね。
ずっとデブレルに関わり続けられるかっていうと、そうでもないと思うんですよ。
ずっと登壇したりとか、いろんなところに旅行行ったりとか、そういうのが好きな方もいますけど、
そういう生活をずっとするべきなのかどうかっていうのは考えなきゃいけないと思っていて、
そういうデブレルの次のキャリアっていうのはどういう道があるのかっていうのは、
割とあんまないんですよね、見た目が。
あとはCTOになったりとか、企業ケースもそれなりですかね。
プロポーザルとセッション採択
AWSの玉川さんとかは企業ですしね。
そうやって外の空気にいろいろ触れて、いろんな現状とか課題感みたいなものが見えてくると、
じゃあこの領域で企業しようかみたいな、そういうところはあったりするのかなと思いますね。
あとはカントリーマネージャーっていうケースもありますかね。
しんどうさんのケースはね、ちょっとあれですね、
同じことができるかって言われるとちょっと難しい部分があるかなと思うんですけど、
なんか新しいプロダクトができると、とりあえずしんどうさんに声をかけて、
一緒にやろうよみたいに言われて、今は完全に手持ち弁当で、
GPUスタックっていうプロダクトを担いでいろんなイベントとかやってますけど、
そのうちうまくいったらカントリーマネージャー的な立場で動いていくのかなって思いますけどね。
そのセカンドキャリア問題はよくある話かなと思うんで、
今このレディットの記事で言うと、自分がこれから飛び込んでいくっていう上で、
そこでずっと過ごせるかどうかはわからないですけれども、
その後の自分のキャリアがいいものになるかどうかっていうのは、
結構今のうちに考えている部分なのかなと思いますね。
結構エンジニアに戻る方もいらっしゃいますね。
やっぱり自分はものづくりが好きだったっていうところで、
かつ自分のキャリアをエンジニアとして築いていって、
ある程度自分の得意な技術領域っていうのができてきて、
そこでいろいろ喋ることもできるようになってきたんで、
DevRelにエヴァンジリストだったりデベロッパーアドボケイトになったりするんですけれども、
そこから現場からちょっと離れてしまうので、
そうすると現場なら知ってるよね的な知識がだんだん薄れていっちゃうんですよね。
よく知識の切り売りとかって言いますけど、
ずっとこう過ごしていくうちに、
自分の喋る言葉っていうのがだんだん古いものになっていってしまって、
最新の現場の課題感に追いつけないところもあったりしますんで、
そういった意味でですね、開発がとても好きだという方にはですね、
向かないとは言わないですけれども、
若干こう戻る傾向もある職業なのかなと思いますね。
そういった意味では兼務とかがね、難しい部分もあるんですけれども、
エンジニアをやりながら必要に応じて登壇をするみたいな感じだと、
ちょっとこう良徳で楽しめる部分もあるのかなと思いますね。
では続いてですね、こちらはロッコリーのブログ、
ハテナブログのロッコリーのブログからですね、
日本武尊さんですね、の記事、
プロポーザルを書くときに心がけ、採択するときに注目すること、
注目していることという記事が出ております。
プロポーザル、CFPとかですね、
プロポーザルってカンファレンスとかでよくやりますけれども、
この日本武尊さんはですね、
コンテンツ委員を担当しているデベロッパーズサミット2026では、
この方がですね、プロポーザルの採択に関わっているので、
この方のですね、観点を見ることによって、
良いプロポーザルが書けるようになるんじゃないかなというところですね。
カンファレンス運営者としてセッション採択時に注目している点というところで、
主語が私になっているかというところですね。
発表と信頼の関係
主語が私ではなく、私の会社となっていた場合、
発表内容が技術の共有ではなく、
会社のアピールになってしまう可能性が高いですということですね。
そして会社のアピールがメインとなってしまうと、
聴講者が持ち帰るものが少なくなってしまいます。
また、主語が私ではないと、
実際の発表でも私がやったことという話し方にならず、
熱のこもった発表にならなかったり、
棒読みのような発表になる傾向がありますということですね。
なので、主語が私の会社となっている場合は、
最初に弾いてしまう可能性が高くなりますということですね。
これはぜひ皆さん注意していただきたいところですね。
続いて、聴講者に対して問題提起ができているかどうかというところも入れています。
そんな言い方をすると、問題提起のないプロポーザルは、
俺の自慢話を聞けと言っているようなものです。
自慢話を聞いてありがたがあるのは、
その発表者のことをよく知っているコアな人だけです。
番人にはなかなか刺さりづらいですということですね。
これも大事な観点ですね。
問題提起が入っているかどうかということですね。
続いて、発表内容を表しているタイトルになっているかどうか。
プロポーザルがたくさんあると、
時間の都合上、どうしても運営は中身を細かく見ることができません。
そのため、まずタイトルで判断しますということですね。
これも大事だと思うんですけどね。
なかなか難しいですよね。
日本のセッションは割と度直球なタイトルの場合が多いんですけど、
海外のプロポーザルは変化球が多いんですよね。
この間のDOMもそうですよね。
DOM何だったっけ?
Developers are not special snowflakesということで、
このスノーフレークス、何のこっちゃって思ったんですよね。
よくよく調べるというか、若干スラングらしいんですよ。
スノーフレークって雪の結晶のことで、
雪が舞い降りてきてですね、
手で受け止めるとすぐ壊れちゃうじゃないですか。
消えちゃうじゃないですか。
なのでスノーフレークスっていうのは、
壊れやすいものだったりとか、
すぐ失われてしまうものみたいな、
そういった意味で使われる単語らしいんですよ。
でも、どうでしょうね。
僕は全然わからなかったんですよ最初ね。
何のこっちゃって。スノーフレークスってなんだよみたいな感じで、
会社名かって感じだったんですけど、
よくよく調べたらそういうふうに書いてあったりとか、
超昔にあったのは、
登壇タイトルの中に主流団っていうのが入っていて、
あれ結局何だったんだろうな。
結局日本語にした時にもよくわかんないから、
主流団にせざるを得なかったんですけど、
本当は多分もしかしたらね、
主流団って意味じゃなかったのかもしれないですね。
なんかこうビッグインパクトみたいな、
そういう思いを乗せた単語だったのかもしれないですけど、
そういう場合もあったりしますね。
日本語だとなかなかそういうのは合わないですよね。
続いてのところが、
具体的な内容が書いてあるかどうかというところですね。
非常にいい問題提起をしていても、
具体的にどのように行ったのかが、
詳しくは発表当日にお伝えします、
などとなっていては、採択することが難しくなります。
よくわからないやつは危険ですね。
私でもこれは確実に落としますね。
具体的なところが見えなかったりとか、
こういうの結構ネームバリューで出す人とかに
ありがちだったりするんですけど、
私は割とこういうのは落とすかなと思いますね。
あとは技術的な学びがありそうかどうかと、
技術カンファレンスを運営する以上、
技術的な要素も当然気にします。
単なるほにゃららやってみたといった発表だと、
ツールや手法の紹介になってしまいます。
また技術的要素がないと、
単なるポエム的な発表になってしまう可能性があります。
そうではなく直面している課題に対して、
技術的にどう乗り越えたかが書いてあると
採択したいと思えるでしょうということですね。
あとはこれは人によるかもしれないですけど、
泥臭さや弱みを見せているかということですね。
ここに書いてありますね。
個人的な好みの範疇かもしれませんが、
泥臭さや弱みを見せているプロポーザルは
好感が持てます。
成功体験だけを書いていると、
聴講者はあのチームだからできたんだよと思ってしまうかもしれません。
再現性というところですかね。
プロポーザルの中で苦労した点や工夫した点を書いていると、
聴講者も追体験がしやすくなり、
より学びが持ちやすくなるのではないでしょうかということですね。
またそのようなプロポーザルは、
自ずと主語が私の会社とならなくなります。
泥臭さや弱みを見せているプロポーザルは、
他の先行委員との話し合いの場に、
私から採択をお勧めしやすい気がしますということですね。
というのを含めた上でですね、
この日本武尊さんが逆に自分がプロポーザルを書くときに、
気をつけているポイントを挙げています。
まずセッション内容の1行目に問題提起を書くということですね。
続いてプロポーザルの内容には、
発表資料下の一歩手前の文章を書くということですね。
そこまで書いたからこそ、ちゃんとドリルダウンしてあるからこそ、
実際の話す内容っていうのも見えてくるというところかもしれないですね。
あとは採択者がわかる単語を用いて書くと、
これは大事ですね。さっきのね、スノーフレークスとか手榴弾とか勘弁してほしいですね。
そしてタイトルにポップでキャッチーなキーワードを入れるということですね。
個人的にはびっくりさせないをキーワードにしたつもりですと。
それもひらがなのびっくりさせないではなくて、
信頼のプレッシャー
カタカナのびっくりでひらがなのさせないですと。
文章の構造として十分になるように心がけている気もします。
そのときのタイトルはシフトライトなテスト活動を適切に行うことで、
無理な開発をせず過剰にテストせず顧客をびっくりさせないプロダクトを作り上げている話というタイトルですね。
あとは自分視点の話を書くというところで、
いろいろプロポーザーの各部で注意したほうがいい点というのがここでまとまっていますので、
これからどうでしょうね。
もう今年の11月、12月、あと2ヶ月か。
あと2ヶ月なんでもうプロポーザーの大抵しまったかなと思うんですけど、
とはいえですね。
1月になれば、2月か。2月はぶり会がありますし、
あと1月か。ごめんなさい。1月だったかな。
1月はぶり会議、2月がデブサミの2026とかあったりするんで、
あとあれですかね、ペチパー会議は確か3月だったかな。
調べたらもう1月から3月期は本当にカンファレンスが少なくて、
気持ちはわかるんですけど、
そういう中でですね、まだプロポーザルを募集しているカンファレンスもあったりするんで、
ぜひですね、先ほど言ったような注意点に気をつけつつですね、
プロポーザル提出してみてはいかがでしょうかというところですね。
ではですね、メインテーマの方に入っていこうかなと思います。
今週のテーマはですね、信頼ってなんだというテーマなんですけれども、
小田翔さんからコメントきてますね。
毎年優勝することかなということですね。
この優勝って言っているのはiPhoneの行列の話かなと思うんですけれども、
信頼なのかな。
小田翔さんだったらまた一番で並んで買ってくれるだろうみたいな、
そういったものは確かに信頼と呼べるかもしれないですね。
なんでしょうね。有言実行に近いのかな。
他は有言ではないけど、小田翔さんの場合は有言かな。
そうですね、期待ですかね。期待に応えてくれる。
こちらの期待値に対して適切に応えてくれるというところが
信頼かもしれないですね。
逆に言うとこれプレッシャーとも言えるかもしれないですね。
そのうち小田翔さんがもうiPhoneいいかなみたいなことを言えないですよね。
言い出したらもうこれは信頼の喪失、小田翔さんのアイデンティティの崩壊とも言えるので、
そういったところを考えると信頼っていうのは広げて言うとプレッシャーということも言えるかもしれないですね。
コメントも来てますね。
毎年プレッシャーエグいですよ、割とマジで。そうだと思いますね。
なんでしょうね。信頼っていうのがいい意味のプレッシャーとも言えるかもしれないですね。
それがあんまり過剰になってくると関わっている本人もちょっとしんどいみたいな感じになる可能性はありそうですね。
そうですね。これはなんかちょっと、私が昔MoonGiftっていうサイトをやっていて
だいたい20年ぐらい毎日ブログ記事を書くみたいなことをやっていて
実際は毎日書いているわけではなくて、週末に書き溜めをして
それを予約配信で月曜日から、毎日ですね。月曜日から日曜日まで記事出してたんですけれども
あれも周り、小田翔さんにほんと近いかもしれないですね。
何のためにやってるんだろうっていうところが出ちゃったんですよね。
別に小田翔さんにiPhoneを毎年買えって誰も言い出したわけじゃないわけですよ。
私の場合もオープンソースのブログ記事を毎日書けっていうふうに誰かが言ったわけじゃないんですよ。
いつの間にか自分でやろうと思ってやり始めて
そこに対して、あのサイトは毎日更新されてるんだ、毎日オープンソースを紹介してるんだみたいな感じの
空気感みたいなことですかね。
それができていくと、更新されているブログっていう信頼を勝ち取ると同時に
逆に中の人にとってみると、それが書かなきゃいけないなる瞬間とか
小田翔さんにしてみたら買わなきゃいけないみたいな瞬間になるとしたら
そこからネガティブな意味でのプレッシャーに変わる可能性はあるかなと思いますね。
あのサイトをいつ辞めたんだったかな。忘れちゃったな。
多分3年ぐらい前に辞めたと思うんですけど、あの辞めるきっかけは何だったかな。
個人の体験
なんかね、私って割と突然フッて思って、やめようみたいな感じになるんですよね。
その時も同じで、緊張の意図は切れたとは言わないですけど
フッて思って、もうダメだ。ダメだじゃないですね。
そんなにネガティブじゃなかったんですけど、もうやめてもいいかなみたいな感じになって
もうその10分後にはいついつ更新やめますって書いてポストしたみたいな感じでしたね。
デブレルコンもね、1回2020がコロナで中止になりましたけど
あの時も大体辞めるって言ったのが1週間ぐらい前で
あの時もね、ずっとモンモンと考えてて
コロナの感染者の方が、当然苦しんでいたと思うんですけど
そういった方々がどんどん増えていくみたいな中で開催できるかどうかみたいな考えて
あの時も突然フッて、やめようと思って
でもスラックの運営メンバーに、もう無理、やめますみたいな感じで報告して
もうね、そしたら気楽なものですよね。決めたらそれをやって終わるみたいな
そういうのがいいのかなと思いますね。はい。
小田翔さんからコメントしてますね。来年も優勝するけどと来てますね。
これもどうなんでしょうね。1回でも優勝できなかったら
もうそこで緊張の糸が切れる可能性はあるのかなと思いますね。
はい。ではですね、いただいているコメントに入っていきたいと思います。
まず最初がデブレルネーム西から来た馬面の男さんですね。いつもありがとうございます。
信頼の本質
今週のテーマは信頼って何だ?です。
デブレルでは開発者の信頼を獲得するのが使命ですが
そもそも信頼って何でしょうか?という問いがありました。
信頼って何でしょうか?約束を守る、期限を守る、時間を守るなど
身の回りで相手に対して守るものってあると思います。
それらを守っていくと次第に信頼されていくものだと思います。
仕事も同じですよね。
デブレルだと、例えば、勉強会での質疑応答に
進捗に答える、会合に参加する、交流するなど
人との交わりの中で信頼を積み上げていく感じですかね。
デブレル会議の基調講演で話をされていた松下さん、マックスさんの発表でも
コミュニティに対してエヴァンジリストとして信頼を積み上げていったエピソードが披露されていました。
また別の人の言葉で、仕事は信頼つむつむゲームだと言われていました。
信頼を積み上げることで次の仕事が舞い込んだり、周りから承認されていくのだと感じます。
信頼の築き方
信頼はよく言葉にしますが、文字にしてみるとなかなか味わい深いですねということでありがとうございました。
今日は以上ですと言っております。
そうですね、積み重ねですよね。一長一短で信頼されるものではないので
先ほどの期待っていうところ、ジャニーマンさんの期待っていうところ
こういうふうに動いてほしいとか、安定していつでも使える状態になってほしいとか
そういったユーザーの期待値をちゃんと真摯に応えていく、裏切らないというのが続いていくと
徐々に信頼につながっていくっていうところですかね。
これは見えない、可視化しづらいところですね。
ちょっとアンケートベースぐらいですかね。
信頼してますかって言われた方としては、その時に初めて気づくのかもしれないですね。
確かに信頼していたかもみたいな感じで
そのプロダクトをずっと使い続ける理由みたいなものを
自分の中で発見してもらうっていうところにつながっていくのかなと思いますね。
信頼なんかで裏切られたって思ったりすると
そのプロダクトを選ばなくなるっていう人が徐々に増えていって
そうした時にその信頼関係っていうのが壊れ
だんだんチャンレートが増えたりとか
信頼が壊されていくっていうのにつながっていくのかなと思いますね。
当然サービスを使わなくなる要因って
別に信頼しているとか関係なく
むしろ信頼していても予算の都合だったりとか
別なプロダクトの方が安いとか
同じような結果が得られるとかですね。
あとはビジネス的な理由みたいなものもあったりするんで
必ずしもその信頼しているっていうのは
イコールずっと使い続けるっていうのには
つながらないかなと思うんですけれども
その1個信頼されているプロダクトかどうかっていうところは
選ばれる大きい要因になるかなというところですね。
その意味ではその信頼は選ばれる理由につながるのかもしれないですね。
例えばAWSとかね、この間ちょっと障害はありましたけど
それでもそういう時々障害はありますが
それでも安心安全で動き続けているというところで
パブリッククラウドのシェアが一番でかいっていうのは
そういった理由につながってくるのかなというところですかね。
信頼は一長一短では獲得できないっていうのは
本当にアグリーするところで
じゃあどうやって信頼されるのっていうと
期待に応え続けるとか
約束ごとをちゃんと守り続ける
こういう風なリクエストをしたらこういうレスポンスが来るっていうのを
ずっと続けていく必要があると
コミュニケーション量かもしれないですね。
コミュニケーションがあって初めて信頼につながっていく
何も話したことがない関係性の中で
いきなり信頼するっていうのは難しいと思うんですよね。
相手とのコミュニケーションとかタッチポイントが
常に発生し続けると
徐々に信頼っていうのは獲得できていくのかなと
当然裏切らないとか約束を守るっていうのが
ずっと続いていった結果だと思うんですけど
そういうところかなと。
なので一発ドカンとイベントやって
そこで名刺交換したから
そこで信頼獲得みたいなものではなく
そのタッチポイントを何回続けられたか
それはもし続かないとしたら
もう相手が飽きてしまったりとか
相手がネガティブな思いがあって
表面上は信頼してますよみたいなことも言いつつ
実際はあまりそんなにいいと思ってなかったみたいな
可能性につながってくるのかなと思いますね。
その意味ではタッチポイントのポジティブな反応が
どれぐらい続いているかっていうところは
信頼のバロメーターとして使えるんじゃないかなと
ちょっと今思いましたね。
期待値と信頼
では続いてですね。
デブレルネームジャーニーマンさんですね。
ありがとうございます。
難しいテーマです。
信頼の言葉で浮かんだのが期待値コントロールです。
それ自体は意識はしていますが
言葉の体が受け手を制御できる考え方に感じて
違和感を感じますと。
そういうことですね。
信頼って相手に押し付けるものではないですよね。
相手がどう思うかっていうところかなと思いますね。
ひるがえって信頼とは相手のことを考えるの
積み上げなのかなと思っています。
このテーマはコロナ禍に入ってから行動を変え
試行錯誤を繰り返していて
向き合うと表現して毎年振り返っていますと。
皆さんのお便りも楽しみですということですね。
相手のことを考える。
相手のことを考える。
そうですね。
僕らのその人とかその会社とかそのプロダクトに対して
勝手に抱いてしまっている
勝手な願望みたいなものってあると思うんですよね。
結構YouTubeとかYouTuberとかもそうですけど
何かあった時にこんなことする人だと思いませんでした。
それってあなたの思い込みですよねみたいな場合
多分あるかなと思っていて
自分の中の相手に対する期待値を勝手に押し付けてしまって
相手が自分の期待した行動をしなかった時に
それを裏切られた。
信頼してたのにみたいに感じてしまう場合もあるかなと思っていて
その相手の立場に立って考えるっていうのも
必要かなと思うんですけれども
我々としては自分ありきかなと思うんですよね。
自分以上のものを相手に見せることっていうのは
なかなか難しいので
自分ができることを自分の等身大で見せていくっていうところですかね。
調子によるとちょっと自分を大きく見せてしまったりとか
あれもできるこれもできますみたいな感じで
安受けしてしまってですね。
その結果として大心配するみたいな。
仕事もそうですよね。
よくある話かなと思うんですけど
そういったものを作らないためには
自分のできる精一杯っていうのをきちんと結果として見せ続ける
一回こっきりではなく
ちゃんと継続的に続けていくことによって
信頼を獲得していくっていうのは大事なところなのかなと思いますね。
そうですね。
割と相手に対して勝手に期待していると
それが裏切られた時に裏切られたっていうか
自分の思っていなかった方向に進んだ時に
イラッとすることってあるかなと思うんですけど
ことを自分で言うと
あまり人に期待はしないようにはしてるんですよね。
あまり期待してしまったがために
相手がその成果を出せなかった時に
多分ストレスになったりすると思うんですよ。
なのでそもそもあまり期待しない。
最悪自分が巻き取ればどうにかなるというところしか
依頼はしないようにしてるんですよね。
そうすると期待したがために何かあった時に
大変なことになると結構つらいので
そもそも期待しないことで
このジャニーマンさんの方も書いてありましたね。
信頼の言葉で浮かんだのが期待値コントロールって書いてあるんですけれども
逆に依頼する側としては
期待値をめっちゃ下げてますね。
過度な期待をかけてしまうと
そうやって期待したがために
その人が奮起してくれる可能性もあるんですけど
それは結構稀なのかなと思ったりしますね。
カンファレンスとかで私はあんまり当日動かない人間なんですけど
それは人と対面していると
対面してずっと同じ空間に居続けると
人って結構これもやらなきゃとか
ここができてないみたいな感じで動く場合があると思ってるんですよ。
完全にタスクを投げてしまって
自分の目から離れるとか
周りの目がなくなると
その作業は滞ってしまったりとか
あの件ってどうなってるって聞いたら
実は全く進んでないみたいなことになりかねないと思うんですよね。
なんとなくですけど
そうじゃない人も当然いると思うんですけど
私の場合は割とそういうことが多かったなっていう気がしていて
信頼の構築と業務の進行
なので誰かに仕事を振るじゃないですか。
期限が明日までですみたいな場合には
とりあえずその前日とかその前々日ぐらいにステータスを確認して
ここからその2日後とか明日までに
タスクができそうな進捗であれば
そのままやってもらいますし
もうダメそうだなと思ったら巻き取ると
それをギリギリになって
その締め切りになって確認して
全然できてませんでしたみたいなこと言われると
もう私も全然巻き取れなくなっちゃうので
私は巻き取って作業すれば間に合う
ギリギリまで依頼する
いう感じの仕事の仕方をよくしてますね。
あんまり良いとは思わないんですけどね
もっと人を信頼しなきゃいけないのかなと思うんですけど
これは逆にあれですね
私は人の信頼を勝ち取りたいって思ってはいるんですけど
逆に人を信頼していない部分は結構あるのかなと思ったりしますね
皆さんいかがですかね
人を信頼してバンバン仕事を任せるタイプもいますし
そういう人の方が割と会社の中では修正しやすいのかなという気がするんですけど
あれがなかなか難しいんですよね
教育が下手くそなんでしょうねきっとね自分がね
人に任せてその人を成長させるみたいなところの
いわゆる教育のフェーズとかがあんまり好きじゃなくて
学ぶんだったら自分で勝手に学んでほしいなって思ったりしちゃうんですよね
完全にゼロベースで大学から新卒ですみたいな場合には
人を学習みたいなところはちゃんとレクチャーできるんですけど
途中からある程度知識を得てから仕事をするっていう時になると
あんまりうまく仕事を投げていってないような気がしますね
逆にAIコーディングとかめっちゃ楽でいいんですけどね
タスクをちゃんと割り当ててそれをタスクを投げてその結果を受け取ってみたいな
ああいうコンピューター相手だとすごくスムーズに進むんですけど
人間相手だとなかなか難しいですね
ということで今日のテーマはですね
信頼って何だでお送りしましたというところで
カンファレンスの季節
今日は10月の28ですね 最初にお伝えしたところなんですけれども
もう来週が11月に入りますというところで
11月も割と技術系のカンファレンス多いですね
何だったら12月もちょろちょろっとあるみたいな感じですよね
10月も多かったし9月も多かったですけど
9月10月11月はカンファレンスのシーズンですね
たぶんカンファレンス運営の方がですね
いろいろこう準備で大変な時期かなと思うんですけれども
くれぐれもですね体に気をつけて取り組んでいただければと思っております
私はあれですね 明後日かな
明後日はAI駆動開発のカンファレンスで2日間ブースに立つというところで
木曜日はセッションもあるんですけど
オフラインで参加される方はですね
ぜひ私がいるブースによっていただければと思います
コメント1件来てますね ジュンさんから
12月は東京にちょっと行きますということですね
お待ちします もし時間があれば飯でも食えればと思います
ということでですね
今日のDevRelラジオ238回目 信頼ってなんだ
はこちらで終了としていきます
ではまた皆さん来週お会いしましょう さよなら
