00:00:03 データサイエンスにおけるデータ準備の概要。
00:00:46 データ準備の複雑さを過小評価する。
00:02:01 一般的なデータ準備プロジェクトの期間。
00:03:19 データ準備の速度と精度に関する課題。
00:06:07 データ準備の文書化の重要性。
00:08:00 サプライチェーンにおける「注文日」の解釈。
00:09:02 システムアップグレードによるデータ解釈の複雑さ。
00:10:07 エラーを回避するためのデータ意味論の理解。
00:10:15 ケーススタディ：サプライチェーンシステムの特異性。
00:14:53 業務におけるデータ文書化の必要性。
00:16:01 サプライチェーンにおけるデータ追跡の重要性。
00:17:24 自動化された意思決定におけるデータスコープの拡大。
00:18:42 データの呼び出しを個人に依存するリスク。
00:19:02 データ準備における課題と期待。
00:20:13 全社を挙げたデータ準備の取り組み。
00:21:56 実際の効果を通じてデータ解釈の正確性を判断する。
00:23:02 誤ったデータ解釈の結果とトレーサビリティの重要性。
00:24:37 不十分なデータ準備の困難さとその結果。
00:24:49 「良い」データ準備の概念。
要約
このLokad TVのエピソードでは、ホストのKieran ChandlerとLokad設立者のJoannes Vermorelが、GDPR遵守のために優先される一方で過小評価されがちな、データの準備におけるデータサイエンスの複雑さについて議論しています。Vermorelは、数ヶ月もの時間と大規模なリソースを必要とするデータ準備が、「ゴミが入ればゴミが出る」問題を回避するために極めて重要であると強調しています。これは、不整合または不完全なデータを理解可能な形式に変換することを求め、そのために徹底した文書化が必要とされます。このプロセスは複雑であり、ビジネス上の多面的な問題の性質やデータの歴史的背景によって形作られています。Vermorelは、組織内のさまざまなチームが関与する分散型アプローチを提唱し、効果的なデータ準備は誰にでも利用でき、明確な意思決定を促進すべきだと主張しています。
詳細な要約
Kieran Chandlerがホストを務めるLokad TVのエピソードで、彼とLokadの創設者であるJoannes Vermorelは、データサイエンスの分野におけるデータ準備の複雑でありながら極めて重要な役割について議論しています。GDPR遵守法の台頭に伴い、データは多くの経営者にとって重要な焦点となっており、企業はデータ準備にのみ4500億ドル以上を費やしていると推定されています。データ準備の目的は、生の状態で不整合または不完全なデータを解釈しやすく、応用しやすい形式に変換することです。
Vermorelは、データ準備の複雑さが頻繁に過小評価されている点に言及しています。企業が膨大なリソースを投入しているにもかかわらず、多くのプロジェクトがスケジュール遅延や予算超過に陥っています。Vermorelによれば、ほとんどのITシステムのバグは、データ準備段階の問題にまで遡るものです。彼は、ビジネス上の多面的な問題の性質がデータ準備の手順として現れ、このタスクの複雑さを増していると説明しています。
タイムラインに関して、Vermorelは、大規模なデータ準備プロジェクトは最低でも数ヶ月かかり、多くの場合6ヶ月に及ぶ可能性があると示唆しています。改善されたツールやよりスケーラブルなソフトウェアがプロセスを迅速化するという仮定にもかかわらず、全体のエコシステムの成熟度が進行を遅らせていると彼は指摘します。本当に「ゴミが入ればゴミが出る」問題を回避するためには、まずデータを文書化し明確にする必要があります。このプロセスが、より長いタイムラインの一因となっていると彼は論じています。
このプロセスの加速が可能かどうか尋ねられると、Vermorelは、単にリソースを増やすだけでは解決しないと説明します。扱われるデータは元々データ準備の目的で作られたものではなく、企業システムの副産物に過ぎません。例えば、彼はポイント・オブ・セールシステムの主な機能はデータ収集ではなく、顧客の支払い処理であると説明します。しかし、これらのシステムでさえ、バーコードエラーなどの実際の運用上の理由で、不整合や欠陥を含むデータを生成するため、効果的な供給チェーン最適化には広範な準備作業が必要となります。
また、Vermorelはデータ準備における文書化の重要性についても語っています。Lokadでは、データ準備プロジェクトは通常、テーブルごとに１フィールドあたり１行未満の文書化から始まり、最終的には１フィールドあたり１ページの文書にまとめられます。この包括的な文書化は、入力データの質が低いと出力データの質も低くなる、いわゆる「ゴミが入ればゴミが出る」という問題を防ぐために不可欠です。したがって、6ヶ月間のデータ準備のタイムラインには、この広範な文書作成プロセスが含まれています。
Vermorelは、単純なデータの一部、つまり過去の注文の日付に関して生じる複雑さや誤解の可能性に言及するところから始めます。彼は、「日付」というものが、一見単純に見えても、例えば顧客が商品をクリックした時、カゴの内容を確定した時、支払いが処理された時、または商品が倉庫で利用可能になった時など、複数の解釈が可能であると説明しています。
彼は、そのようなデータの解釈が、システムのアップグレードやビジネス慣行の変更により、時間とともに変わり得ることを指摘します。そのため、データそのものだけでなく、そのデータが生成された歴史的背景を理解することが不可欠です。これらの複雑さが認識されなければ、誤った解釈が原因で「ゴミが入ればゴミが出る」という問題に直面し、ひいては不適切な意思決定につながる可能性があります。
Vermorelは、自身の主張を裏付けるために、Lokadのクライアントのケーススタディを取り上げています。このクライアントは、短いリードタイムが求められる厳しい産業環境を運用しており、注文された商品の正確な数量の受領が不可欠です。クライアントのシステムには、納品数量が注文と正確に一致しない場合、注文全体が拒否され返送されるという機能が備わっています。これにより、注文よりやや多く受け取った場合には、システム上で元の発注書を納品数量に合わせて修正しなければならないという苦境に陥ります。この回避策により、彼らは納品を受け入れることができます。
産業運用における混乱を回避する。
しかし、このプロセスは、納品が受け入れられることを見越して、注文よりわずかに多くの数量を供給する熟練のサプライヤーによって悪用されています。その結果、実際の需要に比べて割増されたように見える発注書が作成され、購買チームのパフォーマンスを誤って示すデータのアーティファクトが生じます。Vermorelは、こうした複雑さは誤った解釈を避けるために文書化されるべきだと強調しています。彼は、問題の原因は購買チームのパフォーマンスの低さではなく、システムの限界とユーザーがそれに対処する方法にあると主張しています。
話題を変えて、Vermorelは、Lokadのように確率的予測のためにそれを使用する企業以外で、誰が歴史的データを重要視するのかについて論じています。彼は、受け取るまたは支払うべき金額を厳密にモニターしている企業が存在し、そうでない企業は時間の経過とともに淘汰されると指摘しています。彼の言葉を借りれば、これはビジネスにおける「ダーウィニズム」の一形態です。彼は、時間をかけて財務取引に注意を払う企業は、自然と歴史的データを重要視するようになると示唆しています。
議論はデータ準備に向かい始めています。Vermorelは、データは本質的に「クリーン」でも完全に理解されているものでもないと強調します。彼は、データ準備は単なるITの問題ではなく、すべてのビジネスデータの側面を理解してあらゆるビジネスの角度に対応することに関わると提案します。IT部門は、あらゆるビジネスの観点を習得することが期待できず、データ準備の唯一の責任を負すべきではないと述べています。
Vermorelは、組織内の異なる専門知識を持つチームを巻き込む分散型アプローチを提案しています。例えば、購買に関連するデータは購買チームが関与すべきです。同様に、サプライヤースコアカードに必要なデータは調達チームが関与すべきです。このアプローチにより、効果的なデータ準備に必要な洞察が得られます。
情報が不完全な場合においても、データの解釈に確信を持つ方法について、Vermorelはそれを科学的理論に例えています。理論が正しいと断言することはできませんが、厳しい検証に耐えうるときにその正しさが確認されます。データ準備の正確性は、その解釈から導かれる意思決定が正しいときに確立されます。誤ったデータ準備が意味不明な意思決定を招いた場合、原因を辿り、修正し、再評価することが可能です。
続いて、Vermorelは、特に複雑なサプライチェーンのシナリオにおいて、優れたデータ準備がどのようなものであるべきかを説明します。彼はそれを、単なる技術的詳細だけでなく、関連するビジネスの洞察や視点を提供する、よく書かれた本に例えています。データは組織全体で利用可能で、共有された理解を促進すべきであり、文書化、保守、データ理解に対する継続的な努力が求められます。
最後に、Vermorelは、データ準備はデータ自体の有効な理解に基づく解釈であるべきだと強調します。この理解が確立され維持されれば、データに対する論理的操作はかなり単純になります。つまり、良いデータ準備とは、よく書かれたガイドブックであり、サプライチェーンにおける明確かつ効果的な意思決定を可能にする共有された理解でもあるのです。
フル・トランスクリプト
Kieran Chandler: 今回のエピソードでは、データサイエンスの基本の一つであるデータ準備について議論します。最近のGDPR遵守法により、データは多くの経営者の頭上にあります。また、最近の調査によれば、企業はデータ準備にのみ4500億ドル以上を費やしているということで、大きなビジネスとなっています。データ準備は、未加工のデータを利用しやすい形式に変換するプロセスです。さまざまなソースからデータが入ってくるため、不整合や不完全、エラーが含まれることも少なくありません。そのため、Joannes、なぜ今日データ準備について話しているのでしょうか？これだけの企業が4500億ドル以上を投資しているなら、もう理解しているべきではないでしょうか。
Joannes Vermorel: その通りです。データ準備は非常によく知られた分野ですが、その変化に関しては体系的に過小評価されています。興味深いことに、ほとんどのデータ準備プロジェクトは締め切りに間に合わず、予算超過に陥っています。主要な問題は、ITシステムで見られる多くの実際のバグ、一般的にエンタープライズソフトウェアに起因するものが、データ準備段階の問題にまで遡るという点にあります。非常に複雑なプロセスです。よく知られた問題であるにもかかわらず、ビジネスの複雑さがデータ準備の手順として再現されるため、無限の領域となっており、最終的なレシピは存在しません。
Kieran Chandler: では、大量のデータを準備するにはどのくらいの時間がかかるのでしょうか？
Joannes Vermorel: 私は、大規模なデータ準備プロジェクトが数ヶ月未満で完了したのを見たことがありません。通常はおよそ6ヶ月の期間が必要です。より優れたツールやスケーラブルなソフトウェアがあれば迅速化できるという意見もあるでしょう。しかし、実際のところ、Googleのようなデータチャンピオンを除けば、エコシステム全体の成熟度が著しく低いため、まずデータを文書化し明確化する必要があります。「ゴミが入ればゴミが出る」問題を回避するためには、データに対して多くの作業が必要となるのです。したがって、数ヶ月かかり、複雑なサプライチェーンが関わる場合は6ヶ月が妥当なターゲットとなります。
Kieran Chandler: 6ヶ月はかなり長い期間のように思えますね。このプロセスを加速する方法はあるのでしょうか？大企業なら、単により多くの人員を投入すれば済むのでは？
Joannes Vermorel: ここで特定の問題が発生します。1ヶ月で赤ちゃんを作るのに9人の女性が必要ですか？問題は、私たちが対処している課題の種類を理解することにあります。まず、手元にあるデータは、そもそもデータとして作られたものではなく、企業システムの副産物に過ぎません。例えば、スーパーで支払いができるポイントオブセールソフトウェアを例に取りましょう。その主な機能は、店舗を出る際に顧客が支払うべき金額を処理することです。したがって、何らかの理由でバーコードが読み取れない場合、レジ係は同じ価格の商品を2回スキャンする可能性があります。結果的には正しい金額が支払われるものの、データ上は同じ商品が2回数えられることになります。
Kieran Chandler: 1つの製品がゼロ回計上されると、在庫管理に問題が生じ、電子記録が狂ってしまいます。これは良い解決策ではなく、避けるべきです。しかし実際には、データの問題を解決するか、会社の運営をスムーズにするかの選択があれば、現場でサプライチェーンを実際に運営する人々は、商品、顧客、サービスその他すべての流れを乱さない解決策を常に支持するでしょう。会社の運営が最優先であり、データはあくまで二次的な副産物に過ぎません。データは一級市民として扱われることはありません。だからこそ、サプライチェーンの最適化のために収集されたわけではないデータのために、常にこのような作業が発生するのです。これがすべての課題の原因なのでしょうか？
Joannes Vermorel: まさにその通りで、すべての変化はそこから生じるのです。
Kieran Chandler: 先ほど触れた文書化について話しましょう。どのような文書が期待されており、それはどのように役立つのですか？6ヶ月という期間に戻ると、どの程度の文書量が見込まれるのでしょうか？
Joannes Vermorel: 大まかな目安として、通常、ロカドではプロジェクト開始時に各テーブル・各フィールドごとに1行にも満たないドキュメントしかありません。通常、むしろドキュメントは全くないことさえ多いです。私たちは、ERP、MRP、WMS、またはその他のサプライチェーン運営システムにおいて、テーブルごとに１行のドキュメントすら存在しない多くのプロジェクトを始めます。しかし、作業が完了すると、各テーブル・各フィールドごとに１ページのドキュメントが出来上がるのです。つまり、20テーブルに20フィールドある場合、合計400ページのドキュメントになるということです。はい、これら400ページのドキュメントを作成するのには6ヶ月かかるのです。
Kieran Chandler: それは膨大な量のドキュメントですね。本当に全て必要なのでしょうか？
Joannes Vermorel: ゴミが入ればゴミが出るという事態を避けたいのであれば、すべて必要なのです。
Kieran Chandler: なぜですか？
Joannes Vermorel: 具体例を一つ挙げましょう。例えば、「orders」というテーブルがあり、そこには過去の注文が記録され、日付が含まれています。しかし、これは本当に単純なものなのでしょうか？ 我々は、この日付が一体どんな種類の日付なのかを問い直さなければなりません。例えば、顧客がeコマースサイトで商品をクリックしてカゴに入れた時の日付でしょうか？ あるいは、顧客がカゴを確定し支払いを行った時の日付でしょうか？ または、クレジットカード決済業者によって支払いが承認された日付、システムに登録された日付、あるいはシステム上で購入注文が最後に修正された日付なのでしょうか？ この「日付」フィールドだけで、約20通りの解釈が可能なのです。
さらに、もしあなたの会社が10年以上の歴史を持っているなら、「注文日」の細かな解釈が時代とともに変化している可能性が高いです。システムのアップグレードによってこのカラムの意味が変わったという状況に陥るかもしれません。
また、これは会社の全歴史において一様であるとは自然にはいかないのです。加えて、境界的な事例のようなさらなる複雑さが生じる可能性もあります。たとえば、本来この日付は顧客がカゴを確定した日付であるはずですが、支払いが最終的に不正として拒否された場合には、この日付は注文が不正として拒否された日時を示すことになります。
繰り返しになりますが、これは実際には非常に良い設計とは言えません。しかし、複雑なサプライチェーンを運営する企業は、複雑なシステムと長い歴史を持っており、初日から完璧にITが行われていたわけではないため、これらの歴史的な複雑さに対処せざるを得ないのです。そしてそれが、最終的にこのドキュメンテーションに反映されるのです。もしこれらの複雑さを認識しないのであれば、データを分析しようとするたびに問題に直面することになるでしょう。
Kieran Chandler: サプライチェーンの最適な意思決定を生成するために、データを誤って解釈してしまうと「ゴミが入ればゴミが出る」となる問題に直面します。つまり、データの意味を明確にすることがすべてということですか？
Joannes Vermorel: その通りです。データは単なる数字以上のものであり、ひとつのセルに複数の要素が組み合わさっている場合もあるということを理解する必要があります。データを生み出すソフトウェアを理解するだけでなく、人々がそのソフトウェアとどのように相互作用しているのかも考慮に入れなければなりません。ドキュメントは、人々が何をしているのかという「人間的な視点」を反映する必要があるのです。
Kieran Chandler: 過去にクライアントがこの問題に直面した例と、それが彼らの会社にどのような影響を与えたのか、良い例はありますか？
Joannes Vermorel: ええ、例を挙げましょう。あるクライアントは非常に高い可用性を求められる厳しい運用を行っていました。彼らは、非常に短いリードタイムでサプライヤーに発注を出していました。そのシステムには興味深い設計上の特徴があり、もし納品された商品の数量が最初に要求された数量と一致しなかった場合、発注全体を却下してサプライヤーに返す必要があったのです。
例えば、1,000ユニットを注文しても、サプライヤーが1,050ユニットを納品した場合、あなたはそれを却下しなければならなかったのです。しかし、その問題は、却下することで重大な運用上の問題が生じる可能性があるという点にあります。システムは数量の修正を許さなかったため、最終的には納品数量が注文数量と一致しない場合、元の発注書を納品数量に合わせて修正することになったのです。
Kieran Chandler: つまり、納品された数量に合わせて元の発注書を変更するということですか？
Joannes Vermorel: その通りです。しかし、これにより別の問題が発生しました。サプライヤーはこの慣行に気付き、会社が必要としているという事実を利用して、注文より多く納品してもよいと判断するようになったのです。彼らは非常識な量を納品するのではなく、会社が受け入れ可能と考える程度の数量を納品するようになりました。
データ上では、最初から大きな数量で注文が出されたかのように見えてしまいました。その結果、発注書の数量が必要以上に大きいという奇妙なデータが生じ、購買チームが適切な数量の選定に失敗しているように見えることになりました。しかし、実際の問題は購買チームではなく、システムの制約と、その制約に対処せざるを得なかった状況にあったのです。
これらすべての詳細は、誤った結論に至らないように文書化される必要がありました。購買チームが仕事に不向きだったのではなく、問題は彼らが直面していたシステムの制約にあったのです。
Kieran Chandler: システムがこれらの奇妙な副作用を生み出しているのですね。意味を理解するためには、説明用のページが必要ですが、回避策はありません。これは単に、ビジネスそのものの複雑さがこのデータに反映されている結果なのです。さて、狡猾なサプライヤーの話はここまでにしましょう。確かに面白い例でした。ところで、「人」の視点についても触れていましたね。明らかにロカドでは、過去のデータを用いて未来の確率予測を行っていますが、我々以外で過去のデータにこだわるのは誰なのでしょうか？
Joannes Vermorel: 一般に、受け取るべきまたは支払うべき金額に直接関係するものはすべて、大きな注目を集めます。人々が目を向けなかったわけではなく、本来受け取るべきお金を綿密に監視していなかった企業は、時が経つにつれて姿を消していったのです。これは、ダーウィン主義が働くようなもので、たとえそれに注意を払わなくても、やがて消えてしまうのです。だからこそ、五世紀前にイタリアの僧侶たちが複式簿記を発明したのです。注意を払わなければ、修道院さえも不適切な会計処理によって崩壊してしまいます。決して新しい問題ではありませんが、かつては重要視されなかった多くのデータが、今や極めて重要なものになっているのです。
例を挙げると、過去のstock-outsを適切に把握するためには、何を購入しているか、つまりサプライヤーに支払うべき金額、また何を販売しているか、つまり顧客が支払うべき金額を考慮していました。しかし、過去のstock-outを追跡することとなるとどうでしょう？ もし、購入数量を手作業で決定し、stock-outが発生していた奇妙な時期を覚えているサプライチェーンの実務者がいるならば、その歴史的記録を持つ必要はないのです。それらはシステムの一部にすぎないのです。
問題は、ロカドが行っているような、自動化された意思決定による定量的なアプローチに移行しようとすると、過去のstock levelsに関する正確な記録がはるかに重要になるという点です。さもなければ、システムは売上と需要不足の解釈を誤ってしまいます。
もし企業全体でより高度な自動化を導入したいのであれば、単なる生の会計情報だけでなく、より広範なデータに注意を払う必要があります。会計士はstock-outの日数に関心を持たないかもしれませんが、サプライチェーン最適化ソフトウェアはその点に敏感なのです。真に管理すべきデータの範囲を拡大し、文書化し、品質管理と保証を行う必要があるのです。
Kieran Chandler: つまり、過去の出来事を記憶しているこの一人にかなり依存しているということですね。データが入力される段階で、もっと整備された状態になっているべきではないでしょうか？ IT部門や他の誰かがそのデータを準備して、最初からクリーンな状態にするべきではありませんか？ それのほうが簡単な方法に思えます。
Joannes Vermorel: そうですが、問題はITの能力にあるのではなく、クリーンなデータというものはそもそも存在しないという点にあります。重要なのは、データが自動的に十分な深さで理解されるわけではなく、すべてのビジネスの側面が適切にカバーされているわけでもないという事実です。
Kieran Chandler: 企業がAIに何十億も投資していると言われますが、実際にはデータ準備という課題において現れるのは、ビジネス自体の複雑さなのです。そして「IT部門がそれをやるべきだ」というのは、IT部門に会社全体を運営し、あらゆるビジネスの側面に精通していることを期待するのと同じことです。
Joannes Vermorel: 全くその通りです。急に組織上の問題が生じます。なぜなら、IT部門に人事、マーケティング、購買などにも精通していることを期待することになってしまうからです。すなわち、IT部門に会社のあらゆる側面を完全に把握してほしいと望むのですが、それはあまりにも要求が高すぎるのです。IT部門はすでにIT関連の変化に対処しているので、会社内のすべてのビジネス課題にまで対応させるべきではありません。あるいは、IT部門を会社そのものと再定義すればいいのですが、それでは本来の目的が失われてしまいます。
ここに話を戻すと、データ準備は会社内でかなり分散した取り組みでなければなりません。というのも、例えば購買に関連するデータ準備に必要な洞察を提供できるのは、結局のところ購買チームだけだからです。同様に、サプライヤーのスコアカードを作成し、十分なaccuracyを持ってデータが本当に意味をなすようにするためには、調達を担当している各チームと話をする必要があるのです。
問題に取り組むたびに、その問題に精通した社内の専門家を巻き込む必要があります。彼らこそが、意味のあるデータ準備に必要な洞察を提供してくれる存在だからです。これは決して単なるITの問題ではなく、必要な知識をすべて収集し、データ処理を行った際に、解決すべきビジネス上の問題に対して意味をなさない結果にならないようにするための取り組みなのです。
Kieran Chandler: つまり、現時点ではまだ完全とは言えないということでしょうか。達している企業もありますが、それは例外であって一般的ではありません。すべての情報が揃っておらず、解釈に隙間がある中で、どの解釈が正しいと確信できるのでしょうか？ 可能性は数多く考えられます。
Joannes Vermorel: 全くその通りです。そしてこれは興味深い点で、科学的理論に似ているのです。あなたの理論が正しいと断言することはできませんが、「十分に機能している」と判断し、実際の現場で試された結果、うまくいくというだけなのです。より良いものがあれば当然それを採用するのですが、現状ではそれ以上のものは存在しないのです。
では、データ準備にとってそれはどういう意味なのでしょうか？ それは、データパイプラインの最後に、この解釈に基づいて自動生成された意思決定が正しいものであれば、あなたのデータ準備が正確であると分かるということです。正しい意思決定が得られるということは、最適化ロジックが効率的であり、machine learning層が正確であり、その他多くの要素が適切であることを意味します。根本的に、誤った解釈から正しい意思決定が生まれるわけはありえないのです。通常、データの解釈と準備が不十分であれば、その結果はあまりにもひどいものとなり、うまくいく余地が全くなくなってしまいます。
結局のところ、抜け道はなく、まずはデータ準備を徹底し、それに自信を持ってから意思決定を生成するしかありません。もしその意思決定が意味をなさないのであれば、問題の根本原因―しばしばデータ準備に起因する―を突き止め、修正する必要があります。最終的に、実務者自身がその意思決定を評価して「意味がある」と判断できるのであれば、正しいアプローチが取れているということになります。
Kieran Chandler: 一見、適切に準備されているように思えるかもしれませんが、実際にはすべてがグレーの領域なのです。サプライチェーンの実務者は、「いい意思決定だが、もっと改善できる余地がある。たとえば、需要の急増や急落を説明するために、競合他社の価格も考慮すべきだが、まだそのデータがない」といった意見を持つかもしれません。つまり、物事は白黒はっきりしているわけではないのです。
Joannes Vermorel: これまで、データ準備の困難さと、不十分なデータ準備がどのような状態であるかについて多く語ってきました。では、端的に言えば、良いデータ準備とはどのようなものなのでしょうか？ 中程度に複雑なサプライチェーンの場合、良いデータ準備とは、しっかりと構造化された本のようなものです。たとえば、各テーブルにつき1ページ、20テーブルなら合計400ページの本のようなものだと考えてください。しかし、ただ本であるだけでは不十分で、よく書かれた本でなければなりません。
もし非常に退屈な内容を書いてしまえば、誰も読むことはなく、組織に何の影響も与えません。ですから、よく書かれている必要があるのです。そして、ここで言う「よく書かれている」とは、読みやすいという意味です。また、ビジネスの視点から書かれていなければなりません。これはITドキュメントではありません。データ準備は、本来ITの問題ではなく、むしろすべてのビジネス上の洞察を盛り込む問題なのです。
ビジネスにおける正しい視点は常に変化するものです。もし業界の競争環境が変われば、特定の問題に対する正しい視点も変わってしまいます。ですから、この本はよく書かれ、そして維持管理されなければならないのです。
これは会社全体で分散して取り組むべき課題です。たとえば、マーチャンダイジングテーブルがそもそもどのように文書化されるべきかという適切な洞察と視点を持っているのは、マーチャンダイジングチームだけだからです。このようなデータ準備とは、会社内で広く共有され、アクセス可能な、クリーンでよく書かれた資料のようなものです。
面白いのは、必要な洞察がすべて整った後、論理であるデータ変換が、データそのものの正しい理解に基づいた単純な解釈へと変わる点です。データを理解し、文書化し、記述し、維持するためには膨大な労力が必要ですが、一度それを完了すれば、ロジックの記述は非常に単純になります。では、良いデータ準備とは何でしょうか？ それは、よく書かれた本のようなものであり、共有された理解であり、会社内のサプライチェーンのバイブルのようなものなのです。
Kieran Chandler: いいですね！ ということは、「データのグレーの影」は、組織からの新たなベストセラーになるのでしょうか？
Joannes Vermorel: たぶん、誰にも分からないですね？
Kieran Chandler: わかりました。今日はデータ前処理に関するエピソードをお楽しみいただけたなら幸いです。ご質問があれば、いつでもご連絡ください。また次回のLokad TVでお会いしましょう。それでは、さようなら。
