地域情報プラットフォームガイドライン

地域情報プラットフォームガイドライン（第２章）

一般財団法人全国地域情報化推進協会

地域情報プラットフォームガイドライン

地域情報プラットフォームガイドライン第 2 章

項

版数

1

2014.3.11

修正内容
表紙及びヘッダーのバージョン記載を削
除

改版履歴

備考
版数表記を、バージョン標記から修正
日標記に変更内容の修正は行っていないため、版数の変更はなし地域情報プラットフォームガイドライン

目次
２．調達仕様 ........................................................................... 3
２．１ 地域情報プラットフォームの調達について .................................................................................... 3
２．２ サービス基盤の調達 .......................................................................................................................... 12
２．３ プラットフォーム仕様準拠業務ユニットの調達 .......................................................................... 14
２．４ 導入体制.............................................................................................................................................. 21
２．５ 移行計画.............................................................................................................................................. 27

地域情報プラットフォームガイドライン

２．調達仕様２．１

地域情報プラットフォームの調達について

２．１．１ 地域情報プラットフォームのシステム構成(1)地域情報プラットフォームの全体アーキテクチャ
地域情報 PF を構成するシステム構成単位について説明する。下図は、地域情報 PF の論理的なシステ
ム全体アーキテクチャである。 複数のシステム構成単位がネットワークで接続し、PF 通信機能（プラットフォーム通信機能）で連携する構成である。なお、地域情報 PF の各導入パターンでの、具体的なシステム構成は異なる。

利用者(住民)⑥ フロント系業務ユニット

PF通信機能自治体ポータル／申請

WSDL① ＰＦ通信機能
ＰＦ通信機能業務ユニット

ＰＦ通信機能① ＰＦ通信機能③ BPM機能① ＰＦ通信機能
ＰＦ通信機能業務
ｻｰﾋﾞｽ

ＰＦ通信機能① ＰＦ通信機能
利用

提供

業務
ｻｰﾋﾞｽ

②
統合DB機能⑤
利用者（職員）①

共通系業務ユニット

ＰＦ通信機能ＰＦ通信機能

業務
ｻｰﾋﾞｽ

業務
ｻｰﾋﾞｽ

⑤
バック系業務ユニット

利用者（職員）④ PF共通機能

図２．１．１

地域情報 PF の全体アーキテクチャ(2)地域情報プラットフォームのシステム構成単位
地域情報 PF を構成するシステム構成単位を下表に示す。

表２．１．１
区分
サービス基盤

業務ユニットシステム構成単位
名称①

PF 通信機能②

統合 DB 機能③

BPM 機能④

PF 共通機能⑤

業務ユニット（共通系、バック系）⑥

業務ユニット（フロント系（ポータル、総合窓口※等）※住民サービス向上の観点から各種行政サービスを一個所で受けられる窓口のことをいう－ 3 －地域情報プラットフォームガイドライン

地域情報 PF を構成するシステム構成単位について以下に解説する。
①PF 通信機能
PF 通信機能は、国際標準 SOAP (Simple Object Access Protocol) 仕様に基づくサービス通信機能であり、セキュリティや高信頼性通信機能等がオプションで選択できる。PF 通信機能は、業務ユニットや
BPM 機能、統合 DB 機能といった他のシステム構成単位の前提ソフトウェアとなり、PF 通信機能単独でシステム構成単位とはならない。
②統合 DB 機能
業務ユニット間で、データを一元的に利用（参照）する仕組みである。SOAP のサービス呼び出しより情報を提供するため PF 通信機能を前提として持つ。また、業務ユニットとの連携を行うため、標準化された業務ユニットインタフェースと同様のインタフェースを連携に必要な単位で実装している。実装方
式として【公開用 DB 方式】と【共通インタフェース方式】がある。統合 DB 機能は、オプションである（統合 DB 機能は、業務ユニット間のデータ連携の際に、性能、その他の要件から柔軟にデータ交換を行う時に必要に応じて採用を検討するオプション機能である）。
③BPM 機能
ビジネスプロセス(BP)の実行を管理するシステム。国際標準 WS-BPEL(Web Services Business Process
Execution Language Version 2.0)に基づく BP 定義に基づき、業務ユニットが提供するサービスインタ
フェースを呼び出し、ビジネスプロセスを実行する。また、BP 実行の依頼元となる業務ユニットから呼び出される業務サービスインタフェースを持つ。
システム構成上、サービス通信を実施するため PF 通信機能を前提として持つ。BPM 機能は、ワンストッ
プサービス等でサービスを順次実行する際に利用するオプションである。
④PF 共通機能
PF 共通機能（プラットフォーム共通機能）としては時刻同期機能がある。なお、サイト間で使用する
PF 共通機能の各機能（モニタリング機能、サービスの認証認可機能、ユーティリティ機能）は、第 3 章の技術解説にて述べる。PF 共通機能は、オプションである。
⑤業務ユニット（共通系、バック系）
独立して特定の業務を処理するユニットである。PF サービス通信を実施するため PF 通信機能を前提として持つ。他の業務ユニットや BPM 機能から呼び出される業務ユニットインタフェース（詳細は、自治体業務アプリケーションユニット標準仕様 【インタフェース一覧】を参照）を持つ。なお、業務ユニッ
トが BPM 機能から呼び出される業務サービスインタフェースを持つのは、BPM 機能で連携するワンストッ
プサービスを実現する時のみである。
⑥業務ユニット（フロント系（ポータル、総合窓口等）
利用者（住民）や外部機関からの申請やサービスを受け付ける業務ユニットで、共通系やバック系の業務ユニットや BPM 機能を呼び出し、処理結果を利用者（住民）や外部機関に提示する。
PF サービス通信を実施するため PF 通信機能を前提として持つ。

(3)システム構成単位となる PF 準拠製品について
システム構成単位となる PF 準拠製品は下記が想定される。なお、PF 準拠製品とは、ベンダの提供する－ 4 －地域情報プラットフォームガイドライン

製品（サービス基盤製品、業務ユニット製品）が、地域情報プラットフォームの標準仕様に準拠してい
る確認がなされた製品のことである。これらの製品は、OS やミドルウェア、アプリケーションなど複数の製品によりシステム構成単位を実現されることもあり、ベンダの製品提供形態に依存する。PF 準拠製品の詳細は、地域情報プラットフォーム準拠確認及び相互接続確認仕様を参照。
① 自治体業務アプリケーションユニット製品（自治体業務ユニットの何れかを実装した製品）② GIS ユニット製品③ 防災業務ユニット製品④ サービス基盤製品（PF 通信製品、BPM 製品、統合 DB 製品）⑤ 教育情報アプリケーションユニット製品
・業務ユニット
・GISユニット
・防災業務
ユニットのユニット系
製品

全て同一提供者（PF通信内部実装型）

全て同一提供者（製品分離型）

X社がY社を前提
ソフトウェアとして申請

A社業務処理（ｻｰﾋﾞｽIF 処理）（PF通信処理）A社業務処理（ｻｰﾋﾞｽIF 処理）

X社業務処理（ｻｰﾋﾞｽIF 処理）

A社PF通信機能

Y社PF通信機能

全て同一提供者

全て同一提供者

A社 PF通信機能（含、ミドルウェア範囲）

サービス
基盤製品

X社がY社、Z社を前提
ソフトウェアとして申請
Z社ｱﾀﾞ
ﾌﾟﾀ

X社業務
処理

Y社PF通信機能

Z社アダプタにより、
業務ユニットｻｰﾋﾞｽIF
処理を実現

全て同一提供者

全て同一提供者

A社 BP
処理機能

A社統合DB(公開用DB方式)処理機能

A社統合DB(共通IF方式)処理機能

A社 PF通信機能

A社PF通信機能

A社PF通信機能

PF通信製品

統合DB製品(公開用DB方式) 統合DB製品(共通IF方式)

BPM製品

X社がY社を前提
ソフトウェアとして申請
X社サービス基盤
製品処理機能Y社PF通信機能
BPM製品、統合DB製品（公開用DB、共通IF）

図２．１．２システム構成単位となる PF 準拠製品の構成

下図に、自治体内システムにおいて地域情報プラットフォームを実装した例を示す。

利用者端末（住民）

インターネット
業務ユニットサーバ(フロント系)
ポータル
ポータル// 電子申請
電子申請

業務ユニットサーバ
(住基)
住基
住基AP
(シミュレータ)

業務ユニットサーバ(国保)

業務ユニットサーバ
(児童)

国保
国保AP
(シミュレータ)

児童
児童AP(シミュレータ)

WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能WebサーバWebサーバPF通信機能

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

APサーバ
APサーバ

DBサーバ
DBサーバ

BPM機能
BPMサーバ

統合DB機能BPMサーバ

DB
サーバ
Webサーバ

利用者端末（職員）

図２．１．３

APサーバ
APサーバ

DB
サーバ
WebサーバPF通信機能BPM機能（オプション）

APサーバ
APサーバ

統合DB機能（オプション）

自治体内システムの実装例－ 5 －PF通信機能地域情報プラットフォームガイドライン(4) 地域情報プラットフォームのシステム調達構成パターン
地域情報プラットフォームのシステム構成パターンは、8 パターンに分類される。下表に地域情報 PFのシステム構成パターンの一覧を示す。このように、地域情報プラットフォームで定義されている機能は、必要に応じて組み合わせて使用することができる。
なお、PF 通信機能はシステムの構成単位（業務ユニット、統合 DB 機能、BPM 機能等）に包含されていることが前提である。

表２．１．２

地域情報プラットフォームのシステム調達構成パターン一覧

調達構成

統合ＤＢ機能の使用

パターン

目的

パターン 1

業務ユニット間での《1-1》業務ユニット連携

データ交換、サービス

（直接）

なし

あり
《1-2》業務ユニット連携（統合 DB 機能）

連携を行う
パターン 2

ワンストップサービス《2-1》ワンストップ連携を行う（業務ユニット《2-2》ワンストップ連携（BPM）（BPM、統合 DB 機能）

間連携）
パターン 3フロント系業務ユニッ《3-1》電子申請/総合窓口連携

トと連携したワンス《3-2》電子申請/総合窓口連（BPM）

携（BPM、統合 DB 機

トップサービスを行う

能）（業務ユニット間連携）パターン 4

ワンストップサービス《4-1》照会・検索型連携《4-2》照会・検索型連携（統を行う（複数の業務ユ合 DB 機能）

