こんにちは！Riekoです。
Tableau界隈で有名な「オープンデータスゴイ」はご存じでしょうか？
オープンデータスゴイとは
私はオープンデータスゴイの中の人ではないので、
まずはこちらをご覧くださいませ
ざっくりと言えば、
Tableauのエキスパートの集合体であるVIZZIESによる、
オープンデータとコミュニティの力を使って、
可視化や分析して地域貢献しよう！というプロジェクトです
（↑適当に言ってるだけなのでVIZZIESの方間違ってたら指摘してください）
Round4!施設データを分析しよう
これまでRound1から錚々たる分析・可視化が行われてきたのですが、
今回は東京都目黒区の施設データです。
「施設データってなんやねん」って最初は思った（VISSIESさんごめんなさい）のですが、
保育所、交番、障碍者施設などなど目黒区の管轄にあるあらゆる施設をキーにして、
いつできたのか？何の用途なのか？建物名は？土地面積は？
といった、よく見ると目黒区の福祉や地域事情を表す、
夢とロマン（？）が詰まったデータです。
どんなデータ？
百聞は一見に如かず、Excelファイルを切り取ってお見せすると、
うん、長い。テキストが長い。
でもひとまず第1正規化はされてるので、そこは安心しました。
（第1正規化できてないと、見た瞬間拒否反応起こしちゃうので...）
さていよいよ、Prep君に読んでもらいましょう
Prepで見てみる
...おわかりいただけただろうか.....
私のようなアラフォーにもわかるように、大事なところを切り取りましょう
「列数って190あんねん」
某スーパーモデルの声が聞こえました。
もうこうなると目視で全部確認って不可能なんよ。
でもこれ、実務あるあるなんよ。
列数がせいぜい20未満とか親切設計なのは、サンプルスーパーストアだけなんよ。
がしかし、既に整形し終えたつわものの仲間がたくさんいるので、
強い意志を持ち、加工の道へと歩んだのでした。
（めでたしめでたし）
で、どうしたか
ここでは詳細な加工の内容は紹介しません。
そもそも私の加工結果が正しいのかもよくわかりません。
私が何をしたか、めちゃめちゃざっくりご紹介すると、
- みんな大好き横持データはピボット解除
- ファクトテーブルとマスタに分ける（マスタは「建物・土地」と「施設」）
- 欠損値はみんなNULLにしてしまった（いいのか？）
- 和暦は西暦に変換（chatGPT君、ありがとう！）
- 「建物・土地」に表記ゆれがあり過ぎたので、先人の知恵により名寄せ
などなどです。
あとやりたかったけどやれてないこととしては
- 「H3.1.1~R3.1.1」みたいなテキストデータを「開始日」と「終了日」に分けて全部DATEにする
- バリアフリー適合状況列の「エレベーター、トイレ...」みたいなのを、全部SPLITしてピボットして縦持ちにする
どちらも時間かかりすぎるので今回はスコープ外としました。
正直、完璧に綺麗なデータにしようと思ったら時間がいくらあっても足りません。
実務でやれと言われたらやるしかないけど、あくまで練習なので...
ただ、実務でやるのも辛いので、
もしかしたら「完璧に綺麗なデータを作る」よりも
「必要な列だけ必要な人が取り出して、使いたいように加工する」方がいいのではないかと思いました。
「バリアフリー適合状況」に関しては、個人的にVizづくりに挑戦したいと思ったので、
別途バリアフリーだけのマートを作りたいと思いました。
で、今回作ったフローの全体像はこちらです。
今回の加工で感じたこと10選
今回のフロー加工を通じて色々学びましたが、ざっくりあげるとこんな感じです。
- 要るかわからないけどとりあえず列残しておく、のはありなのか
- 項目の定義があるだけでも助かる。今の実務はない
- 耐震のテキストデータは課題。でもこれをちゃんとすればいい分析ができそう
- 建ぺい率と容積率の「・」はどういう意味なの不明で置いてる。
- 今回はエキスパートがやってくれたけど、実務だと自分でユーザーとデータ定義を確認するやり取りが必要
- データ定義は chatGPT 便利すぎる。でも実務では会社情報教えてくれない
- 名寄せは、値のグループより計算フィールドによる上書きの方が正確かも
- 土地名とか土地 ID はないのか。土地を一意に識別できない
- データの発生元は？どっかの RDB から取得？手作業？
- CASE 文は or 使える！
では、多いので一個一個さらっとピックアップ。
1.要るかわからないけどとりあえず列残しておく、のはありなのか
列、多いんですよね。そんなに要るか？みたいな。
なので要らない列はさっさと削除しておいた方がいいと思うのです。
勿論その方がパフォーマンスも良くなるし。
でも、「誰かが使うから」とか「いつか使うから」とかで残してること多いと思うんですよね。
実務でも、使わない列いっぱいあります。
自分は使わないけど、「いつか」「誰か」使うから残す。
それは果たしてベストプラクティスなのか？と思うわけです。
とりあえず必要な列だけ残して、後から要るとなったら復活、というのはできないのかな？とも思うのですが、いかがでしょうか？
2.項目の定義があるだけでも助かる。今の実務はない
今回テーブル定義書的なものを頂いておりました。
全部見たい方はこちら
これが非常に助かりました。
でも、実務ではこういうの無いこともあるんですよね。
だからこういうのちゃんとすること、がめっちゃ大切だと感じました。
ただ、中には、こういうのもあるので、
いや、ちょっと待って（ください）
色々足りてない（ですよ）、というのもありました。
皆さん、テーブル定義はちゃんとしましょう。明日のみんなと自分のために。
3.耐震のテキストデータは課題。でもこれをちゃんとすればいい分析ができそう
「耐震診断」という列があってですね。
Prepのプロファイルペインで上の方見るとこんな感じなんですね
あ～はいはい、耐震診断やった年の和暦ね。
西暦に直して備考欄に分ければ余裕じゃね？
と思うじゃないですか。
ところがどっこい、下にスクロールすると
んんん？まじか～
学校の場合、校舎と体育館で耐震診断年度別なんですね。
これをどう分けるか？
思いつく限りではSPLITしてピボットして縦持ちにするくらいなんですが、
いいアイデアあれば教えてください。
ちなみになんでこの列に着目したかというと、
私今住んでるマンション旧耐震なんですよね。
理事会でも地震来たら怖い怖いってみんな言ってて。
なので「公共施設の防災耐性とは？」みたいなViz作ったら面白いなと思いました。
ただ「新耐震以降」でまとめられてる値をどう扱うかが課題ですね。
（新耐震のマンションに住んでる方は富豪だと思ってます）
4.建ぺい率と容積率の「・」はどういう意味なの不明で置いてる。
「建ぺい率」って何やねん？
とまずそこからなのですが、
chatGPTに聞いてみると
だそうです。
一戸建てで言うと「庭が広いか」「家が広いか」みたいな感じですかね。
（そもそも今回は一戸建てではない、というのは置いといて）
で、そのデータがですよ、Prepで見るとこうなってるわけですよ。
いやいやいやいや.....
「50・60%」、50なのか60なのかどっちなんだい？ってわけですよ。
とりえあえずchatGPTに聞くと
とのことですが、「ほんまかいな」っていう、正直あんまり信じられないので、スルーすることにしました。詳しい方、教えてください。
5.今回はエキスパートがやってくれたけど、実務だと自分でユーザーとデータ定義を確認するやり取りが必要
今回、多くの表記ゆれが発生していました。
が、事前にPrepエキスパートkomatsuさん（@antipop1）とVIZZIESでありPrep Starのもりたさん（@hiroakimo_tw）が、目黒区さんと相談して統一してくださいました。
それがこれ↓
いや～神過ぎる。
名寄せはそこそこ大変だったけど、
「信じられるものがある」というのが何よりの心の支えで、
1ステップずつ頑張って取り組めました。
でもこういうのって実務ではかなり大事な部分で、
整合が取れていないデータの部分を、ユーザーと確認して認識を合わせていく、
（決して「あなたたちのデータ汚い整ってないですよ」なんて言ってはいけない）
そういうプロセスもかなり大事だな～いやむしろ根幹だな～って思いました。
6.データ定義は chatGPT 便利すぎる。でも実務では会社情報教えてくれない
さきほどの「建ぺい率」のように、
分からない用語をchatGTPに片っ端から聞きまくりました。
まあ完全に合ってるか分からないけど、そこはもう信じるしかないです。
でも、実務って、生成AI教えてくれないんですよね。
なぜなら殆ど会社情報だから。
会社情報を学習させてるスーパーカスタマイズAIがいたらいいのですが、
それが実現する未来はまだまだ先かも。
特に私のような立場弱い人間はユーザーさんや上司になかなか会社情報聞けないので、
AIが助けてくれたら1000倍楽なのにな～と思ってました。
7.名寄せは、値のグループより計算フィールドによる上書きの方が正確かも
こちらは単にPrepのtipsです。
Prepには、「値のグループ」といって手作業で特定の値を置換できる機能もあるのですが、
置換というものは値に対して行うもので、
特定の行だけ置換するのはまた別の話になってくるんですね。
上記画像の「建物備考」とかだと表全体で一意（一個しかない）のが多いので「値のグループ」使ってもOKなのですが、
「-」を置換したいってなると、特定の行だけでなく他の行の「-」が全部置き換わってしまうので、そういう場合は計算フィールドで列を上書きしました。
ちなみにこの方法だと一気に色んな行を置換できるので、
ステップ数を減らすのにも使えると思いました。
まぁ、計算式書くのめんどくさいので値のグループも結構使ってしまったのですが....
8.土地名とか土地 ID はないのか。土地を一意に識別できない
このデータ加工でマスタに分けるってなったとき、
だいたい表と先ほどの定義書さらっとみて「施設」「建物」「土地」の3つに分けられると思ったんですね。
で、実際分けたのですが、土地がこんな感じなわけです。
え？主キー何？ってなりません？
そう、「土地を一意に識別する何か」が何もない、そう何もないのですよ。
なのでこれはもう諦めて、「建物・土地」マスタを作りました。
ん～でも建物と土地って別じゃないのかな？
同じ土地でも建物が違う、みたいな？
その辺もドメイン知識がないのでよくわからないです....
そういうわけでなんとなくもやもやしたのでした。
9.データの発生元は？どっかの RDB から取得？手作業？
今回結構たくさんのデータなので、もしかしてDBに貯めてあるのかな？と思ったのですが、
実際どうなんでしょう？
値の型が曖昧な部分もあるし、でもこういうデータこそ正規化してデータレイクなり貯めていく必要があるのでは？と思いました。
オープンデータ、私の愛する大阪市でもがっつり活用されていますが、
その辺のデータ基盤やデータマネジメントの実態が気になったのでした。
10.CASE 文は or 使える！
こちらは勉強会で学んだPrepのCASE TRUEの書き方についてです。
PrepのCASE文はSQLとは少し違っているのですが、CASEの後にTRUEを書けばWHENの後に条件文が書けることを勉強会で知りました。
詳しくはこちらをどうぞ
で、今回やりたかったのは、私が作成したファクトテーブル（っぽいやつ）の「費目分類」を作る式で、
結果的にこのような計算フィールドを作りました。
最初、orを使ったらエラーが出ると思って、勉強会でもそう発言したのですが、
それはタイプミスによるエラーで、
ちゃんと動くことが分かりました！
やはりCASE文、便利ですね！
（知っている方からしたら当たり前すぎてすみません）
（番外編）正解はない
データ加工に正解、ないんですよね。
でも毎週Preppin Dataやっていると、正解があるので、正解と合えばOK!ってなってました。
でも、実務でのデータ加工は正解が与えられていない。
与えられていたらそもそもやる必要がない。
というわけで今回「正解のないデータ加工」に取り組めたのは、貴重な経験でした。
人生に正解がないのと同様、データ加工・分析・可視化etcすべてにおいて正解はない。
なんかかっこいいこと言っている気分になります。
おわりに
なんかとても長くなってしまいましたが、
長文に付き合ってくださった方ありがとうございます！
オープンデータってすっごい面白いし、
サンプルじゃなく実際のデータって本当実世界を反映しているなって思いました。
また、改めてデータ加工が好きだなって実感しました。
（データって手段であってそれ自体目的でないので、データ加工が好きというのも微妙な気がしますが）
ではまた、次回もお楽しみに！
追伸：オープンデータスゴイRound4、ぜひチャレンジしてください！
Rieko