ファッションコーディネートアプリWEARの リプレイスと組織の変遷 / wear-replace-2021

WEARの歴史を振り返りながらリプレイスに至った経緯とリプレイスの方針、その成果について

Transcript

1. ファッションコーディネートアプリWEARの
 リプレイスと組織の変遷
 2021/11/24 TECH HILLS #1
 株式会社ZOZO
 メディア開発本部
 本部長
 脇阪 博成 Copyright © ZOZO, Inc.
2. © ZOZO, Inc. 株式会社ZOZO
 メディア開発本部
 本部長 脇阪 博成
 2019年6月入社
 入社後はWEARのリプレイス開発、組織マネジメントを行い、 その後はFAANSの開発責任者としてサービスをローンチ。
 2021年10月から本部長に就任し、両プロダクトの開発組織 のマネジメントを行う。
 
 
 2
3. © ZOZO, Inc. https://zozo.jp/
 3 • ファッション通販サイト
 • 1,500以上のショップ、8,400以上のブランドの取り扱い
 • 常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商 品を掲載（2021年9月末時点）
 • ブランド古着のファッションゾーン「ZOZOUSED」や
 コスメ専門モール「ZOZOCOSME」、靴の専門モール
 「ZOZOSHOES」、ラグジュアリー＆デザイナーズゾーン
 「ZOZOVILLA」を展開
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など

4. © ZOZO, Inc. https://wear.jp/
 4 • ファッションコーディネートアプリ
 • 1,500万ダウンロード突破、コーディネート投稿総数は1,100万件以上 （2021年9月末時点）
 • ピックアップタグから最新のトレンドをチェック
 • コーディネート着用アイテムをブランド公式サイトで購入可能
 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレント・デザ イナー・インフルエンサーといった各界著名人も参加

5. © ZOZO, Inc. 5 Agenda
 
 1. WEARの歩みとリプレイスに至った経緯
 
 2. リプレイス方針（技術編）
 
 3. リプレイス方針（組織編）
 
 4. 組織変更とその成果
 
 5. まとめ

6. © ZOZO, Inc. 6 資料上の注意
 
 • WEAR1: リプレイス前の環境
 
 • WEAR2: リプレイス後の環境
 
 • WEAR: プロダクト自体
 

7. © ZOZO, Inc. 7 1. WEARの歩みとリプレイスに至った経緯

8. 8 2013 2014 2015 2016 2017 2019 2018 2020 2021 2013.10 WEAR サービス開始 2014.02 100万ダウンロード達成 2014.03 初のテレビCMを放映 2014.05 WEAR初、人気一般ユーザー約20名を WEARISTAに認定 初の海外展開として台湾サービス開始 2015.04 全世界でダウンロード可能 2015.06 約200名の人気一般ユーザーを WEARISTAに認定 2016.02 人気14ブランドが一般ユーザーと スポンサーシップを結び ブランド公認ユーザーに認定 2017.10 Pinterestと連携開始 2018.10 新しい検索機能「新見つける」リリース 広告事業開始 2019.03 1,300万ダウンロード達成 2019.05 Amazon Alexa スキル 「コーデ相談 by WEAR」リリース 2020.03 TOPリニューアル 「今日のピックアップタグ」開始 2020.04 機械学習を活用した 「髪型別コーデ検索」リリース 2020.09 機械学習を活用した 「類似アイテム検索」リリース 2021.10.20 複数枚投稿リリース coming soon ファッション動画投稿機能 リリース ユーザー・コーデコンテンツ獲得期 質の良いコーデコンテンツ獲得期 欲しい服が見つかる機能拡充期 ファッションデータ集めて・届ける期 WEARの歩み

