SESのコードレビューの受け方｜指摘を4種類に仕分けて凹まず成長に変える

レビューで指摘が並んだ画面を見て、「自分は向いていないのかもしれない」と手が止まったことはないでしょうか。私にも、そういう時期がありました。

私はSESエンジニアとして5年ほど、4社の現場を経験しました。3社目の保守改善では約1年半、コードレビューを毎回受けています。ただ、現場によってはレビュー自体がない、という話も珍しくありません。

今回は、レビューの受け方と、指摘を成長につなげる方法、現場による差を、実体験を交えてお伝えします。

目次

1. SESのコードレビューの受け方で最初に決めること｜指摘は「人」ではなく「コード」への意見です
2. 3社目のレビュー環境
3. 最初の1か月は、指摘を「ダメ出し」と受け取っていました
4. 指摘は4種類に仕分けると、受け止め方が決まります
5. 指摘を4種類に分ける
6. 仕分けで一番大切なのは「現場の決まり」の扱い
7. レビューの受け方｜依頼から返信までの5つの手順
8. 指摘を成長に変える｜同じ指摘を二度受けないためのノート
9. 指摘ノートの作り方
10. 指摘の数は、半年で減っていきました
11. 「指摘してくれる人」がいること自体の価値
12. コードレビューの現場による差｜ない現場、形だけの現場
13. 現場によって、レビューの形はこれだけ違います
14. レビューがない現場で、自分でできること
15. レビューが怖い、凹んだときの対処
16. 反論して、空気が悪くなった一回
17. 凹んだときの具体的な対処
18. まとめ

SESのコードレビューの受け方で最初に決めること｜指摘は「人」ではなく「コード」への意見です

結論レビューの指摘は、書いた人の評価ではなく、コードを良くするための意見です。そう割り切ると、指摘を受けて凹む時間が減り、直す時間に回せます。

最初に、私の3社目の環境と、レビューの受け方を大きく変えた最初の失敗を書きます。そのうえで、受け止め方の軸を整理します。

3社目のレビュー環境

3社目は二次請けの現場で、金融系のWebサイトの保守改善を後半の約1年半担当していました。フロントとサーバー側の改修依頼への対応と、障害調査・不具合修正が仕事です。

依頼ごとに担当が割り振られ、実装が終わると、チームの先輩や協力会社の方にレビューしてもらいます。レビューは毎回受ける決まりで、これは小さな修正でも例外がありませんでした。フレームワークは、古い作りのObjectWorksです。

同じ現場には、5年以上いる40代くらいの協力会社の方がいました。保守チームには、途中から自社の後輩も入っています。

最初の1か月は、指摘を「ダメ出し」と受け取っていました

保守改善に入った最初の1か月は、1件の依頼につき、感覚的には10件前後の指摘をもらっていました。厳密に数えたわけではありませんが、画面の修正が数行でも、コメントが並んだ印象です。

指摘の内容は、次のような類のものでした。

• 命名の揃え方
• 既存の書き方との違い
• エラー時の処理の抜け

動くかどうかではなく、「この現場のコードとして適切か」を見られていたわけです。

当時の私は、指摘が付くたびに「ミスをした」と受け取っていました。直す作業よりも、指摘を読んで落ち込む時間のほうが長かったと思います。

あるとき、指摘されているのは私ではなくコードのほうだ、と切り分けて考えるようになりました。指摘は、私の評価ではなく、コードの話をしていると割り切ったところから、凹む時間が減っています。

Googleが公開しているエンジニアリング・プラクティスの文書でも、レビューの目的は完璧なコードを求めることではなく、時間をかけてコードベース全体の健全性を良くし続けることだと説明されています（出典: The Standard of Code Review｜Google Engineering Practices）。レビュアーは相手を採点しているのではなく、コードの質の維持という共通の目的で見ている、という立場です。

指摘は4種類に仕分けると、受け止め方が決まります

指摘を一律に受けると、重い指摘と軽い指摘が区別できず、すべてに疲れます。ここでは、私が整理した4つの仕分けと、それぞれの返し方を書きます。

指摘を4種類に分ける

指摘を読んだら、まず種類を判断します。種類が分かれば、返す内容と優先順位も決まります。

この仕分けは、Googleの文書にある考え方に近いものです。同じ文書では、些細な指摘には「Nit:」のような目印を付けて、必須ではないと示すことが勧められています。

