別冊１ 大規模自治体クラウド化モデル

別冊１
大規模自治体クラウド化モデル

2016 年 4月1日

別冊１ 大規模自治体クラウド化モデル
はじめに

本書はクラウド推進検討会議

報告書「第 1 編

大規模自治体クラウド化モデル」の別冊１として「大規模自治体クラウド化モデル」の内容をまとめたものである。


大規模自治体クラウド化モデルは、「先行事例をモデル化して設定したゴール」を表すドキュメントと「自治体の現状からゴールに至るやり方」を表すドキュメントに分類される以下の 4 つで構成される。
・基本的な考え方
・仕様
・行動計画
・ノウハウ集

各構成の内容は以下の通りとする。


基本的な考え方…「アーキテクチャ」
「運用」
「調達」
「体制」の観点から、大規模自治体クラウド化モ
デルにおける共通基盤と業務アプリケーションの基本的な考え方をまとめたもの（資料１．大規模自治体クラウド化モデルの基本的な考え方）

仕様…基本的な考え方を踏まえ、システム構成等の要件と仕様をまとめたもの（資料２．大規模自治体クラウド化モデルの仕様）



行動計画…大規模自治体の現在のシステム環境からゴールに至るまでの作業フローと作業の留意点をまとめたもの（資料３．大規模自治体クラウド化モデルの行動計画）



ノウハウ集…行動計画の作業留意点のうち、実現を阻むと思われる課題に関する解決方法をまとめた
もの（資料４．大規模自治体クラウド化モデルのノウハウ集）

別冊１ 大規模自治体クラウド化モデル

資料１．大規模自治体クラウド化モデルの基本的な考え方

資料１
大規模自治体クラウド化モデルの基本的な考え方

大規模自治体クラウド化モデルの基本的な考え方（１）アーキテクチャ 「共通基盤」と「業務アプリケーション」を分離し、「共通基盤」上に「業務アプリケーション」を搭載、もしくは「業務アプリケーション」が「共通基盤」の機能を利用する•共通基盤において、共通部分を一元管理する•ハードウェア、ミドルウェア＊１の統合化・仮想化を行う
 地域情報プラットフォーム標準仕様に準拠する共通基盤と業務アプリケーションの構成イメージ業務
業務（分野）

業務（分野）

業務アプリ
業務アプリ

業務アプリ
業務アプリ

同じ分野の業務アプリケーションをまとめて導入する場合も想定されるため、業務の単位は自治体の方針によって異なる。

ミドルウェア（個別）

共通基盤
統合運用
管理機能

業務間のデータ連携基盤
ミドルウェアの統合

ミドルウェアの統合

ハードウェアの統合

ハードウェアの統合

ハードウェア、ミドルウェアの統合範囲
については、業務アプリケーションのハードウェア、ミドルウェアを含む場合と含まない場合が想定されるため、各自治体が、現状のシステム等の状態をふまえ最適な統合範囲を選定する。

＊１．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

資料１
大規模自治体クラウド化モデルの基本的な考え方（２）調達 「共通基盤」と「業務アプリケーション」の調達を分ける。また、「業務アプリケーション」は業務ごとに調達を分ける（３）運用 「共通基盤」の運用については、統一的な運用を行う
 コストに留意した最適なデータセンタを選定する

（４）体制
【自治体】
 「情報システム所管課」、「業務所管課」
 上記を取りまとめるクラウド推進部会を置く※首長等の決定権を持つ者を含んだ組織とする
 関係部署には、財政部門、人事部門も含む【事業者】
 「基盤事業者」、「業務アプリケーション事業者」、「運用事業者」

別冊１ 大規模自治体クラウド化モデル

資料２．大規模自治体クラウド化モデルの仕様

資料２
大規模自治体クラウド化モデルの仕様
№ 区分①
区分②
―
1 アーキ 全体
テク
チャ

要件
共通基盤と業務アプリ ―ケーションが分離した構成となっていること

詳細区分

2

3

補足

共通基盤で提供するソフトウェアは、業務間で共通に必要 ・業務アプリケーションで重複して装備することを防となる機能とする。
ぐ。
共通基盤

ハード 共通基盤上のハード ―ウェア ウェアは統合化を行っていること
共通基盤上のハード
ウェアについて、ダウンタイムを極力短くす
ること

4
5

DBサーバ

統合化範囲は、共通基盤に装備されるソフトウェアが使用 ・ライセンス体系等のコスト面を考慮すること。
するハードウェア及び可能な範囲の業務アプリケーションのハードウェアとする。
部品を冗長化＊１する。
障害時でも業務が継続できるような策を講じる。

Web／APサーバ

6
7

ストレージ（バックアップ装置含む）

9

・アクティブ／アクティブ構成、アクティブ／スタンバイ
構成、といった方法がある。

部品を冗長化する。
障害時でも業務が継続できるような策を講じる。

8・アクティブ／アクティブ構成、アクティブ／スタンバイ
構成、といった方法がある。

部品を冗長化する。
可用性確保のため、コントローラ、スペアディスクなどの部品交換やディスク増設など、オンライン中に運用を止めることなくメンテナンスを行えるような構成とする。

10

コストと性能の最適化 ストレージ（バックが図られていること
アップ装置含む）

11

ストレージ（バックアップ装置含む）

12

ソフト 共通基盤上のソフト
データ連携基盤ウェア ウェアは統合化を行っていること
ジョブ管理機能13仕様
共通基盤は、業務アプリケーションが動作するのに必要となるハードウェア、ソフトウェア等を提供する。

価格と性能とのバランスを考慮したディスク構成とする。

・実現方法の例として、階層型ストレージがある（アプリケーション側からは１つのストレージとしてアクセスでき、管理が効率化できるため）。階層型ストレー
ジにする場合は、性能／信頼性の高い高性能スト
レージと、コストパフォーマンス重視のニアラインスト
レージ＊２を組み合わせた構成となる。
※各ディスクへのデータ配置の例は以下の通り。
①高性能：利用頻度が高く高速なアクセスが要求されるデータ（DB／業務データ領域等）②ニアライン：利用頻度が低いデータ（保存ログ領域等）

大量データのバックアップを時間内に完了させる。

・実現方法の例として、差分情報を使ったバックアップ方法等がある。

業務アプリケーション間で連携する情報は、データ連携基
盤を介した連携とする。
業務アプリケーションについて、ジョブの一元管理を行う。 ・ジョブ管理機能を一元化する際は、業務アプリケー
ション側に改修が必要となる場合がある。そこで、各団体において自団体の状況等に応じて装備する範囲を検討する必要がある。

14

統合運用管理機能 共通基盤と業務アプリケーションの、生存監視、プロセス
監視、リソース監視、ログ監視等の稼働監視を行う。

15

ユーザ認証機能

業務アプリケーションは、ユーザ認証機能を利用して、シングルサインオンを実現する。

16

APPLICの標準仕様に データ連携基盤
準拠した方式で、デー
タ連携を行っていること

地域情報プラットフォーム標準仕様に準拠した業務アプリ
ケーション間連携を実現する。

17

最小限のサーバ、スト ―レージとなること

ハードウェアリソースの最適な配分を行うため、仮想化技 ・ライセンス体系が仮想化に対応していないミドル
術を用いる。
ウェア＊３の場合、そのミドルウェアが搭載された物
理サーバの全コア数（当該ミドルウェア以外も含め）のライセンスが必要になる。そこで、ライセンス数の無駄を省くために、同一の物理サーバに集約することを仕様とする。

18

信頼性を考慮した配置 ―となっていること

共通基盤及び統合化対象の業務アプリケーションに対しては、システム規模に応じて割り当てを行うが、信頼性を考慮した配置とし、ロードバランサによる負荷分散、信頼性の確保を行う。

