1自治体情報システムの標準化・共通化に係る手順書
【第 1.0 版】
令和3年7月7日
総務省1目次
はじめに ..................................................................................................................................1
1.情報システムの標準化・共通化の背景........................................................................1
2.地方公共団体情報システムの標準化に関する法律......................................................2
3.標準化・共通化の特徴..................................................................................................5
4.本手順書の位置付け及び改定.......................................................................................8
第1章 自治体情報システムの標準化・共通化に係る検討................................................10
1.自治体情報システムにおける現状と課題 ..................................................................10
2.情報システムの標準化・共通化の意義及び効果 .......................................................10
3.標準化・共通化に対する国の主な施策・支援措置等................................................14
第2章 自治体における作業手順 ........................................................................................17
1.作業の全体像 ..............................................................................................................17
2.早期(令和3年度)に着手すべき作業......................................................................24
3.フェーズごとの作業項目............................................................................................26
(1)計画立案フェーズ................................................................................................26
1推進体制の立ち上げ................................................................................................27
2現行システムの概要調査 ........................................................................................29
ア)現行システム環境の基礎調査..........................................................................29
イ)連携一覧の作成................................................................................................33
3標準仕様との比較分析............................................................................................35
ア)Fit&Gap 分析...................................................................................................37
イ)標準仕様書対応表への記載 .............................................................................45
4移行計画作成 ..........................................................................................................47
(2)システム選定フェーズ ........................................................................................50
5ベンダに対する情報提供依頼(RFI)資料の作成 .................................................51
6RFI の実施...............................................................................................................56
7RFI 結果分析及び移行計画の詳細化 ......................................................................56
8予算要求..................................................................................................................56
9ベンダへ提案依頼(RFP)
【A パターンのみ】......................................................57
10ベンダ選定・決定【A パターンのみ】...................................................................57
11契約・詳細スケジュール確定.................................................................................57
12特定個人情報保護評価(PIA) ..............................................................................58
ア)評価の対象となる事務.....................................................................................58
イ)評価の実施手続................................................................................................59
(3)移行フェーズ.......................................................................................................61
13システム移行時の設定............................................................................................62114データ移行 ..............................................................................................................62
15テスト・研修 ..........................................................................................................63
16次期システムに合わせた既存環境の設定変更 .......................................................64
ア)新システム環境構築・NW接続......................................................................64
イ)他業務システム連携設計、業務間調整...........................................................64
17条例・規則等改正 ...................................................................................................64
4.その他の留意事項.......................................................................................................65
文字情報基盤文字への対応............................................................................................65
参考 用語.........................................................................................................................66
参考 デジタル社会の実現に向けた重点計画(令和3年6月 18 日閣議決定)
(抄)....741はじめに
1.情報システムの標準化・共通化の背景
日本の高齢者(65 歳以上)人口は 2040 年頃にピークを迎える。総人口に
おいても、2008 年から減少が続き、1995 年に 8,726 万人だった生産年齢人
口は、2015 年には 7,728 万人となり、2040 年には 6,000 万人を割り込むと
見込まれ、今後は労働力の供給に制約が生じると想定される。
現在、我が国の住民生活に身近な行政サービスの多くは、自治体が担って
いる。今後、人口減少が進み、我が国を取り巻く環境に不確実さが増す中で
も、住民の健康で文化的な生活と地域経済を守るため、自治体は安定的かつ
持続可能な形で、行政サービスを提供し続ける必要があることから、労働力
の供給制約の中においても、職員が企画立案業務や住民への直接的なサービ
ス提供など職員でなければできない業務に注力できる環境を作れるよう、制
度や組織、業務の在り方等を変革していくことが求められている。
このような状況を踏まえ、国は「デジタル社会の実現に向けた改革の基本
方針」及び「デジタル・ガバメント実行計画」を令和2年 12 月 25 日に閣議
決定し、
自治体における情報システム等の共同利用、
手続の簡素化、
迅速化、
行政の効率化等を推進するため、自治体の情報システムの標準化・共通化に
取り組むこととした。具体的には、住民記録、地方税、福祉など、自治体の
主要な 17 業務を処理するシステムについて、
デジタル庁
(現内閣官房情報通
信技術(IT)総合戦略室(以下「IT 室」という。))が策定する基本的な方針
の下、
関係府省において標準仕様書を作成※(注記)した上で、
各ベンダが標準仕様に
準拠して開発したシステム(以下「標準準拠システム」という。
)を全国規模
のクラウド基盤(いわゆる「ガバメントクラウド」
)に構築し、当該システム
を各自治体が利用することを目指すものである。
なお、標準準拠システムへの移行の目標時期は令和7年度とされている。
※(注記) 令和3年夏に固定資産税、個人住民税、法人住民税、軽自動車税、就学、介護保険及び
障害者福祉(以下「第1グループ」という。
)の標準仕様書を、令和4年夏に選挙人名簿
管理、国民年金、国民健康保険、後期高齢者医療、生活保護、健康管理、児童手当、児
童扶養手当及び子ども・子育て支援(以下「第2グループ」という。
)の標準仕様書を作
成することとされた。
住民記録については、
「住民記録システム標準仕様書
【第 1.0 版】」(令和2年9月 11 日自治体システム等標準化検討会(住民記録システム等標準化検討会))を作成し、令和3年夏にその改定を予定している。22.地方公共団体情報システムの標準化に関する法律
さらに国は、
自治体情報システムの標準化・共通化の取組を推進するため、
「地方公共団体情報システムの標準化に関する法律案」を第 204 回通常国会
に提出し、同法案は、令和3年5月 12 日に可決・成立した(令和 3 年法律第
40 号。
令和3年5月 19 日公布・同年 9 月 1 日施行。
以下同法を
「標準化法」
という。)。
標準化法では、地方公共団体の情報システムの標準化の対象となる事務
(住民基本台帳、選挙人名簿管理、固定資産税、個人住民税、法人住民税、
軽自動車税、就学、国民年金、国民健康保険、後期高齢者医療、介護保険、
障害者福祉、生活保護、健康管理、児童手当、児童扶養手当、子ども・子育
て支援の 17 業務ごとに対象事務を特定する予定。
なお、
事務の共通性や住民
の利便性の向上、行政運営の効率化に資するという標準化対象事務の趣旨に
合致する事務については、対象に追加することも考えられる。以下「標準化
対象事務」という。
)を政令で定め(第2条第1項関係)
、標準化対象事務の
処理に係る情報システム(以下「標準化対象システム」という。
)の標準化の
ための基準(以下「標準化基準」という。)のうち、各所管法令又は事務に
係る部分については各所管大臣が、各システムに共通する部分については、
デジタル庁
(現 IT 室)
を所管する長としての内閣総理大臣と総務大臣が定め
ることとなる(第6条第1項及び第7条第1項関係)。その上で、地方公共団体に対して、標準化基準に適合したシステム(標準
準拠システム)の利用を義務付けるとともに(第8条第1項関係)
、地方公共
団体は、国による全国的なクラウド活用の環境整備の状況を踏まえつつ、当
該環境においてクラウドを活用して情報システムを利用するよう努めること
とされている(第 10 条関係)。今後、国は、標準化対象事務を定める政令を制定するとともに、標準化の
推進を図るための基本方針を定めることとされており、基本方針では、標準
化・共通化に関する大綱的な方針のほか、標準化基準に関する基本的な事項
についても定めることとされている(第5条関係)。関係府省は、
「デジタル・ガバメント実行計画」に基づき作成中の標準仕様
書を元に、基本方針も踏まえ、所管事務に関する標準化基準を省令で定める
こととなる。また、今後デジタル庁(現 IT 室)及び総務省は、各システムに
共通する基準(以下「共通要件」という。
)を省令で定めることとなる。3図表 1 行政のデジタル化に向けた主な経緯
図表 2 地方公共団体情報システムの標準化に関する法律の概要4図表 3 自治体情報システムの標準化・共通化・ガバメントクラウド活用スケジュール
出典:
「デジタル・ガバメント実行計画」
(令和2年 12 月 25 日閣議決定)P.59 より抜粋53.標準化・共通化の特徴
今後、自治体は、標準化法に基づき、システムの標準化・共通化に取り組む
こととなるが、次のような点において従来のシステム更改とは異なる特徴が
あることから、このことを十分に踏まえた上で、対応する必要がある。
(1) 令和7年度を目標時期として標準準拠システムへ移行する必要がある
こと。
これまで、自治体におけるシステム更改は、法令改正等への対応によ
る場合を除けば、
自らの計画等に基づき、
システム更改時期を決めて行っ
てきたところ。
しかしながら、
標準準拠システムへの移行の目標時期は令
和7年度とされていることから、当該目標時期に向けて各自治体におい
ては、改めて現在のシステム更改計画等を見直す必要が生じ得る。
(2) 全ての標準化対象事務がシステム移行の対象であること。
全ての標準化対象事務について標準準拠システムの利用が求められる
ことから、全ての標準化対象事務を処理するシステムが移行対象となる。
そのため、
システム移行対象や範囲、
それらに関する現行ベンダや契約内
容を網羅的に把握するだけでも、
時間を要する可能性があるとともに、自治体の複数部局にまたがってシステム移行の影響が生じ得る。
(3) 全自治体において短期間に集中してシステムの移行がなされること。
標準化の取組は、自治体が足並みを揃えて、標準準拠システムへ移行
することで、大きな効果が得られることから、全自治体が短期間に集中
してシステムを移行することとなる(「デジタル・ガバメント実行計画」
の工程表によれば自治体の移行時期は令和5年度から令和7年度が想定
されている。)。また、標準化対象事務に係る情報システムは、住民への
サービス提供を支えるものであることから、住民への影響を最小限にと
どめようとすると、自ずとシステム移行に対応できる機会は限られてく
ると考えられるため、自治体間でテストやデータ移行時期の調整などが
生じ得ることも考えられる。6(4) 標準仕様書やガバメントクラウドへの移行など、国の動きと密接に関連
していること。
関係府省の標準仕様書は、令和3年夏と令和4年夏を目途に作成され
る見込みであり、各自治体においては、その検討状況を注視しながら、ス
ケジュールに余裕をもって標準化・共通化に取り組む必要がある。
なお、
この標準仕様書については、デジタル庁(現 IT 室)を中心に検討が進め
られているガバメントクラウドの整備方針や令和4年夏を目途に取りま
とめられる共通要件次第では、
更なる改定の可能性も否定できないが、その検討状況については自治体へ適時適切に情報提供をする予定であるこ
とから、これらの情報を積極的に活用されたい。
標準化・共通化に関する最新の動向については、以下のウェブサイト
にて取りまとめを行っている。
・自治体情報システムの標準化・共通化(総務省)
https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html
・地方公共団体における業務プロセス・情報システムの標準化の推進
(政府 CIO ポータル)
https://cio.go.jp/node/2733
なお、
「デジタル社会の実現に向けた重点計画」
(令和3年6月 18 日閣
議決定)
においても、
「第2部 デジタル社会の形成に向けた基本的な施策」
として、
「ガバメントクラウド、ガバメントネットワーク」や「地方公共団
体の基幹業務等システムの統一・標準化」等が位置づけられていることか
ら、あわせて参照されたい。
https://www.kantei.go.jp/jp/singi/it2/decision.html
(5) 標準仕様書に基づく業務フロー等の見直しの検討が生じ得ること。
関係府省の標準仕様書においては、システムの機能要件に加え、参考
として機能要件に対応した標準的な業務フローを示すこととされている。
自治体においては、標準準拠システムへ移行していく必要があるが、その
際、標準仕様書において併せて示された標準的業務フローも参考に、現在
の業務フロー等の見直しを行うことが重要である。その結果、新たな業務
フローに基づく、全庁的な業務改革(BPR)に取り組むことも考えられる7ところであり、
標準化は単なるシステム移行に留まらない取組である点に
留意が必要である。
これらの特徴を踏まえれば、自治体においては、全庁的な体制整備や綿密
な移行計画の策定等が必要不可欠である。また、円滑に標準化・共通化の取
組を進めるためには、可能な限り早期に着手の上で計画的に取り組むことに
より、標準準拠システムへの移行の目標時期である令和7年度までの事務負
担を平準化することが重要である。84.本手順書の位置付け及び改定
本手順書には、全自治体が円滑に情報システムの標準化・共通化を進める
ため、標準化・共通化に向けた標準的な作業項目やフェーズ毎に想定される
主な作業手順等を掲載している。自治体においては、本手順書を参考にしな
がら、積極的な情報収集に努めるとともに、標準化・共通化の取組を推進し
ていただきたい。
なお、関係府省が作成する標準仕様書、デジタル庁(現 IT 室)を中心に検
討がなされているガバメントクラウドの仕様、共通要件等については、本手
順書策定時点においてもなお、検討・調整中の項目が多く含まれていること
から、今後、これらについて内容が確定し、本手順書に修正を加える必要が
生じた際には、随時、手順書の改定を行うことを予定している。
また、本手順書では、現時点で自治体において想定される作業全般を洗い
出したものの、各自治体のシステムの構成や規模等によって必要となる手順
等に差異が有りうることには留意すべきと考えられる。9重点取組事項
(1) 自治体の情報システムの標準化・共通化
(2) マイナンバーカードの普及促進
(3) 自治体の行政手続のオンライン化
(4) 自治体の AI・RPA の利用推進
(5) テレワークの推進
(6) セキュリティ対策の徹底
デジタル社会の実現に向けた改革の基本方針
(令和2年 12 月 25 日閣議決定)
IIデジタル社会の将来像
1デジタル社会の目指すビジョン
デジタルの活用により、一人ひとりのニーズに合ったサービスを選ぶことができ、
多様な幸せが実現できる社会〜誰一人取り残さない、人に優しいデジタル化〜
デジタル・ガバメント実行計画
(令和2年 12 月 25 日閣議決定)
自治体 DX 推進計画(令和2年 12 月 25 日総務省)
自治体が重点的に取り組むべき
事項・内容を具体化
自治体情報システムの標準化・共通化に係る手順書
(本手順書)
各システムの標準仕様書
地方公共団体情報システムの標準化に関する法律(令和3年法律第 40 号)
図表 4 本手順書の位置付け10第1章 自治体情報システムの標準化・共通化に係る検討
1.自治体情報システムにおける現状と課題
これまで各自治体において、住民ニーズへの対応、利便性向上等の観点か
ら、情報システムのカスタマイズが行われてきた結果、その発注・維持管理
や制度改正対応などについて個別の対応が必要となっており、自治体ごとに
人的・財政的負担が生じていると指摘されてきた。また、カスタマイズ等に
より、同一ベンダのシステムを利用する自治体間でもそれぞれのシステムの
内容が異なるなど、自治体クラウドのような共通プラットフォーム上のサー
ビスを利用する方式への移行の妨げとなっている。また、自治体ごとに様式
や帳票等が異なることは、それらを利用する住民・企業等の負担にもつなが
っている。
2.情報システムの標準化・共通化の意義及び効果
社会全体のデジタル化のためには、住民に身近な行政を担う自治体の DX
の推進が重要であり、その基盤となる自治体情報システムの標準化・共通化
は、住民の利便性向上や行政運営の効率化に資する取組である。
特に、1.のとおり認識されている情報システムにおける課題の解決に、
標準化・共通化の取組は大いに貢献するものと考えられる。
この点、自治体における情報システムの標準化・共通化の取組効果として
は、主に次の3点が考えられる。
(1) コスト削減・ベンダロックインの解消
標準準拠システムを利用することで、自治体が情報システムを個別に
開発する必要がなくなり、人的・財政的負担の軽減といった効果が見込
まれる。なお、
「デジタル・ガバメント実行計画」においては、
「標準化・
クラウド化の効果を踏まえ、地方公共団体の情報システムの運用経費等
については、標準準拠システムへの移行完了予定後の 2026 年度(令和
8年度)までに 2018 年度(平成 30 年度)比で少なくとも3割の削減を
目指す」こととしている。
また、標準化・共通化の取組により、システムで管理するデータ項目11や形式をはじめ、機能や様式・帳票などについて、国が標準を定め、ベ
ンダは当該標準を満たすシステムを開発し、自治体はベンダが開発した
標準準拠システムを利用することとなる。このため、標準化・共通化を
実効的に推進することは、システム間のデータ移行の円滑化に繋がり、
ベンダの切替を容易にするものと考えられる。
(2) 行政サービス・住民の利便性の向上
標準化・共通化の取組により、システム調達等の業務に従事していた
職員を、企画立案や住民への直接的なサービス提供など、職員でなけれ
ば真にできない業務に振り向けることが可能となることから、行政サー
ビスの向上に寄与するものである。これにより、長期的には、生産年齢
人口の減少による労働力の供給制約がある中でも、持続的に行政サービ
スを提供するための自治体の体制整備に貢献し得るものと考えられる。
また、標準化対象システムとマイナポータルぴったりサービスとの接
続など、行政手続のオンライン化に寄与するシステム連携の要件が今後
標準化され、エンドトゥエンドでのオンライン化が広く実現されれば、
更に住民の利便性の向上に資することとなる。
(3) 行政運営の効率化
標準仕様書においては、機能要件に対応する業務フローを示すことと
されていることから、標準準拠システムの利用にあわせて、標準化対象
事務に係る業務フローを見直すことで行政運営の効率化に資することが
期待される。また、標準化・共通化を進めることにより、システムの共
同運用やAI・RPA等のデジタル技術、外部人材等が、従来と比較し
活用しやすくなることも想定されるため、これらを有効に活用した業務
プロセスの見直しを検討することなども考えられる。
上記に加え、標準化・共通化の取組は、図表5のとおり、多様な目的が関
連し合い、相互に意義や効果を生むものである。
むろん標準準拠システムへの移行の目標時期である令和7年度までの期間
は、全自治体において、全庁的な推進体制の構築、多様な移行作業手順の遂
行が求められることから、一時的に作業が集中せざるを得ない場面も想定さ
れるが、早期から計画的に取り組むことでその負担を平準化することも考え12られるところであり、あくまで標準化・共通化の取組は、自治体における将
来的な人的・財政的負担の軽減や住民の利便性の向上に資するものであり、
その目的や効果を意識して取り組むことが重要である。13出典:「住民記録システム標準仕様書【第 1.0 版】」(令和2年9月 11 日自治体システム等標準化検討会(住民記録システム等標準化検討会))
P.19 より抜粋
図表 5 標準仕様書の作成の目的及び意義143.標準化・共通化に対する国の主な施策・支援措置等
国は、自治体の情報システムの標準化・共通化に向けて、以下の施策に取
り組み、推進していく方針である。各自治体においては、標準化・共通化の取
組を推進するに当たり、積極的にこれらの施策を活用することが望ましい。
(1)デジタル人材の確保・育成
自治体 DX 全体手順書4.3及び4.4を参照されたい。
(2)ガバメントクラウドの整備
「デジタル・ガバメント実行計画」では、情報システムの共通的な基
盤・機能を提供する複数のクラウドサービス(IaaS、PaaS、SaaS)の利用
環境を備えたガバメントクラウドの構築が示されており、自治体は、標
準準拠システムへの移行の目標時期である令和7年度までに、ガバメン
トクラウド上に構築された標準準拠システムを利用する形態への移行を
目指すこととされている。また、令和3年の通常国会で成立したデジタ
ル社会形成基本法(令和3年法律第 35 号)第 29 条では、
「地方公共団体
の情報システムの共同化又は集約の推進(全ての地方公共団体が官民デ
ータ活用推進基本法第2条第4項に規定するクラウド・コンピューティ
ング・サービス関連技術に係るサービスを利用することができるように
するための国による環境整備を含む。)」
について規定しており、
また、標準化法第 10 条において、
「地方公共団体は、デジタル社会形成基本法第
29 条に規定する国による環境の整備に関する措置の状況を踏まえつつ、
当該環境においてクラウド・コンピューティング・サービス関連技術を
活用して標準準拠システムを利用するよう努めるもの」とされている。
なお、デジタル庁(現 IT 室)においては令和3年6月からガバメント
クラウドに係る先行事業を開始しており、ガバメントクラウドへ移行す
ることにより、サーバや OS、アプリケーションの共同利用など、さらな
るコスト削減、システムの迅速な構築や柔軟な拡張、各自治体のセキュ
リティ対策の強化やサーバ運用監視事務負担の軽減等の効果が発揮でき
るよう検証を進めている。15図表 6 ガバメントクラウドのイメージ図
出典:
「地方自治体によるガバメントクラウドの活用について(案)」(令和3年1月作成、6月改定 内閣官房情報通信技術(IT)総合戦略室)P.1 より抜粋16(3)移行経費に対する財政支援
各自治体が、目標時期である令和7年度までにガバメントクラウド上
で構築された標準準拠システムを利用する形態に円滑に移行するため、
必要となる準備経費(現行システム概要調査、移行計画策定等)や移行
経費(接続、データ移行、文字の標準化、契約変更等に伴う追加的経費
等)に対する補助を行うこととしている。詳細については、今後、地方公
共団体情報システム機構からデジタル基盤改革支援補助金(地方公共団
体情報システムの標準化・共通化に係る事業)に関する事務処理要領等
を発出する予定としているので参照されたい。
図表 7 自治体情報システムの標準化・共通化に向けた環境整備17第2章 自治体における作業手順
1.作業の全体像
標準準拠システムへの移行に当たっては、
「計画立案」、「システム選定」、「移行」の3つのフェーズに沿って、それぞれ概ね以下に示すような作業項
目が想定される。
これらの作業項目の一覧及び各作業項目における想定月数は、図表9のと
おりであり、あわせてモデル的な移行スケジュールの例を図表 10 及び図表
11 のとおり示している。
しかしながら、自治体の置かれた状況は、例えば、パッケージソフトかス
クラッチ開発か、パッケージソフトの場合オールインワンかマルチベンダ下
での複数導入か、カスタマイズしているかどうかといった現行のシステム構
成、現行のシステム契約の状況、自治体における標準化・共通化の取組に関
する推進体制の規模、ベンダの標準準拠システムの開発時期等、多種多様で
あることから、各自治体に対して、本モデルスケジュールどおりの移行スケ
ジュールの作成を求めるものではない。
むしろ、こうした多種多様な状況下にあっても、本手順書「はじめに」の
「3.標準化・共通化の特徴」に記載したとおり、標準準拠システムへの移
行の目標時期は令和7年度とされており、標準化対象事務の全てに係るシス
テムが更改の対象であることなどを踏まえると、可能な限り早期から自団体
の置かれた状況を的確に把握するため、現行システムの概要調査を実施する
こと等により、それぞれの自治体の実情に応じた移行計画を作成し、取組を
進めることが重要となる。
また、
本作業項目に取り組むに当たっては、
更に次の点にご留意願いたい。
(1) 作業の順番について
作業項目1から17までは、
自治体側で想定される作業を順番に並べた
ものではあるが、必ずしも、各作業項目が終わり次第、次のステップに
進むことを前提とするものではなく、自治体のシステムの状況等に応じ
て、各作業を同時に進めることも十分に考えられるところであり、柔軟
に対応されたい。18(2) 移行方式等に応じた作業項目
システムの移行方式は、各自治体において、標準化・共通化の取組の
趣旨を踏まえ適切なプロセス・比較検討を経た上で、ベンダ切替の有無
に応じて次の A 又は B の2パターンに分類されることが想定される。
移行方式の選択にあたっては、
現行以外も含めたベンダ各社のシステ
ムの費用、機能等を比較することが重要であり、作業項目5から7のR
FIはその代表的な手法の一つである。
なお、これらの検討の結果としてBパターンを選択した場合、作業項
目9及び10は省略されるほか、その他の作業項目についても、パターン
AかBかに関わらず、各自治体の実情を踏まえて一部の作業項目を省略
することも考えられる。
また、現行のシステムをスクラッチ開発している自治体についても、
今般の標準化・共通化の取組の趣旨を踏まえ、原則としてパッケージシ
ステムを利用することを想定していることから、
A 又は B のいずれかの
パターンに分類されるものと想定している。
図表 8 システム移行に係る自治体の類型
パターン 概要
A パターン
ベンダ切替により標準化基準に適合するパッケージを
利用するパターン
B パターン
ベンダを切替えず標準化基準に適合するパッケージに
バージョンアップするパターン
それぞれの作業項目の詳細については、
「3.フェーズごとの作業項
目」にて詳述するので、あわせて参照されたい。19図表 9 標準化・共通化対応に係る自治体作業の全体像
フェーズ 作業項目
自治体作業概要(想定月数)
全自治体共通
計画立案 1 推進体制の立ち上げ 首長のリーダーシップの下、関係部局を特定し、担当者・推進体制を構築する。
(1〜3か月)
 広域連合や複数の自治体間等において、現行システムを他団体と共同利用(自治体クラウド
等)している場合は、他団体との合意等に時間を要することに留意すること。
(〜3か月)
2 現行システムの概要調査 現行システムについて、業務システムの基礎情報、外部委託状況、周辺機器、連携一覧等につい
て調査を行う。
(1〜3か月)。3 標準仕様との比較分析 標準仕様と現行システムとの Fit&Gap 分析を実施する。標準仕様書と差異があり標準準拠シス
テムの利用に向けて個別の対応(業務フローの見直し等)を要する項目があれば標準仕様書対応
表に記載する。
(3〜4か月)
4 移行計画作成 作業項目2・3及び国における検討状況(標準仕様書の作成、ガバメントクラウドの実装)等を
踏まえ、標準準拠システムの移行計画を作成する。
(2か月)
システム
選定
5 ベンダに対する情報提供依頼
(RFI)資料の作成
RFI を実施するための資料を作成する。
(1〜4か月)
 標準準拠システムの影響を受けて更改を検討する標準準拠システム以外のシステムについて
