Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

SaaS・クラウド時代におけるバラバラデータへの取り組み方

去年12月5-6日(Tokyo)と今年1月23-24日(大阪)で開催された Microsoft Ignite The Tour に参加してきました。

そこで、同じ Dynamics 365 MVP のカテゴリである吉島さんのセッション「もしも、バラバラ殺データ事件に遭遇したら(裏タイトル)」を見てきたんですが、これがとても示唆に富む内容でした。

https://www.pbc.co.jp/blog/microsoft-ignite-the-tour-tokyo-how-to-describe-our-promissing-future/

f:id:sugimomoto:20200131131710p:plain

顧客管理や生産管理、プロジェクト管理といった各ビジネスプロセス・マネージメントでそれぞれの要素がバラバラに各サービス・アプリケーションに存在した場合、どのような課題、難しさが存在するか? また、そのソリューションとして考えられるものは何か? といった点をテーマのセッションです。

f:id:sugimomoto:20200131131716p:plain

2020年となった今、企業の内部はマルチクラウド・マルチ SaaS 時代に突入し、データの在り方、連携の方法が改めて大きな課題として直面しています。

吉島さんのセッションでは、メインとなる部分は「ビジネスプロセス的バラバラデータ」を Dynamics 365 はどのように解決できるのか? を中心としたセッションでしたが、これは「ビジネスインテリジェンス(BI)」の考え方としても同じことが言えるな、と思いデータドライバーベンダーのエンジニアの視点として今回の記事にまとめてみました。

なぜバラバラデータを解消しなければいけないの?

BI における「バラバラデータ」の一番の問題とは何でしょうか?

まず認識としてはっきりさせておきたい点は「意思決定や判断にドリルダウンが必須」であるということです。

例えば「売上を前年よりXX%アップする」という単純な目標を掲げるとしても、その施策・アクションのために

→売上ってどうなっているんだっけ? →その売上の顧客の構成ってどうなっているんだっけ?(ERP) →この顧客はどのセールスリードから発生しているんだっけ?(CRM) →この顧客はどうやって流入してきたんだっけ?(MA) →この顧客はどのキャンペーン・Webサイトを見ていたんだっけ?(Web Analytics)

実際の売上のデータを元に、その顧客からその施策までを紐解いていく必要があります。

これが部門最適な時代であれば、各部門ごとでクローズドな判断に任せられたでしょう。しかし、現代はサブスクリプションビジネスに代表されるように分断されたプロセス・部門が連携しながら、サービスを改良し施策を重ねていく時代です。

f:id:sugimomoto:20200131131725p:plain

何か施策を打つ際にそれがマーケティング的施策であったとしても、KPIの結果として現れるのは営業部隊やテクニカルサポートの部隊のデータかもしれません。

顧客に紐づくデータを部門最適では無く、全体視野を持って分析しアクションにつなげる必要があります。

一つの企業で平均20 程度のSaaS を使う時代に

しかし、そこでボトルネックとなるのが、各サービス・アプリケーションでデータがバラバラに存在してしまっている点です。

私達が分析したい対象はCRMERPではありません。顧客とその顧客の繋がりに発生しているデータを分析したいはずです。

あるリサーチでは, 2015 年に企業内で使用するSaaS の数は8程度であったものが、2017年には平均16のSaaS を使うようになったとのことです。

f:id:sugimomoto:20200131131731p:plain

このレポートは2017年のものですが、弊社のUS チームでユーザーから聞くところでは、すでに1企業あたり平均20程度のSaaS に接続する必要があるというのが実情のようです。

さらに示唆に富むグラフがありましたので紹介します。これは企業内で使われているクラウドサービスの割合を示したグラフですが、File SharelingやFinanceといった王道のクラウドサービスだけでなく、実に多様なクラウドサービスが存在し、それぞれにビジネスインテリジェンスを必要とするデータが格納されています。

f:id:sugimomoto:20200131131737p:plain

https://cloudsecurity.mcafee.com/cloud/en-us/forms/white-papers/wp-cloud-adoption-risk-report-2019-banner-cloud-mfe.html

