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
3k
漸進。
TOMIKAWA Sotaro
May 29, 2025
Tweet
Share
More Decks by TOMIKAWA Sotaro
See All by TOMIKAWA Sotaro
Web技術を最大限活用してRAW画像を現像する / Developing RAW Images on the Web
ssssota
2
1.1k
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
2.8k
useSyncExternalStoreを使いまくる
ssssota
6
5.8k
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
8
5.5k
新しいAPI createRawSnippet触ってみた / What is the createRawSnippet?
ssssota
2
230
脱法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
Other Decks in Programming
See All in Programming
iOS 17で追加されたSubscriptionStoreView を利用して5分でサブスク実装チャレンジ
natmark
0
480
気づいて!アプリからのSOS 〜App Store Connect APIで始めるパフォーマンス健康診断〜
waka12
0
260
CSC509 Lecture 01
javiergs
PRO
1
430
Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し / Bridging with Web Components
da1chi
3
1.5k
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
860
Swift Concurrency - 状態監視の罠
objectiveaudio
2
430
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
870
株式会社 Sun terras カンパニーデック
sunterras
0
180
PostgreSQLで手軽にDuckDBを使う!DuckDB&pg_duckdb入門/osk2025-duckdb
takahashiikki
1
230
Pull-Requestの内容を1クリックで動作確認可能にするワークフロー
natmark
1
420
ネイティブ製ガントチャートUIを作って学ぶUICollectionViewLayoutの威力
jrsaruo
0
120
NetworkXとGNNで学ぶグラフデータ分析入門〜複雑な関係性を解き明かすPythonの力〜
mhrtech
3
950
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
How to Ace a Technical Interview
jacobian
280
23k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.6k
Become a Pro
speakerdeck
PRO
29
5.5k
It's Worth the Effort
3n
187
28k
How to Think Like a Performance Engineer
csswizardry
27
2k
Facilitating Awesome Meetings
lara
56
6.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Designing for humans not robots
tammielis
254
25k
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