も調達する場合は、同様に RFI 用の資料を作成する。
(3〜4か月)
6 RFI の実施 作業項目5で作成した資料を基に、ベンダに RFI を実施する。
(1〜4か月)
 現行システムでスクラッチを行っている自治体が RFI を実施する場合は、ベンダによる回答
作成・デモンストレーション等に長期間要することに留意すること。
(〜4か月)
7 RFI 結果分析及び移行計画の
詳細化
作業項目6において収集した情報の集約・分析後、移行計画の詳細化・変更を行う。
(1〜3か月) 調達単位を細かく分けて RFI を実施した場合は、情報の整理・分析に時間を要することに留
意すること。
(〜2か月)
8 予算要求 RFI 結果を勘案し、標準準拠システムへの移行経費の予算要求を行う。
(2か月)
フェーズ 作業項目
自治体作業概要(想定月数)
A パターン B パターン
システム
選定
9 ベンダへ提案依頼(RFP) 最終的な調達仕様を確定し、
各ベンダへ提案依頼
(RFP)を行う。併せて、調達の方式にあった様
式等(実施要領や評価基準)を作成する。
(3か
月)※(注記)(1)―10 ベンダ選定・決定 提案書、
デモンストレーション、プレゼンテーシ
ョン等の評価を通じて、
標準準拠システム提供ベ
ンダを決定する。
(1〜2 か月)※(注記)(2) ―20フェーズ 作業項目
自治体作業概要(想定月数)
A パターン B パターン
システム
選定
11 契約・詳細スケジュール確定 標準準拠システム提供ベンダと契約を行い、データ移行日等の詳細なスケジュールを確定する。
(1〜2か月)※(注記)(3)
12 特定個人情報保護評価(PIA) 特定個人情報保護評価書の作成及び個人情報保護委員会への提出やパブリックコメントを実施
する。
(2〜4か月)
移行 13 システム移行時の設定 標準準拠システムを基に運用のシミュレーションを行い、標準準拠システムの運用方法を検討・
確定する。
採用した新規システムの機能を整理し、画面や
帳票等を見ながら、機能の詳細を確認する。(4〜6か月)
ベンダより現行システムからの変更点の説明
を受け、次期システム利用に向けた各種設定
の協議を行う※(注記)(4)。
(2か月)
14 データ移行 データ移行等について調整を行い、現行ベンダで既存データの整理・抽出を行う。その後、標準
準拠システム提供ベンダにてデータ移行を実施し、データ移行結果を確認する。併せて、文字情
報基盤文字への文字データ移行作業も行う※(注記)(5)。
(4〜6か月)
 ベンダを切り替えた場合、現行システムから抽出したデータの分析・現行仕様に関する問合
せ、変換仕様の設計、移行結果の確認等に期間を要することに留意すること。
(〜6ヶ月)
 現行システムがマルチベンダの場合、現行システムからのデータ抽出の仕様提供、基準日、
