【京都大学公共政策大学院・地方行政実務実況シリーズ】「カタログサイトの操作・公開手順２」（第6回授業：2019年5月20日）

活用事例についての紹介、実際に利用してオープンデータの特性（とくに機械判読性）を考える

授業本文

1. 今日の授業のポイント

前回に続いてオープンデータのカタログサイトの操作をベースにしてお話をしていきます。

今回取り上げる機械判読性については、オープンデータの定義に3つあるうちの1つですけれども、この議論を通じてオープンデータの特性を考える授業にしたいと思います。

また、今回含めたトータル5回分の「データラングリング」というテーマで、データの生成・活用・運用それぞれに必要な要素がお互いに関連していることを頭に置きながら、実際にカタログサイトを操作するとか、オープンデータを触るってどういうことかなっていうのを意識していきましょう。

2. オープンデータ100について

前回紹介した内閣官房で取りまとめをしている「オープンデータ100」、実際はまだ100はないんですが、実はこれ、元ネタがあってですね、2014年に公開されたアメリカのニューヨーク大学Governance Labの「Open Data 500」があり、このサイトからは、オーストラリア・メキシコ・イタリア・韓国・カナダの事例も紹介されていることが見て取れます。

日本では、これを参考に500も事例をいきなり集められるか？ということで、まずは100を目指しましょうっていうこと、もう一つは、それでもこのくらいは目指したい、という相場感みたいなものがあるので、100事例を集めるということで2017年からやっています。

2018年度末からは、今までは推薦とかですね、国が自分たちで拾い集めてっていうところから、自薦も可するとしたそうです。この手のやつって「別にそんな広く知らせなくてもいいです」という控えめなことをする傾向も公務員の中にはあって、結構埋もれている事例って結構あると思いますので、今後事例が増えてくることを期待したいと思います。

こういった事例も参照いただいたということで、それを見ながら、現状のレベル感っていうかですね、こういう使い方をしているっていうのを見ながら、実際に先週から操作をやっていただいたオープンデータそのものですねサイトの利用も含めて、実際に利用してみるということをやってみたいと思います。

3. オープンデータを活用した事例の類型

オープンデータ100をご覧いただいて、どうでしたか？何か感想なり意見なり質問なりをお持ちの方いらっしゃいますか？

へーっていう感じですか？私は、あれちょっとわかりにくいなと思います

事例ごとに上に分野・色が分かれていたかと思いますが、あれはあれでいいと思うんですけれども、別の分類の仕方で説明したものが、ここにお示ししているもので、筑波大学の川島先生が使われているオープンデータを使ってどういう価値、価値というのはこれ使う人にとってですね、どういうメリットがあるか、といったようなことです。それによると、8つの分類ができるんじゃないかというふうにお話されていて、こちらの方が分かりやすいのではないかと思います。

また、類型は、事例側からとして見れば、厳密に分かれているわけではなくて、例えば可視化とリアル・タイム型両方兼ねているものもあります。元の川島先生の元々の議論では、海外の話から抽出されていますが、日本でも、事例として60数事例程度ではありますが、この8つの類型に近いと思われているものが徐々に出てきていることを理解できればよいかと思います。

可視化型を例に

最初に書かれている可視化型を例にしましょう。データの見せ方を工夫して、はっと分かる形にするものです。次回の授業でみなさんにも実践いただきますが、可視化によってデータが何かに変わるわけないですが、見せ方を工夫することでよりよく分かるということはあると思います。

事例としては、オープンデータ100の一番最初に出ている消火栓ですね。

住所とか場所を聞いただけで、パッと分かる人って、たぶん地元の人だけだったりします。地図上に消火栓がある場所を示すだけで、その場所と自分の今いる場所とどれぐらいの距離があるか、それと我々が持ってる空間把握能力というもの、つまり住所も土地勘があれば別ですが、そうでないときは皆さん見知らぬ土地に行ったときに、スマホでGoogleマップなりあってですね、道順を探したりするのが当たり前になっているというものです。

消火栓がここにあるっていうことを示すためには、住所が書かれていると確実なんだけど、どの辺にどうあるのかっていうのが俄には分からないので、それを地図上に置くものです。それで、たくさんあるのか少ないのかという量的な把握もできる。

そういった意味で、これは会津若松市の事例ですけれども、事例の中にも書いてあったかと思いますが、豪雪地帯なので消火栓が雪に埋もれていることがあって、いざ何かするときには分からない。ただもちろん消火栓を示す看板が立ったりするんですけれども、すぐ見つけないといけないというときに、地図上に落としていれば、誰でも見ることができるというのが肝だったわけです。

4. 機械判読性とは

「お馴染みの表」と較べてみる

続いて、今日の本題の機械判読性です。定義では「コンピューターが使いやすい」といったようなことを言っています。

「コンピューターが使いやすい」っていうのは、アプリケーション、これスマホであれば、皆さん使っているスマホのアプリっていうものでもいいですし、もっと広くエクセルとかですね、でもいいですし、何かプログラミング言語で読み出したりとか、加工するといったようなこと、そういったものに転用しやすい、利用しやすい性質のことを機械判読性としておきます。

左の方のやつは、エクセルとかで作るやつでお馴染みの表ですね。

