【備忘録】地方公共団体情報システム標準化基本方針の改定(2023/9/8)
仕様は固まらない、無理な開発スケジュール、移行を舐めた計画に私は危惧する。稚拙設計システムで個人情報漏洩！！文字同定誤りで勝手に私名前変わっていました問題！！住所が良くわからないと郵便局クレーム！！！無理な移行で事業者に過労死が出ていた～！！とかね。今までそこを気にしていたが、マシになった気がする。
そろそろ無難な判断を希望する。そして、言うこと聞かないと補助金出さないぞも含め、デジタル庁がビッグモーターレベルのような現場への圧で強制し、責任を現場に丸投げもやめましょうね。どこかの芸能事務所のように「言えない雰囲気」も作っちゃダメ！！ここでいう現場は自治体とシステムベンダー（資料では事業者）です。
資料によると「標準化リエゾン」が責任を取らされるようですね。こういう所は早いね。と言われないように、ここにどういうスキルセット（PMOだけではダメ）と自治体業務、自治体システムの特異性を知っている人を置けるかだと思います。要は一人ではなくチームであることかと。
＜資料＞
〇地方公共団体の基幹業務システムの統一・標準化（令和5年9月8日閣議決定）
地方公共団体情報システム標準化基本方針（令和5年9月8日閣議決定）
PDF（824KB）／Word（103KB）
〇地方公共団体の基幹業務等システムの統一・標準化に関する関係省庁会議（第3回）（令和5年9月1日開催）
資料2 地方公共団体の基幹業務等システムの統一・標準化に関する関係省庁会議の開催について 新旧対照表（PDF／150KB）資料3 地方公共団体の基幹業務等システムの統一・標準化に関する関係省庁会議幹事会の官職の指定について（PDF／274KB）資料4 地方公共団体の基幹業務等システムの統一・標準化に関する関係省庁会議幹事会の官職の指定について 新旧対照表（PDF／131KB）資料6 地方公共団体情報システム標準化基本方針（改定案）（PDF／370KB）
〇デジタル庁Youtube
〇メディア
＜資料備忘録＞
〇改定ポイント
改定ポイントはITmedia NEWSを引用して。その次に閣議設定された資料でコメント入れます。
自治体の業務を共通化し、システムもそれに沿ったものに移行する“自治体システム標準化”。当初は2026年3月末の完了を目指していたが、デジタル庁が23年9月8日に方針を変更。原則としてタイムリミットは変更しないものの、システム移行の難易度が高いものについては、個別に期限を設定する。
自治体システム標準化、タイムリミット一部緩和
https://www.itmedia.co.jp/news/articles/2309/08/news178.html
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/87bea441-45fa-485a-b891-2866ffecd780/ac55fc06/20230908_meeting_local_governments_outline_05.pdf
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/32fbbae9/20230908_policies_local_governments_policy_01.pdf
以下が要点です。（「→」は私のコメント）
伝わってくるのは、標準仕様を準拠しガバメントクラウドで少しでも多く本稼働させたいということでしょうか。
標準仕様書は2023年3月末までのものを対応する
→2023年9月に出ていますよね・・・運用回るの？？運用回らなかったら責任はデジタル庁なのかな？？というのを懸念して、閣議決定資料では消したのか？？2026年3月までに標準化対応をしガバメントクラウドで稼働させたいが無理なときは国が期限設定のようです。
標準化対応とガバメントクラウドでの運用で、撤退したベンダーもいるようで、自治体システムベンダーが見つけられない。リソースがないのでベンダーと契約できないのでしょう
Webアプリケーションより古いシステムはガバメントクラウド上のシステム対応は難しいので
その他（など）
→この「など」は何でしょうか・・。ベンダーの自治体数のシェアと移行ができるSEのリソースから無理ということでしょうか。無茶して死人が出ないことを願います。
移行困難はデジタル庁や総務省が移行期限を設定とするが、マイナンバーの情報連携など無茶してグダグダだった人が適切な判断をできるのだろうか・・。
「データ要件には対応すること」というのは官民連携などが後に持っているので正しい判断だと思います。
移行困難については、以下のようにあります。
標準準拠システムへの移行前の現行システムがメインフレームにより構成され、システムの全容把握からデータ移行をはじめとした標準準拠システムへの移行完了までに他システムと比較し、相対的に時間を要する場合や、現行システムを構築・運用する事業者が標準準拠システムの開発から撤退し、他の事業者を公募するなどしたものの代替事業者が見つからない場合など、移行の難易度が極めて高いと考えられるシステムについては、デジタル庁及び総務省において、当該システムの状況を十分に把握した上で、標準化基準を定める主務省令において、所要の移行完了の期限を設定することとする。
後述にも出てきますが、リソースが足らないんですね。
河野太郎デジタル相は同日の閣議後記者会見で、基本方針改定の主なポイントをこう説明した。自治体システム標準化を巡っては、全国1741自治体がそれぞれ運用している20種類の業務システムについて、ITベンダーがガバメントクラウド上に構築する標準準拠システムへの移行に取り組む。その期限が2025年度末と迫る中、ITベンダーなどのリソース逼迫が課題となっていた。
多くの自治体のシステム移行が2025年末や2026年初めに集中する見込みで、ITベンダーのリソースが逼迫する構図がより顕著になってきたことも背景にある。既に一部の自治体からは、移行期限の延長を求める声も出ていた。
仕様は固まらない、開発と移行期間がタイト、人が足らないなど、ヒト・モノ・カネがないのに特攻するのはおかしい。だから、ナショナルシステム化で良いと思っている。いずれ、そうせざるを得ない時代が来るのだから。
２０２３年９月、まだ改定しています。
標準化の対象となるのは「住民記録システム」「戸籍情報システム」「税務システム」「健康管理システム」など20の基幹系業務システムだ。それらの「標準仕様書」は2022年8月末までに出そろい、その後2023年3月末などに改定を続けている。
〇改定ポイント：移行困難の条件を考えてみた
移行困難なシステムの移行期限を先送りする具体的な条件やフローは「秋口以降に自治体に示す。2023年度内に移行困難システムがどの自治体でどのくらいあり、いつなら移行できるかを固めていきたい」（デジタル庁担当者）とする。
以下の条件で判断かと思った。
現行システムベンダーが撤退
仮にベンダーが見つかっても、移行の標準レイアウトを作っても、想定外データは出ます！京都市が良い例です。
現行システムが移行時の標準レイアウトに対応してくれるか？というのもある。結局、次のベンダーが他人のよくわからないシステムのデータを抽出からして、京都市のように失敗するのでは・・・。現行システムからクラウドネイティブへのアーキテクト変更度合い
システムベンダーが契約している自治体数とＳＥリソース
標準準拠システム提供するベンダーと現行システムの一致率
２０業務が現行システムと同じなら対応できる可能性はある認識稚拙な設計システム
『【ITコント】コンビニ交付で他人の住民票出た-3巻：状態遷移知っている？【設計ミス】』『【備忘録】コンビニ交付で他人の住民票などがでちゃう【設計ミス】』の通りです。事故ります・・。政令指定都市
標準仕様が不足のようですね。『再検討とされた指定都市要件について早期に標準仕様に反映するとともに、 当該要件を含む標準準拠システム、共通機能及びガバメントクラウド等の要件を 早期に確定し、情報提供を行うこと。』が必要なようです。今から再考はダメでしょ・・。京都市
京都市の刷新失敗は様々な原因があるかと思います。移行も標準化するのだから大丈夫とも考えられるが、イレギュラーデータどうするのか？などシステムが出来ても運用できないかと・・。まさか、過去に300億円税金取り忘れとか出る？？
京都市が117億円投じた30年もの基幹システム刷新を中断
と題して 2018年3月に記事を書きました。
その時に
「本稼働が2020年1月って期間が短くないですか？」
と書いたわけですが、予想通り間に合わないようです。
https://ityarou.com/programmer/2262/
考えることは同じですね。
令和 7 年度に移行作業が集中することが予測されることから、できる限り前倒しをすることによる移行時期の分散が図られるように国は地方公共団体の支援を進めていく。
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/87bea441-45fa-485a-b891-2866ffecd780/161b2827/20230908_meeting_local_governments_summary_08.pdf
移行するのはシステムベンダーじゃないの？？
〇事業者の競争環境確保し、ベンダロックイン回避
① 機能要件等の仕様の標準化とガバメントクラウドの活用により、アプリケーションレベルにおける複数の事業者による競争環境を確保する。
データベースも標準化しないと無理ですよ。前述の京都市例のように移行で失敗するかと思いますよ。民間とは違って過去データ捨てられないものもあるでしょうし。
そして、標準準拠システム20業務以外も入れないとベンダーロックは回避できないです。自治体はマルチベンダーで、標準準拠システム外とのデータ連携開発費は自治体に発生しますよね。。抜け出せないよ。。中途半端！！
しかも標準化対応でも、自治体条例も許された標準準拠20業務がある限り、なかなか離れられないかと・・。
ということで、デジタル庁は、耳を傾けていないか、分かっていないか、考えが浅いのではないかと思う。法改正とセットで進めるべきでは？
② データ要件・連携要件に関する標準化基準への適合性を確実に担保することにより、他事業者への移行をいつでも可能とする競争環境を適切に確保する。
データベース標準化はしないけどデータ連携などは統一するところはしましょうということでしょう。これは冒頭の通り正しいです。
④ 標準準拠システムの構築環境として複数のクラウドサービスから事業者が選択可能な状態（マルチクラウド環境）を整備することにより、クラウドサービス提供事業者間の競争環境を確保し、クラウドロックインを防止するとともに、高い水準のセキュリティを担保しつつ、経済性の高いガバメントクラウドサービスを提供する。
保守費上がるのでは？？結局、1ベンダーにしたがるのでは？標準仕様にマルチテナント！マイクロサービス必須にしましょう！！！（三層分離など法改正いるのかな？？）
次の文より、標準仕様に対応できるのは、数多くの業務ラインナップを持つ自治体パッケージと契約数が多いベンダーが残り、保守費が少なくシステム更改（標準対応）できないと判断し撤退したと推測する。
そして、仮に標準仕様業務を開発して参入したスタートアップも入れないのではと思うのだがね。採算が合わないので踏み込まないかと思う。スタートアップは標準準拠システム以外が無難だと思いますね。
ただし、事業者が複数の標準化対象事務に係る標準準拠システムを、１つのパッケージとして一体的に提供する場合においては、当該パッケージ内におけるデータ連携については当該事業者の責任において対応することとし、必ずしも、データ連携機能の要件に定めるとおり、データ連携機能を実装する必要はない。また、標準準拠システムに段階的に移行する場合においては、各地方公共団体における移行方法を踏まえ、最も合理的で円滑な移行を進める上で合理的に説明し得る範囲及び期間内で、必ずしも、連携要件の標準に適合する必要はない。
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/87bea441-45fa-485a-b891-2866ffecd780/f71a9250/20230908_meeting_local_governments_outline_07.pdf
〇迅速で柔軟なシステムの構築
前述で「稚拙な設計システム」を移行困難にしたのは、今からモダンアプリケーション、ガバメントクラウドのマネージドサービスで安全・安心運用は無理だろうという話と解釈しています。
設定ミスしました～住民情報ダダ洩れでした～！！となるに決まっている。インターネットにつながっていない三層分離の個人番号系で運用しなさいと思いますね。
○ 制度改正や突発的な行政需要への緊急的な対応等のために標準準拠システムを改修する必要がある場合には、当該法令の施行や緊急対応サービスの開始時期に間に合うよう、国が標準化基準を策定又は変更することで、地方公共団体が個別に対応する負担を軽減するとともに、当該改修の範囲を最小限にし、かつ、迅速に改修を行えるようにする。このため、次の点を念頭に置いてシステム構築を図る。
① 標準準拠システムを、モダンアプリケーション（アプリケーションをサービス単位で疎結合（結合される各情報システムの独立性が高く、システム機能の結合レベルが緩やかな結合をいう。以下同じ。）に構成し、サービス同士をＡＰＩで連携させるような設計構造をいう。）のアーキテクチャに基づき構築する。
② ガバメントクラウドのマネージドサービス（運用を自動化するクラウドサービスをいう。以下同じ。）等を活用する。
まあ～マイクロサービス化に向かうのでしょう。サービスメッシュはするようなので、ここは良いと思います。
〇標準準拠システムへの円滑かつ安全な移行とトータルデザイン
具体的には、令和５年（2023年）４月から令和８年（2026年）３月までを「移行支援期間」と位置付け、国はそのために必要な支援を積極的に行う。
標準仕様が出ていないけどガバメントクラウドにリフトアンドシフトして本稼働が意味が分からないです。。土地のないとこ家建たず。
〇令和５年（2023年）４月以降の標準仕様書の改定への対応
令和７年度（2025年度）までの適合が制度改正等の政策上必要と判断されるものを除き、令和８年度（2026年度）以降のシステム改修時において、標準に適合させることとする。
結局、法改正などはシステム対応を強いるわけで、1700ぐらいの自治体のシステム対応が発生する。
※開発は開発ベンダー数だが、移行は自治体数
ナショナルシステム化で、現在、自治体システムを生業にしているベンダーを２０業務で開発を分けたらよいのでは？「モダンアプリケーション（アプリケーションをサービス単位で疎結合（結合される各情報システムの独立性が高く、システム機能の結合レベルが緩やかな結合をいう。以下同じ。」なら、やるのは今でしょ！少しでも開発を前倒しに終わらせないと移行は完結できない！
〇標準化対象事務に関する情報システムの運用経費等は３割の削減
標準化対象事務に関する情報システムの運用経費等については、標準準拠システムへの移行完了後に、平成30年度（2018年度）比で少なくとも３割の削減を目指すこととし、国は、デジタル３原則に基づくＢＰＲを含めた業務全体の運用費用の適正化のための次の取組を行うことにより、当該目標の実現に向けた環境を整備する。
① トータルデザインの考え方の下で、共通機能の仕様策定や文字環境の整備等を行い、全体としてより効率的なシステム構築や運用を行うための取組を、早期に標準準拠システムに移行し当該取組に積極的に協力する地方公共団体と段階的に実証することとする。
② ガバメントクラウド上での構築・運用を前提としたアプリケーションの開発・運用の高度化に挑戦する事業者のスキル・ノウハウを底上げするための支援を強力に行う。
③ システム連携に関する効率的な検証環境の準備を進める。
サザエでございます！？マイナンバー紐付け誤りに続き「文字同定誤り！勝手に私名前変わっていました問題」が出そうな気がする。
情報システムの運用経費等の目標の達成に向けては、移行支援期間である令和７年度（2025年度）までの達成状況及び移行支援期間における実証等を踏まえるとともに、為替や物価などのコスト変動の外部要因も勘案する必要があることから、令和７年度（2025年度）までの間、必要に応じた見直しの検討と達成状況の段階的な検証を行う。
この手があったか～！現状維持だ！！！CSPの利用料が上がっている。ガバメントクラウドはAWS、Azure、OCI、GCPなので3割減はなしかな？
〇制度所管省庁の役割及び連携
総務省は、国と地方公共団体との連絡調整に関することを所掌する観点から、デジタル庁や制度所管省庁、都道府県知事、市長又は町村長の全国的連合組織（地方自治法（昭和22年法律第67号）第263条の３第１項に規定する全国的連合組織で同項の規定による届出をしたものをいう。以下「地方３団体」という。）と協力して、各地方公共団体が標準準拠システムに円滑に移行できるよう支援する。
一度、どこかの自治体の移行をしてみたらよいのでは？
〇標準準拠システム以外のシステムとの関係
標準準拠システムと情報連携する標準準拠システム以外のシステムには、標準化対象外事務を実現するためのシステム（独自施策システムや外部システム等）や標準化対象外機能等を実現するためのシステムがある。
標準準拠システム以外の業務をターゲットにスタートアップが入ったとしても、標準準拠システム外のデータを照会する必要がある業務なら、照会先ごと（ベンダーごと）のデータ連携が発生すると悲惨だろうな。ここらあたりのセンスが３周遅れのIT後進国と揶揄されると思ったり・・・。
ちなみに標準準拠対象業務でも、自治体の条例で決められる業務もあるので、そこはデータ連携標準仕様で定義できない。そう、この条例も厄介なんですよね。そこが考慮できていないような気がするのだが。。
標準準拠システムは次の通りです。
○ 20業務（児童手当、子ども・子育て支援、住民基本台帳、戸籍の附票、印鑑登録、選挙人名簿管理、固定資産税、個人住民税、法人住民税、軽自動車税、戸籍、就学、健康管理、児童扶養手当、生活保護、障害者福祉、介護保険、国民健康保険、後期高齢者医療、国民年金）に係る機能標準化基準で定める内容を盛り込んだ標準仕様書については、令和４年度（2022年度）に作成及び改定されたところであり、主務省令はその後に定める。
〇ガバメントクラウドの利用料
ガバメントクラウドの利用に応じて地方公共団体が負担する。利用料の負担方法については、利用料等の見通しや先行事業等での検証結果などを明らかにした上で、デジタル庁、総務省、財務省、地方公共団体等が協議して検討を行い、令和６年度（2024年度）予算編成と併せて具体化を進め、デジタル庁が別途定める。
移行前倒しも求めていくが、利用料の負担は不明って、自治体マンション早く入居しろ！家賃は後で決めよう！って聞こえるのだが・・。
早期にガバメントクラウドへ移行し、国が行う検証等の取組に積極的に参加する団体に対しては、標準準拠システムを効率的に運用するために検証を行いながら移行を進められるよう、技術的支援に加え、当該検証等に要する費用を国が支援するなど、必要な支援を行う。
デジタル庁と自治体の間に入る人が、正しい情報を国に伝え、国が正しく捉えられれば良いけど。
〇共通機能の標準
共通機能とは、標準準拠システムを用いて業務を行う際に必要な機能であって、全ての標準化対象事務に係る標準準拠システムに共通して実装することができる機能である。
以下、全部を国で用意しましょう。ベンダーロック回避ですよね！自治体システムはマルチベンダーなので、ここを握ったベンダーが勝つと思いません？以下のシステムも含めて移行はきついかと・・・。せめてこれだけでもデータベースのテーブル定義あわせないと。
共通機能の標準は、上記の作成方針に従い、次の機能について定めることを基本とする。
(1) 申請管理機能（申請者が地方公共団体に対し申請手続等を行うマイナポータルと標準準拠システムの間を連携する機能）
(2) 庁内データ連携機能（標準準拠システムが、他の標準準拠システムにデータを送信又は他の標準準拠システムからデータを受信することを効率的かつ円滑に行う機能）
(3) 住登外者宛名番号管理機能（庁内で管理する住登外者を一意に特定するための住登外者宛名番号を付番・管理する機能）
(4) 団体内統合宛名機能（団体内統合宛名番号を付番し、中間サーバと連携する機能）
(5) ＥＵＣ機能（職員自身が表計算ソフト等を用いて情報を活用するために基幹業務システムのデータを抽出、分析、加工、出力する機能）
(6) 統合収納管理機能・統合滞納管理機能（標準化対象システムにおける各賦課業務（税務、介護保険、国民健康保険、後期高齢者医療、子ども・子育て支援をいう。）のうち２業務以上と連携し、共通的に収納管理及び滞納管理を行う機能）
〇共通標準化基準の適合性の確認
標準準拠システムは、デジタル庁が提供するツールを使って実施されるデータ要件・連携要件に関する標準化基準に係る適合確認試験に合格したシステムでなければならないこととする。
〇文字同定
２．文字要件について 文字要件の運用について、令和６年度からの同定マップの本格運用に向け、令和５年度中に地方公共団体における文字同 定作業の全容を明らかにする。 また、令和５年度中に文字同定作業等に係る実証事業を行い、検証内容を示すほか、デジタル庁が定める行政事務標準文字 の管理や地方公共団体における運用上の課題等への対応について、令和５年度中に具体的な対応方針を明らかにする。
まっ文字の同定作業はデジタル庁でAPI用意してあげて・・。
当初は外字を無くして「MJ」文字で運用したかったが無理なので「MJ+」としたようだ。でもさ、標準準拠システム間ということは自治体システムの20業務だけですよね・・。道のりは遠い。
というか、字形ファイルを渡したら候補外字コードと字形のセットを返すAPIをガバメントクラウド上で構築すればよいのでは・・。
〇標準化リエゾン
各地方公共団体との連絡調整窓口は引き続き総務省に担っていただきつつ、デジタル庁では各都道府県からの派遣職員による「標準化リエゾン」を今年 5 月から設置しているため、こうした仕組みを用いて、地方公共団体と「顔の見える関係」を構築し、状況把握を行いながら、技術的観点からの支援を行っていく。その際には、各制度所管省庁の御支援もお願いしたい。
https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/87bea441-45fa-485a-b891-2866ffecd780/161b2827/20230908_meeting_local_governments_summary_08.pdf
〇人には厳しく自分には優しく
１．適合確認について データ要件・連携要件に係る円滑な適合確認の実施のため、令和５年９月中を目途に適合確認ツールを作成し、早期に適合確認試験の実施を目指す。 また、データ要件・連携要件標準仕様書の改定に伴う適合確認ツールの改修及び適合確認試験の実施予定日等の運用方針 については、デジタル庁及び総務省で協議の上、早期に別途定める。
「目指す」「早期に」が好きですね。
〇標準仕様改定ルール
未来のことも書いておこう。
→改定仕様のデッドライン
パブリックではこう言っても、運用を回すべく、システム対応をやらざるを得ないようになり。そして、新たな不具合が出るかもね。
→標準仕様書の改定は、原則として、8月31日又は1月31日
→データ要件・連携要件標準仕様書については、各業務の標準仕様書の改定後１ヶ月後を目途として改定
#デジタル
#システム
#自治体
#マイナンバー
#移行
#ガバメントクラウド
#標準仕様
#アドレス・ベース・レジストリ
#情報連携
#自治体システム
#標準準拠
#地方公共団体の基幹業務システムの統一・標準化
#共通機能等技術要件検討会
#データ連携
#申請管理
#宛名管理
#ナショナルシステム
#デジタル庁
#ガバメントクラウド
#自治体システム
#標準準拠
#公共サービスメッシュ
#中間サーバ
#マイナちゃん
#マイキーくん
#自治体DX
#ITコント
#公金口座
#マイナポータル