TokyoWomen.rbを開催するにあたって私が考えていること
はじめに
3/1（土）にTokyoWomen.rb #1 というイベントを開催します！
女性の登壇者を増やし、技術イベントのジェンダーバランスを改善することを目標としたもので、登壇者は女性（性自認が女性の意味、以下同じ）のみ、参加者は性別不問となっています。
興味深いトピックが集まりすごく「濃い」タイムテーブルとなっています。
https://tokyowomenrb.connpass.com/event/342573/
まだまだ参加者募集中ですので、どなたもぜひご参加ください！
この記事では以下、私がなぜTokyoWomen.rbを開催するか、開催するにあたってどんなことを考えているのかをお伝えできればと思います。
Kaigi on Railsを主催する中での気づき
私はKaigi on Railsという技術カンファレンスを立ち上げて主催しています。2020年が第1回だったのでもう6年目になるのですが、開催を重ねていくうちにひとつ気になることがでてきました。
Kaigi on Railsでは、CFP形式で発表を募集しています。これは発表を公募するため、発表をしたいという人々からいわゆる「プロポーザル」の提出を募り、それが審査されて採択された人のみが登壇できるというものです。
Kaigi on Railsでプロポーザルを募集する際にフォームの中に性別情報を入力する欄を設けていないため（またもちろん性別は公表されていない限りプライベートな情報であるため、）プロポーザル提出者の性別は実際には我々にはわかりません。なので厳密ではなくあくまで印象としてではあるのですが、ざっくり言うとプロポーザル全体における女性の割合はだいたい多くても10%、少ないときにはそれを下回るという認識です。
一方、毎年イベント開催後に募集している参加者アンケートの方には性別入力欄があり、これによると例年の参加者に占める女性の割合は15%以上20%未満になります。（もちろん、アンケートに関しては回答者のみであるのでそこでバイアスはあります）.
つまり女性において、参加者とプロポーザル提出者の比率にアンバランスさがある、といえます。
女性からのプロポーザルが少ないと何が問題か
Kaigi on Railsでは例年、プロポーザルの通過率に性別差はありません。ですので、母数となるプロポーザルの女性割合はそのまま登壇者における女性割合になってしまいます。
私は昨年2024年、Rubyのものだけではなく多くの技術カンファレンスに参加しましたが、女性登壇者（あくまで印象ですが…）の割合はやはり10%くらいにとどまるケースがほとんどであったように思います。また、女性登壇者が不在というケースも少数ありました。
カンファレンスに女性登壇者がいないことによって問題になったケースとして、過去に海外ではカンファレンスそのものが中止になった事例があります。以下のスライドに紹介されています。
https://speakerdeck.com/a_matsuda/a-rubykaigi-talk?slide=48
女性登壇者がいないカンファレンスは、開催側にそのような意図が全くなかったとしても、結果的には多様性の尊重に対して後手に回っているという点に課題があります。Kaigi on Railsにおいては幸いなことに女性登壇者が不在の年はありませんでしたが、Kaigi on Railsのような全国規模の大型カンファレンスではその社会的責任から見ても女性割合をIT業界における女性エンジニアの割合（ https://www.jisa.or.jp/Portals/0/report/basic2023report.pdf?20240410 によると約16%）に近づけたいし、近づけるべきだと考えています。
また、多様性に関しては、私は「それ自体が価値であるので、他の価値を毀損しない限り尊重すべき」という立場を取りたいと考えています。その立場からは、女性からのプロポーザルが少ないというのはそれ自体が解くべき問題の一つということになります。
私自身はKaigi on Railsを始める前から例えばRails Girlsのコーチを務めるなど、ソフトウェア開発の世界における女性の少数者性というのは元々自分の関心の中にありました。その関心と、Kaigi on Railsという自分が関わる現実的な場の存在が結びついて、何かやってみようという気持ちになったのが2024年の中頃のことでした。
登壇の機会を増やすために
何がプロポーザル提出の妨げになっているかを考えると、
- 時間がない（会社での仕事が忙しい、あるいはプライベートで余裕がないなど）
- 自信がない（話す内容への自信のなさ、人前で話すこと自体への不安など）
- 安全上の懸念（個人が特定される状況で人前で話すことに抵抗があるなど）
- 少数派ゆえのハードルの高さ（男性登壇者ばかりの中で少数派になるのを避けたいなど）
などなど私が思いつくだけでもいろいろな理由があるだろうと予測されますし、あるいはもっと他にも大小さまざまな固有のつまづきがあるのかもしれません。
これら全ての障壁を取り除くのは難しいとしても、うちいくつかはカンファレンスやイベント開催のレベルでも取り組みができそうです。
TokyoGirls.rbの存在
実は、ここに書かれたことを踏まえても先進的なイベントがすでに存在していました。それがTokyoGirls.rbというイベントです。
このイベントは登壇者を女性に限定しつつ、参加者は性別を問わないというものです。趣旨や工夫などについては主催の伊藤さんのブログ記事に詳しく書かれています。
私は当時TokyoGirls.rb meetup vol.1およびvol.2に参加していました。イベントとしての体験が良かっただけでなく、同時にイベントの開催自体に社会的意義があると思いました。登壇者の面々もベテランから始めて登壇するという人まで多様性に富んでおり、また他の参加者と喋っていると「初めてこういったイベントに参加した」という人の割合が自分が普段参加しているイベントやコミュニティの場と比べても段違いに高く（その多くは女性）、新しい層を開拓できていると感じていました。
そういうわけでTokyoGirls.rbの続編を待っていたのですが、コロナ禍もあり気づけば2024年になってしまっていました。そのとき女性登壇者の少なさを解消する方法を探していた私はTokyoGirls.rbを再開することを思いつきました。そこで主催の伊藤さんに連絡を取ってもし可能であれば自分が主催で開催したい旨を共有し、結果的に名前をTokyoWomen.rbに変えてリブートすることになったのです。
次のステップにつながる場としてのTokyoWomen.rb
今回、TokyoGirls.rbから見てのマイナーチェンジを行っています。それは、トークをより技術的な方向にシフトするということです。プロポーザル募集ページにも「今回は技術的なトーク・Rubyのコードが出てくるトークを優先して採択します」という文言を入れました。これは、将来の技術カンファレンスへの登壇者を増やすことにつながるような場を作りたいという想いによるものです。
そこでTokyoWomen.rbは女性登壇者限定でかつRubyに特化したイベントとして登壇者を募ったところ、とてもたくさんのすばらしいプロポーザルをいただくことができました。
結果完成したタイムテーブルを見ると、Railsはもちろん、Ruby内部のコードリーディングやwasm、ゲームから自由とAIまで盛りだくさん、バラエティ豊かなラインナップでイベントを開催できることになり、私自身も大変楽しみにしています。
今回TokyoWomen.rbに登壇した方々が将来Kaigi on RailsやRubyKaigiに登壇するようになったらそれはとても嬉しいことだと思います。
では、3月1日にSmartHRさんオフィスでお会いしましょう！
2024年を振り返る
この記事について
気づけばまだ今年1つもブログ記事を書いていない大倉です。色々書きたかったことはあるのですが、全く手が追いついていないため、この記事に全てを入れ込もうと思います。 この記事自体はオーソドックスな（そんなものがあるのだろうか）1年の振り返り記事となっています。書き始める前は「今年は割と何もしていない1年だったなあ（何もないとは言っていない）」だったのですが、書いてみると結構活動的でしたね。
2024年の振り返り
1月
1月はBuriKaigi 2024で登壇しました。この時のネタが「なぜRubyにはBooleanクラスがないのか」というもので、私としてはニッチなテーマと思って臨んだのですが発表資料が意外なほど（2000超、私の資料にしてはとても多い）見られていたので、今後もこのテーマで発表することがあるかもしれません。 懇親会だけでなく会場内にもブリしゃぶがデプロイされており（しかも大学構内）、ブリを堪能しまくることができたイベントでした。
2月
2月はDevelopers Summit 2024でKaigi on Railsについて発表しました。これは元々類似した内容のプロポーザルを送って落選したものを、リレーセッションの一部として発表したものになります。このリレーセッションは「オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッション」と題されたもので、他の乙団社の方々もPHPカンファレンス、PyCon、CloudNative Days Tokyo、技術書同人誌博覧会という様々な団体から参加されており、技術コミュニティの今後を考える上でも興味深いものだったと思います。
また、Kaigi on Railsはこのあたりから動き出しており、初回の顔合わせを行ったのもこの月でした。新しい運営メンバーがたくさん増えたこともあり、早めに顔合わせをして今後の運営をスムーズにする趣旨でしたが、これはやってよかったことの一つで来年以降もやれたらなと思います。
3月
3月はPHPer Kaigi 2024とObject-Oriented Conference 2024という、これまで参加したことのないカンファレンス2つに参加してきました。いわゆる「異文化交流」的な気持ちと、Kaigi on Railsをやるにあたって参考になるものを探そうという気持ちがありましたが、新鮮な気持ちでカンファレンスを楽しむことができました。例えばブース1つをとっても、Rubyコミュニティとは出展している企業が違うのではじめましての出会いもたくさんありました。 Object-Oriented Conference 2024では飛び込みLTをしました。
4月
4月は発表したりカンファレンスに行ったりはしていないのですが、変わり種として大阪で開催された虚構新聞展に日帰りで行ってきました。知っている人は知っている虚構新聞というサイトですが、昔からファンで社主（いわゆる中の人）との親睦会に行ったこともあります。というわけで、ちょっと気分転換も兼ねて大阪まで新幹線に乗って日帰り旅行をしたというわけです。
5月
5月はなんといってもRubyKaigi 2024がありました。例によってプロポーザルは通りませんでしたが、沖縄開催ということもあって観光としても楽しむことができました。トークも3日間を通して結構たくさん聞きましたが、ぺんさんのキーノートが圧巻だったのはもちろんのこととして、kateiさんがブラウザの中でMastodonのサーバーを動かすトークも技術的に高度すぎて理解が困難でした。個人的に最も興味を惹かれたのはvinistockがRubyの開発ツールが多様すぎることについて語ったトークです。自分はこれまでNiwaというドキュメンテーションツールを開発していてそれでプロポーザルを出してもいたのですが、それはRDocとYARDの統合を意識したものでした。このトークで改めてドキュメンテーションツールの統合の必要性を感じたのですが、最終日の夜のとあるバーでIRBメンテナのStanに「RDocをやるべきでは？」と説得され、これらのことが相まってRDocにドキュメンテーションツールを統合する方向で考えていくことになります。 また、TSKaigiに参加したのはRubyKaigiの直前でした。基調講演をするためにアメリカから来ていたDanielを会場で捕まえて結構長いこと話していました。
6月
6月はRubyKaigiのアフターイベントが複数あったのに参加していたのと、Rubyistが集まって将棋を指すイベントに参加したりしていました。最近はYouTubeの将棋動画をよく見て勉強（これは勉強なのか？）していたりはするのですが、人間と対面で指す機会はあまりないので貴重な場でした。 Kaigi on Railsの準備が本格化するのはこのくらいの時期で、打ち合わせの回数が増えていました。同時並行で2025年の会場下見も行ったりしていたので、なんだかんだ結構忙しかったと思います。
7月
7月はRed Dot Ruby Conference 2024に登壇してきました（サイトはリンクが消滅しているっぽい）。内容は「まともなDSLを作るにはどうすればいいか」というテーマでの発表で、これまで自分がDSLについて考えてきたことの集大成的なものになっています。
イベントはシンガポールで開催されたので、1週間ほどシンガポールに滞在して観光も楽しんできました。特に日本からの参加者とAaron Pattersonの4人でドリアンを食べまくったのが印象的です。またシンガポールは島国ですが、対岸にはマレーシアのジョホールバルという都市があるので、そこにも1泊しました。 7月はKaigi on RailsのCFPがオープンしている期間でもあったので、登壇相談会を2回開催しました。これは毎年恒例になっている、プロポーザルを出したい人が私に相談するイベントです。Kaigi on Railsではチーフオーガナイザーという立場でやっていますが、ここでは一人の個人としてプロポーザルの相談に乗っています（実際、Kaigi on Railsでは採択する運営メンバーのうちの一人でしかなくスコアも他のメンバーと同じなので、ここでのやり取りが採択に決定的な影響を与えることはありません）。
8月
8月は怒濤のプロポーザル採択でした。今年は100件を初めて超えた昨年を遙かに上回る193件のプロポーザルが来ました（ありがたいことです）。これだけの量を見るとなるとかなりの時間が必要なのですが、一方でなるべく早く結果を確定させたいという気持ちもあり、結果として月の頭にがんばるしかなくなってしまいます。運営メンバーは原則全員が約一週間以内に全てのプロポーザルにスコアを付けるため、ここはふんばりどころという感じです。 8月には大阪Ruby会議04もありました。こちらにはプロポーザルを出したのですが通らなかったので一般参加者としての参加でした。トークの密度が高く、ベテランを中心としつつも多様なスピーカーがいて地域Ruby会議らしいカンファレンスだったなと思います。カンファレンスの翌日は大阪に住んでいる同僚に車を出してもらって主に京都を観光しました。京都でも普段行けないところに行けたので新鮮でした。来年は関西Ruby会議もあるということなので、今度こそプロポーザルを通したい…！
9月
9月はFukuoka Rubyist会議04があったりTokyuRuby会議15があったりしました。福岡ではPrism作者のKevinとLrama作者の金子さんがキーノートということで「Parser会議」っぽさがありましたが（他の登壇者もパーサー関係者が多かった）、改めて2024年のパーサー熱を感じることができました。観光は1日しか時間がなかったのですが、門司港から気分で下関にまで船で移動し、巌流島に行って戻ってくるというルートが自分的にはハマっていて楽しかったです。 Tokyuは前回のLT王として参戦しLTをしました。RubyのオブジェクトをJSONにシリアライズする方法を15個紹介するというトークでしたが、残念ながら連覇はなりませんでした。LTのレベルが全体的に高く、王を取れないのも納得という感じ。LT王への道は 長く険しい…！（そしてご飯とお酒はいつもながらハイレベルでした、皆さんありがとうございました！）
10月
10月にはKaigi on Rails 2024の本編がありました。が、その前に松江Ruby会議11に登壇者として参加していました。内容は最近取り組みたいと思っている（でもなかなか取り組めていない）RDocの拡張システムに関する発表で、課題意識を共有するトークでした。初参加でしたが、アットホームな雰囲気で（Matzが目の前で聞いていたりする）リラックスして発表できました。観光では隠岐の島に行く予定でしたが、雨だったので予定を変更して温泉津（「ゆのつ」と読みます）へ行ってきました。46度の温泉に挑戦したりして楽しかったのですが、最終日に行った石見銀山では落盤があったり各施設が閉まっていたり雨だったりで空振りに終わったのでまた行きたいですね。 さて後はKaigi on Railsだ、となったのですが、なんとこのタイミングで風邪を引いてしまい、当日も体調不良で迎えることになってしまいました。ですのでトークはほとんど聞けていなかったりします。私不在の中カンファレンスを運営してくれたメンバーに感謝。
11月
11月はKaigi on Railsのアフターイベントに全て参加しました。11月になると体調はだいぶ回復していたのですが、まだ本調子とは言えない状態でした。アフターイベントの数は今年が最多だったと思うのですが、Kaigi on Railsの盛り上がりを（当日感じられなかったぶんも含めて）感じられてよかったです。
12月
12月はRubyWorld Conference 2024に参加しました。10月に続いての松江ですが、今回は純粋に参加者なので終始のんびりと過ごしていました。1階の大ホールでブースを巡ったりモニターでトークを聞いたり、今年は1階で過ごす時間がとても多かったです。観光は出雲大社とその隣の博物館へ行きました。銅鐸や銅剣が壁中に展示してあって圧巻でした。
まとめ
これを書いている時点で2024年はあと9分で終わります。皆さん、よいお年を！
Kaigi on Rails 2023を開催した
はじめに
いつものように、Kaigi on Railsの振り返りを年末に書くことになってしまいました。皆さん良いお年を。
というわけで
Kaigi on Rails 2023が開催されました。この記事では開催にまつわるあれやこれやを書きたいと思います。
準備の話
会場の選定
2020年にKaigi on Railsを初開催して以降、2022年までオンライン開催だったので会場について気にする必要は（良くも悪くも）ありませんでした。しかし2022年初頭の時点で「来年は物理開催ができそう」という予測があり、初めて浅草橋ヒューリックホールの下見に行ったのは2022年4月でした。かなり良い会場だったため、他の会場には特に下見に行っておらず、ほぼ即決に近い状況でした。 ポイントは駅から近いこと、人数が400人ほどとちょうどよい大きさであること、2トラックできること、ブースがそこそこ置けること、配信を手伝ってもらえることなどでした。これら全ての条件を持っている会場は意外なほど少なく、結果的にほぼ即決になったわけです。 会場は1年前からしか本予約ができなかったため、いったん仮押さえをしてもらって2022年はその年の開催に集中することとなりました。去年の感想記事に
オンラインでのやり残しがないようにする
とあるのですが、まさにその勢いで過ごしていたため、2023年の準備を本格的に始めるのは2022年10月以降となりました。
2023年に入って以降の準備
初めての物理開催ということでどういうことが起こるがあまり予想が付かなかったため、以前よりもスケジュールを気にしながらの準備となりました。特に2022年との差分であるスポンサーブース（物理）や会場で必要な諸々のサイン（受付はこちら的なやつ）については2023年に入った時点で意識に入れつつ準備を進めていきました。 例年通りに基調講演について早めに固めつつ、スポンサー募集とCFP公開を順次進め、プロポーザルを選定するところまではこれまでとあまり変わらずにできたのですが、9月頃から会場とのやり取りの回数が増え、スポンサーさんとのやり取りも例年以上に頻繁になってきました。 最終的にはチームメンバーが多くの部分を拾ってくれたため、なんとか当日に間に合ったという感じです。感謝。
当日
ブース
物理ブースの存在は2023年における最大の変化かもしれません。これまでも2021年と2022年にオンラインブースはあったのですが、人の流れと会話の量という点で物理ブースには勝てないということが明らかになっていました。そこで物理開催における重要ポイントの一つはブースということになります。
ブースの設置数は会場との兼ね合いなのですが、今回の会場のサイズ的に10社くらいが限度そうでした。そのため、厳正なる抽選（Array#sample）を行い、多くのスポンサーさんに対してお断りをしなくてはなりませんでした。誰も得しないのでできればお断りしたくはないのですが、こればかりは大きな会場を確保できない限り起こるような気がします…
当日のブースはとても賑わっていて、物理開催の良さが一つ表れているなと感じました。各社ともかなり力が入っていて（ありがとうございます！）、個人的にも楽しませてもらいました。
懇親会
懇親会も2023年で大きく変わったものの一つです。物理で開催するということはもちろんなのですが、これまでのオンライン懇親会ではすでに仲良くなった人たちしか来ず、新規参入者が少ない、という印象があったため、それを変えたいと思いました。 そのため、懇親会のチケットを別売りにすることはせず、本編のチケットにバンドルすることにしました。さらに懇親会の会場を本編と同じ場所にすることにより、できるだけ離脱を減らすようにしました。 その結果、目測ではありますが本編参加者の8割近い数の参加者がありました。多くの方に楽しんでいただけてよかったと思いますし、今後もこの形式でやっていくのが良いという手応えもありました。
フリースペースやハックスペースなど
今回は物理開催ならではということと、会場にちょうどいい大きさの部屋が複数あったということで、今回は各部屋を様々に活用してみました。 まずはサテライト会場です。これはROOM Bが少々手狭であるということから、大勢の人がROOM Bに来た場合に参加者がROOM Bの動画を見れる部屋を別に用意するというものです。一定の需要があったらしく、常に参加者がいる状態だったようです。 ハックスペースもありました。フリースペースとは違ってこちらの部屋には電源があったのですが、あまり積極的に周知しなかったこともあってそれほど利用されていなかったようです。これは課題といえば課題なのですが、そもそも次回の会場に電源を供給できる部屋があるのかもわからないのでなんとも言えません。 そしてフリースペースです。この部屋はかなり広く座席数も多い部屋なのですが、積極的に活用するというよりはむしろ解放しておいて自由に使ってもらうようにしました。机と椅子に関しては会議室的な正面向きの配置ではなく、互いに向き合うように配置して会話しやすいようにしました。これは前日準備で運営メンバーから出てきたアイデアで、実際やってみると非常にうまくいきました。「廊下」的な機能性なのですが、物理的な廊下が狭い会場では廊下部屋を作るのが有効であるという知見を得ました。来年以降も実装を検討したいですね。 フリースペースには水道などの設備があったため、なんとねこのやのogijunさんをお呼びしてコーヒーを淹れていただきました。ogijunさんはKaigi on Railsの名付け親ということもあり、また私がコーヒー好きのため、個人的にもぜひやりたいということで実施の運びとなりました。こちらは満員と行列を避けるために意図的に周知していなかったのですが、それでもかなりの杯数が出たようです。やはりカンファレンス会場で飲む深煎りコーヒーはいいですよね… コーヒーについては元々RubyKaigi 2019で同様のことが行われていた（ただし部屋の外で提供して部屋の中で飲むスタイルだった）のですが、その時と比べると部屋の中でコーヒーを提供する関係でogijunさん周辺に人だかりが出来ていたのが今回の変化でしょうか。もくもくとコーヒーを淹れるというよりはにぎやかな感じで楽しそうでした。島田浩二さんがコーヒースタッフ業（？）をやってらっしゃったのが印象的です。
コンテンツ
今年は初めての2トラックということでした。初めましての登壇者あり、久しぶりの登壇者あり、3人での登壇あり、3年連続の登壇者ありとバラエティに富んだ方々によるトークの総数は基調講演を含め36と過去最多となりました。どのトークも興味深かったのですが、分身の術を得ていないため全て見ることはできませんでした。先日YouTubeに動画が全て公開されましたので、今順次見ているところです。ここでは基調講演の個人的な感想を書きたいと思います。
zzak
zzakは実は日本語で基調講演をしてくれるのでは、と期待していた部分もあるのですが、最終的には英語でのトークとなりました。といっても内容が日本語でスライドに書き込まれていたため、内容を理解するのに支障はなかったと思います。 zzakは昔から活動している人ですが、まとまったストーリーを聞くのは初めてだったのでなるほどと思いながら聞いていました。しばらく触っていなかったRailsをまた触るにあたってissueを全部読むなど、Railsにかける想いが伝わってくる話でした。将来への展望も聞けたので今後も楽しみですね。
byroot
byrootは遠方に住んでいるため動画でトークとなりました。RubyKaigiの会場で直接会って打ち合わせをして最終的に承諾をもらったのですが、実はbyrootは過去の登壇がほとんどなく（探しても見つからない）、非常に貴重なトークになりました。 内容は過去のバグ修正についてですが、特に2つ目のバグはActive Recordのdupの挙動とMarshalの挙動とObject Shapeのobject too complexの挙動とが全て合わさって起こるバグであり、説明を一度聞いただけでは理解できないようなバグでした。byrootはRailsコアチームのメンバーでありかつRubyコミッターでもあり、またObject Shapeの開発にも関わっていたということでバグを直すことができたとのことですが、さすがと言うしかない。
データで見れないKaigi on Rails 2023
見出しは出オチですが、実際、物理開催では例えば参加者の性別のようなデータを正確に取ることは困難です。アンケートに記入する欄はあるのですが、アンケートの回答率はそこまで高くはないので（回答してくださった方ありがとうございます！）、やはり全体像をつかむまではできません。 それでも語れるいくつかのデータとして、例えば実参加人数を見てみましょう。約380人の会場参加登録がありましたが、チェックインは約370人となっています。つまり10人くらいの人は参加費を払ってはいるが実際には来なかったということになります。全体から見ると3%ほどということになりますね。これはいわゆるオーバーブッキングを行っても問題が起こらない可能性を示唆しています。15000円の参加費でもこれくらいの人数が来ないのであれば、もっと安ければさらに来ない人は増えるでしょうから、キャパに対して5%ほど上乗せした人数を入れることは可能そうです。 YouTubeでの視聴に関してはしっかりとしたデータが取れています。それによると、Day2のROOM Aはユニークな視聴者が約600人います。これは興味深いことにオンライン視聴チケットの数を超えています。おそらくTLなどから流入した方がいるのでしょう。平均視聴時間は約20分と非常に短く、見たいトークを1つだけ見るという使い方になっていると思われます。 こうしてみると、カンファレンス参加の形というのは非常に多様なのだなと感じます。物理参加の人たちは2日間ずっと会場の近くにいて人と話したりトークを聞いたりする一方、1つのトークを動画で見るだけの人もかなりの数いるということです。Kaigi on Railsはカンファレンスの敷居を下げることを当初より意図して設計されており、今回の結果もまたその方向性を後押しするものとなるでしょう。
さいごに
さて、ここまで2023年のKaigi on Railsについて書いてきました。2024年についての情報はもう少しお待ちいただくとして、最後に告知があります。 2024年2月15日16日にベルサール羽田空港で開催されるDevelopers Summit 2024にて、オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッションに登壇することになりました。私はKaigi on Railsからの参加ということで、「初学者から上級者まで」という部分にフォーカスしたトークをする予定です。現地でお会いできることを楽しみにしています！
おまけ
画像を置いておきますね。
RubyConfTw2023の感想記事
はじめに
この記事はフィヨルドブートキャンプ Part 2 Advent Calendar 2023の24日目の記事です。23日目の記事はかわかみさんの空手とフィヨブーと私：なにが「たのしい」のか？でした。
お詫び
まだ色々書けていない記事があるのですが、年内には書くので許して…
カンファレンスについて
今年が10回目のRubyConfTwに登壇者として参加してきました。参加者としての参加も含めて今回が初参加です。今年は日本から多くの登壇者がいました。 最初に言い訳をしておくと、自分のトークが2日目だったのと、来るときに飛行機が3時間近く遅延したりして若干疲労していたのもあり、初日はあまりトークを聞けていません。そしてなんと自分以外の日本人登壇者が全員初日だったため、結果として多くを聞けていません。 ランチドリンクがタピオカミルクティーだったりと台湾らしい要素もあり、中国語のトークをGoogle Meet経由の同時通訳で聞いたりと興味深い試みもあり（運営が機材を用意する必要がないのがよい）、楽しく過ごせました。
自分のトークについて
今回は"Writing Minitest clone in 30 minutes"というタイトルでライブコーディングを含むトークをしました。タイトル通りにMinitestっぽい機能、特にautorunを中心に約30分で実際にそれっぽく動作するものを作るという内容です。
今回のトーク、実はEuruko2023からの続きになっています。そちらでは「RSpec」を「読む」がテーマだったため、今回は「Minitest」を「書く」と内容を反転させてみました。時間も同じ40分で、やっぱりライブラリの深い部分というか実装に近いところについてのトークをしようと思ったら最低でも30分、できれば40分はほしいですね。
ライブコーディングというと難しそうですが、実際には準備をキッチリとしていれば意外となんとかなります。時間に余裕を持たせて、多少エディタの操作でミスをしても間に合うように調整すれば大丈夫です。実際、今回も変数名をtypoしていたのを聴衆に助けてもらったのですが、そういう事態を事前に織り込んでおけばよいのです。あとはエディタやターミナルの操作に熟達すること。これは日々の仕事にも効いてくるのでなんにせよやっておくと良いです。
Minitestはライブラリのテストに使っており、Minitestについて紹介するというのもこのトークの一つの目的でした。MinitestはRailsアプリに対して使われることこそ（何故か）少ないものの、シンプルで高速なテストが書けるのでもっと使われてもいいと思っています。
余談：登壇ネタを思いつくことについて
今回のネタは前述のようにEuruko2023のネタを反転させただけなので、そこまで思いつくのが大変ということはありませんでした。ではEuruko2023のネタはどうしたのかというと、サイトにRSpecのテーマが人気だと書いてあったのです。それを見た私はRSpecに関する何かで登壇することに決め、結果的にコードリーディングになりました。元々RSpecが好きで記事を書いていたこともあったのですが、それ以上にRSpecについて話したい動機が私にはありました。 それは勉強です。こういうと変な言い方ですが、プログラマとして10年近く仕事をしていると、大抵のことはなんとかなってしまいます。私は怠惰なので、こうなると勉強をサボります。そこで「登壇駆動勉強」として、定期的に良く知らないテーマについて話をするようにしています。実際、RSpecのコードを読んだことがあるから登壇したのではなく、RSpecのコードを読む理由がほしかったから登壇したというのが本当のところです。今回も、Minitestっぽいものは割と書けそうだし書いてみたいという気持ちが元々あった部分があります。
台湾観光について
今書いています…もうちょっと待ってね…
プロポーザルについて2023 - 作文術とか
はじめに
Kaigi on Railsの運営メンバーであるunasukeがプロポーザルに関するいい記事を書いてくれていました。
https://blog.unasuke.com/2023/kaigionrails-proposal-writing-guide/
この記事の最後に
通過するproposalを書くための作文術(どのように書くか)ではなく
とあるので、この記事ではそれを受けてプロポーザルがより通りやすくなるようなコツについて書いてみようかなと思います。
前提：プロポーザルを出すということについて
しかし、プロポーザルを通す前にはまずプロポーザルを提出しなくてはなりません。これをハードルに感じる人もいるかと思います。そこで、プロポーザルを出すハードルを下げるようなことをいくつか書こうと思います。
プロポーザルを書くことで自分の知識や知見が整理される
個人的に重要視していることとして、プロポーザルという形式はアウトプットをする最も良い方法の一つだと思っています。書いたプロポーザルは公開されない場合も多いので、あまり読み手のことを気にせずに書くことができます（もちろん読み手がいる以上は考えるのですが、例えばよく知らない人からのマサカリとかは来ないわけです）。また、プロポーザルは字数に制限があることも多く、結果として自分が話したいことを「端的に」表現することになります。
これらの結果として、プロポーザルは自分が言いたいことに関するノイズがそぎ落とされた表現となります。プロポーザルを書く過程で「なるほど、自分が考えていたのはこういうことだったのか」となることもよくあります。ここで得られたものはプロポーザルの当落に関わらず今後の糧となります。
ですので、「落ちたらどうしよう」と考えすぎるよりはとりあえず出してみるとよいでしょう。実際、落ちても何も起こりませんし（私も数え切れないプロポーザルをrejectされています）。
カンファレンスで話すと注目される
これは人によってはメリットにならないかもしれませんが、カンファレンスの登壇者は一般参加者に比べて注目されやすくなります。これは特にフリーランスのように自身の知名度を商売道具にするケースでは非常に強力です。
また、副次的な効果として「懇親会でのコミュニケーションが楽になる」というのがあります。登壇者は質問をされることも多く、自分から話しかけに行く必要があまりありません。自分のトークというネタがあるため会話にも困りません。結果として知り合いが増えることで今後のカンファレンスに行った際の助けにもなります。
ちなみにこのこと自体はイベントの規模にかかわらず発生するので、最初は地域Rubyコミュニティなどで発表してみるのもオススメです。
プロポーザルに何を書くか
プロポーザルを書くに当たって考慮すべきことは三つあります。内容と構成とテクニックです。このうち、構成については冒頭のunasukeの記事で書かれているため、ここからは内容面とテクニックについて書きます。
実際に手を動かしたことを書く
「自分が実際に行ったことについて書く」のは重要です。「その人にしか話せない」ようなプロポーザルであれば通る確率はかなり高くなります。そして、自分にしか話せないことを書こうとすると多くの場合自分が実際に行ったことについて書くことになります。
手を動かした内容が日々の業務の中であっても全く問題ありません。各社が業務内で行ったことは公開されにくく、しかし実際に共有されると多くの人の役に立つという性質を持っています。Kaigi on Railsは特に「明日からの仕事に役立て」るということがコンセプトの一つになっているため、業務に直結した内容は比較的通りやすい傾向があります。
ここでの「手を動かす」はコードに関することでも良いですし、それ以外のこと（例えばマネジメント的なこと）でも構いません。また、OSSに関することでも良いですが、自作OSSの自慢的な話は（少なくともRubyKaigiと比べると）通りにくいです。これは単に方針の違いであり、自作OSSの自慢が良いとか悪いとかいうことではありません。
カンファレンスの傾向を把握する
今まさに説明した「方針の違い」というのは非常に重要です。方針に反するプロポーザルは原則として通りません。これらの方針は明記されている場合とそうでない場合があります。Kaigi on RailsではCFPページがありそこに具体例が挙げられています。もし不安がある場合は過去のトークを見てみるとよいでしょう。
Kaigi on Railsの場合、CFPページに「Rubyに特化した話題については、優先度が下がるかもしれません」と明記されています。こういった方針に関しては事前に把握してプロポーザルを出すことが求められています。
プロポーザルを通すテクニック
ここでは私が考える、プロポーザルを通すためのテクニックについて書きます。
アピールするポイントを明確にする
プロポーザルには必ずアピールとなるポイントがあります。例えばそれは新規性であったり網羅性であったりします。それを絞ることで採択する側がどこに注目すべきが明確になります。例えば非常に重要なトピックについては網羅性に重点を置いたプロポーザルは評価が高くなるかもしれません。あるいは新しいテーマや切り口であれば「これまでどこでも議論されていない」ことを強調してもよいかもしれません。
明確なアピールポイントが存在するプロポーザルは採択する側の目に留まりやすくなります。プロポーザルはかなりの数に目を通すため、目立つことは予想以上のアドバンテージとなります。
聴衆を明確化する
もう一つ明確にすべきポイントは聴衆です。例えば入門的なトークをする場合、すでにそのトピックについて詳しい人は得るものが少なくなりがちです。そこで事前にプロポーザルに「詳しくない人がターゲットです」と書いてしまいます。この方法のメリットはいわゆる「枠」に収まりやすくなるという点です。多くのカンファレンスはバランス良くトークを配置しようとする傾向があり、それはある程度意識的に「初心者枠」のようなものを考えながら採択をするということにつながります。ターゲットが明記されていることで枠に入りやすくなります。
これは実際に資料を作る過程でも有効です。聴衆が明確にされていることが入れるべき内容と落とすべき内容がハッキリとしてきます。
分量を書く
冒頭のunasukeの記事にもありましたが、分量はないよりあったほうが絶対に有利です。採択する側も人間なので、がんばってたくさん書いてくれたものは通したくなりますし、逆に手抜きに見えるものは通したくなくなります。それを抜きにしても、実際に登壇する際のイメージが湧くと安心して採択できるので、そういう意味でもたくさん書くのはオススメです。
さいごに：まずは出してみること
残念なことに、提出された全てのプロポーザルに対して主催側がフィードバックをすることは各種の制約により不可能です。ですが、個別にフィードバックを求められた場合は応じるケースもあります（Kaigi on Railsでは可能な限り応えたいと思っています）。もしいいプロポーザルを書けたはずなのに落ちてしまったなら、主催者にコンタクトを取ってみてもよいかもしれません。プロポーザルの提出に使われているアプリケーションによってはその中でやりとりをすることも可能ですが、他の手段もあります。
プロポーザルは出してみないとコツがつかめないと思います。私もキャリアの初期に出したプロポーザルはあまり良いものではなかったはずです。しかし、プロポーザルを出すことを続けるうちに内容や書き方が洗練されていきます。
そもそもプロポーザルは落ちるほうが普通の世界です。倍率はイベントにもよりますが、直近のRails Worldでは6倍になったそうです。通る確率は約15％ということになりますが、ここまで極端でなくても3倍程度の倍率は珍しくありません。プロポーザルの当落にはある種の運も絡んできます。
ですので、「落ちたらどうしよう」と考えるのはあまり有意義とは言えません。むしろ落ちて当然と思いつつ、しかし最善を尽くして書くのがよいでしょう。
皆さんの渾身のプロポーザルをお待ちしています！
RubyKaigi 2023の感想
TL;DR
最高でしたね。LTができたのと多くの人と話せたのが特に良かったですが、トークやパーティーなど、これぞRubyKaigiという感覚が非常に強くて感動しました。
はじめに
この記事はRubyKaigi 2023の感想記事です。基本的にはRubyKaigiについて知っている人を対象としています。基本的な情報は記載しません。
一言でいうと
最高でした！ いや、なんでしょう、RubyKaigiは2016年から基本毎年参加していて（2018年のみ不参加）、全部楽しかったのですが、今年は自分にとって今までで一番楽しかったです。
この記事の構成について
この記事は主に3つのパートで構成されています。
まず最初は私が聞いた各トークの感想です。なお、トークのメモは一切取っていない（忘れたというよりは、気力が持たなかった）ため、うろ覚えでの記述になっていることをご承知おきください。
次のパートは私がLTで行ったトークについてです。プロポーザルを提出するまでのこと、採択されてからの準備、実際に行ってみての感想などを書きます。
最後は今回のRubyKaigiの楽しさの理由について振り返ってみます。主に3つの理由が思いつくのでそれらをそれぞれ考察していきます。
トーク感想（Day1）
Matz Keynote
いつものMatz節が炸裂する場面もありましたが、今回は過去の話がメインだったこともありいつもとは少し毛色が違った気がします。Rubyの開発にはやはり色々な苦労があったのだなあと思いつつも、「なんだかんだで楽しんでいるんだなあ」と感じました。
MatzにDrinkupにて「英語をどうやって勉強しましたか？」と聞いたところ「勉強していません」と返されたのですが、自然体でRubyの開発（や英語）をできてしまう（ように見える）のがすごいですね。
Matzが引退したあとのRubyはどんな感じになるのか現時点では想像できませんが、いずれそういう日は来るのだよな、ということに思いを馳せたりもしました。
The future vision of Ruby Parser
実はこのトークはほとんど見れず、というのも昼食に思ったより時間がかかってしまい間に合わなかったのでした…
あとでLramaがコアにマージされたことを知り、金子さんの腕力に驚いた次第です。Bisonを置き換えるのすごい…
"Ractor" reconsidered
やはり並列処理は難しいのだなあ、というのが最初の感想です。GCが絡んだときの難しさについても語られていて、そこまで理解はできていないのですが難しいことはわかりました。
以前Ractorを試したときはたしかにパフォーマンスの劣化を経験したので、そこがどうにかなると実用するモチベーションが湧くのは完全にその通りだと思います。
自作のライブラリをRactor Friendlyにできればいいなと思っているのですが、その方法などについてドキュメントが整備されてくるとエコシステムの発展も進みそうだなと思いました。誰かやってくれ…
Power up your REPL with types
「型のキラーアプリ」ことIRB。型情報があると補完がリッチになるというのは型を導入する大きな理由になりますね。
ぺんさんはTRICKの人という印象が強いですが、IRBのissueを見るとぺんさんが作ったものが多く、たくさんのバグを見つけているのだなあと気づきました。
IRBには色々と独自の仕組みが導入されていると思うのですが、そこをShopify勢が作っているものと合わせていけたりすると面白そうと思いました。
LT
Building Ruby Native Extention using Ruby
トップバッターはかつよしさん、「これ終わるのか」と思うまもなく「これは終わらないな…」と思ったら案の定終わらないという綺麗な展開でした。内容的には興味深かったのでもったいない…
RBS meets LLMs - Type inference using LLM
最近流行のLLM（よく知らない）を型推論に使うというお話。個人的に今年に入ってから「Copilotでここまで補完が効くなら型はいらないのでは？」みたいなことを考えていたのでまさにドンピシャな内容。5分ジャストで終わったのもすごい。
Customize your Vim/Neovim directly with Ruby
私のLTです。詳細は後ほど。
mruby VM
MatzによるLT。基調講演とは変わって技術的な内容だったようです。「ようです」というのは、このとき会場内で迷子になっており、着席できたときにはもう終わりかけだったのでした。
Natsukantou the XML translator
Rackっぽいミドルウェアパターンを適用して翻訳精度を高めたgemの紹介でした。YARDのコメントを書く必要があるのが面白いですね。
BINGO!
Shugoさんが社長として抱える「ミッションクリティカルな」タスク、ビンゴゲームの実装についてのお話。WASMの実用例としてとても興味深いと思います。Fiberの制約を乗り越えるために事前にコードをERBを用いて展開しておく、というアイデアには脱帽です（この理解で合っているのかな？）。
Adding custom rule for Rubocop in the 2 month of employment
前回のRubyKaigiのMusic Mixinで転職に成功したゆらさんのお話。そして転職するとコードを理解するためにリファクタリングすることになり、そのためのCopを作ったというお話でもありました。Rubyコミュニティいいよね…
Unexplored Region - parse.y -
再びの金子さんが今度は爆速でparse.yの解説をしました。「初級編」から「上級編」まであるうちの「中級編」で時間が来てしまったのですが、一体「上級編」には何が書かれていたのだろう…と思って読んでみたのですが全然わからなかった…パーサーの道は険しい…
Ultra-fast test-driven development
RSpecを高速化するrsepc-daemonの紹介でした。確かに効果的なアプローチだと思うのですが、なぜ今までなかったのだろう…今回の全トークの中でも一番業務に取り入れやすいテーマだったような気がします。
Optimizing Ruby’s Memory Layout: Variable Width Allocation
Rubyのメモリ効率を改善するVariable Width Allocationの解説、というか導入でした。これはちゃんと話すと30分でも足りないみたいなやつだと思うので、5分だと導入だけになるのはやむなしかなと思います。余談ですが、舞台袖でLTの進行についての解説があったのですが、Peterはだいたいわかっていたようです。
Dividing and Managing: The Cops Squad of RuboCop RSpec Dept
rubocop-rspecからgemを切り出しているお話。FactoryBotについてのCopは独立していたほうが使いやすくなるので嬉しいですね。切り出しはこの発表の直前に行われていたということで、ここでも登壇駆動開発の姿が。登壇者のydahさんはここ最近活発に活動していてすごいです。
Serverless IdP for small team
RubyKaigiのオーガナイザーでもあるsorahさんのトークは認証周りのお話。Googleのような巨大な認証の仕組みはRubyKaigiチームのような比較的小規模なチームにとっては大きすぎるということで独自の認証基盤を作ったとのことでした。特にRubyKaigiのようなチームでは各メンバーがすでに認証基盤上にアイデンティティを持っているのでそれをOmniauth経由で使えるようにするという仕組みのようです。
トーク感想（Day2）
Implementing "++" operator, stepping into parse.y
何を隠そう私が関わったトークでした（スライドの英語レビューをした）。超満員で立ち見になりましたが、会場の沸き方はさすがしおいさん。内容的にもパーサーを丁寧に解説しており、今年っぽいトークでした。
Yet Another Ruby Parser
実装というよりはモチベーションなどにフォーカスしたトークでした。問題意識としてはすごくわかる（パーサー乱立しすぎ…）し、それを手書きでゴリっとやるというのもすごいなと思いました。もっと実装のことについて語られるとなお良かったかな…
これは金子さんのLramaとバトルになるんですかねえ…決めるの大変そう…
Revisiting TypeProf - IDE support as a primary feature
エディタが好きなのでこのトークは気になっていたのですが、TypeProfを書き直しているということでまずそれ自体がとても大変そうだなと感じました。結果として応答速度が大幅に向上し、エディタでの利用に耐えるようになったというのはさすがまめさん。
TypeProfで得た情報を他のツールから使えると夢があるなあと思っているのですが、そのへんはどうなんでしょうかね…
Ruby Implementation of QUIC: Progress and Challenges
Kaigi on Railsでも獅子奮迅のうなすけのトーク。まず驚いたのは英語がうまい！忙しいのにいつ勉強しているんだ、という気持ちです。
内容はPythonとRubyのギャップ的な話が多く、Pythonがわからない私は「そーなのかー」となっていました。うなすけの苦労が偲ばれますが、今後もまだやることがあるっぽいのでうなすけ先生の次回作に期待です。
Tips and Tricks for working in the MRI codebase
MRI（いわゆるCRuby）の開発に関するTips集的なトーク。Asakusa.rbなどによく行っているせいか、既知の内容も多かったのですが復習的な意味で楽しく聞けました。特にデバッガについては知らない情報が多かったです。
デバッガといえば、たまたま近くにいたima1zumiさんと話したところ、macOSではgdbのインストールが難しくてlldbを使うしかないそうです。なんだと…
Optimizing YJIT's Performance, from Inception to Production
YJITを生んだMaximeのトーク。基調講演ということもあり丁寧なトークであり、それにもまして丁寧に開発をしているのがとても印象的でした。私はコンピュータサイエンスを学んでいないのですが、「これがコンピュータサイエンス…！」となりました。そして実際にRailsアプリを高速化できているのもものすごい成果ですね。
学術的な成果がRubyに持ち込まれている、という点には感銘を受けつつ、その学術の世界と縁がない私はどうやってYJITと向き合えばよいのだろう、とも思います。勉強することは多いですね…
トーク感想（Day3）
Ruby Committers and The World
今回は初の英語メインということもあり、Shopify勢が元気な印象でした。あとはEregonが正規表現について語りまくっているのがとても印象的でしたね。
１時間では全然足りないなあとも思うし（一言も発していない人も多かった）、これはいっそ３時間くらいやってもらってその間に他のルームでもセッションを進めてしまうとよいのだろうか？
Code indexing: How language servers understand our code
エディタで使えるようなコード情報を集めるお話。エディタ好きとしては気になるところであり、実際なかなか興味深いことを話していました。このインデックス関連のツールはgemとしてリリース予定とのことであり、ruby-lspと合わせて期待が持てます。
なお、登壇者のvinistockから別に聞いた話では、ruby-lspにプラグインシステムを持たせてRailsなどへの対応はそこでするということも進行中とのことでした。こちらも期待ですね。
Ruby JIT Hacking Guide
RJITの紹介トークでした。とにかく私達にJITを作ってほしい、ということに力点が置かれており、k0kubunさんのJITにかける想いが伝わってきます。
私はアセンブラが苦手というかよくわかっていないのですが、調べてみるモチベーションは非常に高まりました（なにか作るかはまあ、余裕があれば…）。
Parsing RBS
soutaroさんの基調講演はまたもパーサーの話。型定義は瞬間瞬間を見ると壊れていることが多い、というのはなるほどなあと思いました。
RBSのパーサーがgemになっていると、外部ツールから型情報を読み取れて便利なのでそれも期待してよいのでしょうか…？
"Customize your Vim/Neovim directly with Ruby"について
発表のきっかけ
私はもともとRubyKaigiにプロポーザルを出していて、今回も出したかったのですがネタがなくて断念しました。最近作っているものである程度まとまったものといえばAlbaくらいしかなく、Albaでは過去にプロポーザルを通せなかったためです。
ですがあるタイミングで"rspec-current.vim"ならばLTくらいならできるのではと思い始めました。その時点ではまだLTがあるという情報はなかったのですが、気持ちの上ではLTにプロポーザルを出すつもりでいました（準備していたとは言っていない）。
そしてLTのCFPが公開されてから割とすぐにプロポーザルを提出しました。以下はその内容です。
Abstract
My editor of choice is Neovim. Do you know what advantage Vim/Neovim have for us Rubyists? Yes, we can write plugins with Ruby!
This facility made it possible to develop rspec-current.vim, a Vim/Neovim plugin to tell you what subject and context are in your cursor position. It's useful with deeply nested RSpec file.
As I mentioned, we can use Ruby as a plugin development language. This means we can even use RubyVM::AbstractSyntaxTree in our plugin. In this talk I'll talk about the implementation detail of the plugin and encourage you to do the same!
Details
I think this type of editor plugin will be still useful in the future.
Although recently lots of developers use Language Server Protocol (LSP) to build editor plugins, there are some benefits not using LSP.
First, it's much simpler. I created only one Vim script file and that was enough. In contrast, if I adopt LSP I need to consider if I create my own Language Server or send a PR to other existing implementations.
Second, it should be faster. There's no overhead of JSON RPC. If we want to display the result from plugins, it's important.
So I think I can introduce something useful, at least for Vimmers.
But most importantly, this talk is about encouraging. Creating small but useful things in Ruby makes our lives a little easier, and it is fun!
Pitch
I've wondered why do we want to use other languages to improve one language. I really appreciate efforts that improve Ruby with Ruby such as RJIT or Typeprof.
But what about editors? VSCode is a great editor but we must use TypeScript to develop any kind of plugin. I'm not a big fan of this.
This talk is a concrete example of using Ruby to improve Ruby experience. As I know more about Ruby I can develop it even better. And I'm working on it!
Btw, I know TextBringer but I have not used it so I cannot talk about it at all :)
プロポーザルが通った！
幸いにしてLTのプロポーザルは通りました。上の文章をよんでいただければお分かりの通り、5分の発表時間に対してかなり長文のプロポーザルを書いており、熱意をうまくアピールできたのが良かったのかもしれません（だから発表中に語られなかったことも大量に書いてある…）。
プロポーザルが採択されたのは4月25日のことで、本番までは2週間くらいしかありません。そこで実装を「手直し」しようとしたのですが思わぬ展開が。
動かない！！！
すでに完成していると思って油断していたのですが、なぜか試してみると全く動作していない。理由は調べられなかったのですが、デモをすることは発表の流れ的に必須である以上、これは重大な問題でした。
そこで割と直前までひたすら修正をしていました。あるあるですが、一度修正を始めると色々なところが目に付き、ついつい細かな修正を繰り返してしまっており、結局発表自体に手を付けたのは5月の7日ごろ…
発表準備
今回の発表をVim（正確にはNeovim）で行うことは当初から決めていました。主な目的はネタですが、デモ用のNeovimと発表資料の行き来がしやすいという隠れたメリットもありました（同じiTermを使っているため、キーボードショートカットでウィンドウの切り替えができる）。
ただそこにも問題があり、iTermは端末アプリケーションなのでフォントサイズはアプリケーション内で固定です。そのため、髙橋メソッド向けにフォントサイズを上げすぎるとデモの際にコードが読めなくなってしまいます。今回はウィンドウを2つ使い、それぞれで異なるプロフィールを利用することで回避しました。
また、Vimでプレゼンする際に邪魔になる色々なもの、例えばタブの表示などは全て非表示にする必要があるのですが、それはコマンドで行いました。以下がそのコマンドです。
command! StartPresentation :tabdo :windo :set laststatus=0 | :set showtabline=0 | :set nonumber | :execute "sign define piet text=>> texthl=Search" | sign place 2 line=23 name=piet
髙橋メソッドで表示する内容についてはテキストファイルとして作成し、それをスクリプトから起動してgtでタブを移動することでページ切り替えをする方法をとりました。この方法のメリットは上のコマンドと合わせてマシンの再起動などに強いことです（簡単なコマンドでプレゼン環境を復元できる）。実際、接続確認をしたら画面が表示されなかったのでマシンを再起動したのが発表の直前だったのですが、ストレスを感じることはなかったです。
内容面について触れると、基本ネタ重視だがしっかりと実用面をアピールするという方針で作りました。途中、Shugoさんと金子さんに触れているのは偶然ではなく、発表内容の相互関連感を演出する目的がありました。本当はMatzにも触れたかったけど無理でした…
発表
発表は英語で行いました。これは言うまでもなくRubyKaigiが国際カンファレンスであるということと、台本がない状態で同時通訳の方が正しく訳してくれることはおそらく期待できないであろうと思ったためです。英語がそれほど得意でなくても聞き取れるよう、平易な英文を心がけました（難しい英語が使えないともいう）。
あれほどの人数を前にして話すのは初めてでしたが、不思議と全く緊張しませんでした。照明の関係で会場にいる人々の顔があまり見えないのがその理由かなと思います。
実際に発表してみると、聴衆から笑いが起きなかったのは残念ですが及第点の発表はできたと思います。笑いについては画像が使えないという制約があったのが大きかった気がしますが、Vimでこの制約を乗り越えるのは大変…
なお、このLTにはセルフ解説があります。英語トークの登壇者が日本語で解説記事を書くのは比較的珍しいと思いますが、ご笑納ください。
楽しさの理由とは
前述の通り、今年のRubyKaigiは今までで一番楽しかったのですが、なぜ自分が今回ここまでエンジョイできたのか、3つの理由について考えてみました。
交流の機会が増えた
一番大きかったのは交流の機会が増えたことだと思います。今年はオフィシャルパーティーやアフターパーティーに加え各社のDrinkupも復活し、Rubyistと話す時間がものすごく長くなりました。元々話すのが大好きな自分としてはこれはとても嬉しい。
Music Mixinも今年初めて参加してみましたが、20時から2時までずっと会場にいて色々な人と話せてとても楽しかったです。最終日なので次の日のことをあまり気にする必要がなかったので、そのままラーメンから居酒屋をはしごし、最後には川に到達してそのまま明るくなるまで飲んでいました。こういう体験はRubyKaigiならではだなと思うのですが、それが楽しいという感覚に大きく寄与しているのは間違いありません。
交流の機会という意味でいうと、今年はヘルパーではなく一般参加だったのですが、結果としてブースをめぐってスポンサーの方々と会話する機会が増えるなど交流には良い影響があったように思います。一方でヘルパー同士の交流は当然ながらできなかったため、一長一短ではあります。
Rubyists on Railsのような交流企画があったのもとても良かったですね。あれはぜひ毎年何らかの形式でやってほしいなと思いますが、企画が大変なのもとてもよくわかる…（沖縄だとRubyists on Jetsになるのかな？）
トークがわかるようになった
今年自分でもビックリしたのが「トークが…わかるぞ…？」という感覚でした。これは去年のRubyKaigiまではあまり得られなかったものです。
初めてRubyKaigiに参加した2016年当時、私は今ほどRubyについて詳しくなかったですし、プログラマとしての実力もまだまだだったと思います。あれから7年が経ち、私はRubyプログラマとしてはかなり成長できました。特に2020年からAlbaを作り始めたのが私の転機の一つであり、ライブラリ的な観点からコードを見ることができるようになりました。
また、個人的に考えていることとして、RubyKaigiは参加するたびに理解度が5％ずつ上がっていくという仮説があります。7年で6回RubyKaigiに参加し（2018年のみ不参加）、理解度が毎年上がっていく感覚は確実にあります。
しかし、それらを考慮しても今年は急に視界が開けたようなところがありました。これは一体何なのだろうかと思うと、一つ考えられるのは問題意識です。RubyKaigiはRubyのエコシステムを改善している人たちのトークが多く、その背後にはRubyの現状に対する様々な課題感があります。今年のRubyKaigiでは開発生産性（いわゆるDX）に関連した話が多かった印象があるのですが、そこに対する課題感は私も強く持っており、実際、kaigieffectとして直後にNiwaという新しいドキュメントツールのプロジェクトを立ち上げました。これまでここまで直接的なkaigieffectを受けたことはなかったので、やはり問題意識がRubyKaigiの楽しみ方に影響を与えているのは間違いないと思います。
これを読んでいる方にもRubyのコア開発やその周辺の話題についてアンテナを張ることをオススメします、RubyKaigiをもっと楽しめること間違いなしです。
松本がとても良い
最後の理由として、松本の町の良さを挙げたいと思います。松本の町には市電やバスの姿がなく、基本的に人々は歩いて移動しているようでした。実際、松本駅・松本城・まつもと市民芸術館の3点の内部は十分に徒歩圏であり、その内部で諸々が完結する印象を受けました（ただスーパーマーケットはなかった気がするので住民はどこで買い物をしているのだろう）。
町にある最も大きな道路も威圧感はそこまでではなく、結果として町が分断されることなく一体感を保っていたように感じます（甲州街道で分断されている町に住んでいたことがあるので余計にそう思う）。そこが松田さんの言う"Nice"というところに繋がっていくのかなと思いました。
町の一角に蔵が集まっているエリアがあったり、謎に水が湧き出ていたり、小さな川が流れていたり、そういったところも町の雰囲気に一役買っていたような気がします。今回はお昼休みが2時間あったため町に滞在する時間も長く（0日目と4日目を含めるともっと長い）、町を堪能できたのはとても良かったです。
おまけ1：松本で何を食べたのか
例によって写真はほとんどないので、文章でメモ程度に残しておきます。
Day0
- そば処かまくらや
- 葉わさび蕎麦というのを食べた、ピリッと辛い葉わさびと蕎麦の相性が良い
- かうひいや3番地
- いわゆる古民家カフェで雰囲気がとても良い、コーヒーはやや深煎りだったけどもっと深いやつを頼んでもよかったかも
Day1
Day2
- 珈琲美学アベ
- このときは普通のコーヒーを頼んでしまった、モーニングはシナモントーストとジャムを選択
- 女鳥羽そば
- 三段重ねの蕎麦が名物らしいので頼んだ、味が段ごとに違っていて美味しく食べ進められた。アスパラの天ぷらも美味
- アルプスコーヒーラボ
- 浸漬コーヒーが名物らしく、自分はラムコーヒーを注文。浅煎りなのとほのかなラムの香りとでなかなか良い
- RIZAP Drinkup at RubyKaigi 2023
- 馬肉のお店で肉を食べまくった。大量のタンパク質を摂取
Day3
Day4
- 珈琲美学アベ
- 今度はモカクリームオーレを注文することに成功
- ホップ・フロッグ・カフェ
- 店主がかなりコーヒーマニアな感じでずっとコーヒーの話をしていた、4種類の飲み比べセットを注文（コーヒーで飲み比べセットは珍しい）
- そば処種村
- 2種類の食べ比べセットを注文、そばつゆも2種類あって計4種類の味を堪能
おまけ2：関連イベント
今年のRubyKaigiの一つの特徴はプレイベントやアフターイベントが多いことなのではないかと思います。今回私は参加できる限り全てのイベントに行くようにはしていたので、ここでは関連イベントの感想についても書こうと思います。
RubyKaigi 2023 予習イベント ～推しトーク紹介～
須藤さんメインの予習イベントでした。登壇者のしおいさんも参加し、主にお二人の推しのトークについて紹介する内容でした。オンラインでかつ昼間の開催だったのが特徴的です。
Shibuya.rb RubyKaigi 2023 前夜祭 ＠GMO Yours・フクラス
最近オフライン開催が復活したShibuya.rbの名前を冠したオフラインでの予習イベントでした。100人近くが集まり非常に賑やかなイベントで、いわゆるReject Talks的なものもあり内容的にも非常に充実していました。
RubyKaigi 2023 を楽しむ予習会
オンラインでの予習会ですが参加人数がとても多く、結果的に全てのトークについてコメントをしていくという内容でした。チーフオーガナイザーの松田さんも参加しており、伝統的な「タイムテーブル徹底解説」的なイベントとなりました。
Ruby-dev office hour RubyKaigi 2023 直前スペシャル
毎週月曜日にまったりとやっているdev office hourの直前号といったイベントでした。他の予習イベントに比べてもRubyコミッターや登壇者の比率が高かったような気がします。dev office hourの性質上ウェビナーモードではないZoomでの開催であり、飛び入りで会話に参加しやすいのが良かったです。
Asakusa.rb Welcome Drinkup for RubyKaigi 2023
オフラインでのAsakusa.rbの拡大版的な内容で、Shopifyの人々も大勢来てとても賑やかかつ国際的な雰囲気でした。登壇者の一言コメントなどもあり直前で大いに盛り上がりましたね。私はShopify勢に積極的に話しかけに行くことができて満足。
ふりかえりRubyKaigi 2023
STORES主催のオンラインの振り返りイベントで、トークをいくつかピックアップして感想を話していく会でした。直後なのでみんな記憶がフレッシュだったので色々濃い話ができていたと思います。登壇者の方々が入れ替わり立ち替わりしゃべっていたのも良かったですね。2時間では時間が足りないのはご愛敬…
RubyKaigi2023 スポンサー振り返り会！エンジニアが語る運営秘話
Wantedlyのオフィスで行われた、スポンサー目線での振り返りイベントでした。私はKaigi on Rails運営の立場からスポンサーについて学ぶために参加しましたが、やはりブースには各社が力を入れているということを感じました。まだお話したことのない方が多く参加していた印象。
After RubyKaigi 2023〜メドピア、ZOZO、Findy〜
タイトルにある3社合同のアフターイベントで、3社から1名ずつとsue445さんとうなすけさんが登壇するイベントでした。sueさんのトークが来年プロポーザルを出したいと思っている私にはとても参考になりました。うなすけのトークは私もちょこっと関わっていました。裏でCookpadのイベントもあったのですが、そちらと比較して若い参加者が多かった印象で、彼らにRubyやRailsの話を色々としていました。
【Money Forward x Shippio】 BaySide Tech Nite
英語メインのイベントで、kaigieffectで英語やらなきゃとなっている人が多い中タイムリーなイベントでした。私はLTをして、英語を学ばないということについてお話しました。詳細は資料を参照してください。
さいごに
というわけで最高のKaigiだったのですが、来年は沖縄ということでまたしても期待が高まりますね！
そして10月にあるKaigi on Railsへの熱量も非常に高まりました。最高のKaigiにしていきたいと思いますのでそちらもご期待ください！
さいごに写真とツイートをどうぞ。
kaigieffect その1
YARPとTypeProfとかを組み合わせたらもっといい感じのドキュメントツールが作れるんじゃないかと思っています。YARDの型のアレはDRYじゃないのが嫌… #rubykaigi
— 大倉雅史（OKURA Masafumi） (@okuramasafumi) 2023年5月13日
kaigieffect その2
Hi Rubyist, I now have another #kaigieffect, I started to listen to English podcasts! I found myself not very good at listening, so this is my attempt to improve myself for next Kaigi (or maybe, conferences outside of Japan?)
— 大倉雅史（OKURA Masafumi） (@okuramasafumi) 2023年5月17日
次はKaigi on Railsだ！
「#rubykaigi が終わった」
— 大倉雅史（OKURA Masafumi） (@okuramasafumi) 2023年5月17日
「終わるとどうなる」
「知らんのか」
「#kaigionrails （の準備）が始まる」
というわけで絶賛準備中です。今月から動いていくので諸々もう少し待ってね！
福岡Rubyist会議03に参加してきた
概要
去る2月18日（土）に福岡Rubyist会議03に参加してきました。とても良い地域Ruby会議だったので、ここではその様子をレポートしていきたいと思います。
全般
今回の福岡Rubyist会議03は基調講演2名、一般講演6名の計8名による講演がメインの技術カンファレンスでした。講演の他には会場の後方に八女茶が提供されていたのが特徴でした（めちゃくちゃ美味しかった…）。
参加者はスタッフの方などを合わせて総勢100人前後、参加登録ページによると一般参加はほぼ満員でした。会場では東京から来た方も多く、賑やかな雰囲気となっておりました。
コンテンツ
ここでは各講演について概要などを書いていきます。今回、個人的に初の試みとしてメモを取っていたので、その内容からの復元となります。
yasulab: RubyistによるRubyistのためのカンタン動画制作
安川さんのお話は動画を撮ることについてで、独自の機材でYouTubeへのライブ配信を行うなどとても意欲的なものでした。「音は丁寧に、画は程々に」というフレーズが印象的で、実際に配信をする際には参考になりそうです。StreamYardやScreenFlowなどの便利ソフトウェアも紹介されていて、今後動画配信をする人にとっては助けになる内容だったと思います。
hsbt: Ruby のリリースを爆速にするための方法
しばたさんのお話はRubyのリリースについてで、かなり自動化できている部分もあるが手動の部分もまだあるということでした。Rubyのような複雑なソフトウェアをリリースするのはとても大変なのだと想像は付くのですが、こうして実際に発表になるといやそれは本当に大変そう。
「セキュリティリリースの際はパッチを公開できない」という話があり、なるほどと思いました（リリースより前にパッチを公開してしまうと問題を認識されて悪用されるから公開できないが、そのために動作確認が大変、という理解です）。
sorah
そらさんの基調講演はRubyKaigiの運営がテーマでした。「大変だけど楽しんでやっている」「Rubyコミュニティには恩がある」という話が印象的でした。特に圧巻だったのはtakeout-appについてで、かなり多機能なアプリをAWSを駆使しつつ数週間で作ってしまうのはさすがの一言。
Wi-Fiの話も色々な苦労を偲ばせておりました（技術的なことはよくわからなかった…）、いつもありがとうございます。
（資料は非公開です）
Y_uuu: mruby on IoT devices.
岡嵜さんはmrubyのお話で、mruby-esp32というライブラリをIoTで使う際に直面したたくさんの課題を解決する話でした。課題の一つは最新バージョンへの追随で、地道にエラーを倒していきます（詳細は発表資料を参照）。MQTTというプロトコルのクライアントがない課題はmgemを作ることでクリアして、エンジニアリングをやっている…！という感想です。mrubyはまだまだ潜在的な応用事例が色々あると思うので、今後に期待ですね。
hachi: Factorybot 改善ツール作成失敗と学び
hachiさんのお話はFactoryBotの改善ツールを作ったこととその「失敗」についてです。「失敗」となってはいますが、実際には「全部思った通りにはいかなかった」くらいの内容に見えました。Railsのメソッドをオーバーライドし、test-profに入っているbefore_allに置き換えたりすることで高速化を図るのですが、CIに入れるくらいの精度を目指そうとすると偽陰性や偽陽性が多くなってしまうとのこと。
「レコードの作成には意図があって、それはレコードが作成されたという事実からはわからない」というのがポイントということで、なるほどたしかにと思いました。アプローチとしては面白いと思うし、テストの高速化はみんなの夢なのですが、なかなか難しいですね。
pocke: 外部コマンド実行入門
pockeさんのお話のテーマは「外部コマンド実行」でした。コマンドインジェクションのリスクがあるため、そもそも外部コマンドを使わないか引数を複数にわけて渡すことでシェルの起動を防ぐべき、という指針は非常に実践的。外部コマンドを実行するメソッドもいくつか紹介されましたが、だいたいOpen3で事足りてしまうという…
znz: Rubyist Magazine Reboot
西山さんはるびまのお話でした。現状更新が止まっているるびまをどうするかについて、関わる人数を増やさなくてはいけないこと、現状のシステムの紹介などが取り上げられました。質疑応答タイムが各自の想いを語る場になっていて良かったですね。
tompng: メンテできないコードをメンテする技術
ぺんさんの基調講演はTRICKに出てくるようなコードをどうメンテするのかという内容でした。「本当にメンテできないのなら、提出まで至らない」という話が個人的に印象に残っていて、TRICKのコードでもメンテナンス性が重要であるというのは発見でした。非常に高度な内容が次々と出てきて圧倒されましたが、「時にはメンテ不能になることもある」という話を聞いて少し安心しました。
TRICKのようなコードはIRBの秘孔を突くことがあるらしく、IRBのバグ修正にも一役買っているということで、すごい話だなあという感想です。
皆さんの反応は該当の時間のハッシュタグ検索結果から見られます。
福岡
福岡に行ったのはこれが二度目でした。滞在時間が長かったので割とあちこちに行けましたが、せっかく行った太宰府の天満宮が工事中で残念でした。美味しいコーヒーをたくさん飲んで、福岡のコーヒー文化の豊かさに触れることができて良かったです。
次回行く機会があれば門司港に行ったりしてみたいですね。
最後に
今回はトークがとても面白くて非常に充実した時間を過ごせました。現地の方と交流もできましたし、久々の地域Ruby会議を満喫することができました。オーガナイザーの方々、スタッフの方々、スポンサーの方々、ありがとうございました！
【宣伝】この記事はFukuoka.rb#296にて執筆されました。