説明にある通り、我々人間はこれ見て一番左のところが2018年のことを示していて、その右隣に上から下に1 2 3 4と書いてあるのは、その一番上に、月と書いてあるので、1月2月3月4月と連続しているもの、そしてその右には、A市B市C市D町とありますが、この列の数字は何でしょう。気温でしょうか。何となく分かりますね。もちろん表の見方は多少の慣れは必要なのかもしれませんが、人間はどういったものがあるかは、何となく分かります。しかし、コンピューターにとっては簡単には解釈ができないものです。

一方でコンピュータ上で使いやすいって言われてるのは、この右のやつです。
順番に1行単位でしかコンピューターは見れないので、まずこれラベルとして年、月、A市、B市…と順番で並んでいるものがあって、その下が、2018年のことである、1月ことである、と順番に行ごとに見て処理をする。それをこの場合はカンマで区切る、もちろんスペースとかですね、他の文字で代替することはありますが、よくあるお作法としては、カンマで区切る。

いろいろファイルを触っている経験がある方であれば、いわゆる右はCSVファイルと言われているものは、カンマで区切られたテキストファイルで、これをエクセルで開くと、左の表のように、2018年は各行に2018と入っているもので、罫線も実はないのですが、罫線があるように見えます。

昔は、これらは手書きで作業をしていて、今はパソコンで作業をしています。左の方が使いやすいから、我々はその形でデータを処理、取り扱っているのが通常ですが、コンピューターが扱う意味では異質なものであることを理解しましょう。

「ネ申エクセル」？

次に、データを利活用しようという話が出てきたときに、「神エクセル」という話があります。「神」は一番偉い、としてネット社会の言い方でダブルミーニングだと思いますが、データ処理に不向きでしかもそういうものを作るのに時間がかけて無駄な書式であるものとされています。

この問題を一番最初に取り上げた奥村論文では、「神」を「ネ」と「申」をつなげて「神」と読ませる、その現象が「神エクセル」そのものであり、こうした言葉と文字の使い方はある意味で特徴的なものですが、問題設定がなされました。

こうした「神エクセル」は、次から次へと新しいものが出てくるので、どうしたらコンピューターにやさしくできるのか、という方法も編み出されています。どんどん「神エクセル」の問題が言われていますが、文句を言っていても実務は回らないので、「傾向と対策」として、どうにかしようという考え方も重要です。

簡単な事例としてご紹介するのは、第3回のRPAの事例で出ていた決算統計のものです。これは総務省がこれで決算統計を作成しなさいと言ってくるものです。実際は、「神エクセル」と言われているもの、そして「方眼紙エクセル」と言われる列の左の方にあるような「通常の列の幅」より狭くして、紙で出力したときに見やすくするために調整して、紙の帳票のようにしています。

このようなものが山盛りになっている様式なんですが、機械判読性が欠ける形で1800余りある自治体すべてに配って、このデータを入力してもらって、総務省がどのような費用にどのくらいお金を使っているかを確認しているわけです。こうしたことをするために、他のシステムから出力した数字を転記してそれをチェックして提出するすごい手間をかけています。これは第3回で紹介したものです。

これを機械の視点で見ると、このスライドで囲んだところは「使いにくい」、つまり「データ処理に不向き」というもので、これをどうするか、という話です。

機械判読性を自分の手で確認する

そうは言っても、機械判読性はいろんな観点があります。この授業が目指す方向性で考えると、当然「自分の手で確認する」ことが大事な訳ですから、その観点で説明しましょう。

まず、「そもそも人間が理解できるか？」です。オープンデータのテストサイトにそれぞれデータをアップロードしていただきました。他の人がアップロードしたファイルを見てみましょう。もともとは、機械判読性という意味ではなく、フラットな状態で「どういうデータだったらいいのか」という観点で考えてアップロードしてください、と申し上げました。

そうですので、テストサイトにログインして、他の人のアップロードしたファイルを見てみましょう。

まず、「別の人の作ったファイルの意味・意図が理解できるか？」です。同じ表のようなものでも、数字を縦に並べたり横に並べたりしていますね。また、よくあるのは「2018年」と書いてあるときに、それが暦年なのか年度なのか、といったことがありますね。それは、普通は「年」と書いてあるから「2018年暦年」だろう、そして、1月から12月まで書いてあるから、たしかに暦年だろうと。

でも、4月からスタートしていたら、「あ、これは2018年度のことだ」という理解をしますね。我々は、他の知識と組み合わせて理解するのですけども、そういうことをして理解する、ということは、やはり「他の人が作った」ことに起因するものですよね。

次のこれは、統計書から取ってきたものですかね。これはこれとして分かるんだけど…というものですよね。

次のは、CSVで作ったものを使っているようですね。市町村ごとに病院の数とかが並んでいるものですね。

次は、入力いただいたものでしょうか。これも、我々は分かるけれども、どうでしょうか。

例えば、「河原町」と言ったときに、我々はJRとか京阪の駅名ではないということを知っているので、阪急の駅なんだな、もちろん表にも書いてありますが、「縦持ち・横持ち」のデータということで来週の授業でも紹介しますが、もう１つ列を作って、阪急・阪急・京阪・近鉄…、次の行には烏丸・河原町・丹波橋・近鉄丹波橋…というように路線名を書く方が分かりやすい、横に見ていく「横持ち」をするのではなく、縦に見ていく「縦持ち」が、機械にやさしい、使いやすいということが分かりますので、そういうことを考えて作る必要があります。

逆に言えば、そのようなルールがないと理解できないということかと思います。理解できない、というのは、ここの文字・数字を動かしてやらないと次のステップである「データを活用する」というところにすぐいけない、いくのに一手間かかっているということになります。

