読者です 読者をやめる 読者になる 読者になる

「ステュディオス」な生活

「ステュディオス」=何かを面白がり、熱中することにより生き生きしている状態。 日々の「ステュディオス」を求めて…

災害に関わる「言い伝え」をマッピングしてみた

今日は大晦日。2016年も残りあと数時間。

振り返ると熊本地震、北海道の台風に鳥取地震、そして先日の糸魚川の大規模火災に、茨城での震度6弱と大きな災害が多かった一年だったように思う。

起こってしまった災害をなかったことにはできないが、そこから教訓や今後発生する災害の被害を減らすための知恵を得ることはできるはずと思う。

そのようなことは私でなくても考えていて、公開から少し時間が経ってしまっているようだが、消防庁が収集・整理した防災に関わる「言い伝え」 なる資料が 全国災害伝承情報:総務省消防庁 に公開されている。

そこには資料に添えて次のように記されている。

有史以来、全国で発生した災害は各地に多大な被害をもたらし、それらの災害の教訓は各地域において記録としてあるもの、図画として残されているもの、あるいは物語、ことわざとして伝承されているものなどがあります。  そのような災害にまつわる資料や情報は、これまで国として整理されず今日にいたっており、その多くが各地域に埋もれたままとなっています。  全国災害伝承情報は、そうした各地域に残る貴重な資料を、国として整理集約し、インターネットを活用し広く一般に公開することを目的としたもので、平成16年度から平成18年度にかけて都道府県や市町村などの協力をいただき、調査を通じて収集した情報を整理集約しました。  この情報を通じて、身近な地域に残されている災害に対する教訓を個々人に認識していただき、防災意識高揚に役立てていただくとともに、防災教育用の教材としての活用が図られることを期待しています。

防災に関わる「言い伝え」

防災に関わる「言い伝え」はなかなか興味深い資料で、全国の災害・防災に関する800弱もの言い伝えが一覧でまとめられている。 各言い伝えごとにそれが伝わる自治体名が記されているので地図上にマッピングしてみた。なお、統廃合により自治体が消滅しているものは引き継がれた現在の自治体にマッピングして旧名を併記している。

地図上の色の付いたエリアをクリックすると、その土地に伝わる言い伝えを右ペインに表示する。

防災に関わる「言い伝え」MAP

f:id:HeRo:20161231164740p:plain

地図化したデータを見てみると北海道、東北の日本海側と近畿地方で言い伝えが少ないのがわかる。これらの地域ではもともと言い伝えが少なかったのだろうかそれとも、伝承が途絶え収集できなかったのだろうか。近畿は長らく都があり、大勢暮らしていたはずなのに、どうして少ないのだろうか。 逆に伝承の多い地域は、古くから多くの災害に見舞われてきた結果、地域の知恵として言い伝えが受け継がれてきたということなのであろう。

個々の地域を見ていくと、言い伝えの内容からどのような災害に苦しんできたのかがわかる。水害に関する言い伝えが多い地域は水害に、地震に関する言い伝えが多ければ地震に苦しめられることが多かったのであろう。

栃木県には地名に関する言い伝えが多い。古い地名を見るとその土地でよく起こった災害がわかるようだ。災害の記憶をいまに伝える日本全国「あぶない地名」(週刊現代) | 現代ビジネス | 講談社(1/6)にも同じような記事がある。この記事にあるように安易に地名を変えてしまうのは良くないのではと思ってしまう。

言い伝えの類似性に目を向けると「地震が来たら竹やぶに逃げろ」に類する言い伝えは、全国的に多いのだなぁと気が付く。竹の根が地盤を強固にし地割れを防ぐことができると知られていたのであろう。