「業務アプリケーショ ―ン」は「共通基盤」の機能を利用すること

業務アプリケーションは、共通基盤の機能を利用する。

APPLICの標準仕様に ―準拠していること

地域情報プラットフォーム標準仕様に準拠していることを前提とする。

19

20

業務ア ―
プリケー
ション

・ユーザ認証機能を一元化する際は、業務アプリ
ケーション側に改修が必要となる場合がある。そこ
で、各団体において自団体の状況等に応じて装備する範囲を検討する必要がある。

・業務アプリケーションのシステム導入ではなく、サービス利用の形態とする場合も、共通基盤の機能を利用することとする。

資料２
大規模自治体クラウド化モデルの仕様
№ 区分①
区分②
21 運用
全体
―

要件
マルチベンダ＊４環境 ―での役割分担・責任分担を明確にし、共通基盤から業務アプリケー
ションまで一環した運用方針の統一化を行っていること

詳細区分

仕様
運用方法について、統一的なルールを定める。

補足

22

コストの最適化につい データセンタても注意し、最適なデータセンタを選定し
ていること

―

・設備、運用に関する各要件に合致したデータセンタ
とする。

23 調達

全体

―

「共通基盤」と「業務ア ―プリケーション」の調達が分かれていること―・「共通基盤」、「業務アプリケーション」の順で調達を
行う。

24

業務ア ―
プリケー
ション

業務アプリケーション ―は業務ごとに調達すること―

・「業務アプリケーション」の調達は、パッケージシス
テムを前提とする。
・カスタマイズの極小化に留意してパッケージを選定
する。

25 体制

全体

基盤事業者、業務アプ 基盤事業者
リケーション事業者、運用事業者の役割が明確になっていること

共通基盤の開発・保守を行う。

26―

共通基盤の仕様・機能に関する「業務アプリケーション事業者」への情報提供を行う。

27

業務間のデータ連携に関して、データの受信側、送信側とそれぞれ調整する。

28

統合化対象の業務アプリケーションに対しては、共通基盤への業務アプリケーションの組み込み、及び受け入れ評
価は、各業務アプリケーション事業者が個別に実施するのではなく、定められた事業者のみが行うようにする。

29

業務アプリケーショ 業務アプリケーションの開発・保守を行う。
ン事業者

30

他業務アプリケーションとのデータ連携に関して、「基盤事業者」と調整する。

31

統合化対象の業務アプリケーションに対しては、共通基盤への業務アプリケーションの組み込みと、受け入れに関する支援を行う。

32

運用事業者

・障害発生時の一次切り分けは「運用事業者」が行うこととするが、原因特定までに、切り分け自体ができない、時間がかかるといったことがないよう留意する。

システム全体の運用に係る業務を行う。

＊１．冗長化：システムの設備や部品等に予備を備えておき、一部に故障が発生しても、システム全体は継続して稼働できるようシステムを構築すること。
＊２．ニアラインストレージ：高速なアクセスが求められるオンラインストレージと、データのバックアップ等に用いられるオフラインストレージとの中間に位置する
オンラインストレージ。
＊３．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊４．マルチベンダ：複数のベンダの製品を組み合わせてシステムを構築すること。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

別冊１ 大規模自治体クラウド化モデル

資料３．大規模自治体クラウド化モデルの行動計画

資料３（１）．行動計画（作業フロー）
資料３（２）．行動計画（作業項目一覧）

作業項目の一覧

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）【期間の目安】Ａ 基本計画６ヶ月～１年程度

Ａ－１ 推進体制の立ち上げ※専従者の人数
等によって期間は異なる。
※予算編成時期との兼ね合いが重要。

Ａ－２ 現行システム概要調査
Ａ－３ システム全体最適化方針の検討
Ａ－４ システム刷新後の概要整理（共通基盤、業務アプリケーション、運用）
Ａ－５ 費用対効果の検討（概算）Ａ－６ 基本計画書の作成★

Ｂ 要件定義７ヶ月～１７ヶ月程度

Ｂ－１ 現行業務の棚卸し
Ｂ－２ 現行システムの棚卸し
Ｂ－３ 改善課題の整理
Ｂ－４ ＲＦＩ＊１の作成★

※条例や規則の改正については、議会スケジュールとの兼ね合いが必要となる。

Ｂ－５ 業務標準化の検討
Ｂ－６ パッケージ適用判断
Ｂ－７ システム刷新後の要件整理（共通基盤、業務アプリケーション、運用）
Ｂ－８ 費用対効果の検討（予算化）Ｂ－９ 条例・規則等の影響調査・改正★

Ｂ－１０ 新システム調達仕様書の作成★

Ｂ－１１ 事業者選定、契約締結★

Ｃ 設計・構築
Ｃ－１ システム設計・構築（共通基盤、業務アプリケーション、運用）
Ｃ－２ データセンタ移行
Ｃ－３ データ移行
Ｃ－４ テスト・研修

１年～２年９ヶ月程度※共通基盤や業
務アプリケーションの構築を行うかどうかによって期間は異なる。

★：当作業については、作業完了後の内容変更は不可能、もしくは変更による影響範囲が大きいため、作業完了には
庁内での意思決定が必要となる。
＊１．ＲＦＩ：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ａ 基本計画ある

全庁的な推進体制がすでにできているか？
なし又は不十分

Ａ－１ 推進体制の立ち上げある

現行システムの設計書など整理された資料があるか？
なし又は不十分

Ａ－２ 現行システム概要調査

Ａ－３ システム全体最適化方針の検討

Ａ－４ システム刷新後の概要整理

Ａ－５ 費用対効果の検討（概算）

投資に対して十分な効果が見込
めるか？
効果あり

効果少ない

システム全体最適化
方針の見直しＡ－６ 基本計画書の作成【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

Ｂ 要件定義へ資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｂ 要件定義ある

現行の業務（システム）を整理した資料があるか？
なし又は不十分

Ｂ－１ 現行業務の棚卸し

Ｂ－２ 現行システムの棚卸し
Ｂ－３ 改善課題の整理※ＲＦＩの作成は、「Ｂ－３ 改善課題の整理」の後、「Ｂ－１０ 新システム
調達仕様書の作成」までのいずれかのタイミングで適宜実施する。

なし

ＲＦＩの作成を行う必要があるか？
あり

Ｂ－５ 業務標準化の検討
Ｂ－６ パッケージ適用判断
Ｂ－７ システム刷新後の要件整理

Ｂ－４ ＲＦＩの作成
Ｂ－８ 費用対効果の検討（予算化）※ＲＦＩで得た情報は、適宜、「Ｂ－６ パッケージ適用判断」「Ｂ－７ システム刷新後の要件整理」「Ｂ－８ 費用対効果の検討（予算化）」の作業に活用する。

効果少ない投資に対して十分な効果が見込めるか？
効果あり

業務標準化の再検討、システム刷新後の要件見直し

Ｂ－９ 条例・規則等の影響調査・改正

Ｂ－１０ 新システム調達仕様書の作成

Ｂ－１１ 事業者選定、契約締結【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

Ｃ 設計・構築へ資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築
Ｃ－２ データセンタ移行
Ｃ－３ データ移行
Ｃ－４ テスト・研修【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築※「Ｃ－１ システム設計・構築」工程内の「共通基盤」「業務アプリケーション」「運用」に係る作業はそれぞれ並行して実施する。

１．共通基盤

1.1 ハードウェア
1.2 ソフトウェア

２．業務アプリケーション

2.1 リビルド＊１
2.2 リビルド・リホスト＊２共通

３．運用

