災害対応・支援を目的とした

ウェブサイト等の構築・運営に

おける技術課題に関する調査

報告書

平成 25年 1月

目 次

1. 調査概要 ............................................................................................................... 1

1.1. 本調査の背景と目的 ................................................................................................ 1

1.2. 調査実施体制 ........................................................................................................... 2

1.3. 全体像の調査 − アンケート調査の概要 .................................................................. 3

1.3.1. アンケート対象 ....................................................................................................... 3

1.3.2. アンケート設計上の基本方針 ................................................................................. 3

1.3.3. アンケート調査項目 ................................................................................................ 5

1.3.4. アンケート回収状況 ................................................................................................ 5

1.4. 特徴的なケースについての調査 - インタビュー調査の概要 ................................... 6

1.5. 本報告書の構成と読み方 ......................................................................................... 6

1.5.1. 本報告書の構成 ....................................................................................................... 6

1.5.2. 本報告書が想定する読者 ........................................................................................ 7

2. 支援サイト等に関わる活動の全体的な傾向の調査 − アンケートの記録 ............ 8

2.1. 回答者とサイトの基本情報 ...................................................................................... 8

2.1.1. 基本情報：回答者の年齢・職業・業種 .................................................................. 8

2.1.2. 基本情報：支援サイトのサービス内容 .................................................................. 9

2.1.3. 基本情報：運営母体の種別 ................................................................................... 10

2.1.4. 基本情報：取り扱ったデータの種類と技術的特徴、公開日、現在の状況 ......... 11

2.2. サイト運営全体としての活動実態 ......................................................................... 13

2.2.1. 決意フェーズ：立ち上げの動機・経緯 ................................................................ 13

2.2.2. 決意フェーズ：サイトの支援を決めた理由・ ..................................................... 13

2.2.3. 決意フェーズ：支援サイト等の公開スケジュールの目標 ................................... 14

2.2.4. 準備・立ち上げフェーズ：立ち上げを決めてから公開するまでに要した期間 .. 14

2.2.5. 準備・立ち上げフェーズ：立ち上げ時のメンバー数 .......................................... 15

2.2.6. 準備・立ち上げフェーズ：立ち上げ時の技術者割合 .......................................... 15

2.2.7. 準備・立ち上げフェーズ：メンバーを集めた方法 .............................................. 17

2.2.8. 準備・立ち上げフェーズ：費用の調達 ................................................................ 17

2.2.9. 準備・立ち上げフェーズ：立ち上げの際に苦労した点 ...................................... 18

2.2.10. 運営フェーズ：サイト運営にあたり、直面した課題 ........................................ 19

2.2.11. 運営フェーズ：他のサイトや団体との協力・連携が効果的だったもの .......... 24

2.2.12. 現状・終了フェーズ：サイト上での支援を継続している理由 ......................... 27

2.2.13. 現状・終了フェーズ：支援サイト等の今後の予定 ............................................ 27

2.2.14. 現状・終了フェーズ：サイト上での支援機能を終了した理由 ......................... 30

2.3. 技術支援者の活動実態 ........................................................................................... 31

2.3.1. 技術支援の経緯：運営者との関係 ........................................................................ 31

2.3.2. 技術支援の経緯：支援を決めた理由 .................................................................... 31

2.3.3. 技術支援の経緯：支援へのかかわり方 ................................................................ 34

2.3.4. 技術支援の経緯：関与したフェーズと果たした役割 .......................................... 36

2.3.5. 利用した技術部品：稼働環境に関する設問 ......................................................... 37

2.3.6. 利用した技術部品：開発手段についての設問 ..................................................... 38

2.3.7. 利用した技術部品：プロジェクト推進・チーム内コミュニケーション ............. 42

2.3.8. 利用した技術部品：技術部品選択にあたり注意した点 ...................................... 43

2.4. サイト運営に必要な情報の収集、サイトで使用する情報の取得と取り扱い ......... 45

2.4.1. サイト運営のために必要な情報の収集手段 ......................................................... 45

2.4.2. コンテンツ・データの取得と取り扱い：情報源と取得手段 ............................... 47

2.4.3. コンテンツ・データの取得と取り扱い：情報取得のタイミング ........................ 49

2.4.4. コンテンツ・データの取得と取り扱い：取得したデータの加工・処理 ............. 50

2.4.5. コンテンツ・データの取得と取り扱い：マッシュアップに関する課題 ............. 51

2.4.6. コンテンツ・データの取得と取り扱い：情報の信憑性や鮮度の維持についての課

題 51

2.4.7. 運営状況の把握と対応：アクセス状況や利用状況の把握・分析、利便性向上改善

53

2.4.8. セキュリティ確保のために取られた技術手段 ..................................................... 55

2.5. 体制に関する課題 .................................................................................................. 55

2.5.1. 技術支援体制 ......................................................................................................... 55

2.5.2. 不足しがちだったリソース ................................................................................... 59

2.5.3. プロジェクトマネジメント上の制約や課題 ......................................................... 60

2.6. 実体験を通じた今後の教訓 .................................................................................... 62

2.6.1. 支援サイト等の立ち上げや運営に寄与した事柄 ................................................. 62

2.6.2. 法令や情報セキュリティ、プライバシー保護等の課題 ...................................... 62

2.6.3. 実体験を踏まえたメッセージやアドバイス ......................................................... 64

2.6.4. 実体験を踏まえ、技術者がその後に取り組んだ事柄 .......................................... 68

2.6.5. 支援サイト運営経験からの教訓、提言、関係方面に望むこと ........................... 69

3. 課題の具体的な状況に関する背景調査 − インタビューの記録 ......................... 77

3.1. アンケート結果から引き出された、検証すべき仮説 ............................................. 77

3.2. インタビュー記録 .................................................................................................. 79

3.2.1. インタビュー記録：震災前から活動していた団体によるサイト ........................ 79

(1) ジャスト・ギビング・ジャパン（JustGiving Japan） ........................................................80

(2) 東日本大震災支援全国ネットワーク（JCN） ........................................................................81

3.2.2. インタビュー記録：被災地に拠点をもつ団体によるサイト ............................... 84

(3) 被災者をNPOとつないで支える合同プロジェクト（つなプロ） .......................................84

(4) ネトボラ宮城 ..............................................................................................................................88

(5) 一般社団法人SAVE IWATE ....................................................................................................90

(6) うらと海の子再生プロジェクト ...............................................................................................92

3.2.3. インタビュー記録：個人が中心になって運用したサイト ................................... 94

(7) 311HELP.com ............................................................................................................................94

(8) 防災情報ストリーム...................................................................................................................97

(9) WiFiMap 無線LANアクセスポイント強度地図作成 .........................................................99

(10) 緊急地震速報 by Extension ................................................................................................ 100

(11) 炊き出したん ......................................................................................................................... 103

(12) TwitForYou! .......................................................................................................................... 105

(13) JAWS-UG 災害復興支援 .................................................................................................... 108

(14) 近隣Tweet確認サイト ........................................................................................................ 109

(15) 炊き出しまっぷ ...................................................................................................................... 111

(16) OLIVE 災害wiki データベース。 ................................................................................... 115

3.2.4. インタビュー記録：法的・制度的な課題をとくに意識して対応したサイト ... 117

(17) 放射線量取得API .................................................................................................................. 117

(18) 日本Androidの会payforwardingプロジェクト .............................................................. 119

3.2.5. インタビュー結果・サマリー ............................................................................. 122

3.3. 背景調査の整理 ................................................................................................... 125

3.3.1. 早期の立ち上げを可能にした諸要因 .................................................................. 125

3.3.2. 立ち上げ期以降、運用期にかけての特徴的な事象 ............................................ 127

3.3.3. 継続・収束期に特徴的な事象 ............................................................................. 128

3.3.4. サイトの目的・特性や情報特性による、運用・技術面での特徴的な事象 ....... 129

3.3.5. 品質やセキュリティに関する課題認識 .............................................................. 131

4. 分析と考察 ....................................................................................................... 132

4.1. 災害発生時からの社会的なニーズの変化と支援サイト等の内容・規模の変遷との関

係性に関する時系列的考察 .............................................................................................. 132

4.1.1. 災害後の各段階における情報ニーズとの関係 ................................................... 132

4.1.2. 東日本大震災における災害状況の時系列的整理 ............................................... 134

4.1.3. サイトの目的・内容と公開日 ............................................................................. 139

4.1.4. サイトの目的・内容と運営団体の種別 .............................................................. 141

4.2. 支援サイト等のライフサイクルと課題 ................................................................ 142

4.3. 迅速なサイト立ち上げの促進要因・阻害要因 ..................................................... 143

4.3.1. 震災前からの備えの効果 .................................................................................... 143

4.3.2. 運営母体の特性と立ち上げに要した時間の関連 ............................................... 144

4.3.3. 人的体制・技術者の確保 .................................................................................... 145

4.3.4. ボランティアの有効活用の課題 ......................................................................... 146

4.3.5. オンライン・コミュニケーションツールの活用 ............................................... 147

4.4. 運用フェーズにおける課題と対応 ....................................................................... 149

4.4.1. 情報の確保と継続的な収集方法 ......................................................................... 149

4.4.2. 情報源の信憑性や鮮度の維持について .............................................................. 150

4.4.3. 周知、プロモーションとアクセス急増による処理能力不足への対応 .............. 151

4.4.4. 法令や制度などの社会的な制約・課題への対応 ............................................... 151

4.5. 継続・収束フェーズの課題と対応 ....................................................................... 153

4.6. IT技術要素と支援サイト等の品質及び安全性との関係性 .................................. 156

4.6.1. 技術部品の選択では、短期間での稼働を優先 ................................................... 156

4.6.2. 新規にプラットフォームを調達したケース ....................................................... 158

4.6.3. 個人情報、プライバシー保護への配慮とセキュリティにかかわる技術選択 ... 160

4.7. 総括 ..................................................................................................................... 161

4.7.1. 支援サイト等の活動成果 .................................................................................... 161

4.7.2. 支援サイト等の制約と課題 ................................................................................. 167

4.8. 提言 ..................................................................................................................... 170

4.8.1. 自助：自らの備え ............................................................................................... 170

4.8.2. 共助：社会・体制としての備え ......................................................................... 171

4.8.3. 公助：法令、政府の備え .................................................................................... 173

4.9. おわりに .............................................................................................................. 174

図目次 ...................................................................................................................... 175

表目次 ...................................................................................................................... 177

1

1. 調査概要

1.1. 本調査の背景と目的

東日本大震災の発生直後からインターネット上で ITの利活用が活発であったことが確認された。それ

は、安否情報の確認、物資の支援、ボランティア活動など様々な支援活動の推進を目的とした多様なサー

ビスを実現するWebサイトやWebサービス、スマートフォンで利用する目的のアプリケーション(通称、

アプリ)の提供などが、短期間で立ち上がったことである。

このようなインターネットの情報流通・情報発信を活用した支援活動の実現にあたっては、支援サイトの

早期立ち上げを実現するための特別な動きがあったこと、また予想を上回る災害の影響により、刻一刻と

変化する社会的なニーズに対応していたことが、客観的に知られている事実となっている。阪神・淡路大

震災や新潟県中越地震など、過去の災害発生時にも、ITを利活用した支援活動は存在しなかったわけで

はない。しかし、今回の東日本大震災においては、それらの活動の数、関与した人々やサービスの多様性

に注目するなら、過去の事例をはるかに凌駕するものであったことが大きな特徴といえる。

では、これら支援サイト等を技術的に実現し運営することに関わったのはどのような人々か、またその実

現を可能にした要因は何か。同時に、どのような課題・困難に直面し、どのように解決し、推進してきたのか。

解決が極めて困難な、どんな課題に直面したのか、またこうした自発的なサービスによる実現を阻害する、

共通した環境要因はあるのか。こうした事柄を明らかにすることは、今後の災害時において迅速・円滑な

支援活動を実現するため、IT技術者はもちろんのこと、支援や情報提供に関わる様々な関係者、ひいては

こうしたサービスを活用するユーザにとっても、今後のための示唆が得られるものと考えられる。

そこで、本調査は、ITの利活用の視点から災害時支援活動に関わる今後の課題を明らかにするため、

これら東日本大震災の発生直後から被災地への社会的支援を目的として運用を実際に開始した支援サ

イト等を対象とし、サービスの構築・運用に携わった IT人材と、その実際の経験に焦点をあて、それを忠実

に記録することを重視した。

また、それぞれの支援サイトによって目的が異なり、状況や課題が異なることを踏まえつつも、支援サイ

2

ト等の企画立案、仕様検討、リリース、運営、そしてサイトの終了までのライフサイクルを視点とし、それぞ

れの段階における課題を抽出することに主眼を置き、ひいては、経験を通して認識できた、将来の環境の

あるべき姿についての理解を収集することを目的とした。

1.2. 調査実施体制

本調査は、独立行政法人情報処理推進機構（IPA）国際標準推進センターが企画・立案し、株式会社仙

台ソフトウェアセンター（NAViS）への委託により、情報支援プロボノ・プラットフォーム（iSPP）の協力を得

て実施された。

3

1.3. 全体像の調査 − アンケート調査の概要

1.3.1. アンケート対象

あらかじめ選定した 250ほどの東日本大震災後に運用を開始された支援サイト等を中心に、アン

ケート調査を実施した。アンケート調査の実施に際しては、調査票、Webアンケートを用い、2012

年6月29日より7月 20日までの回答を集約した。

アンケートは、支援サイト等を通じたサービスの主体者を対象とした「運営者向けアンケート」、

主としてサービスの構築や運営を技術面から支援した技術者を対象とした「技術者向けアンケート」

の２種類を作成し、展開した。また個別の回答については、特に許諾を得ていない限り、公開にお

いては匿名情報として取り扱うとの点を回答の前提条件とした。なお、後述のインタビューについ

てはその限りではない。

1.3.2. アンケート設計上の基本方針

アンケート実施にあたり、以下の３点に留意し、設問設計することを基本方針とした。

(1) 支援サイトのライフサイクルに焦点を当てること

東日本大震災の発災を受けて運営者が支援サイト等の立ち上げを決意してから、実際に支

援サイト等を公開、運営し、継続または終了するまでの一連の活動として支援サイトのライフサ

イクルに焦点を当て、以下の４つのフェーズを基本に設計とすることを基本方針とした。

アンケートでは、立ち上げに至る動機やいきさつ、技術的手段の選択、情報収集、メンバー間

での協力状況など、実際の活動に着目した設問を設けると共に、その中での課題や教訓を具

体的に聞くことにより、今後のインターネットを通じた災害時支援の示唆となる知見の抽出を図

った。

表 1-1 支援サイトのライフサイクル分類

フェーズ 内容

決意フェーズ 被災者等支援サイト等の立ち上げを決意した段階

公開準備・立ち上げフェーズ 具体的な企画からサイト公開まで

運営フェーズ 公開後の運営、サイトを通じた支援活動の実施段階

現状・終了フェーズ 現時点での活動状況

4

(2) 運営団体自身の活動内容や成果自体の精査や評価を目的としないこと

調査の主眼はITを利活用した災害時支援活動の在り方についての今後の課題を明らか

にすることを目的としており、支援サイト等のライフサイクル全体として、どのような

課題に直面し、それをどのように解決してきたのか、またはどのような制約があったの

かを事実として把握することが必要である。そのため、運営団体の活動内容や、成果自

体の精査や評価に関する設問は予め除外した。

(3) 支援サイト等が提供する機能やサービス／構成する技術自体の精査や評価は行わない

（２）と同様の理由により、支援サイト等が提供する個別の機能やサービス、そこで

用いられた技術自体の精査や評価に関する設問は予め除外した。

5

1.3.3. アンケート調査項目

アンケート調査において把握する項目として以下の項目を選定した。

表 1-2アンケート調査項目

企画・運営者への調査項目 技術者への調査項目

［第1部 支援サイトの活動実態］

1) 決意フェーズ

立ち上げの動機・経緯、支援内容の決定理由、公開日

程目標

2) 準備・立ち上げフェーズ

公開までに要した期間、立ち上げ時の体制、費用調達

方法、立ち上げ時の苦労内容

3) 運営フェーズ

情報の収集手段、直面した課題、他サイト・団体との

協力・連携内容

4) 現状・終了フェーズ

継続の理由、今後の予定、終了の理由

［第2部 実体験を通じた今後の教訓］

・支援サイトの立ち上げや運営に寄与した要因

・ 法令による制約、情報セキュリティ、プライバシー

保護などについての教訓

・ 今回の経験に基づく反省や教訓

・ 支援サイトの立ち上げや運営に関する教訓、提言、

関係方面への要望

［第1部 技術支援の経緯］

・ 運営者との関係、支援を決めた理由

・ 運営支援へのかかわり方

・ 他の支援サイト等への支援の有無

［第2部 かかわった技術分野・課題・工夫］

・ かかわったフェーズ

・ かかわった技術分野

・ 利用した技術部品

・ 技術部品の選択

・ 情報・コンテンツの取得

・ マッシュアップ

・ 運営に当たっての配慮や工夫

［第3部 技術支援体制と課題や工夫］

・ 技術支援体制

・ 不足しがちだったリソース

・ プロジェクトマネジメント上の制約

［第4部 実体験を通じた今後の教訓］

・ 支援活動を踏まえ取り組んだもの

・ 支援サイトの立ち上げや運営に関する教訓、

提言、関係方面への要望

1.3.4. アンケート回収状況

アンケートについては、回答者候補 253件に対して、運営者から 97件、技術支援者から 64件の

回答を得られた。また、支援活動に携わったコミュニティなどにおいて周知したため、上記の回答

者候補以外からの回答を得た。調査の対象と判断できる回答として、運営者 16件、技術支援者8

件の回答を得た。なお、アンケート依頼に対し、回答を辞退するとの団体が 12団体あったが、「活

動した団体（チーム）が既に解散している」「逆に支援を受けた団体である」などの理由が伝えられ

た。

6

表 1-3 アンケート回収状況

運用者 技術者 合計

回答者候補 253 253

回答者候補からの回答 97 64 161

オープン回答（候補以外から） 16 8 24

合計 113 72 185

1.4. 特徴的なケースについての調査 - インタビュー調査の概要

アンケートの回答結果から得られた事柄を、より具体的に分析・考察することを目的として、アンケート

の回答内容の中から特徴的な事実や経験を述べ、より詳しい教訓などが得られると想定できる団体を抽

出した。その結果、2012年7月12日より7月26日までに、18団体、20名に対してヒアリング、あるい

はメールなどを用いたインタビュー調査を行った。詳細は、第３章をご覧いただきたい。

1.5. 本報告書の構成と読み方

1.5.1. 本報告書の構成

報告書の構成と各章の内容は以下の通りである。

表 1-4 報告書の構成

第1章（本章） 調査概要

調査の目的、調査テーマ、調査手段の概要を記載。

第2章 支援サイト等に関わる活動の全体的な傾向の調査

対象へのアンケート調査の結果を記載。体制、かかった期間、リソース選択、

直面し

た課題、採用した技術などを含む記録。

第3章 重点項目・背景の調査

選定した対象へのインタビュー記録を記載。具体的な課題と対応に関する記録。

第4章 分析と考察

第2章、第 3章の調査を分析し、考察を示し、提言を示す。

7

1.5.2. 本報告書が想定する読者

本報告書の読み手としては、IT技術の適用によってサービスを構築・運営することに関わる全て

の技術者をはじめ、IT企業、団体、コミュニティなど、ITの利活用を推進することに関係する立場

の方々を想定している。

● 災害対応に関心を持つ一般の読み手

インターネットなど情報技術を用いたサービスを利用するユーザの視点で実態、また意向を把

握し、こうしたサービスを活用する、あるいは協力する際の参考とする。

● IT技術者・コミュニティ

災害の対応において IT関連の技術を活かしてサービス構築を行なった記録には、支援が必要な

場合に必要とされる技術情報や適用のヒントが多く含まれており、サービス構築を担当する人

にとって今後のスキル向上のための、あるいはオープンに協調する種類の活動で、IT技術をよ

り効果的に適用する方法について考える上でのリファレンスとする。

● 企業、団体

企業や団体が企業内外のいずれの場合でも、個人またはグループを支援し、あるいは実現性を

高めるために必要だった事柄を理解し、今後の支援対応のあり方を考える、さらにはそれに適

した人材を訓練するための参考情報とする。また、今後の同様の活動に備え、課題やニーズを

より効果的に解決する取組みを行うための参考とする。

● 国・行政機関など

構造的な問題を把握し、今後の政策・事業展開の参考とする。

8

2. 支援サイト等に関わる活動の全体的な傾向の調査 − アンケートの記録

2.1. 回答者とサイトの基本情報

アンケートの最初に、回答者の基本的なプロフィールと、支援サイト等の基本情報として、取り扱ったデ

ータの種類、公開日、現状、運営母体、特徴的な技術について尋ねた。

2.1.1. 基本情報：回答者の年齢・職業・業種

回答者像の典型は、30代から 40代のいわゆる情報通信関連の業種に勤務する中堅エンジニアであ

るが、支援活動を目的とするNPOなど団体職員、学生、研究者も含まれている。

図 2-1 回答者プロフィール 年齢（運営者 ｎ＝９６／技術者 ｎ＝６０）

全回答 年齢

3.3%

13.3%

35.0%

13.3%

8.3%

6.3%

12.5%

26.0%

3.3%

5.0%

16.7%

1.7%

2.1%

6.3%

26.0%

11.5%

7.3%

2.1%

56歳～

51～55歳

46～50歳

41～45歳

36～40歳

31～35歳

26～30歳

21～25歳

～20歳

運営者

技術者

9

図 2-2 回答者プロフィール 職業（運営者 ｎ＝１１３／技術者 ｎ＝７２）

図 2-3 回答者プロフィール 業種・分野（運営者 ｎ＝１１３／技術者 ｎ＝７２）

2.1.2. 基本情報：支援サイトのサービス内容

災害やその影響で生じている停電などの問題について情報発信を行うもの、災害の被害に対して

直接的な支援につながる情報を扱うもの、そして活動の状況を発信し、国内外に状況を知らせるも

のがある。

全回答 職業

9.7%

1.4%

30.6%

8.0%

27.4%

27.4%

0.0%

0.0%

0.0%

4.2%

4.2%

4.2%

11.1%

20.8%

13.9%

7.1%

0.0%

0.0%

0.0%

0.9%

3.5%

4.4%

9.7%

11.5%

その他

無　職

公務員

農林漁業者

パートタイム

教員・研究者

学　生

専門職・自由業

自営業者

ITエンジニア

団体・NPO職員

会社員

運営者

技術者

全回答 業種・分野

0.0%

0.0%

0.0%

4.2%

55.6%

0.0%

0.0%

0.9%

2.7%

4.4%

15.3%

0.0%

0.0%

0.0%

5.6%

0.0%

0.0%

2.8%

1.4%

2.8%

12.5%

17.7%

0.0%

0.0%

0.0%

0.9%

0.9%

0.9%

3.5%

4.4%

20.4%

43.4%

その他

宗教関係

政府・自治体

流　通

卸・小売

旅行・接客

法　律

製　造

金融・保険・不動産

建設・建築

芸　術

学　生

メディア・出版

医療福祉

各種団体

情報通信

運営者

技術者

10

図 2-4 サイト目的別分類（ｎ＝１２２）

2.1.3. 基本情報：運営母体の種別

運営母体として企業・団体が主導しているものと、ほぼ同等の規模でコミュニティ1・個人が主

導しているものがある。

図 2-5 基本情報 運営団体の種別（ｎ＝１４５（運営者＝１１３／技術者＝３２））

1 なお、本アンケートでは「コミュニティ」の意味合いを特に限定しなかった。活動実態からする

と、地域社会のグループはもちろんのこと、特定の技術をテーマにしたオンラインのグループも含

まれているものと考えられる。

23

18

12

10

7

7

6

5

5

5

4

4

3

3

2

2

2

2

1

1

0 5 10 15 20 25

災害情報

活動支援

生活情報

寄付・チャリティ

文化支援

住宅支援

IT支援

放射能情報

物資支援

被災者支援

復旧復興支援

停電

交通情報

ボランティア支援

通信環境情報

教育支援

海外発信

医療福祉情報

福祉支援

ボランティア情報

全回答者 運営団体の種別（一つの支援サイト等について同一人物が運営者向けと技術者向け両方に回答している

場合、運営者向けのみを採用）

22.1%

20.0%

19.3%

15.2%

6.2%

4.1%

2.1%

0.7%

0.0%

10.3%

企　業

コミュニティ

NPO

個　人

社団法人

財団法人

教育機関

官公庁

自治体

その他

11

2.1.4. 基本情報：取り扱ったデータの種類と技術的特徴、公開日、現在の状況

地理情報が多くのサービスで共通的に用いられた。また情報源、支援者、支援対象などさまざまな役割

で、個人の情報が扱われた。その中には、非常時特有の、避難情報なども含まれている。他方、個人情報を

直接扱わず、Twitterなど他のサイトのアカウント情報で代替する例も少なくない。

図 2-6 基本情報 取り扱ったデータの種類（当てはまるもの全て選択）（ｎ＝１４３（運営者＝１１２／技術者＝

３１））

特徴的な利用技術について自由記述を求めた。この項目については後の章で裏付けられているが、

Webサイトのコンテンツ関連では、twitter, Wiki、CMS・ブログツール、Googleの各サービスが挙げられ

た。地理情報関連ではGoogle Mapsの活用が多くみられる。企業・団体からのサービス提供を活用した

ケースもある。

また、サーバー関連では、クラウドや仮想サーバーのサービスの活用を示したものが目立った。また、サ

ーバーを個別に持たず、AmazonやGoogleなどが提供するアプリケーション・サービスを活用したことも

挙げられた。さらに、スマートフォン用のアプリケーションなど、すでにアプリケーションが動作する基盤を

用いて実現した例も挙げられた。

公開日を見ると、発災後、一週間程度にリリースされたものは過半数を占めた。サイトを構築す

全回答者 取り扱ったデータの種類（一つの支援サイト等について同一人物が運営者向けと技術者向け両方に回答している

場合、運営者向けのみを採用）

44.1%

42.7%

42.0%

39.2%

37.1%

33.6%

31.5%

30.8%

30.8%

27.3%

24.5%

19.6%

16.8%

15.4%

11.9%

10.5%

8.4%

29.4%

地理情報

メールアドレス

人　名

Twitter等の他サイトのアカウント情報

住　所

物　資

寄付等の金銭にかかわる情報

電話番号

公知のニュース情報（放射能・電力・地震速報等）

風景写真

人物写真

所　属

ID・パスワード

動画・音声

決済情報

職　業

避難者名簿

その他

12

るためにすでに所有しているプラットフォームを用いたサイトは 55%程度であり、新規で調達した

ケースも少なくない。なお、１年後にサイト機能を終了させているサイトは 20%程度にとどまって

おり、多くがサービスを継続している。

図 2-7 基本情報 プラットフォーム選択の状況（ｎ＝１４５（運営者＝１０８／技術者＝３７））

図 2-8 基本情報 公開日（ｎ＝１４４（運営者＝１１２／技術者＝３２））

図 2-9 基本情報 支援サイト等の現在の状況（ｎ＝１４５（運営者＝１１３／技術者＝３２））

全回答者 プラットフォーム選択の状況（一つの支援サイト等について同一人物が運営者向けと技術者向け両方に回答している場

合、運営者向けのみを採用）

55.0% 45.0%

既存プラットフォーム 発災後に新たにプラットフォームの準備

全回答者　公開日（一つの支援サイト等について同一人物が運営者向けと技術者向け両方に回答している

場合、運営者向けのみを採用）

8

21

36

17

14

4

11

7

1

5

1 02 3

0 1

13

大震災以前

72時間以内

1週間以内

2週間以内

3週間以内

4週間以内

5週間以内

6週間以内

7週間以内

8週間以内

9週間以内

10週間以内

11週間以内

12週間以内

13週間以内

14週間以内

14週間超

全回答者 支援サイトの現在の状況（一つの支援サイト等について同一人物が運営者向けと技術者向け両方に回答している

場合、運営者向けのみを採用）

71.7% 19.3% 9.0%

継続中 サイトを閉鎖した、またはサービスを終了している その他

13

2.2. サイト運営全体としての活動実態

運営者の活動の経緯についてのアンケート調査結果を示す。

2.2.1. 決意フェーズ：立ち上げの動機・経緯

支援サイト等の立ち上げを決意した動機として、内発的な動機付けが目立つ。次いで、必要に動かされ、

呼びかけに応じたなどの経緯も挙げられている。ほかには、実現手段の新規性、社会的意義などの点も挙

げられた。

図 2-10 運営者向け Q1 立ち上げの動機・経緯（３つまで選択）（ｎ＝１１３）

2.2.2. 決意フェーズ：サイトの支援を決めた理由・

サイトの支援内容は、ニーズを見てとり、所属組織や自身のノウハウや技術が活かせることを考慮し決

定された。一方、所属組織や自身の必要も考慮に入れられている。

また、サイトの公開スケジュール目標に関しては、“とにかく早く公開することを目指した”が70.5％と圧

倒的に多い。これらの結果からは、活動団体等から出された具体的なニーズに基づく立ち上げよりも、自

ら支援ニーズをイメージし、所属組織や自身の持つ技術を用いて一刻も早く公開することを目指した立ち

上げが多かったことが窺える。

運営者向け Q1 なぜ支援サイトを立ち上げようと思ったのですか？

55.8%

49.6%

47.8%

22.1%

19.5%

12.4%

15.0%

自分の経験や技術を活かした貢献をしたいと思った

とにかくできることで貢献したかった

支援活動の推進に必要だった

自ら収集した情報を広く共有したいと思った

他者からの依頼や呼びかけに応えて

所属組織の指示や依頼があった

その他

14

図 2-11 運営者向け Q2 サイトの支援内容を決めた理由について（３つまで選択）（ｎ＝１１３）

2.2.3. 決意フェーズ：支援サイト等の公開スケジュールの目標

支援サイトの公開目標としては、とにかく早く公開することを目指した」が70.5%と大多数を占める。

図 2-12 運営者向け Q3 公開のスケジュールの目標（ｎ＝１１２）

2.2.4. 準備・立ち上げフェーズ：立ち上げを決めてから公開するまでに要した期間

大震災からの日付ではなく、それぞれのプロジェクトがサービスの立ち上げを決めてからサービスのリ

リースまでに要した期間を尋ねた。

6時間以内に公開したサイトが18.8％と最も多く、次いで3日間以内（16.1％）という結果であった。24

時間以内に公開したサイトを合算すると 36.7％、3日間以内での合算では52.8％となり、全体の半数以

上のサイトが、3日間以内に公開されている。

運営者向け Q2 サイトの支援内容を決めた理由について

58.4%

46.9%

40.7%

30.1%

28.3%

20.4%

12.4%

8.0%

8.0%

支援ニーズに合うと判断した

所属組織や自身のノウハウや技術が活かせる内容だった

既存の支援情報やサービスでは不十分だと思った

誰も実行していないと思った

所属組織や自身の支援活動に必要な内容だった

所属組織や自身の業務に関連した内容だった

知人や仲間の知識やアイ ディアを参考にした

支援団体等からの具体的な要請に基づいて

その他

運営者向け Q3 支援サイトの公開スケジュールの目標について

70.5%

10.7%

8.0%

3.6%

1.8%

5.4%

とにかく早く公開することを目指した

きちんと準備ができ次第公開するつもりでいた

特に設定しなかった／気がついたら始めていた

公開予定日を設定した

公開までの目標日数を設定した

その他

15

図 2-13 運営者向け Q4 公開までに要した期間（ｎ＝１１２）

2.2.5. 準備・立ち上げフェーズ：立ち上げ時のメンバー数

立ち上げ時のメンバー数は概して少数である。3人以内の合算では57.3％、6人以内の合算では

78.2％となる。

図 2-14 運営者向け Q5 立ち上げ時のメンバー数（ｎ＝１１０）

2.2.6. 準備・立ち上げフェーズ：立ち上げ時の技術者割合

全体として、技術者と運営者が約半数ずつまたは技術者のみで構成された少人数のメンバーによる立

ち上げが多かった。立ち上げ時の技術者の割合は、「25％超～50％」（40.0％）が最も多く、次いで

「100％」（34.5％）となっており、この2つで全体の74.5％を占めている。

運営者向け Q4 支援サイトの立ち上げを決めてから公開するまでに要した期間

18.8%

4.5%

13.4%

16.1%

12.5%

10.7%

11.6%

12.5%

6時間以内

12時間

24時間

3日間

1週間

2週間

1ヶ月間

その他

運営者向け Q5 立ち上げ時のメンバー数

26.4%

14.5%

16.4%

20.9%

10.9%

7.3%

3.6%

１人

２人

３人

４～６人

７～１０人

１１～２０人

２１人以上

16

図 2-15 運営者向け Q5 立ち上げ時の技術者割合（ｎ＝１１０）

運営者向け Q5 立ち上げ時の技術者割合

15.5% 40.0% 5.5% 34.5%

2.7% 1.8%

０％ ０％超～２５％ ２５％超～５０％

５０％超～７５％ ７５％超～１００％未満 １００％

17

2.2.7. 準備・立ち上げフェーズ：メンバーを集めた方法

メンバーは企業・団体内（42.0％）や知人や仲間（40.2 ％）への呼びかけが多い一方、インターネット

(25.0 ％)やコミュニティ上での呼びかけ（21.4％）も一定の割合を占めている。「その他」の記述としては、

発災後発足した単発的なイベント（Hack for Japanハッカソン、復興支援イベントなど）で呼びかけや、団

体として組織的に対応したことなどが記載された。

図 2-16 運営者向け Q5 メンバーを集めた方法（当てはまるもの全て選択）（ｎ＝１１２）

2.2.8. 準備・立ち上げフェーズ：費用の調達

費用は「運営者の自己負担」が最も多く、外部資金の調達を待たずに立ち上げた傾向が目立つが、所

属組織や外部からの支援もあったことがわかる。「その他」としては、既存資産の流用やフリーのツールの

活用により、特段の費用がかからなかったこと、また、個人がプロジェクトに寄付をするサイト（ファンドレイ

ジングサイト）での調達のケースが記載された。

図 2-17 運営者向け Q6 支援サイトの立ち上げまでに要した費用の調達（当てはまるもの全て選択）（ｎ＝１１２）

運営者向け Q5 メンバーを集めた方法

42.0%

40.2%

25.0%

21.4%

25.9%

企業・団体内での呼びかけ

知人や仲間に個別に呼びかけ

インターネットで広く呼びかけ

コミュニティでの呼びかけ

その他

運営者向け Q6 支援サイトの立ち上げまでに要した費用の調達

47.3%

36.6%

10.7%

8.9%

17.0%

運営者の自己負担

所属組織から

他の企業・団体等から

有志で出し合った

その他

18

2.2.9. 準備・立ち上げフェーズ：立ち上げの際に苦労した点

立ち上げの際に苦労した点は、「状況の変化への柔軟な対応」である。この設問では、特に自由記述の

回答数が多くその内容も多岐にわたっているが、内容として被災地の情報ニーズや支援ニーズの変化に

対する柔軟な対応、それに伴う情報の更新、リソースの確保、運営者の要望と技術者の対応可能レベルの

ギャップなどが記載された。また、「自発的なボランティア活動ならではの体制面や意思決定上の課題」が

あったことも報告されている。本設問に関しては、立ち上げの際に苦労した点についての自由記述を整理

したものを掲載する。

図 2-18 運営者向け Q7 支援サイト立ち上げの際に苦労した点（当てはまるもの全て選択）（ｎ＝１１２）

表 2-1 運営者向け Q7 「立ち上げの際に苦労した点」 自由記述による回答

設問の選択肢 対応する自由記述 キーワード

状況の変化への

柔軟な対応 ・ 避難所やニーズの変化が早く、DB登録情報の決定に苦労した。

・ 避難場所として公開される場所や収容状況が常に変わる中での状況

確認と対応。

・ 最新の情報のアップデートの頻度。

・ 必要な物資や、交通網、ボランティアの持ち物の内容を都度更新した

こと。

・ 時間経過による支援物資の要求内容が変化。

・ サイトの更新を行うメンバーの確保が十分でなく、少数の担当者の負

担が大きかった。

・ 活動の進捗や経過によってメンバーが入れ替わりそれに伴う更新・技

術者の引き継ぎが困難だった。

被災地の状況変化に合わせた情

報の更新、それを行う人員体制

リソース確保 ・ ボランティアである為、人的リソースの計画的確保は不可能。

・ 通常の仕事外でのお願いのため、土日や夜遅くにやり取りが限られて

いたため。

自発的なボランティア活動である

がゆえの人員リソース確保の難し

さ

運営者向け Q7 支援サイト立ち上げの際に苦労した点

31.3%

28.6%

16.1%

15.2%

10.7%

21.4%

25.0%

状況の変化への柔軟な対応

リソース確保

サイトの目的や特性によって異なる課題への対応

状況変化に応じた技術要素の選択

意思決定

その他

特に苦労した点はなかった

19

設問の選択肢 対応する自由記述 キーワード

サイトの目的や特

性によって異なる

課題への対応

・ 放射線量の値によって色分けする場合の基準。

・ 不特定多数のデータを扱う際の人的ミスを考慮したシステム作り。

・ 寄付や物販による法律関係、契約書関係。

・ ユーザフォロー。ボランティアだったので、手が回らなかった。

情報の扱いや基準、

法規関係、

ユーザフォローなど様々な課題へ

の対応

状況変化に応じた

技術要素の選択 ・ 当初のサイトは技術的な問題で自由な更新ができず、扱える人間が

多いソフトウェア（WordPress）に変更した。

・ 最初は個人サーバーで始めたが、すぐに負荷で耐えられなくなり移設

先が必要となった。

・ 日々追加しなければいけない情報が多いことから、そのような IT技術

