情報システム調達のための技術参照モデル（ＴＲＭ）

平成 25 年度版

自治体編

～地方自治体における情報システム調達の考え方～

2014 年 10 月作成

2015 年 3 月更新

経済産業省 商務情報政策局 情報処理振興課

独立行政法人 情報処理推進機構

1

目次 はじめに ................................................................................................................................................. 4

＜地方自治体における情報システム調達のための TRM の位置づけ＞ ........................................... 4

第 1 章 本編の活用方法...................................................................................................................... 6 1.1.地方自治体におけるシステム調達の基本的な考え方 ..................................................................... 6

1.1.1.業務システム構成要素の分離と再構成 ..................................................................................... 6

1.1.2.業務パッケージシステムの活用 ................................................................................................. 7

1.1.3.システム更改時の課題 ................................................................................................................ 7

1.2.地方自治体におけるシステム調達の流れ ........................................................................................ 9

第 2 章 地方自治体における業務システムの動向 ......................................................................... 10 2.1.業務システムの標準化 ..................................................................................................................... 10

2.1.1.デファクトスタンダードの採用 .................................................................................................... 10

2.1.2.仮想化技術の採用 ..................................................................................................................... 10

2.1.3.地域情報プラットフォーム準拠 .................................................................................................. 11

2.1.4.文字コードやフォントの標準化 .................................................................................................. 11

2.2.文字情報基盤 .................................................................................................................................... 12

2.2.1.文字情報基盤とは ...................................................................................................................... 12

2.2.2.文字情報基盤の実装上の問題点 ............................................................................................. 12

2.2.3.文字情報基盤の利用 ................................................................................................................. 14

2.3.情報セキュリティ ................................................................................................................................ 17

2.3.1.地方自治体の情報セキュリティについて ................................................................................. 17

2.3.2.地方自治体情報システム役務調達時の情報セキュリティについての留意点 ...................... 17

2.3.3.情報セキュリティと個人情報保護、業務継続計画 ................................................................... 18

2.3.4.情報セキュリティと自治体業務パッケージシステム ................................................................ 19

2.3.5.地方自治体の情報セキュリティ監査実施時についての留意点 ............................................. 19

2.3.6.参照すべき基準・ガイドライン ................................................................................................... 19

第 3 章 業務アプリケーション調達のポイント .................................................................................. 20 3.1.地域情報プラットフォーム ................................................................................................................. 20

3.1.1.地域情報プラットフォームとは ................................................................................................... 20

3.1.2.地域情報プラットフォームの準拠登録 ...................................................................................... 21

3.1.3.地域情報プラットフォーム準拠登録製品の調達時の留意事項 .............................................. 22

3.2.共通基盤 ............................................................................................................................................ 23

3.2.1.共通基盤について ..................................................................................................................... 23

3.2.2.地方自治体における共通基盤 .................................................................................................. 23

3.2.3.統合 DB ...................................................................................................................................... 24

3.2.4.共通基盤の構成単位 ................................................................................................................. 24

2

3.2.5.共通基盤の調達の留意事項 ..................................................................................................... 26

3.3.業務パッケージの調達...................................................................................................................... 27

3.3.1.自治体業務アプリケーションの特徴 ......................................................................................... 27

3.3.2.パッケージシステムの活用 ....................................................................................................... 27

3.3.3.カスタマイズの抑制 .................................................................................................................... 28

3.3.4.カスタマイズの抑制のための方策 ............................................................................................ 29

3.3.5.システム要件定義 ...................................................................................................................... 30

3.3.6.共通基盤への接続 ..................................................................................................................... 31

3.3.7.業務パッケージシステム調達における文字情報..................................................................... 31

3.3.8.業務パッケージシステム調達におけるデータ移行 .................................................................. 32

3.3.9.データ形式の統一 ...................................................................................................................... 34

3.4.クラウドサービスの調達 ................................................................................................................... 35

3.4.1.地方自治体におけるクラウドの活用等..................................................................................... 35

3.4.2.地方自治体におけるクラウド調達の留意事項 ......................................................................... 36

第 4 章 インフラ基盤統合化のポイント ............................................................................................. 39 4.1.サーバインフラの統合化 .................................................................................................................. 39

4.2.端末の共通化 .................................................................................................................................... 41

第 5 章 ＩＴ調達テクニカルノウハウ集 ............................................................................................... 42 5.1.情報提供依頼（ＲＦＩ）の実施 ............................................................................................................. 42

5.1.1.課題認識 ..................................................................................................................................... 42

5.1.2.解決の方向性 ............................................................................................................................. 42

5.1.3.事例 ............................................................................................................................................. 43

5.1.4.補足 ............................................................................................................................................. 44

5.2.文字情報基盤の活用 ........................................................................................................................ 45

5.2.1.課題認識 ..................................................................................................................................... 45

5.2.2.解決の方向性 ............................................................................................................................. 45

5.2.3 事例 ............................................................................................................................................. 45

5.2.4.補足 ............................................................................................................................................. 46

5.3.IT ガバナンスの確立 ........................................................................................................................ 48

5.3.1.課題認識 ..................................................................................................................................... 48

5.3.2.解決の方向性 ............................................................................................................................. 48

5.3.3.事例 ............................................................................................................................................. 48

3

はじめに

番号制度の導入や SaaS 型クラウドの検討等、地方自治体の業務はより一層の標準化を求め

られている。一方、地方自治体で導入する情報システムについても、パッケージシステム化や

デファクトスタンダード技術の採用等の標準化が進んでいる。このことは、情報システム調達

仕様書の標準化も可能なことを意味している。 本編は、地方自治体の情報システム調達に関係する方々が、その調達において標準的な言葉

で円滑なコミュニケーションを図ることが可能となり、最良の情報システム構築に資するよう

作成したものである。

＜地方自治体における情報システム調達のための TRM の位置づけ＞

地方自治体の情報システムは、取り扱う事務内容や事業規模が異なることから、自治体ごと

に大きく異なっている。また、自治体数も全国で約 1,800 団体と多く、多様である。 地方自治体は地方自治法により、「普通地方公共団体」と「特別地方公共団体」に分類されて

いる。「普通地方公共団体」とは一般的に呼ばれている「地方自治体」であり、広域的な市町村

を統括する「都道府県」と基礎的な地方公共団体としての「市町村」がある。また、「市」は、

人口 5 万人以上、都市化の状況などの要件が、地方自治法により定められており、「市」は、

更に規模等に応じて次の 4 つの区分があり、国が政令により指定する。 「指定都市」(人口 50 万人以上) 「中核市」(人口 30 万人以上) 「特例市」(人口 20 万人以上) 「一般の市」 人口規模や都市化の状況などにより、「町」「村」が定められている。 「特別地方公共団体」には東京都の「区」(23 区)や地方公共団体の組合などがある。 各分類の地方自治体の数は、平成 24 年 1 月 4 日現在で以下のとおり。

都道府県･･･47、指定都市･･･20、中核市･･･41、特例市･･･40、一般の市･･･688 町･･･746、村･･･184

地方自治体には自治事務と法定受託事務があるが、指定都市、中核市、特例市は都道府県か

らそれぞれ事務が委譲されており、一般の市とは業務が異なる。 これらの地方自治体の分類により、事務処理内容に大きく差が生じるため、それぞれの分類

毎に、情報システムの範囲や規模に違いが生じている。 一般に、都道府県は、市町村のような業務システムとしては、税務事務以外はなく、財務会

計、庶務事務、人事給与、文書管理といった内部事務と道府県民税、事業税などの税務事務が

基幹システムとなっている。また、それぞれの事務処理量が多いことから、都道府県ごとに汎

用機システムを独自に開発して運用することが多い。近年ではオープンな標準に基づいた業務

4

システムへの移行が進んでいるが、業務要件や技術要件の共通性が低く、独自の情報システム

調達となっている。 指定都市は他の市と異なり、人口規模が大きく、行政区もあることから、汎用機による情報

システム化がいち早く進んできた経緯や、事務処理内容もそれぞれ異なることから業務パッケ

ージシステムの採用が遅れている状況となっている。また、各情報システムの規模が大きく、

業務要件や技術要件の共通性も低く、独自の情報システム調達が行われている。 中核市、特例市、一般の市の情報システムは、それぞれの業務要件や技術的な要件の共通性

が高い傾向があるが、規模やシステム化の進捗度には差が生じている。近年では汎用機からの

オープンシステムへの最適化も進みつつあり、また、業務パッケージシステムのカスタマイズ

導入など調達の要件を明確化する必要がある。このため、本編はこれらの中核市、特例市、一

般の市の情報システムの調達に向けて活用されることを目的にしている。 なお、町、村の情報システムについては、業務パッケージをカスタマイズせず、そのままで

導入する事例が多く、導入した業務パッケージに合わせて業務を見直す場合もある。

5

第 1 章 本編の活用方法

1.1.地方自治体におけるシステム調達の基本的な考え方

1.1.1.業務システム構成要素の分離と再構成

地方自治体における業務システムの構成要素は、大きく 1．業務パッケージシステム（業務

ユニット）、2．サーバインフラ（サーバ・ネットワーク・ストレージ等）、3．端末（PC・プ

リンタ等）の三点に分類される。これまでは、この三点を業務システムごとにまとめて調達し、

ライフサイクルをそろえる傾向にあったが、このことが業務システムのサイロ化や硬直化をも

たらし、情報システムの TCO の増大、システムリソースの肥大化、運用管理の複雑化等を招

いてきた。

業務システム群

分離

業務システム群

業務パッケージシステム

（業務ユニット）

サーバインフラ（サーバ・

ネットワーク・

ストレージ等）

端末（ＰＣ・プリンタ等）

業務パッケージシステム

（業務ユニット）

仮想化基盤（サーバ・

ネットワーク・

ストレージ等）

端末（ＰＣ・プリンタ等）

図 1.1-1 システムの分離

これらを解消するものとして、近年、仮想化技術やデファクトスタンダードを採用した業務

システムが台頭してきたため、図 1.1-1 のように上記の三点を分離して捉え、情報システム最

適化の観点からそれぞれを標準化、統合化、共通化のうえ再構成する動きが出てきている。 この再構成を推進することにより、サーバ、ネットワーク、ストレージ等を統合した仮想化

基盤を導入し、硬直化したサイロ型の独自システムから仮想化基盤に対応した業務パッケージ

システムへ移行する地方自治体が出てきている。更に、標準化の動きが加速すると、アプリケ

ーションを共同利用する SaaS 型クラウドの実現が容易になる。 また、このことをシステム調達の観点から見ると、業務システムの各構成要素が密結合され

ないため、分離調達が可能になる。 なお、地方自治体におけるクラウドの活用については「3.4.クラウドサービスの調達」を、

仮想化技術については「クラウドサービス編」を参照されたい。

6

1.1.2.業務パッケージシステムの活用

全ての地方自治体が同じ法律に基づき同じ業務を実施しているため、一部の大規模自治体を

除き業務パッケージシステムの活用が主流となっており、独自開発は減少している。このため、

