フロントエンド分割やめました
こちらは株式会社ココナラ Advent Calendar 2025 19日目の記事です。
こんにちは。ココナラ法律相談で開発を担当している高崎です。
以前、こちらの記事でRailsのモノリスから管理画面をReactへ段階的に移行する取り組みについて書きました。
結論から言うと、現在のチームフェーズと事業優先度を鑑み、この「フロントエンド分割（リプレイス）」という方針を中断し、Rails（ERB）主体の開発体制に戻す決断をしました。
今回は、なぜ一度始めたリプレイスを中断するに至ったのか。その背景にある「事業優先の力学」と「合意形成の難しさ」について、自戒を込めて振り返りたいと思います。
理想的なスタートと、現実の壁
当初の計画は、いわゆる 「ストラングラー・フィグパターン」 のようなアプローチでした。
巨大なレガシーシステム（モノリス）を一度に作り直すのではなく、「新しいシステムを少しずつ周囲に構築し、徐々に機能を移行させ、最終的に古いシステムを廃止する」 というアプローチです。
特定の機能を切り出してファーストリリースを行い、その後は各機能の改修タイミングに合わせて、順次React（SPA）へ移行していくというロードマップです。
最初のリリースは順調でした。技術的な検証も済み、あとはこのレールに乗って進むだけ、と考えていました。しかし、現実はそう単純ではありませんでした。
もっとも大きな壁となったのは、「移行コスト」と「事業スピード」のトレードオフです。
私たちの典型的な画面の場合、既存のRailsビュー（ERB）で実装された画面をReactへ移行するには、API設計・実装に2〜3日、フロントエンド実装に2〜3日を要します。一方で、既存のERBに手を入れるだけであれば1〜2日——つまり3〜4倍の差が生じます。
ここで発生したのが、以下のような状況です。
- ある機能に、ビジネス上の緊急な改修要望が入る。
- 「Reactへ移行して改修する」場合と、「既存のまま改修する」場合の見積もりを比較する。
- 当然、後者の方が圧倒的に早い。
- ビジネス判断としてスピードが優先され、既存画面が改修される。
このサイクルが繰り返された結果、減っていくはずの旧画面コードが逆にメンテナンスされ続け、延命されてしまうというパラドックスに陥りました。
そして見えてきたのは、ERBで構築された旧管理画面とReactで構築された新管理画面、その両方をメンテナンスし続ける未来です。「この機能はどちらに実装されているのか？」という混乱、権限管理を両システムで整合させる手間——中途半端な移行状態が続くほど、エンジニアの生産性は下がり続けます。
「動いているもの」をリプレイスする難しさ
もう一つの要因は、対象が 「管理画面」 であったことです。
toC向けのプロダクトであれば、UI/UXの改善が直接的なトップライン（売上やCVR）に寄与するため、リプレイスの投資対効果を説明しやすい側面があります。
しかし、管理画面は社内メンバーが使うツールです。多少使い勝手が悪くても、パフォーマンスが落ちていても、運用でカバーすれば「業務は回る」のです。つまり、改善は "Nice to have（あれば良い）" ではあっても "Must（必須）" ではない——そう判断されやすい領域なのです。
この問いに対して、緊急度の高い他の施策を押しのけてまで納得感のある答えを提示しきれなかったことが、プロジェクト停滞の根本原因だと考えています。
「生産性への投資」を合意できなかった責任
もちろん、エンジニア視点で見れば、モダンなフロントエンド環境に移行することで開発体験（DX）が向上し、長期的には開発生産性が上がると私自身は考えています。TypeScriptの導入などにより、型の恩恵も受けられるのでバグも減る可能性が高いと見込んでいました。
またSPA化することにより、UXが改善され社内オペレーションも効率的に行えるとも考えていました。
しかし、それを「なんとなく良くなる」レベルではなく、事業貢献として言語化し、ステークホルダーと握りきれていなかった。 ここに私たちの反省があります。
トップライン（売上）に直結しない領域だからこそ、「ベストではないが、我慢すれば問題ない」という現状維持バイアスは強力に働きます。それを打破するには、単なる技術的な正しさ以上の、経営的な視点での説明責任が必要だったのです。
一方で、技術的な正しさに固執することなく、結果的に事業スピードを優先し、ユーザーへの価値提供を止めなかったこと自体は、エンジニア組織として健全な判断だったとも捉えています。
さいごに
今回の「フロントエンド分割やめました」という判断は、決してReactやモダンフロントエンド技術そのものを否定するものではありません。
ただ、現在のチームのフェーズ、リソース、そして事業状況を鑑みたとき、中途半端に二重管理の状態が続くことこそが最大のリスクであると判断しました。1つの管理システムが2つのアプリケーションに分散することで、機能の所在が不明瞭になり、権限などの整合性も二重に担保する必要が生じます。この状態はエンジニアにもユーザーにも生産性の低下をもたらしていました。もし移行プロジェクトに専任のリソースを割けていれば、状況は違ったかもしれません。ただ、当時〜現在のチーム規模ではそれも難しい状況でした。
現時点でReact（SPA）へ移行済みの機能が全体の30%程度に留まっていたことも踏まえ、以下の方針で進めています。
- React（SPA）移行済みの画面：塩漬け（積極的な機能追加は行わず、最小限のメンテナンスのみ）
- 新規開発：ERBで実装
- 将来的な方針：全てERBに戻し、二重管理の状態を段階的に解消
「プロジェクト」として一度始めたことを止めるのは勇気が要りますが、サンクコストにとらわれず、チームとプロダクトにとって何が最適かを問い直すことも、エンジニアの重要な仕事であると信じています。
今後は、「Railsの生産性」と「モダンなUX」の"いいとこ取り"を目指し、Hotwireなどを活用したアプローチを模索していく予定です。ReactのようなフルSPAほどの複雑さは不要だが、従来のERBよりもリッチな体験を提供したい——Hotwireは、まさにその現実解になり得ると考えています。（これはまた別の記事にしたいと思います）
明日はtoru ishikawaさんによる記事です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion
ちょうど現在、私も似たような問題に直面しておりましたので大変参考になりました！