こんにちは、アプリケーションエンジニアの鈴木です。
先日、私が担当しているtebiki現場分析を React v18 から v19 にアップグレードしました。
この対応は半年以上前から計画されていたものの、私自身初めての経験が多く、なかなか着手できずにいました。
今回ようやくリリースまでこぎつけたので、特に大変だったポイントや、やっておいて良かったことまとめます。
「依存ライブラリの対応状況の調査」が大変だった
React 側の変更点はアップグレードガイドを読めば理解できます。
一方で「React に依存しているライブラリが React 19 をサポートしているのか」をどう調べればよいのかがわからず、ここが最初の大きな壁でした。
主要ライブラリのメジャーアップデート対応は初めてだったため、ネット検索・issue 調査・deep research など、使える手段を総動員して調べる日々。それでも不安は残りました。
どのように対応したか
最終的には npm 上で peerDependencies を確認する というシンプルな方法に落ち着きました。
GitHub には記載がなくても npm には記載されているケースが多かったため、各ライブラリの情報をスプレッドシートにまとめ、チェックリスト化。ひとつずつ確実に確認していきました。
「Chakra UI をどうするか」の判断が大変だった
現場分析では Chakra UI v2 を利用しています。ネット上では「React 19 に対応するには Chakra UI v3 へのアップデートが必要」という情報も見られ、
- 「先に Chakra v3 にバージョンをを上げないといけないのではないか」
- 「むしろ Chakra UI をやめて Radix UI + Tailwind などに移行し、Chakra UI を剥がす方がいいのでは？」
というレベルの議論にまで発展しました。
実際、Chakra v3 はコンポジションベースとなり破壊的変更も多く、簡単には移行できません。ここを判断するのにも大きく時間を使いました。
対応
結論として、v2 系のマイナーバージョンアップのみで問題なく動作しました。
依存調査に慣れておらずネットの情報を頼っていたため判断ができなかったのですが、
最終的に npm を確認したところ、v2.10.9 の peerDependencies が "react": ">=18" となっており、React 19 もサポート範囲内と判断しました。
さらに VRT (Visual Regression Testing) による UI 崩れの確認も行い、こちらも問題ないこと確認しました。
「Recharts 対応の調査」が大変だった
現場分析ではグラフ描画に Recharts を利用しています。
React 19 へのアップグレード作業中、VRTによってグラフが正しく描画されていないことが判明しました。
原因を調べる過程で、Recharts のメジャーバージョンが上がっていることにも気づき、
- 「React 19 に対応するためには、こちらもメジャーアップが必要なのか？」
という懸念が生まれ、この点を判断するための追加調査に、一定の時間を費やすことになりました。
対応
このケースもメジャーアップデートは必要ありませんでした。
Issueを確認すると「react-is を固定すれば動作する」との記載があり、実際にその対応で問題は解消されました。
ただ、記載されている内容が 自分たちのプロダクトの状況にもそのまま当てはまるのか は慎重に見極める必要があります。
そこで、なぜこの対応で解決に至るのかを改めて調査し、プロダクト側の前提条件と噛み合っているかを確認した上で採用しました。
自動テストが充実していて良かった
単体テスト (vitest x Testing Library)
今回のアップグレードでは、まず 既存の挙動が変わっていないこと を確認する必要がありました。
その点、単体テストがしっかり整備されていたおかげで、影響がある箇所はきちんと fail してくれ、安心して変更を加えることができました。
E2E テスト (Playwright)
tebiki現場分析は、現場のオペレーションに直結するプロダクトです。
サービスが止まるとお客様の業務が止まるため、記録機能・帳票生成などのコア機能に E2E を導入 しています。
これにより「最低限ここが壊れていなければ OK」という基準を持った状態でアップグレードが進められ、作業の精神的な負担が大きく軽減されました。
VRT (Storybook x Chromatic)
Recharts の描画崩れをすぐに検知できたのは、間違いなく VRT のおかげです。また Chakra UI の互換性を判断する際にも大いに役立ちました。
Testing Library では拾えない “見た目の変更” を検出してくれるため、視覚テストの価値を改めて実感しました。
おわりに
React のようにプロダクトの根幹を支えるライブラリをアップグレードした経験は、多くの学びを与えてくれました。同時に、日々積み重ねている "自動テストの追加" や "小さな品質改善" がいかに重要かを改めて実感しました。
ライブラリの更新は直接的にユーザー価値を生むわけではなく、対応には少なくない工数もかかります。
しかし、新しい機能が利用可能になったり、扱いにくかった部分が解消されたりと、長期的には開発効率とプロダクトの健全性を底上げしてくれます。
反対に、対応を先延ばしにしてしまうと、後からもっと大きな負債として跳ね返ってくることもあります。
以前取り組んだリアーキテクチャでも、まさに同じことを痛感しました。
今回のアップグレードを通じて強く感じたのは、
- 「ライブラリ更新を安全に進めるためには、日頃の自動テストの整備と、継続的なリファクタリングによる品質向上が欠かせない」
ということです。
機能開発と並行しながらも、こうした“将来のための改善”を継続していくことで、結果的にプロダクトの開発速度も品質も守られます。
これからも、こうした取り組みを丁寧に積み重ねていきたいと思います。
私たちは一緒に働く仲間を募集しています。
正直なところ、プロダクトにはまだまだ改善の余地があります。
顧客に価値を届けながら、技術的な課題にも向き合っていきたい方、ぜひお話しましょう！
▼採用HP tebiki.co.jp
▼募集中のエンジニア求人一覧 herp.careers