9. 9 2013 2014 2015 2016 2017 2019 2018 2020 2021 2013.10 WEAR サービス開始 2014.02 100万ダウンロード達成 2014.03 初のテレビCMを放映 2014.05 WEAR初、人気一般ユーザー約20名を WEARISTAに認定 初の海外展開として台湾サービス開始 2015.04 全世界でダウンロード可能 2015.06 約200名の人気一般ユーザーを WEARISTAに認定 2016.02 人気14ブランドが一般ユーザーと スポンサーシップを結び ブランド公認ユーザーに認定 2017.10 Pinterestと連携開始 2018.10 新しい検索機能「新見つける」リリース 広告事業開始 2019.03 1,300万ダウンロード達成 2019.05 Amazon Alexa スキル 「コーデ相談 by WEAR」リリース 2020.03 TOPリニューアル 「今日のピックアップタグ」開始 2020.04 機械学習を活用した 「髪型別コーデ検索」リリース 2020.09 機械学習を活用した 「類似アイテム検索」リリース 2021.10.20 複数枚投稿リリース coming soon ファッション動画投稿機能 リリース ユーザー・コーデコンテンツ獲得期 質の良いコーデコンテンツ獲得期 欲しい服が見つかる機能拡充期 ファッションデータ集めて・届ける期 WEARの歩み
 WEAR2環境での 初のAPIリリース
10. © ZOZO, Inc. 10 なぜリプレイスが必要だったのか？

11. © ZOZO, Inc. 11 WEAR1環境の紹介
 開発言語
 
 VBScript
 
 DB
 
 Microsoft SQL Server
 ※ バックエンドのロジックの大半がストアドプロシージャで記述
 
 サーバ
 
 Windows Server（IIS）

12. © ZOZO, Inc. 2013年リリースなのに
 なぜこんな環境に？？？🤔🤔🤔
 
 
2013年といえばRuby, Golang, Node.js, PHP, Javaなどが主流で、選択肢は多かったはずなのに…
 12
13. © ZOZO, Inc. 13 なぜならWEAR1の技術スタックはZOZOTOWNと同じだから
 • ZOZOTOWNは2004年にサービスを開始し、WEARと同様の環境で今も運 用されている
 • なおZOZOTOWNもリプレイスをしています
 ◦ ZOZOTOWNリプレイス2020
 

14. © ZOZO, Inc. 14 リプレイス or リファクタリング
 議論になることが多いが、
 
 • VBScriptの将来性のなさ
 • ストアドプロシージャが抱える様々な問題
 ◦ パフォーマンス上の問題
 ◦ 開発効率の問題
 ◦ CI/CD問題
 ◦ 他にも様々
 
 これらを理由にリプレイスに舵を切り、2019年からプロジェクト開始
 問題は開発言語を何にするか？アーキテクチャをどうするか？
 

15. © ZOZO, Inc. 15 2. リプレイス方針（技術編）

16. © ZOZO, Inc. 16 開発言語、フレームワーク
 Ruby on Railsを採用
 
 • 合併したVASILYで3年以上の開発・運用経験
 • WEAR2の初期メンバーが全員元VASILYかつRuby経験者
 

17. © ZOZO, Inc. 17 インフラアーキテクチャ
 モノリシックアーキテクチャ
 • 機能数、エンジニア数がそこまで大規模とならない想定
 ◦ エンジニアは最大で10名ほどのアサインを想定
 • プロジェクトスタート時にSREのアサインがゼロ！
 
 AWS
 • SREのアサインはゼロだったが、社内に知見は多くあった
 • ECS on FargateでアプリケーションサーバだけAWSへ
 • DBはオンプレのSQL ServerにDirect Connectで接続
 

18. © ZOZO, Inc. 18 2019年1月当時の組織
 WEAR2 サーバサイド: 3人
 WEAR2 SRE: 0人
 WEAR1 サーバサイド（フロント兼務）: 8人
 WEAR1 SRE: 1人
 

