アシストが挑戦するMDS ～データ活用基盤をSnowflakeで構築～

クラウドネイティブなサービスを組み合わせて実現する新たなデータ活用基盤のコンセプト「Modern Data Stack」への関心が高まる中、アシストではその関連製品としてデータクラウドの「Snowflake 」の取り扱いを開始しています。
同時に「自社でも活用してみよう」という考えのもと立ち上がったのが、Snowflakeによる社内データ活用基盤構築のプロジェクトです。
しかし構築リーダーに任命されたのは、BIツールの経験はあるもののデータベースは全くの初心者である企画職。そんなリーダーが試行錯誤しながらも「お客様の声」を分析するデータ活用基盤を構築するまでの軌跡をお届けします。

Modern Data Stackへ挑戦、第1弾はSnowflake

アシストでは、新事業として「Modern Data Stack（以下、MDS）」製品を取り扱うとともに、その自社活用にも挑戦しています。まずはその背景を紹介します。

Modern Data Stackとは？

近年、DXの取り組みが加速すると同時にデータ活用の重要性が叫ばれています。その中でデータ活用基盤の新たなトレンドとして広まりつつあるのがMDSです。

昨今のデータ活用基盤構築では、オンプレミスで構築された既存環境をいかにクラウドへリフト＆シフトして運用していくかという流れが見られますが、MDSはそうした考えの延長線にはありません。フルマネージドサービスを前提に組み立てる考え方であり、具体的にはクラウド型のデータウェアハウス（DWH）を中心に様々なデータ関連技術を組み合わせて構築します。
_{MDSについて詳しく知りたい方はこちら を参照ください。}

MDSが注目を集める背景には、
・既存のDWHではパフォーマンスが出ない
・メンテナンスコストが高い
・データがサイロ化して、見たいデータが思うように見られない
といった企業の課題が挙げられます。

データベース未経験者がSnowflake環境構築のチームリーダーに

アシストでは新事業の一つとしてMDS製品の取い扱い拡充と関連サービスの提供に挑戦するべく、その第1弾製品「Snowflake」を取り扱うためのタスクフォースを発足しました。お客様のデータドリブン実現を支援するための体制を確立する取り組みです。
その取り組みの中で、アシスト自身がSnowflakeを核にした次世代のデータ活用基盤を構築・活用することにより、その体験やノウハウをお客様にお伝えすることを目指した社内実践がはじまりました。その社内実践のチームリーダーに任命されたのが、弊社DX推進技術本部 事業推進部 我満美帆子です。

慎重に決定した目的と対象データの選定

「全員が見たくなる」新しいデータ活用基盤を作りたい

活動が本格化する前にリーダーの我満は、どのようなデータ活用基盤を構築するか検討を始めました。

単にデータ活用基盤を作るならば、既にある社内DWHのレプリケーションを作れば事足ります。しかし、それではゼロからデータ活用基盤を構築するお客様の気持ちやつまずきなどを理解する機会が少なくなるため、プロジェクトの目的にそぐわなくなってしまいます。

活用できるデータが既存のDWHと同じなら、社員の利用は進まないだろうと考えました。目的を持って社員に活用してもらうには、社員がまだ見ることができていないデータがいいのではないかと考えていた折に「アンケートツール『Qualtrics』で集めていたお客様の声がピッタリでは？」とひらめきました。

3つのSaaS製品をSnowflakeで統合するデータ活用基盤を作る

Qualtricsのデータを見るだけであれば、同ツールから出力するだけで済んでしまうため「新しいデータ活用基盤で見たい」と思ってもらえるように、利用者のニーズを探り整理しました。

その結果、データから
・アンケート回答者の所属情報
・アシストとの接点や取引状況
・アシストの担当営業

といった情報も併せて可視化できるように「Qualtrics」に「Salesforce」や「Account Engagement（旧Pardot）」をデータソースに加えたデータ活用基盤をSnowflakeで構築することに決めました。

「Think Big,Start Small,Scale Fast」を意識してゴールを設定

目指すのは、アシストの研修サービスやキャンペーンのアンケートで取得したお客様の声の可視化です。お客様接点と満足度の相関を調べるために、サポートのお問い合わせやイベント参加数、訪問数、Web面談数などのデータも可視化対象としました。

お客様の声は弊社のサービスに対するフィードバックであるため、関係者が定期的に確認・モニタリングしてサービス改善につなげられるようにすることが重要です。お客様の満足度が利用製品・研修コース・イベント・担当部門・対応者によって異なるのかを俯瞰的に分析できるようBIのアウトプットを設計しました。

このプロジェクトでは、大きく描きつつも小さく始め、素早く拡張できる「Think Big , Start Small , Scale Fast」を意識しました。そのため、初期構築では1つの研修アンケートのみを対象にすることにしました。

Snowflake構築の道のり：
データの収集からデータマートの構築まで

ここからはデータ活用基盤の核となるSnowflake構築の過程を詳しくご紹介します。

Snowflakeの構築

