Amazon QuickSightを使って分析ユーザーのコミュニティを構築する(※活用シナリオ紹介)

2016.11.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon QuickSightがリリースされて数日経ちますが、皆様もこのサービスをご利用されていますでしょうか?弊社内でも早速社員総出で使い倒しております。

先程、AWSのBigdata Blogで公開されたエントリでは、Amazon QuickSightを実際のシーンでどのように活用すべきか、よりイメージしやすくなるような形で『物語形式』でAmazon QuickSightの使いどころ、ポイント等を解説しています。私も読んでみたところとても分かり易い内容となっていましたので、その内容についてご紹介してみたいと思います。

 


 

あなたの夢の仕事にちょうど就けた事を想像してください。

あなたは最も困難な問題に取り組んで来ました。そして今のあなたの仕事はコーヒーショップのチェーン店です。熾烈な競争、タイトな予算、低い意気込みとった問題に直面して苦戦しています。ですが、新しい管理チームが出来ました。BIのトップとして、あなたはその状況を変えるチームの一員となっています。あなたの新しい会社("CoffeeCo"という名前としましょう)は既に分析に多額の投資をしており、そして本社スタッフは豊富なレポートへのアクセス出来ています。ですが程無くして会社は『レポートが無い』では無く『他の場所にある』という問題に直面します。

各店舗にはプロモーションを実行し、報酬カードの使用を奨励しているマネージャーがいます。 しかしCoffeeCoの厳しい予算の中では、彼らが自身のレポートを見るのに苦労しているのが現状です。 実際のところ、限定的な売上データしか記載されていないメールの報告を確認するという作業は非常に骨が折れるものです。 恐らく、もっと多くの情報があれば、マネージャー達はもっと多くの洞察を得る事が出来、売上を増やす事が出来るでしょう。 AWSを利用して使いやすく、堅牢で低コストなソリューションを構築する事でそのアイデアをテスト出来ます。

- 1日目 -

まずはじめに、ITチームと一緒に構築したいアーキテクチャを描いてみます。お客様のアーキテクチャは、費用対効果の高い運用と長期的なロックインを保証する為にフルマネージドのAWSサービスに基づいています。データはAmazon Kinesis Firehose(リアルタイムストリーミングデータを配信するフルマネージドサービス)を通じて

  • Amazon Simple Storage Service(Amazon S3)
  • Amazon Redshift
  • Amazon Elasticsearch Service(Amazon ES)

といったサービスに送信されます。

ここでは、フルマネージドのペタバイト規模のデータ管理が可能なDWHサービス、Amazon RedshiftをKinesis Firehoseの配信先として選びました。Redshiftに格納したデータをAmazon QuickSightで視覚化するという流れです。

dayone

各コーヒーショップのデータはFirehoseに送信する必要があります。まず始めに、各コーヒーショップのPOSシステムは変更を行う必要性が生じてきますが、これは難しい作業では無いと考えます。幸いにも、それぞれのPOSシステムはAndroiタブレットである事が分かったので、AWS SDK for Androidを使ってデータを送信する事が出来ます。ここでのアーキテクチャ上の決定は、SPICEデータエンジンを使うのか、またはQuickSightから直接Redshiftにアクセスをするのか、という点です。SPICEは高速でインタラクティブな、データ視覚化の為に特化されて設計・最適化されたインメモリの計算エンジンです。

SPICEがBIリクエストをオフロードする事により、臨機応変のレポートクエリによってAmazon RedshiftクラスタのDWH本番環境に不要な影響を与えないで済むようになります。

SPICEを使うと、Amazon Redshift,Amazon RDS,Amazon Aurora,EXCELやCSVデータファイル、Salesforce等のWebアプリケーション等、様々なデータソースからのデータを組み合わせてレポートやデータマートを構築出来ます。またSPICEを使ってデータへのアクセスを管理する事で、データソースに直接アクセスさせずにレポートデータマートにビジネスユーザーがアクセス出来るようにする事も可能です。

