[レポート] Standing on the shoulders of metrics stores（メトリクスストアの肩の上に立つ） #MetricsStoreSummit

大阪オフィスの玉井です。

（アメリカ太平洋標準時の）4月26日に、Metrics Store Summitというウェビナーが開催されました。

本記事では、セッションの1つである、Standing on the shoulders of metrics storesのレポートをお届けします。

セッション概要

登壇者

• Benn Stancil
  • Chief Analytics Officer at Mode

概要

For as long as analysts have relied on SQL, those in the data community have been trying to figure out ways to make analysis reusable. On the surface, it seems imminently possible and immensely valuable: Software is eating the world; we’re all becoming tech companies; we all use the same tools and try to solve more or less the same problems. Yet, despite that, data practitioners still have to rebuild many of the same models and metrics—from pipelines that clean up Salesforce data to dashboards of daily active users—from scratch.

Our struggles to solve this problem are explained by two phenomena: It’s neither as easy nor as useful to build analytical “libraries” as it appears. There are no frameworks for sharing analytical scaffolding, and the small distinctions in our businesses get amplified into very meaningful differences in our reporting needs. As a result, little of the analysis we create is repurposed across the community, and collective best practices only advance through the slow propagation of tribal knowledge.

The metrics layer could change all this. It, along with other recent developments in the data stack, could provide the technological foundation that finally makes community reusability possible. In this talk, Benn shares how metrics layers have the potential not just to unify a company’s metrics governance, but how they could also shape the giant’s shoulders we’ve long been trying to stand on.

ソフトウェア開発の世界ではオープンソースというものが存在し、それを利用することで、共通の処理をイチから開発せずに済みます。しかし、データ分析の世界（SQL）にオープンソースと呼べるようなものは、まだ存在しません。

データ分析の対象となるサービスが共通してきているのであれば（Salesforceなど）、そのサービスに対するクエリは共通であり、オープンソース（ライブラリ）にできそうですが、そうは問屋が卸しません。同じSalesforceでも、企業によって使い方や定義が微妙に異なるからです。

そういった状況の中で、どうすれば「データ分析のオープンソース化」を実現できるのか、ということについて説明されたセッションです。

セッションレポート

前段

今回は、メトリックストアの肩の上に立つ、という話をします。

私はBennです。今回は、メトリックストアと、それを使って、コミュニティでできることについてお話します。

始める前に私の経歴を簡単に説明しますと、私はModeの創設者の一人で、コラボレーション分析とBIツールを作っています。私はプロダクトチームやデータ分析チームと一緒に多くのプロダクトに取り組んでいますが、インターネットに向かって怒鳴ることにもかなりの時間を費やしています。

そのほとんどはサブスタック（自分のブログ）で行われています。これが私の仕事です。

今日の話がどこから来たのか、もっと知りたい方は、こちらのサブスタックをご覧ください。いくつかのアイディアがあります。

巨人の肩に立つ（オープンソース）

「巨人の肩の上に立つ」ということについて話したいと思います。これは1200年代の言葉ですが、アイザック・ニュートンがこの言葉を引用しています。私がこの言葉を選んだのは、データ分析業界では定期的に出てくるからです。

私にとっては、この言葉はデータ分析業界で最も約束されているが、最も実現されていないアイデアの一つです。過去10年ほどの間に、この業界で最も約束されたが、十分に提供されなかったアイディアの一つで、多くの異なる状況に適用されています。ですから、このフレーズはさまざまな場面で使われています。

最も一般的に適用される方法の1つは、オープンソースです。この象徴としてApacheがありますが、私はこのApacheと何の関係もありません。

オープンソースとして使えるものはたくさんあります。あなたがソフトウェアエンジニアリングの分野で何かをしたい場合、他の多くの人たちもそれをしたいと思っていることは、きっとご存知でしょう。オープンソースのパッケージやフレームワークがたくさんあることが多いです。それはあなたのために大変な仕事をするのを助けてくれます。

たとえば、PythonでHTTPリクエストを作成するようなことをしたい、という場合には、そのためのライブラリがあります。

RubyでWebアプリケーションを構築したいのであれば、そのためのフレームワークがあります。

JavaScriptでデータビジュアライゼーションを構築したいのであれば、そのためのライブラリも充実しています。

他にも同じような問題を解決するために使えるオープンソースのパッケージやフレームワーク、テクノロジーが何千何万とあります。

ソフトウェアエンジニアリングの世界では、このオープンソースのエコシステムが、多くの技術的進歩の基盤となって、より優れたツールを構築することができるんです。なぜなら、私たちが何かを作ろうとするときはいつでも、これらのプロジェクトの肩の上に立つことができるからです。それがオープンソースのものであろうと、プロプライエタリな技術の一部であろうと、関係なく、です。