ほとんどの地方自治体においては、業務と業務パッケージシステムとのフィットアンドギャッ

プ分析とライフサイクルコストとのバランスによるシステム選定が主流となっている。

図 1.1-2 仮想化技術の適用例 ここ数年、業務パッケージシステムはデファクトスタンダードの採用や地域情報プラットフ

ォーム準拠等によるシステムの標準化が進むとともに、仮想化技術への対応も進み、地方自治

体におけるクラウド活用を見据えた製品が主流になりつつある（図 1.1-2）。 地域情報プラットフォームについては「3.1.地域情報プラットフォーム」を参照されたい。

1.1.3.システム更改時の課題

地方自治体においては定型業務のシステム化がほぼ終了しており、新規システムの導入より

もシステム更改の割合が多くなっている。 システム更改においては、旧システムから新システムへのデータ移行作業の煩雑さや移行経

費が課題となっている。更に、データ移行の際、文字コードや外字を整理していない場合、移

行ミスやデータ連携を行う際の煩雑さに直結する恐れがある。 また、独自業務システムから業務パッケージシステムに移行するとともに、サーバインフラ

として、サイロ型システムを解消するためのサーバ統合を目的としたプライベートクラウド等

の仮想化基盤を導入する地方自治体が増えている。 この際、業務パッケージシステムベンダごとに専用の仮想化基盤を導入すると、サイロ型シ

Ａ業務システム

サーバ

ＯＳ

Ａ業務ユニット

Ｂ業務システム

サーバ

ＯＳ

Ｂ業務ユニット

Ｃ業務システム

サーバ

ＯＳ

Ｃ業務ユニット

Ａ業務システム

仮想マシン

ＯＳ

Ａ業務ユニット

Ｂ業務システム

仮想マシン

ＯＳ

Ｂ業務ユニット

Ｃ業務システム

仮想マシン

ＯＳ

Ｃ業務ユニット

仮想化基盤

標準化

専用端末

専用端末

専用端末

共通端末

共通端末

共通端末

統合化

共通化

7

ステムを解消するはずが、仮想化基盤自体がサイロ型となり、サーバ統合のメリットが最大限

に活かされない恐れがある。

8

1.2.地方自治体におけるシステム調達の流れ

地方自治体における情報システム調達の流れとシステムのライフサイクルの考え方は政府調

達と原則同じである（表 1.2-1）。 表 1.2-1 情報システム調達の流れ

№ フェーズ 当該フェーズにおける情報システムの調達例 １ 企画 システム導入（更改）計画策定支援 ２ 調達 システム調達（RFI･RFP）支援 ３ 開発 システム構築（設計・開発・試験・移行・プロジェクト管理） ４ 運用・保守 システム運用・保守・ヘルプデスク ５ 廃止 システム移行・撤去・廃棄

地方自治体においては、業務パッケージシステムの導入が主流となっている。このため、開

発フェーズにおいては、独自業務システムの導入に象徴される要件定義・設計・開発といった

作業の割合は少なく、次の作業割合が多くなる。 ・業務パッケージシステムと業務とのフィットアンドギャップ分析 ・仮想化基盤との調整 ・LAN/WAN 等のネットワークに関する調整 ・他システムとのデータ連携インタフェースに関する調整 ・文字コードと外字の仕様調整 ・旧システムからのデータ移行に関する調整 ・端末（パソコン・シンクライアント・プリンタ・スキャナ等）調整 ・運用・保守調整 ・各種試験 ・プロジェクト管理

9

第 2 章 地方自治体における業務システムの動向

2.1.業務システムの標準化

地方自治体は番号制度の導入や SaaS 型クラウドの実現に向けて、標準化された業務パッケ

ージシステムの調達が求められている。業務パッケージシステムにおける標準化のポイントは

次のとおり。 ・デファクトスタンダードに準拠した OS やミドルウェア等で構成されていること。 ・カスタマイズを抑制すること。 ・仮想化技術に対応していること。 ・地域情報プラットフォーム準拠製品であること。 ・標準化された文字コードやフォントに対応していること。

2.1.1.デファクトスタンダードの採用

情報システムの TCO の削減や SaaS 型クラウドを見据えた業務の標準化を考慮し、業務シ

ステムを独自開発する地方自治体は減少しており、デファクトスタンダードを採用した業務パ

ッケージシステムを導入することが一般的になっている。 また、導入の際は、事前作業として BPR を十分に行うことにより、個々の地方自治体の独

自仕様によるカスタマイズを極力抑えることが望まれる。このことにより、より一層、情報シ

ステムの TCO の削減が可能となり、保守の容易性が増すことにつながる。

2.1.2.仮想化技術の採用

近年、サイロ型となり硬直化したシステムのサーバインフラ統合で脚光を浴びている仮想化

技術を採用し、IaaS や PaaS 等に対応した業務パッケージシステムが出現してきている。この

仮想化技術を用いた業務パッケージシステムを導入した場合、情報システムの TCO の削減や

運用管理の一元化が見込まれると同時に、将来、アプリケーションの共同利用を前提とした

SaaS 型クラウドへ業務システムを移行するうえでの容易性や互換性が見込まれる。 また、仮想化技術を活用することにより、ハードウェアの二重化などに要する費用を比較的

抑えることができるとともに、省電力効果や冷却効率の上昇が見込まれ、グリーン IT の実現

に寄与する。 なお、地方自治体におけるクラウドの活用については「3.4.クラウドサービスの調達」を、

仮想化技術については「クラウドサービス編」を参照されたい。

10

2.1.3.地域情報プラットフォーム準拠

地方自治体内部における業務システム間連携の標準化や、番号制度を見据えた地方自治体間

連携を実現するために、一般財団法人全国地域情報化推進協会（以下、「APPLIC」という。）

が提唱する地域情報プラットフォームに準拠した業務パッケージシステムの調達が一般的にな

りつつある。このことにより、特定ベンダに依存することなく、連携仕様が標準化された業務

パッケージシステムを、容易に調達し、必要に応じて変更することが可能となる。 地域情報プラットフォームについては「3.1.地域情報プラットフォーム」を参照されたい。

2.1.4.文字コードやフォントの標準化

SaaS 型クラウドや地域情報プラットフォーム、あるいは、番号制度を実現するための前提

条件として、地方自治体や業務システムごとに異なる文字コードやフォントを統一する必要が

ある。 具体的には、各業務システム間の情報流通を標準化、簡素化するため、デファクトスタンダ

ードになっているUnicode に対応した業務システムを調達する必要がある。 また、外字については情報流通を阻害する要因となるため、全国的な統一化が課題となって

いる。 今後は、独立行政法人情報処理推進機構（以下、「IPA」という。）が提供する、文字の標準

化を目指す文字情報基盤に対応した業務パッケージシステムの出現が求められる。 文字情報基盤については「2.2.文字情報基盤」を参照されたい。

11

2.2.文字情報基盤

2.2.1.文字情報基盤とは

地方自治体のシステム、特に基幹系システムの調達時に特に留意しなければならないことに、

文字の問題がある。従来は一般的なシステムでは、JIS X 02081の範囲をシフト JIS 符号化方

式で、近来は JIS X 02132の範囲をUnicode の符号化方式で実装する範囲で納まっていた。し

かし、地方自治体等の人名を扱う行政システムでは、従来から外字があると他のシステムとの

間でのデータ交換が困難になる、いわゆる外字問題が存在していた。 従来は、自治体基幹系業務と呼ばれる住民記録や外国人登録などのデータは、大型汎用機等

で管理されており、文字コードは、各汎用機ベンダで異なり、それぞれの拡張エリアにベンダ

固有の拡張文字及び、個々の地方自治体独自作成の外字があるのが実情であった。 近年、Windows へ移行が進み、Unicode が主流になってきており、扱える文字の範囲も広が

って来たが、各汎用機ベンダは汎用機から Windows へ移行する際にその互換性を重視した結

果、Windows においても独自のコード体系とすることが行われてきたため、システムを調達す

る場合やデータ移行する際に大きな妨げになっている。 このような現状から、IPA では、文字の国際標準と整合性の取れる扱いを推進するため、戸

籍統一文字や住民基本台帳統一文字を網羅した、氏名漢字 58814 文字の画像と画数などの文字

情報を整備した文字一覧表を公開するとともに、実運用に必要な環境を整備しているところで

ある。 文字情報基盤の詳細については次を参照されたい。 http://mojikiban.ipa.go.jp/

2.2.2.文字情報基盤の実装上の問題点

文字情報基盤は平成23年10月にフォントと文字情報一覧表が公開され、平成24年11月にはフ

ォントがVer.002.02へ、文字情報一覧がVer.003.01へバージョンアップされ、平成26年9月には

フォントがVer.003.01へ、文字情報一覧がVer.004.01へバージョンアップされ、一般に利用でき

るようになった（図2.2-1）。

1JIS X 0208：7 ビット及び 8 ビットの 2 バイト情報交換用符号化漢字集合 2JIS X 0213：7 ビット及び 8 ビットの 2 バイト情報交換用符号化拡張漢字集合

12

住基統一（漢字のみ）（19.563文字）

ＩＰＡｍｊ明朝フォント Ｖｅｒ.003.01 戸籍統一（漢字のみ）（55.270文字）

登記固有文字

（10.330）

文字情報基盤漢字（58,815文字）

非漢字（2,014図形/1,684文字）

縦書用文字 リガチャを含む

ＢＭＰ（全65,536文字）ＣＪＫ統合漢字拡張

Ｂ～Ｅ（約57,000文字）ＩＶＤ

現在は符号化対象外

1,684文字24,210文字 26,734文字 5,930文字

1,941文字

ISO/IEC 10646UCS

(Universal Coded Character Set)

ほぼすべての情報機器で利用可能

市販の最新の多くの情報機器で利用可能

一部のＯＳ、アプリケーションで対応が始まっている

図 2.2-1 IPAmj 明朝フォント Ver.003.01 の符号化状況

しかしながら正式版にも実装にあたっては様々な問題点が残っている。

（１）IVS 技術の普及の問題 文字情報基盤では IVS(Ideographic Variation Sequence/Selector)技術が用いられている

（図 2.2-2）。現在では、IVS 技術と IVD(Ideographic Variation Database)登録を用いるこ

とにより、同一の符号位置に対応づけられる複数の文字図形を使い分けることは、国際規格

としては標準化されているが、実装技術として十分に確立しているとは言い難く、一般に普

及していない 3。 なお、IVS/IVD については次を参照されたい。 http://mojikiban.ipa.go.jp/1292.html

3平成 24 年 11 月から、一部製品（OS、オフィスソフト）での対応が始まっている。

13

「IVD/IVS とは（http://mojikiban.ipa.go.jp/1292.html）」より引用

図 2.2-2 IVS による字形差異の区別

（２）UCS 対応関係が不確定 文字情報一覧表においてUCS 対応関係がカテゴリー分けされており、例えばカテゴリーA

は文字情報基盤整備事業で対応関係が確認されていると分類されている。カテゴリーがB と

分類されているものは、今後、対応関係が変更される可能性があるため、文字情報基盤では

