品質ゲート定義書のテンプレート
品質ゲートとは、工程の切れ目に置く「通過条件」のことです。条件を満たすまで次の工程に進ませません。考え方は単純ですが、運用に乗せるには2つの準備が要ります。条件を数字で書くことと、止まることを見込んで計画することです。
このページでは、品質ゲート定義書のテンプレートと、判定の進め方、記入例をまとめます。記入例は、事例集の「ノヴァモバイル（架空）の料金計算・請求システム刷新」に当てはめたものです。
■ この帳票が要る場面（背景・よくある課題）
よくある症状 | 本当の原因 |
|---|---|
受入テストで大量の手戻りが出る | 前の工程で確かめるべきことを、確かめずに通していた |
「設計完了」と報告されたが、未確定が残っていた | 完了の判定基準がなく、その場の空気で通っていた |
レビューをしているが、効果が感じられない | 指摘の未クローズがあっても次に進んでいる |
ゲートを作ったが、毎回「特例で通過」になる | 止まる余地のない計画にゲートを置いた |
条件を書いたが、判定で揉める | 条件が「品質が十分であること」のような文章になっている |
■ このテンプレートの目的
不具合を見つける場所を、前の工程へ動かす：下流で見つかるほど、直す費用と期間が大きくなります
完了の判定を、人によってぶれない形にする：条件を数字か○×で書きます
止まることを織り込んだ計画にする：ゲートの後ろにバッファを置きます
大事な前提を1つ。品質ゲートは、不具合を減らす道具ではありません。同じ数の不具合を、より前の工程で見つけるための道具です。総件数はあまり変わりません。変わるのは、どこで見つけるかです。
■ テンプレートの全体像
部品 | 形式 | 役割 |
|---|---|---|
① ゲート定義表 | 表（行＝ゲート） | どこに、いつ、どんな条件のゲートを置くか |
② 判定シート | 表（ゲートごとに1枚） | 条件を1つずつ○×で埋め、判定の記録を残す |
③ 判定履歴 | 表 | 通過／条件付き通過／差し戻しの記録と、遅れの日数 |
■ 各項目の説明
① ゲート定義表の列
列 | 何を書くか | 書き方のコツ |
|---|---|---|
ゲートID | G0、G1… | 工程の出口ごとに1つ |
置く場所 | どの工程の出口か | 要件定義・基本設計・単体テスト・結合テスト・総合テストの出口が基本 |
予定日 | 判定を行う日 | 工程の完了予定日と同じ日にする |
通過条件 | 数字か○×で答えられる条件 | 3〜4個まで。「未解決0件」「計算例72件すべて一致」のように |
判定者 | 誰が判定するか | 会議体で判定する。個人にすると押し切られます |
バッファ | ゲートの後ろに置く日数 | 1ゲートあたり3〜5営業日。ここが計画の余裕になります |
差し戻し時の再判定 | 何営業日以内に再判定するか | 原則5営業日以内 |
通過条件の書き方が、この定義書のすべてです。次の3つの型に当てはめると書きやすくなります。
型 | 形 | 例 |
|---|---|---|
ゼロ型 | 「〜が0件」 | レビュー指摘の未クローズ0件／項目定義の「未定」0件 |
下限型 | 「〜が○以上」 | 単体テストケース密度20ケース/KStep以上／不具合密度1.00件/KStep以上 |
全件一致型 | 「〜がすべて一致・すべて済み」 | 計算例72件すべて検算済み／期待値の記入率100% |
下限型に注意してください。「不具合密度1.00件/KStep以上」は、少なすぎたら疑うための条件です。結合テストで不具合が出ないのは、品質が良いからではなく、テストが甘いからであることが多いためです。
■ 記入例：ノヴァモバイル 料金計算・請求システム
14か月・96KStepのプロジェクトです。前回の案件で受入テストの手戻りに苦しんだ反省から、5つのゲートを設計しました。
ID | 置く場所 | 予定日 | 通過条件 | 判定者 | バッファ |
|---|---|---|---|---|---|
G0 | 要件定義の出口 | 2024/11/29 | ① 業務シナリオ186本すべてに、受入テストのケース番号が紐づいている | 部長級の会議体 | 5営業日 |
G1 | 基本設計の出口 | 2025/2/28 | ① 料金計算の計算例 24プラン×3パターン＝72件すべて手計算で検算済み | 部長級の会議体 | 5営業日 |
G2 | 単体テストの出口 | 2025/6/20 | ① 単体テストケース密度が全サブシステムで20ケース/KStep以上 | 部長級の会議体 | 5営業日 |
G3 | 結合テストの出口 | 2025/8/22 | ① 不具合密度が1.00件/KStep以上 | 部長級の会議体 | 5営業日 |
G4 | 総合テストの出口 | 2025/10/3 | ① 本番同等データ（62万回線・1か月分）での請求計算が、既存システムと全件一致 | 部長級の会議体 | ― |
判定履歴
ID | 判定 | 満たせなかった条件 | 遅れ |
|---|---|---|---|
G0 | 差し戻し（1回） | ② 項目定義の「未定」が14件残っていた | 5営業日 |
G1 | 差し戻し（2回） | ① 計算例72件のうち8件が不一致 | 10営業日 |
G2 | 通過 | ― | 0日 |
G3 | 差し戻し（1回） | ② 直近2週の発生件数がピーク週の34%（基準20%以下） | 5営業日 |
G4 | 通過 | ― | 0日 |
― | 合計4回の差し戻し | ― | 20営業日 |
合計20営業日、約1か月の遅れが出ました。それでも稼働日は動いていません。4つのゲートにそれぞれ5営業日のバッファを置いてあったからです。ちょうど使い切りました。
結果として、受入テストの不具合密度は前回の4.90件/KStepから0.20件/KStepになりました。単体テストで捕まえた割合が35.9%から64.9%に増え、受入テストまで届いたものが21.7%から0.9%に減っています。
■ 運用ルール
通過条件は3〜4個まで。多いと判定に時間がかかり、形骸化します
条件はすべて、数字か○×で答えられる形にする。文章の条件は必ず揉めます
判定は会議体で行い、議事録に残す。個人での判定は押し切られます
ゲートの後ろに3〜5営業日のバッファを置く。これがないと、必ず「特例で通過」が起きます
判定シートは3営業日前に自己点検し、前日に配る。当日に初めて見る資料では確認が終わりません
条件付き通過は、宿題3件まで・担当と期限つき・次のゲートまでに解消。この3つを守らないと、逃げ道になります
特例通過の件数を数える（目標0件）。1件でも出たら、会議で取り上げます
条件付き通過が2回続いたら、基準そのものを見直す。現場の実態に合っていない可能性があります
4番目が、この帳票でいちばん大事なルールです。止まる余地のない計画にゲートを置くと、ゲートは必ず形だけになります。ゲートは、止まれる計画とセットで初めて機能します。
■ 活用シーン
場面 | 使い方 |
|---|---|
計画を立てるとき | ゲートの位置とバッファを、スケジュールに組み込む |
工程の完了判定 | 判定シートで1つずつ確認する。30分で終わる |
ベンダーとの合意 | 契約時に通過条件を示し、成果物の受入基準として合意する |
遅れの説明 | 「G1で2回差し戻し、10営業日。バッファで吸収済み」と説明できる |
次の案件の計画 | 判定履歴を見て、どのゲートで詰まりやすいかを把握し、バッファを調整する |
レビュー運用の見直し | 差し戻しの理由を集計し、前工程のやり方を改善する |
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
条件が「品質が十分であること」 | 判定で揉め、結局その場の空気で通る | ゼロ型・下限型・全件一致型の3つの型に当てはめる |
バッファを置かない | 差し戻すと納期が動くため、「特例で通過」が起きる | 1ゲートあたり3〜5営業日を計画に組み込む |
条件を8個以上置く | 判定に時間がかかり、やがて行われなくなる | 3〜4個に絞る。本当に次工程の前提になるものだけ |
判定を担当者個人に任せる | 押し切られる | 会議体で判定し、議事録に残す |
条件付き通過を広く使う | 宿題が溜まり、最後にまとめて出てくる | 宿題3件まで・担当と期限つき・次のゲートまでに解消 |
「少なすぎたら疑う」条件を入れない | テストが甘いことを見逃す | 結合テストの不具合密度に下限を設ける |
特例通過を記録しない | 何回特例にしたかが分からず、歯止めが利かない | 特例通過の件数を月次で報告する（目標0件） |
■ 導入効果
項目 | ゲートがない場合（前回） | ゲートがある場合（今回） |
|---|---|---|
受入テストの不具合密度 | 4.90件/KStep | 0.20件/KStep |
うち仕様の認識違い | 218件（53%） | 2件（11%） |
単体テストで捕まえた割合 | 35.9% | 64.9% |
受入テストの期間 | 計画6週 → 実績14週 | 計画3週 → 実績3週 |
本番稼働 | 2か月遅れ | 予定どおり |
追加でかかった工数 | ― | 4人月（ゲート運営と差し戻しのやり直し） |
追加の4人月に対して、前回は受入テストが8週間延び、業務部門12名を余分に拘束しました。委託費には出ませんが、社内の人件費としては4人月を大きく上回る損失です。
最後に1つ。ゲートを5つ全部作るのが大変なら、まず1つだけ置いてください。おすすめは要件定義の出口です。条件は「要件に受入テストのケース番号が紐づいているか」「項目定義に未定が0件か」「業務部門の責任者が署名したか」の3つで十分です。この1つだけでも、受入テストの手戻りは目に見えて減ります。