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
Kei Shiratsuchi
PRO
November 22, 2023
Technology
2
1.4k
なぜ リアーキテクティング専任チームを作ったのか
コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT
https://findy.connpass.com/event/300912/
Kei Shiratsuchi
PRO
November 22, 2023
Tweet
Share
More Decks by Kei Shiratsuchi
See All by Kei Shiratsuchi
モノリスとマイクロサービスの橋渡し - ベターからモアベターへ
kei_s
PRO
0
93
実践 Rails アソシエーションリファクタリング / Rails association refactoring in practice
kei_s
PRO
8
8.6k
「Go言語でつくるインタプリタ」を Rust で移植してみた / "Write An Interpreter In Go" In Rust
kei_s
PRO
1
1.9k
Rust言語で作るインタプリタ / Write An Interpreter In Rust
kei_s
PRO
2
630
育児休業のご報告と、育児グッズとしてのスマートスピーカー / Parental Leave and SmartSpeaker
kei_s
PRO
0
850
「深層学習による自然言語処理」読書会 第6章2.7
kei_s
PRO
0
450
「深層学習による自然言語処理」読書会 第5章5.1
kei_s
PRO
0
440
最近個人的に気になるプログラミング言語おさらい Ruby, Python, Go, Rust, Julia
kei_s
PRO
0
1k
「深層学習による自然言語処理」読書会 第2章2.1~2.5
kei_s
PRO
0
440
Other Decks in Technology
See All in Technology
プロダクトエンジニア構想を立ち上げ、プロダクト志向な組織への成長を続けている話 / grow into a product-oriented organization
hiro_torii
1
330
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
390
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
2
160
Reading Code Is Harder Than Writing It
trishagee
2
120
短縮URLをお手軽に導入しよう
nakasho
0
130
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
6
1.9k
遷移の高速化 ヤフートップの試行錯誤
narirou
5
840
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
daiksy
13
3.6k
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
150
日経のデータベース事業とElasticsearch
hinatades
PRO
0
200
Two Blades, One Journey: Engineering While Managing
ohbarye
3
730
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
200
Featured
See All Featured
Practical Orchestrator
shlominoach
186
10k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
How to train your dragon (web standard)
notwaldorf
91
5.9k
Thoughts on Productivity
jonyablonski
69
4.5k
How to Ace a Technical Interview
jacobian
276
23k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Gamification - CAS2011
davidbonilla
80
5.1k
Statistics for Hackers
jakevdp
797
220k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
Transcript
なぜ リアーキテクティング専任チームを 作ったのか 白土 慧, Kei Shiratsuchi, @kei_s ίʔυ্࣭ͷ͍Ζ
- ઌୡʹֶͿ࣮ફྫ Lunch LT, 2023.11.22(Wed)
自己紹介 • 白土 慧 (シラツチ ケイ) • kei-s • @kei_s
• 2021〜: 株式会社アンドパッド • リアーキテクティングチーム(リアーキチーム)を立ち上げ • 主に大規模な Rails アプリケーションを対象
このトークでは • コード品質の向上・維持のために「専任チーム」を作るとい うアプローチがある、という事例をお伝えしたい • 特にライブラリ等のバージョンアップを事例にして • トークの流れ 1. リアーキチームができる前の状況
2. リアーキチームを立ち上げるときに考えたこと 3. リアーキチームでやっていること
前提 • ANDPAD: 建築・建設業向けのSaaS • 様々な業務ドメイン向けのプロダクトを提供 • 施工管理、検査、チャット、etc… • 顧客がサービスを様々な組み合わせで利用できる
• 提供するプロダクトが多く、開発チームも多い
アーキテクチャ • 中心となるRailsアプリ(本体Railsアプリ)と、それに接 続する各ドメイン向けプロダクトで複数のプロダクトを提 供 • 本体Railsアプリだけでも複数のプロダクトを提供 • 開発開始から8年の歴史 •
プロダクトごとの約10チームが同時に開発 • 比較的新しいプロダクトはGoなどで構築
1. リアーキチーム開始以前の状況
「何か開発がうまく行かない」 • 障害が発生する • 機能開発に時間がかかる • ライブラリアップデートが滞る • 「価値を遅滞なく提供し続ける」ことが難しい状況
ライブラリアップデートが滞る • 具体的には、本体Railsアプリの一部ライブラリのバージョン アップが滞っている • いくつかのライブラリは開発停止していたり、マイグレー ションパスが長いものがある • 複数のプロダクトチームにまたがって使われているライブ ラリは、一つのチームで責務を持ちにくい
• Ruby、Rails自体も同様 • 上記二つの理由から、各プロダクトチームのロードマップに載 せにくい
ライブラリアップデートの重要性 • 「価値を遅滞なく提供し続ける」ことが難しくなる • 古いライブラリに依存したコードによるメンテナンス性 の低下 • ドキュメント・知見が見つからなくなっていく • セキュリティリスクの増加
• OSSを用いるメリットを受けられない • パフォーマンスの向上 • 新機能による生産性向上
2. リアーキチームを 立ち上げるまで
リアーキチームの発足 • 全体を俯瞰して課題を発見、解決していきたい • 既存の各チームはプロダクトロードマップを進めること を優先し、広い動きがしづらい状況 • チームの特徴 • 特定のサービス・ドメインに責務を持たない
• 全体の中で改善が追いついていないところをやる • 専任。リアーキにフルコミットする
リアーキチームの位置付け • 目的 • 既存の仕組みのつらみを解消 • 新規サービスの開発を楽にできるように • 改善を継続してやるぞ、という文化を醸成 •
その背景 • 放っておくと既存のつらみを踏襲した部分が増えていくので阻止 • リアーキチームだけでは限界がある。エンジニア全体でよりよい コードが書けるように
リアーキチームの位置付け • スコープ • プロダクトを跨いで共通に利用される箇所 • プロダクトに閉じた部分は各チームに任せ、スコープ 外とする • その背景
• 共通に利用される箇所の改善が追いついていない。 影響が広く、各チームだけで改善を進めにくい
3. リアーキチームで やっていること
ライブラリアップデートの対応 • 重要度・危険度を加味して優先順位をつけ、上から倒していく • 重要機能を担っているか • 開発予定の新機能が依存しそうか • セキュリティリスクが高まっているか •
リアーキチームで対応する • リソース(対応人数)を固定し、与えられたリソースで可能 なところまでやる • 「兼任」「有志」では対応が難しい長期課題に取り組む
ライブラリアップデートの例 • Ruby,Railsのアップデート • Ruby 3.0→3.2 をリアーキチームで対応 • 各チームの動作確認をスムーズに抜け漏れなく行うための環境 整備
• なぜ、アンドパッドは最新のRuby/Railsにこだわるのか?アップデートを 止めないための体制と仕組み • 古いライブラリのアップデート • 例: Webpack から Vite への移行(作業中) • プロダクトチームでは作業見積りが難しく着手されていなかった ライブラリのアップデート作業を実施
その他チームでやってきたこと • エラー通知の整理 • 本体Railsアプリの開発者向け • 共通で利用されるデータのリファクタリング • 中長期の課題向け •
🔎 @kei-s 実践 Rails アソシエーションリファクタリング - Kaigi on Rails 2023 • 本体Railsアプリ内部で広く使われていた独自の仕組みを廃止 • 新たに参加する開発者向け • 🔎 @makicamel 歴史あるプロジェクトのとある技術的負債を隙間プロジェクト の 210 PullRequests で倒しきった話 - Kaigi on Rails 2023
責務のさじ加減 • 「ライブラリアップデートは特定チームの仕事」にはしたくない • ライブラリも我々のプロダクト・コードの一部 • エンジニアチーム全体で責任を持つべき • とはいえ、放っておくと進まない領域は存在する •
広く共有されるライブラリや、極端に古くなったライブラ リ • 「ライブラリアップデートを進めていく姿勢」をエンジニアチー ム全体に広めていきたい
まとめ
まとめ • ANDPADでは、コード品質向上・開発者体験の向上の ために、リアーキテクティング専任のチームを立ち上げ た • 今回はライブラリアップデートを事例に紹介