四十三庵

蔀の雑記帳

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

このブログの昔からの読者ならご存知だと思いますが、
大学時代わたくしは経済学部でデータ分析をやっておりました。
最近のトレンドはまったく追ってない*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:思うところがあり

わかりやすい説明をするテクニック

仕事柄、小難しいことを噛み砕いて説明する機会が多い。
僕は10年くらいこのブログを書いてきて、その中で体得した方法論が、結構仕事でそのまま使えることがある。
そういう経験知を、このたび文章化してみようと思う。

(目次)

最悪の方法

一番わかりづらい説明にするには、思いついたまま喋ることだ。
大学教授とか、講義の準備一切せずに思いついたままに喋ってる人がちょいちょいいましたが、大抵わかりづらい説明になっていた。
ただアドリブで喋ってもある程度形になるトーク力を持ってる人も、
世の中一定数いるので、訓練すれば思いついたまま喋っても、最低限の形にすることはできる。

ただ内容が高度になってくればくるほど、それだと辛くなる。

多分一番大事なこと

わかりやすい説明する上で、たぶん一番大事なのは、構造化することだと思う。

人間は新しい情報をインプットする際、受け取った言葉を、
1から順番に処理しているわけではなく、ある程度自分の中で構成して処理していく、と思う。
一時間の授業の中で、「あ、ここは雑談パートなんだな」とか、「ここは試験にでるから必ず覚えないといけないんだな」とか、
優先順位をつけて、勝手に序論→本論→(話題転換)→本論……みたいにして、メリハリをつけて処理する。
意識的であるか、無意識であるかは別にして、どんな人でもやっている。
人間の記憶力はそんなによくないので、取捨選択しないといけないため、こういう風に処理してるのだと思われる。

日常の雑談の中でも、相手がどうでもいい、忘れてもいいような話をしているときと、
すごく大事な話をしているときとで、反応をわけていると思う。
これもまた無意識の構造化の例だ。

わかりやすい説明をする際は、意識的に構造を組み立てて、相手に提供することだ。
そうすることで、相手の理解と、自分の説明したいことを限りなく近くすることができる。
(完全に一緒にはならないだろうけども)

構成について

以下、構成について書く。
具体例を書いてもいいけど、割と常識的なことだと思うので、
「こういう構成にするといいよ」とだけ簡潔に書く。

起承転結をつくる

説明の流れがあるとわかりやすい。

前提から本論へ

前提があるのなら、最初に話した方がわかりやすい。

具体から抽象へ

抽象論をするときは、具体的な例から話すとよい。

抽象から具体へ

ただ扱う内容や相手によっては、順序が逆の方がいいときもある。
相手が学者や専門家であるならば、こっちの方が話が早いかもしれない。

全体から部分へ

最初に全体像を示してから、各論を掘り下げていく方がわかりやすい。
×「これから全社PCのWindows10アップデート対応について説明します。
 現在我が社ではWindows7がメインで〜〜(云々かんぬん)
 マイクロソフトのサポートは〜〜(云々かんぬん)
 競合他社の対応状況は〜〜(云々かんぬん)
 したがって我が社の対応スケジュールは〜〜(云々かんぬん)」
最初で一応自分が何を話すかは最低限説明しているが、できればもう少し説明した方がいい。

◯「これから全社PCのWindows10アップデート対応について説明します。
  まず我が社の現在の状況をご説明します。
  その次に対応スケジュールのご説明ですが、その前にマイクロソフトのサポート期限と競合他社の対応状況をご説明し、
  その後にスケジュールについて説明致します。
  現在我が社ではWindows7がメインで〜〜(云々かんぬん)(以下同)」

難易度を下げる試み

何かを説明されてわからないのは、結局説明内容が難しいという場合が多い。
まあでもなにか説明して誰でもパッっと理解できることなら、その説明してお金もらえるということもないだろう。

難易度を下げるための方法論を列挙してみる。

割愛する

説明しなくてもいいことは、できるだけ割愛するほうがいい。
学校の授業であれば、脱線して勉強になることをやってもいいけれど、
特に仕事のプレゼンなりなんなりであれば、その場で理解する必要がない事項について補足説明を入れるくらいなら、
多少関連性があっても思い切って割愛したほうが良い。
ただその知識がないと、本質が説明できない、というときは、多少難しくても割愛しないほうがよい。

専門用語を省く

相手が専門知識を持っていない可能性があるなら、専門用語は極力使わない方が良い。
「このぐらいの用語は知ってるだろ。むしろ知ってろ」みたいな気持ちになるときもあるかもしれないが、
専門用語が理解の妨げになることは結構多いので、注意したほうがいい。
経験的に、知らない専門用語が一文に三つ以上でてきたときにその文章が理解できる確率はほぼゼロだ。
二つでもだいぶキツい。

例え話をする

適切なたとえは理解を助けるので、入れるとよい。

たとえば下のサイトのたとえなんてよいですね。
保険加入者がりんご、保険未加入者をバナナにたとえているので、頭の悪い僕でもスッと入ってきます。
hokensc.jp

……ということで、たとえ話は結構センスが問われる。
本質をとらえてるか、芯食ったたとえになってるかは、誰かに確認した方がいい。

