企業データの種類

ほかに 28 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

A kitchen where each kind of food is kept its own way: bins and jars on the pantry shelves, fresh food on the counter, the fridge and freezer, a recipe book. — AI で生成した画像

モジュール2／6：Data Architectコース第4章「企業のデータを理解する」。各モジュールは単独でも読めます。前へ：Salesforceは多くのシステムの一つ · 次へ：Salesforceを取り巻くシステム

このモジュールが答える問い： 企業はどんな種類のデータを持っていて、なぜそれらは違う場所に属するのか？

顧客のレコード。国の一覧。注文。項目の定義。5年分の売上の合計。400万枚の配送写真。どれもデータですが、アーキテクチャの上では同じものではありません。変わり方も、増え方も、使われ方も違い、所有している人も違います。そして自動的に同じ場所に置かれるべきではありません。ですから誰かが「このデータをSalesforceに入れる必要がある」と言ったら、私の次の問いは**それはどんな種類のデータか？**です。その答えが、それをどう扱うべきかを教え始めてくれます。

オブジェクトではなく種類から始める

Salesforceの人間として、私たちは要件をほとんど瞬時に構造に翻訳します。顧客なら取引先、写真ならファイル、ステータスなら選択リスト。いずれはそれも役に立ちます。企業レベルでは、まずどんな種類の情報を扱っているのかを知りたいのです。分類の方法はたくさんあります（DAMAの知識体系が標準的な参考文献です）。私が役立つと考えているのは6つの種類です。マスター、参照、トランザクション、メタデータ、分析、非構造化。 分類そのものがアーキテクチャなのではありません。よりよい問いを立てるための方法です。

マスターデータ：ビジネスが知っているもの

マスターデータは、ビジネスがその周りで回っている長続きするものを記述します。顧客、製品、価格、従業員、仕入先、拠点、資産。Salesforceの営業の組織なら、取引先と取引先責任者、製品と価格表です。Steve Truckingでは、**小売パートナー（Retail Partner）**がマスターデータです。Keystoneは出来事ではなく、Steve Truckingが継続的な関係を持っている組織です。9つの物流センターもマスターデータです。

マスターデータは、それを使うトランザクションより長く生きます。一つの小売パートナーが何百万件もの配送を持ち得ます。ですから、マスターデータについての最初の問いはいつも**誰が所有しているか？**です。Salesforceではないかもしれません。ERPが製品を所有しているかもしれません。Salesforceが見込み客を所有し、顧客になった時点でERPが権威を持つのかもしれません。MDMプラットフォームが、複数のシステムから組み立てた顧客の企業としての識別を所有しているかもしれません。第6章「マスターデータとID」で深く掘り下げます。今は、その形に気づいてください。

参照データ：ビジネスが共有する語彙

参照データは、ほかのデータを分類するために使われる管理された語彙です。国コード、通貨、製品カテゴリ、理由コード、ステータス。Steve Truckingの配送ステータス（予定済み、積み込み済み、配送中、到着間近、配送済み、設置済み、例外、返品）は参照データです。それは配送ではなく、配送を記述するために使われる言葉です。

小さくて無害に見えます。値が8つの選択リストであることも多いでしょう。小さいことと重要でないことを混同しないでください。SalesforceがDeliveredと言い、ERPがCompleteと言い、小売パートナーがDを送ってくるなら、誰かがそれぞれの意味と対応づけを定義しなければなりません。参照データは、連携の前提が隠れている場所です。

トランザクションデータ：何が起きたか

トランザクションデータは活動を記録します。注文された、支払われた、配送が完了した、ケースが開かれた。同じ営業の組織なら、見積と見積品目、注文と注文商品、支払いです。どれも顧客と製品を指し示しています。Steve Truckingの年100万件の配送はトランザクションデータであり、そのステータス更新もそうです。配送1件につき約8回なので、年800万回のステータス変更。しかも年30%で成長しているビジネスです。

それはマスターデータとはまったく違う成長曲線です。上には3社の小売パートナー、その下には何百万行。ここでスティーブのゼロの数が効いてきます。小売パートナー → 配送 → ステータスを見て、すべての箱に同じ重みを与えることはできません。トランザクションデータでは、私はすぐにボリューム、速度、保持、履歴、アーカイブ、連携、そして人が実際にそれをどう見つける必要があるかを考えます。第2部ではそこに多くの時間を使います。

メタデータ：データについてのデータ

