クラウド推進検討会議報告書

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

一般財団法人全国地域情報化推進協会
2016年4月1日

1. 目次1.

自治体におけるクラウド推進の現状と APPLIC の取組状況......................................... 3
1.1.

自治体のクラウド対応をめぐる背景 ....................................................................... 31.2.

大規模自治体のクラウド化推進に向けた APPLIC の取り組み.............................. 5

1.2.1.

大規模自治体クラウド化モデルの普及促進 ..................................................... 6

1.2.2.

ベンダー向けの働きかけ .................................................................................. 6

1.3.

1.3.1.

自治体のオープン化・クラウド化のメリット ................................................. 9

1.3.2.

大規模自治体情報システムの問題点 .............................................................. 13

1.3.3.

大規模自治体クラウド化特有の課題 .............................................................. 13

1.3.4.

クラウド化への誤解 ....................................................................................... 14

1.4.

2.

大規模自治体クラウド化の必要性 ........................................................................... 9

自治体のクラウド化を推進するためのこれまでの取り組み................................. 17

1.4.1.

国における取り組み ....................................................................................... 17

1.4.2.

APPLIC におけるこれまでの取り組み .......................................................... 20

大規模自治体クラウド化モデル.................................................................................... 242.1.

大規模自治体クラウド化モデルの目的及び前提 ................................................... 24

2.1.1.

大規模自治体クラウド化モデルの目的 .......................................................... 24

2.1.2.

大規模自治体クラウド化モデルの検討範囲 ................................................... 24

2.1.3.

大規模自治体クラウド化モデルの対象読者 ................................................... 252.2.

大規模自治体クラウド化モデルの概要 ................................................................. 26

2.2.1.

大規模自治体のシステムが目指すべき姿とモデル化の方針 ......................... 26（１）目指すべき姿 .................................................................................................. 26（２）モデル化の方針............................................................................................... 27
2.2.2.

大規模自治体クラウド化モデルの構成 .......................................................... 28

2.2.3.

大規模自治体クラウド化モデルの活用方法 ................................................... 29（１）基本計画 ......................................................................................................... 30（２）要件定義 ......................................................................................................... 31（３）設計・構築 ...................................................................................................... 41
2.2.4.

大規模自治体のシステムにおける共通基盤の有効性 .................................... 43（１）共通基盤の定義............................................................................................... 43（２）共通基盤の有効性 ........................................................................................... 45（３）共通基盤の導入効果 ....................................................................................... 472.3.

大規模自治体クラウド化モデル ............................................................................ 482.4.

大規模自治体クラウド化モデルの策定にあたって参考とした事例の概要 ........... 56

2.4.1.

北九州事例 ...................................................................................................... 56（１）北九州事例の概略 ........................................................................................... 56
2.4.2.

豊島事例.......................................................................................................... 57
1

（１）豊島事例の概略............................................................................................... 57
2.5.

その他 .................................................................................................................... 58

2.5.1.

オープン化・クラウド化に関する既存ドキュメント .................................... 582

1. 自治体におけるクラウド推進の現状と APPLIC の取組状況
1.1.

自治体のクラウド対応をめぐる背景

電子自治体に係る取組みとして、政府方針（世界最先端 IT 国家創造宣言 平成 26 年 6月閣議決定、平成 27 年 6 月変更）において「地方公共団体が保有する行政システムに関するスリム化」「地方公共団体における業務改革を伴う IT 利活用」が謳われ、自治体業務シ
ステムの運用コスト 3 割削減を目標に、その具体策として『自治体クラウドを中心にクラウド導入市区町村の倍増を目指す』とクラウド化促進が挙げられている。
そして、政府方針を受けた「電子自治体の取組みを加速させるための 10 の指針」（総務省、平成 26 年 3 月策定）及び「電子自治体の取組みを加速するための 10 の指針」フォロー
アップ検討会報告書（総務省、平成 27 年 3 月策定）においても、10 の指針のうち過半数の6 つの指針が自治体におけるクラウド導入の取組み推進（「自治体クラウド」を含む）や業
務標準化に関わるものとなっており、クラウドの導入推進は、自治体規模の大小に関わらず、喫緊の課題である。
電子自治体の取組みを加速させるための 10 の指針【指針１】番号制度の導入に併せた自治体クラウドの導入【指針２】大規模な地方公共団体における既存システムのオープン化・クラウド化等の徹底【指針３】都道府県による域内市区町村の自治体クラウドの取組み加速【指針４】地域の実情に応じた自治体クラウド実施体制の選択及び自治体クラウド導入を見据えた人材育成・確保【指針５】パッケージシステムの機能等と照合した業務フローの棚卸し・業務標準化によるシステムカスタマイズの抑制【指針６】明確なＳＬＡの締結、中間標準レイアウトの活用等による最適な調達手法の検討
自治体クラウドは、小規模自治体から導入が進んでおり、次期更新時の平成 30 年代初めには、人口 5 万人未満の自治体で 68.0%、人口 5～20 万人の自治体で 51.2%と過半数を超える想定である。一方で、人口 20 万人以上の自治体におけるクラウド化の進展が遅れている（図 1-1）。

3

出所：総務省 「電子自治体の取組みを加速するための 10 の指針」フォローアップ検討会 資料

図 1-1

システム形態（現状、次期更新時）

このように、中小規模自治体でのクラウド化は進みつつある一方で、大規模自治体におけるクラウド化は進んでおらず、一層のクラウド化の推進が課題となっている。特に、平成 26 年 4 月現在、人口 30 万人以上の大規模自治体（市町村）は、情報システムの運用コストとして、全自治体（市町村）合計の 5 割近くを占めており、メインフレーム残存率も60%以上となっていることからも（図 1-2）、
「1000 自治体のクラウド化」や「システムコス
ト 3 割削減」の達成にあたっては政令市・中核市のクラウド化（クラウド導入）へ向けた
対応が不可欠である。
厳しい地方財政状況のなかで情報セキュリティ対策の徹底や高度な住民サービスを達成するためにも、情報システムにおけるコスト削減は必須の取り組みである。大規模自治体
におけるオープン化・クラウド化推進策の検討は、大いに進めていく必要がある。
なお、本報告書では、「自治体のクラウド化」を、自治体クラウドを含めた自治体におけるクラウドコンピューティング技術を利用したサービス導入全般として定義する（図 1-3）。

4

出所：総務省 「電子自治体の取組みを加速するための 10 の指針」フォローアップ検討会 資料

図 1-2

市町村における情報システム経費及びメインフレーム残存率

自治体のクラウド化
自治体クラウド（アプリケーション共同利用）

自治体の
オープン化

自治体向けアプリケーション提供サービス利用【SaaS】
自治体向けハードウェア環境提供サービス利用【IaaS】
・・・・・・・・・・・・・・・・・・・・・・
図 1-3
1.2.

「自治体のクラウド化」の定義

大規模自治体のクラウド化推進に向けた APPLIC の取り組み

ここまでで述べた通り、大規模自治体のクラウド化促進が重要な課題となっている。この状況を受け、APPLIC では大規模自治体のクラウド化推進に、技術面におけるサポートを中心に、自治体向けの啓発活動、ベンダー向けの製品対応促進活動など官民協働組織の強みを活かし、積極的な取り組みを展開してゆく。
その最初の取り組みとして本書では次章に述べる「大規模自治体クラウド化モデル」の策定を行った。このモデルを活用することで多くの大規模自治体が従来以上に積極的にクラウド化に取り組めるものと考えている。
APPLIC では今後、大規模自治体のクラウド化推進に向けてこの「大規模自治体クラウド化モデル」の普及促進に向けた情報発信やアドバイザーの派遣、講習会の実施など各種啓発活動に努める。さらに、クラウド実現にはベンダー側の対応強化が不可欠であることから、ベンダー向けの対応製品充実に向けた各種働きかけや技術的な支援、カタログの作成などの促進活動を進めてゆく。

5

1.2.1. 大規模自治体クラウド化モデルの普及促進
まず、「大規模自治体クラウド化モデル」の普及にむけた取り組みを実施する。具体的には APPLIC の Web サイトによる展開、今後 APPLIC で実施されるセミナーなどでの説明や個別の説明会実施などが考えられる。
APPLIC では例年、地域情報化広域セミナーを全国 5 か所程度で実施している。それらのセミナーと連動する形でクラウド推進のための各種広報・啓発活動を行うことが可能である。さらには、メールマガジンや Web サイトでの広報など、従来からの広報チャネルを活用することで広く「大規模自治体クラウド化モデル」の普及・啓発を行う。
また、APPLIC は「APPLIC テクニカルアドバイザー制度」を有しており、自治体向けに地域情報プラットフォーム並びに自治体のクラウド化の普及・啓発を目的として個別ア
ドバイスや講演・セミナーを行う為の専門家を無償で派遣している。派遣内容は


地域情報プラットフォームの基本/応用編



地域情報プラットフォームと自治体クラウド編（レガシー移行/クラウドサービス/共同利用)

地域情報プラットフォームに絡む安心・安全編(防災・見守り)

地域情報プラットフォームに絡むＧＩＳ編（Ｇ空間関連）

地域情報プラットフォームに絡む教育クラウド/校務システム編と多岐に及んでおり、この制度を活用することで直接の普及・啓発活動を行うことができる。従来は自治体向けの支援のみであったベンダー側が本報告書の内容を十分に理解し、適切な対応を行うことができるよう、ベンダー向け説明会やベンダー向け支援策への拡充を合わせて検討する。
1.2.2. ベンダー向けの働きかけ
大規模自治体のクラウド化を実現するにはベンダー側の取り組み促進が不可欠である。
APPLIC は多くのベンダーを構成員とする組織である特性を生かして以下のようなベン
ダー向け支援策を検討してゆく。
（１）大規模自治体クラウド化対応製品の充実支援
大規模自治体のクラウド化促進における課題の一つに対応製品の不足が挙げられている。
大規模自治体がオープン化、クラウド化を実施しようとしたときに、市場に十分な対応製品がなく、必要な調達が実施できないとの意見がある。
そこで、大規模自治体のクラウド化を支える製品、サービスの充実を図るためベンダー
への各種働きかけを行う。具体的には製品化の支援、対応製品の流通支援を行う。
●

製品化の支援（対応製品登録制度の設置）

現在の地域情報プラットフォーム標準仕様準拠製品の登録制度に習い、大規模自治体の6

クラウド化に対応した製品を APPLIC に登録する制度の設置を行う。


大規模自治体に対応可能な業務パッケージ製品



クラウド環境に対応可能なパッケージ製品



大規模自治体クラウド化モデルに対応可能なパッケージ製品など、対応済みといえるための観点を整理し、準拠確認チェックシートを作成する。登録、審査、公開の流れは地域情報プラットフォーム標準仕様準拠製品登録制度と同様のものとし、原則ベンダー側の自主的申し入れにより登録する。登録された製品は APPLIC の
Web サイトで公開するほか、冊子として配布を行う。
地域情報プラットフォーム準拠登録とは「地域情報プラットフォーム準拠登録」は、主に製品ベンダの皆様に、各社の製品が「地域情報プラットフォーム標準仕様書」に準拠しているかを確認いただき、その結果をAPPLICへ登録いただく制度です。
この制度は、対応製品の調達に当たる地方公共団体などに、広く対応製品に関する情報を発信することを目的としています。
準拠登録した製品の情報はAPPLICのWebサイトにて公開されます。調達者はこの情報を確認することで、求める製品に関する情報を迅速に取得できるようになります。
＜準拠登録製品マーク＞
APPLIC が示す手続きに従って登録された地域情報プラット
フォーム準拠製品に対し、APPLICが発行する推奨マークです。
※準拠登録番号より、APPLIC のホームページに掲載している「準拠登録結果一覧」（http://www.applic.or.jp/pf/entry/index.html）に一致する準拠登録番号から、準拠登録の内容、相互接続確認イベントの内容を確認することができます。
地域情報プラットフォーム標準仕様書（技術、業務、ＧＩＳ）
準拠登録●「準拠登録」の意義①製品提供ベンダにとって、自社製品が、地域情報ＰＦ標準仕様に準拠していることを確認＆明示する仕組みが必要

地域情報プラットフォーム②調達者側（自治体他）にとって、製品調達仕様の要件検討時の参考情報として活用

準拠確認及び
相互接続確認仕様③ＡＰＰＬＩＣとして、地域情報プラットフォーム準拠製品の普及促進、および地域情報
ＰＦ標準仕様における準拠ルールの明確化とフィードバック●「準拠登録」の標準化準拠申請・登録のための考え方・運用手法等の確立。
（標準仕様の準拠ルールの抽出（明示化）、準拠チェックリストの策定、申請登録運用フローの策定等）●「準拠登録」の実践
上記で策定した準拠申請・登録の手法にもとづき、製品提供ベンダから準拠申請の受付を実施。※2008.11.04より開始●「準拠登録」の報告
審査後、準拠登録製品の公開（ＡＰＰＬＩＣホームページ）

相互接続確認

図 1-4

地域情報プラットフォーム準拠登録の仕組み

2015 年度段階で準拠確認及び相互接続性検討 TF 活動の一環としてクラウド対応製品の準拠確認方法の検討に着手しており、順次、準拠登録制度の強化を行う。
●

