Tweet
Tweet

Slide 1

Slide 1 text

1 文化が生産性を作る 2024.10.02 Engineering Productivity Meetup #3 in 福岡 @jimpei

Slide 2

Slide 2 text

2 
 SIer -> Yahoo! JAPAN -> mercari (2021/08) 
 Software Engineer 
 
 メルカリでお困りごとを解決するドメインでの 
 プロダクトを開発してます 
 濱村 甚平(@jinpeih) 


Slide 3

Slide 3 text

3 文化が生産性を作る

Slide 4

Slide 4 text

4 文化が生産性を作る ● 物的生産性 / 付加価値生産性 ● DORA / Four Keys / SPACE 生産性には色々語るべきポイントが多い

Slide 5

Slide 5 text

5 文化が生産性を作る ● 物的生産性 / 付加価値生産性 ● DORA / Four Keys / SPACE どれにフォーカスするにせよ、チームで改善や取り組みをしてますよね？ 生産性には色々語るべきポイントが多い

Slide 6

Slide 6 text

6 本日の問い

Slide 7

Slide 7 text

7 本日の問い 『その改善や取り組みは　 どこまでチームで 　合意できていますか？』

Slide 8

Slide 8 text

8 なぜ合意が気になったか

Slide 9

Slide 9 text

9 私達のチームは順調でした ・数値は目標ではなく健康診断のみに利用 ・健全であるという自負も持っていた デプロイ頻度 月30回, 年間400回 変更失敗率 1%未満 deploys / a day / a developer 0.4

Slide 10

Slide 10 text

10 なぜ合意が気になったか ● デプロイ頻度：30/月, 400/年 ● D/D/D: 0.4 ● 事故はほぼ0 → 計測してない 私達のチームは順調でした

Slide 11

Slide 11 text

11 チームに変革期が訪れる

Slide 12

Slide 12 text

12 BE BE FE FE FE FE PdM EM ~ 2023/3 


Slide 13

Slide 13 text

13 BE BE FE FE FE FE PdM EM BE BE FE FE FE FE PdM EM BE (new) ~ 2023/3 
 2023/4 ~ 
 異動や退職

Slide 14

Slide 14 text

14 BE BE FE FE FE FE PdM EM BE (new) 2023/4 


Slide 15

Slide 15 text

15 BE BE FE FE FE FE PdM (new) EM from FE BE (new) FE (new) BE BE FE FE FE FE PdM EM BE (new) 2023/4 
 2024/4 ~ 
 Role Change

Slide 16

Slide 16 text

16 BE BE FE FE FE FE PdM (new) EM from FE BE (new) FE (new) BE BE FE FE FE FE PdM EM BE (new) 育休(2ヶ月) 2023/4 
 2024/4 ~ 
 Role Change

Slide 17

Slide 17 text

17 人がまるっと変わるとどうなる？

Slide 18

Slide 18 text

18 人がまるっと変わるとどうなる？ ● 生産性が下がってしまう のでは？ ● 仕組み化されているので大丈夫かも ？ ● 下がったとしても一時的ではないか？ 懸念と楽観が入り交じる

Slide 19

Slide 19 text

19 人がまるっと変わるとどうなる？ ● 生産性が下がってしまう のでは？ ● 仕組み化されているので大丈夫かも ？ ● 下がったとしても一時的ではないか？ 懸念と楽観が入り交じる 結果 問題なかった

Slide 20

Slide 20 text

20 なぜ合意が気になったか ● デプロイ頻度：30/月, 400/年 ● D/D/D: 0.4 ● 事故はほぼ0 → 計測してない 私達のチームは順調でした

Slide 21

Slide 21 text

21 生産性を支えた仕組み 統一されたマイクロサービスの開発フロー 
 ● FE, BE, 内部ツール, BFF(GraphQL),,,などいくつかのマイクロサービスがある 
 ● 開発フロー 
 ○ masterから直接PRを作る 
 ○ PRでlabelをつけるとPR用の開発環境が作られる 
 ○ マージするとDEV環境に自動でデプロイされる 
 ○ release tagをつけるとInternal リリースされる 
 ○ 問題なければCanaryリリース＆本番リリース 
 ● ログやモニタリングも同様のツール・仕組み 
 ○ 問題があったときに見るべきものがわかりやすい 


Slide 22

Slide 22 text

22 生産性を支えた仕組み 裁量と責任を持った意思決定ができるチーム 
 ● PdMやステークホルダーと一体となっている 
 ○ 朝会にも毎日いる 
 ○ リリース頻度が高いので、朝会で都度デモ＆フィードバックをもらう 
 ○ 細かい認識合わせと意思決定をこの場で決めることができる(大体 


Slide 23

Slide 23 text

23 問題なかった = これからも問題は起きない？ これ以上旧メンバーが 抜けるとまずそう... BE BE FE FE FE FE PdM (new) EM from FE BE (new) FE (new)

Slide 24

Slide 24 text

24 問題なかった = これからも問題は起きない？ これ以上旧メンバーが 抜けるとまずそう... BE BE FE FE FE FE PdM (new) EM from FE BE (new) FE (new) 仕組みだけでなく ちゃんと文化にする 必要がある

Slide 25

Slide 25 text

25 大事にしたい価値観とは 例えば, 個人的には .. CI待ちは無駄な時間だよね 意思決定には説明責任あるよね 作ったものは自分で責任を持つ QAしやすくしたい 人力・属人化するものはなくしたい 価値のあるものを作るべきである PRはすぐレビューする PRとデプロイは小さく 仕事(チケット)のサイズを小さく

Slide 26

Slide 26 text

26 大事にしたい価値観とは 例えば, 個人的には .. CI待ちは無駄な時間だよね 意思決定には説明責任あるよね 作ったものは自分で責任を持つ QAしやすくしたい 人力・属人化するものはなくしたい 価値のあるものを作るべきである PRはすぐレビューする PRとデプロイは小さく 仕事(チケット)のサイズを小さく 聞くと、うんうん、となりますか？ が、チームメンバーも全く同じ気持ちですか？

Slide 27

Slide 27 text

27 実は私たちのチームは暗黙的に合意していたことに気づいた 改善アクションも大事だが アクションが検討される合意が大事 ● 日々のディスカッションで価値観はぎりぎり擦り合わさっていたと思う ● さらにメンバーが入れ変わると暗黙的な価値観の合意は維持できない可能性が あると感じた

Slide 28

Slide 28 text

28 これからどうするか ● チームでの開発について考え方や価値観などの同意を取る ● 同意を作る過程と結果 で目線と意識 を可能な限り揃える ワーキングアグリーメントの作成

Slide 29

Slide 29 text

29 まとめ 開発生産性に対する取り組み、チームでしっかり合意できていますか？ 暗黙的ではなく、ワーキングアグリーメント を作るのはいかがでしょうか？

Slide 30

Slide 30 text

30 おわり