|
|
|
|
|
(2) 全省庁共通の人事・給与システムへの移行【給与計算業務】
各府省情報化統括責任者(CIO)連絡会議において、政府全体の方針として「電子政府構築計画」(2003年(平成15年)7月17日決定、2004年(平成16年)6月14日一部改定)が決定され、この中で「システムの見直しのための警察庁行動計画(アクション・プログラム)」(以下「アクションプログラム」という。)が策定されたところである。
警察庁においては、アクションプログラムに従い保有する「運転者管理等のシステム」、「全国的情報処理センター用システム」及び「指紋業務用システム」の各々に関して更なるシステム経費の削減等の刷新可能性調査を行う。
システム経費等の削減の調査に当たり、システム関連業務分析、現状システムの概要分析、現状システムを踏まえた関連システム技術整理、オープンシステム化の可能性の検証及び再構築の方向性検討、必要な機器(ソフトウェアを含む。)の費用算定方法の妥当性及び費用対効果等について検討を実施する。
本調査は、平成17年度に予定される業務・システム最適化計画策定のための予備調査として位置付けられており、「運転者管理等のシステム」(以下「本システム」という。)を新たなシステムに刷新した場合に、使用者及び利用者の利便性を損なわず、またシステムの安全性、機密性の確保及び信頼性の維持にも配慮しつつ、トータルコストを削減できるか否か、システムの刷新方法も含めて検討し、結論を得ることを目的とする。
本調査の対象範囲は、本システムの中心であるメインフレーム[1]及び都道府県警察設置の端末装置とする。
警察庁全体で共有している共用ネットワーク、及び都道府県警察で個別に維持管理している都道府県警察電子計算機等は対象範囲外とする。
図 1 本調査の対象範囲
警察庁情報処理センター(以下「情報処理センター」という。)に設置している汎用電子計算機を中枢として、全国規模の情報処理を行っており、次の3つに大別できる。
全国の運転者に関する情報を一元的に管理し、都道府県警察の運転免許センター等からの照会、登録に応じるシステムである。
全国の運転免許保有者数は、図 2 運転免許保有者数の推移に示すように年々増加し続けている。このような多数の免許事務を迅速正確に行うために、都道府県警察の電子計算機と相互接続することによって、効率的な運転者管理業務を行っている。
図 2 運転免許保有者数の推移
警察行政を支援するためのシステムで、登録照会業務、管理業務及び統計業務を行っている。
警察事務の効率化を図るシステムである。
本調査で対象とする業務を、表 1 運転者管理等のシステム 対象業務一覧に示す。
No. |
分類 |
業務名 |
1 |
運転者管理システム |
運転者管理業務 |
2 |
行政情報管理システム |
古物営業管理業務 他10業務 |
3 |
事務管理システム |
車両管理業務及び給与計算業務 |
本システムは、情報処理センターに設置されたメインフレームと都道府県警察本部に設置された端末装置等からなる全国規模のシステムである。
図 3 本システムを取り巻くシステム全体構成
メインフレームは帳票編集・印刷機能、DB処理機能等を有し、運転者管理業務等を実装する。
また、端末装置等は利用プロトコルとしてTCP/IPを利用したオープン系端末、プリンタ等を利用している。
なお、運用管理に関しては、情報処理センター内の他システムの統合運用サーバを利用して実施している。
本システムのメインフレームは、基幹業務の高可用性・高性能等の要件に耐え得る中大型クラスの機器を導入している。
また、都道府県警察本部等に設置する端末装置としてPC/AT互換機等のパソコンを導入している。
図 4 情報処理センターにおけるハードウェア構成
なお、メインフレームにおいて要求される性能及び可用性等を実現するための特徴として以下の点が挙げられる。
・ トランザクション負荷分散機能によるCPU負荷の分散
・ 装置の二重化による高信頼性
・ 電子ディスク装置の利用による高速化
・ ディスクアレイ装置又はRAID方式(ストレージ信頼技術)による冗長構成
・ 自動運転制御及びシステム運用監視による運用負荷の軽減
・ ディスク障害時における媒体復旧処理の自動化
本システムのメインフレームは、OS上に汎用DBMS及び警察庁独自仕様のDBMS並びに業務プログラムを実装している。
また、端末装置にはWindows系OSに警察庁独自開発の業務プログラムを実装している。
図 5 メインフレーム及び端末装置におけるソフトウェア構成
各システムのプログラム及びデータ規模は表 2 各システムのプログラム及びデータ規模のとおりである。
全データ量約110GBのうち、80%以上を運転者管理システムが占める。
表 2 各システムのプログラム及びデータ規模
No. |
分類 |
プログラム規模 |
データ容量 (MB) |
|
ステップ数 |
本数 |
|||
1 |
運転者管理システム |
480,000 |
2,244 |
95,437 |
2 |
行政情報管理システム |
899,000 |
3,283 |
16,456 |
3 |
事務管理システム |
175,000 |
329 |
376 |
合計 |
|
1,554,000 |
5,856 |
112,269 |
本システムは、警察庁の共用ネットワークを介して、全国の都道府県警察本部及び運転免許センターに設置されている端末装置と接続している。
表 3 接続端末及びプリンタ一覧
種別 |
端末装置設置数 |
プリンタ設置数 |
端末装置 |
157 |
131 |
このほか、本調査の範囲外であるが、各都道府県警察本部に設置されている計47台の都道府県警察電子計算機と接続している。
なお、本システムの利用実態としては、都道府県警察電子計算機経由の利用の方が、端末装置からの利用よりも多い。
本システムにおけるトランザクション件数の状況は表 4 トランザクション件数のとおりである。
運転者管理システムで全体の約90%を占めている。
表 4 トランザクション件数
No. |
分類 |
1時間当たりの トランザクション 件数 |
1 |
運転者管理システム |
22,400 |
2 |
行政情報管理システム |
2,580 |
3 |
事務管理システム |
8 |
本システムの平成15年度の運用コストは、メインフレーム及び端末の電算借料が全体の運用コスト[2]の99%を占めるコスト構成となる。電算借料以外の既定経費等(消耗品等システム運用にかかる経費及び一時経費)は全体の運用コストの1%である。
表 5 運用コスト構成(平成15年度)
(単位:百万円)
内訳 |
運用コスト |
電算借料 |
1,433 |
既定経費等 |
11 |
合計 |
1,444 |
図 6 運用コスト割合(平成15年度)
平成6年から平成15年度までの過去10年間における運用コストは、システム更改ごとに運用コスト削減効果が見られ減少傾向にある。
表 6 運用コスト推移
(単位:百万円)
内訳 |
年度 |
|||||||||
H6 |
H7 |
H8 |
H9 |
H10 |
H11 |
H12 |
H13 |
H14 |
H15 |
|
電算借料 |
1,706 |
1,587 |
1,568 |
1,615 |
1,668 |
1,678 |
1,482 |
1,482 |
1,482 |
1,433 |
既定経費等 |
93 |
43 |
25 |
26 |
62 |
39 |
19 |
19 |
17 |
11 |
合計 |
1,799 |
1,630 |
1,593 |
1,641 |
1,730 |
1,717 |
1,501 |
1,501 |
1,499 |
1,444 |
図 7 運用コスト推移
運用コスト算定時の見積算定方法等については以下のとおりである。
・ 機器の老朽化及び機能追加による機器増設等のシステム更改に当たり、現行機器の稼働率及びピーク時利用率、将来想定されるシステム拡張、性能、価格性能比等を総合的に判断し、運用コストを導き出している。
・ 過去のシステム構築及び運用コスト算出の経緯、運用コスト実績を勘案し、次年度の運用コスト算出を行っている。
今後は、比較的類似しているシステムの運用コスト、市場価格に関する調査及び複数ベンダからの見積取得等を適宜実施し、一層のコスト削減に向けた継続的な取組みが必要である。
本システムで検討又は予定されている新たなサービスは、次のとおりである。
現在、運転者管理業務においては、運転免許証の交付の際、漢字及び写真データの確認を、免許台帳等により手作業で行っているのが現状であり、運転免許証交付の業務に関して非効率的な状態となっている。
上記のような背景を踏まえ、漢字及び写真データの保有について検討が予定されている。
本システムで漢字及び写真データを持つことにより、免許発行業務の処理作業効率化を図るものである。
漢字及び写真データの保有に当たり、現時点で明らかになっている課題には、次のようなものがある。
・ 外字の取扱い
・ 各都道府県のコード体系の統一
・ JISとの整合性の確保
・ データ量増加に伴うディスク増設
・ 画像情報を取り入れるためのディスク増設
・ データの記録方法及び記録形式の検討
・ 画像処理用システムの整備
現在、本システムで処理している警察庁の給与計算業務に関しては、人事院等が構築する「人事・給与関連業務情報システム」に移行する予定である。
本システムは、対象とする業務及びデータの特殊性により、国内に類似する事例は存在しない。
一般的なオープン化に関する対象事象、方策等は表 7 オープン化対象事象と方策例のとおりである。
オープン化対象事象 |
方策例 |
メインフレーム |
・ オープン系プラットフォーム(サーバ、OS、DBMS等)の導入 ・ 業務パッケージソフトの導入 |
端末 |
・ オープン系端末の導入 ・ 業務パッケージソフトの導入 |
ネットワーク |
・ 標準プロトコル(TCP/IP)の利用 ・ 標準的なネットワーク機器の導入 ・ 各種回線サービスの導入 |
本システムでは、端末は既にWindows系端末を導入していること、ネットワークは、標準プロトコルを採用していることからメインフレームのオープン化を対象範囲として検討する。
本システムの最適構成を検討するに当たり、信頼性、可用性等の観点からメインフレームとオープン系サーバ[3]の比較を行った。
表 8 メインフレームとオープン系サーバの比較
観点 |
メインフレーム |
オープン系サーバ |
比較優位 |
信頼性 可用性 |
基幹業務で培われた完成度の高いOSのため信頼性が高い |
OSのバージョンアップが繰り返されOSとしての完成度は発展途上 |
メインフレーム |
構成するコンポーネントが集約されているため、障害の発生要因は少ない |
性能と信頼性の向上を目指すハードウェア及びミドルウェアの冗長化が必要で、障害発生要因が増加 |
||
故障検出機能が充実しているため、障害に強いハードウェアによる高可用性を実現 |
冗長化等により高可用性は実現可能であるが、チューニングや整合性の事前調査が必要 |
||
OLTP、DBMS、ファイルシステム等において、OSレベルで統一的なリカバリ機能を提供 |
OLTP、DBMSのミドルウェアごとに個別にリカバリ機能が提供されているため、統一的なリカバリ方式について詳細設計が必要 |
||
性能 |
データIOや通信等の専用機器を構成できるため、バッチ処理等大量データ処理に強い |
高性能なハードウェア及び分散構成をとることでメインフレームを凌ぐ性能を実現可能である(バッチ処理で分散処理が出来ない場合は劣る) |
メインフレーム |
メインフレーム、オープン系とも単一処理はCPU性能に依存するが、汎用機OSは資源配分の最適化を目標として進化してきたため、安定的なレスポンスが期待できる |
オープン系OSは資源配分のバランス調整が適切に出来ていないため、トラフィックが増大するとレスポンスタイムが極端に悪化する場合がある |
||
機密性 |
各ベンダ固有のOSであり技術情報が公開されていないため、情報が漏洩しにくい |
OSの技術情報が公開されているため、セキュリティホールに対する攻撃を受けやすい |
メインフレーム |
柔軟性 拡張性 |
1台のメインフレームで多様な役割を担うため、負荷が集中しやすく、きめ細かなチューニングが必要 |
個々の業務要件に応じた構成を組むことが可能であり、業務変更、新規業務追加等に柔軟に対応可能 |
オープン系サーバ |
オープン系に比べオープン環境で導入された最新技術の導入にタイムラグが発生する |
Webサービス等の最新技術については、オープン系から成熟するため、最新技術の早期導入が可能 |
||
運用性 保守性 |
あらゆる機能を一箇所に集中しているため、運用管理が容易 |
分散システムの形態をとる場合、全体としての管理が煩雑になり、管理に必要な労力が大きい |
メインフレーム |
ハードウェア、ソフトウェア共に同じ製造元の製品であり迅速なサポートが可能 |
ハードウェア、OS、ミドルウェア、アプリケーションの提供ベンダが異なり、原因の特定や問題解決までに時間がかかることがある |
||
運用操作はコマンドラインが基本であり、コマンド投入ミス、入力タイムラグは発生するおそれがある |
GUI操作を実現した統合監視製品等が充実しており、オペレーションミスが少ない |
オープン系サーバ |
|
ネットワーク変更、及び機器増設の際はハードウェアの構成定義を変更する作業が発生し、システム停止を伴う |
分散システムの形態をとることでハードウェア構成変更に対する影響を局所化することができる |
||
コスト |
ハードウェアについては、一般的にコストは高くなる
|
単体としてのハードウェアについては、一般的にコストは低くなる(ただし、メインフレーム系と同等以上の性能、可用性の実現を目指すとなると、様々なプロダクト、構成技術、新規アプリケーションが必要となり、これらのコストがメインフレームのコストを上回る可能性がある) |
オープン系サーバ |
メインフレーム製造元への依存度が高いため、調達先や選択肢の多様性は低い |
調達先や製品選択の選択肢の多様性は高い |
前述のメインフレームとオープン系サーバの比較のとおり、信頼性、性能、機密性を重視する場合はメインフレームが採用され、柔軟性、拡張性、コストを重視する場合はオープン系サーバが採用される傾向がある。
ここでは、メインフレームを全てオープン系サーバに置き換えた場合(パターンA)と参考値としてメインフレームを継続利用した場合(パターンB)のコスト試算を行った。
表 9 オープン化検討パターン
パターン |
パターンごとの特徴 |
パターンA |
メインフレームをオープン系サーバに置換え |
パターンB (参考情報) |
メインフレームを継続利用 |
メインフレームを全てオープン系サーバに置き換えるに当たり、メインフレームにて実装しているシステム論理階層ごとにサーバを分けて、完全オープン化のシステム構成とした。
表 10 システム論理階層
システム論理階層 |
特徴 |
Enterprise Application Integration※層 (EAI層) |
端末及び他システムとの接続機能をEAIサーバに実装し、1対N若しくはN対Nの接続環境に依存する対応を行う。APサーバ及びDBサーバ等に接続環境の変化の影響を与えない構造とする。 |
アプリケーション層 (AP層) |
業務機能の拡張、業務処理量の増加等、業務環境への変化の対応をAPサーバに集約する。業務処理増加時の対応は新業務APサーバの増加で対応する。 |
データベース層 (DB層) |
データベース機能を集約し、高可用性、高レスポンスを実現する。業務アプリケーションはDBサーバの切り替えを意識せずに構築が可能となる。 |
※ 業務に使用される複数のコンピュータシステムを有機的に連携させ、データやプロセスの効率的な統合をはかる一連の技術やソフトウェアの総称。組織内のシステム統合や電子商取引を行うためのシステム間連携の手段として利用される。
図 8 完全オープン化(パターンA)のシステム構成概要
パターンごとのオープン系サーバの機器構成は、メインフレームにて求められる性能等と同等の要件を満たす構成[4]を想定した。
オープン系サーバの機器等のリース期間は4年間、リース料率は2.4%とした。
オープン系サーバにおいて価格性能比の向上、競争調達の導入等による価格下落を想定し、機器及びソフトウェアを標準価格の3割減とした。また、機器及びソフトウェアの保守費用も同様に標準価格の3割減とした。
メインフレームに求められる可用性をオープン系サーバ等の機器で実現するため、機器構成の冗長化等の安全性、信頼性を高める技術の採用に加えて、可用性を維持するサービス(CE常駐サービス等)を追加し費用計上した。
メインフレームを継続利用する場合、メインフレームの価格下落により電算借料が1割低減することを想定してコスト試算を行った。
メインフレームを継続利用する場合(パターンB)、平成15年度のメインフレームの電算借料は13億2,600万円であるため、将来想定されるメインフレームの電算借料は、1割減じた11億9,300万円とした。
一時費用は、業務構築基盤の開発、運用環境の構築、運用設計等に関する費用を想定した。また、システム移行期間中の機器の設置期間を2年間とし、機器、ソフトウェア及び保守費用を一時費用に含めた。
なお、警察庁職員で実施する移行設計、移行作業等の費用は除外した。
システム更改後の機能追加及びシステム規模拡大等は実施されないことを前提とした。
施設費用、電源費用、通信回線関連費用及び運用支援費については、パターンごとに大きな差異はないとし、コスト試算からは除外した。
想定パターンごとのランニングコストは、メインフレームを全てオープン系サーバに置き換えた場合(パターンA)がメインフレームを継続利用した場合(パターンB)よりも低額になる。
表 11 ランニングコスト比較
(単位:百万円/年)
分類 |
オープン系 サーバ (パターンA) |
メインフレーム 継続利用 (パターンB) |
オープン系サーバ 機器・ソフト・保守費用 |
774 |
- |
オープン系サーバ 可用性維持サービス |
232 |
- |
メインフレーム 機器・ソフト・保守費用 |
- |
1,193 |
ランニングコスト合計 |
1,006 |
1,193 |
図 9 ランニングコスト比較
想定パターンごとの一時費用を以下に示す。メインフレームを全てオープン系サーバに置き換えた場合(パターンA)がメインフレームを継続して利用する場合(パターンB)に比べて大幅に費用を要する。
表 12 一時費用比較
(単位:百万円)
分類 |
オープン系 サーバ (パターンA) |
メインフレーム 継続利用 (パターンB) |
一時費用 |
2,848 |
153 |
図 10 一時費用比較
本システムのメインフレームをシステム論理階層ごとに全てオープン系サーバに置き換えた場合(パターンA)、メインフレームを継続利用した場合(パターンB)よりも1億8,700万円のコスト削減効果があり、ランニングコストは16%削減される。
本システムをメインフレームから全てオープン系サーバに置き換えた場合(パターンA)の一時費用は28億4,800万円である。
前述のランニングコストの削減額及びシステム更改時の一時費用より、メインフレームから全てオープン系サーバに置き換えた場合(パターンA)の一時費用の回収期間は15.2年となる。
前述したとおり、ランニングコストについては、すべてオープン系サーバに置き換えた場合(パターンA)の方が、メインフレームを継続利用する場合(パターンB)に比べて16%低くなる。
ただし、オープン系サーバへの置き換えには、可用性を高めるサービスを追加する必要性や、移行時の一時費用の精査等、実現可能性に関する諸問題が存在する。
したがって、機器・ソフトウェア及び保守費用等のコストの単純比較にとどまらず、システム移行期間、移行時期及び移行手法等における課題と合わせて総合的に判断する必要がある。
ここでは、こうした課題を次の5つの観点で整理分類する。これらの課題については、今後の最適化計画やシステム設計の中で引き続き詳細な検討が必要である。
今後、業務・システムの最適化を検討する上では、業務プロセスの見直しが必要である。現行のシステムにとらわれることなく、業務の流れや情報の流れ等を整理・分析し、あるべき業務プロセスを導き出すことが重要である。
オープン環境で情報資産の共有やシステム構築の効率化を図るためには、データ定義の標準化を促進することが望ましい。具体的には、各業務のデータ項目やシステム間連携のインタフェース仕様を整理した上で、データ項目定義及び連携インタフェースの標準化を検討することが必要となる。
現行システムにおいては、即時処理のほかに準即時処理や一括処理等が存在し、データ量、処理件数、処理の緊急度に応じた使い分けを行っている。業務の見直しに当たっては、バッチ処理を含め、新業務における最適な処理方式について検討を行う必要がある。
本システムでは厳しい性能要件を満足するために、警察庁独自仕様のDBMSを採用することにより、照会・更新処理の高速化を実現している。
本システムのオープン化に当たっては、現行の処理性能を実現できるか、十分な検証が必要となる。
オープン系プラットフォームでシステムを構築する場合、処理性能は同時に処理する業務の組合せやトランザクション特性に大きく依存する。性能設計のためには、各業務の処理フローを詳細化し機能単位で分類整理した上で、処理負荷を見積もることが重要である。また、設計値の検証を目的としたプロトタイプシステムの構築も検討する必要がある。
前述のとおり本システムは全国の警察で利用されていることから、高度な可用性が要求される。
オープン系プラットフォームで可用性を確保するためには、CPUやディスク、ファンといった各種装置・部品の冗長化構成をはじめとして、複数系統による電源確保等の可用性向上策を十分に検討する必要がある。
前述のとおり、本システムは取り扱う情報の特性から高度な機密性が要求される。機密性確保のための技術的アプローチとして、バイオメトリクス認証等をはじめ、最新の技術動向を踏まえた検討が必要である。
現在行っている他システム間連携について、本システムをオープン化した際の連携方式をはじめ、ファイルレイアウトや文字コード変換等、影響範囲の確認と対応策の検討が必要となる。
メインフレームシステムで最適化されたプログラムのオープン化手法については、主にリホスト[5]、リライト[6]、リビルド[7]の3つがある。
表 13 主なオープン化手法と一般的な特徴
手法 |
リホスト |
リライト |
リビルド |
システム構成の見直し(複雑さの改善、資産整理) |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
新サービスへの対応、他業務との連携(統合DB(データの一元化)、連携基盤の構築)) |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
法改正への対応 |
現状と変らない |
見直しが 可能 |
大幅な見直しが可能 |
経費(移行、開発経費) |
小 |
中 |
大 |
経費(運用経費(ハード、ソフト、運用保守委託) |
削減が可能 |
||
開発期間 |
小 |
中 |
大 |
運用体制(運用課、システム利用課) |
見直しが可能 |
||
業務改善(あるいは現行業務変更度など) |
現状と変らない |
見直しが可能 |
|
セキュリティの向上 |
検討が必要 |
||
SE問題 |
ある程度解決される |
解決される |
|
性能(信頼性、安定性など) |
検討が必要 |
このほか、メインフレームを存続させたままオープン環境での利用を可能とするエミュレーションやラッピング等の手法もある。
オープン化検討に当たっては、それぞれの手法の特徴やメリット・デメリットを十分に検討した上で、慎重に手法を選択する必要がある。
一般的に、長年利用してきた既存アプリケーションは内在する不具合の割合が少なく、動作信頼性が高いとされている。
手法の選択に当たっては、こうした傾向も踏まえた上で、これまで蓄積してきた既存資産の有効活用についても検討することが重要である。
新システムへの移行に当たっては、データ移行についても検討する必要がある。
データ移行の方式としては、デ-タ特性(データ量や更新頻度)、移行期間等を勘案し、最適な移行方式を決定する必要がある。
データ量が非常に多い場合、データ移行に相当の期間が必要となるが、移行期間中に更新が発生した場合、更新内容を移行データとして反映させる必要がある。したがって、新旧システムでの並行運用についても検討が必要となる。
新旧システムの並行稼動期間については、ハードウェア機器の設置スペースを二重に確保する必要がある。他システムのリプレース計画等にも十分配慮の上、情報処理センター内の機器設置計画を策定しなければならない。
また、本システムを利用する端末側にも新旧2つのシステムのインタフェースが必要となる。並行稼動環境の正系副系の取り決めや利用端末の制限等、並行稼動期間中の運用ルールとともに検討する必要がある。
オープン化によりハードウェアのコンポーネント数が増加し、それに伴って障害監視等の運用管理業務が煩雑となる可能性がある。
そこで、システムを統合して運用管理を行う仕組みが必要となる。統合運用管理ソフトの導入により、プラットフォームを意識しない運用管理の実現は可能であるが、効率的な運用管理を実現するためには、運用要件を整理した上で運用設計に反映させることが必要となる。
業務の新体系への移行やシステムの新プラットフォームへの移行により、運用面においては大幅な変更が発生する。
したがって運用体制を早期に整備し、運用に携わる警察庁職員の教育訓練を十分に行うことが必要となる。
オープン化の推進に当たっては、過渡的にメインフレームの保守運用に従事するCOBOL技術者と、新オープン系システムの保守運用に従事するJAVA等の技術者が混在する体制となる。
技術体系が大きく異なる2系統のシステムの保守運用に当たっては、経費の増大だけでなく、開発効率の低下や品質の劣化が懸念される。このような事態が生じないよう、保守運用体制の確保や開発標準の確立等について、慎重に検討を行う必要がある。
本システムでは業務の重要性により、可用性及び完全性の確保について検討が必要である。
解決策の一つとして、バックアップセンターの設置が考えられるが、その検討に当たっては以下のような課題がある。
・ バックアップセンターに整備するハードウェア機器の手配
・ 情報処理センターとバックアップセンター間の高速伝送回線の整備
・ バックアップセンターの維持経費、運用要員の確保
オープン化の検討及び推進に当たっては、専門性の高い知識を要する分野が存在する。こうした分野については、外部の専門家を積極的に活用し、効率的かつ効果的に計画を推進することが望ましい。
オープン化の推進に当たっては、「性能の確保」「可用性の確保」「機密性の確保」といった本システムの特徴に十分配慮した上で、可能な限り公平性及び透明性の向上を意識した入札による調達を行うことが望ましい。
情報処理センターに設置されているメインフレームをオープン化するに当たり、前項「2 オープン化に関する課題」の解決を図る必要がある。
今後策定される「最適化計画」においては、情報処理センターのメインフレームのオープン化のみならず、より高度な警察業務の実現も考慮された「効率的」且つ「効果的」なシステムの実現について検討されることが重要である。
[1] 官公庁及び企業の基幹業務システムなどに用いられる汎用大型コンピュータ。電源やCPU、記憶装置をはじめとするほとんどの部品が多重化されており、並列処理による処理性能の向上と耐障害性の向上が図られている。
[2] ネットワーク関連費用(情報処理センター内LAN機器、配線等の費用)、運用人件費については本調査の対象外とした。また、統合運用サーバの電算借料については他システムにて計上されているため、運用コストの対象外とした。
[3] 本調査では、パソコン・サーバやUNIXサーバを総称してオープン系サーバとした。
[4] 開発用の機器及びソフトウェア並びに保守料等については除外した。
[5] プログラムソースをオープンCOBOL等でリコンパイルし、オープン環境に移植する手法。単純なオープン化であり、システム機能や運用管理体制は変わらない。
[6] リホストに加えて、一部ユーザインタフェースに関る部分をJava等のオープン系標準言語で書き換える手法。Java等のオープン系標準言語の採用により、技術者の確保も容易でメンテナンス性の向上が期待できる。
[7] 既存システムの機能やアーキテクチャを分析し、全面的にオープン系システムに最適化して再構築する手法。新技術の採用やアーキテクチャの最適化により、システムの柔軟性が大きくなる。