Blocking（ブロッキング）とは

意味と文脈上の位置づけ

Blocking（ブロッキング）とは、コードレビューにおいて「この指摘が解消されない限り、Pull Request（PR）はマージしてはならない」とされる重大な指摘を意味する表現です。

この言葉はGitHubの公式レビューオプションには存在しませんが、現場でのコメントやレビューツール（例：Gerrit、Phabricator）などではレビューの優先度・強度を示すラベルとして頻繁に用いられます。

blocking: 仕様を満たしていないため、修正が必要です。

使用される場面と意図

• 明確な仕様違反（例：必須項目のバリデーション漏れ）
• ロジックミス（例：負数の扱いでクラッシュ）
• 保守不能な構造（例：密結合のままリリース）

これらの問題が放置されたままマージされると、ユーザー影響・バグ発生・設計崩壊など重大なリスクを引き起こす可能性があります。

そのため、Blockingコメントは強い修正要求として扱われ、Approveの条件からも外されるのが一般的です。

実務での使われ方と会話例

ケース：APIのバージョン指定忘れ

Reviewer:
  blocking: APIのversion指定がありません。
  このままだと互換性が壊れた時に後方影響が出ます。

ケース：ユースケース不一致

Reviewer:
  blocking: 本件、ビジネス仕様として「キャンセル不可」の扱いが求められています。
  UI変更と連携しないと誤解を招くリスクがあります。

SlackやPRコメントの例

• この修正、blocking出しておきます。
• 指摘2件ありますが、どちらもblockingではないです。

注意すべき点と誤解の防止策

⚠ Blockingが乱用されるとレビューが硬直化する

• 担当者が萎縮して修正をためらう
• 小さな設計差異や好みの問題までblockingにされる

対策

• Blockingコメントには根拠（仕様・バグ・保守性）を明示
• チーム内で「Blocking基準」を共有・文書化する
• 指摘が「意見」レベルなら non-blocking と明記する運用を取り入れる

よくある関連用語との違い

結論

• Blockingは「このままマージすべきでない」という明確な修正要請
• 使うときは理由を具体的に書くことで信頼性が増す
• チーム文化として「Blockingの意味と基準」を共有しておくと、レビューが円滑になる

関連用語

• Must
• Non-blocking
• Request Changes