ichigan 参照アーキテクチャ

ICHIGAN参照アーキテクチャ

2011ｰ09-27 菊間裕二，アプリケーション・アーキテクチャ・リーダー

2011/12/26 2 Copyright(C) 2011 Project ICHIGAN. All rights reserved

この文書の位置づけ

当文書は、ICHIGAN参照アーキテクチャはどのような使われ方を想定しているか、またその概要を説明するための文書です

参照アーキテクチャがどのようなものであるかを示すために、いくつかの成果物例や利用プロセスがでてきますが、これらはたたき台であって、決定されたものではありません

関係者のみなさまのご意見をうかがって成長させていくべきものと考えております


目次

はじめに： ICHIGAN参照アーキテクチャとは？

【第1部】ICHIGAN参照アーキテクチャの使い方１．ICHIGAN参照アーキテクチャの使い方２．アーキテクチャー分析とは３．アーキテクチャ分析の流れ

【第2部】ICHIGAN参照アーキテクチャ概要４．アプリケーションアーキテクチャ概要５．アプリケーションアーキテクチャ想定シナリオ


ICHIGAN参照アーキテクチャとは？

通常業務

システム

被災時業務

システム

災害発生時のIT対策が十分

なのか、自治体の業務継続計画に照らし合わせて分析・

評価する手法を提供

あるべき

アーキテクチャ

災害対策を考慮した

ITシステムにしていくための

ヒントやガイドラインを、参照アーキテクチャ形式で提供

BCP策定時、災害対策やITシステム見直し時期にご利用ください

第1部 ICHIGAN参照アーキテクチャの使い方


１．ICHIGAN参照アーキテクチャの使い方

自治体の既存の業務・システムとBCPを前提として、以下の活動の実施を想定する。

– ICHIGANで定義したシステム評価シナリオに基づき、既存の業務・システムの

災害対策および業務継続性対応状況の評価を行う。

– 評価結果に基づき、業務・システムの改訂を行う。検討にあたり、ICHIGAN参

照アーキテクチャを活用することが可能である。

上記の活動の主担当として、自治体担当者、および、自治体の担当ベンダーを想定

する。

自治体

既存システム（通常時基幹ｼｽﾃﾑ）（被災時ｼｽﾃﾑ）


評価・分析

ICHIGAN

評価シナリオ

システム改訂

ICHIGAN参照


分析

レポート

自治体担当者

自治体担当ベンダー自治体担当者

自治体担当ベンダー

ICHIGAN

提供物

ICHIGAN

提供物

業務アプリケーションデータインフラユーザー・エクスペリエンスセキュリティ

自治体既存

業務継続計画

地域防災計画

ICHIGAN

コミュニティ

ICHIGAN

コミュニティ


２．アーキテクチャ分析とは・・・

通常時業務の

影響分析通常時業務改訂

被災時業務の

対応状況分析被災時業務構築

アーキテクチャ分析とは

システム方針

ポリシーの設定

自治体

既存システム（通常時基幹ｼｽﾃﾑ）（被災時ｼｽﾃﾑ）


評価・分析

ICHIGAN

評価シナリオ

システム改訂

ICHIGAN参照


分析

レポート

自治体担当者

自治体担当ベンダー自治体担当者

自治体担当ベンダー

ICHIGAN

提供物 ICHIGAN

提供物

業務アプリケーションデータインフラユーザー・エクスペリエンスセキュリティ

自治体既存

業務継続計画

ICHIGAN

コミュニティ

ICHIGAN

コミュニティ


３．アーキテクチャ分析の流れ

II. リスク識別

III. 想定影響定義

IV. 被災システムの

必要性分析

VI. アーキテクチャ分析

想定リスク一覧

被災時の想定業務

評価シナリオ

アーキテクチャ分析レポート

目標業務層

非機能要求

自治体BCP

地域防災計画

ConOPS

V. 業務層非機能要求

の目標定義（NFR）

現行システムモデル

分析シナリオ 1

～3

I. 現行モデル定義

アーキテクチャ分析は以下の流れに従って作業を進めます

それぞれのアクティビティはICHIGANから提供されるテンプレートに基づいて作業します

対応状況分析

業務層非機能要求詳細化

アーキテクチャの精査

を実施


３．アーキテクチャ分析の流れ I. 現行モデル定義

現行のハイレベルなシステムモデルを定義します

以下の項目について関連を記述します –ネットワーク状況やサーバーの配置、ユーザーのロケーションなど

施設（庁舎）

ネットワーク

（回線、ルーター、

ファイアウォールなど）

プレゼン

