組織全体で開発生産性に取り組むために 専門チームを作った話 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の可視化 ○ 負荷試験基盤の開発 ○ コード品質の可視化 & 改善

まとめ ● 各チームの手が回り切らない部分を担当するチームが必要になる。 ● ある程度の組織規模じゃないとコスパが悪い。

おわり