そのため、データ分析のエコシステムにおいても、多くのオープンソースツールが利用されています。

代表的なものをいくつか挙げましょう。Rでデータを扱うためのツールは、Tidyverseのように、Rでいろいろなことができるオープンソースのフレームワークがあります。

データパイプラインをオーケストレーションするためのオープンソースツールがあります。

予測作成ツールのprophetがあります。

SQLでデータを変換するためのツールがあります（dbt）。

このカンファレンス全体のテーマである、メトリクスを定義し、作成するためのツールもあります（MetricFlow）。

これらのことはすべて良いことです。これらは、業界が持っている強力なツールです。

データ分析のオープンソース化

しかし、私たちデータ分析の人間は、ツールを作るためにいるのではなく、ビジネスの問題を解決するためにいるのです。

このツイートでSarahが言っているように、私たちが知りたいのは、あなたがデータをどのように使っているかであって、あなたが作っているプロダクトやデータスタックがどのようなものかではないのです。私たちは最終的にビジネス上の問題を解決するためにここにいるのであって、テクノロジーを構築するためにいるのではありません。

このことが、長年にわたってデータ分析業界の多くの人々が、ツールをオープンソース化する方法を探すだけでなく、データ分析をオープンソース化する方法、ビジネス上の問題を直接解決するために行おうとしていることをオープンソース化する方法を探すきっかけとなったのです。

ここでの考え方は非常にシンプルです。PythonでHTTPリクエストを行うように、ソフトウェアで解決したい一般的な技術的問題がたくさんあるように、データ分析で解決したい一般的なビジネス上の問題もたくさんあります。

Google広告を運用する中で、何が良いのか悪いのか、広告のパフォーマンスを測定できるようになりたいと思うことは誰にでもあります。そして、みんな同じような疑問を抱いています。

もし私たちがSaaSビジネスをしているとしたら…世の中にはたくさんのビジネスがありますが、私たちは皆、同じように、10個、24個、7個、14個くらいのメトリクスをトラッキングしています。SaaSビジネスを検討する際、私たちは皆、基本的に同じコンセプトについて考えています。

そして、規模が大きくなり、GAAPのようなものを採用しなければならなくなった場合、会計士が必要となります。ある時点で、会計士が私たち全員を相手にして、標準化されたGAAPのレポートを大量に作成しなけれ ばならなくなります。このすべての根底にあるのは、もっと大きなポイントです。

ほとんどのビジネスはほとんど同じで、似たような問題を解決しようとするものなのです。皆、同じ基盤でそれらを構築しようとしています。特にある技術系スタートアップを他の企業と比較すると、多くの点で同じように見え始めるのです。

そこで、広告レポートやSaaSのメトリクスなどの問題を、各企業で個別に何度も解決するのではなく、コミュニティで解決できるような分析を共有することはできないでしょうか。

データ分析チームに所属している人ならご存知でしょうが、職を転々としていると、同じような問題をたくさん解決しなければならない場面に遭遇します。つまり、技術的な巨人だけでなく、データ分析的な巨人の肩の上に立つことはできないか、ということです。

このデータ分析を実際に共有する方法はあるのでしょうか？

私たちのビジネスは同じように見えるだけでなく、実際に同じである理屈があります。しかし、データもますます同じように見えるようになってきています。

データ分析について上述の理屈を適用すると、このような地図ができあがります。

ここには、このような標準的なレポートがすべて用意されています。右側には、SaaSのメトリクス、マーケティング、パフォーマンス、GAAP、レポートなど、私たちのビジネスについて調べたい標準的なものがすべて揃っています。そして、私たちは皆、この土台となる同じツールをたくさん使っています。

CRMはSalesforceなどを使っていますね。

プロダクトでイベントトラッキングを行っている場合は、Segmentのようなものを使って、人々がどのようにウェブサイトを利用しているかを把握します。

HubSpotのようなものを使って、マーケティングキャンペーンを発信しています。

私たちはZendeskでサポートチームを管理しています。

このように、左側にはSaaSツール、右側にはレポートが配置され、LAMPのような状態になります。こうなると、もし私たち全員が同じインプットをして、同じアウトプットをしているのであれば、中間でオープンソースのデータ分析（の仕組み）を用意することはできないのか、という疑問が湧いてきます。

この図の真ん中にオープンソースのデータ分析を導入することはできないのでしょうか？同じようなロジックを使い、今のように真ん中部分を作らなくても済むような仕組みはないでしょうか？

