現在、IT系の仕事の中でデータアナリストは高い人気を博している。大手を含めて日本企業の大多数は情報活用が出来ていないので、データアナリストやその志望者にはブルーオーシャンが広がっているように見えるかもしれない。しかし、情報の分析・活用の現場で欠けているのはデータ分析のスキルではない。豊穣かつ正確なローデータ（分析用の生データ）の供給源となるべき「まともな基幹システム」である。
「いや、だからこそ分析基盤の整備から始める必要があるんです」とデータアナリストは語るかもしれない。そんな彼らにはあらためて"garbage in, garbage out"の格言を送りたい。garbage（ゴミ）を手間暇かけて統合・整形しても、そこから得られる分析結果は「整形されたゴミ」でしかない。基幹システムがポンコツである限り、分析基盤をいかに充実させても効果は出ない。かつてビッグデータという言葉があったが、企業が抱えるビッグデータの質が悪すぎて聞かれなくなった。
データアナリストにとってさらに都合の悪い事実がある。基幹システムがまともであれば、大袈裟なデータ分析基盤(SOI,System of Insight)もデータ分析のプロも要らない。基幹システムから取り出したローデータを、Excelやちょっと気の利いたBIツールに流し込めば、ユーザはその上で必要十分な分析をやれてしまうからだ。
そのことをあらためて思わされたのは、最近出版された『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』を読んだからだ。ちなみに原著のタイトルは、"Agile Data Warehouse Design: Collaborative Dimensional Modelling, from Whiteboard to Star Schima"なので、日本語タイトルはミスリードな感じではある。Data Warehouse Designの作業にデータモデリングが含まれているとはいえ、それをデータモデリングと訳すのはおかしい。
分析基盤と基幹システムとの連係
タイトルはさておき、私としてはディメンショナルモデリングの書籍は初めてだったので関心を持って読んだのだが、違和感がずっと消えなかった。とくに面白かったのは、勿体ぶった感じのする本文ではなく、日本語版の付録である事例集だ。それを読んでいてようやく違和感の正体に気づいたのだが、本文を含め、基幹システムとの連係の話がほとんど出てこない。
ここで言う基幹システムとは「本格的な基幹システム」のことだ。それはアジャイル開発された単機能な事業管理アプリのようなものではないし、会計システムでもない。受注、見積、購買、製造、出荷、売掛･買掛、在庫受払、支払･請求といったさまざまな取引をステータス管理できる本格的な事業管理システムのことだ。本書の言い方を借りるならば、マルチユーザによるOLTP（オンライントランザクション処理）を基礎とする企業情報システムのことである。
本来ならば基幹システムは、事業活動に関するローデータの宝庫だ。SOR(System of Records)とも呼ばれるくらいで、マスター項目を含めた基本的なディメンション（次元。分析・集計軸のこと）や、事業が生み出したファクト（取引実績）は基幹システムで扱われている。そんな重要なデータ源泉におけるデータモデルやそれとの連係に関して、ほとんど言及されていない。
なぜなのか。基幹システムの出来の悪さ、正確に言えば「データ分析基盤と連係する意義があるほど良質な基幹システム」が存在しないこと、それが前提になっているゆえではないか。それはそうだろう。良質な基幹システムがあれば、大袈裟なデータ分析基盤など要らないのだから。
多くの大企業では、高価なERPが基幹システムとして事業の中心に鎮座している（ように見える）。ところが重要な事業データは、各部門のユーザが個々に工夫した雑多なExcelシートの上で管理されていたりする。"Fit to Standard"の謳い文句につられてERPを導入してみたら、会計システムから発展した使い勝手の悪い業務システムでしかなかった。仕方ないので、その外側で重要な事業データを管理する羽目になっている。
ERPが入っていない企業も似たようなものだ。COBOL時代と変わらない使いにくい基幹システムだったり、アジャイル開発やサービス指向という名でツギハギされた「基幹システムもどき」だったりする。重要なデータはまとまった形では誰も把握していない。
これらの事例に共通している問題は「データ統制の欠如」だ。属人性にまみれた雑多なデータソースをデータ分析基盤に接続して「データの民主化を実現した」と胸を張るなんて噴飯するしかない。ローデータのレベルでデータ項目の定義域やアクセス権限が統制されていないゆえに、分析基盤を組み込んでも無政府状態であることに変わりはない。むしろその混乱が是認・助長され、改革を遅らせてしまう。
データ分析基盤だけでなく、ETL（抽出・変換・格納）やEAI（Enterprise Application Integration）といったデータ統合サービスについても同じことがいえる。出来の悪い基幹システムを納入したベンダー自身がそれらを提案することさえあって、これをマッチポンプと言う。
答は「まともな基幹システム」の中にある
ではどうすべきか。「データ分析機能を含むまともな基幹システム」を築けばよい。言ってみれば至極まっとうな話で、そもそもどんな統計データを提供できるか（すべきか）を含めて、基幹システムは仕様策定されなければいけない。そこらへんの課題意識が曖昧ならば適切にDB設計できない。
まともな基幹システムは、事業に関連するファクトと基本的なディメンションを扱うので、その内部で基本的な集計ができてしまう。その段階でデータ統制されているので、各ユーザがそれらをダウンロードして自由に加工するための「民主的体制」が手軽に実現する。ExcelやちょっとしたBIで賄えるので、大袈裟な分析基盤もETLもEAIも要らない。
「基幹システムの刷新？ そんな大それた提案は現実的ではない。とりあえずでもいいから分析基盤が必要なんです」といった反論があるとしたら、その種の発想が問題の元凶なのかもしれない。「必要なものをちょっとずつ作って、後でそれらをいい感じで繋げたらいい」といった漸進主義は、戦力の逐次投入に似た愚策である。けっきょくそれは「無秩序に建て増しされた昔の温泉旅館」を生み出し、運用コストが高いわりに使いにくい仕組みとしてビジネスの足をひっぱる。
ITの素人である経営者がそういった発想になるのは仕方ないにせよ、プロであるはずのベンダーまでもが「これからはサービス指向です」などと言いながら弥縫策的な提案をし続けている。その前にやるべき仕事は、事業の情報管理に関するグランドデザインを描き出し、これを実現するための移行計画を示すことではないのか。
本来の姿を実現するための、基幹システムが保持すべき集計・分析用データモデルの一般形を示そう（図１）。データモデルとしては単純であるが、ディメンショナルモデリングについて学びたければ、この基本構造を理解するだけでじゅうぶんだ。基本的ないくつかのファクトを、さまざまなディメンションの組み合わせ（複合主キー）で集計している。それだけのデータ構造で、ようするに「ファクトもいろいろ、ディメンションもいろいろ」という話でしかない。
ファクト(Fact1～3)の典型例を挙げるなら、受払実績（在庫有高増減履歴）、売上実績（売掛増減履歴）、仕入実績（買掛増減履歴）、製造実績（製造原価履歴）である。ディメンション(Dim1～5)の具体例は、取引先（顧客、仕入先等）、品目（商品、製品、材料等）、作業場等、そしてさまざまなタイムバケット（年月、四半期、年等）で、それらが組み合わされることでファクトの集計単位になる。これらに相当する多彩なデータ項目の論理関係を、ユーザにヒアリングしながら洞察し、図面化する。それが、基幹システムに関わる技術者のやるべき仕事である。
図１のモデルが、基幹システム側のデータモデルを洞察する過程で見えてくる点に注意してほしい。上掲書が言うように分析基盤向けのモデルを「プロアクティブ（先）」に確立しても、データ管理のあるべき姿は見えてこない。なぜならその際に根拠となるユーザ要件は、現状を前提とした古い発想にもとづくもの、あるいは、ローデータを収集できそうにない夢のようなものだからだ。
そうではなく、「基幹システム側の抜本的かつ地に足の着いたデータモデル」をプロアクティブに確立すべきである。その結果として、それまでユーザが発想できなかった有意義なファクトやディメンションが明らかになる。とくにDXを目指すのであれば、そうならなければ失敗だ。
ようするに、データ分析のためのディメンショナルモデリングは、基幹システム開発において粛々と実施されるべき広域データモデリングの下位課題でしかない。それゆえ、上掲書においてディメンションを７ｗ(Who, What, When, Where, hoW-many, Why, hoW)にこまごまと分類して解説しても、本が無駄に厚くなるだけ。読者ががんばって読み切っても、源泉側（基幹システム）を設計できるようになるわけでもない。
繰り返すが、実質的なデータ管理が、基幹システムではなくExcelシートを含めた雑多なアプリ群を用いてなされている限り、それらを集めた分析の効果は不完全なままだ。そのための分析基盤やETLやEAIは、基幹システムの劣悪さを限定的にカバーする「ピカピカの高級つっかえ棒」でしかない。企業にとって情報活用のボトルネックになっているのは「分析スキルや分析基盤の欠落」などではなく、「基幹システムの出来の悪さ」である。企業システムに関わる技術者やベンダーは、この事実から逃げてはいけない。
★この記事に関するLT＆座談会のイベントを、2月28日（金）に開催することになりました。基幹システムとデータ分析（第101回IT勉強宴会） 奮ってご参加ください。
