社内のフロントエンドエンジニア同士をつなぐ ― 大規模組織でも人見知りを作らない取り組み
あげさん(ZOZOTOWN開発3部)
- チームが大きくなって人も増えてきた
- 効率化のために分業化
- 進みすぎるとサイロ化されて分断されてしまう
- Webフロントエンド技術共有会
- エンジニア同士の交流目的
- 社内ラジオ
- 技術顧問との相談会のハードルが高くこれになった
- 技術の話
- 働き方の話
- オフライン/オンラインイベントの企画
- 外部イベントの参加や登壇の呼びかけ
- 外部とのイベント企画
WEARリプレイス完遂までの道筋
いもけんさん(WEAR開発部)
- jQueryからNextへリプレース
- 2021〜2025/7
- リプレース後
- Next
- Tailwind
- msw
- vitest
- storybook
- chromatic
- playwright
- Fastly
- sentry
- datadog
- バックエンドも同時にリプレース
- FastlyをCDNで使った
- 旧版と新版を並行稼働していた時も
- テスト戦略
- Chromaticでコンポーネントのテスト
- プルリクにラベルをつけてStorybookをデプロイする
- VRTも
- vitestでロジックのテスト
- コンポーネントのテストはやってない
- E2Eテスト
- QAチームが
- Chromaticでコンポーネントのテスト
本当の敵は思い込み？ ZOZOTOWNのパフォーマンスチューニング実例
いにさん(ZOZOTOWN開発1部)
- 2025/6くらいから検索順位が下がった
- CWVの改善が求められた
- PCのLCPを3.3sから0.7sへ
- 問題の切り分け
- 商品数にかかわらずどのページもLCPが悪い
- バナーと商品画像が遅い
- SPだとスクリプト読み込みがボトルネックでTBTが悪化
- スクリプト読み込んでから画像を読み込み始めてた
- 制約
- パーソナライズしてるのでキャッシュはできない
- GTMとかKARTEとかDatadogとかスクリプトが多い
- PCページのチューニング
- SSRできてると思ったができてなかった
- 画像コンポーネントがloading=eagerで遅延読み込みになってた
- 画像が読み込まれたあとに高さと幅が確定しない書き方になってた
- widthとheightをつける
- SPページのチューニング
- Appチャンクのサイズを減らす
- 同じスクリプトでもSPだと性能の問題か遅い
- 238KBあった
- カルーセルをはがした
- フッターで使ってた
- アニメーションのライブラリとかも引きづられて入っていた
- dynamic importすることで
- openapi-typescript-code-generatorでAPIクライアントを生成
- クラスで作られていてtree shakingが効かない
- 数が増えるほど肥大化していく状態
- FunctionalApiClient.generatorで
- 169KBに
- 実測値ベースでの考察がよかった
- WebOerf Snippetsというページに便利なものがある
LP案件を回すためのデザインガイドライン
ゆうとぴさん(ZOZOTOWN企画開発部)
- 企画LP
- 集客の起点となるランディングページ
- デザインガイドラインの作成
- 企画LPは月に10~20リリースされるし企画ごとに世界感が違う
- 当初はデザイナーが作ろうとしていた
- エンジニアがよく使うコンポーネントを集めて提供
- それをデザイナーがガイドラインに
- デザイナーの作業負荷が高すぎた
- 全体を把握しているデザイナーが少なかったため
- エンジニアが叩きを作成
- コードベースからユースケースを確認しながら
- デザイナーが調整し発展させていく
- デザインシステムへ
- コンポーネント
- バリアブル
- アノテーション
- Code Connect
- ファイル構成
- コンポーネント単位でfigmaのページを作成
- 「デザイン名/実装名」の命名
- 変更可能な要素の整理
- figma上で分かるように
