Hack For Japan

エンジニアだからこそできる復興への一歩

社会的課題をテクノロジで解決するためのコミュニティ Hack For Japanの 活動をレポートする本連載。今回と次回は 2013年 10月に開催された「 ITx災害」会議の模様を前後編に分けて紹介します。

第26回

「ITx災害」会議（前編）

Hack For Japanスタッフ

及川卓也　OIKAWA Takuya

Twitter @takoratta

高橋憲一　TAKAHASHI Kenichi

Twitter @ken1_taka

きっかけと準備

2012年、 Hack For Japanでは、復興支援などに 対して ITの力を活かして貢献したいという思い を持つ方と支援を必要としている方とをつなぐた めの取り組みである、スキルマッチングを開始しま した^注1。しかし、今に至るまであまり活用されて いません。 Hack For Japanの活動に賛同してくだ さっている人は多いものの、やはり開発者が参加者 の多数を占める Hack For Japanのコミュニティだ けでは協力関係構築が難しかったのではないかと考 えられます。この課題はスタッフの中では認識され ており、コミュニティの拡大やほか団体との連携な どが以前から検討されていました。 　そのような中、 Hack For Japanに当初から参加い ただいている方から、今までの活動を振り返り、 IT による復興支援のあり方を考える必要があるのでは ないかという声もあがってきました。 　これらがきっかけになり、「ITによる復興支援の あり方会議」（当初、「ITx災害」はこう呼ばれていま した）の準備会が発足しました。 2013年6月末に行 われた最初の準備会では 30名近くの方が集まり、 震災以降の取り組みなどが共有されました。お互い にそれぞれの存在は知ってはいたものの、直接話す のは初めてという参加者も多く、「つながる」という 意義を再確認し、本会議への期待がさらに高まりま した。 　その後の準備会で、将来に起きうる災害に対して の防災や減災も話し合うことから、会議名を「 ITx 災害」会議（「 x」は「かける」と読みます）とすること に決定しました。また、参加者全員に積極的に参加 してもらうため、アンカンファレンスという形式を とることとしました。 　アンカンファレンスとは、 Software Designの読 者であればすでにお馴(な) 染(じ) みかもしれませんが、あえ て事前にセッション内容などを決めずに、当日に参 加者自身に提案してもらう形式のカンファレンスで す。通常のカンファレンスの場合、セッションで話 す人と聞く人というのが明確に別れてしまいがちで すが、アンカンファレンススタイルの場合はセッ ションのトピックを提案できますし、たとえほかの 人が提案したトピックであったとしても、事前にスライドなどが準備されていることまれなので、全員が同じ立場でセッ ションに参加できます。 　準備会は合計 4度行われ、総勢 20 名以上のスタッフが手分けして準備 を進める、文字どおりの手作りの会 議として用意され、当日を迎えまし た。

午前の部： ショートスピーチ

「ITx災害」会議は 10月6日に東京 大学駒場リサーチキャンパスにて行 われました（写真1）。参加者は 112 名となりました。この会議は招待制 としたのですが、招待した方の 9割 以上が参加されるという大変高い参 加率の会議となりました。 　午前の部はイベントの主旨の説明 と、これまで復興支援活動をされて きた 10名の方からのショートスピー チが行われました（写真2）。

写真1　会場風景

写真2　ショートスピーチの様子

RCF復興支援チーム：藤沢烈さん

情報を復興に活用する3つのキーワードを紹介した いと思います。 1.ラストワンマイル〜地域コミュニティ形成 「復興においてこそ、情報が必要である」 ラストワンマイルをつなぐために現地コーディ ネーターが必要 2. One to One〜産業復興 被災者、被災事業者と支援者がOne to Oneで結 ばれることが意味があり、持続的なかかわりが求 められる 3.テーマ別のプラットフォーム〜人材支援 今回の震災は被災地も多く、支援も多い。被災地 と支援側のニーズを集約し、見える化するテーマ 別のプラットフォームが必要 　復興には10年以上かかり、まだ入り口の段階。引 き続き東北を支えるためにも、情報の整理がたいへん 大事だと思っております。

岩手震災IT支援プロジェクト：村山優子さん

災害時のネット接続支援の課題として、IT支援の重 要性が必ずしも認識されないというものがありまし た。まず支援ありきのスタンスではダメで、相手が必 要とするものを理解し、人や車が先、そのうえで情報 交換が必要です。また、組織プロトコルも重要で管轄 する部署への説得、なぜインターネットが必要か、今 起こっていることをどうやって意思疎通するかという ことが大切です。できることから1つ1つ解決してい くと信頼が出てきて、最終的には情報処理が必要だと いうことがわかってもらえます。

さくらインターネット研究所：松本直人さん

写真からはたくさんのことがわかります。言葉は曖 昧さを持っているため、より多くの視覚情報の共有、 正確な位置情報、データ加工の容易さが大切です。と くにGPS情報付き写真は災害直後の復旧のときに有 用となります。必要な情報がリアルタイムで手に入る 環境づくりを見据えて、GPS情報付き写真を発信しま しょう。常に自分でも情報発信することを心がけてい ると役に立つことがあります。

うらと海の子再生プロジェクト：小泉勝志郎さん

