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