Biz/BrowserからReact/TypeScriptへのポーティング対応を通して感じたこと
目次
はじめに
最近、業務で「Biz/Browser」で動いていたWebアプリケーションを、React + TypeScript にポーティング（内容を変えずにそのまま移行するという意味）するプロジェクトに参加する機会がありました。
いわゆる「レガシーからのモダン化案件」ですが、要件としては「現状の動作をできるだけ踏襲する」という方針で、あくまでUIの置き換え的な意味合いがメインのプロジェクトでした。今回はその中で感じたことや工夫した点などをまとめてみます。
現場の環境と開発フロー
バックエンドはJavaで構成されていましたが、今回私はJavaには手を出さず、フロントエンドのみの対応を担当しました。
開発時では以下のように3つのモードで分かれていました。
Mockモード：画面の動作を確認するだけのダミーモード。APIは動かず、見た目だけのチェック用。
Localモード：自分で用意したモックのJSONなどをAPIとして返し、それに対してリクエストを投げて動作確認。
開発モード：実際のJavaバックエンドと接続し、APIの実際の動作を確認（ただし異常系の確認はここではやらず、後続の総合試験で対応）。
このようにモードごとに役割が明確に分かれていたことで、段階的に実装→確認→統合という流れがスムーズに進められた印象です。
実装内容と使用技術
今回は5画面分のポーティングを担当しました。
mock自体はできあがっていたため、状態管理やイベント処理を実装することが求められました。
ただ、Biz/Browser側がJavaScriptに似たCRSという言語で記載されていたため、まずはそちらのコード解析と既存の動作の把握を進め、そのあと実装する流れで進めました。
実装では主に useState と useEffect を使って機能を実装し、useCallback などの最適化系フックは特に使用しませんでした。
フロントロジックとしてはそこまで複雑なことはなく、状態とAPIの連携をシンプルに構築していくスタイルでした。
バリデーションについては、yup や zod のようなライブラリは使わず、プロジェクト共通で用意されていたバリデーション関数群をそのまま利用しました（おそらく他の誰かが整備してくれていたもの）。
また、Biz/Browser側で既にある程度の型定義がされていたため、TypeScriptでの型定義もそれに沿って作成でき、大きな混乱なく作業を進められました。
環境面で良かったこと・印象に残っていること
開発環境についてはCopilotが導入されていたので、自動補完によりコーディングがしやすかったことが印象に残っています。
チームのバランスも良く、スケジュールの遅延も一度も発生しなかったのも良かったと感じています。メンバーの力量に合わせたタスクが分配されていたため、誰かに負担が過剰にかかることもなかった印象でした。
一方でちょっと驚いたのは、バージョン管理にSVNが使われていたことでした。
Gitに慣れていたため、SVNでのコミットはすぐにリポジトリに変更点が反映されてしまうため、慎重に行う必要がありました。
ただ、こちらも慣れてくるとそこまで気になるほどではなかったかなと感じます。
レガシー→モダンへの移行案件に感じたこと
今回のプロジェクトを通して、「React/TypeScriptでのモダン化」と言っても、やり方や目的は案件ごとに全く異なるということを実感しました。
「技術的に新しくする」ことが目的ではなく、あくまで既存の業務フローや挙動を変えずに移行することがゴールでした。
目的が明確な分、実装の方針も立てやすかったため、こちらもスケジュール通り進められた要因の一つではないかと感じました。
チーム開発の進め方や既存資産を活かした型定義の設計、モードごとの分離された確認方法のような環境については、実務だからこそ得られた知見であると感じています。
まとめ
React/TypeScriptを使った開発案件は世の中にたくさんありますが、「レガシーからの置き換え」という制約の中で、既存処理を変えずに移行するという「ゴール」と、どこを自身で判断して調整するかのバランスが非常に重要だと感じました。
今回のような「既存の動作を忠実に再現する」ことがゴールになるプロジェクトでは、技術的な工夫や最適化よりも、「安定性」や「実装の確実性」が求められると感じました。
一方で、チーム体制がしっかりしていると、開発がスムーズに進むというチームワークの重要性も改めて実感しました。
ReactやTSのスキルアップだけでなく、「現場でのモダン化移行」というリアルな場面を経験できたことは、自分にとって大きな糧になったと感じています。
