2022年9月8日から10日までRubyKaigi 2022が開催されました。2日目の基調講演では、Rubyの作者であるまつもとゆきひろさんが登壇し、「⁠Contribute to Ruby」というタイトルで発表しました。

この講演では、Rubyの価値とRubyに関わる人々に期待するコントリビューションについて話しました。

Rubyの価値

まつもとさんがRubyを公開してから現在に至るまで、Rubyに対してさまざまな意見が寄せられ、批判的な意見もたくさんあったと言います。紹介されたいくつかの意見の中には、Rubyの存在自体を否定する意見もありました。

では、Rubyは存在する価値がないのでしょうか。

まつもとさんは「Rubyの価値について考えたい」と述べ、4つの観点でRubyの価値を紹介しています。

Productivity

Rubyという言語自体の生産性が高いだけではなく、RubyGemsやWebアプリケーションフレームワークなどが充実していることによって生産性が高くなっています。

具体例として挙げたのは、Ruby on Rails 7のHotwireです。「⁠フロントエンドチームとバックエンドチームを分けて開発することが主流となっている一方で、Rails 7ではHotwireを導入することでバックエンドチームだけでの開発を可能にしています。これにはRails作者であるDHH氏の思想“⁠小さなチームで開発する⁠”が表れている」と、まつもとさんは言います。

Community

コミュニティはRubyの価値の中で非常に重要です。

• Rubyのコアチームの開発メンバーがRubyをより良くしている
• RubyGemsのすべての製作者たちがRubyに価値を提供している
• これらを使っている人たちによって価値が創造されている

広いRubyのコミュニティが、Rubyというエコシステム全体の価値を実現しているのです。

Joy

まつもとさんは、Rubyを使っている人から感謝の言葉を向けられたときや、Rubyが多くの人々の生活に役立っていると実感するときに、喜びを感じるそうです。

発表では"Joy"の価値については触れていませんでしたが、「⁠Rubyが存在することで喜びを感じる瞬間があること、それ自体に価値がある」という想いが伝わってきました。

Money

Rubyがお金を生んでいることを示すデータとして2つのサイトを挙げています。

1つ目はTop Ruby Companiesのデータです。このサイトではRubyを使っている公開企業を、時価総額が高い順にリストアップしています。1位のAirbnbは600億ドル以上の時価総額を示しています（2022年9月9日時点⁠）⁠。まつもとさんは、時価総額をどう見るかは諸説あることにも触れたうえで、多くのビジネスでRubyが活用されていることを示しました。

2つ目はY Combinator - Top 50 Software Startupsのデータです。この記事では、2019年10月のY Combinator Top Companiesから上位50件のソフトウェア企業を抽出し、バックエンドの使用言語で時価総額を集計しています。このデータによれば、主要な（または最初の）言語としてRubyを使っている企業の時価総額は上位50企業の52%（924億ドル）を占め、2位Pythonの17%（299億ドル）と比較すると大きな開きがあります。

これらのデータから、Rubyは"Money"の観点でも価値を生み出していそうだと述べています。

価値を生み続けるための鍵はコミュニティ

「わたしたちが価値を生み出している限りは、批判的な意見を気にすることはあまりない」と、まつもとさんは言います。

Rubyがますます価値を生み続け、前に進み続けるためには、より多くの力が必要です。そして、その鍵となるのはコミュニティであり、Rubyに関わる人々からのコントリビューションが重要であると指摘します。

期待するコントリビューション

コントリビューションを期待する観点として、次の9つの事柄を紹介しました。

広報

まず1つ目は広報活動です。Rubyが誤解されたり、正しい情報が広く伝わらなかったりすることがあるので、ブログやSNSを通じて、広く情報を伝えてほしいと述べています。

バグ報告 / 機能要望

2つ目はRuby Issue Tracking Systemへのバグ報告と機能要望です。

Rubyを使う過程でバグを見つけたり新しい機能がほしいと思ったら、報告してほしいとのことです。実際に毎年リリースしている新機能の多くは、コミュニティからの提案によるものです。もしかするとその提案が明日のRubyの進歩につながるかもしれません。ただし残念ながら、提案された機能がすぐに採用されるとは限らず、8〜9割はさまざまな理由でRejectされます。そのためRejectされても心平穏にしていただければ、とのことでした。