ニットへの並行問い合
わせ）以下に地域情報 PF のシステム構成をパターン別に示す。
①パターン 1
《1-1》業務ユニット連携（直接）業務ユニット間のデータ交換や、業務サービス連携を実現するシステム構成である。
《1-2》業務ユニット連携（統合ＤＢ機能）
業務ユニット間のデータ交換や、業務サービス連携を統合 DB 機能を仲介して実現するシステム構成である。

業務ユニットA

業務ユニットD

業務ユニットA

業務ユニットB

業務ユニットE

業務ユニットB

業務ユニットC

業務ユニットF

業務ユニットC

図２．１．４

業務ユニットD
統合DB
機能

業務ユニットE
業務ユニットF

業務ユニット連携（直接、統合 DB 機能）のシステム構成－ 6 －地域情報プラットフォームガイドライン②パターン 2
《2-1》ワンストップ連携（BPM）
自治体内ワンストップサービスを実現する、ビジネスプロセス管理機能による業務ユニット間連携プ
ロセス連携のシステム構成である。
《2-2》ワンストップ連携（BPM、統合 DB 機能）
上記構成において、業務間データ交換を統合 DB 機能により実現する構成である。

《2-2》

《2-1》

BPM機能

BPM機能

業務ユニットB

業務ユニットA

図２．１．５

業務ユニットA

統合DB
機能

業務ユニットB

ワンストップ連携（BPM）のシステム構成③パターン 3
《3-1》電子申請/総合窓口連携（BPM）のシステム構成
自治体内ワンストップサービスを実現する、ビジネスプロセス管理機能による業務ユニット間連携プ
ロセス連携のシステム構成を下図に示す。フロント系業務ユニットとバック系業務ユニットを、BPM のビ
ジネスプロセスにより連携するシステム構成である。
《3-2》電子申請/総合窓口連携（BPM、統合 DB 機能）のシステム構成
上記構成において、業務間データ交換を統合 DB 機能により実現する構成である。

《3-1 》《3-2 》

フロント系業務ユニット

フロント系業務ユニット

BPM機能

業務ユニットA

図２．１．６

BPM機能

業務ユニットB

業務ユニットA

統合DB
機能

電子申請/総合窓口連携のシステム構成－ 7 －業務ユニットB

地域情報プラットフォームガイドライン④パターン 4
《4-1》照会・検索型連携のシステム構成
自治体内ワンストップサービスを実現する、他のシステム構成を下図に示す。フロント系業務ユニッ
トから、複数のバック系業務ユニットへの並行問合せを行い連携するシステム構成である。複数業務ユニットへの状況の並行問合せ等で使用される。
バック系業務ユニットに並行問い合わせする構成である。
《4-2》照会・検索型連携（統合 DB 機能）のシステム構成
上記構成において、統合 DB 機能へも問い合わせする構成である。

《4-1》

《4-2》

フロント系業務ユニット

業務ユニットA

フロント系業務ユニット

業務ユニットB

図２．１．７

業務ユニットA

統合DB
機能

照会・検索型連携のシステム構成－ 8 －業務ユニットB

地域情報プラットフォームガイドライン

２．１．２

オプション機能一覧

地域情報プラットフォームで規定される各機能について、自治体内とサイト間でのオプションの一覧と選択基準を示す。なお、サイト間（自治体間、官民連携）でオプション機能を選択して通信する場合
は、管理主体同士による事前調整を行う必要がある。

表２．１．３ オプション選択一覧表№

機能○:オプション選択可―:該当なし

サイト内

サイト間

仕様

1

OS

Windows,UNIX,Linux

必須

必須

2

インターネットプロトコル

IPv4

必須

必須

3

通信路セキュリティ

SSL3.0,TLS1.0

○

必須

4

転送プロトコルHTTP1.1

必須

必須

5

基本メッセージ

SOAP1.1

必須

必須

6

高信頼性メッセージング

WS-R1.1,WS-RM1.1

○

○

7

添付付メッセージング

本文内埋め込み、SｗA

○

○

8

BPM 機能WS-BPEL2.0

○

○

9

インタフェース定義

WSDL1.1

必須

必須

10

ビジネス文書定義

XML Schema1.0

必須

必須

11

署名認証

XML Signature 等

―

○

12

職責認証

XML Signature 等

○(※１)

○

13

サービス認証

WS-Security1.1,SAML2.0 等

○(※２)

○

14

サービス認可権限基盤技術

○(※２)

○

15

プライバシ情報公開

P3P,プライバシ情報公開技術

―

○

16

サービス監査証跡

サービス監査証跡取得技術

―

○

17

Web サービス情報の登録と検索

UDDI2.0 など

―

○

18

モニタリング機能

モニタリング技術

○(※２)

○

19

サービス＆BP 定義手法

デザインパターン定義等

○

○

20

統合 DB 機能公開 DB 方式、共通 I/F 方式○―※１ 自治体内で職責認証を行う場合は選択可。
※２ 自治体内での当該機能を使用する場合においては、仕様で示された技術を使用せず、既存技術等を利用することも可とする。
【オプション機能の用途と選択基準】
以下に、オプション機能の用途と選択基準を示す。
なお、表２．１．３のオプション機能には、PF 共通機能が含まれている（No.13、No.14、No.15、No.16、
No.17、No.18、No.19）。これらの PF 共通機能について、技術仕様を明確にした段階であり、各ベンダが製品を提供するためには、今後時間を要することが想定される。従って現段階においては、調達の対象外とする。それを踏まえた上で個別導入を検討する場合は、ベンダの製品提供状況を確認し、慎重な導入検討を行う必要がある。

－ 9 －

地域情報プラットフォームガイドライン

No.3．通信路セキュリティ
通信相手（サイト/マシン）の認証に使用する。通信路上の 2 点間の秘匿性確保の目的でも使用する。
HTTP Basic 認証におけるパスワード方式に比べセキュリティ強度が強い。
No.6．高信頼性メッセージング
SOAP 通信処理の信頼性を向上したい時に使用する。メッセージの送達保障（失敗時再送）、重複排除、
順序性保障の機能を持つので、SOAP 通信にメッセージが紛失したり、重複して到着してしまうことを防ぐことができ通信の信頼性を高められる。
No.7．添付付メッセージング
業務ユニット間で「添付書類」を送受信する時に使用する。事前に業務ユニット間で添付書類の送受信方式を決めておけば、確実に添付書類メッセージを処理することができる。
No.8．BPM 機能
ワンストップサービス等、一連の業務処理を複数の業務ユニットで連携して行う時に必要となる。ビ
ジネスプロセスの実行・管理を自動化できる利点がある。
No.11．署名認証
電子申請等の文書（デジタル）の正当性の保証を高める時に使用する。
No.12．職責認証
自治体が発行する公文書（デジタル）の正当性の保証を高める時に使用する。
No.13.サービス認証
ID 体系の異なるサイト（サーバ）間で、シングルサインオンを実現するときに使用する。名前寄せを防止できる等、セキュリティ強度が高い。
No.14．サービス認可
権限管理を別サーバで一元管理し、各業務サーバのアクセス制御を行う時に使用する。権限管理を集中化させることにより、各業務ユニットでのアクセス制御の設計を共通化することができる。
No.15．プライバシ情報公開
サイトを跨って個人情報を交換する場合に使用する。利用者が許諾した情報だけを管理することができるので、利用者のプライバシの保護に役立つ。
No.16.サービス監査証跡
サイトを跨る処理で証拠保全が必要なときに使用する。サイトを跨る処理の効率的な監査や、情報漏
えい時の原因の特定に役立つ。
No.17．Web サービス情報の登録と検索
複数のサイト間で、情報の一元管理（登録、更新、削除、検索、参照）を行う時に使用する。サイト
間で情報を迅速で安全に管理することができる。

－ 10 －

地域情報プラットフォームガイドライン

No.18.モニタリング機能
サイト(サーバ)を跨る処理をする時に、他サイト（サーバ）に依頼した処理の状況を確認したい時に使用する。トラブルの事前回避やシステム改善・サービス改善を策定する際に有効な情報を収集することができる。
No.19. サービス＆BP 定義手法
APPLIC（財団法人全国地域情報化推進協会）で策定される各種 XML 標準定義の設計手法を明確にしたい時に使用する。標準仕様を取り込み独自に拡張するときに役立つ。
No.20．統合 DB 機能
業務ユニット間で必要となるデータを統合的に管理する時に使用する。業務ユニット間でのデータ連携を効率的に行うことができる。統合 DB 機能の詳細は第 3 章 3.2 を参照。

－ 11 －

地域情報プラットフォームガイドライン

２．２

サービス基盤の調達

地域情報プラットフォームのサービス基盤とは、以下の 4 機能である。
機能単位もしくは、機能の組み合わせで調達を行うが、実装形態は規定されていないため、複数の製品提供者から情報を収集し、調達仕様を決めることを推奨する。

２．２．１

プラットフォーム通信機能

プラットフォーム通信機能（PF 通信機能）は、業務ユニットおよび業務サービスが標準インタフェー
スや標準規約（セキュリティ、メッセージ等）に準拠して連携を実現するための機能群である。以下の機能を実現できること。
(1) HTTP 通信（IPv4、HTTP1.1）(2) 通信セキュリティ（通信路暗号 SSL3.0(TLS1.0)、サーバ認証）(3) 通信セキュリティ（通信路認証 SSL3.0(TLS1.0)、クライアント認証）(4) 通信セキュリティ（通信路認証 HTTP のベーシック認証）(5) SOAP 通信（SOAP1.1、document/literal、WS-I ベーシックプロファイル 1.0）
(6) 高信頼性通信（WS-Reliability1.1、WS-ReliableMessaging1.1）(7) 高信頼通信（MEP 方式）(8) メッセージの XML 定義仕様（XML Schema

1.0、PF 仕様の XML プロファイル）(9) サービス I/F の XML 定義仕様（WSDL1.1、PF 仕様の XML プロファイル）

２．２．２

統合 DB 機能統合 DB 機能とは、業務ユニット間で必要となるデータを統一的に管理することで、業務ユニット間のデータ交換を効率的に実現する機能である。したがって、業務ユニット同士がデータ交換（情報を共有
または連携）できるための機能を有する必要がある。
統合 DB 機能の実装方式は次の 2 種類から選定することができる。
(1) 公開 DB 方式（業務ユニット相当の SOAP インタフェース）(2) 共通インタフェース方式
また、統合 DB 機能は、業務ユニットが利用する時の利用側インタフェースとして必要な単位で自治体
業務アプリケーションユニット標準仕様に準拠した SOAP の業務ユニットインタフェースを有するものとする。オプションとして SQL インタフェースの採用も可能である。

２．２．３

ビジネスプロセス管理機能

