日本データマネージメント・コンソーシアム

その他

テーマ3: 内外先進事例に学ぶ行政データマネジメント研究より

「自治体における宛名情報の管理および番号制度を見据えた対応状況について」

講師: 林 浩一 (ピースミール・テクノロジー代表取締役社長)
海老名立弥(同社シニアコンサルタント)
日時: 2014 年 5 月 26 日(月)18:30〜21:00
場所: 三菱電機インフォメーションシステムズ


新生児の出生届が役所に受理されると、戸籍の作成とともに、市町村(基礎自治体)の住民記録台帳に氏名、生年月日、性別、住所等の個人情報が登録される(※1)。このデータ登録をきっかけにして、就学、 就業、結婚、出産・育児、健康増進・医療、介護、看取り……とそれ以後の人生における節目節目のライフイベントを通じて、幾度も自治体の窓口との接点を持つことになる。申告・納税などの務めを果たしつつ、法律で保障される各種権利を行使(行政サービスを利用)していく。

一方、自治体では国から委託される行政業務を代行するとともに、同時に条例などで定めた地域独自の行政サービスを提供する。受益と負担の原則に基づいて窓口などでの利用者(主に当該自治体住民)への対応を日々求められる。

ここで鍵になるのが、上述の住民情報に紐づく「宛名情報」である。行政側が提供するサービスと利用者のニーズを的確かつ迅速にマッチングするために作成・運用される役所内部の情報だ。宛名情報が不正確ならば、住民は受給する権利のある行政サービスを利用できずに不利益を被ったり、その逆で、保険料や税を支払っていないにも関わらずサービスを受給する不正行為が発生したりする。

宛名情報は本来、住民の動態、または、各自の人生における出来事に併せて、適切にアップデートされなければならない類いの情報である。とはいえ、それは容易なことではない。総務省統計局の発表によると、平成 24 年、我が国の出生数は約 103 万人、死亡数は約 125 万人であった。死亡数が出生数を平成 19 年に上回って以来、人口の自然減が続いているが、おおむね人口の 1%程度に相当する戸籍および住民記録のデータが毎年入れ替わっている、という状況が、この数字から読み取れる。 それだけ連動する宛名情報も激しく移り変わる、ということだ。

宛名情報に起因する問題・不正を防止・解決するために、自治体では手続きの都度(または必要に応じたタイミングで)「名寄せ」という宛名情報の紐づけ処理を行っている。また後述するように、業務ごとに管理する宛名情報を横断的に統合しよう、という動きもある。さらに、2016年以降本格的な制度開始を控えるマイナンバー制度のもとで改善が期待される事項も考えられる。

2014年5月26日開催された行政DM研究会では、札幌市をはじめ全国各地の自治体の基幹システム再構築案件などで豊富な実績を有するピースミール・テクノロジー社の代表取締役林浩一氏、シニアコンサルタントの海老原立弥氏に、自治体における宛名情報の管理および番号制度を見据えた対応状況についてレクチャーを受けた。本稿は、その内容をダイジェストでお伝えするものである。

◆行政上の事務処理に欠かせない宛名情報

本稿に登場する「宛名」というのは、当該地方公共団体(主に基礎自治体。以下、自治体と略す)の内部で扱われる住民の個人情報である。氏名、住所、 性別、生年月日という住民基本台帳に記載された 4 つの基本情報および、付随するその他の属性情報から主に構成されるデータだ。その他の情報には、電話番号のような連絡先、税金の還付先となる金融機関の口座番号などが含まれる。詳細な記載項目・内容は手続きに応じて異なる。

