新型コロナ禍は現代日本社会に潜むさまざまな無駄や不合理を明らかにした。出社のための出社や儀礼的な捺印の無駄ばかりか、広々としたオフィスやある種の人員を抱えることの無駄まで明らかになった。無駄や不合理なモノゴトであれば即刻排除せよと短絡的に考えるべきではないが、痛みを伴うこの気づきを今後に生かしたいと思う。それを生かせないほど我々は愚かではないと信じたい。
業務システム開発の専門家として他人事でなかった問題が、自治体システムの非効率さだ。期待されていたオンライン申請が次々に利用停止に追い込まれ、多くが本人証明書の両面コピーを添付する郵送申請に舞い戻った。昭和時代と変わらないやり方だし、何千億円もかけたらしいマイナンバーのしくみが生かされていない。
問題は以下のように大きく３つに整理できる。まさにこれらゆえに、自治体の膨大なシステムコストと自治体職員の過重労働が発生した。何よりも、なかなか入金されずに多くの住民が途方に暮れることになった。
１．中央省庁が管理するマイナンバーと自治体システムの連係が十分でない
２．自治体システムが自治体毎に開発されることが前提になっている
３．給付プログラムが決議されるたびに追加開発や業務委託が必要になる
これらを手当するためのレファレンスモデル「自治体給付管理システム」を公開した。データモデルと、これにもとづいて実際に動作するシステム実装例との組み合わせである。その中からまずは、自治体、世帯、住民、事業所との関係を示すデータモデルを説明しよう。
▼自治体、世帯、住民、事業者のモデル
世帯、住民、事業所の管理テーブルは、それぞれ世帯ID、住民ID、事業所コードを主キーとしている。「マイナンバー」は住民テーブルのサブタイプを構成し、住民IDの二次キーとされている（つまり住民のマイナンバーは変化し得る）。自治体システムの開発において重要なのは、マイナンバーそのものではなく、そのまわりに配置されるテーブル群の設計である。
ここでは、世帯、住民、事業所が日本国全体で一元管理される点が決定的に重大である。たとえば住民が自治体を転出する際には、同じ住民IDのままで自治体コードだけが転入先のものに変わる。現行システムでは転出申請の後に、引っ越し先での転入申請を忘れるだけであっけなく「住所不定」になってしまうが、住民IDを一元管理すればその怖れはない（転出時に転入先住所が求められるからだ）。
厳密に言えば、移転（転出・転入）することで住民の「自治体コード」が変わるのではなく、「世帯ID」が変わる。たとえば家族から独立して他の自治体で一人暮らしをするとすれば、移転先の自治体コードを持つ新たな世帯IDが発番されて、住民データが更新される（続柄は世帯主）。世帯主が長期に単身赴任する場合であれば、移転先のあらたな世帯が発番・設定され、残された家族の誰か（たとえば配偶者）が世帯主とされるような一連のトランザクションが起こる。これらの過程で住民IDはいっさい変化しない。
じつはこのモデルは、自治体システムが日本で１基だけあれば済むことを示している。固定資産管理のような分野では自治体毎の差異が大きいが、そこらへんも可変的に扱えるDB構成を工夫すれば、自治体ごとのアドインは最小限度で済む。各自治体が同一のシステムを用いることで、災害時のオペレーション融通などさまざまな利点が生まれる。最大の利点は自治体のシステム開発・維持コストが桁違いに安くなることだ。ここらへんのコストを減らさねば、いざというときの給付に充てる財源までが減ってしまうので切実だ。
つづいて給付管理のモデルを見よう。公開したレファレンスモデルでは「世帯給付」、「住民給付」、「事業所給付」の３つのサブシステムを用意したが、ここでは、今話題の"新型コロナ禍一律給付"が扱われる「住民給付」のモデルを紹介する。
▼住民給付管理のモデル
"新型コロナ禍一律給付"は「住民給付テーブル」上で定義される給付プログラムのひとつである。それは｛住民給付№｝を主キーとするものだが、「住民給付申請テーブル」では｛住民給付№＋世帯ID｝の複合主キーになっている。これはひとつの給付プログラムに対して、各世帯は最大1件の申請しか出来ないことを意味する（当たり前のように思えるかもしれないが、今回ある自治体では同一世帯主が15件も申請できてしまったという）。
給付プログラムの登録から申請・入金までの流れを見よう。議会での承認が見込まれた時点で、各自治体は住民給付№を発番して各自治体での給付プログラムとして登録して備える。議会で承認され、さらに給付条件が適用される日付が到来したなら、全住民に対する申請データをバッチ処理で一括登録する（今回は全住民が対象であるからだ。通常の申請は住民によって個別登録される）。こうして、適用日時点での世帯人構成と世帯主の銀行口座番号がコピーされた形で申請データが出来上がる。
続いて、各住民が自世帯向けの申請データをオンラインで確認して了承する（スマホやPCのない世帯は役所の窓口で手続きする）。世帯主によって了承された申請データにもとづいて、夜間バッチ処理にて金融機関＋支店毎の振込指示が生成され、ファームバンキングで各支店に送信される。このプロセスを律速するのは公開から住民による了承入力までのリードタイムで、口座番号の登録ミスがない限りは了承入力から数日以内に入金される。もちろん、申請了承のアクセスの殺到が予想されるので、クラウド活用は必須だ。
ちなみにこのモデルには「フィーチャ・オプションのモデルと実装」で説明した「評価式」が効果的に組み込まれている。"新型コロナ禍一律給付"は無条件のプログラムであるが、ふつうはいくつかの条件が伴う。たとえば災害に対する被災給付であれば、家屋の被災状況や面積のような条件が考慮されるだろう。モデルにはそれらの条件への指定値に対する「評価式」や、複数条件値にもとづく給付額を算出するための「算定式」が組み込まれている。それらの設定はそれなりにややこしいが、専用システムを新規開発するより格段に容易である。つまり、新たな給付プログラムの決議はシステムの追加開発や新たな業務委託ではなく、DBへの新たな給付定義の登録しか要請しない。
この強力な仕掛けを実現する際の障害のひとつが、「国民背番号や銀行口座といった個人情報が役所に知られるのはどうも気が進まない」といった住民側の感情だろうと思う。個人情報を役所に知られないままで自治体住民であることは、もちろん許されていい。ただしその場合は役所にわざわざ出向いて、本人確認を含めてアナログに手続きする面倒を引き受けなければいけない。そのうえで「自分は不便でもいいから個人情報は提出しない。それでも自治体システムは合理化されるべきだ」という態度をとってほしいと思う。住民税はけっして安くない（というかものすごく高い）にもかかわらず、自治体システムが抱える不合理ゆえに税金が有効活用されているとはいえないからだ。
システムの開発・保守や運用にともなうコストが最小限になるような自治体システムのあり方が求められている。そのために、我々のような業務システム開発の専業者に何が出来るだろう。現行システムの出来の悪さをあげつらうのは誰にでもできる。そうではなく、今後の改善・刷新に寄与する具体的なシステム構成を考えてみてほしい。今回提示したデータモデルは私なりの拙いアイデアでしかないが、多くの技術者のアイデアを盛り込んで、世界に誇れる自治体システムにしていきたいと思う。新型コロナ禍がそんな動きが始まるきっかけになってほしい。
