自治体向け要件定義書の書き方・作り方

行政AIヤマトにおいては「DX・情報」の「自治体システム書類作成」のボタンで、この仕様の通り、AI出力できます。

要約・結論

自治体向け要件定義書は、システムに何を作らせるかだけでなく、自治体がどの行政目的を、どの業務と運用で実現し、何をもって受入可能と判断するかを合意する文書です。要件定義書が曖昧だと、発注者と事業者が同じ言葉を別の意味で理解し、追加費用、納期遅延、試験不合格、住民サービスの混乱につながります。

結論として、自治体向け要件定義書の書き方で最も重要なのは、目的から業務、機能、データ、非機能、運用、移行、受入条件までを追跡できる状態にすることです。「使いやすい」「迅速に」「適切に」のような表現だけで終わらせず、対象者、条件、処理、例外、測定方法を記載します。個人情報保護、セキュリティ、アクセシビリティ、公平な住民サービス、契約終了時の引継ぎを横断要件として扱います。法令、条例、国のガイドライン、自治体の規程は改定され得るため、案件時点の最新版と適用範囲を必ず確認してください。

想定読者

• 自治体のDX・情報政策担当、業務原課、窓口、契約、監査担当者
• 要件定義を担当する業務分析者、SE、PM、セキュリティ担当者
• 調達仕様書やRFPを作成する職員、支援事業者
• システムの受入試験、運用保守、データ管理を担う職員
• 住民向けサービスのアクセシビリティや利用者体験を確認する担当者

自治体向け要件定義書の章立て

1. 文書目的、対象、用語、版管理、承認
2. 背景、行政目的、成功指標
3. 対象業務、関係者、現行業務と課題
4. 将来業務、業務ルール、役割分担
5. システム化範囲・対象外
6. 機能要件、画面・帳票・通知
7. データ要件、外部連携要件
8. 非機能要件
9. セキュリティ・個人情報保護要件
10. アクセシビリティ・ユーザビリティ要件
11. 移行、教育、運用保守、引継ぎ要件
12. 試験、受入、稼働判定要件
13. 制約、前提、リスク、未決事項
14. 要件トレーサビリティ表

1. 要件定義の進め方

最初に要件定義計画を作り、対象、体制、会議、成果物、決定方法、変更管理を合意します。業務原課だけでなく、情報政策、セキュリティ、個人情報保護、法務・契約、財政、広報、アクセシビリティ、運用担当を必要に応じて参加させます。住民や現場職員の利用実態は、管理職へのヒアリングだけでは把握しにくいため、観察、問い合わせ分析、利用者テストなども検討します。

要件は「誰かが言った希望」をそのまま採用せず、行政目的、根拠、対象者、頻度、優先度、費用への影響を確認します。部門間で矛盾する場合、議事録へ残し、権限を持つ者が決定します。未決事項には責任者と期限を設定し、「別途協議」のまま設計へ流さないことが重要です。

既存資料、条例・規則、業務手順、様式、帳票、問い合わせ、障害、監査指摘、統計を収集します。ただし資料が現行運用と一致するとは限りません。文書上の手順と実際の手順の差を確認し、例外処理や属人的な判断を可視化します。

2. 背景・目的・KPIの書き方

目的は「システムを導入する」ではなく、住民の負担軽減、処理の迅速化、正確性、災害時の継続、職員の政策業務への集中など行政価値で表します。目的ごとに現状値、目標、測定時期、データ取得方法を定義します。

目的：申請手続の完了までに生じる住民負担を軽減する。
現状：平均入力時間は未計測。差戻し理由は自由記述で集計不能。
基準値確定：稼働前に4週間測定する。
指標：入力完了時間、途中離脱率、差戻し率、問い合わせ件数。
目標：基準値確定後、運用開始判定会議で合意する。
注意：オンライン利用率だけを成果とせず、窓口利用者の待ち時間も測る。

測定できない数値を無理に断定せず、いつ基準値を測り、誰が目標を承認するかを要件にします。KPIを達成するために個人を過度に追跡したり、デジタル利用を強制したりしないよう留意します。

3. 現行業務と将来業務

