オープンデータについて考えてみる、というよりも提言
久しぶりに書きます&与太話です。
公私問わず、普段からデータを取り扱う機会が多い僕ですが、一番時間を奪われている作業があります。
それは、データクレンジング。
(データ界隈の方々はたぶんものすごく頷いていると思います。たぶん。。。)
データクレンジングを行わなければいけない原因についてはここでは多くは語らないでおきます。
ただ、データ界隈の人材として一言物申したいのは、「データクレンジングが発生する要因の9割は、データを生み出す輩の設計漏れ、考慮漏れである」ということです。
ちゃんと設計したデータであれば、データクレンジングの工数が限りなく0となるので苦労はしません。
ただ、現実解として、理想的なデータはそう多くなく、多少なり苦労しています。
だからこそ、昨今データエンジニアやデータアーキテクトの需要が高いのです。
データアーキテクト(旧名: データ整備人(仮))についての解説はしんゆうさんのこちらのブログを参照していただければと。
きれいなデータとは?
Tableauを触れたことがある方なら絶対にその存在を知っているデータセット、Sample Superstore。
端的に言えば、架空の店舗のECデータデット、というものです。
これがまた美しく、完成されたデータセットでして、Tableauのスキル習得に汎用的に利用できます。
例えばこんな感じ。Tableau以外のBIツールでも簡単に可視化まで持って行けるほどのポテンシャルがあります。
とはいえ、我々が欲しいデータはサンプルデータではなく、社内データであったり、社外のオープンデータでありますので、Sample SuperstoreはBIの手習い用といった側面が強いです。
閑話休題: 日本のオープンデータは利用しづらい
いきなりタイトル回収になってしまっていますが、上記の通りです。
詳細に入る前に、言葉の定義をします。
前提: きれいなデータ
本noteでいうきれいなデータとは、以下を指すことにします。
RFCに準拠したCSV
欠損項目がない(カラムデータが全てNULLではない)
時系列データに抜け漏れや尺度の違いがない
データ齟齬がない
前提: きれいではないデータ
本noteで批判するデータの代表例を以下に示します。他にもたくさんありますが主旨ではないので多くは語らないことにします。
ネ申Excel
クロス表(Excelの用語でいう、ピボットテーブル)
PDFのように簡単にデータが取り出せない媒体
RFCに準拠しない、Excelで閲覧前提のCSV
事例1: e-Stat
まず、政府のデータが揃うe-Stat。
結論から述べると、e-Statは残念ながらきれいなデータの定義から逸脱しているポータルサイトです。
収録データを眺めていると、活用アイデアやビジネスに転用したい欲はとてもあるのですが、いかんせんそのままでは使えない。データクレンジング必須。
データクレンジングすれば使えなくはないのですが、データクレンジング自体の工数も一般的なデータフォーマットから逸脱している分、特大工数を被る羽目になるため、二の轍を踏んでいる状況です(あくまで個人の感想ですが)。
ちなみに、e-Statのファイル(ExcelやCSV)とDBについては以上のファクト通りですが、APIはそこまで苦労はしません。
とはいえ、「APIを利用する」ということはBIツールではデータを利用することもできないため、必然的にデータパイプラインを考えなければならず、データアナリストが気軽にデータを可視化するハードルは上がります。
事例2: 郵便局
次に、郵便局の住所データ。
データ自体に不満はないのですが、都道府県毎にダウンロードリンクがあるので、全国データを取るのに47クリックするのか。。。47CSVか。。。と。
肝心の全国一括データについてですが、
とあります。
まさか、令和の時代の一般的な表計算ソフトってExcel 2003ではないですよね。。。
(Excel 2003 でサポートされる行数は、ワークシートあたり最大 65536 行です。)
せめて最新バージョンの仕様を踏まえたうえでの注釈をしてほしいなと思ったり。
事例3: 東京都オープンデータ
最後に、こちらは最近使おうとして断念したオープンデータ。
東京都オープンデータカタログサイトより、公衆無線LANアクセスポイント一覧を紹介します。
(コメントは控えますので、リンク先のデータを見てご判断ください)
まとめ
日本のオープンデータはここ数年で急速に普及しつつあるものの、データ利活用の観点から見るとまだまだ改善の余地はあるかと思います。
ただデータを提供するだけではなく、データ提供した先の未来を見据えて提供していただけると、我々データ人材が輝けると確信してます。
と、建前は綺麗にまとめましたが、本音としては、ちゃんとデータ定義、テーブル設計しようね、という話でした。
(これはオープンデータに限らず、データ分析する前のデータソースを生み出すすべての人々に強く発言したい点でもあります)
補足
かなり語気の強い表現をしてしまったので、このnoteを読んだ方によっては、「e-Statや東京都のデータをdisっている」と思われるかもしれません。
ですが、そのような意図はございません。
しかし、これらのオープンデータがデータを専業にしている人々が気軽に活用できるレベルに及んでいないのは事実ですので、オープンデータ提供者に対しての1ユーザーとしての要望として捉えていただければと思います。
オープンデータという、とても貴重な食材を僕たちデータ人材がいい感じに調理し、美味しく提供できるようになる社会を願って、筆をとりました。
2023年9月25日追記
4年前に投降した内容を若干推敲しましたが、主旨は変更していません。というのも、4年たった現在でも上記の通り状況は何も変わっていないのを確認しています。
非常に残念な気持ちでいっぱいになりましたが、悲観的になっても仕方がないので、今後もオープンデータのありかたについては考えていくとともに、機会があればオープンデータの取り組みに関わるような働きができればいいかなと思いを馳せました。
以下は余談ですが、SIerが内製で提供するデータプラットフォームの品質の課題も見えてきたので、こうした独自仕様ではなく、データプラットフォーマーが提供する環境にパブリックデータとして提供するのが時流に則ってよいのではないかなと思います。
BigQueryやSnowflakeで日本のデータを簡単に取り扱うことができる未来を信じています。
ここから先は
¥ 100
読んでいただきましてありがとうございます。 サポート代は次回の執筆の投資に使わせていただきます。 https://twitter.com/kazuya_araki_jp https://public.tableau.com/profile/kazuya.araki#!/