データ基盤とは
データ基盤は部署ごとに異なる売上高を同じ定義で確認できる仕組みです。
受注、会計、在庫、顧客管理などのデータは複数のシステムに分散しています。
これらを1か所へ収集し、分析と報告に利用できる形で提供します。
各支店の日報を本社で同じ様式へ統一する作業に近いです。
役割は収集、蓄積、変換、可視化、品質監視の5つに整理できます。
上の定義を実装の単位で5つに分割したものです。
変換は項目名と計算方法を統一する処理、可視化は集計した数字をグラフや表にする処理、品質監視は取り込みの失敗や件数の欠落を検出する処理を指します。
品質監視がないと数字の誤りを認識できません。
データベースは取引を記録し、BIツールは集計結果を表示します。データ基盤はその間で複数のシステムからデータを収集して整形する層です。
基幹システムが取引を確定して記録するのに対し、データ基盤はその結果を収集して比較と判断に利用します。

部署ごとに異なる数字を同じ定義で把握できる
データ基盤が普及した背景には、次のような困りごとがあります。
- 営業部、経理部、経営会議で売上高が異なる。
- 税込と税抜、受注日と計上日、返品の扱いも統一されていない。
- 月次の集計のたびに各システムからファイルを出力し、Excelで件数と金額を確認する。確認に2〜3日かかることがある。
- 部署ごとに同じ指標のExcelファイルを作成し、作り方が担当者に依存する。異動のたびに引き継ぎが必要になる。
- 会議の直前に数字が変化し、どの取引から計算したのかを追跡できない。
各システムからの取り込みを自動化し、項目名と計算方法を1か所で定義すれば、同じ数字を複数の切り口で確認できます。
部門ごとに分断されたデータの削減と、利用者自身による分析が効果として位置づけられます。

データ基盤の費用と未活用のリスク
データ基盤の費用は稼働後も毎年発生します。
金額と期間は対象範囲、データ量、元データの状態で変化し、以下は一般的な目安です。
- 初期構築: 要件の整理、データの抽出、変換処理とダッシュボードの作成、テスト。費用は数百万円から数千万円、期間は6か月から1年が目安。
- データ品質の整備: 元データの欠損、重複、表記ゆれ、部門コードの不統一を解消する。構築期間の半分近くがこの作業になることがあり、見積もりではこの分を先に計上する。
- 運用と人材: 取り込みを監視し、失敗したときは再実行し、定義の変更や問合せにも対応する。1人以上を配置する。人件費を除いた費用は年間数百万円で、人件費を含めると1,000万円規模が目安になる。
- クラウドの利用料: 蓄積するデータ量と処理の回数に比例し、データ数百GBの日次取り込みでは月数万円から十数万円が目安。個人情報を含む場合は閲覧範囲を定めて管理する。
構築の費用は一度きりですが、維持の費用は毎年継続します。
基盤が利用されないまま維持の費用を支払い続けると、回収できない費用が年ごとに積み上がり、損失が拡大します。
失敗と変更への対応
よくある失敗は基盤が一部の部署にしか利用されないまま維持されることです。
業務部門が求める切り口と画面が一致しない、更新が遅い、定義に納得していない、作成者が異動して放置されるといった原因が複合します。
利用されないまま維持されるのを避けるには、変更への備えと、誰が何を担うかの取り決めが必要です。
基幹システムの更改や組織変更で項目が変化すれば変換処理の修正が必要になります。
データ移行では移行元と移行先の項目を対応づける作業も追加されます。
データの所有者と品質の責任者を決定し、誰がどの範囲を参照できるかを記録します。
保持期間と削除の方法も構築の前に決定します。

定義と取り込み元による判断
まず、指標の定義を1枚の文書に整理できるかを確認します。
1枚に整理できないままでは、基盤を作成しても数字の不一致が解消されません。
定義の整理が完了した段階で、基盤の必要性はデータ量ではなく、同じ数字を何人で確認するか、更新と突合にかかる時間で異なります。
- 取り込み元が3つ以上あり、同じ指標を2部門以上が週次で確認するなら作成する。
- 取り込み元が3つ未満か、同じ指標を確認する部門が1つか、確認が月1回ならExcelの改善で対応できる。1シートの行数が約100万行に近い水準となったときは、行数の面からも移行を検討する。
- 月次の突合に1日以上かかる、更新が週次以上、定義の変更が月1回以上ある、のいずれかに該当するなら移行を検討する。
- 予算が数百万円未満で運用を担当できる人がいないなら、全社の基盤を作成せず1つの業務から開始する。
- 法制度の保存要件への対応が目的なら、会計システムの対応状況を先に確認する。電子取引の取引情報は国税庁の電子帳簿保存法の概要で説明されているとおり、一定の要件の下で保存が求められており、会計システムが対応していれば全社のデータの収集は不要になる。
データ基盤の厚い作り方と薄い作り方
全社のデータを日次で収集し、誰でも自分で抽出できる形にするのが厚い作り方です。
部門3つ以上、取り込み元5つ以上、週次以上の分析があり、運用担当1人以上を確保できるなら、この形が候補になります。
予算が数百万円で部門や取り込み元がこの水準に達しないなら、1つの業務領域に限定した薄い作り方から開始します。
すべてを基盤に移管する必要はありません。
1つの業務領域で定義を統一する作業と更新の流れを確立し、業務部門が利用することを確認してから拡大するほうが安全です。

よくある誤解
データ基盤を構築すれば数字が一致する
順序が逆です。
データ基盤を作成しても、定義が一致していなければ数字は一致しません。
基盤は定義を1か所に集約する場所で、定義を決定するのは業務部門です。
BIツールの導入だけでデータ基盤になる
BI(Business Intelligence)ツールは、集計したデータをグラフや表にする表示の層だけを担います。
各システムからデータを収集する処理と、項目と計算方法を統一する処理がなければ、元データの重複と不一致は残存します。
データ基盤は情報システム部門が構築するもの
指標と定義を決定するのは業務部門、実装と運用を担うのは情報システム部門です。
データ基盤の画面を業務部門が利用しなければ、作成しただけでは維持されません。
Excelファイルの共有と変更履歴が必要になったときが移行の合図
1人で自分の範囲を集計している間はローカルファイルのExcelで十分です。
共有ファイルのExcelを複数人で更新する、変更の履歴を追跡する、承認の記録を保持する、といった要求が生じたときは移行の合図です。
共有の機能を追加するだけでは数字は統一されません。
項目と計算方法を1か所で管理する仕組みが必要です。
移行の合図が生じたら最初に決定するのは指標の定義とその更新の責任者です。
お問合せ
事業の課題や技術的な悩みなどどんなことでもお聞かせください


