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
darquro
April 10, 2023
Technology
1
970
技術的負債を解消してくための組織づくり
darquro
April 10, 2023
Tweet
Share
More Decks by darquro
See All by darquro
Jailbreakと向き合おう
darquro
0
2.5k
ラクマでのSwiftUI導入方針とTips / Rakuma SwiftUI Introduction Policy and Tips
darquro
2
5.2k
Half modal comparision in iOS15
darquro
2
2.1k
2 Years Challenge as Engineering Manager in Rakuma
darquro
0
130
Property Wrappersがもたらす新しいSwiftプログラミング / New Swift programming with Property Wrappers
darquro
3
1.7k
iOS View Class Design Basic
darquro
3
760
Swift 5 Exclusivity Enforcement
darquro
4
830
SDK連携を用いたAdMob活用法
darquro
1
1k
ContributingSwift
darquro
0
86
Other Decks in Technology
See All in Technology
Goss: Faiss向けの新しい本番環境対応 Goバインディング #coefl_go_jp
bengo4com
0
1.4k
Understanding Go GC #coefl_go_jp
bengo4com
0
1.1k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.6k
Webアクセシビリティ入門
recruitengineers
PRO
1
220
イオン店舗一覧ページのパフォーマンスチューニング事例 / Performance tuning example for AEON store list page
aeonpeople
2
270
実践アプリケーション設計 ②トランザクションスクリプトへの対応
recruitengineers
PRO
2
140
自治体職員がガバクラの AWS 閉域ネットワークを理解するのにやって良かった個人検証環境
takeda_h
2
380
実践データベース設計 ①データベース設計概論
recruitengineers
PRO
2
190
JOAI発表資料 @ 関東kaggler会
joai_committee
1
260
Figma + Storybook + PlaywrightのMCPを使ったフロントエンド開発
yug1224
3
150
退屈なことはDevinにやらせよう〜〜Devin APIを使ったVisual Regression Testの自動追加〜
kawamataryo
1
130
自社製CMSからmicroCMSへのリプレースがプロダクトグロースを加速させた話
nextbeatdev
0
130
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
The Cult of Friendly URLs
andyhume
79
6.5k
Side Projects
sachag
455
43k
It's Worth the Effort
3n
187
28k
Optimizing for Happiness
mojombo
379
70k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
A designer walks into a library…
pauljervisheath
207
24k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Thoughts on Productivity
jonyablonski
69
4.8k
Transcript
技術的負債を解消していくための組織づくり Yuki Kuroda(@darquro) Rakuten Group, Inc.
2 楽天ラクマについて • 2014年からネイティブアプリを開発 • 2018年時点では30~40%がSwift/Kotlin (darquro⼊社) • 2022年に100%Swift/Kotlinに移⾏完了 *1
https://www.wantedly.com/companies/rakutenrakuma/post_articles/427902 *2 https://www.wantedly.com/companies/rakutenrakuma/post_articles/455377 技術的負債を解消⽅針 • ⾔語の移⾏と同時にリアーキテクチャーも⾏ い、テストを増やしていく • 機能開発は⽌めない *1 *2
3 EMとしての組織づくり 技術的負債を解消してく組織をつくりたい メンバーが⾃律的に動ける体制を整える 結論 Next どんなこと をやってきたか
4 ⽬標を表明 “今こういうことに取 りん組んでいる”、 ”これはどういう意味 がある” ということを定期的に 発信する。 チーム外 “こういう⽅針でやっ
ていこう” 、 ”いつまでに何を完了 させよう” といったビジョンを伝 える。 チーム内 “これがX⽉くらいに終わってる といいですよね” “今期はリファクタリングで注 ⼒したいのはどのあたりですか ね︖” といった具体的かつ、ある期間 で達成できるゴールのイメージ を掴んでもらう。 メンバー個々 コンテキストが揃うことで、コミュニケーションをスムーズに。 漠然としたゴールではなく、わかりやすいゴールを。
5 評価制度への組み込み リファクタリングの粒度、影響度に応じたImpact Levelを定義。またそれに応じた難易度ポイントを設定。 メンバーにはすべてのPRに対してImpact Lebelを設定してもらう。(→ QA時の分析指標としても利⽤) メンバーは⽬標設定で、⾃⾝のリファクタリングタスクの稼働率から⽬標ポイントを算出し、合計ポイント が⽬標達成しているかどうかを定量評価できるように仕組み化。 Impact
Level Example Point 1 • 機械的に⾏えるリファクタリング • ライブラリのMinor Version Up • 軽微なパフォーマンスチューニング 1 2 • 限定的な影響範囲のクラスのや機能のリファクタリング • ライブラリのバージョンアップとそれに伴う⼀定の調査とテストに時間が要するも ののリファクタリング 2 3 • 複数の機能に影響するクラスのリファクタリング • UXやメモリ削減等に影響するパフォーマンス向上 4 4 • コアとなるクラス、開発のボトルネックとなっている、アプリ全体へ影響する複雑 性の⾼いクラスのリファクタリング • 全体へ影響するアーキテクチャの改善、チーム⽣産性へも影響するリファクタリン グ 8
6 評価制度への組み込み リファクタリング稼働率 (%) = ⽬標達成合計Point Ex. リファクタリング稼働率 20% →
⽬標達成合計Point 20点が100%達成のRatingとする。 • ImpactLevel 2 (2point) × 6件 = 12point • ImpactLevel 3 (4point)× 2件 = 8point さらに合計の1.5倍以上達成で⼀つの上のRatingになる。
7 評価制度への組み込み パフォーマンス 評価 (定量評価) コンピテンシー 評価 (定性評価) リファクタリング ImpactLevelに応じた合計Pointで評価
⽬標達成(完了)まで到達しなかった けど、プロセスとして評価できるも のはグレードに応じた期待役割を軸 に評価
8 品質担保のための仕組みづくり • すべてのPRとImpactLevelをQAに共有し、QAのテスト観点として利⽤ • テストプロセスとリリースプロセスの⾃動化(CI/CD) • どうしてもマニュアル作業が必要なところにリリース プロセスチェックリストで漏れを防⽌ •
本番リリース前の、最終動作確認テスト項⽬を作成し、”違和感”に気がつけるタイミングを設け る
9 トラブル後の振り返り 参加メンバー • iOS/Androidエンジニアチームごとのメンバー全員で参加 事象の再確認 • 検知⽇時、発⽣時期、復旧⽇時 直接原因の整理 •
どんなコード変更をしたのか • どんなオペレーションをしたのか 根本原因の深堀り • どうしてこのようなコード変更をする経緯に⾄ったのか • 間違いに気がつけるタイミング、フロー、プロセスはあったのか 再発防⽌策 • UTでカバーできるか • プロセスでカバーできるか • ドキュメントでカバーできるか … その他仕組み化できることは何か
10 リファクタリングスピードの調整 • ⾃律した組織化が進んでいくと、スピードがどんどん上がっていく • レビュー数が増えることで、⼀つ⼀つの精度が下がる ⼀度⽴ち⽌まって、スピードを落とすことも伝える。 あまりマイナスな印象を与えないようにすることも⼤切。 ⼀歩ずつ丁寧にやっていこうと前向きな⾔葉を使う。 https://www.pixiv.net/en/artworks/32470259
11 ⾃律的なチームを拡⼤ モバイルアプリチームの成功事例を 開発組織全体へ拡⼤ • チームの認知負荷の軽減 • チームの適切な境界を再定義 • 組織の再編成を模索中
『チームトポロジー』⽇本能率境界マネジメントセンター
12 偉業は⼀時的な衝動でなされるものではなく、⼩さなことの積 み重ねによって成し遂げられるのだ。 Great things are not done by impulse,
but by a series of small things brought together. フィンセント・ファン・ゴッホ Vincent van Gogh
Thank you for listening!