Reactリファクタリングを外注すべき症状と進め方

「このコンポーネント、誰も全体を把握していない」「1行直すたびに関係ない画面が壊れる」——Reactでプロダクトを2〜3年運用していると、こうした声を社内で聞くようになります。最初は快適だったフロントエンドが、いつの間にか触るのが怖い場所になっている状態です。

この記事では、Reactフロントのリファクタリングを外注すべきかどうかを見極める「症状」のチェックリストと、全面書き直しをせずに安全に進める手順を、発注者向けに整理します。

症状チェック: こんな状態なら黄色信号

まずは自己診断から。以下のうち3つ以上に心当たりがあれば、リファクタリングを検討すべきタイミングです。

• コンポーネントが巨大化している: 1ファイルが数百〜千行を超え、UIとロジックと通信処理が混ざっている
• state管理が混沌としている: useState があちこちに散らばり、どこで何が更新されているか追えない。Context・Redux・SWR/React Queryなどが場当たり的に混在している
• 型がない、またはanyだらけ: TypeScript導入済みでも any や as の多用でコンパイラが実質機能していない
• ビルドが遅い: ローカルの起動やホットリロードに数十秒〜分単位かかり、開発体験そのものが落ちている
• 新機能追加のたびにバグが出る: 関係なさそうな画面が壊れる、影響範囲が予測できない
• 特定の人しか触れない: 「この画面は◯◯さんじゃないと直せない」という属人化が発生している

これらは個別の不具合ではなく、設計の負債が積み重なった結果としての症状です。1つずつ対症療法で潰しても、根本原因(コンポーネント設計・state設計)が同じなら再発します。

外注を検討すべきタイミング

すべての症状が出そろってから動く必要はありません。「見積もりが開けてみないと分からない」「特定のエンジニアが抜けると詰む属人化がリスクになっている」「テストがなく手動確認に時間を取られている」——このどれかに当てはまれば早めの相談をおすすめします。放置期間が長いほど負債は複利で増えます。

進め方: 全面書き直しをしない理由

Reactリファクタリングの相談で最も多い誤解が「一度ゼロから作り直したほうが早いのでは」というものです。私たちは基本的にこれをおすすめしません。開発期間中ほぼ機能追加が止まりビジネスへの影響が大きいうえ、「今動いている挙動」を仕様として書き直しで漏らすリスクや、新実装が本当に同等以上か検証する手段(テスト)がないまま切り替えるリスクが高いためです。

私たちが基本方針とするのは、段階的リファクタリングです。プロダクトを動かしたまま、優先順位の高い箇所から順に整理していきます。

段階的リファクタリングの進め方

1. 現状把握: どのコンポーネント・画面が最も変更頻度が高く、かつ最も壊れやすいかを洗い出す。git のコミット履歴やバグ報告の集中箇所を見るだけでも優先順位が見えてくる
2. 安全網としてのテスト: リファクタリング対象の箇所から先に、最低限のE2E/統合テストを足す。「挙動が変わっていないこと」を機械的に確認できる状態を作る
3. 型を通す: any を潰しながら型を厳密化する。この過程自体が「実は想定していなかった値が渡っていた」というバグの発見につながることが多い
4. コンポーネント分割とstate整理: UIとロジックを分離し、状態管理を1箇所(または明確なルール)に整理する
5. ビルド・ツールチェーンの見直し: 必要であればビルドツールやパッケージ構成も見直し、開発体験を改善する

ポイントは、テストという安全網を先に敷いてから手を入れることです。安全網なしのリファクタリングは「動いているように見えるが実は壊れている」を検出できず、かえってリスクを増やします。

外注時に確認すべきこと

Reactリファクタリングを外部に依頼する際は、以下を必ず確認してください。

• いきなり全面書き直しを提案してこないか: 段階的な進め方を説明できるパートナーかどうかは重要な判断材料です
• テストをどう位置づけているか: リファクタリング前にテストを足す計画があるか
• 優先順位の付け方を説明できるか: 「なぜこの画面から着手するのか」を根拠込みで説明できるか
• 完了の定義が明確か: 主観ではなく、ビルド時間・型カバレッジ・バグ発生率など測れる指標で定義しているか

こうした観点はNext.jsを使ったプロダクトのリファクタリングでも共通します。フレームワーク固有の論点はNext.jsリファクタリングを外注する際の進め方で解説しています。また、そもそも既存プロダクトのどこに手を入れるべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。

torcheees では React / Next.js を中心に、既存プロダクトのフロントエンド改善・モダナイゼーションを手がけています。詳しくはモダナイゼーションのサービスページをご覧ください。

まとめ

• 「コンポーネントが巨大」「state管理が混沌」「型がない」「新機能のたびにバグが出る」「特定の人しか触れない」は、Reactフロントのリファクタリングを検討すべき典型的な症状
• 全面書き直しはビジネスを止めるリスクが高く、テストという安全網を先に敷いてから段階的に整理する進め方が現実的
• 外注時は「段階的に進める提案か」「テストをどう位置づけているか」「優先順位の根拠を説明できるか」を確認することが失敗しない選択につながる

「Reactのフロントが触りづらくなってきたが、どこから手を付ければいいか分からない」という段階でも構いません。torcheees では既存プロダクト改善向けに、1〜4週間の「開発診断」で現状のコードを確認し優先順位をご提示するほか、継続的な改善支援も行っています。お問い合わせフォームからお気軽にご相談ください。