SquadbaseのPublic Betaをリリース

本日、Squadbase Public Betaを公開しました。

Squadbaseでは、自分たちのデータに自由に問いを投げられます。そして、その中で繰り返し確認したい問いはAIに任せられます。AIはその問いを継続的に実行し、見るべき変化があればEmailやSlackに届けます。

私たちが作りたいのは、単に分析を速くするためのBIではありません。人がデータを見に行き続けなくても、重要な変化の方から人に届く状態です。

この方向を、私たちはData Autopilotと呼んでいます。

AIで分析は安くなった。でも、見に行く仕事は残った

AIによって、データに問いを立てるコストは大きく下がりました。SQLを書かなくても質問できる。数時間かかっていた分析を数分で終えられる。ダッシュボードもAIに頼めば作れる。これは確かな前進です。

ただ、BIの基本的な使い方はまだほとんど変わっていません。誰かがダッシュボードを開き、数字を見て、変化に気づき、そこから次の問いを立てます。Copilotが間に入っても、この始まり方は同じです。

これまで人が直接データを見に行っていたところに、AIが入るようになりました。けれど、最初に動くのはまだ人です。私たちは、ここが変わるべきだと考えています。

AIが人より先にデータを見て、知るべき変化があったときに、その変化の方から人に届く。以前書いたように、分析は潤沢になっても、人間の注意は潤沢にはなりません。

だから次のBIで重要なのは、どれだけ多くの分析を作れるかだけではありません。人がどれだけデータを見に行かなくてよくなるかです。

Data Autopilotにはゴールが必要になる

ただし、AIが先回りしてデータを見るようになると、次の問いが生まれます。何を見ればいいのでしょうか。

売上が5%動いたこと自体には、まだ意味がありません。それが重要かどうかは、今期の目標、追っているKPI、許容できる範囲、進行中の施策、既知の例外、そして数字が動いたときに取れるアクションによって決まります。

つまり、Autopilotにはゴールが必要です。そして、そのゴールは個人でも会社全体でもなく、多くの場合、共通の事業ゴールを持つ小さなチームの中にあります。

私たちは、1つの事業ゴールやKPIを共有し、その数字が動いたときに一緒に行動するチームを「Squad」と呼んでいます。たとえば、顧客の健全性や更新率を追うCustomer Successチーム。パイプラインを追うGTMチーム。ActivationやRetentionを追うProductチームです。

Squadには、追うべきKPIがあります。そのKPIについて、なぜ今それが重要なのかというContextが溜まります。そして数字が動いたとき、実際に動く人がいます。

Data Autopilotが機能するためには、AIが数字だけを見るのでは足りません。Squadが何を目指しているのか。どのKPIを追っているのか。その数字がどのくらい動いたら気にするべきなのか。今どんな施策を進めていて、どんな例外をすでに知っているのか。

そうしたContextがあるからこそ、AIは変化の大きさだけではなく、そのSquadにとって本当に注意すべき変化かどうかを判断できます。そして、見るべきものが決まって初めて、その確認を継続的に任せられるようになります。

Semantic Layerが「この数字は何を意味するか」をAIに教えるなら、Squadが持つContextは「このチームにとって、なぜ今この数字が重要なのか」をAIに教えます。このContextをどうAIに渡すかについては、前回の記事でも書きました。製品をSquadbaseと名づけたのも、この単位のためにData Autopilotを作りたいからです。

Data Autopilotは「何ができるか」ではなく「何を見なくなったか」で測る

自動運転を考えると、この違いはわかりやすくなります。自動運転の進歩は、車がどれだけ多くの機能を持っているかではなく、これまで人が見て操作していたものを、どこまで任せられるようになったかで測られてきました。

Data Autopilotも同じだと考えています。AI機能の数ではなく、人が何を見なくてよくなったかで測るべきです。

最初に、SQLを見なくなりました。普通の言葉で質問できるようになったからです。次に、データセットやダッシュボードを一から組み立てる作業を見なくなり始めています。AIが作れるようになったからです。

そして次に無くなるのは、同じグラフや数字を何度も見に行く仕事です。AIが代わりに見て、必要なときだけ知らせればいい。長期的には、「何か変わっていないか」を探すためだけにデータを開くこと自体がなくなると考えています。

ダッシュボードがなくなるわけではありません。役割が変わります。毎日の仕事を始めるために開く場所から、AIから届いた知らせを確かめ、必要なときに深掘りする場所になります。

問いから始まり、変化が届く

私たちが作りたいのは、質問のための製品と、定期レポートのための別の製品ではありません。作りたいのは、1つの問いが、そのまま継続的に使われ、変化があれば届き、そのまま確認や意思決定につながっていく、1つの流れです。

新しい疑問が生まれたとき、人はまずデータに問いを投げます。これが最初の入口です。そして、その問いが毎週、毎月のように繰り返し確認するものだとわかったら、その確認はAIに任せられます。AIはその問いを継続的に実行し、変化があれば人に届けます。誰かがダッシュボードを開きに行く前に、変化の方から届くイメージです。

大事なのは、通知して終わりではないことです。届いた知らせの流れの中で、その変化が本当に重要かを確かめ、必要なら追加で問いを立て、背景を掘り下げて、そのまま判断につなげられます。

つまり、Squadbaseが作りたいのは、必要なときに問いを立て、繰り返す確認はAIに任せ、変化が届いたらその文脈のまま確かめて、さらに聞いて、決める、という一連の流れです。これを別々の機能として分けるのではなく、1つの連続したループとして扱えるようにすること。それが、私たちの考えるData Autopilotです。

ここには、意図的に引いている線もあります。AIが継続的に見るのは、Squadが見てほしいと決めたものだけです。頼まれていない変化を勝手に探し回ったり、何が重要かをAIだけで決めたりすることは、まだしません。

今Autopilotに向いているのは、毎日、毎週、毎月と繰り返され、たいていは何も起きない確認です。一方で、その場で生まれた問いや、一度だけ調べればいい問いは、人がその都度自由に聞けばいいと考えています。

今日から誰でも使えます

Squadbase Public Betaは、待機リストも申請もなく、今日から誰でも無料でサインアップできます。PostgreSQL、Snowflake、BigQueryをはじめとするデータウェアハウスやデータベース、SalesforceなどのSaaS、Excelのアップロードまで、現在50を超えるコネクタに対応しています。

Viewerはすべてのプランで無料です。チーム全員がデータを見るために席を買う必要はありません。

まずは、毎朝、毎週、毎月、誰かが思い出して見に行っている数字を1つ選んでみてください。そして、その確認をAIに任せてみてください。