3.1 稼働維持作業
3.2 業務アプリケーション対応※各作業の詳細な作業について、次ページ以降に記載する。

＊１．リビルド：メインフレームをオープン化する際に、既存のシステムを廃止し新しい業務アプリケーションを導入すること。
＊２．リホスト：オープン化済みの業務アプリケーションを、共通基盤に対応させること。

【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築
１．共通基盤
1.1 ハードウェア
1.1.1 ＤＢサーバ、Ｗｅｂ／ＡＰサーバ、
ストレージ（バックアップ装置含む）、ネットワーク①方針検討②設計・構築（環境構築）

1.2 ソフトウェア
1.2.1 統合化
①方針検討

②設計・構築

1.2.2 仮想化
①方針検討

②机上でのサイジング③実機でのサイジング

④構築

【凡例】
：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築
１．共通基盤
1.2 ソフトウェア
1.2.3 ジョブ管理機能①方針検討②設計・構築

1.2.4 データ連携基盤①方針検討②設計・構築

1.2.5 ユーザ認証機能①方針検討②設計・構築【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築
２．業務アプリケーション
2.1 リビルド
2.1 リビルド①方針検討②設計・構築2.2 リビルド・リホスト共通
2.2.1 データ連携基盤対応①方針検討②設計・構築【凡例】：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（１）
大規模自治体クラウド化モデルの行動計画（作業フロー）
Ｃ 設計・構築
Ｃ－１ システム設計・構築
３．運用
3.1 稼働維持作業
3.1 稼働維持作業
①方針検討

②運用設計

3.2 業務アプリケーション対応
3.2 業務アプリケーション対応
①方針検討

②運用設計

【凡例】
：実施する作業：作業の流れを表す：作業内容の補足事項

資料３（２）大規模自治体クラウド化モデルの行動計画（作業項目一覧）

項
番

作業項目

留意事項

ー
ー

ー
ー

ー

【凡例】○･･･作業実施、―･･･作業
対象外
自治体のパターン別
該ノ
作業項目
当ウ
・ パ ・ ・ パ ・ ・ ・ パ 課ハ
メ タ 共オ タ 自共オ タ 題ウ
集
庁通
イ
通
の
ン ン 基 プ ン 設基 プ ン
フ ① 盤 ン ② 置盤 ン ③
レ
未化
導化
導済
入済
入
済
ム
み
残
存
ー

1 【全体】

・複数の部署が実施する作業については、並行作業となるため、作業の進め方には注意が必要となる。また、他の部署へ作業を依頼する場合、依頼先部署において作業の準備（作業内容の理解など）が必要となるため、スケジュールの策定において考慮が必要となる。

2 A 基本計画
3
A-1 推進体制の立ち上げ

・トップダウンで大きな方針を打ち出すには首長、ＣＩＯ等の幹部の理解を得ることが有効である。可能であれば、首長、ＣＩＯを推進体制のトップにする。
・コスト分析の観点から財務部門を組み込むことが必要。
・効率的な人材配置の観点から人事部門を組み込むことも必要。
・企画部門及び情報政策部門で取り纏め（事務局）を担う。
・電算部門にはある程度のスキルを持った職員を配置、推進していくことが必要。
・他団体との共同利用の場合、共同利用のための協議会の立上げ作業自体が高負荷となることも想定されるため、例えば、協議会を立ち上げるのではなく、協定書に基づいて検討を開始する、といった方法も有効である。

○

○

○

4

A-2 現行システム概要調査

以下の項目について整理が必要となる。
①現行導入システム一覧（システム名称、所管課） ：現在のシステム化対象業務を明らかにして、クラウド化範囲を検討するために必要②開発形態（自己開発、共同開発、パッケージ導入等（なお、パッケージ導入の場合はパッケージ名も整理する）） ：同一パッケージの自治体ごとにクラウド化する等の検討に必要③システム構成、ハードウェア設置場所 ：可用性等のコスト以外の効果試算に必要（現在、シングル構成がマルチ構成になり稼働率が上がる、バック
アップ等BCPが向上する等々）④利用ネットワーク状況 ：クラウドサービスの利用ネットワーク検討に必要⑤システム連携状況 ：密連携のシステムは、丸ごとクラウド化の方が得策⑥システム稼働日・更新予定日（ライフサイクル） ：クラウドサービス開始時期の検討に必要⑦構築及び運用の体制（事業者名を含む） ：運用体制のスリム化等の効果
試算に必要⑧構築及び運用、改修に係る経費 ：コスト削減効果の試算に必要⑨運用・保守内容（パンチ入力、帳票出力、ヘルプデスク） ：システムだけ
でなく付帯業務のアウトソース化の検討に必要

○

○

○

5

A-3 システム全体最適化方針の検討

・目標を明確にする。
（例：ＩＣＴ経費の削減○○％、など）

○

○

―

6

A-4 システム刷新後の 共通基盤
概要整理

①まずオープン化だけを行ってしばらく稼働した後で、クラウド化を行う段階
的実施と、一気にクラウド化まで行う方式がある。
②ハードウェア（APサーバ、DBサーバ、ストレージ）やミドルウェア＊１の統合
化の範囲を検討する。
③すでにオープン化された業務システムの前提ＯＳやミドルウェア、稼働年数等を考慮して、リホスト＊２（既存のアプリケーションを共通基盤に移植）にすべき業務を判断する。
④監視、ジョブ管理、印刷管理、等の運用業務のうち何を統合化するかを決
める。

○

○

―

7

業務アプリケーション

○

―

―

8

運用

○

○

○

○

○

○

○

○

○

○

―

―

9

A-5 費用対効果の検討（概算）10A-6 基本計画書の作成

・オープン化、クラウド化終了までの複数年度の予算を見積る。
・オープン化、クラウド化後の運用経費も見積る。
・並行稼働期間を考慮する。

11 B 要件定義

・要件定義以降は、外部のコンサル業者に作業を委託する方法もある。
・調達プロセスの標準化を行うことにより、情報システムの調達を担当する職員が、情報システムに関する深い知識がない場合でも標準的な調達手法を実施することができる。さらに、調達プロセスを標準化することにより、職員が情報システムの調達作業を行う際に他職員などからアドバイスを受けやすくなることに加えて、事業者が自治体の調達プロセスを理解して適切な時期に適切な提案・見積を提示することができるようになるという効果も期
待できる。

12

・業務改善ができないかを検討する。大規模自治体で実績のあるパッケー
ジをできるだけ多く調査し、業務改善のヒントを見つけることも可能。
・自治体独自の機能と大規模自治体一般で必要な機能の区分を明確化する。

B-1 現行業務の棚卸し

資料３（２）大規模自治体クラウド化モデルの行動計画（作業項目一覧）
項
番

作業項目

留意事項

ー
ー

ー
ー

ー

【凡例】○･･･作業実施、―･･･作業
対象外
自治体のパターン別
該ノ
作業項目
当ウ
・ パ ・ ・ パ ・ ・ ・ パ 課ハ
メ タ 共オ タ 自共オ タ 題ウ
集
庁通
イ
通
の
ン ン 基 プ ン 設基 プ ン
フ ① 盤 ン ② 置盤 ン ③
レ
未化
導化
導済
入済
入
済
ム
み
残
存
ー

○

○

―

13

B-2 現行システムの棚卸し

14

B-3 改善課題の整理

15

B-4 ＲＦＩ＊３の作成

・ＲＦＩの作成は、「B-3 改善課題の整理」の後、「B-10 新システム調達仕様書の作成」までのいずれかのタイミングで適宜実施する。
・情報提供を要請するべき事項として以下のような項目がある。
①機能要求の実現可否（カスタマイズの要否および業務適合率等）②要求機能の実現に係るカスタマイズ費用③システム構築、運用・保守に係るライフサイクルベースでの費用④制度変更や新サービス導入への対応に係る費用⑤その他、参加団体の懸案事項に対する提案