対応製品の流通支援（対応済みベンダーへのインセンティブ）

大規模自治体クラウド化モデルへの対応を促進するため、対応することにインセンティ
ブを与えるための取り組みを実施する。
・対応製品カタログの作成
対応製品の登録制度と合わせて、登録製品についてのカタログを作成し自治体に配布する。
・対応実績等の紹介（Web、APPLIC 通信等）
ベンダーに対応製品のリリースや導入実績などの対外的なアピールの機会を与える。
現在の番号制度ポータルに習い、APPLIC の Web サイトにクラウド化特設ページを作成し、対応事例を紹介する。
・APPLIC 各種セミナー等での事例紹介推進7

地域情報化広域セミナーなどの APPLIC 主催セミナーの場にベンダープレゼンの枠を設け、対応製品を登録したベンダーには積極的な紹介の機会を与える。

図 1-5
●

地域情報プラットフォーム準拠登録製品カタログ

対応製品の流通支援（大規模自治体クラウド化提案の促進）

大規模自治体に積極的なクラウド化提案が行われるよう、ベンダーからの提案を促進す
るための支援策を実施する。
・RFI、RFP 等収集、展開
自治体から RFI、RFP 等の事例を収集し公開する。現在も APPLIC 通信等で調達情報の公開を行っているが、クラウド化に関する情報発信を積極的に推進する旨を自治体に広く周知し、APPLIC に RFI、RFP などの情報を提供いただくようにする。
提供いただいた情報については APPLIC の Web サイトや APPLIC 通信によって周知
すると同時に、対応製品登録ベンダーに展開するなど、ベンダー側がこれらの要請に積極的に対応できるよう情報発信に努める。
・提案先の紹介クラウド化に関する自治体からのニーズを APPLIC 側で収集し、公開する。自治体との情報交換の場、情報収集の場を APPLIC でもうけ、具体的なニーズを聞き取るほか、可能な範囲で導入計画などを提示いただき、適宜公開する。
自治体側の動きをベンダーが掴みやすくすることで、ベンダー側からの積極的な提案
活動を可能とする。

8

1.3.

大規模自治体クラウド化の必要性

以下、あらためて「大規模自治体クラウド化モデル」検討の前提として整理した大規模自治体にとってのクラウド化の意義や実現課題について整理する。
大規模自治体クラウド化モデルは、以下に整理するクラウド化やその前提となるオープン化によるメリットを大規模自治体が十分に享受しつつ、大規模ゆえに直面する各種の課
題を解決しながらクラウド化を推進するための具体的な方策を示すものである。
大規模自治体は近隣への影響力も大きく、また、生活圏としても近隣自治体との関係が深い。大規模自治体が積極的にクラウド化を推進することは、例えば災害時の備えの観点
では、生活圏全体としての対災害強度の向上に寄与することともなる。また、周辺自治体も巻き込んだクラウド化の推進にもつながる。以下に示す大規模自治体自身のメリットのみならず、地域全体のメリットの観点からも積極的なオープン化・クラウド化の検討が期待される。
1.3.1. 自治体のオープン化・クラウド化のメリット
自治体におけるクラウド導入（クラウド化）はコスト削減のメリットだけでなく、低コ
ストで新しいサービスの提供が可能となってくる。先進自治体では、すでに様々なアイデアを実現すべく取り組んでおり、サービスのメニューや充実度、費用対効果が厳しく比較されるようになる。隣の自治体で提供しているのに、我が街ではできないのはなぜかを問われる。すべての自治体にとってクラウド活用による住民サービスの向上は必須の取り組みとなる。
さらに、災害時の備えとしてもクラウド化の意味は大きい。万一の災害時の被災者支援
や復興に住民情報は欠かせない。これからの行政情報化強化の目的の一つが災害対応となる。システム復旧やデータ復旧に時間がかかり、いざという時に役立たないシステムでは許されない。クラウド対応による災害に強いシステム作りは緊急の課題である。
セキュリティ対応の観点からもクラウド化には優位性がある。番号制度対応では、特定個人情報の流出は首長の責任問題になる可能性がある。標的型攻撃の増加など、セキュリ
ティ対策はますます高度化している。しかし、財源も人材も限られるなか、これらセキュ
リティ上の課題を解決するためには「クラウド化」が最適な解決策である。
クラウド化とは、既存の情報システムを、ガラパゴス化したものでなく、標準化された技術に基づいた汎用性の高いシステムに変え、さらに安全なデータセンター等に設置することである。例えば次のような具体的な効果が期待できる。
【コスト削減】


法制度改正時においても標準サポートにて対応でき、追加コストの発生を抑えるこ
とができる



先進自治体のアイデアで開発された先進的システムを簡単に、適正な価格で利用できる

データセンターでのシステム保守によりエンジニアの移動コストがかからず、運用
9

保守コストを安く、また年度間で平準化できる

ハードウェア機器のリソース共有など、共同化によるコストメリットを享受できる



住民向け大量帳票出力の専門事業者へのアウトソーシング経費が削減できる
表 1-1

クラウド化に伴うコスト構造の変化

費目
イニシャル

パッケージソフトウェ

コスト

ア導入費

クラウド化

左記の考え方

による増減
減（※）



標準化された、もしくは共同での機能説明開催により会議開
催回数が減少カスタマイズ費減（※）



カスタマイズした場合においても、共通のカスタマイズの場
合には割り勘効果

ハードウェア構築費減

自治体それぞれの指定場所への搬入や現地作業に関して
サーバ側作業が原則不要であり、大幅に削減される

ミドルウェア設定費減

自治体における現地作業が不
要データ移行費（取込）

変化なし



―

他システム連携機能構

変化なし



―

減（※）



標準化された、もしくは共同で築費操作マニュアル作成・職員研修費の操作マニュアル作成・職員研修の実施により作業負担が軽減

プロジェクト管理費

変化なし



―

減



各自治体庁舎内の既存電算室

ランニング

データセンター利用料

コスト（現行では、ファシリの維持・改善（セキュリティ面、

ティ面のコスト）

空調、スペース確保）と比較す
ると、データセンターの専用ス
ペースの方が安価
減

ハードウェア機器等利

仮想化などによる効率的なリ用料（現行では、賃借料

ソース管理により無駄が省かなどのハードウェア利れる用に係るコスト）
通信回線費（DC～本庁

増

地域にもよるが、少なからず発
生

間回線）

10

費目
パッケージソフトウェ

クラウド化

左記の考え方

による増減
変化なし



ア利用料

サービス利用料全体に含む場
合もあり

ボリュームディスカウントにより、「減」となる可能性あり

減システム運用費（システ

各自治体への現地訪問が必要なく、作業が効率化

ム監視，ジョブ実行管理，ヘルプデスク，障害対応，データバックアップ）
システム保守費減

現地訪問が必要なく、作業が効
率化

大量帳票出力委託費減

プリンタの効率的な活用により無駄が省かれる※自治体クラウドもしくはアプリケーションの SaaS 利用の場合
クラウド化のコスト効果は多くの場合、共同化によるいわゆる割り勘効果によるところが大きい。しかし、大規模自治体の場合、ホストコンピュータの運用費用や、業務ごとに可用性を優先して必要以上の設備・機器を整備するなどにより自治体単独での運用コストが大きいため、クラウド化に伴うサーバ集約や運用統合による単独での費用低減でも大きな効果が期待できる。
例えば北九州市の事例では、2 台のホストコンピュータと約 150 台のオープン系サーバを仮想化環境（約 50 台の物理サーバ）に集約し、運用を統合することで年間の運用経費を約5 億円削減することに成功している。このシステム再編に伴い、従来は存在しなかった総合
窓口システムや庶務事務システムなどの追加整備を行っており、これら新規システムの運用経費が追加となっていることから実施的なコスト削減はさらに大きいものと考えることができる。
北九州市のシステム再編では、APPLIC の標準仕様に準拠した統合 DB、共通基盤（ESB）、
オープンパッケージの業務システムを前提とすることで、再編後の法改正等への対応コストの低減にも成功している。先の住民基本台帳外国人対応のシステム改修では統合 DB 及
び ESB 機能による統一的かつ効率的な改修により、約 2.8 億円のコストで全システムの対応を行った。これは同等人口規模の他政令市に比較しても格段に低いコストであり、また改修規模の縮小はテスト等を行う職員の労力の削減にも繋がるものである。
北九州市では、全てのホストコンピュータ上の基幹システムと、大規模なオープン系システムの合計約 100 システムを再編の対象として、約 40 システムに統合・再構築したが、その構築及び改修費、進捗管理、データ移行、研修などに約 53 億円の初期投資を行っている。当時（平成 18 年～平成 22 年）は民間の IaaS や PaaS が未整備であり、すべてのハー11

ドウェア資産を自前の環境、いわゆるプライベートクラウドとして整備しているが、現代であれば既存の IaaS、PaaS 環境を活用し、より低コストでの実現も可能であろう。
約 53 億円の初期投資であっても、上記のコスト削減効果を見込めば 10 年以内には費用回収が可能であり、ICT の運用に係る労力も大幅に削減できていることからも、再編（クラウド化）の効果は大きいものといえる。
単純なハードウェアの統合効果に関しては、従来のホストコンピュータ 2 台の運用費用とほぼ同額で、統合対象となった約 150 台のサーバも含めた仮想化環境を運用しており、削減した約 100 台のオープン系サーバの費用が丸々削減された形となっている。統合したシステムは APPLIC 標準仕様への対応改修のみ行い、ハードウェアは仮想化環境へ移行したものであり、ソフトウェア部分の保守費用は従来と同等であることから、コストとしてはハードウェア及びその運用部分が純減となった形である。
【IT ガバナンスの強化】

標準技術の採用で複数事業者の経費見積比較が可能となることにより、ベンダロッ
クインの解消につながる【サービス品質の確保】


サービス利用契約に伴い、サービス品質による取り決め（SLA：Service Level
Agreement）が一般的に行われ、安定稼働や性能など一定の品質確保が保証される【業務プロセスの標準化】


各自治体で異なる業務プロセスが標準化され、業務マニュアルを独自で整備する必要がなく、また、ベテラン職員への属人化を排除でき、人材育成もしやすくなる

他自治体との後方支援業務（申請書の定型チェック等）の集約や、近隣自治体との間で行政事務の広域対応が可能な環境を整備できる【業務継続性の確保】

情報システムを別の遠隔地に設置することで、災害時に同時被害を受ける可能性が低くなる。庁舎側の端末環境は被災するが、汎用性の高いシステムにすることで、万一の場合でも復旧を早めることができる。共同利用環境の標準化が進んでいれば、一時的に端末や端末側プリンタなど同じクラウド環境を共同利用している他の自治体の環境を使わせてもらい、データセンターにあるサーバ環境に接続することでシステムを利用可能にすることも考えられる



ハードウェア設置場所として立地条件の整った場所で、かつ耐震・免震構造の建物に設置されることから、堅牢性も確保できる

同一の情報システムを利用する団体からの支援を受けやすく、大規模被災時における罹災証明書発行業務等については遠隔地からの支援が可能となる【情報セキュリティの強化】

情報システムを安全な環境に設置し、高度なセキュリティ対応（不正なデータ持ち出し禁止、ログ（監査証跡）の取得による抑止効果・早期不正発見、ミドルウェア
等のパッチ適用漏れのチェック）を専門家に任せることで、情報流出事故等の発生
12

を抑制することができる【個人情報保護の強化】

個人情報保護のための閲覧制限や操作ログの取得、DV 等被害者対応のための注意
メッセージ機能など、全国的なインシデント（事故事例）対策を反映した個人情報保護の充実した機能を利用できる【職員負担の軽減】

情報システム担当職員を情報システムの保守や運用といった業務から、新規サービスの企画や他部局の職員の能力開発、業務支援といった業務に振り向けることができる

自治体クラウドもしくはアプリケーションの SaaS 利用の場合、同一の情報システムを利用する他自治体職員との情報交換により、最先端の IT 技術動向を得ることができる

1.3.2. 大規模自治体情報システムの問題点

メインフレーム使用による問題点
随意契約によるメインフレーム経費の高止まりが指摘されている。さらに、メインフレー

ムでは調達の透明性が担保できないとの意見もある。
調達の公平性を確保し、システム投資を適正化する観点からもオープン化は有効な候補と言える。メインフレームを廃止することでトータルコストを削減するとともに、業務シ
ステムの新規導入や改修の際の競争性を確保することができる。


個別最適化による問題点
大規模自治体では業務所管ごとにシステム調達される場合がある。個別最適の観点でシステムが導入されてしまうと類似した機能をそれぞれの業務システムで保有することにな
り、重複投資が発生してしまう。例えばＯＳ及びミドルウェアのライセンス料を重複して支払っているといった例も見られる。また、個別に冗長化の仕組みを導入するため稼動していないハードウェアが多いといった問題もある。
各業務所管課でシステムを保持することから稼働維持、ハード・ミドル保守の負担が大きくなる。また、ハードウェアリソースの利用率が低い業務システムがあっても他の業務に割り当てるなど柔軟な対策が困難となっている。個人情報を含む重要データが業務シス
テムごとに管理され、セキュリティレベルが不均一となったり統一的なＢＣＰ対策が困難となったりしている。
また、業務ごとにシステム調達がなされるため、業務間連携が複雑になり、一つの情報システムが全体に及ぼす影響の把握が困難となっている。また、情報システム改修で予期せぬ障害が起こるなどの弊害が生じやすい。
1.3.3. 大規模自治体クラウド化特有の課題
大規模自治体のオープン化、クラウド化には特有の課題がある。
13

