セルフサービスダッシュボードが機能しない理由
(briefer.cloud)- "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ツールでダッシュボードを作っていた会社で、数字がおかしいのでクエリ生成ツールをのぞいてみたところ、クエリの一部が内部結合なのか左外部結合なのかまったく分からなかった。
そのダッシュボードを作ったビジネスアナリストも分かっておらず、実際には内部結合が意図されていたのに左外部結合が実行され、表示されるデータが実際より一桁も大きくなっていた。
それ以来、SQLを知らない人向けにSQLの上に載せるこうした抽象化レイヤーを信用しなくなった。
データにはアクセスできても、データそのもの、関係性、自分が作った結果が何を意味するのかを分かっていない人が多すぎる。
この25年の間に、分散型／組み込み型のエンジニアやサイエンティスト、セルフサービスダッシュボード、ローコードBI／データツール、そして今ではLLMベースのテキスト→SQL／可視化まで、解決策のように登場してきたが、結局はデータ理解の不足と成果物への信頼の問題を解決できなかった。
ただしSQLも解決策ではない。データを取り出せる程度にSQLを知っている人は多いが、データ構造やスキーマ、正しい使い方まで知っている人はまれだ。
経験以外にこの問題を解決してくれるツールはまだなく、LLMがいつか可能にするかもしれないが、正直なところ可能性は低そうに見える。
ダッシュボードはKPIをすばやく見て掘り下げるにはよいが、結局重要なのはデータ管理の慣行と、データ／関係／指標を正しく理解してビジネスインサイトにつなげる能力だ。
未来には期待しているが、これまで次世代ツールが約束を果たしたことはないので、簡単には絶対に信じないようになった。
合理的なデフォルト値と、自分の足を撃ち抜く仕掛けは、見方の違いでしかない。
大企業で、微妙なバグや設計が売上を高く見せていると、誰も手を付けて売上減少の責任を負いたがらない例を見たことがある。
たとえば平均的な解像度では無料プランのボタンが折りたたまれた画面の下にあるとか、stateの計算が間違っていて割引が適用されないとか、誰かが
falseを抜かしたせいで登録は技術的には不要なのに登録を求めている、といった具合だ。数字が下がったことを自分のせいにされるのでは、という似たような感覚があったのか気になる。
複雑な論理フローを実装するときに難しい部分は、IDEにコードをタイプすることではなく、問題をモデル化し、効果的なアルゴリズムを設計する能力にある。
こうしたツールは、コードを書かなくてよいという約束で非技術系ユーザーを狙うが、ユーザーは依然として解決策を工学的に設計する複雑な部分を理解できず、迷子になったり誤った結果を出したりする。
複雑なビジネスプロセスをノーコードツールで育てようとする試みは、結局多くの試行錯誤の末に壁にぶつかり、最後には本物のエンジニアに引き渡される。
ところがエンジニアは、本物のプログラミング言語でコードを書くときには当然ある支援を失った状態で作業しなければならない。
視覚的なフロービルダーに閉じ込められると、共有リポジトリ、まともなバージョン管理、コードレビュー、自動テスト、CI/CDがほぼ不可能になる。
ユーザーは基本的に自分の視点でしか見ないので、彼らの考え方でも見られる代替手段を用意しなければならない。
教育向けの出席を時間ベースで扱う製品を知っているが、学校・キャンパス・日付ごとに時間割の組み合わせが異なり、スポーツ行事、代替勤務、合同クラス活動、14日周期の時間割のような柔軟性が必要だからだ。
だからといって、その複雑な時間割を授業ベースの出席や午前／午後の出席として合成したビューを作れないわけではない。
ビジネスユーザーは自分の質問、データモデル、ドロップダウンの間の関係を学べない、あるいは性急すぎるという前提はばかげている。
むしろ経験上、彼らは学ぼうとするが、データモデラーがドメインを十分に理解しておらず、質問のニュアンスを取り込めないことが多い。
その結果、セルフサービスを単純化するという名目でニュアンスを隠して答えを得るまでの時間を延ばしたり、そもそも取り除いて不正確で誤解を招く答えを作ったりする。
非技術的という婉曲表現も嫌いだ。LLM、BIクエリ生成ツール、SQLの間には十分な中間地点があり、能力の壁が絶対的だと宣言する必要はない。
コンピュータ、プログラミング、データ分析の専門家になるのはよいが、可能なら自分が学んだり働いたりしているドメインを中心に置き、その能力を副次的に伸ばすようにと言っている。
ドメイン専門家はデータを知らず、データ専門家はドメインを知らないという問題の解決策は、その二つが同じ人間になることだ。
今、組織的な無能が新しいレベルに到達したように見える。
スプレッドシートを批判したDilbertの漫画があったが、BIツールやAIツールにもそのまま当てはまる。
「この発表のスプレッドシートには、当然ながら誤りと間違った情報が満載です。どうせ経営陣がすでに下した決定を補強しない限り誰も二度と見ないので、問題ありません」というような内容だった。
現実でも壊れたレポートやダッシュボードがあふれている。
数か月、場合によっては数年まったく更新されていないのに、誰も気づかないままプロセス、意思決定、ワークフローに使っていることがある。
データは更新されていないが、日付／時刻基準でピボットされ、実行するたびに同じデータを並べ替えるため、大きく壊れていても目立たない場合もある。
各種の数式や「数学」が完全に間違っていて、幻想上の数字を出力することも多い。
世の中が集中型EDWやERPシステムから離れるにつれてデータ問題が指数関数的に難しくなり、投資水準がそれに追いついていないだけだ。
この24年間、ビジネスユーザーにデータを提供してきたが、クエリツールであれ MS Access であれ Power BI であれ、Excel のデータキューブであれ、実際に使う人はごく少数だけだった。
おそらく40年前にも、端末や印刷されたレポートからデータを拾い集めて分析していた、まさに同じような人たちなのだと思う。
それでも経営陣は主要指標のダッシュボードを好むし、新しい BI ツールは KPI ダッシュボードの作成と維持をはるかに簡単にしてくれる。
肩書きは「個人秘書」のようなものかもしれないが、SharePoint フォーム、Access、Excel をハックするように使いこなし、見事なものを作り上げる。
彼らの賢い能力を認め、より強力なツールを与えると素晴らしい。そうすると、より良い職場へ移ってしまうこともあるが、それもまた素晴らしいことだ。
コンピュータがあまりに高価だったため、「コンピュータ部門」が会社内の独立した部門であり、たとえば西部事業部がコンピューティング資源を必要とする場合、現地に設置されたメインフレームを持つコンピュータ部門と契約する、という形だった。
私たちのグループは、新しく「安価な」ミニコンピュータを使う、小規模で機動的な社内分析チームだった。
資金の仕組みのおかげで、ユーザーの要求にずっと速く対応できるのが利点だった。
ある日、工場を歩いていると、ユーザーが私たちの作った緑の罫線入りレポートの行を切り取り、別の紙に貼ってコピーしているのを見かけた。
別の基準でレポートを並べ替えていたので、「それならこちらでできますよ！」と言うと、「本当ですか？」という反応が返ってきた。
仕事を終わらせなければならない人は、どうにかして終わらせるものだ。社内顧客にサービスを提供するコンピュータシステム部門の目標は、そのプロセスをできる限り効率的にすることにある。
また別の人は、PC、タブレットデジタイザ、AutoCAD を使って航空機上の点を記録し、レーダープロファイルを作っていた。
CAD 本来の用途というより、Jane's Combat Aircraft の図面からデータを取り込む独創的な使い方だった。
そのデータが最初から存在していたことを信じられないのだ。
統合は必要なビジネス運用だが、理解しやすいデータはステークホルダーに本当に喜ばれる。非常に簡単な価値追加である。
記事に出てくる従来型 BI インターフェースは Metabase だが、現在の BI 向けインターフェースの中ではかなり良い部類に入る。
Metabase は GUI が生成した SQL を確認でき、その質問を純粋な SQL に変換することもできるため、セルフサービスからガバナンスへ移行しやすい。
ロジックを修正・検証しやすく、技術的な習熟度が低い人にもスキルを伸ばす道筋ができる。
ただし、記事の核心は正しい。専門的にデータの仕事をしている立場から見ても、BI ツールがより多くの人に、データに対する正確な理解や正しい利用に必要なスキルを与えることはまれだ。
データがきちんと管理されていればツールは簡単で、人々も理解できるが、世の中は複雑なのでデータも複雑になる。
データ管理コストは目に見えやすい一方で、利点は見えにくい。
「セルフサービス BI」について似た結論に至ったが、解決策は少し違う。
抽象化レイヤーをさらに高くして、非常にカスタマイズ性の高いダッシュボードを作る一方で、ビジネスユーザーには SQL を見せないほうがよいと思う。
たとえば、20個のフィルターと分解ディメンション、「使用された前提」を制御する20個のパラメータを持つダッシュボードである。
「先月の Google 広告の成果を年齢層別に見たい」という質問は、あらかじめ決められたドロップダウンを3〜4個変えるだけの作業になる。
ここでパラメータが重要になる。検証済みの調整項目だけを公開し、任意の SQL は許可しないからだ。
もちろん、このようなダッシュボードを作るのは難しく、Looker、Tableau、Excel などの可視化に関するかなりの専門性が必要だが、結果として質問の70%はセルフサービスになる。
残りの30%は諦めたほうがよく、ビジネス上の問いをデータ上の問いに翻訳する人が必要になる。それは人の問題だ。
そうすれば CFO であれ誰であれ、特定期間についての答えが必要なときにそのダッシュボードを開き、基本パラメータを少し調整するだけで済む。
画像に出ている Metabase を使っており、概ね非技術系ユーザーも実際に使っている。
導入に役立ったのは、「オフィスアワー」を開いて、「特定の店舗や州の売上を取得する方法」のような例を実際に見せたことだ。
すべての問題・クエリ・エクスポートを解決したわけではないが、以前ならエンジニアリングに来ていた依頼のかなりの部分が、今ではそこまで来なくなった。
Metabase が良いもう一つの理由は、セルフホスティングが可能で、GSuite SSO を使える点である。
重要な指標は「助けを求める回数が減ったので、ユーザーがより自立した」ということではない。
そのユーザーたちが完全に的外れな指標を取り出して解釈する可能性が非常に高いからだ。
技術力の低いユーザーがデータにアクセスすると、「思ったより難しくない」と信じ、でたらめな分析のピラミッドを積み上げていく様子を繰り返し見てきた。
正しい分析には常に文脈が必要だ。
たとえば、継続売上では財務チームが配送日を再入力するため、月次売上の計算に配送日を使ってはいけない。
カタログ価格は USD で保存されているが、実際には
monthly_discountテーブルを基準に為替レートを毎月調整している。前年度の未販売在庫を表示する慣例のため、購入日が null の項目は売上レポートから除外しなければならない。
価格が現地通貨なので、為替レートテーブルと join せずに売上を合算してはいけない。
会社の非プログラマー向けに設定しており、正直なところ彼らは私が作っておいたダッシュボードを見る以上のことにはほとんど使っていないが、反応は良かった。
本当に有用なツールだ。
高位の管理職が高給をもらっているのに BI の SQL クエリを実行できないのは、いつも笑ってしまう
SQL は本来、管理職がデータをより簡単に問い合わせられるように作られたものなのに
以前の営業担当者／管理職の立場からすると、そういう人たちにはあまり同情できない
ただし自分ではやらない。基本的な経済原理を理解しているからだ
他人が3日かかる仕事を本人なら半日でできるとしても、その半日は CEO にしかできない仕事ができない時間になる
有能な CxO は、本当に時間がかかる部分が細部を完璧に合わせることにあるのも分かっている
null 処理の癖、日付処理、合わない結合の処理のように、SQL が「高水準」でも、信頼できる答えを得るには時間と集中が必要だ
それを専門にしている人がいるなら、その人に任せるのが正しい
BI ダッシュボードは、ごく単純な問い合わせにはうまく機能し得ると思う
非技術系ユーザーにデータ結合を実行させる段階なら、すでに踏み込みすぎで、その時点では素直に SQL を使うほうがよい
結合は人によっては基本に見えるかもしれないが、個人的にも時々理解しづらく、SQL より表現力の低いダッシュボード UI では混乱を招く組み合わせだ
結局はトレードオフだ。SQL より非技術系ユーザーがアクセスしやすくすることはできるが、必然的に SQL より非力になる
それでも、その中間領域には大いに使い道がある。実際、「BI」の相当部分は「データ列が2つあるので、一方をもう一方に対して描画してほしい」という程度だ
筆者は SQL を唯一の「セルフサービス」BI ツールだと言うが、正直それは Excel だと思う
多くの BI ツールは、新しく、そのぶん慣れにくいインターフェイスで Excel を作り直しているようなものだ
Excel を嫌うミームは、かつて複雑なことを Excel でやろうとしたことから生まれたのだと思う
複雑なデータ操作は SQL で行い、「これを円グラフで見せて」は Excel でやるなら、BI ツールは本当に不要かもしれない
基盤となるデータソースがクレンジングされ、変換され、アクセス制御さえ適切なら、VLOOKUP とピボットだけでも驚くほど遠くまで行ける
データソースが2つ以上あるときに非技術系ユーザーへセルフサービスの機会を与えると、必ずオフラインでのデータの継ぎはぎにつながる
そして「データチーム、なぜ『あなたたち』のデータは『私の』データと合わないのですか？」という質問が来るが、常に自分側が正しいという前提が置かれている
核心的な問題は、現代のツールが Smalltalk ワークステーションや Emacs のような古典的なデスクトップとは異なるところにある
そうした環境は完全に統合された一つの環境で、すべてがユーザーの手元にあり、エンドユーザープログラミングの概念が組み込まれていた
org-mode では見栄えのよいスライドを一瞬で作り、コード片を素早く書いて実行し、結果を得られる
ただしダッシュボードの観点では限界が大きい。データを素早く描画することはできても、結果は粗い静的画像に近く、PGF/TikZ で見栄えよく作るには時間がかかりすぎて選択肢になりにくく、依然として静的だ
Emacs 自体は適した道具だが、より古い時代の道具でもある
現代のツールはより派手で高速な操作を提供するが、可能な動作は非常に限定され、柔軟性のない UI に閉じ込められており、ほかのものとも統合されていない
R は RStudio/quarto と組み合わせれば、手早く雑でも見栄えのよいコンテンツを最速で作れるかもしれないが、Emacs の柔軟性には到底及ばない
結局、古典的なパラダイムと現代のハードウェア性能を土台に 現代のソフトウェアスタック全体 を書き直さない限り、解決策はなさそうだ