これはとても実現可能なことだと思います。一つの事実として、多くの人が実際にかなり定期的に試しているのです。

例えばFivetranの場合。これは2021年のブログ記事です。彼らは事前にデータモデルを作成し、分析を加速させて、ほぼ瞬時にレポートを作成し、まさにこの種の問題を解決することができるようにしたのです。

dbtは数年前にdbt Packageを発表しましたが、これは同じようなことをするのが目的です。これは「新しいデータを同期して、数分でデータモデルに変換できるようにしたい」ということを可能にする方法です。

Lookerは、2015年にLooker Blocksというものを発表しましたが、これは同じアイデアで、LookMLとダッシュボードがパッケージ化されており、標準的なデータセットにプラグインすることで、もう一方の側から分析を行うことができるのです。つまり、あらかじめ作られたBIツールということです。

このツイートは2016年のものですが、2015年の秋に出ました。

実は、私たちも同じようなことをやっていました。実は2014年に書いたブログ記事があります。個人的に同じことを試みていて、分析結果をオープンソース化したのです。私たちは、社内で行っていることを公開し、誰もがアクセスできるようにしようとしているのです。

この方法は、程度の差こそあれ、成功しました。ただ、例えば、dbt packageは、私がここで発表したものよりもずっと成功していると思います。

しかし、実際のところ、これらは定着していません。

ほとんどの企業は、私たちが同じツールを使っているのと同じように、これらのパッケージやLooker Blocksなどを使って分析を進めているわけではないのです。中には、役に立つものもありますし、役に立たないというわけではありませんが、ツールに関するスタンダードがあるのと同じように、モダンデータスタックで分析を行う方法に関するスタンダードがないのです。

例えば、「how to set up the modern data stack」でググると、たくさんの結果が表示されます。

これは結果の1ページ目のスクリーンショットです。モダンデータスタックを構築する方法について、ベンダーから提供された7つのリンクがあります。

これらのガイドには、実際にどのようにセットアップすることができるかの例が多数掲載されています。ETLツール、ウェアハウス、BIツール、データ変換、リバースETL、オーケストレーション、可観測性、これらすべてについて書かれていますが、packageやBlocks、オープンソースのデータ分析フレームワークについて触れている記事はありません。

使用すべき技術に関するヘルプは大量にあるのです。しかし、データの利用となると、完全に自分たちだけの力になってしまいます。

このままでは、私たちは地面にしっかりと固定され、巨人の後ろに立っているようなもので、実際には何も見ることができないのです。そして、私たち一人ひとりが、自分自身でこれをやらなければならないのです。自分の会社の中で、同じことをしている人がいないかのように、自分のデータ分析を構築しなければなりません。

残りの話は、2つのことに焦点を当てたいと思います。

まず、なぜこれがうまくいかないと思うのか、その理由をお話ししたいと思います。なぜ、私たちはこの問題について長い間考えてきたのに、実際には広まらなかったのでしょう？

もう一つは、この問題に対して何ができるか、そして、メトリクスレイヤーのようなものが、この問題を解決するための実行可能性をどのように変え始めることができるのか、ということについて話したいと思います。

なぜうまくいかないのか？

最初の質問、なぜこれはうまくいかないのでしょうか？

FivetranのCEOであるGeorge Fraserが、Andreessen Horowitzでこれに対する答えを発表しています。

基本的に、Georgeがここで言いたかったのは、この問題の大部分は技術的なものだ、ということです。彼が主張するように、データ分析はほとんどSQLで行われます。SQLには、他の言語にあるようなライブラリやパッケージの概念がないんです。ほとんどのオープンソースソフトウェアは、ライブラリやパッケージを通して他のアプリケーションの中で使われるわけですが、SQLにはそれがありません。Georgeが言いたいのは、この問題を解決することです。

この問題が実際に何を意味するのかを要約すると、次のようなことです。

誰かが、Salesforceのデータをクリーンアップして、チームのパフォーマンスを簡単に評価する方法を見つけたとします。これは実際にFivetranが行ったことです。スライドのクエリはFivetranが実行しているものからコピーしたものです。

これはdbtのFivetran用パッケージで、パッケージライブラリの一種であり、前章で話したものです。このコードをインターネットで見つけて、同じ問題を解決しようとしたとしましょう。

あなたは自分の世界でそれを解決したいと思い、コードエディタを使って、このロジックをSalesforceのデータに適用できるようにしたいのです。現在、SQLにはパッケージライブラリがないため、これを実現する方法は、結局、オンラインで見つけたコードをコピーして貼り付けるだけです。

