#98 コードレビューできる組織づくり～ルールは勝手に浸透しない～

以前にコードレビューをされる側に求められる技術について紹介しました。

社内でも同様の内容を共有したところ多くの同意を得られました。
一方で、そうはいっても難しいという声も上がってきました。

レビューしてもらいやすいプルリクエストの作り方に関する情報は世の中に溢れていますが、実践出来ている組織はあまり多くありません。

ということで、今回は私が自分のチームでコードレビューの文化を浸透させるために行ってきたことを紹介します。

〇コードレビュー文化の土台作りは欠かせない

良くあるアンチパターンはルールを定めて満足するというものです。
ルールがあれば後は勝手に文化が生まれるというのは幻想です。忙しくてルールを作るまででお腹いっぱいになるケースも散見されます。

が、土台作りにはコストがかかると理解し覚悟して取り組まないとルールが浸透することはありません。

自分が一番コードレビューする

日常的にチームのメンバーがコードレビューをする空気感を作るためには、自分が一番コードレビューすることです。
私は自分のチームのメンバーが作るプルリクエストを全てレビューしていました。

最大10人のエンジニアを抱えていた時は真面目にレビューを行うと仕事時間の30%はコンスタントにレビューに持っていかれるので、一定期間やり続ける覚悟が必要です。

👍（承認）2つ以上でマージOKというルールを決める

自分自身が一番レビューするのは必須ですが、一人でレビューし続けるのには限界があります。
そのため、自分とあと一人はレビューしないとマージ出来ないというルールを徹底します。

非常に軽微な対応であればセルフ👍は許容するなど、ルールに柔軟性は持たせつつもレビューをしないと開発が進捗しないという不快感を作っておくことも大切です。

設計を共有し、統一させる

コードレビューされる技術として紹介していないのですが、レビューが難しいケースとして、「意図した振る舞いだがこの実装方針が適切か判断出来ない」ということがあります。
振る舞いとしては正しいからと安易にマージしてしまうと一つのアプリに複数の実装パターンが存在することになります。

それを抑制するためには、事前に設計思想をチームに共有し、プルリクエストのレビューを通しても設計観点のコメントをしたり参考実装を伝えるなど、設計方針に沿わない実装を許容しないようにする必要があります。

当り前のことではあるのですが、コストをかけないと実現が難しいてす。おざなりになりがちなので気をつけましょう。

〇コードレビューパトロールを怠らない

自分が先頭を切ってレビューをしながら毎日のように「このプルリクエストあと１人レビューお願いします。」「今日マージしないとスケジュール影響ありますよ。」「変更が少ないので秒で見れますよ」「〇〇のドメイン知識をキャッチアップ出来ますよ」など、あの手この手この手でレビューの斡旋をしまくります笑

レビューの文化がない時はそもそも日常にレビューをするという発想がないので、待っていてもレビューされません。

毎日のようにしつこいくらいに斡旋をして、レビューをするというイベントを当たり前にしていきます。

また、定期的にレビュー会を実施するのも高価的です。
メンバーで集まって同時にレビューを行います。対応内容の背景や業務知識を、レビュー観点などをベテランから共有できるのも大きな価値があります。

〇当たり前レベルをキープする

泥臭くコードレビューの文化を根付かせることができたら、チームののメンバーもパトロールに加わってくれたり、改善の声が上がってきます。

私のチームでは前述のレビュー会や、レビューをランダムでアサインしてslackで通知する仕組みなどが導入後されました。

このように当たり前のレベルが上がってきたら完了ではありません。
このレベルをキープすることも考えましょう。

チームメンバーが忙しくなってレビューが疎かになったり、人の出入りによって文化の浸透のやり直しが必要になります。

状況に合わせて適宜アクションしましょう。

と言うことで、チームにコードレビュー文化を浸透させるために私の実践方法を紹介しました。
成熟した組織にとっては当たり前のことではありますが、ベンチャーから上場を目指す未成熟な組織の一例として、参考になれば幸いです。

最後までお読みいただきありがとうございます。