プルリクエストレビューを終わらせるためのチーム体制 / The Team for Completing Pull Request Reviews

by ハトネコエ

Slide 1

Slide 1 text

Α͑͜ プルリクレビューを終わらせるためのチーム体制 @yokoe24

Slide 2

Slide 2 text

ࣗݾ঺հ よこえ • X : @yokoe24 （フォローを返すタイプの人類） • ラブグラフの執行役員CTO （MIXIの子会社） • グロービス経営大学院でちょうど１年経った大学院生

Slide 3

Slide 3 text

ϥϒάϥϑ ( https://lovegraph.me )

Slide 4

Slide 4 text

ΈͯͶΞϓϦͰ͸…

Slide 5

Slide 5 text

ϥϒάϥϑ • 出張撮影サービスを提供 • ウェブやみてねアプリを通して撮りたい場所を指定しつつ好みのカメラマンに依頼できる • もともとはカップル撮影で人気が出たサービスだが、現在は家族撮影で幅広く使用される

Slide 6

Slide 6 text

̌ はじめに

Slide 7

Slide 7 text

ϗϯϚ͝ΊΜ • そんなに目新しい話は開発体制が整っている会社だとないかも……ごめん……🥺 • 「これはやってなかったな」というものが１つでもありましたら幸いです☺

Slide 8

Slide 8 text

͜Ε͔Β࿩͢͜ͱ 1. 方針を決めることの大事さ 2. 情報が届くことの大事さ 3. 時間を作ることの大事さ 4. おわりに

Slide 9

Slide 9 text

̍ 方針を決めることの大事さ

Slide 10

Slide 10 text

ίʔσΟϯάϧʔϧ • 「方針」は例えば Linter の設定だったり、どの会社でも共通する統一解があるわけではないもの • 「方針」を決める責任者がいて、意見を聞きつつ決断する必要がある（⇒CTOやテックリードなどが負う）

Slide 11

Slide 11 text

ܾΊΔඞཁͷ͋Δํ਑ • ESLint や Stylelint などの Linter のどの設定をオンにするか • Linter にない決めごと：例）routing の記述をABC順に並べる例）Rails の includes の使用を避ける Custom Rule を作ってもいいが、まずはドキュメントに書くなど最小の工数

Slide 12

Slide 12 text

ํ਑͕ͳ͍ͱ…… • レビューする人によって方針が異なって、レビューされる側が困惑 • レビュアーは同じようなコメントを違う相手に何度もすることになって疲れてしまう • コーディングスタイルを巡って長い議論になってしまうことも

Slide 13

Slide 13 text

ϓϧϦΫςϯϓϨ • プルリクエストに何を書いてもらいたいか、ということを決めるのも大事 • プルリクテンプレートはその方針を落とし込んだものとなる • レビューする人にとって知りたい情報が書かれていると、レビューの往復回数が減る

Slide 14

Slide 14 text

ϥϒάϥϑͰ͸ ͜Μͳײ͡ˠ

Slide 15

Slide 15 text

ॻ͖΍͢͞΋େࣄ • プルリクエストは何度も書くものなので、書きやすさも大事 • HTMLコメントも活用して、書いてほしいことを示しつつも編集の必要な文字数はテンプレ内にできるだけ少なく • https://zenn.dev/lovegraph/ articles/a974f188c6cbb2

Slide 16

Slide 16 text

ϨϏϡʔपΓͷϧʔϧ • 新入社員やインターンは、自分がレビューしていい立場なのか迷ってしまうこともあるので、研修ドキュメントで明言する • 複雑な議論が起こりそうなときに Slackでのやり取りを推奨するルールもレビューを早めるために大事かも？

Slide 17

Slide 17 text

̎ 情報が届くことの大事さ

Slide 18

Slide 18 text

৘ใ͸ pull ΑΓ push • 「情報を取りに行く人は少ない」 ↑ この前提は考えとして大事 • 「レビューをすることはイイこと！」と伝えつつも、一方で「リマインドをしないのにレビューが必ずされると思ってはいけない」ということもチーム内に啓蒙していく

Slide 19

Slide 19 text

ϥϒάϥϑͰ͸ ͜Μͳײ͡ˠ

Slide 20

Slide 20 text

Slack΁ࣗಈϦϚΠϯυ • インターンメンバーは勤務時間も限られているので、リマインドに限界 • https://github.com/nekonenene/gh-pull- requests-slack-reminder を使って、「レビュー依頼中」ラベルが付いたプルリクが Slack チャンネルに投稿されるように！

Slide 21

Slide 21 text

詳しくはこちら → https://zenn.dev/lovegraph/articles/928955bdf03c2f

Slide 22

Slide 22 text

̏ 時間を作ることの大事さ

Slide 23

Slide 23 text

࣌ؒΛͭ͘Δ • それでもやっぱり、みんなレビューよりも開発をやりがちでプルリクエストは溜まってしまう • もはやこれは自然の摂理 • というわけで、みんなでレビューをする時間！

Slide 24

Slide 24 text

ʮϨϏϡʔձʯͷࢼΈ • 週に３回、30分「レビュー会」というミーティングを始めてみた • プルリク作成者がどういうプルリクか説明したあとで、他全員がレビューをする時間。多くのマージを目指す • レビュー会のあとも流れでレビューを続けられるよう、開催時間も大事

Slide 25

Slide 25 text

ϝϦοτɾσϝϦοτ • その場でコードの意図の質問ができたり、直してほしいところを説明するときもやりやすかったりと、レビューの負荷が下がった • 「レビュー会があるから」と、それ以外の時間にレビューしなくなる人が生まれる可能性も？

Slide 26

Slide 26 text

̐ まとめ

Slide 27

Slide 27 text

·ͱΊ • レビュアーのレビューをおこなうことへのモチベーションが上がらない • やり取りの往復に時間がかかる • 時間＝往復回数 × １往復の時間 • プルリクがなかなかApproveされないとき、上の２つがほとんどの原因 • これを解決できるチーム施策が大事

Slide 28

Slide 28 text

必要なこと取り組みプルリクの存在を知らせる・レビューされる側のリマインド意識と、それを促すドキュメントを用意・Slackへの自動リマインド通知レビューをおこなうまでの心理的障壁を低くする・誰でもしていいことを明記、研修・レビュー会・１プルリクのDiffの目安を明文化やり取りの往復にかかる時間を減らす・Linterの導入・遵守・Linter以外の開発ルールのドキュメント化。議論ではSlackも推奨・プルリクテンプレ・レビュー会