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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
pospome
December 13, 2023
Programming
2.2k
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
組織全体で開発生産性に取り組むために 専門チームを作った話
DMM meetup #39 ~開発生産性を熱く語る会~
https://dmm.connpass.com/event/301567/
pospome
December 13, 2023
More Decks by pospome
See All by pospome
生成AIを利用するだけでなく、投資できる組織へ
pospome
2
620
スタートアップを支える技術戦略と組織づくり
pospome
8
21k
技術好きなエンジニアが "リーダーへの進化" によって得たものと失ったもの
pospome
5
1.7k
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
5.2k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
6.2k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
44
22k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
5.3k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
960
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
3k
Other Decks in Programming
See All in Programming
Generative UI & AI-Assistants for Your Angular Solutions
manfredsteyer
PRO
1
160
使用 Meilisearch 建立新聞搜尋工具
johnroyer
0
130
OSINT for SRE: 学術論文とポストモーテムから探る システム障害の共通パターン / SRE NEXT 2026
tomoyk
1
3.5k
Hatena Engineer Seminar #37「言語モデルの活用に関する研究」
slashnephy
0
510
例外の正しい扱い方 そのエラー try-catchして大丈夫?
jinwatanabe
0
360
「なぜそう決めたのか」を残し続ける仕組み ― Notion AI カスタムエージェント × Slack連携による設計判断の自動記録 - NIKKEI Tech Talk #47
niftycorp
PRO
0
260
アルゴリズムは何を圧縮しているのか ─ Haskell から育った「圧縮代数」というメンタルモデル
naoya
16
3.3k
AI 輔助遺留系統現代化的經驗分享
jame2408
1
1.2k
Vite+ Unified Toolchain for the Web
naokihaba
0
740
トークンをケチるな、設計しろ:GitHub Copilotを賢く使うコンテキスト戦略
ochtum
0
310
鹿野さんに聞く!『TypeScriptコードレシピ集』で磨く実践力
tonkotsuboy_com
4
1.1k
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
8
4k
Featured
See All Featured
Are puppies a ranking factor?
jonoalderson
1
3.7k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
260
Building an army of robots
kneath
306
46k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
760
Paper Plane
katiecoart
PRO
2
52k
AI: The stuff that nobody shows you
jnunemaker
PRO
8
820
The #1 spot is gone: here's how to win anyway
tamaranovitovic
3
1.1k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
350
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
3
180
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
72
40k
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の可視化 ◦ 負荷試験基盤の開発 ◦ コード品質の可視化
& 改善
まとめ • 各チームの手が回り切らない部分を担当するチームが必要になる。 • ある程度の組織規模じゃないとコスパが悪い。
おわり