Amazon QuickSightでBI基盤を構築

前年比1.2倍の売上を目指すためには、新規売上を何倍にしたらいいのか?売上がすべて新規売上であれば、1.2倍が答えです。しかし、ストック売上と新規売上が混じっていると、簡単なようで意外と難しい問題になります。過去ディーネットが抱えていた問題でもあります。

必要な新規売上の予測は、このストック売上の影響を排除したうえで、目標金額との差を確認する必要があります。

ストック売上は、毎月の継続的な売上です。金額が毎月固定のものもあれば、増減するものもあります。ある時点の断面だけを見ていても意味はありません。時系列で推移を確認する必要があります。

この問題を解決するために、ディーネットでは「Amazon QuickSight」を活用しています。BI基盤の共通プラットフォームです。このおかげで、データを様々な角度で分析できます。部署横断で同じ情報共有が可能です。データに基づいた意思決定ができるようになりました。また、サーバーレスの環境で構築しており、管理コストがほとんどかからない状態です。

この記事では、当時抱えていた社内の問題や採用の経緯、導入のポイントなどをご紹介します。

たまり続けるデータ

日々更新される商談進捗状況

ディーネットでは、商談の進捗状況をWEBデータベース上に保存しています。各営業担当が都度更新するようになっており、データが日々蓄積されていきます。しかしながら、WEBデータベースなので、「今」の状態を見ることはできましたが、時系列の推移や集計、分析などは出来ず、各個人がExcelにて活用している状態でした。

Windowsアプリ上にある請求情報

また、請求情報はWindowsアプリ上で管理されており、こちらも担当者が必要に応じてExcelで集計分析をしている状態でした。

進まないデータ活用

データは着実に蓄積されていました。定期的にExcelを使い、必要なデータを保存してピボットテーブルやグラフ化などで情報の見える化をしていました。しかしながら、その情報がなかなかうまく活用できません。

ファイルを共有する限界

Excelを共有すると、利用者はローカル環境へダウンロードして活用しようとします。そこで自分好みにカスタマイズして使う人が出てきます。すると、一人ひとりが見る情報が異なってきてしまい、共通認識が持ちにくくなるという課題がありました。

会議などで同じExcelファイルを見ながら議論をすることもありましたが、最終的には誰かがまとめて共有する形になるので、最新情報にアクセスするまでのタイムラグが大きくなっていき、活用しきれない状態になりました。

誰のための分析データなのか?

管理部門が定期的にデータの分析を行い、営業部門へ分析結果が共有する。というフローが管理業務の一環としてルーチン化されていました。

当初は目的があり共有を進めていたはずです。しかし、分析する部門と利用する部門が分かれていたこともあり、時間が経つにつれて目的が失われていき、ルーチン化されたフローだけが残るような状態に近くなっていました。

分散するデータを統合する難しさ

過去の情報は「請求情報」から、現在の情報は「商談進捗情報」から、未来の情報は「請求情報」と「商談進捗状況」を組み合わせたものから、と、別のデータソースからデータ抽出する必要があります。それぞれ別のサービスで管理されており、管理部門も異なっています。

新たな分析をしようとすると、部門間調整が必要になるケースがあり、データ構造の理解から始める必要がありました。なんとか、分析が完了しても、頻繁にデータ更新する手間が大きいため、思い出したタイミングで1から作り直す。というようなことが多発していました。

BI基盤に対する要件

データ活用において様々な課題があったため、データに基づいた意思決定ができずにいました。その状況を打破すべく「BI基盤構築プロジェクト」を発足させました。BI基盤に対する要件は次のように定めました。

  • 部署横断で共通の情報を見て意思決定を行えるようになる
  • 現在の業務フローを大きく変えない
  • 可能な限りコストは安く

要件1.共通の情報を見て意思決定を行えるようになる

BI基盤導入前は、「担当者間」「部署間」「役職者間」で知っている情報に大きな差が出ていました。

Excelを中心とした情報共有がされていたので、ツールの問題、情報取得にかかるコストの問題、意識の問題などが原因としてありました。

ツールを改善することで、情報取得コストを減らし、各自の意識を変えていくこととなりました。

要件2.現在の業務フローを大きく変えない

情報活用のために、業務フローを大きく変えることは避けるべきと考えました。

BI基盤は情報共有の手段にすぎません。業務フローを大きく変えると工数もかかりますし、手段が目的化しやすくなってしまいます。可能な限り現行の業務フローは変えずに、BI基盤を構築することにしました。

要件3.可能な限りコストは安く

当然ですが、コストは可能な限り押さえて進めたいという話になりました。特に直接的に収益を生み出すものではないため、本当に必要な部分に絞り、コストを抑えつつ進めていく必要があります。

BI基盤の構成要素

最終的に、BI基盤の構成は次のようになりました。扱うデータは1GB前後のため、小規模なBI基盤となります。

