年別アーカイブ: 2015年

Smart Fire Fighting その2

Smart Fire Fighting報告書は3つの論から成り、「はじめに」、「本論」、そして「結論」です。「本論」の中の章立ては、以下のとおりです。

 
  • 通信技術と伝送方法
  • 個別防護装備としてのセンサー
  • モバイルセンサー
  • 固定型センサー
  • データ収集
  • ハードウェア/ソフトウェア
  • リアルタイムデータ分析
  • 消防データのアプリケーション – 緊急事態前と後 –
  • 緊急事態対応中のデータ利用
  • 消防士でない人向けのアプリケーション
  • 伝送方法のユーザ・インタフェース
 

上記章立てから分かるように、どのような技術要素があるか漏れ無くまとめています。技術的に何があるか提示し、そこからアプリケーションへ話を展開します。この報告書は個別技術要素を選定するのが目的ではなく、大まかな研究開発ロードマップを示すのが目的なので、もう少し踏み込んで議論しても良いと感じるところもあります。しかし、頭の中をある程度整理するためには非常に分かりやすい報告書です。

 

そして、「はじめに」の中で、以下のとおり具体的な研究項目を例示し、報告書の中でどんな議論が展開されるか示唆します。

 
  • 自動走行、衝突回避技術。なぜなら火災死者の10%は車火災に関連するものだからである。
  • 移動ロボット。DARPAのロボットチャレンジは2014年が第1回、それは消火活動に焦点を絞ったものだった。ロボットに要求されたのは、スタンドパイプを特定し、消火ホースのかたまりを運搬し、スタンドパイプに取り付け、蛇口を開くという作業であった。
  • 次世代防護服。心拍数・呼吸・皮膚温度を測定する。3軸加速度計。速度・距離・歩数・歩幅を計測するブーツ。そして、解析のため、無線でスマホにデータを送る。靴下のセンサーにより、歩数・速度・高さ・距離を測定し、ジャンプしたかどうかも記録する。
  • 仮想現実ゴーグル。まるで見ているかのような情報がゴーグルに表示される。
  • モバイルコンピューティング。何百万のスマホアプリとともに。
  • GPSと連携する高度な地図情報。
  • ビッグデータ。火災の予防や救急対応における新分野を代表するもので、分散されたセンサーからのリアルタイムデータとクラウド中にあるデータベースから構成される。
  • マルチメディア・ソーシャルメディア・IoTの勃興。人口のほとんどが携帯電話を保有することにより膨大な情報が生み出されている。
  • BACnetやASHRAEによるビルの自動化や制御ネットワークのためのデータ通信プロトコル。建物センサーのような個別アイテムの効率が上がる技術の統合を促進する。
  • 火災警告システムを含むスマートホーム。建物の重要な機能である安全・安心・娯楽・エネルギー・周囲の環境を高度に制御する。
  • Firstnet。全米ブロードバンドネットワークであり、警察・消防・救急サービスが7つの方法によって音声会話を可能とする。それらはプッシュ・ツー・トーク機能、グループコール(1対多)、ダイレクトモード(1対1あるいは近傍検索)、全二重音声(通常の電話と同じ)、発信者番号通知を含む。
 

これを見るだけでも、報告書において、Smart Fire Fightingとして想定しているものがどんなものかは掴めるかもしれません。現時点で、CPSとして取り上げられることが多いのが、製造プロセス・モビリティ・スマートハウス等であるので、消防という観点から見るひとつの例として参考になると思います。

 

次の回では、面白いと感じた論点を中心に紹介する予定です。

Smart Fire Fighting その1

Fire Fightingは英語で消防を表します。まさに火と格闘することです。では、スマートな消防は何を表すのでしょうか。答えは、消防の近未来像のひとつであり、他の産業においても検討されているIoT(Internet of Things)あるいはCPS(Cyber Physical Systems)モデルを活用する、です。

 

下図は産業構造審議会商務流通情報分科会が公表した【社会全体がCPSにより変革される「データ駆動型社会」】です。ここに示されているように、CPSによるデータ駆動型社会とは、実世界とサイバー空間との相互連関が社会のあらゆる領域に実装され、大きな社会的価値を生み出していく社会です。

