第１章 本仕様書について
１．背景
自治体の情報システムは、これまで各自治体が独自に構築・発展させてきた結果、その発注・維持管理や制度改正対応等について各自治体が個別に対応しており、人的・財政的負担が生じている。特に人口規模が一定以上の自治体を中心に、同一ベンダのシステムを利用する自治体間でもシステムの内容が異なることが多く、クラウド上のサービスを利用する方式への移行の妨げとなっている。さらに、自治体ごとに様式・帳票が異なることが、それを作成・利用する住民・企業・自治体等の負担につながっている。
また、中長期的な人口構造の変化に対応した自治体行政に変革していくためにも、自治体の情報システムに係る重複投資をなくして標準化・共同化を推進し、自治体行政のデジタル化に向けた基盤を整備していく必要がある。
そうした問題意識から、自治体行政のデジタル化に向け、自治体の情報システムや様式・帳票の標準化等について、自治体、ベンダ及び国が協力して具体的な検討を行う場として、令和元年（2019年）８月から、総務省において、自治体システム等標準化検討会（座長：庄司昌彦武蔵大学社会学部教授）が開催され、さらに詳細な議論を行う場として分科会（分科会長：後藤省二株式会社地域情報化研究所代表取締役社長）が開催されている。
令和２年９月11日に住民記録システム標準仕様書【第1.0版】が公表されて以降、デジタル・ガバメント閣僚会議の下で開催された「マイナンバー制度及び国と地方のデジタル基盤抜本改善ワーキンググループ」における議論も踏まえ、令和２年12月25日の「デジタル・ガバメント実行計画」では、地方公共団体の主要な17業務について、システムの標準仕様を作成すること、地方公共団体の情報システムの標準化・共通化を実効的に推進するための法律案を令和３年通常国会に提出すること、標準化の目標時期を令和７年度とすること等が閣議決定された。このことを受けて、第204回通常国会では、標準化法が可決成立した。
また、令和３年12月24日に閣議決定された「デジタル社会の実現に向けた重点計画」では、基幹業務システムを利用する原則全ての地方公共団体が、目標時期である 令和７年度（2025年度）までに、ガバメントクラウド上に構築された標準化基準に適合した基幹業務システムへ移行する統一・標準化を目指すこととされた。標準化対象事務は、標準化法の趣旨を踏まえ、情報システムによる処理の内容が地方公共団体において共通しているかという観点等から、累次の閣議決定において示されてきた17業務に、印鑑登録及び戸籍、戸籍の附票事務の３業務を加えることとされた。また、戸籍の附票は、住民票と戸籍の情報をつなぎ合わせ、もって住民票の記載の正確性を担保する機能を果たすとともに、在外選挙人名簿への登録等の選挙事務に伴う公証事項のほか、デジタル手続法による改正後の法では、住民票コード等が戸籍の附票の記載事項に追加され、国外転出者の本人確認情報の公証を担うこととなり、市区町村間の情報連携手法がデジタル化されることから、このことを前提とした機能の整備を進める必要がある。
これらを踏まえ、戸籍附票システム標準仕様書（以下「本仕様書」という。）は、戸籍の附票を規定する法及び事務処理要領を基礎にしつつ、「住民記録システム標準仕様書【第2.0版】」を参考に、策定されたものである。
２．目的
本仕様書は、標準化法第５条第１項に基づく地方公共団体情報システム標準化基本方針（令和４年10月）（以下「基本方針」という。）を踏まえ、同法第６条第１項に規定する基準に基づき、作成するものである。
３．対象
（１）対象自治体
本仕様書の対象自治体は、全ての市区町村とする。
なお、本仕様書における「市区町村」の区とは、特別区のことであるが、法令で指定都市の区及び総合区が市と、区長及び総合区長が市長とみなされる場合は、法令と同様の扱いとする。ただし、本文中の各項目に記載のとおり、以下の区分に応じて異なる要件としているものもある。
・指定都市
・一般市区町村
また、指定都市においては、第３章 機能要件の中で示す５（証明）については区を越えた処理を可能とする。
（２）対象分野
本仕様書が規定する対象分野は、おおむね住民基本台帳制度上の戸籍の附票事務と対応しているが、一部については本仕様書において規定していない。例えば、法第19条第１項に基づく通知のうち住基ネット回線を通じて実施する部分については、別途「戸籍附票システム改造仕様書」に基づく仕様があることから本仕様書の対象外とする。
（３）対象項目
本仕様書では、以下の項目について規定する。
・標準化の対象範囲（第２章）
・機能要件（第３章）
・様式・帳票要件（第４章）
・データ要件（第５章）（※）
・連携要件（第３章及び第５章の一部）（※）
・非機能要件（第６章）
・業務フロー（別紙１）
・ツリー図（別紙２）
以下の項目については原則として規定しない。ただし、カスタマイズの発生源になっている場合等についてはこの限りでない。
・画面要件
・ヘルプやガイドの具体的内容等、業務遂行に必須ではなく専ら操作性に関する機能
基本方針を踏まえ、このうち、機能要件、様式・帳票要件及び連携要件はカスタマイズの発生源になっている部分であるため、本仕様書の対象とすることとした。また、機能要件、データ要件及び連携要件（※）は、ベンダ間での円滑なシステム更改を阻害している部分であるため、本仕様書の対象とすることとした。さらに、デジタル社会の実現に必要な機能については、これらの要件の中に反映した。
なお、様式・帳票要件では、戸籍附票システムを標準化するという観点から、多くの自治体において戸籍附票システムから出力する様式・帳票（例：戸籍の附票の写し）について規定することとし、多くの自治体において戸籍附票システムから出力するとは限らない様式・帳票（例：戸籍の附票の写しの請求書）については規定しないこととした。
デジタル社会を見据えた対応
本仕様書は、これからのデジタル社会においてあるべき姿（電子化・ペーパーレス化）を視野に標準を設定するとしつつも、これからのデジタル社会においてあるべき姿にそのまま即したものには必ずしもなっていない。
また、これからのデジタル社会を見据えれば、実務やシステムの前提となる制度自体を見直すべきであるという考え方もあり得る。しかし、そうした制度自体の検討については、一朝一夕にできるものではなく、あまりにも現在の実務から遊離した仕様書となれば、実効性が失われる。
そこで、本仕様書としては、電子化・ペーパーレス化も含め、これからのデジタル社会においてあるべき姿を視野に入れつつ、現行制度の下で、多くの自治体が支障なく対応できるものについて、できる限り盛り込むこととした。
他方、デジタル社会を見据え、様々な社会環境の変化に対応するためには、本仕様書の作成後、実務やシステムの前提となる制度を随時見直していくことが重要であり、制度の見直しとともに本仕様書を改定していくことが求められる。
４．本仕様書の内容
（１）本仕様書の構成
第１章では、本仕様書の背景、目的、対象及び内容について記載している。
第２章では、標準化の対象範囲を記載している。
第３章、第４章、第５章及び第６章では、それぞれ、戸籍附票システムが備えるべき機能要件、様式・帳票要件、データ要件及び非機能要件について記載している。「（２）標準準拠の基準」にあるように、これらの章は、パッケージシステムが本仕様書に準拠するための判断基準となるものであり、言わば本仕様書の本体部分である。
第７章では、本仕様書において用いている用語について、解釈の紛れがないよう、定義している。
また、別紙に業務フロー及びツリー図を記載している。業務フローは、第３章で規定する機能要件が業務上どのように位置づけられ、有効に機能するのかについて自治体及び事業者の共通理解を促すため、それらに対応したモデル的な業務フローを示している。ここで示した業務フローは、実際の各自治体における業務フローを拘束するものではないが、現在の業務フローでは、本仕様書における機能要件どおりの機能で業務を行うことが難しいと考える自治体は、現在の業務フローを本仕様書に示す業務フローに寄せる（BPR）ことで、本仕様書における機能要件どおりの機能で業務を行うことが期待される。ツリー図は、戸籍の附票に係る業務における機能要件の一覧性を高め、標準化の対象となる業務を明確化するため、業務フローにひもづいた形式で記載している。
（２）標準準拠の基準
本仕様書の対象は「第１章 ３．対象 （２）対象分野」のとおりとしており、この対象範囲において定義すべき機能について、【実装必須機能】【実装不可機能】【標準オプション機能】の３類型に分類した。可能な限り３類型のいずれに該当するか分類をした上で、定義すべき機能の範囲内で分類されていない機能は、カスタマイズ抑制、ベンダ間移行の円滑化の観点から、実装不可機能と同様のものとして位置付ける。
パッケージシステムが本仕様書に準拠するためには、第３章、第４章及び第５章に規定する【実装必須機能】をいずれも実装し、【実装不可機能】をいずれも実装しないことが必要である。【標準オプション機能】は、実装しても、実装しなくても、実装した上で自治体が利用を選択できることとしても、いずれも差し支えない。３分類のいずれにも位置付けられていない機能については、原則【実装不可機能】として扱うものとする。ただし、自治体やベンダの創意工夫により新たな機能をシステムに試行的に実装させて機能改善の提案を行う場合であって、他の地方公共団体においても当該機能の必要性が高いと考えられるものについては、当該機能の取扱いを標準仕様書の作成・更新過程において検討することとし、必要に応じて標準仕様書に規定する。その間、実験的に実装を希望する地方公共団体は、費用対効果の検討結果を他の地方公共団体と共有することを前提とする等、標準仕様書の検討に資するよう取り組むこととし、実装は標準準拠システムと疎結合で構築する。
また、本仕様書に準拠しているかどうかは、「３（１）対象自治体」で示した指定都市及び一般市区町村の類型ごとに判断される。特に明記しない限り、２類型全てに当てはまる要件として記載しており、必要に応じて、「指定都市においては、～～」、「（一般市区町村においては、標準オプション機能とする。）」のように記載している。
なお、実装必須機能のうち、法令上必ず使用しなければならない機能と必ずしも使用しなくてもよい機能があり、個別に判断する必要がある。また、実装に当たっては、取り込んだ通知の保存年限等、当然に法令に沿った機能及び運用を満たす必要がある。
氏名の振り仮名について、本仕様書においては、法第17条における戸籍の附票の記載事項とした令和５年改正法の施行日以降を想定した記載としている。当該令和５年改正法施行日より前において、市区町村が戸籍の附票の整理のために管理上、必要であるということで便宜的にシステム上保持されている取扱いとなることに留意が必要である。
（３）想定する利用方法
標準化法第８条第１項では、「地方公共団体情報システムは、標準化基準に適合するものでなければならない。」とされており、本仕様書で規定された内容は、標準化基準として位置付けられる予定のものである。したがって、本仕様書については、
・今後、整備予定の「ガバメントクラウド」上において、各ベンダが、本仕様書に準拠しているシステムを提供する
・各自治体は、本仕様書に準拠しているパッケージシステムをカスタマイズすることなく利用する
ことを想定している。
自治体においては、人口減少による労働力の供給制約の中、システムについて十分な知見がなくても、負担なくシステムを調達し、利用できることが望ましい。自治体としては、標準化後にシステム更改を行う際は改めて本仕様書に示した個別の要件を一々提示してRFI （request for information）やRFP （request for proposal）
、更にはFit & Gap分析を行って調達するのではなく、単に、本仕様書に準拠しているパッケージシステムであることを要件に付するだけで、調達を行うことができ、カスタマイズをすることなく利用できることを想定している。
本仕様書は、本仕様書における機能さえあればカスタマイズなしで支障なく業務が行えるようになるよう、実装必須機能と実装不可機能をその理由とともに整理したものである。そのため、自治体内での検討や自治体・ベンダ間の協議の際に、仮に本仕様書における機能と異なる機能が必要ではないかという議論があった場合、限られた人員、財源の中で、果たして当該自治体だけ特別に必要な機能なのか、本仕様書が想定する業務フローを参照し、効率的な業務運用への見直しが必要ではないか、という観点から、本仕様書における必要／不要の整理を知るための資料として参照することも想定している。
（４）本仕様書の改定
本仕様書については、制度改正時のほか、戸籍情報システムの標準仕様書（法務省所管）に変更が生じた場合、自治体やベンダからの創意工夫によるシステムの機能改善等の提案がある場合や新たな技術が開発される等デジタル化の進展等がみられる場合にも、関係者の関与の下で改定することを想定している。とりわけ、制度改正により本仕様書を改正する必要がある場合は、制度の施行時期を勘案して改定する。改定後の本仕様書に基づいて、ベンダがクラウド上で一括してシステムを改修することにより、制度改正等ごとに個々の自治体が個別にベンダと協議して改修を行う必要がなくなると想定される。
各自治体の調達仕様書の範囲との関係
本仕様書を用いることにより、戸籍の附票事務を運用することは可能であり、本仕様書の対象範囲については本仕様書に記載された内容で調達する必要がある。
しかしながら、各自治体においては、本仕様書の対象範囲外の機能や戸籍情報システム等と併せて調達すること、また本仕様書に規定されていない非機能要件を備えること等も想定され、各自治体の調達仕様書の範囲と標準仕様書の範囲は必ずしも一致しないと考えられる。この場合であっても、各自治体の情報システムの調達において、本仕様書の範囲の業務について本仕様書に記載された内容で調達する限りにおいては、このような対応も許容される。
また、戸籍附票システムについては、戸籍情報システムに同梱されたパッケージを調達することが主流となっているため、戸籍情報システムとアプリケーションモジュールやデータベース等を共有するシステム構成とすることも考えられるが、戸籍の附票事務の独立性が確保される限り、このようなシステム構成についても許容される。例えば、審査・決裁機能について同じアプリケーションモジュールを活用し、同時に処理を実施することは許容するが、戸籍情報システムの審査・決裁機能のみをもって戸籍附票システムの審査・決裁機能とすることは許容しない。また、データベースについても、戸籍情報システムで管理する情報を参照する場合は共通項目としても問題ないが、戸籍附票システムにて独自に管理・更新が必要な項目については個別に備える必要がある。
【戸籍情報システムとシステム構成を共有することを許容する項目】
第３章 機能要件
1.1.5 空欄
1.1.6 年月日管理
1.1.7 年月日の表示
1.1.9 本籍・筆頭者
1.1.15 振り仮名
1.3.1 入力場所・入力端末
1.3.2 住所辞書管理
1.3.3 和暦・西暦管理
1.3.4 公印管理
1.3.5 交付履歴の管理
1.3.6 認証者
2.1.1 検索機能
2.1.2 検索文字入力
2.2.1 異動履歴照会
2.2.2 交付履歴照会
2.2.3 文字コード照会等
2.3.1 キーボードのみの画面操作
3.1 異動・発行・照会抑止
4.0.3 審査・決裁
5.6 公印・職名の印字
5.7 公用表示
5.8 文字溢れ対応
10.2 アクセスログ管理
10.3 操作権限管理
10.4 操作権限設定
10.5 ヘルプ機能
10.7 印刷
30.2 文字
第６章 非機能要件