工程完了判定の基準とチェックリスト｜フェーズゲート判定項目

工程完了判定とは、1つの工程を終えて次の工程へ進んでよいかを、あらかじめ決めた基準で確かめる手続きです。 フェーズゲート、工程移行判定とも呼ばれます。基準を工程の始めに決めておくと、判定の場が「進めたい気持ち」ではなく事実の確認になります。

この記事では、要件定義から総合テストまでの6工程について、判定項目をタブ区切りで貼れる形で載せ、数値基準の計算式、判定会議の議題、判定票の記入例までをそろえました。本番へ出すかどうかを決めるリリース判定には触れず、途中の工程を次へ進める判定に絞っています。

確認環境：計算例は Python 3.11 で実行、Mermaidの図は @mermaid-js/mermaid-cli 11.14.0 とChromiumで描画できることを確かめています（Linux、確認日 2026-10-06）。数値の基準と記入例はすべて架空の例です。自分たちの過去の数字に合わせて置き換えてください。

この記事の結論

• 判定は4つの観点で行う：成果物がそろっているか・品質の数値・残っている課題・次工程の準備
• 結果は「通過・条件付き通過・差し戻し」の3つから決める
• 項目は「必須」と「任意」に分け、必須が1つでも満たせず期限つきでも補えないなら差し戻す
• 条件付き通過には、条件・期限・担当・確認方法の4つを必ず書く
• 数値は割合だけでなく件数でも確かめる（239件÷240件は、整数の表示では100%に見えます）

工程完了判定の早見表

工程完了判定・リリース判定・マイルストーン・完成の定義の違い

4つは重ねて使えます。完成の定義で1つずつの作業を締め、工程完了判定で工程をまとめて確かめ、その日をマイルストーンとして計画表に置き、最後にリリース判定を行うという関係です。

判定の4観点と3つの結果

「成果物」と「品質の数値」は終える工程を振り返る観点、「残っている課題」と「次工程の準備」はこれから始める工程を見る観点です。前の2つだけで判定すると、次工程が初日に止まることがあります。 4つをそろえて見ます。

6工程の判定チェックリスト（48項目）

各工程8項目、合計48項目です。「区分」が必須の項目は、満たさないと通過になりません。「基準の例」は架空の値なので、自分たちの決まりに置き換えてください。

表計算ソフトに貼れるタブ区切りです。右に「結果（○・×）」「根拠の場所」「補える期限」の列を足すと、そのまま判定票の添付になります。

