ブログ

公開日：2022/12/15

前回、名寄せの前の段取りとしてデータ仕様の確認と整理、新たなルール設定、データの状況の確認と修正がまず必要であることをお話しました。
データ仕様の確認として重要なのはやはり項目設定です。データ運用で実際に利用する項目の統合も大事ですが、ここでは名寄せ（マッチング）用の項目の整理に話を絞ります。
個人を特定する項目として考えられるのは、氏名、住所、電話番号、メールアドレスの4つが一般的で、あれば生年月日、というところでしょうか。

氏名は、(A)姓と名を項目分けしている場合、(B)項目は一つだが姓名の間にスペースなどを挟んでいる場合、(C)姓名そのまま一本になっている場合、が考えられます。世帯寄せを想定している場合は(A)があるとそのまま利用できますが、個人寄せには(C)の状態のものが適しています。

住所はコード化した情報が入っている項目を用意するのが理想ですが、それについてはクレンジングの回にお話します。住所文字列として用意しておくとすれば、住所と建物は別項目に設定してしておいた方が便利ですが、入力の際になかなか守られず、境界線が曖昧な表記も多く、これについては推奨程度です。

電話番号は固定電話と携帯電話の混在をどう取り扱うかが問題となります。今や携帯番号を登録する方が主流ですが、蓄積期間が長いデータの場合は混在傾向になることが想定されます。項目が一つであれば時間軸によるデータの傾向として捉えるしかないですが、固定と携帯とで項目が二つ設定されている場合にどちらをどう使うかが悩みどころです。
統合するデータテーブルが三つあるとして、（A）項目は一つで固定・携帯の混在比率は半々、（B）項目は二つあり両方に番号が登録されている傾向にある、（C）項目は二つありどちらか一方には必ずセットされているが、片方か両方かは様々、となっていた場合にどうすべきでしょうか。
マッチ率を上げるためには両方の情報を活用すべきですが、項目を増やすとマッチング条件がその分複雑になります。そこでマッチング用のテーブルでは電話番号項目は一つにし、（B）と（C）は両方に情報がセットされている場合はもう一方を縦展開してレコードを追加（IDを含めた他の情報は同じ）、という方法も考えられます。この辺はデータの傾向によって様々ですのでやり方に絶対はありません。

メールアドレスも２項目設定されている場合、電話番号同様マッチング用のテーブルのレコードを縦展開させるのも手ですが、既に電話で展開済みの場合、メアドとの組み合わせでレコード数が2ｘ2に膨れ上がってしまいますのでそこはデータの状況次第です。項目は一つにして優先順位を決めてどちらかをセットする、というのも考え方です。最近はフリーメールのアドレスで登録されることが増えてきていますが、そうしたデータの傾向も踏まえて方法を決めるのがよいでしょう。

それ以外の項目として生年月日を例にあげましたが、生年月日が登録の必須条件である場合と年齢（層）確認程度のつもりとでは重要度が違ってきます。前者の場合はマッチングの判断材料の優先順位を高くしてもよいですが、後者の場合はマッチング後の補助的な判断材料程度にしておくのが現実的です。

まとめますと、マッチング用の項目はなるべく少なく、組み合わせもなるべくシンプルにまとめるのが理想、ということになります。

（つづく）