ITチームにAmazon Redshiftを導入した事で、他の追加データもRedshiftにロードし、完全なデータウェアハウスを構築する事が決まりました。従って、SPICEを活用して臨機応変にアクセスされてくるであろうレポートのクエリが、この新しい重要なプロジェクトに悪影響を及ぼさない様にする必要が出てきました。

データの準備

ITチームにAWS管理コンソールとAmazon Redshiftへのサインイン情報を提供し、アーキテクチャを構築するのに長い時間は掛かりません。環境にアクセス出来るようになったら、まずは分析で使用するデータを準備します。Amazon QuickSightにサインインし、『Manage Data』を選択して新しいデータセットを選択し、データセットを新規作成します。

Amazon QuickSightではデータセットを作成後に変更出来るので、最初の操作で必要となるデータ全てを入手出来なくても問題はありません。作業を繰り返しながら改善をしていく事が出来ます。

Amazon Redshiftクラスタを自動検知する為にAmazon QuickSightの許可を与える事も出来ます。この許可をする事で、Amazon QuickSightでAmazon Redshiftデータソースへの接続を選択すると、そのリージョンで実行されているクラスタのリストを表示する事が出来ます。各クラスタのデータにアクセスするには勿論ユーザー名とパスワードが必要となりますが、接続文字列やサーバー名を覚えておく必要はなくなります。

Amazon Redshiftへの接続が確立されたら、作業するスキーマとテーブルを選択します。データには複数のテーブルが含まれているため、画面左下にある『Edit/Preview data』ボタンを選択します。

prepare-data

データ準備のフェーズでは、以下の内容を選択出来ます。

  • SPICEを使うか否か
  • データセットにテーブルを追加し、テーブル結合の設定を実施
  • データセットのフィールドの使用・未使用を選択
  • フィールド名やフィールドのデータ型の変更
  • 計算フィールドをデータセットに追加
  • データセットをフィルタリングし、データソースの全ての行がインポートされないようにする

ITチームはAmazon Redshiftを使って標準的な小売のデータモデルを作成しました。

diagram

モデルの中心にはorderテーブル(ダイアグラム上ではcoffeeco_order)があります。このテーブルは1行以上の注文詳細情報(coffeeco_orderdetailテーブル)を含みます。注文詳細テーブルは購入された製品のリンクが含まれています。ダイアグラム内のテーブル間結合は、顧客(coffeeco_customers)と注文(coffeeco_order)のRIGHT JOIN(右外部結合)以外は内部結合されています。

殆どの購入は匿名となっていますが、ロイヤルティカードを使って行われた購入の情報はcustomerテーブルに入っています。 画面上部にある『Prepare data & visualize』を選択すると、SPICEにデータがインポートされます。この作業で最初の分析を始める準備が整いました。

知見の共有

Amazon QuickSightでは分析を利用してビジュアルやストーリーを作成・対話する事が出来ます。

分析は"空白のキャンバス"として考える事が出来るでしょう。このキャンバスにはデータやビジュアルのグラフ表現を落とし込む事が出来ます。Amaozn QuickSightを使って、コーヒーショップ経営者が関心を持つと思われる指標を示すビジュアル分析を即座に作成出来ます。

作成した分析を経営者と共有する最も簡単な方法はダッシュボードを作成する事です。ダッシュボードは、他のAmazon QuickSightユーザーに提供する事の出来る『分析の読み取り専用ビュー』です。共有する前に、画面左側にあるボタンを使い、ユーザーが特定のコーヒーショップに表示されている結果を制限出来るようにするフィルタを追加します。これでダッシュボードを共有する準備が整いました。

dashboard

しばらくして幾つかの電話が掛かってきました。現在構築中のアーキテクチャのベータテストを手伝ってくれるというマネージャーからの電話です。Amazon QuickSightユーザーとしてサインアップを行い、ダッシュボードを共有します。この作業を行うには、画面右上にある[Share]ボタンを選択し、[Create Dashbpard]を選択するだけです。ダッシュボードの内容はAmazon QuickSightにサインインすると[Dashboards]タブに表示されます。

