品質チェックポイント

ポリシーが何を通過可能かを決定し、ゲートがタスクを停止できる箇所を説明します。

A品質ゲート品質ゲートとは、作業が次のステップに進む前に通過しなければならないチェックです。ゲートを設けることで、「出荷可能な水準」という判断が主観的なものではなく、システムが毎回同じように強制するルールへと変わります。

ブロッキングとアドバイザリー

すべてのゲートはこのいずれかであり、その違いこそが設計の核心です。

まずはアドバイザリーとして設定しましょう。実際の作業でゲートが何を検知するかを1〜2週間観察し、条件を満たしたものをブロッキングに昇格させてください。初期段階で何も調整せずにブロッキングを設定すると、ほとんどの場合、開発者がそれを回避する方法を編み出してしまいます。

検出される事象は同じです。ポリシーによってその影響が決まります。ブロッキングゲートはタスクを停止させ、アドバイザリーゲートは事象を記録して作業を続行させます。

ゲートは検証ステージの上に位置し、以下の項目をカバーできます：

最も有用なゲートはほとんどの場合、既存のテストスイートです。なぜなら、チームが重要と判断した事項がすでに反映されているからです。

ゲートは検証中に実行され、開発エージェントの作業が終了した後、レビュー前に適用されます。ブロッキングで失敗すると、作業は再実行対象として戻され、却下されるだけのpull requestが生成されるのを防ぎます。

この順序は意図的なものです。実行中に失敗する方が、画面で失敗するよりもコストが低いからです。

ゲートは「ポリシー」にグループ化されますポリシー、これが実際にプロジェクトに適用されるものです。ポリシーとは、ブロッキング／アドバイザリーの設定を含むゲートの名付けられた集合であり、本番サービス向けの標準ポリシーや内部ツール向けの簡易ポリシーを設定できます。

ポリシーにはバージョン管理がされています。変更を公開した後、新しいゲートが厳しすぎると判断された場合には、以前のバージョンにロールバックできます。

ブロッキングゲートは、権限を持つ人間が上書き承認できます。その履歴（誰が、いつ、何に対して行ったか）は記録されます。

この記録こそが重要なのです。上書き承認が不可能なゲートは回避手段が生まれ、誰でも簡単に上書きできるゲートはゲートとは言えません。履歴が残る上書き承認であれば、実用性と説明責任を両立できます。

ゲートは属性をチェックします。作業が正しい問題を解決しているかどうかは判断しません。それは仕様に定められた受入基準や、レビューの役割です。

すべてのゲートを通過しても、間違った変更である可能性があります。