四十三庵

蔀の雑記帳

なぜ日本がデータ分析で成果を出せないかをシステムの観点から説明する

このブログの昔からの読者ならご存知だと思いますが、
大学時代わたくしは経済学部でデータ分析をやっておりました。
最近のトレンドはまったく追ってない*1ので、
今話題のデータサイエンティストが何やってるのかわからないんですが、
最小二乗法使って回帰分析して、この変数が有意水準何%でどんぐらい効いてるね、みたいなことをやっていました。

で、大学時代データ分析やる中でよく困ったのが、分析したいがデータが公開されてない、ということでした。

「◯◯を知りたいんで、☓☓みたいなデータ探してるんですけど、いいのないっすかね?」
と教授に言うと、
「あ、それはこれとこれがあるけど、どっちもサンプル数少なすぎて参考にならないね……」
「そっすか……」

https://blog.stm43.com/entry/20140727/1406451084

特に民間企業のデータ開示は異常に対応してくれない。
個人情報ならともかく、見せて問題ないものなら、もっと見せてくれてもいいじゃないか、と思っていた。

その後就職してからは業務系システムのSEやってるんですが、
その中で、「ああ、これは確かに開示できないわな」と思うようになったので、
データ開示に対する価値観ではなく、ITシステムの制約の面から説明してみようと思います。

対象読者ですが、データ分析もシステムも前提知識がなくても読めるレベルで書くつもりなので、特にしぼるつもりはないです。

国家や企業の持っているデータは扱いづらい形式になっている

agora-web.jp
ちょっと前に話題になりましたが、勤労統計が間違っていた原因が、
雇用統計担当係の中でも1人か2人しか読めない、COBOLという言語で書かれていたプログラムだったため、
という厚生労働省の報告書がありました。

このニュース自体は単純におそまつですが、ただこの一件からもわかるとおり、
国家や企業の基幹系システムというのは、ボタンをポチポチすると、
必要なデータをきれいに一覧で出してくれる……みたいにはなっていません。
特に厚生労働省みたいなメインフレームを使ってる基幹系システムになると、かなりしんどいです。
このしんどさについて、もうちょっと説明してみようと思います。

基幹系システムは別に時系列にデータを持ちたいわけではない

データ分析したい人にとって、必要なのは、時系列データとかが多いと思います。
ところが、システム側では、時系列でデータを持っていない場合が多いです。
最新情報だけを持っており、日次でバックアップをとっているので、
そのバックアップデータを整形して、時系列データにする、というのは可能です。
可能ですが、多くのシステムは、統計をとるのを目的としていないので、結構しんどい作業になります。

更に昔のデータが欲しい、となると、経費削減のためにテープでバックアップしてあったりします。
テープとかになってくるともう絶望ですね。
僕は官公庁システムは触ったことはないですが、管理台帳はあるが、
現実的には扱いようもない、テープに入った過去データがたくさん死蔵されてる場所があるんじゃないかと想像しています。
記録媒体の進歩にあわせて、そういうバックアップを簡単に扱えるような移管作業をしていればよいのでしょうが、
政府は研究機関ではないので、何か強い理由がなければやらないでしょう。

もちろん会社の中でも、データの推移とかを見たい場合があるので、
最低限の統計処理は内部でしていると思うので、それが上手いことデータ分析者の目的と合えばいいですが、
大抵の場合はデータ分析者の要求している形式ではないと思います。

ファイルやDBから必要なデータをどう抜き出すか

システムの中では、データはファイルやDB(データベース)の中に格納されています。
Excelファイルをダウンロードする、みたいな感じでできたらいいのですが、実際はもっとカオス状態になっています。
DBというのは、サーバ上でデータを蓄積するための仕組みです。
ファイルが普通にストレージ上に保存しただけのデータなのに対して、DBはデータを整理して、格納します。
そのDBを管理しているシステム(DBMSと呼ばれます)がいて、
そいつに対して、データの格納や取り出しを依頼することで、データの一元管理を実現します。

ファイルは部屋の中に本が置かれてるだけの状態なのに対して、
DBはきちんと本棚に並んで管理されていて、司書さんに頼むと色々してくれるイメージですね。
本の数とか客の数とかが増えてくると、司書さんの仕事が回らなくなってくるので、
システムのパフォーマンスのためによく使うデータは一時的にファイルにして、そこを見に行く、みたいなこともやります。

で、ここからはシステムの設計次第ではあるんですが、
このファイルやDBは基本的にはデータ分析しやすい構成になっていることはないと思います。
なぜかというと、基本的にはシステムのパフォーマンスとか、プログラムが処理しやすい形にするだとか、
システムの観点からデータの置き方を考えます。
なので、たとえば「全国で展開しているスーパーの顧客の購買履歴データを分析したい」と思っても、
顧客情報DBと購買履歴DBはおそらく別々にある構成になっています。
だから、購買履歴DBだけを見ても「Aというお客さんが何時何分に◯◯を買った」というデータがわかるだけで、
「Aさんの性別、年齢、職業」などは顧客情報DBを見ないとわかりません。
こういう場合、二つのDBから必要な情報を結合して、出力するということができます。
「Aさん」という情報をキーにして、顧客情報DB+購買履歴DBをつくるイメージです。
ただこれをやるためには、ちょっとしたプログラミングをしないといけません。
データのありかがメインフレームじゃなければCOBOLじゃなくて、
もうちょっと楽なスクリプト言語(pythonとか)でイケるでしょうが、しんどいことには変わりありません。
メインフレームが入っていたら、COBOL書く必要がありますね。辛いですね。
そしてデータ自体が巨大だと、そのデータを整形する処理も数時間バッチ回さないといけなかったりします。
数時間ですめばまだいいですが、ヘタすると何日回しても終わらず、
途中で何か不正データなりを引いて、バッチがコケるとか、そういう展開もありえます。
そうなると、辛いとかじゃなく、インプットのデータが作れない、となってしまうので、厳しいです。

データ分析は正直分析可能なデータ形式まで落としたら、
あとは統計ソフトなり何なりに突っ込むだけなので、下ごしらえが一番大変というのはあるんですが、
基幹系システムのデータだとその下ごしらえで多大な時間と労力を要する気がします。

個人情報の扱いだとか、機密情報へのアクセス権だとか、
その手の権限の問題もあると思いますが、この手のシステムの制約のほうが、
ビッグデータだなんだとバズワードになっている中で、あまり顕著な成果が出ているように見えない要因なのではないかと思っています。

インプットがゴミだとアウトプットはゴミしかでない

どこかでデータサイエンティストの人が書いていました。
インプットがゴミだとアウトプットはゴミしかでない、と。

これは的を射た言葉だなと思っています。
と同時に、データ分析の限界を示す言葉でもあると思っています。
インプットがなければ、データ分析はそもそも不可能。

だからホントの意味でデータドリブンにビジネスを回したいんであれば、
インプット、つまり企業内の統計データ管理体制を設計する段階から、
データサイエンティストみたいな人をおいて、体制を構築しないと厳しいと思っています。

データ分析フレンドリーなシステムって作れるのか?

ここまで書いて思ったんですが、データ分析がしやすいシステム、データ分析フレンドリーなシステムってなんだろう?
recruit-tech.co.jp
テキトーにググってみたら、まあやっぱ案の定データサイエンティストの人も悩んでるみたいです。
大抵の環境で、そんなシステムはないので、データ基盤をつくるところからのスタートになるんでしょうか。
(了)

*1:思うところがあり