上記はUSのトレンドですが、日本でもSaaS の活用はトレンドであり、数年後には現在のアメリカのようにひとつの企業が20以上のSaaS を利用し、それらをデータ分析しアクションに繋げるようにすることは必須の状況に至るでしょう。

しかし、そんなバラバラデータに対応するのに何が一番問題なのでしょうか。

分析のために一番の課題となるのは「インターフェース」である

ちょうど今日見た記事ですが、

www.itmedia.co.jp

f:id:sugimomoto:20200131131743p:plain

また、あるレポートでは「データ準備80%、データ分析20%」と言われています。

f:id:sugimomoto:20200131131808p:plain

それだけデータ分析の手前、様々なデータソースからデータを集め、加工し、分析できる状態に準備するまでに大きな時間と手間がかかっています。

データ準備にも様々な作業・プロセスが存在しますが、その中で今最も大きな課題点として上がっているのはデータソースの多様化であり、そしてそれらがそれぞれ保持している「インターフェース」に潜む課題ではないでしょうか。

「インターフェース」の課題とはなんでしょうか? また、今私達が接しているデータの「インターフェース」はどんなものがあるでしょうか?

数年前であれば私達の身の回りに存在するデータは「MySQLSQL Server」もしくは「Excel」や「CSV」といった数少ないフォーマットでした。インターフェースもシンプルであり、どんなツールでもとりあえずRDBCSVが取り込める状況でした。

しかし、下の図を見てもらえば分かる通り、SalesforceやDynamics 365といった業務横断的なユニバーサルSaaSが出始め、それに追従するような形で、MarketoやServiceNow といった部門特化型、そして最近ではMailChimpやExcelOnlineなどの特定シナリオ・特定機能に特化したクラウドサービスが出てきました。

f:id:sugimomoto:20200131131815p:plain

このように業務も機能も幅広く存在するのが現在のクラウドサービスの状況ですが、それに加えて複雑さを増しているのがインターフェースです。

5つのカットで見るデータを扱う難しさ

インターフェースの多様さは大きく5つのカットで捉えることができます。

  • Protocol
  • Data Model
  • Metadata
  • Authentication
  • Capability

まず一番大きなレイヤーでいくと Protocol でしょう。Web APIに接続するのであれば、HTTPレイヤーのプロトコルは必須ではありますが、HTTPレイヤー上で

SOAPは現在主流ではな無くなっていますが、依然 Salesforce・NetSuiteなど重要なパッケージで利用されています。 また、RESTに関しましては今最も主流のAPIデザインですが、あくまでAPIアーキテクチャスタイルであり、その実装は各API毎で千差万別です。これも単純にAPIというものを捉えることができない重要な要因です。

f:id:sugimomoto:20200131131821p:plain

また、データモデルも多様化しています。上記のように今までであればリレーショナルな形式のみ認識してればよかったですが、NoSQLに代表されるDocument・KeyValue、JSONフォーマットであればネステッドなレイヤーも意識しなければいけません。

f:id:sugimomoto:20200131131827p:plain

さらにデータ分析を行う上で、スキーマは最も重要な要素ですが、残念ながら多くのインターフェース、APIではスキーマが提供されていないのが実情です。

もちろん中にはStaticなモデルであるため、固定的なスキーマを当てはめればいいものもあるかもしれませんが、ユーザーのカスタマイズニーズに答えるようなkintone や Slaesforceといったクラウドサービスでは Dynamics なスキーマ・データモデルがスタンダードです。

f:id:sugimomoto:20200131131834p:plain

更に私達が最も気にしないといけない要素は認証・Authentication部分でしょう。データ分析としては必要のない要素であったとしても、この要素をかいくぐらなければ、私達はデータにアクセスすることすら叶いません。

BasicやNTLM・Kerberosといったスタンダードとなっているプロトコルもありますが、現在のWeb APIではOAuthが主流でしょう。しかし、少しでもセキュリティの意識が高い企業であれば、SSO対応やデバイス証明書の流れを組んでいるものもあります。

f:id:sugimomoto:20200131131840p:plain

最後に私達は各Web APIスペシフィックなインターフェースの機能に対応しなければいけません。