（PCなど）

プレゼン

（PCなど）アプリ

（サーバーなど）

データ

（ディスクなど）

エンドユーザー

（自治体職員など）

IT担当

（システム運用、

開発ベンダーなど）

施設（データセンター）

アプリ


データ


アプリ


データ


施設

（発電所）

プレゼン

（PCなど） IT担当

（システム運用など）

リスク識別

想定影響定義

被災システムの

必要性分析

アーキテクチャ分析



評価シナリオ


目標業務層

非機能要求自治体BCP 業務層非機能要求



分析シナリオ 1～3

現行モデル定義


３．アーキテクチャ分析の流れ I. 現行モデル定義～情報システム全体の抽象モデル

前頁の現行システムモデルのサブセットとして、以下に示すようなレベルの抽象モデルを作成します

この抽象モデルを参照することで、各機能要素に関する具体的な障害のリスクや非機能要求などを洗い出しやすくします

電気

上水道

下水道

ガス

電話

通信企業

交通機関

道路

鉄道

GS

施設サーバー

アプリ

データ

ネットワーク

プレゼンユーザー

運用担当

事象

ベンダー


３．アーキテクチャ分析の流れ II. リスク識別

自然災害など発生する可能性のある事象を選別します –可能であれば多重災害なども検討を行います –物理的な配置（データセンターの場所など）ごとに検討します

事象発生範囲発生確率発生期間自然災害地震津波噴火土砂災害落雷台風竜巻豪雨・洪水山火事火事磁気嵐パンデミック疫病渇水ブリザード・大雪

政治・社会停電・電力不足交通マヒ輪番休業大規模ネットワーク障害サイバーテロ燃料不足（ガス・ガソリン）爆破テロ暴動・ゼネストクーデター航空機などの墜落放射能汚染戦争宇宙人襲来


地震発生の後、

⇒津波

⇒電力停止

⇒火災発生

⇒通信障害

など

多重災害の例

リスク識別

想定影響定義


必要性分析




評価シナリオ


目標業務層







３．アーキテクチャ分析の流れ III. 想定影響定義

現行のシステムモデル、及び想定リスク一覧を基に、システムモデルのどの構成要素に対して影響が出るのかパターンの整理を行います

影響分析テンプレート（抜粋）

影響パターン施設アプリデータプレゼンネットワークユーザー IT担当備考通常稼動状態稼動稼動稼動稼動稼動出勤可出勤可地域全域機能停止停止停止停止停止停止出勤不可出勤不可

*別地域による復旧カップリング？

施設機能停止停止停止停止停止停止出勤可出勤可*別施設による復旧クラウドへの引越し

システム全面停止稼動停止停止停止停止出勤可出勤可システム業務機能使用不可稼動停止稼動稼動稼動出勤可出勤可

*ホットスタンバイによる復旧*コールドスタンバイによる復旧*停止原因修復後のリスタート*遠隔地での代替機によるリスタート*類似機によるリスタート

データ参照・更新機能使用不可稼動停止稼動稼動出勤可出勤可*ホットスタンバイによる復旧*コールドスタンバイによる復旧*停止原因修復後のリスタート*遠隔地での代替機によるリスタート*バックアップ/レプリカからの修復後リスタート*類似機によるリスタート一部データのみの救済含む*Exportによるデータ救済とメンテ HDDからのデータ救済含む*データの再作成住基データからの再構築

システム内主要構成要素

リスク識別

想定影響定義


必要性分析




評価シナリオ


目標業務層







３．アーキテクチャ分析の流れ IV. 被災システムの必要性分析

自治体BCP、地域防災計画、及び想定リスク一覧を基に、被災時に稼動する必要のある業務をリストアップします

L1 L2

総務・企画・消防部門

住民記録 1.住民基本台帳 2.印鑑登録 3.外国人登録 21.戸籍 30.住登外管理

選挙事務 4.選挙人名簿管理

教育事務 20.就学

市町村税 5.固定資産税 6.個人住民税 7.法人住民税 8.軽自動車税 9.収滞納管理

財務会計 50.財務会計

人事・給与 52.人事給与

庶務 51.庶務事務 52.文書管理

共済・貸付

消防事務

民生・労働・衛星関係

福祉 12.障害者福祉 15.児童手当 16.生活保護

年金・保険 10.国民健康保険 11.国民年金 14.介護保険

医療 13.後期高齢者医療 17.乳幼児医療 18.ひとり親医療 19.健康管理

清掃業務

環境保全業務

商工農林水産部門

土木・建築

その他

緊急・応急時業務

