幼稚園・保育所・こども園まわりの話

Code for Kobe で活動していますが、定例会の枠は魔法のように満員御礼状態。たまには自分のネタを出してみたいと思いつつアドベントカレンダーに書いてみることにしました。Civic Tech Advent Calendar 2016 の記事です。

最近は未就学児童を対象とした施設の状況を調べています。ニュースでもよく話題になりますし。話題になる割にはデータがよく見えないと感じているのですが、どうなんでしょうか。複雑な制度なのですが、現在当事者となっていることもあり、試しにデータを集めはじめました。

「子ども・子育て支援新制度」というもので、詳しくは内閣府のページに書いてあります。これまで幼稚園・保育所とあったのを、より一体に運営できるように「こども園」という制度に乗せて、地方自治体に移管していく、というのが大枠です。施設運営には給付金が設定されました。また地方自治体は制度利用にあたって、こどもの「認定」をすることによって定員枠のコントロール権を得ました。

この制度は、例えばこんな形で唐突に始まります。

「平成27年度より幼稚園・保育所の利用について認定が必要になりました」

認定をおおざっぱに説明すると、1号認定＝専業主婦＝幼稚園的で、２・３号認定＝共働き＝保育所的です。２号３号の違いは子供の年齢。金も出すが口も出すということで、運営側は給付金が欲しいし自治体は管理業務が増えるしで、現在のところ実体はかなり硬直化した運用になっているところも多いのではないでしょうか。2号＝ファーストクラス、１号＝エコノミーみたいになっちゃってることもあったりなかったり。枠が無ければ入れないので、例えば子供が複数人いると１号認定から２号認定に移るのは事実上不可能だったりします。これが小学校になると義務教育で、学区にある学校に必ず入れることになるので、その制度のギャップにも驚かされます。

さて。そんな新制度ですが、いろんな自治体で現在進行形で制度変更が起こっています。実際幼稚園がこども園になったりというのは、結構頻繁に起こっています。つまり幼稚園・保育所・こども園一覧は思った以上に頻繁に更新されています。生活がかかっているとはいえ、これについていくのは大変です。

そんな状況もあってか、保育園マップ作成は活発に行われているようです。Code for Sapporo で作られた保育園マッププロジェクトの fork がいくつかあって活発に活動しているようです。この他にも例えば大阪市では独自にマップをメンテナンスしているようです。データ作成イベントとかも開催されているようで、何やら楽しそうです。羨ましい。

しかしまぁ、なんでしょうか。そうはいっても、元データをオープンデータにして欲しいのであって、常日頃からみんなでデータ整備に汗を流したいわけではない、というのが本音ですし、あるべき姿かと思うのです。サステナビリティは大事で、古くなってしまった情報を始末したりケアするのは、なかなかどうして、馬鹿にできないコストがかかります。

ちょうど神戸市のバルセロナワークショップで、神戸市のデータを整備して作品を作った ので、範囲を広げて兵庫県全域でのデータ収集にチャレンジしてみました。サステナビリティ大事なので、とにかく自動化を頑張ります。

まずは施設一覧を目標にしてみます。データを引っ張ってきて「表っぽいところを抜き出してみる」という線で試してみました。リポジトリは U5 にあります。データ取得元は u5/task28.py で、検出できたものは all.ttl です。こういう「あるかどうかわからない、何個あるかもわからない」という種類のデータは RDF が得意ですね。csv や json ではなかなか難しいです。

どうでしょうか。いろんな癖のようなものが見えてくるので、興味深いです。

• 「・」が多用されやすい。しかし Turtle の prefixed name では禁止されている文字列。
• 見出しに半角数字が入ることもよくある。
• 改行にデータ区切りの意味を持たせることがある（セル内で）
• 全角スペースで見栄えの調整がされていることがある
• コンテキストで省略されやすい、県や市などの住所
• コンテキストで省略されやすい、市外局番
• コメントが埋め込まれていることも結構ある
• 丸括弧「（」「）」も多用されやすい。
• 表記ゆれはざらに起こる（全角半角にはじまり多種多様）
• BOOLEAN の表現が多種多様
• 表になっているものは、まだマシ

