# レビュー記録・残課題一覧ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「承認処理の修正差分を、実装者以外の観点でレビューする」（09-04）の本文で実際に記録した内容をまとめたもの。空欄版は `09-04-review-record_template.md`。

## 1. レビュー記録

| 対象差分 | 観点 | 指摘 | 対応 | 確認者 |
|---|---|---|---|---|
| 08-04 storage_v1.js→v2.js | 要件との対応 | 部分失敗を正常完了として扱わない報告にはなっている（REQ-007）。ただし保存先には状態だけ変わった依頼が残る（不変条件の行） | 報告は対応不要。保存先は未対応 | Claude Code（実装者と同一の自己レビュー。独立レビューではない。本文第3.3節・第8.1節） |
| 同上 | 権限 | 権限判定は変更しておらず、新たに許可される操作はない | 対応不要 | 同上 |
| 同上 | 履歴 | 失敗時にも原因調査に必要な情報が失敗ログに残る | 対応不要 | 同上 |
| 同上 | 秘密情報の混入 | 失敗ログにパスワード等の秘密情報は含まれていない | 対応不要 | 同上 |
| 同上 | 不変条件（状態のロールバック） | 履歴の書き込み失敗時に状態を元に戻す処理がなく、記事Aの不変条件（承認済みには承認履歴が必ずある）を満たさない | 未対応（残課題） | 同上 |

## 2. 残課題一覧

| 残課題 | 影響 | 対処予定 |
|---|---|---|
| 実装者以外の人による確認が行われていない | 中（利用開始前に人による確認が必要） | 10-01の確認者も同じAI。10-04で「限定試行へ進む条件」として延期。この教材の範囲では未回収 |
| 履歴書き込み失敗時に状態をロールバックしない設計（不変条件の違反） | 中（頻度は低いが発生時に運用対応が必要） | 設計の解決は記事B（09-02）のトランザクション。題材アプリへの適用は未決。12-02の本文は現時点でこの課題を扱っておらず未回収 |

## 3. 完了条件の確認

- [x] 実装者以外の確認者（または別観点）が明記されている（実装者以外の確認者はいない＝未実施と明記。別観点5つを明記）
- [x] 指摘ごとに対応状況がある
- [x] 残課題に影響の大きさが書かれている

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

- [x] レビュー記録・残課題一覧（第1〜2節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い