災害・被災情報管理災害情報管理被災者支援情報管理

被災住民記録被災者基本台帳安否確認

被災者支援被災証明義捐・支援金管理犠牲者・遺族管理

避難所・物資管理避難所管理仮設住宅管理緊急物資管理

復旧・復興時業務

復旧・復興計画復旧・復興計画

通常時業務

被災時業務

L3

業務ユニット定義

リスク識別

想定影響定義


必要性分析




評価シナリオ


目標業務層







３．アーキテクチャ分析の流れ V. 業務層非機能要求定義

自治体BCPの定義、及び、ICHIGANが提案する業務層非機能要求分析の枠組みに基づいて、業務上の非機能要求を定義します –業務復旧までXX時間、システム利用者はXXを想定など

アーキテクチャは、機能要求と非機能要求を実現するための構造を定義するものです。従って、アーキテクチャーの評価・分析活動において、非機能要求の定義は最も重要な活動の一つと位置付けられます。

「地方公共団体におけるICT部門の業務継続計画（BCP)策定に関するガイドライン」で定義する

ことが推奨される非機能要求

ICHIGANで提案する、

業務層非機能要求分析の枠組み

（詳細は次ページ参照）

業務層非機能要求

b.業務プロセス

a.業務全体

c.情報

d.インターフェース

BCPガイドライン目標復旧レベル

目標復旧時間

データ目標復旧時点

リスク識別

想定影響定義


必要性分析




評価シナリオ


目標業務層






BCPガイドラインと、

ICHIGANの枠組みを活用


３．アーキテクチャ分析の流れ V. 業務層非機能要求定義～分析の枠組み ICHIGANで提案する、業務層非機能要求分析の枠組みの詳細を以下に示します。

業務層

非機能要求

b.業務プロセス

a.業務全体

c.情報

4.処理時間

5.処理量

10.セキュリティ（情報の保護）

6.可用性

8.情報の保管

7.セキュリティ（実行権限）

1.業務観点の基礎数値

2.業務上の制約

11.利用者要求

d.インターフェース

9.情報の利用（鮮度・断面等）

13.セキュリティ（授受情報の保護）

12.使用容易性

住民数、被災者数、避難所数、などの自治体関連基礎数値

遵守すべき法令／ガイドラインの定義。また、現状の各種制約。

被災証明書発行などの事務処理における要求処理時間

想定被災証明書発行数などの事務処理量

事務処理の実施時間帯、実施日、業務停止許容度などの要求

本人確認、被災証明書発行権限、承認権限などの権限管理要求

被災者情報など情報の保管期間などの要求

住民情報など利用する情報の鮮度、タイミングなどに関する要求

住民情報、被災者情報などの情報の保護に関する要求

想定するシステム利用者種別、および、利用者数。自治体職員、自衛隊、被災者数など。

システムの利用容易性に関する要求。ユーザI/F、ネットワーク環境（３Gネットワークを想定など）、想定利用端末など

画面や証明書に特定の項目は表示しない、などにユーザI/Fにおける情報の保護要求。

【定義する非機能要求の例】

ii. 回復目標

i. サービス時間帯

災害発生時の業務復旧時間などの要求

3.業務上の柔軟性柔軟な変更が想定される業務規定、事務処理準書など


３．アーキテクチャ分析の流れ V. 業務層非機能要求定義～ヒアリングから得られた例

被災自治体の担当者へのヒアリングなどから得られた、業務層非機能要求の例を以下に示します。

業務層非機能要求ヒアリング内容

a.業務全体 2.業務上の制約自治体システムのベンダーロックインが強い。新システムに移行したくとも、制約等が多く、なかなか実現できない。自治体システムの標準化に期待したい。

国、または都道府県レベルで、災害時緊急対応のユニットを作成するべき。

3.業務上の柔軟性現場の判断で、ビジネスルールや業務プロセスが頻繁に変える必要があり、システムが柔軟に対応できる必要がある。業務ロジックが厳格すぎると対応ができない。

廃棄物管理、撤去スケジュール管理などの特殊業務の追加に対応が必要。

b.業務プロセス 6.可用性業務の継続性を考慮すると、ベースとなる手続き・処理や、インタフェースは統一する必要があるのではないか。


本人証明書類や、母子手帳、医療履歴情報など、個人情報が喪失される可能性があり、考慮が必要である。

c.情報 9.情報の利用（鮮度・断面等）