カテゴリーB の UCS 欄の利用を控えることを推奨している。現時点の最新版（Ver.003.01）では、文字情報一覧表の UCS 欄の値は、ほぼ確定しており、この情報に基づき、UCS での

符号化が必要な 1,941 文字については、標準化に向けた国際提案を行っている。

（３）UCS･IVS 未実装の問題 CJK 統合漢字に J ソースがなく、符号位置特定の作業が継続中であるものや、対応する

UCS 符号位置が標準化されていないものや対応符号位置が明確でないものについては

IPAmj 明朝フォントでは、UCS 符号位置による使用ができない。

2.2.3.文字情報基盤の利用

現状では文字情報基盤はそのままシステムとして実装することは困難であるが、同事業の成

果物を利用する場合には、慎重な配慮のうえで、以下のような方法も考えられる。例えば、該

当文字図形が未実装により存在しない場合は、その文字図形を、従来のように私用領域に割り

当てて運用する。そうして作成された派生フォントは、フォント名称の変更などの必要な対応

を取ることにより、IPAmj 明朝フォントと同様に、IPA フォントライセンス 1.0 に従えば自由

に複写・利用することができる。

14

（１）ベースフォントとして利用

文字情報基盤の IPAmj 明朝フォントは、通常のUCS 符号位置を経由した用法では、実装

されている約 6 万文字全てを使用できないが、JIS X 0213:2004 の文字は全て利用できるた

め、そのままベースフォントとしての利用が可能である。ベースフォントを固定化すること

でフォントのバージョンによる相違を解消できるほか、将来的に IPAmj 明朝フォントが全て

の字形に対し UCS･IVS 実装が行われ、IVS 技術が普及し業務アプリケーションが対応した

場合にベースフォントを変更する必要がない等のメリットがある（図 2.2-3）。

共通基盤文字情報管理システム

個別基盤

業務Ａ 業務Ｂ 業務Ｃ

連携サーバ

外部システムＤ

外部システムＦ

対象システム

ベースフォント（JISX0213:2004、住基ネット統一文字、文字情報基盤文字相当セット）

外部システムＥ

JISx0213:2004

国民健康保険団体連合会文字

文字情報基盤文字情報技術促進協議会暫定私用コード

後期高齢者医療広域連合会文字

入国管理局在留カード文字

戸籍統一文字

住基ネット明朝文字

図 2.2-3 文字情報基盤を活用したシステム構成の例

（２）データ移行時のマスターとして利用

システム更新や合併等により、業務パッケージベンダが変わる場合、文字体系やベースフ

ォントも変更となる場合が多い。その場合、マスターとして MJ 文字図形名と個々の地方自

治体内の文字の対応テーブルを整備しておくことで、正確な字形の情報交換ができることに

より文字同定作業の負担を軽減できる。

（３）文字情報一覧表の属性情報の利用 文字情報基盤の成果物は IPAmj 明朝フォントのほか、読み、画数などの属性情報を整理し

た文字情報一覧表がある。約 6 万文字の文字を実際し使用するためには、該当文字を検索し特定

する必要があるが、文字情報一覧表はこの文字検索に活用することができる。また、属性情報には

読み、画数などのほか、戸籍統一文字番号や住基ネット統一文字コードなども収録されてお

り、地方自治体が整備すべき変換テーブルのベースとすることが可能である。

（４）外字作成時の負担軽減

15

IPAmj 明朝フォントは、通常の UCS 符号位置経由では、約 6 万文字全てを利用できないが、

SVG フォーマットによる文字図形データも配布されているため、そのデータを流用し文字作

成が可能である。外字作成担当者の文字作成の負担軽減や、文字作成を委託している場合に

は経費削減効果が期待できる。

（５）派生フォントによる活用 IPAmj 明朝フォントは、IPA フォントライセンス 1.0 に従えば自由に複写・利用すること

ができるため、SVG フォーマットファイルなどを利用した派生フォントを作成することがで

きる。例えば IPAmj 明朝フォントで実装していない字形を全て実装することも可能であり、

印刷アウトソーシングなどへの活用が期待できる。この際、変更内容によっては、フォント名を変更

するなどの対応が必要になる場合がある。

（６）外部システム間の連携

その他、MJ 文字図形名との同定が完了している機関のシステム同士では、MJ 文字図形

名を介すことで正確な字形を交換が可能となる。

16

2.3.情報セキュリティ

2.3.1.地方自治体の情報セキュリティについて

政府機関における情報セキュリティ対策と同様に、個々の地方自治体の情報セキュリティに

ついても、「地方公共団体における情報セキュリティポリシーガイドライン」（平成 13 年 3 月

30 日策定、平成 27 年 3 月 27 日改定 総務省）をもとに「情報セキュリティポリシー」を策

定し、それに基づいて情報セキュリティ対策を実施している。 また、その情報セキュリティ対策が組織内において、適切に整備・運用されているかを点検・

評価するため「地方公共団体における情報セキュリティ監査に関するガイドライン」（平成 15年 12 月 25 日策定、平成 27 年 3 月 27 日改定 総務省）等に基づき、情報セキュリティ監査

を行っている。 本章では、地方自治体が、その情報システム調達時の情報セキュリティについて、また情報

セキュリティ監査の際に留意すべき点について示している。

2.3.2.地方自治体情報システム役務調達時の情報セキュリティについての留意点

基本的に、地方自治体による情報システム役務調達において、留意すべき点は、法令（特に

地方自治体条例）の遵守やポリシー、ガイドライン（基準）等の準拠となる。受注者は、全て

の作業において１～４に挙げている内容に留意することが重要である。なお、応札の条件とな

る制約については、全て列挙する必要があり、準拠すべきポリシー、ガイドライン（基準）等

は、応札中の応札者に開示される必要がある。 地方自治体は、その情報セキュリティポリシーについて、情報セキュリティに係る状況の変

化に留意し、定期的にその内容を見直さなければならない。 クラウドサービスを利用する際、そのサービスが海外のデータセンターにサーバを有する場

合は、機微情報を含む個人情報等が海外に持ち出され、国内法等、国内規制が及ばなくなる可

能性があるので、契約するにあたっては、十分な注意が必要である（表 2.3-1）。 注意すべき点について、具体的には、 ・運営会社がデータの所在地について、明らかにすることに同意しているか ・上記の場合において、データをどこのデータセンターに収容しているか ・運営会社について、外国企業の場合は、運営会社に対する所在地国法の規制内容 等が挙げられる。

参考）「クラウドサービス利用のための情報セキュリティマネジメントガイドライン2013年版」 （経済産業省・平成 26 年 3 月 14 日）P84「データセンターの所在」

http://www.meti.go.jp/press/2013/03/20140314004/20140314004-2.pdf

17

表 2.3-1 クラウド契約時の留意点

留意点 留意点の概要 仕様書に記載するポイント １． 情報セキュリティポ

リシーの準拠

各地方自治体の情報セキュリティ

ポリシーに準拠すること。 各地方自治体の情報セキュリティポ

リシーに準拠して仕様書を作成して

いる場合は、セキュリティ要件につい

ての記載のなかに当該ポリシーに準

拠する旨を明記する。 ２． 各種法令・規制等の遵

守

各地方自治体の情報システムの管

理運営に関する条例、個人情報保護

条例、個人情報保護法（個人情報の

保護に関する法律）、刑法、著作権

法、不正アクセス禁止法等、当該の

調達案件において関連する各種法

令等を遵守すること。

対象となる情報システム、業務が関連

する法令・規制に関しては仕様書上で

明記を行い、遵守する旨を記載するこ

と。

３． その他ガイドライン

の準拠

上記以外に、受注者に準拠又は対応

を求めるべきガイドラインが存在

する場合には、受注者は当該のガイ

ドラインに準拠すること。（政府機

関用の基準も必要に応じ参照する）

情報システムの内容等から１~２以外

に準拠するガイドラインを抽出し、仕

様書に準拠又はガイドラインを実現

する提案を求める旨を記載すること。

４． 再委託先に対する情

報セキュリティポリ

シー等の適用

業務の一部を各地方自治体の承認

を得て、再委託する場合は、再委託

を行う事業者にも受注者と同様の

内容に準拠させること。（過去の地

方自治体における個人情報等の漏

えい事例では、再委託先においての

管理不備によるものが多いため特

に注意。）

一部業務について再委託先の活用が

想定される場合には、再委託先にも受

注者と同様の内容に準拠する必要が

あることを明記すること。

2.3.3.情報セキュリティと個人情報保護、業務継続計画

膨大な個人情報を保有する各地方自治体は、各自治体の個人情報保護条例、個人情報保護法、

に基づき、個人情報を保護する義務があり、かつ保有する個人情報が常に正確でなければなら

ない。情報セキュリティ対策は、このように個人情報の保護を行うための手段のひとつであり、

同時に個人情報保護条例、個人情報保護法は、情報セキュリティ対策に法的根拠を与えうるも

のである。 また、各地方自治体は、災害（直下型地震や新型インフルエンザ等）の発生時に業務遂行能

力が低下した状況下において、非常時優先業務（応急業務及び一部の通常業務）をまず継続・

再開・開始し、その後、優先順位に応じて業務を全面復旧するための計画（業務継続計画=BCP）

18

を予め策定しておく必要がある。そのため、それらの業務に対応するシステムも、必要に応じ

て、継続・再開・開始するための、いわゆる「ICT‐BCP」（システムに関する業務継続計画）

も併せて策定しておく必要がある。この「ICT‐BCP」は、情報セキュリティの構成要素「可

用性」に関連するものである。 各地方自治体は、「ICT‐BCP」を含む業務継続計画が有効に運用されるために、代替設備等

の検討を行うとともに、BCP 発動時の訓練等を定期的に行い、PDCA サイクルをもって常に

内容を見直さなければならない。

2.3.4.情報セキュリティと自治体業務パッケージシステム

地方自治体での業務パッケージシステム導入に際しては、各パッケージの情報セキュリティ

対策を検証し、各地方自治体の情報セキュリティポリシーに合致したものであることを確認し

なければならない。クラウドの活用において、自治体業務パッケージシステムを用いる場合も

同様である。

2.3.5.地方自治体の情報セキュリティ監査実施時についての留意点

各地方自治体において、情報セキュリティ監査を実施する際は、内部監査、外部監査とも「地

方公共団体における情報セキュリティ監査に関するガイドライン」等に基づいて行う旨、明示

する。 その際には、「組織」を対象とする（運用面やガバナンスに力点を置く）ものか「情報システ

ム」を対象とする（安全性の監査に力点を置く）ものか等、監査趣旨を明示して行うことが望

ましい。情報セキュリティ監査を調達する際にも、その旨を仕様書に明示することが望ましい。

2.3.6.参照すべき基準・ガイドライン

・「地方公共団体における情報セキュリティポリシーガイドライン」 各地方公共団体（地方自治体）が、情報セキュリティポリシーの策定や見直しを行う際の参考

として、情報セキュリティポリシーの考え方及び内容について解説したものである。 http://www.soumu.go.jp/main_content/000348656.pdf （最新版：平成 27 年 3 月 27 日 総務省） ・「地方公共団体における情報セキュリティ監査に関するガイドライン」

