Railsバージョンアップを外注する前に見るべきこと

「今のRailsは4系/5系のまま、上げないとまずいと分かっている。でも触るのが怖い」——長く運用されているRailsプロダクトの担当者から、こういう相談をよく受けます。動いているものに手を入れて壊れたら本末転倒ですし、外注しようにも何を基準に会社を選べばいいか分かりません。この記事では、Railsバージョンアップを外注する前に発注者側が押さえておくべき論点を整理します。

古いRailsを使い続けるリスクは「地味に」効いてくる

古いバージョンを使い続けるリスクは、ある日突然サービスが止まるような派手な形では現れません。じわじわと選択肢を狭めていくのが厄介なところです。

• セキュリティパッチが提供されなくなる。Railsは概ねメジャーバージョンごとにEOL(サポート終了)が来ます。EOL後に脆弱性が見つかっても公式の修正は出ません。
• gemが新しいRailsにしか対応しなくなる。決済・認証・監視ツールなどのgemが、ある時点から「Rails 6以上」を前提にし始め、周辺ライブラリごと足止めを食らいます。
• 採用・アサインが難しくなる。今のエンジニアは最新版寄りの経験が多く、4系/5系の独特な書き方に慣れた人材を探すコストが上がります。
• インフラ側の足かせになる。古いRubyバージョンとの組み合わせが必要になり、OSやミドルウェアのアップデートまで止まります。

放置期間が長いほど「最新版に追いつくための距離」が開き、後から上げるコストが指数関数的に増えていきます。

バージョンアップの難所は「わかっていないこと」

Railsのバージョンアップ自体は公式のアップグレードガイドがあり、手順は明確です。難しいのはそこではなく、次のような不確実性です。

• gem依存の芋づる。使っているgemが新しいRailsに対応しているかを1つずつ確認する必要があります。メンテナンスが止まっているgemが1つあるだけで代替gemへの乗り換えが必要になり、見積もりが一気に膨らみます。
• 非推奨API・暗黙の挙動変更。Railsは「今は動くが非推奨」の警告を出し、次のメジャーバージョンで削除する進め方をします。警告を無視して積み上げたコードは、いざ上げる段階で一斉に壊れます。File.exists? のように警告すらなくRuby側で削除されるメソッドもあり、実際に動かして初めて気づくこともあります。
• テスト不足で「壊れても気づけない」。これが最大の難所です。テストカバレッジが低いと、バージョンアップ後に壊れている箇所があっても検知できず本番で初めて発覚します。外注先の技術力よりプロダクト側の検証体制がボトルネックになりがちです。テストがない改修全般の考え方はテストがない改修をどう進めるかで解説しています。
• 段階移行の必要性。4系から一気に8系へ、のような大ジャンプは事実上不可能です。各メジャーバージョンを1段ずつ経由しながら非推奨警告を潰していく段階移行が基本で、「一気に最新にしてほしい」という要望は現実には複数フェーズのプロジェクトになります。

外注先を選ぶときに確認すべきこと

見積もりを比較する前に、次の観点で外注先を見極めることをおすすめします。

• いきなり着手せず、調査フェーズから入るか。依存gemの棚卸し・非推奨警告の洗い出し・テストカバレッジの確認をせずに着手見積もりを出す会社は、後から追加費用が発生しやすい傾向があります。
• 既存コードを壊さない進め方を説明できるか。「今動いている機能を維持したまま」という制約を理解し、段階移行・ロールバック手順まで話せるかを確認してください。
• テストがない箇所への対応方針があるか。全部書き直すのではなく、触る範囲に絞って回帰テストを足すという現実的な進め方を提示できるかは重要な判断材料です。
• 見積もりのブレ幅を正直に説明するか。gem依存の芋づるは着手前に把握しきれないことが多く、「確定金額」を断言する会社よりも「調査後に幅を絞り込む」前提を示す会社のほうが実態に即しています。

こうした最初の見極め方は、既存プロダクト改善で外部チームが最初に見る観点でも扱っているので、あわせて参考にしてください。

費用感の考え方

Railsバージョンアップの費用は「何段階上げるか」「テストの有無」「gem依存の複雑さ」で大きく変わるため、一律の相場を示すのは実態と乖離しがちです。

• 調査(現状診断)と実装は分けて考える。まず現状のバージョン差分・gem依存・テストカバレッジを診断し、そこで初めて精度の高い実装見積もりが出せます。診断なしの一発見積もりは、着手後の追加費用リスクを発注者側が抱えることになります。
• 段階が多いほど費用は線形以上に増える。1メジャーバージョンごとに非推奨対応とテストが必要なため、複数段階を経由する場合はそれぞれで工数がかかります。
• テストがないプロダクトほど、実装より検証に時間がかかる。コードを直す作業より「本当に壊れていないか」を確認する作業のほうが時間を食うケースが少なくありません。

私たちは実際に本番稼働中のRailsプロダクトを Ruby 2.7→3.4 / Rails 5.2→8.0 まで段階的にアップグレードした経験があり、gem依存の芋づる対応やインフラ周りの落とし穴を実務で把握しています。詳細はRuby on Railsのページ、対応範囲はモダナイゼーション支援で紹介しています。

まとめ

• 古いRailsを放置するリスクは派手な障害ではなく、セキュリティパッチ停止・gem非対応・採用難という形でじわじわ選択肢を狭める
• バージョンアップの難所は手順そのものではなく、gem依存の芋づる・非推奨API・テスト不足による「壊れても気づけない」不確実性にある
• 外注先は「調査から入るか」「既存コードを壊さない進め方を説明できるか」「見積もりのブレ幅を正直に話すか」で見極める

「バージョンアップが必要なのは分かっているが、何から確認すればいいか分からない」という段階でも構いません。torcheees では既存プロダクトの診断から、継続的な改善支援まで、現状のコードを実際に読んだ上で優先順位と概算費用をご提示します。お問い合わせフォームからご相談ください。