こんにちは！ほみログ編集部のokamiです。
homieのプロダクトチームでは、Nuxt3のリリースやVue2のサポート終了に伴い、昨年Nuxt3への移行プロジェクトを行いました。

今回は社外向けシステムの移行作業を担当した新規チームより、執行役員VPoT・石橋弦樹と、2022年に入社した根橋京輔に当時の作業の裏側をインタビューしました！

NUXT3移行を決定した背景

ーーまずはNuxt3移行を決定した背景について聞いていきたいなと思っているのですが、どういった背景でNuxt3への移行を判断したんですか？

石橋）Nuxt3はアップデートによるパフォーマンスの向上がリリース前から話題になっていたので、Nuxt2を使っていた身としては移行したいという話はしていました。
ただ、移行となるとコストもかかるので、様子を見つつタスクを積んでいる状態でした。
ちょうどそのタイミングでVue2のサポート終了の話があり、移行をしないといけない理由ができたので、本腰を入れて移行しましょうとなったのが今回の背景です。

ーーなるほど。Nuxt自体をやめて他のフレームワークに移行するという選択肢もあったと思いますが、そこに関してはどうですか？

石橋）Nuxtを継続することを選んだ理由としては、既存のNuxt2の資産を利用して移行できるため、最小コストでパフォーマンスの向上も実現できるのではないかと考えたからです。
他のフレームワークに移行する選択肢でいうと、単純に0からアプリケーションを作成するだけでなく、技術スタックが変わることに伴うメンバーの学習コストが大きくなってしまうため、他の選択肢は取りませんでした。

ーー同じNuxtですし、互換性が保たれた状態でアップデートできるというイメージですよね？

石橋）コード規模的に社内システムよりは小さいので、これまで関わってくれたフロントエンドメンバーの開発スピードをイメージすると、移行期間は半年くらい、遅くともVue2のサポート終了(2023年12月末)までには終わるだろうという感覚でいました。

ーー確かに。個人的には当時の見積りは妥当だったかなと思います。

NUXT3移行の進め方

ーー実際、Nuxt3への移行作業はどう進めていきましたか？

石橋）当初は既存のリポジトリを利用する方法で、アップデートに伴う不具合を一つずつ解消していき、一旦動く状態まで一気に進めリリースするという流れで現場にお任せしていました。
しかし、作業を進めていく中でこのアプローチの難易度の高さを実感し、進め方の再考が必要だと判断しました。
難易度が高いと感じた主な理由は以下の通りです。
まず、アップデートには多くの破壊的な変更が含まれていました。さらに、非推奨となったライブラリの置き換えや、新しい記法への対応も同時に行おうとしていました。
これらの要因が重なり、コンパイルエラーの修正箇所を特定することが困難になり、進捗の見通しが立たなくなってしまいました。

ちょうどその頃、別チームでもNuxt3移行をしようとしており、そのチームにはフロントエンドの知見や経験値が豊富なエンジニアがいたので、ノウハウをシェアする場として、僕のチームと合同で進め方を整理しました。

進め方を整理するにあたり、他社のNuxt3移行の事例を調査したところ、

1. Nuxt2 Bridgeバージョンを経由する or 経由しないパターン
2. Nuxt2の段階でComposition APIに対応する or しないパターン
3. axiosやvuexなど非推奨の依存ライブラリを事前にアップデートする or しないパターン

など、Nuxt3への移行時に変更差分が少なくなるように各社戦略を立てて進めていることが分かりました。
他社の事例調査やキックオフミーティングを経て、最終的にはNuxt3用のリポジトリを新規で作成し、0から構築する方法で再スタートすることにしました。

ーー実際問題は分からないですが、一般的に考えたらさすがにReactへ移行するよりはNuxt3へ移行する方が早い、且つサポート終了という背景からNuxt3移行を判断したのは妥当だなと個人的には思います。

ーーHOTLEADには社内向けと社外向けの2つの画面がありますが、社外向け画面よりも機能が多い社内向け画面の移行作業は3~4ヶ月、対して社外向け画面は結果的に1年半と約5,6倍の時間がかかりましたが、両者にはどのような違いがあったのでしょうか？

