別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

別冊２
大規模自治体クラウド化モデルの策定にあたって参考とした事例集

2016 年 4月1日

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集
はじめに

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

報告書「第１編

大規模自治体クラウド化モデル」の別冊２として「大規模自治体クラウド化モデルの策定にあたって参考とした事例集」をまとめたものである。
 本事例集には、北九州事例と豊島事例の２事例を記載している。

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

１．北九州事例

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集【北九州事例の構成】



北九州事例は、以下の構成とする。


概略…事例のプロフィールと、事例における共通基盤と業務アプリケーションの基本的な考え方をまとめたもの（資料１．北九州事例の概略）



仕様…基本的な考え方を踏まえ、システム構成等の要件と仕様をまとめたもの。
（資料２．北九州事例の仕様）



行動計画…従来のシステム環境からゴールに至るまでの作業フローと作業の留意点をまとめたもの（資料３．北九州事例の行動計画）



ノウハウ集…行動計画の作業留意点のうち、実現を阻むと思われる課題に関する解決方法をまとめた
もの（資料４．北九州事例のノウハウ集）

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料１．北九州事例の概略

資料１
北九州事例の概略

プロフィール
 人口約９７万人の政令指定都市
 平成１８年度から平成２２年度にかけて、メインフレーム＊１からのオープン化、クラウド化を実施（再編計画実施）
 ホストコンピュータ以外にも、庁内各部署において独自に整備した情報システムが多数存在した。再編計画では、両方のシステムを対象とした。公開された仕様、製品で構築
 「ハードウェアおよび共通ソフトウェア」と「業務アプリケーション」の完全分離を徹底させ、「次期システム基盤」上に「業務アプリケーション」を搭載
 平成29年7月に基幹システム全体を民間データセンタに移行する予定

共通基盤と業務アプリケーションの構成イメージ業務※業務アプリケーションが共通基盤上に搭載され
る方式
共通基盤

業務Ａ

業務Ｂ

業務アプリ

業務アプリ

ミドルウェア（個別）ミドルウェア（個別）

業務アプリケーションのハードウェア、ミド
ルウェア＊２は原則として共通基盤として装備するため、各業務アプリケーションは、
業務機能部分のみを装備する。
※業務アプリケーションによって、個別のミドルウェアを選択することも可能とする。

統合管理

データ処理連携機能
ミドルウェアの統合
ハードウェアの統合

共通基盤に装備されるソフトウェア及び業
務アプリケーションが使用するハードウェ
ア、ミドルウェア全体を統合化する。

＊１．メインフレーム：ホストコンピュータ、汎用機、汎用コンピュータ、エンタープライズサーバなどと呼ばれるベンダ独自仕様ＯＳを搭載する大型電子計算機を備えた情報処理システム。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊２．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料２．北九州事例の仕様

資料２
北九州事例の仕様№ 区分①
区分②
1 アーキ 全体
―
テク
チャ
2

3
4

共通基
盤

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

詳細区分

ハード 共通基盤上のハード DBサーバ
ウェア ウェアは統合化を行っていること
Web／APサーバ

仕様
共通基盤は、業務アプリケーションが動作するのに必要となるハードウェア、ソフトウェアを提供する。

補足

共通基盤で提供するソフトウェアは、OS、ミドルウェア＊１に加え、業務間で共通に必要となる機能とする。

・業務アプリケーションで重複して装備することを防ぐ。

統合化範囲は、全ての業務システムのDBサーバとする。 ・ライセンス体系等のコスト面を考慮すること。
ただし、統合化しない場合は、その理由を明確化する。
統合化範囲は、全ての業務システムのWeb／APサーバと ・ライセンス体系等のコスト面を考慮すること。
する。ただし、統合化しない場合は、その理由を明確化する。

5

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

一元的なデータ管理とバックアップ処理が行えるような装
置とする。

6

その他サーバ

仮想化管理サーバ、運用・監視サーバは統合化の対象外
とする。

DBサーバ

部品を冗長化＊２する。

78

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

障害時でも業務が継続できるような策を講じる。
Web／APサーバ

910

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

12

13

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

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

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

14
15

性能／信頼性の高い高性能ストレージと、コストパフォー ・大量データに対する、高速かつ高い頻度のアクセ
マンス重視のニアラインストレージ＊３を組み合わせた構成 スが可能となることと、管理するデータの性質に合わとする。なお、各ディスクへのデータ配置の例は以下の通 せた最適なコストであること、の２点を考慮する。
りとする。
①高性能：利用頻度が高く高速なアクセスが要求されるデータ（DB／業務データ領域、SANboot領域＊４）②ニアライン：利用頻度が低いデータ（保存ログ領域
等）
複数種類のディスクを１つのストレージとして見せる。
・アプリケーション側からは１つのストレージとしてア
クセスでき、管理が効率化できるため。
大量のデータのバックアップを時間内に完了させるため、差分情報を使ったボリュームレプリケーション機能等を用いる。

16

セキュリティに配慮したストレージ構成となっていること

17

大量帳票印刷が効率 プリンタ
的に実施できること（最適なコストで時間
内に印刷が行えること）ストレージ（バックアップ装置含む）

18
19

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

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

セキュリティエリアごとにアクセス可能な領域を分ける。

カット紙プリンタでフォームも印刷可能とする。

・印刷はカット紙中心へ変更すると同時に、カット紙プリンタでフォームも印刷できるようにすることで、高速連続紙プリンタや設計帳票（プレプリント帳票）＊５を可能な限り排除する。

オープンシステムでも利用可能な連続紙プリンタを利用す ・連続紙をすべて廃止するのは難しく、高速での連る。
続紙印刷が必要であるため。
セキュリティを考慮した ネットワーク
ネットワーク構成となっ
ていること

20

業務内容によって、ハイセキュリティエリア、ミドルセキュリ
ティエリアを設置し、セキュリティエリア間の通信は原則不許可とする。また、各エリアをL2レベルで分割し、許可されない通信が行えないようにする。
同一ブレード内での同一セグメントでも、業務システム間で許可されない通信が行えないよう、論理サーバOS間通信を行えないようにする。

21

ソフト 共通基盤上のソフト
OS
ウェア ウェアは統合化を行っていること

OSは○○とする。

・共通基盤に装備するOS、及びバージョンを定め、仕様として提示する。（装備するOSは、原則は1つに統合することとするが、業務アプリケーションの対応
状況など考慮して、必要であれば他のOSも対象とす
る）

22

DB

DBは○○とする。

・共通基盤に装備するDB、及びバージョンを定め、仕様として提示する。（装備するDBは、原則は1つに統合することとするが、業務アプリケーションの対応
状況など考慮して、必要であれば他のDBも対象とする）

23

