外部データ製品の構築がなぜ難しいのでしょうか?

著者 |リオル・ガビッシュ

翻訳者 |ザイ・ケ

企画 |ウー・ムー

強力なエグゼクティブダッシュボード、機械学習を活用したマーケティング用の予測購入者モデル、BI チーム用の新しい顧客モデルなど、社内データ製品の開発は、データチームが会社に付加価値をもたらす最も効果的な方法の 1 つです。

ただし、外部データ製品の開発は少し異なります。価値を付加するのは簡単ですが、より困難でもあります。これは異なるアクションであり、チームが新しい習慣を構築する必要があります。

同時に、外部データ製品の開発は、より高いレベルの調整、規律、厳格さを必要とする新しい考え方でもあります。

ただし、同じチームで実行できない、または社内のデータ利用者が外部の顧客と同じレベルのサービスを受けられないということではありません。

レストランの POS プロバイダーである Toast のデータエンジニアリングマネージャーである Noah Abramson 氏は、最近この分野での経験について次のように語っています。「当社の大きな価値提案の 1 つは、お客様にビジネスインサイトを提供することです。レストランの業績は長期的にどうなっているでしょうか。昨日の売上はいくらでしたか。一番の顧客は誰でしょうか。レストランのお客様と関わるのがデータプラットフォームチームの仕事です。私たちは、お客様は Toast の従業員であると考えています。私たちは、従業員全員ができるだけ多くのデータにアクセスできるように努めています。当社のチームは、製品からマーケティング、カスタマーサポート、ハードウェア操作まで、すべての社内データアクセスに対応しています。」また、幸運なことに、過去の仕事では、モンテカルロのデータ観測プラットフォームで内部データ製品だけでなく外部データ製品も構築する機会がありました。

この記事では、これらの教訓をまとめ、データチームが社内製品の構築とは異なる以下の 5 つの重要な側面を理解することで、外部データ製品を成功裏に立ち上げる方法について説明します。

建築
ユーザーの期待
投資収益率
セルフサービス
反復

しかし、まず、外部データ製品またはデータアプリケーションが正確に何であるか、そして開発されたアプリケーションの種類が意思決定にどのように影響するかを理解することが重要です。

外部データ製品とは何ですか?データアプリケーションの例にはどのようなものがありますか?それらはあなたの意思決定にどのように影響しますか?

外部データ製品とは、顧客が直面する、または顧客に影響を与えるデータ資産のことです。これは、顧客請求プロセスに使用されるデータセットから、顧客操作用の独自のユーザーインターフェイスを備えた完全にスタンドアロンのデータ集約型アプリケーションまで多岐にわたります。

現在、データ分野で最もホットなトレンドの 1 つは、前述の Toast 社のように、企業がデータアプリケーションを作成したり、SaaS 製品内にレイヤーを追加して、顧客がデータを分析できるように支援することです。

Snowflake には、5 つの一般的なデータアプリケーションタイプ (リファレンスアーキテクチャ付き) の便利なリストがあります。

Customer 360: マーケティングまたは販売の自動化には、顧客関係の完全なビューが必要です。
モノのインターネット: IoT デバイスやセンサーからの大量の時系列データをほぼリアルタイムで分析します。
アプリケーションの健全性とセキュリティ分析: 大量のログデータを分析して、潜在的なセキュリティの脅威を特定し、アプリケーションの健全性を監視します。
機械学習 (ML) とデータサイエンス: 機械学習モデルをトレーニングおよび展開して、推奨エンジンなどの予測アプリケーションを構築します。
組み込み分析: アプリケーション内で提供されるブランド分析と視覚化。

ただし、外部データ製品は、完全に組み込みのアプリケーションである必要はなく、メインの SaaS 製品に統合する必要もありません。これは、たとえばモンテカルロ法のアプローチではありません。

当社は、ユーザーインターフェイスで監視、警告、ヒントを提供するデータ集約型の SaaS アプリケーションです。また、ユーザーインターフェイスで顧客にインサイトレポートを提供し、顧客自身の Snowflake 環境内で Snowflake Data Share 統合を使用するオプションを提供することも可能です。

後者の場合、当社はお客様に、視覚化方法をさらにカスタマイズしたり、他のデータと組み合わせたりできるようにするビルディングブロックを提供します。

データアプリケーションまたは外部データ製品が何であるかを総合的に理解することは重要です。これにより、チームはより厳密な方法を適用し、エンジニアリングの外部でエラーが発生しないようにすることができます。

以下の質問は重要です:

どのような外部データ製品があり、それらはどのような種類ですか?
彼らは誰に仕えているのでしょうか?ユースケースは何ですか?
彼らはその期待に応えているでしょうか?これをどうやって測定するのでしょうか?
適切なツールとプロセスが導入されていますか?

次の 5 つの側面に沿って外部データ製品を評価することも重要です。

建築

内部製品と同様に、外部データ製品では、データレイクやデータウェアハウスなどのさまざまなデータクラウドサービスをプラットフォームの基盤として活用できます。

