コードレビューというと、「バグがないか」「ロジックが正しいか」といった観点に意識が向きがちです。もちろんこれらは重要ですが、25年以上、複数人・複数チームでの開発を経験してきた中で、それ以上に重視するようになった観点があります。それが、「コーディング規約に則っているか」「誰が書いても同じように見えるか」という、統一感の観点です。

この記事では、なぜこの観点を重視しているのか、そして実際のレビューでどう見ているかをお伝えします。

なぜ、正しく動くことよりも「統一感」を重視するのか

コードが正しく動くことは、当然ながら大前提です。しかし、動くかどうかだけを見てレビューを終えてしまうと、長期的に見て大きな問題が積み重なっていきます。

その問題とは、「書いた人によって、コードの見た目や書き方がバラバラになる」ことです。ある人はif文を多用し、別の人は早期リターンを多用する。ある人は変数名を英語で書き、別の人は日本語のローマ字表記を使う。一つひとつは小さな違いでも、これが積み重なると、システム全体が「継ぎ接ぎだらけのコード」になってしまいます。

この状態になると、次のような問題が発生します。

  • 別の担当者がコードを読むたびに、書き方の違いに戸惑い、理解に余計な時間がかかる
  • 同じような処理なのに、書き方が違うために、共通化できる部分が見過ごされる
  • 保守を担当する人が変わるたびに、「このシステムはクセが強い」という印象を持たれ、改修に慎重にならざるを得なくなる

コードは、書いた本人だけが読むものではありません。数ヶ月後、あるいは何年も経ってから、まったく別の人が読んで手を加えることが前提の資産です。だからこそ、「誰が書いても同じように見える」状態を保つことが、動くこと以上に重要だと考えています。

レビューで、具体的に見ているポイント

1. コーディング規約に沿っているか

命名規則、インデントの付け方、コメントの書き方など、チームで定めたコーディング規約に沿っているかを確認します。規約から外れている箇所は、動作に問題がなくても指摘し、統一された書き方に揃えてもらいます。

2. 同じ処理は、同じパターンで書かれているか

似たような処理を、人によって異なる書き方で実装していないかを確認します。たとえば、エラーハンドリングの書き方、データベースへの問い合わせ方法、条件分岐の組み立て方など、プロジェクト内で「このパターンで書く」という暗黙のルールがある場合、それが守られているかを見ます。

3. 個人の癖が、必要以上に出ていないか

プログラミング言語には、同じ結果を得るための書き方が複数存在することがよくあります。個人の好みで独自の書き方を選ぶこと自体は否定しませんが、チーム開発においては、読み手にとっての分かりやすさを優先し、プロジェクト内で一般的とされる書き方に寄せてもらうようにしています。

4. コメントの粒度が、他の部分と揃っているか

コメントを詳しく書く人もいれば、ほとんど書かない人もいます。コメントの量や粒度がファイルによってバラバラだと、読み手は「このコメントの少なさは、書き手の癖なのか、それとも特に注意すべき複雑な処理だからなのか」を判断できません。プロジェクト全体で、どの程度の粒度でコメントを書くかの目線を揃えることを意識しています。

統一感を保つことで得られる、具体的なメリット

1. 後から見る人が、コードを読みやすくなる

書き方に統一感があると、読み手は「この部分の書き方」に気を取られることなく、処理の中身そのものに集中できます。誰が書いたかによらず、同じ感覚でコードを読み進められる状態は、レビューだけでなく、その後の保守フェーズ全体の効率に直結します。

2. 改修の工数が、確実に減る

統一感のないコードは、改修のたびに「この部分はどういう意図で、こう書かれているのか」を都度調査する必要が生じます。統一されたパターンで書かれていれば、似たような改修を過去に経験していれば、初見の部分でも見当をつけやすくなり、調査にかかる時間が大きく減ります。

3. 属人化を防げる

書き方に強い個性が出ているコードは、その人にしか触れないコードになりがちです。統一感を保つことは、特定の人にしか分からないコードを減らし、チーム全体でメンテナンスできる状態を保つことにもつながります。

レビューで意識している、伝え方の工夫

統一感を理由にした指摘は、時に「好みの押し付け」と受け取られてしまうことがあります。そう受け取られないために、指摘するときは、単に「このルールに合わせてください」と伝えるのではなく、「なぜこのルールがあるのか」「揃えることで、後々どんなメリットがあるのか」まで添えて伝えるようにしています。

理由が伝わらないまま指摘だけを繰り返すと、書き手は「言われたからやる」という受け身の姿勢になりがちです。背景を理解してもらうことで、次からは指摘される前に、自然と統一された書き方を意識してもらえるようになります。

まとめ

コードレビューでは、動くかどうかだけでなく、次の観点を重視しています。

  • コーディング規約に沿っているか
  • 同じ処理が、同じパターンで書かれているか
  • 個人の癖が、必要以上に出ていないか
  • コメントの粒度が、プロジェクト全体で揃っているか

これらを重視する理由は、「誰が書いても同じように見えるコード」が、後からコードを見る人にとっての読みやすさを高め、結果として改修の工数を減らすからです。コードレビューは、バグを見つける場であると同時に、チーム全体の資産としてのコードの質を保つための、大切な仕組みだと考えています。