よくオブジェクト指向の説明のときに、
「オブジェクトとは、モノやコトです。
 たとえばAnimalというクラスがあって、このクラスを継承してDogやCatのインスタンスをつくって、
 鳴き声をワンとニャーにしますね? これがポリモーフィズムです。
 ポリモーフィズムとは多態性です。わかりますね?」
みたいな説明はよくされるけど、これもよくないと思っている。
「え? じゃあオブジェクト指向で書くときは全要素のクラスつくるの?
森羅万象すべてをクラスで表現しないといけないの?」
みたいな気持ちになる。

ただ本質を理解させるのを諦めて、
もうわかったような気持ちになってもらわなければならない状況というのも世の中にはままあるので、
そういうときにもたとえ話は有効だ。
年配の人と話すと、クラウドをホントに雲の中に何かがあると思っていたり、
コンピュータウィルスとワクチンが医療のウィルスとワクチンのイメージでとらえてたりする。
パソコンすら触ったことないし、これから触ることもない人に、コンピュータウィルスを理解させるのは多分不可能なので、
別にパソコンも人間みたいにウィルスに感染するので、そのときは注射しないと動けなくなるとかいうイメージでとらえておいてくれてもよい。

ポンチ絵を描く

ポンチ絵、という言葉がどこまで通じるかわからないけど、要は概要図・概念図のこと。
官公庁とかでよく使われる、らしい。
長々と文章で説明しても、お偉いさんは読んでくれないので、
そういうときに「このペーパーだけだと説明しづらいんで、大臣にご説明するために、ポンチ絵一枚お願いしますわ」みたいな。

これもたとえ話と同じで、適切なポンチ絵は理解を助けるが、
結局モノによっては本質をブレさせたり、誤解を与えたりするので、使い方には要注意である。

メリットを語る

具体例・応用例を話す

対学者に話すときはずっと抽象論で何時間も話せたりするけども、
学生とかビジネスマンとかは、別に理論を知りたいのではなく、
その理論を覚えると何の役に立つのか*1をまず知って、
役に立つのであれば頑張って覚える、というモチベーションになる。
知的欲求から、その分野の知識なら何でも知りたい! みたいな学者タイプとはちょっと相容れない。
学者タイプと言っても、アメリカの大学レベルの教科書とか読むと、
「この学問は何の役に立っているのか」という話がだいたい第一章に来ているように思う。
イマドキは学者であっても、「で、そのご高説は何の役に立つんですか?」という質問の回答は用意しておくべきだ。

いずれにせよ、抽象的な概念を説明するのであれば、具体例・応用例は必ずセットになっているべきだと僕は思っている。
そしてできるなら、具体例に入る前に、メリットを語れると尚よい。
たとえば、

・オブジェクト指向という概念を説明しました、それは何の役に立つんですか? それは具体的にどうやって使うんですか?
 ⇒たとえば
  設計がわかりやすくなります
  コードの再利用性が高まります
  Javaで書くのであれば、こういう感じです。
  (以下略)

・哲学って何の役に立つんですか?
 ⇒その問い答えるためには、役に立つとは何なのかを考えなければなるまい。
  役に立つ、という日本語は、ドイツ語にするとNützlichである。
  哲学がNützlichであるか判断するには、カントの「純粋理性批判」まで遡る必要がある。
  なぜならばNützlichを判断する基準は、紛れもなく純粋理性に他ならないからである。
  (以下略)

どうでもいいですけど、人文系の学者の人って突然日本語を外国語に訳して、
この単語はその国では◯◯という風に扱われている……つまり、これは◯◯ということなのかもしれない、みたいな論法使う人多くないですか?

完全な印象論だけど、文系寄りだとまず先にメリットを説明して、理系寄りだと具体例を説明して、
腹落ちしてからメリットを説明する、という順番の方が、いいような気がする。
文系/理系で二分する考え自体あんま好きじゃないけども。

それがなかったらを話す

正面からメリットを話しても相手がなかなか腹落ちしてくれなかったら、
「それがなかったら何が困るか」で話すとわかりやすいときがあります。
数学の背理法みたいな感じですね。

・オブジェクト指向の説明はわかりましたが、メリットがイマイチ納得できません……
 ⇒じゃあ、オブジェクト指向を使わない場合を考えよう。
  手続き型の設計になるわけだけど、
  それだと似たような関数があっても、ちょっと引数や戻り値が違うだけで別の関数として書かないといけないよね?
  オブジェクト指向を使えば、オーバーロードを使うと引数・戻り値が変えられるので、
  似たような関数がソースのあちこちに散らばることは避けられるね?
  これで将来の変更に強い、保守性の高いソースコードが書ける! うれしい!

・哲学のメリットがイマイチ納得できません……
 ⇒じゃあ、哲学がなくなった世界を考えよう。
  哲学というのは、人の思考そのものだ。
  哲学がなくなるということは、人が存在しないということだ。
  つまり人間が存在する限り、哲学は存在する。
  わかるね?

一旦ここまで

今思いつくことはこんなところです。
将来なにか「これも大事だな」と思ったら追加していきます。
(了)

*1:ITエンジニアはよく「何が嬉しいか」って言いますね