この記事はコインチェック株式会社のアドベントカレンダー4日目（シリーズ1）の記事です。
はじめに
こんにちは。アプリケーション基盤グループでエンジニアをしている草間です。
2024年10月25日-26日に有明で開催された「Kaigi on Rails 2024」に、「サイロ化した金融システムを、packwerk を利用して無事故でリファクタリングした話」というタイトルで登壇させて頂きましたので、参加＆登壇レポートという形で記事を書こうと思います。
今回のプロポーザルを提出するきっかけや、私が所属するチームの紹介は別の記事で取り上げてもらっていますので、興味がある方はそちらもご覧ください。
どのセッションも素晴らしかったのですが、特に自分の業務に近く共感や学びが多かったものを中心に振り返ってご紹介します。また、弊社の牟田さんも参加レポートを上げていますので、あわせてご覧頂けると幸いです。
Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -
弊社にてペアプログラミングなどエンジニア育成にご協力いただいているigaigaさんのセッションです。
前半ではイベント型モデルやPOROなどを例にしたモデルの見つけ方、後半はモデル分割のタイミングと、フォームオブジェクトの紹介をされていました。
コインチェックのバックエンドでもフォームオブジェクトは導入されていますが、モデルを分割するタイミングとして、「モデルのバリデーションはDB用とフォーム用を共有している」「モデル分割のタイミングは1つのバリデーションを条件分岐したくなったとき」としっかり言語化されていて、大きな納得感を得ることができました。
igaigaさんには私自身の発表スライドについても事前に色々とアドバイスを頂き、大変助かりました。ありがとうございました！
現実のRuby/Railsアップグレード
Ruby/Railsアップグレードの実例を基に、実際に発生した課題とその解決方法や、得られたノウハウを豊富に紹介されていました。導入部分にあった「テストカバレッジ0%」の見出しが印象的に頭に残っています。
「保守されていないgem」問題は、アップグレード時に直面すると大きなコストにもなり得るため、gem選定の重要性を再認識させられましたし、選定のポイントも参考になりました。
発表ではアップグレードに対するエンジニアの説明責任にも言及されていて、アップグレードの重要性が広く認知されていない文化だと確かにもの凄く大変だろうな、と感じました。
約9000個の自動テストの時間を50分から10分に短縮、偽陽性率(Flakyテスト)を1%以下に抑えるまでの道のり
50分以上かかっていたCIのテスト時間の短縮や、Flakyテストへの対策手法を多く紹介されていました。自分の組織が向き合うテーマでもあるので共感する点も多く、楽しく聞かせて頂きました。
弊社でも、下記のTipsは取り入れる検討の余地があると感じ、業務に直結するありがたい内容でした。
- test-profのbefore_all/let_it_beを使用してデータ作成を省略
- parallel_testsの並列実行を活かすためにファイル分割
- parallel_testsには、前回のテスト実行時間から均一にならす機能も存在しますが、確かに極端にテスト時間が長いファイルがあるとばらつきが出てしまうので、ファイル分割というアプローチは効果的だなと感じました。
結果としてテスト数は増えているにも関わらず、テスト時間は10分に短縮、Flakyは15％から1％へ低減という素晴らしい実績に感銘を受けました。
Data Migration on Rails
Railsにおけるデータのマイグレーションのレールがまだ確立されていない点に着目し、現在の状況を広くまとめて話されていました。
大きな樹形図のような形で1ページに方式をまとめられていたスライドがとても印象的でした。
弊社でも、migrationとは別にスクリプトを記述して実行するケースが多いですが、migrate用のgem（とその数の多さ）に対する知見が無く、興味深かったです。
発表では、上記を含む5パターンの方式について、メリットデメリットと共に網羅的に紹介されていました。直近で明確に運用を見直す機会はありませんが、今後の運用方式の一案として解像度が高まり、勉強になりました。
そして自分の発表
Kaigi on Railsは私自身、初参加、初登壇、かつ発表がDay2の最後から2番目という状況で、率直に相当緊張していました。
ですが、現地やオンラインで見守ってくれた会社の皆さんや、スポンサーブースで応援頂いた言葉に勇気付けられ、発表自体は無事にやり遂げることができました！今回アフターイベントは残念ながら行けなかったのですが、Xなどでも様々な感想を頂けて、スライドの内容や構成などの学びもあり、大変貴重な経験にさせてもらいました。
改めまして、聞いて頂いた皆さん、スタッフの皆さん、本当にありがとうございました！
WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと
Day2最後の基調講演です。
講演後半のお話で、島田さんは「元に戻す」のではなく、「変わった後の全体と再度調和させる」概念としての修復を紹介されていました。そしてそのお手本がRailsだという話の流れに大きな納得感がありました。
やはりシステムを取り巻く環境は事業の成長などの要因でどんどん変化していくので、修復し続けていくことが大事であること、また、修復が必要な箇所を感じとるために、複雑度などの認知負荷を下げることの重要性については、今回私が発表した内容の中身でもある、認可ロジックの集約、リファクタリングに通ずる要素を感じることができ、自分としてもとてもありがたいお話でした。
そして最後のメッセージ、DON'T FORGET TO HAVE FUN!
楽しむことを忘れない、ことがモチベーションや生産性に繋がるのは本当にその通りだと思いますし、楽しむためには、業務や日常でコードを書くだけでなく、Kaigi on Railsのようなイベントに参加することも1つの大きな手段だなと感じられたメッセージでした。
おわりに
ワクワクとドキドキが入り乱れていたKaigi on Railsでしたが、基調講演や発表のライブ感、スポンサーブース、懇親会と、オフラインイベントの楽しさを一杯感じ取ることができた2日間でした。
社内のメンバーと参加できる機会があるというのも、ありがたい環境だなと感じましたし、来年のKaigi on Railsも是非現地で参加したいと思っています！
