行政デジタル化 青写真と今後の論点

新型コロナ感染症対策での様々な混乱を受けて、今後こうしたことが起こらないように、菅官房長官（当時）の肝煎りでデジタル行政サービスと自治体情報システムの在り方を見直すWGが6月に立ち上がり、この金曜朝に総理臨席のもと3回目の会合がありました。検討の叩き台となる行政情報システム改革のトータルデザインについて斎藤構成員から説明があり、私からも補足説明させていただいた他、戸籍へのカタカナ氏名の追加や、自治体標準化について討議が行われました。関連資料はこちらからダウンロードできます。

行政デジタル化を5年で達成　首相指示、年内に工程表

全体としては手続きのデジタル完結率を向上させて、新たなデジタルセーフティーネットの構築へ向けて、国と地方で一体となって推進していくことを目指しています。2022年までに突発事案に対して即応できる情報システムを整備する「足し算」、2025年へ向けて自治体の情報システム標準化を推進し、段階的なクラウド環境へと集約して各団体の情報システムがバラバラなため必要だった団体間の中間的なデータベースを一掃しAPI連携に移行する「引き算」の改革を提案しました。

まず2022年までに、仮に今回の新型コロナのような突発事案が発生した際、迅速に全国向けの共通システムを提供し、1週間以内で給付を完了できる仕組み。具体的には給付金の消込にも使える自治体共通SaaS、国民の銀行口座と直結して公金出納を集約する公金口座システムの整備を考えています。

特別定額給付金オンライン申請を振り返ると、郵送申請と違って世帯構成などの情報が事前に入力されていないことが問題でした。これは申請事務に用いられたマイナポータルが、申請書の受け渡しについては自治体と繋がっていたものの、自治体の住民システムとは繋がっていなかったからです。給付金を住民に対して実際に支払ったか等の消込は、各団体が個別にシステムを整備したり、Excelなどを使って目視で管理していました。

こうした突発事案の際に、急拵えでつくられた制度に合わせて突貫で業務を組み立ててシステムを構築することは大きな負担です。団体によっては整備が間に合わず、今回のような混乱に繋がりました。そこで突発事案が起こった際、政府が構築した共通のSaaSサービスを各団体向けに提供し、各団体は基準日時点の住民情報をSaaSに流し込んで、その上で給付の消込や電子申請の受付といった業務を回すようにすれば、各団体が個別にシステムを整備する必要はなくなって、電子申請サイトは流し込まれた情報を参照して、最低限の入力で電子申請を受け付けられるようになります。SaaSのデータベースを団体単位で分離すれば現行制度のまま対応できます。

同時に全ての住民に対して公金出納専用の口座を国が提供する「公金口座」の構想も打ち出しました。自治体が住民基本台帳にある誰に対していくら支払うかを台帳に書き込むだけで該当者に給付できる仕組みです。公的機関は今回のような給付に際して、申請書や口座番号の取得に煩わされることがなくなります。住民は「公金口座」と自身の銀行口座を紐付けることで給付を受け取るか、コンビニATM等でマイナンバーカードを使って直接出金できる仕組みを検討しています。

かねて給付の効率化には銀行口座とマイナンバーとを紐付ける「預金付番」が効果的とされていました。しかしながら金融機関の口座にマイナンバーを紐付けただけでは給付を効率化することはできません。金融機関が預金者のマイナンバーを取得するだけでなく、公的機関がどの口座に振り込めばいいか把握でき、その口座に対して給付を行うことについて、住民の同意を取得できている必要があります。公的機関は年金や児童手当、所得税・住民税の還付、水道料金の徴収などのために住民の銀行口座を把握している場合がありますが、給付金の支払いにその口座を用いる同意が取得できていないため、勝手に給付する訳にはいかず、申請書を受け取る必要がありました。

具体的に「公金口座」をどうやって実現するかは未定ですが、年金のように口座番号を登録して銀行口座に振り込む、公と住民との間で包括的な口座振替契約を結ぶといった手堅い方法から、CBDC（中央銀行発行デジタルマネー）など新しい基盤の構築まで、様々な方法が考えられます。

特別定額給付金では世帯単位の給付が不評であったことから、今後は個人単位の給付も視野に入れて検討する必要もあるでしょう。その場合に世帯主の後ろに隠れていた未成年者や成年被後見人の扱いをどうするか、手数料などの事務費をどこまで低減できるかも課題です。いずれにしても誰もが簡単に使えて、困ったときも適切に手を差し伸べてもらえる仕組みとする必要があります。

そして2025年へ向けて、自治体システムをクラウドに移行し、住基ネットや情報提供NWSの中間サーバーをはじめとした団体間のデータベースを廃止して、クラウド内でサービスメッシュを介した直接API連携に移行することを構想しています。

自治体システムの仕様を標準化するのか、それとも団体間のシステム統合まで踏み込むのか、報道も混乱していますし、関係者からもスケジュールが拙速過ぎるのではないかといったお叱りもいただいています。この点については実のところ構成員の間でも様々な意見があるところです。

わたしからは具体的な目標を設定せずに、無理に団体間の仕様を揃え、全ての業務をカバーすることにこだわると、日程的に無理がある中で似たようなシステムの作り直しになってしまって、十分な効果を得られないのではないか、まず目的や目標を明確にしてやるべきことを絞り込む、標準化のための標準化ではなく、具体的な住民メリットを実感できる施策に優先して取り組むべきではないか、といった意見を述べさせていただきました。

個人的な見解としては、住民管理について作成された標準仕様書を見ても、現段階ではSoRとSoEの切り分けが十分にできておらず、この状態で無理してシステム統合まで踏み込んでしまうと、今やっている自治体の事務を十分にカバーできないのではないかという危惧を持っています。

とはいえ現行構成のようにバラバラな自治体システム、業務単位で縦割りの団体間連携システムが相互に足を引っ張って、手を付けられない膠着状態にはメスを入れる必要があります。少なくとも団体間連携に使われている中間的なデータベースと業務ロジックを、サービスメッシュ上でのAPI連携に置き換えて、部分的な改善を積み重ねられる疎結合構造へと解していく必要があるでしょう。

システム統合による割り勘効果と、独占やシステム運営の主体が曖昧になることの弊害とを見極め、廃止できるシステムは廃止して、標準化・共通化を通じて統合運用できるところは集約しつつ、環境の変化に柔軟に適応でき、現場の創意工夫を引き出して、適切に市場競争が働くエコシステムを目指して、現実的かつ住民が便利になったと実感できる目標を設定すべきです。

年内の工程表策定へ向けて、いよいよ検討は大詰めとなりますが、叩き台となる青写真を出したことで、今後は自治体やベンダーなど多くの方々との対話を通じて、効果的かつ実現性の高いロードマップへと磨き込んでいくフェーズとなります。

引き続き皆様よりご指導ご鞭撻のほど何卒よろしくおねがいします。