WEARリプレイス完遂までの道筋

2026/03/18 に行われた「ZOZO フロントエンドMeetup」で発表した登壇資料です。
https://zozotech-inc.connpass.com/event/385379/

株式会社ZOZO
ブランドソリューション開発本部 WEAR開発部 Webブロック
岩崎 拳志

Transcript

1. WEARリプレイス完遂までの道筋 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 Webブロック 岩崎 拳志 Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 2 話すこと - WEARリプレイスにおけるリプレイスの進め方 - リプレイスを安全に進めるためのテスト戦略 - やって良かったこと・辛かったこと
3. © ZOZO, Inc. 3 目次 - 自己紹介 - WEARについて - 出てくる単語について - WEARリプレイスの歴史 - 使用技術について - 構成 - リプレイスのフロー - リプレイスを支えたテスト戦略 - やって良かったこと・辛かったこと - おわりに
4. © ZOZO, Inc. 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 Webブロック 岩崎 拳志 (いもけん) 2024年新卒でZOZOに入社 (2023/06~内定者アルバイト) 趣味: 音楽・ポーカー・ボートレース x: @iimokeenpi 4
5. © ZOZO, Inc. https://wear.jp/ 5 • あなたの「似合う」が探せるファッションコーディネートアプリ • 1,900万ダウンロード突破、コーディネート投稿総数は1,400万件 以上（2025年12月末時点） • コーディネートや最新トレンド、メイクなど豊富なファッション情報を チェック • AIを活用したファッションジャンル診断や、フルメイクをARで試せる 「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレント ・デザイナー・インフルエンサーといった各界著名人も参加
6. © ZOZO, Inc. 6 出てくる単語について
7. © ZOZO, Inc. 7 出てくる単語について ・WEAR1 - リプレイス前環境 (VBScript/jQueryで動作) ・WEAR2 - リプレイス後環境 (Next.jsで動作)
8. © ZOZO, Inc. 8 リプレイスの歴史
9. © ZOZO, Inc. 9 リプレイス歴史 ・WEAR Webチームでは2021年からリプレイスを開始 ・2025年7月、全ページリプレイス完了
10. © ZOZO, Inc. 10 使用技術について
11. © ZOZO, Inc. 11 使用技術について ・Next.js (Pages Router) ・Tailwind CSS ・Mock Service Worker ・Vitest ・Chromatic/Storybook ・Playwright (VRT) ・Fastly (CDN) ・Datadog ・Sentry
12. © ZOZO, Inc. 12 構成
13. © ZOZO, Inc. 13 構成 Fastlyを用いて、WAER1環境とWEAR2環境へのルーティングを制御 リダイレクトなどもFastlyで制御 WEAR1 WEAR2 ユーザー
14. © ZOZO, Inc. 14 リプレイスフロー
15. © ZOZO, Inc. 15 リプレイスフロー 仕様検討 - WEAR1のソースコード/ページを見ながら既存機能洗い出し - 既存機能からの削除・変更やレスポンシブ対応に伴う仕様決め - 必要なAPI洗い出し - 仕様検討書作成
16. © ZOZO, Inc. 16 リプレイスフロー デザイン作成 - Figmaを利用 - レスポンシブ対応デザイン(WEAR1はレスポンシブ未対応) - 既存デザインの改修
17. © ZOZO, Inc. 17 リプレイスフロー バックエンド(API)実装 - バックエンドのリプレイスも並行して行なっていた - API定義書の作成 - 必要なAPIを作成
18. © ZOZO, Inc. 18 リプレイスフロー フロントエンドの実装 - 必要コンポーネントの作成 - コンポーネントを配置して、ページ全体の作成 - (ページによって)計測等の実装 - API連携実装 (ローカルはMSWを使って実装)
19. © ZOZO, Inc. 19 リプレイスフロー デザインレビュー - STG環境にデプロイしてデザイナーによるデザインレビュー - 余白・レイアウト崩れ・アニメーションなどの確認
20. © ZOZO, Inc. 20 リプレイスフロー 仕様書作成 - 最終的な仕様書を作成
21. © ZOZO, Inc. 21 リプレイスフロー QA - 仕様書をもとに動作のテストを行う
22. © ZOZO, Inc. 22 リプレイスフロー リリース - FastlyにてルーティングをWEAR1からWEAR2に変更
23. © ZOZO, Inc. 23 リプレイスフロー リリース後の動作確認 - Sentryにてエラーの確認 - Datadogにてレイテンシ、CPU使用率、Core Web Vitals などの悪化がないかを確認 - Looker Studioにてアクセス数やLighthouseの数値確認
24. © ZOZO, Inc. 24 リプレイスを支えたテスト戦略
25. © ZOZO, Inc. 25 リプレイスを支えたテスト戦略 新たにリプレイスするページはもちろん、既にリプレイス済みのページも考慮し ていく必要があるためテストを設けている フロントエンドの自動テスト - Chromatic / Storybookを用いたコンポーネント単位のテスト - Playwrightを用いたビジュアルリグレッションテスト - Vitestを用いた関数テスト - TypeScript / ESLint / Prettier による静的テスト
26. © ZOZO, Inc. 26 リプレイスを支えたテスト戦略 Chromatic / Storybookを用いたコンポーネント単位のテスト - 特定のラベルを付与したPR単位で Chromatic上にStorybookをビルド - Chromatic上のスナップショット を元にコンポーネント単位の ビジュアルテスト - インタラクションな部分は 手動で確認
27. © ZOZO, Inc. 27 リプレイスを支えたテスト戦略 Playwrightを用いたビジュアルリグレッションテスト - PR毎にPlaywrightによる実行 - 広告の表示もなども含め ページ単位の差分を確認 - MSWのモックデータを使用 - 意図した差分であれば スナップショットを更新
28. © ZOZO, Inc. 28 リプレイスを支えたテスト戦略 Vitestを用いた関数テスト - PR毎に関数単体のロジックテストを実行 - コンポーネントのインタラクションテストなどは 基本的に書いていない - カバレッジレポートをHTML形式で可視化 などもしている
29. © ZOZO, Inc. 29 リプレイスを支えたテスト戦略 その他のテストについて - E2Eテスト - 基本的にQAチームに担保してもらっている - インタラクションテスト - Storybookでの手動確認・ デザインレビュー/QAを通して担保している - パフォーマンステスト - LighthouseやCore Web Vitalsの値の推移を 毎週チームで確認 - アクセシビリティテスト - Lighthouseの値やmiCheckerなどの ツールを使って確認
30. © ZOZO, Inc. 30 リプレイスを支えたテスト戦略 テストに関する参考記事 - WEAR Webフロントエンドの自動テスト構成 2023 - PullRequestのレビュー負荷を軽減し、開発生産性を向上するためにチーム で取り組んだこと - Lighthouse CIでデータを蓄積し、Looker Studioで日々のスコアを可視化した 話
31. © ZOZO, Inc. 31 やって良かったこと・辛かったこと
32. © ZOZO, Inc. 32 やって良かったこと - FastlyをFEで管理したこと - 開発のスピード感を早めることができた - リリースのタイミングを自由にコントロールすることができた - (基本的に)WEAR1の改修を行わない意思決定 - リプレイスに集中することができた - 定期的な振り返り(KPT) - 月に1回KPTと言うフレームワークを使って振り返りを行なった - 課題や問題が発生した時にすぐに改善に向かうことができた
33. © ZOZO, Inc. 33 やって良かったこと - 運用のことを考えた設計(仕様検討) - ヘルプページなどWEAR1ではハードコードしていた - Zendeskに置き換えAPI経由でデータを取得するようにした - 細かいリリース・PR - ほぼ毎日リリース - 問題が発生した際に原因の特定がしやすい - 表に出したくないものはFeature Flagで管理 - 依存ライブラリのバージョン管理 - Renovateを活用し、毎週分担して依存ライブラリを最新に保っていた
34. © ZOZO, Inc. 34 辛かったこと(失敗談) - 既存仕様の把握漏れ - リリースした後に発覚する、考慮もれが多々あった - PRにWEAR1の該当コードURLを貼る - リプレイス時の既存仕様チェックリストを作成しチーム内レビューを実施 - アクセス数が少ないページの監視 - アクセス数が少ないページで発生したエラーに気づかず放置されていた - Datadog上にページ単位で監視できるダッシュボードを作成 - リプレイスに時間がかかりすぎた - 技術トレンドの変化 - リプレイスの実装スケジュールにバッファをとって 余った時間でリファクタリングなどを遂行
35. © ZOZO, Inc. 35 辛かったこと(失敗談) - Flakyなテスト - Flakyなテストをスルーしていたら実際に問題が起きていた - デザインシステムが整ってない - 似てるけど、デザインや挙動が若干異なるコンポーネントが多発 - エンジニア側から積極的にデザイナーに提案 - WEAR(アプリ)で大きいリニューアルがあった - それに合わせてWEAR1の改修を入れないといけない部分があった
36. © ZOZO, Inc. 36 おわりに
37. © ZOZO, Inc. 37 おわりに 自分がジョインしてから、リプレイス完了まで特別大きいバグや障害を起こすこ となく無事リプレイスを完遂できました AI時代だとまた違う進め方になっていくかもしれないが、何か参考になれば幸い です