こんにちは！ZOZOTOWNWEB部 バックエンド2ブロックの佐藤です。

ZOZOTOWNは、①各機能ごとにリプレイスや新規開発が行われるマイクロサービスと、②サービス開始から稼働し続けているASPを利用したアーキテクチャの両輪で構築されています。

私達のチームは②のASPを中心に開発をおこなっており、ざっくりお伝えすると下記の役割があります。

• 今すぐに必要な追加仕様をASPで実現する
• 新しく作成されたマイクロサービスへのリクエスト処理を追加する
• 運用開始後に仕様変更が必要となった際、マイクロサービスの設計・開発にも携わる

創業当時から続くWEBバックエンドチームの業務について、メンバー視点の情報が公に出ることはあまりなかったように思うので、今回はチームのカラーも含めてお伝えできればいいなと思っています！

なお、ZOZOTOWNシステムリプレイスについては下記の記事で技術的な説明をおこなっていますので、是非ご覧ください！

■店舗在庫連携機能の開発

弊社は、ZOZOTOWNで実店舗の商品を取り置き予約し、各ブランド様の実店舗で直接受け取ることができるサービスを2021年11月に開始しました。

現在は一部のブランド様に導入していただいており、対応店舗数は順次拡大しています。お客様は商品のカラーとサイズを選ぶと、在庫のある店舗を表示して取り置きを申し込めます。

ASPでおこなっていること

この仕組みを構築するための専用のマイクロサービスは、社内の別チームが開発しています。データの参照・更新はマイクロサービス内部のみで行われており、ASPではおこなっていません。

ASPで適切な画面遷移や表示を実現するために、WEBバックエンドチームでは各種マイクロサービスの仕様を調査し、時にはコードを深く掘り下げて確認した上で、複数のマイクロサービスを組み合わせてリクエストする処理を実装しています。

自分のチームの管轄範囲ではないリポジトリに調査が及ぶこともあり、マイクロサービスの追加や仕様変更をキャッチアップし続けるなど、ZOZOTOWNの知識を幅広く蓄える気概が必要です。

また、マイクロサービスを開発しているチームとの丁寧な調整・質問などを積み重ねていくことも、意識しているポイントです。

お客様に寄り添う

上記の「店舗在庫連携機能」を含め、新しい機能開発を行う際には、既存の仕組みの改修や、エラーの発生を考慮すべきケースもあります。

「店舗在庫連携機能」の取り置き申し込み完了画面。 取り置き完了までもう少し！というタイミングでエラーが表示されたら辛いですよね。

新機能開発に伴う仕様変更やエラー表示は、お客様にとってストレスの原因となる可能性があります。それを未然に防ぐことに加えて、万が一の場合でもお客様に快適にサイトの閲覧を続けてもらえるように、事前に画面遷移や表示パターンを追加して備えておく必要があります。

その際は、下記のような流れで最終的な仕様を確定します。

1. 改修が必要となるパターンを洗い出す
2. 画面の表示内容をデザイナーと確認
3. 対象のマイクロサービスを洗い出し、仕様の変更可否を確認
4. URLやパラメータについてサービスグロースチームと確認
5. 上記の内容を元に、フロントエンドチームと実装方法を確認

また、時には結合テストに進み、一連の操作フローをテストできるタイミングで、改めて仕様の微調整を品質管理チームやデザイナーとおこなうこともあります。

このように、私たちWEBバックエンドエンジニアの視点に各開発チームの視点を掛け合わせることで、お客様のストレスとなる要素をできる限り排除し、機能リリースの直前まで粘って「お客様の困りごとはこれで解決できるか」「お客様は次にどんな操作をすればよいか明確か」を考慮できるのは、ASP開発者であるZOZOTOWNバックエンドの仕事の醍醐味です。

バックエンドエンジニアの中でお客様に一番近い存在として、最後までこだわりを持って他チームへの提案や開発に取り組むことができるので、大きなやりがいに繋がっています！

■新規サービスの立ち上げ時「以外」の取り組み

新しいサービスが立ち上がるタイミングだけでなく、ZOZOTOWNでは日々様々な施策が実施されています。

例えば、

• 夏やお正月に開催されるZOZOSALE
• 上記以外の時期に開催されるZOZOWEEK（セール）
• 初めて会員になっていただいたお客様を対象としたキャンペーンをはじめ、特定のお客様が特定のタイミングでお得になるポイント施策

などがあり、チームで分担して取り組んでいます。

新春ZOZOSALE、1月1日0時スタートの緊張感

ZOZO内ではお正月のセールに向けて、少しずつお祭りモードになります。まず毎年11月末になると、デザイナー、フロントエンド、バックエンドが集まったセール対応チームが期間限定で立ち上がり、ビジネス担当部門とともにセールを盛り上げるための施策ページの開発に取り組みます。2022年の新春ZOZOSALEでは私が開発リーダー（※）として、職種の垣根を超えて、セールLPに関わるWEBバックエンド以外の各チームとともに開発を進めました。

（※）開発リーダーとは、担当案件の開発要件を実現へと導くために、担当案件内のタスクの把握と管理を行う役割を担う立場です。

その年のセールLPのコンテンツ構成は、過去のセール施策で使用された各コンテンツの効果検証の結果や、その年に特別におこないたい施策の内容を元に決定します。

過去に実施したことのあるコンテンツを流用する場合も、とても細かなアップデートを実施しています。この細かな改善の積み重ねがお客様のお買い物体験の向上に繋がってきます。

まずは年末にプレセールを開始し、お正月から本セールを開始する、という流れであることが多いため、徐々にワクワク感を盛り上げていく演出にも気を配っています。セール対応チーム内であれこれ確認を進め、舞台の準備を整えます！

また、急激なアクセス増加に備えるためにサイトの各所では入念な負荷対策をおこなっています。詳細はお伝えできないのですが、対策期間中も普段と遜色なくお買い物を楽しんでいただけるように、バランスを考慮して実施しています。

これらの準備を経て、いよいよ新春ZOZOSALEを迎えます。

大晦日の夜から徐々にアクセスが増加してきて、マツケンサンバの話をしながら緊張を解きほぐしあいます。一番緊張するのは、1月1日0時のセール開始の瞬間。たくさんのお客様にアクセスしていただくタイミングです。

無事にお客様がお買い物を快適に終えられるよう、万全の体制で臨みます。

こうして、セール担当は安心して年越しを終えることになります……。

ちなみに、必ず大晦日やお正月に出勤しないといけないわけではなく、監視は当番制です！このnoteをお読みになっていて採用への応募を検討してくださっている方はご安心ください。また、当番になったとしても、業務に集中できる環境であれば、例えば実家でこたつに入りながら監視を行うこともできます。

入念な準備が功を奏し、2022年の新春ZOZOSALEでは、お客様にお買い物を快適に楽しんでいただけたのではないかと思っております！

なお、今年のセールにおいてエラーの発生件数が抑えられた大きな要因は、

• カートリプレイス
• 負荷試験の課題解決（効率化・自動化）

にあります。下記の記事で技術的な説明をおこなっていますので、是非ご覧ください。

続きはこちら