プロジェクトチームでシステムを開発していると、ジュニアエンジニアの頃は、このコーディングで大丈夫かなと不安に思うことがあるかもしれません。また逆にシニアエンジニアとして、ジュニアエンジニアのコードレビューを引き受けて、ちょっと気まずい思いをすることもあるかもしれません。この様な問題は、良いコードレビューをすることで解消できます。そこで、今回の記事では「コードレビューで成長する～良いコードレビューの作り方～」をテーマにして、簡潔に考察していきたいと思います。最後までお付き合いいただけましたら幸いでございます。
１.コードレビューとは
コードレビューとは、自作したコードを他のチームメンバーに見てもらい、アドバイスやコメントを求める業務のことです。コードレビューを行うことにより、バクが見つかる、知識が共有されて属人化を避けることができる、チーム全体のコーディングの品質を高めることができるなどのメリットが挙げられます。
コードレビューのやり方は、関係者をリアルに全員集めたり、またはZOOMなどを利用してオンライン上で実施するミーティング形式が主流です。
しかしながら、最近ではオンラインベースのコードレビューツール（バグ検出やコード品質向上を目的とするソフトウェア）を使用してオンラインだけで完結させる例も出てきています。ただし、コードレビューツールを用いた場合は、コミュニケーション不足が心配されます。コードレビューとは、プロダクトの品質を保ち、チーム全体で成長するための共同作業なので、コミュニケーション不足のまま行えば、チーム内の雰囲気が悪くなり、人間関係がギスギスする可能性を秘めていますので、注意が必要です。
参考出典：
2.コードレビューのメリットとは
〇人的ミスを防げます。
コードレビューを行われるということは、レビューイのコードをすべて見ることになります。この作業により、ヒューマンエラー（タイプミスなど）を発見することができます。これにより致命的なエラーも防ぐことができます。
〇コストを削減できます。
他のチームメンバーのコードをすべて点検することで、レビューイのコーディングの改善点が見つかります。それを指摘することで、理想的なコーディングに近づけることができます。そうすると、理想的な工程で作業を進めていくことが可能になり、コスト削減を実現できます。
〇ソースコードを最適化できます。
他の人が書いたソースコード（コンピュータへ命令を伝えるための文章）を、コードレビューすることで、最適なものへとチェンジすることができます。これにより開発しているシステムの最適化も実現することができます。
〇コードに一貫性ができて、コードの可読性が向上します。
チームメンバーを全員集めて行うコードレビューでは、他の人のコーディングの弱点を発見することができます。この弱点に基づきコードを訂正することで、コードに一貫性と可読性が出てきます。
〇学習機会が設けられます。
レビュアーからコードレビューを受けることにより、レビューイは自分のコードに足りない要素が見つけられるので、それをカバーするために学習機会を設けることになります。この学習チャンスを生かして、ジュニアエンジニアは成長していくことになります。
〇属人化を防止します。
このシステムは、コードを書いたAさんにしか理解できないという状態をシステムの属人化と言います。この属人化が起きると、システムに不具合が起きた場合にAさんにしか直せないという弊害が出てきます。ですので、チームで開発していくために属人化しないように、コードレビューを活用して訂正する必要があります。
〇開発チームメンバーのスキルアップにつながります。
システム開発において、他の人が実装したコードをすべて見ることにより、自分には無い発想を学ぶことができ、開発チームメンバー全員のスキルがアップします。
〇知識の共有・認識合わせができます。
システム開発者が書いたコードを全部見るため、知識の共有や、認識を合わせることができるようになります。すると、チームで開発しているシステムに一貫性ができます。
〇コード品質が向上します。
レビューイは、同じチームメンバーが書いたコードを見ることができる、またレビュアーからコードレビューを受けますので、自分のコードにはどういう要素が足りないかに気づくことができます。これにより、コードの品質が向上します。
〇チームの協調性が生まれて、コミュニケーション能力の向上が見込めます。
ミーティング形式で、開発チームメンバーが相互にコードレビューすることで、チーム内で協調性が出てきます。これにより、チームメンバー内でのコミュニケーションのレベルも向上します。
〇バグの検出ができます。
評価・点検するために、システム開発の作成者が書いたコードをすべて見るため、バグを発見することができます。
参考出典：
Qbook Qiita ONES.com エンジニアtype TECH MANIA
3.レビューイ（コードレビューを受ける人）側の解決すべき問題
良いコードレビューにするためには、レビューイ側、レビュアー側がそれぞれ解決しなくてはいけない問題があります。この段落、および次の段落で簡潔に見ていきましょう。
〇「何度も指摘される＝成長できていない」と思い込んでしまいます。
そもそも人間は、何かをする際、自分のやり方で物事を解決しがちです。ですので、コードレビューでも毎回指摘を受けることは多々あるでしょう。そこで言えることは、成長するためには、レビュアーからの指摘を真摯に受け取り、次のコーディングに活かせばよいだけです。
〇自分の書いたコード＝自分の評価 とマイナスに捉えてしまいます。
レビューイは自分の書いたコードにマイナス評価を受けているだけなのに、職業人としての評価が悪いものだと誤解しがちです。コーディングは経験を積んだり、コードレビューを受けることで最適なものになっていきます。ですので、コードレビューを受けることを怖がらないようにしましょう。
〇ダメ出しを受けて落ち込んでしまいます。
レビューイは、コーディングにダメ出しをされているだけなのに、自分という人間そのものにダメ出しをされたと勘違いをしてしまうケースも少なくありません。誤解を受けないためにレビュアーの話し方にも注意が必要です。
〇レビュアーの言い方が厳しく感じます。
コードレビューの際には、レビュアーはレビューイに成長してほしいからこそ、言いづらいにもかかわらず、苦言を言ってくれています。言い方が厳しく感じるのは気のせいです。ご指摘をありがたく頂戴しましょう。
〇「人格攻撃されている」と思い込んでしまいます。
サンプルサイトから引用すると、人格攻撃とは、相手の人格や価値を否定する行為のことです。コードレビューを受けることは、コーディングを最適化するための行動であり、レビューイの人格や価値を否定するための行為ではありません。ですので、コードレビューを受けるレビューイは、自分自身の性格や仕事の仕方を批判されるわけではないので、コーディングについて反省するだけで良いのです。
4.レビュアー（コードレビューを行う人）側の解決すべき問題
〇どう直せばいいのか示さないので、コーディングの訂正が適切にできません。
ただ、コーディングを直してくださいというだけで理由を説明しないのはNG行為です。それは、直し方の指針を提出されないと、コーディングの訂正が適正にできないからです。理由を聞かされず、マイナス評価を与えられるのは、人格攻撃だと勘違いをされることもあるので、注意が必要です。
〇コードレビューはレビューイに誤解を与えないように、行わなければなりません。
他の人のコーディングに「モノ申す」業務であるコードレビューを行うには、相手に敬意をもって行わなければなりません。そのため、コードレビューを行う際には、メールでは文体、口頭では口調を威圧的になってはいないかを、よく考えながら行う必要があります。
〇直してほしい箇所を口頭だけで伝えてはいけません。
ミーティングの際に、コーディングを直すべき箇所を口頭で伝えるだけでは不十分です。レビューイもメモを取りますが、メモだけでは後に振り返るときには不十分になりがちです。ですので、必ずメールなどの文章で伝えるべきです。また、メールなどで指摘した場合には、ログが残るので、「言った、言われていない」などのトラブルも避けることができます。
〇なぜ直すべきか、理由を説明しましょう。
コーディングに評価をつけて訂正を求める際には、「○○だから訂正しましょう」と、きちんと理由を必ず説明しなくてはなりません。ただ、駄目なコーディングをしていると言われても、レビューイは納得できません。理由を適切に説明できる様にしましょう。
〇人格攻撃をしてはいけません。
レビュアーがコードレビューをするときに絶対にやってはいけないのは、人格攻撃（相手の人格や価値を否定する行為）をすることです。コードレビューとは、コーディングについての評価をするもので、コーディングをしたレビューイの人格を評価するものではありません。
5. 良いコードレビューをする際の着眼点
〇自動化できるコーディングは自動化しましょう。
複数回繰り返される基本的なコードは、今の時代AIが代替してコーディングすることが可能です。ですので、タイパやコスパを重視して、AIによる自動化を実践していくべきです。
〇チーム内でコードレビューの目的・観点を共有しましょう。
コードレビューを行うミーティングにおいて、コードレビューの目的や観点を共有化することが重要です。理由は、システム開発はチームで行うものであるからです。この作業をきちんと行うことで、システムに一貫性が出てきます。
〇チームのコーディングルールに準拠していますか。
チーム内であらかじめ決められたコーディングルールを守ることで、システムに一貫性を保つことができます。ですので、チーム内であらかじめ決められたコーディングのルールを守ってコーディングを行っているかが重要です。
〇開発しているシステムは、仕様書に合致していますか。
仕様書とは、システム開発において、成果物が実装すべき内容を具体的に明文化した開発者向けの文書のことです。チームで開発しているシステムは、この仕様書の内容を満さなければなりません。
〇コメントは適切に管理されていますか。
システム開発におけるコメントは、コードレビューの効率化、他者に対してコードの意図を説明する、チームメンバー内での知識の共有、他者に対して複雑なロジックを分かりやすくする、チームメンバーとのコミュニケーションを助けるなどの役割を果たすものです。これらの目的を果たすためにコメントは適切に管理されなければなりません。
〇デバッグ用のコードが紛れていませんか。
デバッグ（debug）とは、コンピュータプログラム内のバグや欠陥を発見して取り除き、動作を仕様通りのものに修正する作業のことです。このデバッグのために用意していたコードを通常開発のコードと間違えて混ぜてはいないかどうか、注意が必要です。
〇ドキュメンテーションの記述は適切でしょうか。
ドキュメントとは、プロジェクトの目的、計画、進捗状況などを明確にし、それを実現するために技術的な情報を明確化することです。ドキュメント作成はチームメンバー全員が一貫性をもってシステム開発するために必要不可欠なスキルです。ドキュメントの効果的な作成方法としては、チームメンバー内で交換されてきた情報を容易に再利用するために、それを整理して文書化することです。
〇デザインの一貫性は保たれていますか。
チームでコーディングをする際に、デザインの一貫性（複数のサーバー間でデータが矛盾なく同じ状態になっていること）が保たれていることを確認する必要があります。このデザインの一貫性がないと、非常に扱いづらいシステムになってしまいます。すると、最終的に作り上げたシステムをユーザーが使用する際に、不便さを感じるようになります。
〇ロジックは正しく、シンプルな状態でしょうか。
ITにおけるロジックとは、プログラムやシステムおいて、目的を達成するための処理の内容、手順、方法のことを言います。このロジックとは、論理的思考に基づき、運用されます。そして、他のチームメンバーが理解しやすいようにシンプルなものにする必要があります。
〇レビューイに不足している知識がどのレイヤーかを考えましょう。
レイヤーとは、システムなどを複数の階層（layer）に分けて、そのそれぞれに役割を持たせたり、固有の機能を持たせる設計手法のことです。レイヤーを分けることで、保守や開発を簡単に行うことができます。コードレビューを行う際に、レビュアーはレビューイの書いたコードが知識不足から起こっている可能性も考える必要があります。ですので、レビューイに不足している知識がどのレイヤーにあるかを発見することが重要です。
〇セキュリティ上の脆弱性は無いですか。
セキュリティ上の脆弱性（Vulnerability）とは、コンピュータのOSやソフトウェア、ハードウェアにおいて、システムの設計上のミスやプログラムの不具合が原因で生じる情報セキュリティ上の欠陥のことです。セキュリティ上の脆弱性を放置して、コンピュータを使用し続けると、ウィルスに感染したり、不正アクセスされたりします。ですので、システム開発において、セキュリティ上の脆弱性が無いかを気を付けることが必要不可欠になります。
〇コードの可読性はありますか。
コードの可読性が高いシステムとは、コーディングされたプログラムが「動くこと」はもちろんですが、「他のエンジニアが理解でき、将来的に修正しやすい」というシステムのことです。この可読性が高いと、拡張、修正が簡単にできるので、システム全体の生産性や品質向上につながります。
〇アーキテクチャ設計は適切になされていますか。
アーキテクチャ設計とは、システムを構築するための設計の枠組みのことです。その目的は、システムを構築・保守するために必要最低限の人材をそろえることです。優れたアーキテクチャとは、工程数を重ねても労力が増えていかない設計のことを指します。
〇命名は一貫性をもって行いましょう。
システムに一貫性を持った名前を付けることにおいて重要なのは、同じ意味や用途に関して、同じパターンには同じ系統の名前を付けることです。さらには、システムの命名には、適切な長さ、システムの意図の説明などを意識する必要があります。
参考出典：CREX Qiita Qiita TECH MANIA Zenn テスター10byみんなシステムズ CREX 国民のためのサイバーセキュリティサイト FRESHET Web制作・Web開発の歩き方 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 Aiquon Zenn LEXIWORD Qiita cmkPLUS ITで未来を照らす
ONES.com note SAISEI.COM Wikipedia MADOショップ羽生下岩瀬店
まとめ
今回の記事では、「コードレビューで成長する～良いコードレビューの作り方～」について簡潔に見てきました。コードレビューではプロダクトの品質を保つために、他の方の仕事に改善点を指摘する業務のため、相手に対するリスペクトが最も重要だと言えるでしょう。今回も最後までお付き合いありがとうございました。