CPSによるデータ駆動型社会

実世界とサイバー空間との相互連関をイメージすることは簡単ではないと思いますが、データを収集・蓄積することと、何らかのモデルを開発することとを合わせ、現実の世界で起きることを予め想定し、行動につなげることです。しかも、モデルはサイクルを回したり、データ量を増やすと改善することが可能なのです。インターネットによって人々の情報への接し方が変革されたのと同様に、CPSによって人々の個別技術システムへの接し方が変革されるだろうと言われています。

 

これは米国の国立標準技術研究所が今年6月に公表した報告書です。報告書の元になったワーキンググループ参加メンバーは、半分が現役の消防士達、半分が各分野の専門家です。

NIST_report

表紙の題名にもあるとおり、研究開発ロードマップです。偶然だと思いますが、Smart Fire FightingにおいてもCPSが検討の柱となっています。日本の消防の近未来像を考えたり、あるいは消防・救急の新たなモデルを検討する上で役立つであろうと想定し、何回かに渡り、この報告書のエッセンスを紹介したいと思います。もちろん、米国と日本の違い、消防のあり方の違い等も踏まえて、お伝えしたいと思います。

「近代消防」8月号 テロ対策の対談掲載

2020年のオリンピック・パラリンピック東京大会開催を控え、様々なところでテロ対策の検討が始まっている。たとえば、消防庁の研究結果「大規模イベント開催時の危機管理等における消防機関のあり方に関する研究」であり、警察庁の「国際テロ対策強化要綱」である。

 

地震・津波・噴火等様々な自然災害に対する防災や減災については、これまでの経験も踏まえ日々全国各地で注意喚起や対策改善に取り組んでいるところである。一方、相手が人間であるテロに関しては、どこか異国の地で起きている事象と認識している人がほとんどではないか。シリアにおける邦人殺害テロ事件で、日本がテロ対象国に名指しされたことは実に大変な脅威である。

 

今回、モトローラ・ソリューションズ社のSmart Public Safety Solutions部門のTom Guthrie副社長が来日するのに合わせ、上記消防庁研究会の有識者でもあった吉井博明前消防審議会会長との誌上対談を実現することができた。紙面の都合で全部を採録することはできなかったが、お二方の深い知識と豊富な経験から導かれる論点は非常に興味深いものであった。

DSC_1951

詳細は7月10日発行の近代消防8月号(32ページから)を御覧ください。

ICT-BCP その4(完)

これまでの話を踏まえて、具体的なICT-BCPの章立てを考えてみましょう。

 
  1. ICT-BCPの基本的な考え方
  2. ICT部門の運用体制(平時、発災時)
  3. 被害状況の想定
  4. 対象システム及びサービス
  5. 検討項目とリスク評価
  6. ICT部門の訓練計画
 

1章では、目標を明示することが大切です。たとえば、発災後72時間以内、という目標を掲げることで、以後記述されていること全てが、この目標を達成するために検討されていることが分かります。ここが、「なるべく中断させず、中断してもできるだけ早急に」のような記述では、想定する範囲が広すぎて検討に曖昧さが残ります。

 

2章では、平時の運用体制と発災時の想定運用体制を提示します。同じ章に記載することで、その違いが明確になります。災害時判断を誰がどのように行うかまで提示されているのが望ましいです。図上訓練で時々見受けられますが、平時のように上司に判断を仰げる状況ではないにも関わらず、それを理由に何もアクションを起こさないことです。そのようなことを許容する体制ではマズイです。

 

3章では、地域防災計画の被害想定を踏まえながら、具体的な想定を掲示することが重要です。もし、職員初動マニュアルも存在するなら、それとの整合にも配慮します。この章が具体的であればあるほどICT-BCPの役に立つ度合いは高くなります。

 

4章では、ICT-BCPの対象とするシステム及びサービスを記載します。

 

5章では、検討項目毎のリスク評価を記載し、検討した対策も記します。この評価を行う際、目標が明確である必要があります。目標や被害想定が変更される場合、あるいは対象システムが追加される場合にも、この考え方を適用することができます。

 

