00:02
はい、夕方5時半になりました。皆さんお疲れ様です。DevRel Radioのですね、今日は69回目ですね、やっていきたいと思います。
まず、最初にDevRelの紹介ですね。DevRelはDeveloper Relationsの略で、自社とか自社製品と外部の開発者とですね、より良好な関係性を築くためのマーケティング手法となっております。
そのDevRelに関してですね、知見を共有したりとかコミュニケーションをしていくのがDevRel Meetup in Tokyoというコミュニティになります。
公式サイトがありまして、DevRel.Tokyoというサイトになります。そちらからですね、スラッグにジョインすることもできますので、ぜひDevRelに興味があったらですね、そちらから参加していただければと思います。
あとはですね、Twitterアカウントが、アットマークDevRelTokyoですね。ハッシュタグは、シャープDevRelJPとなっています。
他としては、FacebookもDevRelTokyoですね。
あとは、ニューチャンネルは、最近レビューというTwitterが提供しているメーリングリストサービスですね。そちらを始めているので、そちらはですね、アットマークDevRelJPというアカウントの方に行くとですね、
公読用のリンクがあるので、それを押すとですね、すぐ公読できるはずです。やったことないのでわからないんですけれども。
他は、大丈夫かな。そんなところですかね。
今日はDevRelラジオ69回目で、メインテーマはですね、DevRelに必須のスキルっていうところでやっていくんですけれども、
こちら今日はですね、ちょっと録画配信となっていますので、もう受付は終了してしまっているんですけれども、すでに3件ほどですね、コメントいただいておりますので、こちらは後ほどですね、ご紹介していこうと思います。
はい、というところで、今日はですね、私が海外に来ていてですね、久々の海外、いいですね、なんだろうな、細かいところだと、マスクの使用率がだいたい3割くらいですかね。
今はウインテ、オーストリアですね、そちらの方にいるんですけれども、基本的に外で歩いているときにマスクをしている人はほぼほぼ見ないかなっていうところですね。
03:04
ただ、昨日、地下鉄に乗ろうとしたときにホームに歩いていた巡回員みたいな人がマスクつけてって言っていたので、公共交通機関に乗るときはつけるみたいな、そんなルールがあるのかなと思うんですけれども、結構つけてない人も3件されたっていう感じですね。
あと、美術館に行ったときもつけている人がいたり、つけてない人がいたりして、そこら辺は個人の裁量に任されているのかなっていう感じですね。
あとは、地下鉄に乗ろうとしたときにマスクをしている人はほぼほぼ見ないかなと思うんですけれども、
あとは、海外とかだとあるあるですけど、生水が基本的に飲めなくてですね、日本の場合は水が安全なので飲めるんですけれども、実はオーストリアも飲めるというのがですね、
初日に調べてわかったというか、このエアビーノホストの人に教えてもらったんですけれども、このオーストリアはアルプスの天然水、アルプスの雪どけ水が使われているらしいので、実は天然水っていう、そういう水道事情らしいということですね。
この後、今日はもう異動なので、そのためにちょっと枠が廃止なんですけれども、次の国とかですね、もしかしたら次回のラジオのときには次の次の年になっちゃうかもしれないんですけれども、そのあたりもですね、情報があればお届けしていこうかなと思うので、お楽しみにしていただければと思います。
はい、今日のメインテーマに入る前にですね、最近のデブレルに関係するようなニュースというのを取り上げていきたいんですけれども、もうあれですね、IT系のニュースというと、今週はとにかくAUの障害が凄まじかったみたいですね。
私がAUさんは使っていないので、影響は全然ないんですけれども、2日弱ぐらいですかね、影響あったみたいですよね。
かなり大変だなと思うんですけど、ネットワーク関係でいうと、今この海外に来ているときにですね、普段だったら現地SIMって空港とかでよく売ってるようなやつを買ってですね、それをインストールして、インストールというか付け替えてですね、使ってたんですけど、今回は初めてですね、eSIMを使ってみたんですよね。
06:16
日本からでもですね、ソラコムさんがですね、ソラコムeSIMだったかな、アプリを出していて、それをインストールしてですね、アプリの中で、今回は10GB、30日間ってやつを買って、それをプロビジョニングインストールしたのかな、してないのかな、なんかやって、
で、だいたい現地に着いて、ネットワークを有効にして5分くらいですかね、もうちょっとかかったかな、10分弱ぐらいですかね、そうしたらアンテナが立ち始めてですね、使えるようになるといった感じでしたね。
で、現地に着いたら普段使ってる物理SIMの方のデータ通信はカットしてですね、それさえやればデータ通信はソラコムの方のネットワークを使って、で、SMSとかは普段のやつで受信できるという感じで、結構便利だなと思いますね。
で、それをやらないとですね、こっちの方がフリーナウっていうのと、あとボルトっていうサービスがですね、いわゆるUberみたいなタクシーアプリがあるんですけれども、そういうアプリって大抵最初にSMS認証が必要だったりするんですよね。
で、物理SIMとかに変えてるとですね、それの電話番号に登録しなきゃいけなかったりとかして、もともとアカウントを持ってるUberとかだとすごい不便な思いするんですけれども、物理SIM残しながらeSIMでデュアルSIMの運用にするとそういった問題がないというところでですね、これ結構便利だなと思いましたね。
そんな英雄さんの障害ですね。結構大変だったと聞いてるんですけれども、そんな中で話題になっていたのがですね、むしろポジティブな反応のやつがあってですね、
こちらは、これかな、トギャッターさんですね。
トギャッターさんのエンジニアとしてAUの会見を見ていたら、幹部たちの聡明さに好感度が上がった話。AUを選んでよかった。社長の技術力というタイトルですね。
一番最初のツイートがですね、技術者の端くれとしてKDDIの会見を見ていたが、KDDIに対する好感度がかなり上がった。幹部があらゆる質問を打ち返せているし、何より驚いたのは社長がiOSとAndroidの使用差分に言及した点。
09:10
慌てふためいたり助けを求めたりするシーンがまるでないというふうにツイートされているということですね。
これ比較としてはあれですかね、セブン&アイでしたっけね、セブンペイかなんかでトラブったときに、ちゃんとまともに質問に答えられていないみたいな感じですね。
どちらかというと技術領域であったりとかIT領域のサービスに取り組む上でトップの人たちがそれをきちんと把握していないという状態はやっぱり問題なのかなという気はしますかね。
やっぱり障害はね、なければないに越したことはないんですけれども、やっぱり発生はしてしまうのかなと。
ただそれは起きたときにきちんとこういう姿勢を見せられるのかとか、ちゃんとトップダウンで状況を把握しているのかとかっていうのは大事なことなのかなと思いますよね。
災い転じ低伏となすかもしれないなという気がしますね。
ちなみに原因ってわかったんですかね、まだ調べ中なんですかね、わかってないんですけれども、
同じようなことも発生しないことを祈るというか、某M銀行のように何度も何度もこういう商売をやっていると、本当にユーザーから飽きられてしまうという気がするので、
これを機にサービスがより良くなるといいなと思いますね。
続いての話で、こちらはZENですね。
ZENのDECLさんの記事なんですけれども、庁舎県から見たGitHub Copilotという記事ですね。
GitHub Copilot、いつだった?2週間くらい前ですかね、リリースされて、
自然言語で書くとプログラミングが出来上がるというサービスなんですけれども、結構話題になってますよね。
特にそのコードのライセンスをGitHubがどう考えているのかみたいな感じで話題になっているかなと思うんですけれども、
難しいですよね、オープンソースでそれをあくまでも学習として使っているだけなので、明示的なライセンス違反をしているわけではない気がするんですよね。
12:03
学習に使ったコードのライセンスってどうなるんだろうっていうのが新しい課題感というか、
そこら辺は当然GitHubとかマイクロソフトは考えた上でサービスをリリースしているはずだと思うんですけれども、
ブログとかで書かれていて、コードをコピペして動かすような人もたくさんいらっしゃる中で、
こういうAIが生成するものに対するその著作権のあり方っていうのは、
とても難しい課題というか新しい課題だなっていう気がしますね。
汎用的ですからね、あくまで。
トレーニングで使っただけなんで、誰かのコードを奪っているというわけではないというところではあるんですけれども、
もしかしたらすごいマニアックな条件とかつけたら、
すごいピンポイントで刺さるようなコードが生成されちゃう可能性もあるのかなというふうに思ったりはしますね。
そんなGitHubコーパイロットがある中で、
面白いサービスとして、これだったかな。
こちらはMintifyというサービスですね。
こちらはプログラミングからコメントを生成するっていう、
これはVSコード機能拡張、あとはIntelliJの機能拡張というものですね。
逆なんですよね。
GitHubコーパイロットは日本にある自然言語のコメントを見て、
それに対してコードを生成するっていう感じなんですけれども、
逆にこのMintifyはですね、
コードを見てそれに対するコメントを生成するということなんですよね。
結構きちんと自然文で出ますし、パラメーターの説明も出ますし、
返り値も出るし、作成者に出る感じでですね、
これもなかなか面白いサービスだなと思いますね。
逆にこっちの場合はどうなんでしょうね。
これもね、このMintifyのほう、
コードからコメントを生成するというところは、
パッと見そんな騒ぐ人は出なさそうな気はしますかね。
面白いですよね。
これできちんと内容が読めるんだったら、
15:03
ぶっちゃけコードさえ書けば詳細使用書はいらなくなるみたいな。
そんな世の中にも、
今のところ無料で使えるみたいなので、
もしよければ使ってみてください。
これもね、
Mintifyというサービスになります。
今のところ無料で使えるみたいなので、
もしよければですね、使ってみてください。
続いての話で、
これもこちらはですね、
シーネットさんの記事で、
テレワークより出勤している人のほうがストレスを感じていると。
inJapanの派遣情報を見ると、
おそらくテレワークより出勤している人のほうがストレスを感じていると。
inJapanの派遣情報サイト、inHAKENを使っている
3135人の方に聞いたアンケート結果ということですね。
仕事でストレスを感じる方の、
そもそも仕事をしているとですね、
ストレスを感じるという方が約7割いらっしゃると。
その中でもですね、
出勤のみであったり出勤多めの人は、
71%がストレスを感じると回答していて、
テレワークのみとかテレワーク多めの人については、
58%の方々がストレスを感じているということですね。
ただこのテレワークというか、
テレワークは良し悪しというよりもやっぱり通勤なんですかね。
オフィスに行って働くことはですね、
そんなにネガティブな人ばっかりじゃないのかなという気はするんですよね。
なんだかんだコミュニケーションロスがあったりとか、
雑談が足りないとかですね。
フェイストゥーフェイスでコミュニケーションした方が
早く決まることもあったりとかすると思うので、
一概にですね、オフィスに出勤するしないというのは、
そんな関係はないのかなと。
やっぱり一番大きいのは出勤です。
出勤というか電車に乗ったりとか、
そういうことかなという気はしますね。
ちなみにストレスを感じるポイント、
一番大きいのがお給料が仕事内容、仕事量に見合わないというところですね。
これが36%の方々となっています。
18:04
派遣の場合ってどうなんでしたっけね。
派遣の場合って見合わないと思ったら辞めれないんですかね。
もし辞めれないんだとすると、
スキルの問題だったりとか経験の問題だったりするのかなという気がするので、
そこは自分でも改善しなきゃいけない部分もあるのかなという気はしますね。
ついで上司との関係と、やっぱり人間関係ですよね。
4位にも同僚後輩との関係とか書いてありますし、
人間関係の絡みでストレスを感じるポイントっていうのは多いのかなという気はしますね。
あとは仕事量が多いとか責任が重いとか。
派遣社員の方って責任の範囲ってどういうふうになっているんですかね。
派遣元の会社と派遣会社の方できちんと取り決めがあって、
それに合わせてやるのかなという気がするんですけど、
それが責任が重いっていうのは偽装っぽい感じがプンプンしますね。
そんな感じでですね、派遣社員の方に行ったアンケートですね。
ストレスと解消法についてというところの記事が上がっております。
解消法っていうのがありますね。
解消法はこの記事の中にはないな。ないですね。
もし気になる方がいらっしゃったらですね、
このm派遣のサイトの方で見てみてほしいですね。
そんな記事がありましたと。
続いてですね、こちらはキータの記事からなんですけれども、
内容がですね、40代プログラミング初心者が
Pythonを始めて半年、独学で勉強が続いている理由と読んだ本という記事ですね。
とてもいい記事かなと思いますね。
もともとはですね、
Pythonを使ってちょっとした自動処理をやりたかったみたいな感じみたいですね。
マックブックで開発環境を整えるところから始めたけれど、
まずそこがうまくいかず挫折しそうだった。
21:03
なんとかその壁を乗り越えてPythonの学習が始まったと書いてありますね。
開発環境を整えるところでドロップしちゃう人って結構いると思うんですよね。
なかなか慣れてる人からすればですね、
やっぱりね、
開発環境を整えるというのはね、
一番大事なところが、
一番大事なところが、
一番大事なところが、
一番大事なところが、
一番大事なところが、
現状の差が一番大きいポイントなのかなという気がしますね。
なのでそこを乗り越えられたのは素晴らしいことかなと思いますね。
あとは全国スペースで一日悩む。
これもつらい。これはつらいですね。
そしてあとは、
家族が天気予報をLINEに届いたら便利ということなので、
雨が降る日だけ通知するLINEbotを作った。
好評だったので友達にも紹介したら喜んでくれたというふうに書いてありますね。
こういう自分でやって自分が楽しいというのもいいですけれども、
誰かのためにですね、こう作って喜んでもらえるというのもいいですよね。
そしてあとは、
そんな中でSQLを勉強すると稼げるらしいという噂を聞いたと。
これはどうなんでしょうね。
マーソン聞いたことないんですけれども、どうなんでしょう。
そういうのもあるんですかね。
その後が、Python勉強してるんだ。
じゃあ機械学習できるでしょって言われたときに、
できませんっていうのが悔しいので機械学習も勉強することにしたとありますね。
これいいですね。
おすすめの本としてはすっきりわかる。
Pythonによる機械学習入門という書籍をあげてらっしゃいますね。
次が、この頃気がついた。
Pythonってスクレーピングでデータ集めてDBにアクセスして、
SQLでデータを入れて、そこからデータをきれいにして機械学習させるのか。
だからPythonって便利なのか。
それが شيくない感じだと思います。
コミュニケーションはどっかで話されてるんですけど、
では次。
Please use python Hide Mountain as one of the first ееleo
24:03
it's free
splashing
つながっていって鉄ができるようになるとか 歯車ができるようになるとかですね
ちょっと忘れちゃいましたけど そういうふうにつながっていく感覚って
すごく気持ちいいんじゃないかなと思いますね
そこからは競技プログラミングとか IoTとかあるんですけど
超初心者にオライリーや公式ドキュメントを 進められても困ると
いや これほんとそうですよね オライリー本がね
初心者向けにはちょっと難しいように 見えちゃいますよね 衝撃
分厚いですしね もうちょっとこう シンプルな本のほうがいいかもしれないですね
本を開いてめっちゃ見やすい 簡単そうって思える本が
初心者の独学に対してですね 継続しやすい本と書かれてますね
確かにそうですね あとは初心者は やっぱり紙の本がおすすめと書いてありますね
電子書籍とかだと検索してページを探せるけど ふわっとあれ何だっけ
確かあの辺にあった気がするとか 本に手書きで書き込んだり
付箋をして自分が見やすいように カスタマイズできるっていうところで
紙の本がいいというふうに書いてありますね
そうですね 個人的には最近は電子書籍で買っちゃってますけど
こういう学習コンテンツっていうのは 紙のほうがやりやすいかなっていう気は確かにありますね
あと大事なところとしてはコピペはしないで 全部手打ちをすると これすごく大切ですね
やっぱり手を動かすことによって 脳に記憶が定着するっていうところもありますし
あとここで書いてあるのはコピペして動くと エラーに出会う頻度が減るので
エラーの対処方法が学べなくなってしまうと 書いてありますね
いや本当これは大切かもしれないですね
最初に全格スペースで1日無駄にした みたいなことも書いてあったんで
なかなかね そのために1日無駄にするというのも なかなかつらいなという気はするんですけれども
必要な体験かもしれないですね
カッコなしで出るエラーですね
これもPythonだとカッコは結構少ないので
そういった意味でPythonは お勧めできる部分もあるかなと思いますね
JavaScriptだとナミカッコが 普通のカッコも結構多いので
それをきちんと相対してるかどうかっていう 確認が大変だなっていうのはありますよね
27:06
その意味ではLispとかも かなりカッコが多いので大変かもしれないですね
あとは無料の講義 京大とか東大が公開しているものもあるので
それもいいですよって書いてあって
最終的にはプログラミングの学習はコスパがいいと
本を1冊3000円ぐらいで 1、2ヶ月遊べるというふうに書いてありますね
技術書って3000円から4000円って 一般の本よりは高いけれども
プログラミングスクールとか 月額課金タイプの学習サイトに払うよりは
よっぽど安いし納得感があるというふうに 書いてありますね
とてもいい知見ですね
これはもともとタイトルにもある通り 40代と40越えてからっていうことが書いてありますけれども
プログラミングを学習すること自体はですね 年齢あんま関係ないのかなっていう気もしますよね
この間 何かの記事で40代未経験な人は
そんな人が現場に来られても困るみたいな ことも書いてあったんですけれども
この方についてはですね ちょっと儲かるみたいな話も書いてありましたけれども
多分そうじゃなくて個人でですね
アプリを作ったりプログラミングしてみたい っていうところで始まっているので
とてもいい経験なんじゃないかなという気がしますね
この辺りをシェアしてくれるのは とても嬉しいことですね
こういう方々にデブレルしたいなって思いますね
はい 続いてがですね
2つぐらいあるんですけれども 1つがこれは日経さんの記事で
システムの内製化は修羅場という記事ですね
もう1個がですね これを受けて多分書かれたんですけれども
こちらはハテナブログのノブタンさんの
システム開発の内製化って本当に必要なのだろうか という記事が挙がってますね
これ本当に両面考え方があるのかなという気はするんですけれども
なかなかDXであったりとか内製化していこうみたいな
雰囲気は各社力入れようとしているんですけれども
中途半端に力を入れてもあんまり意味がないと 個人的には思うんですよね
きちんとシステム作ろうと思ったら それなりの体制にしないといけないですし
1人2人入れたところでですね システム開発がすごく進むっていうわけでもなく
30:06
もしかしたらその人の実力遺憾で エクセルマクロがいっぱい出来上がるだけとかですね
もしかしたらちっちゃいツールが たくさん出来上がっただけみたいになってしまう可能性もありますし
逆に大きいものを作ろうと思って その人がすごい出来る人だと
とても自分一人じゃ出来ないし このチーム体制じゃ出来ないから
外部の方々に協力願いましょうみたいになって
蓋開けで見たら実は今まであんまり変わらなかった みたいなことにもなりかねないかなという気はするんですよね
システムっていう称がちょっと大きすぎる ということは書いてあるんですけれども
なかなかシステムの内製化っていうところが そもそも簡単にはいかないよなっていうのは正直思いますよね
可能性があるとしたら大地さんのいらっしゃる アウトシステムってあったりとか
あと細胞ってあったりとか ああいうローコードとかノーコードって言われるようなものをですね
その辺りを使ってまず地ならしをするというか 自分たちの業務をスムーズに自動化していく
そこで手が空いたらとか そこでそういうツールを使って要件がきちんと出てきたら
もうちょっと大掛かりにしたりとか それぞれのノーコードツールを連携させるとかですね
そういうふうに発展していくほうが いいのかなっていう気はしますよね
あんまりこれ突き詰めていくと エンジニア1人2人ぐらい雇ったら
もう全て万事解決するんじゃないかみたいに 思われちゃうとですね
すごくエンジニアの人にとっては 辛い思いをするんじゃないかなという気がしますね
はい デブレルとしてはですね デブレルをやっている会社さんとしては
こういう内製化支援とかですね 内製化していく中で自分たちのサービスを使って欲しいという
思いはあると思うんですけれども そのサポートの仕方っていうのも結構適切に考えないとですね
ただ相手が辛くなって終わるだけみたいな あとはあんまりこういいことばっかりって言ってるんですね
トップダウンで導入が決まったけど なかなか現場に浸透しないみたいなことも
あったりするのかなという気はしますというところですね
はい なんかちょっと今気になったんですけど この日経さんのコメモっていうところなんですけど
33:01
多分これノートか何かなのかな 独自ドメインのノートみたいですね 日経コメモ
さまざまな分野から厳選した新しい時代のリーダーたちが 社会に思うこと 専門領域の知見などを投稿するサービスです
ノートで投稿されている方へって書いてありますね ノートの独自ドメイン運用でやっているみたいですね
さまざまな分野からって書いてあるんで 記事一覧見てもちょっとバラバラすぎますね
システムの内製化について書いてある時もあれば 家族は減るけど家族だけが人の繋がりじゃないとか
人は忘れる生き物だからいっそ忘れちゃおうぜとか ジャンルがあまりにも多様性ありすぎるメディアみたいになってますね
日経コメモっていうサイトになります
続いてですね こちらは普通ノートの方ですね
進出して分かった日本とアメリカの サースプロダクトニーズの違いという記事なんですけれども
これなかなか面白いですね
数ヶ月間マーケットの調査 商談をしてきて見えてきた
日本とグローバルでサースプロダクトに 求められることの違いを紹介するということなんですけれども
コミュっていう 多分コミュニティを作るサービスだったかな
こんなこと言うとご迷惑かかるんで
顧客コミュニティでカスタマーサクセス っていうふうに書いてありますね
それを多分コミュニティのサポートをする ツールだと思うんですけれども
日本の方がむしろ機能が広いと
コンセプトが広くて 悪く言うと漠然としている
よく言うとイメージで捉えられる感じということですね
マーケットサイズと競合環境が全然違うので 狭さと深さが大事ということですね
サースのマーケットサイズはアメリカだけで日本の10倍 世界で言うと20倍以上ということですね
市場のサイズが10倍だと競合も10倍 レベルも上がると
メジャーリーグは39弾あり それに対して日本は12球なんですけれども
かつ大谷とかトラウトとかに目が行くけど
36:00
メジャーリーグでスタメンナだけでそもそもの平均値が 日本のプロ野球より高いのと一緒というふうに書かれてますね
コミュニティという切り口で捉えると グローバルには30社以上存在し
日本には数社しかいないということですね
毎月新しい競合が出てきて 知名度がないけど
ARRの100億のサースとか普通にある中で それらに勝たないといけないと
とにかく狭くしないといけないというふうに書いてありますね これが面白いですね
USで勝つにはなぜそのプロダクトを選ぶかの 明確なフックが必要ですというふうに書かれていて
逆にそのフックが日本史上に慣れている港を 狭すぎると感じるということですね
うん 確かにね 日本でそのぐらい狭く定義をしてしまうと
あまりにも狭すぎて 日本に十分なビジネスサイズにならないということですね
それに対してUSであったりとかグローバルであれば そのぐらいの狭めであってもですね
10倍ぐらいとかグローバルで見れば 20倍ぐらいの規模があるんで
十分にビジネスとして成り立つと
で そこまでやった後でですね その市場のトップになれたとしたら
今度横に展開するとかっていうことが 考えられるということですね
なので 日本でレブレルをやっていて そのプロダクトを海外に持って
持ったときに ちょっと広すぎて
なんでこれを使わなきゃいけないんだろう みたいなのがぼやけてしまうという可能性があるということですかね
ここにも 日本で単一市場 日地戦略を取ればいいじゃんと思うかもしれませんが
市場が小さすぎて売上が上がらないから資金調達もできず それはそれで苦しいということですね
サースはとにかくインテグレーションが大事ということですね
既に使っているシステムとのインテグレーションが 話題に上がるということですね
なので API公開するだけではなくて インテグレーションできる状態まで持っていくっていうところが
大事になってくるんでしょうね
2020年のデータでいうと 日本企業の1社あたり 平均サース導入数は8.7個
一方でアメリカは80個っていうふうに書いてありますね すごいですね
こんだけサース入れてるからあれなんでしょうね
グローバルなサースとかのサイトに行くと 大抵有名なIT企業のロゴが並んでいたりするんですけれども
39:05
あれは嘘とは言わないですけど ちょっともってんじゃないかなと思ったんですけど
意外と本当に導入している可能性ありそうですね
業務がサースオリエンテッドになっているのも 大きな違いですというふうに書かれてますね
インテグレーションコストが 日本よりもリーズナブルだということですね
これの一番大きい理由としては 日本の場合は外部のSIRに委託することが多いので
お金と時間が結構かかると
さらに日本だとサースとの連携ではなく 自社独自のデータベースとの連携が必要なケースがあり
サース同士の連携に比べると 費用やコースが重くなってしまうと
これはもともと言われているところですよね
パッケージを導入して終わりではなくて それを大抵カスタマイズするっていうところが
日本企業のよくある形で そのカスタマイズ費用が結構高いというところで
本当はパッケージに合わせて自社のワークフローを 変えていく姿勢っていうのが大切だよねみたいなことは
昔からよく言われてますけど このサースオリエンテッドな時代になってくると
よりそれが顕著になってくるのかなっていう気がしますね
エンジニアのベンダー ユーザー所属比率としては
日本の場合はSI側 ベンダー側が72% ユーザー側が28%
一方 アメリカの場合はベンダー側が35% ユーザー側が65%というところで
ほんと逆転してますよね
そういうユーザー側の企業にいる ITエンジニアの人材っていうのは
多分自社開発は そんなもしかしたら インテグレーションの部分だけちょっとやるぐらいで
サースを導入したり検証したりとかしたりとか あとはインテグレーションがどうできるかみたいな
そういう設計をする立場に あるのかもしれないですね
エンジニアとは言いつつ 開発バリバリっていうよりは
上司室とかに近いのかもしれないですね
コミューンでもコミューンAPIとして 汎用的なAPIは提供していますが
それでは不十分です
セールスコースの提供するセールスクラウドという サースの指定カラムにメールアドレスをキーにして
コミュニティのログイン回数データを反映する セールスコース連携用のAPIとかのレベルで
個別具体なものが求められます
これ面白いですね
42:00
本当にここまできちんと連携しないと 導入に至らないということですね
わかる気がしますね
あとは時差の問題ですね
時差の問題として顧客の視点に立つと
自分たちの営業時間の中なのに
最大37%担当者と接触できない時間が存在してしまうと
なのでセルフサービス度合いを高めないと 価値提供が困難になるということですね
セルフサービスをどこまで提供するか
どうやって提供するかというのも
一個課題になってくるかなという気がしますね
サポートとかカスタマーサクセスに関しては
超ハイクラスの給与じゃないと 雇用できないというふうに書いてありますね
なのでアメリカでは 人による顧客支援を前提としたプロダクトよりも
システムに任せた方が企業にメリットがある構造になっているということですね
アメリカの人件費は USの給与テーブルは日本の1.7倍としていますが
それでも日本での採用環境に比べて不利だということですね
これはわからないでもないというところですかね
結構これね面白い内容だなと思うので
自社製品ですね グローバルに展開していきたいという方々ですね
この記事ぜひチェックしてほしいなと思いますね
はい というところでですね
今日のメインテーマの方ですね
今日のメインテーマはデブレルに必須のスキルってというところで取り上げて
皆さんのコメントをですね 取り上げていきたいと思います
まず一つ目ですね
デブレルネームt.kizawaさんですね いつもありがとうございます
コメントはですね デブレルといっても運営の人 盗難の人
いろいろな属性があるかとは思いますが
日頃から情報収集して最新のITトレンドを肌で感じ
自分なりに企画や発表できるスキルが必須だと思います
いわゆるJTCだと
広報の人はITに詳しくなく現場任せだし
エンジニアは外に対して発信することができない
ITを咀嚼し自分なりの言葉で語れる
エヴァンゲリスト的な技術広報は強いんだと思います
というふうにいただいてますね ありがとうございます
そうですね 結構デブレルをですね やるという会社であればですね
45:06
広報の方であっても自社製品のハンズオンぐらいはこなせるとかですね
その中で一番重要のあるプログラミング英語に関しては
自分も学習するとかですね
そのぐらいはこうやってほしいなって思うことは正直ありますね
それをやっていないとですね やっぱりどこか認知がずれ続けるんですよね
結構それが悩みにつながったりする場合もありますし
そういうのも苦手だっていうふうにも
はなから決め込んでですね 諦めてしまっている方々も結構いるので
なかなか説得するのも難しいんですけれども
そうなったらチャレンジしてほしいなっていうふうには思いますかね
では続いてですね デブレルネーム 札幌のじゅんさんですね
知見のお裾分け力が第一だと思います
スキルというよりは性格の特性ですね
知見を抱え込んだ方がエンジニア個人としては学面的に得をするという構造の業界はいくつもあると思いますが
その文化に住まらずにいるためには
ごく自然に人に教えられる性格が備わっていることが いいのではないかと考えます
もちろん企業所属のデブレル職の方は利用されないしたたかさだとか
マネジメント層に活動内容を理解させて 現状を引き出す交渉力などもさらに必要なんだろうと思いますが
そこのところは本職じゃないので よくわかりませんといただいてます ありがとうございます
そうですね この知見のお裾分け力 いわゆるギバーですね
前に紹介したかな ギバー テイカー マッチャーっていう人の3種類の特性があって
一番成功する人はギバーなんですよね 与える人は一番成功するんですけど
一番失敗するというか 一番成功から遠い人もまたギバーだったりすると
ここで札幌のじゅんさんが書かれている 利用されないしたたかさっていうところで
利用されてしまういい人とか都合のいい人みたいな感じで扱われてしまうと
そのギバーも結構大変なんですけれども そうならない工夫をしながらですね
与え続ける人になるっていうのも また大事なことかなと思いますね
ちなみにこのお裾分け力ですね 会社とかでですね
お裾分けができる人とできない人っていうのが いるんですけれども
確かそのギバー テイカー マッチャーの本ですね そちらに書かれていた中で言うと
48:08
常に先んじていくっていうところですね
そんな今自分が持ってる知見なんでも どんどん人に与えていってですね
今自分が抱えている仕事は他の人にどんどんお願いしていって
自分はまた次のステップに進んでいくっていう考え方ですね
それを保ち続けることが大切だっていうふうに 確か書いてありましたね
私もその通りだと思いますね いわゆるあれですね
ハンマーバキデーいうところの レッツ海洋か
レッツ海洋がお前たちのいる場所は 中国はもう4000年前に通り過ぎた場所だ
4000年前は嘘かな 1000年前か100年前か忘れましたけど
通り過ぎた場所だっていうんですよね
だからこそあの人をレッツ海洋はですね
師範として惜しみなく自分の知見を教えてくれると
あれはブロッチ・カツミさんでしたっけね
に教えるというのがあるんじゃないかなと思うんですよね
それをご所を大事にとっておくようだと 自分の価値ってどんどん下がっていくと
特にこのIT業界は日進月歩で進んでいるので 今日役立つ知見だったとしてもですね
1年後にはもう陳腐化している技術って すごいたくさんあると思うので
そんなのをご所を大事に抱えて 誰にも伝えないみたいなことをやっている暇があったらですね
どんどん共有していくほうが いいんじゃないかなと思いますね
なので私自身もですね 自分でどんどん覚えて
新しい知見があったら それをどんどん人に教えていってですね
その代わり教えたことはですね
それを活用してくれる人たちがたくさんいらっしゃるので
自分はどんどん新しいチャレンジをしていく ということがいいのかなと思いますね
ではアンケート こちらが最後ですね
デブレルネーム ジャーニンマンさんからですね いつもありがとうございます
とても興味深いアンケートですね 毎回楽しみです ありがとうございます
とてもとても息の長い活動なので 優先順位第1位は継続力だと思っています
デブレルの中にあるディレーションを支えるスキルだと思います
関係性を作るのは難しく 途切れてしまうのは簡単
いざ途切れると修復するのはとても大変です
ただ01のフェーズはまだ関係性ができておらず 築くのはとても根気が必要だと思います
そのフェーズを乗り越えられずに 止めてしまうケースが多いと思います
51:00
何事にも言えますが 続けたものだけが 関係者との良好な関係を育てていけると考えています
本当ですよね 関係性を築くのは本当に大変なんですよね
関係性 信頼と言い換えてもいいかもしれないですけれども
信頼を築くのは大変なんですが 信頼を壊すのは本当に簡単なんですよね
01も当然すごく大変な部分もあるんですけれども
一度壊した信頼性っていうのは むしろ信頼関係でいうとマイナスから始まるので
さらに厄介というかですね 正直担当者変わった方が話早いみたいな場合もあったりしますよね
なので信頼を壊すのはとても簡単なことなので
それをいかに継続し続けるかっていうのは とても大事なことなのかなっていう気がします
結構人によってもこの辺り捉え方が違くて
例えばゼロからの信頼性で10まで築いて そのまましばらく何もお互いなかったとして
そのまま10を維持してくれている人もいればですね
どんどん接触機会が減ると どんどん信頼性のポイントが減っていく人もいるんですよね
悪く言うとかまってちゃうみたいな感じかもしれないですけれども
定期的に水やりを続けていないと 信頼性が低下するタイプもいますし
逆にそういう影響が何もないタイプもいたりするんで
その辺り 人に合わせてアレンジしていく必要があるというのが
一個問題かなっていう気がしますね
ただ その辺りを嗅覚で分かる場合もありますし
実際 信頼を失いつつある中で ようやくその人が分かるみたいなケースもあったりするので
その辺りはなかなかケースバイケースで 難しいなというふうに思ったりもしますね
ただ 一貫性ですね やっぱり継続していくの大切ですよね
このDevRelで営業したりとか
DevRelを導入したいっていう会社さんに 紹介したりするときもですね
すぐに花が咲くわけではないんですよっていうのは ほんと口すっぱくして言ってるんですよね
そうしないとですね 導入して3ヶ月で思った成果出ないじゃんって
言われてしまうのがほんと悲しいというかですね
いやいや そんなことないっていうふうに 言ってますよねみたいな
当然その3ヶ月の中でもですね できることは当然やってるんですけれども
54:02
それが期待とのギャップというかですね
期待値までいっていないのは うちのやり方が足りなかったりとか
悪かったりする部分もあるかもしれないですけれども
そうならないようにですね そのギャップが生まれないように
あらかじめなるべく何度も何度も 釘は刺してるんですけれども
フッて忘れられちゃうんですよね
そうすると思った成果出ないじゃんみたいになってですね
突然トップダウンで命令が下るみたいなことも あったりするので
正直つらいなと思ったりするんですけれども
継続していけばね
それぞれいろんな会社さんがあって
最適なデブレルのやり方って違うんですよね
うちの方でいろいろアイディアは出せて それぞれ取り組んでいくんですけれども
それが必ずしも100%うまくいくかどうかっていうのは
本当正直ちょっとわからない部分もあるんですよね
なるべく早めに試してその結果を受け取って
それが良いか悪いかっていうのを判断して
ダメだったらやめて別なのやるしっていうのを 繰り返していく中でですね
その会社のとってのサービスのとっての 最適なデブレルっていうのを見出していくんですけれども
なかなかそのジャブの部分ですね
失敗とは言わないですけれども 仮説検証の部分ですね
短くしたいというか100発必中にしたいみたいな
思いもあったりすると思うんですよね
そのほうのギャップがですね なかなか埋め切れない部分は正直あるなというところは
感じたりはしますね
最近なるべくその説明するようにはしているので
徐々にですね 理解してくれてきているのかなと思うんですけれども
なかなか一朝一夕にうまくいかない部分も あるなと思っております
そういった中でですね
何度も言いますけど これからデブレルをやっていくとかですね
今トライしているという会社さんがあればですね
仮説検証しながらエディションとっての 最適なデブレルっていうのを
継続する中で見つけてほしいなと思いますね
他社がやってるからこれうまくいくはずだとかですね
コミュニティ作らなきゃいけないとかですね
そんなことは別にないので
コミュニティ作ってなくてもうまくいく会社さんもあれば
コミュニティがベストマッチする会社さんもあるので
それぞれですね 会社さんによって最適解っていうのは違うんで
ディシャンとってのデブレルを 選んでもらえればと思います
はい というところでですね 最後イベントのご案内です
57:00
まず一つ目はですね 明日ですね
7月の6日水曜日 デブレル Meetup in Tokyo 76回目ですね
分かりやすいドキュメントを学ぼうというテーマでお送りします
今のところ56名の方が登録してくださってますね
リアル参加枠も7人になってますね
大海山のマイクロソフトベースでやりますけれども
たくさんの方が現地でお会いできるということですね 楽しみですね
私は残念ながらオンラインで参加になるんですけれども
皆さんとですね お話できるのを楽しみにしております
はい あともう1個ですね
もう1個はデブレルジャパンカンファレンスですね
こちらのほうも今セッション内容をですね
詰めに詰めている状態です
もう間もなくですね スピーカーの方々のアナウンスもできるかなと思いますので
こちらも追って情報発送をお待ちくださいというところになります
はい ではですね 本日のデブレルラジオが69回目ですね
今日のメインテーマはデブレルに必須のスキルというところでお送りしました
皆さん引き続きお仕事のほうを頑張ってください
ではまた来週お会いしましょう さよなら