はじめに行ったのが、Snowflake環境の名称決定です。「たくさんのデータを受け入れて蓄積し、関係するデータと人を温める使い方をしたい」という意味を込めて「かまくら」に決めました。

かまくらが目指すのは必要なデータを収集して、加工し、可視化用のデータマートを作ること。一見シンプルに思えますが、実際は一筋縄ではいきません。そこで実感したSnowflakeの特長や、構築時の苦労とその乗り越え方についてお話しします。

_{※データマートとは、データウェアハウスに格納された多様なデータを用途、目的などに応じて必要なものだけを抽出、集計し、利用しやすい形に整形したテーブルの集合体}

データの利用許可を得る

構築の最初のステップは、データソースとSnowflakeの接続方法を決めることでした。SalesforceやQualtricsには機密性の高いお客様情報が含まれるため、社内のセキュリティポリシーに則り情報システム部門に利用申請をしなくてはなりません。さらに、SnowflakeにそれらのSaaSからデータを連携するための仕組みも検討する必要がありました。しかし、ETLなどのデータ連携ツールは情報システム部門が管理・運用しており、簡単には使わせてもらえません。

そんな時、検証目的で既に各SaaSとのデータ連携が確立されている別部署で構築したSnowflakeが目に留まりました。ガバナンスが考慮されている別部署のSnowflakeから、今回の可視化に必要なデータだけを取得できるようにマスキングを行うことによって、新たなデータ利用申請は最少限で社内セキュリティポリシーを遵守することができ、情報システム部門からもデータの利用許可を得ることができました。

SnowflakeのData Sharingを活用したデータ連携

データソースは確保できたものの、別部署のSnowflakeからどのようにかまくら（Snowflake）にデータを連携するかが次の問題となりました。従来のデータベース間のデータ連携では、提供元データベースからデータをエクスポート後に対象データベースにインポートが必要で、併せてその後の差分更新の方式についても検討が必要になります。

しかし、SnowflakeのData Sharingを使用すると、Snowflake同士であればデータコピーや転送を発生させずにリアルタイムにデータを共有することができました。もちろん必要な列や行のみ共有することも可能です。この機能により、ものの数分で別部署のSnowflakeから必要なデータをセキュアにかまくら（Snowflake）へ連携することに成功しました。

データの中身を確認しながら、データ加工処理の検討

かまくら（Snowflake）へのデータ連携が決まりましたが、データソースのテーブル構造そのままでは簡単に可視化することはできません。テーブルが正規化されているため、可視化で欲しい情報は複数のテーブルを結合しないと見ることができません。またテーブル名や列名はシステムの画面上で見ているものとデータベース内では異なり、データを参照するときに指定するデータベース内の列名は全てアルファベット表記になっています。さらに複数のテーブルを結合する際、どの列をキーにして結合するかといった見極めも必要です。

そこで、データの加工処理は自分の手元で確認しながら、トライアンドエラーを繰り返して検討しました。この作業にはQlik Senseを利用することでデータ加工処理の実装とその結果確認を簡単に行うことができ、非常に効率良く作業を進めることができました。

Snowflakeにデータマートを構築

可視化に必要となるデータマートの形が整い、いよいよかまくら（Snowflake）にデータマートを構築しました。ここでは物理テーブルと仮想ビューの選択がポイントでした。物理テーブルは複雑なクエリや大量データの高速処理に適していますが、テーブル設計、更新タイミング、ストレージリソースの考慮が必要です。今回のデータは大容量ではなく、BIのレスポンスも考慮が必要なかったため、運用の設計が不要でリアルタイムデータ連携が可能なビューを選択しました。

なお、データ加工は全てかまくら（Snowflake）上で行うことにしました。Qlik Senseで検討した結合などのデータ加工処理をSQLに読み替える必要がありましたが、生成AIを使うことでSQLにそこまで詳しくなくても簡単に変換・実装することができました。

「とにかくやってみる」姿勢が一番のポイント

今回のデータ活用基盤構築を振り返り良かったことは、手を付けられるところから始めてアジャイルに進めたことでした。これはSnowflakeという新しい技術を使ったから可能になったとも言えます。伝統的なデータベースでは、机上で考えた上で設計してテストして実装という手順が当たり前でしたし、特にリレーショナルデータベースでは、キーを考慮するなどデータベース設計の経験が求められます。

実際に経験してみてお伝えしたいのは「作業の手戻りを恐れるな」ということです。「1回やってみてダメだったら戻ればいい」という考え方で進めた方がむしろ速く目的を実現できると感じました。もちろん、今回はこの方法で無事データ活用基盤を構築できましたが、一つの方法に固執しないことも重要です。影響範囲がより小さく対応しやすい方法があれば、その方法を積極的に取り入れる方が良いと思います。

そしていよいよ「かまくら」を利用した、お客様の声の分析が始まります。
今後は貴重なお客様の声を分析し、さらなる「お客様の体験価値向上」の貢献にチャレンジします。