はじめに

「PR出したけど、誰がレビューしてくれるんだろう…？」
「詳しくない箇所の変更だから、自分から名乗り出るのは怖いな…」

開発チームにおいて、このような 「レビュアー決定までの様子見」 が発生していませんか？

私のチームでは元々、以下のようなフローで運用していました。

実装完了後、Slackで「レビューお願いします」と全員に向けて投げる
対応できそうなエンジニアが「👀」のリアクションをつけて意思表明する
レビュー実施

しかし、この「挙手制」には明確な課題がありました。

心理的ハードル：
全く知らない箇所の修正だと、レビュアーとして名乗り出るのを躊躇してしまう
様子見の発生：
「誰か詳しい人がやるかも…」とお互いに様子を見てしまい、着手スピードが落ちる
負荷の偏り：
結局、いつも同じ人が拾うことになりがち

解決方針：強制アサイン＋運用でのカバー

そこで、「いっそシステム側でランダムに自動アサインしてしまおう」 という方針に切り替えました。

自動化：
GitHubの機能を使ってレビュアーをランダム選出
通知：
Slackへメンション付きで通知を飛ばす
運用（重要）：
もし割り振られた人が忙しかったり対応できない場合は、その時点でコミュニケーションをとって交代する

「誰がやるか？」の悩み時間をゼロにしつつ、どうしても無理な場合だけ人間が調整するスタイルを目指しました。

本記事では、GitHub Actionsを使わずに、GitHub標準機能（CODEOWNERS + Teams）とSlack連携でこれを実現する方法を紹介します。

1. OrganizationにTeamを作成する

特定のメンバーの中からランダムにレビュアーを設定するには、個人指定ではなく「チーム」を作成する必要があります。

GitHubの画面右上アイコンメニューから Organizations を選択
対象のリポジトリが所属するOrganizationを選択
上部の Teams タブを開く
「New team」をクリックし、チームを作成（例: backend-reviewers 等）
- ※Team notificationsは Enabled にしておくのがおすすめです
作成したチームの「Members」タブから、レビュアー対象となるメンバーを追加

チーム内の自動アサイン設定

チームを作っただけでは自動アサインされません。チーム設定でコードレビューの「auto assignment」を有効にします。

作成したチームのページ上部 Settings タブを開く
左側メニューから Code review を選択
以下の通り設定を行います

設定項目	推奨設定	説明
Enable auto assignment	チェックを入れる	最重要項目です。これで自動アサインが有効になります。
Only notify requested team members	チェックを入れる	チーム全員ではなく、アサインされた人だけに通知します（ノイズ削減）。
How many team members...?	`1`〜`2`	アサインする人数を指定します。
Routing algorithm	`Round robin` or `Load balance`	Round robin: 順番に割り当て（公平性重視） Load balance: 現在の担当PR数が少ない人を優先（スピード重視）
Child team members	チェックを外す	子チームのメンバーもアサイン対象に含めるかどうかの設定。意図しないメンバーが含まれるのを防ぐため、基本はチェックを外します。
Count existing requests	チェックを入れる	手動指名されている場合も、割り当てカウントに含めます。
Team review request	チェックを入れる	推奨。個人のアサイン完了後、チームへのリクエストを取り下げます。「誰かがやるだろう」という傍観者効果を防ぐために有効です。

最後に「Save changes」をクリックして保存します。

2. リポジトリの書き込み権限をチームに付与する

チームを作成しただけでは、まだリポジトリに対して権限がなく、CODEOWNERSが機能しない場合があります。

対象リポジトリの Settings を開く
左側メニュー Collaborators and teams（または Collaborators）を選択
Add teams をクリックし、先ほど作成したチームを追加
Role（権限）を「Write」以上に設定する（重要！）

なぜWrite権限が必要なのか？
GitHubの仕様上、CODEOWNERSファイルで指定されたユーザー（またはチーム）がリポジトリへの書き込み権限（Write）を持っていない場合、そのルールは無視されます。

