はてなブックマーク

はじめに こんにちは、ZOZOTOWN開発本部リプレイスバックエンドブロックのばやです。普段はZOZOTOWN BFFのリプレイス開発を担当しています。 システムリプレイスのプロジェクトでは、実装に入る前段階として既存コードの調査が必ず発生します。特にレガシーシステムの場合、ドキュメントが整備されていなかったり、仕様が暗黙知として埋もれていたりすることが多く、コードを読み解くことでしか仕様を把握できないケースも少なくありません。 一方で、この調査フェーズは成果物の形式や進め方が属人化しやすく、プロジェクト全体の生産性に大きな影響を与えるポイントでもあります。調査に時間がかかればプロジェクト全体のスケジュールに影響しますし、調査品質が低ければ後工程での手戻りにつながります。 本記事では、リプレイスにおける既存コード調査の課題に対し、調査業務をテンプレート化しその後、Claude CodeでA

はじめに こんにちは、2025年にiOSエンジニアとして新卒入社したZOZOTOWN開発1部iOSブロックのだーはまです。普段はZOZOTOWNのiOSアプリを開発しています。本記事では、新卒1年目の私がZOZOTOWNの画面へMVVM+UseCaseアーキテクチャを導入した過程と、工夫を紹介していきます。 目次 はじめに 目次 背景と目的 チーム配属から1か月でMVVM+UseCaseアーキテクチャ導入を担当した経緯 デバッグ画面について 課題 コードやドメインに対する知識不足 700行以上に及ぶFatViewController 課題を解決するための取り組み Claude CodeのSubagentsを使いキャッチアップを高速化 MVVM+UseCaseアーキテクチャ導入 結果 デバッグ画面のテストカバレッジ0→93.5％ UI実装をStoryboardからSwiftUIへ完全移行 開

はじめに こんにちは、データシステム部MA推薦ブロックの佐藤（@rayuron）です。私たちは、主にZOZOTOWNのメール配信のパーソナライズなど、マーケティングオートメーションに関するレコメンドシステムを開発・運用しています。本記事では、GitHub Projects、BigQuery、Looker Studioを組み合わせて作業工数を可視化し、改善サイクルを回すための仕組みを構築した取り組みについてご紹介します。 はじめに 背景と課題 1. ボトルネックの特定に手間がかかり改善に着手しにくい 2. 工数に対する事業価値を把握できていない 3. AI活用の効果測定とナレッジの蓄積ができていない 解決策 1. GitHub Projectsの運用整備 カスタムフィールドの作成 自動入力の仕組み 2. データ収集の自動化 BigQueryへのデータ保存 GitHub Actionsで日次エ

はじめに こんにちは、検索基盤部検索研究ブロックの小倉です。普段はZOZOTOWNの検索精度改善を担当しています。検索研究ブロックでは2020年から検索結果の「あなたにおすすめ順」（以降「おすすめ順」と呼びます）とその改善に取り組んできました。その過程で「これまで積み重ねてきた改善は、トータルでどの程度効果があったのか？」を確かめるために、ネガティブテスト（最新のロジックと古いロジックを比較するA/Bテスト）を導入・運用してきました。しかし実際に運用を重ねる中で、ユーザー体験の悪化やロジック改善の機会損失といった問題も見えてきました。本記事では、ZOZOTOWN検索おすすめ順におけるネガティブテストを「導入して効果を測った段階」から「運用を見直すに至った段階」まで、その経緯と学びをご紹介します。 目次 はじめに 目次 背景・課題 ZOZOTOWN検索おすすめ順の改善 「1年間の積み上げ改善

はじめに こんにちは、グローバルシステム部フロントエンドブロックの平田です。 私が所属するチームでは ZOZOMETRYというtoBサービスを開発しています。スマートフォンを用いて身体計測し、計測結果を3Dモデルやデータとして可視化します。計測結果はWeb上で管理できます。 このサービスのフロントエンドではReact（Next.js）を採用しています。さらにそれらの知見を深めるために、NYで開催されたJSNation、React Summit US 2025に参加してきました。 この記事では現地参加ならではの経験や、参加したセッションへの考察などを紹介していきます！ はじめに JSNationとReact Summitとは？ Day 1 - JSNation Day 2 - React Summit After Party 気になったセッションについて The AI-Native Soft

