はじめに こんにちは、ZOZOMO店舗在庫取り置きというサービスの開発を担当している、ZOZOMO部OMOブロックの木目沢です。 皆様のチームでは定期的に振り返りをしていますか？ 弊ブロックではZOZOMO店舗在庫取り置きサービスをスクラムで開発しています。スプリント期間は1週間で、スプリントの終わりには毎週振り返り（スクラムの用語では「スプリントレトロスペクティブ」）をしています。 今回はなぜ振り返りが欠かせないか、毎週振り返りを行ってきた成果や数々のプラクティスやワークと共に紹介します。 目次 はじめに 目次 なぜスクラムでは振り返りが必要なのか？ 振り返りが続かない・活かされない理由 チームとしての振り返りになっていない チームとしての場ができていない 振り返りのプラクティスやチームのワークを紹介 KPT as ART チームコンピテンシーマトリックス デリゲーションポーカー おわり

はじめに こんにちは、CISO部の兵藤です。日々ZOZOの安全を守るためSOC業務に取り組んでいます。 本記事ではMicrosoftのDefender for Endpointを用いてAppleのmacOSに対してセキュリティ対策するTipsについて紹介します。 また、CISO部ではその他にもZOZOを守るための取り組みを行っています。詳細については以下の「OpenCTIをSentinelに食わせてみた」をご覧いただければと思います。 techblog.zozo.com 目次 はじめに 目次 背景と概要 前提知識 Microsoft Defender for Endpoint導入方法 macOSとWindowsでのDefender for Endpointの機能差分 macOSへのLive Response機能 Live ResponseのBashスクリプトの登録と実行 スクリプトのTip

はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 本連載では、ZOZOTOWNリプレイスプロジェクトについて紹介します。2017年に始まったリプレイスプロジェクトにおいて、ZOZO がどのような意図で、どのように取り組んできたのか、読者のみなさんに有益な情報をお伝えしていければと思いますので、ご期待ください。第1回目のテーマは、「ZOZOTOWNリプレイスプロジェクトの全体アーキテクチャと組織設計」です。 目次 はじめに 目次 ZOZOTOWNリプレイスの背景、目的 背景 目的 柔軟なシステム 開発生産性 技術のモダン化 採用強化 ZOZOTOWNリプレイスの歴史とアーキテクチャの変遷 アーキテクチャの変遷 2004年〜2017年：オンプレミス（リプレイス前） 2017年〜20

はじめに こんにちは、MA部の林（@hayash__p）です。 私達のチームでは、メール、LINE、Push通知、サイト内お知らせなどでユーザにZOZOTOWNのセールや新着商品を紹介するといった、マーケティングに関わるシステムを開発しています。これまで、配信チャネルや配信内容ごとに個別最適化したシステムを開発していましたが、それらを一新したマーケティングプラットフォームを作ることになりました。新しいマーケティングプラットフォームであるZOZO Marketing Platform（以下、ZMP）の概要については以下のテックブログをご覧ください。 techblog.zozo.com 本記事では、マーケティングプラットフォームのリプレイスにあたり、フロントエンドエンジニアとして取り組んだことを紹介します。 目次 はじめに 目次 背景 ZMPの管理画面モジュール MPマネージャー 技術選定 M

はじめに こんにちは、技術本部SRE部フロントSREブロックの柳田です。オンプレミスとクラウドの構築・運用に携わっています。 ZOZOTOWNでは、既存システムのリプレイスプロジェクトを進行中です。リプレイス過渡期の現在、オンプレミスのネットワークとAWSのデータセンターを直接専用線で接続し、安定した高速通信を実現するDirect Connect（以降、DX）を利用しています。各サービスのマイクロサービス化に伴い、オンプレミスとクラウド間の通信量が増えた為、DX10Gの回線が逼迫する問題に直面しました。 本記事では、この回線逼迫の課題をどのように解決したかについて紹介します。 目次 はじめに 目次 回線逼迫の課題 ZOZOTOWNへのアクセスが困難 今後のリプレイスプロジェクトが遅延する可能性 DX10GからDX100Gへの移行 ステップ1：DX100Gの利用申請（クラウド） ステップ2：