各地方公共団体（地方自治体）に対し、情報セキュリティ監査の標準的な監査項目と監査手順

を示すものである。 http://www.soumu.go.jp/main_content/000348657.pdf

（最新版：平成 27 年 3 月 27 日 総務省）

19

第 3 章 業務アプリケーション調達のポイント

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

3.1.1.地域情報プラットフォームとは

地域情報プラットフォームは、様々なシステム間の連携を可能にするために、各システ

ムが準拠すべき業務面や技術面のルールを標準仕様として規定したものである。SOAPやXMLなどの標準技術を活用して情報システムの基盤を共通化することで、異なる情報シス

テム間でのシームレスなデータ交換を実現することを目的としている。 なお、APPLICでは「自治体業務アプリケーションユニット標準仕様V2.4」において、

26の業務ユニットを規定している（表3.1-1）。

表 3.1-1 ２６の業務ユニット 番号 業務ユニット名 概要 １ 住民基本台帳 住民の転入・転出・転居・出生・死亡等の異動、照会や証明書の発行・

通知書の出力等を行う。 ２ 印鑑登録 印鑑の登録・廃止・印鑑証明の発行等を行う。 ４ 選挙人名簿管理 選挙人名簿の管理、入場券発行、不在者投票、住民投票の管理等を行

う。検察審査会、農業・海区・漁業委員会選挙人名簿作成を行う。 ５ 固定資産税 固定資産税課税台帳（土地・家屋・償却資産）の評価・賦課・証明書

発行・統計処理等を行う。 ６ 個人住民税 個人住民税の課税対象管理・資料の管理・賦課・統計処理等を行う。 ７ 法人住民税 法人台帳の管理・賦課台帳管理等を行う。 ８ 軽自動車税 車輌台帳の管理・賦課・証明書発行等の処理を行う。 ９ 収滞納管理 個人住民税、法人住民税、固定資産税、軽自動車税及び国民健康保険

税（料）の収納情報・滞納整理情報の管理、消込・滞納整理・過誤納

の処理、統計出力等を行う。 １０ 国民健康保険 資格の管理・保険証の発行、所得資産の管理・保険税（料）の賦課、

レセプトのチェック・管理、療養費等の給付、統計処理等を行う。 １１ 国民年金 国民年金資格の管理・付加・免除・給付の管理を行う。 １２ 障害者福祉 対象者の資格管理、進達処理、通知書発行、支払管理、統計処理等を

行う。 １３ 後期高齢者医療 対象者の資格管理、保険料の賦課管理、収納管理、滞納管理を行う。 １４ 介護保険 介護保険被保険者の資格管理・介護保険料の賦課・介護保険料の収納

管理・受給者の台帳管理を行う。 １５ 児童手当 対象者の資格管理、現況受付、支払管理、統計処理等を行う。 １６ 生活保護 生活相談受付、保護申請審査、支給管理、統計処理等を行う。 １７ 乳幼児医療 対象者の資格管理、現物給付や償還払いによる医療費支払及び統計報

20

告処理等を行う。 １８ ひとり親医療 対象者の資格管理、現物給付や償還払いによる医療費支払及び統計報

告処理等を行う。 １９ 健康管理 成人検診・母子健診・予防接種情報の管理、保健指導、統計報告資料

作成、データ分析の処理を行う。 ２０ 就学 学齢簿の出力、小学校・中学校の就学通知の発行等を行う。 ２１ 戸籍 本籍人の出生・死亡・婚姻・離婚・養子縁組・養子離縁などの異動、

照会、証明書発行、及び通知書出力等を行う。また附票管理を行う。 ２２ 子ども手当 対象者の資格管理、現況受付、支払管理、統計処理等を行う。 ３０ 住登外管理 住登外者・法人情報の管理を行う。 ５０ 財務会計

予算編成・予算管理・歳入管理・歳出管理・歳計外現金・出納管理・

決算管理等の処理を行う。 ５１ 庶務事務 勤怠管理・各種手当申請・その他各種申請・照会／配布・福利厚生管

理・年末調整管理・正規職員以外管理等の処理を行う。 ５２ 人事給与 申請受付・計算・年末調整・支払・人事・福利厚生・研修等の処理を

行う。 ５３ 文書管理 公文書の収受・起案・承認／決裁・施行・保管・検索／照会・ファイ

ル管理・情報公開等の処理を行う。 なお、地域情報プラットフォームの詳細についてはAPPLIC のホームページを参照されたい。

http://www.applic.or.jp/index.html

3.1.2.地域情報プラットフォームの準拠登録

APPLIC では、地域情報プラットフォーム標準仕様に準拠した製品に対し、準拠登録及び相

互接続確認を行っており、調達の指針とすることができる。なお、準拠登録及び相互接続確認

済みの製品には推奨マーク（図 3.3-1）の使用が許される。

＜＜準拠登録製品マーク＞＞ ＜＜準拠登録・相互接続確認製品マーク＞＞

「APPLIC推奨マーク指針」http://www.applic.or.jp/pf/mark/mark.pdfより引用 図 3.1-1 推奨マークのサンプル

なお、準拠登録製品一覧については、APPLIC のホームページを参照されたい。

21

http://www.applic.or.jp/pf/entry/index.html

3.1.3.地域情報プラットフォーム準拠登録製品の調達時の留意事項

地域情報プラットフォームは様々なシステム間の連携に必要な最低限のルールを定めたも

のであって、地域情報プラットフォームが調達時に必要な機能を全て規定しているわけでは

ない。 ただ単に準拠登録製品を調達すればそのまますぐに全ての連携ができるとは限らないため、

要求仕様を確認したうえで、調達仕様書には必要な項目を追加しなければならない。 なお、準拠登録製品のなかには、地域情報プラットフォームの仕様をパッケージシステム

の標準機能とせず、オプション扱いとしている製品もあるので注意が必要である。 以上のことから、地域情報プラットフォームを活用した調達を行う場合には、適宜最適な仕

様・方式を検討したうえで、必要に応じて実装に必要なものを規定し調達仕様へ盛り込むこと

が必要となる。また、地域情報プラットフォーム準拠製品を、標準技術の採用や業務間連携の

考慮された製品であることに対する評価とし、加点対象とするような調達方法も考えられる。

22

3.2.共通基盤

3.2.1.共通基盤について

電子政府・電子自治体の分野では共通基盤という言葉が一般的となってはいるものの、その

定義が確立されていないため、共通基盤という言葉の認識は、個々人や組織によって異なって

いる。本編でいう共通基盤とは、地方自治体や事業者ごとに異なるものではなく、共通的なも

のであることを指す。地方自治体や事業者間において共通言語として機能するものであり、業

務的・技術的な標準仕様によって構成されるものである。 これまでに地方自治体で取り組まれてきた“共通基盤”について、代表的なものを以下のと

おりに分類した（図 3.2-1）。地方自治体の調達においてはこのうち、プラットフォーム・アプ

ローチ型が主なものであると考えられる。

SOA

・ディレクトリ機能

・認証、認可機能

・システム連携機能

・その他

・標準化文書

・アプリケーション群

- 共通化技術標準、

- 統合連携ｼｽﾃﾑや各種共通API・サンプルプログラム

- 具体的なｼｽﾃﾑ構築方法

・サービス協調技術標準

- アーキテクチャ標準仕様

- ﾌﾟﾗｯﾄﾌｫｰﾑ通信標準仕様

・相互接続性標準

- ﾌﾟﾗｯﾄﾌｫｰﾑ準拠仕様

- 相互接続を確認する仕様

・共通機能や開発フレームワークの指針

・業務システムの設計、開発指針

・共通機能や業務システムに求められる遵守要件

・運用、保守のための指針

・その他、調達やプロジェクトマネジメント

に係るガイドラインなど

開発・技術標準定義型

プラットフォーム・アプローチ型共通機能個別調達型

開発フレームワーク整備型

・基本説明書

・標準仕様運用規則

・業務モデル標準

・ガイドライン（指針）

・共通基盤としての考え方や指針が整理共有できる

・「理想（成果物）」と「現実（調達や実装時）」の乖離

を防ぐための工夫が必要になる

・EAでいうTRM（ﾃｸﾆｶﾙﾘﾌｧﾚﾝｽﾓﾃﾞﾙ）を指向している

・業務システム開発を容易にする共通技術群である

・全体最適を指向したSOA部品の構築が必要となる

・業務共通で必要となる機能が抽出できる

・情報システム部門のガバナンスを確立させることが

重要となる

・業務システムは公開インターフェイスのみを定義する

・全体最適を指向したSOAの部品の定義がし易い

・ベンダーロックインの排除（業務カセッタブル性の確保）

やワンストップサービスの実現が目的である

【共通基盤の分類モデル】

図 3.2-1 共通基盤の分類モデル

3.2.2.地方自治体における共通基盤

大規模・中規模の地方自治体では、技術解説編「共通データベースの考え方」における共通

23

統合ＤＢ

住登外管理

国民健康保険

介護保険

児童手当

標準インター

フェース

業務ユニット群 住民基本台帳

データベースだけでなく、ESB（Enterprise Service Bus）、BPM（Business Process Management）などのミドルウェアを含み、認証機能や利用者管理などの共通機能や、共通基

盤と接続する個別業務アプリケーション同士が情報連携を行うための統合DBまでのサービス

基盤を総称し、共通基盤システムとして調達するケースがある。これは、地方自治体の各業務

は相互に関連しデータ連携を行う必要があり、情報の効率的な活用を行うために情報の統合管

理を行うことでシステム全体としての最適化を行うためである。

3.2.3.統合 DB

統合 DB は共通基盤システムでデータを一元的に利用（参照）する仕組みである。業務ユニ

ットとの連携を行うため、標準化された業務ユニットインタフェースと同様のインタフェース

を連携に必要な単位で実装しており、実装方式として公開用 DB 方式共通インタフェース方式

がある。業務ユニット同士が直接データのやり取りを行うのではなく、この統合 DB を介して

連携を行うことにより、業務ユニットは他の業務ユニットに影響を受けずに連携することがで

きる（図 3.2-2）。

図 3.2-2 統合DBの一元化

3.2.4.共通基盤の構成単位

共通基盤は自治体システムの基幹を成すものであるため、庁内システム全体のライフサイ

クルを考慮して調達することが望ましい。また、システム構成単位を目的に合わせてその範

囲を規定する必要がある。

（１）システム間通信機能

業務ユニットや BPM 機能、統合 DB 機能といった他のシステム構成単位の前提ソフトウ

ェアであるため、SOAP 仕様など標準技術を採用することを推奨する。

24

（２）統合 DB 機能

統合 DB は公開用 DB 方式か共通インタフェース方式、あるいはその併用かを人口規模、

データ量、業務ユニットの調達状況など総合的な判断をして規定する。また ESB 製品等を

活用することも検討されたい。

（３）共通 DB 機能

業務ユニットが共通で使用する全国市町村情報や全国銀行情報などの辞書データ、コード

