承認 / 承認を得る: その意味、Gitにおける承認とコードレビュー

pull request承認とは

承認は、pull requestに対する良好なレビューであり、レビュアーがコードをチェックし、危重な問題がないことを確認し、変更がマージの準備ができているとみなすことを意味します。GitHubのインターフェースでは、これはPRページの緑色の«Approve»ボタンです。承認後、著者（または書き込み権限を持つメンバー）がマージを実行できます。

承認プロセスはBranch Protection Rulesの一部です。リポジトリの所有者は必須要件を設定します: 最小承認数（例えば1または2）、承認できる人（コード所有者、チームメンバー）、および変更後にPRを再承認する必要があるか（Dismiss stale reviews）。ルール設定なしでは承認はオプションですが、プロのチームでは必須です。

GitLabはApproval Rulesと呼ばれる同様の仕組みを使用します。GitLabでは、異なるグループからの必要承認数を設定できます（例えば、バックエンド開発者から2つ、DevOpsから1つ）。すべての必須承認を受けた後、CI/CDパイプラインが緑であれば、PRはマージのために自動的にアンロックされます。

レビューの種類: Approve, Request Changes, Comment

GitHubとGitLabには、レビュアーがpull requestに残すことができる3つのレビュータイプがあります。各タイプには異なるステータスとマージプロセスへの影響があります。Approveは緑、Request Changesは赤、Commentは中性の灰色です。選択はコードの品質と変更の受け入れ準備によります。

Approve — レビュアーが確認: コードは正しく書かれており、基準を満たし、明らかなエラーがなく、マージできます。Approveはコードが完璧であることを意味しません — ただプロダクションに十分なクオリティであるというだけです。小さなコメント（スタイル、名前付け）がある場合は、PRをブロックせずにコメントとして残すことができます。

Request Changes — レビュアーが、マージ前に修正すべき問題を発見: 論理エラー、脆弱性、アーキテクチャ違反、テスト不足。Request Changes後、PRはブロックされ、同じレビュアーによる再承認が必要です（新しいコミットでDismiss stale reviewsが有効な場合）。

• Approve — コードはマージ準備完了、CIクリア後にマージ可能。
• Request Changes — 必須修正があり、再レビューまでPRはブロック。
• Comment — PRをブロックせずに一般的な指摘または提案。

リポジトリでの承認ルール設定

