はじめに
ジメジメムシムシと暑いを通り越し熱いになっている今日このごろどうお過ごしですか？
ぼくは夏バテなのか最近調子があまり上がらず、困っています。
７月中に書き上げようと思っていたブログ記事を5ヶ月も寝かせる大罪を犯してしまいました。 どうも、マネーフォワードで技術広報をしている @luccafort です。 今日は6月（！）に登壇した Kyoto.js #22 の感想と参加したことで見えてきたこと、新たな体験を得たことについてダラダラと書いてみました。
いつも通り長文ではありますが、お時間があればお読みください。 ご意見ご感想はぜひこのブログのURLを引用してブログ記事などを書いていただければと思います。
[2024.12.13 追記] 一部掲載内容について、弊社対応不備があったため削除しています。
登壇について
タイトルの通り、Kyoto.js #22 で「君は新しい日付/時刻API Temporal を知っているか？」というタイトルで登壇をしてきました。
https://kyotojs.connpass.com/event/321343/kyotojs.connpass.com
発表したスライドはこちらにアップしています。
スライド共有の X へのポストを行ったところ、まあまあインプレッションがあり、イベント後の懇親会でも「あれ面白かったよ！」と言われたので突貫で資料をまとめて発表した割には上出来ではないかなと思います。
このあと発表するスライドですー。忘れないうちに投げておく。
— luccafort (@luccafort) June 28, 2024
「君は新しい日付/時刻API Temporal を知っているか？」https://t.co/wDydPba5w4
#kyotojs
個人的には @nagayama さんにイベント後にこのように言及してもらえたので大満足です。
Temporal APIおもしろかった。個人のプロジェクトで日時扱うのにpolyfillから使ってみようかなー #kyotojs https://t.co/sWXPkh7BeE
— 𝐧𝐚𝐠𝐚𝐲𝐚𝐦𝐚 (@nagayama) June 28, 2024
Kyoto.js #22 の感想とか
タイムラインは #kyotojs のハッシュタグの投稿を追っていただくなり、YouTube のアーカイブをみるなりしてもらうといいかなーと思います。
ぼくの登壇は YouTube の29分ごろになります。
（めっちゃ音が割れててウケる）
https://twitter.com/search?q=%23kyotojs&src=typed_query&f=livetwitter.com
個人的に面白いなと思った発表を紹介します。
TypeScriptで関数型指向で抽象を扱うにはどうすれば良いのか @ Kyoto.js 22 / @mrsekut さん
tryangle株式会社 @mrsekut さんの発表。 TypeScript で関数型指向で抽象を扱う際どうするか？というもの。
この次発表します〜
— mrsekut (まる) (@mrsekut) June 28, 2024
『TypeScriptで関数型指向で抽象を扱うにはどうすれば良いのか @ Kyoto.js 22』https://t.co/bCVaEoMYMz #kyotojs
ぼくの後の発表だったんですが、データ構造に着目するサンプルでお金の話題が出てきて「これは◯◯するといいのか？だがしかし……」みたいな設計や実装上の疑問点や自分だったらこうするかなーという考えを巡らせながら、発表を聞いていました。 社内でよく見かけるようなビジネスドメインに近い話だったので自然と「あーでもない、こーでもない」と考えながら、自分だったらどうするかを考えるのが楽しかったです。
以下は自分でも「こうするといいのか？だがそれだと微妙では？」と思った投稿をしたところ、速攻で Pixiv の CTO はるかさん(@harukasan) に突っ込まれている図です。
そうなるとPayってのがでかすぎてちゃんと分割できていなさそうなきがする #kyotojs
— はるかさん (@harukasan) June 28, 2024
こういう「自分たちならどうするか？」や「こういうケースの場合どう考えるか？」という話は際限がないんですが、実務に近い感覚で議論できるので楽しかったです。 この例ではあくまでサンプルなので、あえて考慮していない点とかもあったんだろうと思いますが、なかなか妄想しがいのあるテーマでした。とても好き。
登壇資料が Cosense（旧Scrapbox） に感想が書かれているの、めっちゃいいですね。 ついつい読み耽ってしまいました。
もうちょいウケを狙っても良さそう
ここは登壇者と聴講者の違いかもしれませんが、テーマの内容が面白かったので、個人的には無理にウケを狙わなくてもいいかなーと思いました。 「慣れないやつほど奇をてらう（CV: 福部里志@氷菓）」ということもあると思うので、テーマで勝負できるほうが王道で強いな！と感じていました。
なぜ技術広報がフロントエンドの勉強会に登壇したか？
そもそも今回、技術広報のぼくがなぜ登壇したのかというと、ぼくが応募する時点ではまだ「一般トーク枠が埋まっていなかったから」です。
ぼく自身は元々バックエンドが専門で、あまりフロントエンドが得意ではないのですが、いつも Kyoto.js には参加させてもらい楽しませてもらっていたのでその恩返しのつもりで登壇しました。 普段みている面白い発表と同じ……とはいかずとも、多少は貢献できていたら個人的にはよいかなと思っています。
本来はマネーフォワード社内のエンジニアに登壇してもらうのが一番良かったんですが、前回2名登壇してもらっていたことやフロントエンドエンジニアの多くが大阪なので、急きょ登壇を依頼しても難しそうかもと思い、自分が登壇する方向で舵を切りました。 「普段はみんなにお願いをして登壇してもらってるので今回くらいは（登壇ネタになりそうなアテもあるし）やってみるか！」とエントリーしましたが、個人的には面白いテーマを見つけられて楽しかったです。 30分話せ！と言われたら難しいけど、本職じゃなくても10〜15分くらいなら丁寧に説明とかしてたら一瞬だよな！と楽観視していたのもあります。 （なお、このあと資料作成で地獄を見ます）
登壇資料の作成時に考えていたこと
とりあえず、15分くらい話せるテーマかどうかを検証するために以下のようなアウトライン（原文ママ）を登壇枠で応募したあとにすぐ書きました。
## 目的 TC39 のリポジトリで Stage3 になっている Temporal について学ぶ ##想定読者 - Temporal の存在を知らない人 - 日付や時刻の JS API で困ったことがある人 - Temporal について調べようとして手が止まっている人（つまり自分） ## アウトライン - Date API のおさらい - Temporal が必要になった背景 - Temporal の構成図 - Temporal API のユースケース - 注意点 - (Optional)話題になったりいまホットなIssueの紹介 - まとめ
実際にはここから更に情報収集したり、登壇時間内に収まらなさそうなものをバッサリ捨てたり、自分が調べきれるものに集約させたりしました。
登壇が決定してからアウトラインだけ作成して、登壇の2日前に有給休暇を取って資料作りに専念する形を取りました。 以下は午前中（業務時間外）にビールを飲みつつ、コパ・アメリカ 2024のアルゼンチンvsチリ戦を観戦してる様子です。 ちゃんと午後から資料作成していてえらい！！！
やっていきます！
— luccafort (@luccafort) June 26, 2024
勝つぞアルゼンチン！！！！！！！ https://t.co/DC3ueHC8fN pic.twitter.com/K03Q5oPvNF
多分13時から19時くらいまで書いていたので、ざっくり6時間くらいで8割近く登壇資料ができていたと思います。 残り2割は登壇当日の数時間前に宣伝入れたり、誤字脱字がないか確認したり修正したり……という感じで当日を迎えました。
技術広報からみる登壇に関する考察
普段のお仕事が技術広報、つまりエンジニアの人に登壇を依頼する立場なのでその観点から「なぜエンジニアでないのに登壇できたか？」を考えてみました。
なぜ登壇できたのか
まず1つ目、登壇できるテーマを持っていたこと。 2つ目、登壇や発表慣れしていたこと。 3つ目、イベントの雰囲気を知っていたこと。
この3つの観点が大きかったのではないかなと思います。
1つ目、登壇できるテーマを持っていたこと
技術広報をしていて「こういうイベントがあるんですが登壇してみませんか？」といったときに返ってくる答えナンバーワンはなにか？と聞かれたらこれになります。
「登壇するような技術ネタがない」
まあ気持ちはわかるよ……でもそれ本当？って疑問もあります。 明らかにエンジニアよりも技術情報の接点やインプットしている時間が少ないぼくが登壇できて、エンジニアができない理由ってあるんでしょうか？ そう考えると「登壇する技術ネタがない」は正確ではなく、「登壇する技術ネタを見つけるスキルが不足している状態」じゃないかなと考えました。
ぼくは幸い、「こういう登壇テーマがあって、〇〇さんがこれについて話していたから、XXの部分を付け加える形で登壇できると思うんだけどどう？」と提案するお仕事を日常的にしています。
そういった日々の業務が「技術ネタをみつけるスキル」を磨いていったのではないかと思います。 普段から「これは面白そうだな、メモしておこう」や「これってなんでこうなっているんだろう？時間がないからあとで調べよう（URL をメモ帳に残す）」といったことをしているので、 そういった小さな積み重ねによって「技術ネタをみつけるスキル」につながったのかもしれません。
だからこそ、エンジニアに比べて技術情報のインプットが足りなくても、登壇テーマを見つけられたのかなと推測しています。
偶然ですが、元同僚が SNS で似たようなことを書いていました。
LTを始めとした登壇の類、技術力高いつよつよな話をしたい…！という気持ちはとてもよく分かるんですけど、素振りもせずにいきなりは出てこないので社内外どっちでも良いのでネタを出したり作り出す練習はしたほうかいいと思うんですよね
— にゃふんた (@nyafunta9858) June 29, 2024
ブログでも社外登壇でも社内発表や社内ドキュメントでも何でもいいので、他人に聞いてもらう場を作ることが重要なのかもしれません。
2つ目、登壇・発表慣れしていたこと
登壇や発表をするためには、ある程度の慣れが重要になってくることがあります。 登壇、今回の場合はオフラインでの登壇 + オプショナルな形でオンライン配信でしたが、メインとなるオーディエンスは会場に来ていた参加者です。
@mrsekut さんの感想にもありましたが、オーディエンスの反応というのはこういったイベントではとても重要です。 自分が発表した内容に対してうまく伝わってなさそうな雰囲気や、逆にうなずいて共感してくれてそうだという反応をみて、補足説明をするか省くかを判断するなどの「魅せる（見てもらう）登壇の仕方」が求められることがあります。
コロナ禍でオンライン登壇しか経験がない方の中には、オフラインでも原稿を読み上げることに必死になってしまっているケースをたまに見かけます。 オンラインでは 1:N の関係性なのでテレビやラジオのように一方通行なコミュニケーションでも問題ないケースもありますが、会場の場合オーディエンスの反応によってアレンジをつけ加えるとより魅力的な登壇になるケースがあります。 本質的にはそういった演出は余分なのかもしれませんが、みんながみんな質の高い発表を行えるかどうかはわかりません。 そんなときでも小技を覚えて楽しんで帰ってもらうことができれば、自分の登壇は成功だったと言えるんじゃないかと思います。
そういった意味でも過去に登壇経験がある、1000人程度の前で緊張せずに発表することができる、周りを強引にトークに巻き込む自分なりの手段を確立している……といった点が自分にとって優位に働いたと考えています。
3つ目、イベントの雰囲気を知っていたこと
過去に登壇こそしてないものの Kyoto.js には何度もお邪魔していたのでイベントの空気感や参加している人がどういったものを求めているか、また困ったときに誰に助けを求めればいいかなどを把握できていたのは登壇を決定する際の大きなポイントかもしれません。
登壇や発表慣れしていないときは「誰が」「なにを」求めているのか想像できないことが多々あります。 そういったときにノンバーバルな情報がとても重要になることがあります。 例えば、会場の雰囲気であったり、どういった人がいるかであったり、参加者の身振り手振りなどのノンバーバルコミュニケーションによって「ここは退屈そうだから早めに終わろう」や「あまり反応がないのでもう少しわかりやすく説明したほうがいいかも」といった対応を取れます。
今回でいうと「Kyoto.js にはどういう人が参加しているか」「過去どういった発表が楽しまれていたか」を知っているかどうかが大きく影響しました。 最悪、駄目なら Temporal API が実装されている GitHub のリポジトリにある issues や Pull Requests などを眺めて、どのように実装されたか、どのような議論が交わされていたかをみるだけでもこの会に参加する人は楽しんでくれる、なんなら自分が知らない情報を足してくれるだろうという信頼を持っていたため、恐れずに挑戦できました。
案の定、主催者の ぱすたけさん（@pastaK） a.k.a マジカルペンネくん🍝 さん（以降、ぱすたけさん）から「実はあの Stage 2.7 というのは……」という補足を懇親会の場で教えてもらいました。勉強になる……。
懇親会では、こういったイベントの本筋そのものには関わらないが、自分だけでは知ることができない知識に触れることがあります。 ぼくは最近そういった瞬間が楽しいと感じ、できるだけ懇親会に参加するようにしています。 昔は「馴れ合うためにイベントに来たのではない」みたいなことを考えて、懇親会にはあまり参加していませんでした。
以前のぼくのように懇親会の参加が苦手な人も多いと思いますが、そこでしか得られない体験や知識もあると知っておいてもらえればと思います。 なかなか懇親会で話すようなことはブログや登壇では発信されないので、こういった情報に触れられるのは参加した人だけの特権かなと思います。
登壇後に TC39 の Stage に Stage 2.7 が新設された経緯を解説しているブログを見つけました。気になる方はどうぞご覧ください。
他にも過去の経験を活かす
実は今回の登壇はテーマや発表スタイルに関して主催のぱすたけさんの過去の登壇を大いに参考にさせてもらいました。
参考にさせてもらったのは Kyoto.js #18 で開催したときの「WebExtension の MV3 対応にまつわるあれこれ」という登壇です。
このイベントの懇親会のときにぱすたけさんと話していて「登壇内容めっちゃ面白かったけど普段どこでインプットみつけてるの？」と話しかけたところ「実はこの登壇はめちゃくちゃカンタンでテーマだけ決めて、公式ドキュメントから必要な情報をピックアップしつつ、どうやら議論が紛糾してそうな GitHub issues を見つけてまとめただけなんですよ！」と教えてもらいました。
このときは「へー登壇慣れしてる人は面白いネタの見つけ方をするんだなー」と思っていたのですが、今回ぼくも似たスタイルを踏襲させてもらっています。 「Temporal API」というテーマだけ決めて、「現状どのような課題があるか」「新 API によって何が解決するか」「実際動かしてみたり、ドキュメントを読んでみて気になったことはなにか？」という軸でアウトラインや資料を作成しました。
ぼくは普段仕事で開発の実務をする時間はほぼありません。 そのため、業務に関わる開発の話ができず、エンジニアの皆さんのような登壇ができません。 そこで、業務に関連する発表ができないという制約を逆手に取って、完全に公式ドキュメントのサマリーや実際に自分が実行してみた結果を発表することに全振りをしました。 そういうものばかりだと飽きると思うけど、幸いこのときは他の方とかぶらなかったのでセーフでした。
テーマとして目星をつけていた Temporal API はまだ知っている人は多くないんじゃないか、とあたりをつけ、そこそこ面白おかしく話すことができそうだと考えていました。 反面、情報感度の高いフロントエンドエンジニアのような方にとっては「公式ドキュメントのサマリーだな」と思われる可能性が高いことは考慮していました。 そのため、今回の登壇の想定参加者から上記の「情報感度が高い方」は対象として含めないという方向で方針を決定しました。
開発の筋力と登壇・発表の筋力の違い
今回の登壇で思ったことではありませんが、登壇における筋力と普段の開発における筋力のようなものは明確に異なると改めて実感しました。 開発業務では「ユーザーが抱える課題を解決すること」が主になります。 ですが、登壇や発表は「オーディエンスに価値を届けること」が主になるのではないかと思います。 最終的にはどちらの概念も同じゴールに到達すると思うのですが、そこに至るまでの過程に違いがあるように思います。
それが「筋力」と表現したものになります。 登壇だけを繰り返していても、開発のための技能は高まらないと思いますし、その逆も然りだと思います。 登壇をおこなうことで抽象と具体、あるいは言語化することを通して、より概念の抽出ができるかもしれません。 ですが、それだけでは「開発」と「登壇・発表」の両方によい影響をもたらすことは難しいかもしれないと思いました。
少なくとも、ぼくには次の課題があります。
- フロントエンドが苦手であること
- ここ数年開発の現場から遠ざかっており、実際の開発現場の経験談が話せないこと
- エンジニアの最新技術の事情を以前ほどインプットできていないこと
上記のような状態のぼくでも登壇できたので、エンジニアの方ならもっと面白い話ができるんじゃないかと思います。 では、何故そうならないか？といえば時間がない、忙しいというのが1つの答えになるかと思います。 基本的に忙しくないときを正として考えると、常に登壇やブログ執筆はできない状態になると思うので、何かしらの方法でカバーできる領域や工夫できる余地を事前に見つけておくのがよいのかもしれません。
登壇しない・登壇したくない人に関しては登壇するためのモチベーションがないので、「いまはまだそのときではない」ので無理をする必要はありません。 まさにこちらのスライドにある「無理に動かさなくていい」状態ですね。
判断が難しいのは「依頼をすれば登壇してくれる人」です。 登壇を引き受けてくれている人はとてもありがたい存在であるという大前提はあるのですが、「もったいない」と感じるケースと「すごくよかった」と感じるケースの2つに分かれることがあります。
後者は「想定しているよりも盛り上がった、面白い発表だった」という期待を超えた状態なので何も問題はないかなと思います。 難しいのは「もったいない」と感じるケースです。
もったいないと感じる理由はさまざまですが、気持ちとしては「あともう一歩踏み込めば、もっと良くなりそうだ」と感じる発表です。 これはあくまでぼく個人の感覚なので、登壇そのものが面白かったという方もいると思います。
何故そう感じたのかを考えたときに、「イベントの現場を知っていること」や「実際に自分が体験していること」に着目しました。
前者は過去にイベントに参加したことがある、あるいは似たイベントで登壇したことがあるなどの解像度を高めるための知識がインプットされている状態。 後者は過去に類似の体験（登壇や発表）をしたことがあり、過去の体験を昇華している状態を指します。
これらの要素が不足している場合、テーマやオーディエンスが求めるものの解像度を高めることができず、 伝えたいことが伝わりきっていないようにみえてしまい、「もったいない」と感じたのかなと考えました。
昨今、京都・大阪ではオフラインイベント復調の兆しがあります。東京のほうでも最近オフラインのみのイベントを見かける機会が増えました。 もしかすると、今後さらに登壇した体験やそこから学んだ経験が重要な意味を持ってくるのかもしれません。
まとめ
普段、イベントの企画・運営をしているため、自分が主催しない場で登壇する機会がめっきり減ってしまいました。 今回の登壇をきっかけに、いろいろと普段の業務でも登壇に活きることがあると再発見することができました。
たまたま業務で Google App Script を書く際に Date API について調べたところ、 Temporal API の存在を知り、そのうち個人ブログ記事に書いて公開しようと考えていたものが思ったよりも早く世の中に公開されることとなりました。
また、業務を絡めて発表することができないという制約から、正式リリースされていない API の公式ドキュメントのサマリーを面白おかしく発表し、さも最新情報に敏感であるかのようなふるまいをする練習もできました。
Temporal API の設計や今回の登壇やこのブログ記事を執筆する際にぼくよりも先陣を切って、調べてくれた方のお世話になりました。とても感謝しています。
今回の登壇を通して、 Temporal API のことを調べるきっかけになったのはもちろん、自発的に登壇する人のコツのようなものの言語化が進んだのも収穫でした。 いままでできなかったことができると壁を乗り越えた爽快感のようなものがありますね。
次は実際にコード書いた体験や経験をお伝えできるといいなと考えています。
……と書いていたのですが、なんと次回の Kyoto.js #23 は 2024年12月18日（水） 19時開始です。 ぱすたけさんは「ISUCON 14の Node 実装の話をするかも」と言ってたので興味がある方はぜひご参加を！ 懇親会で根掘り葉掘り聞いていきましょう！！！