辞書などを格納する共通 DB 機能 を規定する。

（４）BPM 機能

ワンストップサービスや総合窓口機能などでサービスを順次実行する。地域情報プラット

フォームではデファクトスタンダードとなっている WS‐BPEL を用いることを前提として

いる。

（５）共通機能

認証機能や利用者管理機能、時刻同期機能など、共通基盤に含める機能を規定する。

（６）宛名管理機能

宛名管理を個別業務ユニットとして調達するパターンと、共通基盤の機能として調達する

パターンが考えられる（図 3.2-3）。業務パッケージ製品として宛名システムを調達する場合

や、住民基本台帳ユニットや住登外ユニットの一部に宛名管理機能を有するような調達を行

う場合には個別業務ユニットの位置づけとなる。一方、宛名管理システム自身ではデータ作

成を行わず、元となる住民基本台帳ユニットと住登外ユニットのデータを横断的に管理する

機能としての調達を行う場合、全ての業務ユニットが使用することも考慮すれば共通機能で

ある。

図 3.2-3 宛名管理機能の調達パターン

統合ＤＢ

住民基本台帳

住登外管理

国民健康保険

介護保険

児童手当

宛名管理機能

統合ＤＢ

住民基本台帳

国民健康保険

介護保険

児童手当

25

（７）総合窓口機能

総合窓口機能も個別業務ユニットとして調達するパターンと、共通基盤の機能として調達

するパターンが考えられる。業務ユニットとして調達する場合には、業務ユニットとデータ

連携を行うために必要なインタフェース定義の整備とその問い合わせに対応する統合DB と

の連携が重要となる。

3.2.5.共通基盤の調達の留意事項

共通基盤システムは、全ての業務ユニットが使用するため、可能な限り標準技術を採用し、

ベンダロックインとならないよう特に留意する必要がある。また、使用される技術だけでなく

統合 DB のシステム間連携で使用する標準インタフェースは、業務ユニット導入ベンダに平等

に公開される必要があるため、調達時にユーザ自らが規定するか、基盤製品として調達する場

合においても公開を条件とすることが必要である。 また、共通機能を導入する場合においても同様に、ベンダロックインとならないよう留意す

る必要がある。認証機能などで使用するミドルウェアが業務ユニットに対し制限事項を発生さ

せることのないようにするとともに、宛名管理機能では、特に文字コードにベンダ独自文字体

系を使用しないよう留意すべきである。

26

3.3.業務パッケージの調達

3.3.1.自治体業務アプリケーションの特徴

地方自治体における調達は、住民基本台帳システムや税システムのように同じ法律に基づき

同じ業務を実施しているため、機能やサービスとして提供されるシステムではなく、パッケー

ジシステムの調達が主流である。ただし、自治体の規模により必要機能要件が異なるため大規

模自治体ではパッケージシステムをカスタマイズすることも行われる。近年では業務パッケー

ジシステムベンダも標準技術を業務パッケージシステムに採用することを重視してきている。

3.3.2.パッケージシステムの活用

業務パッケージシステムを調達する際は、カスタマイズを極力抑えることが望まれる。自

治体業務は法制度改正が頻繁に行われ、その都度システム改修が必要となる。独自開発によ

り構築されたシステムでは個々の地方自治体ごとにそれぞれシステム改修が必要となるが、

パッケージシステムでは修正モジュールとして統一的に提供されることから、改修費用と工

数削減が期待できる。

（１）パッケージシステム製品

調達する製品が、パッケージシステムであるかは提供ベンダの製品ラインナップで決まる

ため、製品としてどこまで標準で用意されているかはベンダにより異なる。例えば、パッケ

ージシステムでは基本機能のみサポートし、その他の機能を個々の地方自治体ごとに改めて

要件定義し、これをもとに構築するタイプもパッケージシステムと呼ぶ場合がある。この場

合には個々の地方自治体ごとの細やかな適用が可能である半面、構築部分が多いためその後

の改修作業も個別対応となることが多い。

（２）業務パッケージシステムと業務とのフィットアンドギャップ分析 要件定義を作成する際に、現行システムの機能を、その必要性を再評価せずに、安易に踏

襲したり、業務担当者の要望を単純に羅列したりすると、多くの場合、パッケージシステム

としての適用が非常に困難となってしまい、開発量も膨大なまま削減されない。

こういった事態を避けるためには、要件定義において、業務パッケージシステムと業務と

のフィットアンドギャップ分析を十分に行うことが必要である。全体アーキテクチャの策定

時、業者への見積もり依頼時、調達仕様作成時、設計時の全てにおいて、真に必要とされる

業務要件を、パッケージシステムを適用していかに合理的に実現するかという視点が不可欠

となる。

（３）運用保守

業務パッケージシステムベンダから提供されるシステム導入後の不具合対応や機能改善などを

27

行った修正モジュール等を、そのままシステムに上書きするような対応（オーバライト）は通常運用

保守に含めるが、法制度改正等による軽度、中度、重度のシステム改修をどこまで含めるか

については意見の分かれるところである。システムのライフサイクル中での法制度改正等に

よるシステム改修を全て含めると、システム改修規模がわからない状態での費用算定となる

ため保守料が高額となるほか、法改正等が契約期間中に発生しなかった場合においても費用

を払い続けなければならない。一方、制度改正等によるシステム改修を含めないこととする

と、その都度費用算定をして契約行為を行う必要がある。また、その場合においては業務パッ

ケージシステムベンダの随意契約となるため、適正な費用算定のための競争原理が働かない恐

れがある。

（４）業務パッケージシステム調達と役務との関係

システム構築は、設計、開発、テスト、移行の各詳細フェーズから構成され、運用･保守

へと続く。業務パッケージ調達ではこの開発作業は発生しないと思われがちであるが、要件

定義によりパッケージで提供されていない機能を新規に開発する場合や、業務パッケージシ

ステムを実際に使用可能とするための適用作業が別途役務として発生する場合が多い。その

ため、業務パッケージシステムにおいても役務調達を意識して調達することが必要となる。

なお役務についての技術参照モデルは「役務調達編 2.3.システム構築（設計・開発）」を参

照されたい。

3.3.3.カスタマイズの抑制

前述のとおり、地方自治体の業務の大部分はパッケージシステムで導入されている。パッケ

ージシステムは、事業者が提供する既製品であるため、個々の地方自治体ごとに業務システム

をカスタム開発・改修していた従来手法に比べると、時間や費用等のコスト縮減が簡便に実現

できる。例えば、全ての地方自治体が一斉に国の制度等への対応を求められる法制度改正時に

は、パッケージシステムのバージョンアップによって対応することができる。このように、パ

ッケージシステムによるコスト効果等を最大化するためには、一切のカスタマイズを実施しな

い、いわゆるノンカスタマイズで導入することが望ましい。

一方で、業務パッケージシステムベンダは、より多くの地方自治体から評価されるシステム

提供を目指しているが、現実的には、ノンカスタマイズのパッケージシステムが導入できる地

方自治体は少ない。それは、個々の地方自治体ごとに行政サービスに特色があること、人口や

面積等の規模、少子高齢の割合、産業構造等が多様であることから、情報システムに求められ

る業務要件、技術要件等が異なるためである。また、以下のいくつかの理由によってカスタマ

イズせざるを得ない状況になっているといえる。

（１）地方自治体により異なる業務要件への対応

少子化や高齢化が問題となっている地域においては、個々の地方自治体が独自に子育て支

援や教育サービス、介護や医療等に係る行政サービスを実施していることがある。これらに

対応するためには、パッケージシステムのカスタマイズが必要となる場合がある。また、総

28

合窓口やワンストップサービスを実施している等、自治体等を単位とした高付加価値サービ

スを提供しようとする場合も同様と考えられる。

（２）非定形的な業務、一時的に発生する業務等への対応

地方自治体における住民記録や税等の定形的な業務は、業務パッケージシステムベンダが

提供するパッケージシステムとして必要十分な機能が提供可能であると思われる。一方で、

「臨時福祉給付金・子育て世帯臨時特例給付金」や「被災証明／リ災証明の発行」、「住民調

査・アンケート」等、非定形的な業務または一時的に発生する業務は、パッケージシステム

として提供することは困難であると思われる。このような業務においては、新規システムの

導入やカスタマイズでの対応が必要となる場合がある。

（３）非機能要件や技術要件、業務要件等への対応

個々の地方自治体ごとに業務フローが異なり、パッケージシステムで実現できない処理が

必要となる場合があり、性能要件等も加えると、個別対応せざるを得ない場合がある。また、

個々の地方自治体で独自にセキュリティポリシーを定めてシステムを運用しているため、こ

れらのポリシーに合致するようカスタマイズ対応が必要な場合がある。

3.3.4.カスタマイズの抑制のための方策

パッケージシステムのカスタマイズは、地方自治体ごとに異なる地域性への対応や行政サー

ビスを提供していくために必要になることが多いことから、カスタマイズの抑制には限界があ

る。一方で、パッケージシステムのノンカスタマイズ利用は目指すべきものであるため、カス

タマイズの抑制は継続的な活動として実施していく必要がある。そこで、地方自治体がパッケ

ージシステムのカスタマイズ抑制を目指すためには、以下の方策が考えられる。

（１）業務を可能な限り標準化する 自治体業務においては以下について標準化されていないと思われる。 ・同一行政業務であっても手続きや運用が違う ・データ定義や項目が標準化されていない ・データベースのスキーマのほか、プロトコルなどの適用技術が標準化されていない

地方自治体においては、全国共通となる業務及びそれらに関連する各種法制度体系が存在

しているため、転入や出生等の各種異動処理や住民票等の各種証明書発行申請は、全国共通

で実施されている。一方で、これらの業務の運用方法等については、個々の地方自治体に任

されているため、結果として自治体の業務の多くが標準化されていない実態となっている。

例外的に標準化されている例としては、戸籍電算化業務がある。戸籍電算化業務では、「戸籍

手続オンラインシステムの構築のための標準仕様書」といった システム構築のための仕様書

が全国の地方自治体に配布されているため、どこの自治体においても標準的なパッケージシ

ステムの導入が可能となっている。このように全国統一の仕様書が作成されることは、標準

化の観点では有効であり、パッケージシステムの導入が容易となると考えられる。

29

（２）相互接続及び相互手続きのための共通仕様を整備

業務をまたぐ電算処理の相互接続及び相互手続きのための共通仕様がないと、業務間を連

携するためのカスタマイズが発生する。それを防ぐためには、地域情報プラットフォーム標

準仕様等のような共通仕様を採用していくことがカスタマイズの抑制に効果的であるといえ

る。 例えば、住民記録における新規転入を考えた場合、新たな住民データが住民記録システム

上で確定処理した後、税システムや福祉システムなどの関連業務システムへのデータ連携処

理がされるが、データ受け渡しに関する共通的な仕様がないと、連携を行うためのカスタマ

イズが必要となる。これらの処理は、パッケージシステムによるところが大きいため、処理

のタイミング、エラー処理、適用文字コード等が共通仕様として整備されることで、業務分