目印がない現場でも、「個人的には」「できれば」といった言い回しの指摘は、好みに近いと判断できます。判断に迷うときは、レビュアーに「必須ですか」と聞いて構いません。

仕分けで一番大切なのは「現場の決まり」の扱い

4種類のうち、新しく現場に入った人が一番つまずくのは、「現場の決まり」です。文書になっていない暗黙の決まりも多く、知らないものは、自分では気づけません。

たとえばログの出し方や、例外のまとめ方は、既存のコードを読んで初めて分かる類の決まりです。同じ種類の指摘を2回受けたら、「これは決まりだ」と判断して、出どころを先輩に聞くのが早いと思います。

質問の仕方や出し先の考え方は、別の記事にもまとめています。

関連記事客先常駐で質問できない｜相談相手の作り方と聞き方の工夫客先常駐で質問できない・相談相手がいないと感じたら、質問をどこに置くかを決めると動きやすくなります。在宅中心の現場で隣席に声をか…

レビューの受け方｜依頼から返信までの5つの手順

仕分けの考え方が分かっても、実際のレビューの流れの中で動けなければ意味がありません。ここでは、毎回レビューを受ける中で私が意識してきた手順を、依頼を出す前から返信までの順に書きます。

1. 出す前に、自分で差分を読む他人のコードのつもりで、自分の差分を一度読み直します。これだけで、命名の揺れや不要な行といった指摘は、かなり防げます。
2. 変更の意図を一言添えて出す「何のために、どこを変えたか」を先に書きます。意図が分からない差分は、レビュアーが余計な推測をして、指摘がずれます。
3. 指摘は、まず全部読んでから返す1件ずつ反応せず、最後まで読み、種類に仕分けてから対応します。途中で感情的に返信しないための歯止めにもなります。
4. 分からない指摘は、直す前に聞く意図が読み取れないまま直すと、的外れな修正が入ります。「この指摘は、◯◯という意味でしょうか」と短く聞くほうが早いです。
5. 直したら、何をどう直したかを返す「修正しました」だけで終えず、直し方と、採用しなかった指摘があればその理由を一言添えます。

Googleの文書にも、指摘を個人への攻撃と受け取らないこと、怒りに任せて返信しないこと、分からなければ質問すること、説明をレビューの返信に書くのではなく、まずコードを分かりやすく直すことが書かれています（出典: How to Handle Reviewer Comments｜Google Engineering Practices）。

現場で身につけた手順は、この文書とほぼ同じ方向でした。自分で試行錯誤して行き着いた型が、公開された指針と一致していたので、今の現場でも、この5つは変えていません。

特に返信は、結論だけでなく理由を一言添えるのがコツです。「仕様どおりです」だけでは相手に意図が伝わらず、やり取りが何往復にも伸びがちです。

指摘を成長に変える｜同じ指摘を二度受けないためのノート

レビューを受けるだけでは、成長は止まりやすいものです。同じ指摘を何度も受ける状態から抜けるには、指摘を記録して、振り返る仕組みが要ります。

指摘ノートの作り方

レビューで受けた指摘は、テキストファイルに残すのがおすすめです。形式は簡単で、1行に「日付・種類・指摘の要点・次回の自分への一言」を書くだけです。

2週間に一度、種類ごとに眺めます。同じ種類の指摘が3回以上並んでいれば、それは単発のミスではなく、自分の癖です。癖が分かれば、出す前のセルフチェックの項目に加えられます。

指摘の数は、半年で減っていきました

毎回レビューを受け続けた結果、指摘は数も中身も変わりました。あくまで振り返っての感覚値ですが、1件あたりの指摘数は次のように推移した印象です。

1件の依頼あたりの指摘数の推移です。厳密に数えたものではなく、振り返っての感覚値です。

数が減っただけでなく、指摘の中身が変わった点が重要でした。最初は名前や書き方の指摘が大半でしたが、半年後には「この変更は、他の画面に影響しないか」といった設計寄りの指摘が中心になりました。

指摘が減るのはゴールではありません。指摘の質が上がることが成長だと、私は受け止めています。影響範囲の見落としの指摘は、保守の現場でリリースが重くなる理由ともつながっています。

関連記事SESの保守改修でリリースが重い理由｜影響範囲調査は半日〜1日かかった現場SESの保守改修でリリースが重くなる理由を、保守改善約1年半の実体験で整理します。影響範囲調査のやり方、証跡とドキュメントの多さ…