受け渡し方式等に関するベンダ間調整に期間を要することに留意すること。
(〜6ヶ月)
15 テスト・研修 テストデータ準備、テスト及び確認を行う。
(2〜6ヶ月)
標準準拠システム提供ベンダより次期システムの操作等に関して研修を受ける。
(1〜2ヶ月)
 スクラッチ開発からの移行の場合は、他のパターンと比較し、テストに時間を要することに
留意すること。
(〜6か月)
16 次期システムに合わせた既存
環境の設定変更
標準準拠システムと庁内ネットワーク接続、構築、端末整備等を行う。また、他業務とのデータ
連携項目、ファイル形式、処理タイミング等を確認の上、データ連携のテスト・変更を行う。(4か月)
17 条例・規則等改正 標準準拠システムを利用する場合の運用や出力される帳票等を確定し、議会日程を勘案しなが
ら、必要に応じて条例・規則等の改正を行う。
(4か月)
・作業項目がゴシックフォント太字になっている項目は、通常のシステム移行と比較して、標準化・共通化の取組において特に必要となるものを示している。
・作業項目毎の想定月数は、令和3年度における「自治体システムの標準化・共通化を推進するための調査研究業務」の受託事業者が過去の自治体システム更改におけ
る実績値を元に算出した作業目安を参考として示したもの。
※(注記)(1)・(2)・(3)については、マルチベンダで標準準拠システムへの移行を想定している場合、ベンダ毎に同作業が必要となる。
※(注記)(4)
「各種設定の協議」とは、ベンダより現行システムから機能変更がある点について説明を受け、該当機能の使用方法等について協議を行うプロセスなどを想定
している。
※(注記)(5)
「2.早期(令和3年度)に着手すべき作業」に記載のとおり、前倒して実施することが望ましい。21図表 10 A パターンのモデルスケジュール例
(作業項目ごとに要する想定月数を積み上げた際のスケジュール例(※(注記)))22
図表 11 B パターンのモデルスケジュール例
(作業項目ごとに要する想定月数を積み上げた際のスケジュール例(※(注記)))23
(※(注記))モデルスケジュールの前提条件・「デジタル・ガバメント実行計画」の工程表(図表3参照)に基づき、機能要件等に関す
る関係府省が作成する標準仕様書は、
令和3年夏及び令和4年夏に公開されデジタル庁(現IT 室)が中心となって作成する、共通要件に関する標準仕様書は、令和4年夏に公開され
る。今後、本格移行に向けて、ベンダにおいて、順次標準準拠システムの開発・公開するこ
とを想定。
・モデルスケジュール例中の本稼働時期は、第1グループ、第2グループともに、標準仕様
書が公開された後(令和3年夏又は令和4年夏)に、自治体として行うべき作業項目(1か
ら17まで)毎に想定される月数を積み上げたものである。242.早期(令和3年度)に着手すべき作業
標準準拠システムへの移行の目標時期は令和7年度とされており、目標時
期までの作業を平準化するため、実施可能なものから取り組むことが何より
も重要である。
可能な限り早期からの庁内体制立ち上げや各種調査に加えて、
現行ベンダや他のシステムベンダとの意見交換等も積極的に行い、移行準備
に着手することが望ましい。
図表9で示した作業の全体像のうち、図表 12 に掲げる作業項目について
は特に早期に実施可能であると想定される。
図表 12 早期に実施可能な作業項目
No. 作業項目 本手順書内の記載頁数
1 推進体制の立ち上げ P.27~28
2 現行システムの概要調査 P.29~35
3 標準仕様との比較分析 P.36~46
4 移行計画作成 P.47~49
5 ベンダに対する情報提供依頼(RFI)資料の作成 p.51~55
6 RFI の実施 P.56
(14の
一部)
文字情報基盤文字への対応 P.65
このうち作業項目1「推進体制の立ち上げ」及び作業項目2「現行システ
ムの概要調査」は、標準化・共通化の取組の入口であることから、早期に実
施することが望ましい。
作業項目3「標準仕様との比較分析」については、まずは、令和3年夏に
作成される第1グループの標準仕様書に関して現行業務との Fi t
フィット
&
アンドGapギャップ分析を行うことを想定している。また、第2グループの標準仕様書は令和4年
夏を目途にとりまとめることとされているが、標準仕様の検討状況に応じて
ホームページ等で適時適切に情報提供が行われることから、令和4年夏を待
つことなく、随時これらの情報を元に確認・分析を進められたい。
作業項目4「移行計画作成」については、ガバメントクラウドに関する検
討状況等を踏まえて詳細化・変更する必要があるが、第1グループに関する25移行時期、予算計上時期等については早期に検討することが望ましい。
作業項目5「ベンダに対する情報提供依頼(RFI)資料の作成」及び作業項
目6「RFI の実施」についても、ベンダから可能な限り早く情報収集を行う
観点から、早期に実施することが考えられる。
また、標準準拠システムへの移行に伴う文字情報基盤文字への対応につい
ても、作業内容の確認及び同定基準作成等について、早期にベンダとの協議
を開始することが望ましい。
なお、現行システムでスクラッチ開発を行っている等の理由により、自治
体において多岐にわたる移行作業が見込まれる場合や、効率的かつ速やかな
事業遂行に著しい支障を生じる場合には、作業項目2「現行システムの概要
調査」から作業項目6「RFI の実施」までの作業については、外部委託の活用
も選択肢として考えられる。
図表 13 令和3年度の作業スケジュール例263.フェーズごとの作業項目
(1) 計画立案フェーズ
計画立案フェーズにおいては、まず首長のリーダーシップによる推進
体制の立ち上げ及び現行システムの基礎情報の調査を実施する。
その後、標準仕様書と現行システムの仕様・現行の業務フローとの差
異の分析や移行計画の作成を行う。
自治体の置かれた状況は、現行システムの状況や契約状況等に応じて
多様であるが、本フェーズについては、どの自治体においても可能な限
り早期に実施することが望ましい作業であることから、「2.早期(令
和3年度)に着手すべき作業」で記載したとおり、本手順書に沿って早
期に着手することを推奨する。
図表 14 計画立案フェーズの各項目の役割及び記載頁数271推進体制の立ち上げ
標準化・共通化に向けては、可能な限り早期に全庁的な推進体制を立
ち上げ、部局横断的に取り組みながら、国の標準化・共通化に係る検討
状況の把握、現行ベンダとの協議、着手可能な調査の実施等を進めるこ
とが重要である。そのためには、標準化・共通化の対象となる情報シス
テムを所管する関係部局を特定し、目標時期である令和7年度までのお
おまかなスケジュールや当該年度に実施する作業項目を想定しつつ、推
進体制を検討する必要がある。
なお、標準化・共通化の検討初期の段階で全庁的な推進体制を立ち上
げることが困難な場合は、作業項目2「現行システムの概要調査」で述
べる調査等を実施し、移行計画をある程度まとめてから最終的な推進体
制を整備するといった段階的な手順を取ることも考えられる。
ただし、いずれの場合においても、首長のリーダーシップの下、標準
化・共通化の取組に係る体制整備が重要である。
また、標準準拠システムへの移行の目標時期が令和7年度とされてお
り、かつ、自治体内部でも関係部署は多岐にわたることから、全体の進
捗管理が鍵となる。そのため、いわゆる PMO(Project Management
Office)の役割を担う部署を定めておくことも考えられる。
進捗管理の支
援を要する場合には、例えば、外部人材の任用や複数市町村による共同
設置等も選択肢となり得る。PMO の機能・役割等に関しては「デジタ
ル・ガバメント推進標準ガイドライン」
(令和3年3月 30 日内閣官房情
報通信技術(IT)総合戦略室)を参照されたい。
また、都道府県は、これまでも、自らの業務のデジタル化にとどまら
ず、域内市区町村の自治体クラウドの推進に当たっての調整や、情報セ
キュリティクラウドなどのセキュリティ対策をはじめ、広域自治体とし
ての自治体行政のデジタル化に向けた主導的役割を担ってきている。ま
た、標準化法第9条第3項では、都道府県の役割として、市区町村への
助言、情報の提供その他の措置を講ずるよう努めることが規定されたと
ころであり、域内の市区町村が円滑に情報システムの標準化・共通化を
進められるよう、例えば、検討会や勉強会の開催、域内市区町村の移行
状況調査・把握、技術的助言等を行うなど、今後も積極的な役割が期待
される。こうした観点から、都道府県においても、市区町村の検討過程28の支援等をするための体制を構築することが考えられる。
情報システム標準化推進本部
(情報化推進本部等)
CIO 等、各業務所管部部長・課長 等
推進本部事務局 / PMO(Project Management Office)
DX 推進担当部署 or 情報政策担当
※(注記)上記に加えて PMO に外部人材を活用することもあり得る
各情報システム標準化対象業務等担当者
標準化対象業務等担当者、標準化対象と併せて更改を検討するシステム等の業務等担当者、
行政改革担当部署担当者、法令担当部署担当者、財政部署担当者 等
進捗報告・課題共有
進捗管理・全体調整等
全体進捗報告等
指揮・監督
※(注記)1 住民記録については、令和3年夏に標準仕様書の改定を予定している。
※(注記)2 戸籍、戸籍の附票及び印鑑登録事務については、
「デジタル社会の実現に向けた重点
計画」において、標準化対象事務に加えることを検討することとされた。
図表 15 標準化・共通化の取組における組織体制全体イメージ図292現行システムの概要調査
標準化・共通化の取組を進めるに当たっては、まずは各自治体におい
て現行システム環境の情報を整理し、把握する必要がある。
現行システムの概要調査をすることで、標準準拠システムや、標準準
拠システムと併せて更改を検討するシステムに関し、作業項目6「RFI
の実施」や作業項目9「ベンダへ提案依頼(RFP)
」を実施する際に、現
行システムに関するより正確な情報をベンダに提供できることから、各
自治体にとって最適な提案を受けることにつながる。
ア)現行システム環境の基礎調査
現行システム環境の基礎調査においては、
現行ベンダの協力のも
と、
図表 16 のとおり、
「業務システムの基礎情報」
から
「周辺機器」
にいたるまで、広範な調査を実施する必要がある。調査の実施に当
たっては、あわせて、データ移行作業のため現行ベンダがデータを
抽出する際に追加的費用が発生するか否か等、
現行ベンダとの契約
内容や見直しの可否についても十分に確認・調整しておくことが重
要である。
必ずしも調査票の全ての項目について調査を行わなければなら
ないわけではないが、本調査結果は、作業項目4「移行計画作成」
や作業項目6
「RFI の実施」、作業項目9
「ベンダへ提案依頼
(RFP)」におけるベンダへの情報提供に活用する基礎的な資料となる。
その
ため、図表 16 記載の重要度も加味した上で、可能な限り調査を行
うことが望ましい。
その際、
業務システムだけでなく、
共通基盤(宛名、職員認証、運用監視等)も含めて調査を行うことで移行作業の
円滑化を図ることができる。30図表 16 基礎調査項目
分類 調査項目 情報の用途
重要
度※(注記)
調査様式例
業務システム
の基礎情報
業務システム名 庁内の推進体
制、標準準拠
システムへの
移行時期等の
検討に活用
高 図表 17
業務主管部署(担当課)
システム所管部署(予算執行部署)現行システムのパッケージ製
品等の名称
現行システム構築ベンダ
現行システム運用保守ベンダ
現行システム利用開始年月
現行システム契約終了年月
標準準拠システムの利用開始
希望年月
外部委託状況 帳票印刷 各種外部委託
業務の要否の
判断、費用見
積りの根拠と
して活用中パンチ業務
封入・封緘・発送
その他委託作業(窓口業務委託
状況等)
システム利用
拠点
現行システムの利用拠点・住所 次期システム
環境の検討に
活用
低 図表 18
システム利用
状況
(業務主管部
署ごと)
利用対象業務システム 次期システム
環境の検討に
活用
低 図表 19
システム利用者数
システム端末台数
データ量 業務ごとの対象データ項目(住
民登録者数、地区別の人口等)
次期システム
へのデータ移
行に係る費用
見積りの根拠
として活用
低 図表 20
各データの対象数
各データの集計日・集計期間31分類 調査項目 情報の用途
重要
度※(注記)
調査様式例
周辺機器 種類(プリンター、スキャナ、
OCR 等)
・台数
各種周辺機器
の 要 否 の 判
断、費用見積
りの根拠とし
て活用
中 図表 21
設置場所
用途
型番・品番
性能要件
(カラー/白黒、
印刷速
度等)
※(注記)重要度 高:庁内検討及び RFI・RFP 時の情報提供として必須となる項目
中:RFI・RFP 時のベンダ見積りに与える影響が大きい項目
低:RFI・RFP 時のベンダ見積りに与える影響が比較的小さい項目
図表 17 業務システムの基礎情報及び外部委託状況調査シート様式の例
図表 18 システム利用拠点の調査シート様式の例
No. 利用拠点名 住所12345No
業務
システム名
パッケージ
製品等
の名称
構築
ベンダ
運用
保守
ベンダ
帳票
印刷
パンチ
業務
封入・
封緘・
発送
その他12345準拠シス
テム
利用開始
希望年月
備考
対象業務 業務主管
部署
(担当課)システム
所管部署
(予算執
行部署)
現行システム 現行
利用
開始
年月
現行
契約
終了
年月
外部委託の状況32図表 19 システム利用状況の調査シート様式の例
図表 20 データ量の調査シート様式の例
図表 21 周辺機器の調査シート様式の例住民記録個人市民税法人市民税固定資産税軽自動車税
○しろまる
○しろまる
○しろまる×ばつ
△しろさんかく
△しろさんかく
△しろさんかく...備考
利用
人数
端末
台数
業務システム名
業務
主管課
利用者(係/担当)
No. 業務名称 項目 データ名称 補足 担当課
1 住民記録 住民記録 住民登録者数
2 普通徴収対象者数
3 特別徴収義務者数
4 課税対象者数
5 普通徴収対象者数
6 特別徴収義務者数
7 課税対象者数
8 ○しろまる○しろまる○しろまる
9 ×ばつ10個人市民税 個人市民税
確定申告支援
調査対象業務量 業務主管部署
各業務に
おける
対象数
集計日/
集計期間
・・・
基幹系プリンタ12345No. 台数
4型番・
品番
(社名:
型番・品番)6対応
用紙
(A3、不
定形など)1プリンタの分類
個別の機能・性能要件
高速(連帳)/
レーザ/ドットインパ
クト単票等
備考
2設置
場所
3用途
5カラー
/白黒
7印刷
速度
8トレイ数9手差し
有無
その他周辺機器12345備考
※(注記)スキャナやOCRの速度などのスペック指定が
ある場合は記入
1周辺機器の分類
No. 台数
2設置場所 3用途
4型番・品番
(社名:型番・
品番)
個別の機能・性能要件
スキャナ/OCR/バーコード
リーダ/圧着機/その他33このほか、図表 22 に掲載されている資料について用意できる場
合は、図表 16 の基礎項目調査や作業項目3「標準仕様との比較分
析」にて後述する Fit&Gap 分析等の参考資料とすることができる。
図表 22 現行システム・現行業務に関する参考資料
No. 情報項目
1 現行システム機能要件一覧
2 現行システム帳票要件一覧
3 現行業務フロー(業務の流れ、頻度等)
4 現行ベンダとの契約内容
5 現行システムの運用保守設計書
6 年間業務スケジュール
イ)連携一覧の作成
ア)の調査項目に加え、標準化・共通化の取組を進めるに当たっ
ては、
現在利用しているシステム間での住民情報等のデータ連携に
ついても調査をすることが求められる。
これは、
自治体によってシ
ステム間で連携しているデータ項目や、連携方式(自動・手動)、処理タイミング(即時、日次等)等が異なることから、現行システ
ムの業務フローと標準仕様の業務フローとを比較し BPR を実施す
る際や、標準準拠システムへの移行の際に必要となるものである。
具体的には、図表 23 で示す「
(1)標準化対象システム間の連
携」、「
(2)標準化対象システムと標準化対象システム以外のシス
テム間の連携」及び「
(3)標準化対象システム以外のシステム間
の連携(今回併せて更改を検討するシステムに関連する連携)
」に
ついて調査が必要である。34図表 23 連携一覧の整理の対象
連携については、各自治体によってその態様も多様であること
から、
庁内の業務主管部署や現行ベンダ等とともに、
網羅的、
かつ、
正確に把握しておくことが望ましい。
【現行システムでスクラッチ開発の自治体における留意点】
特に現行システムでスクラッチ開発を行っている自治体において
は、現行システムの分析や見積り作成に、長期間要することが見込
まれることに留意し、現行ベンダと早期にスケジュールや段取り等
の協議を行う必要がある。
標準化対象システム
住民記録
個人住民税固定資産税法人住民税生活保護
障害者
福祉・・・今回更改を行わないシステム
Bシステム・・・・・・
連携する全てのシステムが調査対象
(1) (3)(2)標準化対象システム以外のシステム
Aシステム・・・・・・
今回併せて更改を検討するシステム35図表 24 連携一覧調査項目
分類 調査項目 調査様式例
現行システム
連携
データ作成元・データ連携先・連携方向 図表 25
連携情報名・主な項目(例:住基情報、住民税情報、
生活保護情報 等)
連携方式(例:自動・手動)
処理タイミング(例:即時・随時・日次・週次・月
次・年次)
調達範囲外システムとの連携対象(該当・非該当)
(調達範囲が確定していない場合は空欄でも可)
データ連携時のコード変換の有無
コード変換の仕様
図表 25 連携一覧の調査シート様式の例
例 住民記録 → 後期高齢 住記異動情報 自動 日次 該当 有
UNICODE
(UTF-16)
またはJIS12345No.方向
連携情報名・
主な項目
データ作成元
システム
データ連携先
システム
連携
方式
処理
タイミング
調達範囲外
システムとの
連携対象
備考
コード
変換の
有無
コード変換の
仕様363標準仕様との比較分析
標準仕様書が作成された後、各自治体において、標準仕様書に記載さ
れている業務フローや機能・帳票要件等について、現行の業務との
Fit&Gap 分析を実施する必要がある。
一般に Fit&Gap 分析は、自治体としてシステムに求める要件とベン
ダが開発するシステムとの違いを分析し、自治体として求める要件に合
わせていくケースが多いが、今回の標準化・共通化の取組は、標準仕様
に対して、現行システムとの差を分析し、標準仕様に合わせていくとい
う視点に立った Fit&Gap 分析を行う点に留意されたい。
また、Fit&Gap 分析を行うに先立ち、標準仕様を詳細に確認する必要
があるが、その際の確認の流れについては、図表 26 を参照されたい。
図表 26 標準仕様確認の流れ
業務フロー等の
確認
機能要件の確認 帳票要件の確認
 標準化対象範囲を確認す
