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
pospome
December 13, 2023
Programming
2
2.1k
組織全体で開発生産性に取り組むために 専門チームを作った話
DMM meetup #39 ~開発生産性を熱く語る会~
https://dmm.connpass.com/event/301567/
pospome
December 13, 2023
Tweet
Share
More Decks by pospome
See All by pospome
スタートアップを支える技術戦略と組織づくり
pospome
8
11k
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.6k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
4.6k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
6k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
41
21k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4.6k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
870
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.8k
(再アップロード)Microservices & APIs
pospome
0
210
Other Decks in Programming
See All in Programming
Atomics APIを知る / Understanding Atomics API
ssssota
1
210
関数の挙動書き換える
takatofukui
4
750
知られているようで知られていない JavaScriptの仕様 4選
syumai
0
630
Building AI with AI
inesmontani
PRO
1
260
Agentに至る道 〜なぜLLMは自動でコードを書けるようになったのか〜
mackee
5
2k
Combinatorial Interview Problems with Backtracking Solutions - From Imperative Procedural Programming to Declarative Functional Programming - Part 1
philipschwarz
PRO
0
100
Chart.jsで長い項目を表示するときのハマりどころ
yumechi
0
160
Micro Frontendsで築いた 共通基盤と運用の試行錯誤 / Building a Shared Platform with Micro Frontends: Operational Learnings
kyntk
0
1.6k
Feature Flags Suck! - KubeCon Atlanta 2025
phodgson
0
160
目的で駆動する、AI時代のアーキテクチャ設計 / purpose-driven-architecture
minodriven
11
3.4k
アーキテクチャと考える迷子にならない開発者テスト
irof
9
3.3k
How Software Deployment tools have changed in the past 20 years
geshan
0
7.6k
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
118
20k
The World Runs on Bad Software
bkeepers
PRO
72
12k
Code Review Best Practice
trishagee
72
19k
The Cult of Friendly URLs
andyhume
79
6.7k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
Mobile First: as difficult as doing things right
swwweet
225
10k
Unsuck your backbone
ammeep
671
58k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Visualization
eitanlees
150
16k
The Language of Interfaces
destraynor
162
25k
KATA
mclloyd
PRO
32
15k
Large-scale JavaScript Application Architecture
addyosmani
514
110k
Transcript
組織全体で開発生産性に取り組むために 専門チームを作った話 pospome
登壇者 名前:pospome(ぽすぽめ) 所属:DMMプラットフォーム Twitter:@pospome
今回の発表内容について DMMプラットフォーム x 開発生産性 x 専用のチームを作った話
DMMプラットフォームについて 扱う領域:DMM会員、決済、DMMポイント、不正対策など エンジニア数:120名以上 開発チーム数:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト:19,000RPS
大きな組織と開発効率の関係 • 大きな組織ほど開発効率が下がる。 エンジニア数が10倍になっても開発スピードは10倍にならない。 • 主な原因 ◦ コミュニケーションコストの増加 ◦ 横断的関心事に対する開発工数の増加
今回はこっちを取り上げる。
横断的関心事とは? • 組織全体に共通して必要となる作業のこと 例:CI/CD、負荷試験 • 横断的関心事を各チームで扱うと 開発効率が悪くなる
横断的関心事とは? • 専任のチームを作って共通化する 例:プラットフォームエンジニアリング • 開発生産性も横断的関心事に属する 専任のチームを作って取り組む。
Developer Productivity Group を作った
専門チームを作るメリット 1. 各チームが同じようなことをする工数を削減できる。 2. 各チームのノウハウをシェアすることができる。 3. 各チームが開発生産性に取り組む工数は限られている。
1. 各チームが同じようなことをする工数を削減できる • Four Keysの可視化 ◦ デプロイの頻度 … CI/CDパイプライン ◦
変更のリードタイム … GitHub ◦ 変更障害率 … 監視ツール ◦ サービス復元時間 … 監視ツール
1.各チームが同じようなことをする工数を削減できる • 組織全体で利用できる共通の仕組みを開発 Four Keysに限らず、Developer Productivity Groupが共通の仕組みを作 るだけで済む。
2.各チームのノウハウをシェアすることができる • “特定のチームだけ上手くやる” という状態を避けたい。 あくまで組織全体が上手くやれるようにする必要がある。 専任のチームが組織全体の最適化を進めていく。 • 各チームの状態を相対的に比較し、課題を可視化 & 解決する。
大きな組織ならではのノウハウ共有が可能になる。 例:開発生産性アンケート
例:開発生産性アンケート
3.各チームが開発生産性に取り組む工数は限られている • 各チームは開発生産性にフルコミットできるわけではない。 例:決済チームは決済領域にフルコミットすべき
3.各チームが開発生産性に取り組む工数は限られている • 課題を解決する取り組みに大きく工数を割けない。 ◦ Four Keysの可視化 ◦ 負荷試験基盤の開発 ◦ コード品質の可視化
& 改善
まとめ • 各チームの手が回り切らない部分を担当するチームが必要になる。 • ある程度の組織規模じゃないとコスパが悪い。
おわり