先月くらいから、ちょいちょいとデータを扱う業務を担当するようになった。今までの職でも、なんにかんやデータを漁ったりする人だったので、いや、そんなことをやってたのかと言われるとあんまりやってなかった気もするけど、そんでもいつの間にやらマーケティングっぽいですねと言われたりもしていたので、まぁ、なんというか、やっとこさ本丸に取りかかったという気がしなくもない。
ただ、今回はそれほど自由な環境じゃない。前の職場だと、自分のＰＣにMySQLとAnaconda入れて、Jupyterで処理するなんてこともできたのだが、今はセキュリティの壁に阻まれている。かなりセンシティブな個人情報を含むから、社内のネットワークから取り出せないのである。それを考えると、前の職場のセキュリティがゆるかった、と、言えなくもない。
そんな事情もあって、使える環境は限られる。最初はメイン武器にExcelを据えていたけれど、早々に諦めた。テーブルの結合が多過ぎる。Access使うしかない。ほとんど使ったことなかったAccessと悪戦苦闘して、１ヶ月ぐらいでちょっとはAccessのSQLのクセとかがわかってきた。結合を繰り返すので、レコード数に気をつけていないといけない。それで意図しないダブルカウントが発生してしまったりするので、勘弁してくれいと言いたくなることもある。
いや、これはAccessばかりのせいではない。そもそもデータベースの構造が、２次利用に向いていないのだろう。
●◯。。。...
あんまり詳しいことを書く力量がないが、要は、うちのシステムは本部と支部にわかれているのである。統合的に情報を管理する本部システムが幹としてあり、枝葉にそれぞれの分野にあわせた専門的な動きをする支部システムがつながっている。本部、各支部、各々が別のメーカーの製品であるため、データの規格が統一されているわけではない。本部と支部のデータの受け渡しは、その組み合わせごとにつくられている感じだろう。ある意味で、場当たり的に、必要に応じて、構築時にできる範囲で、データがやり取りされている。
楽天市場で言ってみると、専門店が楽天ドメイン外に出ていってしまってるような状態だろうか。楽天から入って、専門店はそれぞれ別のWebサイトに出ていって、決済で楽天に戻ってくるみたいなイメージなら、近いかもしれない。
支部システムの専門性が高過ぎるのもあってか、本部システムを中心としたガチャガチャ組み合わせシステム体になっている。それは仕方がないかもしれないが、顧客はあっちのシステムに行って、こっちのシステムに来て、システム渡り歩きをするから、当然のごとく、データもガッチャガチャになる。
そんなら串刺しするＩＤを振ったらいいじゃないか、と言われるだろう。ぼくもそう思う。それがないから困る。ユーザーＩＤはあるけど、セッションＩＤがない。故に、ユーザーＩＤをもとにした結合をするけれども、あとはどう捌くか、解析屋の考え方次第となる。ユーザーＡの行動１と行動２が同じ日付であっても、それが本当に１本の筋の上に並ぶ連続した行動なのかどうかは霧の中なのだ。
こういう事情は、意外とよく知られていない。データ屋さん以外は、当然のごとく結びついているものと認識してたりする。世の中そんなに甘くない。セッションＩＤを振っていたとしても、どこかで切れちゃうなんてことは、よくある。本当によくある。
●◯。。。...
データは掘り返さないと使えない。どういう活用につながるかわかっていることはほとんどない。だから、資産価値としては未知である。未知の利用を見越して、システムを組むなんてことは、原理的には不可能である。当てずっぽうに手を伸ばして、ごそっとデータを取っておこうとするのは、お金がかかり過ぎる話でもある。２次利用を想定してつくられたシステムは稀なのだ。
ならば、ざっくりのデータを何となく取り出して、細かい部分はさておきどっちの方向を向いているかぐらいがわかるものとして、データを捉えてみてはどうだろうかと思ったりもする。金勘定は１円まであわなきゃならんかもしれぬけれども、マーケティングデータにピッタリ数値がそこまで必要かと言われると、そうではないのだ。と、いう、開き直りもあっていい。
データというと、とかく正確性を求められてしまうので、データ側の事情もわかっておいてほしいもんだと、少し思う。
m(_ _)m