宛名情報は、自治体内の複数の業務システム(コンピューター)が必要に応じて参照できるように、基本的には電子的に保存されている。民間企業の業務にたとえると顧客台帳(顧客マスター)に該当するものだ。申告・納税手続きを行ったり、行政の支援・助成を受けたりする住民に向けた事務処理の円滑化に欠くことのできないデータと位置づけられる。
宛名情報のデータ構造は、各自治体のシステムアーキテクチャに依拠するため一律ではな いが通常は宛名データベース(以下、宛名DB)と呼ばれるリレーショナルデータ ベース(RDB)に集約されている。宛名 DB は各自治体に一つだけ、ではない。内部の業務ごとに「税宛名DB」「福祉宛名DB」のように各業務アプリケーションに付随する形で、複数作られているのが一般的だ。各宛名DB のデータ(宛名情報)は、自治体内部で独自に付番された「住民コード」や、税システムや福祉システムなどをまたぐ「(統合)宛名番号」(後述)によって紐づけられている。
◆宛名情報の生成プロセス

宛名はどのように作成されるのだろうか。ある自治体(z市B区)に転居してきた A さん (60 歳)の例で説明しよう。z市は政令指定都市であり、条例により市の権限に属する事務を分掌させるために区(行政区)を設けている。B区もその一つである(※2)。

さて、転入してきたAさんについて、B区役所の住民課では、記入してもらった転入届や以前Aさんが住んでいた自治体で発行された住民票をもとに、住民記録用の宛名DBの中に新たに宛名A1を作成した。
転入してしばらく経った頃、A さんは高齢者向けの福祉サービスを申請した。B区役所の福祉課ではAさんからの申請書類に基づいて、福祉宛名DBの中に宛名A2を作成した。
その後、A さんは病気を患い、障がい者向けの支援を受けるための申請を行った。障がい支援を行うB区役所の窓口担当者は、申請書に沿って新たに障がい者用の宛名A3を当該DBに作成した。
これら 3 つの宛名データを同一人物のものであると紐づける作業が名寄せである。データを判別するソフトウェア(ツール)を使ってある程度、機械的に処理することが可能である。しかし、現実には、どの自治体でも名寄せ不足の宛名(「迷子の宛名」)が多かれ少なかれ発生しているのが実情だ。発生理由については後述する。

◆窓口における応対サービスの品質低下

宛名情報の名寄せ不足によって、どのような問題が引き起こされるのだろうか。
1つ目の問題が、「役所窓口における応対サービスの品質低下」である。
前述のAさんが、福祉サービスを申請する場合、窓口の担当職員は、規定された業務ルールに沿っていくつかの確認作業を行う。申請者が本人であるかどうか(代理人の場合、本人との関係を把握する)。自治体のサービスを受給する資格があるか(住民票のある住民か、納税義務を果たしているか、すでに当該サービスを受給していないか)などである。担当職員は、申請書類に記載された情報や、本人確認用の書類(運転免許証、パスポート、住民基本台帳カード、健康保険証など)と、自治体の福祉宛名DBを照合してそれらの確認を行う。過去の納税情報については、税務を扱う他部署の担当者に文書、電話、口頭で確認する。福祉課から問い合わせを受けた税務の担当者は、税宛名DBの宛名情報をキーとして納税情報についてチェックを行う。

こうした確認作業には、それなりの時間がかかる。A さんにしてみると、きちんと申請書に漏れなく記入し、納税も日頃しているのに「なぜ、 こんなに待たされるのだろう」とストレスを感じるかもしれない。窓口の担当者が納税情報などをうまく確認できない場合、Aさんは「税務関係の部署に直接出向いて尋ねて下さい」と複数窓口をたらい回しにされるかも知れない。税務課でもうまく納税情報などが確かめられない場合は納税情報をデータベースに登録し直すため、「 お手数ですが(以前に提出いただいた)申請書類をもう一度、作成・提出してください」と指示される可能性もある。
こうした窓口の対応ついて「長く待たされる」「不親切だ」といった不満や苦情が増え、利用者の窓口の応対品質に対する満足度が低下するおそれがある。

◆行政サービスを不正利用される原因に