①業務ごとのシステム規模が大きく、業務別にシステムを調達する必要があること②業務アプリケーションのパッケージは、人口 10 万人程度の規模を想定して機能が整備されていたため、大規模自治体向けの機能が充実していないこと（近年、大規模自治体でのパッケージ導入が進み、機能強化によって解消されつつある）③全システムを一括クラウド化することは、職員の負担が大きく困難であること（一括切り替えは現実的でなく、段階的な切り替えもデータ移行等でリスクを伴うため）④独自業務・帳票（カスタマイズ）が多く、システム仕様がブラックボックス化して、機能変更に伴う業務・システムへの影響が見通しにくいこと⑤業務担当が細分化してしまい、業務全体を把握できている職員がおらず、統率力をもって強力に推進する体制構築が難しいこと⑥データ量が多く、またシステム停止時の影響が大きく、性能面や安定性での要求が高
いこと⑦中小規模自治体よりも財政面で余裕がある分、システム経費削減への危機意識が低いこと
このような課題のうち、上記①、③、④、⑥ではマルチベンダ環境での柔軟なシステム
間連携の実現や業務の標準化、運用環境の統合などが必要となる。これら技術面の解決策
として、業務間のデータ連携や統合運用環境を備えた共通基盤を整備し、その上に各業務システムを構築して段階的にクラウド化を行うなどの工夫が必要になる。特に大規模自治体におけるマルチベンダ環境でのオープン化・クラウド化推進では「地域情報プラットフォーム」の活用がカギとなる。

○メインフレームからオープンシステムへの移行に向け策定された、業務システム間連携のためのインタフェース標準○これを活用することにより、基盤上に、業務ごとに異なる社のシステムを運用（マルチベンダー）することが可能に○主要ベンダーが準拠製品を展開し、自治体の主
要26業務をカバー。準拠製品総数は７８社887製品に達し、デファクト標準に○北九州市など先行自治体がこの活用によりオー
プンシステムへの円滑な移行を実現

図 1-6

地域情報プラットフォーム活用による大規模自治体のオープン化・クラウド化

1.3.4. クラウド化への誤解
上記のように大規模自治体特有の課題がある一方、クラウド化についての誤解から積極的な取り組みを躊躇している例も見られる。典型的な誤解として次のようなものがあげら
14

れる。
（誤解１）サーバなどはデータセンターよりも自庁内に設置する方がセキュリティが高い
データセンターのセキュリティは、施設（建物等）の耐震性や耐火性に優れ、補助電源対策が考慮されていることで、自庁内よりもはるかに優れている
データセンターではデータセンターの社員ですらほとんど入室できないレベルでのセキュリティ対策が取られており、人的面でのセキュリティも極めて高い（誤解２）データセンターに設置すると通信料が嵩む所有する情報システムの一部だけをデータセンターに設置する程度の場合は、現在のハードウェア設置場所を維持する必要があり、今よりも割高となる可能性がある。
しかし、通信料については、LGWAN を活用することで抑えることも考えられる。
また、全ての情報システムをデータセンターに設置することで、以下のコスト削減なども可能となり、全体で見ると割安となる。


電気使用量の減

UPS 等の電源対策設備の減コンピュータ室専用設備の減

独立空調、耐震床やサーバラック、入退室関連設備の設置（誤解３）自庁導入でないと、障害時の復旧等が遅くなる
データセンター設置には多くの優位性がある。


人的な 24 時間監視が担保されている



担当 SE への連絡が 24 時間化されるため、自治体庁舎内の設置に比べ、障害対応に至る時間が短縮化される

ハードウェアの予備品の確保・搬入等が迅速に対応可能



自庁設置の場合には、庁舎電源の定期点検等によりシステム停止が必ず生じる

自庁設置の場合には、特殊部品等の取り寄せに時間を要し、結果としてシス
テム停止が回避できないケースが生じる（誤解４）クラウド化すると、自由度が損なわれる
複数自治体で、同じソフトウェアを共同利用する形式でのクラウドを選択した場
合には、複数自治体で合意した共通化（標準化）が図られるので、捉え方によっては自由度が小さくなる場合が有る。
ただし、この場合には、広域で同じ業務プロセスとなり、帳票や申請方法等も共通化が図られるため、地域住民や企業等の利便性が格段に向上する。
一方で、共同型でない選択をした場合には、自由度は一切損なわれない。
（パッケー
ジソフトウェア利用の場合は、クラウド化に関わらず、一定の制約あり。
）
15

（誤解５）データ移行等のシステム導入経費を含めるとコストは下がらない
現行システムを使い続けない限り、いつかデータ移行等は発生するものであり、１度、データ移行時に基本フォーマットを「中間標準レイアウト」とする等、デー
タ抽出の協力までを作業範囲とすることで、それ以降は、システム導入経費が抑制できる。なお、データ移行に係る特別交付税の財政措置を活用することで、財政負担が軽減できる。
【新旧ベンダーが異なる場合】


旧ベンダーの役割を最小限化する調達仕様を作成し、新ベンダーが役割の大半を担える工夫を施す。具体的にはデータ変換ツールや移行実績を評価する調達を実施する【新旧ベンダーが同一の場合】


クラウドベンダーの調達時にデータ移行経費の低廉化に係る提案を求め、コ
スト増になる場合には調達を見送る旨を調達仕様に明記する（誤解６）バックアップ環境を庁内設置するなどこれまでより複雑なシステム構成になる
クラウド化に伴い、ネットワーク切断時においても最低限の業務遂行を可能となるために、住民票発行などが可能なバックアップ環境を庁内設置する自治体が多く見られているが、業務継続性の確保のためにも必要な対応と考えられる。


システム復旧に要する時間を勘案すると、多くの業務システムのバックアップ環境を庁内に設置するメリットはないため、庁内設置する業務システムの絞り込みを実施することで、複雑なシステム構成は避けられる（誤解７）マイナンバー利用業務、関連業務、その他で分けられるネットワーク分離に対応できない
クラウドサービスとしては、自治体における一般的なネットワーク構成に対応したサービス提供が進むと考えられるため、総務省が示す自治体情報システム強靱性向上モデルにも準拠する見込みである。
（誤解８）カスタマイズをせず導入できる業務アプリケーションパッケージが存在しないパッケージ標準に業務フローを合わせることができれば、以下のメリットを享受できる。なお、現行の業務フローは、現行システムの機能制限を補完するためにできているものが大半であり、業務遂行上必須のものではないケースが多いことを知る必要がある。このために有効な方法が、ベンダーによるデモの実施と、機能要件を構築しての情報提供依頼等の実施である。


制度改正に伴うシステム改修がバージョンアップで可能となり、改修のためのシステム設計や改修結果を検証する手間や時間、改修に伴うバグ発生等のリスクが軽減される
16

逆にカスタマイズを増やせば増やすほど、開発及び運用経費が嵩むだけでな
く、検証・試験等のために職員の手間の削減ができない。パッケージ本体のバージョンアップの都度、前述の手間を要する（誤解９）職員の IT スキルが低下して、ベンダロックインが助長される
現在は、大規模な制度改正が重なり、高度なセキュリティ対策が日々求められているため、職員の ICT スキルで対応できる状況ではなくなっている。職員の ICT
スキルで対応できる「旧環境」を維持するためにベンダロックインが助長されているということが実情である。今後求められる職員の ICT スキルは「全体最適化」に資するシステム評価等のスキルや運用面でのセキュリティ対策に資するスキルである。
（誤解１０）独自事業への対応がとれず、自治体の個性を発揮できない
自治体（市町村）の業務のほとんどは、法に基づくものである。自治体の個性を発揮できるジャンルは保健・福祉サービスであるが、この場合でも法制度を基礎に、自治体独自の「上乗せ」等が展開される事例が多い。基本機能を共同型クラウドで実現した場合に、当該「上乗せ」対応をシステム上で実施する方法は「追加機能のアドオン」等がある。

1.4.

自治体のクラウド化を推進するためのこれまでの取り組み

参考のため、APPLIC のこれからの取り組み方針の検討や大規模自治体クラウド化モデルの検討の参考とした自治体のクラウド化推進を目指したこれまでの取り組みを整理する。
1.4.1. 国における取り組み
自治体のクラウド化（「自治体クラウド」を含む）推進にあたって、総務省や地方公共団
体情報システム機構（J-LIS）を中心として平成 21 年以降に様々な取組みが行われてきた（下表参照）。自治体クラウド実証及び導入団体の先進事例は体系的に整理されており、さらに、情報セキュリティ対策やデータ移行支援、そして人材育成など多岐にわたる支援を行っている。
表 1-2
1「自治体のクラウド化」における取組み例

取組み内容

実施団体、時期

概要「地方公共団体におけ平成 22 年 4 月、 自治体において ASP・SaaS 利用（自治る ASP・SaaS の導入・ 総務省

体クラウドを含む）時のサービス利用契活用に関するガイドラ

約を締結する際の留意事項や参考様式、イン」の作成導入事例を整理したもの。

17

2

取組み内容

実施団体、時期

概要

自治体クラウド開発実

平成 23 年 3 月、 北海道、京都府、徳島県、佐賀県、大分

証事業の実施総務省

県・宮崎県をフィールドとして、データセンター機能実証、データセンター間接
続実証及びアプリケーション接続実証を実施。

3

自治体クラウド開発実

平成 21～22 年

自治体クラウド開発実証事業での取組証に係る標準仕様書

度、J-LIS

成果を踏まえて、今後自治体クラウドの導入を検討する際に参考となる内容を整理したもの。

4

自治体クラウド推進本

平成 22 年 9 月～

自治体クラウドの全国的導入を加速す

部有識者懇談会の開催

平成 23 年 1 月

るための具体的施策を提言するとともに、クラウドサービス導入による効果提案項目を例示。

5「地方公共団体におけ平成 23 年度～現

モデル団体支援事業等の自治体クラウるクラウド導入の取組

在、J-LIS

ド導入事例等を踏まえ、自治体クラウド

み」の作成
6

の導入手順や留意点を整理したもの。

自治体クラウド推進事

平成 24 年 3 月、 クラウド環境下において、自治体が様々

業（団体間の業務デー

総務省

な団体との間で円滑な業務データ連携

タ連携に係る検討・実を実現できる環境を整備していくため、

証）

連携データ項目や連携機能・方式等の検討・実証を実施。
※「地域情報プラットフォーム」の普及促進として、平成 26 年度まで継続的に実施。

7

自治体クラウドにおけ平成 24 年 3 月、 自治体が保持する情報をクラウド上でる住民サービス向上の総務省より広汎かつ安全に取り扱うことのでためのアクセス・認証

きるようにするため、セキュリティ、

方式等に関する調査研

ユーザビリティを考慮した機能要件等

究をフィールドにおいて検証し、その効果、課題等を分析。

8

自治体クラウドの導入

平成 24 年 3 月、 自治体クラウドの取組み事例を整理すに関する調査研究

総務省るとともに、新たなベンダロックイン対
策を提案。

9

外字の実態調査に係る

平成 24 年 3 月、 クラウドサービス間の相互運用性の確

調査

総務省

保として、コンピュータ処理上使用する文字（特に、市町村毎に設定の外字）について調査。

18

10

取組み内容

実施団体、時期

概要

自治体クラウドの円滑

平成 23 年 7 月～

自治体業務システムの切り替えに伴うなデータ移行等に関す

現在、総務省・データ移行時に、全国の自治体が共通的る研究会、中間標準レ

J-LISに利用できる中間標準レイアウト仕様（APPLIC の地域情報プラットフォー

イアウト仕様の作成

ム標準仕様に準拠）を作成。定期的な更新を実施中。
11

自治体クラウドの情報

平成 25 年 5 月、 自治体クラウドに取り組もうとする自セキュリティ対策等に総務省治体が留意すべきセキュリティ対策事関する調査研究12項について調査。

自治体クラウド・情報

平成 25 年 5 月、 自治体クラウドの導入や番号制度導入

連携推進のための研修

総務省を踏まえた団体間連携など自治体の情教材

報システムを取り巻く環境変化に対応した人材を育成するための研修教材を開発。

13

電子自治体の取組みを

平成 25 年 7 月～

平成 18 年度に策定した「新電子自治体

加速するための検討会

平成 26 年 1 月、 推進指針」の改訂について検討。
総務省

14

自治体クラウドの取組

平成 26 年 3 月、 自治体クラウドの促進を阻害しているを加速するための現状

総務省

課題を明らかにし、効率分析及び促進方策に関的かつ効果的に自治体クラウドを推進する調査研究するための要件やその実現のための提言15

電子自治体の取組みを

平成 26 年 11 月

平成 26 年 3 月 24 日に策定した「電子自加速するための 10 の～平成 27 年 3