析や改修費用等を大幅軽減することが可能となる。

3.3.5.システム要件定義

開発型の調達では要件定義が作業フェーズに含まれ、要件定義作業も含めた契約となるが、

業務パッケージの調達の場合、予め発注者側で要件定義を提示し、それがパッケージシステ

ムに含まれるか否かにかかわらず、その要件を満たす条件で発注されることとなる。オープ

ンな標準のためには、要件定義を適切な粒度で提示することが必要であるが、例えば「戸籍

手続オンラインシステムの構築のための標準仕様書」など、公的機関による義務的に提示さ

れる標準仕様書が存在する場合はまれであり、多くは自治体自ら作成しなければならない。

そのため、地方自治体では従来詳細な要件定義を提示せず、「住民基本台帳システム一式が

動作すること」といった、いわゆる一式調達というものも行われてきた。ベンダは現場適用の

リスクを考慮するため割高となる傾向があるほか要件にどこまで含まれるかの範囲について、

契約後にトラブルになる場合がある。また、特定ベンダの作成した要件定義をそのまま流用し

て調達し、ベンダロックインとなる仕様のため適正な競争原理が働かない場合も見受けられる。

そうしたことを防ぐため、個々の地方自治体がそれぞれ先進事例や各種実証事業等の成果物を

参考に作成している程度に留まっている要件定義を、今後は標準化して整備していくことが重

要である。

なお、要件定義を適切に定義する手段としてRFI･RFPが有効である。調達予定の業務ユニッ

トの業務パッケージシステムを持つ複数のベンダに対しRFI･RFPを行い、想定している要件定

義がそれぞれのベンダが保有する業務パッケージシステムが満たすことができるか予め確認し、

必要に応じて加除・修正することにより、できるだけオープンな要件定義とすることができる。

場合によりRFI･RFPの段階で業務パッケージシステムにない機能であっても、他のベンダが持

つ有効な機能であれば、そのベンダが標準機能として業務パッケージシステム自体をレベルア

ップさせることも考えられる。

30

3.3.6.共通基盤への接続

個別業務パッケージの調達においても、全体最適化を意識してシステム間連携を前提とした調達

をすることが重要であり、共通基盤システムとの接続のための標準インタフェースを備えることを推奨

する（図 3.3-1）。そうすることで、共通基盤システムを介し、地方自治体内のシステム間連携を円滑に

行えるほか、番号制度で想定されているような自治体間の連携を行う場合にも有効であると思われ

る。

共通基盤システム 中間サーバ

他社システム 個別システム自己開発システム情報連携IFサーバ

給食費・保育・市営住宅など

情報連携基盤

他市 他県 他機関

住基システム

個別業務ユニット税システム 福祉システム

図 3.3-1 共通基盤システムを介した連携

公開用 DB 方式に接続する場合では、実データを共通基盤側でも保持するため、業務ユニッ

トに直接アクセスされることはなく他の業務ユニットを意識する必要はないが、共通インタフ

ェース方式の場合には、他の業務ユニットからの問い合わせが共通基盤を介して要求されるた

め、その負荷も考慮に入れたハードウェアやソフトウェアの最適化が必要となる。

3.3.7.業務パッケージシステム調達における文字情報

（１）文字情報の指定

文字情報は政府調達のシステムと違い、地方自治体の調達においては大きな意味を持つ。

それは政府調達のシステムは氏名などの文字は単に識別として判別できるものであれば良い

のに対し、地方自治体は戸籍法、戸籍法施行規則、住民基本台帳事務処理要領などにより、

31

戸籍に記載されている字形の正確な表記が要求されている。業務の目的が、個人の身分、居

所等を公証することであることも大きな違いである。そのため地方自治体で取り扱う文字情

報は文字図形としての厳密性が求められるため、調達時には明確に指定が必要である。

例えば、JIS X 0208 と指定しただけでは字形の相違を表現できないので、JIS X 0208:1990、UnicodeV2.3 のような指定が必要である。また、フォントによっても字形の違いがあるため、

フォントも考慮することが必要であるとともに、バージョンによっても字形の相違があるた

め、例えば、「JIS X 0213:2004、IPAmj 明朝フォントVer.003.01 をベースフォントとする」

などの表現となる。

（２）文字情報に関する留意事項

製品RFI･RFP は、単にUnicode のコードポイントを使用していることのみをもって、国

際標準規格でない独自の字形を使用しているにもかかわらず Unicode であるとしているも

のも見受けられる。また、導入する業務パッケージ自体は仕様を満たしていても、関連する

サブシステムに独自の文字体系を使用しているため、本来の Unicode の文字を使用できない

といったことも起こりうる（図 3.3-2）。特に住基システムは、全てのシステムの宛名情報の

元となるシステムであることとともに、自治体内のみならず自治体間連携も想定されている

ため、ベースフォントに独自文字体系を使用しないことを強く推奨する。

双方向連携

住基システムUnicode等+PUA

住基ネット連携サーバ

ベンダ独自文字住基ネット

住基ネット明朝

片方向連携

関連するサブシステムがベンダ独自文字の場合文字の体系が独自文字の仕様により制限される。

自動発行機システム

ベンダ独自文字

双方向連携

図 3.3-2 独自文字体系による制約例

3.3.8.業務パッケージシステム調達におけるデータ移行

業務パッケージシステム調達時には、円滑な切替えを行うために、データ移行について時期

と方法を明確にする必要がある。また、現行システムからのデータ移行はもちろんのこと、シ

ステムライフサイクル終了後のシステム更新時のデータ移行も考慮する必要がある。データ移

行は現行ベンダに有利になることが多くベンダロックとなることが想定されるため、オープン

な調達を行うためにはデータ変換作業が特定ベンダに有利になることがないよう配慮する必要

がある。

なお、データ移行の調達方式として以下のものが考えられる。

32

（１）受注者がデータ変換を行う方式

業務パッケージシステムの受注ベンダが、現行システムからのデータを変換する作業を含

める調達方式。現行システムのベンダは、現行システムを熟知しており、移行ツールが用意

されている場合もあり現行ベンダが有利となるため、発注者が現行システムのデータ仕様を

参加ベンダに等しく提供できることが必要である。また、現行ベンダが現行システムの仕様

の提供費用を要求する場合があることや、それを発注者が負担しなければならないデメリッ

トがある。それを回避するには、システム調達時に予め次回システム更新時のデータ抽出と

データ仕様の提供を行う契約とするなどの方法もある。

（２）発注者がデータ変換を行う方式

業務パッケージシステムの受注ベンダが要求するデータ移行レイアウトに合わせて、発注

者が現行システムからのデータを変換する作業を行う調達方式。発注者が現行ベンダにデー

タ変換作業を委託する場合もある。現行システムのベンダにかかわらず、入札参加ベンダに

平等な条件が提示できる反面、発注者の負担が大きくなるとともに、データ移行の主導権を

業務パッケージシステムの受注ベンダに与えるデメリットがある。受注ベンダのデータ仕様

に完全に合わせるのではなく、ある程度の変換作業も受注ベンダが行うことも含める（１）

と併用する方法もある。

（３）中間レイアウトを提示して行う方式

発注者が予めデータ移行のための中間レイアウトを提示し、その中間レイアウトからのデ

ータを変換する作業を含める調達方式。現行システムからのデータを中間レイアウトに変換

する作業と、中間レイアウトから新システムへ変換する作業が発生し、作業の不明確性によ

るリスク分が加味されやすいこと、また、変換プログラムはその都度作成し使い回しができ

ないため、変換プログラム開発の割り勘効果も期待できないことからデータ移行費用がかさ

むといった課題があったが、総務省が作成・公表している中間標準レイアウトを活用するこ

とで、それが解消される。中間標準レイアウトの活用により、現行システムのベンダと発注

者・受注ベンダとの調整作業が不要となり、また、作業工数の透明化が図られ、データ移行

費用の抑制効果が期待できる。

なお、中間標準レイアウトについては、総務省ホームページの自治体クラウドポータルサ

イトを参照されたい。

http://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/lg-cloud/02kiban07_03000024.html

（４）データ変換作業を別委託とする方式

現行システムからと調達した新システムへのデータ変換作業のみを別途委託する方式。自

治体業務パッケージシステムやベンダごとに異なる文字コードなど、現行システムと調達し

た新システム両方の仕様を熟知したベンダが必要である。データ移行仕様をユーザにではな

く他のベンダに知られることを理由に、現行システムのベンダや業務パッケージシステムの

受注ベンダが許諾しない場合も想定される。

33

3.3.9.データ形式の統一

多くの地方自治体では、職員が担当業務として必要な情報がどのようなものであるかは認識

していても、具体的にどういった形式で、どのデータベースやファイル等に格納されているか

を把握できていないことが多い。従って、これらの情報を分析したり、他の業務などに利活用

しようとすると、そのデータを管理している特定ベンダに依存してしまうことになる。このこ

とは、主体的に行政情報を管理・活用等すべき行政側で、大きな課題となっている。 そこで、特定ベンダに依存せず、自治体ごとの目指す姿を効果的・効率的に実現していくた

めには、データガバナンスが確立された環境の構築、すなわち、自治体が主体となり、住民情

報等も含む情報資産が管理できている状態の確立が必要となる。そのために最も重要となる課

題として、データ形式の統一が挙げられる。 電算化前は、情報資産は紙が原本であるため、情報資産を容易に把握できると伴に情報の管

理も職員が主体となって実施できていた。しかし、レガシーシステムからの脱却とともに、パ

ッケージシステムが主流のオープンシステムを採用することになってきた背景も一端となり、

データ形式の統一が必要となってきたのである。すなわち、特定ベンダのパッケージシステム

内にデータが格納されてしまうことによる、いわゆるデータのブラックボックス化である。こ

のことは、新旧システムを切り替える際に、旧システムのベンダに対してデータ移行費用を支

払わなければならなくなるなど、多くの自治体において大きな課題となっている。パッケージ

システムが業務パッケージシステムベンダの製品であるという位置づけから、データベースの

設計等を含む内部仕様がベンダの所有であり、ベンダのみが把握できるということが原因とな

っている。 この問題解決のためのデータ標準化の取り組みとしては、新旧システム間のデータ移行を標

準化することでデータ移行費用を縮減させることができる「中間標準レイアウト」、自治体内の

業務システム間連携するためのインタフェース等を標準仕様としてまとめた「地域情報プラッ

トフォーム」、そして前述の「文字情報基盤」等があり、それらを活用することが有効である。

また、更に「中間標準レイアウト」や「地域情報プラットフォーム」に加えて、これらの標準

仕様を拡張活用してきた成功事例の実績を付加することで、データ項目の網羅性を高めること

が有効になる。

34

3.4.クラウドサービスの調達

クラウドとは、一般的に「ネットワークを通じて、情報処理サービスを、必要に応じて提供／利用す

る」形の情報処理の仕組みであり、その存在が雲のなかにあるようなイメージであることからクラウドと

称されている。

3.4.1.地方自治体におけるクラウドの活用等

地方自治体におけるクラウドの活用等においては、SaaS、PaaS、IaaS 等のクラウドサービ