○

○

○

16

B-5 業務標準化の検討

・業務標準化の際は、以下のような点が阻害要因となるため事前に対策が必要。
①現行の業務プロセスを見直すBPRへの意識が十分でない②担当業務に特化した「個別最適化」の観点が強く「全体最適化」への意
識が低い
・業務標準化が十分に進まないと、以下のような影響が予想される。
①法制度改正等の際の改修費への影響（費用がかさむ主要因となる）②システム改修時・更改時の際の正常稼働への影響（カスタマイズの多さ
が品質低下の要因となる）

○

―

―

17

B-6 パッケージ適用判断

・パッケージが適用可能かどうか、以下のような手順で整理する。
①FIT＆GAP分析の実施-RFI及びヒアリング等により、パッケージソフトの適合率、カスタマイズ
対応の可否及び経費等を把握する。併せて運用での対応の具体的な可能性を探る。
-できるだけ多くの自治体が採用している事業者の参加を得ることが重要。
②業務フロー図等の作成・整備-業務の「見える化」、BPR推進の観点から、AsIsで作成しToBeへと深化させることが重要。
③カスタマイズに対する見方を変える-軽微なものについてはEUCでの対応も検討する。
④パッケージの標準仕様への取込みを促す-パッケージに不足する機能が、自団体だけでなく他団体でも必要と思われる場合は、パラメータ設定での対応が可能となるように、事業者への働きかけを図る。
→ノウハウ集№9

○

―

―

18

B-7 システム刷新後の 共通基盤
要件整理
業務アプリケーション

○

○

―

○

―

―

○

○

○

19
20

・リソース消費状況については、ＣＰＵ利用率、メモリ利用率等の状況をピー
ク時、閑散期等に分けて調査することが望ましい。
・運用については、統合化がどこまでされているか、監視だけでなくジョブや印刷の統合化状況含めて調査する。

○

運用

―

21

B-8 費用対効果の検討（予算化）・必要に応じて、事業者から見積りを取る。
・契約方法についても検討する。ＳＬＡ＊４に基づくサービス契約と従来の業務委託契約ではコストのかかり方が異なる。
・サービス契約であれば、サーバ更新時の初期費用がかからない（月額で一定の使用料負担）ため、コストが平準化される。
・費用対効果の定量評価では、コスト回収期間を設定し、その期間に投資コストが回収できるかどうかが一つの目安となる。例として、機器のリース期間
やメーカのサポート期間などから、情報システムが稼働からおおよそ5年程度で更新時期を迎えることが多いと考えられるため、コスト回収期間を5年間を単位として設定するといった考え方ができる。

○

○

○

22

B-9 条例・規則等の影響調査・改正・条例等の改正に当たっては、パブリックコメントや審査会等、一定期間を要する手続きが必要となる。

○

○

○

№9

資料３（２）大規模自治体クラウド化モデルの行動計画（作業項目一覧）
項
番

作業項目

留意事項

ー
ー

ー
ー

ー

【凡例】○･･･作業実施、―･･･作業
対象外
自治体のパターン別
該ノ
作業項目
当ウ
・ パ ・ ・ パ ・ ・ ・ パ 課ハ
メ タ 共オ タ 自共オ タ 題ウ
集
庁通
イ
通
の
ン ン 基 プ ン 設基 プ ン
フ ① 盤 ン ② 置盤 ン ③
レ
未化
導化
導済
入済
入
済
ム
み
残
存
ー

23

B-10 新システム調達仕様書の作成

24

B-11 事業者選定、契約締結

・共通基盤と業務アプリケーションを別発注とする。
・業務アプリケーションは段階的に発注することで、ノウハウを蓄積することが出来る。
・調達仕様書には、利用者数（端末数）やデータ件数はもとより、性能要件（検索時の応答時間など）や信頼性要件（稼働率など）についても具体的な数値を記載することにより、事業者の間で見積りの精度にばらつきが少なくなり、より公平な競争を促すことができるようになる。ただし、信頼性要件やセキュリティ要件をあまり厳しくすると、業務の重要性以上に過剰な性能・機能を持った高価な情報システムを導入することにもなりかねないため留意が必要。
・事業者の提案を評価する評価基準については、事業者向けに公開した評
価基準をさらに詳細化した内部審査用の評価基準書（非公開で可）を前もって作成し、審査に望むとよい。この内部審査用評価基準は、提案書の評価のみならず、内部での説明資料としても利用することができる。
・共通的な調達仕様書を整備することにより、調達仕様書を作成する部署が異なる場合でも調達するシステムが個別最適になることを防ぎ、ＩＴガバナンスの確立を図る。

25 C 設計・構築
26
C-1 システム設計・構築（共通基盤、業務アプリケーション、運用）
1
1.1
1.1.1
①方針検討 ・現状のシステムについて、業務規模（対象人数、事務件数など）やデータ
27
共通基盤 ハードウェ ・DBサーバ件数を調査する。事務件数については、通常期と繁忙期のそれぞれの値もア・Web／APサーバ必要となる。
・ストレージ（バック28②設計・構築 ・大量データを扱う場合、ストレージIOがボトルネックになりやすく、業務アプ
アップ装置含む）（環境構築） リケーションの性能に問題が発生した際の切り分けが難しくなるため、ボトル
・ネットワーク
ネックにならないような構成とする。
→ノウハウ集№5

29

1.2.1
1.2
ソフトウェ 統合化
ア

○

○

○

○

○

○

○

○

―

○

○

―

№5

・共通基盤については高信頼性を確保する必要があるため、部品レベルの二重化を行っているサーバを採用して高信頼性を確保する。また、論理ＣＰ
Ｕ・メモリ割当て等のサイジングは安全優先とする。
→ノウハウ集№6№6・セキュリティを高めるため、業務内容に応じて、ハイセキュアエリア、ミドル
セキュアエリアを設置し、セキュリティエリア間の直接の通信は原則不許可とする。また、各エリアをさらにVLAN＊５等でセグメント分割し、許可されない通信が行えないようにする。
→ノウハウ集№7№7①方針検討 ・現状の業務システムについて、OS、DB、開発言語などの基本的事項を調査する。OS、DBについては、バージョン、エディション等の調査も必要。各業
務システムの状況を踏まえて、全体の方針を検討する。
→ノウハウ集№1

○

○

―

№1

②設計・構築①方針検討 ・各業務システムの現状と移行方針（リビルド＊６（再構築）、リホスト（既存のアプリケーションを共通基盤に移植）を整理した上で、あらかじめ決定した仮想化方式の判断フローに基づき、仮想化方式を検討する。
→ノウハウ集№2

○
○

○
○

―
―

№2

②机上での
サイジング

○

○

―

№3

・ミドルウェアを統合する場合、業務システムによってはミドルウェアのバー
ジョンアップを行う必要がある。バージョンアップに対応するには、コンバー
ジョンや動作確認の作業が発生するため、業務システムの状況（大きな法改正が予定されているなど）も踏まえて、バージョンアップするかどうか、などの方針を検討する。
→ノウハウ集№1
30
31

32

1.2.2
仮想化

・リホスト（既存のアプリケーションを共通基盤に移植）の場合、ベンチマーク
値（SPECINT＊７）等で新旧サーバスペック変換を行い、仮サイジングする。
→ノウハウ集№3
・論理サーバの配置の際は、ピーク性や信頼性を考慮する。
→ノウハウ集№3№4

・仮想空間上への配置の仕方によって割高になるミドルウェアもあるため、配置の検討の際は留意する。
→ノウハウ集№4
33