ビジネスプロセス管理機能（BPM 機能）は、自治体の業務サービスおよび自治体間、官民連携業務サー
ビスの実行を制御する機能であり、サービスを順番に連携させるタイプのワンストップサービスに利用できる。
業務サービスインタフェースを組み合わせてビジネスプロセスを組上げ、ワンストップサービスや高付加価値サービスを構築することができる。このとき、BPM 機能は、プラットフォーム通信標準仕様に従う機能内容でなければならない。また、プロセス定義のためのスクリプトは、プラットフォーム通信標
準仕様に従うものでなければならない。以下の機能を実現できること。
ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：基本アクティビティ（receive、reply、
invoke）対応）ビジネスプロセス－ 12 －

地域情報プラットフォームガイドライン(1) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：構造化アクティビティ（sequence、
flow、if、while）対応）(2) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：変数処理（assign、XPath1.0 利用可能）対応）(3) ビジネスプロセスの XML 定義仕様（PF 仕様指定の WS-BPEL2.0：エラーハンドリング（fault、
throw）
対応）

２．２．４

プラットフォーム共通機能

プラットフォーム共通機能は、サイト内や、さらに、異なるサイトに跨った業務サービスを連携する
際に必要となる共通的な機能群である。PF 共通機能について、技術仕様を明確にした段階であり、各ベンダが製品を提供するためには、今後時間を要することが想定される。従って現段階においては、(1)時
刻同期機能以外の PF 共通機能は、調達の対象外とし、第 3 章技術解説で機能および利用方法を紹介するという扱いとする。
(1) 時刻同期機能
地域情報プラットフォーム内で動作するサーバ等の各マシン間で時刻を一致させる機能である。時刻同期の方法として以下のいずれかの方法をとること。
ａ．外部 NTP(RFC1305 準拠)サーバを用意する（インターネット経由で接続）。自治体等の地域情報 PFのサイト毎に決定する。インターネット経由で正確な時刻に基づく NTP サーバとしては、例えば、
NICT 公開 NTP サービス (NTP サーバ名: ntp.nict.jp)

等がある。

ｂ．内部のＮＴＰサーバを準備し、外部ＮＴＰサーバとの同期をとる。W32Time サービス（NTP を使った Windows Time サービス）機能を使用。プロトコル：NTP(RFC1305 準拠)。
ｃ．サイト内の全てのマシンを NTP クライアントとして、②のサーバに接続する。

２．２．５

サービス基盤の調達にあたって

サービス基盤の調達には、サービス基盤構築に必要なハードウェア及びソフトウェアの調達および、システム等の設計、開発、搬入、据付、調整及び試験ならびに保守、教育支援等システム運用のための役務の調達が含まれる。
また、本書に明示していない物品及び役務については、システム調達要求仕様に合わせて、別途、調達が必要である。
サービス基盤の調達にあたっては、庁内システム全体のライフサイクルを考慮し、多段階に分けた調達を行っていくことが望ましい。

－ 13 －

地域情報プラットフォームガイドライン

２．３

プラットフォーム仕様準拠業務ユニットの調達

自治体が、地域情報プラットフォーム標準仕様に準拠した業務ユニットを調達する際、その業務機能要件を検討するにあたって、実際に必要または参考となる事項について下記に示す。各自治体においては、下記事項を参照の上、各業務ユニットの調達仕様を作成して頂きたい。
地域情報プラットフォームでは、「自治体業務アプリケーションユニット標準仕様」(*1)にて規定された業務ユニットに関して、「調達の最小単位を可能とするもの」と位置付けている。そこで注意して頂きたい点は、実際に調達される粒度としては、必ずしもユニット単位（一つずつ切り分けて）である必要はなく、たとえば、住民基本台帳ユニット・印鑑登録ユニットの 2 つを一括で調達するといったように、各自治体の実状に合わせて検討頂くことになる。
なお、本章は、地域情報プラットフォーム標準仕様に準拠した業務ユニットの調達に関連する必要事
項に限定して記載しているため、一般的に業務システムの調達に必要となる事項全てを網羅しているものではない。
(*1)「自治体業務アプリケーションユニット標準仕様」の位置付けについては、「1.1.1 ガイドラインの位置づけ」を参照のこと。

２．３．１

業務ユニットの調達を検討する際に必要となる前提事項「自治体業務アプリケーションユニット標準仕様」では、各業務ユニットが持つ機能(*2)、各業務ユニット間の連携データ項目(*3)、およびオンラインによるデータ連携のインタフェース(*4)を規定しており、同仕様に準拠した業務ユニット製品はそれらを実装している。自治体においては、ここで規定されていない業務機能や連携データ項目などに関しては、個別に検討し、調達仕様へ業務機能要件として反映する必要がある。
そのような場合の変更方針の基本的な考え方としては、下記の２点がある。
・同仕様の中の基本的あるいは共通的な業務機能やデータ項目については、極力変更しないことが望ましい。
・そのような中でも、やはり個別の変更が必要となる場合においては、業務機能やデータ項目の【変更】や【削除】よりも【追加】が望ましい。標準仕様との差異を把握し、管理する上で、わかりやすいからである。
なお、これらの標準仕様にて規定された項目範囲(*2)～(*4)を、自治体にて独自に変更される場合には、業務ユニットの差し替え容易性の低下にもつながることになるので、よく留意されたい。
(*2) 「自治体業務アプリケーションユニット標準仕様」の「業務１－４ 機能一覧」にて規定されているが、この機能一覧の基本的な考え方として、各業務ユニット同士におけるデータ連携を実現するに必要となる業務機能を中心に、必要最小限なものに集約している。
(*3)「業務１－７ インタフェース仕様」「業務１－８ データ一覧」にて規定されている。「インタフェース仕様」に関しては、他の業務ユニットと連携されるデータ項目（オンライン、バッチ）を提示し、「データ一覧」は、そのうちオンライン連携となるデータ項目に集約したものである。
(*4)「業務１－９ インタフェース一覧」にて規定されている。
「データ一覧」にて規定されたオンラ
イン連携用のデータ項目に関して、実際にそれらを連携するための実装方式（SOAP インタフェー－ 14 －

地域情報プラットフォームガイドラインス）を規定したものである。
また、同標準仕様にて規定されていない範囲（＝上記以外の部分）(*5)に関しては、適宜最適な仕様・方式を検討した上で、必要に応じて調達仕様へ盛り込むこととなるが、いずれにしても各自治体固有の改修は必要最小限に抑えることにより、業務ユニットの差し替えを、より容易にすることが可能となる。
(*5) 詳細については、後述の「２．３．３規定された範囲と規定されていない範囲」を参照のこと。
なお、同標準仕様で規定された業務ユニットにおいては、主な前提事項として以下のものがある。自治体においては、同標準仕様に準拠した業務ユニットの調達を検討する際には、まずは以下を踏まえて検討して頂きたい。
※「自治体業務アプリケーションユニット標準仕様」における主な前提事項
・住登外管理ユニットでは、各業務ユニットで扱う住登外者と法人の基本情報を共通的に管理する。
・住登外管理ユニットは、同標準仕様 V2.3 以前は、住登外者の世帯は必要な業務ユニットがそれぞれの業務ユニット内で管理することを前提としていたが、同標準仕様 V2.4 にて、住登外管理ユニット
内で住登外者の世帯を管理する仕様と管理しない仕様のいずれかを選択可能としている。なお、住登外管理ユニットが世帯を管理しない仕様の場合、各業務ユニットで世帯を管理しなければならない。
○世帯を管理する仕様の場合
住登外管理ユニット
基本情報

自ユニット内で管理する世帯の情報

自ユニット内で管理する

各業務ユニット
住登外管理ユニットから情報を取得する
住登外管理ユニットから情報を取得する○世帯を管理しない仕様の場合
住登外管理ユニット
基本情報

自ユニット内で管理する世帯の情報

自ユニット内で管理しない

各業務ユニット
住登外管理ユニットから情報を取得する
自ユニット内で管理する※矢印の組合せの調達は、問題がある。
・収滞納管理ユニットは、税（個人住民税、法人住民税、固定資産税、軽自動車税）、および国民健康
保険税（料）を対象としており、同時に口座情報管理の機能も持つ。これらの税以外の料金を扱う業
務ユニットはそれぞれ当該業務ユニット内に収滞納管理と口座情報管理の機能を持つこととする。
・送付先情報は、必要な業務ユニットがそれぞれ当該業務ユニット内で管理する。
・同標準仕様 V1.5 においては、庶務事務ユニットは人事給与ユニットのデータエントリシステムとして位置づけ、両ユニットは同時調達を前提としていたが、同標準仕様 V2.0 において、人事給与ユニッ
トにもデータエントリ機能を追加し、両ユニットは単独調達を可能としている。
・外字を有するデータ項目としては、「氏名（名称）」・「住所」項目とし、これ以外のデータ項目には基本的に外字を用いない。また、外字の発生源としては、「住民基本台帳」、「戸籍」、「住登外管理」の3 つの業務ユニットを想定している。

－ 15 －

地域情報プラットフォームガイドライン

２．３．２

根拠法令と法改正対応状況、および留意事項

各業務ユニットが持つ業務機能の根拠となる法令、および自治体業務アプリケーションユニット標準
仕様の改定時点における各業務ユニットの法制度改正への対応状況(*6)については、同標準仕様「業務１－２０

法改正対応状況と留意事項」を参照されたい。また、同標準仕様において前提となっている

各業務ユニット固有の留意事項に関しても「業務１－２０（同上）」にて確認願いたい。
自治体においては、それらを把握した上で、各業務ユニットの調達（業務機能要件）の検討に入る必要がある。なお、各業務ユニットが持つ機能概要については、同標準仕様「業務１－２ 業務ユニット概要説明」を参照のこと。
(*6)同標準仕様に関する今後の法改正への対応は、適切な対応を実施していくものとする。ただし具体的な、改版仕様の提供方法などは今後の検討による。

２．３．３

規定された範囲と規定されていない範囲