工程  観点  判定項目    区分  基準の例
要件定義    成果物 要件定義書（機能・非機能）が版つきでそろっている    必須  全章が記入済み
要件定義    成果物 業務の流れと機能の対応表が埋まっている 必須  対応のない業務が0件
要件定義    品質の数値   要件定義書のレビューを全ページ終えた  必須  レビュー実施率100%
要件定義    品質の数値   レビュー指摘がすべて対応済みか、対応方針が決まっている 必須  指摘の対応率100%
要件定義    残っている課題 未決の事項に担当と期限が付いている   必須  担当・期限なしが0件
要件定義    残っている課題 範囲に入れないことを明記した  任意  対象外の一覧がある
要件定義    次工程の準備  利用部門の代表から要件の承認を得た   必須  承認の記録がある
要件定義    次工程の準備  基本設計の担当と日程が決まっている   必須  体制表と日程表がある
基本設計    成果物 画面・帳票・外部連携・データの設計書がそろっている   必須  一覧の全項目が作成済み
基本設計    成果物 要件と設計の対応表が埋まっている    必須  対応のない要件が0件
基本設計    品質の数値   設計書のレビューを全ページ終えた    必須  レビュー実施率100%
基本設計    品質の数値   レビュー指摘密度が目安の範囲にある   必須  0.2〜1.0件/ページ
基本設計    品質の数値   レビュー指摘がすべて対応済み  必須  指摘の対応率100%
基本設計    残っている課題 未決の事項が詳細設計を止めない 必須  影響の大きい未決が0件
基本設計    次工程の準備  詳細設計の書き方と見本が用意できている 必須  見本が1機能分ある
基本設計    次工程の準備  非機能の方式（性能・可用性・権限）が決まっている    任意  方式の記述がある
詳細設計    成果物 対象の全機能の詳細設計書がそろっている 必須  機能一覧の全行が作成済み
詳細設計    成果物 単体テストの観点が書かれている 必須  機能ごとに観点表がある
詳細設計    品質の数値   設計書のレビューを全ページ終えた    必須  レビュー実施率100%
詳細設計    品質の数値   レビュー指摘密度が目安の範囲にある   必須  0.2〜1.0件/ページ
詳細設計    残っている課題 基本設計へ戻す変更がすべて反映済み   必須  未反映が0件
詳細設計    残っている課題 未決の事項に担当と期限が付いている   必須  担当・期限なしが0件
詳細設計    次工程の準備  コーディングの決まりと開発環境が用意できている 必須  全員の環境で起動を確認
詳細設計    次工程の準備  実装の担当割りと見積もりの見直しが済んでいる  任意  担当表がある
実装  成果物 対象の全機能のコードがリポジトリに入っている  必須  機能一覧の全行が取り込み済み
実装  成果物 単体テストのコードと結果がそろっている 必須  結果の記録がある
実装  品質の数値   コードレビューを全変更で終えた 必須  レビュー実施率100%
実装  品質の数値   単体テストを予定どおり消化した 必須  テスト消化率100%
実装  品質の数値   静的解析の指摘が基準内である  任意  重要度高の指摘が0件
実装  残っている課題 未解決の不具合が基準内である  必須  重要度高0件、中3件以下
実装  次工程の準備  結合テストの環境とデータが用意できている    必須  環境で起動を確認
実装  次工程の準備  結合テストの仕様書がレビュー済み    必須  レビュー実施率100%
結合テスト   成果物 テスト結果の記録がそろっている 必須  全ケースに結果と証跡がある
結合テスト   成果物 不具合の一覧が最新である    必須  全件に状態と担当がある
結合テスト   品質の数値   テストを予定どおり消化した   必須  テスト消化率100%
結合テスト   品質の数値   合格率が基準を満たす  必須  テスト合格率95%以上
結合テスト   品質の数値   不具合の発見が落ち着いている  任意  直近5日の新規が減っている
結合テスト   残っている課題 未解決の不具合が基準内である  必須  重要度高0件、中3件以下
結合テスト   残っている課題 直した不具合の再テストが済んでいる   必須  再テスト待ちが0件
結合テスト   次工程の準備  総合テストの環境・データ・体制が用意できている 必須  環境で起動を確認
総合テスト   成果物 機能と非機能のテスト結果がそろっている 必須  全ケースに結果と証跡がある
総合テスト   成果物 運用の手順書と利用者向けの資料がそろっている  必須  一覧の全項目が作成済み
総合テスト   品質の数値   テストを予定どおり消化した   必須  テスト消化率100%
総合テスト   品質の数値   性能などの非機能の目標を満たした    必須  目標値をすべて達成
総合テスト   残っている課題 未解決の不具合が基準内である  必須  重要度高0件、中0件
総合テスト   残っている課題 見送る不具合に回避策と対応の時期がある 必須  全件に記載がある
総合テスト   次工程の準備  受け入れの確認をする人と日程が決まっている   必須  日程表がある
総合テスト   次工程の準備  移行の手順を通しで試した    任意  試した記録がある

数値基準の例と計算式

基準を決めるときの考え方です。

• 上限と下限の両方を置く。 レビュー指摘密度が上限を超えれば成果物の作りを、下限を下回ればレビューのやり方を確かめます。
• 割合と件数を組にする。 テスト消化率100%は「予定240件、実施240件」と件数で書きます。
• 重要度の決め方を先にそろえる。 「高＝次工程の作業が止まる」「中＝回避策があれば進められる」「低＝表示や文言」のように、1行で言える定義にします。
• 最初の基準は過去の自分たちの数字から置く。 数字がなければ、今回の工程の値を記録して次回の基準にします。

Pythonで計算して判定する

3つの例（基本設計・結合テスト・詳細設計）で、指標の計算と判定を行うコードです。満たせない点ごとに「期限つきで補えるか」を持たせ、すべて補えるなら条件付き通過、1つでも補えないなら差し戻しとします。

def ratio(numer, denom):
    """分母が0のときは None を返す（まだ数えられない、の意味）"""
    return None if denom == 0 else numer / denom


