RubyKaigi 2024 に Ruby Sponsor として協賛しました！
こんにちは。人材プラットフォーム本部プロダクト開発室 第五開発グループ所属の寺内です。 新卒からメドレーに入社して今年で 4 年目のエンジニアで、老人ホーム・介護施設の検索サイトである 介護のほんねの開発を担当しています。
メドレーは 5 月 15 日から 17 日に 沖縄県那覇市の那覇文化芸術劇場なはーと にて開催された RubyKaigi 2024に Ruby Sponsor として協賛しました！ RubyKaigi 2024 は Ruby をテーマとした国際的なカンファレンスで、世界中から様々な Ruby エンジニアが集う大規模なイベントです。
エンジニアとエンジニア採用担当の計 12 名が現地参加し、たくさんの方々と交流させて頂きました。また、スポンサー LT もさせていただきました。 今回は会場・ブース・発表の様子と、スポンサー LT の内容をご紹介します。
会場の様子
会場となった那覇文化芸術劇場なはーとは、国際通りからほど近い場所でありながら閑静な市街地にありました。
沖縄らしさを感じさせる建築デザイン
建物内は 4 階まで吹き抜けとなっていて開放感が溢れている会場でしたが、セッション間はこのように各社のブースを訪問する人々でいっぱいになり、RubyKaigi の盛況ぶりを感じることができました。
なんと今年の来場者数は約 1400 人だったそうです！
RubyKaigi 2024 の公式配布グッズは、例年とは異なり T シャツではなくかりゆしとビーチサンダルでした！運営の粋な計らいのおかげで、会期中会場がカラフルでしたね。
2 日目から始まったスタンプラリーでは来場者のブース訪問がより活発になったのを感じました。ブースを巡ってスタンプを集めると限定バッジがもらえました。
バッジ交換時にスタッフさんが全力で拍手をしてくださるのでとても幸せな気持ちになりました！
弊社ブースの様子
メドレーブースではうちわやビーチサンダルなどの沖縄らしいものをはじめ、医療事業を手がける企業のアピールとして絆創膏をノベルティとしてご用意しました。
靴擦れしてしまった方に絆創膏をお渡ししたらとても喜んでいただきました
アンケートパネルを用いて参加者の方が抱えている医療体験のお悩みを伺いました。
伺ったお悩みからわかる課題に対してメドレーがプロダクトを通じてどのように向き合い・解決しているのかをご紹介しました。
特に回答が多かったのが 「待ち時間が」長い という課題でした。
メドレーの提供するオンライン診療・服薬指導アプリ「CLINICS」では病院や調剤薬局の予約、事前の問診票入力などが可能です。オンラインによる診療・服薬指導（薬剤師によるお薬の説明）を予約した場合は待ち時間だけではなく移動時間も削減されることや、直近では Uber Eats との連携で服薬指導後30分程度で自宅までお薬を届けてもらうことも可能になったことをご説明すると、「ここまで便利になっていることは知らなかった！」と驚きのお声を多数いただきました。
会場の那覇付近でもこれだけの医療機関が見つかりました
また、直接的ではありませんが、待ち時間の長さには人員不足や院内オペレーション、利用システムも影響していることがあります。それらをジョブメドレーや医療機関向けのシステム（CLINICS、MALL、Pharms、Dentis）を通じてサポートしていること、一つの課題に対して様々なアプローチをとっていることなどをお話ししました。
ツアー風 T シャツには今年メドレーがスポンサードしたイベントの一覧が掲載されています
メドレーブースにお越しいただいた皆様、ありがとうございました！
参加したメドレーメンバー全員で
発表の様子
3 日間にわたってさまざまなセッションがありましたが、私が気になった以下のセッションについて少しご紹介します。
- Keynote
- DAY1 rubykaigiB 「Long journey of Ruby standard library」
- DAY2 rubykaigiB 「Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜」
- Matz Keynote
Keynote
今年の Keynote は tomoya ishida さんによる「Writing Weird Code」という発表でした。 Quine というコードと実行結果が同じ内容になるプログラムに関する発表で、Rubyの表現力と楽しさを紹介するものでした。 中でも発表中に行われた一人 TRICK(Transcendental Ruby Imbroglio Contest for RubyKaigi)では、Most 〇〇 と名付けられたグラフィカルなコードが紹介され、会場は大盛りあがりでした！ 紹介されていたものは GitHub にてソースコードが公開されています。
引用元:drive.google.com
DAY1 rubykaigiB 「Long journey of Ruby standard library」
Hiroshi SHIBATA さんによる、Ruby の標準ライブラリとは何なのかと、その歴史についての発表でした。
引用元:speakerdeck.com
組み込みクラスと標準ライブラリの違い
組み込みクラスとは require しなくても使えるもので、標準ライブラリとは require しないと使えないものです。標準ライブラリの中には Ruby だけで書かれたものと C 拡張で書かれたものがあります。
歴史と傾向
Ruby の標準ライブラリの数は Ruby1.8 から減少傾向にあります。1.6 から 1.8 では数が増えたようですが、これはインターネットが常時接続ではなかったため、gem install でインストールするより、Ruby をインストールしただけでたくさんの機能が使えたほうが良いのではという背景のもとに増えたとのことです。
default gems と bundled gems という概念の導入
default gems にコミットされたものは自動で Ruby 本体にもコミットされ、bundled gems にコミットされたものは Ruby 本体にコミットされないようになったそうです。 default gems や bundled gemsに関する活動をする理由は、セキュリティ対応と Ruby の持続可能性を高めるためとのことでした。 セキュリティ対応については、サプライチェーンアタックを防ぐために gem 同士の依存関係を少なくするようにしているそうです。これにより脆弱性対応時に単体のライブラリをアップデートするだけで済むようになり、結果として工数を削減することができるようになったのは開発者として大変ありがたいことだと思いました。 Ruby 自体の持続可能性については、Ruby にコミットしたい人に適切に権限を付与できるようにし、ライブラリ単体でも開発できる状態を目指すということだそうで、Ruby のこれからを支える人々の動きを促進する素晴らしいものだと感じました。
影響
default gems が bundled gems になる影響として、bundler の下で使う際に Gemfile に書かないと使えなくなってしまうことが紹介されました。default gems でもバージョン指定する際は Gemfile に書き込む必要があるようです。
これを解決するために、Ruby3.3 では警告機能が実装されました。require "csv"などで実行すると、Ruby3.4 では bundled gems になる旨を伝える警告が出力されるというものです。これを元に Gemfile に情報を追加すれば良いので、対応がわかりやすくなったというメリットがあります。
また、自分が使っていないライブラリの警告だとしても、他のどのライブラリから呼び出されているのかも確認できるそうです。これを確認する際に、使っていないものであれば削除して依存関係を少なくする整理にも役立つそうです。
感想
引き続き bundled gems の数を増やして default gems の数を減らすことでメンテナンス性を高める方針のようなので、適宜分類をチェックして Gemfile への追加や Gem を使っているかの整理を進めて行きたいです。
DAY2 rubykaigiB 「Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜」
Shunsuke Mori(kokuyou)さんによる、Ruby で大型言語モデル（LLM）を使用して RBS 型シグネチャを改良するツールである RBS Goose を作成されたことに関する発表でした。
引用元:slides.com
RBS とは？ & 既存の RBS 作成手法
RBSとは、Ruby の型構造を定義するためのもので、型検査による安全な開発や補完の強化など開発体験を向上させる目的で使用されます。 既存の RBS 作成手法としては以下の 3 つが紹介されていました。
- 静的構文解析: 高速であるが推測できるものが少ない。attr_accessor などはメタプログラミングで生成されるものなので静的構文解析では RBS に出力されない。ruby にそもそも型情報がないので untyped になる。
- 動的ロード: ロード時にクラス全体が読み込まれ、その結果をリフレクションで RBS に書き出すことで、メタプログラミングで生成している attr_accessor のメソッドも定義される。しかし、こちらも型情報がないので untyped になる。
- 型レベル実行: 実行時の値を渡すときに型の情報を受け渡し、これをとっておいて RBS に出力する。コードを実際に動かす必要がある。 これらの手法では untyped を手作業で直したり、足りないものを補うのが大変であり、これを解決したい動機で RBS Goose を作成されたそうです。
RBS Goose の仕組み
RBS Goose は RBS を生成する既存手法でネックになっていた untyped を手作業で直したり、足りないものを補う作業を LLM の力を借りて解決する仕組みのようでした。 RBS 生成の流れは以下のようになっています。
hoge.rbに対して静的構文解析などでhoge.rbsを作成- LLM の入力に使う prompt を組み立て
- この際に
hoge.rbとは全く違うfuga.rbとそれを静的構文解析などで作ったfuga.rbsと LLM に出力してほしいお手本のrefined_fuga.rbsの 3 つを追加で入れる - お手本を入れることで期待する答えを出しやすくする Few-shot プロンプティング という手法を採用している
- この際に
- LLM に prompt を渡す
- RBS を出力
実用レベルにするには複数ファイルを扱えるようにする必要があり、それをどうするかの実現ビジョンについても語られていました。
LLM を使った開発の Tips
開発時の Tips が共有されていたのですが、その中でも特に学びになったのはテスト時の Tips でした。 従量課金のコストがかかる & 応答時間がかかるのでテストに時間がかかってしまうことを解決するために、VCRのような Web モックを利用すると良いということ、 LLM の再現性確保のために Temperature（言語モデルの出力のランダム性を制御するパラメータのこと）の設定は 0 にすることがおすすめであるという Tips が共有されました。
感想
性能については割愛しますが、RBS Goose を用いてより良い RBS を得られると、補完の強化などで開発体験が向上することが期待できそうで、実用化が待ち遠しいです。 去年の Keynoteで ChatGPT に型を推論させてもある程度形になることが語られていましたが、今年の発表で LLM を使用して型情報の定義をサポートするツールが発表されたことで、RBS への興味関心が大きくなりました！
Matz Keynote
今年の RubyKaigi 最後のセッションは Matz が担当しました。どうしたら Ruby をもっとよくできるかについての話では、パフォーマンス改善がキーになるというお話がありました。
パフォーマンス改善のために必要な要素は多岐にわたるため、これをコミュニティ全体で力を合わせて解決していく必要がある というメッセージや、カンファレンスで人々が話をしたことがきっかけでRubyGems が生まれたことから、コミュニティの人々が一緒に取り組めばもっとRuby を良くすることができるはずである というメッセージを受け、Ruby コミュニティの一員として胸の熱くなる想いでした。
メドレーブースに遊びに来てくれた Matz と
スポンサー LT の様子
メドレーの LT 登壇は Matz の ClosingLT の直前ということもあり、会場が超満員に。登壇した VPoE の山﨑を応援しようと、サプライズで応援うちわを作っていったのですが、残念ながらあの大舞台からは見えなかったようです（笑）
うちわは社内で活用させていただきます
あそこまで大きな会場だと思ってなかった…！by 山﨑
LT で発表させていただきましたが、メドレーはコミュニティへの支援を行っています。6 月 13 日に約 1 年半ぶりの開催となる Roppongi.rb をスポンサードしており、メドレーオフィスで開催予定です。ご興味のある方はぜひご参加ください。 https://roppongirb.connpass.com/event/319768/
私も地域 Ruby コミュニティに積極的に参加しようと思いますので、Ruby コミュニティを一緒に盛り上げていきましょう！
さいごに
RubyKaigi 2024 に Ruby Sponsor として協賛した様子をお届けしました。 ブースやパーティーを通じて交流させていただいた皆様、Ruby とそのコミュニティの素晴らしさを存分に体感できるイベントを運営してくださった皆様に心より感謝いたします。
メドレーでは領域を問わず、Ruby を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 ご興味を持っていただいた方からのご連絡をお待ちしております。