コードレビューを成功させるためにCTOが考えるべき7つのことー監修:高遠和也(株式会社LIG CTO)

コードレビューとは、誰かが作成したソースコードを他者がレビューすることで、問題のある記法やバグがないかを確認する作業のこと。プログラムの品質を高めるために、なくてはならない工程のひとつです。

しかし、コードレビューを成功させることは簡単ではありません。読者のなかにも、「同じような指摘を何度もしているのに、メンバーのスキルが向上しない」「つい感情的なコメントをしてしまう」といった悩みを抱えている方は多いのではないでしょうか。

やみくもにコードレビューを実施しては、成功率は上がりません。レビューアーが実施方法やマインドを適切なものに変えなければ、良いコードレビューにはならないのです。
ここでは、コードレビューを成功させるための方法を7つご紹介します。

本記事の監修:高遠和也(株式会社LIG CTO)

コードレビューを成功させるためにCTOが考えるべき7つのこと

①レビューイーに「どのレイヤーの知識が不足しているのか」を考える

レビューイーが良くないソースコードを書いている場合、レビューアーは「なぜ、レビューイーはこのソースコードを書いたのか?」を、まず考える必要があります。

特定言語の文法やメソッドを知らないのかもしれません。例外がどのような状況のときに発生し、どうエラーハンドリングすべきなのかを理解していないのかもしれません。デザインパターンを学んだことがなく、どのような設計が適切なのかわからないのかもしれません。良くないソースコードを書く理由は十人十色なのです。

コードレビューで指摘をする際に、「レビューイーにどのレイヤーの知識が不足しているのか」を確認しましょう。例えば「○○ではなく△△のような書き方にしましょう」とコメントする代わりに、「○○ではなく△△のような書き方もできますよ。○○にした理由はありますか?」と問いかけてみましょう。

返答の内容によって、レビューイーにどのような知識があるのかを可視化できます。それをふまえてレビューを進めることで、コードレビューの効果をより高められるのです。

②レビューの目的は何か、チーム内でコンセンサスをとる

「コードレビューが終了したときに、どういう状態になっていれば成功なのか」を意識したことはあるでしょうか。答えが「NO」ならば、コードレビューの実施方法そのものを見直した方が良さそうです。

メンバーが目的と共通認識を見失ったコードレビューは非常に危険です。例えば、新人エンジニアに対して高すぎる要求をする中堅エンジニアが現れたり、些末なことにこだわって他工程の工数が逼迫されてしまったり、ということが考えられます。こうした状況を防ぐには、レビューが「何を目的としているか」「どの程度の品質レベルを担保したいのか」などのコンセンサスをとることが重要です。

コードレビュー会など対面でレビューを行う場合は、実施前に各メンバーと口頭で確認を取りましょう。Pull Requestをベースに机上でレビューを行う場合は、実施中に特定のメンバーがレビューの舵取りをするのをおすすめします。テックリードやCTOなどの立場にある方は、こうした場で適切なファシリテーションをすることで、組織の文化をつくり上げることも重要な役割です。

それでは、どのようにファシリテーションをしていくか例を挙げます。例えば、重要な機能のリリースが差し迫っているにもかかわらず、中堅エンジニアが新人エンジニアに対して「新機能で○○のメソッドを修正するついでに、△△の処理をリファクタリングしてください」と、コメントしたとしましょう。

この状況で、最も優先すべきは「重要な機能にバグが含まれていない状態でリリースすること」であって、「ソースコードの可読性を高めること」ではありません。

中堅エンジニアに対して「△△のリファクタリングは、すごくいいですね! ただ、修正の期間があまりないので、機能をリリースした後にリファクタリングをする方針にしましょうか」とコメントし、最優先すべき目的を守りましょう。

プログラム開発に投入できる人や時間は有限です。そのため、ソースコードレビューにおいてレビューアーは「自分の指摘にはどれくらいの実現可能性があるか」「指摘を反映した場合に、プロジェクト全体にどんなメリットがもたらされるか」を常に考えておかなければいけません。

そもそも、ソースコードレビューとは広義でいえば「投資」なのです。レビューの段階で悪いコードやバグを未然に発見しておくことで、将来的に必要になる修正・対応コストを削減することが重要な目的になります。その基本を忘れてはいけません。

③批判すべきはコードであり、人格ではない

コードレビューでは、人の習慣や考え方についての批判をしてはなりません。レビューイーが萎縮してしまい、モチベーションが大きく下がってしまうからです。