6章では、訓練計画を提示します。特にライフライン(電力、通信、水、道路等)が途絶える場合、実際どのような動きを各システムがするのか確認する訓練が求められます。「実運用しているシステムで検証するな」というのはICTの基本的な考えです。しかし、災害時を想定すると、できるだけ本番に近い環境で訓練を行うことが大切です。庁舎電源の定期点検はそういう意味ではチャンスです。5章で検討したことが、想定通りにいくかどうか確認し、その結果から導かれることを再び5章に反映させるのです。

 

4回シリーズでICT-BCP策定ポイントについて記載しました。ICT-BCPは防災・減災に重要な役割を果たします。何らかの理由でICT-BCP策定が進んでいない自治体の中で、少しでも取り組み始めることを期待します。もちろん、このブログでの記載だけでは充分ではないので、お問い合わせから具体的な相談をいただければ対応したいと思います。

 

最後に、ICT-BCP策定時に参考になる2つの書籍を紹介します。ひとつが国土交通省がkindle版を無償公開した「東日本大震災の実体験に基づく 災害初動期指揮心得」です。日本語版と英語版があります。もうひとつが東日本大震災時に後方支援拠点となった遠野市が発行する「3.11東日本大震災 遠野市後方支援活動検証記録誌」です。ICT-BCPは、絶たれた補給路の再構築手順に他ならず、2つの書籍から学ぶことは多いはずです。

 

以上

土砂災害防止法一部改正への対応

平成26年8月広島豪雨により広島市北部で発生した土砂災害は死者74名、負傷者69名、全壊家屋179棟という大きな被害をもたらしました。「8.20豪雨災害における避難対策等検証部会」の中間報告が公表された後の平成26年11月現地を訪れ、広島市消防局危機管理部の方々にお話を伺いました。特に、消防局指令センター、危機管理部執務室、災害対策本部室(消防局講堂)の情報システム(電話・FAX含む)設備関係、作業空間・位置関係等を踏まえ、当日の情報処理について確認しました。この時の豪雨は局地的且つ夜から未明だったため、住民への情報提供に関し課題が浮かび上がりました。

八木3丁目県営住宅横から県道41号線方向

 

今般、土砂災害警戒区域等における土砂災害防止対策の推進に関する法律(土砂災害防止法)の一部改正する法律が施行された(平成27年1月18日)のを受け、土砂災害に関する住民への情報提供および警戒避難体制・避難所開設について支援するコンサルティングサービスを立ち上げました。対象は、自治体です。サービス概要は資料を参照下さい。

 

国土交通省の説明会では、「住民に土砂災害の危険性が十分伝わっていない」「土砂災害警戒情報が、直接的な避難勧告等の基準にほとんどなっていない」「避難場所や避難経路が危険な区域内に存在する」等指摘されています。実際、これらをどのように具体的な防災対策に結びつけていくか多くの自治体担当者が頭を悩ませていると思います。土砂災害を想定した災害対策本部・警戒本部図上訓練、避難所運営ゲーム、防災リーダー・ワークショップ等を行うことにより、実践的な防災対策を推進してはいかがでしょうか。

ICT-BCP その3

ICT部門は、全てのサービスを運用するために、ハードェア、ソフトウェア、及び保守を提供してくれる業者(ベンダー)を活用しています。ICT−BCPを策定する際、このベンダーとの関係をどう活かすか悩ましいと感じている人は多いはずです。特に、運用のために人を派遣してもらっていれば尚更です。

 

東日本大震災で明らかになったことのひとつに、自治体とベンダーとの契約には災害条項は含まれていなかったことがあります。この場合の災害条項とは災害時の努力義務です。一般的には、保守契約の適用除外項目の中に災害(地震)が明記されていますので、地震が起きた時点で契約が無効になります。それは止むを得ないと思うのですが、復旧作業に一緒に携わって欲しいのに、何も契約が存在しないことになってしまうのです。もちろん、ベンダーにとっても災害時対応は最も難しいことのひとつなので、何かを約束することはなかなか無いとは思いますが。

 

