reviewer-assignment｜適切なレビュー担当者の選定と運用設計

概要

reviewer-assignment（レビューアーの割り当て）は、レビューの品質とスピードを左右する重要な設計事項です。
「誰が見るか」によって、見落とし・指摘の精度・レビューの信頼性が大きく変わります。

レビュープロセスは人選から始まります。割り当て設計は運用のコアです。

基準	内容
ドメイン知識	その機能に詳しい人／同じモジュールを担当している人
設計責任者	元設計者、仕様策定者など
育成目的	初学者・ジュニアメンバーに意図的にレビュー機会を与える
負荷分散	レビュー集中を防ぎ、1人に偏らないようローテーション管理
レビュー文化	あえて別プロジェクトの人を交えて「他視点レビュー」化する例もあり

「実装の背景が分かる人」と「コードの構造に強い人」を分けると、多面的レビューが可能になります。

# frontend配下のファイルは @frontend-team がレビュー
/frontend/  @frontend-team

### レビュアー
- [ ] @team-lead
- [ ] @feature-owner

レビュー担当ローテーション表（週次）
今週: 田中、来週: 鈴木、その次: 張

Author: このPR、設計を決めた◯◯さんに見てほしいです。
ReviewerA: 今ちょっと立て込んでるので、先に◯◯さんが初回見てもらえると助かります。

Author: あえて別の視点でのレビューがほしいので、◯◯さんにも依頼します。
ReviewerB: 了解です。新鮮な視点でチェックします。

リスク	対策例
担当者がいつも同じ	レビュアーのローテーションや週次交代制を導入する
特定の人しか理解できないモジュール	ドメイン知識を共有するドキュメントを整備する
必要な人にレビューが届いていない	PRテンプレートやBotでレビュアーの確認を必須化する

「レビューの質が低い」の背景には、「レビュー担当が適切でなかった」という根本的な配役ミスがあることも多いです。

reviewer-assignmentは「コードを見る」だけでなく、「誰が品質保証の役を担うか」を設計する行為です。
レビュープロセスの信頼性はこの割り当て次第で決まります。チームでルールを持ち、透明性と納得感のある運用を構築しましょう。