以下に、同標準仕様における規定範囲について示す。なお、各項目の規定されていない範囲について
は、各自治体に適宜最適な仕様・方式を検討した上で、必要に応じて調達仕様へ盛り込むこととされたい。
また、本章目では、自治体業務アプリケーションユニット標準仕様に準拠した業務ユニットの調達に関連する必要事項に限定して記載しているため、一般的に業務システムの調達に必要となる事項全般を網羅しているものではない。それらに関しては、自治体個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（１） 業務ユニットの機能
各業務ユニットが備える機能については、同標準仕様の「業務１－４ 機能一覧」で示しているが、その実装方式（サービスの単位や詳細な機能など）については規定しない。また、基本的な考え方として、各業務ユニット同士におけるデータ連携を実現するに必要となる業務機能を中心に、標準として必要最小限なものに集約しているため、同機能一覧にて規定されていない業務機能については、各自治体にて個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（２）業務ユニット間で連携するデータ項目、および各業務ユニットが所管（管理）するデータ項目
業務ユニット間で連携するデータ項目のうち、標準として妥当なデータ項目については、同標準仕様「業務１－７ インタフェース仕様」で規定しているが、それに含まれていない連携データ項目があれば、必要に応じて各自治体にて調達仕様へ盛り込む必要がある。また、各業務ユニット内で独自に管理する
データ項目（＝他の業務ユニットとの連携の対象とならないもの）については規定していない。
（３）業務ユニットの画面、帳票など各業務ユニットのオンライン画面の画面展開、ユーザインタフェース、各種帳票等は、同標準仕様では規定しない。各自治体にて個別に検討し、必要に応じて調達仕様へ盛り込む必要がある。
（４） バッチ処理
業務ユニット間のデータ連携のうち、バッチ処理にかかるデータ連携の方式は、処理効率化のために
自治体ごとに最適な実装方式を検討することとし、同標準仕様では規定しない。なお、連携するデータ
項目は、「業務１－７

インタフェース仕様」に準拠することにより、実装方式にかかわらず、業務ユニッ－ 16 －

地域情報プラットフォームガイドライン

ト間の連携を容易に実現することが可能となる。
（５）コード辞書
同標準仕様に準拠した業務ユニットにおいては、各業務ユニット間のデータ連携時に、「業務１－１３
コード辞書」で規定されたコード値に変換してデータ連携ができるものとする。ただし、コード値については、導入する自治体ごとに変更は可能なものとする。なお、その場合、一自治体内では統一したコー
ド辞書で運用することが望ましい。特に共通のコード辞書（例：年号、性別、住民種別等）の変更は全体に広く影響するので、極力変更しないでそのまま利用することが望ましい。
（６）共通 DB
複数の業務ユニットで共通的に利用する DB（例：住所辞書等）は、１カ所にて保持し、一自治体内では共通（統一）的なアクセス方式で利用することを推奨する。ただし内容や形式は多様であるので、同標準仕様では、具体的なデータの内容、種別、辞書名、およびアクセス方式等は規定しない。
（７）業務ユニット横断的な検索機能
自治体業務においては、複数の業務ユニット（たとえば住民基本台帳、住登外管理等）にまたがって、「名前」や「生年月日」等で人の検索を行う機能の必要性が考えられる。しかし、検索の要件は多様であるため、同標準仕様では、このような検索方式については、具体的に規定しないものとする。このような複数業務にまたがった機能の仕様は、各自治体において、必要に応じて検討し、調達仕様へ盛り込
むものとする。
（８）業務ユニット間のデータ連携におけるサービス呼び出しの実装「業務１－９

インタフェース一覧」でデータを提供する側の業務ユニットの SOAP インタフェースの実装方式を規定しているが、データを参照する側の業務ユニットの実装方式は規定していない。業務ユニット間において、どこでどのようにオンライン連携するのかを充分に検討の上、実装すること。

－ 17 －

地域情報プラットフォームガイドライン

２．３．４

業務ユニットを実際に導入する際に検討すべき関連事項

同標準仕様に準拠した業務ユニットを実際に導入するにあたり、自治体側で検討すべき事項の中で、業務ユニットの調達に際しても予め検討しておく必要がある主な関連事項、およびその考え方の例を示す。
なお、本章目では、自治体業務アプリケーションユニット標準仕様に準拠した業務ユニットの導入に関連する検討事項に限定して記載しているため、一般的に業務システムの導入に必要となる検討事項全てを網羅しているものではない。それらに関しては、必要に応じて自治体個別に導入ベンダ含めて検討して頂きたい。

（１）業務ユニット導入・運用における同標準仕様の考え方とその利用①番号管理の検討
人（住民、住登外、法人等）に関しては、一自治体内では統一的なルールによるユニークな番号（同標準仕様では「識別番号」と称す）で管理することとし、異なる人に同じ番号が付番されることが無いようにすること。ある人に付番された番号は、その人が住民基本台帳、住登外管理のどこで管理されるにしても同じ番号のままであり、これらの間を移っても（例えば住民基本台帳に登録されていた住民が転出して住登外管理に登録される等の場合でも）同じ番号のままとする。ただし、具体的な番号体系（桁数やチェックデジット等）と付番管理の方式に関しては、自治体ごとに異なることが多いため、同標準仕様では規定しないが、導入の際に最適な方式を検討し、採用すること。また、各業務ユニットにおいては、人の同定をどんな方法で行うかも適宜検討し、実施すること。
②「独自領域」の利用検討
住民基本台帳と住登外管理は人に関する基本的な情報を扱うが、そこで管理するデータ項目に関しては、基本的な項目以外にも各種の要望があり、自治体ごとにそれぞれ要件が異なる。その中で特に、業務的な運用上の都合で、人の情報を何らかの属性で識別するようなフラグ的な項目を持つことも考えられる。
（例えば窓口業務で、このフラグが立っている人に対しては特別な対応をする等のケース）このよ
うな要求に対応するために、「独自領域」として一定の領域を同標準仕様として確保しており、ここに自治体ごとの固有の項目を定義することができる。
「独自領域」の利用方法は特に定めておらず、無理に利用する必要もない。利用方法は個々の自治体で何らかの具体的な要件が出てきた時に決まることを想定している。
③「異動中区分」の利用検討
住民基本台帳の業務ユニットにおいてオンラインで異動処理中のデータは、異動処理の開始時に「異動事由」と共に「異動中区分」に「1」をシステムで自動的にセットすることにより、現在その「異動事由」で異動処理中であることを示すことができる。異動処理が終了すれば、「異動中区分」を「0」にリセットする。異動処理実施中の一定時間だけ、「異動中区分」に「1」が立っている（ロックしている）
ことになる。同標準仕様として用意しているこの仕組みを、必要に応じて利用することにより、他の業
務ユニットが、住民基本台帳を参照しながら自業務の更新処理を行おうとする際、業務的に矛盾や不整合を起こさないように、住民基本台帳の異動処理が終了するまで自業務の更新処理を待つ、といった排他制御的な作りこみの実装が可能となる。例えば国民健康保険ユニットがある人の国保資格の異動を行おうとしたところ、対象者は住民基本台帳ユニットで「転居」の異動処理中であったため、住所や世帯構成の不整合を避けるため、更新処理を一時中止する、といったケースでの利用が考えられる。

－ 18 －

地域情報プラットフォームガイドライン④「異動年月日」の利用検討
同一人物の住民基本台帳データあるいは住登外・法人のデータを、複数取り出してきて一緒に扱う場
合に、データの新旧が容易に把握できるようにするために、同標準仕様では、データの登録・更新日付
を「異動年月日」として持っている。必要に応じて、この「異動年月日」でソートすることによってデー
タを時系列で並べることができる。蓄積された複数のデータの中から、最新のデータを判定して抽出することにも利用できる。住民基本台帳、住登外管理の各業務ユニットにおいては、最新のデータを登録・更新する際に、異動年月日に日付時間情報をセットする必要がある。
⑤｢宛名管理｣の検討
自治体では、業務ユニットをまたがって共通的に人の基本的な情報（氏名・住所など）を管理するいわゆる「宛名管理」機能を実現していることが多い。これは住民基本台帳ユニット・住登外管理ユニットを中心に、複数の業務ユニットの情報を合わせて管理することによって実現することができる。ただしその実現方法に関しては、「宛名管理」の利用目的・方法によって、管理すべき項目・関連する業務ユニットの範囲・実装方式が自治体ごとに多種多様であると考えられるので、大変重要な要素ではあるが、同標準仕様では規定しないこととしている。
「宛名管理」機能に関しては、必要に応じて個々に最適な実現方法を検討されたい。
⑥複数業務ユニットにて共有利用するデータの管理について
同標準仕様における住登外管理のデータ項目（住登外者、法人）は、実際の運用において、複数の業
務ユニットで同じデータを共有して利用することを想定しているが、データの更新・削除を行う際に、各業務ユニットの業務に支障をきたすことが無いように、更新・削除による影響範囲を把握できるように、同標準仕様では、次のような「最初登録業務ユニット」および「利用業務ユニット」のしくみを準備している。その必要性を検討の上、適宜利用されたい。
・まず、ある業務で住登外者または法人のデータを最初に登録する際に、その業務（業務ユニット番号）をセットする。
「最初登録業務ユニット」の業務ユニットがそのデータのいわばオーナーである。
・次に他の業務ユニットが同じ人物のデータを業務の対象にしようとする場合、「利用業務ユニット」の該当業務の箇所にフラグ「1」をセットする。こうすることによって、この業務ユニットもこのデータの利用業務ユニットのひとつであることを示すことができる。
・もし将来、この人物のデータが不要になって、削除をしようとする際には、利用業務ユニットそれぞれの利用状況を確認の上、削除してもよいかどうかを確認することができる。
なお、「利用業務ユニット」項目上において、各業務ユニットが項目の何桁目のフラグに対応しているかの対応づけは、あらかじめ決めておく必要がある。

（２）業務ユニットの導入・運用におけるその他検討事項①住登外管理の管理体制の検討
同標準仕様における住登外管理は、複数業務にまたがって利用するものであるが、住登外管理ユニッ
トのシステム管理責任部門と住登外情報・法人情報の管理責任部門は、自治体内にて事前に明確に定めておくことを推奨する。
②外字への対応の検討
外字を持つ業務データ項目等については、2.3.2 章に記載しているが、外字全体に関する対応方針の検討にあたっては、「プラットフォーム通信標準仕様」を参照の上、各自治体の既存の業務システムとの整合も配慮し、十分な検討が必要である。
－ 19 －

地域情報プラットフォームガイドライン

業務ユニットの導入に関する検討関連事項は以上であるが、これ以外に、自治体の業務運用において導入の必要性が高いと想定される各種サービス(*7)についても、各自治体において必要に応じて検討して頂きたい。それらサービスのサンプルとして、業務ユニットを活用したユースケース例を、第 4 章の4.1 節に紹介しているので参照して頂きたい。
(*7)たとえば、複数の業務ユニット（住民基本台帳、税系、福祉系など）にまたがって個人の情報を総合的に照会するサービスなど。

－ 20 －

地域情報プラットフォームガイドライン

２．４

導入体制

