番号法施行へ向けて、改修仕様の確認と移行作業確認（平成26年04月〜平成26年06月）が必要である。PIA（特定個人情報保護評価）と並行作業が予定される。
　今回は、この内中間サーバへの登録更新に当たり、宛名データのクレンジング作業の短縮化についての方策を検討してみる。

（前回より）

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
○WBS（大日程）案
1．体制づくり
2．制度・条例など改正と新規作成（平成26年度）
3．情報システムの改修と新規開発
　　＊PMO設置（PM体制確立、ベンダーとの役割分担）　・・・　平成26年04月〜
　　1．改修仕様の確認と移行作業確認（平成26年04月〜平成26年06月）
　　　　1．住基システム
　　　　　　　住民コード（利用者コード／宛名番号）と「機関符号」の関連付け
　　　　　　1．住基システム異動処理（第1次）
　　　　　　　　「番号」取得、入力系・検索系・出力系（住民票など）
　　　　　　2．住基システム異動処理（第2次）
　　　　　　　　「機関符号」取得、入力系　ー＞　「機関符号」との関連付け
　　　　2．宛名システム
　　　　　　　宛名番号と「機関符号」の関連付け
　　　　　　1．住民登録外　「番号」&「機関符号」取得　＜−　データクレンジング！
　　　　　　2．法人・事業所　「法人番号」&「符号」取得
　　　　　　3．住登外宛名DBの生成（住民登録外　＋　法人・事業所）
　　　　　　4．「統合宛名DB」の生成
　　　　　　5．連携インターフェース
　　　　3．中間サーバ　宛名番号と「機関符号」の関連付け
　　　　　　＊導入・運用形態の決定
　　　　　　1．提供情報のフォーマットの全国統一
　　　　　　2．文字コードの全国統一

2．9条関連事務（別表1、個別条例事務）　・・・　平成28年01月〜
　＜ー　「番号」利用事務
　　　　　・・・　（平成26年07月〜平成27年09月）
　　　　1．住基システム改修（第1次）
　　　　2．入力系・検索系・出力系システム改修
3．19条7項（別表2）関連事務　・・・　平成29年07月〜
　＜ー　「番号」提供事務
　　　　　・・・　（平成26年07月〜平成28年06月）
　　　　総合運用テスト　平成28年07月〜平成29年06月
　　　　1．住基システム改修（第2次）　・・・　（平成28年01月〜12月）
　　　　　　1．関連付けDB（「変換DB」）　−＞　統合宛名システム
　　　　　　2．第1次改修　・・・　（平成26年07月〜平成27年09月）
　　　　　　3．第2次改修　・・・　（平成28年01月〜06月）−＞　第一次か？
　　　　　　　　1．異動処理（出生、転入等）
　　　　　　　　2．検索処理
　　　　　　　　3．統合宛名DB更新処理、中間サーバへの登録更新処理
　　　　2．税務・宛名システム改修
　　　　　　1．宛名システム　・・・　（平成26年10月〜平成27年09月）
　　　　　　　　1．住登外個人システム（データクレンジング作業含む。）
　　　　　　　　2．法人事業所宛名システム（データクレンジング作業含む。）
　　　　　　　　3．住登外宛名システム改修と再生成
　　　　　　　　4．統合宛名DB更新処理、中間サーバへの登録更新処理
　　　　　　　　　　　　　　　　　　　　　（フォーマット変換含む）
　　　　3．「マイポータル」へのプッシュ型情報登録更新
　　　　　　　・・・　（平成28年04月〜12月）
　　4．人事・給与システム　・・・　平成26年07月〜平成27年12月）
　　5．その他
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
（以上）

○3−1−2　宛名システム
1．宛名管理の統一
　市町村においては、宛名番号がキー情報となり業務システムが運用されている。番号法施行後においても問題なく運用される。

　特定個人情報の連携は、「機関符号」がキー情報となることが求められている。
中間サーバには、「機関符号」と「宛名番号」を紐づける必要がある。この関係は1：1である。

2．既存共有宛名DBには重複して個人（法人）が存在する。
・既存共有宛名DB
　ー＞　住民登録　＋　（住民登録外　＋　法人事業所）

・住民登録コード（宛名番号）の重複登録の例
　1．再転入
・住民登録外コードの登録　・・・　組織ごとに付番している場合に重複登録が見られる。
（2．死亡・転出など　ー＞　住民登録外）
　3．住民税（均等割）／家屋敷所有者
　4．固定資産税／住民登録外所有者
　　　　　　　　／共有者（代表者××他○名など）
・法人事業所コードの登録
　5．住民税特別徴収義務者
　6．法人住民税／法人
　7．固定資産税／法人事業所所有
　8．軽自動車税／法人事業所所有

○共有宛名DBの現状

＜共有宛名DB＞

（注1）
・最新住民登録住民の宛名番号を代表宛名とする！
（注2）
・転出・死亡など直前の宛名番号を代表宛名とする！
（注3）
・ＸＸＸさんの個人番号取得作業が“データクレンジングの中心！”

3．重複する個人データの整理
・課題と対応
　1．宛名管理を特定の既存システムに集約
　−＞
　複数の宛名管理の内から特定の既存システムに集約する。
　−＞
　個人番号：宛名番号＝1：1

　2．新たに統合宛名管理システムを構築
　−＞
　既存業務システムの宛名管理はそのまま存続させる。
　統合宛名管理システムで、名寄せ、紐付け関係を管理し。宛名管理を集約する。
　−＞
　個人番号：宛名番号：個別業務宛名＝1：1：ｎ

　3．連携インターフェース（代表宛名番号方式）　・・・　参照1
　連携インターフェース（代表宛名番号方式）DBを介して中間サーバへ登録。この方式は重複する個人宛名データの整理が不要となる方式です。
　個人番号：宛名番号：個別業務宛名＝1：1：ｎ

＜連携インターフェースDB＞

・対応策
1．宛名管理の統一（統合宛名）
2．中間サーバへの登録更新（フォーマット変換など）
　−＞　連携インターフェースDBを介して中間サーバへ登録

○中間サーバへの登録更新　・・・　参照2

　「個人番号＋組織識別子」　を可逆暗号　−＞　「機関符号」を生成

＜中間サーバ＞

　次回は、これら連携インターフェース（代表宛名番号方式）方式にて、情報提供ネットワークを通じた、特定個人情報の提供が実現できることを確認してみたい。（exの1〜6の事例）
　PIA作業についても、できる限りの工数短縮の方式を考えることが必要かもしれない。
　再来年9月までに、確実に第一次改修が完了しておくことが最重要である。

平成25年12月05日