Guide
小さなシステムの要件定義テンプレート
目的、利用者、業務フロー、対象・非対象、入出力、受入条件、運用担当を15項目に絞り、本番向け拡張も示す初心者用要件定義テンプレート。
小さな社内ツールやWebサービスでも、要件は残します。まず目的、利用者、業務フロー、対象・非対象、入出力、受入条件、運用責任者を15項目の1枚にまとめます。データや権限などの本番要件は、案件に当てはまるものだけを拡張すると、AIへ頼む実装範囲も伝えやすくなります。
対象は、初めて要件を書く非エンジニアと個人開発者です。解く課題と成功指標が未定なら、先に課題定義の手順を使ってください。大規模基幹システムの調達仕様や個別法務判断は対象外です。
まずは15項目を1枚にまとめる
最初から全項目を埋めようとせず、実装範囲を話し合うための最小版を作ります。次の15項目だけを1枚にまとめてください。分からない項目は空欄にせず「未決」と書き、決める人と期限を添えます。
# 小さなシステムの要件メモ
1. 解く課題:
2. 利用者:
3. 現在の手順:
4. 成功指標:
5. 今回の非対象:
6. 利用者がしたいことと理由:
7. 通常の流れ:
8. 例外・失敗時の流れ:
9. 人が確認する箇所:
10. 入力:
11. 出力:
12. 扱うデータと機密区分:
13. 受入条件と確認方法:
14. 業務責任者と副担当:
15. 実装を止めて相談する条件・相談先:この最小版は、試作の目的と境界をそろえるための入口です。個人情報や機密情報、本番運用、外部サービス連携、ログイン、課金、公開、自動実行を含む場合は、次の拡張項目も必要です。
本番や外部連携がある場合の拡張項目
すべての案件へ一律に追加するのではなく、該当する行を要件メモへ足します。未確認のまま本番データの利用や外部接続へ進まないでください。
| 分類 | 追加する項目 | 追加が必要な例 |
|---|---|---|
| データ | 取得元、正本、形式、利用目的、保存先、ログ、バックアップ、受信者、保存期間、削除方法、区間ごとの分類と承認 | 個人情報、契約上の機密、外部送信、国外処理がある |
| 認証・権限 | 認証方法、閲覧・編集・承認・管理の範囲、権限変更者、サービスアカウント、異動・退職時の回収 | ログインや管理者操作がある |
| 受入条件 | 正常時、失敗時、権限差、重複・同時操作、締め処理後、測定方法、合格値 | 複数人で使う、外部サービスに依存する |
| 運用 | 技術窓口、変更承認者、監視、問い合わせ、停止・復旧手順、復旧目標、引継ぎ、廃止 | 本番で継続利用する |
| バックアップ | 対象、責任者、取得頻度、保持期間、本番からの分離、復元テストと証拠 | 業務データを保存する |
| 契約・高影響操作 | 課金・自動更新の責任者、公開・送信・削除・一括更新・自動承認の承認者、停止方法 | 金銭や外部への影響がある |
以降では、各項目をどう決めるかを順に説明します。
利用者要件は「誰が・何を・なぜ」で書く
GOV.UKのユーザーストーリーガイドは、利用者、必要な行動、理由を分ける形式を示しています。
たとえば「CSV（表形式のデータを文字で保存する形式）の書き出し機能を作る」では、誰の何が改善するか分かりません。
月次報告を作る経理担当者として、承認済みの当月明細だけをCSVで取得したい。会計システムへ手入力せず照合するため。
この文章から、対象月、承認状態、項目、文字エンコード、権限、空データ時の挙動を質問できます。ユーザーストーリーは入口であり、データやセキュリティ要件の代わりではありません。
業務フローは画面の外まで描く
画面遷移だけを書くと、メール、電話、承認、手作業の転記が抜けます。GOV.UKのサービス全体を可視化するガイドは、オンライン・オフライン接点、裏側の処理、関与者、利用者が提出する情報を含めるよう説明しています。
最小の出発点として、まず次の5列に整理します。案件に応じて関与者、証拠、例外の列を追加してください。
| 順番 | 利用者の行動 | システムの処理 | 人の処理 | データ |
|---|---|---|---|---|
| 1 | 申請する | 入力を検証 | — | 申請内容 |
| 2 | — | 承認者へ通知 | 内容を確認 | 申請・履歴 |
| 3 | 結果を見る | 状態を更新 | 承認・差戻し | 結果・理由 |
通常どおり進む経路（正常経路）の下に、入力不足、権限なし、外部サービス停止、重複操作の経路を足します。
対象と非対象を対で書く
対象範囲は機能一覧だけではありません。
| 対象 | 非対象 |
|---|---|
| 承認済み明細のCSV出力 | 会計仕訳の自動登録 |
| 社内アカウントでの利用 | 顧客への公開 |
| 当月分の検索 | 過去データの完全移行 |
| 人が承認して送信 | AIによる自動送信 |
非対象は永久に作らない宣言ではなく、今回の完成判定を守る境界です。追加要望は新しい判断として記録します。
実装を止めて相談する条件
現状の手順、非対象、成功指標を部門内で整理する作業は進められます。一方、次の条件に当てはまる場合は、確認結果が記録されるまで契約、本番データの利用、外部接続、公開を止めます。架空・合成データによる試作も、社内規程で認められた範囲に限ります。
| 条件 | 主な相談先 | 未確認の間に止めること |
|---|---|---|
| 個人情報、契約上の機密、秘密情報を扱う | 業務・データ責任者、セキュリティ、個人情報保護・法務 | 本番データの取得、複製、入力 |
| 外部サービスへ送信する、APIで連携する、国外で処理される | IT、セキュリティ、データ・契約責任者 | 外部送信と接続 |
| ログイン、認証、権限、管理者・サービスアカウントを設ける | IT、セキュリティ、業務責任者 | アカウント発行と本番設定 |
| 課金、決済、契約、自動更新が発生する | 業務責任者、調達・経理 | 購入、契約、支払情報の登録 |
| 外部送信、公開、削除、一括更新、自動承認など影響の大きい操作を行う | 業務責任者、IT、セキュリティ、出力承認者 | 自動実行と本番公開 |
| 法令、業界ルール、契約、本人同意の適用が不明 | 個人情報保護・法務、業務責任者 | 対象データを使う実装 |
組織によって担当部署の名称は異なります。一人が複数の役割を担う場合も、相談内容、判断者、確認日、条件を要件へ残します。この表は個別案件の適法性や安全性を保証するものではありません。
データ要件は項目名だけで終わらせない
GOV.UKのデータ設計ガイドは、必要なデータの種類、取得元、形式、収集方法を考えるよう案内しています。
各データ群について、次を埋めます。
- 目的に本当に必要か
- どこから取得するか
- 正本（更新の基準となる原本）はどこか
- 誰が直せるか
- 保存と削除をどうするか
- 個人情報、契約上の機密、秘密情報を含むか
- テストに実データを使ってよいか
データフローを入口から削除までつなぐ
取得元だけでなく、処理、保存、ログ、バックアップ、出力、受信者、削除までを一つの流れにします。同じデータでも、ログやバックアップへ複製された時点で保存先と削除手順が増えるためです。
| 区間 | データと分類 | 処理・保存先・受信者 | 承認者・確認日 | 保持・削除 |
|---|---|---|---|---|
| 取得元→処理 | 取得する項目と分類 | 処理内容と実行環境 | ||
| 処理→保存 | 保存する項目と分類 | データベース等の保存先 | ||
| 処理→ログ | ログへ残す項目と分類 | ログの保存先と閲覧者 | ||
| 保存→バックアップ | 複製する項目と分類 | バックアップ先 | ||
| 処理・保存→出力・受信者 | 出力する項目と分類 | 画面、ファイル、外部送信先 | ||
| 保存・出力→削除 | 削除する対象 | 削除する場所と方法 | 完了の確認方法 |
実際の本番経路にある全区間を埋めます。分類、送信先・受信者、外部処理、承認のいずれかが未確認なら、本番データの投入と接続を止めます。承認には対象データ、利用目的、環境、条件、確認日を残し、経路が変わったら再確認します。
生成AIへデータを渡す場合は、入力してよいデータの判断フローを先に確認してください。
権限は操作単位で分ける
「ログインできる」だけでは権限要件になりません。NIST CSF 2.0のPR.AA-05（権限管理の項目）は、必要最小限の権限に絞り、申請や承認を一人へ集中させない管理を成果として挙げています。
| 操作 | 閲覧者 | 編集者 | 承認者 | 管理者 |
|---|---|---|---|---|
| 一覧を見る | ○ | ○ | ○ | ○ |
| 内容を変える | — | ○ | — | ○ |
| 公開・送信する | — | — | ○ | ○ |
| アカウントを管理する | — | — | — | ○ |
サービスアカウント（人ではなくシステムが使うアカウント）にも責任者を置き、権限、認証情報の保管場所と更新時期、停止方法を残します。
主担当だけで運用しない
本番運用へ進む前に、作った人が不在でも停止・復旧・問い合わせ対応を続けられる体制を決めます。
| 役割 | 残す内容 |
|---|---|
| 業務責任者 | 目的、優先順位、継続・停止の判断 |
| 副担当 | 主担当不在時の連絡、停止、復旧の手順 |
| 変更承認者 | 変更理由、影響範囲、受入条件の承認 |
| 保守責任者 | 監視、更新、問い合わせ、使える時間と予算 |
| 引継ぎ責任者 | 文書、権限、契約、データ、連絡先の受渡し |
| 廃止責任者 | 利用停止、データ移行・削除、権限回収、契約終了 |
小さな組織では一人が複数の役割を担うことがあります。それでも副担当と資料の保管先は分けて記録します。副担当を置けない試作品は、そのリスクを「未決」と残し、本番化の前に業務責任者が継続可否を判断します。
バックアップは復元できるところまで決める
「バックアップあり」だけでは、障害時に戻せるか判断できません。責任者と対象を決め、取得頻度、保持期間、本番環境からの分離方法を要件へ書きます。復旧目標には、業務を止められる時間と、戻す必要があるデータの時点を記録します。
復元テストでは、実施日、対象、結果、担当者、ログ等の証拠の保管先を残します。証拠を確認できない場合は「復元確認済み」とせず、未決の運用条件として本番判断へ戻します。
受入条件は観測できる文にする
「使いやすい」「高速」「正しく動く」では合否を判定できません。前提（Given）、操作（When）、期待結果（Then）、測定方法に分けます。
Given: 承認済み明細が3件ある
When: 経理担当者が当月を選びCSV出力する
Then: 承認済み3件だけが指定列順で出力される
And（追加条件）: 未承認明細と他部署の明細は含まれない
確認: 自動テストと経理担当者のサンプル確認AI機能なら、通常例だけでなく、境界例、拒否すべき例、人へ引き継ぐ例を含めます。一般の業務ツールでも、入力不足、役割ごとの権限差、重複・同時操作、締め処理後、外部サービス停止、復旧後を確かめます。
AIへ渡す前の最終確認
- 要件にないファイルやデータを読ませない
- 変更対象と非対象を明示する
- 受入条件ごとに作業を分ける
- 実行するテストコマンドを書く
- 秘密情報や本番データをAIへの指示文（プロンプト）へ貼らない
- 差分を人が読んでからコミットする（Gitへ変更履歴として記録する）
変更を履歴へ残す方法はAIコーディングのGit作業手順で解説しています。
よくある質問
要件は途中で変えてもよいですか
変えて構いません。ただし、変更理由、影響する受入条件、データ移行、公開日を同じ記録へ残します。過去の判断を消すのではなく、新しい版として扱います。
項目を全部埋めないと実装できませんか
影響の小さい試作品では「未決」と明記して検証できます。本番公開を判断する時点では、権限、データ、運用責任者、停止・復旧を未決のまま残さない前提で確認します。