また、次のような言い伝えもある。

  • 地震のとき「マンダラッコ、マンダラッコ」と唱えるとよい。(神奈川県平塚市)
  • 地震のとき「マンザイロク、マンザイロク」といって、竹やぶに逃げる。(新潟県新潟市
  • 地震のときは「まんぜえろく」と唱える。(埼玉県毛呂山町

一説によると「まんぜいろく」とは「万歳禄」と書き、末永く神の恩恵を受けられますように、という祈願らしい。 同じような言葉が地域を超えて言い伝えられているのはなぜだろうか? 一見、つながりなさそうな地域で同じような言葉が言い伝えられているのも興味深い。昔は互いに交流があったのだろうか?

雑雑とした印象・感想を綴ったが、眺めていると色々発見がありそうな資料だ。

tingbot アプリを公開してみた

f:id:HeRo:20161011225300p:plain

この所、ちょっと前に届いた、tingbotで遊んでいる。
ひととおり機能を試したので、アプリを作ってみた。

作ったのは天気予報を表示するアプリ。
どこかのAPIから天気予報を取ってきて、それを表示するだけ。 出かける前に傘が必要かどうかが分かる程度でも便利かなぁと。

サクッと実装

とりあえず、情報源として天気予報APIを探さねばとぐぐってみると OpenWeatherMap が見つかった。 3時間単位で予報が取れ、詳細なのだが、海外のサービスなのでデータはすべて英語。 また、APIを利用するためにはアカウントを作って、API Keyを取らないといけないのがちょっと面倒。 アプリをダウンロードした人にもこの面倒をお願いすることになる。 更に天気予報を取得する都市コードを探すのもちょっと面倒そう。

無料で、使用制限が緩くて、登録など不要で使えそうなAPIで、できれば日本語のAPIということで探してみると、 Weather Hacks - livedoor 天気情報 くらいしか なさそうだった。
降水確率が含まれないのは残念だが、手軽さを優先して今回はこれを採用。

Python でコードを書くのは久々なので思い出しながら、作ってみた。

見栄えを変更

最初のデザインはこんな感じ。いたってシンプルな表示。

f:id:HeRo:20161011231152p:plain

Weather Hacks - livedoor 天気情報APIでは アイコンのURLも含まれているので、画面に表示しているのはそのアイコン。 でも、画像サイズが小さく、これ以上拡大して表示すると粗さが目立ってしまう。 文字を読まなくても絵を見てわかるほうが、離れたところからも確認できるだろうと 思ったので、もっと大きく、わかりやすく天気を絵で表示できるようにすることにした。

ライセンスフリーのアイコン集とかを探してみると、天気アイコンをフォントとして公開しているものもあることに気がついた。 フォントのほうが、大きさや色を自由に調整できるのはと思い、天気フォントを探すことにした。

良さげなのは次の2つ。

前者は各天気がひとつづず1文字に割り当てられたもの。 後者は天気要素をばらして文字にしており、必要に合わせて組み合わせて使うもの。

後者のForecast Font は太陽はオレンジ、雲はグレーと塗り分けられ、それらを組み合わせて ひとつのアイコンを作れそうなのが良いなぁと思い、採用。

次はフォントを組み合わせて各天気に対応したアイコンを作っていく作業。 やってみて思ったのは、外国には「晴時々雨」とか「雨のち曇」っていう表現はないのかな?ってこと。 もともとのAPIで取れる天気予報には例えば「雨時々晴」という予報があり、それに対応した天気アイコンが用意されているが、 いろいろ見た天気フォントにはそのようなどっち付かずの状態を表すようなものがなさそうだった。
このような表現は日本特有なのかな。 などと思いながら、少々面倒だったが、APIが返す30種類の天気それぞれにフォントの組み合わせを実装した。

そして公開

さて、ひととおりできたので、公開してみようとマニュアルで方法を確認する。 tingbotでは The Tingbot Oceanというサイトで、tingbot アプリを募って公開している。

ここに自作アプリを公開する手順は次の通り。

  1. 楽しいor便利なアプリを作る
  2. アプリのソースにicon.png と言う名前でアイコンを追加する(なくてもアプリを実行することはできる)
  3. 更にapp.tbinfoという名前でアプリ名や作者、Webサイトなどのメタ情報をつける
  4. ソースをGithubにpushする
  5. The Tingbot Oceanリポジトリにある ocean/apps.yamlに公開したいアプリの情報を追記して、プルリクを投げる
  6. マージされるのを待つ

で、マージされれば、The Tingbot Ocean に次の様に公開される。 登録の仕方が、なんとも手作りな感じだが、PRして中一日くらいでマージされた。

f:id:HeRo:20161012010437p:plain

日本語を表示するアプリでは最初の公開かな。

Tingbotを少し試してみた。

前回は、組み立ててサンプルアプリを動かしてみただけだったが、もう少しいじってみた。

↓前回↓ hero.hatenablog.jp

イメージファイルの表示

アニメーションGIFはサンプルアプリで試せるので、 それ以外でどんな画像フォーマットが表示できるのか試してみた。

試した結果は次の通り

フォーマット 表示結果 備考
GIF アニメーションもOK
PNG アルファチャンネル付きもOK
JPG
MBP
WebP エミュレータでは利用できず

それを表示した画面写真は次の通り。 右下方は 33.3%の 赤、青、緑 の半透明PNGを重ねている。

よく使われる画像フォーマットは問題なく表示できる。
WebPは実機では問題ないが、エミュレータではエラーとなり起動もできなかった。

日本語の表示

日本語を表示できるのか?

これは日本人にとっては重要なのだが、英語圏の人々からは軽視されている機能なので試してみた。

結果としては、表示可能。

ただし、次の3項目に注意する必要あり。

  1. # coding: utf-8ソースコードエンコーディングを指定すること。
    さもないとコード内に日本語を含むとaccii文字として解釈されてエラーとなる。
  2. unicode文字列を使うこと。
    リテラルでは u'ほげ' を使い、ネットワーク越しに日本語を取得したときにはunicode()関数や.decode()メソッドでunicode文字列に変換する
  3. フォントをアプリに同梱して、コード内で指定すること
    フォントファイルのファイル名にハイフン-を含んでいるとエラーとなるので注意。

アプリを公開する場合、同梱するフォントは再配布可能なライセンスである必要があるので注意。
フォントファイルのフォーマットは TTF でも OTF でもOK。

サンプルコードはこんな感じ。

# -*- coding: utf-8 -*-

import tingbot
from tingbot import *

# setup code here

@every(seconds=1.0/30)
def loop():
    # drawing code here
    screen.fill(color='black')
    message = u'日本語もOK'
    screen.text(message, xy=(0,0), color="white", align='topleft',
                font='fonts/NotoSansCJKjpRegular.otf')
    screen.text(message, xy=(0,45), color="blue", align='topleft',
                font='fonts/ipagp.ttf')
    screen.text(message, xy=(0,80), color="aqua", align='topleft' , 
                font='fonts/ipamp.ttf')
    screen.text(message, xy=(0,120), color="lime", align='topleft' ,
                font='fonts/cinecaption226.ttf')
    screen.text(message, xy=(0,160), color="yellow", align='topleft', 
                font='fonts/TanukiMagic.ttf')
    screen.text(message, xy=(0,200), color="fuchsia", align='topleft', 
                font='fonts/kiloji_p.ttf')

tingbot.run()

これを表示した結果は次の通り。

Webhook

この機能は使い方によっては面白いことができそう。 URLを指定して、ネットワーク上の画像を表示したり、APIにアクセスしてデータを取ってくることもできるのだが、 Webhookはネットワーク越しにTingbotにデータを渡すための機能。

例えば、次のようなコードを Tingbotで動かしながら、

# -*- coding: utf-8 -*-
import tingbot
from tingbot import *

font = 'NotoSansCJKjpRegular.otf'
font_color = 'white'
wh_name = 'my_webhook'

screen.fill(color='black')
screen.text('Waiting...')

@webhook(wh_name)
def on_webhook(data):
    data = data.decode('utf-8')
    screen.fill(color='black')
    screen.text(data, color=font_color, font=font)
tingbot.run()

次のコマンドを実行すると、

$curl -X POST -d '日本語!!!' "http://webhook.tingbot.com/my_webhook"

データとして送った文字列を表示させることができる。

マニュアルにも書かれているが、IFTTTのMakerチャネルを使えば、様々なWebサービスをトリガーにして Tingbot にデータを渡して表示させることができるだろう。

ただし、使い方には注意が必要で、Tingbot にデータを渡すには次のようなURLに 文字列をPOSTしてやればよいのだが、 webhook名は予めどこかに登録しておく必要もなく、自由に設定できる。

http://webhook.tingbot.com/<webhook名>

ということはたまたま、Tingbotユーザの誰かと 使っているwebhook名が一致してしまうと、見知らぬ誰かにデータを見られてしまう可能性や見たくもないデータを見てしまう可能性がある。
ある程度、ランダムで長いwebhook名を使えば、当てられることも少ないと思うが、一度送ったデータは次のデータを送るまでずっとTingbotで取れてしまうので、あんまりプライベートなデータを送らないほうが良いだろう。
逆に大勢にデータを配信するのに使えるかと思ったが、他人も同じwebhook名にデータを送信できるので容易になり済ませてしまう。 そういう使い方もしないほうが良いと思う。
おおらかなパブリック性をもったPub/Sub(誰でも投稿できて、誰でも見たい人に配信される)と捉えれば、面白い使い道があるかも。

このエントリーで書いた3つのアプリは次のリポジトリで公開している。 tingbot_samples

Tingbot が届いたので動かしてみた。

Kickstater で申し込んでいた Tingbot がやっと届いたので触ってみた。

ポチった時の計画だと5月に出荷予定だったので、約4ヶ月遅れで手元に届いた。

どんなもの?

Rasphedy Piを中に組み込んで写真用なモニター付きの小型端末にするキット。 自分でアプリを書いて実行させることができる。

ハードウェア

ものとしては 3.2インチのタッチモニターと4つのボタン。これとラズパイを包む筐体からなる。 ラズパイは自前のものを使う。なんとなく購入して放置していた RPi3を組み込んで組み立てた。

モニタとラズパイを接続するコードの接続ピンさえ間違わないように注意すれば組立自体は簡単。ただし、筐体を閉じるネジが極小なので精密ドライバーがないと閉められない。

ソフトウェア

ソフトウェアとしては Tingbot-OSというものが提供されており、それをSDカードに書き込んで起動すると動く。

SDカードへの書き込み方も セットアップガイドの通りやれば特にハマりどころもなかった。

Tingbot-OSと言ってもRaspbianの一部を上書きしただけのもののようで、起動後はRaspbianのデフォルトユーザでSSH接続もできる。

開発環境

Tide というElectoronベースのIDEが開発環境として提供されている。 リリース前にGithubに上がっていたものは起動しようとしてもうまくいかなかったので心配したが、Mac用に配布されているビルドは問題ない。

このIDEではコードを書く他に次のことができる

  • Tingbotへのwifi設定
  • エミュレータでの実行
  • Tingbotでのテスト実行
  • Tingbotへのインストール

同じネットワークにあるTingbotを自動検知してくれるので、なんなく接続することができる。

Tingbot-python

TingbotアプリはPythonで実装できるようになっている。 Tingbot用に用意されている機能は次の通り

  • 画面上に図形を描画する
  • イメージファイルやテキストを表示する
  • 画面タッチを検知する
  • ボタンの押下、押しっぱなし、複数ボタンの押下の組み合わせ検知
  • ハードウェア情報(IPアドレスやキーボード、マウスの接続状態)の取得
  • 設定の保存
  • Webhook

ちなみにpythonのバージョンは2.7のようだ。

sys.version_info(major=2, minor=7, micro=10, releaselevel='final', serial=0) 

起動

起動すると、2つのアプリがインストールされている。ひとつはKickstarterのバッカーのリストを表示するもの。 もう一つが、Terminal。キーボードをUSBで接続すると、コマンドの入力、実行が可能。

左右2つづつある4つのボタンのうち、外側のボタンを押すとアプリの切り替え、 内側の2つを同時押しするとHOMEに戻るようだ。

サンプルアプリの実行

Tideには5種類のサンプルプログラムがついている。 それらを順に実行してみた。

  • Hello world

    • まあ、何はともあれスタートはこれから。
      f:id:HeRo:20161002181933j:plain:w150
  • Show an Image

    • アニメーションGIFで猫が走る
      f:id:HeRo:20161002182759g:plain:w150
  • Buttons

    • 本体ボタンのサンプル。押す毎にカウントアップ/カウントダウンする
      f:id:HeRo:20161002182715g:plain:w150
  • More Buttons

    • これも本体ボタンのサンプル。ボタンのDOWN/UP、長押しのサンプル
      f:id:HeRo:20161002184420g:plain:w150
  • Touch

    • 画面タッチのサンプル。タッチしたところに点を打つ。
      f:id:HeRo:20161002183056g:plain:w150

いずれも、TingBotの基本的なハードウェアの操作サンプルとなっている。

なかなか遊べそうだ。

東京防災アイデアワークショップに行ってきた

9/4に実施されたオープンデータ利活用 防災アイデア ワークショップに参加した。

ネットのニュースか何かで見かけて、すぐに申し込んでみたのだが、 抽選とのことだったので、当たるかなぁと思ったいたら当選メールが来た。

当日は電車の遅延に巻き込まれ少し遅刻してしまった。
会場についてみると、すでに始まってはいたが、神武直彦氏が主催者挨拶と概要説明しているところで、まだ内容の説明には至っておらず、支障はなかった。

参加者は約40人で5,6人づつチーム分けされていた。受付で所属チームを知らされたので、指定されたチームのテーブルに着いた。

プログラム

ワークショップのプログラムは次の通り

  1. 主催者挨拶・概要説明
  2. イニシャルトーク
  3. チームビルディング
  4. フィールドワーク
  5. 昼食
  6. 午後のイニシャルトーク
  7. データサポートの説明
  8. イデア創出のためのワークショップ
  9. 最終発表
  10. ドット投票
  11. 講評
  12. 表彰
  13. 閉会挨拶・写真撮影
  14. 閉会

イニシャルトーク

最初はインプットからということで、墨田区企画経営室情報システム担当課長 内田正代氏から「墨田区の特徴」ということで、ワークショップの開催地である墨田区の地域的な特徴や情報発信の取り組みの説明があった。

オープンデータは昨年から公開を始めており、区としても推進していくとのことで今後に期待だ。
オープンデータポータルサイト 墨田区公式ウェブサイト

最近、区のホームページをリニューアルしたとのことで、キーワード検索を中心のナビゲーションに変更したとことだった。 見てみると、従来の自治体のホームページのトップと言えば、ページのインデックスになっているところがほとんどだが、 墨田区のホームページでは検索ボックスが最初にあり、スマートホンでも使いやすそうなデザインとなっていた。 検索に慣れていない人が迷ってしまうのでは?と気になったが、メニューも備えており、一応、階層的に辿れるようだ。

続いて 東京都総務局情報通信企画部情報通信施策推進担当課長 斎藤圭司氏より「東京都のオープンデータの取り組み」の説明があった。 まだまだPDF中心だが公開はしている(東京都オープンデータ一覧(試行版)|東京都)
データを公開するとそれを使って、GD Freak のようなサイトが可視化したりして新たな気づきや価値の創造に繋がる可能性を感じており、今後、データを増やしていきたいとのことだが、なにぶん費用もかかるので... とのことだった。

特に防災ということでは東京都防災マップを公開しており、地理情報の上に載せて提供していきたいとのこと。 すでに、避難所やコンビニ、ガソリンスタンドなどはマッピングされており、東京での災害時には役立つだろうと思った。現在はPC向けなデザインなので、スマホから使いやすいUIも用意してもらえればと思った。

チームビルディング & フィールドワーク

イニシャルトーク後は、チームでの活動。
チームメイトは、学生1人と社会人の混成チーム。学生は神武直彦氏のゼミの学生のようだった。
アイスブレイクとして、6つのマスに名前や日頃の防災活動、この夏のニュース等を書き込んでお互いに説明した後、 このあとのフィールドワークに出かけるコースの確認と、どういう観点で見て回るのか?といった点を軽く話し合ったあと フィールドワークに出かけた。

フィールドワークは、会場となっているリッチモンドホテル プレミア東京押上から墨田区役所までの指定コースを歩きながら話し合った観点で見て回るというものだった。早朝、雨が降っていたが、フィールドワーク頃にはやんでおり、それほど日が照っていないので、まあまあの夏のフィールドワーク日和といったところか。(暑いのは暑かったが。)

墨田区で防災というと、木造家屋が密集したいわゆる木密地域を思い浮かべるが、フィールドワークのエリアは、どちらかという住居よりも事業所が多いようだった。各所の案内図や防災設備(消化器や町内会の防災倉庫)などを写真に撮りながら歩き、墨田区役所を往復した。 歩いてみた感想としては、思ったより避難所の案内が少ないのと、公衆トイレも少ないなぁということだった。

会場まで帰ると昼食の時間で、ホテル1Fに入っているスーパーで惣菜とおにぎりを買って、チームメンバーとフィールドワークで見たものを話ながら食べた。

午後のイニシャルトーク

午後の最初は 墨田区都市計画部危機管理担当防災課長 菅原幸弘氏から「墨田区の防災対策と課題」の話があった。
内容は 「すみだ防災パンフレット 地震に備えて」を見ながら以下のような内容だった。

  • 墨田区 関東大震災で被害が大きかった。
  • 本所は江戸時代から都市部
  • 向島は木密地区
  • 地震以外の災害への対策は?
    • 荒川が万一決壊すると2回床下で2週間水が引かないと言われる
    • 識者から近年の意見を聞いている
  • 既存の増水対策は割りと設備が整っている
  • 複合災害への対策は?
    • 区の基本計画で複合対策を意識し始めている

ワークショップ

いよいよ、このイベントのメインのワークショップ。テーマは「避難のためのアイデア」ということだったので、それに沿ったチームテーマをブレストしながらまずはアイデア出し。付箋にアイデアを書いてはホワイトボードに張り出した。30ほどのアイデアが出たところで、メンバー全員で良いと思うアイデアに印をつけて評価。結局、避難所までのナビゲーションアプリという案でまとまった。
方向性が定まったところでブラッシュアップ。

このアイデアの課題としては次のような項目が挙がった。

  • 災害時にしか使わないものなら、結局災害時にしか使われない
  • ナビゲーションって、最初どっちに進めばよいかがわかりにくくない?
  • ありがちなないようなので何かひとひねり必要

などなど

これらに対して出たアイデアは次の通り

  • やっぱ墨田区ってどこからでもスカイツリー見えるよね!これを利用して方向示せばわかりやすいんじゃない?
  • 普段は避難所の代わりに観光スポットを案内すれば、予めのインストールも促せるんじゃない
  • アプリとしての特徴も出る!

というような議論をして、アイデアが固まって来たところで、 ステークホルダー分析と、体験スケッチボード分析を行っていった。

ステークホルダ分析

ステークホルダ分析では、誰が運営するのか? サービスとして持続するにはマネタイズもできないととね などと考え次のように考えた

  • 通常運営:墨田区から業者に委託
  • 広告主:アプリで紹介する観光スポット周辺の事業主を想定。集客にアプリを利用する
  • ユーザ:無料で利用できる
  • 災害時情報発信:墨田区

体験スケッチボード

体験スケッチボードと言うのは今回初めて知ったのだが、「サービスの利用体験を、顧客の目線で感情豊かに捉えるための道具。」で、ユーザ体験をステージに分けて、各ステージでのユーザの行動と思考を同時に考えて、ユーザの感情の変化を曲線で表す。そこからサービスに必要なもの・仕組みを考察するというもの。

今回作成した体験スケッチボードは次の様になった。

f:id:HeRo:20160918093415j:plain

アプリの内容

ざっくりではあるが、アプリの内容は次の様に決まった。

  • 通常時はスカイツリー周辺の観光案内アプリ
  • 行きたい場所を選んで、スカイツリースマホをかざせは、ARチックに方向を矢印で示す
  • 災害時には、スカイツリーにかざすだけで最寄り避難所を示す。
  • スカイツリーと避難所の座標と、GPSによる現在位置座標がわかれば方向を示せるのでオフラインでも機能する
  • PUSH通知で災害状況も通知できる

サーバサイドには次の仕組みが必要であろう

  • 観光スポット情報の管理
  • 観光スポットに関連した広告の管理
  • 避難所情報の管理と更新情報の発信
  • 災害時の情報配信

発表

チームごとに、アイデアを発表。各チームの内容はざっくり次の通り。

  1. 災害時に表示が変わるデジタルサイネージ
  2. デジタルサイネージによる情報提供
  3. 避難弱者を救う地域医療SNS
  4. バルーン型ディスプレイによる避難誘導システム
  5. 地元住民を活用した災害時情報提供
  6. スカイツリーを利用した避難所ナビ
  7. 避難所ナンバリング:コード統一システム

各チームともなかなかおもしろいアイデアが出ていたと思う。

特にチーム4のアドバルーン型のディスプレイで避難所に誘導するアイデアは、誰にでも 避難所の場所がわかりやすく示せ、興味深かった。

表彰

各チームのアイデアは参加者全員で評価した。 評価軸は次の3点。

  • 実現性
  • 革新性
  • データ活用の有用性

我々のチームは、すぐにでも作れそうな内容だったので、実現性でトップとなり、賞品(慶応義塾のボールペン)を頂いた。 各評価軸毎の表彰のあとは最優秀の発表。 すでに自分たちは表彰されていたので、どのチームのアイデアが獲るのかなと思っていたら、 最優秀も頂いてしまいました!

必要なオープンデータもすでに存在しており、すぐにでも実現できそうなことに加え、スカイツリーという象徴的なランドマークをうまく利用できている点が評価された。
優秀賞の賞品は スカイツリーのチケット。ただし、当日券(よく見たら、防災訓練用と書かれており、余り物だったのかな)。

感想など

個人的には優秀賞も貰ったし、楽しいイベントだった。

東京都が主催するオープンデータ活用イベントは初めてだったと思うが、今後も継続してほしい。 都側のオープンデータへの取り組みの活性化になると思う。

また、防災に限らず、問題山積の東京都なので、こういったイベントから思わぬ解決や改善が生み出されるかもしれないし、 東京で住んだり、働いたりしている人々が、行政を利用、あるいは行政と協力してより良くしていこうという意識を高められるのは 良いことだと思う。

小池都知事は情報公開を方針に掲げているが、データとして活用できる形で公開していただくよう願いたい。

関連リンク

東京都によるこのイベントのレポート

Googleスプレッドシートのアドオンをリリースした。

Googleスプレッドシートのアドオン Address2Geocode というのを作ってリリースした話。

f:id:HeRo:20160815213600p:plain

これはなに?

Google スプレッドシート上の日本の住所に緯度経度を付加することができるアドオン。住所の一覧にバッチで処理することもできる。住所を記載したセルやカラムを選択し、変換ボタンをクリックすると、住所の右側のセルに緯度と経度を書き込む。 住所のあるデータを地図にマッピングするときに緯度・経度を求めるのに便利(だと思う)。 ただし、精度は番地レベル。(ちなみにGoogle Mapsなどは号レベルで更に精度が高い。)

きっかけは熊本地震

減災インフォというWebサイトの運営に参加しており、地震などの自然災害は起こった際には情報を収集して再発信している。2016年4月14日の熊本地震以降も、活動している。 熊本地震で回ってきたデータのうち、200ヶ所以上の避難所の住所の一覧というものがあった。添えられた依頼は「Geocoding API - 住所から緯度経度を検索」というサイトを利用して、緯度経度をつけてほしいとの事だった。できたデータは減災インフォで地図にマッピングしたり、他に活動している人たちに配って活用してもらおうというのが目的だった。 数カ所なら手作業したかもしれないが、200ヶ所以上は流石に辛いと思いGoogle Maps APIを利用したスプレッドシートのカスタム関数を作って対応した。 しかし、次のような問題があった。

  1. Google スプレッドシートはちょっと操作すると関数の再計算が走るのですぐにMaps APIのリミットに達してしまう
  2. APIの規約で Maps APIにより得たデータはGoogle Map以外で利用するのはNG
  3. カスタム関数だと別のスプレッドシートで使いたい場合にコードをコピペして移植する必要がある。つまり配布しにくい

Google Maps API以外への変更

上記の1,2の理由により、Google Maps APIは使えないなぁという結論に至った。1.は関数にせず、バッチ処理に変更するなどすれば回数のコントロールは可能だろうが、2の制約のために作ったデータの利用に制限ができるのは嬉しくない。乗換先としては Yahoo!ジオコーダAPI も考えたが、「API経由で取得したデータを保存したり、二次利用することはできません。」との事なのでやはりNG。 色々探してみて、利用についてほぼ制限がなさそうな CSISシンプルジオコーディング実験 の提供するAPIを利用に乗り換えることとした。

カスタム関数からアドオンへ

カスタム関数だと上記の1で挙げたように外部のAPIを無駄にコールして、不要な負荷になりかねないし、3で挙げたように配布にしにくい。 熊本地震でもまだ同様の作業が必要になるかも知れないし、今後発生する災害時にも必要になるかも知れない。せっかく作ったのだから利用しやすい形にしたい。ということで、スプレッドシートのアドオンサイトからすぐにインストールして使えるように最初に作った関数を基にアドオンを作って公開しすることとした。

はじめはナメてた

アドオン自体の実装はそれほど難しいものではなく、HTMLとJavascriptで作ることができる。見栄えをそれらしくできるCSSも提供されている。 きっとAndroidアプリ同様に登録すればとりあえず公開されるのだろうと思いさくっと作って、登録してみた。

登録直後はレビュー待ちのステータスになった。すぐに公開状態になるのかと思いきや、一向に変わらない。 数日後、リジェクトされ、その理由がメールで送られてきた。

メールにはGoogle Docが添付されていて、不具合とUXの改善提案が記載されていた。エラーの画面キャプチャも貼り付けられており、思っていた以上に丁寧にレビューされていた。

指摘事項は次の項目

  1. 処理でエラーが発生し、しかもエラーハンドリングされておらず、組み込みエラーダイアログが表示されている
  2. 変換した緯度・経度を出力するカラムをユーザがわざわざ指定する必要があるのは使いづらい
  3. 処理終了を知らせるのにアラートでなくトーストを使っては?そうすればユーザは閉じるボタンを押す必要がない。
  4. ユーザを待たせる時間があるならローディングイメージを表示したほうがよい。

1.について、確かにエラー処理については自分でも足りないだろうなと思っていた部分だった。でも、地震発生時でニーズがある時にまずリリースしてそれから改善していこう思っていた。そんな甘く考えていた部分を的確に指摘されたのだった。利用していたAPIが日本語で住所を送らないと該当なしの空レスポンスではなく、サーバーエラー(500)を返してくるのも確認不足だった。

2,3,4は不具合ではなく、うーんなかなか的確だなぁと思う改善の提案。 2.については、選択範囲のすぐ右のカラムが空ならば緯度経度を書き込む様に変更した。ただ、緯度経度を書き込む位置は自分で指定したいと日本人マインド的に思う人も結構いるのではと、指定できるようにもした。 3.で提案されたトーストについてはそんな機能があるとは知らなかった。変更してみると確かにトーストのほうが格好いいし便利だなぁと思った。 4についてはちょっと困った。ぐるぐる廻るイメージを処理中表示しようと思って、フリーな素材はすぐに見つかったが、アドオンにはHTMLとJSのファイルしか含められない。プロダクトの一部としてイメージを入れることができないのだ。一箇所にまとまっていないと今後のメンテナンス的に面倒だけど、外部画像をアドオン内で表示できそうなのでS3にでも置いてそれを表示しようかと思ったが、画像のサイズがそれほど大きなものでなかったので、base64変換してコードに含めてみてはどうだろうかと試してみると、思った通りに動く。ということでコードに含める実装にした。

再レビュー、再々レビュー

GoogleのAdd-ons Advisor氏の指摘に沿って修正した後、修正したアドオンの更新の仕方が間違っていて再レビューまでに時間がかかったが、再度評価してもらった。で、またリジェクトされた。 理由は、「うまく動かない」とのこと。どうやらアメリカの住所を試しているらしい。日本語で表記した住所しか変換できないことを伝えたら、次のいずれかの対応を入れようとの返事が来た。

  1. もし日本語以外の入力だったら、日本の住所にしか対応していないことをユーザに示す
  2. 翻訳APIを利用して翻訳してから変換する

結局のところ、翻訳しても日本国内の住所にしか対応できないので、1を対応して、再々レビューを受けた。 数日後、まだうまく動かないとの返事がきた。今度はきちんと日本語で試していると。 どんな住所を試しているのかと聞いたら次の文字列が返ってきた。

4-2-15銀座、中央区、東京104から0061 、日本

ああ、単に英語表記の住所を機械翻訳にかけただけなのね...。思わず笑ってしまった。それは予想してなかった。 そりゃあ、アメリカ人は普通、日本語の住所表記がアメリカの逆になっているなんて知らないんだろうなぁ。 日本語の住所表記はアメリカとは順序が違うんだよと説明して、いくつか住所のサンプルを送った。

そうしたら、動いたよという返事とともにアクセプトされた。

リリース

アクセプトされると公開状態となり、Addonストアから見えるようになった。 結局、最初の申請からリリースまで半月ほどかかった。

おもったより時間がかかったが、自分の作ったものをしっかり評価して改善提案もしてくれるDocs Add-ons Advisor とのやり取りは楽しかった。

Code for Japan Summit 2014 に行ってきた。

2014/10/11 に開催されたCode for Japan Summit に行ってきた。

Code for Japanというのは、Code for America の日本版で、テクノロジーを活用して公共の課題に取り組み、より良くしていこうという団体。

存在は以前から知っていたが、イベント等に参加するのは今回が初めてだった。

最初の基調講演では SIX 代表の野添剛士さんの講演が特に良かった。 一言でいうと「作った」だけではまだ、登山で言うと5合目で、ユーザの心を動かすものに磨き上げることが必要ということだった。 作る側としては、実現しているアイデアがどんなに奥深かろうが、バックエンドでどんなに高度なことをいようが、それを使うユーザにとっては、得られる体験がすべてであり、体験が心に響かなければ、アイデアや実現されている仕組みが理解されることもないという内容だった。 それが、氏がこれまでに取り組んだプロジェクトで具体的に説明された。よくわかり、よく”心に響く”講演だった。

午後は3トラックにわかれたセッションだったのだが、自分は特に聞こうと思って行ったわけではなかったのだが、「コミュニティデザイン」セッションを聴いた。

5人の実際に地域コミュニティ活性化の取り組みをしている方の発表のあと、パネルディスカッションという内容だった。 中でも印象に残ったのは、studio-L の 西上ありささんの発表だった。ある地方自治体の美術館設立を通じた地域活性化の事例の紹介だったが、最初はなかなか参加してくれなかった住人の方々をいかにして巻き込んでいったのかという話が面白かった。 基本的には女性を巻き込めば男性も参加し始めるということで、おばさん、おばあさんの懐にどう飛び込むかが重要らしい。この事例ではイケメンの担当者を現地に住まわせ、かわいがってもらうという方法が有効だったとのこと。あと、現地で買えないお菓子を持って行くと「それが食べたい」という口実で集会に参加してくれるという。なるほどなぁと思った。 いずれの発表者の方も、これからの地域コミュニティ活性化にはITの活用が不可欠だという。その上で、地域の方だたのITスキルの差をどのように埋めるのか、特に高齢者にどのように教え、使ってもらうかが重要ということだった。ITエンジニアとして自分にはなにができるだろうかと聞きながら思った。

これまではITエンジニアばかりのイベントには参加してきたが、そこでは聞けないエンジニアではない方々の話を多く聞くことができ、楽しいイベントだった。