データマイニングを妨げる3つのアンチパターン
Water, water everywhere nor any drop to drink.
「どこもかしこも回りは水だらけ、なのに飲める水は一滴もない」
サミュエル・テイラー・コールリッジ（老夫水行）
はじめに
データマイニングは、当然ながらデータが無いとできません。そして、データマイニングにまつわる苦労はこのデータを用意する段階で発生することがほとんどです。
この苦労は、そもそもデータが無いというパターンと、大量のデータはあるが使うのは難しいというパターンに分かれますが、今回は後者、つまり使いにくいデータについて書こうと思います。
『マスタリング・データマイニング』[1]では、データ収集の難しさを海水に囲まれながら乾きに苦しむ老人の嘆きに例えて表現していますが、言い得て妙だと思います。
ビジネスの現場に大量にあるデータはそもそも後の分析を想定して蓄積されておらず、これをデータマイニングに適したデータにするには「前処理」と呼ばれる、海水から真水を生み出すようなプロセスが必要となるのです。
前処理は更に二つのフェーズに分けることができます。
まずデータマイニングに掛けられるところまでデータを整形するというフェーズ、それからデータマイニングの結果が良くなるように修正を繰り返すフェーズ。どちらも大変ですが今回は最初のデータ整形に注目します。
データマイニングに適したデータ、適していないデータ
データマイニングには色んな手法がありますが、どんな手法でもおおよそ一個の大きな表の形になるようにデータを整形していきます。行が分析対象で、列が分析に使う項目（変数）です。
例えば顧客を分析の対象とするなら、一行が一人分のデータになります。顧客の時間変化を見る場合は人×日の組や人×月の組を一行とすることもあります。
また、全ての変数には抜けが無い状態が望ましいです。
ところが、このような形式でデータが利用できることはまれです。通常必要なデータは複数のファイルに分かれているものですし、データが重複することや抜けがあることもしばしばです。
次からはデータ整形における問題を以下の3つに分類し、それぞれ考察していきます。
- データの分散
- データと現実の不一致
- データの欠損
1. データの分散
『顧客に関する情報は複数のファイルまたは情報システムにばらばらに格納されています。特に、顧客を特定するIDがそれぞれ別々に付けられているとそれら情報を紐付けることが困難です。IDが付けられていない場合すらあります。』
こうした問題は、部門毎に別々の顧客リストをもっているケースや、業務毎に異なる顧客情報管理を行っているケースで発生します。業務的にはそれで十分なのですが、後にデータの活用をしたいという要求が生まれたときに問題が表面化します。
最近では「シングルソース・データ」という、同じ人物に関する多面的なデータを一元的に扱う取り組みが見られるようになってきました。これから顧客情報管理を設計するのであれば意識しておくべきでしょう。
統一のIDを振っておくことや、1つの事実は1箇所にのみ存在、といったといったデータベース設計の原則にしたがうことが対策となります。
一方、既存の大量データをシングルソースとするには名寄せの問題があり、最後は手作業による紐付けが発生してしまうために活用が進まないということをよく見かけます。
かくいう弊社においても、SFAの顧客情報とサービス利用管理用の顧客情報と請求情報が別々のシステムにあるため、それら情報の紐付けには苦労していました。
なお、シングルソース・データを得るためのより積極的な技術として「データ融合」が注目されています。これについてはまた別のエントリで取り上げたいと思います。
2. データと現実の不一致
『記録されるデータには実態と一致しないものが含まれます。キャンセル済み、あるいは未来の日付で予約された取引がそうでないデータと混在しています。データが確定するタイミングにも注意が必要です。また、同じ顧客でありながら別のIDで登録しなおすという運用が頻発すると、顧客の貢献度や生存期間に対する分析がゆがんでしまいます。』
顧客の時間変化を予測する問題において、一行が例えば人×月の組み合わせとなるようにデータを整理することが必要です。
難しいのは過去のデータをその当時の状態として表現しなければならないという点です。そのため、キャンセル情報やその時点の予約情報は除外する必要がありますし、分析当月あるいは前月の情報はその時点で未確定なので使えないといったことが起こります。
IDが変わって再登録というケースは、例えば過去のIDを解約し新しいIDで再契約という形で起こりますが、そのままで扱って良いか、同じ顧客として名寄せすべきか、は場合によるため議論が必要です。
いくつか例を挙げましたが、見たままのデータが現実と一致しないということは様々な理由で発生します。もちろん業務上は全く問題がないのですが、業務を知らない第三者が分析のためにデータを扱うとはまってしまうポイントです。
この問題への対策は、業務を知っている人をいかに巻き込むかに尽きます。分析者はデータに対するあいまいな期待や思い込みを捨て、どういう意味をもったデータかしつこく確認しなければなりません。
3. データの欠損
『分析者が知ることのできないデータがあることに気づきます。あるヒアリング項目は一部の顧客にしか記録されていません。ある顧客は引越ししたので去年の住所が分かりません。注意深く探せば別のファイルからそういったデータが見つかることもあるでしょう。』
データが欠損する理由には、たまたまデータが登録されていないケース、ある条件ではそのデータを登録していないケース、上書きされて過去の状態が分からなくなるケースという3パターンが考えられます。
対処方法は、「データが無い」というデータだと考える、何か別の値で埋め合わせする、その変数を使わない、のいずれかになるでしょう。
こうした欠損の原因と対処法を判断するには、「2. データと現実の不一致」で述べたように業務を知っている人の協力が不可欠です。議論のなかで、場合によっては別のファイルから欠損したデータを補うことができるかもしれません。
例えばログファイルに変更前のデータが残っているとか、新規登録と更新が別の業務に分かれているので別のファイルに記録されていることが分かったりします。
一方、そうしたファイルから欠損したデータを補うことにはコストが掛かりますので、そのデータがどれほど重要かも考慮すべきでしょう。
おわりに
以上、データ収集にまつわる問題を3パターンに分けて考察しました。
新しく顧客情報管理システムを設計するならあらかじめ分析についても考えておくことが望ましいですが、大抵は後からデータの活用を考えるようになるので、データマイニングは前処理が9割などと言われるゆえんとなっています。
次回からは最初に述べたデータが無いケースを含め、データ収集にまつわる高度なトピックを扱おうと思います。
参考文献
[1] マスタリング・データマイニング＜理論編＞ ：マイケルJ.A.ベリー／ゴードン・リノフ 著
※記載されている内容は掲載当時のものであり、一部現状とは内容が異なる場合があります。ご了承ください。