石橋）進め方で明確に違いがありました。
社内向け画面はビッグバンリリースで一気に進めていきましたが、僕のチームが担当していた社外向け画面は影響範囲が社外にも及ぶため、また、それを実現するためにAmplifyからS3+CloudFrontへ、アーキテクチャの変更も必要だったため、進め方の差によって必要な作業が多かったというのが時間がかかった理由の1つです。

また、スキルセットの差もあったと感じています。
社内向け画面の担当チームにはフロントエンドの知見も経験も豊富で、それゆえに全体像を見てプロジェクトを進められる方がいました。
一方で、社外向け画面側には自分を含めてそこまでの知見はありませんでした。プロジェクト全体の進め方も自分たちで考えてもらう形でタスクをお任せしていましたが、その意図が伝わらず個々人の作業に焦点が集中してしまい、作業報告を聞いてもいつ終わるか目処が立たない状況が再び発生していました。

NUXT3移行から得た学び

ーー今回のNuxt3移行での学びや良かったことを教えてください。

石橋）根橋くんがチームに来てくれたことです。彼が来てくれて一気に作業が進みました。

ーちなみに根橋くんが来てくれたことによって何が大きく変わったんですか？

石橋）当時の最大のネックは「品質の保証・担保」でした。
自分も含めてそこに十分な時間を掛けることができず、ネックは明確ではあったものの、そこを担ってくれる人がいないという状態でした。そんな時に救世主として根橋君が来てくれました。

根橋）学びという点でいうと、チームで動けたからこそ、スムーズに終わったのかなと思ってます。
石橋さんは僕が来たから一気に進んだと言ってくれましたが、僕1人だけで進めたわけではありません。
僕はこれまでバックエンドがメインでNuxtの知識があまり無かったため、品質の担保はできるものの、修正が苦手でした。そこに新しくフロントエンドに強い業務委託の方が入ってきてくれたので、僕がQAを担当して、その方と二人三脚で進めたことで上手くいったのかなと思っています。

ーーなるほど。組み合わせで上手くいったってことですね。単に要件定義して作ることができるだけではなく、品質の保証までできる人がいないと成り立たないという、見逃されがちですが大きな気付きですね。

NUXT3移行を検討している人・何かしらの移行を検討している人たちへ

ーーでは最後に、今回の学びを踏まえて今移行を検討している人へアドバイスをください。

根橋）僕は今回の経験を通して、改めてテストは書いた方が良いと感じました。
テストは正しい挙動の証明にもなるので、自動テストや仕様書を作成するなど手法はなんでも良いのですが、正しい挙動を確認できるものがあるとゴールが明確になるので、スムーズに進められるのではないかなと思います。

ーー事前準備としてテストを書いておきましょうってことですね。

石橋）今回改めて思ったのは、元々のシステムの正しい挙動が分からなかったり、意図しない動作に依存したオペレーションが存在する場合もあったので、日頃の開発の中で正しい挙動や、意図を知る術を残しておくことはすごく重要だと思いました。
あとは正直、Nuxt3に固執せずに一番知見がある人に合わせるのも選択肢の1つかなと思います。
既存の資産があるのであればそれを利用して作った方がいいですし、無いのであればReactや他のフレームワークを検討したり、とにかくあらゆる選択肢の中からベストな方法を選ぶのが良いんじゃないでしょうか。Nuxt3こそ最高！なんてことはないです。

それと、最後までプロジェクトを遂行できる責任者を置くというのは大事だと思います。
最小労力で移行したかった背景もあり、現場がやりやすい方法で進めていました。ただ、振り返った時にそれが失敗した要因の1つでもあったので、自分の感覚として違和感を覚えたら、積極的に現場に介入して方向性の統制をした方がよかったと感じます。

ーー石橋さん、根橋さんありがとうございました！
homieでは一緒に働く仲間を募集しています。
少しでも興味をお持ちいただけましたら、是非お気軽に「話を聞きに行きたい」にお進みください♪