前提

複数の企業において、Tableauを主として導入・活用した経験があるため、特定の企業というよりは共通的な経験談になります。
- インターネット・広告領域での話が中心です。
経験したシステム規模は、最大で数十人規模の利用は想定していますが、詳細な分析操作を行うヘビーユーザによる同時アクセスは10人ほどを想定しています。
- ヘビーユーザとは、データ集計・分析に長けた人で、BIツールをガツガツ使い込む人を指します。

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

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

BIツールは作って終わりではなく、リリースした後に改善していく。
- 改善のヒントは、まずは、BIツールの利用状況を可視化すること。
  - 例：Tableau Onlineでの管理者インサイトを利用した利用状況可視化
BIツールを利用するユーザセグメントを設定する。
- BIツールは全員に使ってもらう必要はない。
  - １担当者が、営業活動やCS業務からデータ集計・分析業務を完結させる必要が本当にあるのか？はケースバイケース。組織規模によっては分業も検討すべき。
- 大きくわけて、モニタリング、アナリティクスの用途に分かれて、利用ユーザセグメントも異なる。
  - 経営やマネジャー層がモニタリングとして使うダッシュボードと、企画担当者がアナリティクスとして使うダッシュボードは、異なる。
    - モニタリング用ダッシュボードでは、基本的なKPIを監視する。
      - 例：売上・予算ダッシュボード（月次の売上、予算達成状況を監視する。）
    - アナリティクス用ダッシュボードでは、すぐにアクションに繋がる指標であることが必要。
      - 例：広告媒体別効果ダッシュボード（効果が薄い媒体予算を、効果が高い媒体予算に振り替える。）
- データの粒度によって、利用想定ユーザ数は変わる。
  - ユーザ数が多いケース：
    - 例：組織のKPIに紐づく様な代表的なデータ（起業した直後の会社でない限りはCSVファイルやExcelとして既に取得出来る状態になっている。そのため、BIツールで置き換えるインセンティブが弱い。）
  - ユーザ数が少ないケース：
    - 例：取得が難しいデータ、より細かい粒度のデータ、履歴が必要だがスナップショットしかないデータ。（現場などに要件ヒアリングに行くと良く出てくる。）
BIツールの費用対効果(ROI)を見積もる。
- 費用は計算できるが、効果は見積もりが難しい。
  - 売上向上の観点：
    - ダッシュボードを使った際の施策効果に一定の貢献度(1%とか？)をかけて具体的な売上で計算？
  - コスト削減の観点：
    - 担当者の今までのデータ集計業務の時間に対して、削減した時間と時給で計算？
- ただし、ダッシュボード自体をプロダクトとすれば、直接的に売上に繋げられる可能性もある。
  - 自社が扱うデータを他社が使いたい場合などにビジネスチャンスがある。
    - 例：モバイル市場の各指標が確認できるAppAnnie

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

要件整理編

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

導入編

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

設計編

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

運用・改善編

利用状況をモニタリングして、要望者の利用実態をほぼリアルタイムで把握。使われない場合は、当初の要望部署へのヒアリング。
- 例：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
  - リクルートでのデータ活用の事例、改善プロセス、定着のための文化形成などが書かれた。データ集計・運用・活用業務に関する体系的な内容であり、一読すべき内容。