はじめに こんにちは、生産プラットフォーム開発本部のstakmeです。 本稿では、スプレッドシートの作業に「手続き的なアプローチ」と「宣言的なアプローチ」という観点を持ち込み、ふたつを対比しながら紹介します。Google Sheetsの多彩な関数を駆使して、日常的な問題に効率的に対応するための具体的なテクニックやヒントを提供します。また注意点やリスクを指摘し、スプレッドシートをより強力に活用するための知識を提供します。 目次 はじめに 目次 背景・課題 本稿の目的 規則的な処理を繰り返すケース 手続き的に構築された例 宣言的に記述された例 SEQUENCE ARRAYFORMULA 関数の組み合わせ なぜ「宣言的」なのか データが徐々に増えるケース 手続き的に構築された例 宣言的に記述された例 別の見せ方でデータを表示したいケース 手続き的に構築された例 宣言的に記述された例 やりすぎのケ

はじめに こんにちは、ECプラットフォーム部会員基盤ブロックのturbofishです。弊社ではモノリスのプログラムで動いているZOZOTOWNをマイクロサービス化する取り組みを行なっており、複数チームが1つの大きなオンプレシステムをマイクロサービスでリプレイスしています。その中で私が所属する会員基盤ブロックでは、ZOZOTOWNの会員情報を管理するマイクロサービスを開発しています。 本記事では、弊チームを含む複数のマイクロサービス開発チームにおいて、既存のアプリケーションの一部をマイクロサービスを使用する処理に置き換えた際、サービス無停止でオンプレ環境にあるDBからマイクロサービスが使用するクラウド環境のDBにデータを移行した戦略を紹介します。 ディスクレイマー 本記事で紹介するデータ移行方法には下記の制約があり、全ての状況に対応できるわけではありません。 DBへの書き込み処理と読み取りの

こんにちは、サーバーサイドエンジニアの竹若です。今回GraphQLにおけるエラーハンドリングを調査、Ruby on Railsとgraphql-rubyを使って実装する機会があったので、そこで得られた知見を共有させていただきたいと思います。(なお今回の実装はプロダクション環境には出ていません) GraphQLの仕様とプラクティス それではまず初めに、GraphQLが仕様に定めているレスポンスの返し方を見ていきましょう。 レスポンスのフォーマットに関するプラクティス GraphQLのプラクティスの1つに、レスポンスのhttp statusを200で統一し、レスポンスのerrorsキーにエラーの詳細な情報を持たせるというものがあります。 なぜならGraphQLではリクエストに複数のクエリを含めることができるからです。 https://www.graph.cool/docs/faq/api-ee

はじめに こんにちは。検索基盤部の岩崎です。検索基盤部ではZOZOTOWNの検索機能の改善に日々取り組んでいます。ZOZOTOWNのおすすめ順検索のプロジェクトでは、機械学習モデルを活用した検索結果の並び順の改善に取り組んでおり、全ての施策はA/Bテストで検証しています。なお、最近の並び順精度改善の取り組みについては以下の記事をご参照ください。 techblog.zozo.com 本記事におけるA/Bテストとは、特定期間中ランダムに振り分けたユーザーに対してそれぞれ別の施策を提示し、その成果の差を検定するテストのことを指します。A/Bテストは施策の効果を検証するための優れた手段として広く知られており、おすすめ順検索改善のリリース判断には欠かせない存在となっています。ZOZOではA/Bテスト基盤の整備を進めており、おすすめ順検索以外にもさまざまな施策でA/Bテスト基盤を用いた運用がされていま

はじめに こんにちは、CTO/DevRelブロックの堀江（@Horie1024）です。ZOZOではGitHub Copilotを全社へ導入しました。本投稿では、GitHub Copilotの導入に際して検討した課題とその課題の解決策としてどのようなアプローチを取ったのかを紹介します。 目次 はじめに 目次 GitHub Copilotとは何か？ GitHub Copilot導入の背景と目的 導入する上での課題 セキュリティ上の懸念 ライセンス侵害のリスク GitHub Copilot for Businessの利用 導入による費用対効果 試験導入による費用対効果の見積もり 試験導入の実施 対象者の選出 アンケートの設計 試験導入の実施 アンケート結果の集計 アンケート結果の考察 費用対効果の見積もり 全社導入の判断 導入決定後のGitHub Copilot利用環境の整備 社内LT会 おまけ