アプリケーション実 アプリケーション実行基盤は○○とする。
行基盤

・共通基盤に装備するアプリケーション実行基盤を定め、仕様として提示する。（装備するアプリケーショ
ン実行基盤は、原則は1つに統合することとするが、業務アプリケーションの対応状況など考慮して、必要であれば他のアプリケーション実行基盤も対象と
する）

資料２
北九州事例の仕様
№ 区分①
24

区分②

要件

詳細区分
バッチ処理機能仕様
業務アプリケーションについて、ジョブの一元管理を行う。

25

統合管理

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

26

ユーザ認証機能

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

27

データ処理連携機 業務アプリケーション間で連携する情報は、データ処理連能
携機能を介した連携とする。

28

プリント実行基盤

29

職員ポータル機能 ユーザ認証機能とあわせ、シングルサインオン環境を実現し、業務アプリケーションのリンク起動等を行う。各業務
アプリケーションは認証済のユーザ情報を本機能から受
け取る。

30

ファイル入出力機
能業務アプリケーション間のファイルのやり取りは、ファイル入出力機能を介して行う。

31

EUC機能

業務アプリケーションがDBから汎用的な条件でデータ抽出を行う。その際に、DBの負荷を軽減するため、多重実
行数を制御する仕掛けを備える。

32

ログ管理機能共通基盤では、ログ管理機能の最低限必要な項目を規定する。業務アプリケーション側でこの範囲を超えるログ管
理機能を有している場合は、業務アプリケーションのログ管理機能を用いることも可能とする。

印刷データを一元的に管理する。

33

バッチジョブの一元管 バッチ処理機能
理が効率よく行えること34

APPLICの標準仕様に データ処理連携機 地域情報プラットフォームの標準仕様に準拠した業務アプ
準拠した方式で、デー 能
リケーション間連携を実現する。
タ連携を行っていること35

大量帳票印刷が効率 プリント実行基盤的に実施できること（最適なコストで時間
内に印刷が行えること）印刷出力の優先度を設定し、オペレータによりコントロー
ル可能とする。

36

統合化において、セキュリティに配慮していること

ハイセキュアエリアとミドルセキュアエリアでは、個別にユーザ認証を行い、個々の認証はそのエリア内のみで有効となり、別のエリアへの認証の引継ぎは行わないこととする。

ユーザ認証機能補足

バッチ処理機能には、一般的なジョブの実行を管理する機能に加えて、業務所管課の担当者が操作できるジョブのスケジュールを管理する機能を備える。

37

職員ポータル機能 ネットワークのセキュリティエリアに合わせて、「ハイセキュ
ア側ポータルサイト」、「ミドルセキュア側ポータルサイト」の２つのポータルサイトで構成する。

38

ファイル入出力機
能

ファイルのやり取りが可能な範囲は、各業務アプリケー
ションの属するセキュリティエリアのファイル入出力機能に限定し、ミドルセキュアエリアとハイセキュアエリアのエリアを跨いだやり取りは許可しない。

39

EUC機能

ハイセキュアエリアとミドルセキュアエリアのシステム間ではデータ通信などのやり取りは原則行うことができないた
め、EUC機能はハイセキュアエリアとミドルセキュアエリア
の各々で設置する。

・大量帳票印刷が集中したり、業務所管課の担当者が個別自由に印刷を行うことにより、予定時間内に印刷が終わらないといったことがないようにする。

40

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

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

41

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

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

42

43

44

ソフトウェア（ミドルウェア）は可能な限り二重化し、物理
サーバ（ブレード）、シャーシを分けて配置することで負荷分散、信頼性の確保を行う。
業務ア ―
プリケー
ション

「業務アプリケーショ ―ン」は「共通基盤」上に搭載されていること

共通基盤のハードウェア、ミドルウェアで動作することを原則とする。

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

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

資料２
北九州事例の仕様
№ 区分①
区分②
45 運用
全体
―

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

詳細区分

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

補足

46

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

―

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

47 調達

全体

―

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

48

業務ア ―
プリケー
ション

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

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

49 体制

全体

基盤事業者、業務アプ 基盤事業者・運用 共通基盤の開発・保守を行う。
リケーション事業者、 事業者
運用事業者の役割が （北九州事例では明確になっていること 基盤事業者の役割 共通基盤の仕様・機能に関する「業務アプリケーション事と運用事業者の役 業者」への情報提供を行う。
割を、同一事業者
が担う）
業務間のデータ連携に関して、データの受信側、送信側とそれぞれ調整する。

50
51

―

52

「業務アプリケーション事業者」への支援（情報提供、技術 ・統合的な運用に対して、「業務アプリケーション事
的助言、事業者間調整）を行う。
業者」ごとに作業品質等にばらつきが出ないよう支
援する。

53

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

54

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

55

業務アプリケーションで共用するプリンタを対象に、プリンタの操作を行い、印刷業務を実施する。

56

印刷された帳票を納品可能な状態に加工（ディタッチ、裁断、穴あけ、製本、圧着）する業務を含む。

57

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

58

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

59

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

60

システムのテストに関する支援を行う。

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

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

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料３．北九州事例の行動計画

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

資料３（１）北九州事例の行動計画（作業フロー）

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

Ｂ 要件定義Ｂ－１ 現行業務の棚卸し
Ｂ－２ 現行システムの棚卸し
Ｂ－３ 改善課題の整理
Ｂ－４ ＲＦＩ＊１の作成
Ｂ－５ 業務標準化の検討
Ｂ－６ パッケージ適用判断
Ｂ－７ システム刷新後の要件整理（共通基盤、業務アプリケーション、運用）
Ｂ－８ 費用対効果の検討（予算化）Ｂ－９ 条例・規則等の影響調査・改正
Ｂ－１０ 新システム調達仕様書の作成
Ｂ－１１ 事業者選定、契約締結

Ｃ 設計・構築
Ｃ－１ システム設計・構築（共通基盤、業務アプリケーション、運用）
Ｃ－２ データセンタ移行
Ｃ－３ データ移行
Ｃ－４ テスト・研修＊１．ＲＦＩ：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。

資料３（１）北九州事例の行動計画（作業フロー）
情報システム
所管課

業務の効率化と情報システム再編推進部会

業務所管課

Ａ 基本計画ある

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

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

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

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

調査の支援

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

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

整理の支援

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

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

効果の判断

効果少ない

システム全体最適化
方針の見直し基本計画書の承認

Ａ－６ 基本計画書の作成【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す

Ｂ 要件定義へ：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム
所管課

業務の効率化と情報システム再編推進部会

業務所管課

Ｂ 要件定義ある

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

Ｂ－１ 現行業務の棚卸し

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

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

業務標準化検討の支援（標準化手法の整理など）