Branch Protection Rulesは、マージの品質を制御するGitHubの仕組みです。保護されたブランチ（main、develop、release/*）ごとにSettings → Branchesで設定します。主なパラメータ: 必須承認数、コード所有者（CODEOWNERS）、必須CI/CDチェック、およびPRなしのpushの禁止。

Dismiss stale pull request approvalsパラメータは、PRに新しいコミットが追加された場合に自動的に承認を外します。これにより、レビュアーがマージされるコードのバージョンを承認することが保証されます。この設定がなければ、著者は承認後に新しいコードを追加し、再チェックなしでmainに入ってしまう可能性があります。

CODEOWNERS — リポジトリのルートにあるファイルで、異なるディレクトリの責任者を指定します。PRがコード所有者のファイルに影響する場合、その承認が必須になります。CODEOWNERSにより責任範囲を分散できます: iOS開発者はSwiftファイル、DevOpsはDocker設定、テスターはテストシナリオを担当します。

# リポジトリルートのCODEOWNERSファイル例

# iOS開発者がSwiftコードを所有
*.swift @team/ios-developers

# DevOpsがCI/CD設定を所有
.github/workflows/* @devops-team

# QAエンジニアがテストをレビュー
**/tests/* @qa-engineers

# その他全てのデフォルト所有者
* @tech-leads

承認前のコードレビュー: 確認事項

承認前のコードレビューは、システマティックなコードチェックであり、diffをちらっと見るだけではありません。質の高いコードレビューには、アーキテクチャ、論理、スタイル、テスト、セキュリティのチェックが含まれます。このチェックがなければ、承認は品質管理ツールではなく、形式となってしまいます。

まず確認すること: 変更の論理 — コードは任務を解決しているか、副作用はないか、エッジケースの処理は正しいか。テスト — 新しいテストはすべてのシナリオをカバーしているか、既存のテストは変更後もパスするか。セキュリティ — SQLインジェクション、XSS、機密データの漏えいがないか。

レビューの対象としてはならないべきもの: フォーマッティングスタイル（そのためのlinterやformatterがあります）、事前に決定されたアーキテクチャ決定（コードを書く前に話合いされます）。レビューが400行を超えたり、1時間を超えたりする場合、それは任務が大きすぎて分解が必要であることを示しています。最良のレビュー実践 — PR作成後24時間以内の200〜400行のポーション。

• 論理 — 解決の正確さ、エラー処理、エッジケース。
• テスト — 新しいシナリオのカバレッジ、既存テストのパス、flakyテストの無さ。
• セキュリティ — インジェクションの無さ、出力のエスケープ、データアクセス制御。
• パフォーマンス — アルゴリズムの効率、過剰なクエリ、メモリリーク。
• ドキュメンテーション — ドキュメントは更新されているか、複雑な部分のコメントは明確か。

チームでの承認ワークフロー

5〜10人の開発者からなるチームでの典型的な承認ワークフローは次のようになります: 開発者がPRを作成し、レビュアーを指定し（通常はチームから1〜2名またはコード所有者）、CI/CDが自動チェックを実行します。すべての必須承認と緑色CIを受けた後、著者がマージを実行します。PR作成からマージまでの時間は、複雑さにより2時間から2日程度です。

GitHub Actionsは、承認後のマージを自動化することができます。ブランチルールが設定されていれば、すべての条件が満たされるまでGitHubが自動的にマージをブロックします。いくつかのチームはbors-ngやMergifyを使用しています — これらのボットは、すべての承認を受け、CIがパスした後に自動的にPRをマージします。これによりプロセスが効率化され、マージにおける人的要因が除去されます。

現代的なアプローチはtrunk-based developmentで、短期のブランチを使用します。このワークフローでは、数時間以内に承認を得る必要があり、それ以外は任務が古くなり、mainとの再同期が必要となります。レビュー文化の高いチームは、承認までの時間を労働4時間以内にすることを目指しています。

承認のミスとその回避法

もっとも多いミスは、実際のコードチェックなしの形式的な承認です。PRが大きいか期限が迫っている場合、レビュアーは変更を調べずにApproveを押すことがあります。これにより、コードレビュープロセス全体が貧値化します。解決策: PRサイズの制限を設ける（400行以下）、およびコード解析ツール（SonarQube、CodeClimate）を使用して自動チェックを行う。

2つ目のミスは、過度に厳しい承認です。完璧なコードを期待すると開発がブロックされます。レビュアーが品質に影響しないスタイル上のコメントを修正するよう要求することがあります。解決策: 必須コメント（ブロッキング）とオプショナル提案（コメント）を明確に区別する。GitHubでは、コメントがブロッキングかどうかを明確に指定できます。

3つ目のミスは、CI/CDを確認せずに承認することです。コードが正しく見えても、コンパイルできなかったり、テストに失敗したりする可能性があります。設定されたBranch Protectionは赤色CIで自動的にマージをブロックしますが、いくつかのチームは速さを優先してこの保護を無効にしています。解決策: 承認前に常にCIステータスを確認し、赤色パイプラインのPRを承認しない。

• 形式的な承認 — 実際のコードチェックの缺如。解決策: PRを400行に制限。
• 過度の厳しさ — スタイル上のコメントによるブロック。解決策: blockingとoptionalに区分。
• CIの無視 — 赤色パイプラインでの承認。解決策: 常にテストステータスを確認。
• 著者の指定 — PR著者による承認。解決策: Branch Protectionを著者に対して設定。