「指摘してくれる人」がいること自体の価値

もう一つ、あとから気づいたことがあります。私は、毎回きちんと指摘してくれる人がいる環境にいたのだと思います。

レビューの指摘は、時間を使ってもらって初めて出るものです。毎回読んで指摘してくれるのは、実はありがたいことで、当時の私は、その価値に気づいていませんでした。

コードレビューの現場による差｜ない現場、形だけの現場

ここまでは、レビューがきちんとある現場の話でした。ここからは、現場による差と、レビューがない・形だけの現場にいる場合の動き方を整理します。

私が詳しく書けるのは、毎回レビューを受けた3社目の話です。ほかの現場の具体的な状況は書かず、以下は私の考えとして読んでください。

現場によって、レビューの形はこれだけ違います

SESでは、レビューの有無や質は、現場ごとに違うと考えておくのが安全です。客先の開発ルールとして決まっている場合もあれば、リーダーの裁量だけの場合、そもそも誰も見ない場合もあり得ます。

レビューが機能している現場

• 毎回、決まった人が見る
• 指摘が記録に残る
• 観点に、現場の決まりと設計が入る
• 直した後の確認まである

形だけ、またはない現場

• 「動けばOK」で通る
• 見る人が決まっていない
• 指摘が口頭で残らない
• 自分で気づくしかない

指摘が多い現場が、必ず良い現場とも限りません。好みの指摘ばかりで、設計やバグの観点が抜けているレビューもあります。多さではなく、観点の中身を見るのが大事です。

レビューがない現場で、自分でできること

「レビューがないのでスキルがつかない」と悩む人は多いと思います。仕組みがない現場で、個人の工夫でできることを挙げます。

3つ目の「個別に頼む」は、勇気が要ります。ただ、断られても失うものは小さく、通れば毎回の習慣にできる可能性があります。スキルが身につかないという悩み全般は、別の記事に整理しました。

関連記事SESでスキルが身につかない理由｜移行と保守で見えた、積める現場の見分け方SESでスキルが身につくかどうかは、担当が「手順を実行する役」か「自分で判断して完結させる役」かで変わります。データ移行と保守改…

レビューが怖い、凹んだときの対処

結論凹んだときは、返信を急がず、指摘を種類で仕分けてから返します。感情が動いている間に返した文章は、あとで読み返して後悔しがちです。

指摘の中身以前に、レビューそのものが怖いと感じる時期は、誰にでもあります。ここでは、私が実際に凹んだ場面と、そのときの対処を書きます。

反論して、空気が悪くなった一回

保守改善の中盤、納得できない指摘が続いた時期がありました。そのとき、「前の担当者のコードがこうなっているので、合わせました」という趣旨の返信をしたことがあります。

事実ではありましたが、書き方が悪く、言い訳に見える返信でした。結局その指摘は私が直す形になっています。

後から読み返すと、指摘そのものは妥当でした。返信を書く前に、少し置くか、せめて種類の仕分けをする時間をとっていれば、結果は変わっていたはずです。既存コードに合わせた、という事情は、言い訳ではなく確認の質問として出すほうが通ります。

凹んだときの具体的な対処

この失敗以降、凹んだときのルールとして意識しているのは次の3つです。

指摘が10件並んでいても、バグや抜けに当たるものは、多くの場合ごく一部です。残りは決まりと読みやすさで、直せば済むものです。件数の多さと、ミスの深刻さは別だと分かると、気持ちが軽くなりました。

それでも、指摘の言い方がきつくて、人格を否定されたように感じる場合もあります。それは、コードの話から外れているので、無理に受け止めなくて構いません。リーダーや営業に相談する選択肢も、持っておいてよいと思います。

まとめ

SESのコードレビューは、現場によって有無も質も違います。受ける側にできるのは、指摘を「人への評価」ではなく「コードへの意見」として扱い、種類に仕分けて、記録することです。

私の場合、約1年半のレビューで、1件あたりの指摘は体感で10件前後から2〜3件に減りました。そして、指摘の中身が、書き方から設計へ移っていったことが、一番の成長の実感でした。

今レビューで凹んでいる方は、まず直近の指摘を10件ほど、4種類に仕分けてみてください。意外と、本当に重い指摘は少ないことに気づくはずです。レビューのない現場にいる方は、今週の差分を1件だけ、誰かに見てもらうところから始めてみてください。