Ｂ－５ 業務標準化の検討

あり

Ｂ－６ パッケージ適用判断
Ｂ－４ ＲＦＩの作成

Ｂ－７ システム刷新後の要件整理
Ｂ－８ 費用対効果の検討（予算化）※ＲＦＩで得た情報は、適宜、「Ｂ－６ パッケージ適用判断」「Ｂ－７ システム刷新後の要件整理」「Ｂ－８ 費用対効果の検討（予算化）」の作業に活用する。
投資に対して十分な効果が見込めるか？
効果あり効果少ない
業務標準化の再検討、システム刷新後の要件見直し

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

Ｂ－１０ 新システム調達仕様書の作成【凡例】：主担当として行う作業

Ｂ－１１ 事業者選定、契約締結：支援として行う作業：作業の流れを表す

Ｄ 設計・構築へ：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム
所管課

業務
所管課

事業者

Ｃ 設計・構築
各作業における
設計の承認など

Ｃ－１ システム設計・構築
Ｃ－２ データセンタ移行
Ｃ－３ データ移行
Ｃ－４ テスト・研修【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム
所管課

業務
所管課

事業者

Ｃ 設計・構築
Ｃ－１ システム設計・構築※「Ｃ－１ システム設計・構築」工程内の「共通基盤」「業務アプリケーション」「運用」に係る作業はそれぞれ並行して実施する。

１．共通基盤

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

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

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

３．運用

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

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

【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
１．共通基盤

事業者
1.1 ハードウェア
1.1.1 ＤＢサーバ、Ｗｅｂ／ＡＰサーバ、
ストレージ（バックアップ装置含む）、ネットワーク①方針検討②設計・構築（環境構築）
各作業における
設計の承認など

1.1.2 プリンタ
①方針検討

②プリンタ搬入・テスト

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

②設計・構築

1.2.2 仮想化
①方針検討

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

④構築

【凡例】
：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
１．共通基盤

事業者
1.2 ソフトウェア
1.2.3 バッチ処理機能①方針検討②設計・構築
各作業における
設計の承認など

1.2.4 プリント実行基盤①方針検討②設計・構築

1.2.5 データ処理連携機能①方針検討②設計・構築

1.2.6 ユーザ認証機能①方針検討②設計・構築

1.2.7 職員ポータル機能①方針検討②設計・構築

1.2.8 ファイル入出力機能①方針検討②設計・構築

1.2.9 ＥＵＣ機能①方針検討②設計・構築

1.2.10 ログ管理機能
①方針検討
【凡例】
：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項②設計・構築資料３（１）北九州事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
２．業務アプリケーション

事業者
2.1 リビルド
2.1 リビルド①方針検討②設計・構築
各作業における
設計の承認など

2.2 リビルド・リホスト共通
2.2.1 データ連携対応①方針検討②設計・構築2.2.2 プリント実行基盤対応①方針検討②設計・構築【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料３（１）北九州事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
３．運用

事業者
3.1 稼働維持作業
3.1 稼働維持作業
①方針検討

②運用設計

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

②運用設計

3.3 印刷関連業務
3.3 印刷関連業務
①方針検討

②運用設計

【凡例】
：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料３（２）北九州事例の行動計画（作業項目一覧）

項
番

作業項目

1.1.2
プリンタ

①方針検討

ー
ー

29

ー
ー

28

ー

1 A 基本計画
2
A-1 推進体制の立ち上げ○
3
A-2 現行システム概要調査○
4A-3 システム全体最適化方針の検討○
5A-4 システム刷新後の 共通基盤○
6
業務アプリケーション
○
概要整理
7
運用
○
8
A-5 費用対効果の検討（概算）○9A-6 基本計画書の作成○
10 B 要件定義
11
B-1 現行業務の棚卸し
12
B-2 現行システムの棚卸し○
13
B-3 改善課題の整理○
14○
B-4 ＲＦＩ＊１の作成
15
B-5 業務標準化の検討△
16
B-6 パッケージ適用判断○
17
B-7 システム刷新後の 共通基盤○
18
業務アプリケーション
○
要件整理
19
運用
○
20
B-8 費用対効果の検討（予算化）○21B-9 条例・規則等の影響調査・改正
22B-10 新システム調達仕様書の作成○
23
B-11 事業者選定、契約締結○
24 D 設計・構築
25
D-1 システム設計・構築（共通基盤、業務アプリケーション、運用）
1.1
1 .
1.1.1
26
①方針検討 ○
共通基盤 ハードウェ ・DBサーバ
ア・Web／APサーバ
・ストレージ（バック27②設計・構築 ○アップ装置含む）（環境構築）
・ネットワーク

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

【凡例】○･･･主担当、△･･･支援
作業
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課

○
○
○
○
○
○
○
○

△
△
△

○
○
○

○
○
○
○
○
○
○
○
○
○
○
○
○

○
○
○
○
○
○
△

△ ・現状のシステムについて、業務規模（対象人数、事務件数など）やデータ件数を調査する。事務件数については、通常期と繁忙期のそれぞれの値も必要となる。

○△ ・大量データを扱う場合、ストレージIOがボトルネックになりやすく、業
務アプリケーションの性能に問題が発生した際の切り分けが難しくなるため、ボトルネックにならないような構成とする。
→ノウハウ集№5○№5○ △ ・セキュリティを高めるため、業務内容に応じて、ハイセキュアエリ
ア、ミドルセキュアエリアを設置し、セキュリティエリア間の直接の通信は原則不許可とした。また、各エリアをVLAN＊２等でセグメント分割し、許可されない通信が行えないようにする。さらに、同一ブレード
内の同一セグメントでも、業務システム間で許可なく通信が行えない
よう、論理サーバＯＳ間通信を遮断する。
→ノウハウ集№9○№9○ △ ・近場に印刷事業者が居るかどうかを確認し、居る場合は印刷のア
ウトソーシングを検討する。
→ノウハウ集№6○№6・近場に印刷事業者がおらず自前で印刷する場合は、統合化対象の全業務の大量帳票印刷について、プリンタを統合し、主にカット紙プリンタでの印刷に変更しても、従来の運用スケジュールと同様に運用可能で、かつ高速連続紙プリンタを削減できる。
→ノウハウ集№6
・特に高速な印刷が必要な帳票や原本性を重要視する帳票に限り連続紙プリンタを使用、それ以外はオープン化システムでも利用可
能なカット紙プリンタでの印刷とすることで、コストの最適化を図ることができる。
→ノウハウ集№630
31

1.2
1.2.1 統合化
ソフトウェ
ア

②プリンタ
搬入・テスト

○ △

○

①方針検討