良くない指摘の代表例は、「以前も指摘したと思いますが、○○は△△してください」といったものです。「以前も指摘したと思いますが」というフレーズが、「人の習慣」に対する批判になっています。

おそらくレビューアーは、イライラしながらこの指摘をしたのではないでしょうか。一方でレビューイーは「以前に受けた指摘をまた受けてしまうのは、自分がなっていないからだ」と自分を責めてしまうはずです。これでは、良いコードレビューになるはずがありません。

なぜこのような事態が起こってしまうのでしょうか。それは多くの場合、「レビューイーが、なぜ良くないコードを書いたのか?」をレビューアーが理解できていないことに起因しています。根本原因を理解できていないため、「失敗するのは、レビューイーの努力や注意力が足りないからだ」という発想に陥ってしまうのです。

これを防ぐためにも、冒頭で解説したように「レビューイーに、どのレイヤーの知識が不足しているのか」を考えることが必要です。その原因を丁寧に解き明かしていけば、レビューイーがなぜ良くないソースコードを書いたのか、どうすれば改善できるのか、道筋が見えてきます。必然的に、レビューアーがレビューイーの習慣や考え方についての批判をすることも少なくなるでしょう。

とりわけ、高いコーディングスキルを持ったエンジニアがレビューアーになった場合に、こういったコメントをしやすい傾向にあります。自分自身が技術に高い関心を持って学習をしてきたからこそ、技術力の未熟な人が「なぜできないのか?」を慮(おもんぱか)るのが苦手なためです。

「自分はそういう傾向があるな」と思う方こそ、意識してこの習慣を身につけましょう。また、レビューアーがレビューイーの習慣や考え方についての指摘をしていないか、常に気を配っておくことが必要です。普段のなにげないコミュニケーションが、チームの文化をつくります。

④コードレビュー“以前”にキャッチアップすべきことを考える

プロジェクトにおいて「コードレビューの段階で指摘をしても、すでに手遅れ」というシチュエーションが発生することがあります。顧客からの要望をそもそも勘違いしていたり、不適切な設計のまま実装を進めてしまったり、ということは、その最たる例でしょう。

こうした事態が起きてしまうと、大規模な手戻りが発生してしまいます。レビューアーもレビューイーも疲弊しますし、大急ぎで修正したソースコードは品質も悪くなってしまうでしょう。誰も幸せになりません。本来ならば、設計を考える前には各メンバーが要件を正しく理解しているべきですし、ソースコードを書く前には設計のアウトラインができあがっているべきです。

これを防ぐには、プロジェクトの初期フェーズにおいて「どの時期にどんな種類のレビューをすれば、最も段取りが良くなるか」のマイルストーンを置き、最善のタイミングで適切なレビューを行うことをおすすめします。取り返しのつかない状態に陥る前に各メンバーのチェックを通すことで、プロジェクトが失敗するリスクを未然に回避できるのです。

また、中期〜後期のフェーズにおいて大きな手戻りが発生するのは、プロジェクトを適切にマネジメントできていないことに起因する可能性が高いです。もしあなたがチームを牽引する立場にあるならば、マネジメント失敗の原因について考えてみましょう。

例えば、顧客の要望を適切にヒアリングできていないのかもしれません。メンバーとのコミュニケーションがそもそも足りていないのかもしれません。根本原因を解消することで、プロジェクトの業務全般も自然と改善されていきます。

⑤「どんな勉強をすれば、コードレビューで受けた指摘を改善しやすくなるか」もセットで教える

多くのエンジニアは真面目ですし、「もっと成長したい」という意欲を持っています。ですが、経験の浅いエンジニアの場合、「何を勉強すれば、自分のレベルを上げられるのか」を理解できていないケースが多いです。

そのため、他のメンバーから「もっと〇〇のスキルを上げよう!」と言われても途方に暮れてしまいます。下手をすると「何を勉強したらいいのかがわからないのは、自分にセンスがないからだ」となってしまい、モチベーションの低下にもつながりかねません。

筆者は「この本や記事がすごく良かったよ」と、勉強するためのヒントになるような情報を、レビュー後にSlack上で共有することが多いです。そうすることで、当人の上達の道しるべとなります。

ここで大事なのは、ダイレクトメッセージではなく、他のメンバーも参加しているチャンネルで情報を共有することです。他のメンバーの学びにもつながりますし、活発に情報交換を行うチーム文化も醸成されるからです。

⑥ソースコードの良い部分には「いいね!」と言う