る(標準化対象外のもの
についても対応方針を決め
る必要がある)
 標準仕様書における業務
フローと現行業務フローに
差異があるかを確認する
 自団体で実装している機能が
標準仕様書内の【実装すべき
機能】、【実装してもしなくても
良い機能】、【実装しない機
能】のどれに該当するかを確認
する
 標準仕様書と現行システムに
差異がある場合は、標準仕様
書に合わせる
 標準仕様書の帳票レイアウ
トと自団体が使用している
帳票レイアウトに差異があ
るかを確認する
 標準仕様書と現行システム
に差異がある場合は、標準
仕様書に合わせる
自治体
における
作業内容37ア)Fit&Gap 分析
Fit&Gap 分析は、
「STEP1 標準化対象範囲の確認・業務全体の
流れの確認」、「STEP2 業務フロー内の各作業の確認」
及び
「STEP
3 その他業務フロー外の各作業の機能・帳票要件等の確認」の3
STEP により取り組むこととなる。それぞれの STEP の作業は、
p.41 から p.45 までに記載のとおりである。
それぞれの STEP に沿って、
例えば、
住民記録システムにおける
「転居」手続について Fit&Gap 分析を実施した場合の作業イメー
ジは、図表 27 のとおり。38標準化対象範囲の確認・業務全体の流れの確認
転居の一連の事務作業で、標準化対象範囲に入っていない業務
はないか、標準化対象業務であれば、標準仕様書の業務フロー
と差異はないかQ.→標準仕様書の業務フローと現行業務の事務作業で差異がないか
比較し、差異(課題)を抽出
バックヤード
窓 口
現行業務
STEP 1
比較
管内本籍人の住所異動時に
おいても、住所情報は、CS
を介して戸籍附票システム
と連携する必要がある。
課題の抽出(例)
ア) Fit&Gap分析例(1/3)
住民担当課
住民
窓口
バックヤード
本籍地
市区町村
出入国在留
管理庁
業務フロー 4.1.2 転居 転居
入力
照合
住民記録
システム
通知
通知して終了
市町村通知等住民記録
システム
市町村通知情報及び市町村伝達情報
内容確認 本人確認 受理1標準仕様書の業務フロー
標準仕様書対応表への記載(イ)
図表 27 Fit&Gap 分析作業イメージ(例:住民記録システム 転居)39STEP 2
業務フロー内の各作業の確認(機能:管理項目・処理)
処理後に出力する可能性がある住民票の記載事項等に変更はな
いかQ.→標準仕様書の住民データの中に、使用しているデータがあるか
確認
転居を現行事務と同様に処理できる機能が定義されているかQ.→標準仕様書から機能要件を抽出し、今後の事務に支障がないか
確認
ア) Fit&Gap分析例(2/3)
課題の抽出(例)
同一住所の別領域の家屋へ移動した場合の備考
への自動記載機能を除外する必要がある。
出典:「住民記録システム標準仕様書【第1.0 版】(本体)」(総務省)
「4.1.0.1 届出に基づく住民票の記録等」(P.167)
「4.1.2.1 同一住所への転居」(P.172,173)より抜粋
標準仕様書で示されている機能要件
標準仕様書対応表への記載(イ)
図表 27(続き)40図表 27(続き)
STEP 2
業務フロー内の各作業の確認(帳票:外部・内部帳票)
処理後に出力する可能性がある住民票の記載事項等に変更は
ないかQ.→標準仕様書で定義されている様式・要件が現行帳票と異なるか
確認
ア) Fit&Gap分析例(3/3)
標準仕様書対応表への記載(イ)
STEP 3
業務フロー内の各作業の確認(帳票:外部・内部帳票)
統計データの抽出のために必要な機能や、データ取込・出力機能
などの各業務に共通した機能、アクセスログ、操作権限等、業務
フロー外の処理や各業務における共通機能に変更がないか確認
課題の抽出(例)
操作権限者を個人単位で管理する必要がある。Q.→現行の処理で内部帳票として、標準仕様書で出力することが
可能か確認
処理結果等を内部帳票として、出力できるデータ項目・形式等
に変更はないか
比較41STEP1 標準化対象範囲の確認・業務全体の流れの確認
標準仕様書内に記載されている対象分野や業務フロー等を
参照し、現行システムにおける標準化対象範囲を確認する。
標準仕様書と現行の業務において業務全体の流れに差異が
ないか、標準仕様書の業務フロー図と現行業務を照らし合わ
せ、次の観点から確認する。
 標準仕様書の業務フローと比較して、現行の業務に過不
足はないか。
 標準仕様書の業務フローと比較して、システムで対応す
る作業に差異はないか。
差異があった場合は、図表 30 を例とする標準仕様書対応
表に、当該業務フローを標準準拠システムに対応させるため
の方法を記載する。
業務フロー等の確認イメージは図表 28 のとおりである。42図表 28 業務フローの確認イメージ
現行業務の流れと差異がある場合は、
運用の見直しを検討する必要がある。
(例)管内本籍人の転居時において、
住所情報を直接戸籍附票システ
ムと連携している場合、当該機
能は「住民記録システム標準仕
様書【1.0 版】」では、「実装しな
い機能」とされているため、運用を
見直す必要がある。
出典:
「住民記録システム標準仕様書【第 1.0 版】」(令和2年9月 11 日自治体システム等
標準化検討会(住民記録システム等標準化検討会)
)P.37(
「4.1.2 転居」
)より抜粋43STEP2 業務フロー内の各作業の確認
STEP1において標準仕様書の業務フロー図と業務全体の
流れを確認した後、業務フロー内の各作業に係る標準仕様書
の機能要件、帳票要件等を分析し、現行業務への影響を確認
する。
影響がある場合は、図表 30 を例とする標準仕様書対応表
に記載する。
各作業の機能要件や帳票要件について、
Fit&Gap
分析において確認すべき事項の一例は図表 29 のとおりであ
る。
なお、
「住民記録システム標準仕様書【第 1.0 版】
」におい
ては、要件を【実装すべき機能】、【実装してもしなくても良
い機能】、【実装しない機能】
の3種類に分けて記載しており、
これらの機能要件に対応した業務フローと各自治体における
現行業務フローとの比較を行う。44図表 29 業務フロー内の各作業において確認すべき事項(例)
機能・帳票要件 該当する主な作業 各作業における確認ポイント 標準仕様書と比較すべき事項機能
管理項目
窓口:届出、内容確認
バックヤード:入力照会、証明書出力
 届出や入力照会において、不要なデータ、
不足しているデ
ータはないか。
 データの項目・種類
処理 バックヤード:入力照会
 該当作業でデータ登録をし
ていた機能はあるか。
 データ等において、
他業務と
連携の必要性はあるか。
 登録するデータ等に変更は
ないか。
 異動等のデータを登録できる機能の種類
 登録のため入力必須となるデータ
 他システムとの連携機能
 バッチ処理の種類
 エラー・アラートの種類帳票
外部帳票 バックヤード:証明書出力
 記載事項に変更はないか。
 記載内容の変更により、条
例・規則の改正が必要か。
 証明書等帳票レイアウト
 証明書記載事項
内部帳票 バックヤード:入力照会
 出力できるデータ項目・デー
タ形式等に変更はないか。
 データ項目・種類
 帳票の出力形式
 バッチ処理の種類45STEP3 その他業務フロー外の各作業の機能・帳票要件等の確認
STEP1〜2で確認した業務フローの他、統計データの抽
出のために必要な機能や、データ取込・出力機能などの各業
務に共通した機能も確認する必要がある。データの取込・出
力については、取込・出力するデータ形式やデータの種類に
齟齬がないか、その他の機能については、現在使用している
システムの機能が含まれているか、標準仕様書の機能・帳票
要件から確認し、標準仕様書と差異があった場合は、図表 30
を例とする標準仕様書対応表に記載する。
イ)標準仕様書対応表への記載
ア)で分析した結果、標準仕様書と現行の作業等で差異があり、
標準準拠システムの利用に向けて個別の対応(現行業務フローの見
直し等)を要する項目は対応表上で整理した上で、次の観点から対
応方法を検討する。
 現行業務フローの見直しを検討する必要性
 予算措置の必要性
 人員配置の必要性
 条例・規則、要綱、事務要領等の改正の必要性
 RFP・RFI を通じて対応方法を確認する必要性
 運用テストを通じて対応方法を確認する必要性46図表 30 標準仕様書対応表の記入例474移行計画作成
作業項目2「現行システムの概要調査」及び作業項目3「標準仕様と
の比較分析」の調査・分析結果や国における標準仕様書の作成、ガバメ
ントクラウドの検討状況等を踏まえ、移行時期や標準準拠システム提供
ベンダとの契約時期、予算計上時期等を検討し、移行計画を作成する。
なお、
帳票印刷などの外部委託契約を結んでいる場合は、
標準化に伴い、
委託事業者との調整が必要となる可能性がある点にも留意されたい。
図表 31 移行計画に記載する主な項目
主な項目 具体的な記載内容
移行目的  標準化を行う目的
移行方針  システム特性(パッケージへの移行)
 シングル or マルチベンダ
 ガバメントクラウドの利用
 他システムとの連携方法 等の方向性
調達範囲・単位  標準化対象システムとそれと併せて更改を検討する
システム、周辺機器・外部委託等の範囲及び単位
調達方式  指名型/公募型プロポーザル方式 or 総合評価落札方
式 or 最低価格落札方式
スケジュール  標準化・共通化に係る工程表
(図表 10 及び図表 11 参照)・RFI・RFP 実施
・予算計上
・移行時期
・条例規則改正 等の時期
移行に当たっての
課題と対策
 標準仕様と現行業務の乖離(Gap)
 標準仕様の対象外となっている機能 等
推進体制  推進本部・事務局・各業務の所管(担当)部署等のメ
ンバー及びその役割48<移行計画を作成するに当たっての留意点>
 標準準拠システムへの移行の目標時期は令和7年度とされてい
