ここではRails ERBで書かれたシステムのフロントエンドをReact, Vue等に書き換えるプロジェクトについて、その注意点を説明します。公開されている情報および現場で苦闘した経験を交えた話になります。
- フロントエンドのリプレイスは5年以上を要する大規模プロジェクトになることが多いです。
- 一見すると短期間で終わりそうですが、実際には滅多にそうはなりません。
- リプレイス開始から5年ほど経過しても、まだリプレイスが完了しないことが多いです。
- 成熟してある程度複雑化したプロダクトなら、１ページをReact化するのに平均で0.5 ~ 2.0人月かかると思ってください（単純に考えているよりもはるかにかかります）。200ページ分のERBがあれば、100人月(1人なら8年)かかります。
- 途中状態ではリプレイス前後のフロントエンドが共存するため、DXが悪くなります。
- 会社も無限にリソースを投入できませんので、途中で中断になっているケースを多く見かけます。
- フロントエンドのリプレイスは基本的にはユーザ価値やビジネス上の価値を生まず、DX上のメリットが主です。そのため、ビジネスに理解されにくいものになります。
ソフトウェア開発のリプレイスプロジェクトのリスクについてはFrederick P. Brooks氏が「人月の神話」(1975年)で説いています。
セカンドシステムは、人間が設計したものの中で、最も危険である。なぜなら、作り込みすぎてしまうというのが、一般的な傾向だからである。
フロントエンドのモダン化について言えば、下記のこと注意する必要があるでしょう。
- モダン化よってもたらされるビジネス上の貢献を明確にします。貢献が少ないものを作り込まないようにします。
- プロジェクト全体のコストを明確にします。進捗を正確に把握し、何年何ヶ月をかければ完了するかを意識します。
- 事前に測定できないコスト・ベネフィットについては追跡調査します。
- ユーザからのフィードバックを確認します。UI変更のフィードバックはネガティブになりやすいです。
- モダン化によってエンジニア採用に効果があったかどうかを確認します。
- DXが改善したか。開発者の声だけでなく、機能開発スピードの改善・バグの減少で具体的な測定をします。
- モダン化プロジェクト開始当初の技術が今では陳腐化していないかを確認します。
- パーツ(コンポーネント)ごとのリプレイスの方が低リスクです。
- 食べログのブログで解説されています。
- ページ単位のリプレイスはリスクは大きくなります。途中で中断した時の悪影響が大きくなるためです。
- デザインや操作性の統一感が失われます。
- 同じ機能のパーツを新バージョンと旧バージョンで共存させることになります。
- ２種類のシステムが共存するために複雑になります。
- 画面全体を支配するSPAやNext.jsなどの導入はリスクが高いため、注意が必要です。
- SPAやNext.jsは画面全体を支配するため、上記のパーツ単位でのリプレイスと相いれません。
- 認証システムが難しくなりがちです。
- モデル単位のJSON APIエンドポイントを作るのは高リスクです。
- JSON APIエンドポイントを作る工数は少なくありません。
- ERBのエンドポイントを再利用できればバックエンドの工数が大幅に減ります。認証・認可などは全くそのままで、JSONシリアライザだけ書けば良いためです。
- 技術リプレイスと同時にデザインを変更するのは高リスクです。
- デザインを変更してしまうと、途中で複数のデザインが共存することになり、ユーザにネガティブな印象を与えます。
- リプレイスが長期化したり中断したりしたする可能性を否定できなければ、同時のデザイン変更はかなりの高リスクです。