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
980
技術的負債を解消してくための組織づくり
darquro
April 10, 2023
Tweet
Share
More Decks by darquro
See All by darquro
Jailbreakと向き合おう
darquro
0
2.6k
ラクマでのSwiftUI導入方針とTips / Rakuma SwiftUI Introduction Policy and Tips
darquro
2
5.3k
Half modal comparision in iOS15
darquro
2
2.2k
2 Years Challenge as Engineering Manager in Rakuma
darquro
0
140
Property Wrappersがもたらす新しいSwiftプログラミング / New Swift programming with Property Wrappers
darquro
3
1.7k
iOS View Class Design Basic
darquro
3
780
Swift 5 Exclusivity Enforcement
darquro
4
840
SDK連携を用いたAdMob活用法
darquro
1
1k
ContributingSwift
darquro
0
86
Other Decks in Technology
See All in Technology
ざっくり学ぶ 『エンジニアリングリーダー 技術組織を育てるリーダーシップと セルフマネジメント』 / 50 minute Engineering Leader
iwashi86
4
1.8k
.NET 10のBlazorの期待の新機能
htkym
0
150
ヘンリー会社紹介資料(エンジニア向け) / company deck for engineer
henryofficial
0
410
OTEPsで知るOpenTelemetryの未来 / Observability Conference Tokyo 2025
arthur1
0
300
CREが作る自己解決サイクルSlackワークフローに組み込んだAIによる社内ヘルプデスク改革 #cre_meetup
bengo4com
0
350
東京大学「Agile-X」のFPGA AIデザインハッカソンを制したソニーのAI最適化
sony
0
140
ViteとTypeScriptのProject Referencesで 大規模モノレポのUIカタログのリリースサイクルを高速化する
shuta13
3
220
個人でデジタル庁の デザインシステムをVue.jsで 作っている話
nishiharatsubasa
3
5.2k
Behind Postgres 18: The People, the Code, & the Invisible Work | Claire Giordano | PGConfEU 2025
clairegiordano
0
150
AI時代の発信活動 ~技術者として認知してもらうための発信法~ / 20251028 Masaki Okuda
shift_evolve
PRO
1
110
From Natural Language to K8s Operations: The MCP Architecture and Practice of kubectl-ai
appleboy
0
300
Retrospectiveを振り返ろう
nakasho
0
130
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
A Tale of Four Properties
chriscoyier
161
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
Designing Experiences People Love
moore
142
24k
The World Runs on Bad Software
bkeepers
PRO
72
11k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Raft: Consensus for Rubyists
vanstee
140
7.2k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
10
890
Designing for Performance
lara
610
69k
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!