自治体システム標準化・共通化を理解しよう！　「全体像の理解と疑問」

前回は、行政のDXに求められるアプリケーションアーキテクチャとクラウドプラットフォームについて簡単に整理しました。今回は具体的に、「自治体システム共通化・標準化」に求められるプラットフォームとはどのようなものかを考えていきたいと思います。ここで総務省の資料から引用するものは、以下のリンクからご参照ください。https://www.soumu.go.jp/menu_seisaku/chiho/jichitaijoho_system/index.html

まずは、この取り組みにまつわる課題と方向性について述べられています。

現状

・基幹系情報システムは利便性等の観点からカスタマイズされている

課題

1.　維持管理や制度変更による個別対応により、負担が大きい
2.　情報システムの差異により、クラウドによる共同利用が進まない
3.　住民サービスの向上の取り組みを迅速に全国へ普及できない

ゴール

・これらの問題を解決するために、法令に根拠を持つ機能要件等を定義して、財源を支援することで地方自治体システムの標準化を推進する
・自治体ごとのカスタマイズをなくすことで、共同利用や団体間調整を原則不要とし、ベンダロックインを防ぎ、事業者間のシステム更改を円滑にする

対象

・住民記録、地方税、福祉などの主要な17業務を対象とする
・医療・教育・防災等についてもGov-Cloudを利用するという同様な方向性とする

解決方法

・共通的な基盤・機能を提供する複数のクラウドサービス(IaaS / PaaS / SaaS)の利用環境であるGov-Cloudを整備する
・17業務に関する標準仕様をデジタル庁が策定する基本方針の下、各府省で作成する

時期

・2025年度（令和7年度）を目標とする

　

ざっとまとめるとこんな感じでしょうか。ここからさらに深堀りすると同時に浮かぶ疑問についても併せてまとめていきます。

標準仕様書とは？

以下のURLにAPPLICという団体が策定している地域情報プラットフォームについての概要がまとめられています。https://www.soumu.go.jp/main_content/000579848.pdf

標準仕様書とは、こちらの図のようにそれぞれの業務ユニットがどのようなものであるか、どのように連携するかについて、定義されているものになります。この標準仕様書に準拠している業務に対して、関係府省がさらにDXをを推進するための標準仕様書をデジタル庁と一緒に策定していくということのようです。そのため、APPLICが出している標準仕様書と、今回の取り組みによって出てくる標準仕様書は別物の可能性がありますが、行政のオンライン化・ワンストップ化を踏まえますと、APPLICの標準仕様書をベースに策定されるのではないかと考えています。そのため、APPLICの標準仕様書についてもきちんと中身を理解しておく必要があります（別途APPLICの標準仕様書の中身に触れる機会も執筆したいと思います）。ちなみに、業務によってこの標準仕様書が公開される時期が異なります。現時点では2022年夏に出てくるものが、最も遅い標準仕様書とされています。

既に公表されている標準仕様書に従っている業務アプリケーションは多くあり、分野に依りますが採用率にはバラつきがあるようです。準拠製品だけで2000弱あり、100社弱の企業が開発をしています。

さて、ここでいくつかの疑問が浮かびますが、このあたりについては、また別途記事を書きたいと思います。

・既にカスタマイズをしている自治体は、カスタマイズをやめなければならないのか

・2025年度末までに移行完了できるのか

・2022年度夏までに標準仕様書が出てきていない、もしくはその標準仕様書に従った業務アプリケーションがない場合に、その対象システムの更改がある場合にはどうしたら良いのか

Gov−Cloudとは?

ガバメントクラウドは、以下のスライドのように定義されています。複数のクラウドサービスを指していることから、「マルチクラウド」の形で形成されることが見てとれます。アプリケーション開発事業者が、標準仕様に従ったアプリケーションを構築する場所ということになり、地方自治体はネットワーク越しにこれらを利用することとされています。今までのようにインフラやソフトウェアを調達する形ではなく、サービスとして利用する形が想定されています。

このような形にすることで得られるメリットが述べられています。
1. 共同利用やベンダーロックインを防ぐことでコスト削減
2. 迅速な構築と拡張を実現し、住民サービスを早く届けられるようにする
3. 住民サービスにてワンスオンリーが容易になる
4. セキュリティ・運用監視をガバメントクラウド側でおこなうことが可能

また、サービス利用になることで契約形態がどのように変化するでしょうか。現在のイメージを仮定としてまとめます。国がクラウドサービス提供事業者と契約しクラウドインフラを用意し、アプリケーション開発事業者はそれを利用して基幹システムを構築します。地方自治体はアプリケーション開発事業者と契約を結ぶことで、基幹システムを利用するという形態を想定しているようです。

そもそもガバメントクラウドの定義とは何なのかについては、以下にまとめられています。要件としては以下が定められています。
・ISMAP準拠
・日本国内法適用
・17業務以外とは専用回線で結ぶ
・インターネットからの接続はセキュリティクラウド等の対策を行う
・東西2センターを構築する等、高い可用性を確保する

Gov-Cloudについても、多くの疑問が浮かんできます。こちらも次回以降で１つずつ深堀りしていきたいと思います。

・住民サービスの制度改正などについて、どれくらいの頻度を想定しているか（どんなアプリケーションアーキテクチャにするかを決める判断基準となる）

・ワンスオンリーを提供するのは、ガバメントクラウドではなく、標準仕様書に準拠されたアプリケーションではないのか

・国がクラウド事業者と契約をして、ガバメントクラウドとして準備をしておく想定となっているが、クラウド事業者の数が多く、どのクラウドが採用されるかわからない中で、弾力性のある需要に対して予算を確保し、準備しておくのか

・ガバメントクラウド上の17業務の基幹システムとそれ以外のシステムとは、専用線が想定されているが、LGWANを利用することはできないのか

・東西2センター構築によるコスト増大について、どのように考えていけばよいか

・ISMAP準拠のIaaSを利用して構築されたSaaSはISMAP準拠する必要があるか

・17業務をすべて持っているオールインワンパッケージベンダーではない、組み合わせ前提のアプリケーション開発事業者間で選択されたガバメントクラウドが異なる場合には、その間のネットワーク及びセキュリティについてどのように考えればよいか

以上のように、まだまだ現在の検討資料から読み取れる範囲だけでは、判断に迷う部分があるかと思います。そのため、先行事業自治体を募り、様々な項目及びケースを検証していく計画があるようです。そこにもある程度の仮説を持って臨む必要がありますので、今後はこれらの疑問を仮説に基づいて整理していきたいと思います。