#7 CODEOWNERSで自動レビュー割り当て - Python OSS開発記録
karrinn
著者
ブランチ保護と命名規則で「うっかりミス」を防いだ、次は？「誰がレビューすればいいの？」を自動化します。
今回はCODEOWNERSを使って、特定のファイルを変更したら自動的にレビュアーをアサインする仕組みを実装します。
KEY TAKEAWAYS
この記事でわかること
- CODEOWNERSファイルで特定のファイル・ディレクトリのオーナーを定義
- 自動レビュー割り当てでレビュー漏れを防ぐ
- 責任の明確化で「誰に聞けばいいか」が分かる
用語の定義
TERM 01
CODEOWNERS
特定のファイル・ディレクトリのオーナー（責任者）を定義するファイル。PRが作成されると、変更されたファイルのオーナーが自動的にレビュアーにアサインされる。
TERM 02
Code Owner
コードオーナー。特定のコードに対して責任を持つ人。レビュー権限だけでなく、「このコードについて質問があったら誰に聞くか」を明確にする役割もある。
TERM 03
Auto Assignment
自動割り当て。PRが作成されると、変更されたファイルに基づいて自動的にレビュアーがアサインされる仕組み。
TERM 04
Required Review
必須レビュー。Topic #5で設定したRulesetsの「Require code owner review」により、CODEOWNERSに指定された人の承認が必須になる。
なぜCODEOWNERSが必要？
wagtail-reusable-blocks では、Topic #5でRulesetsを設定し、「PR必須」「承認者1人必要」を強制しました。
でも、「誰にレビューを頼めばいいの？」という問題が残っています。
問題1
PRを作ったけど、誰にレビューを頼めばいいか分からない
問題2
レビュアーを指定し忘れて、PRが放置される
問題3
「このコードについて質問があるけど、誰に聞けば？」
解決策: CODEOWNERSでファイルごとにオーナーを定義すれば、自動的にレビュアーがアサインされます。
Topic #5で設定した「Require code owner review」と組み合わせれば、CODEOWNERSに指定された人の承認が必須になります。
CODEOWNERSファイルの実装
CODEOWNERSファイルの配置場所
CODEOWNERSファイルは、以下のいずれかの場所に配置します。
配置場所（優先順位順）
.github/CODEOWNERS← wagtail-reusable-blocksはこれCODEOWNERS（リポジトリルート）docs/CODEOWNERS
推奨:.github/CODEOWNERS に配置するのが一般的です。
GitHub関連の設定ファイルをまとめて管理できます。
# CODEOWNERSファイルを作成 mkdir -p .github touch .github/CODEOWNERS # ファイル構成 . ├── .github/ │ ├── CODEOWNERS ← ここ │ ├── ISSUE_TEMPLATE/ │ ├── PULL_REQUEST_TEMPLATE.md │ └── workflows/ ├── src/ ├── docs/ └── README.md
CODEOWNERSの書き方
基本構文
構文ルール
- パターン + ユーザー名の形式で記述
#でコメント- 最後にマッチしたルールが優先される
- ユーザー名は
@username形式
パターンの種類
*: すべてのファイル（デフォルトオーナー）/src/: 特定のディレクトリ*.js: 特定の拡張子README.md: 特定のファイル
重要:
下に書いたルールほど優先されます。
一般的なルールを上に、具体的なルールを下に書きましょう。
# CODEOWNERS - Define code ownership # https://docs.github.com/en/repositories/... # デフォルトオーナー（すべてのファイル） * @kkm-horikawa # コアソースコード /src/ @kkm-horikawa # ドキュメント /docs/ @kkm-horikawa README.md @kkm-horikawa CONTRIBUTING.md @kkm-horikawa # 設定ファイル pyproject.toml @kkm-horikawa .github/ @kkm-horikawa
wagtail-reusable-blocksの実際のCODEOWNERSファイルです。
すべてのファイルのオーナーは @kkm-horikawa（筆者）です。
ブランチ保護との連携: コードオーナーのレビューを必須化
「Require review from Code Owners」設定
CODEOWNERSファイルを作成するだけでは、レビュアーが自動でアサインされるだけです。
コードオーナーの承認を必須にするには、GitHubのブランチ保護設定が必要です。
設定方法（GitHub Rulesets）
- リポジトリ → Settings → Rules → Rulesets
- 対象のRulesetを選択（または新規作成）
- 「Require a pull request before merging」を有効化
- 「Require review from Code Owners」にチェック
Topic #5との連携: wagtail-reusable-blocksでは、Topic #5のRulesets設定で既にこの設定を有効化しています。
この設定で何が変わる？
| 状態 | CODEOWNERSのみ | + ブランチ保護 |
|---|---|---|
| レビュアー自動アサイン | ||
| コードオーナーの承認 | 任意 | 必須 |
| マージ可否 | 誰でも承認OK | オーナーの承認必須 |
注意:
この設定を有効にすると、CODEOWNERSに定義されたユーザー/チームの最低1人からの承認がないとマージできなくなります。
複数のファイルを変更した場合、それぞれのコードオーナー全員からの承認が必要です。
自動レビュー割り当ての仕組み
どう動くのか
Step 1: PRが作成される
開発者が feature/add-new-block ブランチから develop へPRを作成します。
Step 2: 変更されたファイルを確認
GitHubが、このPRで変更されたファイルを確認します。
src/blocks/reusable_block.py← 変更ありREADME.md← 変更あり
Step 3: CODEOWNERSでオーナーを検索
CODEOWNERSファイルを見て、変更されたファイルのオーナーを探します。
src/blocks/reusable_block.py→/src/にマッチ →@kkm-horikawaREADME.md→README.mdにマッチ →@kkm-horikawa
Step 4: 自動的にレビュアーをアサイン
オーナーが自動的にレビュアーとしてアサインされます。
これで実現できること
- レビュー漏れ防止: レビュアーを指定し忘れても、自動でアサインされる
- 適切な人にレビュー依頼: そのファイルに詳しい人が自動で選ばれる
- 責任の明確化: 「このファイルは誰の担当か」が明確
OSS vs 企業プロジェクト: CODEOWNERSの意味
OSS: メンテナーの負担軽減とコントリビューターの安心
OSSプロジェクトでは、初めてPRを送る人がたくさんいます。
「誰にレビューを頼めばいいの？」と迷うことも多い。
CODEOWNERSがあれば、自動的にレビュアーがアサインされるので、迷う必要がありません。
メンテナー側も、「このPR、レビュアーが誰もいない...」という事態を防げます。
メリット
- コントリビューター: レビュアーを誰にすればいいか悩まなくていい
- メンテナー: レビュー漏れを防げる、自動的にアサインされる
- プロジェクト全体: 「このコードは誰が詳しいか」が明確になる
初心者に優しい:
「このPR、誰にレビューしてもらえばいいんだろう...？」と不安にならない。
システムが自動で適切な人を選んでくれるので、安心してPRを送れます。
重要な制限: 無料プランのプライベートリポジトリでは使えません
CODEOWNERSは無料プランのプライベートリポジトリでは使えません。
プライベートリポジトリで使うには、GitHub Pro（個人）またはGitHub Team（組織）以上の有料プランが必要です。
パブリックリポジトリなら無料プランでも使えます。
企業: 「誰に聞けばいいか分からない」問題の解決
Topic #4〜#6で触れた「萎縮による開発効率の激減」問題は、レビュー依頼でも起こります。
新入社員や異動者が「誰にレビューを頼めばいいの？」と悩むのは、不安だからです。
「間違った人に頼んだら怒られる」「誰が詳しいか分からない」という恐怖が、質問を生みます。
従来の問題: 不安と質問の嵐
- 「このファイル、誰が詳しいんですか？」 ← 毎回質問
- 新人は萎縮: 「間違った人に頼んだら怒られるのでは？」と不安になる
- レビュー依頼し忘れ: 誰に頼めばいいか分からず、結局放置
- 教える側も消耗: 「このファイルは○○さんに聞いて」と何度も説明
- 開発効率が下がる: 質問と確認に時間を取られる
CODEOWNERSによる解決: システムで自動化
システムでちゃんと設定してあげれば、誰に頼むか悩まなくていい。
- 自動的にレビュアーがアサイン: 適切な人が自動で選ばれる
- 「えい」ってPRを作ることができる: 誰に頼むか悩まなくていい
- 質問が不要: 「誰が詳しいですか？」と聞かなくていい
- レビュー漏れ防止: レビュアーを指定し忘れても大丈夫
- 心理的安全性: 「間違った人に頼んだらどうしよう」と不安にならない
安心して失敗できる環境:
これは教育の本質です（私が教育機関で働いていた経験から）。
「誰にレビューを頼めばいいか」を覚えられなくても大丈夫。システムが自動で選んでくれる。
具体例: レビュー依頼
従来（人間に任せる）:
- 新人: 「このPR、誰にレビューしてもらえばいいんだろう...？先輩に聞かなきゃ...」（不安）
- 先輩: 「このファイルは○○さんに頼んで」（説明）
- 新人: 「次もまた聞かないと...」（萎縮）
- 結果: 毎回確認しないと怖い。開発効率が下がる。
CODEOWNERS（システムによる自動化）:
- 新人: 「PRを作ろう」（試す）
- GitHub: 「自動的に○○さんをレビュアーにアサインしました」（システムが自動処理）
- 新人: 「なるほど、このファイルは○○さんが担当なんだ」（学習）
- 結果: 悩まずにPRを作れる。経験値が溜まる。
プロジェクト管理の責任
効果的なプロジェクト管理には、システムやツールに対する理解が重要です。
技術的な背景を持つマネージャーは、以下のような利点があります：
システムを活用した予防: ツールや自動化で問題を未然に防げる
効果的な意思決定: 技術的な制約や可能性を理解した上で判断できる
円滑なコミュニケーション: チームメンバーとの技術的な対話がスムーズになる
重要:
CODEOWNERSファイルを作るのは「面倒」に感じるかもしれません。
しかし、新規参画者の目線に立てば、これは最大の親切です。
「誰に頼めばいいか」を毎回質問させるより、システムで自動化する方が、遥かに生産的です。
よくある質問と回答
FAQ
Q1: 無料プランのプライベートリポジトリで使える？
A:使えません。
プライベートリポジトリでCODEOWNERSを使うには、GitHub Pro以上の有料プランが必要です。
パブリックリポジトリなら無料プランでも使えます。
Q2: ソロ開発でもCODEOWNERSは必要？
A: ソロ開発なら不要です。
ただし、将来コントリビューターを受け入れる予定があるなら、最初から設定しておくと良いでしょう。
Q3: 複数人をオーナーにできる？
A: できます。/src/ @user1 @user2 のように、スペース区切りで複数指定可能。
全員がレビュアーにアサインされます。
Q4: チームをオーナーにできる？
A: できます（Organizationの場合）。/src/ @org-name/team-name のように指定。
チームメンバー全員がレビュアーにアサインされます。
Q5: CODEOWNERSファイルが反映されない？
A: 以下を確認してください：
① プライベートリポジトリの場合、有料プランか？
② .github/CODEOWNERS に配置されているか
③ ユーザー名が正しいか（@username形式）
Q6: 企業の非公開プロジェクトで使いたい場合は？
A:GitHub
Team（組織向け有料プラン）が必要です。
個人ならGitHub Pro、組織ならGitHub Team以上のプランに加入してください。
まだコメントはありません。最初のコメントを残しませんか？