大学時代わたくしは経済学部でデータ分析をやっておりました。最小二乗法使って回帰分析して、この変数が有意水準何%でどんぐらい効いてるね、みたいなことをやっていました。大学時代データ分析やる中でよく困ったのが、分析したいがデータが公開されてない、ということでした。「そっすか......」https://blog.stm43.com/entry/20140727/1406451084特に民間企業のデータ開示は異常に対応してくれない。個人情報ならともかく、見せて問題ないものなら、もっと見せてくれてもいいじゃないか、と思っていた。その後就職してからは業務系システムのSEやってるんですが、その中で、「ああ、これは確かに開示できないわな」と思うようになったので、データ開示に対する価値観ではなく、ITシステムの制約の面から説明してみようと思います。対象読者ですが、データ分析もシステムも前提知識がなくても読めるレベルで書くつもりなので、特にしぼるつもりはないです。雇用統計担当係の中でも1人か2人しか読めない、COBOLという言語で書かれていたプログラムだったため、という厚生労働省の報告書がありました。必要なデータをきれいに一覧で出してくれる......みたいにはなっていません。厚生労働省みたいなメインフレームを使ってる基幹系システムになると、かなりしんどいです。このしんどさについて、もうちょっと説明してみようと思います。基幹系システムは別に時系列にデータを持ちたいわけではないデータ分析したい人にとって、必要なのは、時系列データとかが多いと思います。ところが、システム側では、時系列でデータを持っていない場合が多いです。最新情報だけを持っており、日次でバックアップをとっているので、そのバックアップデータを整形して、時系列データにする、というのは可能です。可能ですが、多くのシステムは、統計をとるのを目的としていないので、結構しんどい作業になります。昔のデータが欲しい、となると、経費削減のためにテープでバックアップしてあったりします。テープとかになってくるともう絶望ですね。現実的には扱いようもない、テープに入った過去データがたくさん死蔵されてる場所があるんじゃないかと想像しています。政府は研究機関ではないので、何か強い理由がなければやらないでしょう。場合はデータ分析者の要求している形式ではないと思います。ファイルやDBから必要なデータをどう抜き出すかシステムの中では、データはファイルやDB(データベース)の中に格納されています。Excelファイルをダウンロードする、みたいな感じでできたらいいのですが、実際はもっとカオス状態になっています。DBというのは、サーバ上でデータを蓄積するための仕組みです。ファイルが普通にストレージ上に保存しただけのデータなのに対して、DBはデータを整理して、格納します。そのDBを管理しているシステム(DBMSと呼ばれます)がいて、そいつに対して、データの格納や取り出しを依頼することで、データの一元管理を実現します。ファイルは部屋の中に本が置かれてるだけの状態なのに対して、DBはきちんと本棚に並んで管理されていて、司書さんに頼むと色々してくれるイメージですね。本の数とか客の数とかが増えてくると、司書さんの仕事が回らなくなってくるので、システムのパフォーマンスのためによく使うデータは一時的にファイルにして、そこを見に行く、みたいなこともやります。ここからはシステムの設計次第ではあるんですが、このファイルやDBは基本的にはデータ分析しやすい構成になっていることはないと思います。いうと、基本的にはシステムのパフォーマンスとか、プログラムが処理しやすい形にするだとか、システムの観点からデータの置き方を考えます。顧客情報DBと購買履歴DBはおそらく別々にある構成になっています。顧客情報DBを見ないとわかりません。いう場合、二つのDBから必要な情報を結合して、出力するということができます。「Aさん」という情報をキーにして、顧客情報DB+購買履歴DBをつくるイメージです。これをやるためには、ちょっとしたプログラミングをしないといけません。データのありかがメインフレームじゃなければCOBOLじゃなくて、もうちょっと楽なスクリプト言語(pythonとか)でイケるでしょうが、しんどいことには変わりありません。メインフレームが入っていたら、COBOL書く必要がありますね。データ自体が巨大だと、そのデータを整形する処理も数時間バッチ回さないといけなかったりします。途中で何か不正データなりを引いて、バッチがコケるとか、そういう展開もありえます。なると、辛いとかじゃなく、インプットのデータが作れない、となってしまうので、厳しいです。基幹系システムのデータだとその下ごしらえで多大な時間と労力を要する気がします。個人情報の扱いだとか、機密情報へのアクセス権だとか、その手の権限の問題もあると思いますが、この手のシステムの制約のほうが、ビッグデータだなんだとバズワードになっている中で、あまり顕著な成果が出ているように見えない要因なのではないかと思っています。インプットがゴミだとアウトプットはゴミしかでないどこかでデータサイエンティストの人が書いていました。インプットがゴミだとアウトプットはゴミしかでない、と。これは的を射た言葉だなと思っています。同時に、データ分析の限界を示す言葉でもあると思っています。インプットがなければ、データ分析はそもそも不可能。ホントの意味でデータドリブンにビジネスを回したいんであれば、インプット、つまり企業内の統計データ管理体制を設計する段階から、データサイエンティストみたいな人をおいて、体制を構築しないと厳しいと思っています。データ分析フレンドリーなシステムって作れるのか?ここまで書いて思ったんですが、データ分析がしやすいシステム、データ分析フレンドリーなシステムってなんだろう?recruit-tech.co.jpテキトーにググってみたら、まあやっぱ案の定データサイエンティストの人も悩んでるみたいです。環境で、そんなシステムはないので、データ基盤をつくるところからのスタートになるんでしょうか。(19)Searchはてなブログをはじめよう!st43さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。