機械がどう読んでいるのか？

ここまでは、普段からいろいろなデータを見る、そういう観点でデータを見たことがないかもしれませんが、データをいろいろ見てそれを組み合わせる必要があり、それには時間がかかるということでした。

それでは、次に「機械がどう読んでいるのか？」という話です。

オープンデータの世界では、次のようなやり方でどうしているのかを確認できます。一つはAPIと呼ばれているApplication Program Interfaceと言われるものです。説明するより、実際に動かした方が早いですが、APIを整備して、サイトからデータを取り出すためのルールを決めていて、そのルールに則って操作をすると望んだデータを取り出すことができるものです。

どこにでもある世界になっていますが、RESASでもAPIを整備して例えば、ある都道府県のある年の人口を知りたい、となったときに、RESASの画面を操作して画面でそれを確かめることもできますが、APIで整備されたルール通りに（よく「APIを叩く」と言います）コマンドを打てば、数字がとれます。それは京都府のオープンデータのカタログサイトでも同様のことができます。

もう１つ最近整備が進んでいるのは、SPARQLエンドポイントと呼ばれる、SPARQLと呼ばれるデータベースの設計の１つで、そのルールが整備されていて、コマンドもそうですし、それに対応するデータも整備されていて、様々な使い方ができるようになっています。有名なところでは、総務省統計局のサイトもそうですし、京都市や福井県鯖江市のオープンデータのサイトといった自治体のサイトでも整備してデータを取り出すことができます。

オープンデータの段階

それでは、なぜそのような方向性になっているのかと言えば、前回のオープンデータの説明ではあまりしていませんでしたが、オープンデータの段階として5つの段階があると言われています。左の表に段階とありますが、「1つ星」「5つ星」と言われているもので、公開の状態を示しているもので、5つ星が一番よいものとされています。今回みなさんがアップロードされているもので言えば、例えば駅乗降客数のデータではPDFでしたが、これはそれしかなくてアップロードをまずしてみた、ということかと思いますが、このPDFなりJPGというデータ形式では、とりあえずブラウザやソフトで見ることができるとされているものです。

そこから先は、さきほどのデータでも、XLSのデータもあったかと思います。これも、コンピュータで取り出すことができるけれども、マイクロソフトのOfficeや互換性のあるソフトでないとデータが取り出しにくい、処理はできるけれど、万人ができるか、Wordとかがない人にはアクセスができない、といった意味で2つ星とされています。

さらに先には、全国的にも3つ星段階のファイルがオープンデータとして公開が進んできていますが、XMLはデータベースのものなので、CSVで説明すれば、これはテキストですのでテキストエディタと呼ばれるどのOSでも標準的に搭載されているアプリケーションでアクセスできるので、「オープンに利用できる」とあるのは、使っているコンピューターの環境に依存しないという意味で、言われているものです。

そこから先は、難しくなりますが、表の下に説明があります。

先程の駅のデータで説明していた「河原町は駅名である」と、我々は別の知識で補完して理解すると言いましたが、ここではそれぞれのデータがお互いどう関係しているか、語彙という言い方をしていますが、いわゆる意味を定義するということで、世界各国で標準的な辞書を作り始めていて、日本でもそうです。そういう意味で関連付けられたファイルをRDF、さらに他の語彙と連携しているLinked-RDFといったものがあります。

人間だったら補完できるんですけれども、コンピューターで処理するためには、そこまでしっかり決めておかないと正しくないっていうふうになってしまうので、それをちゃんと担保するために言葉の定義をしっかり決める。そういったものとしてデータを用意するっていうのが、五つ星と言われているグレードのものです。まだ、このところはもうお分かりになるかと思いますが、すべてきちんと決めないといけないですね。さきほどカタログサイトでみなさんを掲載いただいたものもそうですし、京都府のオープンデータのサイトを見ていただいたと思いますが、そういう形で運用・整備しているところは、まだ少ないわけです。

なぜ少ないかは「それを使ってないから」っていうことになると思いますけれども、目指すべきは5つ星であるという考え方の方もいらっしゃいます。他方で、どのパソコンでも見られるようにすることが重要だという考え方もいらっしゃいます。

そうした中で、とりあえずテキストファイルとして標準的に読めるようにしておこうという3つ星の段階が日本の自治体では広く見られるところです。

5つ星にするには、きちんとシステムを整備しないといけないのですが、それは予算もないところで取り組めない訳です。他方で国の方針で2020年度末までに全自治体がオープンデータに取り組むように言われていることもあって、まず3つ星でデータを出していこうとする自治体もあります。

京都府についても、全市町村でオープンデータを公開していますが、まずはCSVファイルを用意するところから始めています。

その際、オープンデータを進めるということは、本来は先程の表のように、最初から5つ星を目指していく、それをどうやっていくかという問題構成になっているのですが、次は、実際にはそうならないのだ、いう説明をします。

実際にAPIを叩いてみよう

「実際に」ということを考えるために、「そもそもどうやってデータを取り出すのか」ということを理解することが必要です。実際にやってみるとどうでしょう。

ブラウザで

カタログサイトではクリックしてブラウザ上でアクセスしていましたね。普通はそうします。ホームページや、スマホでもそうですが、アクセスするためにはリンクを辿っていって、クリックをして閲覧したりダウンロードしています。そうしたものをソフトウェアで加工したりしているわけですね。