③実機での
サイジング

34

④構築

・リソースを最小限に抑え、かつ、稼働後にリソース不足などの問題がおこらないようにするために、評価環境でのベンチマークテストを行い、仮サイジン
グの想定と同様か確認を行った上で、サイジングを行う。

○

○

―

○

○

―

資料３（２）大規模自治体クラウド化モデルの行動計画（作業項目一覧）
項
番

作業項目

留意事項

ー
ー

ー
ー

ー

【凡例】○･･･作業実施、―･･･作業
対象外
自治体のパターン別
該ノ
作業項目
当ウ
・ パ ・ ・ パ ・ ・ ・ パ 課ハ
メ タ 共オ タ 自共オ タ 題ウ
集
庁通
イ
通
の
ン ン 基 プ ン 設基 プ ン
フ ① 盤 ン ② 置盤 ン ③
レ
未化
導化
導済
入済
入
済
ム
み
残
存
ー

35
36

1.2.3
ジョブ管理機能①方針検討②設計・構築 ・バッチジョブの登録の際など、ジョブ管理機能を利用したことのない事業者への配慮（簡易な入力シートを配布するなど）が必要となる。
・ジョブ管理機能に合わせて、バッチジョブに対する制約事項や機能の切り分けなどを明確にしておく。（処理結果の出力内容や方式、バッチの排他などジョブ実行に関するルールの決定は誰が行うか、など）
・バッチジョブに対する制約事項や機能間の切り分けなどのルール説明を、運用工程での業務アプリケーション事業者への説明時に実施する。

○
○

○
○

―
―

37

1.2.4
データ連携基盤①方針検討 ・データ連携は、データの送信側と受信側で、連携の方式や連携するデータ
項目などの調整が必要となる。しかし、それぞれの業務アプリケーション事
業者が直接調整をすると時間がかかるため、基盤事業者が統一した手順、整理用のシートなどによってそれぞれの事業者と調整する。
→ノウハウ集№8○○―②設計・構築 ・設計時に、各業務アプリケーション側に、連携すべきデータをヒアリングする工程を設ける。テストでは、業務アプリケーション間の連携をすべて確認するため、期間を長めにとる。

○

○

―

①方針検討
②設計・構築①方針検討 ・適切なパッケージの選定が重要である。できるだけ大規模自治体や政令指定都市への導入実績のあるパッケージを選定する。
→ノウハウ集№9

○
○
○

○
○
―

―
―
―

②設計・構築
2.2.1
2.2
①方針検討
リビルド、 データ連携基盤対 ②設計・構築 ・リホストは基本的に共通基盤への載せ替えだけであり、開発は発生しない
が、データ連携対応等の共通基盤への対応が必要となる。
リホスト共 応
通

○
○
○

―
○
○

―
―
―

3.1
稼働維持作業

○

○

○

№8

・段階的な移行を行っている場合、一部メインフレーム＊８が残存している場合がある。その際は、メインフレームとオープンシステム間の連携についても検討する。
→ノウハウ集№8
・統合DBを用いてデータ連携を行なう場合、統合ＤＢの更新スケジュールの調整が重要となる。連携（更新）数などが増えると時間内に処理が収まらない可能性もあるため、スケジュールの組み方等についても調整が必要にな
る。
38

39
40
41

1.2.5
ユーザ認証機能2
2.1
業務アプ リビルド
リケー
ション

№9

・最適なパッケージを選定しても、要望する機能が不足する可能性はある。
そこで、他の団体規模でも必要な標準機能と団体独自機能の分類を明確にし、必要な標準機能については、業務アプリケーション事業者と標準機能追加（機能強化）の交渉を行なうことで、カスタマイズを抑制する。
→ノウハウ集№9
42
43
44

45

3
運用

①方針検討 ・運用の統一ルールを定めるが、各事業者がそのルールに容易に則れるようにする。例えば、バッチジョブの登録の際など、ジョブ管理機能を利用したことのない事業者へ配慮（簡易な入力シートを配布する）など。 また、事前に、業務アプリケーション事業者に説明する。
→ノウハウ集№10、ノウハウ集№11№12・マルチベンダ＊９環境の場合、実際に障害が発生した際に、安易に自分以外の関係者側の課題であると判断してしまう可能性がある。障害発生時の一次切り分けについても役割分担は整理しておくが、上記のような理由により、切り分けが迅速に進まないといった問題が発生する恐れがあるため、一次切り分けが完了するまでは、各業務アプリケーション事業者が協力することを作業内容として明確にしておく。
→ノウハウ集№10、ノウハウ集№12・SLAを適用する場合について、SLAでは合意したサービスレベルを大きく上回った場合のインセンティブ（報奨金）や下回った場合のペナルティ（違約金）を契約の中で明記することも多い。その際、サービスレベルを必要以上に高く設定すると、システム構築・運用費用が高くなってしまうため留意が必要。（例えば稼働率について、高い稼働率を守るためには、サーバの二重化
やSEの常駐などにより、構築および維持管理の費用が高くなる）
46
47

48

3.2
業務アプリケーション対応

№10
№11

②運用設計
①方針検討 ・運用側で受け入れる際のルール（業務アプリケーション側で何を準備するか、など）を整理しておく。
・運用側では、性能影響や他業務との連携の確認が重要である。

○
○

○
○

○
―

②運用設計

○

○

―

資料３（２）大規模自治体クラウド化モデルの行動計画（作業項目一覧）
項
番

作業項目

留意事項

ー
ー

ー
ー

ー

【凡例】○･･･作業実施、―･･･作業
対象外
自治体のパターン別
該ノ
作業項目
当ウ
・ パ ・ ・ パ ・ ・ ・ パ 課ハ
メ タ 共オ タ 自共オ タ 題ウ
集
庁通
イ
通
の
ン ン 基 プ ン 設基 プ ン
フ ① 盤 ン ② 置盤 ン ③
レ
未化
導化
導済
入済
入
済
ム
み
残
存
ー

49

C-2 データセンタ移行

・以下のメリット、デメリットを総合的に考慮し、データセンタ（DC）化について
総合的に判断する。

○○○【メリット】-DC設置に伴うセキュリティ、耐震性、耐火性、補助電源対策の向上。
-全システムをDCに設置することで、場所代、空調設備・電気対策設備
費用が不要。（※ただし、一部システムを自庁に残す場合は、本メリットは少ない。また、現在これらの費用が計上されていない場合は、設備費用の増加に見える。）【デメリット】-自庁とDCとのネットワーク回線による回線コストの増加。
-DC使用費用の増加。（自庁の場合は無償）-運用時の責任分解点が不明確の場合、障害時対応等で時間がかかる可能性がある。（※ただし、責任分解点、監視レベル、担当SEへの連絡が確実にできるようになっていれば、本デメリットは発生しない。）-SLAベースの契約となるため、自治体からは機器構成･方式・障害情報の原因がブラックボックス化する。

50
51

C-3 データ移行
C-4 テスト・研修

・データセンタ利用においてはセキュリティの確保が懸念事項となるが、実際に民間のデータセンタでもセキュリティ面に配慮した高ファシリティのデータセンタがあり、庁内設置と比較しても経済性や柔軟性・拡張性などで優れている。
→ノウハウ集№13№13・国からの通達等で、業務よってはデータセンタの利用が許可されないという懸念があるが、担当部局に確認することで、データセンタ活用が可能とわ
かり、コンソール、ＵＰＳ＊１０などは共用できた実績もある。
→ノウハウ集№14№14・運用テストは、実際に操作を担当する職員や過去の実データを用いて十分な検証を行い、日次、月次、年次処理等できるだけ稼働後の状況に近い状態で実施することが望ましい。