現行業務は、開始条件、担当、入力、処理、判断、出力、次工程、使用システム、所要時間、件数、例外を業務フローで示します。正常系だけでなく、書類不足、代理申請、取下げ、重複、期限超過、災害、システム停止などを確認します。

将来業務では、自動化後も人が判断する箇所を明示します。法的・政策的判断を単純にシステム判定へ置き換えず、説明、異議、訂正、救済の手段を設計します。AIを使う場合、AIの出力を参考情報とするのか、職員確認が必須か、誤りを誰が訂正するかを定義します。

窓口、郵送、電話、オンラインのチャネルを一体で考えます。オンライン化によって紙利用者の待ち時間が増えたり、職員が二重入力したりしないよう、全体業務を再設計します。デジタルに不慣れな人への支援や代理入力も業務要件です。

4. スコープと優先度

対象業務、対象組織、対象利用者、対象期間、対象データを明記します。対象外は「やらない」とだけ書かず、既存運用を継続するのか、別調達か、将来フェーズかを説明します。隣接システムとの責任境界を図示すると有効です。

優先度は、必須、重要、希望など定義を決めます。すべてを最優先にしないでください。法令・条例等の根拠、サービス停止の影響、代替手段、利用頻度、費用を基に判断します。MoSCoW等の分類を使う場合も、各区分の契約上の意味を合意します。

要件IDを付け、変更や削除でもIDを再利用しません。例は FUN-申請-001、SEC-認証-003 です。親要件と子要件、根拠、設計、試験を追跡できるようにします。

5. 機能要件の書き方

機能要件は「システムは、［利用者］が［条件］のとき、［処理］を行い、［結果］を確認できること」という形にすると具体化できます。入力項目、必須条件、形式、業務ルール、権限、エラー、ログ、通知、取消しを記述します。

要件ID：FUN-APP-012
名称：申請の一時保存
利用者：申請者
事前条件：申請者が本人確認を完了している。
要件：入力途中の申請を保存し、同一アカウントで再開できること。
例外：提出期限を過ぎた場合は再開不可とし、理由と問い合わせ先を表示する。
保存期間：業務上必要な期間を原課と個人情報担当が確定する。
監査：保存、再開、削除の日時を記録する。
受入基準：指定ブラウザとスマートフォンで保存・再開・期限切れを確認する。

一覧、検索、CSV出力では、対象項目、絞り込み、並び順、最大件数、文字コード、権限、マスキングを定義します。帳票は名称、用途、用紙、改ページ、押印欄、二次元コード、アクセシビリティ、保存形式を整理します。

通知は送信契機、宛先、文面管理、再送、送信失敗、個人情報の記載範囲、配信停止を定義します。メール本文に機微情報を直接書かず、安全な画面へ誘導するなどの方式を検討します。

6. データ要件

データ要件では、データ項目、意味、型、桁、必須、コード、主キー、関係、保持期間、更新者、利用目的、公開区分をデータ辞書にします。同じ「住所」「受付日」が部署ごとに違う意味を持たないよう、定義と基準時点を明確にします。

個人情報は、目的に必要な最小限の収集とします。「将来使うかもしれない」だけで収集項目を増やしません。本人からの開示・訂正等に対応できる検索性、誤登録の訂正履歴、保存期限到来時の削除・匿名化を定義します。

オープンデータや統計利用を想定する場合、個人が再識別される可能性を検討します。単純に氏名を削除すれば安全とは限りません。公開単位、少数値、位置情報、他データとの結合を考慮し、承認手順を定めます。

7. 外部連携要件

外部連携は、連携先、目的、方向、方式、項目、頻度、タイミング、認証、暗号化、再送、重複防止、タイムアウト、監視、責任分界を定義します。API、ファイル、手動取込の選択理由も記録します。

連携先が停止した場合に、処理を保留するか、後で再送するか、職員へ通知するかを決めます。連携成功のHTTP応答だけでなく、業務データが受理されたかを確認します。時刻、コード体系、文字種、最大サイズの差も重要です。

連携仕様が未確定の場合は、仮定と確定期限を置きます。「他システムと連携可能」で終わらせず、誰が接続先事業者を調整し、試験環境・証明書・費用を準備するかを書きます。

