マージリクエストにレビュアーを割り当てるBotを運用してみて

2022年1月26日 17:30

入社1年目 Web開発担当のYです。よろしくおねがいします。エンジニアブログの1記事目を任されました。よ〜し、ぼくがんばっちゃうぞ〜！

📝 概要

今回は、GitLabのマージリクエストにレビュアーを割り当てるBotの開発と運用の話をします。

このBotは、Web開発のコードレビューの回りが悪いことへの改善策として、私がメインで開発し、運用しています。運用した結果、以前よりもコードレビューがスムーズに進み、溜まっているマージリクエストの数はおよそ半数(40個台→20個台)に減りました。今もその状況を継続できています。このBotの開発・運用の流れをご紹介します。

マージリクエスト：GitHubなどでいうプルリクエストに相当します。GitLab特有の表記のようです（参考記事）。

コードレビュー：主に動作確認(test)とコードの校閲(review)を行い、その実装が現行のプロダクトに統合されても問題が発生しないかを確認するような作業です。コードレビューする人をレビュアー(reviewer)、レビューされる人(マージリクエストの執筆者)をレビュイー(reviewee)と言います。

🤔 開発動機

前提情報

先に、弊社のコードレビューのフローを紹介します。

弊社では、バージョン管理システムとしてGitを、コードレビューツールとしてGitLabを利用しています。基本的には、開発してマージリクエスト（以下MR）を出してレビューもらってGOサインが出ればマージ、というフローです。

課題点

このようなフローの中で、以前のWeb開発のチームではレビューを 「手の空いた人が、できそうなものを適宜レビューする」 形で回していました。その結果、重たいタスクを請け負っているエンジニアがタスクにかかりきりになってしまったり、レビューが難しそうなMRに長い間レビュアーがつかなかったりして、レビュー待ちで作業が止まってしまうことが増えていました。

💡 そこで、レビュアーを自動で決めてMRに割り当ててしまおう という話になり、「これは是非やってみたい！」と思った私が手を上げて、Botを開発・運用することになりました。

🖥 開発の流れ

要件

開発要件として最初に決まっていたのは以下の点です。

各MRにレビュアーを2人割り当てる
- 当時、他の開発チームがレビュアー2人体制だったことを参考に
- 2人とも新人にはならないようにする
割り当てられるメンバーはランダムで選択される
- 当時、他では↓の流れで運用していたので、他でやってないランダムを試してみることに
  - アプリ開発のメンバーは順番に自動割り振り
  - サーバー開発のメンバーは手動で指名
- ランダムでは不都合がある場合は手動で指名することで対応

言語と実行環境

今回はメインで開発するのが私だったので、私が一番使い慣れている Python で開発することにし、出来上がったものを実際に動かす際にはAWSの何らかのサービスを利用することだけを先に決めて開発に入りました。

最終的な言語と実行環境を書いておきます。

言語：Python 3.9.6
実行環境：AWS Lambda + Amazon EventBridge

開発

まずは動くことが大事！という勢いで開発しました。処理内容をフローチャートにして↓に示します。開発中はGitLabのAPIリファレンスに大変お世話になりました。この動作がひとまず動くようになったので、先輩にお願いして実行環境を手配・デプロイしてもらい、運用のフェーズに入りました。

🏃 運用

課題発見と改善

9月下旬から1週間程度運用してみたところ、他の社員さんからの意見や自分の感覚としても、改善すべき点が出てきました。整理すると、以下の3つの課題点があることがわかりました。

ランダムがランダムすぎて割り当てが偏ってしまって業務が圧迫されてしまっている
割り当てられていることに気が付かないので結局レビューが遅くなってしまう
レビュアーが2人になったことで、差分の小さなMRもレビューに時間がかかるようになった

ここからこの課題点を解決していくことになります。それぞれの課題の原因を考察しつつ、業務効率化に向けてBotを改良していきます。

1. 重み付きランダムでレビュアーを割り当て

