SupershipでDatapiaのプロジェクトマネージャーをやっています。アドテックに来られている方の中では、SupershipはDSPやSSPといったアドテク関係で名前を知っていただいているかと思いますが、実は昨年から非マーケティング領域におけるデータの事業に取り組んでおります。データ分析においては、「自社のデータベースがいくつもあるけどそのデータベースを全く活用できていない」「社内のメンバーなのに自社データのアクセス権限をもらえていない」「環境が複雑すぎて、分析の準備をしていたら時間がなくなってしまった」といった問題を皆さん抱えてらっしゃるかと思うのですが、Datapiaを使うことによってそれらを解消するサポートをしていきたいと考えています。分析やレポートの作成におけるエンジニアの負担を軽減させ、ビズサイドが現場でアジャイル的にデータ活用できる=「データの民主化」を実現できるプロダクトがDatapiaです。Housmartの取締役兼CTOの高松と申します。弊社では、カウルというtoCのプロダクトと、PropoCloudというBtoBのプロダクトを手がけています。PropoCloudは、不動産営業マンの物件の提案作業を自動化するツールで、CRMと物件データが融合したようなイメージです。不動産を購入する人は、検討から購入までだいたい6ヶ月から2年ほどかかるのですが、その間、営業マンは物件データを検索してPDFを作って送付するという手間のかかる作業を続けており、それを自動化するものです。実際、1ユーザー送るのに45分から1時間ほどかかっていたのが、このツールを使うことで1分程で完了させることができます。データを活用した業務効率化などに取り組んでいるので、今回は「不動産テック業界における、データ×DX」といった文脈でお声がけいただいたのかな、と思っています。本日はよろしくお願いします。1つ目のテーマにいきたいと思います。「DXを支えるデータマネジメントの重要性」ということで、なぜデータマネジメントが必要なのか?という導入の部分から始めていきたいと思います。DXという言葉をどうやって捉えるかは、個人や企業によって異なるかと思います。個人的な解釈なのですが、データや、今までの顧客接点をデジタル化し、コミュニケーションのみならず商品開発といった段階まで活用を進めることで、顧客に提供する価値を革新したり、価値提供までの生産プロセスを改善することだと思っています。それを実現しようと思った時に、まず大前提としてデータマネジメントがかなり重要になってきます。新しいビジネスに取り組むためには、データの中からアイデアだったりインテリジェンスを見つけ出さなければいけないわけですが・・ひらめくときは一瞬でひらめくものの、頭をひねっている時間はかなり長くかかっていると思います。その「頭をひねる時間」を作るためにも、データマネジメントに使う時間は最小限に抑えたいですよね。データを分析するにしても、必ずしも統計的に有意差が出るわけではありません。「なんとなく、ここに特徴があるっぽいな・・」というセンスを磨くことが大事ですが、そもそも適切なデータマネジメントを行えていないとその“香り”すら感じ取ることができないという状態になってしまいます。この2点を鑑みると、時間を無駄にしないという意味でも、アイデアを潰さないという意味でも、データの信頼性をしっかりと担保することは欠かせませんし、そのためにもデータマネジメントが重要になってくると考えています。DXと言うと「アプリを作ろう」とか「新しいビジネスを始めよう」といったふうに捉える方が多いと思いますが、今やっている不動産会社を念頭にお話しすると、日常の業務オペレーションをしっかりとデジタルに落としていって、そこから出てくるデータを利活用していこう、ということがまず第一義に来ると思っています。最近では様々なSaaSプロダクトが出てきていますが、今後は、それらを導入して出てくるデータを、統合し活用することがテーマになってくると思います。例を挙げると、オフラインの業務で入力したデータを、WEB上のマーケティングでも活用する、といったことが考えられます。実際にデータマネジメントを進めようとする時に立ちはだかる課題とは?ということで・・まず「データベースが分散して一元管理できない」というものですが、これについては良いソリューションが出てきたような気もしますが(笑)。ありがとうございます(笑)。いった課題を解決したいということで、Datapiaを10月にローンチしたのですが、おかげさまでお問い合わせも多数いただいております。した中で様々な企業のお話を聞いていると、そもそもデータベースが分散していないというお客様がいらっしゃいませんでした。いうのも、複数のデータベースを持つことが最適解だということなのだと思います。複数持てばそれで良いというわけではありませんが、どうしてもデータによってそれぞれ性質は異なりますよね。「システム的にはこっちのクラウドが安定してるけど、解析系だとライブラリはあっちのほうが充実してるからあっちのクラウドを使いたい」とか、あとは「個人情報系のデータはクラウド上に出してはならない」という会社のポリシーがあったりと、それぞれに事情があり、個別最適の側面が強い領域だと思います。いったお話を聞いていると、なんとなくこのプロダクトのコンセプトは時流に乗っているのではないかという実感を得たりもするのですが、逆にテックサイドの方から見て、その辺りの実情は実際こうなっているというお話を伺いたいですね。バラバラになってしまっている現状についてですよね。先ほど話していたことにはなるのですが、SaaSプロダクトによるデータがそれぞれバラバラに保存されていて、それを横断で見ようとした時に、データを集める場所をひとつ作る必要があるというのは感じているところです。私もこの・・サイロ化という言い方もされていますが、その一つを担っているようなプロダクトを作っている者として、バラバラになっている現状は良くないという話は聞きますし、実態としてそうなのだと感じています。そのデータへ容易にアクセスできるようにして、蓄積し、別々のソースのデータを一つのものだと紐づけることが必要になってくるかと思います。Service)は最近結構伸びてきていて、ご存知の方も多いかと思います。この分野が増えてくると、SaaSを1個入れたら、例えば既存のサービスが3つあったら3つ連携させなければいけない、サービスを増やしたら今度はSaaSと4つ連携させなければいけない・・と、加速度的にデータベースの分散が進み、サイロ化が深刻になっていくという状況が近い将来やってくると思われます。Service)という概念が活きてきます。プラットフォーム間を連携するものをサービスとして提供しているのがiPaaSで、Datapiaはそこに位置付けられるプロダクトとして提供しています。日本国内ではまだまだ浸透していないところではありますが、さきほど申し上げたようにその需要は急速に増えていくと考えています。課題という面で言うと、そもそも「データの蓄積〜統合〜分析〜活用」までの全体の絵をしっかりと描ける人が必要だと考えています。その上で、どう統合し結び付けられるかが最大の課題ではないでしょうか。全体を見ることができて、では実際にデータマネジメントに取り組んでいきましょう!となった時に、「エンジニアリソースが無い」という課題も新たに出てくるかと思います。なった時に、エンジニアのリソースを使わずに済むプロダクトというのは・・・これもまた宣伝みたくなってしまっていますが(笑)。Datapiaがある!という話かもしれませんが(笑)、弊社では、エンジニアリソースを全く使っていないわけではありませんが、自前でBigQueryにデータソースを全てつなぎこんでDWHを構築しています。BigQueryはかなり優秀で、開発コストも含めてかなりリーズナブルに抑えられていますね。エンジニアの間では「BigQuery万能説」とも言われたりしていますね。BigQueryを導入しているお客様は実際かなり多くて、提供しているWEBサービスはAWS上で構築しているけど、解析はBigQueryでやりたい、といったケースはめちゃくちゃ多いです。ここで本当にエンジニアリソースが全くかからずにできるようになれば素敵ですね。スピード感を持って出来るのは良いですよね。エンジニアはここ以外の領域で力を発揮できるわけですし、重要性が変わることはもちろんないと思いますが・・。「このデータの出どころは◯◯(サービス名)の管轄だから、ここには出してOK、あそこはNG」・・といった話ですね。後は、先ほどお話ししたデータ活用の全体の絵が描けていないと、投資すべきという判断も難しいかと思います。データの出口も用意して、こうやって分析して結果はこうなります、という話をできないと厳しいですね。意思決定の組織問題に関しては「データクオリティの責任を誰が取るのか」という点が様々な企業で話題に上がっています。Officer=最高データ責任者)といったポジションが求められています。本当にしっかりとデータを活用したいのであれば、CTOだけではなく、それぞれにおける責任者を置く必要性があると思います。データの作成者がわからず、そのデータについて話を聞きたくてもたらい回しにされてコミュニケーションだけで時間を浪費してしまう・・ということも起こっているので、「データオーナー」という概念ももっと普及していかなければいけないと考えています。ここまでお話しいただいた、課題とその対処法をふまえて、続いてはデータマネジメントを一歩進めるためにどうすればいいかを考えていきたいと思います。これは視点の違いであると考えていまして、「営業部」とか「マーケティング部門」、はたまた「個人」という、小さい1個1個の組織の個別最適を考えるのであればそれでいいと思うのですが、会社としての全体最適を考えると、誰かが必ず割りを食っているんですよね。それが裏側にいらっしゃる、高松さんのような、BigQueryにデータを送るパイプラインを作っているエンジニアの方々だと思います。私自身も過去そうだったのですが、GoogleやFacebookから管理画面のレポートを落としてきて、それがいわゆる“データ”であると思っているとあまり良くないと思います。ダッシュボードで出てくるグラフなのか、それとも、データベースに入っている表形式のデータなのか、はたまた、正規化されていない1レポートずつ雑然と並んでいるものなのか・・・と、「データ」という言葉の捉え方次第でコミュニケーションにおけるすれ違いがかなり起きてしまいます。マーケター側が「こういうデータ出しておいて!」とつい簡単に言ってしまうものでも、実はエンジニアが裏側でめちゃくちゃ処理してやっとの思いで綺麗にして出している・・という、「現場が楽できているのは結局エンジニアが血反吐を吐いて頑張っているから」という現実をもう少し現場が意識しないと、社内のコミュニケーションは上手くいかないと思いますね。DXを何と捉えるか?という点はありますが、冒頭にお話ししたように、そもそも今の業務をシステムに乗せて効率化したり、日常業務の中でデータ化するプロセスが無いのであれば、弊社が提供しているものなど、いろいろとイケてるSaaSがあるので、そういったものを入れていくところからまず始めるのが良いのではないでしょうか。その次に、データ蓄積から活用までの全体の図を、データの入り口・出口、他のサービス同士での連携まで描いてからようやく次のステップに進めるのではないかと思います。難しいですね・・結局のところ、マーケティング、データ、エンジニアと、3つの分野の素養が揃っている方がベストですが、それはなかなか難しいので、その3つを揃えるという前提でチームを作るのが良いのではないでしょうか。いった専門家の方にお話を聞いてみるというのは良いと思いますね。自分の開発プロジェクトの体制もそうなっているのですが、「エンジニアの気持ちがわかるビジネスサイド」と、「ビジネスサイドの気持ちがわかるエンジニア」は、一人ずつ架け橋が必要だと思っています。そこをブリッジしているのが1人だけというケースも多いのですが、やはりブリッジしてくれるメンバーが両方の出身で1人づついるのが理想ですね。翻訳者は2人いないと厳しいです。これは人材というより思想の問題になってきますが、現時点の環境を見て「これがベストだ!これで行こう」と言って始めたとしても、おそらく2、3年後にはもう環境は変わっています。環境が変わっても適応し続けられる構成や体制を常に考え続けられる思想を前提に持っておかないと、データマネジメントはすぐ破綻してしまうと思います。1発入れてそれで終わりではなく、入れてからちゃんと維持していくことも大事だということですね。最近よく言われている「SDGs(持続可能な開発目標)」ではないですけれども、それに近い考え方で、適応し続けることが大事だと思います。エンジニアはビジネスサイドを理解し、ビジネスサイドはエンジニアを理解すべき、というのは私たちも“わかりみ”があって、仕事をしていても、エンジニア側に寄り添ってくれる人がいるからこそ支障なくできているんだなというのは普段からすごく感じているところではありますね・・・。秋山が加わり講演やパネルディスカッションを行います。✓データマネジメントを活用して売上を伸ばしたい!✓情報が分散していて、データを整理することで業務を効率化したい!✓溜めたデータを上手く活用したいと考えている・・・という方はぜひお越しください!▼詳細はこちらのバナーからどうぞ▼DatapiaDatapia(データピア)は、オンプレミス・マルチクラウドにサイロ化したデータベースを横断してひとつのシステムで統合管理することができる、ハイブリッド環境に対応したデータマネジメントシステムです。Inc.PAGETOP。