こんにちは。山口です。
大阪事業所に新卒として入社し、5年目を迎えました。

今まで開発を中心に携わってきた中で、コードレビューを受けること（＝レビュイー）は日常的にありましたが、
コードレビューをする（＝レビュワー）側に立つことはほとんどありませんでした。

そんな中ですが、最近、レビュワー側に立つ機会がありました。

本記事では、その時に意識したことなどを共有できればと思います。

当時の状況

• 新規システム開発

  • PHP/Laravel/JQuery

• レビュイー（レビューされる側）：新規開発は初めて。今回は短期（数ヶ月間）での参画。

• レビュワー（レビューする側）：私。3年ほど今のプロジェクトで開発作業を行う

  • 同案件内での別システムの開発含む

• レビュー形式：書面レビュー

私の所属するプロジェクトでは、基本的に書面レビューを行っています。

①ソースを見る観点

一般的に適切なコードか

コードレビューを行う上で、最も重視される部分かと思います。

• ロジックが適切か
• 不要な処理はないか
• ソースを見てわかる範囲のバグがないか
• 仕様を満たしているか
  このあたりを重点的に確認しました。
  また、「適切なコード」かどうかは書籍「リーダブルコード」に記載されている内容を基に判断して進めました。
  

プロジェクトのコーディング方式から大きくずれていないか

各プロジェクトに、多かれ少なかれある種のコーディングルールのようなものがあると思います。
コーディングルールについては、以下を参照していただければと思います。
2024/7 少人数開発でのコーディング規約をどうするか

今回は小規模（５人程度）のプロジェクトなのでそこまで細かいものは設けていませんが、事前に内容を共有し、
大きく逸脱していないかどうかは注意して確認しました。

技術Tipsや開発を行う上でのアドバイス

この案件はフルリモートなので、なかなか同僚の開発風景を見るということが難しいです。
（本案件に限らず、クリエーション・ビューではフルリモートの案件も多いです）

少し話がそれますが、私自身、画面共有で人の操作を見ていると
「今のどうやったの！？」
とか
「その拡張機能便利そう！」
と思うことが多々ありますｗ。
そのやり方を教えてもらい、開発効率がアップした経験があるので、
他人の操作を見て学ぶことは大事だと考えています。

なので、最初のうちは書面に加えて、google meetを使って画面共有しながら説明しつつ、
開発するうえで便利な拡張機能やショートカットを共有したりしました。

また、レビュイーが短期での参画だったので、
ショートカットやエディタの使い方は次の案件でも生かしやすいと思い、意識的に知識共有したつもりです。

この部分は一般的なコードレビューではあまり実施されない部分であり、
コードレビューの範疇を超えているかもしれませんが、次の案件のことを考え意識的に取り入れました。

②心理的安全性

最近「心理的安全性」という言葉を目にする機会が増えました。
端的に言えば、チームメンバーが安心して発言したり、作業できる状態のことを表します。

私もそうでしたが、コードレビューを受けることは結構緊張したりします。
書面レビューだと多少緊張は少ないですが、その中でもレビュイーが委縮したりしないように、以下の点を意識しました。

褒める

前回から改善された点を見つけたり、綺麗な実装だと思ったりした際は、その内容を忘れず記載するよう心がけました。
コードレビューをしていると、どうしても指摘が多くなってしまい、レビュイーも精神的にしんどく感じることがあります。
なので、最低でも一つは褒めるように意識して、少しでもレビュイーの心的負担を減らすよう心がけました。

レビュイーの方からも、
「褒めてもらったことでモチベーションアップにつながった」
といった内容のフィードバックをいただいたので、心掛けとしては良かったと思います。

やわらかい言葉を使う

書面だとついつい堅い印象になってしまい「怒っているのかな？」と感じさせることがあります。
レビューに苦手意識を持たないよう、
「○○の書き方いいですね！」
や
「○○のように書いてみてくださいー。」
など、語尾に「！」を付けたり語尾を伸ばすことで、やわらかい印象を与えるよう意識しました。
私自身、上司や先輩方がこうした語尾をつかってくださり、親しみやすさを感じていたので、レビュー以外でも意識して使うようにしています。
（もちろん、TPOはわきまえてですが。。。）

「なぜ？」はできるだけ使わない

私もそうですが、「なぜ？」という言葉は、人によってはかなり「詰められている」というような強い言葉に感じることがあります。
「詰められている」と感じると委縮してしまうこともあるので、なるべく使わないようにしました。

実装で気になった箇所があった場合、
「なぜこう書いたのですか？」
ではなく
「なにか意図はありましたでしょうか？なければ○○のように書いてみてくださいー。（以下理由）」
という風に書くようにしていました。

特に、開発に慣れていないうちは、実装理由について聞かれても
「これしか思いつかなかった。」
「あまり深く考えていなかった。」
ということがありがちです。（私もそうでした。）

なので、明確な理由がある場合のみ説明してもらうように意識しました。

正直、まだ言葉として少し強い印象があるので、良い表現がないか模索中です。

③粒度

どこまで細かく伝えるかという点ですが、
気になった点はすべて伝えました。
コメントの誤字などにいたるまで、プロジェクトの進捗に余裕があったのでかなり細かいところまで指摘しました。
（「細かいですが」といったクッション言葉は添えるようにしていました。）

また、修正点については、「なぜこうするべきか」ということは必ず書くようにしました。
これを書くことで、自分が惰性でやっていた実装についてもちゃんと理由を考えたりと、
私自身の実装の見直しにもなりました。

④レビューの効果

レビューの回数を重ねるうちにソースコードがきれいになり、どんどん指摘が減っていきました。
最後の方には細かい指摘のみになったので、コーディングに関してかなり良くなったと感じました。

総評

全体を通して、初めてにしてはうまく回すことができたと感じています。

よく言われるレビューの極意に「自分のことは棚に上げろ」というものがあります。
自分ができていないからといって、指摘をためらうのではなく、
指摘したうえで自分の反省点とすることが大切だと実感しました。

コードレビューを通して、レビュイーの成長に貢献できたことと、
自身の成長や反省点も実感でき、とても有意義な経験だったと感じています。