私自身が宮城県塩竈市で被災し、弟が携わっている 浦戸諸島という離島の養殖業も壊滅状態となってしま いました。それを救うために始まったのが「うらと海 の子再生プロジェクト」で、クラウドファンディング で1億8千万円を集め、現在はオーナーさんにほぼ返 した状態となっています。 　また、よくボランティアが集まらないという話を聞 きますが、つらいとか大変という言葉ばかりでは誰も 来たいと思いません。楽しい要素を伝える必要があり ます。たとえば浦戸は海の物が豊富でそれを採ったり 食べたりすることが楽しめるといった地域の魅力を伝 えていけば、ボランティアも集まってくるのではない かと思っています。

岩手医科大学：秋冨慎司さん

スーパーコンピュータによる試算では揺れだけを計 算して、津波を考慮していませんでした。それが岩手 は大丈夫という当初の誤認識につながりました。情報 の持つ怖さというものがあると思います。 　また、災害後のフェーズは10のn乗の時間で考え ることが大切です。 1時間：自分たちの安全確保 10時間：救助、救援の準備、情報収集 100時間：人命救助 1000時間：復旧活動 10000時間：復興活動 　このように受ける側、送る側の双方がきちんと時間 軸で考えていく必要があります。 　情報のマネジメントの仕方によっては、嘘の情報で も本当の情報になってしまうことがあります。テレビで 「かわいそうですねぇ、ここの避難所」といったような取 まだら り上げられ方をした場所に支援が集中し、斑が発生し ます。また道路が復旧したという情報も、民間の利用 により、自衛隊などが使えないことがあってはいけま せん。情報は魔物にも神にもなると思っております。

株式会社Eyes, JAPAN：山寺純さん

アメリカで盛り上がっているヘルスケアITの日本 版を推進しており、Health 2.0 Fukushimaチャプ ターを務めています。昨年は医療ハッカソンも行いま した。

情報支援プロボノプラットフォーム（iSPP） 岸原孝昌さん

被災地の情報サービスにおいてさまざまな取り組み が行われたと思うのですが、ちゃんと記録にとってお かないと次に進められません。そこで、地域と時系 列、情報ツールが生きていたのか、提供されたものと 必要とされた情報の差などについて情報行動調査を行 いました。 　災害発生直後はラジオが有効で、徐々に携帯電話、 インターネットなどのメディアに移行していき、必要 とされた情報も時系列とともに変わってくることがわ かっています。まだ構想段階ですが、情報支援レス キュー隊のコンセプトを検討しています。

Code for Japan：高木祐介さん

Hack For Japanなどで行ってきたハッカソンは コミュニティ形成や問題への理解の促進には効果を発 揮するが、継続したサービスに結びつけていくのは難 しいと考えて始めたのがCode for Japanです。 オープンデータを活用することで地域防災を推進して いき、緊急時にスムーズな対応ができるように地域で のITコミュニティ作りを支援します。

イトナブ石巻：古山隆幸さん

震災後に街づくりの活動をしていく中で、ITを活用 して若者たちが動けるフィールドを作っていこうとめたのがイトナブです。支援を受け続けるだけではな く、自活できる人作り＝自立した産業の開拓サイクル を回していくという活動を目指しています。

IPA/WASForum：岡田良太郎さん

震災後、個人として社会継続のために自発的に行動 した人たちによるWeb上の支援サイトを調査したと ころ、地理情報を扱ったものが44％、人命を取り 扱ったものが41％、さらに起案からリリースまで72 時間以内のものが52％、さらに半数が3名以下のプ ロジェクトだったという統計が得られました。利用可 能なデータがなくて苦労したという話もありますが、 プライバシーの問題など、当時はスピードのことを考 えて意識していなかったこと、なりゆきでやってはい けないことが、改めて考えると多々あるはずです。

参加証にひと工夫して交流のきっかけに

会議では参加者間の交流を促すために、いくつか のしくみを用意しました。その 1つが参加証です。 首から下げた参加証で、名 前と所属がわかるというのはどのイベントでも良くあ る風景なのですが、今回の 会議では、その参加証を自 作してもらうようにしまし た。 　実は、参加証をスタッフ 側で用意し、受付でそれを 受け取ってもらう方法にす るか、事前に参加者に作っ てもらうようにするかは、 準備会でかなりの議論を重 ねました。というのも、た だでさえ準備に時間がかかり、当日の受付が混乱する可能性もある中で、さら にスタッフにも参加者にも負荷のかかる作業を追加 する意味があるかが争点となったからです。 　結果から言うと大成功でした。 PDFのテンプレー トを用意し、参加者に項目を埋めてもらうようにし た^注2のですが、それぞれ工夫を凝らしてさまざま な参加証を用意していただきました。図1、2は筆者 （及川）の参加証をスキャンしたものです。 　今回は PDFでテンプレートを用意したのですが、 「開発」「運用」「インフラ」などの自分の専門分野に関 しては複数選択可能としていたので、 Acrobat Readerのレイヤー機能を利用して、該当する分野 のレイヤーを有効にしてもらうようにしました。残 念ながら、 ITの専門家ではない参加者には難易度が 高い操作だったようで、ふと気づくと、そこかしこ にすべての分野の専門家というスーパーエクスパー トがいるという状態になっていました。次回がある ならば、この部分は Webのフォームに該当項目を 入力することで、 PDFが自動生成されるようなシス テムを用意できればと考えています。 　次号では後編として、お昼に振る舞われた芋煮の 話と午後の部のアンカンファレンスについてレポー トします。

図1　参加章の例（表）

図2　参加章の例（裏）

脚注

注1）http://blog.hack4.jp/2012/12/blog-post.html
注2）http://www.itxsaigai.org/20131006/namecard.html

Updated on 2 24, 2013 by Seigo Ishino