野良データを撃つ銀の弾丸はない
日本でもオープンデータの取り組みが大きく動き始めた。昨年7月にIT戦略本部が電子行政オープンデータ戦略を発表し、12月に電子行政オープンデータ実務者会議が立ち上がり、2月に入ってオープンデータIDEABOXで意見を募集し始めている。さっそく経済産業省がOpenData METIを立ち上げてデータを公開し始めた。公開に当たっては利用者が扱いやすいフォーマットで提供できるに超したことはないが、準備に時間をかけるよりはExcelで構わないから提供可能な文書から公開し、フィードバックを受けて段階的に改善した方がいい。
政府の保有している情報のうち統計や地図、道路情報など利用価値の明確なものは既に公開または商用化されている。これから公開するデータとして検討の俎上に上がるとすれば、何らかの行政目的のために収集され、ビジネスや学術分野で副次的な利用価値があり、かつプライバシー等の課題をクリアして公開できる情報と考えられる。これらは使途がはっきりすれば適したフォーマットや保守に要する業務手順、改竄やら悪用のリスクも見えてくるが、ユースケースとデータは鶏と卵の関係にある。
ざっくりとオープンにすべきデータの分類基準として、
- 公開可能な情報として切り出されているか
- フォームなりスキーマが定義されているか
- 作成・閲覧等のツールが提供されているか
といった要素が考えられる。
例えば地理情報のようにスキーマが定義されてツールも提供されていれば、そのままで必要十分なメタデータがついた機械判読可能なデータとなる。スキーマが存在せずツールも存在しないと現場が自由にExcelで表を組むことになるが、担当者のセンス如何で自動処理が難しい形式となってしまう場合が少なくない。
これは別にExcelだけの問題じゃなくて、RDBのテーブルだって、XMLのスキーマだって設計者センスが悪いと悲惨な結果になるし、自由度が高いほど間違った設計をされると後から手に負えない。ブルックス先生も「腐ったロジックは書き直せばいいが、腐ったデータは似ても焼いても食えない」的なことを『人月の神話』で書いてた気がする。良かれ悪しかれ表計算ソフトには表しか入らないから腐ったオブジェクトやバイナリデータよりはマシで、最悪でも印刷すれば読める。
現場としては文書として使えれば十分なのに突然「機械判読可能なフォーマットで公開して下さい」と頼まれ「え？それ何に使うんですか」と聞いたら「まだ分からないけど、そのうち何か使うかもしれないんで」なんて答えられた日には「そんなテキトーな思いつきで現場の仕事を増やさないでよ」と思ってしまうのが人情ではないか。
だから順番としては、
- 手元にあるデータから公開・カタログ化し利用者から意見を吸い上げる
- 項目中に空白を入れないとか再利用容易なデータ作成の手引きをつくる
- 利用頻度の高い共通データはスキーマを定義しツールを整備し展開する
- 外部からよく使われているデータは扱いやすいフォーマットに整形する
といった流れが現実的だろう。まずはExcelなり手元にあるデータを公開するのが手っ取り早くて、何でもかんでも最初からLinked Open Dataで出せといっても難しい。仮に力業でやり遂げたところで当面ボットの肥やしにしかならないかも知れない。とりあえず人間判読可能なフォーマットでデータを公開していれば、必要に応じてクラウドソーシングで機械判読可能なかたちに変換することも簡単にできる。
ところでOpenData界隈に蔓延るExcel悪玉論について思いを巡らせると、日本の事務書類にはやたらと複雑なExcel帳票が多い。日程調整やら履歴書やら予算申請やら何でもExcelテンプレートで回ってきて、どれも微妙にフォーマットが異なる上に入力が難しい。表計算ソフトをこんな奇天烈な使い方するのは世界広しといえども日本くらいではないか。ワープロや電子帳票アプリを使うべき局面でも、ワープロソフトの罫線機能が貧弱だった時代の名残で表計算ソフトを使う珍妙な慣習が残っている。
学生時代ライターとして駆け出しの時分だから15年以上も前の話になるが、担当編集者からLotus 1-2-3のムックを出したら筆者から原稿を123形式で受け取り泣きながらCSVに落としてエディタのマクロで整形した逸話を聞いたことがある。今でもExcel方眼が馬鹿にされるけれども、昔は表計算の達人が1セル1文字の1-2-3原稿用紙で入稿したらしい。閑話休題。
わたしがXMLを学んだ90年代後半、まさか十数年後Semantic Webが流行らないどころかXHTMLが頓挫してHTML5でデータとUIとロジックが混ざった世界でWebアプリのワープロや表計算と格闘してる未来なんか想像できなかった。期待したXFormsやらInfoPathやらXfyは流行らず、まだまだ検索エンジンは自然言語での問いに答えられず、今日も今日とて右のExcel帳票から左のExcel帳票へコピペ奮闘している訳だ。それが正しい未来とは思わないけれども、何故そうなったか胸に手を当てて考える必要は感じている。
ひとつに表よりも複雑なデータを正しく設計できるデータアーキテクトは多くないし、実際の事務でも表に収まるデータが割と多い。だから柔軟かつ高速なOODBやXMLデータベースは流行らず今でもRDBが好まれるし、Lotus Improvの20年前から表計算ソフトは多次元データを扱えるようになり、ExcelもPivot Tableを簡単に扱えるにも関わらず、相変わらず使いこなす人は限られるのではないか。CSVは単純で扱いやすいが2次元の表しか表現できず、値の単位や属性のメタデータを欠いている。それでも困らない程度に多くの人が表計算ソフトで扱っているデータは単純なのだろうか。
世間に流通するデータを見渡して、一方の極に厳密に構造化されて専用のツールで扱うデータがあって、その対極に未整理で構造化されていない自然言語や生データがある。その合間でグラデュアルに漂う中途半端に構造化されてはいるが分断されたデータの受け皿として、この何十年か表計算ソフトが使われてきた。
Excel文書はバイナリやテキスト文字列、CSVと比べてリッチなデータ型やメタデータや構造を持っている。GUIで表に収まらない多次元データも扱え、要素にURIを持たせてデータ間をリンクし、バインディングを定義してXMLにマッピングすることもできる。にも関わらず現実には機械処理の困難なデータがExcelで量産され続けるのは、構造化されたデータや計算式を「紙上の表」として表象する表計算ソフトの宿命なのだろうか。
5★OpenDataは幾つかの異なる論点を混同している。Excelについて「データを文書から取り出すには独占的なソフトウェアが必要です」と解説し、CSVの方が望ましいとしているが、Excel 2007以降のXLSX文書フォーマットの標準化はISO/IEC JTC1に委ねられ、Libre OfficeやiWorkを含む多くの製品でサポートされていることや、APIを通じてアプリケーションからもデータを取り出せることを無視している。
現実に流通している表計算文書が適切に構造化されていないのは、紙での慣習が持ち込まれがちな上、ユーザーにとってデータ設計が難しいからで、柔軟な文書フォーマットや分かりやすいツールほど同様の問題に直面する。そして文書や値の意味を明確にするメタデータやリンク構造はデータを適切に重ね合わせる上で有効だが、自動処理しようとすると複雑になる。CSVよりもXLSXの自動処理が難しいように、LODの自動処理もCSVよりは難しい。
これら本質的なトレードオフが曲解されて安易なExcel批判に転化しがちなのは、現実に社会で広く使われているExcelと比べてLODを扱う実装が普及していないため、矛盾が表面化していないからではないか。Linked DataはWeb空間に構造化された情報空間を形成することを目指しているが、その障壁は独占企業や製品固有のフォーマットよりも、現実世界の複雑さとデータを入力する人間のスキルのばらつきや能力の限界にある。RDFやLODを普及させるには簡便にスキーマ定義やデータ入力できるツールが不可欠だが、それらが整備された暁にはExcelと似たようなリテラシーの問題に直面するのではないか。
OpenDataの公開と活用を中長期的に拡大していくには、データにアクセスして分析ツールを開発するプログラマーの視点だけでなく、データを保守する現場や、データの分析者、受益者の視点も不可欠だ。特に住民生活に密着したデータを多く保有する市町村での横展開を図るには、技術的な敷居や運営費用を下げると同時に、具体的な住民サービスの改善に資することを示す必要があるだろう。
