足りないのは人材と望まれるデータなのだった

前回のおさらいから

前回の記事「そろそろオープンデータにおける立場の違いについて書いておこうか」の続き。
立場の違いについても、もう少し考えるべき事項があるはずなので、できればそれらも交えながら思考してみる予定。

こぼれ落ちた人＝ギーク

当初、産官学民それぞれの立場や思惑の違いをまとめるだけのつもりだったのだが、比較的ドラスティックに分類した結果、こぼれ落ちちゃう人がいて、その人たちがオープンデータから派生する施策の成果に寄与する人材であることを再認識したということ。
で、この希少人材のことを、ギークとか、ハッカーとか、ウィザードというのだけど、日本語で表現するのは難しい。趣味人とか遊び人とか、そういう類が近いのかもしれない。
例えば、こんな人。

邪悪な心を持たない。
息をするようにコードが書ける。
公的活動に理解がある。
金銭的欲求が高くない、あるいはすでに十分な金銭的報酬を他から得ている。
業界内の評価を重要視する。
ある程度の社交性がある。

こう考えると、行政機関が公開するデータの種別や形式も工夫するべきポイントがあることに気付くし、動機付けやモチベーションの維持のための工夫が必要なこともわかると思う。

公開するデータの形式

今さらな感じがするけど、誰に向けたオープンデータかと言えば、今回は「ギークに向けて」ということで話を進めたい。
ギークたちは面倒なことを嫌うので、プログラム処理できない（あるいはその処理に手間がかかる）形式でのデータ公開には見向きもしないし、自分が面白いと感じて、周りの人に感謝されるテーマのデータでなければ、スルーするだろう。
また、そのデータの取扱いについて懸念するような状態も（いちいち確認するのが面倒なので）避けられる傾向にあると思う。（これは私の思い込みかも）
なので、データ公開の形式は最初からスキーマ定義されたRDFやXMLであることが必要だろう。また、マッシュアップすることでビジュアルの面で訴求力のある地図（座標情報）や市民が気になるお金に関する情報、議会や請願に関する情報が公開されると、ギークを支援する声も高まる。
リアルタイムで更新し続ける情報もギークたちは大好きだ。自動化、ビジュアル化の効果が高いので、モチベーションが高まる。
セマンティックWebの考えに基づくならば、スキーマ定義することは絶対に必要で、オープンデータはデータの公開ではなく、むしろスキーマの公開の方が重要だと思うぐらいだ。このあたりが、行政職員にはなかなか理解してもらえないのが、私の力不足なところ。
ちなみに私の博士論文のテーマは、行政機関で取り扱う申請書類のスキーマ定義を公開し、リンクさせることで行政手続の手順を推論することができる、というものである。つまり私自身がコテコテのセマンティックWeb肯定論者である。
関連する論文はこれ↓　当時は行政機関で働くとは思ってなかったなぁ（遠い目）。
「申請手続オントロジを用いた一括申請手続に対する作業計画支援」（情報処理学会論文誌）
そういう背景もあるので、公開するデータがCSVでよいとか、PDFのままでも公開すればオープンデータだ、という主張を聞くと悶絶してしまう。もはやデータの公開自体が目的になっているのは、悲しすぎる。

ライセンス表記

これも私の強い思い入れだが、ライセンス表記はセマンティックWebの流儀に従って、公開するデータの中にリンクとして埋め込むべきだろう。
カタログサイトにライセンスを書いているだけでは不十分なのである。なぜならば、公開したデータが二次利用、三次利用していく中であっても、元のライセンスの意図が適切に伝達されなければ、データ利用側は怖くて使えない。
公的機関だから許される、とか、無償だから許される、とかの意見はちょっと暴論で、原則としてあらゆる著作物にはそれなりの権利があり、権利者が「このように使ってほしい」という意思を込めたライセンスは尊重されるべきだろう。
では、具体的にどうすればよいのかというと、CC-BYなどすでにオーソライズされているライセンスならば、それを適用する旨のリンクをデータに加えればよい。