8. 非機能要件

非機能要件は、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、環境、技術制約に分けます。目標値には測定条件と除外条件を付けます。

• 可用性：サービス時間、計画停止、稼働率、障害復旧目標
• 性能：対象処理、同時利用、データ量、応答時間、バッチ完了時刻
• 拡張性：利用者・データ増加、増強方法、上限、リードタイム
• バックアップ：対象、頻度、保持、暗号化、復元試験
• 監視：死活、性能、容量、セキュリティイベント、通知先
• 保守性：変更手順、構成管理、パッチ、検証、本番反映
• 継続性：災害、通信断、クラウド障害時の代替業務と復旧

稼働率の計算式、計画停止を含むか、測定場所を定義します。RTOとRPOは業務影響分析に基づき、全機能へ最高水準を一律要求しないことも費用適正化につながります。

9. セキュリティと個人情報保護要件

認証、認可、最小権限、職務分離、特権管理、暗号化、ログ、脆弱性、インシデント、委託先管理を定義します。異動・退職・休職・委託終了時のアカウント変更期限、定期棚卸しも重要です。

ログは、誰が、いつ、何を、どの対象へ行い、結果がどうだったかを記録します。保存期間、改ざん防止、閲覧権限、検索、時刻同期、監視、削除を定義します。ログそのものに個人情報が含まれるため、無制限保存は避けます。

脆弱性対応は、情報収集、評価、修正期限、緊急パッチ、試験、報告を定めます。インシデント時は、連絡先、初報期限、証拠保全、封じ込め、復旧、原因分析、再発防止、個人情報担当等への連携を整理します。具体的な準拠規程と版は発注者が確認し、一般的な雛形をそのまま適用しません。

10. アクセシビリティとユーザビリティ

対象とするウェブアクセシビリティ基準、適合目標、対象範囲、試験方法、公開後の維持を要件化します。色だけに依存しない表示、キーボード操作、フォーカス、読み上げ、代替テキスト、拡大、エラー特定、入力支援、時間制限への配慮を扱います。

高齢者、障害者、外国人、スマートフォン利用者、低速回線、デジタルに不慣れな人を想定します。利用者テストでは、参加者への安全と個人情報に配慮し、同意を得ます。分かりやすい言葉、やさしい日本語、多言語の品質確認も検討します。

アクセシビリティを納品直前の検査にせず、プロトタイプ段階から確認します。不適合が見つかった場合の修正、例外承認、代替手段、公開情報を定めます。

11. 移行・教育・運用要件

移行要件では、対象データ、提供形式、品質、変換、リハーサル、照合、切替、戻し、旧システム参照を定義します。件数一致だけでなく、関連、添付、権限、履歴、検索の確認基準を設けます。個人情報を扱う移行環境、受渡し、消去も要件です。

教育要件では、対象者、到達目標、形式、教材、演習、実施時期、異動者教育、理解度確認を定義します。マニュアルは利用者用、管理者用、運用用を分け、更新責任と編集可能形式を決めます。

運用要件には、サービスデスク、監視、障害、問題、変更、リリース、構成、アカウント、バックアップ、定期報告を含めます。自治体と事業者のRACIを作り、夜間休日や重大障害時の意思決定者を明示します。

12. 受入基準とトレーサビリティ

各要件には検証方法を付けます。実演、試験、文書確認、分析のどれで受け入れるかを決め、合否基準を客観化します。「問題なく動作すること」ではなく、入力、期待結果、環境を記載します。

変更要求が出たら、要件、設計、試験、費用、スケジュール、運用への影響を分析し、承認後に基準版を更新します。口頭合意だけで変更しないでください。版ごとの差分と承認者を記録します。

12-1. 自治体特有の調達・公平性要件

要件定義は、特定製品を選ぶための説明ではなく、行政目的を公平に実現できる条件を定める活動です。製品名や独自機能を要件にする必要がある場合は、相互運用性、既存資産、移行リスク等の合理的な理由を記録し、同等品や代替方式を認められるか検討します。市場調査で得た一社だけの仕様を、一般的な必須要件のように転記しないでください。

