こんにちは、株式会社ACES でテックリードをしている奥田(@masaya_okuda)です。
リポジトリで利用するライブラリを適宜バージョンアップするのは、現場によっては当たり前かもしれません。しかし、プロダクトを前に進めるため日々機能開発を行うスタートアップにおいて、継続してバージョンアップを実施するのは容易ではありません。
本記事では、入社後半年で全てのライブラリを最新にバージョンアップし、2024年1月からこの状態を保ち続けている取り組みについてご紹介します！
- なぜライブラリのバージョンアップを継続的に行うのか？
- 入社時は責任者が曖昧な状態
- 入社後半年で全てのライブラリを最新に
- CIで守りながら毎日自動でバージョンアップ
- ライブラリバージョン以外もメンテナンスする
- 技術ロードマップの策定
- Takepepeさんを技術顧問に迎え、Next.js App Routerへ移行！
- おわりに
なぜライブラリのバージョンアップを継続的に行うのか？
ライブラリのバージョンアップを継続的に行うことで、以下のような状況が起こりにくくなると考えています。
- EOLの前後で、慌てて開発ロードマップの変更を余儀なくされる
- ビッグバンバージョンアップによるインシデントリスク
- 機能開発を止める、もしくはバージョンアップ担当者とのコンフリクトに常に気を使う
- メンテナンスされてないリポジトリだから手を抜いてもいいという割れ窓の力学
グラフはフロントエンドのリポジトリにおいて、dependabotが作成したバージョンアップPR数です。
近年フロントエンドの変化は大分安定したように思います。ですが気を抜くとすぐにバージョンが離れてしまうため、コツコツと対応していくことが重要です。ACES Meetのフロントエンドリポジトリでは日次でバージョンアップを行っています。
入社時は責任者が曖昧な状態
私が入社した当時、正社員のフロントエンドエンジニアは他におらず、業務委託の方が片手間でメンテナンスを行っている状況でした。TypeScriptをはじめとする主要なライブラリもメジャーバージョンから大きく離れており、セキュリティアップデートも滞っている状態でした。
これまで携わったプロジェクトにおいても、メジャーバージョンレベルのアップグレードが後回しにされる傾向があり、それが技術的負債の蓄積につながる場面を目にしてきました。技術的負債が蓄積されると、最終的には大規模なリファクタリングやシステムのリプレイスが必要となり、事業運営にまで影響を及ぼす可能性があります。
ちょうどNext.jsのメジャーバージョンアップが行われた直後でもあったため、「これ以上バージョンの遅れを放置することは避けたい」という思いから、まずは私がリポジトリオーナーとしてメンテナンスを主導することを決めました。
入社後半年で全てのライブラリを最新に
特に主要ライブラリのメジャーバージョンが2つ以上離れた場合のビッグバンバージョンアップを懸念し、下記の順で対応しました。
- セキュリティアップデートで対応可能なものを全てバージョンアップする
- Next.jsのメジャーバージョンなど、離れすぎると破壊的変更の対応が困難になるものを優先的にあげる
- dependabotを導入し自動でバージョンアップPRを作成
- その他のライブラリも順次最新化
特に2は破壊的変更に対する広範囲の修正が必要、関連ライブラリも上げないと壊れるなど、泣きそうになりながら気合いで乗り切ったのは良い思い出です（笑）
CIで守りながら毎日自動でバージョンアップ
dependabotがライブラリのバージョンアップ時に自動でPRを作成してくれるものの、都度確認してマージするコストが高い状況でした。そこでGitHub Actionsを整備し、パッチバージョンの場合は自動マージされるようにしてから格段に運用しやすくなりました！
バージョンアップPRのマージを安心して行える背景には以下の防波堤があるためです。
余談ですがリグレッションテストの自動化も進めており、今後はより高頻度なリリースを目指しています！
ライブラリバージョン以外もメンテナンスする
バージョンアップ以外にも適宜メンテナンスしています。その際にもほとんどのライブラリが最新のため、「TypeScriptやReactのバージョンがネックで新しい技術を導入できない」などはありません。
- Recoil → Jotai
- ESLint & Prettier → Biome
- Popper → Floating UI
- Node.jsのLTSに追従
Recoilは以前からずっと開発停止していましたが2025年始に遂にアーカイブとなりました。ACES Meetでは半年以上前からJotaiに移行しており緊急対応を回避できました。
破壊的変更を伴うメジャーバージョンアップや別ライブラリへのリプレイスには、一定の工数が必要です。これまでは以下のような方法で対応してきました。
一方で、Next.jsのApp Routerへの移行のように1ヶ月単位で工数が必要な大玉はなかなか着手できない状況でした。残業での対応は長続きせず品質の担保も難しいため、今期からは組織目標に組み込みきちんとリソース確保できるようにしました。
技術ロードマップの策定
テックリードの福澤と共に、DORA Core Modelに基づいて技術戦略を整理しロードマップを策定しました。ロードマップには技術負債解消の項目もありますが、あくまでも事業成長をゴールとし、商業的な成功やチームの満足度など、組織が目指す最終的な結果である成果（Outcomes）から逆算して注力すべき領域を定めました。
詳しくは福澤のテックブログでご紹介していますので、こちらもぜひご覧ください！
策定の背景には、ACES Meetの開発チームが機能開発において高い生産性を維持し、経営層やBizチームからの信頼を積み重ねてきたことも大きいです。
ACESはBizもエンジニアも「プロダクトをより安定させ、より遠くへ進めるためには？」と、同じ方向を向いて議論できる土壌があります。
また、経営層との合意ももちろん大切ですが、1エンジニアとして現代の開発プロセスにマッチした新しい技術や方法を通して、メンバーが開発を楽しめるようにしていきたいとも考えています！
Takepepeさんを技術顧問に迎え、Next.js App Routerへ移行！
フロントエンド領域におけるロードマップの第一弾として、Next.js v15へのメジャーバージョンアップとApp Routerへの移行を2025年1月に完了しました！工数の確保に加え、『実践 Next.js ― App Routerで進化するWebアプリ開発』の著者であるTakepepeさんを技術顧問に迎え、移行プロセスや移行後の設計について議論を重ねました。
約70画面の移行を、機能開発を止めることなくダウンタイム0で達成でき胸を撫で下ろしています。移行後の新しいディレクトリ設計に早くも「より開発しやすくなった」「どこに何を作るか迷わなくなった」という声も上がっており、生産性の改善に繋がりそうです。
App Router移行とその後の活用に関しては、また個別記事でご紹介できればと思います！
おわりに
今回はライブラリのバージョンアップの取り組みを中心に、ACES Meet開発チームの技術負債への向き合い方についてご紹介しました。フロントエンド領域に限らず以下の観点を大事にしています。
- ライブラリのバージョンアップやメンテナンスはコツコツ継続的に実施する
- 目的や重要性を含めてマネジメント・経営と合意し、ロードマップとして可視化する
今後も機能拡張と安定した技術基盤構築の両方を妥協することなく推進していきます！
最後に、私たちと一緒に事業と技術の両面で力を発揮いただける方を募集しています！ACESに少しでも興味をお持ちいただけましたら、ぜひカジュアル面談でお話ししましょう！
ACESの採用情報はこちら↓
