こんにちは、フロントエンドエンジニアの大場です。
本記事では、2023年2月にリリースしたユーザー情報を管理するアプリケーション（以下、マイページ）とログイン機能の統合について、開発の背景および経緯を交えてご紹介します。
マイページ開発の背景
マイページ開発以前は以下のような課題がありました。
ユーザー情報の閲覧、変更機能が映像視聴アプリケーション(以下、SafieViewer)の1コンテンツとして存在していた。
ログインのセッション管理はアプリケーション間で共通であるにもかかわらず、ログイン画面が各アプリケーションに実装され、メンテナンスも個別に行われていた。
アプリケーションのラインナップが増えていく中で、各アプリケーションの相互遷移の導線が無く、利便性が低下していた。
ユーザー情報の閲覧、変更がSafieViewerの1ページとして存在していた
創業当時はSafieViewerしかアプリケーションが存在しておらず、ユーザー情報や契約情報の閲覧・変更などの処理もこのアプリケーションですべて行っていました。それから数年が経過し、事業規模の拡大に合わせて多数のアプリケーションが追加されましたが、ユーザー情報や契約情報の閲覧や変更機能は依然としてSafieViewerの1コンテンツとして存在していました。そのため、他のアプリケーションがSafieViewerに機能を依存しており、またユーザー関連の一部の機能は各アプリケーション側で独自に再実装されていました。さらに、SafieViewer側の制約が大きく、機能拡張を行うことが非常に困難な状況でした。
セッション管理はアプリケーション間で共通であるにもかかわらず、ログイン画面が各アプリケーションに存在し、個別にメンテナンスされていた
セッション(ログイン状態)はCookieで管理されているため、アプリケーション間で遷移した際に、利用条件を満たせば再ログインすることなく継続してアプリケーションを利用することができます。しかし、各アプリケーションが個別に新規開発および拡張がされた経緯があり、ログイン画面においても各アプリケーション側で個別に実装されていました。そのため、2段階認証やシングルサインオン(SSO)認証など、ログイン関連の機能が拡張されていく中で、各アプリケーションが足並みを揃えてそれぞれ開発を進め、リリースタイミングを合わせる、という開発上の手間が発生していた上に、品質維持のために行うQAテストのコストも膨大になっていました。 また、セッションはバックグラウンド(別タブなど)でログアウトされた際や再ログインされた際に適切に破棄する必要がありますが、これらの処理が各アプリケーション側に委ねられており、仕様に差異が生じていました。
アプリケーションのラインナップが増えていく中で、各アプリケーションの相互遷移ができない
企業の成長と共に、アプリケーションのラインナップも増えていきましたが、これらを相互遷移する仕組みがありませんでした。そのため、ユーザーがどのアプリケーションを利用可能か直感的に判断する術がなく、Web検索、あるいはブラウザのブックマーク機能などを活用してアプリケーションを遷移する必要がありました。
課題に対するアプローチ
これらの課題を解決するため、以下の方針でマイページの開発を進めました。
- マイページを新規開発し、ユーザー情報や契約情報の閲覧、変更機能をSafieViewerから分離し、マイページに移設する。また、各アプリケーションで個別に実装されていたログイン機能をマイページに統合し、各アプリケーションからマイページのログイン機能を統一的に利用できるようにする。
- ユーザー情報や各アプリケーションのリンクを集約したヘッダーUI(以下、共通ヘッダー)を開発し、各アプリケーションで共通利用し、マイページや各アプリケーションへの導線を提供する。
マイページの開発
新規開発したマイページには主に以下の役割があります。
利用中のアプリケーション一覧の表示
ユーザーの契約情報に基づき、利用可能なアプリケーションの一覧を表示します。これにより、ユーザーがマイページを起点として各アプリケーションに容易に遷移することができるようになります。
ユーザー情報、デバイス・契約情報、明細の閲覧
これまでSafieViewerに実装されていたユーザー情報、デバイス・契約情報、明細の閲覧などの機能をマイページ側に移設しました。これにより、映像視聴以外の機能がSafieViewerから完全に切り離され、より柔軟なレイアウトの設計が可能になりました。
ログイン機能をマイページに統合する
マイページ側でログインページを再実装し、各アプリケーションで共通利用できるようにしました。これにより、ログイン関連の開発をマイページ側に集約させ、各アプリケーションからはログイン周りの実装の排除を実現しました。 各アプリケーションはマイページへ遷移してログイン処理を行い、ログイン後に各アプリケーションへリダイレクトさせます。
共通ヘッダーの開発
マイページの開発により、ユーザー情報や契約情報の分離およびログイン機能の統合を実現しました。しかし、課題としてアプリケーション間の相互遷移ができない点、ログインセッションの管理が各アプリケーションに依存している点は解決できていません。そこで、この課題を解決すべく、マイページと合わせて開発したのが共通ヘッダーになります。 共通ヘッダーはマイページのヘッダー部分に配置されているUIコンポーネントであり、ユーザー情報の簡易表示やアプリケーション間の遷移機能を提供します。
共通ヘッダーはWeb ComponentsのCustom Elementsとしてエクスポートすることにより、各アプリケーションからはWeb標準のカスタム要素として利用することができます。Custom Elementsを採用したメリットは以下の通りです。
Web標準のカスタム要素であるため、利用するWebフレームワークに依存しない。またHTML上にカスタム要素として配置するだけで利用可能であるため、各アプリケーション側の実装がシンプルになる。
各アプリケーションと同一ドメインでスクリプトが実行されるため、ローカル開発環境などクロスドメインの環境下においても共通ヘッダー側でログインセッションを管理することができる。
マイページに実装されているリソースをそのまま流用できるため、共通ヘッダーの開発にかかるコストを最小化できる。
共通ヘッダーではユーザーが利用可能なサービス・アプリケーションが一覧として表示されます。これにより、各アプリケーションは共通ヘッダーを介して他のアプリケーションへ相互に遷移する導線を提供することができます。
ログインセッションの管理
実は共通ヘッダーはUIとして表示するだけでなく、内部でログインセッションを管理する機能も有しています。そのため、各アプリケーションは共通ヘッダーをサイト上に組み込むだけで、ログインセッションの管理を自動的に行うことができ、ログアウト時の処理を考慮する必要がなくなります。
一般的にサイト間のUIパーツ共有はiFrameが採用されることが多いですが、ログインセッションの管理にはCookieを扱うため、同一ドメインでスクリプトが実行される必要があります。その意味でも、WebComponentsを採用するメリットは大きいと言えます。
※マイページはAngular フレームワークを採用しているため、Custom ElementsのエクスポートはAngular Elementsの機能を活用しています。
終わりに
本記事ではマイページ開発の経緯と実装方針についてご紹介しました。プロダクト構成やその規模に関しては、事業規模拡大に応じてスケールしていくのが一般的です。しかし、それと同時に解決すべき課題も必ず山積します。一方で、SaaSビジネスのように絶え間なく稼働し続けることが求められ、常に進化し続けるサービスでは、課題は認識しつつも一朝一夕では解決を図ることが困難であるのも事実です。マイページの開発も足掛け丸1年ほどはかかっていますし、ログイン統合においては運用に支障が生じないよう慎重に進める必要があったため、完全な移行まで相応の期間を要しています。 しかしながら、マイページのように、大きな課題に対して1つずつ解決に向けて進めることができれば、これまで実現しなかった新機能の実装や機能拡張も可能になります。そのため、こうした負への取り組みは、企業の次の成長フェーズへステップアップさせる上で非常に重要であると言えます。本記事が多少なりとも課題解決の一助になれば幸いです。
セーフィーではエンジニアを積極的に採用しています。興味がある方は是非下記サイトを一度覗いてみてください
