Vol.5 No.2 2012

42/76

研究論文:災害救助支援のための情報共有プラットフォーム(野田)−118−Synthesiology Vol.5 No.2(2012)多くの災害は不定期、しかも長い時間間隔をおいて起こるものである。例えば地震では、社会的な被害の出るような規模の地震は、ある特定の地域で見れば、数十年~数百年、場合によっては千年のスパンでしか起こらない。比較的頻度の高い風水害にしても、毎年必ず襲ってくるものではなく、まれに起こるからこそ思わぬ大きな被害が生じることになる。裏を返せば、まれな時を除いた残りの期間は、災害情報システムは、訓練等を除いてほとんど稼働しないことになる。一方、情報技術の進歩は日進月歩である。自治体がもつ災害情報システムは、だいたい5~10年の間隔で更新されることが多く、その更新のタイミングで時々の最新技術や機能が組み込まれていく。それと同時に、古びた技術や機能は徐々に外されていく。このためほとんどのシステム・技術は、ほんの数回、場合によっては全く実際の災害に使われずに役割を終えることになる。このライフサイクルの時間スケールの差を乗り越えるのがデータの継続性である。システムの頻繁な更新に比べると、データは長期に渡って蓄積されるものであり、その寿命は長い。特に再利用可能な形で記録されたデータの価値はなかなか古びないことが多い。先にも述べているように、自治体の情報システムは5~10年間隔で更新されるが、その更新の際にデータがいかに引き継がれるかが重要となる。このことから、災害情報共有のシステムを設計する上では、十年・百年の長期にわたるデータの再利用性・蓄積性を中心に考えることが有効である。3.2 データ中心による臨機応変なシステム連携データ中心の考え方は、臨機応変なシステム連携の視点でも重要である。災害への対処は数多くの組織が関わる活動であり、災害情報システムもそれらの組織を跨って運用されなければならない。このような複数組織が関わる情報システムをモノリシックに設計・実装することは、現実問題として難しい。よって、各組織がサブシステムとして個別に情報システムを設計・構築し、それらを連携させることが現実的な解となる。この場合、その連携を機能中心に設計するか、データ中心に設計するか、二つの考え方がありうる。機能中心のシステム連携の一例が、WSDL(Web Services Description Language)やUDDI(Universal Description, Discovery and Integration)を活用したウエブサービス連携である。ウエブサービス連携では、各サーバーがさまざまな機能を実現・公開し、それらを組み合わせて高次のサービスを実現する。この考え方は、多様な要求に柔軟に応えることを容易に実現できるという点で優れており、さまざまな対応が求められる災害救助でも有用な考え方ではある。しかし、各サーバーは「連携」を意識した設計・実装を行う必要があり、各自治体において必要な機能をそろえておく必要がある。データ中心のシステム連携は黒板モデルで代表される。この黒板モデルでは、各サブシステムは共通領域(黒板)にデータを提供し、あるいはそこにあるデータを取得することで、サブシステム同士の連携を実現する。この考え方では、黒板にデータが提供されれば各サブシステムを機能させることができ、各サブシステム同士の「連携」を意識する必要はない。一方、機能を密にあるいは柔軟に組み合わせることは難しく、多機能・高機能の実現には向かない。災害情報システムは日本全国の自治体で活用されることを考えると、システム連携の仕組みは機能中心よりもデータ中心とすべきである。南北に広がる我が国では、災害の種類も多岐にわたり、雪害に悩む地域もあれば、水害を最重要視しなければならない地域もある。よってそこで必要とされる機能もさまざまであり、組み合わせも複雑となる。また、自治体の防災体制や関係組織は画一的ではなく、サブシステムの構成方法も異なってくる。このため、必要とされる機能やデータをどのサブシステムに担わせ、不足しているものをどう補うかが重要となるが、不足機能の補填は即席では困難である一方、不足データについては、精度や動的性・正確性の劣化を許容すれば、補うことは難しくない。さらに、東日本大震災を被災した自治体でのヒアリング[5]によると、さまざまな想定外の事象により、多くの自治体では事前の防災計画をいろいろと手直しせざるを得なかったことが明らかになっている。この震災を契機に各自治体での防災計画はさまざまな形で見直されると思われるが、それでも想定外のことは起きるものとして、対応の柔軟性を確保しておくべきである。それに伴い、情報システムも事後に機能の組み替えを行うものとして設計されなければならないといえる。そして、この事後の組み替えを迅速に行う鍵として、データ仲介による単純な連携は効果的である。これについては、次章の実証システムで事例を示す。このデータ中心のシステム連携は、オープンソースでのプログラム開発にも通じる考え方である。E. Raymondは「伽藍とバザール」(http://cruel.org/freeware/cathedral.html)の中で、有名なハッカーの言葉として以下のような記述をしている。“賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。”(フレデリック・P・ブルックス著「人月の神話」第十一章)“コードだけ見せてくれてデータ構造は見せてもらえなかったら、私はわけがわからぬままだろう。データ構造さえ見せてもらえれば、コードのほうはたぶんいらない。見るまでもなく明らかだから。”比較的緩い方針の下で多数の人間により開発が進められ

※このページを正しく表示するにはFlashPlayer9以上が必要です