def judge(gate):
    """必須項目と数値基準から 通過・条件付き通過・差し戻し を返す"""
    findings = []  # (内容, 期限つきで補えるか)

    for name, ok, can_fix in gate["required"]:
        if not ok:
            findings.append((f"必須項目が未達: {name}", can_fix))

    for name, value, low, high, can_fix in gate["metrics"]:
        if value is None:
            findings.append((f"{name}: 分母が0で計算できない", can_fix))
        elif value < low:
            findings.append((f"{name}: {value:.3f} が下限 {low} より小さい", can_fix))
        elif high is not None and value > high:
            findings.append((f"{name}: {value:.3f} が上限 {high} より大きい", can_fix))

    for level, count, limit, can_fix in gate["open_bugs"]:
        if count > limit:
            findings.append((f"未解決の不具合（重要度{level}）: {count}件、上限 {limit}件", can_fix))

    if not findings:
        return "通過", findings
    if all(can_fix for _, can_fix in findings):
        return "条件付き通過", findings
    return "差し戻し", findings


gates = [
    {   # 例A：基本設計
        "name": "基本設計",
        "required": [("設計書がそろっている", True, False),
                     ("要件との対応表が埋まっている", True, False)],
        "metrics": [("レビュー実施率", ratio(120, 120), 1.0, None, False),
                    ("レビュー指摘密度（件/ページ）", ratio(54, 120), 0.2, 1.0, False),
                    ("指摘の対応率", ratio(54, 54), 1.0, None, True)],
        "open_bugs": [],
    },
    {   # 例B：結合テスト
        "name": "結合テスト",
        "required": [("テスト結果の記録がそろっている", True, False),
                     ("総合テストの環境が用意できている", True, True)],
        "metrics": [("テスト消化率", ratio(234, 240), 1.0, None, True),
                    ("テスト合格率", ratio(230, 234), 0.95, None, False)],
        "open_bugs": [("高", 0, 0, False), ("中", 2, 3, True), ("低", 5, 10, True)],
    },
    {   # 例C：詳細設計
        "name": "詳細設計",
        "required": [("設計書がそろっている", True, False),
                     ("単体テストの観点が書かれている", False, True)],
        "metrics": [("レビュー実施率", ratio(150, 200), 1.0, None, False),
                    ("レビュー指摘密度（件/ページ）", ratio(12, 150), 0.2, 1.0, False)],
        "open_bugs": [],
    },
]

for g in gates:
    result, findings = judge(g)
    print(f"[{g['name']}] 判定: {result}")
    for name, value, *_ in g["metrics"]:
        print(f"  {name} = {value:.3f}" if value is not None else f"  {name} = 計算できない")
    for text, can_fix in findings:
        print(f"  - {text}（{'期限つきで補える' if can_fix else '補えない'}）")

print("--- 表示の丸めに注意 ---")
print(f"{239/240:.0%}", f"{239/240:.1%}", 239 == 240)
print(ratio(0, 0))

実行結果です。

[基本設計] 判定: 通過
  レビュー実施率 = 1.000
  レビュー指摘密度（件/ページ） = 0.450
  指摘の対応率 = 1.000
[結合テスト] 判定: 条件付き通過
  テスト消化率 = 0.975
  テスト合格率 = 0.983
  - テスト消化率: 0.975 が下限 1.0 より小さい（期限つきで補える）
[詳細設計] 判定: 差し戻し
  レビュー実施率 = 0.750
  レビュー指摘密度（件/ページ） = 0.080
  - 必須項目が未達: 単体テストの観点が書かれている（期限つきで補える）
  - レビュー実施率: 0.750 が下限 1.0 より小さい（補えない）
  - レビュー指摘密度（件/ページ）: 0.080 が下限 0.2 より小さい（補えない）
--- 表示の丸めに注意 ---
100% 99.6% False
None

• 例A（基本設計）は、120ページすべてをレビューし、指摘54件（0.45件/ページ）がすべて対応済みで通過です。
• 例B（結合テスト）は、240件のうち6件が残っています（消化率97.5%）。残りが環境の都合で、期限を決めて実施できるため条件付き通過です。
• 例C（詳細設計）は、レビューが200ページ中150ページ（75%）で、指摘密度も0.08件/ページと下限を下回りました。レビューの残りは次工程と並行では補えないと判断し、差し戻しです。

