こんにちは。アソビューでフロントエンドエンジニアをしている白井です。
アソビューでは2022年7月から、業務時間の10％ほどを使ってフロントエンドまわりの改善を行うワーキンググループを始めました。
この取り組みの立ち上がった経緯、これまで実施してきた施策、そしてエンジニア視点で見たやりがいなどを記載していきます。
立ち上がった背景と経緯
まずはじめに、改善プロジェクトが立ち上がった背景と経緯をご説明します。
普段の開発で新機能の実装や機能追加、バグ修正といった優先度の高いタスクが多くある状況下で、優先度の低いフロントエンドタスクは後回しになることが多く、気づけば大量のタスクが積まれていっていました。
- UX上の小さなペインポイント
- デザインはあるものの手をつけられていないデザイン変更系タスク
- フロントのトレンド変化によって実務上に影響があるようなコード負債
上記のようなタスクが徐々に増えてきたものの消化できておらず、またタスクが各所のバックログに分散していて優先度が曖昧になっており、 ユニットごとに所属するフロントメンバーの少なさも相まってなかなか対応できていない状況でした。
これらの改善系のタスクは専任のチームができない限り優先度が上がらない ⇨ 直近で専任のチームができる状況はない ⇨ フロントメンバーを集めて、フロント改善プロジェクトを発足しよう！
というのが始まりでした。
フロントエンド改善プロジェクトの目的
各ユニットからフロントメンバーを集め、下記を目的として進めることにしました。
- 各ユニットのバックログに入ってはいるものの、優先度の上がらないようなタスクを消化する
- ユーザビリティやCVRに直結しないようなタスクでも前に進める
- フロントメンバーのフロントエンド技術の向上
- 負債の解消、品質基盤の改善により長期的な開発速度向上と品質向上を図る
どんなことをやってるか
このプロジェクトでは2週間のスプリントに設定し、週に1度の定例でタスクの状況確認・相談などを行い、新しく入ってきたタスクの優先度付けなどを行なっています。
実際にどういった施策を実施してきたのかご紹介していきます。
技術的負債の解消（既存コードのリファクタリング）
asoview.com では2017年あたりからリニューアルや何度かの細かいリファクタリングをしていますが、その際全てのフロントエンドコードがリニューアルされたわけではなく、下記のような状態となっていました。
- リニューアル前後の JavaScript ファイルが混じっている
- Flux・Redux・React hooks が共存している
- TypeScript への移行が部分的
| 2022/07/24時点 | ファイル数 | 行数 | 行数割合 |
|---|---|---|---|
| 古い設計 | 527 | 35681 | 40.32% |
| 新しい設計（JS） | 160 | 9733 | 11.00% |
| 新しい設計（TS） | 329 | 43086 | 48.68% |
現在では6割ほどが React Hooks をメインとした新しい設計のコードに書き変わっています。
ですが依然として古い設計のコードも残っており、古いコード・新しいコードが入り乱れた状態では改修時にバグを生み出しやすく、新機能実装のスピードにも影響が出てきます。また、大きなシステムになると TypeScript による型の恩恵がないのは辛いため、残っている JavaScript ファイルは積極的に TypeScript へ移行していきたい部分です。
また React の Class Component を使っている箇所もあり、hooks が主流な現在では Functional Component でないとカスタムフックの使い回しもできません。
ですが、現状では各プロジェクトでリファクタリングを行うタスクは無く「何らかのタスクのついでにリファクタリングも行う」程度で、時間がない場合は負債に負債を重ねるような形になっている状況でした。
そこでリファクタリングのタスクとして作成し、細分化を行い部分的に対応していくことにしました。
デザインリニューアルと細かいデザイン修正
前述した通り、優先度の高いタスクが入り込んできた場合には最優先で対応する必要があるため「デザインはすでに出来ており、あとは実装するだけ」といったデザイン修正・リニューアル系のタスクは後回しになってしまうようになりました（中には数年前にデザインが起こされたものも…）。
この状態でデザイン改修が入ると、新・旧両方のデザイン修正が必要になってしまいデザイナーの方に余計な工数を発生させてしまいます。
デザインの反映についてはインパクトの大きいページ順に優先度を分け、下記のような細かい粒度から対応していくことにしました。
- 古いナビゲーションアイコン画像を新しいものに差し替え
- 旧デザインの画像カルーセルを SP・PC で統一
- 施設の一覧を表示するカードのデザインを SP・PC で統一
部分的にリニューアルを進めると全体のデザインが損なわれるため、これらはデザイナーとも相談して進めています。
UX上の小さなペイン解消
「少し余白がずれている」「画像の画質が悪い」「使えるけど、少し挙動がおかしい」など、軽微なものは優先度が低く設定されがちです。
ですがこのような小さなペインが積み重なるとユーザー体験が悪くなり、ウェブサービスとしての信用度も下がります。
こういった細かい修正はすぐに対応できることも多いため、重大なバグではないからといって放置せず、積極的に修正しリリースを回していきました。
下記は実際に行ったタスクの例です。
- テキストが改行されたときのレイアウト崩れ
- 要素同士がくっついてしまっている部分の余白調整
- レビュー画像の枚数カウントが実際の画像枚数とズレているバグ修正
PC/SP コンポーネント共通化
asoview.com では PC と SP のUIコンポーネントが分かれているものが多く、UIの変更の際は両方のファイルを修正する必要があります。
レスポンシブ化を行いPC・SPを共通化することで、修正コストを半分に減らすことができ、今後 SPA 化する際の下準備にもなるため、中期的に効果が望めます。
こちらは共通化タスクを作るというより、前述したタスクの中で同時並行して進めることも多いです。
やってみてよかったこと
- フロントのタスクは「とりあえずフロント改善プロジェクトに作成する」としたことでタスク化しやすくなりました。優先的に対応すべきものが明確になり、放置されていたタスクも少しずつ前に進められるようになりました。
- リファクタリングのために既存コードを読み込むことで、仕様やフロントまわりの理解が深まりました。コードの読み書きが多いリファクタリングはやったことが身につきやすく、スキルアップして中堅層が増えれば今後のレビュー効率も上がります。
- 改善タスクはフロントメンバー全員が共通認識を持っているため相談もしやすく、フロント改善定例やPRレビューでも意見交換を行なったことで新しい発見もありました。
やってみてわかった課題
- 購入に関わるページの修正の場合は、テスト量が多いためどうしても時間がかかります。10% の作業時間で効率よくタスクを進めるためには、テストの自動化をしていかなくてはなりません。
- あくまでベストエフォートで進めるため、本業プロジェクトが多忙だとリリースまでの時間が長くなりコンフリクトも起きやすくなります。細分化できない大きなタスクはなかなか手をつけられませんでした。
以上のようにタスクや課題も多いですが、その分やりがいも大きいです。 フロントエンドエンジニアも徐々に増えてきているので、みんなで協力し合いながらどんどん改善を推し進めていきます！
最後に
今回はフロントエンドの内容でしたが、アソビューではどのエンジニアでもフロントエンド、バックエンド、インフラなど全ての領域で挑戦しスキルアップできる環境が整っています。
カジュアル面談もありますので、少しでも興味があればお気軽にご応募ください！
