---
title: チェックリストの三重構造
description: 子タスクリスト・受入基準・Delivery Statusの3種類と、それぞれのチェック権限
seo:
  image: /ogp.png
---

すべてのバックログアイテムは3種類のMarkdownチェックボックスを持ちます。どれも見た目を整えるための飾りではありません。
GitLab/GitHubが進捗カウンターとして表示する、そのアイテムの現在の状態そのものです。

| チェックリスト | 存在場所 | 1ボックス= | チェックする権利を持つスキル |
|---|---|---|---|
| **子タスクリスト** | 親のdescription(Epicの`## Sub-Epics`、Sub-Epicの`## Issues`) | 子アイテム(`- [ ] #<iid> <title>`) | `implement-backlog`(実装とテストが完了した時)。`review-issue`が差し戻し、`merge-issue`がマージ時に検証 |
| **受入基準** | Issue本体の`## Acceptance Criteria` | 検証可能な条件(`- [ ] <criterion>`) | `implement-backlog`(実装確認)→`review-issue`(検証確認) |
| **Delivery Status** | 各アイテムの`## Delivery Status` | 進行段階(`Implemented` / `Reviewed` / `Merged`) | その段階に到達させたスキル(下の表) |

子タスクリストと受入基準が表すのは**実装状態**、つまりコードが書かれてテストが通ったかどうかです。
マージされたかどうかは表しません。マージまで含めた進行状況は`## Delivery Status`が担当します。

| 段階 | チェックするスキル | 意味 |
|---|---|---|
| `Implemented` | `implement-backlog` | コードがコミットされ、テストが通った(受入基準がすべてチェック済み) |
| `Reviewed` | `review-issue` | レビュー判定がMergeableになり、PR/MRを作った |
| `Merged` | `merge-issue` | PR/MRがマージされ、Issueがクローズされた |

:::warning[子タスクリストのチェック=マージ済み、ではありません]
子タスクリストにチェックが入っていても、マージが終わったとは限りません。`implement-backlog`が
「実装＋テスト完了」の時点でチェックするからです。逆に`review-issue`は、レビューで実装やテストが
不十分だと分かった場合、理由を添えてチェックを**外します**。
マージ済みかどうかを知りたいときは、`status::*`ラベルか`## Delivery Status`の`Merged`を見てください。
:::

:::note[この規約が保証すること]
チェックが入っている項目は、実際に確認が終わったものだけです。「あとで確認する予定だから」という理由で先にチェックは入れられません。
`export-backlog`は3種類すべてを**必ずチェックなしの状態で作成**します。そのあとは、どのスキルも「計画済みだから」という理由でチェックを入れることを禁止されています。
つまり、チェックが入っていれば、それは本当に検証済みだと信じられる仕組みになっています。
:::