ただし、リレーショナルデータを大規模に保存およびクエリする方法を最適化するため、多くの企業が Snowflake のようなソリューションを活用するでしょう。チームがマルチテナントアーキテクチャについて議論するのは今回が初めてかもしれません。これは、外部のクライアントにサービスを提供する際の大きな変化と意思決定のポイントです。

Snowflake は、データウェアハウスを製品の基盤として活用する場合の 3 つのマルチテナント設計オプションについて説明しています。

マルチテナントテーブル: テナントを 1 つの共有オブジェクトに集中管理し、テナントがコンピューティングやその他のリソースを効率的に共有できるようにします。
テナントごとのオブジェクト: 同じアカウント内でテナントを個別のテーブル、スキーマ、データベース、ウェアハウスに分離します。
テナントごとのアカウント: テナントを個別の Snowflake アカウントに分離します。

それぞれのオプションには長所と短所がありますが、一般的には、共有コンピューティング/ストレージかロールベースのデータアクセスのどちらをより効率的に拡張する必要があるかによって選択が変わります。

ほとんどの社内製品は同じ会社内で提供され、同じ社内ポリシーと規制が適用されます。たとえば、マーケティングチームのデータ資産が法務チームのデータ資産と同じウェアハウスにあったとしても、彼らは不満を抱くことはないでしょう。しかし、外部の顧客はもっと懸念しているかもしれません。

もちろん、スタック内で他のアーキテクチャを選択して、これらのトレードオフを軽減することもできます。たとえば、Monte Carlo は Snowflake の MTT マルチテナントアーキテクチャを活用し、トークン化などの業界のベストプラクティスを使用して顧客データを論理的に分離します。さらに、当社ではハイブリッドアーキテクチャを使用して、データコレクターを顧客の環境に組み込みます (ただし、通常は独自の仮想プライベートクラウドとして組み込むわけではありません)。

つまり、データは環境から外に出ることはありません。 PII と機密データは抽象化され、データシステムの健全性を評価するために必要な、機密性のないログとメトリックの集計が抽出されます。

内部データ製品と同様に、アーキテクチャ決定プロセスのもう 1 つの部分は、ユースケースとワークロードを理解することです。必要な頻度、規模、タイムラインはどれくらいですか?クライアントは設定された時間にデータを受信するのか、オンデマンドでデータを照会できるのか、リアルタイムでデータにアクセスするのか、それともこれら 3 つすべてを組み合わせるのか?前述したように、ワークロードを理解することは、コスト効率の高いアーキテクチャの選択を行う上で非常に役立ちます。ただし、外部製品とは異なり、サポートする必要があるユースケースは多岐にわたる可能性があります。

Monte Carlo を構築する際には、ミッションクリティカルな本番ワークロードだけでなく、社内のチームが外部向けのデータにどのようにアクセスするかも考慮する必要がありました。この場合、機械学習を活用した異常モニターの開発の一環として、社内分析とデータサイエンスの研究が行われました。

ユーザーの期待

ユーザーが一般的に信頼して、いくつかの質問に答えられるデータ製品があるとします。データは毎日更新され、ダッシュボードにはクリック可能な要素があり、詳細な情報にドリルダウンできます。

一部の社内ユーザーにとってはこれで十分かもしれません。ダッシュボードがない場合よりも、仕事をより効率的にこなすことができます。一方、外部のユーザーは怒っています。顧客はあなたの製品を信頼し、すべての質問にリアルタイムで答えてほしいと思っています。

彼らはなぜ怒ってはいけないのでしょうか?結局のところ、彼らはあなたの製品にお金を払っているのであり、競合他社の製品を選ぶこともできたのです。

データが製品である場合、データの品質は製品の品質です。この単純な事実こそが、当社のデータ監視プラットフォームを最も熱心に採用している一部の企業が、自社のデータアプリケーションを強化するためにそれを活用し始めている理由です。たとえば、マルチチャネルデジタル広告プロバイダーの Choozle は、クラス最高のデータ信頼性を実現する大規模なプラットフォームアップグレードを展開する際に、データインサイト機能を採用しました。

「このようなツールがなければ、最終結果の表を監視することはできるかもしれないが、それでは多くの問題が隠れてしまう可能性がある」と、Choozle の最高技術責任者であるアダム・ウッズ氏は言う。表内の何千ものキャンペーンのうち、ごく一部に関連するコンテンツが表示されない場合もありますが、そのキャンペーンを実行している広告主には表示されます。 [データの観測可能性]があれば、妥協する必要がありません。 3500 個のテーブルすべてを監視できます。

データが顧客向けである場合、または顧客向けアプリケーションを動かす場合、品質が悪いと製品が台無しになることもあります。たとえば、同じ主キーを持つ重複オブジェクトを作成するデータの問題により、Netflix で実際に障害が発生しました。