面のノウハウの課題。

技術人材の不足、

サーバーのアクセス過多、システム

の運用管理

など

意思決定 ・ ボランティアという性格上、ピラミッド型ではなくフラット型なので、意

思決定に時間がかかる。

・ 運営責任者からのサイトへの要望と技術者レベルにギャップがあり、

初期段階の仕様決定に苦労。

ボランティア活動ならではの意思

決定の難しさ

2.2.10. 運営フェーズ：サイト運営にあたり、直面した課題

サイト運営面で直面した課題として、人員体制、情報収集、情報源の信頼性、支援サイトの周知・プロモ

ーションが挙げられた。その他の回答としては、ネット回線の不安定さ、接続環境の不足、取得したデータ

の著作権に関する懸念、関係者の ITリテラシーについての指摘があった。

20

図 2-19 運営者向け Q9 サイト運営にあたり、直面した課題（３つまで選択）（ｎ＝１１３）

31.0%

29.2%

23.9%

23.9%

22.1%

19.5%

14.2%

14.2%

13.3%

10.6%

8.8%

8.0%

7.1%

5.3%

1.8%

11.5%

人員体制

情報収集

情報源の信頼性

支援サイトの周知・プロモーション

使いやすさ（ユーザビリティ）

人的費用（労務費等の“ヒト”関係）

技術ノウハウ

物的費用（サーバー維持費、資材費等の“モノ”関係）

他の団体等との協業・連携

アクセスの急増によるサイトの処理能力

関連する法令や制度

運営方針や改善についてのチームの合意形成

企画・運営ノウハウ

運用面での情報セキュリティ（プライバシー保護の要請など）

技術面での情報セキュリティ（システムセキュリティなど）

その他

運営者向け Q9 サイト運営にあたり、直面した課題

21

表 2-2 運営者向け Q9 「サイト運営における直面した課題」 自由記述

設問の選択肢 主な自由記述回答 キーワード

人員体制 ・ 最初は一人でやっていたので、なかなか広まらず、開発も進まなかった。専

従者を確保できず、情報の取りまとめや更新に苦労した。

・ 当初は検索したキーワードからの炊き出し場所の表示だけでしたが、数日後

にGPSを用いて現在地から近い炊き出し場所の検索もできるようにした方

が良いと考え実装しましたが、携帯電話の各キャリアごとに端末を所有しテ

ストができる人を探すのに苦労した。

・ リリースを遵守する為、時間的リソースマネジメントを実施したかったのだ

が、ボランティアである以上、リソースマネジメントも不可能だった。

・ 計画停電実施の有無については自動化できず、手動での情報更新を行っ

た。そのため、更新作業を行う人員が必要であった。

・ 人員としては、コンテンツを作成するのが弁護士であり、かつボランティアで

あることから、持続可能性が問題となった。事務局機能はないため、個々人の

弁護士の個別作業をまとめる形になるので、どうしても遅延したり、作業時間

にも限界が出たりする。したがって、結局各方面で活躍する人材であるため、

復興支援も本格始動する中、当初の800件あまりの掲載ののちは、更新が

持続できないという課題に直面し、現在に至る。

・ ボランティア同士がメーリングリストを通してやりとりしたため、打ち合わせ

や人的リソースに限界があった。

情報の更新を中心と

した人員不足

自発的なボランティ

ア活動であるがゆえ

の人員リソースマネ

ジメントの難しさ

情報収集 ・ ニーズの情報収集がもっとも大きな課題だったと思います。初動では被災地

のWeb利用状況がつかめなかったり、またニーズが時間経過とともに変化

していったりと、そうした状況を把握することに課題および精力を傾けました。

・ 自治体のHPの情報は必ずしもわかりやすいものばかりではなく、確認をし

なければならない自治体も沢山ありました。

・ 個人から寄せられるTwitterでの情報も、文字数140字制限という制約もあ

って必ず自分がもう一度調べ直してからでなければ情報発信出来ず、確認

作業が大変でした。

・ 刻一刻と状況が変化するため実際に現地に行かないと判らない状況だっ

た。

・ 支援制度を充分に説明している情報リソースがなかった。例えば、どういった

申請書が必要か明確でない制度も多々あった。

・ 特に被災地ではインターネット環境が十分ではなく、非被災地との情報のギ

ャップを感じることが多かった。

刻々と変化する被災

地ニーズの把握

22

設問の選択肢 主な自由記述回答 キーワード

情報源の信頼性 ・ 収集情報がNPOの専門家にとって十分な情報でない場合に再確認が必要

となった。

・ APIとして公表すると、それを利用した複数の第三者サービスが立ち上がる

可能性があったため、情報の信頼性が高いサイトを選ぶのに時間をかけた。

・ 事故当初は情報が大量にあってもそれを被災者に届ける手段がなかったた

め、ひとつでも多くという意識が大きかった。しかし実際はその中にはすでに

終了している情報などもあり、信頼性の確保といった点では考慮するべきこ

とが多かったと思う。だけど、当時はそこまで配慮する余裕がなかったし、考

えてもしかたがなかったという現実もある。現時点でもどういう方法がよい

のかは答えが出ていない。

・ Twitterの内容が正しいかどうか判断することは非常に難しかった。Twitter

やFacebookのリアルな声を元に動くこともあったため、情報の信頼性は課

題になっていた。

収集情報の再確認の

必要性

APIとして公表する

場合の情報源の信頼

性

Twitterや

Facebookのリアル

な情報の信頼性

支援サイトの周知・

プロモーション

・ いかにして多くの人に読んでもらうか、アイディアを工夫した。

・ どうやって被災地域内部へ情報を届けるべきか。インターネットを超えた情報

提供の体制には不足があった。サイトの立ち上げはすぐにできたが、どうや

ってサイトの存在を知らしめるかが重要な課題であった。

・ FacebookやTwitterのアカウントを活用したり、相互リンクを張ったりした

ほか、一時的に仙台に駐在員を派遣して、役所や避難所を実際に回って情報

収集しつつ、被災者の方々に知っていただく努力をした。

インターネット以外の

情報提供の体制

多様な手段でのサイ

トの存在の周知

使いやすさ（ユー

ザビリティ）

・ 入力側にはシンプルな構造だったが、閲覧側には情報を探しにくかった。

・ 重要な情報がページ構造上、奥深くにあり、被災者の方から、Webページが

見にくいとの指摘があった。

・ 位置登録が1回でもあればMapに色がつく仕様だが、最初は位置登録件

数によって色を変えるという案も出ていました。しかし、「基地局が生きている

かどうかがわかることが重要なのだ」という結論に至り、最終的にはシンプ

ルで見やすい形にしました。

シンプルな見やすさ

情報を探しやすい

構造

人的費用

（ヒト）

・ ネット通販のリンク集なので、その通販サイトの製作者の発信している情報

を確認するマンパワーが割けなかった。これは情報リテラシー的には問題を

生じやすい。しかし、そんな贅沢を言っていられる状況ではなかったため、サ

イトを作ることを優先した。

・ 支援活動の長期化に伴い、人的・物的コストの問題が一番大きくなってい

る。現状では基本的にメンバー（約300名）のコストは一律ボランティア扱

い。

・ 被災地に取材するためには10万円単位で取材費が必要で、この費用の確

保に苦労した。

・ 人的費用があれば、人を雇えるが、ボランティアの枠を超える為、（費用があ

ったとしても）そういうアプローチは採りたくなかった。結果、リリースが遅延

している。

・ 予算があれば、また、IT関係で信頼できて実務をこなしてくれる人がいれ

ば、もっと早期に立ち上げる事ができた。

ボランティア活動とし

ての持続性

“ボランティア活動”

という性質と“人的費

用”の関係性や位置

づけ

技術ノウハウ ・ 大量の位置データのプロットをどう地図に表現するかが難しかった。

・ 技術面では新たな対応を行う必要があり、どこまで被災団体の期待に応えら

れるかわからない部分もあった。

23

設問の選択肢 主な自由記述回答 キーワード

物的費用

（モノ）

・ 震災を契機に利用者が急増し、サーバーの増設に関わる費用やサーバーの

処理向上に関わるシステム開発費用等が生じ、その工面が課題となった。

・ サイトの開発には、Microsoftからの資金は出たが、サイト設計、データ収

集、運用費用、サーバー費用などはすべて持ち出しとなっており、現在も継続

が困難な状況。

・ サーバー維持費、SSL証明書の費用が個人負担。

利用者急増に伴うサ

ーバーの処理能力向

上、運用費用の確保

他の団体等との協

業・連携

・ 同様の活動を行っている他団体との協力。

・ 協力団体などが自宅勤務体制であったため、緊急の連絡がつかず、スムー

ズにいかない面があった。

協力団体との緊急時

の連絡体制

アクセス急増によ

るサイト処理能力

・ 想定を遥かに超えるアクセス増が、システム開発を圧迫。

・ 当初1台のサーバーでサービスを開始したが、ユーザが急速に増加し、遅延

が顕著になった。

・ レンタルサーバーでの運用だったため、アクセス数増加によるサーバーへの

負荷が心配になる場面があった。

・ 最大で1日2万～3万アクセスがあったときはサーバーに負荷が掛かって

いた。

・ アクセス急増により、Amazon EC2 への移行とスケーラブルな構成の構築

に迫られた。

・ アクセス急増の対策として、コンテンツの表示件数を減らしたり、画像ファイ

ルを削除したりするなどの対応を行いました。

想定を遥かに越える

アクセスの急増

関連する法令や制

度

・ 政府からのおびただしい量の通達が分散しており統一性がなかったこと。当

初数か月で1,000～1,500という「通知」や「事務連絡」を自治体に発信した

が、自治体では、これをまともに受けて解釈し、啓発周知にも手がまわってい

なかった。このため、現地での問題点を克服すべく、東京の弁護士有志があ

つまり、主要省庁の通知などをHPから全件抜き出し、エクセルにまとめる作

業を実施した。そもそもどこに何があるのか、省庁ごとの統一性がなく、時系

列にまとまっていない省庁も多く、検索は難航を極めた。

・ 企業・政府との間での情報の流通（PDFでしか届かない、フォーマットが違

う、など）法制度と運用における問題（柔軟な政府の対応）。

・ 既存の平時の法律の複雑性が、このような状況を想定していないために、か

えって被災者にとって円滑な住まいを得ることの妨げになっていること（借地

借家法）。

・ 避難所データを行政のホームページから取得し、利用しようとしたが著作権

の保護から二次利用ができず、情報を集められなかった。

企業・政府間でのデ

ータフォーマット

法制度の制約

データの 2次利用の

著作権

企画・運営ノウハウ ・ ITはだぶつきぎみだった。重要なのはどう使うかのガイダンスであった。

・ 情報を更新し続けることが課題。

情報の更新、

サイトの活かし方

運用面の情報セキ

ュリティ

・ 現地写真を撮影する際、写っている人に掲載の許可を取っていない場合が

あり、結局使えないケースがあった。

肖像権の保護

技術面の情報セキ

ュリティ

・ 個人情報の固まりのTwitterの情報をどう扱うか、が重要な事項でした。 個人情報保護

24

設問の選択肢 主な自由記述回答 キーワード

その他 ・ クラウドシステムのためネット環境が必須にも関わらず、回線が不安定だっ

た。

・ 放射線量をあつかったので、いたずらに不安を煽らないように、なるべく感情

的な表現を削除するように苦労した。

・ 自分一人で朝から晩まで行っていたので、精神状態は大丈夫なのかと家族

にずいぶん心配をされました。

・ 日本語だけでなく、英語での情報発信を強く求められた。

・ いかに労力をかけずに、しかし継続性のある仕組みにするかということを目

指し、そのように実装したため、課題などは特にない。

クラウドシステムを使

う場合の回線の安定

性

家族からの心配

多言語対応

被災地への配慮や被

災地のネット環境を

踏まえた周知や利用

2.2.11. 運営フェーズ：他のサイトや団体との協力・連携が効果的だったもの

他のサイトや団体等との協力・連携で効果的だったものについては、サイトの周知・プロモーション、サ

イト上で提供する情報（データ）やコンテンツの連携、大手ポータルサイト等の有名サイトとの連携・相互リ

ンク、およびボランティアやNPOなど類似の活動を行うサイト間の相互リンクなど。自由記述の内容から

も、こうした相互リンクや Twitter等を通じた協力・連携に効果があったことが裏付けられる。

図 2-20 運営者向け Q10 他のサイトや団体等との協力・連携が効果的だったもの（３つまで選択）（ｎ＝１１３）

運営者向け Q10 運営にあたり、他のサイトや団体等との協力・連携が効果的だったもの

33.9%

25.0%

21.4%

21.4%

17.0%

14.3%

8.0%

6.3%

19.6%

6.3%

サイトの周知・プロモーション

サイト上で提供する情報（データ）やコンテンツの連携

大手ポータルサイト等の有名サイトとの連携・相互リンク

サイト間の相互リンク

サイト上での情報（データ）やコンテンツ提供のための人

的連携

技術面での他者からの支援

サイトに関連した共同事業や共同プロモーション

技術面での他者への支援

特に協力・連携はしなかった

その他

25

他のサイトや団体等との協力・連携で効果的だったものについては、各選択肢について、自由記述によ

る以下の回答があった。

表 2-3 運営者向け Q10 「他のサイトや団体等との効果的な協力・連携」 自由記述

設問の選択肢 主な自由記述回答 キーワード

サイトの周知・

プロモーション

・ 団体の機関紙で告知に協力いただいたほか、別の団体には電話対

応窓口を代行してもらうなど、こちらの活動体の弱い部分を支援して

もらった。

・ サーバーの負荷を下げるため、アプリのサポートサイトについては、

他の支援サイトからの協力を得た。また、サーバー増設に伴う費用を

工面している旨、他のサービスを用いてプレスリリースを発信した。

・ Twitterとの連携。

・ データ提供元との連携なしにサービス展開は不可能だった。NHK

および多くのメディアがくり返し周知を呼びかけて下さった。

・ ハナサケニッポンの共通ロゴを設けて、同じ趣旨のサイトのリンク集

を作ってくれたサイト運営者がいて、うれしく思った。

・ 取材した情報をもとに、ダイヤモンド・オンラインやYahoo!ボランテ

ィアなどの大手ポータルサイト、東北復興新聞などの媒体に記事を

寄稿。

・ Hack For Japanによるハッカソンなどでもプレゼンさせていただ

き、認知度は向上した。

・ gihyo.jpやPC Onlineで紹介して頂いた。

・ Yahoo! 様に告知いただき、利用者が急増しました。

・ サイトと同時期にメーリングリストを立ち上げることで、他団体の関係

者からの情報提供と情報共有を効果的に実施できた。

告知や電話対応におけ

る団体間協力

他の支援サイトからの

協力

データ提供元との連携

同じ趣旨のサイトのリン

ク集

大手ポータルサイトや

媒体

コミュニティへの投稿

サイト上で提供

する情報（デー

タ）やコンテン

ツの連携

・ 自分の発信している情報と同じ内容のものを系統立てて集団で発信

されるサイトが出来上がったと教えていただいた時点で、自分はそ

ちらへ誘導するリンクを貼って情報発信を終了しました。

・ 個人運営の電力使用状況を提供するサイトと連携。

・ SaaS型電子カルテの場合、電子カルテ自体を使ったことの無い医

師もいるため、現地でのレクチャーが必須だった。

同じ役割を持つサイト

への統合

サイト間の相互

リンク

・ 他サイトによって当団体を知ったという支援者が多かった。また、メデ

ィア（新聞・テレビなど）の報道によってサイト閲覧者が増加した。

・ FacebookやTwitterの活用が効果的であった。

・ API利用者にWebサイトやアプリケーション上に情報取得元として

当サイトのリンクを貼って頂いた。レンタルサーバー会社が公開した

支援サイトまとめページに掲載して頂いた。

情報源として利用する

利用者側での情報源サ

イトのリンク

26

設問の選択肢 主な自由記述回答 キーワード

大手ポータル

サイト等の有名

サイトとの連

携・相互リンク

・ 公開してすぐにブログなどでとりあげられ、いろんな人に注目しても

らえるきっかけになった。

・ Yahoo! やソフトバンクなどの災害支援サイトからのリンクで、多く

の新規ボランティアが集まった。

・ Yahoo! やGoogleといったサイトへの情報提供を行った助け合い

ジャパンと連携し、ボランティアの誘導などを行なってもらった。

・ ヤフーの震災情報の生活情報の中にリンク掲載していただいた。

大手ポータルサイト自

体やそこに災害情報を

提供する団体との連携

サイト上での情

報（データ）やコ

ンテンツ提供の

ための人的連

携

・ Facebookの有効活用。

・ ボランティアの情報や支援情報の連携。

・ ボランティア、被災者支援系の団体との相互リンクを行った。

技術面での他

者からの支援

・ お声掛けを頂き、Amazon Web Serviceに変更した。

・ 知り合った仲間とイベントなどをして、技術協力や課題解決方法の模

索などが出来た。

・ MediaWiki使用に伴い、Wikipedia JAPANの方々の支援があっ

た。これにより、Wikiでの共同編集に際しておこりがちなトラブル（編

集方針の対立等）が相当程度に回避できた（あるいは問題化しても

早期に沈静化できた）。

・ 大手SI会社よりシステムと技術者の全面協力を得られたため、DB

項目の変更やリニューアル、分析のためのデータ抽出などをスピー

ディーに実施することが可能となった。

・ Twitter等で海外の初めてコンタクトをとる技術者が何人もサポート

してくれて助かった。

・ 一定期間通信がないとネットワーク上の機器が接続を勝手に切って

しまう問題があったが、当初その原因が分からなかった。html5jのコ

ミュニティで質問して回答を頂き、対策をたてることができた。

・ ExcelのコンテンツのHP化には、Hack For Japan有志メンバーの

献身的な技術協力があった。

メーカーやクラウドサー

ビス事業者によるプラ

ットフォームの提供

技術者仲間での技術協

力

Twitter等やオンライン

上のコミュニティを通じ

た技術サポート

技術面での他

者への支援

・ 当サービスを公開した翌日に、友人が「anpi レポート」を公開した。

ただ、携帯版がなかったため、私が担当することになった。

・ radmonitor311というグループに参加することで、APIの認知が上

がった。また、技術的にも連携を深められた。

・ 手作業ではなく、機械的にTwitter上のツイートから人名や住所を抽

出する技術で得られた結果を、それを必要として下さる他の運営者

の方々に利用して頂くために、我々の活動を知って頂く事は有益でし

た。

その他 ・ 著名人のブログにて記事を書いていただいた事で、アクセス数の増

加につながり、ブログがきっかけで寄付をして下さった方もいた。

27

2.2.12. 現状・終了フェーズ：サイト上での支援を継続している理由

支援サイト等を継続している理由は、被災地の継続的な復興支援・ニーズがあり、利用者が存在してい

るためとなっている。

図 2-21 運営者向け Q11 サイト上での支援を継続している理由（３つまで選択）（ｎ＝８７）

2.2.13. 現状・終了フェーズ：支援サイト等の今後の予定

まだ継続しているサイトに問うたところ、その中では、今後終了を計画しているという回答はわずかであ

り、現在まで支援を継続しているサイトの9割以上が、何らかの形で引き続き継続する意向を示した。

自由記述からは、継続の目的として、将来の災害に備える目的や、震災のアーカイブ、震災以外の分野

への発展拡充などが挙げられている。

運営者向け Q11 サイト上での支援を継続している理由

50.0%

47.7%

45.3%

27.9%

24.4%

4.7%

0.0%

15.1%

被災地の継続的な復興支援に役立ちたいと思うため

継続的な支援ニーズがあり、それに応えるため

利用者が存在しているため

特に負担がないため

自団体や立ち上げた支援サイトの存在を継続的に社会に

認知してもらいたいため

会社や組織、周囲の理解が得られているため

終了することが負担なため

その他

28

図 2-22 運営者向け Q12 支援サイトの今後の予定（ｎ＝８６）

支援サイト等の今後の予定については、各選択肢について、自由記述による以下の回答があった。

運営者向け Q12 支援サイトの今後の予定

0.0%

5.8%

5.8%

12.8%

19.8%

23.3%

32.6%

その他

運営に必要なリソースの減少に伴い、縮小して継続する

具体的な終了の計画がある、終了を予定している

将来の災害に備え、機能や体制の強化を行いながら継続し

ていく

当面は継続するが、目的が達せられたら終了する

現時点と同等の規模、内容を可能な限り維持していく

支援ニーズの変化に対応しながら継続していく

29

表 2-4 運営者向け Q11、Q12 「継続理由と今後の予定」 自由記述による回答

主な自由記述回答（サイト継続の理由／今後の予定） キーワード

・ 今もなお、計画停電の恐れがなくなったとは言い切れないため。

・ 支援の輪を広げるため。

・ 被災地や支援の現状を伝えることで、震災の風化を防ぎたい。

・ APIを公表することで利用者の利便性に役立ちたい。

・ 復興支援はまだまだ必要であり、われわれも支援活動を続けていく。活動を続ける

限り、情報も発信していく必要がある。

継続的な復興支援に役立ち

たい

・ 現在もAPIへのアクセスが多数あることと、費用面での負担がそれほど大きくない

ため、サービスの公開を継続している。

・ 喜んで読んでくれる読者がいるため、できる限り続けたい。

・ 弊団体の支援状況を報告する為、支援が継続する限りはサイトも継続する。

・ 被災地に訪れる方から、支援の一つとして要望がある。

・ 今の現地で支援活動をしているから。

利用者がいる

・ 今後の防災・減災に役立てるため。

・ 災害の発生に備えるため。

・ もしもの時に、誰でも情報を得られるように、また、前もって知識を得られるように、サ

イトの運営を継続させています。

・ 東日本大震災に限らず、集中豪雨、竜巻、台風などの災害による多くの被災者の復

旧復興の一助となるよう継続していきたいと考えている。

将来の災害への備え

・ 3月のこの時にどのようにみんなが協力して動いて、どのように大変で頑張ってい

たかを伝える場であり、忘れないように見られる場であるのかもしれないと思い、ま

だしばらくこうして残していました。

・ このようなシステムが存在しており、一定の役に立ったという点を示すためには動

いている必要があると思っている為。

・ サイト自体は、蓄積されたメッセージの検索や寄付者および寄付先の一覧が見られ

るアーカイブサイトとして存続している。

・ 防災・減災に役立つよう、震災関連の情報をアーカイブする機関に協力するため。

・ 情報が整理された「残しておける」支援サイトであるため、利用活性化施策等は行

なっておりませんが、継続して閲覧できるようにしています。

震災のアーカイブ

・ 今後、東日本大震災に限定せず、広く災害全般に関する文化施設の情報サイトに発

展させていく予定である。

・ 寄付を集めやすくなる仕組みを継続開発。

・ 4月からネット番組を立ち上げ配信を始めた。今後もさらに内容を充実させ継続させ

ていきたい。他の支援団体と協働して、もっと大きな支援活動をプロデュースしてい

きたい。被災地以外の人にも利用できるようなシステムに変更できないか模索して

います。

・ 被災地からのフィードバックによって、更にコンテンツを増やしたり公開方法を検討

したりする等、対応を考える予定。

震災以外の分野への発展・

拡充

30

2.2.14. 現状・終了フェーズ：サイト上での支援機能を終了した理由

支援機能を終了したと回答した 26サイトの 80.6%が役割を終えたためと回答した。サイト運営者の負

担などを訴える例も見受けられる。

図 2-23 運営者向け Q13 サイト上での支援機能を終了した理由（３つまで選択）（ｎ＝２６）

運営者向け Q13 サイト上での支援機能を終了した理由

80.6%

16.1%

9.7%

9.7%

9.7%

6.5%

3.2%

0.0%

0.0%

6.5%

時間の経過と共に支援ニーズが変化し、役割を終えたた

め

運営者自身の負担が大きくなったため

サイトがあまり利用されなかったため

物的費用（モノ）の負担が大きかったため

人的費用（ヒト）の負担が大きかったため

同種の支援サイトと重複したため

法令や条例などの制度へ対応の問題

会社や組織、周囲の理解が得られなかったため

人材不足のため

その他

31

2.3. 技術支援者の活動実態

技術者向けアンケートから、運営者との関係性や技術選択に関する状況を抽出することを試みた。

以下にそのアンケート結果を示す。

2.3.1. 技術支援の経緯：運営者との関係

運営者との関係に関して、技術者が支援サイト運営者本人である例が約半数を占めている。同一組織

のメンバーであったケースや、会社や仕事を通じた関係など、旧知の関係であることがそれに続いている。

発災後に知り合った関係に絞ると、ITコミュニティやボランティアを通じた紹介、TwitterやFacebookで

の呼びかけなどで知り合った関係などが挙げられている。

図 2-24 技術者向け Q1 運営者との関係（ｎ＝７２）

2.3.2. 技術支援の経緯：支援を決めた理由

自分の技術やスキルを活かした貢献をしたいとの動機が全体の 62.5％と多数であった。その具体的な

理由として、遠隔地でできる支援であることや、技術者的意欲など、IT分野での支援ならではの経緯がわ

かる。

技術者向け Q１ 運営者との関係

47.2%

15.3%

13.9%

6.9%

5.6%

2.8%

2.8%

1.4%

4.2%

支援サイト運営者本人

同一組織のメンバーであった

会社や仕事を通じた関係があった

友人関係や個人的なつながりで関係があった

支援依頼や紹介があった

インターネットやソーシャルメディア等のつながりで

インターネットやソーシャルメディア等での募集を見て

コミュニティ活動やボランティア活動を通じた関係があった

その他

32

図 2-25 技術者向け Q2 支援を決めた理由（３つまで選択）（ｎ＝７２）

技術者向け Q2 支援を決めた理由

62.5%

31.9%

20.8%

18.1%

9.7%

5.6%

15.3%

自分の技術スキルを活かした貢献をしたいと思ったから

支援サイトの趣旨に共感したから

会社や仕事の人間関係があったから

リアルな人脈を通じて知人から依頼されたから

所属するコミュニティへの依頼があったから

特に積極的な理由はなかった

その他

33

表 2-5 技術者向け Q2 「支援を決めた理由」についての自由記述

主な自由記述回答 キーワード

・ 一国民として当然の行動でした。

・ できることをしなければ、と思ったから。

・ （前略）たまたま自分には貢献できるとしたら IT分野における技術しかなかったの

でそうしたのです。

・ 阪神の経験があり（中略）なにかできないかという想いがありました。開発のきっか

けは、友人の「これできたらいいのにな」という一言を聞き、「よし作ろう」となって開

発に至りました。

貢献したいという思い

・ 阪神淡路大震災を経験している身としては、今回の被災地から遠くても、なにかで

きないかと思っていたから。

・ 場所の制約なく、貢献できると思ったから。

・ 自分は子供を育てているため、直接現地に赴いての復興支援はできません。しか

し、

・ 活動によっては、自分でもできることがたくさんあると思い、参加しました。

・ 現地に赴かなくても、空いた時間で、サイトの更新ができることに魅力を感じた。

・ 実際には仕事の都合で現地には一度しか行けませんでした。しかし、リモートでの

支援もできるはずだと思っていたので参加に至りました。

遠隔地から可能な支援

・ 震災後に募金以外の活動でも何かしら行動すべきと感じました。

・ 金銭面的な支援よりも有効なことはできないかと考えていた時にお話を頂きまし

た。

募金以外の支援

・ 自社で保有する位置登録情報やサービスをみなさまに役立てていただけると考え

たから。

・ 人のために役立つ無料アプリを作りたかった。

・ 震災が発生したとき、ちょうど弊社緊急地震速報配信サービスの開発と運用を担当

していました。その基盤や知識を利用して、多くの人の役に立ちたいと思ったからで

す。

・ 過去にCtoCの物を取り扱うサービスの開発経験があったため、ノウハウが物資支

援に役立てられると開発を行った。

保有する技術やノウハウを生か

した支援

・ 支援活動団体の後方支援や、震災の記録アーカイブが必要。

・ 自分自身が阪神の震災で被災したわけではありませんが、被災地に足を運んで学

校や体育館などの「避難所」での生活がどんなに大変で、そしていつまでもその場

にいられるわけではない事を知っていたので、できるだけ迅速に仮の居住場所の

確保をできるように情報提供の手伝いができればと動き始めました。

被災地の現状やニーズを踏ま

えた支援

・ 電力の表示が分かりづらかったから。

・ wikiシステムの立ち上げをみていて、いくつか改善点があることがわかり、自分が

やることによってもっとよくなることがはっきりしていたため。

・ 当時の東京電力は現在の電力使用状況をグラフで掲載していたが、必要な情報が

すぐに判別できるとは言いづらいものだったため、興味を引いてもらえそうなデザ

インで作り直した。

技術者的意欲からの支援

34

2.3.3. 技術支援の経緯：支援へのかかわり方

また、支援へのかかわり方として、会社や所属組織を離れた個人としてのボランタリーな活動としての

立場が多数を占めた。しかし、所属団体の理解を得て業務の一環とすることができた例もある。また、全体

の 4分の１程度が複数のサイトへの支援を行なった。

図 2-26 技術者向け Q3 支援へのかかわり方（ｎ＝７２）

図 2-27 技術者向け Q4 他に支援をしたサイト（ｎ＝６９）

支援へのかかわり方について、各選択肢について、自由記述による以下の回答があった。

表 2-6 技術者向け Q3 「支援へのかかわり方」 についての自由記述

主な自由記述回答 キーワード

・ ボランティア活動は、会社の業務とは切り離して活動。長期に渡る個人的なボラン

ティア活動の経験から、スタッフのマネジメント、チームづくりにも貢献できると判断

したため。また会社で行うと、共にワークしてくれるスタッフから利益相反の有無を

問われることになり、指揮が落ちると判断しているため。

・ 会社を経営しているものなので、会社を介在させることはできるのですが、それを

するとさまざまな人に手伝ってもらうことが困難なので、当方が個人的に中心となっ

て進めております。

自発的な活動を会社の業務と

して行う上での課題

ボランティア活動のチームづく

りや協働に対するメリット

・ 自分一人だけの会社だったので、ほぼ業務になった。

・ 個人事業主なので、個人的な開発であっても屋号としての責任を負うと思っていま

す。

・ フリーランスなのでどれとも取りにくいですが、基本的には個人的な意思です。そ

個人の場合の自由度と業務と

の関係

技術者向け Q3　支援へのかかわり方

2.8%

18.1%

34.7%

44.4%

その他

会社や所属組織の理解の下でのボランタリーな活動

会社や所属組織の業務の一環

会社や所属組織を離れた個人としてのボランタリーな活動

技術者向け Q4 他に支援をしたサイト

あり, 26.1% なし, 73.9%

35

主な自由記述回答 キーワード

の活動がフリーランスエンジニアとしての実績になり得ることも否定しませんが。

・ 活動内容を業務の一環として認めるよう説得し理解していただいた。

・ 最初は上司の理解の下でのボランティア。公開するにあたり、法務関連の部署を説

得し、偉い人を説得して業務の一環となりました。

所属する会社の理解

36

2.3.4. 技術支援の経緯：関与したフェーズと果たした役割

多くの技術者がサイトのライフサイクル全体にかかわっている。技術的に果たした役割は多岐にわたる。

Webサイトに不可欠である、システム運用管理やデザイン・コンテンツ制作、ユーザインターフェースに携

わった技術者が多い。

自由記述による設問回答からは、サーバー、アプリケーション、デザイン、クラウドサービス等の利用技

術、情報コンテンツの入力更新のほか、サーバー提供会社探し、パソコン設置の支援といった周辺的な技

術支援も挙げられた。

図 2-28 技術者向け Q5 かかわったフェーズ（当てはまるもの全て選択）（ｎ＝７２）

図 2-29 技術者向け Q6 かかわった技術分野（当てはまるもの全て選択）（ｎ＝７２）

技術者向け Q5 かかわったフェーズ

76.4%

84.7%

93.1%

55.6%

サイトの企画段階

サイトの構築段階（サイトの公開まで）

サイトの運営段階（サイト公開後の運営・改良）

サイトの展開／終了段階

技術者向け Q6 かかわった技術分野

66.7%

61.1%

54.2%

52.8%

40.3%

37.5%

37.5%

33.3%

25.0%

22.2%

13.9%

システム運用管理

デザイン・コンテンツ制作

ユーザーインターフェース

プログラミング

ネットワーク関連

サーバー構築

技術ノウハウの提供

外部サービスの初期登録・設定等

クラウドサービス関連

セキュリティ関連

その他

37

2.3.5. 利用した技術部品：稼働環境に関する設問

以降の節においては、支援サイト等の立ち上げや運営において技術者がかかわった技術分野・技術上

の課題や工夫の中で、技術部品に関するアンケート結果を整理する。

アンケートは、分類と選択肢を示す形をとった。得られた回答を分類ごとに整理すると、特徴的な技術部

品について垣間見られるものの、必ずしも統計的な意味合いを持つと判断できるほどの回答数にはなっ

ていないものと考えられる。

また、回答者によって同じ技術部品でも、用途が異なるなどの理由で、同じ技術部品について複数の項

目の中で回答された例も見られる。

そこで、本節で示す技術部品の分類ごとのグラフと「その他」の回答についての記載は、それぞれの分

類において選択された技術部品についての回答を、可能な限りそのままの形で示すものである。

稼働環境に関する設問の最初に、プラットフォーム、サーバOS、サーバサービスについて尋ねた。ここ

では、Linuxなどのオープンに入手しやすいものが使われたことのほか、サーバ環境を構築せずに、コミ

ュニケーション機能を持つウェブサイトや、サーバ機能をほとんど考えずにアプリケーションを動作させる

ことの可能なサービス（PaaS）を利用する例が目立つ。スマートフォンのアプリケーションも、サーバ構築

を意識しないものがある。

技術者向け Q７－A 技術部品 プラットフォーム

35

21

20

10

10

3

7

Facebook、mixi、TwitterなどのSNSサービス

自身もしくは運営団体が所有するサーバー

レンタルサーバーサービス

ブログサイト

SaaS、PaaS、IaaSなどのクラウドサービス

VPSなどの仮想アプライアンスサービス

その他

38

図 2-30 技術者向け Q7-A 技術部品（プラットフォーム）（当てはまるもの全て選択）（ｎ＝６５）

「その他」： Picasa、ｅコミュニティ・プラットフォーム、toggeter、Google Sites、AWS

図 2-31 技術者向け Q7-B 技術部品（サーバーOS）（当てはまるもの全て選択）（ｎ＝５４）

「その他」： iOS、GAE、Google、Cloud

図 2-32 技術者向け Q7-C 技術部品 （サーバーサービス）（当てはまるもの全て選択）（ｎ＝４７）

「その他」： node.js、GAE、Google、Cloud

2.3.6. 利用した技術部品：開発手段についての設問

システム開発に用いた開発言語、開発環境、技術部品としてフレームワークやデータベースやCMS(コ

ンテンツ管理システム)などの利用について尋ねた。HTML, CSS, JavaScriptなどのウェブサイト構築の

ために一般的に利用されるものを別にすると、WordPressなどのCMSの利用は目立っており、コンテン

ツを迅速に取り扱うことのできる仕組みの採用が目立った。詳細な技術手段については多岐にわたってお

り、特に迅速な開発につながるとされるフレームワークなどでは、特定の手段が目立つものとはならなかっ

技術者向け Q７－B 技術部品 サーバーのオペレーティングシステム

21

12

8

7

4

9

Linuxディストリビューション（コミュニティベース）

Microsoft Windows

Linuxディストリビューション（商用）

FreeBSD／OpenBSD

Mac OS X

その他

技術者向け Q７－C 技術部品 サーバーサービス

31

2

2

1

14

Apache HTTP Server

Microsoft IIS（Internet Information Services）

Tomcat

Sun Java System Web Server

その他

39

た。

図 2-33 技術者向け Q7-D 技術部品（開発言語）（当てはまるもの全て選択）（ｎ＝５９）

「その他」: Adobe ColdFusion、C++、C、Jimdoレベル、WordPress

技術者向け Q７－D 技術部品 開発言語

38

30

30

26

19

13

6

6

4

4

3

3

3

2

2

1

1

1

1

9

HTML

CSS

JavaScript

PHP

jQuery

HTML5

Perl

Java

Python

Java Servlet／JSP

prototype.js

Ruby

Objective-C

Adobe Flash

Visual Basic

Canvas

Silverlight

ASP／ASP.NET