こんにちは、ZOZO NEXTでウェブエンジニアを担当している木下です。先日、弊社が運営するオウンドメディアのFashion Tech Newsにおいて、記事リストのパーソナライズを行いました。本記事ではパーソナライズ導入における、要件定義、レコメンドエンジンの比較、実装での知見や注意点についてまとめます。 fashiontechnews.zozo.com 背景 解決方法の検討 課題の分析 パーソナライズ手法の検討 レコメンド方式について サービスの比較 Amazon Personalizeの実装 実装の流れ アーキテクチャ 実装での工夫点 採用したアルゴリズム アイテムデータの更新頻度 ユーザーの識別 注意点 AWS Personalizeのサンプルリポジトリが古い データの収集には時間がかかる まとまった料金が発生する まとめ 背景 「Fashion Tech News」とは、2018

こんにちは、MA部MA開発1ブロックの齋藤（@kyoppii13）です。 ZOZOTOWNではユーザ行動に基づくキャンペーン配信を実施しています。この配信はリアルタイムマーケティングシステム（以降、RTM）と呼ばれるシステムによって実現しており、RTMでは配信トリガーや配信タイミングの最適化等にユーザの行動ログを利用しています。 この行動ログは、ユーザがZOZOTOWNのページへアクセスした際に、HTTPリクエストをRTMが直接受信する形で収集していました。しかし、RTMの既存のログ収集機能はシステム要件や運用などの課題を抱えていました。また、その一方で全社的にログを収集・蓄積する基盤も並行して運用されており、RTMはこのログ基盤を活用できていませんでした。そのため、RTMでもこの全社ログ収集基盤を利用することで既存の課題を解決しました。 本記事では、RTMにおける行動ログの活用方法と、全

こんにちは、技術本部SRE部ZOZOSREチームの斉藤です。普段はZOZOTOWNのオンプレミスとクラウドの構築・運用に携わっています。またDBREとしてZOZOTOWNのデータベース全般の運用・保守も兼務しております。 ZOZOTOWNではSQL Serverを中心とした各種DBMSが稼働しています。その中で、Amazon RDS for SQL Server（以下、RDS）を使用したデータベースが存在します。これらは、トラフィックの増減が激しいZOZOTOWNのサービスにおいて、オンデマンドでスケール可能なデータベースとして運用されています。 本記事では、クライアントであるEC2（以下、Webサーバー）とRDSの間にデータベースプロキシをnginx TCP Load Balancerで構築し、ロードバランシングを実現した事例を紹介します。参照系データベースのアクセスに関してロードバラン

はじめに こんにちは。基幹システム本部・物流開発部の岡本です。普段はZOZO基幹システムのリプレイスを担当しています。 ZOZOではさらなる成長のため、様々なリプレイスプロジェクトが進行しており、これまでにZOZOTOWNやWEARなどのプロダクトにおける多くのリプレイス事例を公開してきました。本記事では、2022年8月より本格始動したZOZO基幹システムリプレイスの第一弾であるZOZOの物流拠点「ZOZOBASE」を支える「発送システムリプレイス」を紹介します。「発送システムリプレイス」は設計を終えた開発段階で、リリースに向けて進行中です。本記事を皮切りに今後も継続的に発信を続けていくので、是非ご注目ください。 現状の「発送システム」は、Classic ASPのトランザクションスクリプトで実装された大規模なモノリス構成のシステムの一部であり、「障害リスク」と「開発速度の低下」に課題を抱え

こんにちは、WEARバックエンドブロックの天春です。バックエンドの運用・開発に携わっています。本記事では、以前公開したWEARにおけるプッシュ通知システムのリプレイス のフェーズ2を終え、旧環境のプッシュ通知システムのリプレイスを完了したのでシステム構成や移行手順をご紹介します。 目次 目次 1:Nのプッシュ通知システム リプレイス前の1:Nのプッシュ通知システム リプレイス前のシステム構成 問題点 リプレイス後の1:Nのプッシュ通知システム リプレイス後のシステム構成 1:Nキュー（Sidekiqダッシュボード） 負荷テスト 目標 対象 事前準備 負荷テスト実施 負荷テスト結果 負荷テスト実施後の改善内容 大量の通知の遅延を減らす 同時実行数の調整 500件単位でFCM通知配信 1:N通知配信の親ジョブ 500件単位でFCM配信を行う1:N通知配信の子ジョブ 500件単位でDynamoD

