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
930
技術的負債を解消してくための組織づくり
darquro
April 10, 2023
Tweet
Share
More Decks by darquro
See All by darquro
Jailbreakと向き合おう
darquro
0
2.2k
ラクマでのSwiftUI導入方針とTips / Rakuma SwiftUI Introduction Policy and Tips
darquro
2
5k
Half modal comparision in iOS15
darquro
2
1.8k
2 Years Challenge as Engineering Manager in Rakuma
darquro
0
110
Property Wrappersがもたらす新しいSwiftプログラミング / New Swift programming with Property Wrappers
darquro
3
1.6k
iOS View Class Design Basic
darquro
3
730
Swift 5 Exclusivity Enforcement
darquro
4
770
SDK連携を用いたAdMob活用法
darquro
1
990
ContributingSwift
darquro
0
78
Other Decks in Technology
See All in Technology
技術スタックだけじゃない、業務ドメイン知識のオンボーディングも同じくらいの量が必要な話
niftycorp
PRO
0
120
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
3
340
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
140
E2Eテスト自動化入門
devops_vtj
1
100
生成AI×財務経理:PoCで挑むSlack AI Bot開発と現場巻き込みのリアル
pohdccoe
1
780
Two Blades, One Journey: Engineering While Managing
ohbarye
4
2.3k
Qiita Organizationを導入したら、アウトプッターが爆増して会社がちょっと有名になった件
minorun365
PRO
1
200
Snowflakeの開発・運用コストをApache Icebergで効率化しよう!~機能と活用例のご紹介~
sagara
1
500
あなたが人生で成功するための5つの普遍的法則 #jawsug #jawsdays2025 / 20250301 HEROZ
yoshidashingo
2
320
MIMEと文字コードの闇
hirachan
2
1.4k
JAWS DAYS 2025 アーキテクチャ道場 事前説明会 / JAWS DAYS 2025 briefing document
naospon
0
2.6k
AIエージェント入門
minorun365
PRO
32
19k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Agile that works and the tools we love
rasmusluckow
328
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Documentation Writing (for coders)
carmenintech
68
4.6k
Designing Experiences People Love
moore
140
23k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Designing for Performance
lara
605
68k
Side Projects
sachag
452
42k
GraphQLの誤解/rethinking-graphql
sonatard
69
10k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
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!