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

※このスライドはPHPカンファレンス香川2024で登壇したトークのものになります。

未経験からエンジニアとして入社し、初めてのチーム開発を経験しました。
1年間の学びで重要だと感じたのはプルリクエスト（PR）の作成方法です。

PRはマージされて終わりのものではなく、後続のメンバーや開発段階のメンバーが参照することへの考慮が必要です。
PRはプロジェクトの重要な履歴であり、その質はチームの健全性に影響します。

美しく、有用で分かりやすいPRを作成することで、
・コミュニケーションエラー減少
・誤った仕様理解に基づく実装ミス削減
・レビュワーのレビュー効率向上が期待でき、チームメンバーの幸福に繋がる
といった効果が期待できます。

このトークでは、経験をもとに学んだ良いPRの具体的な要素やTipsに焦点を当て、良いPRがチームの生産性や雰囲気に与える良い影響についてもお話できればと思っています。

Transcript

1. チームが幸せになる プルリクの作り方 受託1年目が学んだ PULL REQUEST mp 1
2. 自己紹介 mp 名前 @pm99763343 Xアカウント 1年6ヶ月 バックエンドエンジニア1年目 PHP歴 温泉、ドライブ、日本酒、ビール 趣味 株式会社クルービット　 所属 2
3. 前提条件 ソースコード管理ツール: GitHub 工数管理ツール: Redmine 3
4. この登壇でお話しないこと commitを積むとは「物語を書く」ことである/asumikamさん https://speakerdeck.com/asumikam/commit-is-the-story 4
5. もくじ １　そもそもチームが幸せになるプルリクとは? ２　地獄の日々 ３　チームメンバが幸せになるためにプルリクを見直した ４　プルリクを変えるとどうなったか?〜そして天国へ〜 ５　伝えたいこと 5
6. そもそも チームが幸せになるプルリクとは？ 6
7. チームが幸せになるプルリクの定義 １. 仕様理解が深まる ２. レビュワーの負担が少ない ３. チームメンバーの実装速度が上がる(未来の自分を含む) 7
8. ストーリー 8
9. 地獄の日々、、、 9
10. ２０２２年１１月　株式会社クルービットに未経験で入社 10
11. 楽しいチーム開発の日々ではなく、地獄の日々 11
12. PJの進行体制 弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終える プライム案件ゆえにウォータフォールのようなかっちりきまった仕様 書がない 12
13. PJの進行体制 弊社は受託企業 1チーム1~4人 PJにPLが1人 1ヶ月~半年でPJの開発〜リリースを終える プライム案件ゆえにウォータフォールのようなかっちりきまった仕様 書がない 13
14. PJの進行体制 弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終える プライム案件ゆえにウォータフォールのようなかっちりきまった仕様 書がない 14
15. PJの進行体制 弊社は受託企業 1チーム1~4人 PLが1PJに1人 1ヶ月~半年でPJの開発〜リリースを終える プライム案件ゆえにウォータフォールのようなかっちりきまった仕様 書がない 15
16. プルリクの作り方が良くないと、 、 、 まずめちゃくちゃ工数の負荷が増え、 チームの雰囲気は悪くなり、 仕事は思うように進まず、 空は堕ち、大地は割れ、海は枯れ、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 、 16
17. プルリク プルリク プルリク 17
18. 具体的にどのような問題のある プルリクをあげていたかというと、 、 、 18
19. こんなプルリクをあげてしまっていた、 、 、 説明欄にチケットのリンクのみを貼っていた 説明欄に、 「ログイン機能を実装した」や「削除機能を実装した」など の一言だけ 19
20. こんなプルリクをあげてしまっていた、 、 、 説明欄にチケットのリンクのみを貼っていた 説明欄に、 「ログイン機能を実装した」や「削除機能を実装した」など の一言だけ 20
21. こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連する機能を実装したプルリクを見てさっと把握した いが、結局コードをすみずみまで見ないと把握できない 3. 差し込みのタスクを優先してしばらくたって実装途中のプルリクに戻 ると何をしなくちゃいけないのか思い出せない 21
22. こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連するプルリクを見てさっと概要を把握したいが、結 局コードをすみずみまで見ないと概要が把握できない 3. 差し込みのタスクを優先してしばらくたって実装途中のプルリクに戻 ると何をしなくちゃいけないのか思い出せない 22
23. こんなプルリクをあげた弊害として 1. コードをちゃんと読まないと仕様が把握できない 2. 自分の機能に関連する機能を実装したプルリクを見て、さっと把握し たいが、結局コードをすみずみまで見ないと把握できない 3. 差し込みのタスクを優先して、しばらくたって実装途中のプルリクに 戻ると、何をしなくちゃいけないのか思い出せない 23
24. ？？？？？？？ ？？？？？？？ ？？？？？？？ 24
25. 「コミットの履歴を見れば良いのでは？」 25
26. ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ ｔｍｐ 26
27. こんなプルリクを出し続けた結果 チームはどうなったのか 27
28. PLのスイッチコストの増大 28
29. レビュー時間の増大 29
30. 負のスパイラル レビューの工数が 圧迫される 開発速度が落ちる スケジュールが 圧迫される みんな 余裕が無くなる ギスギスした 雰囲気、 、 、 30
32. 「良いプルリクを意識すれば 色々変わってくると思うよ」 32 ※弊社CTO
33. 私はチームメンバを自分のプルリクで 不幸にしてしまっていた、 、 、 33
34. チームメンバに幸せになってもらうために 自分のプルリクを見返すことにした 34
35. １　プルリクを作る時の粒度 ２　タイトルの付け方 ３　説明欄に書くべきこと チームが幸せになるプルリクの作り方 35
36. １　プルリクを作る時の粒度 ２　タイトルの付け方 ３　説明欄に書くべきこと チームが幸せになるプルリクの作り方 36
37. プルリクを作る時の粒度 1. そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切 られている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてプルリクをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 37
38. 1.プルリクを作る時の粒度 そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切 られている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてプルリクをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 38
39. 1.プルリクを作る時の粒度 そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切 られている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてプルリクをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 39
40. 1.プルリクを作る時の粒度 そもそもプルリクを作る前に適切な粒度でチケットからプルリクが切 られている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてプルリクをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 40
41. 1.プルリクを作る時の粒度 そもそもプルリクを作る前に適切な粒度でチケットからPRが切られ ている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてPRをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 41
42. 1.プルリクを作る時の粒度 そもそもプルリクを作る前に適切な粒度でチケットからPRが切られ ている 大きくしない・複数のことをしない プルリクのタイトルで「編集機能と削除機能を実装した」みた いなのはなるべく避ける 「編集機能」と「削除機能」に分けてPRをつくる レビュワーの負担を下げる 開発速度をあげてマージまでの時間を短くする 42
43. １　プルリクを作る時の粒度 ２　タイトルの付け方 ３　説明欄に書くべきこと チームが幸せになるプルリクの作り方 43
44. 2. タイトルの付け方 探しやすく端的なタイトルになっている １つの機能にたいして複数個のPRがあるときは章見出しのように 「 【機能A】外部予約サイトの席を取得して保存できるようにした」 などと 機能見出し 実装内容 　　　　に分けて書くようにする タイトルでだらだら実装理由を書かない PRを探しやすくするため 実装理由はタイトルではなく説明欄で書く 44
45. 2. タイトルの付け方 探しやすく端的なタイトルになっている １つの機能にたいして複数個のプルリクがあるときは章見出しの ように「 【機能A】外部予約サイトの席を取得して保存できるよう にした」などと 機能見出し 実装内容 　　　　に分けて書くようにする タイトルでだらだら実装理由を書かない プルリクを探しやすくするため 実装理由はタイトルではなく説明欄で書く 45
46. 2. タイトルの付け方 探しやすく端的なタイトルになっている １つの機能にたいして複数個のプルリクがあるときは章見出しの ように「 【機能A】外部予約サイトの席を取得して保存できるよう にした」などと 機能見出し 実装内容 　　　　に分けて書くようにする タイトルでだらだら実装理由を書かない プルリクを探しやすくするため 実装理由はタイトルではなく説明欄で書く 46
47. 外部予約サイトとコースの設定内容が同期されて いないとエンドユーザが混乱するためAPIを使っ てコース内容を同期させるようにした 悪い例 47
48. 探しづらいタイトルになっている 実装理由がタイトルにだらだら書いてある 悪い例 48
49. 外部予約サイトとコースの設定内容が同期されて いないとエンドユーザが混乱するためAPIを使っ てコース内容を同期させるようにした 悪い例 49
50. 【コース設定】外部予約サイトのコース設定を〇 〇システムのコース設定と紐づける処理をした 良い例 50
51. 【コース設定】外部予約サイトのコース設定を〇 〇システムのコース設定と紐づける処理をした 良い例 機能見出し 51
52. 【コース設定】外部予約サイトのコース設定を〇 〇システムのコース設定と紐づける処理をした 良い例 機能見出し 実装内容 52
53. 【コース設定】外部予約サイトのコース設定を〇 〇システムのコース設定と紐づける処理をした 良い例 53
54. １　プルリクを作る時の粒度 ２　タイトルの付け方 ３　説明欄に書くべきこと チームが幸せになるプルリクの作り方 54
55. 3.説明欄に書くこと １.チケットのリンク ２.実装内容の概要 ３.レビュワーの確認事項 55
56. マークダウン必須！ 56
57. 3.説明欄に書くこと １.チケットのリンク ２.実装内容の概要 ３.レビュワーの確認事項 57
58. チケットのリンクが貼ってあること = 最低条件！ 58
59. 3.説明欄に書くこと １.チケットのリンク ２.実装内容の概要 ３.レビュワーの確認事項 59
60. 2.実装内容の概要 何のどんな機能を実装したのか 何がどうなれば成功なのかレビュワーに簡潔に伝える フロントの動作を見てほしいのであれば動画を貼る モーダルの動き(例) アコーディオンメニューの動き(例) 画面遷移の様子 フロントの見た目を見てほしいのであれば画像を貼る どのみちコードのレビューはするが、ブランチに入る前に 確認できることが多く無駄なレビュー時間を省ける 60
61. 2.実装内容の概要 何のどんな機能を実装したのか 何がどうなれば成功なのかレビュワーに簡潔に伝える フロントの動作を見てほしいのであれば動画を貼る モーダルの動き(例) アコーディオンメニューの動き(例) 画面遷移の様子 フロントの見た目を見てほしいのであれば画像を貼る どのみちコードのレビューはするが、ブランチに入る前に 確認できることが多く無駄なレビュー時間を省ける 61
62. 2.実装内容の概要 何のどんな機能を実装したのか 何がどうなれば成功なのかレビュワーに簡潔に伝える フロントの動作を見てほしいのであれば動画を貼る モーダルの動き(例) アコーディオンメニューの動き(例) 画面遷移の様子 フロントの見た目を見てほしいのであれば画像を貼る どのみちコードのレビューはするが、ブランチに入る前に 確認できることが多く無駄なレビュー時間を省ける 62
63. 2.実装内容の概要 なぜその機能を実装したのか その機能を実装することによって何が解決されたのかまで書いて あるとベスト 自分自身のプロダクト理解が深まるのでおすすめ 実装した理由が「そこにチケットがあったから」では歩兵 から抜け出せない 63
64. ー 実装した理由が「そこにチケットがあったか ら」では歩兵から抜け出せない 64
65. 3.説明欄に書くこと １.チケットのリンク ２.実装内容の概要 ３.レビュワーの確認事項 65
66. 3.レビュワーの確認事項 レビュワーに確認してほしいこと コードの動作を確認する前に実行して欲しいコマンドを必ず書く 実行する順番も必ずかく 「〇〇をしたら〇〇になること」のようにかならず動作と結果を セットにしてかく 66
67. 3.レビュワーの確認事項 「新しくカラムを追加したので migrateコマンドの実行をお願いします。 」 67
68. 3.レビュワーの確認事項 レビュワーに確認してほしいこと コードの動作を確認する前に実行して欲しいコマンドを必ず書く 実行する順番も必ずかく 「〇〇をしたら〇〇になること」のようにかならず動作と結果を セットにしてかく 68
69. プルリクを変えるとどうなったか？ 〜そして天国へ〜 69
70. プルリクを変えるとどうなったか？ 〜そして天国へ〜 70
71. 伝えたいこと 71
72. たかがプルリク、 されどプルリク 72
73. ご清聴ありがとう ございました！！！ 73