.NET Framework (C, C++, C#, F#)

その他

40

図 2-34 技術者向け Q7-E 技術部品（IDEや開発環境）（当てはまるもの全て選択）（ｎ＝４３）

「その他」： Dashcode、Jimdo、Coda、WordPress

図 2-35 技術者向け Q7-F 技術部品（フレームワーク）（当てはまるもの全て選択）（ｎ＝１８）

「その他」： GAE、Jimdo、jQuery Bootstrap、Rhaco、Cocoa

技術者向け Q７－E 技術部品 IDEや開発環境

12

8

7

7

4

2

2

2

1

1

10

Eclipse

vi/vim

Emacs

Adobe Dreamweaver

Apple Xcode

NetBeans

Microsoft Visual Studio

EmEditor

JDeveloper

Microsoft Visual Web Developer

その他

技術者向け Q７－F 技術部品 フレームワーク

2

2

2

1

11

Zend Framework

CakePHP

Ruby on Rails

Django

その他

41

図 2-36 技術者向け Q7-G 技術部品（データベース管理システム）（当てはまるもの全て選択）（ｎ＝４２）

「その他」：Mongo DB、BigTable、DaRuMa、テキストファイル、JIMBO、Core Data

図 2-37 技術者向け Q7-H 技術部品（CMS）（当てはまるもの全て選択）（ｎ＝３０）

「その他」： ｅコミュニティ・プラットフォーム、Google Sites、自社製CMS

技術者向け Q７－G 技術部品 データベース管理システム

26

6

3

3

1

1

10

MySQL

PostgreSQL

SQLite

Microsoft SQL Server

Microsoft Access

Microsoft Excel

その他

技術者向け Q７－H 技術部品 CMS

11

6

3

2

1

7

WordPress

PukiWiki

Movable Type

ｅコミュニケーション プラットフォーム*

MediaWiki

その他

42

2.3.7. 利用した技術部品：プロジェクト推進・チーム内コミュニケーション

プロジェクトを推進するためのコミュニケーション手段について尋ねた。進捗管理やバグトラッ

キング、またバージョン管理を利用した例は全体からすればそれほど多くない。また、利用してい

る場合でもその手段はそれぞれである。

コミュニケーションのためには、旧来から用いることに慣れているもの fmlなどのメーリングリ

スト配送システム、Skypeなどのオンラインチャット・通話システムを活用したと見られる。

図 2-38 技術者向け Q7-I 技術部品（進捗管理やバグトラッキング）（当てはまるもの全て選択）（ｎ＝２８）

「その他」： Pivotal Tracker、Google Sites、Google Docs、fml

図 2-39 技術者向け Q7-J 技術部品（バージョン管理）（当てはまるもの全て選択）（ｎ＝２３）

「その他」：fml

技術者向け Q７－I 技術部品 進捗管理やバグトラッキング

8

5

3

3

1

1

10

Google Apps　

Redmine

Trac

Microsoft Excel

MantisBT

Bugzilla

その他

技術者向け Q７－J 技術部品 バージョン管理

8

7

2

1

1

5

Git

Apache Subversion

CVS

Bazaar

Mercurial

その他

43

図 2-40技術者向け Q7-K 技術部品（チーム内コミュニケーション）（当てはまるもの全て選択）（ｎ＝４８）

「その他」： チャットワーク、IPメッセンジャー、Google Sites、Twitter、メール

2.3.8. 利用した技術部品：技術部品選択にあたり注意した点

技術部品選択にあたり注意した点としては、使い慣れていること／実績があること、早期に開発や設定

が終わることが重視されている。

技術選択に情勢を考慮に入れた例を挙げた回答者もいた。たとえば、被災地で被災者が情報を見るた

めにはまだ電気などが十分に確保出来ない状況であること、PCでの情報検索は困難と考えた、などの点

である。

24

22

16

15

14

8

2

2

1

1

6

メーリングリスト

Skype

Facebook

Dropbox

Google ドキュメント

サイボウズLive

Twitter*

チャットワーク*

desknet’s

IRC

その他

技術者向け Q７－K 技術部品 チーム内コミュニケーション

44

図 2-41技術者向け Q8 技術部品選択にあたり注意した点（３つまで選択）（ｎ＝７２）

技術者向け Q8 技術部品選択にあたり注意した点

65.3%

58.3%

50.0%

34.7%

25.0%

11.1%

使い慣れていること／実績があること

早期に開発や設定が終わること

費用や開発工数の負担が少ないこと

支援サイトの目的に適していること

広く使われている技術（標準技術）であること

その他

45

2.4. サイト運営に必要な情報の収集、サイトで使用する情報の取得と取り扱い

ここでは、サイト運営上必要だった情報、またウェブサイトで用いたコンテンツ・データの取得と取り扱

いに関するアンケート結果を整理する。

2.4.1. サイト運営のために必要な情報の収集手段

運営者に尋ねたところ、サイト運営に必要な情報収集手段はWebサイトや SNSが活用され、インター

ネットでの収集が多くを占める。他方、連携団体や、被災地に直接赴く、あるいは電話などを用いた、人手

による情報収集を実施した例も少なくない。

インターネット上での収集に関しては、TwitterやAPIの機能を用いた自動収集、公的機関のサイトを

含むWebサイトからの収集、利用者によるサイトへの直接的な情報提供・投稿がある。

図 2-42 運営者向け Q8 サイト運営に必要な情報の収集手段（当てはまるもの全て選択）（ｎ＝１１３）

表 2-7 運営者向け Q8 「情報の収集手段」 自由記述による回答

設問の選択肢 主な自由記述回答 キーワード

運営者向け Q8 サイト運営に必要な情報の収集手段

61.9%

44.2%

39.8%

33.6%

31.0%

30.1%

28.3%

14.2%

14.2%

WebサイトやSNSなどを通じて

連携団体等を通じて

メンバーが被災地に直接赴いて

公的機関や企業の配信情報を利用

新聞やTVなどのマスメディアを通じて

個人から寄せられて

運営している支援サイトの利用者から

電話取材により

その他

46

設問の選択肢 主な自由記述回答 キーワード

Webサイトや

SNSなどを通じて ・ 基本的には、Webで公開されている情報の2次利用。個人から

は間違いや新しい情報などを指摘していただいた。

・ ネットで見つけた被災地通信設備関連情報を利用、英語のブロ

グ記事を書きました。

・ サイトの知名度が全くなかったため、Twitterからの情報収集を

主に行った。

・ 緊急地震速報を配信しているTwitterのアカウントから

Streaming APIを通じて情報を取得。

TwitterやAPIの機能を用いた自動収

集

連携団体等を通じ

て・メンバーが被

災地に赴いて

・ 初期は電話・ネットが長期に渡って通じにくかったため、物資配

送時に現地で見たり聞いたりして収集した情報が正確だった。

中期においては、無作為に電話帳で選んだ被災地の電話番号

へ電話をかけることにより、冷静な生の情報収集ができた。

・ 被災地現地で自主的に活動している学生たちなど外部の有志

とコミュニティを形成して収集活動をおこなった。

情報の人手による収集、

被災地スタッフからの報告、直接現地に

赴く、電話を使う、など

公的機関や企業

の配信情報を利

用・新聞やTVな

どのマスメディア

を通じて

・ 内閣府防災担当が震災前から公開していた資料などを基にデ

ータを作成。

・ 経産省の復旧・復興支援制度データベースや都道府県Webサ

イトを利用。

・ 文科省の放射線モニタリング情報を参考にしているため。

・ 基本的には東京電力が公開している資料をもとに計画停電の

データベースを構築し、資料で間違っている箇所などを、利用者

の方から教えて頂いた。計画停電実施の有無については、テレ

ビ・各種ポータルサイトの情報も利用した。

放射線や計画停電情報等を中心とした、

公的機関が提供する情報のサイトを通

じた収集

個人から寄せられ

て・運営している

支援サイトの利用

者から

・ 元々投稿型のサイトであったため、ユーザ様からの投稿に頼り

ました。

・ ログイン処理を省略し、まずは知っている人が知らない人へ伝

えるという面から誰でも書き込めるようにしていた。

・ メッセージの収集と寄付の促進およびサイトのプロモーション

自体が自動でまわる仕組み

利用者によるサイトへの投稿

47

2.4.2. コンテンツ・データの取得と取り扱い：情報源と取得手段

サイトで取り扱うコンテンツ・データの情報源に関しては、サイト上の情報や被災地メンバー、公的

機関、ボランティア機関、また同様のデータを扱う支援サイトなど多岐にわたる。

情報の取得、加工、処理に関しては、プログラムによる手段と人手による手段の両方がとられており、

APIによる自動取得や Twitterの投稿、現地スタッフからの情報、政府・自治体が行った公開情報の取得

である。取得のタイミングや加工に関しても、APIでの自動取得の場合は定期的に、利用者の投稿など、ト

リガーのあるものはそのタイミング（不定期）となっている。

表 2-8 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「情報源」（ｎ＝４８）

種別 回答内容

WebサイトやSNS ・ 全国の支援者、仲間達からの情報、Twitterのつぶやき。

・ Twitter API（Streaming API）。

・ Google Maps でのマイマップ「炊き出しまっぷ」の kmlを利用。

・ 電力供給状況API。

・ 自社サービスの位置情報ゲームプラットフォームで得られたユーザの位置登録情報（緯度、経度、時刻）

・ Hack For Japan、Google Crisis Response、助け合いジャパン、API、Yahoo! デベロッパネットワーク、政

府内閣官房の国民保護ポータルサイト、電力会社、原子力発電所運営事業体の公式サイトを総合。

被災地の人物や団体か

らの直接情報

・ 現地に入っているメンバー、調査員が避難所を巡回してヒアリングして来た内容。

・ メール、電話によるヒアリング。

・ 関連する支援団体から提供された情報。各ボランティアセンター/社会福祉協議会が運営しているWebサ

イト、ブログ、Twitter等の公開情報。

公的機関や企業の配

信情報・マスメディア

・ ホンダ・トヨタ提供の通行実績情報、コミュニティサイトによるガススタンド情報、自治体が公開する通行止

め情報。

・ 書籍、雑誌、本、ラジオ放送

・ 各地方自治体のホームページ。

・ ニュースサイト。

・ 自治体の防災無線での放送情報

・ 東京電力のホームページ、Twitterアカウント、テレビ、各種ポータルサイト、API利用者からの情報。

・ 気象庁が発表する緊急地震速報 高度利用者向け

・ 復旧・復興支援制度データベース

個人・サイト利用者・そ

の他

・ サイト利用者の投稿

・ 運営会社の入力。

48

表 2-9 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「取得手段」について（ｎ＝４９）

種別 回答内容（抜粋）

投稿・Web検索 ・ Web、投稿。

・ Twitter、メール、Webサイトへの投稿など。

・ 地方自治体のHPを毎日巡って。

・ Webの閲覧、 RSS の取得。

・ Webをこちらから見に行く。Twitterで依頼される。

・ HP/ブログを手動で巡回、運営Twitterアカウントからのフォロー。

・ メール、Twitterクライアント（HootSuiteなど）。

・ ユーザからの投稿。

・ ユーザからのPaypal支援の決済メールと、運営会社のメール。

・ Twitterを介してのAPI利用者からの情報提供。

・ Google Maps でのマイマップ「炊き出しまっぷ」の kmlの情報。

WebAPI ・ Web API。

・ Google Maps API。

・ Twitter API。

・ API引用元を明記した上での手作業による転記。

・ スクレイピング、グラフ画像解析、API。

情報通信手段 ・ 気象庁と弊社を専用線で直結し、TCP にて受信。

人手 ・ 現地に入っているメンバーより。

・ 支援対象者、避難所運営者へのヒアリング。

・ 関係者からのメール、電話、Twitter。

・ メール

・ 電話、郵便、Skype。

・ メッセージ収集、協賛金の募集はユーザからの投稿、または申請による。

・ テレビの視聴。

既存プラットフォー

ムの利用

・ 既存のプラットフォームを活用。

・ 直接、既存サーバーにあるデータへのアクセス。

49

2.4.3. コンテンツ・データの取得と取り扱い：情報取得のタイミング

表 2-10 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得「取得タイミング」について（ｎ＝４５）

頻度 回答内容

1日1回 ・ 現地ヒアリング調査を平日実施し、夕方夜間に入力作業

・ 1日1回取得

・ 1日1回深夜のバッチ処理にてデータを加工しています。

・ 1日1度（だったと思います）、cronにてWeb API より取得。

・ 基本的に、1日に1回、夜。

短い間隔 ・ 30秒毎に取得。

・ 10分毎に取得。

・ 15分に1回。

・ 30分間はサーバー内のキャッシュを読むようにし、30 分ごとに取得するようにしました。

・ 30分間隔のクーロンによる定期取得です。

・ 60分毎に取得

随時・都度 ・ 随時更新。

・ 更新の有無はRSS等で効率的に取得。

・ ただ必死に、HPを巡って探し当てていきました。

・ APIにより都度取得。

・ その都度。

・ 気づいた時に。

・ 情報提供元からリアルタイムに受信。発表から 1 秒以内に取得。

サイト利用者のアクシ

ョンをトリガーに

・ サイト利用者のアクション。（2名）

・ サイト利用者、情報提供サイトからの投稿（メール）。

・ ユーザの投稿または申請の都度。

自動 ・ 常時接続。

・ クライアントの自動リロード機能。

その他 ・ ソフト起動時。

・ FTPなどでは困難です。。。

・ 1日3回程度。

50

2.4.4. コンテンツ・データの取得と取り扱い：取得したデータの加工・処理

表 2-11 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「データの加工・処理」について（ｎ＝４

１）

種別 回答内容

手動 ・ 人手、人力。

・ JavaScriptコードに手作業で書き込み。

・ 完全に手動。情報の取捨選択が人間にしか出来ないため。

・ 見出しと要点を書き、詳細は各サイトのURLを貼る。

・ APIから取得したデータを処理。避難所等、固定的なデータは手作業により転記。

・ HTMLソースからのデータ切り出し。

自動取得・分析 ・ nodeでパース。

・ Rubyとデータベースによる情報集約・分割。

・ 受信したデータから正規表現を使って切り出し。

・ 自作で取り込み。

・ 弊社運営の既存のWebサービスの既存システムによる。

・ kml の情報を解析。

・ JSONデータのパース

・ バリデーション。

・ Twitter APIからの xml取得と、HTMLソースからのスクレイピング。

加工して情報編集 ・ Google Sitesの機能を利用。またTwitter連携や更新一覧の表示にガジェットを作成。

・ ファイル形式、ディレクトリ、ファイル名などが不明確で、その処理にも膨大な時間がかかりました。

・ csvデータをエクスポートして統計分析。

・ 出来るだけ必要事項を一度（140字）で発信出来るように必要事項（自治体名、募集人数、無償期間、応募期

間等）だけを情報として編集。

・ スクレイピングし、グラフ画像を解析。

・ 外部APIからのデータを切り出し、検索、XMLフォーマットへの埋め込み。

・ APIからの JSONデータ取得、解析、その後HTMLとしてアウトプット。

・ 記事をEmacsに書き出し加工してツイート。

・ テキストエディター・正規表現によるExcelデータの整形。

51

2.4.5. コンテンツ・データの取得と取り扱い：マッシュアップに関する課題

マッシュアップによる実現手段の課題として、許容されるアクセス頻度、接続数、遅延の問題がある。ま

た通常のセキュリティ意識を無理に緩和して実現することの必要を感じたと述べた投稿もあった。

図 2-43 技術者向け Q10 マッシュアップの際の注意点（３つまで選択）（ｎ＝７２）

2.4.6. コンテンツ・データの取得と取り扱い：情報の信憑性や鮮度の維持についての課題

情報の信憑性や鮮度の維持に関しては、利用者の自主判断に任せるなど、性善説を前提としたサイト

がある。また、免責事項の表示や、規約の明確化、必要最小限の情報や最新の情報への絞り込みによって

ある程度のリスク回避を試みたサイトもある。情報の信憑性を確認するために、人海戦術によって確認を

行っていたサイトも少なくない。

表 2-12 技術者向け Q11 サイト運営にあたって行った「取り扱う情報の信憑性や鮮度の維持」（ｎ＝４０）

回答内容（抜粋） キーワード

・ 編集・校正した記事を公開前にステージング環境にてメンバー内で確認し、誤った情報が公開されな

いようにしました。

・ 情報の信頼性や鮮度は、相手側運営サイトを人手で直接確認している、直接依頼が来る等でとくに問

題は無い。古い情報は人手で取り除く事も平行して行っている。

・ 計画停電実施の有無については、正確性を重視するため手動で行ったが、更新作業をする手間が大き

な負担となった。

人手でのチェックを基本とした

対応

・ 詳しい事は各自が自治体に直接確認する方がよいと考え、素早い情報発信を優先して必要最低限の 信憑性の高い情報への提供情

技術者向け Q10 マッシュアップの際の注意点

29.2%

26.4%

22.2%

20.8%

13.9%

13.9%

12.5%

9.7%

5.6%

4.2%

16.7%

マッシュアップは用いなかった

ユーザーインターフェースに関する問題

情報源のデータフォーマットに関する問題

アクセス過多による問題

問い合わせ先APIのアクセス制限

内部データと外部データの連携

文字コード等のデータ形式に関する問題

キャッシュにまつわる問題

複数のAPIの同時並行処理に関する問題

セキュリティ制御の必要性

その他

52

回答内容（抜粋） キーワード

情報だけを流しました。簡易な情報ではあっても正確な事のみ発信するように電話確認等で必ず不明

な事項は確認を取りました。

・ ボランティアの募集については信憑性の高いものしか掲示しない。調べるボランティアセンターの数

が多いため、住所変更などはタイムリーに調べられなかった。ほとんど気力の問題。

・ 掲載内容を人力で1日1回更新している。信憑性についてはボランティアセンターの公式サイトに載

った情報のみを拡散した。

報の絞りこみによる対応

・ 通行実績については、以前からの関係で信頼関係があった。通行止め情報は、県による公式情報を元

にした。ガススタンド情報は、コミュニティ情報であるため、その旨を明記した上で公開。

・ 送信される位置情報に関しては、携帯電話より機械的に送信されるもので信憑性は高いと思っていま

す。

・ 政府から出ている情報なので問題はないと認識しています。

・ 公式ソースなので信頼性はすべて東京電力に任せられる。

・ ツイート時に情報元の更新日をつける。公式アカウント/HP/ブログの情報のみを用いる。ラジオ放送

コンテンツなので何ら問題ありません。

政府など元々信憑性がある情

報源の情報を用いる

・ 個人情報を開示させることで信憑性を高める。

・ 情報源と情報記入者、日付を必ず記入すること。履歴を残すこと。憶測はかかず、事実のみを書くように

することをルールとした。

・ ソースをなるべく変えないようにした。

・ 発信元、発信日時を明示1-2日ごとに更新状況を確認。

・ Twitter プロフィール欄と弊社サイトにて、免責事項を記載。

ルールや規約の明確化による

対応

・ データに対して、嘘だったとか古いといった情報をフィードバックできるようにし、それを重み付けした

上で検索にヒットしないようにした。

・ 収集データをもとに毎週統計分析情報の公開を実施していた。

技術面やサイトの機能面での

工夫による対応

・ 情報元である「炊き出しまっぷ」は、個別で登録されているため、信憑性の担保はありませんでしたが、

非常時の情報提供ということで信頼しました。

・ 情報自体の信憑性については、判断（フィルタリング）せず、質よりも量を優先した。

・ 性善説に基づき、投稿されたメッセージを信用することにした。（というより、とくに何もしない）。

・ 個々のユーザの判断に任せる方針とした。その代わり判断できるだけの情報提供を促した。

あえて意図的に対応しなかった

もの

53

2.4.7. 運営状況の把握と対応：アクセス状況や利用状況の把握・分析、利便性向上改善

アクセス状況の把握をしていないサイトが多い反面、その目的も、改善を目的とするものから、アクセス

過多を警戒するものまで様々であった。

表 2-13技術者向け Q11 「アクセス状況や利用状況の把握・分析、改善」（抜粋）

回答内容

・ Google Analyticsによる解析、それに基づく改善（ほぼサイトへの誘導導線の問題）。

・ 一つのTwitterアカウントに処理が集中しないように複数のアカウントに分散するようにした

・ アクセス解析の導入（Google Analytics）

・ Twitter上でのRetweet状況をウォッチ。とくに Twitterユーザからの反応をもとに改善

・ アクセス数やアクセス元、リクエストURLはログとして記録し、APIのドキュメント作成時に参考にした。

・ クラウドを利用することで、無停止で多数のアクセスを捌いた。

利用者の利便性については、運営開始後は、利用者の声を受け付け、要望を反映したサイトの機能改

良した例や、携帯電話やスマートフォンなどへの対応を行い、できるだけ幅広い情報提供を目的とし、利用

者の情報リテラシーに対する配慮を行ったサイトも見られた。

表 2-14技術者向け Q11 「支援サイト利用者の利便性向上」（抜粋）

回答内容

・ データ取得の時間短縮のためにキャッシュを用いたり、個別に「メールを送る」ボタンを設置したりするなど。

・ ナビゲーションやページのデザインに関して特殊なデザインは取り入れず、なるべく一般的かつシンプルなサイト

デザインを心掛けた。

・ ユーザから入力のデータ型（文字数増や選択肢変更）変更の希望には都度対応していた。

・ ビジュアル的に一見して見やすいように表組みとした。

・ 関連情報を俯瞰できるよう、できるだけ簡易な一覧表とする。

・ ファイルダウンロードなどは、Word／PPTとPDF、Google共有ドキュメントの併用。低速回線環境の配慮、ことば

使い（投稿するときは、読み手に配慮）

・ ガラケー版を後追いで作成した。

・ 情報元の更新が止まっているか継続しているかをひと目で分かるようにしている。

・ 質問・要望をTwitterおよびメールで受け付け、対応可能なものについては、即時に対応を行った。

・ PCおよび携帯電話で利用可能とし、リテラシーが低い人でも利用できるように注意した。

54

55

2.4.8. セキュリティ確保のために取られた技術手段

セキュリティの確保のために実際にとられた具体的な技術手段に関して尋ねた。以下の表にあるとおり、

「アカウント情報を保持しない」、「必要以上の情報の発信は行わない」といった運用面での回避的手段や、

アクセスログやマルウェアスキャン等のツールを用いた一般的手段も挙げられたが、特別に不正アクセス

を意識した運営などの取り組みについてはごく一部にとどまった。

表 2-15技術者向け Q11 「セキュリティ確保のための具体的な技術手段」主な自由記述（抜粋）

回答内容

・ Twitterなどのアカウント情報を保持しない。

・ 当サービス内の情報を他社へ送信する場合に、携帯付属のメーラーを使用しました。

・ 情報にTwitterやメールのアドレスがはいっていた場合、該当部分の文字を置き換えるなどした。

・ 必要以上の情報の発信は行わないようにした。

・ データ処理については、Web サービスとは別に行った。

・ ID、パスワードによる書き込み制限。

・ アクセスログを定期的に分析し、不正な利用がないか監視を行った。

・ マルウェアスキャンの導入。

・ 情報公開範囲の制限・SSL・パスワード等のDB情報暗号化・トークンの発行（CSRF対応）。

2.5. 体制に関する課題

ここでは、技術者による支援サイト等の立ち上げ・運営支援の体制や、技術支援を行う上での課題や工

夫に関するアンケート結果を整理する。

2.5.1. 技術支援体制

技術支援のメンバー数は1人及び4人～6人が最も多く（共に 27.0％）、次いで 2人（22.2％）とな

っている。また、2人以下の合算では全体の半数（50.8％）を占め、比較的小規模な支援体制が多かっ

たことを裏付けている。

56

図 2-44 技術者向け Q12 技術支援メンバー数（ｎ＝６３）

図 2-45 技術者向け Q12 技術支援体制とその特徴（ｎ＝６３）

表 2-16 技術支援体制の特徴（自由記述）（抜粋）

トピック 内容

メンバー構成 ・ 全体統括：1人 システム運用：2人 運用コンテンツ作成：3人 コーデ

ィング：2人（すべて兼任ありの数字）。技術的な責任、判断は、統括の理

事が行う。コンテンツの更新は、２人の理事が中心となり、人手が足りな

くなったときに、他スタッフも作業。コーディングについては、1人の理

技術者向け Q12 技術支援メンバー数

4.8%

9.5%

27.0%

3.2%

22.2%

27.0%

1.6%

4.8%２１人以上

１１～２０人

７～１０人

４～６人

３人

２人

１人

０人

技術者向け Q12　かかわった支援サイトの技術支援体制とその特徴

88.9%

61.9%

54.0%

44.4%

52.4%

42.9%

58.7%

61.9%

69.8%

39.7%

6.3%

36.5%

44.4%

49.2%

47.6%

54.0%

41.3%

38.1%

28.6%

58.7%

4.8%

1.6%

1.6%

6.3%

3.2%

1.6%

1.6%

その他

外部サービスの初期登録・設定等

技術ノウハウの提供

デザイン・コンテンツ制作

ユーザーインターフェース

プログラミング

サーバー構築

ネットワーク関連

クラウドサービス関連

システム運用管理

０％ ０％超～２５％ ２５％超～５０％ ５０％超～７５％ ７５％超～１００％未満 １００％

57

トピック 内容

事と技術スタッフ1人。技術ノウハウの提供については、1人の理事と技

術力が高いスタッフ1人から。

・ メインの開発は、普段当社のWebシステム開発を手がける外注エンジニア

チームにて担当。デザイン関係は一部ボランティアスタッフ（プロ）が参

加。

・ Google App Engineの使用により、ほぼ全員がプログラミングに専念でき

ました。また各変更も1-2人の少人数チームでデザイン・実装・公開を担

当しました。

・ 被災自治体の公式サイトを復旧再構築するに当たり、自治体が雇用した臨

時職員3名（HP作成未経験者）に対して技術指導を行う技術者1名を提供、

その後、同自治体出身のデザイナー1名が参加して合計5名で制作を行っ

た。

・ 出来るかぎり多数のスタッフに参加してもらうために、コードを書くだけ

でなく周辺の対応などに参加してもらうことで、滞りなく運営できました。

また現在も進行中です。

・ ハッカソンで一度顔を合わせただけのメンバーで継続は可能であるか当初

は疑問がありましたが、Facebook上でのやり取りだけでリリースまで持ち

込めたのは嬉しい誤算でした。

・ 活動メンバーがJAWS-UGのメンバーという事もあり、「全員がAWS使いであ

った事」、「その支援方法が、基本的に誰がどのサイトというように、担当

がサイトごとに分かれていた事」で、技術的な分担は無く、逆にサイトを

復旧するために基盤からサーバー知識まで、各人が全て持ち合わせていた

のが特徴。

・ 通常の技術部門の運営体制のままの体制である。

・ 学生団体なので技術者をそろえることが難しかった。また、サイトを立ち

上げる際のサーバーは学校のものを用いた。金銭的な見通しがつかなかっ

たため、サイトの改良を積極的に行えなかった。

・ HTML/CSSテンプレートとCakePHPの設定をそれぞれ分担してあたった。

得られたサポート ・ 新たに実装するなどの専門的な技術支援は、Googleの方が対応してくださ

った。そのほか、初心者の方でもすぐに参加できるよう、マニュアル作成

などおこなった。

・ 大手SI会社から、災害支援特別チームと現地子会社より技術者２名が１週

間張り付きでサポート頂いた。開発支援以外にもカスタマイズや情報分析

に関するリソース紹介を受けた。

・ 免責事項の文面は、法務関連部署から協力を得た。弊社サイトのページ追

加は広報部署から協力を得た。

・ ボランティアでのつながり。Jimdo講座を行い、支援者も募集。シニア、

女性を含む緩い関係。現地被災地のかたは女性が多いので、女性支援も重

要と考え、複数チームで支援の輪。ボランティアネットワーク組織として

のチームとした。（安心していただくため）

・ 臨時職員としてIT技術に詳しい方に来ていただきました。要望に合わせて

サイトの構築をしていただきました。

単独・少人数 ・ 開発は一人で行い、技術提供を友人にお願いし、携帯でのテスト（DoCoMo

58

トピック 内容

/Softbank） を友人二人にお願いしました。

・ グラフィックデザインは他メンバーが担当していましたが、そのメンバー

より受け取ったグラフィックデータ（PSD形式/AI形式）を分解／処理／

HTMLコーディング／WordPressテンプレート作成などをしてWebサイトと

して公開できるまでを一人で行なっていました。

・ 基本一人で全部作って、デザイン周りだけ知り合いにお願いしました。

・ サービスの設計を2人で行い、その後の開発・運用は基本的に1人で行っ

た。

・ 3人中の2人がデザイン制作、1人がシステム構築とコーディングを行い、

公開後は2人で管理を行っている。

・ 単独で開発を行った為、早期に実装出来た。

59

2.5.2. 不足しがちだったリソース

図 2-46 技術者向け Q13 不足しがちだったリソース（当てはまるもの全て選択）（ｎ＝７２）

表 2-17不足しがちだったリソース（自由記述）（抜粋）

トピック 内容

人に関する事柄 ・ スタッフによって技術力の差がありすぎるため、特定スタッフに依存しがちとなる。

・ 災害支援はリリースまでの時間的要件が非常にタイトなため、一定レベルのエンジニ

アリソースの確保が困難であった。

・ 優秀な人はいくらいても足りないと思う。開発者不足。

・ なかなか特定キャリアのガラケーを持っている友人がいなかったので、探すのに苦労

しました。

・ UI設計者・ディレクター。

・ 1人でおこなっていたので一日での情報発信量の限界もありました。

・ 他に業務があり多忙な人ばかりがメンバーだったので、必要な時にすぐ動ける、車を

持っていてフットワークが軽い人。

・ コンテンツ更新のための日々の作業者。

・ 現地に行ける人。

・ 時間。

・ コンテンツ制作、翻訳。

・ 他のサイト管理者。本業が忙しいときに代替できない。

・ デザイナー（デザインセンスのある人）、ユーザビリティについての造詣が深い人。

ノウハウ関する事柄 ・ Google Sitesは自由度が低く回避策がわからないところがあった。

・ WordPressの内部仕様について、調査する時間が無かった。

・ Jimdoというクラウドサービスを初めて知ってからのサポートのため、仲間と協力しての

スキルアップ。

・ 情報ソースの形式、数字の意味、流通形式。

・ コンテンツを収集する手段と発信形式。

・ 何が必要とされているかの把握が最も大変でした。

・ 現地では存在するはずのニーズ情報。

・ 情報が分散していたので、それを統合し他とどう連携すればいいのか？という点でうまく

いかなかった。

技術者向け Q13 不足しがちだったリソース

38.9%

34.7%

23.6%

13.9%

30.6%

特定分野のエンジニア（ヒト）

情報（ノウハウなど）

資金（カネ）

特定分野の技術部品等（ハード・ソフト）（モノ）

不足したリソースは特になかった

60

トピック 内容

・ もっといろいろな情報を統合したかったが、処理可能な情報が少なかった。

・ 復旧依頼が非常に多かったので、そのサイトを復旧すべきかどうかという事を判断するの

が難しかったです。

金銭的な事柄 ・ 現在まですべて私のポケットマネーです。集まりの場所、飲食の用意など。

・ 電話代電気代は被災地への義援金だ、と思って各地方自治体に電話をかけていました。

・ どうしても実際に現地で打ち合わせの機会が必要。そのための移動資金は個人負担なの

で、資金と時間で制約がある。

・ 企業として運営継続ではいくらかの営利を求める必要性があった。

設備・物品 ・ サーバー。パソコン。

・ ネットワークの接続環境。

・ 現地の支援対象のかた(団体）は、PCやネット接続環境がない等、弱体であった。電

話でのやりとりなど通信費負担も増えた。

2.5.3. プロジェクトマネジメント上の制約や課題

図 2-47 技術者向け Q14 プロジェクトマネジメント上の制約や課題（当てはまるもの全て選択）（ｎ＝７２）

プロジェクトマネジメント上の制約や課題については、自由記述による以下の回答があった。

表 2-18 技術者向け Q14 プロジェクトマネジメント上の制約や課題の内容を具体的に示した自由記述（抜粋）

設問の選択肢 主な自由記述回答

技術者向け Q14 プロジェクトマネジメント上の制約や課題

43.1%

43.1%

12.5%

5.6%

5.6%

27.8%

15.3%

一刻も早く公開しなければというタイムプレッシャー

一刻も早く公開するための品質面での見切り発車や割り切

り

混成技術者メンバーでの指揮系統の調整

混成技術者メンバー間での設計開発手法の相違

混成技術者メンバー間でのアカウント管理やプラットフォー

ム共有などチームでの開発環境共有

運用開始後の環境や情報源の変化に伴う仕様の変更

その他

61

設問の選択肢 主な自由記述回答

タイムプレッシャー ・ 拙速でも、まずカタチにすることを優先。待つ身になって考える。質よりスピード感。先方との相互信頼

への気遣い。

・ 皆が積極的にできることをし、不思議なくらい問題がなかったです。強いてあげるとすれば、仕事が終

わった後からこの開発が始まるので夜中作業にならざるをえませんでした。

見切り発車や割り切り ・ 炊き出しは震災初期の支援なので、なるべく早くリリースした方がいいという考えの下で開発したの

で、デザインや送信フォームなどの工期を省きました。

・ リソース不足や制約等無かったというのは、実は逆で、むしろできる事をできる範囲で行う。という市民

ボランティアである為、「こうあるべき」の様なものを設定しなかったから。

・ とにかく早く公開するためにサイトはマッチしていない箇所があっても既存のものを利用した。また、ネ

ットを経由しない電話・Faxによる対応も行った。

仕様の変更 ・ サービス公開までの早さを最重要視して開発を行った。東京電力が公開する計画停電情報(Excelファ

イル)のフォーマット変更への対応に苦労した。

混成技術者メンバーで

の指揮系統の調整

・ 本当に役に立っているのかという無力感、自分の生活に対する不安、目の前の仕事に没頭できる（あ

る種の）充実感のなかで、チームメンバーが体調を崩したり生活のリズムを崩したりしないように気をつ

けるのが大変でした。

・ 納期の短さ。PJ としての仕様意志決定の難しさ。開発者自身が運営主体とイコールの状態以外では、

時間とリソースの制約上、かなり難しいと感じた。

混成技術者メンバーで

の設計・開発手法の相違

・ メンバーによっての価値観や優先順位の付け方の相違。

・ 混成チームでの仕様確定プロセスの欠落。

・ 企業コーダーの人たちはその会社のスタイルがあるので、その交通整理をしとかないと大変です。

その他 ・ 技術力の低いスタッフは、引き上げることを前提にマネジメントを組むので非常に労力を使う。また、参

加意思を表明してくれても、継続して行えるかどうかは、練習期間をおいて判断するため、時間がかか

る。技術力と所有時間の要望に応えられるスタッフは少ない。

・ コンテンツの更新に関わるコアメンバーを集めることが大変でした。

・ 様々な情報の中から信憑性の高い情報のみを取得すること。対外的に見ても、自分に金銭的物質的な

利益が発生しないようにすること。

62

2.6. 実体験を通じた今後の教訓

ここでは、支援サイト等の運営者及びそれを支援した技術者双方が、サイトの立ち上げや運営の実体

験を通じて得た今後の教訓に関するアンケート結果を整理する。

2.6.1. 支援サイト等の立ち上げや運営に寄与した事柄

ここでは、課題ではなく成功要因を運営者に尋ねた。支援サイト等の立ち上げや運営に寄与した事項と

しては、ソーシャルメディアの活用が挙げられた。続いて、既存の人間関係性が挙げられている。

図 2-48 運営者向けQ14 支援サイトの立ち上げや運営に寄与した事柄（５つまで選択）（ｎ＝運営者 １１３）

2.6.2. 法令や情報セキュリティ、プライバシー保護等の課題

法令や情報セキュリティ、プライバシー保護等の課題に直面したと、運営者全体の4分の1が指摘して

いる。自由記述からは、法令（支援活動）、寄付金の取り扱い、個人情報保護、データの2次利用の著作権

についての課題が認識されたことがわかる。

65.5%

39.8%

35.4%

27.4%

27.4%

24.8%

19.5%

18.6%

18.6%

17.7%

16.8%

15.0%

14.2%

9.7%

6.2%

2.7%

ソーシャルメディア（Facebook、mixi、Twitter、ブログなど）

会社や組織を越えたネット上のコミュニティ

会社や組織を含むリアルなコミュニティ

パソコンやITシステムの広汎な利用

NPO・ボランティア活動

位置情報や地図情報技術（Web GISなど）

スマートフォンやタブレット端末等の普及

ブロードバンドの普及（光回線、Wi-Fi、3Gパケット回線など）

アプリケーションの容易な実現（Google Apps、iPhone、Androidなど）

インターネットサーバーの容易な実現（VPSやクラウドサービスなど）

地域に根ざしたコミュニティ

他のサイトや情報源との連携（マッシュアップ、Web APIなど）

過去の災害の経験やその教訓

企業のCSR活動

音声・動画サービス（Skype、YouTube、Ustream、ニコニコ動画など）

その他

運営者向け Q14 支援サイトの立ち上げや運営に寄与した事柄

63

図 2-49 運営者向け Q15法令等による制約、情報セキュリティ対策やプライバシー保護等の課題（ｎ＝１１１）

運営者向け Q15 制約、課題、教訓

あり, 26.1%特になし,

73.9%

64

表 2-19 運営者向け Q15 「制約、課題、教訓」 自由記述による回答

主な自由記述回答 キーワード

・ 緊急時は緩和できる法律を決めておいてもいいかもしれない。薬事法とか。

・ 支援してはいけない商品（薬など）があったが、無料で送ることに対しては規制がきつい。

・ 借地借家法等、平時の法律の複雑性が妨げになっていること。弱者保護の法律がかえって良識ある弱者

にとってマイナスになること。

法令

（支援活動）

・ 法令による制約によりサービスが充実していないため、社団法人はWebを通じて個人から寄付を集めら

れない。

・ 義援金の収集が資金移動業者に該当するかどうかの法的判断が難しいです。

・ ファンド的要因が多く、金融商品等の法令の確認が必要。

法令（寄付金）

・ 緊急時にアップした個人情報（その時点では有効）は適正な段階で削除する、などの必要がある。

・ 有事の際の個人情報公開の水準や基準を設定しておくと、より円滑な情報共有が可能かと思われる。

・ 個人からの支援とはいえ、直接特定情報は載せない。

個人情報保護

・ 著作権、肖像処理の問題をどのようにクリアしていくか。

・ 自治体のホームページなどで公開された情報（避難所情報など）は著作権に守られ、情報の2次利用な

どについての考慮がされていなかった。他への転載や再利用を前提として情報を公開するようにしてほし

い。

・ 行政がお持ちの避難所データ（Webサイトに公開されている情報）が著作権の保護の対象として、2次利

用できないこと。

データの2次利用の

著作権やルールの取

り決め

・ デジタルデータとしてインフラ企業や自治体官公庁がデータを出す場合、データ化しやすい形で提供し

てほしい。

・ 情報公開のありかた。画像は最悪。PDFもあまりよくない。HTMLもいまいち。機械による読解が可能な

CSVやAPIによる公開がベスト。

オープンデータ

2.6.3. 実体験を踏まえたメッセージやアドバイス

実体験を踏まえたメッセージやアドバイスに関しては、半数以上（55.0％）が“あり”と回答し、多くの自

由記述が寄せられた。その中では、スピード、リソース、普段からの備え、情報の信頼度や可用性を保つ仕

組み（データ形式など）など、実体験に基づく多様な回答が寄せられた。

図 2-50 運営者向けQ16 実体験を踏まえたメッセージやアドバイス（ｎ＝１１２）

運営者向け Q16 アドバイス等

あり, 55.0%特になし,

45.0%

65

66

表 2-20 運営者向けQ16 「実体験を踏まえたメッセージやアドバイス」自由記述による設問回答の整理

分類 主な自由記述回答 キーワード

意思決定 ・ 決意とネットワーク。

・ まずは作る。

・ あげたもん勝ち。

・ とにかく始めること。正しい情報をできるだけ多くの人に伝えよう。その気持ち

さえあればよい。スピード。完璧を求めないこと。許可を求めることを考え過ぎ

ず、正しいと思ったことを、とにかく行動に移すこと。

・ 災害発生時、すこしでもできる・やるべきだと考えたなら、速やかに実行すべ

き。細かなことはあとで考えればよい。とにかく意思決定のスピード。そしてイ

ンターネットを通じてなるべく多くの意見をもらい、反映させる。

スピード

実行

運営マネジメント ・ 初期スコープを可能な限り小さくして、初期Iterationを迅速に完了させること

/リソースをできるだけ広く確保して個人の負担を減らすこと/運用やメンテナ

ンス計画を最初に立てておくこと。

・ 更新頻度を維持する体制があるのは重要。

・ 共同作業者とのやり取りは極力オープンにしたほうが、他の人も現状の問題

点や課題を知っていただき更なるアドバイスをいただく機会がもてる。

・ コーディング以外にも効果を生み出す方法はある。例えば難しいことをプレゼ

ン化してすぐに公開すること。

・ まずは、信頼できる IT技術者を見つける事、それにつきます。

・ いかに運営者自身に負担がかからず（金、人的コストいずれも）、それでいて

継続性のある企画にするかが重要。

継続

人的リソースの確保

オープンな情報公

開・共有

コミュニティとの

連携

・ サイトを立ち上げるだけではなく、リアルな協働関係を作り、現地で活動する

被災地支援とリンクすることが大切。地図情報はマッシュアップ可能なAPI等

(WMS, KMLなど)で公開することが大切。

・ ソーシャルメディアをもちいて、エンジニア有志たちによる開発コミュニティを

素早く形成することが肝要かと思います。

・ あらかじめ、「なにか起こったら一緒にサービスつくろうな！」といいあえるコミ

ュニティをあらかじめ作っておく。

支援団体とのリアル

な協働関係

日頃からの技術者コ

ミュニティの形成

平時からの準備 ・ 平常時のしくみ、取り組みを生かすことが重要。

・ 災害がおきた時等の支援活動には、HPやソーシャルメディア等が必須となる

ため平時から支援サイト等を運営できるメンバーを登録等によってDB化して

おくこと。

平時からの備えやつ

ながり

67

分類 主な自由記述回答 キーワード

提供する情報 ・ いかに独自の情報を盛り込むかが多くの読者に読んでもらうためのポイント

だと思います。できるだけ読者が客観的に判断できるように情報ソースを明示

することが重要です。

・ 支援サイトでよく聞く物資や人的リソースの適正なマッチングシステムなど

は、正直完璧なものは作りきれないという印象があります。罹災直後は情報を

出す側も受ける側も正確な情報を発信する余裕はありませんので、マッチン

グ精度にこだわりすぎると、結果、提供されるリソースが需要に対して不足す

るという問題が生じます。かといって情報の氾濫は混乱をよびますので、支援

サイトはむやみに乱立させずに自主的に集約をしていった方がいいと思いま

す。

・ サイトが提供する情報の信憑性が別組織によって認証され、サイト自体の社

会的責任がまっとうできること。

情報の信憑性を担保

する仕組み

プラットフォーム ・ 事前にスケーラブルな仕組みにしておくべき。

・ サイトを立ち上げるためにプラットフォームみたいなものが予めあるといいで

すね。ブログとフォームとDBを合わせたようなもの。

提供サービスの規模

に応じたプラットフォ

ームの事前提供

義援金・寄付金 ・ 支援サイトだけではないですが、使えるインフラとスキームをある程度認識し

ていることは重要だと思います。また、各種支援団体への送金がスキームに入

っている場合は、税務処理や資金移動に関する法令の把握、他団体の活動状

況把握→支援者への報告といった継続的情報収集と公開に対する意識は必

要かと思います。

・ 100%全て寄付するのではなく、少しは運営サイドにお金を残しておかないと

続きません。10%程度は手数料をもらっていた方が継続できたり、参加した

方々へのケアもできたりしたのではないかと反省をしています。

継続的な運営資金の

確保の仕組みづくり

ユーザビリティ ・ スマホ対応、Wi-Fi対応、情報更新と投稿者のフォロー。

・ 類似サービスはできるだけ集約し、利用者が「ここさえ見れば何とかなる」と

いう状況を目指すこと。

・ 既に似たサービスがないか調べて、同じ物があればそこに協力する。実績の

あるオープンソースソフトウェアを使う。可能な限り現地組織やNPOと連携す

る。

情報のワンストップ

化、多様なアクセス手

段への対応

68

2.6.4. 実体験を踏まえ、技術者がその後に取り組んだ事柄

技術者アンケートでは、「技術支援の実体験を踏まえた取り組み」についての設問を設け、支援経験に

基づく技術者としての活動状況を聞いた。各４割以上の高率で公開・共有を進められ、エンジニア間での

経験や知見の共有活動が多方面で行われたことを示した。

図 2-51 技術者向けQ15 実体験を踏まえ、取り組んだもの（当てはまるもの全て選択）

（ｎ＝７２）

技術者向け Q15 実体験を踏まえ、取り組んだもの

45.8%

43.1%

43.1%

12.5%

8.3%

22.2%

Webサイト、ブログなどへの経験の公開

経験を記録／プロジェクト化して共有

コミュニティへの経験の投稿・共有

新たな標準化やツールの開発、あるいはその提案

支援サイトにかかわったメンバー等による新しい技術者コ

ミュニティや団体への参画

その他

69

2.6.5. 支援サイト運営経験からの教訓、提言、関係方面に望むこと

教訓、提言に関しては、運営者と技術者双方のアンケートを同一の設問構成とし、それぞれの実体験に

基づく教訓や提言について聞いた。

技術者の回答では、今後の教訓に関して、運営者同様に「オープンデータ」が群を抜いて多く、回答者

の約半数（48.6%）が望むこととして挙げた。また技術者の回答ならではの特色として「標準的な ITインフ

ラやサービスの長期無償提供」も 4割以上（40.3%）と高率で挙げられた。

自由記述を見ると、オープンデータ関連では、政府／自治体／各省庁に対するXMLなど標準的な形

式でのデータ提供、WebAPI（オープンガバメント）、PCで利用しやすいデータ形式（PDF、Excelなど）と、

具体的内容が示されている。

70

図 2-52 教訓、提言、その他関係方面に望むこと（運営者 ｎ＝１１２／技術者 ｎ＝７２）

全回答 教訓、提言、その他関係方面に望むこと

5.6%

15.3%

19.4%

20.8%

29.2%

30.6%

40.3%

31.9%

23.2%

27.7%

30.4%

39.3%

47.3%

13.9%

15.3%

9.7%

20.8%

20.8%

19.4%

23.6%

48.6%

4.5%

8.9%

11.6%

14.3%

16.1%

17.9%

23.2%

24.1%

26.8%

27.7%

30.4%

その他

情報連携技術の普及推進

技術部品のオープン化・オープン標準化

各種法制度や許認可の存在をわかりやすくする整備

異なるソーシャルメディア間の横断的な検索連携

Web API、Web GIS、マッシュアップ技術

セキュリティ対策、個人情報／プライバシー保護に関する整備

協力を得られる、技術者などの人材にアクセスできる仕組みの整備

告知協力やリンクなどの広報面での支援

一般利用者側の災害に備えるITリテラシーの向上

標準的なITインフラやサービスの長期無償提供

マスコミ、ポータルサイト、ソーシャルメディア事業者間における整備

資金面の援助

支援団体間における整備

情報を効率的に収集・共有できるシステム・ノウハウの充実

政府／自治体による活用しやすい形式の情報公開（オープンデータ）

運営者

技術者

71

運営者からの、支援サイト等の立ち上げや運営に関する教訓、提言、その他関係方面に望むことについ

て、自由記述を整理したものが以下の表である。この表に続き、技術者からの意見も同様に掲載する。

表 2-21 運営者向け Q１６「アドバイス」、Q17 「教訓、提言、望むこと」自由記述による設問回答の整理

Q17の選択肢 運営者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

各種法制度や許認可の

存在をわかりやすくす

る整備

・ 支援サイトだけではないですが、使えるインフラとスキームをある程度

認識していることは重要だと思います。また、各種支援団体への送金が

スキームに入っている場合は、税務処理や資金移動に関する法令の把

握、他団体の活動状況把握→支援者への報告といった継続的情報収集と

公開に対する意識は必要かと思います。

・ 非常時に、超法規的な対応を可能とする社会制度が必要（例：個人情報

保護法の運用等）。

・ 政府や自治体は、シンプルなルールの整備やわかりやすい基本の支援に

しぼり、多様性への対応は民間ベースが効率的と考える。

非常時のルールや法

令の整備・事前の取

り決め

支援団体間における整

備

協力を得られる技術者

などの人材にアクセス

できる仕組みの整備

・ ソーシャルメディアをもちいて、エンジニア有志たちによる開発コミュ

ニティを素早く形成することが肝要かと思います。

・ 自分に足りない部分を補ってくれるような友人との関係性を築くこと。

・ あらかじめ、「なにか起こったら一緒にサービスつくろうな！」といい

あえるコミュニティをあらかじめ作っておく。

・ 共同作業者とのやり取りは極力オープンにしたほうが、他の人も現状の

問題点や課題を知っていただき更なるアドバイスをいただく機会がも

てる。

・ コーディング以外にも効果を生み出す方法はある。例えば難しいことを

プレゼン化してすぐに公開すること。

・ 定期的なオフラインのミーティングができたらよかったと思いました。

住んでいる地域が遠いと実際に会うことができなかったので、その機会

を作れたら良かったと思いました。

・ 公開までの早さと情報の信頼度が重要であると感じた。サービスの告知

にSNSサイトが非常に役立った。

・ IT系の人材と常に交流しておくこと。

日頃からの活動者と

支援技術者、技術者

同士のコミュニティ

の形成

72

Q17の選択肢 運営者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

政府/自治体による活用

しやすい形式での情報

公開（オープンデータ）

WebAPI、WebGIS、マッシ

ュアップ技術

・ 細々でも災害がおこる前から準備が必要。とくに放射線量は事故前のデ

ータがあれば全く違うサイトができたと思う。

・ 第一次の情報を発信する国や行政機関の情報を二次利用しなければう

まく伝播できないという点は、今後の迅速な支援を遅らせるものと考え

る。行政機関が発信した情報は、直ちにその場で検索でき、その場でた

どり着きやすい形になるべきである。

・ 東京電力がAPIを公開していますが、このような、開発者がアクセスで

きる仕組みをいろいろな業界が提供してくれたらさらに役立つサイト

や面白いサイトができるのではないかと思います。

・ 震災前に全国のハザードマップアプリ作成を検討していたが、各市町村

で公開されているデータ形式が全く異なるため断念した。共通のデータ

ベース化して欲しい。

・ WebAPIの充実、とくに行政情報の公開・オープンガバメントが必要だ

と考えます。

・ 標準フォーマットで、情報をわかり易く、正しいライセンス公開するこ

とを望みます。行き過ぎた個人情報保護により本来の目的を見失ってい

るケースも見られました。

・ 文科省にはモニタリング情報をPDF形式にするのではなく、アクセシビ

リティのたかいCSVデータなどで発表していただきたい。

・ 情報公開をする際は、PCで利用しやすいデータ形式(PDF・Excelなど)

とWebアプリケーションで利用しやすいデータ形式(XMLなど)で公開を

してほしい。

オープンデータ

データの2次利用の

著作権やルールの取

り決め

標準的なITインフラや

サービスの長期無償提

供

・ 初期スコープを可能な限り小さくして、初期Iterationを迅速に完了さ

せること/リソースをできるだけ広く確保して個人の負担を減らすこと

/運用やメンテナンス計画を最初に立てておくこと。

・ 有事における有料サービスの無償提供や、アクセス制限などの緩和をし

てほしい。

標準的なITインフラ

やサービスの長期無

償提供

73

Q17の選択肢 運営者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

情報を効率的に収集・共

有できるシステム・ノウ

ハウの充実

・ 参加ボランティアのメーリングリストを初期に開設したが、サイトに反

映するのに時間がかかった。緊急時にはTwitterがサイトへの反映がす

ばやく、有効だったようだ。

・ 実践したことだが、1．簡易なデータ構造で始めること、2．人的手段で

のデータ入力を厭わないこと。

・ 情報が正確なものかの判断基準が難しいです。

・ 情報の鮮度を高めるには、スピード感を持って一気にまとめ上げて形に

する必要があります。そのためには人的リソースをいかに集められるか

が重要な要素となるかと思います。そういうサイトを立ち上げるために

プラットフォームみたいなものが予めあるといいですね。ブログとフォ

ームとDBを合わせたようなもの。

・ アナログな情報収集及び情報の信頼性をどう担保していくかが重要だ

と思います。またクラウドプラットフォームの利用は必須条件だと思い

ます。

・ ネットは便利であるが、情報の伝達や共有において諸刃の剣であること

は今回の震災後のTwitterなどでの情報の混乱などを見ても明らか。正

しい情報を伝えること、それをきちんと理解して伝播するリテラシーが

メディア、企業、団体、個々人に求められる。

情報の鮮度や信憑性

を担保する仕組みづ

くり

資金面の援助

各種法制度や許認可の

存在をわかりやすくす

る整備

・ 100%全て寄付するのではなく、少しは運営サイドにお金を残しておかな

いと続きません。10%程度は手数料をもらっていた方が継続できたり、

参加した方々へのケアもできたりしたのではないかと反省をしていま

す。

・ 継続がもっとも難しい。理想を現実へコミットすることの勇気。

・ いかに運営者自身に負担がかからず（金、人的コストいずれも）、それ

でいて継続性のある企画にするかが重要。

・ 支援金の収集のシステムの構築。

活動資金の確保の仕

組みづくり

ファンドレイジング

の活用

マスコミ、ポータルサイ

ト、ソーシャルメディア

事業者間における整備

情報を効率的に収集・共

有できるシステム・ノウ

ハウの充実

・ 類似サービスはできるだけ集約し、利用者が「ここさえ見れば何とかな

る」という状況を目指すこと。

・ 既に似たサービスがないか調べて、同じ物があればそこに協力する。実

績のあるオープンソースソフトウェアを使う。可能な限り現地組織や

NPOと連携する。

・ 災害時は、支援サイトが無数に立ち上がるとともに利用側も複数の支援

サイトへ情報発信を行うため、実際の支援が交錯する場面が多く見受け

られました。利用側の発信コーディネート機能を支援する仕組みができ

ていくことを希望します。

・ 震災当時は、自治体、企業、マスコミ、個人、の情報発信がバラバラだ

という印象でした。それの中から必要な情報を探し出して選んで使う、

という行動が被災している方のあいだで冷静にゆっくりとできるとは

思いません。わかりやすく簡単な方法でしかし正確に、情報がきちんと

伝わるように整備できればいいと思います。

情報のワンストップ

化、情報受発信の整

理機能

74

Q17の選択肢 運営者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

その他 ・ 集団や企業などによる支援サイトや情報発信はどうしても瞬発力が劣

ると思っていたので、個人にできる一番の長所は情報の早い発信だと思

っていました。いい加減な情報では意味はありませんが、早いと言う事

も支援にはとても重要で、その時々にそれぞれができる動きをできる範

囲で行えたら良いと思いました。

・ 感謝の気持ちを忘れず「最終決定は自分でする」と捗ると思います。

・ とにかく早く立ち上げる。細かいことはあとから考える。

・ 震災発生後の開設だったため、とにかくスピードが重要でした。被災地

の人がインターネットにアクセスできる段階になった時に、利用するこ

とができる役に立つ情報がストックされている状態をいち早くつくる

ことを考えました。

スピードと実行

75

次に技術者からの支援サイト等の立ち上げや運営に関する教訓、提言、その他関係方面に望むことに

ついて、自由記述を整理したものが以下の表である。

表 2-22 技術者向け Q16 「教訓、提言、望むこと」自由記述による設問回答の整理

Q16の選択肢 技術者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

支援団体間における整備 ・ 災害後に動くのではなく、平時から基盤作りが必須ではないか。

・ 自治体の動きがまったくバラバラで情報の種類もまちまちで、各地それぞれ違

うから仕方ないとは言え、それでも、もう少しどうにかならないのかと思って情報

を集めていました。良し悪しは別として、長の年齢が若い自治体の方が、動きが

速い印象でした。

・ 情報を発信する人達が、それぞれ色々な形式であるので、結局人手をかけて拾

っていくのが一番かも知れません。情報発信手段の無い様な人から情報を取っ

てきて、ネットに上げるというのも重要ですし。

サイト上だけでな

く、人手での情報

収受を想定した

体制の準備

支援団体間における整備

協力を得られる技術者な

どの人材にアクセスでき

る仕組みの整備

・ 個々の支援活動が活かされるためにも、連携、ネットワークが必要。

・ 災害後は被災者支援という志で、多くの人々が組織横断的に同じ目標に向けて

投入ができるリソースが一時的に生まれる。しかし、意志決定や組織づくりなど

がボトルネックになる。

・ 技術力のあるエンジニア自身が全て個人の独断で走るケースや、企業が明示

的にリソース投入を決定するケースの方がスピード面で分があったのが印象的

であった。災害後に生まれるリソースを使いこなすための枠組みが事前に必要。

日頃からの技術

者同士のコミュ

ニティの形成

政府/自治体による活用

しやすい形式での情報公

開（オープンデータ）

WebAPI、WebGIS、マッ

シュアップ技術

・ 政府／自治体／各省庁に対して、XMLなど標準的な形式で様々なデータの提

供をお願いしたく思います。（単純なファイルでの公開でもWeb APIでの公開

でも）扱いやすいデータが広く公開されることで、社会にとって有益なシステム

／サービスの開発が促進されるのではないかと考えております。

・ 行政データを恒常的にオープン化・情報開示するWebAPIが必要（オープンガ

バメント）。

・ 情報公開をする際は、PCで利用しやすいデータ形式(PDF・Excelなど)とWeb

アプリケーションで利用しやすいデータ形式(XMLなど)で公開をしてほしい。

・ とくに国のサイトは猛反省すべき。公開していないのは論外だが、公開していて

も如何に使えないデータが多かったか。企業の災害システムとか軒並み何の役

にも立っていなかった。被災当日のケータイも通じない状況の中、一番役に立っ

たのは、災害用途では全くないTwitterだった。

オープンデータ

オープンガバメ

ント

標準的な ITインフラやサ

ービスの長期無償提供

・ 「サービスを公開してはいけない」というレンタルサーバーで公開していたの

で、「うちのサーバーを使っていいですよ」というような企業があってもよかった

のかなと思います。他のサービスでも「アクセス過多で落ちた」という話も聞き

ました。

・ みんなのビジネスオンラインがもっと早く利用できるようになっていればこちら

を使用していた可能性が高い。

標準的な ITイン

フラやサービス

の長期無償提供

情報を効率的に収集・共

有できるシステム・ノウハ

ウの充実

・ 災害時は避難所の状況がめまぐるしく変化し、情報が錯綜しやすいので、情報

整理やデータ抽出の精度やスピードを上げる技術向上とともに発信側のリテラ

シー向上にも取り組む必要がある。

情報の鮮度や信

憑性を担保する

仕組みづくり

76

Q16の選択肢 技術者からのアドバイス・メッセージ・教訓・提言

主な自由記述回答

キーワード

資金面の援助

各種法制度や許認可の

存在をわかりやすくする

整備

・ ボランティアだからすべてこちらで用意して要求に応じるのは大変困難です。

支援の体制がないと難しいでしょう。年度をまたいだ時に予算がどうのこうのと

なってしまって、結局は対応が市ではできなくなってこちらが対応しなければな

らないことなど。民間とは違った部分で難しかったです。

・ 資金面の援助があれば、いまだに継続しているはず。

・ 資金は持ち出しが多くなるため、中長期で支援するために必要。

活動資金の確保

の仕組みづくり

（ファンドレイジン

グ）

マスコミ、ポータルサイト、

ソーシャルメディア事業

者間における整備

・ 情報サイトが乱立、とまではなりませんでしたが、ここにくればその先につなが

っているというポータルが欲しかったです。

情報のワンストッ

プ化、情報受発

信の整理機能

その他 ・ ネトボラ宮城のスタートは、避難所等で情報を受け取れない被災者、情報発信

をできない被災者の所に、PCと回線を持って行って据え付けるという事と、支援

サイトと、二本立てでした。例えば、Amazonで避難所の人達が欲しいものリス

トを作って、誰かが買って送付。と言うのが初期に立ち上がりましたが、一番被害

の大きい地域では、その為のネット環境自体が無いわけです。そういった、被災

者が情報を受信、発信する事のできるインフラあっての支援サイトというのが、

一番の思いです。

回線インフラが

失われた時の情

報受発信の仕組

み

77

3. 課題の具体的な状況に関する背景調査 − インタビューの記録

アンケートの調査結果を基に、サイトが直面した課題についてより深く背景理由や状況を確認し、特徴

的事象についての想定を検証する材料を得ることを目的として、インタビュー調査を実施した。

3.1. アンケート結果から引き出された、検証すべき仮説

アンケートの結果からは、支援サイト等の実態、直面した課題と IT技術要素について、全体としておお

むね以下の実態があったことが確認できた。

・ 迅速な立ち上げが実現できたところが多かったこと

・ 構築・運用にあたった母体の種別・規模は、個人、コミュニティ、企業・団体と様々であったこと

・ 一般向けから専門用途に特化したものまで、サイトのバリエーションが多様であったこと

・ 状況の変化が大きく、運用面、技術面で様々な対応が迫られたこと

・ 品質面、セキュリティやプライバシーなどの社会的課題への考慮も必要であったが、緊急対応と実

行体制の実情を優先したことによる矛盾が存在したこと

これらの実態について、その要因などを中心に検討・整理した結果、支援サイト等には、大きく以下のよ

うな課題と、それらを反映する特徴的な事象が存在していたとの仮説を立てることができた。

仮説 １) 立ち上げ期には、可及的速かに、かつ限られたリソース（人的・経済的）の中で、最善を尽くさ

なければならない状況が強く存在し、その結果、サイトの目的・種別・運用主体、サイトの構築・

運用方法、関与するメンバー同士のコミュニケーションのあり方、スキルの違いなどにより、特

徴的な事象が生じていた。

仮説 2) サイトのリリース時期、活動フェーズなどのライフサイクルおよび外的条件の変化が要因とな