判定会議の議題（30分の例）

会議をなめらかに進めるための準備です。

• 判定票は前日までに配る。 会議は読む場ではなく決める場にします。
• 根拠の場所（ファイルやページ）を判定票に書く。 その場で開いて確かめられます。
• 次工程の担当に必ず出てもらう。 受け取る側の「始められる」という確認が、4つ目の観点の答えになります。
• 判定者を1人に決めておく。 意見が分かれたときに結果を出せます。

判定票のテンプレート

# 工程完了判定票

| 項目 | 内容 |
|---|---|
| 対象 |  |
| 工程 |  |
| 判定日 |  |
| 判定者 |  |
| 出席者 |  |
| 使用した基準 | 工程完了判定基準 第　版 |

## 1. 4観点の結果

| 観点 | 結果（○・△・×） | 根拠の場所 | 補足 |
|---|---|---|---|
| 成果物がそろっているか |  |  |  |
| 品質の数値 |  |  |  |
| 残っている課題 |  |  |  |
| 次工程の準備 |  |  |  |

## 2. 数値

| 指標 | 分子 | 分母 | 値 | 基準 | 結果 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 3. 満たせていない項目

| 番号 | 項目 | 理由 | 期限つきで補えるか |
|---|---|---|---|
|  |  |  |  |

## 4. 判定

結果：通過 ／ 条件付き通過 ／ 差し戻し

## 5. 条件（条件付き通過のとき）

| 番号 | 条件 | 期限 | 担当 | 確認方法 | 確認者 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

期限までに満たせないときの扱い：

## 6. 差し戻しのとき

- やり直す範囲：
- 再判定の日：

条件付き通過の記入例

例Bの結合テスト（社内向け備品予約システム）を判定票に書いたものです。

# 工程完了判定票

| 項目 | 内容 |
|---|---|
| 対象 | 備品予約システム 第2版 |
| 工程 | 結合テスト |
| 判定日 | 2026-06-19 |
| 判定者 | 中村（管理する立場の人） |
| 出席者 | 山本（結合テスト担当）、小林（総合テスト担当）、田中（進行役） |
| 使用した基準 | 工程完了判定基準 第3版 |

## 1. 4観点の結果

| 観点 | 結果（○・△・×） | 根拠の場所 | 補足 |
|---|---|---|---|
| 成果物がそろっているか | ○ | 結合テスト結果一覧 | 実施済み234件すべてに結果と証跡あり |
| 品質の数値 | △ | 同上、不具合一覧 | 消化率が基準に届いていない |
| 残っている課題 | ○ | 不具合一覧 | 重要度高0件、中2件、低5件 |
| 次工程の準備 | ○ | 総合テスト計画書 | 環境の起動を6月18日に確認 |

## 2. 数値

| 指標 | 分子 | 分母 | 値 | 基準 | 結果 |
|---|---|---|---|---|---|
| テスト消化率 | 234 | 240 | 97.5% | 100% | × |
| テスト合格率 | 230 | 234 | 98.3% | 95%以上 | ○ |
| 未解決の不具合（高） | 0 | － | 0件 | 0件 | ○ |
| 未解決の不具合（中） | 2 | － | 2件 | 3件以下 | ○ |

## 3. 満たせていない項目

| 番号 | 項目 | 理由 | 期限つきで補えるか |
|---|---|---|---|
| 1 | テスト消化率100% | 通知メールの6件が、検証用メールサーバーの準備待ちで実施できていない | 補える（サーバーは6月22日に使える見込み） |

## 4. 判定

結果：条件付き通過

## 5. 条件（条件付き通過のとき）

| 番号 | 条件 | 期限 | 担当 | 確認方法 | 確認者 |
|---|---|---|---|---|---|
| 1 | 通知メールの6件を実施し、すべて合格する | 2026-06-24 | 山本 | 結合テスト結果一覧で6件の結果と証跡を見る | 中村 |
| 2 | 重要度中の不具合2件を直し、再テストを終える | 2026-06-26 | 山本 | 不具合一覧の状態が「完了」になっている | 小林 |

期限までに満たせないときの扱い：期限の翌営業日に判定者へ報告し、総合テストのうち通知に関わるケースを止めて再判定する。

