はじめに
プログラミングを行うとき、ソースコードレビューは非常に重要な役割を担います。
１０年前、２０年前と比べても重要性はあがっていて、仕事やチームで開発する場合は現在では「やって当たり前」くらいの扱いになっているように感じています。
開発の基礎となるべきコードレビューですが、オンボーディングでの説明やチームでの認識合わせのために話している内容をまとめておきたいと思い、記述することにしました。
ソースコードレビューするときの心得について、私の考えや意識していることを記載しようと思います。
本題
ソースコードレビューとは
ソフトウェアを開発する際、ソースコードの管理はバージョン管理システムをつかっておこなうと思います。
ソフトウェアのオリジナルとなる管理バージョンから、開発者の担当分の開発によるソースコード差分を第三者が確認することをコードレビューと呼びます。
ここではGitを前提に具体的な話を勧めます。
Gitで開発する際、大本となるmain branchがあり、そこから派生したsub branchを作成し、sub branch上で担当者が開発を進めることがあると思います。
sub branch上での作業が完了した際に、main branchに開発差分を合流（merge）させる必要があります。
mergeする前にチームメンバーや共同開発者の確認を専用のシステムで行ってもらいます。
GitHubなどのGitのホスティングサービスではデフォルトで使えるようになっていると思います。
コードレビューをおこなう意味合い
コードレビューをおこなうことで以下のメリットがあります。
レビューアーの注意点
レビューをする側をレビューアーと言います。
この時の私の考える注意点について以下に記載します。
仕様を満たすか確認する
重要度：最高
開発によって実現したい要求である仕様を満たせているかを確認することが一番大事だと考えています。
今のソフトウェアでは実現できなかったことを実現できるようにするために開発を行っていると思うので、まず開発によって要求を満たせているかが一番重要だと考えます。
機能として十分か、機能要件・性能要件など様々な指標をクリア可能か、実装者の仕様の解釈は問題ないかなど確認が必要だと思います。
動作上問題ないか確認する
重要度：高
プログラムにバグなどがないかという視点でレビューしています。
たとえばパターンの考慮漏れや、プログラム言語やミドルウェアなど固有の個性による問題を引き起こさないかなどの視点で確認が必要です。
確認やテストは十分か
重要度：高
実装者やユニットテストなどの確認は十分か、レビューアーとして確認します。
動作上問題ないか。と似ているかもしれませんが、テストの視点についてはここでは分けました。
実装者自体がただしく動作確認しているか、ユニットテストで必要なパターンが実装されているかの視点でレビューの段階でおこないたいです。
ユニットテストの実装自体がされているかももちろんですが、テストする観点やパターンも十分か確認します。
保守性が保たれているか確認する
重要度：高
保守性についてもレビューの対象になると考えています。
実装方法は問題ないか、今後変更する場合に変更しやすいコード、読みやすいコードになっているかなどの視点で確認します。
数か月後に自分がメンテナンスできるコードになっているかなど考えてレビューしています。
コード規約にそっているか確認する
重要度：低
チーム内でコード規約があった場合、ルール通りの実装になっているかを確認します。
例えば、プログラム言語上は実装可能だが、あまり好ましくない実装方法になっていないか。など。
ただし、この部分を「重要度：低」として捉えているのは、人間によるレビューとするにはコストがもったいないように感じているからです。
後述もしますが、こういう機械的にできる部分はなるべく自動化など機械に任せて、人間にはより価値の高い仕事ができる環境にしたいと考えます。
指摘の仕方には気を付ける
重要度：最高
あえて意識する必要もない人も多いと思いますが、必要事項として。
指摘の仕方は重要だと思います。
- わかりやすく説明しているか
- 変更する場合の注意点やイメージを伝えているか
- 指摘の内容は十分か
実装者側は「問題ない」と判断してレビューに出していると思うので、的確に指摘できているかは意識したいです。
指摘は必要ですが、中傷にならないようにする意識は重要です。
また、「本当に変更は必要か」というのは常に自問自答しています。変更してもらうということは、相手の工数を発生させていることは意識して、経済的な部分でもコストが見合うかは検討しています。
レビューイーの注意点
レビューをする側をレビューアーと言います。
この時の私の考える注意点について以下に記載します。
※テクニック的な部分よりメンタル的な部分ばかりになってしまった。
セルフレビューする
第三者にレビューしてもらうまえに、自分できる確認はやっておきたいと思います。
レビューアーの注意点で書いた内容を自分でおこなうことや、
実装が終わってから数時間から１日たってから確認するようにしたいと思います。
時間をおけば自分でも多少客観的に自分の仕事を見つめなおせるので、自分でも問題点に気づきやすくなります。
指摘は受け入れる前提で考える
レビューアーからの指摘は、基本的に修正するように考えています。
レビューイーは背景や実装意図を十分理解していますし、また実装したときのテンションの上昇と疲労からコード細部について見落としがあるかもしれません。
第三者であるレビューアーが違和感を感じていたら、当事者よりも客観視しているはずですし、その視点は実装したときの記憶のなくなった将来の自分かもしれず、将来修正が必要になった時に背景や意図を忘れているかもしれません。
「コレどっちでもよくないか？」と思うことでも、第三者視点を優先して修正するようにしています。
それでも納得できそうにない場合や修正するメリットを見いだせない場合はレビューアーに指摘の意図を確認し、話あうことも解決策の一つだと考えています。
感情的にならないように注意する
あえて意識する必要もない人も多いと思いますが、意識として持っておきたいので記載したいと思います。
自分としては完璧なものを用意したつもりだと思うので、指摘された内容によっては、もしくは指摘されたこと自体に良い印象を覚えないこともあるかもしれません。
それでも貴重な機会であること、良い品質の仕事をするために必要なことだと捉えて冷静に対応するように心がけたいです。
レビューの仕組みづくり
レビューの仕組みづくりは非常に重要だと思います。
事前に環境の充実や、認識合わせをしておくことで、負担減やレビューの目的の認識合わせをしてレビュー自体の精度を上げていきたいと思います。
レビュー規約
必要であれば、チームでレビューするときのルール作りもしておきたいです。
また、レビュー規約は「作って終わり」ではなくて、アップデートが前提にあることを考えておきたいです。
自動化の充実化
スクリプトやCI機能などを使って、自動化できる部分は自動化したいです。
単純な工数削減や、レビュー時の負担を減らすことでレビューアーの集中力を維持することでレビューのクオリティ向上に貢献したいです。
ターゲットとなるのは、Linter設定などを使って文法やコーディング規約に沿っているかなどは自動で解決できることが理想です。
AIによるレビュー
2025年現在だとAIレビューなども可能な環境もあると思いますが、積極的に活用していきたいです。
最後に
レビューをすることもされることも工数的にもメンタル的にも非常に大変です。ですが、非常に重要だと思います。
重要な業務やアクションの一環だと思い、感謝の気持ちを忘れずにやっていきたいと思います。
