Share
Embed

Slide 1

Slide 1 text

WEARリプレイス完遂までの道筋 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 Webブロック 岩崎 拳志 Copyright © ZOZO, Inc. 1

Slide 2

Slide 2 text

© ZOZO, Inc. 2 話すこと - WEARリプレイスにおけるリプレイスの進め方 - リプレイスを安全に進めるためのテスト戦略 - やって良かったこと・辛かったこと

Slide 3

Slide 3 text

© ZOZO, Inc. 3 目次 - 自己紹介 - WEARについて - 出てくる単語について - WEARリプレイスの歴史 - 使用技術について - 構成 - リプレイスのフロー - リプレイスを支えたテスト戦略 - やって良かったこと・辛かったこと - おわりに

Slide 4

Slide 4 text

© ZOZO, Inc. 株式会社ZOZO ブランドソリューション開発本部 WEAR開発部 Webブロック 岩崎 拳志 (いもけん) 2024年新卒でZOZOに入社 (2023/06~内定者アルバイト) 趣味: 音楽・ポーカー・ボートレース x: @iimokeenpi 4

Slide 5

Slide 5 text

© ZOZO, Inc. https://wear.jp/ 5 ● あなたの「似合う」が探せるファッションコーディネートアプリ ● 1,900万ダウンロード突破、コーディネート投稿総数は1,400万件 以上（2025年12月末時点） ● コーディネートや最新トレンド、メイクなど豊富なファッション情報を チェック ● AIを活用したファッションジャンル診断や、フルメイクをARで試せる 「WEARお試しメイク」を提供 ● コーディネート着用アイテムを公式サイトで購入可能 ● WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレント ・デザイナー・インフルエンサーといった各界著名人も参加

Slide 6

Slide 6 text

© ZOZO, Inc. 6 出てくる単語について

Slide 7

Slide 7 text

© ZOZO, Inc. 7 出てくる単語について ・WEAR1 - リプレイス前環境 (VBScript/jQueryで動作) ・WEAR2 - リプレイス後環境 (Next.jsで動作)

Slide 8

Slide 8 text

© ZOZO, Inc. 8 リプレイスの歴史

Slide 9

Slide 9 text

© ZOZO, Inc. 9 リプレイス歴史 ・WEAR Webチームでは2021年からリプレイスを開始 ・2025年7月、全ページリプレイス完了

Slide 10

Slide 10 text

© ZOZO, Inc. 10 使用技術について

Slide 11

Slide 11 text

© ZOZO, Inc. 11 使用技術について ・Next.js (Pages Router) ・Tailwind CSS ・Mock Service Worker ・Vitest ・Chromatic/Storybook ・Playwright (VRT) ・Fastly (CDN) ・Datadog ・Sentry

Slide 12

Slide 12 text

© ZOZO, Inc. 12 構成

Slide 13

Slide 13 text

© ZOZO, Inc. 13 構成 Fastlyを用いて、WAER1環境とWEAR2環境へのルーティングを制御 リダイレクトなどもFastlyで制御 WEAR1 WEAR2 ユーザー

Slide 14

Slide 14 text

© ZOZO, Inc. 14 リプレイスフロー

Slide 15

Slide 15 text

© ZOZO, Inc. 15 リプレイスフロー 仕様検討 - WEAR1のソースコード/ページを見ながら既存機能洗い出し - 既存機能からの削除・変更やレスポンシブ対応に伴う仕様決め - 必要なAPI洗い出し - 仕様検討書作成

Slide 16

Slide 16 text

© ZOZO, Inc. 16 リプレイスフロー デザイン作成 - Figmaを利用 - レスポンシブ対応デザイン(WEAR1はレスポンシブ未対応) - 既存デザインの改修

Slide 17

Slide 17 text

© ZOZO, Inc. 17 リプレイスフロー バックエンド(API)実装 - バックエンドのリプレイスも並行して行なっていた - API定義書の作成 - 必要なAPIを作成

Slide 18

Slide 18 text

© ZOZO, Inc. 18 リプレイスフロー フロントエンドの実装 - 必要コンポーネントの作成 - コンポーネントを配置して、ページ全体の作成 - (ページによって)計測等の実装 - API連携実装 (ローカルはMSWを使って実装)

Slide 19

Slide 19 text

© ZOZO, Inc. 19 リプレイスフロー デザインレビュー - STG環境にデプロイしてデザイナーによるデザインレビュー - 余白・レイアウト崩れ・アニメーションなどの確認

Slide 20

Slide 20 text

© ZOZO, Inc. 20 リプレイスフロー 仕様書作成 - 最終的な仕様書を作成

Slide 21

Slide 21 text

© ZOZO, Inc. 21 リプレイスフロー QA - 仕様書をもとに動作のテストを行う

Slide 22

Slide 22 text

© ZOZO, Inc. 22 リプレイスフロー リリース - FastlyにてルーティングをWEAR1からWEAR2に変更

Slide 23

Slide 23 text

© ZOZO, Inc. 23 リプレイスフロー リリース後の動作確認 - Sentryにてエラーの確認 - Datadogにてレイテンシ、CPU使用率、Core Web Vitals などの悪化がないかを確認 - Looker Studioにてアクセス数やLighthouseの数値確認