○ △ ・現状の業務システムについて、OS、DB、開発言語などの基本的事項を調査する。OS、DBについては、バージョン、エディション等の調査も必要。各業務システムの状況を踏まえて、全体の方針を検討する。
→ノウハウ集№1○・ミドルウェアを統合する場合、業務システムによってはミドルウェア＊３のバージョンアップを行う必要がある。バージョンアップに対応す
るには、コンバージョンや動作確認の作業が発生するため、業務シ
ステムの状況（大きな法改正が予定されているなど）も踏まえて、バージョンアップするかどうか、などの方針を検討する。
→ノウハウ集№132②設計・構築 ○ △○№1

資料３（２）北九州事例の行動計画（作業項目一覧）
項
番

作業項目

ー
ー

ー
ー

34

ー

1.2.2 仮想化

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

33

【凡例】○･･･主担当、△･･･支援
作業
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課
①方針検討

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

○

№2

②机上での
サイジング

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

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

36
37
38

③実機での
サイジング

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

○

④構築
○ △
①方針検討 ○ △②設計・構築 ○ △ ・ジョブスケジュールの管理については、業務所管課の担当者が操作できるようなシステムとすることでジョブスケジュール管理の作業
負荷を減らし、多くのジョブを効率的に管理･実行できるようにする。
→ノウハウ集№8

○
○
○

№8

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

1.2.4 プリント実行 ①方針検討 ○ △②設計・構築 ○ △ ・近場に印刷事業者がおらず自前で印刷する場合は、オペレータが基盤
印刷実行の優先順位を制御できる方式を検討する。
→ノウハウ集№7

○
○

№7

41

1.2.5 データ処理
連携機能

○

№10

①方針検討

○ △ ・データ連携は、データの送信側と受信側で、連携の方式や連携するデータ項目などの調整が必要となる。しかし、それぞれの業務アプ
リケーション事業者が直接調整をすると、時間がかかるため、基盤事業者が統一した手順、整理用のシートなどによってそれぞれの事
業者と調整する。
→ノウハウ集№10
・段階的な移行を行っている場合、一部メインフレーム＊７が残存している場合がある。その際は、メインフレームとオープンシステム間の連携についても検討する。
→ノウハウ集№10

42

43
44
45
46
47
48
49
50
51
52

②設計・構築 ○ △ ・設計時に、各業務アプリケーション側に、連携すべきデータをヒアリングする工程を設ける。テストでは、業務アプリケーション間の連携をすべて確認するため、期間を長めにとる。
1.2.6 ユーザ認証 ①方針検討 ○②設計・構築 ○機能
1.2.7 職員ポータ ①方針検討 ○②設計・構築 ○ル機能
1.2.8 ファイル入出 ①方針検討 ○②設計・構築 ○力機能
1.2.9 EUC機能①方針検討 ○
②設計・構築 ○1.2.10 ログ管理機 ①方針検討 ○②設計・構築 ○
能

△
△
△
△
△
△
△
△
△
△

○

○
○
○
○
○
○
○
○
○
○

資料３（２）北九州事例の行動計画（作業項目一覧）
項
番

作業項目

ー
ー

○ △ ・適切なパッケージの選定が重要である。できるだけ大規模自治体
や政令指定都市への導入実績のあるパッケージを選定する。
→ノウハウ集№11

ー
ー

①方針検討

ー

2
2.1
業務アプ リビルド
リケー
ション

留意事項

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

53

【凡例】○･･･主担当、△･･･支援
作業
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課

○

№11

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

57
58
59

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

○

2.2.2 プリント実行 ①方針検討 ○ △②設計・構築 ○ △
基盤対応
3.1①方針検討 ○ △ ・運用の統一ルールを定めるが、各事業者がそのルールに容易に稼働維持作業
則れるようにする。例えば、バッチジョブの登録の際など、バッチ処
理機能を利用したことのない事業者へ配慮（簡易な入力シートを配布する）など。また、事前に、業務ベンダに説明する。
→ノウハウ集№12、ノウハウ集№13

○
○
○

2.2
2.2.1 データ連携
リビルド、 対応
リホスト共
通

3
運用

№14

・マルチベンダ＊８環境の場合、実際に障害が発生した際に、安易に自分以外の関係者側の課題であると判断してしまう可能性がある。
障害発生時の一次切り分けについても役割分担は整理しておくが、上記のような理由により、切り分けが迅速に進まないといった問題が発生する恐れがあるため、一次切り分けが完了するまでは、各業務
アプリケーション事業者が協力することを作業内容として明確にしておく。
→ノウハウ集№12、ノウハウ集№14
60
61

62
63

64
65

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

3.3
印刷関連業務D-2 データセンタ移行

№12
№13

②運用設計
①方針検討

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

○
○

②運用設計
①方針検討

○ △
○ △ ・バッチ処理で印刷される帳票について、各帳票の印刷の要件を整理し、全体の要件をまとめる。
・バッチ処理機能と併せて検討する。（ジョブスケジュール登録時に、帳票の印刷枚数や納品日時などを設定できるようにすることで、印刷実行の制御がより効率的に行えるようになる。）

○
○

②運用設計

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

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

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

○
○ △

○
○

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

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料４．北九州事例のノウハウ集

資料４
北九州事例のノウハウ集

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

観点

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

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台のコア数分である）４コアのライセンスで済む。

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• 仮想化の効果（性能）を最大限に出すには、ハードウェアの選定をどのように行えばよいか。

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

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

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• （近場に印刷事業者が無く、自前で印刷する場合）連続紙で印刷していた業務について、安価に実現できるか。（非常に高価で頻度の低い高速連続紙プリンタを削減することが出来るか。）◆解決事例• カット紙プリンタは、連続紙プリンタよりも安価に導入可能なため、連続紙からカット紙へ移行可能な帳票は、カット紙に変更した。
• 従来連続紙で行っていた設計帳票（プレプリント帳票）＊１もカット紙に変更した。具体的には、カット紙プリンタに、プリンタ番号とフォームを登録し、出力の際に業務アプリケーションからフォーム名を指定することで、フォームを含めた印刷を実現した。設計
帳票を廃止することにより、設計帳票の在庫管理等の負荷の削減も行えた。
• ただし、連続紙をすべて廃止するのは難しく、大量印刷帳票や３つ折り葉書、保険証などの原本性を重要視するものについてはオープンシステムでも利用可能な連続紙プリンタを採用することとした。

【カット紙プリンタによるフォームを含めた印刷のイメージ】
共通プリント管理サーバ
ＡＰサーバ

スプール

基盤プリント
実行サーバ
プリンタ
共有

①ＡＰ出力時にプリンタ番号を指定する。
（プリンタ番号は印刷データ中に埋め込まれてフルカットカラー紙プリンタへ送付される）

