マイナンバーの壁を元SIerエンジニアがパッケージという側面から見る

　実際に起きているだろうということです。

業務分担と机

　基本的に市町村役場は、定期異動が職制毎に発生いたします。それは定期異動があることによって、座る机と業務がセットになっているというイメージがあります。
　これは、もっと深い話として、前例を変えにくいという部分があります。県や国からの指示として実施する部分に対しては、肯定的と言えると思いますが、内部的な改善に対しては後ろ向きなことが多い気がします。

パッケージをそのまま導入できないケースが多い

　上記の理由で、パッケージをそのまま導入できないケースが多いです。例えば、一番当時分かりやすかったこととして、予算の積み上げの階層や名称が、団体、自治体でバラバラだったということがありました。
　また、ホストコンピューターからクライアントサーバになり、Web化となっても、そこで業務改善までは切り込めないと思います。
　というところで、必ずカスタマイズするというイメージが色濃いです。

　方や、私の企業ではBtoCのBへSaasを提供していますが、予算規模が大きくならないと、基本はデフォルト活用で対応できます。その中で、利用のサイジングが主なトピックとなっています。

縦と横の連携

　こんな例はあるかと思います。
① 数人の市民課で住民票・戸籍・国保・年金全部・税金業務やる自治体
② それぞれのグループで住民情報管理・国保・年金・税金の組織のある
　自治体
　それぞれ、横(総務省系と厚労省系、財務省系)データの連携する考え方も異なると思います。
　そして、健康保険組合、国家公安委員会・警察が今後関わってきます。
　まず、業務体系の標準化が必要だと大体察しがつくと思います。

即時適用の危険性

　民間の処理などでも、毎日のデイリーの処理、週次処理、月次処理を夜間でやっています。ただ、その辺が、どうも最近のスマホアプリの感覚で考えると、即時性というバイアスが見え隠れします。
　2日適用までかかると言って、憤慨する人多いですよね。でも、それはデータの安全性を考えると、必要な時間だと考えられないことがエンジニアとしては恐ろしい部分。

完全なマスタデータと一時データの互換

　現実問題、即時性は必要だと思います。但し、それは完全なマスターデータを必要な部分だけ、一時データとして持ち、必要な更新は、細かい適用ルールに基づいて、夜間処理で本番適用か却下の判断をしなければいけないと思います。この処理を間違うと、恐ろしいことが起きます。

台帳登録の難しさ

　Excelベースでも紙ベースでも台帳登録というのは難しいものです。在籍したSIerでは戸籍システムを販売しておりましたが、精鋭の入力部隊ありきだったと記憶しています。
　それでもヒューマンエラーは不可避と思いますし、それを最低限に抑えるというのはノウハウであり、価値であり、コストだと思っています。

消えた年金問題

　年金の場合は言わばワンイシューの問題でしたが、今回は省庁をまたぎ、かつ、健康保険団体、医療機関をまたぐというマルチイシューな内容です。年金よりもハードルが高いのは目に見えていますね。
　何も知らない政治家先生はこれを、超短時間で片付けようとしています。まぁ無理でしょう。ランサムウエアにでもやられたら、目が当てられない状況になるのは必至ですね。

　今日はこれにて