治体の取組みを加速するための 10 の指指針フォローアップ検

月、総務省

針」に関する地方公共団体における取組の状況についてフォローアップ等を行

討会

い、その結果を踏まえて地方公共団体に対して情報提供・助言等の支援を実施。

なお、自治体のクラウド化（「自治体クラウド」を含む）推進への次の地方財政措置も取られている。
 情報システムの集約と共同利用 （共同化計画策定等の経費） ：特別交付税（H23 年度～）
 住民データのクラウド移行 （データ移行経費） ：特別交付税（H23 年度～）
 自治体クラウド導入支援コンサルタント ：特別交付税（H26 年度～H28 年度限定）
 自治体クラウド導入後の実務処理研修 ：特別交付税（H26 年度～H28 年度限定）19

出所：総務省 「電子自治体の取組みを加速するための 10 の指針」フォローアップ検討会 資料

図 1-7

自治体のクラウド化（「自治体クラウド」を含む）推進における地方財政措置

1.4.2. APPLIC におけるこれまでの取り組み
APPLIC では 2006 年の設立以来、『官民一体となって地域情報化施策の総合的な推進を図り、多彩なＩＣＴ利活用による高付加価値 ICT サービスを享受できる地域社会の構築を目指す』との活動理念のもと、地域情報プラットフォーム標準仕様の策定、普及促進などに取り組んでいる。
すでに標準化活動は 10 年を超え、会員数は 782、地域情報プラットフォーム標準仕様に準拠した製品を提供する企業数は 80 を数え既に 900 以上の対応製品がリリースされるに至っている。また、導入団体数も 1500 団体を超え、すでに自治体におけるデファクトスタ
ンダードと言える状況にある。
H17.10.4
設立

H18.5.15
統合(一財)全国地域情報
全国地域情 化推進協会
報化推進協
The Association for
Promotion of Public Local
議会
Information andCommunication

会員数 7８２※新公益法人制度の導入に伴H24.4に財団法人から一般財団法人に移行(財)電気通信高度化協会
S60.6.10 設立

残余財
産寄附

情報基盤協議会
Ｓ63 設立

残余財
産寄附

H17.12 解散

ｅー自治体協議会（地方公共団体行政サービ
スオンライン化促進協議会）

H13.4 設立

特別 :541
普通 107
賛助 134
残余財産寄附

H18.6.30 解散

テレトピア促進協議会

H18 秋 解散

Ｓ60 設立e-Japan戦略Ⅱ(H15年7月)

e-Japan戦略(H13年1月)

利活用促進

ICT基盤整備

昭和60年（H27.9月16日現在）

平成15年

図 1-8

ＩＴ新改革戦略(H18年１月)
いつでも、どこでも、誰でも

平成17年

平成18年

平成27年

APPLIC の変遷

地域情報プラットフォーム標準仕様は 2007 年の V1.0 リリースより、全体最適化の観点
20

から自治体の庁内業務システムの整理・最適化、さらにデータ連携の標準化による業務デー
タ多重管理の抑制やマルチベンダ環境の実現に寄与してきた。地域情報化の実現に向け、まずは自治体内部の情報連携の標準化、高度化に取り組んでおり、それらは高付加価値な総合窓口の実現など自治体サービス向上の形で成果を結んでいる。

団体内連携

税

住基

福祉

他団体

・・・

情報提供ネットワーク

地域情報プラットフォーム

ＰＵＳＨ型サービスなどの新サービス

外部機関との情報連携

総合窓口などの
高度なサービス

マルチベンダ環境における情報連携

業務データの整理
多重管理の抑制業務システムの整理
全体最適化

図 1-9

・・・

地域

地域情報プラットフォームにおける情報連携の標準化、高度化への取組み

例えば、福岡県粕屋町では地域情報プラットフォーム標準仕様を採用し、庁内の業務システムを柔軟に連携させることによって住民の状況に合わせた適切なサービス提供を可能とする「インテリジェント型総合窓口サービス」を実現させ 2011 年度情報通信月間総務大臣表彰を受賞している。

住民視点

職員のスキルに依存しない均質のサービスを受けられる一つの窓口で複数のサービスを受けられる（ワンストップサービ
ス）

図 1-10

その人にあったサー
ビスを漏れなく提供できる

エキスパートナビにより個人の能力に依存しない均質なサービスが提供できる

福祉ＤＢ

税務
システム
税務ＤＢ

統合
データベース

職員情報、宛名、口座情報など共通で利用するデー
タを統合管理しているため、他システム
で入力されている情報を重複入力することなく利活用できる

税務担当

連携の準
備はOK

・
・
・

必要最低限の情報のみ伝えることで、「手続き」、「サービス」が
受けられる

福祉
システム

住記担当

他の自治体

総窓DB

住記ＤＢ

フレキシブルな組織体制でバックヤ ード業 務を遂行することで業務効率 UP

必要な手続きや受けられるサービスについての情報を享受できる

総合窓口
システム

地域情報プラットフォームのサービス連携ルールに準拠

住民

受けられる
サービスの
情報提供

既存情報の活用
取得した情報の
即時DB化

住民情報系
システム

国（霞が関）

専門グループいらっしゃいませ、私が対応させていただきます

適切な
ヒアリング

システム
視点

福祉担当
機能、データの重複所
有がなくなり、保守が容易になる
職員の異動があっても、データが一元管理されているため、そこだけ変更すれ
ばOK

民間企業

総合窓口グループ

転入手続き
に来ました

子供が生まれたので手続きに来ました

職員視点

福岡県粕屋町における地域情報プラットフォームの活用事例

21

自治体のクラウド化促進にも早くから取り組んでいる。「地方公共団体における ASP･
SaaS 導入活用ガイドライン」（総務省 2010 年 4 月）では、システム間連携時に留意すべき事項として、『柔軟なインターフェース連携を実現するためには、地域情報プラットフォー
ムに準拠したものの導入や、既存のシステムにおける外部とのインターフェー
ス仕様の開示、庁内システムのミドルウェアの整備などが挙げられる』とされ、さらに、バックオフィス業務への ASP･SaaS 導入にあたっての留意点としては、『庁内システムの ASP･SaaS への移行に際して、地域情報プラットフォームの活用などによって、段階的にかつ円滑に進めることが重要である』と謳われている。そして、2011 年度の総務省「自治体クラウド開発実証事業」では自治体クラウド内の連携基盤として地域情報プラットフォームが採用されている。
さらに、「自治体クラウドの導入に関する調査研究報告書」（総務省 2012 年 3 月）においても、クラウド化の阻害要因となるベンダロックインに対する求められる対策として『地域情報プラットフォームを活用したシステムの導入により、マルチベンダ
接続や業務システムの差し替えを容易に実現することができる』と述べられている。
そして、自治体のクラウド化指針を決定づけた「電子自治体の取組みを加速するための１０の指針」（総務省 2014 年 3 月）では、「【指針２】大規模な地方公共団体における既存システムのオープン化・クラウド化等の徹底」においてマルチベンダへの対応として、『マルチベンダの環境下において、番号制度対応等による庁内情報連携等に適切に対応するため、必要に応じ情報連携基盤の導入を検討する。その際、地域
情報プラットフォームに準拠したシステム導入を検討する』としている。また、「【指針６】明確なＳＬＡの締結、中間標準レイアウトの活用等による最適な調達手法の検討」では『地域情報プラットフォームに準拠したシステムを導入することで、将来にわたる競争性を確保すること』と明記され、『システム間のデータ移行における多額の費用発生等、自治体クラウド導入の阻害・ベンダロックインの原因を、総務省が公開する中間標準レイアウト仕様
や、地域情報プラットフォームの活用により解消すべきである』と解説されている。

22

これらの流れを受け、APPLIC では、「地方自治体における業務の標準化・効率化に関する研究会」（総務省 2014 年度）においてクラウド化推進の考え方を発表し、全体最適を推進する組織として、クラウド化においてはコスト削減、業務効率化、住民サービス向上を
バランスよく推進することが必要であること、そのための標準化推進の重要性を主張した。

３つの目的 （コスト削減、業務効率化、住民サービス向上）
自治体に必要なのはコスト削減、業務効率化、住民サービス向上の三点
これらをバランスよく、総合的に推進しなければならない

第一回資料「研究会の趣旨」より

業務
標準化
効率化

評価：
「業務の標準化」の効果をどう把握するか（達成指標の設定）

コスト
効率化
削減

推進：
「業務の標準化」にはどのような課題があるか（阻害要因の解消）

住民
サービス
サービス向
向上
上
Page 5

図 1-11

バランス：「業務の標準化」とは何か（定義、目的の整理）

Copyright 2014, The Association for Promotion of Public Local Information and Communication

クラウド化推進によるコスト削減、業務効率化、住民サービス向上

さらに、「電子自治体の取組みを加速するための 10 の指針」フォローアップ検討会ではクラウド推進への取り組みを発表し、地域情報プラットフォームが既に 90%の団体に普及していること、北九州市のプライベートクラウドや神奈川県町村情報システム共同化等でも利用されていることなどを説明した。また、クラウド化時代に見合った全体アーキテク
チャの必要性に言及し、総務省事業と連携してクラウド化推進に積極的に取り組む姿勢を表明した。

地域情報プラットフォームを活用したクラウドモデル

地域情報プラットフォームを活用したクラウドモデル

高付加価値サービスの実現に向け、地域情報プラットフォームを活用した戦略的なクラウドモデルを構成

次世代クラウドモデルとして業務共通部分の標準化

クラウド

第二ステップとしてクラウド基盤部分のカバー領域を拡大する
法改正などの影響を受けるビジネスロジックとの切り分け

基幹系業務ユニット
総合窓口、ワンストップ、PUSH型
サービスなどの機能標準

業務共通な機能部分の整理を
クラウド時代に合った形で再構成する必要がある

業務システムアーキ
テクチャの統一

業務共通要素基盤

ＳＴＥＰ２

ＳＴＥＰ１

総合窓口
高付加価値サービス機能

総合窓口
高付加価値サービス機能

業務共通要素基盤

情報連携基盤情報連携基盤

クラウド時代のコスト削減モデル、大規模団体を含めたクラウド
利用メリットを最大化する共通機能群を再構成する

高付加価値サービスの基礎となる情報連携。番号制度・条例対応

業務共通機能をクラウド基盤に切り出すことによる
業務システム構築コストの削減も視野にPage 15

Copyright 2017, The Association for Promotion of Public Local Information and Communication

図 1-12

Page 18

Copyright 2017, The Association for Promotion of Public Local Information and Communication

地域情報プラットフォームを活用したクラウドモデル

23

2. 大規模自治体クラウド化モデル
大規模自治体クラウド化モデルの目的及び前提

2.1.

2.1.1. 大規模自治体クラウド化モデルの目的
大規模自治体の基幹系情報システムのシステム運用コスト削減のため、オープン化、クラウド化の推進が求められている。実際に大規模自治体においてオープン化、クラウド化を実施し、以下の効果を上げている例もある。


北九州市では、基幹システムの再編としてオープン化、自庁クラウド 1を実施し、基幹システム全体の運用経費について、年間約 5 億円を削減した。



豊島区では、メインフレーム 2からのオープン化、クラウド化を実施し、イニシャ
ル費とリース費、運用費などの減により 5 年で総計 2 割に近い削減効果を上げられる見込みである。

そこで、大規模自治体クラウド化モデルは、大規模自治体（政令市・中核市相当）に対して『自治体の規模に関わらず、オープン化、クラウド化が実現可能であること』を示し、オープン化、クラウド化を促進することを目的とする。
具体的には、大規模自治体クラウド化モデルにおいて、以下を提示する。


大規模自治体がオープン化、クラウド化する際に、参照できるモデルがあれば検討を進めやすくなるため、実現可能なシステム（オープン化、クラウド化実施後のシステム）を、事例をもとにモデル化し、参照可能な形式で提示する。



オープン化、クラウド化を推進する大規模自治体に対して、導入に至る手順、想定される課題とその解決策を、具体的に提示する。

2.1.2. 大規模自治体クラウド化モデルの検討範囲
大規模自治体クラウド化モデルでは、以下に示す範囲について記載する。


自治体クラウド関連資料等の既存ドキュメントではあまり言及されていない、大規模自治体にとって重要な事項を中心に記述する。



政府が進めるクラウド化のターゲットである主要 5 分野 3（住基、税、国保、年金、福祉）を含めた、基幹系業務（APPLIC において標準化を進めている 26 業務 4）を対象とする。


1

オープン化・クラウド化を推進する自治体及び事業者に対する技術的な支援策につ自庁クラウド：統合化したサーバを自庁内に設置すること。
メインフレーム：ホストコンピュータ、汎用機、汎用コンピュータ、エンタープライズサー
バなどと呼ばれるベンダ独自仕様ＯＳを搭載する大型電子計算機を備えた情報処理シス
テム。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）
3 主要 5 分野：「電子自治体の取組みを加速するための検討会」（総務省）による「新たな電子自治体推進のための情報化調査」における「基幹系システム（住民情報、税務、国民健康保険、国民年金、福祉関連システム）」。
4 26 業務：APPLIC「地域情報プラットフォーム標準仕様」の「自治体業務アプリケーションユニット標準仕様」で規定されている 26 の自治体業務ユニット。
242

