Comments
Description
Transcript
情報システム調達のための技術参照モデル（TRM） 平成
情報システム調達のための技術参照モデル（ＴＲＭ） 平成 24 年度版 別冊２ 自治体編 ∼地方自治体における情報システム調達の考え方∼ 2013 年 4 月 経済産業省 商務情報政策局 情報処理振興課 独立行政法人 情報処理推進機構 1 目次 はじめに ................................................................................................................. 4 ＜地方自治体における情報システム調達のための TRM の位置づけ＞ ............................. 4 第１章 1.1. 本書の活用方法 ..................................................................................... 6 地方自治体におけるシステム調達の基本的な考え方 .............................................. 6 1.1.1. 業務システム構成要素の分離と再構成 ................................................................ 6 1.1.2. 業務パッケージシステムの活用........................................................................... 7 1.1.3. システム更改時の課題 ......................................................................................... 7 1.2. 地方自治体におけるシステム調達の流れ .................................................................. 8 第 2 章 地方自治体における業務システムの動向.................................................. 9 2.1. 業務システムの標準化................................................................................................. 9 2.1.1. デファクトスタンダードの採用............................................................................... 9 2.1.2. 仮想化技術の採用 .................................................................................................... 9 2.1.3. 地域情報プラットフォーム準拠............................................................................. 10 2.1.4. 文字コードやフォントの標準化............................................................................. 10 2.2. 文字情報基盤 ............................................................................................................. 11 2.2.1. 文字情報基盤とは ................................................................................................ 11 2.2.2. 文字情報基盤の実装上の問題点............................................................................. 12 2.2.3. 文字情報基盤の利用............................................................................................... 13 2.3. 情報セキュリティ...................................................................................................... 15 2.3.1. 地方自治体の情報セキュリティについて .............................................................. 15 2.3.2. 地方自治体情報システム役務調達時の情報セキュリティについての留意点 ........ 15 2.3.3. 情報セキュリティと個人情報保護、業務継続計画 ................................................ 16 2.3.4. 情報セキュリティと自治体業務パッケージシステム ............................................ 17 2.3.5. 地方自治体の情報セキュリティ監査実施時についての留意点 .............................. 17 2.3.6. 参照すべき基準・ガイドライン............................................................................. 17 第 3 章 業務アプリケーション調達のポイント........................................................ 19 3.1. 地域情報プラットフォーム ....................................................................................... 19 2 3.1.1. 地域情報プラットフォームとは............................................................................. 19 3.1.2. 地域情報プラットフォームの準拠登録 .................................................................. 20 3.1.3. 地域情報プラットフォーム準拠登録製品の調達時の留意事項 .............................. 21 3.2. 共通基盤 .................................................................................................................... 22 3.2.1. 自治体における共通基盤 ....................................................................................... 22 3.2.2. 統合 DB ................................................................................................................. 22 3.2.3. 共通基盤の構成単位 ............................................................................................. 22 3.2.4. 共通基盤の調達の留意事項 .................................................................................. 24 3.3. 業務パッケージの調達............................................................................................... 24 3.3.1. 自治体業務アプリケーションの特徴 ..................................................................... 24 3.3.2. パッケージシステムの活用 .................................................................................... 25 3.3.3. システム要件定義 .................................................................................................. 26 3.3.4. 共通基盤への接続 .................................................................................................. 26 3.3.5. 業務パッケージシステム調達における文字情報.................................................... 27 3.3.6 業務パッケージシステム調達におけるデータ移行 .................................................. 28 3.4. クラウドサービスの調達 ....................................................................................... 29 3.4.1. 自治体におけるクラウドの活用等 ..................................................................... 30 3.4.2. 自治体におけるクラウド調達の留意事項 .......................................................... 31 第 4 章 インフラ基盤統合化のポイント.................................................................. 33 4.1. サーバインフラの統合化 ........................................................................................... 33 4.2. 端末の共通化 ............................................................................................................. 34 3 はじめに 番号制度の導入や SaaS 型クラウドの検討等、地方自治体の業務はより一層の標準化を求め られている。一方、地方自治体で導入する情報システムについても、パッケージシステム化や デファクトスタンダード技術の採用等の標準化が進んでいる。このことは、情報システム調達 仕様書の標準化も可能なことを意味している。 本書は、地方自治体の情報システム調達に関係する方々が、その調達において標準的な言葉 で円滑なコミュニケーションを図ることが可能となり、最良の情報システム構築に資するよう 作成したものである。 ＜地方自治体における情報システム調達のためのTRMの位置づけ＞ 地方自治体の情報システムは、取り扱う事務内容や事業規模が異なることから、地方自治体 ごとに大きく異なっている。また、自治体数も全国で約 1,800 団体と多く、多様である。 地方自治体は地方自治法により、 「普通地方公共団体」と「特別地方公共団体」に分類されて いる。 「普通地方公共団体」とは一般的に呼ばれている「地方自治体」であり、広域的な市町村 を統括する「都道府県」と基礎的な地方公共団体としての「市町村」がある。また、 「市」は、 人口 5 万人以上、都市化の状況などの要件が、地方自治法により定められており、 「市」は、 さらに規模等に応じて次の４つの区分があり、国が政令により指定される。 「指定都市」(人口 50 万人以上) 「中核市」(人口 30 万人以上) 「特例市」(人口 20 万人以上) 「一般の市」 人口規模や都市化の状況などにより、 「町」 「村」が定められている。 「特別地方公共団体」には東京都の「区」(23 区)や地方公共団体の組合などがある。 現在、各分類の地方自治体の数は、平成 24 年 1 月 4 日現在で以下のとおり。 都道府県･･･47、指定都市･･･20、中核市･･･41、特例市･･･40、一般の市･･･688 町･･･746、村･･･184 また、地方自治体では自治事務と法定受託事務があるが、指定都市、中核市、特例市は都道 府県からそれぞれ事務が委譲されている。 これらの地方自治体の分類により、事務処理内容に大きく差が生じるため、それぞれの分類 毎に、情報システムの範囲や規模に違いが生じている。 一般に、都道府県は、市町村のような業務システムとしては、税務事務以外はなく、財務会 計、庶務事務、人事給与、文書管理といった内部事務と道府県民税、事業税などの税務事務が 基幹システムとなっている。また、それぞれの事務処理量が多いことから、都道府県ごとに汎 用機システムを独自に開発して運用することが多く、近年ではオープンな標準に基づいた業務 4 システムへの移行が進んでいるが、業務要件や技術要件の関連性が低く、独自の情報システム 調達となっている。 指定都市は他の市と異なり、人口規模が大きく、行政区もあることから、汎用機による情報 システム化がいち早く進んできた経緯や、事務処理内容にもそれぞれ異なることから業務パッ ケージシステムの採用が遅れている状況となっている。 また、 各情報システムの規模が大きく、 業務要件や技術要件の関連性も低く、独自の情報システム調達が行われている。 中核市、特例市、一般の市の情報システムは、それぞれの業務要件や技術的な要件の関連性 が高い傾向があるが、規模やシステム化の進捗度には差が生じている。近年では汎用機からの オープンシステムへの最適化も進みつつあり、また、業務パッケージシステムのカスタマイズ 導入など調達の要件を明確化する必要がある。このため、本書はこれらの中核市、特例市、一 般の市の情報システムの調達に向けて活用されることを目的にしている。 なお、町、村の情報システムについては、ほとんどが、業務パッケージをカスタマイズせず、 そのままで導入する事例が多く、 導入した業務パッケージにあわせて業務を見直す場合もある。 5 第１章 本書の活用方法 1.1. 地方自治体におけるシステム調達の基本的な考え方 1.1.1. 業務システム構成要素の分離と再構成 地方自治体における業務システムの構成要素は、大きく１．業務パッケージシステム（業務 ユニット） 、２．サーバインフラ（サーバ・ネットワーク・ストレージ等） 、３．端末（PC・プ リンタ等）の三点に分類される。これまでは、この三点を業務システムごとにまとめて調達し、 ライフサイクルを揃える傾向にあったが、このことが業務システムのサイロ化や硬直化をもた らし、情報システムの TCO の増大、システムリソースの肥大化、運用管理の複雑化等を招い てきた。 業務システム群 業務システム群 業務パッケージ システム 業務パッケージ システム （業務ユニット） （業務ユニット） 分離 サーバインフラ （サーバ・ ネットワーク・ ストレージ等） 仮想化基盤 （サーバ・ ネットワーク・ ストレージ等） 端末 （ＰＣ・プリンタ等） 端末 （ＰＣ・プリンタ等） これらを解消するものとして、近年、仮想化技術やデファクトスタンダードを採用した業務 システムが台頭してきたため、上記の三点を分離して捉え、情報システム最適化の観点から、 それぞれを標準化、統合化、共通化のうえ再構成する動きがでてきている。 この再構成を推進することにより、サーバ、ネットワーク、ストレージ等を統合した仮想化 基盤を導入し、硬直化したサイロ型の独自システムから仮想化基盤に対応した業務パッケージ システムへ移行する地方自治体が出てきている。さらに、標準化の動きが加速すると、アプリ ケーションを共同利用する SaaS 型クラウドへ近づくことになる。 また、このことをシステム調達の観点から見ると、業務システムの各構成要素が密結合され ないため、分離調達が可能になる。 なお、自治体におけるクラウドの活用については「3.4.クラウドサービスの調達」を、仮想 化技術については「本編 5.クラウド」を参照されたい。 6 Ａ業務 システム Ｂ業務 システム Ｃ業務 システム Ａ業務 システム Ｂ業務 システム Ｃ業務 システム Ａ業務 ユニット Ｂ業務 ユニット Ｃ業務 ユニット Ａ業務 ユニット Ｂ業務 ユニット Ｃ業務 ユニット ＯＳ ＯＳ ＯＳ 仮想 マシン 仮想 マシン 仮想 マシン 標準化 ＯＳ ＯＳ ＯＳ サーバ サーバ サーバ 統合化 専用 端末 専用 端末 専用 端末 共通化 仮想化基盤 共通 端末 共通 端末 共通 端末 1.1.2. 業務パッケージシステムの活用 すべての地方自治体が同じ法律に基づき同じ業務を実施しているため、一部の大規模自治体 を除き業務パッケージシステムの活用が主流となっており、独自開発は減少している。このた め、ほとんどの地方自治体においては、業務と業務パッケージシステムとのフィットアンドギ ャップ分析とライフサイクルコストとのバランスによるシステム選定が主流となっている。 ここ数年、業務パッケージシステムはデファクトスタンダードの採用や地域情報プラットフ ォーム準拠等によるシステムの標準化が進むとともに、仮想化技術への対応も進み、自治体に おけるクラウド活用を見据えた製品が主流になりつつある。 地域情報プラットフォームについては「3.1.地域情報プラットフォーム」を参照されたい。 1.1.3. システム更改時の課題 地方自治体においては定型業務のシステム化がほぼ終了しており、新規システムの導入より もシステム更改の割合が多くなっている 。 システム更改においては、旧システムから新システムへのデータ移行作業の煩雑さや移行経 費が課題となっている。さらに、データ移行の際、文字コードや外字を整理していない場合、 移行ミスやデータ連携を行う際の煩雑さに直結する恐れがある。 また、独自業務システムから業務パッケージシステムに移行するとともに、サーバインフラ として、サイロ型システムを解消するためのサーバ統合を目的としたプライベートクラウド等 の仮想化基盤を導入する地方自治体が増えている。 この際、業務パッケージシステムベンダごとに専用の仮想化基盤を導入すると、サイロ型シ ステムを解消するはずが、仮想化基盤自体 がサイロ型となり、サーバ統合のメリットが最大限 7 に活かされない恐れがある。 1.2. 地方自治体におけるシステム調達の流れ 地方自治体における情報システム調達の流れとシステムのライフサイクルの考え方は政府調 達と原則同じである。 № フェーズ 当該フェーズにおける情報システムの調達例 １ 企画 システム導入（更改）計画策定支援 ２ 調達 システム調達（RFI・RFP）支援 ３ 開発 システム構築（設計・開発・試験・移行・プロジェクト管理） ４ 運用・保守 システム運用・保守・ヘルプデスク ５ 廃止 システム移行・撤去・廃棄 地方自治体においては、業務パッケージシステムの導入が主流となっている。このため、開 発フェーズにおいては、独自業務システムの導入に象徴される要件定義・設計・開発といった 作業割合は少なく、次の作業割合が多くなる。 ・業務パッケージシステムと業務とのフィットアンドギャップ分析 ・仮想化基盤との調整 ・LAN/WAN 等のネットワークに関する調整 ・他システムとのデータ連携インタフェースに関する調整 ・文字コードと外字の仕様調整 ・旧システムからのデータ移行に関する調整 ・端末（パソコン・シンクライアント・プリンタ・スキャナ等）調整 ・運用・保守調整 ・各種試験 ・プロジェクト管理 8 第 2 章 地方自治体における業務システムの動向 2.1. 業務システムの標準化 地方自治体は番号制度の導入や SaaS 型クラウドの実現に向けて、標準化された業務パッケ ージシステムの調達が求められている。業務パッケージシステムにおける標準化のポイントは 次のとおり。 ・デファクトスタンダードに準拠した OS やミドルウェア等で構成されていること。 ・カスタマイズを抑制すること。 ・仮想化技術に対応していること。 ・地域情報プラットフォーム準拠製品であること。 ・標準化された文字コードやフォントに対応していること。 2.1.1. デファクトスタンダードの採用 情報システムの TCO の削減や SaaS 型クラウドを見据えた業務の標準化を考慮し、業務シ ステムを独自開発する地方自治体は減少しており、デファクトスタンダードを採用した業務パ ッケージシステムを導入することが一般的になっている。 また、導入の際は、事前作業として BPR を十分に行うことにより、個々の地方自治体の独 自仕様によるカスタマイズを極力抑えることが望まれる。このことにより、より一層、情報シ ステムの TCO の削減が可能となり、保守の容易性が増すことにつながる。 2.1.2. 仮想化技術の採用 近年、サイロ型となり硬直化したシステムのサーバインフラ統合で脚光を浴びている仮想化 技術を採用し、IaaS や PaaS 等に対応した業務パッケージシステムが出現してきている。この 仮想化技術を用いた業務パッケージシステムを導入した場合、情報システムの TCO の削減や 運用管理の一元化が見込まれると同時に、将来、アプリケーションの共同利用を前提とした SaaS 型クラウドへ業務システムを移行するうえでの容易性や互換性が見込まれる。 また、仮想化技術を活用することにより、ハードウェアの二重化などに要する費用を比較的 抑えることができるとともに、省電力効果や冷却効率の上昇が見込まれ、グリーン IT の実現 に寄与する。 なお、自治体におけるクラウドの活用については「3.4.クラウドサービスの調達」を、仮想 化技術については「本編 5.クラウド」参照されたい。 9 2.1.3. 地域情報プラットフォーム準拠 地方自治体内部における業務システム間連携の標準化や、番号制度を見据えた地方自治体間 連携を実現するために、APPLIC が提唱する地域情報プラットフォームに準拠した業務パッケ ージシステムの調達が一般的になりつつある。このことにより、特定ベンダに依存することな く、連携仕様が標準化された業務パッケージシステムを、容易に調達し、必要に応じて変更す ることが可能となる。 地域情報プラットフォームについては「3.1.地域情報プラットフォーム」を参照されたい。 2.1.4. 文字コードやフォントの標準化 SaaS 型クラウドや地域情報プラットフォーム、あるいは、番号制度を実現するための前提 条件として、地方自治体や業務システムごとに異なる文字コードやフォントを統一する必要が ある。 具体的には、各業務システム間の情報流通を標準化、簡素化するため、デファクトスタンダ ードになっている Unicode に対応した業務システムを調達する必要がある。 また、外字については情報流通を阻害する要因となるため、全国的な統一化が課題となって いる。 今後は、独立行政法人情報処理推進機構（以下、 「IPA」という。 ）が提供する、文字の標準 化を目指す文字情報基盤に対応した業務パッケージシステムの出現が求められる。 文字情報基盤については「2.2. 文字情報基盤」を参照されたい。 10 2.2. 文字情報基盤 2.2.1. 文字情報基盤とは 自治体のシステム、特に基幹系システムの調達時に特に留意しなければならないことに、文字 の問題がある。一般的なシステムでは従来は、JIS X 0208 の範囲をシフト JIS 符号化方式で、 近来は JIS X 0213 の範囲を UNICODE の符号化方式で実装する範囲で納まっていた。 しかし、 自治体等の人名を扱う行政システムでは、従来からいわゆる外字問題と言われる問題が存在し ていた。 従来は、住民記録や外国人登録などいわゆる自治体基幹系業務のデータは、大型汎用機等で 管理されており、文字コードは、各汎用機ベンダで異なり、それぞれの拡張エリアにベンダ固 有の拡張文字および、自治体独自作成の外字があるのが実情であった。 近年、WINDOWS へ移行が進み、UNICODE が主流になってきており、扱える文字の範囲 も広がって来たが、各汎用機ベンダは汎用機から WINDOWS へ移行する際にその互換性を重 視した結果、WINDOWS においても独自のコード体系とすることが行われてきたため、シス テムを調達する場合やデータ移行する際に大きな妨げになっている。 このような現状から、IPA では、文字の国際標準と整合性の取れる扱いを推進するため、戸 籍統一文字や住民基本台帳統一文字を網羅した、氏名漢字 58712 文字の画像と画数などの文字 情報を整備した文字一覧表を公開すると共に、実運用に必要な環境を整備しているところであ る。 今後は、SaaS 型クラウドや地域情報プラットフォーム、あるいは、番号制度等を実現する ための前提条件として、情報流通を阻害する要因となる外字を含む、地方自治体や業務システ ムごとに異なる文字コードやフォントを統一する必要があることから、業務パッケージシステ ムの調達においても文字情報基盤の対応を考慮することが求められる。 文字情報基盤の詳細については次を参照されたい。 http://ossipedia.ipa.go.jp/ipamjfont/ 11 IPAmj明朝フォントVer.002.01 戸籍統一（漢字のみ） (55,269文字) 登記固有 文字 (10,330) 住基統一(漢字のみ） （19,563文字) 非漢字 （2,002図形/1,672文字） 縦書用文字、リガチャを含む 文字情報基盤漢字 (58,813文字) 23,941文字 1,672文字 ISO/IEC 10646 UCS (Universal multi-octet coded Character Set) 25,808文字 2,275文字 CJK統合漢字拡張B,C,D (全47,000文字) BMP (全65,536文字） 6,789文字 IVD ほぼ全ての情報機器で利用可能 市販の最新の情報機器の多くで利用可能 一部のOS,アプリケーションが対応を開始 IPA 文字情報基盤成果物（フォント、MJ 文字情報一覧表）利用ガイドより抜粋 2.2.2. 文字情報基盤の実装上の問題点 文字情報基盤は平成 23 年 10 月にフォントと文字情報一覧表が公開され、平成 24 年 6 月 には Ver002.01 へバージョンアップされた。しかしながら正式版にも実装にあたってはさまざ まな問題点が残っている。 ・IVS 技術の普及の問題 文字情報基盤ではIVS技術が用いられている。現在では、IVS技術とIVD登録を用いることに より、同一の符号位置に対応づけられる複数の文字図形を使い分けることは、国際規格として は標準化されているが、実装技術として十分に確立しているとは言い難く、一般に普及してい ない 1。 なお、IVS については次を参照されたい。 http://ossipedia.ipa.go.jp/ipamjfont/faq/ivs_ivd.html 1平成 24 年 11 月から、一部製品（OS、オフィスソフト）での対応が始まっている。 12 フォントには未 実装 http://ossipedia.ipa.go.jp/ipamjfont/ivs_detail.html IPA 文字情報基盤整備事業 IVD/IVS の考え方(参考）より ・UCS 対応関係が不確定 文字情報一覧表において UCS 対応関係がカテゴリー分けされており、たとえばカテゴリーA は文字情報基盤整備事業で対応関係が確認されていると分類されている。そのうちカテゴリー が B と分類されているものは、今後、対応関係が変更される可能性があるため、文字情報基盤 ではカテゴリーB の UCS 欄の利用を控えることを推奨している。現時点の最新版では、文字情 報一覧表の UCS 欄の値は、ほぼ確定しており、この情報に基づき、UCS での符号化が必要な 約 1800 文字については、標準化に向けた国際提案を行っている。 ・UCS・IVS 未実装の問題 CJK 統合漢字に J ソースがなく、符号位置特定の作業が継続中であるものや、対応する UCS 符号位置が標準化されていないものや対応符号位置が明確でないものについては IPAmj フォ ントでは、UCS 符号位置による使用が出来ない。 2.2.3. 文字情報基盤の利用 現状では文字情報基盤はそのままシステムとして実装することは困難であるが、同事業の 13 成果物を利用する場合には、慎重な配慮の上で、以下のような方法も考えられる。たとえば、 該当文字図形が未実装により存在しない場合は、その文字図形を、従来のように私用領域に割 り当てて運用する。そうして作成された派生フォントは、フォント名称の変更などの必要な対 応を取ることにより、IPA MJ 明朝フォントと同様に、IPA フォントライセンス 1.0 に従えば 自由に複写・利用することができる。 （１） ベースフォントとして利用 文字情報基盤の IPAMJ 明朝フォントは、通常の UCS 符号位置を経由した用法では、実装さ れている約 6 万文字すべてを使用できないが、JIS X 0213:2004 の文字はすべて利用できるた め、そのままベースフォントとしての利用が可能である。ベースフォントを固定化することで フォントのバージョンによる相違を解消できるほか、将来的に IPA MJ 明朝フォントがすべて の字形に対し UCS・IVS 実装が行われ、IVS 技術が普及し業務アプリケーションが対応した場 合にベースフォントを変更する必要がない等のメリットがある。 （２） データ移行時のマスターとして利用 システム更新や合併等により、業務パッケージベンダが変わる場合、文字体系やベースフォ ントも変更となる場合が多い。その場合、マスターとして MJ 文字図形名と自治体内の文字の 対応テーブルを整備しておくことで、正確な字形の情報交換ができることにより文字同定作業 の負担を軽減できる。 （３） 文字情報一覧表の属性情報の利用 文字情報基盤の成果物は IPAMJ 明朝フォントのほか、読み、画数などの属性情報を整理した 文字情報一覧表がある。約 6 万文字の文字を実際し使用するためには、該当文字を検索し特定する 必要があるが、文字情報一覧表はこの文字検索に活用することができる。また、属性情報には読み、 画数などのほか、戸籍統一文字番号や住基ネット統一文字コードなども収録されており、自治 体が整備すべき変換テーブルのベースとすることが可能である。 （４） 外字作成時の負担軽減 IPAMJ 明朝フォントは、通常の UCS 符号位置経由では、約 6 万文字すべてを利用できないが、 SVG フォーマットによる文字図形データも配布されているため、そのデータを流用し文字作成 が可能である。外字作成担当者の文字作成の負担軽減や、文字作成を委託している場合には経 費削減効果が期待できる。 （５） 派生フォントによる活用 IPAMJ 明朝フォントは、IPA フォントライセンス 1.0 従えば自由に複写・利用することがで きるため、SVG フォーマットファイルなどを利用した派生フォントを作成することができる。 たとえば IPAMJ 明朝フォントで実装していない字形をすべて実装することも可能であり、印 刷アウトソーシングなどへの活用が期待できる。この際、変更内容によっては、フォント名を変更する などの対応が必要になる場合がある。 （６） 外部システム間の連携 その他、MJ 文字図形名との同定が完了している機関のシステム同士では、MJ 文字図形名 を介すことで正確な字形を交換が可能となる。 14 2.3. 情報セキュリティ 2.3.1. 地方自治体の情報セキュリティについて 政府機関における情報セキュリティ対策と同様に、各地方自治体の情報セキュリティにつ いても、 「地方公共団体における情報セキュリティポリシーガイドライン」 （最新版：平成 22 年 11 月 9 日 総務省）を元に「情報セキュリティポリシー」を策定し、それに基づいて情 報セキュリティ対策を実施している。 また、その情報セキュリティ対策が組織内において、適切に整備・運用されているかを点 検・評価するため「地方公共団体における情報セキュリティ監査に関するガイドライン」 （最 新版：平成 22 年 11 月 9 日 総務省）等に基づき、情報セキュリティ監査を行っている。 本章では、地方自治体が、その情報システム調達時の情報セキュリティについて、また情 報セキュリティ監査の際に留意すべき点について示している。 2.3.2. 地方自治体情報システム役務調達時の情報セキュリティについての留意点 基本的に、地方自治体による情報システム役務調達において、留意すべき点は、法令（特 に地方自治体条例）の遵守やポリシー、ガイドライン（基準）等の準拠となる。受注者は、 全ての作業において 1∼4 に挙げている内容に留意する事が重要である。なお、応札の条件 となる制約については、全て列挙する必要があり、準拠すべきポリシー、ガイドライン（基 準）等は、応札中の応札者に開示される必要がある。 地方自治体は、その情報セキュリティポリシーについて、情報セキュリティに係る状況の 変化に留意し、定期的にその内容を見直さなければならない。 クラウドサービスを利用する際、そのサービスが海外のデータセンターにサーバを有する 場合は、機微情報を含む個人情報等が海外に持ち出され、国内法等、国内規制が及ばなくな る可能性があるので、契約するに当たっては、十分な注意が必要である。 注意すべき点について、具体的には、 ・運営会社がデータの所在地について、明らかにすることに同意しているか ・上記の場合において、データをどこのデータセンターに収容しているか ・運営会社について、外国企業の場合は、運営会社に対する所在地国法の規制内容 等が挙げられる。 参考） 「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」 （経済産業省）P73「データセンターの所在」 http://www.meti.go.jp/press/2011/04/20110401001/20110401001-7.pdf 15 留意点 １． 情報セキュリティ 留意点の概要 仕様書に記載するポイント 各地方自治体の情報セキュリテ 各地方自治体の情報セキュリティ ィポリシーに準拠すること。 ポリシーの準拠 ポリシーに準拠して仕様書を作成し ている場合は、セキュリティ要件につ いての記載の中に当該ポリシーに準 拠する旨を明記する。 ２． 各種法令・規制等の 遵守 各地方自治体の情報システムの 対象となる情報システム、業務が関 管理運営に関する条例、個人情報保 連する法令・規制に関しては仕様書上 護条例、個人情報保護法（個人情報 で明記を行い、遵守する旨を記載する の保護に関する法律） 、刑法、著作 こと。 権法、不正アクセス禁止法等、当該 の調達案件において関連する各種 法令等を遵守すること。 上記以外に、受注者に準拠又は対 情報システムの内容等から 1~2 以 応を求めるべきガイドラインが存 外に準拠するガイドラインを抽出し、 在する場合には、受注者は当該のガ 仕様書に準拠又はガイドラインを実 イドラインに準拠すること。 （政府 現する提案を求める旨を記載するこ 機関用の基準も必要に応じ参照す と。 ３． その他ガイドライ ンの準拠 る） ４． 業務の一部を各地方自治体の承 一部業務について再委託先の活用 再委託先に対する 認を得て、再委託する場合は、再委 が想定される場合には、再委託先にも 情報セキュリティポ 託を行う事業者にも受注者と同様 受注者と同様の内容に準拠する必要 リシー等の適用 の内容に準拠させること。 （過去の があることを明記すること。 地方自治体における個人情報等の 漏洩事例では、再委託先においての 管理不備によるものが多いため特 に注意。 ） 2.3.3. 情報セキュリティと個人情報保護、業務継続計画 膨大な個人情報を保有する各地方自治体は、各自治体の個人情報保護条例、個人情報保護 法、に基づき、個人情報を保護する義務があり、かつ保有する個人情報が常に正確でなけれ ばならない。情報セキュリティ対策は、このように個人情報の保護を行うための手段の一つ であり、同時に個人情報保護条例、個人情報保護法は、情報セキュリティ対策に法的根拠を 与えうるものである。 また、各自治体は、災害（直下型地震等）の発生時等に、庁舎等が被災して業務遂行能力 16 が低下した状況下において、非常時優先業務（応急業務及び一部の通常業務）をまず継続・ 再開・開始し、その後、優先順位に応じて業務を全面復旧するための計画（業務継続計画 =BCP）を予め策定しておく必要がある。そのため、それらの業務に対応するシステムも、 必要に応じて、継続・再開・開始するための、いわゆる「ICT-BCP」 （システムに関する業 務継続計画）も併せて策定しておく必要がある。この「ICT-BCP」は、情報セキュリティの 構成要素「可用性」に関連するものである。 各自治体は、 「ICT-BCP」を含む業務継続計画が有効に運用されるために、代替設備等の 検討を行うとともに、BCP 発動時の訓練等を定期的に行い、PDCA サイクルをもって常に 内容を見直さなければならない。 2.3.4. 情報セキュリティと自治体業務パッケージシステム 自治体業務パッケージシステム導入に際しては、各パッケージの情報セキュリティ対策を 検証し、各自治体の情報セキュリティポリシーに合致したものであることを確認しなければ ならない。クラウドの活用において、自治体業務パッケージシステムを用いる場合も同様で ある。 2.3.5. 地方自治体の情報セキュリティ監査実施時についての留意点 各地方自治体において、情報セキュリティ監査を実施する際は、内部監査、外部監査とも 「地方公共団体における情報セキュリティ監査に関するガイドライン」等に基づいて行う旨、 明示する。 その際には、 「組織」を対象とする（運用面やガバナンスに力点を置く）ものか「情報シス テム」を対象とする（安全性の監査に力点を置く）ものか等、監査趣旨を明示して行うこと が望ましい。情報セキュリティ監査を調達する際にも、その旨を仕様書に明示することが望 ましい。 2.3.6. 参照すべき基準・ガイドライン ・ 「地方公共団体における情報セキュリティポリシーガイドライン」 各地方公共団体（地方自治体）が、情報セキュリティポリシーの策定や見直しを行う際の 参考として、情報セキュリティポリシーの考え方及び内容について解説したものである。 http://www.soumu.go.jp/denshijiti/jyouhou_policy/pdf/100712_1.pdf （最新版：平成 22 年 11 月 9 日 総務省） ・ 「地方公共団体における情報セキュリティ監査に関するガイドライン」 各地方公共団体（地方自治体）に対し、情報セキュリティ監査の標準的な監査項目と監査 17 手順を示すものである。 http://www.soumu.go.jp/denshijiti/jyouhou_kansa/pdf/jyouhou_kansa_guideline.pdf （最新版：平成 22 年 11 月 9 日 総務省） 18 第 3 章 業務アプリケーション調達のポイント 3.1. 地域情報プラットフォーム 3.1.1. 地域情報プラットフォームとは 地域情報プラットフォームは、様々なシステム間の連携を可能にするために、各シス テムが準拠すべき業務面や技術面のルールを標準仕様として規定したものである。SOAP やXMLなどの標準技術を活用して情報システムの基盤を共通化することで、異なる情報シ ステム間でのシームレスなデータ交換を実現することを目的としている。 なお、一般財団法人全国地域情報化推進協会（以下、 「APPLIC」という。 ）では「自 治体業務アプリケーションユニット標準仕様V2.4」において、２６の業務ユニットを規 定している。 番号 １ 業務ユニット名 住民基本台帳 概要 住民の転入・転出・転居・出生・死亡等の異動、照会や証明書の発行・ 通知書の出力等を行う。 ２ 印鑑登録 印鑑の登録・廃止・印鑑証明の発行等を行う。 ４ 選挙人名簿管理 選挙人名簿の管理、入場券発行、不在者投票、住民投票の管理等を行 う。検察審査会、農業・海区・漁業委員会選挙人名簿作成を行う。 ５ 固定資産税 固定資産税課税台帳（土地・家屋・償却資産）の評価・賦課・証明書 発行・統計処理等を行う。 ６ 個人住民税 個人住民税の課税対象管理・資料の管理・賦課・統計処理等を行う。 ７ 法人住民税 法人台帳の管理・賦課台帳管理等を行う。 ８ 軽自動車税 車輌台帳の管理・賦課・証明書発行等の処理を行う。 ９ 収滞納管理 個人住民税、法人住民税、固定資産税、軽自動車税及び国民健康保険 税（料）の収納情報・滞納整理情報の管理、消込・滞納整理・過誤納 の処理、統計出力等を行う。 １０ 国民健康保険 資格の管理・保険証の発行、所得資産の管理・保険税（料）の賦課、 レセプトのチェック・管理、療養費等の給付、統計処理等を行う。 １１ 国民年金 国民年金資格の管理・付加・免除・給付の管理を行う。 １２ 障害者福祉 対象者の資格管理、進達処理、通知書発行、支払管理、統計処理等を 行う。 １３ 後期高齢者医療 対象者の資格管理、保険料の賦課管理、収納管理、滞納管理を行う。 １４ 介護保険 介護保険被保険者の資格管理・介護保険料の賦課・介護保険料の収納 管理・受給者の台帳管理を行う。 １５ 児童手当 対象者の資格管理、現況受付、支払管理、統計処理等を行う。 １６ 生活保護 生活相談受付、保護申請審査、支給管理、統計処理等を行う。 １７ 乳幼児医療 対象者の資格管理、現物給付や償還払いによる医療費支払および統計 19 報告処理等を行う。 １８ ひとり親医療 対象者の資格管理、現物給付や償還払いによる医療費支払および統計 報告処理等を行う。 １９ 健康管理 成人検診・母子健診・予防接種情報の管理、保健指導、統計報告資料 作成、データ分析の処理を行う。 ２０ 就学 学齢簿の出力、小学校・中学校の就学通知の発行等を行う。 ２１ 戸籍 本籍人の出生・死亡・婚姻・離婚・養子縁組・養子離縁などの異動、 照会、証明書発行、および通知書出力等を行う。また附票管理を行う。 ２２ 子ども手当 対象者の資格管理、現況受付、支払管理、統計処理等を行う。 ３０ 住登外管理 住登外者・法人情報の管理を行う。 ５０ 財務会計 予算編成・予算管理・歳入管理・歳出管理・歳計外現金・出納管理・ 決算管理等の処理を行う。 ５１ 庶務事務 勤怠管理・各種手当申請・その他各種申請・照会／配布・福利厚生管 理・年末調整管理・正規職員以外管理等の処理を行う。 ５２ 人事給与 申請受付・計算・年末調整・支払・人事・福利厚生・研修等の処理を 行う。 ５３ 文書管理 公文書の収受・起案・承認／決裁・施行・保管・検索／照会・ファイ ル管理・情報公開等の処理を行う。 なお、地域情報プラットフォームの詳細については、APPLIC のホームページを参照のこと。 http://www.applic.or.jp/index.html 3.1.2. 地域情報プラットフォームの準拠登録 APPLIC では、地域情報プラットフォーム標準仕様に準拠した製品に対し、準拠登録及び 相互接続確認を行っており、調達の指針とすることができる。なお、準拠登録及び相互接続 確認済みの製品には推奨マークの使用が許される。 ＜＜準拠登録製品マーク＞＞ ＜＜準拠登録・相互接続確認製品マーク＞＞ ※マークはサンプルです。 http://www.applic.or.jp/pf/mark/mark.pdf 「APPLIC 推奨マーク指針」より引用 20 なお、準拠登録製品一覧については、APPLIC のホームページを参照のこと。 http://www.applic.or.jp/pf/entry/index.html 3.1.3. 地域情報プラットフォーム準拠登録製品の調達時の留意事項 地域情報プラットフォームは様々なシステム間の連携に必要な最低限のルールを定めたも のであって、地域情報プラットフォームが調達時に必要な機能をすべて規定しているわけで はない。 ただ単に準拠登録製品を調達すればそのまますぐにすべての連携ができるとは限らないた め、要求仕様を確認した上で、調達仕様書には必要な項目を追加しなければならない。 なお、準拠登録製品の中には、地域情報プラットフォームの仕様をパッケージシステムの 標準機能とせず、オプション扱いとしている製品もあるので注意が必要である。 以上のことから、地域情報プラットフォームを活用した調達を行う場合には、適宜最適な 仕様・方式を検討した上で、必要に応じて実装に必要なものを規定し調達仕様へ盛り込むこ とが必要となる。また、地域情報プラットフォーム準拠製品を、標準技術の採用や業務間連 携の考慮された製品であることに対する評価とし、加点対象とするような調達方法も考えら れる。 21 3.2. 共通基盤 3.2.1. 自治体における共通基盤 大規模・中規模の自治体では、本編「共通データベースの考え方」における共通データベ ースだけでなく、ESB（Enterprise Service Bus）、BPM（Business Process Management） などのミドルウェアを含み、認証機能や利用者管理などの共通機能や、共通基盤と接続する 個別業務アプリケーション同士が情報連携を行うための統合DBまでのサービス基盤を総称 し、共通基盤システムとして調達するケースがある。これは自治体の各業務は相互に関連し データ連携を行う必要があり、情報の効率的な活用を行うため情報の統合管理を行うことで システム全体としての最適化を目的としている。 3.2.2. 統合DB 統合 DB は共通基盤システムでデータを一元的に利用（参照）する仕組みである。業務ユ ニットとの連携を行うため、標準化された業務ユニットインタフェースと同様のインタフェ ースを連携に必要な単位で実装しており、実装方式として公開用 DB 方式共通インタフェ ース方式がある。業務ユニット同士は直接データのやり取りを行うのではなく、この統合 DB を介して連携を行うことにより、業務ユニットは他の業務ユニットに影響を受けずに連 携することができる。 児童手当 介護保険 国民健康保険 住登外管理 住民基本台帳 業務ユニット群 標準インター フェース 統合ＤＢ 3.2.3. 共通基盤の構成単位 共通基盤は自治体システムの基幹を成すものであるため、庁内システム全体のライフサイ クルを考慮して調達することが望ましい。また、システム構成単位を目的に合わせてその範 22 囲を規定する必要がある。 ① システム間通信機能 業務ユニットや BPM 機能、統合 DB 機能といった他のシステム構成単位の前提ソ フトウェアであるため、 SOAP 仕様など標準技術を採用することを推奨する。 ② 統合 DB 機能 統合 DB は公開用 DB 方式か共通インタフェース方式、あるいはその併用かを人口 規模、データ量、業務ユニットの調達状況など総合的な判断をして規定する。また ESB 製品等を活用することも検討されたい。 ③ 共通 DB 機能 業務ユニットが共通で使用する全国市町村情報や全国銀行情報などの辞書データ、 コード辞書などを格納する共通 DB 機能 を規定する。 ④ BPM 機能 ワンストップサービスや総合窓口機能などでサービスを順次実行する。地域情報プ ラットフォームではデファクトスタンダードとなっているWS-BPEL を用いることを 前提としている。 ⑤ 共通機能 認証機能や利用者管理機能、 時刻同期機能など、 共通基盤に含める機能を規定する。 ⑥ 宛名管理機能 宛名管理を個別業務ユニットとして調達するパターンと、共通基盤の機能として調 達するパターンが考えられる。業務パッケージ製品として宛名システムを調達する場 合や、住民基本台帳ユニットや住登外ユニットの一部に宛名管理機能を有するような 調達を行う場合には個別業務ユニットの位置づけとなる。一方、宛名管理システム自 身ではデータ作成を行わず、元となる住民基本台帳ユニットと住登外ユニットのデー タを横断的に管理する機能としての調達を行う場合、すべての業務ユニットが使用す ることも考慮すれば共通機能であると言える。 23 児童手当 介護保険 国民健康保険 住民基本台帳 児童手当 介護保険 国民健康保険 住登外管理 住民基本台帳 宛名管理機能 統合ＤＢ 統合ＤＢ ⑦ 総合窓口機能 総合窓口機能も個別業務ユニットとして調達するパターンと、共通基盤の機能とし て調達するパターンが考えられる。業務ユニットとして調達する場合には、業務ユニッ トとデータ連携を行うために必要なインタフェース定義の整備とその問い合わせに対応 する統合 DB との連携が重要となる。 3.2.4. 共通基盤の調達の留意事項 共通基盤システムは、すべての業務ユニットが使用するため、可能な限り標準技術を採 用し、ベンダロックインとならないよう特に留意する必要がある。また、使用される技術 だけでなく統合 DB のシステム間連携で使用する標準インタフェースは、業務ユニット導 入ベンダに平等に公開される必要があるため、調達時にユーザ自らが規定するか、基盤製 品として調達する場合においても公開を条件とすることが必要である。 また、共通機能を導入する場合においても同様に、ベンダロックインとならないよう留 意する必要がある。認証機能などで使用するミドルウェアが業務ユニットに対し制限事項 を発生させることの無いようにすると共に、宛名管理機能では、特に文字コードにベンダ 独自文字体系を使用しないよう留意すべきである。 3.3. 業務パッケージの調達 3.3.1. 自治体業務アプリケーションの特徴 自治体における調達は、住民基本台帳システムや税システムのように同じ法律に基づき同 じ業務を実施しているため、機能やサービスとして提供されるシステムではなく、パッケー 24 ジシステムの調達が主流である。ただし、自治体の規模により必要機能要件が異なるため大 規模自治体ではパッケージシステムをカスタマイズすることも行われる。近年では業務パッ ケージシステムベンダも標準技術を業務パッケージシステムに採用することを重視してきて いる。 3.3.2. パッケージシステムの活用 業務パッケージシステムを調達する際は、カスタマイズを極力抑えることが望まれる。自 治体業務は法制度改正が頻繁に行われ、その都度システム改修が必要となる。独自開発によ り構築されたシステムでは自治体ごとにそれぞれシステム改修が必要となるが、パッケージ システムでは修正モジュールとして統一的に提供されることから、改修費用と工数削減が期 待できる。 （１） パッケージシステム製品 調達する製品が、パッケージシステムであるかは提供ベンダの製品ラインナップで決まる ため、製品としてどこまで標準で用意されているかはベンダにより異なる。たとえば、パッ ケージシステムでは基本機能のみサポートし、その他の機能を自治体ごとに改めて要件定義 をもとに構築するタイプもパッケージシステムと呼ぶ場合がある。この場合には自治体ごと の細やかな適用が可能である半面、構築部分が多いためその後の改修作業も個別対応となる ことが多い。 （２） 業務パッケージシステムと業務とのフィットアンドギャップ分析 要件定義を作成する際に、現行システムの機能を、その必要性を再評価せずに、安易に踏 襲したり、業務担当者の要望を単純に羅列したりすると、多くの場合、パッケージシステム としての適用が非常に困難となってしまい、開発量も膨大なまま削減されない。 こういった事態を避けるためには、要件定義において、業務パッケージシステムと業務と のフィットアンドギャップ分析を十分に行うことが必要である。全体アーキテクチャの策定 時、業者への見積もり依頼時、調達仕様作成時、設計時のすべてにおいて、真に必要とされ る業務要件を、パッケージシステムを適用していかに合理的に実現するかという視点が不可 欠となる。 （３）運用保守 業務パッケージシステムベンダから提供されるシステム導入後の不具合対応や機能改善などを 行った修正モジュール等を、そのままシステムに上書きするような対応（オーバライト）は通常運用 保守に含めるが、法制度改正等による軽度、中度、重度のシステム改修をどこまで含めるか については意見の分かれるところである。システムのライフサイクル中での法制度改正等に よるシステム改修をすべて含めると、システム改修規模がわからない状態での費用算定とな るため保守料が高額となるほか、法改正等が契約期間中に発生しなかった場合においても費 用を払い続けなければならない。一方、制度改正等によるシステム改修を含めないこととす ると、その都度費用算定をして契約行為を行う必要がある。また、その場合においては業務パ ッケージシステムベンダの随意契約となるため、適正な費用算定のための競争原理が働かない 恐れがある。 25 （４）業務パッケージシステム調達と役務との関係 システム構築は、設計、開発、テスト、移行の各詳細フェーズから構成され、運用･保守へ と続く。業務パッケージ調達ではこの開発作業は発生しないと思われがちであるが、要件定 義によりパッケージで提供されていない機能を新規に開発する場合や、業務パッケージシス テムを実際に使用可能とするための適用作業が別途役務として発生する場合が多い。そのた め、業務パッケージシステムにおいても役務調達を意識して調達することが必要となる。な お役務についての技術参照モデルは「役務調達編2.3. システム構築（設計・開発）」を参照 のこと。 3.3.3. システム要件定義 開発型の調達では要件定義が作業フェーズに含まれ、要件定義作業も含めた契約となる が、業務パッケージの調達の場合、予め発注者側で要件定義を提示し、それがパッケージシ ステムに含まれるか否かにかかわらず、その要件を満たす条件で発注されることとなる。オ ープンな標準のためには、要件定義を適切な粒度で提示することが必要であるが、たとえば 「戸籍手続オンラインシステムの構築のための標準仕様書」など、公的機関による義務的に 提示される標準仕様書が存在する場合は稀であり、多くは自治体自ら作成しなければならな い。 そのため、自治体では従来詳細な要件定義を提示せず、「住民基本台帳システム一式が動 作すること」といった、いわゆる一式調達というものも行われてきた。ベンダは現場適用の リスクを考慮するため割高となる傾向があるほか、要件にどこまで含まれるかの範囲につい て、契約後にトラブルになる場合がある。また、特定ベンダの作成した要件定義をそのまま 流用して調達し、ベンダロックインとなる仕様のため適正な競争原理が働かない場合も見受 けられる。そうしたことを防ぐため、各自治体がそれぞれ先進事例や各種実証事業等の成果 物を参考に作成している程度に留まっている要件定義を、今後は標準化して整備していくこ とが重要である。 なお、要件定義を適切に定義する手段としてRFI･RFPが有効である。調達予定の業務ユニッ トの業務パッケージシステムを持つ複数のベンダに対しRFI･RFPを行い、想定している要件 定義がそれぞれのベンダが保有する業務パッケージシステムが満たすことができるか予め確 認し、必要に応じて加除・修正することにより、できるだけオープンな要件定義とすること が出来る。場合によりRFI･RFPの段階で業務パッケージシステムに無い機能であっても、他 のベンダが持つ有効な機能であれば、そのベンダが標準機能として業務パッケージシステム 自体をレベルアップさせることも考えられる。 3.3.4. 共通基盤への接続 個別業務パッケージの調達においても、全体最適化を意識してシステム間連携を前提とした調 達することが重要であり、共通基盤システムとの接続のための標準インタフェースを備えることを推 26 奨する。そうすることで、共通基盤システムを介し、自治体内のシステム間連携を円滑に行えるほか、 番号制度で想定されているような自治体間の連携を行う場合にも有効であると思われる。 個別業務ユニット 住基システム 税システム 福祉システム 共通基盤システム 他社システム 個別システム 自己開発システム 給食費・保育・市営住宅など 中間サーバ 情報連携IFサーバ 情報連携基盤 他市 他県 他機関 公開用 DB 方式に接続する場合では、実データを共通基盤側でも保持するため、業務ユニ ットに直接アクセスされることはなく他の業務ユニットを意識する必要はないが、共通イン タフェース方式の場合には、他の業務ユニットからの問い合わせが共通基盤を介して要求さ れるため、その負荷も考慮にいれたハードウェアやソフトウェアの最適化が必要となる。 3.3.5. 業務パッケージシステム調達における文字情報 （１） 文字情報の指定 文字情報は政府調達のシステムと違い、自治体の調達においては大きな意味を持つ。それは 政府調達のシステムは氏名などの文字は単に識別として判別できるものであれば良いのに対し、 自治体は戸籍法、戸籍法施行規則、住民基本台帳事務処理要領などにより、戸籍に記載されて いる字形の正確な表記が要求されている。業務の目的が、個人の身分、居所等を公証すること であることも大きな違いである。そのため自治体で取り扱う文字情報は文字図形としての厳密 性が求められるため、調達時には明確に指定が必要である。 たとえば、JIS X 0208 と指定しただけでは字形の相違を表現できないので、JIS X 0208:1990、 UnicodeV2.3 のような指定が必要である。また、フォントによっても字形の違いがあるため、 フォントも考慮することが必要であるとともに、 バージョンによっても字形の相違があるため、 27 たとえば、JIS X 0213:2004、IPAMJ 明朝フォント V2.01 をベースフォントとするなどの表現 となる。 （２）文字情報に関する留意事項 製品の中には、単に Unicode のコードポイントを使用していることのみをもって、国際標準 規格でない独自の字形を使用しているにもかかわらず Unicode であるとしているものも見受 けられる。また、導入する業務パッケージ自体は仕様を満たしていても、関連するサブシステ ムに独自の文字体系を使用しているため、本来の Unicode の文字を使用できないといったこと も起こりうる。特に住基システムは、すべてのシステムの宛名情報の元となるシステムである こととともに、自治体内のみならず自治体間連携も想定されているため、ベースフォントに独 自文字体系を使用しないことを強く推奨する。 双方向連携 双方向連携 住基システム 住基ネット連携サーバ ベンダー独自文字 住基ネット 住基ネット明朝 Unicode等 片方向連携 関連するサブシステムがベンダー独自文字の場合 文字の体系が独自文字の仕様により制限される。 自動発行機システム ベンダー独自文字 3.3.6 業務パッケージシステム調達におけるデータ移行 業務パッケージシステム調達時には、円滑な切替えを行うために、データ移行について時 期と方法を明確にする必要がある。 また、 現行システムからのデータ移行はもちろんのこと、 システムライフサイクル終了後のシステム更新時のデータ移行も考慮する必要がある。デー タ移行は現行ベンダに有利になることが多くベンダロックとなることが想定されるため、オ ープンな調達を行うためにはデータ変換作業が特定ベンダに有利になることがないよう配慮 する必要がある。 なお、データ移行の調達方式として以下のものが考えられる。 （１） 受注者がデータ変換を行う方式 業務パッケージシステムの受注ベンダが、現行システムからのデータを変換する作業 を含める調達方式。現行システムのベンダは、現行システムを熟知しており、移行ツー ルが用意されている場合もあり現行ベンダが有利となるため、発注者が現行システムの データ仕様を参加ベンダに等しく提供できることが必要である。また、現行ベンダが現 行システムの仕様の提供費用を要求する場合があることや、それを発注者が負担しなけ 28 ればならないデメリットがある。それを回避するには、システム調達時に予め次回シス テム更新時のデータ抽出とデータ仕様の提供を行う契約とするなどの方法もある。 （２） 発注者がデータ変換を行う方式 業務パッケージシステムの受注ベンダが要求するデータ移行レイアウトにあわせて、 発注者が現行システムからのデータを変換する作業を行う調達方式。発注者が現行ベン ダにデータ変換作業を委託する場合もある。現行システムのベンダにかかわらず、入札 参加ベンダに平等な条件が提示できる反面、発注者の負担が大きくなるとともに、デー タ移行の主導権を業務パッケージシステムの受注ベンダに与えるデメリットがある。受 注ベンダのデータ仕様に完全に合わせるのではなく、ある程度の変換作業も受注ベンダ が行うことも含める（１）と併用する方法もある。 （３） 中間レイアウトを提示して行う方式 発注者が予めデータ移行のための中間レイアウトを提示し、その中間レイアウトから のデータを変換する作業を含める調達方式。現行システムからのデータを中間レイアウ トに変換する作業と、中間レイアウトから新システムへ変換する作業が発生し、作業の 不明確性によるリスク分が加味されやすいこと、また、変換プログラムはその都度作成 し使い回しができないため、変換プログラム開発の割り勘効果も期待できないことから データ移行費用が嵩むといった課題があったが、総務省が作成・公表している中間標準 レイアウトを活用することで、それが解消される。中間標準レイアウトの活用により、 現行システムのベンダと発注者・受注ベンダとの調整作業が不要となり、また、作業工 数の透明化が図られ、データ移行費用の抑制効果が期待できる。 なお、中間標準レイアウトについては、総務省ホームページの自治体クラウドポータ ルサイトを参照のこと。 http://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/lg-cloud/02kiban07_03 000024.html （４） データ変換作業を別委託とする方式 現行システムからと調達した新システムへのデータ変換作業のみを別途委託する方式。 自治体の業務パッケージシステムやベンダごとに異なる文字コードなど、現行システム と調達した新システム両方の仕様に熟知したベンダが必要である。データ移行仕様をユ ーザにではなく他のベンダに知られることを理由に、現行システムのベンダや業務パッ ケージシステムの受注ベンダが許諾しない場合も想定される。 3.4. クラウドサービスの調達 クラウドとは、一般的に「ネットワークを通じて、情報処理サービスを、必要に応じて提供／利用す る」形の情報処理の仕組みであり、その存在が雲の中にあるようなイメージであることからクラウドと称 されている。 29 3.4.1. 自治体におけるクラウドの活用等 自治体におけるクラウドの活用等においては、SaaS, PaaS, IaaS 等のクラウドサービスに 加え、ファシリテーションのみを提供するハウジングサービスや、プラットフォーム、業務 アプリケーション等が共同で利用可能な様々な形態が存在し、一般的なクラウドで要求され る仮想化、一元管理、自動化、オンデマンド等の技術を前提としない場合もある。 以下に自治体におけるクラウドの活用等の代表的な形態を示す。 ① クラウド型 SaaS や ASP のようにパブリッククラウド、 コミュニティクラウドとして提供される形態。 自治体では個人情報の取り扱い上の制約等から、利用できる業務システムが限られる場合が ある。 パブリッククラウド、コミュニティクラウドの詳細は TRM 本編「5. クラウド」を参照 されたい。 ② ハウジング型 アプリケーションの共同利用を前提とせず、各自治体の所有する業務システムをデータセ ンターに設置し、データセンターのファシリティを共同利用、すなわちハウジングサービス のみを利用する形態。仮想化等の技術も前提としない。 データセンター Ａ自治体システム Ａ自治体 （住民記録、税、福祉など） 業務 ﾕﾆｯﾄ 業務 ﾕﾆｯﾄ 業務 ﾕﾆｯﾄ なお、ハウジングについては「物品調達編 2.3. iDC・設備」を参照のこと。 ③ 共同利用型 複数の自治体が共通的に利用する業務システムをデータセンターに置き、業務アプリケ ーションを中心に、プラットフォーム、ファシリティ等を共同利用する形態。プラットフ ォームを各自治体毎に構築する、いわゆるオンプレミスの形態を含むところがクラウド型 とは異なる。 30 データセンター Ａ自治体システム Ａ自治体 （住民記録、税、福祉など） 業務 業務 業務 ﾕﾆｯﾄ ﾕﾆｯﾄ ﾕﾆｯﾄ 同システム Ｂ自治体 B自治体システム （住民記録、税、福祉など） 業務 業務 業務 ﾕﾆｯﾄ ﾕﾆｯﾄ ﾕﾆｯﾄ なお、総務省は、複数の自治体において主に基幹業務システムを自分たちの庁舎で保有・ 管理することに代えて、外部のデータセンターに集約し、ネットワークを経由して共同利用 できるようにする形の取組みへの支援を行っている。 3.4.2. 自治体におけるクラウド調達の留意事項 クラウドの活用では、自庁内に資産を持たないメリット、共同利用による費用の削減効果 等が期待されるが、 一方で、 運用経費や分担負担の妥当性、 共同利用に伴うセキュリティの 課 題、サービスの継続性、 ベンダ ロックインが容易になること等、留意事項も存在する。 ① ノンカスタマイズ クラウドの調達では、業務アプリケーション（パッケージシステム）のノンカスタマイズ が前提となるため、可能な限り業務のやり方をシステムにあわせることが必要となる。また、 クラウド型やSaaSタイプの共同利用型を利用する場合には、全ての利用自治体が運用形態、 場合によっては制度もシステムにあわせることが必要となる。 ② データ移行 クラウドの調達時には、個々の業務システムの開発が伴わないため、新システムの導入が 容易と誤解される場合があるが、データ移行については、従来と同様の作業が必要になり、 入念な計画、準備が必要となる。また、現在、使用中のクラウドから別のクラウドに変更す る場合においても、同様な準備が必要となる。 31 ③ 法改正等に伴う業務アプリケーションの改修 一般的なクラウドでは、システム改修が必要となった場合でも、サービスとして使用して いるので改修費用は原則として発生しない。しかし、自治体におけるクラウドでは、法改正 等によりシステム改修が必要となった場合は、ハウジング型では従来と同様に改修費用が発 生する。また、共同利用型であってもオンプレミスな構築をおこなっている場合には改修費 用が発生する場合がある。 ④ ベンダロックイン クラウドにおいては、業務システムの構造が従来の形態よりも、さらにブラックボックス 化するため、ベンダロックインの容易化が想定される。これに対抗し競争環境を醸成するた めには、別のクラウドへの乗り換えが可能な状態を担保しておくべきである。例えば、デー タ移行を容易にするため、 中間標準レイアウトの活用等、 予めデータのフォーマット提供と、 それに基づいた移行データの提供を契約に含めること等も有効である。 ⑤ セキュリティ対策 共同利用の場合、個人情報の取り扱いを中心に、各自治体のセキュリティポリシーとクラ ウドの形態、サービス、セキュリティ対策等が衝突しないか、十分に確認することが必要と なる。 ⑥ クラウド事業者の撤退リスク 自治体の基幹業務は１日たりとも停止させることが出来ない。また、クラウド事業者の倒 産、解散、ビジネス撤退等で、突然、サービスが停止される場合においても、クラウド事業 者等のデータセンターに蓄積された個人情報を含むデータを確実に移行、また、消去できる か、予め留意しておく必要がある。特に秘密保持契約を交わしていても、倒産により契約の 相手がいなくなることも想定しておくべきである。 ⑦ 外字の削減 データ移行の際は、各自治体が独自に管理している外字の同定作業を行う必要があり、多 くの時間と労力が割かれている。総務省が実施した市区町村における外字の実態調査結果を 活用するなど、クラウド移行にあたり不要な外字を削減しておくことが必要である。 なお、市区町村における外字の実態調査結果については、総務省ホームページの自治体ク ラウドポータルサイトを参照のこと。 http://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/lg-cloud/02kiban07_03000 021.html 32 第 4 章 インフラ基盤統合化のポイント 4.1. サーバインフラの統合化 小規模地方自治体においては、近隣の団体と共同で SaaS 型の業務パッケージシステムを調 達する動きも出てきているが、中規模以上の地方自治体においては、業務やシステムの運用等 の違いにより、小規模地方自治体と共同で SaaS を利用することが難しい状況にある。しかし、 ここ数年の仮想化技術の進歩により、サーバ、ネットワーク、ストレージ等を統合した仮想化 基盤の共同利用は可能な状況になりつつある。このため、自治体におけるクラウドの活用に向 けて、小規模な地方自治体は SaaS の積極的な利用が求められ、中規模以上の地方自治体はサ ーバインフラの統合が求められる。 これらを踏まえた、サーバインフラ統合化のポイントは次のとおり。 ・SaaS の積極的な利用 ・汎用型仮想化基盤の導入 ・仮想化基盤の所有から利用への転換 システム更改の際、複数の業務システムを搭載する仮想化基盤を調達し、サーバインフラを 統合化する地方自治体が増えているが、このことは、業務パッケージシステムの標準化が進ん だことと仮想化技術が進歩したことにより、業務パッケージシステムとサーバインフラの分離 が促進されたことを意味している。 仮想化基盤の構築において、特定業務パッケージシステムとその専用型仮想化基盤をサイロ 的に複数構築するよりも、複数の業務パッケージシステムが動作可能な汎用型仮想化基盤を構 築することにより、サーバインフラ統合化におけるスケールメリットや運用性、可用性等が高 まる。このことにより、業務パッケージシステムベンダとサーバインフラは分離され、ベンダ フリーのシステム構成となる。 仮想化基盤として、オンプレミスのプライベートクラウドを調達する選択肢もあるが、当面 の最終目標である SaaS 型クラウドへの中間目標として、サービスプロバイダが提供する IaaS や PaaS といったパブリッククラウドサービスの調達をも視野に入れる必要がある。 IaaS や PasS を調達することにより、 特定のサービスプロバイダへの依存度が低くなるため、 プライベートクラウドと比較し、より容易に SaaS 型クラウドへのシステム移行が可能になる。 この仮想化基盤の所有から利用への転換により、自庁への仮想化基盤の設置が不要になり、サ ーバインフラの運用からも開放される。 仕様書の作成にあたっては、 「本編 5.クラウド」を参照されたい。 33 【現在位置】 サイロ型 システム 汎用機 システム 【中間目標】 【最終目標】 業務 ユニット群 業務 ユニット群 業務 ユニット群 業務 ユニット群 ＯＳ ＯＳ ＯＳ ＯＳ ハード ウェア ハード ウェア ハード ウェア ＩａａＳ ＰａａＳ ハード ウェア プライベート クラウド ＳａａＳ 4.2. 端末の共通化 情報システムの TCO の削減や執務空間の省スペース化を目指し、デファクトスタンダード を採用し、一台で複数の業務システムの処理や OA 作業等が可能となるパソコンやプリンタ等 の端末を共通化する地方自治体が増えている。 サーバインフラの統合化に先立ち、端末の分野では業務パッケージシステムやサーバインフ ラからの分離が進み、端末の共通化が進んでいる。 端末の更改の際は、情報セキュリティの確保、端末の運用・保守の軽減、情報システムの TCO 削減の観点から、仮想化技術を用いたデスクトップの仮想化やシンクライアントシステムの調 達も視野に入れる必要がある。 仕様書の作成にあたっては、 「物品調達編 5.8.共通 PC・オフィスプリンタ」を参照されたい。 34