上記とは別に、宛名情報の名寄せ不足に起因して、「行政サービスが不正に利用される事態」も起こりえる。 たとえば、生活保護を重複して受給するというケースだ。
B さんは、z市C区ですでに生活保護を受けている人物だ。しかし、(故意・過失を問わず)同市 D 区でも、生活保護の受給を申請した(いずれの区でもBさんは住民登録を実施していないとする)。
申請を受け付けたD区の担当職員はまず、D区で過去に申請がなされていないかどうかを、z市の当該宛名DBを利用して確かめる。
この時、初回申請時とは異なる別名で申請され、本人確認も別名で行われると、D区窓口担当が重複申請に気づくことができずに見落としてしまうことがある(また、自治体間をまたぐ場合には確認作業はさらに困難である。日本には基礎自治体が1,700以上あるので個別にすべて確認することは費用対効果に見合わない)。その結果、z市の当該宛名DBに、Bさんの新たな宛名ができてしまい、重複受給が発生してしまう。

◆払い過ぎに気づかない、逆のケースも

不正受給とは逆に、住民側の不利益が見過ごされるケースも、宛名情報の名寄せ不足で生じる可能性がある。たとえば、税金や保険料の払い過ぎという状況である。ほかにも立場上、利用できる助成金や支援サービスがあるのにそれを知らなかったゆえに、必要以上の医療費の支払いなどを自己負担で行ったり、生活の窮状から脱する機会を逸したりするおそれがある。

◆住登内者と住登外者

ここでいちど、行政機関の窓口から見た「住民」という言葉を整理したい。実は、自治体の住民登録には大きく2つの区分がある。

1つは、「住登内者」である。自治体に住民登録がある人を指す。自治体内に現住所を有し、生計を営み、所得があって住民税を納めなければならない人である。住民登録があるので、自治体内の宛名DBには、住民コード(住民番号)が付番されている。住民コードは役所の内部業務処理用なので本人には通知されない。役所内部のみで流通する管理番号である。

他方で、当該自治体の住民ではないが、その自治体でなんらかの住民サービスを受けている人がいる。 たとえば、主に生計を営む地域はi市だが、j市に別荘を所有し、j市に固定資産税を支払い、公営の上下水道やゴミ収集サービスを利用している人、などだ。j市では、こうした人を「住登外者」と呼び、行政機関のシステム上は住登内者と区別している(この住登外者は住民票のあるi市において住登内者の扱いになる)。

住登内者にも、住登外者にも属さない人もいる。一例が、観光や出張で一時的に当該自治体を訪れた人だ。システム上は「何者でもない人」になる。ただ、こうした人が、訪問先で傷病を負い、行政サービスを利用するケースも稀ではあるが存在する。
職員は窓口に来た人に対して、住登内者か、住登外者か、あるいはどちらにも属さない人 か、宛名 DB を使って調べる。住登内者でも住登外者でもなければ、「今日、初めてこの自治体で行政サービスを受ける人」と判断されて、本人(場合によっては代理人)の申請内容に基づいて、新規に住登外者として宛名情報が登録されることになる。

◆宛名情報の統合が難しい理由

上述のように、異なる部署の職員は、互いに他の署のシステムが管理・運用する宛名情報を自由に利用したり、更新したりす ることはできない。これはシステムの作りの問題、あるいは行政の縦割りの問題であるという以前に、それぞれの制度で宛名が持っている法令上の意味が異なるためである。

たとえば、今住んでいる住所が重要な制度もあれば、その年の1月1日に居住していた住所が重要な制度もある。そのため、住所変更の届けを受け取った担当部署が、すぐに住所を変更してしまうと問題が生じる。これらの要件は法令で決まっているものである。ひとつの部署だけでも非常に複雑な要件からなる。すべての関連法令を熟知した上で、それらに配慮しつつも「特定の制度の都合を考慮して宛名情報を扱う」ということは実際には不可能である。

現状は、連携が必要なケースについて、対象となる制度間をつなぐ連携機能を個々に作っていくアプローチが取られている。そのため、複数業務の関連が複雑に錯綜したスパゲッティシステムになっている自治体も多い。まとまった規模の業務全体に対応するパッケージを導入することで、宛名をある程度まとめることはできても、全業務にまたがるような統合化は実現されていないのだ。