調達前の情報提供依頼や対話を行う場合は、参加条件、回答の扱い、秘密情報、調達への影響を明確にし、自治体の手続に従います。事業者から得た価格や技術情報を無断で他社へ開示せず、一方で調達に必要な共通条件は公告資料へ公平に反映します。質問回答で要件が変わった場合は、全関連文書と見積条件を更新します。

成果物の権利、データの利用、ソースコード、第三者ライセンスは、運用継続と将来の再調達を考慮して要件化します。「著作権をすべて移転」または「事業者にすべて帰属」と一律に決めず、自治体が保守・改修・引継ぎに必要な利用権と、既存知的財産の保護を整理します。

12-2. 合意形成と説明責任

自治体システムは複数部署、住民、外部機関に影響します。要件決定会議では、決定事項だけでなく、採用しなかった案、理由、影響を記録します。特に、本人確認の強度、保存期間、自動判定、オンライン限定化など住民の権利や負担に関わる判断は、業務効率だけで決めません。

公開すべき情報と非公開にすべきセキュリティ情報を分け、議会、監査、住民への説明に使える要約を用意します。重大な仕様変更では、影響を受ける部署や利用者への周知、既存手続との並行期間、問い合わせ窓口を要件に含めます。苦情、誤判定、データ訂正を受け付け、処理状況と結果を説明できる業務を設計してください。

要件の根拠資料は、基準日と版を含めて保存します。制度改正が予定される場合は、現行要件と将来対応候補を分け、施行日や正式仕様が未確定の事項を確定要件として扱いません。稼働前に最新情報を再確認し、必要なら正式な変更管理を行います。

13. 契約終了・運用引継ぎ要件

契約終了時に、データ、添付、設定、ログ、運用手順、構成、障害・変更履歴、未解決課題をどの形式で引き渡すか定義します。後継事業者への説明、並行期間、追加抽出、消去証明、アカウント停止、秘密情報返却を扱います。

オープンな形式やデータ辞書を要求し、再調達時の比較可能性と移行可能性を確保します。ただし知的財産や第三者製品の制約も確認し、提供できる成果物と利用条件を契約と一致させます。

終了時要件は将来の問題ではありません。導入前に受入基準と費用条件を定めることで、ベンダーロックインを抑え、住民サービスを継続できます。

重要事項

1. 行政目的から受入試験まで要件を追跡可能にする。
2. 現行業務の例外と非公式な作業も確認する。
3. システム化範囲、対象外、責任境界を明示する。
4. 機能要件には利用者、条件、結果、例外を記載する。
5. 非機能値には測定条件と業務上の根拠を付ける。
6. 個人情報は目的に必要な最小限とし、保存・消去を定義する。
7. アクセシビリティと代替手段を上流から設計する。
8. 移行、教育、運用、契約終了を要件に含める。
9. 未決事項へ責任者と期限を付ける。
10. 最新の法令、条例、国のガイドライン、庁内規程を確認する。

禁止事項

• 要件定義書を製品機能一覧のコピーにする。
• 「柔軟に」「十分に」「必要に応じて」だけで合否基準を作らない。
• 現場確認なしに管理職の意見だけで将来業務を決める。
• すべての要件を最優先として費用と期間の現実性を失う。
• 本人の救済や職員確認なしにAI判断へ全面依存する。
• 必要性を説明できない個人情報を収集・無期限保存する。
• 正常系だけを定義し、取消し、誤り、障害、災害を無視する。
• 未決事項を隠したまま固定価格・固定納期を求める。
• 口頭やチャットだけで要件を変更する。
• 一般的な雛形を最新法令等の確認なしにそのまま採用する。

具体的な要件テンプレート

要件ID：［一意なID］
要件名：［短く識別可能な名称］
目的・根拠：［行政目的、業務課題、規程等］
利用者：［住民、職員、管理者、外部機関等］
事前条件：［実行前の状態］
要件本文：システム／運用は、［条件］のとき［処理］できること。
正常結果：［期待する結果］
例外・エラー：［想定外入力、障害、取消し等］
データ：［入力、出力、保存、ログ］
権限・セキュリティ：［閲覧、更新、承認等］
優先度：［必須／重要／希望］
受入基準：［環境、操作、期待値、測定方法］
関連要件：［ID］
未決事項：［責任者、期限］

