数字が一致しても、同じ現実を見ているとは限らない

架空事例：青葉機材が貸出実績を使って事業分析を行う。データ、件数、集計期間、業務用語は教育用に作った条件であり、実在企業の集計・統計調査ではない。

「稼働率」が二つ届いた

経営会議へ、二つの資料が届いた。

営業部の資料では、機材の稼働率は45%。整備部の資料では50%と書かれている。計算ミスが起きたと思われた。しかし元のデータをたどると、どちらも算術としては正しかった。

一日に百台の機材があり、一台当たり八時間を対象とする。全台の理論上の時間は800台時である。整備中の十台を除くと利用可能な時間は720台時。実際の貸出し利用が360台時だった。

営業部は 360÷800＝45% と計算していた。整備部は 360÷720＝50% と計算していた。

数字の差は分母にあった。何に対しての稼働を測るか、定義が違うのである。これはサーバの可用性を表す稼働率とも異なる。たとえ同じ漢字でも、業務の意味が違えば一つの指標へ混ぜられない。

データ分析では、正しい計算より先に、何を数え、何を母集団としたかを確定する必要がある。

一行が表す出来事を決める

予約テーブルには、一件の予約につき一行がある。ところが、実際の貸出しは一つの予約に複数の機材が含まれ、返却時刻も機材ごとに異なる。

予約の行数を数えれば予約件数は得られる。しかし、貸し出した機材の個数や時間は、そのままでは分からない。別の明細テーブルと結合すると行数が増える場合があり、予約IDを単純に数え続ければ重複した件数になる。

データ分析の最小単位、すなわち粒度（grain）を決める。予約単位、機材単位、時間帯単位のどれを一行として扱うかで、集計可能な指標も異なる。

例えば「機材一台の一時間」を利用実績の基準にするなら、貸出時間の端数や途中返却の扱いを定める必要がある。「一日に何件の注文があったか」を知るために機材時間を集計しても、正しい件数にはならない。

原教材のデータモデル・集計・データウェアハウスの知識は、粒度を意識すると業務へつながる。主キー・外部キーの整合性と、分析で意味のある集計が成立することは、両方必要である。1

事実は一つでも、いつ見たかで答えが違う

営業部は今朝八時に集計した。整備部は昨夜二十時のデータを使っていた。その間に一件の返却時刻が修正されていた場合、同じ定義でも数字が違う可能性がある。

分析へ使うデータには、対象期間、データの更新時点、処理の完了時点、集計結果を再計算できる条件が必要になる。時刻の名称をそろえず「最新」とだけ表示すれば、別のチームが同じ数値を再現できない。

IoTの測定データも同じだ。機材が値を観測した時刻と、通信が復旧してサーバへ届いた時刻は異なる。昨日の測定が今日届いた場合、昨日分を修正して集計するか、今日の受信分として扱うかで結果が変わる。

また、時計のタイムゾーンや日付の区切りも影響する。月末の夜に発生した操作をどの月へ含めるかが決まらなければ、決算や請求の数字と一致しない。集計SQLが間違っていなくても、業務の期間定義と異なれば誤った意思決定へつながる。

OLTPを強くしただけでは、分析に向くとは限らない

予約システムのデータベースは、取引ごとの正しい状態を保存するために設計されている。予約確定時の競合や重複を防ぎ、必要な更新を整合的に行うことが重要だ。

一方、経営分析では何年分もの予約と請求、機材の点検を横断して集計したい。多数の行を走査する処理と、少数の行を速く更新する処理では求める構成が違う。

OLTPは業務トランザクションの処理、OLAPは集計・分析の処理に関係する用語である。特定の製品が必ずどちらか一方だけしかできないという分類ではないが、重視するアクセスパターンは異なる。1

本番DBへ重い集計を直接投げれば、顧客の予約操作が遅くなるかもしれない。分析用のデータストアへ複製・変換する案には性能面の利点がある。しかし、その時点で複数のデータの写しを持つことになり、鮮度と同期の問題が生じる。

「分離したら安全」でも「同じDBなら正確」でもない。取引の整合性と分析の鮮度を、求める目的ごとに評価する。

ETLかELTかより、変換の意味が問題になる

青葉機材は、予約システム、請求システム、点検システムのデータをまとめることにした。三つのシステムで顧客番号の形式が異なり、同じ会社でも別の識別子を持つ。

ETLは抽出（Extract）、変換（Transform）、格納（Load）の流れとして説明される。ELTは抽出・格納後に変換する順序で考える。どちらの方式でも、どの顧客を同一とみなし、取消しをどう扱い、訂正をどう反映するかという業務規則は必要である。

IBMのCRISP-DMの公開説明は、Business Understanding、Data Understanding、Data Preparation、Modeling、Evaluation、Deploymentという六つの段階を示す。順序は硬直した直線ではなく、問題に応じて戻りながら検討する。2

データの品質を点検する際も、欠損値をゼロで埋めればよいとは限らない。貸出時間がゼロという記録と、貸出時間が不明という記録は業務上異なる。外れ値をすべて除去すれば、まさに調べたい異常利用を失う可能性もある。

変換ロジックは、速く処理できたかだけでなく、業務の意味を保っているかを検証する必要がある。

データウェアハウスも、レイクも、置いただけでは分からない

データウェアハウスには分析に適した整理や集計を行う役割があり、データレイクではさまざまな形式のデータを保管する設計が考えられる。ただし、名称を選んだだけでデータが整備され、出典や品質が自動的に保証されるわけではない。

AWS Glueの公式資料では、Data Catalogがテーブルなどのメタデータを扱い、ETL処理がデータの変換・移送を担うことを説明している。3 カタログに登録したことと、表が示すビジネス上の意味を全員が合意したことは違う。

