00:06
皆さんお疲れ様です。
皆さんお疲れ様です。DevRelラジオの今日は、235回目ですね。やっていきたいと思います。
まず最初にですね、DevRelラジオのご紹介からですね。
DevRelラジオは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間程度お送りしているというものになります。
DevRelというのはですね、デベロッパーリレーションズの略で、
自社とか社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoでもですね、そんなDevRelに関わるような方々、
例えばテクノロジーエヴァンデリストとかコミュニティマネージャーですね、
あとはデベロッパーアドボケイトとか、そういった方々が集まって情報交換したりとか、
イベントをやっているというコミュニティになっております。
公式サイトがありまして、DevRel.Tokyoというサイトですね。
普段はSharpDevRelJPという、ごめんなさい、そちらからスラップに参加できますので、
ぜひDevRelに関わっているとか、DevRelに興味があるという方はそちらに入っていただければと思います。
あとは公式のXアカウントがあります。
atDevRelTokyoというアカウントで、普段はSharpDevRelJPというハッシュタグをつけてですね、
ポストしてますので、ぜひそちら見ていただけるといいかなと思います。
というところで、あとはですね、公式のYouTubeチャンネルとかありますので、
XとかYouTubeチャンネル、ぜひですね、チャンネル登録したりとか高評価いただけると嬉しいです。
というところで、すいません、ちょっとですね、ドタバサになってしまって、
ギリギリになってこのライブのURL作ったりしていたんで、
今日はちょっと別な場所というところもあってですね、
ちょっとトラブリながらやっております。
カンファレンスご飯の思い出
まずですね、今日はメイントピックがカンファレンスご飯の思い出2となっております。
なんで2かというと、先週ですね、ライブじゃなくてレコーディングにしたんですよね。
レコーディングだとちょっと早くレコードしているというところがあってですね、
結果見事にコメントが何も来ていないというところで、
そのままなければですね、別に何も問題なかったんですけど、
その後見たらですね、いくつかコメントを寄せていただいていたというところで、
それだったらせっかくなんで、そのまま同じテーマでいこうかなというところで、
カンファレンスご飯の思い出となっております。
私の思い出なんだろうな。
デブレルコンロンドンの一番最初、つまり多分2015かな。
デブレルコンロンドン2015の時のランチボックスみたいなやつが本当においしくなくて、
あれは思い出に残っているというか、記憶に残ってますね。
イギリスってあんまご飯がおいしくないってよく言われることがあって、
そんなに期待はしてなかったんですよね。
ただイングリッシュブレックファーストがおいしくって、
別にそんなイギリスのご飯悪くないじゃんとか思って、
お昼とかも無理にイギリスのご飯食べなければ、
中華とかもあるんで、マックとかもあるんで、
そういうの食べればいいとか思ってたんで。
そんな中、カンファレンスで出たランチボックスの絵も言われぬおいしくなかったこと。
あれはなかなかすごかったですね。
おいしいカンファレンスご飯よりもおいしくないカンファレンスご飯のほうが
思い出に残っているってちょっと残念な気もするんですけど。
食事の質とトラブル
あとはね、これもDevRelConだな。
DevRelConのSUZU、ソ州ですね。
日本語で言うとソ州っていうところのDevRelConがあって、
その時はソ州の大学でやったんですよね。
なんていう大学かちょっともう覚えてないですけど。
お昼もその大学のランチが食べれるっていうシステムだったんですけど、
学生に混じってお盆持って行かなきゃいけないんです。
目の前に作ってる人がいて、指差したりとかしながら、
撮ってもらうんですけど、なかなか中国語わかんないし、
向こうは英語もわかんないし日本語もわかんないしみたいな状態でやってて、
結局あんまり欲しいものがもらえずに終わったような、
どれがおいしいのかもよくわからないままに適当に指差して食べて、
こんなもんかみたいな、そんなような思い出がありますね。
それもいい思い出じゃないですね。
いい思い出。いい思い出なかったかな。全然覚えてないな。
そんなリッチなカンファレンスに行かないせいかもしれないですね。
というところで、ぜひ皆さんのいい方の思い出、
後ほど取り上げていきたいと思いますので、
カンファレンスのご飯に関する思い出ですね。
ぜひご要請いただければと思っております。
あとあれだな、デブレルコイン横浜の時のスピーカースポンサーディナーの超激込みの、
あれはひどかったですね。
あれは自ら場所を選んでて言うのも大変心苦しいんですけど、
あれはひどかったですよね。
今だから言えますけど、そんな安くないんですよ、あの店。
しかも現金オンリーみたいな感じで、
割ともう次は利用したくないなっていうようなお店だったんですけど、
なのにめちゃくちゃ混んでて、めちゃくちゃ狭くて、
すっごい大変だった思い出がありますね。
あれは私が選択したんで、私の責任なんですけど、
いや、なかなか大変でしたね。
カンファレンスご飯に関する話題は、この後6時過ぎぐらいからやっていこうかなと思いますんで、
ぜひ今のうちにコンパスのページから、
そちらのコメントいただけると嬉しいなと思っております。
DevRelの最近の動向
それまでは最近のDevRelに関するところの話題を取り上げていこうかなと思うんですけれども、
まず、私が最近頑張っているRedditからいきましょうかね。
確かこれコメントしたかな。
フルスタックエンジニアからDevRelエンジニアに転職するという方が、
CTOインタビューでどういうふうにやったらいいかみたいな質問が来ていました。
フルスタックエンジニアからDevRelエンジニアインタビューwith CTO for Open Source AI Startup
How can I prepare?というところで、どんな用意をしたらいいでしょうかという質問が来ておりました。
それに対してですね、まずバックグラウンドから言うと、
この方は近々CTOとの面接のインタビューが控えているというところで、
受けるところがオープンソースのスタートアップで、
エージェンティックAIにフォーカスしているプロダクトだということですね。
この方は元々経歴としてはフルスタックエンジニアで、
そういうバックエンドとかインフラ周りとか、
あとはWebスタックとかにも関わってきたということで、
CTOとの30分の面接ではどういった質問がされるというところを考えればいいかと。
あとはフルスタックの経歴をどう活かせばDevRelで成功できるだろうか。
3つ目がCTOの印象に残るような、
オープンソースとコミュニティ重視の会社であることを示すにはどんな方法がありますか。
あとはAIエージェント関連のオープンソースプロジェクトについて、
何か具体的なアドバイスはありますか。
この最後の2つぐらいは微妙かもしれないですけれども、
そのCTOと30分面接するというところで、
どんな質問をされる想定だったりとか、
どういうふうな回答をすればいいのかっていう話で、
これってもともとDevRelに関わってますみたいな、
そういうエヴァンジリストの経験とかアドボケイトの経験がある人だったら、
そんな問題ないと思うんですけど、
みんなはみんなそういうわけじゃなくて、
どっちかというと、もともとエンジニアをやっていて、
その中からコミュニティとかに関わり始めたりとかして、
そういうDevRelっていう道があるんだっていうのを知り、
そういう求人があるからそこにジョインしてみるっていう方の方が、
どっちかというと多いと思うんですよね。
これからDevRelやりますっていう人ですね。
そういった方が面接でどういったポイントを 注意すればいいかというところだったんですけど、
まず私の回答としてはですね、
その会社、エージェンティックAIをやっているその会社が、
どんな開発者をターゲットにしているのかっていうのを、
ちょっと深掘りした方がいいのかなと思っていて、
その中でこういうエンジニアですっていうのが絞り込めればですね、
そこに対して自分のフルスタックの経験がどう役立つかっていうのを、
見つけられると思うんですよね。
開発者みたいにバーンみたいな感じですごい幅広いと、
ちょっとどういうふうにやればいいのかっていうところもわからず、
焦点がぼやけてしまうかなと思うんで、
そこが大事じゃないですかというところと、
あとは会社としてどういうKPIを追跡しているのか、
どういうKPIを持っているのかっていうのを、
確認した方がいいということを説明しましたと。
あとはどのぐらいのタイムスパンでそれを達成したいって考えているのか、
っていうところの擦り合わせがちゃんとできていないと、
短い期間で大きい成果を出そうと思ったら、
やっぱりそれなりの予算であったりとか、
それなりの体制が構えられていないと難しいと思いますし、
逆にすごく長いスパンで考えてくれてるんだったら、
結構腰を背て取り掛かれるかもしれないし、
そんな大きい予算はいらない可能性があると思うんですよね。
DevRelでいろんな会社さんを手伝いしてて思うところとしては、
我々がエヴァンジリストとかアドボケイトとかっていう存在がいたとしても、
その人だけで解決できる問題ってそんな多くないんですよね。
チームメンバーとかも人的なリソースもそうですし、
あとはお金とかもそれなりに予算が積まれていないと、
そもそも出張もいけないし、
カンファレンスにブースも出せないし、
何かスポンサーすることもできないみたいな感じになって、
何すればいいの状態になる可能性は大きいと思うんですよね。
あらかじめ予算が決まっていれば一番いいと思うんですけれども、
そうじゃなかった場合にエヴァンジリストとかアドボケイトとか
コミュニティマネージャーみたいな人が入ったから、
もうこれでオロケみたいに思われちゃうと結構しんどいのかなという気はしてます。
なのでそのKPIの部分、どういう成果が求められているのか、
それに対して自分がどういうふうにコミットできるのかっていうのを
検討する必要があるかなと思ってますね。
あともう一人ですね、回答してる人がいて、
ジミニーにCTOの役を演じてもらうっていうことが書いてあるんですけれども、
これね、最近若干増えているというか、
ビジネスインタビューサービスがいくつかあると思うんですけど、
それをチャットGPTに代わってもらうみたいなやつがあるんですよね。
そういうやり方があるっていうか。
ペルソナを細かく設定して、
チャットGPTにその役になって私との会話を行ってくださいみたいな、
そういうことを言うと、それっぽいこと返してくれるんですけど、
基本的にネガティブなこと返ってこないんですよね。
ある意味、こっち側が理想としているペルソナでしかなくて、
予想外の答えも返ってこないし、
新しい道が開けるような感じにもなりづらいんですよね。
そこはAIだとなかなか難しいというか、
AIって基本的にネガティブな情報を出す備えですよね、LLMって。
トレーニングするときの評価ポイントとして、
オンボーディングバディの紹介
基本的にポジティブなほうが評点が高いっていうところがあるんで、
そうすると基本的に分かりませんみたいなことは言わないですし、
とりあえず何でもいいから答えを出しがちですし、
こっち側がはいかいいえで求めるようなものだったら、
なるべくはいって答えたほうがポジティブな傾向があるので、
誘導尋問的になってしまうっていうところがあるんですよね。
ビジネスインタビューサービスも結構難しいなとは思うんですけど、
そういうアンケートの仕方、聞き方っていうところが、
AIを使う、このジミニにCTを役演じてもらうっていうね、
これはそんなに意味があるのかなっていうのはちょっと分からないですね。
これは多分この間も取り上げたからいいのかな。
Linuxはそうですね、そんなとこかな。
スタートアップの創業者としてのデブレルにどう取り組めばいいかみたいな質問が来てるんですけど、
ちょっと大雑把すぎてアドバイスが難しいよって言われてましたね。
ちょっとしたサービスで、
私これ知らなかったんですけど、
オンボーディングバディっていうサービスがベータリリースされています。
面白いですよね。
オンボーディングの一緒に解決してくれるみたいなやつなんですかね。
オンボーディングの時間を節約できるサービスです。
特にその顧客のオンボーディング、
自社っていうよりは顧客のオンボーディング体験を合理化してくれる、
最適化してくれるサービスということですね。
全部で3つAPIがあって、
まずValidation APIっていうのを使って、
これはメールアドレス、携帯電話、ユーザーエージェント、IPアドレスなどをチェックできるAPI。
あとは、
難しいな。
Sanction APIとかFile Storage API。
これはどういうふうにオンボーディングにつながるんだろうか。
全然情報が出てこないな。
多分、オンボーディングのステータスとかを取れるんだと思うんですよね。
面白いなと思ったんだけど、ちょっと違うのかな。
ぜひ気になる方がいらっしゃったら、
このオンボーディングバディですね。
こちら見てみてくださいというとこです。
テクニカルライターの役割
一応DevRelの文脈で上がってたんですけどね。
では別のやつに行きます。
これはDev.toの記事ですね。
Why Every Engineering Team Needs a Technical Writerということで、
なんで全てのエンジニアリングチームにテクニカルライターが必要なのかという記事になっております。
個人的にはですね、文章を書くの大事だし好きだと思っているんで、
こういうテクニカルライターっていうのはですね、
どんなチームにもいてほしいなとは思うんですけど、
どうなんでしょうね。
いないチームの方が多いような気はするんですけど、
テクニカルライターはどのような仕事かというところで、
ドキュメントを整備するだけの仕事ではないよということですね。
優れたテクニカルライターは単にドキュメントを書くだけではない。
摩擦を減らし、開発者の速度を高め、チームの集合値を維持すると。
開発者の精神的負担を軽減すると。
確かに相当読みづらい文章とかだとストレスを感じることはありますけどね。
オンボーディングの苦痛を軽減できると。
このサービスが何をするものなのかとか、APIの仕様はどうなっているのかとか、
なんでこんな構造になっているのかみたいな。
そういった新しく入られた方が同じような質問をすると思うんですけれども、
そういったところの質問を構造化し、再利用可能な形に変えていくということですね。
このあたりQAと組み合わせた方がいいと思うんですよね。
割と私が普通の会社員だったときに、ドキュメントとかたくさん書くんですけど、
やっぱり全部読まないんですよね。
かつ全部読んで100%理解するっていうのも無理なので、
そこに書いてあるはずなのにっていうところ、
ただその読み方が前提知識がある状態で読むのと、
前提知識が全然ない状態で読むので、全然その印象とかキャッチアップする部分が変わるので、
そうすると書いた方としては書いたはずなのにって思いつつ、
読んでる方はどこにもそういうのがないので聞かなきゃ無理だみたいな感じで聞くっていう、
そういうのが多いと思うんですよね。
それが積み重なると書いてる人たちもすごいやる気がなくなっちゃうので、
私は割とQA形式で聞いてもらう方がいいかなとは思ってるんですけど、
ただQAの難しいところってどう聞けばいいか分からないっていう、
分からないところが分からない状態になると聞きようがなくなって、
参考にすべきドキュメントもすごいプワで、
そうするともうどうしたらいいのみたいなお手上げ状態になっちゃうんですよね。
なのでバランスですよね。
ドキュメントあんまり詳しく書きすぎて、
このドキュメントを100%理解しなかったら質問しちゃダメみたいな雰囲気にするのも良くないと思いますし、
逆にドキュメントを書かなすぎて最初の取っ掛かりすらないみたいなのも良くないかなと思いますね。
この間、バイコンJPの広島に行って、
いろんな開発者の人とお話ししてたんですけど、
一番最初にAIにコードを書いてもらうときに、
期待したものじゃない状態で上がってくる時もあると思うんですよね。
それって何が原因なのかっていうと、
基本的に最初のインプットが足りないっていうところになってくると思うんですね。
社内の暗黙地みたいな感じのものだったりとか、
開発者だったら、このディレクトリ構成を見たら、
どこに自分がモデルを追加すればいいのかとか、
どういうマイグレーションファイルを置けばいいのかみたいなのが分かるっていう、
そういうドキュメントにはない匂いみたいなものを、
どこまでドキュメント化するか、
ちゃんと共有できる形の知識として作り上げるかっていうのが、
大事になってくると思うんですよね。
それを一個一個思いつくままに、
ドキュメントにしていくのもいいっちゃいいんだけど、
なかなか難しい、特に大きい、
もう既に動いてずっと運用しているようなシステムの場合、
それに慣れている人たちは何も気にせず作れるようになったりとかするので、
なかなか難しいところはあると思うんですが、
それでもAIのagent.mdとかcrawl.mdとかが、
AIだけではなくて、人間も分かるようにドキュメント化しておくと、
もともとマークダウンなんで人が読みやすいっていうところがあるんですけど、
人が読みやすい形式っていうところを意識してあげると、
それはオンボーディングの資料としても使えるみたいな感じになっていくんじゃないかなっていう話をしてました。
なので、AIオーディングエージェント向けみたいなドキュメントとかも、
意外と回り回って人間にも役立つって感じになっていくんじゃないかと。
そんな中で多分足りない仕様とかもいっぱいあるので、
そういったところをQ&Aみたいな形で質問してもらって、
それに対してシニアとか先輩のエンジニアが答えて、
そのQに対してのAっていうのを、今度それをドキュメントにしていくっていう、
そのプロセスが大事になってくるんじゃないかなと思うんですよね。
Slackとかがそういうのに使われたりもするんですけど、
Slackのインターフェースで情報をストックするのってなかなか難しい気がするんですよね。
私とか唯一、大事なURLだけはとりあえずブックマーカー、リードレイターみたいな、
そこだけつけとく。
それ以外だと本当に流れちゃってて、検索とか使うんですけど、
何も検索もいい結果返ってこないなっていう気がしてますし、
日本語の検索って結構難しかったりしますんで、
あんまりチャットだとうまくいかない気がしてますね。
Q&Aの場所を立てて、
質問が来たらそれをSlackに通知するみたいな仕組みは必要かなって思うんですけど、
ただSlackの中で質問して答えるだけだと、
また同じ質問が来る可能性が含まれてしまうんじゃないかなって思ったりしますね。
そういったところでテクニカルライターの人がやり取りされた内容とかもベースにしながら、
ドキュメントをうまく作っていくことができれば、
オンボーディングの苦痛を軽減させられるんじゃないかなというところですね。
これも回り回ってシニアエンジニアの時間を奪うことなく、
新しいエンジニアの方がより早く成長し、
知識が足りないがためにブロックされることも少なくなり、
より早く自信を持てるようになるというふうに書かれてますね。
難しいですけど、確かにテクニカルライターはこういう動きをしてくれるといいですよね。
システムの歴史とドキュメントの重要性
あとはチームのコミュニケーションを助けるのがテクニカルライターの役割である。
コードは機械のため、ドキュメントは人間のためだ。
あなたのチームは今日もコードを書くが、人々は何年もドキュメントを読む。
優秀なテクニカルライターはスラックのもつれたスレッドとか、
文書化されていない設計上の決定事項、
あとはチーム内のクローズドな知識をアーキテクチャの概要、統合概要、意思決定ログなど、
チーム全体が使用できるきれいで検索可能な文書に変える。
そういうことですね。
単純にドキュメントを書くだけではなくて、スラックでやり取りされていることとか、
あとはミーティングの中で話した決定事項とか、
そういうのをドキュメントに落とし込んで、
ちゃんと構造化された状態の検索ができる形にするというところが役割になってくるということですね。
テクニカルライターはエンジニアと非エンジニアの橋渡し役でもあると。
例えばプロダクトマネージャー、サポートスタッフ、QAテスター、
そしてさらに顧客でさえも、彼らはみんな何らかの形でシステムに接していると。
ただ彼らはコードを読まない。それはそうですよね。
基本的に動いているシステムだけを見ますよね。
テクニカルライターはそういった意味で、開発者と開発者以外の間に共通言語を生み出す。
この連携が実現すると、プロジェクトが円滑に進み、
フィードバックループが短縮され、ハンドオフが混乱なく行われるようになるということですね。
次が技術的な仕事を長続きさせると。
人は去っていきますし、システムの格改も起きますし、チームは進化していくものだと。
残るものは、去ってしまった後に、残るものはビルドの背後にある理由であると。
これは確かにありますよね。
長い歴史の中で、何でこんなシステムになっているの?みたいな時ってあると思うんですよね。
ただ、それって何の理由もなく起こったわけではなくて、
もともと何かの理由があって、そこに対して決定されていったという歴史の部分ですよね。
テクニカルライターはシステムを単純にドキュメント化するだけではなくて、
その記録の部分も残していかないといけないということですね。
手戻り少なく、手直しが早く終わり、長期的な判断をしやすくするということですね。
確かに、これって作り直した方が早いじゃん、みたいなケースも割とよくあるんですけど、
本当に作り直そうとするとすっごい時間がかかるんで、
そこの歴史の部分を正しく理解していくことによって、
そもそも作り直さないという判断もできるかもしれないですし、
そういったパターンもあるのかっていうのを認識しながら、
システムの使用を決めるみたいなこともできますよね。
ちっちゃいチームではミスコミュニケーションをするような余裕はありません。
テクニカルライターの役割
混乱することなく明瞭に迅速に行動しなければいけない。
また、毎週同じ質問に答え続ける余裕もないと。
パートタイムだったりとか、組み込みのテクニカルライターでも、
テクニカルライター自身がパートタイムであったとしても、
ドキュメントをうまく書くことによって、
いない場合といる場合で大きな違いを生み出すことができると。
ドキュメンテーションはインフラであると書いてありますね。
スタートアップの規模を拡大するにしても、
成熟したシステムを管理するにしても、
明確なドキュメンテーションは必要不可欠でなく、インフラなどだと。
優秀なテクニカルライターはチームのペースを落としません。
苦労していた知識を保持します。
システムを理解しやすく、使いやすく、保守しやすくします。
いや、面白いですね。
こういうドキュメントを書くとか、
ドキュメントを整備するのがテクニカルライターの役割かなと思ったんですけど、
意外と拾ってくる部分も割と多い気がしますね。
システムのミーティングのレベルから決まったことから要件をドキュメントにして、
それがちゃんとシステムに反映されているかっていうのを確認したりとか、
そういったところの何でそういう欠点につながったのかっていうところも含めて、
ちゃんとドキュメントにしていくっていうのが、
テクニカルライターの仕事なのかなと思いますね。
ちなみにこれはサンドラメ・シャックさんという方ですね。
ヨーク大学の出身の方で、
科学計算とマシンラーニングの経験を持つソフトウェアエンジニアですというところですね。
面白いですね。
でもテクニカルライターはソフトウェアエンジニアリングの知識があった方がいいのは確かですよね。
ソースコードを追いかけて細かく見ていくかっていうのはちょっとわからないですけれども、
そうではなかったとしてもシステムの動作を見るのに、
完全にブラックボックスで何をやっているのかわからんみたいな状態とか、
技術用語の部分が正しくわかっていない状態だとなかなか難しい仕事なのかなという気はしますね。
それでいくと、
ジュニアのエンジニアとかシニアのエンジニアとかの次のステップぐらいにあってもいいのかもしれないですね。
コーディングをするっていう仕事ではなく、
もうちょっと広い視点でシステム全体を見つつ、
自分が今まで開発してきたものもそうですし、
新しいシステムに対してもドキュメント化していくみたいな、
そういう役割っていうところも面白いかもしれないですね。
ということで、続いてはメインテーマのほうですね。
デブレルコンの食事
カンパレンスご飯の思い出2というところで。
ではまずさいしょう。
デブレルネームジャーニーマンさんですね。
いつもありがとうございます。
思い出に残るカンパレンスのご飯、
デブレルコンのシューマイ弁当ですねと。
素晴らしいチョイスでした。
非常に人気があり、最初に完売した気がします。
マイセンミニバーガーや他の弁当もいいのですが、
開催地に目指した食事はカンパレンス遠征の醍醐味ではないでしょうかと。
デブレル会議の登壇参加楽しみにしています。
いただきました。
ありがとうございます。
そうですね、これはたぶん2023のことですかね。
デブレルコンの横浜のときかなと思うんですけれども。
横浜なんでシューマイ弁当を用意したというところですね。
お弁当本当に難しいんですよね。
もう何でしょうね。
何が食べたいのか全然わからない。
一番最初にやったカンパレンスからわかってないですね。
デブレルコンの東京の2018かな。
17?17だったかな。
あのときもお寿司がちょっと入ったような弁当を用意したんですよね。
そっちはめちゃくちゃ人気で。
てっきりどっちかっていうと、
お寿司系ってお魚とかであんまこってりじゃないじゃないですか。
さっぱり系かなと思うんですけど。
なのでハンバーグ弁当とかそういうこってり系が好きな人の方が多いんじゃないかと思って発注したら
全然開けてみたら逆だった。
ありましたね。
正直みんな何が食べたいか全然わからないですね。
そうですね。シューマイベート喜んでもらえて良かったですね。
さくたろうさんからコメントきてますね。
こんばんは。ケータリングの手配が一番大変ですよね。
そうなんですよね。
これが難しくてね。
私は運営メンバーの分投げてるんですけど、
お一人ですね。そういうお弁当の手配、食べ物の手配に関してはスペシャリストがいてですね。
その方にお任せしているっていうのがあるんですけど、
ちょっと面白いのが、今回のDevRel会議にドンっていう方が来るんですね。
ドングッドマン。
ドンは私すごく仲良くしていて、
先週の火曜日お休みだったんで、
私はラジオレコーディングにして、
ドンと一杯遊んでたんですよ。
その時にドンがお土産を買いたいと言って、
一番最初にDevRelコンに来た時に食べたチーズなんとかみたいなのが良かったんだよ。
あれを買っていきたいんだよって言ってて、
僕は全然そんなの覚えてないというか、
そのチョイスは僕はしたわけじゃないので、
全然覚えてなかったんですけど、
東京チーズファクトリーだったかな。
確か。
それがめっちゃ美味しかったらしいですね。
って言ってて、
それをこの間の運営ミーティングの時に、
いつも手配してくれている人に伝えたんですね。
ドンがそれがめっちゃ美味いって言ってたから、
だから今回もそれ用意しようかって言ったら、
全然不評っていうか、
全然手つけられてなかったらしいんですよ。
本人的にはそれを用意したらトラウマになってたみたいで、
どうしようかなーみたいな感じだったんですけど、
リベンジとしてもう一回やってみようって言って、
それを用意するんだったんだけど、
オンライン注文できなかったんだよな。
それ共有してなかったな。
それを用意したいんですけどね。
わからなくもないんですよ。
日本でコンファレンスやりますって言って、
目の前に食べ物を用意してもらってたら、
大体日本人だったらこういう味なんだろうなっていうところで、
手つけられるものもありますけど、
例えば私はインドに行きましたって言って、
インドで目の前にインドのお菓子とか用意されてても、
それがヒンドゥ語とかで書かれてたら、
なかなか手出ししづらいと思うんですよね。
なんだかわからないからちょっと控えちゃうみたいな。
食べたら美味しいのかもしれないけど、
開けたら全部食べなきゃいけなくて、
もし万が一美味しくなかったらやだなーみたいな感じになるかなと。
いう気がするんですよね。
なのできちんとこれがどういう食べ物なのかっていうのを説明しないと、
手出ししづらいのかなという気はしてますね。
なので今回リベンジをぜひやりたいなと思ってますね。
もう一つ作太郎さんからコメントきてますね。
海外カンファレンスの思い出
最近はインフレの影響で食事が高等化してつらいですと。
そうですね。
そうですね。
インフレはしょうがないと思うんですよ、正直。
インフレって言うとちょっとあれですね。
食事が高等化したときに食事が高等化して、
食事が高等化したときに食事が高等化したときに食事が高等化して、
こういう状態になるかというと、
アメリカのUSDOFがすげー高くて、この間のデブリルトンのニューヨークの時とか、本当に移動するのも嫌になるくらい高いみたいな感じに感じたりとか
シンガポールとかもそうですよね、めちゃくちゃ高く感じるようになってきてたりとか
シンガポールの真ん中にあるコワーキングスペースがあって
そこを日本の会社がやってるんですよ、なので中の人とか日本語が喋れる人なんですけど
そこはね、1日ドロップインで使うと30シンガポールドルとかして
それは多分ね、5000円超えるくらいなんですよね
あれはね、なかなか8時間もいないかな、6時間くらいで5000円かみたいな感じで
すごい円が弱くなってるっていうのを思い知るんですけど
インフレが良くないっていうよりは給与が上がってないのがやるせないなって思いますね
給与が上がってればそんなに気にしないと思うんですよ、食べ物が上がってて
デブレル東京もそうですけど、1回の食事、昔は1000円いただいて食事を提供したりとかできてましたけど
今は無理ですよね、1000円じゃとても食べれない
飲み物だけだと逆にちょっと貰いすぎみたいな感じかなと思いますよね
では続いてですね、デブレルネームtkizawaさんですね
ありがとうございます、お久しぶりですね
最初に海外カンファレンスに参加したのは2017年のVMworld
アメリカメシの衝撃を受けたのもこの時でした
全く出汁の入ってない味噌汁や朝から甘く重いマフィンなど色々ありますが
未だに疑問なのがランチボックスに入っているリンゴ丸ごと1個です
そのままかじるんですよねきっと
今では年1回海外に行く機会がありますが何が出てきても慣れてしまいましたということですね
これは本当はアメリカのランチボックスですね
リンゴ丸ごと1個勘弁してほしいですよね
歯に何かあったらどうしてくれるんだって思ったりしますけど
あとは出汁の入ってない味噌汁
いやー、そうですね
あまり海外行って食事を期待する機会ってそんな多くない気はするんですよね
食事が美味しい国ってシンガポールぐらいしか
シンガポールとあとポルトガルとかイタリアとかぐらいかな
フランスとかもお金払えば美味しいもの食べれますけど
そこそこの料金ぐらいだとあんま美味しくないイメージはありますかね
逆にイタリアとかはそんなに高くなく行けますし
ポルトガルも魚介とかが多くてそんなに払わない感じですね
他の国は本当にそもそも食事期待して行くみたいなのは難しいですよね
アメリカとかもイギリスとかもね
そうですねーリンゴ丸ごと1個やるなー
せめて皮剥いてほしいけど皮剥いたらきっとこう
サビついちゃうというか参加しちゃうんでやらないんでしょうね
アメリカはこの間のデブレルコンニューヨークは
ラップサンドかなんかだったような気がしますね
アルミホイルかなんかに包まれた状態で自分でピックアップして食べるような感じですね
あとサラダもあったかな
そんなに悪いっていう感じではなかったですね
サンフランシスコは覚えてないな
ではですね続いてデブレルネーム西から来た馬面の男さんですね
いつもありがとうございます
今週のテーマはカンファレンスご飯の思い出ということでお便りします
ジョードデイズ2019コタンダTOC
懐かしい
が会場で満館全席がテーマだったと記憶しています
これあったね
キッチンカーが来ていて会場をちょっと出たところの屋外の駐車場か何かで食べたのが思い出に残っています
外でかつキッチンカーでできたての食事をいただく体験並ぶ行列でも会話が弾んでいましたねと
数々のカンファレンスで食事をいただきましたがユニークな思い出として残っています
カンファレンスという少し日常から離れた場でコミュニティ仲間と食べた飯記憶に残っています
カンファレンス飯とは少し離れますが最近はコーヒーブレイクでホットコーヒーがいただけるのもありがたいです
あと遠方からの参加の方のお菓子のお土産が並べてあったりして感謝です
これも会話が弾みます
2つのエピソードを披露しましたが
ランチ体験の紹介
共産スポンサー様ランチスポンサー様主催のコミュニティ運命の皆さんへの感謝の気持ちも忘れないよう感謝していきたいと思います
今週は以上ですということですね
URL来てますね
この満館全席のランチについてですね
ランチの詳細についてはこちらで紹介します
今年はお弁当への本気度合いが違います
なぜならば満館全席だから
参加者の名札についているALB王様ランチボックスチケット
それは満館全席にふさわしくあなたの胃袋を満たす食べ物に交換できますということで
王様ランチボックスチケットっていうやつですね
これを不要な方は回収ボックスに入れて
それを他の人がまたお代わりに使えるということですね
まず一つ目がキッチンカーでチケットと交換で先着順に無料配布します
というのがコーヒーがあり
コーヒーだけじゃないのかな
粉カフェですね
カフェ類中心のやつ
あとは道というので
これは八王子ラーメン120食
混ぜ麺100食ということですね
あとは笑い豚
あとはお弁当、まいせん、マザー豪華一口カツと千魚のてりやき
ペキンハンテン
などなどというところでかなり豪華ですよね
確かにこういう何でしょうね
食事の出た数で後で料金請求してくれる方が
無駄にはならないですよね
提供側もプロの人たちなんで
計算してというか
そんなに無駄が出ないように作ってくれるかなと思うんで
そういった意味では
お弁当よりもこっちの方がいいなって思いつつ
ただ当然これはお高いので
なかなか上手UGぐらいしかできない方法かもしれないですね
こんな豚丼とかラーメンとか
なかなかすごいですよね
リッチですね
あとはなかったかな
あとはジャニーマンさんと西から来た馬面男さんは
もう一つずつ送ってもらってますね
でもジャニーマンさんは先ほどのシューマイ弁当の話で
西から来た馬面男さんはちょっと違いますね
こちらも読ませていただきます
エンジニア採用のフォークウェルさんがコロナも明けた頃
フォークウェル文化祭と対してテックカンファレンスをしていました
そこでお昼のランチに出たのがスパム握りでした
スカウトのスパムメール撲滅みたいな打ち出し方だったと記憶していますが
面白い取り組みだなと印象に残っています
ちょっとネタっぽいですがいい感じだった印象があります
そういえば今週はデブレル会議のスピーカーディナーがありますが
これも大変楽しみにしています
ありがとうございます
スパム握りおいしいですよね
ご飯がいちいちで1個食べるだけでかなりお腹いっぱいになってしまうという感じはありますよね
もうやってないですかね
このフォークウェル文化祭というのはね
ちょっとわからないですけれども
もしやっていればまたこういうのが出るかもしれないですね
スカウトメールのスパムメール撲滅って自虐的なネタでいいですね
デブレル会議の詳細
ではですね最後イベントのご案内です
デブレル会議2025ですね
もうあさってからか
そうですよね2347
あさってから始まります
あさってはですねワークショップデーなので
ワークショップをですね
大崎のところでやりますと
それは午後一杯ぐらい使ってですね
デブレルに関するところマーケティングの話とか
コミュニティの話とかですね
あとは登壇の話テックブログの話とかですね
そういったものを学べる時間というのをやります
これはカンファレンスの普通のセッションのフィーとは別でですね
いただく形となっています
あとはセッションですね
3日と4日金曜日と土曜日はセッション中心となっております
あと中ではですね
土曜日はパネルディスカッションが1個あったりとか
あとLinux Foundationさんからですね
LFXっていうプロダクトがあるんですけれども
そちらのワークショップですね
開催となっておりますので
ぜひですね参加者の方
そちら参加してみていただきたいなと思っております
そうですね
デブレル会議については
先ほども言った通り2日にですね
スピーカースポンサーディナーがあるんですけれども
今回は場所は広いので
そんな問題はなく滞りなく進むんじゃないかなというところですね
今続々とスピーカーの方が来日されてまして
コンテンツとかもですね準備進めておりますので
ぜひぜひ皆さんご参加いただければと思っております
このデブレル会議もですね
年に1回とかそのぐらいしかやりませんので
あとかつグローバルな形で
コミュニティだったりとかドキュメントとかですね
そういったあとは個人経験談ですね
自分がどういうふうにデブレルに入るようになったのかみたいな
そういった話とかも聞ける機会っていうのは
そんなに多くありませんので
ぜひですね参加いただいて
そのあたりの知見を獲得しつつですね
次の自分のキャリアに生かしていただければなと思っております
デブレル会議のURLも一応ポストしておきます
10月の2日から4日ですね
市街の方で開催をいたしますので
2日はさっき言った通り大崎ですね
チケットはですね全部バラバラで購入ができます
ワークショップだけとかですね
あとセッションだけ
あとはセッションとランチとか
セッションとアフターパーティーとかですね
そういう感じで分けて買うことができます
それはランチとかもね
残されるのはすごく残念なんですよね
それをなんとか減らしたい
無駄を減らしたいと思ってですね
ラッキーは別でアフターパーティーも別という形に
料金分けておりますので
ぜひご興味がある方は
購入いただければと思っております
ではですねまだあさって
3日間ですねデブレル会議直前となっておりますので
皆さんぜひぜひ会場でお会いできればなと思っております
そんなところかな今週は
ではですね今週はカンパレンスご飯の2回目
先週がレコーディングだったという関係で
2回目になってしまったんですけれども
また来週以降はですね
普段通りやっていければなと思っておりますので
また皆さん来週お会いしましょう
さよなら