実務チェックリスト

目的・業務

• [ ] 行政目的とシステム導入目的を区別した
• [ ] 現状値、目標、測定方法、測定時期を定義した
• [ ] 正常系、例外、繁忙期、災害時の業務を確認した
• [ ] 窓口・郵送・電話・オンラインの全体を設計した
• [ ] デジタル利用が困難な人の代替手段を確保した

要件品質

• [ ] 全要件に一意なID、根拠、優先度、責任者がある
• [ ] 曖昧語を測定可能な条件へ置き換えた
• [ ] 機能、データ、連携、非機能の整合を確認した
• [ ] 各要件に受入方法と合否基準がある
• [ ] 未決事項に期限と決定者がある

公共性・継続性

• [ ] 個人情報の利用目的、最小化、保存、消去を定義した
• [ ] 認証、権限、ログ、脆弱性、インシデントを定義した
• [ ] アクセシビリティの対象、試験、維持を定義した
• [ ] 移行、教育、運用保守の責任分担を定義した
• [ ] 契約終了時のデータ返却と後継引継ぎを定義した
• [ ] 最新の条例、国のガイドライン、自治体規程を確認した

FAQ：自治体向け要件定義書のよくある質問

Q1. 要件定義書と調達仕様書の違いは何ですか。

要件定義書は行政目的、業務、機能、非機能、受入条件を具体化します。調達仕様書は調達対象、契約条件、提案条件を含む発注文書です。案件により統合されますが、目的と粒度を意識します。

Q2. 要件定義は誰が承認しますか。

原課だけでなく、情報政策、セキュリティ、運用等の責任者を要件分野ごとに定め、最終承認者を明確にします。事業者任せにせず、自治体が業務要件を決定します。

Q3. 曖昧な要件をなくすコツは何ですか。

利用者、条件、入力、処理、結果、例外、測定方法を質問します。「迅速」は何秒か、「大量」は何件か、「適切な権限」はどの役割かを具体化します。

Q4. パッケージ導入でも要件定義は必要ですか。

必要です。ただし製品を一から設計するのではなく、標準機能へ業務を合わせる範囲、設定、追加開発、対象外、移行、運用を明確にします。

Q5. 法令要件はどう書けばよいですか。

根拠、適用範囲、確認者、基準日を記載します。法令やガイドラインは改定されるため、名称だけを固定せず、設計・稼働前に最新版を確認する工程を置きます。

Q6. 非機能要件の数値は高いほどよいですか。

高水準ほど費用や複雑性が増える場合があります。業務影響、利用時間、代替手段、データ量に基づき、必要十分な目標と測定条件を定めます。

Q7. AI機能の受入基準はどう作りますか。

対象データ、評価用データ、正確性だけでなく、有害出力、偏り、説明、人の確認、停止、ログを評価します。確率的な出力に単純な完全一致だけを要求しない設計が必要です。

Q8. アクセシビリティ要件はいつ確定しますか。

要件定義時に対象基準と範囲を決め、設計、実装、試験で継続確認します。納品直前だけの診断では、修正費と日程リスクが大きくなります。

Q9. 要件変更はどこまで認めますか。

変更自体を禁止せず、理由、影響、優先度、費用、納期を分析し、権限者が承認します。基準版と履歴を管理し、設計・試験へ反映します。

Q10. 要件定義の完了条件は何ですか。

全要件の状態、未決事項、前提、受入基準、優先度、責任者が明確で、関係者が承認し、見積とスケジュールの更新が完了していることです。

まとめ

自治体向け要件定義書の作り方は、機能を多く列挙することではなく、行政目的を検証可能な条件へ翻訳することです。住民と職員の業務、データ、連携、非機能、個人情報保護、セキュリティ、アクセシビリティ、移行、運用引継ぎを一体として定義してください。要件IDと受入基準で設計・試験まで追跡し、未決事項と変更を透明に管理します。案件時点の最新の法令、条例、国のガイドライン、自治体規程を確認し、発注者と事業者が同じ完成像を共有できる自治体向け要件定義書にすることが成功の土台です。