はじめに こんにちは。SRE部会員ID基盤SREブロックの田中です。 ZOZOではマイクロサービスの増加に伴い、昨今高度化するサイバー攻撃に対応しつつ、各システム間のセキュリティとその統一性を維持するための仕組みが求められていました。なかでも、認可基盤の統一は長年にわたる重要な課題のひとつでした。 そこで今回、Istioを活用することで認可機能をアプリケーションから切り離し、ZOZOTOWN共通の認可基盤を実装する方針を採用することにしました。 本記事では、IstioのAuthorizationPolicy機能を利用した認可制御の実装方法について紹介します。 目次 はじめに 目次 Istioとは 課題 Istioを選定した理由 AuthorizationPolicyによる認可制御 AuthorizationPolicyの基本構造 metadata selector（適用対象） action

こんにちは、ZOZOの市橋です。2025年6月にリリースされたマッチングアプリであるZOZOマッチのバックエンド開発を担当しています。本記事では、ZOZOマッチのリアルタイムメッセージング機能を実現するために、AWS AppSyncとGraphQL Subscriptionを活用したアーキテクチャと実装について紹介します。 なお、本記事ではバックエンドのアーキテクチャにフォーカスして解説しますが、ネイティブアプリ側の実装については別記事「ZOZOマッチアプリのメッセージ機能を支えるFlutter × GraphQLの実装」で紹介しています。こちらもご確認いただくことでより理解を深められます。 目次 目次 ZOZOマッチシステム全体の構成 AWS AppSyncとは GraphQLとは AppSyncの基本概念 GraphQLスキーマ Resolver なぜZOZOマッチでGraphQLを採

はじめに こんにちは、ブランドソリューション開発本部プロジェクト推進部PMOブロックの三谷です。普段はPMOとして、ファッションコーディネートアプリ WEARの開発組織が企画を実現する上で発生する様々な課題の解決サポートを行っています。 WEARは2014年のローンチ以来アップデートを繰り返し、様々な機能をリリースしてきました。その中で、1つ1つの案件が大きくなってしまうことがしばしばあり、リリースまでのリードタイムや価値検証のサイクルが長くなりすぎてしまうことがありました。この課題を解決すべく、2024年5月より私たちPMOブロックは開発責任者@tsuwatchのもと、スクラム開発の導入を推進しました。本記事では、スクラム導入におけるPMOの取り組みをご紹介します！ なお、今回ご紹介する内容はWEARのアプリ開発に限った話であり、Webサイトの開発は対象外としています。 目次 はじめに

1. はじめに 検索基盤部 検索基盤ブロックの佐藤（@satto_sann）、岡田（@ryokada33）、SRE部 検索基盤SREブロックの富田（@kei_gnu622）です。 ZOZOTOWNアプリ用に検索機能を提供していたオンプレサーバー上のレガシーなAPIを、約1年かけてクラウド環境へ全面リプレイスしました。 このリプレイスプロジェクトではスパイラル開発の導入や開発初期からの環境整備といった工夫を積み重ねることで、当初のスケジュールどおり移行を完了しています。 また、副次的な効果として、検索速度が約2倍に向上しユーザー体験の改善にもつながりました。 本記事では、大規模リプレイスを円滑に進めるために実践したプロジェクト運営の取り組みを、以下の流れで紹介します。リプレイスをはじめとした、ソフトウェアやマイクロサービス開発プロジェクトの参考になれば幸いです。 【2章】リプレイスプロジェク

