3-9.基幹システムに分析させない。BigQueryを活用したBI分離アーキテクチャ
「せっかく基幹システムを刷新するなら、分析機能も載せたい」——誰もがそう考える。私たちの答えは逆だった。基幹システムには、分析をさせない。 第9回は、データの「蓄積(基幹)」と「分析(BI)」を明確に分離するデータ基盤戦略——基幹のDBからBigQueryへ流し、Looker Studioで見る——というアーキテクチャを書く。EC運用でLooker Studioを使い込んできた私にとって、ここはこだわりの領域だ。
この回はシリーズの中核思想がもっとも鮮明に出る。AIの時代、「分析する」という行為そのものはコモディティになる。 集計も、グラフ化も、ダッシュボードの構築も、いずれ安く速く誰にでもできる。だが、その分析が意味を持つかどうかは、ひとえに「土台のデータが整っているか」にかかっている。データが汚く分散していれば、どれほど高性能なAIに問いかけても、返ってくるのはゴミだ。だから本質は、分析という手段ではなく、その下のデータ基盤をどう設計するかにある。
Before:基幹に分析をさせると何が起きるか
旧来の発想では、基幹に帳票機能やレポート機能をどんどん追加していく。一見便利だが、二つの問題を生む。一つはパフォーマンスの低下だ。基幹のデータベースは、受注や出荷といった日々のトランザクションを高速・確実に処理するために設計される。そこへ「過去3年の全取引を集計する」ような重い分析クエリが走ると、業務処理と分析処理がリソースを奪い合い、最悪、受注入力の画面が固まる。分析のために業務が止まるという本末転倒だ。もう一つは分析の硬直化だ。基幹に作り込まれた帳票は、変更のたびにベンダーへの開発依頼になる。「この切り口でも見たい」が見積もりと納期の世界になる。分析とは本来、問いが次々変わる探索的な営みだ。それを開発案件にすると、現場は分析を諦め、またExcelに戻る。
After:蓄積と分析を、物理的に分ける
次期アーキテクチャの原則はこうだ。基幹システム(DB)は正確なデータを蓄積することに専念する。分析は、データを別の場所(BigQuery)へ複製した上で、そちらで行う。 具体的には、基幹のデータベースからBigQueryへ日次でデータを連携する。方式はELT——まずデータをそのまま転送(Extract/Load)し、変換(Transform)は分析基盤側で行う。基幹側の負担は「日次でデータを渡す」だけで済み、加工ロジックはすべてBigQuery側に持つ。この分離で二つの問題が同時に消える。どれだけ重い分析を回しても基幹の業務処理には一切影響せず、分析の自由度は基幹の開発スケジュールから解放される。
なぜBigQueryか
分析基盤にBigQueryを選んだ理由は、大量データの集計に特化していること、使った分だけの課金で始めやすいこと、そしてLooker Studioとの接続が自然であることだ。ここで私のEC運用の経験が繋がる。ShopifyのデータをLooker Studioで可視化し、SKU別の粗利をダッシュボードにする——この小さなBI運用を何年も回してきた。次期基幹のBI分離は、あの小さなアーキテクチャの全社版だ。Google Workspaceを使う会社にとって、BigQuery+Looker Studioの組み合わせは権限管理も共有も自然に繋がる。第1回のマルチクラウド——業務本体とは別に、分析はGCPに置く——の具体的な中身がこれだ。ツールが横並びに成熟した今、「どれが一番高機能か」より「自社の制約(既にWorkspaceを使っている、スモールスタートしたい)にどう噛み合うか」で選んだ。これも一つの評価軸だ。
ダッシュボードで「予実」が日常になる
このデータ基盤の上に、経営ダッシュボードを構築する。売上の予実管理、受注残の推移、在庫の状況、拠点別の実績。これまで月次資料として人手で作られていた数字が、日次更新のダッシュボードとして常時見られるようになる。「月末に振り返る数字」が「毎朝見る数字」に変わると、判断のリズムそのものが変わる。さらにこの基盤はAI活用の土台にもなる。整ったデータがBigQueryに揃っていれば、需要予測や異常検知といったAIの応用はその上に載せるだけだ。ここがこのシリーズの通奏低音と直結する。AIで分析するという手段は、いずれ完全にコモディティ化する。 だが、その手段が活きるか死ぬかを決めるのは、土台のデータ基盤の質だ。データが汚く分散している会社はAI以前の段階で詰まる——データ基盤こそがAI活用の前提条件であることは、強調してもしすぎることはない。 AIに飛びつく前に、自社が整ったデータを持っているかを見極めること。それが順序だ。
「分けること」は設計思想である
蓄積と分析の分離は、このシリーズで繰り返してきた思想——役割を分け、それぞれを最適な場所に置く——の一つの到達点だ。認証はGoogle Workspaceへ(第2回)、事実の記録はSSOTへ(第4回)、そして分析はBigQueryへ。それぞれの専門領域に、それぞれの仕事をさせる。全部を一つのシステムに抱え込ませない。分けることは、それぞれを強くすることだ。
次回は、システムの「顔」の話——複雑な業務画面をどう使いやすくするか。
評決ではなく、レンズを。
AIで分析する手段はいずれ完全にコモディティ化します。その手段が活きるか死ぬかは、土台のデータ基盤が整っているかという本質で決まります。AIに飛びつく前に、自社のデータの整い方を見極める——その順序こそが差を生みます。
AIで「作る」はコモディティになります。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、どう活かすか——を見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は発注者にあります。
選定とAIDDレディネスの要点を1枚にした無料の「評価軸チェックシート」を配布中です。
▶ 無料で受け取る:https://atomb.it/lens?utm_source=note&utm_medium=article&utm_campaign=s3