筆者は、外国人エンジニアが非常に多い企業で働いていたことがあります。そこでは、誰かのソースコードを読んだときに「Good!」とコメントする習慣がありました。とても良い習慣だと筆者は思います。

「Good!」と言ってもらえたメンバーは、モチベーションが非常に高まります。当然、チームの雰囲気も良くなるでしょう。さらに、コメントを見た他のメンバーも「なるほど。これが良い書き方なんだ」と学ぶことができ、メリットだらけなのです。コードレビューで良いコードや良い指摘を目にしたら、積極的に「いいね」とコメントしましょう。絵文字を使うのもおすすめです。

日本人は他の国の人々と比べて、ポジティブなフィードバックをするのが苦手な傾向にあるといわれています。弱み潰しをしてしまいやすいのです。フィードバックとは悪い部分を改善するためだけではなく、良い部分を伸ばすためにもあります。その点を忘れてはいけません。

⑦コードレビューとペアプログラミングを使い分ける

メンバーを育成し、ソースコードの品質を高める目的で、ペアプログラミングが用いられることもあります。ペアプログラミングにはどんな長所・短所があり、どのようにコードレビューと使い分けるべきなのでしょうか。

ペアプログラミングの長所は、ドライバー(ソースコードを書く側)の開発効率・学習効率が非常に高くなることです。ドライバーがわからないことや誤って理解していることに対して、ナビゲーター(指摘をする側)がリアルタイムでコメントをしてくれるためです。

一方でペアプログラミングには、細かい部分に対する指摘が漏れやすいという短所があります。リアルタイムで指摘をしていくという特性上、ソースコードに書かれた内容についてナビゲーターが熟考することが難しいためです。また、ナビゲーターが特定領域についての知識が少ない場合、指摘に抜け漏れが発生してしまう危険性もあります。

コードレビューであれば、そうした欠点をカバーできます。レビューアーがある程度時間をかけてソースコードを読み解くことができますし、複数人でレビューすることによって知識の偏りを防げるからです。これらを踏まえ、コードレビューとペアプログラミングを適切に使い分けましょう。

おわりに

読者のなかには、日常的にコードレビューを実施している方も、普段はあまりコードレビューを行っていない方もいらっしゃると思います。もしかしたら、「コードレビューなんて、時間ばかりかかる無駄な作業だ」と考える方もいるかもしれません。

ですが、前述のとおりコードレビューは重要な「投資」なのです。この工程があることによって、中長期的に見たプロジェクトの成功率は確実に上がります。また、メンバー同士の知識がチームに共有されることにより、職場全体の技術レベルも向上するでしょう。

あなたが今いるチームにコードレビューの文化がないならば、本稿の内容をもとにして「なぜレビューを実施する意味があるのか」を提案してみてください。本来、エンジニアはまじめな人が多いですから、メリットを理解できればきっと賛同してくれるはずです。

本稿が、良いコードレビューを行うためのご参考になれば幸いです。

監修:高遠和也(株式会社LIG CTO)

技術的負債を無くすために、より綺麗なコードにするために。
コードレビューのできるCTOやハイスペックエンジニアのご紹介を
ご希望の法人様は、下記よりご依頼ください。
即戦力となる人材を、案件(タスク)ベースでご紹介いたします!
法人お問い合わせ
メールでのご連絡を希望の方はflexy@circu.co.jpにご連絡をお願いします。

この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

業務委託契約・開発案件(JavaScriptメイン)

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 4万円/日
必要スキル JavaScript・React
勤務地 東京都内/リモート含む
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

業務委託契約・インフラエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 2-3日/週
報酬 5万円/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート 相談可

業務委託・フロントエンドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週1日〜
報酬 5万/日
必要スキル それぞれの案件により異なります
勤務地 東京
リモート リモートと常駐のMIXなど

人材紹介のCTO案件(非公開求人)

テーマ CTO、技術顧問案件はflexyに登録後、案件をコンサルタントからご紹介します
勤務日数 業務委託から人材紹介への移行
報酬 年収800万以上
必要スキル CTOとして活躍可能な方、エンジニア組織のマネージメント経験
勤務地 東京
リモート 最初は業務委託契約で週3日などご要望に合わせます

業務委託契約・サーバサイドエンジニア

テーマ flexy登録画面から案件詳細の確認と直接応募が可能です
勤務日数 週2-3日
報酬 案件により異なります
必要スキル 案件により異なります
勤務地 東京都内
リモート 相談可能
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)