- Review
- デジタル革命、デジタル化による社会構造転換
自治体システム標準化とガバメントクラウドにより転換する自治体ITビジネス環境＜前編＞「デジタル庁発足と自治体システムの標準化」
April 27, 2022
R-2022-003-1
※本稿は、2022年3月4日に開催された「日本におけるDXの社会的インパクトに関する研究プログラム」研究会で講演された内容の一部です（後編はこちら）
三木浩平（総務省デジタル統括アドバイザー）
|
・デジタル庁と自治体の関わり |
資料はこちら
松崎：早速では、お願いいたします。
三木：まず最初に、講演資料の表紙に「私の私見や解説を含みます」と書いている理由について。自治体システム標準化とガバメントクラウドは、現在8つの府省庁、そして数十の課室にまたがって検討されており、それらから集めた情報を私が統合したのがこの資料ですが、公表されている情報量が不足している部分については、私が補足で加えたページが幾つかあります。補足で加えたページには、右上のところに「解説」・「考察」と表示してあります。補足で作成したページについては、現状想定されるいくつかの可能性について言及しています。
自治体システムの標準化については、3年前の経済財政諮問会議において、府省庁全体でという方針になりました。これは大きな転換点でした。これまで自治体システムの標準化の手法としては「標準ソフト」といって、国がソフトウェア（プログラム）を作り、それを自治体に配布するという方式が2000年頃からの主流でした。それを方針転換して、標準ソフトを作るのではなくて「標準仕様書」を提示する方法に変わりました。自治体が標準仕様書を使って調達を行うことにより、全国的に自治体システムの標準化を図れるということです。ただし、自治体の基幹系システムについての標準仕様書は、過去にほとんど例がなく大きなチャレンジといえます。
デジタル庁と自治体の関わり
昨年、デジタル改革関連の6法案（講演資料4頁）が成立して、そのなかに自治体のシステムの標準化を定める法律も含まれています（「地方公共団体情報システムの標準化に関する法律」）。あと自治体のシステム環境に関わる重要なものとしては、デジタル庁設置法もできました。これまでの国の役割とデジタル庁が違うところは、デジタル庁の業務に「システム整備」が含まれており、自治体が利用するシステムの一部についても国が整備することになります（図表1）。つまり、これまで国は自治体のシステムについては、ガイドラインを作るというレベルに留まっていたのですが、デジタル庁設置後は、システムに関わるインフラを国が整備していくということになります。これが、いわゆるガバメントクラウドです。
＜図表1（講演資料11頁）＞
次は、自治体に関わるデジタル庁の組織についてです。組織図の中に、複数のグループが並んでいますが、これらが他の府省庁における「局」に相当する組織です。グループ長というのは局長と同格の統括官クラスであり、次長は審議官クラスです。グループの中の、「アーキテクチャー」、「データ」等はそれぞれチームと呼ばれ、他の府省庁における課室に相当します。各チームは、課長クラスである参事官や、室長クラスである企画官がリーダーとしてとして率いています。
図中（図表2）に赤で抽出したところが、自治体に関係が深いチームです。デジタル社会共通機能グループに地方業務システム基盤というチームがあり、自治体システム標準化を担当、そしてクラウドチームはガバメントクラウドを担当しています。
＜図表2（講演資料12頁）＞
自治体システムの標準化の法律・目的
本日の本題である「自治体システムの標準化」についてご説明します。まずは、昨年9月に関係する法律が施行されています（図表3）。条文には、「自治体システムは、標準化基準に適合するものでなければならない」とあり、標準仕様書に準拠することが必須となっています（講演資料17～18頁）。
一方で、クラウド・コンピューティング・サービス関連技術の活用については、「～努めるものとする」とあり、これは努力規定ですが、次の理由から必須度合いの高い状況になっています。これらについて自治体が対応するための補助金（令和2年度第3次補正、10分の10補助）が用意されていますが、その内容はガバメントクラウドに移行するための準備経費という側面が強くなっています。つまり、標準仕様書に対応したソフトはガバメントクラウド上で提供されることが想定されるため、標準仕様書対応とガバメントクラウド利用は不可分に近いということです。
＜図表3（講演資料16頁）＞
自治体情報システムの標準化の目的には、大きく2つがあります。まず1番目は「機能の標準化による住民サービスの共通化とコスト削減」です。国民は、どこに引っ越しをしてもどこの街に住んでも同じようにサービスを受けることができます。コスト削減は、仕様を共通化することによる、運用やシステム改修の効率化により期待されます（3割程度のコスト削減を目標としている）。2番目は「新たな機能の提供による住民サービスの向上」です。システムの仕様が標準化されることにより、システム間をつなぐワンストップサービスや外部システムと連携するオンライン申請がやりやすくなります。標準仕様書のうち、現在すでに発出されているものは半数程度あり、ひとつ（住民記録システム）を除いて、全て初版（1.0版）ですが、初版では主に最初の目的（住民サービスの共通化とコスト削減）の要素が入っています。一方、2番目の目的は、標準仕様書が改定される（2.0版以降）度に追加されることになると想定しています。例えば、住民記録システムについては、2.0版に更新された際に「転出入のワンストップサービス」の要素が盛り込まれました。
標準化の対象事務・スケジュール
標準化対象の事務は当初17ありましたが、その後3つ（印鑑登録、戸籍、戸籍附票）追加されて現在は20あります（図表4）。事務のそれぞれに個々の情報システムが存在するわけではなく、例えば税関係は全てひとつの税務システムで処理するなど、いくつかのまとまりがあります。これらを処理する情報システムは、大規模な住民データを含み、「基幹システム」や「住民情報系システム」、あるいは「マイナンバー系システム」という分類で呼ばれています。これらの事務の大部分は、国の法令に基づいたものなので、標準化が図りやすいという側面があります。
一方で、「印鑑登録」のように自治体の条例で行われている事務もあります。これは、当初標準化対象に含まれていませんでしたが、実態として住民基本台帳業務を行う住民記録システムに付随して導入される（住民記録システムの機能のひとつ）ケースが多いため、同時に標準化しておいた方が良いだろうという判断のもとに追加されました。
＜図表4（講演資料30頁）＞
標準仕様書は、それぞれの制度を所管している府省庁の部署で作成しており、8つの府省庁と数十の課室に跨っています（講演資料34頁）。また、システム間のデータ連携など共通的な仕様はデジタル庁にて作成しています。それぞれ制度所管が検討会を立ち上げ、そこに自治体職員や自治体関係の全国団体等が構成員として参加しています。スケジュールは、標準仕様書の第1グループが昨年（2021年）の9月に発出されたところで、第2グループが今年（2022年）の8～9月くらいに発出され、全部揃う予定です。標準仕様書が出た後、各システムベンダーは標準仕様書に準拠するためにシステムを再構築して、ガバメントクラウドに搭載します。自治体は、2025年末までにその環境に移行するというスケジュールです（図表5）。
＜図表5（講演資料33頁）＞
標準仕様書の検討体制・検討方法
総務省が担当する検討会を例にとると、親会が3つあり、その下にワーキングチームや分科会といった実務ベースの会議体があります（図表6）。検討会の構成員としては、政令指定都市から中核市、小規模団体まで特徴の異なる団体から参加いただいている上、知事会や市長会といった自治体の全国団体からも参加いただいています（講演資料36頁）。そして、準構成員として、それぞれのシステムでシェアの高い主要なベンダーから参加いただいています。また、一般財団法人全国地域情報化推進協会（APPLIC）等の自治体にシステムを提供するベンダーの協議会とも意見交換しながら進めています。
＜図表6（講演資料35頁）＞
標準仕様書の作り方については、現状では還元法に近い形が採られています。普及している主要なパッケージソフト群のノンカスタマイズ版の差分を切り落とした、つまり最大公約数的なものがそのイメージです（講演資料44頁）。
一方で、現行のパッケージから大きく変更される要素もあります。各標準仕様書のデータ要件に「文字情報基盤文字の活用」（図表7）とありますが、これはフォントです。具体的には、これまで各システムは、それぞれベンダー固有の文字を使っていました。標準仕様書では、それをやめて、IPA（独立行政法人 情報処理推進機構）が作った文字基盤に共通化します（一般社団法人文字情報技術促進協議会から提供）。文字基盤は6万字強あり、そこには、戸籍統一文字も住基統一文字も含まれています（講演資料46頁）。
＜図表7（講演資料45頁）＞
共通仕様とワンストップ化の検討
事務ごとに制度所管府省庁にて検討されている仕様とは別に、デジタル庁にて検討しているシステム間に共通する仕様があります。そのひとつはデータ要件・連携要件です。従来、自治体基幹系システムを繋ぐデータ要件・連携要件としては、地域情報プラットフォーム・中間標準レイアウトというものがありました。これは、自治体に情報システムを提供するベンダー等約120団体が参加した一般財団法人全国地域情報化推進協会（APPLIC）が定めたものです。地域情報プラットフォームは、システム間を結ぶ際のAPIで、中間標準レイアウトはシステム移行の際のデータ形式です。標準仕様書では、これらデータ項目に足りていない部分を拡充した上で、それを各仕様書に、共通の非機能要件としてプラスすることにより、システム間の連携についても標準化を図っていきます（図表8）。
＜図表8（講演資料56頁）＞
目的のひとつである「新たな機能の提供による住民サービスの向上」については、まだ標準仕様書への反映は十分進んでいないところですが、2.0版に更新された住民記録システムの標準仕様書には、「転入・転出のワンストップ」が追加されています。このワンストップサービスは、引越しの際の手続きを簡略化するものです（図表9）。住民の方が転出する際に、マイナポータルを使ってオンラインで申請します。そうすると、転出届はオンラインで転出地の自治体に提出されるので、転出地の役所を訪問する必要はありません。同時に転入先の役所には転入予約が送付されるので、転入地のほうでは転入手続きの事前準備等を行います。できることは事前に準備しておいて、実際その方が転入地の役所にやってきた時に迅速に処理できるという仕組みです。具体的には、予約窓口による待ち時間の減少、申請書への情報の事前印刷による書類記入の負担低減、転入者のステータスに応じた制度案内の準備等が考えられます。
＜図表9（講演資料59頁）＞
質疑応答（前編）
満永：セキュリティーについても気になるのですが、設計がちょっとまだ分からないので、基本的なところかと言われてしまうかもしれないですが、そのクラウドにいく、つまり国が持っているクラウドがあって、そこにつなぐアプリを今標準化しているということですが、直接つないだらまずいのでしょうか。つまり、もうアカウントをばらまいてしまうというような方法です。そうすると、比較的国が全部名簿を持ってしまったらまずいというような、自治行政の話が出てくるのでしょうか。
三木：法律の建て付け的には、そうなります。これまでは、国は法律を作りますが、その処理をするのにシステムを使うのか、システムを使う場合もどのようなシステムを使うのかを選択するのは、自治体に委ねられてきたわけです。それが非効率であり、自治体間の横の連携を阻害しているということが最近課題として指摘されて、ようやく国が仕様の標準化を進めようということになったのです。現状についての課題意識は皆さんが共有していて、それを変えようとしているというのが、まずひとつの流れです。
次に、それでは国が全国共通の1個のシステムを作り自治体に提供するのかという課題があります。これは、20年前に住基ネットを開始した際に議論となり、その議論はマイナンバー制度においても踏襲されました。すなわち、国はデータを流通させるプラットフォームは作ったものの、データ自体は各自治体に帰属しており、お互いの照会要求に対して個別に開示しているという仕組みを取っています。ですから、今回ガバメントクラウドにおいても過去の議論に配慮した上で、データの持ち方や流通の仕方を設定する必要があると考えます。
満永：もう一点よろしいですか。先ほど、転入出の予約制度があるという話をされていたと思うのですが、これは、どこを経由していくんでしょうか。それぞれの自治体間で、1対1でやるのですか。どこかゲートウェイみたいなのがあって通過していく感じですか。
三木：まず、オンライン上の申請窓口としてはマイナポータルです。国のシステムを通じてということになります。マイナポータルと全自治体はつながっていますので、マイナポータルで届け出が出されたものが、転出地と転入地両方の自治体に送られるという仕組みです。
満永：なるほど、マイナポータル経由でA市からB市にデータがいく。
三木：個人情報の部分は住基ネットに連携します。マイナポータルからの処理をトリガーとして、住基ネットのほうで転出証明書情報が、転出地から転入地のほうに受け渡される仕組みです。
満永：分かりました。先ほど三木さんも言及されていましたし、須藤先生がお話されたAPI化というのが、ある種ベストプラクティスというか、標準化してデータで連携し合ってやると、そこのベンダーニュートラルも達成できるようにも思えますし、ある程度、例えば決済とかは何とかペイとか、ものすごい勢いで連携したAPI決済が行われていますけれども、ああいったものに近付けるとシステム的に言うときれいな感じになるのかなと思うのですが、過去の住基ネット等の経緯があるから、まだまだそこと向き合っていく感じなのですか。
三木： APIに類するところとして、まずこのAPIまでたどり着く半歩先の世界としては、地域情報プラットフォームのベースでルールが統一化されることになるので、そこで統一のデータ形式で受け渡すことができます。ただし今のところ、自治体の基幹システム間のデータ連携は想定されていますが、Web上にある民間企業のシステムから自治体の基幹システムにAPIを叩いて情報を取得するというところまでは至っていません。
満永：ありがとうございます。
須藤：今後、都市OSの展開があると、地域情報プラットフォームの標準仕様との関係は、今後どうなるのですか。
三木：今、ちょうど都市OSと地域情報プラットフォームとの連携についての調査業務を実施しているところだと思います。まず、制度的には、都市OSは、性質上都市インフラや自然環境情報が多く、個人情報はあまり含みません。一方で、地域情報プラットフォームで扱っている個人情報には世帯や税、社会保障など機微な個人情報が多く含まれます。また、技術的には、現在複数ある都市OS間で異なる形式であってもコンバーターによってデータ連携をすることを目指しているようです。
須藤：ベンダーがあんまり協力的じゃないように思えます。そこら辺は、何とか協力してもらえそうなのですか。
三木：データ連携やデータ標準化に関するベンダーの姿勢には企業間で差があると感じています。やはり、既存のシェアが高い企業ほど守りの姿勢になりがちだと思います。また、後段でご紹介するガバメントクラウドをベースとしたビジネスモデルについても、対応姿勢に差があると感じています。これまで均質的だった自治体向けIT市場にベンダー間の差が生まれるということは、この市場の転換点になる可能性があります。
須藤：もう一つ、こういうふうに、この図（講演資料53頁）で介護保険とか国保とかがありますが、大きな上流のシステムというのは大手のベンダーのようなクラウドが強いところですけれども、例えば、北日本コンピューターサービス株式会社が強いのは生活保護ですね。それから、介護保険が強いのはカナミックとかが有名です。特定分野に特化して強みを発揮しているベンダーはデータ連携にうまく乗っていけるのでしょうか。
三木：システム規模とそこで活動するベンダーの規模は相関関係にあると言えます。大規模システムである、住民記録や税、国民健康保険といった分野は全国企業の大手ベンダーの割合が高く、一方で中小規模システムである福祉や子ども・子育てといったものになると中小規模のベンダーや地域ベンダーが増えてくる傾向かと思います。中小規模ベンダーについては、理想像としては、従来のようにオンプレミス型で体制を組んで各ユーザー団体に張り付けなくても、ソフトウェアだけ優秀なものを創れば、オンラインで全国展開しやすいという側面があります。一方で、中小規模ベンダーの技術やビジネスモデルからするとクラウド型と合いづらい面もあるかと思います。
須藤：そう思います。
三木：例えば、福祉にしても子育てにしても、個々の自治体の条例で提供している部分が大きく、カスタマイズ率が高くなるので、同じソフトウェアの全国一律提供がやりづらいという側面があります。また、ビジネスモデルとしては、制度改正のたびにカスタマイズ部分の改修を行うことにより提供体制の維持や継続的な売り上げを確保している現状もあるようです。実際に、既にそのようなベンダーから撤退通告を受けたという話が自治体から聞こえてきます。
須藤：なるほど。今、厚生労働省系は本当に大変ですよね。
三木：そうですね。なかなか一筋縄じゃいかないところですから。やはり条例を無視して標準化しろと言っても、それは各団体の地域事情によりサービスを提供しているので、それを標準化により無くすことはできないですね。
満永：今の話の、ベンダーとの付き合いという話でいうと、ベンダーがポジティブかネガティブかという話というものは、ちょっと乗り切れないのがあると。その前提として、かなりきついベンダーロックインがあるように聞こえたのですけれども、乗り換えは、やはり頻繁にはできないものなのでしょうか。
三木：まず基幹系のシステムを更新するというのは、自治体にとって大きな作業なのです。霞が関はシステムをせいぜい5年しか使いませんが、自治体の基幹系システムは、まず10年は使います。仕様の策定、端末やネットワークなど周辺環境の切り替え、新システムでのトレーニングなど相応の費用が掛かるため、ユーザー側からの希望としては、長期間固定された環境でやりたいという側面があります。
また、日本の自治体市場のベンダーは、いまだにゼネコン型のビジネスモデルが主流です。いわゆる、受託して、そこで人工数単位で開発や運用業務の請求をする。クラウド型のビジネスモデルとは真逆なのです。クラウド型は先行投資の世界ですけれども、受託型ビジネスはあくまでも作業が発生することを待っていて、その作業が発生すると対価として人工数でお金がもらえます。ですから、そこが効率的なシステムであるかどうかというのは、ベンダーにとってビジネス上、あまりメリットとして関係ないわけです。
それどころか、制度改正の度に手間がかかるような非効率なシステムのほうが、作業が多く発生するので人工数を稼げるという、ディスインセンティブになる恐れがあります。調達側も受託側もこのジレンマを続けてきたわけですが、これを機にクラウド型にシフトできれば、人工数ビジネスから脱却できるチャンスになります。
満永：勉強になりました。ありがとうございます。
須藤：われわれはDX、クラウド化が大前提だということで考えているけれども、今三木さんがおっしゃるように、詳細を見ていくとものすごく課題があって、簡単ではないのですよね。それが分かった上でDXということも考えないといけない。ありがとうございます。
（「自治体システム標準化とガバメントクラウドにより転換する自治体ITビジネス環境＜後編＞『ガバメントクラウドとベンダーのビジネス転換』」に続く）
-
- 総務省デジタル統括アドバイザー
- 三木 浩平
- 三木 浩平
-
-
- 研究主幹
- 須藤 修
- 須藤 修
- 研究分野・主な関心領域
-
- 情報学
- 機械学習
- データサイエンス
- 社会システムの自己組織性
-
-
-
- 主席研究員
- 満永 拓邦
- 満永 拓邦
- 研究分野・主な関心領域
-
- サイバーセキュリティ
- データサイエンス
- コンピュータサイエンス
-
-
-
- 主席研究員
- 松崎 和賢
- 松崎 和賢
- 研究分野・主な関心領域
-
- ソフトウェア工学
- 制御システムセキュリティ
-
-
-
- 主席研究員
- 加藤 綾子
- 加藤 綾子
- 研究分野・主な関心領域
-
- 情報政策
- 情報社会
- 個人情報の保護と活用
- 個人中心のデータ活用
- プライバシー
-
-
-
- 研究員
- 原 翔子
- 原 翔子
- 研究分野・主な関心領域
-
- 社会情報学
- 人文情報学
- 情報デザイン
- ネットワーク論
-
注目コンテンツ
-
れいわ新選組「消費税ゼロ」の実現可能性を探る－ 連載コラム「税の交差点」第71回
れいわ新選組「消費税ゼロ」の実現可能性を探る－ 連載コラム「税の交差点」第71回
-
いまさら聞けない金融所得課税（1億円の壁）
いまさら聞けない金融所得課税（1億円の壁）
-
健康の社会的決定要因の向き合い方と課題
健康の社会的決定要因の向き合い方と課題
-
「年収の壁」の真偽と現行年金制度の歪み
「年収の壁」の真偽と現行年金制度の歪み
-
106万円の壁より深刻な住民税非課税の壁―欧米は給付付き税額控除で対応――連載コラム「税の交差点」第108回
106万円の壁より深刻な住民税非課税の壁―欧米は給付付き税額控除で対応――連載コラム「税の交差点」第108回