78

って、運用者の直面する課題が変化し、それを受けた形で特徴的な事象が生じていた。すなわ

ち、発災後の経過時間、復旧活動の進捗状況、支援を受ける被災者側の状況変化、支援者側

の体制や対応方法、社会環境などが変化していったことにより、サイトの運用面および技術面

での課題が変化し、それに伴う解決・対応が求められた。

仮説 3) サイトの目的・特性に従って、扱った情報の特性（内容、規模、最新性、信憑性、継続性など）は

異なり、立ち上げ時にも運営時にも、運用面、技術面での対応すべきリスクや直面した課題、対

応方法に特徴的な事象がみられた。

仮説 4) サイトが直面した品質、セキュリティ、プライバシーなど、法令・制度にかかわる社会的課題へ

の対応方法と、選定した IT技術要素とその組み合わせとの間には、通常と異なる関係性を示

す事象が発生していた。

上記の点について、アンケートへの回答結果をもとに、具体的な検証材料となる特徴的な事象を得られ

るとみられるサイトを選定し、インタビューの依頼をした結果、合計18サイトのインタビューを実施するこ

とができた。

79

3.2. インタビュー記録

インタビューした団体・個人は計18あったが、主な特徴をもとに、大きく以下の4グループに分類した。

1. 震災前から活動していた団体によるサイト

2. 被災地に拠点をもつ団体によるサイト

3. 個人が中心になって運用したサイト

4. 法的・制度的な課題をとくに意識して対応したサイト

ただし、この分類は、サイトが直面した主な課題とその対応についての全体的な理解を助けることを目

的としている。言うまでもなく、個々のサイトはこれらの要素を複合的にもっており、そのなかからあえて特

徴的な要素を選んで分類したものである。

3.2.1. インタビュー記録：震災前から活動していた団体によるサイト

アンケートの回答には、東日本大震災発生以前から大規模災害に備えた防災・減災のため活動を展開

し、とくに ITを活用した情報支援を手掛けていた団体・個人が立ち上げたサイトがあった。彼らのこれまで

の活動経験とそれによる知見は、今回のサイトの立ち上げ、運用にも大きく寄与したものとみられた。

以下、非営利団体の活動を支援する「寄付文化」の形成が重要と考え、ITを活用したファンドレイジング

のインフラを提供する一般社団法人ジャスト・ギビング・ジャパンと、これまでの災害情報支援活動の経験

を活かし、短期間に数百団体が参加する連携組織を立ち上げた東日本大震災支援全国ネットワーク

（JCN）の 2団体のインタビュー結果を紹介する。

なお、インタビューでは、これ以外のサイトでも、阪神・淡路大震災など、運営者がなんらかの形での過

去の被災体験をもち、それが今回の活動を開始する動機に結び付いた事例が見られた。

80

(1) ジャスト・ギビング・ジャパン（JustGiving Japan）

ご対応者：一般社団法人ジャスト・ギビング・ジャパン 代表理事 佐藤大吾氏

サイトの特徴：英国JustGivingの日本版。NPOなど非営利団体への支援を目的とするファンドレイジング

のプラットフォームを提供するWebサービス。

■立ち上げの経緯

震災以前から、日本のNPO活動を支えるためには『寄付文

化』の社会インフラが必要と考え、英国の JustGivingを基礎

としたサービスを立ち上げていた。災害支援NPOにかかわっ

てきた経験から、災害時の寄付集めの重要性も事前に意識し

ていた。

東日本大震災発災後、即日、「震災支援特別ページ」を立ち上げ、4月30日までは手数料なしで寄付を

呼びかけ、3月だけで 5億円の寄付を集める結果となった。ただし、寄付を直接集めるのではなく、寄付を

必要とする団体が利用できる寄付集めのためのツール・インフラを提供していることが特徴。ファンドレイ

ジングとは、自分が寄付して満足するのではなく、他者への寄付・資金提供を依頼することで、そこがポイ

ントである。

アクセスが当初の1万～2万件から一気に100万件まで急増し、サーバーがクラッシュしたが、

Amazon側からの支援申入れにより、AWSを利用して解決した。委託先の社員と事務局長の梶川氏とが

福岡へ行き、復旧に専念した。

5月以降は、寄付を受ける団体から 10％の手数料を徴収する制度で運用している。

■成功の要因

81

あまりに甚大な被害に、国民全体が何とかしなければという環境が醸成されたことと、それを受け止め

る仕組みを用意したこと、具体的な支援内容をリストアップし、依頼したい事柄を明確にできたことが成功

要因である。

■制度的課題と取り組み

クレジットカードは、決済・入金までに通常の仕組み通りだと2ヶ月かかる。しかし、支援金を被災地に現

金で早く届けたかったために、銀行に前例のない融資を要請し、なんとか実現した。携帯電話の料金徴収

を通した寄付金の収納代行をソフトバンク孫社長に要請したところ、即決実現された。

資金の透明性確保、ガバナンスに注力し、社会的信用を確保するため、大手監査法人の監査を受けた。

今回の経験を基に、NPOへの寄付インフラ確立に必要な諸制度拡充のための取り組みに注力してい

る。具体的には、NPO信用情報（内閣府）、決済手段の多様化（クレジットカード、携帯電話）、寄付税制整

備（2011年6月改正法可決）、ファンドレイジング手法の普及などである。

まとめ：ITを活用することで、ファンドレイジングのプラットフォームを迅速に実現

災害時に多くのボランティア団体などが直面するのが、資金面の課題である。ジャスト・ギビング・ジャ

パンでは、震災前から取り組んできた、インターネットを効果的に利用する寄付集めインフラを活用、発災

後いち早く呼びかけ、多くの支援団体への迅速・多額の資金確保に貢献した。これまで日本で定着してい

なかった、マイクロペイメントの仕組みによるNPOのファンドレイジングのプラットフォームを、ITを活用し

て迅速に実現した点は、注目に値する。

(2) 東日本大震災支援全国ネットワーク（JCN）

ご対応者： JCN事務局 岡坂健氏

サイトの特徴：支援者向け情報提供。参加団体760団体超。ボランティアバス（通称、ボラバス）情報、ガ

82

イドライン提供情報等、支援者が活用する情報を提供。

■立ち上げの経緯

3月14日、東日本大震災支援全国ネットワーク（JCN）設立

に向けた最初の集まりが開かれ、連絡がつく30団体に呼びか

け、賛同団体を募り、3月30日の設立総会には141団体が参

加した。

回答者は JCNの事務局を務め、総会当日には仙台から私

物のサーバーでサイトを立ち上げていた。当初、震災前から準

備していた訓練用ドメインとサーバーを使用、後に独自ドメイン／サーバーに移行した。

■背景

対応者は、2000年の有珠山噴火の際、ボランティアセンターのホームページとメーリングリストを運営

した経験をもち、災害支援における情報分野の専門職として、NPO愛知ネット（災害救援活動として情報

発信支援を実施）に勤務してきた。

2004年中越豪雨での経験から、内閣府防災ボランティア検討会メンバーになり、2010年にも、内閣

府・自治体による共同訓練にボランティア団体としての参加を依頼され、訓練用サイトを準備していた。

こうした災害情報支援活動の蓄積から、中心メンバーにとって、災害時のホームページの立ち上げは当

然のことだった。

■運用体制

各段階とも、ほぼ一人で作業。Webディレクション1.5人、データ更新、Webデザイン各1人。たまたま

集まったメンバーだが、体制化しやすかった。体制化できた要因としては、プロジェクト・マネージャーとし

83

ての役割を持つ人材がいたことにより、スムーズに統括をとることができた。また、ホームページの運用経

験のあるスタッフがいたので、必要な技術を持つ人との連携が取りやすかった点もある。情報チームは、

25人から最大で40人の体制となった。

発信すべきコンテンツに一人ひとりの思いがあった。すべてボランティアあるいはプロボノで参加。彼ら

のモチベーションをそがないために、トップダウンでの指示は行いにくかった。

集まったエンジニアは、CMSのアドオンが使える位の人が多く、DB、MLサーバー、MySQL等の下層

部分（サーバーレベルで SSH等コマンド操作を要するもの）の技術をもつ人材確保は困難だった。

■今後の教訓

類似内容を提供するサイト同士は、APIや特定プロトコルを用いて情報交換できればよかったが、お互

いに独自に仕組みを作りながら進め、相互交換ができず、無駄があった。今後、ボランティア情報について

課題があるとすれば、複数サイトで収集した情報をエクスチェンジする部分かと思う。

こうした経験を今後に生かすものにするためには、自分たちの今回の活動を、外部の第三者に評価して

もらう必要がある。

■災害と IT技術について

災害時の情報発信はこの15年ほど、ITが下支えしてきた。技術革新により新しいことができるように

はなったが、新しい技術を使いこなす人と実際に支援活動をしている人達が、まだまだ乖離している。リア

リティを持って活動している人達（実際の支援活動をする人）は技術よりも当然活動を優先する。一方エン

ジニアは技術を優先する。初期段階では紙とペンのような身近なアナログのものが役立つフェーズもある。

災害支援と技術側との折り合い、運営側のニーズに合っているかを考慮すべきである。

84

まとめ：過去の経験・蓄積を活かし、短期間で多数の団体の連携を実現、ネットで支援

JCNそのものは、震災後に設立された団体だが、コアメンバーは、対応者を含めて、災害支援活動に取

り組んできたNPO・個人が多く、災害時の情報発信の経験を豊富にもっていた。そうした蓄積が、短期間

で多くの支援団体を集めて、横の連携を可能にしたことは、日頃からの備え、経験の共有、教訓の警鐘の

重要性をあらためて裏付けるものといえる。また実際の連携活動には、ホームページをはじめ、ネットによ

る多様なツールの利用が必須だったということも示された。

3.2.2. インタビュー記録：被災地に拠点をもつ団体によるサイト

アンケート回答を活動拠点に着目して大別すると、被災地内、被災地外、両者をつないだ形のものと、三

通りあった。アンケートからは、それらの主たる活動拠点の違いが、立ち上げから運用・展開の過程、メンバ

ーの形成、情報収集方法、技術部品の選択などになんらかの影響をもたらしたのではないかと想定され

た。

インタビューでは、これらの点についての具体的な事実を確認するために、被災地内のサイト運営者に

取材した。以下は、東日本大震災の発生後、現地に活動拠点を立ち上げ、被災者のニーズを把握し、情報

支援活動を展開した4団体の事例から、それらの特徴的な事実、今後の教訓などについて整理したもの

である。

(3) 被災者をNPOとつないで支える合同プロジェクト（つなプロ）

ご対応者： つなプロマッチング班 星野美佳氏 河野良雄氏

サイトの特徴：宮城県内の避難所アセスメント巡回を実施、収集分析した情報を発信、ニーズ情報を連携

NPOと共有。大手ベンダーが技術支援。

85

■立ち上げの経緯

幹事団体6団体は日常的な連携があり、3月14日に集まり、

全国のNPO、とくに被災地のせんだいみやぎNPOセンターと

のネットワークがあることから、被災地の支援ニーズと、専門

NPO、マイノリティ支援NPOをつなぐ役割を担うことを決定し

た。

3月14日に活動開始を決定し、17日から宮城県に技術支援者河野氏を含む7名を先遣隊として派遣

した。避難所での支援ニーズのアセスメント要員として、一般ボランティア100名を、28日より投入するこ

とが予定され、彼らによるアセスメント作業を支える情報入力システムの構築に着手した。

最初は自力開発で作業を開始したが、2～3日後に、富士通より全面支援の申し出があり、共同開発と

なった。東京から技術者とマネージャーが参加し、4日間で構築。端末などハード面の支援を受けた。自作

の時間もなかったので、たいへん助かった。アセスメント項目はダイバーシティ研究所で素案を作成した。

■活動形態

スタッフ30人中、マッチング班は5人で他は被災地のロジスティクス、地元キーパーソンとの人脈形成

などを担当した。被災地メンバーが避難所に出向いてニーズ調査を行い、アセスメントシートに記入、その

内容を夜間に仙台で入力し、１週間毎に東京で集計・分析を実施する分業体制であった。

仙台ではニーズ情報に関してマッチング班を組織し、連携NPOとマッチング。NPOの活動実態・予定、

キャパシティを把握、マッチング班が電話をかけまくった。

■行政の目の届かない災害弱者に対するコミュニケーション

86

当初避難所で発見しようとしたマイノリティのニーズは、思ったほど多くはなかった。避難所に来られな

い在宅避難者や介護施設・障がい者支援施設等の福祉施設が、特別な配慮を必要とする人の臨時避難

所的な役割を担ったからでもあった。

災害弱者に関しては、支援者が避難所に行って、自分たちのところに連れてくることが多く、避難所に行

っても該当する人がいないことも多かった。彼らには、行政の目が届かないことも多い。

NPOとして役割を果たした面は結構あり、たとえば先遣隊の時期に、福祉避難所で医薬品が足りない

ことを発掘した。ただし、避難の状況はめまぐるしく変わり、避難所が日々縮小していく中で、わずか2時間

位の聞き取り調査ではすべてを把握しきれない制約もあった。

■活動の推移の状況と ITニーズの変化、ITリテラシーの課題

活動のピークは発災から 5月1日までの5週間（フェーズ1）で、ボランティアを週平均80人ほど派

遣した。派遣した人数も訪問する避難所も多かった。

フェーズ 2は 3ヶ月単位の長期インターン（14名）と1週間単位のボランティア（10名～30名）を動

かした。避難所は10箇所ほどに絞り、地域密着型として、周辺の在宅避難者も含む支援を行った。地元の

方とのつながりができ、8月以降のフェーズ 3では地元で動きたい人をサポートする形態に変えた。支援

テーマはどんどん変わり、最終的に10月位に避難者全員が仮設住宅に移った。

聞き取りを通じてアセスメントを行い、つないでいくというのが「つなプロ」の活動の根幹である。仮設住

宅の段階になると、初期のクラウドで立ち上げたデータベースは意味がなくなり、SNSで情報を随時共有

できることの方が、優先度が高かった。

ニーズ情報を地図情報にプロットできるシステムも用意されたが、NPO側との連絡調整不足、利用者

の ITリテラシーなどの課題があり、システム活用の有効性を示すことができず、あまり利用されなかった。

この段階では現地密着が基本で、その場での決定が多く、団体のリストが共有されていれば十分で、それ

以上のシステム利用の必要性はあまりなかった。

87

■2011年3月18日にタイムスリップした想定での教訓・提言

避難所からの情報発信方法が重要で、今後の課題だ。巡回だけでは少ない情報しか得られず、避難所

に貼りつかないといけないが、それでは人が不足する。本当は避難所にシステムがあったほうがいいが、

専門的な眼と莫大な投資が必要になる。避難所での支援は重複が多く、他の団体が既に来ていることも

多かった。錯綜は仕方ないが、避難所管理機能は今後も重要になるのではないか。