しかし、「コンピューターで読める」とは、そういうことをする必要はないです。オープンデータのカタログサイトで言えば、APIで説明したように決められたルールでコマンドを打てばデータを呼び出せる訳ですので、オープンデータカタログサイトでは、APIを標準搭載していて、この資料のリンクをクリックしていただくと、ブラウザによってはちょっと文字化けするかもしれませんが、京都府のオープンデータのカタログサイトに載せているデータセットの一覧を呼び出すコマンドを書いています。
（参考）APIの使い方については、京都データストアに説明があります。

データセットの数は約480なのですが、ここではデータセットの中にあるリソースそのものを読み出していて、それが1万ファイルぐらいあって、それを全部呼び出すことになるので、パラメーターとして最後に”limit”というもので最初から5つ分だけ見せてっていうふうにしています。

表示されるこの結果は、我々にとっては「うーん」となります。というのは、データセットの一覧は別にファイルでもあるわけで我々はそれを開いて見ることもできます。結局、やっていることはそのファイルをいちいち開かなくてもよいというわけです。ですので、ブラウザで見ると、「何が違うの？」となるわけですね。

Excelで

では、ピンとこないであれば、EXCELでやってみましょう。
EXCELにはPower Queryエディターという機能があって、それを使えば同じことができます。Query（クエリ）というのは、サーバーなりに問い合わせをして情報を取り出すことを言いますが、このPower Queryを使って、APIのリクエストを打ち込むとEXCELで取り出したデータで作業ができます。

その意味は、クエリの実行でデータを取り出すことができますし、サーバー側でデータが変われば、更新を行えば自動的にデータが更新されるわけです。これは何が違うのか。

それを考えるには、行政の現場でも、エクセルファイルで管理しているデータで、何かデータの更新をするとなったときに、行を追加して転記して、間違っていないか確認して…というのがよくあることを理解する必要があります。若手の仕事としてよくある訳ですが、クエリ機能を知ったみなさんは、そうした行政の現場で行われていることが、なんて無味乾燥な作業なんだろうとお感じかと思います。確かにそれはそうです。

みなさんがパソコン上でクリックしたり入力したり、それを目で見たりすることとコンピューターの世界では同じことをしているわけです。さらに言えば、ルールが決まっているということは、今回はAPIのリクエストの文字をコピペしましたが、これもリクエスト内容はルール化されているので、これも自動化できることになります。

APIを操作することの意味

そして、データの中身そのものは、今回は詳細は説明しませんが、オープンデータのサイトが用意する機能を端的に言えば、直接データの中身にアクセスすることができるとことに尽きると思います。

例で説明しましょう。
犯罪発生状況というオープンデータがあります。

今後改修を予定するカタログサイトでは、APIが整備されていて、さきほどCSVファイルのプレビューがありましたが、今後はファイルに直接アクセスができるようになるわけです。そうするといちいちダウンロードして…というのではなくてよくなります。

みなさんも、エクセルファイルをダウンロードして、必要なデータを探すということをするときに、ソート機能を使って必要なものを選んでいくといったことをすると思いますが、大量になったらやりやすいでしょうか。

機械判読性ということは、そのデータを取り出したいということを、任意にできるということが重要なわけです。それを可能にする機能がAPIというものですね。さらに言えば、京都市のオープンデータサイトで搭載されているSPARQLエンドポイントでも操作ができます。例えば、データ一覧を欲しいとなったら、これまででは、コピーして、右クリックしてリンクを貼り付けるみたいなことを手でやる必要があるのですが、これを使えば、自動的にできるわけです。

以上の議論をまとめると、「二次利用可能」というオープンデータの定義の意味は、こうしたオープンデータのサイトに搭載されている機能を、しっかり使うことでデータがもっと活用できるということが期待されており、そのためにオープンデータのサイトは運用されている訳です。

5. 機械判読性の射程

そうしたことを、もともと法律でも書いていますよ、ということです。
それをここでは「機械判読性の射程」と言っていますが、ここまでこだわっていうのは、相互運用性というものについて考える必要があるからです。

官民データ活用推進基本法等における規定

官民データ活用推進基本法において、第15条第2項に次のように規定されています。

第15条
第1項　国及び地方公共団体は、官民データ活用に資するため、相互に連携して、自らの情報システムに係る規格の整備及び互換性の確保、業務の見直しその他の必要な措置を講ずるものとする。
第2項　国は、多様な分野における横断的な官民データ活用による新たなサービスの開発等に資するため、国、地方公共団体及び事業者の 情報システムの相互の連携を確保するための基盤の整備 その他の必要な措置を講ずるものとする。

とあり、それを受けた基本計画（世界最先端IT国家創造宣言・官民データ活用推進基本計画）では、以下のように記載されています。

官民データ流通の基盤となる、データの標準化(語彙、コード、 文字等)やAPIの連携、認証機能等による分野横断的なサービスプラットフォームを整備する

この相互運用性が法律に登場しているのは、議員立法である基本法の元になった自民党の報告で示されているところに注目しましょう。「官民のシステムの相互の連携を確保するために」と言った際に、行政は、所掌する観光やインフラなど様々な政策分野があり、それぞれ事業者もビジネスを行っています。そこに「業界標準データ」とあるように、分野別、今回のデータ活用と言った際には、この図で示されているような分野ごとに「サイロ」になっている現状があります。それをどうにかしようというよりも、まず共通になっている部分、さきほどのようにAPIでデータが取り出せるかどうか、共通語彙基盤と言われる「同じ言葉を書いていたら、業界は違っていても同じものだと安心して使える」ということを確保するために、共通部分を整備しましょうというものです。そして、この点が国なり事業者においてー自治体はどこまでできているかはありますがー広く「行政のデジタル化」と言われるときに狙っているところです。

