自治体システム標準化とガバメントクラウドにより転換する自治体ITビジネス環境
土地がないとこに家は建たずということを伝えておきます。1700以上の自治体システムを1年で移行するとは地獄絵図にしか思えない・・。ガバメントクラウド上でデジタル庁が共通基盤・機能などをAPIで提供するなどして、開発工数減、イニシャル＆ランニング減、○野源！？
・デジタル庁と自治体の関わり：割愛
・自治体システムの標準化の法律・目的
本日の本題である「自治体システムの標準化」についてご説明します。まずは、昨年9月に関係する法律が施行されています（図表3）。条文には、「自治体システムは、標準化基準に適合するものでなければならない」とあり、標準仕様書に準拠することが必須となっています（講演資料17～18頁）。
一方で、クラウド・コンピューティング・サービス関連技術の活用については、「～努めるものとする」とあり、これは努力規定ですが、次の理由から必須度合いの高い状況になっています。これらについて自治体が対応するための補助金（令和2年度第3次補正、10分の10補助）が用意されていますが、その内容はガバメントクラウドに移行するための準備経費という側面が強くなっています。つまり、標準仕様書に対応したソフトはガバメントクラウド上で提供されることが想定されるため、標準仕様書対応とガバメントクラウド利用は不可分に近いということです。
・標準化の対象事務・スケジュール
標準化対象の事務は当初17ありましたが、その後3つ（印鑑登録、戸籍、戸籍附票）追加されて現在は20あります（図表4）。事務のそれぞれに個々の情報システムが存在するわけではなく、例えば税関係は全てひとつの税務システムで処理するなど、いくつかのまとまりがあります。これらを処理する情報システムは、大規模な住民データを含み、「基幹システム」や「住民情報系システム」、あるいは「マイナンバー系システム」という分類で呼ばれています。これらの事務の大部分は、国の法令に基づいたものなので、標準化が図りやすいという側面があります。
一方で、「印鑑登録」のように自治体の条例で行われている事務もあります。これは、当初標準化対象に含まれていませんでしたが、実態として住民基本台帳業務を行う住民記録システムに付随して導入される（住民記録システムの機能のひとつ）ケースが多いため、同時に標準化しておいた方が良いだろうという判断のもとに追加されました。
標準仕様書は、それぞれの制度を所管している府省庁の部署で作成しており、8つの府省庁と数十の課室に跨っています（講演資料34頁）。また、システム間のデータ連携など共通的な仕様はデジタル庁にて作成しています。それぞれ制度所管が検討会を立ち上げ、そこに自治体職員や自治体関係の全国団体等が構成員として参加しています。スケジュールは、標準仕様書の第1グループが昨年（2021年）の9月に発出されたところで、第2グループが今年（2022年）の8～9月くらいに発出され、全部揃う予定です。標準仕様書が出た後、各システムベンダーは標準仕様書に準拠するためにシステムを再構築して、ガバメントクラウドに搭載します。自治体は、2025年末までにその環境に移行するというスケジュールです（図表5）。
・標準仕様書の検討体制・検討方法
事務ごとに制度所管府省庁にて検討されている仕様とは別に、デジタル庁にて検討しているシステム間に共通する仕様があります。そのひとつはデータ要件・連携要件です。従来、自治体基幹系システムを繋ぐデータ要件・連携要件としては、地域情報プラットフォーム・中間標準レイアウトというものがありました。これは、自治体に情報システムを提供するベンダー等約120団体が参加した一般財団法人全国地域情報化推進協会（APPLIC）が定めたものです。地域情報プラットフォームは、システム間を結ぶ際のAPIで、中間標準レイアウトはシステム移行の際のデータ形式です。標準仕様書では、これらデータ項目に足りていない部分を拡充した上で、それを各仕様書に、共通の非機能要件としてプラスすることにより、システム間の連携についても標準化を図っていきます（図表8）
標準仕様が2022年夏で、そこから分析し「地域情報プラットフォーム」や「中間標準レイアウト」をキャッチアップするということは、かなり大変な気がする。デジタル庁がAPIをで出せばコストダウンかと思いますが、要は自治体システムを生業にしているベンダーが同じものを作る必要はない。
三木： APIに類するところとして、まずこのAPIまでたどり着く半歩先の世界としては、地域情報プラットフォームのベースでルールが統一化されることになるので、そこで統一のデータ形式で受け渡すことができます。ただし今のところ、自治体の基幹システム間のデータ連携は想定されていますが、Web上にある民間企業のシステムから自治体の基幹システムにAPIを叩いて情報を取得するというところまでは至っていません。
三木：今、ちょうど都市OSと地域情報プラットフォームとの連携についての調査業務を実施しているところだと思います。まず、制度的には、都市OSは、性質上都市インフラや自然環境情報が多く、個人情報はあまり含みません。一方で、地域情報プラットフォームで扱っている個人情報には世帯や税、社会保障など機微な個人情報が多く含まれます。また、技術的には、現在複数ある都市OS間で異なる形式であってもコンバーターによってデータ連携をすることを目指しているようです。
須藤：もう一つ、こういうふうに、この図（講演資料53頁）で介護保険とか国保とかがありますが、大きな上流のシステムというのは大手のベンダーのようなクラウドが強いところですけれども、例えば、北日本コンピューターサービス株式会社が強いのは生活保護ですね。それから、介護保険が強いのはカナミックとかが有名です。特定分野に特化して強みを発揮しているベンダーはデータ連携にうまく乗っていけるのでしょうか。
三木：システム規模とそこで活動するベンダーの規模は相関関係にあると言えます。大規模システムである、住民記録や税、国民健康保険といった分野は全国企業の大手ベンダーの割合が高く、一方で中小規模システムである福祉や子ども・子育てといったものになると中小規模のベンダーや地域ベンダーが増えてくる傾向かと思います。中小規模ベンダーについては、理想像としては、従来のようにオンプレミス型で体制を組んで各ユーザー団体に張り付けなくても、ソフトウェアだけ優秀なものを創れば、オンラインで全国展開しやすいという側面があります。一方で、中小規模ベンダーの技術やビジネスモデルからするとクラウド型と合いづらい面もあるかと思います。
三木：例えば、福祉にしても子育てにしても、個々の自治体の条例で提供している部分が大きく、カスタマイズ率が高くなるので、同じソフトウェアの全国一律提供がやりづらいという側面があります。また、ビジネスモデルとしては、制度改正のたびにカスタマイズ部分の改修を行うことにより提供体制の維持や継続的な売り上げを確保している現状もあるようです。実際に、既にそのようなベンダーから撤退通告を受けたという話が自治体から聞こえてきます。
須藤：なるほど。今、厚生労働省系は本当に大変ですよね。
・共通仕様とワンストップ化の検討
まだ標準仕様書への反映は十分進んでいないところですが、2.0版に更新された住民記録システムの標準仕様書には、「転入・転出のワンストップ」が追加されています。このワンストップサービスは、引越しの際の手続きを簡略化するものです（図表9）。住民の方が転出する際に、マイナポータルを使ってオンラインで申請します。そうすると、転出届はオンラインで転出地の自治体に提出されるので、転出地の役所を訪問する必要はありません。同時に転入先の役所には転入予約が送付されるので、転入地のほうでは転入手続きの事前準備等を行います。できることは事前に準備しておいて、実際その方が転入地の役所にやってきた時に迅速に処理できるという仕組みです。具体的には、予約窓口による待ち時間の減少、申請書への情報の事前印刷による書類記入の負担低減、転入者のステータスに応じた制度案内の準備等が考えられます。
このOSS（ワンストップサービス）続くようですね。
満永：もう一点よろしいですか。先ほど、転入出の予約制度があるという話をされていたと思うのですが、これは、どこを経由していくんでしょうか。それぞれの自治体間で、1対1でやるのですか。どこかゲートウェイみたいなのがあって通過していく感じですか。
三木：まず、オンライン上の申請窓口としてはマイナポータルです。国のシステムを通じてということになります。マイナポータルと全自治体はつながっていますので、マイナポータルで届け出が出されたものが、転出地と転入地両方の自治体に送られるという仕組みです。
満永：なるほど、マイナポータル経由でA市からB市にデータがいく。
三木：個人情報の部分は住基ネットに連携します。マイナポータルからの処理をトリガーとして、住基ネットのほうで転出証明書情報が、転出地から転入地のほうに受け渡される仕組みです。
・ガバメントクラウドの事業要件
自治体向けの場合は、この基盤上に複数の民間企業が標準仕様書に準拠したアプリを搭載します。自治体は、ガバメントクラウド上の任意のアプリを選択してオンラインで利用することができます。つまり、標準仕様書に適合したアプリはひとつではなく、複数の中から選ぶことができます。つまり、自治体から見た場合は、SaaS（ Software as a Service）型サービスのように見えます。
ガバメントクラウドに搭載することができるシステムは、標準仕様書対象の20事務のシステムに加えて、これらと密接に連携するものも含まれます（講演資料70頁）。例えば、町や村といった小規模団体は、システムを個別に調達しなくて、オールインワンパッケージという統合化されたシステムで調達しているため、20事務とそれ以外という分割ができません。
ガバメントクラウドのセキュリティ要件として重要なのは、「政府情報システムのためのセキュリティ評価制度」（ISMAP: Information system Security Management and Assessment Program）に登録されているサービスであることです。また、この制度では、毎年監査を受けることが義務付けられています
2022年6月3日時点ですが何もない。ということで、冒頭に「土地のないとこ家建たず」ですね。
・先行事業用環境の調達：割愛
・回線の可能性：割愛
・地域IT事業への影響について
三木：ガバメントクラウドは、ナショナルクラウドなので、地域のデータセンターや地域のコミュニティーネットワークという広域事業は、競合相手となるので、ビジネス領域が重なる部分については影響を受けると思います。
地域のデータセンターというのは県とか市町村といった自治体と、地域の有力企業、電力会社などの有力企業が共同出資でつくった第三セクタータイプが多く見られ、それぞれの県内では最大規模のIT企業です。そこが事業の転換を求められるということは、少なからず自治体の業務にも影響が出てくる可能性があります。小規模な団体は、情報部門に職員が一人しかいない状況のところも多く、中長期計画や制度対応、運用など広範囲な業務を地域のデータセンターに依存しています。
須藤：大阪府がDX、新しいクラウドを、ベンダーと大阪府とで組んで作る検討をしている。どう考えたらよいでしょうね。
三木：大規模団体の思考として、ガバメントクラウドのみに依存せず、自ら調達したクラウドと合わせてマルチクラウド運用にして、いずれかの環境で障害が発生した際のリスク回避を図ることは考えられるのではと思います（図表13）。
・補助金、移行作業、体制について：割愛
・ベンダーのビジネスモデル転換
三木：昨年よりガバメントクラウドの実証環境を使った先行事業という取り組みが始まっています。ここでは、神戸市から京都府笠置町まで規模の異なる8団体が取り組んでいます（講演資料106頁）。ただし、現状標準仕様書に対応したアプリが無いため、現行のソフトをIaaS環境に上げるという実証内容が多いと考えています。
三木：今後、テンプレートやアカウント振り出しなどガバメントクラウドの利用方法が固まってくれば、ベンダーもクラウドをPaaS型で使うサービスモデルの検討に入れると思います。ガバメントクラウドで採用されている、AWSにしてもGCPにしてもさまざまなツールやマネージドサービス提供されていますが、まずそのツール群の中で、どれとどれがメニューとして採用可能なのか。そして、恐らくセキュリティや管理機能は、ガバメントクラウド利用アプリの中で統一しなければならない要素なので、恐らくデジタル庁が設定要件を示すことになると思います。
主要ベンダーは2022年度に本格対応を始めるようです。今年の夏には標準仕様書が全部揃い、ガバメントクラウドの利用環境や利用できる回線についてもより明確化されると思います。このタイミングで、今のパッケージソフトを標準仕様書とガバメントクラウドに対応したものに作り替えていきます。
そして、ベンダーのビジネスモデルについても転換が迫られると考えています。これまで、人工数で課金する受託型開発のビジネスモデルでしたが、それは同じパッケージベースでも個々の自治体にてカスタマイズがあり仕様が異なることが原因でした。それが標準仕様書を国が示すことにより、揃ってしまうわけです。また、実装する環境はオンプレミスではなくガバメントクラウドになります。
三木：それでは新しい姿とはどのようなイメージなのでしょうか。従来のビジネスでは、個々に受注した環境ごとにパッケージソフトをカスタマイズしたり、独自構築したりしているものがたくさんあります（図表17）。300団体受注していれば、300種類のソフトウェアがあるので、運用する部隊もそれぞれに張り付け、制度改正に伴うシステム改修も個々に行わなければいけない。これをクラウドベースの環境に移行した場合、数百種類あったシステムが整理統合されて、数種類のタイプに集約されます。あとは自治体ごとにセグメントを切り、アカウントを振り出して使ってもらう。
「300団体受注していれば、300種類のソフトウェアがある」というのは嘘ですね。自治体クラウドしているところもあるので。
・自治体セキュリティ思想の転換
三木：標準化・ガバメントクラウドでのセキュリティについては、ガバメントクラウドや回線などの要件が固まるなかで検討されていくと思います。現状、自治体のセキュリティは、総務省の発出している自治体セキュリティポリシーガイドラインが方針を定めています。取り扱う情報の重要度に応じてネットワークを三分割する「三層の対策」という境界型防御の思想です。物理的にネットワークが分かれているため利用者（自治体職員）にとって認識しやすく、自治体情報部門による運用もある程度シンプルです（図表18）。
ガバメントクラウドの実証環境で調達されているAWSやGCPは、そのままではインターネットに繋がったパブリッククラウドであり、「三層の対策」では重要な情報資産を置くことが憚られます。それでは、境界型防御をやめて新たなセキュリティ手法に移行するのでしょうか。
・クラウド時代の新たなサービス
三木：確かに、従来のオンプレミス型のシステム導入だと、どうしても利用者の少ない団体は1件当たりのコストが大きくなってしまいます。例えば、証明書のコンビニ交付システムを導入するために約2000万円かかりますが、団体規模が小さくなってもそれほど金額は下がりません。一方で、団体規模が小さくなり利用件数が小さくなると、1件当たりのコストが大きくなります。コンビニ交付が便利だからと言って、1通当たりの発行コストが数万円とかになれば、税金を原資とする行政機関としては導入を躊躇しますよね。
導入費2000万って、機器代？？？？