Share
Embed
Slide 1
Slide 1 text
17周年のWebアプリケーションに
TanStack Queryを導入する
さいと / Muddy Web #10
Slide 2
Slide 2 text
自己紹介
● 2022年新卒入社 (3年目)
● フロントエンドエンジニア
● 最近CloudflareとHonoが熱い
● ポケモンカードが好き
さいと @saitolume
Slide 3
Slide 3 text
“好き”に出会えるイラスト・マンガ・小説作品の
投稿プラットフォーム
サービス開始日 2007年9月10日
登録ユーザー数 約1億ユーザー
累計投稿作品数 約1億4000万作品
Slide 4
Slide 4 text
● 変えることは難しい
● でも、変えられる
● 変えるためには泥臭く (Muddyに) 課題に向き合うことも必要
今日伝えたいこと
Slide 5
Slide 5 text
アジェンダ
● pixivの歴史と負債
● 変える
● 課題と向き合う
● 事例: 非同期データ管理ライブラリの導入
Slide 6
Slide 6 text
pixivの歴史と負債
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
● 2007年 pixiv誕生
○ 個人サイトや掲示板からSNSの時代へ
○ 動的なコンテンツを扱うためPHPとSmartyで実装
pixivの歴史と負債
Slide 9
Slide 9 text
● 2010年 pixiv touch誕生
○ ガラケーからスマホの時代へ
○ スマホに最適化するために新規で実装
pixivの歴史と負債
Slide 10
Slide 10 text
● 2018年 SPA移行
○ 仮想DOMによる高速なレンダリングが可能なライブラリ・フレー
ムワークが台頭
○ デスクトップはReactを採用
○ モバイル (touch) はVue.jsを採用
pixivの歴史と負債
Slide 11
Slide 11 text
● 2022年 大統一時代
○ デスクトップとモバイルの実装が分離していることによる生産性
の低さが課題に
○ 解決するためにレスポンシブデザインの実装が増加する
○ Next.jsに移行して実装を統合するプロジェクトが始動
pixivの歴史と負債
Slide 12
Slide 12 text
● 2024年 現在
○ Smarty、React、Vue、Next.jsの4つの実装が存在
○ 各時代で移行しきれなかったコードが断層のように残っている
○ それぞれを切り取って見るとうまくいっていそうだったが、振り返
ると負債になっている
pixivの歴史と負債
Slide 13
Slide 13 text
● 課題
○ 実装が分散しているため作業量が多い
○ 1億人以上のユーザーに影響を与える可能性がある
○ テストが不足している
○ フロントエンドエンジニアが各チームに分散している
○ 相談先や相談する場所がない
pixivの歴史と負債
Slide 14
Slide 14 text
変える
Slide 15
Slide 15 text
● ソフトウェアエンジニアはスペシャリスト
● 要求に応じて、より早くより高い質で変えることが求められる
● プラットフォームには様々な要求が発生する
○ ユーザーの声、プロダクトの方針
○ 技術革新、法令対応、決済リスク
変える
Slide 16
Slide 16 text
● 17周年を迎えたpixivは変更容易性が低い状態
● 変えることは難しい
変える
Slide 17
Slide 17 text
● 課題
○ 実装が分散していて作業量が多い
○ 1億人以上のユーザーに影響を与える可能性がある
○ テストが不足している
○ フロントエンドエンジニアが各チームに分散している
○ 相談先や相談する場所がない
pixivの歴史と負債 (再掲)
Slide 18
Slide 18 text
課題と向き合う
Slide 19
Slide 19 text
● ゴールを「変更容易性を手に入れること」とする
● 何を得られると変えられるようになるのか
○ 人月
○ 堅牢な設計
○ テスト
○ ？？
課題と向き合う
Slide 20
Slide 20 text
● pixivに最も必要だったものは「合意」
○ 1つのプロダクトを複数のチームで開発している
○ 個人やチームで完結できない
○ 変えるときにやっていいのか不安になる
○ いざやってみても手戻りが発生するリスクがある
課題と向き合う
Slide 21
Slide 21 text
● 失敗事例
○ 2023年末にApp Routerを導入しようとした
○ 一部ページを移行する実装のレビューをお願いしたときに、設計
で折り合いがつかなかった
○ 凍結へ
課題と向き合う
Slide 22
Slide 22 text
● 合意に必要なもの
○ 意思決定の仕組み
○ 意思決定の場所
課題と向き合う
Slide 23
Slide 23 text
意思決定の仕組み
Slide 24
Slide 24 text
● Architecture Decision Record (ADR) を導入
● ソフトウェア開発における意思決定を文書化する手法
● 文脈、選択内容、選択理由などを記録
● 後から辿ることができる
○ “なぜフェンスが建てられたのかわかるまで、決してフェンスをと
りはずしてはならない”
意思決定の仕組み
Slide 25
Slide 25 text
● ルール
○ 開発者全員が提案・コメントできる
○ 提案者は提案に責任を持って進行する
○ 提案内容は同期的に意思決定される (後述)
意思決定の仕組み
Slide 26
Slide 26 text
● テンプレート
○ 文脈: どのような状況で選択が迫られているか
○ 選択: 意思決定の内容
○ 比較・検討: 事実ベースで選択に必要な情報をまとめる
○ 結果: 意思決定がシステムやメンバーに与える影響
意思決定の仕組み
Slide 27
Slide 27 text
● 変えるためのレールが敷かれた
○ レールに乗って進めば変えられる！
○ わかりやすくなった
○ やることが減った
○ 心理的なハードルが低くなった
意思決定の仕組み
Slide 28
Slide 28 text
意思決定の場所
Slide 29
Slide 29 text
● フロントエンドエンジニアが集まって同期的に話す会を開催
○ 隔週
○ 誰でも参加可能
○ 最大30分
○ トピックがないときは解散
意思決定の場所
Slide 30
Slide 30 text
● テンプレート
○ 前回までの宿題
○ 今週の議題
○ 更新・追加された開発マニュアルの確認
○ 提案中のADRの確認
意思決定の場所
Slide 31
Slide 31 text
● 場所ができると人が集まってくる
○ 今までは別チームにいて議論することが少なかった人も
○ 関心が可視化されて雰囲気が良くなった
○ カイゼンに伴う孤独感が薄れる
意思決定の場所
Slide 32
Slide 32 text
● 納得感
○ オープンな場所で透明性がある
○ 関心のあるメンバーが集まっている
○ 「フロントエンドで悩んだらあそこで決めよう」
意思決定の場所
Slide 33
Slide 33 text
● 実績
○ ちょうど1年間継続 (計23回開催)
○ 62件のトピックを議論
○ 11人がトピックを起票
○ 25件の意思決定をサポート
意思決定の場所
Slide 34
Slide 34 text
事例: 非同期データ管理ライブラリ
Slide 35
Slide 35 text
● 2023年5月 Slackではじめて言及される
○ 当時はADRも会もなかったので話が進まない
● 2024年2月 会のトピックに上がる
● 2024年4月 ？？
● 2024年5月 検討を再開
● 2024年8月 承認・導入 🎉
事例: 非同期データ管理ライブラリ
Slide 36
Slide 36 text
● 検討から導入まで3ヶ月かかった
● 最初は隔週の会だけで話していて期間が空いてしまった
● 主務の部署の業務が優先されるため、優先度が下がりがち
● 開発者によって選択肢に好みがある
○ SWR、TanStack Query、RTK Queryなど
○ 納得感の醸成が必要
事例: 非同期データ管理ライブラリ
Slide 37
Slide 37 text
● 隙間時間を活用してプロトタイピング
○ ライブラリごとの違いを客観的に評価
○ コードを見ながら議論する
● 目的と手段を見比べる
○ 例えば、目的の1つに「Reduxをやめたい」もある
○ RTK QueryだとReduxへの依存をやめられない
事例: 非同期データ管理ライブラリ
Slide 38
Slide 38 text
● 結論
○ TanStack Queryを選択
● 理由
○ クエリ単位で抽象化ができる
○ context.metaを活用できる
○ SWRは既存のAPIクライアントクラスと相性が悪かった
○ など
事例: 非同期データ管理ライブラリ
Slide 39
Slide 39 text
● 意思決定の仕組みと場所があるおかげで話を進められた
● ADRで選択肢の比較と意思決定の記録ができた
● 会が定期的に開かれていることで気軽に提案できる
事例: 非同期データ管理ライブラリ
Slide 40
Slide 40 text
● 2023年5月 Slackではじめて言及される
○ 当時はADRも会もなかったので話が進まない
● 2024年2月 会のトピックに上がる
● 2024年4月 ？？
● 2024年5月 検討を再開
● 2024年8月 承認・導入 🎉
事例: 非同期データ管理ライブラリ (再掲)
Slide 41
Slide 41 text
● 2023年5月 Slackではじめて言及される
○ 当時はADRも会もなかったので話が進まない
● 2024年2月 会のトピックに上がる
● 2024年4月 Muddy Web #8 でTanStack Query導入の話を聞く
● 2024年5月 検討を再開
● 2024年8月 承認・導入 🎉
事例: 非同期データ管理ライブラリ
Slide 42
Slide 42 text
Muddy Webがきっかけで
モチベーションを高められました
感謝🙏
Slide 43
Slide 43 text
まとめ
Slide 44
Slide 44 text
● pixivは17年の積み重ねで変えることが難しくなっていた
● 変えられる状態 = 変更容易性を手に入れたい
● そのためにADRと場所をつくって運用している
● 成果の1つとして、TanStack Queryの導入ができた
まとめ
Slide 45
Slide 45 text
● 変えることは難しい
● でも、変えられる
● 変えるためには泥臭く (Muddyに) 課題に向き合うことも必要
今日伝えたいこと (再掲)
Slide 46
Slide 46 text
● ピクシブは一緒に「創作活動を、もっと楽しくする。」メンバーを募集し
ています
● pixivのフロントエンドにはまだ課題が山積み
● しかし、それらを変えられるベースができてきた
● 一緒に挑戦したい方をお待ちしています
最後に
https://hrmos.co/pages/pixiv/jobs