いて記述する。


クラウド化については、単独自治体によるクラウドも検討対象とする。

なお、大規模自治体クラウド化モデルでは大規模自治体を対象としているため、大規模自治体に共通的または特徴的な内容を中心にモデルの詳細を記載している。そのため、大規模自治体に特化しない（中小規模自治体のシステムでも大きな差がない）事項については記載の対象外としている場合がある。また、大規模自治体ごとに内容が大きく異なる事項については、モデルを構築することが困難なため、記載の対象外としている場合がある。
2.1.3. 大規模自治体クラウド化モデルの対象読者
大規模自治体クラウド化モデルは、主な読者として以下のような自治体の職員、及び事業者を想定している。
【自治体】


オープン化、クラウド化したいが推進できない大規模自治体の職員

【事業者】


自治体のオープン化、クラウド化に関する計画立案、設計・構築、運用等の作業を請け負う事業者

25

大規模自治体クラウド化モデルの概要

2.2.

2.2.1. 大規模自治体のシステムが目指すべき姿とモデル化の方針（１）目指すべき姿
本章では、大規模自治体がオープン化、クラウド化する際の実現可能なシステムをモデル化する。モデル化を行うにあたって、大規模自治体のシステムが目指すべき姿を整理した。
本章において、大規模自治体のシステムが目指すべき姿は「IaaS 5以上のクラウドが実現した姿」とする。
なお、大規模自治体のシステムが最終的に目指すべき姿は、「クラウド推進検討会議報告書

多様なクラウド活用による住民サービスの向上」（APPLIC）で示す多様なクラウドを組み合わせたハイブリッドクラウドである。しかし、各自治体のオープン化、クラウド化が完了していない現時点では、当面は、ハイブリッドクラウド実現の前提となる IaaS 以上のクラウド化を目指すこととする。
「IaaS 以上のクラウドが実現した姿」においては、システムを自庁内に構築するのではなく外部のデータセンターを活用し、場所代・機器・運用も含めたサービス契約によるシステム導入を行うものとする。なお、サービス契約の範囲については、情報システムの稼動に必要なハードウェア等のインフラのみを範囲とする場合、ミドルウェア 6まで含める場
合、更に業務アプリケーションまで含む場合など、どこまでをサービスの範囲とするかは各自治体が選択するものと考える。そこで、大規模自治体のシステムが目指すべき姿においては、
ハードウェア等のインフラのみをサービス契約の範囲とする IaaS を最小限として、
IaaS 以上のクラウドが実現されているものとする。
以上のように、大規模自治体のシステムが目指すべき姿を設定するが、メインフレームが多く残存している大規模自治体のシステムにおいて、メインフレームが残存している状態から目指すべき姿までは、オープンシステム、プライベートクラウドといった段階が想定される。
オープンシステムは、自治体のシステムにおいて全てのメインフレームが廃止され、オープン化が完了した姿である。
プライベートクラウドは、オープン化されたシステムにおいて、ハードウェアやミドルウェアが仮想化技術により統合された姿である。なお、プライベートクラウドにおいては、
データセンターではなく自庁内にシステムを設置しているものとする。
このように、メインフレームから目指すべき姿までは段階的な進展が想定されるが、目指すべき姿の実現においては、必ずしもその段階ごとに実現する必要はなく、各自治体が自団体の状況に応じて選択するものと考える。
IaaS：利用者が、システムが稼働するためのハードウェアをクラウド経由で利用するサービス。
6 ミドルウェア：コンピュータの基本的な制御を行う OS と、各業務処理を行うアプリケー
ションソフトウェアとの中間に入るソフトウェア。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）
26
5

以下に、メインフレームから目指すべき姿までのクラウド化の進展を段階的に表したイメージを示す。

図 2-1

大規模自治体におけるクラウド化の進展と目指すべき姿（２）モデル化の方針
すでに、オープン化、クラウド化を実施し、実際に効果を上げている大規模自治体の先行事例があることから、これらの先行事例を分析し、先行事例の共通的な事項を抽出してモデル化したものを大規模自治体クラウド化モデルとした。

図 2-2

モデル化の考え方

なお、オープン化、クラウド化を進める自治体は、本章で提示する大規模自治体クラウド化モデルをそのまま踏襲する必要は無く、各自治体の現状のシステム等の状態を踏まえ、この大規模自治体クラウド化モデルを参照し、必要となる事項を取捨選択して当該自治体
での実現方式を検討することを想定している。

27

2.2.2. 大規模自治体クラウド化モデルの構成
大規模自治体クラウド化モデルは、「先行事例をモデル化して設定したゴール」を表すド
キュメントと「自治体の現状からゴールに至るやり方」を表すドキュメントに分類される
以下の 4 つで構成される。
【先行事例をモデル化して設定したゴール】①基本的な考え方「アーキテクチャ」「運用」「調達」「体制」の観点から共通基盤と業務アプリケーショ
ンの基本的な考え方をまとめたもの。
②仕様
実現可能な姿を示すため、基本的な考え方を踏まえ、システム構成等の要件と仕様をまとめたもの。
【自治体の現状からゴールに至るやり方】③行動計画
どうやれば大規模自治体クラウド化モデルが実現できるかの手順を示すため、大規模自治体の現在のシステム環境からゴールに至るまでの作業フローと作業の留意点をまとめたもの。
④ノウハウ集大規模自治体クラウド化モデルを実現できない技術的な理由はないということを示すため、行動計画の作業の留意点のうち、実現を阻むと思われる課題に関する解決方
法をまとめたもの。
なお、大規模自治体のクラウド化において、当面目指すべき姿は、個々の自治体の事情「先等によって様々な実現形態（IaaS、PaaS 7、SaaS8など）となることが想定されるため、行事例をモデル化して設定したゴール」についてはこれらの実現形態に依存しないようゴールを設定している。

PaaS：利用者が、システムが稼働するためのハードウェアや OS、ミドルウェアをクラウ
ド経由で利用するサービス。
8 SaaS：利用者がシステム開発を行わず、業務アプリケーションをクラウド経由で利用するサービス。
（総務省「電子自治体の取組みを加速するための１０の指針」より引用）
28
7

2.2.3. 大規模自治体クラウド化モデルの活用方法
オープン化、クラウド化を実現するための作業手順は、大きく、事前検討、基本計画、
要件定義、設計・構築の 4 つに分けられる。これらの作業において大規模自治体クラウド化モデルが活用できるものと考える。
ただし、事前検討では、オープン化、クラウド化を実施することに関する庁内の合意形
成が主な作業となる。本章ではクラウド化を実施することを前提として、その推進のための支援策を検討するため、主に基本計画以降の作業において活用されることを想定している。なお、庁内の合意形成については 1 章に記載している。
基本計画、要件定義、設計・構築の 3 つの工程に対して、大規模自治体クラウド化モデルの活用が可能な部分を以下にまとめる。
表 2-1

大規模自治体クラウド化モデルの活用場面

1

基本計画

自治体

2

要件定義

3
4

RFI 9

事業者
RFP

7

自治体

10

5
6

自治体

事業者
設計・
構築

自治体

事業者

活用する場面

基本計画を策定する際に、目指すべきシステム ○の姿やそれを実現するためのスケジュール、調達の考え方などを具体化する。
策定した基本計画の妥当性等を検証するため、 ○複数の事業者に対して情報提供を依頼する。
自治体が RFI を通して求めている内容を理解 ○し、適切な情報提供を行う。
基本計画等で検討したシステムの目指すべき ○姿を具体化し、調達時の要求仕様として適切に記載する。
RFP に対して、基本的な提案事項に抜け漏れ ○が無いよう、適切な提案を行う。
事業者が設計した内容に対して、自治体として妥当性を確認した上で、承認するかの判断を行う。
調達・提案の時点で概ね決定されている内容に加え、設計時に、必要に応じて実現方式の事例などを収集した上で、詳細検討を行う。

ノウハウ集

利用者

行動計画

工程

仕様

№

基本的な考え方

活用可能な
大規模自治体
クラウド化
モデル

○ ○ ○

○ ○ ○
○
○ ○ ○

○

○

○ ○ ○

○

○

RFI：Request for Information（情報提供依頼書）のこと。システム等の調達を行なう際に、システムや業務の要件をまとめるために事業者に情報提供を依頼する文書。
10 RFP：Request For Proposal（提案依頼書）のこと。調達するシステム等について、計
画内容や仕様を提示し、事業者に提案を依頼するための文書。調達仕様書とも言う。
29
9

工程ごとの活用方法の詳細な内容を、以下に記載する。
（１）基本計画
庁内体制の整備、システム構築の目的の明確化、などを行い、オープン化、クラウド化の実現に向けた具体的な進め方を基本計画としてまとめる工程である。
①自治体職員による活用
基本計画を策定する際には、目指すべきシステムの姿や、それを実現するためのスケ
ジュール（実施期間）、調達の考え方などを具体化する必要がある。それらを具体化する際に、大規模自治体クラウド化モデルの内容を活用する。
大規模自治体クラウド化モデルは、特定の自治体や事業者に固有の内容ではないことから、オープンで公平な調達を実施することを担保することができる。
また、大規模自治体クラウド化モデルは、すでに大規模自治体で実現し、実際にコスト削減効果を上げた事例をもとにしているため、実現可能な姿であることの裏づけにもなると考える。
基本計画書の主な記載事項を以下に挙げる。
A) 新システムの構成・基本方針
B) 業務システムの再構築方針
C) 調達の方針
D) システム再構築に係る体制
E) 構築スケジュール
各記載事項について、具体的な活用方法として以下を想定している。
A) 新システムの構成・基本方針『基本的な考え方』の「アーキテクチャ」「運用」や『仕様』の「アーキテクチャ」「運用」の記載内容を、新システムの全体構成や基本方針を検討する際の参考とする。
B) 業務システムの再構築方針『仕様』の「アーキテクチャ」、『行動計画』の留意事項、『ノウハウ集』に記載する業務システムの構築の考え方を、業務システムの再構築方針を検討する際の参考とする。
C) 調達の方針『基本的な考え方』の「調達」や『仕様』の「調達」の記載内容を、業務シス
テムの再構築に関する調達の方針を検討する際の参考とする。

30

D) システム再構築に係る体制『基本的な考え方』の「体制」や『仕様』の「体制」の記載内容を、体制検討の際の参考とする。さらに、運用に関する体制については、事業者間の役割分担の検討が難しい場合があり、『ノウハウ集』の記載を参考にできる。
E) 構築スケジュール『行動計画』で示す作業フローと作業の留意点を、スケジュール検討の際の参考とする。
基本計画書の記載において、大規模自治体クラウド化モデルが活用可能な部分を一覧に
まとめる。
表 2-2

○

ノウハウ集

○ ○
○

行動計画

体制

調達

運用

○ ○

アーキテクチャ体制

新システムの構成・基本方針
業務システムの再構築方針
調達の方針
システム再構築に係る体制構築スケジュール

調達基本計画書の記載事項

活用可能な
大規模自治体クラウド化モデル
基本的な
仕様
考え方
運用

1
2
3
4
5

アーキテクチャ№

基本計画書に対する大規模自治体クラウド化モデルの活用可能箇所

○ ○
○

○

○

○
○

（２）要件定義構築するシステムの要件や、運用方法、体制等を明確にし、新システムの調達仕様書としてまとめ、構築や運用を請け負う事業者を選定する工程である。なお、要件が定まらない場合等は RFI での情報収集が必要となる。
（ア）RFI（情報提供依頼書）の作成／提供
必要な情報を収集するために自治体が RFI を作成し、それに対して事業者が該当する情報の提供を行う。
①自治体職員による活用
RFI は、作成した基本計画の妥当性等を検証するため、必要な情報を事業者から入手することを目的とする。RFI で入手した情報等をもとに RFP の作成を行うこととなるため、より具体的で正確な情報を入手することが必要となるが、そのためには、自治体側の考え方や検討内容を適切に提供することが重要となる。そこで、RFIにおいて、自治体から情報を提供する際に大規模自治体クラウド化モデルを活用する。
31

参考として、一般的に想定される RFI の実施目的を以下に記載する。
一般的な RFI の実施目的としては、以下の 3 つが想定される。


新システム導入における要求内容の妥当性検証
新システムの目指す姿やスケジュール等における要求内容の妥当性を検証するために、事業者からの意見等を収集する。

新システムの開発、保守、運用に関する概算費用の算定
共通基盤等の開発・保守および統合運用に関する概算費用を算定するために、費用の見積を入手する。

パッケージシステムの適用可否の判断
パッケージシステムの適用可否などを判断するために、事業者が保有するパッケージシステムについて、地域情報プラットフォーム標準仕様への準拠
状況、要求機能に対する対応（カスタマイズ要否）、自治体への導入実績等を調査する。

