受託1年目が学んだチームが幸せになるPRの作り方

by mp

Slide 1

Slide 1 text

チームが幸せになるプルリクの作り方受託1年目が学んだ PULL REQUEST mp 1

Slide 2

Slide 2 text

自己紹介 mp 名前 @pm99763343 Xアカウント 1年6ヶ月バックエンドエンジニア1年目 PHP歴温泉、ドライブ、日本酒、ビール趣味株式会社クルービット　所属 2

Slide 3

Slide 3 text

前提条件ソースコード管理ツール: GitHub 工数管理ツール: Redmine 3

Slide 4

Slide 4 text

この登壇でお話しないこと commitを積むとは「物語を書く」ことである/asumikamさん https://speakerdeck.com/asumikam/commit-is-the-story 4

Slide 5

Slide 5 text

もくじ１　そもそもチームが幸せになるプルリクとは? ２　地獄の日々３　チームメンバが幸せになるためにプルリクを見直した４　プルリクを変えるとどうなったか?〜そして天国へ〜５　伝えたいこと 5

Slide 6

Slide 6 text

そもそもチームが幸せになるプルリクとは？ 6

Slide 7

Slide 7 text

チームが幸せになるプルリクの定義１. 仕様理解が深まる２. レビュワーの負担が少ない３. チームメンバーの実装速度が上がる(未来の自分を含む) 7

Slide 8

Slide 8 text

ストーリー 8

Slide 9

Slide 9 text

地獄の日々、、、 9

Slide 10

Slide 10 text

２０２２年１１月　株式会社クルービットに未経験で入社 10

Slide 11

Slide 11 text

楽しいチーム開発の日々ではなく、地獄の日々 11

Slide 12

Slide 12 text

PJの進行体制弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終えるプライム案件ゆえにウォータフォールのようなかっちりきまった仕様書がない 12

Slide 13

Slide 13 text

PJの進行体制弊社は受託企業 1チーム1~4人 PJにPLが1人 1ヶ月~半年でPJの開発〜リリースを終えるプライム案件ゆえにウォータフォールのようなかっちりきまった仕様書がない 13

Slide 14

Slide 14 text

PJの進行体制弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終えるプライム案件ゆえにウォータフォールのようなかっちりきまった仕様書がない 14

Slide 15

Slide 15 text

PJの進行体制弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終えるプライム案件ゆえにウォータフォールのようなかっちりきまった仕様書がない 15

Slide 16

Slide 16 text

プルリクの作り方が良くないと、、、まずめちゃくちゃ工数の負荷が増え、チームの雰囲気は悪くなり、仕事は思うように進まず、空は堕ち、大地は割れ、海は枯れ、、、、、、、、、、、、、、、、、 16

Slide 17

Slide 17 text

プルリクプルリクプルリク 17

Slide 18

Slide 18 text

具体的にどのような問題のあるプルリクをあげていたかというと、、、 18

Slide 19

Slide 19 text

こんなプルリクをあげてしまっていた、、、説明欄にチケットのリンクのみを貼っていた説明欄に、「ログイン機能を実装した」や「削除機能を実装した」などの一言だけ 19

Slide 20

Slide 20 text

こんなプルリクをあげてしまっていた、、、説明欄にチケットのリンクのみを貼っていた説明欄に、「ログイン機能を実装した」や「削除機能を実装した」などの一言だけ 20

Slide 21

Slide 21 text

こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連する機能を実装したプルリクを見てさっと把握したいが、結局コードをすみずみまで見ないと把握できない 3. 差し込みのタスクを優先してしばらくたって実装途中のプルリクに戻ると何をしなくちゃいけないのか思い出せない 21

Slide 22

Slide 22 text

こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連するプルリクを見てさっと概要を把握したいが、結局コードをすみずみまで見ないと概要が把握できない 3. 差し込みのタスクを優先してしばらくたって実装途中のプルリクに戻ると何をしなくちゃいけないのか思い出せない 22

Slide 23

Slide 23 text

こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連する機能を実装したプルリクを見て、さっと把握したいが、結局コードをすみずみまで見ないと把握できない 3. 差し込みのタスクを優先して、しばらくたって実装途中のプルリクに戻ると、何をしなくちゃいけないのか思い出せない 23

Slide 24

Slide 24 text

？？？？？？？？？？？？？？？？？？？？？ 24

Slide 25

Slide 25 text

「コミットの履歴を見れば良いのでは？」 25

Slide 26

Slide 26 text

ｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐｔｍｐ 26

Slide 27

Slide 27 text

こんなプルリクを出し続けた結果チームはどうなったのか 27

Slide 28

Slide 28 text

PLのスイッチコストの増大 28

Slide 29

Slide 29 text

レビュー時間の増大 29

Slide 30

Slide 30 text

負のスパイラルレビューの工数が圧迫される開発速度が落ちるスケジュールが圧迫されるみんな余裕が無くなるギスギスした雰囲気、、、 30

Slide 31

Slide 31 text

Slide 32

Slide 32 text

「良いプルリクを意識すれば色々変わってくると思うよ」 32 ※弊社CTO

Slide 33

Slide 33 text

私はチームメンバを自分のプルリクで不幸にしてしまっていた、、、 33

Slide 34

Slide 34 text

チームメンバに幸せになってもらうために自分のプルリクを見返すことにした 34

Slide 35

Slide 35 text

１　プルリクを作る時の粒度２　タイトルの付け方３　説明欄に書くべきことチームが幸せになるプルリクの作り方 35

Slide 36

Slide 36 text

１　プルリクを作る時の粒度２　タイトルの付け方３　説明欄に書くべきことチームが幸せになるプルリクの作り方 36

Slide 37

Slide 37 text