仮想
プリンタ

物理
プリンタ

フルカラーカット紙プリンタ
プリンタ番号001

ＦＯＲＭ001

プリンタ番号002

ＦＯＲＭ002

プリンタ番号n

ＦＯＲＭ ｎ②印刷データの中に指定されたプリンタ番号に応じて帳票種別毎のフォーム印刷を実現。 なお、各プリンタ番号には使用するフォームをプリンタ内で対応付けておく。

＊１．設計帳票（プレプリント帳票）：特殊サイズの用紙や、あらかじめ色つきの枠や注意書きの文字などを印刷した帳票。

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• （近場に印刷事業者が無く、自前で印刷する場合）複数の業務が個別自由に大量の帳票印刷を行うと、優先度に応じた印刷実行などが行えず、時間内に印刷が終わらなくなるのではないか。

◆解決事例• 各業務アプリケーションが直接プリンタに出力するのではなく、プリンタ出力の前に一旦出力データを蓄積し、オペレータが分割印刷や出力プリンタの指定等のコントロールをできる方式とし（出力データ作成部分とプリンタ出
力実行部分の切り離し）、大量印刷を分割して処理できるようにした。具体的には、業務毎にプリンタに直接出力する方式ではなく、一旦印刷データを仮想プリンタに蓄積し、その後、仮想プリンタから物理プリンタへはオペ
レータにより、プリンタの空き状況、印刷量を加味して（状況により分割印刷）ドラッグ＆ドロップする方式とした。
• これにより、優先順位の低い印刷データが先行して印刷データ作成指示された場合でも、指示順に依存することなく、効率的な印刷実行が可能となった。
【プリンタ出力のイメージ】
ＡＰサーバ
業務
アプリケーション

基盤プリント実行サーバ
プリンタ
帳票
ドライバ
エンジン
プリンタ
ドライバ

ＡＰサーバ
業務
アプリケーション

基盤プリント実行サーバ
プリンタ
帳票
ドライバ
エンジン

共通プリント管理サーバ

スプール
プリンタ
ドライバ
プリンタ
ドライバ

プリンタ
ドライバ
印刷データが１つの仮想プリンタ上に蓄積される。
（画面上１つのキューに表示）

仮想
プリンタ

物理プリンタ①
物理プリンタ②

プリンタ①

プリンタ②

オペレータによる
ドラッグ＆ドロップ

プリンタ状態を見て、仮想プリンタ上のデータをプリンタと対応する物理プリンタへドラッグ＆ドロップにより出力指示を行う。

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• バッチジョブが実行されるサーバが分散するため、一元管理が出来ないのではないか。また、業務所管課からのスケジュール変更要求に柔軟に対応できないのではないか。

◆解決事例• 共通基盤上にジョブを管理する機能（ジョブ実行管理機能）を装備し、ジョブの一元管理を行った。
• ジョブ実行管理機能についてはパッケージ製品を採用したが、さらに、ジョブスケジュール管理機能を追加装備することで、業務所管課の担当者が確認／操作できるようにし、多くのジョブの管理・実行を効率化した。
• ジョブスケジュール管理機能については、業務所管課でも簡単に変更・参照できるように画面を作成したことにより、ジョブスケジュール管理の作業負荷を減らし、多くのジョブを効率的に管理･実行できるようになった。
また、マルチベンダ＊１で複数の業務アプリケーション事業者が存在したため、バッチ管理ツールを利用したことのない事業者へ配慮し、簡易な入力シートを配布する等を行った。
• ジョブ実行管理機能とジョブスケジュール管理機能による、ジョブの登録から実行までの流れは以下の通り。
①バッチ処理のマスタ情報登録②ジョブ実行予定の確認／変更、帳票納品指示の登録③予定の確認④業務所管課へのスケジュール確認依頼⑤ジョブの実行詳細は次紙参照。
＊１．マルチベンダ：複数のベンダの製品を組み合わせてシステムを構築すること。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

資料４
北九州事例のノウハウ集①バッチ処理のマスタ情報登録【ジョブの登録から実行までの流れのイメージ】
バッチ処理機能• 基盤事業者が業務アプリケーション事業者
から情報を入手し、ジョブを仮登録する。

スケジュール登録／照会②ジョブ実行予定の確認／変更、帳票納品指示の登録印刷管理

システム• 業務所管課がジョブ実行予定の確認／変更、帳票納品（印刷枚数、納品日時）の登録を端末より実施する。

システム
日程調整

④

業務所管課

基盤事業者

②
③予定の確認①• 基盤事業者がジョブの実行予定の確認、納品日の調整、進捗管理を実施する。

ジョブ間関連登録
帳票情報登録• 基盤事業者が業務所管課にメールでスケ
ジュール確認を依頼し、必要に応じて業務所管課より調整を依頼する。

⑤ジョブの実行• ジョブ実行管理機能によりジョブを自動実行
し、実行結果を反映する。

③
ジョブスケジュール
管理機能

バッチ処理
情報

実行スケジュール登録④業務所管課へのスケジュール確認依頼

実行結果反映基盤事業者①
バッチジョブ情報

ジョブ実行
管理機能

⑤

ジョブ情報登録
ジョブ定義
情報

ジョブ実行情報（予定・実績）帳票情報
ジョブ間関連情報

業務アプリケーション
事業者

進捗管理

システム

システム

実行監視

予実績管理

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• オープン化した場合や、仮想化した場合、ウィルス感染等セキュリティ面での不安がある。

解決事例は次紙参照。

資料４
北九州事例のノウハウ集◆解決事例• 住民情報などの守秘性の高い情報を扱う業務アプリケーションが存在する基幹系ネットワークと、そこまで高いセキュリティは求められない内部情報を扱う業務アプリケーションが存在する内部情報系ネットワークが接続することで、ネットワーク全体のセキュ
リティが低下することが懸念された。そこで、基幹系ネットワークをハイセキュア、内部情報系ネットワークをミドルセキュアに区分
けし、ネットワークセキュリティを高めるため、ネットワークをハイセキュアエリア、ミドルセキュアエリアに分割した。
• セキュリティエリア間の直接の通信は原則不許可とした。また、各エリアをさらにＶＬＡＮ＊１等により、Ｌ２レベルでセグメント分割し、許可されない通信が行えないようにすることとした。
• セキュリティを高めるため、同一ブレード内の同一セグメントでも、業務システム間で許可されない通信が行えないよう、論理サー
バＯＳ間通信を遮断した。（ソフトウェアの設定等で変更できないよう、ファームウェアレベルでの制御を行うこととした）【ネットワークのイメージ】
ハイセキュアエリア ＤＢサーバ『セグメント1』
Ｌ２ＳＷ

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

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