本章では、地域情報プラットフォーム導入時における調達者体制、ベンダ体制について記述する。
なお、この２．４導入体制に示す内容は一例であるため、実際は本書で示す内容を参考として個々の団体の状況に応じた体制づくりが必要となる。本章では「１．１．６

対象とする自治体規模(人口規模)」に示すとおり、人口数十万人規模の比較的大きな自治体における地域情報プラットフォーム導入を想定して記述しており、人口規模の比較的小さな自治体においては、自治体の実情に即した対応が必要となる。
また、一般的な情報システム導入時における体制について詳細に記述するものではなく、地域情報プ
ラットフォーム導入にあたっての留意点を中心に記載する。

２．４．１

調達者体制

地域情報プラットフォーム導入時における調達者体制について、関連部門と主な役割を以下に示す。

表２．４．１
部門
CIO
CIO 補佐官

情報化主管部門

主要
な部
門

情報システム部門

業務主管部門

全庁横断的意志決定チーム

調達者体制における関連部門と主な役割
主な役割
・ 自治体の情報化統括責任者であり、自治体の情報化戦略および地域情報プ
ラットフォームを含む情報システム調達の最終責任者。
・ CIO、および情報化主管部門に対し、専門的な見地から支援を行う。
・ 自治体の情報化戦略の主管部門であり、地域情報プラットフォームを含む
情報システム調達の主体となる部門。
・ 調達フェーズにおいては、調達仕様書の作成及び作成支援等を行う。また、調達フェーズにおける全体統制を行う。
・ 構築フェーズにおいては、全庁横断的意志決定チーム、プロジェクト管理
チームの事務局を担当する場合が多い。
・ 庁内で共通的に使用するネットワーク等のインフラや基盤系情報システ
ムに関する構築、運用、保守を主管する。地域情報プラットフォーム導入
後はサービス基盤の所管部門となる。
・ 調達フェーズにおいては、サービス基盤等のシステム共通部分について、調達仕様作成及びレビュー等を行う。
・ 構築フェーズにおいては、サービス基盤等のシステム共通部分について、仕様に関する確認・検討・試験、および運用に関する確認・検討を主体となって行う。
・ 業務ユニットを所管する部門であり、実際に情報システムを利用して住民サービスの提供等を行う部門。
・ 調達フェーズにおいては、業務ユニットの調達仕様の作成及びレビュー等を行う。
・ 構築フェーズにおいては、業務ユニットの仕様に関する確認・検討・試験、および運用に関する確認・検討を主体となって行う。また、業務ユニットのデータ移行について、検討および一部作業を行う。
・ 全庁にまたがる情報化戦略に関する意志決定を行う。通常、組織体制図上の関係する各部門からの参加メンバーにより構成される。
・ 調達フェーズにおいては、調達仕様書の最終レビュー等を行う。
・ 構築フェーズにおいては、プロジェクト全体に関わる事項等について意志決定を行う。

－ 21 －

地域情報プラットフォームガイドライン

部門

関
連
す
る
部
門

主な役割

プロジェクト管理チーム

・ 調達後の構築フェーズにおいて、プロジェクト管理（進捗管理、品質管理等）を実施する。通常、自治体、受託者の双方の参加者から構成される。

財政部門

・ 情報システムの調達における予算審査等を実施する。

総務部門

・ 情報システム調達を含む購買に関連する契約管理等を実施する。

首長
議会
自治体住民

２．４．２

・ 自治体の経営における最高責任者。情報システムの調達において、政策面で最終的な意志決定を行う。
・ 自治体の立法機関。情報システム調達における予算について、議決による意志決定を行う。
・ 情報システムを活用した住民サービスを受ける主体であり、パブリックコ
メントや選挙等を通じて、直接・間接的に情報システム調達に対する意志を表明する。

ベンダ体制

地域情報プラットフォーム導入時におけるベンダサイドの体制について、必要となるベンダと主な役
割、各々ベンダに要求される能力、および留意点を以下に示す。また、本項では物品のみを提供するベンダは除いている。
（１）必要となるベンダと主な役割
地域情報 PF 導入時におけるベンダサイドの体制について、必要となるベンダと主な役割を以下に示す。

表２．４．２
ベンダ・・
導入支援
コンサルタント
全
体
・
イ
ン
フ
ラ

・

・

システム基盤
構築ベンダ

・
・
・

・

必要となるベンダと主な役割
主な役割
情報化主管部門・情報システム部門を支援し全体的な導入計画の策定支援を行う。
調達フェーズにおいては、個々のベンダ、機器の調達仕様作成支援を行う。
構築フェーズにおいては、全庁横断的意志決定チーム、プロジェクト管理チームと協働して全体的な進捗管理支援、問題管理支援、調整支援を行う。
本ベンダを調達しない場合は、情報化主管部門・情報システム部門において本役割を全て担う必要がある。また、自治体側の体制・予算を考慮して上記内容から発注範囲を限定することも一般的である。
システム基盤について、設計・構築作業を行う。
システム基盤について、構築後の保守・運用を行う。
システム基盤に必要な物品（ハード製品・ソフト製品）については、本ベンダが必要な物品一覧（原則としてスペック指定）を行い、別途、競争的な調達を行うことが望ましい。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、住民基本台帳等の主要業務ベンダに併せて担わせる必要がある。

－ 22 －

地域情報プラットフォームガイドライン

ベンダ・

ネットワークベンダ

・
・

・
・

データセンタ・・・・

保守・運用統括ベン
ダ

・
・
・
・

○○業務
コンサルタント
・

・
業
務
ユ
ニ
ッ
ト

・
新規
○○業務ベンダ・・既存○○業務ベンダ

主な役割
既存ネットワークの地域情報プラットフォーム対応について、現状調査、
ToBe モデルの設計、移行計画の策定、移行・構築作業を行う。
ネットワークについて、構築後の保守・運用を行う。
ネットワークに必要な物品（ハード製品・ソフト製品）については、本ベンダが必要な物品一覧（原則としてスペック指定）を行い、別途、競争的な調達を行うことが望ましい。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、システム基盤構築ベンダに併せて担わせる必要がある。
地域情報プラットフォーム対応に関する機器の設置スペース、設備、電源等の提供、及び、機器等の運用・管理等におけるオペレータ業務を行う。
機器を自庁舎内に設置しない場合に調達が必要となる。
単独でデータセンタを調達する選択肢と、共同アウトソーシングを活用する選択肢が存在する。
システム基盤構築ベンダに併せて担わせる選択肢も存在する。
保守・運用には上記の全てのベンダの関与が必要であるが、保守・運用の全体を管理・統括するベンダも必要となる。
本ベンダを調達しない場合は、情報システム部門において本役割を全て担うか、システム基盤構築ベンダに併せて担わせる必要がある。
業務主管部門を支援し業務システムの導入計画の策定支援を行う。
調達フェーズにおいては、業務システムの調達仕様作成支援を行う。
構築フェーズにおいては、業務システムの仕様に関する確認・検討・試
験、および運用に関する確認・検討の支援を行う。また、業務システムのデータ移行についての検討を支援する。
本ベンダを調達しない場合は、業務主管部門において本役割を全て担う
か、導入支援コンサルタントに併せて担わせる必要がある。また、自治体側の体制・予算を考慮して上記内容から発注範囲を限定することも一般的である。
地域情報プラットフォーム対応の業務ユニットを用いて最小限のカスタ
マイズによる業務システムの設計・構築作業を行う。
業務システムに必要な物品（業務ユニットを構成するソフトウェア製品
等）については、本ベンダが必要な物品一覧（原則として製品指定）を行い、別途、競争的な調達を行うことが望ましい。
既存の業務システムからの移行について、移行計画の策定と移行・構築作業を行う。
本ベンダを調達しない場合は、業務主管部門・情報システム部門において本役割を全て担う必要がある。

・ 既存の業務システムからの移行について、移行計画の策定を既存システ
ムの観点から支援する。
・ 既存の業務システムからのデータ移行について、データの整備・抽出作業を行う。
・ 本ベンダを調達しない場合は、業務主管部門・情報システム部門において本役割を全て担うか、業務コンサルタント・新規業務ベンダに併せて担わせる必要がある。

－ 23 －

地域情報プラットフォームガイドライン（２）ベンダに要求される能力
地域情報ＰＦ導入時におけるベンダサイドの体制について、ベンダに要求される能力を以下に示す。

表２．４．３
ベンダ

導入支援
コンサルタント

全
体
・
イ
ン
フ
ラ

システム基盤構築
ベンダ

ネットワークベンダ

データセンタ

・
・
・
・
・
・

・
・
・
・
・

・
・
・
・
・

・
・
・
・

ベンダに要求される能力要求される能力
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
公共分野における IT 調達の方針・動向への理解と知識・経験。
コンサルティング能力と経験。
プロジェクト管理の能力と経験
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
インフラ設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
サービス基盤構築に係る SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
ネットワーク設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計等）
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
対災害性、セキュリティ対策に優れた設備、電源等の提供
プロジェクト管理の能力と経験
機器等の運用・管理等におけるオペレータ業務の能力と経験
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）－ 24 －

地域情報プラットフォームガイドライン

ベンダ

保守・運用統括ベンダ○○業務
コンサルタント

業
務
ユ
ニ
ッ
ト
新規
○○業務ベンダ

既存○○業務ベンダ

２．４．３

・
・
・
・
・

・
・
・
・
・
・
・

・
・
・
・
・

要求される能力
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
インフラ設計・構築の能力と経験。
特に以下の技術への知見と経験が望ましい。
インフラ基盤（高信頼性設計、性能設計、仮想化設計等）
IT ガバナンス・IT コンソリデーション
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報 PF への理解と知識・経験。
自治体業務への理解と知識・経験。
公共分野における IT 調達の方針・動向への理解と知識・経験。
コンサルティング能力と経験。
プロジェクト管理の能力と経験
対象業務、業務システム、業務ユニットへの知見と経験
特に以下の技術への知見と経験が望ましい。
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等）
地域情報ＰＦへの理解と知識・経験。
自治体業務への理解と知識・経験。
プロジェクト管理の能力と経験
対象業務、業務システム、業務ユニットへの知見と経験
特に以下の技術への知見と経験が望ましい。
セキュリティ（ネットワークセキュリティ、SSO 等）
運用・管理（構成管理、バックアップ、監視、障害対策等）
SOA 技術（Web サービス関連技術、ESB、BPM、サービス管理等））－（既存ベンダであり、調達時に必要な能力は評価されていると考えられるた
め省略）

体制上の留意点