RFI の際には、自治体側の考え方や検討内容を自治体側から提供する必要がある。
上記に挙げた RFI の実施目的に対しては、提供情報は大きく 3 つに区分できる。各区分と、区分ごとの提供情報を以下に記載する。
ⅰ）新システム導入における前提事項
ⅰ-1 導入目的
ⅰ-2 対象業務システム
ⅰ-3 アーキテクチャの考え方
ⅰ-4 調達の考え方
ⅰ-5 運用の考え方
ⅰ-6 体制の考え方
ⅰ-7 構築期間
ⅱ）新システムに関する情報
ⅱ-1 機能要件
ⅱ-2 運用要件
ⅱ-3 システム構成案
ⅱ-4 スケジュール案
ⅲ）現行システムに関する情報
ⅲ-1 現行システム構成
ⅲ-2 データ連携一覧
ⅲ-3 処理件数
ⅲ-4 リソース使用状況

32

RFI を行う際は、これらの情報から RFI の目的に応じて必要な情報を選択し、提供することとなる。各目的について、自治体から提供する情報を以下に記載する。
情報の番号（ⅰ-1、ⅰ-2･･･）が同じ場合は同じ情報を表しており、同じ情報を複数の目的について利用することが可能である。
なお、RFI では、事業者から提供される情報の比較検討がしやすいように、あらかじめ回答フォーマットを提示して情報提供依頼を行うことが有効であるため、RFIの実施目的ごとに、あらかじめ提供するフォーマットの例も併せて記載する。
表 2-3 RFI の実施目的ごとの提供情報と回答フォーマット例
№
1

2

RFI の
実施目的
新システム
導入におけ
る要求内容
の妥当性検
証

新システム
の開発、保
守、運用に
関する概算
費用の算定

自治体から提供する情報提示する回答フォーマット例ⅰ）新システム導入における前提事項
ⅰ-1 導入目的
ⅰ-2 対象業務システム
ⅰ-3 アーキテクチャの考え方
ⅰ-4 調達の考え方
ⅰ-5 運用の考え方
ⅰ-6 体制の考え方
ⅰ-7 構築期間
ⅱ）新システムに関する情報
ⅱ-1 機能要件
ⅱ-2 運用要件
ⅲ）現行システムに関する情報
ⅲ-1 現行システム構成
ⅰ）新システム導入における前提事項
ⅰ-1 導入目的
ⅰ-2 対象業務システム
ⅰ-3 アーキテクチャの考え方
ⅰ-4 調達の考え方
ⅰ-5 運用の考え方
ⅰ-6 体制の考え方
ⅰ-7 構築期間
ⅱ）新システムに関する情報
ⅱ-1 機能要件
ⅱ-2 運用要件
ⅱ-3 システム構成案
ⅱ-4 スケジュール案
ⅲ）現行システムに関する情報
ⅲ-1 現行システム構成
ⅲ-2 データ連携一覧
ⅲ-3 処理件数
ⅲ-4 リソース使用状況

・意見書〔記載内容例〕
 新システムの妥当性（実現可能性）に関する見解
 新システムの実現に有益だと考える事業者の保有製品や提供可能サービスの提案

33

・概算見積書〔見積項目例〕
 ハードウェア（標準価格、導入据付費用、年間保守費用）
 ソフトウェア（標準価格、カスタマイズ費用、年間保守費用）
 年間運用費用

№
3

RFI の
実施目的
パッケージ
システムの
適用可否の
判断

自治体から提供する情報提示する回答フォーマット例ⅰ）新システム導入における前提事項
ⅰ-1 導入目的
ⅰ-2 対象業務システム
ⅰ-3 アーキテクチャの考え方
ⅰ-7 構築期間
ⅱ）新システムに関する情報
ⅱ-1 機能要件
ⅱ-3 システム構成案
ⅱ-4 スケジュール案
ⅲ）現行システムに関する情報
ⅲ-2 データ連携一覧
ⅲ-3 処理件数

・地域情報プラットフォーム標準仕様への準拠状況・要求機能対応表〔回答項目例〕
 要求機能に対するパッケージシステムの対応を改修量等で定量的に評価したもの※評価基準をあらかじめ提示
する≪評価基準例≫
 標準的な機能として実装
 設定により対応
 軽微な改修により実現
 大幅な改修により実現
・導入実績一覧〔回答項目例〕
 導入年月 導入自治体名※自治体名を明示できない場
合は、人口規模と団体区分（政令指定都市・中核市・特例市・一般市）のみでも可RFI においては、自治体から提供する情報を準備する際に大規模自治体クラウド化モデルを活用することが可能であると考える。
特に、自治体から提供する情報のうち、「ⅱ）新システムに関する情報」について
大規模自治体クラウド化モデルが活用可能と考える。
なお、「ⅰ）新システム導入における前提事項」については、基本計画書からの抜粋によって提供情報を整備することが可能であると考える。また、「ⅲ）現行システ
ムに関する情報」については、各自治体がそれぞれのシステム内容に応じて整理するものとなる。
自治体から提供する情報のうち、「ⅱ）新システムに関する情報」として整理した
以下の 4 つの情報について、提供情報の整備において想定する、大規模自治体クラウド化モデルの具体的な活用方法を記載する。
A) 機能要件
B) 運用要件C) システム構成案
D) スケジュール案
A) 機能要件『基本的な考え方』の「アーキテクチャ」や『仕様』の「アーキテクチャ」の記載内容を、共通基盤の機能要件を記載する際の参考とする。
34B) 運用要件『基本的な考え方』の「運用」や『仕様』の「運用」の記載内容を、共通基盤及び業務アプリケーションにおける運用要件（運用範囲や体制を含む）
を記載する際の参考とする。
また、運用ルールの統一や障害対応の考え方については『ノウハウ集』の記載内容を参考にできる。
C) システム構成案『基本的な考え方』の「アーキテクチャ」や『仕様』の「アーキテクチャ」の記載内容を、システム構成（ネットワーク構成を含む）を検討する際の参考とする。
また、システム構成を検討する際の仮想化の考え方については、『ノウハウ集』の記載内容を参考にできる。
D) スケジュール案『行動計画』の作業フローの記載内容を、共通基盤の構築スケジュールを検討する際の参考とする。
RFI において、自治体から提供する新システムに関する情報に対して、大規模自治体クラウド化モデルを活用可能な部分を一覧にまとめる。
表 2-4 RFI における大規模自治体クラウド化モデルの活用可能箇所
ノウハウ集

行動計画

体制

調達

○
○

○

運用

アーキテクチャ

○

体制

機能要件
運用要件
システム構成案
スケジュール案

調達

新システムに
関する情報

運用

1
2
3
4

RFI において自治体から提供する情報（新システムに関する情報）アーキテクチャ№

活用可能な
大規模自治体クラウド化モデル
基本的な
仕様
考え方

○

○
○

○
○

②事業者による活用
事業者が RFI に対する情報提供を行う際は、どのような情報を提供すべきか整理した上で適切な情報提供を行う必要があり、事業者側の作業負荷も大きくなるもの
と考える。
35

そこで、
『基本的な考え方』や『仕様』をもとに、提供情報を作成したり、あらか
じめ、提供可能な情報を具体的な要件にそって雛形として準備しておくことで、情報提供にかかる作業負荷を軽減できる。
（イ）RFP（提案依頼書）の作成／提案
自治体は、システムの導入にあたって事業者に対して提案を依頼するために RFPを作成する。事業者は RFP をもとに提案書を作成する。
①自治体職員による活用
調達時には、基本計画等で検討したシステムの目指す姿をより具体的にする必要がある。また、求める仕様が正しく提供されるようにするためには、要求仕様として適切に記載することが重要となる。
そこで、RFP を作成する際に、大規模自治体クラウド化モデルを活用する。
なお、参考として、共通基盤の開発・保守、及び統合運用を調達する場合を想定
し、一般的に RFP に記載すると思われる事項を以下に記載する。
表 2-5
№
1
2
3
4

共通基盤の調達における RFP の一般的な記載事項

RFP 記載項目
本編
概要
調達件名
目的

5
6

用語の定義
基本的な考え方

7
8
9
10
11
12
13

本調達の範囲及び作業内容
スケジュール
作成物
契約形態・支払方法
履行場所
再委託
特記事項

14
15

機能要件
共通基盤の機能に関する事
項補足

システム導入に至った背景（現状の問題点や解決の方向性等）及び、システム導入の目的を記載する。
固有の用語、専門用語等の意味を記載する。
システムの全体像と目指す姿、調達の考え方等について記載する。

受注者側の作業、納入成果物を記載する。

第三者への再委託に関する事項を記載する。
入札制限、個人情報保護や機密保持に関する事項
等の留意事項を記載する。
ジョブ管理機能、統合運用管理機能、ユーザ認証
機能、データ連携基盤など、共通基盤に求める機能の一覧と各機能の要求事項を記載する。
※共通基盤の機能の詳細を№60「共通基盤の機能要求一覧」に記載する。
※共通基盤の機能を利用する（共通基盤上に搭載する場合も含む）業務アプリケーションに関する情報を№61「対象業務システム一覧」、№62「データ連携一覧」に記載する。

36

№
16
17
18
19
20
21
22
23
24
25
26

RFP 記載項目
非機能要件
規模・性能要件
規模要件
性能要件
信頼性等要件
信頼性要件
拡張性要件
情報セキュリティ要件
権限要件
情報セキュリティ対策
情報システム稼働環境

27

全体構成

28

ハードウェア構成

29

サーバ類

30
31
32
33

クライアント端末類
プリンタ
ネットワーク機器
ソフトウェア構成

34
35

ネットワーク環境
テスト要件

36
37
38

移行・教育要件
移行に係る要件教育に係る要件

39

運用要件

40
41
42
43
44

統合運用の範囲と作業項目
運用スケジュール
運用体制
運用の役割分担
データ管理要件45

運用施設・設備要件

補足
規模・性能要件、信頼性等要件、情報セキュリティ
要件等の非機能要件を記載する。
※各要件に対する具体的な要求レベルは№63「非機能要求一覧」に記載する。なお、非機能要求一
覧を作成する際は、「平成 25 年度「非機能要求グレード（地方公共団体版）利用ガイド」」（財団法
人 地方自治情報センター）の「活用シート」を利用することで非機能要件を網羅的に定義できる
等のメリットが得られる。
バックアップも含めたシステムの稼働環境に関する要件を記載する。
なお、現行のシステムの状況も併せて記載する。
※現行システムの状況の詳細については№64「現行システムの情報」に記載する。
ハードウェア、ソフトウェア、ネットワーク等、システムが稼働する環境全体の構成図を記載する。
共通基盤（業務アプリケーションを共通基盤上に搭載する場合は業務アプリケーションも含む）を稼働させるために必要となるハードウェアについて記載する。
DB サーバ、Web／AP サーバ、ストレージ（バックアップ装置含む）等について記載する。

共通基盤（業務アプリケーションを共通基盤上に搭載する場合は業務アプリケーションも含む）を稼働させるために必要となるソフトウェア（OS、DB など）について記載する。
テストに係る要件（要件に適合しているか検証す
る際の合否の判断基準等）を記載する。

共通基盤の導入に伴う、新しい運用フローや操作について、業務担当者・運用担当者向けに実施する教育に関する要件を記載する。
新システムに共通的な運用作業について、システ
ムの操作・監視、データ管理、運用施設・設備等、統合運用に関する要件を記載する。

電子媒体により管理するデータの要件（対象デー
タ、保管期限、等）を記載する。
設置場所となるデータセンタに求める施設要件を
記載する。

37

№
46

RFP 記載項目
保守要件

47
48
49
50

保守の範囲と作業項目
ソフトウェア保守要件
ハードウェア保守要件
サービスレベル要件

51
52

作業の体制及び方法
作業体制

53
54
55
56
57

開発方法
開発管理
開発工程
スケジュール
導入

58
59
60
61

瑕疵担保責任別紙
共通基盤の機能要求一覧
対象業務システム一覧

62

データ連携一覧63

非機能要求一覧64

現行システムの情報

65
66
67

参考資料
地域情報プラットフォーム標
準仕様
情報セキュリティ対策基準

補足
共通基盤の保守に関する要件（作業内容や頻度等）を記載する。

求めるサービスレベルの対象、考え方、SLA 11の運用、評価の流れ、サービスレベル項目案等を記載する。
開発体制に関する要求事項（要求する人材の要件、人数、役割、保有すべき資格等）を記載する。

開発したシステムを本稼働させるために必要となる作業について記載する。
瑕疵担保責任の期間と内容について記載する。
共通基盤の詳細な機能要件を記載する。
共通基盤の機能を利用する（業務アプリケーショ
ンを共通基盤上に搭載する場合も含む）想定の業
務アプリケーションの一覧を記載する。
共通基盤を介して行われると想定する業務アプリ
ケーション間のデータ連携の一覧を記載する。
非機能要件について、具体的な要求レベルを記載する。
機器構成、稼働実績（稼働時間、処理件数・処理時間、等）等の現行のシステムに関する情報を記載する。

自団体の情報セキュリティ対策基準があれば添付する。

RFP の作成における大規模自治体クラウド化モデルの活用には、大きく以下の 2
つの活用方法がある。
A) RFP を実際に作成する前に、調達の単位や順序を決定する必要があるため、その検討の際に『基本的な考え方』の「調達」や『仕様』の「調達」の記載内容を参考にする。
B) RFP を作成する際に『基本的な考え方』『仕様』『行動計画』『ノウハウ集』の記載内容を参考にする。
『基本的な考え方』は調達するシステムの基本的な考え方