情報をどこまでオープンにするかの判断が難しい。災害弱者の個人情報等はオープンにせず、連携

NPOだけに IDを渡せばいいが、付き合いのない団体には IDを渡さないようにした。その団体の信憑性

の問題である。情報をどこまでオープンにするか、普段からお互いに協定を結ぶ必要がある。

まとめ：知見を活かし、連携する団体で立ち上げ、被災地を拠点にマッチング展開

大規模災害時には、膨大な物資・サービスの支援ニーズが発生し、供給側とのマッチング作業は大き

なチャレンジとなる。今回の東日本大震災でも、ITを活用した各種マッチングサイトが多数出現した例で

ある。

コアメンバーに阪神・淡路大震災で被災した外国人への支援活動を行った方がいるなど、災害支援へ

の知見、問題意識をもっていた。日頃からの横の連携をもった団体同士で立ち上げたことも、ポイントで

ある。事前に関係性がない団体との情報シェアの困難性も指摘された。

被災地に拠点を置き、そこから展開する支援活動に直接必要な機能をサイトに実装した点が、特徴的

である。IT企業の全面支援を受け、共同開発をしたことも、今後の教訓を含めて注目される。また、被災者

が避難所から仮設住宅に移転するなど、状況の変化によって支援ニーズも変わり、ITシステムに求めら

れる機能も変化した。

88

(4) ネトボラ宮城

ご対応者：代表 佐藤大氏

サイトの特徴：宮城県内の避難所や各種拠点にインターネット環境を整備。被災地での情報収集・発信の

支援。

■立ち上げの経緯

当初は一人で立ち上げを考えたが、東北大学医学部の教授が運営する保健医療支援室から医療・福

祉拠点でのパソコンやインターネットの整備支援の要請があり、4月になって周囲に呼びかけた。これに対

し多数の参加者が集まったため、広く一般への支援に対象を拡げて活動を始めた。最初はパソコンのない

医療拠点に対する情報共有のための環境整備を手伝っていたが、4月中旬より、「ネトボラ宮城」として独

自活動を展開した。

Twitterによる情報提供を始めたきっかけは、当時の予想

として、ゴールデンウィークにボランティアが集中することや、

渋滞や混乱が発生することが考えられたため、あらかじめ交

通情報やボランティア情報を流すことを計画したことであった。

Webサイト公開は4月21日で、ニーズにあわせてページの

コンテンツやフォーマットを変えていった。立ち上げまでは一人で実施して3日かかったが、方針や内容等

で迷った時間も含まれ、作業で実際に困ったことはなかった。Wikiやメーリングリスト等は、以前から使っ

ていたものを使い、サーバーも職場に以前からあった自分のサーバーを使った。当初は信用を得るために

大学のドメインを使用していたが、サイトの知名度が上がったため、汎用 JPドメインに後日移行した。

■メンバーの形成

知り合いのエンジニア、メーリングリスト、Twitterで呼びかけて集めた。スペシャリストでなくてもできる

89

支援を、Twitterなどで広く声をかけた。人数ではTwitter、“この分野の人材”という点では知り合いが効

果的だった。 ボランティアなので、役割分担は一切指示せず、全て立候補制で進めた。ボランティアは

毎日活動できるとは限らず、サイト更新をルーチンでこなせる人が少なく、コアメンバー3人の負担が大き

かった。グループとしての企画運営ノウハウや宣伝の方法なども課題であったが、それぞれの課題に応じ

てメーリングリスト上でオープンに相談していた。

■被災地と遠隔地の連携作業

これまでつながりのない技術者は、Twitterでの反響が多かった。オンライン作業は環境があれば被災

地の外の誰でもできるので、プラットフォームも遠方からの支援を意図したものにした。

現地に駆けつけるには被災地に近い仙台にいる強みがあるが、ネット上での支援は遠くにいる人にや

ってもらった方が良い。負荷分散という意味もあるが、被災地から遠く、関心の低い地域に関心を持たせる

きっかけを作ることを意識した。こうして、サイト運営やツイートは、遠隔地メンバーにほぼ任せることがで

きた。

■情報の収集・発信

本業の活動は被災地へのパソコンの設置だが、Twitterでボランティア情報の提供を行い、Webサイト

上でボランティア情報、交通情報、気象情報などのリンク集、設置した機器で使うための情報ポータル（行

政を含む生活情報、道路情報、携帯のサービスエリア等のリンク集を、気仙沼、石巻などの各地域向けに

それぞれ用意）の整備を行った。

ボランティアの情報は連携団体を通じたり、ボランティアインフォさんが社協等から電話で集めた情報

を提供してもらってネットで流したりした。後に社協や支援団体のWebサイトやブログが増えてきて、ネッ

ト上でも情報収集できるようになった。Twitter経由で得られた情報は、メーリングリスト上の3人のメンバ

ーが、情報の信憑性等のチェックをし、運営方針の整理・提案も行った。

90

常に情報を更新し続けることが課題で、7月頃まで、現地情報の入手手段が課題だった（電話しかない

ボランティア団体の情報など）。情報ボランティア（情報流通の価値を知っており、現地での情報のやり取

りに専念できるボランティア）が不足した。現地に入り込んで情報発信をする「取材班」的なボランティア

が本当は必要だった。

まとめ：被災地からの IT支援ボランティア活動を効果的に展開

4月後半になってからの立ち上げは、厳しい状況が続いていた被災地現地では、当然と思われる。そ

の現地に拠点を置きつつ、被災地外との連携、分業を、Webサイトや Twitterを活用して、効果的に推進

した例として注目される。ボランティアメンバーの呼びかけ、情報の収集・発信などに様々な工夫がみら

れた。「情報ボランティア」の不足という指摘がなされた。

(5) 一般社団法人SAVE IWATE

ご対応者：事務局長 加藤昭一氏 金野万里氏

サイトの特徴：岩手県盛岡に拠点を置き、被災者と支援者への情報提供／支援金・支援物資・ボランティ

アの募集／活動報告。

■立ち上げの経緯

現在の代表が 3月12日に宮古に入り、事態の悲惨さを知っ

た。代表の知人（遠方）の後押しもあり、13日に支援活動の開始

を決定し、6人が被災地支援チームで活動を始めた。3月13日

16:27、メーリングリストに発信。その晩のうちにWebサイトの運

91

用を開始した。サイト構築に詳しい技術者の存在と、通電が早かったため、12時間で立ち上げができた。

立ち上げが早いことで、直後から遠方のボランティアに情報の提供を行った。被災地と遠隔地をつなぐ

役割を果たし、ボランティア団体や市民活動の中からスタートしたことが寄与につながった。

■メンバー形成と人材の確保

まず安否情報サイトを立ち上げた。協力を募るためということもあった。発災以前に利用していたメーリ

ングリストを活用し、友人、市民活動、NPOの仲間に呼びかけた。

■情報収集

活動初期はメンバーが現地にて対面による情報収集を行った。他の手段はなく、詳細な情報を得るため

に必要だった。3月25日頃からは、メールが利用できるようになり、メーリングリストからの口コミも活用し

た。

中期（4月下旬～5月上旬）：被災地の電話帳を利用し、無作為に電話して情報収集を行った。

■サイト運営継続の理由

震災の風化を防ぎたいという想いが強いが、内容によって書いてよいのか、異論があることがある。生

活困窮者が支援を必要としていると書きたいが、難しい。残酷な取材をしないと真実を伝えられない。ただ

実状の一端でも伝えられればという想いでWebを更新している。Webやメールだけでの情報提供で十

分とは言えないが、現実を知りたくなるコンテンツの発信が必要である。

まとめ：被災地の厳しい実態に即した展開をした

沿岸被災地支援のために、盛岡を拠点に活動したサイトで、被災地の厳しい実態に即した展開をした

点が注目される。発災翌日に現地を訪問、翌13日、震災前からのメーリングリストに呼びかけ、停電から

92

復旧したこともあり、12時間でサイトを立ち上げた。初期には現地訪問、中期には電話と、アナログ型で

情報収集を行ったことも、現地の厳しい実情の反映である。

(6) うらと海の子再生プロジェクト

ご対応者：東北デベロッパーズコミュニティ 小泉勝志郎氏

サイトの特徴：宮城県の浦戸諸島の養殖漁業復興支援。

■立ち上げの経緯

浦戸諸島（宮城県塩釜市の離島）に移住した翌日に震災

にあった弟への支援がきっかけだった。津波による被害がひ

どく、産業が無くなるとの危機感から、漁業の再生をめざす

活動を始めた。

既存のネット通販システムを利用して、支援金の募集を目

的とした「一口オーナー制度」を開始した。2011年3月下旬に準備を開始し、4月11日にサイトを公開し

た。サイトで呼びかけることで、漁業再生に必要な支援金を集め、漁具を購入でき、オーナーには生産され

た海産物を送るという仕組みである。

支援金募集サイトは、海産物の生産量を考え、その後いったん閉鎖した。

■技術部品の選択・サイト移行

当初利用したシステムは、塩釜市が震災前より地域産業活性化のために稼働させていた既存ネット通

販システムだったが、行政サイトで収益事業を続けることの社会的影響を考慮し、プロジェクトの一般社

団法人化を期に、6月末にGoogle Sitesに移行した。Google Sites選択の理由は、自分の経験、費用無

料、テンプレートがあり更新が容易なことなどである。他のプラットフォームとの比較は行わなかった。

93

OSS（オープンソースソフトウェア）は、一般にはライセンス、費用などの制約が少なく、早期立ち上げに

向いているが、被災地の様々な制約から、Google Sitesなど既存の仕組みを利用する方が、手間がかか

らずより早く立ち上げられると判断した（小泉氏自身はOSSに通じた技術者であると同時に、自らも被災

者である）。

Google Sites に用意されている部品で多くの機能を構成できるが、ブログの更新情報表示やTwitter

との連携などについては、独自のガジェットを作成、実装した。CSSが使えず、体裁を整えるため、ガジェッ

トで工夫。既存部品で構成できると思っていたが、結局プログラミングで対応することになった。

■今後の教訓

災害時に動けるためには、平時から情報を知識としてストックしておくことが重要である。震災前からオ

ープンソースコミュニティに入っていたが、今回はより簡便にできることにこだわった。オープンソースで

動いたのは被災地外の人で、プログラミングを集中的にできる状況にあった人がほとんどではないかと

思う。

被災地では、深刻な被害を受けた人々が多く、状況が逼迫しているため、精神的、時間的にプログラミン

グに集中することはとても困難だった。そのため、プログラミングをなるべく行わないで機能を実現できる

方法を考えた。オープンソースは自由度が高いが、その分自分で行う設定が多すぎ、手間がかかる側面

があり、十分使いこなせるメンバーが必要となる。

まとめ:被災地の厳しい状況が、技術部品の選択に直接影響を与えた

家族が被害の直撃を受け、生活の再建、産業の再興を直接支援するためのサイトである。被災地の厳

しい状況、制約が、技術部品の選択にも直接影響を与えたことを実証する例といえる。

94

3.2.3. インタビュー記録：個人が中心になって運用したサイト

本節では、インタビュー全体の中から、主として個人が支援活動を牽引したとみられる事例を選び、サイ

ト立ち上げ・展開の過程、技術部品の選択、運用面の課題、他との連携、社会的課題への対応などについ

て、具体的にどのような特徴的事実が存在したのかに着目し、整理した結果である。

アンケートの記述内容からは、企業などの組織が運営するサイトであっても、立ち上げやその後の展開

には、特定の個人の思いやリーダーシップ、経験やスキルが発揮され、活動の展開に寄与したとみられる

ものが多かった。しかし、彼らは同時に、様々な課題にも直面したとみられた。

(7) 311HELP.com

ご対応者：株式会社42 代表取締役 田原大生氏

サイトの特徴：被災者が必要とする物資と支援者の物資提供とのマッチングサイト。支援要求を地図上に

表示。

■立ち上げの経緯

3月17日に公開した。殆どの部分は、発災後72時間以内に

作成できた。

テレビで津波の被害映像を見てすぐ支援活動開始を決意し、

即日ドメインを取得したが、しばらくは、何をすべきか見えなかっ

た。生存者確認情報を考えたが、他の団体が取り組んでいたの

で、一人で悩んだ末に物資の支援にした。

これまで NPO活動などやったことがなく、ボランティアのイメージはマイナスであり、恥ずかしくてでき

ない、という思いがあった。もともと現地に行こうとは思っておらず、むしろ立ち上げのときには「現地には

行くな」、という雰囲気があり、行けないなりの支援の方法を考えた。支援物資の情報提供による支援に行

95

き着くまでは、他には相談せずに１人で黙々と考えていた

ソフトバンク孫社長のツイートで一気に拡散し、テレビ放映などでアクセスが急増したが、Amazon

Web Services（AWS）の運用ノウハウがあったため、対応できた。

■運営のポイント

地図が有効であるとの意見を受け、地図にこだわった。不動産システム開発の経験から、マッシュアッ

プ技術はわかっていた。親に紹介された東北学院高校の生徒が、避難所を訪問して必要物資の情報を収

集・提供してくれたことが効果的だった。高校生が動く方が注目を浴びると考えた。仙台には5月頃の落ち

着いた段階になってから実際に行って、東北学院の生徒と一緒に、多賀城市役所や避難所などを訪問し

た。

ピーク時にも、サイトに寄せられたメールには一件一件、丁寧に書いて返信した。資金はすべて持ち出

しだが、それほど大きな費用は出ておらず、自身での作業がほとんどであった。

■制度的な課題

情報の信憑性を確保するために、実名・メールアドレスをフルオープンにしたが、とくに問題は起きなか

った。個人情報、セキュリティ・ポリシーは意識していたが、価値ある資料になるとの意識から、本人の同意

を得る形で、個人情報を公開した。

■メンバーの形成

チームづくりの過程では、まったくつながりのなかった人から、手伝いたいと声がかかったが、その場合

には自分で何ができるかを尋ね、参加者の主体性に委ねた。例えばAPIを作りますという技術者にはAPI

のみを任せるようにした。

初期のサイトスケッチは大変だったが、管理画面作成後オンオフ機能をつけ、管理してもらう人に管理

96

を委ねた。マネジメントのモチベーションを保つ仕組みとして、自発的に取り組みたいことを募った。こちら

から依頼することはしなかった。サイトに実装する手前の段階で送ってもらい、こちらでテストして大丈夫

なら運用する、という分業が生まれた。これらを通じ、お互いの助け合いが生まれた

■展開

夏に「ISAM HOPE-Japan」というイベントを開催、一部の支援メンバーとははじめて実際に会うことが

できた。このイベントの結果、農家が自分で採取していた放射線量を民間で調べて公開していくべき、とい

う話がきっかけとなり、放射性物質拡散範囲を確認できるオンラインマップ支援サイト、“HOPE-Japan”

を開設した。京都大、豊橋科学技術大等も参加している。放射能を測るのにお金がかかるのがネックとなっ

ている。

まとめ：個人中心だが、支援メンバーの主体性を尊重、責任ある分業体制をつくった

個人の強い動機で開始され、自分のもつ技術の力を通して社会的に貢献できた代表的な事例といえ

る。

災害時に支援を申し出る人は多いが、自分で何をしたら明確でないまま手伝いに来られると、適切な

タスクをアサインすることが難しく、マネジメント側のボトルネックを生じることも多い。311.HELPでは、手

伝いたい人に具体的な提案をしてもらい、実際に開発作業をしてもらうことで、自分で責任をもってチー

ムの一員となり、互いに助け合い、責任をもったチームを形成することに成功した点が注目される。また、

イベントを通して新たに放射能測定・確認サイトを立ち上げるなどの展開につながっている。

97

(8) 防災情報ストリーム

ご対応者：株式会社コエカタマリン 代表取締役 入江太一氏

サイトの特徴：Twitter上の情報を利用した災害関連情報のとりまとめ・案内

■立ち上げの経緯

中学生のときに阪神・淡路大震災を大阪北部で経験した。

そこで 3.11 が発生し、正義感から今こそ支援が必要と考えた。

生命が脅かされる感覚を、身をもって経験したことで、題材とし

て安全を考える契機になった。

震災直後、以前経済産業省Twitterまとめサイトの仕事を一緒にした知人から依頼され、3月13日に

開設した。実質の作業時間は1−2時間で、修正がなければ数時間でできるものだった。既存のプラットフ

ォーム・技術を応用することで、災害関連情報を必要とする人に広く知らせることができると考えた。

■提供の意図

ITリテラシーの高くない人でもわかるようなものを作りたい、というのが動機だった。たとえばTwitter

の使い方がわからない人でも、新聞を読む感覚で閲覧可能なプラットフォームの提供をめざした。

実際の被災者、本当に必要な人は見られない状況にあるとは理解し、見てもらえるとは期待していなか

ったが、支援者の継続支援のために防災情報を公開することにした。水先案内が目的。Twitter上での情

報の傾向を知り、多様な情報入手の糸口を提供することを重視したものである。

Twitter経由で収集、提供する個々の情報の真偽は検証しなかった。全てを開示する状態が土台にあっ

てこそ次の行動に移れると思い、必要最小限の機能の提供に限定した。Twitter検索だとハッシュタグを

個別に探す必要があり、全体の把握ができない。全体を一覧化し、ソーシャルメディアに参加していない

人でもわかるようにと考えた。

98

■サイト機能の変更・改善

Twitter側のAPIの利用回数・頻度には制限があり、2週間後からはリアルタイム性は犠牲にして、1

時間4回、サーバーから情報取得する設定に変更した。情報の集約を優先し、リアルタイム性を求める人

は、直接Twitterを利用してもらえればよいと考えた。

Uniqueユーザ数などのアクセス記録は、ログを取得していないため不明である。ユーザからのフィー

ドバックでサイトの改善をするのが良いと思っていたが、実際のフィードバックは、Google docsでデータ

を共有した一部のユーザからのみで、計10名程であった。

■エンジニアとしてのマインドについて

自分は、技術スキルはそう高くないと考えている。ポイントは、視点を変えたことである。技術的に高級

なところに留まって、Ajaxをばりばり動かすことよりも、少し緩い感覚で目線を下げ、簡単にできることで価

値を持つものがあると考えている。マッシュアップは高級ではない、だれでもできるようなものを作ること

にも意義がある。元のサイトも、3時間でできたものである。思いつくかどうかでなく、目線下げたら、思い

つくはずである。

■教訓・意見

政府など公的機関には、よりオープンな情報開示を期待したい。情報が多ければ、情報に触れられる機

会が増え、役に立つ。テレビだけ見ていたら、リテラシーは意味を成さない。また、震災以前から操作可能な

形のデータが広く公開されていれば、緊急時にも、普段から使い慣れていることができ、多様な取り組み

が数多く出現する可能性があった。

まとめ：技術的に高度でないことでも、社会的に有用な機能を

99

技術的には必ずしも高度ではないことでも、社会的に有用な機能を提供できるというメッセージは、今

回の支援サイト等全体に見られる傾向と共通するものがある。Twitter経由で集められる情報を、分類整

理して、一般向けに提供するという手法をとったサイトは、今回の調査では多数みられた。

(9) WiFiMap 無線LANアクセスポイント強度地図作成

ご対応者：keydepth氏（鍵井清幸氏）

サイトの特徴：災害後に避難所生活となり、通信環境が失われた場合、草の根で通信環境を探す方法を

Androidアプリとして提供。無線LAN技術、地図位置座標技術、情報蓄積共有技術を活用。

■立ち上げの経緯

震災時は茨城にいて、数日間避難所生活であった。自分は

安全が確保できたので、被災した人たちのために何か支援で

きないかと思ったのが動機だった。しばらくは電気・ガス・水道

のない避難所で、ネットも繋がらず不便だった。3 日後に電気

は回復したが、水道は使えなかった。避難所の人々はスマート

フォンをもっている人が少なく、インターネットのページは見ら

れなかった。無線LANがあればパソコンは使えたと思って発想した。

震災の 5～6日後に愛知に移動し、1人で開発し、3月21日に開設した。ライブラリなどの基本技術は

持っていたものを流用して、早くできた。地図情報はGoogle Mapsにマッシュアップした。調べないとでき

ないとは思ったが、Web アクセスの統計情報、データ自動収集、SQL アクセスなどの技術ノウハウは持っ

ていたため、見通しは立っていた。

100

■利用実績

Android向けの同種のアプリが少ないためか、アプリのダウンロード数は、震災から 4月までで9,000、

以降は36,000、50,000、60,000、80,000と順調に増加し、現在260,000になった。地震の時とは違う

用途で、現在も日々使われている。最近サーバーのアクセスが増えすぎたため、レンタルサーバーのサー

ビス提供ができなくなったため、移行しなければならない状況である。

まとめ：ユーザ視点から、必要なサービスを短期で提供

自分が体験した避難所生活から、不便と感じたニーズを発掘し、自分がもつ技術力を活かして短期間

に開発・提供した例である。社会的状況・ニーズを的確に受けとめ、スマートフォンやクラウドなどの環境

を活用することで、個人によって簡便にかつ実用的なサービス開発が容易に可能になった時代を窺い知

れるものの、安価に調達できるサーバの利用では、過負荷が容認されないことがある。

(10) 緊急地震速報 by Extension

ご対応者：（株）２２ Inc. 代表取締役 石本光明氏

サイトの特徴：Google Chromeの拡張機能を使って緊急地震速報を表示。

■立ち上げの経緯

3.11の発災後、余震を知らせる緊急地震速報などのニュー

スを受けるために、自分も含めて、テレビをつけたままにする人

が多かったが、省エネでもなく、速報音が不快で、常時テレビ

をつけておくことに疑問を抱いた。そこで緊急地震速報をパソコンにプッシュ型で自動配信するソフトの自

101

作を考えた。情報源としては、Twitter上に流れる緊急地震速報を取り込むことにした。

スピード重視で開発したが、できたときはうれしかった。震災前からWebSocket技術に注目していた

ので、実装の見通しは立っていた。WebSocketは開発途中で安定した仕様ではなかったが、他の選択肢

がなかった。ブラウザのエクステンションを作るのは簡単なので、ネイティブでアプリを作成するより、早く

リリースできる。

■アクセス状況と対応

1台のサーバーで1万件のクライアントに対応する能力があった。ユーザ数は、せいぜい1日500人

程度と想定していたが、すぐに 1日1万以上となり、大変な焦りがあった。

アクセス数は最初の一週間がピークで、１日１万程度に到達した。4月11日に大きな余震があり、その

際にまた大きく増えたが、その後は減少し、時折大きな地震があると多少数が伸びるといった状態になっ

た。ピーク時には、32,000～33,000のクライアントに、サーバー4台で対応した。サーバーのコストは安く、

負担にはならなかった。

クライアントのダウンロードは、アクセスログからみると 3月17−18日がピークで、大きな余震の翌日、

4月12日が再度ピークとなった。データ通信量も、地震の量に比例する。インストール数は、延べ64,000

クライアントになった。Google Analyticsも、管理画面に拡張タグで参照できるようにして、ダウンロード状

況をモニターした。

■情報セキュリティ面の課題

当初は拡張機能、サーバーの実装面で、リツイートも配信されてしまうなど、いたずらへの脆弱性があっ

た。そこで情報源をスクリーニングする工夫が必要になった。サーバー側の配信設定を変更し、クライアン

ト側は自動更新されるようにした。

102

■技術的課題とその対応

Twitter 側のAPIの影響で、データが円滑にパースできなかった。API の仕様通りではないデータが

返ってきた際の異常処理に課題があった。そこでサーバー間で通信するコードを書いて対応した。また、一

定期間通信がないとネットワーク上の機器が自動切断してしまう問題があった。html5jのコミュニティに

質問し、回答を得て対策を立てることができた。WebSocket の度々の仕様変更にも苦労したが、β段階

のため、仕方がないと考えている。

不足したリソースは、情報だった。接続切れ、運用ノウハウ、サーバーの性能などで、実際に作ってみな

いとわからない部分が多かった。同じエンジニアでもバックエンドとフロントエンドで違う。ネットワーク関

係の技術は、知り合いに詳しい人がいないため苦労した。

緊急地震速報の情報を気象庁から公式に受け取ることも考えたが、コストが高いので断念し、Twitter

を情報源に選択した。気象庁にはオープンに配信するようにして欲しい。

品質面での見切り発車としては、通常はリリース前に必ず行うベンチマークをしなかった。

経験共有の機会として、ブログやコミュニティ、html5jの勉強会のライトニングトークで発表してきた。

■今後について

今回のような公的に価値のあることを、個人の趣味で取り組むことが正しいのかと考えることがある。資

金面では、サーバーの費用などに関して何らかの補助があればよいと思う反面、自分個人で自由にやっ

ていきたいという思いもある。ただし、たとえば、自分が病気で長期入院したら、維持するのに困るようにな

る。その点では、安定して運用できる団体が存在するなら、依頼したいとも考える。

まとめ：エンジニア個人で迅速に立ち上げ、Twitterを情報源に公的情報を共有

ユーザニーズを的確にとらえ、簡単な開発で迅速に立ち上げ、展開した代表例といえる。気象庁からの

公的情報に費用的制約があるため、Twitterを情報源に採用したのも、他の例と共通する。

103

技術的には、開発途上にあったWebSocket技術を採用し、チャレンジも少なくなかった。めざす機能

を実現する最適手段として、そうしたチャレンジに積極的に取り組む「エンジニア魂」が感じられる。

(11) 炊き出したん

ご対応者：株式会社 Re:Kayo-System 代表取締役社長 寺園聖文氏

サイトの特徴：Twitterによる炊き出し情報の案内

■立ち上げの経緯

震災直後に開設を決意したわけではなく、ニュース等で被災

地の状況を見て、できることを考えていたが、通常通りの生活を

するしかなかった。知り合いがFacebookで炊き出し情報を収集

していたのを見たのがきっかけになった。そこで情報を集めても、

従来型の携帯電話で見る方法が無かったので、見られる方法を

作ろうというのが活動の動機だった。

他にできることが思い当たらなかったため、まずは一人でも必要とする人がいればという思いで立ち上

げ、開設してから必要なこと不要なことを精査していこうという意識で始めた。他の方から意見を聞きなが

ら進めればもっとよいものになったかもしれないが、一人で進めたので、逆に早期公開につながったとい

104

えるかもしれない。

■立ち上げメンバー

基本的には一人で活動しようと思ったが、活動したいという人がいるだろうという思いから協力者を募

った。メンバーが多いと調整が図れない面が出てくるため、プログラムの依頼に限って、2 名体制で取り組

んだ。

■情報の信憑性の確保

「炊き出しまっぷ」サイトから定期的に情報を取得し、リクエストに応じて Twitter で呟く仕組みで、元情

報のコピーを保持したが、個人が登録したものなので間違いもあった。何が間違った情報かの判断が困

難だった。複数場所のデータの管理も難しかった。

誤ったデータを削除するのではなく、コピーしたデータに正確性に関する付加情報を加え、検索時のヒ

ット率を低くする工夫をした。データの誤りの判断は、現地の声を反映するようメールやTwitterで受け、情

報を追加した。

■マッシュアップなどの制約への対応

Google Maps APIのアクセス制限・ブロックを回避するため、情報取得は30分間隔に設定した。

Twitter側のAPI制限も、複数アカウント利用などの工夫で、ブロックされるのを回避した。

GAE を活用した情報取得では、タイムアウトしないよう短時間の処理を心掛けた。アクセス数の増加や、

GAEの料金体制が途中で変わったため、なるべく料金がかからないようにプログラムを変更した。

■今後の教訓など

情報源としてニーズを把握し、活動を知るためにはソーシャルメディアの持つ役割は大きい。

105

今回は炊き出しのみを取り扱ったが、情報の内容と質的に適切であったのか、実際に現地のニーズに

合っているのかという点について、今後同じような状況に陥った際に経験が活かされることを望む。

まとめ：ソーシャルメディアを活用、必要な情報を簡単に共有

情報源として別の炊き出し情報サイト（炊き出しまっぷ）を利用、配信機能は Twitter経由でのリクエス

トに応じて個別配信するという、シンプルな仕組みで成果を上げた例として注目される。単に機械的に自

動収集・配信するのではなく、情報の信憑性チェックの仕組みを、ユーザからの投稿により組み込んだと

ころに工夫がみられる。

(12) TwitForYou!

ご対応者：ロケットスタッフ株式会社 代表取締役 高榮郁氏

サイトの特徴：被災者に必要な支援を必要な分だけ送ることができる、支援マッチングサービス。

■立ち上げの経緯

もともと Twitter経由の商用フリーマーケット・サービスを運営していた。震災発生後に、そのプラットフ

ォームを物資などの支援マッチングサービスに転用した。フリーマーケットはサービスを停止した。機能的

にはほぼ同じものであり、目的・内容を変えることで、震災2日後の3月13日に提供可能となった。

3月20日にソフトバンクの孫社長がTwitterに「素晴らしい」と投稿したことで、利用者が一気に 50

万人に達し、アクセスのピークを記録した。

■サイトの仕組み

106

「支援します」というボタンがあり、登録するフォーマットがある。タイトルは 20文字から30文字で、記

入すると Twitterのユーザに広がる仕組みとなっている。写真や地図のアップロードにも対応している。

支援をしたい側が物資を購入して送るパターンが多い。受け取った側が支援完了のボタンを押せば、

結果が表示される。なかなか支援が成立しないものは、直接電話等で確認し、管理者権限で入って仲介・

成立させるなど、運用の負荷は大きかったが、その時はそうするしかなかった。

ビジネスとして用意したサービスを流用したため、システムの仕組みはしっかり埋め込んである。

■サイト構築・運用について

会社の業務を 2～3週間休んで取り組んだ。システム自体は韓国で開発したので、エンジニアの確保

は問題なかった。韓国のエンジニアたちが、日本を応援しようという気持ちを持っていた。

開発費用が必要だったが、成果が出たらインセンティブを支払うという予定だった。結果的には韓国の

技術メンバーが報酬なしのボランティアで取り組んでくれた。サーバーは日本のサーバーで、アカウントを

発行して韓国からアクセスしてもらった。プラットフォームは新規に月5万円程度のレンタルサーバーで準

備したが、アクセス過多で何度もパンクし、そのまま20分～30分放置することも多かった。Amazonの無

料サービスの存在は把握していなかった。

■支援ニーズの変化

当初は米や水など食料支援が中心だった。去年の 7 月頃にはカレンダーのニーズがあった。仮設住宅

への入居等が始まった時期で、津波で流されてなくなったからだろう。直近では将棋等の娯楽的なもの、

浴衣などのニーズに変わっている。

必要なモノは多様化しているが、被災地から具体的に何がほしいと意見を出すことは難しいこともあり、

きめ細かなニーズをどう吸い上げるかが課題である。たとえば「味噌汁がアレルギーで飲めないので他の

スープが欲しい」、「カツラが必要だが言えない」といった支援事例もあった。貴重なニーズを吸い上げて、

107

ピンポイントで送ることができた。最近はサービスの支援が多くなってきた。支援を受けて結婚式を実現で

きた夫婦も2組あった。

■社会的課題への対応

プライバシーポリシーは、わかっていたが、急いで立ち上げ、運用に追われたために、準備する時間が

なかった。支援者のなかには、被災地の女性に付きまとったストーカーのような人がいて、警察沙汰になっ

た。役所からも「住所が残っているので消してください」と苦情・依頼がきた。キャッシュに残っていたもの

で、キャッシュ消去の説明などに、人手が必要だった。

法的対応という面では、弁護士を共通に利用できるような仕組みがあればよかったと思う。

■金銭的な協力を得ることやサービス停止の難しさ

運用の資金負担については、会社としてボランティアで行っているため、理解、協力を得るのがなかな

か難しい。「企業として当然のことではないか」といった視線を感じる。打ち切りたくても、まだ利用者がい

るため、途中で打ち切ることはできない。「やってあげたい」という気持ちだけで、ビジネスにならないと継

続は難しい。アイディアを金銭的なものでフォローしていくプラットフォームが必要だと感じている。

まとめ：経営者による社会貢献、国際協力の例

専用サイトとTwitterによる拡散とを組み合わせることで、支援のマッチング機能を効果的に実装した

例である。企業を経営しながら、商品だったはずのものを無償の支援サイトに転用するなど、CSR（社会

貢献事業）として取り組んでいるが、それだけに苦労もある。運営者は日本で ITビジネスを行っている韓

国人経営者であり、開発も韓国のエンジニアが取り組むなど、国際協力が発現した貴重な例である。

108

(13) JAWS-UG 災害復興支援

ご対応者： JAWS-UG 代表 竹下康平氏

サイトの特徴：被災者のためにインターネット上で情報発信をしたい企業・団体・個人の ITインフラの支

援。技術者コミュニティによる支援活動。

■立ち上げの経緯

AWS User Group - Japan（通称JAWS-UG）は、

Amazon Web Services（AWS）の利用促進や情報交換のた

めのユーザグループである。メンバーは、全国26支部、約

150人いる。もともと全員がビジネスではなく、ボランティアで

参加するグループである。回答者の竹下氏はその代表を務め

ている。

震災後、Amazonと連携・情報交換を行い、被災してインフラ機能に支援が必要なサイトに資源と技術

支援を提供する支援活動を展開してきた。支援提供を伝えるには、Twitterでの拡散がもっとも効果があり、

合計50～100の支援依頼が寄せられ、そのうち 30程度を支援。被災自治体には、こちらからFAXで直

接アプローチをした。電話は迷惑だと考えた。自治体からの回答率は直後で 10～15％ほどあった。支援

依頼を受けた自治体に対しては、情報の代行発信も行ったところがある。反応があったのは、多い順に宮

城、岩手、福島であった。比較的被害が大きくないところからの反応が見られた。

コアメンバーは、ピーク時は15人前後で、その後Amazonに入社したメンバーもいる。現在のコアメン

バーは東京で7、8人程度である。支援を決定したサイトに対しては、原則として、必要とされる機能・仕様

に強い担当者を一人つけ、すべて作業する体制にした。

■技術部品の選択とサポート

109

AWSでの支援内容にはOSのライセンス料金が含まれていたため、Windowsも Linuxも短時間で

立ち上げが可能だった。先方サイトの元々のOSや仕様に合わせて移行作業を行った。さくらインターネッ

トや、マイクロソフトのAzureの人々と情報連携した。Azureの方が得意な分野は任せる、というように。ク

ラウドコミュニティは、企業系列を超えて横のつながりが強い。

災害当初、クラウドの無償提供を行う企業が多く出現したが、設備のみの提供が主で、移行作業などは

支援対象外のところが大半だったようだ。自分たちはAmazonと協力しつつ、技術・労力まで提供した。そ

のようなことができるコミュニティが重要と考える。

クラウドの活用にはユーザグループの育成が必要。Amazonだけでなく、クラウドに関するコミュニティ

に参加しているエンジニアが横につながったことの意義は大きかった。

まとめ：被災地の情報支援にクラウド基盤を提供、ボランティアによる技術・人的支援まで

今回の震災では、多くの ITベンダーが、期間限定で「クラウド無償利用」を提供した。JAWSは、

Amazonと連携するものの、ベンダーから独立したユーザグループで、IT企業の経営者やエンジニアが、

ボランティアで技術作業の支援を行ったところに特色があった。技術コミュニティにより複数の実際的な

支援を実現した点は顕著である。

(14) 近隣Tweet確認サイト

ご対応者： NTTコミュニケーションズ株式会社 小松健作氏

サイトの特徴：近隣の災害・支援情報を Twitter経由で提供・共有。

110

■立ち上げの経緯

ただ単に何か支援をしたいという思いで始めた。自分たちの

技術を生かした貢献がしたかった。

利用者が指定した地域についての、Twitter上での交通・避難

情報などの災害関連情報を検索・確認できるサイトを 24時間で

立ち上げた。社内のオープンラボを使い、周囲にいる社員に声を

かけ、技術者7人で取り組みを進めた。直属上司の了解は得た。役員からも、発災3時間後に異例の許可

を得た。通常の社内手続きは省略できた。

ハッシュタグ追加、キーワード検索機能などのノウハウがあり、負荷にはならなかった。こうした Twitter

利用サービスの研究開発で培われたノウハウがなければ難しかった。早期に立ち上げられたことには、帰

宅後に自宅から SSHでVPN接続し、作業が可能だった勤務環境も寄与している。

■技術部品の選択

社内サーバーを利用し、Apacheからインストールした。ソフトウェアは一から開発して立ち上げた。早

期に開発が終わることを優先し、Ruby on Railsを選択した。

Twitterに特化したユーザインターフェースを採用し、先行ノウハウを応用した。立ち上げ時間を優先し、

ユーザインターフェースの作り込みはさほど行わなかった。運用開始後に、ユーザインターフェースを若

干改良した。持っているノウハウで可能な範囲に留め、「技術的なチャレンジングをしない」と良い意味で

割り切りをした。最低限の目標を決め、それを優先した。

小松氏が主導をとり、24時間で開発の役割は終了した。オープンソースについては、業務用ではあまり

実装していない会社だが、自分たちはR&D部門の研究職として、内外の勉強会、社外の技術者コミュニ

ティに積極的に参加しており、そうした交流、日常的な情報交換があった。

状況変化に応じた技術的な選択として、地域、地名についてのハッシュタグを網羅しなければならなか

111

ったが、適当なものを探し出すのが難しかった。データをどこから収集するかが課題だった。これらは 2名

で行った。

ハッシュタグのまとめサイトがあったため、それを参考にしつつ、該当エリアの実際のTweetや実際の

ユーザから連絡のあった情報を手作業で集めて掲載した。

まとめ：企業内で個人が主導、会社もサポート、技術より早期の立ち上げを優先

IT大手企業の社員が、個人としての自発性と会社の体制のバランスを取り、企業内のリソースを活用

して24時間で立ち上げたところに特徴がある。研究ノウハウを活用しながら、品質、ユーザインターフェー

