クイック エンジニアリングブログ

株式会社クイック Web事業企画開発本部のエンジニアリングチームが運営する技術ブログです。

BIツールの元データ設計についてまとめてみた

こんにちは、BIKKAです。
これまでDWHチームの人(人?)という感じで職種名が定まらず、ふわふわやってきたのですが、最近データマネジメントチームのデータプランナーという称号を得ました!٩(๑❛ᴗ❛๑)۶
気持ちを新たに、社内のデータ活用に尽力したいと思います。

さて、今回のテーマはBIツールの集計に使う元データの設計です。

BIツールって意外と難しい

BIツール(ビジネスインテリジェンスツール)というと、膨大なデータをさくっと分析して意思決定ができる!というのが説明の定型句。
分析者自身がデータにアクセスして見たいグラフやリストをすぐに出せる、データ抽出者の作業量をぐっと減らせる、という夢のようなツールですが、そこまでたどり着くには分析者、データ抽出者共にBIツールを使いこなす努力が必要と感じています。

弊社でもマーケター用と営業部用、2つBIツールを導入しており、私自身はデータ抽出者としてBIツールを触るようになって半年くらいになりますが、ここまで

「BIツールに取り込むデータをどう設計したらいいかわからない…」
「元データを加工したもののBIツールにうまく読み込めない…」
「グラフの分析軸が思うように設定できない…」

と一つひとつのステップで丁寧に課題にぶつかってきました。

そして(今考えると)その度に一番最初、BIツールにデータ取り込む前の、元データを設計する段階に問題があったことに気づくことになります。

元データの設計は「事実」が入っているデータソースから「分析」の素材となるデータを作る重要なプロセスで、スムーズなデータ分析には欠かせません。
このプロセスを何とかノウハウ化したい…!

元データ設計のステップ

ということで、ひとしきり苦しんで「この順序で作れば割とスムーズにできるのでは」と思ったステップを紹介します。

1.作るグラフ/表のイメージをできるだけ具体化する

BIツールを使ったデータの可視化は以下のような流れで進みます。

  1. 元データの設計/加工
  2. 元データのBIツールへの取り込み
  3. データの定義決め(数値型、文字列型、日付型など)
  4. BIツール上でのグラフ/表の作成

が、最初に考えるのは最後に完成するグラフ/表のイメージです。

最初にグラフ/表を具体化するメリット

グラフや表のイメージを最初に具体的にする最大の利点は分析者が何のデータを見たいのか、そのすり合わせができる点です。

分析者が求めているのはグラフ/表という最終的なアウトプットであり、必ずしも「元データはこんな形がよくて、それぞれの項目はデータベースのこのカラムから取ってきていて…」とデータ加工のプロセスを把握している訳ではありません。
もしかしたらデータソースにはないデータや、重たい処理を含む可能性があり、依頼されたデータを本当に出せるとも限らないのです。
依頼を受けたタイミングを逃すと、次に分析者とすり合わせができるのは一通り作業を完了して、アウトプットを見せるタイミングです。
データ抽出者の作業をスムーズにするためにも、最初に

  • 分析者がどんな分析をすることをイメージして依頼したのか
  • 受けた依頼が本当に実現可能なのか
  • (不可能だったら)どういう代替案がありうるのか

を十分にディスカッションし、グラフや表のイメージを分析者と共有できるようにしましょう!
ちなみに前に行ったセミナーではアウトプットイメージのラフまで描いて依頼者とすり合わせているという方もいらっしゃいました。

グラフを構成する要素

具体化具体化と言ってきましたが、グラフは大きく、3つの要素で構成されています。
依頼者が出したいグラフをイメージしたときに

  • 縦軸:何をカウントするのか(①)
  • 横軸:何で分類するのか(②)
  • 系列:どうグループ分けするのか(③)

を明確にして元データの設計に移ります。

f:id:aimstogeek:20191004092247p:plain
グラフの最終イメージ

2.元データを設計する

上記の内容を元データの設計に反映します。
元データは集計対象・切り口・粒度の大きく3つの要素に分解することができると思っています。

f:id:aimstogeek:20191004111906p:plain
元データの設計イメージ

集計対象

先ほど出てきた中でいうと、①縦軸に該当します。数値型のデータが入ります。

切り口

②横軸③系列、両方です。こっちは文字列型や日付型です。
数値型の場合は読み込む際のデータ型に注意してください。

粒度

①-③の要素をもつ、最小単位です。
今回の例でいうと「いつ、どの商品が購入されたのか」がわかる購買データがあります。

粒度に関しては、①-③の要素だけで一意に決まる訳ではないので、

  • データソースに入っているデータ
  • BIツールが許容できるデータ量
  • 汎用性:今後作ると想定されるグラフへ流用できるか

との相談になります。

購買データなのか、ユーザーデータなのか、営業メンバーのデータなのか…粒度は「それが何のデータなのか」を定義します。
分析者や自分以外のデータ抽出者が利用することも考え、「●●のデータ」と一言でシンプルな名前をつけられる粒度を設定するのが理想だと思います。
作るグラフにあわせて集計/加工しすぎると、新たにグラフを作るときに扱いづらくなったり、別の人が集計するときに何のデータなのかがわかりづらくなったりする点に注意が必要です。

「全てのデータを入れるのは件数的に厳しい…」という場合は、直近2年分のデータに絞り込むなど、期間で区切るのがおすすめです。
すでに社内で出されているレポート≒今後BIツールで作っていくレポートなので、既存のレポートがどんな軸で抽出されているかを参考に決めましょう。

元データの設計で注意したいポイント

他に自分がつまづいたところ(抜粋)です。
全てのBIツールに共通する話とは限らないので悪しからず…。

できるだけデータを絞り込まない

商品A、B以外の商品の売上データがあるのであれば、最初は使わないとしても全ての商品のデータをあらかじめ入れておき、BIツール側で絞り込むのが楽です。

  1. 商品A、Bに絞り込んだ元データを使ってレポートを作る
  2. 他のレポートでその元データを利用する
  3. 後から「商品全体の売上でAとBってどれくらいの割合を占めるのか知りたい」と分析者から言われる
  4. 元データの絞り込みを解除し、これまで作った全てのグラフに「商品A、Bだけを表示する」絞り込みを入れる(結構大変!)

というように、「他のデータも含めた分析がしたい」という要望が発生することが想定できるからです。

数値型のデータのデータ定義に注意する

例えば購入された商品の個数別に購買データの数をグラフにしたい場合。

f:id:aimstogeek:20191004110232p:plain
売上個数別に購買の回数をカウントする

この場合、数値型で取り込むと自動的に集計対象と判定されてしまい、横軸(切り口)に使えないツールが多いようです。
数値型のデータだったとしても切り口で利用したいのであれば文字列型として読み込む必要があります。

また、同じ元データで同じ項目を集計対象と切り口両方で使いたい場合、↓のどちらかを採用することになるかと思います。

  • 1つの元データに集計対象用と切り口用に同じ項目を2つ用意し、それぞれ数値型、文字列型で読み込む
  • 集計対象と切り口を盛り込んだ別々の元データを準備し、数値型、文字列型で読み込んだ後にBIツール内で結合する

まとめ

世の中にはたくさんのBIツールが出回っていますが、共通点も多いはず。
私自身、sanameko先生に教えてもらいながら、少しずつBIツールの使い方を学ぶことができました。
今後は社内だけでなく、他の会社の同じ立場で悩む人たちとも情報共有ができたらうれしいなと思う次第です。



\\一緒に『明日のはたらくを創る』仲間を募集中です!! //

919.jp