[概論] BIツール導入のポイント

前提

• 複数の企業において、Tableauを主として導入・活用した経験があるため、特定の企業というよりは共通的な経験談になります。

  • インターネット・広告領域での話が中心です。

• 経験したシステム規模は、最大で数十人規模の利用は想定していますが、詳細な分析操作を行うヘビーユーザによる同時アクセスは10人ほどを想定しています。

  • ヘビーユーザとは、データ集計・分析に長けた人で、BIツールをガツガツ使い込む人を指します。

---

BIツールを導入する前に考えておきたいポイント

※BIツールも、Webサービスやアプリの企画や改善の考え方を流用できます。

• BIツールは作って終わりではなく、リリースした後に改善していく。

  • 改善のヒントは、まずは、BIツールの利用状況を可視化すること。
    • 例：Tableau Onlineでの管理者インサイトを利用した利用状況可視化

• BIツールを利用するユーザセグメントを設定する。

  • BIツールは全員に使ってもらう必要はない。
    • １担当者が、営業活動やCS業務からデータ集計・分析業務を完結させる必要が本当にあるのか？ はケースバイケース。組織規模によっては分業も検討すべき。
  • 大きくわけて、モニタリング、アナリティクスの用途に分かれて、利用ユーザセグメントも異なる。
    • 経営やマネジャー層がモニタリングとして使うダッシュボードと、企画担当者がアナリティクスとして使うダッシュボードは、異なる。
      • モニタリング用ダッシュボードでは、基本的なKPIを監視する。
        • 例：売上・予算ダッシュボード（月次の売上、予算達成状況を監視する。）
      • アナリティクス用ダッシュボードでは、すぐにアクションに繋がる指標であることが必要。
        • 例：広告媒体別効果ダッシュボード（効果が薄い媒体予算を、効果が高い媒体予算に振り替える。）
  • データの粒度によって、利用想定ユーザ数は変わる。
    • ユーザ数が多いケース：
      • 例：組織のKPIに紐づく様な代表的なデータ（起業した直後の会社でない限りはCSVファイルやExcelとして既に取得出来る状態になっている。そのため、BIツールで置き換えるインセンティブが弱い。）
    • ユーザ数が少ないケース：
      • 例：取得が難しいデータ、より細かい粒度のデータ、履歴が必要だがスナップショットしかないデータ。（現場などに要件ヒアリングに行くと良く出てくる。）

• BIツールの費用対効果(ROI)を見積もる。

  • 費用は計算できるが、効果は見積もりが難しい。
    • 売上向上の観点：
      • ダッシュボードを使った際の施策効果に一定の貢献度(1%とか？)をかけて具体的な売上で計算？
    • コスト削減の観点：
      • 担当者の今までのデータ集計業務の時間に対して、削減した時間と時給で計算？
  • ただし、ダッシュボード自体をプロダクトとすれば、直接的に売上に繋げられる可能性もある。
    • 自社が扱うデータを他社が使いたい場合などにビジネスチャンスがある。
      • 例：モバイル市場の各指標が確認できるAppAnnie

---

BIツール導入から改善までの流れ

1. 要件整理編

• トップダウン的アプローチと、ボトムアップ的なアプローチの両軸から攻めてみる。
  • トップダウン的なアプローチでは、業務プロセスやユーザー行動フローに紐作くKPIツリーから分解してみる。
    • 例：営業パイプライン(例：Salesforceのサンプルダッシュボード)、集客からコンバージョンまでのユーザー導線(例：アプリのKPIツリー)など。
  • ボトムアップ的なアプローチでは、要望の高いが見れていない指標やデータを洗い出す。
    • 例：最新のユーザー情報しかないが、過去からの現在までの更新履歴を可視化したい、など。

1. 導入編

• 最初は出来るだけ小さく安く試す。
  • データをGoogle Cloud環境で使えるようにできるなら、Google Data Studioが最初に試すには適切。