この方法は明らかにかなり脆弱で、最新の状態に保つのが難しく、非常に面倒で、クエリも複雑です。自環境に翻訳するのは難しいですし、複数のものを翻訳することもあります。コピー＆ペーストが良くない理由はたくさんありますし、パッケージのような方法で拡張することもできません。

Georgeが言うには、このような「データ分析的な巨人の肩の上に立つ」ことを妨げているのは、単にパッケージをインポートして、このように動作させることなのだそうです。

例えば、SalesforceのSQLをインポートするとします。そして、その中の関数を呼び出します。この関数は、Salesforceの商談をマネージャのパフォーマンステーブルに変換します。

これらのディテールのいくつかがどのように機能するかは手探りですが、実現したいことのイメージはつかめるはずです。私は、Georgeと同意見で、これは本当に実現可能だと思います。Georgeが前述の記事で言っているように、dbtは私たちをそこに連れて行き始めています。彼らはこのような種類のパッケージライブラリを持ち、少なくともdbtの環境では動作するクールなものがあり、少しづつこのように見え始めています。

でも、実はこれが一番の問題だとは思っていません。私たちの多くが望んでいるような、オープンソースによるデータ分析の実現を阻んでいるのは、実はこの問題ではないと思うのです。

私が問題だと思うのは、すべてのビジネスが少しずつ違って見えることです。このような小さな違いは、それほど大きくはありませんが、非常に重要であり、ある会社の分析を他の会社の分析に置き換えることを難しくしているのです。

そこで、Salesforceの例に戻って、「Salesforceのデータを整理して、その上にメトリクスを構築したい」と考えてみましょう。収益レポートなどを作成したいのです。

Salesforceのオブジェクトを変換するための標準的な方法があればいい、という考えがあります。

例えば、商談テーブルや口座テーブルを標準的なレポートに変換するようなものです。Fivetranで作ったものをSalesforceの生データに適用するのです。これをパフォーマンスレポートや収益レポートに変換します。そして、その結果をすべて出力することができます。

しかし、Salesforceの使い方は人によって微妙に異なります。Salesforceには標準的なフィールドがたくさんあります。しかし、Salesforceにはカスタムフィールドもあり、誰もがそのうちのいくつかを定義しています。そして、そのようなフィールドを使うことで、その企業のビジネスが成り立っているのです。

例えば、複数年契約をどのように扱うか、誰もが考えなければなりません。2年契約を販売する場合、それは2つの商談として、それぞれ年換算されるのでしょうか？それとも1つの大きな商談ですか？Salesforceでどのように処理するのでしょうか？トライアルはどのように扱うのですか？顧客が3ヶ月間の有料トライアルを利用している場合、それは顧客としてカウントされるのでしょうか？この場合、どうすればよいのでしょうか？非営利団体のような場合、どのように対処するのですか？実際にお金を払っていない人が、急な割引のためにお金を払っている場合、その人は顧客としてカウントされるのでしょうか？子会社についてはどうするのか？親会社や子会社に販売する場合、それらは同じアカウントにロールアップされるのでしょうか？別会計にするのか？そのような階層を管理する方法はありますか？オフサイクル・アップセールスとは何ですか？年間契約の9カ月後に更新する人がいた場合、どのように対応しますか？そのために新しい商談を作るのですか？既存のものに何かを追加するだけなのか？

このように、さまざまなことに対処しなければなりません。これはすべてSalesforceのデータで定義されています。しかし、これらの選択は、データエンジニアリングの原則によって決定されるものではありません。ベストプラクティスでもなく、「こうすればいい」ということもありません。あなたのビジネスが実際にどのように販売されているかによって定義されるのです。

例えば、Mode社のアップセルは、特定の販売方法に従っており、Modeが実際にどのように顧客に採用され、どのように予算を組み、どのように販売チームが実際に販売できるようにするかというダイナミクスによって決定されます。このような要素は、覆い隠すべきものではありません。また、解決するためのフレームワークが必要な、複雑なものでもありません。私たちのビジネスの根幹であり、Mode社のビジネスをMode社のビジネスたらしめているものなのです。それらをデータで表現することは、私たちにとって絶対に必要なことなのです。

このような問題は、あらゆるドメインに存在します。