ICT-BCP策定の際は、この部分にも踏み込みます。前回言及した具体的な被害想定に基いて、お互い最善を尽くす手段を決めるのです。幸い多くのベンダーはICT-BCP策定支援の経験もあります。自治体側が具体的な被害想定を作り、ベンダー側がそれへの対応を考え、お互いに実現可能性や忘れている点がないかを検討することができれば良いと思います。ややもすると、被害想定も含めてたたき台を作って欲しいとベンダーに依頼したいかもしれませんが、ここは踏ん張りどころだと思います。発災時点から災害対策本部は様々な情報を集めることが可能なのですから。

 

念の為に書くと、「サーバ類が設置されているラックを免震のものに替えましょう」という提案などは、庁舎が無事で、電源・通信も安定供給されている場合には検討価値があります。ICT-BCPを検討すると、視野が広くなるので、少なくとも部分解決策の採択を判断する前に全体を俯瞰することにつながると思います。

 

余談ですが、分かっているつもりでも書いてみると気づくことがあります。自分の市町村、普段働いている庁舎、仕事をする端末など、被害想定という目で見直し書き出してみることを薦めます。

 

続く

ICT-BCP その2

地域防災計画には地震による被害想定があります。ICT-BCP策定の場合にもこれを活用します。ただし、この被害想定は人的被害(死者数、重傷者数)、住家被害(全壊・半壊棟数)が中心です。人的被害と住家被害から、生き埋め者救出、怪我人搬送、応急危険度判定、避難所開設・避難者受け入れ、死亡届の受付、罹災証明書発行などの仕事量が想定できます。被害想定の中には電力被害、通信被害に言及するものもありますが、視点はその自治体のエリア全体です。

 

ところが、ICT-BCP策定時に必要なのは特定箇所の想定です。各庁舎(支所含む)の揺れによる被害がどの程度か、庁舎内部にあるサーバ・PC等の情報機器の被害はどの程度か、各庁舎への電力、通信はいつ復旧するかです。細かいことを言えば、庁舎の中の、ある特定の部屋のサーバあるいはPCに電力、通信を供給できるかです。そして、万が一代替物品を輸送する必要があるなら、対象となる場所までの緊急輸送路等の通行可否、車両・運転手調達、あるいはヘリコプターによる輸送なども重要な要素になります。

 

地震が起きると、津波、火災、そして土砂崩れ、液状化が続く場合があります。揺れによる被害だけでなく、それに続く被害も念頭に想定を行うことが大事です。

 

庁舎の耐震性が無い場合、あるいは津波浸水域にある場合、地域防災計画に災害対策本部の代替設置場所が記載されています。そうなると情報システムを復旧する拠点も代替場所の想定が必要です。これは必ずしも災害対策本部と同じ場所になるとは限りません。なぜなら、情報システムを復旧する拠点には電源及び通信が不可欠だからです。電力や通信の復旧を待つだけでは能がありません。停電が長期に渡る場合も想定し、代替場所を想定しておくことが肝要です。

 

ある程度被害想定を具体的に描いてくると、いつどんなサービスを復旧するのかが目標として必要になってきます。ICT-BCPを策定するにはこれが不可欠です。住民基本台帳システム、課税台帳システム、国民健康保険システム、後期高齢者医療システムなどが優先度が高いサービスだと思われます。しかし、各自治体によって異なるかもしれません。これを全庁合意の下で決めるのがICT-BCPの最も重要な作業のひとつと言えるでしょう。これらのシステムを使用している部門(住民課や税務課など)に、発災後の仕事量と方法(場所含む)を確認し、想定されるシステム復旧工数と重要度を順位付けします。もちろん、より多くのシステムができるだけ早く使えることが望ましいですが、残念ながら復旧に投入できる人数、代替物品、時間には限りがあります。総合的な判断から、いつどんなサービスを優先して復旧するのかを目標に掲げます。

 

続く

ICT-BCP その1

ICT-BCPを策定しようか悩んでいる自治体として次のようなところを想定します。人口数万人の市町村。ICT部門である情報システムグループは5〜8名の陣容で、ICT-BCPに詳しい人材はいないと仮定します。組織的には総務部配下です。

 