あなたはこのコースでずっとメタデータを扱ってきました。オブジェクトの定義、項目のデータ型、説明、リレーション。企業全体にもあります。ウェアハウスのスキーマ、連携の対応表、データカタログ、APIの契約、そして項目ごとの所有者、機密度、定義、系統、保持のルール。値はデータで、それが何を意味するかの記述がメタデータです。第3章で言ったように、Flag2__cは誰にも何も教えてくれません。そして、AIがデータの意味を読み解くためにメタデータを読む今、それはさらに重要になっています。

分析データ：ほかのデータから作ったデータ

「過去5年間の、小売パートナー別の時間通り配送率は？」はトランザクションではありません。分析の問いであり、何百万件もの配送から新しいデータを導き出すことで答えます。時間通りの割合、損傷率、パートナーごとの売上、設置の品質、クルーの傾向。そしてそれは別の仕事です。「トラック217の次の停車地は？」と尋ねる配車担当者は、5年分の履歴を走査する必要はありません。地域ごとの5年分の時間通りの実績を比べる経営陣は必要です。だから分析データはたいてい、その仕事のために作られたウェアハウス、レイクハウス、分析プラットフォームに置かれます。Salesforceに保存できるからといって、業務プラットフォームがその上ですべての分析を行う場所になるわけではありません。

非構造化データ：行に収まらないもの

文書、PDF、画像、音声、動画、メール、文字起こし、ナレッジ記事。Steve Truckingでは配送写真です。配送1件につき約4枚、設置があればもっと多く、年400万〜500万枚。写真はただの項目ではありません。大きく、人の家の中を写していることがあり、独自の保持ルールを持ち、検索のされ方も違います。そもそも検索されるならですが。

この種類は年々重要になっています。以前は構造化されたモデルの外にあった情報で、AIが今では役に立つことができるからです。文字起こしはデータです。PDFのマニュアルはデータです。設置の写真はデータです。だからといって、それがSalesforceのコアに属するわけではありません。全体像の上に属するのです。

Click to enlarge

6つの種類、それぞれに4つの問い。答えは種類ごとに変わります。そこが肝心なのです。

種類は問いの半分にすぎない：ワークロード

どんな種類のデータを持っているかを知るだけでは足りません。それで何をしているのかも知りたいのです。ここでは3つのワークロードが重要で、それを混同すると悪いアーキテクチャになります。

業務：ビジネスを動かす。 配車担当者が配送を更新し、クルーが停車地を完了させ、エージェントがケースを開く。小さな読み書きがたくさんあります。これを見つける、あれを更新する、今日の停車地を見せる。これがOLTP（オンライントランザクション処理）で、Salesforceはこれがとても得意です。管理者や開発者が暮らしている場所です。

分析：ビジネスを理解する。 5年分のすべての配送を、パートナー別、物流センター別にまとめ、前年と比べ、財務と結合する。ここでは走査と集計をしています。これがOLAP（オンライン分析処理）で、ウェアハウス、レイクハウス、分析プラットフォームはこのために作られています。簡単に言えば、組織はビジネスを動かし、ウェアハウスやレイクはビジネスを分析する。 典型的な間違いは、そのワークロードを業務プラットフォームに載せ、ゼロが増えるにつれて驚くことです。誰かが膨大な履歴を繰り返し走査したいなら、「ただのレポートの一つ」として扱わないでください。それが正しいプラットフォームなのかを問いましょう。第2部の大規模に向けた設計 *(coming soon)*でこの話に戻り（コアをウェアハウスにしない）、第3部のリレーショナルを超えて *(coming soon)*で分析のための構造がどう作られるかを示します。

ストリーミング：動いているデータ。 イベント、テレメトリ、ステータス変更、センサーの読み取り値。Steve Truckingのトラックは1日に約20万件のGPSの読み取り値を送ってきます。配車担当者が気にするのは、トラック217が今どこにいるかです。Salesforceは、すべてのトラックの1分ごとの読み取り値をすべて保持する必要があるでしょうか？　おそらくありません。「今どこにいるか？」と「前の四半期のルート効率の傾向は？」は同じ源から来ていて、まったく違う保存の判断につながります。

どれくらい速く動く必要があるか？

次は遅延です。クラスではこう説明しています。リアルタイムとは、誰かが戻ってくるのをドアの前で待っていることです。送り出してそこに立っている。戻ってくるまで先に進めないからです。それが同期です。ニアリアルタイムとは、出ていくのを見送ってほかのことに取りかかることです。少しして戻ってきたら、それに対応する。それが非同期です。そしてバッチがあります。誰も一人ずつドアから出ていきません。データは待っていて、スケジュールに従ってまとめて動きます。1時間ごと、数時間ごと、あるいは1日1回。バッチで十分な場面はたくさんあり、そうでない場面もあります。どちらがどちらかを見極めるのが仕事です。この3つは単なる連携の用語ではなく、アーキテクチャ上の選択です。