Slide 24

Slide 24 text

© ZOZO, Inc. 24 リプレイスを支えたテスト戦略

Slide 25

Slide 25 text

© ZOZO, Inc. 25 リプレイスを支えたテスト戦略 新たにリプレイスするページはもちろん、既にリプレイス済みのページも考慮し ていく必要があるためテストを設けている フロントエンドの自動テスト - Chromatic / Storybookを用いたコンポーネント単位のテスト - Playwrightを用いたビジュアルリグレッションテスト - Vitestを用いた関数テスト - TypeScript / ESLint / Prettier による静的テスト

Slide 26

Slide 26 text

© ZOZO, Inc. 26 リプレイスを支えたテスト戦略 Chromatic / Storybookを用いたコンポーネント単位のテスト - 特定のラベルを付与したPR単位で Chromatic上にStorybookをビルド - Chromatic上のスナップショット を元にコンポーネント単位の ビジュアルテスト - インタラクションな部分は 手動で確認

Slide 27

Slide 27 text

© ZOZO, Inc. 27 リプレイスを支えたテスト戦略 Playwrightを用いたビジュアルリグレッションテスト - PR毎にPlaywrightによる実行 - 広告の表示もなども含め ページ単位の差分を確認 - MSWのモックデータを使用 - 意図した差分であれば スナップショットを更新

Slide 28

Slide 28 text

© ZOZO, Inc. 28 リプレイスを支えたテスト戦略 Vitestを用いた関数テスト - PR毎に関数単体のロジックテストを実行 - コンポーネントのインタラクションテストなどは 基本的に書いていない - カバレッジレポートをHTML形式で可視化 などもしている

Slide 29

Slide 29 text

© ZOZO, Inc. 29 リプレイスを支えたテスト戦略 その他のテストについて - E2Eテスト - 基本的にQAチームに担保してもらっている - インタラクションテスト - Storybookでの手動確認・ デザインレビュー/QAを通して担保している - パフォーマンステスト - LighthouseやCore Web Vitalsの値の推移を 毎週チームで確認 - アクセシビリティテスト - Lighthouseの値やmiCheckerなどの ツールを使って確認

Slide 30

Slide 30 text

© ZOZO, Inc. 30 リプレイスを支えたテスト戦略 テストに関する参考記事 - WEAR Webフロントエンドの自動テスト構成 2023 - PullRequestのレビュー負荷を軽減し、開発生産性を向上するためにチーム で取り組んだこと - Lighthouse CIでデータを蓄積し、Looker Studioで日々のスコアを可視化した 話

Slide 31

Slide 31 text

© ZOZO, Inc. 31 やって良かったこと・辛かったこと

Slide 32

Slide 32 text

© ZOZO, Inc. 32 やって良かったこと - FastlyをFEで管理したこと - 開発のスピード感を早めることができた - リリースのタイミングを自由にコントロールすることができた - (基本的に)WEAR1の改修を行わない意思決定 - リプレイスに集中することができた - 定期的な振り返り(KPT) - 月に1回KPTと言うフレームワークを使って振り返りを行なった - 課題や問題が発生した時にすぐに改善に向かうことができた

Slide 33

Slide 33 text

© ZOZO, Inc. 33 やって良かったこと - 運用のことを考えた設計(仕様検討) - ヘルプページなどWEAR1ではハードコードしていた - Zendeskに置き換えAPI経由でデータを取得するようにした - 細かいリリース・PR - ほぼ毎日リリース - 問題が発生した際に原因の特定がしやすい - 表に出したくないものはFeature Flagで管理 - 依存ライブラリのバージョン管理 - Renovateを活用し、毎週分担して依存ライブラリを最新に保っていた

Slide 34

Slide 34 text

© ZOZO, Inc. 34 辛かったこと(失敗談) - 既存仕様の把握漏れ - リリースした後に発覚する、考慮もれが多々あった - PRにWEAR1の該当コードURLを貼る - リプレイス時の既存仕様チェックリストを作成しチーム内レビューを実施 - アクセス数が少ないページの監視 - アクセス数が少ないページで発生したエラーに気づかず放置されていた - Datadog上にページ単位で監視できるダッシュボードを作成 - リプレイスに時間がかかりすぎた - 技術トレンドの変化 - リプレイスの実装スケジュールにバッファをとって 余った時間でリファクタリングなどを遂行

Slide 35

Slide 35 text

© ZOZO, Inc. 35 辛かったこと(失敗談) - Flakyなテスト - Flakyなテストをスルーしていたら実際に問題が起きていた - デザインシステムが整ってない - 似てるけど、デザインや挙動が若干異なるコンポーネントが多発 - エンジニア側から積極的にデザイナーに提案 - WEAR(アプリ)で大きいリニューアルがあった - それに合わせてWEAR1の改修を入れないといけない部分があった

Slide 36

Slide 36 text

© ZOZO, Inc. 36 おわりに

Slide 37

Slide 37 text

© ZOZO, Inc. 37 おわりに 自分がジョインしてから、リプレイス完了まで特別大きいバグや障害を起こすこ となく無事リプレイスを完遂できました AI時代だとまた違う進め方になっていくかもしれないが、何か参考になれば幸い です

Slide 38

Slide 38 text

No content