## 6. 差し戻しのとき

- やり直す範囲：（該当なし）
- 再判定の日：（該当なし）

条件を書くときのこつです。

条件の数は3つまでを目安にします。 それより多くなるなら、差し戻して範囲を決めてやり直すほうが、結果として早く進みます。

判定フロー図（Mermaid）

flowchart TD
    A[工程の作業が終わる] --> B[担当が判定票を記入する]
    B --> C{必須項目は<br>すべて満たしたか}
    C -- はい --> D{数値は基準の<br>範囲内か}
    C -- いいえ --> E{不足は期限つきで<br>補えるか}
    D -- はい --> F[通過]
    D -- いいえ --> G{理由を説明でき<br>追加の確認が済んだか}
    G -- はい --> F
    G -- いいえ --> E
    E -- はい --> H[条件付き通過<br>条件・期限・担当を記録]
    E -- いいえ --> I[差し戻し<br>やり直す範囲と再判定日を決める]
    F --> J[次工程を始める]
    H --> J
    H --> K{期限までに<br>条件を満たしたか}
    K -- はい --> L[条件を閉じる]
    K -- いいえ --> M[判定者へ報告し<br>再判定する]
    I --> B

Mermaidに対応したエディタやドキュメントに貼ると図になります。条件付き通過は次工程を始めたあとも線が続き、期限の確認まで終えて閉じる形にしています。

確かめて分かったこと

• 239件÷240件は、小数点なしの表示では「100%」になりました（小数第1位までなら99.6%）。割合の表示だけで判定すると、1件残っていても通過に見えます。件数どうしを比べるか、小数第1位まで表示します。
• 指摘密度が低い例Cは、下限の確認で引っかかりました。 上限だけを基準にしていると、0.08件/ページは「よい結果」として通ります。下限を置くと、レビューの量を見直すきっかけになります。
• 分母が0のとき（テストが始まっていない、など）は割り算ができません。 コードでは値を None にして「計算できない」と表示する形にしました。判定票でも、空欄ではなく「対象なし」「着手前」と書き分けると読み違いが減ります。
• 「期限つきで補えるか」を項目ごとに持たせると、3つの結果を機械的に分けられました。 判定の場で話し合うべき点が、「補えるかどうか」の1つに絞られます。
• Mermaidのフロー図では、ひし形の中の改行に <br> が使え、矢印のラベルは -- はい --> の形で描画できました。 条件付き通過から2本の矢印（次工程の開始と、期限の確認）を出しても崩れませんでした。

よくある質問

Q. 工程完了判定とは何ですか？ A. 1つの工程を終えて次へ進んでよいかを、決めておいた基準で確かめる手続きです。成果物・品質の数値・残っている課題・次工程の準備の4観点で見ます。

Q. 工程完了判定とリリース判定の違いは何ですか？ A. 工程完了判定は途中の工程を次へ進める判定、リリース判定は本番へ出すかどうかの判定です。前者は工程ごとに繰り返し、後者は出す前に行います。

Q. 基準を満たせないときは必ず差し戻しですか？ A. いいえ、期限つきで補える内容なら条件付き通過にできます。条件・期限・担当・確認方法を書き、期限に確かめることが前提です。

Q. 数値の基準はどう決めればよいですか？ A. 過去の自分たちの数字を出発点にします。数字がない場合は、この記事の例を仮の基準として使い、今回の値を記録して次回に見直します。

Q. 判定会議には誰が出ればよいですか？ A. 判定者、終える工程の担当、次工程の担当、進行役の4者です。次工程の担当が「始められる」と確かめることが、次工程の準備の観点の答えになります。

まとめ

• 工程完了判定は4観点（成果物・品質の数値・残っている課題・次工程の準備）で行う
• 結果は通過・条件付き通過・差し戻しの3つ。分かれ目は「期限つきで補えるか」
• 6工程48項目のチェックリストを、必須と任意に分けて使う
• 数値は上限と下限、割合と件数を組にして確かめる
• 条件付き通過には条件・期限・担当・確認方法を書き、満たせないときの扱いも決める
• 判定会議は30分。判定票は前日までに配り、次工程の担当に出てもらう
• リリース判定・マイルストーン・完成の定義とは、決めることと時点で使い分ける

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。