浦添市 第六次総合行政システム構築委託事業 ― 企画提案基本仕様書 ―

浦添市
第六次総合行政システム構築委託事業
―
企画提案基本仕様書
平成27年1月9日
浦添市
企画部情報政策課
―
1.システム更新の趣旨
浦添市で現在稼働している基幹系業務システムは、平成21年3月のシステム更新に伴い導入
した総合的な自治体情報システムでありその対象範囲は多岐にわたるが、番号制度等の法改正度
等の大規模法改正を対応するにあたり、より機能性に優れたシステムへと更新を行う必要が生じ
ている。
更新に際しては、今後更なる事務効率の改善、住民サービスの向上を図るべく、他市町村にて
稼働する最新パッケージシステムを含めた検討、導入を行うものである。そして、システムに合
わせた運用形態とすることにより、高止まりしているシステム運用・改修などの総合的経費を削
減し、将来にわたり高度な住民サービスの提供が可能となるよう、業務改革への布石とする。
また、更新においては、短期間での確実なシステム構築、データ移行を実現し、現状と同様以
上の高い信頼性(機能、安定性、セキュリティ)の確保が最低条件となる。
そのため、本システム更新においては、以下の事項を達成することを目標とする。
(1) 運用形態の改善
・ 最新パッケージシステムの導入による業務の見直しを行い、運用形態の改善を図ること
で、高度な住民サービスの提供を可能とする。
(2) スムーズな更新
・ 住民サービスに支障を来たすことなく、各課職員の負荷を極力抑制したスムーズな更
新を行う。
(3) 安定性、確実性の確保
・ 更新後のシステムにおいてもシステムダウン等のトラブルによる業務停止の無い高レ
ベルのサービスが安定的に供給できるシステムであること。
・ 現行システム以上に安定性、確実性の確保を考慮し、構築に際し発生するデータ移行
を確実に実施する。
(4) 安全性の確保
・ 基幹系システムに蓄積された各種情報は、適切な住民サービスを提供する上で不可欠
な最重要データとなっている。システム構築に際してのセキュリティを充分考慮し、
稼動後においても個人情報保護をはじめとするセキュリティ面においてルールに基づ
いた厳重な管理を行ない、安全に利用できるシステムであることが必要不可欠となる。
(5) 長期的な費用対効果の追及
・ 導入時の初期経費のみではなく、法改正等によるシステム改修費、保守サポート料、
バージョンアップ経費、職員の人件費等、長期的な運用コストも含めた TCO 削減を追
及した効率的な更新・導入を行う。
2.更新システムの基本要件
システム更新に際しては、システムのレベルダウンは極力避け、住民サービスに支障をきたす
ことなく、短期間にかつ安全確実なシステム更新を行う必要がある。
また、更新システムの基本要件として、財団法人全国地域情報化推進協会の成果物である地域
情報プラットフォーム標準仕様書に準拠していることを前提とする。
(1) システム構成/形態
・ 更新システムは、同等規模自治体での充分な稼働実績を有した、電子自治体や電子政
府への対応が可能な WEB システム構成(論理構成)とし、各業務システムが有機的に
連動したデータベース構造により可能な限り一元管理を行なうこと。
・ 地域情報プラットフォーム標準仕様書に準拠していること。もしくは地域情報プラッ
トフォームの同様の概念を持ち、各業務システムとシームレスな連携が実現できるこ
と。
・ 一般的に Web システムやリッチクライアントシステム等のように、クライアント側へ
特殊な専用ソフトウェアを必要としないこと。
・ 稼働環境がオープン系システム(Windows や Linux 等の OS で構築されたシステム)を
基盤に構築されていること。
・ システム構築にあたっては、既存の機器(クライアント、ネットワーク)等を最大限
に利用し、経費節減を図ること。
(2) システム開発・導入
① 前提事項
・ 本市と同等規模以上の自治体において、稼働実績を有していること。
・ 将来的にクラウドを利用したシステム構築の可能性もあるため、クラウド型システム
に対応できるパッケージシステムの導入を条件とする。
・ 同等規模自治体での豊富な開発・導入実績を有する経験豊富な業務 SE を確保し、原課
職員への詳細説明や協議ができること。
・ 定められた期間内に確実な稼働、引渡しができ、職員に対しシステム操作説明の教育
研修を行い、本稼働までに各業務の操作マニュアル及び管理運用マニュアルを完備す
ること。
② 作業体制
本システム更新においては、以下の役割を持つメンバーを配置すること。
・ プロジェクト管理責任者(プロジェクトマネージャー)
本市との総合窓口となり、受託業者におけるプロジェクト管理を行う者であり、本業
務に関わる業務従事者及び関係者全てを統括するとともに、本契約に定める全ての交
渉、作業及び成果物の管理を行うこと。
・ 品質管理責任者
プロジェクトの全工程において、品質のチェックを行い、成果物の適切な品質を維持
する者。
・ セキュリティ管理責任者
プロジェクトにおける情報セキュリティに関する指針・手順を定め、実際にセキュリ
ティに関する手順が遵守されているかをチェックし、セキュリティの管理を行う者。
・ パッケージ適用責任者(担当SEのリーダー)
本市各業務担当課との窓口となり、業務パッケージ毎に、要件定義書に則り再構築作
業及び運用作業の管理を行う者。
※ 上記のメンバーは、類似業務を経験し、当該の役割を担う上で必要な業務実績を
有する者を優先的に配置すること。
(3) システム規模
・ 更新システムのシステム規模は、現行システム規模と同等のクライアント数250台
とし、全てのクライアントからの同時アクセス数は、最大50台を想定している。
・ 庁内 LAN 及び WAN については、現行ネットワークを利用する。
(4) 処理方式
・ 原課主体型の処理方式とし、各課係に権限付与したクライアント端末から必要な業務
について直接的にオンライン処理業務(照会・入力・出力)が可能であること。
・ 大量入出力などのバッチ処理業務については、処理量に応じ、効率的な運用が可能で
あること。
・ トランザクションについて、バッチ処理の実行の有無に関わらず、以下のレスポンス
を目標とすること。
画面表示:3 秒、 更新:5 秒、 印刷:開始まで 5 秒、
単一検索(単一テーブル
の検索)
:5 秒、 集計検索(複数テーブルの検索)
:30 秒
(5) 各業務システム要件(共通要件)
・ 各業務システムの基本要件については、
「システム機能要望書」を参照すること。パッ
ケージシステムの導入を基本とするが、システム機能要望書に記載した内容について
はカスタマイズの要否等を記述すること。各業務システムの基本要件は、財団法人全
国地域情報化推進協会の成果物である地域情報プラットフォーム標準仕様書の機能一
覧を基に定めているため、標準機能として対応していることを前提とする。
・ 原則カスタマイズは行わず、パッケージシステムにて稼働できること。
・ 総合窓口、総合収納に対応することを考慮されたシステムであり、当市同規模自治体
において、総合窓口・総合収納の稼働実績があること。
・ 当市の窓口形態に合わせた、総合窓口システムが導入可能なこと。
・ 総合証明発行機能、総合照会機能、窓口案内(案内文書)作成機能を装備しているこ
と。
・ 証明書自動交付機及びコンビニ交付による証明書発行に対応できること。
・ 番号制度に対応したシステムであること。
① 各システムの統一性
・ 各業務システムは、画面構成・システム毎の起動やキー操作等・履歴管理などの仕組
みが統一されていること。
・ 各課へ配置する端末から原課の担当者が直接、照会・入出力できるシステムとし、原
課クライアントからデータ照会・検索および帳票の出力などタイムリーに処理できる
システムであること。
・ 全てのシステムにおいて、業務画面より参照可能なヘルプ機能(電子マニュアル)を
有すること。
・ バッチ処理業務については、業務システム毎に定例的なバッチ処理が可能であり、日
次、月次処理のスケジュールの自動化が可能なこと。
・ 業務メニューに EUC 機能が用意されており、各種業務データより切り出し編集を行い
エクセルなどに展開し活用できること。ただし、セキュリティシステムにより操作部
署が限定できること。
・ 添付書類の管理が必要な業務については、添付資料等のイメージ管理を行うことがで
きること。
② 入出力処理
・ 入力処理の効率化を考慮したシステムであること。
・ 出力帳票は、印刷前にプレビューにて確認が可能なこと。
・ 出力帳票は、原則A版を基本とし、可能な限りA4版化を図ること。
・ 認証印は、電子公印対応可能なこと。
・ 出力帳票の印刷は、外部委託に柔軟に対応できるようイメージ(PDF 等)で出力でき
ること。
③ セキュリティ
・ 個人情報の保護のため必要なパスワード等の認証技術を用いて、万全なセキュリティ
対策を講じること。
・ 業務利用の権限管理が可能な、業務システム全体を管理するセキュリティシステムを
保有し、データに対する不当なアクセスからの保護ができること。
・ 基幹業務システムの運用開始後のセキュリティリスクの見直し(セキュリティホール
や脆弱性、新たな脅威の調査等)は、セキュリティに関するイベントの発生時(ウィ
ルス感染、不正侵入、DoS 攻撃、情報漏えいなどの情報システムに関するインシデン
トが発生した時のこと)を含め、万全なセキュリティ構成を保つ必要が生じた場合に
実施すること。
・ 基幹業務システムの運用開始後のセキュリティリスクの見直し範囲は、基幹業務シス
テム全体とし、セキュリティリスクの対応範囲は、洗い出した脅威全体とすること。
・ 本業務で納品される機器、ソフトウェアの各種ログ(端末を除く)を確実に記録し、
万一事故が発生した場合に追跡のための基礎情報として利用可能とすること。取得対
象のログは、不正な操作等を検出するためのログイン/ログアウト履歴(成功/失敗)
、
操作ログ(アクセスログ含む)等とすること。また、ログへのアクセスは管理者のみ
に限定すること。
・ 基幹業務システムの各種ログの保管期間は、5年とすること。また、保管期間を満了
していないログを、DVD-R 等の一般の PC で読み込み可能なメディアに保存し、本市の
要求に応じて参照できるようにすること。
・ 基幹業務システムのマルウェア対策実施範囲は、基幹業務システム全体とすること。
④ データ連携
・ 全てのデータにおいて一元管理を行うとともに、重複登録を排除すること。また、各
業務システム間は、相互にデータ連携を行い、常に最新のデータを利用すること。導
入システムは、住基業務・税務業務・福祉業務など各業務間における有機的なデータ
連携が図られ、データの安全な一元管理が可能であり、データの重複登録や入力漏れ
および同期ずれを防ぐことができること。
・ 他システム(他事業者が有するものも含む)とのデータ連携機能の開発費を抑えられ
るように、業務パッケージシステムのインタフェース仕様には、Unicode、CSV、TSV、
固定長レコード等簡素で使用実績が多く安定した規格を用いること。
・ 他システムのインタフェース仕様書に準拠して提供可能であること。
NO
システム名
連携周期
連携データ
1
住基ネット
随時
住基
2
戸籍管理
随時
住基
3
住基・固定、市民税、軽自
滞納管理
日時、年次
動車税、国保税、法人税、
宛名、総合収納、法人収納
4
介護保険システム
随時、日時、月次、年
次
住基、市民税
備考
5
後期高齢システム
日時、月次、年次
住基、市民税
6
子ども子育て支援
日時、月次、年次
住基、市民税
7
ケアシティ
日時
住基
8
住基(印鑑含む)
・固定、市
証明書自動交付機
随時
民税、軽自動車税、国保税、
総合収納
※上記は現行の基幹系システムと自動的に連携を行っているシステムの一覧です。データ連携に
ついては、システム機能要望書のデータ連携・取込・出力も参照すること。
⑤ 過年度・履歴管理
・ 年度を指定することで、現年・過年度を意識することなく該当データを照会・出力す
ることができ、すべての業務において最新のみでなく、過去の履歴データも管理され
経年的データの照会ができること。
⑥ バックアップ機能
・ バックアップデータは、ユーザエラー(管理者の作業ミスなど)によって発生したデ
ータ損失等に利用すること。
・ バックアップ処理については、業務システム毎に行わず、各サーバの一括バックアッ
プが可能なストレージシステムを構築し、自動運転による一元管理が可能なこと。
・ テープバックアップは日次で取得すること。
・ テープバックアップの保存期間は一週間とすること。
・ 過年度データの保管期間は、各業務の法制度に準拠すること。
3.更新システムの対象範囲
更新システムの対象範囲については、下表及び別添「システム機能要望書」を参照すること。
NO
システム名
1
住民基本台帳
2
印鑑登録
3
カード登録
4
国民年金
5
軽自動車税
6
個人住民税
7
市民税(証明)
8
法人市民税
9
固定資産税
10
総合収納
11
宛名管理(送付先・口座管理等)
12
返戻管理
13
高齢福祉
14
支援給付
15
障害者福祉
16
生活保護
17
こども医療費助成
18
児童手当(子ども手当)
19
児童扶養手当(特別児童扶養手当)
20
母子及び父子家庭等医療費助成
21
包括的支援・救急医療情報キット配布等
22
国民健康保険
23
健康管理
24
就学援助・学齢簿
25
選挙人名簿等
26
住居表示
4.移行要件
データ移行は、システム更新時における最重要課題であり、安全かつ確実な対応が必須となる。
本システム更新においては、以下を基本方針として確実な対応を行う。
(1) システム移行要件
① システム移行の手法
・ 基幹業務システムの移行順序及び詳細な時期等は、別途協議を行うこと。
・ 基幹業務システムの設備・機器は、本業務で新設するため、現行システムの設備・機
器の移行は行わない。
② セキュリティ
・ 移行に伴う現行システムの停止可能時間は、夜間などの利用の少ない時間帯とするこ
と。
・ 移行中のトラブル発生に備えて、トラブル発生時の対応体制と対応プランを策定する
こと。
③ システム移行のリハーサル
・ 移行のリハーサルにあたっては、事前に「システム移行計画書」を作成・提出し、当
市の了承を得たうえで実施すること。
・ 移行のリハーサル範囲は、全ての正常ケースとすること。
・ 移行のリハーサルにおいては、本番データを使用し、1回以上実施すること。
・ 移行のリハーサルにおいては、外部連携リハーサルも実施すること。
(2) データ移行要件
① データ移行の手法
・ 更新システムへのデータ移行(取込)については、構築業者が主体となり確実な移行
を行うこと。
・ 受け渡しの際のデータ仕様(ファイルレイアウト、コード表、確認資料他)について
は、当市と構築業者が調整し仕様を決定するものとする。構築業者は提供されたデー
タについて分析を行い、更新システムに対してデータ変換及びデータセットを行うこ
と。
・ データ移行にあたっては、事前に「データ移行実施計画書」及び「検証計画書」を作
成・提出し、当市の了承を得たうえで実施すること。
・ 移行用データとして、現行システムからテスト用 2 回、本番用 1 回を提供する。デー
タベースレイアウト、コード表及びその他必要なデータについては随時提供する。な
お、これらの移行用データを使って、次期システムのデータベースレイアウトに変換
してセットアップすること。
② 移行対象業務と範囲
・ 現行システムにて保有するデータは、原則、履歴も含め全てのデータについて移行を
行うこと。なお、移行データの対象範囲は、更新対象範囲内の業務データとする。
③ セキュリティ
・ データを安全に移行し、移行後の運用に問題がないよう配慮すること。また、移行時
には安全確保のための十分な検査方法を示し、当市の検査を受けること。
・ データ移行を実施する際の作業場所は、当市電算サーバルームもしくは構築業者のオ
フィス内に限定し許可するものとし、データの授受運搬については、施錠できる専用
ケースを用意し、セキュリティを考慮した運送を行うこと。
・ 構築業者は、データ保管に際し、セキュリティが考慮された保管室または保管庫等に
保管するなど適正に管理し、適宜本市職員により検査を実施する。
④ 移行後の確認及び追い異動
・ データ移行後の最終結果確認は、当市職員が責任をもって実施する。構築業者は、正
確かつ迅速な移行が行えるよう協力すること。
・ データ移行後に発生する追い異動や並行異動、不足項目のデータ登録については、本
市にて実施する。またそれに伴うスケジュールは、原課職員の作業負荷の軽減を極力
考慮したスケジュールを提案すること。
5.検証要件
限られた期間の中で安全かつ確実なシステム更新を行うため、システム利用開始までに入念な
検証を実施し、利用開始後の安定稼動を確保すること。
(1) 検証要件
・ 検証に当たっては、事前に「システム検証実施計画書」を作成・提出し、当市の了承
を得たうえで実施すること。また、結果を「システム検証結果報告書」としてまとめ、
提出すること。
・ 当市が、検証結果から構築したシステムが本業務仕様に適合しないと認めるときは、
速やかにシステムの修正を行うこと。
・ システムの利用開始前に十分な検証期間を確保し、信頼性の確認を行うこと。
・ 利用開始後であっても、検証不足と合理的に認められる場合には、必要な検証を実施
すること。またその結果、システムが本業務仕様に適合しない事実が発見されたとき
は、速やかにシステムの修正を行うこと。但し、システム修正にあたっては、稼働中
のシステムの運用保守に最も影響の少ない方法をもって実施しなければならない。
6.更新機器
更新機器については、本仕様書に記載した事項を踏まえ、構築業者が提案する機器構成を基本
とするが、データ量の増加や法改正対応によるシステム資産の増大等などを考慮した上で、内部
増設が可能であり、導入後最低 5 年間は利用可能なスペックの機器構成とする。
下表は、当市の想定する機器スペックである。
項目
スペック等
数量など
サーバ機器
基本構成は提案システムがストレス無く安定的に稼働するために必要
必要数
なサーバ構成とし、以下の要件を満たすこと。
形状
ラックマウントタイプ構成とし、必要数ラックを見積
もること。
構成
DB・AP 他根幹を成す主要サーバについては複数台に
よる冗長構成とする。
CPU
2.0GHZ 以上、マルチコア
HDD
RAID を構成し、活性保守が可能なこと。将来的なデ
ータ増に対して充分な容量を確保し、拡張が可能なこ
と。
メモリ
同時接続クライアント数(50台)を見込み充分な容
量とすること。
UPS
必要台数 UPS を構成し、各サーバ機器は UPS 接続によ
り電源管理が可能なこと。
自動運転
電源投入・切断はスケジュール機能等で自動処理が可
能であること。
電源ユニット
電源ユニットは冗長構成とすること。
LAN
1GBまたは100MBで2枚以上装着による冗長
構成とする。
ストレージ
各サーバの一括バップアップを可能とするストレージシステムを構築
1式
すること。
検証用機器
管理端末
1式
電算室へ設置する運用管理クライアント。機器の性能については、
必要台数
窓口用端末と同程度とし、提案システムを運用するために必要な台
数や機能を有すること。
印鑑登録スキャナ
解像度 600Dpi 以上
2台
ネットワークスイッチ
サーバ結線用のコアスイッチ、冗長構成とすること。
必要台数
バーコードリーダ
住基ネット関連
必要台数
継続利用のため連携を行うこと。
必要構成数
連携に必要な FW、中間サーバを構成すること。
その他
提案システムで必要な機器を明記し、構成に含むこと。
必要数
7.保守について
システム更新後、安定したシステム運用を維持し、ソフトウェアの不具合やハードウェア障害、
法制度改正に伴うシステム改修に迅速に対応できること。
(1) ソフトウェア保守
・ すべての業務システムを対象とし、障害発生時の切り分け等、迅速に対応すること。
・ システム変更時には事前に検証機等で十分に検証を行うこと。
(2) ハードウェア保守
・ 保守対象機器は障害発生時の受付、切り分け、修理等、迅速に対応すること。
・ ハードウェアの保守対応については、原則として当日オンサイト保守での対応とする
こと。
・ システム導入当初の OS、ミドルウェア等のバージョンに係るサポート期間がシステム
稼働期間中に終了した際には、新たなバージョンに迅速かつ円滑に対応し、移行する
こと。なお、システム稼動期間中において、問題なくサポートを受けられる製品を選
択すること。
(3) 運用に関するサポート
・ システム(操作等)に関する問い合わせは、基本平日 8 時 30 分~17 時 15 分の業務時
間内とし、迅速に対応すること。
・ 必要に応じ、バージョンアップ等により、機能強化を図ること。
・ 法制度改正等の対応は、本業務の範囲内で行い、特別な対応費用が発生しないこと。
但し、大規模法制度改正はこの限りではない。
・ 法改正対応・個別対応に伴いシステムのバージョンアップを実施した場合も、システ
ムサポート料が増加しないこと。
※
ここでいう「大規模法制度改正」とは、法制度の新設あるいは抜本的な改正に伴
い、通常のバージョンアップでは更新が実施できない程度の大幅な変更が必要で
あると合理的に判断される場合、及び全国的に補助金・交付金等が支給される改
正に限ることとし、その場合の対応は、最も費用縮減が図れる手法を選択し、更
に同規模団体における事例を考慮して決定する。
8.構築スケジュール
平成 27 年 4 月構築開始から平成 28 年 12 月切替として、全体スケジュールを提示すること。な
お、当市が現在想定している構築スケジュールは下表の通りである。
4
5
6
7
平成27年度
8
9
10
11
12
1
2
3
4
5
平成28年度
6
7
8
9
10
11
12
計画
システム構築
スケジュール
要件定義・設計
▲本稼働
構築・運用・テスト
9.その他
(1) データの提出
・ 本契約満了後、基幹系業務を別システム(自社・他社問わず)で稼働することとなっ
た場合には、本業務で導入するシステムに本市が入力したデータ、そのデータを基に
行った計算結果など、移行データ及びそれらの提供用データレイアウト等新システム
へのデータ移行作業に必要となる資料について、本市が提出を求めた場合は無償で提
出すること。また、提出したデータ等への本市からの問合せには、その依頼日(依頼
日は本契約期間内とする)から1年間無償で対応すること。
(2) 瑕疵担保責任
・ ソフトウェア等の納入物に対し検出された瑕疵を、1年間にわたって、無償で修正し
なければならない。但し、本市職員のオペレーションに依らない不具合が発見された
場合には、瑕疵担保期間外であっても、無償で修正すること。なお、瑕疵を修正する
に当たって、運用中の業務に影響を与えないこと。
(3)他システムの導入
・ 今回の構築に含まれていないシステム(介護保険、後期高齢者医療、子ども子育て支
援、証明書自動交付機、コンビニ証明書交付)の追加導入に対応できること。
10. 評価対象と配点
審査点は 3,091 点(満点)とし、機能及び提案審査評価点を 2,091 点、価格点を 1,000 点とし
評価を行う。ただし、当市が定める提案上限額×70%を評価下限額とし、提案額がこれを下回る
場合は価格点を一律 1,000 点とする。
※価格点=1,000×(最低提案価格/当該提案価格)
※複数の評価委員が評価する項目については、合計点を評価委員数で除した平均値とする。
11. 失格判定基準及び一次審査
当市による審議の結果、提案書、導入スケジュールの内容について、実現性の低い提案と判断
されたものは、失格になることがあるので留意すること。また、審議の結果、一次審査を合格し
た場合のみ二次審査(システムのデモンストレーション等)を行うこともあるので留意すること。