もしあなたが自社サービスのユーザー行動をトラッキングしようとしているのなら、あなたが対処しなければならない複数のデバイスについてどう考えるか？ウェブクライアントとモバイルクライアントを使い分けている人たちを対象にするか？デスクトップクライアントがある場合はどうでしょうか。Substackのように電子メールのエンゲージメントをトラッキングする場合はどうでしょうか。Substackは多くのメールに関与していますが、他のプロダクトはそうではありません。これらの人々はアクティブユーザーとしてカウントされるのでしょうか？クリエイターと消費者という異なるタイプのユーザーがいる場合、プロダクトによってはそれがあるものとないものがあります。APIによるアクセスのようなものはどうでしょうか？プログラマティックなインタラクションはユーザーとしてカウントされるのでしょうか？あるプロダクトではカウントされ、あるプロダクトではカウントされないかもしれません。

このような多くの質問に答えない限り、デイリーアクティブユーザーのような単純なものでさえ、実際に定義することはできないのです。

サポートにおいても、同じことが言えます。

サポート時間をどのようにカウントするのか？24時間365日のサポートなのか、実際の営業時間はどのくらいなのか。プロアクティブなサポートや、直接連絡をとるようなことはしているか？ライブチャットは行っているか？電子メールを使用しているか？エスカレーションポリシーは？トップアカウントに対するSLAがあるか？

これらの点から、初回返答時間の一般的な定義は意味を持ちません。なぜなら、リアクティブサポートのみを行う場合の初回返答時間と、リアクティブとプロアクティブが混在する場合の初回返答時間は同じには見えないからです。

結局のところ、ちょっと変な例えをすれば、ビジネスはゴルフクラブによく似ています。

お絵かきクイズで、左の4番アイアンと右の9番アイアンを説明するとしたら、ほとんど同じようなことを言うでしょう。「テープで巻かれた長い金属の柄のようなもので、先端に傾斜した金属のものがあり、その傾斜したものの表面は平らで、小さな溝が切ってあるんだ。それでゴルフボールを打つんです」これらのことはすべて、これらのクラブを正確に定義するようなものです。

アイアン同士の差は、実は本当に微々たるものなんです。それはちょうどクラブヘッドの傾きの数度のようなものです。しかし、その違いが、そのクラブをクラブたらしめているのです。そのわずかな違いがなければ、9番アイアンは9番アイアンではないのです。9番アイアンと5番アイアンの違いは、そのわずかな違いだけです。

ゴルフクラブをそのわずかな違いで表現することはありません。ただ、これは企業の仕組みと同じです。同じように見えますが、実はそのビジネスのあり方を決定するのは、そのビジネスの運営方法における小さな違いなのです。

この例として、SlackとMicrosoft Teamsを考えてみましょう。

これらのプロダクトはほぼ同じものです。滑稽なことに、Teamsは基本的にSlackのパクリだと言われ、TeamsがSlackと同じ広告を掲載しているようにさえ見えるほどです。

これは2019年に両者が出した広告ですが、見た目は同じです。

これらは同じプロダクトで、同じ人に売られているにもかかわらず、Slackは人々が実際にSlackでどれだけの時間を過ごしたかでビジネスを測定しています。これは、彼らのコアメトリクスの1つであることを示すいくつかの投稿があります。

また、SlackがいかにユーザーをEメールから解放するかについても、多くの記事があります。Slackは、あなたがメールではなくSlackにどれだけの時間を費やしたかで成功を計っているのです。

一方、Microsoftは、Daily collaboration minutesと呼ばれるもので成功を計っています。Microsoft 365は、Office Suiteの中の任意のMicrosoft製品を使うことであり、これにはEメールのOutlookも含まれています。つまり、Slackはスタンドアロンで、Microsoftはパートナー製品群の1つ。TeamはOffice Suiteの一部というビジネスの性質上、同じ製品にもかかわらず、両社は正反対のことを気にしているのです。Microsoftはユーザをメール（Outlook）に誘導したいのに対し、Slackはユーザをメールから解放したいのです。

これは（今の話の文脈的に）非常に残念なことです。なぜなら、SlackとTeamsのように類似した製品に対して、一貫した評価基準を持つことができないのであれば、どうやって一貫した評価基準を持つことができるでしょうか。

より広範なコミュニティに対して、一貫したメトリクスを設けることができるでしょうか。私は、できると思います。最近の業界の動き、特にメトリクスレイヤーで起こっていることを見ると、ここに解決策があるように思います。

4つのステップ

前述したことを実現するためには、4つのことを違う方法で行わなければならないと思います。具体的には、4つのステップを踏むことになると思うのです。

この「4つのステップ」は、今までとは逆で、コミュニティの知識を徐々に蓄積していくことで、新しいデータ分析をするたびに新たな気づきが必要にならないようにするのです。

最後に、この種のコミュニティによるデータ分析が機能するために、実際に変更を加える必要がある場所と、それがメトリクスストアで起こっていることと、どのように関連するのかを、この4つの項目から説明します。

