Rails Girls Gathering Japan 2022で基調講演をした感想
お断り
この記事は諸般の事情によりKaigi on Rails 2022の振り返りより先にリリースされていますが、そちらも書き途中です。
はじめに
先日行われたRails Girls Gathering Japan 2022で基調講演をさせていただきました。イベント自体の雰囲気は#rggjpなどから感じ取れるかなと思いますが、とても楽しいイベントでした。
いきさつ
例年Rails Girls Gathering JapanではLTをしていて、今年もLTをするつもりでした。ところが主催の江森さんから連絡があり、
これからの10年も一緒にご協力して頂きたい方にキーノートをお願いしたい
とのことで、キーノート（基調講演）をさせていただくことになりました。基調講演は初めてのことだったのでとても嬉しく思いました。
内容
大倉さんには「これからの10年」の方を話して頂けたらと思っております
というオーダーをいただき、未来志向の話をするということは早々に決定しました。一方、イベントの性質上女性の参加者あるいは比較的経験の浅い参加者が多いことはわかっていました。その交差するところとして、「コミュニティに積極的に参加する」ような方向性にしていくこととなりました。女性がコミュニティに少ないことは個人的にずっと課題に思っていたのと、経験の浅い方々を積極的にコミュニティに迎え入れていく必要があるという考えがあるためです。
さらに、過去のコーチの経験などをトークの中に入れることで話に厚みが出るという意図、未来の話の文脈として過去の話をする必要がいずれにせよあるということから、前半を過去の話、後半を未来の話という構成にすることにしました。ペース配分が難しくはなってしまいましたが、結果的にはこれで良かったと思います。
そしてできあがったのがこちら。
感想
今言いたいこと・言うべきことはだいたい言えたかな、という意味では手応えはありました。特に普段直接会う機会が少なくメッセージを届けることが難しいような方々に対して話すことができたのはとても有意義だったと思います。
今後もコミュニティを盛り上げるような活動を色々やっていきたいですね。基調講演の機会をくださった江森さん、そして運営の皆さん、ありがとうございました！
最近の@okuramasafumi
はじめに
この記事はRubyist近況[1] Advent Calendar 2021の18日目の記事です。昨日は@joker1007による最近のjoker1007でした。
お仕事の話
相変わらずフリーランスの開発者としてお仕事をしています。現場も去年と変わらずです。今年は年後半に『オブジェクト指向設計実践ガイド』の読書会をする機会があったので、そこで色々と意見を述べたりしています。ちょうど1年前に入った未経験の方々はとても優秀なのですが、「こうするとこういうつらいことがあったよ」みたいなことについては私の方が詳しいのでそういうことを言ったりしました。特に後述するように今年はライブラリを作ることをがんばったため、その観点から意見を言えたのは面白かったかなと思います。
あと、これまでなんだかんだJavaScript周り（Reactとか）とTypeScriptを避けてきたのですが、いよいよ挑むかという気持ちになってドキュメントを読んだりコードレビューをしたりしています。Neovimの環境もTypeScript向けに整えたので来年は仕事でフロントエンドも書けるようになりたいなという気持ちです。
Albaの話
Albaというgemを作っています。詳しくは紹介記事をご覧ください。
今年の初めにはバージョン0.11.0だったものが今では1.5.0まで来ました。今年1年でだいぶ開発が進んでいたらしいですね。GitHubのスター数も350まで増えてきて、ここからさらに広めていきたいなと思っています。
Kaigi on Railsの話
今年一番大きかったというか大変だった出来事はKaigi on Rails 2021なんですが、これについては1万文字のブログ記事を書いたのでそちらを読んでください。
Kaigi on Railsの後の話
Kaigi on Rails 2021は10月の後半にあったのですが、そこから今まで2ヶ月でも結構色々なことがありました。
各種登壇
まず、Kaigi on Railsの準備期間中に密かにRubyConf 2021での発表のために動画を収録していました。この動画でもってRubyConf初登壇をすることができました。今年のRubyConfはハイブリッド開催であったこともあり、自分の発表がどれくらい反響があったのかはよくわかりませんが（多分あまりなかった）、英語で30分話すのは良い経験になりました。録画の際にConfreaksの人が手伝ってくれるというのがなかなか面白かったです。
そして、同じ内容の日本語バージョンの動画を収録してRubyWorld Conference 2021で発表しました。こちらの録画は自前だったのですが、Logitech（Logicoolとも、どっちが正式なんだろ）のソフトウェアで簡単に自分の顔とスライドを両方映しながら録画ができました。デモが2回あるのでそのたびに録画を中断した結果、ファイルの個数は5個になってしまったのですが、MacだとQuicktime Playerがドラッグ・アンド・ドロップでの動画ファイル結合機能を提供していると知って驚喜しました。おかげで録画の技術関係ではほとんど悩むことがありませんでした。
なお、発表の内容については以下のスライドを参照してください。
フィヨルドブートキャンプへの参加
11月からフィヨルドブートキャンプにアドバイザーとして参加しています。直接のきっかけはKaigi on Railsのブース設営でフィヨルドの町田さんに声をかけていただいたことですが、それ以前からフィヨルドの受講生の方々とはコミュニティなどで接点があったため、参加の心理的ハードルは非常に低かったです。
現状、アドバイザーらしいことはあまりできていないと思うのですが、時間があるときにモブプロなどができたらいいなと思っています。
Step-to-Rails-Expert.rbの主催者になる
Step-to-Rails-Expert.rb（以下"Step"）というRubyコミュニティがあります。数年前からもくもく会（一時はみんなで別々に同じお題のアプリケーションを開発するという試みも）をやっていて私もちょくちょく参加していたのですが、2020年の10月を最後に開催されていませんでした。私が週末の夜にもくもく会を開催したいなという考えを11月に抱き、その趣旨も含めてStepに近いことに気づきました。そこでStepの主催者である@ebihara99999に連絡を取って管理者権限をいただきました。
まだ1回しか開催できていない（本当は12月にも開催したかったけどちょっと厳しかった）のですが、今後も継続的に開催していきたいと思っています。
まとめ
こうしてみると色々とやっているようです。来年もやっていくぞ！
今年作ったRubyのライブラリたち（mruby含む）を紹介します
はじめに
この記事はRubyアドベントカレンダー2021の4日目の記事です（が、公開は5日になってしまいました、遅刻してしまってすみません！）。昨日は@hasumikinによるPicoRubyあるいはRuby言語のコンパイラについてと、@Reichardtによる勝手に「点字メーカープログラム」を作ってみるでした。
今年作ったものたち
今年がファーストコミットなプロジェクトを時系列順に紹介します。
Inherint
Inherintは"Inheritance"と"Lint"の合成語で、クラス階層の深さが指定のレベルを超えるとブロックを実行できるgemです。
Lintと言いつつ静的解析ではないのですが、メタプロの練習的になかなか面白かったです。技術的な挑戦としては、初めて"Module Builder Pattern"を試してみたことが挙げられます。詳細は以下のスライドを参照してください。
mruby-malba
mruby-malbaはmrubygems、mrubyのためのgemの一つです。malbaという名前は私が作っているAlbaというJSONシリアライザにmrubyの"m"を足し合わせたものです。mrubyの範囲内でAlbaの機能を再現したものですが、実用というよりはmruby向けのgemを作ってみたいという気持ちから始まったプロジェクトです。
技術的な挑戦としては、mrubyを使うのが初めてだったのでそもそもmrubyのビルドの仕組みなどを学ぶのに苦労しました。今見るとコードが非常に古く今年いっぱいでAlbaに対して行った改善が全く反映されていないので、そろそろ書き直すべき時期かもしれません。
mruby-factory
mruby-factoryは平たく言うとfactory_botのmrubyポートです。といっても、フル機能の移植ではなく一部機能のみとなってはいますが、普段実用するものはなるべく実装するようにしたつもりです（factory_botは機能が多すぎる…）
今回はコードを短くすることを意識した結果、140行でかなりたくさんの機能を実装できました。これもかなり良い練習になりましたね。
TinyHooks
今年作り始めたもので一番がんばって作ったのはこのTinyHooksです。用途としては任意のクラスにincludeするとそのクラスのインスタンスメソッドと特異メソッドに対して、before, after, aroundの3種類のフックを定義できます。ActiveSupport::Callbacksと似た感じですが、フック対象のメソッドを編集する必要がないという利点があります。またかなり高速に動作し、特に「フックの準備はしたが実際には定義されていないとき」にActiveSupport::Callbacksで発生するオーバーヘッドを回避できる利点が大きいと思います。
Ruby 2.7からキーワード引数の扱いが変わった影響をモロに受けていて、コードが割と汚くなってしまっています。
mruby-callbacks
mruby-callbacksは前述のTinyHooksをmrubyでも実装できそうと思って試したらあまり実装できなかったやつです。mrubyの制約の多さに驚きました。
range-compacter
お仕事で作ったgemで、複数の範囲オブジェクトまたは範囲っぽいオブジェクトを受け取り、重複を排除して配列の配列として返します。日本語よりREADMEのコード例の方がわかりやすいかも…
振り返ってみて
今年は結構コードを書いているなあという印象ですが、来年はもっとたくさん書いていきたいですね。
Ruby製の究極のJSONシリアライザ、Albaのご紹介
はじめに
この記事はRuby on Rails アドベントカレンダー 2021の記事です。昨日は@yamat47によるRuby on RailsでもHLS形式で動画を再生したい！でした。
Railsアプリにおける鬼門、JSONシリアライザ
昨今のRailsアプリケーションははじめからAPI専用として構築されることも多くなってきています。この場合、フルスタックフレームワークとしてRailsを利用する場合と比べて利用しなくなるgemも多いのですが、一方でAPI専用の場合に多く使われるgemも存在します。それがJSONシリアライザです。
この文脈における「JSONシリアライザ」という単語の指すものは、「任意のRubyオブジェクトをJSON文字列に変換するための機構（特にDSL）」を提供するライブラリです。
RubyにおけるJSONシリアライザの歴史は長く、最も有名なActiveModelSerializersのバージョン0.1.0がリリースされたのは2011年のことでした。そこから10年、今やRubyにおけるJSONシリアライザは史上最大の乱立期を迎えています。
現状については私自身が記事を書いていますが、この記事を書いた後にさらに多くのライブラリを発見したため、今や考慮できる選択肢は10近い数存在します。記事で言及されていないものとしては、panko_serializerというライブラリが圧倒的な速度で目を引きます。高速な分制約も大きいため、常に採用できるものではないかもしれませんが、有力な候補にはなるでしょう。
ここで問題なのは、存在する選択肢には決定版が存在しないことです。スター数やダウンロード数からはActiveModelSerializersの1強なのですが、こちらはあまり活発にメンテされていませんし、コードベースは非常に複雑です（コード行数は2600行を超えます、これは類似のライブラリ中最大です。ちなみにAlbaは約500行です）。
Jbuilderもまた著名でありダウンロード数も非常に多いのですが、（主観が入りますが）かなり癖の強いDSLを書かなくてはいけない点と、partialが多用されると速度が遅くなる点が原因で敬遠されることも多いgemです。
他の選択肢はすべてそれほど著名ではありません。Jbのスター数が1000を超えているほかは4桁に達しているものはまだありません。機能の面でも速度の面でも、存在するほぼ全ての選択肢に改善の余地が多く残されています。
Alba
そんな状況で決定版となるべく作られたのがAlbaです。Albaは機能と速度の両面で他の全ての選択肢を凌駕することを目標としています。
機能についてはさすがに客観的な指標があるわけではないのですが、他のgemが持つ有力な機能はほとんど備えているはずです。唯一足りていないのはJSON:APIへの対応ですが、こちらは次期バージョンで対応予定です。
速度についてはベンチマークがあるのでそちらを実行すると、Albaは総じて前述のpankoより3割程度遅い速度で動作します。pankoはC拡張まで使って高速化を図っているのでさすがに勝てないと思われます。そのほかのgemに対してはAlbaは互角以上に高速に動作しています。
Albaの興味深い機能
Albaにはユニークな機能がいくつかあります。
レイアウト
https://github.com/okuramasafumi/alba#layout
最近実装されたのは「レイアウト」機能です。これはAlbaが基本的に単一のオブジェクトまたはコレクションに対してのみシリアライズを行うため、任意のJSON文字列を生成できないという制約を解除するものです。
使い方は上記リンクに記載されていますが、日本語で書くと「あるリソースが自分のシリアライズ結果をその中に埋め込むような文字列またはハッシュを指定できる」というものです。この文字列はファイルの内容として与えるかProcの返り値として与えることができます。どちらの場合でもシリアライズ済みのJSON文字列などにメソッドかインスタンス変数経由でアクセスできます。
レイアウトの主な使いどころはページネーションかなと思っています。また、前述のJSON:API対応はこの機能の上に作られることになりそうです。
インライン定義
https://github.com/okuramasafumi/alba#inline-definition-with-albaserialize
多くのJSONシリアライザは動作のためにクラス定義が必要です。普通はそれで問題ないのですが、再利用しないことがわかっている場合などはクラス定義は若干冗長に感じるかもしれません。
このような場合にAlba.serializeというメソッドを使うことができます。このメソッドはブロックが与えられた場合はブロックの内容をリソースの内容であるかのように解釈してシリアライズします。ブロックが与えられなかった場合は、引数として与えられたオブジェクトのクラスに基づいて既存のリソースクラスを探し、見つかればそれでシリアライズします。
この機能はSinatraのような単一ファイルで動作するフレームワークを利用する際に有用かもしれません。
型定義
https://github.com/okuramasafumi/alba#experimental-support-of-types
最近何かとホットな型定義ですが、Albaでも型定義ができます。といっても、RBSを使ったものではなく、JSONに対する型定義です。
現時点では属性に定義できる型はJSONのネイティブ型であるString, Integer, Booleanのみです。配列とオブジェクト型は現時点ではサポートされていません。
（これを書いていて気づいたのですが、今の実装ではFloatに対応できていないので近いうちに対応します）
型を定義するだけでなく型を自動で変換することも可能です。例えば型をStringに指定した場合、デフォルトの自動変換はto_sを呼び出します。Procを与えて独自の型変換ロジックを実装することも可能です。
依存関係がない
Albaはデフォルトでjsonライブラリのみに依存しています。jsonは標準ライブラリですので、gemとして見た場合はAlbaに依存関係はありません。一部の機能については実行時にrequireするので、機能を使わなければ依存も発生しない設計になっています。これにより、例えば非Rails環境での利用の際にactivesupportが依存に入ってしまう事態を防げます。
今後のデファクトになってほしい
作者の私が言うので割り引いて考えてほしいですが、Albaはかなり良い選択肢になっています。今後もRailsを含むRubyアプリケーションでオブジェクトをJSONに変換する機会はたくさんあると思うのですが、その際にはぜひ、Albaを試してみていただけるとありがたいです。そして、利用して何か困ったことや改善のアイデアがあればDiscussionsよりフィードバックをいただけるととても助かります。
そして、RailsアプリケーションをAPIサーバーとして利用する際にJSONシリアライザについて考える必要がなくなることを願っています。
Rails Girls Gathering Japan 2021で登壇しました
この記事について
この記事はRails Girls Japan Advent Calendar 2021の2日目の記事です。昨日は@emorimaによる「Women Developers SummitでRails Girlsのお話をしてきました」でした。
この記事では、タイトルの通りRails Girls Gathering Japan 2021というイベントでLTをしてきたのでその報告をします。
何をしゃべってきたのか
このスライドのタイトルの通り、「Railsの未来をDHHの発言から予測する」みたいなコンセプトの発表でした。
なぜこの発表だったのか
この発表は公募だったのですが、イベントが「Rails Girls Gathering Japan 2021」なので「Rails Girlsの話でもRailsの話でもどちらでも大丈夫だろう！」という気持ちだったのと、多分Rails自体の話をする人は少ないだろうから自分がRails成分メインの話をできればという気持ちでこの発表をしました。
なんとなく、オフラインでRails Girlsに参加したときのコーチLTを思い出させるような感じでした。
発表の内容
スライドに全部書いてあるのでそちらを見ていただきたいのですが、基本的には"Conceptual Compression"という最近DHH（Railsの作者）が重視している概念を援用し、「Railsがフロントエンド開発の方法論を現在主流の方法（Reactとか）とは別に開発して、Railsは個人や小さなチームがフル機能のアプリケーションを開発しやすくするフレームワークであり続ける」というような結論を導きました。
この結論自体にはそれほど異論はないのかなと思っていて、「フロントエンド開発の方法論」が現在の主流たるReactに匹敵しうるのかが議論の焦点であるという気はします。
こぼれ話
発表の時間は5分しかなかった（LTなので当然）ので、かなり圧縮して話しました。内容自体は15分でも足りないくらいに込み入った話だったと思います。
さいごに
「Rails Girls Gathering Japan 2021」はとても素敵なイベントでした。前回に続いてイベントを開催していただいたオーガナイザーの皆様に感謝します。
そして、2022年はまたRails Girlsのコーチとしてあちこち行けるとよいなと思っております。
明日は
明日は@siroemkによる記事です！
Kaigi on Rails 2021をやったので振り返る
Kaigi on Rails 2021の振り返り
この記事では先日行われたKaigi on Rails 2021の振り返りを行います。
私（@okuramasafumi）はチーフオーガナイザーですので、主催者目線での振り返りとなります。
ブースについて
個人的には、今年のKaigi on Railsの最大のポイントはやはりオンラインブースでした。これはまだあまり前例がない試みであり、カンファレンス全体の印象を左右しかねない試みでもありました。ありがたいことに概ね好評をいただいている今回のオンラインブースについて、振り返ってみましょう。
オンライン開催、再び
Kaigi on Railsのカンファレンスは前回のSTAY HOME Editionに続いて2回目です。開催形態はまたしてもオンラインとなりましたが、前回終了時点でオフライン開催の見込みが全く立たなかったことから今回もオンラインでの開催となりました。
ただし、全く同じようなカンファレンスにするつもりは最初からありませんでした。前回はオンライン開催そのものに手探りだったのですが、今回は「動画提出の登壇者とライブの登壇者がいて、ライブの人はZoomに入って画面共有して、それらをOBSでまとめて配信する、視聴者はそれをYouTube Liveでみる」だけではない、もっとインタラクティブなカンファレンスをやりたかったのです。皆さんの感想で挙げられていた「Kaigi感」を出すこと、それは最初から重要なものとして位置づけられていました。
議事録で振り返る「インタラクティブなオンラインカンファレンス」への道
「インタラクティブ」といっても、色々な方向性があります。2021年1月時点の議事録には、「モブプロ会をやりたい」「ワークショップやりたい」という記述があり、当時の思考がわかります。この時点では、金曜日と土曜日に開催し、金曜日をワークショップ中心にする、というアイデアがあったようです。
2月の議事録には、「動画のコレクションではなく、場である」という考えとあります。この時点で、如何に「場」を作るかが議論の中心にありました。今考えると、カンファレンスまで8ヶ月も前の時点で方向性が固まってきていたことはその後の進行にかなりプラスになっていたと思います。
3月の議事録に、「RailsGirlsをKaigi on Railsの枠の中でやる」というアイデアがあり、さらにさらにそこから発展して「コミュニティスペース」という単語も出てきています。これらは実現しませんでしたが、2022年以降、ぜひトライしたいアイデアですね。
4月の議事録で初めて「スポンサーブース」という単語が出ました。この時点ではSpatialChatを使う構想だったようです。これが2021年の「インタラクティブ」として実現することになります。
その後しばらく他のタスクをやっていてブースの話はあまり出てこなかったのですが、7月頭の議事録でブースについて突っ込んだ議論が始まりました。この時点では使うツールが決まっていないためイメージも具体的にならず、ただ懸念だけがある状態でした。議事録にあるオンラインでわざわざブースに行くか？という部分が印象的です。杞憂に終わりましたが、私たちが手を抜いていたらこの懸念が当たっていた可能性もあったと思います。
そして次のミーティングで、今回利用することになったreBakoが初めて登場します。この時点では「よさそう」くらいだったのですが、実際に触ってみて「これならいい感じのオンラインブースが作れるのでは」と思えたため、みんなで触ってみることになりました。ちなみに、reBakoを見つけた経緯としては、運営メンバーの一人がフィヨルドブートキャンプの卒業生で、そのフィヨルドブートキャンプのメンターをしている人が所属しているしくみ製作所がreBakoを作っている、という縁がありました。
reBakoの問題点の一つが、懇親会にはあまり向いていなさそう、ということでした。前回も懇親会はSpatialChatを使ったのですが、やはりSpatialChatのあの手触りが懇親会には最適である、という考えはreBakoを触っても変わることはありませんでした。ここは結局ツールを分けることでそれぞれの良さを引き出すことができたと思います（クロージングキーノートがあるため、どのみちブースから撤収するというのもありました）。
さて、使うツールが決まったらあとは実装あるのみ！…なのですが、重要な問題がありました。
そう、誰もオンラインブースについて詳しくないのである！！
手探りのオンラインブース
まず、reBakoは新しいツールなのでWeb上に感想があまりありません。もちろん実際に触ってみることでかなり感触はつかめてくるのですが、「ここに100人とかを入れたら何が起こるんだ」ということについては本当によくわからないのが現実でした。
さらに重要なこととしては、スポンサーの皆様も状況はだいたい一緒のようでした。オンラインでのカンファレンス自体歴史が2年しかないので、それはまあ当たり前なのですが、この「当事者の誰もが知見を持っていない」というのはこの種のイベントにしてはかなり特殊なことだと思います。
スポンサーとの説明会を2回開催してみたのですが、使ったレイアウトはサンプルのものをそのまま流用したのもあって、具体的なイメージについては依然として共有できていなかったと思います。実際、スポンサー各社から来た問い合わせのメールを見てスポンサー向けのブース資料を書き直す日々でした。
さらに、reBakoの最大の問題点が同時編集ができないことでした。これは25社がブースを持つKaigi on Railsのようなイベントではかなり致命的な問題となります。同時編集ができないということは、誰かが排他制御をしないとコンフリクトが起きて編集内容が失われるということを意味しており、直列で最低でも25回設営の場を持つ必要があります。各社のレイアウトを揃えてしまえばこちらで編集すればよくなるのですが、それだとブースの個性が失われて本末転倒となってしまいます。
この「スポンサーがイメージを持っていない」「同時編集ができない」を解決する手段はただ一つ、私が各社とオンラインミーティング形式で打ち合わせと設営を行うというものでした。これならば私が細かなヒアリングと説明を行うことができるし、私自身が排他制御をするのでコンフリクトは起きなくなります。
まずは日程調整をする必要があるわけですが、なんといっても25社の調整をメールですると正気を失ってしまいます。今回はTimeRexというサービスを使って日程調整を行いました。これは調整さんと同じ会社が作っているということで採用してみましたが、かなり使い勝手が良かったのでオススメです。
日程調整後、設営会の毎日がやってくるのですが、なんとこの時点でまだ全体レイアウトが決まっていないという失態…というより、そもそも募集をちゃんと締め切っていなかったので合計何社になるのかも不透明で、これは完全に私のミスでした。ブースの数が確定してからも、全体レイアウトが仮のもののままになっていて、この時期に設営していた各社にはお手数をおかけしまったと思います。
設営に関する興味深いこととして、ある時期の設営から流行したのがボットでした。私は最初ボットはいらないかなと思っていたのですが、とある企業さんがボットを設置したところ各社が真似をしだし、結局8割近い企業さんがボットを設置していました。このへんは各社が最適解を模索している感が出ていますね。
ボットの件もそうですが、私自身がスポンサー各社の設営から学び、急速にreBakoについて詳しくなっていました。その知見をフィードバックしていくのですが、後半には担当者の方の持っている知識と準備具合によって対応を分けるのが最適であると気づいてそれを実践していました。
全体レイアウトを確定させ、すでに設営済みだったブースをお引っ越しして、設営会の波を突破して、前日にはリハーサルもしたのですが、この時点でおそらく40時間近くブース関連に費やしていたと思います。これは持続可能性に乏しいので、来年以降は改善したいですね。
当日のブース
さて、いよいよ当日となりました。オープニングキーノートが終わった後、人々がブースに来るわけですが、そこですぐに気づくことがあります。
みんなテーブルに着席しない！！
まあ、それはそうですよね。ブースの中の人が知り合いならともかく、知らない人が待ち構えているテーブルに着席するのにはかなり勇気が要ります。私たちもそれは認識していて、対策として「グッズを売っているSuzuriで使える2000円引きクーポン」をブーススタッフからもらえるという施策を打ったのですが、それでも参加者はテーブルに着席しません。
テーブル着席は2000円以上の重みがあるという事実を知ることができました。
それでもブースに人は増え続け、初日の昼には約140人がブースにいました。50人くらいはスタッフさんだと思うので、参加者の人数は100人弱といったところでしょうか。かなり集まっていますが、やはり各社のブースへの着席率は芳しくありません。雑談テーブルはそこそこ賑わっているので、ここが来年に向けて最大の改善ポイントになりそうです。
さすが技術カンファレンスだなと思ったのが、2日目になると各社のスタッフさんが工夫をしてくれるようになって、全体チャットが活用され始めるようになったり、テーブルに書くメッセージが多様になったりといった変化が起こりました。全関係者の練度がみるみる上がっていくのは見ていて楽しかったですね。
ブースについての記述の最後に、この場を借りまして、スポンサー各社にお礼を申し上げます。ありがとうございました。そして、来年以降もぜひご支援を検討していただければと思います。
コンテンツについて
さて、ブースについて長々と語ってきましたが、やはり技術カンファレンスの本筋は技術に関する発表です。もちろん、Kaigi on Railsはコンテンツについてもしっかりと設計・実装を行いました。
kamipoさんの基調講演
最大の目玉となる基調講演ですが、オープニングキーノートとクロージングキーノートで2つの枠がありました。そのうち一つをkamipoさんにお願いしたいというのは、去年の段階からすでに考慮されていました。やはり、日本人で最多となるRailsへのコミット量を考えるとkamipoさんにはいつかしゃべってほしいというのは個人的にも強く思っていました。
また、日本人のRailsコミッターは3人いますが、松田さんにはすでに去年基調講演をお願いしており、y_yagiさんは最近は活動が少なくなってきているという事情からも、日本で行われるRailsを中心としたカンファレンスとして、kamipoさんを外すことはできないのでした。
しかし、kamipoさんは発表資料を作って発表するようなスタイルについては依頼を一切引き受けていないとのことでしたので、モデレーターがいる状態での「漫談形式」がよいということになりました。モデレーターについては当初は私がやるつもりがあったのですが、やはり同じコミッターの松田さんがよいということになり、松田さんに快くお引き受けいただきました。
結果的には非常に良い「漫談」になったと思います。もっと時間があるとエンジンがかかってきてよかったとも思うのですが、カンファレンスの枠に収めようとするとなかなか難しいですね。
Rafaelの基調講演
もう一つの基調講演の枠ですが、5月の時点でRafaelがいいねと話していました。Rafaelについては、なんといってもRailsコントリビューターランキング1位という実績を重視しての人選でした。議事録にはRailsへの情熱はどこから来るのか、的な話とあり、この時点で路線は示唆されていたことがわかります。
といっても、7月頃にRafaelから送られてきたメールには「Railsへのコントリビューションの話とShopifyでのスケールの話、どっちでも話せるよ」みたいなことが書いてあり、運営メンバーの意見も2つに割れてしまったため、欲張って「両方はどうだろう」と提案したところ、その路線で話してもらうことになった、という経緯があったりもします。
その後、Zoomで打ち合わせをしつつも基本はメールで連絡を取り合い、動画を送ってもらいました。送ってもらった動画には台本もセットになっていたため、運営メンバーで動画担当のうなすけがDeepL Proに台本を通して得られた日本語を下敷きに、字幕向けの調整をしたものをうなすけに字幕として処理してもらいました。ただ、Rafaelがアドリブで話している箇所については必死に聞き取って日本語に翻訳しました。Rafaelの動画は内容に関しては最高だったので、「これを日本人の開発者に伝えたい」という気持ちで字幕を付けました。結果的に多くの人に楽しんでいただけたようでとても嬉しいです。
CFP
プロポーザルについても非常に良いものがたくさん送られてきて、運営メンバーで一生懸命選考しました。今年は特にイベントでのプロモーションなどは行わず、もっぱら私が各地のRubyコミュニティに赴いて「プロポーザルどうっすか」みたいな声かけをしていたのでしたが、幸いにもカンファレンスの知名度が去年よりも上がったためか数としては去年以上になりました。
今年はcfp-appという、RubyKaigiでも使われているプロポーザル管理ソフトウェアを使っての募集となりました。これは利便性を考慮しての選択でしたが、UIが英語のみであったりと必ずしも日本人による日本人向けのカンファレンスにおいて最適なツールではなかったのかもしれません。尤も、cfp-appはOSSなRailsアプリですので、がんばれば改善できるのですが。
プロポーザルの集まり方としては、例年通りにほとんどが最後の3日に集中していました。私がプロポーザルを出すときもだいたいそうなってしまうので、これはまあしょうがないかなという感じです。
プレイベント Kaigi on Rails _2021_ new
今年もプレイベント、Kaigi on Rails 2021 newを開催しました。去年はプロポーザルを増やすための啓蒙活動の一環だったのですが、今年は位置づけを変更して本編への参加者、特にこれまでカンファレンスに参加したことのないような参加者を増やすという目的の下に企画が進められました。そのため、開催日程はイベントの直前である10月10日に設定されました。
運営体制
重要なこととしては、このプレイベントは一部のメンバーのみが運営に携わるいわば「サブチーム」体制での運営となりました。運営メンバーは私を含めて10人いるのですが、10人参加の会議だとなかなか発言できないメンバーもいるため、サブチームとして半ば独立させて会議も別々で行うことで全体の会議にかかる時間を軽減しつつ、より主体的な参加を促す意図がありました。
結果的にこの試みは一定の成果を上げ、イベント自体の企画も成功裏に終わりました。ただ、配信班との連携が不十分で配信班に負荷をかけてしまったのは反省点です。チームの適切な分割は難しいですね…
座談会とLT会
プレイベントでは、Rails界隈で教育活動に携わっている、五十嵐さん・伊藤さん・安川さんの3名を招いて座談会を行うこととしました。これはこの3名が知名度が高いことの力を借りて、普段コミュニティやカンファレンスに興味のない人たちにもリーチする意図がありました。この意図はかなりの程度達成され、Doorkeeper上では初見の方を多数含む180人の参加者を集めることに成功しました。このうちの一部は本編にも参加してもらえたと思うので、それだけでも成功と呼べるものでしょう。
また、単純に座談会の内容が興味深く、私はファシリテーターとして参加していましたが「もっと話を聞きたい」と思ってしまうくらいでした。座談会という形式は適切に進行させるのが難しいため若干の懸念はあったのですが、満足のいく内容になったと思います。
座談会に加えてLT会も直後に行われました。本編でもLT会をやってみたかったけどそれがタイムテーブル的に難しいというのを受けて、プレイベントでチャレンジしてみたいという気持ちがありました。
このLT会はいわゆる「強制終了型」LTで、5分経ったら私が止めて次の人が話し始めるタイプでしたが、進行が驚くほどうまくいって、9人が5分でしゃべって50分以内に終わるという理想的な進行となりました。内容も粒ぞろいで、幸先の良いスタートとなりました。
当日
当日は12時スタートであったため、運営の集合も11時となり朝の苦手な私にはかなり助かりました。といってもやることは山盛りあって、あっという間に12時を迎えてしまうのですが。
本編の間はそれはもう忙しいし、必死です。私は司会業をしていたので、各トークの始まりと終わりに口上を述べる必要がありました。これは登壇者への「今から話してください」という合図、配信班への「今から画面を切り替えてください」の合図になっているため、何気なく重要な役目です。それ以外の場面でも、右耳でZoomの音声を聞きつつ左耳でトランシーバー的役割のDiscordの音声を聞く、という状態なので精神的には休まることがありません。
また、休憩時間にはブースの様子を見に行き、そこにいる人々と交流していました。これは私の役目というよりは趣味ですが、時間を気にしてブースから立ち去らなければいけないのは不思議な感覚でもありました（RubyKaigiだとブースにいるうちにトークを聞き逃すことがありましたが、前述のように司会業があるとそうはいきません）。
当日については、運営メンバーがみな優秀なため、私は司会に専念できました。優秀なメンバーに恵まれるって素敵ですね…
懇親会
カンファレンスといえば懇親会です。前述の通り、今回も去年と同様にSpatialChatを利用しました。オンラインブースに引き続きreBakoを使うことも可能ではありましたが、やはり席につかないと会話ができないのはブースならともかく懇親会には不向きだと判断しました。
有料版を使っているはずが参加可能人数が50人と、無料版と変わらない状態で最初はちょっと焦ったのですが、どうやら別の部屋を作るとそちらにも50人が参加できる、それらの部屋の合計が120人になるまでは参加できる、という仕組みのようでした。別の部屋を背景画像含めて「川」にしたのですが、そもそも合計人数が50人強にとどまりあまり活用されなかったのは少し残念でした。
懇親会は当初の想定に比べればやや人数が少なかったものの、それでも懐かしい方々や新しい人々ともゆっくり話せたので個人的にはとても満足でした。あまりに満足すぎて当初閉める予定だった12時を過ぎても居座ってしまうくらい…
データでみるKaigi on Rails 2021
さて、データを見ていきましょう。
Day1
まずは初日ですが、トータルの視聴数は2609となっています。1視聴あたりの視聴時間は51分20秒でした。ユニークな視聴者数は1289人となり、これらの数字は去年のものから1.5倍程度となっています。
同時視聴者数は最大で419人、400人前後の時間帯が多かったようです。去年の240人と比べるとこちらも1.5倍以上になっています。
年齢分布は
- 18~24: 6.3%
- 25~34: 57.5%
- 35~44: 31.5%
- 45~54: 4.6%
となっており、やや若年層に偏った結果となっています。
意外だったのは、全視聴者に占める女性の割合が9.3％であることです。
また、reBakoにいた人数は140人弱となっています。
Day2
続けて2日目ですが、トータルの視聴数は1495となっています。1視聴あたりの視聴時間は55分13秒でした。ユニークな視聴者数は650人となっています。数字としては初日よりもだいぶ低調であるばかりか、去年の数字も下回っています。
同時視聴者数は246人と去年とほぼ同じ数字でした。
年齢分布は
- 18~24: 5.5%
- 25~34: 53.7%
- 35~44: 31.4%
- 45~54: 9.5%
となっており、初日と比べると40代後半以上の割合が顕著に高くなっています。
全視聴者に占める女性の割合が10.5％であり、初日より改善したものの去年よりかなり低調となっています。
また、reBakoにいた人数は120人弱となっています。
データに対する解釈
一つ明らかなこととしては、平日である初日の数字は休日である2日目の数字に対して1.5倍以上パフォーマンスが良いということです。この事実に対する解釈ですが、やはり仕事をしながら見ていた人が相当数いるのではないでしょうか。reBakoにいた人数はさほど変わっていないということがこの解釈を裏付けています。ながら見の人はブースには足を運ばないでしょうから。
初日のパフォーマンスの良さ以上に気になるのは2日目の弱さです。去年と比べて社会情勢が変化し、外出する人が増えたのはあるかもしれません。業務的な内容の多い2日目のほうがライブで見る動機付けが弱かったのかもしれません。
また、個人的に少しショックだったのは視聴者の女性比率が半分近くまで減ってしまったことです。Kaigi on Railsは「敷居を下げる」ことをコンセプトの一つとして活動しており、女性の参加者を増やすことにも意識を向けています。それが今回は現実とはならなかったのは残念です。考えられる原因として、去年は女性登壇者が4名いたのが今年は1名のみだったのはあるかもしれません（追記：スポンサーLTを含めると女性の登壇者は3名いました。しかし、スポンサーLTに関しては個人名がタイムテーブルに載らないので、当日になるまでは女性登壇者は1名のみに見えていたとは思います）。あるいは、単純に去年に対する今年の増分がほぼ男性だったのかもしれません。
…と書いた後に気づいたのですが、去年は参加者240人に対して女性が約2割なので約50人だったのですが、今年は参加者400人に対して女性が約1割なので約40人、そう考えると人数自体は劇的に減ったわけではないのですね。ただ、なんにせよ女性に対するリーチが広がっていないことには変わりないです…
来年への展望
閉会式で宣言したように、来年も開催するということ自体はほぼ確定事項です。オンラインなのかオフラインなのかについてはまだ完全に未定です。未定です。
上に書いてあるように女性の登壇者と参加者が少なかったので、それを増やすことは重要な目標になるでしょう。具体的には、女性登壇者が1日当たり2名以上、参加者の女性比率が2割以上になるといいなあと思っています。これは現時点では個人的な目標ですが、業界全体から見ても中長期的に重要だと思われますので、Kaigi on Railsとして取り組む価値はあるでしょう。
インタラクティブさ、「Kaigi感」についてもさらに追求していきたいところです。オンラインブースについては知見を得られたので来年についてはその知見を生かしてそれぞれの距離感を縮めていけるとよいと思っています。今年実現できなかったアイデア、例えば「コミュニティexpo」などについても実現の可能性について探っていきたいところ。
そして、これらを現実のものとするには運営メンバーの質量両面における充実が欠かせません。インタラクティブでKaigi感に溢れたカンファレンスを作ることに興味のある人はぜひ、私のTwitterアカウントにDMをください！
感想
ここまで10000文字近く振り返りを書いてきましたが、なんといっても思うのは「楽しい！！」ということですね。これに尽きます。楽しくなければこんなことやってません。
この「楽しさ」の正体はなんなんだろうな、と思うのですが、やっぱり大勢の人を巻き込んで何かするということなんでしょうかね。ブースの設営のときも、各スポンサー企業の担当者の方とやりとりをして自分の世界が少し広がるのが楽しかったりもしました。
また、自分は世界に対して何か意味のあることをしている、という手応えも大きいと思います。感想ブログもたくさん拝見しましたが、「みんなが良いと言ってくれるものを作ったぞ！」という満足感はなかなか得がたいものがあります。
そんな感じで、私がカンファレンス作りを楽しんでいる限り、Kaigi on Railsもまた続いていきます。これを読んでいるあなたとまた来年Kaigi on Railsで会えますように！
おまけ
バーチャル背景置いておきますね。
カンファレンスとは？CfPとは？プロポーザルって出すといいことあるの？調べてみました！
はじめに
タイトルはふざけていますが本文はまじめです。
カンファレンスとは
私達ソフトウェア開発者の世界におけるお祭り、それが技術カンファレンス（以下「カンファレンス」）です。年に一回、日本中あるいは世界中から人々が集まり特定の技術分野に関する発表を行います。カンファレンスには企業が主催するもの（例：Google I/O）とコミュニティあるいは任意団体が主催するもの（例：RubyKaigi）があります。
カンファレンスのメインコンテンツは技術発表です。では、その発表はどのようにして集められるのでしょうか。
CfPとは
技術発表を公に募集するものがCfP（CFPとも）です。この単語は"Call for Proposals"または"Call for Papers"の略称であると言われますが、言わんとすることは同じで「発表募集」です。
もしカンファレンスの主催者が大勢の人から発表者を集めたいと思った場合、CfPの形式を取ることが多くあります。それ以外の方法だと主催者から個別に声をかけていく方法が考えられますが、コストなどの兼ね合いから一定以上の規模ではCfPのほうが好まれる傾向にあります。
CfPにおいては、あるカンファレンスでの発表を希望する人が「プロポーザル」と呼ばれるドキュメントを主催者に提出し、主催者はそれらの中から自分たちのカンファレンスにふさわしいと思われるものを選びます。選ばれたプロポーザルを書いた人は実際にカンファレンスで発表することになります。
CfPの選考は名前付きでの選考とそうではない匿名形式での選考があります。前者においては「この人の話が聞きたい」という要素が含まれるのに対し、後者ではプロポーザルの内容によってのみ判断が行われるという違いがあります。事前に選考の指針やガイドラインが示されている場合も多いのでプロポーザルを提出する際には参考にしましょう。
プロポーザルを出すといいことがあるの？
まず、自分が好きなカンファレンスに対するある種のサポートの意味合いがあります。というのは、多くのカンファレンスではプロポーザルが集まらないと質量ともに十分なコンテンツを確保できないからです。もちろんむやみにプロポーザルを送ればいいというものではありませんが、もし自分が発表に値する内容を持っていると思うのであれば、時にはカンファレンスに発表者として参加してみるのもよいのではないでしょうか。
もしプロポーザルが採択されなくても、プロポーザルを書くことそれ自体にメリットがあります。プロポーザルを書く過程で自分のスキルや得意なことの棚卸しをすることになるのです。これはキャリアや技術スタックの観点で意味を持ちます。
そして、プロポーザルが採択されて登壇・発表をするとさらに良いことがあります。カンファレンスでの発表は公的な成果であり、例えば職務経歴書などに書くことができるでしょう。特に印象的な発表をすれば多くの参加者の記憶にも残り、フリーランスのような個人の名前に依存した働き方をしている人にとってはかなり大きな効果があるでしょう。また、参加者とのコミュニケーションを取りたいときにも発表自体がネタになるのでその点でも役に立ちます。
私個人のことですが、「VimConf2018にプロポーザルを送る→採択されて発表する→翌年の主催者の一人になる」という流れがあり、結果的にはKaigi on Railsでチーフオーガナイザーをするにまでつながってきています。このような出会いはカンファレンスでの発表の醍醐味かもしれません。
さいごに
いかがでしたか？カンファレンスでの登壇・発表に興味を持っていただけたら幸いです。
最後に、6月17日の20時から、「登壇準備もくもく会」と題したイベントを開催します。ぜひご参加ください！
