顧客管理データのような企業自身が作り出したデータであれば、まだシステム設計レベルで改善の余地がある。ところが、これからの時代は、データ分析に利用されるデータが、政府統計やSNSのように、企業活動の外から集められる可能性がある。こういったデータを集めてなお品質の高いデータを整備するという作業は、片手間でまかなえるものではない。
「データ分析にかかる時間の8割は前処理に費やす」――。この言葉はもともと、ウェブページは大量の価値のない情報からなっているため、80%の前処理作業が必要、という言葉に由来しているようだ。一方、前述の名寄せやデータクレンジングといった作業は、ウェブページに限らずデータ分析において大部分を占めているのは間違いないだろう。
こういったデータの前処理は、システム統合などでやらざるを得ない場合もあり、運用上で人手によりメンテナンスされることもありうる。しかしながら、データ分析は必要に駆られて取り組む作業ではない。分析者が、人手ではあまりにも膨大なデータを前にして、分析のための前処理で手一杯になってしまうという事態もあり得る上、前処理を施すだけでは、分析のスタートラインに立ったことに過ぎないのだ。
前処理により、きれいなデータが完成したら、データ分析の次の一手はデータを分析に適した形式にする作業である。単純な集計のような分析であれば、選択（selection）・射影（projection）・結合（join）といったRDBの基本的な操作でまかなえることもあるが、カラムを分析に適切なレベルまで分解・結合するといった試行錯誤が必要になることも多い。
RDBの取り扱いに慣れているエンジニアには、データから知見を抽出するのに「試行錯誤」が必要であるという感覚に慣れておらず、マーケターのさまざまなデータへの要求や試行錯誤を面倒だと思うかもしれない。
この連載の初回でも述べたように「多くのマーケティング部門がデータを自在に取り扱うことができない」ことに起因する不幸だろう。
データの巨大化にともなう専門性
RDBのような比較的単純なデータ構造を扱うことは、実はそこまで高度なエンジニアリング技術を必要としない。マーケターであっても少しの訓練で対応できるような内容である。というのもマーケターが得意とする、Excelを代表とするスプレッドシートはRDBと同様にテーブル構造を持っているため、一旦RDBとExcelの対応がつけばあとは自分の領域でなんとか補えるまでになる。しかし世の中のデータが良いRDBだけで成り立っているかといえばそうではない。
直近の流行の話題でいえば、FacebookやTwitterに代表されるSNSのユーザー間のつながりを表したグラフ構造であったり、各ユーザーのアクティビティを集めた自然言語データのようなものは、従来のRDBで扱いづらいデータのひとつだ。また、IoT（Internet of things = モノのインターネット）から収集されるようなセンサーデータは、デバイスのリソース制約からデータ構造こそ単純ではあるが、その後のデータ活用のための、データ間結合や集計処理を考えると、一筋縄ではいかない。