今日スタートとして、行政ではどうやってますか？というお話をしました。行政の現場では、ああいうデータを作っている訳です。「人件費」という部分は、スペースが入っていても、我々はつなげて「人件費」と読めますが、コンピューターでは「人」「件」「費」となります。人件費の言葉の定義を決めて、コンピューターで共通して取り出せるようにしましょう、ということをすれば、庁内でも同様に普段やっている業務が効率的に扱えるはずです。

その上で書式の話に限らず、そもそもデータを持っているやり方そのものは仕方がないとして、共通部分はきちんと整備していくことによって、法律が狙っている新しいサービスの開発等に資するように、システム相互の連携を実現するための取り組みを進めよう、というのが現時点での方針な訳です。

それがまだまだ全然できていないよね、というのは、オープンデータのデータの中身を見たときにそうなっていませんでしたね。ですから、方向性としては出ていますが、それをどうやって進めていくかということが、大きな論点になります。

相互運用性

その際ポイントとなる「相互運用性」interoperability、は海外では定義がはっきりしていますが、ここで重要なことは、なぜそれが重要かです。
資料にあるとおり「相互運用性が大切な理由は、さまざまなコンポーネントを組み合わせて使えるようになる」から、という「つなぎ合わせて使う」というものです。

また、「相互に使える」ということは、台湾でオープンデータでは「開放資料」と言いますが、これを借りれば「オープン」は「開放」なのです。「公開」ではないことに注意が必要です。異なるコンテキストの人たちが相互にデータを使うことができること、「どうぞデータを使ってください」だけでなく、「定義として間違っていない言葉が使える」ことを保証するという意味です。法律の中にもこの意味で使われているわけです。

オープンデータで難しいのは、こうした意味が分かりにくいまま、また、オープンデータと情報公開の違いで前回指摘したように、別の大学で授業をした際に、学生から寄せられたように「行政は自分の都合の悪い情報は隠すのではないですか？オープンデータもそういうものですか？」という素朴な疑問があるからです。

これは、オープンデータの狭い意味での議論ですね。
当初オープンデータが登場した際に、議論のウエイトが論者によってまちまちだったことなど、こうした新しい言葉を受容する際に起こりうるといった、そういう側面があることは否定できません。しかし、ここでは「行政のデータをどのように活用することができるか」ということが議論の中心ですし、官民データ活用推進基本法が目指す世界観で考えましょう。

さらに、別の観点から言えば、「オープン」という意味については、総務省の「ICTスキル総合習得教材」の資料が、これにわざわざ言及するという意味も含めて理解しましょう。また、公共政策大学院で学ぶ皆さんにとっても、「オープン」の意味は、やはり前者の狭い意味で理解することが多いでしょう。

しかし、オープンデータの理解、その活用を考えるときには、機械判読性が肝でして、その内容がここで説明した相互運用性があり、そのデータのレベルでの中身、授業では支障事例の形で説明しましたが、現場レベルでどこまで浸透しているのかが課題になっていることを理解いただけたかと思います。

オープンデータが説明する「データとアプリの分離」

そうは言っても、昨年総務省の研修で府内市町村の担当者にオープンデータについて研修をした際に、講師の方が使われた資料でも注意を促されています。もちろん、それが市町村の担当者にどう理解されたかはありますが、ここでの説明をより分かりやすく言うと、「データとアプリの分離」と言っています。行政の広くサービスという観点から考えても、これは重要な観点です。

これまでは、データも作るし、その上に表示したり使ったりするアプリも一体で作っていました。それだと、データが変わるとアプリ側も自分たちで変えないといけない。これは大変です。一方で、スマホに限った話だけでもそうですが、ネットの情報なりデータを使うことが当たり前になってくるときに、いちいち全部を提供する側が用意するんでしょうか？、それはよくないですよね、費用的にもそうですし、サービスをよくしようとした場合に、全部抱えていると費用でできないなんて理由になってしまうのはよくないことです。

行政がアプリもデータをセットで出すのではなく、行政ももちろんアプリも作りますが、いろんな形でアプリを作る。一つの大きなアプリではなく、この図では5つのアプリができています。ここで言いたいことは、1つの行政のアプリだけでなくて、官民データとあるように、民間のデータも組み合わせる。冒頭で紹介した100事例でも、そういう説明があったかと思います。

そういう観点で、行政側にオープンデータで期待することは、行政はデータホルダーとして非常に大きな主体です。こうした様々なアプリを通じて提供されるサービスに転換するために、行政サービスもアプリとデータをセットとしてではなく、データを出してほしいということです。つまり、民間も、あるいは地域の人たちという意味も含めて、それを行政サービスというかは別として、様々なサービスを作りうる現在において、1つの大きな主体である行政も、相互運用性を促進するための活動に、もっと参画してください、これがオープンデータの話だと理解しています。

そして、開放資料、また、オープンデータの分類で紹介した川島先生の話でも「オープンデータは運動論」ともおっしゃっています。何か決まったことをするべし、という性質のものではなく、それによって考え方を変えていくような取り組みという意味であって、金科玉条のように扱うのではなくて、それによって何をするか？できるか？ということを考えるために「オープンデータ」という言葉を持ち出しています。それが、ようやく法律にも書かれるようになったこと、その元になった政治家の理解も深まりつつあるなど、それが集約されつつあるのが、100事例で示されているということかと思います。