中継エリア

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

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

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

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

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

シャーシ内部
ブレード１
業務１

ブレード２
業務１

業務２

業務２

業務３

業務３

同一ブレード内の同一セグメントでも論理サーバ間通信を
遮断する。

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

◆解決事例
• 各システム間のデータのやり取りは、「データ処理連携機能」を介することで、システム間のデー
タ連携を把握でき、一元的に管理できる。
• ただし、データの連携機能を一元化することで、データ連携基盤が不具合により停止等した場合に影響を受ける業務アプリケーションが多数になるため、データ連携基盤には冗長化＊１等の対策が必要となる。

＊１．冗長化：システムの設備や部品等に予備を備えておき、一部に故障が発生しても、システム全体は継続して稼働できるようシステムを構築すること。

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

◆解決事例• ノンカスタマイズは難しいが、少しでも抑制するという観点から、できるだけ大規模自治体や政令指定都市への導入実績のあるアプリケーションパッケージを選定した。
• 他の団体規模でも必要な標準機能と団体独自機能の分類を明確にし、必要な標準機能については、業務アプリケーション事業者と標準機能追加（機能強化）の交渉を行った。
• 各業務ごとにベンダの得意・不得意分野があると考え、業務ごとにアプリケーションパッケージを選定し、マルチベンダ対応を行うことで要求仕様に近いアプリケーションパッケージの採用ができ、カスタマイズの抑制を図った。

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• マルチベンダ化により、ベンダ間の責任分解点が不明瞭となり、作業や機能の考慮漏れが発生するのではないか。

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

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

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

資料４
北九州事例のノウハウ集◆想定される懸念事項・課題• 障害発生時に、一次切り分けができない、時間がかかる、障害切り分けの責任の所在が不明確になる、といった問題が発生するのではないか。
• 障害発生時に、職員による一次切り分けを行うことは難しいのではないか。

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

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

２．豊島事例

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集【豊島事例の構成】



豊島事例は、以下の構成とする。


概略…事例のプロフィールと、事例における共通基盤と業務アプリケーションの基本的な考え方をまとめたもの（資料５．豊島事例の概略）



仕様…基本的な考え方を踏まえ、システム構成等の要件と仕様をまとめたもの。
（資料６．豊島事例の仕様）



行動計画…従来のシステム環境からゴールに至るまでの作業フローと作業の留意点をまとめたもの（資料７．豊島事例の行動計画）



ノウハウ集…行動計画の作業留意点のうち、実現を阻むと思われる課題に関する解決方法をまとめた
もの（資料８．豊島事例のノウハウ集）

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料５．豊島事例の概略

資料５
豊島事例の概略

プロフィール
 人口約２８万人の特別区 平成２０年度から平成２６年度にかけて、メインフレーム＊１からのオープン化、クラウド化を民間データセンターを活用して実施（システム再構築計画による）
 ホストコンピュータ以外にも、庁内各部署において独自に整備した情報システムが多数存在した。再編計画では、両方のシステムを対象とした
 業務ごとに業者選定を実施。地域情報プラットフォーム標準仕様準拠の製品導入を必須とした
 最初に構築したシステム共通基盤の情報連携基盤や共通データ基盤、文字基盤などの活用を各業務システムに求めた 平成２５年に住基関連システムを世田谷区とともにＰａａＳ＊２クラウドで構築した共通基盤と業務アプリケーションの構成イメージ※共通基盤と業務アプリケーションをそれぞれ構築し、業務アプリケーションが共通基盤の機能を利用する方式
共通基盤
業務
保守運用基盤業務（住基分野）

業務（税分野）

業務アプリ
業務アプリ
業務アプリ

業務アプリ
業務アプリ
業務アプリ

ミドルウェアの統合

ミドルウェアの統合

ミドルウェアの統合

ハードウェアの統合

ハードウェアの統合

ハードウェアの統合

システム
連携基盤

業務アプリケーションのハードウェア、
ミドルウェア＊３は各業務分野ごとに装備する。

共通基盤に装備されるソフトウェアが使用する
ハードウェア、ミドルウェアを統合化する。
＊１．メインフレーム：ホストコンピュータ、汎用機、汎用コンピュータ、エンタープライズサーバなどと呼ばれるベンダ独自仕様ＯＳを搭載する大型電子計算機を備えた情報処理システム。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊２．ＰａａＳ：利用者が、システムが稼働するためのハードウェアやＯＳ、ミドルウェアをクラウド経由で利用するサービス。
＊３．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料６．豊島事例の仕様

資料６
豊島事例の仕様№ 区分①
区分②
1 アーキ 全体
―
テク
チャ
2

共通基
盤

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

詳細区分

ハード 共通基盤のハードウェ ―ウェア アは統合化を行っていること

3

ハードウェアについて、ダウンタイムを極力短くすること

DBサーバ

4
5

Web／APサーバ

6
7

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

8

仕様
補足
共通基盤で提供するソフトウェアは、業務間で共通に必要 ・業務アプリケーションで重複して装備することを防となる機能とする。
ぐ。
統合化範囲は、共通基盤に装備されるソフトウェアが使用するハードウェアとする。
部品を冗長化＊１する。

・共通基盤が止まった場合の影響が大きいため、可用性を重視する。

障害時でも業務が継続できるような策を講じる。

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

部品を冗長化する。

・共通基盤が止まった場合の影響が大きいため、可用性を重視する。

障害時でも業務が継続できるような策を講じる。

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

部品を冗長化する。

・共通基盤が止まった場合の影響が大きいため、可用性を重視する。

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

9

ソフト 共通基盤上のソフト
保守運用基盤
ウェア ウェアは統合化を行っていること【統合運用管理システム】
業務アプリケーションのハードウェア、ソフトウェア、ネット
ワーク等を一元的に管理する。

10

職員認証基盤【職員認証システム】
職員情報を一元管理し、各業務システムへのアクセスを権限のある職員に限定するという認証機能を提供する。

11

システム連携基盤 【連携基盤システム】
各業務システムをネットワーク間で接続し、セキュリティ等に配慮したシステム連携を行う。

12【共通情報管理システム】
各業務システムが共通して利用するデータを共通情報として管理する。

13【共通外字管理システム】
外字の標準化および一元管理（外字フォントと文字コードの一元管理）を行う。
業務支援基盤14

15【職員ポータルシステム】
各業務システムの入り口となるシステムであるとともに、グループウェア（お知らせ、掲示板、スケジュール、施設予約等）の機能も合わせ持つ。
【共通EUCシステム】
主管課において職員が自らデータの抽出や、Excel等のソフトウェアによる加工、帳票出力等を行うことを支援する。

16

共通業務基盤【窓口受付システム】
総合窓口及びワンストップサービスを支援する。

