ミイダスのフロントエンドをNext.jsに移行した背景と課題
ミイダスのフロントエンド開発では、これまでReactとReduxを中心に、プロダクトや開発組織フェーズとその変化に対応するため技術選定を進めてきました。
そして2021年からスタートしたNext.jsへの移行計画「ミイダス2.0」プロジェクトの全貌について、フロントエンド開発を担当した後藤と松村、李に話を聞きました。
移行した背景や課題、今後の展望についてご紹介します。
2021年のミイダスのフロントエンド開発環境については以下の記事をご覧ください。
https://note.com/miidas_tech/n/ndabbd910feb5#Xfspo
– 自己紹介をお願いします。
後藤：ミイダスに入社して約5年になります。フロントエンド組織のテックリードとして、フロントの開発から採用まで色々と担当しています。特にレビューや施策周りの仕様決めなどを担当しています。
李：ミイダスに入って、4年半くらいになります。フロント開発の実装もやっていますし、2.0の基盤側の実装やバグ対応、レビューの対応などを担当しています。
松村：私はミイダスに入社して2年3ヶ月くらいになりますね。入社後少し経ってから、李さんと一緒に2.0の基盤側をスタートしました。私が入る時点で設計自体は決まっていたので、実際の実装部分を担当し、どう作っていくかなどを検討しました。施策のレビューはしないですが、基盤周りの修正があるときはレビューに入ったりします。
– ミイダスのフロントエンド開発組織体制・技術・環境について
後藤：1つのプロジェクトに対して、フロントエンド、バックエンドを含め4-5名体制となっています。少し大きめのプロジェクトでも基本は4-5名体制で開発を進めていますね。プロジェクトに参画するチームとは別に、機能単位での開発チームとチケット単位で開発をするDevCenterに組織が分かれています。
李：フロント開発では主にReact.jsを使い、Reduxで開発をしています。またReduxと相性の良いImmutable.jsを使っています。
2.0の基盤にはNext.jsというフレームワークを導入しました。Next.jsをベースにReact.jsとReduxを使いミイダスならではの環境を構築しています。今までは普通にCSSを書いていましたが、2.0ではCSS Moduleを使うようになっています。
松村：開発環境でいうと、開発メンバーはフルリモートで、エディタはみんな自由に好きなものを使ってもらっています。
プロジェクトの進め方は開発プロセスはチームによってだいぶ違いますが、DevCenterでいうとその色合いは大きいかも知れません。
例えばとあるプロジェクトのフローを例に出すと、まずは大きな施策についてワイヤーフレームが降りてきます。そこからフロント開発チームとワイヤーフレームを書いた人や企画の人でプロジェクトチームが作られます。そこで実装に向けて互いに意見を出し合い、より良いものにしていきます。
DevCenterは基本、決まったものを作ることが多いのですが、チームによっては開発側からも意見を出し良い案であれば採用され実装に組み込むこともあります。
Next.jsへの移行計画「ミイダス2.0」プロジェクトの取り組み
松村：今回の移行計画では、私と李さんが基盤のコアの実装部分を担当しました。
移植を手伝ってくれるメンバーとのスケジューリングは私が主に担当し、コアなログイン周りの実装は李さんにお願いしたりと、プロジェクト管理と実際に手を動かす部分を臨機応変に2人で分担しながら進行しました。
– 移行計画の背景と課題
李：開発環境をリフレッシュして、モダンな技術が入りやすいような構成にするために2.0をスタートしました。元々はgulpやwebpackなどを使って手作業で組んでいましたが、バージョンアップがし辛いという課題があったんです。古いライブラリに依存している箇所もあり、1つでもバージョンアップすると、他のライブラリも連動してバージョンアップしなければならず、動作確認等のコストが高いという状況でした。
バージョンアップをしても問題が起きないようにするためにNext.jsへ移行を決めました。
React.js自体のバージョンアップもしやすいですし、Next.jsが活発に開発されてどんどん強い機能が入るような感じになりましたね。
松村：元々、HackというPHPの仕組みの上にReactを被せて動かしていたのですが、そこの部分がちょっとレガシーな仕組みだったんです。
それがフロントエンドだけで完結するようなNext.jsの上で改めて構築し直しましょうというのが、2.0の根幹になるのかなと思っています。
PHPのアプリケーションの上に乗っていることもあり、ビルドする時にwebpackとgulpの両方を使っている状況で。これが結構苦しかったですね。ここも2.0に向けて解決したいと思っていました。
一つのページを作るのに、PHP側のコードを触り、JSでReactを書かなければいけなく、ページ更新する際に必要な手数が多かったです。
– なぜNext.jsを決めたのか。技術選定について
松村：今後、SSRやSSGが必要となった時に、Next.jsはそのまま対応できるというのが決め手の一つでもありますね。対応したい状況になった時サクッと実装できるのが、Next.jsの良いところです。
後藤：フロントエンド開発メンバーだけで20数名いるので、技術導入におけるコストは検討の観点として大きく、ミイダスでこれまで使っていない技術、例えばVueにしますみたいな選択肢はサービスの性質に合っていてよほどのメリットが無い限りとらないと思います。そういうところである意味自然だったのかなと思っています。
以前、フロントエンド開発組織の技術の紹介記事でも紹介していますが、Next.jsの採用にあたってはパフォーマンスやSEOの観点からの選定理由も当然あったのですが、「組織編成の変化に適したコードベースにしていく」という、来たるべきアーキテクチャへの準備のような観点も大きい理由です。詳しくはそちらの記事を見ていただければと思います。
– Next.jsの移植の進め方
李：Next.jsを立ち上げて、まずは基盤の開発を進めました。問題になりそうな部分や検証が必要そうな箇所については、事前に後藤さんや眞下さんと議論をしていました。
そして基盤と最初に一番シンプルな画面を一つ移植して開発環境にあげ、問題なく動作することが確認できたら一画面移植するのに必要な作業を洗い出しました。移植するメンバーが入ったら、それに基づいて作業できるように手順書を準備をしました。
移植の主なフロー
1. 他の進行中・開始しそうな施策を確認
2. 上記の施策にあまり影響を受けなさそう、もしくは施策によって大きく作り替えが必要そうなページをピックアップ
3. ざっくり見積もり
4. 見積もりを元に移植する人員を確保できるかMTG
5. 移植にあたってのタスクを大まかにチケット化・必要に応じてより細かいタスクのチケットを作成
6. チケットベースで移植作業を進めていく
7. ある程度リリースの目安が見えてきたら、インフラチームと既存←→2.0間の転送設定などを相談、テストチームとリリースタイミングを相談
8. URLごとに2.0側のページが表示されるように転送設定を仕込んでリリース
新機能開発と移行を並行させる大変さ
– 移行に際して大変だったこと、苦労した部分
松村：今までのミイダス側と新しく作る2.0側で両方使われている機能、例えばユーザー側の場合「ドロワー」であったりとか、全画面に出てくる「ポップアップ」であるとか、そういったものはどっちにも出てくる可能性があるので、修正が入ったら両方に変更を加えなきゃいけないところが大変です。
開発側としては早々に移植を済ませてしまいたいのですが、なかなかその調整がうまくいかず。それが今の課題でもある気がします。
現状、経営陣としては新規機能開発や既存サービスのバグ解消に対応することにフォーカスされているので、移植自体の優先度をそこまで上げることができないという現状です。
松村：一番大変だったことはスケジューリングですね。同時にいろいろな機能開発が進んでいるので、いつどのタイミングでどのページを移植するのかを決める段取りがとても大変でした。
新規開発のスケジュールを見ながら、都度調整し、検討を進めるという形でプロジェクトを進めました。
李：大変なところは全部忘れましたね（笑）
でも一つ挙げるとすると、ルーター周りの実装は大変だったかなと思います。
既存のミイダスはReact ルーターというルーティング機能を使っています。例えば下の画面が描画されてても、上の親が変わらないとういう構成があって、ミイダスもその構成に基づいて実装されてたんです。
しかし当時のNext.jsのバージョンではその構成が使えなかったのです。
Next.js自体のルーティング機能があって、それを使うしかない状況でした。
React ルーターはフロントだけに提供されている機能なのですが、Nextルーターはサーバー側にもSSR機能があり、バックエンドもフロントも対応しています。
Nextルーターを導入すると、既存のルーターと共存できない状態になるので移行する際一番苦労しました。
– Next.jsに移行することで改善された部分
松村：webpackやgulpで頑張ってビルドしていた部分を全部Next.jsに丸投げして、フレームワークの提案する作り方に基本的に乗っかるようにしました。
これまで頑張ってミイダスのベストプラクティスの状態まで作った環境構築を、フレームワークのベストプラクティスに合わせていったというのが一番の大きな改善の部分だと思います。
また、依存関係のライブラリのバージョンアップがすごくしやすくなりました。今までは導入しているライブラリを触ろうとするとgulpのファイルを触らなければいけなくて。秘伝のタレ状態だったので、あまり触りたくないとみんな思っていたんです（笑）
その部分が解消されたので、誰でも手軽に上げられるようになったなっていうのは大きいですね。
李：これまでの開発では、ソースコードの再利用で他の画面のAPIを叩いたりしていたので、画面間の依存関係がとても強かったんです。ただ、今回の移植でそれらの依存関係をなるべく切り離すような実装を入れたので、前よりも依存関係が下がり、個々のページの開発がしやすくなったと思います。
今後の課題と展望
松村：現状、フロント側に型がないので、TypeScriptを導入しようとすると大変そうだなと思っていますね。またテストもないのでテストを導入しようとすると大変そうだなと思っています。
李：ミイダスの基盤が安定しているので大きい課題はないと思います。ただ、最近入ったメンバーから新しいトレンドを入れたいなどの要望があるので、そういう新しいトレンドを今度どのように取り入れていくかは課題かなと思っています。
無理やり入れることはないと思うんですけど、現状より良くなりそうな部分については取り入れていきたいなと思っています。
後藤：企業(toB)側の移植が個人的にあまり進む気がしないので、そこは課題かなと思っています。李さんが挙げてくれたルーティングにも関係しますが、ページ間の依存やページ自体の数も多いので、やるなら一気にやらないと無理な構成になっています。
とはいえ、ミイダスも昔と比較すると大きくなってきたので、過去に1年半かけてやった企業側の画面を丸置き換え（画面全部一新）プロジェクトのような形で、プロジェクトとして機会を作っていかない限りは難しいんじゃないかなって思ってますね。
李：あれはかなり大変ですね。同時にバグ対応の施策もあったので。
松村：そもそもの前提として、ミイダスのシステムの中に、ユーザー側のtoCのページと企業さん側が使うtoBのアプリケーションと、ミイダス自体が使っているAdminという領域があります。
今回のミイダス2.0のスコープの中には、Adminは実は含まれてなくて。このAdminがこの後も結構な期間、PHPの上に残るだろうっていう感じではあります。
現状、toCのユーザー側は7〜8割は移植が完了しているのですが、企業側に関してはまだ1割、2割というところなんですよね。
李：小さいところだけをまず移植を進めたので、メインはここからですね。まず基盤を作って、その機能を後に少し進めていったという状況です。
松村：そして新しい大きな施策が動いているので、移植の進行そのものも一時停止している状態で終わりはまだ見えていないですね。今後の予定が立てられない現状なんです。
引き続き、toCのユーザー側を対応しつつ、今後も少しづつ移植を進めていく予定です。
一緒に開発者体験がよくなる環境を整えていきましょう！
ミイダスでは一緒にフロントエンド開発をしてくれるメンバーを募集しています
この記事が気に入ったらサポートをしてみませんか？