よくある Rails バージョンアップ

19 July, 2025

よくある Rails バージョンアップ

ここ数年、バージョンアップ担当としていくつかのプロジェクトに参画してきた。全く異なる組織の全く違う事業分野の Rails プロジェクトなのに、割と共通する状況があるので書き出す。

背景

業績が順調に伸び始めたプロダクトで、社内リソースを新規機能開発や別の新規プロダクトに割り当てたいという背景で依頼されることが多い。

大体、Rails のメジャーバージョンで 2 から 3 程度遅れている。

担当範囲

アップグレードすることは決定で、進め方や方針も含めて提案してほしい、ということが多い。ほぼ全て、自分がどこまでマネジメントするか、どれくらい実作業を担当するかも含めて提案してほしいし、必要なら開発チームも編成するので提案を、ということになる。

技術的な問題

アップグレードに必要な個々の対応は、定石を用いて進める意外にはない。ノウハウは google や生成 AI でたくさん手に入るので、ここでは省略する。

一番の問題は見積にまつわること。対応が必要な課題がいくつあるのか、早く正確に見極める方法がほとんどない。結局、次の二択を迫られる。

1. 調査フェーズを設けて実装を把握して、徹底的にコードと挙動を分析して課題を洗い出し、その情報を元に計画する

2. まずとにかく一定期間取り組んでみて、どんなバリエーションの課題が見つかるか、どんな速度で解決できたかを記録しつつ、それらが漸減する曲線を見て経験的に計画する

1 は徹底調査パターンで、2 は探索と試行パターン。

7 割くらいのプロジェクトは 2 を選択する。だいたいはコストを優先しがちなので、2 のほうが最終的に安くなる、という感覚があるため。特にスタートアップのプロジェクト規模だと、ある程度のリスクを取らざるを得ないので、なおさら 2 に傾いていく。

成功を左右する要点

2 の場合、結局このイテレーションを必死に繰り返すことになるので先が見えない。先が見えない中でとにかく疾走を続けないと前進しないので、忍耐力が必要になる。

品質の確保

品質確保の方針を決めるとき、ここにも同じようにトレードオフがある。

1. この機会に必要なテストコードのカバレッジを定めて、rspec を充実させる
2. テストコードは増やさず、E2E や手動でのテストで挙動を担保する

これについても 7 割以上のプロジェクトで 2 を選択する。ただ、最後に振り返ってみると、1 でも 2 でもトータルの時間は変わらないような印象がある。運が良ければ 2 のほうがコストが低くなるので、その可能性にかけて 2 で進めるが、最後にかなり大きな課題（特級呪物と呼んでおく）が見つかって時間がとられることが多い。

「なんだ、割とあっさり動くし、大体できているじゃないか」から、終盤に特級呪物が出てきて手こずる展開になりがち。

気をつけること

こちらからあらゆる提案をするけど、実行とその最終的な責任は委託元が負担することをよく確認しておいた方がいい。

責任分担を明確にして自分のリスクを減らすということではない。もともと委託元に丸投げの意図があるから、こちらから委託元にやってほしいことを明確に伝えないと委託元もアクションをとりにくいので、動きやすくしてあげたい。丸投げと不平を言うよりも、進んで相手を助けて動かす方が前に進みやすい。

やってはいけないこと

エージェント型 AI に任せてノールックで進めてはいけない。特級呪物が隠蔽された状態になったり、特級呪物の存在に気付きにくくなる。

最後に

たくさん失敗しました。次はうまくやりたい。