レビュー文化が定着しない現場
開発チームの中にコードレビューを導入しているものの、うまくワークしていない組織が多いという話はよく聞かれます。または、表面的にはうまくいっているようには見えても、負荷が特定の人に集中している（その人が我慢しているからうまくいっているように見える）というケースや、結果的にコードの品質は上がっていないと言った話もよく聞かれます。
レビュー文化が根付くかどうかは、チームの文化やフェーズに大きく依存します。そのため、自社サービスを開発しているチームのように固定メンバーの場合は、レビュー文化が根付くこともありますが、プロジェクトごとにメンバーが変わるようなチームでは、レビュー文化をイチから作らなければなりません。この場合、実はチームではなく、企業としてレビュー文化の育成に取り組む必要が出てくるでしょう。
レビュー文化が定着しない理由は何でしょうか。本記事では、その辺りを深掘りしながら、レビュー文化を根付かせるための視点を提供します。
なぜうまくいかないのか？レビュー導入の3つの障壁
コードレビューがうまくワークしていない現場で、よく聞かれる声をいくつか挙げてみましょう。
レビューが面倒くさい
これはレビューする側、多くの場合シニアエンジニア側の視点になります。レビューは時間がかかり、面倒な作業と感じられがちです。特に、レビュー対象のコードが多い場合や、複雑なロジックを含む場合は、その傾向が強まります。
レビューを行う場合には、まず自分自身の作業をストップしなければなりません。コーディングが乗っている時、思考をスイッチするのは大変です。そして、レビュー対象のコードを読みつつ、その意図を理解しなければなりません。場合によっては、業務レベルの知識を思い起こしたり、ドキュメントを参照したりする必要もあります。これらの作業は、時間と労力を要し、面倒に感じられることが多いです。
その割に指摘事項がぱっと見れば分かる程度のものだったり、タイポだったりすればどう感じるでしょうか。「こんなことを指摘するために、こんなに時間をかけるのか」と感じてしまうのは自然なことです。
レビューの質がバラバラ
レビューの質が人（レビュアー）によって異なることも、レビューを受ける人にとって大きなストレスになります。特に、チーム内で経験やスキルの差が大きい場合、レビューの質にばらつきが生じやすいです。
バラツキは異なるレビューイの場合もあれば、同じレビューイでも発生する可能性があります。レビューイは多くの場合、シニアレベルのエンジニアであり、多忙です。彼ら自身多くのタスクを抱えており、その合間をぬってレビューを行っています。
そのため、プロジェクト初期は時間がとれるので割としっかりレビューができるのですが、終盤になってくると時間がなくなり、余裕がなくなります。大抵、プロジェクト終盤になるに従ってコードの複雑性が増すので、できれば終盤のコードレビューの方が重要なのですが、時間が取れないために悪い意味で適当なレビューになりがちです。さらに悪いパターンは、レビューイの余裕がなくなり、コメントが攻撃的になったりするでしょう。
レビューイによって質が変わる場合、レビュアーは誰に出せば指摘が少なく通過できるかを考えるようになってしまいます。その結果、なるべく緩いレビューイの時を狙ってPRを出し、レビューを依頼するようになります。これは組織の健全性において問題があります。
レビューがボトルネック化
レビューを一切通していないコードをプロダクトの中に組み込むのは危険です。そのため、レビューを通すのは大事なのですが、そのレビューがボトルネックになって開発生産性が低下してしまうと言う問題があります。レビューは誰でもできるというものではありません。その結果として、特定の人たちに負荷が集中し、ボトルネックになってしまうのです。
真剣にレビューを行おうとすると、仕様や要件の把握が必要になり、時間を要します。1日に数件しかコードレビューできない場合もあるでしょう。そうなると、複数人のプログラマーがいれば、どんどんレビュー待ちが増えてしまいます。とはいえ、レビューをなおざりにすれば、プロダクトの品質が下がってしまいます。
レビューを受けるのが恐い
レビュアーから聞かれる声です。ジュニアレベルのプログラマーの場合、コードに自信がありません。ロジックが無駄に複雑化している、スパゲティコードになっていることもよくあります。そうしたコードを人前に出すのは恥ずかしさもあるかも知れません。
その上で、レビューイから手厳しい指摘があれば、もうコードを見せるのが恐くなってもおかしくありません。チームにおける精神的安全性が担保されていない状態は、開発生産性の低下に直結します。プログラマーは自分の悪いところを隠すようになり、メンバー間の対立などにもつながるでしょう。
レビューできる人がいない
ジュニアレベルのプログラマーは、シニアレベルのプログラマーにレビューを受けられます。ではシニアレベルのプログラマーは誰にレビューしてもらえれば良いでしょうか。小さなスタートアップの場合、CTOすら前線でコードを書いていることもよくあります。その場合、CTOのコードを誰がレビューできるでしょうか。
CTOのコードを見て、タイポを指摘できるプログラマーが組織の中にいるでしょうか。CTOの機嫌を損ねてしまい、自分のコードレビューで細かな指摘を受けるかも知れません。そうした精神的安全性が担保されていない状態で、上下関係の逆転したレビューは困難です。
同様に、スモールチームではアプリ・Web・サーバーサイドのエンジニアが一人ずつしかいない場合も多いです。少数精鋭といえば聞こえが良いですが、コードレビューは非常に困難です。自分の畑違いのプログラミング言語を見て、適切な関数やロジック、ライブラリを使っているか判断するのは難しいでしょう。
チームのフェーズ別に考えるレビュー導入
コードレビューはチーム開発時には必須の仕組みですが、そのやり方や考え方はチームの規模によって異なります。ここでは3段階のチーム規模に分けて、それぞれの最適なレビュー体制について解説します。
小規模チーム（5名以下）
スタートアップや、新規サービス立ち上げなどでよくあるチーム人数です。この規模では、各メンバーが専属的技術を持っており、横断的な技術を持っているのはリーダー的な人になるでしょう。また、担当が分かれているため、互いの業務要件について把握している人は多くありません。
こうしたチームでは、会話やチャットベースでの即時レビューがお勧めです。それぞれに専門外の技術を扱っていることが多いので、実際のコードの細かな部分をレビューするのは難しいでしょう。よほどのタイポやロジック的におかしい部分がなければ問題なしと判断してしまうはずです。
リーダーによるレビューでは、より細かな部分までチェックが入るでしょう。ただし、それでも要件の詳細な部分については担当者しか知らない部分もあるはずです。そうした部分については、担当者の責任において実装し、必要があればチームメンバーへ説明する形になります。
中規模チーム（5〜15人）
中規模になると、レビューを行う人が複数人になります。そのため、組織におけるレビュー方針が必要になります。小規模チームではリーダー自身が指針でしたが、中規模になると指針を明文化し、チームでの共有が必要になります。
こうした指針ができると、ミドルクラスのエンジニアでもレビューが行えるようになります。レビューの権限を委譲できれば、組織の開発生産性の低下を防止できます。
また、コーディング規約なども明文化し、フロントエンドチームなどで共有されます。こうした規約はLinterの設定に反映され、レビュー前の品質維持に利用されます。
大規模チーム（16名以上）
よりチームの規模が大きくなると、レビュー体制の確立が必要になります。特に大事なのは、スケールすることを念頭におき、組織全体における開発生産性とプロダクトの品質維持を両立することです。
そのために、体制とともにツールの導入・活用が重要になります。Linterや自動コードレビューの導入により、人によるレビュー前にコード品質を高めるための工夫が必要です。こうしたツールの導入検討は、レビュー体制の一部に含めるべきです。
体制を作る際には、レビューを行うための学習環境も用意すべきです。レビューを権威的なものにするのではなく、プログラマーとしての成長の一環に組み込むことで、レビューを通してレビュアーとレビューイの相互成長を促せるようになります。これが組織におけるレビュー文化の育成につながります。
レビュー文化を育てるために必要なもの
開発組織にレビュー文化が根付かない、という課題はよく聞かれます。思い立ってレビューをはじめても、半年もするとレビューがお飾りになっているなど、いつの間にかレビューしない状態に戻ってしまったなんて話もあります。さらにレビューガイドラインを作ったものの、形骸化しているという声もあります。
では、レビュー文化を育てるためには何が必要なのでしょうか。ここでは、以下の3つのポイントで解説します。
- コミュニケーションからはじめる
- 軽めにはじめる
- レビューは学びだという共通認識を持つ
コミュニケーションからはじめる
レビュー以前の話として、開発組織の中に対話がほとんどないという問題はないでしょうか。チャットがほとんど使われていない、技術的な相談がメンバー同士で行われていないといった状況ならば、まずその問題を解消しましょう。
チームの大小に関わらず、各自の担当部分が明確に分かれていると「相談しても仕方がない」と考えてしまう傾向があります。また、みんなが忙しそうにしていると「相手の時間を奪ってしまうのは申し訳ない」「イライラしていそう」と感じて相談に及び腰になってしまいます。
そうならないように、チームの心理的安全性を高め、カジュアルに相談できる雰囲気を作りましょう。相互に相談できる状態になれば、互いの信頼関係も生まれ、レビューも自然発生的に行われるようになるでしょう。
軽めにはじめる
レビューを仰々しくはじめるのは避けましょう。いきなり「コードレビューを始めます」と宣言しても、メンバーは戸惑うだけです。まずは、軽いコミュニケーションから始めましょう。
例えば、コードの変更点をチャットで共有し、軽くコメントをもらうところから始めます。最初は「これで大丈夫？」といった簡単な質問からで構いません。メンバーが気軽に自分の意見を言えるような雰囲気を作ることが重要です。
特に大事なのは、シニアエンジニアの相談に対して、ジュニアであっても意見を言えるような環境作りです。レビューが常にトップダウンで行われてしまうと、本格的なレビューが行われるようになった際に、シニアエンジニアばかりに負荷がかかるようになります。
レビューは学びだという共通認識を持つ
レビューを何のために行うのか、その共通認識を持ちましょう。よくないのは、レビューが「コードの品質を上げるため」や「バグを減らすため」といった目的で語られることです。確かにそれも重要な目的ですが、レビューの本質は「チーム全体の技術力を向上させるため」にあります。
レビューはジュニアレベルのエンジニアに学習機会を提供し、チーム全体で業務知識を獲得するのにも役立ちます。レビューは単なるコードのチェックではなく、チーム全体の成長を促すための重要なプロセスです。そのためにも、特定の人に負荷を押しつけるような形になってはいけません。
まとめ
レビュー文化が根付かない理由は、これまでのチーム文化やフェーズに大きく依存します。レビューを導入する際には、チームの規模や特性に応じた設計が必要です。場合によっては、チームの文化そのものを見直す必要もあるでしょう。
最初は小規模、カジュアルにはじめてみましょう。その中でトライ＆エラーを繰り返し、徐々にレビューの質を高めていくことが重要です。そして、うまくいった施策をチーム全体に広めていくように進めてみましょう。
おまけ：CodeRabbitの活用
CodeRabbitはAIコードレビューサービスで、GitHubやGitLabと連携してPRに対して自動的にレビューを実行します。開発者はCodeRabbitからの指摘を確認し、修正を行うことで、コードの品質を向上できます。最近リリースされたCodeRabbit for VSCodeを利用することで、ローカルでのレビューも「無料で」可能になりました。
ぜひ、CodeRabbitを活用して、コードレビューの効率化と品質向上を図ってください。
Discussion