11

SLA：サービスの品質に対する利用者側の要求水準と提供者側の運営ルールについて明文化したもの。（総務省「電子自治体の取組みを加速するための１０の指針」より引用）
38

を記載する際に活用することができる。
『仕様』は調達するシステムの機能や運用、体制等の要件を記載する際に活用することができる。『行動計画』は調達するシステムの導入スケジュールを記載する際に活用することができる。
『ノウハ
ウ集』は上記に挙げた調達するシステムの基本的な考え方、システムの機能や運用、体制等の要件、導入スケジュールなどを記載する際に、更に具体的な内容の検討を行う場合に活用することができる。
B)の RFP を作成する場合について、RFP の記載事項をもとに、大規模自治体クラウド化モデルが活用できる部分を一覧としてまとめる。
なお、大規模自治体クラウド化モデルでは、大規模自治体に共通的または特徴的な内容を記載対象としており、大規模自治体に特化しない事項や自治体ごとの事情に応じて内容が大きく異なる事項については記載の対象外としている場合がある。
そこで、RFP の一般的な記載事項に対して、大規模自治体クラウド化モデルが該当しない事項については、「2.5.1

オープン化・クラウド化に関する既存ドキュメント」に記載する各種ドキュメントを参照いただきたい。
表 2-6 RFP 記載事項に対する大規模自治体クラウド化モデルの活用可能箇所
ノウハウ集

行動計画

39

○

○

体制

○

調達

○ ○ ○ ○ ○運用

アーキテクチャ

体制

本編
概要
調達件名
目的
用語の定義
基本的な考え方本調達の範囲及び作業内容
スケジュール
作成物
契約形態・支払方法
履行場所
再委託
特記事項
機能要件
共通基盤の機能に関する事項
非機能要件
規模・性能要件

調達

RFP 記載項目

運用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

アーキテクチャ№

活用可能な大規模自治体
クラウド化モデル
基本的な
仕様
考え方

○

○

○
○

○
○

○

○
○

○

○
○
○

○

○
○

○
○

○

○

○

○

○

○

40

ノウハウ 集

行動計画

体制

調達

運用

○

アーキテ クチャ

体制

規模要件
性能要件
信頼性等要件
信頼性要件
拡張性要件
情報セキュリティ要件
権限要件
情報セキュリティ対策
情報システム稼働環境
全体構成
ハードウェア構成
サーバ類
クライアント端末類
プリンタ
ネットワーク機器
ソフトウェア構成
ネットワーク環境
テスト要件
移行・教育要件
移行に係る要件教育に係る要件
運用要件
統合運用の範囲と作業項目
運用スケジュール
運用体制
運用の役割分担
データ管理要件
運用施設・設備要件
保守要件
保守の範囲と作業項目
ソフトウェア保守要件
ハードウェア保守要件
サービスレベル要件
作業の体制及び方法
作業体制
開発方法
開発管理
開発工程
スケジュール
導入

調達

RFP 記載項目

運用

18
19
20
21
22
23
24
25
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
52
53
54
55
56
57

アーキテ クチャ№

活用可能な大規模自治体
クラウド化モデル
基本的な
仕様
考え方

ノウハウ 集

行動計画

体制

調達

運用

アーキテ クチャ

体制

調達

運用

58
59
60
61
62
63
64
65
66
67

アーキテ クチャ

RFP 記載項目№

活用可能な大規模自治体
クラウド化モデル
基本的な
仕様
考え方

瑕疵担保責任別紙
共通基盤の機能要求一覧
対象業務システム一覧
データ連携一覧
非機能要求一覧
現行システムの情報
参考資料
地域情報プラットフォーム標準仕様
情報セキュリティ対策基準②事業者による活用
RFP に対する提案自体は、大規模自治体クラウド化モデルの内容に限定せず、各事業者が各社独自の工夫点、優位性を提示するものであるが、基本的な提案事項の抜け漏れを防ぐためや、あらかじめ雛形として準備して各提案時の作業負荷を軽減するためなど、提案時に大規模自治体クラウド化モデルの『基本的な考え方』『仕様』
を活用することができる。
なお、RFP の一般的な記載事項に対して、大規模自治体クラウド化モデルを活用できる部分については、「表 2-6 RFP 記載事項に対する大規模自治体クラウド化モ
デルの活用可能箇所」の記載内容と同様である。

（３）設計・構築
RFP に基づき、実際にシステムを構築・導入する工程である。調達範囲については事業者が実際の作業を行い、自治体は各作業において設計内容等の承認を行う。
①自治体職員による活用
自治体職員は、事業者が設計した内容について、自治体として実現方式の妥当性を判断し、承認する必要がある。
そこで、設計の方針を検討する場合の前提知識として、『仕様』の「アーキテクチャ」の記載内容や、『ノウハウ集』を参考にする。
41

②事業者による活用
システム構成などは調達・提案の時点で概ね決定されているものではあるが、詳細な実現方式は設計時に検討が必要になるものと考える。
そこで、設計・構築時において、実現方式の例として、『仕様』の「アーキテクチャ」の記載内容や、『ノウハウ集』の解決事例を参考にする。
なお、自治体職員と事業者の間で設計内容のレビュー等を行う場合に、自治体職員と事業者の間の認識のずれや、検討内容の漏れを防ぐために、『仕様』や『ノウハウ集』を共用
資料として参考することも有効であると考える。

42

2.2.4. 大規模自治体のシステムにおける共通基盤の有効性（１）共通基盤の定義
本章で想定する共通基盤とは、各業務アプリケーションで共通的に必要となる機能等を一元的に備えたものであり、業務アプリケーションが動作するために必要なシステムは、
業務アプリケーションそのものと、共通基盤の 2 つによって構成されるものと考える。
共通基盤のイメージを以下に示す。

図 2-3

共通基盤のイメージ「共通基盤」と「業務アプリケーション」はそれぞれ以下のように定義する。
「共通基盤」


ハードウェアは、業務アプリケーションを稼働させるために必要な機器である。



ソフトウェアは、ミドルウェア（OS、DB、アプリケーション共通機能）、業務間のデータ連携基盤、統合運用である。

「業務アプリケーション」


業務アプリケーションは、自治体に必要な住民情報、税務、国民健康保険、国民年金、福祉等の業務を遂行するために必要なアプリケーションである。

従来の業務アプリケーションの導入においては、その業務アプリケーションが動作するために必要となるハードウェア、ミドルウェアを業務アプリケーションごとに装備し、業務機能部分に加えて、他の業務アプリケーションと情報連携するための機能も各業務アプ
リケーション内に備えていた。また、運用についても業務アプリケーションごとに行っていた。それによって、以下のような問題が発生していた。


類似した機能をそれぞれの業務アプリケーションで保有することとなり、重複投資が発生する。
43



個別に冗長化 12の仕組みを導入するため、通常は稼働していないハードウェアが多い。



業務アプリケーション間の情報連携を個別に行うため、連携が複雑になる。



個別に運用を行うため、運用が非効率になったり、運用品質が低下したりする。

これらの問題に対し、共通基盤は、業務アプリケーションごとに装備していた機能のう
ち複数の業務アプリケーションで共通的に必要となる機能、業務アプリケーションが動作するために必要となるハードウェアや DB などのミドルウェア、等を一元的に装備、統合することを目的としている。

図 2-4

12

共通基盤導入の考え方

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

（２）共通基盤の有効性
大規模自治体のシステムに特徴的な内容と、それに基づく共通基盤の有効性の全体概要を以下に示す。

図 2-5

大規模自治体の状況を要因とした共通基盤の有効性の概要

システムの導入において、大規模自治体と中小規模自治体の大きな違いは、大規模自治
体は、中小規模の自治体と比べて「人口が多く、制度・体制が異なる」ことである。
この違いにより、大規模自治体のシステムには、中小規模自治体と比べて、広範囲な業
務要件に対応することや、大量データを処理することが求められる。
広範囲な業務要件に対応するため、システムには大規模自治体特有機能が必要になることから選択できるパッケージシステムが少なくなる。また、取り扱うデータが大量になることから、中小規模の自治体ではオンラインで処理するような事務について、バッチでの一括処理が求められるようになる。
このような広範囲な機能を、オールインワンパッケージで対応しているパッケージシス
テムは少なく、大規模自治体は、業務ごとにパッケージシステムを選択することとなる。
このため、マルチベンダ 13による業務システム導入が必要となる。また、マルチベンダになることで、事業者間の調整が重要となる。
また、大量データの処理については、処理を時間内に行うために、性能、信頼性を重視したシステムが必要となる。
13

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

しかし、このようなマルチベンダによる業務システム導入や、性能、信頼性を重視したシステムの導入を実現しようとすると、コストや手間の増加といった課題が発生する。
そこで、これらの課題を解決する策として共通基盤の導入が有効となる。
マルチベンダによる業務システム導入や性能、信頼性を重視したシステムの導入に対する課題と、その課題に対して、共通基盤で実現できることについて以下に示す。
①マルチベンダ環境における課題と共通基盤で実現できること【課題】
業務システムごとに業務間のデータ連携を行うと、調整や開発・改修の手間がかかり、コストが増加する。



メインフレームでは一元的な運用が行えていたが、マルチベンダ環境において業務システムごとに運用を行うと、運用の分散による手間が発生したり、運用の品質低下が起こる可能性がある。

【共通基盤で実現できること】


マルチベンダ環境において、共通基盤を導入することで、業務間接続コストの抑制、運用一元化による効率的な運用が実現できる。

②性能、信頼性を重視したシステム構成における課題と共通基盤で実現できること【課題】


性能を確保するために、業務システムごとに十分なハードウェアを装備しようとすると、必要なハードウェアが多くなり、コスト増につながる。



信頼性を考慮し、業務システムごとにハードウェアの冗長化等の対策を行うと、ハードウェアが大幅に増え、コスト増につながる。

【共通基盤で実現できること】


共通基盤を導入することで、ハードウェアリソースやミドルウェアライセンスの有効活用が実現できる。

なお、上記の通り、大規模自治体のオープン化、クラウド化の際に共通基盤の導入は有効であるが、共通基盤はオープン化以前のメインフレームと同等の機能を備えるものではない。オープン化、クラウド化によって、業務システムの分散化やマルチベンダによる業務システム導入が進んだ際に、業務システム間の連携や運用を効率的に行うための機能を装備するものである。

46

（３）共通基盤の導入効果
前述した通り、共通基盤を導入することで、業務間接続コストの抑制や運用一元化による効率的な運用、ハードウェアリソースやミドルウェアライセンスの有効活用が実現できるが、具体的には以下のような効果が得られる。
【業務間のデータ連携基盤の導入効果】


業務間連携の一元化により、業務間接続コストが低減できる。



地域情報プラットフォーム標準仕様に準拠することで、業務間の連携がさらに容易になるとともに、業務アプリケーションの競争性の確保につながる。



連携先の業務アプリケーションとの間の連携方式等を個別に考慮する必要がな
くなり、業務アプリケーションを自由に選択することが可能となる。



庁内のデータ連携についてデータ連携基盤を導入しておくことで、大規模自治体のシステムが最終的に目指すべき姿であるハイブリッドクラウドを実現する
場合にも、この連携機能を活用することができ、ハイブリッドクラウドへの拡張が容易になる。

【統合運用の導入効果】


メインフレームでは実現されていた運用の一元化を、マルチベンダ環境においても実現することができ、運用の効率化が図られる。



業務アプリケーションごと、事業者ごとに運用が異なることによる運用品質の低下を防ぐことができる。

【ミドルウェア統合の導入効果】
ミドルウェアを統合することにより、ミドルウェアのライセンス料が削減できる。ただし、統合する範囲は、現状のシステム等の状態を踏まえ、自治体ごとに検討が必要。

【ハードウェア統合の導入効果】
ハードウェアを統合することにより、ハードウェアリソースの有効活用が可能となる。ただし、統合する範囲は、現状のシステム等の状態を踏まえ、自治体ごとに検討が必要。

また、上記のような導入効果に加えて、共通基盤を前提に導入を進めることで、庁内のシステムを所管する部門と業務を所管する部門等の間で目指すべき姿の方向性が統一されるという効果も期待できる。

47

2.3.

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

