データ適格性は重要です

Joannes Vermorel

Wikipediaは、data analysisプロセスにおける7つのステップ、すなわちデータ要件、データ収集、データ処理、データクリーニング、探索的データ分析、データモデリング、そして最後に生産結果の生成を挙げています。Lokadが在庫予測、価格最適化、または商取引の最適化に取り組む際、我々のプロセスは上記で説明されたものに非常に近いものです。しかし、Lokadのチームが通常の作業の半分以上の労力を費やす非常に重要なステップがあり、それは上記のリストにすら含まれていません。そのステップがデータ適格性です。

「ビッグデータ」がバズワードとなった今、無数の企業が自社のデータをより有効に活用しようとしています。データ適格性は、おそらく不明瞭または不適切なビジネス目標に次いで、プロジェクト失敗の第二の大きな原因となっているでしょう―これは、多くの場合、取り組みが「問題」からではなく、「解決策」から始まるために起こります。この謎めいた「データ適格性」ステップに光を当ててみましょう。

ビジネスアプリの副産物としてのデータ

大多数のビジネスソフトウェアは、企業の運営を支援するために設計されています。例えば、POSシステムは顧客が支払いをできるようにし、Warehouse管理システムは商品を選別・保管するために存在し、ウェブ会議ソフトウェアは人々がオンラインで会議を実施できるようにします。このようなソフトウェアもデータを生成することはありますが、データはあくまで主要な目的の副産物に過ぎません。

前述のシステムはビジネスの運営のために設計されているため、担当者がより良い業務運営とより良いデータのどちらかを選ばなければならない場合、常に業務運営が優先されます。例えば、地元の大型スーパーのPOSでバーコードの読み取りに失敗した場合、レジ係は必ず同じ価格の商品を選んで二重にスキャンします。場合によっては、バーコードのチートシートが紙にまとめられていることさえあります。レジ係の判断は正しく、最優先事項は何があっても顧客の支払いを完了させることなのです。顧客へのサービスという緊急なニーズと比較すると、正確な在庫記録の生成は即座に達成すべき目標ではありません。

バーコードの読み取りの問題は実際にはデータクリーニングの問題だと主張する人もいるかもしれません。しかし、状況は微妙です。顧客に請求される金額やカゴ内の商品数が正確であるため、記録自体はある程度正確に保たれています。疑わしいレコードを安易にすべて除外してしまうと、ほとんどの分析において逆効果となるでしょう。

それにもかかわらず、企業やそのソフトウェアベンダーは、生成されるほぼ全てのビジネスデータについて、この基本パターンを熱心に無視し、データ処理からデータクリーニングへと直接飛びついているのをよく目にします。

データ適格性はデータの意味論に関わる

データ適格性ステップの目的は、データの意味論を明確にし、徹底的にドキュメント化することにあります。多くの場合、大企業がLokadに表形式のデータファイルを送る際、各ファイル内の各列に対して、通常は例えば「Price: 製品の価格」のような短い説明を記したExcelシートも添付されます。しかし、このような簡潔な説明は、数多くの疑問を残すことになります：

• 製品に適用される通貨は何ですか？
• 税込み価格ですか、税抜き価格ですか？
• 実際の価格に影響を与える、他の変数（例えば、割引など）が存在しますか？
• すべての販売チャネルで製品の価格は本当に同一ですか？
• まだ販売されていない製品に対しても、価格の値は意味を持つべきですか？
• 欠落値を示すゼロのようなエッジケースはありますか？

ordersテーブルにdate列が存在する場合、日時が以下のどのタイミングを示すのかという意味のあいまいさが生じる優れた候補となります：

• カゴの検証
• 支払いの入力
• 支払いの決済
• 会計ソフトでの注文の作成
• 出荷
• 配達
• 注文の締め

しかし、このような短いリストでは、実際の現場で遭遇する奇妙な事例をほとんど網羅できません。たとえば最近、ヨーロッパ最大級のオンライン事業者の一つで働いていた際、購入注文に関連する日付が、供給元工場の所在国によって意味が異なることに気づきました。ヨーロッパの供給業者はトラックを使って出荷しており、日付は倉庫への到着を示していましたが、アジアの供給業者は船舶を使って出荷しており、日付は港への到着を示していました。この小さな_ひねり_が、リードタイムの計算において、通常10日以上の差を生み出していました。

