Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

pospome
July 18, 2023

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

"ソフトウェアアーキテクトの挑戦 技術選定を成功させるために" の登壇資料です。
https://offers.connpass.com/event/289340/

pospome

July 18, 2023
Tweet

More Decks by pospome

Other Decks in Technology

Transcript

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

    View Slide

  2. 登壇者
    名前:pospome(ぽすぽめ)
    所属:DMM.com
    Twitter:@pospome

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. Amazon: Two-Pizza Team Rule

    View Slide

  9. Amazon: You build it, you run it.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide