Amazon QuickSightを使ったBI基盤の構築事例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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