はじめに こんにちは、ビジネス・アナリティクス部マーケティング・サイエンスブロックの茅原です。普段はマーケティング施策の効果検証を担当しています。マーケティング・サイエンスブロックではAI協働型分析フロー構築の取り組みをしています。本記事では本取り組みの詳細や、この中で得られた知見をご紹介します。 目次 はじめに 目次 背景・課題 取り組みの紹介 分析環境の標準化 AI活用フロー検証のためのGitHubリポジトリ構築 分析設計書の活用 分析作業フローの定型化 再利用性を高める工夫 文化の醸成 まとめ 背景・課題 近年、生成AIの発達が目覚ましく、開発をはじめとするエンジニアリング組織ではその活用事例が多く見られるようになってきました。一方でデータ分析組織においては、エンジニアリング組織ほど生成AIとの協業事例が見られないという所感があります。これは分析組織にとって、生成AIの持つ不確実性の

はじめに こんにちは、AI・アナリティクス本部データサイエンスブロックの大戸徳仁です。普段は、サービスや機能の現状把握・要因分析、施策の効果検証、需要予測モデルの開発・運用などを担当しています。私が所属するチームでは、「データに基づいた意思決定を支援すること」をミッションに、社内の各部門に対してデータ分析サービスを提供しています。 その取り組みの一環として、ZOZOの物流拠点「ZOZOBASE」のデータ活用に取り組んでいます。中でも、出荷計画や人員配置の判断材料となる「注文数の予測」については、予測精度が安定しない、予測工数がかかるといった課題があります。本記事では、これらの課題に対してどのようにアプローチしたのか、そしてプロジェクトを通じて得られた気づきについて紹介します。 目次 はじめに 目次 背景 課題 課題解決アプローチ 1.評価指標の設計 2.EDA（探索的データ分析） 3.予測

はじめに こんにちは、EC基盤開発本部SRE部の金田、花房、松石です。普段はSREとしてZOZOTOWNのインフラ運用や開発を担当しています。 ZOZOではgatling-operatorをOSSの負荷試験ツールとして公開・運用してきました。しかし、Gatling本体の破壊的変更やメンテナー不足といった課題に直面し、新たな負荷試験ツールとしてk6の導入を進めています。 本記事では、gatling-operatorが抱えていた課題と、k6への移行に至った経緯、そしてClaude Codeを活用した既存シナリオの移行方法についてご紹介します。 目次 はじめに 目次 背景・課題 gatling-operatorとは Gatlingの破壊的変更 Gatling 3.11での変更 Gatling 3.12での変更 メンテナー不足 検討した対応策 なぜk6を採用したのか 要件 k6を採用した理由 導入

はじめに こんにちは、SRE部 検索基盤SREブロックの花房です。2025年12月11日に東京の虎ノ門で開催された「OpenSearchCon Japan 2025」にZOZOのエンジニア5人が参加しました。本記事では、会場の様子と印象に残ったセッションについて紹介します。 はじめに OpenSearchCon Japanとは 会場の様子 セッションレポート Maximize Resource Efficiency with Separated Index and Search Workloads 課題 解決策: ワークロードの物理的分離(Reader-Writer Separation) Remote Store(S3など)でデータの共有を実現 感想 Intelligent Japanese Search With OpenSearch 感想 Lessons From Migrating

はじめに こんにちは、「ZOZOMO」のブランド実店舗の在庫確認・在庫取り置き機能の開発を担当しているZOZOMO部OMOブロックの木目沢です。先日、プロダクト開発メンバーとビジネスメンバー合同で2日間の「ユーザーストーリー」ワークショップを開催しました。 1日目は「キャンプ」を題材にユーザーストーリーの型と会話を体験し、2日目は実際のZOZOMO店舗在庫取り置きでユーザーストーリーを書き、優先順位を決めて実際に開発するところまで行いました。 この記事では、その2日間をまとめて振り返ります。 目次 はじめに 目次 開発チームの課題感と、ワークショップのねらい なぜ「ユーザーストーリー」なのか？ 1日目：キャンプでユーザーストーリーの型を体験する メインワーク１：キャンプで“WHAT”を考える メインワーク２：WHYを考える──価値の核心を探る メインワーク３：WHAT/WHYを“実現したと