悩みのひとつは、予算が厳しく情報システムに新たな投資はできないことだと思います。想像の通り、ICT-BCPを策定するのには費用はあまりかかりません。なぜなら主な成果物は文書だから。ただし、どの程度危ういか評価した結果、何かしら事前に対策を打つと決断し実行するといくばくかの費用がかかります。つまり、予算が無いからICT-BCPは策定できない、ことはありません。ICT-BCP策定に踏み込むと、相当な予算が必要になる、ことはないのです。

 

悩みのふたつ目は、推進する人材がいないことだと思います。あるいは、他業務との兼務でやってもらうしかない状況があると思います。ICT-BCP策定に限らず、小規模市町村の中で、恵まれた環境で始められるプロジェクトはほとんど無いでしょう。そうなると、やらなければならないいくつかの政策の中で、ICT-BCP策定をどのあたりに位置付けるかによります。市町村トップがやると決めるのが良いのですが、判断するまでに至っていないところは未だたくさんあると思います。

 

ひとつの考え方は、ICT-BCP策定の中で出てくるPDCA(Plan-Do-Check-Action)サイクルは、他のプロジェクトにも応用できるものなので、その導入のためにICT-BCPを使うというものです。逆の発想です。自分のところにPDCAサイクルを導入してみるとどうなるか理解するために、ICT-BCPで試すのです。ICTが向かう方向はMobile Firstです。情報を提供する側も、受ける側も場所に縛られなくなるということです。現在の多くの自治体の情報システムは対応していませんが、徐々に進み、いずれ劇的に変わるのではないかと思います。自治体クラウドはその一歩とも言えます。そして、情報セキュリティへの組織的対応を必ず求められますが、その際には、PDCAは必須となります。

 

ところで、ICT-BCPを推進するのにICTの知識は無くても大丈夫なのかと心配する方がいるかもしれません。答は「ある方が良いが、無くても構いません」です。総務省から懇切丁寧なガイドラインも出ています。強いてどんな人が向いているかと言えば、ICT-BCPは大地震のような場合に発動・実行されるものなので、危機に瀕する状況を思い描くことが得意な人が良いと思います。たとえば、如何に早く必要物資を手配し必要な場所へ届けるかという非常時物流を思い描けるといいです。また、運用している情報システムの被害状況をすばやく掴むには、停電時、あるいは通信不通時は、ほとんど役に立たないICT部門が管理している機器ではなく、防災行政無線だったり、消防団の無線だったりするので、それらの活用の発想に長けているといいですね。

 

ICT部門も推進するべきでしょうか。答は、もちろん、Yesです。ただし、主に推進する人材は必ずしもICT部門からでなくて良いと思います。このあたりは各々の組織の状況によりますが、このような組み合わせを可能と考えるなら、選択肢が増えるでしょう。

 

続く

ICT-BCP

BCP(Business Continuity Planning)は業務継続計画と訳します。企業は、大きな災害や想定外の問題に見舞われた際、どのように生き延びるべきかの指針としてBCPを策定し運用しています。それは事業が持つ脆弱性が思っているより大きいためです。常に競争に直面している企業は、突然赤字に転落したり、場合によっては事業譲渡、あるいは倒産もあり得るのです。対極にあるのが公共事業体です。「つぶれる」ことを想像するのは難しいです。ところが、東日本大震災で明らかになったのは、庁舎が失われ、インフラが失われ、そして人材も失われると、住民サービスを継続することが非常に厳しいということです。しかも、代替してくれるところは無いのです。そこで、自治体にもBCPを策定し、危機に瀕する場合に、適切な対応を取ることが期待されています。特に、住民基本台帳の元データのように貴重なものが失われ、バックアップも同時に失われると、その復旧にとてつもない労力がかかり、その影響が被災した人々に及ぶことが明らかになりました。そのため、BCP策定の前であっても、ICT-BCPの策定を急ぐよう求められています。

 

ところが、なかなか策定が進んでいないようです。そこで、これまでの経験から、いくつかのポイントを指摘したいと思います。何回かに分けて書くことになると思いますが、ICT-BCPに取り組んでみようと思う人・組織が増えることを願っています。