コードレビューはプロセス（監査）ではなく、コミュニケーション（対話）である

プロダクトチームのエンジニアリングマネージャーをしている @_kehondaです。この記事は、ポート株式会社 サービス開発部 Advent Calendar 2025の内容になります。

---

概要

コードレビューが社内で採用されてもう10年以上経つ。
コードレビューがなかなかされなくて困っているとか、コードレビューが大変だという話をきっかけに、レビュイーやレビュワーの責任について考えることがあったので、社内で話していることや、私の考えるコードレビューを言語化してみる。

前提

取り扱っているプロダクトやチーム体制

• 自社での開発プロダクト
• アジャイルな開発プロセスで開発
• エンジニアの相互レビューを行っている
• QAチームは存在せず、チーム内や依頼者で品質の担保を実施

私が考えるコードレビューとは

コードレビューは｢品質高く・早く価値を届けること｣だと定義している。

コードレビューは関所ではない

一般的にはコードレビューというプロセスが、「管理プロセス」の一部として取り扱われているのではと思う。これはガバナンスを強化するためや、監査のための取り組みとして機能していることを意味している。

しかし、私たちは開発者であり、監査官ではないと考えている。

開発者同士のレビューにおいて最も重要なのは、「承認」ではなく「対話」であり、そして何より「スピード」だと考える。
もしプルリクエスト上のコメントが何往復も続いているなら、その時点で見直すべきで、（リモートであれば）すぐに通話をするか、次回から設計について事前に相談するようにしたり、そもそもレビューという工程を挟まずにペアプログラミングで解決すべきかなどを検討する必要がある。
「レビューを通すこと」を目的にしないで、チームとして最速で最高の結果を出すために、今のレビュー運用がボトルネックになっていないかを確認してほしいと考える。

作成者（レビュイー）としての責任

コードレビューにおいて、作成者は常に「説明責任」を負っていると考えている。 自分が生み出した制作物は、自分が一番知っているはずだと思っているので。
この前提に立ち、たとえ経験が浅くても、「なぜこの実装を選んだのか」を自分の言葉で語れなければならない。
そのためには、徹底したセルフレビューを行い、自分の書いたコードに、またその周辺に不明点がないかを確認する必要がある。
自分で説明できないコードが含まれていないか？AIの提案を鵜呑みにしていないか？自身のコードに「分からない」を残さないことを心がけていきたい。

そして、レビュワーに疑問を持たせないことも意識したい。
疑問は確認の手間を生み、マージを遅らせてしまう。複雑なロジックにはコメントを添え、背景を事前に共有する。
レビュワーが疑問を持つ前に答えを用意しておくこの先回りが、チームの開発スピードを最大化すると考えている。

レビュワーとしての心得

まず大前提として、レビュワーは｢デバッガー｣ではない。不具合を未然に防ぐ責任の第一義は、あくまでコードを書いた作成者にあると考えている。
間違いを見つけるために読むのではなく、設計意図を正しく理解し、チームとしてその変更を受け入れることが適切かを検討するためにコードを読み込んでいく。

そして、最大限の考慮を経て出されたコードへ敬意を持ってレビューに取り組む。「なぜこのように実装したのか」を深く理解する姿勢が大事だと考えている。
そのために私が有効だと考えているのが、「自分ならどう書くか」という仮説を持って読むこと。
自分の想定と実際のコードの差異から学びを得ることで、レビューは単なる監査から、相互学習や理解促進の場になる。

また、コメントをする際は指摘の重要度を明確にすべきだと考えている。
必ず直すべき不具合（Must）なのか、より良くするための提案や個人の好み（Want）なのか。
この区別が曖昧だと、些末な指摘でマージを遅らせ、チームの生産性を下げてしまうと考える。

ちなみに私は、単なる好みであってもコメントはすべきだと考えている。
それは対話のきっかけになり、メンバー間の価値観理解やチームのこれからの方針を作ると考えている。しかし、それがマージをブロックしたり、スピードを下げる要因にならないようにしたい。「これは提案なので、反映は任せます」と一言添える配慮が、スピードと品質を両立させる鍵だと考える。

まとめ

私が考えるコードレビューのスタンスを書いてみた。
もちろん、すべてのチームに当てはまることではないと思うし、メンバーの習熟度やスキルに応じて成立しない時、監査としてのプロセスを取り入れざるを得ないことは往々にしてあると思う（弊社もある）。

その上で、「品質」と「スピード」を両立し、ユーザーに価値を届けるために、レビュイーの責任やレビュイーの心得を再認識し、そしてそのために精進し、コードレビューという手段が目的やボトルネックにならないように務めたい。

また、最近だとAIを利用した開発やレビューも当たり前になってきている中で、レビュイー･レビュワーどちらも、AIはあくまで補助をしてくれた自分の成果物であることを認識しなければ、AIへの責任の押し付けになって、結果レビューというプロセスは負債になってしまうと思う。
AI駆動開発でも、レビュイーとしての責任を認識し、自分自身がハンドリングすることを心がけたい。

参考

https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/