複数情報源の売上データを統合する——単位・期間・出所と網羅性を検査する

売上が三通り届く月曜日

本部に支店別の売上報告が届いたとします。販売システムには出荷した日の金額、経理の表には入金した日の金額、営業の日報には注文を受けた日の金額が入っています。どれも見出しは「売上」ですが、同じ月の欄を足しても会社の売上にはなりません。重複だけでなく、月をまたぐ注文や返品の扱いも違うからです。複数の資料を一画面に集める仕事では、見た目が似た数字ほど危険な入口になります。

最初の問いを「どの表を取得できるか」から「この画面で何を比べたいか」へ変えます。今回の目的は支店別の出荷実績を前年同月と比較すること、と決めれば、注文額と入金額は参考情報へ分けられます。三つの表を同格に扱う必要はありません。利用者が必要とする判断を先に定めることで、統合の対象も、統合してはいけない対象も見えてきます。データを集めることと、同じ意味へ揃えることは別の工程です。

営業会議で欲しいのが出荷の増減だと分かれば、注文の増減を同じ線で描く必要もなくなります。受注から出荷までの遅れを知りたいなら、二つの指標を別に置いて関係を見ます。どちらを採用するかを争うより、指標が答える問いを分ける方が、情報源それぞれの価値を生かせます。目的が変わったときに同じ集計を使い続けないためにも、画面が答える問いを表示の近くへ残します。

比較の単位を文章で固定する

支店別の出荷実績という目的にも、まだ曖昧さがあります。税込みか税抜きか、出荷後の返品をどの月へ戻すか、海外支店の換算通貨は何か。ここでは「支店、出荷月、税抜き金額、返品控除後、日本円換算」の組を一件の比較単位とします。項目名だけ並べるより、計算の前提を一文で残す方が運用者に伝わります。支店の移転や統合がある場合は、現在の名称だけで過去年月を読み替えないことも約束に加えます。

この定義は、一番詳しい情報源に全てを合わせるためのものではありません。別の目的では入金日基準が正しいかもしれません。同じ資料を使う二つの画面で数字が異なるなら、それぞれの比較単位を示す必要があります。揃える対象を限定しておけば、経理担当が会計資料と数字が違う理由を確認できます。単位の決定を隠したまま「正規化済み」と表示しても、数字の信用は増えません。比較可能性は処理の名前ではなく、前提の一致で決まります。

変換の責任者も決めます。支店の対応は営業管理、税の扱いは経理、取得の不具合は情報システム、と分ければ確認先が明確になります。全てを技術担当の判断にすると、処理は正しく動いていても業務の意味が違うままになります。定義には確認日と責任者を添え、制度や組織の変更があった時点で見直します。日々の収集では、承認した定義を継続して適用できます。

入力に出所と時点を添える

取り込む行には支店名、金額、対象月だけでなく、提供元、資料の更新日時、取得日時を添えます。更新日時は資料側が示した時刻、取得日時は自分たちが取り込んだ時刻です。月曜日に取得したからといって、月曜日の値とは限りません。紙から転記した表なら、資料に時刻がないこともあります。その場合は不明と記録し、取得時刻で代用しません。後から誤りを調べるとき、この区別が同じ表を再取得すべきかの判断になります。

入力の原形も保持します。例えば「札幌支店」「札幌営業所」という二つの名称を同じ支店として扱う場合でも、元の表記まで上書きする必要はありません。利用者向けには統一名称を見せ、調査用には元の表記と対応関係を残せます。単位が千円なら元の数値と単位を保持したうえで円へ換算します。整えた数字だけ保存すると、誤差が計算によるものか、入力資料の改訂によるものかを切り分けられなくなります。

保存時には、原資料から整えた行へ進める関係も残します。数字だけ一致していても、どの行を使ったかが分からなければ訂正時に困ります。一つの合計が複数行からできているなら、その対象行の組を示します。これにより、ある資料が撤回されたとき、影響する月と画面を絞れます。全期間を作り直すか、対象月だけを直すかも、根拠との関係があれば判断しやすくなります。

対応表は便利だが推測では埋めない

名称の対応は、担当者が承認した一覧で管理します。会社名や支店名の似た文字列をAIが見つけることは候補作りには使えますが、似ていることだけで統合してはいけません。同じ都市に二つの営業拠点がある場合や、旧支店を引き継いだ別法人がある場合があります。新しい表記が現れたら、一旦未対応として残し、確認の対象を絞ります。既存の対応を毎回問い直す必要はなく、変化した部分へ確認を集中できます。

期間の対応も同様です。「第一区分」という表記が一月から三月とは限りません。会社の年度が四月始まりなら意味が変わります。入力の期間を開始日と終了日へ展開し、比較対象の月と一致するかを確認します。三か月の合計を三で割って各月へ配る方法は、便宜的な推計であって実績の統合ではありません。どうしても推計が必要な分析では、推計方法を別欄で説明します。取得できない月を自然な数字で補うことは、欠落を発見しにくくします。

対応が未確定の行は、単に捨てず確認一覧へ残します。一件の未対応が金額の大部分を占めるなら、件数だけでは影響を判断できません。件数、金額、対象月を併記して確認順を決めます。ただし大きな金額を先に確認することと、小さな行を無視することは別です。完了時には全件の扱いが決まっているかを確認し、残件がある場合は集計の対象範囲へ明記します。

値が衝突したときの選び方

同じ支店、同じ月、同じ基準なのに二つの資料で金額が違う場合があります。単純に最新の取得値を採用すると、後から取得した古い資料が勝つことがあります。今回は、提供元の確定版を優先し、その中で改訂日時を比較する方針にします。速報値しかない月は速報と表示します。選ばなかった値も出所とともに残し、差が許容範囲を超えた場合は確認へ回します。多数決で正しさを決める方法も、同じ元データを転載した三資料では機能しません。