通常のレビュアー招待であればRead権限でも可能ですが、CODEOWNERSによる自動アサイン機能を利用する場合はWrite権限が必須となるため注意してください。

参考：コードオーナーについて

3. CODEOWNERSファイルを作成する

いよいよ、PR作成時にチームを呼び出す設定ファイルを作成します。
リポジトリのルート直下に .github ディレクトリを作成し、その中に CODEOWNERS ファイルを配置します。

ディレクトリ構成:

📂 root
 ┗ 📂 .github
    ┗ 📄 CODEOWNERS

CODEOWNERSの内容:

# 全てのファイルに対してチームをアサインする
* @organization-name/team-name

注意点:

チーム名は @Organization名/チーム名 の形式で記述します
親チームの下にある子チームであっても、パス形式ではなく単独のチーム名として記述します

動作確認の注意点（重要）

CODEOWNERSの設定は、ファイルを追加したPRがデフォルトブランチ（main/master）にマージされた後に有効になります。

まず、CODEOWNERSファイルを追加するPRを作成し、マージする。
その後、新しくブランチを切ってPRを作成する。
PR作成時（Open時）に、右サイドバーの Reviewers 欄に、チームメンバーが自動的にセットされていればOKです！

※ Draft PR の場合、作成時点ではアサインされません。「Ready for review」にしたタイミングでアサインが走ります。

4. PR作成時にSlackへ通知する

自動アサインされても、GitHubを見ていないと気づきません。Slackへ通知を飛ばして気づきやすくします。

GitHubアプリの導入

Slackのワークスペースに「GitHubアプリ」をインストールします（公式リンク）。
Slack上で以下のコマンドを実行し、GitHubアカウントと連携します。

/github signin

※レビュアー対象となるメンバー全員がこれを行っておくと、GitHub上のメンションがSlackのメンションに変換され、通知に気づきやすくなります。

リポジトリの購読（Subscribe）

通知を受け取りたいSlackチャンネルで、以下のコマンドを実行します。

/github subscribe <organization-name>/<repository-name> pulls,reviews

pulls: PRの作成・マージなどの通知
reviews: レビュー依頼やコメントなどの通知

ポイント: reviews だけだとPR作成時の通知が来ない場合があるため、pulls も含めておくのがおすすめです。

この状態で再度PRを作成し、以下のようにSlackに通知が届けばOK！

【Tips】メンションが飛ばない場合の回避策

基本的には /github signin していれば通知は届きますが、環境によってはうまくメンション変換されないケースがあります。
その場合、Slackの 「環境設定 > 通知 > チャンネルのキーワード」 に、自分のGitHubユーザー名 を登録しておきましょう。

こうすることで、変換漏れがあってもSlack側がキーワードを検知してハイライトしてくれるため、見落としを防ぐことができます。

導入効果のまとめ

今回の仕組みを導入したことで、課題だった 「レビュアーの偏り」 と 「着手までのリードタイム」 が以下のように改善されました。

項目	導入前（Before）	導入後（After）
レビュアー選定	「誰かやってくれないかな...」という挙手制・様子見	システムによる強制・自動アサイン
負荷の偏り	特定の詳しい人に集中（属人化）	チーム内で公平に分散
心理的ハードル	知らない箇所のレビューに名乗り出るのが怖い	「割り振られたからやる（無理なら聞く）」と割り切れる
通知・気づき	Slackの全体チャンネルに埋もれがち	メンション通知により自分事として即座に気づく
スピード	誰かが反応するまで待機時間が発生	PR作成と同時にレビュー依頼が完了

おわりに

自動アサインによって、タイミング悪く忙しい時や、自分の苦手な領域のレビューが回ってくることもあります。そんな時に「仕組みだから、なんとしても一人で頑張らなきゃ...」と抱え込まないようにしましょう。

もし対応が厳しい時は、Slackで「今手一杯なので代わってくれませんか？」と声をかけ合うなど、無駄なことは仕組み化しつつ、本質的な部分で協力し合えるチーム作りができると良いですね。