標準準拠システムにおけるカスタマイズ・EUCについての課題整理
国、自治体、ベンダーが一丸となっている「標準準拠システム」への移行に関して、これまで息を吐くように行われていたカスタマイズはどうなるのか、またEUCについて運用に耐えうるもの仕上がるのかといったことを、徒然なるままに書きなぐってみようと思います。
※自分の整理も兼ねて書いてます。なるべく公表されている事実に基づいて書こうとは思っていますが、自分の感想・意見も多分に含まれます。ご容赦ください。
1．これまでのカスタマイズとは
私は2014年にSEとして入社しておりますので、バリバリのパッケージビジネス世代です。パッケージビジネスとは、型決めされた仕様で開発された業務システムを、複数団体にそのまま提供し利用いただくことで、管理コスト等を集約して利益を出そう、というものです。なので、原則パッケージの仕様を変更する、追加するカスタマイズはNGとされています。（少なくとも弊社では。）
ただし、実態はパッケージビジネス以前、現地作りこみシステム時代の運用を、ユーザ側は変えたくないので、現行踏襲できるようなカスタマイズが、これでもかというほど実施されている状況です。まれに「パッケージを導入するのだから、運用側がシステムに合わせるべき！」という職員様に遭遇することがあり、いたく感動することもありました。
カスタマイズが入っているデメリットはというと、先述したように管理を集約しづらくなるので、管理コストがかかります。また数十年前のトレーサビリティがあまり重要視されていない時代に実装されたカスタマイズは、荒い設計書しか残っておらず、法改正時や機器更新時にカスタマイズソースに手を入れると正しく動作しなくなる、など品質の観点でもリスクがありますし、もちろんソース修正工数やテスト工数も余分にかかってきます（コスト増）。もちろん、そこも担保しますよ！ということで契約しているのですが、現地SEとしては黒ひげ危機一髪をやらされているような気持ちです。そのため、我々ベンダーとしても、カスタマイズは可能であればご勘弁願いたいものである、ということをまず主張させていただきたいです。
2．標準化対応におけるカスタマイズとは
では、標準化対応におけるカスタマイズは、これまでのカスタマイズとは異なる意味を持つのでしょうか。これを整理するには、そもそもなぜ標準準拠システムを導入しないといけないんだっけ？という原点に立ち戻る必要があります。
①カスタマイズ撲滅大作戦
総務省のHPに「自治体情報システムの標準化・共通化に向けた取組」というPDFが掲載されています。これまでの、標準化・共通化の取組の軌跡がまとめられております。
（https://www.soumu.go.jp/main_content/000733148.pdf）
先述したように、様々な自治体でカスタマイズされることにより、コスト、品質、あとは法施策などのデリバリーにも影響がでるとされています。なので、なるべくカスタマイズしないようにシステムの標準化（仕様の統一という文脈でしょう）を進めましょう！ということです。我々ベンダーはお客さんに頼むのではなく、国が言ってくれるのですから、ありがたい話ですよね！
もちろん他にも、2040問題（高齢化社会が進行し、労働人口が著しく減少するため、少ない労働力でこれまで以上に高度な行政レベルを維持しないといけない！っていうアレ）などが理由にもあげられていますが、カスタマイズは撲滅せねばならんのです。話は続きます。
何故基幹システムが対象なのか、また標準化することによるメリットが述べられています。曰く、法令により定められているので創意工夫の幅が小さく、本来であれば現状のようなバラバラな状況には陥らんだろうということ。画一的な仕様を定めれば、カスタマイズの抑制、ベンダーロックインを防ぎ、事業者間システム移行も容易になるということ。我々ベンダーにとっては、中々耳の痛い話となってきます。でも言っていることは理路整然としており、我々はその仕様に則ってシステムを開発すればいいのね、ということになりました。ではその仕様はどのように定められ、どういった内容になるのでしょうか。
標準仕様書は、デジタル庁が策定する基本方針の下、関係府省が作成することとなりました。次にデジタル庁が策定した基本方針を確認します。
②標準仕様書とは
度はデジタル庁のHPに移ります。「地方公共団体情報システム標準化基本方針（令和5年9月8日閣議決定）にデジタル庁の定める基本方針が定められています。標準仕様書の構成について、述べられている箇所を抜粋してみます。
○機能標準化基準において規定する機能の要件には、(1)実装必須機能、(2)標準オプション機能、(3)実装不可機能のいずれかの分類を、機能ごとに明記する。
(1) 実装必須機能は、標準準拠システムに実装しなければならない。
(2) 標準オプション機能は、標準準拠システムに実装してもしなくても良い機能である。地方公共団体の政策判断や人口規模等による業務実施状況の違いがあり、その違いを吸収するため、やむを得ない場合に設定する。事業者が標準オプション機能を実装するかどうかを判断して標準準拠システムを構築し、複数の事業者が構築した標準準拠システムの中から、地方公共団体は、自らの団体に適したものを選び、当該標準準拠システムを提供する事業者と契約して利用する。
(3) 実装不可機能は、標準準拠システムに実装してはならない。また、標準準拠システムと疎結合で構築することもできない。
なお、(1)～(3)のいずれにも位置付けられていない機能については、原則(3)として扱うものとする。ただし、自治体や事業者の創意工夫により新たな機能をシステムに試行的に実装させて機能改善の提案を行う場合であって、他の地方公共団体においても当該機能の必要性が高いと考えられるものについては、当該機能の取扱いを標準仕様書の作成・更新過程において検討することとし、実験的に実装を可能とする。実験的に実装を希望する地方公共団体は、当該機能の概要や費用対効果の検証結果を他の地方公共団体と共有することを前提に標準化検証機能（標準化対象事務において、標準化の対象外と明記されていないが、標準仕様書への位置付けを検討中である機能をいう。）として、デジタル庁に登録し、標準準拠システムと疎結合で構築することとし、その詳細についてはデジタル庁が別途定める。
（令和5年9月8日閣議決定）
（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/19edfeb0/20230908_policies_local_governments_policy_02.docx）
ちゃんと読みましたか？ちゃんと読みましたね？笑
つまり、全区市町村および広域自治体みんなが必ず守らなければならないのは、「実装必須機能」のみとなります。また、「実装不可機能」はいかなる場合においても実装してはいけない、ということになります。仕様書に明記されていない機能についても、現時点では実装してはいけません（手続きを踏むことで将来的には実装できる可能性はあります。ちゃんと読みましたね？笑）。
ということは、自治体によって差が出るものは「標準オプション機能」のみとなるはずです。我々ベンダーは、各自治体の求める標準オプション機能を、標準準拠版パッケージに実装することによって、競争力を高めていくことになります。あくまでパッケージビジネスになるので、より多くの自治体が欲すると思われる標準オプション機能を見極め、パッケージに実装させる、が基本動作になります。例外的に、予算に余裕のある自治体さんに対しては現地で標準オプション機能を追加する、ということもありうるかもしれません。これがベンダーからするとカスタマイズにあたるかと思います。2025年度末までは必須機能で手一杯です！というベンダーもいる可能性も大いに、大いにありますが、制度から読み取れる状況としては、このような感じだと認識しています。
続いて、定義する機能の種類について言及している箇所を抜粋します。
5.1.1.3 機能標準化基準の構成
○機能標準化基準は、機能要件の標準、画面要件の標準及び帳票要件の標準で構成する。
5.1.1.3.1 機能要件の標準
○機能要件とは、システムに対し、どのようなデータを入力し、どのような処理を行い、結果、どのような出力がされるか等の要件を規定するものである。
～省略～
5.1.1.3.2 画面要件の標準
○画面要件とは、システムが出力する画面に関する要件を規定するものである。画面は、通常は事業者の競争領域であることから、画面がカスタマイズの主要因となっている場合に限り、画面要件の標準を作成する。
5.1.1.3.3 帳票要件の標準
○帳票要件とは、システムから出力する帳票・様式に関する要件を規定するものである。
○帳票には、(1)住民向けの帳票・様式（通知・証明書等）と、(2)職員向けの帳票・様式（確認のための一覧表等）がある。
(1)住民向けの帳票・様式については、既に外部システムにおける仕様等で規定され、カスタマイズの主要因となっていない帳票・様式等を除いて、標準を定める。
(2)職員向けの帳票・様式については、紙への出力を前提とするのではなく、ＥＵＣ機能等を利用して画面で確認する等のデジタル化を原則とし、真に必要なものに限定して、標準を定める。
○帳票要件の標準は、(1)帳票ＩＤ、(2)帳票のレイアウト、(3)帳票の諸元表で主に構成する。
(1)帳票ＩＤは、帳票の管理や電子的な交付等を行う際に利用する。統一的なＩＤの振り方については、デジタル庁が別途定める。
(2)帳票のレイアウトは、標準化されていない場合にはカスタマイズの発生原因となるため、標準を定めることを基本とする。
(3)帳票の諸元表は、データ要件の標準と整合性を保たなければならない。なお、二重管理を避けるなどの観点から、データ要件の標準をもってこれに代えることができる。
はい、全部読みましたか？読みましたね？
では実際に、標準仕様書を見てみます。試しに「住民記録システム標準仕様書【第4.1版】 別紙 機能・帳票要件一覧」を確認しましょう。
（ https://www.soumu.go.jp/main_content/000900661.xlsx）
「機能・帳票要件一覧」シートを見ると、H,I,J列に「実装区分」とあります。指定都市、中核市、一般区市町村で実装区分が分かれるということです。少し前に、「実装必須機能」のみが、すべての自治体で必須となるといったことが早速嘘になってしまいました。申し訳ございません。ここに「◎」がついているものが「実装必須機能」です。
例えば、F列の機能ID「0010133」の「処理日は、処理当日が自動入力されること。」という機能は、すべての自治体区分で実装区分が「◎」になっていますので、これはすべてのベンダーのすべてのパッケージで実装する機能になります。逆に、その次の「0010134」の「処理当日以外を処理日として入力できること。」という機能はすべての自治体区分で実装区分が「×」になっていますので、これはすべてのベンダーのすべてのパッケージで実装してはいけない機能になります。では次に、機能ID「0010045」をご覧ください。「方書から住所地番を候補として選択できること。」という機能はすべての自治体区分で実装区分が「〇」になっています。
機能ID「0010133」・「0010134」 ・「001045」
（https://www.soumu.go.jp/main_content/000900661.xlsx）
これが「標準オプション機能」です。便利機能的な扱いにあたりますので、然もありなんという感じですね。こういった形で、機能要件については整理をされています。帳票要件の見方も一緒です。画面要件は割愛します。標準仕様書について、だいぶ具体的にイメージできたと思いますので、ここで区切りとします。
③カスタマイズはなくせるか
ここまで述べてきた通り、デジタル庁の定めるルールに従っていけば、カスタマイズは撲滅されることとなります（途中述べましたが、ベンダーのパッケージ管理の観点からすると、個別に標準オプション機能を実装することはあり得ますので、ベンダーからするとカスタマイズは残るとも言えます。）。ところがどっこい、基本方針には下記の記載もあるのです。
3.2 標準準拠システムの機能等に係る必要な最小限度の改変又は追加
○標準化法第８条第２項は、地方公共団体において、「標準化対象事務以外の事務を地方公共団体情報システムを利用して一体的に処理することが効率的であると認める」ときは、「当該地方公共団体情報システムに係る互換性が確保される場合に限り、標準化基準に適合する当該地方公共団体情報システムの機能等について当該事務を処理するため必要な最小限度の改変又は追加を行うことができる」旨規定している。
○地方公共団体が行っている独自施策のうち、標準化対象外事務において、地方公共団体の基幹業務システムの統一・標準化の目標等を踏まえると、標準準拠システムのカスタマイズについては、原則として不可であり、標準準拠システムとは別のシステムとして疎結合で構築することが望ましく、真にやむを得ない場合に限るものとする。
難しすぎんねん！！！
いえ、くじけずに向き合ってみましょう。まずは「標準化対象事務以外の事務を地方公共団体情報システムを利用して一体的に処理することが効率的であると認める」ですが、「子ども子育て支援システム標準仕様書（第1.1版）」をもとに一例をあげてみます。
<延長保育事業の標準化の対象事務範囲>
延長保育の利用の決定や延長保育料の算定、納付管理に関する事務
※延長保育を行う園への補助事業等は対象事務範囲外。
<実費徴収に係る補足給付を行う事業の標準化の対象事務範囲>
施設型給付を受けない幼稚園における副食費の補足給付に関する事務
（h￥ttps://www.cfa.go.jp/assets/contents/node/basic_page/field_ref_resources/7fa80f34-9ed2-49f6-963d-038c7d0f0632/1795b5f2/20230523_jichitaijoho_system_shien_01.pdf）
と明記されています。この場合、標準化対象外事務は標準準拠システムには実装せずに、
別システムとして構築したうえで標準準拠システムと疎結合することが基本ルールとなっています。下記のイメージです。
著者作成
しかし、現在利用しているパッケージではこれらの事務が一体的に処理されている、外部システムに切り出すことで業務効率が損なわれるなど様々な課題が生じることが考えられます。その場合においては、まずはベンダーに対して、外部システムとしての構築を打診し、受け入れられない場合は「真にやむを得ない」と判断し、下図のような形での構築となると考えています。
著者作成
これが、標準化対応におけるカスタマイズの一つの姿だと考えています。ただし、ここで気を付けておきたいのが、この対応が許されるのはあくまで下記の機能群に限定されるということです。
・標準化対象外事務：標準化対象事務の範囲に含まれない事務をいう。独自施策や、外部システムが対象とする事務がある。
・標準化対象外機能：標準仕様書において、明示的に標準化の対象外としている施策に係る機能をいう。
（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/034f5707/20220428_policies_local_governments_outline_01.pdf）
あとは、先述したように標準仕様書に明記されていない機能が、「独自機能」として定義されていますが、これは基本的には実装してはいけません。実装するには、所定の手続きが必要となります。
「資料：地方公共団体の基幹業務システムの 統一・標準化のために 検討すべき点について」（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/034f5707/20220428_policies_local_governments_outline_01.pdf）
独自機能が実装されないようにするには、標準仕様書を隅から隅まで読み込み、現行システム機能とのFIT＆GAPの中で、実装不可機能および独自機能が現行システム機能に存在した場合には、BPRによりシステム化以外での手段を検討するしかありません。
また、経過措置として下図の対応も認められています。
「資料：地方公共団体の基幹業務システムの 統一・標準化のために 検討すべき点について」（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/c58162cb-92e5-4a43-9ad5-095b7c45100c/034f5707/20220428_policies_local_governments_outline_01.pdf）
所謂、パッケージ特例と呼ばれるものです。先ほどの「一体的に処理する場合のイメージ」と酷似しています。
著者作成
つまり、標準準拠システムへの直接のカスタマイズについては、あくまで経過措置的に許されているものと思っていたほうがよさそうです。あくまで「移行を円滑に行うため」の経過措置となっているため、2025年度以降に終了となる可能性が高いと思われます。
⑥曖昧な標準仕様書への対応
ここまでは、総務省およびデジ庁のルールにのっとったうえで、カスタマイズが本当になくなるのかを考えました。ここからは、標準仕様書に則って開発をすれば、本当に自治体が横並びで使えるアプリケーションが開発でき、カスタマイズ抑制が可能かどうかを考えます。
（６）計算・集計ロジックに係る事項
税務業務においては、課税計算や延滞金、還付加算金、各種集計表等の計算・集計ロジックが多く存在する。これらについては、システムの内部設計に当たると考えられるため、本仕様書では詳細化を行っていない。
（ https://www.soumu.go.jp/main_content/000898739.pdf）
記載の通り、税務システムは膨大で複雑な計算から成り立っており、各社のパッケージもそうですが、各自治体の制度対応や法解釈の揺らぎによりその計算式は大なり小なり異なっています。その状態において、標準仕様書では、標準となる計算ロジックが定められないため、各ベンダーは、各ベンダーの解釈で税務システムを構築することとなります。
その結果、標準準拠システム導入前後で、計算結果に差異が生じることが懸念されます。これまでもベンダーリプレース時には同様の課題が発生しておりましたが、基本的には導入するパッケージ側の計算式にカスタマイズを加えることで、影響が出ないように対処をしていました。今回はBパターン（現行事業者が標準化対応を行う）の場合においても、計算式が異なる可能性があります。
自治体として、それを受け入れられない場合は、計算式は標準仕様書に定義されないので、ベンダーに計算式を現行と合わせるように要求することができます。ベンダーがそれに対応することも、標準準拠パッケージへのカスタマイズとなります。
このように、各自治体の様々な運用に対応するために標準仕様書の定義を曖昧にしている要件がある場合には、すべての自治体でその機能に対する要件定義が必要になり、カスタマイズ実施要否の判断を双方で行い、原則2025年度末までに標準準拠システムへの移行を完遂させる必要があります。これは、現実的ではないと考えます。
⑤まとめ
一度整理をします。標準化以降のカスタマイズは、下記３つになると考えます。
標準準拠パッケージに実装した標準オプション機能以外の標準オプション機能（※ベンダー目線でのカスタマイズであり、自治体からはあまり関係なし）
パッケージ特例等で実装した標準対象外事務／機能
（ただし経過措置のため、疎結合対応をする際に再度改修が必要）標準仕様書上曖昧に定義された機能に対する各自治体への要望対応
3．移行期限を見据えたカスタマイズの実現性
ここまでで、標準化におけるカスタマイズがどういったものになるのかに対して、自分なりの解を示しました。自治体運用の観点から考えると、「この標準オプション機能は必ず実装してほしい」「標準対象外事務／機能はどういう形でもいいので実装してほしい」「標準仕様書上、現場の好きにしていいと読み取れるものは現行踏襲してほしい」というニーズが多数あることが想定されます。
しかし、ベンダー側の状況はというと、まずは標準準拠システムと呼べるように、「実装必須機能」の実装を最優先で行っているところです。それでも、一部の必須機能の開発が追い付いていない業務も存在します。原因としては、昨今叫ばれておるベンダーのリソース不足、2025年度末までに施行を迎えることが予想される法改正への対応などが挙げられます。こういった状況のため、やむを得ず移行困難を自治体に申請するベンダーも増えてきています。
そういった状況の中で、標準オプション機能、標準対象外の事務／機能については、なかなか検討が進んでいかない実情があります。仮に必須機能の開発が間に合ったとしても、その自治体運用には必須の「標準オプション機能」が実装されていない、という可能性も考えられます。例えば、都道府県ごと、区市町村ごとに行っている給付の上乗せ事業や、特別な手当については、そのほとんどが標準オプション機能として整理されています。そういった場合はやむを得ず、現行システムと二重稼働させたうえで、標準オプション機能にあたる機能は、現行システム側を利用します。その際は、双方のシステムが連携可能となるように改修が必要となります。これもある種、カスタマイズと言えるでしょう。当然、SEリソースが個別に必要となるケースも考えられます。
ここでさらに状況を悪化させるのが、現行システムの保守の終了です。ベンダー側からすると、標準準拠システムがはれて完成できたのであれば、可能な限り早く現行システムを手放したいのです。その理由は、法改正対応です。法改正は標準化に関係なくどんどん進んでいくものですから、現行システムと標準準拠システムが同時に稼働する時間が長くなればなるほど、双方のシステムに対する改修が必要となってしまうのです。ご存じの通り、現行システムにはカスタマイズがてんこ盛りです。そのカスタマイズをつぶさないように、丁寧に法改正資産を適用するには、やはり現地SEのリソースが必要となります。
その場合には、例えば標準準拠システムからＥＵＣ機能（後述）を用いて、必須機能で作成した処理結果をアウトプットし、職員の手により何らかの形で改修し、それを個別で管理する、あるいは再度標準準拠システムに結果をロードさせる、などの対応が考えられます。職員の俗人化、品質担保への懸念など、大きな課題が生じると思います。
また、そもそもですがこのようにカスタマイズ残存の可能性があるのであれば、標準仕様に即して開発した標準準拠パッケージを自治体で共同利用する、ベンダーのリプレースをこれまで以上に簡素化して行う、国の施策をより迅速に標準準拠システムに適用する、ひいては運用経費を低減し、より少ないリソースで行政運営を回していくという当初の目的達成も難しくなっていくのではないでしょうか。
これらの状況を解消するには、やはり一律の移行期限の撤廃、各自治体の裁量による移行期限の設定を認める、というベンダー、各自治体が求める結論となるのではないでしょうか。そのうえで、標準準拠移行後には、各自治体同士での運用のすり合わせ、自治体独自施策をどの範囲で行っていくのか、そのうえで標準仕様書の曖昧さをどこまで排除できるのか、などの議論も継続的に行っていく必要があるのだと思います。
4．EUCについて
人生の諸先輩方より、EUCについても話さんかいと厳命されたため、私見を述べさせていただきます。まず、EUCとはなんぞやですが、IT用語辞典ではこう定義されています。
EUC（End-User Computing）とは、企業などで情報システムを利用して現場で業務を行う従業員や部門（エンドユーザー、ユーザー部門）が、自らシステムやソフトウェアの開発・構築や運用・管理に携わること。
出典：「IT用語辞典」
こと公共業界においては、ほぼほぼデータ抽出定義の作成と同義だと思ってよいでしょう（私見）。賦課処理前のデータの確認、人口統計、などなど様々な用途で利用されています。私が担当する顧客では、これを易々と扱える職員様はほぼおらず、運用SEのほうで必要な定義を作成して納品する、といったような状況でした。もちろんベンダー以上にITに明るい職員様もたくさんいらっしゃいますので、その限りではない認識です。
弊社の標準準拠パッケージにもデータ抽出定義をWEBのUIから簡易的に行えるEUC機能を実装します。デジタル庁の「標準仕様書間の横並び調整方針」にも、下記のように記載されています。
ＥＵＣ機能（「地方公共団体情報システム共通機能標準仕様書」に規定するＥＵＣ機能をいう。）を利用して、データの抽出・分析・加工・出力ができること。
ＥＵＣ機能へ連携するデータ項目は「地方公共団体情報システムデータ要件・連携要件標準仕様書」の「基本データリスト（○○システム）」の規定に従うこと。（○○システムとＥＵＣ機能を一体のパッケージとして構築する場合については、基本データリストに定義されたデータ項目を利用できることを前提に、基本データリスト外のデータ項目の利用も可能とする。）
なお、機能別連携仕様にて他業務から取得しているデータ項目については、基本データリストにないデータ項目であっても、データソースの対象とし、データの型、桁数等は連携元である他業務の基本データリストの定義に従う必要がある。
基本データリストとは、デジタル庁が業務横断的に定めたデータ項目定義書のようなものです。基本的には、その設計書に定められた項目はＥＵＣ機能で抽出できるように実装する必要があります。ただし、基本データリスト外のデータ項目の利用も可能とされていますので、ここはベンダーの競争領域となると思われます。また、デジタル庁の「地方公共団体情報システム標準化基本方針」には下記の記載があります。
(2)職員向けの帳票・様式については、紙への出力を前提とするのではなく、ＥＵＣ機能等を利用して画面で確認する等のデジタル化を原則とし、真に必要なものに限定して、標準を定める。
これまで、職員向けの帳票（例えば日次の異動者を取りまとめた確認用の帳票など）を紙で管理していた場合には、ＥＵＣ機能を用いてデータで管理しなさい、ということです。
さて、ではＥＵＣを利用する場面についてですが、一番具体的にイメージできるのが都道府県からの統計提出命令への対応でしょう。都道府県ごとに定められた様式で様々な業務で、データを抽出・加工・分析し対応を行ってきました。私の担当する自治体では、県様式に合わせたデータ抽出カスタマイズ資産を作成し、県下ユーザーで共有するなどの対応を行っていました。個別にカスタマイズ資産を作成する必要があるほど、複雑なデータ抽出定義が必要だったのです。
今回、基本的には基本データリストからの抽出および加工で対応することがベターとなりますので、そういった統計関係はすべて見直しとなります。基本データリストで賄えない項目があった場合は、抽出可能とするようにＤＢ側に項目を用意しておく、あるいはEUCで抽出後にデータを加工するなどのカスタマイズが必要となります。標準仕様書には、都道府県の求める統計の詳細要件はもちろん定義されておらず、ＥＵＣ機能等により対応を図ること、などでぼやかされています。
都道府県が今回の標準化について、統計項目を基本データリストに合わせた形に見直す、などの動きを少なくとも私は観測しておりません。ただしこの動きがないと、各々の自治体が基本データリストとこれまでの様式を見比べ、対応を検討することとなります。場合によっては、ベンダーに「この項目は出せるように実装すること」という追加要望を出すことも考えられます。受け入れられない可能性もあるでしょう。つまり、都道府県としても、標準化は他人事ではないということです。
本章における、私の主張は、「都道府県が区市町村に求める統計は、都道府県が主体となり基本データリストで作成可能な形に見直すことが必須」ということです。基本データリストでまかなえない場合は、データの加工方法まで提示するのでもいいし、デジタル庁に基本データリストへの項目追加を要請する、など47都道府県が動くことで区市町村の稼働リソースを最小限にしていうことが望ましいと考えます。
標準化における広域支援はなかなか難しいというところもあるかとは思いますが、少なくとも本章で主張する統計問題については、都道府県でイニシアティブをとって進められるはずです。広域職員の琴線に触れますように！
この記事が気に入ったらサポートをしてみませんか？