6. アプリを作る

以上を概論だとして、そうした世界はどのようなものか？
アプリが作ろうということですので、みなさんも手を動かしてそれを理解してみましょう。

Glideでアプリを作ってみる

Glideというサービスにアクセスしてみてください。
https://www.glideapps.com/

今日は1つの作り方をお示しするだけですが、Googleで検索するといろいろなものが出てきますのでのちほど参考にしてください。

「アプリって、専門の人たちのものでしょ？」と思わせておいて、「いやいや自分たちで作れるんですよ」ということが肝です。

先に作っておいたものをご覧いただきましょう。URLを入力いただくかQRコードスマホで読み込んでみてください。
https://emergency-hospital.glideapp.io/

Googleアカウントでログインすると、アプリを作る画面になります。ここでGoogleドライブに格納しているスプレッドシートを自動的に呼び出して表示されますので、そこから使うデータを選択すると画面上にそれっぽく並べてくれます。

ここから先は、タイトルをどれにするかなど、実際に自分で変更しながらアプリ側がどう変わるかがすぐ反映されます。住所であれば、Googleマップで表示するといったこともできます。試しながらやっていくと分かるかと思います。

データで何ができて何ができていないか？

今回のアプリは何かの一覧をリストで並べて選択して表示するといったごく簡単なよくあるスマホアプリの一種です。ここでは無料でできる範囲で作っていますし、作成自体は30分程度だったかと思いますが、それで一旦は完成です。ここでは、完全に完成することが重要ではなくて、まずは一旦作ってみる、これを可視化とまでは言いませんが、「どういうことができるか」ということが理解できること、これが重要です。

そして、お気づきのように、みなさんがこれまでアップロードしたデータで、このように簡単にアプリになりますか？ということを考えるとどうでしょう。

今回のアプリでは、不要な列を削除して、画面でコネコネするとできました。では、アップロードした、例えばPDFのデータではどうでしょう。また、1つのファイルだけでなくて、他のデータもあった方がいいね、となったときに、どこからどういうデータが取り出せるか、一旦作成したアプリにどのように組み込めばいいか、ということを考えるかと思います。

こうしたことが、無料のサービスとオープンデータのサイトを使うことで、誰でも使えてしまう、第1回授業で申し上げた言葉では「テクノロジーの民主化」と言いました。また、今回は京都府のオープンデータで作ってみましたが、この病院の一覧を知りたいとなったときに、紙で持っておくのではなくて、アプリのURLを持っておけばいいわけです。自分のスマホで素早く調べられる。

こうした説明ですが、こうしたことができるということは、私はなかなかいい世界だなと思います。みなさんも、興味を持ったら、京都府のサイトでもいいですし、他の自治体や国のオープンデータでもやってみるといいと思います。この授業でも、資料や動画のリンクを紹介していますが、それを一覧にすれば、復習用にすぐアクセスできるアプリになったりもします。大学が用意する授業補助システムがありますが、どうでしょう。自分なりにカスタマイズできる方、パソコンで見るより、スマホでアクセスできる方が使いやすかったりしませんか。

こうしたことができると分かったときに、では自分が作ったデータに何が足りないのか、はっきり理解でき、言語化できるかと思います。それが重要な訳ですね。

7. まとめ

それでは、今日のまとめです。
今日説明したことは、機械判読性という言葉を手がかりに、データの運用について説明しました。オープンデータを運用するということは、2つのことでまとめられると思います。

機械判読性の確保＝縦割りの排除

1つは、データのあり方、オープンデータとして提供することを前提だとしてたとき、多くの人に活用してもらうための「公開」ですが、これは庁内においても言える訳で、私は、まずはこの庁内利用を重要なポイントだと考えています。そのために機械判読性を確保するということは、抽象的な言い方ではありますが、まずはデータを扱う環境を共通化して、お互い異なる分野のデータも使えるようになることで、ゆくゆくは縦割りの排除につながっていくことだと思います。

各事業部門は、自分たちのテリトリーで業務を完結させがちで、他の部門の政策課題や事業の内容については、気になるはずですが、それにアクセスするためのデータがもともと共有されていないという問題とがあります。

それをオープンデータの話で実現するというのは、一見迂回しているように見えますが、これはオープンデータの理解を、今回述べたような形でできれば、庁内に限っていっても業務の効率化、またその先には違う分野の政策分野における課題の発見、それによって別の分野との課題共有に基づいた施策立案、新たな課題解決につながることが期待されているはずです。それが現状どうかという点は、心もとないことではありますが、オープンデータというものが登場して、カタログサイトが設置されていることは重要なターニングポイントです。

「真心のこもったオープンデータ」？

次に、実務者間でも議論になっていることは、とは言っても、ホームページでの公開とどう違うのか、ということです。これを従来型と呼べば、従来型の思考でして、行政なので情報をオープンにしないといけない、ということは、この20数年でこうした話が随分当然になってきたものです。隠すことはできないだろう、むしろ積極的に公開しようという、そうしたマインドセットになったことは好ましいものですが、それが行き着きたところが、「真心のこもったオープンデータ」ではないか、というものです。そのためにオープンデータが進まないという矛盾した事態にもなっています。