よくあるERP連携を考えてみましょう。午前11時にERPで新しい製品が作られます。営業は本当に正午までにそれを売る必要があるでしょうか？　私はどちらの答えも見てきました。できるだけ早くほしいというクライアントもいれば、そのSKUをまだ出荷していないのだから、まだ売ってもらえるとは期待できない、と言うクライアントもいます。ですから製品はたいてい1日1回、ときにはそれより速く。顧客は最低でも1日1回。1時間ごとも見てきましたし、極端な場合はニアリアルタイムもあります。注文は違います。出荷を始めなければならないので、ニアリアルタイムです。営業担当者は商談を成立させて次に進み、注文は数秒から1、2分でERPに届きます。「企業データ」に唯一の正しい遅延はありません。ビジネスが実際に何を必要としているかを問い、聞こえがいいからといってすべてをリアルタイムにしないでください。リアルタイムにはコストがかかります。

分類の背後にある4つの問い

「これはトランザクションデータだ！」と宣言して回る必要はありません。分類は、重要なデータセットのすべてについて4つの問いを引き出すためにあります。

誰が所有しているか？ どのシステムが権威を持っているか？　私はこれを3つに分けます。どこで作成されるか、どこで編集されるか、どこで参照されるか？　第6章でこれらを深く掘り下げます（どこで作成され、編集され、参照され、どれくらい速く変わるのか？）。
どれくらい速く変わるか？ 年に1回、毎日、1秒に数十回から数百回？
どれくらい大きくなるか？ 10件、1万件、1,000万件、100億件？
ライフサイクルはどうなっているか？ 永遠に生きるのか、アーカイブされるのか、削除しなければならないのか、時間とともに価値を失うのか？

この4つは、「Salesforceはこれを保存できるか？」よりずっと多くのことを教えてくれます。そして、すでに学んだことをまとめてくれます。所有、ライフサイクル、ゼロの数、データの置き場所。

一つのビジネスがすべての種類を生み出す

Steve Truckingでは、小売パートナーはマスターデータ、ステータスの語彙は参照データ、一つひとつの配送はトランザクションデータ、その項目の定義はメタデータ、5年分の時間通りのスコアカードは分析データ、設置の写真は非構造化データ、そしてGPSのフィードはストリーミングです。どれも「Steve Truckingのデータ」です。だからといって、同じデータベースに属するわけではありません。それが転換です。

試験の先へ：AIが変えること。 一つの問いに答えるために、エージェントは構造化された顧客レコード、最近のトランザクション、PDFのマニュアル、サービスの文字起こし、そしてライブのテレメトリを必要とするかもしれません。非構造化データとストリーミングデータは、CRMのデータベースには属さないとしても、アーキテクチャの一級の部品になります。そしてアーキテクトはやはり、それぞれの源を誰が所有し、それがどれくらい新しく、エージェントがそれを信頼すべきかを知っていなければなりません。

ここでアーキテクトが決めること

重要なデータセットのそれぞれが、どんな種類のデータで、誰が所有しているか。
そのワークロードが業務か、分析か、ストリーミングか、その組み合わせか。
どれくらい速く変わるか、そしてほかのシステムが本当はどれくらい速くその変化を見る必要があるか。
ボリュームとライフサイクルが、それがどこにどれくらいの期間置かれるかをどう形づくるか。
Salesforceがそれを所有すべきか、コピーを持つべきか、参照すべきか、それともそのワークロードにもっと適した場所に置いておくべきか。

要件を渡されたら、どのオブジェクト、どの項目、どのAPIかに飛びつかないでください。まず、それがどんな種類のデータで、誰が所有し、どれくらい速く変わり、どれくらい大きくなり、どれくらい長く生き、それで何をしようとしているのかを問いましょう。取引先、配送のイベント、5年分の集計、そして写真は、同じアーキテクチャの問題ではなくても、すべて同じビジネスにとって重要であり得るのです。

さらに学ぶ

DAMA International、DAMA-DMBOK: Data Management Body of Knowledge、第2版（2017年）：データの分類とデータ管理についての標準的な参考文献（日本語版『データマネジメント知識体系ガイド』もあります）。
Steve Truckingの概要資料、セクション4（ボリューム）（英語）。