00:00
はい、夕方5時半になりました。みなさんお疲れ様です。DevRel Radioのですね、
125って書いてあるけど、なんか違ったような覚えが、そうですよね、124回目ですね。
今日は、DevRel Radioの124回目をお届けしていきます。
はい、なんか早速コメント来てます。ジャニーマンさんからコメント来てますね。
よろしくお願いしますと来てますね。はい、よろしくお願いします。
DevRel Radioの紹介
はい、まずですね、DevRel Radioの紹介からです。
DevRel Radioはですね、DevRel Meetup in Tokyoでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間ぐらいお届けしているラジオになります。
DevRel Meetupはですね、DevRelに関するミートアップコミュニティなんですけれども、
DevRelっていうのは、デベロッパーリレーションズの略で、
自社とか自社製品と外部の開発者との良好な関係性を築くためのマーケティング手法となっております。
DevRel Meetupはですね、そんなDevRelに関わるエヴァンジェリストアドボケイト、
コミュニティマネージャー、マーケター、あと人事の方とかですかね、
そういった方々が集まって情報共有をするといったコミュニティになっております。
Twitterアカウントじゃないですね、Xアカウントですね。
Xアカウントがありまして、アットマークDevRelTokyoとなっております。
ハッシュタグはいつも、シャープDevRelJPっていうのを使っておりますので、
ぜひそちらも見ていただければと思います。
あとは公式サイトがありますね、DevRel.Tokyoというサイトになります。
そちらからスラップに参加することもできますので、
もしDevRelに興味があったらですね、ぜひご覧いただければと思っております。
はい、ということでですね、今日のメインテーマがですね、
よく使うクラウドサービスとなっております。
クラウド全盛な時代なので、多分これリストアップするとですね、
切り無く上げられるんじゃないかなと思うんですよね。
なので、ぜひですね、これはというものをですね、
一つに限って教えていただきたいと思っております。
はい、だいたい6時10分ぐらい。
いつもなんかこれね、駆け足になってるような気がするんで、
もうちょっと時間の余裕を見てですね、
今日は取り上げていきたいなと思っているので、
ぜひ今のうちにですね、皆さんおすすめのクラウドサービスがあれば、
ぜひコメントいただければと思っております。
Xアカウントの変化
はい、ホッタさんからコメント来てますね。
Xアカウントってもう言わなきゃいけないんですね。
そうですね、多分これをTwitterっていつまで引きずるかどうかが、
老害化するかどうかの、インターネット老人会に入るかどうかのですね、
切れ目だと思っているので、
もう私はXアカウントで通していこうと思いますね。
そんなにね、多分もう戻らないでしょう。
ここまで変えて、会社のシャオ君のところにも、
よくわからないキラキラ光るロゴを立てたりとかしていたりするんで、
もう戻らないと思うんで、
一時期ね、イーロンマスクがTwitter買収した後に、
犬のアイコンに変わったことありましたよね。
芝犬かなんかのね、アイコンに変わったことありましたけど、
あれはね、ジョークですぐ元に戻したという感じで、
今回のXに関しては、続くだろうなと思っているんですけど、
ただ、一部Twitterっていう名残が残り続けてますよね。
今、X.comにアクセスすると、Twitter.comにリダイレクトされますし、
あと、Web版のPWAアプリとしてインストールすると、
まだマニフェストがTwitterって入ってたりとか、
あとまだちょっと探してないんですけど、
Twitterのシェアボタンとかも、
どこでこれURL発行するのか忘れたんですけど、
Twitter.comのシェアかな?
違うな。
そのURL忘れちゃったんですけど、
そこら辺も多分変わってないだろうなとか、
デベロッパー、Twitterとかも、
ここも多分まだ未だに変わってないですね。
Twitter開発者プラットフォーム。
ロゴだけXに変わってるし、
そこから順にTwitter、Twitterって入りまくってますね。
そのうちこれを全部掃除していく作業があるんだろうなと思いますね。
なかなか大変ですね。
また別のコメント来てますね。
祖母が亡くなるまで伝々公社って言ってたみたいに、
私も死ぬまでTwitterって言おうと思っていたんですが、
コーポレートのデブレル的になしですねと。
そうですね。これどうなんでしょうね。
今からTwitterというか、Xを触る人からしたら、
そのうちTwitterって何ですかっていう時代が必ず来ますよね。
伝々公社懐かしいですね。
伝々公社さすがにどのぐらい?
多分30より前の人は知らないですよね。
テレカとかも知らないですよね。
そういう人とかって知ってんのかな。どうなんだろうな。
また道端に電話ボックスはチラチラ見ますけど、
テレカとかね、もう使ってる人いないと思うんで、
伝々公社なんてね、まずまずいないですよね。
小田翔さんから持ってますね。
ソフトバンクを東京デジタル本って呼んでる。
これも確かにね。
私多分東京デジタル本の時使ってたかな。
一番最初多分そうだったような気がするな。
そっから一回ピッチに行って戻ってきた時、
Jフォンに変わってたような気がしますね。
Jフォンもグローバルだとあるんで、
未だにソフトバンクを見るとJフォンを思い出したりするんですけど、
多分東京デジタル本はいないでしょうっていう気もしますね。
はい、そんなところで、
そうですね、皆さんXって呼んでいかなきゃいけないと思うんですけど、
なんかね、言いづらいですよね。
分かりづらいですよね。
普通の、ただのXって一文字だけじゃんみたいな感じがするんでね、
なかなかついていきづらいところはあると思うんですけれども、
その話題が確か一個あったような、
そうそう、アプリストアの名前も変わったんですよね。
なんかもともとAppleの規約的に、
名前が一文字は受け入れられないみたいな感じだったんですけど、
それをなんか無事乗り越えたみたいで、
Xっていうアプリがリリースされてますね。
スレッドと合わせるとね、
アットマークとか、Xとかね、
怪しいアイコンばっかりになってきたなっていう気がしますよね。
はい、自動アップデートかかっているかなと思うんで、
皆さん多分変わっちゃったと思うんですけれども、
だんだん懐かしいTwitterのアイコンはなくなっていくんだろうなっていう気がしますね。
もともとTwitterってアイコン全然違いましたよね。
鳥なのは変わってないんですけど、
なんか全然違う鳥だったような気がするんですよね。
一番最初、立体感のある鳥だったような気がするんですよね。
その次変わった時に、横向きに変わったような気がしてて、
そのうち何回かバージョンアップしていくうちに、
今のやつに落ち着いた感じもするんで、
ロゴもね、だんだん色々変遷はあったんだろうなと思いつつ、
ここで一気にXに飛ぶっていうね、
そんなすごい展開だなと思ったりもしますね。
コットさんからもコメント来てますね。
黒いアイコンが並ぶ不穏な気持ちわかります。
本当ですよね。
一昔前ってソーシャルメディア系って全部青いアイコンで、
それこそ今も結構青系が多いような気はするんですよね。
ただその中に突然黒系のアイコンがどんどん今紛れ込んでるような気がしますね。
ヒザワさんからもコメント来てますね。
こんにちは。久しぶりの参加です。
よろしくお願いします。
エンジニアの勉強
ではですね、まず最初は最近のデブレル周りにですね、
ニュースをお届けしていこうと思うんですけれども、
これ結構定期的に話題になるなと思うんですけど、
クリアッターの記事でエンジニアは勉強し続けないといけないっていう記事が出ております。
これどうでしょうね。
2年に1回、それから毎年ぐらいのペースで定期的に話題に上がるような気がするんですよね。
ここで言うエンジニアっていうのは多分ITエンジニアを指しているところかなと思うんですけれども、
実際どうなんでしょうね。
そんなに勉強してるっていう感じなんですかね。
普通に言う勉強っていうと、
学校とか行って、あとは何らかのスクールみたいなものに行って、
そこで自分の仕事とは関係ない領域で新しい技術を手に入れるみたいな感じがするんですけど、
なんとなくそのITエンジニアの言う勉強って、
仕事の延長というか、必要な知識があれば手に入れるし、
技術の変遷が激しいので、新しい何かトレンドの変化があったらそれに追従するためにその技術を学んだりとか、
全然違う自分とは全然違う分野でも新しいトレンド、
ちょっと昔だったらDockerであったりKubernetesだったりとか、
そういったものとかが来たりとかAIが入ってきたりとかすると、
その技術をキャッチアップするためにトライするというか学ぶ、
勉強っていうとちょっと違うような気がするんですよね。
そうですね、別に絵画教室に行って絵画を勉強するみたいな、
そういうニュアンスとはちょっと違うんじゃないかなと思うんですけれども、
そういった広い範囲での勉強っていうところをどう捉えるかっていう話だと思ってますね。
その意味では学び続けないといけないと思うんですけど、
逆に学ばなくてもいい業界ってそんなあるのかっていう気がするんですよね。
それこそ経理とか会計士とかあと弁護士とかもありますし、
そういう修行に携わる方って法律が改変されたりとか、
新しい、最近だと何でしたっけ、請求書かなんかのインボイスとか、
そういうふうな新しいのが入ってきたらそれに対してきちんとキャッチアップしていかないといけなかったりとか、
修行の人って独自のコミュニティがあって、
そこで最近の法律の改正に伴う勉強会とかやられてたりするんで、
そういうので学ぶと思うんですよね。
勉強って言うとあれですね、新しい情報のキャッチアップは、
エンジニアの学ぶ意欲とキャッチアップ必要性
特に別にITエンジニアに限らず必要なんじゃないかなって思うんですよね。
なので別にエンジニアに限らずそういう学ぶ意欲というか、
新しい情報のキャッチアップをしないといけないっていうのは、
どんな職業でも同じなのかなって思うんですよね。
それこそ経営とかされている方にとっても、
今の現状の延長性をずっとやっていたら、
だんだんダウントレンドになっていたとかある話なんで、
新しい情報を吸い上げて、
どう経営に活かすかみたいなのはずっと検討してたりとかすると思うんで、
そういった意味では別にITエンジニアだけじゃないと思うんですけど、
なんとなくこれ定期的に言われているような気がするんですよね。
なので別に勉強というわけではなくですね、
ある意味他の業種に比べると、
情報の移り変わりが激しい業種だと思うので、
そういった意味で日々キャッチアップしていく必要があるのかなという気はしますね。
ということで、個人的にはエンジニアだけに限らず、
学び続けっていうのは必要なんじゃないかなと思いますね。
APIのトラフィック増加とセキュリティリスク
そしてですね、続いてテックフィードの記事ってことは、
これ多分別な記事のような気もするんですけれども、
APIはインターネットトラフィックの83%を占めると、
APIのセキュリティリスクについて試算が公開という記事が上がっております。
これ極論言うともうあれですよね、
人がインターネット使ってるよりも、
もしかしたらシステム連携で動いているトラフィックの方が多いんじゃないかっていう感じですよね。
確かにわからないでもないですよね。
一つのサービスで全部丸く収まることってもうだんだん少なくなっていて、
それぞれ情報キャッチアップ、機能ピックアップして、
それを組み合わせて作るみたいなのが当たり前のようになっているので、
そういった中でAPIのトラフィックがどんどん増えているというところだと思いますね。
これで言うと、それでも2024年は69%というふうに書いてはありますかね。
API Gatewayを提供するKongによるレポートということですね。
全世界のインターネットトラフィックの83%以上を占めているということですね。
わからないでもないですけれども、
昔はインターネットは猫のために作られてるって言いましたけど、
今はもうAPIのために作られているっていう感じかもしれないですね。
面白い。
どんどんAPIの利用が増えていくと、
さらにこの記事でも言ってるんですけど、
セキュリティの部分だったりとか、
あとはレスポンスの速度であったりとかっていうのが問題になってくるんだろうなという気はしますね。
大抵のDevRelやっている企業はAPI提供していると、
そのAPIを使ってもらいたいというところで情報を発信していたりするんで、
こうやってAPIの利用が伸びていくっていうところは望ましいというかですね、
どんどん促進していきたいというところだと思うんですけど、
特に大事なのはこのセキュリティの部分ですよね。
セキュリティ一歩間違うと、
システム連携している中のセキュリティのリスクって、
なんか別な記事もあった。
どこだっけ。
2ヶ月ぐらい放置していたら、
セキュリティを乗っ取られた。
そう、名古屋のやつだったかな。
名古屋の港のシステムですね。
これ結局解決できたんですかね。
ランサムウェアでシステム暗号化されて、
ミノシロ金要求されたみたいな話がありましたけど、
今はもう復活したのかな。
これの原因が、これは読売新聞オンラインですね。
そちらの記事にあるんですけれども、
システムに使われていたVPNが、
セキュリティリスクがあったということですね。
このOTGateっていうVPN機器なんですけれども、
これに対して脆弱性があったということを、
6月に発表していたということですよね。
当然、ベンダー側としては、
修正プログラムをリリースしていたんですけれども、
それを適用しなかった。
直近で修正プログラムを適用したのは、
今年の4月だったということですね。
これがやられたのが7月ということなんで、
わずか1ヶ月の間でやられたということなんですけれども、
結構そういうクラッキングのやり方も、
ほぼほぼ自動化されていたりするんで、
うちはちっぽけだから狙われないだろうみたいなのって、
ほぼほぼありえないですよね。
ワードプレスとか本当に凄まじいですよね。
ウェブサービス立ち上げてて、
トラフィックのログとか見てると、
別にワードプレス使ってないんですけど、
明らかにWPアドミンとかに対するアクセスとかですね、
どっかのプラグインに対するURLの不正攻撃を狙ったようなやつとかが
バンバン飛んでくるんで、
もうあの辺りって決め打ちで、
ありとあらゆるアドレスに対して発行してて、
その中で攻撃がうまくいったら、
そこからどんどん深く深くいくっていうパターンのやり方なんで、
もうこの自分たちのシステムは、
安全みたいなことってほぼほぼありえないなっていう気がするんですよね。
なのでこれは非常に残念なことではあるんですけれども、
6月に修正プログラムを発表して、
それに対して約1ヶ月くらい放置してしまったことによって、
名古屋の港システムが大打撃を受けるということですね。
皆さんもぜひぜひ注意してください。
ここら辺面白いというか、
AWSとかパブリッククラウドの責任分解点というか、
データセンターの住所非公開
責任の分かれ目を正しく理解していない方々ってやっぱりいて、
AWSにあるから安全ですみたいなことを言ったりする場合もあったりするんですけど、
そんなことはないので、
ぜひ注意していただきたいなって思いますね。
これもちょっと取り上げたいなと思うんですけど、
こちらはアスキーJPさんの記事ですね。
データセンターの所在地ってやっぱり書いてはいけないのかという記事が出ております。
最近データセンターに行くことってないんですけれども、
これどうなんでしょうね。
なんか昔、監修というか本当に何の理由かわかんないんですけど、
データセンターの場所って公開されてなかったですよね。
うちの近所に3つぐらいデータセンターあるんですよね。
1箇所は書いてなかったかな。
多分書いてなくて、
ただGoogleマップに明らかにデータセンターっぽい場所が書いてあって、
そこをクリックすると、
ドコドコ総研のデータセンターっていうふうに名前が出るんですよね。
別の所はテキストでGoogleマップ上に
ドコドコのデータセンターですっていうのが出てて、
もう1個の所は名前は出てなかったんだけど、
データセンターって検索すれば普通に出てくるみたいな感じで出てたんですよね。
確かに私がデータセンター行ってた時って2003年よりも前な気がするんで、
その頃って本当に契約しないと住所を教えませんみたいな感じだったと思うんですよね。
あそこはね、何だったかな、
Exodusみたいなそんなような名前だったような気がするんですけど、
そこ確か買収されて今ソフトバンク系のデータセンターに変わっちゃったような気がするんですけど、
そこがあったのが新宿山頂目の方だったかな、確か。
だから本当契約するまでは新宿の近くですぐらいしか言われなくて、
漁園の方だったかな、新宿漁園の方だったかもしれないですね。
契約したら教えてくれてですね、そこにようやくこのサーバーを搬入できるみたいなそんな感じだったんですけど、
正直別にセキュリティにこだわる場所ってデータセンターに限らないと思うんですよね。
データリスクとか資産っていう観点でいくと、よっぽど原発とかの方が重要だったり、
他のね、ある火力発電所とかも含めですね、そっちの方が重要だったり、
国会議事堂とかの方が重要度があったりとかすると思うんで、
かといって別に国会議事堂なんて場所も公開されてるし、
何だったら社会科見学で中を行く小学生とかいっぱいいるみたいな感じだったりするんで、
なんかね、このデータセンターの住所明かさないのって、明かさないというか書いてないのってなんかね、
うさんくさいような気がするんですよね、なんかこう書かないことがかっこいいみたいな、
そんな観点なんじゃないかなーって思ったりするんですよね。
キザさんからコメントきてますね。会議はしてないけど、
隠蔽…隠蔽…すごい…読み方がわかってない。
隠罪誌って読むんですね。隠罪にあることはアピールしてると。そうそう、そんな感じなんですよね。
新宿にあることはアピールする。そうですよね。
たぶん桜インターネットさんとかは西新宿にあるっていうのは結構昔から言ってたような気がしますし、
何だったらそのデータセンター内でコミュニティのイベントとかもやってたりするんで、
あれも全然隠してなかったような気がするんですよね。北海道のところも全然隠してないですよね。
家族とかもツアーとかやっていたりしますよね。
なので、このデータセンターの住所を隠す文化、ちょっと怪しいなって思ったりしますね。
小田翔さんからコメントきてますね。隠罪には悪しき記憶しかないな。データセンターでひどい目に遭った。
私もそんなデータセンターに対していいイメージ全然ないんですよね。
荷物搬入するのめちゃくちゃ大変だし、テレビとかに中継出るっていうから、
サーバーが落ちたら大変だっていうことでデータセンターまで行って、
夜中中ずっとそのセンターの中にいてめちゃくちゃ喉が枯れるんですよね。
湿度がすごい低くてかつ寒かったりするんで、上着着込んでずっとそこにいたりとかしてですね。
本当に全然ろくな思い出ないんですけど、データセンターね。
逆にクラウド化になって、いかなくはなってますけどたっぷり使ってはいるんで、
そんなこと言ってちゃいけないなと思いますね。
そしてですね、続いてこちらは経済産業省の記事なんですけれども、
ソフトウェア管理に向けたSBOM、ソフトウェアビログマテリアルズの導入に関する
手引きを策定しましたという記事が上がっております。
このSBOMっていうのは私が初見で知らなかったんですけれども、
それぞれの多重構造でシステムを構築していたとして、
それぞれのコンポーネントに対してどういったソフトウェアとかどういったライブラリを使っているのかっていうのをまとめて、
それを発注元に投げることによってそれをだんだんミックスしていって、
最終的なソフトウェアの構成図とかライブラリの利用状況みたいなところを
ドキュメント化するみたいな、そういった仕組みみたいですね。
そのサプライチェーンの部分ですね。
よくサプライチェーンの攻撃を多分去年ぐらいでしたっけね、
ノードJSのNPMとか乗っ取られて、ライブラリ書き換えられて、
サプライチェーンアタックかまされるみたいな、そういったことが話題になっていたと思うんですけれども、
そういったのを防ぐための手段としてですね、
そのSBOMを利用するといいみたいな、そんな話なんですけれども、
結構めんどくさいんですよね、本当に。
一応PDFで手引きがあってですね、
そもそもSBOMとはみたいな話があったりとかしたり、
それのメリットとかですね、いろいろ書いてあるんですけど、
これ結局柔軟性には本当に乏しいような気がするので、
何らか自動化するシステムっていうのが必ず必要になるのかなとは思うんですよね。
それこそ何でしたっけ、あれは何だっけ、
セキュリティ系のDevOpsやっているところ?
どこだっけ、会社名を忘れてしまったな。
犬みたいなアイコン使われているところですね。
あそことかがそのあたりのチェックを自動でやってくれるというサービスなんで、
ああいうものとか、DevSecOpsか、逆ですね。
セキュリティを先に言ってたような気がする。
そのあたりとかを自動的に使って検出したりするようにしないと、
なかなか厳しいんじゃないかなという気がするんですよね。
何でしたっけ、DevSecOps、これ毎回調べるときに
Kiitaのアドベントカレンダーを2022年にスポンサードしてたなと思って、
そこから毎回調べるんですけど、
Kiitaアドベントカレンダー2022、
何だっけこれ、スニークか、スニークですね。
スニークがDevSecOps、多分一番日本、日本というか世界だと有名なのかなという気がするんですけど、
このあたりとか使うのがいいんじゃないかなと思うんですよね。
その意味でSBOMに対応したようなドキュメントとかを
自動的に生成できるようにするのがいいんじゃないかなと思いますね。
この中で上がっているのがログ4Jの脆弱性ですね。
それに関する話が上がっているんですけど、
これも結構有名ですよね。
ログ4Jが脆弱性が絡んだのが2021年の話らしいですね。
このログ4Jを納品物の多重下請け構造がある中で、
どこかで一箇所だけ使っていると不具合につながるというところで、
それをきちんと管理していく必要があるよという話ではありますね。
これシステムが複雑になればなるほど、
もはやどのライブラリをどこで使っているかってわからなくなってくるんで、
どうなんでしょうね。
それこそマイクロサービスとかやっているといいのかもしれないですけどね。
ふなきさんからコメント来てますね。
はい、スニークですね。
SBOMの形式としてはXMLファイルが使われるらしいですね。
そうですね。きちんとさっきのバージョンアップの話もありましたけど、
バージョンアップしてなんぼっていうところもあるんで、
どうなんでしょうね。
責任分解点とかの話はありますけど、
こういうのってさっきのVPNとかクラウドサービスで提供しているところがあれば、
そういうのを使っておけばアップデートはそっちに任せられて、
脆弱性にはつながらなかったのかなと思ったりしますね。
持ちは持ち合いじゃないですけど、
任せるべき部分はどんどん任せておくのはいいんじゃないかなと思ったりしますね。
はい、じゃああと最後、次ぐらいは最後にしておこうかなと思うんですけれども、
どれがいいかな。
これはレバテックさんの記事ですね。
1位はGoの87万円、プログラミング言語別単価ランキング、
2023年7月最新版という記事が出ております。
皆さんどうですかね。何の言語が好きですかね。
私最近ようやくGoをちゃんと学び始めるというか、
Goでライブラリー書き始めてるんですけど、
そのフリーランス、これの記事自体がレバテックフリーランスの記事なので、
おそらくフリーランス向けの、そうですね、
フリーランス向け案件データを元にされているという話なんですけれども、
1位がGoですね。
最高の単価が150万円、平均単価としては87万円ということですね。
他にあるのがSwiftも出てますね。
Swiftは最高単価200万というとこなんですけど、
平均単価としてはGoよりちょっと下がるぐらいということですね。
面白いのは3位がRubyなんですね。
意外だな。Pythonはもうちょっと下になるみたいですね。
順位的にはGo、Swift、Ruby、Kotlin、Python、JavaScript、C++、PHPという感じで、
C++もゲームとゲーム以外でちょっと順位が変わっていて、
さらにその下になるとJava、C、Cシャープ、VB.NET、コボル、VBAといった感じになっているみたいですね。
こんな感じの単価なんですね。
意外とPythonそんな高くないですかね。
それともPythonいろんなとこで使われているから、
それぞれいろんなバリエーションがあって、
ちょっと単価が分かれてしまっているのかもしれないですね。
Pythonの最高単価は多分170から175万ぐらいの案件みたいで、
平均で言うと多分80万ぐらいみたいですね。
結構プログラミング言語によって、
値段が単価が変わるっていうのを踏まえると、
一番最初とか今後5年食っていくためには、
どの言語を採用すべきかっていうのは結構悩ましいんですよね。
こないだラストに関するパネルディスカッションをやって、
とある会社さんは社長だったかCTOだったか忘れましたけど、
確かにCTOだったかなの号令で、
うちはもうラストに絞るからみたいな感じですね。
ラストをもう押すっていうふうに決めて、
社内言語を全部ラストに変えたらですね、
ラストの求人に関してはすごく楽になったっていう話をしていて、
ラストをビジネスで仕事でやっていきたいと思ったら、
その会社さんっていうブランディングができたことによって、
求人は楽になりましたっていう話をしていてですね、
それすごい面白いなと思ったんですよね。
同じことってコンパスとか作っているBプラウドさんもそうで、
Bプラウドさん一番最初Javaだったんですよね。
そのBプラウドの社長の佐藤さんがJavaが好きでですね、
ずっとJavaやってたんですけど、あるときPythonに一気にスイッチしてですね、
それも全然今みたいにPythonが広まる前なんで、
多分ジャンコが出てきたぐらいかもしれないですね。
そのぐらいのときにPythonに一気に社内言語を切り替えてですね、
もう今PyConJPとか運営されている方もいますし、
Pythonの書籍とかもですね、いろいろ出されていて、
結構その会社のブランディングとしてPythonにしたことによってですね、
結構向上したっていうのがありますね。
なので結構ある言語に完全に振るって結構リスキーかもしれないですけど、
他と混じってしまうぐらいだったら何か先見の目を立ててですね、
どっかの言語に振るっていうのがありなのかなという気はしますね。
この中で言うと、Goって聞いてどこを思い浮かべるかな。
個人的にはメルカリのマイクロサービス化とかかな。
他も多分やってらっしゃると思うんですけれども、
あとRubyって聞くとやっぱCookpadさんが思い浮かぶかな。
多分世界一巨大な、GitHubよりも下かな。
日本では最大規模のRailsアプリっていう感じがしますし、
Kotlinは分かんないな。
Pythonって聞くとやっぱABcloudさん思い浮かべるし、
JavaScript、ここはもう分かんないな。
どうなんでしょうね。
Node.jsとか有名な会社さんであったりするんですかね。
その後はPHPもありますね。
PHPって言うとどこだろう。
色々あるような気がするけど、
すごい昔だったらGreeとかのイメージがありましたけど、
今どうなんでしょうね。
今ちょっと分からないですね。
Javaとかになるとさらに分からないな。
Javaって聞くとどうしてもエンプラ系というかSIR系のイメージが強いので、
Javaでサービス作ってますって言うとサイバーさんとかくらいかな。
そんな言語ごとに会社のイメージがあると、
求人は確かに楽になるような気がしますね。
ということでニュースはその辺りにして、
続いて本日のメインのトピックですね。
デブレルネームさんのクラウドサービスの利用
よく使うクラウドサービスといったところに入っていきたいと思います。
今日は4件ほどいただいてますね。
まず最初がデブレルネーム。
西から来た馬面の男さんですね。
いつもありがとうございます。
今週のテーマはよく使うクラウドサービスということです。
Amazon、Google、Microsoftをそれぞれ利用していると思います。
仕事の中では用途に合わせて自然と使い分けている感じです。
個人利用ではGoogleドライブに写真やスライドを格納しています。
共有するというよりバックアップ先としてファイルは貯めっぱなしです。
あと家族で子どもの写真共有サービスとして、
見てねを使っていましたが、
最近はLINEで共有して終わりになっちゃいました。
何か特徴ないなと思って綴りましたが、
普通な感じになってしまいました。
ということですね。
Googleドライブの活用
Googleドライブか。
このドライブ系クラウドストレージサービスって、
多分そんなにいっぱい使わないと思うんですよね。
個人的にはGoogleドライブか。
今は個人じゃないですね。
会社で使っているのはGoogleドライブと、
あとiCloud。
iCloudはあんまりメインで使うっていうよりは、
この西から来た馬面の男さんと同じで、
iPhoneのバックアップ目的とか写真のバックアップ目的で
使っているような感じですね。
仕事上はGoogleドライブだけじゃないですけどね。
GoogleドライブとかあとGmailとかひっくるめて
Googleの方に入れているんですけれども、
お客さんによってドロップボックス使っていたりとか
するケースもあってですね。
別にいくつも使いたくないんですよね。
ストレージなんで。
なので、ドロップボックスは多分今無償版のままなのかな。
共有ドライブだけもらってそこにアップしているっていう
使い方をしていますね。
写真サービスは見てねを使っているっていうこと書いてありますけど、
見てねって確かアルバム作ってくれるサービスだったような気がするんで、
家族含めあとおじいちゃんおばあちゃんとかですね、
そのあたりと写真を共有するっていうところだと便利かなと思うんですけど、
私もやってたっていうか、あれですね、
結局もうLINEじゃなくてFacebookメッセンジャーですけど、
そこで写真共有して終わるみたいなことの方が多いような気がしますね。
アルバムの方がいいっていう場合は見てね使えると思うんで、
ぜひご利用くださいというところですね。
ではですね、続いてDevRelNameの札幌のじゅんさんですね。
いつもありがとうございます。
発表スライド共有サービスDocsWell
発表スライド共有サービスのDocsWellを気に入って使っています。
URLを共有すれば活動の概要を伝えられるため、
いちいち資料をゼロから作ることなく、
即興で事例紹介などに役立てています。
表示中に頻繁に動画広告で足止めされるとか、
アップロードしたスライドのフォントがボソボソになるとかのマイナス体験も
今のところ起きていないため、しばらく使えたら嬉しいですということですね。
DocsWellは、誰だっけ…
DevRelにもよく来てくれてたんですよね。
よく来てくれてたんですよねとかって言って、
お名前を忘れているっていうのは、本当失礼極まりないんですけれども。
あれ?会社になってる?会社になってる?
あれ?なんか名前が違くなってる気がするぞ。
あれ?DocsWellって売却したのかな?もしかして。
あれ?DocsWellって知り合いの人がやってませんでしたっけ?
もし誰かコメントくれると、
DevRel Meetupにもよく来てくれていた方だと思うんですよね。
個人であれ?でもこれじゃなかったのかな?
あれ?もし違ったら大変申し訳ないっていうところなんですけれども。
あれ?違ったのかな?もしかしたら、すみません、違いかもしれないですね。
あれはマークダウンで何か作れるような、スライドを作れるようなサービスだったような気もするんで違ったかな。
DocsWellは日本語でPowerPointやPDF、ワードファイルを共有できるサービスということですね。
昔、こういう似たようなサービス作ったんだよな。
スライドシェアが出てきた直後ぐらいで、
昔OpenOfficeっていうソフトで、今はDevRelOfficeでしたっけね。
それ使うとPowerPointとかをPDFに変換することができてですね。
それをフラッシュベースのスライドビューアーみたいなやつで表示するみたいなサービスを昔作ったことがあるんですよね。
名前忘れちゃったな。
何とかDocっていうサービスだったんですけど、
よくよく思うと、今はもうフラッシュとか全然使わなくなってるんで、
それほど伸ばすのは難しかったのかなっていう気がするんですけれども、
DocsWellは今も着実に成長しているサービスということですね。
個人的にはスピーカーデック使っちゃってるんで、
なかなかDocsWellに移行するのは難しいかなと思うんですけど、
何か特徴あるんですかね。他と違うところは。
もしご存じの方がいたら教えていただきたいというところですね。
はい、では続いてですね。
Googleカレンダーとスラックの利用
3人目ですね。DevRelNameみきほさん。いつもありがとうございます。
気がついたら本当にたくさんのクラウドサービスを使っています。
スマホの普及とクラウドサービスはセットなのかなと思います。
音楽のサブスクとかもクラウドサービスですし、
ミキシに始まるソーシャルメディア全般もクラウドサービスと言える。
銀行のAPIやクレカ情報と連携した家計部ツールも
今は当たり前となっているのが昔はなかったんですよね。
その中であえて一つといえば一番付き合いが長くて身近なやつ。
Googleカレンダーですときてますね。
確かにGoogleカレンダーは私も使ってますけど、
すごい息が長いですね。
もうなんかあって当たり前みたいな感じに
これ読んで確かにGoogleカレンダー確かに身近だなって思いましたね。
もうスマホとかにあるのも全然当たり前だと思いますし。
ビジネスでも使うのも当たり前になってますよね。
個人的にはカレンドリーっていうサービスを予定共有で使ったりするんですけど、
それもGoogleカレンダーと連携してカレンドリーの抑えられる枠の中から
Googleカレンダーでも予定が入ってたら
それは自動で取り除いてくれるとかあったりするんで
そういうところでGoogleカレンダーは他のカレンダーサービスは使わないですね。
やっぱり連携サービスがいろいろあるっていうのは大きいと思うんですよね。
さっきのカレンドリーもそうですし、
あと個人的に使ってるTodoistっていうタスク管理のサービスもあるんですけど、
それもGoogleカレンダーと連携できるんで
Todoistで予定を入れるとその枠が自動的にカレンダーになってくれたりとかしてですね。
さらにカレンドリーで連携するとTodoistで登録すれば
その枠はもうカレンドリーで抑えられなくなるみたいな感じで
これもさっきのAPIの話に通ずるかもしれないですね。
こういうシステム連携とか実現するのはやっぱりAPIベースなんで
Googleカレンダーが完全にハブになっているような感じはしますね。
そういうメールは最近はあんまり使わなくなってはいるんですけど
カレンダーサービスであったりタスク管理だったりとか
チャットとかそのあたりはハブになりやすいサービスなのかもしれないですね。
スラックとかもやっぱりAPIベースで伸びてきたっていうところが
そのハブになったっていうところは大きいと思うんで
ハブになるサービスを作れるかどうかっていうのは結構
伸びるサービスかどうかの決め手になるかもしれないですね。
ということで4件目ですね。
DevRelName ジャニーマンさんですね。いつもありがとうございます。
なかなか一つに絞るのは難しいですと。
強いて言えば広める活動をしたスラックですと。
社内やクライアントさんとのやり取りに欠かせません。
リモートワークする上でも必須ですと来てますね。
そうですね。
最近お手伝いさせてもらっている会社さんの
多分9割以上はスラックですね。
残るのはDiscordがあるのと
あとチャットは参加してないんですけど
Teamsを使っているっていうケースはありますね。
Teamsって本当にチャットに参加したことがないので
スラックオルタネイティブサービスっていう風に言われてますけど
どうなんでしょうね。
同じように使えてるんですかね。
Discordもスラックと同じように使えるかって言われると
ちょっと使い勝手違うと思うんですよね。
なんとなく。
チャットよりも
何でしょうね。
リアルタイムに画面共有して
そこに対してわちゃわちゃコメントする
いわゆるゲームの使い方であったりとか
あと画面共有はしないんだけど
みんなコンソールのゲームやりながら
チャットだけ、ボイスチャットだけDiscordでやるみたいな
なんかこうスラックのような文化は
生まれづらいような気がするんですよね。
私の使い方がそうなってるっていうだけかもしれないんですけれども
ただスラックは結構
セールスフォースに買収された後に
ビジネス系に重点なので
それに対して
Discordは個人ベースの方に振ってるっていうところで
住み分けできてるのかなっていう気はするんですよね。
うちはね、社内は全然私しかいないんで
社内でコミュニケーションっていうのはしないんですけど
クライアントさんとのやりとりはもう
スラックばっかりですね。
ただスラックって
いいとこでもあると思うんですけど
ワークスペースっていうんですかね
単位ごとに認証が変えられるじゃないですか。
多分ほぼほぼのところが
ワークスペース同士を連携させるやつ
なんていうのか忘れましたけど
コネクトとかそんなやつを使ってるんですけど
それ以外のところも結構あるんですよね。
お客さんのところで
クライアントさんのところで
アカウントを払い出してもらって
使っているところも多いんですけど
その時にセキュリティの仕組みが
それぞれ別々になっているので
やれマイクロソフトのオーセンティケーター
使ったりとか
しかもそれが
Googleのサムルと連携してやってるとか
っていうのがあったり
あとは完全に
別なアカウントを払い出してもらって
独自のサムルのシステムのところで
ログインしなきゃいけないとか
やれ二段階認証が
どこでも使える
Googleオーセンティケーターでも使えるような
やつだったりとか
別なところはワンログインのやつだったりとか
別なところマイクロソフトのオーセンティケーターしか使えないとか
もう本当なんかセキュリティの仕組みが
自由度が高いのは良いことなんですけど
点でバラバラになるんで
いろんなアカウントも渡されると
本当その管理が煩雑になるんですよね
あれは本当に嫌なんですよね
結局なんかそれって
会社同士のコネクトと普及率の話
会社同士のコネクトを使うと
おそらく作成できるプライベートチャンネルとかの
制限があったりするんで
中に取り込んじゃうみたいな感じっぽいんですよね
その制限があるから
運用がめんどくさくなってるような感じが
あるんですよね
それぞれの会社さんにセキュリティのやり方があるんで
かといってそれが本当に満たされるんだろうかっていうのは
疑問なんですよね
ホットさんからコメントきてますね
スラックの普及率ってそんなに高くないんですよね
世の中的にときてますね
こと日本においては
チャットワークもかなり頑張ってる気はするんですよね
特に修行とかの人たちに対しての
チャットワークの普及率ってかなり高いっていう風に聞いているので
私は今のところ一つのお客さんだけですね
もうそこはやってないんですけれども
一つのところだけがチャットワークを使ってましたね
あれのインターフェースも全然慣れなくてね
確かスラックが日本に上陸する前は
別のお客さんのところもチャットワークでやってたんですけど
あれは本当に慣れなかったな
使い慣れている方とか逆にITリテラシーがそれほど高くない方からすると
多分チャットワークのインターフェース使いやすいんじゃないかなと思うんですけれども
なかなかスラックとかに慣れてしまうと
入り込みしづらくなるような気はしますね
そしてさっきのアカウント周りですね
フリーの人あるあるな気がする
そうですよね
これどうなんでしょうね
大きい会社とかだったらそういうことにならないんですかね
フリーというか一人法人だからそうなっちゃってるのか
その会社さんとの力関係なんですかね
なかなかつらいですね
多分これフリーとかもありますし
あと代理店とかもあるあるだと思うんですよね
代理店とかでお客さんのところと色々付き合いがあると
それぞれに対してアカウントを作らなきゃいけないっていう感じもするんで
でもSIRとかもそうかな
プロジェクトとかでお客さんのところのスラックだったり
お客さんのところのTeamsとかに入らなきゃいけないというケース
よくあったりするんで
そういった意味でなんかこう
チャットインターフェースが色んなところに飛び散ってるような気はしますね
なかなかつらいですよね
そんな話もありながらですね
DevRel Meetupのイベント情報
最後イベントのご案内ですね
DevRel Meetupの通常回
ラジオではなくですね
通常回の方が明日あります
明日です
7時からですね
86回目ということですね
テーマはですね
マネージメント層から見るDevRelと題してお届けいたします
結構面白い方はですね
登壇していただきます
例えばまず最初のセッションが
セゾン情報システムズの有間さんですね
セゾン情報システムズさん
運営メンバーであったりとかね
よくイベントに来てくれている方とか
そのセゾンの方なんですけれども
そのCTOの有間さんがですね
以前何回くらい前かな
2,3回前に来てくれてですね
今後そのDevRelを強化していきます
みたいなお話をしていたので
是非初心商議みたいなところを聞きたいなと思ってですね
明日登壇いただくといった予定になっております
あと2番目のセッションが
さくらインターネットの横田さんですね
横田さんはさくらインターネットの執行役かな
完全にもともとさくらインターネットの
さくらのクラウドのエヴァンジリストをしていて
そこからだんだんキャリアを積み重ねてですね
今はそういった立場になっているというところで
このようなテーマ設定で
パネルディスカッションもしてもらったこともありますし
すごい昔にお話ししてもらったりしたこともあるんですけれども
是非アップデートも含めてお話ししてもらいたいなと思って
今回お呼びしています
さくらインターネットさんは
コミュニケーションマーケティング室みたいな
そんなような部があってですね
そこは私も関わって
コミュニティ周りとかお手伝いしていたりするので
中の状況とかある程度知ってはいるんですけれども
今回はそれを経営目線で見たところというのを
お話ししてもらおうと思っております
3番目がですね
ファインディーの神谷さんですね
採用の最前線から見るデブレルの効果といったところで
結構その求人系とか転職系とかで
デブレルを頑張ってイベントをいっぱいやってですね
ユーザーベースを作られている会社さんって
いろいろあると思うんで
そのあたりのお話含めですね
ファインディーさんにお話を聞くと
いったところになっております
なのでですね
結構今回のお話は面白いお話がいろいろ聞けそうかなと思うんで
ぜひですね
明日配信はやらないので
ぜひぜひ現地に来ていただけると嬉しいなと思っております
はいということでですね
本日のデブレルラジオの125回
うそ124回目ですね
124回目よく使うクラウドサービスは終了していこうと思います
来週も
来週ってそろそろ何か
何だっけ
お盆なんですかね
そんなことない?
大丈夫?
いつがお盆なのか全然わからないんですけど
はい
来週もやっていこうと思いますので
ぜひぜひご覧いただければと思います
はいということでですね
本日の配信デブレルラジオは以上になります
皆さん引き続きお仕事頑張ってください
ではまた来週お会いしましょう
さよなら