青葉機材が「予約確定日」という属性を持つとき、それは営業が承認した時刻なのか、顧客へ通知された時刻なのかを決める必要がある。同じ列名が二つのシステムにあっても、意味が違えば、単純に結合した結果は信頼できない。

データ辞書は属性の意味と制約を整理し、ビジネス用語集は業務上の概念をそろえる。テーブル定義を集めるだけでなく、使う人が同じ意味で話せる状態を作ることが重要になる。4

集計結果が保存されても、最新ではない

貸出実績の集計を毎秒実行すると負荷が高いため、あらかじめ集計した結果を保持することにした。分析画面は高速になったが、新しい返却の情報がすぐには反映されなくなった。

たとえばPostgreSQLのマテリアライズドビューは、計算済みの結果を保存し、REFRESH MATERIALIZED VIEWで内容を更新できる。参照時に必ず元テーブルの最新状態を自動再計算する仕組みではない。5

ここでいう「リアルタイム」という要求を曖昧にしない。契約先が当日何時までに出庫可能か判断する情報と、月次の事業分析へ使う情報では必要な鮮度が異なる。秒単位の更新が不要なら、計算負荷を減らすために遅延を許す選択も合理的である。

一方、集計データがどの時点まで反映されたものかを利用者へ知らせなければ、速い画面ほど誤解を生む。値の正確性と鮮度は別に評価する。

数字が下がっても、各現場は改善している

二つの業務区分について、正しく処理できた割合を比べてみる。

前月は標準的な業務が90件あり、81件成功した。例外的な業務は10件あり、1件成功した。全体では82件／100件、成功率82%だった。

翌月は標準的な業務が10件で10件成功し、例外的な業務が90件で18件成功した。標準業務の成功率は90%から100%へ、例外業務も10%から20%へ改善している。それなのに全体成功率は28件／100件、28%へ低下した。

同じ二つの区分ではそれぞれ改善したのに、全体の数字は逆へ動く。母集団の構成比が変わったからだ。集計だけ見て「すべて悪化した」と判断してはいけない。これはシンプソンのパラドックスとして知られる集計上の現象の一例である。

逆に全体が改善した場合も、すべての区分が改善したとは限らない。重みや対象区分の変化を確認する必要がある。

この例は実測ではない。比率の計算が正しくても、何が業務成果へ作用したかという因果関係まで証明したわけではないことを示すための作例である。

数字の来歴を残すことが、後からの判断を支える

経営者から、先月の報告書の数字が変わった理由を聞かれた。データ担当者は、変換プログラムの版を更新したが、以前の処理条件を残していなかった。

集計に使った元データ、抽出した時点、変換の規則、実行した版、生成した成果物を追跡できれば、差を説明できる可能性が高くなる。このようなデータの流れと加工の経緯をデータリネージ（lineage）として扱う。

AWSのデータガバナンス資料も、データの出所、変換、移動先を追跡する意義を説明している。4 ただし、メタデータだけ保管しても、必要な過去の元データや定義が失われれば完全に再現できるとは限らない。

管理の対象には個人情報や契約条件も含まれる。分析用に大量複製すると、閲覧可能な範囲と保存期間が広がり得る。権限と保持・削除を含む統制も必要になる。技術者が扱いやすいデータと、事業上取り扱ってよいデータを一致させるためである。

手法を選ぶ前に、意思決定を選ぶ

分析の目的が「故障を減らす」なら、何を判断するためのデータなのかを明確にする。予兆モデルを作りたいのか、部品の交換周期を見直したいのか、点検記録の入力漏れを発見したいのかで、必要なデータと技術は異なる。

規則で分かる異常に機械学習を導入しても、複雑さだけが増える可能性がある。逆に複雑な変動パターンを人がすべて手で分類しているなら、モデルによる支援が有用な場合もある。

技術の選定では、達成したい業務の結果、データの定義、入力と結果の検証方法、運用時に変わり得る条件をそろえる。最後に残る問いは、いつも同じである。新しい技術があるから使うのではない。必要な判断を、必要な根拠で行うために選ぶのだ。

知識を答案へ戻す

午前Ⅱ。 OLTP・OLAP、ETL・ELT、DWH・データレイク、データ辞書・リネージ、集計の粒度、相関と因果の違いを整理する。割合の分母を必ず確認する。

午後Ⅰ。 同じ数値名に異なる業務定義がないか、集計時点と対象期間が一致するか、元データからの変換が追跡できるかを本文から読む。

午後Ⅱ。 データ活用の目的、情報の正本と粒度、選択した収集・加工方式、品質と鮮度の確認、業務上の効果測定を説明する。

立ち止まって考える：整備部と営業部で機材稼働率が50%と45%になった。どちらか一方が計算を間違えたか

断定できない。整備中の台数を分母から除くかを含め、対象と時間の定義が違う可能性がある。何の意思決定へ使う指標かを明確にする。

出典と照合範囲

[1] コンプリートテキスト第1・3・17・18・25・27・28章、IPA SAシラバスVer.5.2：データモデル、集計、業務効果の評価を出発点とした。数値例と青葉機材の判断はすべて架空。公式シラバス

[2] IBM SPSS Modeler, CRISP-DM Help Overview：六段階の構成と反復的な関係を参照した。IBM公式資料

[3] AWS Glue Concepts：ETL処理とデータカタログの役割を参照した。すべての分析基盤で同じ実装を採用すべきという意味ではない。AWS公式資料

[4] AWS Enterprise Data Governance Catalog：業務用語集、データ辞書、データリネージの役割を参照した。AWS公式資料

[5] PostgreSQL 18, REFRESH MATERIALIZED VIEW：計算済みの結果の保存と更新の役割を参照した。他DBの同名機能に同一の仕様があると主張していない。PostgreSQL公式資料