はじめに
私の所属するプロジェクトでは、複数のスクラムチームで継続的なプロダクト開発をしております。
10年以上にわたりサービス提供する中で、各種EOLに対応するため複数回の更改にチーム横断で取り組んできました。
いずれの更改においても機能開発と並行した対応を進めており、これまでクラウド移行・DB更改・認証基盤更改・APIゲートウェイ更改を完遂しました。
本記事では現在取り組んでいるフロントエンド更改の概要を紹介します。
技術要素
更改前・更改後ともにSPAです。
旧SPA：Backbone.js（Marionette.js）/ CoffeeScript / Grunt / Bower
新SPA：React / TypeScript / Vite / npm
段階移行
機能開発と並行させる必要があること、10年分積み重なった開発物のボリューム・リスクが大きいことから、段階移行を行う方針としました。
旧SPA・新SPAの両者を共存させ、段階的に旧SPAから新SPAへの更改を行います。
エンドユーザは旧SPA・新SPAを意識することなく、更改後画面であれば新SPA、更改前画面であれば旧SPAが表示されます。
開発チームは以下方針によりチーム間の干渉を避けながら機能開発・更改を行います。
- 機能開発チーム
- 新たな機能開発は新SPA上に実装
- 更改前画面の改修は旧SPA上に実装
- 更改後画面の改修は新SPA上に実装
- 更改チーム
- 機能開発チームの改修が行われていない画面を旧SPAから新SPAへ更改
画面仕様は変更しない
旧SPAのレガシーなデザインの画面仕様を更改を機に刷新する案も検討しましたが、以下を理由に画面仕様は変更しない方針としました。
- エンドユーザはシームレスに旧SPA・新SPAを利用するため、デザインは旧SPA・新SPAで統一する必要がある
- 新たなデザインへ刷新していく場合、新たなデザイン・ガイドラインを検討してPOの承認を得ていく工数が非常に大きい
- 画面仕様を踏襲することで、更改チームの作成すべき成果物が明確となる（画面仕様を変更する場合、更改チームは明確な”正解”が存在しない前提で開発を進める必要がある）
インフラ構成
1つのドメインに2つのSPAをホストする方式としました。
具体的にはCloudFrontのルーティング先として旧SPA・新SPAの両者を登録し、ベースパスに応じて旧SPA・新SPAを呼び分けます。
旧SPA・新SPAが同一のオリジンとして存在するため、CookieやLocalStorage（各種認証情報や状態）の共有も可能となります。
本方式のデメリットとして旧SPA・新SPAを跨ぐページ遷移はSPAのリロードが発生してしまう点がありますが、機能単位での更改（後述）により旧SPA・新SPA間の遷移を最小限にしております。
尚、他の選択肢としてマイクロフロントエンド等も検討しましたが、誰でも保守できる簡便性と安定した動作が期待できる本方式を採用いたしました。
旧SPA・新SPA間のページ遷移
本SPAは機能（グローバルメニューのメニュー）ごとに独立性の高いアプリケーションとなっていることから、機能単位で更改しております。
エンドユーザに対して旧SPA・新SPAを出し分けるため、旧SPA・新SPAに同一のグローバルメニューを保持した上で、各メニューのリンクを旧SPAから新SPAに差し替えることで新SPAが参照される仕組みとなっております。
尚、グローバルメニュー以外からのリンクにも対応するため、更改により利用を終えた旧SPAに対するリンクを新SPAへリダイレクトする仕組みも用意しております。
チーム体制
「複数の機能開発チーム」と「専任のフロントエンド更改チーム」
複数の機能開発チームによる機能開発と並行して、専任のフロントエンド更改チームが更改を行う体制で実施しております。
更改のメインタスクである開発・試験は更改チームで実施するものの、受入試験は機能のオーナーである機能開発チームが担当しております。
役割分担の最も大きな理由は「業務知識の十分でない更改チームによる品質担保は限界があること」ですが、リリース後の機能開発チームによる保守に向けた引き継ぎも理由の1つです。
週次定例
機能開発チームと更改チームが互いに干渉を避けながら更改を進めていくため、チーム間の認識合わせが大変重要です。
また、各チームはスクラムによるアジャイル開発を採用しているため、急なスケジュール・優先度変更が発生します。
これらを解決するため、更改チームの作業スケジュールを作成し、週次の定例において意識合わせを行っております。
定例内で各チームの変化点を共有し、必要ならその場でスケジュール・優先順位の見直しを行うことで、機能開発のアジャイルに呼応するアジャイルな更改を実現しました。
※ChatGPTで生成。
最後に
機能開発と並行したフロントエンド更改について紹介しました。
一般的には機能開発を停止して一気に更改するほうが効率的であるかと思いますが、
- 機能開発を止められない
- 段階リリースでリスクを分散したい
といった段階移行が必要な状況において、本記事のアプローチが参考になれば幸いです。