オープンソースのデータ分析を二つに分ける

まず、このオープンソースの分析を2つに分けて考える必要があると思います。

このようなものがどのように構築されるかを考えてみます。

オープンソース分析のようなものを作ろうとする私たちの努力のほとんどは、このようなものです。オープンソースのパッケージは生のデータを取り、それをきれいにして、その上でたくさんのメトリクスを計算し、すべて1つのクエリーで、あるいは一緒に使うように設計されたクエリのDAGのようなもので構成されています。

結局のところ、これはあまりに複雑で、書くのが大変なので、うまくいかないのです。このクエリを自分のビジネスに合うように書き換えるのは、労力に見合わないほど大変なことです。

もし、Salesforceの契約をARRで返すように定義したい場合、実際に契約をどう考えるかに合わせてクエリを書き換えなければなりません。そして、そのモデルやメトリクスをどう定義するか、つまり、SlackかMicrosoftか、どうやって報告するか、などを書き換える必要があります。このように、既存のモデルを、ゼロから自社で行うことが多い企業の特殊性に合わせて調整するのは、非常に大変な作業です。

この状況から抜け出さなければならないと思いますが、実際に行うにはあまりにも複雑なため、一度に大きなステップで行うことはできません。

そこで、この問題を半分に分割することで解決できると思います。まず、私たちが社内で行う最初のステップは、生データを取得することです。

そして、次に行うのは、それをビジネスの概念にモデル化することです。ユーザーとは何か、契約とは何か、アカウントとは何か、といった具合にです。つまり、Dim users、 Dim customers、といった具合です。

そして、その上にメトリクスを構築し、標準化されたレポートに反映させます。

その中で、実はほとんどのビジネスで一貫しているものがあります。それは、「ビジネス・エンティティ」です。Teamsが使うデータとSlackが使うデータがどんなに違っていても、これは一貫しています。どちらの会社にもユーザーがいますし、プロダクトにもユーザーがいます。ユーザーのアクションがあります。顧客もいます。

このような意味論的な概念は、実は世界共通なのです。たとえ、そこに至る方法が異なっていても、それを使って行うことが異なっていても、これらの意味的概念は一貫しています。オープンソースのプロジェクトが本当に機能するためには、エンティティがその中心にいなければなりません。その左側にあるものはすべて、このような共通のエンティティに食い込んでいかなければなりません。右側にあるものはすべて、この共通の実体の上に構築されなければならないのです。

こうすると、2つのことが実現できると思います。データをモデリングする人たちは、それがパッケージ的なオープンソース・フレームワークであろうとなかろうと、あるいは企業内でモデリングする人たちであろうと、実際に何をモデリングすべきか、という明確なターゲットを得ることができます。オープンソースのダッシュボードやテンプレートなどを作りたい人にも、その上に構築するための明確なセットを提供します。実際に何を作ればいいのか、そのベースができるのです。

ユーティリティ用のSQLパッケージの作成

次のステップですが、私たちはSQLパッケージを推進し続けるべきだと思います。ただし、あらかじめ構築されたデータモデルではなく、ユーティリティに焦点を当てるべきでしょう。

これはGeorgeがこのSQLライブラリの件で言及した投稿です。彼は、これがますます可能性を増していると話しています。さっきも言ったように、これは正しいことだと思います。SQLライブラリが言語となる可能性が出てきたのは良いことだと思います。ただ、そのライブラリやパッケージを構築して、何をするのかを考える必要があります。

今、SQLのパッケージというと、このようなエンドツーエンドのオープンソースモデリングに多くフォーカスされる傾向があります。パッケージは、あるデータソースをクリーンアップするために設計されています。

これは、この種のdbtパッケージのプロバイダの一つに過ぎない。大抵の場合、プロバイダーが中心になっているので、このプロバイダーだけを取り上げるのはやめましょう。しかしご覧のように、これらは特定のソース向けに作られています。Squareのデータ用、Xeroのデータ用、SalesforceやQuickBooksのデータ用などです。このアイデアは、これらの特定のソースをクリーンアップすることです。

しかし、私はこれが本当にうまくいくとは思っていません。というのも、Salesforceのデータがどのように書き込まれているのか、それをどのようにクリーンアップするのか、というのは非常に難しく、オーダーメイドになり、複雑すぎるからです。このようなことを定義するためのオープンソースのフレームワークがないのです。

つまり、このステップをすべて解決することに焦点を当てるのではなく、このステップをより簡単に解決するためのツールを提供するのです。たしかに、「Salesforceのデータをきれいにする方法」というようなパッケージのようなものは、あまり見かけません。