◆政令市で進む先駆的な宛名DB統合化の取組み

しかし、もし、こうした宛名間の複雑な関連をシステムで整理した上で、相互に宛名情報を閲覧できるようになれば、行政サービスの対応品質向上や、行政区をまたぐ不正受給の問題解消、払い過ぎのような利用者側が不利益を被るケースも減るだろう。

自治体の中には、これまで説明したように極めて複雑に絡み合った制度上の関係を、統合モデルとして整理した上で、部署間での宛名DBを統合化する取り組みを進めているところも現れている(なお、この宛名DBの統合は、後で述べるマイナンバーのための統合宛名システムとは異なる) 。
従来、システムごとに各種宛名DBを管理・運用していたが、各部門の窓口担当者が相互に宛名情報を閲覧できれば、窓口における確認作業などがより確実に、効率化・迅速化するメリットが得られる。

◆「包括フレームワーク技術」によるシステム開発

さて、上で説明したような自治体における宛名情報の統合化という課題への取組みを支援しているのが、ピースミール・テクノロジー社だ。ピースミール・テクノロジーは、産総研の基幹システム再構築を通じて生まれた「包括フレームワーク」の技術を事業展開するというミッションを持つ企業だ。包括フレームワークは、発注側にシステム開発に必要になる標準一式を提供するもので、それらを使うことによってSI会社へ丸投げするのではなく、利用者主導でのシステム開発を可能にする狙いがある。

包括フレームワークは、利用者主導を実現するための「グラスボックス化」という考え方で整備されている。利用者でなくてもシステム概要が理解できるような仕様の透明性と、十分な技術力の開発者であればシステムのアーキテクチャが理解できるような技術の透明性を高めるという考え方からなる。包括フレームワークは元々は製造業などの民間企業で行われてきたエンタープライズ・アーキテクチャの考え方を横展開できるように産総研において理論化したものである。

包括フレームワークは、ベンダーロックインと言われるSI会社への過度の依存状態の問題を解決したい自治体で広く採用されており、横浜市や札幌市といった政令市をはじめ全国各地の大小様々な自治体での採用、また、製造業や金融機関での活用も進められている。

◆政令市向けシステム基盤における宛名DB

包括フレームワークでは、仕様の透明性の観点から、利用者が理解しやすい業務フローを起点にしたシステム開発のプロセスを定めるとともに、技術の透明性の観点からオープンソースをベースにした、システム基盤を用意するところに特徴がある。システム基盤で重要なことは、組織全体の業務を俯瞰する形で作ったデータモデルに基づく統合データベースを持たせるところにある。組織全体の業務をサポートする統合データベースを中核に持つシステム基盤を用意することによって、業務プロセス分析から得られるシステム化部分を効率よく実現することが可能になるという。

包括フレームワークのシステム基盤のアプローチはフルスクラッチ開発だけでなく、パッケージの導入や既存システムを整備していく上でも有用な枠組みとなるという。

今日、公共・民間問わず、多くの企業や事業体において、様々な時期に導入されたパッケージ、ERP、独自開発システム等が乱立し、複雑な連携をしているのが現状だ。システム基盤を中心にこれらを統合化することが、ビジネスの変化に素早く対応することのできる基幹システムを整備することにつながる。

宛名DBの統合は、包括フレームワークをベースにしたシステム基盤における全体業務を支援する統合DBに対応する。なお、政令市向けシステム基盤には、それ以外にも自治体で重要になる外字文字基盤や帳票基盤などが用意される。

◆マイナンバーと統合宛名システム

マイナンバー制度に関連して、統合宛名システムという考え方に対して注目されるようになっている。マイナンバーは住民に対して唯一の番号を与えるものであるが、それを行政サービスに用いるには、自治体で管理している住民コードと紐付ける必要がある。どの宛名に紐つけるかという問題に対する回答として、統合宛名システムで管理を容易にするというアプローチがある。ここでいう、統合宛名システムは前述したような全業務俯瞰的にモデル化をするものだけでなく、主要なパッケージに宛名情報を合わせていく、といったようにいくつかの考え方がある。

