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.2k
漸進。
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.7k
useSyncExternalStoreを使いまくる
ssssota
6
5.5k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.1k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
180
脱法Svelte / Evasion of svelte rules
ssssota
1
210
Documentation testsの恩恵 / Documentation testing benefits
ssssota
2
1k
TypeScriptとDocumentaion tests / Documentation tests with TypeScript
ssssota
8
3.9k
Svelteでライブラリを作る / Make your library with Svelte
ssssota
0
160
現代のReactivityとSvelteの魔法
ssssota
0
2.2k
Other Decks in Programming
See All in Programming
FormFlow - Build Stunning Multistep Forms
yceruto
1
190
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.2k
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
240
5つのアンチパターンから学ぶLT設計
narihara
1
110
Select API from Kotlin Coroutine
jmatsu
1
190
Team operations that are not burdened by SRE
kazatohiei
1
180
ReadMoreTextView
fornewid
1
470
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
480
GitHub Copilot and GitHub Codespaces Hands-on
ymd65536
1
110
Beyond Portability: Live Migration for Evolving WebAssembly Workloads
chikuwait
0
390
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
130
関数型まつり2025登壇資料「関数プログラミングと再帰」
taisontsukada
2
850
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
Side Projects
sachag
455
42k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
Unsuck your backbone
ammeep
671
58k
Facilitating Awesome Meetings
lara
54
6.4k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
The Invisible Side of Design
smashingmag
299
51k
Rails Girls Zürich Keynote
gr2m
94
14k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Fireside Chat
paigeccino
37
3.5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
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