るところ、
令和4年夏までの間は、
第2グループの標準仕様書や
共通要件の検討等が継続する予定であることから、自治体にお
ける最終データ移行については、令和5年度から令和7年度ま
でに行われることが想定され、住民への影響を最小限にとどめ
ようとすると、
自ずとその機会が制約される。
全自治体が短期間
に集中してシステムを更改することを想定した場合、実際に活
用できる日程は極めて限られていることも考えられることから、
具体的な、
かつ、
余裕を持った最終データ移行時期を定めた上で
移行計画を作成すること。
 現在、標準仕様書の作成やガバメントクラウドの先行事業など
国においても並行して検討が行われており、今後順次公表され
る情報を基に、移行計画の詳細化・変更を行うこと。
また、関係府省による標準仕様の検討などにおいて自治体の多
様な実情をきめ細かく把握し、丁寧に意見等を聴くこととされ
ており、このような機会を十分に活用することが考えられる。
 標準準拠システムのシステム調達においては、標準準拠システ
ムであることを要件に付するだけで、カスタマイズすることな
く利用できることが想定され、自治体におけるシステム調達時
の作業負担の軽減が見込まれる。
その上で、
適切な調達方式(公募型・指名型プロポーザル方式、
総合評価落札方式、
最低価格落
札方式など)を検討すること。
また、標準化対象外の業務システムをあわせて調達する場合に
ついても、
例えば、
デモンストレーションによる評価を主とする
等、作業負担も勘案しながら適切な調達方式を検討すること。
 今後、
システムの更新時期を迎え、
新たな契約の締結等を検討す
る際は、ガバメントクラウド上の標準準拠システムの提供が開
始されるのが
「デジタル・ガバメント実行計画」
に基づく工程表
(図表3参照)
上令和5年度以降とされていることや、
標準準拠
システムへの移行の目標時期が令和7年度とされていることを
踏まえ、必要に応じて、例えば、現行契約の延長等、契約期間を49工夫する等の取組も併せて検討することが望ましい。
また、
この
時期に長期の契約を締結するとなると、目標時期である令和7
年度までの標準準拠システムへの円滑な移行に当たって支障と
もなり得ることから、
標準化・共通化の目標時期を念頭に置いて
適切に対応することが必要である。
 なお、今後、
「デジタル・ガバメント実行計画」に基づきオンラ
イン化を進めることとされている 31 手続のマイナポータルぴ
ったりサービスとのシステム連携についても、令和4年度まで
にシステム更改が必要となることが見込まれており、標準化の
作業と並行して取り組む必要がある。
詳細については、
自治体の
行政手続のオンライン化に係る手順書を参照すること。50(2) システム選定フェーズ
システム選定フェーズにおいては、計画立案フェーズで作成した移行
計画を踏まえ、
ベンダに対する情報提供依頼
(RFI)、移行計画の詳細化、
予算要求等を行い、ベンダへの提案依頼(RFP)を経て、標準準拠システ
ム提供ベンダを選定する。
本フェーズは、システム移行の時期によって実施すべきタイミングが
異なってくるものの、
RFI については早期に実施し、
ベンダからの情報収
集を積極的に進めることを推奨する。なお、デジタル庁(現 IT 室)を中
心に検討が進められているガバメントクラウドの整備方針や令和4年夏
を目途に取りまとめられる標準化に関する共通要件次第では、関係府省
が作成する標準仕様書に変更等が生じる可能性があるため、関係府省の
検討状況を把握の上、適切に RFI・RFP 等を実施されたい。
図表 32 システム選定フェーズの各項目の役割及び記載頁数515ベンダに対する情報提供依頼(RFI)資料の作成
計画立案フェーズにて整理した機能・帳票要件や移行計画を基に、調
達範囲について検討を行った上で、
各ベンダに情報提供依頼
(RFI)
を行
うための資料を作成する。RFI の目的は、想定している次期システムの
要件等を実現性
(想定している調達スケジュールが現実的か、
【実装して
もしなくても良い機能】の実装見込みはどの程度か等)
・経済性(自団体
が想定している費用(予算)の範囲内で調達することは可能か)の観点
から確認するものである。図表 33 の分析観点を参考に、RFI に必要と
なる資料を作成することが望ましい。
なお、機能の確認に当たっては、標準準拠システムであれば【実装す
べき機能】及び【実装しない機能】については標準仕様書に記載の要件
に準拠していることから、
【実装してもしなくても良い機能】
の実装度合
いや実際の製品の画面・操作性等を重点的に情報収集・分析することと
なる。
また、標準仕様の対象外のシステムについても併せて更改を検討する
場合は、当該システムの全ての機能・帳票要件等を対象とした、要求仕
様書等を RFI 用に作成する必要がある。52図表 33 RFI の分析観点ごとに必要となる資料
分析観点 分析内容 RFI の分析(実施)に当たって必要となる資料等 参考図表実現性全般
 調達範囲・単位、
スケジュール、
インフ
ラ等の実現性の確認
 調達範囲・単位、スケジュール、インフラ(回線容量やネット
ワーク構成等)等の調達に関する現在の想定と確認事項を整
理した資料
図表 34
機能・帳票
要件
 標準仕様書に準拠した業務フローに関
するベンダ意見の収集
 業務フローの見直しに係る課題と確認事項を整理した資料 図表 34
 【実装してもしなくても良い機能】の
うち、必要な機能の確認
 【実装してもしなくても良い機能】
のうち、
必要な機能を整理
した資料*1
図表 35
 標準準拠システムとそれ以外のシステ
ム間の連携に係る追加的に必要な連携
要件等の確認
 標準準拠システムとそれ以外のシステム間の連携に係る追加
的に必要な連携要件等を整理した資料*2
図表 36
非機能要件
 標準仕様で定められている非機能要件
のほか、追加的に必要な非機能要件の
確認
 標準仕様で定められている非機能要件のほか、追加的に必要
な非機能要件
(帳票印刷、
バッチ処理代行、
処理立会等の役務
要件等)を整理した資料*3
図表 37
デモンスト
レーション
 画面・操作性・ユーザーインターフェー
ス等が実際の製品・サービスにおいて
どのように実現されているか
 デモンストレーション実施要領、デモンストレーションにお
ける確認観点等を整理した資料 -経済性全般
 移行方式
(切替/バージョンアップ)ごとの費用の比較、妥当性の評価
 見積り様式
図表 38
機能・帳票
要件
 追加的に必要な機能・帳票要件につい
ての費用対効果の検証
 追加的に必要な機能・帳票要件ごとの見積りを取得できる様
式(*1・*2の資料において「追加費用」を記載する欄)
図表 35
図表 36
非機能要件
 追加的に必要な非機能要件についての
費用対効果の検証
 追加的に必要な非機能要件ごとの見積りを取得できる様式
(*3の資料において「追加費用」を記載する欄)
図表 37
※(注記)標準準拠システムと併せて更改を検討するシステムがある場合は、別途 RFI 用に要求仕様書等を作成する必要がある。53確認事項一覧
No 大項目 小項目 ベンダへの確認事項 ベンダ回答欄
1 全般 スケジュール 現在想定している移行スケジュールについて、対応可否をご教示ください。
2 機能要件 個人住民税 ○しろまる○しろまるという機能の実現可否をご教示ください。345RFI 時にベンダにて
記入
RFI 時にベンダにて記入
図表 34 確認事項一覧の様式例
図表 35 【実装してもしなくても良い機能】のうち必要な機能一覧の様式例54折り 圧着 製本 封入 封緘 引抜き
郵送
代行
納期(引抜き・
郵送代行なし)
納期
(全サービス)
1 個人市民税 給与支払報告書総括表
2 個人市民税
市申告書(当初準備) ※(注記)未
申告調査用も含む
3 個人市民税
住民税納付書(一般で年金
特徴でない)
4 個人市民税
住民税納付書_65歳以上(一般)5 個人市民税
住民税納付書_65歳以上
(一般で年金特徴)
ベンダ名
備考
ベンダ回答欄
提供サービス
単価 見積額
No. 業務名称 帳票名称
上表の前提条件に基づき、
RFI 時にベンダにて記入
連携要件一覧
有無
変換先
コード
1 住民記録 →
証明書コンビニ
交付システム
住基情報 自動 即時 ●くろまる 5分サイクル
2 住民記録 →
総合福祉システム住基情報 自動 随時 ●くろまる
3 固定資産税 →
被災者生活
再建支援
課税情報(現況
情報)
手動 月次 ●くろまる ●くろまる SJIS
4 個人市民税 →
証明書コンビニ
交付システム
所得証明書データ 自動 日次 ●くろまる
追加費用
調達外
システム
連携
コード変換
備考No.データ
作成元名方向
データ
連携先名
連携情報名
連携
方式
処理タイ
ミング
RFI 時に
ベンダに
て記入
折り 圧着 製本 封入 封緘
引抜き郵送
代行
同封
物の
有無
(同封物有の場合)
同封物名
1 個人市民税 給与支払報告書総括表 20,000 1枚で1通分 20,000 ●くろまる ●くろまる ●くろまる ●くろまる ●くろまる ●くろまる 有
・送付状(B5)
・返信用封筒152 個人市民税
市申告書(当初準備) ※(注記)未
申告調査用も含む
12,000 1枚で1通分 12,000 ●くろまる ●くろまる ●くろまる ●くろまる ●くろまる ●くろまる 有
・申告の手引き
・返信用封筒
・郵送申告の案内(A4)31当初分9,500件...5営業日
2調査分2,500件...3営業日
3 個人市民税
住民税納付書(一般で年金
特徴でない)
24,000 6枚で1通分 4,000 ●くろまる ●くろまる ●くろまる ●くろまる 有
・○しろまる○しろまる市税口座振替依頼書/
自動振込利用申込書(ハガキ)・課税説明用チラシ(A4)24 個人市民税
住民税納付書_65歳以上(一般)5,000 6枚で1通分 833 ●くろまる ●くろまる ●くろまる ●くろまる 有 ・課税説明用チラシ(A4) 5
項目5・6・7・8・14は同時に
依頼
(5月下旬〜6月上旬)
5 個人市民税
住民税納付書_65歳以上
(一般で年金特徴)
5,000 6枚で1通分 833 ●くろまる ●くろまる ●くろまる ●くろまる 有
・課税説明用チラシ(A4)
・年金特別徴収説明用チラシ(A4)5
項目5・6・7・8・14は同時に
依頼
(5月下旬〜6月上旬)
希望納期
(営業日)山分
け要件備考
(発送時期など)No.概算出力枚数(年間)
1通当たりの枚数
業務名称
印刷以外の役務要件(要望) 同封物要件
帳票名称
通数
(=封入
封緘の数)図表 36 追加的に必要な連携要件一覧の様式例
図表 37 追加的に必要な非機能要件一覧(帳票印刷の記載例)の様式例55【実装してもしなくても良い機能】について
既に公表されている「住民記録システム標準仕様書【第 1.0 版】
」に
おいては、自治体が利用を選択できることとして差し支えない機能と
して「実装してもしなくても良い機能」の整理がなされた。
図表 39 に示すとおり、現行システムにおけるシステム要件を整理
した上で、
「実装してもしなくても良い機能」のうち、各自治体におい
て必要だと判断する機能については、次期システムに求める機能の優
先順位付けを行うことが必要である。その上で、ベンダごとの「実装
してもしなくても良い機能」に関する実装見込みの確認を行うことが
望ましい。
図表 39 【実装してもしなくても良い機能】の確認作業
現行要件の整理
(3標準仕様との比較分析)
機能の優先順位付け 実装見込みの確認
 自団体で実装している機能が標準
仕様書内の【実装すべき機能】、
【実装してもしなくても良い機能】、
【実装しない機能】のどれに該当す
るかを確認
 ベンダごとの【実装してもしなくて
も良い機能】の実装見込みの
確認
自治体
における
作業内容
 【実装してもしなくても良い機
