PRっていいですよね。
起票側だけでなくレビュー側も刺激が得られる貴重な場面だと思います。
私、もうすぐ業界3年目を迎えます。
親身なレビュワー方に恵まれているのもあって、PRを通してとても成長の実感を感じています。
気づけばこの1年間で「起票→マージ」されたPRは350をこえてました…。
（びっくり 😳）
PRで溢れている環境に身を置く前の心境、筆者の環境がPRで溢れ出した時の心境、現在の心境を綴ります。
筆者がPRにおいて重視していることのみを知りたい方はこちら。
PRってなぁに？
PullRequestへの馴染みがない人に一応説明します。
行ったコードの変更をレビューしてもらい、それを元のコードベース（リポジトリ）に統合するためのリクエスト。
要は...。
実装コードを他者に見てもらう。OKだったらマージしてもらう。っていう仕組みです。
はじめまして、 PR。
PRに対して一番最初に思ったことはこれです。
「めっちゃ FB もらえるシステムじゃん。」
細かい作法、新しいテクニック、パフォーマンスへのチューニングだったりと、レビュワーからの指摘がめちゃくちゃありがたい。
PRの数に比例して自身の成長を感じていました。
でも…。
慣れもあいまって、PRに対する「軽視」「勘違い」「不満」を覚えていました。
軽視していたこと
「正直、実装が多少雑でもレビュワーの方が気づいてくれる。」そう思っていたのは事実…。
（ほんとすみませんでした）
スピード感をかなり優先していたので、一時期ちょっとしたケアレスミスが山程ありレビュワーを困らせていたこともありました。
勘違いしていたこと
- 教育の場！！
- 他の人のコードを吸収できる貴重な場！！
本音ですが、品質担保という視点を無視して自分の成長に都合のいい捉え方をしていたのは事実です。
不満に感じていたこと
- かなりこだわって実装したのになんでつっこむの？
- 重箱の隅じゃね…？
- 後ででいいんじゃね？一旦マージしたくない？
レビュワーの真意を捉えきれず、不満を抱えていたこともありました。
意識が変わりました。 PRって「報告書」だよね！！
え、「報告書」なの？
技術面でかなりお世話になっている先輩から以前「PRは報告書と思ってください」と言われたことがありました。
「単なるコードの提出ではなく、報告書のような役割を果たすもの」 だと思います。
変更点やその理由、影響範囲を詳細に記述することで、ドキュメントとして残せますよね。
品質担保
報告書でありながら、品質を保証するための工程管理表の側面を持つとも感じています。
例えば…。
- チーム内で決めているコーディング規約を守れていない状態
- リントのエラーを見過ごしている状態
- SOLID原則に沿っていない状態
この状態を見過ごしたまま、主となるブランチにマージされてしまうってよくないですよね。
チームや開発ルールによって、重視することは異なるかと思いますが、
他エンジニアへの配慮や納品というゴールが待っている以上、品質保証は絶対に必要だと思います。
品質がイマイチな商品を見て、店頭で買う人って稀ですよね。
なんで急に意識が180度も変わった。
結構ここ数ヶ月で刺激されたイベントがありました。
フィードバックもらえる環境は当たり前じゃない
やっぱり一番は フィードバックいただける環境って当たり前じゃない。どんな小さいことでも言ってもらえるのはありがたい です。
FB は当たり前じゃないです。ちょっとした心理的影響だったりプロジェクトの方針だったりでレビューがないがしろになるケースもあります。
（あまり健全じゃないですが。）
レビューする側の機会が増えた
- このまとめ方は、簡略かつどんな作業をしたかわかりやすいな
- 仕様を別ドキュメント化しているのは整理されるからいいな
とか、他人のPRを見ることで刺激が増えました。
（なんだかんだ私もレビューをする機会が増えてきたんですよね。）
逆に、読みづらいPRに触れることでNGなパターンを学ぶこともできました。
勝手な行動…？
「めんどいし書くほどのことでもないからPRには書いてない。でも実は対応してた。」
これって勝手な行動ですよね。
勝手な行動を取るやつってレッテルを貼られるだけでなく、評価の機会を失うことにも繋がります。
決めたこと
この記事を書くにあたって、今までのPRについて振り返ってみました。
概要が伝わるタイトルを書く。
新機能なのか、バグ対応なのか、ドキュメント追加なのか、その程度でいいと思います。
概要がわからないPRは報告書としてやばいです。
「やったことを報告しない」はありえない。
勝手な行動をしない。小学生でも守れますよね。
もちろんどの粒度で記載するかはプロジェクト次第ですが、「追加対応」等に箇条書きで書くだけでも、あるとないじゃ全然違いますよね。
PR内での説明で収まらないなら別でドキュメントを作成する
「簡易なリリースノート」って意味でも、ドキュメント化にへの意義があると思います。
実装の意図は明確に記載する
「かなりこだわって実装したのになんでつっこむの？」
この不満って、レビュワー側が悪いわけではなく単純に私の説明が不足しているだけですよね。
- 「他の機能との統一性を考慮して汎用的に実装しました。」
- 「〜という理由で局所的な対応が適してると判断してこのアプローチを採用しました。」
- etc…
ひとことあるだけで全然違うと思います。
PRの起票にそんなに時間をかけない
日報や報告書に、そこまで時間をかけないですよね。
「思ったよりまとまらない」「前提の仕様を説明したい」っていう場合は、ドキュメントを別で用意したほうがいいのでそちらに工数を割いたほうがいいと思います。
文章以外でコミュニケーションを取る
出社しているなら意図を対面で話して聞く。
リモートならWeb会議で聞く。
報告書に関することって大事なやり取りだと思います。
文章だけじゃ伝わらないこともあると思いますよね。ショート(10分)でも説明する機会があれば全然違うと思います。
※ もちろん文章だけで済むように起票しておく。というのが理想ですよね。
まとめ
エンジニアであればPRって避けては通れないですよね。
レビュー内容によっては、渋い報告書になることもあります。
実装は悪くないのに伝え方が悪くてリジェクトされることもあるかもしれません...。
それでも...。
それでも、僕は今日もPRを出し続けます。
時系列形式で文章を書く機会があまりないので読みづらかったかもしれません。
ここまで読んできただきありがとうございます。