○
○

―
○

―
○

※参考 ： 総務省「平成24年度「自治体クラウド・情報連携推進のための研修教材」」＊１．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊２．リホスト：オープン化済みの業務アプリケーションを、共通基盤に対応させること。
＊３．RFI：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。
＊４．SLA：サービスの品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊５．VLAN：庁内ネットワーク（ＬＡＮ）において、物理的な接続形態とは独立に、仮想的なＬＡＮセグメントを設定すること。
＊６．リビルド：メインフレームをオープン化する際に、既存のシステムを廃止し新しい業務アプリケーションを導入すること。
＊７．SPECINT：ＳＰＥＣ（標準性能評価法人）が策定した、システムの性能評価を行うベンチマーク（コンピュータの整数演算性能を表す指標）のひとつ。
＊８．メインフレーム：ホストコンピュータ、汎用機、汎用コンピュータ、エンタープライズサーバなどと呼ばれるベンダ独自仕様ＯＳを搭載する大型電子計算機を備えた情報処理システム。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊９．マルチベンダ：複数のベンダの製品を組み合わせてシステムを構築すること。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊１０．UPS：無停電電源装置。停電の際でも、一定時間継続して電力を供給することができる。

別冊１ 大規模自治体クラウド化モデル

資料４．大規模自治体クラウド化モデルのノウハウ集

資料４
大規模自治体クラウド化モデルのノウハウ集

行動計画の実現可能性を担保するため、先行事例の解決事例を参考に、懸念との思い込みが散見される事項について解決方法を提示する。その一覧を以下に示す。
№

観点

懸念との思い込みが散見される事項

1

統合化の範囲 ストレージ、サーバ、ミドルウェアなど、どの範囲までを統合化すればよいのか、判断が難しい。
 統合化により、本当にコスト削減できるのか不安。

2

適切なサイジングの実施①

 仮想化方式の選択方法が分からない。

3

適切なサイジングの実施②

 実際の環境を構築した際に想定した性能、信頼性が確保できないのではないか。

4

適切なサイジングの実施③

 仮想化によるサーバのコスト削減が十分に行えないのではないか。

5

ハードウェアの最適化①

 仮想化の効果（性能）を最大限に出すには、ハードウェアの選定をどのように行えばよいか。

6

ハードウェアの最適化②

 信頼性を重視する共通基盤のハードウェアの選定を、どのように行えばよいか。

7

ネットワークの検討

 オープン化した場合や、仮想化した場合、ウィルス感染等セキュリティ面での不
安がある。

8

マルチベンダ化による懸念：データ連携方式の検討

 マルチベンダ化により、システム間のデータ連携が多く、複雑となるのではないか。

資料４
大規模自治体クラウド化モデルのノウハウ集№

観点

懸念との思い込みが散見される懸念事項

9

アプリケーションパッケージの選定

 大規模自治体や政令指定都市の利用を想定したアプリケーションパッケージ
ソフトがほとんどないのではないか。（大規模団体では、処理件数が多いためバッチでの一括処理が必要となる、例外的業務に対応する機能が必要となる、政令市独自の機能が必要となる、など）
 アプリケーションパッケージを使用した場合、カスタマイズが増大するのではな
いか。
 ひとつの事業者のアプリケーションパッケージが提供する機能の範囲内では団体の求める水準の仕様を満たせないことがあるのではないか。

10

マルチベンダ化による懸念：
責任分解点の明確化

 マルチベンダ化により、事業者間の責任分解点が不明瞭となり、作業や機能の考慮漏れが発生するのではないか。

11

マルチベンダ化による懸念：
運用ルールの確立

 マルチベンダ化により、事業者ごとに運用手順や運用ドキュメントが異なり、品
質低下やトラブルが発生するのではないか。

12

マルチベンダ化による懸念：
障害対応手順の検討

 障害発生時に、一次切り分けができない、時間がかかる、障害切り分けの責任の所在が不明確になる、といった問題が発生するのではないか。
 障害発生時に、職員による一次切り分けを行うことは難しいのではないか。

13

民間データセンタの活用①

 民間のデータセンタに基幹系システムを預けてもセキュリティ上問題はないか。

14

民間データセンタの活用②

 戸籍システムなど国の通達などによりデータセンタを活用できないものがある。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• ストレージ、サーバ、ミドルウェア＊１など、どの範囲までを統合化すればよいのか、判断が難しい。
• 統合化により、本当にコスト削減できるのか不安。

◆解決事例• 再編計画が掲げる全体最適の観点から、原則、ハードウェア（サーバ・ストレージ）・ＯＳ・ミドル
ウェア、監視運用を統合化の範囲とした。
• ミドルウェアの統合については、ＯＳ、ＤＢ、アプリケーション実行基盤、ジョブ実行管理機能、プリント実行基盤について製品名･バージョンを規定した。ミドルウェア変更による改修が大きい等必要性が認められる場合に限り、統合化の範囲からはずすこととした。
ただし、その場合でも、業務アプリケーション事業者からの提案をもとに、責任分担、発生するリスク（サイジング、可用性担保、監視運用、障害対応、チューニング他改善作業、製品ロード
マップを含めたメーカーサポート）への対策を、自治体、基盤事業者、業務アプリケーション事業者で調整したうえで認めることとした。また、大きな法改正が予定されているシステムの場合は、それに合わせてミドルウェア変更対応をすることも検討した。

＊１．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 仮想化方式の選択方法が分からない。

◆解決事例• 業務処理量、安定性能の必要性、ＯＳに応じて、仮想化方式の判断基準をあらかじめ決定し、選択した。
【判断基準のフローの例】
該当しない
Ｗｅｂ／ＡＰサーバ

業務処理量大？
安定性能必要？
該当する

対応
ＤＢサーバ

仮想化方式１

仮想化方式２が対応するＯＳか
未対応

仮想分割なし仮想化方式２
Ｗｅｂ／ＡＰサーバ上
に配置する

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 実際の環境を構築した際に想定した性能、信頼性が確保できないのではないか。

◆解決事例• 以下の方式でサイジングし、処理性能を確保した。
 現行サーバのＣＰＵと新サーバで使用予定のＣＰＵのベンチマーク値（ＳＰＥＣＩＮＴ＊１）をまとめ、その比率をもとに新サーバで必要となるＣＰＵコア数を仮算出する。現行サーバで、余分なリソースがあれば削除し、不足していれば安全値を検討して補正する。
 各物理サーバ（ブレード）に搭載される論理サーバ数・ＣＰＵコア数・メモリ量について一覧化し（次紙参照）、
論理サーバの総ＣＰＵコア数・総メモリ量が、物理サーバのコア数・メモリ数を過不足無く利用する配置かど
うか確認する。
 また、ピーク性を考慮した論理サーバの配置（ピークが重らない場合はより最適な配置が可能な場合がある）、信頼性を考慮した論理サーバの配置（同一業務は同一ブレードに搭載しない）を検討し、仮サイジン
グとする。
 その後、評価機にてベンチマークテストを実施し、妥当性を評価する。
業務シナリオで同時実行させ、その他の論理サーバにも負荷をかけて、処理時間が目標どおりか確認する。
結果により、ＣＰＵコア数等の割り当てや論理サーバの配置を変更して、処理時間を確認する。
 最終的なサイジング評価は、主要業務を対象としたテストで評価する。
なお、ブレードサーバとストレージを含めたスループットを十分に考慮する必要がある。（ＣＰＵだけみれば、十分に性能を満たしている場合でも、ストレージのＩＯ等がネックで、性能が出ていないこともある。）※性能確保については、同一規模団体の運用実績のあるサーバリソースと比較を行うことも有効である。
＊１．ＳＰＥＣＩＮＴ：ＳＰＥＣ（標準性能評価法人）が策定した、システムの性能評価を行うベンチマーク（コンピュータの整数演算性能を表す指標）のひとつ。