一般的に「データが欲しい」といった場合は、「構造化データ」や「半構造化データ」を指します。表になっていればそれだけで構造が一つ与えられるので、少しマシです。表にすらなっていないものは、文書構造からさらに推測して何とか構造化データにできれば御の字です。PDF は文書構造すら一旦壊すので、大変使いにくいですね。

また表になっていても、構造化データでないものも厄介です。「ネ申エクセル」が論外なのはもちろんなのですが、表のセル内で改行や括弧やその他文字列の規則でデータ構造を表現してあるものもイマイチです。「セル＝データ一つ」が望ましいです。見栄え調整のためのスペース文字入力もやめたほうがいいです。ちょうど HTML で table を見栄えの調整に使うべきでないのと同じ話です。この二つをクリアしていると、それだけで使い勝手はぐっと良くなります。HTML でも table layout が駆逐されるのに相当な時間がかかったので、こちらも時間がかかりそうですね。ともあれ、現状は見栄えと内容を一体化して配布しているので、確かにこれらは区別せずにメンテナンスされやすい環境にあります。ひょっとしたらデータアカデミーとかで話をしているのかな？

フィールド名らしきものとして抽出されたのは次のようなものです。ファイルにも主力しています。思ったよりたくさん種類があります。

• 0歳児入所時期
• 3歳児
• 4歳児
• ４歳児定員
• 5歳児
• ５歳児定員
• FAX番号
• No
• オムツ替え
• バス送迎
• ファクス番号
• ファックス番号
• ブロック
• ホームページ
• ミルク用お湯
• ミルク用備考お湯
• 位置
• 一時保育
• 一時預かり
• 一時預かり（一時保育）
• 一時預り
• 運営
• 運営主体
• 園（所）の紹介
• 園バス
• 園歌
• 園歌楽譜
• 園章
• 園庭開放
• 園名
• 延長保育
• 延長保育実施時間
• 科目
• 会場
• 開園時間
• 開所時間
• 開所時間（月～金曜日）
• 開所時間（土曜日）
• 開所時間(保育短時間)
• 開所時間（保育短時間）
• 開所時間教育標準時間保育短時間
• 各園のホームページ
• 学級
• 学級名
• 学校名
• 休所日
• 休日保育
• 給食
• 区
• 区分
• 経営主体
• 公私
• 産休明け保育
• 施設の名称
• 施設所在地
• 施設名
• 施設名住所
• 児童の年齢別定員
• 時間外
• 時間外の有無
• 時間預かり
• 時間預り
• 種類
• 受け入れ時間
• 受入開始月齢
• 受入開始年齢
• 受入時間
• 受付時間
• 受付日時
• 授乳室
• 住所
• 所在区
• 所在地
• 所在地（播磨町）
• 所在地・電話番号
• 所在地電話番号
• 小学校区
• 小学校名
• 証明
• 証明書交付の有無(※)
• 障害児
• 嘱託医医院名
• 職員数
• 申込児童数
• 設置
• 設置者
• 設置主体
• 設置年月
• 設置名
• 組織
• 卒園年齢
• 対象
• 地区
• 地図
• 中学校名
• 朝の預かり保育開始時間
• 定員
• 定員（2.3号認定）
• 定員1号2号3号
• 定員2号3号
• 電話
• 電話FAX（078）
• 電話番号
• 電話番号（079）
• 電話番号授乳室
• 乳児の受入
• 乳児受入
• 入園してから必要なもの
• 入園に必要なもの
• 入園区域
• 入園対象年齢
• 入所対象年齢
• 入所年齢
• 入所年齢（歳）
• 認可外保育施設指導監者督基準適合状況
• 認可外保育施設指導監督基準適合状況
• 認可定員(全体)
• 認定こども園名
• 番号
• 備考
• 病児・病後児保育
• 分類
• 保育園名
• 保育施設名
• 保育所名
• 保育短時間（8時間）
• 保育短時間（８時間）
• 保育定員教育定員
• 保育標準時間（11時間）
• 保育標準時間（保育短時間）教育標準時間
• 保育標準時間保育短時間
• 募集クラス数
• 満3歳児
• 未就園児教室
• 名称
• 郵便番号
• 夕方の預かり保育終了時間
• 預かり保育
• 預かり保育の実施
• 幼稚園名
• 利用定員
• 利用定員（2・3号）
• 利用定員（２・３号）
• 利用年齢
• 利用年齢1号2号・3号
• 類型