プルリクを作る時の粒度 1. そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切られている大きくしない・複数のことをしないプルリクのタイトルで「編集機能と削除機能を実装した」みたいなのはなるべく避ける「編集機能」と「削除機能」に分けてプルリクをつくるレビュワーの負担を下げる開発速度をあげてマージまでの時間を短くする 37

Slide 38

Slide 38 text

1.プルリクを作る時の粒度そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切られている大きくしない・複数のことをしないプルリクのタイトルで「編集機能と削除機能を実装した」みたいなのはなるべく避ける「編集機能」と「削除機能」に分けてプルリクをつくるレビュワーの負担を下げる開発速度をあげてマージまでの時間を短くする 38

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

1.プルリクを作る時の粒度そもそもプルリクを作る前に適切な粒度でチケットからPRが切られている大きくしない・複数のことをしないプルリクのタイトルで「編集機能と削除機能を実装した」みたいなのはなるべく避ける「編集機能」と「削除機能」に分けてPRをつくるレビュワーの負担を下げる開発速度をあげてマージまでの時間を短くする 41

Slide 42

Slide 42 text

Slide 43

Slide 43 text

１　プルリクを作る時の粒度２　タイトルの付け方３　説明欄に書くべきことチームが幸せになるプルリクの作り方 43

Slide 44

Slide 44 text

2. タイトルの付け方探しやすく端的なタイトルになっている１つの機能にたいして複数個のPRがあるときは章見出しのように「【機能A】外部予約サイトの席を取得して保存できるようにした」などと機能見出し実装内容　　　　に分けて書くようにするタイトルでだらだら実装理由を書かない PRを探しやすくするため実装理由はタイトルではなく説明欄で書く 44

Slide 45

Slide 45 text

2. タイトルの付け方探しやすく端的なタイトルになっている１つの機能にたいして複数個のプルリクがあるときは章見出しのように「【機能A】外部予約サイトの席を取得して保存できるようにした」などと機能見出し実装内容　　　　に分けて書くようにするタイトルでだらだら実装理由を書かないプルリクを探しやすくするため実装理由はタイトルではなく説明欄で書く 45

Slide 46

Slide 46 text

Slide 47

Slide 47 text

外部予約サイトとコースの設定内容が同期されていないとエンドユーザが混乱するためAPIを使ってコース内容を同期させるようにした悪い例 47

Slide 48

Slide 48 text

探しづらいタイトルになっている実装理由がタイトルにだらだら書いてある悪い例 48

Slide 49

Slide 49 text

外部予約サイトとコースの設定内容が同期されていないとエンドユーザが混乱するためAPIを使ってコース内容を同期させるようにした悪い例 49

Slide 50

Slide 50 text

【コース設定】外部予約サイトのコース設定を〇〇システムのコース設定と紐づける処理をした良い例 50

Slide 51

Slide 51 text

【コース設定】外部予約サイトのコース設定を〇〇システムのコース設定と紐づける処理をした良い例機能見出し 51

Slide 52

Slide 52 text

【コース設定】外部予約サイトのコース設定を〇〇システムのコース設定と紐づける処理をした良い例機能見出し実装内容 52

Slide 53

Slide 53 text

【コース設定】外部予約サイトのコース設定を〇〇システムのコース設定と紐づける処理をした良い例 53

Slide 54

Slide 54 text

１　プルリクを作る時の粒度２　タイトルの付け方３　説明欄に書くべきことチームが幸せになるプルリクの作り方 54

Slide 55

Slide 55 text

3.説明欄に書くこと１.チケットのリンク２.実装内容の概要３.レビュワーの確認事項 55

Slide 56

Slide 56 text

マークダウン必須！ 56

Slide 57

Slide 57 text

3.説明欄に書くこと１.チケットのリンク２.実装内容の概要３.レビュワーの確認事項 57

Slide 58

Slide 58 text

チケットのリンクが貼ってあること = 最低条件！ 58

Slide 59

Slide 59 text

3.説明欄に書くこと１.チケットのリンク２.実装内容の概要３.レビュワーの確認事項 59

Slide 60

Slide 60 text

2.実装内容の概要何のどんな機能を実装したのか何がどうなれば成功なのかレビュワーに簡潔に伝えるフロントの動作を見てほしいのであれば動画を貼るモーダルの動き(例) アコーディオンメニューの動き(例) 画面遷移の様子フロントの見た目を見てほしいのであれば画像を貼るどのみちコードのレビューはするが、ブランチに入る前に確認できることが多く無駄なレビュー時間を省ける 60

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

2.実装内容の概要なぜその機能を実装したのかその機能を実装することによって何が解決されたのかまで書いてあるとベスト自分自身のプロダクト理解が深まるのでおすすめ実装した理由が「そこにチケットがあったから」では歩兵から抜け出せない 63

Slide 64

Slide 64 text

ー実装した理由が「そこにチケットがあったから」では歩兵から抜け出せない 64

Slide 65

Slide 65 text

3.説明欄に書くこと１.チケットのリンク２.実装内容の概要３.レビュワーの確認事項 65

Slide 66

Slide 66 text

3.レビュワーの確認事項レビュワーに確認してほしいことコードの動作を確認する前に実行して欲しいコマンドを必ず書く実行する順番も必ずかく「〇〇をしたら〇〇になること」のようにかならず動作と結果をセットにしてかく 66

Slide 67

Slide 67 text

3.レビュワーの確認事項「新しくカラムを追加したので migrateコマンドの実行をお願いします。」 67

Slide 68

Slide 68 text

3.レビュワーの確認事項レビュワーに確認してほしいことコードの動作を確認する前に実行して欲しいコマンドを必ず書く実行する順番も必ずかく「〇〇をしたら〇〇になること」のようにかならず動作と結果をセットにしてかく 68