スに加え、ファシリテーションのみを提供するハウジングサービスや、プラットフォーム、業

務アプリケーション等が共同で利用可能な様々な形態が存在し、一般的なクラウドで要求され

る仮想化、一元管理、自動化、オンデマンド等の技術を前提としない場合もある。 以下に地方自治体におけるクラウドの活用等の代表的な形態を示す。

（１）クラウド型

SaaSやASPのようにパブリッククラウド、コミュニティクラウドとして提供される形態。

地方自治体では個人情報の取り扱い上の制約等から、利用できる業務システムが限られる場

合がある。 パブリッククラウド、コミュニティクラウドの詳細は「クラウドサービス編」を参照され

たい。

（２）ハウジング型 アプリケーションの共同利用を前提とせず、個々の地方自治体が所有する業務システムを

データセンターに設置し、データセンターのファシリティを共同利用、すなわちハウジング

サービスのみを利用する形態。仮想化等の技術も前提としない（図 3.4-1）。

Ａ自治体

データセンター

Ａ自治体システム（住民記録、税、福祉など）

業務ユニット

業務ユニット

業務ユニット

図 3.4-1 ハウジング型の例

なお、ハウジングについては「物品調達編 2.3.iDC・設備」を参照されたい。

35

（３）共同利用型

複数の地方自治体が共通的に利用する業務システムをデータセンターに置き、業務アプリ

ケーションを中心に、プラットフォーム、ファシリティ等を共同利用する形態。プラットフ

ォームを個々の地方自治体ごとに構築する、いわゆるオンプレミスの形態を含むところがク

ラウド型とは異なる（図 3.4-2）。

Ａ自治体

データセンター

Ａ自治体システム（住民記録、税、福祉など）

業務ユニット

業務ユニット

業務ユニット

B自治体B自治体システム（住民記録、税、福祉など）

業務ユニット

業務ユニット

業務ユニット

同システム

図 3.4-2 共同利用型の例

なお、総務省は、複数の地方自治体において主に基幹業務システムを自分たちの庁舎で保

有・管理することに代えて、外部のデータセンターに集約し、ネットワークを経由して共同

利用できるようにする形の取り組みへの支援を行っている。

3.4.2.地方自治体におけるクラウド調達の留意事項

クラウドの活用では、自庁内に資産を持たないメリット、共同利用による費用の削減効果等

が期待されるが、一方で、運用経費や分担負担の妥当性、共同利用に伴うセキュリティの 課題、

サービスの継続性、 ベンダ ロックインが容易になること等、留意事項も存在する。

（１）ノンカスタマイズ

クラウドの調達では、業務アプリケーション（パッケージシステム）のノンカスタマイズ

が前提となるため、可能な限り業務のやり方をシステムに合わせることが必要となる。また、

クラウド型やSaaSタイプの共同利用型を利用する場合には、全ての利用自治体が運用形態、

場合によっては制度もシステムに合わせることが必要となる。

36

（２）データ移行 クラウドの調達時には、個々の業務システムの開発が伴わないため、新システムの導入が

容易と誤解される場合があるが、データ移行については、従来と同様の作業が必要になり、

入念な計画、準備が必要となる。また、現在、使用中のクラウドから別のクラウドに変更す

る場合においても、同様な準備が必要となる。

（３）法改正等に伴う業務アプリケーションの改修 一般的なクラウドでは、システム改修が必要となった場合でも、サービスとして使用して

いるので改修費用は原則として発生しない。しかし、地方自治体におけるクラウドでは、法

改正等によりシステム改修が必要となった場合は、ハウジング型では従来と同様に改修費用

が発生する。また、共同利用型であってもオンプレミスな構築を行っている場合には改修費

用が発生する場合がある。

（４）ベンダロックイン

クラウドにおいては、業務システムの構造が従来の形態よりも、更にブラックボックス化

するため、ベンダロックインの容易化が想定される。これに対抗し競争環境を醸成するため

には、別のクラウドへの乗り換えが可能な状態を担保しておくべきである。例えば、データ

移行を容易にするため、中間標準レイアウトの活用等、予めデータのフォーマット提供と、

それに基づいた移行データの提供を契約に含めること等も有効である。

（５）セキュリティ対策

共同利用の場合、個人情報の取り扱いを中心に、各地方自治体のセキュリティポリシーと

クラウドの形態、サービス、セキュリティ対策等が衝突しないか、十分に確認することが必

要となる。

（６）クラウド事業者の撤退リスク

地方自治体の基幹業務は1日たりとも停止させることができない。また、クラウド事業者の

倒産、解散、ビジネス撤退等で、突然、サービスが停止される場合においても、クラウド事

業者等のデータセンターに蓄積された個人情報を含むデータを確実に移行、また消去できる

か、予め留意しておく必要がある。特に秘密保持契約を交わしていても、倒産により契約の

相手がいなくなることも想定しておくべきである。

（７）外字の削減

データ移行の際は、各地方自治体が独自に管理している外字の同定作業を行う必要があり、

多くの時間と労力が割かれている。総務省が実施した市区町村における外字の実態調査結果

を活用するなど、クラウド移行にあたり不要な外字を削減しておくことが必要である。

なお、市区町村における外字の実態調査結果については、総務省ホームページの自治体ク

ラウドポータルサイトを参照されたい。

37

http://www.soumu.go.jp/main_sosiki/jichi_gyousei/c-gyousei/lg-cloud/02kiban07_03000021.html

38

第 4 章 インフラ基盤統合化のポイント

4.1.サーバインフラの統合化

小規模地方自治体においては、近隣の団体と共同で SaaS 型の業務パッケージシステムを調

達する動きも出てきているが、中規模以上の地方自治体においては、業務やシステムの運用等

の違いにより、小規模地方自治体と共同で SaaS を利用することが難しい状況にある。しかし、

ここ数年の仮想化技術の進歩により、サーバ、ネットワーク、ストレージ等を統合した仮想化

基盤の共同利用は可能な状況になりつつある。このため、地方自治体におけるクラウドの活用

に向けて、小規模な地方自治体は SaaS の積極的な利用が求められ、中規模以上の地方自治体

はサーバインフラの統合が求められる。 これらを踏まえた、サーバインフラ統合化のポイントは次のとおり。 ・SaaS の積極的な利用 ・汎用型仮想化基盤の導入 ・仮想化基盤の所有から利用への転換 システム更改の際、複数の業務システムを搭載する仮想化基盤を調達し、サーバインフラを

統合化する地方自治体が増えているが、このことは、業務パッケージシステムの標準化が進ん

だことと仮想化技術が進歩したことにより、業務パッケージシステムとサーバインフラの分離

が促進されたことを意味している。 仮想化基盤の構築において、特定業務パッケージシステムとその専用型仮想化基盤をサイロ

的に複数構築するよりも、複数の業務パッケージシステムが動作可能な汎用型仮想化基盤を構

築することにより、サーバインフラ統合化におけるスケールメリットや運用性、可用性等が高

まる。このことにより、業務パッケージシステムベンダとサーバインフラは分離され、ベンダ

フリーのシステム構成となる。 仮想化基盤として、オンプレミスのプライベートクラウドを調達する選択肢もあるが、当面

の最終目標である SaaS 型クラウドへの中間目標として、サービスプロバイダが提供する IaaSや PaaS といったパブリッククラウドサービスの調達をも視野に入れる必要がある。

IaaSやPaaSを調達することにより、特定のサービスプロバイダへの依存度が低くなるため、

プライベートクラウドと比較し、より容易に SaaS 型クラウドへのシステム移行が可能になる。

この仮想化基盤の所有から利用への転換により、自庁への仮想化基盤の設置が不要になり、サ

ーバインフラの運用からも開放される。

39

プライベートクラウド

ハードウェア

ＯＳ

業務ユニット群

ＩａａＳ

ハードウェア

ＯＳ

業務ユニット群

ＰａａＳ

ハードウェア

ＯＳ

業務ユニット群

ＳａａＳ

ハードウェア

ＯＳ

業務ユニット群

【中間目標】 【最終目標】【現在位置】

サイロ型システム

汎用機システム

図 4.1-1 ＳａａＳへの段階的な移行例 仕様書の作成にあたっては、「クラウドサービス編」を参照されたい。

40

4.2.端末の共通化

情報システムの TCO の削減や執務空間の省スペース化を目指し、デファクトスタンダード

を採用し、一台で複数の業務システムの処理や OA 作業等が可能となるパソコンやプリンタ等

の端末を共通化する地方自治体が増えている。 サーバインフラの統合化に先立ち、端末の分野では業務パッケージシステムやサーバインフ

ラからの分離が進み、端末の共通化が進んでいる。 端末の更改の際は、情報セキュリティの確保、端末の運用・保守の軽減、情報システムの TCO

削減の観点から、仮想化技術を用いたデスクトップの仮想化やシンクライアントシステムの調

達も視野に入れる必要がある。 仕様書の作成にあたっては、「物品調達編 5.8.共通 PC・オフィスプリンタ」を参照されたい。

41

第 5 章 ＩＴ調達テクニカルノウハウ集

IT 調達の実態を把握するため、地方自治体に対して IT 調達の課題と解決策に関するアンケ

ート調査を実施し、約 30 団体から回答を得た。第 5 章ではこれをもとに、次の 3 つの課題認

識に沿って地方自治体の IT 調達における課題と解決策に関するテクニカルノウハウを示し、

より具体的に IT 活用が行えるようにすることを目指す。

＜地方自治体の IT 調達における 3 つの課題認識＞ 1.情報提供依頼（RFI）の実施 2.文字情報基盤の活用 3.IT ガバナンスの確立

5.1.情報提供依頼（ＲＦＩ）の実施

地方自治体の情報化はパッケージシステムに依存する部分が大きい。このため、提案依頼

（RFP）に先立つ情報収集の精度が、その後のシステム導入に非常に大きな影響を与えるため、

本課題を選定した。

5.1.1.課題認識

地方自治体の業務の大部分はパッケージシステムに支えられており、その調達は業務継続の

ためにも重要なイベントである。安定したシステムをできるだけ安価に導入するためには、RFIを実施し、システムの情報を十分に得ることが必要になる。この RFI の成否が、RFP やその

後のプロジェクトマネジメントに大きな影響を及ぼす。 また、パッケージシステム導入における懸念として、カスタマイズによるコスト増が挙げら

れる。着実に RFI を実施し、パッケージシステムと業務や既存情報システムとの適合性を評価

することにより、ノンカスタマイズあるいは小規模なカスタマイズにより導入できる可能性が

高まる。その結果として、ライフサイクルコストの抑制が期待できる。 ただし、RFI の結果、業務や既存情報システムにフィットするシステムが必ずしも安価にな

るとは限らないため、RFP を実施する際は、費用対効果のバランスを勘案する必要がある。

5.1.2.解決の方向性

アンケート調査の結果、パッケージシステムの導入の際、地方自治体とベンダの間での仕様

を巡るトラブルが後を絶たず、やむを得ずカスタマイズとなった、あるいは、導入後に実施し