しかし、その代わりにdbtのユーティリティのようなものに焦点を当てたパッケージがあります。これはdbtが出しているパッケージで、ユーザーが実際に使える関数の束を提供するものです。これらの関数は、ユーザーのために実体を作り出してはいけません。オープンソースのフレームワークやWeb開発が、ユーザーのために完成したWebアプリを作る（わけではない）ことと同じです。私たちは、完成したWebアプリを作るためにRailsを使っているのではありません。私たちは、私たちが望むWebアプリを作成するためのツールの束を利用するためにRailsを使います。

私にとって、この種のパッケージは同じものであるべきです。私たちが望むエンティティを、私たちが適用したいビジネスロジックとともに作成するのを助けるツールであるべきで、そのエンティティに至るまで私たちをショートカットできると主張するのとは対照的なものであるべきです。

メトリクスライブラリはエンティティの上に構築する

3つ目のステップのポイント。このようなことは、ユーザーがエンティティを構築する理由を持っている場合にのみ、本当に意味をなすのです。もし私が顧客のエンティティを作りたかったら（理由がない限り）なぜそんなことをするのでしょうか。これこそが、メトリクスが本当に提供できる価値だと思うのです。

私にとって、メトリクスライブラリとは、これらのエンティティの上にオープンソースのメトリクスを構築する必要があるものです。

これはTransformの素晴らしい点の1つで、パッケージやオープンソースのテンプレートを作って、エンティティの上に置くことができるようになるのです。dbtでユーティリティを作るのと同じようなものです。

これを実現するためには、スライドのような形にならないことが重要だと思います。オープンソースのメトリックフレームワークが生データの上で直接動作することができないように見えることはありえません。これは、すべてを一度に解決しようとする前の問題に戻っていると私は思います。この構造は、他のオープンソースの取り組みが失敗したのと同じ理由で、複雑すぎるという理由で失敗すると思います。

その代わりに、このようにエンティティの上に構築することで、2つの大きな問題が解決されると思います。

1つ目は、この種のオープンソースやダッシュボードを作っている人たちが、より簡単に構築できるようになります。なぜなら、購入品目表や顧客リストなどの上に構築するエンティティが何であるかを、意味的に仮定することができるからです。Salesforceのデータがあると仮定するよりも、はるかに使いやすく、汎用性も高いです。こういうのは、人によって見た目が違いますからね。

2つ目は、先ほども述べたように、実際にデータをモデリングしている左側の人たちをターゲットにすることができます。

一方、「モデル・エンティティの上に置くことができるメトリクス関数もありますよ」と言われたら、これは強力なインセンティブになります。このようなエンティティを構築して、実際にこのようなものを手に入れるためのフライホイールを始動させたいという強力な動機付けになります。

ベンダーではなくコミュニティ主導で

最後に、私は（データ分析プロダクトの）ベンダーとして、少なくともベンダーのカンファレンスに参加する一部のベンダーを含む聴衆に対して、このように話したいと思います。もしこのすべてがうまくいくのであれば、ベンダーも参加させるべきだということです。コミュニティ主導でなければならないのです。

オープンソースを実現するための過去の取り組みに立ち返ってみましょう。これまで、このようなオープンソースの取り組みがうまくいかなかったのには、もう一つ理由があると思います。それは、ほとんどがベンダーから提供されたものだということです。

ベンダーは、この問題を正しい方法で解決しようというインセンティブをあまり持っていないのです。私たちがどんなに立派な取り組みをして、「コミュニティーの枠組みを作って、みんながパッケージを作れるようにしたいんだ」と言っても、ベンダーに動機は出ません。

ベンダーには常に別の動機があります。自社のプロダクトをアピールしたい、このプロダクトをどれだけ早く購入できるかを見せたい、という動機です。ボタンを数回押すだけで、すぐに使える（というアピール）をしたいのです。

このような、売り込みの仕方にも、それが表れています。Fivetranのものについては、素晴らしいです。Fivetranを隠しておいて、データをセットアップして「ほぼ瞬時に」レポートを作成する方法、という紹介です。

dbtも同じです。dbtのパッケージがあれば「数分で」モデルのようなものができあがる、という紹介です。

Lookerも同じで、「非常に速く簡単に」Lookerを始めることができる、とあります。

Mode社のブログには、パンチの効いた名言みたいなものはないのですが、言えるのは、なぜこのようなことをしたのかという動機です。実際にModeを使ってもらうためのキッカケを伝えています。

