皆さんの所属するフロントエンド開発課についてご紹介をお願いします。

フロントエンド開発課は、ラクスが提供するプロダクトを横断したフロントエンド専門の開発に取り組んでいます。

チームのミッションは「フロントエンドの技術で快適なUXを提供する」、ビジョンとしては「すべてのサービスのフロントエンド開発を担うスペシャリスト集団」を掲げています。

比較的最近結成した組織ですが、複数のプロダクトから様々なフロントエンド開発の知見が得られることと、異なる経験や専門知識を持ったメンバーがいるため、お互いに協力と情報共有をしながらプロダクトの魅力を最大限に引き出す努力をしています。

それぞれの自己研鑽やチーム内の勉強会、社外への情報発信も積極的に行っていることも特色かと思います！

今回VRT（ビジュアルリグレッションテスト）の導入事例についてご紹介いただきますが、チームとしてこのような改善に取り組む目的や背景について教えていただけますか？

前提としてVRTとは、アプリケーション修正前後についてスクリーンショットを取って差分を比較し、ページや要素が期待通り表示されているかをチェックするものです。関連の深い技術としてはフロントエンドテスト自動化があります。VRTを手動で行うと膨大な工数がかかりますが、Playwrightなどのツールを用いることでこのプロセスを自動化することができます。

今回のVRT導入目的は、運用歴が比較的長く機能開発も活発に行われている「楽楽精算」、「楽楽明細」などの大型プロダクトに対し、品質を担保しながら効率的にフロントエンド開発を行うことです。特に、従来は手動や目視で行われてきたテストを自動化し、開発に伴う影響範囲の確認を効率的にすることを目指しています。

チームとしては、テストの整備はお客様に高品質なフロントエンドを提供するための先行投資として必要だと考えていました。楽楽明細はバックエンド側で大型の機能開発がありましたが、フロントエンド側の開発には余裕がありました。一方の楽楽精算についても、予定されているUIのリファクタリング前にVRTを導入したほうがデグレを検知しやすくなります。そこで両プロダクトにVRT導入を進めることにしました。

具体的にはどのように進めていったのでしょうか。

まずは楽楽明細から導入検討を始め、その知見を楽楽精算に応用する形で進めました。これは横断チームとしてのフロントエンド開発課の強みが生きたと思います。

楽楽明細のアーキテクチャは、機能ごとにいくつかのモジュールに分かれています。なかでも、新規オプション機能のフロントエンドについては、クロスブラウザテストやE2EテストでPlaywrightを部分的に使用しており、テスト効率化の効果が実証できていました。

一方で、楽楽明細の既存機能部分にはVRTを入れていなかったのですが、今年度のインボイス制度対応の開発で大掛かりな機能追加が行われることになり、これを機にPlaywrightを導入することにしました。

VRT導入決定後、見積もりを作成するためにプロトタイプを作成しました。プロトタイプ段階では対象画面を絞る形でVRTを仮作成するかたわら、アプリケーションの画面一覧を整備しました。

プロトタイプでかかった時間と画面の一覧を元に見積もりを行い、全体のスケジュールを決め、実装、レビューと進めた形です。初期実装ではダイアログのスクリーンショットを取っておらず、基本的にファーストビューのみを対象としていましたが、ヒアリングの結果、ダイアログのスクリーンショットも撮ってほしいという要望が上がったため、そちらのテストも作成しました。

その後、実際の運用を行うプロダクト担当の方々向けに、運用に必要となる各種ドキュメント（環境構築方法、テストの作り方、実行方法、注意点、etc…）を作成しました。

横断チームとして取り組んだことによって、楽楽明細での知見を楽楽精算で活かすことができました。具体的にはスクリーンショットの比較ロジックや、ユーティリティ関数の再利用を行ったこと、また、効率的なデバッグ手法の共有等です。反対に、フロントエンド開発課は横断チームのため各プロダクトを専門的に扱っておらず、個別のドメイン知識は相対的に不足する部分もあり、網羅性チェック等に苦戦しました。プロダクト開発チーム側に業務フローを深く理解しているエンジニアがいるため、協力しながら業務を進めていきました。

取り組む上で工夫、検討したこととしては画面一覧を出力出来るようにしたことです。また、モブプロで行うことで知見の浅いメンバーとのギャップを埋めることが出来ました。

最終的にはどのような結果になったのでしょうか。

楽楽明細ではVRTの導入によって、ブラウザやライブラリのバージョンアップに伴う画面のデザイン崩れ確認を自動化することが可能になりました。

楽楽精算ではこれまで導入されていなかったフロントエンドに関するテストを新たに追加することが出来ました。また、副次的効果として、大規模プロダクトである楽楽精算の画面一覧をテストから出力することが可能になり、保守性の向上に役立てることが出来るようになりました。

今後の展望について教えてください。

楽楽明細では、テスト結果のエビデンスの保管方法や共有方法に課題があるので、今後の展望としてGitLab Pagesを用いた結果確認用の静的サイトの構築を行っていきたいです。

楽楽精算では、現状、CSS一つの修正でも影響箇所の洗い出しやテストケースの作成といった手間、時間のかかる工程を踏む必要がありますが、修正した箇所以外に変更されていないことをVRTで担保出来るため、受け入れのレビューが楽になることを期待しています。

今回VRTの導入は始まったばかりですが、引き続き信頼性を高めて、自動テスト活用の幅を広げていきたいと思います。特に楽楽精算ではテストを専門とするQA課とも連携し、将来的にはプロダクト開発全体のテストコストを下げていくことも目指しています。