Tableauダッシュボードが“探索的である”とは?

2025.01.06

目次

    こんにちは。Praztoでプロジェクトマネージャー/コンサルタントを務めております大竹と申します。本日は、私たちが日常的にお客様へご提案しているTableauダッシュボードについて、「探索的である」とはどのような意味を持つのか、私も頑張って調べました。具体例を交えながらご説明いたします!

    Salesforceダッシュボードが定点観測で、Tableauが探索的とは?

    Salesforce社の営業担当者様や、弊社代表の芳賀および営業メンバーとお客様との商談に同席する際、「Salesforceダッシュボードは定点観測、Tableauは探索的」という表現が頻繁に話題に上がります。

    私自身、この表現に初めて触れた際は、「定点観測」と「探索的」という対比は直感的に理解できるものの、具体的にどのようなことなのかを説明することができませんでした。この具体的な意味を把握することは、製品やソリューションをお客様へご提案する際にとても重要です。

     
    本記事では、このTableauダッシュボードの特徴を、Salesforce標準ダッシュボードStreamlit in Snowflakeという2つのサービスとの比較を通じて、具体的に解説していきます。

    比較に使用するTableauダッシュボードのご紹介

    Salesforce標準ダッシュボードと比較する「プロジェクト収益管理ダッシュボード」

    Tableauダッシュボードの1つ目はプロジェクトの収益管理ダッシュボードです。このダッシュボードをSalesforce標準ダッシュボードとの比較を通じて、その特徴をご説明してまいります。

     
    本ダッシュボードは、プロジェクトの売上と利益を可視化し、適切な利益率の維持を支援することを目的としています。売上はSalesforceの商談における期待収益から算出され、コストはTeamSpiritに記録された稼働時間とメンバーごとのグレード単価から直接労務費を計算しています。最終的な利益は、売上から直接労務費を差し引いて算出されます。

    Streamlit in Snowflakeと比較する「コールセンター向けKPIダッシュボード」

    次にご紹介するのは、コールセンター業務のパフォーマンス管理を目的として構築したダッシュボードです。このダッシュボードは、アポ獲得数や獲得率などの重要指標を可視化しており、上段ではKPIの達成状況を、下段ではメンバー別の詳細な実績を確認することができます。

    このダッシュボードは、Tableauの柔軟な可視化機能を活用し、オペレーターごとのパフォーマンスの状況と傾向を探索的に分析できる構造となっています。

     
    このダッシュボードをStreamlit in Snowflakeとの比較を通じて、その特徴をご説明してまいります。

    Salesforce標準のダッシュボードと比較をしてみる

    最初に、Salesforce標準ダッシュボードとの比較を行います。比較対象として、以下の特徴を持つ一般的なSalesforce標準ダッシュボードを取り上げます:
     

    • 受注・失注商談における各フェーズの滞留日数を表示
    • 組織全体と個人別の両方の視点で可視化
    • 商談活動の適時性と一貫性を明確化

    このダッシュボードは、その目的に対して適切に設計・構築されています。「商談フェーズの滞留日数」という指標を通じて、フォローアップやNext Actionの実施状況を定量的に把握することができ、さらに組織全体と個人レベルの両方で状況を確認することが可能です。

     
    しかしながら、例えば「03-メリットの訴求」フェーズの滞留日数が組織全体で増加している場合、その原因を詳細に分析しようとすると制約が生じます。現状では、以下の二つの方法でしか分析を進めることができません:

     

    1. ダッシュボード下部のリンクからレポートへ遷移し、データを確認する
    2. ダッシュボードを下方向にスクロールし、個人別の滞留日数を目視で確認する

     
    このような限定的な分析方法では、以下のような重要な洞察を得ることが困難です:

     

    1. 「特定の部門において商談フェーズの滞留日数が長くなっている。そのためこの特定の部門の運用に問題がありそう」
    2. 「特定の商材において商談フェーズの滞留日数が長くなっている。そのためこの特定の商材の想定が現実と異なっていそう」

    続けてこの比較として、Tableauダッシュボードの特徴について、プロジェクト利益分析ダッシュボードを例にご説明いたします。

    それぞれの操作について説明する前に、実際の動画で操作感をご確認いただけるようにしました。以下に続く探索的な操作手順は、実際に画面で行った内容を収録したものです。

    それでは、各操作の詳細について順を追って解説していきます。

    2023年4月から2024年3月までの期間を対象としたこのダッシュボードでは、2月と3月の利益率が著しく低下していることが確認できます。ここでは2月の利益率低下の要因を分析するため、2月のデータに絞って詳しく見てみましょう。

    画面上で2月を選択すると、ダッシュボード全体が2024年2月のデータにフィルタリングされます。

    すると、「株式会社西村」のプロジェクトにおいて利益率が大幅に低下していることが判明します。この状況をより詳しく理解するために、画面中段の「詳細」ボタンから、プロジェクトの進行状況を確認してみましょう。

    このボタンを選択すると、ダッシュボード内で詳細分析画面へと切り替わります。

      
    切り替わった画面では、「株式会社西村」のプロジェクトに特化した時系列データが自動的に表示されます。この詳細な分析から、プロジェクト中盤までは適切な利益率を維持していたものの、終盤で急激な利益率の低下が発生していたことが明確になりました。

     
    この急激な低下の背景には、要件の追加や想定外の工数発生などの可能性が考えられます。この分析結果をもとに、プロジェクトマネージャーや部門長へのヒアリングを実施することで、経営層でも具体的な原因究明を進めることが可能となりました。
      
    先ほどの2024年2月のデータに限定された全体ダッシュボードに戻り、プロジェクトマネージャー別の散布図を確認してみましょう。

    伊藤さんの担当案件において、利益率が顕著に低下していることがわかります。そこで、伊藤さんが関与するプロジェクトに焦点を当てて、詳細画面で確認してみましょう。

    この分析から、伊藤さんが先ほど確認した「株式会社西村」のプロジェクトマネージャーであることが分かります。株式会社西村のプロジェクトは、終盤での利益率低下は著しいものの、プロジェクト全体としては許容範囲内に収まっていることが確認できます。

     
    しかし、より詳細な分析により、伊藤さんが担当する他の顧客プロジェクトにおいても、全体平均を下回る利益率の低下が発生していることが判明しました。この傾向が、株式会社西村のプロジェクトにおける2月の利益率低下にも影響を与えている可能性が考えられます。

     
    これ以上の原因究明には、伊藤さんおよび関係者へのヒアリングを行うことが自然かと考えますが、ここで特筆すべきは、Tableauの探索的な分析により、組織の拡大に伴い見えづらくなりがちな問題の発見にまで到達できた点です。このような探索・発見・分析が可能となることは、経営管理において非常に重要な価値を持つと考えています。

    Tableauの「探索的な操作性」とは、全体像を常に把握しながら、連動する絞り込み機能を活用することで、新たな気づきを得られる分析環境を実現できる点にあります。これは、Salesforceの標準ダッシュボードのみでは実現が難しい特徴であり、Tableauの導入を検討されるお客様の課題解決に向けた設計において、重要な特性の一つとして認識しておくべきだと考えています。

    Streamlit in Snowflakeと比較をしてみる

    これまでSalesforce社の製品である、Salesforce標準のダッシュボードとTableauの比較を行ってきました。ここからは視点を変え、Streamlit in SnowflakeとTableauを比較することで、Tableauの特徴である「探索的な画面設定」について掘り下げていきたいと思います。

     
    この記事のために、社内の先輩エンジニアに教えてもらいながら、Streamlit in Snowflakeで以下のような簡単なアプリケーションを構築してみました(なお、私は業務ではStreamlitの開発は担当していません)。このアプリケーションを基に、両者の比較検討を進めていきます。

     
    データ分析担当者向けのソリューションとして、Streamlit in SnowflakeをTableauとの比較対象として選定しました。まず、この選定理由について簡単に説明させていただきます。

    Streamlitフレームワークがもたらす「Webアプリ開発の高度な抽象化」

    通常のWeb開発では、サイドバーの表示や人数表示用のBoxレイアウトなどの実装に、HTMLやCSSの深い知識が必要です。一方、Streamlitフレームワークではこれらの実装が高度に抽象化されています。実際、今回のケースでは、色の調整にわずかなカスタムCSSを使用しただけで、HTMLやCSSをほとんど記述することなく、これらの機能を実装することができました。

     
    下記が、サイドバーと画面右上のメトリクス表示部分の実装です。HTMLの記載を行わず実装が完了していることがわかると思います。

    # -----------------------------------------------------
    # サイドバー設定
    # -----------------------------------------------------
    def setup_sidebar(df):
        Division = st.sidebar.multiselect(
            "リードの対象事業部を選択してください",
            options=df["DIVISION"].dropna().unique(),
            default=df["DIVISION"].dropna().unique()
        )
        LeadSource = st.sidebar.multiselect(
            "リードソースを選択してください",
            options=df["LEAD_SOURCE"].dropna().unique(),
            default=df["LEAD_SOURCE"].dropna().unique()
        )
        Phase = st.sidebar.multiselect(
            "フェーズを選択してください",
            options=df["PHASE"].dropna().unique(),
            default=df["PHASE"].dropna().unique()
        )
        return Division, LeadSource, Phase
    # -----------------------------------------------------
    # メトリクス表示
    # -----------------------------------------------------
    def metrics(df_selection):
        # フェーズ名と日本語の対応
        phases = {
            '9.Unqualified': '無効',
            '9.Closed': 'クローズ',
            '1.New': '新規',
            '2.Contacted': '接続',
            '3.Qualified': 'ナーチャリング中',
            '4.Needs Analysis': '検討中',
            '5.Proposed': '提案済み',
            '6.Follow Up': 'フォローアップ中'
        }
    
        # PHASE別の件数集計
        counts = {phase: len(df_selection[df_selection['PHASE'] == phase]['EMAIL']) for phase in phases}
    
        # 画面に4列で表示
        cols = st.columns(4)
        phase_list = list(phases.keys())
        for i, phase in enumerate(phase_list):
            label_jp = phases[phase]
            with cols[i % 4]:
                st.metric(label=f"{label_jp}(人)", value=f"{counts[phase]:,d}")
    

    プログラムのコード記述は必要ですが、Streamlitフレームワークによる抽象化は、Webアプリケーション開発の敷居を大幅に下げています。そのため、必要なレイアウトや機能がStreamlitフレームワークの対応範囲内であれば、このフレームワークの活用は非常に効率的な選択肢となります。

    Snowflakeプラットフォーム上での構築がもたらす「インフラの高度な抽象化」

    本事例では、StreamlitアプリケーションをSnowflakeプラットフォーム上に構築しており、その様子は以下の通りです。

    通常のWebアプリケーション開発では、Webサーバー、アプリケーションサーバー、DBサーバーの構築に高度なインフラ知識が必要とされます。メモリやCPUのスペック設定が不適切な場合、例えばメモリスワップが発生してサーバーの応答が著しく遅くなり、アプリケーションが実質的に機能停止に陥ってしまう可能性があります。

     
    一方、Snowflakeでは、基本的にウェアハウス(処理能力)の選択のみで構築が可能です。ウェアハウスを選択すれば、内部のシステム構成要素は自動的にSnowflake側で最適化されます:

     
    細かい設定のチューニングができることは利点の一つです。しかし、一般的な業務アプリケーションであれば、ベストプラクティスに基づいた標準的な構成で十分な性能を発揮できます。このように、Snowflakeのウェアハウスという概念は、データ分析担当者をターゲットとして明確に定めたプラットフォーム設計の表れだと考えています。

    このように、Streamlit in Snowflakeは「データ分析担当者がデータ分析そのものに集中できる環境」を実現していると言えます。これが、今回Tableauとの比較対象として、Streamlit in Snowflakeを選定した主な理由です。

    Streamlit in SnowflakeとTableauにおける「探索的な分析設定」の比較

    先ほど言及した「探索的な操作性」と「全体像を把握しながら連動する絞り込み機能の活用」について、両者を具体的に比較していきます。

     
    まず、サイドバーに表示されている一覧データは、動的に取得した実際の値から重複を除外して表示しています。

    このサイドバーでの選択内容を変更すると、右側の分析結果がリアルタイムで更新されます。このような操作性により、データ全体を俯瞰しながら傾向を確認することが可能です。具体的な操作イメージは、添付の録画でご確認いただけます。


    一方で、Tableauのような「画面右下の円グラフをクリックすることで、他のチャートやテーブルを連動して絞り込む」という機能についてはどうでしょうか。

     
    こちらは、どうやら簡単には実現することは出来なさそうです。

     
    “簡単には出来ない”ということを説明するのは難しいのですが、社内の先輩エンジニアたちと色々と話したのですが、「Plotly イベントを JavaScript で拾い、streamlit_js_eval などの拡張を使って Python 側へ送信し、セッションステートを更新して再度チャートをレンダリング…」といった少しゴリゴリとした実装をすれば実現は出来そうですが、かなり手間がかかるというのが結論のようです。

    Tableauでは同様の操作はどのように設定できるのか?

    ここからは、Tableauダッシュボードにおける探索的な分析の操作設定について説明します。

    具体的な例として、2つ目のTableauダッシュボードの下部に焦点を当てて解説していきます。

    まず、このダッシュボード部分の機能と分析設計について説明します。このセクションでは、コールセンターのオペレーター別のパフォーマンスを以下の指標で可視化しています:
     

    • コール数
    • コンタクト数・コンタクト率(担当者との通話接続)
    • アポ数・アポ率(商談機会の設定)

     
    画面左上の散布図では、以下の要素を用いて各オペレーターの実績を表現しています:
     

    • X軸:コンタクト率
    • Y軸:アポ率
    • 円の大きさ:コール数

     
    この可視化により、各メンバーの実績を直感的に比較することが可能となっています。

    オペレーターごとの傾向分析

    このダッシュボードのもう一つの重要な機能は「各オペレーターの詳細な傾向把握」です。左上の散布図で特定のオペレーターをクリックすると、以下の詳細指標が連動して表示されます:

     

    • 通話時間の分布
    • 曜日・時間帯別のコール傾向
    • コール密度(稼働時間中のコール実施割合※準備時間含む)
    • リードソース別のコール率およびアポ率
    • コールテンプレート別のコール率およびアポ率

    ※コール密度はこの構築での独自指標です

    具体的な例を見てみましょう。

    高実績のオペレーターである相葉さんの場合:

     

    • 通話時間が短い
    • コール密度が低い
    • コンタクト率とアポ率が全体的に高い水準を維持

    一方、課題のある植田さんの場合:

     

    • 通話時間が長い
    • コール密度が高い
    • コンタクト率とアポ率が全体的に低い水準

    ※このデータはデモ用に作成されたものであり、ここでの分析結果は分析手法の例示を目的としています。


    このダッシュボードは、高実績オペレーターの成功パターン(効果的な曜日・時間帯など)を特定し、それを実績向上が必要なメンバーへ展開することを目的として設計されています。

    これらの分析がいかにスムーズに行えるか、添付の動画でご確認いただけます。

    Tableauの優れた特徴の一つは、このような高度なフィルタリング機能をノーコードで実現できる点です。以下に示すように、ダッシュボードアクションの設定だけで、この複雑な連動機能を実装することが可能です。

    先ほどStreamlit in Snowflakeについて「データ分析担当者がデータ分析そのものに集中できる環境」と評価しましたが、この特徴はTableauにも共通しています。またTableauに関しては、プログラミングを必要とせず、ポイント&クリックの操作だけでここまでの高度な探索的分析が実現できる点が大きな特徴と言えます。

    TableauとStreamlit in Snowflakeには、どちらにも優れた特徴がある。

    ここではTableauのノーコードでの詳細なアクション設定機能について説明しましたが、これはTableauが優位であるということを示すものではありません。両者にはそれぞれの特長があります。
     
    例えば、Streamlitはプログラムベースで構築されているため、異なる観点での柔軟な拡張が可能です。具体的な例としても、Tableauダッシュボードが基本的に読み取り専用であるのに対し、Streamlitでは更新可能な表を実装できたり、Snowflakeの外部関数を活用することでより幅広い機能拡張が実現できたりする点が挙げられます。

    これらの違いは、各サービスの設計思想に基づくものであり、どちらにも固有の価値があります。用途や要件に応じて、それぞれの特長を活かした選択が可能です。

    まとめ

    今回の記事では、「Tableauは探索的」という特徴について、他のサービスとの比較を通じて深く掘り下げてきました。その結果、Tableauの探索的な特徴は、主に以下の2つの側面から構成されていることが分かりました:

     
    1. 全体を俯瞰しながら絞り込んでいくUXの実現
    Tableauの大きな強みは、ダッシュボード全体の状況を常に把握しながら、連動する絞り込み機能を活用できる点です。この操作性により、データの新たな気づきを効果的に得ることが可能となっています。

     

    2. 分析担当者が分析に集中できる機能設計
    もう一つの重要な特徴は、これらの高度な機能設定を、ノーコードの標準機能だけで実現できる点です。この設計により、データ分析担当者はその他の技術的な習熟を行う必要がなく、分析業務そのものに集中することができます。

    Tableauというサービスと、それを用いて構築されるダッシュボードは、いずれもお客様の課題解決のための手段です。そのため、それらの特性を深く理解し、適切に活用することが課題解決への重要な一歩となります。本記事でご紹介したTableauの特徴が、皆様の業務改善のヒントとなれば幸いです。

    他のオススメ記事

    一覧トップへ戻る