これは、このようなセットアップを奨励するものです。「私のプロダクトを買ってください。プラグインは1つです。エンド・ツー・エンドのソリューションで、ただ動くだけです」と言うような構造を助長するのです。これは、コミュニティの問題を本当に解決するというより、プロダクトの価値を売り込むための方法なんです。

その代わりに必要なのは、このステップを踏むことだと思うのです。

生データをエンティティにモデル化する方法（エンティティをメトリクスに変換するようなもの）が必要です。繰り返しますが、ベンダーはエンドツーエンドの問題を解決したいので、必ずしもそのような方法を取るインセンティブはベンダー側にはありません。しかし、コミュニティがこの問題に焦点を当て、最初にそれを実行すれば、メトリクスベンダーはこの構造に合わせて構築すると思います。

私が最後に言いたいのは、ようやくデータアナリストが巨人の肩の上に立てるようになったということです。しかし、その「肩」はベンダーやツールのものであってはならないのです。ベンダーの立場では、正しいことをするインセンティブがないため、正しいことをしようとはしません。

例えば、Fivetranは多くのデータを提供することができます。dbtは、人々が実際にSQLパッケージを使って、言語の問題やライブラリの問題などを解決する方法を見つけることができます。Transformは、このメトリックフレームワークとプラットフォームを提供できます。Modeは、こうしたあらゆる種類のもののための統合開発環境を提供します。

しかし、実際のデータ分析や仕組みは、最終的にはコミュニティからもたらされなければなりません。なぜなら、この問題を解決するためのインセンティブは、コミュニティにあるからです。

質疑応答

ビジネスが拡大する中で、メトリクスのライフサイクルをどのように考えていますか？例えば、あるメトリクスの元となる定義やパイプラインの変更をどのように管理しますか？

何事も進化していかなければならない、ビジネスは常に進化していくものです。価格設定モデルなどは、その良い例だと思います。どの企業も価格設定モデルを見つけられずにいるのです。どの価格設定モデルも、数カ月後には劇的な変化を遂げているのです。ですから、メトリクスはそれを反映する必要があると思います。このようなことは永久に続くものではないということを理解した上で、メトリクスを構築する必要があります。

このことは、2つのことにつながります。

ひとつは、変更可能であることを認識した上で、ある程度、柔軟性のある方法で構築する必要があるということです。しかし、同時に、一度にすべてを計画することはできないという事実にもつながります。

何かを得るためには、反復のプロセスがあります。そして、それが進化していくことを認識するのです。ライフサイクル・マネージメントや技術的な問題については、私よりずっと頭のいい人たちや、この問題について深く考えている人たちに任せたいと思います。しかし、データを消費する者の一人として、メトリクスは決して決まっていないということを認識することは重要だと思います。メトリクスは決して完成されたものではないのです。同じように、価格設定モデルも決して決まったものではなく、すべてが常に変化するものであり、それに適応する必要があると思います。

これだけ標準的なメトリクスや分析パッケージがあっても、まだ探索的な分析が必要なのでしょうか？

100%必要です。

標準的なSaaSのダッシュボードがあるとして、何か障害が発生した場合、どうすればいいのでしょうか？

ほとんどの分析では、その原因を突き止めようとします。世の中で何が起こっているのかを知った上で、何をすべきなのか。本当にあらゆる種類のパッケージは、どこまでいっても、圧倒的に現状を伝えるだけです。

データ分析チームが行うことのほとんどは、何が起こっているかを解明することです。もしそれをショートカットして、「どうすればいいのか」ということにまでたどり着けるなら、それはとても大きな勝利です。

しかし、コミュニティで得られるのは、たいていの場合、何が起こっているかということだけです。何が起きているのかがわかると、それに対してどうすればいいのか、何か別のことをしたらどうなるのか、といった疑問が山ほど出てきます。そこで、探索的な分析が威力を発揮するのです。

おわりに

メトリクスレイヤーがどうというより、データ分析基盤全体の未来について語られたような印象を受けました。

Fivetranやdbtが開発したパッケージを見て「すげー」と思っていましたが、「データそのものを生成するライブラリではなく、分析用SQLを開発しやすくなるユーティリティ的なライブラリが必要」という主張は、かなり食らっちゃいました。セッションでも言っていますが、Webアプリそのものを作ってくれるパッケージやライブラリってあまり無いですもんね。開発自体を楽にしてくれるものがほとんどで、データ分析もそうあるべき、という点については激しく同意です。

また、「（例えば）Salesforceの使い方や定義は企業間で異なるが、エンティティ（商談とか顧客など）は共通」という点も目からウロコでした。その共通エンティティの上にメトリクスを構築することで、もっとデータ分析基盤が加速しそうです。