地域情報プラットフォーム導入にあたっての体制上の留意点を以下に示す。
（１）地域情報プラットフォーム標準仕様に関する理解
地域情報プラットフォームを導入する場合、調達仕様は地域情報プラットフォーム標準仕様がベースとなるため、調達仕様の策定にあたっては、地域情報プラットフォーム標準仕様の内容を踏まえ、調達を行う自治体の現状のシステム仕様との差異を考慮し、適切な調達仕様の策定、構築時の仕様検討を行うことができる体制が求められる。
（２）セキュリティ、個人情報保護に関する検討
地域情報プラットフォーム標準仕様は、他自治体や民間企業との連携も見据えた仕様となっており、導入にあたっては自治体全体、もしくは地域全体の最適化を意識したセキュリティ、個人情報保護の検討が必要となるため、全庁的なセキュリティ、個人情報保護に関する検討を十分に行うことができる体制が求められる。
－ 25 －

地域情報プラットフォームガイドライン（３）業務横断的な検討体制
地域情報プラットフォーム標準仕様においては、業務ユニット間インタフェースの標準化により、業務ユニット間連携の構築を容易に行えることを目標としているが、業務ユニット間連携に関する検討が不要になるということではない。また、文字（外字等の扱い）、共通コード等、ワンストップサービス導入等、特定業務システムのみでは解決できない要素もあり、業務横断的な検討を十分に行うことができる体制が求められる。また、業務主管部門の体制（役割分担）、業務システムの調達単位、業務ユニットの単位等において整理が必要となる場合も想定され、この点についても業務横断的な検討を十分に行うことができる体制が求められる。
（４）マルチベンダによる構築時の留意点
地域情報プラットフォーム標準仕様においては、特定ベンダに依存することのないオープンな仕様を採用するなど、マルチベンダ化の促進を目指した仕様となっている。こういったマルチベンダによる協働作業では、責任分界点の明確化による「抜け」の発生防止に特に注意が必要となり、責任分界点の整理・定義に加えて、全体を取りまとめる責任者の明確化にも注意が必要となる。全体を取りまとめる責
任は、情報化主管部門・情報システム部門、もしくは主要な業務主管部門が担うのが原則であるが、導入支援コンサルタント、業務コンサルタント、システム基盤ベンダ、保守・運用統括ベンダ等にも一定の役割を担わせて、自治体側の負荷を軽減することも有効である。
（５）長期視点に立った計画の策定と複数プロジェクトの管理
地域情報プラットフォームを全面的に導入する場合には広範囲における情報システムの入れ替えを行うことになるため、通常、長期間にわたって複数のプロジェクトを並行的、段階的に進めることになる。
自治体の情報化戦略の主管部門である情報化主管部門では、長期的な視点から導入計画を策定し、また、全体最適の視点に立って複数のプロジェクトの整合を図るなど適切なマネジメントを行っていく役割が求められる。この際に、CIO 補佐官や導入支援コンサルタントの支援により、自治体側の負荷を軽減することも有効である。

－ 26 －

地域情報プラットフォームガイドライン

２．５

移行計画

２．５．１ 移行方針の策定
地域情報プラットフォーム導入のスケジュール策定において特に留意すべき点は既存業務システムからの移行であり、そのための基本的な方針を決定しておく必要がある。基本方針策定上留意すべき主要な項目は次のとおりである。
（１） 既存業務システムと業務ユニットの粒度（機能範囲）の調整：
地域情報プラットフォームの基本的な連携単位は業務ユニットであり、既存業務システムから移行、
あるいは併存する時には両者の粒度（カバーする機能の範囲）の調整が必要であるが、可能な限り標準仕様に準じた粒度が望ましい。
（２） 標準インタフェース仕様と既存業務システムデータの整合性への対応：
業務ユニットへのデータ移行および併存する既存業務システムとのデータ交換においては、標準イン
タフェースとの整合性が求められる。既存業務システムにおけるデータ項目の過不足や定義の相違等への対応のために変換ルールや独自領域の利用ルールを定める必要がある。データ項目定義の相違について代表的なケースを以下にあげる。
—

同一データ項目で長さや属性が異なるケース—

コードデータ（続柄、異動事由、年号等）の定義や割当てが異なるケース—

データ項目の分割、区分方法が異なるケース（住所と方書き、姓と名等）—

レコードやデータの状態や属性を固有のフラグで表現するケース—該当しないデータ項目の記録方法（ブランク、Null 等）特に金額等数値データは要注意

具体的な検討事項は「２．５．３既存業務システムとの整合性について」で示す。
（３） 識別番号の統一
内部事務系の業務ユニットを除く業務ユニット間の業務ユニットインタフェースはサービス要求側業
務ユニットが個人または世帯の識別番号を提供側業務ユニットへ指定するルールとなっている。したがって要求側業務ユニットは何らかの方法で個人または世帯の識別番号を特定する必要があるが、既存
業務システムから移行するデータにこれ等の識別番号が含まれていない可能性がある。したがって地域
情報プラットフォームへの移行に当っては個人、世帯、法人等について全業務共通の識別番号を定め、名寄せ等の作業によってこの識別番号を各業務ユニットのデータベースに取込む必要がある。
この識別番号として既存住民基本台帳システムや住登外管理システムの個人、世帯番号を用いることが一般的であるが、自庁内でのみの識別番号であることから、他行政機関や民間とのサイト間連携を行う場合には、他機関共通でユニークとなる番号を利用する可能性を検討する必要がある。
（４） 文字セットの統一
地域情報プラットフォームでは、文字セットについては、JIS X0213:2004 の範囲を前提としている。
しかし、当面の経過措置として自治体内の合意に基づき、「内字」を JIS X0208 の文字に限定することや、
JIS X0213:2004 中の第一、第二水準文字に限定することができるものとしている。したがって既存業務システムで用いられている外字（ベンダ選定文字とユーザー選定文字）を含むデータの移行・交換においてもこの範囲の文字セット(JIS X0213:2004)に置換え・変換するのが前提である。しかし、書面で外部に出る字形の継続性や証明書類の証憑性の点で、これらの外字を含んだ、全ての業務ユニットで使用する文字セットについては、JIS X0213:2004 の範囲を前提に外字を追加していく形で拡張していくことが望ましい。この場合、外字の同定作業を行う必要があるが、特にベンダ選定文字はベンダによって文字セットが異なるため、既存業務システムが複数の異なったベンダのシステム環境で稼働している場合
は同定に注意を要する。
－ 27 －

地域情報プラットフォームガイドライン

また、他行政機関や民間とのサイト間連携を行う場合を考慮すると、新しく定義する文字セットは可
能な限り独自性を廃し、地域情報プラットフォーム内字、あるいは一般的に認識されている文字セットに準拠することが望ましい。例えば戸籍統一文字や法務省統一文字などが考えられる。
なお、地域情報プラットフォームの文字セットに関しては、「プラットフォーム通信標準仕様・３．３
メッセージの XML 定義仕様（３）文字コード・外字に関する規則」を参照。

２．５．２

段階的移行

（１） 段階的移行の必要性
地域情報プラットフォームによる行政情報システムの構築では、多くの場合既存行政情報システムからのアプリケーションの移行が必要となるが、多様な既存行政情報システムのアプリケーションを一斉に移行することは容易ではない。その主な理由は次のとおりである。
—

既存行政情報システム環境の多様性（汎用機、オフコン、CS 等）—

アプリケーション運用主体の多様性（情報システム部門、業務主管部門、外部委託先等）—

移行ワークロードおよびコストの集中—システム機器リースの満了—

アプリケーション改修の影響（新規制度の創設、既存制度の大幅な改正等）

したがって、地域情報プラットフォーム導入によって達成すべき目標と移行すべきアプリケーションの優先度等により行政情報システム全体の移行計画を策定し、その計画に沿って段階的に移行することが現実的である。
（２） 移行の形態
地域情報プラットフォーム基本説明書にあるとおり、既存行政情報システムの地域情報プラット
フォーム環境への移行の形態にはリホスト、リライト、リビルド（リエンジニアリング）が考えられる。
これ等の移行形態の選択は、移行コスト、既存業務システムの状態、業務継続性等によって、概ね図２．
５．１の様に類型化することができる。なお、図２．５．１において実線矢印は既存業務システムと地域情報プラットフォーム環境の併存を意味し、破線矢印は地域情報プラットフォームへの業務ユニットの置き換えを意味する。

－ 28 －

地域情報プラットフォームガイドライン

既存業務システムの環境
業務システム業務システム業務システム業務システム業務システム業務システム

A

B

C

D

E

F

① 併存・
統合ＤＢ連携②③

併存・

アダプタ連携

アダプタ

④

リホスト

⑤

リビルド

⑥

リビルド

⑦
新規導入

アダプタ連携リライト

業務システム業務ユニット業務ユニット業務ユニット業務ユニット

C

D

E

F

G

パッケージ適用

アダプタ

統合ＤＢ

サービス基盤地域情報プラットフォーム環境
図２．５．１

地域情報プラットフォームへの移行形態の例① 既存業務システム環境を併存して既存業務システムを移行せず、地域情報プラットフォームの統合データベース経由で連携する形態。既存業務システムのデータベースのデータを地域情報プ
ラットフォームの統合 DB 機能へ提供することで実現。主なコスト要因はレガシー環境併存のための運用コストであり、その他には比較的大きなコスト要因はないが、連携の範囲は限定的。
② 既存業務システム環境を併存して既存業務システムを移行せず、アダプタの開発・付加により連携する形態。アダプタの開発は既存業務システムのコンポーネント化の程度やアダプタによって実現する連携の範囲によって難易度・コストが異なる。既存業務システム環境併存のための運用コストと共に、アダプタ開発コストが判断の鍵となる。
③ 地域情報プラットフォーム環境で既存業務システムの稼働が可能な場合、既存業務システムを現状のままリホストしてアダプタの開発・付加により連携する形態。既存業務システム環境併存のための運用コストは不要となるが、仮想化等による両者が共存できるシステム環境の有無が判断の鍵となる。アダプタ開発は②と同様。
④ 既存業務システムの処理機能を、そのまま地域情報プラットフォーム環境の業務ユニットとして再開発する形態。地域情報プラットフォームとの親和性は高くなるが人が関与する作業を含めた業務処理の改善にはつながらない。また、標準仕様書で示される業務ユニットおよび業務サービスの要件との整合性を考慮する必要がある。
⑤ 人が関与する作業を含めた業務処理の内容を見直し、再設計して、地域情報プラットフォーム環
境の下で再開発する形態。業務・システム最適化を実現するために効果的な形態だが、移行に要する時間とコストが大きくなる。
⑥ 地域情報プラットフォーム準拠のパッケージ製品へ移行する形態。パッケージ製品が前提とする業務処理、人が関与する作業を自組織に適用することの可否がこの形態の鍵となる。
⑦ 新規に業務システムを地域情報プラットフォームに導入する形態。既存業務システムは存在しないので比較的自由度は大きい。通常は上記⑥同様にパッケージ製品を導入する。

