Septeni Japan株式会社でプロダクト開発のエンジニアをしている工藤です。
私が所属する開発チームではデータエンジニアリング領域の業務を行っております。
この記事では、データクレンジングや名寄せの基礎的かつ実践的な方法について知りたい方向けに内容をまとめました。
はじめに
昨今、デジタルトランスフォーメーション（DX）の重要性が高まっており、企業におけるデータ活用の動きが加速しています。
特に、人材データの活用を積極的に検討する企業が増えていますが、その一方で、データ統合の課題に直面している企業も少なくありません。
本記事では、従業員データの統合を一例にデータクレンジングや名寄せの具体的な処理方法を解説します。
なお、実務ではデータクレンジングや名寄せのルールの策定が大きな課題となりますが、本記事ではルールが既に決まっている前提で進めます。（具体的なルールはそれぞれ後述します）
統合ルールの策定のプロセスや、システム全体の設計に関する詳細な議論は範囲外としています。
実際にあるデータ統合の課題例
ここでは、以下の2つのシステムを例に考えてみます。
システム1：人事管理システム
- 入社時に登録された基本情報（氏名、住所、電話番号、生年月日、部署など）をバックオフィスで管理している
| 従業員ID | 氏名 | 住所 | 電話番号 | 生年月日 | 部署 |
|---|---|---|---|---|---|
| 0001 | 桃太郎 | 川の近く1-1 | 080111XXXX | 1534-06-23 | 人事部 |
| 0002 | 竜宮太郎 | 竜宮城2-2 | 080222XXXX | 1537-03-15 | 営業部 |
| 0003 | かぐや姫 | 竹3-3 | 080333XXXX | 1521-12-01 | 営業部 |
| 0004 | 一寸法師 | お椀4-4 | 080444XXXX | 1530-02-18 | 開発部 |
| 0005 | 赤ずきん | 森5-5 | 080555XXXX | 1522-06-14 | 開発部 |
システム2：社内ポータル
- 従業員が自分でプロフィール情報（氏名、住所、電話番号、部署、スキルセットなど）を入力・編集できる
- ニックネームや略称を使うケースがあり、正式な人事情報とは異なる表記になっていることもある
- ログイン情報を忘れてアカウントを作り直す従業員もいる
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000001 | 桃太郎 | 川の近く1-1 | momo@example.com | 080-111-XXXX | 鬼退治 | |
| 00000002 | 浦島太郎 | 海の近く2-2 | urashima@example.com | 080-222-XXXX | 亀助け | |
| 00000003 | かぐや 姫 | 竹3丁目3番地 | kaguya@example.com | 080(333)XXXX | 竹取 | |
| 00000004 | 一寸 法師 | お椀4-4 | issun@example.com | 03-666-XXXX | 080-666-XXXX | 巨大化 |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080-222-XXXX | 玉手箱 |
この2つのシステムを統合し、1人の従業員に関する情報を一元的に扱えるようにすることがミッションです。
例えば、部署とスキルセットをまとめて確認できれば、適材適所なアサインが可能になりますよね。
きびだんごで完全成功報酬型リクルーティングをこなす桃太郎は最強の人事
具体的なプラクティス
データクレンジングとは
データをキレイな状態に変更することを言います。
何をもってしてデータがキレイと判断するかは目的によって異なりますが、
今回は2つのシステムのデータを比較して同じものを見つけたいので、同じものを表しているデータが同じ形になっていればキレイと言えます。
それぞれのシステムのデータを確認すると、同じ従業員を表すはずの項目に以下のような不一致がありキレイではないと言えます。
氏名にスペースがあったり、住所に行政区画が含まれていたり、連絡先がカッコで区切られていたりします。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000003 | かぐや 姫 | 竹3丁目3番地 | kaguya@example.com | 080(333)XXXX | 竹取 | |
| 00000004 | 一寸 法師 | お椀4-4 | issun@example.com | 03-666-XXXX | 080-666-XXXX | 巨大化 |
今回は「登録値が揺らいでいる項目は何か、各項目においてどういうフォーマットに揃えるか」に基づいて加工を行います。
名寄せとは
データのマッチングのことです。
今回の場合は同じ人物のデータを紐付け、統合することを指します。
それぞれのシステムのデータを確認すると、同じ人物に思われるレコードが別に分かれています。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000002 | 浦島太郎 | 海の近く2-2 | urashima@example.com | 080-222-XXXX | 亀助け | |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080-222-XXXX | 玉手箱 |
氏名や住所は異なりますが、メールアドレスや電話番号が一致しているため、おそらく同じ人物でしょう。
今回は「どの項目をキーに2つのシステム間で同一人物と判定するか」「どの項目をキーに同一システム内のレコード間で同一人物と判定するか」に基づいて処理を進めます。
データ統合ロジック案
以下は一例のロジック案です。
データ統合を進めるには、まずルールを適用して処理を進めることが必要です。
本章では、具体的な処理方法を解説した後、次章でルールを見つけ出す作業の重要性について触れます。
（１）各システム間でデータクレンジングを行う
最終的に名寄せで比較するために、まずデータを一貫性が保たれ比較や統合が可能な状態にします。
システム1のデータとシステム2のデータとが同じ形式になれば良いので、システム2のデータの形式をシステム1に合わせます。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000001 | 桃太郎 | 川の近く1-1 | momo@example.com | 080-111-XXXX | 鬼退治 | |
| 00000002 | 浦島太郎 | 海の近く2-2 | urashima@example.com | 080-222-XXXX | 亀助け | |
| 00000003 | かぐや 姫 | 竹3丁目3番地 | kaguya@example.com | 080(333)XXXX | 竹取 | |
| 00000004 | 一寸 法師 | お椀4-4 | issun@example.com | 03-666-XXXX | 080-666-XXXX | 巨大化 |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080-222-XXXX | 玉手箱 |
このテーブルをシステム1と比較するために、今回は以下のルールでデータクレンジングを行います。
・氏名の間の全角・半角スペースを取り除く
・「丁目」を半角ハイフンに置換、「番地」を取り除く
・連絡先1、2の半角ハイフンや半角括弧を取り除く
するとシステム2のデータは以下の様になります。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000001 | 桃太郎 | 川の近く1-1 | momo@example.com | 080111XXXX | 鬼退治 | |
| 00000002 | 浦島太郎 | 海の近く2-2 | urashima@example.com | 080222XXXX | 亀助け | |
| 00000003 | かぐや姫 | 竹3-3 | kaguya@example.com | 080333XXXX | 竹取 | |
| 00000004 | 一寸法師 | お椀4-4 | issun@example.com | 03666XXXX | 080666XXXX | 巨大化 |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080222XXXX | 玉手箱 |
（２）各システム内で名寄せを行う
クレンジング後のシステム2ですが、同一人物っぽいレコードが存在します。
改姓と引越しがあったのかもしれません。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000002 | 浦島太郎 | 海の近く2-2 | urashima@example.com | 080-222-XXXX | 亀助け | |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080-222-XXXX | 玉手箱 |
今回は以下のルールを適用し、同一人物のレコードをくっつけます。
・システム2においてメールアドレスが同じであれば同一人物とする
→同一人物と判定された場合、ユーザーIDが大きいレコードを最新とみなして採用する
今回の処理は、名寄せの理想的な統合処理とは異なり、項目単位の比較ができないという制約の中で、実務的な対応として代表レコードの選定にとどめています。
本来、名寄せは、氏名・住所・連絡先など各項目ごとに情報の新旧や信頼性を精査し、より正確なデータを項目単位で選択・統合するのが目的です。
しかし今回のデータでは、各項目に個別の更新日時や更新履歴が記録されていないため、レコード単位で優劣を判定し、ユーザーIDが大きいものをより新しいレコードとみなして採用しています。
するとシステム2のデータは以下の様になります。
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000001 | 桃太郎 | 川の近く1-1 | momo@example.com | 080111XXXX | 鬼退治 | |
| 00000003 | かぐや姫 | 竹3-3 | kaguya@example.com | 080333XXXX | 竹取 | |
| 00000004 | 一寸法師 | お椀4-4 | issun@example.com | 03666XXXX | 080666XXXX | 巨大化 |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080222XXXX | 玉手箱 |
（３）各システム間で名寄せを行う
両システムのレコードが同じフォーマットになり、各システム内で名寄せされたので、各システム間での名寄せを行うことができそうです。
システム1の元テーブル
| 従業員ID | 氏名 | 住所 | 電話番号 | 生年月日 | 部署 |
|---|---|---|---|---|---|
| 0001 | 桃太郎 | 川の近く1-1 | 080111XXXX | 1534-06-23 | 人事部 |
| 0002 | 竜宮太郎 | 竜宮城2-2 | 080222XXXX | 1537-03-15 | 営業部 |
| 0003 | かぐや姫 | 竹3-3 | 080333XXXX | 1521-12-01 | 営業部 |
| 0004 | 一寸法師 | お椀4-4 | 080444XXXX | 1530-02-18 | 開発部 |
| 0005 | 赤ずきん | 森5-5 | 080555XXXX | 1522-06-14 | 開発部 |
システム2のクレンジング後テーブル
| ユーザーID | 氏名 | 住所 | メールアドレス | 連絡先１ | 連絡先２ | スキルセット |
|---|---|---|---|---|---|---|
| 00000001 | 桃太郎 | 川の近く1-1 | momo@example.com | 080111XXXX | 鬼退治 | |
| 00000003 | かぐや姫 | 竹3-3 | kaguya@example.com | 080333XXXX | 竹取 | |
| 00000004 | 一寸法師 | お椀4-4 | issun@example.com | 03666XXXX | 080666XXXX | 巨大化 |
| 00000005 | 竜宮太郎 | 竜宮城2-2 | urashima@example.com | 080222XXXX | 玉手箱 |
今回は以下のルールを適用します。
・システム1、2において氏名・住所が同じであれば同一人物とする
すると名寄せ後のデータは以下になります。
| 従業員ID | ユーザーID | 氏名 | 住所 | 電話番号 | 生年月日 | 部署 | メールアドレス | 連絡先1 | 連絡先2 | スキルセット |
|---|---|---|---|---|---|---|---|---|---|---|
| 0001 | 00000001 | 桃太郎 | 川の近く1-1 | 080111XXXX | 1534-06-23 | 人事部 | momo@example.com | 080111XXXX | 鬼退治 | |
| 0002 | 00000005 | 竜宮太郎 | 竜宮城2-2 | 080222XXXX | 1537-03-15 | 営業部 | urashima@example.com | 080222XXXX | 玉手箱 | |
| 0003 | 00000003 | かぐや姫 | 竹3-3 | 080333XXXX | 1521-12-01 | 営業部 | kaguya@example.com | 080333XXXX | 竹取 | |
| 0004 | 00000004 | 一寸法師 | お椀4-4 | 080444XXXX | 1530-02-18 | 開発部 | issun@example.com | 03666XXXX | 080666XXXX | 巨大化 |
| 0005 | 赤ずきん | 森5-5 | 080555XXXX | 1522-06-14 | 開発部 |
一旦ここまでできれば先述の「1人の従業員に関する情報を一元的に扱えるようにする」ミッション達成です。
「部署とスキルセットをまとめて確認」することが可能になりました。
さらに他システムと統合する際や一元管理可能になったデータに対する機能追加などの拡張性を高めるために、各レコードに一意の統合IDを付与する、必要なデータだけに絞って保存する、といった対応もお勧めします。
お爺さんになるまで寄り道から帰ってこない浦島太郎は最弱の営業
今回の様なケースで必要な名寄せ・クレンジングのルールの判断基準
ここまで駆け足でミッションを達成してきましたが、実際の現場では、これほどスムーズに進むことはほとんどありません。
その理由は、各ステップで適用する「ルール」が事前に決まっているケースはほとんどないからです。
現場では、ルール自体をゼロから検討する必要があり、その際には
- システム運用者へのヒアリング
- データの現物比較
- 名寄せの試行とマッチ率の確認
といった、地道で丁寧な作業の積み重ねが求められます。
今回のような従業員データでのケースを一例にポイントを整理します。
従業員データ統合ルールを決める際に考慮すべきポイント
-
統合後のテーブル構成をどう設計するか
└ どのような業務で活用するかを想定し、必要なカラムや構成を決めます。 -
登録値が揺らぎやすい項目と、その標準フォーマットの定義
└ たとえばスペースの除去や表記の統一など、実装しやすく再現性の高いルールを優先することが一般的です。 -
2つのシステム間で同一人物とみなすための判定キー
└ 氏名・住所・電話番号などのうち、どの組み合わせが信頼できるかを検討します。 -
同一システム内の重複レコードの判定方法（名寄せルール）
└ 実際に結合して件数やマッチ率を確認しながら、現実的で効果的なルールを探ります。 -
同一人物と判定されたレコード間で値が異なる場合の優先順位
└ どちらのデータがより信頼できるか（例：人事システムの方が正確、更新日が新しい方を優先、など）を明文化します。
さいごに
名寄せやデータ統合の作業は、一見すると地味で手間のかかる裏方仕事です。
ただ私たちのようにインターネット広告事業に携わっていると、こうした作業の重要性を日々痛感します。
広告媒体のデータは、媒体ごと・キャンペーンごと・担当者ごとにフォーマットも粒度もばらばら。
案件や配信先が多岐にわたる中で、「このレポート、どこまでが同一キャンペーン？」「媒体Aのこの指標、媒体Bだと何に相当する？」といった混乱は日常茶飯事です。
だからこそ、バラバラに散らばったデータを拾い集めて、ルールを決めて、意味のある形に整理していく作業は非常に価値があります。
そういう泥臭くても整える作業が楽しい人、「散らかったものをきれいに揃えたい」「このデータ、もっと見やすくならないかな」と感じる人には、データエンジニアという仕事はとても向いていると思っています！
情報は一元化してこそ価値を持つ。適切に変換し、使える知恵へ。
Discussion