OSSで構築した被災者管理システム
1 like3,677 views
技術セミナー「被災地復興におけるOSS」 http://bit.ly/IEQifi 多賀城市は、東日本大震災の発生後、被災者を対象に罹災状況等のヒアリングおよび支援制度説明、罹災証明書・義援金の交付申請受付、応急仮設住宅の申込受付等を目的とした「被災者総合相談窓口」を開始した。相談窓口の運用には、未曾有の大災害の中で疲弊する対応職員の負担を限りなくゼロに近付け、かつ被災者へのサービスの質を担保するため、その業務を補助する何らかのシステムが強く求められた。しかし、情報の錯綜と混乱状態が続く中で、依頼先もなく、要求仕様を満たすシステムを相談窓口開始日までに準備することは困難を極めた。本講演では、OSSで構築した被災者管理システムの稼働前また稼働後の種々の課題と改善アプローチ、災害時における地方自治体の情報システム部門のあるべき姿について述べる。
OSSで構築した被災者管理システム
- 1. ＯＳＳＡＪセミナー「被災地におけるＯＳＳ」 平成２４年５月２４日（木） 豊嶋 茂一 宮城県 多賀城市
- 2. ＯＳＳで構築した被災者管理システム 1. 多賀城市の紹介 2. 多賀城市が直面したＩＣＴ課題 3. 被災者相談窓口の開設 4. 被災者管理システムの構築 5. 東日本大震災を振り返って 6. 震災から１年以上が経過して 2
- 3. １．多賀城市の紹介 人口・面積・職員数 仙台市と塩釜市・ 松島町の中間に位置 多賀城市（歴史・文化財のまち） 人 口：61,884 人 世帯数：24,842 世帯 面 積：19.65 平方キロメートル 職員数：正職員471名・非常勤163名 友好・姉妹都市： 福岡県 太宰府市・山形県 天童市・奈良県 奈良市 3 （平成２４年４月３０日現在）
- 4. １．多賀城市の紹介 名所・旧跡 ↑多賀城跡 多賀城碑→ 4
- 5. １．多賀城市の紹介 名所・旧跡 ↑沖の井（沖の石） 末の松山→ 5
- 6. １．多賀城市の紹介 被害状況：廃棄物・仮設住宅・支援 災害廃棄物 約29万立方メートル （25mプール約440杯分） 仮設住宅 入居戸数／総戸数 ＝ ３６５／３７３ 支援 人的：約15,900人 物的：約1,420団体、約640人 詳細はこちら http://www.city.tagajo.miyagi.jp/saigai/hisaizyouhou.html 6 （平成２４年４月３０日現在）
- 7. １．多賀城市の紹介 被害状況：住家被害 津波 地震 計 全 壊 1,676 76 1,752 大規模半壊 1,506 126 1,632 半 壊 885 1,207 2,092 一部損壊 1,070 4,874 5,944 合 計 5,137 6,283 11,420 全世帯数：24,842 大規模半壊以上は津波による 半壊以上：約２２％ 被害が９０％超 7 （平成２４年４月３０日現在）
- 8. １．多賀城市の紹介 被害状況：津波規模 津波の高さ 仙台港：約７ｍ 市 内：約２～４ｍ 浸水面積 約6.62平方キロメートル （市域の約３割） 犠牲者 １８８名 （男１１２名、女７６名） ＃ 市域で海に面しているの ＃ は約300mだが、砂押川 # 下流から上流へ逆流し、 ＃ 被害拡大 8 （平成２４年４月３０日現在）
- 9. １．多賀城市の紹介 被害状況：浸水地域の記録 至 塩釜・七ヶ浜 松島・石巻 至 仙台・名取・岩沼 仙台港 （多賀城市ＨＰにて動画・写真を公開中） http://www.city.tagajo.miyagi.jp 9
- 15. ２．多賀城市が直面したＩＣＴ課題 ① 情報発信手段がない！物資がない！ ② データ損失を防ぎ業務継続性を担保！ ③ 端末配備とネットワーク構築が困難！ ④ 情報共有手段を確立し混乱を防ぐ！ ⑤ 災害発生時点での住民データ保存！ ⑥ 災害時に利用できるシステムの準備！ （OSSで構築） 15
- 16. ２．多賀城市が直面したＩＣＴ課題 日 月 火 水 木 金 土 3/11 12 復電 13 14 15 16 17 18 19 インター ① 情報発信手段がない！物資がない！ ネット復旧 ② データ損失を防ぎ業務継続性を担保！ 20 21 22 23 24 25 26 ③ 端末配備とネットワーク構築が困難！ ④ 情報共有手段を確立し混乱を防ぐ！ 27 28 29 30 31 4/1 ⑤ 災害発生時点での住民データ保存！ ⑥ 災害時に利用できるシステムの準備！ 16
- 17. ２．多賀城市が直面したＩＣＴ課題 ①情報発信手段がない！物資がない！ 背景 課題 震災時の対応 ＮＴＴ交換局がダメージ HPによる情報発信不可 仙台市内個人宅でHP更新 電話、インターネット回 被害状況や支援物資 燃料確保、移動の必要 線が不通（3/17復旧） の呼びかけできず孤立 があり更新は１回／日 携帯電話もつながり難 情報入手 回線復旧後、全国から い状態 テレビ、ラジオ、新聞 支援物資が続々到着 現在：情報発信手段の二重化 専用回線・衛星通信端末 Webサーバの冗長化（未定） 支援物資が全国から届くが… 避難所への仕分け・配給作業に多数の従事者が必要 昼夜問わず届く支援物資の保管場所確保・在庫管理 負担軽減の手段が必要（POSシステム等） 17
- 18. ２．多賀城市が直面したＩＣＴ課題 ②データ損失を防ぎ業務継続性を担保！ 背景 課題 震災時の対応 データセンター利用済 特になし！ 特になし！ H22.10より、住基サー インターネット回線不通 バックアップ機からデー バをデータセンターへ の期間はシステムが使 タ抽出、加工 移行 用できない ハウジングによるシス 汎用機からWebパッ 庁舎内サーバルームは テム構築メリット再認識 ケージシステム 免震床のため無事 業務継続性が第一 現在：データセンター利用が原則 業務継続性に大きく貢献 年額コスト平滑化 メリットばかりではない インターネット回線の利用前提 バックアップ機をイントラ内に要準備 緊急時を想定したバックアップ・リストア手順 18
- 19. ２．多賀城市が直面したＩＣＴ課題 ③端末配備とネットワーク構築が困難！ 背景 課題 震災時の対応 震災対応窓口の設置 端末配備とケーブル配線 無線ＬＡＮの導入 廊下、物置等を使用し 端末数に応じたＬＡＮ 端末数増やどんな場所 た業務展開が必要 ケーブルとハブ、電源 にも柔軟に対応可能 罹災証明、義援金申請 確保が困難 職員の負担軽減 種々の臨時相談 ケーブル引き回し▲ 要セキュリティ対策 機器自体の枯渇 現在：柔軟なネットワーク構築環境が可能 無線ＬＡＮ親機・子機 ＬＡＮケーブル、ハブ、電源ドラム 水・食糧と同じく機器を『備蓄』 無線ＬＡＮ利用のために 暗号化、セキュリティ対策 常設は不要、設定知識を持つこと 19
- 20. ２．多賀城市が直面したＩＣＴ課題 ④情報共有手段を確立し混乱を防ぐ！ 背景 課題 震災時の対応 連絡手段が貧弱 情報格差 簡易メルマガ運用 避難所への連絡手段 職員間で持つ情報に差 職員の携帯電話メール が携帯電話のみ 分があり、混乱 アドレス収集にＱＲコー 本部会議の決定事項 特に避難所配置職員は ド利用 が全職員に情報展開さ 完全に孤立 本部決定事項 れない 住民への説明責任▲ を手動送信 現在：安否確認・情報配信システム導入予定 非常時に職員を緊急招集する手段確立 最新情報を正確、公平に職員へ展開 初動の組織体制をいかに迅速に整え、どう維持するか 職員ありきの復興 → 使い捨て・自己犠牲 → 負担軽減 決定権を持つ経営層の意識改革 （○○は会議室で起こってるんじゃない！） 20
- 21. ２．多賀城市が直面したＩＣＴ課題 ⑤災害発生時点での住民データ保存！ 背景 課題 震災時の対応 支援制度の適用条件 異動処理してしまった 異動全件を加除 3.11時点で登録されて 災害後は異動届が増 転出者を復元 いる住民リストが基礎と 加 転入者も取り除く なる 3.11時点の住民リスト バッチ処理では不完全、 生活実態が確認できれ を保存せず3.31まで放 要目視確認 ば支援制度利用可 置 現在：災害発生時の住民データを一元管理 あらゆる支援制度の基礎データ（マスタ） 関連システムを構築する際の材料 システム復旧後に必ず保存 電気→回線→システム復旧、その後の処理を忘れずに 被災者生活再建支援制度 申請期間 （基礎支援金 ２５ヶ月 ／ 加算支援金 ８５ヶ月） 21
- 22. ２．多賀城市が直面したＩＣＴ課題 ⑥災害時に利用できるシステムの準備！ 背景 課題 震災時の対応 被災者相談窓口開設 対象が膨大かつ長期 職員負担を軽減するには 支援制度の説明や相 相談者殺到が予想 相談内容を記録 談受付業務 被災者生活再建支援 相談履歴を残す フロア全体を利用した 制度の申請は長期間 履歴確認しながら受付 大規模運用 一元管理、情報共有す る手段がない 被災者相談窓口の受付で使える 『何らかのシステム』が必要 22
- 23. ３．被災者相談窓口の開設 目的と概要 目的 ヒアリング（input） • 罹災状況、避難所、現在の連絡先等 • 上記以外にも話を聴き、相談者の不安を和らげる 制度説明（output） • 被災者生活再建支援制度、義援金、仮設住宅等 概要 平成23年4月1日（金）から、現在まで継続中 受付 31,140件（相談者一人当り平均３～４回） 23 （数値は延べ数、平成２４年４月３０日現在）
- 24. ３．被災者相談窓口の開設 会場レイアウト 複合機 複合機 （後衛） 被災者生活 仮設住宅 仮設住宅 住宅の 専門 弔慰金 再建支援 A B 応急修理 ブース 複合機 複合機 （前衛） 後衛へ 義援金 一般窓口 一般窓口 一般窓口 一般窓口 振り分け 申請受付 A B C D 混雑時は整理券を配布 各窓口に職員２名、無線LAN接続のPC１台 複合機４台（証書のコピー、資料の印刷等） 義援金 申請受付 前衛は一次フィルタとして相談内容に基づき 後衛の専門ブースへ振り分けを行う 進 路 24
- 26. ３．被災者相談窓口の開設 窓口開設前の課題：猶予はたったの５日間 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 猶予５日間 窓口開始 窓口開設を知ったのは５日前 『窓口業務に使えるシステムはないか』 情報システム部門としては 寝耳に水 職員間での情報共有不足 （震災で庁内全体が混乱） どんな機能が必要なのか？ ５日間でどこまでできるのか？ 26
- 27. ３．被災者相談窓口の開設 窓口開設前の課題：要求仕様 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 猶予５日間 窓口開始 窓口業務に求められる機能 住基データに相談記録機能付加、一元管理 ヒアリング（input）、制度説明（output） • 罹災状況、避難所、現在の連絡先 • 被災者生活再建支援制度、各種貸付金 • 義援金、仮設住宅、住宅の応急修理 相談は複数回受付可能、履歴を残す 複数の相談窓口から同時アクセス 相談内容は機密情報、要利用者認証 長期的な受付が可能なシステム 27
- 28. ３．被災者相談窓口の開設 窓口開設前の課題：やるしかない！ 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 猶予５日間 窓口開始 『相談内容の記録』『履歴を残す』 相談履歴のデータベース化に特化した 『被災者管理システム』の必要性 ないものねだり。 ノウハウ、時間、依頼先、お金・・。 窓口業務に必須だが、資源は人員だけ。 どうする？ ５日間でやるしかない！やりきる！ 28
- 29. ４．被災者管理システムの構築 調査 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 システムの要求仕様と実現手段 複数の窓口から同時アクセス、相談履歴記録 CSS：クライアントサーバシステム DBMS：データベース管理システム 時間ない！依頼先なし！イチから開発無理！ 既存システム・パッケージ組合せ、派生開発 オープンソースだとベター（ライセンスフリー） やるしかない！とは言ったものの… 『藁をも掴む思い』 29
- 30. ４．被災者管理システムの構築 調査 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 できたらいいな サーバ 住基データをベースに • 相談履歴の記録機能を追加 • 避難先、各種支援制度の申込状況更新 Read/Write、利用者認証 クライアント：窓口端末 • 複数の窓口から同時アクセス 30
- 31. ４．被災者管理システムの構築 評価・レビュー・選定 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 調査結果：いずれもオープンソース 被災者支援システム（NICC:西宮市情報センター） 1995 M7.3 阪神・淡路大震災 Sahana （Sahana Japan Team） 2004 M9.1 スマトラ島沖地震 → 物資、家屋被害、仮設住宅、罹災証明 ボランティア、地図連動等、充実した機能 しかし…『相談履歴記録』の機能は持たない！ 31
- 32. ４．被災者管理システムの構築 評価・レビュー・選定 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 様々なアクションをトリガにその結果を記録す ることは、どこにでもある一般的な業務 例１：小売業 商品の販売履歴、営業活動の進捗状況管理 例２：行政 収納・生活保護・介護支援・障害福祉・訪問 要求仕様を満たすのは 「顧客関係管理システム：CRMシステム」 （CRM：Customer Relationship Management） 32
- 33. ４．被災者管理システムの構築 評価・レビュー・選定 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 SugarCRM：オープンソースCRMシステム Webブラウザで動作、問合せ管理・営業支援ツール 取引先・顧客に対して、いつどんな営業活動・商談を行ったか等 の全ての記録を履歴として一元管理する機能を持つ。 33
- 34. ４．被災者管理システムの構築 評価・レビュー・選定 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 方針決定：SugarCRMのサブセット 標準では多機能さ故に誤操作を誘発 必要な要素は次の通り 取引先 ：相談窓口を訪れた被災者 営業担当：応対職員（要利用者認証） 営業活動：相談内容（input/outupt） 最小限の機能にカスタマイズ 34
- 35. ４．被災者管理システムの構築 構築・開発・テスト 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 環境構築 S/W SugarCRM(SugarCE 5.2.0k) XAMPP(v1.7.4) PHP(v5.3.5), Apache(v2.2.17), MySQL(v5.5.8), phpMyAdmin(v3.3.9) デバッグ：Eclipse(v3.7,Indigo)+PDT / Pleiades Ver.管理：Apache Subversion(v1.6) H/W PentiumE2160(1.80GHz), Memory2GB, RAID5 Windows 2003 Server, ApacheBenchで負荷試験 35
- 36. ４．被災者管理システムの構築 構築・開発・テスト 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 住基データをインポートしたものの… 基本的な設計構造・仕様が把握仕切れず コメントアウトするコードを探すのに四苦八苦 GREP, コメントアウト, 動作確認の試行錯誤 条件が整っていたためチャレンジできた 電源、ネット回線は復旧済（2011/3/14） サーバルームは免震床だったため無事 他の職員が体を動かしている間、ずっと画面とにら めっこ。（災害と戦うための武器を精製） 36
- 37. ４．被災者管理システムの構築 動作環境・開発・デバッグ環境概要図 WindowsServer2003（既存、免震床設置） SugarCRM（サブセット） Apache：Webサーバ（クライアントサーバシステム） PHPソースを設置（ブラウザ動作） MySQL：データーベース管理 住基データ取込、属性追加 Read/Write、利用者認証 デバッグ後にソース更新 データベースのメンテナンス クライアント：窓口端末 開発・デバッグ端末 ブラウザ動作, OS不問. WindowsXP以上 数世代前のPCでもOK. Eclipse：統合開発環境
- 38. ４．被災者管理システムの構築 構築・開発・テスト 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 操作は３ステップ！ １．検索 相談開始時：名前、住所、生年月日等で検索 ２．相談履歴追加：複数回の相談に対応 ヒアリング（input）、制度説明（output） ３．相談内容の写しを渡す：相談者の安心 次回以降、以前と異なる職員が対応 →履歴参照しながら相談受付、負担抑制 38
- 39. ４．被災者管理システムの構築 デモンストレーション 被災者管理システム デモ環境（ダミーデータ） 動作環境：下記ブラウザで確認済 Internet Explorer 7.0以上 Google Chorome 10.0以上 39
- 40. ４．被災者管理システムの構築 被災者相談窓口開始 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 窓口開始初日：波乱の幕開け 次々に押し寄せる被災者 整理券を配布したが底をつく 被災ストレス、不満爆発、怒号 応対職員：ローテーションしていた が特殊な窓口業務で疲弊 新たな混乱を招いてしまった… 窓口開設が最適解だったのか？ 40
- 41. ４．被災者管理システムの構築 被災者相談窓口開始 3/27（日） 3/28（月） 3/29（火） 3/30（水） 3/31（木） 4/1（金） 調査 評価・レビュー・選定 構築・開発・テスト 窓口開始 最適解とするための武器：被災者管理システム 応対職員への操作説明（開始前1.0h） 一切のトラブルなく安定稼働 機能改善、追加はカスタマイズ対応 もしシステムがなかったら･･･大混乱 相談内容をメモ？（紙かオフィスソフト） 共有・一元管理できず、信頼性の低い記録 履歴を残せず、何度も同じ話を聴く 41
- 42. ４．被災者管理システムの構築 現在の稼働状況 被災者管理システム 照会 ＃ 相談履歴 更新 データ取込 罹災証明発行システム 義援金管理システム 職員 被災者生活再建支援制度 仮設住宅、応急修理 •ブラウザ動作 ＃ 申込・進捗状況を固有番号で紐付け •利用者認証 被災者の総合照会ツールとして活躍 • 情報共有、一元管理、職員負担軽減 • 被災住民に対するサービスの質向上 42
- 43. ４．被災者管理システムの構築 ＯＳＳで構築したことのメリット ライセンスフリー クライアントの急な増設にも柔軟対応 商用ソフト：要ライセンス管理で負担増 情報入手が容易 先駆者がネット上で情報を公開 商用ソフト：サポートを受けられる状況では なかった 動作環境を選ばない ブラウザ動作：特別なソフトの個別インス トールが不要で運用負担減、数世代前のＰＣ でもサクサク動作 43
- 44. ４．被災者管理システムの構築 稼働後の課題 相談履歴以外のデータが最新でない 義援金, 各種貸付金, 仮設住宅, 応急修理等 →これらのシステムは、別管理システムで運用中 回避：定期的に最新データをシステムに取込む 住民登録外の取り扱い そもそも取り込んだデータ内に存在しない 回避：システムに相談対象者の新規追加機能を追加 →住民登録外データの固有番号管理が未だ問題 住基連携できない 転入・転出をリアルタイム反映できず、本人か らの申告がなければ最新の情報が不明 稼働後もデータの新鮮さを 保つためのメンテナンスが必要 44
- 45. ４．被災者管理システムの構築 被災者相談窓口のあるべき姿 当時100点、振り返れば60点 4/1開設は早過ぎ 制度理解不足で玉虫色の回答 体制未整備で混乱（誰が何をいつまでに） 一元管理・情報共有のための管理手段を提案 100点に近付くには？今だから言えること 情報システム部署の役割：情報展開リーダー！ 現場で臨機応変かつ最適な提案・指示を出す 公平, 正確, 迅速：知らない・知らせないは大罪 デマ・誤った情報が広まることを抑制 45
- 46. ５．東日本大震災を振り返って 災害を相手にした戦争（本部） 『災害』を相手にした戦争 情報戦が肝要、受け身では勝てない 分からないからできない、は甘え 「できないからやらない」「できるけどやらない」 本当に勝ちたいなら自分から打って出る 目の前の敵だけと戦っていては勝てない 裏に潜む新たな敵・問題から目を逸らさない 武器・道具を準備した事前訓練、本番で発揮 予算とりました、導入しました、それで終わり？ 避難訓練？消火訓練？それで終わり？ 使わない武器・道具なんて金食い虫、負の資産 武器・道具を使えない・使おうと努力しない職員 46 なんて…
- 47. ５．東日本大震災を振り返って 災害を相手にした戦争（本部） 指揮系統を明確・強固に リーダー、一般兵の役割を明確に 決定・周知：誰が、いつ、どうやって 現場を鈍化させ混乱を呼ぶリーダーは失格 普段のプロセスをショートカットする体制も必要 現場を知る頭脳労働者が必要 力仕事だけではNG、焼畑農業はナンセンス 目標は何か、ゴールはどこか、周囲を誘導 自己犠牲が美徳は大きな間違い しっかり食わせる、休ませる、ローテーション リーダーがチーム内の負荷分散管理、意識強化 監視し合う体制は崩壊を招く、人に優しく 47
- 48. ５．東日本大震災を振り返って 災害を相手にした戦争（避難所） 連携強化：自衛隊、消防、警察、自治体職員 水・食料・備品の備蓄 避難者が殺到、必ず不足する、配給にも限界 熱源、毛布、生理用品、離乳食、アレルギー 衛生環境を整備すること トイレは流れない、紙もない、電気もない 居住エリアは土足厳禁 弱者への配慮（弱者の定義も重要） 乳幼児：可能であれば限定エリアを設ける 高齢者：指定福祉避難所への引き渡しも視野に 48
- 49. ５．東日本大震災を振り返って 災害を相手にした戦争（罹災証明） 罹災証明発行には家屋調査が必要 家屋被害判定の明確な根拠 調査依頼：「来るのが遅い！」 人が足りず、1か月待ちがザラ その間に自分で修理できてしまう、写真判定 判定結果：「厳し過ぎる！」 不服申し立て→再調査の繰り返し 表に出ないけれど…ゴネ得 プロフェッショナルの職員を大量投入しない とさばききれず、早期に応援が欲しい業務 49
- 50. ６．震災から１年以上が経過して 復興元年の体制・動き 震災復興関連の部署新設 生活再建支援室：被災者への支援 復興建設課：公共施設や道路の整備 自治法派遣職員の受け入れ ２６名、北は秋田県、南は沖縄県、雰囲気一新 非常勤職員・臨時職員の大量任用 前年度ベース ５０%増 大量の復興業務に対応 50 （平成２４年４月３０日現在）
- 51. ６．震災から１年以上が経過して 復興期におけるＩＣＴ課題 課題１：操作端末の不足 業務量増加に伴い、パソコンの配備台数が急 激に増加 ソフトウェアライセンスも同じく不足 対策 補正予算等で費用捻出 耐用年数を過ぎた端末も再利用 ＩＣＴ支援を要請（OpenOfficeでも何とかなるが、 可能であれば商用ライセンスも…） 基幹システムの動作に必要なライセンスと現在 の保有数を確認すること！ 51
- 52. ６．震災から１年以上が経過して 復興期におけるＩＣＴ課題 課題２：情報資産の増加 業務データ（紙媒体含む）が急激に増加 特にファイルサーバの容量が不足 ファイルサーバ負荷、ネットワークトラフィック増 対策（電子データ限定） ファイルサーバリプレース（負荷・容量） RAID5/660GB → RAID6/1.80TB → RAID5/5.40TB （現在） ネットワーク見直し（トラフィック） 未解決：1000BASE-T/100BASE-TX混在 52
- 53. ６．震災から１年以上が経過して 復興期におけるＩＣＴ課題 課題３：情報セキュリティモラルの維持 種々の申請受付データの所管が不明確 個人情報を扱う機会急増（正規職員に限定しない） 対策 注意喚起：機密情報の取り扱い、閲覧範囲 利用制限：USBフラッシュメモリ等、外部記憶媒体 セキュリティポリシー見直し 非常時だから…は既に通用しない時期 非常時であっても、個人情報の取り扱いは明確なガイ ドラインがなく、判断は困難を極めた 53
- 54. 【参考】稼働中の災害支援システム 稼働日 業務名等 (H23) ソフト等 開発 罹災証明発行 4/20 Access （株）パスコ様 義援金管理 4月末 Access 日本電気（株）様 災害援護資金貸付 未定 Access （株）東北電子計 算センター様 仮設住宅受付 4/1 Excel 職員 住宅の応急修理 4/25 Excel 職員 被災者相談窓口 4/1 SugarCRM 職員 職員向け 6/1 Limesurvey 職員 ストレス評価アンケート その他、評価中のOSS ファイル転送（OpenUpload） 、PHPLIST(メール配信）、CMS（JoruriCMS） オフィスソフト（OpenOffice） 54
- 55. 【参考】震災前・震災後の課題比較 課題 判定 備考 防災無線 ◎ 13機→53機、ディジタル化 キャリアはNTT docomo エリアメール △ 限定 職員の安否確認・情報連絡ツール × 予算確保できず Webサーバはホスティング ホームページ公開手段 ○ 衛星携帯電話 免震床サーバルーム サーバ移設 ○ データセンター 55
- 56. 【参考】いざという時のために ひと（採用・配置） 専門性を持った人間がいれば何とかなる！適材適所！ もの（機器、ネットワーク、システム） いざと言う時の設備、使えるシステムは事前に要準備！ 導入しっぱなしは論外！使い方を訓練し、非常時に活用！ かね（どこにお金をかけるか） 情報システム部門は金食い虫？仕分け対象？ナンセンス！ 業務継続性担保のためには、必要な費用をかける！ 経営者のリスクマネジメント 56
- 57. 連絡先 宮城県 多賀城市 総務部 総務課 情報化推進係 TEL :022-368-1141 E-mail : [email protected] http://www.city.tagajo.miyagi.jp 57