能】の中で自団体が次期システ
ムに求める機能を整理、優先
順位付けを実施
項目定義 金額(税込) 明細、前提条件 令和●くろまる年度
導入費用 導入の過程で必要となる初期費用 0 (千円) 0 (千円)
導入費用 パッケージシステム導入費用の総額 0 (千円) 0 (千円)
パッケージ費用 パッケージシステム本体費用 0 (千円)
サービス利用料として請求する場合は、
サービス利用料の欄に記載ください
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
0 (千円)
パッケージ適用費用 パラメータ設定や運用テスト等の導入費用 0 (千円) 0 (千円)
0 (千円)
0 (千円)
●くろまる●くろまるシステム
住民記録システム
選挙人名簿管理システム
項目
住民記録システム
選挙人名簿管理システム
固定資産税システム
個人住民税システム
法人住民税システム
軽自動車税システム
●くろまる●くろまるシステム
●くろまる●くろまるシステム
●くろまる●くろまるシステム
左記システムのパッケージ本体費用
左記システムのパッケージ適用費用
RFI 時にベンダにて記入
図表 38 見積り様式例566RFI の実施
作業項目5「ベンダに対する情報提供依頼(RFI)資料の作成」で
作成した資料を基に、各ベンダに RFI を実施する。また、文字情報基
盤文字への対応については、作業前倒しの候補となり得ることから、
ベンダに対する RFI を積極的に行うべきである。
なお、
RFI は、
必要に応じて、
移行方式
(切替/バージョンアップ)
における費用対効果の比較が可能な形式で情報収集を行うことが考
えられる。
【現行システムでスクラッチ開発の自治体における留意点】
特に現行システムでスクラッチ開発を行っている自治体で RFI
を実施する場合は、
ベンダからの回答に長期間を要することがある
ことから留意が必要である。
7RFI 結果分析及び移行計画の詳細化
作業項目6「RFI の実施」において収集した情報を集約し、分析し
た後、移行計画の詳細化・変更を行う。情報の分析に当たっては、図
表 33 で示した分析観点を参照すること。
なお、調達単位を細かく分けて RFI を実施した場合は、情報の整
理・分析に時間を要することに留意されたい。
8予算要求
RFI 結果を勘案し、
標準準拠システムへの移行経費について予算要
求を行う。
なお、予算要求に際しては、ベンダ間の見積りを照らし合わせる等
により、積算漏れ項目がないかの点検を十分に行った上で、国の財政
支援を活用することも考えられる。579ベンダへ提案依頼(RFP)
【A パターンのみ】
RFI の後、必要に応じて仕様の調整を行い、最終的な調達仕様を確
定する。その後、各ベンダへ提案依頼(RFP)を行う。
なお、
マルチベンダで標準準拠システムへの移行を想定している場
合、
契約単位数に応じた回数実施する必要があることに留意すること。
「デジタル・ガバメント推進標準ガイドライン解説書」
(令和3年
3月 30 日内閣官房情報通信技術(IT)総合戦略室)の「第 6 章 調達
ア 契約方式の検討」においては、
「契約方式は、一般競争入札(総合
評価落札方式を含む。
)を原則とする。例外的に随意契約を行う場合
には、原則、企画競争又は公募を行うことにより、透明性及び競争性
を担保するものとする。公募を行った結果、応募が複数あった場合に
は、一般競争入札(総合評価落札方式を含む。
)又は企画競争を行う
ものとする。
」とされている。
(https://cio.go.jp/guides)
RFP 実施に当たっては、調達の方式にあった様式等(実施要領や
評価基準)を作成すること。
10ベンダ選定・決定【A パターンのみ】
提案書、デモンストレーション、プレゼンテーション等により、画
面、操作性、非機能要件等を評価し、標準準拠システム提供ベンダを
決定する。なお、マルチベンダで標準準拠システムへの移行を想定し
ている場合、
契約単位数に応じた回数実施する必要があることに留意
すること。
11契約・詳細スケジュール確定
標準準拠システム提供ベンダと契約を行う。あわせて、データ移行
日等の詳細なスケジュールを確定する。なお、マルチベンダで標準準
拠システムへの移行を想定している場合、
契約単位数に応じた回数実
施する必要があることに留意すること。
【A パターンにおける留意点】
A パターンにおいては、データの円滑な移行を行うため、ま58ずは現行契約中、移行データ出力作業に係る内容の有無を確認
し、データ出力作業に係る内容が現行契約に含まれない場合に
は、
契約内容の追加・変更等を行うことが望ましい。
この場合、
移行データ不備が原因で標準準拠システムのテスト等が滞るこ
とがないように、
自治体・現行ベンダ・標準準拠システム提供ベ
ンダとの三者協議の場を設け、
データの精度・内容等について共
通認識を持つことが重要となる。
また、
ベンダ起因による移行デ
ータ不備時の移行データ出力回数に関して柔軟に対処すること
や、
移行データ出力も必要回数を見込んだ上での契約により、対処することができると考えられる。
12特定個人情報保護評価(PIA)
行政手続における特定の個人を識別するための番号の利用等に関
する法律(平成 25 年法律第 27 号。以下「番号法」という。
)に基づ
き、
標準化対象事務においても、特定個人情報ファイルを取り扱う場
合は、
特定個人情報保護評価書の作成及び個人情報保護委員会への提
出、公表が必要となる。
(参考)個人情報保護委員会 特定個人情報保護評価ホームページ
https://www.ppc.go.jp/legal/assessment/
ア)評価の対象となる事務
評価の対象となる事務は、上述のとおり特定個人情報ファイ
ルを取り扱う事務であり、
原則として、
番号法別表第一に掲げる
事務ごとに評価を実施する必要がある。
なお、
既に当該事務について評価を実施していたとしても、現行システムから標準準拠システムへの移行作業を行う際に、
シス
テムを全面的に入れ替える場合や事務手続を大幅に変更する場
合は、
評価実施機関が実施する事務又はシステム全体に複雑な影
響を及ぼしかねないことから、
評価の再実施が必要であるため留
意されたい。59イ)評価の実施手続
評価を実施又は再実施する場合、
しきい値判断※(注記)1
の結果に従い、
特定個人情報保護評価書を作成の上、個人情報保護委員会へ提出
し、当該評価書を公表する。その際、特定個人情報保護評価計画
管理書を更新し、併せて提出する。
評価の実施時期について、原則として、特定個人情報ファイル
を保有する前又は特定個人情報ファイルに重要な変更を加える
前に実施するものとされているところ、システム開発を伴う場合
は、
プログラミング開始前の適切な時期※(注記)2
に評価を実施又は再実
施する必要がある。
 特定個人情報保護評価計画管理書
 特定個人情報保護評価書※(注記)2
