コードレビューを成功させるには？ CTOが考えるべき7つのこと│監修：高遠和也（株式会社LIG CTO）
※本記事は2019年1月に公開された内容です。
コードレビューとは、誰かが作成したソースコードを他者がレビューすることで、問題のある記法やバグがないかを確認する作業のこと。プログラムの品質を高めるために、なくてはならない工程のひとつです。
しかし、コードレビューを成功させることは簡単ではありません。読者のなかにも、「同じような指摘を何度もしているのに、メンバーのスキルが向上しない」「つい感情的なコメントをしてしまう」といった悩みを抱えている方は多いのではないでしょうか。
やみくもにコードレビューを実施しては、成功率は上がりません。レビューアーが実施方法やマインドを適切なものに変えなければ、良いコードレビューにはならないのです。 ここでは、コードレビューを成功させるための方法を7つご紹介します。
本記事の監修：高遠和也（株式会社LIG CTO）
コードレビューを成功させるためにCTOが考えるべき7つのこと
1. レビューイーに「どのレイヤーの知識が不足しているのか」を考える
レビューイーが良くないソースコードを書いている場合、レビューアーは「なぜ、レビューイーはこのソースコードを書いたのか？」を、まず考える必要があります。
特定言語の文法やメソッドを知らないのかもしれません。例外がどのような状況のときに発生し、どうエラーハンドリングすべきなのかを理解していないのかもしれません。デザインパターンを学んだことがなく、どのような設計が適切なのかわからないのかもしれません。良くないソースコードを書く理由は十人十色なのです。
コードレビューで指摘をする際に、「レビューイーにどのレイヤーの知識が不足しているのか」を確認しましょう。例えば「○○ではなく△△のような書き方にしましょう」とコメントする代わりに、「○○ではなく△△のような書き方もできますよ。○○にした理由はありますか？」と問いかけてみましょう。
返答の内容によって、レビューイーにどのような知識があるのかを可視化できます。それをふまえてレビューを進めることで、コードレビューの効果をより高められるのです。
2. レビューの目的は何か、チーム内でコンセンサスをとる
「コードレビューが終了したときに、どういう状態になっていれば成功なのか」を意識したことはあるでしょうか。答えが「NO」ならば、コードレビューの実施方法そのものを見直した方が良さそうです。
メンバーが目的と共通認識を見失ったコードレビューは非常に危険です。例えば、新人エンジニアに対して高すぎる要求をする中堅エンジニアが現れたり、些末なことにこだわって他工程の工数が逼迫されてしまったり、ということが考えられます。こうした状況を防ぐには、レビューが「何を目的としているか」「どの程度の品質レベルを担保したいのか」などのコンセンサスをとることが重要です。
コードレビュー会など対面でレビューを行う場合は、実施前に各メンバーと口頭で確認を取りましょう。Pull Requestをベースに机上でレビューを行う場合は、実施中に特定のメンバーがレビューの舵取りをするのをおすすめします。テックリードやCTOなどの立場にある方は、こうした場で適切なファシリテーションをすることで、組織の文化をつくり上げることも重要な役割です。
それでは、どのようにファシリテーションをしていくか例を挙げます。例えば、重要な機能のリリースが差し迫っているにもかかわらず、中堅エンジニアが新人エンジニアに対して「新機能で○○のメソッドを修正するついでに、△△の処理をリファクタリングしてください」と、コメントしたとしましょう。
この状況で、最も優先すべきは「重要な機能にバグが含まれていない状態でリリースすること」であって、「ソースコードの可読性を高めること」ではありません。
中堅エンジニアに対して「△△のリファクタリングは、すごくいいですね！ ただ、修正の期間があまりないので、機能をリリースした後にリファクタリングをする方針にしましょうか」とコメントし、最優先すべき目的を守りましょう。
プログラム開発に投入できる人や時間は有限です。そのため、ソースコードレビューにおいてレビューアーは「自分の指摘にはどれくらいの実現可能性があるか」「指摘を反映した場合に、プロジェクト全体にどんなメリットがもたらされるか」を常に考えておかなければいけません。
そもそも、ソースコードレビューとは広義でいえば「投資」なのです。レビューの段階で悪いコードやバグを未然に発見しておくことで、将来的に必要になる修正・対応コストを削減することが重要な目的になります。その基本を忘れてはいけません。
3. 批判すべきはコードであり、人格ではない
コードレビューでは、人の習慣や考え方についての批判をしてはなりません。レビューイーが萎縮してしまい、モチベーションが大きく下がってしまうからです。
良くない指摘の代表例は、「以前も指摘したと思いますが、○○は△△してください」といったものです。「以前も指摘したと思いますが」というフレーズが、「人の習慣」に対する批判になっています。
おそらくレビューアーは、イライラしながらこの指摘をしたのではないでしょうか。一方でレビューイーは「以前に受けた指摘をまた受けてしまうのは、自分がなっていないからだ」と自分を責めてしまうはずです。これでは、良いコードレビューになるはずがありません。
なぜこのような事態が起こってしまうのでしょうか。それは多くの場合、「レビューイーが、なぜ良くないコードを書いたのか？」をレビューアーが理解できていないことに起因しています。根本原因を理解できていないため、「失敗するのは、レビューイーの努力や注意力が足りないからだ」という発想に陥ってしまうのです。
これを防ぐためにも、冒頭で解説したように「レビューイーに、どのレイヤーの知識が不足しているのか」を考えることが必要です。その原因を丁寧に解き明かしていけば、レビューイーがなぜ良くないソースコードを書いたのか、どうすれば改善できるのか、道筋が見えてきます。必然的に、レビューアーがレビューイーの習慣や考え方についての批判をすることも少なくなるでしょう。
とりわけ、高いコーディングスキルを持ったエンジニアがレビューアーになった場合に、こういったコメントをしやすい傾向にあります。自分自身が技術に高い関心を持って学習をしてきたからこそ、技術力の未熟な人が「なぜできないのか？」を慮（おもんぱか）るのが苦手なためです。
「自分はそういう傾向があるな」と思う方こそ、意識してこの習慣を身につけましょう。また、レビューアーがレビューイーの習慣や考え方についての指摘をしていないか、常に気を配っておくことが必要です。普段のなにげないコミュニケーションが、チームの文化をつくります。
4. コードレビュー“以前”にキャッチアップすべきことを考える
プロジェクトにおいて「コードレビューの段階で指摘をしても、すでに手遅れ」というシチュエーションが発生することがあります。顧客からの要望をそもそも勘違いしていたり、不適切な設計のまま実装を進めてしまったり、ということは、その最たる例でしょう。
こうした事態が起きてしまうと、大規模な手戻りが発生してしまいます。レビューアーもレビューイーも疲弊しますし、大急ぎで修正したソースコードは品質も悪くなってしまうでしょう。誰も幸せになりません。本来ならば、設計を考える前には各メンバーが要件を正しく理解しているべきですし、ソースコードを書く前には設計のアウトラインができあがっているべきです。
これを防ぐには、プロジェクトの初期フェーズにおいて「どの時期にどんな種類のレビューをすれば、最も段取りが良くなるか」のマイルストーンを置き、最善のタイミングで適切なレビューを行うことをおすすめします。取り返しのつかない状態に陥る前に各メンバーのチェックを通すことで、プロジェクトが失敗するリスクを未然に回避できるのです。
また、中期〜後期のフェーズにおいて大きな手戻りが発生するのは、プロジェクトを適切にマネジメントできていないことに起因する可能性が高いです。もしあなたがチームを牽引する立場にあるならば、マネジメント失敗の原因について考えてみましょう。
例えば、顧客の要望を適切にヒアリングできていないのかもしれません。メンバーとのコミュニケーションがそもそも足りていないのかもしれません。根本原因を解消することで、プロジェクトの業務全般も自然と改善されていきます。
5. 「どんな勉強をすれば、コードレビューで受けた指摘を改善しやすくなるか」もセットで教える
多くのエンジニアは真面目ですし、「もっと成長したい」という意欲を持っています。ですが、経験の浅いエンジニアの場合、「何を勉強すれば、自分のレベルを上げられるのか」を理解できていないケースが多いです。
そのため、他のメンバーから「もっと〇〇のスキルを上げよう！」と言われても途方に暮れてしまいます。下手をすると「何を勉強したらいいのかがわからないのは、自分にセンスがないからだ」となってしまい、モチベーションの低下にもつながりかねません。
筆者は「この本や記事がすごく良かったよ」と、勉強するためのヒントになるような情報を、レビュー後にSlack上で共有することが多いです。そうすることで、当人の上達の道しるべとなります。
ここで大事なのは、ダイレクトメッセージではなく、他のメンバーも参加しているチャンネルで情報を共有することです。他のメンバーの学びにもつながりますし、活発に情報交換を行うチーム文化も醸成されるからです。
6. ソースコードの良い部分には「いいね！」と言う
筆者は、外国人エンジニアが非常に多い企業で働いていたことがあります。そこでは、誰かのソースコードを読んだときに「Good!」とコメントする習慣がありました。とても良い習慣だと筆者は思います。
「Good!」と言ってもらえたメンバーは、モチベーションが非常に高まります。当然、チームの雰囲気も良くなるでしょう。さらに、コメントを見た他のメンバーも「なるほど。これが良い書き方なんだ」と学ぶことができ、メリットだらけなのです。コードレビューで良いコードや良い指摘を目にしたら、積極的に「いいね」とコメントしましょう。絵文字を使うのもおすすめです。
日本人は他の国の人々と比べて、ポジティブなフィードバックをするのが苦手な傾向にあるといわれています。弱み潰しをしてしまいやすいのです。フィードバックとは悪い部分を改善するためだけではなく、良い部分を伸ばすためにもあります。その点を忘れてはいけません。
7. コードレビューとペアプログラミングを使い分ける
メンバーを育成し、ソースコードの品質を高める目的で、ペアプログラミングが用いられることもあります。ペアプログラミングにはどんな長所・短所があり、どのようにコードレビューと使い分けるべきなのでしょうか。
ペアプログラミングの長所は、ドライバー（ソースコードを書く側）の開発効率・学習効率が非常に高くなることです。ドライバーがわからないことや誤って理解していることに対して、ナビゲーター（指摘をする側）がリアルタイムでコメントをしてくれるためです。
一方でペアプログラミングには、細かい部分に対する指摘が漏れやすいという短所があります。リアルタイムで指摘をしていくという特性上、ソースコードに書かれた内容についてナビゲーターが熟考することが難しいためです。また、ナビゲーターが特定領域についての知識が少ない場合、指摘に抜け漏れが発生してしまう危険性もあります。
コードレビューであれば、そうした欠点をカバーできます。レビューアーがある程度時間をかけてソースコードを読み解くことができますし、複数人でレビューすることによって知識の偏りを防げるからです。これらを踏まえ、コードレビューとペアプログラミングを適切に使い分けましょう。
終わりに
読者のなかには、日常的にコードレビューを実施している方も、普段はあまりコードレビューを行っていない方もいらっしゃると思います。もしかしたら、「コードレビューなんて、時間ばかりかかる無駄な作業だ」と考える方もいるかもしれません。
ですが、前述のとおりコードレビューは重要な「投資」なのです。この工程があることによって、中長期的に見たプロジェクトの成功率は確実に上がります。また、メンバー同士の知識がチームに共有されることにより、職場全体の技術レベルも向上するでしょう。
あなたが今いるチームにコードレビューの文化がないならば、本稿の内容をもとにして「なぜレビューを実施する意味があるのか」を提案してみてください。本来、エンジニアはまじめな人が多いですから、メリットを理解できればきっと賛同してくれるはずです。
本稿が、良いコードレビューを行うためのご参考になれば幸いです。
監修：高遠和也（株式会社LIG CTO）
コードレビューを含む案件のご紹介
FLEXYでお取り扱いしているコードレビューを含む案件をご紹介します。気になる案件がありましたらお気軽にご連絡ください。
【AWS】世界に通用する “ KAWAII ” を生み出している企業で技術顧問支援（フルリモート可）
ソーシャルゲームを通し、日本のkawaii文化の伝播をビジョンにおいた企業です。開発組織としては、ビジョンはあるが技術的な観点での方向性を定めたい、エンジニアの技術全体の底上げをしたい、という思いをお持ちです。
■案件概要
- 職種：CTO
- 稼働日数：月1-2日
- 報酬：〜20万円／月
- 勤務地：四条
- リモート：可
■募集背景
バックエンドやインフラ領域の技術の知見が、エンジニアマネージャーを含めても社内に不足している状況です。また、インフラチームを立ち上げたいため、その観点でも技術アドバイスをいただけると嬉しいです。（ビジョンはあるけど方向が分からない状況）
■業務内容
ソーシャルゲーム開発において、バックエンド/インフラ領域（AWS環境下）の技術アドバイスをいただきたいです。
- 技術選定（ex. バージョンアップ時の判断等）
- コードレビューや勉強会
■必須要件
- AWS環境下で技術選定や技術アドバイスができる方
- コードレビューができる方
■歓迎要件
- ゲーム開発に携わったことのある方
- エンジニア組織の立ち上げに強い方
案件のご紹介を希望される方は、FLEXYに登録（案件のご紹介）よりご応募ください。
多種多様な事業領域でシステム開発やサービス提供をしている企業でECサイト事業のマイクロサービス化推進支援
関西地場大手グループでホワイト500認定の優良企業です。外部人材含めメンバーを大事にする社風で就業歴の長い方が多い組織です。成長市場のECソリューション分野でニーズ拡大中のサービス基盤強化でご実績が作れるお仕事です。
■案件概要
- 職種：ITコンサルタント
- 稼働日数：週2〜3日
- 報酬：〜48万円／月
- 勤務地：野田
- リモート：可
■募集背景
現在同社が運営するECサイト事業のマイクロサービス化を推進しています。マイクロサービスの導入により開発Teamを分割できる状態にして、納期短縮や外注化を可能にしたいですが、社内に導入知見が無く試行錯誤しながら開発中です。今後実施予定のSingle Page Application化も含めて、知見を元に開発を牽引して頂ける方を募集しております。
■業務内容
- アーキテクチャ設計
- コードレビュー
- リファクタリング対応方針相談
■必須要件
- 状況に応じて対応策の提案ができる方
- 既存のソースコードから問題点や改善箇所を指導できる方
- 開発言語/インフラ/ネットワーク/マイクロサービスの知識
■歓迎要件
- 初月のキャッチアップ期間だけ常駐できる方
案件のご紹介を希望される方は、FLEXYに登録（案件のご紹介）よりご応募ください。
学生中心のスタートアップ企業で設計図からメタバース空間に建築できるツール開発のPM支援(フルリモート可)
・学生中心のスタートアップ企業で、メンバーのバリューを最大化することでより質の高いプロダクト開発に導くやりがいの大きな案件です。メタバースなど今アツい新しい領域でのご経験を積める案件です。
■案件概要
- 職種：PM
- 稼働日数：週2〜5日
- 報酬：〜50万円／月
- 勤務地：本山
- リモート：可
■募集背景
昨年7月創設の学生を中心とした企業で、現在、設計図からメタバース空間に簡単に建築ができるツールをUnityを使って開発しています。昨年11月にβ版をリリースしていますが、まだまだバグが多くβ版とは言えない状態です。
今夏メタバース空間での音声通話などの機能追加やバグの修正を進め、その後は不動産企業への営業などを含め今年度中の正式リリースを予定しています。
開発は先月からアジャイル開発を取り入れていますが、元デザイナー領域でマネジメント未経験の方がリーダーを担っていることや、エンジニア全体のスキル不足もありうまく開発が進捗していない状況です。
開発をスムーズに進めるため、プロジェクト全体のリードやタスクの割り振り、進捗管理をになっていただける方を募集しています。
■業務内容
以下を含めたプロジェクト全体のリード
- タスクマネジメント（アジャイルベース）
- 要求、要件定義
- チームビルディング
- コードレビューなどの技術指導（可能であれば）
■必須要件
- アジャイル開発におけるプロジェクトマネジメント経験
■歓迎要件
- Unityを使った開発経験
- メタバースを活用したプロダクト開発又はそのマネジメント経験
案件のご紹介を希望される方は、FLEXYに登録（案件のご紹介）よりご応募ください。
