はじめに
業務中、ふと「雰囲気でコードレビューしてしまっている」ということを自覚しました。
そこで、コードレビューにおいて気をつけていること、こうすればさらに良くなりそう！を言語化してみました。
「雰囲気レビューを卒業したい」、「コードレビューの質を向上・体系化したい」といった方はぜひ読んでみてください。
✊ レビュアーの役割
レビュアーが果たすべき重要な役割として、システムの品質を保証することが挙げられます。
- 要件不十分
- 不具合
- コード品質低下
などの発生責任は、レビュアーにも共有されます。
それらの発生を防ぐために、レビュアーが心がけるべきことをについて書いていきます。
👀 コードレビューの視点
コードレビューのときに特に見るべき観点は、大きく分けると以下の３つです。
- 仕様を満たしているか
- バグが含まれていないか
- コードの品質が低くないか
1と2は言わずもがな重要です。死ぬ気で見ましょう。
３はリリーススピードを優先するためにおざなりになりがちですが、品質の低下は将来的なバグ発生や開発・レビューコストの増加につながります。
忙しいからと言い訳せず、できるかぎり見るようにしましょう。
また、疑問・不安はしまいこまず、できるだけ解消するようにしましょう。
仮に意見が不適当だったとしても、あなたにとって学習の機会になり、同様の疑問を抱えている他のレビュアーの助けになります。
🗣 コードレビューの伝え方
指摘内容が妥当でも、伝え方が不適切だと反映されないという結果になりかねません。
良い意見を無駄にしないために、伝え方にも配慮しましょう。
指摘のしかた
指摘について書くべきは以下です。
- 改善してほしいこと
- 理由（根拠）
- 解決方法
1. 改善してほしいこと
何が課題なのか、該当行へのリンクやコードブロックなどを用いてわかりやすく説明しましょう。
このときに、頭ごなしに拒否せず肯定から入るようにすることで、より受け入れられやすくなります。
2. 理由（根拠）
論理的な正しさを証明するためには根拠を添えることが効果的です。
- 仕様書
- 公式ドキュメントやリファレンス
- スタイルガイド
- 他参考サイト
参照元は１次情報に近ければ近いほど信憑性が高い為、その点も意識しましょう。
3. 解決方法
課題提起にとどまるのではなく、解決のサポートまでできればベストです。
思いつかない場合でも議論を喚起するなどして、必要な協力を惜しまないようにしましょう。
ただし成長を促したい場合は、あえて解決方法まで教えないことも選択肢です。
心理的安全への配慮
なぜ心理的安全に配慮するべきか
それは、「正しく意見交換をする為」です。
レビューで少しでも辛い気持ちになったことはありませんか？（私はあります）
心理的安全性の欠如は、以下のようなことを引き起こします。
- 不健全な対立によるコミュニケーションの消極化
- モチベーションおよび生産性の低下
コードレビューのコメントでは基本的に意見の違いを伝えることになります。
間違いを受容することは、決して簡単ではありません。
その上理不尽だと感じる要求は、さらに受け入れがたいものになります。
どうすればいよいか
「指摘のしかた」を遵守する
上で述べている「指摘のしかた」を心がけましょう。
レビューイがコードの指摘を人格否定だと勘違いしてしまうことが、心理的安全を損なう要因の一つです。
論理的であることは大前提です。
その上で解決方法を提案し、寄り添うスタンスを示しましょう。
褒める
コードレビューでは指摘が連なりやすく、レビューイの心は荒みがちです。
そうなりやすいことを強く念頭に置き、良い点にも積極的にリアクションするようにしましょう。
👍 のような絵文字１つでも、かなり雰囲気が和みます。
感情を表現するツールを使う
テキストコミュニケーションは感情が伝わりにくく冷淡に受け取られやすいため、無自覚に相手にネガティブな印象を与えてしまっていることがあります😿
感情の受け取られ方に気を払うことで、それを未然に防ぐことができます💪
感嘆符（！）、絵文字、顔文字は感情を表現する強力なツールなので、ぜひ活用しましょう！！
ただ、このようなコミュニケーションが合わないという方もいらっしゃると思います🙋
そういう方はコメントをする前に一度読み返し、相手に不安を与えるような表現がないか確認することを習慣づけましょう！
まとめ
コードレビューは開発者がメイン、レビュアーはサポート的立場だと考えがちですが、実際は責任を共有する立場です。
レビュアー側も当事者意識を持つことで、建設的なレビューを実現していきましょう😺
また、レビューを依頼する側の考えを理解しておくと、より歩み寄りがしやすいです。
>> コードレビューを依頼する側の心構えはこちら