ようとしていたことや前システムで実施していたことが実現できなかったという意見が多数あ

った。

42

パッケージシステム導入の際、仕様を巡るトラブルを回避するためには、RFI をシステム調

達の一部と位置づけ、事前に十分な情報を得ることが重要である。RFI を効果的かつ効率的に

実施するための方向性は次のとおり。

（１）コミュニケーションの強化 地方自治体の情報システム部門は、業務部門やベンダとの認識にそごが生じないよう、丁

寧なコミュニケーションを心がける必要がある。用語の定義や仕様の認識違いは後工程にな

ればなるほど、解決が困難になる。

（２）デモンストレーションの実施 RFI の一環として、ベンダにデモンストレーションを依頼し、実際に操作することで、シ

ステムに対する地方自治体側の理解を深める。

（３）業務及びシステムの可視化 RFI を実施する際の事前準備として、情報システム部門は既存情報システムの状況を、業

務部門は業務内容を可視化する必要がある。これらはRFI の際、パッケージシステムの適合

性の評価に役立つほか、業務やシステムを最適化する際にも利活用できる。

5.1.3.事例

事例１ ・地方自治体が提示した調達要件と、事業者決定後に要件定義をした際のベンダとの認識に食

い違いが出る。 ・システム構築中及び構築後において、仕様書記載事項を満たしているか否か、発注者と受注

者間で意見の相違が発生する。 解決策 ・RFI やRFP の際に、地方自治体は自団体固有の言い回しを使用しないように留意する。 ・地方自治体は仕様書について、ベンダからの質疑や提案等を勘案し、一般的で理解されやす

い表現にする。 ・地方自治体はRFI の一環として、ベンダにフィットアンドギャップ分析を目的としたデモン

ストレーションを依頼し、相互理解を図ったうえでRFP を実施する。 ・地方自治体側で第三者の中立的な有識者等と契約し、問題解決のための指導や助言を得られ

る仕組みを作る。 事例２ ・情報システム部門がカスタマイズを行わない方針を示しても、業務部門からカスタマイズ要

望が発生し、それが本当に必要なものか判断が難しい。 解決策 ・カスタマイズをしないことによる影響を、作業時間等として定量的に算出し、費用対効果を

43

勘案のうえカスタマイズの可否を判断する。 ・パッケージシステムごとにカスタマイズの有無が異なる場合があるので、RFI や RFP の段

階では要望事項として挙げておき、調達後にカスタマイズ対応可否の協議を行う。 ・RFI や RFP の際、次のカスタマイズの発生要因を留意することにより、カスタマイズを抑

制、あるいは、カスタマイズに備えることができる。

5.1.4.補足

【カスタマイズの発生要因の例】 （１）法解釈の違い ・法解釈が地方自治体ごとに違いがあり、課税計算の仕方などが各自治体で異なる

（２）制度（条例・要綱等）の違い ・地方自治体固有の制度や各自治体で独自のサービス提供をしているもの ・地方自治体が法の不足部分を補うものや法で方式を各自治体の選択制としているもの

（３）運用の違い ・地方自治体規模の違いによるチェックタイミングやチェック項目の差 ・小規模地方自治体はオンライン入力中心、大規模地方自治体はバッチ中心等の運用の差 ・受付業務や審査業務などを一体で行うか、別々に行うか等の組織体制の差

（４）操作性の向上 ・業務部門職員の主観的な判断 ・業務部門からの業務効率化のための画面展開や画面表示項目の要望

（５）システム間連携 ・連携先のシステムごとに技術要件や文字コード等が異なる

44

5.2.文字情報基盤の活用

文字情報がベンダロックインの一因となっていることは「2.2.文字情報基盤」のとおりであ

るが、これに取り組むために文字情報基盤の活用に関する事例が参考となるため、本課題を選

定した。

5.2.1.課題認識

実際の調達段階で文字情報に関する要件の示し方に留意することで、その後の開発・適用時

の文字情報の課題を軽減することができる。

5.2.2.解決の方向性

解決策の 1 つに文字情報基盤の活用が挙げられる。

5.2.3 事例

事例１ ・マルチベンダーで業務アプリケーションを導入している場合、業務システム間の文字コー

ドや外字の調整に手間取る。 解決策 ・マルチベンダーで調達する際、仕様書に文字コードや外字の取り扱いについて明記するこ

とは特に重要である。また、「文字コードの変換機能を実装する」、「各システム間で利用

する外字の対応表を作成し、各システム間で利用する外字を統一し共有する。」等の機能

を有した文字情報管理システムを導入することも有効である。その際に文字情報基盤をマ

スターとした管理を行うことを要件とすることで、標準的な文字情報管理システムの導入

が可能である。

事例２ ・汎用機を使用しているが、他ベンダの他業務システムとデータ連携を行う際の、外字の問

題は対応が難しい。また汎用機のコードと文字フォントのマッピングテーブルの提供が受

けられない。 解決策 ・マッピングテーブル自体はベンダの著作物であることから許可なく広く一般に公開するこ

とはできないが、ユーザとして業務上必要なことであるため、ユーザはベンダに対してマ

ッピングテーブルを知ることを含めて使用許諾を受けていると解される。また、汎用機で

あっても文字情報基盤との同定テーブルを保持していくことにより、様々な文字情報の交

45

換が可能となるため、そのような標準的な文字情報管理システムの導入は有効である。

5.2.4.補足

文字情報基盤漢字は JIS 第 1～第 4 水準の範囲においてMS 明朝等の一般的な文字フォント

と字形の差異はなく、見た目上の違いはあってもデザイン上の差（包摂される）に相当し、導

入にあたって「文字グリフデザインが変わる」ということはない。文字包摂基準については、

“常用漢字表（附）「字体についての解説」”及び“外字の実態調査に係る調査報告書等（総務

省,2012 年 3 月）の包摂基準書”（http://www.soumu.go.jp/main_content/000157024.pdf）を

参照されたい。 ※自治体外字の実態調査に係る調査報告書等の包摂基準書における「字形一致」と「デザイ

ン差」に相当するものが「包摂される」ものとする。 調達仕様書に文字情報の指定を行う場合の留意点については 3.3.7.に記載したが、具体的な

文字情報の要件例を以下に示す。

【文字情報管理システムの調達の場合】 ・既存の内字・外字と外部システムの文字の同定を行い最も近い文字との変換ができること。 ・JIS X 0213:2004 及び住基ネット統一文字、文字情報基盤文字セットが扱え、外部システ

ムの文字コードとして入国管理局在留カード等に係る漢字氏名の表記等に関する告示（平

成 23 年法務省告示第 582 号）文字、後期高齢者医療広域連合会文字、国民健康保険団体

連合会文字、JIS X 0213:2012 への縮退変換、戸籍統一文字等の相互の変換テーブルの管

理ができること。 ・文字検索時に文字情報基盤の属性情報が利用できること。 ・文字情報基盤の文字セットを利用することで外字作成の負担が軽減されること。

【業務システムに文字情報を指定する場合】 利用したいパッケージによってサロゲートペアに対応している場合と対応していない場合や、

利用できる文字フォントが固定している場合などがあるので、事前に調査したうえで下記のケ

ース 1 から 3 のどれかを選択する。

ケース 1：サロゲートペアまで許容し、文字情報基盤の文字を全て使用したい場合 ・ベースフォントとして IPAmj 明朝フォント、文字情報一覧表が利用可能であること。 ・外部システムとのインタフェースとして文字情報技術促進協議会作成の暫定私用コードが

利用可能であること。

ケース 2：内字としてはサロゲートペアまで許容せず、文字情報基盤の 16 ビットの範囲のみ利

用する場合（内字以外は基本多言語面（BMP 面）のPUA の外字として扱う） ・ベースフォントとして IPAmj 明朝フォントが使用可能であること。

46

・ただし、ベースフォントの範囲はサロゲートペアや IVS を含まない 16 ビットの範囲とし、

入力抑制できるようにすること。 ※なお、外字は基本多言語面（BMP 面）のPUA に割り当てる。

ケース 3：独自文字を許容するが、文字情報基盤を介すことでロックインを解消したい場合 ・システムで使用する文字情報は文字情報基盤と相互に変換可能であること。 ・またデータ移行時は文字情報基盤を鏡として利用できること。 なお、外部システムとの連携などで、文字情報に文字情報基盤を指定する場合、文字情報基

盤以外の文字について留意が必要である。具体的には、データ連携の際は文字情報基盤と同定

された情報をもとにデータ連携を行うこととなるが、文字情報基盤に同定されなかった文字に

ついては、そのまま流通（データ連携）させず、代替可な文字が存在する場合は文字情報基盤

漢字に代替割り当て、代替割り当て不可能な文字は共通代替文字（“●”など）に置換するなど

して、文字情報基盤にない文字の流通を極力控える運用が望ましい。 ※代替割り当てについては、「外字の実態調査に係る調査報告書等」の「包摂基準書」におけ

る「類似文字」の定義を参照されたい ※外字の実態調査に係る調査報告書等において「同定不可」とされた文字が共通代替文字

（“●”など）に置換される文字となる。

47

5.3.IT ガバナンスの確立

電子行政サービスの推進のためには、全庁的な観点で情報システム導入の目的・必要性を明

らかにし、IT 戦略を策定するとともに実現方法を確立、常にフィードバックしながら目指すべ

き方向へとコントロールする組織的能力が自治体に備わっていないと、情報化計画を策定した

としてもその遂行が困難となってしまうため、本課題を選定した。

5.3.1.課題認識

行政においては、電子行政サービスに止めることなく、住民の利用者視点を取り入れた ITガバナンスを確立することで、はじめて、住民サービスの向上も視野に入れた電子行政サービ

スが構成される。

5.3.2.解決の方向性

地方自治体においては、首長や情報部門のリーダーシップが働き易い場合には、IT ガバナン

スが確立され全体最適化等のメリットを享受することができると考えられる。すなわち、地方

自治体においては、トップマネジメントが全庁的な業務・システム最適化などの全体最適化に

直結することとなる。そのためには全体最適化のためのガバナンスを確立することが重要とな

る。そしてガバナンスを確立することにより、「業務に関連する作業が整理される環境」、「組織

や職員・職務に応じた作業を適切に遂行できる環境」、「業務プロセスを可視化・評価・改善で

きる環境」といった環境整備を行うことができるようになると考えられる。

5.3.3.事例

事例１：全体最適化されていないシステムの予算要求及び予算執行（システム構築）が情報部

門の関与無く成されている。 事例２：情報部門の権限が弱くガバナンスが効きにくい。権限を持つ企画部門や財政部門も IT

の内容になると得意分野ではないケースもあり、原課の言いなりになったり、行き過

ぎたコストカットとなる恐れがある。結果的にはそれを運用する原課にしわ寄せがい

くことになる。 解決策：全庁的な意思決定機関において、全体最適化のコンセンサスを取り、場合により組織

改正などの推進体制を作ることが必要である。例えば、情報関係予算は一元化するな

ど、全庁的な横串の通ったシステム構築のできる環境づくりが重要である。

48