DevRel Tokyoの紹介
はい、皆さんお疲れ様です。DevRel Radioの201回目ですね、やっていきたいと思います。
まず、DevRel Radioの紹介ですね。DevRel Radioは、DevRel Tokyoというコミュニティでやっているインターネットラジオになります。
ファンの音、もし気になったらコメントいただければ消したいと思います。
DevRel Tokyoがやっているネットラジオになります。
毎週火曜日ですね、夕方5時半から1時間程度お送りしているというものになります。
DevRelというのはですね、Developer Relationsの略で、自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング処方となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、例えばテクノロジーエヴァンジェリストとか、デベロッパーアドボケイトとか、コミュニティマネージャーとかですね、
そういった方々が集まってイベントをやったりとか、コミュニケーションをしているといった、そんなコミュニティになっております。
DevRel Tokyoの公式サイトがあります。DevRel.Tokyoというサイトですね。
そちらからスラックに参加もできますので、DevRelに興味があるとかですね、DevRelに関わっているという方はぜひジョインいただければと思います。
そこまでじゃないよという方はですね、公式のアカウント、Xアカウントがあります。
アットデブレル東京というアカウントですね。普段はシャープデブレルJPというハッシュタグでポストをしていますので、そちらの方のハッシュタグを追っていただいたりとか、
あとはそのXアカウントの方ですね、ぜひフォローいただけると嬉しいですというところです。
仕事の息抜き方法
はい、ではですね、今日はメインテーマが仕事の息抜きとなっております。
リモートワークだとですね、よく言われるのが仕事の切り替えが難しいみたいな話があったりしますよね。
自宅で働いていたりとかして、もうすぐ横にベッドがあるみたいな状態だとですね、どうもプライベートの時間と仕事の時間がうまく切り替えられなくて大変みたいな話もあるかなと思うんですけれども、
そんな中でですね、皆さんがやっている息抜きがあればですね、ぜひお聞かせいただきたいと思っております。
個人的には何だろうな、結構働く体制はよく変えてるんですよね。
自宅というか、室のスペースがあるんですけど、そこの机は昇降デスクになってるので、気が向いたら立って仕事したりとか座って仕事したりとか。
あと下に無印の人をダメにするクッションがあるんで、そこで寝っ転がって仕事やったりとか、リビングのとこ行ってソファで仕事やったりとか。
あと最近はカフェで仕事することも増えている気がしますね。別にそんな意味があるわけじゃないんですけど、
ちょっと集中してとか、ちょっと気分変えて仕事したいなっていうときに歩いて10分ぐらいですかね、そこらぐらいのカフェ行って、
そこで集中して仕事して、帰りにジムで体動かしてから帰るみたいな、そういうことはよくやってますね。
そのあたりかな、たぶん息抜き、あと何かあるかな。
取り立ててこれみたいなものってあんまりないんですけど、皆さんも自分がやっている息抜きありましたら、ぜひ今のうちにコメントを寄せくださいというところで、
コメントのフォームはですね、ここで流せばいいんですよね。
コメントのフォームはGoogleフォームでいつもやってまして、
どういうふうにテンプレート作っておけばよかったんですけど、
これコメント流すと、Xに流せないのか。
テーマは仕事の息抜きですね。
これをとりあえずXとYouTubeのほうは流しましたと。
あとXのほうもですね、流しましたので、ぜひ皆さんのコメントのほうをお待ちしております。
小田翔さんからコメント来てますね。
もはや息抜きしかしてないけんと。
大嘘って書いてありますけど。
そうですね。仕事はちゃんとしたほうがいいと思います。
社会人ですから。
その話題はですね、6時過ぎ、あと30分後ぐらいですかね。
取り上げていこうかなと思うので、
求人情報とMongoDBの取り組み
それまではですね、最近のDevRel周りの記事とかを取り上げていこうかなと思うんですけど、
昨日ね、DevRel東京のスラックのほうで、
最近の求人案件をちょっと流してみたんですよ。
なんとなくフラッと気が向いてですね。
テクノロジーエヴァンジリスト、技術的なエヴァンジリストですね、
の求人が割と最近増えているっぽいんですよ。
例えば、エヴァンジリストだけじゃないかな、アドボケイトもですけど、
ジャパンでですね、スノーフレークのリードデベロッパーアドボケイトが募集されてたりとか、
あとですね、データドックのテクニカルアカウントマネージャーとか、
あとプライムナンバー、プライムナンバーのエヴァンジリストとか、
あとはコミューンっていう、確かこれコミュニティの
なんかのサービスを提供されてるかなと思うんですけど、
そこのチーフエヴァンジリストとか、
あとはクライス&カンパニーっていうところのエヴァンジリスト、
違うかな、ごめんなさい。これは違うな。
そこは求人サイトの名前だったかも。
サンアステリスク、アステリスク、アスタリスク、サンアスタリスクですね。
のエヴァンジリストとか、
あとはですね、ランドスタッドジャパンっていうところのチーフエヴァンジリスト、
Amazonテクニカルアカウントマネージャーとか、
あとさっき言いましたね、スノーフレーク2つ目、
あとオープンAIですね、オープンAIのデベロッパードボケイトとか、
IOVラボのデベロッパードボケイトとか、
ミラティブっていうところのテックコミュニティマネージャー、
このテックコミュニティマネージャーっていうのはわからないんですけど、
などなどですね。
パッと探した感じでも、わりと求人増えてきているっぽい気がします。
フルリモートみたいになってるんですけど、
それでも日本人、日本史上ですかね、
っていうところがあるんですけど、増えてるっぽいです。
というところで、ぜひですね、DevRelに興味がある方はですね、
そういう求人とかチェックしてみるといいんじゃないかなと思います。
あんまりやっぱりね、仕事の数自体はそんなないので、
いわゆるプログラマーとかソフトウェアエンジニアみたいな感じで、
ババーンみたいな感じであるっていうよりは、
それぞれの会社さんがそれぞれ個別にやってるみたいな感じですね。
Googleで探して、多分Googleジョブみたいなやつでしたっけね。
そこで検索に引っかかるやつとか、あとLinkedInとか、
あとXもあるんですよね。
Xの求人って皆さん使ったことあります?
私はないんですけど、というか見たことないんですけど、
ジョブサーチ、Xジョブサーチっていうのがあって、
ここにカタカナとかあんのかな。
エヴァンジェリストって検索して、ロケーションジャパンとかにないですね。
ないですね。
あとはデベロッパーアドとかでやると、
あ、出た出た。デベロッパーアドボケイトでやるとですね、
さっきのオープンAIがあるとか、
あとですね、APACのコミュニティっていうところで、
ユニスワップラボ、これはちょっとわからないですね。聞いたことないですね。
あとは、スクエア、これはちょっと違うのかな。
JPリスクオペレーションスペシャリストとか。
あとは、サークルCIも出してますね。シニアフィールドエンジニア。
アドボケイト職なのかな。これはちょっとわかんないんですけど。
ココスデベロッパー。あとは、これはなんだろうな。
アカウントマネージャー、API、デベロッパープラットフォーム、
Xキャリアー、これはあれかな。きっと、
求人経営っていうところで会社名は出してないのかもしれないですね。
あとは、IBM。IBMはカンタムデベロッパーってことで、
カンタムってあれですよね。量子コンピューティングですね。
カンタムデベロッパーの役割は、量子コンピューティングに精通した
ソフトウェア工学の科学的技術的背景を持ち、
フルスタック開発者として働いた経験、分散システム、
オブジェクト思考プログラミング、特定の業界の機械学習や
最適化を解決する拡張可能なソリューション構築の技術的深さと
実務経験が求められます。こんな人いる?世の中に。
カンタムデベロッパーって、量子コンピューティングに精通した
ソフトウェア工学の持ち主っていう時点で、かなり市場狭いというか、
ターゲットほとんどいないんじゃないかっていう気がするんですけど、
そこにつけて、さらにフルスタック開発者として働いた経験、
分散システム、機械学習と最適化を解決する拡張可能なソリューション構築。
すごいな、てんこ盛りもてんこ盛りな気がしますね。
小田翔さんからコメント来てますね。
Xのジョブサーチちょっとだけ見てみたことある。
個人的にはLinkedInとかの方が充実しているイメージがある。
そうなんですよね。なんとなく私も今探してみた感じだと、
やっぱりLinkedInの方が強いかなって思ったりしますね。
エアビーとかも出してますね。
シニアマーケティングリード、ジャパン、ヘッドオブマーケティングとか。
あとはサップ、プロジェクトプリンシパーコンスタルタム。
そんな感じでですね。
最近ちょっと割と求人増えつつあるのかなっていう気がするので、
そこら辺もですね、スラックでシェアしています。
今回はですね、なんかこうチャンネル作ってそこに投稿するっていう形ではなく、
ジェネラルに投稿してあるんですよ。
見えると嫌じゃないですか。
なんかそのチャンネル参加者とか。
そうすると、こいつ今転職考えてるなみたいな感じに見えちゃう可能性があるので。
なので、ジェネラルのところにですね、投稿してるので。
チラ見していただけると、こういう職があるんだみたいな感じで、
楽しんでいただけるんじゃないかなと思ってますね。
ノーションとかもあるらしいですよ。
ジャパンコミュニティリードでした。コントラクトなんですけど。
意外と他の国に比べると、
日本、求人増えてんじゃないのっていう気がしますね。
スクエアとかもかなりいっぱい出してますね。
ヘッドオブインダストリーレーション&オペレーションズとか。
セールスデベロップメントリプレゼンティティブとか。
そんな感じで求人の話題もですね、
コミュニティの方で取り上げていければなと思っているところです。
っていうのもですね、職につながらないと、
なんかこう、あれですよね。
デブレルを学んでもしゃーないやんけみたいなところあると思うんですよ。
逆に職がどんどん増えれば、求人がいっぱい増えれば、
その職に就きたいと思って、
じゃあ自分の足りない素養というか、
要件って何だろうっていう感じになって、
そこでデブレル東京で学ぶみたいな流れが生まれるといいんじゃないかなと思っているので、
その位置所として求人を取り上げていきたいなというふうに思っています。
続いてのところでですね、こちらは海外の記事なんですけれども、
ミディアムの記事ですね。
全然関係ないんですけど、ミディアムって最近めっちゃ読みづらくないですか。
課金してる人はそんな大したことないのかと思うんですけど、
課金してないとめちゃくちゃバナーがでかいんですよね。
下から脇出てくるやつが。
これがすっごいうざったくて、最近ミディアムほとんど見ないなーってなったりしますね。
これはデブレルインサイツ、
Read, Modify, Write Anti-Pattern by MongoDBという記事ですね。
デブレルのインサイト、Read, Modify, Writeのアンチパターンという記事です。
ここではですね、MongoDBの方ですね。
MongoDBのデベロッパーリレーションについて取り上げてるんですけれども、
MongoDBのデベロッパーリレーションは顧客と直接仕事をするチームです。
コーディングやスキーマーに関する問題を特定し、
業界のベストプラクティスを世界中で共有するお手伝いをしています。
つまり定期的にプロダクトの問題や一般的な問題に遭遇していると。
お客さんと直接話して問題解決に取り組んでいるので、
その業界特有の問題であったりとか、
MongoDB自体の問題とかに遭遇しやすいということですね。
この記事を書いている方、名前ないな。
MongoDBとデータ整合性
ジャスティン・ラブレックさんなんですけれども、
この方が目にした傾向は問題を特定するのが難しく、
データが欠落してしまうという不吉なものだと。
これはなかなかデンジャーな匂いがしますね。
MongoDBって使われている方たくさんいらっしゃると思うんですけど、
MongoDBって基本的に3台ないといけないみたいなのって昔からあると思うんですよ。
今どうなのかわからないんですけど、
MongoDBは何台かの複数台の体制にして、
メインとサブがホットで入れ替わったりとかするような体制にしないと、
データの整合性が維持できないというか、
安全な運用ができないみたいに言われてた気がして、
昔は本当そうやって運用していて、
今はもう個人的にMongoDBって自分で立てる気にはならなくて、
Atlasとかを使った方がいいんじゃないかなって思ったりするんですけど、
データの欠落が起きるという不吉な症状があったということですね。
データベースは期待通りに動作して、
アプリケーションの要求通りにデータを正確に保存すると。
しかしそれはアプリケーションが平行性によって情報を失う可能性のある方法があることを意味します。
つまり一度に一つのドキュメントへの書き込みが、
1より大きくなるデータ平行性。
こわ、こわ。
MongoDBって、あれはトランザクションってあるんでしたっけ?
あるよな。あるよな。
MongoDBトランザクションあるんだったら、
それだったら大丈夫なんじゃないのかね。
ここでブログ記事にあるリードモディファイライトという用語があるんですけれども、
これは低レベルなコンピューティングに由来する言葉です。
コンピュータハードウェア内のコンピュータレジストリ、
またはメモリーバンクへの情報の読み取り、更新、保存をカバーするということですね。
データベースに対するアトミックな操作を意味する言葉でもあるということですね。
全体的な流れから、MongoDBからすると、
まず文書がデータベースからメモリーに読み込まれる。
クライアント上のローカルメモリーで変更される。
最終的にその変更がデータベースに書き戻されて、
保存されていたドキュメントがローカルクライアントのコピーに置き換えられるという、
その3段階なんですけれども、
開発者はこのパターンをよく使います。
しかし、リード、モディファイライトは、
ソフトウェアアプリケーションがデータベースに書き込む際のアンティパターンです。
その理由を探ってみましょうか。
そういうことですね。
いわゆるクラサバのシステムですよね。
最初にクライアント側でデータを表示します。
画面上でデータを変更します。
保存ボタンを押したら、その入力したデータがサーバー側に飛んでいって、
データベースを更新するという流れ。
これは良くないというふうに書いてあります。
1個目の例としては、ページカウンターの例です。
これは分かるような気がしますね。
ウェブページを訪問するたびに、ページをロードするたびに、
カウンターがインクリメントされる仕組みを考えてみてください。
異なるページにはそれらを区別するために、
それぞれに異なるカウンターが含まれています。
ページカウンターは定期的で頻繁な更新を必要として、
重要な平衡性が求められるということですね。
当然、今のマックスの数字、今が1000だったとして、
その1000という数字を読み込んで、クライアント側で1001にして書き込むみたいな、
そんなことをやったら当然それはダメですよね。
そうしたら、2人同時にアクセスしたら、
1001が何回も繰り返されちゃうみたいな感じになるので、
それは良くないので、確かあれですよね。
モンゴデビーだったら、インクリメントみたいなやつが用意されてませんでしたっけ?
それを使った方がいいよねっていう話だと思うんですけど、
モンゴデビーのインクリメントって、
インクリメントした後にその数字が来なかったような気がするんだよな。
今は違うのかな?さすがに。
昔、NCMBっていうエンバースのエヴァンジェリストやってた時があるんですけど、
その時、バックエンドがモンゴデビーだったんですよ。
何年くらいだろう?2019年とかかな?だったんですけど、
その中の人たち曰く、
多分日本最大級にモンゴデビー使ってるみたいな、
そのぐらいの規模でサービスをやっていたりしましたね。
その時にインクリメントを使ってデータ更新しても、
その最新の数字が来なかったような気がしたんだけどな。
違ったかな?
インクリメントするときはモンゴデビー、確かインクリメントのキーワードがあったはずですと。
そういった使い方を間違えて、リード・モディファイライトを間違って使うと、
データの上書きみたいなものが発生してしまう可能性があるということですね。
今はインクっていうのがあるんですね。
これ知らなかったな。
これはJavaかな?
多分。
インクっていう関数が、メソッドが用意されてるみたいですね。
それを使うとインクリメントが正しく実行できると。
そういったデータ更新のパターンみたいなものを、
Javaだな。
使うことによって安全にモンゴデビーを使うことができるといった内容がブログ記事として書かれております。
ドキュメントの重要性
そうですね。
こういうのって中の人からすると当たり前なことっていっぱいあると思うんですよね。
当たり前なことっていっぱいあると思うんですよね。
実際そのユーザーのエラーというかユーザーが抱えている課題とかを聞くと、
マジか、そんな使い方するみたいな場合があって、
それこそ人のことそんな言えないですけど、
SKLの書き方一つにしても、そんなナレッジがなかった時代のSKLって、
それこそめちゃくちゃデータいっぱい取ってきて、
フォーのループで該当するデータを探すとか、フィルターするとか、
アンチパターンですけどついついやってしまったりとか、
条件の付け方わかんないからとりあえず全部取ってきちゃうみたいなことをやったりして、
やったりしてしまったりとか、
そういうのを一体的にして、
やっぱりデータが全てユーザーに対して許可されているとこのようなことが起こったりとか、
見たりとかするんじゃないかと。
そういうのを取り直すことができるようになってきます。
そういうのがあったりとか、
やっぱり人がこういうのを取り直すことができるようになってくるんだと、
けど そのときにピンポイントに その問題がパフォーマンス低下
に直結している問題であれば まだいいと思うんですよ ここの
変え方こういうふうに変更してください みたいな感じで言えるんですけど
それがすごいいろんなところに 散らばっていて もう見てるだけで
結構クラクラするというか 今 このパフォーマンスの問題って
ここだけじゃないんだよなみたいな 根本的にここの部分から変えて
いかないとダメなんだよなみたいな 感じになっちゃうと すごくつらい
というか大変な事態になっていく っていうことがあったりします
ね それがSaaS系のサービスとかで ネットワークにアクセスするもの
だったりするともうそのユーザー の行動がそのまま自分たちのサービス
のパフォーマンスにも結構影響 してきちゃうことが多かったり
するので いろいろ直してもらったり とか 結構このMongoDBのケースじゃない
ですけど 実際にお客さんのところ 行って お客さんの行動を見せて
もらって ここの部分をこういう ふうにしてもらえませんかみたいな
感じで言ったりするというケース は私も何回か経験したことがあります
ね 作太郎さんからコメントきてます
ね ミディアム分かりますよね 画面半分ぐらい埋めるバナーって
どうなのよって思うんですよね 今 これちょっと1回出しちゃった
せいかな リロードしても出なく なっちゃったんですけど すごい
でっかいバナー出てきて シークレット でやったら 出る出る 出るな 半分
以上だな サインアップで フリー ディストラクションフリーリーディング
ノーアズなんで 読むだけだったら 別にいいのかな Organize your knowledge
with lists and highlights ここまででかく出されると もう絶対登録
したくなくなると思うんですよ ね メンバーシップは5ドルかかる
ということですね 申し訳ないけど この強烈なバナーを見せられる
と登録する気失せるなって個人 的には思ってしまいますね 続いて
がドキュメントのお話なんですか How to prevent devs from rolling their eyes
at docs ということで 開発者がドキュメント を読んで目を丸くするのを防ぐ方法
ということですね 面白い表現ですね Rolling their eyesっていうふうに言う
と目を丸くするっていうことなん ですね 皆さんが書いたドキュメント
を見て開発者の人が目を丸くして しまうということをどうやったら
防いだらいいかということですね この中で書かれているのは アーキテクチャー
ドキュメントを もしあなたがエンジニア との会話でアーキテクチャードキュメント
を書く必要があると言ったとしたら どうしますかと 最善のケースは
目を丸くして深い溜息をつくこと であり 最悪のケースは彼らがただ
振り返って部屋から出ていって しまうことです それくらいアーキテクチャー
ドキュメントは骨の折れる作業 なのだと ここで二択ありますね
ドキュメントが全くないのとドキュメント があるが常に古いのとでは どちら
が苦痛が伴うか議論する人もいる かもしれないが ベストプラクティス
はドキュメントを持つことだということ ですね 常に古いドキュメントっていう
のもどうなんだろうっていう気が しますけど ドキュメントがない
よりはあったほうがいいということ ですね ドキュメントのないソフトウエア
アーキテクチャーは不完全である と あなたはドキュメントがないこと
に満足している開発者に出会った ことがあるだろうかと 結局のところ
コードが書かれたとき それを理解 できるのは神とプログラマーだけ
だ 半年後に理解できるのは神だけ だ これいいですね どうなんだろう
な 昔はそうでしたよね 特にVBA とかコピペが増えがちなプログラミング
言語の場合は何ヶ月か経つと元々 のコードが自分でさえ分からなくなる
ことはあったかなと思いますね さすがに今はそういう書き方をしてない
ので どのぐらいだろうな それでも 多分1年ぐらいかな 2年ぐらい経つ
とフレームワークが変わっちゃ ってる場合が多くて それによって
もう書き方が根本的に違くなって たりとかしますよね 前のやつ見て
もこれどっから呼ばれてんだっけ みたいな感じになることないですか
ね 私はよくあるんですけど さすがに 最近のプログラミング言語はそこ
まではないかなと思うんですけど 半年後に理解できるのは神だけ
だということですね ソフトウェア アーキテクチャドキュメントは
ソフトウェアの構造を示すガイド であり 多くの目的があると ここ
では全部で四つ挙げてますね 生産性 コラボレーション 一貫性オンボーディング
という四つですね そういうこと つまり システムのアーキテクチャ
に関するドキュメントがどうチーム の生産性に関与するかということ
ですね これは分かるけど めちゃ くちゃ書くの大変ですよね 正直
システムだけじゃないと思うんですよ ソフトウェアの仕様書であったり
とか ソフトウェアのER図であったり とかっていうのはできなくはない
と思うんですけど アーキテクチャ 全体 例えばソースコードのリポジトリ
をどこに保存していて どういう ふうにCICDが流れて それがフェイル
したときにはどこに通知が行って とか 運用まで含めた上でエラー
管理をどこでやってとか そういう のをソフトウェアアーキテクチャ
ドキュメントっていうふうに書いて あると思うんですけど それ全体
をドキュメント化するのって結構 骨の折れる作業じゃないかなと思います
ドキュメントの必要性と困難
ね このドキュメント ソフトウェア アーキテクチャドキュメントという
のはチームの生産性を高め最終 的なソフトウェアの品質を上げる
ことができます ただ それを書く のはとても苦痛であるということ
ですね 簡単に言えばドキュメンテーション が正確で最新で包括的であることを
保障するために時間と労力を多大 かつ継続的に投資する必要がある
からですということですね 全部で コストについて挙がってるんですけど
全部で四つ挙がってますね 開発者 のための追加的なオーバーヘッド
一般的に開発者は作業中に自分の 決定と行動を文書化することが
推奨されています しかし これは 時間がかかるだけでなく予測不可能な
作業量でもあります 結局のところ ドキュメンテーションを先延ばし
にしようとする誘惑に上がらう のは非常に難しい 2番目 ソフトウェア
アーキテクチャーはますます複雑 になっていると 分散システムの
対等により互いに影響し合うコンポーネント サービステクノロジーの数は指数
関数的に増加していると 2022年の 平均的な企業では88以上の異なる
ウェブアプリを使用しているということ です 確かに これがそれぞれシステム
的に有機的に結びついているみたい になったら 本当にコントロール
するの難しいですよね だからマイクロサービスとか注目
されるっていうのは分かるんですけど マイクロサービスも単体で見る
とシンプルなんですけど 全体で 見るとすごい複雑になったりします
よね さらにシステムはしばしば ダイナミックで常に進化している
と 確かに そして従来のアプローチ を完全に置き換えるような新しい
標準は登場していないと そう UMLですよね 分かるんだけど UML
っていつぐらい 2020年か 2001年か2002年ぐらいにはもうありました
よね 日本では出てきてましたよね 個人的にはスマートドックっていう
のがあったんですよ 知らないですかね スマートドック
ってもうないかな スマートドック に関していい感じのがないな 書籍
があった 懐かしいXMLスマートドック っていう書籍があるんですよ これ
もう昔すぎますね いつの本だろう 2002年か あれ本当に2002年か そうか
2002年に発売されたスマートドック っていうXMLスマートドックっていう
のがあって これ多分もうちょっと 記憶定かじゃないんですけど 日本
で生まれた技術だったと思うんですよ ね そう 朝見さんだ 朝見さんって
めちゃくちゃ有名な人ですよね そうだ UML界で有名だ 多分朝見さん
がスマートドック作られた後に このUMLっていうのが登場して 多分
この朝見さん自身も今は多分スマートドック じゃなくUMLを押されてるのかな
と思うんですけど このスマートドック っていう考えがすごく個人的に
好きで それすごい本読んだりとか して勉強して それでドキュメント
作って ドキュメント?ドキュメント なのかな そうだ ドキュメントでは
あるのかな そのXMLで書くんですよ そのXMLって何だっけ 同じような
XMLで表示をコントロールする技術 何だっけ もう名前が出てこない
何だっけ なんかレイアウトみたいな XMLのレイアウトする技術 もう懐かし
すぎますね すごい久々に思い出しちゃった もう分かんないな そのスマートドック
のXMLの中にCSSみたいな感じなんですけど それを定義すると そのスマート
ドックのドキュメントをHTMLにも できるし あとラテックスもできる
し プレインテキストもできたり とか 確かPDFとかもできたのかな
そういうふうに変換できるっていう のがあったんですよ それが最初
ちょっと私の現体験としてはそれが あって その後 UMLもやりましたね
いろいろ文章書いたりしたんですけど UMLは本当にそんな使わないんです
よね 皆さん 使ってます 未だに 未だにプラントUMLとかそういう
UMLの技術言語ってあったりするんですけど 正直 うーんって気がするんです
よね ああいうのでソフトウェア とかのアーキテクチャ全部書いた
として その後メンテナンスする人 とかいるんだろうかとか思ったり
しますよね プラントUMLだったら まだ あれはYAML形式でしたっけ ごめんなさい
ちょっと忘れちゃったな JSONだった かな なのでプレインテキストで
書くので まだちょっとメンテナンス はしやすいかなと思うんですけど
正直 最初の頃ってMSのVisioとか あと何だったかな なんかのUMLの
専用エディターみたいなやつ使って 書いてたりしたんで 本当にメンテナンス
コストがでかすぎて 最初ノリで 作ったはいいけど 誰も見向きもしない
ドキュメントみたいなものが 出来上がっていった歴史がある
かなと思ったりしますね ドキュメント 本当奥深いですね ということで
リモートワークと息抜き
さくっとドキュメントの話をやめて 今日のメインテーマに入っていき
たいと思います 今日は仕事の息抜き となっております では最初はデブレル
ネーム 株川さんから ありがとうございます フルリモートなので 本当は散歩
とかしたいですが Slackのスコココ が怖いので家事 洗濯とか食器洗い
家族のお茶を入れるをするのが 息抜きですということですね 確か
に Slackのスコココって本当に嫌 ですよね 分かる このスコココって
私だけかもしれないですけど デスクトップ の場合ですよね これ多分ブラウザー
の場合ですよね iPhoneとかだと普通 に通知ですよね 大抵Siriが読み上げ
られなくて 私が読み上げられない 通知が来ていますとかっていう
のが連続してくるんですよね それか 例えばジムとか行って走って
たりするじゃないですか その時に 音楽とか聞いて運動してんのに
そこに対して割り込んでくるんですよ ね 読み上げられないんだったら
通知すんなよとかって思うんですけど それが連続してきたりすると本当に
嫌な気分にさせられますよね 作太郎さんもコメント来てますね
Slackのスコココ恐怖なの分かります ということですね スコココって
言われてんのかな なんかあれみたい ですね 昔懐かしいICQの ICQの音
何でしたっけ 忘れちゃった 言っと いて忘れちゃった QEじゃなくて
あれ 何だっけ 鳥みたいな鳴き声 だったような気がしたんですけど
それを思わせる音 今じゃもうスコココ っていう音に敏感になっている
方がいらっしゃるんですね 皆さん どうですかね 私もあんまり好き
じゃないですね 今 このブラウザー のタブの中にSlackあるんですけど
なんかアイコンついてるんですよ ね これ多分 タブを切り替えたら
スコココって何かなりそうな気が するので そのまま閉じちゃおう
閉じておきました では デブレル ネームジャーニーマンさんですね
いつもありがとうございます 週1回 出社する頻度なので そうなんですね
少なくていいですね 基本的に 自宅でリモートしています 息抜き
は家事と 二人目 家事 家事と たまの昼食作り 稀に行くランチ
です 家事はまとめてやらずに 作業 の合間に考え事をしながらやります
仕事の気づきを得られるときが あり いい習慣になっています また
外出ランチは頭を切り替えるのに とてもいいです 少し外に出るだけ
でも随分違います ただ 近くだと 店が少ないので 新規開拓したい
今日この頃ですということですね ランチ いいですよね この間 税務署
に行ったんですよ 社団法人の件で 税務署に行かなきゃいけない用事
があって行ったんですね 電車で 多分20分か30分ぐらい その後歩いても
ちょっと10分ぐらい歩いたりする と思うんですけど その間 別に仕事
していればいいので 電車座って 仕事していればいいやって思ったん
ですけど なぜかその日に限って なぜかパソコン忘れたんですよ 電車
に乗ってカバン開けて さあ ちょっと 仕事しようかなと思ったら パソコン
入ってなくて もうスマホしかないん でしょうがないんで オーディブル
とか聞きながら過ごしてたんですけど そのランチに帰りに行こうと思
ってたんですね 税務署の仕事終わったら ランチに寄って それで帰ろうと思
ってたんですけど ダメですね パソコンがないともうランチ
行く気にもなれなくなっちゃって もういいやと思って 用事終わって
すぐ帰ってきたんですけど ランチ 行くのはとてもいいんですけど
出てくるまでに多少時間待たされる じゃないですか その時にすごく
手持ち豚さんになるんですよね パソコンがあるだけで 仕事したり
とかできてるんで いくらでも待てる っていうふうになるんですけど
本当 パソコンないと何もできない というか 何もする気がなくなっちゃ
って よろしくないですね そうか でもこれ息抜きなんだな 息抜き
ですもんね 息抜きなんだからパソコン 持ってたらダメですよね そうだ
息抜きだったらパソコン持ってない のは正しいと思いますね
外出ランチね 外出 カフェは行くん だけど大抵ランチまで行かないん
だよな ランチの時間になると帰っちゃ おうかなみたいな感じで個人的に
帰っちゃってることの方が多いですね ちょっと出かけたときはむしろ
ランチしてから帰るみたいなこと のほうが多いかな あとはあれですね
お二人とも家事をやられるということで それはとても良さそうですね しかも
まとめて一気に時間取るっていう よりは作業の合間合間で考え事
をしながらやるということですね 面白いですね お二人目家事ということ
ですね では続いてですね デブレル ネーム西から来た馬面の男さん
息抜きのテクニック
ですね いつもありがとうございます 仕事の息抜きというテーマでお
便りします 仕事中の息抜き大事ですね 集中力が続くのは45分とかなので
適宜息抜きが大事と思っています 息抜きというと代表的なものは
体を動かすことです 一日に一度 職場のトレーニング室に行って
県水ぶら下がりなどをトレーニング をしています リフレッシュできます
もう一つは普通に職場を歩き回る というのも息抜きになります 同僚
との軽い雑談も気分転換になります し コミュニケーションをすることで
相互理解にもつながります この前イベント参加してくれてありがとう
とか また今度おにゃららがある ので来てねとか声かけをします
自分のフロアより2階上と下は階段 で移動して職場を歩くというのも
いいと思っています ぶらぶらしています これはどうなんでしょう
周りから見て馬面の男さんよく ぶらぶらしてるなとかって思わ
れたりしないんですかね 在宅ワーク では仕事と家事を代わりバンコ
にしています やっぱ家事多いですね 多いな 仕事25分して食器を片付け
また仕事を25分して洗濯物を片付け みたいな感じ 単純作業は気分転換
になりますし家事の進捗も出ます ポモ泥テクニックというのもあります
ということでいろんな息抜きを 紹介しました 今週もありがとうございました
ということですね 25分何かやって 消休止してまた25分やるというのは
いわゆるポモ泥テクニックですね 人間の集中力25分 この西から来た
馬面の男さんは限度は45分という ふうに書いてくれてますけれども
ポモ泥テクニックの場合は基本 25分ぐらいしか集中力が続かない
という考えに立っているので どうなんでしょうっけ 25分を4回
ぐらいやるんでしたっけ 確か そうすると長い休憩を確か15分
ぐらいとかやるんじゃなかった かなと思うんですけど このポモ
泥テクニック 私もいつだったかな いつだったかな 去年の秋ぐらい
にやったんですよね もうちょっと 集中できるんですよ このポモ泥
テクニックがちょうど乗り始め たみたいなタイミングでボボボボ
とかってなるとすごく集中が削 がれるというか そこを調整すれば
いいのかな Macのソフトでそういう ポモ泥テクニックのやつを使う
と画面が閉じるんですよ 録画面 みたいな感じになってキー入力
を一切受け付けなくなるみたいな 感じだったんですけど 本当集中
してるときにそれが起きるんですよ ね それでああみたいな感じになる
ことが多くて使うのやめちゃったん ですよね なので 仕事の種類にも
リモートワークの工夫
よりますかね そんなに集中しなくてもいい 仕事だったら25分でちょうど
いいのかもしれないですし 開発 とか あとライティングとか ある
程度集中してバーってアウトプット を続けたりするようなやつとか
ってもっと集中できるような気が しますかね それこそプログラマー
とかだと気がついたらもう昼とか もう夕方とかもう夜みたいなこと
は多々あるんじゃないかなという 気がするんで 作業の内容によりけり
だと思うんですけど 個人的には ちょっと25分では短いことが多かった
かなと思ったりしますね ということで 西から来た馬面の男さん
も家事ですね 仕事と家事を代わり 番号にやると 会社だったらトレーニング
室行ったりとかして 自宅だったら 仕事と家事を代わり番号にやる
というところで やっぱり家事が ちょっと優勢な感じですね
あとは4人目ですね デブレルネーム 小田翔さんですね いつもありがとうございます
2020年頃からずっと在宅勤務の状態 で カンファレンスやコミュニティー
以外は滅多に外出しないので 息抜き には気を使っています 抜きすぎる
のも良くないんですよね 最悪 寝ちゃうので 確かに そうですね
寝るのも それはそれでいいと思うん ですよね お昼で25分寝るのは その
後の生産性にかかってくるみたいな 話もあったりするんで 計画的に
寝るんだったらいいと思うんですけど 息抜きとして寝すぎちゃうのは
あんまり良くないかなと思います ね 最近は書斎やリビングなど仕事
をする場所を変えるといいですね これは私もやってますね その際に
特にキーボードやマウスなどの インプットデバイスを変えるの
がおすすめです そうなんだ 私の場合 多分さっき言ってた
昇降デスクの場合は外付けのキーボード とタッチパッドを使ってるんですね
去年のいつぐらいからかはちょっと 忘れたんですけど 胸を開いて仕事
をするためにMacのキーボード 外付け キーボードを2つ 1つ元々使って
たんですけど もう1個買って2つ 今片手片手にしてるんですよ スプリット
キーボード 分割型のキーボード あると思うんですけど あれの
いわゆる標準的なキーボードの 叩き方 右手と左手のやつが 私は
バランスが悪いので 違う 本当は 左手で叩かなきゃいけない
キーなのに 私は普段右手叩いて いたせいで 分割キーボードにする
と そこのときに指がすっぽ抜けて すごいそれがストレスになって
たんですね そこで矯正しろよって 話なんですけど それが嫌だった
ので 分割キーボードをやめちゃ ったんですけど とあるネットの
記事でMacのキーボードを2つ使えば いいじゃんっていうそういうティップス
があって これでいいじゃんと思って 今 昇降デスクのときには外付け
キーボードを2つですね それ以外 のときにはいわゆるMacBookについて
るキーボードをそのままっていう 感じですね 確か小田翔さんあれ
ですよね HHKB KBDのか ハッピーハッキングキーボード 確か使われて外でも持ち歩
いてた気がしましたね 私の場合 はOSごと変えていますと あとは
手が寂しくなるのでヨーヨーを 回したり スキルトイで休憩がてら
遊んだりしています 浴槽を洗ったり ゴミ捨て行ったり 強制的に仕事
から目を離すタスクを残しておく ようにしていますねということ
ですね 小田翔さんも家事が1つ キーワードに入っているように見え
ますね ヨーヨーは別に家事ではない ですけど 洗濯をやったりとか あと
ゴミ捨てに行くというところで 強制的に仕事から目を離すタスク
を作るということですね 今回4つ ご意見いただいてますけど 皆さん
あれですね 家事が1個キーワード に上がっているように見えますね
息抜きの大切さ
いくつかコメント来てますね 小田翔 さんから HHKBとキークローン
キークローンでやってるんですか ね タッチパッドとトラックボール
で使い分けてる タッチパッドと トラックボールの使い分けできん
のすごいですね もう全然個人的に ダメですね 入力デバイスがタッチパッド
だと何でしたっけ 4点タッチとか できるじゃないですか でも IBMの
ポチみたいなやつ IBMじゃない 今はレノボですか レノボのポチとか
あとマウスとか いわゆる何点タッチ みたいなのができないのが本当
ダメですごいな しかもトラックボール ね トラックボールは知り合いも
すんげえ使いこなしてるんです けど 私は全然ダメですね あれ 親指
で動かしたりする感覚が全然ついて いけないですね 作太郎さんから
ですね キーボード欲しい お小遣い ないから沼製なるものは避けて
ます 本当そうなんですよね 本当 沼ですよね キーボードは 私も分割
キーボードとかあといくつか それは 一昨年ぐらいかな 2年ぐらい
前にちょっとハマりかけて 結局 Macのでいいじゃんっていう感じ
で戻ってきましたね 順さんからは シンクパッドキーボード2枚使っている
方はいますね 2枚キーボードは悪くない と思います 個人的に 分割キーボード
割と高いんですよ 本当にいいやつ って 求めてたものは Macの外付け
キーボードを分割になってるやつ が欲しかったみたいな だったら
2枚買えばいいじゃんっていう そのぐらいの短絡的な感じでいいん
じゃないかなと思いますね キークローン はキースイッチ別で3台同じもの
を使っていると小田翔さん めっちゃ また多いなとか あと最近は加湿器
の水を補給したりしていると 確かに 確かに それもいい 休憩になり
そうですね キークローン キークローン 失礼しました マウスについては
普通のマウスも使っている もしかして ただ沼に沈んでいるだけかもしれない
沼ですね 小田翔さん基本的に沼 大好きですよね 何にしてもね 何でも
カメラにしても カメラ レンズにしても 携帯にしても とにかく沼が見え
そうになったら飛び込んでいく タイプですよね ということで 皆さん
コメントありがとうございます ということで 明日ですね 明日デブレル
東京の99回目がございます デブレル とAIというテーマでお届けして
いくので まだ参加できますんで ぜひご参加いただければと思います
というところで ただ1点注意点として 場所がちょっと変更になります
もう 多分 確定はすぐできると 思うんですけど デブレルとAIという
テーマはすぐできると思うんですけど 最寄り駅は新宿 変わらずです ただ
ちょっと場所変わりますんで ご注意 いただければと思いますという
ところで 今 終了5分前のアナウンス みたいなものが流れたので 今日の
デブレルラジオ201回目ですね 終了 していこうと思います では また
皆さん来週ですね 今日はちょっと またリモートワークボックスみたいな
ところでお届けしたんですけれども 来週は多分 自宅というか いつもの
場所からできるかなと思います というところで 皆さん また来週
お会いしましょう さよなら