こんにちは、プロダクト戦略部の土屋です。普段はFAANS（アパレル店舗で働くショップスタッフ向けの業務支援ツール）のプロダクトマネジメントを担当しています。 「新しいことをやりたいけれど、既存タスクで手一杯」プロダクト開発の現場では、こうした状況は珍しくありません。特に、特定の領域や役割にタスクが偏りやすい構造的な課題を抱えた組織では、新しいチャレンジが後回しになってしまうケースも多いのではないでしょうか。 この記事では、チーム内のリソースの偏りという組織的な課題に対して、私たちが取り組んだ「PoC専用開発レーン」の設計と運用についてご紹介します。設計思想から開発フローまで具体的な内容をお伝えできればと思います。 FAANSの開発チームについて FAANSの開発チームは、バックエンド、フロントエンド（Web/iOS/Android）、デザイン、プロダクトマネジメントの各専門領域で構成されて

はじめに こんにちは、ZOZOMO部SREブロックの中村です。普段はZOZOMOのSREを担当しています。 本記事では、ECS on FargateにPipeCDを導入してGitOpsベースのデプロイ基盤を構築した取り組みをご紹介します。デプロイ経路の複数存在による管理の煩雑さと、段階的デプロイができない課題をPipeCDでどのように解決したかを解説します。 本記事がECS on Fargateを運用していてGitOps化に興味がある方や、PipeCDの導入を検討している方の参考になれば幸いです。 目次 はじめに 目次 導入前の課題 デプロイ経路の複数存在による管理の煩雑さ 段階的デプロイができない 解決アプローチ PipeCDとは 導入構成 実装 Control Planeの構築 Control Planeの初期設定 Pipedの構築 マニフェストファイルの構成 アプリケーションの登録

はじめに こんにちは。ブランドソリューション開発本部WEARバックエンド部SREブロックの和田です。 普段はWEARのSREチーム（以下、WEARSRE）に所属し、開発や運用に加えて、ここ3年ほどはマネージャーとしてチーム運営にも携わっています。 WEARSREは発足以来、クラウドを活用した課題解決に取り組んできました。その一方で、10年以上稼働し続けているオンプレミス環境の運用については、長らく他部署に任せきりの状態が続いていました。 プロダクト専任のSREチームでありながら、システム全体にアプローチできていない。この矛盾を解消すべく、私たちはオンプレミス環境への関与を少しずつ拡大し、最終的に自チームでの運用を実現しました。 本記事では、これら一連の取り組みを振り返りつつ、チームの成長と現場で得られた気づきをご紹介します。 目次 はじめに 目次 これまでの取り組み 取り残されたオンプレミ

はじめに こんにちは。ZOZOTOWN開発本部プロダクト戦略部Tech-PMの高橋です。普段はZOZOTOWNの新機能開発、改善に関わりながらPMとしてプロダクトの開発進行を担当しています。 今回は、2023年11月にリリースした「アイテムレビュー機能」にまつわる、約2年間のプロジェクトの裏側とリリース後に直面した課題、そしてどのように改善を進めていったかをまとめました。 待望のアイテムレビュー機能、ついにリリース ZOZOTOWNでは以前から、お客様・ショップ様双方からレビュー機能の追加を求める声が多く寄せられていました。しかし、監視体制、ブランド様の意向、開発規模など、越えるべきハードルが多く、長年リリースできずにいた背景があります。 そんな中、2023年11月29日、ついに念願のレビュー機能を公開しました。リリース後Xの反応でも「やっと付いた！」「助かる！」という声が多く、ポジティブ

はじめに こんにちは、WEARフロントエンド部iOSブロックの西山です。普段はWEAR iOSチームのマネジメント兼アプリの開発を担当しています。今年のWWDC25で、新しいソフトウェアデザインのLiquid Glassが発表されました。透明感のあるUIと流動的なアニメーションが特徴的なこの新デザインは、WEARアプリに大きな影響を与えました。鋭意進行中の取り組みとして、本記事では、Liquid Glass対応を計画的に進めるための取り組みを紹介します。 目次 はじめに 目次 Liquid Glassとは 課題 UIが大きく変わることでデザイン崩れが発生 タブバー タブバーの裏側にコンテンツが透過しない タブバーとコンポーネントが被る ナビゲーションバー ボタンに枠がつく ナビゲーションバーの下に配置してあるコンポーネントとの一体感を失う その他のコンポーネント Switchが大きくなった