こんにちは、最近気になるニュースはサザエの学名が数年前に初めて命名されたこと1な、MLデータ部データ基盤ブロックの塩崎です。BigQueryのストレージに関する新料金プランが先日発表されたので、その検証をしました。我々の環境では年間で数千万円という費用削減を達成できることが分かりましたので、BigQueryに多くのデータを蓄積している会社は是非お試しください。 ストレージ費用の悩み データ基盤を長期間運用していると、データ量の増加が問題になることがしばしばあります。特にユーザーの行動ログやスタースキーマにおけるファクト系テーブルなどはデータがどんどん蓄積されます。古いデータを削除することでデータ量の増加を緩和できますが、それでもサービスの成長に伴いデータ量は増加する傾向になります。 BigQueryはコンピューティングとストレージが高度に分離されているので、初期のAmazon Redshi

はじめに ZOZOTOWN開発本部の武井と申します。ZOZOTOWNのフロントエンドリプレイスプロジェクトを主に担当しております。ZOZO DEVELOPERS BLOG でも「ZOZOのリプレイスプロジェクトで得られる唯一無二の経験。大規模サービスを進化させるやりがいとは」というインタビュー記事を掲載しておりますので、もしよろしければこちらも併せてご覧ください。 さて、本題です。現在ZOZOTOWNではオンプレミスかつ、モノリスだった既存システムをマイクロサービスAPIに責務を分割したり、インフラをクラウドに移行したりしています。しかし、いわゆるWebのUIを構築するためのシステムは現在も既存システムに新機能開発や機能改修を行なっており、リプレイスに着手できていませんでした。 そこで、まずホーム画面から段階的にリプレイスすべく設計・開発を昨年から行ない、無事リリースできました。ZOZOT

はじめに こんにちは。計測プラットフォーム開発本部バックエンドチームの佐次田です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。去年の夏に、ZOZOFITというサービスを北米向けにローンチしました。 本記事では、ZOZOFITのローンチまでに遭遇した意思決定における課題と、ADRというドキュメンテーション手法を用いた解決までの取り組みについて紹介します。 目次 はじめに 目次 計測プラットフォーム開発本部 バックエンドチームとは ZOZOFITとは 開発中に直面した課題 過去の背景が分からず決断しにくい 意思決定の結論が追いにくい 意思決定の認識合わせに時間がかかる ADRの導入 ADRとは 展開 ADRのフォーマット 使用ツール チームへの展開 ADRの一例 振り返り 課題はどう解決されたのか メリット デメリット 最後に 計測プラッ

はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの田村です。普段はサーバサイドエンジニアとしてFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。FAANSでは、データベースとしてGCPのサーバレスでドキュメント指向のNoSQLデータベースであるCloud Firestoreを当初採用していました。Cloud Firestoreはサーバレスなので運用負荷が掛からず、また安価でスケーラビリティにも優れたハイパフォーマンスなデータベースです。 しかし、Cloud Firestoreを使用して開発・運用していく中で直面した様々な課題からGCPのフルマネージドのリレーショナルデータベースであるCloud SQLのPostgreSQLにデータベースのリプ

こんにちは、ZOZO NEXTで新規プロダクトの開発を担当している木下です。先日、3Dバーチャル試着に関する実証実験の取り組みが発表されました。3Dバーチャル試着ではユーザーが入力した体型データを基に3Dアバターが作成され、好みのアイテムを選んで着丈やサイズ感を確認できます。 zozonext.com この実証実験のために開発したアプリは、Unity as a Library（UaaL）という技術を利用して実装されています。今回はUaaLをiOSアプリに組み込むにあたって工夫した点を、UX観点も交えながらご紹介します。 Unity as a Libraryとは 背景 UaaLをSwiftで利用するに当たって Unityクラスの実装 AppDelegateでUnityを呼び出す UnityのWindowからViewだけを利用する Unityを一時停止する CollectionViewCell