古いjQuery画面をReactへ段階移行する進め方
「この画面、jQueryのイベントがどこで発火しているか誰も追えない」「1つセレクタを直したら別のボタンが反応しなくなった」——長年運用されてきたjQueryの画面には、こうした声がつきものです。DOMを直接いじりまわすコードは動いている限り触りたくないブラックボックスになりがちで、機能追加のたびに関係ない箇所が壊れる、対応できるエンジニアが社内に一人もいない、といった状態に陥っている会社は少なくありません。
この記事では、そうした古いjQuery画面をReactへ移行する際に、全面書き直しの罠を避けて安全に進める段階移行の考え方を、発注者向けに整理します。
なぜ「全面書き直し」が罠なのか
jQueryからReactへの移行相談で最も多い提案が「いっそ全部作り直したほうが早いのでは」というものです。気持ちは分かりますが、私たちはこれを基本的におすすめしません。理由は3つあります。
- 仕様が文書化されていないことが多い: jQueryの画面は「動いている挙動そのものが仕様」になっているケースが大半です。書き直しの過程でこの暗黙の仕様を見落とすと、リリース後に「前はできたのにできなくなった」というクレームが噴出します
- 開発期間中、機能追加がほぼ止まる: 全面書き直しは数ヶ月〜1年単位のプロジェクトになりがちで、その間ビジネス側の要望に応えられません
- 切り替えのタイミングがリスクの塊になる: 新実装への一斉切り替えは「本番で初めて気づく不具合」が起きやすく、切り戻しも難しい一発勝負になります
古いjQuery画面が触りづらいのは事実ですが、だからといって作り直しがリスクを減らすとは限りません。むしろ動いているものを動かしたまま、少しずつ置き換えるほうが、ビジネスへの影響を抑えながら確実に前進できます。
段階移行の現実解: 画面・機能単位で少しずつReact化する
私たちが基本方針とするのは、jQueryとReactを一定期間共存させながら、影響範囲の小さい単位から順にReact化していくやり方です。
1. 移行単位を「画面」より小さく切る
いきなりページ全体をReactに置き換えるのではなく、フォームの1セクション、モーダル、一覧のフィルタ機能といった独立して動くパーツ単位で移行します。この粒度であれば、1つの移行が失敗しても影響範囲が限定され、切り戻しも容易です。
2. jQueryとReactの共存期間を前提に設計する
移行期間中は、同じページの中にjQueryが操作するDOMとReactがマウントする領域が混在します。これは過渡的な「汚さ」ではなく、段階移行では避けられない正常な状態です。重要なのは、両者が同じDOM要素やグローバル変数を奪い合わないよう境界を明確に引くことです。Reactでマウントした領域にはjQueryが手を出さない、逆にjQuery管理の領域にReactが干渉しない、というルールを最初に決めておきます。
3. 既存の動作を壊さないための安全網を先に敷く
jQuery側にテストがないことがほとんどなので、移行対象の画面・機能について、まず現状の挙動を確認する最小限のE2Eテストを用意します。「移行前後で挙動が変わっていないこと」を機械的に確認できる状態を作ってから着手することで、「動いているように見えるが実は壊れている」を防ぎます。
4. データの受け渡し方法を統一する
jQuery側とReact側でstateやAPIレスポンスの持ち方がバラバラだと、共存期間中の不整合の温床になります。APIから取得したデータの正規化方法、フォームの値の同期方法など、最低限のルールを最初に決めておくと、後続の移行が楽になります。
移行の優先順位のつけ方
すべての画面を同じ熱量で移行する必要はありません。私たちは次の観点で優先順位をつけます。
- 変更頻度が高く、かつ壊れやすい画面から着手する: 機能追加のたびに事故が起きている画面は、React化によって型やコンポーネント分割の恩恵を最も早く受けられます
- jQueryのコードが読めるエンジニアが少ない箇所を優先する: 属人化が進んでいる箇所ほど、後回しにするリスクが大きくなります
- ビジネスインパクトの大きい画面は慎重に進める: 申し込みフォームや決済画面のように失敗が許されない箇所は、テストを厚めに敷いてから着手するか、あえて後回しにして先に手順を確立してから臨みます
- 単純な表示のみの画面は最後でよい: イベントの絡みが少なく、そのままでも大きな問題を起こしていない箇所に無理にリソースを割く必要はありません
「触りづらい」という感覚だけで優先順位を決めると、影響範囲の見積もりを誤ります。実際の変更頻度・バグ発生箇所・属人化の度合いを基準に据えることが重要です。
外注時に確認すべきこと
jQueryからReactへの移行を外部チームに依頼する際は、以下を確認してください。
- 全面書き直しを最初の提案にしていないか: 段階移行を前提とした進め方を具体的に説明できるかどうかは、パートナー選びの重要な判断材料です
- 共存期間の設計方針を持っているか: jQueryとReactの境界をどう引くか、事前に方針を説明できるか
- 移行前にテストを足す計画があるか: 「今の挙動」を壊さない前提で進めるための安全網をどう用意するか
- 優先順位の根拠を説明できるか: なぜその画面・機能から着手するのかを、変更頻度やリスクを根拠に説明できるか
こうした段階移行の考え方は、Reactで書かれたプロダクト自体が肥大化・属人化しているケースのリファクタリングとも共通する部分がありますが、対象が異なります。すでにReactで書かれたコードの整理はReactリファクタリングを外注すべき症状と進め方で扱っており、こちらの記事は「jQueryという別の技術スタックからの移行」に焦点を当てています。また、そもそも既存プロダクトのどこから手をつけるべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。
torcheees では React を中心に、jQueryなど古い技術スタックからの段階移行を含む既存プロダクトの改善・モダナイゼーションを手がけています。詳しくはモダナイゼーションのサービスページをご覧ください。
まとめ
- jQueryからReactへの移行は全面書き直しではなく、画面・機能単位で少しずつ置き換える段階移行が現実的で、共存期間を正常な状態として設計することが重要
- 移行前に既存の挙動を確認する最小限のテストを敷き、変更頻度・属人化の度合い・ビジネスインパクトを基準に優先順位をつけることで、リスクを抑えながら進められる
- 外注時は「段階移行を前提にしているか」「共存期間の設計方針」「テストの計画」「優先順位の根拠」を確認することが失敗しない選択につながる
「jQueryの画面が触りづらくなってきたが、どこから手をつければいいか分からない」という段階でも構いません。torcheees では既存プロダクト改善向けに、1〜4週間の「開発診断」で現状のコードを確認し優先順位をご提示するほか、継続的な改善支援も行っています。お問い合わせフォームからお気軽にご相談ください。