トラディショナルな環境へのモダン分析導入

今回のブログは、InterWorks 社でシニアコンサルタントとチームリードを務める、David Pires 氏の寄稿です。2015 年に Tableau を使い始めた Pires 氏は、Tableau Ambassador であり、ヨーロッパで初めて開催された Iron Viz では優勝を果たしました。2017 年、できるだけ多くの組織の Tableau 導入を支援しようと InterWorks 社に入社しました。Pires 氏には、こちら (英語) から連絡を取ることができます。

「老犬に新しい芸を教えることはできない。決まった方法で物事を行うことに長い間慣れた者は、習慣を変えられない」

これは、「成長できる若いうちに新しいことを学べ」という意味の英語のことわざですが、私はそんなことはないと思っています。マーケティングコンサルタントの　Simon Sinek 氏が述べている、成功者が成功したのは同じことをずっと行い続けたためでも、競争に重点を置いたためでもなく、成功の秘訣は、ビジネスに価値を付加する新たな方法に目を向け、現状に甘んじないことである、という説はよく知られています。

Tableau は誕生から今日に至るまで変わらずに、「お客様がデータを見て理解できるように支援」することをミッションとして掲げています。変化したのは、小さな製品から、Linux や Windows、AWS、Azure、そしてそれらを組み合わせた環境と統合が可能なプラットフォームへと、成長を遂げた点です。そして、管理者が組織に Tableau を導入する際は、このすべてが選択肢となります。

Tableau のユーザーとして始まり、後にはコンサルタントになった私の経験から言うと、Tableau の導入は選択肢を選び取っていくアドベンチャーゲームのようなものです。

1. 最初から積極的な戦略
2. 急がば回れ戦略
3. パイロットプロジェクトの後に実施される積極的な戦略

それぞれを詳しく見ていきましょう。なお前提として、すでに調査がすべて完了し、組織の分析と BI の面で Tableau をイネーブラーとして導入する意思決定が行われたものとします。

スコープ

このようなタイプの戦略は、新しいプラットフォームには旧来のシステムのあるレベルしか移植されない場合や、組織のスタンスがオープンであり、分析方法の変化を受け入れられる場合に最も向いています。新しいプラットフォームでも従来のレポートを作成したいという要望が少なく、組織はこの機会を利用して、分析環境の活用方法で見直しと変革を行うことになります。

またこれは企業にとって、クラウドに移行して、AWS などのプラットフォームや Snowflake などのクラウドベースのデータベース (どちらも使った分だけ支払う方式で立ち上げ時間は非常に短くて済みます) の柔軟性を活用する、絶好の機会でもあります。

このアプローチには、移行作業がほぼ必要ないという非常に重要な特徴があり、必要に応じてモデリングを行える完全に新しいサービスを構築することになります。

スケジュール

積極的な戦略は、スケジュールも積極的です。速いペースで進む短期間の取り組みになると考えてください。

規模

私の経験上、このような形の戦略は小規模から中規模の企業に最も向いています。そのような組織は俊敏で、短期間で変革に順応できる傾向があるためです。大企業では不可能だという意味ではありませんが、形式主義のために対応が遅くなる傾向はあります。

リソース

この戦略には完全に専用のリソースが必要です。組織の規模に応じて、次のものが必要になります。

• サーバー管理者 (インフラストラクチャを管理)
• Tableau Desktop を利用する作成者 (通常は、他のユーザーが使用するコンテンツの作成に重点を置くアナリスト)
• データスチュワード (データ管理とガバナンス実施に精通し、ビジネス部門がデータをどのように利用するかを理解している、アナリストまたは IT 担当者)
• スペシャリストの社外リソース (Tableau の専門知識を持つ PM)

同様に重要なのは、組織のあらゆる部分、特に IT 部門から同意を取り付けることです。ディスカッションの初期の段階で IT 部門とビジネス部門を関与させると、ハードウェアのプロビジョニングを遅らせずに、迅速な実行を確実に計画できます。

さらに、社外リソースとのパートナーシップも鍵になります。理想的には、以前に同様の導入を行った経験を持ち、一般的な問題で行き詰まらないように支援できるリソースを探すことになります。

注意事項

組織では、どのような変革も 100 m 走のようにすぐ終わることはありません。そして明らかに、マラソンのように長い時間をかけるべきでもありません。ですから後援者やチームと話し合い、現実的な目標を設定しましょう。それが重要なのは、後援者である幹部チームには、達成不可能な期限を押し付けられるのではなく、取り組みの支援を行ってもらわなければならないためです。

スコープ

このようなタイプの変更を選ぶ組織は、多くの場合、次の 2 つに分けられます。1 つは予算と能力が限られており短期間に大量のリソースを投入できない組織で、もう 1 つは変更管理に対する抵抗が強い大規模な組織です。

移行では、すでに導入されている他のシステムを検証して最大限に活用する必要があります。つまり、考慮に入れるべき旧来の要素があるということです。従来のスプレッドシートを利用しており、かつ Tableau を最大限に活用しようとしている組織では、データ戦略も確立しなければなりません。小さな規模であれば、Excel からビジネスルールを移植する作業を Tableau Prep でスピードアップできますが、完全にリレーショナルなデータベースに移行する場合は、データスチュワードがデータ戦略に責任を負う必要があります。その場合、分析に役立つ新しいビューや表は Tableau で作成することになるかもしれません。

