🐤

Offers 技術組織の課題 a.k.a 誰か手伝ってリスト - Web フロントエンド編 | Offers Tech Blog

ahomu

2022/07/11に公開

Offers を運営している株式会社 overflow のあほむでございます。

今回は Web フロントエンドの技術課題と展望です

前回は CTO の大谷旅人からバックエンドや DevOps の領域における技術課題をご紹介しましたが、今回は Web フロントエンド編ということで私からお送りします。

Issue 1. リアーキテクチャと付随する技術スタックの変更

前提として Web フロントエンドは ユーザー体験を維持するだけでも外的環境の変化に応じた新陳代謝を特に必要とする と考える立場にあります。とはいえ、リファクタリングという規模ではなく式年遷宮（技術スタックの抜本的刷新）であることから事業とも足並みを揃えつつ進める長期課題です。

1-1. Ruby on Rails と密結合している実装の漸進的な剥離

現状の Offers は Ruby on Rails にフロントエンドの技術スタックが密結合していて、かつ jQuery 時代から Vue.js 上乗せ時代、その過渡期に至るまでいくつかの地層を成しています。^[1]次項でも触れますがインタラクティブな要件の箇所と、静的な要件の箇所が入り交じっている中で個別に最適なアーキテクチャや実装を選択できていません。

1-1-1. RoR の API Endpoint または Gateway 化

方向性としてはフロントエンド目線で見たときの Ruby on Rails の役割を API Endpoint ないし microservices の Gateway に限定させることを考えています。一方でフロントエンドの領分とも言える HTML の生成と配信など、ユーザー向けの Web アプリケーションとして機能する部分を独立させます。

1-1-2. フロントエンド環境の独立と新陳代謝の促進

ひとつのコードベースの中に含まれている複数の特性をもったアプリケーションおよびメディアそれぞれにおいて、フロントエンドの環境を独立させることで Ruby on Rails の構造や既存の技術スタックに引っ張られていた部分の制約を外せます。

技術スタックや設計の一貫性を損ねる意図はなく、新しく開発する部分が古いスタックに誘因されて制約を受けているという状況の打開と、適切な新陳代謝の促進を念頭に置いています。またフロントエンド環境単体で動作してシステム全体を立ち上げなくても開発可能（Docker レス）にすることで開発体験の向上も見込んでいます。^[2]

1-2. 特性に応じて、性能と運用の両面で優位な設計

前項で述べたフロントエンド環境の独立を前提として、ひとつのコードベースの中に含まれている複数のアプリケーションとメディアそれぞれについて求められる性能の高さと運用を見据えた実装の力加減を見定めます。

そういえば先日 TechFeed Conference 2022 で、現代の Web フロントエンドにおける設計議論のポイントを述べた資料があるのでよろしければどうぞ！

1-2-1. 堅牢に作りたいインタラクティブな Web アプリケーション

Offers に含まれるインタラクティブな Web アプリケーション部分は下記があります。

一般ユーザー（副業・転職の候補者さま）向けのログイン後画面
企業ユーザー（契約企業さま）向けのログイン後画面
社内カスタマーサクセス向けのログイン後画面

これらはユーザーの操作に応じた状態の変化により、画面の更新や通信処理が多く発生します。多少重厚でも手堅く組み上げられるコードベースとパターンの定着が必要と考えており、Next/Nuxt のような多機能なフレームワークに乗ることも考慮しやすいです。

1-2-2. 軽妙に作りたい静的な Web メディア

一方、静的な静的な Web メディア部分には下記があります。

Offers Jobs ※ログインしている候補者の応募なども少しある
Offers Magazine

現在は裏側で WordPress に投入されたデータを Ruby on Rails で処理して HTML を生成するなどしており、やや冗長な仕組みです。静的なメディアであれば静的 HTML の事前生成が選択肢にあがり、複雑なロジックが含まれないので堅牢さよりも軽妙なコードベースを選択しやすくなります。

直近だと Offers のコードベースとは異なりますが Offers デジタル人材総研では microCMS + Astro による Jamstack を実験的に採用しています。

Issue 2. 現行実装のアップデートによる持続的な開発

長期課題と称して大きな夢を語りましたが、ここからは短中期の現実と向き合う課題です。式年遷宮は漸進的かつ長期的な取り組みであることから、まずは目の前の課題をやっつける必要があります。

2-1. 各種の境界を型で保護するための TypeScript 導入

新規開発中のサービスは TypeScript が利用されていますが、Offers ではまだ途上の段階です。
バックエンドと型を共有し、境界部分を型安全かつ効率的に開発するためのも TypeScript 導入は必須であると社内で認識されていますが、多くは既存コードへの適用となるので厳格さよりも漸進性を優先した展開を想定しています。

2-2. ユニットテスト拡充やビジュアルリグレッションテスト導入

はい。やろうね。

2-3. 短中期で必要になるライブラリメンテナンスの実施

Offers の Vue.js が 2 系であるため現状のまま開発を続けるにせよアップデートが必要であったり、lodash など古のライブラリが利用されていてバンドルサイズを圧迫している部分の解決をしたかったり、webpack のビルド時間がまだまだ長かったり、大小の課題が山積しています。

2-4. クライアントサイドの性能監視と改善フローの確立

バックエンドのメトリクスは一通り監視できていますが、ブラウザ上で発生するパフォーマンスメトリクスの監視が不十分な状況です。計測するだけであれば SpeedCurve 等のサービスを導入すればよいのですが、アラートの基準や改善フローなどの運用面の取り決めが確立していない為、ただ測っているだけといった趣です。

Issue 3. 一貫性ある体験を提供する手触りの良い UI 基盤

最後はエンジニアだけでなくデザイナーを含む開発全体で進めていきたい、いわゆるデザインエンジニアリング文脈です。
私自身は LAMP エンジニア（死語）をキャリアの発端として、Web フロントエンドを専門とするに至っているためどちらかといえばシステムやアーキテクチャに重心が寄っていますが、UI 開発者としてはシステムとユーザーの境界であるデザインとその実装をかなり重要視しています。

デザインシステムに包含されるような UI に関するルールの言語化
Offers ブランドにおいて汎用的な実装のライブラリ化
- View Component ライブラリに依存しないポータビリティの獲得（できるといいなー）
DevOps/DesignOps にまたがって開発生産性を高めるプロセス

まだまだ解像度は粗いフェーズですが準備は既に始まっています。SmartHR^[3] の @masupP9 が技術顧問として参画し、他にもデザインエンジニアとして 1 名ジョインいただきました。デザイナーとも密に連携できているので、将来が楽しみなプロジェクトです。

あとがき

以上のような展望と課題を抱えているのでありました。いかんせん Ruby on Rails プロジェクトによく見られる負債返却的な側面は拭えませんが、媒体の特性や要件に応じた再設計のチャンスや識者の監督つきでデザインシステムを構築〜運用するチャンスなど、得られる経験も少なくないのではないでしょうか。

私も今は前段階として持続可能な体制づくりに時間を割いていますが、リアーキテクチャに取りかかれる頃にはハンズオンで関われるよう善処するので興味のある方はぜひ一緒に最高の Web をつくりましょう！

次回は CTO にボールを戻して SRE ＆ Security 編を公開予定です。💁