# 利用開始判定記録ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「残課題・受入結果・復旧手段を並べ、今の事実で下せる利用開始判定を記録する」（10-04）の本文で実際にまとめた内容をまとめたもの。空欄版は `10-04-go-nogo_template.md`。

## 1. 未解決問題と扱い

| 未解決問題 | 出所 | 扱い（受容／延期） | 理由 |
|---|---|---|---|
| 実際に動く画面が無く、受入確認で観測した結果が無い（合格0件・未確認4件） | 10-01 | 延期（画面完成後に10-01と同じ手順で再確認） | 観測していないものを確認済みとはみなせない |
| 提出時の必須項目チェックが実装に無い（AC-005の一部） | 10-01 | 延期（08-02へ戻して修正） | REQ-004に関わる。修正前に実際の依頼を載せない |
| 実装者以外の人による確認が行われていない | 09-04、10-01 | 延期（画面完成後、業務担当者による受入確認とあわせて行う） | 同じAIによる確認は独立した保証にならない |
| 履歴書き込み失敗時のロールバック設計の是非 | 09-04 | 受容（演習の範囲では） | 発生頻度が低く、失敗ログで検知できる。限定試行へ進む前に扱いを決める |
| 本格的な同時アクセス・負荷が未検証 | 09-03 | 延期（実業務導入前に確認） | 全社導入前には確認が必要 |

## 2. 利用開始判定記録

| 項目 | 内容 |
|---|---|
| 判定区分（演習／限定試行／実業務） | 演習成功（実際の業務では使わない） |
| 判定の根拠 | 承認可否の判定・保存・提出の連携は架空データで確認済み。画面が無く、受入確認で観測した結果が0件のため、実際の依頼を載せる限定試行に進む前提が整っていない |
| 利用範囲 | 配置サンドボックス内での演習のみ。実際の依頼データは載せない |
| 限定試行へ進む条件 | ①画面が実装・配置されている ②実装者以外が受入確認を行い、AC-005〜011に観測した結果がある ③提出時の必須項目チェックが修正されている ④総務課長（架空）の承認 |
| 未解決問題と扱い | 上表のとおり（延期4件、受容1件） |
| 責任者 | 運用管理者（架空の仮定） |
| 復旧手段 | 05-04の復旧方針、12-03・12-04のバックアップ・復元手順 |
| 承認条件 | 限定試行へ進む条件①〜③が満たされたうえで、総務課長（架空）の承認を得ること |
| 判定日 | 2026-09-20（作成日。実際の承認日ではない） |

## 3. 完了条件の確認

- [x] 判定区分（演習／限定試行／実業務）が明記されている
- [x] 責任者と承認条件が書かれている
- [x] 未解決問題ごとに受容／延期の扱いがある
- [x] 判定区分が入力の事実（受入確認済み0件・画面未実装）と矛盾していない

## 4. 次工程へ渡すもの

- [x] 利用開始判定記録（第2節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い