京都府でも、庁内に「データ出してね」という検討をしています。そのままの形で出すと恥ずかしいのか、あるいはオープンデータの定義で機械判読性があるもんだから、別途データを用意して手作業で転記したり、ここまで載せたらいけないかなと協議してから公開するといった手順を踏んだりしがちです。「せっかく出すからには、しっかりしたもので出さないといけない」と行政は考えがちですが、オープンデータの世界からすると、過剰品質になります。

さらにいびつな話なのは、今あるデータそのままのでいいのであれば、オープンデータ化によってそれを加工する人も出てきます。また、さきほどアプリの作り方のイメージをお示ししましたが、ここでいう「過剰品質」にしなければアプリにしにくいのではないか、と考えてしまう。こういう話は、「機械判読性」や「相互運用性」から見たら、いびつであり、場合によっては行政側が考えるようなことではないかもしれません。例えば、データの加工が必要なのであれば、それは端的にはそれを含めたビジネスモデルを考えればよい、それ自体は行政のやることではありませんと言えます。

一方で、過剰品質にこだわるがために、もともとのデータがそのままになってしまう。最終的な活用を想定して、そこまで加工する過程に着目するのではなく、そもそもオープンデータの形でデータを扱って様々な形に変換するという仕事をするべきなのです（ワンデータ・マルチユース）。普段使っているソフトにそうしたことを前提とした機能がある（シートを分ける、関数によって変換するなど）、そういうことに気が付かない。年度が変われば元のファイルを更新して、オープンデータとして転記して公開する、それはオープンデータの状態で仕事をすればなくなる話です。

さらに、相互運用性の考え方でオープンデータを作っていない、そうしたことも考えていない。すると、過剰品質と相互運用性双方からかけ離れた実務が奇妙にも共存するという実態を見ると、今日述べてきた意味でのオープンデータに関してまだまだ消化不良になっていると考えられます。

法律にしっかり書かれ、各種資料にもまざまざと書かれている中で、そして授業でアプリが簡単にできてしまうこともお示ししました。そうしたことが、行政の現場にしっくり来ていない。そういうことを指摘するのは簡単で生産的ではありません。むしろ、こうした授業なりでみなさんに説明したり、今日も自治体職員さんに来ていただいていますが、実際に見せるということがまずは重要なんだろうと思います。

とはいっても、考え方としてどうするのか？
そこは説明の仕方としては、「新しい枠組み」だと説明する方が理解しやすいのかなとも思っています。ですから、自らの業務はオープンデータをベースにした業務にしていく、それが法律にも定められたのです、という説明も可能だと思います。

どちらの説明でもオープンデータは理解可能な概念として成立しています。ですので、そういうことは分かりにくいのか、人によって使い分ければいい話かどうかはあるかとも思います。しかし、そこは私も実務を5年やっていて感じることは、不幸にもこの両極端な共存のまま業務が成り立っている中で、それを変えないといけないと考えるマインドセットを新たに持つのか、あるいは今までモヤモヤしていたことが説明されるとすっきりする、という形になるか、どっちで説明しようかという話でした。

オープンデータが示した思考様式をどのように使うか？

次に、入り口としての「データの生成」を次の「データの運用」にどうつなげるか？という問題構成だったとまとめると、もう1つ説明したのは、「データの活用」側から、どう考えるかというものでした。

この観点からは、自治体の現状を見ると、アプリのことのようにまだまだ実務には知られていない、またエクセルのようにまだまだ神エクセルが当然のような業務でやっているものでした。

データ利活用スキルを身につける

そうすると、データ利活用をするためのスキルを身につける必要があることが当然ですが、現状でもIT研修というものが用意されていたり、書店に行くと自分で勉強できる書籍がたくさん出ています。どちらにしても、最初はいいとして、これは我流にしかなりません。得手不得手があるかもしれませんが、これから社会に出る学生さんにとって重要なことですが、最初に覚える仕事のやり方が、その後の自分の仕事のやり方を規定してしまう可能性が高いです。

今日の「オープンデータ」の「オープン」という意味でお分かりのとおり、「我流」というものとは相容れないものです。むしろ、みんなのやり方に合わせるという指向性を持ったもので、それが一番いいだろうというものが、一定の経過の中で、決められてくるものです。インターネット上のサービスを考えればいいと思いますが、いろいろサービスが登場してきて、その後淘汰されていく。RPAの回でも申し上げたとおり、どんどんよくなるサービスに合わせて仕事をしていく、サービスがよくなれば、仕事も勝手に生産性が上がっていくというサイクルに業務を再設計するという考え方ですね。こうしたものは我流で目指しているものの近道なのです。ただし、ITといった話になった途端、こうしたことが逆転して理解されてしまうことは十分考えなければならないと思います。それは個人単位でも起こることですし、さきほど「サイロ」と申し上げた、各分野なり部門別の中で独自に積み重ねるようなものもあります。これもRPAの回で申し上げたように、各分野なりにそれぞれビジネスモデルを構築している事業者がいて、相互運用性を妨げている面もあると思います。

それをどのように崩すか、いきなり全部を崩すことは難しい訳ですが、ここで申し上げている「オープンデータが示した思考様式」とも言うべき、考え方が変わってしまったこと、私などはこちらの方が楽だなと思っていますが、この切り替えが困難なのだろうと思います。

国もオープンデータ研修を自治体向けに実施する、これは2020年度末までにすべての自治体でオープンデータを公開するという目標があるからですが、オープンデータを公開し継続することは、今日の授業で申し上げたような観点からは、その研修内容もまだまだ改善しないといけないと思います。