17

決裁基盤

【文書決裁システム】
庁内の文書を電子的に決裁する。

18

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

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

19

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

20

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

共通基盤の各機能に対しては、規模に応じて割り当てを行うが、信頼性を考慮した配置とし、ロードバランサによる負荷分散、信頼性の確保を行う。

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

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

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

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

21

22

業務ア ―
プリケー
ション

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

資料６
豊島事例の仕様
№ 区分①
区分②
23 運用
全体
―

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

24

詳細区分

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

補足
・サービス利用の形態とした業務アプリケーションは除く。

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

―

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

25 調達

全体

―

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

26

業務ア ―
プリケー
ション

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

・「業務アプリケーション」の調達は、パッケージシス
テムを前提とする。
・ＲＦＰ＊４では指定しないが、ＲＦＩ＊５で事前に調査し、90％以上の業務についてパッケージシステムが適用できることを確認した上で、調達を実施した。

27 体制

全体

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

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

28―

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

29

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

30

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

31

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

32

33
34

共通基盤への業務アプリケーションの組み込みと、受け入れに関する支援を行う。
運用事業者

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

＊１．冗長化：システムの設備や部品等に予備を備えておき、一部に故障が発生しても、システム全体は継続して稼働できるようシステムを構築すること。
＊２．ミドルウェア：コンピュータの基本的な制御を行うOSと、各業務処理を行うアプリケーションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊３．マルチベンダ：複数のベンダの製品を組み合わせてシステムを構築すること。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊４．RFP：Request For Proposal（提案依頼書）のこと。調達するシステム等について、計画内容や仕様を提示し、事業者に提案を依頼するための文書。調達仕様書とも言う。
＊５．ＲＦＩ：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料７．豊島事例の行動計画

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

資料７（１）
豊島事例の行動計画（作業フロー）

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

Ｂ 要件定義Ｂ－１ 現行業務の棚卸し
Ｂ－２ 現行システムの棚卸し
Ｂ－３ 改善課題の整理
Ｂ－４ ＲＦＩ＊１の作成
Ｂ－５ 業務標準化の検討
Ｂ－６ パッケージ適用判断
Ｂ－７ システム刷新後の要件整理（共通基盤、業務アプリケーション、運用）
Ｂ－８ 費用対効果の検討（予算化）Ｂ－９ 条例・規則等の影響調査・改正
Ｂ－１０ 新システム調達仕様書の作成
Ｂ－１１ 事業者選定、契約締結

Ｃ 設計・構築
Ｃ－１ システム設計・構築（共通基盤、業務アプリケーション、運用）
Ｃ－２ データセンタ移行
Ｃ－３ データ移行
Ｃ－４ テスト・研修＊１．ＲＦＩ：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 職員認証基盤①方針検討②設計・構築

1.2.6 業務支援基盤①方針検討②設計・構築

1.2.7 共通業務基盤①方針検討②設計・構築

1.2.8 決裁基盤
①方針検討

②設計・構築【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料７（１）
豊島事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
２．業務アプリケーション

事業者
2.1 リビルド
2.1 リビルド①方針検討②設計・構築
各作業における
設計の承認など

2.2 リビルド・リホスト共通
2.2.1 データ連携対応①方針検討②設計・構築【凡例】：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料７（１）
豊島事例の行動計画（作業フロー）
情報システム所管課

業務
所管課

Ｃ 設計・構築
Ｃ－１ システム設計・構築
３．運用

事業者
3.1 稼働維持作業
3.1 稼働維持作業
①方針検討

②運用設計
各作業における
設計の承認など

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

②運用設計

【凡例】
：主担当として行う作業：支援として行う作業：作業の流れを表す：作業内容の補足事項

資料７（２）
豊島事例の行動計画（作業項目一覧）

項
番

作業項目

○
○
○
○
○
○
○

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

11
12
13
14

B-1 現行業務の棚卸し
B-2 現行システムの棚卸し
B-3 改善課題の整理
B-4 ＲＦＩ＊１の作成

○
○
○ ○
○ ○

○
○
○
○

15
16
17
18
19
20

B-5 業務標準化の検討
B-6 パッケージ適用判断
B-7 システム刷新後の 共通基盤
業務アプリケーション
要件整理
運用
B-8 費用対効果の検討（予算化）

△
○
○
○
○
○

○
○
○
○
○
○

○
○
○
○
○ ・自庁舎に設置する場合とデータセンターに設置する場合について
費用比較を実施し、民間のデータセンターに設置する方針とした。
・事前評価として、情報システム検討依頼書を主管課が作成し（情報システム所管課が作成支援）、構築する予定の情報システムに投資効果があり、区の技術標準（オープン化、共通基盤の活用等）と適合していることを確認する。
・定量評価におけるコスト回収期間
システム検討依頼書の定量評価では、5年間でIT投資コストが回収できるかどうかを一つの目安としている。これは、機器のリース期間
やメーカのサポート期間などから、情報システムが稼働からおおよそ5年程度で更新時期を迎えることが多いと考えられるためであり、必ずしも5年間で回収しなければならないというものではない。

21

B-9 条例・規則等の影響調査・改正○ ・様式をアプリケーションパッケージに合わせる条例改正を行う。業
務所管課への費用対効果の面での説得が必要である。

○

22

B-10 新システム調達仕様書の作成○ ○ ・共通基盤と業務アプリケーションを別発注とする。業務アプリケー
ションは段階的に発注することで、ノウハウを蓄積することが出来る。

○

・調達仕様書にはできるだけ具体的な数値を記載
調達仕様書には、利用者数（端末数）やデータ件数はもとより、性能要件（検索時の応答時間など）や信頼性要件（稼働率など）についても具体的な数値を記載することにより、事業者の間で見積もりの精
度にばらつきが少なくなり、より公平な競争を促すことができるようになる。ただし、信頼性要件やセキュリティ要件をあまり厳しくすると、業務の重要性以上に過剰な性能・機能を持った高価な情報システムを導入することにもなりかねない。信頼性要件やセキュリティ要件等については、情報システム所管課に相談しながら決定する。
・内部審査用評価基準の作成
事業者の提案を評価する評価基準については、事業者向けに公開した評価基準をさらに詳細化した内部審査用の評価基準書（非公開で可）を前もって作成し、審査に望むとよい。この内部審査用評価
基準は、提案書の評価のみならず、事業者選定委員会における説
明資料としても利用することができる。
23

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

○ ○

○

ー
ー

△

○

ー
ー

○
○
○
○
○
○
○

・検討体制
システム化とは、業務の効率化の手段であり、業務に精通した主管課の職員でなければ真の効率化を目指すことができない。また、システム化にあたっては、業務の見直しを行うことで業務改善を進めることが重要であり、それを実現できるのは、主管課の職員のみである。従って、システム化の企画構想は、主管課が中心となって進めなければならない。

