レビュアー、レビュイーのだれがマージするかを追記

documents/forGitBranch/git_branch_standards.md

@@ -291,6 +291,24 @@ featureブランチでの作業中に、developブランチが更新された場
 
 [^2]: https://docs.github.com/ja/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
 
+### マージはだれが行うべきか
+
+プリリクエストの承認（Approve）をもらった後、マージはレビュアー／レビュイーのどちらが行うべきか議論になる場合がある。
+
+| 観点    | レビュアー派                                   | レビュイー派閥                                        |
+|-------|------------------------------------------|------------------------------------------------|
+| 説明    | 開発者の責務が、developブランチにマージするまでという役割分担の場合に有効 | 各開発者がその機能のリリースについて責任を負うモデルの場合に有効               |
+| 生産性   | ⚠️レビュアーがブロッキングになりがち                      | ✅️高い。コメントはあるがApproveしたので、適時対応してマージして、といった運用が可能 |
+| 統制    | ✅️レビュアーが管理しやすい                           | ✅️メンバーの自主性に依存                                  |
+| 要求スキル | ✅️低い。中央で統制を書けやすい                         | ⚠️開発メンバーの練度が求められる                              |
+
+上記にあるように、そのプルリクエストで実装した機能を、本番環境にデリバリーする責務をどちらに持たせるかという観点で、意思決定することが多い。
+
+本規約の推奨は以下。
+
+* プロダクトオーナー（業務側）などでリリースタイミングを完全にコントロールしたいといった分業制を取る場合は、レビュアーがマージする
+* 各開発者により自律性を持たせ、アジャイル的に生産性を重視するのであれば、レビュイーがマージする
+
 ## 3. 永続ブランチ間で変更を取り込む
 
 永続ブランチ同士の変更を取り込むケースとして、`develop` ブランチを `main` ブランチや `release`ブランチにマージするといった場合がある。