スケジュール

正確には言えませんが、このタイプの組織では、組織全体に Tableau を導入するのに 18 ～ 24 か月かかることもよくあります。これは必ずしも悪いことではありません。期限が長ければ企業は無理のないペースで導入を進められ、その結果、エンドユーザーもサポートされていると感じて満足できるためです。

規模

私の経験から言うと、ほぼあらゆる規模の企業はリソース不足、変更に対する抵抗、あるいはその両方が理由で、このカテゴリーに当てはまる可能性があります。

リソース

• サーバー管理者
• Tableau Desktop を利用する作成者 (小規模な組織では同じ人物がサーバー管理者も兼任可能)
• データスチュワード
• イネーブルメントチーム (サポート担当者、ベストプラクティスを共有するエキスパートなど)
• プロジェクトマネージャー

注意事項

多数のプロセスやルールが確立されている大規模な組織では、IT 部門が移行作業の中心になります。エンタープライズ環境ではおそらく、クラウドよりもオンプレミスで導入が行われる可能性が高いでしょう。また Tableau プラットフォームは、他のシステムの大半と統合するべきです。たとえば、Active Directory を利用したシングルサインオンや、Kerberos による偽装が挙げられます。どのような場合でも、当初から IT 部門に積極的なリーダーシップを取らせつつ、長期的に見て時間やコストの大きな削減につながる有益なアドバイスを提供してください。

リソースの面では組織の規模に応じ、データスチュワード、Tableau Desktop 開発者、イネーブルメント担当者の数を増やすと良いでしょう。

スコープ

私の経験上、このタイプのアプローチは、成功率と満足感が高くなります。通常は、IT 部門の支援を受けた事業部門によって後押しされて、組織は概念実証として使用するための、鍵となるプロジェクトを 1 つ探します。最も困難な作業は、適切なプロジェクトを特定することです。成功するには、変更をあまり加えずに迅速に価値を付加しようとするアプローチが必要です。すでにあるデータを活用できますか。関係者が長い間抱えているビジネス上の質問を解決できるかを検討してください。
プロジェクトを特定したら、MVP (最小価値プロジェクト) で成果を目指します。すべての機能をテストしてすべての要素を確認する時間はありませんが、要件の大多数を満たす必要があり、可能であれば上回る必要があります。

2 番目のステップは周知させることです。パイロットプロジェクトを特定して要件を満たすことができたので、次にその成果を知らせます。職場で紹介し、インサイトを共有して、成功した理由と他の人々がそのプロジェクトから学ぶ方法を伝えましょう。それ以降は、複数の事業部門でイネーブルメントを実施し、自らの成功経験を生かして成長を支援することが仕事になります。

スケジュール

理想的には、複雑さに応じてパイロットプロジェクトに 1 ～ 3 か月かけてください。それ以降は、パイロットプロジェクトから学んだ経験を使って、社内に拡大を図ります。

規模

この戦略はあらゆる組織に適しており、私が他の戦略よりも成功例を多く見ているのはおそらくそれが理由です。

リソース

• サーバー管理者
• Tableau Desktop を利用する作成者
• データスチュワード
• スペシャリストの社外リソース (PM)
• 社内 PM
• イネーブルメントチーム

注意事項

パイロットプロジェクトを日常業務に取り込むのではなく、プロジェクトチームがパイロットプロジェクトに専念する時間を作ってくださいMVP の成功に向けて専念できる時間を長く取れば取るほど、より多くのことが学べます。

自分たちの事業部門は他と違うという、同僚からの反発を受ける準備をしておいてください。その場合に重要なのは、得られたメリットをデータで証明することです。たとえば、手作業によるプロセスが必要なくなった、問題の答えが出たために会社の経費を大きく抑えることができた、などです。

組織への Tableau 導入に関しては、万能のアプローチというものは存在しません。しかし、Tableau プラットフォームの機能を利用することはできます。Tableau の Web 作成機能の場合、クラウドがすでに定着しており、Tableau Desktop とほぼ同等のことが行えます。組織内の多くのアナリストにとっては、取り付きやすい出発点になるかもしれません。

Tableau コミュニティが持つ膨大な経験を活用しましょう。Tableau Conference やユーザーグループに参加し、できるだけ多くの質問をしてください。Tableau パートナーや Tableau Ambassador に相談すれば、貴重なアドバイスが得られます。

社内では、必ず経営陣から支援を得てください。 予算の支援だけでは十分ではありません。アナリストには、Tableau を操作して導入するためだけに費やす時間が必要です。また、高くつく失敗を避けるために、IT チームと緊密に連携して当初から協力を得てください。むしろ、IT チームが主導し Tableau をサービスとして組織に導入する形が理想的です。

Tableau の導入でどのような方法を取るにしても、「楽しさ」の要素を入れることをお勧めします。たとえば、社内ハッカソンの実施、Makeover Monday、ユーザーグループセッションなどです。社内のコミュニティとつながることにはメリットがあり、ユーザーもお互いから学べる機会を活用することができます。

導入やガバナンスなど、トラディショナル BI から Tableau への移行に関する詳細は、Tableau オンラインセミナーシリーズをご覧ください。また、このページの質問 (英語) に答えることで、組織に最適だと思われる Tableau の導入オプションを知ることができます。