規模と速度の点では、外部の顧客はデータを待つことを望んでおらず、心ゆくまで切り分けたりつなぎ合わせたりできるように、より多くの次元のデータを求めています。たとえば、ある金融サービス顧客は、データの鮮度だけでなくデータのレイテンシ、つまりクエリをサポートしながらほぼリアルタイムでデータをロードおよび更新する能力にも懸念を抱いていました。

Snowflake データ共有と Snowpipe は、データ遅延の削減に役立ちます。 Blackboard は、Snowpipe を使用して S3 からデータを継続的にロードし、バッチロードすることで、レイテンシーの問題を解決し、ETL ワークロードを以前よりも 400 倍高速に実行できるようになりました。

データ次元をスケーリングすると、差別化にも役立ちます。再び Choozle を例に挙げると、Adam のアップグレードされたプラットフォームによれば、 Snowflake によってすべての情報をユーザーが利用できるようになります。たとえば、上位 20 の郵便番号におけるキャンペーンのパフォーマンスを表示できます。また、広告主は、米国の 30,000 のすべての郵便番号のデータにオンデマンドでアクセスできるようになりました。

最後に、データセキュリティとプライバシーの観点から、外部データ製品では、PII を理論上考慮するだけでなく、SOC II などの業界標準を通じて効果的なセキュリティ制御を実際に実証する必要があるかもしれません。

投資収益率

データチームの大部分は、明確な ROI に基づいて評価されていません。実際、皮肉なことに、パフォーマンスに関しては指標が欠如していることが多く、データプラットフォームの製品管理ディレクターである Brandon Beidel 氏によると、Red Ventures の当初もそうだったそうです。

次のレベルはパフォーマンスの測定です。システムのパフォーマンスはどうですか?問題がたくさんある場合は、システムを効率的に構築できていない可能性があります。あるいは、時間とリソースをどこで最適化すべきかを教えてくれます。記録があれば、データチームの評価を「チームはうまくやっている/うまくいっていない」という感覚から、よりデータに基づいたものへと進化させることもできます。

社内データ製品についても同様です。多くの場合、成果は制作コストやユーザーあたりのコストで測定されるのではなく、「新しい顧客データプラットフォームのおかげで、広告費用対効果が 3 倍になりました」というように、アドホックな方法で達成されます。外部データ製品を構築すると、この幸運は消えてしまいます。製品マネージャーは価格設定の方法を理解する必要があり、価格設定は（ある時点で）利益を生むものでなければなりません。製品を構築するための初期コストだけでなく、サービスが提供される際の各コンポーネントのコスト (商品の原価) も知っておく必要があります。

これは、使用量の規模に応じて顧客を差別化、追跡、課金できるデータ製品の内部課金モデルを構築していないデータチームにとっては困難なことです。

セルフサービス

「あはは！」「私たちのチームではすでに社内ユーザー向けにセルフサービスを有効にしており、これは新しいことではありません。」と言います。それは本当かもしれませんが、セルフサービスのレベルと可用性の基準も引き上げられました。

外部の顧客はいつでもデータについて質問することはできませんし、この顧客の解約の可能性が「しかめっ面 5 のうち 3.5」であるという結論にどのようにして至ったかも知ることはできません。データ製品はブラックボックスであってはならず、作業内容を示す必要があります。

UI は直感的で、関連性が即時にわかり、コンテキストが明確である必要があります。

反復

社内データ製品を構築する場合、要件の収集、構築、ビジネス関係者との反復作業を行うため、最初は進捗が遅くなることがよくあります。

その後、チームはすぐに仕事に取り掛かり、次のプロジェクトに進むことが多いです。データのダウンタイムに対処したり、社内の SLA を満たしたりするために、いくつかのパッチや修正が行われますが、概して、これらのダッシュボードを四半期ごとに再構築することはありません。

前述したように、有料の顧客は期待値が高く、フィードバックも多く提供します。ただし、それが来ることを知って、それに備えて準備する必要があります。たとえば、Toast はプロセスの効率性に重点を置いています。「ビジネスのニーズに耳を傾け、それを強力にサポートするだけでなく、スケーラビリティの問題を社内で探して解決します」と、Toast のデータエンジニアである Angie Delatorre 氏は述べています。「以前は 1 時間かかっていた仕事が、今は 3 時間かかるようになったら、必ずその事例を振り返って確認する必要があるため、OKR にも影響が出ます。」

運用のスケーリングに関しては、Snowflake の製品管理ディレクターである Chris Child 氏は次のようにアドバイスしています。まず、すべてのデータを最高の忠実度で 1 か所にまとめます。生データをそのまま公開してください。次に、データアナリストにデータを提供するための再現可能なパイプラインを作成します。何かをするたびに元のデータに戻る必要はありません。

元 Uber データプロダクトマネージャーの Atul Gupte 氏は、データプロダクトを反復処理する際にデータプロダクトを理解することの重要性について説明しました。プロダクトロードマップの優先順位付けの方法、誰のために構築および設計する必要があるか (通常はエンジニア) とアナリストを含む日常的なプラットフォームユーザーについて説明しました。