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
120名の開発組織を支える、技術マネジメントと選定
Search
pospome
July 18, 2023
Technology
11
7.6k
120名の開発組織を支える、技術マネジメントと選定
"ソフトウェアアーキテクトの挑戦 技術選定を成功させるために" の登壇資料です。
https://offers.connpass.com/event/289340/
pospome
July 18, 2023
Tweet
Share
More Decks by pospome
See All by pospome
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
8
3.6k
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
10
5.5k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
33
15k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
4k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.8k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
690
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.5k
(再アップロード)Microservices & APIs
pospome
0
120
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
130
Other Decks in Technology
See All in Technology
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
9
1.1k
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.7k
Amplify Gen2 Deep Dive / バックエンドの型をいかにしてフロントエンドへ伝えるか #TSKaigi #TSKaigiKansai #AWSAmplifyJP
tacck
PRO
0
390
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
870
DynamoDB でスロットリングが発生したとき/when_throttling_occurs_in_dynamodb_short
emiki
0
250
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
680
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
130
100 名超が参加した日経グループ横断の競技型 AWS 学習イベント「Nikkei Group AWS GameDay」の紹介/mediajaws202411
nikkei_engineer_recruiting
1
170
The Role of Developer Relations in AI Product Success.
giftojabu1
1
130
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
Featured
See All Featured
Become a Pro
speakerdeck
PRO
25
5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
97
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Happy Clients
brianwarren
98
6.7k
Why Our Code Smells
bkeepers
PRO
334
57k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
Transcript
120名の開発組織を支える 技術マネジメントと選定 @pospome
登壇者 名前:pospome(ぽすぽめ) 所属:DMM.com Twitter:@pospome
話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果
話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果
DMMプラットフォーム 扱う領域:DMM会員、決済、DMMポイント、不正対策など エンジニア数:120名以上 開発チーム数:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト:19,000RPS *2016年くらいからマイクロサービスになっている。
話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果
pospomeが入社する前のDMMプラットフォーム 独立性の高い小さいチームで構成されていた。 以下のメリットがある。 1. コミュニケーションパスを減らす。 2. オーナーシップを持たせることで自走して開発ができる。 3. 開発チームが開発から運用まで自分たちで対応できる。
Amazon: Two-Pizza Team Rule
Amazon: You build it, you run it.
しかし、開発効率は高くなかった
テクノロジースタックがバラバラすぎる 1. チーム同士の技術的な知見共有が難しい。 2. エコシステムの構築が難しい。 3. 他チームへのヘルプなどで実力を発揮できない。 各チームが強力なオーナーシップを持った結果、 大きな組織だからこそ取れる戦略を取ることができない。
究極にサイロ化しており、 スタートアップの集合体のようだった
それぞれのチームのオーナーシップが強すぎる 会員チーム 独自のテクノロジースタック 独自の開発ルール プロダクト設計 採用 決済チーム 独自のテクノロジースタック 独自の開発ルール プロダクト設計
採用
話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果
オーナーシップの程度設計が重要である 開発チームに与えるオーナーシップの程度(権限の強さ)を 適切なものに再設計する必要がある。 今回のイベントのテーマに沿って “技術マネジメント(テクノロジースタックの統 一)と技術選定” という観点で話を進める。
こんな感じにする必要がある DMM会員チーム プロダクト設計 採用 決済チーム プロダクト設計 採用 共通のテクノロジースタック 共通の開発ルール
統一の程度が難しい 統一の程度 小さい 大きい 各チームの要件 満たせる 満たせない
最終的なイメージ DMM会員チーム プロダクト設計 採用 決済チーム プロダクト設計 採用 共通のテクノロジースタック 共通の開発ルール 独自のテクノロジースタック
独自の開発ルール 独自のテクノロジースタック 独自の開発ルール
なにをやったのか? 統一したテクノロジースタックの一例 技術領域 選択した技術 プログラミング言語 バックエンドはGo言語 フロントエンドはTypeScript コンテナ環境 k8s モニタリング
& ログ Datadog
なにをやったのか? 統一しなかったテクノロジースタックの一例 技術領域 選択した技術 クラウド AWS & GCP を選択可能とする。 DB
& キャッシュ 各チームが自由に選択して良い。 アプリケーションフレームワーク & ライブラリ 各チームで自由に選択していい。
デファクト・スタンダードから外れる権利 各チームは組織として定義するテクノロジースタックから外れる権利を持ってい るが、各種恩恵を受けられなくなる。 各チームでメリデメを判断してもらう形になっている。
どのように進めたのか? 既存チームと会話して課題を洗い出し、 CTOに課題と解決策を提案してトップダウンで進めた。 想定に反して現場のエンジニアからの反発はなかった(各チームも同じような 課題を感じていたのかもしれない)。
話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果
技術選定の結果は? テクノロジースタック統一のアンケート結果としては約8割のエンジニアが「開発 効率が向上した」と回答している。 残りの2割は「まだ判断できない」と回答している。
技術選定の結果は? 選定したテクノロジースタック群が適切かどうかは分からない。 これは他の選択をした場合との直接的な比較が難しいからである。 e.g. 「GoよりもPHPの方がよかったのでは?」
技術選定の結果は? 時間の経過によって分かることもあるが、 選定した当時の状況を考慮しなければいけないので、 結果論になる部分もある。 ただ、”当時の判断に妥当性があること” は最低限必要だと思う。
まとめ • テクノロジースタックを統一した。 各チームに自由度をもたせた部分もある。 • 方針変更はトップダウンで実行した。 • 前よりは良くなったので成功とみなせる。 • 技術選定が成功したかどうかは分からない。
“選定理由の妥当性” が大事である。