スなどでは割り切りを行い、技術的完成度よりも早期立ち上げを優先したところは、他の支援サイト等に

も共通する傾向であった。

(15) 炊き出しまっぷ

ご対応者：日本学術振興会特別研究員PD（国際日本文化研究センター）山口欧志氏

サイトの特徴：被災された方々を支援するような情報を地図上にまとめて提供。

■立ち上げの経緯

発災後、ニュースなどを見て、被災地はどういう状況なのか気に

なり、情報を集めていた。Twitterで「炊き出しの情報はないのか」

というつぶやきを見て、炊き出し情報を集めて共有しようと思った。

震災直後の情報は主にTwitterからであり、現地からの情報は少なく、公的機関の情報発信は皆無という

状況であった。

112

サイトのプランは一人で考えた。被災地では情報を受け取れないかもしれないが、選択肢の一つにな

ればという想いから始めた。3月12日、6時間で立ち上げ、公開してから情報提供を呼びかけた。2～3日

経ったところで情報が増えたが、偽の情報も増えた。

■運営体制

情報提供者を登録制にし、運営メンバーもネット上でオープンに呼びかけて募集した。sinsai.infoと連

携をとった。

既存の関係はほとんど無い方々がメンバーとなり、20人で情報収集・運営した。山口氏は運営責任者

という立場で全体のおおまかな役割分担や情報整理を行い、プログラム作成などは主に他の方に依頼し

た。3ヶ月くらいの長期戦を意識し、雰囲気作りを重視した運営を心掛けた。

■運営とコミュニケーション

表示方法はメンバーと話し合い、Google Crisis Responseのメンバーとメーリングリストなどで話し合

って決めた。ほとんどのコミュニケーションはインターネットを利用して行った。電話は活動時間がずれて

いるので適さなかった。

山口氏へのメールなどでフィードバックを受け、メンバーへ個人情報を伏せて転送・共有した。このよう

に、「炊き出しまっぷ」は、メンバーとの連続した共同作業により実現できた。

■情報収集と信憑性の確認

情報収集の際、様々なフォーマットあり、整理が大変だった。登録は標準テーブルを作成し、それにあわ

せて整理・入力するようにした。

情報の信憑性のチェックは、公共機関発のものであること、複数の情報源からの確認ができること、炊

113

き出しの実績があることなどを重視し、自分一人で、手作業でチェックした。ピーク時にはチェック作業に

1日3～4時間程度かけていた。寄せられた情報については発信者の本人確認をしたり、発信者とは違う

名前と電話番号などが含まれたりする場合には、発信者との関係などを電話で確認した。トラブルなどは

発生しなかった。

■ニーズを反映した情報内容の変化と技術部品の選択

「炊き出し情報」から始めたが、被災地のニーズを反映して、情報の種類を増やしていった。お風呂、コイ

ンランドリー、コンビニ、ガソリンスタンドなど、集めている方々に連絡をとり、マッシュアップしたいとお願い

し、許可を得て情報を利用した。ガソリンスタンドの要望が多かったが、すぐ売り切れになったりしたので、

公式発表に絞った。

情報を見やすく整理する必要性が高かった。マインドマップなどを使い、カテゴリ分けを行った。自分の

専門である考古学の分類、整理、展開・共有のスキルを活用した。

データの種類や量が次第に増え、単純なマップでは対応できず、Google「被災地救援ぽーたるまっぷ」

に移行した。移行後は、多様な支援情報の提供に拡大して展開した。Googleなら情報量の増加に対応可

能とも考えた。

Google Mapsは、サーバーも合わせて無償だったことから選択した。KMLやマッシュアップは、考古

学でGISを使ってきたので、すぐに応用できた。

■今後の教訓や提言

「炊き出しまっぷ」のデータはアーカイブしてあり、独立行政法人防災科学技術研究所へ渡し、役立てて

もらうつもりである。

WebGIS、GIS、位置情報は活用できたと思うが、被災地ではパソコンを使えないので、スキルがある人

が被災地に入って活動するのがよいのではないか。月並みだが、日頃からどんなことにでも興味をもつこ

114

とや、ネット上での良好な人間関係を維持することが大事だと考える。考古学に携わる者としては、震災で

破壊された遺跡などの復旧にも力を入れて行きたい。

まとめ：考古学の知識・技術を活用し、6時間で立ち上げ

ITエンジニアでないが、考古学の研究で身に付けたGISなどの専門知識・技術を活かすことで、支援

サイトを 6時間で立ち上げられたことは、注目に値する。また、チームづくり、情報の収集整理などにも気

を配り、情報の信憑性チェックに一日4時間もかけるなど、労を惜しまない献身的なボランティア活動の

姿が浮き彫りにされている。

115

(16) OLIVE 災害wiki データベース。

ご対応者：OLIVE PROJECT 長谷川香織氏

サイトの特徴：もしもの時に、身近な素材から生きるためのものがつくれる知恵が世界中から集まった。

発災後40時間でサービス開始、Google Sitesを利用。IDとパスワードを公開し、様々な人が情報の追

加、編集を行った。

■立ち上げの経緯

OLIVEは、デザイン会社が運営する支援サイトで、もしもの

時に身近な素材から生きるためのものがつくれる知恵を世界中

から集めた災害Wikiのデータベース。地震発生から40時間で

開設した。

Twitter に情報を投稿し続けるところから始めたが、Twitter では情報は次々と流れていってしまうため、

集めていつでも検索できる場所が必要になり、Wikiサイトの立ち上げに至った。

■運営の特徴

誰でも容易に参加できる方法として、WikiやGoogle Sitesを選択した。Wiki更新用の ID、パスワード

を広く公開することで、誰でも情報の掲載・アップデートが可能となり、より多くの方々が参加できる場とな

った。

ユーザは、被災地のために何ができるのかを自分で考え、行動する方々であったため、IDとパスワード

の公開でとくに問題は生じなかった。

必要な情報にはタイムラインがあり、緊急性をもった情報（暖をとる、水を確保する）と、避難所での生活

についての情報（パーテーションをつくる、ベッドをつくる）、遊びの情報（子どもの遊び道具をつくる、生産

116

的な話し合いの方法など）と、フェーズは変化する。そのための情報の整理、編集が必要な作業となった。

サイトは多言語（英語、中国語、韓国語）で展開している。OLIVEを運営するデザイン事務所には、当時、

海外のインターン生が加わっていた。英語ができるスタッフがいたこと、海外インターン生の協力、ボラン

ティアの自主的な参加が大きな助けとなった。世界中から情報提供を受けたことに加えて、翻訳ができる

ボランティアが参加し、多言語化が進んだ。

■適切な情報提供のための工夫

立ち上げ時、投稿された情報の信憑性や正確性の確認に苦労したが、基本的には、投稿者が情報を実

際に試し、確認した後にサイトに投稿することをルールとした。当時すべての情報を確認することは、不可

能であったが、印刷して被災地に送るためにピックアップした情報は検証していた。

Google Sitesの利用方法については、映像での説明を制作し、ユーザの ITリテラシーに対してフォロ

ーをすることで、できるだけ誰でも使えるようにした。

被災地ではインターネットにアクセスすることが難しい場合もあることを考慮し、印刷物による情報提供

も行った。インターネットだけだと情報が届かない場所があると思ったため、自主的に被災地に印刷版を

運んだ。

まとめ：デザイン会社がボランティアと運営、早期に立ち上げ、「生活の知恵」を多言語で提供

デザイン会社がインターンやボランティアと共に運営、早期に立ち上げたサイトで、被災者の「生活の

知恵」を提供する点がユニークである。英語、中国語、韓国語と多言語で展開、海外インターンの協力もあ

った。被災地に配慮し、印刷物を制作・配布したことも注目に値する。

117

3.2.4. インタビュー記録：法的・制度的な課題をとくに意識して対応したサイト

災害支援活動は、人命救助をはじめ、一刻を争う緊急事態のなかで始められ、平時とは異なる過酷な状

況のなかでの対応が迫られる。今回の支援サイト等では、通常なら求められる個人情報の保護、セキュリ

ティなどの法的・制度的な課題への対応は、あえて優先度を下げ、緊急性、公共性を重視したという傾向

が強くみられた。

アンケート回答では、数こそ少なかったが、様々な法的・制度的な制約を意識し、それらの課題に対応す

ることが迫られたと回答したサイトがいくつかあった。そこで、それらの課題に具体的にどのように対応し

たのか、あるいは対応が困難だったか、どう判断したのかを中心に、特徴的事実と今後の教訓などを整理

した。

(17) 放射線量取得API

ご対応者：株式会社gotton 代表取締役 綿村一彦氏

サイトの特徴：公的機関（文部科学省原子力防災ネットワーク）が定期的に発表する放射線量データを自

動取得・整形し、APIによって公開・提供。

■立ち上げの経緯

福島原発の爆発の数日後、3 月 20 日に公開したが、「何かしな

ければならない」という気持ちからだった。東北大学出身で、仙台・

東北は思い入れのある土地であった。

被災地に直接ボランティアに行くことも考えたが、仕事で離れに

くく、IT の専門家として、IT でボランティアをするのが一番貢献で

きると思った。仕事でWebのグラフ表示の経験があったため、放射線量取得・提供のアイディアはすぐ浮

かんだ。まだどこも出していないと思った。

118

※注） 右図は同APIを活用して開発されたソフトウェアFirefoxアドオンの紹介のスクリーンショットであ

る。

■情報源の提供に徹した

一般利用者への直接提供ではなく、API を公開して、他のサイトが必要な情報を提供するためのソース

を提供することに徹した。このサービスを作った理由として、フロントを作る人（ユーザに対して Web サー

ビスを行う人）がスクレイピング（Webサイトのデータの必要な部分だけを抽出して利用すること）をしなく

て良いというメリットがあると考えたからである。また、その人達は、善意の第三者となり、公的な責任を問

われることがなくなり、問われるとしたら自分が問われることで、情報源の入手に関する敷居も低くできる

と思った

■利用者や技術コミュニティとの関係

利用者は、まったく知らない人がブログ経由で来てくれたのがほとんどだった。Twitter 経由でタグな

どを探してたどり着いたものと思われる。また、当時 Twitter でたくさんつぶやいていた方にサイトに関す

る情報を送り、リツイートしてくれたため注目があがった。また、Twitter 経由で知り合った方が運営してい

る radiation311という専門家グループに入れてもらい、その中で議論をしていった。

119

■法的・制度的懸念

始めるにあたって、エンジニアが偽計業務妨害罪で逮捕された「リブラハック事件」2 が念頭にあり、情

報源側のサーバーに過度の負荷をかけて同罪に問われることへの懸念があった。そこでサーバーへのア

クセス回数を調整し、負荷をかけないようにした。

著作権に関しても、データ 2次利用の許諾を取らないことへの心配があった。自分の責任でデータを取

得・整形して公開すれば、その情報を利用する多くの人々は「善意の第三者」として公的責任は問われな

くなり、情報入手に関する敷居を低くできると思った。無断で行っていたが、指摘は来ないと思っていた。

悪者扱いはされないだろうとの意識があった。ただし、次に同様のことをする場合は、了解を得るようにし

たい。行政が「オープンデータ」を実施するのがベストだ。

まとめ：センシティブな放射能情報の情報源を提供、「偽計業務妨害罪」や 2次利用問題も意識

放射能情報というセンシティブな情報の情報源を提供、「偽計業務妨害罪」も意識し、アクセス回数を

調整した。著作権の2次利用について、許諾をとらないことを懸念したが、自分がリスクをとれば、利用者

は「善意の第三者」になると、社会性について明確に意識していたことが注目される。

(18) 日本Androidの会payforwardingプロジェクト

ご対応者： SW Designs 茶圓亮氏

サイトの特徴：避難所の検索、災害情報の閲覧、ボランティア情報の閲覧、SOS情報の発信など、9点の

Androidアプリを提供。避難所情報を行政ホームページから取得・発信。著作権法上の２次利用の制約

2 2009年9月、愛知県岡崎市中央図書館がweb上で公開している新着図書検索システムに、あるプログラマが自動アクセスソフトを実行したところ、webサーバーへのDoS攻撃を行い、ダウンさせたとして、「偽計業務妨害罪」で警察に逮捕された事件。22日間拘留後、不起訴処分となった。原因は図書館側のシステム管理の不備だとの指摘も強くある。

120

を意識。

■立ち上げの経緯

震災直後、日本Androidの会の丸山会長の呼びかけがきっかけとなり、「今、我々にできることをやろう。

災害時に役に立つアプリを作ろう」と立ち上げた活動。震災情報集約サイト「sinsai.info」のAndroidクラ

イアントアプリが最初に開発したアプリだった。

3月25日、マッシュアップについてのオフライン・ミーティング。2週間以内を目標としてアプリ開発にと

りかかり、4月上旬にリリースした。

■技術者の呼びかけ、開発、仕様変更

技術者は、当初はメーリングリスト、その後は知り合いに

声を掛けるなどして募った。もっとも人手を要したのは避難

所の情報集めで、人海戦術で行った。

運用は各個人に任されていた。1週間毎にマッシュアップミーティング（計3回）があり、最初のミーティ

ングにはマイクロソフトやAmazonも参加し、その中でアイディアを深めていった。

Andoroidのアプリは複数の人物で作るよりも 1人で作る方が早いという性質があり、まずは、プロジ

ェクトに参加された人が自分のアイディアをもとに、それぞれアプリを開発した。新しい支援者によって、リ

リース後に新機能が追加されることもあった。

ニーズに合わせた仕様変更として、オープンソースのushahidiをベースにローカライズし、sinsai.info

に合わせるように開発したsinsai.infoアプリで、APIのバージョンに不具合があり、それを修正した。また、

データに位置情報が含まれていない想定外のバグが発生したが、Androidアプリ側で修正した。

■運営の費用負担

121

サーバーは個人負担で、当初はAmazon EC2（月額2.7万円）を利用していたが、コストの負担が大き

いため途中からさくらインターネットのVPN（月額1万円）に移行した。SSLは年間2千円で、2012年は

茶圓氏が負担した。2011年はAmazon EC2、さくらインターネットの利用料を負担した別の方が合わせ

て負担した。

Amazonの無料で利用できる範囲内で利用するつもりだったが、費用がかかってしまった。

■行政の発信情報の 2次利用

避難所情報を提供しようとして、行政がもつ避難所情報を収集した。地方自治体がホームページで公開

している避難所情報は、データ形式が統一されてなく、整理作業が必要だった。内閣府の有事の避難所情

報はPDF形式で、プログラムを書いて、情報を取り出した。

とくに著作権法上の制約に苦労した。自治体の避難所情報の 2次利用については、記載なし、許諾条

件提示、禁止など、記載内容がまちまちである。国のホームページには、要許可または禁止の記載がある。

どう対処するか、データを収集する個人のモラルに任すと、協力者に迷惑がかかるとの意見があった。社

会問題化させて 2次利用を可能にしようとの意見もあったが、最終的には個人の判断に任された。結局、

茶圓氏自身が個人としてリスクをとることで、2次利用を強行した。ただし、全データを網羅できず、データ

は正確ではないとの注意書きを添えた。2次利用が広く認められれば、メンバーに負担をかけずに、情報

取得作業を分担できたはずであった。

まとめ：Androidアプリを提供。避難所一覧情報で、政府・自治体の 2次利用制限に直面

災害対応の Android アプリを 9 点開発したが、避難所一覧情報では、政府・自治体の公開情報の 2

次利用の許諾条件の不統一に直面した。自分がリスクをとることで、一般の利用者が安心して利用できる

ようにと意識。緊急時の法的制限の緩和措置の必要性をあらためて喚起する例といえる。

122

3.2.5. インタビュー結果・サマリー

以下は、インタビューの結果得られた内容を、サイト名、対応者、実施日、サイトの概要、そしてインタビ

ューから得られた特徴的な事実や知見を抽出し、一覧表に整理したものである。特徴的な事象については、

複数のサイトから得られたものも多かったが、ここでは重複を避け、代表的な例のみを示すようにした。

表 3-1 インタビューしたサイトの概要と経験した特徴的な事象

サイト名/対応者 サイトの概要 運営・技術面での特徴的な事象

1. 震災前から活動していた団体によるサイト

JustGiving Japan 一般社団法人ジャスト・ギビング・ジャパン 代表理事 佐藤大吾氏

英国JustGivingの日本版。ファンド

レイジング（寄付を集める）ことができる日本唯一のサービス。

・ 日本の NPO 活動を支える「寄付の社会インフラ」が必

要と考え、震災以前から寄付サイトを開始、発災即日「支援特別ページ」を立ち上げた。

・ アクセス急増でサーバーがクラッシュ、Amazon側から

の支援申入れにより、AWSを利用して解決。

東日本大震災支援全国ネットワーク（JCN） 事務局 岡坂健氏

支援者向け情報提供。 JCN 参加団体760団体超、ボラバス情報、ガイドライン提供情報等が

支援者に活用される。

・ 3月14日に呼びかけ、3月30日、141団体で設立。 ・ 震災前からあった訓練用ドメインとサーバーを活用、後に独自ドメイン／サーバーに移行。

・ 運用体制：PM 役がいてスムーズ。DB、ML サーバー、MySQL等のエンジニアの人材確保が困難。

2. 被災地に拠点をもつ団体によるサイト

被災者をNPOとつないで支える合同プロジェクト（つなプロ）

マッチング班 星野美佳氏 河野良雄氏

宮城県内の避難所実態把握のため

のアセスメント巡回を実施し、収集分析した情報を発信し、ニーズ情報を連携NPOと共有。

・ 3月14日活動開始、17日宮城に技術者を含む先遣隊

派遣。 ・ ボランティアによる避難所アセスメント作業を支える情報システムを自力で開発開始、すぐ富士通が全面支援

を申し出、共同開発に。 ・ 地理的分業体制を実現：避難所でニーズ調査、結果をシートに記入。夜間に仙台で入力、1 週間毎に東京で集

計・分析。

ネトボラ宮城 代表 佐藤大氏

被災地での情報収集／発信の支

援。 避難所や各種拠点にインターネット環境を整備。

・ ボランティアなので、役割分担は指示ではなく、全て立

候補制で進めた。コアメンバーの負担は大きかった。 ・ 被災地外の遠方からの支援を意図したプラットフォームにして、関心の低い地域の人々にも関心を持たせるきっ

かけを作り、サイト運営やツイートを遠隔地の支援メンバーに任せた。

一般社団法人SAVE IWATE

事務局長 加藤昭一氏 金野万里氏

被災者と支援者への情報提供／支援金・支援物資・ボランティアの募集／活動報告。

・ 被災地隣接地域の団体。3月12日に宮古に入り、13日Webサイト運用開始。支援チーム6人で活動。

・ サイト構築に詳しい技術者と、通電が早かったため、12

時間で立ち上げ。被災地と遠隔地をつなぐ役割には、ボランティア団体や市民活動の中からのスタートが寄与。

・ メンバー形成：これまで利用のメーリングリストを活用、

友人、市民活動、NPOの仲間に呼びかけ。 ・ 情報収集：初期は現地で対面による収集、3月 25日頃からメール、メーリングリスト活用。その後、電話帳から

無作為に電話して情報収集。

123

うらと海の子再生プロジェクト 東北デベロッパーズコミュニティ 小泉勝志郎氏

宮城県浦戸諸島の養殖漁業復興支援。

一口オーナー制度を利用し支援金を集めて漁具を購入し、養殖漁業の復興を図る。支援者＝オーナーには

海産物を送る仕組み。

・ 2011年3月下旬に準備開始、4月11日サイト公開。 ・ 被災地では状況が逼迫、プログラミングに集中すること

は困難。経験、費用、更新の容易性などから Google Sitesを選択。既存部品での構成が難しく、結局プログラミング、独自ガジェットを作成。

３. 個人が中心になって運用したサイト

311 HELP.com 株式会社42 代表取締役 田原大生氏

必要物資・支援要求のマッピング、マッチング。

地図上に支援要求を落とすことができる。

・ 知らない人には何ができるかを尋ねるなど、参加者の主体性に任せることで、分散管理を実現した。

・ モチベーションを保つ仕組みとして、自発的に取り組みたいことを募り、分業体制を形成した。

防災情報ストリーム 株式会社コエカタマリン 代表取締役 入江太一氏

災害関連のソーシャルメディア情報のとりまとめ・および水先案内。

Twitter 上の情報とりまとめに特化。被災地内外での情報共有支援において一定の成果。

・ 阪神・淡路大震災を中学生で経験。 ・ 3 月 13 日開設。既存プラットフォームを応用、Twitter

の使い方がわからない人でも、災害関連情報を必要とする人に、新聞感覚で閲覧可能にした。

・ TwitterのAPIの利用制限のため、リアルタイム性は犠

牲にし、集約を優先。

WiFiMap 地震後無線LAN アクセスポイント強度地図作成 keydepth 鍵井清幸氏

災害後に避難所生活となり、通信環

境が失われた場合、草の根で通信環境を探す方法を提供。無線 LAN技術、地図位置座標技術、情報蓄積

共有技術。

・ 茨城で避難生活中に、ネットが繋がらず不便。無線

LAN があればパソコンは使えたとの思いから発想。愛知に移動し、１人で開発、３月21日開設。

・ Google Mapsにマッシュアップ、Webアクセスの統計

情報、データ自動収集、SQL アクセスなどの技術ノウハウを持ち、最初から見通しは立っていた。

緊急地震速報 by Extension 株式会社２２ Inc. 代表取締役 石本光明氏

Google Chrome の拡張機能を使

って緊急地震速報を表示。

・ 緊急地震速報を、Twitter を情報源として取得し、パソコ

ンにプッシュ型で自動配信するソフトを自作し、公開。 ・ WebSocket技術を応用、スピード重視からOSの拡張機能として開発、WebSocket は開発途中で仕様が不

安定で苦労。

炊き出したん

株式会社 Re:Kayo-System 代表取締役社長 寺園聖文氏

Twitterによる炊き出し情報の案内。 ・ 情報の信憑性の確保：誤データ削除ではなく、正確性に関する情報を付加して検索ヒット率を低くする工夫をし

た。データ誤り判断には、現地の声を反映。メールやTwitterで受け、情報を追加。

・ Google MapsやTwitterのAPI制限に対して、情報取

得間隔の設定や複数アカウント利用などの工夫で対応。

・ アクセス数増加、GAE 料金体制が途中変更があり、な

るべく料金がかからないようプログラムを変更して対応。

TwitForYou!

ロケットスタッフ株式会社 高榮郁氏

被災された方に必要な支援を必要な分だけ送ることができる、支援マッ

チングサービス。

・ 支援ニーズ、当初は米や水など物資が中心。後に浴衣など趣向・娯楽系に変化。必要なモノは多様化。

・ きめ細かなニーズをどう吸い上げるかが課題。 ・ 急いで立ち上げ、プライバシーポリシー準備の時間がなかった。女性へのストーカー、警察沙汰に。役所からも

苦情あり、弁護士がいればよかったと思う。

JAWS-UG 災害復興支援 JAWS-UG 竹下康平氏

Amazon Web Services（AWS）の利用促進や情報交換のためのユー

ザグループ。全国26支部、150人。 被災者のためにインターネット上で情報発信をしたい企業・団体・個人

の ITインフラの支援提供。

・ Amazonと連携、必要なサイトにインフラ支援提供。 ・ 50～100組織から依頼。30程度を支援。被災自治体に

はFAXで直接アプローチ。 ・ 技術部品の選択とサポート：先方サイトの元のOSや仕様にあわせて選択。

・ クラウド無償提供企業の多くはハードのみ。自分たちはコミュニティをベースに、技術・労力まで提供。

124

近隣Tweet確認サイト 小松健作氏 (NTT コミュニケーションズ株式会社所属)

近隣の災害・支援情報を共有するツイートの提供。

・ 24時間で立ち上げ。自宅からVPN接続可能な勤務環境も寄与。上司、役員も異例の許可。

・ 時間優先。研究開発で培われたノウハウが奏功。早期開発できるRuby on Railsを選択、ユーザインターフェースの作り込みは行わなかった。

・ 持っているノウハウで可能な範囲に留め、“技術的なチャレンジはしない”と割り切り。

炊き出しまっぷ

日本学術振興会特別研究員PD （国際日本文化研究センター） 山口欧志氏

被災された方々を支援するような情

報を地図上にまとめて提供。

・ 6 時間で立ち上げ。情報は主に Twitter から。現地から

の情報は少なく、公的機関の情報発信はなかった。 ・ 被災地では受け取れないかもしれないが、選択肢の一つになればとの思いから一人で始めた。

・ 情報提供者を登録制にし、運営メンバーもネット上でオープンに呼びかけて募集。既存の関係が無かった人々がメンバーとして参加。

OLIVE PROJECT 長谷川香織氏

発災後40時間でサービス開始した災害wiki データベース。 もしもの時に、身近な素材から生き

るためのものがつくれる知恵が世界中から集まった。

・ Twitter への情報投稿から始めたが、検索機能が必要になり、wikiサイト立ち上げ。

・ wikiやGoogleを選択、更新用 ID、パスワードを広く公

開、誰でも情報の掲載・アップデートが可能、より多くの方々が参加できる場に。

・ ユーザは、被災地のために何ができるのかを自分で考

え、行動する方々であったため、ID とパスワードの公開でとくに問題は生じなかった。

4. 法的・制度的な課題を特に意識して対応したサイト

放射線量取得API 株式会社gotton 代表取締役 綿村一彦氏

放射線量をAPIで取得可能にする。 公的機関からHTML等で公表され

るデータを自動的に取得、整形し、APIによって公開する。

・ エンジニアが偽計業務妨害罪で逮捕された事件を念頭に、情報源側のサーバーに過度の負荷をかけないよう

にした。 ・ 著作権に関して、データ 2次利用の許諾を取らないことへの心配があった。

日本Androidの会 Payforwardingプロジェクト

SW Designs 茶圓亮氏

Android 搭載のスマートフォンから

避難所の検索、災害情報の閲覧、ボランティア情報の閲覧、SOS情報の発信など9つのアプリを開発・提供。

3/25公開。

・ 自治体HP の避難所情報、2 次利用は、記載なし、許諾

条件提示、禁止など方針不統一。国は要許可または禁止。

・ 個人の判断で、茶圓氏がリスクを受容して 2 次利用。広

く認められれば、個人に負担をかけず情報取得作業が可能であったと思う。

125

3.3. 背景調査の整理

これらインタビューによる調査により、アンケート結果への貴重な示唆が得られた。以下に、サ

イトのライフサイクルごとに、得られた示唆を整理する。

3.3.1. 早期の立ち上げを可能にした諸要因

災害発生直後の立ち上げ期には、可及的速かに、限られたリソース（人的・経済的）の中で、最善を尽く

さなければならない状況が強く存在していた。インタビュー結果からは、サイトの目的・種別・運用主体、具

体的な構築・運用方法、関与するメンバー同士のコミュニケーションのあり方、スキルの違いなどの面で、

特徴的な事象がみられた。

◆震災前からの備えが効果的だった

・ 震災前から備えがあった組織は、早期の立ち上げを効果的に行うことができた。ただし、備えがなか

った組織や個人でも、高いモチベーションをもち、支援目的・内容を明確に設定し、自分たちのもつス

キルや経験を応用し、技術部品を的確に選択した多くのサイトが、短期間で立ち上げられた。

◆人的リソースの確保が課題だった

・ 経済的リソースの面で立ち上げ時に苦労したところは、組織の種別や規模にかかわらず少なかった。

個人においては費用のかからないものを選択し、企業においては、既存のリソースを流用した。

・ 人的リソースについては、少人数で集中的に立ち上げたところが多いが、その場合にも、必要な人材

を周囲に呼びかけたり、Twitter やメーリングリストで集めたりするなどの工夫がみられた。個人で立

ち上げたところなどでは、自分が詳しくない分野のエンジニアや知識の不足で苦労した例もみられ

た。

◆技術部品の選択は早期稼働を重視

・ 技術部品の選択で、エンジニアの多くは「使い慣れていること」、「早期に開発や設定が終わること」、

126

「費用や工数の負担が少ないこと」を基準にした。緊急事態のなかで、早期稼働を目指し、迅速性、公

共性、非営利性などを優先し、品質面、法令・制度への対応は通常より割り切った対応をした傾向が

強かった。

◆情報収集の手法と信憑性の確保に工夫がみられた

・ 必要な情報収集の手法としては、直接収集が困難な情報について、いわゆる「デジタル収集」の方

法で、Twitter をはじめ、公的機関が公表しているデータなどをネット経由で収集して整理・発信した

例が目立った。この方法は、震災前からスクレイピング技術などのスキルをもっていたエンジニアな

どによって実装された。

・ その場合、情報源となったサイト側のAPI制限を回避する技術的な工夫が必要となった。

・ 緊迫した状況のなか、必要な情報がなかなか入手できない立ち上げ期には、情報の信憑性について

「割り切り」を行い、被災者支援に役に立つと思われる情報をとにかく集め、検証しないで発信したサ

イトが多かった。

◆メンバー同士のコミュニケーションにはネットを活用

・ メンバー同士のコミュニケーションは、全体では、メールやメーリングリスト、Skype、Twitterなどネッ

ト上のツールを効果的に活用した例が多かった。

・ 自分のスキルについて明確に把握していた人は、迷うことなくタスクを設定し、実装に取り組むことが

できた。他方、貢献したい意識はあっても、明確なスキルをもたない人々は、自ら具体的なタスクを設

定することが難しく、チームのメンバーとして、タスクをもって取り組むことが困難な状況があったと

思われる。

・ 異なる技術分野の人材が必要な場合などで、特定分野のエンジニアが不足したケースもみられた。

・ 異なる専門スキルをもっている人々の間で、「価値観の違い」が摩擦の原因となったが、結果的には

127

かえって多様な展開ができて効果を上げたところもあった。

3.3.2. 立ち上げ期以降、運用期にかけての特徴的な事象

◆サイトの告知：テレビや、TwitterなどのSNSが効果的であった

・ 支援サイト等が広く利用されるために、サイトの存在やサービス内容についての周知・プロモーショ

ン活動が様々に行われた。そのなかでもとくに効果的だったのは、テレビや Twitter での有名人によ

る紹介、リツイートなどだった。その多くは偶然の結果で、運用者自ら仕掛けた例はみられなかった。

・ 十分な告知ができなかったサイトでは、利用が少なかったところもみられた。

◆アクセス集中への対応に追われ、クラウドを有効利用

・ アクセスが事前の想定を大幅に上回って集中し、サーバー増強などの対策に追われたサイトもあっ

た。この点では、Amazonなどのクラウド利用・移行支援が効果的だった。ホスティング事業者から過

度の負荷のためサービスを停止するとの警告を受け、クエリーの回数を減らすなど、仕様変更を余儀

なくされたところもあった。他方、メディアによる紹介で一時的にアクセスが急増しても、時間が経過

すれば収束するとして、とくに対応しなかったサイトもあった。

◆情報の「デジタル収集」が普及、被災地では「アナログ収集」が主

・ 情報源として、Twitter その他、公開情報をネット経由で大量に収集、2 次利用し、発信するサイトが

多く立ち上げられた。「デジタル収集」が有効に機能した。

・ 「情報の空白地帯」となった被災地では、デジタル収集では情報が集まらない厳しい状況が続き、人

手をかけて行う直接訪問や電話取材など、アナログ収集が多用された。

・ 多数の人々が収集したアナログ情報を、システム化してデジタル処理した例もみられた。

128

・ 被災地とそれ以外の後背地の間で、収集した情報の入力、整理・加工などの作業を分業・連携したと

ころもみられた。

・ 情報の信憑性については、運用期に入って検証の工夫を行ったサイトも存在した。

◆ボランティアメンバーによるサイトの運用

・ サイトの運用体制の点で、ボランティアで集まってきた人々は、通常の企業組織などの業務にみられ

るトップダウン型のアサインをすることは難しく、ボトムアップ型、提案型などの工夫がみられた。

◆変化する状況への対応

・ 変化する状況に対し要求仕様が追加されることについて、技術面でとくに苦労したり、特徴的な対応

を行ったりしたところは少なかった。

・ その一方、被災地の状況変化・支援ニーズの変化に応じて、情報収集の対象を避難所から仮設住宅

へと変更させた例など、活動内容の変化が情報内容に反映されたサイトはみられた。

3.3.3. 継続・収束期に特徴的な事象

開始してからの期間が経過するにつれて、目的を達成したとして閉鎖するサイトや、継続したくても資金

や人員などのリソース面での制約に直面し、継続するかどうかの判断に迫られるなど、状況変化への対応

に以下のような特徴的な事象がみられた。

◆継続か閉鎖かの判断

・ 目的達成を判断した根拠として、利用の減少をあげたところが多かった。

・ 資金面の負担を感じても、利用者が存在しているため、閉鎖を選択できないというサイトもあった。

・ 個人など小規模で運用しているサイトでは、人的・資金的なリソース面で、とくに負荷を感じてないの

129

で継続しているというサイトがいくつかあった。情報収集などの運用を自動化しているサイトなどで

の運用負荷はミニマムで、立ち上げコストに比較して、ランニングコストは小さいということが要因と

思われる。

・ 公的価値があるものを、個人の趣味で取り組むことが正しいのか、自分に何らかの事故があって継

続ができなくなる事態を想定して、他の団体に依頼したいとの思いを述べたサイトもあった。

◆目的の変化、利用者の増加も

・ 例外的ではあるが、震災時とは異なる目的での利用者が増えたサイトがあった。企業として、今回の

サイト運用で得られたノウハウを活かし、システムの改善、機能追加などのブラッシュアップを行って、

なんらかの形での商品化を図り、公共的な利用はその中に包摂したいというところもあった。

◆次の災害への備え、アーカイブも

・ 数量は多くなかったが、今回の教訓を活かし、次の災害への備えとして継続していくというサイトもい

くつかあった。東日本から全国規模のものにしたいというサイトもあった。

・ 継続するかどうかとは別に、今回の経験をオープンソースのような団体によりアーカイブし、アップデ

ートをはかるという考えも提示された。

3.3.4. サイトの目的・特性や情報特性による、運用・技術面での特徴的な事象

サイトの目的・特性や扱う情報の特性（内容、規模、最新性、信憑性、継続性など）は異なり、立ち上げ時

にも運営時にも、運用面、技術面での対応すべきリスクや直面した課題、対応方法に以下のような特徴的

な事象がみられた。

◆個人情報への配慮、工夫

130

・ 個人情報保護を扱ったサイトでは、Twitter などの公開情報を自動収集した場合、アカウント情報を

削除したり、個人情報を含むファイルをそのままサイトに登録することを防いだりするなど、運営面で

の対策をとった例がいくつかあった。

・ 物資のマッチングサイトでは、送り主、送り先の住所・氏名・連絡先などの個人情報の表示・利用が必

要で、プライバシー保護に苦労したサイトがみられた。

・ 個人情報保護について、個人が運用するサイトや小規模サイトなどでは、運営面でも技術面でも、あ

えて対策をとらないところがみられた。公共性、非営利性を優先し、時間的な制約から割り切ったとこ

ろも多かった。

◆情報の信憑性確保、2次利用

・ 放射能情報提供では情報の信憑性が重要となるが、その確保のために、情報源を公的機関の発表

データに限定したところがみられた。

・ 情報の新鮮度の確保、更新について、規模が小さく運営メンバーも少人数のところでは、苦労したと

ころも多かった。Twitter での投稿について、コアメンバー3 人のチームで検証したが負荷が多かっ

た例や、古い情報を削除しないまま、新しい情報を追記できるようにして、新鮮度について利用者が

自分で確認できるようにするといった工夫がみられた。

・ 情報の信憑性が重要なサイトで、投稿者の本名やメールアドレスなどをあえて公開する設定とし、サ

イト全体を「フルオープン」にし、利用者側を信頼する方針により結果的に信憑性を担保しようとした

例がみられた。

・ 当初の立ち上げ期には対策が不十分だったが、落ち着いてから、情報源のスクリーニングなど、技術

的対策を施したところがあった。

・ 放射線量や避難所情報など、政府・自治体などの公的機関から情報を収集・利用したサイトでは、著

作権の 2 次利用の許可をとらないことを懸念したところがあった。いずれも責任者一人がリスクをと

131

ることで、他の作業者や利用者のリスク回避を実現しようとした。

3.3.5. 品質やセキュリティに関する課題認識

サイトが直面した品質やセキュリティなどの課題についてインタビューからは、以下の状況が見いださ

れた。

◆緊急性、社会性、公共性を優先する傾向

・ 技術者アンケートでは、品質面で「割り切り」や見切り発車をしたとの回答が目立った（43％）と多か

った。支援サイト等のもつ緊急性、社会性、公共性を意識し、セキュリティを確保する技術手段につい

ては、特別に厳重な対策をとらなくても大丈夫だという傾向は確認できた。

・ メッセージを投稿するアプリの仕様上の制約から、一定の認証サービスソフトを選択したサイトがみ

られた。

◆偽計業務妨害罪を意識した例も

・ API を利用して情報を自動取得したサイトで、情報源となるサイトへのアクセス過多によってトラブル

を起こし、「偽計業務妨害罪」に問われることを懸念し、アクセス頻度の調整をしたところもあった。

132

4. 分析と考察

4.1. 災害発生時からの社会的なニーズの変化と支援サイト等の内容・規模の変遷との関係

性に関する時系列的考察

4.1.1. 災害後の各段階における情報ニーズとの関係

災害においては、具体的な場所や被災状況などにより、被災者が必要とする救援・復旧の社会的なニ

ーズが異なってくる。とくに、時間の経過につれて、被災地・被災者の置かれている状況やニーズは変化し、

それによって、支援のために必要とされる情報も異なってくる。支援サイト等もまた、そうした状況の変化を

反映して活動の内容が変化する。これらの変化を分析する枠組みとしての時系列的視点について、まず

整理を記す。