被災時に取得する情報は、手書き情報など、不正確となる可能性が高い。情報の整合性を(事後でも）確保する仕組みが必要と思われる。

d.インターフェース 11.利用者要求システムの利用者が通常時と異なる可能性が高い。代替自治体、警察、消防、自衛隊などの代理業務遂行、被災所などでの訓練されていない住民による操作など

12.使用容易性高齢者や障害者に使いやすいシステムである必要がある。

被災所でのデータ入力は、居酒屋の注文用機器レベルの容易さが求められる。

緊急時の、衛星回線などのナローバンドでの通信を考慮する必要がある。


３．アーキテクチャ分析の流れ VI. アーキテクチャ分析

これまでの分析結果から得られた各種要求の実現について、想定される対策のパターン（分析シナリオ：詳細は後述）に基づき以下のような詳細な分析作業を実施し、分析レポートとしてまとめます –対応状況分析 –業務層非機能要求詳細化 –アーキテクチャの精査

業務層

非機能要求

b.業務プロセ

ス

a.業務全体

c.情報

4.処理時間

5.処理量

10.セキュリティ（情報の保護）

6.可用

性

8.情報の保管


1.業務観点の基礎数値

2.業務上の制約

11.利用者要求

d.インター

フェース

9.情報の利用（鮮度・断面等）

13.セキュリティ（授受情報の保護）

12.使用容易性

ii. 回復目標

i. サービス時間帯

3.業務上の柔軟性

目標業務層非機能要求

影響パターン施設アプリデータプレゼンネットワークユーザー IT担当備考通常稼動状態稼動稼動稼動稼動稼動出勤可出勤可地域全域機能停止停止停止停止停止停止出勤不可出勤不可

*別地域による復旧カップリング？

施設機能停止停止停止停止停止停止出勤可出勤可*別施設による復旧クラウドへの引越し

システム全面停止稼動停止停止停止停止出勤可出勤可システム業務機能使用不可稼動停止稼動稼動稼動出勤可出勤可

*ホットスタンバイによる復旧*コールドスタンバイによる復旧*停止原因修復後のリスタート*遠隔地での代替機によるリスタート*類似機によるリスタート

データ参照・更新機能使用不可稼動停止稼動稼動出勤可出勤可*ホットスタンバイによる復旧*コールドスタンバイによる復旧*停止原因修復後のリスタート*遠隔地での代替機によるリスタート*バックアップ/レプリカからの修復後リスタート*類似機によるリスタート一部データのみの救済含む*Exportによるデータ救済とメンテ HDDからのデータ救済含む*データの再作成住基データからの再構築

システム内主要構成要素

評価シナリオ

L1 L2

総務・企画・消防部門

住民記録 1.住民基本台帳 2.印鑑登録 3.外国人登録 21.戸籍 30.住登外管理

選挙事務 4.選挙人名簿管理

教育事務 20.就学

市町村税 5.固定資産税 6.個人住民税 7.法人住民税 8.軽自動車税 9.収滞納管理

財務会計 50.財務会計

人事・給与 52.人事給与

庶務 51.庶務事務 52.文書管理

共済・貸付

消防事務

民生・労働・衛星関係

福祉 12.障害者福祉 15.児童手当 16.生活保護

年金・保険 10.国民健康保険 11.国民年金 14.介護保険

医療 13.後期高齢者医療 17.乳幼児医療 18.ひとり親医療 19.健康管理

清掃業務

環境保全業務

商工農林水産部門

土木・建築

その他

緊急・応急時業務

災害・被災情報管理災害情報管理被災者支援情報管理

被災住民記録被災者基本台帳安否確認

被災者支援被災証明義捐・支援金管理犠牲者・遺族管理

避難所・物資管理避難所管理仮設住宅管理緊急物資管理

復旧・復興時業務

復旧・復興計画復旧・復興計画

通常時業務

被災時業務

L3

業務ユニット定義

リスク識別

想定影響定義


必要性分析




評価シナリオ


目標業務層






被災時システム（カップリング）

被災時システム

被災時業務情報

被災時業務機能

被災時業務情報(カップリ

ング)

被災時業務機能（カップリ

ング)

データ取得・連携機能

データ復旧・連携機能

分析シナリオ

分析レポート

シナリオ1：通常時システムの災害対策

シナリオ２：被災時システムの立上・活用

シナリオ３：被災時システムのバックアップ対策

第2部 ICHIGAN参照アーキテクチャ概要


４．アプリケーションアーキテクチャ概要アプリケーション・スコープの定義

ICHIGANにおけるアーキテクチャ分析の対象システムは、以下のシステムである。

–通常時基幹システム： APPLICに代表される、通常時自治体業務を支えるシステム

