普段の業務でどのようなデータを分析し、業務改善やサービス改善または意思決定に活用しているでしょうか。勘定系のデータや各種目標として設定するべき指標（KPI）の集計データなどを日々目にしていることが多いと思います。
例えば、営業系のKPIであればSalesforceなどのダッシュボードを目にするでしょうし、ウェブサイトのKPIであればGoogle AnalyticsやSiteCatalystなどのデータ。アプリの解析ではFirebaseやMixpanelなどを目にするでしょう。
これらは基本的には既に何らかのロジックで集計をされたデータなので、日々のモニタリングなどには向いていますが、何か検証をしようとしたり、探索的な分析を実施しようとしたりする場合には不向きな場合もあります。そんな時は自社のデータベースに蓄積されているデータを元に自分自身でさまざまなロジックで集計や分析をしたくなるものです。
しかし、ここで多くの企業で問題になる点は、「こういう分析したいけど、そのデータはどこにあるのか」ということです。
インフラ部門などデータマネジメントを担っている担当者に聞いてすぐにわかる場合もありますし、そもそもそのありかを知っている担当者を探すところからスタートするケースもあるでしょう。最近ではセキュリティインシデントによる企業ブランドの低下の事例も発生しているので、データへのアクセスを厳格に管理する企業が多いと思います。
セキュリティウォールが高くなれば高くなるほど利用者としてデータにアクセスするハードルは高くなるので、自社のセキュリティポリシーがどの程度なのかは把握しておくべきでしょう。
また、基幹系のデータではあまりありませんが、ウェブやアプリのログなどはそもそもデータを蓄積していないこともあります。そういう場合は根気よく計測の仕込みを依頼し、データが蓄積するまで待ちましょう。
さて、そのようなハードルを乗り越えてデータにアクセスできるようになった後に立ちはだかる問題があります。それはデータベースに蓄積されているデータの種類とマスタデータとの突合を実施するための関係性の把握です。
いわゆる実体関連図（ER図）のようなものがあれば、それをもとにリレーショナルを定義すればよいのですが、多くの場合、整備されていなかったり、そもそもそういったものがなく、直接データベースを触りながらエンジニアに確認しながら進めるといったことが必要です。
またリレーショナルデータベースマネジメントシステム（RDBMS）では、上記のような進め方でよいのですが、MongoDBなどキーバリューモデルを採用するNoSQLなどの場合はエンジニアに協力してもらわないとうまくいかない場合も多いです。関係部署とのリレーションも良好にしておかなければなりません。一般的にマーケティング部と情報システム部門はデータに対する考え方などの観点から敵対する傾向にあるようなので、この点は特に注意したいですね。これはデータを活用したいマーケティングと情報漏えいの可能性を少しでも減らしたい情報システム部門で考え方が異なるためです。
