PRと向き合う意識について

人によってPR (Pull Request) と向き合うときの意識は異なります。
PRにどのような意識で向き合うか、チームで共通認識を持っておこう、という話です。

私のPRの向き合い方

PRをレビューするとき、PRを作成するときに、どのような意識で取り組んでいるのか、私の向き合い方を書いておきます。

明日PRを作った人がチームを離れても継続して開発できるように

これはPRをレビューするときの意識です。
会社の業務として書いたコードは個人のものではなく会社の資産です。
だからPR内容を資産として評価できるかという視点を持ってフィードバックしています。

レビューコストはPRの大きさや説明の充実具合に大きく影響を受けます。
小さなPRであればおおよそ10分前後でレビューできますが、大きく複雑な作業を含むPRだと数時間掛かります。

レビューしていてPRの説明が足りないと思ったら、具体的に欲しい情報を追記してもらうようお願いしますが、そんなに簡単ではないこともあります。自分の作業を俯瞰して言語化することが苦手な人もいるので、レビューにはメンバーを育てる覚悟を持つ必要があると思っています。

明日チームを離れてもいいようにPRをレビューしよう。
永遠に一緒に働くようにメンバーを育てよう。

ガンジーの教えみたいですね。

明日死ぬかのように生きよ、永遠に生きるかのように学べ

情報を持っている人が積極的に情報提供したほうが効率的

これはPRを作成するときの意識です。
情報を持っている人というのは、プログラミング経験が長いかどうかという話ではありません。
コードを書いた人がレビューで読む人よりも、そのコードの設計について多くのことを知っているのが普通です。そのため、PRを作成する人のスキルやレビューする人のスキルとは関係なく、PRを作成する人は「実装していて考慮したこと」をできるだけ書いたほうがよいと思っています。

実装していて考慮したことにはいろいろなものが含まれます。

• PRの前提となるコンテキスト
• コードの設計方針
• 検討した代替案
• etc...

今回の記事ではあくまで意識にフォーカスしたいので、よりよいPRの作り方については別の記事を探してください。

レビューのためにこういった情報をレビュアーが想像するより、PRを作成するメンバーが書いたほうが早いケースがほとんどだと考えています。そうすることでチーム全体で考えたときのレビューコストが削減できます。また後からPRを読み返す機会があったときにも重宝します。

私のPR作成のコストは10分〜1時間ぐらいです。これはセルフレビューも含めた時間です。PRの説明を整える過程で気がついたことを修正することもあります。もちろんその修正についてもPRの説明に記述します。

PRと向き合う意識の４象限

ここからが本題です。
PRの書き手と読み手の意識が揃っていないと、いろいろと無駄になるな〜と思っています。

PRの書き手・読み手、それぞれの意識の高い・低い、それらを4象限として考えると、次のようになります。

	書き手の意識が高い	書き手の意識が低い
読み手の意識が高い	レビューしやすい フィードバックしやすい	レビューに時間が掛かる...
読み手の意識が低い	PRを書くコストが無駄になる...	レビューは形だけ コストは掛かっていないが属人化が進む

書き手と読み手のコミュニケーションとして見ると、こんな感じだと思います。

	書き手の意識が高い	書き手の意識が低い
読み手の意識が高い	❤️	💔
読み手の意識が低い	💔	🩵

PRの意識にギャップがあるといいことがありません。
意識の高いメンバーは意識を高く保ち続けるモチベーションが削られていきます。

PRのプロセスにあまり価値を感じていないメンバーには、
細やかなフィードバックに「面倒・うるさい」という気持ちになるかもしれません。

まとめ

PRについてどれぐらいの意識で向き合うかについて、しっかりチームで話し合って認識を合わせたいですね。