–被災時システム：LASDEC被災者支援システムやSAHANAに代表される、被災時に

要求される自治体業務を支援するシステム

–ブリッジシステム：被災時に通常時基幹システムと被災時システムとの連携を実現

するシステム

突発的なシステム追加に対する実現可能性についても評価する。 –例：累積被曝量管理DBの新規開発、など

通常時基幹システム住民情報、税、etc

ブリッジ

システム被災時システム被災所支援、安否確認



（カップリング）

通常時システム（災害対策・カップリング）

４．アプリケーションアーキテクチャ概要アプリケーションアーキテクチャ概要の想定イメージ

通常時システム

通常時業務

情報


被災時業務

情報

被災時業務情報の反映

災害発生時において、以下の三つのシナリオを考慮したアーキテクチャーを検討する：

シナリオ１：通常時システムの災害対策

ホットスタンバイなどの復旧方式、カップリングなどの方式が考えられる。

シナリオ２：被災時システムの立上・活用

被災自治体内での被災時システム利用、支援自治体での被災時システム利用などが考えられる。

EXPORTファイルの連携、担当者による手動入力などが考えられる。

シナリオ３：被災時システムのバックアップ対策

被災時システムの二次災害対策なども同様に検討する。

ブリッジシステム

通常時業務情報の取込

1.通常時システムの災害対策

２.被災時時システムの立上・活用

３.被災時時システムのバックアップ対策

被災時業務

機能

通常時業務

機能


通常時システムが災害により被害を受けた時の、バックアップシナリオを想定する。

通常システムの災害対策の方法について：

• ホットスタンバイ、コールドスタンバイなどの復旧／カップリング方式をパターン化して検討を行う。

• 特定のデータセンターの被災など、一般的に検討される被災シナリオの適用を基本とし、大規模災害を想定した地域災害規模も考慮した検討を行う。

遠隔地でバックアップを稼動させる場合、カップリングした場合などに、必要なアプリケーション上の留意点、必要となるコンポーネント（業務機能、データ要素、プレゼンテーション機能など）の特性などについて、方式パターンごとに今後整理を行っていく予定です。(以降のシナリオにおいても同様です。）


（カップリング）通常時システム

通常時業務

情報通常時業務機能

通常時業務

情報(カップリング)

通常時業務

機能（カップリング)



５．アプリケーションアーキテクチャ想定シナリオシナリオ１：通常時システムの災害対策


ブリッジシステム

被災時（応急期）のみに実施が求められる自治体業務を支える、被災時システムの立上および利用におけるシナリオを想定する。

• 被災者管理システム

• 被災所支援システム、など

通常時システムから被災時システムへの情報連携の方式パターンの整理が必要となる

• 住民基本台帳や税などの情報を想定する

• 方式パターン例： • データのExport / Import による連携

• 印刷出力を手動でデータ転記、など

• ビジネスルールやポリシーを連携できる仕組みの必要性の検討

被災時業務で作成・更新した情報を、被災時システムから通常時システムに反映させる仕掛け

• 手作業反映、データロード、リラン、など



被災時業務

機能

通常時業務

機能

データ抽出

機能(通常)

データ変換

機能

データ取込

機能(被災)

データ抽出

機能(通常)

データ取込

機能(被災)

通常時業務

情報

被災時業務

情報

被災時業務情報の反映

通常時業務情報の取込

５．アプリケーションアーキテクチャ想定シナリオシナリオ２：被災時システムの立上・活用


二次災害などで、被災時システムが被害を受けた時の、バックアップシナリオを想定する。

被災時システムのバックアップ方式パターンの検討を行う

• システム障害などで、自治体既存の被災時システムが稼動しない場合

• 被災時システムが二次災害にあい、建屋などが被災した場合


（カップリング）


被災時業務

情報

被災時業務

機能

被災時業務

情報(カップリング)

被災時業務

機能（カップリング)



５．アプリケーションアーキテクチャ想定シナリオシナリオ３：被災時システムのバックアップ対策


ご清聴ありがとうございました


参照資料

LASDEC –自治体クラウド開発実証に係わる標準仕様書（平成21年度版）ドラフト版

APPLIC –防災業務アプリケーションユニット標準仕様 V1.0 (APPLIC-0003-

2009) –アーキテクチャ標準仕様 V2.1

総務省 –地方公共団体におけるICT部門の業務継続計画（BCP)策定に関するガイドライン

内閣府 –地震発生時における地方公共団体の業務継続の手引きとその解説

SAHANA –オープンソースの災害時救援情報共有システム

ichigan 参照アーキテクチャ

Technology