19. © ZOZO, Inc. 19 改めてWEAR1環境の紹介
 WEAR1の構成を大きく分類すると
 • Web: PC/SPのWebサイト
 • API: アプリ、Webが利用するAPI
 • StaffTool: 社内の管理者が利用する管理画面
 
 この中でもっともユーザ影響が少ないStaffToolのリプレイスから始め、技 術検証を行うことに

20. © ZOZO, Inc. 20 StaffToolリプレイス後の環境
 FargateでRailsアプリケーションを動かし、Direct Connect経由でオン プレのSQL Serverに接続することに無事成功。
 リプレイスの過程をテックブログにも公開。
 Fargate x Railsで考慮したassets配信・ログ・秘匿情報管理・モニタリ ングについて
 
 無事に技術検証はできたので次はAPIのリプレイスへ

21. © ZOZO, Inc. 21 APIリプレイス、その前に

22. © ZOZO, Inc. 22 組織の増員（2019年6月時点）
 • リプレイスチームが3人から6人に増員
 ◦ うち2人はRails未経験者
 • 試しに1つのAPIリプレイスをして、サンプル実装を用意することに
 

23. © ZOZO, Inc. 23 API実装方針 Schema編
 WEAR1環境もOpenAPIで定義されていたが…
 
 • 定義されていても実装と乖離しているものがほとんど
 
 そのためWEAR2環境では実装との乖離を防ぐために
 
 • 定義に基づいたリクエストパラメータのバリデーション
 • request specで定義に基づいたレスポンスのテスト

24. © ZOZO, Inc. 24 API実装方針 DB編
 • 脱ストアドプロシージャ
 ◦ DBパフォーマンス改善
 ◦ ストアドをRailsで再実装
 • モデルの再定義
 ◦ 既存のテーブル名、カラム名をそのまま使わず再定義
 ◦ ユビキタス言語の策定
 ◦ 右図は社内で説明に使っている芸術的な図

25. © ZOZO, Inc. 25 API実装方針 ドキュメント編
 • 設計思想をドキュメント化
 • 配属時に必ず読む
 • コードレビューに利用
 

26. © ZOZO, Inc. 準備は整った
 API量産体制へ…
 
 と行きたかったのですが、いくつか問題が発生しました。
 26
27. © ZOZO, Inc. 27 APIリプレイスの問題点
 1. WEAR1 APIの統一感のないリクエスト、レスポンス
 a. そのままリプレイスをするとパフォーマンスやメンテナンス性に難あり
 b. 悪い設計から良いコードを生むのは難しかった
 2. プロダクトオーナー、アプリチームがリプレイスに消極的
 a. 既存仕様そのままにリプレイスしているがバグが生まれる可能性はある
 b. テストのコストが上がるため、案件を進めながらリプレイスは難しい
 3. WEAR1チームとWEAR2チームの関係性に課題があった

28. © ZOZO, Inc. 28 3. リプレイス方針（組織編）

29. © ZOZO, Inc. 29 改めて当時（2019年10月）の組織について説明
 WEAR2（青山）: 4人
 WEAR1（幕張）: 9人
 
 これまで拠点の話をしていませんでしたが、チームで拠点が分かれていました

30. © ZOZO, Inc. 30 拠点間でのコミュニケーション
 • 週に1回の定例のみで、参加者はリーダー陣だけ
 • 現場間での顔を合わせたコミュニケーションはほぼ無し
 • Slackでのテキストベースでのやり取りがほとんど
 • 後にわかったことだが、リプレイスの目的や重要度が現場に伝わっていなかった

31. © ZOZO, Inc. 31 WEAR2チームの考え
 • 当時の代表やCTOからWEARの目指す姿、リプレイスについて共有されていた
 • それから逸れるWEAR1チームの姿を見て、「あるべき姿」を主張
 ◦ なぜWEAR1チームは逸れるのか？
 ◦ なぜ相談なく勝手に進めるのか？
 ◦ なぜリプレイスに非協力的なのか？