資料４
大規模自治体クラウド化モデルのノウハウ集

ブレードサーバを利用した場合に、各サーバに適切な配置を行う際の整理方法の例を以下に示す。
各ブレード（物理サーバ）に搭載される論理サーバ数・コア数･メモリ量等を一覧に整理することで、物理サーバを過不足無く活用した配置かどうか確認することが容易となる。
項番

筐体（シャーシ）

1 シャーシＡ
2
3
4
5
6
7
8

物理サーバ

障害時
交替処理

OS1（論理サーバ1）

ブレード1
ブレード2
ブレード3
ブレード4
ブレード5
ブレード6
ブレード7
交替機

（N+1）
（N+1）
（N+1）
（N+1）
（N+1）
（N+1）
（N+1）

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

主要
CPU
ﾒﾓﾘ
業務
ﾐﾄﾞﾙｳｪｱ （コア数） (GB)
XXXXX
4.00
6.0 業務①#1
XXXXX
4.00
8.0 業務②#1
XXXXX
4.00
4.0 業務③#1
XXXXX
4.00
6.0 業務①#3
XXXXX
4.00
8.0 業務②#3
XXXXX
2.00
4.0 業務④#3
XXXXX
2.00
4.0 業務④#2

ブレード1
ブレード2
ブレード3
ブレード4
ブレード5
ブレード6
交替機

（N+1）
（N+1）
（N+1）
（N+1）
（N+1）
（N+1）

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

ＯＳ

OS2（論理サーバ２）

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

主要
CPU
ﾒﾓﾘ
業務
ﾐﾄﾞﾙｳｪｱ （コア数） (GB)
XXXXX
2.00
4.0 業務④#1
XXXXX
0.25
2.0 業務⑤#1
XXXXX
2.00
2.0 業務⑥#1
XXXXX
2.00
2.0 業務⑭#1
XXXXX
2.00
2.0 業務⑭#2
XXXXX
0.75
1.5 業務⑦#1
XXXXX
0.25
2.0 業務⑦#2

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

XXXXX
XXXXX
XXXXX
XXXXX
XXXXX
XXXXX

ＯＳ

・
・
・
17 シャーシＣ
18
19
20
21
22
23

4.00
4.00
4.00
4.00
2.00
2.00
2.00

6.0 業務⑦#3
8.0 業務⑨#1
4.0 業務⑩#1
4.0 業務⑪#1
6.0 業務⑫#1
6.0 業務⑭#3
4.0

1.00
2.00
2.00
0.75
2.00
1.00

2.0 業務⑧#１
2.0 業務⑮#1
2.0 業務⑮#2
3.0 業務⑫#2
2.0 業務⑬#1
2.0 業務⑬#2

・・・

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 仮想化によるサーバのコスト削減が十分に行えないのではないか。

◆解決事例• 「適切なサイジングの実施②」の確認、テストで、物理サーバに想定の負荷がかっていることを確認し、適切な配置となっているかどうかを判断した。
• ミドルウェアのライセンス体系が仮想化に対応しておらず、論理サーバで使用するコア数に関わらず、物理サーバのコア数で課金されるライセンス体系のミドルウェアがあったため、そのミドルウェアを搭載する論理サーバを可能な限り1台の物理サーバに集約する配置（論理サーバのコ
ア数の総数≒物理サーバのコア数となる配置）とした。
• ピークが異なる論理サーバは別々の物理サーバではなく、同一の物理サーバに配置する等、各業務のピーク性を考慮して効率的に論理サーバを配置した。
◇仮想化に対応していないミドルウェアの課金の例
物理サーバ２台（各４コア）で論理サーバ２台が２コアしか使わない設定の場合、物理サーバ２台”それぞれ”に論理サーバが各1台ずつ搭載する場合は、（物理サーバ２台のコア数分である）８コア分のライセンスがかかる。
これを物理サーバ1台に論理サーバ２台を集約して搭載する場合は、（物理サーバ1台のコア数分である）４コアのライセンスで済む。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 仮想化の効果（性能）を最大限に出すには、ハードウェアの選定をどのように行えばよいか。

◆解決事例• 仮想化では、大量データを扱う場合、ストレージＩＯがボトルネックになりやすく、業務アプリケー
ションの性能に問題が発生した際の切り分けが難しくなるため、ストレージＩＯがボトルネックとならないように、高速のデータ転送に適したＦＣ＊１ディスクの使用やＦＣ＊１アダプタの負荷分散を行った。これにより、以降のベンチマークテストで性能が出ない場合に、原因の切り分けが容易（ディスクネックの可能性は低い）となる。

＊１．ＦＣ：ファイバーチャネル。サーバやストレージ間のネットワーク技術の一つ。高価であるが、性能・信頼性が高く、高速のデータ転送に適している。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 信頼性を重視する共通基盤のハードウェアの選定をどのように行えばよいか。

◆解決事例• 機器選定においては、機器についても部品レベルの二重化を行っているサーバを採用して高信頼性を確保した。
• 仮想化することにより、仮想化ソフトウェアのもつ冗長化＊１機能を活用することができ、信頼性をより向上することができた。
• 共通基盤導入時点では、業務システム導入による処理量・データ量の増加の予測が困難であったため、シンプロビジョニング＊２等の仮想化技術により柔軟性を高める構成とした。
• 仮想化先行事例が少なく、最適化のための判断材料が不足していたことから、各仮想サーバへの論理ＣＰＵ・メモリ割当て等のサイジングは安全優先とした。
• リモート監視機能のあるハードウェアを採用した。

＊１．冗長化：システムの設備や部品等に予備を備えておき、一部に故障が発生しても、システム全体は継続して稼働できるようシステムを構築すること。
＊２．シンプロビジョニング：ストレージのボリューム容量を仮想化して、容量設計を不要とする技術。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• オープン化した場合や、仮想化した場合、ウィルス感染等セキュリティ面での不安がある。

解決事例は次紙参照。

資料４
大規模自治体クラウド化モデルのノウハウ集◆解決事例• 住民情報などの守秘性の高い情報を扱う業務アプリケーションが存在する基幹系ネットワークと、そこまで高い
セキュリティは求められない内部情報を扱う業務アプリケーションが存在する内部情報系ネットワークが接続することで、ネットワーク全体のセキュリティが低下することが懸念された。そこで、基幹系ネットワークをハイセ
キュア、内部情報系ネットワークをミドルセキュアに区分けし、ネットワークセキュリティを高めるため、ネットワー
クをハイセキュアエリア、ミドルセキュアエリアに分割し、セキュリティエリア間の直接の通信は原則不許可とした。
• 各エリアをさらにＶＬＡＮ＊１等でセグメント分割し、許可されない通信が行えないようにすることとした。
【ネットワークのイメージ】
ハイセキュアエリア
ＤＢサーバ『セグメント1』
Ｌ２ＳＷ

Ｗｅｂ／ＡＰサーバ『セグメント2』
Ｌ２ＳＷ

負荷分散装置ハイセキュアＮＷ

中継エリア

ミドルセキュアエリア
ＤＢサーバ『セグメント3』
Ｌ２ＳＷ

Ｗｅｂ／ＡＰサーバ『セグメント4』
Ｌ２ＳＷ

ファイアウォール
アクセス制御負荷分散装置ミドルセキュアＮＷ

許可されない通信は
行えない
ように設定

