今回はTableauダッシュボード構築を成功させるために、ダッシュボード構築前にチェックすべきことについてまとめてみたいと思う。
私はこの数年、Tableauコンサルタントとして上場企業やベンチャー企業など様々な企業のダッシュボード構築をしてきた。
この経験の中で強く思うのは、「そもそもダッシュボードは使われなければ意味がない」ということだ。
しかし、数多くのプロジェクトに参加する中で、ダッシュボード構築前に必要な確認が漏れていたため、炎上して頓挫したプロジェクトやダッシュボードを作り上げることしか考えてなかったため、結局使われないダッシュボードが作成された、、、という残念なダッシュボードをいくつも見てきた。
本記事ではそういう残念なダッシュボードになる可能性を減らすために、ダッシュボード構築前にチェックすべきポイントについてまとめていく。
Contents
ダッシュボード構築前にチェックすべきこと
ダッシュボード構築の依頼を受けたら、必要な情報を提供してもらい整理する必要がある。
私の経験上、使われないダッシュボードが作られたり、プロジェクトがうまく進まない大きな原因の1つとして必要な情報を整理せずにダッシュボード構築を進めてしまう点があると思う。
私が通常、ダッシュボード構築前に確認することは下記の通りだ。
- ダッシュボードの目的
- ダッシュボードを利用するユーザー
- ダッシュボードを見た後に行うアクション
- データソース
- データソースのアクセス権限付与依頼
- 照らし合わせるべきデータ（ファイル）の共有依頼
- データの表示期間
- データの更新頻度
- ダッシュボードのサイズ
1つずつ確認していこう。
ダッシュボードの目的
まずはダッシュボードの目的だ。
ダッシュボードを作るのはどんな目的のためのなのか？を明確に確認しておく必要がある。
目的としては例えば下記のようなイメージだ。
- 「会社全体の売上・利益傾向を把握するため」
- 「各店舗の集客状況を比較してチェックするため」
- 「製品の工程履歴を可視化するため」
この目的が曖昧なままダッシュボード構築を進めてしまうと、
「作ったはいいけど、これって何のために使うの？」
「見た目は良いんだけど、全然使えない、、、」
というダッシュボードが出来上がる可能性が高くなる。
ダッシュボードの目的はダッシュボードの見せ方を迷った時に
「この目的なら表形式よりグラフ形式の方が良さそうだな。」
と判断基準にもなるので、是非確認しておきたい項目だ。
ダッシュボードを利用するユーザー
ダッシュボードを見るユーザーが誰なのか？という点も非常に大事な確認項目だ。
経営層が見る場合と現場の担当者が見る場合では求められるダッシュボードの粒度は大きく異なる。
経営層であれば、会社全体あるいは部署ごとの粒度で売上や利益の推移を見て会社としての傾向を確認したいはずだ。
一方で現場の担当者は会社全体の売上傾向を確認しても日々の業務では役に立たない（もちろん把握しておくべきではあると思うが、、、）
それよりも自店舗の売上を確認出来たり、商品ごとの売上傾向を確認できる方がよっぽど役に立つダッシュボードになるはずだ。
ダッシュボード構築の依頼者がダッシュボードを利用するユーザーであれば、特に問題ないと思う。
しかし、経営層からダッシュボード構築依頼を受けた場合など依頼者とプロジェクト進行の窓口となる人が異なる場合は要注意だ。
基本的に経営層がダッシュボード構築プロジェクトの責任者になることは多くないので、現場の責任者が窓口になったりする。
そのような場合に、窓口である現場の責任者の観点を考慮してダッシュボード作成を進めてしまって、ある程度完成してから経営層に見せたら
「そんな細かい粒度では使い物にならない。作り直せ。」
と言われてしまう、、、という事態が起こりうる。
こういう事態を避けるためにもダッシュボードを利用するユーザーは誰なのか？は把握しておきたい。
ダッシュボードを見た後に行うアクション
ダッシュボードを見た後に行うアクションを確認することも非常に重要だ。
ダッシュボードで数値を確認しても
「ふ～ん、売上が前日より10万円多かったのか。よかったよかった。」
と思うだけで何もアクションしないのであれば、正直あまり意味がない。
ダッシュボードを見ることにより、次のアクションに繋げられることが大事だ。
アクションというのはどういうものかというと、例えば、下記のようなものだ。
「店舗ごとの売上推移のダッシュボードを分析して、売上が芳しくない店舗に原因のヒアリングを行う。」
「日別の売上推移ダッシュボードを確認し、売上推移に応じて次のキャンペーン施策を検討する。」
「サービスの利用分析ダッシュボードで利用率の悪いユーザーをピックアップし、その原因のヒアリングを実施して機能改善につなげる。」
このアクションとダッシュボードの目的次第でダッシュボードの見せ方は変わってくる。
「分析後のアクションに繋げやすいように、データはこう見せる方が良いかな？」
とダッシュボードの見せ方のアイディアも湧いてくるため、アクションを確認することも非常に大切だ。
データソース
ダッシュボードの元データとなるデータソースは何を利用しているか？という点も確認しておく必要がある。
ダッシュボードの構築において、データの準備さえ出来てしまえば、全体の8割の対応は完了していると言っても過言ではないと思う。
それぐらいデータ準備は重要だ。
SalesforceやGA4、Snowflake、Google BigQueryなどTableauから直接接続できるデータベースに格納されているデータを利用する場合はデータの照らし合わせも比較的簡単だ。
一方でデータベースからダウンロードしたデータをExcelに貼り付け、それを加工したデータを元データにして日次で更新できるようにしたい、と言われる場合もある。
その場合は、Excelの加工ロジックを紐解いてSQLクエリやTableau Prepでそのロジックを再現する必要があるので難易度が上がる。
また、企業によってはTableauで直接接続できない独自のデータベースに格納されているデータを元データにしたいと言われる場合もある。
その場合はTableauで接続出来るようにTableauから直接接続できるデータベース（BigQueryやSnowflake、AWS RedShiftなど）にデータ連携する仕組み自体の構築から始めなきゃいけない。
※そのデータ連携を誰が行うか？という課題も発生する。
このようにダッシュボードのデータソースが何か？によってダッシュボード構築の難易度は大きく変わる。
そのため、ダッシュボードの元データとなるデータソースは依頼を受けたタイミングで聞いておき、データ加工の難易度がどれくらいになりそうかを見積もっておこう。
データ連携が難しい場合は依頼を断る場合もあるだろうし、他部署に協力依頼を掛けて対応する場合もあるだろう。
データソースへのアクセス権限付与依頼
必要なデータソースへのアクセス権限を早めに付与してもらうことはダッシュボード構築をスムーズに進めるために重要だ。
アクセス権限の付与とは、例えば、データソースとなるSalesforceやBigQuery、Snowflake等に自分が接続してデータをダウンロード出来るようにしてもらったり、Tableauから接続できるようにしてもらう、ということだ。
リリースの際にいずれ必要になる権限なので、出来る限り早めに付与してもらおう。
実際のデータソースのアクセス権限を早めに付与してもらえるかどうかでダッシュボード構築の効率は劇的に変わってくる。
アクセス権限をすぐに付与してもらえず、サンプルデータでダッシュボード構築を進めないといけない場合は結構リスクがある。
サンプルデータでダッシュボード構築を進めていたが、実際にデータソースに接続したらカラム構成が違って大きな手戻りが発生するリスクもある。
サンプルデータに最適化してダッシュボードを作っていたが、いざデータソースに繋いでみたら、データ量が多すぎてダッシュボードのレイアウトを大幅に作り直す必要があった、という私自身の苦い経験もある(笑)
「Salesforceのレポートをダッシュボード化して欲しい」
という依頼を頂くことも多いが、アクセス権限を直前まで付与してもらえなかったせいで、Salesforceのレポートに使われている裏側の計算ロジックが把握しにくく、ものすごく非効率だった経験もある。
そもそも、アクセス権限がないとダッシュボードの数値確認のために都度依頼してデータを共有してもらう必要があったりと何かと非効率だ。
もちろん、システム移行で移行先のシステムをデータソースとして使う場合とかはリスクを承知でサンプルデータで進めるしかない。
しかし、既に稼働しているシステムをデータソースとして利用する場合はアクセス権限を極力早めに付与してもらうようにしよう。
照らし合わせるべきデータ（ファイル）の共有依頼
ダッシュボードを構築する上で「数値がぴったり一致する」ということはとても重要だ。
数値が一致しているかどうかを確認するためには、現状クライアントが正としているデータ＝照らし合わせるべきデータを共有してもらう必要がある。
例えば、ExcelファイルやSalesforceレポート、他のBIツール等を利用したダッシュボードなどだ。
照らし合わせるべきデータを把握せずにダッシュボード用のデータを作ってしまうと、リリース前に数値が合わずに炎上、ということがよく起きる。
そのため、なるべく早めに照らし合わせるべきデータ（ファイル）を共有してもらい、
「この数値と合っていればいいんですね？」
と合意しておくことが重要だ。
注意点としてはExcelなどにデータを貼り付けたり、手動入力している場合など照らし合わせるべきデータ自体が間違っている、、、というトラップもある。
その場合はあらかじめ手動入力されている部分で間違いがあり、それで原因でずれる可能性があることもクライアントに伝えておくことも必要だ。
データの表示期間
ダッシュボードに表示させるデータの表示期間も早めに確認しておこう。
ダッシュボードによってはSQLやTableau Prepでのデータ加工を行ってダッシュボード用のデータを作ることも多いと思う。
その際に、データの表示期間が1年なのか10年なのかによってデータ整形の設計が変わってくる場合がある。
ダッシュボードのパフォーマンスにおいても1年分のデータを表示する場合と10年分のデータを表示する場合とでは大違いだ。
1年分のデータを読み込むだけならサクサク動くダッシュボードが、10年分のデータを読み込んだ場合、
「重くて使えない、、、」
なんてこともある。
もちろん依頼段階でデータ表示期間が決まっていない場合もあると思うので、出来ればであるが、早めに把握しておけると安心だ。
データの更新頻度
データの更新頻度もチェックすべき項目の1つだ。
ダッシュボードの更新が月次（月1回）で良いのか、日次で良いのか、数時間単位の頻度が必要なのかを確認する。
データの更新頻度によってもダッシュボードの作りが変わる場合がある。
例えば、月次でデータ更新して月1回程度確認すればいいダッシュボードの場合、時系列を日次単位で表示してもあまり意味がないことが多い。
逆に数時間に1回のデータ更新頻度を要求される場合は、1日の中での数値の動きをチェックしたいだろうから、時系列の表示は1時間単位での表示にするのが適切な場合もある。
ちなみに、私の今までの経験上は圧倒的にデータの更新頻度は日次更新が多いが、勝手に決めつけずに確認しておこう。
ダッシュボードのサイズ
ダッシュボードのサイズは重要度としては低いが、一応確認しておこう。
企業によっては既存のダッシュボードと合わせるためにサイズの指定があったり、Salesforce等にダッシュボードを埋め込むために特定のサイズで作っている場合もある。
私自身はダッシュボードサイズが指定されたことは1，2回しかない。
もし指定があるのであればそれに応じたダッシュボードレイアウトを検討する必要があるので、構築前に把握できるのがベストだ。
ただ、数値が合わないことに比べれば、ダッシュボード上のレイアウト変更はそこまで大した手戻りにならないので確認しそびれてもそこまでクリティカルではないと思う。
最後に
今回はダッシュボード構築前にチェックすべきポイントをまとめてみた。
- ダッシュボードの目的
- ダッシュボードを利用するユーザー
- ダッシュボードを見た後に行うアクション
- データソース
- データソースのアクセス権限付与依頼
- 照らし合わせるべきデータ（ファイル）の共有依頼
- データの表示期間
- データの更新頻度
- ダッシュボードのサイズ
あくまで私自身の経験からまとめているポイントなので、他にもっと考慮すべき点が多々あるかもしれないが、その点はご了承いただきたい。
上記ポイントを少しでも意識しながらダッシュボード構築を行えば、以前より少しはダッシュボード構築がスムーズに進むはずだ。
まだまだ言語化できていないことや抜け漏れもあると思うので、今後も気づいたタイミングで追記していこうと思う。