32. © ZOZO, Inc. 32 WEAR1チームの考え
 • リプレイスが始まってるらしいが、情報共有されていないので普段どおり開発
 ◦ 「いつかWEAR2チームがなんとかしてくれるだろう」
 • するとWEAR2チームの人達があるべき論を振りかざす
 ◦ 正論ではあるけれど、よく知らない人からなぜそんなことを言われるの？
 • 我々にだってこれまでWEARを築き上げてきた自負がある
 ◦ なんでそんなことを言われなければならないのか

33. © ZOZO, Inc. つまり仲が悪かった
 33
34. © ZOZO, Inc. リプレイス設計の前に、
 組織設計が重要だったという学び
 
 
ここからが本題です
 34
35. © ZOZO, Inc. 35 ONE TEAMになるために
 • 2019年秋頃からWEAR2チームが積極的に幕張に出社
 • エンジニアに限らず、関係者と会話を増やし、困ってることをヒアリング
 • プロダクトオーナーと腹を割って話す（ただの飲み会）
 
 
 
 
 
 

36. © ZOZO, Inc. 36 ヒアリングの結果、課題が見えてきた
 • アプリのトップページをリニューアルしていること
 • サーバのパフォーマンス面で不安があること
 • 運用チームがコーデを選定する業務が発生すること
 • プロジェクト自体が手戻りが多く前に進まないこと
 
 
 
 
 
 リプレイスを主目的とすることは止め、 WEAR2チームはこの課題を一緒に解決していくことに
37. © ZOZO, Inc. 37 リプレイスの方針変更後
 • TOPページのリニューアルに成功
 ◦ パフォーマンスも問題なし
 ◦ 運用チームが作業するツールも整備
 • その後の案件もWEAR2チームが相談に乗りながら主導
 • 業務やキャリアの悩みに関するヒアリングは継続
 
 
 
 
 WEAR2チームの信頼貯金が貯まり、 組織が一体となってリプレイスを推進できるようになった
38. © ZOZO, Inc. 38 4. 組織変更とその成果

39. © ZOZO, Inc. 39 選択と集中
 • 運用の改善
 ◦ WEAR1チームは日々問い合わせ対応に追われ、開発ができていなかった
 ▪ 問い合わせ対応はDBサーバにログインして手動でのSQL実行
 ▪ 鳴り止まないアラート対応
 • APIリプレイスに集中
 ◦ リプレイスを主目的とせず、機能追加や改修に合わせてリプレイス
 ◦ 一旦Webサイトのリプレイスは後回し
 ◦ フロントエンドが得意な人材も一旦バックエンドへ
 • WEAR1のコードフリーズ
 ◦ WEAR1の改修をしていては一向に改善しないため
 
 
 
 

40. © ZOZO, Inc. 40 組織変更
 • 運用改善チーム：5人
 • サービス開発チーム：5人
 
 ※ 拠点関係ないチーム構成になりました
 
 
 

41. © ZOZO, Inc. 41 組織変更後のモチベーションを高めるために
 • 組織の行動規範を定め、理想のエンジニア像、目指す組織像を定義
 ◦ リプレイスが必要な理由
 ◦ 個々の成長が必要な理由
 • 組織変更の意図を伝え、全員が納得感を持って同じ方向を目指す状態へ
 

42. © ZOZO, Inc. 42 各チームの成果

43. © ZOZO, Inc. 43 運用改善チームの成果概略（2021年5月時点）
 • エンジニア作業依頼チケット 82%削減(2020年4月比)
 • 不要API 201件 コード52,392行削除
 • 不要ストアドプロシージャ 895件削除
 • SQLのクエリタイムアウト 97%削減(2020年10月比)
 • プッシュ通知 開封数7.48倍(2020年9月比)
 
 ※ 詳細はAppendixに
 

