見出し画像

自治体業務システム標準化キソのキソ

自治体業務システム標準化は対象となる業務も広く関わる自治体職員は非常に多くなる。全員専門家になれと言うのも無理な話なので最低限必要な理解を整理してみた。なお用語についてはこちらに整理してある。
わかりやすさを最優先にしたのであえて雑な説明の部分もある。どうぞご容赦願いたい。

なぜ標準化するのか

全ての自治体がスマート自治体になるため。
標準化で自治体の足並みを揃える。

総務省の「自治体戦略2040構想研究会」第二次報告においてスマート自治体への転換が必須と宣言された。人口減少に伴い2040年には職員数半減が確実。この状況を乗り切るにはAIなどの最新技術を使いこなす自治体(これをスマート自治体と呼んでいる)になるしかないからだ。
スマート化と業務システムとの関連は深く、これがバラバラではスマート自治体導入支援が難しい。さらに、デジタル庁が全国的なサービスを立ち上げるにも自治体ごとに対応がバラバラになってしまう。そこで業務システムを標準化して自治体の足並みを揃えることになった。

法律上の義務

標準化法で2026年度から標準仕様に適合したシステムしか利用できなくなる。
システム導入自体が義務ではない。

標準化は「地方公共団体情報システムの標準化に関する法律(令和三年法律第四十号)」(俗にいう標準化法)で自治体の義務とされている。といってもシステムの導入や利用が義務付けられているのではない。

第八条 地方公共団体情報システムは、標準化基準に適合するものでなければならない。

地方公共団体情報システムの標準化に関する法律

とあるように、標準仕様(法律上は標準化基準という)に適合したシステムしか使ってはいけないという規制だ。期限は2026年度初めから。

標準化の対象とは

標準化されるのは標準化法で定められた対象事務だけ。
といっても、主要な事務はだいたい対象。
自治体が実施している事務全てが標準化の対象というわけではない。標準化の対象事務は標準化法(に基づく政省令)で定められたものだけ。俗に20業務とか言われているもの。普通”業務”と言うけど、法律上は”事務”と呼ばれている。住民対象の主要な事務は大抵入っている。それ以外の事務で使う情報システムは自由。

なにが決まっているのか

機能と帳票が決まっている。
業務フロー(手順)は参考扱い。

具体的に決まっているのは業務システムが持つ機能と出力できる帳票。標準化の対象となる事務ごとに使って良い業務システムが備える機能と帳票がそれぞれ”機能要件”、”帳票要件”として定められている。ここで決まっているもの以外の機能や帳票を持つことは原則禁止。
業務の流れ、いわゆる業務フローについては標準化されていない。とはいえ、機能を標準化する上でだいたい想定する業務フローはある。そこで、これは参考として例示されている。将来的には例示のフローに統一していきたい。

標準オプション機能というのもある

自治体ごとの違いは標準オプション機能が吸収する。
標準オプション機能が実装されているかはパッケージ次第。

機能が標準化されるので自治体ごとの違いはなくなる。とは言え、例えば市では実施するが町村では県が実施するので対応不要な機能など、自治体ごとの違いは実際には存在する。完全に統一しようのない部分については”標準オプション機能”というカテゴリが作られている。実装してもしなくても良い機能である。
ただし、この標準オプション機能を実装するかは事業者の判断となる。自治体からすると、使いたい標準オプション機能があるならそれを実装しているパッケージ製品を選択しなければならないとなる。

ガバメントクラウド

