はじめに
以前、AS/400を利用した基幹システムのデータをBIで活用するためのデータ整備を行ったことがあります。
当時、一番苦労したのはSQLを書くことでも、ETLツールを使うことでもありませんでした。
本当に時間を使ったのは、
「同じ意味を持つデータを探し、業務上の意味を失わない形で整理すること」
でした。
今振り返ると、この作業こそが私にとっての「データの棚卸し」だったと思います。
最初に行ったのは、データを読み解くこと
この作業は、プロジェクトとして決められたものではありませんでした。
私はシステム部門へ相談し、AS/400へODBCで参照のみ行える権限を取得しました。
更新は一切行わず、データを読み取るだけです。
その状態で、ルーチンワークの合間を使って、
- どんなテーブルが存在するのか
- どんな項目があるのか
- どの業務で使われているのか
- 他のテーブルとどう関係しているのか
を一つひとつ調査し、Excelへまとめていきました。
当時は単なる一覧表を作っている感覚でしたが、後になって振り返ると、このデータ辞書がBI構築の土台になっていました。
同じ意味なのに項目名が違う
調査を進めると、すぐに大きな問題が見えてきました。
例えば、
- 規格書
- 社内加工実績
- 社外加工実績
- 受注情報
それぞれに、
- 得意先コード
- 商品コード
- 作業No.
が存在します。
しかし、同じ意味であるにもかかわらず、項目名は統一されていませんでした。
人が見れば同じ意味だと分かります。
しかしコンピュータは項目名で判断するため、そのままでは別のデータとして扱われます。
そこで最初に行ったのは、対応表を作成することでした。
| 元データ | 得意先コード | 商品コード | 作業No. |
|---|---|---|---|
| 規格書 | （システム固有） | （システム固有） | （システム固有） |
| 社内加工実績 | （システム固有） | （システム固有） | （システム固有） |
| 社外加工実績 | （システム固有） | （システム固有） | （システム固有） |
| 受注情報 | （システム固有） | （システム固有） | （システム固有） |
BIではこれらを、
- CustomerCode
- ProductCode
- WorkNo
という共通名称へ変換しました。
これにより、異なる業務データを横断して分析できるようになりました。
しかし、項目名を揃えただけでは分析結果は正しくならない
項目名を統一しても、分析結果がおかしいケースがありました。
その代表例が、
加工先と加工工程
です。
例えば実績データは次のようになっています。
| 加工先 | 加工工程 |
|---|---|
| A社 | 印刷 |
| A社 | ドライラミネート |
| A社 | 押出ラミネート |
| A社 | スリット |
| B社 | 印刷 |
| C社 | 印刷 |
| C社 | ドライラミネート |
| D社 | スリット |
このデータを見て、
「加工先マスタ」
「加工工程マスタ」
だけを作ってしまうと、一見きれいに整理できたように思えます。
しかし実際には、
どの加工先が、どの加工工程を担当できるのか
という重要な業務情報が失われてしまいます。
BIは業務の意味までは理解してくれない
例えば、
「スリット工程だけを分析したい」
とします。
本来なら対象は
- A社
- D社
です。
ところが、
加工先と加工工程を別々に管理してしまうと、
存在しない組み合わせまで分析対象になる可能性があります。
逆に、
「A社だけ」
で分析すると、
印刷なのか、
ドライラミネートなのか、
押出ラミネートなのか、
スリットなのか、
区別できなくなります。
BIは高速に集計できます。
しかし、
データの意味までは理解してくれません。
だからこそ、
「加工先 × 加工工程」
という関係性を保持したデータモデルが必要でした。
私が見ていたのはデータではなく業務だった
私はもともと研究開発部門に所属していました。
研究では、
「目の前で起きている現象を、どのようにモデル化するか」
という考え方をします。
この経験は、データ整理でも非常に役立ちました。
私が見ていたのはデータそのものではありません。
データの向こう側にある業務です。
例えば、
- 加工中の製品は、計画として扱うべきなのか。
- 実績になるタイミングはいつなのか。
- データはどの時点で登録されるのか。
- リアルタイムで見えている数値は、本当に現場の状態を表しているのか。
こうしたことを現場と照らし合わせながら、一つずつ確認していきました。
データが期待どおりに分析できないとき、その原因はSQLではなく、
業務とデータの意味が一致していないこと
である場合が少なくありませんでした。
データの棚卸しとは「意味を整理すること」
以前は、
データの棚卸しとは
「どのテーブルに何があるか」
を調べる作業だと思っていました。
しかし実際は違いました。
本当に重要だったのは、
- 同じ意味の項目を見つける
- 項目名を標準化する
- データ同士の関係を整理する
- 業務上の意味を失わないデータモデルを作る
ことでした。
私は、この作業を続けた結果、
「データはどう登録されるのか」
「加工中のデータは計画なのか実績なのか」
「なぜBIで誤った結果になるのか」
といったことを判断できるようになりました。
データを集めることが目的ではありません。
現実の業務を、正しくデータで表現できる状態を作ること。
それが、私にとっての「データの棚卸し」でした。
おわりに
BIやダッシュボードでは、SQLやETLの実装に目が向きがちです。
しかし、それらが正しく機能するかどうかは、その前段階でどれだけデータの意味を整理できているかに左右されます。
私がAS/400のデータ整備を通じて学んだのは、
データ統合とは、データを集める仕事ではなく、業務の意味を再設計する仕事である
ということでした。
技術的な手順だけでなく、「なぜデータの棚卸しが必要なのか」という考え方については、noteでも整理しています。
データの棚卸しとは何か ― 物理の棚卸しと比較して見えた本質
技術だけでなく、データを「会社の資産」として捉える視点に興味がある方は、こちらも読んでいただけると嬉しいです。