災害における時系列的枠組み、いわゆる災害フェーズの区分としては、一般に、初動期、応急対応期、

復旧・復興期という区分がなされる。3 それぞれの段階が実際にどの程度の期間となるかは、災害の規模

や被害の程度、復旧の状況などによって異なるが、東日本大震災の場合は、過去に例のない規模での被

害が発生したことで、それぞれの期間が、これまでの災害よりも長くかかるところに大きな特徴がある。

東日本大震災は、地理的に超広域にわたって発生した大規模災害で、被害の種類や程度も、地震、津

波に加えて、原子力発電所事故関連の被害が加わり、具体的な地点の違いによって状況は大きく異なっ

ていた。被災した場所と時間の組合せにより、きわめて多様・複雑な被害が複合的に発生した災害であっ

た。

災害発生直後から救援・復旧活動が開始されたが、交通・電力・通信などの社会インフラ破壊の影響は

大きく、被災地からの被害情報がまったく入らず、救援活動は困難をきわめ、復旧・復興活動にも、これま

での災害と比べても多大な時間が必要である。被災地の厳しい状況は、本レポート発表現在も、なお続い

ている。

3 京大・NTTリジリエンス共同研究グループ著『しなやかな社会への試練』（P43）。

133

こうした状況を受け、被災者の求める社会的ニーズはきわめて多様なものとなり、被災者を支援する活

動も、被害や復旧の状況によって、多種多様な形で展開されてきた。支援サイト等も、当然、こうした状況を

反映して、運営主体、目的や提供される支援内容や規模などに様々な違いがみられた。

134

4.1.2. 東日本大震災における災害状況の時系列的整理

東日本大震災における主な被害の状況、救援・支援、復旧・復興活動を、時系列に沿って整理する。

表 4-1 東日本大震災における災害フェーズ、被害、救援・支援活動の時系列整理

災害フェーズ 初動期 応急対応期 復旧・復興期

経過時間 当日

（3月11日） ～100時間 ～1週間 ～1ヶ月 1～3ヶ月（以上）

主な被害状況

3月11日午後2時46分、地震発生、 建物・インフラに被害発生。 約30分後から沿岸部に津波到達、浸水、建物流失・倒壊、火災などにより、人的被害を含む甚大な被害が発生。

余震、連日多発 4月7日 東北地方大きな余震

人的被害：死者・行方不明者計、約19,000人（1都1道10県）。 家屋：全壊13万436戸、半壊26万3,950戸 道路、鉄道、航空路など交通寸断。 停電、水道、ガス、通信回線停止。食料・水、ガソリンなど生活物資不足。

福島第1原発： 冷却機能停止、炉心溶融

原発1、3、4号機、爆発事故、放射能拡散。

原発周辺地域住民、強制／自主避難

農産・水産物、観光などに汚染・風評被害

首都圏、交通網混乱、帰宅難民発生。携帯輻輳

計画停電（東京電力） 夏季電力不足懸念 節電

救援・支援活動

警察・消防、自衛隊、災害NPOなどによる、救急・救援活動

除染作業

公的機関、NPO団体、ボランティア、企業など、被災者支援活動。 避難所開設・運用、物資配布、義捐金提供。

復旧・復興活動

水道、ガス、電気、通信などライフライン復旧活動 瓦礫撤去

仮設住宅建設・移転 仮店舗・工場再開

道路、鉄道などのインフラ復旧活動 東北自動車道再開（3/24） 仙台空港再開（4/13） 東北新幹線全線開通

（4/29）

135

被災地では、初動期には前述のインフラ被害、情報断絶などの影響により、救急・救援活動が困難で、

その後の復旧・復興活動も長期間かかり、その分被災者の困窮は著しく、様々な情報を必要とした。

情報支援プロボノ・プラットフォーム（iSPP）が2011年7月に実施した「情報行動調査」では、東北三

県（岩手・宮城・福島）の被災者が必要とした情報は、時間を追って以下のように変化したことが明らかに

されている。

・ 地震発生直後には、地震の震度や津波の到達度など災害情報、水道・ガス・電気・電話などのライフライン情報、

家族・知人・同僚などの安否情報、食料などの生活物資の情報、ガソリン・灯油などの情報、道路・鉄道・バスなど

の交通情報が上位を占めていた。

・ 1 週間後には、災害情報、安否情報も依然として高いが、ライフライン、食料、ガソリンなどの生活関連情報が上

位3位を占めた。

・ 1ヶ月後まででも同様で、地震発生後1ヶ月が経過しても、ライフラインの復旧が十分ではなく、生活に必要な物

資が不足し、それらに関連する情報が求められたことが明らかにされていた。

・ 3ヶ月まででは、放射能などの原発事故に関する情報が 1位となり、教育、罹災手続き、義捐金などの資金、求

人・仕事、街づくりなど、生活再建・復興にかかわる情報ニーズの増加がみられた。ただし、この時点でも3割近

くが生活情報を必要としていた。

[出典：情報支援プロボノ・プラットフォーム（iSPP）が 2011年7月に実施した「情報行動調査」]

表 4-2 必要とされた情報[出典：『情報行動調査』情報支援プロボノ・プラットフォーム（iSPP）, 2011年7月実

施]

発生から 数時間

1週間まで 1ヶ月まで ３ヶ月まで

震度などの地震の情報 81.2 62.2 40.7 30.3

津波の大きさや到達時期などの津波の情報 49.0 37.1 17.6 10.3

道路、鉄道、バスなどの交通情報 60.8 67.2 58.2 40.5

建物などの被害情報 43.8 43.2 31.8 20.4

家族、知人、同僚などの安否情報 69.0 61.4 33.5 13.6

救出や捜索活動の情報 18.8 26.7 24.0 14.8

避難所などの避難に関する情報 28.7 31.5 21.0 13.4

水道・ガス・電気・電話などのインフラ情報 81.1 84.5 64.1 30.9

食料・生活物資の情報 64.8 80.0 67.0 31.6

ガソリン・灯油などの情報 64.7 82.4 74.4 34.1

病院などの医療に関する情報 26.9 31.0 26.2 16.0

放射能などの原発に関する情報 33.8 42.2 45.7 48.7

仮設住宅などの住宅に関する情報 3.3 5.1 7.6

学校などの教育に関する情報 19.1 20.4 15.8

り災証明などの行政手続きに関する情報 7.6 11.9 20.1

義捐金や保険金、貸付金などの資金に関する情報 6.5 9.3 13.5

求人などの仕事に関する情報 3.7 5.1 7.9

街づくりなどの復興に関する情報 5.3 8.0 14.0

その他 0.8 1.0 1.2 1.4

とくになかった 0.6 0.8 4.0 14.9

全体 100.0 100.0 100.0 100.0

136

（％、ｎ＝２８１５）

137

ここで、あらためて、被災者の情報ニーズ、情報行動の変化を、前記被害状況および救援活動の時系列

段階と対応させて整理したものが、次表である。これをみると、被災者の情報ニーズ、情報行動の変化が、

刻一刻と変化する被害状況や救援・支援活動、復旧状況に対応しなければならなかったことを反映してい

ることがわかる。

表 4-3 東日本大震災における被害、救援・支援活動の状況と情報ニーズ、情報行動の時系列整理

災害フェーズ 初動期 応急対応期 復旧・復興期

経過時間 当日

（3月11日） ～100時間 ～1週間 ～1ヶ月 1～3ヶ月～

主な被害状況

3月11日午後2時46分、地震発生、

建物・インフラに被害発生。

約30分後から沿岸部に津波到達、浸水、建物流失・

倒壊、火災などにより、人的被害を含む甚大な被害が

発生。

余震、連日多発 4月7日

東北地方大きな余震

人的被害：死者・行方不明者計、約19,000人（1都1道10県）。

家屋：全壊13万436戸、半壊26万3,950戸

道路、鉄道、航空路など交通寸断。

停電、水道、ガス、通信回線停止。食料・水、ガソリンなど生活物資不足。

福島第1原発：

冷却機能停止、炉心溶

融

原発1、3、4号機、爆発事故、放射能拡散。

原発周辺地域住民、強制／自主避難

農産・水産物、観光などに汚染・風評被害

首都圏、交通網混乱、

帰宅難民発生。携帯輻

輳

計画停電（東京電力） 夏季電力不足懸念

節電

救援・支援活動

警察・消防、自衛隊、災害NPOなどによる、救急・救援活動 除染作業

公的機関、NPO団体、ボランティア、企業など、被災者支援活動。

避難所開設・運用、物資配布、義捐金提供。

復旧・復興活動

水道、ガス、電気、通信などライフライン復旧活動

瓦礫撤去

仮設住宅建設・移転

仮店舗・工場再開

道路、鉄道などのインフラ復旧活動

東北自動車道再開（3/24） 仙台空港再開（4/13） 東北新幹線全線開通（4/29）

被災者の

情報ニーズ

地震・津波の被害状

況、

安否情報

ライフライン・生活関連

情報

ライフライン・生活情報

被害状況、安否情報

ライフライン・生活情報

被害状況、安否情報

放射能・原発情報

ライフライン・生活情報

罹災証明、義捐金など

の情報

放射能・原発情報

仮設住宅、教育・求等

復旧情報

ライフライン・生活情報

被災地の情報行動

津波被災状況、外部に

発信不可能。

被災地内部は「情報の

空白地帯」。

わずかにラジオが聞け

た。

テレビの津波映像をはじ

めとするニュース、新聞な

どで徐々に報道。

口コミも多い

固定電話、携帯電話など、順次復旧。

テレビ、新聞、雑誌など、多様なメディアでの受発信・利用。

SNS、ブログなど、ネットメディア、各種サイトによる受発信・利用

被災地外の情報行動

Twitter、mixiなどネットメディアによる情報交換が被

災地外でさかんに行われる

さまざまなテーマ別のウェブサイトが本格的に稼働し、被災地との連携、物資

や人的支援を含む広範囲な情報ニーズに対応する活動が活発になる

138

139

4.1.3. サイトの目的・内容と公開日

サイトの目的や内容とサイトの立ち上げ日との間には、前述の災害フェーズ、すなわち被害状況とそれ

に対応した支援ニーズ、情報ニーズを反映する論理的な関係がみられた。以下の図のとおり、サイトの目

的・内容と公開日の関係をみると、発災直後は緊急性の高い内容の情報やサービスを提供する支援サイ

ト等が多く立ち上がった。その後、時間の経過とともに明らかになってくる被災地の状況・ニーズを反映す

る内容の支援サイト等が立ち上がっていった。

具体的には、発災直後から72時間までに立ち上げられた支援サイト等では、災害そのものについての

情報サイトがもっとも多く、活動支援、生活情報、寄付・チャリティ、IT支援、物資支援と続いた。停電情報と

文化的支援も、それぞれ2件登場している。

72時間から 1週間までは、もっとも多くの支援サイト等が立ち上った。全体の傾向は72時間までと同

様だが、放射能情報提供サイトが、住宅支援、交通情報とともに登場した。

2週間までになると、新たに立ち上げられた支援サイト等の数が半減し、災害情報は残るものの、活動

支援、生活情報は減る一方で、住宅支援、放射能情報が引き続き登場している。3週間でもこの傾向は変

わらない。4週間以降になると、支援サイト等の数そのものが大きく減り、特定の傾向を認めることは難しく

なる。

１４週目以降において、直接的な支援を行うサイトが発足する傾向からは、ウェブサイトを活用した支援

において、迅速性のあるサイト同様、継続して支援にあたる取組みの必要とされていることも窺える。

140

図 4-1 サイトの内容と公開日（ｎ＝263）

3

11

12

8

3

1

1

1

2

10

12

4

5

3

1

2

1

7

9

3

4

1

2

1

1

2

7

3

3

1

1

2

2

1

3

1

1

2

7

2

2

1

4

5

1

1

1

2

3

1

1

1

3

1

1

3

2

1

3

1

1

1

1

3

7

6

1

1

1

1

3

3

3

1

1

2

3

1

1

1

1

1

1

1

1

2

1

1

2

1

1

1

2

2

1

1

1

1

1

1

1

1

1

1

1

1

2

1

2

1

1

0 10 20 30 40 50 60 70 80

大震災以前

72時間以内

1週間以内

2週間以内

3週間以内

4週間以内

5週間以内

6週間以内

7週間以内

8週間以内

9週間以内

10週間以内

11週間以内

12週間以内

13週間以内

14週間以内

14週間超

災害情報 活動支援 生活情報 寄付・チャリティ 住宅支援 IT支援 文化支援 被災者支援 物資支援 放射能情報

停電 復旧復興支援 ボランティア支援 交通情報 医療福祉情報 海外発信 教育支援 通信環境情報 ボランティア情報 福祉支援

141

4.1.4. サイトの目的・内容と運営団体の種別

サイトの目的・内容別の分類は、大きく広い意味での「情報提供」、被災者への「直接支援」、そして

NPOなどの支援団体、支援者の活動を対象にした「中間支援」を目的にしたものに分けられる。

◆情報提供は個人、企業が多く、直接支援は社団・財団法人・企業が、中間支援はNPOが多かった。

サイトの目的と運営団体の種別との関係についてクロス集計により分析したところ、情報提供を目的と

するサイトの運営団体の比率は、個人、コミュニティ、企業の順で多く、直接支援は企業、NPO、個人の順

となり、中間支援はNPO、教育機関が多い傾向を示した。

これは、個人やコミュニティが運営するサイトは、相対的には外部に働きかけなくてもサイトが立ち上げ

られる情報提供型の活動が多かったのに対して、企業やNPO、社団・財団法人が運営するサイトは、支援

サイト等を手段として直接ないし間接的な支援活動の推進を目的とする傾向があったからと考えられる。

図 4-2 サイトの目的と運営団体の種別（ｎ＝111）

（グラフは構成比、値は件数）

13

9

12

5

1

2

0

2

44

7

5

13

8

4

3

1

5

46

0

2

1

11

0

1

2

4

21

個 人

コミュニティ

企 業

NPO

社団法人

財団法人

教育機関

その他

全体

情報提供 直接支援 中間支援

142

表 4-4 サイトの目的と運営団体の種別（ｎ＝111）

項目 情報提供 直接支援 中間支援 合計

個 人 13 7 0 20

コミュニティ 9 5 2 16

企 業 12 13 1 26

NPO 5 8 11 24

社団法人 1 4 0 5

財団法人 2 3 1 6

教育機関 0 1 2 3

その他 2 5 4 11

全 体 44 46 21 111

4.2. 支援サイト等のライフサイクルと課題

支援サイト等のライフサイクルについては、調査対象から得られた情報を鑑みても、以下のように、初期

＝準備・立ち上げ期（以下、「立ち上げ期」）、中期＝運用期、後期＝継続・収束期の３つのフェーズに区分

できる。支援サイト等の活動の内容や形態は、被害者を中心とする社会的ニーズの影響を受けており、そ

の意味で、災害サイクルの影響を受ける。なお、サイトの立ち上げ時期は震災の発災直後とは限らないた

め、サイトのライフサイクル自体は、災害サイクルと必ずしも一致しない。

そこで、以下の４．３節から４．５節において、それぞれの段階の課題に関し、また４．６節に共通した技術課

題について浮き彫りとなった特徴的な事柄を整理する。

表 4-5 支援サイト等のライフサイクルと共通課題

フェーズ 初期

準備・立ち上げ期

中期

運用期

後期

継続・収束期

サイトの状況 支援サイト等の開始を決意し、各

種の準備を行い、公開・運用に至

るまでの期間

サイトを公開し、安定的に運用できるよ

うになってからの期間

状況の変化により、サイトの支

援目的・内容・機能の変更、閉

鎖検討、実際に閉鎖するまでの

期間

共通課題 サイトの運用者の動機の明確化、

状況変化への柔軟な対応、人員

体制の確保、技術資源の確保。

（４．３節）

情報の収集、情報源の信頼性確保

サイトの告知・プロモーション、アクセス

急増対策、変化する状況への対応、資

金の確保、使いやすさの実現、他の団

体との連携。

（４．４節）

目的や内容、体制の変更、継続

するか閉鎖するかの判断、活動

の総括・教訓の抽出など。（４．５

節）

143

4.3. 迅速なサイト立ち上げの促進要因・阻害要因

災害発生の初期には、可能な限り速く、しかも限られたリソース（人的・経済的）の中で最善を尽くさなけ

ればならないという社会的状況が強く存在し、これに対してサイトの種別や構築・運用方法、関与するメン

バー同士のコミュニケーションのあり方、スキルの違いなどにより、特徴的な現象が生じていた。また、アン

ケート結果が明らかにしたように、多くのサイトが震災発生後の短期間に立ち上げられた。

ここではそれを可能とした促進要因および阻害要因について分析し、その意義についての考察を行う。

4.3.1. 震災前からの備えの効果

東日本大震災は、日本社会全体としては、時期、規模ともに「想定外」のもので、この事態を予測してい

た主体は、ほとんど存在していなかった。しかし、きわめて少数ではあるが、災害への備えをミッションとし

ている団体のなかには、災害が発生すると同時に救援・支援活動を開始した団体も存在していた。当然の

ことだが、彼らのこれまでの活動経験とそれによる知見に基づいた備えがあったことが、発災直後の迅速

なサイトの立ち上げに結びつき、効果的な支援活動の展開に寄与したと考えられる。

防災分野全般では、たとえば医療関係者によるDMATや、阪神・淡路大震災の教訓から設立されたレ

スキュー・ストックヤードなどは、災害専門に備えをもった団体であり、東日本大震災の発災後、あらかじめ

用意していた装備・資材をもって、被災地にいち早く駆けつけ、救援活動を展開した。

これらの団体と同様に、災害時にも、とくに ITを活用して災害支援を行うことをあらかじめ想定し、準備

していた団体は、当然立ち上げが早かった。インタビューしたジャスト・ギビング・ジャパンと、東日本大震

災支援全国ネットワーク（JCN）に見られるように、阪神・淡路大震災やそれ以降の様々な災害への支援活

動の経験をもち、情報提供の重要性や、ITを活用することでNPO団体を支える資金確保が可能となるこ

技術選択と課題 技術要素と品質、安全の確保

個人情報、プライバシーなどへの配慮、セキュリティへの配慮、制度、法律などへの対応

（４．６節）

144

とについての理解を持っていたため、いちはやくサイトを立ち上げることができ、大きな成果をあげたとい

える。

個人でも、支援サイト等の立ち上げの背景として、阪神・淡路大震災など、これまでの被災経験に触れ

た例がいくつかみられた。そうした経験から生まれた問題意識が、今回の立ち上げの際の動機や迅速な

意志決定などに結び付いたものと考えられる。

災害に対して事前に十分な備えをもち、インターネットサイト構築などの情報支援のスキルを積み重ね、

ノウハウや人的ネットワークを維持・継承しておくことの重要性があらためて確認できる。

4.3.2. 運営母体の特性と立ち上げに要した時間の関連

アンケート調査からは、支援サイト等の立ち上げがきわめて早期に集中したことが明らかになっている。

つまり、過去に被災経験がない人々、備えもなかった団体や個人でも、支援サイト等を迅速に開始できた例

が多くあった。こうした人々の共通点は強い意志、目的意識、明確な動機が存在した。

早期に立ち上げた支援サイト等について、組織の種別をみると、企業、NPOなど組織的な母体が明確

に存在していたところが迅速なサイトの立ち上げに寄与した例が多いが、個人ないし小規模な企業や団

体でも、素早く立ち上げられたところは少なくなかった。

6時間以内から 24時間以内までに立ち上げたサイトでは、4人以内の比率が70％以上であったのに

対して、1ヶ月間要したサイトでは、10－14人が38.5%ともっとも多く、比較的大人数で取り組んだ傾向が

みられた。

次の図は、サイト運用の体制、人数と立ち上げに要した時間についての関係をクロス集計したものであ

る。

145

図 4-3 サイトの規模と立ち上げに要した時間の関係（ｎ＝112）

4.3.3. 人的体制・技術者の確保

立ち上げ時の人的リソースの確保は、特に大きな課題であった。運営者アンケートへの回答では、立ち

上げの際に苦労した点として、「状況の変化への柔軟な対応」に次いで、「リソース確保」があげられた。よ

り詳細に、自由回答を調べると、「人的リソース」、「技術者の確保」、「作業時間の確保」、「ボランティアで

あるため、人的リソースの計画的確保は不可能」、「協力者の確保」などの記述があった。

以下は、立ち上げまでに要した時間と人を集めた方法の関連性についてクロス集計した結果である。

6時間以内に立ちあげた支援サイト等では、「インターネットで広く呼びかけ」という人材確保手段は、「知

人や仲間に個別に呼びかけ」と同率であるが、「企業・団体での呼びかけ」や「コミュニティでの呼びかけ」

と比べてそれほど差がない。Twitterは、人材集めよりは、サイトそのものの利用の周知、拡散、技術的ノウ

ハウが不明なときなどに見知らぬ人から解決が得られるなど、知的資源を調達するために効果的だったと

思われる。

運営者向け Q5t1サイト立ち上げ時のメンバー数とQ4立ち上げに要した時間

50.0

30.8

58.3

71.4

61.1

80.0

80.0

76.2

28.6

15.4

25.0

21.4

22.2

13.3

20.0

9.5

14.3

38.5

5.6

9.5

7.1

7.7 7.7

8.3

5.6

6.7

8.3

7.1

5.6

4.8

0 10 20 30 40 50 60 70 80 90 100

その他

1ヶ月間

2週間

1週間

3日間

24時間

12時間

6時間以内

0～4 5～9 10～14 15～19 20～24 25～29 30以上

146

図 4-4 立ち上げまでに要した時間と、人を集めた方法（n=110、％）

4.3.4. ボランティアの有効活用の課題

運営者アンケートの「立ち上げの際に苦労した点」および「サイト運営で直面した課題」についての以下

のコメントからは、切迫した状況、限られたリソースのなかで、ボランティアメンバーでのプロジェクトを進

めることに苦労したサイトが多かったことが確認できる。

サイトによって目的、扱う情報分野、サービス内容などが異なり、また実際に集まった技術人材の得意分

野も個別に異なっていたため、支援サイト等全体として、具体的に特定分野の技術スキルが不足していた

という傾向を抽出することは難しい。それよりも、限られた時間とリソースのなかで、支援サイト等を効果的

に立ち上げるためには、まずは、一人で様々な技術に精通し、プロジェクトマネジメントもできる人材が必

要だったといえる。

他者とのコミュニケーション能力をもっていること、他者との協調ができることの重要性も浮き彫りとな

った。つまり、個々人の自発性やスキルに依存するだけでなく、集合的な取り組みをはかることである。多く

の支援サイト等が、人材を集める段階ではTwitter などの SNSを用いたと述べているが、実際の貢献と

いう結果の視点で深掘りすると、すでに構築されていた人間関係、コミュニティを通して、必要な人材が集

まる例が目立った。

30.8

25.0

16.7

13.3

0.0

42.9

46.2

50.0

64.3

33.3

26.7

20.0

52.4

38.5

50.0

35.7

38.9

26.7

40.0

16.7

13.3

0.0

7.1

47.6

38.5

7.1

22.2

47.6

0.0 10.0 20.0 30.0 40.0 50.0 60.0 70.0

1ヶ月間

2週間

1週間

3日間

24時間

12時間

6時間以内

インターネットで広く呼びかけ

知人や仲間に個別に呼びかけ

企業・団体内での呼びかけ

コミュニティでの呼びかけ

147

IT人材については、自発的に集まってくる人々をどうマネジメントするかという課題がある。多くの支援

サイト等では、自発的に協力を申し出る人々が集まり、それまでまったく知らなかった人々が協働で作業し、

専門分野の異なるメンバーが分業を行うなど、通常の組織における業務体制とは異なる形態で作業が進

められた。また、実際に集まることは少なく、オンラインでの打合せなどが主だったサイトも多い。

アンケート結果から、チームメンバー同士のコミュニケーションに、インターネットによる各種のツールが

効果的に活用されていたことがわかっている。支援サイト等の関係者は、インターネットのツールを活用し

て、メンバー同士のコミュニケーションを推進することで、限られた条件のもとでのプロジェクトの効果的

な遂行が可能になったといえる。

「手伝いたい。何をすればよいですか」とノーアイデアで集まってこられる人材を活用するため、常にプ

ロジェクトのイシューリストを整備するなどの運営者側の組織的整備をしておくことや、支援者に「何がで

きるか」を問いかけ、具体的な提案の内容を判断して依頼事項を決定するなどの方法がある。

4.3.5. オンライン・コミュニケーションツールの活用

インターネット上での各種コミュニケーションツールの利用は、迅速なプロジェクト推進の促進要因だっ

たといえる。たとえば、技術者アンケートの結果では、メンバー同士のコミュニケーションツールとして利用

されたものとして、Skypeとメーリングリストが同数で 30％、Facebook（22％）、Dropbox（20％）、

Googleドキュメント（15％）、サイボウズLive（12％）などがあげられた。Skypeやシスコ社が震災支援用

に無償提供するWebExなど、複数名がオンラインで簡便にテレビ会議ができるサービスは、地理的には

分散した開発チームを結んでメンバー同士のコミュニケーションを促進する上では、奏功したとみられる。

Wikiを活用した事例もみられた。

このほか、オープンソースコミュニティで一般的に利用される進行管理ツールである、Google Apps、

Redmine、Gitなどのバグトラッキングやイシュートラッキング、バージョン管理システムを採用した例も、

148

少数だが存在していた。

これらオンライン・コラボレーションツールの利用は、支援サイト等立ち上げなどのように時間的プレッ

シャーが強く、離れた場所同士で、場合によっては全く知らない人間同士が役割分担を行い、刻々と変化

する状況に対応しながら、短期間に成果を上げなければならない作業を進めるのにあたって、全体として

大きな効果を上げたものと考えられる。

149

4.4. 運用フェーズにおける課題と対応

支援サイト等のライフサイクル全体を通して、被災地の状況、支援を受ける側の状況が変化し、それが

要因となって、サイト運営者の直面する運用上、技術上の課題も変化し、それらへの対応・解決が求めら

れた。以下、とくに運用期に特徴的な技術面の課題について述べる。

(1) 情報の確保と収集方法

(2) 情報の信憑性や鮮度の問題

(3) アクセス急増による処理能力不足への対応

4.4.1. 情報の確保と継続的な収集方法

今回の震災は、災害規模がきわめて広域で、かつ多様であっただけに、必要とされる情報の種類も、多

様なものが求められた。制約の大きな状況のなかで、これらの情報の収集や整理、発信には多大な困難

があったことは明らかである。そのなかで、さまざまな IT手段を駆使することで、大量の情報の素早い取

得や整理、発信などをきわめて効率的、効果的に行えた事例が多数みられた。これは、これまでの災害時

にはみられない、今回はじめて出現した特徴的な事象といえる。

運営者アンケートの調査結果からは、情報収集の方法として、WebサイトやSNSを情報源とし、ITを活

用した“デジタル収集”と、直接現地を訪問したり、電話その他で現地からの情報を収集したりする“アナ

ログ収集”のパターンに分けられるが、この“デジタル収集”こそが、今回の特徴的事象である。

アンケートでも、情報収集の方法としても「WebサイトやSNSなどを通じて」が62％、「公的機関や企業

の配信情報を利用」が31％と、デジタル収集が多用されたことが明らかにされた。「Web2.0」が主流とな

った現在のWebサイトでは、自分のサイトにあるデータ構造やアプリケーションのインターフェース仕様

を公開し、データの自動収集など、Web機能の外部利用を許し、マッシュアップを可能にすることが一般

化しており、今回の支援サイト等でもそうした例は数多くみられた。自らが提供するデータについて、API

を公開して他の支援サイト等からも利用できるようにしたサイトも存在した。

150

情報源のなかには、政府機関、自治体、電力会社などの公的機関が発表するものを利用した支援サイト

等も多かった。情報源との関係では、API利用制限、データ2次利用における著作権処理などについて明

確なルールがなく、個々のサイトが独自に判断を迫られる状況があった。そのような場合に、Twitterなど

から一般の投稿を公式アカウントや、ハッシュタグ検索によって収集する事例は多くあり、公的機関などか

ら公に活用の許可を得にくい情報の取得手段として、いわば情報流通のロンダリング手段として Twitter

が用いられたとの見方もできる。

この点については、運営者、技術者の両方のアンケートにおいて、「教訓、提言、その他関係方面に臨む

こと」で、「政府／自治体による活用しやすい形式での情報公開（オープンデータ）」が、全回答者の 47％

と第一位となり、第二位に、「情報を効率的に収集・共有できるシステム・ノウハウの充実」が34％で続いた

ことから、今後の課題も明確にされた。すなわち、今後、災害時に広く必要となる公的価値をもったデータ

について、政府・自治体が提供するものも、民間企業が提供するものも、その公開・共有方法について明

確なルールを定め、共通化をしていくことが求められると言える。

4.4.2. 情報源の信憑性や鮮度の維持について

情報収集の方法として、「メンバーが被災地に直接赴いて」という回答は 40％あり、アナログ収集の必

要性・有効性が挙げられる。 情報源の信頼性の確保と関連して、個々の情報の信憑性や鮮度の維持は、

とくにWebや SNSなど、デジタル手段で得られる情報について、多くのサイトでは、そうした課題が意識

されていた。

収集方法におけるデジタルとアナログの違いは、運営者が自由に選択できたものではなく、求める情報

の性質や情報源、とくに入手可能性による違いに起因したものと考えられる。端的にいえば、津波の直撃

を受けた沿岸部など、被害が酷かった被災地ほど情報発信が著しく困難で、支援者側が現地に直接出か

けて、積極的に収集しなければ必要な情報が得られない状況にあったため、いわゆる“アナログ収集”に

頼るしかなかったといえる。

151

他方、信憑性の確保や判定は最初から困難であると認めて、「正確性は保証しない」、「すべてをオープ

ンにする」と、利用者側に判断を委ねる方針をとったところも多い。緊急時であることや、被災者支援を目

的にすることなどから、そのような「割り切り」も社会的に許容されると判断したものと思われる。限られた

リソースであっても、人的な作業によって信憑性の確認を行ったサイトも存在していた。

4.4.3. 周知、プロモーションとアクセス急増による処理能力不足への対応

テレビで紹介されることも、大量のアクセスを発生させ、周知手段としては効果的だった。また、支援サ

イト等についての周知手段として効果を発揮したのが、Twitterや Facebookなどのソーシャルメディア

であった。アンケート結果でも、「支援サイト等の立ち上げや運営に寄与した」ものとして「ソーシャルメディ

ア」が群を抜いている。特に著名人が、支援サイト等についてTwitterで言及すると、その直後から大量の

アクセスが発生した。こうした事例がインタビューでも明らかになっている。

このようなサイトの告知・プロモーションが一定の効果を上げた場合や、取り扱っているデータの特性に

大きく影響するような事象が発生すると（寄付、放射能関連、余震情報など）その都度、大量のアクセスが

集中し、用意していたサーバーなどの容量が不足して、場合によっては機能停止などの障害が発生したケ

ースが広く存在していた。

サーバー拡張、移転などを取り扱うことのできるエンジニアが少なからず必要とされた。ただ、全体とし

て見ると、概ね、アクセスのピークは、おおむね2～3ヵ月で解消したものとみられる。

4.4.4. 法令や制度などの社会的な制約・課題への対応

本調査では、社会的な目的をもった支援サイト等に対して、刑法、民法、著作権法、個人情報保護法、不

正アクセス禁止法、薬事法、借地借家法などの様々な法令や、ガイドラインなど関連する諸制度が、結果的

に抑制的に働いた事実が指摘された。情報収集における2次利用などの許諾や著作権処理、個人情報や

プライバシー保護、セキュリティ関連などで、法令や社会制度上の制約・課題への対応が求められる局面

152

がみられた。

（１）緊急時の支援活動を制約した各種の法令・制度

個々の支援サイト等の運営者は、災害支援という公益の実現と、法令・制度の順守義務との間でどのよう

にバランスをとるか、自主的判断を迫られることとなった。実際には、多くの運営者が災害支援の重要性を

優先させ、自らをリスクにさらすことを覚悟したうえで、法令・制度の順守義務をあえて二次的なものとみな

す選択を行った者もある。

現在の我が国には、こうした災害などの緊急時における情報共有の在り方について、法令の適用除外

を認める、個別許諾を不要とするといった具体的な指針となる制度は、残念ながら存在していない。

（２）データの 2次利用の許諾、著作権処理

一般に公開されているサイト上の情報は、技術的には、情報源側の同意を得なくても、容易に取得し、加

工・整理し、その結果を一般に提供・共有することができる。今回も多くの支援サイト等が、情報源側の同

意を求めることなく公開情報を収集・加工し、再提供した。なかにはその合法性、妥当性について疑問をも

ちつつも、災害支援の公益性、緊急性を優先する判断を行ったところもみられた。公的機関が公開してい

る情報源にアクセスして、情報収集を行うときに、情報源側のサーバーへの負荷から、「偽計業務妨害罪」

に該当するリスクを想定した運営者も存在していた。

インタビューでも、自治体などの公開情報を取得し、加工したうえで情報提供することに関して、情報源

側の許諾との関係で懸念が表明された。また、APIによって一定の条件での情報取得が認められている

サイトから情報を取得した場合でも、その利用制限などへの対応を含めて、許諾範囲を超えているかどう

かの判断を迫られた支援サイト等も存在していた。

153

4.5. 継続・収束フェーズの課題と対応

アンケート調査では、現在も継続している支援サイト等は、運用者全体の7割近くあり、閉鎖したところ

は 2割だった。調査実施は2012年の 7月であり、震災発生から 1年4ヶ月が経過した時点でこれだけ

の支援サイト等が継続されているという事実は、それだけ東日本大震災における被害が大きく、復興に時

間がかかり、支援を必要としている人がまだまだ多いという事実を物語る。同時に、支援サイト等の多くは

一時的な勢いだけで始められたものではなく、復旧復興のために持続的に貢献しようという意志や体制を

示すともいえる。

継続・収束期における支援サイト等は、状況の変化に即して、活動の目的や内容、体制などの変更を迫

られたものも少なくなかった。利用が大きく減った支援サイト等では、目標が達成されたとして、閉鎖・終了

したものも出てきた。そうした場合に、今後の総括や教訓のまとめ、外部への発表などを行ったところもあ

る。

一方、ピーク時と比較すれば利用は減ったものの、支援サイト等が提供するサービスを利用する人が

依然として存在するものや、継続するための負荷、ランニングコストが小さいものなどにおいては、閉鎖を

選択せず、そのままの状態で継続している。より積極的に、被災地支援を継続していく、という積極的継続

の意志を示した支援サイト等も多かった。

サイトの特性と継続のしやすさを分析するため、支援サイト等の目的「情報提供」「直接支援」「中間支

援」の別と、継続中かどうかの関係をクロス集計により分析した。その結果、閉鎖したと答えた比率は、情

報提供を目的とする支援サイト等がやや高く、直接支援、中間支援の順となり、情報提供サイトの閉鎖率

がやや高いという結果が示された。これは、被災者への直接・中間支援のニーズのほうが、情報提供ニー

ズよりも長期にわたって存在していることを示唆するものであると言える。

154

図 4-5 支援サイト等の種別と支援サイトの現在の状況（ｎ＝１２５、％）

22.5

30.6

15.3

10.8

8.1

1.8

6.3

2.7

1.8

0.0 10.0 20.0 30.0 40.0

情報提供

直接支援

中間支援

継続中

サイトを閉鎖した、またはサービスを終了している　

その他

155

また、サイトの運営団体の種類と継続のしやすさを分析した。その結果、グラフで示されているように、

現在も継続しているサイトの運営団体は、個人、コミュニティ、企業、NPOの順に多かったが、その差は僅

かであり、継続のしやすさは運営母体の種別にかかわらないと言える。

図 4-6 運営団体の種別と支援サイト等の現在の状況（ｎ＝113、％）

運営者向け 運営団体の種別とQ02-4支援サイトの現状

70.0

64.7

63.0

62.5

20.0

11.8

33.3

25.0

10.0

23.5

3.7

12.5

0.0 10.0 20.0 30.0 40.0 50.0 60.0 70.0 80.0

個人

コミュニティ

企　業

NPO

継続中

サイトを閉鎖した、またはサービスを終了している　

その他

156

4.6. IT技術要素と支援サイト等の品質及び安全性との関係性

4.6.1. 技術部品の選択では、短期間での稼働を優先

支援サイト等の立ち上げにあたって技術者がとった判断として、高い技術レベルを実現することよりも、

早期に稼働させることを優先した点が挙げられる。

サイトの構築・運用にあたっては、使い慣れていること／実績があることを優先的に選択した傾向が浮

かび上がった。技術者アンケートの「技術部品選択にあたり注意した点」の回答結果では、「使い慣れてい

ること／実績があること」（65.3％）が一位で、「早期に開発や設定が終わること」（58.3％）、「費用や開発

工程の負担が少ないこと」（50.0％）と続いた。

技術者は「プロジェクトマネジメント上の制約や課題」の問いに対して、「一刻も早く公開しなければと

いうタイムプレッシャー」と「一刻も早く公開するための品質面での見切り発車や割り切り」が同数（43.1%）

で多く、品質よりも時間的に急いで立ち上げることを優先させた傾向を明示していた。ただ、一般に、使い

慣れている技術部品の方が品質的に安定しやすいという側面はある。

技術者アンケートでは、支援サイト等の運営にあたって選択された技術部品として、さまざまなレベルの

ソフトウェアが用いられたが、その大半はオープンソースソフトウェアによるものである。インタビューでは、

自分の経験が直接生かせる形でサイトを立ち上げ、技術部品の選択にあたっても、使い慣れたものを活

用し、すでに所有しているプログラムなどを流用・展開した例が具体的に示された。

また、運用開始後の仕様変更対応については、技術部品の選択理由にかかわらず、共通した課題だっ

たことが窺える。

