「カンファレンス・勉強会がRubyコミュニティを活性化している」　まつもとゆきひろ氏が歓迎する、ユーザーからの貢献

EVENT

RubyKaigi 2022

2022年09月28日に開催

プログラミング言語Rubyの国内最大級のカンファレンス「RubyKaigi」。「RubyKaigi 2022」のKeynoteで登壇したのは、「Ruby」開発者のまつもとゆきひろ氏。「Contribute to Ruby」をテーマに、Rubyの歴史・これからについて語りました。全5回。3回目は、Rubyユーザーからの貢献で特に募集していることについて。

スピーカー

まつもとゆきひろ

Ruby開発者

gemの名前のつけ方でまつもと氏が思うこと

まつもとゆきひろ氏：次「Gems」ですね、RubyGems、十何万個あると聞いた気がするんですが、Rubyのコアの部分だけではなくて、gemはすごく便利だと思います。みなさんも、どんどんgemを公開していただければいいんじゃないかなと思います。

私がお手伝いしているいくつかの会社でも、自分の会社で使っているものを一部gemに切り出して公開したり、オープンソースに貢献して、リクルーティングにも役立てている企業もたくさんあります。確かにそのとおりだと思うので、gemを提供することについてご一考いただければと思います。

Rubyのgemについていくつか思っていることがあって、1つは名前ですね。gemの名前のつけ方って、個人的には派閥が2種類ぐらいあって（笑）。1つは、なんかシンボリックっていうんですかね、実際の機能とまったく関係ない名前をつける一派がいて、それはそれですごくいい、Rubyの伝統としておもしろいと思うんですけども。

「Nokogiri」とか「Kaminari」とかですね。なんだこれみたいな感じ（笑）。特に外国人がそう思うことが多いんですけれども、1回覚えると覚えやすいというのは確かにあります。

一方、初心者は最初にそのgemを見た時に「なんでこれNokogiriなんだろう？」とか思うことがけっこうあって。そういう、覚えやすいけど最初のハードルが高いという欠点も若干あります。

逆に、すごくシンプルな名前。「Parser gem」とか「JSON」「YAML」とかですね。やっていることそのもの1単語みたいなやつがけっこうあります。個人的にはシンプルなほうが好きっちゃ好きです。

ただ、そうは言っても、例えばRubyの場合、プログラミング言語とルビーの名前の間にまったくなんの関係もないので、実際に自分の作っているプロダクトはシンボリックな名前だと思うんですね。やはり名前は重要で、自分の作っているgemやプロダクトにどんな名前をつけるかによって、運命がだいぶ変わってくるんじゃないかなと思います。

もし私がRubyを作る時に「Ruby」という名前を選ばなかったら。もうなんか違う名前を選んでいたら、RubyKaigiで1,000人の前で話をするとか、そういうことは起きなかったんじゃないかなと思うと、特に覚えてもらいやすい名前をつけるというのは重要なことではないかなと思います。

プログラミング言語の名前もいろいろあって、一番典型的なシンプルネームにAPLという言語があります。APLというのは略語で、略さないで全部書くと、「A Programming Language」。「あるプログラミング言語」、そのままですね（笑）。

そういう名前はもう二度と出てこないと思いますが、名前は重要なので、ぜひgemを作る時には名前をよく考えていただければなと思います。

gemは具体的なユースケースを想定して作る

もう1つは、スコープです。自分の達成したいゴールを明確にして、スコープも明確にするのがすごくいいんじゃないかなと思います。このへんが曖昧だと機能を拡張・拡大しすぎみたいな問題が起きたりしますしね。あと、実際に使う自分のユースケースに適合する機能を考えていただければなと思います。

DHHが最初にRailsを作った時、彼らは「こういうWebアプリケーションフレームワークがあるべきだ」と思って作ったわけではなく、当時作っていた、なんだっけ、名前忘れちゃった。「Basecamp」か。BasecampというWebアプリケーションの一部を切り出してきた上で、ちょっと調整してWebアプリケーションフレームワークとして作ったんですね。

というわけで、Ruby on Railsについて言うと、最初の日から「このユースケースを支援する」と明確にした状態で生まれてきました。

逆にRubyはそうじゃなかったんですけど（笑）。今振り返ってみる時に、みなさんに使ってもらいやすいツールを作るのに近道になるのは、具体的なユースケースがあるという方向性だなと思うので、みなさんがもしgemを作る時には、どっちかというとそっちのほうをお勧めします。

リクエストの優先順位付けにおいて手数が足りていない

貢献の中で、今ここが足りないなと私が思っているのは、「Triage」です。コミュニティも随分大きくなりましたし、参加してくださる方も随分増えたので、ありがたい限りではあるんですけれども、正直言うと、リクエストをさばく時に、ちょっと手数が足りないなと思う時があるんですね。

