120名の開発組織を支える、技術マネジメントと選定

by pospome

Slide 1

Slide 1 text

120名の開発組織を支える技術マネジメントと選定 @pospome

Slide 2

Slide 2 text

登壇者名前：pospome（ぽすぽめ）所属：DMM.com Twitter:@pospome

Slide 3

Slide 3 text

話す内容 1. pospomeが所属する開発組織の規模感 2. pospomeが入社する前のDMMプラットフォームについて 3. pospomeが入社して技術選定をした話 4. 技術選定の結果

Slide 4

Slide 4 text

Slide 5

Slide 5 text

DMMプラットフォーム扱う領域：DMM会員、決済、DMMポイント、不正対策などエンジニア数：120名以上開発チーム数：16チームマイクロサービス数：約40サービスピーク時のリクエスト：19,000RPS ＊2016年くらいからマイクロサービスになっている。

Slide 6

Slide 6 text

Slide 7

Slide 7 text

pospomeが入社する前のDMMプラットフォーム独立性の高い小さいチームで構成されていた。以下のメリットがある。 1. コミュニケーションパスを減らす。 2. オーナーシップを持たせることで自走して開発ができる。 3. 開発チームが開発から運用まで自分たちで対応できる。

Slide 8

Slide 8 text

Amazon: Two-Pizza Team Rule

Slide 9

Slide 9 text

Amazon: You build it, you run it.

Slide 10

Slide 10 text

しかし、開発効率は高くなかった

Slide 11

Slide 11 text

テクノロジースタックがバラバラすぎる 1. チーム同士の技術的な知見共有が難しい。 2. エコシステムの構築が難しい。 3. 他チームへのヘルプなどで実力を発揮できない。各チームが強力なオーナーシップを持った結果、大きな組織だからこそ取れる戦略を取ることができない。

Slide 12

Slide 12 text

究極にサイロ化しており、スタートアップの集合体のようだった

Slide 13

Slide 13 text

それぞれのチームのオーナーシップが強すぎる会員チーム独自のテクノロジースタック独自の開発ルールプロダクト設計採用決済チーム独自のテクノロジースタック独自の開発ルールプロダクト設計採用

Slide 14

Slide 14 text

Slide 15

Slide 15 text

オーナーシップの程度設計が重要である開発チームに与えるオーナーシップの程度（権限の強さ）を適切なものに再設計する必要がある。今回のイベントのテーマに沿って “技術マネジメント（テクノロジースタックの統一）と技術選定” という観点で話を進める。

Slide 16

Slide 16 text

こんな感じにする必要がある DMM会員チームプロダクト設計採用決済チームプロダクト設計採用共通のテクノロジースタック共通の開発ルール

Slide 17

Slide 17 text

統一の程度が難しい統一の程度小さい大きい各チームの要件満たせる満たせない

Slide 18

Slide 18 text

最終的なイメージ DMM会員チームプロダクト設計採用決済チームプロダクト設計採用共通のテクノロジースタック共通の開発ルール独自のテクノロジースタック独自の開発ルール独自のテクノロジースタック独自の開発ルール

Slide 19

Slide 19 text

なにをやったのか? 統一したテクノロジースタックの一例技術領域選択した技術プログラミング言語バックエンドはGo言語フロントエンドはTypeScript コンテナ環境 k8s モニタリング & ログ Datadog

Slide 20

Slide 20 text

なにをやったのか? 統一しなかったテクノロジースタックの一例技術領域選択した技術クラウド AWS & GCP を選択可能とする。 DB & キャッシュ各チームが自由に選択して良い。アプリケーションフレームワーク & ライブラリ各チームで自由に選択していい。

Slide 21

Slide 21 text

デファクト・スタンダードから外れる権利各チームは組織として定義するテクノロジースタックから外れる権利を持っているが、各種恩恵を受けられなくなる。各チームでメリデメを判断してもらう形になっている。

Slide 22

Slide 22 text

どのように進めたのか? 既存チームと会話して課題を洗い出し、 CTOに課題と解決策を提案してトップダウンで進めた。想定に反して現場のエンジニアからの反発はなかった（各チームも同じような課題を感じていたのかもしれない）。

Slide 23

Slide 23 text

Slide 24

Slide 24 text

技術選定の結果は? テクノロジースタック統一のアンケート結果としては約8割のエンジニアが「開発効率が向上した」と回答している。残りの2割は「まだ判断できない」と回答している。

Slide 25

Slide 25 text

技術選定の結果は? 選定したテクノロジースタック群が適切かどうかは分からない。これは他の選択をした場合との直接的な比較が難しいからである。 e.g. 「GoよりもPHPの方がよかったのでは?」

Slide 26

Slide 26 text

技術選定の結果は? 時間の経過によって分かることもあるが、選定した当時の状況を考慮しなければいけないので、結果論になる部分もある。ただ、”当時の判断に妥当性があること” は最低限必要だと思う。

Slide 27

Slide 27 text

まとめ ● テクノロジースタックを統一した。各チームに自由度をもたせた部分もある。 ● 方針変更はトップダウンで実行した。 ● 前よりは良くなったので成功とみなせる。 ● 技術選定が成功したかどうかは分からない。 “選定理由の妥当性” が大事である。