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
ANDPAD inc
November 21, 2023
Programming
0
220
なぜリアーキテクティング専任チームを作ったのか
白土 慧
@kei_s
テックリード
2023 年 11 月 22 日
「
コード品質向上のいろは - 先達に学ぶ実践例 Lunch LT
」
ANDPAD inc
November 21, 2023
Tweet
Share
More Decks by ANDPAD inc
See All by ANDPAD inc
アンドパッドにおける CocoaPods ライブラリ群の SwiftPackageManager への移行戦略
andpad
0
17
Flutter は DCM が 9 割
andpad
1
14
Amplify で SPA をホスティングする際の注意点
andpad
0
18
マルチプロダクト開発の現場でAWS Security Hubを1年以上運用して得た教訓
andpad
0
58
rails stats で紐解く ANDPAD のイマを支える技術たち
andpad
1
390
本編では話さない Zig の話
andpad
2
250
"noncopyable types" の使いどころについて考えてみた
andpad
0
380
ANDPAD黒板のオフラインモード機能 リリースまでの軌跡
andpad
0
260
アンドパッドのマルチプロダクト戦略を支える SRE
andpad
1
250
Other Decks in Programming
See All in Programming
.NET Frameworkでも汎用ホストが使いたい!
tomokusaba
0
180
データの整合性を保つ非同期処理アーキテクチャパターン / Async Architecture Patterns
mokuo
53
18k
Honoのおもしろいミドルウェアをみてみよう
yusukebe
1
210
『品質』という言葉が嫌いな理由
korimu
0
180
ファインディLT_ポケモン対戦の定量的分析
fufufukakaka
0
860
Honoをフロントエンドで使う 3つのやり方
yusukebe
7
3.4k
Grafana Loki によるサーバログのコスト削減
mot_techtalk
1
130
一休.com のログイン体験を支える技術 〜Web Components x Vue.js 活用事例と最適化について〜
atsumim
0
690
『GO』アプリ バックエンドサーバのコスト削減
mot_techtalk
0
150
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
180
CDK開発におけるコーディング規約の運用
yamanashi_ren01
2
190
dbt Pythonモデルで実現するSnowflake活用術
trsnium
0
220
Featured
See All Featured
The Language of Interfaces
destraynor
156
24k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Six Lessons from altMBA
skipperchong
27
3.6k
We Have a Design System, Now What?
morganepeng
51
7.4k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Rails Girls Zürich Keynote
gr2m
94
13k
Code Review Best Practice
trishagee
67
18k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
Building Your Own Lightsaber
phodgson
104
6.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
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では、コード品質向上・開発者体験の向上の ために、リアーキテクティング専任のチームを立ち上げ た • 今回はライブラリアップデートを事例に紹介