この記事では、ハコベルで行っている開発効率と生産性の向上を目的としたコードレビューを早めるための取り組みについてご紹介します。
サクッと読みたい方はこちらのスライドもどうぞ。
※ この記事に記載の内容は当時の情報です。最新の状況を反映していない可能性があるため、ご了承ください。
背景
私たちは、ソースコードの管理をGitHub上で行っており、プルリクエストを利用したペアレビューをしています。
一方、事業の拡大によりエンジニアの責務が増加しています。そのため、レビューのタスクが後回しにされ、レビュー待ちがブロッカーになってしまう場面が増え始めていました。
プロダクトの開発効率が低下するだけでなく、開発のリズムが崩れてしまいモチベーションや生産性が低下するといった問題にも繋がってしまいます。
そこで、私たちはコードレビューがブロッカーになることを防ぐために、様々な環境づくりと、仕組みづくりに取り組みました。
コードレビューを早めるための環境づくり
ルール (Working Agreement) の策定
まずは、ハコベル全体で「レビューや修正を優先タスクとする」というルール (Working Agreement) を定めました。
具体的には、次のようなルールを定めています。
- チームメンバーはレビュー依頼を受けたら、それを優先タスクとする
- レビューでコメントがあれば、レビュイーは返信と修正を優先タスクとする。意思疎通に時間がかかるようであればペアレビュー、モブプロを検討する
- レビュイーはレビュアーにレビューの催促をSlackなどでしてもよい
- 当日にレビューをする時間が取れない場合、デイリースクラムなどで告知し、代わりにレビューをするメンバーを相談する
レビューや修正を優先タスクとすることをルールとして明文化することで、チーム内で優先順位の認識を揃えることができました。また、レビューされない場合に促したり、他のメンバーにヘルプを出しやすい空気を醸成しています。
他方で、「コードレビューにラベルを付ける」というルールを定めることで、気兼ねなくレビューコメントを送信しやすい環境を作っています。
担当するレビュアーの整理
次に、エンジニア1人あたりのレビュー負荷を削減しました。
以前は、1人のエンジニアが複数のリポジトリのレビューを担当することがありました。複数のリポジトリを交互にレビューすることで、コンテキストスイッチが頻繁に発生していました。
ここで言うコンテキストスイッチとは、OSにおけるプロセス管理の用語から転じて、人があるタスクから別のタスクに切り替えることを指します。コンテキストスイッチが増えると、脳に認知負荷がかかり、集中力や生産性が低下し、ミスやストレスが増加すると言われています[1]。
担当するリポジトリが増えた結果、レビュアーはある程度貯まってからまとめてレビューをすることが増え、レビュイーの待ち時間が増えていました。さらに、他のプロジェクトとごちゃ混ぜになって観点漏れを引き起こすこともありました。
そのため、マネージャー主導の下、レビューを担当するリポジトリを整理しました。
レビュアーのコンテキストスイッチを減らしたことにより、依頼が貯まってからレビューすることが減ったり、より品質の高いレビューが可能になったりする効果がありました。
マネージャー主導の下、レビューを担当するリポジトリを整理
コードレビューを早めるための仕組みづくり
Scheduled reminders の活用
GitHubには、Organizationで使用できるScheduled remindersという機能があります。Scheduled remindersは、参加しているプルリクエストに関してSlackのダイレクトメッセージで通知してくれる機能です。
主に2種類の通知があります。
- アサインされた、コメントされた、メンションされたなどのイベント時にリアルタイムで行われる通知
- レビュー待ちになっているプルリクエストのサマリーを特定の時刻に行う通知
GitHub アプリから届く Scheduled reminders の通知の例
設定は各自のアカウントにおいて行う必要があるため、Working Agreement内でメンバーに設定するようにお願いしています。
この機能を活用することにより、チームメンバー全員のプルリクエストに関するレスポンスが大きく向上し「レビューや修正を最優先タスクとする」というルールを無理なく仕組みで実現できました。
一方、より通知を活用できるようにGitHubの使い方についてオンボーディングで行うようにしています。
修正し終わってから、再度レビューしてほしいタイミングで Re-request review ボタンをクリックする
作業中のプルリクエストは Draft に設定する
Code Owners の活用
GitHubには、 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
この機能を活用することにより、レビュー作成時にレビュアーを入力する必要がなくなるためレビュー依頼の効率が向上します。また、複数メンバーの中で手が空いたメンバーから先にレビューできるため、より迅速にレビューをしてもらうことができます。
さらに、担当する領域に関わるすべてのプルリクエストにアサインされることから、チーム内で共通認識を持つことができます。属人性の解消ができるため、他のメンバーが代わりにレビューしても背景を理解したより質の高いレビュー品質を保つことが可能になります。
まとめ
ハコベルで行っている開発効率と生産性の向上を目的としたコードレビューを早めるための取り組みについて紹介しました。
環境づくりと仕組みづくり両面からの取り組みを行うことで、コードレビューの速度と品質が向上しました。
結果として、事業の拡大を進める中でチーム全体としてデリバリーの速度が向上し、顧客への価値提供をより迅速に行える組織を作ることができました。
-
Qatalog with Cornell University’s Ellis Idea Lab "Workgeist Report ‘21" ↩︎
「物流の次を発明する」をミッションに物流のシェアリングプラットフォームを運営する、ハコベル株式会社 開発チームのテックブログです！ 【エンジニア積極採用中】t.hacobell.com/blog/career
Discussion
この記事ではルールやツールを用いた手法をメインとしていますが、元々チームファーストな行動指針や、OKR が整備されていたからこそ成功したという面もあると考えています。
自分の中で整理できたら、そのあたりもまた書いてみます！