ある配送拠点であるElm Yardでは、1マイルあたりの燃料費が2か月間で9％上昇しました。同じ期間に同じトラックを追跡したテレマティクスプラットフォームでは、走行距離に変化はなく、新しいルートもアイドリング時間の変化も確認されませんでした。どちらの数値も間違っていませんでした。
この組み合わせこそが、本稿で取り上げる問題の形態です。データが破損しているのではなく、それぞれ独自の信頼できる情報源から正確に報告しているものの、もともと相互に整合するようには設計されていない2つのシステムが存在しているということです。給油カードプラットフォームは、ドライバーのカードによる請求内容を追跡します。テレマティクスプラットフォームは、トラックが物理的に移動した場所を追跡します。両者ともそれぞれの役割を果たしており、不整合はどちらか一方の内部ではなく、両者の狭間に生じていたのです。
一般的な比較は、集計値同士の比較です。つまり、今月の燃料費総額と先月のそれ、今月の総走行距離と先月のそれといった比較です。しかし、この比較方法では、総額の背後にある個々の取引や移動の実態が把握できないため、ここで生じている不一致の正確な原因が見えなくなってしまいます。2つの集計値の乖離は、データの品質とは無関係で、定義やスケジュール、そして誰も一か所にまとめて記録していない業務ルールに起因する場合があるのです。
合計値のみを比較するチームは、不一致がコスト増につながり始めてから数日あるいは数週間経って初めてその事実に気づきます。集計値に異常が見られる頃には、その根底にある不一致は通常、すでにしばらくの間、目立たない形で進行しているものです。まさにそれがElm Yardで起きたことです。
数値が一致しない理由：システム間の不整合の背景にある4つのメカニズム
システム間の不整合は4つの要因によって生じ、一見不可解に見えるケースのほぼすべてが、そのいずれかに起因しています。具体的には、タイミングや遅延によるずれ、システム間のビジネスロジックの違い、スキーマや分類のずれ、そして重複や不完全なレコードです。
タイミングや遅延によるずれは、説明が最も簡単である反面、誤診されやすいものです。Elm Yardの燃料カードシステムでは、ドライバーがカードをスワイプした当日に取引が記録されていました。テレマティクスの走行距離データは、毎晩のバッチ処理で更新されていました。月曜日の夜に給油したトラックの場合、火曜日の朝のバッチ処理が完了するまで、対応する走行距離が表示されませんでした。この1日の遅れを、チームは当初、実際の不一致だと誤解し、2つの更新スケジュールを直接比較するまで、丸1週間も原因究明に追われていました。
ビジネスロジックの相違は、より目立たず、発見も困難です。なぜなら、両方のシステムが設計通りに正確に機能している可能性があるからです。燃料費の集計クエリは、MCC（加盟店分類コード）5541と5542、つまり「燃料」とマークされた2つのコードに厳密にフィルタリングされていました。Elm Yard近くのトラックストップにコーヒーカウンターが追加された際、カードネットワークは当該加盟店をMCC 5499「コンビニエンスストア」に再分類したのです。燃料取引のデータは以前と全く同じように生データフィードに流れ込み続けましたが、財務チームのクエリが捕捉するように構築されていた「燃料費」の分類からは外れてしまいました。これは、クエリの奥深くに埋もれていたルールが、カードネットワーク側が密かに変更したルールと一致しなくなったためです。
スキーマや分類のずれは、それほど目立たない場所でも現れます。同じメカニズム、つまり誰の決定もなく定義が変化することで、一晩のうちに、ジオフェンスの境界線のずれが、配車システムにおける「オフサイト」滞在時間フラグへと変化してしまう可能性があります。配車プラットフォームが故障したわけではありません。ヤードの境界に関する定義が数フィート移動しただけで、下流のすべてのシステムがその変化を継承してしまったのです。
重複レコードや部分的なレコードもこのリストに含まれていますが、これらは他の3つとは挙動が異なります。というのも、2つのレコードがともに存在しており、技術的にはどちらも間違っていないからです。一部のElm Yardドライバーは、テレマティクスユニットに依存せず、今でも走行距離を紙に手書きで記録しています。これらの手動入力は、同じ走行に対するテレマティクスの値に近いものの、完全に一致することはほとんどなく、数十分の1マイル、または丸められた開始時刻分のずれがあります。「余計」に見えるレコードを削除してしまうと、情報が失われてしまいます。ほぼ重複しているレコードと、完全な重複レコードでは、それぞれ異なる対処法が必要です。
これら4つのいずれを十分にさかのぼっても、同じ根本原因に行き着きます。表面上は、いずれもデータ品質の問題のように見えます。その実態は、一方のシステムで変更されたものの、もう一方では変更されなかった定義、スケジュール、またはビジネスルールであり、両者の乖離を誰も監視していなかったことによるものです。
少し立ち止まって考えてみてください。これら4つのうち、ご自身のチームが毎月比較しているシステム内で、検知されないまま既に稼働している可能性が最も高いのはどれでしょうか？
誰かが「データの問題」と指摘する前に、見過ごされていた不一致がもたらすコストとは
Elm Yardのチームは、その比較手法そのものに疑問が投げかけられるまで、6週間にわたり、あるデータ上の異常を運用上の傾向として扱っていました。その6週間の期間こそが、真のコストが積み重なった時期でした。それは9％という数字そのものではなく、チームがその数字を真実だと信じていた間に下されたあらゆる決定に起因するものです。
その期間中に両方の車両で「燃料消費量が多い」というフラグが立ったため、整備部門は2台の車両を点検のために引き取りました。整備士は、どちらのトラックにも異常を見つけられませんでした。フラグの原因は、トラック内部で発生していた問題ではなく、2つのシステム間の実体のない9％の差異でした。そのため整備工場は、そもそも問題ではなかった機器の診断に何時間も費やしてしまいました。
この異常事態は組織の上層部まで報告され、経営陣は、実際には存在しないコストの推移を根拠に、燃料カード業者の契約を再交渉するための案の作成に着手しました。データアーティファクトに基づいたベンダーとの交渉は、一度動き出してしまうと撤回するのに多大なコストがかかるものであり、今回の件は草案の段階を超えるところでした。
これは、ある特定のフリートチームに限った問題というわけではありません。Gartnerは、組織におけるデータ品質の低さによる年間平均損失を数百万ドル規模と推計しており、このテーマに関するForresterの調査では、少なからぬ割合のデータ実務者が、本来一致しているはずのシステムとの照合が行われず、使用可能に見えたデータという同じ根本原因に関連して2,500万ドル以上の損失が生じていると報告していることが明らかになりました。
最も目に見えにくいコストは、その出来事そのものよりも長く尾を引くものです。ルーティングチームや財務チームが誤った傾向によって痛い目に遭うと、同じシステムから発信される本物のシグナルまでも過小評価し始めるようになります。前回が結果的に何の問題もなかったからという理由で、6か月後に正当な異常が発生しても調査されずに見過ごされてしまいます。そして、このような信頼の失墜を修復することは、元の不整合を発見することよりも困難です。
ここには監査リスクという側面もあり、これは現場のチームよりも、アナリティクスリーダーにとってより重要な問題となります。これほどの規模の不一致が6週間も発見されずに放置され、保守に関する決定に影響を与え、さらにはベンダーとの契約締結寸前まで至る事態となりました。これは、監査人がいずれ質問してくるであろうトレーサビリティの不備です。誰かが何か間違ったことをしたからではなく、2つのシステムのデータに不一致が生じ始めた時期や、なぜそれに気づくまでに6週間もかかったのか、誰も説明できなかったからです。6週間というのは、幻のトレンドが何の異論もなく続くには長い期間であり、それが、次のセクションがツールではなくデザインから始まる理由です。
レジリエントな検出設計が他と異なる点
レジリエントな検出設計では、2つのシステム間で個々のレコードを比較し、一致したもの、一致しなかったもの、およびその理由を出力します。2つの集計合計を比較するだけで終わることは決してありません。合計値こそがまさに、Elm Yardの不一致が6週間にわたって潜んでいた場所だからです。
Alteryxのソースからターゲットへのマッピングガイドでは、こうしたシステム間の不整合について、フィールドがシステム間でどのように移動・変換され、場合によっては黙って削除されてしまうかといった点を具体的に解説しています。このガイドで説明している問題を解決するために、チームが最終的にどのようなツールを使うことになろうとも、一読の価値があります。
ERP、倉庫、フリートシステム全体のデータを1つの比較可能なビューに統合しようとすでに取り組んでいるチームにとっても、Alteryxのサプライチェーン分析リソースは有用な参考資料となるでしょう。これはElm Yardの事例に対する直接的な解決策としてではなく、その種のマルチシステムデータの統合に実際に何が必要かを理解するための背景情報として役立ちます。
Elm Yardに適用する場合、「記録レベルの比較」とは、今月の燃料費総額と今月の総走行距離を比較するのではなく、車両IDとタイムスタンプのウィンドウに基づいて、燃料カードの取引データとテレマティクスおよび配車イベントログを照合することを意味します。その結合が実行されると、集計上の差異ではなく、不一致レコードが調査の対象になります。複数のソース間でレコードを比較し、データセット間の一致および不一致を特定するために構築されたツールは、一致したレコード、燃料カードフィードにのみ存在するレコード、テレマティクスフィードにのみ存在するレコードという3つの結果を生成します。2つ目のカテゴリー、つまりテレマティクスとの照合結果がない燃料カード取引については、MCC再分類された請求額が、6週間後に漠然とした傾向として現れるのではなく、初日から直接反映されていたはずです。
手動で記録された走行距離については、どちらのシステムからも欠落していないため、別のアプローチが必要です。単に、両者が完全に一致することがないだけです。ドライバーが入力した走行距離とテレマティクスの記録を照合するには、完全一致のルールではなく、設定可能な類似度閾値を用いて、異なる入力ファイル間で完全に一致しない重複を特定できるように設計されたツールが必要となります。これが、「これら2つの記録は同じ移動を表している」と認識することと、「これら2つの記録は完全に同一でなければならない」と要求することの違いであり、手動の記録が後者の条件を満たすことは決してありません。
また、一見重複しているように見えても、実際には重複していないケースもあります。ここでは、重複レコードと一意のレコードを区別するために作られたツールが役立ちますが、そのツールのドキュメントには率直な注意書きが記載されています。つまり、名前も大まかな数値も同じで一見同じに見える2つのレコードであっても、実際には同じものを指しているとは限らないのです。これは、自然に解決するのを待つよりも、誰かに確認してもらうよう指摘しておく価値があります。
比較処理を実行する前に、各ソースのフィールドのプロファイリングを行っていれば、MCC(マシューズ相関係数)の問題を6週間も経ってからではなく、早い段階で発見できたはずです。列レベルのプロファイリングでは、NULL値、一意性、値の範囲、最小値および最大値などを網羅しており、まさに「燃料消費量の集計」に影響を与えたような「目立たない変更」を指摘しています。つまり、誰もクエリを編集していないにもかかわらず、フィールドの値のセットが変化してしまったというケースです。データを比較する前に両方のフィードで大文字/小文字、句読点、コードを標準化しておけば、最初からフォーマットの違いが実際の不一致と誤認されるのを防ぐことができます。
このいずれも自動では実行されません。ここにある各要素、つまり結合、類似性照合、重複チェック、プロファイルは、環境をスキャンして人の手を介さずに結果を報告する機能ではなく、各チームが自らの2つのシステム向けに設定するものです。設計の原則は、どの単一のツールよりも重要です。合計値ではなく記録を比較し、誰かが数値の不自然さに気づくのを待つのではなく、比較処理が継続的に実行されるように構築してください。
すでに存在するシステムに検出機能を後付けする方法
検知機能の後付けにあたって、給油カードシステム、テレマティクスプラットフォーム、またはそれらを取り巻く配車・保守システムを置き換える必要はありません。これには、両者の間に、これまで存在しなかった定期的な照合層が必要となります。それは、人が月に一度、合計値を抜き打ちで確認するのを待つのではなく、自動的に結合処理を実行するものです。
そのようなシステムはすでに存在しています。不足しているのは、新しいデータソースではなく、スケジュールに従って実行されるワークフローです。そのワークフローを構築するには、3つのステップがあります。
まず、両方のフィードを結合する前に加盟店コード、カテゴリコード、タイムスタンプを標準化し、MCC（マシューズ相関係数）の変更のような再分類によって比較で再び警告なしに不具合が発生しないようにします。結合処理やファジーマッチの比較は、監査カレンダーで指定されている頻度ではなく、テレマティクスのバッチ処理サイクルに合わせて毎晩実行するなど、基となるデータが実際に次に更新される頻度に基づいたスケジュールに従って実行してください。一致しないレコードは、誰も開かないエクスポートファイルに保存してしまうのではなく、最後に特定の指定された担当者に転送し、確認してもらうようにしてください。その3番目のステップこそが、不一致を「数日」のうちに発見するか、「数週間」経ってから発見するかの違いを生むのです。つまり、誰の名前も記載されていない不一致レコードのファイルは、Elm Yardで6週間もの間、誰も確認しなかった輸出貨物とまったく同じように振る舞うのです。
データ量が増加するにつれ、後回しにせず今すぐこれを構築すべき理由が一層説得力を増していきます。2030年までのエンタープライズデータとAIの導入に関するマッキンゼーの調査も、同様の課題を指摘しています。データ量やAIを活用したユースケースが拡大するにつれ、システム間でデータがどのように移動し、定義されているかを追跡する取り組みは、ますます必要不可欠になっていくのです。その成長に合わせて、その場その場での手作業による比較では、円滑に拡張させることができません。予定された比較レイヤーは、システムの数と、それらを通過するデータ量が増加するにつれて、その価値が高まります。
「Ask Alteryx」のような自然言語アシスタントを活用すれば、チームはこのような比較ワークフローをより迅速に構築・設定できるようになります。特に、結合処理を手作業でコーディングする予定のないアナリストにとっては、非常に役立ちます。これは、不一致を自動的に見つけるツールとしてではなく、ワークフロー構築の助けとして捉える価値があります。現時点では、その部分を自動的に行うツールは存在しません。不一致の原因がワークフローや定義の変更にあることが判明した場合、フィルタリング可能な監査ログを活用することで、何がいつ変更されたかを明らかにすることができます。これは、結合処理を行うアナリストよりも、6週間のデータ欠落について説明責任を負う分析部門の責任者にとって、より重要な情報となります。
これらはいずれも、唯一の正解というわけではありません。比較ロジックが非常に複雑である場合や、データ量が膨大である場合、あるいはすでにデータエンジニアリングチームがロジックを管理している場合は、ローコードの比較ワークフローよりも、コードベースのパイプライン（Python、dbt、SQLなど）を活用する方が適している可能性があります。最も確実な判断基準となるのは、現在そのロジックを誰が管理しているかという点です。もしその答えが「アナリストが時間のある時に処理する」というものなら、スケジュールされたワークフローは実際の課題を解決してくれます。一方、データエンジニアリングチームがすでに独自のパイプラインを運用している場合は、そのパイプラインにこの比較機能を追加する方が、その上に新たなツールを重ねて導入するよりも適切でしょう。
まだ実行していない結合から始める
この障害モードが自社のシステムですでに発生しているかどうかを確認する最も手っ取り早い方法は、結果が一致するはずの2つのシステム間でレコードレベルの結合を1回実行し、一致しない箇所を確認することです。全面的な監査を行う必要はありません。1回の結合、2つのシステム、そして一致しない出力結果を率直に確認するだけです。
Alteryx Oneは、カスタムコードを記述することなく、このようなシステム間の比較作業（データの結合、照合、プロファイリング、クレンジング）をサポートするように設計されています。これは、比較ロジックがデータエンジニアリングのバックログではなくアナリストの担当となるチームにとって、最も重要な点です。
Alteryx Oneの無料トライアルを開始し、ご自身の2つのシステム間で比較を実行してみてください。もし不一致があれば、それが6週間も隠れたままになることはありません。