※(注記)1 特定個人情報ファイルを取り扱う事務について特定個人情報保
護評価を実施するに際しては、
1対象人数、
2評価実施機関の従
業者及び評価実施機関が特定個人情報ファイルの取扱いを委託
している場合の委託先の従業者のうち、当該特定個人情報ファ
イルを取り扱う者の数(以下「取扱者数」という。)、3評価実施
機関における規則第4条第8号ロに規定する特定個人情報に関
する重大事故の発生(評価実施機関が重大事故の発生を知るこ
とを含む。以下同じ。
)の有無に基づき、特定個人情報保護評価
の種類を判断する必要がある(図表 40 参照)。※(注記)2 パッケージシステムをノンカスタマイズで利用する場合は、シ
ステム等を稼働させるサーバ等へのパラメータ設定等の適用
が行われることにより、
サーバ等に直接的に変更を加えること
になるため、プログラミングに相当するものとして、システム
への適用を実施する前までに評価を実施する必要がある。
なお、実施する特定個人情報保護評価の種類によっては、個人
情報保護委員会へ提出する前に、住民からの意見聴取や条例等に
基づき自治体が設置する個人情報保護審査会等による第三者点
検を受ける事務が生じる場合もあるので、留意されたい。60出典:
「特定個人情報保護評価について
(概要版)」(個人情報保護委員会ホームページ)
より抜粋
○しろまる 特定個人情報ファイルの取扱いに重要な変更を加えようとするときは、特定個人情報保護評価を再実施。
○しろまる 特定個人情報に関する重大事故の発生等によりしきい値判断の結果が変わり新たに重点項目評価又は全項
目評価を実施するものと判断されたときは、特定個人情報保護評価を再実施。
○しろまる その他の変更が生じたときは、評価書を修正。
○しろまる 少なくとも1年に1回は評価書の見直しを行うよう努める。
○しろまる 一定期間(5年)経過前に特定個人情報保護評価を再実施するよう努める。
計画管理書の作成
特定個人情報保護評価の実施
基礎項目評価+重点項目評価
基礎項目評価+全項目評価
(地方公共団体等)
基礎項目評価+全項目評価
(行政機関等)
重点項目評価書について
は、個人情報保護委員会
に提出し、公表。
全項目評価書については、
住民等の意見聴取を実施
し、第三者点検を行った後、
個人情報保護委員会に提
出し、公表。
全項目評価書については、
国民の意見聴取を実施し、
個人情報保護委員会の承
認を受けた後、公表。
基礎項目評価
基礎項目評価書を、個人情報保護委員会に提出した後、公表。
実施後の手続き
1対象人数、2取扱者数、3特定個人情報に関する重大事故の発生の有無に基づき
実施すべき特定個人情報保護評価の種類の判断
しきい値判断
※(注記) 特定個人情報ファイルを保有する前(プログラミング前)に実施
図表 40 特定個人情報保護評価の一般的な作業フロー61(3)移行フェーズ
移行フェーズにおいては、
標準準拠システムへの移行に伴い、
実際
の画面・帳票確認や事務運用の変更内容の確認、ネットワーク接続等
を行う。加えて、移行しようとするシステムの標準準拠性について確
認する。
データ移行に関しては、
自治体・ベンダ双方に文字データ移行に係
る作業が発生する見込みであり、本作業は現行ベンダと協議のうえ、
可能な限り前倒しで作業を進めることを推奨する。
また、
標準準拠システムの円滑な稼働開始に向けて、
実際にシステ
ムを利用する自治体職員に対して十分な研修を行う。
なお、
マルチベンダで標準準拠システムへの移行を想定している場
合、ベンダ間の調整を自治体で行う必要がある点に留意されたい。
さらに、これらの作業項目に加え、標準仕様を確認し、条例や規則
等の改正が必要な場合は、
議会日程等も勘案しながら改正する必要が
ある。
図表 41 移行フェーズの各項目の役割及び記載頁数6213システム移行時の設定
標準準拠システムを基に運用のシミュレーションを行い、
標準準拠
システムの運用方法を検討・確定する。
ベンダから提供を受ける標準準拠システムの機能を確認する。
現行システムとの最終的な差異の確認(Fit&Gap)を行い、調達仕
様に対する提案内容と同一か確認する。
【Aパターンにおける留意点】
A パターンにおいては、ベンダの切替に伴い、現行システム
と操作方法や画面等の変更があり得るため、確認が必要となる。
また、
標準準拠システムと併せて更改を検討するシステムがあ
る場合には、必要に応じて要件定義(自治体が次期システムに求
める機能や業務横断的な課題について、その実現の可否・実現手
段をベンダと主管課、当該業務の関連部署・情報所管課が WG な
どを開催し、
それぞれ確認していくプロセスをいう。)を実施する。
14データ移行
既存データの整理(データクレンジング)を実施の上、データ移行
方針や外字の文字情報基盤文字への同定の基準について自治体とベ
ンダで調整を行う。
RFI 時に確認した文字情報基盤文字対応の作業について、
標準準拠
システム提供ベンダとの契約前に自治体側で先行作業できる内容(既存システムの文字セットや外字数の確認、同定作業内容の確認、同定
基準作成等)については、現行ベンダに対応可否を確認し、作業を進
める。作業の具体的な内容については、P.65「文字情報基盤文字への
対応」を参照すること。
また、データクレンジング作業(異動日・届出日・生年月日等の誤
入力の修正、必須項目の入力漏れ等に対する追記等)についても可能
な範囲で、標準準拠システム提供ベンダとの移行作業契約前に、自治
体において作業着手しておくことが望ましい。
最終のデータ移行に当たっては、
移行に備えたバックアップをとり、63行政サービスに支障が生じないように留意する。最終データ移行は、
それまでに複数回同じ手順でリハーサルを実施している前提である
が、ネットワークの帯域影響等、リハーサル時と異なる要因が原因で
作業スケジュールが遅延するリスクがないか、
あらかじめ職員と標準
準拠システム提供ベンダの作業関係者内で十分にリスク確認と対策
の検討を行う。
15テスト・研修
標準準拠システム提供ベンダと業務主管部署が調整の上、
運用テス
トデータ準備、運用テスト及びデータ移行の最終確認等を行う。
システム更改後、
データ移行内容やシステム間の連携において問題
が発生することが多いため、
事前に十分に運用テストを実施するとと
もに、
バックアップ体制確保や調整についてもあらかじめ移行計画に
組み込んでおく。
また、標準準拠システムの操作研修を開催する。会場の確保、職員
の参加手配については、
業務主管部署とも協議の上、
事前準備を行う。
【Aパターンにおける留意点】
A パターンにおいては、ベンダの切替に伴い、操作方法や画
面等の変更があり得るため、疑似データによる実機研修を行う
のか、検証環境等を利用し本番データで業務後に研修を行うの
か等、RFI、RFP 時に最適な研修方法を見極める。6416次期システムに合わせた既存環境の設定変更
ア)新システム環境構築・NW接続
標準準拠システムと庁内ネットワーク接続の設計、構築、端末整
備等を行う。また、必要に応じて、端末やプリンタ等の周辺機器の
調達も行う。
イ)他業務システム連携設計、業務間調整
他業務とのデータ連携項目、ファイル形式、処理タイミング等を
確認の上、他業務とのデータ連携テスト・変更を行う。
17条例・規則等改正
標準準拠システムを利用する場合の運用や出力される帳票等を確定
し、
議会日程等も勘案しながら、
必要に応じて条例や規則等を改正する。
特に様式等については変更が生じる可能性が大きいため、
条例や規則等
でどのように規定しているかを事前に十分に確認しておく。654.その他の留意事項
文字情報基盤文字への対応
「住民記録システム標準仕様書【第 1.0 版】
」では、他システムに対し
文字情報基盤文字で住民記録データが連携できる機能を実装すべきとさ
れていることから、
標準準拠システムの移行に際し、
文字情報基盤文字へ
の文字データ移行が発生する。また、今後、デジタル庁(現 IT 室)及び
総務省が、
各システムの共通要件を省令で定めるに当たって、
文字情報基
盤文字でのデータ連携が要件として規定された場合には、住民記録シス
テム以外のシステムについても文字データ移行作業が発生することが想
定される。
このため、
作業項目14の
「データ移行」
の際に行うのではなく、
前倒して実施することが重要となる。
文字データ移行の工程は、図表 42 のとおりである。特に「移行内容・
作業内容確認」及び「同定基準作成」は、早期に実施可能な作業と考えら
れるため、
先行着手する等、
移行作業の平準化についても積極的に検討す
ることが望ましい。
図表 42 文字データ移行の作業工程(例)
No 工程 作業概要 自治体
現行
ベンダ
標準準拠
システム
提供ベンダ
1 移行内容・作業内容確認 既存システムの文字セットや外字数の
確認、同定作業内容の確認
○しろまる ○しろまる
2 同定基準作成 同定作業に当たっての、同字とする条
件・別字とする条件の検討
○しろまる ○しろまる
3 外字ファイル抽出 既存システムの外字ファイル(字形及
び属性情報)の抽出
○しろまる
4 使用文字調査 既存システムのデータベースを調査、
移行対象文字を絞り込み
○しろまる
5 同定作業 内字・外字の同定作業を実施 ○しろまる
6 同定結果確認リスト作成 同定結果を帳票形式で作成 ○しろまる
7 同定結果確認・承認 同定結果の確認及び承認 ○しろまる
8 コード変換テーブル作成 承認結果を基に使用文字の変換テーブ
ルを作成(必要に応じて、住基統一文
字との変換テーブルも作成)
○しろまる
9 新システム用外字ファイル承認結果を基に新システム用の外字フ
ァイルを作成(必要に応じて、作成し
た外字の派生元に関する情報(戸籍統
一文字番号、住基統一文字の文字コー
ド、登記統一文字番号)も整理)
○しろまる
10 外字ファイル登録、データ
移行
外字ファイルを新システムに登録、デ
ータ移行作業及び移行結果の確認
○しろまる ○しろまる66参考 用語
以下では、本手順書についての解釈に紛れが生じないよう、用いられている
用語の定義を示した。ここで示す定義はあくまで本手順書における定義であり、
用語によっては、本手順書以外では、別の意味で用いられていることもあるの
で、留意すること。あRFI【あーるえふあい】......Request For Information の略。情報システムの
導入や業務委託を行うに当たり、発注先候補の業者に情報提供を依頼する
こと。調達条件などを決定するために必要な情報を集めるために発行する
もので、一般的にはこれを基に RFP を作成し、具体的な機能要件の提案業
者に求めて発注先の選定に移る。
RFP【あーるえふぴー】......Request For Proposal の略。情報システムの導入
や業務委託を行うに当たり、発注先候補の業者に具体的な提案を依頼する
文書。必要なシステムの概要や構成要件、調達条件が記述されている。
RPA【あーるぴーえー】......Robotic Process Automation の略。人間がコン
ピュータ操作にて行う作業を、ソフトウェアによる自動的操作により代替
するもの
IaaS【あいあーす】......Infrastructure as a service の略。システムの稼動に必
要な仮想サーバ、
機材やネットワーク等のインフラを、
「総合行政ネットワ
ーク(LGWAN)
」やインターネット上のサービスとして提供する形態のこ
と。自治体クラウドを含むクラウドコンピューティングの利用形態は、
「SaaS(software as a service)」、
「PaaS(platform as a service)」、
「IaaS
(infrastructure as a service)
」の 3 つに分類できる。
アクセスログ......端末やソフトウェアに対して、人間や外部のシステムから
の操作や要求などを一定の形式で時系列に記録したもの
アプリケーション......Web アプリケーションのことで、
Web サーバのうち、
ソフトウェアの実行環境や連携機能などをもつもの。
アラート......論理的には成立するが特に注意を要する入力等について、注意
喚起の表示を経た上で、当該入力等を確定できるもののこと。論理的に成
立し得ない入力その他の抑止すべき入力等について、抑止すべき原因が解67消されるまで、当該入力等を確定(本登録)できないエラーとは区別され
る。えAI【えーあい】......Artificial Intelligence の略。人間の思考プロセスと同じよ
うな形で動作するプログラム全般。あるいは、人間が知的と感じる情報処
理・技術全般。
エラー......論理的に成立し得ない入力その他の抑止すべき入力等について、
抑止すべき原因が解消されるまで、当該入力等を確定(本登録)できない
もののこと。論理的には成立するが特に注意を要する入力等について、注
意喚起の表示を経た上で、当該入力等を確定できるアラートとは区別され
る。おOS
【おーえす】
......Operating system の略。
基本ソフトウェアともいわれ、
コンピュータを作動させるために不可欠なシステムの入出力や同時並行処
理などを管理する複数のプログラムの集合体のこと。制御プログラム、言
語プロセッサ、ユーティリティーから構成される、基本的な操作環境を提
供するソフトウェアの総称。
OCR【おーしーあーる】......Optical character recognition の略。活字の文書
画像(通常イメージスキャナーで取り込まれる)を文字コードの列に変換
するソフトウェアのこと。光学文字認識ともいわれる。
オールインワンパッケージ......対象システムのすべてが1社のパッケージシ
ステムにより構成されている状態のこと。か外字【がいじ】......各ベンダが提供する文字セット等において、標準では収
録されておらず、市区町村が個別に追加した文字のこと。
カスタマイズ......市区町村の業務に合わせて、ベンダがパッケージの機能へ68の追加・変更・削除を行うこと。カスタマイズしていないものは、ノンカ
スタマイズと呼ぶ。
ガバメントクラウド......政府の情報システムについて、共通的な基盤・機能
を提供する複数のクラウドサービス(IaaS、PaaS、SaaS)を利用できる環
境のこと。き機能要件【きのうようけん】......業務要件を実現するために必要な情報シス
テムの機能のこと。
業務改革
(BPR)
【ぎょうむかいかく
(びーぴーあーる)】......Business Process
Reengineering の略。業務のプロセス全体について、詳細に分析・評価・改
善を行うことを通じて、抜本的な業務効率化と利便性向上の双方を実現す
ること。くクラウド......クラウドコンピューティングをさす。情報システムを外部のデ
ータセンターで保有・管理し、通信回線を経由して利用すること。こコード......文字コードをさす。文字とビット組合せの対応関係を示したもの。さSaaS【さーす】......Software as a Service の略。インターネット経由で、電子
メール、グループウェア、顧客管理などのソフトウェア機能の提供を行う
サービスのこと。
サーバ......Web サーバをさす。Web システム上で、利用者側のコンピュー
タに対しネットワークを通じて情報や機能を提供するコンピュータ及びソ
フトウェアのこと。69サイバーセキュリティ......電子的方式、磁気的方式その他人の知覚によって
は認識することができない方式(以下「電磁的方式」という。
)により記録
され、又は発信され、伝送され、若しくは受信される情報の漏えい、滅失
又は毀損の防止その他の当該情報の安全管理のために必要な措置並びに情
報システム及び情報通信ネットワークの安全性及び信頼性の確保のために
必要な措置(情報通信ネットワーク又は電磁的方式で作られた記録に係る
記録媒体を通じた電子計算機に対する不正な活動による被害の防止のため
に必要な措置を含む。)が講じられ、その状態を適切に維持管理しているこ
と。しCIO
【しーあいーおー】
......IT に関する専門的な知見に基づき、
業務の革新、
情報技術の活用を推進する役職
CS【しーえす】......住基ネット CS のことで、CS は Communication Server
(コミュニケーションサーバー)の略。各市区町村の既存住民記録システ
ムと住基ネットを接続するためのサーバのこと。
自治体クラウド【じちたいくらうど】......自治体が情報システムのハードウ
ェア、
ソフトウェア、
データなどを自庁舎で管理・運用することに代えて、
外部のデータセンターにおいて管理・運用し、ネットワーク経由で利用す
ることができるようにする取組であって、かつ、複数の自治体の情報シス
テムの集約と共同利用を行っているもの。すスクラッチ開発【すくらっちかいはつ】......既存のソフトウェア製品を改修
する等の方法で開発するのではなく、新規に開発すること。ち中間標準レイアウト
【ちゅうかんひょうじゅんれいあうと】
......市区町村の情
報システム更改においてデータ移行を円滑に行うため、移行データの項目
名称、データ型、桁数、その他の属性情報等を標準的な形式として定めた70移行ファイルのレイアウト仕様。
平成 24 年6月に総務省から公開され、平成 25 年度から、地方公共団体情報システム機構(J-LIS)が維持管理を担
っている。てDX【でぃーえっくす】......ICT の浸透が、人々の生活をあらゆる面でより良
い方向に変化させること。この変化は次のような段階(※(注記))を経て社会に
浸透し、大きな影響を及ぼすこととなる。
(※(注記))まず、インフラ、制度、組織、生産方法など従来の社会・経済システ
ムに、AI、IoT などの ICT が導入される。次に、社会・経済システム
はそれら ICT を活用できるように変革される。さらに、ICT の能力を
最大限に引き出すことのできる新たな社会
・経済システムが誕生する。
デジタル人材【でじたるじんざい】......効果的・効率的に行政サービスを提
供するために、システムや AI 等の技術を駆使することができる人材。
データクレンジング......既存データの中から、
異常値や重複データ等を修正・除去等を行い、移行しやすいデータを作成すること。と特定個人情報ファイル【とくていこじんじょうほうふぁいる】......個人番号
(個人番号に対応し、当該個人番号に代わって用いられる番号、記号その
他の符号であって、
住民票コード以外のものを含む。
)をその内容に含む個
人情報ファイル。な内字【ないじ】......各ベンダが提供する文字セット等において、標準で収録
されている文字のこと。71は
バージョンアップ......ベンダの切替を伴わずに、現行システムから標準仕様
書に準拠したシステムに更改すること。
PaaS【ぱーす】......Platform as a Service の略。インターネット経由で、仮想
化(※(注記))されたアプリケーションサーバやデータベースなどアプリケーシ
ョン実行用のプラットフォーム機能の提供を行うサービスのこと。
(※(注記))仮想化:仮想化とは、コンピュータやハードディスク、OS やアプリ
ケーションなどを物理的構成に拠らず、柔軟に分割・統合ができる技
術。1 台のものをあたかも複数台であるかのように利用できたり、逆
に複数台のものをあたかも 1 台であるかのように利用することが可能。
パッケージシステム......特定の市区町村の業務内容、運用を対象に開発した
ものではなく、業務に共通して必要な機能を汎用品(既製品)として販売
しているシステムのこと。
バッチ処理【ばっちしょり】......一括処理を行う処理方式のこと。複数の手
順からなる処理において、あらかじめ一連の手順を登録しておき、自動的
に連続処理を行う処理方式等、複数のパターンがある。
パンチ業務【ぱんちぎょうむ】......手書きの文章や数字を PC 等で入力し、
電子データとして保存する業務のこと。ひPMO
【ぴーえむおー】
......組織内における個々のプロジェクトマネジメント
の支援を横断的に行う部門や構造システムのこと。
非機能要件【ひきのうようけん】......情報システムやソフトウェアの開発時
に定義される要件のうち、機能面以外の要件全般をいう。システムの性能
や機能の信頼性、
拡張性、
運用性、
セキュリティなどに関する要件のこと。ふ72
Fit&Gap 分析【ふぃっとあんどぎゃっぷぶんせき】......事業者の提供するパ
ッケージソフトの機能が、利用者として求める要件に適合(fit)している
点と乖離(gap)している点を明らかにし、事業者の提供するパッケージソ
フトと利用者として求める要件との適合性を判断する分析手法。
プラットフォーム......情報通信技術を利用するための基盤となるハードウェ
ア、ソフトウェア、ネットワーク事業等。また、それらの基盤技術。へベンダ......ハードウェアやソフトウェア等の製品やサービスに責任を持つ
事業者のこと。
ベンダロックイン......特定ベンダ独自の技術・仕様等に依存することで、他
ベンダの提供する同種のシステム、サービス、製品等への乗り換えが困難
になること。まマルチベンダシステム......対象システムが複数社のシステムによって構成さ
れている状態のこと。も文字情報基盤
【もじじょうほうきばん】
......文字情報基盤推進委員会による、
人名等を正確に表記する必要のある行政業務で用いられる漢字約6万文字
を整備して国際標準化を行う事業、また、同事業により整備された一連の
成果物をいう。
同委員会は、
平成 22 年度に、
内閣官房情報通信技術(IT)担当室(現 IT 室)
、総務省、法務省、経済産業省、文化庁などの関係府省
や専門家、産業界関係者が参加し、独立行政法人情報処理推進機構を事務
局として設置されたものである。行政機関や行政機関内のシステムごとに
外字を作成していた文字の相互参照を可能とすることによって、行政事務
の効率を向上し、外字管理コストを削減することを目的としている。
文字情報基盤では、国際規格化を進めることを目的に作成が開始された73「IPAmj 明朝フォント」、MJ 文字集合(約6万文字)の文字に関する各種
データを集めた「MJ 文字情報一覧表」
、MJ 文字集合と JIS X 0213 の範
囲にある漢字
(約1万文字)
との結びつきを整理した
「MJ 文字縮退変換マ
ップ」
、MJ 文字情報一覧表の文字を様々な条件で検索できる「検索システ
ム」、MJ 文字情報一覧表等の文字情報をより活用しやすい形にデータベー
ス化した「文字情報基盤DB」
、その他、
「文字情報基盤導入ガイド」、「文
字情報基盤導入テクニカルスタディ」、「参考:変体仮名一覧」、「導入事例」、「調達仕様書記載例」等が提供されている。ゆユーザーインターフェース......ユーザーに対する情報の表示様式や、ユーザ
ーのデータ入力方式を規定する、
コンピュータシステムの操作感、
操作性。74参考 デジタル社会の実現に向けた重点計画
(令和3年6月 18 日閣議決定)
(抄)
第1部 我が国が目指すデジタル社会と推進体制
2.デジタル社会の形成に向けたトータルデザインと推進体制
(1)デジタル社会の形成に向けたトータルデザイン
目指すデジタル社会の形成に向けた官民の様々な施策や取組の関係について、
その全体像すなわちトータルデザインを示すとき、国民からみて、以下の3つの
階層に主に区分できる。
2 デジタル社会に必要な共通機能の整備・普及
・・・(略)・・・
さらに、地方公共団体にあっては、基幹業務システムの統一・標準化を進め
るとともに、オンライン化を促進することで、引越しなどを経ても、どこでも
同じように国民が手続等を完了できることに 繋
つ な
がる。手続を行う国民だけで
はなく、
行政事務を担う地方公共団体の職員の負担を軽減することも期待され
るところ、業務の見直しと併せて、システムの統一・標準化の実現に向けて早
急に取り組む必要がある。
・・・(略)・・・
(2)デジタル社会の形成に向けた推進体制
1 司令塔としてのデジタル庁の設置
デジタル庁は、これまで IT 政策を担ってきた高度情報通信ネットワーク社
会推進戦略本部及び官民データ活用推進戦略会議
(これらの下に開催される会
議体を含む。
)を廃止し、我が国が目指すデジタル社会の形成に関する司令塔
として設置される内閣直属の行政機関であり、
内閣総理大臣を長とする組織で
ある。デジタル大臣のほか、副大臣、大臣政務官、デジタル監等が置かれる。
デジタル庁は、主として次の役割を担う。
・・・(略)・・・
・ 地方共通のデジタル基盤に関し、全国規模のクラウド移行に向けて、総務
省と連携して、地方公共団体の情報システムの統一・標準化に関する企画と
総合調整を行い、政府全体の方針の策定と推進を担うほか、補助金の交付さ
れるシステムに関する統括・監理を行うこと。
・・・(略)・・・75第2部 デジタル社会の形成に向けた基本的な施策
1.デジタル社会に必要な共通機能の整備・普及
(2)ガバメントクラウド、ガバメントネットワーク
1 ガバメントクラウドの整備
政府情報システムについて、共通的な基盤・機能を提供する複数のクラウド
サービス
(IaaS、
PaaS、
SaaS)
の利用環境であるガバメントクラウドを整備し、
令和3年度(2021 年度)に運用を開始する。各府省庁は、令和4年度(2022
年度)以降の新たなクラウドサービスの利用の検討に当たっては、原則として
ガバメントクラウドの活用を検討する。
令和3年度
(2021 年度)
以前からクラ
ウドサービスを利用している政府情報システムについては、
更改時期等を踏ま
え、段階的にガバメントクラウドに移行する。
独立行政法人、地方公共団体、準公共分野(健康・医療・介護、教育、防災
等)等の情報システムについても、令和3年度(2021 年度)から順次、ガバメ
ントクラウドの活用に向けた方策や課題等を検討する。
2 ガバメントネットワークの整備
信頼と実績がある最新技術を採用してガバメントネットワークを再構築し、
国の行政機関等は、順次、新たなガバメントネットワークの利用への移行を図
る。これに合わせて現在利用している「政府共通ネットワーク」は廃止する。
令和2年度(2020 年度)に各府省庁のネットワーク統合後の姿を前提とし
て整備したネットワーク環境については、令和3年度(2021 年度)を通じ、円
滑な業務遂行を図るためのツールの有効性も含め、
各府省庁の円滑なネットワ
ーク統合に向けての検証を実施する。各府省庁は、令和4年度(2022 年度)以
降のネットワーク更改等を契機にこの環境への移行を検討する。
また、ネットワークに接続する情報資源を管理し、更なるセキュリティの確
保を図るため、
デバイスやアプリケーションの管理を含むディレクトリサービ
スについて、円滑かつ効率的な実現手法の検討を行う。
国においては、全国的なネットワーク環境の再構築を実現するため、地方支
分部局等との接続に際しては、
従来のインターネットサービスプロバイダ等が
提供するサービスだけでなく、国自ら既設の全国広域通信網を活用の上、直接
的に管理し、高セキュリティ、高品質、低遅延な独自の回線網を令和4年度
(2022 年度)から運用できるよう整備を進める。76地方については、地方公共団体の業務システムの統一・標準化・ガバメント
クラウドの活用に向けた検討に伴い、国・地方全体を通じた効率的かつ高品質
なネットワーク環境を整備し、国・地方間の情報連携を密にすることも含め、
より効率的に業務を遂行できる環境を整備することを目的に、必要な検討・対
応を行う。
(3)地方公共団体の基幹業務等システムの統一・標準化 1
地方公共団体の基幹業務システム 2
について、情報システムの迅速な構築と柔
軟な拡張、データ移行や連携の容易性の向上、高度のセキュリティ対策の導入、
サーバ等の共同利用による情報システムに係るコスト削減等を通じて、
デジタル
ファースト及びワンスオンリーを徹底し、
住民サービスの向上と行政の効率化を
図るため、基幹業務システムを利用する原則全ての地方公共団体が、目標時期で
ある令和7年度(2025 年度)までに、ガバメントクラウド上に構築された標準
化基準 3
に適合した基幹業務システムへ移行する統一・標準化を目指す。
具体的には、
複数のアプリケーション開発事業者が標準化基準に適合して開発
した基幹業務のアプリケーション及び基幹業務と付属又は密接に関連する業務
のアプリケーション(以下「基幹業務等のアプリケーション」という。
)をガバ
メントクラウド上に構築し、
地方公共団体がそれらの中から最適なアプリケーシ
ョンを選択することが可能となるような環境の整備を図る。
その結果、
地方公共団体が基幹業務等のアプリケーションをオンラインで利用
することにより、従来のようにサーバ等のハードウェアや OS・ミドルウェア・
アプリケーション等のソフトウェアを自ら整備・管理することが不要となる環境
の実現を目指す。
また、ガバメントクラウドが提供する共通的な基盤や機能を活用しながら、ア1「統一」とは、地方公共団体の情報システムに必要とされる機能等のうち、共通的に利
用できるものを地方公共団体が利用することを指す。例えば、地方公共団体がシステム
を共通のクラウド基盤に構築することにより、共通のハードウェアや OS などを利用する
こと等を指す。
「標準化」とは、地方公共団体が各団体で共通した事務を行っている場合
に、機能等について統一的な基準に適合したシステムを利用すること等を指す。2国民生活に直接関係する事務に係る情報システムであって、相互に連携が必要なシステ
ムを指す。3地方公共団体情報システムの標準化に関する法律(令和3年法律第 40 号)第5条第2項
第4号に規定する標準化基準を指す。77プリケーションレベルにおいては複数の民間事業者による競争環境を確保して、
ベンダーロックインによる弊害を回避する。
統一・標準化の効果を踏まえ、地方公共団体の情報システムの運用経費等につ
いては、標準化基準に適合した情報システムへの移行完了予定後の令和8年度
(2026 年度)までに、平成 30 年度(2018 年度)比で少なくとも3割の削減を
目指すこととする。また、国の削減目標は令和7年度(2025 年度)までに令和2
年度(2020 年度)比で3割削減であることを踏まえ、削減目標の更なる上積み
を目指す。
1 地方公共団体情報システム標準化基本方針の策定等
地方公共団体情報システムの標準化に関する法律(令和3年法律第 40 号。
以下「標準化法」という。
)に基づく標準化対象事務を政令で規定した上で、デ
ジタル庁は情報システム整備方針との整合性の確保の観点から、総務省は地方
公共団体との連絡調整の観点から、標準化対象事務に係る法令又は事務を所管
する府省庁とともに、標準化法第5条第1項に規定する基本方針(以下「地方
公共団体情報システム標準化基本方針」
という。)の案を策定し、
関係行政機関
の長に協議し、知事会・市長会・町村会から意見聴取を行った上で、令和3年
度(2021 年度)中を目途に定める。
標準化対象事務は、標準化法の趣旨を踏まえ、情報システムによる処理の内
容が地方公共団体において共通しているかという観点等から、累次の閣議決定
において示されてきた 17 業務 4
に、戸籍、戸籍の附票及び印鑑登録事務を加え
ることを検討する。
地方公共団体情報システム標準化基本方針においては、
法令改正の検討を行
う場合に同時に標準化基準の改定を検討する旨、統一・標準化の目的に沿った
業務改革(BPR)に関する提案を地方公共団体から所管府省庁が受け付け、標
準化基準に反映していくために必要な具体的措置、
標準化基準への適合性の確
認の方法等についても記載する。
また、システムの統一・標準化の取組については、議論の過程を透明化し、
ホームページ等にその過程を公表すること、目標・取組・スケジュール等の段4児童手当(内閣府)
、住民基本台帳、選挙人名簿管理、固定資産税、個人住民税、法人住
民税及び軽自動車税(総務省)
、就学(文部科学省)
、国民健康保険、国民年金、障害者
福祉、後期高齢者医療、介護保険、生活保護、健康管理及び児童扶養手当(厚生労働
省)並びに子ども・子育て支援(内閣府、厚生労働省)を指す。78取りを地方公共団体にも分かりやすい形で提示すること、
多様な地方公共団体
の実情や進捗をきめ細かく把握し、丁寧に意見を聴いて進めること、地方公共
団体が計画的に取組を進められるよう国として十分に支援を行うこと等につ
いても記載する。
なお、
地方公共団体情報システム標準化基本方針に定められる事項に関する
調整及び標準化対象事務ごとの進捗管理については、
デジタル庁及び関係府省
庁が地方自治体業務プロセス・情報システム標準化等に関する関係府省会議を
通じて行う。
2 標準化基準における共通事項
ア 地方公共団体によるガバメントクラウドの活用に係る先行事業の実施
ガバメントクラウド上に構築された標準化基準に適合した基幹業務シス
テムを地方公共団体が安心して利用できるようにするため、
ガバメントクラ
ウドへの移行に係る課題の検証を行う先行事業を令和3年度(2021 年度)
及び令和4年度(2022 年度)にかけて実施する。
具体的には、
ガバメントクラウド上に構築する基幹業務と付属又は密接に
関連する業務のアプリケーションの対象範囲の検討、
先行事業において構築
したシステムが「地方自治体の業務プロセス・情報システムの非機能要件の
標準(標準非機能要件)5
」が求める非機能要件(セキュリティ、可用性、性
能・拡張性、移行性、運用・保守性等)を満たすことの検証、ガバメントク
ラウドに移行したシステムと移行しないシステムとの連携の有効性の検証、
現行システムとの投資対効果との比較等を行う。
イ 非機能要件の拡充
標準非機能要件
(セキュリティを含む。)については、
先行事業での検証を
踏まえて、令和4年(2022 年)夏までに、必要に応じて拡充する。
このうちセキュリティについては、地方公共団体の業務システムの統一・
標準化の取組を踏まえ、
「自治体の三層の対策 6
」の抜本的見直しを含めた新5令和2年9月 IT 総合戦略室・総務省6平成 27 年(2015 年)以降に実施されたセキュリティ強化策であり、この対策により自
治体の内部ネットワークがインターネット接続系・LGWAN 接続系・マイナンバー利用
事務系の3つのセグメントに分割され、マイナンバー利用事務系については、他のセグ
メントと原則物理的に分離されている。79たなセキュリティ対策の在り方について検討を行う。
具体的には、デジタル庁及び総務省は、令和3年(2021 年)夏を目途に、
先行事業の検証・実稼働に向けて、地方公共団体のガバメントクラウド活用
に関するセキュリティ対策に関する要件を整理した上で、
先行事業を通じた
検討も踏まえつつ、令和4年(2022 年)の夏を目途に、基幹業務等のシステ
ムの標準化基準の作成と併せて、
地方公共団体のガバメントクラウド活用に
関するセキュリティ対策の方針を決定する。
ウ データ要件・連携要件の策定
各制度所管府省庁における標準仕様書の検討と並行して、デジタル庁は、
地方公共団体が基幹業務等のアプリケーションを選択し、
旧アプリから新ア
プリに乗換える場合等のデータ移行を容易にするため、
データ要件を定める
ほか、
基幹業務等システム間や他の行政機関等とのデータ連携が円滑に行わ
れるようにするため、連携要件を定める。
具体的には、基幹業務等システムに関する既存の標準(中間標準レイアウ
トや地域情報プラットフォーム、データ標準レイアウト)の拡充や整合性の
確保を図ることや、
基幹業務等におけるマイナポータルぴったりサービスの
円滑な活用のため、
マイナポータルと基幹業務等システムとの間の連携要件
を新たに定めるなど、
関係機関の協力を得ながら検討を進め、
令和4年
(2022
年)夏を目途にこれらの標準仕様を作成する。
データ要件・連携要件の内容と各制度関係府省庁が定める各業務の標準仕
様の内容との整合性が保たれるよう、デジタル庁と各制度関係府省庁は、相
互に連携を図る。
エ ガバメントクラウドが提供する共通機能の検討
基幹業務システムが利用可能な共通機能としてガバメントクラウドが地
方公共団体に向けて提供する機能については、
先行事業を通じて具体的な在
り方を検討し、令和4年(2022 年)夏までに、基幹業務等のシステムの標準
化基準の作成と併せて、その方針を示す。
3 制度所管府省庁による標準化基準の策定
地方公共団体における基幹業務等システムの標準化基準のうち、
2の共通事
項を除いたもの(機能要件等)については、地方公共団体情報システム標準化
基本方針に基づき、制度所管府省庁が検討体制を整備の上、以下のとおり作業80を進めるとともに、データ要件・連携要件の内容との整合性の確保を図った上
で、作成する。
この際、デジタル3原則 7
に基づき、行政サービスの利用者の利便性向上並
びに行政運営の簡素化及び効率化に立ち返った業務改革(BPR)の徹底を前提
に進める。
ア 住民記録
住民記録システムについては、
関係府省間で共有された作業方針等を踏ま
え、標準仕様書(第 1.0 版)8
を改定する。
イ 地方税(固定資産税、個人住民税、法人住民税、軽自動車税)
、選挙人名簿
管理
固定資産税、個人住民税等の基幹税務システムについては、令和3年
(2021 年)夏までに標準仕様書を作成する。
選挙人名簿管理に係るシステムについては、令和4年(2022 年)夏まで
に標準仕様書を作成する。
ウ 社会保障
国民健康保険に係る業務支援システムは、
設計書等について記載の粒度や
活用実績等を踏まえ、令和4年(2022 年)夏までに標準仕様書の見直しを
行う。
介護保険、障害者福祉に係る業務支援システムは、令和3年(2021 年)
夏までに標準仕様書を作成する。
児童扶養手当、生活保護、後期高齢者医療、国民年金、健康管理に係る業
務支援システムについても、令和4年(2022 年)夏までに標準仕様書を作
成する。
エ 教育
就学に係る学齢簿作成、就学援助認定等のシステムは、令和3年(2021
年)夏までに標準仕様書を作成する。7デジタル手続法において明記された次の3原則のこと。1デジタルファースト:個々の
手続・サービスが一貫してデジタルで完結する、2ワンスオンリー:一度提出した情報
は、二度提出することを不要とする、3コネクテッド・ワンストップ:民間サービスを
含め、複数の手続・サービスをワンストップで実現する8「住民記録システム標準仕様書【第 1.0 版】」(令和2年(2020 年)9月 11 日自治体シ
ステム等標準化検討会(住民記録システム等標準化検討会))81
オ 児童手当、子ども・子育て支援
児童手当、子ども・子育て支援に係る業務支援システムについては、令和
4年(2022 年)夏までに標準仕様書を作成する。
4 統一・標準化を進めるための支援
ア 財政支援
目標時期である令和7年度(2025 年度)までにガバメントクラウド上で
基準に適合した情報システムを利用する形態に移行することを目指すため、
デジタル庁は、令和2年度(2020 年度)第3次補正予算により地方公共団
体情報システム機構(J-LIS)に造成された基金の執行について、情報シス
テム整備方針に基づき、総務省を通じて適切に統括・監理を行う。
イ その他の支援
統一・標準化の推進に当たり、デジタル庁は、
「デジタル改革共創プラッ
トフォーム」を活用し地方公共団体と対話を行う。また、総務省は、実務を
担う専門職員が不足する小規模自治体のためにも、令和3年(2021 年)夏
を目途として、
取組の具体的内容を盛り込んだ手順書を作成した上で、
地方
公共団体に提示する。
また、
各地方公共団体が当該手順書を踏まえて市町村
の標準準拠システムへの円滑な移行を行えるよう、
関係省庁・都道府県とも
連携して市町村の進捗管理等の支援を行う。
加えて、デジタル庁及び総務省は、都道府県と連携して、複数市町村での
兼務を含め、
デジタル人材の CIO 補佐官等としての任用等が推進されるよ
うに支援の仕組みを構築する。また、地方公共団体職員との対話や研修、人
事交流等を通じて地方公共団体のデジタル人材育成に寄与する。
<連絡先>
総務省 自治行政局
住民制度課デジタル基盤推進室
電 話:03-5253-5364
メール:digital-kiban@soumu.go.jp