データに付加価値を与える技術
はじめに
株式会社ナウキャストでデータエンジニアをしている沼尻です。
この記事では、私が担当している「マッピング」という業務についてご紹介したいと思います。マッピングと言われてもピンと来ないと思いますが、あまり語られることのない（それがゆえに何と呼称したらよいかさえ定かではない）データエンジニアリングの重要な一領域だと思っていて、他社さんにも類似する業務が存在するのではないかと思っています。この記事をきっかけにして、他社さんと情報交換や技術交流などができたら嬉しいですし、ひいては、将来的なマッピング（ないしその類似業務）に関する知識の体系化につながれば幸いです。
マネージャーやエンジニアの募集もしていますので、ご興味を持っていただけたら、この記事の最後に掲載している求人をご確認いただければと思います。
マッピングとは何か
ナウキャストでは、パートナーから様々なオルタナティブデータ（POSデータ、決済データ、クレジットカードデータ、人流データなど）のご提供を受けていますが、これらのデータはそのままでは活用できる形にはなっていません。そのため、様々な仕方でユースケースに応じた加工を施しています。例えば、個人情報を特定できないように匿名加工化した決済データの利用明細に、内製したマスタデータを紐づけてクライアントに提供している例があります。（データそのものを加工して分析用途で提供することもあれば、レポート業務を受託し社内で分析することもあります。）
このように、発生源の異なるデータを紐づけることをマッピングと呼んでいます。マッピングは、そのままでは分析に活用しづらいオルタナティブデータを分析可能なデータに変換する、まさにデータに付加価値を与える仕事です。
例として、決済データに関するマッピングの種類とユースケースを簡単に図示すると以下のような感じになります。
マッピングはどう作られるのか
「店舗名×ブランド」を例に、マッピングの作り方を説明します。
新規ブランド追加のフロー
新しいブランドを作りたい場合は以下のフローでデータを作成します。
- マスタリング
まず欲しいブランドのレコードを作成します。また、そのブランドに紐づけたい店舗名が含むだろうキーワードを作成します。 - マッチング
クレンジングした店舗名とキーワードを単純に文字列検索でマッチさせ、「店舗名×ブランド」のマッピングの候補を機械的に作成します。 - HI (Human Intelligence) チェック
マッピングの候補を人目でチェックし、OK/NGの判定結果をデータベースに登録します。「NGが多い＝キーワードが悪い」なので、必要に応じてマスタリングからやり直します。
新規店舗チェックと継続的な品質の維持
一度すべての店舗名に対してマッチングした後、そのブランドに紐づけるべき実在店舗が増えたり、既存店舗の店舗名が何かしらの理由で変わったりします。これらの「新規店舗」を継続的にマッチングしていかないと、ブランド毎の売上を時系列で見たときに、ある時点からの売上が欠損して見えてしまう可能性があります。このようなことが起こらないように、月に何回か、一度作成したキーワードと直近の新規店舗だけをマッチングさせ、HIチェックをしています。これを「新規店舗チェック」と呼んでいます。このように、マッピングは一度行ったら終わり、ではなく、品質を維持するための継続的な努力が不可欠です。
HIチェックとマシンマッピング
ブランド数が増えてくると、すべてのブランドについて人目で新規店舗チェックすることが現実的に厳しくなってきます。そのため、キーワード作成時のHIチェックの結果、精度がよかった（NGが無かった）キーワードについては、その後の人目での新規店舗チェックを省略できるようにしています。つまり、機械的なマッチングの結果をそのまま正しいマッピングとして採用します。このように（キーワード作成時を除いて）機械で完結するマッピングを「マシンマッピング」と呼んでいます。
リバイズ
一度作成したブランドやキーワードを作り直すことを「リバイズ」と呼んでいます。以下のようなイベントがトリガーになります。
- ブランドリバイズの主要トリガー
- 実世界でブランドの統廃合が起こったとき
- クライアントからブランド細分化などの要望があったとき - キーワードリバイズの主要トリガー
- ブランドリバイズに応じてキーワードも変更する必要があるとき
- 新規店舗が増えて既存キーワードの精度が悪くなってきたとき
クレンジングの例
マッチングの際に表記ゆれをある程度キャンセルするために店舗名とキーワードをルールベースでクレンジングしています。クレンジングのイメージを膨らませていただくために、わかりやすいルールの例をいくつかご紹介します。
キーワードの例
キーワードは、少ない数でより多くの店舗名がマッチするように作成されるため、ほぼほぼ正規表現で作成しています。またキーワードには、例えば下表のようにクレンジングで吸収しきれなかった店舗名の表記ゆれを吸収する役割もあります。
マッピングの体制
ナウキャストのマッピングチームには、マスタリング等を行うオペレータと私のようなエンジニア、そしてチーム全体を管理するマネージャーがいます。
- オペレーター（数名）
- マスタリング
- HIチェック - エンジニア（数名）
- オペレーターが使う業務システムの構築
- データ受領からデリバリーまでのパイプラインの構築
- デリバリー＝社内のデリバリー部隊に対するデリバリー - マネージャー
- 各所から上がってくる要望のハンドリング
- ステークホルダー（特にデータホルダー）との関係性構築
「オペレーター」という名前に慣れているのでこの呼称を使っていますが、業務内容としては決められたルールに則って正誤チェックするOperationの面だけではなく、元データの特性と（複数ある）ユースケースを睨んで最適なマスタをデザインし、何を正解（のマッピング）とするのかの基準を決める役割、つまりDevelopmentの面もあるため、「オペレーター」という言葉ではその職掌を表現し切れないとは思っています。
デリバリーという観点で見たときのマッピングチームを含む社内体制とステークホルダーの関係は、以下のようになっています。（※イメージです。）
- データホルダーユニット
データホルダーから受領したデータに最低限の加工を施してマッピングチームを含む社内の利用者に提供します。 - データコンシューマーユニット
データホルダーユニットが加工したデータをプロダクトに落とし込んでクライアント（データコンシューマー）にデリバリーします。
バージョンリリースとマッピングの品質保証
プロダクトサイドにいるマッピングチームとしては基本的に「現実世界の最新の状況を反映したマッピングデータを素早く提供したい」というモチベーションがありますが、クライアントに分析レポートを提供するアナリストには「過去の分析と前提条件を揃えたい」という気持ちもあり、マッピングに対する変更が必ずしも歓迎されない場合があります。そこで、下記のようなバージョニングを行っています。
- パッチバージョンアップ
新規店舗チェックによるマッピングの増加が含まれます。これをしないと、例えばあるブランドの売上を可視化した際に直近の売上が欠損してしまう可能性があります。日次バッチで自動的に実行されます。 - マイナーバージョンアップ
ブランドやキーワードなどのマスタデータの変更とそれに伴うマッピングデータの変更が含まれます。年数回、手動で実施します。 - メジャーバージョンアップ
データホルダーから受領したデータ自体への変更やバージョニングの仕組み自体を変更する場合など、上記以外の大きな変更をする場合はメジャーバージョンを上げます。
マイナーバージョンアップの際に、エンジニアが追加・変更があったブランドの売上の時系列データを可視化し、品質チェックをしています。この業務をEDA（Explanatory Data Analysis）と呼んでいます。一般的なEDAとは少し意味がズレていますがナウキャストの歴史的な経緯でそう呼んでいます。ただし、すべてのブランドをEDAすると大変なので、数より質が求められるユースケースで利用するブランドに限定してEDAをしています。
このように、マッピングデータを作るオペレーターだけではなく、エンジニアも品質保証プロセスに参加しています。
- オペレーターによる品質保証
店舗名とブランドや業種の文字列の目視確認によるマッピングの確からしさを保証 - エンジニアによる品質保証
（主に）ブランド毎の売上を可視化し売上系列に異常がないことを保証
そして、これらの品質保証において具体的にどのような品質項目をどのようにして保証するかについては、マッピングチームとデータコンシューマーユニットの間で合意した社内SLAにて定めています。
エンジニアリング観点で見たマッピングの特徴
Human In the Loop
筆者はデータエンジニアなので、基本的にすでに存在するデータを集めてガシャガシャしてユーザーに届けることを生業としてきましたが、マッピングのためのシステムの場合、データ受領からデリバリーの間にオペレーターによるマスタリングとHIチェックが介在するため、Human In the Loop なシステムになっています。その意味では、オペレーターは、AIの教師データを作成するアノテーターに似ているところがあります。
OLTP or OLAP
マスタリングだけを取るとOLTP的なので、RDBがあって管理画面がある一般的な業務システムのノウハウが生かせるのですが、キーワードで大量の店舗名を取ってきたり、EDAでトランザクションログを集計したりする必要があり、その場合はOLAP的な側面もあります。したがってデータベースとしてはRDB（Amazon Aurora）とDWH（Snowflake）を併用しています。ただ、サービスが跨っていてかなり非効率になってきているため、将来的には Snowflake Unistore への全面移行を検討しています。
データのバージョニング
マッピングは現実世界の変化に合わせてアップデートしていかなければならないため、バージョニングが不可欠です。そして、先に説明したように新規店舗チェックのようなパッチバージョンアップが存在するため、単純なスナップショットでは済みません。そのため、すべてではないですが、一部のマッピングデータについては、テーブルをGitのブランチに見立ててコミット・マージ・リリースを行っています。
- featureブランチ
- オペレーターの変更を即時反映するブランチ - stageブランチ
- EDAしたい変更を含むfeatureブランチをかき集めたブランチ - mainブランチ
- EDAしたデータをリリースするためのブランチ
このようなデータハンドリングの戦略を仮に「データブランチパターン」と名付け、あらゆるマッピングデータに適用できるデザインパターンとして定義できないか議論を重ねています。
マッピングはどういう場面で必要になるか
冒頭でマッピングを「発生源の異なるデータを紐づけること」と定義しました。（「異なるドメインで発生したデータを紐づけること」と言い換えてもいいかもしれません。）発生源が異なると、共通のIDがなかったり、同じ実体を指す名称項目はあるが表記ゆれが激しかったりするため、容易に２つのデータを紐づけることができません。そのようなときにマッピングが必要になります。マッピングが必要になるケースは、大別すると以下のようなパターンに分類できるかと思います。
複数の組織から上がってくるデータを取りまとめるとき:
- 組織ごとにデータ作成のシステムとプロセスが異なると当然表記ゆれが発生します
- また、組織が分かれていると、同じブランド体系を同じルールで店舗に付与する、みたいなことが実行困難になります
- 「複数の組織」は社外の場合もあれば社内の場合もあるかもしれません
- 例えば筆者が扱っているデータの一つにクレジットカードの利用明細がありますが、クレジットカード会社とそのカードが使える実際の店舗との間にはアクワイアラという別の組織が介在する場合があり、表記ゆれの補正とブランドのような属性情報の事後的な付与が必要になります
自社データとオープンデータやサードパーティデータを紐づけるとき:
- 商談を管理するシステムがあるとして、法人名は登録されているが法人番号がない場合に、政府のオープンデータから法人名と住所を使って法人番号を紐づけたい、みたいなケースが考えられます
おそらくこうしたマッピングが必要になるケースはすでに様々な企業の中で発生していて、あまり表沙汰になることはありませんが、マッピングに類するようなことをされている企業も多く存在するのではと思っています。また、自社データだけではデータ活用のオプションに限りがあるため、オープンデータやサードパーティデータと紐づけたいというような需要は今後さらに高まるのではないかと予想しています。
マッピングの類似概念
マッピングに類する業務をされている他社さんと話していると、業務はとても似ているのですが、呼び方が違ったりします。他社と会話する際にはまず、この辺りの用語の定義について認識を合わせた方がよさそうです。
クレンジング
類似概念としてよく出てくるのが「クレンジング」です。データ分析の前処理一般をクレンジングと総称しているのだと思いますが、その場合はマッピングはクレンジングの一工程になるでしょう。他方で、マッピングの前処理としても表記ゆれ等のクレンジングは必要です。筆者の見解としては、クレンジングは表記ゆれの補正やL2正則化、True-Falseを0–1に変換するなど、意味が変容しない程度の値の変換と考えていて、（異なるエンティティ同士を紐づける）マッピングはその中に納まり切らないのではと考えています。
名寄せ
「名寄せ」という言葉もよく出てきます。例えば店舗名だったり法人名だったりの表記ゆれ補正と考えてもらえればよいでしょう。名寄せしたら同じ値になる店舗名同士をマッピングしていると考えれば、確かに名寄せとマッピングは近い概念です。ただしマッピングの場合、店舗のような同じもの（エンティティ）同士をマッピングすることもあれば、店舗名とブランドのような異なるエンティティ間のマッピングもあります。前者を同一エンティティマッピング、後者をクロスエンティティマッピングと呼ぶとしたら、名寄せは同一エンティティマッピングという特殊な種類のマッピングといえるでしょう。
Labeling or Tagging or 分類
ナウキャストでは歴史的にマッピングという言葉を使っているのでそれに慣れていますが、ラベリングでもタギングでも分類でもよかったかもしれません。ただし、これらの場合は、ラベルとラベル付けされるもの、タグとタグ付けされるもの、分類するものと分類されるものの存在を暗に前提にしており、同一エンティティマッピングのような概念を内に含むことはできません。したがって、マッピングの方が概念として広く便利なのではと考えています。
LLMとマッピングの未来
最後に、LLMについても触れておきたいと思います。
マッピングはほとんど文字列操作になるため、LLMとの相性はよさそうに思えます。実際、筆者も「店舗名×業種」のマッピングをLLMで試してみた感じ、そこそこの結果を返してくれました。ただし、すべてのプロセスがLLMに置き換わるわけではなく、LLMが解ける問題に落とし込むまでの部分は引き続き人間が担うことになるでしょう。つまり、LLMを最大限活用したマッピング業務の未来は以下のようになるのではないかと考えています。
このように外注先が担っていた役割をLLMに置き換えた場合、以下のようなメリットがあると考えられます。
- 人のコストは上昇していくがLLMのコストは下がっていくため長期で見たらLLMの方がコストが安い
- 契約を交わすなど、組織を跨ぐことによる事務コストが不要
- 人数を集めたりタスクがない期間が生まれないようにアサイン調整したりみたいなことも不要
これにより、マッピングの生産性がスケーラブルになるでしょう。他方で、クリアしなければならない課題もありそうです。
- 人間と同程度には冪等なレスポンスを得るためのプロンプトの開発
- 品質を落とさずにスケーラビリティを最大限活用するためのレビュー体制の構築
- LLMに沢山マッピングさせることができるようになったとして、レビューする人数は簡単に増やせないため、品質を落とさないように対象をサンプリングしてレビューする仕組みを構築する必要がある
ナウキャストでは、目下これらの課題の解決に取り組んでいます。
仲間を募集中
ナウキャストのマッピングチームでは、一緒に働いてくださる方を常時募集しています。実はCEOがマネージャーを兼務しており（ベンチャーらしいですね）、専任のマネージャーを一番優先度高く募集しています。
もちろん、データエンジニアも募集中です。
冒頭にも書きましたが、社外の「仲間」も募集中です。マッピングと似たことやってるよみたいな企業の方がいらっしゃいましたら、苦労を共有したいので是非お声がけください。絶対に仲良くなれると思います。
最後まで読んでいただきありがとうございました！
