こちらの記事は カケハシ Part1 Advent Calendar 2023 の8日目の記事になります。
こんにちは！ カケハシでMusubi Insightの開発を行っている高田です。
Musubi Insightは、立ち上げ当初よりフロントエンドフレームワークにAngularを採用していましたが、この度、React（Next.js）にリプレイスしました。
今回は振り返りも兼ねてその経緯やリプレイスまでの流れ、リプレイスを通して得られたメリットなどをまとめていきます。
※技術的な内容はまた別記事にまとめたいと思います。
なぜリプレイスしたのか？
Musubi Insightはカケハシの中でも比較的古いプロダクトで、当時のメンバーの技術スタックやカケハシのメインプロダクトであるMusubiがAngularを採用していたこともあり、Musubi InsightでもAngularが採用されました。
しかし、Musubi Insightをリリースして今年で4年が経過し当時とは状況が変わってきました。
社内では新規プロダクトのフロントエンドフレームワークとしてReactの採用が増え、業界全体でもAngularのシェアは年々減少傾向にあります。
こちらはAngular、React、VueのGithub star数の推移ですが、ReactがAngularに二倍以上の差をつけてまさに一強状態となっています。
また、State of JavaScript 2022の結果を見ても、Reactは利用者が伸びている一方、Anguluarは徐々に利用者が減ってきています。
このような状況の変化をふまえ、今後も中長期的にプロダクトを成長させるためには、今時点でAngularからReactへのリプレイスが必要だと判断しました。
さらにチームのフロントエンドスキルが一部のメンバーに偏ってしまっていたので、全員でリプレイスプロジェクトに取り組むことでチーム全体としてのフロントエンドスキル向上も図りたいという思いもありました。
リプレイス完了までの手順
リプレイスを行うにあたり、次のような手順で進めました。
- チームでの合意を取る
- スケジュールとリリース方式の戦略を決める
- 技術選定
- 実装と検証
- リリース
チームでの合意を取る
まず、リプレイスを行うにあたり、チームでの合意を取りました。
実際に開発を行うエンジニアはもちろんですが、大規模なリプレイスになるため、プロダクトマネージャやデザイナーなど、関係者全員に合意を取りました。
Musubi Insightチームではエンジニア以外でも技術負債解消に対する理解があり、リプレイスに対しても合意を得やすかったです。
スケジュールとリリース方式の戦略を決める
続いて、おおまかなスケジュールとリリース方式の戦略を決めました。
スケジュールは既存システムのコンポーネント数やページ数を元に大まかなStory Pointを見積もり、Musubi Insightチームのベロシティから計算して5ヶ月ほどかかる見込みとなりました。
リリース方式としては、既存のAngularで動作しているシステムの一部をReactで動作するようにし、徐々にリプレイスを進めていくか、全てのページを一気にリプレイスするかで検討しました。
それぞれのメリットデメリットは以下のように整理した上で、今年の後半には開発しなければならない案件が積まれていることもあり、今回は開発コストを抑えた短期集中でのリプレイスを優先し、全てのページを一気に置き換える方式を採用しました。
| メリット | デメリット | |
|---|---|---|
| 部分置き換え方式 | ・リプレイスに対するリスクを下げられる | ・AngularとReactの二重管理 ・複雑性が増し開発コストが増加する |
| 一括置き換え方式 | ・短期集中で開発コストを抑えられる | ・リプレイス失敗時のリスクが大きい |
技術選定
スケジュール感やリリース方式が決まったので、次に具体的に技術選定を行いました。 技術選定の基準としては、なるべくデファクトスタンダードなものを採用し、中長期的に運用が可能かつエンジニア採用にも不利にならないもの、としています。
また技術選定にはチーム内だけではなく、社内の知見を持ったメンバーにもレビューしてもらい、最終的には以下のような技術スタックを採用しました。
- 言語：TypeScript
- フレームワーク：React（Next.js）
- CSS：CSS Modules（Sass）
- 状態管理：Zustand
- テスト：Vitest、React Testing Library
- コンポーネントライブラリ：Ant Design
- その他：Storybook、ESLint、Prettier、StyleLintなど
実装と検証
技術選定が完了したので、まずはプロトタイプ的な実装を行いました。
ここではいきなりチーム全員で開発を進めるのではなく、自分を含めた2人で実装を行い、実装の方針や技術選定の妥当性を検証しました。
また、共通コンポーネントの作成や、雛形の作成など後から参加するメンバーの生産性を上げるための準備も行っています。
プロトタイプ的な実装が完了したところで、いよいよ新規開発をストップしメンバー全員で本格的な実装を行いました。
このフェーズではAngularのコードをそのままReactに移植するのではなく、負債の解消やリプレイス後の開発スピードを上げるためアーキテクチャーの再設計なども合わせて行っています。
開発が終盤に差し掛かる頃には、開発チームだけではなくビジネスサイドのメンバーも巻き込んでバグ出しや検証会を実施することで、エンジニアだけでは気づくことができなかった多くのバグを発見することができました。
リリース
リリースを目前にした最終段階では、どのバグを優先して修正するか、どこまで修正できればリリースできるかなどをプロダクトマネージャーと密にコミュニケーションを取りながら最終調整を行いました。
リリース方式の戦略で全てのページを一気にリプレイスする方式を採用したことで、リリースの失敗が大規模障害に繋がってしまう恐れもあったのでリリース手順書も作成し、開発環境やステージング環境を用いてリリースのリハーサルなども念入りに実施しました。
そして最終的には当初のリリース予定日にはバグが収束しきらず、1スプリント（2週間）リリースを延期してしまいましたが、無事リリースを完了することができました。
今回のリプレイスを通して得られたもの
モダンな技術スタック
AngularからReactに変わったというところはもちろんなのですが、ビルドやテスト周りも刷新することで開発体験を大きく向上させることができました。
さらにAngular時代の負債の解消やアーキテクチャーの再設計も行ったことで、開発スピードの向上や、新規機能の追加がしやすくなったと感じています。
また、エンジニア採用に関してはこれからですが、今回の技術スタックを見て興味を持ってもらえる方が増えると嬉しいです。
チームのフロントエンド力の向上
Musubi InsightはBIツールという特性上、フロントエンドよりもデータ基盤やバックエンドが得意なエンジニアが多いのですが、今回のリプレイスではエンジニア総出でReact開発を行ったことでチームとしてのフロントエンド力の強化・冗長化に繋がったと感じています。
これまではフロントエンドの開発を行う際には、フロントエンドエンジニアが中心となって開発を行っていましたが、今回のリプレイスを通して、フロントエンドの開発に関してはチーム全員が対応できるようになりました。
まとめ
今回1つのプロダクトをAngularからReactにリプレイスするという大きなプロジェクトを完走することができました。
リプレイスを行うにあたり、開発だけではなく、チームでの合意を取ったり、スケジュールやリリース方式の戦略を決めたり、技術選定を行ったりとプロジェクトを進める上での様々な工程を経験することができました。
またリプレイスを行うことで、当初目的としていた技術スタックの刷新やチームのフロントエンド力の向上に加え、開発スピードの向上や細かな技術負債の解消なども行うことができ、今のタイミングで取り組めたことはとても良かったと感じています。
今後もプロダクトの成長のために、新機能の開発に加え、技術的な負債の解消もしっかりと行っていきたいです。
最後まで読んでいただきありがとうございました！