座学的なものを最初に取り入れ、みなさんが思い浮かべる「オープン」に近い話をしています。そうではなくて、アプリをみなさん作ってみれば、「オープン」の意味は一目瞭然ではないかと思いますが、学びという意味では「あ、今までのやり方ではこういう点でよくないんだな」と気がつくようなことの方が意味は大きいのではないかと思います。まだ、そういうカリキュラム構成になっていないことは残念なことだと思います。

デザイン思考から見たアプリ

また、さきほどのアプリもそうですが、すぐできたと申し上げました。では、具体的には、病院のリストを公開しているアプリで、実際に使うときのことを考えてみましょう。近くの病院をどう探すか。これはアプリをどう作るかという観点で、考えるべきことが多いです。

現状は一覧をずらっと並べていますが、これが完成だとは思いません。第2回のデザインのところで説明しましたが、こうしたアプリを使うときはどういうときだろうと考える必要がある。例えば、ページの遷移は一覧と詳細という簡単なものになっていました、これは無料バージョンだからこうした機能のみというものでしたが、サービスをよくするということを考えるときに、現状のものが最良ではなくあくまでスタートです。そこからどうやってよくしていくかは、デザイン思考も含めて考える、これはまずそうしたことを知ること、実際にやってみることから始まるのではないかということを申し上げたかった訳です。

最後に、第10回の授業で議論しますが、「自らも作れる」ということを考えたときに、「それはどういう人なのか」を考えるという点です。そういう社会になることを期待して法律ができている訳ですが、そうした人との対話、とふわっと言いますが、オープンデータは公開したあと、どういう形で使うかは問わない（2次利用可能）というのが、定義にありました。「好きに使う」とはなんだろう、そういうことにどれだけ想像力を働かせて、対話できるかという観点も重要です。

では、次回の授業について若干説明します。
次回は、5回シリーズの3回目として、可視化の話をします。今日の授業でも少し出てきましたデータの形式（縦持ち・横持ち）、あるいはデータの列の削除や追加といった前処理など、手を動かしながら理解いただくものです。

それを実現するために用意しているのが、Tableauというソフトウェアです。必要なインストールなど準備をお願いします。

8. 質疑

 Q　行政がバラバラでデータを作ったりしているという話だったら、それをまとめていこうという動きがあるのか。

A　バラバラです。ただし、分野によっては標準的なものを示して、それをシステム化するというものも、例えば住民基本台帳や厚労省所管の事務なりで出てきています。システム化をするということは、業務の手順が決まってくるわけです。そこには恣意的な判断を排除するといったことも含めて効果があるわけですが、それをそのまま受け入れて対応する自治体はまだまだ少ない。

というのは、これまでのやり方を維持する部分を追加したり、それには経緯があるということで存置ということが行われがちです。また、標準化されたシステムと言いましたが、自治体側で言えば、そうした業務フローを設計するということに慣れていないということを示してもいると思います。それはトレーニングしていないからですし、それには一定に実務を経験しないといけない、でも現場が回らないからできる人がやることで我流に変質してしまう、標準的にできる人が育たない、あるいはシステムを開発するベンダー側からの事情もあると思います。

こうした三位一体のような関係に、トレーニングから入るといっても、その後その人が異動したら元の木阿弥みたいな話が繰り返されます。そうしたことを排除することが標準化であるはずですが、そうではない面が大きい

事務が多いのは市町村ですが、こうしたことを担う職員がそもそも減ってしまい、取り組むための時間がない、目の前のことにかかりっきりで、気がついたときはもう遅いということです。行政の実務は連続したものですので、ガラガラポンは難しいですし、企業も含めたデジタル・トランスフォーメーションと言われるものも同様の傾向です。

Q　アプリについてだが、現状どの程度使われているのか。また自治体側はそれをフォローできているのか。

A　いくつかあるのは、100事例のとおりで、これは期待している程ではないというのが現状ですね。また、難しい問題として、そもそもオープンデータはデータ提供側への報告義務はないわけです。ですのできちんとフォローしにくいものではありますが、これはデータ提供側と利活用側がコミュニケーションをどう図るかというものではないかと思います。

また、さらに難しいのは、京都府のオープンデータだけを使うというものではないことが多いということです。そうすると、アプリ側から京都府へコミュニケーションをとってほしいと考えることは、多数のデータ提供者のデータを扱う中で、おこがましいのではないかとも思います。そのギャップは、オープンデータの性質がそうであれば避けられないものですね。

Q　コミュニケーションをとるというのは、具体的にどういうものか。

A　運用する段階では、APIでデータを取り込む訳ですから、その手順には京都府のAPIで使うとなるわけです。作るときはまず探すということはありますが、動かし始めるとそうしたことを意識しなくてもデータが更新され続けるということが重要なわけです。更新されていく中で、アプリに不具合が出た、データに欠落があったということ、あるいは追加なりこういう形でデータを出してほしいという段になってコミュニケーションが出てくることが多いです。

こうした話を進めていくと、自治体ごとにデータを公開して使ってもらうというような話も考えてみればおかしなことで、例えば国が一括してデータを提供できるようにすればいいではないか、といった議論が過去あったように聞いていますが、最近はなんとなく都道府県単位という議論がある程度であまり進んでいるものはありません。もっと言えば、分野ごとという話もありましたので、こうしたカテゴライズなりコミュニケーションで何が正しいかはそもそも難しいものでもありますね。