ただ、どのようなやり方を取るのかに関わらず、統合宛名管理システムを導入しても、名寄せ不足の問題は残る。窓口利用者が自己申告する氏名や住所、提出する本人確認書類など、表記の仕方が揺れやすい漢字仮名まじりの日本語の文字列を手がかりに、職員がデータを検索したり、処理したりせざるを得ないからだ。
さらに、自治体に住民票を有する住登外者の扱いが難しい。ほかにも、10年も20年も海外に暮らしていた人が自治体に戻ってきた場合、もともと住登内者であっても、過去の宛名情報がシステムに残っていない(あるいは見つけられない)ために、職員が内部で用いる住民コードを新規に振り出す場合がある。長年経つと、担当職員もだいたい異動・退職しているため、当時の状況をトレースできないためだ。

◆マイナンバーで期待されること

ただ、マイナンバー制度によって、この問題について一定の解決が期待される。
マイナンバー制度とは、国民一人ひとりに一意に決まる番号を割り振り、その番号を用いて個人情報を管理し、一部の行政サービスで運用する仕組みである(※4)。法律の中身を読み解くと、マイナンバー制度の目的はおおむね2つある。

1、公平な給付と負担(払い過ぎ、払い漏れの防止)
2、行政サービスにおける利便性の向上(ワンストップ、プッシュ型サービスの実現)

である。

上記目的を実現する手段が主に 4 つ示されている。

1、組織内で個人を一意の番号で特定すること (マイナンバーの付番)
2、組織間の情報連携をオンラインで行えること(情報提供ネットワークシステム)
3、本人確認手段として使えること(個人カードの提供)
4、個人番号を安全かつ適正に管理すること(法整備・監査等)

制度導入直後の個人番号利用は、社会保障と税分野の行政業務に限定される見通しだ。将来的 には金融機関などの民間企業とのマイナンバーの共通利用も視野には入ると見られる。民間利用については、法律施行後3年をめどに、その段階での法律の施行状況等をみながら検討するとしている。国民に付与する個人番号(マイナンバー)の生成は、地方情報団体システム機構(JLIS:旧LASDEC)に委託される。自治体が発行した住民コードを JLIS 側に渡し、それをもとに個人番号を生成してもらう、という流れだ。

◆マイナンバー施行以降の「迷子の宛名」問題は

マイナンバー制度に基づいて、個人を識別する番号が付与されると、既存の宛名DB に、個人番号という列(カラム)を持つテーブルが追加されることになるだろう。窓口に生活保護の受給申請を行うBさんが訪れたとすると、Bさんのマイナンバーから、どのような行政サービスを利用しているのか、1年前にあるサービスを利用した時に対応した職員は誰か、などをすぐに追跡することができるはずだ(ただし、住登外者についての確認作業はおそらく、団体間の情報連携が開始される2017年1月以降を待たなければならないだろう)。

将来的には、宛名情報に起因していた窓口での対応の遅れやたらい回しなどが減る可能性がある。また、不正受給の問題などが減る見通しも立つ。「行政分野での公平な給付と負担」という目的に近づくわけだ。 ただ、マイナンバー施行前にすでに迷子になってしまっている宛名情報を名寄せできるかどうか、という問題は個人番号の導入だけでは解決できない(※5)。それを防止するためシステムの開発者は、既存の宛名情報の更新・整備と、マイナンバー制度開始後の宛名情報の名寄せのどちらにも目配りすることが必要になる。