<metadata>
<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:dcterms=”http://purl.org/dc/terms/”
xmlns:cc=”http://creativecommons.org/ns#”>
<cc:Opendata rdf:about=”ここにデータの所在を書く”>
<dc:date>2015-06-01</dc:date>
</cc:Opendata>
<cc:license rdf:resource=”http://creativecommons.org/licenses/by-sa/4.0/”/>
</rdf:RDF>
</metadata>

たとえば、CC-BY4.0 を適用するのならば、データ実体の前にこのようなメタデータ部を入れておく。（ここではついでに別のスキーマ定義も入っているけど）
独自のライセンスならば、名前空間（xmlns）を定義し、必要なライセンスページを作成し、そこへのリンクを license タグで指定すればよい。

データの生成と公開

オープンデータ化して公開するデータをどのように生成するのか（特にスキーマ定義をきちんとするのならば）は、行政機関にとっても悩ましい問題である。
常にコスト－ベネフィット、という話は前回もしたとおりだが、ベネフィットの目途も立てずに予算を使ってオープンデータ化するのは（個人的には）感心できない。
やはりオープンデータは本来の事業の副産物として取り扱うことが、当面取り組める範囲なのではないだろうか。つまりオープンデータ化する事業ではなく、本来の事業のついでにオープンデータ化してね、というスタンスである。
そもそも最終成果物が印刷物だったり、Webサイトだったり、報告書だったりする時点で、中間生成物はデータ化されているのだ。ならば、納品物をひとつ増やして「発注者が指定するスキーマ定義に沿って、データを生成し納品すること」とすれば、頭の良い受注者ならば、最終成果物を作る際に、要求に沿ったデータを生成する工程を溶け込ませることぐらい造作ないのである。（厳密に言えば工数は増えるのだが、作業を工夫すれば吸収できる程度の規模だと思うし、業者選定は入札するので、頭を使ったところが残る仕組みとなるはず）
一方、いくつかの先行自治体で採用されている「既存のデータをRDFに変換して公開するサービス」は当面は有効だと思うが、BPRもしないでその仕組みに依存するのは危険な気がする。オープンデータはなかなかやめられないので、手離れの悪い（サービスを提供する側にとってはうまみのある）関係になってしまう。チューチュー吸われちゃうよ。

システム開発の副産物としてのオープンデータ

上記に関連するけど、システム開発の過程でオープンデータを意識しておくと、システム開発の質も向上すると思う。
これは私が実際に支援したケースなんだけど、高知県漁海況情報システムという漁師向けのWebサイトがある。
高知県漁海況情報システム（高知県）
このサイトは高知県沖にある４基の漁礁（魚のエサ場）に海水温や風力、波高などを計測するセンサーを設置して、それらの情報を逐次集約し可視化する仕組みだ。漁師は高知港を出港して漁場に行くまでに数時間かかるので、あらかじめ現地の情報がわかっていると漁の戦略も立てやすいのだ。
現在の仕組みを作ったのは、私が高知県にいた時だから2011年ぐらい。世の中でオープンデータという言葉がメジャーになるずいぶん前の話である。
このころから私はデータ公開の重要性を認識していて、システム導入を企画した時に次の2つの方針を示した。

センサーから取得した情報は一度RDFとして成形させ、公開する。
RDFとして成形した公開情報を、表形式やグラフなどにして表示させる。

つまり、このサイトで表示しているグラフは、公開されたデータをもとに作成しているのだ。この時点でシステムの開発者とまだ見ぬギークは競争関係になる。
また、見方を変えれば行政機関はデータを公開することによって、より良いサービスを提供する余地を与えているとも言える。システム開発者の力量が乏しくても、ギークの尽力により、それを上回るサービスが提供できるのであれば（行政機関は甘えているのかもしれないが）結果オーライなのではないかと思うのだ。

まとめ

強引にまとめておく。
アプリコンテストやアイディアソン、ハッカソンの開催は、ギークの興味を喚起する手段としては有効。これはちょっとした工夫でそうなる。
併せてギークを育てるための土壌作りも必要。コードも書かないでオープンデータとか語っちゃダメだろ、というのが私の本音である。（お前のことか？　いやいや、私はコードは書きますが、息をするように書けないだけです）
ということで、オープンデータについて、私が考えているのはこんな感じ。