－ 29 －

地域情報プラットフォームガイドライン

コラム ２．４．２ （２）移行の形態
地域情報プラットフォームへの移行の典型的な形態は⑥のパッケージ適用による業務システムのリビルドであり、標準仕様の目標である差換え可能性（カセッタブル）実現のためにも望ましい形態である。この形態では業務主管部門の業務処理をパッケージにあわせることを原則としてパッケージの改変（カスタマイズ）は極力避けるべきである。
業務処理の継続性や独自性を重視する場合は⑤リビルドまたは④リライトによるが、十分な体制と能力、および予算で開発および保守に当る必要がある。特にシステムライフ期間の保守体制と予算への配慮が重要である。
既存業務システムをそのまま地域情報プラットフォームに連携する形態の内、①および②は既存業務システムのシステム環境併存のための運用経費増となるため、移行のための経過措置と位置づけるべきである。また、③の形態は仮想サーバにより地域情報プラットフォームのシステム環境に既存業務システムの環境を導入するため、現時点では余り一般的ではない。

（３） アプリケーション移行優先度の考え方
地方自治体の業務体系には大きく分けて基幹情報系（住民基本台帳、税務等）と内部情報系（財務情報、人事給与等）に分かれる。どちらの体系を優先して移行するのか、または同時に移行するのかは各自治体の判断によるものである。
地域情報プラットフォームの要件でも示したように、地域情報プラットフォームで最初に実現することは標準インタフェースによる業務ユニット間データ交換である。特に住民基本台帳（以下住基と略す）、
税務、保健福祉等の住民サービス系アプリケーション群では住基アプリケーションが管理する住基デー
タとの連携が重要となるため、住基アプリケーションの既存行政情報システムから地域情報プラット
フォーム・住基業務ユニットへの移行順位が鍵となる。住基アプリケーションの移行順位には概ね次のように２つの考え方があり、いずれを採用するかは地方自治体の判断による。
①住基アプリケーションを優先移行する考え方
住民ポータルや総合窓口等のフロント系業務ユニットの構築・運用を優先したアプローチである。
住基業務ユニット移行を先行することによって、フロント系業務ユニットが必要とする住基データを中核とした統合データベースを早期に実現できる可能性があるが、既存システム環境で稼動する未移行の住民サービス系各アプリケーションは、住基業務ユニットに対するインタフェース（アダプタ）を個別に付加することが必要となる。
②住基以外のアプリケーション（住基データ利用アプリケーション）を優先移行する考え方
住民サービス系アプリケーションのバックエンド・アプリケーションの脱レガシー、置き換え可能性（カセッタブル）を優先したアプローチである。
そのために、既存システム環境で稼働する住基アプリケーションに業務ユニット標準インタフェース（アダプタ）を付加し、地域情報プラットフォーム移行済みの住民サービス系各業務ユニットと住基デー
タ交換を実現する。上記①に比べインタフェース開発のワークロードは少ないが、移行期間中の暫定処置であり、住基データを中核とした統合データベースの実現は遅れる。
（４）

既存行政情報システムとの併存

一般的に既存レガシー・システムを SOA 環境と連携させるために、アダプタを開発・付加することが提唱されているが、アダプタは既存レガシー・システム毎に個別開発する必要があり、既存レガシー・システムの改変を最小限に留めて SOA 環境が要求する全てのサービスインタフェースに対応することは非常に困難であり、その実現のためには多大な開発期間とコストが見込まれる。
したがって、移行期間中の既存行政情報システムと地域情報プラットフォーム・業務ユニットとの併
存では連携の範囲を次のような考え方で限定することが適当である。
－ 30 －

地域情報プラットフォームガイドライン①前提条件第 2 段階、第 3 段階におけるデータ交換、サービス連携
既存行政情報システムのアプリケーションがデータ提供側の業務ユニットとして機能する連携に限定する。既存アプリケーションが地域情報プラットフォーム・業務ユニットからデータの提供を受けて利用するためには、プログラムの大幅な改修が想定されるため現実的でない。
この連携のためには次のような方法が考えられる。
—

既存アプリケーションに一方通行（既存アプリケーション⇒業務ユニット）のデータ交換
インタフェースを提供するアダプタを開発・付加する。

既存システム

業務Ｂ

業務Ａ

業務Ｃ

業務ＤＢ

業務ＤＢ

・・・

業務ＤＢ

Ａ社
業務ユニットＡ

業務ＤＢ
既存アプリケーションとの連携インタフェース
業務ｻｰﾋﾞｽ
ｲﾝﾀﾌｪｰｽ
アダプタ
PF通信機能（SOAP通信）SOAPインタフェース

図２．５．２—

既存システム－業務ユニット間データ交換例

既存アプリケーションのデータベースのレプリカを地域情報プラットフォームの統合デー
タベース（公開データベース方式）と定義して、各業務ユニットからの連携を可能にする。

既存システム
業務Ａ

業務Ｂ

業務Ｃ

業務ＤＢ

業務ＤＢ

業務ＤＢ

・・・

Ａ社
業務ユニットＡ
業務ＤＢ
既存アプリケーションとの連携インタフェース
業務ｻｰﾋﾞｽ
ｲﾝﾀﾌｪｰｽ
統合ＤＢ機能アダプタ

PF通信機能（SOAP通信）SOAPインタフェースまたはSQLインタフェース
SOAPｲﾝﾀﾌｪｰｽ
または
SQLｲﾝﾀﾌｪｰｽ

統合ＤＢ

図２．５．３

既存システム－統合ＤＢ機能－業務ユニット間データ交換例－ 31 －

地域情報プラットフォームガイドライン

２．５．３

既存の業務システムとの整合性について

段階的な移行の場合、既存システムと新システム（地域情報 PF）との共存（連携）を考慮した、両システム間のデータ整合性について検討する必要がある。
既存システムの依存関係
業務システムA

業務システムB

業務システム
C

DB-A

DB-B

DB-C

ﾌｧｲﾙ

DB

段階的移行例

業務システムB、Cを業務ユニットb、cに移行
新シ ステ ム調達範囲
業務ユニット
b

DB-B

DB-C

DB-b

DB-c

既存シ ステ ム

既存デ ー タ移行

業務システム
A

地域情報PF

DB-A

図２．５．４

デ ー タ整合性確保業務ユニットc

統合DB

既存システムと新システム（地域情報 PF 準拠）との共存【データの整合性に関する検討事項】（１）新システムへの既存データ移行
既存システムから新システムへ円滑な切替えを行うために、データ移行について時期と方法（ツール）を明確にする。
調達する業務ユニット b、c に既存業務システム B、C のデータを移行する場合、事前に両データ間（DB-Bと DB-b、DB-C と DB-c）のギャップを分析し、策定した対策方法に従ってデータ移行を可能とするツールが必要になる（図２．５．４参照）。
（２）既存システムと新システム間におけるデータの整合性
既存システムと新システムが同期のとれたサービスを提供するために、両システム間のデータの整合性を確保する方法を明確にする。
既存業務システム A が、調達する業務ユニット b に即時公開を要求する場合、即時更新仕様の業務ユ－ 32 －

地域情報プラットフォームガイドライン

ニット b を調達する必要がある（図２．５．４参照）。
既存業務システム A が、調達する業務ユニット b に日時公開を要求する場合、即時更新または日時更
新仕様の業務ユニット b を調達する必要がある（図２．５．４参照）。
（３）文字データの整合性
新システム導入の際に「内字」の文字セットを決定する。地域情報プラットフォームでは、文字セッ
トについては、JIS X0213:2004 の範囲を前提としている。しかし、当面の経過措置として自治体内の合意に基づき、「内字」を JIS

X0208 の文字に限定することや、JIS X0213:2004 中の第一、第二水準文字に限定することができるものとしている。
（４）新システム（地域情報 PF）における文字の分類
新システム（地域情報 PF）の文字は「内字」と「外字」分類される。
「内字」は地域情報 PF 上のすべての業務ユニットで等しく認識され、また、確実な利用（連携）が保障される文字である。
「外字」は「内字」以外の文字であり、「標準外字」と「個別外字」に分類される。
「標準外字」は戸籍統一文字や法務省統一文字など、公的に整備されたものを候補として検討している。
「個別外字」は「標準外字」に含まれない文字を個別、独自に定義したもので、新システム（地域情報 PF）内においても利用（連携）が困難な文字である。
なお、システム内では文字を UCS(UTF-8 または UTF-16)に符号化して取り扱う。
（５）新システム（地域情報 PF）で利用できる文字
V1.0 の範疇では「内字」の利用（流通）を必須とする。
「外字」については、PUA を用いて表現し、自治体内で十分な管理がなされる範囲で流通を許す。ただし、「外字」の自治体外への発信は禁止する。
PUA : Private Use Area

外字私用領域

なお、業務ユニットの調達に際しては、「２．３．４
関連事項」も併せて参照のこと。

－ 33 －

業務ユニットを実際に導入する際に検討すべき地域情報プラットフォームガイドライン

２．５．４

テスト方式