はじめに こんにちは、EC基盤開発本部SRE部の杉山です。普段はSRE部のテックリードを務めています。 本記事では、2024年10月〜2025年4月に実施した、オブザーバビリティ製品移行の実現可能性を検証するPoC（Proof of Concept）について、その検証観点や分かったことを紹介します。 目次 はじめに 目次 前提 背景 目的 PoCチーム フェーズ/スケジュール Ph.1 機能検証について 検証対象の機能一覧 課題と対応 対応策 機能検証まとめ Ph.2 運用検証について 運用フローの変更 Traceの見え方 IaC化についての移行コスト 運用検証まとめ まとめ 前提 ※本記事の内容は、2024年10月〜2025年4月に実施したPoCの検証結果に基づいています。記載している機能や挙動は当時のバージョンでの確認内容であり、今後のアップデートにより変更される可能性があります。 背

はじめに こんにちは。ZOZOTOWN開発本部の齋藤（@Jin_Pro_01）です。 2025年8月26日にちょっと株式会社さんと共同で「ちょっと株式会社×株式会社ZOZO フロントエンド合同勉強会」をクローズドイベントとしてオンラインで開催しました。両社におけるフロントエンドを用いたプロダクト開発における具体的な事例を共有し、課題解決の糸口を見つけるきっかけや両社のエンジニアの知見を深めることを目的として開催しました。当日は両社合わせて50名以上の方に参加いただき、大変貴重な機会となりました。 この記事ではまず当日の勉強会の内容について紹介し、その後に運営する中での工夫や得た学びについて共有します。 登壇内容まとめ 本勉強会のファシリテーションはちょっと株式会社さんの西村さんにご担当いただき、両社から次の4名が登壇しました。 発表タイトル 登壇者 最近のNext.jsのことはなにもわから

はじめに こんにちは、情報セキュリティ部SOCブロックの大山です。普段はSOC業務、いわゆる「守る側」の業務を担当しています。攻撃者視点の理解をより深めることで、検知の質や対応手順の説得力を高めることを目的に、OffSec社が提供する「OSCP+」および「OSCP」を受講し、それぞれ資格試験に合格しました。 本記事では、同じブロックの兵藤と共同で受講から合格までの流れや学び、実務への還元ポイントをまとめて紹介します。 目次 はじめに 目次 背景・課題 OSCPについて 試験形式（OSCP+） OSCPとOSCP+の関係 学習リソース 試験までの準備 学習リソースと時間配分 試験 1回目（不合格） 2回目 結果発表 学習・演習・実技試験から得た知見のSOCへの還元 各メンバーのトリアージ精度の向上（SIEM/EDR観点） 検知ルールの拡張・更新 ハードニング（設定強化）の取り組み まとめ 背

はじめに こんにちは、ECプラットフォーム部マイクロサービス戦略ブロックの半澤です。2025年11月15日（土）に「JJUG CCC 2025 Fall」が開催されました。ZOZOはブーススポンサーとして協賛し、ブースを出展しました。 JJUGは、日本におけるJava技術の向上・発展と一層の普及・活性化を目指して設立された、ボランティアメンバーで運営される日本のJavaユーザーコミュニティです。CCCは、JJUGが主催する「Javaに閉じず」「技術に閉じず」オープンソースを中心とする様々なコミュニティから参加者を募って、コミュニティを横断した「クロスコミュニティなカンファレンス」です。 ZOZOTOWNでは、かつてVBScriptによって構築されていたシステムから、段階的にJavaへの移行を進めています。現在は、カート決済基盤、ショップ直送基盤、検索基盤、基幹システムなど、多くの領域でJa