例えば世の中に数多く存在するWeb APIは、ほとんどが集計処理に対応していません。またエンティティ、リソース同士をJoinすることもできませんし、特定カラムのみしかフィルターをサポートしていないというのも日常茶飯事でしょう。

f:id:sugimomoto:20200131131847p:plain

上記にあげたのは全体像を捉えるためのキーワードの羅列にすぎませんが、私達はこういった要件を制約を機能をかいくぐりながら、マルチクラウドサービス。マルチSaaSの時代をデータドリブンしていかなければいけません。

では、私達はいかにマルチSaaS・マルチクラウド時代のデータ分析基盤を整えるべきか?

おそらく大変のエンジニアであれば、APIの一つや2つの連携実装くらい、どうということは無いでしょう。

しかしながら、前述の1企業あたりにおけるクラウドサービス・SaaSの利用拡大を踏まえると、一つ一つ手動で作り込みをしていたら、追いつかない状況になっている状況であることは明確です。

用途やプラットフォームに合わせて連携アプローチを変えていく必要があります。 如何に低コストで膨大なデータを活用するか?

・インターフェースを整えてくれるツールを最大限に活用すること。 ・扱いやすいデータ基盤に投入すること。

「素早くローディングし、アドホックに分析できる環境を整えること」

そういった際にELTツール(データプレパレーション)とDWHの連携、データマートとしてBIツールを使うのが現在のスタンダードです。

  • CDataSync
  • Azure DataFactory
  • Power BI DataFlow
  • AWS Glue
  • Google Data Fusion
  • Tableau Prep
  • Embulk
  • Talend

ELT的 Dynamics 365 アプローチ:業務担当者が接しやすいBI

そんな中で最近特に興味深い Dynamics 365 的アプローチがありましたので紹介したいと思います。

それが「Dynamics 365 / PowerApps CDS のデータフロー機能」です。

f:id:sugimomoto:20200131131856p:plain

https://docs.microsoft.com/ja-jp/powerapps/maker/common-data-service/create-and-use-dataflows

データフローでは Dynamics 365 / CDS へ簡単に AccessSharePoint リストなど30種類ほどの外部データを簡単に取り込める機能です。

f:id:sugimomoto:20200131131902p:plain

何がいいかと言えば、データフローで取り込んだデータは Dynamics 365 のデータモデルとして直接扱うことができる点です。

通常はマスタデータ同期であったり、名刺データの取り込みといったアプローチに使われることが多いのですが、データモデルとして扱えるということは、顧客と関連付けてDynamics 365のデフォルトダッシュボード機能などで分析やアクションに繋げることができるというのが大きなポイントです。

f:id:sugimomoto:20200131131907p:plain

また、データフローはODBCの接続をサポートしており、CData ODBC Driver を組み合わせることで、200種類のデータ接続先をカバーすることが可能になります。

www.cdatablog.jp

f:id:sugimomoto:20200131131919p:plain

例えば、以下の画面は Google Analytics から各コンテンツのPVを Dynamics 365に連携したものです。Dynamics 365にはマーケティングのモジュールもあるため、マーケティング施策がフィードバックとして適切にサイト流入にも反映されているかどうか、といったところが一つのインターフェースで見れるようになります。

f:id:sugimomoto:20200131132029p:plain

まとめ

世の中のデータは指数関数的に増えていますが、それ以上に多様なインターフェースが存在し、その複雑さが顕著になってきています。

直近のデータ連携のトレンドとしても、データ加工や安定的な稼働よりも、データ接続先の多様さが連携ツールに求められてきていることがわかります。

f:id:sugimomoto:20200131132358p:plain

www.cdatablog.jp

スケーラブルかつ柔軟なDWHが増えて、データ加工の処理コストが大きく下がり始めている今、注力するべきはバラバラデータを如何にコストパフォーマンスよく収集することではないでしょうか。

f:id:sugimomoto:20200131132642p:plain

様々なツールをうまく活用し、一つ一つ手組ではなく、全体効率として適切なアプローチをとっていくことが今後ますます重要になってくると思います。