1つ目の課題の原因は、ランダム性を制御せずそのまま利用していたことです。全てがすべて一定の時間でレビューできるわけではないので、重たいMRに割り当てられた人に更にレビューが集中してしまうと、業務圧迫につながる欠陥になっていました。

💡 対策として、レビュアーを選択する際に、完全なランダムではなく現状の割り当て具合を考慮して傾斜のついたランダム選択を行うことにしました。

重み計算は以下のかたちで行っています

# 擬似コード (python風味)
基準 = マージリクエストを最も割り当てられているメンバーの担当数
for メンバー in webメンバー全員:
    メンバーの重み = 基準 - メンバーの担当数

この重みをpythonのrandom.choices()にわたすことで、割り当て状態を考慮したレビュアー選択が行われるようになりました。

2. レビューお願いしますコメントを投稿

2つ目の課題の原因は、割り当ての通知がなかったことです。

Web開発のプロジェクトでは、MRが作られたときやMRにコメントがついたときにSlackにその内容が送信されるようになっていて、より手軽にプロジェクトの更新を確認できるようになっています。しかし、今回のBotのレビュアー割り当てではこのSlackへの通知がなされていなかったため、気が付きづらくなってしまっていました。

💡 この対策として、Slackにも割り当て内容が送信されるように、MRに割り当てられたメンバーの名前をいれてコメントをするようにしました。

3. レビュアーを1人にできるように

3つ目の課題の原因は、レビュアーが増えたことでMRのマージまでで依存する人的リソースが増えてしまったことです。もともとはMRは一人がレビューしてGOサインを出せばマージされていたので、それに比べれば開発フローの安全性は向上しましたが、その一方で開発スピードを犠牲にしてしまっている部分があります。特に、差分が小さいMRではこれが顕著で、「計算式1つの変更だけ」でも、レビュアーのタスク状況によってマージまでにかかる時間が長くなることがありました。

💡 この対策として、特定のラベルがMRについている場合にはレビュアーを一人しか割り当てない処理を追加しました。これで軽微な変更などを一人レビューで通すことができ、効率化されたはずです。

現在の処理内容

その後もいくつかの改良が加えられ、現在では以下のようなフローで動作しています。

残っている課題とそれを解決するアイデア

何度かの改善を経た今でも、まだ各メンバーのレビュー速度とレビューを割り当てる量が釣り合っていない状況で、長いレビュー待ちが発生してしまうことがあります。この対策として

MRの変更量からレビュー難度を推定して、これを考慮する
GitLabのユーザーステータスで保持タスク量を各メンバーに設定してもらい、それを参考にタスク量の平均化を図る
タスク管理ツールで各メンバーのタスク量を調べて考慮できる機能を追加する

などを考えています。

🏁 まとめ

このBotを運用し始めて約3ヶ月が経過し、MRのレビュー速度は運用前と比べて向上したと感じています。しかし、各エンジニアが持っているタスクは「開発」のみではないことなど、よりよいMRレビュー割り振りに向けて考慮すべきことはたくさんあります。自分も他タスクの合間を見てよりよい開発環境を目指して改良を続けています。

また、このBotの開発を通じて、「自分の技術力で身近な困りごとを解決する」ことの楽しさを改めて感じられたのもいい体験でした。自分自身も開発したBotの恩恵を受ける当事者であり、またフィードバックをすぐそこにいる社員さんから聞けたことは、開発のモチベーションを持続させる上で非常に大きな要因になったと感じています。普段のweb開発のコードではないものを書くことで気分転換にもなってよかったです。

弊社には、自分の技術力を生かした課題解決ができる積極的な社員が多くいます。今回のBotもそういった社員さんのお力添えも有り開発できました。また、そういう開発力のある新たな社員を常に求めています。是非私達と一緒によりよい開発者環境を作りながら、世の中の課題を解決していってみませんか？興味がある学生の方は、ぜひ2022jig.jp冬インターンシップにご応募ください！

この記事が気に入ったらサポートをしてみませんか？