データ分析・活用現場のボトルネック③「SQL」
―― 以前、西内さんにうかがって興味深く感じたことに、分析のツール化があります。業務ごとに分析のベストプラクティスが定まり、いずれツール化される。しかし、そうしたツールに入力できるようにデータを加工する「ETL（Extract/Trasform/Load）」だけは、今後も人力による作業になるだろうと。それは企業や部署ごとにデータの構造や形式が異なるため、一様にツール化できないというのが理由でした。そうしたところでSQLも出てくるわけですが、SQLのニーズはどのくらいあるものですか？
西内 ► ETLは、データ分析の中で人が行う作業において、一番のボトルネックになっているかもしれないと思っています。データ分析を仕事とする、いわゆるデータサイエンティストと呼ばれる人たちにはいろんなタイプがいるんですが、多いのが修士・博士課程で機械学習の研究をしていて、そのときにR言語やJavaなどの手続き型言語を一通りやってきた、というタイプです。その彼らがあまり得意じゃないことがあるんですよ。
―― 得意ではないこととは？
西内 ► SQLを使ったデータの抜き出しと加工ですね。これが苦手だとどういうことになるかというと、自分は「一休さん」みたいだと表現する状況に陥るんです。将軍様から「屏風に描かれたトラが夜中に出てくるから、それを縄で捕まえよ」と命じられた一休さんが、「捕まえますから、トラを屏風から追い出してください」と切り返すという話があるんですが、同様に「それでは解析しますからこの形でデータを持ってきてください」というんですよ。
データを管理されている情シス部門の方々は、「いやいや、それが君の仕事でしょ」と思うのですが、大学の研究では分析用のデータがキレイな形で揃っているのが前提なんです。例えば、ダミーのデータを全部乱数を使って発生させたり、加工済みのデータを教授や先輩、共同研究者からもらったりするんです。ですが、いざ社会に出て実際に分析する場面になると、そういうデータを作ってくれる人はもちろんいません。そこで情シスの人に「すみません、こういうデータを作ってください」と頭を下げるわけですが、情シスの人も忙しいですから、事前に聞いていない作業を急にはやってくれない。
―― ええ。
西内 ► こうした場合、例えば顧客に関する分析をしようとすると、RDBで別々のテーブルとして管理されているものを非正規化し、顧客に関連するすべての属性を1つの顧客レコードに紐付けて集計する、といった作業が必要になります。
ですが、そもそもこういう作業って情シスの人も普段あまりやらなかったりするんですよ。こうしたデータをつくるときには、CASE式をかなり使うSQLを書くことになるんですけれども、情シスの古株の方ってCASE式に慣れていない人が多い。こうした分析のためのSQLをわかっている人がいないと「こういうデータをください」といっても「いや、できません」となって、プロジェクトが停滞することがよくある気がします。