表記ゆれを抑えながら、まとめていくのもなかなか骨が折れそうです。差し迫っては、現在の一覧と未来の一覧（予定）が同時に掲載されている場合に、情報をどう整理するかが悩みです。地図に乗せるのに geocoding もしないと。ライセンスをクリアしたものが欲しい。

早くいい感じでデータが流通するようになるといいなぁ…。

「5 star open data」の図

脱線話その1。オープンデータをはじめると、5 star open dataの図をよく目にします。正直これにはうんざりしています。文章で書かれていることはまともです。丁寧に読むぶんには大丈夫。しかし絵は「LOD が最高」というプロパガンダです。ポジショントークなので、鵜吞みにするのはやめたほうがいい。

未来を見すえつつも、現在オープンデータを運用していくことを考えるなら、現実を見るべき。私が使っていて思う、それぞれの特徴を書いてみます。

LOD

• アクセス手段に信頼性が必須
• 実装が発展途上。効率の良い実装は？
• RDF の性質を継承する

RDF

• トリプルの形で扱わなければならない
• トリプルが無いことで NULL を表現できる
• データ型が表現できる
• ツールが未整備で、事実上表データを直接編集できない
• 表にしにくいデータを上手く扱える時がある

CSV

• コメントが入らない
• colspan, rowspan が使えない
• 先頭行が見出しであるという暗黙の了解があり、マルチインデックスが使えない

Excel

• データの領域を推測するしかない
• OpenDocument や Office Open XML の親戚オープンフォーマットがあり、ロックインを避けられる
• セル一つをデータの単位として使える
• 複数のシートを格納できる
• ツールが揃っている

PDF

• 文書構造が失われる
• 意味のあるデータを抽出するのは困難

現時点では手で更新するものについては Excel が妥当ではないでしょうか。例えば pandas.read_excel で読み込めます。Open Packaging Convention を拡張して、スキーマがバンドルされるとかなると、かっこいいですね。CSV が Excel より常に優れているなんてことは全くありません。

また表データは、表が適切な表現方法である限り、表のままメンテナンスしたほうがいいです。メンテナンスコストを重視したほうが良いです。triple にしたほうが実現できること（データ流通やリポジトリ）もありますが、そっちはむしろ自動化しやすい話です。

HTML table も使い勝手はいいです。

社会課題？

脱線その２。Civic tech で見ていると、「社会課題の解決～」「事業の創出～」みたいなのを見かけます。私自身は Civic tech をやっているつもりではいるのですが、どちらも当てはまりそうにありません。会社員で働いている一方で、せめて個人的に身の回りのことを最低限現代的に整えたいな、くらいの気持ちです。

実のところ、今一番「意外と使える」と思っているのは、給食のカレンダー化です。

社会課題の解決や事業の創出はもちろん大切なことですが、ただ生活を快適するだけの活動も Civic tech として認められることであって欲しいと思います。幼稚園・保育所データの整備も「何が解決されるの？」「それから、どうするの？」「儲かるの？」みたいな突っ込み方をされますが、なんとも答えにくいですね。

Code for Kobe

脱線その３。Code for Kobe では、広く皆様の参加をお待ちしております。参加資格は何もありません。分からないことがあったら聞いてください！→Facebookページ