ビジネス関連のデータセットでは、データの意味論はほぼ常に企業の根底にあるプロセスや実務に依存しています。このようなプロセスに関するドキュメントは、存在する場合でも、通常は経営陣や監査人が関心を持つ点に焦点を当てており、企業のIT環境内に存在する無数の細部までは決して記述されません。しかし、細部にこそ問題は潜んでいます。

データ適格性はデータクリーニングではない

データクリーニング（またはクレンジング）は、実験科学において、実験結果を誤った方向へ導く可能性のある特定のデータポイント（外れ値）を除去する必要がある場合に最も理にかなっています。例えば、光学実験におけるチャート測定値は、実際の研究に関連する何かではなく、光学センサーの欠陥を反映しているに過ぎないかもしれません。

しかし、このプロセスは、ビジネスデータの分析に通常必要とされるものを反映しているわけではありません。データベース復旧の失敗で生じた残存データの中に外れ値が見つかることはありますが、ほとんどの場合、外れ値は僅かなものです。現在運用されている大多数のデータベースの（ビジネス上の）整合性は非常に優れています。誤ったエントリは存在しますが、ほとんどの最新システムは最も頻繁なエラーの発生を防ぐために十分に機能しており、後で修正する際にもしっかりとサポートしています。しかし、データ適格性は、データポイントを除去または修正するのではなく、むしろデータ全体に光を当て、その後の分析が真に意味を成すようにするという点で大きく異なります。データ適格性プロセスによって「変更される」のは、元のデータドキュメントのみです。

データ適格性は作業の大部分を占める

商取引、航空宇宙、ホスピタリティ、バイオインフォマティクス、エネルギーなどに関連する数十のデータ駆動型プロジェクトに携わる中で、_データ適格性_が常に最も要求の厳しいステップであることが明らかになりました。Machine learningアルゴリズムは洗練されているように見えますが、取り組みが回帰や分類問題というよく知られた範囲内に留まる限り、機械学習の成功は主に事前のドメイン知識に依存します。ビッグデータ処理も同様です。

データ適格性の問題は潜在的で、何が欠落しているのか分からないために発生します。これは、現行システムが生成するデータに基づいて理解されるべき「真の」意味論と、データ分析を行う人々が認識する「実際の」意味論との間にあるギャップです。知らないことが損害をもたらすことがあります。時には、その意味論のギャップが分析全体を完全に無効にすることさえあります。

私たちは、多くのIT実務者が、現実のビジネスデータセットに潜む_特異性_の深さを大いに過小評価していることを観察しています。ほとんどの企業では、テーブルの各フィールドごとに完全なドキュメントが存在しません。それでも、フィールドごとに半ページ程度のドキュメントがあっても、その記述は決して徹底的とは言えません。

Lokadが直面する（多くの）課題の一つは、そもそも必要と認識されていないものに対して料金を請求するのが難しいということです。そのため、私たちはしばしば「統計アルゴリズムのチューニング」など、より高尚なタスクや科学的に響く作業の名の下に、データ適格性の作業を押し付けています。

しかし、実際の作業は、データ適格性が人手集約的であるだけでなく、それ自体が非常に挑戦的なタスクであるということです。それは、ビジネスを理解すること、多くのシステム―中にはレガシーシステムも含まれる―にまたがるプロセスを理解すること、そして生成されたデータと機械学習パイプラインが求める結果とのギャップを埋めることの複合体です。

ほとんどの企業は、データ適格性に対する投資を大幅に怠っています。過小評価されがちな課題であることに加えて、データ適格性に人材を投入しても派手なデモや実際の数値として現れるわけではありません。その結果、企業はデータ分析プロセスの後半に急いで進むものの、何も期待通りに機能せず、まるで糖蜜の中を泳いでいるかのように苦労することになります。データを実際に理解するための簡単な解決策は存在しません。