＊１．ＶＬＡＮ：庁内ネットワーク（ＬＡＮ）において、物理的な接続形態とは独立に、仮想的なＬＡＮセグメントを設定すること。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• マルチベンダ＊１化により、システム間のデータ連携が多く、複雑となるのではないか。

◆解決事例• 各システム間のデータのやり取りは、「データ連携基盤」を介することで、システム間のデータ連携を把握でき、一元的に管理できる。
• ただし、データの連携機能を一元化することで、データ連携基盤が不具合により停止等した場合に影響を受ける業務アプリケーションが多数になるため、データ連携基盤には冗長化等の対策が必要となる。
※「データ連携基盤」を介したデータ連携を、円滑に行なうためには、データ連携方式等をマニュアル化し、利用ガイドラインとして業務所管課等に提示することも有効である。

＊１．マルチベンダ：複数のベンダの製品を組み合わせてシステムを構築すること。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 大規模自治体や政令指定都市の利用を想定したアプリケーションパッケージソフトがほとんどな
いのではないか。
（大規模自治体では、処理件数が多いためバッチでの一括処理が必要となる、例外的業務に対応する機能が必要となる、政令指定都市独自の機能が必要となる、など）• アプリケーションパッケージを使用した場合、カスタマイズが増大するのではないか。
• ひとつの事業者のアプリケーションパッケージが提供する機能の範囲内では、団体の求める水準の仕様を満たせないことがあるのではないか。

解決事例は次紙参照。

資料４
大規模自治体クラウド化モデルのノウハウ集◆解決事例• ノンカスタマイズは難しいが、少しでも抑制するという観点から、できるだけ大規模自治体や政令指定都市への導入実績のあるアプリケーションパッケージを選定した。
• 他の団体規模でも必要な標準機能と団体独自機能の分類を明確にし、必要な標準機能については、業務アプリケーション事業者と標準機能追加（機能強化）の交渉を行った。
• 業務ごとに事業者の得意・不得意分野があると考え、業務ごとにアプリケーションパッケージを選定し、マルチベンダ対応を行うことで要求仕様に近いアプリケーションパッケージの採用ができ、カスタマイズの抑制を図った。
• 予め情報システム所管課にてＲＦＩ＊１を実施し、パッケージの情報収集を行なった。
• 現行業務と、アプリケーションパッケージの差異については、各業務所管課と情報システム所管課で合議し、カスタマイズ可否を検討した。カスタマイズを可としたのは、カスタマイズを行なわな
いと市の全体方針に関わる場合や市民サービスの著しい低下につながる場合である。
• 業務所管課がパッケージに合わせて柔軟に業務の見直しを行えるよう、各パッケージ事業者に事前にデモを実施してもらった。
• ノンカスタマイズを前提とするが、どうしても必要となる機能は外付けとしてＥＵＣ機能等により実現した。なお、ＥＵＣでの対応については、業務所管課の職員負荷をできるだけ下げるため、各業務で定常的に使用する帳票等について、ＥＵＣで簡易に作成できるようなマニュアルを事業者側にて整備してもらうこととした。
＊１．ＲＦＩ：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• マルチベンダ化により、事業者間の責任分解点が不明瞭となり、作業や機能の考慮漏れが発生するのではないか。

◆解決事例• 共通基盤の開発・保守を行う「基盤事業者」、業務アプリケーションの開発・保守を行う「業務アプリケーション事業者」、システム全体の管理・機器操作等のオペレーション等を行う「運用事業者」の役割を明確にした。具体的な作業分担については、システム構築時、システム運用時のそれぞれについて、作業項目別の役割分担表を作成し、責任範囲を明確にした。役割分担を決める際は、作業の漏れや重複が発生しないよう、関係者間で十分な協議を行い適切な作業範囲となるように留意した。
• 複数の業務アプリケーションが関連する機能（データ連携機能など）については、「基盤事業者」
が情報提供側、情報照会側のそれぞれと調整する、といった方法で整理を行うことで、統一的に作業を進めることができた。
• 統合化対象の業務アプリケーションに対しては、共通基盤への業務アプリケーションの組み込み、組み込みの際の受け入れ評価は、「基盤事業者」の担当とした。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• マルチベンダ化により、事業者ごとに運用手順や運用ドキュメントが異なり、品質低下やトラブルが発生するのではないか。

◆解決事例• 統一的な運用ルールを決め、運用手順や運用ドキュメントを統一化した。
• あらかじめ統合運用を前提（方針）として、構築を行った。
• 業務アプリケーション事業者に、一元管理するためのソフトウェアを共通的に使用してもらうことが必要なため、基盤事業者が先導してジョブ･監視の設計基準、ソフトウェアを意識させない設計ツール（テンプレート）を業務アプリケーション事業者に提供することで、全体品質の確保を図った。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 障害発生時に、一次切り分けができない、時間がかかる、障害切り分けの責任の所在が不明確になる、といった問題が発生するのではないか。
• 障害発生時に、職員による一次切り分けを行うことは難しいのではないか。

◆解決事例• 作業の漏れや重複が無いように、責任分解点を明確にしておく。
• 障害が発生した場合の原因箇所の特定（一次切り分け）の担当を明確にしておく。
• 障害発生時の一次切り分け作業を「運用事業者」への委託とした（業務アプリケーションごとではなく、統合化対象となる業務アプリケーションで共通した作業とする）。
※なお、団体によっては、障害発生時の一次切り分けを含む共通基盤の運用を、自治体の職員が問題なく行なっている例もある。
• 一次切り分けは「運用事業者」の役割としたが、原因が特定されるまでは業務アプリケーション
事業者の当事者意識が低くなってしまい、切り分け自体ができない、時間がかかるといった懸念があった。このような場合を想定して、一次切り分けまでは各業務アプリケーション事業者が協力するよう決めておく。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 民間のデータセンタに基幹系システムを預けてもセキュリティ上問題はないか。

◆解決事例• 庁舎建設設計の段階で基幹系サーバを民間データセンタに預けた場合と、庁舎にデータセンタと同等のファシリティ機能を有した場合との比較をした。
• 自前で高ファシリティのサーバルームを構築し、それを維持管理していくよりも、民間のデータセンタの中から自治体の基幹系サーバを設置しても問題ないレベル（セキュリティ等のレベル）のデータセンタを選定し、そのデータセンタと契約するほうが、経済性や柔軟性・拡張性などで優位であることが判明した。
• 実際にデータセンタの選定を行った結果、仕様に記載したファシリティよりもはるかに良い条件（床荷重や耐震性能などで）のデータセンタと契約することができた。
• 民間のデータセンタは複数の先進的セキュリティ技術を施すとともに、24時間365日の有人監視を行なっており、自前のデータセンタに同様のサービスを持たせることは、多大な運用経費が必要となる。
• データセンタのセキュリティ等のレベルについては、稼働後も定期的な確認等を行なうことが重
要である。

資料４
大規模自治体クラウド化モデルのノウハウ集◆想定される懸念事項・課題• 戸籍システムなど国の通達などによりデータセンタを活用できないものがある。

◆解決事例• 国の通達においてデータセンタの活用が認められていないという懸念があったが、通達がかなり以前のものであったため、担当部局に問い合わせをした。
• 預けようとするデータセンタの仕様と運用方法を担当部局に伝えて確認したところ、特に問題はないとの回答があった。
• 仮想化についての許可は得られなかったため、サーバとディスクは単独で構築したが、ラックやコンソール、ＵＰＳ＊１などは共用し、自前でサーバを調達するよりも経費の削減が図られた。情報技術は日進月歩であり、過去の通達にとらわれていては新技術は取り込めない。

＊１．ＵＰＳ：無停電電源装置。停電の際でも、一定時間継続して電力を供給することができる。