# 機能一覧・対象範囲ひな形（記入例）

架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。
記事「業務要件から、最初に作る機能と後回しにする機能を分ける」（02-02）の本文で使った内容をまとめたもの。空欄版は `02-02-feature-scope_template.md`。

## 1. 機能一覧

| 機能 | 区分（最初に作る／後で／今回は作らない） | 関連要件ID | 理由 | 代替運用 |
|---|---|---|---|---|
| 依頼の作成（下書き） | 最初に作る | REQ-001 | 依頼を識別できなければ、他の操作が成立しない | — |
| 依頼の提出 | 最初に作る | REQ-004 | 必須項目（件名・内容・承認者）がそろっていることの確認が要件そのもの | — |
| 承認 | 最初に作る | REQ-003 | 割当承認者だけが承認できることが、この業務の中心の約束 | — |
| 差戻し | 最初に作る | REQ-003、REQ-004 | 理由付きの差戻しがなければ、不備のある依頼が承認済みになりかねない | — |
| 一覧閲覧 | 最初に作る | REQ-002 | 自分に関係する依頼が見えなければ、提出・承認のどちらも始められない | — |
| 提出済みの取り下げ | 後で | — | 誤って提出した場合の操作だが、差戻してもらう運用で当面代替できる | 承認者に差戻しを依頼する |
| 承認取消 | 後で | — | 承認済みの扱いを初期版では固定し、取消の影響範囲を先に確定させない | 誤承認が起きた場合は運用管理者が記録し、以後は手順を見直す（システムでは戻さない） |
| 代理承認 | 後で | — | 誰がいつ代理できるかという社内ルールが未確認 | 承認者が対応できない場合は、運用管理者が承認者の割当を変更してから承認者本人が承認する |
| 通知メール | 後で | — | まず一覧で状況が見えることを優先する | 依頼者・承認者が一覧をこまめに確認する |
| 依頼への添付ファイル | 今回は作らない | — | 社外秘の情報を含むかどうかが未確認 | 添付が必要な場合は、既存の共有フォルダのリンクを内容欄に文字で書く |
| 管理者による緊急の業務変更 | 今回は作らない | — | 設計書第5.2節の未採用テーマ。通常運用の振りをして曖昧に実装しない | 緊急時は運用管理者が関係者に直接連絡し、対応を記録に残す（システム上の特別な操作は用意しない） |
| 退職者データの詳細な保存期間 | 今回は作らない | — | 設計書第5.2節の未採用テーマ。保存期間の規程が確認できていない | 退職者の依頼・履歴は削除せずそのまま残し、保存期間の運用は別途確認してから設計する |

## 2. 完了条件の確認

- [x] すべての機能に3区分のいずれかと理由がある
- [x] 最初に作る機能が要件IDと対応している
- [x] 未採用テーマ（設計書5.2）が「今回は作らない」に明記されている
- [x] 「後で」「今回は作らない」の機能に代替運用が書かれている

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

- [x] 機能一覧（第1節）
- [x] 代替運用の一覧（第1節）
- [ ] 承認者：総務課長（架空）— 記入例のため未承認の扱い