私たちは、開発者ミーティングというのを月に1回オンラインで開いていて、その時に、今までに来たフィーチャーリクエストの中でRubyに入れるべきものは何かをリストして、それを上から順番に議論しています。

どれを話題にしてどれを先延ばしするかを決めなくちゃいけないんですが、イシューが多すぎて、ミーティングも1ヶ月に1回で時間は有限なので、その時の決め方が、見つかったものを順番に、とかになりがちなんですよね。本当は重要なのに見落とされているというケースがたまにあるんですね。

こういうのを優先順位付けして、今まで議論されていないイシューのうち、これについては結論を出すべきだというものをリストアップする。そして優先順位を付けて、開発者会議にかけるとか。

遠藤さん（遠藤侑介氏）とかに「フルタイムコミッターだからやらせろ」という人たちも、もしかしたらいるかもしれないんだけれども、遠藤さんの特異な才能は、もうちょっと別のところで発揮されるべきではないかと（笑）。

そういうようなことを考えたりするわけです。こういうところで、もうちょっと協力してくださる方が増えると変わってくるんじゃないかなと思います。

管理・バックログ・翻訳に対する貢献も大歓迎

さらに言うと、我々が一番苦手なのは「Bookkeeping」というところで「ちゃんと管理する」みたいな話です。

開発者ミーティングで議論した上で、時間内に結論が出ないこともけっこうあるんですよね。そういうのは、「一度議論したから」と、結論が出ないまま放置されることが続いたりすることがけっこうあるんですよね。

なので、「これは結論が出ませんでしたが、今まで議論したことはこれこれで、中間的な結論はこれで」と記録して、次回に回すとか優先順位を管理して忘れないようにするということは、ぜひ必要だなと思います。

あるいは、開発者ミーティングの議事録を見たりとか。時々、議事録の内容と本当に議論したことがずれていることがあるので、そこを直したりすることも本当は必要です。

それから、バックログですね。議論したけどできていないやつ、あるいは、一度断ったんだけど、最終的にリジェクトしていないやつを記録しておくみたいな。コアにいる人たちはそういう細々としたことがすごく苦手な人が多いので、そういうところをやっていくことも必要ではないかなと思います。このように実際にコードを書けなくても、時間さえあればできるようなことがけっこうあるので、手を挙げていただける人がいれば、歓迎します。

それから、翻訳ですね。だいたいの情報は英語と日本語であるんですけれども、RubyのWebサイトなりドキュメントなりは、スペイン語、中国語、インドネシア語、マレーシア語、ロシア語など、いろいろな言語に翻訳されているのですが、十分ではない。

英語を見ればいいというのも1つのポリシーではあるのですが、可能であれば母国語で、自分の言語でドキュメントが見られるように翻訳チームに参加してくださる方がいらっしゃれば、歓迎しますということですね。

カンファレンス・勉強会がRubyのコミュニティを活性化している

それから、カンファレンスとかミートアップとかも大事だと思います。この会議もそうですが、やはりカンファレンスで直接人と会っていろいろなことを話すことによって、インスピレーションを受けることってけっこうあるんですよね。

今回のRubyKaigiも、何年かぶりに会って講演を聞くだけではなくて、廊下で雑談をしたり挨拶をしたり、そういうことによって受けるインスピレーションもたくさんあります。実際にありました。

また、それぞれの地区で勉強会をする時に、その交流の中から生まれてくるものってたくさんあると思うんですね。これらのカンファレンスとか勉強会とかを開催するのも、だいぶコストがかかると思います。特に、RubyKaigiクラスになっちゃうと、本当に大変だと思います。

私自身は、RubyKaigiのオーガナイザーメンバーではないのですが、松田さんの活動とか、みなさんの活動とかを見ていると、本当に頭が下がります。

あっ、そうそう、松田さんとかに拍手（笑）。

（会場拍手）

スタッフのみなさん、本当にどうもありがとうございます。

私も11月に松江で開かれる「RubyWorld Conference」のオーガナイザーの1人ではあるのですが、だいぶお飾りなので、見ているだけのことのほうが多いんですよね。

だいぶ規模が小さいカンファレンスでも死にそうになっている人たちを見るんですね。特に感染症で不確定な時期にカンファレンスを開くことは、本当に本当に大変なことだと思いますが、その中でカンファレンスを開いてくださっているみなさんに感謝しています。このカンファレンスによってRubyのコミュニティが活性化して、インスピレーションを受けると確信しています。

世界中では「RubyKaigi」であるとか、ヨーロッパの「Euruko」であるとか、「Ruby Conference」であるとか、各種地域の「Ruby Conference」であるとか、年末に向けてめじろ押しですが、彼らの働きがRubyのコミュニティを活性化し、インスピレーションを与えると確信しています。