地域情報プラットフォームによる行政情報システムは、多様なハードウェアに各々アプリケーションが搭載され、それらがネットワークによって連携される構造となる。本書でのテスト方式の検討では、
サービス連携基盤の各単体機能、業務ユニットについては地域情報プラットフォーム標準仕様に準拠（PF準拠）を満たし、且つ、各々のユニットでの単体テストは終了していることを前提とする。
住基ユニットのように業務ユニット間連携で主軸となるような業務ユニットから、税務、健康福祉のような個別業務ユニットまで、既存の行政情報システムが業務ユニットの単位で段階的に移行しながら、
統合データベースや地域情報プラットフォームによるサービス基盤上で新行政情報システムが構築されていく過程でのテスト方式という設定で検討を行う。
（１）テスト実施にあたっての基礎作業
通常、テスト計画を策定するに当たって、まず、下記の作業が必要となる。
① テストスコープの確立
冒頭でも述べたとおり、ハードウェアからネットワーク、アプリケーションといった構成のほかに、移行・構築にああっては複数の段階に渡る事となるため、テストすべき範囲と目的を明確に設定する必要がある。
② テスト方法の定義
テストの主催者は誰か、参加構成主体は誰か、各パートのテスト方式がセルフ方式かテスト
スィートを使う方式か、進行スケジュール、テストシナリオ、問題発生管理の方法、評価方法といった一連のテスト方法について決めておく必要がある。
③ リソース要件特定
テストに必要となるデータやソフトウェア、ハードウェア、さらには、作業空間や人材等の各種リソースについて、テスト種別毎に整理しておく必要がある。
（２）標準的なテストパターン
複合的なアプリケーションで構成される行政情報システムのような場合、標準的なテストパターンとしては以下のようなものがある。
① 単体テスト
本書では調達範囲ベンダにより実施済みとみなす。
② 統合テスト
本書では調達範囲の担当ベンダによるシミュレーションレベルでのテストは実施済みとみなす。
③ 総合テスト
このテスト結果が要件定義書・基本設計書を満たしているかといった視点から品質評価を行い、次フェーズの受入れテストへと円滑に進める。
サービス基盤における 4 機能および業務ユニットが複数存在するケースが想定され、開発導入時期も一致しないことから、各機能・ユニット間の連携テスト部分については、テスト計画、テストスケジュールの入念な調整が重要である。
④ 受入テスト
PMO(Project Management Office：マネジメント業務を横断的に調整し支援する組織）等を中心に第三者的に組織された体制が受入れテストを主体的に行い、当該自治体やその主要部門に対してサービス基盤およびその上での新業務ユニットの稼動を実演し、業務要件の充足や作業時の使い易さなどについての検証・評価を行い、移行運用へと円滑に進める。
業務要件を定義した部門・組織、システム開発ベンダ、主要部門における支援コンサル等が協同で受入れテストを実施することとなるが、体制面での役割分担や意思決定ロジック等の組織整－ 34 －

地域情報プラットフォームガイドライン備が重要となる。
また、現データベース、現システムデータの切り替えには、現行システム担当者・移行改修業者との連絡・調整が必要である。さらに、旧システム稼動場所と新システム稼動場所が異なる場合を想定したテスト環境の構築も検討しなければならない。
（３）テスト実施体制
地域情報プラットフォームによる行政情報システムの構築では、一般的には、調達側である当該自治体内に PMO が組織され、PMO が事務局となって、地域情報プラットフォーム推進会議といった全庁意思決定機関が設置されるケースが多いものと考えられる。テスト結果の承認や対応策協議によって結論を下すのは、この地域情報プラットフォーム推進会議といった体制で行われるはずである。ここを頂点にテスト実施体制としては、以下のように設置する事が想定される。
① 地域情報プラットフォーム推進会議
CIO 或いは首長を議長として主要な部門および関連する部門の長によって構成される調達者体制である。通常は、情報化主管部門か PMO によって事務局機能が提供され、当該自治体としての
地域情報プラットフォーム構築運用に係る最終意思決定機関となっている。
② テスト評価会議
情報化主管部門か PMO が単独か導入支援コンサルタントを加えて主催し、何種類かの総合テス
トや受入テストが、段階ごとに実施されていく際に、逐一、テストスコープや方法・シナリオ、結果に至るまでを評価する。
ここには、関連する主要業務部門の責任者、関連する機能やユニットのベンダ、既存ユニットのベンダ、既存ユニットの関連場所・リソース管理者等が参加して、テスト実施が円滑かつ効率的に行われると共に、結果を客観的に評価して、再テストの必要性や問題点や課題の洗い出しを行う。
・レビュー方針（チェックリスト）の作成
・ベンダが作成したテスト計画の評価・ベンダが作成したテストシナリオの評価
・ベンダが構築したテスト実施環境の評価
・ベンダが実施したテスト結果の評価と問題課題整理
・その他調整作業（テストデータ受け渡し等）③ テスト実施 TF
まず、サービス基盤の 4 機能に係るテスト実施 TF が必要な場合を想定しなければならない。この TF の必要性については、サービス基盤（全体インフラ）の構築段階によるが、本ガイドライン
では、サービス基盤 4 機能のテストの必要性も定義しておく。
各業務ユニット系の移行に際しては、各々TF を設置して実際のテストを行うこととなる。この
TF はサービス基盤ベンダあるいは当該 TF と調整をとって、まず、サービス基盤との総合テストを実施し、ついで、サービス基盤上で連携する他業務ユニットとの総合テストを実施する。
また、総合テストの実施結果によってサービス基盤や各業務ユニットに対して問題解決の必要性が生じた場合は、テスト評価会議が地域情報プラットフォーム推進会議に諮って実施を定めた
内容によって改修を実施することとなる。
以上の TF については、当該ベンダが主軸となって、関連する主要業務部門の担当者、関連する機能やユニットのベンダ、既存ユニットのベンダ、既存ユニットの関連場所・リソース管理担当者等に参加を呼びかけてテスト実施することとなる。
この際は、サービス基盤のテスト実施ＴＦを中心として、複数の TF で相互にテストし合う必要があり、全ての組合せについて各々がテスト結果をテスト評価会議に提出する方式が妥当と考えられる。
－ 35 －

地域情報プラットフォームガイドライン

地域情報プラットフォーム推進会議

テスト評価会議

複数のテスト実施ＴＦの組合を想定
サービス基盤
テスト実施ＴＦ

業務ユニットＡ
テスト実施ＴＦ

図２．５．５

業務ユニットＢ
テスト実施ＴＦ

・・・・・

テスト実施体制の例（４）テスト計画
地域情報プラットフォームによる行政情報システムの構築では、2 つの段階的な移行・構築パターンが示されているが、いずれもインタフェースやアダプタ、既存アプリケーションのデータベースのレプリ
カといったコンポーネントが統合環境の中に組み込まれることとなる。
これらを含めた統合システムとして全体を捉え、業務ユニットの統合化の順番や時期を考慮して有効な段階を区切るといったテストスコープ、その場合の方法、リソースを定義しつつ、総合テストおよび受入テストを実施していく必要がある。
① サービス基盤総合テスト
サービス基盤における PF 通信機能、統合 DB 機能、BPM 機能、PF 共通機能の 4 つの機能に対して、導入支援コンサルタントとシステム基盤構築ベンダ、ネットワークベンダ、データセンタベ
ンダ、保守・運用統括ベンダが定義されている。
なお、統合 DB 機能、BPM 機能、PF 共通機能はオプションとして位置づけられており、なおかつ、
PF 通信機能は SOAP として OS に組み込まれた状態で各業務ユニットに保有する形態も想定されており、最小構成の場合は、このサービス基盤総合テストは不要となるケースも考えられる。
PF 通信機能とどれかのオプション機能が装備される場合、上記ベンダも一括かあるいは複数存在する事となるが、その際には、各機能間と各ベンダ責任範囲間での総合テストが必要となる。
これにより要件定義書・基本設計書を満たしているかといった視点から品質評価を行い、次フェーズの受入れテストへと円滑に進めなければならない。
サービス基盤内機能が複数存在し開発導入時期も異なる場合は、各機能およびベンダ間の連携したテストとなるため、テスト実施ＴＦは導入支援コンサルタントを事務局とした関連ベンダで構成する事が望ましい。
・テスト評価会議へのレビュー方針（チェックリスト）の作成
・総合テスト計画・スコープの作成
・テストシナリオの作成
・テスト実施環境構築計画の作成
・テスト結果の評価方法の作成
・テストデータの作成－ 36 －

地域情報プラットフォームガイドライン② 業務ユニット系総合テスト
業務ユニットについては、共通系・バック系とフロント系との 2 種類で定義されているが、いずれの場合であっても、対サービス基盤あるいは業務ユニット間での連携が発生することとなる。
サービス基盤における PF 通信機能が各業務ユニットに内蔵されている場合は、関係する業務ユニット間での相互接続性テストとして各業務ユニットのテスト実施 TF によって全ての組合せでテストを実施する事となる。
PF 通信機能および統合 DB 機能、BPM 機能、PF 共通機能等をサービス基盤として具体的に形成する場合は、前項のサービス基盤総合テストを完了していると想定した上で、まず各業務ユニットとサービス基盤との総合テストが必要となる。ついで、サービス基盤を介しての関係する業務ユニット間の全ての組合せで相互接続性テストを行う。
これらの際に各々テスト実施 TF によって相互にテスト結果を得てテスト評価会議に図っていくこととなる。
下記の各作業は、サービス基盤および業務ユニットによるテスト実施 TF 間で協議の上遂行される必要があるが、その検討結果をテスト評価会議が調整して、テストの順番や評価方法について決定する必要がある。
・テスト評価会議へのレビュー方針（チェックリスト）の作成
・総合テスト計画・スコープの作成
・テストシナリオの作成
・テスト実施環境構築計画の作成
・テスト結果の評価方法の作成
・テストデータの作成
なお、本総合テストで問題や課題が発生した場合は、テスト評価会議の結果を受けて相互に調整するか、仕様の変更を必要とするレベルの対策についてはテスト評価会議の整理からさらに地域情報プラットフォーム推進会議の決定を受けて実施し、対策実施後は、再度テストをやり直すこととなる。
③ 受入テスト
受入テストについては、上記各総合テストが完了することによって実施可能となる。
ただし、既存システムと併用しながら段階的に業務ユニットが稼動するパターンが想定されており、サービス基盤形成や業務ユニット接続のタイミングを計りながら、必要なところで受け入れテストを実施し、既存システムと新システムとが共に実稼動するようにしなければならない。よって、
既存システムの入れ替えが完了するまで、必要回数の受入テストを行う必要があり、各自治体の推進スケジュールによってテスト計画は異なる。
この受入テストは、テスト評価会議が主体となって必要となるテスト実施 TF を統合して実データを扱うことによって実施される。サービス基盤およびその上での新業務ユニットの稼動について地域情報プラットフォーム推進会議に対して実演し、業務要件の充足や作業時の使い易さなどについての検証・評価を示す。この際、現データベース、現システムデータの切り替えには、現行システム担当者・移行改修業者との連絡・調整を行ったうえで実施する。さらに、旧システム稼動場所と新システム稼動場所が異なる場合は両方の環境が形成されている状況でテストして検証・評価を示す。
以上の検証評価方法については予め地域情報プラットフォーム推進会議に了承を得た方法を使い、問題・課題の管理方法についても予め決めておき、地域情報プラットフォーム推進会議の決定を受けておく。
・受入れテスト計画書（見直し）の作成
・受入れテストシナリオの作成－ 37 －

地域情報プラットフォームガイドライン

・受入れテストデータ（実データ）の準備
・受入れテストの実行環境構築
・受入れテストの実施
・移行データやシステム関連文書等、ソフトウェア以外の成果物のテスト・受入れテストの評価報告書の作成
・その他調整作業（ユーザのテスト参加等）－ 38 －