そもそもデータを宛名 DB、もしくは部署・業務間をまたぐ統合宛名管理システムに入力するのは基本的に自治体の職員である。入力するタイミング(きっかけ)、入力される内容は、窓口を訪れた利用者の申請・申告内容によって左右される。常に、最新の情報が反映されている訳ではない(その年の1月1日時点の情報なのか、4月1日時点の情報なのか、などは宛名DBを確かめてみないことには分からない)。住登内者も数年ぶりに窓口に来たのであれば、それだけ宛名情報にタイムラグが生じていることになる。
窓口に訪れた利用者が節目節目で正しく自己申告していること、なおかつ、職員がそれを正しくシステムに入力していることが、宛名情報(データ)の真正性、信頼性を担保していることは、マイナンバーの施行前後で変わらない。

◆「きれいごと」では済まない現場

行政サービスの利用者が氏名を変更する理由は主に、結婚や離婚、養子縁組による改姓であることが多い。しかし、あえて窓口で本名ではない名前を告げることもある。DV 対策やストーカー対策でやむを得ず、素性を隠そうとしているケースもあるからだ。また、ホームレスの人が、住所を偽って行政サービスを申請することもある(住所不定ではサービスを受けることができない、等の場合がある)。
マイナンバー制度開始後も、来訪者がマイナンバーの記されたカードを所持していない場合は、従来通りの対応で行う「例外規定」が恐らく必要だろう。だとすれば、現状と同様の迷子の宛名ができる可能性がある。こうした運用上の問題は、制度開始後も宿題として残されるはずだ。

◆ワンストップ/プッシュ型の行政サービスの実現に向けた課題

マイナンバー制度の目的の一つに掲げられた、ワンストップ/プッシュ型のサービスの提供は果たして実現可能だろうか。 窓口にある人物が来て、「自分がどのようなサービスを受けられるか教えて欲しい」と職員に尋ねたとする。そこで適切な回答・提案を行うには、各種サービスの受給要件を満たしているかどうかを判別するために、数多くの事前情報が必要となる。住所、年齢、性別、傷病の履歴、職業、家族構成、収入状況等々。マイナンバー制度の施行前でも、現状の統合宛名管理システムを利用して宛名情報を横断的に検索する場合でも、作業は基本的に同じである。

仮に、人口千人規模の小さな基礎自治体であれば、業務横断的な知識と住民の顔をよく見知っている有能な職員がいれば、それなりに適切な回答や提案が行えるかも知れない。 だが、 50 万人を超える人口を擁する政令指定都市のような、大規模な自治体ではこのような人海戦術的なアプローチは事実上、不可能だろう。

ピースミール・テクノロジーでもシステム的な支援によって業務横断的な情報活用を可能にする対応策の実現を支援しているが、何でも業務横断で共有できればよいというわけではない。先述した DVやストーカーから身の安全を守る、といった「何らかの事情で」行政側が情報を見せない対応を迫られるケースもあるからである。システムの機能としての支援でどこまでを行い、残るシステム以外の部分での解決をどうするべきかを行政全体のサービス視点から慎重に検討しなければならない(※6)。

マイナンバー法に基づいて、さまざまなガイドラインも整備されているが、実務に即した内容になるかどうか、まだ不透明だ。たとえば、日本国籍を有する海外在住者に個人番号を誰がどのように通知するか、という点についてもガイドラインの策定待ちだ。制度開始後に、各自治体の現場はかなり混乱するのではないだろうか。
詳細が不透明な中、前向きに対応を進める自治体は多くないのが実情だ。大半の自治体は、様子見、もしくは現状の状況把握を進める段階に留まっている。団体間の情報連携も不透明な中で、行政サービスのワンストップ/プッシュ型サービス化については、青写真を描くことがまだ難しい段階だ。

●講演後の質疑応答より
Q: マイナンバーは、民間企業での活用も議論されている。たとえば、従業員の個人番号を企業側で把握し、労務管理などに役立てるなどの対応をする場合、番号の照会などについて自治体の協力が得られるだろうか。

A: まだ分からない、というのが実情だ。大半の自治体は何から着手すればよいか、現状を把握しようと努めている段階だと認識している。

