システム基盤部の栗原です。

この記事は「READYFOR Advent Calendar 2022」の9日目の記事です。

昨日の8日目は「チームビルディングでドラッカー風エクササイズをやってみた」でした。

READYFORでは週に一度バックエンドのメンバーが集って、持ち回りで好きなことを発表する仕組みがあります。この記事はそのために作成した資料を、社外向けにブラッシュアップしたものです。

RubyKaigi2022

別の記事でも紹介いただいたとおり、RubyKaigi2022に登壇しました。

今回は、なぜRubyKaigiに登壇するに至ったのかをお話したいと思います。

元をたどると、業務上の課題が発端となっているのです。

業務上の課題

私は過去に別のプロジェクトでRBSを導入し実用的なメリットを感じていたので、READYFORのプロダクトにも導入を試みました。

導入自体は成功しました。しかし、正直に言ってあんまり使われなかったのです。。。

原因をいくつか考えました。

時期を同じくしてRBSメンテナのぽっけ (id:Pocke)さんからインタビューミーティングの申し出がありました。

今RBSの自動生成周りを1から見直そうと思っていて色々考えているのですが、ksssさんにも課題や意見を聞きたくて一度時間をいただけないでしょうか！
来週の4,5,7日あたりだと都合がつけやすくて助かるのですがご都合いかがでしょうかー
— 🎹 (@p_ck_) April 1, 2022

そこまで深く考えていなかったので焦りました。「何も考えていません」は失礼すぎると思い、なんとか考えをひねり出すために、深く深く問題について考えてみることにしたのです。

自分の書いた導入コードを思い返すと、RBS自体をカスタマイズして使っていました。その経験から「使う人の環境によってニーズは様々」だということが分かっていました。

また、プロダクトで使用していたActiveRecordを拡張するgemに型をつけようと思うと、アプリケーション側で定義しているモデルの情報が必要だということも分かっていました。

例えば以下のようなgemのコードは、返る型はモデル次第なのでgemの型としては決めれません。

# User::ActiveRecord_Relation ?
# Like::ActiveRecord_Relation ?
# Blog::ActiveRecord_Relation ?
def self.foo(foo_id)
  where(foo_id: foo_id)
end

また、ActiveSupport::Concernのような動的なmoduleの組み込みもカバーするためには既存のツールだと難しく、型エラーを増やす原因となっていました。

そうやって問題を整理しつつ、ミーティングの日も迫っていたのでなんとか考えをひねり出しました。締切って大事ですね。

ミーティングでも「こういうのどうでしょう」と紹介し好感触をいただき、実りあるミーティングにすることができました。

その後初期アイデアをまとめたgistも残っています。(最初はRBSGという名前でした。)

二ヶ月ほど、毎日一時間夜の自由時間を使ってプロダクトを作り、その紹介としてRubyKaigiに応募したところ、採択いただくことになりました。

私はこのようにして、仕事上の課題からRubyKaigi登壇に至ることとなりました。皆様の日々の業務上のタスクにも、もしかしたらRubyKaigi登壇のアイデアとなる種が眠っているかもしれません。

次の10日目はミノ駆動さんによる「非エンジニアに技術的負債をわかりやすく説明する方法」です。楽しみですね。