ガバメントクラウドの利用は努力義務
従来、情報システムを持つにはサーバなどのハードウエアをまず準備して、ネットワークを構築し、そこにソフトウエアをセットアップしていた。クラウドの仕組みではハードウエア、ネットワークに相当するコンピュータ資源は世界中に展開されるデータセンターに分散してる。この分散した資源を一つの巨大なコンピュータのようにみなす。そして、そこから必要な資源を切り出して、顧客にあたかも自分専用のハードウエアがあるように提供する。
さまざまな利点があるクラウドだが、外国のデータセンターにあると国内法が通用しないなど行政が活用するには契約上の注意点も多い。
中央官庁もクラウド化を推進しているが、このような契約上の複雑さに各省庁が対応するのも無駄なので、デジタル庁で一括して契約し、各省庁に資源を払い出す仕組みを導入しようとしている。これに自治体も乗っかったものがガバメントクラウドだ。
デジタル庁がクラウド事業者と一括して契約を行い、自治体に必要な資源を払い出す。結果、自治体はクラウド事業者との複雑な契約から解放され、契約先はデジタル庁に一本化される。
このガバメントクラウドの利用が標準化における第一選択肢とされている。ただし、標準化法はガバメントクラウドの利用を強制していない。あくまで努力義務であり、他の環境を利用することも許されている。

単独利用方式と共同利用方式

単独利用方式はプライベートクラウド。
共同利用方式はSaaS
共同利用方式が推奨されている。

自治体がガバメントクラウドを利用するには単独利用方式と共同利用方式の二つの方式が準備されている。
単独利用方式は従来のプライベートクラウドに相当する。自治体がデジタル庁から払い出されたクラウド環境を全面的に管理し、事業者にそこへシステム実装を依頼する。環境を持つのは自治体。事業者はそこにシステムを載せる。
共同利用方式は実質的なSaaSである。事業者がガバメントクラウド上にシステムを実装し、自治体はそれをサービスとして利用する。クラウド環境の管理は事業者が行う。自治体はあくまでサービス利用者となる。
単独利用方式は自治体が全面的にクラウド環境をコントロールできる。そのかわりクラウド環境の管理者が必要となる。共同利用方式は管理を事業者に任せられるので自治体の手間は削減できる。そのかわりクラウド環境のコントロールに限界がある。
自治体業務システム標準化は職員数半減の未来に対応するためだ。よって職員の手間が削減される共同利用方式が推奨されている。

で、何をすれば良いのか

一言で言えばシステム更改作業。
従来と違い、カスタマイズ禁止の制約がある。

標準化対応とは何をするのか。一言で言えばシステム更改作業である。現状の業務システムから標準仕様(標準化基準)に適合した新しい業務システムに乗り換える。古くなったシステムを更改するのと本質的には何も変わらない。
ただ、次の二点で従来と異なっている。

  • カスタマイズは禁止である

  • 超短期間の実施である

従来のシステム調達では既存の事務処理手順ありきで必要な機能を考え、それに近い機能を持つパッケージを選定していた。どうしても合わない部分についてはカスタマイズで調整していた。
標準化後はカスタマイズは原則禁止である。そもそもパッケージごとの機能差もなくなる。機能は選定基準にならず、使いやすさや処理性能、事業者のサポート体制などが評価基準となる。
カスタマイズでパッケージ側を合わせるのではなく、決まった機能で実現できるよう、事務処理手順側で合わせなければならない。
とはいえ、従来もパッケージの機能や考え方に合わせて事務処理手順側を変えるいわゆるBPRは実施されてきた。その意味では今までのシステム更改作業と本質的に違うところはない。
最も異なるのは超短期間の実施である点だ。全庁的なシステム更改となると数年がかりのプロジェクトとなることもある。しかし、今回は明日初めても三年しか時間がない。残念ながら多くの事業者はまだ標準適合パッケージを開発中である。実際に導入に使える時間は二年か最悪一年となる。しかも、全国の自治体が一斉にシステム更改を行う。これは日本の行政コンピュータシステム史において初めての体験である。
結果、パッケージの選定はいかに期限に間に合わせるかを最優先課題として考えねばならない。機能が選定基準にならず、大きな差がなくなっていることを考えると既存事業者を第一候補とせざるを得ないだろう。

結局標準化とは

極論すれば、クラウドベースの新しいシステムへの更新作業である。
ただ、更新先のシステムが持つ能力は標準化基準によって制約されている。その制約の範囲で事務を回す工夫をしつつのシステム更新である点が従来と異なっている。しかも与えられた時間は極めて少ない。


続編「自治体業務システム標準化キソ(独自施策編)」はこちら


この記事が気に入ったらサポートをしてみませんか?