Q: マイナンバー制度で割り振る個人番号について。住民基本台帳をベースにしている点に当初から疑問を持っている。住所不定者や海外への転出者も少なくない。しかし、戸籍の登録事項などをアンカーにしていれば対応は可能になる。今のスキームでは、異なる自治体に転出して、10年も経過してしまうと、データが抹消されてしまう可能性がある(自治体側に宛名情報の永久保存義務はない)。海外に転出して10年も経過すると、既存の宛名情報と紐付けられなくなる。給付と負担の公平性、という観点でも長くデータを持つ必要性があるだろう。法務省では戸籍とマイナンバーをどう結びつけるか、という議論がようやく始まった段階だ。

A: 税、福祉サービスなどの情報は、それぞれ縦割りになっており、10年以上保存されるものもあるし、そうではないものもある。たとえば、ある自治体に住んでいた人が、しばらく経ってから何らかの事情で再び住民として戻ってくる場合、基幹システム上からデータが失われ、また新たに宛名情報/住民コードが振り出され、JLISによって個人番号が新規に生成される可能性がある。こうなると別人扱いになってしまうだろう。こうしたケースは現状でも決して稀ではない(※7)。職員が所持するPCのExcel などに記録が残っていれば紐付けられるかも知れないが、残っていない場合、まっさらになってしまう。そのことを悪用し、別人になりすます可能性もある。
国民の情報を地方で分割管理するために、ある自治体から他の自治体で管理する住民情報が見えなくなっている。そのことが、宛名情報管理を複雑化させている。
合併などで新しく誕生したできた政令市のシステムをみると、旧自治体のシステムや宛名DBが統一されていないこともある。自治体のサービスについて不十分という指摘はしばしば聞かれるが、サービスの向上のためにシステム面も含めて、様々な努力をしているところは少なくない。システムやデータを最適化していく上で、 様々な事情や現行制度上の縛りがあることを是非知って頂きたい。

<脚注>
※1 住民基本台帳と戸籍
住民記録台帳のデータは選挙人名簿を作るための情報として元々作られている。家族関係・系譜がわかる戸籍とは利用の目的が異なる。戸籍を遡れば、近世に農民等の身分を寺社などが証明した宗門人別帳などにたどり着く。

※2 区(行政区)とは
行政区は、市の権限に属する事務を分掌させるために設けられたもので、 独立した地方公共団体ではなく、市の組織の一部となる( 地 方自治法第 252 条の 20 第 1 項の規定に基づく)。 したがって、独立した法人格を持つ「特別地方公共団体」である東京都の区(特別区)とは異なる。

※3 生活保護の不正受給
親族等になりすまして、不正受給をする事件もあった。家族には DV(ドメスティック・ バイオレンス)などのために連絡しないでほしいと窓口で偽り、職員による身元確認をさせないようにしていた、と見られる。

※4 マイナンバー制度
社会保障・税に関わる番号制度、共通番号制度、国民総背番号制度などの呼び名で報じられることが多い。政府発表のロードマップによると、2015年10月に市町村により個人番 号の付番が、翌2016年1月に地方公共団体内での番号利用が開始される。同年4月には 市町村が個人カードを交付する予定。2017年1月には団体間での情報連携開始、同年7月にはインターネットブラウザ経由で各種電子申請や情報連携履歴の確認が行えるようになる(マイポータルの開始)、という計画。

※5 データの真正性
マイナンバー制度開始前に生じた迷子の宛名を名寄せするには、職員などによる当事者へのヒアリングや足を使った実地調査がおそらく必要になる。

※6 DVやストーカー対策
番号制度だけで解決できる問題ではない。警察による取り締まりやシェルターの整備など総合的な対策が求められる。

※7 人口の社会増減と宛名情報
日本では、年間 5 万人程度が自治体間の転出入や自治体内の転居を行っている。こうした転出入・転居の発生は出生・死亡とあわせて、宛名情報を増加させている(データを削除しない限り)。人が動けばデータも動くということである。

(まとめ/エクリュ 柏崎吉一)

※本稿で使用した図版の著作権は、いずれもピースミール・テクノロジー社に帰属致します。

RELATED

PAGE TOP