設計者の発言

業務システム開発とデータモデリングに関する語り

職場にマイナンバー提出っておかしくない?

 2016年にマイナンバー制度が施行されてから、正社員もバイト要員も職場にマイナンバーカードと身分証明書のコピーを提出することが求められるようになった。現状では事由次第で提出拒否が認められるようだが、それにしても残念なルールだ。住民がどの事業所からどれだけ所得を得たかがわかれば税務や社会保障に生かせるはずで、そのために事業所と住民の紐づけが必要なのは理解できる。しかし、だからといって従業員がマイナンバーをいちいち職場に知らせる必要があるとしたら、自治体システムの出来が悪すぎると言わざるを得ない。どういうことか。

 まず、住民と事業者に関する「本来あるべきデータモデル」を確認しよう(図1)。住民は世帯を介して自治体と関連され、事業所は直接自治体と関連されている。具体値として、"ABC123456"のマイナンバーを持つ岩見沢市在住の"山田太郎"氏と、札幌を拠点とする企業"大日本帝国産業"が示されている。

f:id:dbconcept:20210821092807p:plain

図1.住民と事業所のモデル

 住民がマイナンバーではなく、UI上では不可視な「住民ID」で識別される点に注意してほしい。マイナンバーはマイナンバーテーブル(3)の二次識別子(*1)を構成している。マイナンバーテーブルは総務省の住基システム上に置かれ、住民テーブル(4)は自治体システム(統一自治体システム)上に置かれる。住民がマイナンバーカードを用いて自治体システムにログインする際に、住基システムのAPIが「マイナンバーに対応する住民ID」を返す。それ以降の処理でマイナンバーは利用されない。つまり、マイナンバーは「セッション開始時点でログインユーザの住民IDを確保するためのダシ」でしかない。

 各事業所にとってはどうか。彼らが従業員の住民IDを確保するための手掛かりとしてマイナンバーは必要なのだろうか。必要ないし必要であるべきではない。従業員のマイナンバーを預かる事業所のデータ管理方針を厳しく規定する法律は存在する。しかし、日本中に星の数ほどある会社の管理レベルをあてにしているようでは、マイナンバー制度そのものに対する信用が損なわれかねない。会社としても余計な管理責任を負いたくないに違いない。マイナンバーは基本的に「(扶養者等を除く)いかなる他人にも知られる必要のない個人識別情報」として扱われるべきだ。

 マイナンバーを職場に知られずに、自治体システム上で職場からの給与支払を記録したい。そのための仕掛けを説明しよう。仕掛けといっても大袈裟なものではないし、DB設計としては単純かつ平凡だ。図2を見てほしい。

f:id:dbconcept:20210821093147p:plain

図2.住民と事業者の関係を含むモデル

 赤枠で囲まれている「事業所別住民属性(5)」のテーブルが肝だ。自治体システムがこれを参照することで、事業所コードと社員コードの組み合わせから住民IDを特定できる。ゆえに、事業所が社員コード指定で毎月の給与支払額を申告すれば、自治体システムは住民IDを特定して毎月の「給与所得実績」を追加できる。その過程で事業者がマイナンバーや住民IDを意識する必要はない。

 事業所別住民属性のレコードが登録される過程を説明しよう。山田太郎氏(住民ID:111111)は大日本帝国産業(事業所コード:555555)で働くことになった。会社は山田氏に事業所コードとともに、彼に付与した社員コード(S0123)を伝える。山田氏は自分のスマホかPCを使って自治ポータルサイトにログインし、伝えられた事業所コードと社員コードの組み合わせ、すなわち事業所別住民属性のレコードを登録する(*2)。これだけで、会社が自社向けの自治ポータルサイトを開けば山田氏の行が追加されていることを確認できる(*3)。登録を忘れていたとしても、会社が月次で給与支払申請する際にエラーになるので遅かれ早かれ対処できる。

 細かい点を補足すれば、住民税や所得税を計算するためには給与所得だけでなく、保険料や寄付といった控除に関する支払情報も必要になる。ゆえに、モデル上の給与所得実績は「控除支払実績」を兼ねる形で設計されたほうがよさそうだ。関係する事業所が保険料や寄付の入金実績を登録する際には、住民はその事業所コードと住民識別コード(事業所が住民を識別するために払い出したコード。上述した社員コードに相当する)を同様に登録することになる。最終的に、給与所得実績や控除支払実績は住民別年次サマリに集約され、そのレコード上で税計算が実行される。

 このように自治体との連係や税務処理が合理化されるわけだが、住民は「当局や事業所の事務は楽になるだろうが、自分は所得を月次でがっちり把握されるだけで美味しくない」と感じるかもしれない。そうではない。所得情報は社会保障の基礎になるからだ。たとえばイギリスでは住民の毎月の所得がリアルタイムで把握されており、コロナ禍で過去数カ月間の収入が減った住民には簡単な申告で平均給与額の8割が補償された。申告から入金まで数日しかかからなかったという。

 いっぽう日本では給与所得が年次に合算でしか更新されないので、期中で所得が減ったことの申告や評価にたいへんな手間がかかる。本来なら、もともと少なめの所得がより減少した住民に対して手厚くかつ素早く補償されるべきなのにそれがやれない。与党は「10万円給付」のように無駄の多い施策で人気取りするしかない。しかも自治体システムが各自治体毎に個別に開発・運用されているので、入金されるまで何カ月もかかる。こういった不合理もまた、あなたが職場にマイナンバーを伝える羽目になっているのと同様、自治体システムの出来の悪さゆえである。


*1.一次識別子(primary key)はユニーク制約を持つだけでなく、参照整合性を維持するために値の変更が許されない。いっぽう二次識別子(secondary key)はユニーク制約を持つが、リレーションシップの基礎となっていない限り値の変更が許される。このモデルのマイナンバーはリレーションシップとは無関係なので、値を何度でも変更できる。すなわち、カード上のICチップデータを役所設置の専用機で書き換えるだけでいい。カードの再発行は要らないはずだが、マイナンバーがカード上に印字されていれば再発行が必要だ。

*2.この手順さえ面倒だという向きは、漏洩リスクを覚悟のうえで、職場にマイナンバーを伝えて作業を代行してもらえばいい。

*3.社員コードと氏名付きだが、住民IDやマイナンバーは示されない。社員コードは必要に応じて修正できるが、その値は事業所内でユニークでないといけない。