バグ修正 / 機能実装

3つ目はバグ修正と機能実装です。最近GitHub - ruby/rubyでプルリクエストを受け付けるようになりました。先述のバグ報告・機能要望に留まらず、バグ修正・機能実装に踏み出すことも大いに期待しているとのことです。

ただし機能実装の場合には、事前に機能要望の議論をして実装可否が決定してからプルリクエストを出すことをオススメすると、注意事項を述べていました（先述の通り、多くの提案はRejectされるためです⁠）⁠。

ドキュメントの更新

4つ目はドキュメンテーションです。多くの開発者はコードを書くほうが楽しくてドキュメントの更新が放置されてしまいがちだと言います。

• 新しく追加された機能のドキュメントがない
• 既存のドキュメントのここが間違っている

等に気づいたら、Ruby Issue Tracking Systemに報告してほしいとのことです。

またtypoの修正の場合には、直接プルリクエストを出しても問題ないと付け加えていました。

RubyGems

5つ目はRubyGemsの開発です。RubyGemsを開発してどんどん公開してほしいとのことです。

ここで話はやや脱線して、RubyGemsの命名とスコープについて、まつもとさんは自身の考えを述べました。

命名には2つのケースが見られると言います。機能の内容から連想しにくいシンボリックな命名をするケースと、機能の内容を直接的に表現したシンプルな命名をするケースです。両者ともにメリットはあり、前者（例えばkaminariやnokogiriなど）は象徴的で覚えやすく、後者（例えばparserやyamlなど）は内容がわかりやすいです。

まつもとさんは、基本的にはシンプルな後者が好みとのこと。一方でRuby自体は前者のようなシンボリックなスタイルの命名であり、「⁠もしわたしがRubyをつくったときにこの名前を選ばなかったら、いまのRubyの発展はなかったかもしれない」と振り返っていました。どんな名前をつけるかによって運命がだいぶ変わってくると思うので、良く考えて命名してほしい、とのことです。

スコープについては、「⁠そのGemで達成したいゴールを明確にすること」「⁠自身のユースケースに適合する機能を考えること」を重視すると良いと言及していました。

トリアージ

6つ目はトリアージです。コミュニティが大きくなったので、機能要望を捌くときに手数が足りないと思うときがあるとのことです。

月に一度の開発者ミーティングで議論する際に、 issueが多すぎて話題の選定が難しく、重要な話題を見落としてしまうことがあるそうです。優先順位をつけて話題を選定すること、議論した内容を整理して記録し結論が出るまで管理すること、といった作業に協力してくれる方を求めているとのことです。

翻訳

7つ目は翻訳です。ドキュメントの翻訳が十分ではないとのことです。英語のドキュメントを読めば良いというのは1つのポリシーではあるものの、可能であれば多くの方が母語でドキュメントを読めることが望ましいと言及していました。

カンファレンス、ミートアップ

8つ目はカンファレンスやミートアップの開催と参加です。直接人と会って受けるインスピレーションはたくさんあります。RubyKaigiをはじめとするさまざまなイベントによって、Rubyのコミュニティが活性化することを確信していると語っていました。

開発者の雇用

最後の9つ目は、企業による開発者の雇用です。業務としてRubyの開発に貢献する人材を雇用してもらいたいと述べたうえで、すでに貢献している具体的な企業をいくつか紹介していました。

まとめ

その後Ruby3.2での新機能をいくつか紹介したうえで、発表の最後にまとつもとさんは次の言葉で締めくくりました。

「Rubyは価値を生み出す方向に進みます。Rubyの生産性、Rubyでプログラミングしているときの快適性をより良くするために前に進み続けます。より良い世界を作るために。Rubyをつくらないほうがよかったと言われる世界ではなく、Rubyがあるこの世界はすばらしいと思っていただけるようにしようと思っています。そしてそれは、みなさんといっしょにやっていくことだと考えています」（⁠まつもとさん）