DevRelの紹介とキャリアスキル
はい、皆さんお疲れ様です。9月の9日ですね、今日はDevRel Radioの232回目ですね、やっていきたいと思います。
まず最初にですね、DevRel Radioの紹介からですね、DevRel RadioはDevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日夕方5時半から大体1時間程度ライブでやっているというものになります。
DevRelというのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、例えばテクノロジーエヴァンジリストとか、デベロッパーアドボケイトとか、コミュニティマネージャーとか、マーケターとか、
そういった方々が集まってですね、情報交換したりイベントをしているというコミュニティになっております。
DevRel Tokyoの公式サイトがありまして、DevRel.Tokyoというサイトになります。
そちらからスラックに参加もできますので、DevRelに関わっているとか、興味があるという方はぜひジョインいただければと思います。
あとは公式のXアカウントのAtDevRelTokyoとか、今これ配信しているYouTubeチャンネルとかですね、ありますんで、
ぜひチャンネル登録いただいたりとかフォローいただいたりとか、動画の高評価いただけると嬉しいですというところで、
今日のメインテーマなんですけれども、今日はエンジニアのキャリアを広げるスキルという風になっております。
このAIの時代になってですね、たぶんプログラミング能力が不要にはならないと思うんですけど、
そこまで必須スキルじゃなくなるエンジニアとしてですね、必須スキルじゃなくなっていくような気はするんですよね。
そういった中でですね、単純にエンジニア力だけだとなかなか食っていくというのは難しくなっていくのかなというところがありますんで、
それ以外のエンジニア力プラスアルファでどういったスキルがあるとですね、キャリアが広がるのかというところを、
ぜひ皆さんの意見をお聞きできればと思っております。
個人的にはですね、デブレルやっているという関係があるんで、
マーケティングスキルというのがですね、とても大事になってくるんじゃないかなという気はしているんですよね。
マーケティングスキル自体は、そんなにこうエンジニアの理系の考え方とずれていないというかですね、
結構地道な数字の積み重ねの部分ってあったりするんですよね。
基本的にはそのフレームワークみたいなものはいくつも提唱されていて、
それにのっとって考えていくことで、次どういう施策がいいのかみたいなところは考えていくんですけど、
中にはですね、新しい発表しもないアイディアによってですね、バズったりとか注目を高めたりみたいなこともできたりするんですけど、
そこらへんは結構アイデア力っていうところも問われるのかなと思うんですけど、
基本的なところとしてはですね、割と数字の積み上げの部分になってくるんで、
個人的にはですね、マーケティングスキルっていうのはとてもキャリアを広げる上で役立つんじゃないかなと思ってはいるんですよね。
というところで、皆さんのご意見をですね、ぜひ今のうちにいただければというところで、
コメントにURLをですね、載っけてきましたんで、ぜひ今のうちに投稿いただければと思っております。
ロボティクスとDevRelの必要性
コメントは匿名で寄せられますんで、ぜひお気軽に送っていただければと思います。
それまではですね、最近デブレルに関係するような話題っていうのを取り上げていきたいんですけど、
最近ちょっとですね、思うところがあって、日本っていうよりは英語圏での活動をやるように個人的にしているんですね。
1個、レディットってあの掲示板フォーラムサービスがあると思うんですけど、
そこで話している人がいて、そこにコメントしてあげたら、
向こうからもまた返事が来て盛り上がりそうだなっていう話題で、
Looking for feedback. Can I run the process automation platform in automation and robotics inspire a new wave of IT evangelism?
っていうタイトルで書かれていてですね。
それ自体は、フィードバックくださいっていう話で、
この方がですね、ロボット工学における自動化されたR&Dプロセスプラットフォームっていうのを作ってるらしいんですけど、
そこに対してエヴァンゲリズムが必要なのかどうかっていうところですね、意見を聞いていたんですね。
サービス名がBeep Toolkitっていうサービスで、
パソコンでロボティックスの開発とかオートメーションとかを開発できるというプラットフォームらしいと。
いわゆるラズバイであったりとか、アルディーノとかそういうものを使わずに、
そういうロボティックスの開発ができるっていうのが魅力らしいんですね。
そういったものを作ってるんだけど、その時にエヴァンゲリズム活動っていうのがどこまで必要なんでしょうっていう風に聞かれていて、
誰も答えてなかったんで私が答えたんですけど、
私の答え自体を簡単に言うと、このサービスの説明は書いてあるんですけど、そんなに詳しくはわからないんで、
そもそもこのサービスが開発者がステークホルダーとして必要な存在だとしたら、
DevRelはやるべきじゃないですかっていうところ。
こういうロボティックス関係であったとしても、別に開発者関係ないっていう場合もあると思うんですよね。
そういった場合は別に無理にDevRelをやる必要はないと思うんですけれども、
そもそもこのサービスをやる上で、開発者の存在がステークホルダーとして大事になるんだったら、
やるべきじゃないですかっていうのがまず1個ポイントになります。
2つ目のポイントとしては、RaspiとかArduinoが上がってたんですけど、
そことの差別化っていうところをきちんと説明しないと、
開発者ってRaspiとArduinoずっと使い続けてきたりとかして、他のマイコンとかも使ってたりするんで、
新しい何か魅力がないとなかなかスイッチしづらいところがあると思うんですよね。
RaspiとかArduinoに対して何か不満が溜まってますとかって言うんだったら乗り換える余地はあると思うんですけど、
多分そうはならない。
マイコンの世界ではすごく有名だし、モジュールもいっぱいあるしっていう中で、
どういうふうに自分たちのサービスが特別なんだっていうのを見せるのかが問われますよねっていう話。
このサービス自体がパソコン上でオートメーションだったりとかロボティクスとかが開発できるっていう話なんで、
開発者のターゲットがそもそもソフトウェアエンジニアなのか、それともハードウェアエンジニアなのかが、
結構ぼやける可能性がある。
開発者にしてみると自分がこのサービスの使うべきユーザーなのかどうかが、
ちょっと分かりづらい部分があるんじゃないかなっていう気がするんですよね。
なので自分たちのサービスがどちらの開発者をターゲットにしていて、
どういうふうに使ってほしいかっていうのをきちんと示す必要があると。
その時に多分一番いいのはデモアプリみたいなものだったりとか、
一番刺さるであろう一番いいソリューションというかアプリケーションみたいなものを作って、
こういう時に使えるのねみたいな感じのことが分かるといいんじゃないっていうところ。
教育機関との連携と業界の成長
あとは例えば広めていく上ですね。
まず今のところ作ったばっかりのサービスっていうところがあると思うんで多分。
なので例えばハッカソンとかに出展してですね。
そこでいろんな開発者の人に触ってもらった上で、
そこでフィードバックを得てPMFをきちんとやっていくと。
あわよくばですね。
ある程度大きいクライアントですごくしっかり触ってくれるようなところが2、3個でも確保できればですね。
その人たちにもいっぱい使ってもらって、
そこで密にコミュニケーションしながらPMFをちゃんとやっていくというのがいいんじゃないですかっていうふうに私はコメントしてたんですけれども。
そこに対して返事が来ていて、
Beapツールキットの主要なステークホルダーとして開発者は存在しますと。
ただ他にも異なる層があって、
研究開発を行っているエンジニアとか、
メカトロニクスの専門家とかテスターとか。
そういう人たちは大学とか専門学校にいる講師の人たちですという話があります。
学校をやるってなるとまたちょっとやり方考えないといけないかなっていう気はするんですけど、
そもそも学校とかで採用してもらう場合ってある程度の認知度があったりとか、
あと学校にとってのメリットみたいなものがないとちょっと難しい部分あると思うんですよね。
日本の場合でいうと、
学校で採用してもらうのってすごいハードルが高くて、
特にその学校の予算の付け方が結構複雑なんですよね。
クラウドサービスとかはかなり難しくて、
某サービスだと本を買ってもらうんですよね。
本を買ってもらって、その本に1年間使ってもらえるっていう権利を付けますと。
そうするとその1年間の授業ではそのサービスが使い続けられるみたいな感じになって、
その時に面白いのがバージョンアップしちゃいけないんですよね。
このサービス使ってる間。
少なくともそのサービスを学校の授業で使ってもらうってなったら、
ある意味そのバージョンを切り出すんですよね。
エデュケーションバージョンみたいなものを作って、
それはもう本当1年間ずっと固定の状態でやると。
さらに言えば、もし次の年も採用してもらうってなると、
学校の先生がそのバージョンアップしたのに追従するのがすごく大変だったりするんで、
そのまま継続して使ってもらえるように、
エデュケーションバージョンについては最低限のセキュリティの問題とかしか対応しない。
もうずっと同じ状態で使うみたいな感じになったりとか、
あと先生が説明する時に説明しやすいように、
キーボードショートカットとかは基本的に無しなんですよね。
キーボードショートカットがあると、
その先生が画面をプロジェクターとかで見せてて、
こうやって操作するんですよって言った時にすごく、
画面が動いてないので学生は理解できないというところで、
必ずボタンを用意してこのボタンを押してくださいって言ったりしないと操作できないですよね。
っていう制限があったりとかして、
今どきのある程度いけてるインターフェースとか操作性みたいなものをつけちゃうと、
学校で採用しづらかったりするとかですね。バージョンアップできないとかですね。
いろいろ厄介な問題があるというのが、
エデュケーションでよく言われるところですね。
ジャニーマンさんからコメント来てますね。
久しぶりにライブで聞けます。よろしくお願いします。
ArduinoとかRaspiとの差別化については、
というところでは中小化のレベルですというところでブラブラブラって書いてくれてます。
ここら辺はうーんぐらいな感じなんですけど。
ソフトウェアとハードウェア領域の曖昧さについては、
ポジショニングにおける課題ですということで、
ここは考えていくんじゃないかなというところですね。
あとはPMFというところで、
産業プロジェクトで実績のあるところと事例をセットで構築中ですというところで、
これはいいんじゃないかなと思いますね。
八甲村は来年の春開催を検討していますというところらしくてですね。
コメントしてよかったなというそういう内容になっています。
あともう一個はですね、これもまたRedditなんですけれども、
Is the DevRel industry still growingということで、
DevRelの業界はまだ成長してるんですかというスレッドがあってます。
これは色々コメントが書いてあるんですけど、
私がコメントしたのは、
これはもう今リストにはリスティングにないんですけど、
とある人の報告でですね、
アンソロピックとかあとメタとかスナップとかがですね、
求人情報を出していて、
DevRelJob.comっていうやつなんですけど、
ここになんと年収が350Kで出してたんです、USドルで。
350KUSドルってことはだいたい5000万ぐらいですね、年収にして。
っていうポジションをですね、出していたっていうところがあり、
メタとかって確か何でしたっけ、
AIのエンジニアにそれこそ数億円で引っ張ってきたみたいな話とかもあったりしたので、
DevRelのポジションで年収5000万っていうのが、
デベロッパーアドボカシーの重要性
彼らにとってすごい莫大かって言われるとちょっと分からないんですけれども、
アンソロピックとかメタとかですね、
そういうAI系に今力を入れているところっていうのが、
DevRelのロールに対してですね、
かなりハイサラリーを提供しているという状態になっているんで、
このDevRelの業界自体はですね、全然拡大しているというか、
ポジションとかも企業も結構出していたりするんで、
拡大しているんじゃないかなっていう気はしてますね。
っていうコメントを出したりとかしてます。
他にも記事としてですね、
これはDev.2の記事ですね。
White Developer Advocacy Matters in India Guide for Aspiring Advocatesということで、
インドでデベロッパーアドボカシーが重要な理由というですね、
記事が出ております。
これはですね、Nimitっていう方が書いていて、
この方は今度のDevRel会議でも登壇してくれる方ですね。
そのNimitの記事になります。
この中で書いてあることとしては、
なんでインドでデベロッパーアドボケイツみたいなポジションが重要なのかというところの理由を3つ挙げていて、
まず1つ目が情報格差の解消というところで、
これは別にインドに限った話ではないですね。
最新のツールやAPIへのアクセスが難しい開発者に向けて、
分かりやすく情報を伝え、学習の機会を提供するということですね。
2番目、役割の認知が低いというところで、
これは日本もあんま変わってないのかな。
学生にも企業の経営層にもこのデベロッパーアドボケイツっていう役割の理解があまり進んでおらず、
事例や教材が不足しているということで、
デベロッパーアドボケイツだけじゃないのかな、これは。
APIとかも含めなのかな、事例や教材がまだまだ不足しているので、
まずは体験談を共有することが大事だということですね。
あと3つ目としては、技術連携の促進ということで、
異なるプロダクト同士の統合や連携のきっかけを作るのが、
デベロッパーアドボケイツの新骨頂ですと。
結果的に導入率の向上に貢献するということですね。
というところがデベロッパーアドボケイツの大事な役割だと書いてあります。
デベロッパーアドボカシーになる方法
このデベロッパーアドボケイツになる方法、全部で5つ挙げています。
1つ目、技術力を磨くということですね。
これは当然ちは当然ですよね。
オープンソースとか作って、自分の技術力をアピールしましょうということですね。
2番目、コミュニティに参加しましょうということで、
例えばフォーラムだったりとか、あとここにはIRC、懐かしいですね。
私は大好きですね、IRC。
IRCなどで情報発信やディスカッションに参加し、
自分の存在感を高めましょうということですね。
3番目、コミュニケーション能力をつけましょうと。
他の外部の開発者との建設的なディスカッションを意識し、
常に助け合いの姿勢を持ちましょうということですね。
4番目、ロールモデルに学びましょうというところで、
まだそんなにインドでデベロッパー界隈の人いないことはないかな。
いないことはない。
日本よりも人口が10倍ぐらいあるので、いないことはないです。
日本の10倍はいます、軽くね。
なんですけれども、人口比で考えれば日本と同じぐらいで、
デベロッパーアドボケイツみたいな役割になっている人ってそんなに多くはない。
むしろコミュニティマネージャーの方が多いかもしれないですね。
なので、そういうロールモデルそんなに多くはないんですけれども、
そういうロールモデルに学んでいきましょうということで、
ただ、なるべく自分でちゃんと調べた上で、
より具体的な質問を相手に投げかけていきましょうということで、
例えばホニャララっていうデベロッパーアドボカシーに関するブログを読んだんですけれども、
イベントでのメッセージ設計について意見をくださいみたいな、
そのぐらい踏み込んだ感じで聞いたほうがいいと。
例えばデベロッパーアドボカシーについて教えてくださいぐらいだったら、
もうオンラインにいろんな情報があるんで、
自分で調べれば大丈夫じゃないっていうそういう話だと思いますね。
最後、5つ目がオープンソースに貢献しましょうというところで、
日々使っているオープンソースソフトウェアに対して、
グッドファーストイシューっていう、これはXのハッシュタグだと思いますね。
グッドファーストイシューなどで小さな貢献から始めて、
自信と実績を積み上げましょうということですね。
オープンソースの影響
ほんとね、インドってオープンソースがめちゃくちゃ人気があるんですよね。
彼らの中にかなり染み付いてるんじゃないかなっていうぐらい、
使うほうもそうですし、あと作るほうもそうですね。
割とオープンソースで始めて、ある程度大きくなったら、
それをサース化するとか、オープンソースはそのまま維持しつつ、
プレミアムの機能を優勝として提供するみたいな、
そういうモデルが結構多いんですよね。
有名なところで言えば、
Hustlerっていうポストグレースケールに、
GraphQLの機能を追加するっていう、そういうやつであったりとか、
あと、AppWriteっていうエンバースのサービスであったりとか、
あと、うちで協力してるCodeRabbitっていうのも、
もともとPRなんとかみたいな、そんなオープンソースのツールがあって、
それが人気が出てきたんで、クラウド化して、
今CodeRabbitっていうサービスに変わってるんですけど、
それもまだね、
オープンソース版の方はリポジトリもアーカイブはしてあるんですけれども、
まだ見ることはできるので、もしかしたら使っている方もいらっしゃるのかなっていう感じですね。
他にも結構オープンソース、
オープンソースインド初っていうのもありますし、
インド初じゃないんだけど、インドでめっちゃ使われてるみたいなものは多かったりするので、
そういった意味ですね。
このやり方はヨーロッパとかインドに結構多い気がしますね。
アメリカでオープンソースでみたいなのないことはないか。
日本語でABとか、
サークルCIはちょっと違う。
違う、サークルCIじゃない。
Jenkinsはちょっと違いますかね。
Jenkinsって確か元々日本ですよね。
日本で言えばプリザンターとか、
ヨーロッパではあと、
ウィキのサービス、コンクリートファイブとか、
ドゥルーパルとかワードプレスとかかな、
そのあたりが近いモデルの考え方かなと思うんですけど、
あれが結構インド初っていうのが多いんですよね。
逆に日本はそんなに多くないイメージではありますかね。
私が調べた限りでも有名なところだと、
センチャーっていう業務システムの請求書出したりとか、
あと、何だったかな、
業務アプリケーションシリーズがあるんですよね。
抹茶シリーズだったかな、センチャーシリーズだったかな。
っていうのであったりとか、
あとさっき言ったプリザンターとか、
グロービーもそうかな、社内ウィキのサービスとかくらいかな。
そんなに多くないイメージではありますね。
なかなか日本に限った話ではないんですけれども、
本当その利用者ばっかり増えるんですよね。
あとEC-CUBEもあったか。
コントリビューターが増えない問題っていうのがあって、
本当にこれができません、あれができませんみたいな、
そういう意見ばっかり来るっていうところで、
開発リソースがすごく逼迫しちゃって、
うまく回らないみたいな、そういう話はよく聞きますね。
オープンソースなんで、
何らかお互いコントリビュートできる仕組みがあればいいと思うんですけど、
なかなかそれがうまくいかないみたいな話は聞きますね。
なんでそれがインドだとうまくいくんだって言われると、
私もよくわからないんですけど、
割とインドだとうまく回っているんじゃないかなって思いますね。
ただ面白いのはインドでオープンソース作って、
そこでコントリビューター増えたりとかして、
ユーザー増えたりとかして、
その有名になりVCとかからお金が入ると、
サンフランシスコ行っちゃうんですよ、速攻で。
全然インドに残らないっていうね、
インドでサービスを盛り上げていこうみたいな感じじゃなくて、
まっという間にサンフランシスコとかシリコンバレーに行っちゃって、
そこでサービス開発したり、人員募集したりするっていうのはね、
結構あるあるの話ですね。
っていうのがこちらがNimitの記事でしたね。
何か面白いのあったかな。
これはPospiのTogetherのクローンサービスじゃないですね。
公式のサービスなんであれですけど、
Pospiの記事の何の営業かなって気軽に会議に出たら、
データセンターサービス終了のご挨拶で震えているということで、
いやこれはね、恐ろしいですよね。
データセンター終了しますんで移行してくださいって。
私は言われたことないかな。
昔々2000年ぐらいのときにデータセンター使ってたんですよ。
で、そのときはハウジングでエクソダスとかなんとかいうサービス、
多分蛇がお互いの尻尾を食べ合ってるみたいな、
そんなような意味のデータセンターサービスだったと思うんですけど、
多分エクソダスみたいな名前だったような気がしますね。
新宿御苑のところにデータセンターあったんですけど、
そこにハウジングしていて、そこがサービス終了じゃないんですけど、
多分記憶うろ覚えなんですけど、
多分ソフトバンク系に買われたんですよね。
で、そのときは会社をサービスを売却して、
別なデータセンターサービスのところになりますっていう挨拶に来てもらったっていうのは覚えてますね。
ただそのサービス終了ではないので、そんな問題なく、
ただ多分料金とかSLAとかがちょっと変わったとかあったと思うんですけど、
影響なく終わったんですけど、
このデータセンター終了しますってなって、
もう取れる選択肢がそんなに多くないと思うんですよね。
少なくとももうハードがある話なので、
いきなり別のところに移行するっていうことはできないじゃないですか。
そしたらコールドスタンバイしている全く同じ環境があったとしたら、
じゃあそれを新しいデータセンターのところに構築して、
で、スイッチしてそっち側にトラフィックが流れるようにして、
旧サーバーの方を停止して、新しいところに持っていき、
そこで今度はそっち側をコールドスタンバイなりホットスタンバイなりにしてセットアップするみたいな、
結構ジコリそうな感じですよね。
コールドスタンバイとかにしていると、
大抵うまく切り替えがうまくいかなかったりとか、
ハード的な不具合が発生してたりとかして、
いざ動かしてみたらダメでしたみたいなことはよくあるあるなのかなっていう気はするので、
それで結構難しい気はしますし、
コールドスタンバイとかホットスタンバイしていたとしても、
少なくともルーターの部分は一箇所になっていたりとかするんで、
そうするとそのネットワーク機器は買わなきゃいけない感じだったりとかするかなと。
もうあとはクラウドに移行するかどうかだけですよね。
クラウドに移行したくないからこそ、ずっとハードウェアを、
データセンターを使っていたわけで、
それがなくなるってなるとね、
ハードの予算とか盛りないってなったらもうどうしようもないですよね。
本当にデータセンターは終了しちゃダメでしょって、
少なくともどっかに売却してほしいですよねって思ったけど、
とある事例記事のインタビュー行ったときも、
確かにデータセンターサービスが終了するから、
そこはクラウドに移行するっていう話で事例を聞いた覚えがありますね。
そこは多分そんなに後ろ向きだったわけじゃないですよね。
ただハードがもうあったし、
それが特に問題なく動いていたので、
そのままずっと使い続けてますっていうところだったんですけど、
それがサービス終了っていう風になったんで、
じゃあこれをいい機会と捉えてクラウド移行しようかっていう感じだったんですよね。
データセンターの影響
クラウド移行自体は特に問題なく完了したんですけど、
それができない場合もあると思うので、
その場合、このデータセンター終了はかなりインパクトでかいですよね。
最近データセンターはむしろ広がっていくというか、
どんどん今建築ラッシュが進んでいるっていう話ではあるんですけどね。
私の近所はデータセンターが割と多くて、
3つぐらいあるらしいんですよね。
2つは知ってるんですよね。
2つはデータセンターってあからさまに怪しい建物じゃないですか。
ぱっと見窓ないし、すごい四角いシーンみたいな感じで、
何があるのかようわからんみたいなの普通に見たらなると思うんですけど、
そういう建物が2つはあるんですけど、
実際には3つあるらしいということを聞いたことがありますね。
あとは最近相模原の方に建設を相模原が手を挙げたみたいなのがニュースになってた覚えがありますね。
多分そこら辺の過疎地というか、そんなに人が住んでない場所みたいなのを
ちゃんとデータセンターに開放するのかなっていう気はするんですけど、
あと北海道とかもまだ開発進んでたりしますし、
なのでデータセンターを畳むっていうのは、
なかなかあまり聞かない話だなって思いますね。
この中でサービス終了するジバのデータセンター増えるんだろうなっていうことも書いてありますね。
ジバのデータセンターってことは規模がそんなに大きくない可能性はありますかね。
一番最初に入った会社がケーブルの会社だったんですけど、
インターネットプロバイダー業務もやってたんですよね。
そこはケーブル販売やっているところの一室みたいなところにサーバーがいっぱい入っている部屋があって、
そこで多分インターネットプロバイダー提供してたんですけど、
サーバーもいくつかあったんですよね。
あれは全然めちゃくちゃ規模ちっちゃいので、
多分2000年の頭ぐらいでも畳んだか打っちゃったかした可能性はあると思いますし、
そんなに大きな影響はなかったのかなって思いますけど、
今存在しているデータセンターとかであればそれなりの規模だったりするかなと思うんで大変ですね。
3社目の時は社内の一角にサーバーは入れてたんですよね。
今どうなっているか全然知らないですけど、
あの時は外部公開しているものはどっかの専用サーバーを借りてやってたから、
データセンターって本当2社目の時だけかな、私が関わっていたのは。
あの時別にそんなに大きな問題もなく買い続けられていたんで、
今もしこのデータセンターサービス終了するからサーバーなんとかしてって言われたら、
いや本当に嫌になる気がしますね。
このコメント面白いですね。
昔いた現場で社長の知り合いの会社さんが借りてたデータセンターのサーバールームの一角を曲がりして、
その知り合いの会社さんがAWSに移行したからサーバールーム解約するから出て行ってくれって言われて、
突然AWSに引っ越しさせられたことがあった。
2ヶ月で引っ越したけどさすがに死ぬかと思った。
そっかそっか。
AWSに移行するってなったとしても、やっぱあれですよね。
いろいろ準備が必要だし、システム上の修正も必要だし、テストも必要だしみたいなところを考えると、
そうそう簡単ではないですよね。
これは本当にやりたくない。
しかもこの予算とかってどっから出るんですかね。
どうなんだろう、このデータセンターサービス終了ってなりますって言って、
少なくとも2年はやってほしいですよね。
最近SaaSのサービスとかで速攻で終わるところが増えたような気がしていて、
本当あれ良くないと思うんですよね。
日本の招集官とか考えたら少なくとも2年ぐらいは継続してやってくれないと、
予算も取れないし、開発期間もできないしみたいな気がするんですよね。
なのでこのデータセンターサービス終了問題、どのぐらいきついものかっていうのは、
読みづらい部分はあるんですけれども、
怖いですね。身がつままれるというか、話ですというところです。
翻訳業とAIの関係
あと何かあったかな。
このオライリーの話もあるかな。
ヤムダス現更新履歴さんからですね。
オライリージャパンにおける翻訳書の制作体制の変化と、
もうすぐ消滅する人間の翻訳についてという記事が出ております。
これは割とよく言われるところで、
何回か前のラジオでも紹介したと思うんですけれども、
もうすぐ消滅するという人間の翻訳についてという記事を前に紹介したかなと思うんですけど、
もうそれがオライリーとかで現実になりつつあるということですね。
翻訳に対して個人の名前ではなく、オライリージャパン編集部になっていると。
ただそこに対して翻訳は、
多分このオライリージャパン編集部っていうふうに書いてあるのは、
AIによる翻訳が導入されているんだろうということで、
ただあとは翻訳者っていうところで個人の名前があるということですね。
技術的なところで翻訳のおかしい部分があれば、
そういう翻訳者の方がチェックするというところかなと思うんですけれども、
全体の翻訳っていうのは、
AIでやっている可能性があるということですね。
違っていたらすいませんって書いてありますけれども。
割と私も翻訳の作業で、
その翻訳のタスクだけでお金をもらっているわけではなくて、
マーケティングする上で、
一部翻訳作業みたいなものが発生する場合あるんですけど、
その時にはAI使っている方が多いかなという気はしますね。
DeepLでどうなんでしょう。
普通のテキストであればDeepLでいいんですけど、
マークダウンとか渡すと、
大抵構造がメタメタになるんですよね、DeepLだと。
なので、マークダウンを使う場合は基本的には、
ChatGPTなりクロードなりに渡して、
必ずマークダウン構造を崩さないようにみたいな指示を与えて、
翻訳してもらってますね。
それで翻訳してもらってそのまま使えるかって言われると、
ちょっと微妙なところがあって、
それを修正はするんですけど、
この修正の量っていうのは年々減っている気はしますね。
こっち側のプロンプトである程度カバーできるところがあって、
熟練のタレというか、
だんだん内容が追加されていって、
洗練されたプロンプトみたいなものがあるんですけど、
そういうもので指示していくと、
どんどん品質の翻訳っていうのが上がっていて、
指示がだんだん必要なくなっているという状況ではあるんですよね。
よくやっているのが指示をします、翻訳してもらいます、
それを読んだ上でこっち側でちょっと変だなっていうところを修正して、
それをまたチャットGPTなりに渡して、
私が編集した文章と元の文章でどういう違いがあるのかっていうのを、
次回の翻訳で活かせるようにプロンプト文として出力してくださいとかっていう風に言うと、
つらつらつらって出てきて、
それを次のプロンプトの時に貼り付けるみたいな感じのことをしていると、
だんだんだんだん性能は良くなっていくんですよね。
っていうのがあって、
本当そのこと翻訳について言えば、
個人の力が及ばないところまで来ているなっていう気はしますね。
このオライリージャパンとかの書籍レベルの翻訳に関しても、
一気にやると多分失敗すると思うので、
軽くやりつつ、そこで編集、
もう一回ちょっと人間の編集が入ったやつをAIに渡して、
そこでフィックスしてっていうのをどんどん繰り返しながら、
だんだんだんだん長文を与えるようにしていったりすると、
ちゃんとできるようになるんじゃないかなという気はしますね。
ただ、ワイヤードの記事によると、
翻訳業のようにAIの影響を受けそうに見える分野では、
むしろ雇用が増加しているということなんですね。
どうなんだろう。すごく意外な気はしますね。
スタンフォード大学の経済学者たちは、
エンジニアのキャリア向上スキル
人工知能が特定の仕事を消し始めているという最も強力な証拠を見つけたと。
しかしその物語は単純ではない。
ある業界では若い労働者がAIにとって変わられている一方で、
経験豊富な労働者には新たな機会が生まれていると。
どうなんでしょうね。
経験豊富な人に新しい機会を与えるだけでいいんですかね。
単純な雇用創出ではないと言われつつも、
顧客サービスとかソフトウェア開発などにおいては、
若年層の雇用機会の減少が発生していると。
22から25歳の労働者の雇用の16%が減少しているということですね。
顧客サービスについて言えば、
セールスフォースがめっちゃカスタマーサポートから
人員を営業の方に変更したみたいなのが記事になってましたね。
その意味は本当に顧客サポートのカスタマーサポートの部分は
AIにとって変わられやすい可能性はありますね。
そういった中で人間とAIの協業がより重要になってくるということですね。
AI企業が人間とAIの共同を図る新しいケンタウルス型ベンチマークを
開発すべきだということですね。
人間と機会が一緒に作業することで、
AI単体よりも優れた成果が出せるタスクは
まだまだたくさんあると思いますということですね。
面白い。本当に恐ろしいですね。
では、今日のメインテーマのほうに入っていきたいと思います。
今日のメインテーマはエンジニアのキャリアを広げるスキルというところですね。
まず一つ目、デブレルネームジャーニーマンさんですね。
いつもありがとうございます。
この例に挙げていたコミュニケーションとか
マーケティング、ライティングなど
すべてできるといえるスキルを習得できたら
キャリアが広がると思います。
他にマネジメントは広がると思います。
今は上下ではなく役割と認知され出している点もポイントです。
取りまとめられている方がいると仕事がスムーズに進みます。
成果物を直接作る立場ではないですが、
生産性や品質に大きな違いが出ると思っています。
組織の役割でなくてもプロジェクトなら
PMP、いわゆるプロジェクトマネジメントプロフェッショナルとか
アジャイルならCSM、認定スクラムマスターなど
グローバルで通用する認定資格もあります。
学んでみてはいかがでしょうかということですね。
これはね、私は本当にアグリというか
マネージャーって上下じゃないと思うんですよね。
役割の違いでしかなくて、プロジェクトマネージャーとかもそうですけど
なんかその上に立とうとする人がいるじゃないですか。
あれ本当に良くないと思うんですよね。
現場のプログラマーの人であったりとか
テストエンジニアの方であったりとか
あとデザイナーの方であったりとか
そういう方々が仕事をしやすい環境を整えるっていうのが
プロジェクトマネージャーとかの役割であって
彼らのケツを叩く役割ではないと思うし
そこにこの評価みたいなものが混ざり込むと
すっごく良くないと思うんですよね。
確かに現場の人の方が
全然違う立場にいる人事の方とかよりも
より明確に作業とかが見えやすいっていうメリットはあるのかもしれないですけど
それは360度評価の一端であって
あくまでもプロジェクトマネージャーとか
CSMとかそういう人の求められるロールっていうのは
プロジェクトのスムーズな進行だと思うんですよね
そのためには上に立つとかではなく
むしろ下とは言わないですけど
整えるところですよね
部署であったりとかお客さんとかのやり取りを通じて
それをスムーズにタスクとして
プロジェクトに関わる人たちが仕事しやすくするっていう
そこだと思ってるんですよね
そこを勘違いして
メンバーの評価管理みたいなものがそこに入ってくると
なんかあんまよろしくないのかなという気はしてるんですよね
マネジメントっていう
ヒューマンリソースのマネジメントは
取った方がいいんじゃないかなという気がしてますね
今ちょっと私も普通の会社員みたいな立場じゃなくなって
長いので今も普通の会社のあり方って分かってないんですけど
昔は割とリソースマネジメントみたいなところもあって
その人たちを評価しなきゃいけないみたいな話があり
私はあれが本当に嫌いでしたね
キャリアを広げるスキルセット
その中ですね ジャニーマンさんが役割と認知されだしている点もポイントですというところで
これはいい傾向なのかなという気がしますね
マネジメントって本当に難しいですよね
こういうPMPとかCMS CSMみたいな
ちゃんと資格として存在してくれているととてもいいですよね
私昔Pinbookとか取った覚えがありますね
取ってないか 取ってないな
多分資格の勉強をしたぐらいで終わったのか
多分 あと何でしたっけ
ISMSとか あの辺りの対応するときの勉強とかね
ああいうもの
でもISMSって国際的な基準のはずなんですけど
ほんまなんかこう 日本以外の国でやってるとこ少ない気がするんですよね
海外だと何でしたっけ
クラウドベンダーとかが取る資格が微妙に違くて
何だっけな
SOC2 Type2みたいな
そういうのを取得するほうが多いんですよね
ISMSみたいなものがあんま取られてないような気がして
プライバシーマークとかは完全にドメスティックな資格だったりするんで
ちゃんと資格っていうところで学ぶんだったら
こういうグローバルで通用するものっていうのを取るのがいいのかなという気はしますね
意外なことにこの中にAWSの資格が入ってなかったのが面白いですね
AWSの資格ってどうなんでしょうね
転職するとかっていう意味では役立つと思いますし
AWSぐらいシェアが拡大しているところであれば
持っておくとこの人はそういうところは問題ないんだろうな
っていうふうに認知される可能性はあるかなと思いますね
では続いてデブレルネーム西から来た馬面の男さんですね
いつもありがとうございます
キャリアの幅深さを広げられるようなスキルセットは何になるでしょうかというテーマでお便りします
その中で関心が出た分野を掘り下げてみるのがいいかもしれません
あと受け身で言われた仕事でも何かしら興味が持っている分野であれば
その分野をやってみるとかと
エリゴの見せずにやっていくうちにキャリアの幅が広がっているかもしれません
あとはキャリアは掛け算というので
例えばAWSかけるオンプレとかAWSかけるGoogleクラウドみたいな掛け合わせるといいかもしれないですね
私はインフラエンジニアかける採用採用かける採用広報みたいな感じで
気がついたら掛け合わせをしている感じになっていました
お便り遅くなってすみませんということですね
ありがとうございます
関心が出たここですよね
関心が出た分野をどこに持っていくかというところで
採用ね
採用もかなりAIに食われている分かなっていう気は個人的にしてますね
最近どこのサービスだったか忘れましたけど
一時面接をAIがやってくれるサービスがあるんですよね
それのメリットっていうのが
受ける方
採用を受ける方がある意味いつでも受けれるんですよね
自分の自宅であったりとか
好きな時間に面接を受けられるっていうところがあって
大抵会社員で転職活動しようと思った時って
前の会社をやめてから転職活動するでもいいですけど
やっぱりちょっと怖い部分があるんで
私とかもそうでしたけど
前の会社に勤めながら面接に行ったりすると思うんですよね
その時に普段スーツとか着ないような仕事があったりすると
スーツをどっかにロッカーとかに入れとかなきゃいけないとか
普段は帰らないような時間で帰らなきゃいけないとか
そういうのがあったりしてあいつ動きが怪しいなって
思われちゃうと思うんですよね
その意味で少なくとも一時面接とかは
このAIとかで動画でできますみたいになっていると
結構心理的な障壁は低いと思うんですよね
あとはその何でしたっけ
なんとかレターオファーレターみたいなものとかが
割と昔ってばらまき系が多かったかなっていう気はしてて
自分には全然ミスマッチと思えるような
メールとかもバンバン送られてくるみたいな感じがあったかなと思うんですけど
そのあたりってAIとかで情報収集したりとかして
より最適なマッチングみたいな感じでメールを送ってくれると
それは双方にとって採用側も採用される側にとっても
いいのかなっていう気がしてるんですよね
なので結構最近採用周りっていうのは
AIに食われちゃってるっていう話を聞いているので
この西から来た馬面のお父さんが
どこに人間の付加価値みたいなものを出していくのかっていうのは
非常に気になるところではありますね
というところでですね
デブレル会議の案内
今日はジャニーマンさんと西から来た馬面のお父さんのご意見
紹介しましたというところでお二人ありがとうございます
ではですね最後イベントのご案内です
DevRel会議2025ですね
こちら10月の2日から4日ですね
3日間で開催をいたしますと
2日はですねワークショップデーっていうところで
豪一杯使ってDevRelに関する内容とか
開発者コミュニティとか
あと登壇全般とか
あとテックブログとかですね
そういった内容を学べるワークショップデーとなっております
2日目と3日目はですね
セッションがメインの日となっていて
基本的には2日目はビジネスマーケティングデーっていうところで
企業に関するようなチーム管理とか
マーケティングとかの内容がメインのセッション
4日は土曜日ですね
土曜日はデベロッパーコミュニティデーっていうところで
開発者の個人の体験であったりとか
あとコミュニティとかに関するようなセッションが提供されると
いった内容になっております
ぜひですね
チケットはもうすでに発売しておりますので
ぜひご購入の上ですね
参加いただきたいと思っておりますと
あとですね
Linux Foundationですね
Linux Foundation Japanのほうから
ほうともですね連携して
ANAっていうヨーロッパのほうのですね
担当している方に来日してもらったりとか
あともうお一人ですね
LFXっていうLinux Foundationが提供している
オープンソースプロジェクト管理ツールがあるんですけれども
そちらのワークショップをですね
4日開催する予定となっているので
ぜひですねそちらも参加いただけると
嬉しいですというところになっております
はいというところで
本日のですねデブレルラジオ232回目
エンジニアのキャリアを広げるスキルといったテーマ
こちらで終了していきます
そうだ今日はあれでしたね
オープニングでデブレル会議の
オープニングをちょっと流してみたんですけれども
このクローズもですね
5秒なんですけれども
そちらの動画流して終わりたいと思います
はいではまた皆さん来週お会いしましょう
さよなら