大規模自治体クラウド化モデルは、以下の 4 つで構成する。
①基本的な考え方②仕様③行動計画④ノウハウ集本報告書では、各構成物の記載事項について示す。
各構成物の内容については、大規模自治体クラウド化モデルの考え方を示す①基本的な考え方についてのみ、本報告書で記載する。
②仕様、③行動計画、④ノウハウ集の内容については別冊 1「大規模自治体クラウド化モデル」を参照のこと。
なお、大規模自治体クラウド化モデルは、オープン化、クラウド化を実現した先行事例
から共通的な事項を抽出したものであり、今後オープン化、クラウド化に取り組む自治体
は、必ずしもこのモデルの通りに実現する必要はない。各自治体の現状のシステム等の状態を踏まえて必要となる事項を取捨選択し、当該自治体に最適となるような実現方式を検討されたい。
①基本的な考え方
大規模自治体クラウド化モデルの考え方を示す。
本章において、大規模自治体のシステムが目指すべき姿は「IaaS 以上のクラウドが実現した姿」であり、IaaS 以上のクラウドの実現形態としては、IaaS、PaaS、SaaS などが想定される。大規模自治体クラウド化モデルでは、これらの実現形態を問わず、前節「2.2.4
大規模自治体のシステムにおける共通基盤の有効性」に記載したように、大規模自治体シ
ステムにおける、オープン化、クラウド化には共通基盤の導入が有効であると考え、共通基盤を導入したシステム構成を前提としている。
大規模自治体クラウド化モデルの基本的な考え方については、以下の 4 つの区分に分けて記載する。
A) アーキテクチャ
B) 調達
C) 運用
D) 体制
以下に区分ごとの基本的な考えを記載する。
48A) アーキテクチャ
アーキテクチャについては、自治体の業務遂行に必要なシステムを業務部分と共通基盤の大きく 2 つに分けて整理する。
業務部分は、自治体に必要な住民情報、税務、国民健康保険、国民年金、福祉等の業務を遂行するために必要な機能を備えた業務アプリケーションと、業務アプリ
ケーションが動作するために必要となるハードウェア、ミドルウェアで構成される。
業務アプリケーションは業務（分野）ごとに装備することとするが、同じ分野の業務アプリケーションをまとめて導入する場合も想定されるため、業務（分野）の単位は自治体の方針によって異なるものと考える。
共通基盤は、各業務アプリケーションで共通的に必要となる機能等を一元的に備える。業務アプリケーションで共通的に必要となる機能としては、業務アプリケー
ション間のデータ連携を仲介する機能である「業務間のデータ連携基盤」と、運用を統合的に行うために必要となる各種の機能である「統合運用管理機能」がある。
また、共通基盤には、これらの機能が動作するためのハードウェア、ミドルウェ
アも含む。
なお、本章では、大規模自治体のシステムが当面目指す姿を「IaaS 以上のクラウドが実現した姿」としているが、この姿が実現した場合、ハードウェアやミドルウェ
アの統合化、仮想化も実現されているものと考える。そのため、大規模自治体クラウド化モデルでも、基本的にはハードウェアやミドルウェアの統合化が行われているものと考える。
そこで、業務アプリケーションが動作するために必要となるハードウェア、ミド
ルウェアと、共通基盤に備える機能が動作するために必要となるハードウェア、ミドルウェアは、それぞれ統合化されていることとする。
また、共通基盤では、業務アプリケーションが動作するために必要となるハード
ウェア、ミドルウェアを含める場合もある。共通基盤に業務アプリケーションが動作するために必要となるハードウェア、ミドルウェアを含める場合は、ハードウェ
ア、ミドルウェア全体を統合化することが可能となる。
なお、ハードウェア、ミドルウェアの統合範囲については、各自治体が、現状のシステム等の状態を踏まえ最適な統合範囲を選定する必要がある。
共通基盤と業務アプリケーションの構成イメージを以下に示す。

49

図 2-6

共通基盤と業務アプリケーションの構成イメージ＊１．同じ分野の業務アプリケーションをまとめて導入する場合も想定されるため、業務の単位は自治体の方針によって異なる。
＊２．ハードウェア、ミドルウェアの統合範囲については、業務アプリケーションのハードウェア、ミドルウェアを含む場合と含まない場合が想定されるため、各自治体が、現状のシステム等の状態を踏まえ最適な統合範囲を選定する。
これらの考え方をまとめ、アーキテクチャに関する基本的な考え方は以下の通りとする。
「共通基盤」と「業務アプリケーション」を分離し、「共通基盤」上に「業務アプリケーション」を搭載、もしくは「業務アプリケーション」が「共通基盤」の機能を利用する。



共通基盤において、共通部分を一元管理する。

ハードウェア、ミドルウェアの統合化・仮想化を行う。

地域情報プラットフォーム標準仕様に準拠する。

B) 調達


「共通基盤」と「業務アプリケーション」の調達を分ける。また、「業務アプリ
ケーション」は業務ごとに調達を分ける。

C) 運用


統一的な運用を行う。



コストに留意した最適なデータセンタを選定する。

50

D) 体制【自治体側の体制】


自治体内の関係部署は、「情報システム所管課」、「業務所管課」とする。

「情報システム所管課」は自治体内のシステムの統制（統制する範囲は自治体
によって異なる）を行う部署、「業務所管課」は実際の業務を所管する部署とする。



上記を取りまとめるクラウド推進部会を置く。クラウド推進部会は、首長等の決定権を持つ者を含んだ組織とする。



関係部署に、財政部門、人事部門も含む。

【事業者側の体制】


関係する事業者は、役割の内容によって「基盤事業者」、「業務アプリケーショ
ン事業者」、「運用事業者」の 3 つに分類する。

「基盤事業者」は共通基盤の開発・保守、「業務アプリケーション事業者」は業
務アプリケーションの開発・保守、「運用事業者」はシステム全体の運用に係る業務をそれぞれ請け負うものとする。

②仕様「アーキテクチャ」「調達」「運用」「体制」の区分ごとに、「共通基盤」と「業務アプリ
ケーション」が満たすべき条件（要件）と、要件に対する具体的な実現内容（仕様）を示す。
なお、記載する内容は、すべてを網羅的に記載するのではなく、基本的な考え方を踏ま
え、大規模自治体に特徴的な内容に特化して記載する。また、「仕様」の記載内容は、大規
模自治体がオープン化、クラウド化を推進する際に調達仕様作成の参考にするための粒度に合わせたものとする。

③行動計画
大規模自治体の現在のシステム環境からゴールに至るまでの作業手順を示す。
作業手順については、オープン化・クラウド化の一般的な作業手順のうち、基本計画、
要件定義、設計・構築の 3 つの工程を対象とする。行動計画では、この 3 つの作業項目を、さらに詳細な作業項目に分ける。

51

図 2-7

行動計画の考え方

なお、自治体ごとに、メインフレームかオープン化しているかといった現在のシステムの状態は様々であり、現在のシステム状態に応じて、大規模自治体クラウド化モデルを実現するための作業手順の開始地点や、作業手順の内容が異なるものと考える。そこで、読者である自治体職員が、自団体の状況に応じて、どの作業を実施すればよいのか分かるよ
うに、自治体の現在のシステム状態をパターンに分け、それぞれのパターンに応じて、行動計画での必要な作業項目を明示する。

52

パターン分けについては、まず、メインフレームが残っているかオープン化済みかの大きく 2 つのパターンに分ける。さらにオープン化済みの場合には、共通基盤の導入有無によってパターンを細分化する。これによってパターンは以下の 3 つとなる。


自治体パターン①
メインフレームが残っている状態



自治体パターン②
オープン化は実現済みであるが、共通基盤は導入されていない状態



自治体パターン③
オープン化は実現済み、共通基盤も導入されているが、自庁内にシステムを設置している状態

自治体のパターン分けのイメージを以下に示す。

図 2-8

自治体の現在のシステム状態によるパターン分けのイメージ

なお、ゴールの実現においては、必ずしも上記の段階を踏んで実現するものではなく、自治体パターン①の状態から自治体パターン③の状態を目指す（オープン化と共通基盤導入を同時に進める）といった進め方も可能である。

53

作業手順は、作業フローと作業項目一覧の 2 種類のドキュメントとして提示する。
作業フローと作業項目一覧には以下の事項を記載する。
【作業フロー】
一連の作業手順をフロー図として記載する。
作業フローでは、実施する作業項目に加え、作業を実施する必要があるかどうかなどの判断が必要な場合は分岐を記載する。
なお、作業期間の目安も記載するが、作業期間は自治体の規模や開発規模等により変動するため、参考として記載している。

図 2-9

行動計画（作業フロー）のイメージ

54

【作業項目一覧】
作業フローの各工程について、スケジュールの策定や作業実施の際に留意すべき事項がある場合は記載する。なお、留意すべき事項については、「④ノウハウ集」に記載する解決事例も参考となるため、該当する箇所にノウハウ集とのリンク（ノウ
ハウ集の解決事例の番号）も記載する。
また、詳細化した作業項目ごとに、自治体のパターンに応じた作業実施の要否について記載する。

図 2-10

行動計画（作業項目一覧）のイメージ④ノウハウ集大規模自治体クラウド化モデルを実現する際に想定される、懸念事項や課題を取り上げ、それに対する解決事例をノウハウとして示す。
「③行動計画」の作業項目一覧に、作業項目ごとの留意事項に関連するノウハウ集の解決事例（解決事例の番号）を記載しているため、行動計画の参照と合わせてノウ
ハウ集を参照することを想定している。また、ノウハウ集にも冒頭に想定される懸念事項や課題の一覧を記載するため、その一覧から参照したい解決事例を探して参照することも可能である。

55

2.4.

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

大規模自治体クラウド化モデルの策定にあたっては、すでに、オープン化、クラウド化を実施し、実際に効果を上げている大規模自治体の先行事例として、北九州事例と豊島事
例を参考とした。
各事例の詳細については、大規模自治体クラウド化モデルの構成を参考に、概略、仕様、
行動計画、ノウハウ集として整理した。本報告書では、概略のみを記載する。仕様、行動
計画、ノウハウ集の内容については、別冊 2「大規模自治体クラウド化モデルの策定にあたって参考とした事例集」を参照のこと。
2.4.1. 北九州事例
メインフレームからのオープン化、クラウド化を実施し、基幹システム全体の運用経費について、年間約 5 億円の削減効果を上げた実現例であることから、北九州市を事例とする。なお、北九州事例は、北九州市の実施内容をもとに、クラウド化への修正を行ったものとしている。

（１）北九州事例の概略


人口約 97 万人の政令指定都市



平成 18 年度から平成 22 年度にかけて、メインフレームからのオープン化、自庁クラウド化を実施（再編計画実施）

メインフレーム以外にも、庁内各部署において独自に整備した情報システムが多数存在した。再編計画では、両方のシステムを対象とした。公開された仕様、製品で構築「ハードウェアおよび共通ソフトウェア」と「業務アプリケーション」の完全分離を徹底させ、「次期システム基盤」上に「業務アプリケーション」を搭載



平成 29 年 7 月に基幹システム全体を民間データセンタに移行する予定

図 2-11北九州事例の共通基盤と業務アプリケーションの構成イメージ56

2.4.2. 豊島事例
メインフレームからのオープン化、クラウド化を実施し、イニシャル費とリース費、運用費などの減により 5 年で総計 2 割に近い削減効果を上げられる見込みであることから、豊島区を事例とする。
（１）豊島事例の概略
人口約 28 万人の特別区

平成 20 年度から平成 26 年度にかけて、メインフレームからのオープン化、クラウ
ド化を、民間データセンタを活用して実施（システム再構築計画による）

メインフレーム以外にも、庁内各部署において独自に整備した情報システムが多数存在した。再編計画では、両方のシステムを対象とした



業務ごとに事業者選定を実施。地域情報プラットフォーム標準仕様準拠の製品導入を必須とした

最初に構築したシステム共通基盤の情報連携基盤や共通データ基盤、文字基盤などの活用を各業務システムに求めた

平成 25 年に住基関連システムを世田谷区とともに PaaS クラウドで構築した

図 2-12

豊島事例の共通基盤と業務アプリケーションの構成イメージ

57

2.5.

その他

2.5.1. オープン化・クラウド化に関する既存ドキュメント
大規模自治体に特化しない事項については、すでに、以下のような文献が公開されているので、参照のこと。
表 2-7

オープン・クラウド化に関する既存ドキュメント
オープン・クラウド化に関する既存ドキュメント

平成 25 年度「電子自治体の取組みを加速するための 10 の指針」 総務省
平成 26 年度「電子自治体の取組みを加速するための 10 の指針

総務省

フォローアップ検討会報告書」
平成 26 年度「地方公共団体におけるクラウド導入の取組（平成地方公共団体情報

26 年度改訂版）」

システム機構平成 25 年度「地方公共団体の自治体クラウドの取組を加速する

総務省ための現状分析及び促進方策に関する調査研究報告書」
平成 24 年度「自治体クラウド・情報連携推進のための研修教材」 総務省
平成 23 年度「自治体クラウド推進本部有識者懇談会とりまとめ」 総務省
及び「クラウドサービス導入による効果提案項目（例）」平成 23 年度「自治体クラウドの導入に関する調査研究報告書」

総務省

平成 22 年度「自治体クラウド開発実証調査研究報告書」

総務省

平成 22 年度「自治体クラウド開発実証に係る標準仕様書」

財団法人

地方自

治情報センター
平成 24 年度「自治体クラウドの情報セキュリティ対策等に関す

総務省

る調査研究報告書」
平成 25 年度「地方公共団体の情報システム調達仕様書における財団法人非機能要件の標準化に関する調査研究報告書」

治情報センター

平成 25 年度「非機能要求グレード（地方公共団体版）利用ガイ

財団法人

ド」

治情報センター

平成 25 年度「クラウドサービス利用のための情報セキュリティ

経済産業省

マネジメントガイドライン 2013 年度版」
平成 25 年度「クラウドセキュリティガイドライン活用ガイド
ブック」

58

経済産業省

地方自

地方自