• もし、最初に無償のBIツールを使えない場合は、
  • データ未整備の可視化要望がある際に、データ整備とともにBIツールを導入して、BIツールを使うモチベーションにしてしまう。
  • Tableauを体験版で導入して、センスのある上司に見せて興味を引いてみるのも一手。
• BIツールは、セルフBIか、管理者のみが作れるBIで大別される。
  • セルフBI例：Tableau, PowerBI
  • 管理者BI例：Looker, Domo

1. 設計編

• 画面
  • TOP画面では一般的な指標を採用する。より深掘って分析したい人には、そこから詳細画面に遷移させる。
• データ
  • BI側に複雑な計算を持たせない。DataMartやDWHなどテーブル側で事前に計算を行うようにする。

1. 運用・改善編

• 利用状況をモニタリングして、要望者の利用実態をほぼリアルタイムで把握。使われない場合は、当初の要望部署へのヒアリング。
  • 例：Tableau Onlineでの管理者インサイトを利用した利用状況可視化
• セルフBIの場合、利用が増えてくるつれて、ダッシュボードやDataMartが乱立するため、作戦を持っておく。
  • 減らす観点：BIの利用状況から、使われていないと判断できる閾値を作って、自動アーカイブする。
  • 整理する観点：ユースケースとテーブル命名ルールを一致させる。
    • 例：dm _ (1.指標/KPI) _ (2.集計粒度) _ (3.集計day粒度) _ (4.集計期間)
      • dm_uu_app_day_last30days → 直近30日の、日次で、アプリ毎のイベント毎UUのデータが格納されています。

---

BIツール"Tableau"の紹介

ユースケース

• 管理者が作ったグラフを見るよりは、様々な軸で分析を行いたい人がいる。いわゆる、セルフBIを使いたい。
• DataMart(DM)を構築する基盤がある。

欠点

• [大]ユーザ側での加工を許容するため、データガバナンスが困難である。
  • Tableau上での独自計算フィールド作成により、作成者と意思決定者の間に認識齟齬が発生し、解釈がぶれる可能性がある。（例：消費税込み売り上げ）
  • この問題点は、組織内で独自Excelとマクロが乱立しているのと同じである。
• [中]データ自体の説明資料が別途必要になる。
  • カラムの意味、データの属性値、など。
• [中]組織内での利用拡大のためには、トレーニングやサポート体制の構築が必要である。
  • ピボット操作で簡単というUIのため、導入者側からすると、誰でも簡単に操作できると思う。しかし、独力で分析操作が出来るレベルに達するのは、5人に1人程である。

良く活用されていた機能

• フィルタ機能
  • 複数のフィルタを使う場合に、フィルタの優先順位をつけられる。
• LOD関数
  • 集計粒度をダッシュボードの粒度ではなく、任意の粒度に設定できる。
  • SQLでいうところの、Window関数に相当する。

導入した際の所感

• SQLを使わなくてもデータ操作が出来るため、企画部署内でデータ集計を完結できる場面が増えた。
• 玄人が計算フィールドなどを駆使してカスタマイズされまくったTableauは、他人が理解するのが辛い内容になる。
• Excel主流の現場では、完全にTableauに切り替えることは不可能という前提で考えた方が良い。
  • Excelに精通した人に、Tableauを習得させることが難しい場合は、業務が滞るリスクがあるため。

---

#Appendix

• 用語説明

  • DataMart(DM)
    • データ分析用の集約されたテーブル群です。特定のユースケース毎にテーブルを整備するため、ユースケースに沿った分析を行う場合には、BI側でのデータ加工を行う手間がほぼ不要になる利点がある。

• 参考になる資料

  • 事業のグロースを支えるDataOpsの現場 #DataOps #DevSumi #デブサミ / 20180727
    by yuzutas0
    • リクルートでのデータ活用の事例、改善プロセス、定着のための文化形成などが書かれた。データ集計・運用・活用業務に関する体系的な内容であり、一読すべき内容。