プログラマのコードレビューでボコボコにされる人は多いです。レビューでの見方について本記事で解説します。プログラマーの業務はプログラミングをして終わりではありません。実際に実装したコードをレビューされることも良くあります。しかしコードレビューの中にはあまりにも過度な批判も多く、その人をぼこぼこに攻撃するものもあれば、人格否定と思われるようなものまであります。
コードレビューにおける人格攻撃
これはプログラミング現場でよく起こる心理的・コミュニケーション上の問題で、技術的指摘と人格攻撃を区別することが重要です。整理して解説します。現場で使ってみた感じ、思ったいじょうに以下の事はよくあります。
1. コードレビューとは
- 開発者が書いたコードを、他の開発者がチェックして改善点を指摘するプロセス
- 主な目的：
- バグの早期発見
- コード品質の向上
- チーム内での知識共有
2. 本来のレビューのポイント
- コードに対する指摘が中心
- 「変数名がわかりにくい」「関数が複雑すぎる」
- 改善策や理由を添える
- 「この関数は複雑なので、分割すると可読性が上がる」
- 個人攻撃ではなく、コード改善のための建設的フィードバックが基本
3. 人格攻撃（Personal Attack）の例
人格攻撃とは、コードではなく、書いた人そのものを批判することです。レビュアーは人格否定や書くコード以外の面で攻撃をします。開発で協調しようという姿勢は皆無。
典型例
- 「このコードを書いたあなたは理解力がない」
- 「こんな書き方をする人は仕事ができない」
- 「常識がない」「初心者丸出し」など、スキルや性格を攻撃
影響
- モチベーションの低下
- チーム内の心理的安全性の喪失
- 建設的な議論ができなくなる
4. 技術的指摘との違い
| 技術的指摘 | 人格攻撃 |
|---|---|
| 「この関数は長すぎるので分割した方が可読性が上がる」 | 「あなたは関数を分割できない人だ」 |
| 「変数名をもう少し具体的にすると他人が理解しやすい」 | 「あなたの命名センスは最悪だ」 |
| 「ここはエラー処理が抜けているので追加してください」 | 「あなたはミスが多すぎる」 |
→ **「コードにフォーカスしているか」「改善策があるか」**が判断の基準
5. 人格攻撃を防ぐ方法
- 指摘はコードに限定する
- 「誰が書いたか」ではなく「コードそのもの」を話す
- 改善策をセットで伝える
- 「こうすると良くなる」＋理由
- 言葉遣いに注意する
- 「〜すべき」「〜してください」と命令口調を避ける
- 「〜した方が読みやすくなります」と柔らかく表現
- 心理的安全性を意識
- チームで「批判はコードに対してのみ」というルールを共有
- 第三者レビューやペアレビューを活用
- 個人攻撃が入りにくくなる
6. まとめ
- コードレビューは技術改善のための建設的コミュニケーション
- 人格攻撃は、書いた人そのものを批判する行為で、チーム全体に悪影響
- 判断基準：
- 指摘はコードにフォーカスしているか
- 改善策や理由があるか
- 言葉遣いは柔らかいか
コードレビューを受ける側の心構え
「コードレビューを受ける側の心構え」です。前提としてレビューはスキル向上のチャンスですが、受け方次第で学びにもストレスにもなります。ポイントを整理します。受ける側は説明が大事であり、レビュワーに食いつくと結果として混乱を生むことになります。当たり前ですが自身の認識や経験からこれは確実に言えます。
1. レビューは個人攻撃ではないと理解する
- 指摘はコードや実装に対するもので、人格や能力を否定するものではない
- 心理的に反応する前に、「改善ポイント」として受け止める
2. オープンマインドで受け入れる
- 修正や改善の提案は、自分のスキルアップのチャンス
- 「なぜこの指摘が出たか」を考える姿勢が重要
- 感情的にならず、学ぶための情報として捉える
3. 質問・確認を恐れない
- 理解できない指摘があれば、遠慮せず質問する
- 例：「この変更をこうした理由を教えていただけますか？」
- 目的は「理解を深め、改善につなげること」
4. 修正の優先順位を整理する
- すべての指摘を一度に直そうとせず、重要度・緊急度を判断
- チームの方針やコード規約に従う
5. 改善策を学びに変える
- 指摘された内容を自分の今後のコーディングに活かす
- 同じミスを繰り返さないためにメモやチェックリストを作る
- レビューコメントは学習資料として活用
6. 感謝の意を伝える
- レビューしてくれた人に「指摘ありがとう」と伝える
- 単純ですが、チームの信頼関係を維持しやすくなる
7. 心理的安全性の意識
- 不快な言い方や人格攻撃が混ざる場合もある
- 受け止め方を工夫する：
- 「これはコードの改善のための意見」と切り分ける
- 必要ならチームリーダーやメンターに相談
コードレビューを行う側の注意点
「コードレビューを行う側の注意点」を整理します。レビューは単なるチェックではなく、チームの生産性や心理的安全性にも直結する重要なコミュニケーションです。
1. 指摘はコードにフォーカスする
- 人ではなくコードや設計、実装方法に対して意見を出す
- NG例：「あなたはこういう書き方が下手だ」
- OK例：「この関数は長すぎるので分割すると可読性が上がります」
2. 改善策や理由をセットで伝える
- 指摘だけではなく具体的な改善方法と理由を添える
- 例：「変数名を具体的にすると他の人も理解しやすくなります」
- 理由があると、受ける側が納得しやすく学びにつながる
3. 言葉遣い・トーンに注意する
- 命令口調や攻撃的な言葉は避ける
- 「〜してください」ではなく、「〜するとより良くなります」と柔らかく表現
- 感情的な表現はチームの心理的安全性を損なう
4. 個人の成長を意識する
- レビューは教育・改善の機会であり、人格攻撃ではない
- 同じミスを指摘する場合も、相手を責めるのではなく、改善ポイントに焦点を当てる
5. ポジティブなフィードバックも忘れない
- 指摘だけでなく、良い点も伝える
- 例：「この実装は可読性が高く、テストもしやすいです」
- ポジティブなフィードバックは、モチベーション維持に効果的
6. 過剰な細かさは避ける
- 些細な書き方の違いや個人の好みを過剰に指摘すると、受ける側が萎縮する
- 「チーム全体で統一が必要な部分」と「個人の裁量で良い部分」を見極める
7. 時間と量を配慮する
- 一度に大量のコメントを出すと、受ける側が消化しきれない
- レビューは小分けに、優先度順に伝えると効果的
8. チームのルール・規約に沿う
- コード規約やレビュー方針を事前に共有しておく
- 個人の感覚ではなく、チーム基準に基づいた指摘にする
より良いコードレビュー文化の構築
「より良いコードレビュー文化」を構築するには、単なるチェック作業ではなく、チーム全体の学習・成長・心理的安全性を意識した仕組み作りが重要です。以下に具体的なポイントを整理します。
1. 文化の基本理念を共有する
- レビューは攻撃ではなく学びの場であることをチーム全員で共通認識にする
- 「指摘はコードに対して行い、人格は攻撃しない」
- 「建設的な改善提案がチーム全体の生産性を上げる」という意識を浸透させる
2. コードレビューのルール・ガイドラインを整備
- レビューの目的・基準・優先度を明確化
- 例：バグ・セキュリティ・可読性・パフォーマンスの優先度
- コメントの形式や言葉遣いを標準化
- 例：「〜した方が読みやすくなります」「〜すると安全性が向上します」など、柔らかく建設的な表現
- コード規約やチーム方針を文書化して、新人でもすぐ理解できる状態にする
3. レビューのプロセスを改善する
- 小分けレビューで消化しやすくする
- 大量の指摘を一度に出すのは避ける
- ペアレビューや二重チェックで公平性・正確性を担保
- 自動化ツールを活用して、スタイル・Lint・テストのチェックは自動化
4. ポジティブフィードバックを取り入れる
- 良いコードや改善の成果も必ずコメント
- モチベーション維持と心理的安全性の確保に効果的
- 例：「この関数のテスト網羅率が高くて助かります」「コメントの書き方が分かりやすいです」
5. 継続的な学習機会にする
- 指摘内容をナレッジとして蓄積
- FAQやTips集、社内Wikiにまとめる
- 定期的にレビューの振り返りを行い、プロセス改善
- 例：どの指摘が多かったか、どの表現がわかりやすかったか
6. 心理的安全性の確保
- 人格攻撃は絶対にNG
- 意見を自由に出せる環境を整える
- 失敗を恐れず挑戦できる雰囲気を作ることで、チーム全体の成長スピードが向上
7. 評価や報酬とリンクさせる（任意）
- コードレビューでの貢献度や建設的なコメントを評価対象にする
- 良質なレビューをする文化をインセンティブで促す
仕事を探しているなら
仕事を探しているなら以下の記事がおすすめです。フリーランスエンジニアのエージェントを一式紹介しているので登録をしてみましょう。
コメント