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
2.9k
漸進。
TOMIKAWA Sotaro
May 29, 2025
Tweet
Share
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
2.8k
useSyncExternalStoreを使いまくる
ssssota
6
5.7k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.4k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
210
脱法Svelte / Evasion of svelte rules
ssssota
1
230
Documentation testsの恩恵 / Documentation testing benefits
ssssota
2
1.1k
TypeScriptとDocumentaion tests / Documentation tests with TypeScript
ssssota
8
4k
Svelteでライブラリを作る / Make your library with Svelte
ssssota
0
180
現代のReactivityとSvelteの魔法
ssssota
0
2.3k
Other Decks in Programming
See All in Programming
AI時代のドメイン駆動設計-DDD実践におけるAI活用のあり方 / ddd-in-ai-era
minodriven
23
9k
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
なぜ今、Terraformの本を書いたのか? - 著者陣に聞く!『Terraformではじめる実践IaC』登壇資料
fufuhu
4
660
私の後悔をAWS DMSで解決した話
hiramax
4
140
技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
rvirus0817
1
2.2k
A Gopher's Guide to Vibe Coding
danicat
0
170
WebAssemblyインタプリタを書く ~Component Modelを添えて~
ruccho
1
920
UbieのAIパートナーを支えるコンテキストエンジニアリング実践
syucream
2
730
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
190
「リーダーは意思決定する人」って本当?~ 学びを現場で活かす、リーダー4ヶ月目の試行錯誤 ~
marina1017
0
240
Langfuseと歩む生成AI活用推進
licux
3
300
AIでLINEスタンプを作ってみた
eycjur
1
200
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.8k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
820
How to train your dragon (web standard)
notwaldorf
96
6.2k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Practical Orchestrator
shlominoach
190
11k
The World Runs on Bad Software
bkeepers
PRO
70
11k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Music & Morning Musume
bryan
46
6.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
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