DevRel Radioの紹介
皆さん、お疲れ様です。
1月21日ですね、夕方5時半になりました。
DevRel Radioの今日はついに199回目ですね。
次回がついに200回となる予定です。
ではですね、まず最初にDevRel Radioの紹介からですね。
DevRel Radioは、DevRel Tokyoというコミュニティでやっているネットラジオになります。
毎週火曜日、夕方5時半からですね、1時間程度お送りしているというものになります。
DevRelっていうのはですね、Developer Relationsの略で、
自社とか自社製品と外部の開発者との間に良好な関係性を築くためのマーケティング手法となっております。
DevRel Tokyoではですね、そんなDevRelに関わるような方々、
例えばデベロッパーアドボケイトとかコミュニティマネージャーとか、
テクノロジーエヴァンジェリストとかですね、
そういった方々が集まって情報を共有したりとか、
イベントをやっているといった、そんなコミュニティになっております。
公式サイトがありまして、DevRel.Tokyoというサイトですね。
そちらからスラックに参加することもできますので、ぜひご覧いただければと思います。
あとは、公式のXアカウントですね。
アットデブレル東京というアカウントがあります。
普段はシャープデブレルJPっていうハッシュタグつけてポストしてますんで、
ぜひそちらのハッシュタグ追っていただいたりとか、
あとこのDevRel.Tokyoですね。
そちらの方をフォローいただければ嬉しいですというところで、
リモートワークの実践
今日のですね、メインテーマなんですけれども、
今日は私のリモートワークTipsとなっております。
リモートワーク、皆さんまだ継続されてますかね。
多分継続されてる方が多いのかなとは思うんですけど、
結構バックトゥオフィスの話がちらほらと出てきているかなと思うので、
どうなんでしょうね。
さすがに週5全部オフラインっていうわけじゃないと思うんですけど、
週3とか週2とかでオフィスに行っているという方もいるかなと思うんですよね。
そんな中なんですけれども、リモートワークですね。
うまくやるための工夫みたいなところですね。
もう何年?
かれこれ5年ぐらいやってるってことですよね。
そうっすよね。2020年の忘れもしないですけど、2月29日ですよね。
あの時にDevRelCon Tokyoの2020をやろうとして開催できなかったというのがあったんですよね。
あの時にちょうどクルーズ船がちょうど横浜に寄港したんでしたっけ。
そのコロナの感染者がすごく出て、
結構てんやわんやになって日本に渡航するのが難しいみたいな感じになったのかな。
まだそこまでじゃなかったのかな。
でも会社さんによって日本とか東アジアに出張するのは禁止みたいなのが出てきてしまって、
登壇者からも日本大丈夫みたいな、本当にイベントやるの?みたいな感じで言われて、
2月の20日ぐらいに、20日じゃないか、もうちょっと前かな。
中止を決めたんですよね。
で、ちょうどその前の2月の10何日ぐらいにDevSamiの東京のやつがあって、
それが本当ギリギリのイベントだったんですよね。
あれは本当、消費者さん滑り込み政府だったなと思うんですよね。
確かDevRelConの東京の2020はバックログワールドも確か同日日程で開催予定してて、
同じようにコロナショックを食らったみたいな、そんな感じの思い出がありますね。
そこからなんでね、もう5年経つんで、
随分リモートワークもごくごく当たり前のものになってきてるのかなとは思いつつ、
その間に転職をされたりとか就職されたりとかしている方っていうのは、
その前と今とで全然働き方とか評価のされ方とか変わってしまっているので、
すごく適応するのが難しくなってるのかなとか思ったりするんですよね。
個人的なところで言うと、多分今お付き合いしているお客さんの9割ぐらいはコロナ禍になってからの感じがするんですよね。
っていうのもあって、ほとんど実際にお会いしたことがないお客さんの方が多かったりとかして、
そういうふうに言いつつ、最近定期的に多分月1ぐらいでバスケをやってるんですけど、
昨日ちょうどそのバスケがあった日で、そこに参加してくれるお一人がちょうどお客さんなんですよね。
そのお客さんの会社のオフィスって一回も行ったことなくて、ミーティングもずっとオンラインなんですけど、
唯一バスケだけ会うみたいな感じで、昨日もその話してて、
オフィス行ったり、仕事で実際に会ったことないけどバスケだけで会いますねみたいな感じのことを言ってたりとかして、
なんかそれもすごい今ならではというか、今時だなって思ったりしますね。
そんなところでですね、リモートワークTipsというテーマでお届けしていこうと思っておりますので、
ぜひ皆さんのリモートワークする上で工夫しているところをコメントいただければと思います。
ドキュメントの重要性
そちらの話題に関しては、まだあと30分ぐらいしてから取り上げていこうと思っておりますので、
最近、新しい方のご意見がなくて定番化してきてるような気もするので、
是非ですね、匿名でも投稿できますんで、コメントをいただけると嬉しいなと思っております。
個人的には何だろうな、私の働いているスペースの改造を始めたのは去年の年末からなんですよね。
壁紙の色変えたりとか、後ろのポール立てたりとかしてるんですけど、
なるべく部屋に入ってテンション上がる仕組みにしたいなというところがあって、
なるべくコンセプトを作って部屋を作っているという感じですね。
なので、普通のオフィススペースみたいな感じだとあんまりテンション上がらないんですよね。
仕事したいという気分にならないので、なるべく少しでもその部屋にいたいと思えるような感じにしてますね。
前は後ろの方、絵とか飾ってたんですけど、今ここの右のところに置いてあるんですけど、
絵を飾るといろいろ飾りすぎちゃって、すごいランダムになるんですよね。
カオスな状態になっちゃってきたので、もうちょっとわかりやすくしたいなっていうのがあって、
今一旦絵を全部取り下げ、後ろの壁のところをちゃんと作り、
いつでも後ろ向くといいなみたいな感じで楽しめる環境を作っているという感じですね。
というところで、今日のメインテーマのほうは後ほどやっていこうと思うので、
それまでは最近のDevRelに関係したようなブログ記事とかを取り上げていこうかなと思うんですけど、
今週はドキュメントに関するものがすごく多いんですよね。
海外のものが多いんですけど、一つ目これはウケジュチュクベメリオさん。
Reason why developers hate your docsということで、
開発者があなたのドキュメントを嫌う理由という記事が出ております。
これで押すとして大丈夫かな。
Dev.toの記事ですね。
ドキュメントを開発者が読んでくれないとか、読みづらいと思ってしまう問題点というのをいくつか挙げていって、
一個目がDX機能が低いと。
DX、いわゆるDeveloper Experienceですね。
開発者があなたのドキュメントにどれだけ満足しているかを表す大事な要素です。
キーワードやトピックに関連した検索結果、コード、スニペットのコピーや複製、
キーボードナビゲーションやスクリーンリーダーのサポートといったアクセシビリティ機能といった機能は、
技術文書にとって譲れないものです。
どれかを捨ててしまえば、ドキュメントのDXは著しく低下し、
競合他社に流れてしまうでしょう。
あとは保守性というところ。
ドキュメントをいかに簡単に修正できるかというところですね。
ドキュメンテーションを最新の状態で維持するためには、
モジュール化、バージョン管理、構造的一貫性、自動化、
ステークホルダーの協力が不可欠であるということですね。
モジュール化がやっぱり難しいと思うんですよね。
ドキュサウルスとかMDXに対応しているやつとかは、この辺り解決しやすいのかなとは思いますね。
あとはドキュメンテーションの問題を修正するというところで、
ポストマンのようなツールを使って、
ドキュメント作成プロセスを自動化し、
あらゆる言語のAPI実装を自動生成する。
これどうなんだろうな。
結構いわゆるSDKなんですけど、
自動生成系のツールっていくつかあるんですけど、
まだそんな使い勝手いいような気がしないんですよね。
でも様々な言語に一瞬で対応していこうみたいなことを考えると、
自動生成系ツールを使わざるを得ないような気はするんですが、
使い勝手悪いんですよね。
CICDパイプラインに統合し、
コードリリースがドキュメントと一致するようにし、
文法やスタイルの一貫性を保つツールを回していくということですね。
それができれば一番理想かな。
コードを書いて、上のほうにJSDocとかAPIのドキュメントに使えるようなやつを書き、
スワガーが生成され、
オープンAPIスペシフィキュエーションが生成され、
コードを使ってSDKが各種言語向けに自動で生成されるとか、
そういうことができれば一番理想っちゃい理想なんですけど、
個人的にはまだちょっと難しい。
使い勝手っていう部分ですね。
難しいかなって思ったりしますね。
あとはドキュメントは翻訳ですよね。
翻訳の問題に踏み込んでいる人って多くないんですけど、
なかなか英語をそのまま読んでくれないケースもあったりするのかなという気はしますね。
続いてドキュメントの話。
これはテクニカルライティングなんですけれども、
How to incorporate style guides into your technical writing processということで、
テクニカルライティングプロセスにスタイルガイドを取り入れる方法という記事ですね。
こちらもDev.toの記事になっております。
スタイルガイド、ライティングのスタイルガイド。
書かれたコンテンツがどのようにフォーマットされ、
構成され表示されるべきかを規定する包括的なガイドラインと基準のセットであるということですね。
ライターとしては参考マニュアルとして機能しており、
仕事の統一性を保つのに役立つということですね。
スタイルガイドは文法、句読点、書式、トーン、用語など多くの要素をカバーしています。
スタイルガイドは様々なタイプのライティングで使用されますが、
正確さと一貫性が最優先されるテクニカルライティングでは特に重要ですということですね。
これね、わかるんですけど、どのぐらいの流度でやるのが理想なのかがちょっとわかんないんですよね。
用語集とかは必要だし、文字一文の長さとかそのあたりを規定したほうがいいと思いますし、
そこら辺はリントツールとかで十分できるところかなと思うんですけど、
あと漢字とひらがなの開くとか開かないとか、
句読点の数とか、そのあたりは多分リントツールでも十分回せると思うんですけど、
それ以上どのぐらいきっちりやるかっていうのは難しいところがあるかなって思ったりしますね。
結構こだわってる会社さんはめっちゃこだわるんですよね。
大抵とは言わないですね。
編集であったりとか、何らかのメディアとかで働いていらっしゃった方とかがライティング部門とかの担当になると、
結構細かく規定とか作ってくれるんですよ。
もともとそういう職にいらっしゃった方だったりするんで作れるんですけど、
なかなかそれが社内に浸透しないんですよね。
チームのエンジニアの人とかがドキュメントを書くときに、
スタイルガイドを1から10まで全部理解した上でドキュメントを書くっていうのはなかなか難しかったりとかして、
結局そのドキュメントがプログラムコードの中に入っているようなタイプとかだと、
テクニカルライターの人とかがそこに手出しできなかったりとかして、
やきもきするみたいな感じになるんですよね。
テクニカルライティングの基礎
開発ガイドみたいな感じでテクニカルライターの人が主に書いてくれるような文章だと、
それなりに整った形になるんですけど、
APIドキュメントとかプログラムから生成したようなドキュメントになると、
品質が違うみたいな感じになったりするんですよね。
そのときに気をつける。
国によっても違うけれども気をつける部分としては、
文章と苦等点が1つと、
あとはフォーマットとレイアウト。
フォントの選択、余白、見出し、読み出し、リスト、表、図の使用などの側面を扱います。
あとは用語と語彙。
用語集は必要ですよね。
あとはトーンとスタイル。
トーンとスタイルね。
英語の文章とか読んでて全然このトーンは硬いなとか、
このトーンはカジュアルだなみたいなのって、
なかなかパッと見私にはわからなかったりしますね。
日本語とかだとわかると思うんですよね、皆さんも。
読んでてこれ硬いなとか、これすごいフランクだなみたいなのってわかると思うんですけど、
英語とか例えばドイツ語とかイタリア語とか、
それがトーンとかって言われてもなかなかわからないので、
これは基本的にその現地語っていうところですかね。
現地の人が読んだときにどう思うかみたいな感じですかね。
あと引用と参考文献をちゃんと書くとかですね。
文書の審査と承認のプロセスを作る。
すごい難しいですね。
まず1個目、これを適用するためにはどうしたらいいかというところで、
ガイドになれると。
使用するスタイルガイドを熟読しなれることから始めると。
そうですね。
参考シートを作成すると。
いわゆるチートシートを作るということですね。
そこを見ればだいたいわかるみたいな感じのもの。
こういうのいいですね。
一貫性を確立する。
すべてのライターと貢献者がスタイルガイドを認識し、
従うことを約束するようにします。
難しい。
そしてあとはテンプレートを使用する。
これもいいですね。
スタイルガイドの書式やレイアウトの推奨事項に従ったテンプレートを開発する。
これらのテンプレートは時間を節約し、
ライターがガイドの基準に準拠した文章を作成するのに役立ちます。
ブログとか書いててそうなんですけど、
エンジニアからするとマークダウンとかで書いたほうが楽ってなるんですけど、
それを別な方にチェックしてもらうとかってなったときに、
テキストファイルじゃなくて、
.mdとかだと開けないみたいな感じのことがあるんで、
Googleドキュメントとかで渡すときがあるんですよね。
そのときに見出しとかリストとかをきちんと構造化されたドキュメントとして設定すると思うんですよ。
私は設定するほうなんで、
見出し1とか見出し2とかリストとか変換して渡すんですけど、
人によってフォントサイズを直接いじる人いるじゃないですか。
見出しっぽくなっているんだけど、
それは見出しじゃなくてフォントサイズが16になっているだけだったみたいな感じとか、
太字になっているだけだったとか。
あれはちょっとやめたほうがいいんじゃないかなって思うんですよね。
そのテンプレートとかで見出し2にすると、
フォントサイズ18で太字とかフォントを何々使うとか、
そういうのはもう設定できるので、
それに従ったほうがきちんと統一された文章にできるんじゃないかなって思ったりしますね。
最近Googleドキュメントも確かマークダウンで貼り付けると、
貼り付けはダメだったかな。
マークダウンで書くと自動的に見出しとかに変わってくれる機能が追加されているはずなんで、
それを使うほうがいいのかなと思ったりしますね。
テクニカルライティングで人気のスタイルガイドっていうのがいくつか挙がってますね。
AppleのスタイルガイドとかMicrosoftスタイルガイド、
IBMスタイルガイド、セールスフォーススタイルガイド、
GoogleのGoogleデベロッパードキュメンテーションスタイルガイドとか。
そうなんですね。これは何か良さそうですね。
あとGNOMEのスタイルガイドとかもあるんですね。
Appleのスタイルガイドは、
Appleの従業員とパートナーはApple製品、アプリケーション、サービスの言語、
用語、デザインの一貫性を確保するためにこのスタイルガイドを使用しています。
ライティング、デザイン、ユーザーエキスペリエンスをカバーし、
Appleブランドに沿ったコンテンツの作成に重点を置いています。
ただあれかな、自動でチェックしてくれるようなものではなくて、
Appleスタイルガイド、そういうことか。別にこれはあれですね。
デザインとかも含めっていうところのやつですね。これはありますよね。
これを熟読するのが難しいんですよね。
なのでLintツールとかに統合されているといいのかなと思いますね。
アクセシブルな技術文書
Googleとかもそうかな。Googleも多分これはAndroidデベロッパーとか、
そこら辺でも使えるというものですね。
Red Hat、Supplyment Style Guide for Product Documentationとか、
それぞれの会社さん、やっぱプラットフォーマーだとこういうのを作られているという感じなんですね。
こちらは、これもまたDevDotというか、
Writing Accessible Technical Documentation、アクセシブルな技術文書を書くという内容ですね。
本当なんかドキュメント最近よく見るんですよね。こういうドキュメントに関する記事。
技術文書は製品、システム、ソフトウェアをナビゲートするユーザーにとって道しるべの役割を果たします。
しかしその道しるべがある人にとってはアクセスしにくいものであった場合、どうなるでしょうか。
アクセシブルな技術文書を書くことで、誰もが話すことができるようになります。
アクセシブルな技術文書とは何かというと、
全ての人が使用できるように設計された文書のことです。
スクリーンリーダーを使用しているユーザーが内容を理解できるとか、
動きの不自由な方でも文書を操作できるとか、
あと認知に問題のある方も使用できるようになります。
動きの不自由な方でも文書を操作できるとか、
あと認知に問題のある方も内容を理解できるといったものがアクセシブルな文書ということですね。
なんでアクセシブルな文書が重要なのかというところで、
一つ目が包括性ということですね。
世界中で10億人以上の人々が何らかの障害を抱えて生活しています。
ドキュメントにおいてアクセシビリティを優先するということは、
世界人口のかなりの部分をオーディエンスに含めることができるということですね。
続いて、より良いユーザー体験。
ユーザーが必要な情報を簡単に見つけて理解できれば、
製品に満足する可能性が高くなるということですね。
三番目、サポートコストの削減。
品質よく書かれたドキュメントは、
チームが受け取るサポートチケットの数を大幅に減らすことができます。
これは本当そうですよね。
一時サポートとして使うことができるというところですよね。
四番目、ブランドの評判。
包括性へのコミットメントを示すということは、
徴収のユーザーとの間に信頼と好意を築くことができるということですね。
そのためにできることっていうのが、
実践的なヒントっていうところで書いてあって、
全部で、結構あるな、8つぐらいあるのか。
代表的なところですね。
まず1個目が、普通のシンプルで日常的な言葉を使う。
専門用語は可能な限り避けるということですね。
続いては、見出しでコンテンツを構成する。
適切な見出しレベル。
H1からH3などを利用して文章を整理するということですね。
これね、一つ疑問があるんですけど、
H1って、私の中では、
1つのHTML文章の中で1回しか登場しないものっていうイメージがあるんですけど、
そんなことないんですかね。
H1が見出し的な感じで、
もうその本文的なところはH2以降から始めるみたいなイメージがあって、
そうするとH1って1回しか使えないようなイメージがあるんですけど、
無駄にH3、H4、H5みたいな感じで増えていくんだったら、
全体的に1個上げて、
H1も何回も使いまわしていいのかなって思ったりするんですけど、
多分SEO的な話なのかな、
そういうところでH1って1回しか使わないほうがいいみたいな感じで言われてる気がして、
常にH1って1回しか使わないんですよね。
そのせいで全体的にネストが深くなっちゃってるような気がしますね。
私の書いてる文章とかですね。
多分聞いたところで書くときも、
H1を何回も使ってもいいんだろうなって思いながら、
いつも2個以上のシャープ使って書いてる気がしますね。
3番目、画像のだいたいテキストを追加するということですね。
あとはテキスト以外のコンテンツにテキストと同等のものを提供すると。
例えばビデオの場合はキャプションとトランスクリプトを含めるとか、
音声コンテンツの場合は書き起こしを提供するなどということですね。
あとはアクセシブルな書式を選ぶ。
読みやすいフォントサイズと読みやすい3セリフ系のフォントを使用するということですね。
あとテキストと背景の間には十分なコントラストをつけるということです。
あとは説明的なリンクを使う。
ここをクリックしてくださいのような曖昧なテキストは避けると。
代わりにユーザーガイドをダウンロードするとか、
アクセシビリティ基準についてもっと読むのような意味のあるリンクを使うということですね。
支援技術を使ったテスト。
例えばボイスオーバーのようなスクリーンリーダーを使用してコンテンツをテストするということですね。
そういったところを注意してアクセシビリティの高い技術文章をつけるのがいいということですね。
AI時代のプログラマー
結構学びになりますね、この辺り。
これ投稿しておりますね。
というところで、あとこれちょっと取り上げたかったんだよな。
これはスピーカーデックのスライドなんですけれども、
LINEヤフーの岸田さんの書かれたもので、
AI時代に求められるプログラマーの能力というスライドですね。
最近GitHubコーパイロットワークスペースというサービスが出たりとか、
あとDevinというAIエンジニアとかAIプログラマーと呼ばれるような技術とか、
他にもいくつか出てるんですけれども、
そういうのもちゃんと使いこなせなきゃいけないなというところで試してるんですね。
ちょうど一つSDKを作らなきゃいけないというのがあるんで、
そこで試してるんですけど、
ゼロから作り、機能を作って、同時にテストコードとかも作ってくれて、
それをある程度形になったところでGitHub Actionsでテストするように投げたんですけど、
そこで落ちたんですね。
そうなったときに修正しなきゃいけないポイントが結構多くて、
すごく面倒くさくなっちゃったんですよね。
しょうがないんで、それはそのコードをほぼほぼ破棄しちゃって、
まず自分でベースになる簡単な、ごく簡単なテスト可能なコードの部分だけ作って、
それをGitHubでテストをして、投して、そこで一回コミットして、
その状態からこういうメソッドを追加してくださいとか、
こういう仕様でこういうのを記述してくださいみたいな感じで書いていくと、
随分進みやすくなったんですよね。
ゼロから作らせるとあんまりいい結果にならなかったなっていう感じですね。
リモートワークの課題
ただ、ある程度作れているものに対して、追加でここの部分を補正してくださいみたいな感じで書けば、
それなりのものになるという感じですね。
ただ厄介なのが、私が作ろうとしているSDKに関して、
プログラミング言語の部分からもちゃんとわかっているので、
エラーが出たときに何が悪いかっていうのが判別できるんですけど、
プログラミングの初学者とかだと、出てきたエラーに対して何が悪いのかっていうのがわからないので、
多分エラーメッセージをコピーして、それをまたそのまま投げてぶん投げてやっても、
多分修正されないんですよね。
私もこういうふうに修正してみたいな感じで書いても、
なんかそれはうまく反映されないんですよね。
ほぼほぼ修正しないとか、全然関係ないところ修正しちゃうとかっていうふうになっちゃって、
もうしょうがないんで、途中まで修正されているコードをローカルに持ってきて、
必要な修正して送るみたいな感じで、
エラーの原因がちゃんとわからないとうまく付き合うことできないかなという気がしてます。
特にSaaSのサービスですよね。
SaaSのサービスでAPIをコールして、そこに対してエラーが返ってきましたっていうときに、
そのエラーメッセージの内容をぶん投げても多分修正できない。
超有名なGoogleとかAWSとかであれば、
多分その知見とかがネット上にあふれているので、
それに合わせてコードをフィックスできると思うんですけど、
そんなに別に知られてないようなSaaSのサービスとかだと、
そのエラーメッセージを見たくらいじゃ何もいい答えにたどり着けないので、
多分コードの修正とかも難しいんだろうなという気がしてますね。
その意味でさっきのOpenAI SpecificationとかSUA側のファイルカットから、
AIの利用とその欠点
コードを起こすというのはかなり難しいんじゃないかなという気がしてますね。
岸田さんのスライドの中にもあったような気がするんだよな。
AIを開発に使う場合、リファクタリングをしてもらうとか。
リファクタリングは結構割と得意だと思いますね。
テストを書いてもらうというのもこれも得意だと思います。
プルリクを書いてもらうというのもこれも問題ないと思いますね。
フレームワークやAPIの使い方を教えてもらうという、これもそう。
何でしょうね。参照すべき情報がばっちりちゃんと揃っている状態。
そのリファクタリングする前のちょっと乱れたコードがいっぱいあるとか、
実装されたコードがあるという状態から何かをするという場合は得意なんですけど、
自然言語で指定したものに対してゼロからコードを起こしてもらうみたいになると、
品質まだ難しいのかなという気がしてますね。
AIの欠点として岸田さんが挙げていらっしゃるのが、
ハルシネーション、最新情報を知らない、論理が苦手、逆方向の推論ができない、
コストがかかるというところを挙げています。
ハルシネーションに関して言うと、単純ですね、出力が正しいとは限らない。
コーディングに関しては精度がかなり高くなっているというふうに書いてありますけれども、
結構出力が間違っている場合もあるのかなという気はしてますね。
最新情報を知らないというところで、カットオーバー時期までの知識しかないと、
新しい情報はネットに載らないということがあります。
そして、論理が苦手、確率的な処理なので論理が苦手、
定型化された問題への能力は上がっていると、そうなんですよね。
定型化されていない場合は間違いがちと。
なので、本当に今世の中にないものを作ろうとすると難しいんですよね。
車輪の再発明とかもめちゃくちゃ得意というか、すごくうまくやってくれるというところで、
ある程度フレキシブルな車輪の再発明が今はできるようになってきているので、
将来的にこのフレキシブルな部分がどんどん広がっていくと、
エンジニアが食いっパグれていく未来になっていくのかなという気がしてますね。
リモートワークのヒント
そして逆向きの推論ができないというときに、
これはAはBであるという知識があるときに、
BからAを導き出せないということですね。
すごく単純に言うとしりとりがそうですよね。
普通のしりとりでChatGPTとかと一緒にやると普通に楽しめるんですよね。
でもその逆ができないんですよね。
例えば無で終わる単語を50個あげてみたいなことを言っても、
絶対それあがらないんですよ。
そのLLMの考え方として、
頭のキーワードがあってそこからどんどん連想していく形で、
確率の問題で言葉をつないでいくので、
その逆方向というのができないんですよね。
っていうのもあるんで、
この岸田さんも書かれてますね。
APIリファレンスから実際のコードを組み立てるのは苦手と、
コード例が必要ということですね。
そうなんだよな。
でもSDKとか作ってる方からすると、
このAPIリファレンスから実際のコードを作ってほしいんですよね。
BからAを説明する資料が多いので、
欠点は隠されているということですね。
その逆方向はできないんですけど、
逆方向に関する情報とかもたくさんあれば、
欠点は隠されている傾向があるということですね。
あと最後はコストがかかるというところで、
高性能のモデルを動かすにはコストがかかると、
これChatGPTのプロが月5番ぐらいでしたっけ、
あれが使われまくって大赤字だみたいな
CEOのポストがありましたけど、
本当に今って札束でぶん殴り合ってる状態なので、
あの金額で、僕らは安い金額で使えてますけど、
これたぶん普通に考えて回らないと思うんですよね。
将来的にもずっと回るとは思えないという気はしてますね。
ちょっと今ゲストが来られたのでお呼びします。
小田将さんお疲れ様です。
お疲れ様です。聞こえますか?
はい、聞こえます。
なんかちょっと遠目で見たらガチャピンかと思いました。
確かにこれiPhone行列のときにいただいたTシャツですね。
そうなんですね。
ボストンどうでした?
ボストンは寒かった。
なんかすごいあれですよね、マイナス20度超えぐらいの。
10度とか15度とかそんな感じでしたね、マイナス。
その気温ってどんな感じなんですか?
耳がね、耳がちぎれそうになるので現地でニットボートが買いました。
あれはメガネとかは大丈夫でした?
メガネはそうですね、とりあえずはもうなんか曇るとかじゃないですね。
普通でした、何週間回って。
室内は温度調整がしっかりされてて比較的過ごしやすかったんですけど、
移動のときですよね、やっぱね。
寒くてびっくりしました。
家からほぼ出てないリハビリしてる状態から急に暑いとこ行って寒いとこ行ったりしたので。
体がびっくりしてますね、だいぶね。
健康療法のね、サウナに入ってこういう風にね。
海流移動式のサウナに行ってる感じで、1万キロぐらいかな。
ヤザグとかで自宅にあるやつとかと自宅とかで見てみたんですけど、
1万キロぐらい離れててはすげえなと思いながら、バイクいつ修理しようかなみたいな。
Bostonの移動は何だったんですか?
Bostonの移動は、帰国自体はその下にロードアイランド州っていうのがあって、
マサチューセット州じゃなくてロードアイランド、その下にあるんですけど、3時間ぐらいバスで移動して。
バス?
バス?
会社がチャーターしたバスですね。
へー。
それ、雪とかは大丈夫なんですか?雪はないから。
雪残ってたんですけど、幸い自分がいるタイミングでは降らなかったのと、
あとあれですね、また自分がいた州はまだね、天候的には良かったんですよ。
暖かかった。
先週はもっとやばかったみたいな話を聞きました。
前の州はもっとやばくて、移動もつかないレベルだったっぽいですけど。
マジか。移動的にはどのぐらいなんですか?北海道とかにも全然上なんですか?
だいたい北海道ぐらいですかね。地図とかで見ましたけど、だいたいそのぐらいだったかなーってとこです。
日本で言えば北海道とか、あれかね、もうちょっと上の方だとしても朝日川とか、そこら辺とかですかね。
そうですね、感覚的にははい。見た感じは、もう気持ち上なのかな。北海道の上の方って感じかな。
だいぶ寒かったです。
ハワイがいいですね。
なかなか、ボストン。ボストンってシカゴの近く?
いや違います。シカゴって多分もうちょっと真ん中ら辺ですよ。
あ、そうなんですね。
確か、いや分かんないけど、ニューヨークとかの方が近いですよ。
ほとんどもう、アメリカのほぼ端と言ってもいいぐらいですかね。
なんかね、観光する余裕はなかったんですけど、ハーバード大とかマサチューセッツ工科大学とか、
日本でも有名な大学とかが近所にあるみたいな感じで、観光する余裕もなく帰ってきましたけど。
逆にあれか、そういうところで学んだ学生とかが起業したりして、ボストンでそのまま会社があるみたいな感じなんですかね。
うん、だと思いますね。歴史とかアカデミックなカルチャーを感じながらというか、
セブンで買ったピザ食ってましたね。
ホテルにセブンイレブンが併設されてて、ものすごい安堵しましたよね。
おー、そうなんだ。
いや最高でした。
アメリカのセブンイレブンですよね。日本のじゃん。
アメリカのセブンイレブンですね。
で、行き帰りにハワイ寄って。
そうです。往復2泊ずつ。
もう半袖な感じですか。
そうですね。25から27度ぐらいですごく過ごしやすい。
もうなんならちょっと暑いぐらいで。
だからキャリーケースの中がもうあんな暑服なのか冬服なのかみたいな、
オールシーズンこれでいけるのかなみたいな感じ。
めちゃめちゃ慌ただしかったですけど。
確かに。
そうなんですよ。で、大体9日間ぐらい来たので、ちょっと量も多めでって感じで。
ギリギリでした。預け入れ無料のギリギリのサイズでギリギリの重量で。
そういうことですね。全然選択とかしないタイプなんですね。
日本だったらやりますけどね。海外とかだと、
何だろうな、何かあったりなかったりとかちゃんと動くかもよく分からなかったりとかするんで。
確かに。
ではですね、プライベートチャットの方にURLを置いておきました。
今日のメインテーマですね。今日はリモートワークTipsとなってますが、
和尚さん、なんか部屋の雰囲気ずいぶん変わりましたね。
そうなんです。今日グリーンバック使ってないんですよ。
なぜかというとですね、大掃除をしたんですよね。
きのこを全部捨てたってやつですね。
きのこはね、全然まだ古びません。70匹ぐらい。
何を捨てたんですかね、大掃除って。
でも結構捨てましたよ。いらない服とかもそうだし。
ガラクタがね、物持ちなんで結構いっぱいあったんで。
いらないものはだいぶガサッと捨てたんですけど。
ただあれなんですよね。ハワイとかでダウン買ったりとかでまたちょっと増えちゃったなみたいな。
去年ハネムーンでハワイ行ったときに、ダウン売ってる高級店があって、
ハワイまで来てこんな暑いダウンなんか誰が買うんだよみたいな。
お前だよ。
そう思ってたんですけど、1年後に自分が買ってるっていうね。
これくださいとか言って。
これ着てボストン行くみたいな。そんな感じでしたね。
去年でもどうなの?ハワイで売ってるダウンとボストンで売ってるダウンだったら
ボストンの方が確実に強力そうな気がしますけどね。
一応ちょっと長く使おうと思って、それなりの有名どころのやつをちょっと買って。
そこそこいいやつ買って。
日本にもロメンテンがあったりとかするような。
リモートワークの工夫
割とちゃんとしたやつなので。
でもハワイで買う人いいのかな、俺以外に逆に。
ハワイ経由でカナダの上の方とか行かない限りね。
そういう寒い地域に住まれてる方とかあるかもしれないですけどね。
日本ハワイだと日本冬でも買わないですもんね、基本はね。
店の人もなんで買ったんだろうと思ってるかもしれないですね。
本当に本当に雰囲気でお店出してるだけなのに、本当に買ってきたやついるぞって。
困っちゃいますね、ほんと。
じゃあですね、一つ目。
小田将さん読んでもらってもいいですか。
レベルネームジャニーマーさんですね。いつもありがとうございます。
いかやりもできるのであまりこだわってません。
いくらでも仕事できてしまうので、
個室にこもらず、夕食までに切り上げやすい工夫をしています。
例えばリビングで作業するなど。
またリモートに最適化してきたので、
社員、メンバー、パートナーさん含めリモートを継続し、
出社回帰はありません。皆さんのこと楽しみにしています。
とのことです。ありがとうございます。
リモート継続なんですね。珍しいですね。
リモートいいですよね。
うちの場合だともう国内のオフィスないから、
それこそ先週初出社をしたわけですけど。
家でやって、家に最適化してみたいな。
リビングで作業するとか、ジャニーマーさんおっしゃってますけど。
自分も家に2カ所くらい。リビングと、
あとは書斎で2カ所用意してて。
あちこち動きながら仕事したりしますね。
今いるのが書斎ってことですか?
今は書斎です。
それとは別でリビングで仕事するときもあるんですか?
ノートパソコンを広げて仕事したりとかはしてますね。
今だと正月番組とかを昇華しながら仕事してますね。
モニターの数とかは大丈夫ですか?仕事すると。
モニターの数はiPadとかで増やせたりとかするのと、
あと、ふるさと納税でモバイルディスプレイ発注したの。
3枚ぐらいで使えそうかな。
家の中でモバイルディスプレイ。
家の中でモバイルディスプレイ。
これなんで発注したんだろうなみたいな。
ちょっと余っちゃったからしょうがないから
いっぱいみたいな感じで発注しましたけど。
確かに私もモバイルディスプレイ1つあるんだよな。
Mac mini用に置いてあるんですけど、
確かにリビングとかで仕事するときに、
そういうのを持ち込めばいいんですね。
ジャニーマンからコメント来てますね。
3カ所。
3カ所あります。
いいな、俺もベランダとかにもう1カ所作ろう。
ベランダね。
ベランダね。
ベランダってそうなんですよね。
ベランダ、しかもメンテしないとすぐ汚れちゃうんでね。
臭いんですよね。
そうですね。
でも同じものの住んでる地域だったら
いくらでもカフェは探したらありますもんね。
確かにカフェはありますね。
それこそマイクロソフトの太田和樹さんとかと
結構近所に住んでるんで、
普通にカフェでお茶しながらゴニョゴニョやってたら
和樹さん来て。
でありますね。
ちなみにボストンはフラペチーノチャレンジはしなかったんですか?
したかったんですけどね。
何だろうな。
普通にコーラ飲んでました。
どうしたの?冷えちゃったんですか?
普通にハワイもそうなんですけど忘れたなと思って。
飲みやすいかなと思って。
あとハワイにはドンキホーテがあって
ドンキホーテがしなぞれ完全に日本だったんですよ。
ガブ飲みメロンソーダとか飲んでましたよね。
そんなのハワイじゃなくても飲める。
ガブ飲みメロンソーダめっちゃ飲みたいな。
なんだこれとか言いながら。
あとは日本のお菓子食べてみたいな感じだったのでね。
ラーメン食べたりとか普通に日本の食事を。
おだしょーさんからフラペチーノのラベリングが外れかけてますね。
そうなんですよね。そろそろ飲まないとね。
2月ぐらいが怒られやすいのでチャンスかなと思ってるんですけど。
怒られる?
そうなんですよ。ハムすぎてなんでこんな頼むんだって。
以前怒られたことがあって。
じゃあそろそろ。
そろそろハイシーズンですね。自分の中では。
ではですね。お二人も私から読みます。
デブレルネーム西から来た馬面の男さんですね。
いつもありがとうございます。
前提として自分は妻子がいて自宅からリモートワークすることが多いです。
なので家族への一定の配慮が大事かと思っています。
一つ目ホワイトボードA3サイズのホワイトボードを部屋の前に掲げておいて
オンライン会議がある時間帯を記載しておきます。
そのオンライン会議の時間帯は
部屋に入らないでという位置表示にもつながりますね。
家族はいつも、家族は私がいつオンライン会議をしているかわからないと
声がかけづらいので
LINEで連絡するみたいなことになってしまいます。
また小さい子供も知らずに乱入するみたいなこともあります。
なので会議時間の掲示が大事かと思って見える化しています。
ホワイトボードマーカーでホワイトボードに書きます。
結構新鮮ですよ。
二つ目、有線のイヤホンマイク。
自宅でリモートワークする際、自分の部屋にいるので
マイクなしでもと思いがちですが
周囲の雑音を拾わないよう
また自分だけが会議の音が聞こえるように
イヤホンマイクは必須です。
口元にマイクがあるパターンですので
指向性があっていいです。
ただオンライン会議が多くずっと装着していると
耳の周辺が痛くなりますが
会社向けにも家族向けにも環境を整えるには
大事だと思います。
以上、たまにしか在宅で勤務しないのですが
私が気をつけていること、Tipsを紹介させていただきました。
音声環境の整備
1月ももうすぐ終わりですね。
1月後半もよろしくお願いしますということですね。
おだしょーさんはあれですよね。
普段はもう自分一人しかいないんですよね。
そうですね。日中帯は大体自分一人で
ただ夜間なんですよね。
やっぱり打ち合わせが多いのも
今日のコマンドから
セルフ帰国とかがあるので
今週はもうずっと夜中起きてやっていると思うんですけど
ホワイトボードがいいですよね。
ちょっと自分で使うようなのかなと思ったら
周りでアナウンス付けようなんですね。
A3サイトですね。いいと思います。
そういった意味だと昔
マイクロソフト時代にこういったドアノブ
こういうのを作ったんですよね。
もう今手元に数枚しかないのであれなんですけど
こういうのは書けたりとかはたまにしてますけど
ただこんなにいないんでね奥さんも。
あともう家帰ったらね
家のことやって風呂入って寝るとか
っていう感じだと思うので
こういったのも便利かなと思いながら
ホワイトボード自分で
1枚用意しておいて書きやすいとか
書きやすいというか考えてることを
言語化しやすいとかそういう系かと思ったら
まさかのって感じでしたね。
それノベルティですか?
これノベルティでしかも重ならないんで
いいですねそれね。
そうなんですよ。ミーティングとかね
ワーキングナウとかね
どっちにしても開けんのって感じですけどね。
それこそ開けちゃダメじゃんって
どっちも開けんじゃねえみたいな感じですけど
こういったの作ってましたね。
IoTだったらねそれこそオンエアとか
手術機械とかそういうの使いたいですよね。
いいですね手術機械。確かにそういったのあってもいいですよね。
イヤホンマイク
この辺も確かにあるといいですよ。
夜中のミーティングとかは音声注意したりとかしてるんですか?
基本的にはヘッドホンで音出すのとスピーカーで出すのは
つまみで切り替えられるように今もしてるんで
音声にしたがってそれだけ気をつけてますね。
英語ミーティングで結構自分ががっちり話すことって
稀なので、稀というか夜中とかでやってるのは
みんなが集まってる中でやるっていうのは
あれなので基本危機戦だからそこまで気にしないですけど
少人数でやるミーティングの時とかは逆に朝が多いので
あんまりもうその時間には奥さんは家に出てるので
あんまり気にせずゴリゴリ喋ってるって感じですかね。
分かりました。では3件目ですね。
コミュニケーションの重要性
こちら読んでいただいてもいいですか?
はい3件目ですね。デブレルネーム札幌のじゅんさんですね。
いつもありがとうございます。
普通にしていたら知り合いない2人の間を
繋ぐみたいな活動を続けていますが
その時に気にしていることは
お互いの課題が多分共通しているかどうかということです。
紹介をする時には公開されている情報から
活動内容をまとめて共有して
お互いの課題解決に向けたコラボの可能性があることを
丁寧に書きます。そういうことをしておくと
オンラインファーストでも話が広がっていきますし
オフ会みたいなことが起こっても楽しく過ごせる可能性が
高いと思っています。簡単に会えないからこそ
テキストでストーリーを作っておく準備をする意義があると
考えています。ありがとうございます。
これはじゅんさんがやることなのか?
どうでしょうね。ただ第三者的に入ることで
客観性の高い文章が出来上がって
そこに情報がまとめてあると
同じイーブンな感じで話しつなげられるんじゃないですか?
そうだと思うんですけど
お互いにやってほしいなっていう気がしちゃいますよね。
それが出来たら別とかもしれないですけど
お互いがその辺意識できてないっていうことが
ディスコミュニケーション起こるぐらいだったら
最初の方はちょっと並走してみたいな感じかもしれないですね。
すごい優しいですね。
めちゃめちゃ優しいと思います。このぐらい丁寧にやってくれると
コミュニケーションが取りやすいですよね。
ちょっと前にもそういった話を
それこそ先週ボストンに行った時に
同僚とかと話したんだけど
映像と音声っていう
後方、あとテキストとかだけに頼ると
互換の情報って結構情報としてそぎ落ちちゃうから
あって話すのっていいよねみたいな話をしてたんですよね。
手振りだったりとかその時に浴用だとか温度感だったりとか
あとはオンラインミーティングってやっぱり
昔から言われてますけど雑談が少なくなりがちというか
なのでそういったアイスブレイクを意識してやるやらないみたいな
話とかはちょっと向こうでしてましたね。
結構雑談いっぱいしてきましたね。
ラーメン自作してるやつとかいました?同僚で。
いいね。そんな話をオンラインで言ってもなかなか伝わらない。
そうなんですよ。
それを話を繰り出すタイミングが分からないじゃないですか。
受けるのか受けないのかみたいな。
だけどオフラインで話したりとかすると
本当に日本の豚骨ラーメンが大好きでみたいな
自作してるんだけどあんまりうまく作れないんだよ
どうしたらいいと思う?みたいな相談を受けて
こっちは別にラーメン屋の人間しかやってるわけじゃないのに
分かんねえよとか言いながら
水が違うんじゃない?とかヘッドのこと言いましたけど
この間あれですね、リュウジさんのYouTuberのリュウジさんが
福岡の博多ラーメンを一覧ラーメンを再現するみたいなやつやってて
イギリスに住んでる日本人が一覧めちゃくちゃ高いから
リモートワークとコミュニケーション
これをジェネリック一覧で我慢しますみたいな
あのURL送ってあげると
その豚骨スープの作り方とかやつ
いいですね。ちょっと探して送っておいてあげようかな
っていうのがすごかったです。
メイブルって結構日本好きな人多くて
来月プライベートで行くからちょっと観光付けってよとか
いろいろこう
だからよく分かんない口約束を大量にしてきましたけど
本当かよとか思い出して
本当に来るんだったら連絡ね
またトラックで来るでしょうからね
いつからいつまで来るから
時間作ってよとか多分来ると思うので
適当な口約束だけしておきましたけど
こんな形で
そういった話を
カジュアルな話をしやすくするというか
オンライン、拠点が離れてて
そんなにすぐ会えない距離感だったりとかした場合に
整地しておいてあげるみたいなやつは
すごく親切だなと思うし
今コメントも来てますけど
所属学会が違うとかで似たことやっててお互い知らないとか
縦割りになってて近しいことやってて
コラボレーションするとちょっと面白くなりそうなんだけど
横軸で見てるJunさんは分かるんだけど
彼ら分かんないからコミュニケーションの口がないんだけど
縦割りだからちょっとプロトコルが違ったりするんでしょうね
同じことやってたとしてもね
その辺の調整をJunさんが間に入って
1回2回やってあげることで進みやすくなるみたいな
そんな感じなんじゃないかなって気はします
分かるんですけどね
私だったらFacebookメッセージでつないで
じゃああとよろしくみたいな
あるあるある
この前つないでいただいたときもね
サクッとLINEでグループ作ったと思ったらすぐいなくなりましたからね
そうですね通知器のうざみたいな感じになっちゃう
本当に必要だったら上手くコラボレーションするでしょうけどもね
それもそれでありだと思いますけど
すごいJunさんの人柄が出てる感じですね
そういう経験でいいと思いますね
皆さんコメントありがとうございますというところで
今日のお時間というところもあるんで
次回の特別なエピソード
今日が199回目ですねついに次回200回ですよ
素晴らしい
すごいですね200回
なんで続いてるのかよく分かんないですけど
すごいですよね
録画使ったりとか場所を都合があったら
駅とかにある個室使ったりとかね
あらゆる手段で続けてたみたいな感じはありますか
そうですね続くもんですね
素晴らしいゆるーく継続していくのって
口で言うは優しいというか
実際やろうとすると結構大変ですからね
そうですね
毎週ですか
次回は200回なんでここのストリームヤード
ギリギリ限界ぐらいまで
いろんな人が来てくれるといいですね
確かに確かにそうかもしれない
なんかないかな
お祝いするアイテムなんもねえだよ
適当
小田翔さんがボストンから参加してたら受けるんだけどね
確かにね
でも時差しんどい本当に時差しんどい
14時間なんで
きついな14時間かダイレクトで14時間
そうですね
いや違います時差が14時間です
時差が14時間かすごいな
ダイレクトだと飛行機だと15時間とかですかね
15時間遠いな
そうなんですよ
ハワイを真ん中にすると10時10分みたいな感じ
地球が時計みたいな感じ
移動距離だったんで
東海岸初めてだったんでいい経験になりましたけど
何回も行くの大変だなと
そういった意味だとタイジさんとか
本社ニューヨークほぼほぼ近いところなので
大変だと思いますよ移動
行くだけで疲れちゃう
今年の7月はねデブレルコンニューヨークがまたありますんで
そうか行きたいな
4月かいいですね
ネイブルに寄った後来るとかね
確かにそれありですよねちょっとお金出してくれないかな
でも案外安かったですよハワイアン空港とか
20万ぐらいオフから案外安いしスターリンク使えるっていう
インターネットとか動画見てました普通に
YouTubeとか
そうっすよねあれまだよく体感したことないんで
全然分かんないです
普通にインターネットできるみたいな
素晴らしい素晴らしいのこれ休めなくなっちゃいますね
はいよくないです
全然よくない本当に
飛行機の中で休みましょう
とりあえず海内ロケの調整のためにね
息を余って寝たほうがいいので
そうですね
分かりました
ではですね次回はついに200回というところで
また皆さん来週火曜日ですね
夕方5時半にお会いしましょう
では小田将さん今日はありがとうございます
ありがとうございます
ではまた皆さん来週お会いしましょう
さよなら
さよなら
