Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
漸進。
Search
TOMIKAWA Sotaro
May 29, 2025
Programming
0
3.1k
漸進。
TOMIKAWA Sotaro
May 29, 2025
Tweet
Share
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
なんでRustの環境構築してないのにRust製のツールが動くの? / Why Do Rust-Based Tools Run Without a Rust Environment?
ssssota
13
44k
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
2k
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
2.9k
useSyncExternalStoreを使いまくる
ssssota
6
5.9k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.5k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
240
脱法Svelte / Evasion of svelte rules
ssssota
1
250
Documentation testsの恩恵 / Documentation testing benefits
ssssota
2
1.1k
TypeScriptとDocumentaion tests / Documentation tests with TypeScript
ssssota
8
4k
Other Decks in Programming
See All in Programming
Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地
imkaoru
4
890
Webサーバーサイド言語としてのRustについて
kouyuume
1
4.7k
CSC305 Lecture 10
javiergs
PRO
0
230
Pythonに漸進的に型をつける
nealle
1
120
その面倒な作業、「Dart」にやらせませんか? Flutter開発者のための業務効率化
yordgenome03
1
140
TFLintカスタムプラグインで始める Terraformコード品質管理
bells17
2
360
3年ぶりにコードを書いた元CTOが Claude Codeと30分でMVPを作った話
maikokojima
0
630
Claude Agent SDK を使ってみよう
hyshu
0
1.4k
モテるデスク環境
mozumasu
3
1.2k
Six and a half ridiculous things to do with Quarkus
hollycummins
0
210
Building, Deploying, and Monitoring Ruby Web Applications with Falcon (Kaigi on Rails 2025)
ioquatix
4
2.5k
実践Claude Code:20の失敗から学ぶAIペアプログラミング
takedatakashi
18
8.3k
Featured
See All Featured
Navigating Team Friction
lara
190
15k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6k
The Straight Up "How To Draw Better" Workshop
denniskardys
238
140k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
Java REST API Framework Comparison - PWX 2021
mraible
34
8.9k
Agile that works and the tools we love
rasmusluckow
331
21k
Writing Fast Ruby
sferik
630
62k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Rails Girls Zürich Keynote
gr2m
95
14k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
930
The Cult of Friendly URLs
andyhume
79
6.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Transcript
漸進。 株式会社ZOZO ブランドソリューション開発本部 WEARフロントエンド部 Webブロック 冨川 宗太郎 Copyright ©
ZOZO, Inc. 1
© ZOZO, Inc. 株式会社ZOZO ブランドソリューション開発本部 WEARフロントエンド部 Webブロック 冨川 宗太郎 2022年新卒で株式会社ZOZOに入社。
WEAR by ZOZOのWebフロントエンド開発に従事。 フロントエンド領域のテックリードを務める。 2
© ZOZO, Inc. https://wear.jp/ 3 • あなたの「似合う」が探せるファッションコーディネートアプリ • 1,800万ダウンロード突破、コーディネート投稿総数は1,400万 件以上(2025年3月末時点)
• コーディネートや最新トレンド、メイクなど豊富なファッション 情報をチェック • AIを活用したファッションジャンル診断や、フルメイクをARで試 せる「WEARお試しメイク」を提供 • コーディネート着用アイテムを公式サイトで購入可能 • WEAR公認の人気ユーザーをWEARISTAと認定。モデル・タレン ト・デザイナー・インフルエンサーといった各界著名人も参加
© ZOZO, Inc. 4 WEAR Webが抱えていた負債 WEARは10年近く運用されてきたプロダクト。 オンプレミスのIISサーバーでVBScriptが動作しjQueryで動きを作っていた。 VBScriptでは独自のテンプレートフレームワークが動き、 Node.jsなどという高尚なツールは使わず手作業でminify/リリースし、
仕様はドキュメント化されていなかった。 →リリース時のミス・時間がかかる 技術スタックの時が10年以上昔で止まっていた。
© ZOZO, Inc. 5 ただし敵ではない 10年近く運用され、多くのユーザーに価値を提供してきた。 VBScriptも独自フレームワークもよくわからないが、動いている。 旧環境は負債であっても、敵ではない。 コードと開発者に敬意を忘れない。蔑ろにすると痛い目を見る。
© ZOZO, Inc. 6 リプレイスという名の再建 リプレイスのゴールは「いまあるものを0に、あたらしいものを100にする」。 と聞くとすべてエイヤで置き換えたくなる。(通称ビッグバンリライト) よく知られた話ではあるが、 ビッグバンリライトはよほどの理由がない限り避ける
© ZOZO, Inc. 7 ビッグバンリライトはダメ(一般論) ビッグバンリライトを避けるべき理由は以下の通り: • 完遂できなかった場合、進捗が0になる • 完遂できても、
◦ 一度に作り切るので設計が洗練されない ◦ 新たな負債へ • スケジュールが立たない・守れない • 仕様の見落とし • 新機能開発が止まる • etc... ※ただしやむを得ない場合や圧倒的腕力がある場合はこの限りではない
© ZOZO, Inc. 8 すこしずつリプレイスするために 1 とにかく旧環境を触り、コードを読む。 仕様がドキュメントにないなら尚更、仕様があっても未知の仕様を拾う。 拾った情報を仕様書やコードに落とす。 (可観測性のためのコードが仕様書に載っていなかったり...)
ただし、すべてをフォローする必要もない。明らかな無駄は積極的に省く。
© ZOZO, Inc. 9 すこしずつリプレイスするために 2 漸進的な適用方法を考える。 ビッグバンリライトをしない、という話の延長線。 • コンポーネントレベルでの適用:
「フッターのみ」など • ページ(URL)単位での適用: 「/privacy のみ」など いかに小さく始められるかを常に考える。
© ZOZO, Inc. 10 すこしずつリプレイスするために 2 WEARでは、CDN(Fastly)を置きパスルーターにした。 実装+テストが完了したページから順次切り替え。
© ZOZO, Inc. 11 開発者体験に投資する。 CI/CD、静的解析(TypeScript, ESLint)、テスト、自動化。 すべてを最初から100点にする必要はないが、60点を切らないように常に改善。 あくまでも投資なので、すぐに結果がでなくても良い。 すこしずつリプレイスするために
3
© ZOZO, Inc. 12 • リプレイスは既存のコードを変形するだけで済む箇所もあるので、 変形のためのスクリプトを用意する ◦ 万人に役立つスクリプトじゃ無くていい ◦
リプレイスのためのものはそうそう都合よく公開されていない • リンターでは拾いきれないコーディングルールを明文化する ◦ カスタムルールをサッと書けるならそうする すこしずつリプレイスするために 3
© ZOZO, Inc. 13 負債にしないために 1 プロダクトのコードは、その瞬間だけでも自分の中での100点を追求する。 コードは知らないうちに劣化し減点されていく。 ライブラリには脆弱性が見つかり、新しいAPIが追加される。 人間は常にアップデートされて、コード自体変わっていなくても100点に見えな
くなる。 数年前に自分が書いたコードを見て、なにもわからなくなる。
© ZOZO, Inc. 14 負債にしないために 1 「来た時よりも綺麗に」を意識し、劣化が目立つところは適宜改善を重ねる。 (ただし機能追加とリファクタリングの変更は分ける) 命名には最大限の注意を払う。命の名前。名は体を表す。 AIに聞くもよし、著名なライブラリを参考にするもよし。
WEARチームでは輪読会も有効だった。 • 良いコード/悪いコードで学ぶ設計入門 • Good Code, Bad Code ~持続可能な開発のためのソフトウェアエンジニア的思考 • HTML解体新書-仕様から紐解く本格入門
© ZOZO, Inc. 15 負債にしないために 2 ライブラリは極力最新に追従し続ける。 ひとつひとつの差分は小さくても「塵も積もれば山となる」ので、 まとめてやったほうが楽などということはない。 WEAR
WebチームではRenovateのPRごとにランダムでメンバーがアサインされ 基本一週間以内に確認・マージ・リリースまで行う。 ライブラリに対するアンテナとしても機能する。
© ZOZO, Inc. 16 負債にしないために 3 腐敗防止層(ACL)を意識する。 DDDを導入しましょうでは無く、 特にライブラリを差し替えられるように意識する。 例えば日付のフォーマット。Intlの実装状況でライブラリが不要になるかも。
© ZOZO, Inc. 17 負債にしないために 4 フットワークの軽さを確保する。 リリースの頻度が少ないと、リリースの変更が大きくなる。 →変更箇所が多いと、バグを埋め込んだ時に原因が特定しづらくなる →原因が特定しづらいと、変更を恐れるようになる
変更はこまめにリリース、異変を見つけたらすぐに引き返す。 機能フラグ(フィーチャーフラグ)を積極的に活用して、 開発途中の機能でも非公開でリリースするなど。
© ZOZO, Inc. 18 負債にしないために 4 フットワークの軽さを確保する。 そのために、タスクの粒度を細かくする。 IssueやPull Requestを細かくすることで変更内容を把握しやすくする。
レビュー負担軽減により開発速度の向上にもつながる。 ただし、細かすぎは前後関係が途切れるので注意が必要。 やりながらラインを見極める。
© ZOZO, Inc. 19 もし「PHPやRuby on Railsを剥がしてReactにしたいです」と言われたら? ここまで確認してきたように、 1. 旧環境に敬意を持つ
(過信は禁物) 2. 少しずつ確実に進める(必要に応じ並行して機能開発もする) 3. 開発の基礎を守る リプレイスをすることになったら
© ZOZO, Inc. 20 全てを一度に良くすることはできないので、一歩ずつ確実にコトを進めましょう リプレイスじゃなくても
None