前提

- 複数の企業において、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ツリー)など。

　- ボトムアップ的なアプローチでは、要望の高いが見れていない指標やデータを洗い出す。
　　- 例：最新のユーザー情報しかないが、過去からの現在までの更新履歴を可視化したい、など。

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

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

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