2020年の抱負
前置き
やっぱり抱負を書かないと一年が始められないと思うので、今から今年の抱負をつらつら書いていきます。
キーワードは「創造」
2019年のキーワードは「自律」だったのですが、今年は「創造」がキーワードかなと思っています。
理由としては、自律についてはある程度達成できたという感覚があり、それを踏まえて守りから攻めに転じる一年にしたいなという想いがあるからです。
また、後述するように大型のテックカンファレンスをやる可能性があるというのがあるのですが、それって立派な創造行為だよなという自負がありまして、このキーワードとなりました。
やることリスト2020
今回はやりたいこと順になっています。
テックカンファレンスをやる
これはおそらくRailsに関係したテックカンファレンスになる可能性が高いのですが、すでに界隈にはRubyKaigiがあるということを踏まえつつそれとは異なるカンファレンスをやるという方向性になりそうです。これについては語ると長くなりそうなので今回は省略します。
ちょっと痩せる
なんかわからんけど最近体重が顕著に増加して70キロ台を突破してしまったので、2020年はせめて70キロちょうどくらいまで体重を落としたいと思います。
Rails以外の技術を一つ勉強する
毎回言っている気がしますが、Railsしかできないというのも技術者としてはあまりよろしくないよねとは常日頃感じているので、2020年はフロント関係の技術とかやりたいなあと思っています。
代表作のOSSを作る
去年はRailsにコントリビュートできたりと色々やれた感はあったのですが、自分に代表作がないのがなんとなく寂しく感じるようになってきたので、作ってみたいなあという気がしています。
まとめ
書き出してみると結構やりたいことありますね……
健康に気をつけつつ攻めの姿勢で過ごす一年にしたいですね！
Railsの未来についての一考察
概要
前置き
この記事はRails Advent Calendar 2020の15日目の記事です。昨日はnegito6さんの忙しい人のための Rails デバッグ方法まとめでした。
動機
うなすけさんのRailsを主戦場としている自分が今後学ぶべき技術について(随筆)という記事と、それに対するmizchiさんのアンサーブログ、Re: Rails を主戦場としている自分が今後学ぶべき技術についてに触発されて書いています。
お断り
この記事ではRailsの技術的な側面を意図的に重視していません。というのは、私がRails以外の技術についてそこまで詳しくないため比較するのが困難だからです。
また、ふわっとした話題を扱うということもあり、どうしても書き方が推測多めになってしまっています。これは私の知見と経験の少なさによるものです。
本編
アプリケーション開発のマトリックス
いきなりですが、アプリケーションを開発するときに、チームのサイズ感と将来的なスケール感とをそれぞれ横軸と縦軸にすると以下のようなマトリックスが描けるかと思います（テキスト失礼！余談ながら、Webでいい感じにマトリックスみたいな図が描けるツールあったら教えてください）。
| チームサイズ | 将来的なスケール感 |
|---|---|
| スモールチーム | スケールしない |
| ビッグチーム | スケールしない |
| スモールチーム | スケールさせたい |
| ビッグチーム | スケールさせたい |
このうち、「ビッグチーム・スケールしない」というアプリケーション開発は例が他と比較して極端に少なさそう（スケールしないならビッグチームを支えられない可能性が高い）なので、実際に考えるべきはそれを除いた3つになります。
Railsはスモールチームでスケールしないアプリケーションを開発するのに最適
上記のマトリックスのうち、Railsが最も力を発揮するのは「スモールチーム・スケールしない」のケースです。これはRubyが動的型付け言語であるということと、Railsのそもそもの設計思想によるというが私の考えです。
Rubyが動的型付け言語であるということは、Rubyでの開発はチーム規模が大きくなるほど生産性が（その他の言語と比較して）急激に低下しやすいことを示唆しています。これにより、Railsはスモールチームに最適化されていると考えられます（異論はあると思います）。
Railsの設計思想についてはやさいちさんのRuby on Railsの正体と向き合い方に詳しいのですが、要するに「少人数チームによる速くてキレイな開発を実現するためにコンポーネントを密結合させている」という話で、これがRailsではスケールが困難という事実につながってきます。もちろん、Ruby言語自体のスケーラビリティが低いということも場合によっては意味を持つでしょう。
チーム規模の拡大とスケールを前提としたアプリケーションをRailsで作るのは理にかなっているとは言えない
ということは、なんにせよスケール前提のアプリケーションであれば、それをRailsで構築するのは最適ではないのかもしれません。少なくとも、何らかの工夫なしにRailsアプリケーションがスケールしていくと辛くなってくる、という事例は複数あるようです。また、チーム規模が大きくなることでRailsでの開発が最善ではなくなってくるケースもあるでしょう。
何より、世の中にはRails以外の選択肢も豊富にあります。静的型付けやスケーラビリティを求めるのであればそれらを採用することが最適である場合が多いと考えられます（現状のチームが持つ技術的な強みなど他の考慮点もあるので常にとは言えない）。
スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークがRails
RailsのオリジナルアプリケーションはBasecampですが、このアプリケーションを開発しているBasecamp社は創業当初から社員数を増やさないことを徹底しているらしく、チームページによれば、創業から21年経った今でも60人ほどしかいないようです。
また、Basecampというアプリケーションはフリーミアムモデルを適用しておらず、価格ページによると現在は月99ドルの固定価格のようです。これはBasecampが大規模にスケールしなくてもビジネスとしては成立するということを意味しています。
このように、Railsの開発を最も強く推進しているBasecamp社の現状を考えると、Railsが「スケールが不要なアプリケーションをスモールチームで開発する」ことに特化しているとしてもさほど不思議ではないでしょう。
興味深い話として、Basecamp社は自社のスマートフォンアプリをWeb技術中心で開発し、そのために自社開発のライブラリであるTurbolinksを活用して、わずか数名のチームでiOSとAndroid向けのスマートフォンアプリを開発できたということです（リンクを探したのですが見つかりませんでした…）。このように、Basecamp社のアプローチは少なくとも彼らの環境では機能しているようです。
また重要な点として、Railsはこの「スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワーク」としては最も成熟したフレームワークです。近年ではLaravelとの差が急激に縮まっている、またはすでに追い抜かれているとの言説もあるようですが、その文脈においてすらRailsの成熟度と利便性は否定されません。
Railsが強みを発揮できるケースはどれくらいあるのか
この「スケーラビリティが不要なアプリケーションをスモールチームで開発する」というシチュエーションですが、Webアプリケーション開発の全体に占める割合はどのくらい大きいのでしょうか。意外と大きいのでは、というのが私の見解です。
まず、スタートアップ企業が開発するアプリケーションはすべからく少人数での開発となる場合が多いです。これは単純に資金が少ないまたは貴重であることからチーム規模を大きくできないケースが多いでしょう。スモールビジネス（スタートアップと違って大きく成長する前提ではない）も定義上スモールチームでの開発をするしかありません。これらのケースではRailsを採用することは、以下のスケーラビリティの問題をクリアできるのであれば、合理的な選択肢の一つと考えて間違いないでしょう。
アプリケーションのスケーラビリティについてですが、いわゆるSaaSの場合はスケールメリットが相対的に小さいとは考えられます。一方、UGC（User Generated Contents）のサービスであれば、スケーラビリティは必須になってくるでしょう。それ以外にもECサイトなど、急激なスケーラビリティを必ずしも必要としないサービスはそれなりにあると思われます。
個人開発の友
Railsは「フルスタックフレームワーク」であり、それが逆にフロントエンドの最適化の妨げになっているという話がmizchiさんの記事の一つの論点であると私は理解しています。私はフロントエンドに詳しくないので深く議論することはできないのですが、Rails（あるいは他のフルスタックフレームワーク）がフロントエンドの最適化をある意味で犠牲にして提供しているものがスモールチームでの生産性です。その究極の形は個人開発でしょう。
個人開発は笑い飛ばせるような存在ではもはやなく、実際にいくつものサービスが個人開発から育っていっています。そこでは「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。
これらの点で他のフレームワークがRailsを超えるまでは、Railsはある程度安泰と言っていいかもしれません。
Railsの改善点：段階的なスケーラビリティ
もちろん、ここまでの話はRailsに問題がないことを意味しません。私の考えでは事実は逆で、Railsには改善すべき点が多くあります。ここではいくつかの考えを紹介します。
Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。これは、現実の世界では「スケールするアプリケーション」と「スケールしないアプリケーション」にハッキリと分かれるわけではないという、これまであえて触れて来なかった事実に由来します。最初は個人開発またはスモールチームで作ったものが予想以上に成功してしまい、スケーラビリティを考慮する必要が出てきた―こんなシチュエーションはRailsの最も顕著な弱点です。
Railsはomakaseであるというのが、Railsドクトリンに掲げられたRailsの思想ですが、これに照らし合わせれば、Railsはいわば「スケーラビリティを標準で備える」べきです。具体的には、多くのケースでモデル層が肥大化することがスケーラビリティを下げているという点を踏まえ、モデル層を段階的に分割するような機構を導入することなどが考えられます。例えばコマンドオブジェクトやフォームオブジェクト、シリアライザなどです（大雑把にはそれぞれCRUDのD, CU, Rに相当します）。
もちろん、Railsのエコシステムにはこれらが含まれているのですが（それぞれinteractor-rails、yaaf、active_model_serializersなどが代表例）、これらは結局コアと統合されておらずメンテナンスなどの面で不安があります（実際、AMSのメンテナンスは滞っています）。
Railsに「段階的なスケーラビリティ」が組み込まれることで、開発の初速を担保しつつ開発をスケールさせられるようなフレームワークに進化すると良いなと思っています。
まとめ
というわけで、Railsの未来について考えてみました。この記事ではいくつかの点に触れることができず（例えばShopifyやCookpad, GitHubのような大規模Railsアプリケーションの実例など）、悔しい気持ちも少しあります。もしかしたら、また別の機会に似たテーマで書くかもしれません。
Rubyコミュニティカタログ2020
概要
Ruby言語の一つの特徴に活発なコミュニティ活動があります。東京だけでも10近いローカルなRubyコミュニティがあり、私はそれらのほとんどに参加したことがあったのでした。
しかし、今年はCOVID-19の影響でオフラインでの活動が困難となり、多くのコミュニティがオンラインに活動の場を移しました。この記事ではそんなRubyコミュニティをざっくりとご紹介します。
紹介の基準としては、少なくとも私が1回は行ったことがあるコミュニティに限っています。言うまでもなく、実際に体験したことがないものの紹介をするのは無理があるためです。また、現在も活動しているコミュニティだけを紹介しています。
本編
Asakusa.rb
老舗コミュニティであるAsakusa.rbは現在も毎週火曜日に活動しています。一時期は毎回使用するボイスチャットツールを変えていたのですが、現在ではDiscordを使用することが多くなっています。
集まる人たちはRuby歴が長い人も多く、しばしば「インターネット老人会」的な会話になることもあります。私のような若輩者には非常にありがたい話です。
雑談ベースの場ではありますが、回によっては非常に静かであることもあります。
Tama.rb
比較的新興のコミュニティであるTama.rbは夏ごろから活動を再開し、"Coffee Lounge"と名付けた雑談会をほぼ毎月どこかの週末で開催しています。また、「OSSコードリーディング部」の活動も内部的に行っており、先日はWEBrickのコードリーディングを公開形式で行うなど課外活動も行われているコミュニティです（ちなみにコードリーディング部は私が音頭を取っています）。
Slackでのコミュニケーションが活発であることも特徴的で、総じてにぎやかなコミュニティといえるでしょう。
私はTama.rbの共同オーガナイザーの一人です。
Fukuoka.rb
Fukuoka.rbは（文字通り）福岡で活動しているRubyコミュニティです。現在は21時からの「夜会」をメインに毎週水曜日に活動しています。
形式はいわゆるもくもく会に近いですが、回によっては雑談メインになることもあります。
エンジニアフレンドリーシティ福岡アワードのコミュニティ部門を受賞したようです。
Sendagaya.rb
Sendagaya.rbは東京ではAsakusa.rbと並んで毎週開催をしていたコミュニティです。現在もオンラインで毎週月曜日の19時30分から活動しています。
ディスカッションメインですが、その場で話題が決まります。自由な雰囲気で、フィヨルドブートキャンプの受講生を中心に未経験の人が比較的多く来るのも特徴的です。
Mitaka.rb
Mitaka.rbは三鷹市近辺のRubyistのためのコミュニティです。ずっとイベント管理アプリケーションをモブプロで作る活動を行っており、オンラインになってからも継続しています。
だいたい毎月第2木曜日に開催されています。
Omotesando.rb
Omotesando.rbは毎月第1木曜日に開催されているコミュニティです。しばらく活動を休止していましたが、11月から再開しています。
LT会メインで、コミュニティのオンライン移行に伴いLTの場が減った中で貴重な存在です。
オフライン時は懇親会が豪華だったのですが、オンラインに移行してからも懇親会は行っています。寿司は自前です。
西日暮里.rb
西日暮里.rbは長期に渡って活動しているコミュニティです。オンラインに移行してからはもくもく会メインで活動しています。
ボイスチャットを使わずにテキストチャット中心にコミュニケーションを取るのが特徴的になっています。
開催は毎月最終の月曜日が多いようです。
nikotama.rb
nikotama.rbは楽天のメンバーが中心となって運営しているコミュニティです。最近はオンラインでLTとディスカッションを組み合わせた活動を行っています。
Rubyに関するニュースを紹介するコーナーもあるなど、内容の多彩さが特徴的です。
火曜日の開催が多いようですが、他の曜日で開催することもあります。
Machida.rb
Machida.rbは今回取り上げるコミュニティの中では最も新しいコミュニティです。最近は毎回テーマを変えてオンラインで活動しています。
こちらもフィヨルドブートキャンプの関係者が多く参加しています。
開催は第1金曜日です。
Shinjuku.rb
Shinjuku.rbはディスカッションをメインとしたコミュニティです。LTをする人がいればLTが行われ、その内容についてディスカッションが行われます。
最終水曜日に開催されています。
Hamada.rb
Hamada.rbは島根県浜田市の地域Rubyコミュニティです。現在はオンラインで"Ruby Hacking Challenge"の活動を行っています。
Ruby言語本体に関する話題が多いのが特徴です。
火曜日に開催されることが多いようです。
Sendai.rb
Sendai.rbは仙台市の地域Rubyコミュニティです。現在はオンラインでもくもく会と企画をだいたい交互に行っているようです。
開催は月後半の木曜日が多いようです。
Entaku.rb
Entaku.rbは私が主催しているコミュニティで、オンラインでのディスカッションにフォーカスしています。
もともとの意図としては、COVID-19下で新しい出会いが減ってしまったため、ディスカッションを通じて知り合いを増やしてほしいと考えて作ったコミュニティです。
最近は私が忙しくてあまり開催できていません。
Grow.rb
Grow.rbは私が去年始めたコミュニティで、Rubyのコードを書くことにフォーカスしています。
オンラインでも数回活動しましたが、私が忙しいため開催頻度が減ってしまっています。
まとめとちょっとした感想
というわけで、私がCOVID-19後に行ったことのあるコミュニティについてご紹介しました。
日程被りについて
ちなみに、私はShibuya.rbのオーガナイザーでもあるのですが、最近活動できていません。理由はやはり忙しさではあるのですが、それとは別にある事実もあります。
それは、「オンラインだとすべてのコミュニティに参加できるため、日程被りを気にしないといけなくなった」という点です。実際、地域.rbカレンダーというものがあるのですが、これを見ているとほとんど隙間がありません。従来であれば物理的に行けなかったので気にする必要はなかったのですが、全てがオンラインになると気にする必要が少し出てきます。
どうせ開催するならたくさんの人に来てほしいな、と考える私のような人間にとって、この日程被りはなかなか難しい問題だったりしています。
おわりに
そんなわけで、コミュニティの紹介をしつつ最後に主催者としての私の気持ちについてもちょっとだけ書いてみました。
ご覧いただいたようにRubyコミュニティはオンラインでも活発に開催されています。またどこかのコミュニティでお会いしましょう！
プログラミングを学習する上で気をつけるべきこと―コーディング・調査・質問
前置き
この記事はRails Girls Japan Advent Calendar 2020の2日目の記事です。昨日はsuperrino130さんのターミナル で文字化けしたら Git Bash を使おうでした。
概要
この記事では「プログラミングを学習する上で気をつけるべきこと」というテーマでいくつかのTIPSを書いていきます。
プログラミングを学習中の（業務歴がない）方あるいはプログラミング学習に興味がある方が主な対象ですが、業務歴がある方でも役に立つことはあるかもしれません。
また、RubyやRailsなどの言語やフレームワークに固有の話ではなく、あくまでプログラミング学習一般の話をしたいと思います。
本編
手を動かす
実際にコードを書くのが上達への最短ルートであることは間違いありません。本を読む・動画教材を見るなどの学習法はもちろん有効ですが、コードを書くことと併用することで更に効果が高まると思います。
ただ、闇雲にコードを書くと間違ったやり方を覚えてしまったりもします。コードを「正しく」書くためにはいくつかの方法があります。
写経する
まずは写経です。これは本などに出てくるサンプルコードをそのまま書き写す方法です。いわば「体で覚える」やり方ですので、合う合わないがかなりあります。私個人はあまり合わないようですが、もくもくと練習するのが好きな人にはうってつけです。
写経に慣れてきたら、写経したコードをベースに自分なりの改造を加えてみてもいいかもしれません。その際、Gitなどを使って元のコードにすぐ戻れるようにしておくとはかどります。
レビューを受ける
もう一つ重要なのがレビューを受けることです。どんなに完璧だと思っていても、自分が書いたコードには何かしらの改善点があるものです（プロの開発者ですらそうなので心配無用！）。あるいは、自信がないコードを見てもらいたいということもあるでしょう。
身近にコードレビューをしてくれる人がいるなら、その人にお願いしてコードを見てもらいましょう。お題は何でもよいのですが、課題にアクセスしやすく理解もしやすい競技プログラミングなどがおすすめです。
身近にレビュアー候補がいないなら、Exercismなどのサービスを利用するのも一手です。このサービスではメンターにコードを見てもらいながら徐々にコードを改善していくことができます。英語でのコミュニケーションになるのが難点ですが、英語に自信がある人におすすめできます。
同じ問題を何通りもの方法で解いてみる
もしレビューが受けられないのであれば、セルフでレビューをするしかありません。このときにポイントとなるのは、同じ問題には複数の解法があるということです。同じ問題を考えつく限りの方法で解こうとすることで、結果的にコードレビューを受けたのに近い効果を得られるかもしれません。
解く問題ですが、例えば伊藤淳一さんの問題などが良いでしょう。ネットに回答例があるものであれば自分で答え合わせもできます。
上手に調べる
ある問題について調べる能力はプログラミングをする上で欠かすことができません。調べ方にはコツがあり、コツを抑えることで効率的に調べることができます。
エラー内容をコピペする
なにかを調べる必要に駆られるケースはいくつもありますが。最も多いのはエラーに直面したときでしょう。
エラーメッセージはほとんどの場合英語ですが、恐れる必要はありません。エラーの出方もメッセージの種類もたかだか数十通りくらいしかありませんし、コピペすればかなりの確率で解決法がわかります。
その際、自分の環境に固有の問題との区別を付けることが重要です。例えば、以下のようなRubyのコードがあるとします。
hoge
ここで、hogeはいきなり登場しているのでエラーになります。おそらく、NameError (undefined local variable or methodhoge'のようなエラーになりますが、メッセージに含まれるhogeは今まさに問題となっている名前そのものです。これを除外して、例えばNameError undefined local variable or method`とWeb検索できれば解説が載っているサイトまでたどり着けます。
基本的に、「名前」（今回はhoge）は検索クエリに含めても意味がない場合が多いです。NameErrorのようなErrorで終わっている単語とuninitializeやundefinedのような否定的な意味の単語を組み合わせて検索するのがコツです。
公式情報から探す
RubyやRailsのような成熟したソフトウェアは公式の情報が非常に充実しています。まずは公式情報から調べるようにすることで余計な手間を省ける可能性があります。
Webで検索する際は、"site: ruby-lang.org"のようにサイトを指定すると公式サイトからの情報のみに絞り込むことができます。
注意点としては、公式情報は（以下にあるように）英語で書かれている場合が多いです。「英語にビビらない」こともプログラミング学習におけるポイントの一つです。
日本語で出てこないときは英語で調べる
プログラミングに関する情報はほとんどが英語で出回っています（Rubyなどの少数の例外を除く）。エラーメッセージを検索する場合は結果的に英語での検索になりましたが、もっと抽象的な調べ方をする場合でも英語で検索するのは有効な手段です。
例えば、"How to reverse array in Ruby"（「Rubyで配列を逆転させる方法」）のように調べると、高確率で海外のQ&Aサイトがヒットします。そのサイト内でのベストアンサーを頼りにすれば、多くの場合問題を解決できるでしょう。
なお、比較的マイナーなライブラリについて調べようと思うと日本語での情報がほとんどない場合もあります。そのような場合は否応なく英語で調べることになります。
上手に質問する
なにかを学習するとき、質問をしたくなるケースがあると思います。プログラミング学習においては現役のエンジニアが質問に回答してくれる場所がオンラインに複数存在しますが、同じ質問でもいくつかの点に注意を払うことで回答を得やすくなります。
画像を貼らない
エラー画像を貼ってはいけません。繰り返します、エラー画像を貼ってはいけません！
エラーはテキストで表示されます。テキストはコピペできます。テキストは加工できます。テキストならタイポが見つかりやすくなります。エラーを画像で送るとこれらの利点がすべて消し飛んでしまいます。
エラーについて質問したいなら、エラー内容をコピペしてください。それだけで回答者はだいぶ楽になります。
5Wをしっかり記述する
質問をしたいときというのはなにかに困っているときです。その「困り方」は、質問者であるあなたはわかっていますが、回答者の人は全く知りません。この知識の差が困難を生みます。
質問をする際、"5W"をできるだけ正確に記述するように心がけてください。"5W"とは、
- When, 問題が起きたのはいつか（問題の直接の原因と思われる行動）
- Where, どのような環境で問題が起きたのか（OSの種類や言語のバージョンなど）
- Who, あなたはどこまで問題を理解しているのか（問題を修正するために何を試してみたのか）
- What, 問題となっている具体的なものはなにか（ライブラリやフレームワークの名前）
- Why, なぜそれが今問題になっているのか（何を達成したいのか）
です。
具体例を示します。例えば、
「画像アップロードがうまくいきません！」
はダメな質問です。一方、
「Mac環境でCarrierwaveというライブラリを使って画像をアップロードしたいです。ローカルにはアップロードできていますが、S3にアップロードしようとするとNoMethodErrorが出ます。どうすれば修正できるでしょう。以下にログを貼ります。」
は良い質問です。
省略しない
質問をするときに、「重要でない」部分（ログの一部など）を省略する誘惑に駆られるときがありますが、これは罠です。というのは、どんな情報が重要なのかを判断するのは回答者であって質問者ではないからです。
質問には可能な限り多くの情報を載せましょう。断言しますが、情報量が多すぎて困る回答者はいません。ほとんどすべてのケースで情報が少なすぎるのが問題なのです。
まとめ
というわけで、コーディング・調査・質問の3つのサブテーマでプログラミング学習における注意点について解説してみました。
プログラミング学習は困難な道のりですが、この記事にあるような抑えるべきところを抑えればぐっと効率が上がるはずです。みなさんのプログラミング学習の道が実り多きものでありますように！
データで見るKaigi on Rails STAY HOME Edition
概要
この記事はKaigi on Railsに関するいくつかのデータを公開して、オンラインカンファレンスを更に良いものにするための考察を行うためのものです。
なお、以下で使用されているグラフの数値と本文中の数値が異なるケースがありますが、グラフ表示上の制限などによるものです。ご了承ください（数値に大差はないため、論旨には影響がないと考えています）。
データ
視聴者数など
トータルの視聴数（視聴者数ではない）は1622でした。ユニークな視聴者数でいうと705となっています。延べ視聴時間数は約1600時間、1視聴当たりの視聴時間は約1時間でした。
また、同時視聴者数は240人前後で一定でした（お昼休みなどを除く）。
コメント
コメント数は1595でした。ということは、1回視聴されるごとに1回コメントが残されていた計算ですね。
視聴者属性
視聴者のうち、男性は82.7%女性は17.3%でした。業界の男女比にかなり近い数値が出たのではないでしょうか。
また、年齢分布は
- 18~24: 5.5%
- 25~34: 47.4%
- 35~44: 40.7%
- 45~54: 6.4%
となっています。やはりRailsを業務で使っているであろう年齢層が多く、若年層にはあまりリーチできない結果となりました。
視聴デバイスなど
視聴に使われたデバイスは、コンピュータが約50%、スマートフォンが約40%となっています（残りはタブレットなど）。興味深いのは、4割を占めるスマートフォンが視聴時間に占める割合はわずか7%しかないという点です。具体的には、スマートフォンでは平均して約15分しか視聴されていません。この数値はコンピュータの約1時間10分と比べると非常に低く感じられます。
また、OSで見ると、Mac, iOS, Androidの順に多く、この3つで9割を越えます。Windowsは2.4%のみであり、Rails開発者のほとんどがWindowsを利用していない可能性を示唆しています。
考察
ここから先は個人的な考察となります。
良かった点
単純に、700人もの人に見てもらえたのはよくやったと思います。多くの人に見てもらうのは直接の目的ではないにしても、やはりせっかくの素晴らしいコンテンツを一人でも多くの人に届けたいという想いもあります。約240人がほぼ通しで見てくれたということも含め、初回のイベントとしては上々だという受け止めです。
また、女性の視聴者が多かった点は重要だと思います。今回のKaigi on Railsは、運営メンバー7人のうち3人、登壇者の16人（基調講演含めれば18人）のうち4人が女性でした。視聴者も含め、全体的な女性比率は2割くらいと言ってもよいでしょう。オンラインカンファレンスはオフラインによくある「会場に男性ばかりで参加しづらい」というような感覚（あくまで感覚であって実際にはそんなことはないのですが…）が生じづらく、結果的に女性の視聴を促した面があるのかもしれません。
コメントの多さもかなり目を引きます。積極的にコメントをしてくださった方々が多かったからこそだと思いますし（ありがとうございました！）、オフラインカンファレンスのわいわい感が少しでも出せていたらよいなと思います。
悪かった点
そんなに悪い点はないのですが、やはり若年層にリーチできなかったのは少し残念です。今回は初回でありリーチも限られていたので仕方がないのですが、20代前半の人たちが興味を持たない技術は徐々に衰退していきそうだなあ、などと考えると、次回以降は若年層にもアピールできるとなおよいのかなと思いました。
まとめ
また次回！
Kaigi on Railsのチーフオーガナイザーを務めました
はじめに
先日行われたKaigi on Rails STAY HOME Editionのチーフオーガナイザーを務めていました。カンファレンスの共同オーガナイザーを務めたことは何度かあるのですが、チーフという立場は今回が初でした。
今回はチーフオーガナイザーの目線から、Kaigi on Railsについて書けることを書いていこうかなと思います。
カンファレンスの概要
基本的には公式サイトに書いてありますが、一応記載すると、2020年10月3日（土）の10時から18時ごろまで、YouTube Live上で配信されたオンラインカンファレンスです。基調講演が2つと16の通常セッションで構成され、常時230人ほどにご視聴いただきました。
懇親会はSpatialChat上で行われ、40人ほどにご参加いただきました。
開催に至るまでの経緯
名称の決定とメンバーの集合
もともと2019年の終わりごろにイベント開催の機運が高まっていたところ、Railsコミッターの@a_matsudaさんに猫廼舎という喫茶店での打ち合わせをセットしてもらいました。実はマスターの@ogijunさんは最古参のRubyistで、かつて"Kaigi on Rails"という名称のカンファレンスを構想していたのです。その場で"Kaigi on Rails"という名称を引き継がせていただくことになり、企画はスタートしました。
Kaigi on Railsはこの時点ではオフラインカンファレンスとして企画されていたのですが（ビフォーコロナ、覚えていますか…）、板橋区の会場をひとまず抑えることに成功しました。
その後、2020年に入ってから運営メンバーに声をかけ始め、私を含めて8人のメンバーが集まりました。また、デザイナーにはべこ（@becolomochi）さんをお迎えしました。2月に顔合わせをしたタイミングまでは何事もなかったのですが、そこで皆さんご存知の通り、COVID-19がやってきます。
オンラインカンファレンスへの移行
3月になると、情勢はすでに厳しくなっており、オフラインで運営メンバーが集まることも困難になっていました。その後幾度かオンラインでのミーティングを重ねましたが、最大の問題は「オフラインにするか、オンラインにするか」でした。
やはりオフラインの経験を捨てがたいというメンバーもいましたし、私もそれは重々承知していたのですが、安全な開催をするためにはオンラインにするしかないということ、すでに社会的にもオフラインでのカンファレンス開催は困難になってきていることなどを私は感じていました。
議事録によると（オンラインミーティングの良いところとして、議事録が残ることがあります）、
今後のテックカンファレンスの位置付けが変わってしまうのでは？という感覚がある
初回だからこそ全力でオンライン側に振るのも手ではないか
違った体験として受け入れてもらえるのではないか？
ということを私は他のメンバーに説得し、結局4月末にオンラインでの開催を決定しました。
オンラインカンファレンス何もわからない
オンラインでの開催を決定したものの、問題は山積みでした。何しろ、オンラインカンファレンスはそもそも存在したことがないものであり、当然運営経験のある人もいません。何を使って配信するのか、という初歩的な問題すら誰も答えを知らないので、手探りで進めていくことになりました。
ミーティングの頻度を増やし、議論を積み重ねた結果、日程の変更（平日2日間から土曜日1日間へ）などを決定していき、CFPの公開を急ぐこととなりました。
CFPとタイムテーブル
CFPは7月末まで公開され、60件を超えるプロポーザルが集まりました。
1つの工夫として、CFPの公開終了直前に"Kaigi on Rails new"と題したLT会を開催しました。ここでイベント名を広めつつプロポーザルの提出をアピールしたのです。
プロポーザルの選定を終え、タイムテーブルを確定させたときにはもう8月も終わりに近づいていました。ここからようやく広報的な活動が始まっていくことになります。というのは、初回開催のカンファレンスは知名度も信用度もないため、コンテンツが確定しないと広報できないのです。
そして本編へ
プロポーザルが採択された人たち（以下登壇者）に連絡をし、動画提出を選んだ人たちには事前に動画を提出してもらいました。ライブ配信を選んだ人たちは当日Zoomで接続して配信するのですが、事前に素振り会をすることで接続面での問題の軽減を試みたりもしました。
また、銀座Rails#25で@ogijunさんと@a_matsudaさんと一緒に歴史の話をしたり、うなすけ（@yu_suke1994）と一緒にタイムテーブルの解説をしたりしました。
当日
コンテンツに関することは、参加者の方々がまとめてくれているのでここには書きません。
カンファレンス本編
開会式には隠しコンテンツとしてMatzのビデオメッセージがありましたので、手短にイベントの紹介をするに留めました。Aaronの基調講演が始まって、運営メンバーは少しだけ一息つくタイミングを得ましたが、緊張は休まりません。切り替えのタイミングでは常に気を張っていましたし、そのため若干アナウンスのテンションが下がっていたなあと今は反省しています。
その後、いくつかのトラブルはありつつもなんとか乗り切り、カンファレンスは進んでいきます。トークの最中はあまりやることがないため、トークを聴くゆとりも徐々に出てきました。
困ったのは、音声の問題です。登壇者との接続用Zoomと運営メンバー間のコミュニケーション用のDiscordと参加者が観ているYouTube Liveと、音声が出ていて確認もしたいものが3つあるわけです。さらに、Zoomのミュートを忘れてDiscord向けに喋りかけてしまうと放送事故になってしまいます。このため、脳は急速に疲労していきます。
さらに、SpatialChatが本編中も開放されており、そちらで雑談もできるようにしていたのですが、そちらは全く確認する余裕がありませんでした。
閉会式では、ちょっとだけエモい話をさせてもらいました。「歴史」をキーワードに次回開催を宣言したのですが、本当に次回どうするかについては何も決まっていません。
懇親会
SpatialChat上での懇親会は、PCスペックなどの原因でトラブルを抱える人もいたものの、総じて好評なようでした。ここは私個人もこだわりが強い部分であったため、参加者の皆さんに喜んでもらえたのはとても良い手応えとなりました。
懇親会では私も一参加者として大いに楽しみました。個人的には、唯一の海外からの登壇者である@lulalalaさんと話せたのが非常に良かったです。
懇親会は23時まで続き盛り上がりましたが、予定通りに終了となりました。
振り返り
良かった点
- 無事開催できた
- アンチハラスメントポリシー的な意味で何事も起きなかった
- 配信が途中でストップしたりしなかった
- 誰も倒れなかった
- コンテンツがとても良かった
- 正直、初回としては最高レベルのコンテンツである自信がある
- 初学者の人にも満足してもらえた
- 私個人としても学びが多かった
- 少人数の運営メンバーで乗り切れた
- もちろん、個々のメンバーの負担は大きかった（これは課題）
- 全体的に挑戦したかったことに結果が出た
- SpatialChatを常時開放しておくのは、オフライン感が出てよかった
- 懇親会も、そもそも多くのオンラインカンファレンスでは用意されていないので、やってみて楽しんでもらえたのは収穫
- 動画とライブのミックスも実現できた
改善点
- 運営メンバーの疲弊
- どのカンファレンスでもある程度起こることではある
- タスク量の偏りはあった
- 本編でのいくつかのトラブル
- オペミスはまあ仕方がない
- 接続トラブルに関しては、事前フォローが必要だったかも
- もっと幅広い人にリーチしたかった
- これは初回なのでしょうがないという見解がベテラン勢から出ている
- 初学者を意識していたけど、そもそも初学者はどこにいるんだろう
その他宣伝
グッズはSuzuriで販売中です（私はこのデザインが大好きなので宣伝隊長をやっております）！
ブログを書くまでがカンファレンスだそうなので、これを読んだ本編参加者の皆さんもぜひ書いてね！
さいごに
スポンサー・登壇者・参加者の皆様、そして何よりここまで一緒に運営してきた運営メンバーのおかげでカンファレンスが成功したと思っています。また次回、2021年にお会いしましょう！
2019年のアウトプットまとめ
はじめに
端的に言います。ブログをサボりすぎていたのと時間が経ちすぎたのとで、2019年をきちんと振り返ることはもはや困難です（特に前半）。それでも、カレンダーの助けを借りてなんとかやっていこうと思います。
1月
1月は人生初のRailsへのコントリビュートをキメたのでした。この後もちょくちょくRailsにコントリビュートしていて、執筆時点では8コミットしています。これからもOSSへのコントリビュートは続いていくでしょう。
2月
2月はRails Girls Tokyo 11thのコーチをしました。過去最大の規模ということで、とても賑やかでしたね。この月まではブログをある程度真面目にやっていたのでした。
3月
3月はRails Developers Meetup（RailsDM）がありましたね。私は運営の一人として関わりました。DHHとメールのやり取りをしたのは思い出深いです。ジェレミーのトークも良いトークでしたし、yasaichiさんのトークが個人的にヒットしたり（もちろんどのトークも良かったのですが、一際目立っていたように思います）、とてもいいイベントになりました。
4月
4月はRubyKaigiで当日スタッフ（ヘルパー）をやったりしました。色々な人と触れ合えてとても充実した3日間でした（トークについては言うまでもなく）。技術評論社さんのレポートに寄稿もしました（nagachikaさんのキーノートのレポートでした）。
あと、Grow.rbの第0回もこの月に行ったのでした。そこでやった、Enumerableの再実装をテーマにRejectKaigiでLTをしたりもしました。
更に、Ruby本体のレポジトリにドキュメント改善のPRを送ったりもしています。めちゃ活動してますね…
5月
5月は仕事の環境がガラッと変わりました。これまで2人チームのスタートアップで開発者をしていたのがフリーランスのRubyプログラマとなりました。渋谷の『ウリドキ』という会社のお世話になることにしました（当時は『ウリドキネット』という社名でした）。 さすがに登壇とかは無理だったみたいです。 …と思ったら、銀座Railsでライブコーディングしてるんですね私。お題は本当にその場で決まったのでヒヤヒヤしましたがなんとか実装できました。
6月
6月は名古屋Ruby会議04とゆるはちという勉強会で登壇しました。前者は準備不足で不完全燃焼になってしまいました。30分という長さも含め、聴衆を引きつけることの難しさを改めて感じました。教訓としては、あまり抽象的な話を長くしないことですね。 更にこの月は記念すべき第1回のRails Girls Ehimeでコーチをしたりもしました（松山は人生初でした）。遠征がこの頃から増えていきます。 OSS活動ではActiveHashというgemに機能追加のPRを送って無事マージされました。これは仕事上必要だったもので、かなり達成感がありました。
7月
7月は私が運営の一人だったTamaRuby会議01が無事開催されました。私はコミュニティのことについてトークもしました。 Rails Girls Sendai 2ndにも行ってコーチをしてきましたが、カプセルホテルに泊まったことが仇となったのか風邪を引いてしまったことをよく覚えています。 更に、またしても銀座Railsに登壇して６月のゆるはちの再演をしました。
8月
8月はRails Girls Tokyo 12thのコーチをしました。ここまで読んで「こいつやたらコーチしているな」と思ったあなた、その印象は間違いではなく、なんと2019年に10回あった全国のRails Girlsで私は5回コーチをしているとのこと。半分は私がいると考えるとなんだか薄気味悪いですね。 この月はこれくらいで、やや低空飛行です。
9月
9月はTokyo Rubyist Meetupで英語での登壇がありました。内容はテスト高速化の話ですが、内容以上に英語で20分話すということに意義を感じていたりします。 他にも、Rails Developer Beer BashというイベントでLTをしました。 この月で面白いのは、OSSGateというイベントで進行役をやったことです。OSSをやりたい人とやったことある人が一緒にOSSへのコントリビュートを目指すのですが、進行役は結構やることが多くて大変でした。
10月
10月は人生初の沖縄の地を踏みました。もちろんRails Girls Okinawa 2ndのコーチのためです。Railsのおかげで本当にいろんなところに行ってますね。 フリーランスやフリーランス志望の人が集まる会でトークしたりもしました。要は「実力をつけるまでフリーランスになるな」という話で、会の趣旨的に大丈夫か心配でした。
11月
11月はVimConfがあってそれの運営をしました。イベントは非常に良いものにできたと自負できるものでしたが、代償として風邪を引いてしまい、翌週のRuby World Conferenceではつらい想いをしました。 その更に翌週にはEbisu.rbで「車輪の再発明入門」という、もともとTamaRuby会議で話す予定だったトークをしました。
12月
12月はLegalForce Ruby Meet Upというイベントでブロックの話をしました。このイベントにはMatzが来ていたので、Matzの前でRuby愛をテーマに話そうと思ったときにブロックが浮かんだのでした。 12月はアドベントカレンダーの月ですが、自分はRuby, Rails, Vim, Rails Girlsと4つのアドベントカレンダーに記事を書きました。それぞれは小さな記事ですが、例外的にRailsのだけはコードリーディングでとても重たくなってしまいました。
まとめ
全般的に雑ながらもなんとか書き終わりましたね。これ以外にも多分アウトプットはしているのですが、全部を書こうとするととても大変です。まあ、それくらい2019年はアウトプットの年だったということでご笑納ください。
