令和8年度（債務）山元町住民情報系システム標準化対応業務委託公募型プロポーザルの実施について

令和8年度（債務）山元町住民情報系システム標準化対応業務委託公募型プロポーザルの実施について 1令和８年度(債務)山元町住民情報系システム標準化対応業務委託公募型プロポーザル調達仕様書山元町i目 次１ 本業務の概要.. 1(1) 件名.. 1(2) 背景と目的.. 1(3) 業務の概要.. 1(4) 契約形態.. 1(5) 調達範囲.. 2(6) 作業場所.. 4２ 導入計画.. 5(1) 基本方針.. 5３ 期間.. 6(1) 本業務の契約期間.. 6(2) 次期システム稼働期間.. 6(3) 想定スケジュール.. 6４ 成果物.. 7(1) 本業務における成果物.. 7(2) 成果物の納入方法.. 7(3) 知的財産権の帰属.. 7５ 業務要件.. 8(1) 機能要件及び帳票要件.. 8(2) 連携要件.. 8(3) 国の示す共通機能にかかる要件.. 9６ 非機能要件.. 10(1) 非機能要件の前提条件.. 10(2) 非機能要求事項.. 10７ システム稼働環境(プラットフォーム)要件.. 11(1) ガバメントクラウドの設定.. 11(2) ソフトウェア要件.. 11(3) ハードウェア要件.. 11(4) 業務用端末.. 11(5) ネットワーク要件.. 12(6) システム環境.. 12(7) 認証方法.. 12８ セキュリティ要件.. 13９ システム導入に付随する役務要件.. 13(1) 基本方針.. 13ii(2) データ移行に係る補足.. 13１０ 運用保守要件.. 15(1) 基本方針.. 15１１ サービスレベル定義.. 15(1) 基本的な考え方.. 16(2) 努力目標型.. 16(3) SLAモニタリング報告.. 16(4) サービスレベル向上の取組み.. 16１２ 標準化基準への適合性検証.. 17iii＜調達仕様書 別紙＞別紙１ 調達範囲一覧別紙２ 成果物一覧別紙３ 役務・運用保守要件一覧別紙４ SLA要求一覧別紙５ 機能要件別紙６ 帳票要件別紙７ 非機能要件別紙８ 連携要件別紙９ マニュアル等の提出を求める業務一覧別紙10 評価項目、評価基準及び配点表[※] 本仕様書及び付属資料の本プロポーザル以外の使用、複製、転載を禁ずる。 1１ 本業務の概要(1) 件名令和8年度(債務) 山元町住民情報系システム標準化対応業務委託(2) 背景と目的「地方公共団体情報システムの標準化に関する法律(令和３年法律第40号)」が令和３年９月１日に施行されたことにより、各自治体は住民記録や税業務を含む20の業務システムを国の策定する標準仕様に準拠したシステム(以下「標準準拠システム」という。)に令和７年度末を目標時期として移行することが求められている。 上記の国の方針に基づき、本町においては、令和７年度までに標準化対象業務システムを標準準拠システムに切り替えることを目指していたが、一部業務を除いて令和９年度中に標準化対象業務システムを標準準拠システムに切り替えることを目指している。 また、標準準拠システムは、国の準備するガバメントクラウド(または受託者が提供する環境で本町が求める要件と同等の水準を満たすもの)上に構築されたものを導入する予定としている。 (3) 業務の概要本委託業務では、主に次の業務を行う。 ア 標準準拠システム及び関連システムの導入業務イ 標準準拠システムの運用・保守業務(標準準拠システムへの切替後、稼働日を含む当年度内の運用保守業務)※導入システムは、導入後５年間の利用期間を想定(4) 契約形態契約形態は次のとおりである。 ・ 本調達は、「１(5)調達範囲」に含む物品・役務等を一括で調達する。 ・ 本調達における支払いは、確保している予算の範囲で、契約後に定めるプロジェクト計画に対する業務進捗に応じて行うものとする。 2(5) 調達範囲本調達における調達範囲を次に示す。 なお、調達範囲については別紙１ 調達範囲一覧にも記載する。 ア 標準準拠システム導入次に示す業務を遂行するため、標準準拠システムを導入すること。 なお、戸籍・戸籍附票並びに障害者福祉に関しては現行事業者にて標準準拠システムへ移行済のため対象外とする。 また、本町では就学事務システム(就学援助)、生活保護システムについてはシステム未導入である。 ＜標準準拠システム 対象業務＞項 番対象システム 対象業務1 住民記録システム 住民基本台帳2 印鑑登録システム 印鑑登録3 国民年金システム 国民年金4 選挙人名簿管理システム(選挙人名簿管理、期日前・不在者投票管理、当日投票管理が対象。)選挙人名簿管理5 就学事務システム(学齢簿編製等) 学齢簿編製6 税務システム 個人住民税固定資産税法人住民税軽自動車税収納滞納7 国民健康保険システム 国民健康保険8 後期高齢者医療システム 後期高齢者医療9 健康管理システム 健康管理10 児童手当システム 児童手当11 子ども・子育て支援システム 子ども・子育て支援イ 関連システム導入次に示す業務を遂行するため、以下の関連システムを導入すること。 ただし、「１(5)ア標準準拠システム導入」のシステム内で下記システムに係る機能を実現できる場合、別個に導入する必要はない。 ＜関連システム 対象業務＞項番 対象システム 対象業務1 医療費助成システム 医療費助成2 土地評価システム 固定資産税3 概要調書システム 固定資産税3ウ ガバメントクラウドの設定本町においては、標準準拠システムの提供とガバメントクラウド運用管理補助者を同一事業者が兼務することを予定している。 従って、提案する標準準拠システムを導入・運用するために必要なガバメントクラウドの設定等、ガバメントクラウド運用管理補助者に求められる全ての作業を本業務内で漏れなく実施すること。 なお、「ガバメントクラウド単独利用方式」「ガバメントクラウド共同利用方式」に関しては、本町の人口規模・業務規模に十分対応できるのであれば、いずれの方式であっても可とするが、いずれの場合においても採用した方式の根拠を示すことと、標準準拠システムの利用にあたり本町に求められるガバメントクラウド、標準準拠システムにかかる全ての役務、運用保守業務等を本調達の範囲とする。 エ ネットワークガバメントクラウド接続ゲートウェイからベンダ VPC までの回線及び受託者拠点とガバメントクラウドを繋ぐネットワーク(システム稼働後の運用保守用ネットワーク)を本調達に含めること。 ※本町とガバメントクラウド接続サービスを繋ぐネットワークについては現行のネットワーク運用管理補助者に対して調達を行う予定である。 オ システム導入に付随する役務「１(5)ア 標準準拠システム導入」に示したシステムの導入に付随する役務として業務要件分析、業務システム設計・構築、稼働環境設計・構築、ネットワーク設計・構築、端末等の設定、テスト、データ移行、職員研修、本番切替(稼働確認)等を実施すること。 ただし、提案する標準準拠システムやシステム構成によって不要な作業が生じ、かつ本町にとっての不都合が生じないと認められる場合には、いずれかの作業を対象外とすることを妨げるものではない。 なお、詳細な要件は「別紙３ 役務・運用保守要件一覧」を参照すること。 カ ハードウェア・ソフトウェアガバメントクラウド以外に「１(5)ア 標準準拠システム導入」に示したシステムの稼働に必要な端末および専用のハードウェア(サーバ機器、プリンタ、ネットワーク機器、その他本書の要件を満たすために必要なハードウェア)がある場合、該当するハードウェアを本調達に含めること。 (本町内部ネットワークや標準化対象業務で利用するプリンタについては本調達の対象外とする。端末については項番クを参照。)また、「１(5)ア 標準準拠システム導入」に示したシステムの稼働に必要なソフトウェア(OS、ミドルウェア、その他本書の要件を満たすために必要なソフトウェア)を導入すること。 システム稼働後契約期間終了までのハードウェア保守・ソフトウェア保守を実施すること。 キ システム運用・保守業務システム及び稼働環境(ガバメントクラウド)の運用保守に係る役務(ガバメントクラウド運用管理補助者役務)として保守、業務運用(バッチ運用等の各種オペレーション業務等)、システム運用(定常運用、監視、ログ管理等)を実施すること。 シス4テム運用・保守を実施するにあたり、クラウド上のサービスを利用することを想定している場合は、そのサービスの利用料も本調達に含むこと。 また、帳票印刷、封入・封緘等付帯業務も含むこととする。 また、ガバメントクラウド運用管理補助者役務に必要な接続回線等の関連サービスも本調達に含める。 なお、運用保守に係る役務の詳細な要件は「別紙３ 役務・運用保守要件一覧」を参照すること。 ク 業務用端末標準準拠システムを使用するための業務用端末および動作に必要な OS、ソフトウェア、周辺機器を本調達に含めること。 業務用端末については、提案システムを動作可能なスペックの端末とする。 なお、現在、本町が想定する業務用端末のスペックを参考に示す。 ただし、提案システムが問題なく動作すればこの限りではない。 なお、業務用端末については導入時期が令和 9 年度となる想定であるため、本プロポーザル実施時点において予期することのできない物価又は為替相場の著しい変動が生じ、契約金額が不適当となったと発注者が認める場合には、客観的な指標等を踏まえ、必要に応じて契約内容の変更について協議を行うことがある。 ＜本町が想定する参考スペックの例＞区分 バージョン 備考CPU Intel Core i5メモリ 16GBメモリストレージ 256GB HDD光学ドライブ DVD-ROMドライブ端末形態 ノート型パソコン画面解像度 1920×1080OS Windows 11関連ソフトEdge(推奨)その他必要なウイルス対策ソフト 等左記記載のもの以外に、提案システムを管理、動作するために必要な標準的なソフトウェアを含めること(6) 作業場所本業務における開発作業及び運用保守作業は、原則、受託者にて用意した作業拠点にて実施すること。 ただし、役場内で作業が必要な場合は、本町と協議の上、作業場所を設置することとする。 また、受託者自身で用意した作業場所で利用する端末及びセキュリティ対策を講じるた5めに必要な設備・機器等は本調達に含めること。 なお、受託者自身で用意した作業場所では、本町が管理する個人情報及び機密情報を取り扱う可能性があるため、「８ セキュリティ要件」に記載された内容を遵守すること。 加えて、作業着手前に具体的なセキュリティ計画を提出し、本町の承認を得ること。 また、本町が受託者の作業環境の確認、視察を行う場合は、真摯にこれに応じること。 ２ 導入計画(1) 基本方針ア 導入手法標準準拠システムに関しては、パッケージシステムの導入(標準仕様書に準拠していれば、他自治体にて稼働しているシステムをパッケージシステムとして本町に導入することも可)とする。 提案する製品は Web 型のシステムを選定し、最新のブラウザ(Microsoft Edge(推奨))に対応していること。 なお、サポート期限が切れているため、Internet Explorerは利用不可とする。 また、業務用端末(クライアント端末)にはソフトウェアのインストールは原則として認めない。 イ 標準仕様等への準拠受託者が導入するシステムは、原則、稼働日時点の最新の標準仕様書に記載された各要件の適合基準日を満たすこととする。 ただし、標準仕様書の改定による開発作業への影響等を考慮し、最新版の適合基準日を満たすことが難しい場合には、該当箇所を明らかにしたうえで代替手段等を含め本町と協議のうえ合意すること。 また必要に応じて国に対して経過措置申請を行うこと。 ＜国からの提示資料＞項番 資料名1 地方公共団体情報システム標準化基本方針(令和７年 12 月 24 日閣議決定)2 地方公共団体情報システムのガバメントクラウドの利用について【第 3.0版】3 地方公共団体の基幹業務システムの共通機能に関する標準仕様書【第 2.5版】4 地方公共団体情報システムデータ要件・連携要件標準仕様書【第4.1版】5 地方公共団体情報システム非機能要件の標準【第1.2版】6 標準仕様書間の横並び調整方針(令和６年８月７日)7 地方公共団体における情報セキュリティ監査に関するガイドライン(令和７年３月版)8 健康管理システム標準仕様書【第4.0版】9 住民記録システム標準仕様書【第6.1版】10 印鑑登録システム標準仕様書【第3.3版】11 税務システム標準仕様書【第5.0版】12 選挙人名簿管理システム標準仕様書【第1.4版】6項番 資料名13 介護保険システム標準仕様書【第4.1版】14 国民健康保険システム標準仕様書【第1.5版】15 後期高齢支援システム標準仕様書【第1.3版】16 国民年金システム標準仕様書【第1.3版】17 就学事務システム(学齢簿編製等)標準仕様書【第3.1版】18 就学事務システム(就学援助)標準仕様書【第4.0版】19 児童手当システム標準仕様書【第2.0版】20 子ども・子育て支援システム標準仕様書【第1.2版】また、上記に示した資料の改版又は新たな資料の追加等、国の計画が変更となった場合、本プロジェクトに与える影響を直ちに検討し、影響がある場合は、プロジェクト計画を速やかに修正すること。 なお、プロジェクト計画の修正に際し、必要に応じて、契約内容の変更を本町と協議するものとする。 加えて、上記に示した資料の改版又は新たな資料の追加等に対して、受託者が提案するシステムを対応させること。 契約期間内における対応に掛かる費用は本調達内で実施すること(別途追加費用を支払わないことを意味する)。 ウ ガバメントクラウドの利用受託者が提案する標準準拠システムは、原則、本稼働当初よりガバメントクラウドを利用することとする。 ３ 期間(1) 本業務の契約期間契約締結日から令和10年3月31日まで(2) 次期システム稼働期間令和10年1月4日(仮)から令和15年3月31日までの５年間なお、各業務システムの稼働日は、今後変動する可能性がある点に留意すること。 (3)想定スケジュール具体的なスケジュールについては契約後に本町と受託者による協議にて確定するものとするが、スケジュールの提案にあたっては以下の点を考慮すること。 ・ システム導入期間に想定外の事象が発生することも考慮し、各工程において余裕のあるスケジュールを策定すること・ 業務所管課との打ち合わせ・確認作業が必要な場合は業務の繁忙期を可能な限り避けること・ 次期システムへの移行期間は、令和9年12月24日(金)閉庁後から令和10年1月3日(月)までの閉庁期間に本番稼働に向けた移行を行う想定とする。 7４ 成果物(1) 本業務における成果物本業務において受託者が作成する成果物は「別紙２ 成果物一覧」のとおりとする。 なお、成果物の内容、本町への提示時期及び納入期限の詳細については契約締結後に作成するプロジェクト計画書で定め、本町の承認を得ること。 (2) 成果物の納入方法成果物は、各工程完了時に当該工程で作成したものを本町に納入すること。 なお、各工程完了時に納入する成果物については、プロジェクト計画書において本町と合意した期限までに納入することとし、納入前に本町のレビューを受け、本町の承認を得ること。 また、成果物は原則としてMicrosoft Office(Word、Excel又はPowerPoint)で作成し、電子媒体(CD-R、DVD-R等)で納入すること。 本町が要望した場合は、指定した部数を指定場所に紙媒体で納入すること。 なお、成果物の内容、本町への提示時期及び納入期限の詳細については契約締結後に作成するプロジェクト計画書で定め、本町の承認を得ること。 (3) 知的財産権の帰属 本調達に関し作成・変更・更新されるドキュメント類の著作権(著作権法(昭和 45年法律第48号)第21条から第28条に定めるすべての権利を含む)は、受託者が本調達以前より権利を保有していた、又は受託者が本委託業務以外の目的で作成した汎用性のある著作物に関する著作権は、受託者に留保され、その使用権、改変権を委託者に許諾するものとし、委託者は、これを本委託業務の納入物の運用その他の利用のために必要な範囲で使用、改変できるものとする。  本調達に係り発生した権利については、受託者は著作者人格権を行使しないものとする。  本調達に係り作成・変更・修正されるドキュメント類等に第三者が権利を有する著作物が含まれる場合、その著作物の著作権は、当該第三者に留保され、かかる著作物に使用許諾条件が定められている場合は、委託者はその条件の適用につき協議に応ずるものとする。  受託者は、本町の事前の書面による承諾を得た場合を除き、この契約によって生ずる権利又は義務の全部若しくは一部を第三者に譲渡、承継させてはならない。 ただし、売掛債権担保融資保証制度に基づく融資を受けるに当たり信用保証協会及び中小企業信用保険法施行令(昭和２５年政令第 350 号)第1 条の 3 に規定する金融機関に対し債権を譲渡する場合は、この限りではない。 その場合、速やかにその旨を書面により本町に届けなければならない。  本調達に係り第三者が有する著作物をめぐる紛争については、受託者の責任、負担において一切を処理すること。 8５ 業務要件本調達における業務に係る要件を次に示す。 (1) 機能要件及び帳票要件ア 機能要件及び帳票要件次期システムは国が策定する標準仕様書に記載されている仕様を満たすこととし、各実装類型の機能については以下のとおりとする。  実装必須機能は全て実装すること。  標準オプション機能は、「別紙５ 機能要件」及び「別紙６ 帳票要件」にて本町が実装を要望する機能を実装すること。 なお、類型①に当たる要件は、パッケージ標準機能として実装していない場合は代替案を記載すること。 代替案については、それぞれ内容を評価の上、本町の要望を十分に満たすと判断した場合には、「〇」として評価する。  本町が特に効率的なシステム操作を求める要件については「別紙９ マニュアル等の提出を求める業務一覧」に記載の通りとする。 なお、各業務が共通的にみたすべき仕様(地方公共団体情報システムデータ要件・連携要件標準仕様書、地方公共団体の基幹業務システムの共通機能に関する標準仕様書等)についても準拠すること。 標準仕様書の改版があった場合は、原則、本調達の範囲内で対応すること(別途追加費用を支払わないことを意味する)。 ただし、補助金対象となるような大規模な法令改正対応が本業務のシステム稼働日までに発生した場合、委託者の環境状況を踏まえて、対応を別途協議すること。 イ EUC機能要件、帳票要件に対してEUCによる実現を提案する場合は、EUCの環境設定作業(EUCサーバへのバックアップ・レプリケーション運用構築等)及び業務設定作業(抽出要件の整理、抽出条件の設定、起動タイミングの整理・設定(バッチジョブ化)等)についても本調達に含めること。 (2) 連携要件ア 連携要件標準準拠システムに関して、連携仕様は、デジタル庁「地方公共団体情報システムデータ要件・連携要件標準仕様書／機能別連携仕様(連携要件)」)に準拠したものであること。 標準準拠システムと、データセンター環境及び本町オンプレミス環境に構築されている既存システムとの連携に関して、以下に次期システム構成図を示す。 標準準拠システムと本町既存システムとのデータ連携については、ガバメントクラウドのオブジェクトストレージを用いたファイル連携を想定しているが、本町のネットワーク環境を踏まえたうえで効率的な連携方法を受託者より提案すること。 また、連携するデータの一覧については、「別紙８ 連携要件」で示す。 9図１ 次期システム構成図(案)(3) 国の示す共通機能にかかる要件「地方公共団体の基幹業務システムの共通機能に関する標準仕様書【第2.6版】」に示された各共通機能に関する利用方針は次のとおりとする。 ア 申請管理機能デジタル庁「地方公共団体情報システム共通機能標準仕様書【第2.6版】」に定める仕様で、マイナポータル等との接続に係る要件が定められている住民記録システム等に申請管理機能を実装すること。 イ 庁内データ連携機能デジタル庁「地方公共団体情報システム共通機能標準仕様書【第2.6版】」に定める仕様で、庁内データ連携機能を受託者が提案するシステムに実装すること。 ウ 住登外者宛名番号管理機能各業務の機能要件に定める仕様で、受託者が提案するシステムに実装すること。 エ 団体内統合宛名機能デジタル庁「地方公共団体情報システム共通機能標準仕様書 【第2.6版】」に定める仕様で、ガバメントクラウド上に団体内統合宛名機能を構築すること。 10オ EUC機能各業務の機能要件に定める仕様で、受託者が提案するシステムに実装すること。 カ 統合収納管理機能・統合滞納管理機能本町においては、統合収納管理機能・統合滞納管理機能は調達対象外とする。 ６ 非機能要件本調達における非機能に係る要件を次に示す。 (1) 非機能要件の前提条件非機能要件における前提となる事項、条件は次のとおりとする。 ア オンライン稼働時間システムのオンライン稼働時間(業務処理を実施する時間)は次に示すとおりとする。 なお、稼働時間外においても職員が参照可能な画面及びバッチ処理を実行可能な環境を準備すること。 (実現方法は受託者の提案内容に基づき協議のうえ決定する。)＜オンライン稼働時間＞曜日 通常時利用時間帯 備考平日 8時00分 ～ 20時00分 年末年始(12月29日～１月３日)を除く 土日祝祭日8時00分 ～ 13時00分(2) 非機能要求事項次期システムに求める非機能要求事項については、「別紙７ 非機能要件」を満たすこと。 11７ システム稼働環境(プラットフォーム)要件次期システムの稼働環境(プラットフォーム)に係る要件は次のとおりとする。 本仕様書の要求事項を満たしたうえで、業務アプリケーションのオンライン及びバッチ処理が安定稼働するガバメントクラウド設定・ハードウェア(受託者が必要と考える場合のみ)・ソフトウェアを提案すること。 なお、本システム構築に必要な受託者側の開発環境は受託者が用意すること。 また、ソフトウェアについては市場における汎用製品を選定し、利用期間中、開発事業者によるサポートが継続される製品の選定を前提とする。 サーバ仮想化技術の採用等により、機器構成の最小化及び高可用性の実現、規模の拡張縮減(スケールアウト及びスケールダウン)の実現に努めた提案とすること。 さらに、クラウド利用による季節変動も含めた処理能力の変動化によるスケールアウトやコストダウンなど、柔軟な提案を行うことが望ましい。 (1) ガバメントクラウドの設定本仕様書の要求事項を満たしたうえで、受託者が提案する業務アプリケーションが安定稼働するガバメントクラウドの設定・設計・構築すること。 なお、運用・保守要件等を満たすために必要な設定やソフトウェア(システム監視、遠隔監視、資源配布、文字情報配布、バックアップ、ログ取得・解析、ウイルス定義ファイル更新等に必要なもの)があれば、本調達に含めること。 ガバメントクラウドを使用するために掛かる費用のうち、本業務の受託者から本町に請求する必要がある利用がある場合には本調達に含めること。 (国から本町に請求される費用はこの限りではない。)(2) ソフトウェア要件ソフトウェアの選定にあたっては、受託者が知見を有し、構築実績のあるソフトウェアを基調として構成すること。 ライセンスは「４(1)非機能要件の前提条件」で示す内容に基づき、適切な数量を設計すること。 サーバや端末の更新があった場合であっても、契約期間内にシステムが適切に利用できるよう、ライセンスの管理を行うこと。 (3) ハードウェア要件ガバメントクラウド以外に本調達でハードウェアを導入する場合は、リソースや性能が過大にならないよう、仕様策定において性能的な根拠と事務処理規模等に応じたハードウェア選定の妥当性を明示すること。 業務アプリケーションの利用により、負荷が一時的に高まることが想定される場合は、冗長化による負荷分散を行うこと。 なお、サーバユニット内部における電源系統の障害に起因するシステム停止、データ消去又は破壊のリスクを低減可能な構成とするとともに、一部の電源系統に障害が発生しても、少ない停止時間で待機系サーバの縮退運転開始を可能とすること。 (4) 業務用端末本町で現在使用している業務用端末を更改予定のため、標準準拠システムを利用するための端末を本調達の対象とする。 12(5) ネットワーク要件ガバメントクラウド接続サービスからベンダ VPC までの回線及び、受託者拠点とガバメントクラウドを繋ぐネットワーク(システム稼働後の運用保守用ネットワーク)の構築及び利用に係る費用を本調達に含めること。 なお、本調達におけるガバメントクラウド利用時のアプリケーションサービスプロバイダ(ASP)とネットワーク事業者の責任分界点は以下を想定しており、(①ネットワーク事業者、②ASP)本調達においては②ガバメントクラウド接続ゲートウェイからベンダVPCまでの回線について調達の範囲としている。 ①の範囲は本町において令和 7 年度に調達をしているため、②については①のネットワーク事業者と調整の上、回線を敷設すること。 図２ ASPとネットワーク事業者の責任分界点(6) システム環境システム環境として、受託者は本番環境、リリース環境、研修用環境を構築することとする。 本番環境とは、本町の行政事務を遂行する環境とする。 リリース環境とは、本番稼動後の機能改修、パッチ適用等の事前検証及び利用者研修等に利用する環境とし、本番環境と同環境下に構築する。 研修用環境は、本町職員の人事異動等に伴い操作研修等を行うための環境とする。 ただし、運用に特別な支障がなければリリース環境と同一環境とすることを妨げない。 なお、開発期間中に、構築段階におけるデータ検証等を行うための開発環境が必要になる場合、原則は本番環境及びリリース環境と同環境下に構築すること。 その他必要な環境を別途構築することを妨げるものではないが、その際に生じる費用は含めること。 (7) 認証方法システムログイン時にはID/パスワードによる認証や、ICカード認証、生体認証等の方式で二要素認証を実施すること。 認証方式については、システム事業者より提案すること。 13８ セキュリティ要件次期システムの導入及び運用保守においては本町が定める規程等を遵守すること。 (セキュリティ関連資料は契約締結後に提供予定である。)なお、本町の情報セキュリティポリシーに定めのない項目であっても、総務省の公表する「地方公共団体における情報セキュリティポリシーに関するガイドライン(最新版)」に準じた対応を求められる点に留意すること。 また、次期システムに求める情報セキュリティ要件は以下のとおりである。 セキュリティ対策の実施においては、継続的にセキュリティが確保されるよう、ＰＤＣＡサイクルで管理運用を行い、セキュリティレベルが低下することのないよう取り組むこと。 ＜情報セキュリティ要件＞要素 要件事項認証  IDとパスワードを用いた認証が可能なこと。  2要素認証に対応すること。 権限管理  システム利用者・管理者別にアクセス権限を設定できること。  所属組織・職務分掌の単位で権限グループを設定できること。 ログの取得  システムログ及びアプリケーションログ(ユーザID、操作日時、対象データ、操作内容、IPアドレスなど)を取得できること。 ログの保管  取得したシステムログ及びアプリケーションログについては、権限のない者が改変できないようにするなど、適切に管理・保管すること。 不正侵入・不正利用の防止 ネットワーク外からの不正な接続及び侵入、行政情報資産の漏えい、改ざん、消去、破壊、不正利用等を防止する対策を講じること。 ウィルス対策  サーバ環境は、アンチウィルスソフトウェアなどを活用して、不正プログラム対策を実施すること。 脆弱性対策  アプリケーションレベルで、クライアントからサーバに攻撃の糸口になり得る情報を送信しないように情報システムを構築すること。 (セッションハイジャックやクロスサイトスクリプティングなどの対策)９ システム導入に付随する役務要件(1) 基本方針次期システム導入における役務要件(プロジェクト計画、要件定義、構築、テスト、移行等)については、「別紙３ 役務・運用保守要件一覧」のとおりとする。 なお、本業務の役務はクラウドサービスの導入であることに鑑み、役務要件に規定している役務のうち、クラウドサービスで品質が保証されている範囲については、品質が保証されている旨の文書を提出することで一部の役務の実施を省略することは可とする。 (2) データ移行に係る補足ア 移行方針現行システムより抽出したデータを受託者に提供する。 受託者は本町から提供する現行システムの設計書等を参考に、必要に応じて移行対14象データを受託者の提案する業務アプリケーションの仕様に合わせた状態に変換すること。 なお、移行対象データは原則、業務データ全件とするが、「地方公共団体情報システムデータ要件・連携要件標準仕様書 基本データリスト」に存在しないデータ項目などについては、本町と協議の上、移行可否・方式を検討すること。 原則本町(現行システム事業者を含む)の提供するデータレイアウトをもとにデータ移行を行うこと。 なお、現行システムからのデータ抽出については、本町(現行システム事業者を含む)で実施予定である。 その他、移行方法の詳細については本町と調整すること。 データ移行にかかる本業務受託者の作業は「別紙３ 役務・運用保守要件一覧」を参照すること。 データ移行作業は、本町、現行システム事業者、本業務の受託者の一体的な作業が重要となることから、作業漏れの防止のため、３者の役割分担を明確にする。 それぞれの役割は、以下のとおりである。 ＜データ移行にかかる割分担表＞作業区分 作業概要 役割(〇：主体、△：支援)本町 現行事業者 受託者作業管理 1 作業計画の策定、作業結果の報告等 - 〇 ○データ抽出処理2 現行システムファイル仕様の整理・提示 - 〇 -3 現行システムファイル仕様の確認 - △ 〇4 抽出プログラムの作成 - 〇 -5 現行システムのデータ抽出 - 〇 -6 抽出したデータ転送・媒体出力 △ 〇 -変換処理 7 変換ツール設計・開発 - △ 〇8 次期システムへの変換処理 - - 〇9 不正データの抽出・提示 - - 〇10 不正データの補正・修正 △ 〇 △データ取込処理11 次期システムへのデータ移行 - - 〇全体管理 12 事業者間の調整等 〇 △ △その他 13 各種問い合わせ対応、助言等 - ○ -現行システムからのデータ抽出は全４回程度を予定している。 なお、詳細スケジュールについては本町と協議のうえ決定する。 以下に本町が想定する時期を記載する。 ただし、受託者の要請に応じて調整が可能であるため、必要なタイミングを本町に提案すること。 15＜データ移行の実施時期(仮)＞回数 実施時期(仮) 主な目的1回目 令和８年８月(契約直後) データ分析、クレンジング等のため2回目 令和９年１月 修正データ、加工プログラム確認等のため3回目 令和９年10月 移行リハーサル(テスト)のため4回目 令和９年12月(本番移行前) 本番移行のためイ 文字コードの変換現行システムの文字コードから行政事務標準文字への変換作業については、下記のとおり実施すること。 ただし、変換対象となる文字コードが別にあり、提案システムの動作に影響がない場合はこの限りではない。 ＜文字コード変換作業＞作業内容 対象システムMJ→行政事務標準文字(MJ＋) 住民記録システム、印鑑登録システム、国民年金システム、選挙人名簿管理システム、就学事務システム、税務システム、国民健康保険システム、後期高齢者医療システム、健康管理システム、児童手当システム、子ども・子育て支援システムウ データ移行範囲移行の対象となるデータは、原則、現行システムに格納されている全データとすること。 ただし、業務ごとの詳細なデータ移行範囲は、受託後に本町と受託者で協議のうえ、決定することとし、現行システムのデータ形式やデータ項目により移行が困難なデータがある場合には本町と協議のうえ対応を決定すること。 １０運用保守要件(1) 基本方針次期システムにおける運用要件及び保守要件については、「別紙３ 役務・運用保守要件一覧」に記載の要求事項を基本とすること。 また、「別紙３ 役務・運用保守要件一覧」に記載されている帳票印刷、封入・封緘等アウトソーシングを実施すること。 なお、「別紙３ 役務・運用保守要件一覧」に記載の要件を満たさない場合でも、本町が業務に支障がないと判断できる場合については要件の緩和を許容することも可能とする。 １１サービスレベル定義次期システムにおいては、努力目標型のサービスレベル合意書(SLA)を締結することを想定している。 本町で定めるサービスレベルの詳細に関しては「別紙４ SLA要求一覧」を参照のこと。 16(1) 基本的な考え方次期環境のシステムサービスは、サービスレベル協定書(以下、「協定書」という。)を締結しサービスレベルを担保する。 品質を一定に保つために、「別紙４ SLA要求一覧」にて設定した項目と目標値を維持すること。 目標値の維持にあたっては、受託者はSLAの各項目についてモニタリングを実施し、その遵守状況を月次の運用保守報告会にて報告すること。 遵守できていないと判断された場合、受託者は速やかに改善することとし、実施時期や方法については本町と協議すること。 また、協定書の締結にあたっては、SLA項目とサービスレベル評価項目及び要求水準、SLAの実現に向けた「モニタリング実施計画書」を作成し、合意内容を明示化する。 なお、次期環境のサービスレベル協定では、月次のモニタリング結果及び半期のモニタリング報告にて著しく品質を下回る場合、改善策を複数回講じても一向にSLAが遵守されない等、受託者の信頼性、信用性及びパートナーとしての品格について著しい欠落が認められた場合、本業務委託契約を解除する可能性がある。 本業務の引継ぎ等、本町がシステムを継続利用するために必要となる手続きについては、受託者の負担ですべて対応すること。 (2) 努力目標型「別紙４ SLA要求一覧」に記載の項目について、提案事業者は誠意をもってこの目標値を遵守するよう努めること。 なお、目標値の達成度合いの計算にあたっては本業務の受託者の責任範囲外の事象(ネットワーク回線トラブル、機器故障等)は除外することとし、具体的な計測方法は本町と受託者にて協議のうえ決定する。 (3) SLAモニタリング報告受託者は、サービスレベルのモニタリングを逐次実施し、モニタリング結果を毎月定期的に本町へ提出すること。 また、以下に示す運用保守報告会を実施すること。 ＜SLAモニタリング報告＞報告会種別 開催時期 報告方式定期報告 定期(1回／月) 月次の運用保守報告会において、サービスレベルの項目についてモニタリング結果の定例報告を行うこと。 定期(四半期) サービスレベル半期報告会を開催し、モニタリング結果の分析と達成できていない項目の改善案等を提案すること。 (4) サービスレベル向上の取組みSLAの遵守及びサービス品質の向上に向けて、前述の定期報告の結果から、改善案等を検討すること。 定期報告において改善案が双方の合意のもと確定した後、受託者は改善計画書を本町に提出すること。 改善計画書の構成は以下のとおりとする。 ＜改善計画書の構成＞項目 内容状況分析 SLA違反の原因となった障害等の状況及び原因分析結果報告17項目 内容再発防止策 再発防止策・予防策の具体的な提示導入スケジュール 再発防止策・予防策の導入スケジュール本町は、改善計画書の記載内容が妥当と判断した場合、計画を承認する。 受託者は本町の承認を得た上で、承認されたスケジュールに基づき改善策を実行すること。 この際の改善策実施に関する費用は、全て受託者の負担とする。 １２ 標準化基準への適合性検証「地方公共団体情報システム標準化基本方針」において、機能標準化基準の適合性及び共通標準化基準の適合性に関しては、「標準準拠システムを利用する地方公共団体が一義的に責任を有する」とされている。 従って、受託者の提案するシステムが機能標準化基準及び共通標準化基準に適合していることを示すための資料等を受託者が提供すること。 本町は受託者から提示された資料等を基に、内容を確認することとする。 本町が確認した結果、懸念や疑義が生じた場合、受託者に対して問合せや作業依頼を行うため、受託者はこれらに対応すること。 以上 別紙10_評価項目、評価基準及び配点表大項目・本町の状況、システム標準化移行に係る背景や方針を踏まえて、本業務に対する提案者の理解を記載すること。 ・提案者の取組方針の特徴、当該特徴が本町にもたらす効果について、具体的に記載すること。 ・上記の根拠を具体的に記載すること。 ・「1.1.1.本業務の基本方針」についての理解を踏まえた上で、本業務の委託内容(システム導入・運用方針)について具体的に記載すること。 ・提案するシステム導入方針の特徴、当該特徴が本町にもたらす効果について、具体的に記載すること。 ・上記の根拠を具体的に記載すること。 1.1.3 標準仕様等への準拠・提案するシステムについて、国の仕様書等に対する対応方針を具体的に記載すること。 (本業務委託仕様書における適合基準日にかかる要件を満たすこと。)・本業務実施における、スケジュールについて具体的に記載すること。 また、仕様書(別紙も含む)の各要件(マイルストーン等)を踏まえて具体的に記載すること。 ・提案者のスケジュールの特徴、当該特徴が本町にもたらす効果について、具体的に記載すること。 ・上記の根拠を具体的に記載すること。 ・各工程における定義・役割分担を記載すること。 【例】- データ移行を考慮したスケジュール- 関連システムとの調整を考慮したスケジュール- 職員の業務繁忙等を考慮したスケジュール2.2.1 システムの構成・提案するシステムについて、システム全体の機能や構成について、要点を明確に記載すること。 また、提案するパッケージ製品名、バージョン等についても記載すること。 ・提案するシステムが機能標準化基準及び共通標準化基準に適合していることを示すための資料を添付または記載すること。 2.2.2標準オプション機能(機能要件・帳票要件・連携要件)への対応度・別紙「別紙５ 機能要件」「別紙６ 帳票要件」「別紙８ 連携要件」において各業務システムの標準オプション機能への対応度(◎(パッケージ標準機能として実装)、〇(パッケージ標準機能以外による実装(外付けプログラム等))、×(対応不可))を記載すること。 ・類型①に分類されている要件について「×」を回答する場合は代替案を記載すること。 代替案については、それぞれ内容を評価の上、本町の要望を十分に満たすと判断した場合には、「〇」として評価する。 ・なお、「〇(パッケージ標準機能以外による実装(外付けプログラム等))」を実現する場合は、本提案内(提案金額内)に含めること。 別途費用が発生する場合は、「〇」と認めない。 2.2.3. 業務マニュアル等の評価・「別紙9 業務マニュアル等の提出を求める業務」に記載されている業務について、業務マニュアルや画面遷移等が分かるような資料を提出すること。 ・上記の根拠を具体的に記載すること。 【例】 - 職員にとって利便性の高い検索・照会機能 - 業務効率化に寄与する画面構成、画面遷移 - その他個々の職員の操作性向上に寄与する仕組み - 未システム化業務にかかるシステム化対応を含む (導入方針は継続検討)3.1.1 非機能要件・「別紙7 非機能要件」に記載している可用性、性能・拡張性、移行性、セキュリティ、システム環境・エコロジー要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 ・運用保守要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 ・運用保守要件に対する提案者の提案の特徴、当該特徴が本町にもたらす効果について、具体的に記載すること。 ・上記の根拠を具体的に記載すること。 【例】 - システム稼働後における問合せ対応等の利用者支援の体制3.1.3 ハードウェア、ネットワーク要件・ハードウェア要件、ネットワーク要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 3.1.4 ソフトウェア要件・ソフトウェア要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 配点割合 記述項目一覧1.本業務に対する理解 1.1. 本業務に対する理解1.1.1 本業務の基本方針5.0%1.1.2 システム導入方針1.1.4 開発・導入スケジュール2800中項目 小項目評価項目配点小計2.機能要件 2.1. 機能要件定義 25760 46.0%3.非機能要件 3.1. 非機能要件定義 2800 5.0%3.1.2 運用保守要件1/2大項目配点割合 記述項目一覧中項目 小項目評価項目配点小計・プロジェクト管理要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 ・プロジェクト管理要件に対する提案の特徴、当該特徴が本町にもたらす効果について、具体的に記載すること。 特に、システム所管課間の円滑な調整・職員の業務繁忙等を考慮する等、移行による業務影響の最小化に資するプロジェクト管理方法を記載すること。 ・上記の根拠を具体的に記載すること。 【例】 - プロジェクト管理方法(進捗、品質、課題、仕様変更等)、適用方法について - 効率的な会議運営方法 - 関連システム事業者との調整も含めたプロジェクト管理方法 - 類似案件の導入実績に基づいた開発手法・プロジェクト管理方法4.1.2 要件定義・設計・要件定義・設計に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 4.1.3 品質試験(テスト)要件・品質試験(テスト)要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 4.1.4 本番移行要件・本番移行要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 4.1.5 操作研修・操作研修要件に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 4.1.6 SLAの締結について・サービスレベル水準に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 4.1.7 標準仕様書の改版について・標準仕様書の改版に関して、業務委託仕様書(別紙も含む)に示された要件の実現方法(仕様を満たしている根拠)について具体的に記載すること。 5.1. 本町にとって有用な提案 5.1.1 提案者からの追加提案・本町職員の業務負担削減や経費負担に資する提案があれば、具体的に記載すること。 【例】 -AI、RPA等を活用した業務処理の自動化(ただし、パッケージシステムに手を加えないもの)5.2. コンビニ交付に係る提案 5.2.1. コンビニ交付に係る提案・本町で標準準拠システム移行後に導入予定のコンビニ交付システムについて、具体的に記載すること。 【例】実現方法、スケジュール、費用感6. プレゼンテーション評価6.1. プレゼンテーション評価 6.1.1. プレゼンテーション評価 8400 15.0%・別途評価票による7. 価格点 7.1. 提案額 7.1.1 提案額 5600 10.0%・初期費用およびランニングコスト(５年間)を記載すること。 ・参考見積書を提出すること。 参考見積書には内訳を記載すること。 56000 100%14.0%5. 追加提案 2800 5.0%4.業務委託要件 4.4. 業務委託要件4.1.1 プロジェクト管理要件78402/2 別紙１_調達範囲一覧 ○：対象 △：本町の支援等※調達範囲は以下に示す通りであるが、本業務の主旨および提案者の提案事項を踏まえ、本紙に記載がないものの必要と想定されるものは提案内容に含めること。 項番 対象区分 対象費目 仕様書との対応 数量 本調達 別途契約 補足2 標準準拠システム導入・運用保守設計・開発費用(プロジェクト管理、要件定義、設計、構築(製造)、環境構築、テスト、データ移行、切替、研修等)１本業務の概要(5)調達範囲ア 標準準拠システム導入イ 関連システム導入オ システム導入に付随する役務 他一式 ○・関連システムを含む。 ・ガバメントクラウドへの構築を含む。 3各ミドルウェア、ソフトウェアライセンス費用等１本業務の概要(5)調達範囲カ ハードウェア・ソフトウェア 他一式 ○ ・関連システムを含む。 4 ガバメントクラウド１本業務の概要(5)調達範囲ウ ガバメントクラウドの設定 他一式 ○ ・ガバメントクラウドの環境構築を含む。 5 ガバメントクラウド利用料 ‐ ‐ ‐ ○ ・国から本町に請求されるものは本業務の対象外。 6ガバメントクラウドを除くハードウェア１本業務の概要(5)調達範囲カ ハードウェア・ソフトウェア 他一式 ○・ガバメントクラウド以外にシステムの稼働に必要な専用のハードウェアがある場合は含める。 7 システム運用保守業務１本業務の概要(5)調達範囲キ システム運用・保守他一式 ○ ○・関連システムを含む。 ・本委託期間内の運用保守業務は本調達に含む。 8 端末・機器調達 業務用端末１本業務の概要(5)調達範囲ク 業務用端末45台 ○ ○・ID・パスワードを除く2要素認証に必要な認証機器を含む。 ・本委託期間内に発生する経費は本調達に含む。 9 データ抽出作業 現行システムからのデータ抽出作業９システム導入に付随する役務要件(2)データ移行に係る補足ア移行方針一式 ○ ・現行システム事業者との契約10 ネットワーク構築作業 ネットワーク回線１本業務の概要(5)調達範囲エ ネットワーク 他一式 ○・ガバメントクラウド接続ゲートウェイからベンダVPCまでの回線・受託者拠点とガバメントクラウドを繋ぐネットワーク11 ガバメントクラウド接続回線７システム稼働環境(プラットフォーム)要件(5)ネットワーク要件一式 △ ○・本町ルータからガバメントクラウド接続サービスまでのネットワーク構築及び利用。 ・接続回線事業者との調整にあたり本町を支援すること。 12役場内部ネットワーク構築、設定変更等７システム稼働環境(プラットフォーム)要件(5)ネットワーク要件一式 △ ○・役場内部ネットワークの詳細は受託後に本町の指示に従うこと。 ・設定変更等、既存のネットワークに対する変更が生じる場合は、本町の指示に基づき、本町が設計、調達に当たり必要な情報を提供すること。 13 作業環境構築期間中に必要となる作業環境に係る費用１本業務の概要(6)作業場所一式 ○ ○・データ移行作業や打合せスペース等、役場内の作業スペースを使用する場合には、その必要性に応じて本町から提供する(受託者が用意する作業場所については受託者の負担とする。)。 14 その他 帳票アウトソーシング委託費用１０運用保守要件(1)基本方針一式 ○ ○・本契約期間内に発生するもののみとし、令和10年度以降の業務は後年の運用保守契約の範囲とし、受託後に詳細を決定する。 15 帳票封入封緘・発送費用１０運用保守要件(1)基本方針一式 ○ ○・本契約期間内に発生するもののみとし、令和10年度以降の業務は後年の運用保守契約の範囲とし、受託後に詳細を決定する。 別紙２_成果物一覧# 工程 成果物 レビュータイミング 省略の可否成果物の構成要素(簡略化・省略することが可能な構成要素について、下線を付記している。ただし下線の有無に問わず、提出成果物や記載内容については本町と協議可能とする。)1 プロジェクト計画書 契約後2週間以内 省略不可・目的、目標(ミッション)の確認・スコープと最終成果物の定義・業務全体の進め方の概要・業務遂行体制・会議体の定義・各種プロジェクト規定 進捗管理方法、課題管理方法、品質管理方法 情報資産取扱規定、会議開催規定 各ドキュメント標準規定 情報共有手段 等2 開発計画書 設計着手前 省略不可・開発計画 開発スケジュール(WBS)と役割分担 開発体制、開発環境、テスト環境 開発工程の定義・知的財産権に関する確認3設計(外部設計・内部設計)要件定義書システム仕様書パッケージ仕様書システムデザインシート等開発着手前 一部省略可・システム要件 システム利用組織、システム権限一覧、システム提供機能・画面(UI)一覧・システム帳票一覧、帳票レイアウト・コード及び番号体系・データベース仕様・外字、機種依存文字仕様・他システムとの連携仕様・外部インタフェース仕様・システム性能仕様・安全性、信頼性仕様・セキュリティ仕様・システム構成、デザインシート・ハードウェア構成/クラウドサービス設計、ソフトウェア構成・ネットワーク構成・ネットワーク(アドレス・ルーティング)設計・運用保守仕様 サービス提供時間、運用体制、役割分担、運用実施内容 年間イベントスケジュール ハードウェア/クラウドサービス保守仕様、ソフトウェア保守仕様 SLA実現手順詳細シート・研修要件・非機能要件対応表4 テスト計画書 開発着手前 一部省略可・内部テスト計画(単体・結合テスト)・システムテスト計画(総合テスト) テスト方針、品質判定基準 テスト仕様方針策定 テスト役割分担 実施スケジュール テスト仕様、テスト項目一覧5 データ移行設計書 開発着手前 一部省略可・移行/データセットアップ仕様・移行結果検証方法定義・移行スケジュール・データ項目新旧対応表・移行作業テスト仕様・切り戻し時の方針・作業内容6 システム環境構築 構成管理台帳 システムテスト実施前 一部省略可・システム設定シート セットアップ及び初期設定マニュアル 初期設定パラメータ一覧7内部テスト(単体・結合テスト)内部テスト実施報告書 システムテスト実施前 省略可・内部テスト仕様(テスト結果)・故障発生記録・品質判定結果開発協議(基本計画) 以下に、ウォータフォール型開発を前提とした本業務における成果物を整理するが、本業務で導入するシステムは、標準仕様書に準拠したクラウドサービスとしての導入を想定しているため、個別での提出が難しい成果物については簡略化・省略することは可とする。 その場合はクラウドサービスとして品質が保証されている旨の文書を提出の上、事前に本町と協議することとする。 また、システムやクラウドサービスのパラメータ設定情報などについては、必要に応じて情報を提供できることとし、本業務での成果物としての納品は必須としないこととする。 1/2# 工程 成果物 レビュータイミング 省略の可否成果物の構成要素(簡略化・省略することが可能な構成要素について、下線を付記している。ただし下線の有無に問わず、提出成果物や記載内容については本町と協議可能とする。)8 運用管理マニュアル システムテスト実施前 省略不可・共通編 運用管理方針、システム運用体制 運用保守業務一覧 情報資産台帳・運用編 年間運用スケジュール 月次運用スケジュール 作業依頼書、作業指示書管理方法 運用作業手順書・保守編 年間運用スケジュール 月次運用スケジュール 保守作業手順書・セキュリティ編 セキュリティ対策基準書 セキュリティ実施手順書・障害対応編 障害時連絡体制(日中・夜間) 障害時業務運用規定 障害対応手順(切り分け手順)・様式類 作業依頼書、利用時間延長申請書等、運用管理における様式類一式9システム操作マニュアルシステムテスト実施前 省略不可 ・システム操作マニュアル10システム及びデータバックアップシステムテスト実施前 省略不可・稼動前システムバックアップ・稼動前データバックアップ11 初期運用計画書 システムテスト実施前 省略不可・初期稼動体制・初期障害に対する対応方針・留意事項等12 研修計画書 システムテスト実施前 省略不可 ・研修スケジュール、実施方法仕様13 研修マニュアル システムテスト実施前 省略不可 ・システム研修マニュアル14システムテスト(総合テスト)システムテスト実施報告書本番データ移行前 一部省略可・システムテスト仕様(テスト結果)・故障発生記録・是正措置、対応一覧表(デバッグ記録)・品質判定結果15 システム移行 データ移行実施報告書 稼動承認前 省略不可・移行テスト仕様(テスト結果)・留意事項・データ移行確認証明(計算結果や件数確認結果等)16 システム稼動後 稼動報告書 稼動確認後1週間以内 省略不可 ・稼動報告書17 運用保守報告書 随時 省略不可・運用実績報告書・問題・変更管理台帳18 SLA報告書 随時 省略不可・モニタリング結果報告書・改善計画書運用・保守運用・保守設計研修計画2/2 別紙３_役務・運用保守要件一覧(役務要件)1-1 プロジェクト計画書 受託者はシステムの構築における具体的な体制、スケジュール、納品物の一覧、プロジェクト管理方針、品質管理方針、プロジェクト管理方法等を含んだプロジェクト計画書を作成し、本町の承認を得ること。 1-2 進捗管理 受託者は、作成し承認されたプロジェクト計画書に基づき、プロジェクト進捗管理を行うこと。 また、 実施計画と実績の差を把握し、進捗の評価を行うこと。 定例報告会において進捗状況を報告すること。 なお、進捗及び進捗管理に是正の必要がある場合は、その原因及び対応策を明らかにし、速やかに是正の計画を策定すること。 1-3 品質管理 プロジェクト計画策定時に定義した品質管理方針に基づく品質管理を実施すること。 品質基準と状況の差の把握、品質の自己評価を実施し、各工程完了報告会において本町に報告すること。 品質及び品質管理に是正の必要がある場合は、その原因と対応策を明らかにし、速やかに是正の計画を策定すること。 1-4 課題・リスク管理 課題発生時には、課題の内容、解決主体、解決予定を明らかにし、本町と協議のうえ、課題対応策を検討すること。 課題は、解決するまでモニタリングし状況に応じて解決予定や派生課題を管理すること。 システム稼働、費用及びシステム品質に影響を及ぼすと想定されるものはリスクとして管理・評価を行うこと。 リスクが顕在化した場合は対応方針について本町と協議すること。 1-5 変更管理 マスタスケジュール、仕様凍結後の仕様変更、業務遂行の体制変更及び契約条文に影響を与える事象は変更要求として管理し、対応に係る工数(費用)、スケジュール及びその他について、変更委員会にて変更諾否の承認を得ること。 1-6 セキュリティ管理 プロジェクト計画書に定義した管理方法に基づきセキュリティを管理すること。 受託者は、情報漏えい・消失及び不正利用等が発生しないよう、厳格にセキュリティ管理を実施すること。 また、セキュリティ管理に係る体制・報告手順等を明確にし、遵守すること。 1-7 成果物の管理 成果物は常に最新化することとし、変更の履歴管理を行うこと。 また、作成した成果物は、運用・保守期間中も継続して最新化できるように管理すること。 1-8 定例報告会 プロジェクト計画書策定時に定義したプロジェクト管理方針に基づくプロジェクト管理(進捗管理、品質管理、課題・リスク管理、変更管理、セキュリティ管理)を実施すること。 【開催サイクル】定期的(月次)に開催する。 【報告書類】進捗報告書、課題管理表、変更管理票、WBS、その他必要な報告資料等1-9 各工程完了報告会 各工程における成果物の品質を検査し、工程完了判定の実施を依頼すること。 【開催サイクル】各工程の完了時【主要報告書類】各工程における成果物、品質状況報告書等1-10 各作業部会 要件・仕様の調整、進捗管理、課題管理、データ移行等に関する方策・作業内容の検討・調整等を行うこと。 【開催サイクル】随時【報告書類】課題管理表、各検討・調査・報告資料等1-11 推進体制 本業務の遂行にあたっては、必要なスキル及び経験を有するメンバーを配したプロジェクト体制を整え、本町の承認を得ること。 プロジェクト責任者並びに次期システムの設計・構築業務、テスト業務、本番移行業務、研修業務及び保守業務等の各領域別に責任者を定めること(業務に支障を与えない限り、責任者の兼任は可能とする)。 1-12 セキュリティ管理体制 プロジェクトを推進する上で必要なセキュリティの管理体制を整え、情報セキュリティ対策状況を管理する責任者を定めること。 1-13 要員のスキル 要求仕様書に定める全作業内容を理解し、実施するために必要な知識、能力を有すること。 以下のスキルを有する者を不足なく配置すること。 なお、本プロジェクト全体の統括責任者及び各業務領域の責任者を必ず配置し、必要に応じて作業者を指示するリーダーを配置すること。 ・プロジェクト管理能力を有する者・品質管理能力を有する者・インフラ系システムに関する知識を有する者・プログラミング能力を有する者・自治体業務に関する知識を有する者(各業務領域の担当者はその領域における業務知識を有すること)・ネットワークに関する知識を有する者・ハードウェア等構成設計能力を有する者1-14 実績 本業務のプロジェクト管理を実施するものは、本町と同規模自治体において、基幹業務システムの再構築の経験を有すること。 1-15 基本計画・設計(開発協議) 仕様に基づき機能設計(開発協議)を行うこと。 設計は、パッケージプロトタイプを用いて協議を行うこと。 仕様確認結果及びカスタマイズ事項を整理のうえ、指定された成果物を取りまとめ、工程完了判定で承認を得ること。 開発規模について管理を行うこと。 1-16 非機能要件に関する設計 仕様に基づき非機能機能設計(開発協議)を行うこと。 仕様確認結果及び設計内容を整理のうえ、指定された成果物を取りまとめ、工程完了判定で承認を得ること。 開発規模について管理を行うこと。 1-17 運用保守要件に関する設計 仕様に基づき運用保守設計を行うこと。 仕様確認結果及び設計内容を整理のうえ、指定された成果物を取りまとめ、工程完了判定で承認を得ること。 (本町と受託者の役務役割分担、責任分界が明確であること。)1-18 構築方針 受託者は仕様書に記載したとおりのシステムサービスを構築すること。 構築にあたっては、システムサービスが全体として動作し、適切にサービスを提供するために必要となる全ての作業を行うこと。 1-19 開発手法 次期システムサービスの開発の各工程を網羅し、品質の確保とスケジュールの短縮を図ることが可能な総合的な開発手法であること。 他の開発業務において十分な使用実績を有すること。 カスタマイズ事項については、実際のシステム画面や動作・振る舞い、出力帳票等を理解できること。 1 役務要件 システム導入に係る役務に関する要件 プロジェクト管理要件定義・設計システム・サービス構築No. 項目名 要件事項 備考 No. 要件分類 要件項目1/11No. 項目名 要件事項 備考 No. 要件分類 要件項目1-20 既存システムへの影響調査 既存システムやネットワークについて、事前に充分な調査・調整を実施すること。 1-21 構築に係る手配 システムサービスの構築に必要な機器や環境、ソフトウェアは、受託者が全て手配すること。 1-22 システム環境 システム環境については、「調達仕様書 ７システム稼働環境(プラットフォーム)要件」を参照すること 。 1-23 データセンタ環境構築 データセンタに機器等の格納が必要な場合は、別紙に示す要求を満たすデータセンタにサービス提供に必要となる機器等を格納すること。 準備について、作業計画(準備作業に係る全体スケジュール、作業内容、役割分担、成果物等)を定め、本町と合意を得ること。 1-24 ネットワーク構築 システムサービスを利用するために必要となるネットワーク(WAN及びDC内ネットワーク)の構築、NW機器設置等準備を実施すること。 準備について、作業計画(準備作業に係る全体スケジュール、作業内容、役割分担、成果物等)を定め、本町と合意を得ること。 1-25 既存システムとの連携 既存システム及びネットワーク等に対して改修・設定変更等が必要な場合は、当該システム及びネットワークの運用保守を担当している事業者に対し、本町を通じて作業を依頼すること。 また、依頼にあたっては、対応費用を本町が確保するための期間を考慮し、事前の相談の上、これを実施すること。 1-26 EUCの導入・設定 受託者は次期システムで利用するEUCツールを導入すること。 また、問合せ対応や設定変更作業等、データ抽出機能・ツールを本町が利用するための支援作業も実施すること。 1-27 テスト計画 各種テスト(単体テスト、結合テスト及びシステムテスト等)実施するにあたって、目的・環境・手法・品質評価基準等を明記したテスト計画書を事前に作成し、承認を得ること。 1-28 テスト方針 各テスト計画書等に基づいて、開発したシステムの品質試験(テスト)、結果分析及びその対策を実施すること。 テストにおいて、エラー及び障害発生を確認した場合は、本町へ報告の上、その原因や影響をすみやかに特定し、設計変更・アプリケーション改修等しかるべき対応を実施すること。 性能面での問題が発生した場合も同様に、原因を特定の上、適宜性能向上対策を実施すること。 テストにあたっては、網羅的な検証が可能なテストデータを受託者自身で用意すること。 他現行システムとの連携テストについては、受託者が主体的にテスト基本計画書策定の段階から参画し、本町、主管課及び現行システム事業者と調整・協議の上、整合を取りながら進めること。 1-29 再テストの方法 テストにおいてエラー及び障害が発見された場合、当該箇所の設計段階へ立ち戻りの上、原因分析を実施すること。 1-30 テストの報告 各種テスト計画等にもとづいて実施したテストはテスト報告書として提出すること。 テストの結果は、本町がテスト結果を定量的に判断可能な形式(評価項目、評価基準等)で報告すること。 1-31 テストデータの取り扱い 個人情報等を含むデータをテストで使用する場合は、セキュリティに充分に配慮した上で、本町と協議の上取り扱いを決定すること。 1-32 単体テスト アプリケーションが単体で正常に稼動することを担保すること。 1-33 結合テスト 受託者にて環境を用意し、機能の網羅性に配慮した上で、以下の観点にてシステムの稼動品質を担保すること。 ①プログラム連携テスト ②印刷テスト ③バッチ処理テスト ④バックアップ、リストアテスト1-34 結合テストの環境 テストの実施にあたっては、システム構成(概観)、ソフトウェアのバージョン、権限等を本番環境と合わせること。 1-35 システムテスト 本番と同等の環境で、システムが正しく稼動することを担保すること。 以下の観点にてシステムの稼動品質を担保すること。 ①シナリオテスト ②連携テスト ③システム運用テスト ④セキュリティテスト ⑤性能評価(性能テスト、負荷テスト) ⑥リストアテスト ⑦その他必要なテスト1-36 システムテストの環境 システムテスト以降のテストにおいては、本町と作業体制、作業場所等について協議の上、本番と同等の環境で実施するものとする。 1-37 受入テストの支援 テストは本町が一通りの業務機能を確認できるものであることを前提とし、テスト内容を提案すること。 提案後、本町と協議の上、テスト内容を決定すること。 テストの実施にあたっては、テスト環境の手配、テストデータの作成等を行うこと。 1-38 本番移行方針 本番移行作業により、既存システム及びネットワークに影響を与えないよう本番移行計画を立案し、本町の承認を得ること。 本番移行計画書に基づいて、移行作業を主体的に実施すること。 また、移行作業の実施にあたっては、移行が必要なデータの選別を実施すること。 なお、移行終了後は、移行結果を書面にて提出し、本町の了承を得ること。 1-39 本番移行に係る調査・調整 既存システム及びネットワークに対して作業が必要な場合は、当該システム及びネットワークの運用保守を担当している事業者に対し、本町を通じて作業依頼、日時の調整を実施をすること。 依頼にあたっては、対応費用を本町が確保するための期間を考慮し、事前の相談の上、これを実施すること。 1-40 コンティンジェンシープラン 移行作業がうまくいかなかった場合の切り戻し作業等の内容(コンティンジェンシープラン)を設計すること。 1-41 移行リハーサル 本番移行リハーサル等を実施し、本番移行作業が正しく行えることを検証すること。 (２回程度(手順確認、時間計測)のリハーサルを想定)1 役務要件 システム導入に係る役務に関する要件品質試験(テスト)本番移行システム・サービス構築2/11No. 項目名 要件事項 備考 No. 要件分類 要件項目1-42 データ移行 本町から提示される現行システムのデータ(CSV等汎用的な形式)を受け取り、次期システムへ取り込むこと。 その際、必要なデータ変換作業を実施すること。 データの移行は、職員の負担が最小限となる方法で行うよう留意すること。 現行システムからのデータ抽出については、本町(現行システム事業者を含む。)で実施予定であり、移行データの提供方法は、文字コードを原則JIS X0221:2020とし、CSVや固定長等のテキストデータでの提供を予定している。 (本番移行用１回、移行リハーサル用１回、テスト用２回の合計４回程度の抽出を想定)1-43 データ移行の整合性確認 移行対象のデータと、移行後のデータが一致(現新比較)することを確認し、本町へ報告すること。 1-44 データ移行に係るセキュリティ対策データ移行及びそれにかかる作業によって、不正にデータが漏洩しないよう、対策を講じること。 また、講じた対策については本町へ報告の上、承認を得ること。 なお、データ移行の実施場所については、本町と合意した作業場所(本町施設、データセンタ内等セキュリティが確保され、データ移送に伴うデータ紛失事故等が発生しない場所。)にて実施すること。 1-45 移行データの破棄 データ移行にて使用したデータは移行以外の目的には使用せず、システムが安定稼動したことを確認した後、適切に破棄すること。 1-46 マスタパラメータ設定 システムの稼動に必要となる各種初期データは、パラメータ設計シート等に基づき設計を行うこと。 1-47 移行の対象となるデータ 移行するデータは、現行システムに格納されている全データとすること。 採用するパッケージ等によって、必要な追加項目が不足し登録が必要な場合は、登録を実施すること。 操作研修 1-48 マニュアル サブシステム毎に操作マニュアルを作成すること(管理者／一般利用者)。 1-49 初期研修 各業務システム等に関しては、システム毎の開発計画に沿って、システムリリースまでに、研修が必要となる本町職員に対して研修を行うこと。 本町では各課業務担当に対し、個別に操作研修を実施することを想定している。 1-50 初期研修の実施環境 研修は原則、検証環境か本番環境で行うこと。 実施場所は本町の指定する場所とし、操作端末は本町と協議の上、原則本町側で準備を行う。 1-51 初期研修の実施準備 研修を実施するために必要となるシステム・端末の設定や講師の派遣、対象職員数に応じたサポート要員の準備等、研修に必要となるマテリアルや要員等は受託者にて準備すること。 1 役務要件 システム導入に係る役務に関する要件本番移行3/11別紙３_役務・運用保守要件一覧(運用保守要件)1-1 運用体制 運用作業を実施するものを事前に定義し、運用業務を行うこと。 ・運用担当責任者：新システムの運用に関する全責任を担うこと。 ・運用担当管理者：新システムの運用に関して、例外運用等の運用担当者では判断ができない場合等の判断及び指示等を行うこと。 ・運用担当者：新システムの運用において定められた運用を行うこと。 1-2 保守体制 以下、保守作業を実施するものを事前に定義し、保守業務にあたること。 ・保守責任者：保守に関する全責任を担うこと。 ・保守管理者：保守に関する作業の管理を行うこと。 ・保守担当者：保守に関する作業を行うこと。 1-3 運用保守対象 本調達にかかる全てのシステム・サービスに対して、運用保守作業を実施すること。 なお、標準仕様書の改版があった場合は、運用保守委託の範囲内で対応すること。 ただし、補助金対象となるような大規模な法令改正対応が発生した場合、本町と別途協議のうえ対応すること。 1-4 運用保守時間 システム運用保守業務の実施時間は、以下のとおりとすること。 平日 8：00～20：00土日祝日 8：00～13：00※上記以外でも時間外窓口等で障害発生時等の問い合わせ対応を行うこと。 ※なお、サービス提供にあたり必要な作業は、これに依らずサービスに影響を与えることなく実施すること。 1-5 運用作業の範囲 システムサービスを日々稼働させるために必要な作業を行うこと。 作業にあたっては、各システムが円滑に稼動し、品質が確保されるように、作業計画や運用手順書(システム運用マニュアル)に基づくこと。 作業依頼書・作業指示書による作業、共通マスタのアップデート、システム構成管理、バグ対応・機能変更に関する変更管理、アカウント管理、データの作成・登録、データの抽出、データ整合性チェック、各種調査依頼、データバックアップ、システム監視、異動履歴退避データの調査、稼働状況点検、問い合わせ対応(ヘルプデスク)、バッチスケジュール管理、バッチ処理運用管理、運用管理方式の変更対応、SE対応、職員の入力ミスへの対応、ドキュメント管理、運用報告会の開催、他システム対応、SLAモニタリング報告、改善提案、セキュリティ管理、職員用の操作マニュアルの整備・提供・更新1-6 保守作業の範囲 システムサービスを日々稼働させるために必要な作業を行うこと。 作業にあたっては、各システムが円滑に稼動し、品質が確保されるように、作業計画や運用手順書(システム運用マニュアル)に基づくこと。 (保守作業)ハードウェア設定の変更・追加・削除、ハードウェアの交換、ソフトウェア設定の変更・追加・削除、ソフトウェア再インストール等、ソフトウェアバージョンアップ(法制度改正対応等を含む。)、パッチ・パターンファイル等の適用、プログラムバグの対応、機能追加・改良ハードウェアについては、導入するものがある場合に限る。 以下同じ。 1-7 運用作業計画 システムの年間／月間／週間の運用作業計画を作成し、本町の承認を得ること。 1-8 保守作業計画 機能追加／改善、新機器の導入／交換、不具合改修、不具合機器交換等の作業について、事前に保守作業計画を作成し、本町の承認を得ること。 1-9 障害対応時間 「調達仕様書 6(1)ア オンライン稼働時間」に示した時間内においてシステムに異常が検知された場合は、障害対応に係る作業を実施すること。 ただし、システム利用不可となるような重大障害の発生時には、上記時間外であっても、翌日の業務開始時までにシステムを利用可能な状態に復旧すること。 なお、翌日の業務開始時までにシステム復旧が困難な場合など、システムの1-10 障害時の連絡体制 障害発生を検知した際の連絡体制を設定すること。 1-11 障害時の自動通報 障害発生時に、本町に対して自動通報(メール等)を行うこと。 1-12 障害対応の範囲 システムを安定的に利用するための一連の業務(予防保守、障害検知、障害発生連絡、影響報告、障害原因の調査・特定、中間報告、暫定対応、恒久対応、事後報告等)を実施すること。 業務委託 1-13 各業務作業の委託 以下の定期的な業務について、委託事業者が主体となり、下記業務に係る実行、年間処理スケジュールの調整、進捗管理・報告、課題の共有等を行うこと。 また、職員作業についてもその支援を行うこと。 詳細は「外部委託一覧」を参照。 1-14 業務内容 利用者からの各種問合せや障害時の対応及び利用者からの要求依頼に関する対応を実施すること。 1-15 受付 問合せ方法は、電話、メールとし、以下の対応時間とすること。 平日 8：00～20：00土日祝日 8：00～13：001-16 調査 問合せに関して、一次切り分けを実施すること。 問合せ内容に関して、これまでの応対履歴等を調査し、既存事象か否かを判断すること。 既存事象でない場合には調査を実施すること。 1-17 回答 問合せ内容が既存事象であった場合には、速やかに回答すること。 問合せ内容に調査を要する場合、調査内容が判明次第速やかに回答すること。 要件事項 備考障害対応項目名 No. 要件分類 要件項目 No通常運用 システム利用にかかるシステムの運用及び保守に関する要求運用・保守要求 1問合せ対応(ヘルプデスク)4/11要件事項 備考 項目名 No. 要件分類 要件項目 No1-18 記録／報告 問合せ・要求・依頼内容(日時、内容、連絡者、回答内容)等を記録し、作業実績報告書にて、本町に報告すること(月次の運用保守報告会を想定)。 特に、大規模な障害や変更要求等については、原因・対応策や経緯等を取りまとめた上で、月次の運用保守報告会を待たず、すみやかに本町に報告すること。 1-19 実施場所 実施場所については、本町拠点またはリモートのどちらでも許容するが、リモート保守とする場合は、受託者の費用負担にて、本町から別途提示するリモート保守の実施要件を全て満たすことを前提とする。 1-20 セキュリティ対策方針 本町のポリシー、規程等を踏まえ、システムのセキュリティ対策の前提となる上位方針を設定すること。 1-21 セキュリティインシデント管理 事象発生時に、対応の要否を判断する基準を設定すること。 なお、対応要の場合にはセキュリティインシデントして取扱うこと。 また、セキュリティインシデント発生時の事象及びログ等を取得すること。 1-22 セキュリティ管理体制 セキュリティインシデント発生に対応するための体制を設定すること。 1-23 セキュリティ対策実施手順 本町のセキュリティ対策基準及び策定したセキュリティ対策方針に従い、セキュリティインシデント発生時に対応する手順等を示す計画を立案すること。 セキュリティが確保されるシステムサービス環境を提供すること。 1-24 セキュリティチェック 業務システムに対するセキュリティチェック(アクセスログ分析、不要アカウント削除、管理者パスワードの変更等)を定期的に実施をサポートすること。 1-25 検証環境の維持 受託者は、運用・保守フェーズにおける検証環境について、適切な検証作業が可能な状態を維持すること。 (テスト環境を構成するミドルウェアのセキュリティパッチ適用・アプリケーションのバージョンアップ・データベースの更新等の必要に応じた作業の実施、検証環境へのデータベースの同期は月1回程度を想定)本番環境と同等の環境があれば問題ない1-26 運用・保守拠点 運用・保守拠点については、「調達仕様書 1本業務の概要 (6)作業場所」を参照すること。 1-27 運用手順書・マニュアル管理 各システムを運用するうえで必要となる手順書や操作マニュアルを策定すること。 運用手順に変更があった場合は最新化を行うこと。 手順書や操作マニュアルのバージョンや、所在を管理すること。 1-28 利用者向け操作マニュアル 利用者向けの操作マニュアルについて、システムの操作性に変更があった場合は最新化を行うこと。 操作マニュアルのバージョンや所在を管理すること。 1-29 保守手順書管理 各種ソフトウェア、機器に関する保守(開発、試験及びリリース、メンテナンス等)手順が定められた保守手順書の管理を実施すること。 1-30 構成情報管理 以下、構成情報を管理すること。 ＜ソフトウェア構成＞・ソフトウェア一覧・ソフトウェア環境設定書・ソフトウェア連携定義書(インタフェース仕様書等)＜ハードウェア構成＞・機器一覧・機器構成図・機器環境設定書＜ネットワーク構成＞・ネットワーク機器一覧・ネットワーク回線一覧・ネットワーク構成図・ネットワーク環境設定書定例報告会 1-31 運用保守報告会の開催 運用保守報告会を月次で開催すること。 内容は以下とすること。 ①運用保守作業に関する報告②作業計画に関する連絡及び調整③問合せ対応及びバックログに関する報告④課題対応・セキュリティ対策に関する報告⑤障害に関する報告⑥SLAモニタリング報告⑦統計情報に関する報告⑧運用方法等の変更に関する報告及び協議⑨その他、報告及び協議が必要な事項1-32 障害時運用手順 障害時の連絡体制・対応フロー等を定めて、運用手順書に作成すること。 運用手順書は、運用設計段階において作成し、総合テスト及び運用テストを通じて手順の検証を行うこと。 1-33 被災を想定した手順策定 想定しうる災害に対して、運用作業計画に沿った、災害発生時の体制・連絡系統及び手段・対応フロー等(障害確認の手順・対処方法、復旧優先順位の設定)を定め、事業継続を前提とした復旧手順を策定するとともに、年1回の想定訓練を実施すること。 訓練の詳細(休日などに業務を停止して訓練を実施する等)については、本町と協議の上決定する。 ※ドキュメントについては各社のマニュアル等で可 1-34 災害時の復旧 大規模災害時にシステムが停止した場合には、予備機やバックアップデータ等を利用して1ヶ月以内に復旧を行うこと。 セキュリティ管理運用保守環境障害・災害発生時対応手順の策定システム利用にかかるシステムの運用及び保守に関する要求運用・保守要求 1問合せ対応(ヘルプデスク)ドキュメント管理5/11要件事項 備考 項目名 No. 要件分類 要件項目 No1-35 履行満了時の支援 本業務の契約履行期間の満了の際、受託者は本町の指示のもと、本業務終了日までに本町が継続して本業務を遂行できるよう必要な措置を講じ、新規事業者に移行する作業の支援を行うこと。 また、業務引き継ぎに伴いデータ移行等が発生する場合、構築・運用を行っている全ての業務システムについて、移行のために必要となるデータをデジタル庁が定める「地方公共団体情報システム データ要件・連携要件標準仕様書」に沿って抽出すること。 「地方公共団体情報システム データ要件・連携要件標準仕様書」に含まれないデータについても、汎用的なデータ形式(CSV等)に加工し提供すること。 さらにファイル・データレイアウト等の資料を提供するとともにQA対応など、本町または新規事業者に対して誠意を持って協力すること。 1-36 データ消去・撤去 データ移行作業の完了後は、作業内容を本町に報告した上で、業務データの消去及び移行データの消去を行うこと。 1-37 その他必要時の支援 本町との協議の上、特定の業務を本町又は他事業者へ引き継ぐ場合においては、引継ぐべき業務の内容について、次の内容を詳細に記録した業務引継書等を作成し、本町に提出すること。 また、受託者は業務引継書等に基づき、被引継者に対し本業務が停滞しないよう十分な説明及びサポートを行うこと。 本町以外の第三者に引継ぎを行う場合、引継ぎ業務には本町の担当者が立会い、その内容について確認を行う。 ＜業務引継書の内容＞① 引き継ぐ業務の流れ② 引き継ぐ業務の進捗状況(予定と実績)③ 構成管理台帳(プログラム及びデータ、ドキュメント等の資産、及び資産の所在と明細(ソフトウェア・ハードウェアの製品情報や数量、パッチ適用履歴等))④ 関連する資料の明細書(③に付帯する情報(ソフトウェア・ハードウェアのカタログ等))⑤ その他円滑な業務引継ぎのために必要となる資料1-38 固定資産税当初賦課前のシミュレーション固定資産税において当初賦課処理を実行する前にシミュレーションを実施し、エラー等の発生を確認すること。 1-39 国民健康保険システムにおけるマスタの保存年限国民健康保険システムにおけるマスタの保存年限は８年間とすること。 業務個別業務引継ぎシステム利用にかかるシステムの運用及び保守に関する要求運用・保守要求 16/11別紙３_役務・運用保守要件一覧(外部委託一覧)※記載の内容は現行システムにおける外部委託一覧であり、提案パッケージにより要否が異なる可能性がある点に留意すること。 # 種別 名称 処理/納品次期 回数/数量町民生活課 住民マスター更新 1 委託処理 住民マスター更新処理 月次 122 委託処理総括表作成年次(12月) 1回3 委託処理特徴納入書作成年次(5月)、月次(5-4月)当初は1回、修更正で12回4 委託処理特徴のしおり作成年次(5月) 1回5 委託処理特徴決定(変更)通知書(特徴義務者用)作成年次(5月) 1回6 委託処理特徴決定(変更)通知書(納税義務者用)作成年次(5月) 1回7 委託処理発送一覧作成(当初)年次(6月) 1回8 委託処理処理件数表(当初)年次(6月) 1回9 委託処理納税通知書(当初・一般用)作成年次(6月) 1回10 委託処理納税通知書(当初・口座用、年金特徴通知)作成年次(6月) 1回11 委託処理特徴決定(変更)通知書(特徴義務者用)作成月次 12回12 委託処理特徴決定(変更)通知書(納税義務者用)作成月次 12回13 委託処理封入、封緘作業(当初)年次(6月) 1回14 委託処理発送一覧作成(修更正)月次 12回15 委託処理処理件数表(修更正)月次 12回16 委託処理課税額変更通知書作成月次 12回17 委託処理納税通知書(随時・一般用)作成月次 12回18 委託処理納税通知書(随時・口座用、年金特徴通知)作成月次 12回19 委託処理納税通知書(過年度)作成月次 12回20 委託処理課税状況調べ用データ作成(ぜいちょう用)年次(7月) 1回21 委託処理納税通知書封入作業 【修更正】月次 12回22 委託処理納税通知書封入作業【当初】(同封物)年次(6月) 1回23 用紙 納税通知書(当初一般) 年次(6月) 2,00024 用紙 納税通知書(当初口座) 年次(6月) 2,00025 用紙 納税通知書(修更正一般、過年度一般) 月次 1,50026 用紙 納税通知書(修更正口座、過年度口座) 月次 1,00027 用紙 特徴納入書 年次・月次 28,00028 用紙 特徴決定(変更)通知書 特徴義務者用 年次(5月)・月次 4,50029 用紙 特徴決定(変更)通知書 納税義務者用(シーラー加工) 年次(7月)・月次 4,50030 用紙 総括表(特徴分) 年次(12月) 3,00031 用紙 特徴のしおり 年次(5月) 2,50032 用紙 封筒A-40(テープ) 月次 80033 用紙 封筒A-40(ヒート) 年次(6月) 2,50034 用紙 同封チラシ(A4両面印刷) 年次(6月) 3,00035 用紙 バッチ番号シール(各市町村共通) 年次(12月) 7136 委託処理評価変動割合調作成年次(6～8月)２回程度 Ａ４ 20㌻37 委託処理土地総評価用資料作成年次(6～8月)２回程度 Ａ４ 20㌻38 委託処理償却資産申告書(償却資産課税台帳)作成年次(11月)１１月申告用Ａ４700㌻２部(控え含む)白紙無し39 委託処理償却資産種類別明細書(資料用)作成年次(11月)１１月申告用Ａ４1000㌻２部(控え含む)白紙無し40 委託処理宛名シール作成年次(11月)１１月 対象データ600件Ｂ４シール枚数30枚41 委託処理コンビニ用納税通知書(一般用)作成年次(４月) ４月 4400枚42 委託処理納税通知書(口座用)作成年次(４月) ４月 2500枚43 委託処理課税明細書(一般、口座兼用)作成年次(４月) ４月 1500枚課 名 業 務 名委託処理一覧税務課住民税、特徴関係綴固定資産税# 種別 名称 処理/納品次期 回数/数量課 名 業 務 名委託処理一覧44 委託処理名寄帳作成(年度末確定分)年次(５月)6月 PDFファイル45 委託処理土地一覧表作成年次(３月) 1400×446 委託処理封入、封緘作業年次(４月) 1回47 委託処理納税通知書封入作業(同封物)年次(４月) 1回48 用紙 納税通知書(一般用) 年次(４月) 5,50049 用紙 納税通知書(口座用) 年次(４月) 3,50050 用紙 課税明細書(一般、口座用) 年次(４月) 2,50051 用紙 封筒A-40(ヒート) 年次(４月) 7,20052 用紙 封筒A-40(テープ) 年次(４月) 1,70053 委託処理納税通知書発送者一覧作成年次(４月) 154 委託処理コンビニ用納税通知書(一般用)作成年次(４月) 155 委託処理納税通知書(口振用)作成年次(４月) 156 委託処理納税通知書封入作業(同封物)年次(４月) 157 委託処理封入、封緘作業年次(４月) 158 用紙 納税通知書(一般用) 年次(４月) 8,00059 用紙 納税通知書(口座用・課税明細) 年次(４月) 2,00060 用紙 封筒A-20(テープ) 年次(４月) 30061 用紙 封筒A-20(ヒート) 年次(４月) 5,10062 用紙 同封チラシ①(B5両面印刷) 年次(４月) 5,10063 用紙 同封チラシ②(B5両面印刷) 年次(４月) 5,10064 委託処理コンビニ用口座振替不能分納付書兼通知書作成月次 12回65 委託処理口座振替納付済通知書(軽自動車用)作成年次(６月) 1回66 委託処理口座振替納付済通知書(全般用)作成年次(12月) 1回67 委託処理コンビニ用督促状(賦課税用)作成月次 12回68 委託処理特徴督促状作成月次 12回69 委託処理催告書作成随時(5月・11月) 2回70 委託処理封入封緘作業(督促状、口振不能通知)月次 24回71 用紙 コンビニ用納付書(賦課税普通・再発行) 随時 7,00072 用紙 コンビニ用督促状(賦課税用) 月次 10,00073 用紙 コンビニ用口座振替不能分納付書兼通知書 月次 2,00074 用紙 口座振替納付済通知書(軽自動車税用) 年次(６月) 2,50075 用紙 口座振替納付済通知書(全般用) 年次(12月) 4,00076 用紙 郵便振替用紙(ブランク用紙) 随時(4月) 50077 用紙 催告書 随時(5月・11月) 3,00078 用紙 封筒A-20(ヒート) 随時 7,70079 用紙 納付通知書封入封緘 随時80 委託処理コンビニ用納付通知書(一般分)作成年次(７月)、月次(８-３月) 981 委託処理コンビニ用納付通知書(過年分)作成月次 1282 委託処理 納付通知書(口座・特徴分)作成 年次(７月)、月次(８-３月) 983 委託処理課税台帳作成(PDF対応)年次(７月)、月次 1284 委託処理賦課決定・更正通知書(期割額明細)月次 1285 委託処理課税状況調(第１表) 加入者の状況に関する調作成年次(６月) 186 委託処理課税状況調(第１表) 加入者の状況に関する調(その２)作成年次(６月) 187 委託処理課税状況調(第１表) 加入者の状況に関する調(その３)作成年次(６月) 188 委託処理課税状況調(第２表) 実績等に関する調(その１，その２)作成年次(６月) 189 委託処理課税状況調(第２表) 実績等に関する調(その３)作成年次(６月) 190 委託処理保険基盤安定 負担金繰入金額算出基礎表(医療分)作成年次(１０月) 191 委託処理保険基盤安定 負担金繰入金額算出基礎表(支援分)作成年次(１０月) 192 委託処理保険基盤安定 負担金繰入金額算出基礎表(介護分)作成年次(１０月) 193 委託処理調整交付金 統計計算集計表作成年次(１０月) 1税務課固定資産税軽自動車税税収納消込国民健康保険税# 種別 名称 処理/納品次期 回数/数量課 名 業 務 名委託処理一覧94 委託処理実態調査(保険者票)作成年次(１０月) 195 委託処理実態調査(世帯票)作成年次(１０月) 196 委託処理調整交付金 本算定時課税台帳集計表(医療分、全体・退職)作成年次(１０月・２月) 297 委託処理調整交付金 本算定時課税台帳集計表(支援分、全体・退職)作成年次(１０月・２月) 298 委託処理調整交付金 本算定時課税台帳集計表(介護分、全体・退職)作成年次(１０月・２月) 299 委託処理調整交付金 本算定時軽減整理表(医療分、全体・退職)作成年次(１０月・２月) 2100 委託処理調整交付金 本算定時軽減整理表(支援分、 全体・退職)作成年次(１０月・２月) 2101 委託処理調整交付金 本算定時軽減整理表(介護分、全体・退職)作成年次(１０月・２月) 2102 委託処理調整交付金 調査時課税台帳集計表(医療分、全体・退職)作成年次(１０月・２月) 2103 委託処理調整交付金 調査時課税台帳集計表(支援分、全体・退職)作成年次(１０月・２月) 2104 委託処理調整交付金 調査時課税台帳集計表(介護分、全体・退職)作成年次(１０月・２月) 2105 委託処理調整交付金 調査時軽減整理表(医療分、全体・退職)作成年次(１０月・２月) 2106 委託処理調整交付金 調査時軽減整理表(支援分、全体・退職)作成年次(１０月・２月) 2107 委託処理調整交付金 調査時軽減整理表(介護分、全体・退職)作成年次(１０月・２月) 2108 委託処理調整交付金 調査時課税台帳(所得更生分)集計整理表(医療分、全体・退職)作成年次(１０月・２月) 2109 委託処理調整交付金 調査時課税台帳(所得更生分)集計整理表(支援分、全体・退職)作成年次(１０月・２月) 2110 委託処理調整交付金 調査時課税台帳(所得更生分)集計整理表(介護分、全体・退職)作成年次(１０月・２月) 2111 委託処理調整交付金 様式第4-1、4-2、第5作成年次(２月) 2112 委託処理調整交付金 様式32、様式AM(非自発的失業者の軽減)作成年次(２月) 1113 委託処理調整交付金 様式AF旧被扶養者の減免作成年次(２月) 1114 委託処理封入封緘作業月次 12115 委託処理納税通知書封入作業(同封物)年次(７月) 1116 用紙 納付通知書(自主分)ブック 年次、月次、随時 2,700117 用紙 納付通知書(口座分)ブック 年次、月次 3,200118 用紙 納付通知書(随時・過年分)ブック 月次、随時 1,500119 用紙 封筒A-40(テープ) 年次、月次 2,100120 用紙 封筒A-40(ヒート) 年次、月次 1,200121 用紙 同封チラシ1枚(税のしくみ) 年次 2,700122 委託処理被保険者証(一般)作成(２年に１回)年次(７月) 1123 委託処理被保険者証(短期証)作成(２年に１回)年次(７月) 1124 委託処理被保険者証(高校生以下短期証)作成(２年に１回)年次(７月) 1125 委託処理前期高齢者受給者証作成年次(７月)、月次(７月を除く) 12126 委託処理被保険者証封入作業(２年に１回)年次(７月) 1127 委託処理高齢受給者証封入作業(２年に１回)年次(７月) 1128 委託処理被保険者証一斉切替処理における証の切り替え期間変更(２年→１年)対応・説明資料作成及びスケジュール作成、調整等年次(７月) 1129 委託処理被保険者証一斉切替処理における証の切り替え期間変更案内文案内文封入年次(７月) 1130 用紙 被保険者証(即時･バッチ兼用､一般･退職兼用)保護シール付) 年次(４月) 5,500131 用紙 前期高齢者受給者証(即時、年次・月次一括兼用) 年次(４月)、月次(７月を除く) 1,800132 用紙 資格証明書 50133 用紙 限度額適用・標準負担額減額認定証 年次(４月) 300134 用紙 標準負担額減額認定証 年次(４月) 50135 用紙 限度額適用認定証 年次(４月) 300136 用紙 特定疾病受療証 年次(４月) 50137 用紙 被保険者証用封筒(2年に1回) 年次(７月) 2,200138 用紙 被保険者証一斉切替処理における証の切り替え期間変更案内文(A4 4色擦り) 年次(７月) 2,200139 委託処理 世帯調査票作成処理 年次(1月) 1140 委託処理 アンケートデータチェック処理 年次(3月) 1141 委託処理 各種検診申込書受入処理 年次(3月) 1142 委託処理 特定健診データ作成処理 年次(4月) 1143 委託処理 受診者番号チェック処理 年次(4月) 1税務課国民健康保険税保健福祉課国保資格住民検診# 種別 名称 処理/納品次期 回数/数量課 名 業 務 名委託処理一覧144 委託処理 結核・肺がん検診データ作成処理 年次(4月) 1145 委託処理 胃がん検診処理 年次(6月) 1146 委託処理 健診案内状作成処理 年次(6月) 1147 委託処理 子宮がんクーポン券出力処理 年次(10月) 1148 委託処理 乳がんクーポン券出力処理 年次(6月) 1149 委託処理 大腸がんクーポン券出力処理 年次(10月) 1150 委託処理 大腸がんデータ作成処理 年次(10月) 1151 委託処理 前立腺がんデータ作成処理 年次(4月) 1152 委託処理 未健者健診用データ作成処理 年次(10月) 1153 委託処理 乳がん検診処理 年次(6月) 1154 委託処理 子宮がん検診処理 年次(10月) 1155 媒体ＣＤ年次 7156 用紙世帯調査表年次(1月) 5,500157 用紙個人情報保護シール(世帯調査表用)年次(1月) 5,200158 用紙スタンダードシート年次(3,4,6,10月) 2,000159 用紙 胃がん検診票 年次(6月) 2,500160 用紙 健診案内状 年次(6月) 5,000161 用紙乳がん検診受検票年次(6月) 2,000162 用紙子宮がん受検票年次(10月) 2,500163 用紙宛名シール年次(10月) 150164 用紙乳がんクーポン券年次(6月) 1,000165 用紙子宮がんクーポン券年次(10月) 1,000166 用紙大腸がんクーポン券年次(10月) 1,200167 委託処理住民税連携情報(当初・更正)月次(4月～3月) 12回168 委託処理新年度所得一括登録(子ども子育て・障害者・母子父子)年次(9月)9月1回/子ども子育て1300、障害者300、母子父子150169 委託処理現況届作成(本)(子ども子育て・障害者・母子父子)⇒現況届・受給資格更新について(通知) (印刷処理)年次(9月)9月1回/子ども子育て1300、障害者300、母子父子150170 委託処理現況届作成 所得一覧表作表(子ども子育て・障害者・母子父子)⇒所得一覧表 (印刷処理)年次(9月)9月1回/Ａ４240㌻171 委託処理資格一括切替(本)(子ども子育て・障害者・母子父子)⇒受給者証・支給停止通知書・資格台帳一覧 (印刷処理)年次(9月)9月1回/子ども子育て1300、障害者300、母子父子150各種一覧 Ａ４ 400㌻受給者証1800㌻172 委託処理国保資格情報連携月次(4月～3月) 12回173 委託処理国保課税区分情報連携月次(4月～3月) 12回174 委託処理償還支払確定処理(本)(子ども子育て・障害者・母子父子)(担当課様処理)⇒支払決定通知書 (印刷処理)月次(4月～3月)12回(印刷のみ)交付決定通知書兼内訳書月次250㌻年間3000㌻175 委託処理国保連合会向け資格データ作成(子ども子育て)月次(4月～3月) 12回176 委託処理資格一括切替(本)(子ども子育て)小学校入学者切替分⇒受給者証・資格台帳一覧 (印刷処理)年次(3月)3月1回/子ども子育て100受給者証 100ページ各種一覧A45ページ177 用紙支払決定通知書月次 4,000178 用紙受給者証(乳幼児医療費)随時、年次 2,000179 用紙受給者証(母子父子医療費)随時、年次 350180 用紙受給者証(心身障害者医療)随時、年次 450保健福祉課住民検診乳・重・ひ医療費助成# 種別 名称 処理/納品次期 回数/数量課 名 業 務 名委託処理一覧181 委託処理納付書作成(子ども子育て印刷処理)年次(3月)1回 125枚(25人×5ヶ月分)182 委託処理納付書作成(子ども子育て印刷処理)年次(８月)1回 125枚(25人×7ヶ月分)183 委託処理納付書作成(児童クラブ印刷処理)年次(4,7,10,1月)4回 240枚(20人×3ヶ月分)184 用紙 納付書(子ども子育て) 随時(庁内発行)、年次(3月) 1,000185 用紙納付書(児童クラブ)随時(庁内発行)、 年次(3月) 1,000186 委託処理確定賦課 保険料納入通知書(自主分)作成年次(７月) 1187 委託処理確定賦課 保険料納入通知書(口振分)作成年次(７月) 1188 委託処理確定賦課 保険料納入通知書(特徴分)作成年次(７月) 1189 委託処理月次修更正 保険料納入通知書(自主分)作成月次(８月～３月) 8190 委託処理月次修更正 保険料納入通知書(口振分)作成月次(８月～３月) 8191 委託処理月次修更正 保険料納入通知書(特徴分)作成月次(８月～３月) 8192 用紙確定賦課 保険料納入通知書(自主分)年次、月次(７月～３月) 1,500193 用紙確定賦課 保険料納入通知書(口振分)年次、月次(７月～３月) 3,500194 用紙確定賦課 保険料納入通知書(特徴分)年次、月次(７月～３月) ー195 用紙過年度修更正 保険料納入通知書(自主分)随時(７月) 2,000196 委託処理納入通知書作成年次(６月) 1197 用紙 納入通知書 年次(６月) 300198 用紙 督促状 随時(７月以降) 200199 委託処理①給報書年次(1月～2月) 2,700200 委託処理②年金支払報告書年次(1月～2月)201 委託処理③年金納付状況一覧表年次(1月～2月) 800202 委託処理申告エントリー処理支援203 委託処理①レイアウト変換処理年次(1月～2月) 3204 委託処理②申告データ給報取込支援年次(1月～2月) 3205 委託処理③エラー分の抽出作業年次(1月～2月) 3206 委託処理④給報エントリーツール修正支援年次(1月～2月) 3207 委託処理 データセットアップ 年次(申告時期：2月) 1208 委託処理 環境セットアップ 年次(申告時期：1月) 1209 委託処理 申告会場セットアップ 年次(申告時期：2月) 2税務課 申告データセットアップ保健福祉課 後期高齢者医療上下水道事業所 受益者負担金税務課 住民税データ作成子育て定住推進課 子ども子育て 別紙４_SLA要求一覧内容 サービスレベル評価項目 定義(測定式) 備考 SLA要求水準可用性 重大障害発生件数(アプリケーション)システム使用不能等の重大な障害発生状況を管理する。 重大障害発生件数(アプリケーション) ・重大障害発生件数※重大障害の定義については本町と協議の上決定するが，全庁的に120分程度の停止を想定している。 0件／月オンライン稼動率 サービス利用時間内(日常業務時間内)のシステム利用可能状況を管理する。 オンライン稼動率 ・「サービス提供時間」÷「サービス利用時間」×100 (％)99.5%以上／月障害復旧時間 障害が発生してから復旧するまでの時間を管理する。 障害復旧時間 ・復旧時間目標(RTO)の設定 復旧とは全機能の復旧を指す。 12時間以内障害回復予定時間の未遵守障害件数予定通り，障害が回復したかを管理する。 障害回復予定時間の未遵守障害件数 ・受託事業者が提示した障害回復予定時間を遵守できなかった障害件数0件／月機器保守完了率 機器等の定期点検のスケジュールを管理し，保守点検を確実に完了する。 機器保守完了率 ・「保守実施済み機器数」÷「保守対象機器数」×100 (％)100%リソース管理 リリースミス障害発生件数 ・リリースミスによる障害発生件数0件／月バーション管理完備率 ・「リソースのバージョン管理登録件数」÷「リリース対象のリソース数」×100 (％)100%性能 バッチ処理異常終了件数 バッチ処理が異常終了した件数を測定し、以降の業務オペレーションへの支障が出ることを防止する。 バッチ処理が異常終了した件数※異常終了の定義は本町との協議とするが、処理自体が異常終了した場合のほか、処理時間が予定より遅延し業務に影響が出た場合や、正常終了したがその処理を起因に別の処理や業務に影響が出た場合なども想定・予め予定されたバッチ処理の異常終了件数当該におけるバッチ処理とは主に夜間のスケジュールバッチを想定し、日中の職員によるオンラインバッチ処理は対象に含まない1件／月要件分類サービス運用時バージョンアップ，カスタマイズ，障害対応等により，システムに適用したリソースのバージョンを適正に管理する。 1/4内容 サービスレベル評価項目 定義(測定式) 備考 SLA要求水準 要件分類オンライン応答時間 ユーザーの業務オペレーションへの支障が出ることを防止するため，オンライン応答時間を監視する。 ユーザーの業務オペレーションへの影響を防止するため，オンライン応答時間を監視する。 ・オンライン応答時間※データ更新，画面遷移，検索機能等本町と予め設定する処理のについて，オペレーションを開始できる状態になるまでの応答時間を分析アクセス集中時のオンライン応答時間は5秒以内とする。 なお、通信環境等、受託者以外に起因するオンラインレスポンス遅延の場合でも、原因等の調査については受託者においても実施すること。 3秒以内ディスク使用率警告通知時間 ・ディスク使用率の閾値越えを検知してから本町担当へ報告するまでの時間10分以内CPU使用率警告通知時間 ・CPU使用率の閾値越えを検知してからするまでの時間10分以内メモリ使用率警告通知時間 ・メモリ使用率の閾値越えを検知してからするまでの時間 10分以内機密性 システム利用実績管理 システムログイン／ログアウト情報のログ等，システム利用実績を定期的に収集し，不正等を監視する・システムログイン／ログアウトに関するログ集計から通知までの時間・ログを集計してから通知するまでの時間※月次での集計・報告を想定している。 運用保守報告会での報告とする場合は，本町と協議の上，その開催日程に拠るものとする30日以内セキュリティウィルス検出通知時間 ウイルス感染により，システム停止等重大障害に繋がる可能性があるため，ウイルスに感染されていなか，定期的に監視する。 監視の結果，ウイルス感染が確認された場合は，影響範囲の一時切り分け，ネットワーク切断等の対処を実施する。 ウィルス検出通知時間 ・ウイルス感染発見から，本町担当者へ通知するまでの時間※監視ソフトウェアからの自動通知も可とする5分以内最新パターンファイル適用時間最新のウイルスに対応したパターンファイルの適用状況を管理する。 最新パターンファイル適用時間 ・最新パターンファイルの公開から適用までの時間24時間以内最新セキュリティパッチの適用時間適用する必要があるセキュリティパッチを確実に適用されたかを管理する。 最新セキュリティパッチの適用時間 ・最新セキュリティパッチ公開から本町担当者へ通知するまでの時間と本町担当者へ通知後，パッチ適用可否を決定(分析)し，通知するまでの時間15日以内リソース監視 システム安定稼動を確保するために，必要だと思われる項目を監視する。 閾値の瞬間的な超過は含まない。 2/4内容 サービスレベル評価項目 定義(測定式) 備考 SLA要求水準 要件分類運用保守ヘルプデスクの応答時間 サポート時間内の問い合わせに対して、遅延無く対応する。 一次回答時間 ・問い合わせの連絡をヘルプデスクが受けてから、問い合わせ職員へ一次回答を行うまでの時間 24時間以内運用保守報告会の開催 運用保守報告会が開催されたかを管理する。 運用保守報告会の開催回数 ・月次の開催回数(仕様書に記載のテーマを)※事前の日程調整により，N月度分がN+1月に実施された場合も，N月度分とみなす合理的な理由がある場合は，事前に本町と協議の上，開催を見送ることを可とする。 1回／月SLAモニタリング結果の報告 SLAのモニタリング結果が報告されたかを管理する。 SLAのモニタリング結果の報告回数 ・月次の報告回数※事前の日程調整により，N月度分がN+1月に報告された場合も，N月度分とみなす合理的な理由がある場合は，事前に本町と協議の上，報告を見送ることは可とする。 1回／月サービスレベル四半期報告会の開催サービスレベル四半期報告会が開催されたかを管理する。 サービスレベル四半期報告会の開催回数 ・四半期毎の報告回数※月次の運用保守報告会と同時に実施する場合は，モニタリング結果の分析及び達成できていない項目の改善案等の提案等が行われたことで，サービスレベル四半期報告会が開催されたとみなす合理的な理由がある場合は，事前に本町と協議の上，報告を見送ることは可とする。 1回／四半期障害発生通知 障害を検知してから，本町監督職員へ報告するまでの時間を管理する。 ※休日及び夜間において影響が出ないと推測される場合に限っては事後報告を可とする・障害発生通知時間 ・障害を検知してから本町担当職員に報告するまでの時間※受託事業者の故意または過失により，障害検知が遅れた場合は，障害が発生したと想定される時間からの計測とする10分以内帳票アウトソーシングの納品 帳票アウトソーシングの仕様に定める納品期限に対して、適切に納品を行う。 ・納品期日遵守率 ・納品期日までに納品されなかった回数※天災や本町作業都合等その責めに帰することができない事由を除く 0回／月3/4内容 サービスレベル評価項目 定義(測定式) 備考 SLA要求水準 要件分類業務影響作業品質 受託事業者の実施する作業に起因した，本町の業務品質に影響のある障害等事象を管理する。 業務遂行に関連して，受託事業者の作業に起因する以下の事象が発生していないこと。 ・重大な直接的本町民影響の事故事象(庁外)の発生(誤送付，誤計算，期間・期日誤りの通知書/証の発送/発布)・直接的な本町民影響の事故事象(庁内)の発生(処理停滞/出力遅れなどによる窓口業務の遅延)・業務遂行上の事故事象の発生(一括処理や締め処理の遅延・再処理)緊急事態報告，受託事業者の障害報告等から事故事象の発生回数をカウントする。 遅延や再処理について本町と事前に協議／合意された合理的な判断のもとに発生した業務影響については，これを除外する。 0件／月4/4 改定履歴シート※集計機能要件一覧項目詳細一覧エラー・アラート項目一覧帳票関連項目等一覧参照事項一覧(参考)内部帳票についてペーパーレスで行う方法の例(参考)統合記載欄Ｂ類型・Ｃ類型記載例住民記録システム標準仕様書_機能要件【第5.0版】,機能・帳票要件【改定履歴】,版数,改定日,主な改定理由,機能ID,機能IDの変更状況(削除／新規付番／変更なし),適合基準日,第1.0版,2020/09/11,初版公開,ー,ー,ー,第2.0版,2021/08/31,第2.0版公開,ー,ー,ー,第3.0版,2022/08/31,第3.0版公開,ー,ー,ー,第4.0版,2023/03/31,第4.0版公開,ー,ー,ー,第4.1版,2023/08/31,行政事務標準文字の市区町村間における連携方法の明記、誤記訂正,0010018,変更なし,2026/04/01,0010235,変更なし,2026/04/01,0010239,変更なし,2026/04/01,0010242,変更なし,2026/04/01,0010256,変更なし,2026/04/01,0010443,変更なし,2026/04/01,0010444,削除,2026/04/01,0010459,変更なし,2026/04/01,0010465,変更なし,2026/04/01,0010468,削除,2026/04/01,0010471,変更なし,2026/04/01,0010477,削除,2026/04/01,0010478,削除,2026/04/01,0010487,削除,2026/04/01,0010529,新規付番,2026/04/01,0010530,新規付番,2026/04/01,0010531,新規付番,2026/04/01,0010532,新規付番,2026/04/01,0010533,新規付番,2026/04/01,0010534,新規付番,2026/04/01,0010535,新規付番,2026/04/01,第5.0版,2024/01/31,氏名の振り仮名法制化に伴う修正、誤記訂正等,0010001,削除,2026/04/01,0010018,削除,2026/04/01,0010022,削除,2026/04/01,0010033,削除,2026/04/01,0010035,削除,2026/04/01,0010043,削除,2026/04/01,0010045,削除,2026/04/01,0010052,変更なし,2026/04/01,0010077,削除,2026/04/01,0010078,削除,2026/04/01,0010081,変更なし,2026/04/01,0010084,削除,2026/04/01,0010095,変更なし,2026/04/01,0010164,変更なし,2026/04/01,0010166,削除,2026/04/01,0010171,変更なし,2026/04/01,0010183,削除,2026/04/01,0010202,削除,2026/04/01,0010226,削除,2026/04/01,0010227,変更なし,2026/04/01,0010233,変更なし,2026/04/01,0010235,削除,2026/04/01,0010239,削除,-,0010240,削除,2026/04/01,0010242,削除,2026/04/01,0010244,削除,-,0010305,削除,-,0010306,削除,-,0010307,削除,-,0010308,削除,-,0010315,削除,2026/04/01,0010318,削除,-,0010326,変更なし,2026/04/01,0010441,変更なし,2026/04/01,0010443,削除,2026/04/01,0010453,変更なし,-,0010456,変更なし,2026/04/01,0010457,削除,2026/04/01,0010459,削除,2026/04/01,0010469,削除,-,0010471,変更なし,2026/04/01,0010473,変更なし,2026/04/01,0010479,削除,-,0010481,削除,2026/04/01,0010483,削除,2026/04/01,0010484,削除,2026/04/01,0010525,削除,2026/04/01,0010528,削除,-,0010531,削除,2026/04/01,0010532,削除,2026/04/01,0010536,新規付番,2026/04/01,0010537,新規付番,2026/04/01,0010538,新規付番,2026/04/01,0010539,新規付番,2026/04/01,0010540,新規付番,2026/04/01,0010541,新規付番,2026/04/01,0010542,新規付番,2026/04/01,0010543,新規付番,2026/04/01,0010544,新規付番,-,0010545,新規付番,2026/04/01,0010546,新規付番,2026/04/01,0010547,新規付番,2026/04/01,0010548,新規付番,2026/04/01,0010549,新規付番,2026/04/01,0010550,新規付番,2026/04/01,0010551,新規付番,2026/04/01,0010552,新規付番,2026/04/01,0010553,新規付番,-,0010554,新規付番,2026/04/01,0010555,新規付番,2026/04/01,0010556,新規付番,-,0010557,新規付番,2026/04/01,0010558,新規付番,-,0010559,新規付番,-,0010560,新規付番,-,0010561,新規付番,-,0010562,新規付番,-,0010563,新規付番,2026/04/01,0010564,新規付番,-,0010565,新規付番,2026/04/01,0010566,新規付番,2026/04/01,0010567,新規付番,2026/04/01,0010568,新規付番,2026/04/01,0010569,新規付番,2026/04/01,0010570,新規付番,-,0010571,新規付番,2026/04/01,0010572,新規付番,-,0010573,新規付番,2026/04/01,0010574,新規付番,2026/04/01,0010575,新規付番,2026/04/01,住民記録システム標準仕様書_機能要件【第5.0版】,集計用シート,住民記録システム機能要件合計,凡例：,要望オプション数,◎,〇,×,◎：パッケージ標準機能として実装,7,0,0,0,○：パッケージ標準機能以外による実装(外付けプログラム等),×：対応不可,住民記録システム標準仕様書_機能要件【第5.0版】,凡例：類型①：業務運用上必要な要件(対応不可の場合代替案記載)③：業務運用上実装されるとよい要件-：評価対象外,凡例：◎：パッケージ標準機能として実装○：パッケージ標準機能以外による実装(外付けプログラム等)×：対応不可,機能・帳票要件(第5.0版)_機能・帳票要件一覧,【実装区分の凡例】◎：実装必須機能、○：実装オプション機能、×：実装不可機能、－：対象外,要件種別,機能名称,改定種別(直前の版から改定した項目の種別),機能ID,機能要件,実装区分,要件の考え方・理由,備考(改定内容等),適合基準日,類型,備考,貴社システム対応度,代替手段,備考,中分類,小分類,指定都市,中核市,一般市区町村,機能要件,1 管理項目,1.1 住民データ,1.1.1 日本人住民データの管理,修正,0010536,日本人住民について、以下の項目を管理(※)すること。 ※「管理」とは、データの設定・保持・修正ができることをいう。 (シート「項目詳細一覧」を参照),◎,◎,◎,中核市市長会ひな形に付記「住所を定めた年月日」は転入時には入力する必要はないため、入力項目には含めず、また、住民票の写し等の証明書上も表示しない。 ただし、転居していない場合の「住所を定めた年月日」は「住民となった年月日」と同じであるため、その場合、データ上は「住所を定めた年月日」は「住民となった年月日」と同じ日付を保持することとする。 なお、指定都市においては、「住民となった年月日」は市の住民となった年月日を入力するため、区間異動時には「住民となった年月日」を引き継ぐ必要があり、住民票の写し等の証明書上にも表示する。 生年月日については、住基ネット上は、日本人住民は和暦で管理されていることから、住民記録システムにおいても日本人住民は和暦で管理することとする。 ただし、データベースに保持する形式として西暦も許容するが、入出力において和暦に変換する機能を備えること。 住所、本籍、転入前住所、転出先住所については、都道府県名についても省略せずに管理すること(1.1.2についても同様)。 「データ要件・連携要件標準仕様書」に規定されているデータ要件の標準に基づき、住民種別については日本人住民・外国人住民を、住民状態については住登者・転出者・死亡者・その他消除の区分を管理することとする(1.1.2についても同様)。 抑止フラグはエラー(処理不可)、アラート(処理可)をはじめ複数に分けて管理することも可能である(1.1.2についても同様)。 戸籍の表示(筆頭者)の振り仮名については、ベンダ意見照会の中で現在も管理していないため不要との意見が多かったことから、管理する項目としていない。 本仕様書において「振り仮名」は、日本人氏名における振り仮名を指す(旧氏並びに外国人氏名及び通称の場合は「フリガナ」とする。)。 ,【第5.0版】機能ID：0010001から変更氏名の振り仮名法制化に伴い「項目詳細一覧」を修正及び「要件の考え方・理由」を補記,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.1 日本人住民データの管理,0010002,日本人住民について、以下の項目を管理すること。 (シート「項目詳細一覧」を参照),○,○,○,「旧世帯主(転入前の世帯主の氏名)」の情報は、住所地における戸籍の附票記載事項通知情報の入力に際し、任意項目であるため、標準オプション機能とした。 ,ー,-,機能要件,1 管理項目,1.1 住民データ,1.1.2 外国人住民データの管理,0010003,外国人住民(法第30条の45に規定する外国人住民をいう。以下同じ。)について、以下の項目を管理すること。 (シート「項目詳細一覧」を参照)※外国人住民の生年月日及び法第30条の45の表の規定区分ごとの事項のうち、在留期間の満了の日は、西暦で記載すること。 ,◎,◎,◎,法改正により外国人住民も住民基本台帳に記録されることとなった。 その際、記載事項、通称の管理方法及び通称の履歴管理方法について規定された。 生年月日については、住基ネット上は、外国人住民は西暦で管理されていることから、住民記録システムにおいても外国人住民は西暦で管理することとする。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.2 外国人住民データの管理,0010004,外国人住民について、以下の項目を管理すること。 (シート「項目詳細一覧」を参照),○,○,○,ー,ー,-,機能要件,1 管理項目,1.1 住民データ,1.1.3 個人票／世帯票,0010005,住民票を個人を単位として調製できること。 なお、個人を単位として調製できるとは、データの保有方法を問わず、住民票の写し等の交付の際に個人を単位として出力できる状態を指し、現在、データの保有方法を、世帯を単位として調製している自治体においても、住民票の写し等の交付の際に個人を単位として出力できるようにする場合については、当該機能を備えているものとみなす。 ,◎,◎,◎,法第６条第１項で「市町村長は、個人を単位とする住民票を世帯ごとに編成して、住民基本台帳を編成しなければならない。」と規定されていることから、本仕様書においては、住民票は個人を単位として調製するものとする。 なお、現在、データの保有方法を、世帯を単位として調製している自治体が存在することから、そのような自治体においても、住民票の写し等の交付の際に個人を単位として出力できるようにする場合については、当該機能を備えているものとみなすこととした。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.3 個人票／世帯票,0010006,世帯全員分の住民票の写し等の交付の際には、20.1.3で規定する様式レイアウトのとおり、世帯連記式(データベース上は個人単位で管理し、帳票としての出力時に世帯単位でデータを作成する方式)によっても出力できること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.4 改製,0010007,住民票(原票)は、欄の大きさの上限(履歴を保持できる上限回数のこと。)を設けず、満欄による自動改製は行わないこと。 住民票(原票)は、任意のタイミングで手動改製ができること。 特別な事由(特別養子縁組、特別養子縁組離縁、性別の変更)がある場合、異動履歴を住民票(原票)に記載し、改製しないこととすることができ得るが、住民票の写し等の証明書で履歴を記載する場合、デフォルトでは、特別な事由の履歴は記載しないようにすること。 ,◎,◎,◎,履歴が満欄になった場合、改製を行う自治体があるが、磁気ディスクにおいて住民票(原票)を管理する場合で、システム上の費用等の課題がない場合は、欄の大きさの上限を設けず、満欄による自動改製は行わないようにする。 住民票の写し等に記載する履歴が多すぎることを避けるというニーズや住民票の写し等に記載しない方が住民ニーズにかなう履歴があるというニーズに対して自動改製を行う自治体もあるが、これらについては、20.0.3(異動履歴の記載)において、住民票(原票)の記載事項から、住民票の写しや住民票記載事項証明書等の証明書に記載する履歴と記載しない履歴を区分できる機能を設けることで対応する。 ただし、住民票(原本)については、満欄による自動改製を行わないこととし、法においては、市区町村長の判断により改製が可能であることから、任意改製の機能も設けることとする。 もっとも、住民票の写し等の証明書に記載する履歴については、20.0.3(異動履歴の記載)のとおり記載の有無を区分できることとしており、特別養子縁組、特別養子縁組離縁及び性別の変更についてはデフォルトで非表示となるため、ベンダ変更や市町村合併等の場合を除き、住民票(原票)に対する任意改製は実質的にあまり発生しないと想定している。 また、「市町村長は、住民票を改製する場合には、当該住民票の消除前又は修正前の記載の移記を省略することができる」(令第13条の２)とされていることから、改製する場合においても最新の履歴以外を移記することは許容されている。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.4 改製,0010008,改製を行った年月日を管理できること。 ,◎,◎,◎,住民票(原票)に対する改製の有無を明らかにするため、改製を行った年月日を管理する。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010009,住民票(原票)を消除又は改製したときは、除票とすること。 転出による消除については、転出予定年月日又は転入通知に記載された転入日のいずれか早い日で消除すること。 ,◎,◎,◎,中核市市長会ひな形では、「改製原住民票」という用語が用いられているが、改製された住民票(原票)は、制度上、除票に包含されるものであることから、本仕様書においては、「改製原住民票」という用語は用いず、「除票」に統一する。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010010,特別養子縁組の成立に伴う転出の場合に、養子の除票に係る転出先の住所を空欄にできること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010011,法第15条の３で規定する除票の記載事項及び統合記載欄に誤記があることが判明した場合、留意事項(1.1.14のＣ類型)に誤記である旨及び誤記修正後の記載等を入力すること。 ,◎,◎,◎,デジタル手続法による法の一部改正(令和元年６月20日施行)により、住民票(除票を含む。)情報が情報システムで活用する行政事務の基盤(個人番号や住民票コードの原本情報)であること、所有者不明土地問題への対応等、現在の居住関係の公証につながる「過去の居住関係」が公証されることへのニーズの高まり等を踏まえて、除票が公証基盤として法令上明確に位置づけられた。 これにより、除票となった時点の情報を正確かつ確実に記録しておくことが必要であることから、除票の記載事項は修正しないこととされた。 よって、万が一、誤記が判明した場合は、除票の記載事項を直接修正せず、除票の留意事項(Ｃ類型)に誤記である旨及び誤記修正後の記載等を入力しておくこととする。 また、除票の記載事項ではない事項に誤記があることが判明した場合、留意事項(1.1.14のＣ類型)に誤記である旨及び誤記修正後の記載等を入力できること。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010012,除票となるまでは、現存者として、残存世帯員とともに続柄も管理しながら住民票の写し等の証明書を出力できること。 ,◎,◎,◎,転出予定年月日の前日まで除票ではなく通常の住民票として扱う必要があり、住民票の写し等の証明書を出力する際も、現存者として残存世帯員とともに出力できる仕組み又は操作手段を備える必要がある。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010013,除票の管理方法としては、除票となった後、9.3(除票用データベースへの移行)により除票用データベースに移行されるまでは住民記録システムデータベースに保管すること。 除票用データベースに移行された後は、消除後150年を経過するまで、除票用データベースにおいて管理すること。 ,◎,◎,◎,現行令上、除票は150年保存とされているが、除票の写しの交付請求において、除票となった当時のそのままの様式で出力するために当時のシステム等を保有し続けることは、将来に渡り市区町村の大きな負担となり、そもそも、デジタル社会において効率的な運営とはいえない。 また、住民基本台帳の電算化を実施した時点で、既に除票となった時点での様式を出力することは不可能となっており、法における住民票の写し等の交付制度上も公証することとされているものは、記載事項のみであるため、法制度上、除票の出力において、過去の様式を維持することまでは求められていないものと解される。 さらに、長期保存の除票の利用については、頻度も少ないと思料されることから限定的な機能とシステムで運用することが適切と考えられる。 そのため、長期的に見た場合に問題や膨大なコストが発生する可能性の低い除票データを別データベースで管理すること(30.1参照)。 また、データのレイアウトについては、連携やデータ移行が円滑化し、庁内外のデータ連携がより容易となるとともに、地方公共団体が、性能・コスト等によりすぐれた標準準拠システムを提供する事業者に、自由に変更できる環境を実現するため、デジタル庁が規定する「データ要件・連携要件標準仕様書」におけるデータ要件の標準に従うこととする。 (技術的基準はシート「参照事項一覧」を参照),2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010014,ユーザインタフェースの工夫(例：１つの除票検索ボタンを押せば、まず住民記録システムデータベースにある除票を検索し、該当者がなければ除票用データベースにある除票を検索する)により、簡易な操作で住民記録システムデータベースと除票用データベースの２つのデータベースを検索することができること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010015,１年に１回以上、市区町村ごとに繁忙期を避けて、消除から５年を経過した除票について、バッチ処理により、除票用データベースへの移行作業を行うこと。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010016,除票は、磁気ディスクにより処理年月日順に記録しておくこと。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.5 除票,0010017,除票固有の記載事項については、1.1.14(統合記載欄)に記載すること。 (シート「項目詳細一覧」を参照),◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.6 空欄,修正,0010537,1.1.1(日本人住民データの管理)及び1.1.2(外国人住民データの管理)に規定する項目のうち、以下の項目は、空欄を許容しないこと。 その他の項目は、「基本データリスト」を参照すること。 (シート「項目詳細一覧」を参照),◎,◎,◎,日本人住民の氏名については、出生届において名が未定の場合があるが、氏は必ず記載されることから、氏名の項目としては空欄を許容しない。 また、出生届は14日以内に届け出る必要があり、性別が空欄の戸籍ができることがある。 戸籍の記載において性別が空欄となっている場合は、原則としては、戸籍の取扱いに準ずることとなるため、戸籍に関する届出上許容されている場合は住民票の記載時は空欄とし、確定し次第、職権で記載する。 ※出生届に至らない子及び就籍の届出に至らない者については、1.1.12 参照。 児童養護施設へ入所する者については、世帯主や続柄の欄は空欄となる場合があり(総務省通知(昭和43年３月26日自治振第41号)第２問６)、空欄を許容することとする。 実例上、特別養子縁組の場合には、転入前住所を空欄としても差し支えないこととされている。 個人番号については、障害発生時や休日開庁等で個人番号が生成できない場合であっても、届出の受理又は証明書の交付が必要となる場合が想定されるため、記入漏れを防ぐためアラートによる注意喚起を行いつつ、空欄を許容することとしている。 空欄を許容する項目について、構成員及び準構成員に意見照会を実施したところ、かなり前から住んでいて住民となった年月日が分からない人がいるため、住民となった年月日は空欄を許容すべきであるという意見があったが、基本的に空欄となるのは該当がないか、そもそも存在しない項目であり、住民となった年月日のように該当しない人や存在しない人がいない項目については、不詳日入力ができれば空欄を許容しないことで問題なく、むしろ記載漏れでないことが確認できるため、住民となった年月日は空欄を許容しない項目として整理する。 なお、除票については、除票となった時点で制度上存在しなかった記載項目は空欄となり得るため、そのような項目については空欄を許容することとした。 ,【第5.0版】機能ID：0010018から変更空欄を許容しない項目に日本人氏名を追加修正及び「要件の考え方・理由」を補記,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.7 旧氏・通称,0010019,請求に基づき、旧氏の記載、変更及び削除ができること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.7 旧氏・通称,0010020,申出に基づき、通称の記載及び削除ができること。 ,◎,◎,◎,平成21年の法改正により外国人住民も住民基本台帳に記録されることとなり、外国人住民の通称の記載及び削除に関する事項の住民票への記載等について令に規定された。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.7 旧氏・通称,0010021,国外へ転出した者が、その後最初の国外からの転入時に、転出時と同一の市区町村へ転入する場合、国外への転出時に記載していた旧氏又は通称を取り込むことができること。 ,◎,◎,◎,旧氏を併記したまま国外へ転出し、その後最初の国外からの転入時に、転出時と同一の市区町村へ転入する場合、旧氏の登録は申出に基づき、当該旧氏を引き続き記載するもので、国外転出時に記載していた旧氏を再び使用する場合に取り込むことができる機能は、記載にかかる補助機能に留まるものである。 通称を登録したまま国外へ転出した者が、同一の市区町村に転入した場合においては、通称の登録は申出に基づき記載をするもので、国外転出時に記載していた通称を再び使用する場合に取り込むことができる機能は、記載にかかる補助機能に留まるものである。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.8 年月日の管理,修正,0010538,年月日は、暦上日に限り、許容すること。 ただし、1.1.1(日本人住民データの管理)、1.1.2(外国人住民データの管理)に規定する項目のうち1.1.1(日本人住民データの管理)に規定する生年月日、住民となった年月日、住所を定めた年月日、改製記載年月日、改製消除年月日及び外国人住民となった年月日並びに1.2.2(異動事由)に規定する項目のうち出生、死亡又は失踪に係る異動日については、暦上日以外の年月日(例：うるう年でない年における２月29日)も許容するとともに、以下に規定する不詳日入力一覧の不詳日を許容すること。 1.1.2(外国人住民データの管理)に規定する生年月日については、以下 に規定する外国人住民の生年月日不詳日入力一覧の不詳日を許容すること。 (シート「項目詳細一覧」を参照)なお、暦上日以外の年月日(例：うるう年でない年における２月29日)、明治45年７月30日及び大正15年12月25日の設定も許容する。 年月日の入力や管理については、1.1.1の生年月日及び1.1.2の生年月日を除き、和暦・西暦どちらを用いても差し支えない。 ,◎,◎,◎,法施行前から住民である等、住民となった年月日が不明であるケースがあることから、住民となった年月日、住所を定めた年月日及び外国人住民となった年月日について、不詳日を許容する。 改製記載年月日、改製消除年月日及び再製記載年月日について原則不詳日は認められないが、古くから記録されている住民票において不詳となっている場合が考えられるため、不詳日の設定を許容することとした。 暦上日以外の年月日(例：うるう年でない年における２月29日)については、本来、存在しない日付を許容すべきではないが、戸籍側(本籍地)が修正せず、住民記録側では修正できないことがあることから、許容する。 また、準構成員から、明治45年７月30日及び大正15年12月25日と記載した住民票が存在しているとの指摘があったことから、これらの日付も許容する。 同様に、「頃」と「不詳」の使い分けについても、戸籍システムでの整理と連動するため、住民記録側では整理しない。 外国人住民の住民票の生年月日の記載は、在留カード等の記載に合わせる必要があるため、生年月日が不詳の場合の在留カード等の記載に応じた入力を許容している。 ,【第5.0版】機能ID：0010022から変更外国人住民の生年月日を不詳日入力する場合の記載表記を追加修正及び「要件の考え方・理由」を補記,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.8 年月日の管理,0010023,住基ネットに送信する際は必要な変換を行うこと。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.8 年月日の管理,0010024,他システムとは「不詳」のまま連携し、不詳日の値については、住基ネットへ送付するコード定義に基づき規定する。 なお、この場合も、内部的には日付を保有しておくこと。 ,◎,◎,◎,内部的に日付がない場合、例えば、ある業務システムでは有効な個人番号が他の業務システムにおいては無効とされ、個人番号から特定の個人を検索した場合に該当しない等の個人番号連携エラーが発生するおそれがあり、住民記録システムと連携するシステム内部では年月日の全てを保有しておく必要がある。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.8 年月日の管理,0010025,みなし生年月日等を作成できること。 ,×,×,×,不詳日の場合、他業務システム側でそれぞれの都合に応じて前寄せ・後寄せを判断する必要があること(例：保険系業務において、加入者に有利となるよう後寄せする等)、また、みなし生年月日等を入力することとした場合、連携先においてみなし生年月日等か否かを判断できないとの意見があったことから、住民記録システムとしては、みなし生年月日等は作成しない(「不詳」のまま、他システムと連携する。なお、不詳日の値については、住基ネットへ送付するコード定義に基づき規定する。)。 ,ー,機能要件,1 管理項目,1.1 住民データ,1.1.9 年月日の表示,0010026,年月日は、住民票の写し等の証明書及び画面表示において、和暦で記載・表示すること。 ただし、1.1.2(外国人住民データの管理)に規定する項目のうち、外国人住民の生年月日及び法第30条の45の表の規定区分ごとの事項のうち在留期間の満了の日は、西暦で記載・表示すること。 上記の記載・表示のため1.3.6(和暦・西暦管理)による適切な変換機能を備えていること。 ,◎,◎,◎,市区町村によって和暦と西暦が異なると、システムが複雑になる上、QRコード化やOCR読込みに支障が出るため、本仕様書において、「西暦で表記すること」と整理しているもの以外は、全て和暦で表示することとする。 なお、これは証明書等で表示する際のルールであり、入力やデータの持ち方としては、和暦と西暦のどちらを用いても、記載・表示する際や他システム連携の際に適切に変換できれば差し支えない。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.9 年月日の表示,0010027,年月日(1.1.2(外国人住民データの管理)に規定する項目のうち、外国人住民の生年月日及び法第30条の45の表の規定区分ごとの事項のうち在留期間の満了の日を除く。 )を、住民票の写し等の証明書又は画面表示において、西暦で記載・表示(併記を含む。)すること。 1.1.2(外国人住民データの管理)に規定する項目のうち、外国人住民の生年月日及び法第30条の45の表の規定区分ごとの事項のうち在留期間の満了の日を、和暦で記載・表示(併記を含む。)すること。 ,×,×,×,ー,ー,機能要件,1 管理項目,1.1 住民データ,1.1.10 世帯主,0010028,世帯主未設定を許容すること。 ,◎,◎,◎,世帯主が死亡した場合等、直ちに世帯主を設定できない場合がある。 養護施設に居住する児童の場合、世帯主の欄は空欄となる場合がある。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.10 世帯主,0010029,世帯主未設定の場合は、世帯主未設定の状態で他システムへ連携ができること。 未設定世帯に属する世帯員を従前の続柄の状態又は空欄の状態で他システムへ連携ができること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.11 続柄,0010030,以下に示す続柄を管理できること。 (シート「項目詳細一覧」を参照)※「世代」とは、「の」でつなげる個数を機械的に数えたものをいう。 (留意点)・世帯主との関係を示す上で複数の表記があり得る場合、5.2で定める世帯員の記載順位において最も上位のものとすること(例：世帯主の父の兄の子が同時に世帯主の妻でもある場合、続柄は「妻」とする。)。 ・③を５世代以上つなげる必要がある場合(例：子の子の子の子の子)は、「縁故者」とすること。 ・外国人住民の続柄については、世帯主との続柄を証する文書(戸籍法(昭和22年法律第224号)に基づく届出に係る受理証明書若しくは記載事項証明書又は結婚証明書若しくは出生証明書その他外国政府機関等が発行した文書であって、本人と世帯主との続柄が明らかにされているもの)、住民票の写し、住民票記載事項証明書、住民票の除票の写し、住民票除票記載事項証明書によって確認した世帯主との続柄とすること。 また、世帯主との続柄を証する文書等が提出されず、事実上の親族関係が認められる場合には、世帯主との続柄は「縁故者」とすること。 ,◎,◎,◎,世代管理については、４世代以内で管理しているケースが多いことから、４世代までの管理とした。 要領第２－１－(2)－エ－(ｵ)に記載されている続柄を全て表示できる必要がある。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.11 続柄,0010031,「実装必須機能」に示す以外の続柄(例：祖父、祖母、おじ、おば、甥、姪、孫、家事使用人、準世帯主、４世代以内で表記できない続柄)を管理できること。 ,×,×,×,市区町村によっては実装されている「準世帯主の登録が行えること。」のような準世帯主は、国民健康保険上の概念であるため、本仕様書では不要と整理した。 また、J-LIS提供の「既存住基システム改造仕様書」の続柄コードには、「祖父」、「祖母」、「おじ」、「おば」、「甥」、「姪」等、一部ベンダでは入力できない可能性のある続柄が存在するが、分科会における議論の結果、これらは４世代以内で表記するか、４世代で記載できない場合は、「縁故者」として記載することで足りるため、これらの続柄に対応することは不要と判断した。 ,ー,機能要件,1 管理項目,1.1 住民データ,1.1.12 本籍・筆頭者,0010032,本籍・筆頭者欄は、「なし」又は「不明」と記載できること。 ,◎,◎,◎,総務省通知(平成30年10月２日総行住第163号)によれば、就籍の届出に至らない者については、本籍・筆頭者欄を「なし」と記載することとされている。 また、総務省通知(平成20年７月８日総行市第145号)によれば、出生届の提出に至らない子については、本籍・筆頭者欄を「なし」と記載することとされている。 また、実例上、記憶喪失等により本籍・筆頭者が明らかでない場合には「不明」と記載することとされている。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.13 宛名番号・世帯番号,修正,0010539,宛名番号及び世帯番号は、自動付番できること。 宛名番号及び世帯番号はそれぞれ、最下位の１桁を除いて単純連番方式で付番し、最下位の１桁はチェックデジットとする。 チェックデジットの算出方式はモジュラス11(M11W２～７)とする。 余りが０又は１の場合、検査付番は０とする。 また、本ルールの適用は新規付番に限り、付番済み番号の再付番は不要とする。 ,◎,◎,◎,外国人住民の宛名番号を日本人住民と異なる番号体系にしている市区町村等、宛名番号に意味付けを持たせている市区町村もあるが、今回、帰化、国籍取得及び国籍喪失の場合も、宛名番号を引き継ぐこととしたことから(4.5.3～4.5.5参照)、日本人住民・外国人住民を問わず、共通したルールに基づいて宛名番号を設定することとする。 構成員・準構成員意見照会の結果、指定都市における区間異動の場合、宛名番号と世帯番号の付番ルールが区ごとに異なるため、カスタマイズになりやすいという意見があったため、付番ルールを整理。 ,【第5.0版】機能ID：0010033から変更余りが１の場合についての記載を追加修正,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.13 宛名番号・世帯番号,0010034,指定都市における区間異動の場合、世帯番号は新規付番し、宛名番号は異動前と同一の番号を使用すること。 ,◎,ー,ー,指定都市における区間異動の場合、転入元の世帯の住民票(原票)が除票となり、新たに転入地の区で住民票(原票)が調製されることになるため、除票となった住民票(原票)と新たに調製された住民票(原票)で同一の世帯番号を使用することとすると、管理上不都合が生じる可能性があるため、区間異動の場合の世帯番号は新規付番することとする。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.14 統合記載欄,修正,0010540,統合記載欄に異動履歴(Ａ類型)及びそれに関係する留意事項(Ｂ類型)並びに異動履歴に関係しない事項である備考(Ｃ類型)を入力できること。 留意事項については、直接関係する異動項目とひもづけて管理するとともに、20.0.3(異動履歴の記載)により統合記載欄に記載すること。 他方、備考については異動履歴とは別に管理し、20.0.5(備考の記載)により統合記載欄に記載すること。 ,◎,◎,◎,従来、住民票(原票)の統合記載欄に記載されている事項は、以下のとおり、３つに大別することができる。 Ａ類型・・・「年月日」／「異動事由等」／「記載等の種別」(届出・職権・申出・請求の別)で構成されるもの(20.0.3(異動履歴の記載)参照)(例)異動履歴、改製年月日Ｂ類型・・・Ａ類型にひもづく留意事項Ｃ類型・・・それ以外の事項(備考)(各類型の記載例については、シート「(参考)統合記載欄Ｂ類型・Ｃ類型記載例」を参照)Ａ類型については、1.2.1(異動履歴の管理)に規定する異動履歴として管理し、Ｂ類型及びＣ類型については、上記に掲げる内容を留意事項及び備考としてそれぞれ記載することとする。 住民票の写し等の証明書には、特別の請求又は必要である旨の申出があった場合、Ａ類型については20.0.3(異動履歴の記載)に規定するように項目ごとに欄を細分化せず、統合記載欄に記載することとし、Ｂ類型については関係する異動履歴のうち直接対応する異動項目と併せて記載することとする。 他方、Ｃ類型については異動履歴とひもづくものではないため、異動履歴とは別に記載することとする。 なお、Ｃ類型に記載されている内容に変更が生じた場合(例：事実上の世帯主が変更又は削除となった場合)においては、変更前の履歴を残し新たなＣ類型の備考を入力することを想定している。 証明書における統合記載欄は、本人等若しくは国若しくは地方公共団体の機関による特別の請求又は第三者若しくは特定事務受任者による必要である旨の申出を受けて、いずれもプライバシー保護の観点等から市区町村長の判断により記載するかしないかを選択し、記載を選択した場合、記載できることとする。 ただし、Ｃ類型のうち、「除票の記載事項及び統合記載欄に誤記があることが判明した年月日・理由、誤記の箇所及び誤記修正後の記載」について写しを交付する際に記載しない場合、第三者が写しの交付を受けた際に悪用等のリスクも想定されるため、当該内容については必ず統合記載欄に記載すること。 なお、特別の請求又は必要である旨の申出に基づき表示する項目に関する誤記である旨等については、デフォルトでは省略とし、市区町村長の判断で当該項目自体を表示して交付する場合にのみ記載すること。 なお、Ａ類型の性別の変更があった旨、Ｂ類型の特別養子である旨の記載及びその離縁については、デフォルトで非表示とする。 氏名のカタカナ表記については、印鑑登録証明に係る事務処理上の必要性によるものであることから他システムと連携できる形式でデータを保持する必要がある。 ,【第5.0版】機能ID：0010035から変更氏名の振り仮名法制化に伴い「(参考)統合記載欄Ｂ類型・Ｃ類型記載例」を修正,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.14 統合記載欄,0010036,除票にあっては、これに加え、統合記載欄に除票固有の記載事項を記載すること(20.1.4(住民票の除票の写し)参照)。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.14 統合記載欄,0010037,異動履歴については自動で作成されること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.14 統合記載欄,0010038,異動事由ごとに、あらかじめ登録した留意事項が自動入力されること。 一般市区町村において実装しない場合は留意事項について自由入力できること。 ,◎,◎,○,中核市市長会ひな形においては、異動事由ごとに、あらかじめ登録した備考文をもとに備考が自動編集できることとしているが、本仕様書では、異動に関する事項はＡ類型の異動履歴として自動で記載されることとした。 また、留意事項の自動入力については、市区町村照会において政令市から事務運用の効率上必要との意見があったことを踏まえ、一般市区町村については標準オプション機能として整理した。 他方、異動履歴にひもづかない備考の文例や自動入力の事由は設けないこととする。 ,2026/04/01,①,機能要件,1 管理項目,1.1 住民データ,1.1.14 統合記載欄,0010039,備考については自由入力できること。 ただし、特別養子縁組である旨及びその離縁に関する留意事項については以下の文言を含めること。 ・特別養子縁組となった場合：「特別養子縁組」※ 特別養子縁組に当たり、養子が転出し、消除された住民票にあっては転出先住所(予定)及び転出先住所(確定)の異動項目と、特別養子縁組に当たり、養子が転入して作成された住民票にあっては転入前住所の異動項目とひもづけて記載。 ・特別養子縁組を離縁した場合：「特別養子縁組離縁」※ 特別養子縁組離縁に当たり、養子が転出し、消除された住民票にあっては転出先住所(予定)及び転出先住所(確定)の異動項目と、特別養子縁組離縁に当たり、養子が転入して作成された住民票にあっては転入前住所の異動項目とひもづけて記載。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.15 メモ,0010040,個人を単位とし、記載事項を限定しないメモ入力ができること。 メモ入力されたものについては、住民票の写し等の証明書に出力されないこと。 ,◎,◎,◎,中核市市長会ひな形では抑止設定に限定してメモ機能を記載しているが、準構成員からの意見を踏まえ、メモ機能については、1.1.14(統合記載欄)に記載したもの以外の証明書に出力しない事項について、限定せずに記載できる機能とした。 また、メモは個人単位で保持しているメモを複数に分割して管理することも可能である。 なお、個人情報保護の観点にも十分留意の上で記載することが重要である。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.15 メモ,0010041,メモを入力した者の操作者ID及び日時が記録されること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.15 メモ,0010042,メモの修正・削除について履歴管理すること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.16 支援措置対象者管理,修正,0010541,支援措置の実施に当たっては、支援措置対象者の住民票(原票)及び除票(原票)に支援措置対象者である旨の表示ができるとともに、住民記録システム内に以下に掲げる項目のデータベースを構築し、住民票(原票)及び除票の当該表示から画面遷移し、支援措置責任者又は支援措置責任者の了承を得た者のみが端末画面上でデータベースを確認できること。 (シート「項目詳細一覧」を参照)なお、支援措置対象者の相手方及び併せて支援を求める者については複数人設定できること。 なお、支援措置対象者の氏名及び宛名番号並びに併せて支援措置を求める者の氏名及び宛名番号、支援を求める事務及び住所等並びに支援措置の期間以外の項目については、住民記録システム以外のシステムでのデータベースの構築も可能とするが、その場合でも住民票(原票)の支援措置対象者である旨の表示から画面遷移し、端末画面上でデータベースを確認できる機能を備えること。 ,◎,◎,◎,総務省通知(令和４年３月31日総行住第32号、総税固第８号)で「住民基本台帳事務における支援措置申出書」の様式例を示し、申出書に記載する事項を例示しており、左記の項目を抜粋した。 除票の場合は、住所の履歴、転出届に基づいて記載した転出先住所(予定)、転入通知に基づいて記載した転出先の住所にも現住所が表示される可能性があり、データベース上で確認できる必要がある。 支援措置においては、申出がなされてから、支援措置の必要性を確認し、実際に支援措置を開始するまでの間も、被害者保護のために、仮支援措置が必要となる場合があり得、仮支援措置の有無についてもデータベース上確認できる必要がある。 10.3(操作権限管理)において、利用者ごとの表示・閲覧項目及び実施処理の制御ができることとしており、各市区町村の支援措置に係る事務の実情に合わせて、データベースの閲覧権限や閲覧項目、閲覧を実施する際の処理等について、管理できるものである。 本籍地について、住所の変更がない場合であっても本籍地が複数回変更することがあり得ることから、現住が記載されている戸籍の附票又は戸籍の附票の除票の写しを保存している全ての市区町村で支援措置を講ずる必要がある。 なお、支援措置対象者の氏名及び宛名番号、併せて支援措置を求める者の氏名及び宛名番号、支援を求める事務及び住所等並びに支援措置の期間以外の項目については、準構成員への意見照会の結果、宛名システム等で支援措置対象者に係る情報を管理しているとの意見が多く見られたため、住民記録システム以外のシステムでのデータベース構築を可能とした。 ,【第5.0版】機能ID：0010043から変更住民基本台帳事務処理要領の改定に伴い、支援措置対象者の「加害者」表記を一律「支援措置対象者の相手方」に修正及び氏名の振り仮名法制化に伴い「項目詳細一覧」を修正,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.17 郵便番号,0010044,住所、転入前住所、転出先住所(予定)及び転出先住所(確定)の郵便番号を管理すること。 ,◎,◎,◎,構成員及び準構成員に意見照会を実施した結果、自市区町村内の住所、転入前住所及び転出先住所とも、郵送のニーズが一定以上あるとの回答が多かったため、便宜的に管理項目とする。 ,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.18 振り仮名・フリガナ,修正,0010542,日本人氏名の振り仮名及び日本人氏名の振り仮名公証フラグ(当該振り仮名が法第７条の記載事項として住民票に 記載されているかどうかを示すフラグ)を管理すること。 旧氏並びに外国人氏名及び通称のフリガナ及びフリガナ確認フラグ(本人への確認の有無を示すフラグ)を管理すること。 なお、日本人氏名の振り仮名、旧氏並びに外国人氏名及び通称のフリガナについては、カタカナで管理することとし、CSへの送信の際は住基ネットの仕様に合わせて送信できること。 ,◎,◎,◎,日本人氏名の振り仮名が、戸籍における法令上の記載事項とされ、法第７条各号における住民票の記載事項とされたことから、本仕様書において「振り仮名」は日本人氏名の振り仮名を指す(旧氏並びに外国人氏名及び通称の場合は「フリガナ」とする。)。 なお、日本人氏名の振り仮名は、戸籍における振り仮名の届出の受理地又は本籍地から連携され、法第７条の記載事項として住民票に記載されることとなるが、令和５年改正戸籍法の施行日から起算して１年以内に限り、戸籍の筆頭に記載されている者は氏の振り仮名を、戸籍に記載されている者は名の振り仮名の届出をすることができるとされていることから、日本人の氏又は名のそれぞれの振り仮名が戸籍における振り仮名の届出の受理地又は本籍地から連携され、法第７条の記載事項として住民票に記載されていることを管理する「日本人氏名の振り仮名公証フラグ」が必要となる。 当該フラグが立っていない日本人氏名の振り仮名については、法第7条の記載事項として記載された振り仮名ではなく、住民記録システムで事実上保持している振り仮名となる。 また、氏のみ又は名のみの振り仮名が戸籍において振り仮名の届出の受理地又は本籍地から連携された場合において、連携された氏又は名の振り仮名のみを上書きして当該振り仮名に上記フラグを立て、連携されていない氏又は名の振り仮名については従前の振り仮名データを維持することに留意すること。 除票においては、氏名の振り仮名が記載されている者と記載されない者が混在し続けるため、令和５年改正戸籍法の施行日から１年経過した後も「日本人氏名の振り仮名公証フラグ」による管理が必要である。 旧氏並びに外国人氏名及び通称のフリガナについては、住民票の記載事項として法に規定されておらず、市区町村がその読み方を認定するという性格のものではないが、市区町村が住民記録の整理のために管理上、必要であるということで便宜的に記載されていることから、2.1.2(検索文字入力)や2.1.3(基本検索)における検索項目として活用できることとしている。 また、要領第２－１－(2)－アにおいて、「氏名には、できるだけふりがなを付すことが適当である。その場合には、住民の確認を得る等の方法により、誤りのないように留意しなければならない。」とされているものであるが、実際には本人に確認できたものとできていないものがあることから、本人に対する確認の有無を区別するため、旧氏並びに外国人氏名及び通称のフリガナについて本人への確認の有無を示すフラグを住民記録システムにおいて管理することとする。 現在、「旧氏のフリガナ」を住民票の記載事項とすることについて、検討を進めており、関係法令が制定される際に修正を行う予定である,【第5.0版】機能ID：0010045から変更氏名の振り仮名法制化に伴い「振り仮名公証フラグ」に関する機能を追加修正及び「要件の考え方・理由」を補記,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.18 振り仮名・フリガナ,新規追加,0010543,日本人氏名の振り仮名については拗音及び促音が区別できる こと。 ,◎,◎,◎,ー,【第5.0版】機能ID：0010543を追加氏名の振り仮名法制化に伴い、日本人住民の振り仮名について拗音等を区別する機能を新規追加,2026/04/01,機能要件,1 管理項目,1.1 住民データ,1.1.19 氏名優先区分,0010046,郵便物の送付先の記載に対して氏名優先区分(例：外国人住民について、通称のみの記載を希望するか、本名のみの記載を希望するか。)を管理すること。 ,○,○,○,外国人住民に対して郵便物を送付する際、通称のみ記載してほしい、又は、本名のみ記載してほしいといった要望に配慮した対応をするために、どの類型かを示す氏名優先区分を必要とする市区町村があったが、必ずしも全市区町村においてそのような運用をしているとは限らないことから、標準オプション機能とする。 当該機能を実装しない場合、デフォルトでは通称が記載されることとする。 なお、通称が登録されていない者においては、以下理由から「氏名(漢字)」、「氏名(ローマ字)」の順で表示すること。 ・在留カードの記載は原則としてローマ字氏名だが、入管法規則第19条の７において、漢字圏の外国人からの申出により、特別に漢字氏名の併記が認められており、当該者については、社会生活上も漢字氏名を使用している可能性が高いこと。 ・J-LISの既存住基システム改造仕様書で示されている「住民票コード通知票」の宛名氏名の仕様においては、優先度の高い順に、通称、漢字氏名、ローマ字氏名とされており、既に既存の住民記録システムにおいても、上記の優先順位に基づいてシステムを構築、事務処理を行っている団体が相当数あることが想定されること。 ,ー,-,機能要件,1 管理項目,1.2 異動履歴データ,1.2.1 異動履歴の管理,0010047,1.1.1(日本人住民データの管理)及び1.1.2(外国人住民データの管理)に規定する異動履歴(留意事項の異動を含む。)は、以下の項目を管理すること。 (シート「項目詳細一覧」を参照),◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.2 異動履歴データ,1.2.1 異動履歴の管理,0010048,別途管理している操作者ID及び操作日時(10.2参照)については、異動履歴とひもづけることができること。 ,◎,◎,◎,ー,2026/04/01,機能要件,1 管理項目,1.2 異動履歴データ,1.2.1 異動履歴の管理,0010049,異動したデータ自体については、以下のとおり、時点ごとに全項目の履歴データを持つ方式により管理すること。 ・住民票に記載する各項目を１列とし、全項目を１行で保持する。 なお、世帯ごとに共通のデータも個人ごとに保持する。 ・データキーは、宛名番号と履歴番号でユニークとする。 履歴番号は１からの単純連番とする。 ・履歴は、データキーの履歴番号をカウントアップし、項目内容の変更有無に係わらず、全項目の内容を保持する。 ・履歴番号が最大のデータを１件セレクトすることで、その個人の直近データの全項目を取得する。 (例示については、シート「参照事項一覧」を参照),◎,◎,◎,特別の請求又は必要である旨の申出を受けて住民票の写し等に記載される異動履歴については、市区町村・ベンダごとにデータ構造が様々であるが、準構成員への意見照会の結果を踏まえ、時点ごとに全項目の履歴データを持つ方式を採用することとする。 ,2026/04/01,機能要件,1 管理項目,1.2 異動履歴データ,1.2.2 異動事由,0010050,システムが管理する異動事由コード及び付随する区分により、以下の区分が行えること。