- "self-serve dashboards" は、実際にはうまく機能しない。エンジニアやデータサイエンティストが、ビジネスユーザー向けのクエリ作成やダッシュボードの準備に多くの時間を費やすことになるため。
"self-serve BI" が機能しない理由
- SQL は唯一の "self-serve BI" ツールである。だが、ほとんどの "self-serve BI" ベンダーは SQL を別の何かに見せかけようとしている。
- SQL クエリを書くことだけが、ビジネス関係者がデータをクエリする際の障壁ではない。データの意味、出所、計算方法を理解しておらず、結果をどう解釈し検証すべきかも分かっていない。
試み 1: 従来の "ドロップダウンとチェックボックス" アプローチ
- このインターフェースは、単に "SQL-by-mouse" を試したものにすぎない。SQL より優れているわけではなく、むしろ遅く、信頼性が低く、制約が多く、他のツールへ一般化することもできない。
- CFO のような人は、このインターフェースを使ってデータをクエリしないだろう。データを理解するための文脈がなく、結果に確信を持てないため。
試み 2: text-to-SQL アプローチ
- LLM は自然言語を SQL に翻訳するのが、ほとんど過剰なほど得意である。質問が適切でなくても、クエリを生成しようとしてしまう。
- 技術者であれば、質問が適切でないことに気づき、より多くの文脈を求めるだろう。利用可能なデータの種類を説明し、正確で有用な質問を作るためにビジネス担当者と協力するだろう。
- LLM は "self-serve BI" の本当の解決策になり得るが、現状の形では無理である。より多くの文脈が必要であり、不確実性を表現し、追加情報を求めることにもっと長けていなければならない。
実際に機能するもの
- "self-serve BI" の問題は SQL ではなく、データの文脈と意味にある。解決策は、インターフェースに関係なく、人々にクエリ対象のデータについて教えることだ。
- 技術チームがあらゆる知識を文書化するのは、かなりのオーバーヘッドを生み、しかもすぐに古くなってしまう。
- "self-serve BI" の真の解決策は、非技術者向けに BI を "self-serve" にすることではなく、技術者がより良いツールを使ってビジネス関係者をより効率的に支援できるようにすることだ。
より良いツールへの提案:
- LLM をビジネス関係者ではなく技術者に提供する。
- Python、R など使い慣れたツールを使って、データを自由に扱えるようにする。
- 技術者が作業内容を簡単に共有できるようにする。ノートブックや社内データアプリケーションは、コンテナ、依存関係、インフラを扱う必要があるため、共有が難しい。
1件のコメント
Hacker Newsの意見
BIツールの問題点: BIツールを使っていて、クエリの結合方法が誤って設定され、データが誤って表示された経験がある。SQLをよく知らない人向けの抽象化レイヤーへの信頼を失うことになった。
Text-to-SQLの有用性: 開発者にとっては依然として有用だが、非開発者にとっては、データベース構造を十分に理解していないため、誤ったクエリを生成する可能性がある。
組織の無能さ: BIツールやAIツールのエラーや誤情報を含んだレポートが実際に使われており、これは Dilbert の漫画でも同様に批判されていた。
ビジネスユーザーの学習可能性: ビジネスユーザーがデータモデルとドロップダウンの関係を理解できないという前提は誤りである。問題は、データモデラーがドメインを十分に理解していないことから生じる。
データ提供の経験: 24年間のデータ提供経験から、実際にツールを使うユーザーは少数であり、経営陣はKPIダッシュボードを好む。
Metabaseの長所: MetabaseはBIツールの中でも優れたインターフェースを提供しており、GUIで生成されたSQLを純粋なSQLに変換できるため、技術レベルが低い人でも簡単に使える。
セルフサービスBIの限界: セルフサービスBIの限界を認識し、SQLをビジネスユーザーに露出させないカスタムダッシュボードを作ることが解決策である。
Metabaseの利用経験: Metabaseを使いながら「オフィスアワー」を通じて非技術ユーザーに使い方を教育した結果、多くのリクエストがエンジニアリングチームに回らずに済んだ。
SQL利用の皮肉: 上級管理職がSQLクエリを実行できない状況は皮肉である。SQLはもともと、管理職がデータを簡単にクエリできるように作られたものだ。
ETLの難しさ: BIよりもETLのほうが、非技術ユーザーにとってデータを扱うのがさらに難しい。AWS Glueを開発しながら、技術ユーザーが問題をデバッグできるツールが必要だと気づいた。