マネージャは皆、"データのエキスパート"ではありませんが、それはさしたる問題にはなりません。全ての作業はUIを介して行われ、ウェブサイトまたはモバイルアプリのいずれかを使用してダッシュボードを簡単に操作できます。

ダッシュボードの内容はフィルタの条件変更を行う以外の変更・編集操作は出来ません。ベータテスターからのフィードバックは良好でした。ですが、数日後2人のテスターが『もっとデータを深く知り、ダッシュボードのメトリクスを変更したい』という旨の依頼を電話でしてきました。

これを実現する最も簡単な方法は、この(2人の)マネージャーと『分析を共有』する事です。

[Share Analysis]を選択して分析の共有を行うと、他のユーザーに対して分析への完全なアクセス権を与える事が出来ます。管理者がAmazon QuickSightにサインインすると、ホーム画面に分析が表示されます。

share

管理者は分析上のビジュアルを自由に変更し、独自のビジュアルを追加する事が出来ます。ただし、[Manage data]を選択した際のデータセットは表示されません。これにより、データセットがユーザーによって誤って変更されるのを防ぐ事が出来ます。

ストーリーを伝える

数週間が経過しました。Amazon QuickSightでデータを知る事に時間を費やしてきたので、ベータテスターからのフィードバックを得る事は少なくなってきました。そして、マネージャーから1本の電話が掛かってきます。興味深い情報を見つけたのであなたに見せたい、というものでした。

このシナリオを実現する最も簡単な方法は『ストーリーを構築』する事です。

我々は、ビジネスの変化の事例を表す『スライド』の表示に慣れてしまっています。Amazon QuickSightもそういった点では形式は似ているかも知れません。ですが、Amazon QuickSightでストーリーを構築すると、データではなくビジュアルをキャプチャし、一連の連続したシーンを通して『ストーリー』を作成する事が出来ます。

ストーリーを再生すると各シーンが再計算されるため、ストーリーは常に『現在のデータ』を反映します。

Amazon QuickSightの全ての分析には、空のデフォルトストーリーが付属しています。ストーリーの追加はいつでも行なえます。ストーリーにシーンを追加するには、画面右上にある[Capture]を選択します。

マネージャーは異なる販売地域を確認し、どうすれば効果的にプロモーションカードを使う事が出来るか、という部分を考えるのに時間を費やしました。ストーリーの最初のシーンは、特定地域でカードが頻繁に使用される事を示しています。

story

マネージャーは一連の『シーン』を通して、この地域で実施されているプロモーションの詳細を明らかにし、成功した理由を説明します。この場合、地域で組織されたキャンペーンは、本社が行ったキャンペーンよりも遥かに優れている事が分かります。更にCoffeeCoでは、プロモーションがハーフマラソンやパレード等の地元のイベントに結びついた時に最高の結果が得られているという事が判りました。これを見てあなたは『これが他の店舗でも採用出来る戦略だ』と考えます。

本社からのプロモーション件数を減らし、地域ごとのキャンペーンを提供する為に費用を調整する事で売上全体が向上する可能性があります。...という様な感じで、マネージャーがストーリーで説明した"洞察"を、活動に関わる全ての人たちをサポートする為にAmazon QuickSightを使う事が出来るのです。

まとめ

という訳で、Amazon QuickSightの利用に関する『もしも企業がAmazon QuickSightを活用したら』のご紹介でした。

元投稿曰くこの物語は『架空』のお話ですが、業務やプロジェクトに於いてAmaozn QuickSightを活用し、改善を行っていく際のイメージはなんとなく出来たのかな、と思います。Amazon QuickSightでは従来の10分の1のソリューションコストで、長期間のロックインが無くても、組織内のユーザーコミュニティを迅速に構築し、豊富なBI機能を提供出来ます。データ分析に際して効果的なソリューションを探している方がいらっしゃいましたら御検討頂けますと幸いです。こちらからは以上です。