もうブロッカーにしない！コードレビューを爆速にするための組織づくり

ハコベル 物流DXシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとしてSaaSプロダクトの開発を行なっています。

この記事では、ハコベルで行っている開発効率と生産性の向上を目的としたコードレビューを早めるための取り組みについてご紹介します。

背景

私たちは、ソースコードの管理をGitHub上で行っており、プルリクエストを利用したペアレビューをしています。

一方、事業の拡大によりエンジニアの責務が増加しています。そのため、レビューのタスクが後回しにされ、レビュー待ちがブロッカーになってしまう場面が増え始めていました。

プロダクトの開発効率が低下するだけでなく、開発のリズムが崩れてしまいモチベーションや生産性が低下するといった問題にも繋がってしまいます。

そこで、私たちはコードレビューがブロッカーになることを防ぐために、様々な環境づくりと、仕組みづくりに取り組みました。

コードレビューを早めるための環境づくり

ルール (Working Agreement) の策定

まずは、ハコベル全体で「レビューや修正を優先タスクとする」というルール (Working Agreement) を定めました。

具体的には、次のようなルールを定めています。

• チームメンバーはレビュー依頼を受けたら、それを優先タスクとする
• レビューでコメントがあれば、レビュイーは返信と修正を優先タスクとする。意思疎通に時間がかかるようであればペアレビュー、モブプロを検討する
• レビュイーはレビュアーにレビューの催促をSlackなどでしてもよい
• 当日にレビューをする時間が取れない場合、デイリースクラムなどで告知し、代わりにレビューをするメンバーを相談する

レビューや修正を優先タスクとすることをルールとして明文化することで、チーム内で優先順位の認識を揃えることができました。また、レビューされない場合に促したり、他のメンバーにヘルプを出しやすい空気を醸成しています。

他方で、「コードレビューにラベルを付ける」というルールを定めることで、気兼ねなくレビューコメントを送信しやすい環境を作っています。

https://zenn.dev/hacobell_dev/articles/code-review-comment-prefix

担当するレビュアーの整理

次に、エンジニア1人あたりのレビュー負荷を削減しました。

以前は、1人のエンジニアが複数のリポジトリのレビューを担当することがありました。複数のリポジトリを交互にレビューすることで、コンテキストスイッチが頻繁に発生していました。

ここで言うコンテキストスイッチとは、OSにおけるプロセス管理の用語から転じて、人があるタスクから別のタスクに切り替えることを指します。コンテキストスイッチが増えると、脳に認知負荷がかかり、集中力や生産性が低下し、ミスやストレスが増加すると言われています^[1]。

担当するリポジトリが増えた結果、レビュアーはある程度貯まってからまとめてレビューをすることが増え、レビュイーの待ち時間が増えていました。さらに、他のプロジェクトとごちゃ混ぜになって観点漏れを引き起こすこともありました。

そのため、マネージャー主導の下、レビューを担当するリポジトリを整理しました。

レビュアーのコンテキストスイッチを減らしたことにより、依頼が貯まってからレビューすることが減ったり、より品質の高いレビューが可能になったりする効果がありました。

マネージャー主導の下、レビューを担当するリポジトリを整理

コードレビューを早めるための仕組みづくり

Scheduled reminders の活用

GitHubには、Organizationで使用できるScheduled remindersという機能があります。Scheduled remindersは、参加しているプルリクエストに関してSlackのダイレクトメッセージで通知してくれる機能です。

https://docs.github.com/ja/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-membership-in-organizations/managing-your-scheduled-reminders

主に2種類の通知があります。

• アサインされた、コメントされた、メンションされたなどのイベント時にリアルタイムで行われる通知
• レビュー待ちになっているプルリクエストのサマリーを特定の時刻に行う通知

GitHub アプリから届く Scheduled reminders の通知の例

設定は各自のアカウントにおいて行う必要があるため、Working Agreement内でメンバーに設定するようにお願いしています。

この機能を活用することにより、チームメンバー全員のプルリクエストに関するレスポンスが大きく向上し「レビューや修正を最優先タスクとする」というルールを無理なく仕組みで実現できました。

一方、より通知を活用できるようにGitHubの使い方についてオンボーディングで行うようにしています。

修正し終わってから、再度レビューしてほしいタイミングで Re-request review ボタンをクリックする

作業中のプルリクエストは Draft に設定する

Code Owners の活用

GitHubには、 Code Owners  という機能があります。この機能を用いるとファイルやディレクトリごとに責任者を指定できます。

https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

該当のファイルに対する差分があるプルリクエストを作成すると、レビュアーを指定せずとも自動でアサインされます。チームを設定した場合は、Code review assignmentの機能も使用されます。

自動でコードオーナーがレビュアーとしてアサインされる

設定方法は .github/CODEOWNERS を作成することで行います。例えば、スキーマの変更ではチーム全員をアサインするが、フロントエンドの変更ではフロントエンドメンバーのみをアサインするといった設定が可能です。

/project-frontend/ @octo-org/example-frontend
/project-backend/ @octo-org/example-backend
.graphqls @octo-org/example-backend @octo-org/example-frontend

この機能を活用することにより、レビュー作成時にレビュアーを入力する必要がなくなるためレビュー依頼の効率が向上します。また、複数メンバーの中で手が空いたメンバーから先にレビューできるため、より迅速にレビューをしてもらうことができます。

さらに、担当する領域に関わるすべてのプルリクエストにアサインされることから、チーム内で共通認識を持つことができます。属人性の解消ができるため、他のメンバーが代わりにレビューしても背景を理解したより質の高いレビュー品質を保つことが可能になります。

まとめ

ハコベルで行っている開発効率と生産性の向上を目的としたコードレビューを早めるための取り組みについて紹介しました。

環境づくりと仕組みづくり両面からの取り組みを行うことで、コードレビューの速度と品質が向上しました。

結果として、事業の拡大を進める中でチーム全体としてデリバリーの速度が向上し、顧客への価値提供をより迅速に行える組織を作ることができました。