ー3A-2 現行システム概要調査
4A-3 システム全体最適化方針の検討
5A-4 システム刷新後の 共通基盤
6
業務アプリケーション
概要整理
7
運用
8
A-5 費用対効果の検討（概算）9A-6 基本計画書の作成
10 B 要件定義○

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

1 A 基本計画
2
A-1 推進体制の立ち上げ【凡例】○･･･主担当、△･･･支援
作業
担当
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課

資料７（２）
豊島事例の行動計画（作業項目一覧）
項
番

作業項目

ー
ー

ー
ー

ー

24 C 設計・構築
C-1 システム設計・構築
25（共通基盤、業務アプリケーション、運用）

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

【凡例】○･･･主担当、△･･･支援
作業
担当
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課

・スケジュール管理
情報システムの詳細設計・開発においてスケジュールに遅延が生じた場合は、早急に原因を見つけて対策を打たなければならない。
通常、2週間程度までの遅れであれば何とか取り戻すことも可能であるが、1ヶ月以上の遅延が生じた場合、容易に取り戻すことは困難となる。このような場合、事業者は、「人員を投入して遅れを取り戻す」と対応策を述べることが多いが、途中から投入された作業員が当該システムについてよく理解するまでに時間がかかることに加えて、事業者内部の情報伝達や管理に時間をとられ、却って作業効率が落ちることもある。このため、定期進捗報告会を1～2週間毎に開催してスケジュールに遅延がないかどうかを確認し、課題を順次解決していく地道な作業こそが重要である。
・プロジェクト管理
情報システム構築などのプロジェクトにおいて問題が発生する場
合、その原因の90%は主管課と事業者との間のコミュニケーションにあるといわれている。主管課と事業者で使用している言葉の意味が違ったり、口頭の確認のみで文書として残っていなかった重要な決定について水掛け論になったりするなど、多くは、正しいコミュニケー
ションが取れていないことに起因する。このようなことから、プロジェ
クト管理はコミュニケーション管理といわれている。

26
27

28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

49
50
51

①方針検討 ○
1.1.1
11.1
共通基盤 ハードウェ ・DBサーバ
・Web／APサーバ
ア・ストレージ（バック ②設計・構築 ○（環境構築）
アップ装置含む）
・ネットワーク

1.2.1 統合化
1.2
ソフトウェ
1.2.2 仮想化
ア
1.2.3 保守運用基盤
1.2.4 システム連携基盤
1.2.5 職員認証基盤
1.2.6 業務支援基盤
1.2.7 共通業務基盤
1.2.8 決裁基盤
22.1
業務アプ リビルド＊２
リケー
ション
2.2
2.2.1
リビルド、 データ連携対応
リホスト＊３共通
3運用

3.1
稼働維持作業

3.2
業務アプリケーション対応○
・共通基盤については高信頼性を確保する必要があるため、部品レベルの二重化を行っている基幹ＩＡサーバを採用して高信頼性を確保する。また、論理ＣＰＵ・メモリ割当て等のサイジングは安全優先とする。
→ノウハウ集№1○①方針検討 ○
②設計・構築 ○①方針検討 ○
②構築○
①方針検討 ○
②設計・構築 ○①方針検討 ○
②設計・構築 ○①方針検討 ○
②設計・構築 ○①方針検討 ○
②設計・構築 ○①方針検討 ○
②設計・構築 ○①方針検討 ○
②設計・構築 ○①方針検討 △ ○

○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○
○

②設計・構築 △ ○

○

①方針検討

△ ○

○

②設計・構築 △ ○

○

①方針検討

○ ○ ・SLA＊４による品質の確保
SLAでは、合意したサービスレベルを大きく上回った場合のインセ
ンティブ（報奨金）や下回った場合のペナルティ（違約金）を契約の中で明記することも多い。ただし、サービスレベルを必要以上に高く設定すると、システム構築・運用費用が高くなってしまう。稼働率を例にとると、高い稼働率を守るためには、サーバの二重化やSEの常駐などにより、構築および維持管理の費用が高くなる。

○

②運用設計
①方針検討
②運用設計

○ ○
○
○

○
○
○

№1

資料７（２）
豊島事例の行動計画（作業項目一覧）
項番

C-3 データ移行
C-4 テスト・研修○ ○○ ○ ・事後評価として、システムの運用テストから本稼働までの期間において、システムが仕様どおりに稼働し、設計書等が適切に記述されていることを確認する。

ーー○・国からの通達等で、業務よってはデータセンターの利用が許可されないという懸念があったが、担当部局に確認することで、データセン
ター活用が可能とわかり、コンソール、ＵＰＳ＊５などを共用することができた。
→ノウハウ集№3
53
54

ー
ー

△ ○ ・データセンター利用においてはセキュリティの確保が懸念事項となったが、実際に民間のデータセンターでもセキュリティ面に配慮した高ファシリティのデータセンターを活用することができ、庁内設置と比較しても経済性や柔軟性・拡張性などで優れていた。
→ノウハウ集№2ー

C-2 データセンタ移行

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

52

作業項目

【凡例】○･･･主担当、△･･･支援
作業
担当
情 業
報 務
シ 所
ス 管
テ 課
ム
所
管
課

№2

№3

○
○

・運用テスト
運用テストは、実際に操作を担当する職員や過去の実データを用いて十分な検証を行い、日次、月次、年次処理等できるだけ稼働後の状況に近い状態で実施することが望ましい。

＊１．RFI：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。
＊２．リビルド：メインフレームをオープン化する際に、既存のシステムを廃止し新しい業務アプリケーションを導入すること。
＊３．リホスト：オープン化済みの業務アプリケーションを、共通基盤に対応させること。
＊４．SLA：サービスの品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）＊５．UPS：無停電電源装置。停電の際でも、一定時間継続して電力を供給することができる。

別冊２ 大規模自治体クラウド化モデルの策定にあたって参考とした事例集

資料８．豊島事例のノウハウ集

資料８
豊島事例のノウハウ集

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

観点

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

1

ハードウェアの最適化

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

2

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

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

3

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

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

資料８
豊島事例のノウハウ集◆想定される懸念事項・課題• 信頼性を重視する共通基盤のハードウェアの選定を、どのように行えばよいか。

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

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

資料８
豊島事例のノウハウ集◆想定される懸念事項・課題• 民間のデータセンターに基幹系システムを預けてもセキュリティ上問題はないか。

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

資料８
豊島事例のノウハウ集◆想定される懸念事項・課題• 戸籍システムなど国の通達などによりデータセンターを活用できないものがある。

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

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