QuickSightの利用ユーザーにかかる費用を除くと毎月数百円のコストで利用できています。また、AWSの機能を活用して、サーバーレスな構成にしているため、管理コストもかかりません。

Amazon S3

マスタデータと分析用データの保存場所は「Amazon S3」としました。マスタデータは、手動または自動でアップロードしています。分析用データは、後述の「AWS Glue」でマスタデータを編集してアップロードしています。

AWS Glue

「Amazon S3」へアップロードしたデータは、そのままでは使うことができません。使いやすい形に変換してあげる必要があります。俗にいう「ETL」の処理が必要です。ETLの「E」はExtractで抽出、「T」はTransformで変換、「L」はLoadで格納、となり、それぞれの頭文字をとったものが「ETL」となります。

この「ETL」処理を「AWS Glue」で行っています。トリガーは定期実行としており、「Amazon S3」のデータをPythonで取得し、変換し、編集後のファイルを「Amazon S3」へ保存させています。

Amazon Athena

「Amazon S3」へ保存したETL処理後のデータをBI基盤で読み込むために、「Amazon Athena」を使っています。これを使うことで、標準SQLを使ってデータ抽出が可能です。BI基盤である「Amazon QuickSight」からは「Amazon Athena」を経由して、標準SQLでデータ取得を行う形です。

通常であれば、MySQLなどのリレーショナルデータベースをサーバー上に構築して、管理する必要があります。しかしながら、「Amazon S3」と「Amazon Athena」を使うことで同等の機能をサーバーレスで構築することが可能になります。

Amazon QuickSight

情報の可視化は「Amazon QuickSight」を使って行っています。

「Amazon QuickSight」は、管理者ユーザーと参照ユーザーを分けて管理することが可能です。参照ユーザーについては、利用した分だけの従量課金となっており、無駄なコスト発生を抑えて使うことが可能です。

運用方法

次のような運用方法で運用しています。

マスタデータアップロード

今までの業務フロー上で作成していたデータをマスタデータとして、「Amazon S3」上へアップロードしています。

請求情報は月数回の手動更新

Windowsアプリで管理している請求情報は、更新頻度が少ないため手動でデータ更新しています。

商談進捗状況は日に4回にニアリアルタイム更新

WEBデータベース上に保存している商談進捗状況は、日に4回自動更新するようにしています。クローズドな環境に置いているため、社内管理しているサーバ上から、バッチ処理を定期実行させています。この処理については、サーバー上で動作させているため厳密にいえばサーバーレスではないのですが、このために立てたサーバーではないので、管理コストは増えていません。

ダッシュボードの作成

ダッシュボードはBI基盤構築プロジェクトにて、共通的なものを提供しています。

それをベースに、役職者以上のメンバーが自由に編集できるようにしています。やはり各部署で見たいものは違っており、細かい部分は自分で分析出来たほうがスピード感を持って進められます。

なお、ダッシュボードの編集には、管理者権限のユーザーが必要です。

ダッシュボードの閲覧

ダッシュボードの閲覧は、営業メンバーを中心とした社員が閲覧できるようにしています。商談情報が中心となるので、営業メンバーが常に自分や部署、会社の状況を確認できるようにしています。

課題

役職者が自分が必要と考えるダッシュボードに編集することが課題となっています。

グラフの編集をするとなると、標準SQLや「Amazon QuickSight」の操作を覚える必要があります。マニュアルや勉強会を開いていますが、なかなかハードルが高いようです。そのため、現在は、BI基盤導入プロジェクトにて都度情報の取り込みを行っている状況です。

導入効果

情報の可視化が進んだ

次のように様々な情報の可視化が進んでいます。

  • 過去実績情報
  • 現在の商談進捗状況
  • 未来の予測情報
  • 予実の進捗状況
  • 商談状況の入力エラーの可視化

数字を元に議論できるようになった

今までは各個人の予想や雰囲気で行動することが多くありました。共通の数字を見ながら議論できるので、数字を元にした行動や指示を出せるようになりました。

マネジメント層はより的確な指示を出すことができ、メンバーは納得感を持ち行動することができます。また、現在地と目標地点が明確にわかるので、施策の検討もより具体的にできるようになっています。

データの入力精度が上がった

単純にデータをグラフ表示しているだけでなく、商談進捗状況が滞っているものや、入力内容が不適切なものをエラー表示させるようにもしています。そのため、データの入力精度も上がっており、より正確な数字をもとに行動できるようになってきました。

まとめ

ディーネット社内の小規模BI基盤を、「Amazon QuickSight」を中心とするAWSサービスを利用して構築しました。

サーバーレスなアーキテクチャを採用することで、人的管理コストを限りなく減らしており、AWS利用料もかなり抑えられています。

BI基盤を構築することで、情報の可視化がかなり進むことになり、数字を元にした議論ができるようになりました。

同じような悩みを抱えている場合は、ぜひAWSを使ったBI基盤の構築を検討してみてはいかがでしょうか。