157

図 4-7 技術部品の選択とプロジェクトマネジメント上の制約や課題

28.6

22.5

22.2

27.0

27.8

9.1

27.3

20.0

24.4

25.8

26.4

9.1

6.5

12.5

8.9

6.7

6.9

9.1

3.9

3.4

4.2

9.1

5.0

4.4

3.4

4.2

16.9

17.5

20.0

13.5

16.7

9.1

6.5

10.0

6.7

9.0

5.6

9.1

9.1

10.0

11.1

11.2

8.3

45.5

2.5

2.2

1.3

0.0 20.0 40.0 60.0 80.0 100.0

早期に開発や設定が終わること

広く使われている技術（標準技術）であること

支援サイトの目的に適していること

使い慣れていること／実績があること

費用や開発工数の負担が少ないこと

その他

一刻も早く公開しなければというタイムプレッシャー

一刻も早く公開するための品質面での見切り発車や割り切り

混成技術者メンバーでの指揮系統の調整

混成技術者メンバー間での設計開発手法の相違

混成技術者メンバー間でのアカウント管理やプラットフォーム共有などチームでの開発環境共有

運用開始後の環境や情報源の変化に伴う仕様の変更

その他

制約や課題は特になかった

158

4.6.2. 新規にプラットフォームを調達したケース

早期に立ち上げた支援サイトには、プラットフォームを新規調達したところも少なくなかった。とくに、6

時間以内に立ちあげた支援サイト等では、4割を占めていた。サービスやクラウド環境など、時間や手間を

多くかけずに利用できる技術環境があったとの背景が考えられる。

次表は、6時間以内に立ちあげたと回答した支援サイト等のなかで、新規のプラットフォームについて

具体的な記述があるものを抽出したものである。

これらに特徴的なのは、Twitter、Google、wikiなど、すでに広く普及したサービスやクラウド環境を利

用したものが多いことである。いずれもネットを経由して多数のボランティアから情報資源や技術資源を

調達することに成功していることも特徴的である。インタビューでは、当初は自力でシステム構築に取り組

んだが、すぐに IT企業から全面支援の申し入れがあり、共同で構築した事例も見受けられた。

東日本大震災の発災直後から、多くのクラウドサービス事業者が、震災によって直接被害を受けたり、ア

クセス集中でダウンしたりした自治体や電力会社などの公共サーバーや、被災者支援団体のサーバーな

どを対象として、ミラーサービスを含めた無償提供を行った。これらは、ハードウェアやOSなどの環境、プ

ラットフォームだけを提供するものから、復旧に必要な人材まで提供したところ、あるいは既存のツールや

アプリケーションの利用を可能にしたところなど、提供形態にも多様な特性がみられた。

無償提供を受けずに自力で運用したサイトでも、クラウドサービスを活用することで、変動する負荷に柔

軟に対応できたところが多かった。

表 4-6 新規にプラットフォームを用意し、意思決定から 6時間以内に立ちあげたサイト

サイト名 目的 特徴・成果 プラットフォーム 運営団体 開始日 （2011）

SHARE THE TSUKUBA

筑波大学近辺のライフライン状況を共有

TwitterAPIを利用 個人 3/11

saveMLAK 博物館・美術館、図書館、文書館、公民館の支援

MediaWiki を用いた共同編集による所在情報・被災情報・救援情報の集約と共有

MediaWiki コミュニティ 3/11

159

サイト名 目的 特徴・成果 プラットフォーム 運営団体 開始日 （2011）

計画停電カレンダー

計画停電の予定公開

ユーザはグループ別のカレンダーを取り込むことで、計画停電の情報を共有

公開 Google カレンダーを利用。

個人 3/13

sinsai.info 災害情報・復興支援情報の収集と視覚化

クラウドソーシングによる、Twitter を始めとした情報収集と地図上への情報表示

Ushahidi という既存のオープンソースを利用

社団法人 3/14

ボランティアインフォ

ボランティア情報を集約し Yahoo! goo msn @nifty経由で提供

2011 年夏までにヤフーで5000 件のボランティア情報を掲載。被災地に人を送り込んだ

クラウド環境（heroku）の活用。枯れたものでスピーディーに取り組んだ。wikiを利用したポータルから開始

コミュニティ 3/14

Amazon.co.jp被災地向けほしい物リスト

被災地への直接的物資支援

被災地がほしい物をほしい時にほしい数量だけ支援者が直接支援できる

自社運用の「ほしい物リスト」の応用

企業 4/7

Toksy (トクシー)

物が必要な人とあげられる人を個人同士マッチング

30,000品以上マッチングさせ、被災地に物資を送った

Amazon-EC2 を利用。mixi、Twitter アカウントと連携

企業 4/12

160

4.6.3. 個人情報、プライバシー保護への配慮とセキュリティにかかわる技術選択

個人情報やプライバシー保護への配慮や技術的な対策については、緊急時のサイトということで、セキ

ュリティ対策については、運営者の課題認識としても、技術的方策の回答から見ても、優先度が低い傾向

がみられた。

自由回答では、災害などの緊急時にはプライバシーデータの扱いを例外的に緩和する制度が必要だと

いう指摘もあった。またインタビューでは、緊急時の支援サイト等として、迅速な立ち上げや、被災者への

支援活動を優先し、セキュリティやプライバシーへの配慮は２次的なものとして優先度を下げても許容され

るという考え方が見られた。

セキュリティ対策で技術的な実装を十分施さなかった状況の背景には、緊急時に災害支援を行うという

ことで、タイムプレッシャーのなかで余裕がなかったことに加えて、公共的な目的があるので、そこまで要

求されないという意識もあったものと思われる。

重要なデータを迅速にかつ安全に扱うことを実現するため、技術者同士が協力しあえば迅速に実装で

きる、セキュリティ保護に関する技術やツールの整備が求められる。

161

4.7. 総括

4.7.1. 支援サイト等の活動成果

調査結果とそれを受けて行った分析・考察から、今後の災害時における ITを活用した支援サイト等の

効果的な立ち上げおよび運用について資する知見を、以下、提言の考え方と具体的な方策としてまとめ

た。

本調査全体を通じ、支援サイト等が災害時の情報支援という面で様々な役割を果たしてきた実態と、直

面した課題が、詳しく明らかにされた。以下では、本調査の全体としての総括を、支援サイト等の活動の成

果、制約と課題としてまとめた。

（１） 支援ニーズを反映、多種多数の支援サイト等がきわめて迅速に立ち上げられた

今回の震災における ITを活用した支援サイト等の活動の成果として、第一にあげられるのは、災害発

生直後から、きわめて多種多様なサイトが数多く、迅速に立ち上げられた点である。我が国においてはもち

ろんのこと、世界的にみても、前例のない規模、質の活動であったといえるだろう。

時系列的にみても、発災後１週間以内に立ち上げられたサイトがもっとも多く、７２時間以内に立ち上げら

れたサイトがこれに続いたことは、立ち上げのスピードが速かったことを端的に物語る。また、サイトの内

容も、地理情報や位置情報を用いた避難所情報や炊き出し情報、放射線量や計画停電に関する情報、緊

急地震速報などの災害情報、支援物資など支援ニーズのマッチングサイト、多様なボランティア情報、寄

付金仲介など、実に様々な分野に及んだ。

ただし、これらは災害そのものが極めて大規模で、被害も多岐多様にわたり、支援ニーズが広範となっ

たこと、そしてかつ突然の出現であることによる衝撃も大きなものであったことの反映であるとの見方もで

きる。言い換えれば、それほど広範囲に影響の及ばない災害の場合には一定の割合では発現するとは限

らない。災害情報や、支援継続を実行しているサイトなどの必要性を考えさせるものである。

162

（２） 自発性の発現

従来、公的セクターやマスメディアが中心になって行われてきた災害時の情報提供活動を、民間セクタ

ーが自発的に担ったという点で大きな社会変化を示したといえる。また、それらの活動が自発的に開始さ

れ、展開され、多くの ITエンジニアが社会的な貢献活動に従事した。企業もNPOも、個人もコミュニティ

も、ときに既存の組織の壁を超え、ときに既存の組織の強みを活かして、被災者支援の活動に専心した。

支援サイト等を立ち上げた人々は、自らの決意、スキルとリソースの投入を行ったもので、現地支援に駆

け付けたボランティアと同様に、ITサービスを通したボランティア活動が広範に展開されたといえる。

（３） エンジニアが自分のスキルで社会貢献

多くの支援サイト等で、エンジニアが自分のもつスキルを発揮することで、社会貢献を行った点が特筆

される。彼らの多くは、社会的なボランティア活動の経験や問題意識をもっていたわけではなく、伝えられ

る被害のあまりの過酷さに、あたりまえに、市民として何かをしないではいられないという感覚から、自然に、

自発的に支援サイト等を立ち上げた。一人で立ち上げられた支援サイト等がもっとも多かったことは、こう

した状況を裏付けるものである。また、支援サイト等を立ち上げたエンジニアの多くが、他のサイトへの協

力活動を行ったことも、注目に値する。スキルをもっているエンジニアが多くのサイトで必要とされ、そうし

た期待に応えたといえる。

（４） コミュニティによる貢献

個々人の貢献に加えて、エンジニア同士の連携・協力、エンジニアとNPO団体との連携・協力など、コ

ミュニティによる貢献がみられたことも、今回の活動の成果といえる。ユーザ会など、日頃からの活動で人

間関係をもっているところが、支援サイト等の立ち上げにおいても機能した例がみられた。

163

（５） SNS、クラウド、モバイル、BBなどの技術・環境を活用

Twitterやmixi、Facebookなどのソーシャルメディア、クラウドサービスなど、最新の IT技術・環境が

活用され、従来なら不可能であったような分野横断型での連携や協調活動を、きわめて短期間に、きわめ

て広範囲に、そしてきわめてローコストで実現することに大きく寄与した。また、スマートフォンなどのモバ

イルメディアも活躍し、GPS、GISなど地理情報を生かしたサービスが効果的に展開された。

これらの背景としては、ブロードバンドが広く普及していたという社会環境が存在していた。

（６） OSSなどの活用で迅速、ローコストに立ち上げ

多くのサイトでは、オープンソースソフトウェアによる部品、ツールが使われたことで、迅速かつローコス

トでの立ち上げが可能となっていた。エンジニアが使い慣れたプラットフォームなどを活用することで、状

況の変化に柔軟に対応することも可能であった。

（７） 支援活動全般を支えるインフラ＝「新しい公共」の役割発揮

本調査で明らかにしてきたように、多様な目的や機能をもった支援サイト等が数多く、自発的に立ち上

げられ、被災者支援に必要な大量の情報を収集・提供するようになった。これは、大規模災害に対して、IT

を利活用することで救援・支援活動が効果的に推進できる可能性を明確に示唆したものといえる。特に、

Webやブログ、メールはもとより、TwitterやFacebookなどに代表されるソーシャルメディア、Ustream、

Skypeなど多様な ITサービスの普及もあり、支援活動を推進する上で ITの利活用は必須であると言っ

ても過言ではなく、それらは公的サービスの根幹を支えるインフラであるとも言える。

「新しい公共」とは、公共サービスを、従来のように政府・自治体などの公的セクターのみに依存するの

ではなく、市民やNPO、企業なども柔軟な発想により、分担して担うという理念である。その意味では、今

回出現した多数の支援サイト等は、災害時における「新しい公共」を担う有力な存在となったと考えること

ができる。

164

災害時においては、自助、共助、公助のいずれもが必要となり、それらの連携が求められると言われて

いる。「新しい公共」とは、そうした自助、共助、公助の連携とみることもでき、そこでは情報の効果的な共

有が鍵となり、高い自発性に支えられた支援サイト等は、その土台を提供するものである。

（8） 自律・分散・協調型のアイデンティティの確立

今回の災害において、ITエンジニアたちが総体として、集合的に、協調的に、多様な支援サイト等の活

動を実現したことは事実であった。現在、企業社会でも IT業界などの新興ベンチャー企業を中心として、

組織のフラット化や人材の専門職化、ワークシェアリングやコワーキングなど、従来の価値観にとらわれな

い流動的な働き方が急速に普及しつつあり、情報技術の発展はこれらの動き、広い意味でのコミュニティ

活動を支え、今後、より広い規模で実質化が進展していくものと考えられる。

今回調査した支援サイト等のなかにも、自ら「コワーキングスペース」4を運営するなど、こうした新しい

形態での就業・経営形態を推進し、その成果を享受する企業や個人、NPOが多く存在していた。これは単

なる偶然ではなく、彼らの活動や現象の全体は、社会的な意味での“自律分散協調システム”であったと

考えられる。

情報システムが自律分散協調システムとして構成されるためには、広域にわたって分散した膨大な資

源が必要とされるが、今回みられた支援サイト等は、まさにインターネットを通じて相互に接続された個人

や企業、コミュニティなどの多数の主体によって構成された自律分散協調システムであったといえる。

2011年は、まさにこうした社会的な意味での自律分散協調システムを作り上げるための諸条件が整いつ

つあったことを示唆する年だったと考えられる。

「自律」とは、全体を統制的に制御・管理する主体が存在していなくても、個々の主体が他の主体に依存

4 同じ地域コミュニティで活動する複数の企業や団体が、スペースを共同保有・利用し、柔軟で効率的な働き方を実現する仕組み。

165

することなく、あるいは制約を受けることなく存在し、持続できるような力量・構造をもっていることを意味

する。今回の調査で明らかになってきた事実にあてはめていえば、少人数で迅速に立ち上げた支援サイト

等が多く、かつそれらの７割が１年後の現在も存在し、今後の継続を予定しているという事実自体が、支援

サイト等の立ち上げにあたって個人の判断や強い意志、動機さえあれば、とくに大組織の力や、他者によ

る支援がなくとも可能だという点で、高い自律性を示したといえるだろう。

「分散」とは、自律性をもった多数の主体が、互いに物理的には（あるいは論理的には）離れた空間に存

在している状態を指している。ただし、分散は離散とは異なり、相互に離れていてもネットワークが介在す

ることで、相互につながっている状態を意味する。メールであれ SkypeであれTwitterであれ、ネットワー

クを経由して、主体同士の相互作用が行われる状態にあることが、分散状態である。今回の支援サイト等

の活動でも、マッシュアップ、スクレイピングなど、一つの支援サイト等から提供される情報や機能が他の

サイトによって活用され、拡散され、展開していったことは、この「分散」の特徴をよく表すものである。

「協調」とは、文字通りに解せば、主体同士が協力し、調整し、集合的な行為を成り立たせることを意味

する。ネットワークにおいては、共通のプロトコルを用いることで、同一機能を広く利用可能とすること、ある

いは共通のプラットフォームを用いることで、効率的な分業を可能にすることなども、協調といえる。今回

の支援サイト等の活動においては、「炊き出しまっぷ」が集めた情報を「炊き出したん」が利用したり、

Googleのパーソンファインダーが、集まってきた避難所の膨大な画像情報を、ユーザが自発的に読みと

って文字入力したといったところに、ネットワークが可能にした協調の現れを見ることができる。

今回の支援活動についていえば、あまりにも広域にわたって起きた災害であり、横の連携を図ることは

容易ではない。それでも、次回のことを考えれば、何らかの形で主体同士が即時に連絡を取り合い、様々

なリソースの共有、あるいは知恵の交換の仕組みをもっていれば、より有効に災害に対処することができ

ると思われる。

166

いずれにしても、今回の支援サイト等の活動にかかわった ITエンジニアたちは、社会システムとしての

自律分散協調システムの重要な構成要素となり、またその受益者ともなって、その社会的意義を確立でき

たものと考えられる。それは、彼らにとっての社会的な意味でのアイデンティティの確立であるといえる。

167

4.7.2. 支援サイト等の制約と課題

被災地の厳しい状況のまえに、支援サイト等の多くは様々な制約を受け、課題に直面したことも事実で

ある。様々な個人や団体が自発的に立ち上げた支援サイト等は、当事者の自覚の有無にかかわらず、公共

性の高いサービスを担ったことで、結果として以下のような様々な課題が発現した。

（１）インフラ

まず明らかにいえることは、未曾有の災害のまえに、十分な支援能力は存在しなかったことである。本

調査では、個々の支援サイト等の活動についての評価を行うことは目的としていないため、支援サイト等

を含む支援活動がどの程度有効であったかについても、直接考察の対象とはしていない。しかし、被災地

における状況を著した様々な資料・文献などからは、発災直後から避難所、仮設住宅への移転を含めて、

多くの被災者が置かれた状況は、支援活動をもってしても、到底緩和できない過酷なものであったことは

明らかである。

支援サイト等との関連でいえば、とりわけ発災から少なくとも数日間、東北沿岸部では、津波による破壊

のために通信インフラの大半が損壊し、インターネットや携帯電話などの利用はきわめて困難であり、内

陸部においても、停電や通信の輻輳等により、大半の通信サービスが利用困難であったのが実態である。

本調査の対象となった支援サイト等の大半は、東北被災地の外側で立ち上げられたもので、被災地で

直接利用できない状況があったことは、支援サイト等を立ち上げた多くの運営者が自覚していたことであ

る。

（２）リソース

支援サイト等の立ち上げにおいても、多くの制約と課題が存在していた。すでに見たように、人員・技術

168

スキルの不足は広くみられ、また情報源、情報そのものの収集に苦労した支援サイト等も多かった。資金

サポートも十分とはいえなかった。当初は自分たちの技術で社会に貢献したいという純粋な意志で立ち

上げた支援サイト等の多くが、継続のための人員体制や運営資金などの問題に直面した。

本調査で明らかになったことの一つが、サイト同士の連携が必ずしも十分には行われなかったというこ

とである。これについては、個々の支援サイト等の関係者の意思の問題であるだけでなく、連携を可能とす

る「中間支援」のためのプラットフォームが整えられていなかったということも指摘できる。

同様に、支援する側と、被災地で支援を受ける受援側との情報面でのギャップも存在していた。本来、情

報システムが機能すれば、受援ニーズと支援サプライとの間の最適化が可能となるはずであるが、実態

はそうした理想的状態からはほど遠かった。被災地の多くで、支援物資が大量に送られて余ったり、反対

にまったく不足したりという状態が存在していた。物流システムの不足とともに、情報システムの不足も顕

著であり、ボランティアの受給にも同様の状況が存在していた。

なお、本調査は、立ち上げることができた支援サイト等のみを対象としたもので、立ち上げようとしたが、

リソース不足で断念した人々は調査の対象としなかった。リソース不足はそうしたケースに現れていたも

のとみられるが、その実態は把握できていないことも書き添えておく。

今後、災害時において支援サイト等の果たす役割は、増加することはあっても、縮小するとは考えられ

ない。その意味でも、これらの支援サイト等が「新しい公共」にふさわしく、災害時にその機能を果たす強

靭な存在となるために、どのような制度や方策の整備が必要なのか、今後、関係者、関係団体をはじめ、広

く検討・実現されるべき課題といえるだろう。

（３） データ活用に関する環境の問題、またセキュリティ対応の技術知識の不足

本調査のアンケートやインタビューからは、アクセス過多や利用者対応、著作権対応などに課題がみら

れた。緊急時であることを優先することで、セキュリティやプライバシー保護など、品質面や安全面での配

慮が二の次とされたことは、やむをえない選択だったとしても、今後の大きな課題を示したことは否定でき

169

ない。制度上の問題を別にしても、こうした問題を短期的に解決できる技術的方策、あるいは運営上の実

践的な手段についての情報や、実践的な経験がサイト構築にあたることができたレベルの技術者の間で

さえ広く行き渡っていないことを示唆している。

170

4.8. 提言

以下、総括における考察に基づいて、今後の災害に備えて、ITを利活用した支援サイト等が効果的に立

ち上がり、被災者支援に有効な機能を果たせるようになるために必要と考えられる、新たな仕組み、制度、

考え方について、自助、共助、公助のレベルに分けて、提言をまとめた。

4.8.1. 自助：自らの備え

個人にせよ、団体にせよ、緊急時を想定してとられるべき方策としては、「備えること」が重要であり、日

頃からの備えが迅速な意思決定と実行力につながる。本調査から引き出される備えに関する提言を以下

に示す。

（１）日頃からの災害時の準備

緊急災害時の対応のためには、何よりも、日頃から準備をしておくことが重要である。この点については、

エンジニアにとっては、技術面では自らのスキルを活かすことが可能なことが確認されているので、主と

して人的ネットワークに関する準備が重要になると考えられる。技術者がオープンな場で協力して物事に

あたることを促進することは大きな連携による効果的な活動につながる。

（２）BCPに支援活動を含める

緊急事態が到来したときに速やかに支援活動を立ち上げるためには、迅速な意思決定、実行力が求め

られる。この点については、とくに組織において、緊急時の意思決定体制として、支援活動を平時とは異な

る形で展開できるように、事業継続計画（BCP）などにあらかじめ含めておくことが重要である。社会的な

継続性を確保するために、他者への救援・支援について、計画に組み込むことである。

（３）メディアの利用リテラシーの向上

171

緊急時には、情報共有手段としてマスメディアの影響が大きい。同時に、ソーシャルメディアが情報収

集・共有の手段として特に重要になる。また、後者は今後も新たなサービスが展開・普及していくものと思

われる。それらを活用した情報発信・共有の特性を理解し、必要に応じて利用のリテラシーを高めておくこ

とは、災害時の支援活動を推進するうえで無視できない要素であると考えられる。

（４）プライバシ・セキュリティの実装手段の啓蒙・促進

プライバシーデータとの取り扱い保護、セキュリティ対策などの問題が二の次とされたことはやむを得

ないとしても、課題として大きく認識すべき事柄である。これは被災者、支援者の両方の意味におけるサイ

ト利用者としても認識しておかなければならない。

プライバシーデータの緊急時の取り扱いに関する制度面でのことを別にしたとしても、十分普及したオ

ープンな技術の活用においてこの点での技術的理解を高めることにより、実装の敷居を下げることは重要

であると考えられる。オープンな技術を駆使する技術者がウェブサイトのセキュリティ保護についても一定

のレベルで実装できるよう、技術情報やツールの理解を促進することが重要である。

4.8.2. 共助：社会・体制としての備え

個々の準備を進めるだけでなく、共助を構成する分野で、社会全体として以下の備えが必要である。

（１）支援サイト等を運営するための資金や収入に対する理解

災害時の支援サイト等は、すべてがボランティアで成り立つとはいえない。NPOも企業も、外部からの

資金提供があれば、より強力な支援サイト等の運営が可能となる。支援サイト等は、被災地への直接支援

よりも、直接支援団体を支援する中間支援、あるいは、情報発信で自己完結する情報提供型の活動が多

いということが今回の調査で明らかになった。しかし、災害時に発動される各種の資金援助は、そうした中

172

間支援や情報提供活動は対象外とするところが多いという点は課題である。こうした支援の全体的な枠

組みの中での費用負担の理解の醸成は必要となると考えられる。

（２）連携・協力体制の整備

今回の調査を経て、とくに重要と思われる事項が、連携・協力体制の整備である。想定外の災害に対し

て、自発的に立ち上げられた支援サイト等は数も多かったが、その多くは、目前の課題に集中することに

追われ、サイト同士の連携・協力は、必ずしも十分に実現しなかった。今後に備えて、支援サイト等同士の

連携の仕組みを、今から整備することは重要と考えられる。そうした仕組みは、前述の情報ボランティアの

育成や、サイトの運営マネジメントに関するプログラムの推進、資金体制への参画などとセットで推進する

ことが考えられる。また、支援サイト等の運営のマネジメントができる人材も重要となる。これらの人材を育

成するためのプログラムを策定・実施することが必要である。

(３)緊急事態を想定した情報伝達・支援の防災訓練と出動

人材面では、いわゆる「情報ボランティア」など、災害時に現地を中心に、情報収集・発信を行える専任

の人材を育成することが重要である。しかし、災害などの緊急事態に備えるためには、「机上の議論」では

明らかに不足である。

この点で、毎年各地で定期的に行われている防災訓練に、「情報伝達」や「情報支援」のプログラムを組

み込み、実践的な訓練を繰り返し行うことが重要である。さらに、災害時に情報支援を行うことを想定する

団体・個人は、規模の大小を問わず、実際に起きた災害の際に出動し、訓練で得たスキルを実際の災害に

適用し、共有を図ることも重要である。

173

4.8.3. 公助：法令、政府の備え

公助の一環として、法令や制度の見直しは重要と思われる。本調査でも、政府や自治体、公的企業など

に対して、オープンデータやオープンガバメントなどの形で、データの公開や、自由な利活用が保証され

る情報プラットフォームを求める意見が多くあったことが確認できた。

実際の支援サイト等の活動において、行政がもつデータを苦労して加工し一般に提供した例も多く、そ

うした経験に裏打ちされた貴重な指摘として受け止める必要がある。政府においても、オープンデータに

関する検討が開始されているが、今回実際に支援サイト等を立ち上げ、データの収集・加工に苦労した

人々の意見を取り入れることは重要である。また、災害時に被災者支援を行うのは主として自治体であり、

市町村レベルでのオープンデータの取り組みを加速させることも必要である。

著作権、データの 2次利用、個人情報保護などの面で、緊急時において直面した法令や制度上の制約

についても、法律の見直しや災害時の例外措置などの制定を早急に講じるべきである。

174

4.9. おわりに

本調査においては、それぞれの支援サイトの実際的な効果を測定することに主眼を置かなかった。これ

は、自発的なコミュニティが一定の自律性をもち、自分たちの努力で取り組みが進められたことを尊重し、

そこから示唆を得るべきであると考えたからである。

その結果、いみじくも、エンジニアたちが自発的に立ち上がり、高い技術的能力を備えていたとしても、

災害時に有効な情報流通の基礎をなす信頼できる情報源の確保、また自由な情報流通の手段を社会とし

て整備しなければならないことが浮き彫りとなった。

本調査が、我が国に存在したこうした自発的な取り組みに光をあて、同時に今後直面するかもしれない

大災害においてさえ、しなやかな社会を維持する大きな力とするために、各人・各組織によるより進んだ自

発的な取り組みへとつながる一助となれば幸いである。

175

図目次

図 2-1 回答者プロフィール 年齢（運営者 ｎ＝９６／技術者 ｎ＝６０） ......................................... 8

図 2-2 回答者プロフィール 職業（運営者 ｎ＝１１３／技術者 ｎ＝７２） ..................................... 9

図 2-3 回答者プロフィール 業種・分野（運営者 ｎ＝１１３／技術者 ｎ＝７２） .......................... 9

図 2-4 サイト目的別分類（ｎ＝１２２） ....................................................................................................10

図 2-5 基本情報 運営団体の種別（ｎ＝１４５（運営者＝１１３／技術者＝３２）） ............................10

図 2-6 基本情報 取り扱ったデータの種類（当てはまるもの全て選択）（ｎ＝１４３（運営者＝１１２／

技術者＝３１）） ....................................................................................................................................... 11

図 2-7 基本情報 プラットフォーム選択の状況（ｎ＝１４５（運営者＝１０８／技術者＝３７）） .....12

図 2-8 基本情報 公開日（ｎ＝１４４（運営者＝１１２／技術者＝３２）） ...........................................12

図 2-9 基本情報 支援サイト等の現在の状況（ｎ＝１４５（運営者＝１１３／技術者＝３２））.........12

図 2-10 運営者向け Q1 立ち上げの動機・経緯（３つまで選択）（ｎ＝１１３） ..................................13

図 2-11 運営者向け Q2 サイトの支援内容を決めた理由について（３つまで選択）（ｎ＝１１３） ...14

図 2-12 運営者向け Q3 公開のスケジュールの目標（ｎ＝１１２） .......................................................14

図 2-13 運営者向け Q4 公開までに要した期間（ｎ＝１１２） ..............................................................15

図 2-14 運営者向け Q5 立ち上げ時のメンバー数（ｎ＝１１０） ...........................................................15

図 2-15 運営者向け Q5 立ち上げ時の技術者割合（ｎ＝１１０） ...........................................................16

図 2-16 運営者向け Q5 メンバーを集めた方法（当てはまるもの全て選択）（ｎ＝１１２） ...............17

図 2-17 運営者向け Q6 支援サイトの立ち上げまでに要した費用の調達（当てはまるもの全て選択）（ｎ

＝１１２） ................................................................................................................................................17

図 2-18 運営者向け Q7 支援サイト立ち上げの際に苦労した点（当てはまるもの全て選択）（ｎ＝１１

２） ............................................................................................................................................................18

図 2-19 運営者向け Q9 サイト運営にあたり、直面した課題（３つまで選択）（ｎ＝１１３） ...........20

図 2-20 運営者向け Q10 他のサイトや団体等との協力・連携が効果的だったもの（３つまで選択）（ｎ

＝１１３） ................................................................................................................................................24

図 2-21 運営者向け Q11 サイト上での支援を継続している理由（３つまで選択）（ｎ＝８７） .........27

図 2-22 運営者向け Q12 支援サイトの今後の予定（ｎ＝８６） ............................................................28

図 2-23 運営者向け Q13 サイト上での支援機能を終了した理由（３つまで選択）（ｎ＝２６） .........30

図 2-24 技術者向け Q1 運営者との関係（ｎ＝７２） ..............................................................................31

図 2-25 技術者向け Q2 支援を決めた理由（３つまで選択）（ｎ＝７２） .............................................32

図 2-26 技術者向け Q3 支援へのかかわり方（ｎ＝７２） ......................................................................34

図 2-27 技術者向け Q4 他に支援をしたサイト（ｎ＝６９） ..................................................................34

図 2-28 技術者向け Q5 かかわったフェーズ（当てはまるもの全て選択）（ｎ＝７２） ......................36

図 2-29 技術者向け Q6 かかわった技術分野（当てはまるもの全て選択）（ｎ＝７２） ......................36

図 2-30 技術者向け Q7-A 技術部品（プラットフォーム）（当てはまるもの全て選択）（ｎ＝６５）

...................................................................................................................................................................38

図 2-31 技術者向け Q7-B 技術部品（サーバーOS）（当てはまるもの全て選択）（ｎ＝５４） ...........38

図 2-32 技術者向け Q7-C 技術部品 （サーバーサービス）（当てはまるもの全て選択）（ｎ＝４７）

...................................................................................................................................................................38

図 2-33 技術者向け Q7-D 技術部品（開発言語）（当てはまるもの全て選択）（ｎ＝５９） ................39

図 2-34 技術者向け Q7-E 技術部品（IDEや開発環境）（当てはまるもの全て選択）（ｎ＝４３） ....40

図 2-35 技術者向け Q7-F 技術部品（フレームワーク）（当てはまるもの全て選択）（ｎ＝１８） .....40

図 2-36 技術者向け Q7-G 技術部品（データベース管理システム）（当てはまるもの全て選択）（ｎ＝４

２） ............................................................................................................................................................41

図 2-37 技術者向け Q7-H 技術部品（CMS）（当てはまるもの全て選択）（ｎ＝３０） ......................41

176

図 2-38 技術者向け Q7-I 技術部品（進捗管理やバグトラッキング）（当てはまるもの全て選択）（ｎ＝

２８） ........................................................................................................................................................42

図 2-39 技術者向け Q7-J 技術部品（バージョン管理）（当てはまるもの全て選択）（ｎ＝２３） ......42

図 2-40技術者向け Q7-K 技術部品（チーム内コミュニケーション）（当てはまるもの全て選択）（ｎ＝４８） ....43

図 2-41技術者向け Q8 技術部品選択にあたり注意した点（３つまで選択）（ｎ＝７２） .....................44

図 2-42 運営者向け Q8 サイト運営に必要な情報の収集手段（当てはまるもの全て選択）（ｎ＝１１３）

...................................................................................................................................................................45

図 2-43 技術者向け Q10 マッシュアップの際の注意点（３つまで選択）（ｎ＝７２） ........................51

図 2-44 技術者向け Q12 技術支援メンバー数（ｎ＝６３） ....................................................................56

図 2-45 技術者向け Q12 技術支援体制とその特徴（ｎ＝６３） ............................................................56

図 2-46 技術者向け Q13 不足しがちだったリソース（当てはまるもの全て選択）（ｎ＝７２） .........59

図 2-47 技術者向け Q14 プロジェクトマネジメント上の制約や課題（当てはまるもの全て選択）（ｎ＝

７２） ........................................................................................................................................................60

図 2-48 運営者向けQ14 支援サイトの立ち上げや運営に寄与した事柄（５つまで選択）（ｎ＝運営者

１１３） ....................................................................................................................................................62

図 2-49 運営者向け Q15法令等による制約、情報セキュリティ対策やプライバシー保護等の課題（ｎ

＝１１１） ................................................................................................................................................63

図 2-50 運営者向けQ16 実体験を踏まえたメッセージやアドバイス（ｎ＝１１２） .........................64

図 2-51 技術者向けQ15 実体験を踏まえ、取り組んだもの（当てはまるもの全て選択） ...................68

図 2-52 教訓、提言、その他関係方面に望むこと（運営者 ｎ＝１１２／技術者 ｎ＝７２） ..........70

図 4-1 サイトの内容と公開日（ｎ＝263） .............................................................................................. 140

図 4-2 サイトの目的と運営団体の種別（ｎ＝111）................................................................................ 141

図 4-3 サイトの規模と立ち上げに要した時間の関係（ｎ＝112） ........................................................ 145

図 4-4 立ち上げまでに要した時間と、人を集めた方法（n=110、％） ................................................ 146

図 4-5 支援サイト等の種別と支援サイトの現在の状況（ｎ＝１２５、％） ........................................ 154

図 4-6 運営団体の種別と支援サイト等の現在の状況（ｎ＝113、％） ................................................. 155

図 4-7 技術部品の選択とプロジェクトマネジメント上の制約や課題 ................................................... 157

177

表目次

表 1-1 支援サイトのライフサイクル分類 ........................................................................................................ 3

表 1-2アンケート調査項目 ................................................................................................................................ 5

表 1-3 アンケート回収状況 ............................................................................................................................. 6

表 1-4 報告書の構成 .......................................................................................................................................... 6

表 2-1 運営者向け Q7 「立ち上げの際に苦労した点」 自由記述による回答 ......................................18

表 2-2 運営者向け Q9 「サイト運営における直面した課題」 自由記述 .............................................21

表 2-3 運営者向け Q10 「他のサイトや団体等との効果的な協力・連携」 自由記述 ........................25

表 2-4 運営者向け Q11、Q12 「継続理由と今後の予定」 自由記述による回答 ................................29

表 2-5 技術者向け Q2 「支援を決めた理由」についての自由記述 .........................................................33

表 2-6 技術者向け Q3 「支援へのかかわり方」 についての自由記述 ...................................................34

表 2-7 運営者向け Q8 「情報の収集手段」 自由記述による回答 .........................................................45

表 2-8 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「情報源」（ｎ＝４８） ...........47

表 2-9 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「取得手段」について（ｎ＝４９）

...................................................................................................................................................................48

表 2-10 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得「取得タイミング」について（ｎ

＝４５） ....................................................................................................................................................49

表 2-11 技術者向け Q9 サイト運営に必要な情報・コンテンツの取得 「データの加工・処理」につい

て（ｎ＝４１） .........................................................................................................................................50

表 2-12 技術者向け Q11 サイト運営にあたって行った「取り扱う情報の信憑性や鮮度の維持」（ｎ＝４

０） ............................................................................................................................................................51

表 2-13技術者向け Q11 「アクセス状況や利用状況の把握・分析、改善」（抜粋） ...............................53

表 2-14技術者向け Q11 「支援サイト利用者の利便性向上」（抜粋） ......................................................53

表 2-15技術者向け Q11 「セキュリティ確保のための具体的な技術手段」主な自由記述（抜粋） ......55

表 2-16 技術支援体制の特徴（自由記述）（抜粋）.......................................................................................56

表 2-17不足しがちだったリソース（自由記述）（抜粋） ................................................................................59

表 2-18 技術者向け Q14 プロジェクトマネジメント上の制約や課題の内容を具体的に示した自由記述

（抜粋） ....................................................................................................................................................60

表 2-19 運営者向け Q15 「制約、課題、教訓」 自由記述による回答 .................................................64

表 2-20 運営者向けQ16 「実体験を踏まえたメッセージやアドバイス」自由記述による設問回答の整

理................................................................................................................................................................66

表 2-21 運営者向け Q１６「アドバイス」、Q17 「教訓、提言、望むこと」自由記述による設問回答の

整理 ............................................................................................................................................................71

表 2-22 技術者向け Q16 「教訓、提言、望むこと」自由記述による設問回答の整理 ..........................75

表 3-1 インタビューしたサイトの概要と経験した特徴的な事象 ........................................................... 122

表 4-1 東日本大震災における災害フェーズ、被害、救援・支援活動の時系列整理 ............................ 134

表 4-2 必要とされた情報[出典：『情報行動調査』情報支援プロボノ・プラットフォーム（iSPP）, 2011

年7月実施] ............................................................................................................................................ 135

表 4-3 東日本大震災における被害、救援・支援活動の状況と情報ニーズ、情報行動の時系列整理.. 137

表 4-4 サイトの目的と運営団体の種別（ｎ＝111）................................................................................ 142

表 4-5 支援サイト等のライフサイクルと共通課題 .................................................................................. 142

表 4-6 新規にプラットフォームを用意し、意思決定から6時間以内に立ちあげたサイト ................. 158

178

【監修・編集】

IPA 技術本部 国際標準推進センター

災害に対応する ITシステム検討プロジェクトチーム

【著作権・責任】

本書の著作権は、独立行政法人情報処理推進機構（IPA）に帰属します。本書で使用されるIPA

またはその他の団体・企業等の商標、標章、ロゴマーク、商号等に関する権利は、IPAまたは個々

の権利の所有者に帰属します。

2012年度オープンソフトウェア利用促進事業

東日本大震災発災直後におけるインターネット上の支援サイト等の技術課題に関する調査

報告書

2013年1月