優先順位は万能な規則ではありません。確定版の提供が遅れる情報源を使うなら、速報表示を残す方が利用者に役立つ場合もあります。重要なのは、画面の数字がどの方針で選ばれたかを説明できることです。選択理由を「確定版を採用」「速報しか存在しない」「相違があるため比較対象から除外」のような日本語で残します。統合の結果が一つの数値でも、その背後の選択まで消してしまう必要はありません。

優先順位を変更したときは、以前の合計と新しい合計の差を確かめます。値が変わった理由が入力の訂正なのか、選択方針の変更なのかを分けます。方針変更をデータ更新と同じ表示にすると、利用者は業績が変わったと誤解するかもしれません。過去の報告を同じ基準で再計算するか、当時の基準のまま保存するかも決め、報告の用途に応じて両方を残せるようにします。

合計より先に網羅性を検査する

支店別の合計がきれいに計算できても、二支店が欠けていれば全社の数字ではありません。期待する支店一覧と取得できた支店一覧を照合し、どの月で何が足りないかを確認します。金額の合計と取得率は別の情報として出力します。十支店のうち八支店だけを取得したなら、八支店分の合計として見せます。前年は十支店、今年は八支店のまま増減率を出すと、欠落が業績低下に見えるため、同じ範囲へ揃えた比較も必要になります。

検査には異なる種類の失敗を用意します。同じ行が二度届く、千円の値が円として届く、一支店だけ年度表記が変わる、確定版の後に速報版が届く、返品だけ負の値になる。これらを「取込成功」の一種類で片付けないことが大切です。取得の成功、形式の妥当性、意味の一致、集計範囲の充足を順に分けて確かめます。出力した合計だけを見て検査すると、個々の誤りが相殺され、偶然正しい数字になることもあります。

検査の出力は担当者が直せる形にします。「不一致」だけではなく、「支店名は対応済みだが対象期間が違う」「税の扱いが資料に書かれていない」と具体化します。入力が不足しているときに処理方法を推測して先へ進めるより、必要な確認を短く示す方が、翌月の作業にも役立ちます。繰り返し同じ相違が起きるなら、入力資料の側を改善する相談につなげられます。

収集から配信まで、根拠を渡す

支店報告の統合では、取得、構造化、蓄積、読み取り専用配信を別の工程へ分ける設計が考えられます。金融データ基盤のヤクモ提供の実装には、決算、株価、為替、マクロ統計を扱い、取得値ごとの出所と網羅率、整合性監査、開示原本の保持を組み合わせた構成があります。支店報告へ応用するなら、採用した金額と元の報告の対応を残し、どの支店が含まれるかも保存します。収集の成功だけで比較可能とはせず、基準と対象がそろったことを次の条件にします。

金融データの収集と社内の表の統合では、必要な定義が違います。企業内の名称対応や税、返品の基準は別途定義し、入力資料へ当てはめる必要があります。収集するデータ規模だけから処理時間の削減率は分かりません。支店報告の試作では、どの差異を自動処理し、どの差異を担当者へ返すかを先に定めます。新しい名称は確認待ちへ、既知の単位は換算へ、と処理を分け、担当者が訂正した理由を次の検査へ加えます。出所と対象範囲を残すことで、修正する場所を選びやすくなります。

原本の保持は、整形済みの値を疑うときに役立ちます。ただし原本を保存するだけでは参照しやすくなりません。取得値と原本の該当箇所へ戻れる関係を作り、同じ資料を毎回探し直さない設計が必要です。支店報告なら、どの行が採用されたかと、採用しなかった理由も結び付けます。配布できる資料の範囲も確かめます。根拠を見せることが、閲覧者へ全資料の権限を与えることを意味するわけではありません。数値の閲覧と原資料の閲覧を分けて確認します。

収集処理をPython、構造化したデータの保存をPostgreSQLやSupabase、原資料の保持をオブジェクトストレージへ分担する構成が考えられます。定時のクラウドバッチとpytestによる検査を加える場合も、各工程の入出力を先に定めます。売上例では保存前に期間と単位を検査し、元の資料と採用値を対応付けます。技術名だけから更新間隔や個別設定は決まらないため、一件の取込から配信結果までを追い、欠落や訂正がどこへ伝わるかを確かめます。

揃えるほど元の違いも見せる

利用者向けの出力は、支店名、対象月、比較基準、採用した金額、速報か確定か、欠落の有無を基本にします。詳細を開けば提供元、原資料の期間、単位、選択理由へ進めるようにします。全てを初期画面へ詰める必要はありませんが、問い合わせを受けた担当者が根拠へ戻れる経路は必要です。支店長が増減を見て営業方針を決める画面と、経理担当が入力を点検する画面は、同じ蓄積データから別の見せ方を作れます。

この設計は在庫、勤怠、問い合わせ件数の統合にも応用できます。ただし、対象の意味が一致しない情報を無理に一つへ寄せるより、別の指標として並べた方が理解しやすい場合があります。整える作業の成功は列の数が減ることではありません。利用者が同じ条件で比較でき、例外の理由へ戻れることです。最初は一種類の報告と少数の情報源から始め、名称、期間、単位、改訂の規則を確かめてから対象を増やす方が、後からの修正範囲を把握しやすくなります。

運用を続けると、例外が増えて対応表が読みにくくなります。だからこそ、例外を無制限に追加する前に、比較単位そのものが適切かを見直します。複雑な条件で二つの指標を無理に結ぶより、用途別の集計を分けた方が保守しやすい場合があります。例外の件数だけを減らすのではなく、利用者が必要な違いを理解できることを目標にすると、統合の限界を説明できます。