データコンサルYブログ：（第４回）「その情報、本当に必要ですか？」～データマネジメントのすべては分からないが基本的なことはよく分かるブログ

2020-10-23

このブログは、人当たりの良さとマニアックな知識で、世間の荒波を漂流しリアライズに流れ着いた「流浪のデータコンサルY」が、データマネジメントについて控えめに語るブログです。仕事の合間の息抜きにご利用ください。

前回の振り返り

●データは、それ単体では意味をなさない。

●データをつなぎ人間が意味を理解できてはじめて利活用できるようになる。

●“データを利活用するための管理単位”はDIKWモデルでいうところの“情報”。

はじめに

前回のブログで「なるべく早く続きを書きます」としておきながら、忙しさにかまけて執筆がおろそかになっておりました。言い訳ではないんですよ、本当に忙しかったんですよ・・・と言えば言うほど、言い訳っぽくなるのでこの辺にしておきましょう ^^;

前回は“データをつないで情報にしないと人間にとって意味をなさない”ことを説明しました。この“情報”こそがデータマネジメントにとって最も重要な管理単位になるのですが、さてここで問題です。“情報”を管理する上で大切なことは何でしょうか？

答えは1つではありません。例えば、管理する体制であったり、ルールやプロセスであったり、テクノロジーであったりします。ただ、今回は他のところに焦点を当てます。それは何かというと・・・第１回、第２回、第３回のブログの流れから、すでに予想がついた方もいるのではないでしょうか。そうです、早くもアイツが再び現れます。

その買い物、どんな買い物なの？

前回の内容を引き継いで話を進めていきますので、お読みになっていない方は、ぜひ先に前回のブログをお読みください。

“商品価格(税抜)”というデータ1つでは言葉足らずでしたが、以下のように“購入者”や“購入日”といった複数のデータとつながり一定の文脈を成したことで、「買い物」という1回の出来事を表す情報になりました。

キャプチャ4-1.PNG ところで、この買い物って一体どんな買い物なのでしょう・・・見た目そのままでいくと「妻がABCスーパーでX牛乳を買う買い物」ですよね。ただ、それだと非常に限定的じゃないですか？普通スーパーで買い物と言えば、他の商品も買いますよね。だから、こんな会話が続いたとしても不思議じゃないと思います。

キャプチャ4-2.PNG この会話を情報として表現すると以下のようになります。

キャプチャ4-3.PNG

これにより、「妻がABCスーパーでX牛乳を買う買い物」から「妻のABCスーパーでの買い物」に内容が変化しました。そして、この会話にはさらに続きがあったのです。

キャプチャ4-4.PNG

この会話を追加して表現すると以下のようになります。

キャプチャ4-5.PNG

これにより、「妻のABCスーパーでの買い物」から「妻の買い物」に内容が変化しました。そして、なんと！最後にこの会話は別の展開をみせたのです。

キャプチャ4-6.PNG この会話を追加して表現すると以下のようになります。

キャプチャ4-7.PNG

これにより、「妻の買い物」から「買い物」に内容が変化しました。

※厳密には「家族の買い物」ですが、ここでは「買い物」とします。

必要な情報、不要な情報

ここまでで夫には、購入者が異なったり、購入場所や購入商品が異なったりする「買い物」の情報が蓄積されていると考えられます。さて、本当にこの夫には全ての情報が蓄積されているのでしょうか？ここからは夫をキャラ分けして考えてみます。

(1)家族思いの夫の場合

この夫は、“妻や子供を喜ばせる”ことを大切にするでしょう。特売に喜ぶ妻に共感するために、あるいは子供のお手伝いを褒めるために、活用できる情報は全て必要と考えるはずです。よって全ての情報を蓄積しているでしょう。

(2)妻への愛が薄れ、子供だけが生きがいの夫の場合

この夫は、“子供を喜ばせる”ことが何より大切でしょうから、子供の買い物の情報さえあれば良いと考えているかもしれません。よって、“購入者”が子供である情報だけを蓄積している可能性が高いでしょう。

(3)ABCスーパーをライバル視し、XYZマートは眼中にない“いろはストア”の店長が夫の場合

この夫が家族をどう思っているかはさておき、ABCスーパーでの買い物情報は必要とするはずです。逆にXYZマートでの買い物情報は一切不要と思っているでしょう。よって、“購入場所”がABCスーパーである情報を重宝し蓄積していると考えられます。

(4)人類がどうなろうと自分だけは火星に移住したい夫の場合

この夫は、きっと地球上の誰かの「買い物」に関する情報になど一切興味がないでしょう。よって買い物情報は何も蓄積されていないはずです。

必要な情報は主体によって異なる

実在して欲しくない例も含め4つのキャラ設定で考えてみましたが、共通することは「不要な情報は蓄積しないだろう」ということです。妻や子供が買い物をしたという事実は確実に存在するものの、そのうちのどの情報を受け取るか否かは受け手によって異なるのです。

別の例を挙げてみます。「買い物」といっても、先程の例なら夫には自分の家族の買い物ですが、もしABCスーパーの店長だったらどうでしょう。当然、他の家庭の買い物が含まれます。この場合、夫は「買い物」という言葉から、無意識に自分の家族の情報だけを選別しているとも言えます。

キャプチャ4-8.PNG

管理することは、必要な“情報”のメタデータを定義すること

要するに、“情報”を管理する上で大切なことは「管理主体にとって必要な情報とは何か」を明確にすることなんです。明確にするには、必要な情報のかたまりに最適な名前をつけ、具体的に説明をすることです。説明の仕方に決まりはありませんが、例えば『○○であるもの/こと』とか、『○○のみ含める』と書くといい感じです。『○○は含むけど、××は含まない』のように、可能な範囲で不要なものを明示するとより具体的になってベターです。

ここまで読むと、さすがに今回の焦点の当てどころが分かったでしょうか。そうです！メタデータです。第２回で「データを説明するデータ」として紹介しましたが、今回は“情報”を説明するデータとして再登場です。さっそく先程の「夫視点での買い物」を例に書いてみます。

キャプチャ4-9.PNG 一方で「店長視点での買い物」だとこんな感じになりそうです。「買い物」は買う側の視点に立った言葉なので、店長の場合は売る側に立った言葉の方が適切です。そして来店したお客様への販売であることが名前からもわかるように「POS販売」としてみました。

キャプチャ4-10.PNG このように、必要な情報のかたまりに対してメタデータを正しく定義することは、データマネジメントの中でも特に重要です。ちなみに、データマネジメントの世界では、この“情報のかたまり”のことを『エンティティ』と呼ぶことが一般的です。次回以降のブログで繰り返し登場する用語なので、この機会にぜひとも覚えてください！

エンティティのメタデータ管理を怠ると、「デジタルトランスフォーメーションのために必要なデータを貯めておけ！」と号令がかかった結果、メタデータが異なる“情報”を同じテーブルに保存してしまったり、本来不要な“情報”を蓄積してしまったりしてデータスワンプが爆誕！なんて笑えない事が起きてしまうかもしれません。メタデータをしっかり定義し管理することを心がけましょう。

おわりに

当ブログでは、第１回から今回まで、DIKWモデルでいうところの“データ”と“情報”を意識して言葉を使い分けてきました。ただ、実際のところ、皆さんは業務に携わりながらそのような言葉の使い分けを意識していますか？ほとんどの場合は意識せず、例えば「注文データ」や「在庫データ」のように、“データ”という用語が“情報”もしくは“エンティティ”を包含しているように思います。ですので、今回までの言葉の使い分けは、その概念を理解するためのものとして割り切ってもらって構いません。