44. © ZOZO, Inc. 44 サービス開発チーム成果概略
 • 類似アイテム検索機能
 • コーデ画像から着用アイテムの検出とクローゼット内アイテムの推薦機能
 • 動画投稿機能
 • Amazon CloudSearchからAmazon OpenSearchにリプレイス

45. © ZOZO, Inc. 45 2021年11月現在

46. © ZOZO, Inc. 46 さらなる組織変更
 急務であった運用改善は大きな成果を出せたのでサービス開発チームと統合して バックエンドの開発をやりながら改善を進めている。
 選択と集中の結果、後回しにしていたWebのリプレイスを本格稼働
 
 特にWebフロントエンド人材を絶賛採用活動中です！！！
 

47. © ZOZO, Inc. 47 5. まとめ

48. © ZOZO, Inc. 48 まとめ
 • リプレイスでは技術選定ももちろん大事
 • それ以上に組織全体がリプレイスに対する共通の認識を持つことが大事
 • プロダクトの状況やエンジニアの数に合わせて、組織もリファクタリング
 • 各社状況は異なると思いますが、WEARの事例が参考になれば幸いです
 

50. © ZOZO, Inc. 50 Appendix

51. © ZOZO, Inc. 51 Before 2020年 4月 81件
 After 2021年 1~3月 平均14.6件に減少。
 
 半年換算で上半期 112.5時間、下半期 50.6時間の削減
 
 4月の時点で全ての依頼に対し「なぜやる必要があるのか」
 理由を確認、なぜやってるのかわからないものや効果が薄いものは やめる or 頻度を減らす。
 
 意味のある作業については必要に応じて
 StaffTool(管理画面)化・バッチ化を進めた。
 
 運用作業チケット82%削減
 運用開発チームに依頼された JIRAチケット数の推移 2020/4 ~ 2021/3
52. © ZOZO, Inc. 52 2013年のリリース以来WEARは1件も不要API削除をしていな かった。
 
 不要なコードが大量にありリプレイス作業の邪魔だった。
 セキュリティ的にも👎👎👎
 
 8ヶ月かけて201件(61%) 52,392行のソースコードを削除。
 11月にはテックブログで社外にも事例を発表。
 Splunkのアクセスログ解析でWEARのAPIを201件(約5万行)削除した話
 
 不要API 201件削除
 API削除の管理をしていた スプレッドシート
53. © ZOZO, Inc. 53 API同様、リプレイス作業の邪魔になるので消したかった。
 4ヶ月かけて各DBのストアドの件数を大幅削減。
 
 メインDB：1,444件 → 741件（48%削減）
 AnalyzeDB：53件 → 26件 (50%削減)
 ReadOnlyDB：487件 → 324件（33%削減） 
 
 不要ストアド 895件削除
 File changed 1,098件の Pull Requestの様子
54. © ZOZO, Inc. 54 リプレイスを進めるにつれ、アプリケーションからDBに投げたク エリがタイムアウトする事象が多発した。
 • インデックスが効いていない
 • DBサーバの物理ディスクの性能限界までIOが発生
 既存の遅いクエリのせいで、全然関係ない本来は高速なクエリ まで遅くなっていた。
 
 地道に改善を続けて2020年10月比で97.3%のエラー削減に成功
 クエリタイムアウト97.3%削減
 リプレイス後のAPIのエラー件数
55. © ZOZO, Inc. 55 つらすぎると定評があったのがプッシュ通知配信。
 手元のマシンでシェルのウィンドウを4枚開いてコマンドを打ち、 半日以上見守る必要があった。あまりにもつらい。
 
 またなぜかWEARアカウントを持っている人にしか配信ができ ず、未ログインユーザーにはリーチできなかった。
 エンジニアいらずでStaffToolから配信できるように、
 また未ログインユーザーもプッシュ通知を受け取れるように基盤 を作り直した。
 ※ただし事前のサーバ増強依頼は必要
 
 
 プッシュ通知開封数 7.48倍
 Android未ログインユーザーからの アクセスが増えてる様子