はじめに

個人的に、ソースコードレビューでの指摘自体は悪いことではなく、むしろプロダクトの後々の品質維持を考えると重要なことだと考えています。また、指摘から学べることも多々あり、有益な指摘をもらうことでエンジニアとしての知識・技術力の向上にも寄与すると考えています。この感覚は、私だけでなく多くのエンジニアで共通の感覚なのかなと思います。
とはいえ、（上記は理解しているものの）あまりにもその指摘数が多いと修正する側の神経がすり減ることもある、というのが現実です。

本記事では、プルリクエストの指摘数が慢性的に多く修正するのが大変、、、、、という方向けに、どのように指摘数を減らしていけば良いのか、を考えてみようと思います。

考え方

非常にシンプルです。以下の要領で考えます。

指摘内容を分析する
　　1.1. 指摘内容を抽象化する
　　1.2. 具体的な指摘内容を抽象化したものに振り分ける
　　1.3. なぜそのような指摘を受けたのか原因を深堀りする
対応策を考えてみる

以降で1つずつ見ていきたいと思います。

1. 指摘内容を分析する

1.1. 指摘内容を抽象化する

まずは指摘内容を抽象化します。自分の経験上、以下のような観点で抽象化できると考えています。
※他の観点があれば、それも追加しても良いかと思います。

誤字脱字（タイポ）
プログラミング知識不足
コーディング規約違反
要件・仕様誤認識
影響範囲考慮漏れ

1.2. 具体的な指摘内容を抽象化したものに振り分ける

プルリクエストに挙げられた具体的な指摘内容を、「1.1. 指摘内容を抽象化する」で挙げた項目に割り振っていきます（当てはめていきます）。すると、どういった内容の指摘が多いのかが可視化されます。

1.3. なぜそのような指摘を受けたのか原因を深堀りする

この作業の最後に、なぜそのような指摘を受けたのか、原因を深堀りしていきます。すると、この時点で、以下のような形で可視化されると思います。

上記は、イメージですが、この例では圧倒的に？プログラミングの知識不足が原因で指摘を受けていることがわかります。

2. 対応策を考えてみる

指摘内容を分析してみると、上記のように自分がよく指摘をうけるところの傾向が見えてきます。つまり、そこは自分のウィークポイントでもあると考えられます。あとは、そこに対してどのような対策を打つかを検討し、次の機会に活かせることができれば、少しずつではあるもののより質の高いレビューが出せると思います。

まとめ

タイトルは「プルリクエストの～」となっていますが、この考え方は全ての成果物（設計書、テスト仕様書等）に共通していると思います。また、この考え方は仕事における所謂「問題解決」とも言えます。指摘内容が多くあれもこれも対応しているうちに、俯瞰することを忘れがちになりますが、そういった時こそ一度立ち止まって冷静に分析してみると良いかと思います。

以上です。