はじめに こんにちは、データ・AIシステム本部データシステム部推薦基盤ブロックの関口 柊人です。普段はZOZOTOWNのレコメンドシステムの開発やHOME面の改善などに取り組んでいます。 ECサービスにおいて「何を成功指標とするか」は、サービスの方向性を決める重要な要素です。ZOZOTOWNのHOME面も例外ではなく、従来は売上やCTRといった短期的な指標を中心に改善してきました。しかし複数チームでの運用が拡大し、レコメンドシステムの高度化が進む中で、推薦基盤チームとして「短期指標だけではユーザー体験を十分に捉えられていないのではないか」という課題感が徐々に強まりました。 短期的な売上最適化だけでは見落としてしまう価値があるのではないでしょうか。ユーザーの長期的な満足度やサービスへの愛着といった要素をどう測り、育てていくべきでしょうか。 本記事では、こうした課題意識から始まったZOZOTO

はじめに こんにちは、データ・AIシステム本部データシステム部データ基盤ブロックの栁澤（@i_125）です。私はデータ基盤の安定化・効率化を目指しつつ、Analytics Engineerとしてデータ利活用領域にも踏み込み、データマート整備やLooker周辺の整備・サポートに取り組んでいます。本記事では、Lookerダッシュボードに生成AIによる要約機能を組み込んだ「Gemini in Looker」の活用事例をご紹介します。 目次 はじめに 目次 背景 Gemini in Lookerとは 概要 標準機能とLooker Extension アーキテクチャ全体像とデータフロー システム構成 セキュリティ上の重要な設計判断 実際のデータフロー（安全な設計） もしCloud Run側から呼び出していたら（危険な設計との比較） User AttributeとAccess Filterによる権限制

はじめに こんにちは。データシステム部・推薦基盤ブロックの上國料（@Kamiko20174481）です。私たちのチームは、ZOZOTOWNの推薦システムを開発・運用し、ユーザー一人ひとりに最適な購買体験を届けることを目指しています。 これまでは施策ごとに推薦システムをゼロベースで構築していたため、施策実施までのリードタイムが長く、推薦システムの運用負荷も高まりやすいという課題がありました。この課題を解決するために、ユーザーや商品をEmbedding（埋め込みベクトル）として表現し、それらを一元的に管理して複数の推薦施策で再利用できる仕組みの構築に取り組みました。以降では、この仕組みをEmbedding基盤と呼称します。 本記事では、この取り組みの背景となった課題とEmbedding基盤の設計方針・アーキテクチャ、導入後の知見を紹介します。同様の課題に取り組む方々の参考になれば幸いです。 目

はじめに こんにちは。ZOZOTOWN開発本部フロントエンドの菊地（@hiro0218）です。 2021年、ZOZOTOWNはフロントエンドリプレイスを開始しました。現在、ホームページや商品一覧ページなど主要なページのNext.js化が完了し、運用フェーズに入っています。詳細は以下の記事を参照してください。 techblog.zozo.com 開始当初、他社事例を参考にしながら、よくある課題を未然に防ぐディレクトリ構成を設計しました。本記事では、約4年にわたる運用で改善を重ねてきたディレクトリの分割戦略について紹介します。 ※本記事は2025年8月にちょっと株式会社との合同勉強会で発表した内容を基にしています。 speakerdeck.com 背景 現在、私が携わっている領域におけるフロントエンド開発は4チーム、合計30名強で運用しています。この規模で効率的に開発を進めるため、ディレクトリ

はじめに こんにちは、SRE部プラットフォームSREブロックのさかべっちです。2025年度に新卒で入社しました。普段はZOZOTOWNにおけるプラットフォーム基盤の運用・改善を担当しています。 本記事では、Istio Operatorが非推奨となったことを受けて、サービス断を一切発生させることなくHelmへの移行を完遂させた取り組みをご紹介します。移行作業で直面した技術的な課題とその解決方法について、実際の経験をもとに解説します。 目次 はじめに 目次 背景 移行方針 移行戦略と2つの重要なポイント ポイント1: サービス断は絶対NG ポイント2: いかに工数を最小限に抑えるか 各移行先の比較検討 技術的な課題と解決方法 課題1: Istio OperatorとHelmのリソース競合 課題2: Helm Chartで提供されない項目の設定方法 課題3: Istio Operatorをいかに